AX LABS
← 블로그 AX 전략

5일 PoC는 운영 리허설이다

리더는 데모가 아니라 통제 가능성을 본다

임원 보고용 에이전트 PoC는 대개 첫날부터 잘못 흘러간다. 화면은 매끄럽고 답변은 그럴듯하다. 그런데 회의가 끝나면 아무도 같은 질문에 답하지 못한다. 이 에이전트가 어떤 업무를 맡는가. 어디서 멈추는가. 실패하면 누가 본다. 현업 시스템에 연결하면 어떤 로그가 남는다. 이 질문이 비어 있으면 PoC는 데모로 끝난다.

리더는 모델보다 업무 경계를 먼저 본다

에이전트 PoC의 첫 판정 기준은 모델 성능이 아니다. 업무 경계다. 사람의 일을 일부 넘겨받는 순간, 에이전트는 답변기가 아니라 실행 주체가 된다. 실행 주체에는 권한, 금지선, 예외, 감사 흔적이 붙어야 한다.

최근 12개월의 공식 자료도 같은 방향으로 움직인다. OpenAI는 2026년 Agents SDK에서 harness와 sandbox를 분리해 안전한 실행, 상태 복구, 도구 사용을 다룬다. Anthropic은 2026년 에이전트 평가 글에서 transcript, outcome, evaluation harness, agent harness를 분리해 봐야 한다고 설명한다. 핵심은 하나다. 에이전트는 모델 단품이 아니라 운영 구조다.

5일 PoC의 목적은 “잘한다”를 증명하는 것이 아니다. “운영해도 무너지지 않는다”를 판정하는 것이다.

5일이면 투자 판단에 필요한 신호가 나온다

5일 평가는 완성도를 보지 않는다. 확장 투자 여부를 결정할 신호를 본다. 그래서 일정은 기능 개발 순서가 아니라 리더의 의사결정 순서로 짠다.

일차 리더가 확인할 질문 산출물
1일차 이 에이전트가 맡을 업무와 맡지 않을 업무가 갈리는가 업무 경계표, 중단 조건
2일차 필요한 context, memory, tool 권한이 분리돼 있는가 harness 구조도, 권한 목록
3일차 예외 입력과 지저분한 데이터에서 멈출 줄 아는가 실패 로그, 에스컬레이션 규칙
4일차 결과뿐 아니라 실행 과정이 추적되는가 trace 샘플, outcome 판정표
5일차 확장, 보류, 폐기 중 하나를 결정할 수 있는가 투자 판단 메모, 운영 책임자 지정

이 표에서 빠지면 안 되는 것은 5일차다. 많은 PoC가 4일차까지는 만든다. 5일차 결정을 피한다. 그러면 다음 달에 같은 PoC를 다른 이름으로 다시 한다.

에이전트 평가는 정답률 하나로 끝나지 않는다

리더는 평가표를 단순하게 가져가야 한다. 단순하다는 말은 얕다는 뜻이 아니다. 운영에 필요한 질문만 남긴다는 뜻이다.

첫째, outcome이다. 에이전트가 “처리했습니다”라고 말했는지가 아니라 실제 시스템 상태가 바뀌었는지를 본다. 둘째, trace다. 어떤 도구를 어떤 순서로 불렀고 어디서 비용과 시간이 늘었는지 본다. 셋째, stop rule이다. 자신 없는 상황에서 멈추고 사람에게 넘기는지 본다. 넷째, rollback이다. 잘못 실행했을 때 되돌릴 수 있는지 본다.

여기서 harness engineering이 중요해진다. context engineering, memory 전략, tool orchestration, AgentOps는 개발자의 취향 문제가 아니다. 운영 리스크를 줄이는 경영 설계다. MCP와 A2A 같은 표준도 같은 맥락에서 봐야 한다. 연결이 쉬워질수록 권한과 감사는 더 엄격해야 한다.

참고와 다음 행동도 PoC 안에 넣는다

이 글은 최근 12개월 내 공개된 1차 출처를 기준으로 정리했다.

5일 PoC를 끝내면 세 가지 중 하나만 남겨야 한다. 운영 파일럿으로 확장한다. 업무 경계를 다시 자른다. 폐기한다. 이 결정을 못 내리는 PoC는 이미 실패다. AX LABS는 에이전트 도입을 데모가 아니라 운영 전환의 첫 사이클로 설계한다. AX Ops 방법론 →