에이전트의 답변보다 실행 흐름이 중요할 때
AI가 문장을 잘 작성하는 것과 기업의 업무를 안정적으로 수행하는 것은 다르다. 자료를 조회하고, 결과를 검토하고, 담당자의 승인을 받아 외부 시스템에 반영하는 작업에서는 중간 상태와 진행 순서를 관리해야 한다.
어떤 자료를 확인했는지, 다음에 무엇을 해야 하는지, 실패한 작업을 다시 실행해도 되는지 알 수 없다면 결과를 운영 업무에 연결하기 어렵다.
LangGraph는 이러한 상태를 가진 에이전트와 장시간 실행되는 업무 흐름을 구성하기 위한 오케스트레이션 프레임워크이자 실행 환경이다. 공식 문서는 일반 코드로 결정되는 단계와 언어모델이 판단하는 단계를 하나의 그래프에서 결합할 수 있다고 설명한다.
이 글은 공식 문서를 바탕으로 작성한 설계 해설이다. 특정 기업의 도입 성과를 검증하거나 실행 속도와 비용을 측정한 보고서는 아니다. 아래 업무 예시는 설명을 위한 가상 시나리오다.
LangGraph는 LangChain 사용을 전제로 하지 않는다
LangGraph와 LangChain은 함께 사용할 수 있지만 같은 역할을 하는 도구는 아니다. LangGraph 공식 문서는 LangChain을 사용하지 않고도 LangGraph를 사용할 수 있다고 안내한다.
LangGraph의 초점은 작업의 실행 순서와 상태, 중단과 재개를 관리하는 데 있다. 모델과 도구를 연결하는 기능만으로 이해하기보다 전체 업무 흐름을 구성하는 실행 기반으로 보는 편이 적절하다.
또한 모든 작업 단계를 AI 에이전트로 만들 필요는 없다. 필수 항목 검사나 금액 비교처럼 명확한 규칙이 있는 부분은 일반 코드로 처리하고, 문장 작성이나 비정형 자료의 해석에 모델을 사용할 수 있다.
어디에 AI 판단을 허용하고 어디에 고정된 규칙을 둘 것인지 구분하는 것이 설계의 출발점이다.
상태는 업무를 이어가기 위한 기록이다
워크플로우의 상태는 단순한 대화 기록보다 넓은 개념이다. 업무를 다음 단계로 넘기거나 중단 후 다시 시작하는 데 필요한 정보를 담는다.
고객 문의 답변 업무라면 문의 식별자와 분류 결과, 조회한 근거 문서, 답변 초안, 검토 결과, 승인 여부 등이 상태에 포함될 수 있다.
이때 모든 정보를 무조건 저장하는 것은 바람직하지 않다. 다음 단계에 필요한 정보와 감사·문제 분석에 필요한 기록을 구분하고, 개인정보의 저장 범위를 제한해야 한다.
상태에는 완료된 사실과 모델의 추정도 구분해 남기는 편이 좋다. 모델이 ‘승인된 것으로 보인다’고 작성한 문장이 실제 승인 기록을 대신해서는 안 된다.
노드와 분기는 책임을 나누는 장치다
노드는 업무의 한 단계를 수행하는 단위로 생각할 수 있다. 자료 조회와 초안 작성, 검토, 외부 발송을 분리하면 어떤 단계에서 문제가 발생했는지 파악하기 쉬워진다.
분기는 다음 단계로 이동할 조건을 표현한다. 근거가 충분하면 초안 작성으로 보내고, 부족하면 보완 요청이나 담당자 검토로 넘기는 방식이다.
중요한 것은 정상 경로만 그리지 않는 것이다. 조회 실패와 권한 부족, 입력 누락, 승인 거절, 실행 시간 초과 같은 상황에서 어디로 이동할지도 정해야 한다.
노드가 여러 책임을 한꺼번에 수행하면 수정과 재실행이 어려워질 수 있다. 특히 외부 시스템을 변경하는 작업은 조회와 문장 생성 단계에서 분리하는 편이 관리하기 쉽다.
가상 설계 예시: 고객 문의의 답변 초안 작성
고객 문의를 받아 답변 초안을 만드는 업무를 가정해보자. 목표는 자동 발송이 아니라 근거가 연결된 초안을 담당자에게 제공하는 것이다.
처음에는 문의의 필수 정보와 자동화 가능 여부를 확인한다. 필요한 정보가 없으면 고객에게 보완을 요청하거나 담당자에게 넘긴다.
다음 단계에서는 승인된 FAQ와 규정에서 관련 자료를 조회한다. 조회 결과에는 답변에 사용할 내용뿐 아니라 문서 식별자와 위치도 남긴다.
초안 작성 단계는 조회한 근거의 범위 안에서 문장을 만든다. 근거가 없는 내용은 추정으로 보충하지 않고 확인이 필요하다고 표시한다.
검토 단계에서는 정책과의 충돌, 출처 누락, 개인정보 포함 여부를 확인한다. 재작업이 필요하면 정해진 횟수 안에서 수정하고, 해결되지 않으면 사람이 검토한다.
마지막에는 담당자의 명시적인 승인을 기다린다. 승인 기록이 확인된 경우에만 발송 단계로 이동하도록 구성한다.
이 흐름의 장점은 에이전트가 많다는 데 있지 않다. 어떤 조건에서 다음 단계로 가고 언제 멈추는지가 드러난다는 데 있다.
중단과 재개에는 저장 설정이 필요하다
LangGraph의 interrupt 기능은 실행을 멈추고 외부 입력을 기다리는 데 사용한다. 담당자의 승인이나 수정 내용을 받은 뒤 작업을 이어가는 흐름을 만들 수 있다.
공식 문서는 이를 위해 상태를 저장하는 checkpointer와 재개할 실행을 식별하는 thread ID가 필요하다고 설명한다. 운영 환경에서는 요구사항에 맞는 영속적인 저장 구성을 검토해야 한다.
기능을 사용한다는 이유만으로 모든 작업 상태가 자동으로 안전하게 보존되는 것은 아니다. 저장소 장애와 접근 통제, 보관 기간, 재개할 실행의 식별 방식도 설계해야 한다.
승인 대기 중인 업무에 누가 응답할 수 있는지 확인하는 인증·권한 절차도 별도로 필요하다. 중단 기능 자체가 승인자의 신원을 검증해주지는 않는다.
재개할 때 같은 작업이 반복될 수 있다
운영 설계에서 특히 주의할 점은 중단 후 재개 시 노드가 처음부터 다시 실행될 수 있다는 것이다. 공식 문서는 interrupt 앞에 있는 코드가 다시 실행될 수 있다고 설명한다.
예를 들어 외부 발송을 먼저 수행하고 뒤에서 승인을 기다리도록 구성하면, 재개 과정에서 같은 발송이 반복될 위험이 있다.
따라서 승인 전에 실행해도 되는 작업과 승인 이후에만 실행할 작업을 구분해야 한다. 외부 변경 작업에는 같은 요청이 여러 번 들어와도 중복 처리가 일어나지 않도록 하는 장치가 필요하다.
업무 식별자와 처리 기록을 확인하거나, 외부 시스템이 지원하는 중복 방지 기능을 사용하는 방식을 검토할 수 있다. 중요한 것은 재개 기능이 외부 업무의 단 한 번 실행까지 자동으로 보증한다고 가정하지 않는 것이다.
도입 전에 확인할 운영 기준
검증은 정상적으로 완료되는 요청뿐 아니라 실패와 재개 상황을 포함해야 한다.
근거 문서가 없는 문의가 들어왔을 때 답변을 만들어내지 않는지 확인한다. 조회 시스템이 중단됐을 때 반복 호출을 제한하고 담당자에게 넘기는지도 살펴야 한다.
승인을 거절했을 때 외부 발송이 차단되는지, 같은 승인 요청을 다시 처리해도 중복 실행이 발생하지 않는지 점검한다.
성능을 평가할 때는 초안 생성 시간뿐 아니라 사람의 검토 시간과 수정 부담, 재시도 비용을 함께 측정한다. 상태 저장과 로그 관리에 필요한 운영 비용도 고려해야 한다.
단순한 업무라면 일반 코드와 단일 AI 호출만으로 충분할 수 있다. 상태 저장과 분기, 장시간 승인 대기 등이 실제로 필요한지 먼저 확인하는 편이 좋다.
결론: 예측 가능한 것은 모델의 답변보다 업무의 경계다
LangGraph는 상태를 가진 업무에서 일반 코드와 모델의 판단을 결합하고, 중단과 재개를 구성하는 데 활용할 수 있다.
그러나 프레임워크를 도입했다고 해서 모델의 답변이 항상 정확해지거나 외부 시스템 변경이 안전해지는 것은 아니다. 검증 기준과 승인 권한, 반복 실행 방지, 장애 대응은 여전히 설계자의 책임이다.
좋은 에이전트 워크플로우는 모든 일을 자율적으로 수행하는 구조가 아니다. 무엇을 자동으로 처리하고, 어떤 조건에서 멈추고, 누가 책임 있게 이어받는지 명확한 구조다.
참고 자료
LangGraph 공식 개요 https://docs.langchain.com/oss/python/langgraph/overview
LangGraph 공식 문서: Interrupts https://docs.langchain.com/oss/python/langgraph/interrupts
LangGraph 공식 문서: Persistence https://docs.langchain.com/oss/python/langgraph/persistence