사람 승인 없는 에이전트는 위험하다: LangGraph interrupt로 운영 승인 워크플로우 만드는 법

운영 자동화 에이전트는 “자동 실행”보다 “멈춰야 할 지점에서 확실히 멈추는 구조”가 먼저입니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

AI 에이전트를 문서 배포, 운영 변경, 이슈 처리, 외부 발송 같은 업무에 붙이면 금방 이런 질문에 부딪힙니다.

“요약과 초안 작성까지는 맡기고 싶은데, 실제 배포나 삭제까지 자동으로 해도 될까?”

이 글의 답은 명확합니다.

위험한 작업은 에이전트가 바로 실행하지 않도록 설계해야 합니다.

대신 에이전트가 변경 내용을 정리하고, 승인 요청서를 만들고, 사람이 승인한 뒤에만 다음 단계로 넘어가게 해야 합니다.

이번 글에서는 결과물을 하나로 고정합니다.

“운영 변경 승인 요청서 자동화 에이전트”

목표는 다음과 같습니다.

1. 에이전트가 운영 변경 내용을 요약한다.

2. 승인자가 검토할 수 있는 요청서를 만든다.

3. 배포·삭제·외부 발송 같은 위험 작업 직전에 멈춘다.

4. 사람이 승인하거나 반려한 뒤에만 다음 단계로 진행한다.

5. 실행 상태가 끊기지 않도록 persistence를 함께 설계한다.

이 글은 단순히 “에이전트를 운영에 써도 되는가”를 묻지 않습니다.

LangGraph의 interrupt와 persistence를 사용해 승인형 운영 자동화를 어떻게 구성할지에 집중합니다.

왜 LangGraph interrupt가 필요한가

LangGraph 공식 문서는 LangGraph의 핵심 장점으로 durable execution, human-in-the-loop, persistence를 설명합니다.

한 번 호출하고 끝나는 챗봇보다, 오래 지속되는 워크플로우와 중간 승인, 상태 저장이 필요한 에이전트에 맞는 구조라는 뜻입니다.

• LangGraph 공식 저장소: https://github.com/langchain-ai/langgraph
• LangGraph 개요 문서: https://docs.langchain.com/oss/python/langgraph/overview
• interrupt 문서: https://docs.langchain.com/oss/python/langgraph/interrupts
• persistence 문서: https://docs.langchain.com/oss/python/langgraph/persistence

운영 자동화에서 가장 위험한 설계는 에이전트에게 “판단”과 “실행”을 한 번에 맡기는 것입니다.

예를 들어 에이전트가 다음을 모두 처리한다고 가정해 보겠습니다.

• 변경 요청 문서 읽기
• 영향 범위 요약
• 배포 필요 여부 판단
• 배포 실행
• 결과 통보

이 구조에서는 에이전트가 잘못 판단했을 때 곧바로 부작용이 생길 수 있습니다.

특히 배포, 삭제, 권한 변경, 외부 발송은 되돌리기 어렵거나 조직 신뢰에 영향을 줄 수 있습니다.

LangGraph의 interrupt는 이런 지점에서 그래프 실행을 멈추고 외부 입력을 기다리는 패턴을 제공합니다.

공식 문서 기준으로 interrupt는 그래프 실행 중 특정 지점에서 멈춘 뒤, 사람의 입력을 받아 이어가는 human-in-the-loop 흐름을 만들 때 사용합니다.

따라서 질문은 “에이전트가 어디까지 자동으로 하게 할 것인가”가 아닙니다.

“어디서 반드시 멈추게 할 것인가”입니다.

만들 결과물: 운영 변경 승인 요청서 자동화

이번 가이드에서 만들 워크플로우는 다음 역할을 가집니다.

1. 입력

운영 변경 요청의 기본 정보입니다.

예시 입력 항목은 다음과 같이 잡을 수 있습니다.

• 변경 대상
• 변경 목적
• 예상 영향
• 실행 예정 작업
• 롤백 또는 복구 계획
• 외부 발송, 삭제, 권한 변경 여부

여기서 중요한 점은 입력 항목 자체보다 “승인자가 판단할 수 있는 정보가 충분한가”입니다.

확인 필요 항목이 있다면 에이전트가 임의로 채우면 안 됩니다.

본문에 “확인 필요”로 남겨야 합니다.

2. 에이전트 처리

에이전트는 입력을 바탕으로 승인 요청서를 만듭니다.

요청서에는 최소한 다음이 포함되어야 합니다.

• 변경 요약
• 영향 범위
• 위험 작업 포함 여부
• 승인 전 확인해야 할 항목
• 실행 전 체크리스트
• 승인 또는 반려를 기다리는 상태

이 단계까지는 비교적 안전한 자동화입니다.

문서를 읽고, 구조화하고, 요약하는 작업이기 때문입니다.

3. interrupt 지점

에이전트가 실제 실행 단계로 넘어가기 직전에 interrupt로 멈춥니다.

멈춰야 하는 대표 지점은 다음과 같습니다.

• 배포 실행 전
• 삭제 작업 전
• 외부 메시지·메일·게시 전
• 권한 변경 전
• 비용이 발생할 수 있는 작업 전

이 지점에서 에이전트는 “승인 요청서”를 사람에게 보여주고, 승인 또는 반려 입력을 기다립니다.

4. 승인 후 처리

승인이 들어오면 다음 단계로 진행합니다.

반려되면 실행하지 않고 종료하거나 수정 요청 상태로 되돌립니다.

중요한 것은 승인 전에는 부작용이 있는 작업을 하지 않는 것입니다.

에이전트가 “승인 요청서를 만들었다”는 것과 “실제 변경을 실행했다”는 것은 완전히 다른 단계로 분리되어야 합니다.

준비물 → 단계 → 검증 → 실패 시 점검

준비물

이 가이드를 적용하려면 다음 전제가 필요합니다.

1. LangGraph를 사용하는 Python 기반 에이전트 프로젝트

2. 운영 변경 요청을 입력으로 받을 수 있는 구조

3. 승인자가 검토할 수 있는 채널 또는 UI

4. 실행 상태를 이어가기 위한 persistence 설계

5. 위험 작업을 실제 실행하는 도구와 권한의 분리

LangGraph 공식 저장소의 최신 릴리스는 리서치 기준 langgraph 1.2.11로 확인되었습니다.

• 릴리스: https://github.com/langchain-ai/langgraph/releases/tag/1.2.11
• 빠른 시작 문서: https://docs.langchain.com/oss/python/langgraph/quickstart

다만 실제 프로젝트에서는 설치 버전, 의존성, 런타임 환경을 별도로 확인해야 합니다.

단계 1. 업무 결과물을 먼저 고정한다

먼저 에이전트가 만들 최종 산출물을 정합니다.

이번 예시는 “운영 변경 승인 요청서”입니다.

산출물이 고정되지 않으면 에이전트는 매번 다른 형식으로 답할 수 있습니다.

그러면 승인자는 무엇을 봐야 하는지 알기 어렵고, 자동화도 검증하기 어려워집니다.

승인 요청서의 기본 구조는 다음처럼 잡을 수 있습니다.

```markdown

변경 요약

영향 범위

위험 작업 여부

승인 전 확인 필요 항목

실행 전 체크리스트

승인 상태

• 대기

```

여기서 핵심은 “확인 필요” 항목을 숨기지 않는 것입니다.

근거가 부족한 항목은 에이전트가 추측해서 채우면 안 됩니다.

단계 2. 그래프를 승인 전 단계와 승인 후 단계로 나눈다

운영 자동화 그래프는 최소한 두 영역으로 나누어야 합니다.

1. 승인 전 단계

2. 승인 후 단계

승인 전 단계에서는 다음까지만 허용합니다.

• 입력 정리
• 변경 요약
• 영향 범위 정리
• 위험 작업 여부 표시
• 승인 요청서 생성

승인 후 단계에서는 승인된 경우에만 다음을 수행합니다.

• 배포 실행
• 삭제 실행
• 외부 발송
• 권한 변경
• 결과 기록

이렇게 나누면 에이전트가 실수로 실행 단계까지 넘어가는 위험을 줄일 수 있습니다.

단계 3. 위험 작업 직전에 interrupt를 둔다

LangGraph의 interrupt 문서는 그래프 실행을 특정 지점에서 멈추고 외부 입력을 기다리는 패턴을 설명합니다.

운영 승인 워크플로우에서는 이 지점을 “부작용이 있는 작업 직전”으로 잡아야 합니다.

예를 들어 다음과 같은 흐름입니다.

1. 변경 요청 입력

2. 에이전트가 승인 요청서 작성

3. 위험 작업 여부 표시

4. interrupt로 실행 중단

5. 승인자 입력 대기

6. 승인 시 실행

7. 반려 시 종료 또는 수정 요청

여기서 주의할 점은 interrupt 이전에 실제 변경이 일어나면 안 된다는 것입니다.

interrupt는 “이미 실행한 뒤 보고하는 장치”가 아니라 “실행 전에 멈추는 장치”로 사용해야 합니다.

단계 4. persistence로 상태를 이어간다

승인 워크플로우는 한 번의 요청 안에서 끝나지 않을 수 있습니다.

승인자가 바로 응답하지 않을 수 있고, 검토 중에 시간이 지날 수도 있습니다.

따라서 실행 상태를 저장하고 이어갈 수 있어야 합니다.

LangGraph persistence 문서는 checkpointer와 store의 용도를 구분합니다.

리서치 기준으로 persistence는 그래프 실행 상태를 유지하고, 중단된 흐름을 이어가는 데 중요한 개념입니다.

운영 승인 워크플로우에서는 최소한 다음 상태를 남겨야 합니다.

• 승인 요청서 내용
• 현재 단계
• 승인 대기 여부
• 승인자 입력
• 실행 여부
• 실패 또는 반려 사유

상태 저장이 없으면 승인자가 나중에 응답했을 때 “무엇에 대한 승인인지”를 잃어버릴 수 있습니다.

단계 5. 승인 입력을 실행 권한과 분리한다

사람이 승인했다고 해서 에이전트가 모든 권한을 가져야 하는 것은 아닙니다.

실무에서는 승인 입력과 실행 권한을 분리하는 편이 안전합니다.

예를 들어 승인자는 “진행 승인”을 입력하고, 실제 실행 도구는 제한된 범위의 작업만 수행하게 할 수 있습니다.

점검해야 할 항목은 다음과 같습니다.

• 에이전트가 삭제 권한을 항상 가지고 있는가?
• 외부 발송 권한이 기본으로 열려 있는가?
• 승인 전에도 실행 도구를 호출할 수 있는가?
• 실패 시 같은 작업이 중복 실행될 수 있는가?
• 승인 기록과 실행 기록이 분리되어 남는가?

특히 운영 자동화에서는 idempotent 처리가 중요합니다.

같은 승인 입력이 두 번 들어오더라도 같은 작업이 중복 실행되지 않게 설계해야 합니다.

바로 적용하는 체크리스트 또는 비교 기준

운영 승인형 에이전트를 만들 때는 아래 기준으로 점검해 볼 수 있습니다.

설계 체크리스트

• [ ] 에이전트의 결과물이 하나로 고정되어 있는가?
• [ ] 승인 요청서에 변경 요약, 영향 범위, 위험 작업 여부가 포함되는가?
• [ ] 확인되지 않은 항목을 “확인 필요”로 표시하는가?
• [ ] 배포·삭제·외부 발송·권한 변경 전 반드시 멈추는가?
• [ ] interrupt가 실행 후 보고가 아니라 실행 전 중단 지점에 있는가?
• [ ] 승인 전 단계와 승인 후 단계가 분리되어 있는가?
• [ ] 승인자가 반려했을 때 실행하지 않고 종료되는가?
• [ ] persistence를 통해 승인 대기 상태를 이어갈 수 있는가?
• [ ] checkpointer 설정 여부를 확인했는가?
• [ ] 승인 입력이 중복되어도 같은 작업이 반복 실행되지 않는가?
• [ ] 민감 작업 권한이 에이전트에 과도하게 부여되어 있지 않은가?
• [ ] 승인 기록과 실행 기록을 나중에 확인할 수 있는가?

실패 시 점검 순서

문제가 생겼다면 아래 순서로 확인하는 것이 좋습니다.

1. 에이전트가 승인 전 단계에서 실제 실행 도구를 호출하고 있지 않은가?

2. interrupt 위치가 위험 작업 “직전”이 맞는가?

3. 승인 요청서에 판단에 필요한 정보가 충분히 들어 있는가?

4. 확인필요 항목을 에이전트가 임의로 채우고 있지 않은가?

5. persistence 설정이 없어 승인 대기 상태가 사라지는 것은 아닌가?

6. 승인 입력이 두 번 들어왔을 때 중복 실행되는 구조는 아닌가?

7. 실행 권한이 승인 흐름과 분리되어 있는가?

도입 전 비교 기준

LangGraph interrupt 기반 승인 워크플로우가 특히 적합한 경우는 다음과 같습니다.

• 운영 변경처럼 중간 승인 지점이 필요한 업무
• 문서 작성과 실제 실행을 분리해야 하는 업무
• 사람이 최종 판단해야 하는 위험 작업이 포함된 업무
• 실행 상태를 이어가야 하는 장기 워크플로우
• 승인 기록과 실행 흐름을 나중에 확인해야 하는 업무

반대로 단순 요약, 단발성 질의응답, 위험 작업이 없는 내부 문서 정리라면 처음부터 interrupt 기반 승인 흐름까지 만들 필요는 없을 수 있습니다.

마무리 + 생각해볼 질문 1개

AI 에이전트를 업무에 붙일 때 가장 먼저 떠오르는 장점은 속도입니다.

하지만 운영 자동화에서는 속도보다 중요한 것이 있습니다.

멈춰야 할 곳에서 멈추는 능력입니다.

LangGraph의 interrupt와 persistence는 에이전트가 사람의 승인을 기다리고, 중단된 상태를 이어가며, 위험 작업을 통제된 흐름 안에서 다루도록 설계할 때 사용할 수 있습니다.

이번 글의 핵심은 간단합니다.

에이전트에게 모든 실행을 맡기기 전에, 승인 요청서라는 중간 산출물을 만들고, 위험 작업 직전에 반드시 멈추게 하십시오.

생각해볼 질문은 하나입니다.

우리 조직의 자동화 업무 중 “AI가 도와줘도 되지만, 실행 전에는 반드시 사람이 멈춰 세워야 하는 지점”은 어디인가요?