코드 없는 에이전트: 스킬·YAML·파일시스템으로 Python 대체하기

URL: https://www.youtube.com/watch?v=fjF8EKnxKCU 날짜: 2026-09-15 채널: aiDotEngineer

📌 핵심 질문 / 파일이 코드를 대체할 수 있는가

==더 강력해지는 모델에 맞춰 에이전트의 실행 오케스트레이션 코드를 계속 늘리는 대신, 일반 도구와 도메인 지침을 파일로 제공해 모델이 탐색·추론·실행하게 만들 수 있는가==가 핵심 질문이다.

• LLM 에이전트(LLM agent)는 목표를 달성할 때까지 도구를 반복 실행한다.
• 같은 GitHub 풀 리퀘스트(PR) 리뷰 에이전트를 Python 루프, 에이전트 프레임워크, 원격 파일 기반 에이전트의 세 방식으로 만들면서 코드를 단계적으로 삭제한다.
• 모델 역량이 좋아질수록 실행 경로를 마이크로매니징하는 코드를 제거하고, 에이전트의 지침·워크플로·평가(evals)에 집중해야 한다.

Python이 담당하던 도구 라우팅(tool routing), 함수 호출(function calling), 상태 관리, 재시도와 오류 처리는 관리형 에이전트 런타임으로 이동한다. 개발자가 직접 소유할 것은 도메인 규칙과 워크플로를 담은 AGENTS.md, 추가 능력과 맥락을 담은 SKILL.md, 깨끗한 원자적 도구, 결과를 검증하는 평가 체계가 된다.

1. 출발점: 에이전트와 Interactions API

에이전트의 정의와 API의 실행 단위가 이후 세 가지 구현 방식을 관통한다.

1.1. LLM 에이전트의 최소 정의

1. 목표 달성까지 도구를 반복 실행하는 루프

   1. Simon의 정의에 따르면 LLM 에이전트는 목표를 이룰 때까지 도구를 루프 안에서 실행한다.
   2. 사용자 입력과 모델 응답을 한 번 주고받는 챗봇과 달리, 에이전트는 추론·도구 호출·도구 결과를 계속 이어 붙여 목표에 접근한다.

2. 하나의 GitHub PR 리뷰 에이전트를 세 번 구현하는 실험

   1. 첫 번째 버전은 Python으로 루프를 직접 작성한다.
   2. 두 번째 버전은 ADK 같은 에이전트 프레임워크로 보일러플레이트를 제거한다.
   3. 세 번째 버전은 원격 에이전트의 샌드박스에 파일·스킬·일반 도구를 제공해 애플리케이션 코드를 없앤다.
   4. 각 단계의 방향은 “코드는 줄고 파일은 늘어난다”이며, 동일한 PR 리뷰 목표를 유지한 채 구현 부담만 낮춘다.

1.2. Gemini Interactions API의 설계

1. 모델과 에이전트를 함께 호출하는 통합 인터페이스

   1. Interactions API는 Gemini 모델을 직접 실행하거나 새로운 에이전트를 호출하는 통합 Gemini API다.
   2. 관리형 샌드박스(sandbox), 서버 측 상태 관리(server-side state management), 백그라운드 실행(background execution)을 제공해 장시간 실행되는 에이전트에 맞는다.
   3. 도구 호출, 멀티모달 이해(multimodality understanding), 멀티모달 생성(multimodality generation)에 같은 인터페이스를 사용한다.
   4. 개발자가 익숙하게 사용할 수 있는 형태로 모델과 에이전트 구축을 단순화하는 목표를 가진다.

2. 턴(turn) 중심 대화 기록을 단계(step) 타임라인으로 전환

   1. 기존 LLM 애플리케이션은 보통 사용자 입력과 모델 출력이 반복되는 턴 기반(turn-based) 대화 기록을 사용했다.
   2. 일반 채팅에는 사용자 역할(user role)과 모델 역할(model role)의 반복이 충분하지만, 에이전트와 추론 모델에는 더 많은 입력 종류와 중간 상태가 필요하다.
   3. Interactions API는 사용자 입력, 모델 추론(reasoning), 함수 호출(function call), 함수 결과(function result)를 평평한 단계 타임라인(flat steps timeline)에 기록한다.
   4. 환경에서 돌아온 데이터를 사용자 역할로 억지로 포장해 전달할 필요가 없으며, 각 단계의 실제 의미와 타입을 보존한다.

2. 1단계 — Python으로 직접 구현한 에이전트

약 1~1.5년 전의 전형적인 에이전트 개발은 LLM 호출과 도구 실행을 연결하는 Python 루프를 직접 작성하는 일이었다.

2.1. 직접 소유해야 했던 실행 루프

1. 호출·판별·실행을 모두 애플리케이션 코드로 처리

   1. 모델 토큰을 생성하고 native function calling 결과를 받는다.
   2. 모델 출력이 함수 호출인지 일반 텍스트 응답인지 검사한다.
   3. 함수 호출의 타입을 JSON 스키마와 대조해 맞는 도구를 선택한다.
   4. 선택한 도구를 호출하고, 오류가 발생하면 오류를 다시 루프에 넣어 처리한다.
   5. 함수 결과를 모델에 돌려보내 다음 호출을 만들 때까지 이 과정을 반복한다.

2. 반복적으로 작성되는 구성 요소

   1. 실행 루프와 상태를 담은 클래스를 만든다.
   2. Interactions API를 호출하는 run 함수를 구현한다.
   3. 함수 호출 결과를 파싱하고 오류를 추가하며 결과를 축적한다.
   4. 시스템 지침(system instruction)을 별도 파일에 작성한다.
   5. 도구가 수행할 수 있는 동작을 정확히 정의하는 JSON 스키마와 실제 Python 구현을 각각 작성한다.

2.2. GitHub PR 리뷰 데모

1. 구성된 파일과 기능

   1. 시스템 지침은 기본적인 GitHub PR 리뷰어 역할을 부여한다.
   2. 각 도구에는 허용된 동작을 설명하는 JSON 스키마가 필요하다.
   3. 도구 구현은 기본 GitHub API에 요청을 보내 PR 데이터와 코드를 가져오는 Python 함수로 작성된다.
   4. 메인 구현은 사용자가 텍스트를 입력하면 에이전트가 응답하는 단순한 인터페이스다.

2. 도구가 정의한 범위 안에서만 작동하는 실행

   1. hello를 입력하면 “Hey, I’m an agent”에 해당하는 에이전트 응답이 돌아온다.
   2. Gemini Skills 저장소의 풀 리퀘스트를 리뷰하라고 요청하면 함수 호출과 함수 결과가 반복되며 PR 정보, diff, 필요한 코드를 수집한다.
   3. 모델이 PR 리뷰에 필요한 호출을 이어 가더라도 미리 정의한 도구 목록 안에서만 움직인다.
   4. 정의되지 않은 능력을 요청하면 “해당 작업을 할 수 없다”고 답하며, 예를 들어 날씨 API가 없으면 샌프란시스코 날씨를 조회하지 못한다.

3. 직접 구현 방식의 비용

   1. 토큰 생성, native function calling, 루프 실행, 도구 라우팅, JSON 스키마 작성, Python 코드 실행, 상태 관리가 모두 개발자의 책임이다.
   2. 파일과 코드가 많아질수록 누락·파싱 오류·도구 매핑 오류가 생길 지점도 늘어난다.
   3. 에이전트를 실행하기 위해 반복적으로 같은 인프라를 다시 작성해야 하므로 제품 기능보다 런타임 관리에 시간이 쓰인다.

3. 2단계 — ADK 프레임워크로 보일러플레이트 제거

에이전트 프레임워크는 직접 작성하던 루프와 호출 관리 일부를 공통 런타임으로 옮긴다.

3.1. 프레임워크가 대신 처리하는 것

1. ADK의 에이전트 클래스

   1. ADK(Agent Development Kit)에서는 에이전트 클래스가 도구 루프, 함수 호출, 재시도(retry), 오류 처리를 맡는다.
   2. 여러 개발자가 매번 구현하던 보일러플레이트 코드를 프레임워크에 넣어 에이전트 작성 부담을 줄인다.
   3. 개발자는 기본 루프를 다시 만들지 않고 시스템 지침과 도구의 실제 업무 로직에 집중할 수 있다.

2. JSON 스키마 자동 생성

   1. Python 함수마다 별도 JSON 정의를 손으로 작성하지 않는다.
   2. 프레임워크가 함수 시그니처(signature)를 읽어 모델에 제공할 JSON 스키마를 즉시 생성한다.
   3. 두 번째 데모에는 에이전트 실행 파일과 수동 JSON 정의가 사라지고, 시스템 프롬프트와 Python 도구 구현이 남는다.

3.2. 같은 PR 리뷰, 같은 한계

1. 기능 동작의 연속성

   1. 두 번째 에이전트에도 비슷한 입력 인터페이스와 프롬프트를 사용한다.
   2. GitHub PR 데이터, diff, 필요한 코드 조각을 가져오는 함수 호출과 결과 반환이 반복되며 PR 리뷰가 진행된다.
   3. 프레임워크가 턴 전환과 도구 호출을 관리해 첫 번째 버전보다 코드가 줄어든다.

2. 명시적으로 등록한 도구의 경계

   1. 샌프란시스코 날씨를 물어도 날씨 도구를 정의하지 않았으므로 “날씨 API에 접근할 수 없다”는 응답만 돌아온다.
   2. 사용자는 목표만 제시하고 에이전트가 필요한 일을 알아서 하기를 기대하지만, 프레임워크 방식은 여전히 가능한 동작을 미리 지정해야 한다.
   3. 프레임워크는 턴 전환 루프, 라우팅, 실행 매핑, JSON 스키마 생성을 해결하지만 Python 도구 배관(plumbing)은 남긴다.

3.3. 개발자에게 남은 책임

1. Python 도구와 실행 환경

   1. 각 도구를 실제로 수행하는 Python 코드를 계속 작성해야 한다.
   2. 에이전트가 특정 결과를 내도록 규칙과 요구사항을 추가해야 한다.
   3. 모든 도구가 실행될 호스팅 환경을 직접 제공하고 운영해야 한다.

2. 일반 목적 에이전트로 가기 위한 문제

   1. 목표마다 도구를 새로 정의하면 에이전트의 능력이 좁은 고정 목록에 묶인다.
   2. 모델이 이미 가진 일반적 문제 해결 능력을 활용하려면 파일시스템, 셸, 검색 같은 더 원자적이고 범용적인 능력을 직접 노출하는 단계가 필요하다.

4. 3단계 — 원격 에이전트와 격리된 클라우드 샌드박스

Google I/O에서 Gemini API에 Anti-Gravity 원격 에이전트가 공개되면서 도구 루프와 실행 환경을 관리형 서비스로 넘길 수 있게 됐다.

4.1. Anti-Gravity의 정체와 구성

1. 같은 하네스(harness), 다른 에이전트

   1. Anti-Gravity 원격 에이전트는 Anti-Gravity IDE를 구동하는 것과 같은 에이전트 하네스를 사용한다.
   2. 같은 하네스가 같은 시스템 지침과 도구 세트를 의미하지는 않는다.
   3. Anti-Gravity IDE 쪽은 현재 코딩 에이전트이며, Gemini API에서 제공되는 에이전트는 범용 에이전트다.
   4. 따라서 두 에이전트에는 서로 다른 시스템 지침과 약간 다른 도구 구성이 들어갈 수 있다.
   5. Gemini API 쪽 범용 에이전트에는 Google Search 도구가 이미 제공된다.

2. 관리형 실행의 기본 단위

   1. API 요청에 environment 파라미터를 지정하면 호스팅된 격리 클라우드 샌드박스에 에이전트가 접근한다.
   2. 샌드박스 안에서 도구를 실행하고 Bash 명령을 수행하며 파일을 저장할 수 있다.
   3. 개발자는 모든 도구의 서버를 별도로 구축하지 않고 에이전트가 작업할 Linux 환경을 제공한다.

4.2. sources와 안전한 자격 증명

1. 샌드박스에 주입하는 소스

   1. 실행 환경은 소스(sources)로 구성할 수 있다.
   2. 소스는 GitHub 저장소, GCS(Google Cloud Storage) 버킷, 인라인 파일이 될 수 있다.
   3. 시스템 지침 파일과 스킬 파일도 이 환경에 함께 제공되어 모델이 작업에 필요한 맥락을 읽게 된다.

2. 네트워크 프록시가 자격 증명을 숨기는 방식

   1. 에이전트가 샌드박스 안에서 외부 요청을 보낼 때 네트워크 프록시가 요청을 가로채고 필요한 자격 증명을 주입한다.
   2. 에이전트는 실제 토큰을 보지 못하며, “GitHub API를 호출할 수 있다”는 사실만 사용한다.
   3. 개발자가 정의한 올바른 토큰은 요청 시점에 프록시가 제공하므로 비밀이 에이전트 컨텍스트에 노출되지 않는다.

3. 도메인 접근 제한

   1. 접근을 허용할 도메인을 제한할 수 있다.
   2. 네트워크 접근을 완전히 제한하려면 허용 도메인 목록을 비워 둔다.
   3. 기본값은 모든 웹 접근 허용이며, 매번 먼저 목적지를 지정해야 하는 번거로움을 줄이기 위해 단순한 기본값을 택했다.
   4. 자격 증명은 허용된 GitHub URL 등에만 연결하고, 일반 웹 접근에는 자격 증명을 주지 않는다.

4.3. Agents API와 사용자 정의 에이전트

1. 재사용 가능한 에이전트 정의

   1. API 호출을 한 번 쓰고 버리는 대신 Agents API에서 사용자 정의 ID를 지정할 수 있다.
   2. 동일한 시스템 지침, 기본 에이전트, 기본 환경을 저장해 사용자 정의 에이전트를 만들 수 있다.
   3. 만들어진 에이전트는 Gemini 모델이나 Anti-Gravity 에이전트를 호출하는 방식과 같은 방식으로 ID를 넣어 호출한다.

2. 기존 코드와 설정의 재사용

   1. 동일한 호출 코드를 유지하면서 사용자 정의 도구, 자격 증명, 실행 환경을 가진 에이전트로 교체할 수 있다.
   2. 애플리케이션은 에이전트 ID만 사용하고, 실제 구성은 저장된 시스템 지침과 환경이 소유한다.
   3. 반복적으로 필요한 에이전트를 팀과 제품 전반에서 재사용하기 위한 구성 단위가 된다.

5. 파일·스킬 중심 에이전트로 Python 삭제

세 번째 PR 리뷰 구현에서는 애플리케이션의 소스 디렉터리가 사라지고, 모델이 읽고 실행할 파일 구조가 핵심 인터페이스가 된다.

5.1. AGENTS.md와 일반 도구

1. 코드 대신 지침 파일

   1. 더 이상 source 디렉터리가 없다.
   2. agents 폴더와 AGENTS.md 파일이 시스템 지침의 중심이 된다.
   3. 기본 PR 리뷰 지침은 이전과 유사하지만, “GitHub PR 데이터를 읽는 전용 함수”를 호출하라는 규칙 대신 GitHub CLI를 사용할 수 있다고 알려 준다.
   4. 에이전트는 Bash 도구와 파일시스템을 함께 사용해 필요하다고 판단한 작업을 수행한다.

2. 원자적 도구와 모델의 선택

   1. GitHub PR 읽기·diff 수집·파일 검사 각각에 전용 Python 도구를 만들지 않는다.
   2. GitHub CLI, Bash, 파일시스템 같은 일반 목적 원자적 도구를 제공한다.
   3. 모델은 기존 지식과 현재 맥락을 바탕으로 어떤 CLI 명령과 파일 조작을 조합할지 결정한다.
   4. 하나의 고정 실행 경로를 코드로 강제하지 않고 목표 달성에 필요한 경로를 모델에게 맡긴다.

5.2. 첫 실행에서 도구를 준비하는 Bash 스크립트

1. 환경의 자기 점검

   1. GitHub CLI가 샌드박스에 설치되어 있는지 먼저 검사한다.
   2. CLI가 없으면 첫 번째 턴에 다운로드하고 설치하는 아주 단순한 Bash 스크립트를 실행한다.
   3. 설치 과정까지 파일로 제공되므로 애플리케이션 코드에 GitHub CLI 설치 로직을 통합할 필요가 없다.

2. PR 리뷰 작업의 실제 흐름

   1. 스트리밍(stream) 버전을 사용해 API가 끝날 때까지 기다리지 않고 함수 호출과 결과를 즉시 받는다.
   2. 에이전트는 먼저 샌드박스를 탐색해 GitHub CLI가 있는지 확인한다.
   3. CLI를 찾지 못하면 설치한 뒤 기존 지식으로 사용법을 파악하고 PR 리뷰를 진행한다.
   4. 전용 함수 호출 대신 GitHub CLI, Bash, 파일시스템으로 PR과 코드를 살펴본다.

5.3. 범용 에이전트가 된 결과

1. 날씨 질문을 스스로 해결

   1. 같은 에이전트에 샌프란시스코 날씨를 묻는다.
   2. 범용 에이전트는 Google Search를 선택해 7월 2일의 날씨를 조회한다.
   3. 결과는 약 섭씨 20도이며, 날씨 전용 API를 미리 등록하지 않아도 작업이 완료된다.

2. 도구 목록에서 도구 원시 능력으로

   1. 도구마다 업무를 하드코딩한 에이전트는 등록된 함수가 없으면 “할 수 없다”고 답한다.
   2. 파일 기반 에이전트는 Bash·파일시스템·검색이라는 작은 범용 능력과 목표를 결합한다.
   3. 모델은 어떤 도구를 어떤 순서로 쓸지 탐색하고 추론해 문제를 해결한다.
   4. 필요한 모든 API를 개발자가 사전에 열거하는 방식에서, 모델에게 충분히 일반적인 환경을 제공하는 방식으로 이동한다.

5.4. 단일 API 호출과 서버 측 실행

1. 클라이언트가 제공하는 최소 입력

   1. 요청에는 사용자 입력, 환경, 이전 상호작용 ID(previous interaction ID)가 들어간다.
   2. 이전 상호작용 ID를 유지하면 여러 턴의 대화를 이어 갈 수 있다.
   3. GitHub URL 두 종류를 위해 각각 별도 자격 증명을 만든다. 하나는 Git 명령에, 다른 하나는 HTTP 명령에 사용한다.
   4. GitHub URL 외 모든 웹 도메인을 허용하는 설정도 가능하지만, 그 일반 웹 접근에는 자격 증명이 없다.

2. 백엔드가 대신 수행하는 루프

   1. 단일 API 호출 뒤 백엔드가 클라우드 샌드박스를 시작한다.
   2. 샌드박스에서 AGENTS.md와 환경이 제공한 스킬을 로드해 모델에 전달한다.
   3. API와 샌드박스 사이에서 모델이 함수 호출, 함수 결과 반환, 다음 함수 호출을 반복한다.
   4. 개발자는 매번 루프를 실행하거나 도구를 라우팅하거나 함수 결과를 다시 조립하지 않는다.

3. 상태·문맥·실행 환경의 관리형 처리

   1. 서버 측 대화 및 세션 상태를 제공하므로 클라이언트는 새로운 입력만 보낸다.
   2. 장시간 대화에서 문맥 창이 커지면 에이전트가 자동으로 문맥을 압축(compaction)하고 작업을 이어 간다.
   3. 클라이언트가 압축 시점이나 상태 저장을 직접 관리할 필요가 없다.
   4. 격리된 원격 Linux 샌드박스가 코드 실행과 파일 저장을 담당한다.

6. 파일 기반 확장과 업계의 신호

파일 기반 구성이 단순한 데모를 넘어 새로운 기능 추가와 하네스 설계의 방향을 바꾼다.

6.1. 보안 스캔 기능 추가

1. 기존 방식의 확장 비용

   1. PR에 보안 스캔을 추가하려면 Python 함수를 새로 작성해야 한다.
   2. 어떤 CLI 도구를 쓸지 결정하고 실행 환경에 설치해야 한다.
   3. 새 함수의 JSON 스키마를 정의하고 도구 목록에 등록한 뒤 실행 흐름에 연결해야 한다.
   4. 기능 하나가 Python 코드, 스키마, 도구 라우팅, 실행 환경 변경으로 번진다.

2. 파일 기반 방식의 확장

   1. SKILL.md에 보안 스캔 절차와 사용할 CLI 도구에 대한 추가 정보를 적는다.
   2. CLI 도구를 환경에 제공하거나 설치 스크립트를 둔다.
   3. 코드 수정 없이 파일을 더 제공해 에이전트의 능력을 확장한다.
   4. 에이전트는 새 스킬과 현재 목표를 보고 보안 스캔을 실행할지 스스로 결정한다.

6.2. 실제 시스템에서 관찰된 코드 삭제

1. Cursor의 Git worktree 오케스트레이션

   1. AI Engineer in Europe에서 Cursor는 약 12,000줄의 TypeScript 코드를 약 200줄의 에이전트 파일로 바꾼 사례를 공유했다.
   2. Git worktree를 처리하던 하드코딩 오케스트레이션을 스킬과 Markdown 파일로 대체했다.
   3. 파일 기반 지침이 모델의 작업 계획과 도구 조합을 맡으면서 명시적 제어 코드가 크게 줄었다.

2. Manus의 하네스 리팩터링

   1. Manus는 지난해 6개월 동안 에이전트 하네스를 다섯 번 리팩터링했다.
   2. 모델과 실제 작업의 결합 방식이 빠르게 바뀌면서 고정된 하네스가 오래 유지되기 어려웠다.
   3. 반복되는 리팩터링은 모델 역량 변화에 맞춰 오케스트레이션을 계속 줄여야 한다는 신호가 된다.

3. Open Deep Research와 Vercel의 변화

   1. LangChain은 Open Deep Research를 1년에 세 번 다시 설계했다.
   2. Vercel은 도구의 80%를 제거해 단계 수를 줄이고 응답을 빠르게 하며 정확도를 높였다.
   3. 더 많은 도구와 더 복잡한 제어가 항상 더 나은 에이전트로 이어지는 것은 아니다.

4. 모델 개선과 하네스 복잡도의 관계

   1. 모델 역량이 향상될 때마다 하네스가 더 복잡해진다면 실행을 과도하게 설계(overengineering)하고 있을 가능성이 높다.
   2. 모델 개선과 새 기능 추가가 코드 증가와 복잡도 증가를 동시에 일으킨다면 에이전트 하네스 설계를 다시 생각해야 한다.
   3. 좋은 하네스는 모델의 자율적 탐색과 일반 도구의 조합을 허용하며, 모델이 좋아질수록 제거할 코드가 늘어나는 구조를 갖는다.

7. 에이전트는 파일이 된다

파일은 에이전트의 고정 설정을 넘어 능력, 기억, 장기 맥락을 외부화하는 작업 공간이 된다.

7.1. Markdown 파일로 능력 확장

1. 스킬 파일을 통한 능력 제공

   1. 에이전트의 능력을 확장할 때 Python 오케스트레이션 코드를 추가하지 않고 Markdown 파일을 추가한다.
   2. AGENTS.md는 지침·규칙·행동을, SKILL.md는 사용 가능한 능력과 맥락을 담는다.
   3. 파일이 늘어날수록 에이전트가 읽고 활용할 수 있는 작업 절차와 환경 지식이 늘어난다.

2. 모델이 파일을 직접 생성하는 순환

   1. 에이전트는 작업 중 기억해야 할 내용, 규칙, 사용자의 선호를 파일에 기록할 수 있다.
   2. 다음 세션은 그 파일을 다시 읽어 이전에 저장한 내용을 재사용한다.
   3. 에이전트가 스스로 만든 파일이 장기 기억과 재사용 가능한 작업 맥락이 된다.

7.2. 긴 세션의 맥락 외부화

1. 핸드오프 파일

   1. 긴 세션에서 다른 기능을 추가로 작업하고 싶다는 사실을 발견하면 그 정보를 파일로 적는다.
   2. 현재 작업을 중단해도 나중에 해당 파일을 읽으라고 지시해 새 작업을 이어 갈 수 있다.
   3. 파일은 세션의 문맥 창에 모든 내용을 계속 보존하지 않고도 작업 의도와 다음 단계를 전달하는 핸드오프가 된다.

2. 상태 관리의 재배치

   1. 단기 실행 상태는 서버 측 상호작용 ID와 자동 문맥 압축이 관리한다.
   2. 장기 지식과 도메인 규칙은 Markdown 파일이 관리한다.
   3. 반복적인 오케스트레이션 코드는 줄어들고, 사람이 검토 가능한 텍스트가 에이전트 행동의 주요 조정 계층이 된다.

8. 핵심 권고와 월요일부터의 실행 항목

8.1. 모델과 싸우지 않는 설계

1. 실행 경로 마이크로매니징 중단

   1. 개발자가 모든 도구 호출 순서와 분기 경로를 미리 강제하지 않는다.
   2. 일반적인 도구를 에이전트에 제공하고 모델이 올바른 해결책을 탐색하도록 맡긴다.
   3. 모델이 상황을 추론하고 필요한 도구를 발견하며 목표에 도달하도록 실행 공간을 열어 둔다.

2. 개발자가 소유할 것에 집중

   1. 자신의 도메인 지침과 업무 규칙을 명확히 작성한다.
   2. 제품이 수행해야 할 워크플로를 정의한다.
   3. 깨끗하고 원자적인 도구를 제공한다.
   4. 평가(evals)를 설계해 결과가 실제 요구사항을 충족하는지 검증한다.

8.2. “삭제를 목표로 빌드하기”

1. 모델 개선의 이익을 코드 삭제로 연결

   1. 더 나은 모델이 나올 때마다 기존 실행 코드가 정말 필요한지 다시 확인한다.
   2. 직접 관리하던 루프, 라우팅, 스키마, 상태 관리가 관리형 에이전트와 파일로 이동할 수 있는지 점검한다.
   3. 에이전트를 개선할수록 코드가 늘어나는 대신 줄어드는 방향을 목표로 삼는다.

2. 월요일에 바로 할 일

   1. QR 코드를 스캔해 AI Studio로 이동하고 Anti-Gravity 하네스를 즉시 시험한다.
   2. 자체 커스텀 샌드박스를 시작해 프롬프트를 입력하고 파일 기반 에이전트의 동작을 확인한다.
   3. API 키가 없다면 생성한다. API 무료 티어(free tier)가 준비 중이므로 더 빠른 탐색이 가능해질 예정이다.
   4. AGENTS.md와 SKILL.md 파일을 작성해 도메인 규칙과 기능을 제공하는 실험을 시작한다.

주요 발언 모음

“LLM 에이전트는 목표를 달성할 때까지 루프 안에서 도구를 실행한다.”

“각 새 버전마다 코드가 줄고 파일이 늘어난다.”

“우리는 실행 경로를 마이크로매니징하는 일을 멈추고, 일반 도구를 에이전트에 제공해야 한다.”

“당신의 것을 소유하라. 도메인 지침, 워크플로, 특히 평가에 집중하라.”

“삭제를 목표로 빌드하라.”

“모델이 좋아질수록 더 많은 코드를 제거할 수 있다.”

핵심 데이터 & 수치

• 약 1~1.5년 전: 에이전트 구축이 Python 루프, JSON 스키마, 함수 구현, 도구 라우팅, 오류 처리, 상태 관리의 직접 작성에 가까웠다.
• 세 가지 구현: 동일한 GitHub PR 리뷰 에이전트를 직접 Python, ADK 프레임워크, 원격 파일 기반 에이전트로 구현했다.
• 약 12,000줄 → 약 200줄: Cursor가 Git worktree 오케스트레이션 TypeScript를 에이전트 파일로 대체한 사례다.
• 5회 / 6개월: Manus가 지난해 6개월 동안 하네스를 리팩터링한 횟수다.
• 연 3회: LangChain이 Open Deep Research를 다시 설계한 빈도다.
• 80% 제거: Vercel이 도구를 줄여 단계 수·응답 시간·정확도를 개선한 비율이다.
• 약 20°C: 7월 2일 Google Search로 조회한 샌프란시스코 날씨 결과다.
• 두 종류의 GitHub URL: Git 명령용 URL과 HTTP 명령용 URL에 별도 자격 증명을 사용한다.
• 무료 티어 준비 중: Gemini API에서 탐색을 쉽게 하기 위한 무료 사용 계층이 작업 중이다.

결론 및 시사점

1. 에이전트 런타임의 추상화 수준을 높인다: Python 루프와 함수 스키마를 직접 관리하던 구조에서 ADK를 거쳐, 서버 측 Anti-Gravity 에이전트와 격리 샌드박스로 이동한다.
2. 일반 도구를 제공한다: GitHub PR마다 전용 API 함수를 만드는 대신 Bash, CLI, 파일시스템, 검색처럼 조합 가능한 원자적 능력을 노출한다.
3. 행동을 사람이 읽는 파일로 표현한다: AGENTS.md에 규칙과 워크플로를, SKILL.md에 추가 능력과 맥락을 적어 코드 없이 확장한다.
4. 보안을 환경 계층에서 해결한다: 네트워크 프록시가 샌드박스 밖에서 자격 증명을 주입하고, 도메인 허용 목록으로 네트워크 범위를 제어한다.
5. 제품의 고유 가치를 소유한다: 공통 루프·상태·인프라를 반복 구현하는 대신 도메인 지침, 워크플로, 평가, 결과 검증에 투자한다.
6. 모델 성능 향상을 삭제로 반영한다: 모델이 좋아질수록 하네스가 복잡해지는지 점검하고, 불필요한 도구·단계·오케스트레이션을 제거한다.
7. 파일을 기억과 협업의 단위로 활용한다: 에이전트가 선호·규칙·장기 작업 맥락을 파일에 저장하고 후속 세션이나 다른 작업에 핸드오프하게 한다.
8. 즉시 실험한다: AI Studio에서 Anti-Gravity 하네스와 커스텀 샌드박스를 시험하고, 작은 AGENTS.md·SKILL.md부터 작성해 파일 기반 에이전트의 자율성을 검증한다.

핵심 요약 (20줄)

1. LLM 에이전트는 목표를 달성할 때까지 도구를 반복 실행하는 루프다.
2. 동일한 GitHub PR 리뷰 에이전트를 세 가지 구현으로 만들며 코드 삭제의 효과를 비교한다.
3. Interactions API는 Gemini 모델과 에이전트를 호출하는 통합 인터페이스다.
4. API는 도구 호출, 멀티모달 이해, 멀티모달 생성을 하나의 방식으로 다룬다.
5. 사용자·모델 턴 대신 입력·추론·함수 호출·함수 결과를 단계로 기록한다.
6. 직접 Python으로 만들면 루프·라우팅·JSON 스키마·상태를 모두 소유해야 한다.
7. Python PR 리뷰 에이전트는 정의된 GitHub 함수와 API 호출에만 의존한다.
8. 등록하지 않은 날씨 API 같은 능력은 직접 구현 에이전트가 수행할 수 없다.
9. ADK는 도구 루프·함수 호출·재시도·오류 처리와 스키마 생성을 추상화한다.
10. ADK를 사용해도 실제 도구 Python 코드와 호스팅 환경은 여전히 필요하다.
11. Anti-Gravity 원격 에이전트는 격리된 클라우드 샌드박스에서 Bash와 파일을 사용한다.
12. GitHub·GCS·인라인 파일을 sources로 샌드박스에 주입할 수 있다.
13. 네트워크 프록시는 에이전트에게 토큰을 숨긴 채 외부 API 자격 증명을 주입한다.
14. 사용자 정의 에이전트는 Agents API의 ID로 시스템 지침과 환경을 재사용한다.
15. 세 번째 구현은 소스 코드 대신 AGENTS.md, Bash, GitHub CLI, 파일시스템을 사용한다.
16. 에이전트는 첫 턴에 GitHub CLI를 탐색하고 없으면 설치한 뒤 PR을 리뷰한다.
17. 범용 에이전트는 Google Search로 약 20°C의 샌프란시스코 날씨도 조회한다.
18. 보안 스캔은 Python 함수 추가 대신 SKILL.md와 CLI 제공만으로 확장된다.
19. Cursor·Manus·LangChain·Vercel 사례는 모델 개선에 따른 오케스트레이션 삭제를 보여준다.
20. 개발자는 일반 도구·도메인 지침·워크플로·평가를 소유하고 더 나은 모델로 코드를 삭제해야 한다.