AI가 끝까지Graph와 multi-agent가 왜 주목받는지 찾아보다가 질문 하나가 남았다. AI가 그 판단을 할 수 있다는 것과, 그 판단까지 내가 맡겼다는 것은 같은 말일까.
오늘 유독 Graph와 multi-agent에 대한 글을 많이 봤다.
여러 AI가 일을 나눠서 하고, 한쪽의 결과를 다른 쪽이 이어받고, 실패하면 다시 수정하고 테스트한다. 사람은 그 사이에서 작업을 하나씩 넘겨주지 않아도 된다.
왜 이렇게 주목받는지 궁금해서 조금 찾아봤다.
Graph가 실제로 바꾸는 것
Graph의 핵심은 AI를 여러 개 쓰는 것 자체보다 작업의 흐름을 구조로 만드는 것에 가까웠다.
예를 들어,
개발 → 테스트 → 실패하면 수정 → 다시 테스트 → 성공하면 검증
대화형으로 일하면 이 사이를 사람이 연결한다. 개발을 요청하고, 결과를 보고, 테스트를 요청하고, 오류가 있으면 다시 수정해달라고 한다. 실제 작업은 AI가 하지만 작업의 흐름을 관리하는 건 여전히 사람이다.
Graph에서는 이 연결 자체를 시스템으로 만든다. 사람이 머릿속으로 들고 있던 흐름이 다음과 같은 요소로 실행 구조 안에 드러난다.
- Node — 분석, 개발, 테스트, 사람의 승인 같은 실행 단위
- Edge와 Branch — 한 작업의 결과를 어디로 보낼지, 성공과 실패에 따라 어느 길로 갈지
- Loop — 수정하고 다시 검증하는 반복
- Fan-out과 Fan-in — 독립적인 작업을 동시에 돌리고 결과를 다시 합치기
- State — 결과, 변수, 승인 여부 같은 실행 상태
- Interrupt와 Checkpoint·Resume — 사람이나 외부 입력이 필요할 때 멈추고, 상태를 저장한 뒤 같은 지점에서 다시 이어가기
다음에 무엇을 할지 정하는 일이 대화 속 사람의 지시에서 실행 구조로 옮겨 가는 것이다. 프로젝트 지침을 읽고 스스로 순서를 정하는 Agent와도 다르다. 지침은 Agent가 해석하는 규칙이고, Graph는 흐름과 경계의 일부를 실행 구조 자체에 넣는다. 둘은 배타적이지 않아서 함께 쓸 수 있다.
발전 단계가 아니라 서로 다른 운영 방식
조금 더 동적인 방식도 있다. 총괄 Agent가 상황을 보고 일을 나누고, 필요한 전문 Agent를 호출하고, 각각의 결과를 다시 모은다. 같은 일, 예를 들어 “쇼핑몰의 구매 전환을 개선해줘”를 서로 다른 방식으로 돌리면 차이가 보인다.
| 운영 방식 | 다음 작업을 정하는 쪽 | 사람의 역할 | 강점 | 어려움 |
|---|---|---|---|---|
| 대화형 | 사람 | 계속 지휘 | 유연함 | 관리 부담 |
| 지침형 Agent | AI가 지침과 맥락을 해석 | 목표와 중요한 판단 | 유연성과 자동화 | 모델의 해석에 의존 |
| 고정 Graph | 시스템 설계자가 정한 Node·Edge·조건 | 예외와 승인 | 재현성과 통제 | 예상 못 한 상황 |
| 동적 Multi-Agent | 총괄 AI가 실행 중 분해 | 목표와 감독 | 탐색과 병렬화 | 추적·비용·통제 |
| 혼합형 | 고정된 경계 안에서 AI가 동적으로 판단 | 경계와 중요한 선택 | 통제와 유연성 | 경계를 어떻게 설계할지 |
찾아보니 특정 회사만의 방식도 아니었다. Google은 ADK Go 2.0에서 Graph 기반 Workflow 엔진과 내장 HITL, 동적 오케스트레이션을 함께 내놓았다.1 Microsoft Agent Framework는 순차·병렬 실행, Agent 간 업무 전달(handoff), 그룹 대화, 총괄 Agent가 계획을 세우고 조정하는 방식까지 제공하고, 사람이 그 계획을 실행 전에 검토하게 할 수도 있다.2 OpenAI는 총괄 Agent가 전문 Agent를 도구처럼 부르는 방식과 대화를 전문 Agent에게 넘기는 방식을 구분한다.3 Anthropic의 Research 기능은 lead agent가 여러 subagent를 병렬로 움직이는 구조를 실제 제품에 쓴다.4
중요한 건 이 방식들이 어느 한쪽으로 발전하는 단계가 아니라는 점이었다. 어떤 일은 사람이 흐름을 미리 정하는 편이 낫고, 어떤 일은 AI가 상황을 보고 다음 행동을 결정하는 편이 낫다. 실제 시스템은 둘을 섞는다.
Agent가 많다고 무조건 좋은 것도 아니다. Agent가 늘면 상태와 추적, 비용과 승인 지점도 함께 늘어난다. Anthropic은 multi-agent 리서치 시스템이 일반 대화보다 약 15배의 토큰을 쓴다고 밝혔고,4 OpenAI도 전문 Agent는 실제로 나눌 필요가 있을 때 추가하라고 안내한다.3
그래서 왜 사람들이 이 방식에 관심을 갖는지는 금방 이해됐다. AI가 충분히 일을 할 수 있게 되면서 이제는 ‘어떻게 더 좋은 답을 한 번 받을까’에서 ‘어떻게 일을 나누고 오래 맡길까’로 관심이 이동하고 있는 것처럼 보였다. 사람이 사라지는 것이 아니라, 작업을 전달하는 일은 시스템으로 옮겨 가고 사람은 목표와 경계, 새로운 방향 같은 판단에 남는 쪽으로 역할이 이동하고 있었다.
생각해보니 나도 비슷하게 일하고 있었다
나는 AI에게 개발을 맡길 때 코드를 한 줄씩 확인하고 싶지는 않다.
개발하고, 테스트하고, 문제가 있으면 수정하고, 다시 검증하는 과정은 알아서 진행하고 결과를 가져왔으면 한다.
중간 과정마다 허락을 구하는 것보다 내 판단이 정말 필요한 순간에만 멈추는 것을 원한다.
그런데 Graph를 보다 보니 여기서 하나가 궁금해졌다.
그 ‘정말 필요한 순간’은 누가 정하지?
예를 들어 쇼핑몰의 구매 전환을 개선해달라고 했고, 전체 계획도 승인했다고 해보자.
AI가 개발하고 테스트하던 중 이런 판단을 한다.
상품 구조 자체를 바꾸면 더 좋은 결과가 나올 것 같습니다.
기술적으로 할 수 있다. 구매 전환 개선이라는 원래 목표에도 맞는다.
그렇다면 그냥 바꾸면 될까?
테스트가 실패했을 때 코드를 어떻게 수정할지까지 내가 결정하고 싶지는 않다.
그런데 상품 구조 자체를 바꿀지는 조금 다르다.
둘 다 AI에게는 ‘다음 행동을 선택하는 일’일 수 있지만, 사람에게는 같은 종류의 선택이 아닐 수 있다.
| 상황 | AI가 할 수 있는 일 | 사람에게는 어떤 선택인가 |
|---|---|---|
| 테스트 실패 | 오류를 고치고 다시 테스트 | 실행의 판단. 맡겨도 된다 |
| 버튼 구현 방식 | 기술을 골라 구현 | 실행의 판단. 대체로 맡길 수 있다 |
| 상품 구조 변경 | 제품의 방향을 바꿈 | 새로운 방향. 처음 맡긴 범위에 들어가는가? |
| 가격 정책 변경 | 사업 정책을 바꿈 | 새로운 선택. 사람에게 돌려야 하지 않을까? |
| 과거 승인과 지금의 말이 다를 때 | 어느 쪽이 지금 유효한지 판단 | 미리 정한 승인 지점만으로 충분한가? |
사람을 부르는 장치는 이미 있다
앞에서 본 것처럼 Graph에는 이미 사람을 부르는 장치가 있다. 특정 지점에서 실행을 멈추고, 사람의 승인이나 입력을 받은 뒤 같은 지점에서 다시 이어가는 Human-in-the-Loop, HITL이다.
예를 들어,
데이터 삭제 → 사람 승인
일정 금액 이상 결제 → 사람 승인
테스트 실패 → AI가 자동 수정
같은 구조는 미리 만들 수 있다.
그러면 문제는 Graph에 사람을 넣을 수 있느냐가 아니었다.
어디에서 다시 사람을 불러야 하는지를 어떻게 정하느냐였다.
사람이 AI의 일에 끼어드는 방식을 세 가지로 나란히 놓아 보면, 내가 찾는 구조가 보인다.
사람의 부담은 크고, AI의 자율성은 작다.
부담은 작지만, 중간에 생긴 중요한 판단까지 넘어갈 수 있다.
사람은 판단이 필요한 순간에만, 그 판단만 한다.
세 번째 구조도 Graph로 만들 수 있다. 조건에 따른 분기를 두거나, 원래 맥락·맡긴 범위·행동의 영향을 기준으로 시스템이 사람에게 결정을 돌려주도록 만들 수 있다. 다만 AI가 ‘새 판단’이라고 분류했다는 사실만으로 돌려줄 기준이 완성되는 것은 아니다. 그림의 ‘새 판단이 필요한가?’ 안에는 실제로 적어도 세 가지 물음이 들어 있다.
- 근거 — 이미 내린 판단으로 계속할 근거가 충분한가
- 정보 — 정보가 부족하거나 서로 충돌하는가
- 영향 — 외부에 영향을 주거나 되돌리기 어려운 행동인가
앞의 두 물음은 판단이 얼마나 불확실한지를, 마지막 물음은 그 행동을 해도 되는 권한이 있는지를 묻는다. 둘은 같은 값이 아니어서 따로 다뤄야 한다. 판단이 분명해도 되돌리기 어려운 행동이라면 사람에게 돌아와야 할 수 있고, 영향이 작은 행동이라도 근거가 흔들리면 물어야 할 수 있다.
그리고 비어 있는 것은 장치가 아니라 일반적인 기준이다. 이 프레임워크들은 멈추고 돌려주는 방법을 제공하지만, 특정한 사람과 AI의 관계에서 무엇을 ‘새 판단’으로 볼지, 그 기준이 처음 맡긴 범위와 이전의 판단에서 어떻게 나오는지까지 정해 주지는 않는다.
미리 예상할 수 있는 위험은 규칙으로 만들 수 있다.
하지만 실제로 일을 하다 보면 처음에는 없었던 선택지가 생기고, 상황이 달라지고, 며칠 전에 했던 판단이 지금도 그대로 유효한지 애매해지는 순간이 생긴다.
그 순간에도 AI는 꽤 좋은 답을 만들어낼 수 있을 것이다.
그런데 여기에는 다른 질문이 남는다.
AI가 그 판단을 할 수 있다는 것과
그 판단까지 내가 맡겼다는 것은 같은 말일까?
나는 Graph 같은 방식이 반갑다. 내가 Mediation으로 설명해 온 구조의 일부를 실제 실행 구조로 구현할 수 있는 기술적 기반이 점점 구체화되고 있기 때문이다. 어디에서 멈추고, 어떤 상태를 저장하고, 사람의 응답 뒤에 어디서부터 다시 이어갈지를 실행 흐름 안에 명시할 수 있다는 것은, 판단을 이어 쓰고 필요한 순간에 사람에게 돌려주는 일을 이제 설계의 대상으로 다룰 수 있게 되었다는 뜻이다.
그래서 질문은 오히려 더 분명해졌다. 멈출 수 있는 지점을 만들 수 있게 된 지금, 어디에서 멈춰야 하는지는 누가, 무엇을 기준으로 정하는가.
사람의 개입을 줄이는 것과 사람의 선택을 줄이는 것은 같지 않다.
자동화할 수 있는 것과 위임해도 되는 것도 같지 않다.
내가 지키고 싶은 것은 모든 단계에 끼어드는 권한이 아니다. 일이 흘러가는 동안에도 무엇이 중요한지 내가 이해하고 있고, 처음과 다른 선택이 생겼을 때 그것을 내 선택으로 다시 고를 수 있는 자리다.
AI가 어디까지 갈 수 있는지를 만드는 기술은 빠르게 발전하고 있다. 나는 그 옆에서, AI가 어디에서 다시 사람에게 돌아와야 하는지, 그리고 돌아왔을 때 사람이 무엇을 보고 고를 수 있어야 하는지를 더 연구해 보고 싶다.
아직 답을 정한 것은 아니다. 다만 더 많은 Agent가 더 오래 일하게 될수록 이 질문은 더 자주 만나게 될 것 같고, 그래서 지금 붙잡아 두고 싶다.
참고 자료
- Google Developers Blog (2026-06-30). Build reliable multi-agent applications with ADK Go 2.0. 원문
Graph 기반 workflow 엔진, 내장 HITL, 동적 오케스트레이션 소개. - Microsoft Learn. Workflow orchestrations in Agent Framework. 원문
Sequential·Concurrent·Handoff·Group Chat·Magentic 오케스트레이션과 사람의 개입. - OpenAI Agents SDK. Agent orchestration. 원문
manager(agents as tools)와 handoff 방식. - Anthropic Engineering (2025-06-13). How we built our multi-agent research system. 원문
lead agent가 병렬 subagent를 조정하는 orchestrator-worker 구조.