14. 프로덕션 에이전트

✎ 이 문서 수정하기 GitHub에서 수정

한 번의 요청이 동작하는 것과 대화를 이어 가며 안전하게 운영하는 것은 다르다. 이전 문맥을 보존하고, 허용 범위를 벗어난 요청을 막고, 실패나 중단 뒤 어떤 상태에서 다시 시작할지 정해야 한다.

14.1 메모리

메모리는 모델의 가중치에 모든 대화를 새로 학습시키는 기능이 아니다. 애플리케이션이 필요한 상태를 저장하고 다음 실행의 입력으로 복원하는 구조다.

14.1.1 메모리의 범위

단기와 장기는 무조건 저장 매체로 구분되지 않는다. 대화 범위의 상태도 디스크 DB에 오래 보관할 수 있다. 무엇을 어느 범위에서 재사용하는지가 먼저다.

14.1.2 단기 메모리가 필요한 이유

“같은 마을에서 객실을 찾아 줘”라는 질문은 앞에서 고른 마을을 알아야 한다. 매 요청마다 새 상태로 호출하면 그 연결이 사라진다.

도구 호출 대화에서는 사용자와 모델의 문장만이 아니라 호출 요청과 도구 결과의 관계도 중요하다. 일부 메시지만 보관하면 프로토콜상 대응이 끊기거나 결과를 잘못 해석할 수 있다.

메모리가 있다고 모든 과거 메시지를 매번 모델에 넣어야 하는 것은 아니다. 필요한 범위를 선택하고 요약할 수 있지만 중요한 날짜와 제약, 미확인 사항을 잃지 않아야 한다.

14.1.3 LangGraph 체크포인트

체크포인트는 특정 실행 경계의 그래프 상태 스냅샷이다. 대화뿐 아니라 노드의 중간 결과와 다음 실행에 필요한 정보를 포함할 수 있다.

LangGraph의 실행은 super-step이라는 단위로 이해할 수 있다. 같은 단계에서 병렬 노드가 실행될 수도 있으므로 “항상 함수 한 줄마다 저장” 또는 “무조건 각 개별 노드 직후에 독립 스냅샷”으로 외우는 것은 부정확하다.

Thread ID는 상태를 이어 갈 실행 묶음의 식별자다. 같은 Thread에 새 질문을 넣으면 저장된 상태를 바탕으로 이어 가고, 다른 Thread면 별도 대화가 된다.

14.1.4 체크포인터 연결

그래프를 compile할 때 체크포인터를 연결하고 호출 설정에 Thread ID를 제공한다. 인메모리 저장은 실습에 편하지만 프로세스를 재시작하면 사라진다.

운영에서는 영속 저장소와 접근 정책, 보존 기간을 정해야 한다. Thread ID를 알고 있다는 사실만으로 그 상태를 읽을 권한이 있다고 봐서는 안 된다. 인증된 사용자와 Thread 소유권의 연결이 필요하다.

모델 제공자의 이전 응답 ID를 사용하는 방식과 LangGraph의 상태 저장은 다른 계층이다. 제공자와 라이브러리 버전에 따라 메시지 전달 규칙이 다르므로 특정 설정이 모든 조합에서 반드시 필요하다고 일반화하지 않는다.

14.1.5 연속 실행

첫 요청에서 장소를 정하고 같은 Thread로 후속 질문을 보내 대상이 유지되는지 확인한다. 다른 Thread에서는 그 정보가 섞이지 않아야 한다.

저장소에 상태가 남는 것과 모델이 적절한 문맥을 받는 것도 별개다. 모델 호출 전에 메시지를 줄이거나 재구성한다면 실제 전달한 내용을 확인해야 한다.

14.1.6 과거 상태로 돌아가기

이전 체크포인트를 선택해 당시 상태를 확인하거나 다른 방향으로 실행을 이어 갈 수 있다. 같은 질문에서 다른 선택을 했을 때를 비교하는 데 유용하다.

그러나 상태를 되감는다고 외부 세계도 되돌아가지는 않는다. 이미 보낸 메시지나 완료한 결제, 생성한 예약은 별도의 작업이다.

    flowchart TD
    accTitle: 그래프 상태 복원과 외부 부작용의 다른 수명
    accDescr: 과거 체크포인트를 복원하면 저장된 그래프 상태로 돌아가지만 이미 실행한 외부 예약은 취소되지 않는다. 재실행에는 중복 방지와 별도 취소 절차가 필요하다.
    C["체크포인트 A"] --> T["예약 도구 실행"]
    T --> N["체크포인트 B"]
    T --> E["외부 시스템에 예약 생성"]
    N -->|"상태 복원"| C
    C -.->|"자동으로 취소되지 않음"| E
  

재실행 가능한 노드에는 중복 방지 키와 이미 실행한 결과를 확인하는 절차가 필요하다. 읽기 전용 조회와 부작용이 있는 행동의 복구 정책을 나눠야 한다.

14.2 가드레일

가드레일은 입력과 처리, 출력에 적용하는 범위와 정책 검사다. 잘못된 요청을 일찍 막고 모델이나 도구의 결과가 허용 조건을 만족하는지 확인한다.

단순한 주제 분류, 구조 검증과 민감정보 검사, 도구 권한 통제는 서로 다른 역할이다. 모델에게 “규칙을 지켜라”라고 말하는 것만으로 모두 해결되지 않는다.

14.2.1 여행과 무관한 요청 차단

입력에서 서비스 범위에 맞는 질문인지 분류한다. 여행 도우미를 일반적인 무료 모델 호출 창구처럼 사용하는 것을 줄일 수 있다.

그렇지만 분류 모델도 틀릴 수 있다. 정상 요청을 막는 오차단과 범위 밖 요청을 통과시키는 미차단을 함께 평가해야 한다.

주제 검사는 권한 검사가 아니다. 여행 질문이라는 이유로 다른 사용자의 예약 정보에 접근해도 되는 것은 아니다. 허용 자료와 작업은 실행 계층에서 강제한다.

14.2.2 에이전트별 추가 제한

상위 입력이 여행 관련이어도 전문 에이전트가 지원하는 지역과 기능은 더 좁을 수 있다. Cornwall 자료만 가진 도구가 다른 지역의 사실을 추측하지 않도록 범위를 확인한다.

상위 Router의 검사와 하위 에이전트의 검사는 역할이 다르다. 내부 경로가 바뀌거나 도구가 직접 호출되더라도 필요한 제약을 유지해야 한다.

검사 서비스가 실패했을 때의 정책도 필요하다. 위험한 작업에서 확인 실패를 정상 통과로 처리하면 통제가 사라진다. 제한 응답이나 사람의 검토 등 실패 동작을 명시한다.

14.3 운영에서 더 필요한 것

14.3.1 장기 사용자와 애플리케이션 메모리

장기 메모리는 여러 Thread에서 재사용할 정보다. 사용자 선호와 공통 지식을 같은 범위에 저장하면 정보가 섞일 수 있다.

저장할 사실의 출처와 유효 시점, 수정과 삭제 경로를 정해야 한다. 과거 모델의 추측을 사용자에 대한 확정 사실로 저장하지 않는다.

체크포인터는 Thread의 그래프 상태를, Store는 Thread 밖의 애플리케이션 데이터를 보관하는 역할로 구분할 수 있다. LangGraph 영속성 문서도 두 저장 체계를 나눠 설명한다.

14.3.2 Human-in-the-loop

사람의 검토는 모호한 요청이나 외부 행동 전에 실행을 멈추고 확인받는 과정이다. 사용자가 원하는 최종 조건과 실제 실행할 인자를 보여 줘야 의미 있는 승인이 된다.

예약이라면 숙소, 날짜와 인원, 가격 및 취소 조건을 승인 대상에 연결한다. 승인 뒤 내용이 바뀌었다면 이전 승인을 새 요청에 재사용해서는 안 된다.

중단된 실행을 누가 재개할 수 있고 얼마나 기다릴지, 승인 거절과 만료를 어떻게 처리할지도 필요하다.

14.3.3 출력 가드레일

출력에서는 민감한 정보, 근거 없는 주장과 잘못된 형식을 확인한다. 사용자에게 보여 주는 자연어와 외부 도구에 보낼 구조화된 행동 요청은 다른 기준이 필요하다.

존재하지 않는 인용을 검사할 때는 링크 문법뿐 아니라 해당 문서가 실제 주장을 뒷받침하는지 봐야 한다. 구조 검증만으로 의미적 안전을 보장할 수는 없다.

사후 검사는 이미 실행한 행동을 막을 수 없다. 예약과 결제의 승인과 검증은 실행 전에 있어야 한다.

14.3.4 평가

최종 답만 맞았어도 필요 없는 도구를 수십 번 호출했다면 운영 비용이 클 수 있다. 반대로 지정한 경로를 모두 따랐어도 근거를 잘못 읽으면 답이 틀린다. 결과와 실행 경로를 함께 평가해야 한다.

실시간 정보는 정답이 바뀐다. 회귀 시험에서는 고정된 도구 응답을 사용해 비교하고, 실제 연동 시험에서는 현재 서비스의 연결과 데이터 유효성을 별도로 확인하는 방법이 유용하다.

14.3.5 배포

책은 LangGraph 기반 플랫폼과 호스팅 선택을 소개한다. 관리형 환경을 사용해도 서비스의 데이터 경계와 모델 품질, 권한과 비용을 모두 대신 결정해 주지는 않는다.

자체 배포에서는 API 서버와 실행 워커, 상태 저장소와 도구 연결의 수명을 관리해야 한다. 긴 실행의 취소와 재개, 버전 변경 시 저장된 상태의 호환성도 필요하다.

트레이스와 체크포인트에는 대화와 도구 결과가 남는다. 인증과 접근 통제, 암호화와 보존 정책을 적용하고 실제로 삭제할 수 있는지까지 확인해야 한다.

질문

체크포인트가 있으면 실패한 작업을 그대로 재실행해도 될까?

외부 부작용이 이미 발생했을 수 있다. 저장된 그래프 상태와 외부 시스템의 실제 상태를 함께 확인해야 한다.

메모리와 가드레일을 붙이면 프로덕션 준비가 끝날까?

평가, 관측, 권한과 비용, 복구 및 운영 책임이 남는다. 기능이 존재하는 것과 실제 요구에서 검증한 것은 다르다.

이전: MCP 서버 / 시리즈 목차 / 책의 구성