요약 (TL;DR). 1년 전, AI 에이전트를 실행하는 흥미로운 방식은 루프(loop)였습니다. 작업에 에이전트를 지정하고 완료될 때까지 반복하게 하는 것이었죠. "밤새도록 실행해 두세요"라는 스크린샷이 어디에나 있었습니다. 그 시대는 끝나가고 있으며, 이를 대체하는 것은 그래프(graphs)입니다. 그래프는 이름이 지정된 단계들의 구조화된 지도, 단계 사이의 정의된 경로, 명시적인 상태(state), 그리고 분기(branch)하고, 충돌로부터 복구하며, 모니터링할 수 있는 능력을 갖춘 에이전트로 구축됩니다. 이것은 단순한 유행이 아닙니다. 이는 "실행하고 기도하기"에서 실제로 비즈니스를 운영할 수 있는 단계로 이 분야가 성장하고 있음을 의미합니다. 여기 그 변화와 그 뒤에 숨겨진 연구, 그리고 여러분이 코드를 한 줄도 쓰지 않더라도 이것이 왜 중요한지에 대해 설명합니다.

루프 시대와 그 한계

에이전트를 실행하는 가장 간단한 방법은 루프(loop)입니다. 한 단계를 수행하고, 결과를 다시 입력값으로 넣고, 작업이 끝날 때까지 반복하는 것입니다. 가장 순수한 형태는 2025년에 화제가 되었던 Ralph Wiggum 기술입니다. bash 루프 안에서 코딩 에이전트가 무언가를 만들어낼 때까지 관리자 없이 실행되는 방식이죠. 이는 진정으로 영리하며, 적절한 작업에 대해서는 여전히 유효합니다.

하지만 단일 루프는 한계(ceiling)가 낮으며, 작업이 본격화되는 순간 그 한계에 부딪힙니다. 루프는 작업이 동시에 두 갈래로 나아가야 할 때 깔끔하게 분기(branch)할 수 없습니다. 6시간 동안 실행되던 도중 기기가 충돌하면 우아하게 복구할 수 없으며, 그저 처음부터 다시 시작할 뿐입니다. 관찰하기도 어렵습니다. 외부에서 볼 때 루프는 여전히 진행 중이거나 완료되었을 뿐, 그 사이의 과정을 거의 볼 수 없는 불투명한 상자와 같습니다. 또한 한 종류의 하위 작업은 한 방향으로, 다른 종류는 다른 곳으로 보내는 식의 작업 라우팅(route)도 쉽게 할 수 없습니다. 주말 프로젝트라면 이런 것들이 중요하지 않겠지만, 프로덕션(production) 환경에서는 이 모든 것이 중요합니다.

그래프의 등장

이 분야가 도달한 결론은 에이전트를 루프(loop)로 생각하는 것을 멈추고 그래프(graph)로 생각하기 시작하는 것입니다. 즉, 노드(nodes)라고 불리는 이름이 지정된 단계들이 엣지(edges)라고 불리는 정의된 경로로 연결되며, 그 사이에서 상태(state)가 명시적으로 전달되는 구조입니다. 이를 위한 가장 잘 알려진 프레임워크는 LangGraph로, 여기서 노드는 함수이고 엣지는 제어 흐름(control flow)이며, 상태는 사용자가 확인하고 체크포인트(checkpoint)를 생성할 수 있는 요소입니다. 다른 프레임워크들도 존재하지만, 핵심은 이 패턴에 있습니다.

그래프는 루프가 할 수 없었던 문제를 정확히 해결합니다. 엣지의 목적 자체가 분기(branch)와 병합(merge)이기 때문입니다. 또한 전체 실행을 다시 시작하는 대신 실패한 단일 단계만 재시도(retry)할 수 있습니다. 그리고 모든 단계와 모든 전이(transition)에 이름이 붙어 있기 때문에, 실행 과정을 지켜보고, 로그를 남기고, 특정 지점에서 일시 중지할 수 있습니다. 불투명한 상자가 하나의 지도가 되는 것입니다.

이 밑바탕에는 덜 눈에 띄지만 그만큼 중요한 두 번째 변화인 내구 실행(durable execution)이 자리 잡고 있습니다. Temporal이나 Restate와 같은 엔진은 장기 실행되는 에이전트의 각 단계를 감싸서, 프로세스가 충돌하더라도 모든 것을 다시 수행하거나, 더 나아가 고객에게 이미 비용을 청구했거나 이메일을 보낸 단계를 반복하는 대신 멈춘 지점부터 재개할 수 있게 합니다. 밤새 실행되다가 5시간째에 종료되는 루프는 5시간을 날리게 되지만, 내구성이 있는 그래프는 아무것도 잃지 않습니다. 돈이나 실제 시스템을 다루는 모든 작업에서 이 차이는 승패를 결정짓는 핵심입니다.

최전선: 스스로 구축하는 그래프

최첨단 기술은 한 단계 더 나아갑니다. 그래프가 스스로를 설계할 수 있을까요? 엔지니어가 노드와 엣지를 배치하는 대신, 시스템이 자동으로 최적의 구조를 탐색하거나 심지어 각 작업에 맞는 맞춤형 그래프를 생성할 수 있을까요?

연구 결과는 그렇다고 답하지만, 과장된 기대(hype)에 대해서는 중요한 주의 사항을 덧붙입니다. 해당 분야에 대한 2026년 조사인 From Static Templates to Dynamic Runtime Graphs는 이 전체 영역을 매핑하고 냉철한 결론을 내립니다. 즉, 런타임(runtime)에 완전히 새로운 워크플로 그래프(workflow graph)를 생성하는 것은 대개 과잉(overkill)이며 보기보다 위험하다는 것입니다. 실용적인 최적점(sweet spot)은 잘 검증된 하나의 그래프를 구축한 다음, 라우터(router)가 작업별로 그 중 적절한 부분을 선택하게 하는 것입니다. 이는 이미 신뢰할 수 있는 구조의 안전성을 유지하면서도 대부분의 이점을 포착할 수 있는 방법입니다.

자동 구조 탐색(automatic structure search)이 효과를 발휘하는 곳에서는 놀라운 결과가 나타납니다. 몬테카를로 트리 탐색(Monte Carlo Tree Search)을 사용하여 워크플로 그래프의 공간을 탐색하는 시스템인 AFlow는 6개의 벤치마크에서 수동으로 설계된 워크플로보다 평균 5.7%, 다른 자동화된 방법들보다 19.5% 더 높은 성능을 기록했습니다. 더 주목할 만한 점은, 이 시스템이 더 작고 저렴한 모델을 사용하여 코딩 벤치마크에서 GPT-4o 수준의 결과에 도달하면서도 비용은 4.55% 수준으로 낮출 수 있는 구조를 찾아냈다는 것입니다. 이제 성능과 비용의 상당 부분은 단순히 내부의 모델뿐만 아니라 그래프의 구조에 달려 있습니다.

직접 구축하지 않더라도 이것이 중요한 이유

이 부분은 AI를 직접 작성하기보다 비용을 지불하며 사용하는 모든 분들을 위한 내용입니다. 이러한 변화는 단순히 프레임워크의 선호도 문제가 아닙니다. 이는 데모(demo)와 신뢰할 수 있는 시스템 사이를 가르는 경계선입니다.

잃을 것이 없는 상황에서는 루프(loop) 방식도 괜찮습니다. 하지만 그래프와 내구 실행(durable execution)이 존재하는 이유는 프로덕션(production) 환경에는 이해관계(stakes)가 걸려 있기 때문입니다. 실행 과정은 충돌(crash)로부터 살아남아야 하고, 진행되는 동안 관찰 가능(observable)해야 하며, 이미 수행한 작업을 반복하지 않고 복구(recover)할 수 있어야 합니다. 이는 우리가 Oversight Ladder와 keeping AI agents trustworthy in production에서 설명한 성숙 과정과 동일합니다. 루프는 감독되지 않는, 위험 부담이 낮은 영역에 적합합니다. 실제 비즈니스 업무는 사람과 시스템 모두가 무엇이 일어나고 있는지 볼 수 있는, 구조화되고 복구 가능한 레일(rails) 위에서 이루어져야 합니다.

따라서 벤더(vendor)에게 던져야 할 유용한 질문은 "최신 프레임워크를 사용하는가"가 아닙니다. 더 간단한 질문은 이것입니다: 실행이 중간에 실패하면 어떤 일이 발생합니까? 만약 정직한 답변이 "처음부터 다시 시작한다" 또는 "알 수 없다"라면, 당신은 생산 환경(production)의 문제를 루프 시대(loop-era)의 엔지니어링 방식으로 접근하고 있는 것입니다. 만약 그 답변이 단일 단계를 복구하고, 상태(state)를 유지하며, 모니터링이 가능한 구조를 설명한다면, 당신은 루프에서 그래프(graph)로 도약한 사람을 보고 있는 것입니다. 그 도약은 데모만 잘 되는 AI와 비즈니스를 실제로 운영하는 AI 사이의 차이를 조용히 만들어내고 있습니다.

우리는 고객이 의존하는 업무를 위해, 하룻밤 사이에 만들어진 루프가 아닌 구조화되고 복구 가능한 레일(rails) 위에서 프로덕션 AI를 구축합니다. 그것이 유일하게 정직한 방식이기 때문입니다. 고려 중인 솔루션에 이것이 어떤 의미인지 알고 싶다면, 그것이 바로 첫 번째 상담이 필요한 이유입니다.

자주 묻는 질문 (Frequently asked questions)

AI 에이전트가 루프에서 그래프로 이동한다는 것은 무엇을 의미하나요?
루프(loop)는 에이전트를 실행하는 가장 단순한 방법입니다. 2025년에 유행했던 Ralph Wiggum 기법처럼, 작업이 완료될 때까지 단계를 계속해서 반복하는 방식입니다. 그래프(graph)는 구조화된 버전입니다. 이름이 지정된 단계(노드, nodes)가 정의된 경로(엣지, edges)로 연결되어 있으며, 노드 사이에 명시적인 상태(state)가 전달됩니다. 이를 통해 에이전트는 분기(branch)하고, 병합(merge)하며, 단일 단계를 재시도(retry)할 수 있고, 관찰(observed)될 수 있습니다. 업계가 루프에서 그래프로 이동하는 이유는 작업이 실제 상황이 되었을 때 루프가 한계에 부딪히기 때문입니다. 루프는 깔끔하게 분기하거나, 실행 중 충돌(crash)로부터 복구하거나, 면밀히 관찰할 수 없습니다. 그래프는 가능합니다.

LangGraph란 무엇인가요?
LangGraph는 에이전트를 그래프 형태로 구축하기 위한 가장 잘 알려진 프레임워크 중 하나입니다. 노드(nodes)는 함수 또는 단계이며, 엣지(edges)는 제어 흐름(control flow)을 정의하고, 상태(state)는 노드 간에 명시적으로 전달됩니다. 이는 더 넓은 변화를 대변합니다. 하나의 불투명한 루프 대신, 검사(inspect)하고, 체크포인트(checkpoint)를 찍고, 재개(resume)할 수 있는 구조화된 그래프를 얻게 됩니다.

AI 에이전트가 자체 워크플로우 그래프를 구축할 수 있을까요?
연구 최전선에서는 가능하지만, 과장된 기대(hype)에는 주의해야 합니다. 2026년의 이 분야 설문조사(