이 글은 JudyAI Lab의 AI 엔지니어링 시리즈 중 하나입니다 — 100편 이상 발행된 가이드, 60개국 5,000명 이상의 주간 독자가 읽는 콘텐츠로, AI 에이전트·트레이딩 시스템·콘텐츠 파이프라인의 실전 운영에 초점을 둡니다.
해커톤 제출 다음날이 되어서야 전체 시스템이 어떤 모습인지 돌아볼 여유가 생겼다.
정리하다 보니 꽤 의외의 사실을 발견했다.
이 7일 동안 ‘아키텍처를 고민하는 시간’이 코드를 짜는 시간의 두 배였다.
| |
Day 9-12 꼬박 4일 동안 이런 일들을 했다:
- 엄마에게 기장사에서 맡은 채권 추심 케이스를 들었다
- 이모에게 CPA 고객들이 가장 힘들어하는 미수금 막힘 상황을 들었다
- 변호사 비용 조사 — $3K-$40K 미수금 구간을 아무도 서비스하지 않는 이유
- D-001부터 D-022까지 설계 결정 정리
- drawio v1·v2·v3를 반복하며 계속 수정
Day 13에 코드를 짜기 시작할 때는 이미 전체 시스템의 척추가 세워져 있었다.
코드 작성이 오히려 가장 고민 없이 진행된 부분이었다 — 앞선 4일 동안 ‘하지 말아야 할 것’을 충분히 정리해 두었기 때문이다.
이 글은 그 설계 진화 전체를 담는다. 왜 이 선택을 했는지, 중간에 어떤 문제가 생겼는지, 어떻게 수정했는지, 무엇이 추가됐는지.
출발점 — “소기업 사장이 친구에게 추천할 AI 채권 추심 시스템을 만들 수 있을까”
시작 전에 먼저 질문 하나를 던졌다.
“소기업 사장이 친구에게 직접 추천할 AI 채권 추심 시스템을 만들 수 있을까?”
“멀티에이전트 데모를 만들 수 있을까"도 아니고, “9개 스폰서를 다 연결할 수 있을까"도 아니고, “7일 안에 제출 가능한 것을 만들 수 있을까"도 아니었다.
소기업 사장이 친구에게 직접 추천할 만한 것을 만들 수 있는가.
이 질문은 꽤 도발적이다. AI 채권 추심 업계는 소기업 사장들에게 보통 평판을 망치는 것으로 인식된다. “AI 봇으로 고객을 귀찮게 했다"는 걸 추천하는 사람은 없다.
하지만 가능할 수도 있다고 봤다 — 이 AI가 몇 가지 핵심 순간에 진짜로 경계를 존중하고, 지뢰를 밟지 않고, 사장 혼자서는 풀 수 없는 고통을 실제로 해결해 준다면.
이 질문의 설계 영향은 두 층위에서 나타났다:
첫 번째 층위: 전체 시스템의 설계 중심이 “무엇을 할 수 있나"에서 “무엇을 하면 안 되나“로 바뀌었다.
어떤 케이스는 받지 말아야 하는지 (D-031 라이트 모드 < $3K는 추심 포기), 어떤 말을 하면 안 되는지 (D-019 LLM은 은행 계좌번호 작성 금지), 어떤 상황에서는 계속하면 안 되는지 (D-035 988 심리 위기 신호 앞에서 멈추기), 어떤 시간대에 전화하면 안 되는지 (미국 연방 공휴일 + TCPA 법규 통화 가능 시간대).
모든 항목이 “명확한 거절"이다.
두 번째 층위: 전체 시스템의 성공 지표가 “돈을 회수한 건수"가 아니라 “고객 관계 유지 + 사장이 친구에게 추천할 수 있는가"로 바뀌었다.
이 두 지표는 때로 충돌한다.
돈을 받았지만 고객이 AI에게 괴롭힘당했다고 느끼면 — 실패. 돈을 못 받았지만 고객이 “전문적으로 대화해 줬다"고 말하면 — 성공.
어느 쪽이 더 중요한지 알면 프롬프트 전체가 완전히 달라진다.
왜 ‘합계 금액’ 대신 ‘미수금’을 선택했나 (D-038)
이모는 재무 전문가다. 이모가 해 준 말 하나가 전체 설계를 다시 하게 만들었다.
이모 말로는 — 대부분의 국경 간 채권 추심 분쟁에서 금액이 생각보다 크지 않은 경우가 많다고 했다.
“계약금 50%는 이미 냈잖아요”, “나머지는 물건 받고 3개월 뒤에 드릴게요”, “중간에 계약이 변경됐는데 변경 부속 합의서 확인해보실 건가요” — 이런 말들을 고객이 한다.
계약 총액으로 보면 — $47K짜리 인보이스 하나. 실제 미수금으로 보면 — $23K일 수 있다.
미국 변호사는 케이스를 열어보고 $47K를 보면 “너무 작아서 못 받는다, 국경 간 소송 비용이 $30K 넘는다, 계산이 안 맞는다"고 말한다.
하지만 실제 우리가 추심하는 건 $23K — 우리의 스위트 스팟 ($3K-$40K)에 완전히 들어온다.
그 순간 깨달았다 — 업계 전체가 잘못된 숫자로 스위트 스팟을 정의하고 있다.
이것을 D-038로 정리했다 — 우리는 미수금을 추심하지, 계약 총액을 추심하지 않는다.
이 핵심 결정은 5개 에이전트를 관통한다:
| |
각 분기 경계에는 자동 검사가 고정되어 있어, 누군가 실수로 ‘계약 총액’을 넣지 못하게 막는다.
계약 총액 → 미수금, 단 한 글자 차이지만, 이게 바로 이 시스템이 중간 시장에서 살아남을 수 있는 핵심이다.
재무 담당자가 편하게 잔금을 추심할 수 있도록 만든 전문 도구다!
왜 9개 에이전트를 세 레이어로 나눴나, ‘만능 에이전트’ 하나로 안 하고
많은 멀티에이전트 시스템이 선택하는 방법은 — 엄청나게 긴 프롬프트를 ‘만능 에이전트’ 하나에 밀어 넣고 실수 없기를 기도하는 것이다.
우리는 반대 방향을 선택했다. AI를 접한 이후로 변함없이 갖고 있는 생각이기도 하다 — 한 가지 일만 전담하는 AI가 오류율이 더 낮다.
실행자(Doers)는 평범해도 된다. 수호자(Guardians)는 철벽이어야 한다.
왜?
채권 추심 시나리오에서 실수 한 번 — FDCPA를 위반하는 말 한 마디, AI가 환각으로 만들어낸 은행 계좌번호, 동의 없는 에스컬레이션 — 이것으로 고객 신뢰가 영구적으로 무너진다.
신뢰는 이 업계의 자산이다. 수호자는 그걸 지키기 위해 존재한다. AI 수호자의 감시 외에도, 모든 대외 액션은 사람의 승인을 거친다.
이것 역시 내가 일관되게 유지하는 원칙이다 — AI는 우리를 돕는 도구이고, 결정권은 여전히 사람이 쥐어야 한다.
전체 시스템은 세 레이어로 나뉜다:
Layer 1 — Gatekeepers (게이트키퍼)
에이전트는 하나뿐이다: Pre-flight.
하는 일은 계약서를 보고, 이 케이스가 Lite / In-Spot / Attorney-Recommended 세 경로 중 어디로 가야 하는지 판단하는 것이다.
판단 근거는 D-038 미수금 금액 + 계약 조항 (준거법, 중재 조항, 연체료, 계약금 %).
잘못 판단하면 전체 흐름이 틀어진다. 그래서 Pre-flight는 문지기로서 이 부분을 먼저 정확히 해야 한다.
Layer 2 — Doers (실행자)
5개 에이전트: Investigator, Diplomat, Voice, Payment, Escalator.
하는 일은 꽤 ‘평범’하다 — 이메일 작성, 자료 조회, 전화 걸기, 프로세스 진행.
각 에이전트는 한 가지 일에만 집중하고 + 완료 후 수호자의 검토를 기다린다. 실행자는 스스로 이메일·서신·전화를 대외에 발송하지 않는다. 초안을 만들고, Concierge에 전달하고, 승인을 기다린다.
Layer 3 — Guardians (수호자)
3개 에이전트: Concierge, Tone Coach, AAA Specialist.
Concierge는 ‘대외 유일 출구’ — 모든 대외 액션은 여기를 통해 나가고, 운영자가 Slack에서 APPROVE / REJECT / REVISE를 누른다. AI 스스로는 어떤 것도 대외에 발송할 수 없다.
Tone Coach는 ‘에이전트 간 어조 감시자’ — Diplomat, Voice의 초안을 실시간으로 스캔해 FDCPA를 위반하는 문장을 차단한다 (Claude로 어조 판단).
AAA Specialist는 Day 65에 동적으로 추가된다 — 평소에는 Room에 없다가 케이스가 60일 초과 연체됐을 때 Escalator가 Band Platform의 tools.lookup_peers + tools.add_participant를 통해 호출해 법적 통지 초안을 작성하게 한다. 이 역할을 만든 이유는, 향후 확장 시 계약서 분석 후 어느 주법을 따르는지 파악해 해당 주 전문 에이전트를 Room에 불러올 수 있기 때문이기도 하다 — 미국 외 제3국 포함.
이 세 레이어의 설계 철학: 실행자가 실수하면 수호자가 막는다; 수호자가 실수하면 전체 시스템이 멈춘다.
조금 과하게 긴장한 것처럼 보일 수 있지만 채권 추심 시나리오가 그만큼 취약하다. 오자 하나로 무너질 수 있다 — 어떤 단일 에이전트에게도 독자적으로 대외 접촉할 권한을 줄 수 없다.
계약서 접수부터 입금까지 — 케이스 하나가 전체 흐름을 거치면 어떻게 되나
세 레이어 아키텍처를 다 쓰고 나니 나 스스로도 좀 추상적으로 느껴졌다. 실제 케이스 하나로 전체를 돌려보면 9개 에이전트가 어떻게 릴레이하는지 알 수 있다.
Step 1 — 계약서 투입 운영자가 계약서 PDF를 시스템에 올린다. Pre-flight가 받아서 Gemini 2.5 Flash-Lite로 파싱 — 준거법 (텍사스/캘리포니아/뉴욕), 연체료 조항, 중재 조항, 계약금 %, 계약 변경 부속 합의서 여부. 이 내용을 케이스 상태에 기록한다.
Step 2 — 인보이스 투입 운영자가 인보이스 PDF를 첨부한다. 시스템이 자동으로 앞의 계약서와 매칭하고, 미수금을 계산한다 (인보이스 금액 − 이미 받은 계약금), 만기일을 확정한다. 케이스 상태 업데이트.
Step 3 — 캘린더 알림 생성 시스템이 만기일을 기준으로 Day −7 사전 공지, Day 7 친근한 리마인더, Day 30 좀 더 강한 리마인더, Day 55 전화 통화, Day 60+ Escalator, Day 65 AAA 동적 추가를 예약한다. 각 노드는 스케줄 트리거로, 운영자가 수동으로 예약할 필요 없다.
Step 4 — Investigator가 고객 배경 조사 Investigator (Featherless의 Qwen 실행)가 이 고객의 최근 6개월 기록을 가져온다 — 제때 납부한 적 있는지, 분쟁이 있었는지, 답변 이메일에 어떤 패턴이 있는지. ‘행동 태그’를 붙인다: 제때 납부형 / 연체형 / 분쟁 잦음형 / 30일 후 무응답형 등.
Step 5 — Pre-flight가 전체 케이스 경로 결정 이 단계에서 Pre-flight가 하는 것은 ‘전체 케이스 경로’ 분기이지, 이메일 어조의 강도가 아니다 (어조는 Tone Coach가 시간 단계별로 관리하며, 뒤의 Step 7에서 설명한다).
Pre-flight는 미수금 + 고객 행동 태그 + 계약 준거법을 종합 판단해 케이스를 세 경로로 분류한다:
- 라이트 모드 (Lite) (< $3K이고 고객이 협조적): 전체 케이스가 라이트 경로로 진행, 리마인더 1-2회 후 포기, Voice 전화 / 변호사 서신 / USDC 정산 단계는 시작되지 않음
- 완전 모드 (In-Spot) ($3K-$40K 미수금): 전체 흐름 진행, Day −7 사전 공지부터 Day 65 변호사 서신까지 모두 실행
- 변호사 권고 모드 (Attorney-Recommended) (> $40K 또는 고객 적대감 누적): 케이스 전체를 변호사에게 이관, 시스템은 이메일·전화를 더 이상 주도적으로 발송하지 않음
즉 Pre-flight는 “이 케이스를 전체 과정 동안 함께할 것인가"를 묻고, Tone Coach는 나중에 “이 이메일이 맞게 작성됐는가"를 묻는다. 두 에이전트가 관리하는 층위는 완전히 다르다.
Step 6 — Day −7 사전 공지 만기 전에 먼저 친근한 사전 알림을 발송한다: “Just wanted to flag this invoice is due in 7 days. Let me know if there’s anything blocking it.” Diplomat이 초안 작성, Tone Coach 검토, Concierge가 Slack에 올리면 운영자가 APPROVE를 누른 뒤 발송.
Step 7 — Day 7 친근한 리마인더 / Day 30 좀 더 강한 리마인더 (어조 강도 분기는 여기서) 만기 후 입금이 없으면 Day 7에 친근한 리마인더, Day 30에 좀 더 강한 리마인더를 발송한다. 이것이 바로 ‘추심 태도’의 분기 — 시간 단계에 따라 에스컬레이션되며, Pre-flight가 관리하는 것이 아니다. Tone Coach가 Claude Haiku로 각 이메일을 검토한다 — “kindly remind” 같은 너무 약한 표현은 차단 후 수정 요청; “we will sue you” 같은 너무 강한 표현은 FDCPA 위반으로 차단. 모든 이메일에는 결제 링크 (paylink)가 포함된다.
Step 8 — Day 55 Sarah가 전화 걸기 Day 55까지 응답이 없으면 Voice 에이전트가 ElevenLabs ConvAI + Twilio로 전화를 건다. 먼저 현지 시각이 TCPA 법규 허용 통화 시간대인지 (화·수·목 10-11시 또는 14-15시), 미국 연방 공휴일인지 확인한다 — 해당되지 않으면 다음 가능한 시간으로 재예약. (미국 시간에 맞춰 직접 전화 독촉할 필요가 없어진다!)
Sarah가 전화에서 분기할 수 있는 시나리오:
- 고객이 납부 약속 → 구체적인 날짜 기록 (예: “Saturday June 27th”), 다음 사이클 추적 예약
- 고객이 “이틀 내로 보스에게 확인 후 연락 드리겠다"고 말함 → Phase 3b ‘협조 분기’, 구체적 날짜 기록, Concierge가 ‘고객 후속 응답 약속’ 표시
- 고객이 고함·욕설 / 변호사 언급 / 파산 / 심리 위기 신호 → 즉시 에스컬레이션, Concierge가 사람을 호출
- 고객이 전화하지 말라고 요청 → 즉시 통화 종료 + 케이스의 음성 경로 동결
Step 9 — Day 60+ Escalator + Day 65 AAA 동적 추가 그래도 응답이 없으면 Escalator가 변호사 서신 초안을 작성한다 (Featherless의 Llama 70B 실행). Day 65에 Band Platform의 tools.lookup_peers + tools.add_participant를 통해 AAA Specialist를 Room에 추가한다 — 이때 처음으로 변호사 에이전트가 대화에 등장한다. AAA는 Claude Sonnet으로 변호사 서신 문구를 한 번 더 다듬는다.
Step 10 — 결제 링크 + USDC 정산 대외 발송하는 모든 이메일에는 결제 링크 (paylink)가 포함된다. D-019 철칙의 핵심이 여기에 있다 — LLM은 절대 은행 계좌번호를 작성하지 않는다. 결제 링크는 하드코딩된 URL이고, 고객이 클릭하면 Next.js로 만든 결제 페이지로 이동해 payment_methods.json에서 직접 실제 계좌번호 / SWIFT / Stripe / USDC 지갑을 읽어온다. LLM은 은행 정보를 전혀 다루지 않는다.
USDC 결제를 추가한 이유는, 앞으로 AI가 금융을 처리하는 것이 필연적인 흐름이라고 보기 때문이다… 이 시스템이 AI인 만큼 USDC 입출금 설정이 필수적이라고 생각했고, 향후 X402나 다른 신원 인증을 가진 각 AI가 서로 간의 결제를 자체적으로 처리하는 방식으로 발전할 수 있다.
고객이 USDC 결제 선택 → 자신의 지갑에서 Recoverflow의 Circle ARC 지갑으로 이체 → 수금 감지기가 10초마다 스캔해 새 거래를 감지하면 Payment 에이전트가 대조 작업을 트리거.
Step 11 — 4가지 정산 상태 자동 판단 미수금과 비교:
- 정확 납입 (FULL): 금액이 미수금과 정확히 일치 → 케이스 종료, Diplomat이 감사 이메일 발송, 추심 흐름 중단
- 부족 납입 (PARTIAL): 미수금에 미달 → 기록하고 다음 사이클에 잔액 재추심
- 초과 납입 (OVERPAID): 미수금 초과 → 초과분 환불 표시, Concierge가 사람에게 통보
- 매칭 불가 (UNMATCHED): 이 금액이 어떤 케이스에도 매칭되지 않음 → 미처리 큐 진입, 운영자가 수동 처리
Step 12 — 알림 + 감사 로그 어떤 상태이든 모두: 감사 기록 기록 (audit_trail.jsonl, 추가 전용, 21,000+ 행), Resend로 입금 알림 이메일 발송 (한·영 이중 언어), “정확 납입 FULL"인 경우 고객에게도 감사 확인 이메일 발송.
전체를 돌리면 사람은 Slack에서 몇 번 APPROVE / REJECT를 눌렀을 뿐이지만, 9개 에이전트가 계약서 파싱부터 USDC 입금까지 모두 처리한다.
모든 단계에 감사 기록이 남고, 모든 대외 액션에 사람의 검토가 있고, 모든 경계 시나리오는 철칙이 받아낸다.
이것이 “실행자는 약하고, 수호자는 강한” 구체적인 모습이다.
Voice 에이전트의 진화 이야기 (전체 이야기는 Day 2에)
세 레이어 아키텍처를 설계한 뒤 가장 힘들었던 것은 오히려 Voice 에이전트였다. 7일 동안 세 번 진화했다 — V1 단방향 통보 → V2 양방향 대화 → V3 Phase 3b 분기 추가, 버전마다 다른 지점에서 망가졌다.
V2 때 나 자신에게 전화를 걸어봤다. Sarah에게 “이틀 내로 이메일 드리겠다"고 했더니 Sarah가 이것을 바로 ‘지연’으로 판단해 에스컬레이션했다 — 그 순간 프롬프트로 작성한 ‘이상적인 대화’와 실제 사람과의 대화가 얼마나 다른지 깨달았다.
전체 시행착오 이야기와 Phase 3b의 탄생은 다른 글 《AI가 나에게 전화를 걸었다 — Recoverflow 개발 일기 Day 2: Voice 에이전트의 그 두 시간》에 썼으니 관심 있으면 읽어봐도 좋다.
이 글에서 더 쓰고 싶은 것은 — Voice 에이전트가 진짜로 깨닫게 해준 것이 “이상적인 시나리오 설계는 절대 현실 시나리오를 이길 수 없다"는 것이었다는 점이다. 그것이 바로 다음 섹션으로 이어졌다.
아무도 말하지 않은 4가지 숨겨진 시나리오
Voice V3를 완성한 뒤 J에게 물었다 — 경계에서 ‘지연’으로 판단되어 에스컬레이션되는 다른 시나리오도 있지 않을까?
Voice 에이전트의 가능한 대화 시나리오 전체를 다시 검토하고 26가지 경계 시나리오를 나열했다.
그 중 무게가 있는 4가지 숨겨진 시나리오가 이 시스템의 ‘고객 관계를 망칠 수 있는가’를 가르는 핵심이라고 생각한다:
Q1 — 고객이 절반만 납입 (D-028)
구매자가 절반을 내고 “다음 달에 나머지 드릴게요"라고 약속한다.
많은 추심 시스템이 이것을 어떻게 처리해야 할지 모른다 — ‘완료’로 볼 것인가, ‘미완료’로 볼 것인가?
우리의 처리: 다음 사이클 추적. Diplomat이 잔액에 대해 새로 추심을 시작하고, 타임라인을 처음부터 다시 카운트한다. 최대 2사이클 후 에스컬레이션.
이 설계 아이디어는 이모 경험에서 왔다. “절반 낸 고객은 대개 의지는 있지만 현금 흐름이 막힌 것이니, 여유를 주면 나머지도 받을 수 있다"고 했다.
Q2 — 고객이 AI에게 고함
구매자가 자신이 음성 에이전트와 대화하고 있다는 것을 알고 감정적으로 격해지거나 욕설을 한다.
우리의 처리: Tone Coach가 FDCPA를 위반하는 모든 응답을 실시간으로 차단. ConvAI의 16가지 에스컬레이션 이유 목록이 이 케이스를 ‘고객 지속적 적대감’으로 표시. Concierge가 몇 분 안에 사람을 호출.
Sarah (AI)는 절대 감정으로 고객에게 반응하지 않는다.
Q3 — 심리 위기 신호 (988)
구매자가 전화에서 자해, 우울, “정말 못하겠다"는 말을 꺼낸다.
우리의 처리: Concierge에 알리기 전에 set_anomaly_halt(case_id, “welfare”)를 먼저 호출. 케이스 동결. 미국 자살 예방 전화번호 988이 대화에서 언급됨. 이 순서를 고정하는 전용 단위 테스트 3개.
생명이 채무보다 우선이다. 프롬프트가 아닌 코드에 쓰여 있다.
Q4 — 고객이 파산 언급
구매자가 Chapter 11 (미국 파산 보호)을 언급한다.
우리의 처리: Sarah가 부드럽게 확인하고, ‘고객이 파산 언급’을 이유로 에스컬레이션. 법적 채권 신청 기한 인식을 트리거. Concierge가 사람 컨설턴트를 호출.
이 4가지 시나리오는 프롬프트를 작성할 때 떠오른 것들이 아니다.
이것들은 — 내가 이 전화를 받는 실제 사람이라면 어떤 말을 할까 상상했을 때 나온 것이다. (이것이 내 강점이기도 하다 — 상대방 입장이 되어 다양한 상황을 미리 연습하는 것)
방금 어머니를 잃은 사람, 사업이 망한 사람, 거래처가 도망간 사람, 현금 흐름이 끊긴 사람 — 이런 순간에 사람이 어떤 말을 하는지, 어떤 반응이 괜찮은지, 어떤 반응이 사람을 망가뜨리는지.
이 AI가 이 4가지 순간에 지뢰를 밟으면 엄마는 친구에게 추천하지 않을 것이다.
돌아보며 — 7일 동안 배운 것
여기까지 쓰고 나서 7일 동안 배운 것을 정리해 봤다.
첫째: “하지 말아야 할 것“이 “해야 할 것"보다 훨씬 더 생각하기 어렵다. Day 9-12 4일을 ‘금지 / 예외 / 레드라인’ 목록 작성에 썼다. Day 13-15 코드 작성은 3일밖에 안 걸렸다 — 앞에서 정리했기 때문에 연결이 오히려 빨랐다. “해야 할 것"에 너무 많은 시간을 쓰고 있다면 그 위의 층이 아직 충분히 명확하지 않은 것일 수 있다.
둘째: 실행자는 약하고, 수호자는 강하다는 것이 이 설계의 척추다. 멀티에이전트 시스템의 가장 흔한 실패 패턴은 ‘만능 에이전트’가 모든 판단을 프롬프트 하나에 밀어 넣고 실수 없기를 기도하는 것이다. 우리는 반대를 선택했다 — 실행자는 평범하고, 수호자는 철벽. 이 계층이 잡히면 실행자의 프롬프트 때문에 괴로워하지 않아도 된다는 것을 알게 된다. 수호자가 받아내기 때문이다.
셋째: 철칙은 ‘절대 위반 불가 경성 규정’이어야 하고 ‘모범 사례 권장 사항’이어서는 안 된다. 988 심리 위기 동결, D-019 LLM 은행 계좌번호 작성 금지, Tone Coach FDCPA 차단 단어 — 이것들은 모두 권장 사항이 아니라 하드코딩된 것이다. ‘모범 사례’는 “오늘은 시간이 촉박하니 건너뛰자"로 사라지지만, 철칙은 그러지 않는다.
넷째: 현실 시나리오는 항상 이상 시나리오를 이긴다. Voice V2가 망가진 건 내가 직접 전화를 걸어봤을 때 발견한 것이고, 4가지 숨겨진 시나리오는 내가 이 전화를 받는 실제 사람을 상상했을 때 추론한 것이다. 모의 대화 API도, 목 테스트도, 드라이 런도 진짜로 상대방 입장이 되어 한 번 걸어보는 것을 대체할 수 없다.
다섯째: 설계에 시간을 투자한 것은 낭비가 아니었다. 7일 해커톤이라면 “6일 코딩 + 1일 제출"이어야 한다고 생각했다. 실제는 4일 설계 + 3일 코딩 + 3일 폴리싱이었다. 돌아보면 이 비율이 맞았다 — 4일 설계를 마쳤을 때 이미 이후 3일 동안 각 코드 줄이 어떤 모습이어야 하는지 알고 있었다.
마치며
해커톤 제출 순간 전체 시스템은 9개 에이전트, 21,000+ 행의 감사 기록, 482개의 테스트 전부 통과, Circle USDC 실제 ARC-TESTNET 정산 5건, 7개 스폰서 전부 실제 실행 중이었다.
하지만 돌아보면 — 진짜로 내가 스스로 자랑스러운 것은 이 숫자들이 아니라, 이 시스템이 그 4가지 숨겨진 시나리오에서 어떻게 반응하는가이다.
고객이 감정적으로 무너지거나, 988을 언급하거나, 파산을 말하거나, 절반 내고 다음 달에 나머지 주겠다고 할 때 — 엄마가 이 시스템을 같은 상황에 처한 동료 친구들에게 추천하길 바란다.
언젠가 엄마가 실제로 그렇게 한다면, 이 7일은 충분한 가치가 있었다.
아직 시스템에 넣지 못한 것들도 많다 — 시스템의 가격 모델은 아직 비어 있고, 아키텍처에 완성되지 않은 부분도 있고, 수정해야 할 부분도 남아 있다…
하지만 철칙은 세워졌다. 나머지는 천천히 해도 된다.
설계에 시간을 투자한 것은 낭비가 아니었다.