에이전트 협업 열풍, 방은 "90%는 자동화 포장"이라 진단했다

질문 하나가 쏘아 올린 논쟁

오후 1시 23분, 마케터로 일한다는 한 참여자가 방에 오래 눌러두고 있던 질문을 꺼냈다. "에이전트들끼리 협업시켜서 돌리는게 현실적으로 맞는걸까요"라고 물으며, 쓰레드나 인스타그램에서 흔히 도는 '에이전트들이 회사를 운영한다'는 사례들이 실은 토큰만 축내는 구조 아니냐고 되짚었다. 정해진 프롬프트와 워크플로우대로 흘러가는 자동화를 그럴듯한 이름으로 포장한 건 아닌지 묻는 질문이었다.

3분 뒤 답이 붙었다. 한 참여자는 겉으로 보이는 협업 시연에는 실체가 없다고 잘라 말했다.

"인스타 협업은 의미가 없고 그저 보여주기용도 입니다. 실제 그런식으로 수평적 org 로 하는 경우도 있는데 무한루프 문제로 항상 리밋을 줘야하고, 특히 쓰레드 인스타에서 보여주는건 그냥 자극적 연출만을 위한 거죠"

이어 붙은 답은 처음 질문자의 손을 들어줬다.

"결론적으로, 지금 "에이전트들끼리 협업시켜서 기업을 돌린다"고 하는 사례의 90% 이상은 '잘 기획된 워크플로우 자동화(Workflow Automation) 시스템'을 트렌디한 용어로 포장한 것에 가깝습니다. 정해진 프롬프트와 워크플로우대로 흐르는 자동화로 보신 질문자님의 시각이 100% 맞습니다."

그래도 남는 절충안

논의는 부정으로만 끝나지 않았다. 다른 참여자는 실무에서 바로 쓸 수 있는 절충 원칙을 내놓았다. "제일 안전한건 Ai로 분석하고 체계화한다음 ai가 아닌 코드로 자동화를 해두는게 제일 안전할거같아요"라는 제안이었다. 판단은 AI에 맡기되, 반복 실행은 결정론적인 코드로 굳혀두라는 뜻으로 읽혔다.

앞서 "90% 이상은 포장"이라 잘라 말했던 참여자는 자신이 실제로 돌리는 구조를 소개하며 대화를 정리했다. 그의 오케스트레이션은 두 층으로 나뉜다 — 작업 전문성과 툴·경험을 담은 슬롯, 그리고 그 슬롯을 구동하는 LLM 정의다. 웹을 만든다면 디자인·백엔드·프론트엔드·데이터베이스 슬롯에 각각 에이전트를 배치하고, 클로드 페이블(Fable) 같은 모델이 조율을 맡고 소넷과 코덱스 GPT-5.6의 소형 모델(내부에서는 루나로 불린다)이 실무 워커로 붙는 식이다. 그는 "N8n이나 드래그 드롭 워크플로우는 그냥 자동화지 에이전트라고 부를 수 없다"고 선을 그으며, 자신이 말하는 오케스트레이션과 앞서 지적받은 '보여주기용 협업'을 구분했다.

실전성 검증대에 오른 유행어

이 논쟁이 이 정도로 진지하게 오간 건 우연이 아닌 것으로 보인다. '에이전트 오케스트레이션'이 쓰레드·인스타그램에서 화려하게 소비되는 사이, 실제로 돈과 토큰을 쓰는 실무자들 사이에서는 그 이름값에 걸맞은 실체가 있는지 확인하려는 요구가 쌓여온 것으로 보인다. 90% 포장론과 코드-자동화 절충안이 같은 대화 안에서 동시에 나온 건, 유행어와 엔지니어링 현실 사이의 간극을 이 방이 스스로 좁혀가고 있다는 신호로 읽힌다. 오케스트레이션을 자처하는 구조라도 결국 무엇이 판단하고 무엇이 반복 실행을 맡는지 층을 나눠 설명할 수 있어야 한다는 합의가, 이번 대화의 실질적인 결론에 가까웠다.