새벽 3시, 당황한 의사 아빠가 만든 해열제 계산기

김솔

20일 전6분 읽기

Next.js TypeScript Zod 바이브코딩 육아

새벽 3시, 의사도 당황하는 순간

새벽 3시, 윤슬이가 불덩이 같았다.

응급실에서 열나는 소아 환자를 수도 없이 봤지만, 예상치 못한 내 아이의 열 앞에선 그냥 당황하는 아빠일 뿐이었다.

약장을 뒤져 타이레놀을 꺼내 들었는데 순간 머릿속이 하얘졌다.

"40개월에 15kg이면 몇 mL지? 아니 이게 타이레놀이었나, 부루펜이었나?"

급하게 스마트폰으로 검색했다:

광고만 가득한 '가짜' 정보 앱
개인정보를 요구하는 회원가입 페이지
보기만 해도 머리 아픈 복잡한 계산식

윤슬이는 계속 울고, 시간은 흘러가는데, 내가 필요한 건 딱 하나였다.

"지금 당장 몇 mL를 먹이면 되는가?"

그날 밤 윤슬이를 재우고 생각했다. "이건 나만의 문제가 아니겠구나."

골든타임은 거창하지 않다

다음날부터 Claude Code를 열었다.

"체중과 나이만 입력하면 타이레놀, 부루펜 복용량을 자동 계산해주는 웹앱 만들어줘. 최대한 간단하게."

완성된 계산기의 원칙은 세 가지:

앱 설치 불필요 - 링크 하나면 끝
회원가입 불필요 - 개인정보 수집 제로
입력은 최소한 - 체중과 나이만

체중 15kg, 40개월을 입력하면:

타이레놀 현탁액: 4.7~7.0mL (4-6시간마다)
부루펜 시럽: 3.8~7.5mL (6-8시간마다)
맥시부펜 시럽: 6.3~8.8mL (6-8시간마다)

모든 계산이 자동으로 화면에 표시된다.

아이를 기르며 배운 것은 골든타임이라는 게 거창한 게 아니라는 것이다. 아이가 열날 때 10분 안에 약을 먹이는 것과 30분 뒤에 먹이는 것, 의학적으론 큰 차이 없을 수 있지만, 부모의 불안감과 아이의 고통은 완전히 다르다.

이 계산기는 그 10분을 10초로 줄이고자 만들었다.

간단함 뒤의 복잡한 안전장치

간단해 보이는 UI 뒤에는 예상보다 복잡한 안전 설계가 숨어있다.

첫 번째 벽: 의료 데이터는 절대 틀려서는 안 된다

"Claude, 타이레놀 데이터 추가했는데 빌드가 실패해. 왜 그래?"

"제품 정보를 확인해보니, 아세트아미노펜의 농도는 32mg/mL 또는 50mg/mL만 가능합니다. 입력하신 데이터에 20mg/mL가 있어서 빌드가 차단됐어요. 이건 이부프로펜 농도예요."

"아, 내가 실수로 섞었구나. 그런데 이걸 어떻게 자동으로 잡아낸 거야?"

"Zod 스키마에 성분명과 농도의 논리적 조합을 검증하는 규칙을 넣어뒀거든요. 아세트아미노펜인데 농도가 20mg/mL면 말이 안 되잖아요. 이런 잘못된 데이터가 사용자에게 가기 전에 빌드 단계에서 막는 거죠."

일반 웹 앱은 버그가 있어도 새로고침하면 그만이다. 하지만 의료 소프트웨어는 다르다. 어린이 약물 투여에서 작은 오류도 심각한 결과를 초래할 수 있다.

두 번째 벽: 계산은 어떤 입력에도 안전해야 한다

"Claude, 이상한 숫자 입력하면 어떻게 돼?"

"모든 경우의 수를 고려했어요. 농도가 0이면 제품 데이터 오류로 차단하고, 계산 결과가 무한대나 NaN이 나오면 계산 오류로 처리해요. 최대 용량을 초과하면 자동으로 안전한 범위로 조정하고요."

"나이 제한은?"

"4개월 미만 아기에게 타이레놀, 6개월 미만에게 부루펜은 자동 차단됩니다. 사용하려고 하면 '병원 방문 필요' 메시지가 뜨고요."

어떤 입력이 들어와도 계산기가 안전하게 동작하거나 명확한 오류 메시지를 표시하도록 만들었다.

세 번째 벽: 글로벌 확장의 함정

한국에서 잘 작동하는 계산기를 만들고 나니, 영어권 부모들도 도울 수 있지 않을까 생각했다.

그런데 문제가 있었다.

"Claude, 맥시부펜도 영어로 번역해서 미국 버전에 넣어줘."

"잠깐만요. 맥시부펜의 주성분인 덱시부프로펜은 FDA 승인을 받지 않은 성분이에요. 미국에서는 판매되지 않아요. 영어 버전에 노출하면 안 됩니다."

"헉, 그럼 어떻게 해야 해?"

"각 제품마다 판매되는 시장을 정의하고, 사용자의 언어에 따라 해당 시장 제품만 보여주면 됩니다. 한국에서는 맥시부펜, 미국에서는 Motrin 같은 식으로요."

이 과정에서 배운 교훈: 글로벌 서비스는 번역이 아니라 현지화다. 언어뿐 아니라 규제, 문화, 사용 가능한 제품까지 모두 고려해야 한다.

비전공자의 바이브 코딩 여정

솔직히 말하면, 처음엔 막막했다.

TypeScript? Zod? 빌드타임 검증?

하나도 몰랐다.

하지만 Claude Code와 함께라면 가능했다.

"이 오류 메시지가 뭔 뜻이야?" "이 코드를 어떻게 테스트해?" "이 기능을 추가하려면 어디를 수정해야 해?"

하나씩 물어보고, 이해하고, 적용했다.

완벽한 코드를 처음부터 짤 필요 없었다. 작동하는 최소 버전을 만들고, 조금씩 개선하면 됐다.

중요한 건 실력이 아니라 "무엇을 만들고 싶은가"다.

아이디어가 명확하면, 도구는 그저 도와줄 뿐이다.

개발 과정 - 점진적 진화

Git 히스토리를 보면 프로젝트가 어떻게 성장했는지 알 수 있다:

1주차: 핵심 계산 로직 + 기본 UI 2주차: 안전성 강화 (빌드타임 검증, 방어적 프로그래밍) 3주차: FAQ 페이지, 유사 약품 정보 4주차: 영어 번역, 시장별 제품 필터링 5주차: SEO 최적화

총 13개의 Pull Request를 통해 기능이 점진적으로 추가되었다.

완벽을 기다리지 말고, 작동하는 최소 버전을 먼저 출시하라. 그리고 사용자 피드백을 받으며 개선하라.

도구는 도구일 뿐

이 계산기를 만들면서 가장 조심스러웠던 부분은, 부모들이 이것을 의료 조언으로 착각하지 않도록 하는 것이었다.

그래서 계산기 하단에 다음 경고를 명확히 표시했다:

이 계산기는 보조 도구일 뿐입니다. 다음 상황에서는 반드시 병원 진료가 필요합니다:

생후 3개월 미만 영아의 발열

열이 38도 이상으로 3일 이상 지속

경련, 의식 저하, 심한 보챔 동반

해열제를 먹여도 열이 떨어지지 않음

탈수 증상(소변량 감소, 입술 건조 등)

나의 진료 경험상, 체온계 숫자보다 부모의 '직감'이 더 정확할 때가 많았다.

"뭔가 이상하다" 싶으면, 주저하지 말고 병원에 가자.

배운 것들

1. 사용자 경험은 속도에서 나온다

10분을 10초로 줄이는 것. 이것이 진짜 가치다.

기술은 화려해 보이지 않아도, 사용자의 고통을 덜어주면 그것으로 충분하다.

2. 안전성은 처음부터 설계에 녹여야 한다

성능은 나중에 최적화할 수 있지만, 안전성은 처음부터 설계에 녹여야 한다.

특히 의료, 금융 등 실수가 치명적인 도메인에서는.

3. 완벽을 기다리지 마라

작동하는 최소 버전을 먼저 출시하고, 피드백을 받으며 개선하라.

13개의 작은 PR이 완벽한 첫 출시보다 낫다.

4. 비전공자도 의미 있는 것을 만들 수 있다

바이브 코딩 시대.

만드는 사람과 그렇지 않은 사람의 차이는 실력이 아니다.

용기다.

어제 밤, 윤슬이가 또 열이 났다.

이번엔 당황하지 않았다.

스마트폰으로 내가 만든 계산기를 열고, 체중 15kg을 입력했다.

5초 만에 답이 나왔다.

약을 먹이고 윤슬이를 재우며 생각했다.

새벽 3시, 당황하던 그날의 나에게 말해주고 싶다.

"괜찮아. 너는 곧 이 문제를 해결할 거야. 그리고 같은 고민을 하는 다른 부모들도 도울 거야."

당신도 오늘 시작해보면 어떨까.

내일 아침엔 당신도 누군가의 10분을 10초로 줄여줄 무언가를 만들 수 있을지도 모른다.