에이전트가 서로 일하는 방식이 제품 경쟁력을 바꾸는 순간

한 번의 똑똑한 답변보다 여러 역할이 맞물리는 작업 흐름이 더 중요한 순간이 왔다. 질문 하나에 답을 잘하는 모델은 여전히 유용하지만, 제품이 다루는 일이 길어지고 끊어지고 되돌아가고 검증까지 요구하기 시작하면, 성능의 기준은 문장 품질이 아니라 협업 구조로 이동한다. 이때부터 경쟁력은 모델의 크기보다 누가 무엇을 언제 넘겨받고, 어디까지 실행하고, 어떤 흔적을 남기며, 어디서 멈출지를 설계하는 힘에서 갈린다.

요즘 multi-agent orchestration이 갑자기 많이 거론되는 이유도 여기에 있다. 사람들은 흔히 더 큰 모델이 더 복잡한 문제를 한 번에 해결해주리라 기대하지만, 실제 운영에서는 오히려 그 반대 장면이 자주 벌어진다. 맥락이 길어질수록 목적은 흐려지고, 도구 호출이 늘수록 실패 지점은 많아지며, 대화가 길어질수록 책임 경계는 모호해진다. “한 번에 다 해줘”라는 인터페이스는 보기에는 단순하지만, 시스템 내부에서는 가장 관리하기 어려운 약속이 된다.

이 지점에서 openai-agents-js 같은 흐름이 주는 신호는 분명하다. 중요한 것은 모델 호출을 감싸는 래퍼 하나가 아니라, handoff, tools, guardrails, tracing, voice를 같은 축 위에 올려놓고 다루려는 태도다. 이 조합이 의미하는 바는 단순한 기능 추가가 아니다. 이제 에이전트 시스템은 실험용 데모가 아니라 운영 코드로 관리되어야 한다는 선언에 가깝다.

왜 갑자기 한 명으로는 버거워졌나

문제는 모델이 덜 똑똑해서가 아니다. 문제는 업무가 생각보다 훨씬 분업적이라는 데 있다. 고객 지원 자동화만 봐도 그렇다. 사용자의 발화는 자연어지만, 실제 처리 단계는 의도 분류, 계정 조회, 권한 확인, 정책 판단, 예외 대응, 결과 설명으로 쪼개진다. 여기에 음성이 끼어들면 실시간 응답성, 중간 끊김, 재질문, 오인식 보정까지 더해진다. 이 모든 과정을 하나의 거대한 프롬프트에 욱여넣는 방식은 초기에는 빨라 보이지만, 금방 유지보수 불가능한 상태로 간다.

단일 호출 중심 설계가 흔히 무너지는 이유는 세 가지다. 첫째, 책임이 섞인다. 판단과 실행, 검색과 요약, 정책과 문구 생성이 같은 문맥에서 일어나면 실패 원인을 분리하기 어렵다. 둘째, 실패가 조용하다. 도구 호출이 틀렸는지, 문맥이 오염됐는지, 중간 상태가 누락됐는지 보이지 않는데 결과만 그럴듯하게 나온다. 셋째, 수정 비용이 크다. 한 부분을 고치려면 전체 프롬프트와 전체 행동 패턴을 다시 건드려야 한다.

그래서 multi-agent는 화려한 아이디어라기보다 소프트웨어 공학적인 반작용에 가깝다. 복잡한 일을 역할별로 나누고, 서로 넘겨주고, 관찰 가능하게 만들고, 위험한 구간에는 제동 장치를 다는 것. 낯설어 보여도 사실은 오래된 설계 원칙이 LLM 위로 올라온 셈이다.

handoff는 라우팅이 아니라 책임 이전이다

많은 팀이 handoff를 단순 분기 처리로 이해한다. 이 질문은 A, 저 질문은 B. 얼핏 맞는 말이지만, 제품이 커질수록 이 정의는 너무 얕다. 진짜 handoff는 “누가 이 문제의 다음 소유자인가”를 결정하는 일이다. 소유권이 바뀌는 순간은 단순한 라우팅보다 훨씬 무겁다. 왜냐하면 그 뒤의 실패, 재시도, 설명 책임, 사용자 경험의 톤까지 함께 이동하기 때문이다.

예를 들어 결제 문제를 다루는 대화 흐름을 생각해보자. 처음에는 일반 상담 역할이 응대를 시작할 수 있다. 하지만 환불 규정 조회가 필요한 순간, 단지 관련 도구를 호출하는 것과 환불 전담 역할로 넘기는 것은 의미가 다르다. 전자는 여전히 같은 맥락 안에서 임시로 외부 능력을 쓰는 것이다. 후자는 판단 체계를 바꾸는 일이다. 규정 해석의 기준, 허용된 액션, 설명 문장의 보수성, 로그 수준까지 달라질 수 있다.

이 구분이 중요한 이유는 많은 장애가 “누가 결정했는지 불분명한 상태”에서 생기기 때문이다. 잘못된 답변보다 더 무서운 것은 잘못된 답변이 어디서 시작됐는지 모르는 상태다. handoff를 책임 이전으로 설계하면 tracing의 가치도 달라진다. 단순히 호출 체인을 보는 것이 아니라, 어느 시점에 정책 경계가 넘어갔는지 읽을 수 있어야 한다.

tools가 많아질수록 똑똑해지는 게 아니라 불안정해진다

도구는 에이전트 시스템을 유능하게 만드는 가장 빠른 수단이지만, 동시에 가장 빠르게 시스템을 무너뜨리는 요소이기도 하다. 검색, DB 조회, 사내 API 호출, 예약 변경, 결제 취소, 문서 검색, 티켓 발행. 할 수 있는 일이 늘어날수록 성공 사례는 멋있어지지만, 운영자는 다른 장면을 먼저 본다. 잘못된 파라미터, 순서가 뒤바뀐 호출, 중복 실행, 비멱등 액션의 재시도, 예상치 못한 부작용이 쌓인다.

그래서 tools를 기능 집합으로 다루면 늦는다. 실행 권한의 설계로 다뤄야 한다. 어떤 역할이 어떤 도구를 언제 쓸 수 있는지, 읽기와 쓰기를 어떻게 구분할지, 실패했을 때 누구에게 되돌릴지, 결과를 그대로 신뢰할지 아니면 다시 검토할지 같은 질문이 먼저 와야 한다. 특히 쓰기 작업이 포함되면 “실행 가능하다”와 “실행해도 된다”는 전혀 다른 문장이 된다.

여기서 guardrails가 장식이 아닌 이유가 드러난다. 많은 사람이 guardrails를 출력 문구 필터나 금칙어 처리 정도로 오해하는데, 실제로 더 중요한 역할은 시스템의 행동 반경을 자르는 데 있다. 어떤 도구 조합은 가능하지만 금지되어야 하고, 어떤 handoff는 허용되지만 특정 조건에서만 열려야 하며, 어떤 응답은 생성 자체보다 인간 확인을 요구해야 한다. 모델의 자유를 줄이는 일은 대개 성능 저하로 오해받지만, 운영 관점에서는 오히려 품질의 시작점이다.

guardrails는 모델을 못 믿어서가 아니라 제품을 지키기 위해 필요하다

AI 시스템의 사고는 종종 지능 부족보다 권한 과잉에서 터진다. 잘못 이해한 문장 하나보다 더 위험한 것은 너무 자신 있게 실행하는 행동이다. 특히 voice가 개입하는 순간 이 위험은 더 커진다. 음성 인터페이스는 텍스트보다 빠르고 자연스럽지만, 그만큼 재확인 없이 넘어가는 액션이 많다. 사람은 화면에서 읽을 때보다 들을 때 더 쉽게 흘려듣고, 시스템은 텍스트보다 음성 전사에서 더 많은 애매함을 품는다.

이때 guardrails는 “이 말은 해도 되는가”보다 “이 행동은 지금 해도 되는가”를 관리해야 한다. 계좌 이체, 예약 취소, 개인정보 조회, 약관 예외 처리 같은 영역에서는 응답 품질보다 절차 통제가 앞선다. 좋은 시스템은 친절한 문장을 만드는 시스템이 아니라, 위험한 시점에서 반드시 느려지는 시스템이다. 사용자 입장에서는 한 번 더 확인하는 경험이 번거로울 수 있다. 하지만 운영자는 안다. 그런 마찰이 없을 때 장애는 더 조용하고 더 비싸게 찾아온다.

이 설계는 보안팀만의 관심사가 아니다. 제품 경쟁력과도 직접 연결된다. 같은 일을 자동화하더라도 어떤 회사는 더 공격적으로 열고, 어떤 회사는 더 조심스럽게 닫는다. 차이는 기술력보다 리스크 모델에 있다. 그리고 그 리스크 모델은 결국 코드로 남아야 한다. 바로 이런 이유 때문에 orchestration 프레임워크에서 guardrails가 핵심 축으로 들어오는 흐름은 중요하다. 안전장치가 주변부 기능이 아니라 설계의 중심으로 올라온다는 뜻이기 때문이다.

tracing이 없으면 개선이 아니라 미신만 남는다

LLM 시스템은 겉으로 보면 대화형 제품이지만, 실제 운영은 분산 시스템에 더 가깝다. 입력이 들어오고, 역할이 바뀌고, 도구가 호출되고, 재시도가 발생하고, 예외가 우회되고, 최종 응답이 나온다. 이 흐름에서 tracing이 없다면 팀은 결국 체감과 인상으로 시스템을 판단하게 된다. “가끔 이상하다”, “어느 날부터 느리다”, “도구 호출이 많을수록 품질이 떨어지는 것 같다” 같은 말은 자주 나오지만, 그 자체로는 아무것도 고칠 수 없다.

관측 가능한 에이전트 시스템은 적어도 네 가지를 남겨야 한다. 누가 시작했는지, 어디서 넘겨받았는지, 어떤 도구를 썼는지, 왜 멈췄는지. 여기에 latency와 token 비용만 붙여서는 부족하다. 특히 handoff가 많은 구조에서는 성공률보다 경로 분포가 중요해진다. 원래는 세 단계면 끝나야 할 일이 여섯 단계까지 늘어나는가, 특정 역할로 몰리는가, 특정 도구 직후 실패가 급증하는가 같은 신호를 읽어야 한다.

이런 데이터가 쌓이면 재미있는 사실이 보이기 시작한다. 성능 문제처럼 보였던 것이 사실은 라우팅 문제였고, 라우팅 문제처럼 보였던 것이 사실은 도구 스키마 문제였고, 도구 문제처럼 보였던 것이 사실은 guardrails 충돌일 수 있다. 시스템이 복잡해질수록 정답은 더 똑똑한 프롬프트가 아니라 더 좋은 계측에서 나온다. tracing은 디버깅 도구가 아니라 설계 도구다.

짧은 예시는 이런 감각을 잘 보여준다.

const result = await orchestrator.run({
  input: userUtterance,
  trace: {
    sessionId,
    tags: ["billing", "voice"],
  },
  guardrails: {
    requireConfirmationFor: ["refund", "cancel_subscription"],
  },
});

이 코드에서 중요한 것은 문법보다 철학이다. 실행은 응답만 내는 일이 아니라, 추적 단위를 만들고, 위험 액션을 제한하고, 나중에 다시 읽을 수 있는 사건으로 남기는 일이라는 점이다.

voice가 들어오면 설계는 갑자기 현실적이 된다

텍스트 기반 데모는 종종 시스템을 과대평가하게 만든다. 화면 위의 대화는 사용자가 천천히 읽고, 필요하면 위로 스크롤하며, 애매하면 다시 복사해 물어볼 수 있다. 음성은 다르다. 말은 지나가고, 오해는 즉시 누적되며, 침묵은 곧바로 불안으로 번역된다. 그래서 voice는 단순한 입력 채널이 아니라 orchestration의 약점을 가장 빨리 드러내는 시험장이다.

실시간 음성 흐름에서는 응답 품질만으로는 부족하다. 부분 응답을 언제 시작할지, 중간 끼어들기를 어떻게 처리할지, 불완전한 인식 상태에서 도구 호출을 보류할지, 긴 작업 동안 어떤 피드백을 줄지, 최종 확정 전에 어떤 문장을 다시 읽어줄지가 모두 중요해진다. 이 문제들은 거대한 범용 모델 하나로 해결되기보다, 역할 분해와 상태 관리가 잘된 시스템에서 더 잘 풀린다.

예컨대 음성 상담에서 “예약을 바꿔줘”라는 문장은 그 자체로는 작업을 끝낼 수 없다. 날짜가 필요하고, 시간대가 필요하고, 충돌 검사가 필요하고, 변경 수수료 정책이 필요할 수 있다. 텍스트 채팅에서는 누락된 정보를 다시 물으며 천천히 전진할 수 있지만, 음성에서는 질문 하나를 더 던질 때마다 사용자의 인내심이 빠르게 줄어든다. 그래서 voice 환경에서는 한 번에 모든 답을 하려는 충동보다, 최소 마찰로 필요한 정보를 수집하는 choreography가 더 중요하다. 결국 잘 설계된 multi-agent는 더 많이 말하는 시스템이 아니라, 덜 헷갈리게 이어가는 시스템이 된다.

JavaScript 현장에서 이 흐름이 의미하는 것

JavaScript와 TypeScript 환경에서 이런 프레임워크가 갖는 무게는 생각보다 크다. 많은 팀에게 실제 서비스의 접점은 브라우저, Node 서버, Edge 런타임, 실시간 통신, 음성 인터페이스, 로그 파이프라인 위에 있다. 즉, orchestration은 연구용 노트북 안이 아니라 제품 코드 한가운데로 들어와야 한다. 이때 필요한 것은 대단한 이론보다도, 역할 정의와 도구 연결, 추적과 제약을 같은 언어권 안에서 다룰 수 있는 일관성이다.

중요한 변화는 “LLM 기능을 붙인다”에서 “에이전트 시스템을 운영한다”로 시선이 바뀐다는 점이다. 전자는 기능 팀의 실험으로 끝날 수 있다. 후자는 플랫폼 팀, 보안 팀, SRE, 프론트엔드, 백엔드가 함께 보는 운영 문제다. 누가 어떤 trace를 읽는지, 어떤 실패를 경보로 볼지, 음성 흐름에서 장애를 어떻게 재현할지, 도구 스키마 변경이 어느 역할에 영향을 주는지 같은 질문은 전부 소프트웨어 조직의 문제다.

그래서 openai-agents-js 같은 흐름은 단순히 “JavaScript용 SDK가 하나 더 나왔다”는 소식으로 읽으면 아쉽다. 더 정확하게는, 에이전트 시스템을 애플리케이션의 주변 기능이 아니라 아키텍처 구성 요소로 다루기 시작했다는 신호로 읽어야 한다. handoff는 함수 분리와 닮아 있고, tools는 외부 의존성과 닮아 있으며, guardrails는 정책 엔진과 닮아 있고, tracing은 observability와 닮아 있다. 낯설어 보이지만 결국 익숙한 공학의 연장선이다.

흔한 함정은 지능이 아니라 구조에서 나온다

현장에서 가장 흔한 실수는 역할을 너무 많이 쪼개는 것이다. 분업은 좋아 보이지만, handoff가 많아질수록 지연과 비용, 책임 공백도 함께 늘어난다. 반대로 모든 걸 한 역할에 몰아넣으면 초반에는 단순해 보이지만, 곧바로 수정 불가능한 괴물이 된다. 좋은 경계는 도메인 사전이 아니라 실패 양상에서 나온다. 어디서 자주 틀리는지, 어떤 액션이 위험한지, 어떤 설명이 자주 재질문을 부르는지 보고 역할을 자르는 편이 낫다.

또 다른 함정은 tracing을 사후 장식으로 붙이는 일이다. 처음에는 “돌아가게 만든 뒤 계측하자”가 유혹적이다. 하지만 에이전트 시스템은 처음부터 무엇을 남길지 결정하지 않으면, 나중에 아무리 로그를 추가해도 핵심 원인을 놓치기 쉽다. 특히 voice에서는 더 그렇다. 사용자 발화, 전사 결과, 중간 판단, 도구 호출, 재확인 문장이 서로 다른 타이밍으로 흘러가므로, 나중에 합치려 하면 사건의 순서가 이미 흐려진다.

guardrails도 자주 오해된다. 규칙을 많이 넣을수록 안전할 것 같지만, 지나치게 촘촘한 제약은 시스템을 겁먹은 상태로 만들 수 있다. 모든 걸 차단하는 시스템은 안전해 보이지만, 결국 사람에게 계속 넘기게 되고 자동화의 경제성을 잃는다. 중요한 것은 강한 제약이 아니라 선명한 제약이다. 금지할 것은 분명히 금지하고, 허용할 것은 필요한 조건과 함께 허용해야 한다. 회색지대를 줄이는 일이 핵심이다.

제품의 품격은 매끄러운 데모가 아니라 이상 징후를 다루는 방식에서 드러난다

멀티 에이전트 시스템이 실제 경쟁력을 만드는 순간은 성공 시연이 아니라 예외 처리에서 보인다. 사용자가 말을 바꿨을 때, 잘못 들었을 때, 도구가 느릴 때, 정책상 바로 실행할 수 없을 때, 사람이 개입해야 할 때 경험이 어떻게 유지되는가가 더 중요하다. 이때 좋은 제품은 전지전능해 보이려 하지 않는다. 대신 자신의 경계를 정확히 알고, 필요한 순간에 흐름을 안전하게 전환한다.

그런 시스템은 겉으로는 덜 화려할 수 있다. 하지만 운영팀은 안다. 조용히 잘 멈추는 구조가 결국 오래 간다. 추적 가능한 handoff, 절제된 tools, 선명한 guardrails, 읽을 수 있는 tracing, 끊기지 않는 voice 흐름. 이 다섯 가지가 한 축으로 묶이는 순간, 에이전트는 데모의 주인공이 아니라 제품의 하부 구조가 된다.

결국 승부는 누가 더 사람처럼 말하느냐보다, 누가 더 소프트웨어답게 협업하느냐에서 갈린다. 단일 호출의 시대에는 모델의 문장력이 제품을 끌고 갔다. 이제는 역할의 경계, 실행의 권한, 추적의 해상도, 음성의 리듬이 함께 제품을 만든다. 에이전트가 서로 일하는 방식을 설계하는 일은 더 이상 구현 디테일이 아니다. 그것이 곧 신뢰의 구조이고, 비용의 구조이며, 차별화의 구조다.

댓글

댓글을 읽어오는 중입니다.