그것은 당신이 잠든 동안에도 돌아갑니다. 이것은 제품을 판매하는 문구이자, 새벽 3시에 발생하는 모든 잘못된 일들을 숨기는 문구이기도 합니다.

만약 당신이 지금 개발자 포럼에서 시간을 조금이라도 보낸다면, 이런 유형을 본 적이 있을 것입니다. 누군가가 AI 에이전트 (AI-agent) 부서들로 구성된 명단을 통해 자신의 "1인 기업"을 운영하고 있다는 내용 말입니다. 리드 (leads)를 자격 검증하는 영업 에이전트, 티켓에 답변하는 지원 에이전트, 데이터를 조정하는 운영 (ops) 에이전트, 그리고 이 모두에게 정보를 제공하며 급여 없이 조용히 작동하는 리서치 에이전트까지. 이것은 진정으로 흥미로운 아이디어이며, 이를 설명하는 게시물들은 수천 개의 반응을 얻습니다. 왜냐하면 모두가 그것이 사실이기를 바라기 때문입니다. 그래서 저는 이 이야기가 어디까지 유효하고 어디서 무너지는지 알아내기 위해 우리 자신의 운영 전반에 걸쳐 그 버전의 모델을 구축했습니다.

여기 솔직한 보고서가 있습니다. 놀라울 정도로 많은 부분이 작동하며, 계속 유지할 만큼 충분히 잘 작동합니다. 그리고 전체 시스템이 찢어지는 구체적이고 예측 가능한 지점이 있는데, 그곳은 데모 영상이 준비시켜 주는 곳이 결코 아닙니다. 이것은 분해 보고서(teardown)입니다: 제가 무엇을 설정했는지, 무엇이 실제로 유지되었는지, 무엇이 고장 났는지, 그리고 에이전트들로 비즈니스를 연결하려는 누구에게라도 제가 해주고 싶은 말입니다.

한 문장 요약:

제한된 작업 (bounded tasks)을 수행하는 개별 에이전트들은 신뢰할 수 있고 진정으로 유용합니다. 모든 실패는

핸드오프 (handoffs)

— 즉, 한 에이전트가 다음 에이전트에게 작업을 전달하는 이음새에서 발생합니다. 에이전트들은 결코 약점이 아니었습니다. 에이전트들 사이의 연결이 약점이었습니다.

솔직한 설정 과정

이 아이디어에 대해 공정하고 싶으므로, 허수아비 공격 (strawman) 대신 제가 실제로 구축한 것을 설명하겠습니다. 각 "부서"는 좁은 권한, 특정 도구에 대한 접근 권한, 그리고 자신의 업무를 정의하는 프롬프트 (prompt)를 가진 집중된 에이전트였습니다. 리서치 에이전트는 정보를 수집하고 요약했습니다. 초안 작성 에이전트 (drafting agent)는 브리프 (briefs)를 첫 번째 초안으로 변환했습니다. 분류 에이전트 (triage agent)는 들어오는 요청을 분류하고 라우팅 (routing)했습니다. 데이터 에이전트는 일상적인 조정 작업을 수행하고 이상 징후를 표시했습니다. 화이트보드 위에서는 당신이 보았던 다이어그램과 정확히 똑같아 보였습니다. 깔끔한 상자들, 그 사이의 깨끗한 화살표들, 그리고 제가 지켜보는 동안 왼쪽에서 오른쪽으로 흐르는 작업들 말입니다.

유혹적인 부분은 첫 번째 실행이 얼마나 훌륭해 보이는가 하는 점입니다. 시스템에 목표를 부여하면, 에이전트들이 그 목표를 받아 전달하고 마지막에 무언가를 만들어내는 과정을 지켜보게 됩니다. 마치 작고 빠르며 지치지 않는 팀을 고용한 것 같은 기분이 듭니다. 데모를 진행하는 동안만큼은 실제로 그렇습니다. 문제는 이를 한 번이 아니라 백 번을 실행할 때, 그리고 테스트했던 깔끔한 예시가 아닌 실제 입력값(real inputs)을 넣었을 때 나타납니다. 물론, 데모가 아닌 회사를 운영한다는 것의 핵심은 바로 이 지점에 있습니다.

실제로 효과가 있었던 것 (그리고 유지할 가치가 있는 것)

좋은 소식을 숨기지는 않겠습니다. 왜냐하면 그것은 실재하며, 이 모든 시도를 할 가치가 있는 이유이기 때문입니다. 단일하고 잘 정의된 작업에 집중하는 단일 에이전트(Single agents)는 매우 뛰어납니다. 작업 범위가 제한적이고, 반복적이며, 마지막에 인간이 빠르게 훑어보는 것만으로 충분한 경우에는 에이전트들이 즉시 제 역할을 해냈습니다.

초안 작성(Drafting)은 확실한 승리였습니다. 초안 작성, 요약, 구조 재편, 엉망인 브리프(brief)를 몇 초 만에 80% 완성된 상태로 만드는 작업 등이 포함됩니다. 분류(Triage)도 승리였습니다. 주제와 긴급도에 따라 밀려드는 인바운드를 분류하고 라우팅(routing)하는 것은 에이전트가 잘하는 전형적인 패턴 매칭(pattern-matching)의 종류이며, 인간이 예외 사항을 처리하는 방식으로 90%의 정확도를 확보하는 것은 모든 것을 수작업으로 하는 것보다 훨씬 낫습니다. 조사(Research)와 1차 데이터 작업 역시 같은 이유로 승리였습니다. 즉, 범위가 제한적이고, 처리 속도가 빠르며, 경계 지점에서 인간의 점검(spot-check)이 이루어지는 작업들이었습니다. 이 모든 사례에서 에이전트는 하나의 작업만을 수행했고, 사람은 그 결과물에 대한 책임을 졌습니다. 그 조합은 강력하며, 저는 이 모든 방식을 유지했습니다.

성공한 모든 곳에서 유지된 패턴은 다음과 같습니다:

인간이 결과물을 책임지는 가운데, 좁은 범위의 에이전트가 특정 작업을 수행하는 것.

범위가 작고 책임 소재가 인간에게 남아 있기 때문에 레버리지(leverage)는 실제로 발생합니다. 이 과정 중 그 어떤 것도 "회사를 자동 항법(autopilot)으로 운영하는 것"은 아니며, 바로 그 점이 이 방식이 작동하는 이유입니다.

무엇이 고장 났는가: 매번 발생하는 인수인계 문제

이제 데모 영상들이 생략하는 부분입니다. 제가 에이전트들을 서로 연결했을 때 — 즉, 한 에이전트의 출력이 다음 에이전트의 입력이 되는 비감독(unsupervised) 방식 — 신뢰도는 단순히 떨어지는 것이 아니라, 하향식으로 복리로 급감했습니다. 그리고 실패는 항상 동일한 유형으로 발생했는데, 개별 박스 내부가 아니라 그 경계면(seams)에서 발생했습니다.

오류가 체인을 따라 복리로 누적되었습니다. 각 에이전트는 개별적으로는 꽤 훌륭합니다. 예를 들어 대부분의 경우 일을 제대로 처리한다고 가정해 봅시다. 하지만 다섯 개의 에이전트를 서로 의존하게 하여 하나로 묶으면, 그 작은 오류율들이 곱해집니다. 리서치 에이전트(research agent)가 만든 약간 어긋난 요약이 초안 작성 에이전트(drafting agent)에게는 미묘하게 틀린 브리프(brief)가 되고, 결국 마지막에는 확신에 찬 오답인 결과물(deliverable)로 이어집니다. 단 하나의 에이전트가 "실패"한 것이 아닙니다. 체인이 실패한 것입니다. 출력값에서 문제가 눈에 보일 때쯤이면, 그 원인은 이미 세 단계 전의 인수인계(handoff) 과정에 있었으며 추적하는 것이 거의 불가능했습니다.

경계에서 컨텍스트(context)가 증발했습니다. 에이전트들은 정신을 공유하지 않습니다. 분류 에이전트(triage agent)가 요청에 대해 이해한 내용이 다음 에이전트에게 깔끔하게 전달되지 않았습니다. 뉘앙스, 주의 사항, 그리고 "이유"는 에이전트 사이의 메시지에 담길 수 있는 수준으로 평탄화(flattened)되어 버렸습니다. 결과적으로 하류(downstream) 에이전트는 전체적으로는 틀렸지만 국소적으로는 합리적인 결정을 내리게 되는데, 이는 그 결정이 틀렸음을 알려줄 컨텍스트를 전혀 전달받지 못했기 때문입니다. 인수인계는 손실(lossy)이 발생했고, 그 손실은 누적되었습니다.

전체에 대해 책임지는 사람이 아무도 없었습니다. 각 에이전트는 자신의 단계만을 소유할 뿐 그 외에는 아무것도 책임지지 않았습니다. 최종 결과가 잘못되었을 때, "전체적인 사항이 올바른지 확인하는 것"을 업무로 하는 에이전트는 없었습니다. 왜냐하면 그러기 위해서는 체인 전체를 조망해야 하는데, 이는 바로 에이전트들이 가장 취약한 부분인 개방형 판단(open-ended judgement)을 요구하기 때문입니다. 실제로 회사를 운영하는 부분인 오케스트레이션(orchestration)은, 무언가 잘못된 것 같을 때 미친 듯이 로그를 읽어야 하는 저의 업무로 조용히 넘어가 버렸습니다.

실패는 조용히 일어났습니다. 확신이 없는 인간 직원은 "이 부분은 확실하지 않은데, 확인해 주실 수 있나요?"라며 문제를 에스컬레이션(escalate)합니다. 하지만 에이전트들은 거의 그러지 않았습니다. 그들은 불확실한 작업도 쉬운 작업과 똑같은 자신감으로 다음 단계로 넘겨버렸습니다. 그래서 무언가 잘못되었다는 것을 알게 된 첫 번째 신호는 중간에 나타난 경고가 아니라, 마지막에 발생한 잘못된 결과였습니다. 제가 직접 설계(engineer)하지 않는 한, 위험한 단계에서 "멈추고 인간에게 물어보기"와 같은 내장된 기능은 없었습니다. 그리고 그 모든 것을 설계하는 것이 실제 업무의 대부분입니다.

진짜 교훈

이번 분석을 통해 제가 배운 것은 "AI 에이전트는 작동하지 않는다"가 아닙니다. 그것보다 훨씬 더 정확하고 유용한 교훈입니다: 에이전트는 쉬운 부분이고, 오케스트레이션(orchestration)이 어려운 부분이며, 그 오케스트레이션이 곧 회사입니다. 지능형 컴포넌트들을 신뢰할 수 있고, 관찰 가능하며(observable), 책임 소재를 명확히 할 수 있는(accountable) 무언가로 연결하는 것은 심각한 엔지니어링 문제입니다. 이는 분산 시스템(distributed systems)이 항상 겪어온 문제—부분적 장애(partial failures), 컨텍스트 손실(lost context), 단일 진실 공급원(single source of truth)의 부재—와 동일하지만, 이제는 각 노드(node)마저 비결정론적(non-deterministic)이라는 점이 다릅니다.

이는 가장 낙관적인 AI 연구자들의 글을 주의 깊게 읽었을 때 그들이 말하는 내용과도 일치합니다. 오늘날의 완전 자율 에이전트(fully autonomous agents)에 대한 비판은 기반이 되는 모델이 약하다는 것이 아닙니다—모델들은 놀랍습니다—그 모델들을 감독되지 않는 다단계 자율성(unsupervised, multi-step autonomy)으로 엮어내는 것이 아직 신뢰할 수 있는 수준에 전혀 도달하지 못했다는 것이며, 이를 달성하기 위한 현실적인 타임라인은 영리한 프롬프트(prompt)가 아니라 수년간의 엔지니어링을 필요로 한다는 것입니다. 에이전트의 장기적인 미래에 열광하면서도, 오늘날의 자율 에이전트 체인(autonomous agent chains)에 대해서는 냉철함을 유지하는 것은 완전히 양립 가능한 입장입니다. 사실, 이것이 유일하게 정직한 입장입니다.

그래서 저는 자율적인 조직도(org chart)를 구축하려는 시도를 멈추고, 더 나은 것을 만들기 시작했습니다: 특정 작업에 특화된 좁은 범위의 에이전트(narrow agents), 오케스트레이션을 담당하는 인간, 그리고 에이전트들이 서로에게 작업을 넘겨야 하는 모든 곳에 실제 엔지니어링을 적용하는 것입니다. 이것은 "내가 자는 동안에도 돌아간다"는 말보다는 마법 같은 느낌이 덜합니다. 하지만 가치를 조용히 훼손하는 대신, 실제로 가치를 전달하는 버전이기도 합니다.

프로덕션급 에이전트에게 실제로 필요한 것

레버리지(leverage)를 진지하게 받아들이되 그것이 무너지는 지점을 존중한다면, 결국 특정한 것들을 구축하게 됩니다. 즉, 데모용 에이전트 목록을 비즈니스가 의지할 수 있는 무언가로 탈바꿈시키는, 화려하지는 않지만 필수적인 스캐폴딩(scaffolding, 발판 구조)입니다. 이 중 그 어떤 것도 바이럴 게시물에는 나타나지 않습니다. 하지만 이 모든 것이 바로 시스템과 단순한 이야기(story)를 가르는 차이점입니다.

• 모든 에이전트에 대한 가드레일 (Guardrails). 각 에이전트가 무엇을 할 수 있고 무엇을 건드릴 수 있는지에 대한 엄격한 제한을 두어, 확신에 찬 오답(confidently-wrong)이 되돌릴 수 없는 행동으로 이어지지 않도록 합니다. 의도적으로 범위를 제한한 역량(Capability)입니다.
• 정의된 실패 동작 (Defined failure behaviour). 에이전트가 불확실하거나 틀렸을 때 문제를 조용히 다음 단계로 넘기는 대신, 중단, 플래그(flag) 표시, 인간에게 에스컬레이션(escalate) 등 무엇을 할지에 대한 명시적인 규칙을 세웁니다.
• 중요 지점에서의 인간 체크포인트 (Human checkpoints at the stakes). 결과의 영향력이 큰 단계에서는 인간이 루프(in the loop)에 참여합니다. 모든 단계에 참여하는 것은 아닙니다. 그것은 레버리지를 죽이는 일이기 때문입니다. 대신, 잘못되었을 때 비용이 많이 발생하는 결정에 참여합니다.
• 공유 상태 및 메모리 (Shared state and memory). 에이전트들이 읽고 쓸 수 있는 진정한 단일 진실 공급원(source of truth)을 구축하여, 컨텍스트(context)가 메시지로 평탄화(flattened)되어 사라지는 대신 핸드오프(handoff, 인계) 과정에서도 유지되도록 합니다.
• 관측 가능성 (Observability). 모든 에이전트가 무엇을 했는지, 왜 했는지, 그리고 결과가 어디에서 왔는지 확인할 수 있는 능력입니다. 그래야 세 단계 전에서 무언가 고장 났을 때 실제로 그것을 찾아낼 수 있습니다.
• 오케스트레이션 (Orchestration)의 명확한 소유권. 개별 단계뿐만 아니라 전체의 정확성에 책임을 지는 누군가, 혹은 무언가가 있어야 합니다. 이 부분이 진정한 엔지니어링의 영역입니다.

이 중 거의 대부분이 에이전트를 더 "똑똑하게" 만드는 것과는 관련이 없다는 점에 주목하십시오. 이것은 통합(integration), 에러 핸들링(error handling), 상태 관리(state management), 그리고 관측 가능성(observability)에 관한 것이며, 이는 전형적인 프로덕션 엔지니어링(production engineering)의 영역입니다. AI는 구성 요소들이 할 수 있는 일을 바꾸어 놓았습니다. 하지만 구성 요소를 하나의 시스템으로 만들기 위해 요구되는 규율(discipline)을 폐지하지는 않았습니다.

승리하는 소수가 되는 법

올해 수많은 사람들이 자율 에이전트 체인 (autonomous agent chains)으로 운영을 시도하겠지만, 대부분은 저와 똑같은 해체 과정을 겪게 될 것입니다. 다만 더 많은 비용을 쓰고, 고객들 앞에서 그 모습을 보이게 될 뿐입니다. 에이전트로부터 지속 가능한 가치를 얻어내는 소수의 사람들은 식별 가능한 일련의 방식들을 다르게 수행하며, 여러분은 그 모든 것을 그대로 따라 할 수 있습니다.

그들은 특정하고 제한된 작업 (bounded tasks)에 좁은 범위의 에이전트 (narrow agents)를 배치하며, 모든 것을 감독 없는 자율성 (unsupervised autonomy)으로 연결하려는 충동을 억제합니다. 그들은 에이전트를 직원이 아닌 빠른 구성 요소 (components)로 취급하며, 오케스트레이션 (orchestration)과 결과에 대한 책임은 인간이 갖도록 유지합니다. 그들은 공유 상태 (shared state), 명시적인 실패 규칙 (explicit failure rules), 체크포인트 (checkpoints)와 같이 인계 (handoffs) 과정을 의도적으로 설계합니다. 왜냐로 그들은 시스템의 이음새 (seams)가 신뢰성을 얻거나 잃게 되는 지점이라는 것을 배웠기 때문입니다. 그들은 처음부터 관측 가능성 (observability)을 구축하여, 잘못된 결과가 발생했을 때 미스터리한 현상이 아닌 추적 가능한 일이 되도록 합니다. 그리고 업무가 중요해지는 순간 발생하는 진정한 오케스트레이션의 어려움에 직면했을 때, 새벽 3시에 자신의 주의력만으로 취약한 시스템을 붙들고 있는 대신 엔지니어링의 도움을 받습니다.

정직한 재정의는 낙담이 아닌 해방감을 줍니다. 여러분은 "AI 에이전트는 거품이다"와 "모두 해고해라, 이제 로봇이 운영한다" 사이에서 하나를 선택할 필요가 없습니다. 가치는 그 중간의 진실에 있습니다. 에이전트는 강력하고 새로운 종류의 구성 요소이며, 구성 요소를 신뢰할 수 있는 비즈니스로 만드는 것은 엔지니어링 작업입니다. 이 분업 (division of labour)을 제대로 수행하십시오. 에이전트는 제한된 작업을 수행하고, 실제 엔지니어링은 연결 조직 (connective tissue)을 담당하며, 인간은 이해관계 (stakes)를 책임지는 것입니다. 그렇게 하면 새벽 3시의 돌발 상황 없이 꿈꾸던 모습의 대부분을 얻을 수 있습니다.

우리는 에이전트 사이의 부분을 엔지니어링합니다

Shanti Infosoft는 CMMI Level 5 소프트웨어 엔지니어링 기업입니다. 우리는 데모용 에이전트 목록을 비즈니스가 실제로 의존할 수 있는 무언가로 바꿔주는 가드레일 (guardrails), 공유 상태 (shared state), 인간 체크포인트 (human checkpoints), 그리고 관측 가능성 (observability)을 갖춘, 프로덕션 환경에서 견고하게 작동하는 에이전트 시스템 (agentic systems)을 구축합니다. 여러분은 지정된 시니어 팀, 서면으로 작성된 고정 범위 견적, 그리고 완전한 IP 및 소스 소유권을 보장받습니다.

무료 20분 상담 예약하기 →

AI 개발 서비스 탐색하기

자주 묻는 질문 (Frequently Asked Questions)

정말로 AI 에이전트로 회사를 운영할 수 있나요?

회사의 실제적이고 유용한 부분들 — 초안 작성 (drafting), 분류 (triage), 조사 (research), 1차 지원 (first-pass support), 일상적인 데이터 작업 (routine data work) — 을 운영하며 진정한 레버리지 (leverage)를 얻을 수 있습니다. 아직 할 수 없는 것은 전체 기능을 완전히 자율적인 에이전트 (fully autonomous agents)에게 맡기고 자리를 비우는 것입니다. 에이전트는 경계가 명확하고 잘 정의된 작업 (bounded, well-defined tasks)에는 탁월하지만, 개방형 판단 (open-ended judgement)이나 작업 간의 깔끔한 인수인계에는 신뢰도가 낮습니다. 승리하는 패턴은 자율적인 조직도 (autonomous org chart)가 아니라, 인간이 오케스트레이션 (orchestration)을 담당하며 특정 직무에 집중하는 좁은 범위의 에이전트 (narrow agents)를 활용하는 것입니다.

AI 에이전트들을 체인 형태로 연결할 때 실제로 무엇이 고장 나나요?