PoC (Proof of Concept)에서는 상정한 방식으로 시스템이 작동함을 보여줄 수 있습니다. 하지만 본방 전개(Production Deployment)에서는 다른 질문이 전면에 떠오릅니다.

본방 가동 후, 그 시스템에는 누가 책임을 지는가.

그 답에 따라 릴리스 후에 해당 시스템을 운용할 수 있을지가 결정됩니다.

그 이유는 이 역할이 고객의 업무 흐름(Workflow)과 본방 구현(Production Implementation) 사이에 위치하기 때문입니다.

OpenAI의 Forward Deployed Engineer 직무 기술서에서는 이 역할을 고객을 위한 본방 배포(Production Deployment)를 중심으로 설명하고 있습니다. 구체적으로는 디스커버리(Discovery), 기술 스코프 정리, 시스템 설계, 구축, 본방 전개, 본방 환경에서의 정착, 업무 흐름에 미치는 영향, 현장의 피드백을 프로덕트나 모델의 로드맵으로 되돌리는 것이 포함됩니다.

여기서 본방 이후의 책임 경계가 보입니다. 장기적인 책임 주체는 고객 IT 부문, 업무 부문, 서포트, 프로덕트 오퍼레이션(Product Operations), 또는 플랫폼 팀일 수 있습니다. 본방 전개 전 시점에서는 어떤 책임이 아직 할당되지 않았는지를 FDE가 가장 명확하게 보고 있는 경우가 많습니다.

따라서 FDE는 본방 전개 전에 책임 경계를 가시화할 수 있도록 도울 수 있습니다. 이를 통해 고객, 벤더, 프로젝트 관계자는 본방 이후의 각 책임을 어느 팀이 맡을지 결정할 수 있습니다.

이 경계에서는 릴리스 후에 누가 시그널(Signal)을 보고, 무언가 변화했을 때 첫 번째 판단을 내릴지를 결정합니다.

실무적인 모니터링 계획은 3가지 계층을 대상으로 합니다.

계층	시그널
기본 동작	가용성, 레이턴시 (Latency), 에러 (Error), 트래픽 (Traffic), 비용 등
...

기본 동작은 서비스의 건전성을 나타냅니다. Google의 SRE(Site Reliability Engineering) 모니터링 장에서는 이 계층에 대해 최소한으로 확인해야 할 범위로서, 증상과 원인을 분리할 것, 레이턴시, 트래픽, 에러, 포화 상태(Saturation)를 확인할 것, 대응으로 이어지지 않는 알람(Alert)을 피할 것을 제시하고 있습니다. AI 도입에서는 서비스 건전성 시그널로 알 수 있는 것은 시스템의 가동 상태입니다. 답변 품질, 정보원의 최신성, 툴 호출(Tool Call)의 정확성, 사용자 신뢰는 별도로 확인해야 합니다.

AI의 거동은 답변과 업무 흐름의 품질을 나타냅니다. 기본 동작이 정상이라도 AI의 거동은 틀릴 수 있습니다. 예를 들어, 서버는 살아있는데 답변이 틀리거나, API는 정상적으로 응답하고 있는데 취득된 문서가 오래되었거나, 툴 호출은 성공했는데 파라미터(Parameter)가 틀렸거나, 서비스는 이용 가능한 상태인데 사용자가 출력을 신뢰하지 않게 되는 경우 등입니다.

업무 리스크는 그 이용이 조직에 있어 안전하고 유용한 상태를 유지하고 있는지를 나타냅니다. 예를 들어, 사내 서포트 어시스턴트가 직원이 오래된 사내 정책에 기반한 답변에 의존하게 하거나, 답변이 민감한 정보를 노출하거나, 사용자가 어시스턴트를 우회하거나, 또는 팀이 출력을 신뢰하지 못해 수작업 확인을 계속하게 되는 경우 업무 리스크가 됩니다.

시그널은 애플리케이션 로그, 모델 호출 기록, 검색 결과, 툴 호출 트레이스(Trace), 사용자 피드백, 서포트 티켓, 업무 보고서 등에서 얻을 수 있습니다.

누가 보고 누가 대응할지는 그 시그널이 무엇에 영향을 미치는지, 그리고 조직이 어떻게 나뉘어 있는지에 기반하여 결정해야 합니다.

예를 들어 다음과 같이 정리할 수 있습니다.

• 레이턴시 상승 → 플랫폼, 인프라, 모델 엔드포인트(Endpoint), 또는 연계 팀.
• 검색 품질 저하 → 문서, 권한, 인덱스(Index), 또는 배포 팀.
• 툴 호출 실패 → API, 고객 IT, 연계, 또는 배포 팀.
• 사용자의 수작업 회귀 → 업무 부문, 서포트 팀, 또는 업무 흐름 책임자.

이 경계에서는 시스템에 장애가 발생했을 때 누가 최초 대응을 취할지를 결정합니다.

장애 대응은 누구에게 대응 권한이 있는지를 결정하는 것부터 시작됩니다. Google의 SRE 온콜(On-call) 가이드라인에서는 인수인계, 에스컬레이션(Escalation) 경로, 플레이북(Playbook), 심각도 트리아지(Triage), 완화 대응(Mitigation)을 다루고 있습니다.

장애는 업무에 미치는 영향에 따라 분류합니다.

심각도	예시	초기 대응
낮음	1건의 오답, 동기화 실패, 또는 후속 조치를 동반하지 않는 경미한 업무 흐름(Workflow) 오류	사례를 수집하고 장애를 분류한다.
...

심각도가 높은 장애에서는 명확한 역할 분담이 필요합니다. Google의 인시던트 관리(Incident Management) 장에서는 인시던트 지휘(Incident Command), 실무 작업, 커뮤니케이션, 계획을 구분하고 있습니다. 또한, 대응 책임을 가시화된 상태로 유지하기 위한 일환으로 명확한 인수인계(Handover)를 다룹니다.

심각도 분류가 유용한 경우는 각각의 대응 경로에 팀 또는 역할이 할당되어 있을 때뿐입니다.

Google의 인시던트 관리 가이드에서는 인시던트 대응을 조정(Coordination), 커뮤니케이션(Communication), 운영(Operations) 역할로 나눕니다. 동일한 사고방식은 FDE 프로젝트가 모호한 초동 대응을 피하는 데에도 도움이 됩니다. 즉, 누가 보고를 받는지, 누가 증거를 확인하는지, 누가 가용성(Availability)을 제한할 수 있는지, 또는 롤백(Rollback)을 승인할 수 있는지, 누가 영향을 전달할지를 프로젝트 차원에서 정의해 두어야 합니다.

각 장애 수준에 대해, 운영 환경 배포(Production Deployment) 전에 다음 4가지를 결정합니다.

• 누가 보고를 받는가.
• 누가 최초의 증거를 확인하는가.
• 누가 일시적으로 기능의 가용성을 제한할 수 있는가, 또는 롤백(Rollback)이나 폴백(Fallback)을 승인할 수 있는가.
• 누가 회피책(Workaround) 또는 에스컬레이션(Escalation)을 전달하는가.

이를 통해 초기 대응자가 인시던트 도중에 권한을 추측해야 하는 상황을 방지할 수 있습니다. 심각도가 낮은 문제는 배포 팀 또는 지원 팀에서 대응할 수 있을지도 모릅니다. 심각도가 중간 정도인 문제에서는 영향을 받는 업무 흐름을 좁히기 위해 고객 IT 부서, 업무 부서, 또는 FDE/배포 팀이 필요할 수 있습니다. 심각도가 높은 문제에서는 기능을 중단하는 것, 문제를 에스컬레이션하는 것, 영향을 전달하는 것에 대해 사전에 정의된 권한 경로가 필요합니다.

폴백(Fallback)이란 어시스턴트를 더 안전한 운영 모드로 전환하는 것입니다. 시스템 자체는 사용 가능한 상태로 유지하되, 장애 원인이 파악될 때까지 수행할 수 있는 작업을 줄이는 것입니다.

도구를 사용할 수 있는 AI 에이전트나 어시스턴트의 경우, 폴백(Fallback)은 통상적으로 시스템이 자율적으로 실행할 수 있는 범위를 좁히는 것을 의미합니다. 영향력이 큰 작업에 인간의 승인을 필수화하거나, 리스크가 높은 도구 실행을 비활성화하거나, 업무 흐름을 축소하거나, 또는 읽기 전용/검색 전용 모드로 전환하는 등의 대응이 이에 해당합니다. 이는 OWASP의 AI Agent Security Cheat Sheet과 동일한 보안 개념을 적용한 것입니다. 즉, 최소 권한(Least Privilege), 고위험 작업에 대한 명시적 인가(Explicit Authorization), 그리고 Human-in-the-loop 제어입니다.

흔히 발생하는 폴백(Fallback) 패턴은 다음과 같습니다.

리스크 수준	폴백(Fallback) 패턴	변경되는 사항
답변 품질에 불확실성이 있음	검색 전용 모드로 전환	어시스턴트는 최종 답변을 생성하는 대신 정보원을 표시한다.
...

이 경계에서는 출시 후 어떤 팀이 시스템의 어느 부분을 변경할지를 결정합니다.

모든 문제가 프로덕트의 버그(Bug)인 것은 아닙니다. 문제에 따라 원인이나 대응 대상이 고객 데이터, 업무 흐름 설계, 사용자 교육, 연동, 또는 재사용 가능한 프로덕트에 있을 수 있습니다. 개선은 영향을 받는 부분을 변경할 수 있는 팀으로 문제를 배정하는 것부터 시작됩니다.

운영 환경 배포 후의 보고(Post-deployment report)는 담당 부서가 결정된 다음 액션 아이템(Action Item)으로 이어져야 합니다.

흔히 발생하는 배정 패턴은 다음과 같습니다.

배포 후 문제	배정 대상 팀 또는 역할
답변이 오래된 정보를 사용함	문서 또는 데이터 책임자
...

책임을 지는 팀 또는 역할이 명확해지면, 해당 문제는 추적 가능한 후속 조치 항목으로 만들어야 합니다. 예를 들어 데이터 수정, 업무 흐름 변경, 평가 케이스(Evaluation Case), 런북(Runbook) 업데이트, 프로덕트 백로그(Product Backlog) 항목, 또는 사용자 교육 변경 등이 있습니다.

Google의 SRE 포스트모템(Post-mortem) 가이드에서는 추적 실무에 대해 자세히 설명하고 있습니다. 액션 아이템에는 책임자, 추적 번호, 우선순위, 검증 가능한 완료 상태를 포함해야 한다고 명시되어 있습니다.

인수인계(Handover)란 원래의 FDE 또는 배포 팀이 떠난 후에도 시스템을 운영할 수 있도록, 다음 팀 또는 역할에 충분한 운영 지식을 전달하는 것입니다.

실무적인 인수인계에서는 다음 4가지 질문에 답할 수 있어야 합니다.

• 해당 어시스턴트가 어떤 업무 흐름 (Workflow)을 지원하는가?
• 어떤 업무 흐름 (Workflow)을 지원하지 않는가?
• 어떤 문서, 도구, API, 권한, 프롬프트 (Prompt), 또는 모델 (Model)에 의존하고 있는가?
• 로그 (Log), 폴백 (Fallback) 절차, 롤백 (Rollback) 절차, 에스컬레이션 (Escalation) 경로가 어디에 있는가?

런북 (Runbook)은 일반적인 인수인계 결과물 중 하나입니다. Google의 SRE 온콜 (On-call) 관련 가이드라인에서는 에스컬레이션 (Escalation) 경로와 인시던트 관리 (Incident Management) 절차를 중요한 온콜 (On-call) 리소스로 꼽고 있습니다. FDE 프로젝트에서도 인수인계 후에는 동일한 사고방식이 적용됩니다. 다음 팀은 무엇을 가장 먼저 확인해야 하는지, 그리고 어디로 에스컬레이션 (Escalation)해야 하는지를 알고 있어야 합니다.

다음 팀이 의도된 설계 내용만을 알고 있는 상태라면 인수인계는 완료된 것이 아닙니다. 장애 발생 시 무엇이 일어났는지 재구성할 수 있을 만큼의 증거도 필요합니다.

다음과 같은 보고만으로는 불충분합니다.

"어제 AI가 잘못된 답변을 했습니다."

이 보고만으로는 문제가 원본 문서, 검색 (Retrieval), 프롬프트 (Prompt), 모델 출력 (Model Output), 도구 실행 (Tool Execution), 권한, 또는 사용자의 업무 흐름 (Workflow) 중 어디에서 발생했는지 알 수 없습니다.

유용한 장애 기록은 다음과 같은 경로를 남겨야 합니다.

사용자 요청 (User Request)
→ 검색된 정보원 또는 외부 데이터 (Retrieved Source or External Data)
→ 모델 출력 (Model Output)
...

경로가 가시화되면 팀은 문제를 적절한 곳으로 배분할 수 있습니다. 예를 들어 문서 책임자, 업무 부서, 배포 (Deployment) 팀, 협력 팀, 고객 IT 부서, 또는 프로덕트 (Product) 팀 등이 될 수 있습니다.

증거가 많을수록 진단에 도움이 되지만, 로그 (Log)는 리스크도 동반합니다.

AI 도입 로그 (Log)에는 고객 데이터, 개인정보, 기밀 문서, 사내 업무 규칙, 인증 정보, 프롬프트 (Prompt), 검색된 컨텍스트 (Context), 또는 도구 출력 (Tool Output)이 포함될 수 있습니다. OWASP의 Logging Cheat Sheet에서는 실무적인 로그 기록 규칙을 제시하고 있습니다. 운영 및 보안 용도로 충분한 로그 (Log)를 남기되, 민감한 데이터는 제외하거나 보호하고, 액세스 (Access)를 제한하며, 필요한 보유 기간을 초과하여 로그를 저장하지 않는다는 개념입니다.

FDE 프로젝트에서 실무적인 규칙은 더욱 엄격해집니다. 장애를 설명할 수 있을 만큼의 증거를 남기면서도, 어떤 민감한 데이터가 로그 (Log)에 남을 가능성이 있는지, 누가 액세스 (Access)할 수 있는지, 얼마나 오래 보유할 것인지를 관리하는 것입니다.

Google. “Being On-Call.” Site Reliability Engineering. https://sre.google/sre-book/being-on-call/

Google. “Incident Management Guide.” Google SRE: Practices and Processes. https://sre.google/resources/practices-and-processes/incident-management-guide/

Google. “Managing Incidents.” Site Reliability Engineering. https://sre.google/sre-book/managing-incidents/

Google. “Monitoring Distributed Systems.” Site Reliability Engineering. https://sre.google/sre-book/monitoring-distributed-systems/

Google. “On-Call.” The Site Reliability Workbook. https://sre.google/workbook/on-call/

Google. “Postmortem Culture: Learning from Failure.” The Site Reliability Workbook. https://sre.google/workbook/postmortem-culture/

NIST. “AI Risk Management Framework.” National Institute of Standards and Technology. https://www.nist.gov/itl/ai-risk-management-framework

OpenAI. “Forward Deployed Engineer, Tokyo, Japan.” OpenAI Careers. https://openai.com/careers/forward-deployed-engineer-tokyo-tokyo-japan/

OpenTelemetry. “Generative AI Semantic Conventions.” OpenTelemetry Semantic Conventions. https://opentelemetry.io/docs/specs/semconv/gen-ai/

OWASP. “AI Agent Security Cheat Sheet.” OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

OWASP. “Logging Cheat Sheet.” OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html