회사가 멀티 에이전트 AI 시스템을 원한다면, 실제로 누가 구축하게 될까요?

회사가 멀티 에이전트 AI 시스템을 원한다면, 실제로 누가 구축하게 될까요?

저는 기업 엔지니어링 팀 전반에서 나타나는 기묘한 패턴을 목격해 왔습니다. 모두가 멀티 에이전트 AI 시스템 (Multi-Agent AI Systems)에 열광하고 있지만, 정작 누가 이를 담당해야 하는지는 아무도 확신하지 못하고 있습니다.

백엔드 (Backend) 팀은 이것이 아키텍처 (Architecture) 문제라고 말합니다. ML 엔지니어 (ML Engineers)들은 자신들은 모델을 만드는 것이지 워크플로우 (Workflows)를 만드는 것이 아니라고 말합니다. DevOps 팀은 이미 업무 과부하 상태입니다. 그리고 프로덕트 매니저 (Product Managers)들은 누군가 이를 실제로 구현해 주기를 바라며 만화 속 로봇들 사이에 화살표를 그린 다이어그램을 그리고 있습니다.

새롭게 떠오르는 역할인 AI 워크플로우 아키텍트 (AI Workflow Architect)의 세계에 오신 것을 환영합니다. 만약 이 역할을 들어본 적이 없다면, 당신만 그런 것은 아닙니다.

실제 현장에서는 어떤 모습일까요?

구체적인 시나리오를 그려보겠습니다. 당신은 다음과 같은 고객 지원 시스템을 구축하고 있습니다:

• 에이전트 A (Agent A): 들어오는 티켓을 모니터링하고 긴급도를 분류합니다.
• 에이전트 B (Agent B): 관련 문서와 과거 티켓을 가져옵니다.
• 에이전트 C (Agent C): 답변 초안을 작성합니다.
• 에이전트 D (Agent D): 자동 전송할지 아니면 사람에게 에스컬레이션 (Escalate)할지 결정합니다.
• 에이전트 E (Agent E): 사람의 수정 사항으로부터 학습하여 다른 에이전트들에게 피드백을 제공합니다.

이제 재미있는 부분이 나옵니다. 핸드오프 프로토콜 (Handoff protocols, 인계 프로토콜)은 누가 설계할까요? 에이전트 D의 신뢰도 임계값 (Confidence threshold)은 누가 결정할까요? 에이전트 B가 손상된 컨텍스트 (Context)를 제공하여 에이전트 C가 환각 (Hallucinating) 현상을 일으키기 시작하면 누가 디버깅 (Debug)할까요? 에이전트 A가 편향된 피드백 루프 (Bias feedback loop)를 생성하지 않도록 누가 보장할까요?

이것은 단순히

관측 가능성 전문 지식 (Observability Expertise): 전통적인 로깅 (Logging)만으로는 부족합니다. 여러 에이전트에 걸친 의사결정을 추적하고, 프롬프트/응답 (Prompt/Response) 쌍을 캡처하며, 6개의 에이전트 체인 중 어느 지점에서 문제가 발생했는지 이해해야 합니다.

프로세스 매핑 (Process Mapping): 네, 지루한 비즈니스 분석가 (Business analyst)의 기술입니다. 워크플로우 (Workflow)를 자동화하기 전에, 인간이 실제로 무엇을 하는지 (그들이 한다고 말하는 것과는 별개로) 이해해야 하기 때문입니다.

리스크 평가 (Risk Assessment): 에이전트 D가 환불을 자동 승인했을 때, 책임은 누구에게 있을까요? 에이전트 A가 1,000개의 티켓을 잘못 분류한다면 그 영향 범위 (Blast radius)는 어느 정도일까요? 여러분은 단순히 예측을 하는 것이 아니라, 행동을 취하는 시스템을 설계하고 있는 것입니다.

문제는 이렇습니다. 어떤 부트캠프 (Bootcamp)에서도 이를 가르치지 않습니다. 어떤 학위 과정에서도 이를 다루지 않습니다. 현재 이 작업을 수행하고 있는 사람들은 대개 다음과 같습니다:

• LLM (Large Language Models)에 호기심을 갖게 된 시니어 백엔드 엔지니어 (Senior backend engineers)
• 잘못된 자동화로 인해 고생해 본 솔루션 아키텍트 (Solutions architects)
• 실제로 로그 (Logs)를 읽는 그 DevOps 담당자

코드 관점에서의 모습

단순화된 멘탈 모델 (Mental model):

class WorkflowOrchestrator:
    def __init__(self):
        self.agents = self.load_agents()
...

악마는 저 주석 처리된 줄 사이에 있습니다. 전통적인 에러 핸들링 (Error handling)은 결정론적 실패 (Deterministic failures)를 가정합니다. 에이전트의 실패는... 모호합니다 (Squishy).

이것이 지금 중요한 이유

우리는 변곡점 (Inflection point)에 서 있습니다. 2년 전 "프로덕션에서의 AI (AI in production)"는 API 뒤에서 모델을 서빙하는 것을 의미했습니다. 이제 그것은 여러 모델, 전통적인 서비스, 인간 참여형 개입 (Human-in-the-loop interventions), 그리고 결과에 따라 적응하는 의사결정 트리 (Decision trees)를 조정하는 것을 의미합니다.

대부분의 영국 조직들은 다음 중 하나에 해당합니다:

• 가용 인력이 있는 사람을 통해 임시방편 (Ad-hoc)으로 구축 중 (대개 과부하된 시니어 엔지니어)
• 열풍에도 불구하고 전혀 구축하지 않음
• 격차를 줄이기 위해 AI 자동화 및 소프트웨어 개발을 전문으로 하는 에이전시에 아웃소싱함

여러분이 할 수 있는 일

만약 여러분이 시스템 사고 (Systems thinking)를 즐기는 중급 이상의 엔지니어라면, 이것은 진정으로 흥미로운 커리어 방향입니다. 여러분의 입지를 다지는 방법은 다음과 같습니다:

1. 멀티 에이전트(multi-agent) 무언가를 구축해 보세요 (장난감 프로젝트라도 좋습니다) 그리고 무엇이 잘못되었는지 기록하세요.
2. 관측성 패턴(observability patterns)을 공부하세요 — OpenTelemetry, 분산 트레이싱(distributed tracing) 등 여러분이 배우려고 마음먹었던 바로 그것들입니다.
3. 비즈니스 프로세스 매핑(business process mapping)에 익숙해지세요 — 네, 정말입니다. BPMN은 멋져 보이지는 않지만 매우 유용합니다.
4. 프롬프트 엔지니어링(prompt engineering)을 배우세요 — 최종 목표로서가 아니라, 더 큰 시스템 내의 도구로서 배우십시오.

이 사실을 조기에 파악하는 기업들은 상당한 우위를 점하게 될 것입니다. 이 간극을 메울 수 있는 엔지니어들은 대체하기가 정말 어려울 것입니다.

만약 여러분의 회사가 명확한 담당자를 지정하지 않은 채 백로그(backlog)에 단순히 "AI 에이전트 구현"이라는 항목만 추가했다면? 글쎄요, 그것이 바로 여러분의 기회입니다.