10월 9일 금요일

에이전트에게 판단을 맡기면서도 재현 가능한 실행과 검증 경계를 어떻게 만들 것인가?

세 원문이 공통으로 가리키는 실패는 모델 성능 부족보다 제어와 증거가 자연어 컨텍스트 안에 섞이는 데서 시작한다. 메가 프롬프트에 초안, 승인, 전송 규칙을 함께 넣으면 실행이 길어질수록 규칙의 상대적 비중이 낮아지고 어느 문장에서 흐름이 어긋났는지 특정하기 어렵다. 반대로 현재 상태와 이벤트가 다음 상태를 정하도록 만들면 승인 없는 전송처럼 금지해야 할 경로를 구조에서 닫을 수 있다. 그러나 상태 머신만 세운다고 운영 품질이 생기지는 않는다. 로그 원문을 계속 창에 쌓으면 처음과 끝보다 중간 정보를 놓치는 문제가 생기고, 멀티 에이전트가 같은 전체 컨텍스트를 공유하면 비용과 오염 범위가 함께 커진다. 따라서 대용량 자료는 외부 저장소에 두고 포인터, 선택 검색, 압축, 역할별 격리로 입력을 줄여야 한다. Uber의 Debug Assist는 이 두 층을 실제 디버깅 하네스에서 결합한다. 데이터 수집과 전처리는 결정론적 노드가 맡고, 분류·RCA·수정처럼 판단이 필요한 구간에만 LLM을 배치하며, 마지막에는 가장 짧은 재현 경로와 테스트로 수정안을 확인한다.

1. 01

   규칙은 프롬프트가 아니라 전이로

   생성이 필요한 이메일 문안은 비결정론적으로 남겨도 초안 작성, 검토, 명시적 승인, 수신자 확인은 상태 전이로 고정할 수 있다. 핵심은 그래프를 화면용 순서도가 아니라 실행 가능한 계약으로 쓰는 것이다. 같은 상태에서 같은 이벤트가 오면 예측 가능한 다음 상태로 가게 하고, 허용하지 않은 전이는 정의하지 않는다. 평가도 최종 산출물 하나만 보지 않고 각 상태의 결과, 전체 결과, 상태 사이 전이의 품질로 나눈다. 그래야 성공했지만 질문과 재시도가 과도한 흐름도 결함으로 잡고 V1과 V2를 같은 시나리오에서 비교할 수 있다.

2. 02

   컨텍스트는 저장 공간이 아니라 공급 경로

   더 큰 창은 더 많은 토큰을 담을 뿐 모든 위치의 정보를 같은 품질로 쓰게 하지 않는다. 설계 단위는 무엇을 보관할지가 아니라 어떤 에이전트가 어느 시점에 어떤 근거를 회수할지다. 로그 원문은 외부화하고 ID만 상태에 남기며, 질문과 관련된 구간만 선택하고, 오래된 대화는 압축하되 원문을 다시 찾을 경로를 보존한다. 스웜에서는 전체 기록 대신 invocation state의 포인터만 공유한다. 도구는 성공·실패·진행 중을 명확히 반환하고 호출 상한을 둬 반복 결과가 창에 누적되는 일을 차단한다. 장시간 작업은 작업 ID와 상태 조회로 분리해 동기 대기가 실행 전체를 붙잡지 않게 한다.

3. 03

   증거 수집과 추론을 서로 다른 노드로

   Debug Assist의 Context collector는 신고, 앱 상태, 로그와 크래시 자료를 정해진 API에서 가져와 파싱·전처리·가지치기한다. 그 다음 LLM 노드가 코드, 서드파티, 인프라, 네트워크 문제인지 분류하고 신뢰도를 붙인다. RCA는 breadcrumb와 crash correlation처럼 목적이 좁은 서브에이전트로 나눠 병렬 실행하지만 탐색 턴 수를 제한한다. 수정 전에 기능 플래그로 완화 가능한지 확인하고, 수정 뒤에는 unit test를 우선하며 필요할 때 integration, component, 모바일 E2E로 이동한다. 결론 옆의 evidence timeline과 재현 결과가 있어야 로그 요약이 실제 원인과 코드 변경으로 이어졌는지 사람이 검토할 수 있다.

4. 04

   고정 골격과 가변 전문성의 분리

   운영 규모가 커질수록 모든 판단을 하나의 범용 에이전트에 몰아넣는 대신 변하지 않는 실행 골격과 런타임 전문 지식을 나누는 편이 낫다. 상태, 전이, 재시도 상한, 결과 전달과 테스트 순서는 하네스에 남기고, 좋은 PR을 만드는 법이나 Android 이슈를 고치는 법은 스킬과 플러그인으로 선택 로드한다. Uber는 agent type에 따라 바이너리, Docker 환경, 파이프라인과 필요한 플러그인만 가져와 전체 스킬 카탈로그가 컨텍스트를 잠식하지 않게 한다. 이 분리는 모델 교체보다 중요한 검증 경계를 유지하면서도 도메인 팀이 자기 지식을 추가할 수 있게 한다.

최소 구현은 거대한 프레임워크가 아니다. 허용 상태와 종료 조건을 코드로 적고, 대용량 근거를 밖에 저장해 필요한 조각만 회수하며, 모든 전이와 도구 호출을 추적하고, 수정 뒤 재현 테스트를 통과시키면 된다. 그 위에서만 모델이나 스킬을 바꿔 같은 시나리오의 경로 길이, 실패 위치, 결과 품질을 비교할 수 있다. 상태 머신은 생성 능력을 대신하는 장치가 아니라 생성이 넘지 말아야 할 경계이고, 컨텍스트 관리와 증거 검증은 그 경계가 실제 운영에서 지켜졌는지 확인하는 계측층이다. 원문들이 제시한 사례는 이 접근의 가능성을 보여 주지만 모든 도메인에서 같은 정확도나 비용을 보장하지는 않으므로, 팀별 실패 비용과 재현 가능한 평가 세트를 먼저 정의해야 한다.

장시간 실행 에이전트가 코드를 만들고 배포 흐름에 참여할 때 어떤 경계를 순서대로 검증해야 하는가?

독립 샌드박스, 지속적 오펜시브 시큐리티, 소프트웨어 팩토리는 서로 다른 제품 설명처럼 보이지만 실제로는 실행 경계의 세 층을 다룬다. 첫째, 파일 생성·의존성 설치·코드 실행·도구 호출은 격리된 환경에 두고 상태와 작업 ID를 서버 쪽에서 관리한다. 둘째, 샌드박스 안에서 작업이 끝났다는 사실을 안전성의 증거로 착각하지 않고 정적 분석, 동적 테스트, 비즈니스 로직을 이해하는 공격 검증을 코드 변경마다 결합한다. 셋째, 검증된 변경도 버그 리포트에서 계획·리뷰·테스트·배포·릴리스 관찰로 이어지는 조직의 전달 경로를 통과시킨다. 이때 핵심 트레이드오프는 자율성을 얼마나 주느냐보다 실패가 어느 경계에서 멈추고 어떤 증거를 남기느냐다. 관리형 실행 환경은 중계 인프라 부담을 줄이지만 권한과 지속 상태를 별도로 설계해야 하고, AI 침투 테스트는 공격 빈도를 높이지만 기존 SAST·DAST를 대체하지 못한다. 완전한 팩토리를 한 번에 닫힌 루프로 만들면 신뢰와 소유권을 확인할 기회가 줄어드므로 좁은 사건 분류와 진단부터 시작해야 한다.

1. 01

   게이트 1 · 실행 환경과 상태

   원격 환경은 코드, 파일, 의존성과 사용자 도구를 별도 샌드박스에서 실행하고 환경 ID로 후속 작업을 이어 간다. 장기 실행은 HTTP 연결을 계속 붙잡는 대신 작업 ID를 반환한 뒤 스트리밍이나 폴링으로 완료를 확인한다. 이 구조는 클라이언트 오케스트레이션을 줄이고 같은 환경에서 에이전트가 파일을 매개로 협업하게 하지만, 관리형이라는 말이 곧 최소 권한이나 안전을 보장한다는 뜻은 아니다. 어떤 소스와 AGENTS.md·스킬을 주입할지, 환경 상태를 얼마나 지속할지, 사용자 API와 MCP에 어떤 권한을 줄지는 호출자가 별도의 정책으로 고정해야 한다.

2. 02

   게이트 2 · 변경마다 공격을 재현

   정적 분석은 SQL injection과 XSS 같은 코드 패턴에 강하고, DAST는 실행 중인 API를 찔러 BOLA 같은 권한 문제를 찾는다. 인간 침투 테스트는 비즈니스 로직을 이해하지만 비용 때문에 연 1~3회에 머무는 한계가 있다. 지속적 공격 검증은 모든 PR과 코드 delta에서 정찰, 취약점 탐색, Judge의 exploit 검증, 수정 제안과 보고를 이어 붙인다. 중요한 출력은 경고 개수가 아니라 실제 악용 경로와 재현 근거다. LLM이 기존 스캐너 결과와 애플리케이션 맥락을 활용하더라도, 사전 정의 payload에 강한 기존 도구와 맥락 기반 공격 에이전트를 경쟁시키지 말고 서로 다른 탐지 범위로 유지해야 한다.

3. 03

   게이트 3 · 신호에서 배포까지

   소프트웨어 팩토리는 버그 리포트, 사용자 피드백, Sentry 알림을 입력으로 받아 분류·계획·문서·코드·리뷰·테스트·롤아웃과 관찰을 연결한다. 처음부터 이 전체 루프를 자율화하면 설계가 잘못돼도 에이전트가 정밀하게 실행할 수 있다. 제시된 안전한 출발점은 사건 분류처럼 좁고 검증 가능한 자동화다. 에이전트가 알림과 trace를 읽어 Slack에 진단을 남기고 엔지니어가 다음 행동을 결정하게 한 뒤, 정확한 사례와 소유권이 쌓일 때 다음 기둥을 연결한다. RBAC, 최소 권한, 재현 가능한 개발 환경, CI 실패 조건, 단위·통합 테스트가 닫힌 루프에 앞서 있어야 한다.

4. 04

   검증 지표는 산출량보다 경계 통과

   생성 코드 줄 수와 토큰 소비량은 시스템이 안전하고 유용한 변경을 전달했는지 말해 주지 않는다. 대신 신호가 프로덕션 변경으로 이어지는 시간, 필요한 사람 개입 횟수, 복구 시간, 테스트와 롤아웃에서 잡힌 실패를 기록해야 한다. 보안 측에서는 지속 실행 여부, 비즈니스 맥락 추론, 입력 데이터의 폭, exploit 증명을 확인한다. 실행 측에서는 어떤 환경과 상태를 재사용했는지, 도구와 파일에 어떤 권한이 있었는지 감사할 수 있어야 한다. 이 지표들이 연결돼야 샌드박스 성공, 공격 테스트 통과, 배포 성공을 서로 다른 증거층으로 유지할 수 있다.

운영 순서는 환경 격리, 변경별 공격 검증, 조직의 배포 게이트다. 샌드박스에서 명령이 끝난 것은 실행 증거이고, Judge가 exploit을 재현한 것은 보안 증거이며, CI·리뷰·롤아웃 관찰을 통과한 것은 전달 증거다. 어느 하나를 다른 층의 성공으로 대체하면 자율화 속도만 빨라지고 실패 반경은 커진다. 먼저 좁은 입력과 제한된 권한, 명시적인 종료·재시도 조건으로 한 경로를 만들고, 정적·동적·공격 검증과 사람의 승인 지점을 붙인 뒤, 실제 복구 시간과 거짓 양성 감소가 확인될 때 다음 경로를 연결하는 것이 세 원문의 공통된 구현 경계다.