AI로 일하기

숫자만 고쳤는데, 화면은 아직 괜찮다고 말하고 있었습니다 🩹

생각에 잠긴 초록이 아빠

아침에 커피를 내리면서 리포트 넷을 훑어보는 게 요즘 제 루틴입니다. 돈독(제가 혼자 만드는 가족 자산관리 앱, https://don-doc.com )을 개발·기획·디자인·마케팅 네 역할로 나눠서 AI 에이전트가 매일 점검하거든요. 이번엔 버그를 찾은 것보다, 그 버그를 어떻게 고칠지를 놓고 셋이 부딪히다 뒤집힌 과정이 더 눈에 띄었습니다.

만기가 지난 대출인데, 왜 상환액이 잔액 전액에 가까웠을까

대출 현황 화면(DebtTab)에는 매달 얼마씩 갚아야 하는지 추정치를 보여주는 계산 함수가 있습니다. 이 함수가 남은 개월 수를 구할 때, 만기일이 이미 지난 대출이면 개월 수를 억지로 1로 맞춰버리는 코드가 들어 있었습니다. 원리금균등 상환 공식은 이 남은 개월 수로 나눠서 월 상환액을 구하니까, 개월 수가 1이 되는 순간 계산 결과는 잔액 거의 전액이 됩니다. 실제로 확인해보니 잔액 2.8억 원짜리 대출이 화면에는 월 상환액 2.8억 원으로 그대로 찍혔습니다.

문제는 여기서 끝나지 않았습니다. 만기일 배지도 따로 봐야 했습니다. 이 배지는 “1년 이내”라는 노란 경고 하나뿐이라, 만기가 석 달 남은 대출과 이미 두 달 지나버린 대출을 구분하지 못했습니다. 둘 다 똑같이 순한 주의 색으로 표시됩니다.

삽질하다 멘붕한 초록이 아빠

빨리 갈까, 같이 갈까

버그를 코드로 확정한 개발 담당은 “로직만 먼저 단독으로 배포하고, 화면 쪽은 나중에 손보자”고 제안했습니다. 계산식만 고쳐도 부풀려진 숫자는 바로 없어지니 빠른 길이었습니다.

디자인·기획 담당의 생각은 달랐습니다. 로직만 고쳐서 배포하면, 화면에는 여전히 “1년 이내”라는 똑같은 노란 배지가 뜨고 상환액 숫자도 여느 때와 같은 작은 회색 글씨로 나타납니다. 숫자는 정확해졌어도, 정작 이 대출이 만기를 넘겨 재계약이 급한 상태라는 신호는 화면 어디에도 없는 겁니다.

로직만 고치면, 화면은 여전히 “괜찮다”고 말하고 있었습니다.

한 커밋에 로직과 화면을 함께

기획 담당이 중재해서 결론을 냈습니다. 계산 로직과 화면 표시를 같은 커밋에 묶어서 배포하기로요. 실제로 고친 내용은 두 가지입니다. 남은 개월 수가 0 이하로 떨어지면 억지로 1을 채우는 대신 이자만 계산하는 방식으로 갈아타게 했고, 만기 배지는 지나버린 경우 “1년 이내”가 아니라 “만기 지남”이라는 강한 경고색 배지로 바꾸면서, 추정 상환액 숫자 대신 “만기가 지났어요 — 재계약 여부를 확인해 주세요”라는 안내 문구로 대체했습니다. 숫자를 믿을 수 없는 상황에서는 숫자를 보여주는 대신 정확한 안내를 보여주자는 판단이었습니다.

작업은 별도 브랜치에서 커밋 하나로 끝냈고, main에는 아직 병합하지 않았습니다. 이번 주 다른 승인 대기 작업들과 함께 묶어서 사람 승인을 받을 예정입니다.


따라 하기

버그 하나를 고칠 때 “로직만 먼저 빠르게”라는 유혹이 든다면, 이번에 실제로 거친 검증 절차를 그대로 옮겨 쓸 수 있습니다.

1. 작업은 별도 브랜치에서

git checkout -b <브랜치명>
  • main을 바로 건드리지 않고 따로 파두면, 검증이 끝나기 전까지는 실수해도 되돌리기 쉽습니다.

2. 타입 오류부터 잡기

tsc --noEmit
  • 코드를 실행하지 않고도 타입이 안 맞는 부분을 먼저 걸러냅니다. 계산 함수처럼 숫자를 다루는 코드일수록 여기서 걸리는 게 나중에 화면에서 걸리는 것보다 훨씬 쌉니다.

3. 기존 테스트 전체 돌리기

vitest run
  • 이번 수정과 상관없어 보이는 다른 계산 로직까지 전부 다시 돌려서, 남은 개월 수를 고친 게 다른 곳에서 엉뚱한 값을 만들지 않는지 확인합니다.

4. 스타일·톤 가드 스크립트 돌리기

eslint .
node check-tone.mjs
node check-css-tokens.mjs
  • 앞의 둘은 흔한 린트·타입 검증이고, 뒤의 둘은 제가 직접 만들어둔 가드입니다. “AI 판단 전용 색을 규칙 기반 로직에 쓰지 않았는지”, “카피 톤이 기존 문구 규칙과 어긋나지 않는지”를 스크립트로 자동 확인합니다. 사람이 매번 눈으로 보기엔 놓치기 쉬운 것들이라 규칙을 코드로 박아뒀습니다.

5. 커밋은 하되, 병합은 별도 승인으로

git commit -m "<커밋 메시지>"
  • 검증을 전부 통과해도 곧바로 main에 올리지 않습니다. “코드가 맞다”와 “지금 배포해도 된다”는 다른 질문이라, 병합·푸시는 사람이 따로 승인하는 단계로 남겨둡니다.

배운 것

화이팅하는 초록이 아빠

이번에 제가 챙기게 된 질문은 하나입니다. “로직이 맞았나”가 아니라 “이 수정 후에도 화면에 남는 신호가 사용자를 안심시키는 쪽인가”를 먼저 묻는 겁니다. 계산식 하나만 슬쩍 고치고 넘어갔다면 숫자는 정확해졌겠지만, 화면은 여전히 “괜찮다”고 말하고 있었을 겁니다. 버그를 고치는 속도보다, 고친 뒤에도 화면이 거짓말을 하지 않는지가 먼저였습니다.

오늘도 한 걸음. 🐴

이 글은 산업 구조와 만드는 과정을 정리한 개인 기록입니다.
특정 종목의 매수·매도 추천이 아니며, 투자 판단과 그 결과는 독자 본인에게 있습니다.

← 글 목록으로