이 글은 기능 구현에 대한 기록이 아니다.
Step 5에서 급여 계산기 개발이 완료된 뒤, 실제로 검증을 시작하면서 무엇이 부족했고 왜 사람이 다시 개입해야 했는지를 정리한 기록이다.
기능적으로는 잘 동작했다. 하지만 막상 화면을 직접 보고 써보니, 계산이 된다는 것과 실제로 서비스처럼 보인다는 것은 전혀 다른 문제라는 점이 바로 드러났다.
이 글은 무엇을 만들었는지보다 이제 이 결과물을 그대로 써도 되는 상태인지에 대한 판단을 다룬다.

1. 들어가며: 계산은 되었지만, 아직 제품은 아니었다
급여 계산기 개발은 완료되었다.
기능적으로는 정상 동작했다.
입력값을 넣으면 결과가 계산되었고,
기본적인 흐름도 문제없이 이어졌다.
그런데 이 시점에서 바로 느껴진 것이 있었다.
계산이 된다는 것만으로는 충분하지 않다는 점이었다.
무엇을 만들었느냐보다, 이 화면이 정말 사용 가능한 수준인지를 봐야 하는 단계로 넘어온 것이다.
2. 디자인: 왜 기본 디자인부터 다시 잡아야 했는가
처음 완성된 급여 계산기는 기능 자체는 잘 작동했다.
하지만 디자인적으로는 너무 허접한 모습이었다.
딱 “계산은 되는 화면” 정도였고,
실제로 서비스에 넣는 화면처럼 보이기에는 많이 부족했다.
그래서 이 단계에서는 기능을 더 붙이기 전에,
디자인의 기본 틀은 먼저 잡고 가야겠다고 판단했다.
이건 단순히 예쁘게 만드는 문제라기보다,
사용자가 입력하고 결과를 확인하는 흐름 자체를
조금 더 정돈된 형태로 바꾸는 일이었다.
그래서 Gemini에게 요청해서 기본 디자인 구조를 먼저 정리했다.
3. 검증: 기능은 되었지만, 부족한 점은 바로 드러났다
기능 테스트를 해보면서 몇 가지 부족한 부분도 바로 확인할 수 있었다.
이 단계에서 중요한 것은 계산 로직이 맞는가만 보는 것이 아니었다.
사용자가 실제로 입력할 때 어떤 불편이 생기는지를 같이 보는 일이었다.
1) 숫자인데 콤마 표시가 없었다
급여 계산기처럼 금액을 다루는 화면에서는
숫자가 한눈에 읽혀야 한다.
하지만 이 부분이 빠져 있어서 가독성이 많이 떨어졌다.
2) 날짜 입력이 일반 input 형태였다
달력이 붙어 있는 형태가 아니라
그냥 input 형태로 되어 있어서 입력 경험이 자연스럽지 않았다.
3) 오늘 이후 날짜도 그대로 입력되었다
오늘 날짜까지만 입력되어야 하는데
이후 날짜도 그대로 입력이 가능했다.
급여 계산기의 성격상 미래 날짜까지 허용되는 것은 맞지 않았다.
4) 같은 날짜가 계속 입력되었다
같은 날짜가 중복으로 들어가는 것도 확인되었다.
이 부분 역시 validation이 충분히 잡혀 있지 않다는 뜻이었다.
5) 결과 분석 리포트는 너무 최소 상태였다
결과값 자체는 잘 나왔다.
하지만 결과 분석 리포트는 내용이 최소화되어 있어서,
사용자가 결과를 이해하기에는 설명이 부족한 상태였다.
4. 수정: 왜 Codex에게 다시 요청했는가
이 문제들은 새로운 기능을 추가하는 문제라기보다는
완성도를 높이기 위한 세부 보정 작업에 가까웠다.
그래서 이 단계에서는 Codex에게 다시 요청해서
부족한 부분들을 하나씩 보완했다.
숫자는 금액답게 보이도록 콤마를 적용하고,
날짜는 단순 input이 아니라 달력 기반으로 정리하고,
오늘 이후 날짜는 제한하고,
같은 날짜 중복 입력은 막고,
결과 리포트도 조금 더 의미 있게 보이도록 요청했다.
결과적으로는 이 부분도 잘 나온 것 같다.
대부분 validation 부분을 좀 더 상세하게 교정하는 방향으로 수정이 이루어졌고,
사용자가 실제로 입력할 때 생길 수 있는 예외 상황도 더 잘 반영되었다.
5. 정리: 이제는 속도보다 검증의 비중이 커졌다
이번 Step 5를 진행하면서 다시 느낀 것은,
AI가 기능을 빠르게 만드는 데에는 분명 강하다는 점이다.
하지만 기능이 만들어졌다고 해서
곧바로 서비스에 넣을 수 있는 수준이 되는 것은 아니었다.
특히 계산기처럼 단순해 보이는 화면도
실제로는 숫자 표시 방식, 날짜 제한, 중복 방지, 결과 설명 같은
세부 기준들이 꽤 많이 필요했다.
결국 중요한 것은 단순했다.
“계산이 되는가”가 아니라 “사용자가 이 화면을 신뢰할 수 있는가”였다.
이번 단계는 바로 그 차이를 체감한 시점이었다.
AI가 빠르게 뼈대를 만들 수는 있어도,
제품다운 완성도는 결국 사람이 얼마나 세세하게 검증하고 보완하느냐에 달려 있었다.
💬 후기
이번 Step 5를 진행하면서 가장 크게 느낀 것은,
기능이 완성됐다는 사실만으로는 안심할 수 없다는 점이었다.
처음에는 계산이 잘 된다는 것만으로도 충분해 보였다.
그런데 실제로 검증을 시작하자,
오히려 더 많은 기준과 예외가 보이기 시작했다.
이제부터는 속도보다,
어떤 조건을 막아야 하고 어떤 방식으로 보여줘야 하는지 판단하는 일이
더 중요해질 것 같다.
다음 글에서는
다음 글에서는 이런 보정 작업이 실제 완성도에 어떤 차이를 만드는지,
그리고 사람이 어디까지 개입해야 하는지가 더 분명해진 지점을 다룰 예정이다.
기능을 만드는 단계에서 끝나는 것이 아니라,
그 결과를 실제로 쓸 수 있는 상태로 바꾸는 과정이 어떻게 달라지는지 이어서 정리해보려고 한다.
'AI 개발 기록' 카테고리의 다른 글
| [Taxi Driver App] 네이버맵 API로 화장실 지도 기능 만들기 - Part. 6 (0) | 2026.06.28 |
|---|---|
| [Taxi Driver App] 작은 보정이 앱의 완성도를 바꾸는 지점 - Part 5.5 (0) | 2026.06.27 |
| [Taxi Driver App] Step 2~4를 연속 수행하며 앱이 형태를 갖추기 시작한 순간 – Part 4 (1) | 2026.01.28 |
| [Taxi Driver App] AI가 제안한 Step 1을 그대로 따라가 보니, 프로젝트를 시작할 수 있는 상태가 만들어졌다 - PART 3 (0) | 2026.01.24 |
| [Taxi Driver App] 코딩은 AI가, 설계는 내가 한다 – Part 2 (0) | 2026.01.23 |