에이전트 제품 설계

도구 결과는 명령이 아니다

스키마와 출처가 권한 경계를 만든다

에이전트가 망가지는 지점은 도구 호출 자체가 아니라 도구 결과를 명령처럼 읽는 순간이다. Tool-use integrity boundary는 결과의 형식, 출처, 권한을 분리해 운영 사고를 줄이는 설계다.

읽기 →

코드 migration은 수렴 설계다

병렬 agent보다 merge와 verifier가 먼저다

대규모 코드베이스 migration은 agent를 많이 띄우는 문제가 아니다. sandbox shard로 변경을 격리하고, patch merge와 테스트 verifier로 수렴시키는 운영 아키텍처가 본체다.

읽기 →

오래 가는 에이전트는 분리된다

복구는 더 큰 컨테이너가 아니라 상태 설계다

Durable sandbox agent의 핵심은 오래 켜진 컨테이너가 아니다. 하네스와 compute를 분리하고, snapshot·rehydration을 실행 경계로 설계해야 장기 실행이 운영으로 간다.

읽기 →

맥락은 줄이고 기억은 남겨라

긴 세션의 품질은 압축과 기억의 배치가 가른다

에이전트가 길게 일할수록 문제는 모델 성능보다 맥락 운영에서 터진다. 컨텍스트 압축과 메모리 계층을 분리하지 않으면 중요한 규칙은 사라지고 잡음만 남는다.

읽기 →

재시도는 신뢰성이 아니다

멱등성 없는 도구 호출은 운영 사고다

에이전트 도구 호출의 신뢰성은 모델 성능보다 실행 하네스에서 갈린다. 타임아웃·재시도·멱등성을 설계하지 않으면 작은 지연이 중복 실행과 비용 사고로 번진다.

읽기 →

서브에이전트는 경계가 먼저다

역할보다 상태와 책임 경계를 먼저 자른다

서브에이전트는 조직도처럼 나누면 실패한다. 쪼갤 기준은 전문성보다 상태, 권한, 산출물 계약이다. 합칠 때도 운영 기준이 필요하다.

읽기 →

긴 창보다 예산이 먼저다

토큰은 기억이 아니라 운영 예산이다

컨텍스트 윈도우가 커질수록 에이전트 설계는 쉬워지지 않는다. 이제 핵심은 더 많이 넣는 기술이 아니라, 무엇을 매번 넣고 무엇을 검색·압축·캐시할지 정하는 운영 규칙이다.

읽기 →

툴 스키마가 에이전트를 가른다

도구 혼선은 모델 문제가 아니라 인터페이스 문제다

에이전트가 엉뚱한 도구를 고르는 순간은 대부분 실행 전에 결정된다. 툴 스키마는 API 문서가 아니라 모델이 읽는 운영 지시서다.

읽기 →

ReAct만으로 운영은 안 돈다

에이전트는 추론 패턴이 아니라 실행 시스템이다

ReAct는 에이전트의 출발점이지 운영 아키텍처가 아니다. 기업 현장의 에이전트는 계획, 도구, 권한, 관찰, 중단, 복구가 묶인 제어 루프로 설계해야 한다.

읽기 →

하네스가 에이전트를 일하게 한다

context·tool·memory는 제어 루프로 묶여야 한다

에이전트 품질은 모델만으로 결정되지 않는다. 업무 맥락, 도구, 기억, 검증 루프를 어떻게 조립하느냐가 운영 가능한 에이전트의 경계다.

읽기 →

용어를 모르면 에이전트가 흔들린다

운영 언어가 설계 품질을 결정한다

에이전트 개발의 난점은 모델 호출이 아니라 운영 언어의 혼선에서 온다. 같은 단어를 다르게 이해하면 도구, 권한, 평가, 장애 대응이 모두 흔들린다.

읽기 →

장기 메모리는 백엔드 싸움이다

벡터·그래프·파일은 역할이 다르다

에이전트 장기 메모리는 저장소 하나로 끝나지 않는다. 벡터는 찾고, 그래프는 관계를 유지하고, 파일은 작업 맥락을 남긴다. 선택 기준은 기술 취향이 아니라 실패 형태다.

읽기 →