구글 I/O 2026 키노트가 '에이전트'라는 단일 키워드로 수렴하고 있다. 세션 트랙에는 에이전틱 코딩 워크플로, 멀티모달 도구, 로보틱스가 모두 올라 있고, Gemini를 단순 챗봇이 아닌 구글 제품 전체에 깔리는 '운영 레이어'로 자리매김하겠다는 메시지가 뚜렷하다. 이미 Gemini Enterprise 월간 활성 사용자가 전 분기 대비 40% 증가했다는 알파벳 공시 데이터는, AI 에이전트가 더 이상 실험적 개념이 아니라 실무 루틴에 깊숙이 들어왔음을 수치로 증명한다.
문제는 에이전트가 많아질수록 '지금 뭘 하고 있는가'를 파악하기가 오히려 어려워진다는 점이다. Claude Code, Codex, Gemini CLI를 동시에 띄워놓고 다른 작업을 하다 보면 어느 에이전트가 멈췄는지, 얼마나 썼는지 확인하기 위해 터미널을 열고 Activity Monitor를 뒤지는 반복이 생긴다. 오픈소스 도구 Agent Cat은 이 문제를 macOS 메뉴바 고양이 한 마리로 해결한다. 에이전트가 쉬면 자고, 작업 중이면 걷고, 풀가동이면 뛰는 애니메이션으로 상태를 즉각 시각화한다. 클릭하면 모델별 토큰 소비량과 프로젝트별 시간 내역이 펼쳐진다.
설계 철학이 흥미롭다. Agent Cat은 에이전트와 직접 통신하지 않는다. 대신 agentcatd라는 로컬 데몬이 각 에이전트가 어차피 로컬에 남기는 프로세스 상태와 사용량 파일을 수집해 127.0.0.1:8765/v1/snapshot으로 JSON을 제공하고, 메뉴바 앱은 그것만 폴링한다. API 호출 없음, 토큰 소비 없음, 프롬프트와 코드 열람 없음. 이 구조 덕분에 새 에이전트 지원은 '앱 전체 재빌드'가 아니라 '데몬에 어댑터 하나 추가'로 끝난다. 비용 계산도 입력·출력·캐시 읽기·캐시 쓰기를 분리해서 잡는다. 단가가 다른 항목을 합산하면 청구서와 어긋나기 때문이다.
가시성 문제를 해결했다면, 그다음은 에이전트에게 무엇을 시킬 것인가의 문제다. Codex의 Goals 기능은 이 지점을 정확히 겨냥한다. 일반 프롬프트가 '이 다음 작업을 해라'라면, Goal은 '이 결과가 참이 될 때까지 계속 작업해라'다. 멘탈 모델의 차이는 선명하다. 프롬프트는 ask → work → result → wait의 단발 루프지만, Goal은 work → check → continue or complete의 상태 기반 루프다. 스레드에 지속적 목표(durable target)가 부착되어, 턴이 끝날 때마다 현재 증거를 검사해 목표 충족 여부를 판단하고, 충족되지 않으면 예산 범위 안에서 작업을 이어간다.
핵심은 '완료의 정의'다. Codex는 계속 움직일 수 있지만, 완료 여부는 모델의 판단이 아니라 증거가 결정한다. 파일, 테스트 결과, 벤치마크 출력, 로그—구체적 증거에 대해 목표를 검사한 뒤에야 완료 처리가 가능하다. 이 설계가 약한 Goal과 강한 Goal의 차이를 만든다. /goal Reduce p95 latency below 120ms는 검증 수단이 없어서 약하다. 반면 checkout benchmark를 검증 수단으로, checkout service와 관련 테스트를 작업 범위로, 변경 내역·벤치마크 결과·다음 실험을 반복 정책으로, 경로가 없을 때 보고할 조건까지 명시한 Goal은 강하다. p95가 180ms에서 135ms로 개선돼도 120ms 미만이 아니면 미완료, 목표에 도달해도 정확성 테스트가 실패하면 미완료, 벤치마크 실행이 불가하면 성공 선언 대신 블로커를 표면화한다.
강한 Goal이 갖춰야 할 여섯 요소를 정리하면 이렇다: Outcome(완료 시 참이어야 할 것), Verification surface(이를 증명하는 테스트·벤치마크·산출물), Constraints(회귀되어선 안 되는 것), Boundaries(사용 가능한 파일·도구·데이터 범위), Iteration policy(시도 후 다음 행동 선택 방식), Blocked stop condition(방어 가능한 경로가 없을 때 보고하고 정지하는 시점). 이 여섯 요소를 한 문장 패턴으로 표현하면: /goal <종료 상태> verified by <구체적 증거> while preserving <제약>. Use <허용된 도구/경계>. Between iterations, <다음 최선 행동 선택 방식>. If blocked, <보고할 내용과 필요한 입력>.
예산 처리도 설계의 일부다. Goals는 스레드 범위의 영속 상태로 구현되며, 예산 도달 시 작업을 중단하고 진행 상황과 블로커를 요약한 뒤 다음 유용한 단계를 식별한다. 중요한 것은 예산 한도 도달이 목표 완료와 동일하지 않다는 점이다. 지속(continuation)은 이벤트 기반이며 보수적으로 동작한다—턴 종료 후, 대기 작업 없음, 사용자 입력 큐 없음, 스레드 유휴 상태일 때만 작동한다. 도구 호출을 하지 않는 지속 턴이 발생하면 다음 자동 지속을 억제해 스핀을 방지한다. 이 구조가 Agent Cat의 비용 분리 추적과 맞물리면, 어느 에이전트가 예산을 얼마나 소진하고 어디서 블로킹됐는지를 실시간으로 확인하는 루틴이 완성된다.
세 소스가 함께 가리키는 방향은 하나다. 멀티 에이전트 시대의 실용 조건은 도구의 숫자가 아니라 목표 설계의 정밀도 + 운용 가시성 + 비용 추적의 세 축이 동시에 갖춰지는 것이다. 구글 I/O 2026이 '에이전트를 운영 레이어로'라는 방향성을 선언한다면, 개발자에게 실질적으로 필요한 것은 그 레이어 위에서 에이전트가 언제 멈추고 언제 계속 가야 하는지를 명확하게 정의하는 능력이다. Goals는 Codex에게 단순히 '끝내라'고 요청하는 것이 아니라, '끝났다는 것의 의미'를 알려준다. 그리고 Agent Cat은 그 루프가 지금 어느 상태인지를 고양이 한 마리로 답한다.