들어가며

이해를 돕기 위해 가상의 주문 변경 상황을 하나 떠올려 보겠습니다. 어느 기업의 영업지원팀이 거래처 메일을 읽고 주문 변경 초안을 만드는 AI를 도입했습니다. 시연에서는 매끄러운 답장을 순식간에 작성해 호평을 받았습니다. 하지만 실제 업무에 연결하자 곧바로 문제가 생겼습니다.

거래처에서 “지난번 주문한 부품 두 박스만 더 추가하고, 새로 여는 평택 물류센터로 보내달라"는 메일을 보냈습니다. AI는 정중한 안내문을 만들었지만 내용은 틀렸습니다. 1박스 24개입 부품을 낱개 ‘2개’로 적었고 단가는 지난달 종료된 가격을 썼습니다. 수정 대상으로 잡은 주문은 이미 출고 준비가 끝나 변경이 막힌 상태였습니다. 실무팀은 추론력이 부족하다며 더 비싼 최신 모델로 교체했습니다. 문장만 자연스러워졌고 같은 실수는 그대로 반복됐습니다.

AI가 실수하면 흔히 ‘모델의 지능’부터 의심합니다. 하지만 기업 업무는 언어모델 혼자 머릿속으로 끝낼 수 있는 일이 아닙니다. 일머리가 좋은 직원을 뽑아도 현재 단가 원장, 박스당 입수량 기준, 출고 마감 후 승인 절차를 알려주지 않으면 사고가 나는 것과 같습니다.

2024년 2월 BAIR 연구자들의 블로그 글 에서는 이처럼 여러 모델 호출과 검색기, 외부 도구가 맞물려 과제를 푸는 구성을 ‘복합 AI 시스템(Compound AI Systems)‘으로 설명했습니다. 이 개념은 ‘모델 자체의 능력’과 ‘모델을 포함한 업무 시스템의 설계’를 구분해 보자는 실용적인 시선으로, 유행하는 복잡한 구조를 무조건 도입하자는 뜻과는 거리가 멉니다.

단일 모델과 복합 시스템, 무엇이 다를까요?

AI 프로젝트 보고에 등장하는 RAG, 워크플로, 에이전트, 멀티에이전트 같은 용어는 **“누가 실행 순서를 정하고, 어떤 부품들이 역할을 나누는가”**로 보면 정리하기 쉽습니다.

단순한 일에 복잡한 조립은 필요하지 않습니다

복합 시스템이 단일 모델 호출보다 언제나 나은 것은 아닙니다. 내용이 이미 완결된 짧은 메모의 문체를 다듬는 일이나 정해진 범주로 문의를 분류하는 일이라면 모델을 한 번 부르는 것만으로 충분할 때가 많습니다. 불필요하게 검색기나 검토 단계를 덧대면 지연 시간과 호출 비용, 운영 부담만 늘어납니다. 2024년 12월 공개된 Anthropic의 에이전트 설계 지침 도 가장 단순한 구성으로 시작하고 필요가 확인될 때만 복잡성을 늘리라고 권고합니다.

모델의 수와 시스템 구성은 다른 축입니다

복합 AI 시스템은 과제 해결에 언어모델뿐 아니라 외부 원장 조회, 계산 코드, 규칙 검사 같은 여러 부품이 실질적으로 협력해야 할 때 필요합니다.

복합 시스템을 ‘여러 종류의 거대언어모델을 쓰는 것’이나 ‘멀티에이전트’와 같은 말로 오해하기 쉽습니다. 하지만 모델의 종류 수, 호출 횟수, 에이전트 수, 외부 부품 수는 서로 다릅니다. BAIR의 2024년 제안 처럼 같은 언어모델 하나만 쓰더라도 사내 데이터를 조회하고 계산 함수와 검사기를 거쳐 결과를 낸다면 복합 시스템입니다.

실무에서는 실행 순서를 누가 정하느냐에 따라 두 가지를 구분합니다(Anthropic의 설계 지침 ).

• 워크플로(Workflow): 모델과 도구가 움직이는 순서를 코드로 미리 고정한 구성으로, 절차가 정해진 반복 업무에 맞습니다.
• 에이전트(Agent): 모델이 상황을 보고 다음 행동과 도구 사용을 고르는 구성으로, 예외가 많아 경로를 미리 고정하기 어려울 때 씁니다.

멀티에이전트는 여러 에이전트가 역할을 나누는 구성으로 복합 시스템 안에 포함되는 한 가지 방식일 뿐입니다. 모든 단계를 자율 에이전트로 만들 필요도 없습니다. 정상 경로는 코드로 고정하고 예외 판단에만 모델을 쓰는 혼합 구성도 실용적입니다.

가상의 주문 변경 업무로 보는 부품별 역할

앞서 본 가상의 주문 변경 업무로 각 부품이 어떤 책임을 나눠 가져야 하는지 살펴보겠습니다. 고객이 *“지난번 주문을 두 박스 더 보내주시고, 새 물류센터로 바꿔주세요”*라고 했을 때, 목표는 그럴듯한 답장 작성이 아닙니다. 정확한 변경 초안을 만들어 필요한 승인을 거치는 것, 그리고 대상 주문이나 수량 단위, 변경 가능 여부가 모호하면 임의로 확정하지 않고 확인을 요청하는 것입니다.

요청 해석과 사실 조회의 분리

언어모델은 고객 메일에서 ‘직전 주문 수량 추가’, ‘배송지 변경’ 같은 의도를 읽고 누락된 정보를 되물을 질문을 만듭니다. 이때 모델이 내놓은 해석은 최종 확정이 아니라 다음 단계가 확인할 ‘후보 제안’으로 다뤄야 합니다.

주문 ID나 현재 단가, 재고처럼 식별과 갱신 시점이 중요한 값은 ERP 같은 구조화 원장(System of Record)에서 조회하고 배송지 변경 규정 같은 문서는 검색 부품이 찾습니다. OpenAI의 Retrieval 공식 문서 (2026-10-23 확인)를 보면 검색기는 관련 조각과 유사도 점수를 돌려주고 속성 필터로 범위를 좁힐 수 있습니다. 다만 업무 설계에서는 ‘유사도 점수가 높다’는 것을 ‘오늘 이 거래처에 적용되는 유효 규정이다’와 같은 뜻으로 쓰면 안 됩니다. 적용 시점과 거래처 조건을 따로 확인하고 조회 실패를 ‘제한 규정 없음’으로 바꾸지 않는 것이 핵심입니다.

재현 가능한 계산과 다층 검증

원장에서 ‘1박스 24개입’ 기준과 계약 단가를 찾았다면 박스 수를 낱개로 환산하고 합계 금액을 구하는 일은 결정론적 계산 함수(일반 코드)에 맡깁니다. 언어모델이 산수를 못해서라고 단순화할 문제가 아닙니다. 기업의 단가·할인·반올림·통화 계산에서는 같은 입력과 같은 규칙에서 늘 같은 결과를 재현하고 어느 버전의 규칙을 썼는지 기록을 남겨야 하기 때문입니다. 물론 입력된 수량·단위가 틀리거나 코드에 반영된 업무 규칙 버전 자체가 잘못되면 계산 코드도 틀린 값을 그대로 재현합니다. 그래서 계산 부품은 입력값과 단위, 적용한 규칙 버전을 함께 남기고 모델에게는 결과값을 그대로 참조시켜 금액을 문장으로 다시 계산하지 않게 해야 합니다.

계산을 마친 초안은 검증 단계를 거칩니다. 대상 주문이 변경 가능한 상태인지, 필수 정보가 있는지, 초안의 숫자가 계산 결과와 일치하는지는 코드로 검사합니다. 고객의 원래 의도가 설명에 잘 반영됐는지는 명시된 기준에 따라 모델이나 사람이 검토합니다.

순서 통제와 실제 저장의 분리

순서와 예산 한도, 승인 대기를 관리하는 오케스트레이션과 실제 원장에 기록하는 저장 어댑터는 마지막 안전망입니다. OpenAI의 Function Calling 공식 문서 (2026-10-23 확인)가 설명하듯, 언어모델이 도구 호출을 ‘요청’하는 것과 애플리케이션이 실제 코드를 ‘실행’하는 것은 다릅니다. 담당자 승인 여부와 저장 가능 조건은 모델 프롬프트가 아니라 실제 실행 계층에서 확인하도록 설계해야 합니다.

부품 사이의 약속: 인계 계약과 검증의 한계

개별 부품의 역할을 나누더라도 부품 사이에 주고받는 약속, 즉 **‘인계 계약(Handoff Contract)’**이 느슨하면 전체 업무는 쉽게 어긋납니다. 가상의 주문 변경 흐름에서 주의해 설계해야 할 인계 항목들을 짚어보겠습니다.

단위·출처·유효 시각의 명시

첫째는 입력의 의미와 단위입니다. 앞 단계가 수량: 2만 넘기면 두 박스인지 두 개인지, 기존 수량에 더할 증분인지 변경 후 최종 총량인지 알 수 없습니다. 이름이 같은 숫자라도 단위와 기준이 함께 넘어가지 않으면 다음 부품은 다른 뜻으로 계산합니다.

둘째는 식별자와 기준 시각입니다. 고객이 “지난번 주문"이라고만 했는데 최근 주문이 두 건이라면 임의로 하나를 골라 처리해서는 안 됩니다. 확정된 주문 ID와 상품 ID, 원장 레코드 버전, 그리고 가격 조회 시각과 유효기간을 함께 넘겨야 조회 이후 바뀐 상태를 감지할 수 있습니다.

실패 상태를 빈칸이나 0으로 감추지 않기

셋째는 누락과 실패 상태의 구분입니다. 조회가 실패했거나 규정을 못 찾았는데 그 상태를 빈값이나 0으로 넘기면 뒷 단계가 ‘제한 규정 없음’이나 ‘금액 0원’으로 오해해 절차를 진행할 수 있습니다. 인계 계약에는 정상(ok) 외에도 결과 없음(not_found), 대상이 여럿이라 모호함(ambiguous), 원장 조회 불가(unavailable) 같은 상태를 명시해 구분해야 합니다. 모호하거나 조회가 안 될 때는 멈추고 확인을 요청하는 것이 정상 작동입니다. 저장 직후 응답이 끊겼을 때 무작정 재실행해 중복 변경을 만들지 않도록 멱등 키와 재조회 절차도 계약에 포함해야 합니다.

형식 준수와 내용 정확성은 다릅니다

실무에서 “구조화 출력(Structured Outputs)으로 JSON 형식을 맞췄으니 안전하다"고 생각하는 경우가 있습니다. 하지만 양식의 칸을 규격대로 채웠다는 것과 그 안의 값이 사실이라는 것은 별개입니다. OpenAI의 Structured Outputs 공식 문서 (2026-10-23 확인) 역시 스키마 준수를 지원하더라도 출력 내용 자체에는 여전히 실수가 들어갈 수 있으며 거절이나 토큰 한도로 중단된 불완전 응답도 정상 데이터와 구분해야 한다고 명시합니다. JSON 형태가 맞아도 주문 ID가 실제 원장에 없는 번호이거나 단위가 틀릴 수 있습니다.

검증기도 마찬가지입니다. 검토용 모델을 하나 더 붙이더라도 앞단에서 잘못 검색한 자료를 두 모델이 함께 보면 같은 오류를 통과시킬 수 있습니다. 검증기가 있다고 완전한 정답이 보장되지는 않습니다. 그러니 코드 기반 규칙 검사와 사람의 주기적 대조를 병행하고 각 규칙과 부품을 누가 고칠지 운영 소유자까지 정해 두어야 합니다.

모델 교체인가 시스템 수리인가: 경영진의 판단 기준

실제 기업들의 공개 사례에서도 무엇을 모델 밖에 두었는지가 핵심입니다. Uber가 2024년 공개한 QueryGPT 설계 는 자연어 질문을 SQL로 바꿀 때 업무 영역 분류와 테이블 검색을 거치게 했습니다. 그 뒤에는 사용자가 테이블 후보를 직접 확인·수정하는 단계와 불필요한 열 축소를 결합했습니다. Morgan Stanley의 2024년 Debrief 출시 발표 와 OpenAI의 Morgan Stanley 사례 페이지 (2026-10-23 확인)에서도 고객 동의 아래 회의 요약과 후속 메일 초안, Salesforce 메모를 생성하되 메일을 수정해 발송하는 결정은 자문가가 맡도록 역할을 나눴습니다.

증상만 보고 단정하지 말고 단계별 기록을 확인해야 합니다

그렇다면 우리 회사 AI에서 오류가 났을 때 모델을 바꿀지, 시스템을 고칠지 어떻게 판단해야 할까요? 무엇보다 겉으로 드러난 증상만 보고 원인을 단정하는 일을 경계해야 합니다.

가령 주문 변경 초안에 ‘지난달 단가’가 들어갔다고 해봅시다. 원장 데이터 자체가 갱신되지 않았을 수도 있고 검색 필터나 용어 매핑이 어긋났을 수도 있습니다. 검색기가 가져온 여러 후보를 놓고 언어모델이 프롬프트를 해석하다 잘못된 줄을 골랐을 가능성도 있습니다. 그러니 증상만 보고 “검색이 고장 났다"거나 “모델이 나쁘다"고 단정하지 말고 각 부품이 넘긴 중간 기록을 열어 어느 단계에서 잘못된 정보나 판단이 들어왔는지 먼저 조사해야 합니다. 설정이나 모델을 바꿔 한 번 다시 돌려봤더니 결과가 나아졌다고 해서 그것만으로 원인이 증명되지도 않습니다.

원인을 가려내기 위해 같은 업무 사례 묶음과 같은 원장 시점, 예산 조건에서 다음 네 가지를 나란히 비교하는 실험을 제안합니다.

• 현재 모델 + 현재 구조: 기준이 되는 현재 오류·시간·비용 확인
• 후보 모델 + 현재 구조: 모델 교체만의 효과 확인
• 현재 모델 + 확인된 문제 부품 수정: 구조·계약 변경만의 효과 확인
• 후보 모델 + 개선 구조: 결합 효과와 추가 비용 비교

올바른 근거와 단위를 주었는데도 모델이 애매한 요청 문맥을 못 읽거나 문장이 어색하다면 모델·프롬프트 개선을 검토할 수 있습니다. 반대로 원장 조회나 단위 인계, 승인 조건이 비어 있었다면 해당 부품을 수리하는 편이 직접적입니다.

부품 점수가 아니라 전체 결과와 보류 능력을 봐야 합니다

평가할 때도 개별 부품의 점수만 믿어서는 안 됩니다. Uber의 2024년 QueryGPT 설계 에서도 부품 평가와 전체 경로 평가를 구분했습니다. 부품 평가에는 앞 단계 정답을 넣어주고 전체 경로 평가에는 앞 단계 추정값을 그대로 씁니다. Anthropic의 2026년 에이전트 평가 지침 역시 대화 기록이 아니라 시험이 끝난 뒤 실제 환경의 최종 상태를 확인하라고 강조합니다.

경영진이 확인할 지표로 단순 완료율은 부족합니다. 주문 후보가 둘이거나 단위가 빠진 사례에서 모호한 요청을 멋대로 확정하지 않고 적절히 보류했는가, 잘못된 확정 건수, 담당자의 사후 수정 시간, 그리고 호출료·재시도·검토·운영을 합친 완료 건당 총비용을 함께 보고 판단해야 합니다.

나가며

회사 AI의 품질은 더 큰 모델을 기다리거나 무조건 많은 에이전트를 붙여 시스템을 복잡하게 만든다고 높아지지 않습니다. 품질을 높이는 일은 사실 조회, 규칙 계산, 검증, 사람 승인의 책임을 어디서 나눌지 정하고 부품 사이의 인계 계약을 세운 뒤 단계별 기록을 바탕으로 모델 교체와 시스템 수리를 비교하는 운영의 문제입니다.

우리 조직의 AI가 어느 단계에서 흔들리는지 진단하거나 사내 원장과 맞물리는 업무용 AI 설계와 평가 기준이 필요하시다면 언제든 엡실론델타에 편하게 문의해 주십시오. contact@epsilondelta.ai 로 메일 주시면 현업 흐름에 맞는 해법을 함께 고민하겠습니다.