Editor’s Note
닥터나우에서는 어떤 일을 할까요? 에서는 의료 혁신을 향해 나아가는 닥터나우 크루원들이 일하는 이유, 각자의 위치에서 일하는 방식을 소개합니다.
에서 소개하는 분은 닥터나우 초창기부터 함께해 온 백엔드 개발자, 대니입니다. 비대면 진료라는 새로운 의료 경험 뒤에는 환자, 의사, 약사를 잇는 단단한 서버가 있어요. 처방부터 조제까지, 보이지 않지만 가장 중요한 흐름을 책임지는 닥터나우 백엔드 엔지니어는 어떻게 일하고 있을까요?
"닥터나우 백엔드 앤지니어는 서버와 시스템으로 의료 서비스의 신뢰를 만드는 사람이에요"
닥터나우 백엔드 개발자 대니(Danny)
Q1. 안녕하세요, 닥터나우에서 어떤 일을 하고 있는지 소개해주세요!
안녕하세요, 닥터나우에서 백엔드 엔지니어로 일하고 있는 대니예요. 초기에 합류해서 서비스 초반부터 지금까지 함께해 왔는데요.
닥터나우의 의료 여정을 만드는 데 많은 노력을 쏟아 왔고, 그만큼 빠르게 성장할 수 있었던 것 같아요.
현재는 진료 예약/매칭부터 진료, 처방, 조제까지 — 환자가 앱을 열고 의사를 만나 처방을 받고 약국에서 약을 받기까지, 서비스 전반의 흐름을 다루는 서버 쪽을 책임지고 있어요. 한마디로 사용자가 보지 못하는 모든 흐름을 설계하고 운영하는 일이에요.
Q2. 닥터나우의 백엔드에서 가장 중요하게 생각하는 기술적 가치는 무엇인가요?
"단연 '신뢰성'이에요. 의료 서비스니까요."
저는 신뢰성을 가장 중요하게 생각해요. 이 서비스를 쓰는 분들이 아픈 상황인 경우가 많아서, 예약이 안 되거나 결제가 잘못되는 게 단순한 불편함으로 끝나지 않는다고 생각하거든요. 누군가에겐 골든타임을 놓치는 일이 될 수도 있어요.
그래서 "이 코드가 실제 상황에서 문제없이 동작할까?" 를 먼저 떠올리는 습관이 자리 잡았어요. 단순히 동작하는 코드가 아니라, 어떤 상황에서도 동작하는 코드를 만드는 것 — 그게 의료 서비스 백엔드의 출발점이라고 생각해요.
Q3. 가장 도전적이었던 기술적 문제는 무엇이었고, 어떻게 해결했나요?
"약국별 처방약 조제 가능성 시스템 — '왜?'에서 시작된 설계였어요."
가장 기억에 남는 건 약국별 처방약 조제 가능성 시스템이에요.
오프라인에서는 병원에서 처방을 받으면 근처 약국에서 대부분 조제가 가능하잖아요. 동네 병원과 약국이 자연스럽게 연결된 구조라서 크게 문제가 되지 않거든요.
그런데 비대면 진료는 상황이 달라요. 의사와 환자 사이에 거리 제한이 없다 보니, 처방된 약이 환자 주변 약국에 없을 수 있어요. 그래서 약국 리스트 단계에서 조제 가능 여부를 미리 보여줘야 했는데, 약국마다 보유 약품이 다르고 처방 조합에 따라 결과도 달라지다 보니, 이를 어떻게 판별할지 설계하는 것 자체가 가장 큰 도전이었어요.
이때 "왜 이 문제가 발생하는지"부터 깊이 파고든 게 큰 도움이 됐어요. 단순히 로직을 만드는 걸 넘어서, 그 결과를 사용자에게 이해하기 쉽게 전달하는 방식까지 함께 고민해야 했고요. 의료 도메인의 복잡한 현실을 시스템으로 풀어내는 경험 — 진짜 백엔드 엔지니어의 일이 무엇인지 알게 된 프로젝트였어요.
Q4. 의료 도메인의 특수성이 개발 방식에 어떤 영향을 주나요?
"의료법과 정책이 바뀌면, 며칠 안에 시스템도 바뀌어야 해요."
두 가지가 특히 크게 영향을 줘요.
첫 번째는 의료법과 정책 변화에 빠르게 대응해야 한다는 점이에요. 정책이 바뀌면 비즈니스 로직이 바뀌고, 그게 곧 시스템 변경으로 이어지거든요. 때로는 며칠 안에 대응해야 하는 경우도 있어서, 변화에 유연하게 대응할 수 있는 구조를 미리 만들어두는 게 얼마나 중요한지 실무에서 계속 체감하고 있어요. 특히 2025년 12월 비대면 진료 제도화 이후로는 이런 변화가 더 빨라지고 있고요.
두 번째는 환자, 의사, 약사 — 세 주체를 동시에 고려해야 한다는 점이에요. 한 사람의 행동이 다른 사람에게 연쇄적으로 영향을 미치는 구조거든요.
예를 들어 "진료 취소" 라는 단순해 보이는 기능도 세 입장이 다 달라요.
✔️ 환자: 쉽고 빠르게 취소할 수 있어야 하고 ✔️ 의사: 무응답 환자가 반복되면 패널티가 필요하고 ✔️ 약사: 이미 조제를 시작했다면 재고 원복 처리가 필요해요
복잡하게 느껴질 때도 있지만, 그게 오히려 깊이 있는 설계 경험을 쌓을 수 있게 해줘요. 일반적인 서비스에선 만나기 어려운 종류의 문제들이거든요.
Q5. 트래픽 급증이나 장애 상황에서 어떻게 대응했나요?
"코로나 오미크론 시기, 갑작스러운 트래픽 폭증에 팀이 함께 뛰었어요."
코로나 오미크론 시기에 트래픽이 급격히 늘어나면서 서버가 다운된 적이 있어요. 평소와 다름없는 날이었는데, 갑자기 장애 알림이 몰리면서 상황을 인지하게 됐어요.
이때 혼자가 아니라 팀이 함께 빠르게 대응한 경험이 정말 인상 깊었어요. 스케일 업/아웃과 쿼리 최적화를 통해 빠르게 복구했고요. 이후에는 슬로우 쿼리, N+1, 대량 데이터 처리 과정에서 발생하는 DB 부하 패턴들을 하나씩 개선해 나갔어요.
이 경험 이후로는 기능을 구현할 때도 "이게 실제 트래픽에서 어떻게 동작할까" 를 먼저 생각하게 된 것 같아요. 그리고 장애가 났을 때 끝나는 게 아니라, 회고를 통해 더 단단해지는 시스템을 만드는 것 — 그게 진짜 배움이라는 걸 느낀 순간이에요.
Q6. 팀 내에서 기술적 의사결정은 어떻게 이뤄지나요?
"충분히 이야기하고, 결정되면 빠르게 실행해요."
중요한 결정일수록 혼자 정하기보다는 팀원들과 충분히 이야기해보는 편이에요. 각자 보는 관점이 달라서, 논의하다 보면 생각하지 못한 의견이 나오는 경우가 많거든요.
저희 팀은 "이것까지 공유해야 하나?" 싶은 부분까지 투명하게 공유하는 문화가 있어요. 그래서 의사결정의 맥락이 자연스럽게 모두에게 전달되고요.
충분히 이야기해서 방향이 정해지면, 왜 그렇게 결정했는지를 같이 이해하는 걸 중요하게 생각해요. 그 다음에는 의견은 달랐더라도 결정된 목표에 모두가 함께 몰입해서 빠르게 실행으로 옮기는 편이에요.
Q7. 코드 품질과 개발 속도, 어떻게 균형을 잡는 편인가요?
"'일단 빠르게, 그 다음엔 제대로' — 이 사이클을 의식적으로 반복해요."
솔직히 말하면, 스타트업이다 보니 속도를 우선시해야 하는 순간이 많아요. 빠르게 검증하고 시장에 내놓는 게 중요한 단계가 분명히 있거든요.
다만 그 과정에서 쌓이는 기술 부채를 인식하고, 적절한 시점에 반드시 개선하는 것도 개발자의 책임이라고 생각해요. 빚을 모른 척 쌓아두는 게 아니라, '지금 이 빚을 지고 있다'는 걸 알고 가는 거죠.
빠르게 가는 것과 제대로 가는 것, 둘 중 하나를 선택하는 게 아니라 지금 상황에서 가장 좋은 결과가 무엇인지를 판단하는 것이라고 생각해요. "일단 빠르게, 그 다음엔 제대로" — 이 사이클을 의식적으로 반복하려고 해요. 그리고 그 안에서 항상 더 나은 방법이 있다는 믿음을 놓지 않으려고 해요.
Q8. 닥터나우에서 개발자로서, 크게 성장했다고 느낀 순간은?
"시야가 넓어졌고, 서비스가 실제로 퍼지는 걸 실감했어요."
두 가지 순간이 떠올라요.
첫 번째는 문제를 바라보는 시야가 넓어졌다는 걸 느꼈을 때예요. 예전엔 주어진 태스크를 구현하는 데 집중했다면, 지금은 왜 이 기능이 필요한지, 다른 도메인에 어떤 영향을 주는지까지 자연스럽게 고민하게 됐어요. 매 작업마다 회고하는 습관이 쌓이면서 그 변화가 만들어진 것 같아요. 성공한 일도, 아쉬웠던 일도 — 다 돌아보다 보면 다음에는 다르게 해볼 수 있는 게 보이거든요.
두 번째는 서비스가 실제로 퍼지고 있다는 걸 실감할 때예요. 처음엔 주변 친구나 지인한테 닥터나우 얘기를 꺼내도 잘 모르는 경우가 많았는데, 이제는 먼저 닥터나우 쓴다고 얘기를 듣곤 해요. 내가 만든 게 실제로 사람들한테 닿고 있다는 게 느껴지는 순간 — 그게 닥터나우에서 일하면서 가장 보람된 부분이에요.
Q9. 닥터나우 백엔드 팀의 문화가 있다면?
"기획 단계부터 개발자가 함께 들어가요."
제가 사실 닥터나우가 첫 회사라 다른 팀과 직접 비교할 수 있는 기준은 많지 않지만, 한 가지는 확실히 느끼고 있어요.
기획 단계부터 개발자가 함께 참여해서, 왜 이 기능을 만드는지부터 같이 고민한다는 점이에요.
스펙이 정해진 이후에 구현만 하는 구조가 아니라, 문제를 정의하는 단계부터 같이 들어가다 보니 더 깊이 있게 고민하게 되고, 그만큼 내 일이라는 책임감도 자연스럽게 생기는 것 같아요. 단순히 "시키는 걸 만드는 개발자"가 아니라 "같이 문제를 푸는 동료" 로서 일할 수 있는 환경이에요.
Q10. 미래의 디자이너 동료에게, 닥터나우를 추천한다면?
"복잡한 도메인을 제대로 다뤄보고 싶은 개발자라면, 분명 후회 없을 거예요."
복잡한 도메인을 제대로 다뤄보고 싶은 개발자라면 한 번 고려해볼 만한 곳이라고 생각해요.
환자, 의사, 약사가 얽힌 의료 플로우는 일반적인 서비스와는 달라요. 도메인을 깊이 이해하고 그걸 시스템으로 풀어내는 경험을 쌓을 수 있어요. 비대면 진료 제도화로 시장이 본격 확장되는 지금, 디지털 헬스케어 백엔드 엔지니어로서 의미 있는 도전을 해볼 수 있는 시기이기도 하고요.
그리고 함께 고민할 수 있는 동료들이 있다는 점도 큰 장점이에요. 어려운 문제를 혼자 해결하기보다 같이 논의하면서 방향을 잡아가는 과정에서 많이 배우게 돼요. 서로를 존중하면서, 솔직하게 의견을 내고, 결정되면 함께 달려가는 — 그런 동료들이 있어요.
의미 있는 문제를 팀으로 같이 풀어보고 싶은 분이라면 잘 맞을 거라고 생각해요.
Tas
닥터나우 크리에이터 겸 피플 매니저
"닥터나우에서 이모저모를 담당하며, 크루원들의 다양한 이야기를 공유해요."
