Agreed

계약을 따내는 것을 돕는 서비스는 많지만, 계약 후 고객이 요구를 계속 추가하는 국면은 비어 있었습니다. 프리랜서에게는 요구사항 확정·금액·일정·수락 여부가 곧 계약 조건이라, AI가 이걸 대신 정하면 쓸 수 없는 도구가 됩니다. 3일(실질 하루 반)이라 만들 것보다 만들지 않을 것을 정하는 일이 더 중요했습니다.

Gmail·Slack 연동 → 요구 분석 → 사람 판단 → 답변 초안까지 이어지는 동작하는 프로토타입을 만들되, AI가 어디까지 하고 사람이 어디부터 하는지를 제품 원칙으로 못 박는 것.

티켓을 열면 항상 '1 고객 메시지 → 2 AI 분석 → 3 내 판단 → 4 답변 초안' 순서로 보이게 화면 위계를 잡았습니다. AI는 2번까지만 하고 확정·반영·상태 변경·발송은 사람이 누른 자리에서만 일어납니다. 화면의 단위를 '메시지'에서 '티켓'으로 바꾸는 정보구조 재설계(61파일)를 주도했고, 티켓 상태는 Active·Done·Reject 셋만 남기고 자동 전환을 없앴습니다. AI 분석은 메시지마다 필요한 항목만 동적으로 띄우고, 정보가 부족하면 원인을 추정하지 않고 필요한 정보만 나열하도록 설계했습니다. 목 데이터를 걷어내고 백엔드 API에 연결하며 사람의 판단을 localStorage에서 서버로 옮겼고, 세션은 HttpOnly 쿠키로 받아 인증 접점을 lib/auth.ts 한 곳으로 제한했습니다. CLAUDE.md 팀 규약을 작성해 절대 규칙 8개(목 데이터 금지, 상태 변경은 사람만, 인증 접점 단일화 등)를 사람과 AI 에이전트가 같은 문서로 읽게 했습니다.

백엔드에 발송 endpoint가 없는 상태에서 해커톤 시연을 준비해야 했습니다. 보내는 척하는 편이 화려하지만 실제로 보내지 않으면서 보낸다고 말할 수는 없었습니다. 로그인 직후 목록이 비어 보이고 새로고침해야 뜨는 버그도 있었습니다.

'답변 보내기'를 '복사' + '보냄으로 표시'로 바꿔 데모에서 거짓말하지 않기로 했습니다. 로그인 버그는 루트 provider가 로그인 화면에서 이미 마운트돼 401을 받아 들고 있던 것이 원인이라, 조회 시작 지점을 앱 레이아웃 안으로 옮겨 해결했습니다. 못 여는 파일에는 왜 못 여는지 적어 실패를 침묵으로 두지 않았고, 시연 케이스 6종이 화면에서 전환되는지 직접 눌러 확인해 PR에 남겼습니다.

AI 제품에서 가장 중요한 설계는 모델이 아니라 권한 경계였습니다. 기획이 곧 지우는 일이었고, 지운 3,612줄 중 상당수가 하루 전에 우리가 만든 것이었습니다. 데모에서 속이지 않는 선택이 오히려 설명하기 쉬웠습니다 — 못 하는 것을 못 한다고 적으니 무엇을 만들었는지가 분명해졌습니다. 백엔드(FastAPI·요구사항 추출 파이프라인)는 팀원이 만들었고, 저는 기획과 프론트엔드를 담당했습니다.