AI 코딩 어시스턴트가 단순한 자동완성에서 '작업을 대신 수행하는 에이전트'로 넘어가면서, 실제로 그런 도구가 내부적으로 어떤 기능을 손에 쥐고 있는지에 대한 관심이 커지고 있다. 최근 공개된 한 참조 문서는 이른바 'Codex Work' 세션에서 에이전트가 사용할 수 있는 도구와 스킬 정의를 나열한다. 특정 제품의 성능이나 벤치마크를 다루는 자료는 아니지만, 요즘 에이전트형 개발 환경이 어떤 부품으로 조립되는지를 한눈에 보여주는 목록이라는 점에서 실무자가 참고할 가치가 있다.
파일 편집과 명령 실행이라는 뼈대
목록의 중심에는 코드를 실제로 다루는 기본 도구가 있다. 파일을 수정하는 apply_patch는 패치를 JSON으로 감싸지 않는 '프리폼' 방식으로 동작한다고 명시돼 있고, 명령 실행은 PTY(의사 터미널) 위에서 이뤄져 출력값을 돌려주거나 세션 ID를 반환해 계속 상호작용할 수 있게 한다. 여기에 실행 중인 셀의 결과를 기다리는 도구, 세션에 문자를 직접 써 넣는 도구가 따로 있다는 점이 눈에 띈다. 즉 에이전트는 한 번의 명령으로 끝나는 배치 작업뿐 아니라, 대화형 프로세스와 지속적으로 주고받는 상황까지 다룰 수 있도록 설계돼 있다. 개발 자동화에서 실전 난이도가 높은 부분이 바로 이 '오래 살아 있는 세션' 관리인데, 도구 층위에서부터 이를 별도로 분리해 둔 셈이다.
흥미로운 항목은 JavaScript 코드를 새 V8 아이솔레이트 안에서 비동기 모듈로 평가해 여러 도구 호출을 조율·합성하게 하는 기능이다. 이는 에이전트가 개별 도구를 순차적으로 부르는 데 그치지 않고, 코드를 짜서 도구 호출 자체를 프로그래밍적으로 엮을 수 있다는 뜻이다. 반복 작업이나 조건 분기가 필요한 오케스트레이션을 모델의 판단에만 맡기지 않고 결정론적 스크립트로 넘길 수 있는 구조로, 신뢰성 측면에서 의미가 있다.
멀티 에이전트와 작업 계획
또 하나의 축은 에이전트가 다른 에이전트를 부리는 기능이다. 목록에는 하위 에이전트를 생성(spawn)하고, 이미 존재하는 에이전트에 후속 작업을 보내거나 메시지를 전달하고, 진행 중인 턴을 중단시키고, 현재 스레드 트리에서 살아 있는 에이전트를 나열하고, 어떤 에이전트든 메일박스 갱신을 기다리는 도구가 함께 들어 있다. 생성된 에이전트는 같은 도구와 공유 파일시스템에 접근하며 스스로 또 다른 하위 에이전트를 만들 수 있다고 돼 있다. 큰 작업을 여러 병렬 작업자로 쪼개 처리하는 구성이 도구 수준에서 이미 전제돼 있는 것이다. 여기에 계획 항목을 갱신하되 '동시에 진행 중(in_progress) 상태는 최대 하나'로 제한하는 태스크 플랜 도구가 붙어, 작업 흐름을 사람이 추적하기 쉽게 정돈한다.
스킬과 외부 연동, 그리고 MCP
목록은 개발용 도구를 넘어 폭넓은 업무 연동으로 확장된다. GitHub 저장소·이슈·PR 접근, Gmail의 검색과 발송·초안·아카이브, 구글 캘린더의 일정 확인과 생성·수정, 구글 연락처 조회, 라이브러리 파일 관리, 랜딩페이지·대시보드 등을 만드는 사이트 도구, 이미지 생성·편집 도구, 그리고 나중에·반복적으로·특정 조건이 충족될 때 무언가를 수행하는 예약(automations) 도구가 나열된다. 여기서 반복적으로 강조되는 개념이 MCP(Model Context Protocol) 리소스다. 서버가 파일이나 데이터베이스 스키마, 애플리케이션 정보를 리소스 및 파라미터화된 리소스 템플릿 형태로 공유하며, 문서는 '가능하면 웹 검색보다 이런 리소스를 우선 사용하라'고 지시한다. 별도의 스킬 시스템은 권한(authority)과 패키지 단위로 스킬을 나열·조회하도록 돼 있어, 능력을 모듈처럼 붙였다 뗄 수 있는 구조임을 시사한다.
실무 관점에서 이 목록이 주는 시사점은 분명하다. 에이전트형 도구의 경쟁력은 이제 모델 자체보다 '어떤 도구를, 어떤 안전장치와 함께, 얼마나 잘 조율하느냐'로 옮겨가고 있다. 파일 편집과 셸, 병렬 에이전트, 스크립트 기반 오케스트레이션, 표준화된 컨텍스트 프로토콜, 여기에 메일·캘린더·저장소 연동까지 한 세션 안에 모인다는 것은, 사내 자동화를 설계할 때도 이런 계층 구분을 그대로 참고할 만하다는 뜻이다. 특히 대화형 세션 관리와 결정론적 조율을 도구 층에서 분리해 둔 접근은 재현성과 감사(audit)를 중시하는 조직에 유용한 힌트다.
한계도 함께 읽어야 한다
다만 이 자료의 성격을 오해하면 곤란하다. 이것은 한 세션에서 노출된 도구·스킬의 정의 목록일 뿐, 각 기능의 실제 완성도나 성능, 안정성, 요금, 사용 조건을 담고 있지 않다. Gmail 발송이나 캘린더 변경, 저장소 접근처럼 되돌리기 어렵거나 외부로 나가는 동작이 다수 포함돼 있다는 점은, 이런 에이전트에 권한을 부여할 때 명시적 승인 절차와 최소 권한 원칙이 필수임을 역설적으로 보여준다. 또한 이런 참조 페이지가 외부에 그대로 드러났다는 사실 자체가, 에이전트 시스템의 내부 지시가 의도치 않게 공개될 수 있음을 상기시킨다. 결국 실무자에게 남는 교훈은 화려한 도구 목록이 아니라, 그 도구들이 실제 데이터와 계정에 닿을 때 무엇을 어디까지 허용할지 스스로 통제선을 그어 두는 일이다.