블로그

에이전트 지연은 연결 문제다

긴 작업은 모델보다 왕복 설계에서 먼저 느려진다

tool-call이 많은 에이전트는 답변 생성보다 왕복 오버헤드에서 지연이 쌓인다. Responses API WebSocket은 이 왕복을 열린 세션 안에서 이어 붙이는 transport 설계다.

읽기 →

도구는 늦게 올려야 한다

수백 개 schema는 context가 아니라 색인에 둔다

MCP 도구가 늘면 agent는 똑똑해지는 것이 아니라 산만해진다. Lazy tool hydration은 도구 정의를 미리 싣지 않고, 필요한 순간 검색·파일시스템·코드 실행으로 주입하는 운영 설계다.

읽기 →

FDE는 채용보다 양성이다

현장에 심을 엔지니어는 따로 길러야 한다

에이전트는 회의실에서 정착하지 않는다. 고객사 데이터, 권한, 예외, 운영 리듬 안으로 들어가 끝까지 책임지는 FDE 팀이 있어야 한다.

읽기 →

FDE가 AX 성패를 가른다

에이전트는 현장에 붙은 엔지니어가 완성한다

에이전트 프로젝트는 PoC 통과가 아니라 운영 투입에서 성패가 갈린다. Forward Deployed Engineer 모델은 컨설팅과 엔지니어링을 분리하지 않고, 고객사 현장에서 프로덕션까지 책임지는 딜리버리 구조다.

읽기 →

루프 디버깅은 로그가 아니다

에이전트 운영은 스텝의 의미를 관측해야 끝난다

에이전트 장애는 에러 로그보다 실행 궤적에서 먼저 드러난다. 헛도는 스텝, 무한루프, 조기종료는 각각 다른 관측 지표와 다른 튜닝 처방이 필요하다.

읽기 →

에이전트는 끝나야 일한다

수렴은 모델 성능이 아니라 루프 설계의 결과다

에이전트 실패는 답을 못 해서가 아니라 멈출 조건 없이 계속 움직여서 생긴다. 종료조건, 진행도, 예산 게이트를 루프에 넣어야 운영 가능한 제품이 된다.

읽기 →

프로세스 오너가 에이전트를 맡아야 한다

AI-Native 조직은 역할표부터 다시 짠다

AI 에이전트는 도구가 아니라 위임받은 일의 실행 단위다. 프로세스 오너는 업무 설명자가 아니라 Agent Product Owner가 되어 backlog, 권한, 평가, RACI를 운영해야 한다.

읽기 →

제품 기능은 버튼이 아니라 계약이다

agent가 호출할 수 없으면 기능은 잠긴다

AI-Native 제품의 표면은 화면이 아니라 action contract다. UI는 그 계약을 사람이 쓰는 방식이고, agent는 같은 계약을 기계가 호출하는 방식이다.

읽기 →

로그인 에이전트는 가둬야 쓴다

권한보다 격리가 먼저인 브라우저 설계

SaaS를 조작하는 에이전트의 핵심 리스크는 모델이 아니라 로그인된 세션이다. 브라우저 VM, 세션별 egress allowlist, credential shadowing을 기본 구조로 잡아야 운영에 올릴 수 있다.

읽기 →

Subagent는 큐로 다뤄야 한다

위임보다 중요한 것은 join과 cancel이다

Supervisor가 subagent를 호출하고 기다리는 구조는 운영에서 막힌다. 원격 subagent는 task ID로 위임하고, 필요할 때 join·update·cancel하는 비동기 큐로 설계해야 한다.

읽기 →

추론은 저장이 아니라 재생이다

tool call마다 reasoning span을 다르게 다룬다

에이전트가 tool call을 여러 번 거치면 실패는 모델보다 컨텍스트 재생에서 먼저 난다. reasoning span은 로그가 아니라 실행 상태다. 보존·마스킹·재주입 정책을 tool call 단위로 설계해야 한다.

읽기 →

Skill도 검증돼야 쓴다

출처와 권한이 없는 Skill은 운영 자산이 아니다

Skill과 MCP bundle은 문서가 아니라 실행 가능한 운영 자산이다. provenance, SBOM, 권한 manifest, tamper check가 붙어야 배포·승인·폐기가 가능해진다.

읽기 →