← 작업일지

2026-07-31 · v1.0.0

2026.07.31 작업일지 v1.0.0

22:57, 상담봇에 “결제가 안되요” 라고 쳐 봤다. 봇은 주문번호를 물었다. 결제에 실패한 사람에게는 줄 주문번호가 없다. 23:14, 결제창이 “테스트 결제라 실제로 청구되지 않는다”고 적어둔 채 진짜로 돈을 받고 있었다는 걸 고쳤다. 23:25, 첫 손님의 결제가 승인됐다. 19,900원.

작명 서비스를 실서비스로 전환한 날이다. 자동화 저장소에는 29건이 들어갔지만, 이날의 이야기는 커밋 숫자가 아니라 처음으로 남의 돈이 들어온 몇 시간에 있다.

1. 결제창이 거짓말을 하고 있었다

결제 페이지에는 결제 수단을 연결하는 열쇠가 하나 박힌다. 테스트용과 실제용이 따로 있고, 페이지 문구도 그에 맞춰 “테스트라 청구되지 않습니다” 또는 “실제로 청구됩니다”로 바뀐다.

라이브를 열고 확인해 보니 실서비스에 테스트용 열쇠가 올라가 있었다. 실제 카드 승인이 하나도 나지 않는 상태였다. 그리고 더 나쁜 건 그 반대 방향이었다 — 열쇠를 실제용으로 바꾼 뒤에도 페이지 문구가 그대로 남아, “청구되지 않습니다”라고 적힌 화면에서 진짜로 청구되는 구간이 생겼다.

05f3130  23:14  fix(checkout): 라이브 결제창의 거짓 고지 제거
                — 실제로 청구된다

돈을 받는 화면이 사실과 다른 말을 하는 건 기능 결함이 아니라 고지 문제다. 문구를 열쇠 종류에서 자동으로 끌어오도록 바꾸고, 배포 전에 산출물을 검사하는 관문을 붙였다.

배운 것 — 사용자에게 돈에 관해 말하는 문구는 사람이 손으로 맞추는 자리에 두면 안 된다. 실제 설정에서 파생되게 만들어야 어긋날 수가 없다.

2. 첫 결제, 그리고 영수증 첫 줄의 하이픈

23시 25분, 첫 결제가 승인됐다. 그런데 2분 뒤 영수증을 열어 본 나는 이렇게 시작하는 문장을 봤다.

-님, 결제가 완료되었어요

이름 자리에 하이픈이 찍혀 있었다. 결제를 요청할 때 이메일은 넘기는데 구매자 이름을 안 넘기고 있었다. 결제사는 이름이 없으면 하이픈으로 그린다.

단순히 값 하나 추가하면 끝나는 문제가 아니었다. 결제 폼에서 애초에 구매자 이름을 안 받고 있었기 때문이다. 폼에 칸을 하나 더 넣을지(정확하지만 결제 직전에 마찰이 늘어난다), 신청서에서 이미 받는 정보를 쓸지(마찰은 없지만 구매자 본인 이름은 아니다) — 제품 결정이 먼저 필요한 자리라 결정 대기로 남겼다.

기능은 멀쩡히 돌아갔다. 다만 영수증은 손님이 가장 오래 보관하는 물건이고, 유료 서비스의 첫인상이다.

3. 결제에 실패한 사람은 줄 주문번호가 없다

라이브 전환 직전, 카톡 상담봇에 “결제가 안되요”라고 쳐 봤다. 봇은 이렇게 답했다.

어떤 주문 관련 문의신가요? 결제 시 입력하신 이메일이나 주문번호를 알려주시면 바로 확인해 드릴게요.

“결제가 안된다고요!”라고 다시 쳤다. 똑같은 문장이 돌아왔다.

결제 실패라는 상황을 알아듣는 분기가 아예 없어서 두 발화가 같은 기본 응답으로 떨어진 것이다. 그런데 진짜 문제는 반복이 아니다. 결제에 실패한 사람은 주문 자체가 성립하지 않아서 줄 주문번호가 없다. 기본 응답이 이 상황에서 구조적으로 막다른 길이었다.

배운 것 — 폴백 문구를 쓸 때는 “이 문구를 받을 사람이 요구받은 걸 갖고 있는가”를 물어야 한다. 실패한 사람에게 성공했을 때만 생기는 정보를 요구하면, 그건 안내가 아니라 벽이다.

4. 24분짜리 검사를 이미 닫힌 문에 붙이고 있었다

내부 쪽에서는 검증 설비를 하루 종일 손봤다. 가장 인상적인 건 이것이다 — 검사기가 이미 닫힌 PR에 24분짜리 전체 검사를 돌리고 결과를 정상적으로 게시하고 있었다. 대상이 아직 살아 있는지를 아무도 안 물어봤기 때문이다.

시각커밋무엇을 고쳤나
00:580e71bf11상속받은 실패를 이 작업의 결함으로 세던 것 — 공통 조상과 1회 대조
13:45b4242934한 컴퓨터에서 전체 검사가 두 판 겹쳐 돌던 것 — 상호 배제 잠금
15:119508ee57대상 PR 생사 확인 — 닫힌 문에 검사 결과를 붙이지 않는다

여기에 맥 계열 컴퓨터 세 대에서만 나던 구조적 실패 두 종도 정리했다. 테스트를 지우거나 건너뛰는 방식이 아니라, 실행기를 이식해 커버리지를 하나도 안 잃고 초록으로 만들었다.

5. 그래서 뭐가 남았나

  • 자동화 저장소 29건 착지, 검증 설비 수리 6건
  • 작명 서비스 실서비스 전환 — 첫 실매출 19,900원
  • 그 자리에서 바로 드러난 숙제 셋: 영수증의 이름 자리, 상담봇의 결제 실패 분기, 결제 열쇠 이름과 내용의 불일치
  • 결제 문구를 설정에서 파생시키고, 배포 전 산출물 검사 관문 신설

첫 매출이 난 날 남은 기록이 축하가 아니라 결함 목록 세 개라는 게 이 일의 성격을 잘 보여준다. 물건이 실제로 팔리기 시작하는 순간, 그때까지 아무도 안 밟던 경로에 전부 사람이 들어온다.


다음 이야기는 「배포 성공」이라고 찍힌 초록불이 실은 아무 데도 안 올라간 배포였다는 이야기.

— 강대종 / @ssamssae