Editor’s Note
닥터나우에서는 어떤 일을 할까요? 에서는 의료 혁신을 향해 나아가는 닥터나우 크루원들이 일하는 이유, 각자의 위치에서 일하는 방식을 소개합니다.
에서 소개하는 분은 닥터나우 프론트엔드 개발자, 패드입니다. 유저 앱·웹, 의사 웹, 약사 웹, 어드민까지. 우리가 눈으로 보는 모든 것을 구현하는 사람들이 바로 Front-end Engineer인데요. 이분들은 닥터나우에서 어떤 경험과 성장을 하고 있을까요?
"닥터나우의 프론트엔지니어는 화면 너머의 경험을 코드로 완성하는 사람이에요"
닥터나우 프론트엔드 개발자 패드(Padd)
Q1. 안녕하세요, 닥터나우에서 어떤 일을 하고 있는지 소개해주세요!
"환자 앱, 의사 웹, 약사 웹, 어드민 — 서비스 전반의 프론트엔드를 책임지고 있어요."
안녕하세요, 닥터나우에서 프론트엔드 엔지니어로 근무하고 있어요. doctornow-fe-mono 프로젝트를 중심으로 환자 앱, 의사 웹, 약사 웹, 어드민까지 서비스 전반의 프론트엔드 구현을 담당하고 있어요.
한 서비스의 한 화면이 아니라, 닥터나우라는 의료 플랫폼을 구성하는 거의 모든 클라이언트 사이드를 다룬다고 보시면 돼요.
Q2. 닥터나우 FE 개발의 가장 큰 특징은 무엇이라고 생각하시나요?
"SSR, CSR, 웹앱 — 다양한 서빙 구조가 하나의 모노레포에 공존하는 환경이에요."
SSR, CSR, 웹앱 등 다양한 서빙 구조가 공존하는 환경이라는 점이 가장 큰 특징이라고 생각해요.
Next.js 기반의 SSR 서비스부터 Vite 기반의 어드민, React Native 앱까지 — 하나의 모노레포 안에서 다양한 기술 스택을 다루다 보니, 자연스럽게 폭넓은 기술 과제에 직면하게 되고 그걸 직접 해결해나가는 경험을 할 수 있어요.
최근에는 AI 도구와 백엔드 세션을 활용해서 Spring Boot/Kotlin 기반의 내부 도구에 기여하거나, 직접 어드민 기능을 구현하기도 했는데요. 점차 프론트엔드 엔지니어에서 Product Engineer로 역할이 확장되어 가는 과정에 있다고 느끼고 있어요. 직무의 경계를 스스로 확장해가는 — 그게 닥터나우 FE의 매력이에요.
Q3. 가장 기억에 남는 UX 개선 프로젝트가 있다면?
"약사웹 도매몰 퍼널 혁신 — 월 매출 30% 신장으로, UX가 비즈니스 지표를 움직였어요."
약사웹 도매몰의 퍼널을 혁신한 프로젝트가 가장 인상 깊어요.
기존에는 도매 상품 검색이 불편하고 결제까지의 단계가 복잡해서 이탈률이 높았는데, 여기서 "왜 이탈이 발생하는지" 를 깊이 들여다보는 데서 시작했어요.
✔️ 상품 리스트에서 장바구니나 결제로 바로 이어지는 직결 퍼널을 구축하고
✔️ 품절 상품에 대한 서버 실시간 교차 검증 로직을 추가해서 주문 실패도 방지했어요
그 결과 월 도매 매출이 약 30% 이상 성장했고, 참여 약국 비율도 2.19% 상승했어요. 작은 UX 개선이 비즈니스 지표에 직접적으로 연결된다는 것을 체감한 사례였어요. 화면을 만드는 게 아니라 고객(약사)의 임팩트를 만드는 일이 프론트엔드의 본질이라는 걸 다시 느낀 프로젝트였어요.
Q4. 의료 서비스에서 사용자 불안을 줄이는 UX, 어떻게 만드나요?
"기술적인 이유로 흐름이 끊기는 경험은 최대한 없어야 한다고 봐요."
서비스 이용 과정에서 흐름이 끊기거나 예상과 다르게 동작하는 순간이 사용자에게 가장 큰 스트레스를 준다고 생각해요. 그래서 전환 과정에서의 끊김을 없애는 데 특히 신경을 쓰고 있어요.
첫 번째 사례로는, 결제 시스템을 토스페이먼츠로 전환할 때 결제 끊임을 방지했던 일이에요. 결제 시스템을 토스페이먼츠로 전환했을 때, 웹 뷰에서 결제창이 열리고 다시 앱으로 돌아오는 과정에서 데이터가 사용자는 결제가 된 건지 안 된 건지 불안해질 수밖에 없어요. 이걸 해결하기 위해 BroadcastChannel API를 활용해서 웹뷰와 앱 간 실시간 데이터 동기화를 구현했고, 결제 경험이 끊기지 않도록 만들었어요.
두 번째 사례로는, Web-to-App 전환 플로우 최적화를 들 수 있어요. 당시 제가 받은 미션은 웹 유저를 앱 유저로 전환하는 역할을 맡았었는데요. 웹에서 저희 서비스를 접한 유저가 앱을 설치하고 진료까지 도달하는 과정이 매끄럽지 않다면 중간에 많은 이탈이 일어나게 돼요. 이걸 해결하려고 Airbridge 딥링크를 고도화해서 웹 유입 유저가 앱 설치 후, 원래 의도했던 진료 화면까지 자연스럽게 이어지도록 최적화했어요. 그랬더니 일일 앱 설치 수가 기존 대비 2.5배 증가, 진료 전환이 4배 증가하는 결과로 이어졌죠.
결국 사용자가 의식하지 못할 정도로 자연스러운 흐름을 만드는 것이 의료 서비스에서의 불안을 줄이는 핵심이라고 생각해요. 아픈 상태에서 서비스를 이용하는 분들이기 때문에, 기술적인 이유로 흐름이 끊기는 경험은 최대한 없어야 한다고 봐요.
Q5. FE로서 성능 최적화나 접근성 개선을 위해, 기억에 남는 작업이 있다면?
"DNS 조회 44ms → 2.2ms, CI 빌드 9분 → 10초대 — 숫자로 증명하는 개선이에요."
몇 가지 대표적인 사례가 있어요.
먼저, SSR 성능 개선 AWS ECS 환경에서 Next.js 서버의 외부 API 호출 시 잦은 DNS 조회로 인해 응답 지연이 발생하고 있었는데, Node.js 프로세스 레벨에서 cacheable-lookup을 활용한 인메모리 DNS 캐싱 레이어를 구현해서 평균 DNS 조회 시간을 44ms에서 2.2ms로 단축하고, 캐시 히트율 99.93%를 달성했어요.
CI/CD 단축 모노레포 내 테스트 코드 증가로 CI가 9분을 넘기고 있었는데, dayjs 같은 무거운 라이브러리의 전역 Mocking 처리와 Jest 환경 튜닝을 통해 9분 12초에서 10초대로 약 98% 단축시켰어요.
렌더링 성능 개선 Styled-components의 런타임 오버헤드를 해소하기 위해 Tailwind CSS와 Radix UI 기반의 Headless 디자인 시스템을 구축해서 런타임 스타일링 비용을 제거했고, 광고 컴포넌트에는 IntersectionObserver를 활용한 지연 로딩을 적용해 CWV 지표 저하 없이 광고 시스템을 도입했어요.
검색 노출 개선 (SEO) URL 구조를 쿼리 파라미터 방식에서 경로 방식으로 변경하고, H1 태그 적용 및 메타 태그 동적 생성 로직을 개선해서 주요 검색 엔진에서 서비스 페이지가 상단에 안정적으로 노출되도록 만들었어요.
매번 "더 나은 방법이 있을 거야"라는 믿음으로 끝까지 집요하게 파고들었던 결과들이에요.
Q6. 기획, 디자인, 백엔드와 협업할 때 FE 로서 어떤 역할을 해오고 계신가요?
"AI 에이전트의 발전을 기점으로, 역할이 'Product Engineer'로 확장됐어요."
AI 에이전트의 발전을 기점으로 프론트엔드 엔지니어의 역할 정의가 달라졌다고 생각해요.
[이전] UX적 결함이 없는지 검토하고, 기획과 디자인이 화면으로 구현 가능한지·일정 내에 소화할 수 있는지를 판단하며, 구현 방식에 따른 사이드이펙트를 점검한 뒤 백엔드와 스펙을 협의해서 화면을 만들어내는 역할이었어요.
[이후] 에이전트의 발전 이후로는 좀 더 제품 관점에서 기획 단계부터 관여하게 되었어요.
✔️ 정의한 문제의 배경부터 함께 논의하고 ✔️ 어떤 문제를 해결하려는 것인지 서로 같은 이해 수준을 맞춘 뒤 ✔️ 그 위에서 전략이나 기능에 대한 의견을 내고 ✔️ 거기에 클라이언트 사이드의 도메인 지식을 더해 기술적인 제안을 하는 방식으로 역할이 확장되었어요
결국 각 직무 고유의 헤리티지를 가진 제품 개발의 일원으로 통합되어 가고, 직무 간 경계는 점점 흐려질 거라고 생각해요. 그 변화의 한가운데에 있다는 게 닥터나우 FE에서 일하는 즐거움이에요.
Q7. 닥터나우 FE 코드베이스에서 가장 자랑스러운 부분이 있다면?
"가장 자랑스러운 건, 가장 최근에 정착시킨 Micro FSD 아키텍처예요."
가장 최근에 프론트 사이드에 정착시킨 Micro FSD 아키텍처를 두 가지 측면에서 자랑스럽게 생각해요.
1️⃣ AI 친화적인 구조 도메인 단위의 스코프로 코드가 재정의되면서 AI 도구가 코드를 탐색하고 수정하기에 훨씬 친화적인 구조가 되었어요. CLAUDE.md를 에이전트 친화적으로 구성하고 Cursor IDE 설정까지 프로젝트에 통합해서, 팀 전체가 이 구조의 이점을 체감하고 있어요.
2️⃣ 아키텍처 무결성 자동 검증
MVVM 패턴과 ACL 패턴이 잘 유지되어 UI, 비즈니스 로직, 서버 통신부가 명확히 분리되어 있고
Slice 간 직접 참조를 금지하고 Public API를 통해서만 소통하도록 강제하면서
madge 기반 순환 참조 감지까지 CI에 포함시켜 아키텍처 무결성이 자동으로 검증되는 체계를 갖추고 있어요
단순히 동작하는 코드가 아니라, 시간이 지나도 망가지지 않는 구조를 만드는 일 — 그게 가장 자랑스러운 부분이에요.
Q8. 빠르게 변화하는 규제나 방향 속에서 FE를 유연하게 유지하는 방법이 있다면?
"확장 가능한 구조를 미리 잘 설계해두는 것 — 구조가 곧 유연함의 토대예요."
확장 가능한 구조를 미리 잘 설계해두는 것이 핵심이라고 생각해요.
코드 컨벤션과 아키텍처를 탄탄하게 잡아두는 게 중요한데요, AI가 코딩에 깊이 관여하는 시대이기 때문에 디자인 시스템, Micro FSD 아키텍처, ACL 같은 결정적인 패턴과 구조를 잘 구축해서 '하네스'를 만들어 놓으면, 어떤 기능 변화나 규제 변경이 와도 AI를 활용해서 유연하게 확장할 수 있다고 생각해요.
실제로 저희도 Feature Flag를 적극 활용해서 광고 시스템이나 PG사 전환 같은 민감한 변경 사항을 점진적으로 롤아웃하고 있고, 서버 피처 플래그 기반으로 관측성 수준까지 동적으로 제어할 수 있는 구조를 갖추고 있어요.
구조가 곧 유연함의 토대라고 봐요. 비대면 진료처럼 정책 변화가 잦은 도메인일수록 더더욱요.
Q9. 닥터나우에서 가장 성장했다고 느꼈던 경험이 있다면?
"기능 구현을 넘어, 팀의 개발 문화와 코드 품질 자체를 끌어올리는 경험을 했어요."
레거시 코드를 모노레포로 전환하고, 디자인 시스템을 구축하고, Micro FSD 아키텍처를 도입해서 의사 웹과 약사 웹 전체에 마이그레이션을 완료하기까지 — 프론트엔드 레벨에서 발전시킬 수 있는 부분들을 직접 전파하고 적용해온 과정이 가장 큰 성장이었어요.
단순히 기능을 구현하는 것을 넘어서 팀의 개발 문화와 코드 품질 자체를 끌어올리는 경험을 했고요.
지금은 거기서 한 단계 더 나아가서 CLAUDE.md, Cursor IDE 통합 같은 AI 개발 환경을 구축하면서, AI를 어떻게 하면 더 효과적으로 활용할 수 있을지 고민하고 그를 위한 하네스를 만드는 방향으로 관심이 이동하고 있어요.
매번의 시도를 돌아보면서, 다음에는 더 나은 방향으로 — 그 사이클이 쌓여 지금의 코드베이스가 만들어졌어요.
Q10. 미래의 FE 동료에게, 닥터나우를 추천한다면?
"많은 권한과 책임을 가지고 다양한 시도를 해볼 수 있는 환경이에요."
솔직히 말씀드릴게요. 때로는 제안했던 일들이 정책 이슈에 막히기도 하고, 진행 중이던 작업이 빠르게 롤백되거나 방향이 바뀌는 경우도 있어요.
하지만 그럼에도 불구하고, 많은 권한과 책임을 가지고 다양한 시도를 해볼 수 있는 환경이라는 점이 가장 큰 매력이라고 생각해요.
자율이 큰 만큼 그에 따르는 책임도 크고, 그래서 내 손으로 만든 변화가 실제 서비스에 반영되는 경험을 자주 할 수 있어요.
순수하게 FE로서의 성장만을 추구하기보다는, Product Engineer로서 제품 전체를 바라보며 성장하고 싶은 분에게 잘 맞는 곳이라고 솔직하게 말씀드리고 싶어요.
Tas
닥터나우 크리에이터 겸 피플 매니저
"닥터나우에서 이모저모를 담당하며, 크루원들의 다양한 이야기를 공유해요."
