[연재] 클로드에게 처음 시킨 것 — HTML 한 장에서 시작
만든 지 35분쯤 됐을 때, 계산기가 저한테 거짓말을 했어요
체크박스 하나를 켰습니다. "배우자도 육아휴직을 사용합니다"라는 칸이요.
그랬더니 받을 돈이 월 250만 원에서 450만 원으로 뛰었습니다.

부모가 둘 다 육아휴직을 쓰면 6+6 제도가 붙어서 첫 6개월 상한이 250 / 250 / 300 / 350 / 400 / 450만 원으로 올라가거든요. 그러니까 이 표 자체는 맞습니다.
문제는 배우자가 0개월이어도 이게 붙었다는 거예요.
체크박스만 켜고 옆의 슬라이더를 0에 둬도 상한이 올라갔습니다. 배우자는 휴직을 하루도 안 쓰는데요. 실제로는 못 받을 돈을 받는다고 말하는 계산기였던 겁니다.
육아휴직 급여 계산기를 보러 오는 사람은 대개 진짜로 휴직을 앞둔 사람이에요. 그 사람이 이 화면을 보고 "1년에 이만큼 나오네" 하고 계획을 세우면요. 남한테 돈 얘기로 거짓말을 하는 물건을 만든 셈이 됩니다.
2026년 7월 22일 오후 3시 39분에 잡았습니다. 만들기 시작한 지 35분 만이었어요.
그날 하루가 이랬습니다
이건 그날 나온 여러 건 중 하나였어요. 통상임금에 음수를 쳤더니 급여가 −540만 원으로 나온 것도 있었고, 월급 60만 원인 사람에게 70만 원을 준다고 계산할 뻔한 것도 있었습니다.
그리고 그날 나온 물건이 이겁니다.

육아휴직 급여 계산기예요. 통상임금을 넣으면 매달 얼마씩 몇 달을 받는지, 총액이 얼마인지 계산해줍니다. 1편에서 말씀드린 그 도구, 저를 홈페이지까지 만들게 한 전환점이 된 물건이고요.
오후 3시 4분에 시작해서 6시 44분에 마지막 커밋을 찍었습니다. 3시간 40분이에요.
"AI한테 시키니까 3시간 만에 계산기가 나왔다"로 들리실 것 같은데요. 오늘은 그 3시간 40분 안을 열어보려고 합니다. 거짓말하는 계산기가 어쩌다 나왔고, 어떻게 잡았는지가 이 글의 내용이에요. 아마 생각하시는 것과 좀 다를 겁니다.
첫 명령은 "만들어줘"가 아니었어요
가장 흔한 오해가 여기 있는 것 같아요. AI한테 "육아휴직 계산기 만들어줘" 하면 뚝딱 나올 거라는 그림이요.
그렇게 시키면 뭔가 나오긴 합니다. 문제는 그게 맞는지 아무도 모른다는 거예요.
육아휴직 급여는 규칙이 꽤 복잡합니다. 1~3개월은 통상임금 100%에 상한 250만 원, 4~6개월은 100%에 상한 200만 원, 7개월부터는 80%에 상한 160만 원. 여기에 하한 70만 원이 걸리고, 방금 보신 6+6이 얹히고요.
이걸 모르는 상태에서 "만들어줘"라고 하면, 나온 화면이 그럴듯해 보여도 숫자가 맞는지 확인할 방법이 없습니다. 계산기의 유일한 가치가 숫자의 정확성인데, 그걸 확인 못 하면 만들 이유가 없는 거죠.
그래서 첫 명령은 코드가 아니라 설계 문서였어요. 오후 3시 4분 커밋이 그겁니다. 그리고 그 문서에서 제일 먼저 정한 건 뭘 만들지가 아니라 뭘 안 만들지였어요.

제외 목록을 보시면요.
- 출산전후휴가 급여, 육아기 근로시간 단축 급여 — 다른 제도예요. 섞으면 계산이 엉킵니다.
- 지자체 지원금 — 이게 제일 아까웠는데, 지역별로 제각각이라 한번 넣으면 계속 따라다니며 고쳐야 해요. 유지가 안 될 걸 알면서 넣을 수는 없더라고요.
- 사업주 지원금 — 받는 사람이 다릅니다.
- 사후지급금 — 2025년 1월부로 폐지됐어요. 없어진 걸 계산에 넣으면 안 되죠.
이 목록을 안 적으면 어떻게 되냐면요. 만들다가 "이것도 넣으면 좋겠는데" 하면서 계속 커집니다. 그러다 어느 순간 아무도 관리 못 하는 물건이 돼요. 범위를 자르는 건 AI가 대신 해주기 어려운 일입니다. 뭘 포기할지는 만드는 사람이 감당할 수 있는 크기를 알아야 정할 수 있거든요.
규칙을 정리하다 출처가 어긋난 걸 찾았어요
규칙을 표로 옮기는 작업은 AI가 잘합니다. 흩어진 안내를 모아 구간별로 정리하는 건 사람이 하면 지루하고 실수도 나는 일이고요.
그런데 정리하다가 출처끼리 어긋나는 항목이 하나 나왔습니다.

대상 자녀 연령 요건이 어떤 데는 만 8세(초등 2학년) 이하, 어떤 데는 만 12세(초등 6학년) 이하로 돼 있더라고요. 아마 육아기 근로시간 단축 기준과 헷갈린 것 같은데, 확신이 안 섰어요.
여기서 갈림길이 있었습니다. 그냥 하나 골라서 적을 수도 있었어요. 어차피 이 값은 계산에 안 들어가고 자격 안내 문구일 뿐이거든요. 골라 적어도 티가 안 납니다.
그런데 그러지 않기로 했어요. 화면에 이렇게 적었습니다.

맨 아래에서 두 번째 줄이에요. "대상 자녀 요건은 만 8세 이하 또는 초등학교 2학년 이하로 정리했으나 출처에 따라 다르게 안내되고 있습니다. 신청 전 고용24에서 확인해 주세요."
계산기가 "확실하지 않다"고 말하는 문장인데요. 이건 AI가 알아서 넣어주는 문장이 아닙니다. 모르는 걸 모른다고 화면에 적을지, 아니면 조용히 하나 골라 적을지는 만든 사람이 정하는 거예요. 저는 이 연재를 통틀어 이 판단이 제일 중요했다고 생각합니다.
그래서 HTML 한 장을 두 장으로 쪼갰어요
여기서부터가 아까 그 거짓말을 잡은 얘기로 이어집니다.
설계 문서에 적힌 산출물은 index.html 파일 한 장이었어요. 빌드 도구도, 프레임워크도 없이 HTML 한 장. 더블클릭하면 열리는 물건.
그런데 그렇게 만들면 계산이 맞는지 자동으로 확인할 방법이 없습니다. 계산 코드가 HTML 안에 파묻혀 있으면 브라우저를 열어서 눈으로 보는 것 말고는 검사할 길이 없거든요. 눈으로 보는 검사는 놓칩니다. 실제로 방금 그 6+6 버그가 눈으로 봐서는 안 보이는 종류였고요. 화면은 멀쩡했으니까요.
그래서 계산하는 부분만 따로 파일로 빼냈습니다. 지금은 이렇게 나뉘어 있어요.
| 파일 | 하는 일 |
|---|---|
engine.js | 제도 수치와 계산. 화면을 모릅니다 |
index.html | 입력 폼과 그리기. 계산을 안 합니다 |
tests/engine.test.js | 계산이 맞는지 검사 |
"계산하는 쪽은 화면을 모르고, 화면 쪽은 계산을 안 한다." 이렇게 갈라두면 계산만 따로 꺼내서 자동으로 검사할 수 있습니다. 파일은 둘이 됐지만 더블클릭으로 열리는 건 그대로고요.
그리고 계산 파일 맨 위에 제도 숫자를 한 상자에 몰아넣었습니다.

구간별 지급률과 상한, 하한 70만 원, 6+6 상한 여섯 개, 최대 개월 수까지 전부요. 계산하는 코드에는 금액을 직접 쓰지 않습니다. 그래야 제도가 개정됐을 때 이 상자만 고치면 되거든요. 육아휴직 급여는 몇 년에 한 번씩 바뀌는데, 그때마다 코드를 뒤져야 한다면 결국 방치될 게 뻔했어요.
테스트를 먼저 썼는데, 그중 하나가 이상했어요
코드를 짜기 전에 검사부터 썼습니다. "이 입력에는 이 답이 나와야 한다"를 먼저 적어두고, 그걸 통과하도록 짜는 방식이에요.
그중에 이런 게 있었습니다.

위쪽은 평범해요. 통상임금 80만 원인 사람의 7개월 차는 80%면 64만 원인데, 하한이 70만 원이니까 70만 원으로 올려준다.
문제는 아래쪽입니다. 통상임금이 60만 원인 사람은요?
하한이 70만 원이니까 70만 원을 줘야 할 것 같잖아요. 그런데 그러면 원래 받던 월급보다 육아휴직 급여를 더 받게 됩니다. 그럴 리가 없죠. 급여가 임금을 넘을 수는 없으니까요. 답은 60만 원입니다.
이 경계는 솔직히 저는 생각 못 했어요. 규칙 어디에도 "하한은 통상임금을 넘지 않는다"고 적혀 있지 않거든요. 규칙 두 개를 겹쳐놓고 끝까지 따라가야 나오는 값입니다. 여기는 AI가 잘한 지점이라고 정직하게 적어둘게요. 이런 경계값을 빠짐없이 훑는 건 사람보다 기계가 훨씬 잘합니다.
지금은 이런 검사가 47개 있고, 전부 통과합니다.

명령어 한 줄이면 0.08초 만에 47개가 다 돌아요. 제도가 개정돼서 숫자를 고칠 때, 어딘가 조용히 깨지지 않았는지 이걸로 확인합니다.
그 경계는 지금도 화면에서 이렇게 지켜지고 있어요. 통상임금 65만 원을 넣어본 화면입니다.

7개월 차부터 "하한 적용"이 붙는데 금액은 70만 원이 아니라 65만 원입니다. 오른쪽 근거 칸에 왜 그 금액인지가 같이 적혀 있고요. 금액만 던지지 않고 상한 때문인지 하한 때문인지를 같이 보여주자는 것도 설계 때 정한 것이었어요.
그리고 맨 앞의 그 거짓말을 잡았습니다
준비가 여기까지 되고 나서, 오후 3시 39분에 6+6 버그를 잡았어요.
원인은 간단했습니다. 코드가 "배우자 정보가 있는가"만 확인하고 있었어요. "배우자가 실제로 몇 개월을 쓰는가"는 안 봤습니다. 화면의 슬라이더 최솟값이 0이었기 때문에, 체크박스만 켜면 누구나 상한이 뛰었고요.
고치는 방법 자체도 간단했습니다. 배우자의 사용 개월 수 합이 0보다 커야 한다는 조건 하나 추가하면 돼요. 다만 순서를 지켰습니다. "배우자가 0개월이면 6+6이 아니다"라는 검사를 먼저 써서 실패하는 걸 확인한 다음 고쳤어요.
이게 별것 아닌 것 같은데 중요합니다. 고치고 나서 화면이 멀쩡해 보이는 건 원래도 멀쩡해 보였기 때문이거든요. 실패하는 검사를 먼저 만들어두지 않으면, 진짜로 고쳐진 건지 화면만 그대로인 건지 구분할 수가 없습니다.
화면이 나오고 나서야 보인 것들
계산이 끝나고 화면을 붙이자 새로운 종류의 문제가 나오기 시작했어요.
오후 4시 21분, "사람별 한도를 슬라이더에 실제로 걸었다" 커밋인데요. 육아휴직 한도는 사람마다 따로 붙습니다. 그런데 배우자 슬라이더가 최대 18개월 고정이라 한도에 걸리질 않았어요. 배우자가 이미 10개월을 썼는데 이번에 18개월을 또 쓰는, 합계 28개월짜리 계산이 그대로 나왔습니다.
고친 화면이 이거예요.

본인은 "최대 10개월 (한도 18 − 기사용 8)", 배우자는 "최대 8개월 (한도 18 − 기사용 10)". 슬라이더가 왜 거기서 멈추는지를 옆에 적어뒀습니다. 그냥 안 움직이면 고장 난 줄 알거든요.
이 화면에 사실 하나가 더 들어 있어요. 아래 표를 보시면 9개월 차부터 시작합니다. 이미 8개월을 쓴 사람이 다시 신청하면 1개월 차부터가 아니라 9개월 차부터거든요. 250만 원 구간을 다시 받지 않습니다. 이걸 반영 안 하면 나눠 쓰는 사람에게 매달 250만 원을 준다고 뻥튀기해서 알려주게 돼요. 설계 시작 4분 만인 3시 8분에 이 항목이 들어간 이유입니다.
전체 점검에서 7건이 나왔어요
오후 4시 26분, 커밋 제목이 그냥 "전체 점검에서 나온 오류 7건 수정"입니다. 화면이 다 만들어진 뒤 처음부터 끝까지 한 번 훑은 결과예요.
1. 음수 통상임금이 음수 급여를 만들었습니다. −540만 원 같은 게 나왔어요. 입력 칸에 "0 이상"이라고 지정해둬도 직접 타이핑하는 건 못 막습니다. 읽는 쪽에서 잘라야 했어요. 2. 연도를 잘못 친 미래 생일이 "생후 0개월"로 처리돼서 6+6이 조용히 붙었습니다. 3. 한부모와 "배우자도 사용"을 동시에 켤 수 있었어요. 둘 다 켜면 한부모 상한 300만 원이 6+6 첫 달 상한 250만 원에 덮여서 오히려 낮아집니다. 서로 못 켜게 묶었어요. 4. 판정이 불가능한 상태를 표시하려고 넣어둔 값 999가 화면에 "생후 999개월"로 샜습니다. 5. 입력 칸과 설명 글자가 연결이 안 돼 있었어요. 13개 중 2개만 연결돼 있었습니다. 글자를 눌러도 칸으로 안 가고, 화면 읽어주는 프로그램이 못 읽습니다. 6. 그래프 라벨 칸이 고정 폭이라 "다섯째 배우자" 같은 긴 이름이 막대 위로 넘쳤어요. 7. 안 쓰는 죽은 코드 제거.
여기서 하나 짚고 싶은 게 있어요. 7건 중에 계산이 틀린 건 하나도 없습니다. 47개 검사가 전부 통과하는 상태였어요. 전부 사람이 예상 못 한 값을 넣거나, 예상 못 한 순서로 누르거나, 눈이 아닌 다른 방법으로 읽을 때 나온 문제였습니다.
검사는 "내가 생각한 경우"만 검사합니다. 생각 못 한 경우는 화면을 열어서 이상하게 굴어봐야 나와요.
"잘못 입력했다"고 말하는 화면
바로 4분 뒤인 4시 30분에 재미있는 커밋이 하나 있습니다.
미래 날짜 생일 자체는 원래 허용돼 있었어요. 아직 안 태어난 아이의 출산 예정일을 넣고 미리 계산해보는 게 이 도구의 주된 쓰임새거든요. 배우자 계획이 확정되기 전에 이리저리 따져보는 것도요.
그런데 예정일을 넣는 순간 빨간 오류부터 떴습니다. 휴직 시작일이 아직 오늘로 돼 있어서 "생일보다 시작일이 이르다"에 걸린 거예요. 계획을 세워보려고 들어온 사람에게 "당신 잘못 입력했습니다"라고 말하는 화면이었던 거죠.
그래서 빨간 오류를 주황 안내로 낮추고, "시작일을 이 날짜로 맞추기" 버튼을 옆에 붙였습니다. 다만 값을 마음대로 바꾸지는 않습니다. 날짜를 입력하는 도중에 값이 혼자 튀면 더 혼란스러우니까요. 누르면 바뀌고, 안 누르면 안 바뀝니다.
기술적으로는 아무것도 안 틀린 화면이었어요. 틀린 건 말투였습니다. 이런 건 코드를 봐서는 안 보이고, 자기가 쓸 상황을 떠올려야 보입니다.
그리고 오늘, 이 글을 쓰다가 하나 더 찾았어요
여기서부터는 그날 일이 아니라 오늘 일입니다.
이 글에 넣을 화면을 찍으려고 출산 예정일을 넣어봤는데, 이런 게 나왔어요.

맨 위 줄을 보세요. "첫째 — 2026.11.10생 · 생후 Infinity개월"
아까 7건 점검의 4번 기억하시나요? "999가 생후 999개월로 화면에 샜다"는 항목이요. 그때 999를 Infinity(무한대)로 바꿔서 막았거든요. 그런데 새는 값만 999에서 Infinity로 바뀌어 있었습니다.
경고 배지 쪽은 멀쩡했어요. 거기엔 "아직 태어나기 전이면 이 문구를 쓰지 마라"는 조건이 걸려 있었거든요. 그 조건이 카드 제목 한 줄에만 빠져 있었습니다. 계산은 정확히 맞고 표시만 깨지는, 눈에 잘 안 띄는 종류의 구멍이었어요.
고쳤습니다. 지금은 이렇게 나옵니다.

"첫째 — 2026.11.10 출산 예정". 오늘 아침 배포에 같이 나갔습니다.
이게 오늘 이 글에서 제일 하고 싶은 얘기예요. 점검은 자기가 아는 만큼만 훑습니다. 7건을 잡아낸 그 점검조차, 같은 종류의 구멍이 한 칸 옆에 남아 있는 걸 못 봤어요. 사흘 뒤에 글을 쓰려고 화면을 다시 열어본 사람이 그걸 봤습니다.
3시간 40분의 내역
그날 하루치 커밋을 시간순으로 늘어놓으면 이렇습니다.

서른 개예요. 하나씩 보시면 성격이 눈에 들어옵니다.
- 15:04 ~ 15:24 (20분) — 설계와 계획. 코드 한 줄 없습니다. 이 사이에 "이미 쓴 이력을 입력받자"로 설계가 바뀌고, 계획이 12개 항목에서 8개로 줄고, 계획 자체를 두 번 정정했어요. 하나는 빈 껍데기만 남게 돼 있던 걸 고친 것이고, 하나는 검사 실행 명령이 이 컴퓨터에서 안 먹는 걸 미리 바꾼 겁니다. 코드를 짜기 전에 계획을 고치는 게 제일 쌉니다.
- 15:23 ~ 15:52 (30분) — 계산 부분. 여기가 실제로 코드를 짠 구간이에요. 30분입니다. 맨 앞의 6+6 거짓말도 이 안에서 나왔다 잡혔고요.
- 16:00 ~ 16:30 (30분) — 화면을 붙이고 나서 나온 것들. 자녀 여러 명, 모바일, 사람별 한도, 7건 점검, 출산 예정일.
- 16:32 ~ 17:04 — 검색 등록, 문의 창구, 엑셀 내보내기 같은 마감.
- 18:35 ~ 18:44 — 저녁에 다시 앉아서 그래프. 17시와 18시 반 사이가 비어 있죠. 밥 먹었습니다.
계산기를 만드는 데 실제로 코드를 짠 시간은 30분입니다. 나머지 3시간은 뭘 만들지 정하고, 계획을 고치고, 나온 걸 두들겨보고, 말투를 다듬은 시간이에요.
16시 52분 커밋 하나만 더 말씀드릴게요. "문의를 mailto 대신 신고 위젯으로 교체"인데, 우상단 메일 버튼을 눌러도 아무 일이 없다는 제보를 받고 고친 겁니다. 메일 앱이 설정 안 된 컴퓨터에서는 그 버튼이 그냥 죽어 있어요. 제 컴퓨터에서는 잘 됐고요. 이건 검사로도, 점검으로도 안 나옵니다. 다른 사람이 눌러봐야 나와요.
그래서 사람은 어디에 있었나
이 연재의 숨은 질문이 그거였죠. 오늘 편의 답을 정리해볼게요.
AI가 확실히 잘한 것들이 있습니다. 흩어진 제도 안내를 구간표로 정리한 것, 하한과 통상임금이 부딪히는 경계를 끝까지 따라가 찾아낸 것, 검사를 먼저 쓰고 실패를 확인한 뒤 고치는 순서를 지킨 것, 화면 전체를 한 번에 훑어 7건을 뽑아낸 것. 사람이 하면 지치고 빠뜨리는 일들이에요. 정직하게 인정하는 게 맞습니다.
사람이 붙잡아야 했던 자리는 이런 곳이었어요.
- 지자체 지원금을 빼기로 한 것 — 유지 못 할 걸 아는 건 만드는 사람입니다
- 출처가 어긋난 항목을 "확인 필요"라고 화면에 적기로 한 것
- 설계 문서에 적힌 "HTML 한 장"을 뒤집어 검사가 가능한 구조로 바꾼 것
- 아직 안 태어난 아이의 예정일을 넣는 게 오류가 아니라 정상 사용이라고 정한 것
- 메일 버튼이 안 눌린다는 제보
- 그리고 오늘, 사흘 뒤에 화면을 다시 열어본 사람이 찾은 Infinity
공통점이 보이시나요. 전부 "무엇을 만들 것인가"와 "이건 아직 모른다"에 관한 것들이에요. 코드를 어떻게 짜느냐는 한 줄도 없습니다.
AI는 자기가 만든 걸 자기가 점검할 수 있습니다. 꽤 잘해요. 다만 점검의 기준은 자기가 아는 만큼입니다. 999를 막으라고 하면 999를 막고, 그 옆에 남은 Infinity는 안 봐요. 무엇을 기준으로 삼을지, 어디까지가 이 물건의 몫인지를 정하는 자리 — 지금으로선 거기가 사람 자리 같습니다.
맨 앞의 그 거짓말도 그래서 잡힌 거예요. 화면은 멀쩡했고 아무도 항의하지 않았습니다. "체크박스만 켜면 진짜 저 돈을 받나?"라고 한 번 의심한 사람이 있었을 뿐이에요.
다음 편에
이렇게 만든 계산기를 이제 인터넷에 올려야 하는데요. 서버를 빌리면 매달 돈이 나갑니다. 그런데 저는 1편에서 1년에 만 오천 원이라고 말씀드렸어요. 도메인 값이고, 서버비는 0원입니다.
다음 편은 서버 없이 어디까지 되나 — 정적 사이트라는 선택입니다. 왜 서버가 없어도 되는지, 없어서 못 하는 건 뭔지, 그리고 그 선택이 나중에 뭘 막고 뭘 허락했는지를 적을게요.
읽다가 궁금한 게 있으면 댓글로 남겨주세요. 로그인 없이 쓸 수 있습니다.
계산기는 여기 있습니다 — victor-house.com/leave
#육아휴직 #육아휴직급여 #육아휴직계산기 #66부모육아휴직제 #통상임금 #고용노동부 #고용24 #AI코딩 #클로드 #ClaudeCode #바이브코딩 #1인개발 #개인개발 #웹개발 #자바스크립트 #HTML #정적사이트 #테스트코드 #TDD #node #깃 #커밋로그 #코드리뷰 #버그수정 #휴먼인더루프 #AI활용법 #AI와사이트만들기 #개발일지 #사이드프로젝트 #빅터하우스