나는 LangGraph로 Agent를 배웠다
1년 반 전, 나는 시장 정보 분석 팀에서 CSO에게 제출할 20장 분량의 보고서 초안을 만드는 데 멀티에이전트 시스템을 사용했다. 이 일은 자료를 모아 문장으로 정리하는 것만으로 끝나지 않았다. 시뮬레이션, 시나리오, 민감도 분석에는 Python으로 계산할 부분이 있었고, 그 계산을 연결하는 로직도 만들어야 했다. 조사와 분석의 결과가 계산으로 이어지고, 계산 결과는 다시 보고서의 논거가 되어야 했다.
그래서 여러 Agent가 자료를 조사하고 분석하고 검증한 뒤 결과를 합치는 구조를 만들었다. 나는 그 흐름을 설계할 때 먼저 그래프를 그렸다. 조사 결과와 계산 결과를 어느 state에 담을지, 다음 Agent에게 어떤 맥락을 넘길지, 중간 작업이 실패하거나 결과가 부족하면 어떻게 다시 진행할지 정해야 했다. conditional edge, 재시도와 대체 경로, 맥락 관리, 결과 통합은 장식이 아니라 보고서 초안을 끝까지 만들어내기 위한 실제 구현 문제였다.
당시 내게는 에이전트가 곧 LangGraph였고, LangGraph가 곧 에이전트였다. 한 번 질문에 답하고 멈추던 LLM을, 도구를 사용하고 결과를 다음 단계로 넘기며 작업을 이어가는 업무 흐름 안에 놓을 수 있었다. 역할과 상태 전이를 눈에 보이게 만들고, 실패하면 어디서 다시 시작할지 설계할 수 있다는 점도 컸다. 내게 LangGraph는 LLM을 단순한 답변 도구에서 일하는 시스템으로 확장해준, 상당히 혁신적인 프레임워크였다. 그래서 지금 그래프의 필요성을 다시 묻는 것도 그 가치를 몰라서가 아니다. 그 방식으로 에이전트를 만들어봤기 때문에 묻게 된 질문이다.
그래프가 복잡해질수록 이상한 점이 보였다
처음에는 Agent 하나를 더 붙이면 능력 하나가 늘어난다고 생각하기 쉽다. 실제로는 접점도 늘어난다. 새 Agent가 읽을 맥락을 정리하고, 이전 결과를 어떤 형식으로 넘길지 정하고, 실패와 재시도의 책임을 나눠야 한다. 호출 횟수가 늘면 지연과 토큰 비용도 늘고, 결과가 왜 그렇게 나왔는지 추적하는 일도 어려워진다.
이것이 그래프 자체의 결함은 아니다. 복잡한 일을 여러 주체가 처리하면 원래 생기는 비용이다. 다만 그래프가 그 비용을 깔끔하게 표현해 주는 순간, 우리가 애초에 필요하지 않은 역할까지 그려 놓은 것은 아닐까라는 질문을 늦게 하게 될 수 있다. 나에게 더 중요한 설계 질문은 “노드를 어떻게 연결할까”에서 “정말 별도의 노드와 Agent가 필요한가”로 옮겨갔다.
모델 자체가 달라졌다
예전에는 개발자가 Planner → Researcher → Critic → Writer → Retry 같은 경로를 세심하게 설계해야 하는 경우가 많았다. 모델이 도구를 잘못 고르거나, 중간 결과를 확인하지 않고 다음 단계로 넘어가거나, 실패 후 같은 행동을 반복할 수 있었기 때문이다. 정해진 경로가 모델의 약점을 보완했다.
최근의 모델과 도구 사용 환경에서는 다른 선택이 가능해졌다. 모델이 검색 결과를 읽고, 부족하면 다른 검색을 하고, 코드 실행이나 테스트 결과를 본 뒤 수정 방향을 바꾸는 작업을 하나의 실행 순환 안에서 처리할 수 있는 범위가 넓어졌다. 계획, 다단계 추론, 도구 선택, 결과 점검, 재시도, 자기 수정이 늘 완벽하다는 뜻은 아니다. 개발자가 모든 중간 경로를 사전에 고정해야 하는 비율이 줄어들었다는 관찰이다.
개발자가 경로와 분기를 먼저 정한다
모델이 실행 중 결과를 보고 다음 행동을 고른다
그래프는 여전히 실행을 기록하고 상태를 복구하는 좋은 방식일 수 있다. 여기서 달라지는 것은 “그래프를 쓰는가”보다 누가 다음 경로를 결정하는가다. 개발자가 모든 간선을 미리 쓰는 곳과, 모델이 결과를 보고 다음 행동을 선택하는 곳을 구분해야 한다.
철도에서 자동차로
내가 이 변화를 이해하는 데 도움이 된 비유는 철도와 자동차다. 철도에서는 선로를 먼저 깐다. 어디서 갈라지고 어디서 멈추는지 미리 설계한다. 초기 Agent 시스템에서 개발자가 작성한 그래프가 이런 선로에 가까웠다.
자동차에는 다른 설계가 필요하다. 목적지와 도로망은 있지만, 운전자는 앞에서 벌어지는 일을 보며 경로를 바꾼다. 이때 중요한 것은 선로를 더 촘촘히 까는 일이 아니라, 운전 가능한 범위, 교통 규칙, 연료, 계기판, 사고 시 제동 장치를 갖추는 일이다. 모델이 실행 중 trajectory를 만들 수 있다는 말도 이런 뜻에 가깝다.
물론 자동차도 신호와 도로의 경계를 따른다. 이 비유는 모든 업무 흐름을 자유주행으로 바꾸자는 주장이 아니다. 탐색의 자유를 줄 수 있는 구간과 반드시 정해진 절차를 따라야 하는 구간을 나누자는 제안이다.
그래서 Python으로 직접 만든 에이전트가 다시 흥미로워졌다
이 관점에서 Python으로 직접 구현한 에이전트 루프는 매력적이다. “프레임워크를 전혀 쓰지 않는다”는 구호가 아니다. 핵심 루프를 내가 소유하고, 필요한 영속성, 추적, 도구 실행, 승인 경계만 선택해 붙이겠다는 뜻이다. 짧게 쓰면 이런 모양이다.
messages = [{"role": "user", "content": goal}]
while True:
response = model.generate(messages, tools=tools)
messages.append(response.message)
if response.is_final:
return response.text
for call in response.tool_calls:
result = execute_allowed_tool(call)
messages.append(tool_result_message(call, result))이 코드는 개념 예시일 뿐 그대로 운영 환경에 넣을 코드는 아니다. 실제 운영에서는 반복 횟수와 비용 제한, 시간 초과, 도구 권한, 실패 재시도, 중복 실행 방지, 영속성, 추적, 맥락 압축, 사용자 승인, 복구 절차가 필요하다. 직접 루프를 소유하면 자유가 생기는 동시에 이 책임도 내 것이 된다. LangGraph가 제공하는 영속 실행과 중간 저장 지점, 사람의 개입이 필요한 경우라면 그것을 다시 직접 구현하는 것이 더 단순하다고 장담할 수 없다. LangGraph 공식 개요와 영속성 문서도 이 기능들을 핵심으로 설명한다.
Google AX가 보여주는 변화
최근 Google AX 저장소의 README와 설계 문서를 읽으며 흥미로웠던 것은 질문의 위치였다. AX는 Task를 선언하고, Workspace에 저장소와 도구를 연결하며, Model 설정을 제공한다. concepts와 manifests는 이런 리소스와 작업의 수명주기를 설명한다. 설계 문서에는 Gateway API도 나오지만, 이를 안정된 사용자 개념으로 과장해 나열할 단계는 아니다. 저장소 스스로 핵심 개념과 규격이 아직 바뀔 수 있다고 경고한다.
중요한 것은 AX가 “Agent는 조사자 다음에 비평가로 가야 한다”고 알려주는 도구가 아니라는 점이다. 어디서 실행할지, 어떤 작업 공간과 모델을 줄지, 격리 환경에 어떤 접근을 허용할지, 작업을 어떻게 보고 중단·재개할지가 중심이다. 실행기 문서는 작업 컨테이너가 환경을 준비하고 Agent 명령을 실행하는 계약까지 다룬다.
AX 아래의 GKE Agent Substrate 공식 설명은 더 분명하다. Actor를 Worker 격리 환경에서 실행하고, 유휴 상태가 되면 메모리와 파일을 스냅숏으로 저장했다가 다시 활성화한다. Google Cloud 문서는 복원을 1초 미만으로 설명하지만, 이 수치를 내 작업 부하의 보장 성능처럼 읽어서는 안 된다. 현재 안내에는 일반 고객 대상 평가·비운영 사용, 운영 환경 지원은 허용 목록 기반이라는 조건도 붙어 있다. 2026년 9월 공식 발표의 밀도·속도 수치는 제품 측 발표 수치로만 받아들이는 편이 정확하다.
Google이 “그래프는 필요 없다”고 선언한 것이 아니다. 내가 읽은 변화는 Agent의 사고 순서를 그리는 도구와 Agent 작업 부하를 안전하고 경제적으로 실행하는 도구가 서로 다른 문제를 푼다는 점이다.
아키텍처 계층을 나눠 보면
위 그림은 제품의 공식 분류표가 아니라 내가 설계할 때 쓰는 지도다. 모델의 추론과 도구 선택이 가장 안쪽에 있다. 그 주변의 에이전트 런타임은 반복 순환, 맥락, 상태 전이, 중단과 재개를 다룬다. LangGraph는 이곳에서 강하다. 작업 실행 런타임은 작업을 실제 격리 환경에서 돌리고 작업 공간, 네트워크, 자원, 수명주기를 관리한다. AX와 Agent Substrate가 주로 보여주는 관심사다. 그 아래에 Kubernetes와 인프라가 있다.
이 계층은 서로 배타적이지 않다. LangGraph로 내부 상태와 승인 절차를 만들고, 그 Agent를 격리된 실행 환경에 올릴 수도 있다. 반대로 간단한 Python 순환을 AX 같은 실행 계층에서 돌릴 수도 있다. 그래서 AX를 LangGraph의 직접 경쟁자로 소개하면 질문을 잘못 놓치게 된다.
그래도 LangGraph가 필요한 곳
코딩 Agent를 생각해 보자. 파일을 찾고, 코드를 읽고, 수정하고, 테스트 결과를 보고 다시 고치는 내부 작업은 정답 경로가 매번 다르다. 이 구간에서는 검색 ↔ 읽기 ↔ 코딩 ↔ 테스트 ↔ 재시도 같은 열린 순환이 자연스럽다. 어떤 파일을 먼저 볼지까지 개발자가 간선으로 정한다면 오히려 유연성을 잃는다.
하지만 Agent가 “테스트가 통과했다”고 말한 뒤의 일은 다르다. 테스트 통과 → 보안 검사 → 사람의 승인 → 운영 환경 배포 → 상태 확인은 순서와 책임이 중요하다. 상태 확인이 실패하면 되돌리기로, 통과하면 완료로 가야 한다. 누가 승인했는지, 어느 버전을 배포했는지, 실패 시 어떤 보상 작업을 했는지 남아야 한다. 이 구간은 명시적인 그래프나 상태 기계가 더 자연스럽다.
에이전트 내부: 탐색과 수정의 자유
시스템 경계: 검증 가능한 순서와 승인
LangGraph는 바로 이런 결정론적 절차와 모델 주도 단계를 한 그래프 안에 섞을 수 있고, 공식 문서도 영속 실행, 영속성, 사람의 개입을 강조한다. 승인 대기, 장시간 작업의 복구, 실패 후 재개는 기능 목록이 아니라 운영상 실질적인 이유다. 결제 승인, 금융 거래 실행, 규제된 절차, 되돌릴 수 없는 조치와 보상/되돌리기에도 같은 논리가 적용된다. 물론 단순한 절차라면 일반 코드와 기존 업무 흐름 엔진으로 충분할 수 있다. 도구 이름보다 상태 전이를 얼마나 명시적으로 관리해야 하는지가 선택 기준이다.
자율성과 절차를 구분해야 한다
개방형 추론에서는 탐색 중에 얻은 정보가 다음 행동을 바꾼다. 결과가 좋지 않으면 다른 가설을 시험하고, 예상 밖의 오류를 만나면 새 경로를 찾는다. 이곳에 모든 분기를 미리 그리면 그래프는 빠르게 비대해지고, 정작 모델이 잘할 수 있는 선택을 개발자가 대신하게 된다.
결정적 업무 흐름에서는 다른 가치가 우선한다. 승인 없이는 넘어갈 수 없고, 순서가 바뀌면 안 되며, 어떤 실패가 어떤 복구로 이어지는지 설명할 수 있어야 한다. 여기서 “모델이 알아서 하겠지”는 설계가 아니다. 두 방식을 한 시스템에 넣되, 어디까지가 자유이고 어디부터가 통제인지 경계에 이름을 붙여야 한다.
Agent 내부에서는 자유를, 시스템 경계에서는 통제를.
내가 지금 Agent 아키텍처를 보는 방식
이제 나는 Agent를 설계할 때 노드 수부터 세지 않는다. 먼저 일이 열린 탐색인지, 정해진 절차인지 묻는다. 열린 구간에는 모델이 다음 행동을 선택할 수 있는 도구와 피드백을 준다. 동시에 예산, 권한, 시간, 중단 조건을 정한다. 정해진 절차에는 승인과 상태 전이, 재시작 지점, 실패 후 보상 작업을 명시한다. 그리고 Agent가 실제로 일할 작업 공간과 실행 환경을 별도의 설계 문제로 본다.
이 관점은 AX의 방점은 AI가 아니라 Transformation에 있다와 AX는 좁고 날카로워야 한다에서 말한 업무 재설계와도 연결된다. 모델의 능력을 과시하기보다, 어떤 판단을 agent에게 맡기고 어떤 결정은 사람이 책임질지 업무 단위로 정해야 하기 때문이다.
결론
내가 LangGraph를 걷어낸다는 말은 그래프를 폐기한다는 뜻이 아니다. 예전에는 그래프가 Agent의 기본 골격처럼 보였다. 지금은 필요한 경계에 배치하는 정밀한 도구에 가깝다. 모델이 실행 중 경로를 만들 수 있는 곳에서는 작은 순환이 충분할 수 있다. 순서, 승인, 복구가 계약인 곳에서는 명시적인 그래프가 오히려 단순하고 안전하다.
내가 바꾸는 것은 프레임워크에 대한 충성도가 아니라 설계의 출발점이다. 먼저 Agent가 스스로 찾아갈 수 있는 길을 보고, 그다음 반드시 선로가 필요한 구간에만 선로를 깐다.
Discussion
토론
질문, 정정, 반례, 다른 해석이 있다면 남겨 주세요.