사내에서 들어오는 AI 요구를 모아 보면 서로 달라 보이는 요청들이 비슷한 구조로 수렴했다.
- 복잡한 기업 내부 문서를 이해한다.
- 외부의 시장·경쟁사·재무 정보를 결합한다.
- 특정 분석 틀을 적용해 통찰을 만든다.
예를 들어 내부 사업계획, 경쟁사 실적, 시장 데이터를 모아 3C 분석을 만드는 식이다. 분석 대상과 산출물은 달라도 필요한 능력은 상당 부분 겹쳤다. 그렇다면 공통 기능을 재사용 가능한 구성 요소로 만들고, 사용자가 직접 조합하게 하면 되지 않을까?
이 생각은 자연스럽게 플랫폼으로 이어졌다.
가장 아래에는 개발자가 제공하는 도구가 있다. 내부 문서 검색, 웹 검색, 데이터베이스 조회, 파이썬 실행, 외부 API, 금융 데이터, 사내 시스템 연동 같은 기능이다.
그 위에는 사용자가 여러 도구와 작업 지침을 묶어 만드는 모듈이 있다. 예를 들어 내부 검색, 시장 검색, 경쟁사 검색에 분석 지침을 더하면 ‘3C 분석 모듈’이 된다. 모듈은 단순히 저장된 프롬프트가 아니라 특정 목적을 수행하기 위한 재사용 가능한 업무 기능이다.
여러 모듈을 연결하면 에이전트 실행이 된다. 시장 조사 → 경쟁사 분석 → 내부 역량 분석 → 종합처럼 순차 실행할 수도 있고, 전문 에이전트들을 병렬로 실행한 뒤 종합 에이전트가 결과를 합칠 수도 있다.
마지막에는 동적 조정이 있다. 사용자가 복잡한 질문을 입력하면 시스템이 문제를 분해하고, 필요한 모듈과 도구를 찾고, 의존 관계를 판단해 순차·병렬 작업 흐름 또는 다중 에이전트 실행 그래프를 실행 시점에 구성한다.
한 번 만들고, 여러 업무 흐름에 조합한다.
개념적으로 꽤 합리적인 구조였다. 여러 요구를 각각 별도의 애플리케이션으로 만드는 대신, 공통 기능을 한 번 개발하고 다양한 업무에 조합할 수 있었다. 새로운 요구에도 빠르게 대응할 수 있고 사용자에게 일정한 자율성을 줄 수 있었다. 당시 이 선택이 잘못된 것은 아니었다. 다만 실제 운영이 우리에게 아직 알려주지 않은 것이 너무 많았다.
프로토타입이 너무 그럴듯해진 시대
지금은 Claude Code, Cursor, Codex 같은 코딩 에이전트가 파일을 읽고 수정하며, 명령을 실행하고, 테스트를 돌리고, 비교적 큰 작업까지 이어서 수행한다. 각 제품의 공식 설명도 이들을 단순 자동완성이 아니라 복잡한 개발 작업을 수행하는 에이전트로 규정한다. 덕분에 문서를 읽고, 검색하고, 도구를 호출하고, 여러 에이전트를 조정하며, 완성도 높은 화면까지 갖춘 AI 애플리케이션을 며칠 안에 만드는 일이 가능해졌다.
이것은 분명한 기술 진보다. 문제는 성공의 외형도 함께 압축됐다는 데 있다.
이제 프로토타입은 예전의 프로토타입처럼 보이지 않는다. 데모는 실제 데이터를 읽고, 자연어로 계획을 설명하고, 여러 시스템을 오가며, 완성도 높은 화면에 결과를 표시한다. 기술을 직접 만들지 않은 사람의 눈에는 이미 제품처럼 보인다. 경영진이 비합리적이어서가 아니다. 화면에 보이는 신호 대부분이 ‘거의 완성됐다’고 말하기 때문이다.
나는 이것을 프로토타입의 착시라고 부른다.
초기의 눈에 보이는 기능은 아주 빠르게 상승한다. 모델을 연결하고, 프롬프트를 쓰고, 도구 호출을 붙이고, 화면을 다듬으면 짧은 시간 안에 놀라운 결과가 나온다. 하지만 실제 운영 준비도의 곡선은 훨씬 완만하다. 평가, 권한, 보안, 상태 관리, 장애 복구, 지연 시간, 모니터링, 감사, 운영 절차, 그리고 신뢰는 긴 꼬리를 가진다.
그래서 지금의 핵심 문장은 이것이다.
AI 코딩이 줄인 것은 데모 제작 비용이지, 시스템 운영 비용이 아니다.
코딩 에이전트는 구현 비용을 크게 낮춘다. 하지만 그 시스템이 실제 업무에서 매일 같은 수준으로 작동하도록 만드는 비용은 다른 종류의 비용이다. 두 곡선 사이의 간격이 바로 데모와 실제 운영의 간극이다.
어려운 문제는 구조보다 예측 가능성이었다
플랫폼이 실제 운영에 가까워질수록 어려움의 중심은 ‘무엇을 할 수 있는가’에서 ‘어떻게 예측 가능하게 할 것인가’로 이동했다.
예를 들어 도구 선택 하나만 해도 그렇다. 같은 질문인데 왜 어떤 실행에서는 내부 검색을 먼저 하고, 다른 실행에서는 웹 검색부터 시작하는가? 도구 설명을 고치면 선택은 나아지지만 다른 업무의 경로 선택이 망가질 수 있다. 모델 버전이 바뀌면 이전에 안정적이던 경계가 다시 흔들린다.
문제 분해에도 편차가 생긴다. 어떤 실행은 문제를 세 단계로 나누고, 어떤 실행은 일곱 단계로 나눈다. 각각의 하위 작업은 그럴듯해도 순서와 의존 관계가 달라지면 최종 결과가 달라진다. 여기에 맥락 손실과 중간 결과의 환각이 더해진다. 앞 단계의 작은 오류가 다음 에이전트에게 사실처럼 전달되면, 뒤의 에이전트는 잘못된 전제 위에서 더 정교한 결론을 만든다.
연결은 또 다른 문제였다. 모듈 A와 B를 각각 테스트하면 잘 작동하는데, A의 출력을 B의 입력으로 연결하면 품질이 떨어졌다. A의 결과가 사람에게는 충분히 읽히지만 B가 기대하는 입력 형식에는 맞지 않을 수 있다. B가 A의 불확실성을 전달받지 못할 수도 있다. 각 단계의 품질만으로 전체 작업 흐름의 품질을 보장할 수 없었다.
실패 복구는 더 까다롭다.
- 도구 하나가 시간 초과되면 그 단계만 재시도할 것인가, 계획부터 다시 시작할 것인가?
- 부분 재시도 뒤에 이미 생성된 상태를 유지할 것인가, 폐기할 것인가?
- 외부 API 호출이 실제로 실행됐지만 응답만 유실됐다면 재호출해도 되는가?
- 병렬 분기 중 하나가 실패했을 때 나머지 결과로 계속 진행할 것인가?
- 잘못된 중간 답변이 다음 단계로 전파되는 것을 어디에서 차단할 것인가?
여기에 인증, 권한 부여, 기록, 관측 가능성, 결과 검증, 문서 형식의 다양성, API 장애, 모델 변경이 겹친다. 질문 하나에 답하는 데 필요한 자유도를 높일수록 기능은 커지지만 가능한 실패 유형의 조합도 함께 늘어난다.
결국 가장 어려운 질문은 하나였다.
어떻게 해야 에이전트를 예측 가능하게 만들 수 있을까?
우리 시스템은 약 3개월 동안 실제 사용과 실패, 수정의 반복을 거치면서 상당히 안정화됐다. 안정성은 처음 그린 구조에서 나온 것이 아니라, 어떤 실패가 실제로 반복되는지를 알게 된 뒤 추가한 작은 제약과 복구 장치들의 합에서 나왔다.
무엇이 시스템을 끌어올렸나
안정성을 끌어올린 것은 하나의 더 좋은 프롬프트나 더 큰 모델이 아니었다. 반복되는 실패 유형을 하나씩 시스템의 명시적인 책임으로 바꾼 일이었다.
먼저 불필요한 자율성을 줄였다. 모든 질문에서 실행 시점의 계획 수립을 허용하지 않고, 반복 빈도가 높은 업무는 허용된 도구와 실행 경로의 범위를 좁혔다. 사용자가 원하는 결과의 형식이 분명한 경우에는 에이전트가 형식을 새로 결정하게 두지 않았다. 자유도를 줄인 것은 기능의 후퇴가 아니라, 업무에 필요하지 않은 편차를 제거하는 일이었다.
모듈 사이에는 명시적인 계약을 만들었다. 다음 단계가 필요로 하는 항목, 출처, 불확실성, 검증 상태를 구조화해 전달했다. 중간 결과가 조건을 충족하지 못하면 다음 에이전트로 넘기기 전에 중단하거나 보완하도록 했다. “사람이 읽기에 그럴듯한 결과”와 “다음 단계가 안전하게 사용할 수 있는 결과”를 분리한 것이다.
재시도도 단순히 같은 호출을 다시 보내는 기능이 아니었다. 어떤 실패는 해당 단계만 재시도하고, 어떤 실패는 계획부터 다시 해야 하는지 구분했다. 외부 시스템에 부수 효과가 있는 호출에는 멱등성과 실행 상태를 남겼고, 장시간 실행에는 중간 저장 지점을 두어 부분 재시도 뒤에도 상태 일관성을 유지했다.
관측과 평가도 업무 단위로 좁혔다. 각 실행에서 선택한 도구, 문제 분해, 중간 결과, 검증 결과, 지연 시간, 재시도 이유를 함께 추적했다. 모든 질문을 대표한다는 거대한 벤치마크 대신, 실제 업무에서 반복적으로 실패한 사례를 평가 집합에 추가했다. 모델이나 프롬프트, 도구 설명이 바뀔 때는 그 실패 집합이 다시 나타나는지 회귀 테스트로 확인했다.
마지막으로 실패를 숨기지 않도록 사용자 경험을 바꿨다. 근거가 부족하거나 도구가 실패했을 때 억지로 완성된 답처럼 보이게 하지 않고, 무엇이 완료됐고 무엇이 불확실한지 보여주고 필요하면 사람에게 넘겼다. 신뢰성은 항상 성공하는 것만을 뜻하지 않는다. 실패했을 때 예측 가능한 방식으로 멈추고 복구할 수 있는 것도 신뢰성이다.
세 달 뒤 시스템이 나아진 이유는 에이전트가 갑자기 완벽해졌기 때문이 아니었다. 우리가 어떤 자유도를 허용하고, 어떤 상태를 기록하고, 어떤 결과를 통과시키며, 어디에서 사람에게 넘길지를 실제 운영에서 얻은 근거를 바탕으로 더 구체적으로 결정했기 때문이다.
이 경험에서 더 일반적인 교훈도 얻었다. 좁은 업무를 배포하고, 실제 맥락에서 실패를 관찰하고, 실패한 경계나 제어 장치를 고치고, 다음 업무에 재사용 가능한 해결책을 가져가는 피드백 순서가 플랫폼의 모양을 만든다. 플랫폼은 배포 전에 완성되는 청사진이 아니라, 배포를 거치며 누적되는 운영 지식에 가깝다.
사용자는 우리의 구조를 경험하지 않는다
개발자는 시스템이 왜 어려운지 안다. 복잡한 사내 권한을 지키면서 여러 문서 형식을 처리하고, 외부 데이터와 내부 시스템을 연결하며, 긴 작업 흐름의 상태를 유지하는 일이 얼마나 까다로운지 안다.
하지만 사용자는 그 복잡도를 평가하지 않는다. 사용자가 비교하는 것은 다른 사내 시스템이 아니라 ChatGPT와 Claude다.
내부 에이전트가 더 어려운 문제를 다루고 있더라도, 이상한 답을 한 번 내거나, 지나치게 느리거나, 같은 질문의 결과가 크게 달라지거나, 엉뚱한 도구를 선택하거나, 이유를 알 수 없는 행동을 하면 평가는 간단하다.
“아직 잘 안 된다.”
이 평가는 불공정하지 않다. 사용자는 구조도가 아니라 업무 경험을 평가하기 때문이다.
사용자는 아키텍처가 아니라 실패를 경험한다.
기업용 에이전트에는 일반 대화형 서비스보다 많은 제약이 있다. 내부 시스템과 연결돼야 하고, 사용자의 권한을 따라야 하며, 기업 문서를 이해하고, 업무 흐름을 실행해야 한다. 반면 상호작용 품질에 대한 기준은 이미 세계 최고 수준의 소비자용 AI가 만들어 놓았다. 이 둘의 간극을 좁히는 것이 기업용 에이전트 엔지니어링의 상당 부분이다.
수면 아래의 마지막 10%
데모에서 눈에 띄는 것은 모델, 프롬프트, 도구 호출, 검색, 에이전트의 추론, 여러 에이전트의 협업, 화면이다. 이 요소들이 실제로 중요하지 않다는 뜻은 아니다. 다만 실제 운영에서 살아남는 조건은 대체로 수면 아래에 있다.
평가 체계가 없으면 개선인지 회귀인지 알 수 없다. 관측 가능성이 없으면 실패했다는 사실은 알아도 어디에서 왜 실패했는지 모른다. 권한 부여가 허술하면 좋은 답을 내는 것 자체가 사고가 될 수 있다. 재시도 정책이 없으면 일시적 장애가 전체 실패가 되고, 잘못 설계하면 같은 외부 작업을 두 번 실행한다. 사람에게 넘기는 절차가 없으면 시스템이 모르는 것을 모른다고 말해도 업무가 끝나지 않는다.
이 때문에 나는 다음 표현을 쓴다.
마지막 10%의 엔지니어링이 체감 신뢰도의 90%를 결정할 수 있다.
이 숫자는 측정된 통계가 아니라 강조를 위한 표현이다. 요점은 데모의 마지막 부분처럼 보이는 운영·통제 계층이 사용자가 체감하는 신뢰도의 대부분을 결정할 수 있다는 것이다.
너무 이른 공개가 만든 신뢰 부채
데모를 본 우리 쪽 임원은 이 시스템이 상위 경영진에게도 충분히 설득력 있게 보일 수 있다고 판단했던 것 같다. 그 뒤 출시 일정은 원래 계획의 절반으로 줄었고, 우리는 당초 계획과 달리 시스템을 매우 서둘러 비교적 넓은 사용자에게 공개하게 됐다. 기술적으로는 작동했지만 우리가 원하는 신뢰성에는 아직 도달하지 못한 상태였다.
돌이켜보면 이런 일은 회사에서 생각보다 자주 일어난다. 설득력 있는 데모가 기술의 가능성뿐 아니라 배포 준비도까지 보여 주는 것으로 받아들여지면서, 검증을 위해 남겨 둔 시간이 사업 일정에 흡수된다.
그 결과 초기 사용자 중 상당수가 이탈했다. 이후 품질을 안정화하고 사용자 경험을 개선하고 적합한 업무를 다시 발굴했지만, 사용자를 되돌리는 일은 처음 사용자를 모으는 일보다 어려웠다.
이 경험을 나는 신뢰 부채(Trust Debt)라고 정리한다.
기술 부채는 빠른 구현을 위해 미래의 개발 비용을 빌려오는 일이다. 신뢰 부채는 성숙하지 않은 경험을 넓게 노출해 미래의 사용자 회복 비용을 빌려오는 일이다.
AI 시스템의 신뢰는 대칭적으로 움직이지 않는다. 몇 번 좋은 결과가 나왔다고 바로 중요한 업무를 맡기지는 않는다. 반면 중요한 순간에 크게 실패하면 사용자는 빠르게 돌아선다. 이후 시스템이 실제로 좋아져도 “예전에 써 봤는데 안 됐다”는 기억이 새로운 평가보다 먼저 작동한다.
그래서 공개 범위는 단순한 배포 범위의 문제가 아니다. 학습 속도와 신뢰 보존 사이의 설계다. 좁은 문제와 제한된 사용자로 시작해 실패를 가까이에서 관찰하면 피드백을 얻으면서도 신뢰 손실의 영향 범위를 줄일 수 있다. 반대로 넓은 공개는 많은 피드백을 주지만, 아직 모르는 실패 유형까지 한꺼번에 사용자에게 노출한다.
플랫폼을 먼저 만들지 않는다는 것
처음의 사고 순서는 이랬다.
많은 요구사항 → 공통 추상화 → 플랫폼 → 다양한 업무
여러 요구에서 공통점을 관찰하고, 추상화를 설계하고, 플랫폼을 만든 뒤 다양한 업무를 태우는 방식이다. 논리적이지만 한 가지 취약점이 있다. 공통적으로 말해진 요구와 실제 운영에서 반복되는 문제는 같지 않을 수 있다.
지금 다시 한다면 순서를 바꿀 것이다.
예를 들어 “전략 보고서를 작성하는 AI 에이전트”처럼 넓게 시작하지 않는다. 다음 정도까지 줄인다.
내부 사업계획과 지정된 경쟁사 5곳의 최신 실적을 읽어, 정해진 양식의 3C 분석을 생성한다.
데이터 출처를 제한한다. 도구를 제한한다. 결과 형식을 고정한다. 에이전트의 자율성도 제한한다. 사용자가 어떤 결정을 내리기 위해 결과를 쓰는지 정의하고, 그 하나를 실제 운영 수준까지 가져간다.
첫 번째 업무에서 생긴 문제를 모두 플랫폼 기능으로 만들지도 않는다. 일부는 그 업무만의 예외일 수 있기 때문이다. 두 번째 업무에서도 같은 문제가 나타나는지 본다. 세 번째에서도 반복될 때 비로소 공통 기능으로 추출한다.
경험 → 반복 → 추상화
이 순서는 추상화를 포기하자는 말이 아니다. 추상화의 증거 기준을 높이자는 말이다.
예를 들어 세 업무가 모두 “승인된 출처만 검색해야 한다”는 문제를 가진다면 권한을 인식하는 검색 기능은 구성 요소가 될 수 있다. 세 업무가 모두 장시간 작업 흐름의 중간 결과를 검증하고 재개해야 한다면 지속 상태와 중간 저장 지점이 공통 계층이 될 수 있다. 반면 한 업무에서만 필요한 특수한 보고서 구조를 범용 모듈 규격에 밀어 넣으면 플랫폼 전체가 예외 처리로 부풀어 오른다.
핵심은 이것이다.
올바른 추상화는 상상하는 것이 아니라 발견하는 것이다.
그렇다면 플랫폼은 언제 만들어야 하는가
“플랫폼을 먼저 만들지 말라”는 말이 플랫폼 팀을 없애거나 모든 업무를 일회성으로 만들라는 뜻은 아니다. 공통 기반이 반드시 필요한 경우도 있다. 인증, 감사, 데이터 경계, 배포 표준처럼 기업 전체가 처음부터 지켜야 하는 제약은 첫 업무 전에도 설계해야 한다.
다만 처음부터 완성해야 하는 것은 최소한의 제어 기반이지, 미래의 모든 작업 흐름을 표현할 수 있는 범용 추상화가 아니다.
플랫폼으로 추출할 시점을 판단할 때는 다음 질문이 유용하다.
- 이 문제가 서로 다른 업무에서 실제로 반복됐는가?
- 반복된 문제의 원인이 정말 같은가, 표면만 비슷한가?
- 공통화하면 각 업무의 품질과 속도가 좋아지는가?
- 추상화를 유지할 담당자와 운영 비용이 있는가?
- 예외가 생겼을 때 플랫폼을 우회할 탈출구가 있는가?
세 번의 반복이 마법의 숫자는 아니다. 중요한 것은 추상화의 근거가 사전 추측이 아니라 실제 운영에서 관찰된 증거라는 점이다.
운영을 거친 뒤 플랫폼을 만든다
처음에는 기업의 수많은 AI 요구사항을 하나의 플랫폼에서 해결하고 싶었다. 그 목표는 여전히 매력적이고, 어떤 부분은 실제로 유효했다. 하지만 플랫폼의 모양을 가장 정확히 알려주는 것은 요구사항 목록이 아니라 실제 운영에서 반복되는 실패였다.
지금 다시 시작한다면 하나의 문제를 선택할 것이다.
그리고 그 하나를 끝까지 해결할 것이다.
두 번째 문제에서 반복되는 것을 찾을 것이다.
세 번째에서도 반복된다면 비로소 추상화할 것이다.
그리고 그때야 그것을 플랫폼이라고 부를 것이다.
플랫폼부터 만들지 말라. 실제 운영을 통해 플랫폼을 획득하라.
핵심 요약
- 코딩 에이전트는 데모 구현 비용을 낮췄지만, 실제 운영 비용까지 없애지는 않았다.
- 기업용 에이전트의 핵심 난제는 기능보다 예측 가능성이다.
- 사용자는 구조의 복잡성이 아니라 실패의 빈도와 복구 경험으로 시스템을 평가한다.
- 넓고 이른 공개는 기술 부채와 별개로 사용자 회복을 늦추는 신뢰 부채를 만들 수 있다.
- 좋은 추상화는 요구사항 회의에서 상상하기보다 서로 다른 실제 운영 업무에서 반복되는 문제로부터 추출해야 한다.
- 먼저 필요한 것은 범용 플랫폼이 아니라 좁은 업무와 최소한의 제어 기반이다.
- 플랫폼은 배포의 전제라기보다 운영 → 학습 → 반복 → 제품화의 결과물에 가깝다.
Discussion
토론
질문, 정정, 반례, 다른 해석이 있다면 남겨 주세요.