블로그
AI 전환(AX), 에이전트 도입, AX Ops 방법론에 대한 현장 기록.
-

Agent Card는 계약이다
A2A v1 적합성은 실행 테스트로 증명한다
A2A Agent Card는 소개 문서가 아니라 호출 계약이다. supportedInterfaces, auth scheme, streaming·push 선언은 TCK에서 실제 요청으로 깨뜨려 봐야 운영에 올라간다.
읽기 → -

프롬프트가 아니라 루프를 설계하라
가장 가치 있는 일이 모델 호출에서 한 칸 멀어졌다
2026년 6월, 루프 엔지니어링이라는 이름이 붙었다. 가치의 무게중심이 좋은 프롬프트를 쓰는 일에서 에이전트를 굴리는 시스템을 설계하는 일로 옮겼다. 부품은 이미 Claude Code와 Codex 안에 다 들어 있다.
읽기 → -

업무 기능은 등록돼야 한다
AI 시대의 조직도는 부서가 아니라 호출 가능한 기능이다
AI agent가 일하려면 부서 매뉴얼이 아니라 호출 가능한 capability가 필요하다. 기능명, owner, eval SLA, 권한 범위를 registry로 관리하지 않으면 agent 운영은 매번 현장 해석에 의존한다.
읽기 → -

전체 로그보다 델타가 싸다
Agent rollout 비교는 상태 변화로 줄여야 한다
test-time scaling은 rollout을 늘릴수록 비용과 판정 난도가 같이 오른다. 전체 로그를 다시 읽히지 말고, compact state delta로 trajectory sketch를 만들고 그 스케치를 re-ranking해야 운영비가 잡힌다.
읽기 → -

검증도 라우팅해야 산다
위험도별 reward 선택이 운영 품질을 만든다
에이전트 운영의 병목은 생성이 아니라 검증이다. 테스트, rubric, 사용자, agent verifier를 하나로 묶고 작업 위험도별로 라우팅해야 reward가 운영 통제 장치가 된다.
읽기 → -

위임은 호출이 아니라 계약이다
Task adapter가 벤더 경계를 낮춘다
내부 에이전트를 그대로 외부에 열면 벤더별 호출 규칙만 늘어난다. A2A Task adapter는 내부 실행을 Task·Artifact·state transition 계약으로 감싸 위임 가능한 단위로 바꾼다.
읽기 → -

에이전트 지연은 연결 문제다
긴 작업은 모델보다 왕복 설계에서 먼저 느려진다
tool-call이 많은 에이전트는 답변 생성보다 왕복 오버헤드에서 지연이 쌓인다. Responses API WebSocket은 이 왕복을 열린 세션 안에서 이어 붙이는 transport 설계다.
읽기 → -

도구는 늦게 올려야 한다
수백 개 schema는 context가 아니라 색인에 둔다
MCP 도구가 늘면 agent는 똑똑해지는 것이 아니라 산만해진다. Lazy tool hydration은 도구 정의를 미리 싣지 않고, 필요한 순간 검색·파일시스템·코드 실행으로 주입하는 운영 설계다.
읽기 → -

FDE는 채용보다 양성이다
현장에 심을 엔지니어는 따로 길러야 한다
에이전트는 회의실에서 정착하지 않는다. 고객사 데이터, 권한, 예외, 운영 리듬 안으로 들어가 끝까지 책임지는 FDE 팀이 있어야 한다.
읽기 → -

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

루프 디버깅은 로그가 아니다
에이전트 운영은 스텝의 의미를 관측해야 끝난다
에이전트 장애는 에러 로그보다 실행 궤적에서 먼저 드러난다. 헛도는 스텝, 무한루프, 조기종료는 각각 다른 관측 지표와 다른 튜닝 처방이 필요하다.
읽기 → -

에이전트는 끝나야 일한다
수렴은 모델 성능이 아니라 루프 설계의 결과다
에이전트 실패는 답을 못 해서가 아니라 멈출 조건 없이 계속 움직여서 생긴다. 종료조건, 진행도, 예산 게이트를 루프에 넣어야 운영 가능한 제품이 된다.
읽기 →