의료기관의 예약 시스템을 개선하고, 네이버·당근·카카오톡 등 외부 플랫폼과 환자 데이터를 연동해 병원과 환자를 자연스럽게 이어주는 연동 서비스를 만들었습니다.
한 줄로 요약하면 “연동”이었지만, 실제로 마주한 문제는 화면(UI)부터 데이터 모델, SEO/SSR, 배포 구조, 협업 체계, 레거시 한계까지 전방위였습니다.이번 글에서는 단순히 “무엇을 했다” 가 아니라, 프로젝트에서 반복적으로 나타난 문제를 어떻게 분류하고, 어떤 원칙으로 해결했는지(그리고 무엇을 배웠는지) 를 정리해보려 합니다.
프로젝트에서 계속 반복되던 문제의 공통점
초반에는 이슈가 서로 다른 종류처럼 보였습니다.
- 병원 유입이 안 됨
- 플랫폼마다 포맷이 달라 연동이 깨짐
- 검색 노출이 안 됨(SSR/SEO 취약)
- 배포가 느리고, 실패 원인을 FE가 확인하기 어렵다
- 외부사 일정/스펙 조율이 혼란스럽다
- 레거시(Vue2) 구조가 확장/개선을 막는다
그런데 해결을 진행하면서 공통점이 하나 보였습니다.
“문제는 기능이 아니라 구조(입력 구조 / 데이터 구조 / 배포 구조 / 협업 구조)에서 터지고 있었다.”
그래서 저희 팀은 이 프로젝트를 구조를 재설계하는 프로젝트로 정의했습니다.
그리고 아래 순서로 문제를 풀려고 노력했습니다.
- UI 구조 재설계 (사용자 현실을 구조화)
- 데이터 모델 정규화 (포맷 차이를 FE에서 흡수)
- SSR/SEO 적용 (기술 구조로 유입 회복)
- 배포 파이프라인 개선 (FE가 독립 운영 가능)
- 문서화/동기화 체계 구축 (이해관계자 많은 환경에서 기준 만들기)
이 글에서는 기능 나열이 아니라, 문제가 구조에서 어떻게 발생했고 FE가 어떤 레벨까지 개입해 해결했는지를 정리하려고합니다.
1) 신규 병원 유입률 저조: “입력 UI가 이탈을 만든다”
이슈
의료 종사자의 플랫폼 접근성이 낮아 신규 병원 유입이 월 1곳 수준에 머물러 있었습니다.
가입 및 초기 세팅 과정에서 입력 단계가 복잡했고, 특히 입력 UI가 실제 병원 운영 방식과 맞지 않아 초기 이탈이 반복적으로 발생했습니다.
접근
신규 병원 유입의 병목이 기능이 아니라 입력 구조와 UX에 있다고 판단했습니다.
초기 UI 설계 단계에서 디자이너와 가장 중점적으로 논의한 지점 역시 “얼마나 간편하게 첫 입력을 끝낼 수 있는가”였습니다.
- 병원 운영 패턴(점심시간 / 요일별 운영 / 휴진)을 기준으로 운영시간·요일 입력 UI를 전면 재설계
- 시간·요일·휴진을 단순한 form 필드가 아닌 운영 단위 개념으로 모델링
- SNS·차트사 연동 확장을 고려해 통합 입력 스키마를 선제적으로 설계
- 병원 사용자 인터뷰를 통해 실제 입력 흐름을 분석하고 단계 최소화
닥톡의 주 고객층인 의료 종사자들은 공통적으로
자주 쓰는 화면, 큰 글자, 명확한 정보 구조를 선호했지만,
연령대와 전문과가 매우 다양해 모든 병의원을 포괄하는 UI는 현실적으로 어렵다고 판단했습니다.
이에 따라 대형 병원을 제외한 의원·중소 병원의 실제 사용 패턴에 초점을 맞추는 방향으로 합의했고,
프론트엔드 팀에서는 라이브러리를 사용하지 않고 직접 UI 컴포넌트를 설계·구현했습니다.
- 반드시 필요한 입력만 남기고 나머지는 자동화
- 클릭 한 번으로 확인·입력 가능한 구조 설계
- 입력 실수를 줄이기 위한 기본값·자동 계산 로직 적용
이 과정에서 다양한 케이스를 직접 테스트하며,
“최소 입력으로 최대한 정확한 운영 정보를 만들 수 있는 구조”를 목표로 반복 개선했습니다.
결과
- 입력 오류 감소 → 예약 연동 실패율 감소
- 회원가입 간소화 및 병의원 운영시간 입력 자동화로 초기 세팅 허들 대폭 감소
- 필수 입력 외 정보는 클릭 한 번으로 확인 가능한 구조 정착
- 이후 SNS 연동 확장 시에도 기존에 직접 구현한 UI 구조를 그대로 재사용, 추가 구조 변경 없이 대응 가능
배운 점
UI/UX는 화면을 예쁘게 만드는 문제가 아니라,
도메인과 사용자의 현실을 구조로 번역하는 작업이라는 점을 다시 체감했습니다.
특히 병원처럼 바쁜 사용자 환경에서는
‘완벽하게 정확한 입력’보다 현실적으로 빠르고 부담 없는 입력 경험이 더 중요했습니다.
이 경험을 통해, 입력 UI 설계가 곧 서비스 진입 장벽을 결정한다는 것을 명확히 인식하게 되었습니다.
2) SNS·EMR 포맷 불일치: “표준이 없으면 연동은 계속 깨진다”
이슈
네이버·당근·카카오·EMR 업체마다 데이터 구조가 모두 달라 FE/BE 연동 실패 사례가 계속 반복되고 밤새는 작업을 계속 했습니다. 표준 스키마가 없어서, 스펙 조율 비용이 계속해서 커지는 상태였습니다.
접근
작업을 빨리 들어가야하는 상황속에서 제가 할수 있는 방법들은 아래와 같았습니다.
- FE 기준으로 통합 ViewModel(표준 모델) 정의
- 서로 다른 API 응답을 매핑·정규화하는 유틸/모듈 구현
- TypeScript interface를 먼저 정의하고 BE와 스펙을 동기화
- 정규화 기반 Validation + 에러 핸들링 구조 정립
결과
- 플랫폼별 포맷 차이를 FE에서 흡수 -> UI 분기 제거
- 스펙 불일치 오류 감소 -> 개발 속도 개선
- FE가 정의한 TS interface가 팀 전체의 표준 스키마로 채택
배운점
복잡한 외부 연동 환경에서는 FE가 단순 UI구현자가 아니라,
데이터 모델링 중심의 조율자가 되어야 한다는 걸 확실히 느꼈습니다.
타입 정의/모델 정리는 중간 정리와 팀내부의 조율역할까지 할수 있기에 FE가 기술적 리더십을 가질 수 있는 강력한 수단이었습니다.
3) SEO 취약 & SSR 미지원(Vue2): “유입은 기술 구조에서 끊겼다”
이슈
Vue2 기반 구조로 SSR이 어려워 검색 노출이 거의 되지 않았습니다.
주요 페이지 검색 유입이 끊기면서 서비스 인지도가 낮아졌습니다.
접근
- SEO가 필요한 화면들을 Nuxt 기반 SSR로 점진적으로 이전하여 페이지 별 메타데이터 및 OG태그의 품질 향상, 중복 콘텐츠 제거 및 사이트 구조와 디자인 변화
- head/meta/OG 태그를 통합 효과적으로 관리하는 SEO 모듈 설계
결과
- 검색 노출 정상화 -> 외부 유입 개선
- SNS 공유 미리보기 정상 표시 -> 사용자 신뢰 향상
배운 점
SEO는 마케팅 문제가 아니라 기술 구조가 같이 들어가 마케팅 영역에 직접적으로 영향을 주는 영역이었습니다.
Vue 기반에서도 SSR 전환 플랜을 초기에 잡아야 비용이 줄어듭니다.
4) FE 배포 구조 비효율(Jenkins 의존): "FE도 배포를 통제해야 한다"
이슈
Jenkins 중심 구조에서 FE는 빌드/배포 상태를 직접 확인하기 어려웠고,
배포 실패 원인 파악도 BE에 의존해 비효율이 컸습니다.
내가 한 일
- Github Actions + AWS S3·CloudFront 기반 FE 전용 배포 파이프라인 설계
- FE도 직접 빌드/검증/배포 가능한 구조 구축
결과
- 배포 속도 개선 & CI/CD 가시성 향상
- FE가 독립적으로 운영 가능해져 개발 효율 증가
- 장애 대응 속도 단축
- 커뮤니케이션 비용 감소
배운 점
배포 파이프라인은 전적으로 DevOps만의 영역이 아니라,
FE 생산성을 좌우하는 핵심 인프라라는 걸 확실히 깨달았습니다.
5) 외부사 일정 충돌 & 스펙 조율 혼란: “기준이 없으면 커뮤니케이션이 비용이 된다”
이슈
SNS·차트사·병원 등 이해관계자가 많고 일정이 다 달라 조율 난이도가 높았습니다.
내부도 문서/스펙 기준이 불명확해 커뮤니케이션 비용이 커졌습니다.
내가 한 일
- 요구 필드·타입·예외 케이스를 정리한 통합 명세 문서(Notion) 생성
- 데일리 스크럼으로 외부사 일정/내부 진행/리스크 공유
- 업무를 파편화해 Notion에서 실시간 관리
결과
- 스펙 재확인 비용 감소
- 외부사/내부 개발팀 의사결정 속도 증가
- 팀 전체가 동일 기준으로 커뮤니케이션
배운 점
이해관계자가 많은 프로젝트일수록 FE가 정리자(Organizer) 역할을 해야 합니다.
문서화는 귀찮은 작업이 아니라 리스크를 제거하는 가장 강력한 도구였습니다.
6) 레거시(Vue2) 구조 한계: “구조가 의도를 담을 공간이 없었다”
이슈
Vue2 기반 구조에서 목적성 있는 아키텍처 적용이 어려웠고,
일정 압박으로 테스트 코드(TDD) 적용이 불가해 QA 부담이 컸습니다.
내가 한 일
- 폴더/모듈 구조를 점진적으로 개선하며 리팩토링
- QA 적용 방식 정리 → 후속 프로젝트에 반영 계획 수립
결과
- 타입 안정성 일부 확보 → 유지보수 비용 감소
- 후속 프로젝트(Vue3·TS)에서 아키텍처/리팩토링 전략을 빠르게 적용 가능
배운 점
레거시는 “오래된 코드”가 아니라,
기술적 의도를 반영할 공간이 부족한 상태라는 걸 체감했습니다.
다음 프로젝트에서는 TDD/구조 설계를 반드시 초기에 도입해야 한다는 확신이 생겼습니다.
7) 시간·스케줄 결합 UI에서 드러난 함수 설계의 중요성
이슈
병원 운영시간 입력 Input 컴포넌트는
주말·공휴일 체크, 평일 중 특정 요일 휴무, 요일별 운영시간 설정이 서로 강하게 결합된 UI였습니다.
시간과 스케줄이 동시에 변경되며 상호 영향을 주는 구조였기 때문에, 초기 구현 단계에서 QA 이슈가 집중적으로 발생했습니다.
초반에는
- 특정 체크를 해제했을 때 다른 요일의 시간이 의도치 않게 변경되거나
- 휴무 설정과 시간 입력 상태가 어긋나거나
- 일부 조합에서 입력이 불가능해지는 문제들이 반복되었습니다.
문제의 원인을 분석해보니,
하나의 함수가 너무 많은 역할을 동시에 수행하고 있었고,
시간 계산, 요일 활성화 여부, 휴무 판단 로직이 서로 얽혀 있었습니다.
그에 따른 QA 이슈가 다수 발생했고 제 머릿속에는 상호작용이 정리 되어 있지 않아 큰 복잡함을 느끼게 되었습니다.
내가 한 일
이후 접근 방식을 명확히 바꿨습니다.
- 하나의 함수는 하나의 책임만 가지도록 분리
- 시간 계산, 요일 활성화, 휴무 판단을 각각 독립적인 로직으로 분리
- UI 상태는 단일 함수에서 처리하지 않고, 작은 함수들을 조합해 상태를 구성
즉,
복잡한 기능을 만드는 함수가 아니라
단순한 기능을 수행하는 함수들을 조립해 복잡한 동작을 만드는 구조로 전환했습니다.
이 구조로 전환한 뒤에는
QA 과정에서 문제가 발생했을 때도
- “어떤 함수의 책임 영역에서 문제가 발생했는지”가 빠르게 드러났고
- 수정이 다른 로직에 영향을 주는 범위도 명확해졌습니다.
결과
- QA 단계에서 반복적으로 발생하던 케이스성 버그 감소
- 시간/스케줄 관련 로직 수정 시 사이드 이펙트 최소화
- 디자이너·기획자와 QA를 진행할 때 문제 지점을 로직 단위로 설명 가능
- 복잡한 UI임에도 점진적인 개선과 확장이 가능한 구조 확보
- 클린 코드로 인한 유지보수 난이도 하락
배운 점
이번 경험을 통해 명확히 얻은 교훈은 다음과 같았습니다.
- 함수는 최대한 단순해야 한다
- 복잡한 UI일수록 “큰 함수 하나”가 아니라
작은 기능 단위의 함수들을 조합하는 구조가 필요하다 - 특히 시간·스케줄처럼 상태 간 의존성이 강한 영역에서는
함수 설계가 곧 QA 비용과 유지보수 비용을 결정한다 - 클린 코드는 곧 코드를 파악하는 시간 자체를 줄여준다.
이후 다른 UI를 설계할 때도
“이 함수가 한 가지만 하고 있는가?”,
“이 로직은 조합 가능한 형태인가?”를 먼저 점검하게 되었고,
복잡한 화면일수록 구조를 먼저 나누는 방식이 습관으로 자리 잡았습니다.
마무리: “연동”을 통해 구조의 중요성을 체감하다
이 프로젝트는 단순히 기능을 구현하는 데서 끝난 작업이 아니라,
문제의 원인을 구조로 환원하고, 구조를 통해 해결해 나간 경험이었습니다.
- 사용자 현실을 반영한 입력 구조
- 외부 플랫폼 차이를 흡수하는 표준 데이터 모델
- SSR/SEO로 유입을 회복한 렌더링 구조
- FE가 독립적으로 운영 가능한 배포 파이프라인
- 이해관계자가 많은 환경에서 기준을 만드는 문서화 체계
결과적으로 “예약 연동”은 하나의 트리거였고,
실제 성과는 기술과 조직 양쪽을 함께 움직일 수 있는 구조를 만들어낸 것이었다고 생각합니다.
아쉬웠던 점과 한계
물론 부족한 부분도 분명했습니다.
- 디자인 시스템이 정립되지 않은 상태에서 개발을 진행하다 보니,
디자인과의 불일치로 재확인·수정 작업이 반복된 점 - TDD를 적용하지 못해 기능 추가 이후에도 수정 작업이 이어졌던 점
- 일정 압박 속에서 야간 작업이 반복되며, 개인적으로 사소한 실수가 발생했던 점
하지만 이런 시행착오를 통해
“왜 구조와 기준이 초기에 필요했는지”를 몸으로 이해하게 되었고,
개인적으로는 이후 부트캠프를 통해 구조적 설계와 테스트에 대해 더 깊이 학습하게 된 계기가 되었습니다.
다음 프로젝트에서 반드시 지키고 싶은 원칙
이 경험을 통해, 비슷한 규모와 복잡도를 가진 프로젝트를 다시 진행한다면 아래 원칙들은 반드시 지키고 싶다는 기준이 생겼습니다.
-
Storybook을 활용한 디자인 시스템 선제 구축
→ UI 변경과 커뮤니케이션 비용 최소화 -
기능을 최소 단위로 분해해 조립하는 방식으로 구현
→ 개발 시간 단축과 QA 비용 감소
문서화를 ‘사후 정리’가 아닌 ‘개발 과정의 일부’로 체계화
- 기술적 구조를 통해 커뮤니케이션 코스트를 줄이는 설계
→ 말로 설명하지 않아도 코드와 구조가 기준이 되도록
이 프로젝트를 통해 얻은 가장 큰 교훈은,
복잡한 문제를 해결하는 가장 현실적인 방법은 더 많은 기능이 아니라 더 나은 구조라는 점이었습니다.
앞으로도 기능 구현에 앞서
“이 문제를 구조로 풀 수 있는가?”를 먼저 고민하는 개발자로 성장해가고 싶습니다.
