🏥
병원이 원한 것은 단순 리뉴얼이 아니라 검색과 AI 답변에 인용되는 사이트였습니다. 화면부터 그리는 대신 정보구조와 시스템 간 계약을 먼저 세웠습니다.
배경
10년 가까이 멈춰 있던 소아·청소년 진료 특화 한의원의 사이트를 새로 지은 프로젝트입니다. 완성품을 납품하고 빠지는 외주가 아니라, 의료 파트너와 함께 서비스를 세우는 공동사업입니다. 기획과 프론트엔드를 함께 맡았고, 운영 백엔드(CMS·인증·리드)와 AI 챗봇 서버는 각각 별도 담당자 소관입니다.
한 일
- 정보구조와 페이지 표준을 먼저 세움: 진료과목 18개를 상위 메뉴 5개로 묶고, 의료진·시술처럼 화면이 감당할 수 있는 최대 수치를 미리 정해 항목이 늘어도 레이아웃이 무너지지 않게 했습니다. 의료진 소개·전후 비교·가격표·FAQ처럼 반복되는 형태를 표준 레이아웃으로 묶어 콘텐츠만 채우면 같은 품질의 페이지가 나오게 정리했습니다.
- 세 시스템이 주고받을 계약을 기능정의서로 직접 명세: 이 프로젝트에서 제일 오래 붙잡은 일입니다. WebSocket 접속·메시지 규격과 종료 코드별 프론트엔드 처리, 방문자·회원·운영자·최고관리자 4단계 권한, 대화 로그 30일 보관 후 파기, 동의 없는 상담은 서버에서 막도록 검증 위치까지 표로 정리했습니다. 백엔드 팀이 이 문서를 기준으로 구현했습니다. 협의를 왕복하는 대신 명세를 먼저 써서 넘기는 방식이 속도를 만들었습니다.
- 검증된 계보를 가져오고 답변 규칙까지 명세: 챗봇의 WebSocket과 화면 구성 방식은 전시 부스 앱에서 이미 3일간 현장에서 돌려본 구조를 기준 리포로 확정해 같은 방식으로 붙였습니다. 서버는 포크하지 않고 멀티테넌트로 분리 운영하는 쪽으로 정리했습니다. 의료 답변은 골든셋 54문항으로 만들어, 진단이 아니라는 고지와 진료 권유 필수 포함 규칙, "완치·보장" 같은 단정 표현 금지 규칙을 함께 정의해 백엔드에 넘겼습니다.
- 프론트엔드를 직접 구현하고 배포 후 직접 측정: 회원가입·이메일 인증, 카카오 로그인과 지도, 구조화 데이터(JSON-LD), 방문 계측, 운영 화면을 붙였습니다. 배포 직후 이미지 전송량을 직접 재보고 당일 고쳤습니다. 질환 상세 한 면을 여는 데 이미지가 33.8MB나 내려가고 있었고, 원고 이미지를 그대로 쓰던 게 원인이라 배치 시점에 WebP로 변환하고
next/image로 전환해 약 0.38MB로 줄였습니다. - 2017년에 멈춘 레거시 데이터의 이관 범위를 직접 판정: 검색 데이터 16개월치를 분석해 유입 페이지와 검색어 각 약 1,000건, 외부 링크 약 500건을 집계했습니다. 그 결과로 구 URL을 1:1 정밀 연결 / 카테고리 상위 일괄 / 폐기 세 가지로 나눠 이전 계획을 만들었고, 저작권 문제가 있는 언론 기사나 회수할 수 없는 첨부 이미지는 옮기지 않기로 판정하고 대체 방안을 제시했습니다.
- 막힌 결정을 풀어 일정을 움직임: 대화 로그 보관 기간과 위젯 디자인처럼 "병원 확정 필요"로 걸려 있던 항목을 근거를 정리해 직접 확정했고, 출시를 막고 있던 의존성 14건을 통화 한 번으로 전부 확정했습니다. 법적 판단이 필요한 동의 문구 한 건만 자문 회신 대기로 남겼습니다.
결과
- 프론트엔드 사실상 단독 구축: 리포 커밋 전건 본인
- 운영 v1.6.0 서빙: 개발·운영 이중 환경 라이브
- 33.8MB → 약 0.38MB: 질환 상세 이미지 전송량 (약 99% 감소)
- 18개 → 5개: 진료과목을 상위 메뉴로 재편
- 54문항: AI 답변 골든셋으로 응답 규칙 명세
- 14건 전건 확정: 출시를 막던 외부 의존성
정리
결정을 문서로 잡아두고 화면으로 확인받는 방식이 비개발자 파트너와의 협업에서 효과적이었습니다. 즉 협의를 왕복하는 대신 명세를 먼저 써서 넘기는 쪽이 빨랐고, 배포 뒤에는 직접 측정해야 문제가 보였습니다.