10월 5일 월요일

장기 실행 코딩 에이전트가 많은 변경을 만들면서도 사람이 모든 대화를 감시하지 않게 하려면 무엇을 분리해야 하는가?

에이전트 운영을 모델 호출 수의 문제로 보면 병렬화할수록 검토 부채도 함께 커진다. 한 달에 2,000개의 PR을 반영한 사례가 보여 주는 핵심은 에이전트 수가 아니라 실패하기 어려운 변경 경로다. 애플리케이션을 직접 실행하는 검증 CLI, 기능과 조작 경로를 기록한 Feature Map, 정적 분석과 CI, 의존성 경계, 원자적 PR을 겹쳐 결과를 증거로 남긴다. 동시에 프롬프트에는 행동, 외부 메모리에는 크고 자주 바뀌며 출처와 권한이 필요한 사실, 모델 가중치에는 합의된 안정적 패턴을 둬야 한다. 여기에 대화 이력과 모델 상태를 잇는 Interaction ID, 파일·패키지·실행 상태를 보존하는 Environment ID를 분리하면 장기 작업의 재개 지점을 명시할 수 있다. 즉 안전한 에이전트 플랫폼은 변경, 지식, 실행 상태라는 서로 다른 수명주기를 하나의 거대한 프롬프트나 불투명한 세션에 섞지 않는다.

1. 01

   변경 경계: 가장 쉬운 길을 안전한 길로 만든다

   에이전트가 기존 코드를 복사한다는 전제에서 코드베이스 자체를 첫 방어선으로 삼는다. Dune은 기능을 한 폴더에 모으고 Electron의 Main과 Renderer 사이 import 경계를 CI로 강제하며, 60 FPS의 16밀리초 예산을 침범할 무거운 작업이 렌더러로 들어오지 못하게 한다. 반복되는 교정은 사람의 리뷰 메모가 아니라 lint와 정적 분석으로 내린다. 검증 스킬은 앱을 실행해 성능 트레이스와 Heap Snapshot을 모으고, Engineering Skill은 구현 품질을 보완한다. 여기서 테스트 통과는 기능 정확성의 증거이지 모든 불변식의 형식 검증은 아니다.

2. 02

   지식 경계: 행동·사실·능력을 다른 저장소에 둔다

   말투와 실패 시 사람에게 넘기는 절차처럼 작고 안정적인 행동은 프롬프트에 적합하다. 제품 목록, 정책, 코드처럼 크고 빠르게 바뀌며 출처와 접근 제어가 필요한 사실은 검색 가능한 외부 메모리에 둬야 한다. 코드 검색은 함수·클래스 같은 구조를 보존해 청킹하고 저장소·사용자·권한 메타데이터로 먼저 필터링해야 한다. 검색 실패를 파인튜닝으로 덮으면 낡은 사실이 가중치에 굳을 수 있다. 파인튜닝은 변화가 멈추고 조직의 판단이 합의됐으며 능력이나 비용이라는 명확한 목적이 있을 때 검토하는 선택이지, 검색의 상위 단계가 아니다.

3. 03

   상태 경계: 대화 맥락과 실행 환경을 따로 이어 간다

   Interactions API는 서버가 thought signature와 이전 행동을 보존하고, 클라이언트는 previous_interaction_id로 다음 상호작용을 잇게 한다. 그러나 대화 상태만으로는 장기 작업을 재개할 수 없다. Managed Agents는 Environment ID로 같은 파일, 설치된 패키지, 샌드박스 실행 상태에 돌아가게 한다. Steps의 강한 타입은 텍스트·이미지·오디오·비디오·함수 호출을 명시적인 단계로 구분한다. 자격 증명은 모델 컨텍스트에 넣지 않고 outbound 프록시가 대상 API 요청에 주입한다. 대화 ID와 환경 ID를 함께 기록해야 어떤 맥락이 어떤 작업공간을 변경했는지 추적할 수 있다.

4. 04

   검증 경계: 주장보다 재현 가능한 증거를 남긴다

   검증은 계층마다 달라야 한다. 코드 변경은 동일한 CLI로 기능 경로와 성능을 재현하고, 최신 사실은 검색된 문서 조각과 권한 필터를 확인하며, 장기 실행은 Interaction ID와 Environment ID 조합으로 상태를 복원한다. 에이전트가 많은 PR을 만들었다는 처리량, 200만 토큰 규모 저장소를 분석했다는 실행량, 최대 1,000개의 Named Agent를 지원한다는 용량은 각각 사례와 제품 범위를 설명하지만 독자 시스템의 정확성을 보장하지 않는다. 실제 채택 전에는 실패 입력, 권한 경계, 상태 재개, 회귀 탐지의 관측값을 별도로 수집해야 한다.

확장 순서는 에이전트를 더 띄우는 것보다 경계를 먼저 고정하는 쪽이어야 한다. 나쁜 변경을 구조적으로 막는 paved path, 사실을 최신 상태와 권한에 맞게 꺼내는 메모리, 대화와 샌드박스를 독립적으로 복원하는 식별자를 준비한 뒤 병렬성을 높인다. 그리고 사람의 반복 교정이 생길 때마다 규칙을 더 강한 계층으로 옮긴다. 설명은 프롬프트에, 반복 위반은 lint와 CI에, 실행 결과는 재현 가능한 검증 도구에, 비밀은 모델 밖 프록시에 두는 식이다. 이 경계를 넘는 예외가 계속 생기면 모델을 교체하기 전에 저장 위치와 검증 경로가 잘못됐는지부터 진단해야 한다.

오픈 모델을 실제 서비스에 넣을 때 지연시간·장애 복구·판단 오류를 어떤 계층에서 각각 통제해야 하는가?

프로덕션 AI의 성능은 모델 벤치마크 하나로 설명되지 않는다. 서빙 경로에서는 요청을 관련 KV cache가 있는 GPU로 보내는 cache-aware routing, 작은 draft 모델의 출력을 큰 모델이 확인하는 speculative decoding, 계산 중심 prefill과 메모리 중심 decode의 분리, 품질을 보존하는 quantization이 지연·처리량·비용을 바꾼다. 인프라 경로에서는 Slurm의 gang scheduling과 topology awareness를 Kubernetes의 노드 수명주기·관찰 가능성과 결합해 GPU 장애를 격리하고 작업을 재큐해야 한다. 애플리케이션 경로에서는 모든 판단을 생성형 LLM에 맡기지 않고, 제한된 선택지와 보정된 확률을 반환하는 System One 모델로 분류·라우팅·검토 경계를 만들 수 있다. 세 계층은 연결되지만 성공 기준은 다르다. 빠른 토큰, 복원된 작업, 보정된 결정은 서로 대체 가능한 지표가 아니다.

1. 01

   서빙 제어면: 같은 모델도 배치 방식이 비용을 바꾼다

   긴 코드베이스와 다양한 출력 길이를 가진 요청을 GPU에 무작위로 나누면 캐시가 파편화된다. cache-aware router는 관련 캐시가 있는 GPU로 요청을 보내고, KV cache가 GPU 메모리를 압박하면 일반 메모리로 offload했다가 재사용한다. speculative decoding은 빠른 작은 모델이 초안을 만들고 큰 모델이 승인하거나 다시 생성하게 해 순차 디코딩 비용을 낮춘다. prefill과 decode를 서로 다른 GPU 집합에 분리하면 계산 집약 단계와 메모리 집약 단계의 자원 경쟁을 줄일 수 있다. 다만 캐시의 5~10배 속도 향상과 draft 모델의 최대 30% 개선은 발표에서 관찰한 값이므로 실제 입력 분포와 하드웨어에서 다시 측정해야 한다.

2. 02

   복구 제어면: 스케줄러와 노드 수명주기를 연결한다

   분산 학습에서 Slurm은 gang scheduling, topology awareness, 익숙한 sbatch 흐름을 제공하지만 하드웨어 원인 분석과 노드 교체까지 단독으로 책임지지는 않는다. Kubernetes 위의 Managed Slurm은 XID 79를 감지하면 노드를 down 처리하고 작업을 취소·재큐한 뒤, 최대 2분의 SIGTERM 유예 동안 checkpoint와 로그를 저장하게 한다. 이어 Kubernetes가 노드를 cordon·drain하고 예비 노드로 교체한다. 데모에서 인프라 복구는 약 5분, checkpoint 로딩을 포함한 전체 중단은 15분 미만이었다. 자동 교체가 성공해도 애플리케이션이 유효한 checkpoint를 저장하고 읽지 못하면 작업 상태는 복원되지 않는다.

3. 03

   판단 제어면: 생성 대신 타입과 확률로 분기한다

   Jev는 자유 문장을 쓰지 않고 예·아니오인 Noul, 제한된 목록의 Choice, 순서형 Score와 각 선택의 확률을 반환한다. 고객지원에서는 환불 여부·담당 팀·긴급도를 한 요청에서 판단하고, 높은 확률은 자동 처리, 중간 구간은 사람 검토, 낮은 확률은 비처리 경로로 보낼 수 있다. 여기서 calibration은 80%라고 한 판단 묶음이 장기적으로 약 80% 맞는 집단적 성질이지 개별 결과의 보증이 아니다. 임계값은 오판 비용과 실제 라벨 데이터로 정해야 한다. Jev는 텍스트 전용이고 수학·계수에 약하며 적대적 지시의 영향도 받을 수 있으므로, 출력 타입이 제한됐다는 사실을 판단 안전성과 혼동해서는 안 된다.

4. 04

   통합 검증: 평균 성능보다 경계의 실패를 측정한다

   운영 검증은 서빙, 복구, 판단을 따로 관찰한 뒤 연결해야 한다. 서빙은 입력·출력 길이별 지연시간, 처리량, 캐시 적중률, 품질 저하를 비교하고, 복구는 장애 감지부터 격리·교체·재큐·checkpoint 재개까지의 단계별 시간을 기록한다. 판단 모델은 확률 구간별 실제 적중률, 자동 처리율, 사람 검토량, 비싼 오판의 빈도를 본다. 프로덕션 로그를 학습·튜닝·재배포로 잇는 폐루프는 개선 속도를 높이지만, 잘못된 라벨이나 드리프트도 되먹임할 수 있다. 따라서 모델 버전, 서빙 설정, checkpoint, 임계값을 독립적으로 되돌릴 수 있어야 어떤 변경이 회귀를 만들었는지 분리할 수 있다.

오픈 모델 운영의 아키텍처 결정은 ‘무엇이 가장 똑똑한가’보다 ‘어디에서 무엇을 실패로 볼 것인가’에서 시작해야 한다. 토큰 경로는 캐시·디코딩·양자화의 성능과 품질을, GPU 경로는 노드 교체와 checkpoint 재개의 복구 시간을, 업무 경로는 확률 보정과 사람 검토 비용을 책임진다. 관리형 수직 통합은 이 복잡성을 숨길 수 있지만 검증 책임까지 없애지는 않는다. 공급자가 제시한 최대 개선치와 데모 복구 시간은 기준 후보로만 쓰고, 실제 트래픽·장애·라벨 분포에서 같은 경계를 계측해야 한다. 세 제어면의 지표와 롤백 단위를 분리할 때만 최적화가 다른 계층의 오류를 가리는 일을 피할 수 있다.