*이 장을 다 읽고 나면 알게 될 것: Agent 시스템이 PoC에서 운영으로 가는 네 단계, 각 단계의 통과 조건, 대부분의 프로젝트가 죽는 Death Valley의 정체, 그리고 "빠르게 실패하라"가 실제로 의미하는 것*
도입: 데모는 성공했다, 그 다음이 문제였다
2023년 겨울. 서울의 한 중견 제조업체 회의실이었다. 프로젝트 팀이 자체 개발한 Agent를 시연하고 있었다. 품질 검사 보고서를 자동 생성하는 시스템이었다. 사용자가 질문을 입력하면, Agent가 과거 검사 데이터를 검색하고, 패턴을 분석하고, 보고서 초안을 만들어냈다. 3분 만에. 사람이 하면 반나절 걸리는 일이었다.
회의실에서 박수가 나왔다. CTO가 말했다. "대단합니다. 언제 전사 도입할 수 있습니까?"
프로젝트 매니저가 대답했다. "3개월이면 됩니다."
나는 그 자리에 컨설턴트로 앉아 있었다. 속으로 생각했다. 3개월은 안 된다.
6개월 뒤, 나는 같은 회의실에 다시 앉아 있었다. 시스템은 아직 시범 운영 중이었다. 데이터 품질 문제가 터졌다. 현업 담당자들이 기존 방식으로 돌아갔다. 보안팀이 클라우드 API 호출을 문제 삼았다. 프로젝트 매니저는 지쳐 있었다.
데모는 완벽했다. 그러나 데모와 운영은 다른 세계다. 좋은 데모를 만드는 것과 좋은 운영 시스템을 만드는 것은 전혀 다른 역량을 요구한다. 그리고 그 사이에 대부분의 프로젝트가 죽는다.
나는 데이터 분석 기반 컨설팅을 하면서 이 패턴을 수도 없이 봤다. ERP 때도 그랬고, 빅데이터 때도 그랬고, AI Agent 때도 그렇다. 기술은 바뀌어도 실패의 구조는 같다. 그래서 로드맵이 필요하다. 경험에서 나온, 현실적인 로드맵이 말이다.
24.1 네 개의 문 — PoC, Pilot, Production, Scale
구현 로드맵은 네 단계로 나뉜다. PoC, Pilot, Production, Scale. 각 단계 사이에는 문이 있다. 그 문을 통과하려면 조건을 충족해야 한다. 조건을 충족하지 못하면 다음 단계로 가면 안 된다.
많은 조직이 이 문을 무시한다. 데모가 잘 되니까 바로 전사 도입을 시도한다. 또는 Pilot이 어중간하게 돌아가는데도 Production으로 올린다. 그러면 십중팔구 실패한다. 문을 건너뛰는 것은 시간을 절약하는 것이 아니라 낭비하는 것이다.
각 단계의 핵심을 정리하면 이렇다.
PoC (0~90일). 개념증명이다. "이 과제에 Agent가 작동하는가?"를 확인한다. 작은 범위, 제한된 데이터, 소수의 사용자. 핵심은 가능성을 확인하는 것이다. 완성도가 아니다.
Pilot (90~180일). 시범 운영이다. "현업에서 실제로 쓸 수 있는가?"를 확인한다. 실제 데이터, 실제 사용자, 실제 업무 흐름. 핵심은 현실을 드러내는 것이다. 숨기는 것이 아니다.
Production (180일~1년). 운영 전환이다. "안정적으로 돌아가는가?"를 확인한다. 모니터링, 장애 대응, 거버넌스, 보안. 핵심은 시스템을 조직의 일부로 만드는 것이다.
Scale (1년 이후). 확장이다. "다른 과제로 넓힐 수 있는가?"를 확인한다. 아키텍처 재활용, 팀 역량 전파, 조직 학습. 핵심은 한 과제의 경험을 조직 전체의 자산으로 바꾸는 것이다.
이 네 단계는 직선이 아니다. 뒤로 돌아갈 수 있다. PoC에서 가능성이 안 보이면 과제를 바꿔야 한다. Pilot에서 현업 거부가 심하면 PoC로 돌아가 범위를 재설정해야 한다. Production에서 성능이 안 나오면 아키텍처를 다시 봐야 한다. 되돌아가는 것은 실패가 아니다. 되돌아가야 할 때 안 돌아가는 것이 실패다.
잠시 멈추고 생각해보자
당신의 조직에서 진행 중인 AI 프로젝트는 지금 네 단계 중 어디에 있는가? 다음 단계로 넘어가기 위한 조건은 명확하게 정의되어 있는가?
24.2 Phase 1: 첫 90일 — 현실을 드러내는 시간
첫 90일의 목표는 단순하다. "이것이 작동하는가?"를 확인하는 것이다. 멋진 시스템을 만드는 것이 아니다. 가능성을 확인하는 것이다.
90일을 다시 세 구간으로 나눈다.
1~30일: 과제 선정과 팀 구성.
19장에서 다룬 RAPIDS 프레임워크로 과제를 고른다. 이미 골랐다면, 범위를 좁힌다. PoC의 범위는 작을수록 좋다. "전사 품질 관리 자동화"가 아니라 "A공장 B라인의 일일 품질 검사 보고서 자동 생성"이다. 이 정도로 좁혀야 한다.
팀은 최소 구성으로 시작한다. AI 엔지니어 1~2명, 현업 담당자 1명, 프로젝트 리더 1명. 4명이면 충분하다. 여기서 가장 중요한 사람은 AI 엔지니어가 아니다. 현업 담당자다. 현업이 빠진 PoC는 기술 실험이지 사업 검증이 아니다.
31~60일: 데이터 준비와 아키텍처 초안.
데이터가 가장 큰 변수다. 많은 프로젝트가 여기서 멈춘다. "데이터가 있다"와 "쓸 수 있는 데이터가 있다"는 완전히 다른 말이다. 데이터가 흩어져 있고, 형식이 제각각이고, 품질이 들쭉날쭉한 것이 현실이다. 이 현실을 첫 90일 안에 드러내야 한다.
아키텍처는 20장의 9-node GoT에서 출발하되, PoC에서는 3~4개 노드로 시작한다. Intake, Retriever, Generator, Router 정도면 된다. 나머지는 Pilot에서 추가한다.
61~90일: 첫 PoC 개발과 시연.
최소 기능 Agent를 만든다. 완성도는 60~70%면 충분하다. 핵심은 "이 과제에서 Agent가 가치를 만들 수 있는가"를 보여주는 것이다. UI는 없어도 된다. 노트북이나 커맨드라인으로 충분하다.
시연 자리에서 보여줘야 하는 것은 세 가지다. 첫째, Agent가 무엇을 하는가. 둘째, 사람이 같은 일을 하면 얼마나 걸리는가. 셋째, Agent가 틀리는 경우는 어떤 경우인가. 세 번째가 가장 중요하다. 강점만 보여주는 데모는 의심을 산다. 약점까지 보여주는 데모가 신뢰를 얻는다.
Phase 1 게이트 — 통과 조건
Phase 1을 마치고 Phase 2로 가려면, 다음 다섯 가지를 확인해야 한다.
하나. Agent가 해당 과제에서 측정 가능한 가치를 보여주었는가. 시간 단축이든, 품질 향상이든, 비용 절감이든. 감으로 "좋아 보인다"가 아니라 숫자로 말할 수 있어야 한다.
둘. 데이터의 현실이 드러났는가. 어떤 데이터가 있고, 어떤 데이터가 없고, 어떤 데이터의 품질이 문제인지 파악했는가.
셋. 현업 담당자가 "이것이 내 업무에 쓸 만하다"고 말했는가. 기술팀의 흥분이 아니라 현업의 공감이 있어야 한다.
넷. 주요 리스크가 식별되었는가. 보안, 비용, 정확도, 법적 이슈 등.
다섯. 경영진 스폰서가 Pilot 진행을 승인했는가.
다섯 중 하나라도 불충분하면 멈춘다. 멈추는 것이 부끄러운 일이 아니다. 계속 가는 것이 더 위험하다.
잠시 멈추고 생각해보자
당신이 마지막으로 참여한 기술 프로젝트에서, PoC와 Pilot의 경계가 명확했는가? 만약 경계가 없었다면, 그것이 이후 진행에 어떤 영향을 미쳤는가?
24.3 Phase 2: 90일에서 180일 — Pilot, 현실과 부딪히는 시간
PoC가 실험실이라면, Pilot은 현장이다. 실험실에서 잘 돌아간 것이 현장에서 안 돌아가는 경우가 많다. 그것을 발견하는 것이 Pilot의 목적이다.
Pilot의 핵심은 세 가지다.
첫째, 실제 사용자가 실제 업무에서 쓴다.
PoC에서는 기술팀이 시나리오를 정해서 테스트했다. Pilot에서는 현업 담당자가 자기 업무에서 직접 쓴다. 여기서 온갖 문제가 터진다. "이 경우는 어떻게 하지?" "내 데이터 형식이 다른데?" "결과가 이상한데 누구한테 말하지?" 이런 질문이 쏟아진다.
이 질문들이 보물이다. PoC에서는 보이지 않았던 현실이 Pilot에서 드러난다. 이 현실을 무시하면 Production에서 더 큰 문제가 된다. 이 현실을 직시하면 시스템이 강해진다.
현업 피드백을 수집하는 체계가 필요하다. 주 1회 피드백 미팅. 사용 로그 분석. 불만과 제안을 기록하는 채널. 이것들을 처음부터 설계해야 한다.
둘째, 아키텍처를 보강한다.
PoC에서 3~4개였던 노드를 필요에 따라 늘린다. Analyzer, Critic, Refiner가 추가될 수 있다. 데이터 파이프라인을 안정화한다. 에러 처리를 넣는다. 로깅을 붙인다. 24장에서 다룰 AgentOps의 기초가 여기서 시작된다.
셋째, 운영의 씨앗을 심는다.
Pilot은 기술 프로젝트이면서 동시에 조직 변화 프로젝트다. 사용자 교육이 필요하다. 업무 프로세스가 바뀐다. 역할이 재정의된다. 이 변화를 관리하지 않으면, 기술이 아무리 좋아도 현업이 거부한다. "전에 하던 방식이 더 편해요." 이 말이 나오면 Pilot은 실패다.
Pilot에서 가장 흔한 세 가지 함정
첫 번째 함정. "데모 시나리오만 잘 돌아가는" 시스템. PoC에서 미리 준비한 데이터로는 잘 되는데, 현업의 실제 데이터를 넣으면 무너진다. 데이터 전처리가 부족하거나, 엣지 케이스를 처리하지 못한 것이다.
두 번째 함정. 현업 챔피언의 부재. 현업 부서에서 이 시스템을 자기 것으로 여기는 사람이 없으면, 아무도 문제를 제보하지 않는다. 조용히 안 쓰고 끝이다.
세 번째 함정. Pilot 기간의 무한 연장. "조금만 더 다듬으면 될 것 같은데"가 반복된다. 3개월이 6개월이 되고, 6개월이 1년이 된다. 이것이 바로 Pilot purgatory다. 시범사업의 연옥. 영원히 시범이고, 영원히 본격이 아닌 상태.
Pilot purgatory를 벗어나는 방법은 하나다. 처음부터 Pilot의 종료 조건과 기간을 정해놓는 것이다. 90일. 90일 안에 통과 조건을 충족하면 Production으로 간다. 충족하지 못하면 과제를 재검토하거나, 범위를 줄이거나, 중단한다.
Phase 2 게이트 — 통과 조건
하나. 실제 사용자가 2주 이상 연속으로 사용했는가.
둘. 핵심 성능 지표(정확도, 처리 시간, 사용자 만족도)가 목표치의 80% 이상인가.
셋. 에러와 장애에 대한 대응 프로세스가 정의되어 있는가.
넷. 운영에 필요한 인력과 비용이 산출되었는가.
다섯. 현업 부서장이 Production 전환에 동의했는가.
24.4 Death Valley — 대부분의 프로젝트가 죽는 곳
PoC에서 Pilot으로, Pilot에서 Production으로 넘어가는 구간. 이 두 번의 전환 사이에 Death Valley가 있다. 특히 Pilot에서 Production 사이가 가장 위험하다.
가트너의 2025년 보고서에 따르면, 기업 AI 프로젝트의 약 절반 이상이 Pilot 단계를 넘기지 못한다. 맥킨지도 비슷한 숫자를 내놓았다. 구체적 수치는 조사 방법에 따라 다르지만, 방향은 일치한다. 대부분의 프로젝트는 데모까지는 간다. 운영까지 가는 것은 소수다.
왜 그런가. 이유는 기술이 아니다. 조직이다.
첫 번째 이유. PoC와 Production은 다른 역량을 요구한다. PoC는 프로토타이핑 역량이다. 빠르게 만들고, 빠르게 보여주고, 빠르게 수정한다. Production은 엔지니어링 역량이다. 안정성, 확장성, 보안, 모니터링. PoC를 잘 만드는 사람과 Production을 잘 만드는 사람은 종종 다른 사람이다.
두 번째 이유. 경영진의 관심이 식는다. 데모 때 박수를 쳤던 경영진이, 6개월 뒤에는 다른 주제에 관심이 옮겨간다. 예산이 줄고, 인력이 빠진다. Pilot이 버텨내지 못한다.
세 번째 이유. 조직의 저항이 본격화된다. PoC는 위협적이지 않다. 실험이니까. 그러나 Production은 위협적이다. 업무가 바뀌니까. 누군가의 역할이 사라지니까. 이 저항은 보이지 않는 곳에서 작동한다. 데이터를 안 준다. 피드백을 안 한다. 회의에 안 나온다.
Death Valley를 건너는 방법은 세 가지다.
하나. 경영진 스폰서를 확보하고 유지한다. 확보하는 것보다 유지하는 것이 더 어렵다. 정기적으로 진행 상황과 성과를 보고해야 한다. 숫자로.
둘. 현업 챔피언을 키운다. IT 부서가 밀어넣는 것이 아니라, 현업 부서가 끌어오는 구조를 만든다. 현업에서 "이거 없으면 불편하다"고 말하게 만들어야 한다.
셋. 작게 성공한다. 한 부서, 한 업무, 한 팀에서 확실한 성과를 만든다. 그 성과가 다른 부서의 관심을 끈다. 풀(pull) 방식이다. 밀어넣는(push) 것보다 훨씬 효과적이다.
잠시 멈추고 생각해보자
"빠르게 실패하라(Fail Fast)"는 실리콘밸리의 유명한 격언이다. 그런데 한국 기업에서 이 말은 종종 오해된다. 빠르게 실패하라는 것은 무모하게 덤비라는 뜻이 아니다. PoC 단계에서 가능성이 없는 과제를 빠르게 걸러내라는 뜻이다. 당신의 조직에서 "빠른 실패"는 허용되는가, 처벌되는가?
24.5 Phase 3: 180일에서 1년 — Production, 시스템이 조직의 일부가 되는 시간
Pilot을 통과했다면, 이제 Production이다. 여기서부터 Agent는 실험이 아니라 업무 시스템이다. 이 차이는 크다.
실험은 멈출 수 있다. 업무 시스템은 멈추면 안 된다. 실험은 틀려도 된다. 업무 시스템은 틀리면 영향이 크다. 실험은 만든 사람만 아는 것이어도 된다. 업무 시스템은 만든 사람이 없어도 돌아가야 한다.
이 전환을 위해 세 가지를 구축해야 한다.
첫째, 운영 체계.
모니터링이 핵심이다. Agent가 지금 정상인지, 응답 시간이 느려지고 있는지, 에러율이 올라가고 있는지를 실시간으로 봐야 한다. 24장에서 다룰 AgentOps가 여기서 본격 가동된다. MLflow로 모델 성능을 추적하고, 로그를 분석하고, 알림을 설정한다.
장애 대응 프로세스도 필요하다. Agent가 이상한 답을 내면 누가 확인하는가. LLM API가 다운되면 대안은 무엇인가. 데이터 소스가 바뀌면 어떻게 대응하는가. 이런 시나리오를 미리 정의하고 담당자를 지정해야 한다.
둘째, 거버넌스.
25장에서 상세히 다루겠지만, Production 전환 시점에 최소한의 거버넌스는 갖춰야 한다. 누가 Agent의 프롬프트를 수정할 수 있는가. 누가 데이터 접근 권한을 가지는가. Agent의 판단에 이의가 있으면 어떻게 처리하는가. 이 규칙이 없으면 혼란이 온다.
셋째, 지식 이전.
만든 사람만 아는 시스템은 위험하다. 문서화가 필요하다. 아키텍처 문서, 운영 매뉴얼, 트러블슈팅 가이드. 그리고 만든 사람이 아닌 사람이 운영할 수 있도록 인수인계해야 한다.
나의 시스템에서 나는 이 교훈을 직접 배웠다. Article Lingua를 처음 만들 때, 모든 것이 내 머릿속에 있었다. 그러다 한 번 출장을 다녀오는 사이에 시스템에 문제가 생겼다. 아무도 고칠 수 없었다. 그때 깨달았다. 운영 가능한 시스템은 만든 사람이 없어도 돌아가는 시스템이다. 그 뒤로 코드보다 운영 문서를 먼저 만들기 시작했다.
Phase 3 게이트 — 통과 조건
하나. 시스템이 2주 이상 무중단으로 운영되었는가.
둘. 모니터링 대시보드가 가동 중이며, 주요 지표의 임계값과 알림이 설정되어 있는가.
셋. 장애 대응 프로세스가 문서화되어 있고, 1회 이상 실제로 작동했는가.
넷. 운영 담당자가 지정되어 있고, 개발자 없이 일상 운영이 가능한가.
다섯. 거버넌스 규칙(접근 권한, 변경 관리, 이의 처리)이 문서화되어 있는가.
24.6 Phase 4: 1년 이후 — Scale, 조직의 역량이 되는 시간
한 과제에서 Production까지 갔다면, 이제 진짜 질문이 시작된다. "이 경험을 다른 과제에도 쓸 수 있는가?"
Scale은 단순한 복제가 아니다. 첫 번째 과제에서 만든 아키텍처, 데이터 파이프라인, 운영 체계, 팀의 노하우를 재활용해서 두 번째, 세 번째 과제를 더 빠르게, 더 싸게, 더 잘 만드는 것이다.
여기서 18장의 Composite AI Framework가 빛을 발한다. 프레임워크가 있으면 두 번째 과제부터는 처음부터 다시 시작하지 않는다. 아키텍처 패턴이 있다. 데이터 파이프라인의 뼈대가 있다. 운영 체계의 틀이 있다. 새로운 것은 과제의 고유한 부분뿐이다.
나의 시스템에서의 경험이 정확히 이랬다. 첫 시스템인 Article Lingua는 PoC부터 안정 운영까지 약 4개월이 걸렸다. 두 번째 시스템인 SAF는 2개월. LangGraph 기반 아키텍처를 재활용했기 때문이다. 세 번째인 KVIC는 6주. 단순 비교는 불가능하지만 방향은 분명했다. 프레임워크가 축적될수록 다음 프로젝트는 빨라진다.
Scale 단계에서 해야 할 일은 네 가지다.
하나. 재활용 가능한 자산을 정리한다. 아키텍처 템플릿, 공통 노드 라이브러리, 데이터 커넥터, 프롬프트 템플릿, 평가 지표 세트. 이런 것들을 정리하면 다음 과제의 시작점이 높아진다.
둘. 팀 역량을 전파한다. 첫 과제를 만든 팀의 노하우를 다른 팀에 전달한다. 교육, 페어 프로그래밍, 내부 세미나, 사례 공유. 이것이 없으면 모든 팀이 처음부터 시행착오를 반복한다.
셋. 과제 포트폴리오를 관리한다. 한 과제만 하면 위험이 집중된다. 여러 과제를 동시에 진행하되, 각각의 단계를 관리한다. 어떤 과제는 PoC, 어떤 과제는 Pilot, 어떤 과제는 Production. 이 포트폴리오를 전체적으로 보는 시각이 필요하다.
넷. 조직 구조를 조정한다. Agent가 한두 개일 때는 기존 조직에서 처리할 수 있다. 다섯 개, 열 개가 되면 전담 조직이 필요하다. CoE(Center of Excellence)든, AI 팩토리든, 이름은 중요하지 않다. 중요한 것은 Agent 시스템을 만들고 운영하는 역량이 조직 안에 영구적으로 자리 잡는 것이다.
잠시 멈추고 생각해보자
당신의 조직에서 첫 번째 AI 프로젝트의 경험이 두 번째 프로젝트에 제대로 전달되었는가? 만약 전달되지 않았다면, 그 이유는 사람의 문제인가 구조의 문제인가?
24.7 "빠르게 실패하라"의 진짜 의미
실리콘밸리에서 온 이 격언은 한국에서 가장 많이 인용되면서 가장 많이 오해되는 말이다.
"빠르게 실패하라"는 무모하게 덤비라는 뜻이 아니다. 실패해도 괜찮다는 위로의 말도 아니다. 이것의 진짜 의미는 이렇다. 가능한 한 빨리, 가능한 한 적은 비용으로, 이 과제가 될 것인지 안 될 것인지를 확인하라.
PoC 단계에서 90일 안에 가능성을 확인하는 것. 이것이 "빠르게 실패하라"의 실천이다. 90일 안에 안 되면 과제를 바꾼다. 부끄러운 일이 아니다. 90일의 비용으로 1년의 낭비를 막은 것이다.
반대로 "빠르게 실패하라"를 핑계로 충분한 준비 없이 Production으로 돌진하는 것. 이것은 빠른 실패가 아니라 빠른 재앙이다. PoC에서 빠르게 실패하는 것은 좋다. Production에서 빠르게 실패하는 것은 나쁘다.
각 단계마다 빠름의 의미가 다르다. PoC는 빠를수록 좋다. 완성도를 낮추고 속도를 높인다. Pilot은 적당히 빠르되, 현실을 충분히 흡수해야 한다. Production은 빠를 필요가 없다. 안정적이어야 한다. 속도의 기어를 단계마다 바꿔야 한다.
빠를 때와 느릴 때를 아는 것. 이것이 좋은 로드맵의 핵심이다.
24.8 전체 로드맵 요약 — 한눈에 보기
네 단계를 다시 한번 정리한다.
Phase 1 (0~90일) — PoC. 과제 선정, 팀 구성, 데이터 현실 파악, 최소 Agent, 가능성 확인.
Phase 2 (90~180일) — Pilot. 실제 사용자와 실제 데이터로 검증, 아키텍처 보강, 현업 피드백 수집.
Phase 3 (180일~1년) — Production. 모니터링, 장애 대응, 거버넌스, 지식 이전, 시스템의 조직 편입.
Phase 4 (1년 이후) — Scale. 자산 정리, 역량 전파, 포트폴리오 관리, 프레임워크의 축적.
이 타임라인은 절대적인 것이 아니다. 과제의 복잡도, 조직의 성숙도, 팀의 역량에 따라 달라진다. 작은 과제는 더 빠를 수 있고, 큰 과제는 더 느릴 수 있다. 그러나 네 단계의 순서와, 각 단계 사이의 게이트는 바뀌지 않는다. 단계를 건너뛰는 것은 시간을 절약하는 것이 아니다.
핵심 정리
Agent 시스템의 구현은 네 단계를 따른다. PoC, Pilot, Production, Scale. 각 단계는 고유한 목적이 있고, 다음 단계로 넘어가려면 명확한 통과 조건을 충족해야 한다.
첫 90일은 현실을 드러내는 시간이다. "이것이 작동하는가"를 확인한다. 완성도가 아니라 가능성이 핵심이다. 데이터의 현실, 현업의 반응, 기술적 가능성을 빠르게 파악한다.
90일에서 180일은 Pilot이다. 실제 사용자가 실제 업무에서 쓴다. 여기서 PoC에서는 보이지 않았던 현실이 터진다. 이 현실이 보물이다. Pilot purgatory에 빠지지 않으려면 종료 조건과 기간을 처음부터 정해야 한다.
대부분의 프로젝트는 Pilot에서 Production 사이의 Death Valley에서 죽는다. 이유는 기술이 아니라 조직이다. 경영진 스폰서 유지, 현업 챔피언 육성, 작은 성공의 축적이 Death Valley를 건너는 방법이다.
Production은 안정성의 시간이다. 모니터링, 장애 대응, 거버넌스, 지식 이전. 만든 사람이 없어도 돌아가는 시스템을 만드는 것이 목표다.
Scale은 한 과제의 경험을 조직 전체의 자산으로 바꾸는 단계다. 프레임워크가 축적될수록 다음 프로젝트는 빨라진다. 이것이 Composite AI Framework의 실전적 가치다.
"빠르게 실패하라"는 PoC에서 빠르게 걸러내라는 뜻이지, Production에서 무모하게 돌진하라는 뜻이 아니다. 속도의 기어를 단계마다 바꿔야 한다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신의 조직에서 진행 중인 AI 프로젝트를 네 단계에 매핑해보라. 각 단계의 통과 조건 중 충족된 것은 무엇이고, 미충족인 것은 무엇인가?
질문 2. 당신의 조직에 Death Valley를 건너본 경험이 있는가? 있다면 무엇이 결정적이었는가? 경영진 스폰서였는가, 현업 챔피언이었는가, 기술적 돌파였는가?
질문 3. 첫 번째 프로젝트의 아키텍처와 노하우가 두 번째 프로젝트에 전달되었는가? 전달되지 않았다면, 그 원인은 문서화의 부족인가, 사람의 이동인가, 과제의 이질성인가?
질문 4. 당신의 조직에서 "빠르게 실패하라"는 말이 실제로 허용되는가? PoC를 중단하겠다고 말했을 때 조직의 반응은 어떠한가? 그 반응이 다음 프로젝트에 어떤 영향을 미치는가?
질문 5. 만약 지금 첫 Agent 프로젝트를 시작한다면, Phase 1의 30일을 어떻게 보내겠는가? 과제는 무엇이고, 팀은 누구로 구성하겠는가?
더 깊이 탐구하기
맥킨지, "The State of AI in 2025" 보고서. 기업 AI 프로젝트의 성공률과 실패 원인에 대한 가장 포괄적인 서베이.
마틴 파울러, "Building Evolutionary Architectures" (2017). 시스템을 단계적으로 진화시키는 아키텍처 설계의 고전. PoC에서 Production으로의 전환을 설계할 때 참고할 만하다.
에릭 리스, "The Lean Startup" (2011). "빠르게 실패하라"의 원전. MVP와 검증 루프 개념이 Agent 프로젝트에도 그대로 적용된다.
가트너, "Hype Cycle for Artificial Intelligence, 2025." AI 기술별 성숙도와 기업 도입 현황. Death Valley의 위치를 가늠하는 데 도움이 된다.
나의 시스템 Composite AI Framework 운영 가이드 (2025). Article Lingua, SAF, KVIC의 구현 타임라인과 단계별 체크리스트를 정리한 내부 문서.
다음 장에서는 Agent가 운영에 들어간 뒤의 이야기를 다룬다. AgentOps — 관찰하고, 평가하고, 개선하는 순환. 만드는 것보다 운영하는 것이 더 어렵다. 그리고 더 중요하다.