AI 에이전트는 더 정교한 프롬프트가 아니라 control flow가 필요하다 — 12-Factor Agents와 LangGraph가 가리키는 같은 방향

5월 09, 2026

프로덕션 에이전트의 90%는 사실 결정적 코드예요

"AI 에이전트"라는 단어를 들으면 자율적으로 사고하고 도구를 골라 일을 처리하는 모습을 떠올리게 됩니다. 그런데 실제로 프로덕션에서 돌아가는 에이전트의 약 90%는 결정적 코드이고, 그 안에 LLM 호출이 작은 결정 지점에만 박혀 있다는 게 최근 엔지니어들 사이의 공통된 관찰이에요. 그 흐름을 한 문장으로 압축한 표현이 최근 화제가 됐습니다. "Agents need control flow, not more prompts." 그런데 왜 갑자기 이런 주장이 동시에 여러 곳에서 튀어나왔을까요.

70~80%에서 멈춥니다, 그게 모든 LLM 에이전트의 벽이에요

데모는 멋지게 돌아갑니다. 그런데 같은 에이전트를 실제 사용자에게 넘기는 순간 일관되게 동일한 벽에 부딪힙니다. 신뢰성이 70~80% 부근에서 멈춰버리는 현상이에요. 무한 루프에 빠지거나, 잘못된 도구 호출을 만들거나, 자기 상태를 잊어버리는 식이죠.

한 엔지니어는 자기 경험을 이렇게 표현했어요. "약 30개 파일을 넘어서면 LLM이 통제하는 흐름이 무너집니다. 어떤 파일은 빼먹고, 어떤 파일은 세 번씩 테스트하고, 한 파일에서 에러가 나면 이전에 잘 동작하던 네 개를 다시 검사하기 시작합니다." 자율성을 줬더니 안정성이 떨어진 거죠. 이건 모델이 멍청해서가 아니라, 언어 생성 자체에는 '제어' 개념이 없기 때문이라는 게 핵심입니다.

더 정교한 프롬프트로는 그 벽을 못 넘어요

기존 접근은 보통 두 갈래였습니다. 하나는 프롬프트 체인을 점점 정교하게 만드는 방향, 다른 하나는 사람이 옆에서 베이비시팅해 주는 방향이었어요. 둘 다 한계가 분명합니다. 프롬프트 체인은 길어질수록 분기마다 실패 확률이 곱연산으로 늘고, 베이비시팅은 자동화의 의미가 사라지죠.

최근 담론은 결론을 단순하게 정리합니다. "지난 50년간 모든 신뢰성 분야가 했던 그 일을 똑같이 하면 됩니다. 테스트를 쓰고, 호출을 게이팅하고, 계약이 깨지면 큰 소리로 실패시키는 것." LLM이 흐름의 주체가 아니라, 잘 짜인 흐름 안에서 특정 결정 지점만 맡는 부품이 되어야 한다는 얘기예요.

12-Factor Agents가 제안한 새 출발선

이 흐름을 한 프레임워크로 묶어 낸 사람이 Dexter Horthy(humanlayer)예요. Heroku의 12-Factor App에서 이름을 빌려 12-Factor Agents를 제안했는데, GitHub에서 큰 호응을 얻으며 사실상 표준 담론으로 자리 잡았습니다.

핵심 원칙 몇 가지만 짚어 보면 이렇습니다. (1) control flow는 코드에 두고, LLM은 안내자 역할만. (2) 컨텍스트 윈도우를 명시적으로 관리 — 토큰을 자동으로 쌓아가지 말고, 매 단계 무엇을 넣을지 손으로 정하라. (3) prompt·switch·context·loop를 코드 컴포넌트로 소유. (4) stateless 에이전트로 설계해서 일시정지·재개·수평 확장이 가능하게. (5) 명시적 OODA 루프와 수렴 조건을 둘 것. 정리하면 "에이전트는 LLM이 들어간 잘 짜인 소프트웨어이고, 마법은 가능한 적게 써야 한다"는 입장이에요.

LangGraph가 보여주는 2026의 표준 패턴

이 철학을 가장 또렷하게 구현한 프레임워크가 LangGraph입니다. 2026년 들어 stable 시맨틱 버전을 발표하면서 "타입드 상태(state) + 조건부 엣지 + 체크포인팅 + 인터럽트 지점"이라는 네 가지를 1급 추상화로 제공해요.

실제 패턴은 이렇게 정리됩니다. 결정적 백본(backbone) 위에 LLM 호출이 노드로 박혀 있고, 어떤 분기로 갈지는 코드의 조건부 엣지가 결정합니다. 노드가 끝나면 제어권이 다시 백본으로 돌아오고요. 중간에 외부 승인이 필요하면 그 노드에서 인터럽트를 걸고, 사람이 결재한 뒤 정확히 그 체크포인트부터 재개합니다. Anthropic의 "Building Effective Agents" 가이드도 같은 결을 강조하는데, "단순한 워크플로가 자율 에이전트보다 거의 항상 낫다"는 표현으로 요약돼요. 자율은 가장 마지막에, 그것도 좁은 범위에서 쓰라는 권고입니다.

마법 같은 추론에서, 신뢰할 수 있는 엔지니어링으로

한 발짝 떨어져 보면 이번 흐름이 의미하는 게 분명해집니다. AI 에이전트 분야가 '마법 같은 추론을 기대하는 단계'를 지나, 데이터베이스·메시지 큐·테스트·관찰성 같은 일반 소프트웨어 엔지니어링과 같은 규율을 받아들이는 단계로 넘어가고 있다는 얘기예요. 흥미로운 점은, 그렇게 LLM의 자율성을 줄일수록 오히려 시스템 전체로서 할 수 있는 일이 더 많아진다는 사실이고요.

실무자에게 의미하는 것도 분명합니다. 새 프롬프트 트릭을 외우는 대신, 상태·재시작·도구 호출 스키마·실패 게이팅을 어떻게 설계할지 고민하는 시간이 더 가치 있어졌어요. ML 엔지니어보다 백엔드 엔지니어의 직관이 다시 중요해진 시기라고도 볼 수 있습니다.

한 줄 정리

2026년 LLM 에이전트의 핵심은 "더 똑똑한 프롬프트"가 아니라 "더 잘 짜인 control flow"이고, 12-Factor Agents와 LangGraph 패턴이 보여주듯 신뢰성은 결국 결정적 코드 위에 LLM을 작게 박는 엔지니어링에서 나옵니다.

이 블로그 검색

AI 비즈니스 설계도

Pinned Post

공식가 90% 할인 'Claude 암시장', 진짜 위험은 가격이 아닙니다