직짱건강 — 직장인을 위한 올인원 헬스케어 서비스

한눈에 보기

헬스케어 도메인을 공부하고 싶은 개발자와 비개발자가 모인 동아리에서 진행했습니다. 여러 주제 중 직접 기획한 아이템을 만들고 싶었고, 간호사로 근무했던 기획자님 의견을 바탕으로 방향을 잡았어요. 증상에 따라 건강 설문을 제공하고, 위치 기반 병원 추천과 별점·리뷰 기반 선택, 건강 관리 캘린더까지 한데 모으는 구성이었습니다.

사이드 프로젝트라 사용자 규모 기반의 정량 지표가 없습니다. 아래 성과는 팀의 작업 방식이 어떻게 달라졌는지 중심으로 적었어요.

1. 건강 설문 — 백엔드를 기다리지 않기로 한 결정

상황. 초기 단계라 백엔드 API가 미완성이었습니다. 설문 인터페이스는 이 서비스의 첫 화면이자 핵심이라 개발과 테스트가 급했는데, 연동 대상이 없었어요.

고른 방법. API를 기다리는 대신 JSON 목업 데이터로 설문 데이터를 관리하고, 사용자 선택과 데이터 필터링 로직을 실제 백엔드 없이 먼저 구현했습니다.

③의 리스크가 표에 적은 그것이라서, 관리 방법은 목업의 형태를 실제 응답 형태와 같게 맞추는 것이었습니다. 백엔드와 스키마 합의를 먼저 하고 시작한 게 이 작업에서 제일 중요한 부분이었어요. 목업을 대충 만들면 연동 시점에 화면 로직을 다시 짜게 되고, 그러면 목업으로 아낀 시간이 전부 사라집니다. 즉 ③은 "단점이 없는 선택"이 아니라 단점을 합의로 앞당겨 지불한 선택이었습니다.

한 일.

• 단계별로 동적 필터링되는 설문 데이터 로직 구현
• useEffect 기반 반응형 화면 업데이트
• 화면 크기에 따른 CSS 클래스 동적 적용

결과. 설문 인터페이스를 먼저 완성하고 이후 데이터 매핑만으로 연동을 끝냈습니다. 무엇보다 백엔드 팀이 API 개발에 집중할 수 있는 병렬 작업 환경이 만들어졌어요. 설문 항목 추가·변경도 JSON만 고치면 되니 기획 변경에 빠르게 대응할 수 있었습니다.

기간이 짧은 협업 프로젝트에서 "내 작업이 남의 작업에 막히지 않게 만드는 것" 자체가 기여라는 걸 이때 배웠습니다.

2. 병원 북마크 — 클라이언트 상태와 서버 상태를 나눠 관리

상황. 북마크한 병원 정보와 건강 설문 데이터를 다루는 인터페이스가 필요했습니다. 상태 관리와 네트워크 요청이 정리되지 않으면 화면이 계속 깜빡이거나 옛 데이터를 보여주게 되는 영역이었어요.

고른 방법. 상태를 성격에 따라 나눴습니다.

서버에서 온 데이터를 전역 스토어에 복사해두면 두 벌이 되고 그 순간부터 동기화 문제가 시작됩니다. 서버 데이터는 서버 데이터를 다루는 도구에 맡기고, 클라이언트가 만들어낸 상태만 전역으로 뒀어요.

한 일.

• 북마크 삭제 후 UI와 데이터 실시간 동기화, 삭제 결과를 Snackbar로 즉시 피드백
• 인증 여부를 확인하는 useAuthRedirect 훅 설계 및 리다이렉션 처리
• 로딩 중 / 데이터 없음 상태에 따른 동적 화면 처리
• 재사용 컴포넌트(LikeList, NoLike)로 목록·빈 상태 표현 일관화

결과. 북마크 조작 결과가 지연 없이 화면에 반영되고, 빈 상태·로딩 상태가 화면마다 다르게 보이는 문제가 사라졌습니다.

빈 상태(NoLike)를 따로 컴포넌트로 뺀 게 의외로 효과가 컸어요. 아무것도 없는 화면은 대충 만들기 쉬운데, 신규 사용자가 처음 보는 화면이 대체로 그 화면이거든요.

3. 돌아보면

• 의존성 때문에 막힐 것 같으면, 의존성을 잠시 끊는 방법부터 찾는 게 빨랐습니다. 목업으로 먼저 만든 게 제 일정만 아니라 백엔드 팀 일정까지 풀어줬어요.
• 목업은 실제 응답 형태와 같게 만들어야 의미가 있습니다. 형태가 다르면 연동 시점에 화면을 다시 짜게 되고, 그러면 아낀 시간이 전부 없어져요.
• 서버 상태와 클라이언트 상태를 한 스토어에 섞지 않는 것이 이 프로젝트에서 얻은 기준입니다. 이후 TripTune에서도 같은 방식(React-Query + Zustand)으로 갔어요.
• 비개발자와 함께한 게 컸습니다. 간호사 출신 기획자가 없었으면 설문 문항 자체가 성립하지 않았을 거예요. 도메인 지식이 있는 사람이 팀에 있는 것과 없는 것의 차이를 처음 체감했습니다.

화면