2016년 알파고 대국, 기억하는 사람 많을 거야. 나도 그때 생중계 보면서 진짜 충격받았거든. 세계 최강 바둑기사가 AI한테 무너지는 걸 실시간으로 봤으니까.
그런데 10년이 지난 2026년 3월 9일, 이세돌 9단이 다시 AI 앞에 섰다. 같은 장소, 서울 종로구 포시즌스 호텔. 근데 이번엔 맥락이 완전히 달랐어.
사진 = 구글 제공
📌 팩트 체크 먼저: 인스타그램에 떠도는 게시물에서 “단 61수, 10분 만의 패배”라고 적혀 있는데, 이건 과장된 표현이야. 실제 행사는 오후 1시~1시 30분 30분간 진행된 기술 시연 행사였고, 순수한 승부 대국이 아니라 AI 협업 데모가 핵심이었어. 아래에서 자세히 정리할게.
이번 대국, 정확히 뭔 일이 있었나
핵심은 이거야. 10년 전처럼 “인간 vs AI 승부”가 목적이 아니었어. 인핸스가 주최한 ‘에이전틱 AI 상용화 글로벌 캠페인’ 행사에서, 이세돌 9단이 직접 AI와 협업해 바둑 모델을 만들고 그 모델과 대국하는 시연을 보인 거야.
실제로 어떻게 진행됐나
이세돌 9단이 무대에 올라서 인핸스의 AI 에이전트에게 음성 명령을 내렸어.
“나와 대국을 펼칠 수 있는 수준의 바둑 모델을 만들어 줘”
그러자 AI 에이전트가 바둑 관련 웹사이트, 아마존 도서, 유튜브 자료 등을 실시간으로 수집해서 약 30분 만에 바둑 AI 모델 ‘유아’를 완성했어.
⚠️ 팩트 체크: 일부 게시물에서 “20분 만에 완성”이라고 나오는데, 복수의 언론 보도 기준으로 약 30분이 정확한 수치야.
이어서 이세돌 9단이 직접 이 AI와 대국을 시작했는데, 반응 속도와 수준에 본인도 놀란 표정이었다고 해.
이세돌이 직접 한 말들
이날 이세돌 9단의 발언이 꽤 인상적이었어.
“방금 제가 둔 수 좀 물러도 되겠습니까? 제가 만든 얘가 바둑을 너무 잘 둬서 사람이 이기는 건 어렵겠는데요”
그러면서 이렇게 덧붙였어.
“체감상 10년 전 알파고보다 훨씬 뛰어난 수준” “사람이 아니라고 느껴지는 속도”
그리고 핵심 메시지는 이거야:
“나 같은 AI 문외한이 말 몇 마디로 이런 수준급 모델을 만든다는 것은 인간과 AI가 어떻게 협업을 해야 하는지 보여주는 사례다. 이제 AI는 승부나 경쟁의 대상이 아니라, 인간이 더 큰 창의성을 발휘할 수 있게 돕는 도구로 정의돼야 한다.”
마무리
이번 행사에서 내가 가장 인상 깊었던 건, 이세돌 9단이 AI에 맞서는 게 아니라 AI를 쓰는 사람이 됐다는 거야.
10년 전엔 “인간이 AI를 이길 수 있나”가 질문이었다면, 2026년 지금은 “AI를 얼마나 잘 활용하느냐”가 진짜 질문이 된 거지.
개발자 입장에서 솔직히 공감가는 게, 요즘 좋은 결과물이 나오는 사람들이 코딩을 잘하는 사람보다 AI한테 의도를 잘 전달하는 사람인 경우가 많거든. 이세돌이 바둑 경험으로 AI한테 명령을 내리고 수준급 모델을 만든 것처럼, 앞으로는 도메인 지식 + AI 활용 능력의 조합이 핵심 역량이 될 것 같아.
솔직히 처음에 “AI 에이전트”라는 말 들었을 때, 그냥 ChatGPT 좀 더 잘 쓰는 거 아닌가 싶었다. 근데 직접 만들어보니까 얘기가 완전 달라진다. 어떻게 연결하고, 어떻게 역할을 나누느냐에 따라 결과물 품질이 하늘과 땅 차이다.
나도 요즘 Claude 기반으로 AI 에이전트 구조를 설계하면서 Anthropic 공식 문서를 꽤 뒤졌는데, 공식적으로 권장하는 패턴이 딱 5가지로 정리돼 있더라. 이걸 알고 나서 “아, 내가 그냥 감으로 짜고 있었구나” 싶었다. 오늘은 그 5가지를 개발자 입장에서 가능한 쉽게 풀어볼게.
그리고 이번엔 실제 비용도 같이 따져본다. 패턴마다 API 호출 구조가 다르다 보니, 어떤 패턴이 얼마나 비싼지 알고 선택하는 게 중요하다.
비용 계산 기준
Claude API는 입력 토큰 + 출력 토큰 기준으로 과금된다. 2025년 기준 주요 모델 요금은 아래와 같다.
모델
입력 (1M 토큰)
출력 (1M 토큰)
Claude Haiku 3.5
$0.80
$4.00
Claude Sonnet 4
$3.00
$15.00
Claude Opus 4
$15.00
$75.00
이 글에서는 Sonnet 4 기준, 1회 호출당 입력 1,000 토큰 + 출력 500 토큰 조건으로 계산한다. 이 기준으로 단일 호출 비용은 약 $0.011 (약 15원). 이걸 1배로 놓고 패턴별로 비교해보자.
1. Prompt Chaining — 가장 기본, 그래서 가장 안전한
구조는 단순하다. 설계 → 구현 → 검증, 순서대로 넘긴다.
앞 단계의 출력이 다음 단계의 입력이 되는 방식이다. 마치 공장 컨베이어벨트처럼. 복잡한 마법은 없고, 그래서 오히려 디버깅이 쉽다.
예를 들면 이런 식이다:
1단계: “이 기획서를 분석해서 핵심 요구사항 뽑아줘”
2단계: “위 요구사항 기반으로 코드 짜줘”
3단계: “이 코드에서 버그나 개선점 찾아줘”
Anthropic이 가장 먼저 권장하는 이유가 있다. 단순하고 예측 가능하다. 처음 에이전트 시스템 만드는 거라면 무조건 여기서 시작하는 게 맞다.
💰 비용 수준: 낮음 — 단일 호출의 N배 호출 횟수 = 단계 수. 3단계 체인이면 단일 대비 3배. 각 단계가 독립적이라 컨텍스트 누적이 적어서 토큰이 크게 불어나지 않는다. 3단계 기준 약 $0.03 (약 45원)
2. Routing — 작업 난이도에 따라 모델을 나눈다
모든 요청에 Opus를 붙이면 비용이 폭발한다. Routing 패턴은 이 문제를 해결한다.
복잡한 작업 → 고성능 모델 (예: Opus)단순한 작업 → 경량 모델 (예: Haiku)
분류기가 먼저 요청을 판단하고, 적절한 모델로 라우팅한다. 실제로 서비스 운영할 때 API 비용 최적화에 꽤 효과적이다. 사용자 입장에서는 차이를 못 느끼는데, 인프라 비용은 확실히 줄어든다.
개발자라면 이런 생각 해봤을 거다. “이 요청은 굳이 GPT-4o 써야 하나?” Routing이 그 고민에 대한 공식 답변이다.
💰 비용 수준: 가장 낮음 — 유일한 절감 패턴 분류 콜(Haiku) 1회 + 실제 처리 콜 1회. 요청의 70%가 Haiku로 처리된다고 가정하면 Sonnet 단독 대비 비용 60~70% 절감 가능. 트래픽이 많을수록 효과가 극적으로 커진다. 단일 호출 대비 0.2~1배 (상황에 따라 더 저렴)
3. Parallelization(Voting) — 같은 문제를 여러 에이전트가 동시에 푼다
이게 좀 재밌다. 동일한 문제를 에이전트 A, B, C가 각각 독립적으로 풀고, 결과를 종합해서 최선을 고른다.
일종의 다수결 투표 방식이다. 한 에이전트가 틀려도 나머지가 커버할 수 있어서 신뢰도가 높아진다. 특히 정답이 하나로 수렴하기 어려운 창의적 작업이나 판단이 필요한 작업에 강하다.
단점은 당연히 비용. 같은 작업을 3번 돌리니까. 그래서 정확도가 중요한 핵심 기능에만 선택적으로 쓰는 게 현실적이다.
💰 비용 수준: 중간~높음 — 에이전트 수에 정직하게 비례 에이전트 3개 + 결과 종합(Aggregator) 콜 1회 = 총 4회 호출. 약 $0.04~0.05 (약 60~70원) “신뢰도를 돈으로 사는” 패턴이다. 어디에 정확도가 필요한지 선별해서 써야 한다.
4. Orchestrator-Workers — 가장 강력한 구조
구조도 복잡하고 설계도 어렵지만, 제대로 만들면 가장 강력하다.
오케스트레이터가 큰 작업을 받아서 동적으로 분해한다. 그리고 각각을 워커 에이전트에게 위임한다. 워커들이 각자 처리한 결과를 오케스트레이터가 종합한다.
예를 들어 “이 앱 전체 리팩토링해줘”라는 요청이 들어오면:
오케스트레이터: 작업을 분析하고 “파일 구조 정리 / 컴포넌트 분리 / API 통합”으로 나눔
워커 A: 파일 구조 담당
워커 B: 컴포넌트 분리 담당
워커 C: API 통합 담당
오케스트레이터: 결과 종합 후 최종 출력
현실적으로 LLM 기반 오케스트레이터가 항상 최선의 분해를 하지는 않는다. Anthropic도 이 점을 솔직하게 경고한다. 오케스트레이터가 워커보다 나은 판단을 항상 하는 건 아니라고.
💰 비용 수준: 높음 — 5가지 중 가장 비싸다 오케스트레이터는 보통 Opus급 모델을 쓴다. Opus 4 기준 호출 1회만 해도 $0.09 (약 130원). 여기에 워커 3개(Sonnet) 호출까지 더하면 1회 파이프라인에 $0.12~0.20 (약 180~300원). 단순 Sonnet 단일 호출 대비 10~18배 비싸다. 비용이 정당화되는 작업인지 반드시 먼저 따져봐야 한다.
5. Evaluator-Optimizer — 품질을 반복으로 끌어올린다
생성 에이전트와 평가 에이전트가 루프를 돈다.
생성 에이전트가 결과물을 만든다
평가 에이전트가 기준에 맞는지 검토한다
기준 미충족 → 다시 생성
기준 충족 → 종료
코드 리뷰, 글쓰기 퀄리티 체크, 번역 품질 검증 같은 데 쓰기 좋다. 반복 횟수 제한을 걸어두지 않으면 무한루프에 빠질 수 있으니 max iteration 설정은 필수다.
💰 비용 수준: 가변적 — 가장 예측이 어려운 패턴 루프 1회 = 생성 콜 + 평가 콜 = 약 $0.02. 평균 3회 반복이면 $0.06 (약 90원). 기준을 너무 높게 잡으면 루프가 10회를 넘기도 한다. 그러면 비용이 순식간에 $0.20을 넘어선다. max iteration은 반드시 5 이하로 고정할 것.
패턴별 비용 한눈에 보기
패턴
예시 호출 수
1회 비용 (Sonnet 기준)
단일 대비
비용 예측 가능성
Prompt Chaining (3단계)
3회
~$0.03 (약 45원)
3배
✅ 예측 쉬움
Routing
2회
~$0.002~0.011 (3~15원)
0.2~1배
✅ 예측 쉬움
Parallelization (3 에이전트)
4회
~$0.04 (약 60원)
4배
✅ 예측 쉬움
Orchestrator-Workers
5회+
~$0.15~0.20 (180~300원)
10~18배
⚠️ 작업에 따라 변동
Evaluator-Optimizer (3루프)
6회
~$0.06 (약 90원)
6배
⚠️ 루프 수에 따라 변동
실전에서 쓰는 조합 — Voting + Evaluator-Optimizer
토론 구조처럼 여러 관점을 비교해야 하는 작업이라면 이 두 패턴의 조합이 정답에 가깝다.
(사진 = claude)
예를 들어 “이 기능을 어떻게 구현할까” 같은 설계 결정에서, A는 REST API 방식으로, B는 GraphQL 방식으로 각각 설계안을 제시하고, 평가자가 요구사항 대비 적합도를 판단하는 식이다.
단, 이 조합은 비용이 꽤 나온다. Parallelization + Evaluator-Optimizer 루프 비용이 합산되니까. 정말 중요한 결정에만 써야 한다.
마무리
Anthropic이 남긴 핵심 조언이 하나 있다.
“LLM이 실제로 필요한지 먼저 확인하라.”
에이전트 시스템은 복잡할수록 비용도 올라가고 디버깅도 어려워진다. 단순한 Prompt Chaining으로 해결되는 문제에 Orchestrator-Workers를 붙이는 건 오버엔지니어링이다. 비용 측면에서도 마찬가지다.
5가지 패턴을 외우는 것보다 중요한 건, 내 문제에 어느 패턴이 맞는지, 그 비용을 감당할 수 있는지 같이 판단하는 눈이다. 그 눈은 결국 직접 만들어보면서 생긴다. 나도 여전히 만들면서 배우는 중이다.
