10월 10일 토요일

확률적인 에이전트에 장기 실행과 실제 부작용을 맡기면서도 시스템을 복구·감사·검증 가능하게 만드는 최소 경계는 무엇인가?

네 원문이 만나는 지점은 모델 호출이 애플리케이션의 중심이 아니라는 사실이다. 에이전트의 `reason → act → observe` 루프는 다음 행동을 제안할 수 있지만, 실행 순서·권한·승인·재시도·외부 부작용은 결정론적 계층이 소유해야 한다. 사람의 응답은 200밀리초짜리 함수 반환이 아니라 수분에서 수주까지 늦어질 수 있는 비동기 신호다. 그 시간을 스레드가 붙잡고 기다리게 하면 한 승인이 전체 흐름을 막고, 프로세스 장애 때 질문과 상태도 잃는다. 반대로 워크플로 이벤트 이력에 상태를 저장하고 외부 호출을 별도 활동으로 분리하면 서비스가 내려간 동안 들어온 승인도 복구 뒤 이어서 처리할 수 있다. 이 구조는 자율성을 줄이는 장치가 아니라, 어느 지점에서 모델의 유연성을 허용하고 어디서 시스템의 불변 조건을 강제할지 명시하는 실행 계약이다.

1. 01

   상태·외부 호출·인간 신호를 분리한다

   Temporal 사례에서 workflow는 결정론적 단계와 대기 상태를 보존하고, activity는 모델·도구처럼 결과가 달라질 수 있는 외부 호출을 담당하며, worker는 실제 코드를 실행한다. 인간 승인은 `wait condition`에 주차된 실행으로 `signal`을 보내 해제한다. worker가 꺼진 동안 승인해도 이벤트가 저장되고, 복구 뒤 이력을 재생해 다음 단계로 간다. 재생은 과거 부작용을 무조건 다시 실행하는 일이 아니라 현재 상태를 복원하는 과정이다.

2. 02

   LLM은 계획하고 하니스가 행동한다

   Conductor 사례는 LLM을 ‘뇌’, 하니스를 ‘손’으로 나눈다. SRE 에이전트가 로그 분석·롤백·복구 검증을 계획해도 프로덕션 재시작의 승인 게이트와 실행 순서는 코드에 고정된다. 작업은 가능하면 멱등적으로 만들고, 불가능하면 이메일 발송이나 클러스터 재시작 같은 부작용을 상태에 기록한다. 런타임에 도구 순서를 고르는 유연성은 유지하되, 허용된 도구·권한·게이트는 미리 제한한 후기 바인딩 사가에 가깝다.

3. 03

   프로덕션을 마지막 검증자로 둔다

   샘 뉴먼은 분산 시스템이 정보 지연, 사라질 수 있는 의존성, 유한한 자원이라는 세 현실을 피할 수 없다고 지적한다. 따라서 AI 자동화도 성공 기준과 관측 데이터를 먼저 정하고, 비결정적 작업을 명확한 모듈 경계 안에 가둬야 한다. 테스트와 사양은 중요한 모델이지만 실제 사용자 경험·SLO·장애가 그 모델을 반박할 수 있다. 위험이 낮고 경계가 분명한 모듈에서 자율성을 높이고, 중요 경로에서는 인간과 결정론적 코드를 남기는 점진적 전략이 필요하다.

4. 04

   검증 권한은 신뢰에 맞춰 단계적으로 넓힌다

   AI가 PR의 수와 크기를 늘리면 비용은 생성에서 리뷰·CI·운영으로 이동한다. Guitar.ai 사례는 자동 리뷰 결과를 사람이 확인하는 단계에서 시작해, 정확성이 확인되면 병합 차단, 자동 수정, 조건부 승인·병합 순으로 권한을 넓힌다. 에이전트 판단만 쓰지 않고 태인트·제어 흐름·데이터 흐름·소프트웨어 구성 분석 같은 재현 가능한 프로그램 분석을 결합해 정밀도와 커버리지를 보완한다. 자동화의 속도보다 어떤 증거를 통과해야 다음 권한을 얻는지가 핵심이다.

구현 경계는 선명하다. 비결정론은 계획과 해석에 쓰고, 상태 전이와 권한·승인·부작용은 결정론적으로 보존한다. 인간 대기는 비동기 신호로 모델링하고, 프로덕션 데이터가 사양을 검증하게 하며, 자동화 권한은 관찰된 정밀도에 맞춰 올린다. 이 네 층이 빠지면 에이전트는 데모에서는 영리해도 장애 뒤 복구할 수 없고, 무엇을 실행했는지 설명하기도 어렵다.

에이전트가 더 많은 컨텍스트를 읽는 것과 실제 업무 구조·운영 상태·근거 있는 기억을 이해하는 것은 어떻게 다른가?

컨텍스트를 긴 프롬프트나 검색 결과의 묶음으로만 취급하면 에이전트는 관련 문장을 찾을 수 있어도 현재 시스템이 무엇을 하고 있으며 어떤 절차가 검증됐는지 알기 어렵다. Reducto는 API 엔드포인트마다 MCP 도구를 붙인 첫 구현이 큐레이션된 데모에서는 동작했지만 실제 팀 입력이 들어오자 자신 있게 틀리는 워크플로를 만들었다. 해법은 시스템 프롬프트를 늘리는 것이 아니라 도구의 형태를 바꾸는 일이었다. Dynatrace 사례는 여기에 서비스 의존성과 프로덕션 사용 방식, 권한과 관측 데이터를 공급해야 로컬 변경이 주변 서비스에 미칠 영향을 볼 수 있다고 덧붙인다. Neo4j 사례는 한 단계 더 나아가 메시지 검색이 아니라 엔티티·관계·결정 이유·도구 결과를 타입과 근거가 있는 그래프로 남기고, 거기서 실행 가능한 스킬을 증류한다. 세 층을 합치면 컨텍스트는 토큰 더미가 아니라 도구 선택과 검증을 제한하는 운영 모델이 된다.

1. 01

   엔드포인트가 아니라 업무 전이를 도구로 만든다

   Reducto는 첫 MCP 서버 전체를 삭제하고 도구 수를 줄였다. 모델이 `classify` 다음 `extract`를 프롬프트에서 추측하게 두지 않고, 검증된 전이를 하나의 도메인 도구로 제공했다. snapshot 도구는 파이프라인의 live state와 오류 코드를 돌려주며, confidence score와 bounding box는 불확실성을 다음 판단의 입력으로 만든다. 애매한 입력에서는 추측보다 질문을 보상하고, 세션과 사람의 override를 계측해 장기 가이드로 되돌린다.

2. 02

   운영 맥락을 개발 루프로 끌어온다

   에이전트가 같은 시도를 반복하며 토큰을 쓰는 이유는 모델이 약해서만이 아니라 실패한 접근을 바꿀 환경 맥락이 없기 때문이다. 서비스 의존성, 사용자에게 전달할 가치, 실제 부하와 정상 상태, 코드 변경과 운영 이상 사이의 연결을 제공하면 로컬에서 성공한 기능이 다른 서비스를 깨뜨리는 문제를 배포 전에 볼 수 있다. 흐름은 관찰, 맥락 구축, 로컬 테스트, 이상 감지, 수정 제안, 인간의 최종 배포 결정으로 이어진다.

3. 03

   검색된 기억을 추적 가능한 절차로 바꾼다

   임베딩 검색은 관련 텍스트를 찾지만 동일 인물의 여러 표현을 하나로 해소하거나 행동의 근거를 보장하지 않는다. Neo4j는 단기·장기·추론 기억을 컨텍스트 그래프로 연결하고, 결정 추적에 근거·정책·실행 계획·도구 호출·결과·토큰·시간을 함께 저장한다. 스킬은 산문 파일보다 타입이 있는 실행 그래프로 표현해 입력·행동·출력을 디버깅한다. 증류 과정은 grounding, coverage, coherence를 검사하고 원천 데이터 변경에 따른 stale skill과 drift도 관리한다.

4. 04

   세 층의 실패 모드를 따로 관측한다

   도구 구조가 잘못되면 에이전트는 유효하지 않은 업무 순서를 만든다. 운영 맥락이 없으면 현재 환경에서 안전하지 않은 변경을 제안한다. 기억의 근거와 최신성이 없으면 과거에 맞았던 절차를 지금도 옳다고 재사용한다. 따라서 도구 호출 성공률 하나로 품질을 판단하지 말고, 도메인 전이의 유효성, 의존 서비스 영향, 결정 근거와 스킬 최신성을 별도 신호로 남겨야 한다. 그래야 모델 교체와 무관하게 실패가 어느 층에서 생겼는지 좁힐 수 있다.

에이전트의 컨텍스트 엔지니어링은 더 긴 프롬프트를 만드는 작업이 아니다. 실제 업무 전이를 담은 좁은 도구, 프로덕션의 관계와 상태, 근거·타입·최신성을 가진 기억을 결합하는 일이다. 이 구조가 있으면 에이전트는 추측 공간을 줄이고, 사람은 오류가 난 계층과 책임을 추적하며, 조직은 검증된 실행만 공용 스킬로 확장할 수 있다.