AI Agent 파일럿이 프로덕션 전에 실패하는 이유: 빠진 네 계층

결론부터 말하면: 끝내 출시되지 못하는 agent 파일럿은 거의 모델에서 지지 않는다 — 발밑에 네 계층, 즉 시맨틱, 권한, 결재, 감사가 빠져 있기 때문에 진다. 더 강한 모델은 그것을 고치지 못한다. 그 네 계층이 고친다.

그 프로젝트는 시연일에 박수갈채를 받았다.

총괄을 맡은 비즈니스 책임자 천 씨는 또렷이 기억한다. 고객 응대 agent가 현장에서 까다로운 질문 일고여덟 개에 빠르고 정확하게 답했고, 회의실에서는 박수가 나왔다. 임원이 그 자리에서 투자 확대를 결정해 예산과 인력을 줬다. 그것은 그의 직장 생활에서 흔치 않은 하이라이트 순간이었다.

넉 달 뒤, 이 프로젝트는 조용히 종료됐다. 예산은 매몰 비용으로 적혔고, 천 씨가 경영진 마음속에 가진 신뢰도도 한 단계 깎였다.

그것을 죽인 것은 모델이 아니다 — 모델은 줄곧 잘 싸웠다. 법무가 출시 리뷰에서 던진 질문 하나였다. “이 agent가 A 고객에게 답할 때, B 고객의 정보를 함께 쓰지 않는다고 보장할 수 있는가? 당신은 그것이 그러지 못한다는 것을 어떻게 증명하는가?”

아무도 증명하지 못했다. 그것이 반드시 유출하기 때문이 아니라, 시스템 안에 그것을 막거나 사후에 그것이 그랬는지 아닌지 분명히 말할 수 있는 곳이 애초에 없었기 때문이다. 그 순간 천 씨는 깨달았다. 처음부터 끝까지, 문제는 모델에 있지 않았다.

그는 혼자가 아니다. 업계 보고서의 숫자는 서로 다르지만 같은 방향을 가리킨다. 많은 agent 파일럿은 프로덕션 전에 멈추고, 많은 프로젝트는 측정 가능한 수익을 내지 못한 채 끝난다. 이토록 많은 하이라이트 순간이 결국 같은 조용한 결말로 걸어 들어갔다.

더 강한 모델로 바꿔도 왜 안 통하나

이런 성적표를 마주하면 대부분 팀의 첫 반응은 같다. 모델이 충분히 강하지 않다. 그래서 더 큰 모델로 바꾸고, 프롬프트를 더 정교하게 다듬고, 더 복잡한 오케스트레이션을 올린다.

통과율은 크게 움직이지 않는다. 진실이 다른 데이터 묶음에 숨어 있기 때문이다. 파일럿에서 프로덕션까지 필요한 일의 대부분은 데이터 엔지니어링, 거버넌스, 프로세스 통합, 측정이고, 모델 자체는 작은 한 조각만 차지한다. 많은 파일럿은 ‘충분히 똑똑하지 않아서’ 죽는 게 아니라, 모델 발밑에 빠진 몇 계층 때문에 죽는다 — 그리고 그 몇 계층은 아무리 강한 모델로도 메울 수 없다. 그것들은 애초에 모델 쪽에 있지 않기 때문이다.

먼저 PoC로 빠르게 검증하는 게 잘못인가?

여기서 흠잡을 데 없어 보이는 반론 하나를 받아야 한다. 먼저 데모를 만들고 PoC를 돌려 가치를 검증하는 것은 본래 옳은 방식이며, 처음부터 시연을 과도하게 엔지니어링해야 한단 말인가?

PoC 자체는 잘못이 없다. 잘못은 그것이 엉뚱한 것을 검증했다는 데 있다.

천 씨의 그 데모가 검증한 것은 ‘모델이 잘 답하는가’였다 — 그리고 이것이 하필 프로젝트 전체에서 가장 걱정할 필요 없는 부분이다. 그것이 검증하지 않은 것, 검증하지 않도록 설계된 것은, 생사를 진짜로 결정하는 그 네 계층(권한, 기준, 결재, 흔적)이다. 그래서 PoC는 경영진에게 잘못된 자신감을 줬다. 시연이 이렇게 매끄러우니 투자를 확대해도 리스크는 크지 않겠지? 넉 달 뒤에야 모두가 깨달았다. 시연의 매끄러움과 프로덕션의 가능성은 거의 무관하다는 것을.

그러니 올바른 PoC는 ‘모델이 맞게 답하는가’만 물어서는 안 되고, ‘이 답을 권한, 결재, 흔적이 모두 갖춰진 진짜 환경에서 옳은 사람에게 안전하게 인도할 수 있는가’를 더 물어야 한다. 검증 대상을 잘못 잡으면, 화려한 데모일수록 더 깊이 묻힌 함정이 된다.

데모는 본래 그 네 계층이 필요 없다 — 그래서 당신을 속였다

왜 데모의 매끄러움이 프로덕션과 이토록 철저히 동떨어지는가? 좋은 시연은 어떤 거버넌스 문제도 건드리지 않도록 설계되기 때문이다 — 그것은 내보낸 데이터 한 벌을 써서 한 사람에게 보여 주며, ‘이 사용자가 이 줄을 볼 수 있는가’, ‘이 단계는 먼저 결재해야 하는가’를 묻지 않는다.

그래서 잔혹한 따름정리가 있다. 매번 성공한 시연은, 그것이 장차 실패할 원인을 체계적으로 숨긴다. 당신이 본 것이 화려할수록, 숨겨진 그 몇 계층은 더 깊다. 프로덕션 데이터에 연결하는 그 순간 환경은 완전히 바뀌고, 성패를 결정하는 것은 모델 발밑에 이 네 계층이 있는가다.

그것이 반드시 답할 수 있어야 하는 것	빠진 것이 어느 계층인가	빠지면 어떻게 되나
’고객’이 도대체 무엇을 가리키나? 기준은 어디 있나?	① 시맨틱 레이어	동문서답, 기준 충돌, 비즈니스가 인정 안 함
A 고객의 정보가 B 고객에게 쓰이지 않을까?	② 권한 계층	월권 유출, 법무가 거부권 행사
이 단계는 먼저 사람의 결재를 기다려야 하나?	③ 프로세스 및 결재 계층	멈춰야 할 것이 안 멈춤, 아무도 손대게 안 함
이 조작은 누가, 언제, 무엇에 근거해 했나?	④ 감사 계층	증거를 못 냄, 컴플라이언스가 즉시 차단

천 씨의 그 프로젝트는 ②행에서 죽었다.

왜 이 네 계층은 늘 부재하나

그럼 왜 처음부터 잘 지어 두지 않나? 전통적인 방식으로는 각 계층이 한 덩어리의 횡단적인 강성 엔지니어링이기 때문이다. 시맨틱 레이어는 십수 개 시스템의 데이터를 통일된 객체 모델로 정렬해야 한다. 권한 계층은 각 애플리케이션 코드에 흩어진 규칙을 일관된 정책으로 거둬들여야 한다. 결재는 기존 체계에 연결해야 하고, 감사는 사람과 AI의 동작을 같은 한 권의 장부에 모아야 한다. 그것들은 어떤 기능의 일부가 아니라, 모든 기능 밑에 깔리는 기반이다 — 더럽고 느리며, 게다가 전부 시연에서는 보이지 않는 부분이다.

더 나쁜 것은, 많은 팀이 파일럿마다 이 네 계층을 따로 다시 짓는다는 점이다. 이번 라운드가 끝나고 시나리오를 바꾸면, 네 계층을 처음부터 다시 한다. 예산과 인내심이 기반을 거듭 만드는 데 전부 소진된다.

당신의 파일럿이 프로덕션에 갈 수 있는지 판단하는 데 넉 달을 기다릴 필요 없다. 네 계층에 대해 각각 한마디씩 물으면 충분하다.

1. 시맨틱: 다른 사람이 agent에게 같은 비즈니스 질문을 물어도 기준이 일관된가? 아니면 각자 다르게 답하나?
2. 권한: 각 사람이 자기가 볼 권한이 있는 데이터만 보게 한다는 것을 증명할 수 있는가?
3. 결재: 고위험 동작에서 그것이 자동으로 멈춰 사람의 서명을 기다리는가, 곧장 해 버리는가?
4. 감사: 그것이 한 일 아무거나 하나 골라, 그 전 과정을 끄집어낼 수 있는가?

넷 다 ‘예’라고 답할 수 있으면, 프로덕션에 갈 가능성은 크게 올라간다. 하나라도 ‘불확실’이라고 답하면, 그것이 다음 천 씨다.

프로덕션에 가는 팀은 무엇이 다른가

반례 하나를 볼 가치가 있다. 그것과 천 씨의 차이가 하필 모델에 있지 않기 때문이다.

다른 회사가 거의 똑같은 고객 응대 agent를 만들었는데, 쓴 모델은 오히려 좀 더 수수했다. 하지만 그들은 ‘모델이 화려하게 답하게’에서 출발하지 않고, 먼저 네 계층을 통일된 런타임 위에 지었다. 고객, 주문, 작업 지시가 모두 같은 한 벌의 객체였고(시맨틱 갖춤), agent는 질문하는 상담원의 신원으로 행동하며 그 상담원이 볼 권한이 있는 데이터만 볼 수 있었고(권한 갖춤), 환불 초과는 자동으로 사람에게 넘어갔고(결재 갖춤), 모든 동작이 같은 한 권의 장부에 기록됐다(감사 갖춤).

그들의 시연일은 천 씨만큼 화려하지 않았다 — 안정적으로 답했지만 놀랍지는 않았다. 하지만 출시 리뷰에서 법무가 똑같은 그 질문을 던졌을 때, 프로젝트 매니저는 그 자리에서 권한 집합과 감사 기록 한 줄을 끄집어내, agent가 상담원 신원으로 상담원이 볼 권한이 있는 데이터만 볼 수 있고, 월권은 런타임이 즉석에서 차단하고 흔적을 남긴다는 것을 증명했다. 법무가 고개를 끄덕였고, 프로젝트는 통과됐다.

차이는 바로 여기에 있다. 프로덕션에 진입하는 팀은 모델이 이긴 게 아니라, 그 네 계층을 미리 지어 둬서 ‘당신은 어떻게 증명하는가’라는 질문을 견딜 수 있다. 천 씨가 진 것은 기술 함량이 아니라 순서다 — 그는 가장 걱정할 필요 없는 것(모델)을 앞에 놓고, 생사를 진짜로 결정하는 것(네 계층)을 맨 뒤로 미뤘다.

먼저 찬물 한 바가지: 네 계층이 갖춰져도 성공이 보장되지는 않는다

여기서 정직하게 한마디 해야 한다. 그러지 않으면 또 만병통치약이 된다.

또 하나의 반론도 맞다. 많은 파일럿은 변화 관리에서 죽는다 — 사람이 안 쓰고, 프로세스가 안 바뀌고, 조직이 인정 안 한다. 이것은 ‘네 계층이 빠져 죽는다’와 모순되지 않고, 한 일의 양면이다. 법무가 통과를 안 해 주고 비즈니스가 기준을 인정 안 하는 시스템은, 조직에 채택될 입장권조차 얻지 못한다. 그러나 거꾸로, 네 계층이 갖춰진 것은 입장권을 얻은 것일 뿐, 경기에서 이긴 것은 아니다.

기술 준비는 필요조건이지 충분조건이 아니다. 네 계층은 agent의 동작을 통제 가능, 추적 가능, 설명 가능하게 만들어, 조직이 그것을 신뢰하고 채택할 가능성을 연다 — 하지만 진짜 도입하려면, 누군가는 프로세스 변화를 추진해야 하고 누군가는 습관을 바꿀 의향이 있어야 한다. 누군가 “이 네 계층을 채우면 파일럿은 반드시 성공한다”고 한다면 그것은 과잉 약속이다. 그것이 치우는 것은 기술적 사인(死因)이지, 조직적 사인은 치우지 못한다.

출구: 네 계층은 런타임에서 오지, 프로젝트마다 다시 짓지 않는다

성공 확률을 바꾸는 것은 더 강한 모델이 아니라, 이 네 계층을 더 이상 프로젝트마다 자체 구축하는 엔지니어링이 아니라 런타임이 자체적으로 갖춘 능력으로 만드는 것이다.

설비 수리 신청 시나리오를 하나 들어 보자. 당신은 객체와 그 권한만 선언한다.

export const RepairTicket = ObjectSchema.create({
  name: 'ops_repair_ticket',
  label: '수리 신청서',
  fields: {
    device: Field.lookup('ops_device', { label: '설비', required: true }),
    cost: Field.currency({ label: '수리 비용', min: 0 }),
  },
});

나머지 네 계층은 런타임(ObjectOS)이 한 번에 갖춰 준다. 시맨틱 레이어 — 이 선언 자체가 agent가 비즈니스를 이해하는 근거다. 권한 계층 — 누가 수리 신청서를 읽고 쓸 수 있는지를 런타임이 매 호출마다 강제 검증한다. 프로세스 및 결재 계층 — ‘수리 비용 초과 시 결재로’는 객체에 걸린 선언형 프로세스라, 자동으로 일시정지하고 서명을 기다린다. 감사 계층 — 사람과 agent의 매 동작이 같은 한 권의 장부에 기록된다. 다음 시나리오로 바꿔도 이 네 계층을 다시 지을 필요 없이, 객체 몇 개만 더 선언하면 된다. 반복되는 기반 만들기가 수백 줄의 선언으로 눌러졌다.

천 씨의 그 프로젝트가 이렇게 지어졌다면, 법무의 그 질문은 사형 선고가 아니었을 것이다. 그는 그 자리에서 권한 집합을 끄집어내, agent가 질문자의 신원으로 질문자가 볼 권한이 있는 데이터만 볼 수 있음을 증명할 수 있었을 것이다 — ②계층이 본래 발밑에 있었고, 그 자리에서 통과 가능성을 만들 수 있었을 것이다.

맺으며

프로덕션에 진입하는 팀이 기댄 것은 거의 한 번도 가장 좋은 모델만이 아니었다. 기댄 것은 모델 발밑의 그 네 계층 — 시맨틱, 권한, 프로세스, 감사 — 이 든든히 자리한 것, 그리고 조직이 진짜로 그것을 쓰기 시작한 것이다. 전자는 입장권이고 후자는 경기이며, 둘 다 있어야 한다.

그러니 당신의 agent 파일럿이 또 막혔다면, 모델부터 바꾸려 서두르지 마라. 천 씨가 넉 달 뒤에야 물을 줄 알게 된 질문을 물어라. 발밑의 이 네 계층, 도대체 몇 계층이나 지었는가? 이것이 프롬프트를 한 버전 더 다듬는 것보다 훨씬 돈을 아끼고, 프로젝트 하나와 사람 하나의 신뢰도도 구할 수 있다.

npm i -g @objectstack/cli && os start

객체 하나와 그 권한을 선언하고 agent가 그것을 쓰게 해 보라 — 그 네 계층이 이미 발밑에 있고, 당신은 겨우 수십 줄만 썼음을 알게 될 것이다.