상태 외부화로 설계하는 컨텍스트 프로그래밍 에이전트

컨텍스트를 변수로 옮기는 이유

필요한 정보를 매 턴 컨텍스트에 모두 넣는 방식은 창 길이 제한에 먼저 닿고, 현재 판단과 무관한 기록까지 모델의 입력에 남긴다. 세션이 길어질수록 정확도가 낮아지고 전체 히스토리를 반복 전송하는 비용도 누적된다.

Prime Agent는 이 문제를 영속 IPython 커널로 다룬다. 모델은 고정된 도구 호출 스키마 대신 세션 전체에 유지되는 REPL을 호출하고, 사전 임포트된 스킬과 도구를 코드로 조합한다. 조건 분기와 반복도 모델 턴을 추가로 쓰지 않고 실행 환경 안에서 처리한다.

RLM(Recursive Language Model) 관점에서는 컨텍스트가 단순히 쌓이는 텍스트가 아니다. 과거 정보는 액티브 컨텍스트 바깥의 변수에 보존하고, 현재 판단에 필요한 내용만 조회해 가져온다. Prime Agent는 이 구성으로 네이티브 하네스보다 높은 점수를 더 낮은 전체 토큰 사용량으로 달성했다고 보고됐다.

영속 커널이 다루는 상태

세션당 커널을 하나씩 배정했다면, 먼저 수명과 재시작 조건, 최대 유지 시간을 정해야 한다. 커널을 무기한 유지하면 메모리와 실행 슬롯이 계속 점유된다. 재시작 시에도 어떤 상태를 복원하고 어떤 상태를 버릴지 구분해야 하며, 모든 상태를 되살리면 재시작은 정리 효과를 잃는다.

변수 네임스페이스 역시 운영 대상이다. 모델이 만든 임시 변수와 하네스가 관리하는 상태 변수가 구분되지 않으면 임시 값이 중요한 상태를 덮어쓸 수 있다. 비동기 서브에이전트를 RLM으로 실행할 때는 각 에이전트의 네임스페이스를 분리해 서로의 상태가 섞이지 않게 한다.

조회 결과를 다시 컨텍스트에 넣을 때는 최대 길이와 요약 형식이 필요하다. 외부로 옮긴 대용량 결과를 그대로 되돌려 넣으면 컨텍스트 외부화의 이점이 사라진다. 반대로 요약이 판단에 필요한 항목을 누락하지 않도록 필수 필드를 규격에 명시해야 한다.

⤢✕

상태를 밖으로 꺼낼 때 함께 정할 운영 규약

대용량 조회 결과, 중간 계산 산출물, 파일 내용, 이전 턴의 관측값은 외부화 후보가 된다. 반면 판단 규칙과 제약 조건처럼 매 턴 참조하는 정보는 컨텍스트에 남기는 편이 맞다. 외부화 자체가 목적이 되면 조회 부담만 늘어난다.

실행 환경의 격리 방식도 처음부터 결정해야 한다. 컨테이너 격리, OS 샌드박스, 원격 실행 환경 가운데 하나를 선택하고 접근 가능 범위를 문서화한다. 자격증명이 커널 환경 변수에 노출되지 않는 경로도 확보해야 한다. 임의 코드를 실행하는 도구에서는 격리 수준이 곧 권한 통제다. 저장소 쓰기 권한은 작업 워크트리로 제한한다.

커널별 메모리·CPU·디스크·네트워크 상한과 초과 시 처리 방식을 정하고, 동시 커널 수에도 상한을 둔다. 유휴 시간 기준 종료, 최대 유지 시간, 강제 재시작 조건을 세션 정책에 포함하면 세션 증가가 호스트 자원을 소진하는 일을 막을 수 있다. 종료 시 스냅숏 보존 여부와 보존 기간도 같은 정책 안에서 다룬다.

조회 함수 인터페이스, 변수 이름 규칙, 요약 형식, 필수 필드는 문서로 고정하는 편이 낫다. 규약이 없으면 모델은 매번 다른 방식으로 상태를 찾는다. 이 규약을 스킬 모듈로 사전 임포트하면 모델이 조회 방식을 반복해서 재구성할 필요도 없다.

스냅숏과 오류 격리가 장기 세션을 지탱한다

참조되지 않는 변수는 주기적으로 회수하되, 회수 이력과 사전 스냅숏을 남긴다. 장기 세션은 메모리 누적으로 종료되는 경우가 많고, 잘못 회수한 상태는 복구할 수 있어야 한다.

주요 체크포인트에서는 네임스페이스 스냅숏을 직렬화해 보존한다. 이는 커널 재시작이나 세션 이관의 근거가 된다. 열린 소켓과 파일 핸들처럼 직렬화할 수 없는 객체는 스냅숏에서 제외하고 재생성 절차를 별도로 정의한다.

커널 예외가 세션 전체를 끝내지 않도록 오류를 잡아 모델에 관측값으로 전달해야 한다. 오류 메시지는 다음 코드 작성의 입력이 된다. 무한 루프와 장시간 실행에는 실행 시간 상한을 두어 커널 점유를 끊는다. 정기 작업에서는 고아 커널, 만료된 스냅숏, 미회수 변수를 정리하되 활성 세션 여부를 먼저 확인한다.

상태 외부화와 컨텍스트 누적의 선택

구분	상태 외부화 구성	컨텍스트 누적 구성
처리 가능 정보량	큼	창 크기 제한
컨텍스트 길이	짧게 유지	계속 증가
정확도 (장기 세션)	유지	저하
토큰 사용량	낮음	높음
구현 복잡도	높음	낮음
조회 지연	발생	없음

상태 외부화는 필요한 정보를 변수에 남겨 두고 조회하므로, 짧은 컨텍스트로 더 많은 정보를 다룰 수 있다. 관련 없는 과거 기록이 판단을 흐리는 문제와 토큰 사용량도 줄어든다. 대신 조회 규약과 요약 규격을 설계해야 하며, 모델이 무엇을 찾아야 하는지 판단하지 못하면 필요한 정보에 접근하지 못한 채 답할 수 있다.

컨텍스트 누적은 모든 정보가 입력에 있으므로 조회 실패가 없고 구현이 단순하다. 짧은 세션에서는 지연도 최소다. 그러나 세션이 길어지면 창 한계와 무관한 과거 정보의 간섭을 피하기 어렵고, 매 턴 전체 히스토리를 전송하는 비용이 쌓인다. 정보량과 세션 길이가 창 크기 안에 확실히 들어오는 작업이라면 누적 구성이 합리적이다. 장시간 작업에서는 외부화가 사실상 유일한 선택이 된다.

코드 실행 도구와 전용 도구의 경계

단일 코드 실행 도구는 조건 분기와 반복을 코드로 표현해 여러 도구 호출을 한 턴에 묶을 수 있다. 새 도구도 함수로 추가하면 되므로 확장이 가볍고, 턴 수와 토큰을 함께 줄일 수 있다. 하지만 임의 코드 실행 권한이 한 지점에 모이며, 격리가 없으면 사고 반경은 실행 환경 전체가 된다. 모델이 잘못된 코드를 작성했을 때 실패 양상도 전용 도구 호출 오류보다 진단하기 어렵다.

다수의 전용 도구는 입력 스키마가 고정돼 잘못된 호출을 사전에 걸러낼 수 있고, 도구별 권한을 나눠 최소 권한을 적용하기 쉽다. 반면 도구 정의가 컨텍스트를 차지하고, 여러 도구를 조합하는 작업은 턴 수만큼 왕복을 요구한다. 도구가 많아질수록 선택 정확도도 떨어진다. 강한 샌드박스 격리를 전제할 수 있다면 단일 코드 실행이 효율에서 앞서고, 격리가 어려운 환경에서는 전용 도구의 권한 분리가 안전 측면에서 우세하다.

영속 세션은 커널에 남은 변수와 임포트 상태를 재사용하므로 반복 준비 작업을 줄이고 장기 작업의 맥락과 서브에이전트 협업 상태를 이어갈 수 있다. 그 대가로 메모리와 커널 슬롯을 점유하며, 누적 상태가 오염되면 원인을 찾기 어렵다. 요청별 신규 세션은 깨끗한 상태에서 시작하고 종료와 함께 자원을 회수하지만, 준비 작업이 반복되고 이전 산출물을 이어받을 별도 방법이 필요하다. 짧은 단발 요청은 신규 세션으로, 장기 위임 작업은 유휴 종료와 최대 유지 시간을 둔 영속 세션으로 나누는 방식이 자원과 맥락을 함께 관리한다.

운영 설계에서 보는 핵심 연결점

미참조 변수 회수와 스냅숏 보존은 가비지 컬렉션과 체크포인팅을 결합한 구조다. 액티브 컨텍스트와 외부 변수의 분리는 작업 집합과 전체 데이터를 나누는 계층 구조에 대응한다.

임의 코드 실행 도구에서는 컨테이너와 샌드박스 선택이 보안 통제의 실체가 된다. 서브에이전트별 네임스페이스 분리도 프로세스 간 주소 공간 분리와 같은 목적을 가진다. 결국 조회 규약과 요약 규격을 고정하는 일은 인터페이스를 표준화하는 작업이며, 재현성의 전제가 된다. 무엇을 액티브 컨텍스트에 두고 무엇을 외부 변수로 보낼지 정하는 판단이 이 아키텍처의 본체다.

코드 실행 단일 도구 구성이 에이전트 하네스의 주류 패턴으로 자리잡고 샌드박스 격리가 기본 요건이 되는 흐름, RLM 계열 추상화가 프레임워크 API로 제공되는 방향, 상태 스냅숏 형식의 표준화와 세션 이관·도구 간 이식이 가능해지는 흐름이 이어지고 있다. 커널 자원 상한과 세션 수명 정책도 에이전트 운영의 표준 항목으로 편입되는 방향이다.