InBodyLIKE - 1

InBodyLIKE

서비스 중

헬스케어 스타트업이 오픈이노베이션 프로그램에 지원하고 진행 상황을 확인하는 공식 홈페이지 - 지원 데이터가 투자사 관리 시스템으로 바로 연결됩니다

Next.js 16React 19TypeScriptTailwind CSS v4SupabaseSWRFramer MotionResendReact Email카카오 OAuthGA4 / GTMVercel

주요 기능 개발

InBodyLIKE는 인바디와 블루포인트파트너스가 함께 운영하는 헬스케어 스타트업 지원 프로그램의 공식 홈페이지입니다. 외부 디자인 업체의 시안을 받아 주 개발자로 기획 협업부터 개발·배포·운영까지 담당했습니다.

이 홈페이지는 혼자 서 있지 않습니다. 지원자가 신청서를 내면 그 데이터는 투자사가 쓰는 운영 플랫폼(Lattice)으로 들어가야 합니다. 데이터를 내보내는 쪽 API와 받아 쓰는 홈페이지를 모두 제가 만들었기 때문에, 스펙의 빈틈을 사용자 입장에서 먼저 발견할 수 있었습니다.

1. 운영자가 개발자를 찾지 않아도 되는 구조

프로그램 소개·뉴스·갤러리·모집 분야·약관까지 홈페이지의 모든 내용을 Lattice 어드민에서 관리하고, 홈페이지는 그것을 받아 보여주기만 합니다. 문구 하나 고치려고 개발자에게 요청하는 흐름을 처음부터 없앴습니다.

  • 지원·문의·자료 제출이 전부 Lattice로 모여, 운영자는 한 곳에서 관리
  • 개인정보 처리방침 같은 약관 본문도 하드코딩하지 않고 받아와 표시하도록 전환

2. 회원가입과 로그인

이메일 가입과 카카오 로그인 두 경로를 모두 지원합니다. 카카오로 처음 들어온 사용자는 프로그램 지원에 필요한 정보가 비어 있어, 프로필을 채우는 단계를 따로 두었습니다.

  • 약관 동의를 언제 무엇에 동의했는지까지 기록 — 동의 여부만 남기면 되는 도메인이 아니기 때문
  • 사업자등록번호는 형식만 보지 않고 국세청 검증 규칙으로 확인해, 오타를 제출 시점에 차단

3. 지원·문의 플로우

프로그램마다 지원 양식이 다르기 때문에, 양식을 코드에 적어두지 않고 Lattice 에서 받아와 화면을 그리도록 만들었습니다. 새 프로그램이 열려도 개발 없이 양식을 바꿀 수 있습니다.

  • 이미 제출한 지원자가 다시 열면 기존 내용을 채워두고 수정 모드로 동작. 마감된 기수는 안내 문구로 차단
  • 문의가 접수되면 운영자에게 알림 메일을 보내되, 곧장 처리 화면으로 갈 수 있는 링크를 함께 동봉
  • 마이페이지에서 지원 현황과 프로필을 직접 확인하고 수정

4. 화면 품질과 검색 노출

디자인은 외부에서 받았지만, 시안이 다루지 않는 영역은 직접 판단해야 했습니다. 브레이크포인트 사이 구간, 아주 큰 화면, 첫 화면이 그려지는 순간 같은 것들입니다.

  • 모바일에서 첫 화면이 잠깐 데스크톱 크기로 그려지던 문제와, 1920px 초과 화면의 여백 문제를 해결
  • 흩어져 있던 버튼 스타일을 한 곳으로 모아 시안이 바뀌어도 고칠 곳이 하나
  • 프로그램 링크가 카카오톡·슬랙에서 제대로 펼쳐지도록 공유 카드 정비 — 모집에 직접 영향을 주는 부분
  • 방문 분석 도구를 연결하고 신청 버튼에 추적을 걸어 지원 퍼널을 확인 가능하게

트러블 슈팅 경험

1. 인증 메일 링크가 누르기도 전에 만료되던 문제

이메일로 가입한 뒤 인증 메일의 링크를 눌렀는데 "이미 만료되었다"는 응답이 나오는 사례가 있었습니다.

원인

메일 서비스와 보안 프로그램이 메일에 담긴 링크를 사용자보다 먼저 눌러 검사합니다. 인증 링크가 방문하는 즉시 완료되는 형태였기 때문에, 사용자가 클릭할 때는 이미 다 쓰인 상태였습니다.

해결

링크를 누르는 것만으로 인증이 끝나지 않게 바꿨습니다. 링크는 확인 페이지로 데려가기만 하고, 인증은 그 페이지에서 한 번 더 밟는 절차로 분리했습니다. 검사 프로그램이 미리 방문해도 인증이 소모되지 않습니다.

2. 남의 신청서를 볼 수 있는 구조를 사전에 차단

신청서를 Lattice로 보낼 때 "누가 낸 신청서인지"를 함께 보내야 했는데, 초기 구현은 이 값을 브라우저에서 받아 그대로 전달하는 형태였습니다.

원인

브라우저가 보낸 값을 그대로 믿으면, 요청을 조작해 다른 사람의 번호를 넣는 것만으로 남의 신청서를 열어볼 수 있습니다. 지원자의 개인정보와 사업 계획이 오가는 서비스라 넘길 수 있는 사안이 아니었습니다.

해결

두 겹으로 막았습니다. 홈페이지 쪽에서는 요청에 어떤 값이 들어 있든 서버가 알고 있는 로그인 정보로 덮어쓰고, Lattice 쪽에서는 받은 토큰의 주인과 신청서의 주인이 같은지 다시 대조하도록 설계했습니다. 홈페이지 코드가 실수해도 API가 한 번 더 막습니다.