작동하는 AI 데모는 오해를 불러일으킬 수 있습니다. 데모가 가짜이기 때문이 아닙니다.

데모는 보통 단 한 가지만을 증명하기 때문입니다:

제어된 조건 하에서 모델이 유용한 출력을 생성할 수 있다는 것.

그것은 해당 기능이 고객을 맞이할 준비가 되었다는 것을 증명하는 것과는 다릅니다.

고객 대상 AI 기능은 다양한 입력, 반복적인 사용, 비용 압박, 느린 응답, 차단된 요청, 불분명한 출력, 인간의 검토 (human review), 변화하는 모델 가용성, 그리고 해당 기능에 의존하기 시작하는 사용자들을 견뎌내야 합니다.

바로 이 지점에서 많은 AI 기능이 프롬프트 작업 (prompt work)이 아닌, 제품 작업 (product work)이 됩니다.

단순히 모델 선택 (model selection)의 문제가 아닙니다.

제품 작업 (product work)입니다.

이것이 팀이 배포 전 AI 기능 준비 상태 검토 (AI feature readiness review)를 수행해야 하는 이유입니다.

검토 과정이 무거울 필요는 없습니다. 프로세스를 위해 팀의 속도를 늦춰서도 안 됩니다. 하지만 반드시 한 가지 명확한 질문을 던져야 합니다:

실제 사용자가 이 AI 워크플로우 (workflow)에 의존할 때, 이를 신뢰할 수 있는가?

이것이 지금 중요한 이유

AI 제품의 표면이 점점 더 복잡해지고 있습니다.

최근의 모델 출시들은 팀에게 역량, 속도, 비용, 그리고 추론 깊이 (reasoning depth) 측면에서 더 많은 선택지를 제공합니다. 이는 유용하지만, 동시에 팀이 어떤 작업에 어떤 모델 경로를 할당할지 결정해야 함을 의미합니다.

프롬프트 캐싱 (Prompt caching)은 반복되는 컨텍스트 (context)가 잘 구조화되어 있을 때 비용과 지연 시간 (latency)을 줄일 수 있지만, 안정적인 프롬프트 설계와 측정이 필요합니다. 매번 변하는 컨텍스트를 보내는 기능은 큰 이득을 얻지 못할 수도 있습니다.

AI 코딩 에이전트 (AI coding agents)는 IDE에서 풀 리퀘스트 (pull requests) 및 커맨드 라인 워크플로우 (command-line workflows)에 이르기까지 소프트웨어가 배포되는 방식에 점점 더 가까워지고 있습니다. 이는 검토 과정이 가시적으로 유지될 때만 팀이 더 빠르게 움직이는 데 도움을 줄 수 있습니다.

AI 트래픽 제어 (AI traffic controls) 또한 더욱 구체화되고 있습니다. 검색, 사용자 지향 에이전트, 그리고 학습 크롤러 (training crawlers)는 웹사이트와 제품 콘텐츠에 서로 다른 결과를 초래합니다.

이러한 변화들은 모두 동일한 패턴을 가리킵니다:

AI는 더 이상 단순한 역량 계층 (capability layer)이 아닙니다.

AI는 제품 운영 체제 (product operating system)의 일부가 되고 있습니다.

즉, 준비 상태 검토 (readiness review)가 중요하다는 뜻입니다.

7가지 체크리스트

1. 작업 적합성 (Task fit)

모델이 아니라 작업 (task)에서 시작하십시오.

훌륭한 준비 상태 검토 (readiness review)는 다음과 같은 질문을 던집니다:

• AI 기능이 수행하는 정확한 작업 (job)은 무엇인가?
• 해당 작업이 반복적인가, 판단 중심적인가, 민감한가, 아니면 고객을 직접 상대하는가?
• AI 출력물이 결정을 내리는가, 결정을 제안하는가, 아니면 인간을 위한 작업 준비를 하는가?
• 출력물이 불완전하거나 틀렸을 경우 어떤 일이 발생하는가?

모든 AI 작업의 리스크가 동일하지 않기 때문에 이 질문은 중요합니다.

고객 지원 노트의 짧은 요약은 가격 책정 권장 사항 (pricing recommendation)과는 다릅니다.

답장 초안은 자동 계정 조치 (automatic account action)와는 다릅니다.

코드 제안은 프로덕션 변경 (production change)과 다릅니다.

작업이 불분명하다면, 해당 기능은 준비되지 않은 것입니다.

첫 번째 준비 상태 규칙은 간단합니다:

지능 (intelligence)을 선택하기 전에 작업을 정의하십시오.

2. 모델 라우팅 (Model routing)

다음 질문은 "어떤 모델이 가장 좋은가?"가 아닙니다.

다음과 같습니다:

어떤 작업에 어떤 모델 경로 (model path)가 적합한가?

어떤 작업은 빠르고 비용이 저렴한 모델에서 실행될 수 있습니다. 어떤 작업은 더 강력한 추론 (reasoning)이 필요합니다. 어떤 작업은 출력이 가시화되기 전에 인간에게 라우팅되어야 합니다.

유용한 제품은 모든 요청에 대해 가장 강력한 모델을 필요로 하지 않습니다.

라우팅 (routing)이 필요할 뿐입니다.

간단한 라우팅 모델은 다음과 같을 수 있습니다:

• 일상적인 작업: 빠른 모델
• 복잡한 작업: 더 강력한 추론 모델
• 민감한 작업: 검토 필요
• 불분명한 작업: 추가 컨텍스트 요청
• 실패한 작업: 폴백 경로 (fallback path)

이는 두 가지 흔한 실수를 방지합니다.

첫 번째 실수는 가장 강력한 모델을 과도하게 사용하여 불필요한 비용을 발생시키는 것입니다.

두 번째 실수는 약한 추론이 재시도 (retries), 고객 지원 업무, 또는 신뢰 문제를 야기하는 작업에 더 저렴한 모델을 사용하는 것입니다.

올바른 제품 관점의 질문은 다음과 같습니다:

이 작업에 대해 가장 저렴하면서도 신뢰할 수 있는 경로는 무엇인가?

3. 워크플로별 비용 (Cost by workflow)

AI 비용은 API 호출 (API call)만으로 측정해서는 안 됩니다.

성공적인 작업 (successful task)을 기준으로 비용을 측정하십시오.

하나의 작업에는 다음이 포함될 수 있습니다:

• 한 번의 모델 호출,
• 반복되는 컨텍스트 (context),
• 재시도 (retries),
• 출력 수정,
• 검토,
• 에스컬레이션 (escalation),
• 고객 지원,
• 그리고 폴백 (fallback).

첫 번째 출력이 저렴하더라도 자주 재작업이 필요하다면, 그 워크플로 (workflow)는 저렴한 것이 아닙니다.

준비 상태 검토 (readiness review)에서는 다음 사항들을 정의해야 합니다:

• 예상 입력 크기 (expected input size),
• 예상 출력 크기 (expected output size),
• 재시도율 (retry rate),
• 검토율 (review rate),
• 에스컬레이션율 (escalation rate),
• 캐시 히트율 (cache hit rate),
• 성공적인 작업당 비용 (cost per successful task),
• 그리고 사용량 증가 시의 비용 (cost at higher usage).

소규모 파일럿 (pilot)은 이를 숨길 수 있습니다. 10번의 내부 테스트는 저렴해 보일 수 있습니다. 하지만 1만 번의 고객 액션은 워크플로 (workflow)의 실제 모습을 드러낼 수 있습니다.

출시 전, 다음 세 가지 수준에서 모델 비용을 모델링하십시오:

1. 파일럿 사용량 (Pilot usage)
2. 일반 사용량 (Normal usage)
3. 성장 사용량 (Growth usage)

기능에 완벽한 수치가 필요한 것은 아닙니다.

현실적인 가정이 필요할 뿐입니다.

4. 컨텍스트 (Context) 및 캐싱 (caching)

많은 AI 기능들이 동일한 컨텍스트 (context)를 반복해서 전송합니다.

여기에는 다음이 포함될 수 있습니다:

• 제품 규칙 (product rules),
• 고객 정책 (customer policies),
• 도움말 센터 콘텐츠 (help center content),
• 시스템 지침 (system instructions),
• 도구 정의 (tool definitions),
• 예시 (examples),
• 그리고 계정 수준의 설정 (account-level configuration).

해당 컨텍스트가 반복된다면, 캐싱 (caching)이 비용과 지연 시간 (latency)을 줄이는 데 도움이 될 수 있습니다. 하지만 캐싱은 반복되는 콘텐츠가 안정적이고, 시스템이 재사용할 수 있는 방식으로 구조화되어 있을 때만 효과적으로 작동합니다.

준비 상태 검토에서는 다음을 질문해야 합니다:

• 프롬프트 (prompt)의 어느 부분이 안정적인가?
• 어느 부분이 사용자마다 변하는가?
• 반복되는 컨텍스트가 일관되게 배치되어 있는가?
• 캐시 히트 (cache hits)를 측정하고 있는가?
• 캐시 미스 (cache miss)가 발생하면 어떻게 되는가?
• 캐싱이 사용자가 인지할 수 있을 정도로 지연 시간을 충분히 변화시키는가?

이 지점이 바로 프롬프트 디자인 (prompt design)이 아키텍처 (architecture)가 되는 단계입니다.

프로덕션 (production)용 프롬프트는 매번 바뀌는 하나의 커다란 텍스트 블록이어서는 안 됩니다.

안정적인 컨텍스트와 가변적인 입력을 분리해야 합니다.

5. 사람의 검토 (Human review)

어떤 AI 기능은 출력을 직접 보여줄 수 있습니다.

반면, 그렇지 않아야 하는 기능들도 있습니다.

준비 상태 검토에서는 사람의 검토 (human review)가 어디에 위치해야 하는지를 정의해야 합니다.

다음 질문을 던지십시오:

• 출력이 고객의 결정에 영향을 미치는가?
• 법적, 재무적, 보안적 또는 제품 리스크를 초래할 수 있는가?
• 기록 시스템 (system of record)에 기록을 남기는가?
• 고객에게 노출되는 데이터를 변경하는가?
• 코드, 액세스, 결제, 신원 또는 지원 결과에 영향을 미치는가?
• 검토자가 왜 해당 출력이 생성되었는지 이해할 수 있는가?

검토는 막연한 안전망으로 취급되어서는 안 됩니다.

설계되어야 합니다.

예를 들어:

• AI가 초안을 작성하고, 사람이 승인합니다.
• AI가 분류하고, 사람이 예외 케이스 (edge cases)를 검토합니다.
• AI가 제안하고, 제품 로직 (product logic)이 결정합니다.
• AI가 조사하고, 엔지니어가 검증합니다.
• AI가 요약하고, 고객이 선택합니다.

핵심은 소유권 (ownership)입니다.

만약 아무도 검토 지점 (review point)을 소유하지 않는다면, 그 워크플로 (workflow)는 준비되지 않은 것입니다.

6. 폴백 동작 (Fallback behavior)

프로덕션 환경의 AI 기능에는 폴백 (fallback)이 필요합니다.

모델이 항상 실패할 것이기 때문이 아닙니다.

실제 워크플로에는 예외 케이스 (edge cases)가 존재하기 때문입니다.

• 모델을 사용할 수 없는 경우.
• 출력 결과의 신뢰도 (confidence)가 낮은 경우.
• 안전 규칙 (safety rule)이 응답을 차단하는 경우.
• 요청이 너무 모호한 경우.
• 비용이 한도를 초과하는 경우.
• 작업에 더 많은 정보가 필요한 경우.
• 사용자가 범위를 벗어난 것을 요청하는 경우.

준비 상태 검토 (readiness review)에서는 이러한 순간에 제품이 어떻게 동작해야 하는지를 정의해야 합니다.

좋은 폴백 동작에는 다음과 같은 것들이 포함될 수 있습니다:

• 명확한 질문을 던지기,
• 더 좁은 범위의 답변을 반환하기,
• 사람의 검토로 라우팅 (route)하기,
• 작업을 대기열 (queue)에 넣기,
• 더 낮은 성능의 경로를 사용하기,
• 정당한 사유가 있을 때만 더 강력한 모델을 사용하기,
• 또는 왜 요청을 완료할 수 없는지 설명하기.

나쁜 폴백 동작은 침묵, 모호한 에러, 혼란스러운 거절 문구, 또는 고장 난 것 같은 경험으로 나타납니다.

사용자는 AI가 실패한 것인지, 아니면 제품이 의도적인 결정을 내린 것인지 추측할 필요가 없어야 합니다.

7. 접근 권한 및 경계 (Access and boundaries)

AI 기능에는 접근 규칙 (access rules)이 필요합니다.

이는 제품 내부와 외부 모두에 적용됩니다.

제품 내부에서 팀은 다음을 정의해야 합니다:

• AI가 읽을 수 있는 데이터,
• AI가 호출할 수 있는 도구 (tools),
• AI가 수행할 수 있는 작업,
• 승인이 필요한 작업,
• 어떤 로그 (logs)를 유지할지,
• 그리고 어떤 데이터가 모델에 절대 들어가서는 안 되는지.

제품 외부에서 팀은 다음을 정의해야 합니다:

• AI 크롤러 (crawlers)가 접근할 수 있는 공개 콘텐츠,
• 검색 가능하게 유지되어야 할 문서,
• 제한되어야 할 학습 접근 권한,
• 그리고 사용자 지향 에이전트 (user-directed agents)가 가져올 수 있는 것.

이것은 더 이상 단순한 SEO 문제가 아닙니다.

이것은 제품 접근 (product access) 문제입니다.

창업자가 모든 규칙을 직접 설정할 필요는 없습니다. 하지만 창업자는 그 규칙 뒤에 숨겨진 원리를 알고 있어야 합니다.

AI는 정의되지 않은 접근 권한(undefined access)을 가져서는 안 됩니다.

준비 상태 검토 템플릿 (A readiness review template)

고객 대상 AI 기능을 출시하기 전에 다음 질문들에 답해 보세요.

작업 (Task)

AI가 수행하는 작업은 무엇인가?

사용자가 완료하려는 일은 무엇인가?

무엇을 성공적인 결과(successful outcome)로 간주할 것인가?

모델 경로 (Model path)

1. 어떤 작업이 빠른 모델(fast model)을 사용하는가?
2. 어떤 작업이 더 강력한 추론(reasoning)을 필요로 하는가?
3. 출력이 사용자에게 도달하기 전에 검토되어야 하는 작업은 무엇인가?

비용 (Cost)

1. 성공적인 작업당 비용은 얼마인가?
2. 사용량이 10배로 늘어나면 어떻게 되는가?
3. 재시도(retries), 검토(review), 에스컬레이션(escalation)이 비용을 추가하는 지점은 어디인가?

컨텍스트 (Context)

1. 어떤 프롬프트(prompt) 내용이 반복되는가?
2. 어떤 내용이 요청(request)마다 변경되는가?
3. 캐시 히트(cache hits)를 측정하고 있는가?

검토 (Review)

1. 영향력이 큰 출력물(high-impact outputs)을 누가 검토하는가?
2. 무엇을 반드시 확인해야 하는가?
3. 무엇이 인간의 소유(human-owned)로 남아야 하는가?

폴백 (Fallback)

1. AI가 작업을 완료할 수 없을 때 어떤 일이 발생하는가?
2. 사용자가 명확한 다음 단계(next step)를 볼 수 있는가?

접근 권한 (Access)

1. AI가 읽을 수 있는 것은 무엇인가?
2. AI가 쓸 수 있는 것은 무엇인가?
3. 어떤 페이지, 흐름(flows), 도구, 데이터가 금지 구역(off limits)인가?

무엇이 기능을 준비된 상태로 만드는가

AI 기능은 모델이 한 번 작동한다고 해서 준비된 것이 아닙니다.

팀이 다음 사항들을 설명할 수 있을 때 비로소 준비에 가까워집니다:

• 사용자 작업 (user task)
• 모델 경로 (model path)
• 워크플로우 비용 (workflow cost)
• 검토 지점 (review point)
• 폴백 동작 (fallback behavior)
• 접근 규칙 (access rules)
• 그리고 성공 지표 (success metric)

이것이 바로 AI 데모를 제품 워크플로우(product workflow)로 전환하는 핵심입니다.

가장 강력한 AI 기능은 흔히 가장 인상적인 모델 라벨을 가진 기능이 아닙니다.

고객이 실제 생활에서 사용할 때도 계속해서 작동하는 기능입니다.

출처 (Sources)

출처 (Sources)

• OpenAI: Previewing GPT-5.6 Sol
• OpenAI API Docs: Prompt caching
• GitHub Changelog: Copilot Agent is now available in JetBrains AI Assistant
• GitHub Changelog: Per-user AI credit budgets available for cost centers
• Cloudflare: Your site, your rules, new AI traffic options for all customers
• Cloudflare: Unmasking the crawls with Attribution Business Insights