에이전트 제품 설계

ReAct만으로 운영은 안 돈다

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

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

읽기 →

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

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

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

읽기 →

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

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

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

읽기 →

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

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

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

읽기 →

기억은 저장이 아니라 정책이다

에이전트 메모리는 쓰기 기준에서 갈린다

에이전트 메모리 설계의 출발점은 저장소가 아니다. 무엇을 기억할지, 누가 쓰게 할지, 언제 폐기할지를 먼저 정해야 운영에서 오염을 막는다.

읽기 →

출력은 약속이 아니라 계약이다

스키마·검증·수정 루프가 운영을 만든다

구조화 출력은 프롬프트 문구가 아니라 운영 계약이다. 스키마로 경계를 정하고, 검증으로 실패를 분리하고, 자기수정 루프로 복구 가능한 오류만 되돌려야 한다.

읽기 →

에러 복구가 에이전트를 가른다

재시도보다 먼저 실패 경로를 설계해야 한다

에이전트는 실패하지 않는 시스템이 아니다. 좋은 에이전트는 실패를 숨기지 않고, 재시도·폴백·서킷브레이커로 업무 피해가 커지기 전에 멈추고 우회한다.

읽기 →

에이전트는 중간에 멈춘다

승인 버튼보다 멈춤 지점이 먼저다

Human-in-the-loop는 마지막 승인 버튼이 아니다. 에이전트가 언제 멈추고, 누구에게 무엇을 물으며, 어떤 근거로 다시 실행할지 정하는 운영 계약이다.

읽기 →

검색은 이제 파이프라인이 아니다

agentic retrieval은 검색을 판단 가능한 도구로 격상시킨다

RAG의 한계는 벡터DB가 아니라 검색을 고정 절차로 다루는 설계에 있다. agentic retrieval은 언제, 어디서, 얼마나, 다시 찾을지를 에이전트가 판단하게 만드는 운영 설계다.

읽기 →

메모리는 에이전트의 운영체계다

단기·장기·공유 메모리를 섞으면 에이전트는 흔들린다

에이전트 메모리는 대화 이력을 오래 보관하는 기능이 아니다. 단기·장기·공유 메모리를 분리하고, 승격·폐기·권한 규칙을 운영해야 현장 에이전트가 반복 업무에서 누적 성과를 낸다.

읽기 →

팀 설정이 에이전트를 지킨다

settings.json은 개인 취향 파일이 아니라 운영 규약이다

Claude Code를 팀에 풀면 성과보다 먼저 설정 편차가 드러난다. settings.json은 권한, hook, plugin, sandbox를 팀 운영 단위로 고정하는 에이전트 통제면이다.

읽기 →

권한 없는 에이전트는 사고다

도구·데이터·예산은 실행 전에 잘라야 한다

에이전트 실패는 답변 품질 문제가 아니라 권한 경계 문제로 터진다. 운영 에이전트는 도구, 데이터, 예산을 같은 통제면에서 설계해야 한다.

읽기 →