대기 명단(Waitlist)을 공개하기 전, 인디 해커의 AI 에이전트 제품에 필요한 7가지

만약 당신이 지난 90일 동안 1인 창업자(Solo founder)로서 AI 에이전트 제품을 만드는 데 시간을 보냈다면, 당신에게는 작동하는 데모, Stripe 테스트 모드, Gumroad 리스팅, 그리고 Twitter 스레드가 있을 것입니다. 하지만 당신에게 없는 것은 바로 당신을 위해 작성된 프로덕션 준비 상태 체크리스트(Production-readiness checklist)입니다. 인터넷에 있는 다른 모든 체크리스트는 당신에게 플랫폼 팀, Datadog 예산, 그리고 호출 가능한 SRE(Site Reliability Engineer)가 있다고 가정합니다. 당신에게 있는 것은 MacBook, 신용카드

가장 저렴한 점검 방법: 코드에서 부수 효과(side-effecting)를 일으키는 도구들의 함수 이름(send_email, charge, create_*, update_*)을 검색해 보세요. 각 함수에 대해 다음과 같이 질문하십시오: "만약 동일한 인자(args)로 이 함수를 두 번 호출하면 어떤 일이 발생하는가?" 만약 답변이 "이메일이 두 번 발송된다"라면, 당신의 미래에는 새벽 2시에 장애 대응(incident)을 해야 하는 상황이 기다리고 있습니다.

해결책: 멱등성 키(idempotency key)를 추가하세요. 이 키는 보통 (user_id, intent, day_bucket)의 해시값입니다. 실행하기 전에 작은 Redis 또는 SQLite 테이블에서 이 키를 확인합니다. 거부된 중복 요청은 캐시된 결과를 반환합니다.

더 깊이 있는 내용을 원하신다면 Why Your AI Agent Sent That Email Twice에서 이 주제에 대해 더 자세히 작성했습니다.

2. 세션당 토큰 제한 (10분)

세션당 소비되는 토큰에 엄격한 상한선(hard ceiling)을 설정하세요. 월 29달러 요금제로 GPT-4급 모델을 실행하는 1인 개발자는, 단 한 명의 사용자가 50단계의 에이전트 루프(agent loop)를 트리거하는 것만으로도 파산할 수 있습니다.

가장 저렴한 점검 방법: 각 LLM 호출 전에 대화 기록(conversation history)을 조립하는 부분을 찾으세요. API 호출에 max_tokens 파라미터가 있습니까? 에이전트 루프에 max_messages 또는 max_steps 파라미터가 있습니까? 둘 중 하나라도 없다면, 당신에게는 제한(cap)이 있는 것이 아니라 그저 기도(prayer)만 하고 있는 것입니다.

해결책: 에이전트 진입점 근처에 MAX_TOKENS_PER_SESSION = 50_000 상수 하나와 MAX_AGENT_STEPS = 12 상수를 설정하세요. 두 상수 모두 BudgetExceeded 예외(exception)를 발생시키며, 이를 포착(catch)하여 사용자에게 친절한 에러 메시지를 반환하면 됩니다.

비용 폭발의 형태에 대한 심층 분석은 Your AI Agent Bill Is Probably 10x-700x Higher Than It Needs To Be에서 확인할 수 있습니다. 2026년 인디 에이전트의 88%가 실패하는 이유는 모델이 나빠서가 아니라, 청구서가 런웨이(runway)를 끊어버리기 때문입니다.

3. 부수 효과당 3줄의 로그 (15분)

에이전트가 이메일을 보내거나, 카드를 결제하거나, 파일을 작성할 때마다 반드시 다음 세 줄의 로그를 남겨야 합니다:

[intent]      사용자가 요청한 내용
[post-verify] 부작용 발생 후 세상의 모습
[outcome-assert] 작동했는지 나중에 확인할 항목

구조화된 JSON 세 줄이 아닙니다. 검색 가능한(grep-able) 로그 라인 세 개입니다. 이 로그는 Grafana 대시보드에서가 아니라, 새벽 2시에 tail -f 명령어로 읽게 될 것입니다. 형태는 Your AI Agent Returns 200 and Is Wrong: The Silent-Success Drift Pattern에 문서화되어 있습니다. 요약하자면, 위험한 에이전트 실패는 충돌(crash) 자체가 아니라 조용히 잘못된 일을 저지르는 '성공'입니다.

4. 수동 비활성화 스위치 (Manual kill switch) (10분)

재배포 없이 60초 이내에 에이전트를 끌 수 있는 방법이 필요합니다. 가장 저렴한 버전은 S3의 JSON 파일 내 기능 플래그(feature flag), Redis 키, 또는 Stripe 구독 웹훅입니다. 핵심은 다음과 같습니다: 고객이 오후 6시에 DM을 보내며 "당신의 에이전트가 내 전체 고객 목록에 마케팅 이메일을 보냈어"라고 말할 때, 당신에게는 그것을 중단할 60초의 시간이 주어져야 합니다.

실제 상용화된(production) 에이전트 제품은 상태 페이지(status page)를 갖추고 있습니다. 개인 개발자(solo-builder)가 만든 에이전트 제품이라면 휴대폰에서 플립(flip)할 수 있는 IS_AGENT_ENABLED 상수만 있으면 됩니다.

5. 출시 전에 항상 실행해야 하는 3가지 테스트 입력값 (The 3 test inputs that always run before you ship) (15분)

모든 인디 에이전트 제품에는, 이것들이 망가지면 전체 제품을 망가뜨리는 3가지 입력값이 있습니다. 이 값들은 에이전트마다 다르지만, 항상 존재합니다. 그것들을 찾아내고, 적어두세요. 그리고 배포(deploy)하기 전에 매번 실행하세요.

고객 지원 에이전트의 경우: (a) 환불 요청, (b) 인간에게 에스컬레이션되어야 하는 요청, (c) 에이전트가 가지고 있지 않은 도구가 필요한 요청.

리서치 에이전트의 경우: (a) 단일 출처 질문(single-source question), (b) 다중 출처 질문(multi-source question), (c) 좋은 답변이 없는 질문.

코딩 에이전트의 경우: (a) 한 줄 변경, (b) 다중 파일 리팩토링(multi-file refactor), (c) 인간의 판단이 필요한 요청.

이것들을 PRE_PROD_SMOKE.md라는 파일에 넣으세요. 실행하세요. 매번. 단 한 번도 빠짐없이.

6. IP당이 아닌 사용자별 속도 제한 (Rate limit per user, not per IP) (15분)

단 한 명의 헤비 유저(power user)가 당신의 API 예산을 모두 태워버릴 수 있습니다. 만약 IP 기반으로 속도 제한(Rate limit)을 건다면, 그 사용자는 VPN을 사용하여 다시 예산을 소진할 것입니다. 요청 횟수(requests)가 아니라 user_id(또는 api_key)와 cost(사용된 토큰량)를 기준으로 속도 제한을 설정하세요. 하나의 긴 에이전트 루프(agent loop)는 하나의 "요청"이지만 4달러의 API 비용을 발생시킬 수 있습니다. 당신에게는 비용의 형태를 고려한 제한(budget-shaped limit)이 필요합니다.

가장 저렴하게 확인할 수 있는 방법: 당신에게 속도 제한이 아예 있습니까? 있다면, 그것이 사용자별입니까 아니면 IP별입니까? 만약 없다면, 당신은 지불할 수 없는 4,000달러의 OpenAI 청구서를 받기까지 단 2주밖에 남지 않았습니다.

7. "속도 제한에 걸렸습니다" 페이지 (10분)

속도 제한이 작동할 때, 사용자는 무엇을 보게 됩니까? 만약 답변이 "OpenAI 라이브러리에서 발생한 500 에러"라면, 당신은 플랫폼의 내부 정보(internals)를 고객에게 유출하고 있는 것입니다. 만약 답변이 "빈 페이지"라면, 당신은 고객을 영원히 잃게 될 것입니다.

가장 저렴한 버전: /rate-limited 경로에 "너무 빠르게 실행하고 있습니다. 여기 60초 카운트다운이 있습니다. 그동안 할 수 있는 일은 다음과 같습니다"라고 적힌 정적 HTML 페이지를 만드세요. 작성하는 데 5분이면 충분합니다. 이는 "앱이 그냥 작동을 멈췄어요"라는 트윗으로부터 당신을 구해줄 것입니다.

1주 차 체크인 (6일 차에 살펴봐야 할 5가지)

대기 명단(waitlist)을 공개했습니다. 40명이 가입했습니다. 그중 12명이 에이전트를 3회 이상 실행했습니다. 2명은 환불을 요청했습니다. 여기서 살펴봐야 할 것은 다음과 같습니다:

1. 사용자당 비용 분포 (The cost-per-user distribution). 중앙값 사용자 비용이 0.05달러인데 90백분위수 비용이 4달러인가요? 만약 꼬리 부분(tail)이 두껍다면, 이는 파워 유저(power-user) 문제이자 가격 책정(pricing) 문제입니다.
2. "완료되었으나 틀린" 비율 ("completed but wrong" rate). 무작위로 선정된 10개의 완료된 세션에 대해 [outcome-assert] 로그 라인을 읽고 사용자가 얻은 결과와 일치하는지 확인하세요. 10개 중 3개가 틀렸다면, 이는 침묵하는 성공 드리프트(silent-success drift) 문제입니다.
3. "도구 호출 실패" 비율 ("tool call failure" rate). 무작위로 선정된 10개의 세션에 대해 에러를 반환한 도구 호출(tool calls) 횟수를 세어보세요. 만약 에이전트가 환각(hallucination)된 결과로 도구 에러를 덮어버리고 있다면, 이는 상태 그래프 발명(state-graph invention) 문제입니다.
4. "모름" 비율 ("I do not know" rate). 에이전트가 "모릅니다"라고 말하거나 사람에게 에스컬레이션(escalate)하는 빈도는 어느 정도인가요? 만약 2% 미만이라면 에이전트가 환각을 일으키고 있을 가능성이 높습니다. 만약 30% 이상이라면 에이전트는 쓸모가 없는 것입니다.
5. "첫 세션 성공" 비율 ("first-session success" rate). 40명의 가입자 중 첫 세션을 성공적으로 마친 사람은 몇 명인가요? 만약 60% 미만이라면 온보딩(onboarding)이 잘못된 것입니다. 만약 90% 이상이라면 에이전트가 너무 보수적일 가능성이 높습니다.

3계층 관측성 모델(3-layer observability model)에 대한 더 심도 있는 내용은 What Your AI Agent's Tool Calls Actually Look Like in Production에서 확인할 수 있습니다. 프로덕션 환경에서 무엇인가를 디버깅하려면 LLM 호출 엔벨로프(LLM call envelope), 도구 시도(tool attempt), 부수 효과 검증(side-effect verification)이라는 3개 계층을 모두 확인해야 합니다.

제가 계속 목격하는 3가지 설정 오류 패턴

다음은 개발 단계에서는 괜찮아 보이지만 프로덕션에서 당신을 망가뜨리는 세 가지 요소입니다:

A. 멱등성 키(idempotency key) 없는 타임아웃 시 재시도

LLM 호출에 재시도 데코레이터(retry decorator)를 추가했습니다. LLM 호출이 타임아웃되었습니다. 재시도는 성공했습니다. 하지만 LLM 호출 내부의 도구 호출(tool call) (카드를 결제하거나 이메일을 보내는 부분)이 타임아웃된 부분이었습니다. 재시도가 도구 호출을 다시 실행했고, 고객은 두 번 결제되었습니다. 이것이 가장 흔한 1주 차 장애 사례입니다.

B. 스트림이 완료되기 전 부수 효과(Side effects)를 동반한 스트리밍 응답 (Streaming response with side effects)

사용자에게 에이전트의 응답을 스트리밍(Streaming)합니다. 스트림 내용은 "네, 고객 리스트로 지금 바로 이메일을 보내겠습니다 — 보내는 중 — 완료되었습니다."와 같습니다. 하지만 _완료(done)_는 스트림의 끝에서 발생합니다. 만약 사용자가 "보내는 중" 단계에서 브라우저를 닫는다면, 이메일은 이미 발송되었지만 사용자는 확인을 받지 못하게 됩니다. 결과적으로 사용자는 이메일이 발송되지 않았다고 생각하지만, 실제로는 이메일이 발송된 상황이 발생합니다. 이는 결제 취소(Chargeback)가 발생하기 직전의 상황과 같습니다.

C. 테스트 모드가 실제로는 테스트 모드가 아님

Stripe가 테스트 모드(Test mode)로 설정되어 있습니다. 에이전트 코드는 테스트 모드에서 stripe.Charge.create를 호출합니다. 하지만 에이전트는 동시에 프로덕션 모드(Production mode)에서 sendgrid.send를 호출하며, 정작 실패하는 것은 sendgrid.send입니다. 로그에서 보이는 500 에러는 Stripe 테스트 호출에 대한 것입니다. 실제 프로덕션에서의 실패는 SendGrid 호출입니다. 당신은 6시간 동안 엉뚱한 시스템을 디버깅(Debug)하게 됩니다.

문제를 발견했을 때 해야 할 일

이 리스트를 실행해보고 아직 갖추지 못한 것이 2~3개 있다면, 당신은 2026년 인디 에이전트 빌더(Indie agent builders)의 90%와 같은 상황에 처해 있는 것입니다. 해결책은 "Langfuse를 구매하는 것"이 아닙니다. 해결책은 당신의 코드, 로그, 그리고 가장 빈번한 3가지 사용자 흐름(User flows)을 90분 동안 사람이 직접 읽어보는 것입니다. 이는 정확히 프로덕션 준비 상태 검토(Production-readiness review)의 형태를 띱니다.

이 글의 요점은 "컨설턴트가 필요하다"는 것이 아닙니다. 요점은 "여기 체크리스트가 있고, 여기 순서가 있으며, 인디 에이전트 제품에서 실제로 하중을 견뎌내야 하는(Load-bearing) 7가지 요소가 여기 있다"는 것입니다. 만약 당신이 스스로 이 리스트를 실행하여 7가지를 모두 구현해낼 수 있다면, 당신은 엔지니어 5명을 보유하고 Datadog 비용으로 5만 달러를 지불하는 대부분의 팀보다 앞서 있는 것입니다.

만약 그렇게 할 수 없다면 — 시간이 없다고 느끼거나, 7가지 중 무엇을 갖추고 있는지 확신이 서지 않거나, 1주 차 체크인 섹션을 읽고 5가지 질문에 답할 데이터조차 없다는 것을 깨달았다면 — 바로 그 순간이 90분간의 검토가 일주일간의 디버깅보다 저렴한 시점입니다. 상단의 링크가 바로 그 90분간의 검토를 위한 것입니다.

즐거운 출시(Shipping) 되시길 바랍니다.

출처

• Master of Code, "AI가 생성한 코드의 45%가 보안 결함과 함께 출시됨," 2026년 5월
• DigitalApplied, "에이전트 실패율 88%, 평균 직접 비용 34만 달러," 2026
• Wiz, "프로덕션 환경의 vibe-coded 앱 20%가 심각한 취약점을 보유함," 2026년 5월
• Predict/Medium, "LLM 비용 폭발의 5가지 메커니즘, 최악의 경우 717배 증가," 2026년 5월
• Tom's Hardware, "토큰당 가격은 2년 연속 하락했으나, 태스크당 비용만이 유일하게 변동된 단위임," 2026년 5월
• Datadog, "LLM 호출 스팬(span)의 5%에서 오류 발생, 60%는 속도 제한(rate-limit) 초과로 인한 것," 2026년 2월
• Oso, "프롬프트 인젝션(Prompt injection)은 실제 위험이 아닙니다; 과도한 권한이 부여된 작업이 실제 위험입니다," 2026