에이전트가 런타임에 스스로 도구를 만들고 고치는 방법

URL: https://www.youtube.com/watch?v=33Oct2hqGnk
날짜: 2026-10-05 (수집일)
채널: aiDotEngineer(AI Engineer)

메타데이터

• 원문 제목: Agents That Write Their Own Tools at Runtime — Sandhya Subramani, AWS
• video_id: 33Oct2hqGnk
• 원본 발행일(drop_date): 2026-10-04 (yt-dlp upload_date=20261004)
• 발표자: Sandhya Subramani, Senior Developer Advocate, Generative AI, AWS
• 사용 프레임워크: Strands Agents open-source agentic harness
• 영상 길이: 20분 40초
• 핵심 키워드: meta-tooling, runtime code generation, self-healing agent, multi-agent, evals, guardrails

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트가 처음부터 모든 도구를 갖추지 않아도, 런타임에 필요한 도구와 하위 에이전트를 만들고 로드해 스스로 능력을 확장하며 오류까지 고칠 수 있게 하려면 어떻게 해야 하는가?==

• editor, shell, load_tool 세 도구와 도구 작성 규칙을 담은 system prompt만으로 런타임 도구 생성이 가능하다.
• Strands Agents는 모델 교체, MCP(Model Context Protocol), 여러 model provider를 수용하는 harness이며, 생성된 도구·에이전트를 동적으로 불러올 수 있다.
• 자율적으로 파일을 쓰고 수정·삭제하는 힘이 커질수록 목표 달성, 도구 선택, 파라미터, 다중 에이전트 흐름을 평가하고 실행 환경·권한·관측 가능성에 guardrail을 둬야 한다.

고정된 도구 목록에 없는 요청이 들어오면 기존 시스템은 배포를 중단하고 엔지니어가 코드를 고쳐 다시 시작할 수밖에 없다. 반면 meta-tooling agent는 자신에게 없는 능력을 판별하고 도구를 작성한 뒤 같은 실행을 계속하며, 더 나아가 하위 에이전트와 수정된 소스 코드까지 만들 수 있다. 이 가능성은 단순한 코드 자동완성보다 운영 중인 시스템의 적응·복구·확장을 목표로 한다.

1. “도구를 쓴다”에서 “도구를 만든다”로

1.1. 기존 코딩 에이전트와 런타임 자기수정의 차이

1. 도구 생성 자체는 새롭지 않다는 문제 제기

   1. 일반적인 코딩 도구의 능력: Claude Code로 지칭된 “claw code”, Cursor, 일반 code editor도 파일을 쓰고 새 도구를 만들 수 있다.
   2. 핵심 차이: 중요한 질문은 도구 파일을 만들 수 있느냐가 아니라, 이미 production에서 실행 중인 에이전트가 중단·재시작 없이 runtime에 코드를 고칠 수 있느냐이다.

2. 운영 중 오류를 고치는 에이전트

   1. 기존 순서: production 프로그램에서 무언가 실패하면 시스템을 내리고, 사람이 코드를 수정하고, 다시 시작한 뒤 editor와 함께 배포를 복구해야 한다.
   2. 자기복구 순서: 에이전트가 오류를 감지하고 “무언가 작동하지 않는다, 스스로 고쳐야 한다”고 판단한 뒤 필요한 도구와 에이전트를 직접 작성하고 계속 실행한다.
   3. 발표의 초점: 이 런타임 적응성이 meta-tooling과 self-healing code를 실무에 적용하는 이유다.

1.2. zero-tool agent 데모의 출발점

1. 실행 파일과 능력의 분리

   1. agents.py: 데모 에이전트는 멋진 system prompt와 세 가지 기본 도구를 호출하는 코드만 가진 단순한 파일이다.
   2. 빈 tools 디렉터리: 도구 패키지 안에는 작성된 도구 파일이 하나도 없으므로, 시작 시점의 agent는 실질적인 업무 capability가 없다.
   3. 일반적인 예상: LLM이 뒤에서 답을 생성할 뿐이라면 실제 계산 대신 hallucination을 할 것처럼 보인다.

2. 데모 실행 조건

   1. runtime 확인: 먼저 프로세스를 실행해 에이전트가 현재 실행 중임을 확인한다.
   2. 사용자 관점: 사용자는 “복잡한 수학 방정식을 계산해 달라”고만 말하며, 어떤 도구를 만들라고 지시하지 않는다.
   3. 에이전트의 판단: 현재 가진 도구로 요청을 처리할 수 없음을 확인하고, 필요한 math calculator를 만들기로 한다.

1.3. 런타임에 계산기와 문자 수 세기 도구 만들기

1. math calculator 생성과 즉시 사용

   1. 도구 작성: 에이전트는 실행 중에 math calculator tool을 새로 만든다.
   2. 무중단 로드: 프로그램을 다시 실행하지 않고 방금 만든 도구를 곧바로 호출한다.
   3. 기능 표면: 생성된 파일에는 최소·최대값(min, max) 같은 연산 기능과 도구가 할 수 있는 작업이 정의된다.
   4. 검증 요청: 임의의 큰 수의 제곱을 계산해 달라는 요청이 들어오자, 에이전트는 자신이 만든 계산기 도구를 사용해 답을 반환한다.

2. character counter 생성

   1. 새 능력 요청: 사용자가 갑자기 어떤 문자열의 문자 수를 세어 달라고 요청한다.
   2. 능력 점검: 에이전트는 현재 접근 가능한 도구에 문자 수 세기 기능이 있는지 먼저 확인한다.
   3. 도구 생성: 기능이 없다는 사실을 파악하자 character counter tool을 새로 작성한다.
   4. 빠른 생성: 사용자가 말을 끝내기도 전에 도구 파일이 만들어질 만큼 생성이 빠르다.

3. 명시적 명령 없이 도구 사용

   1. 첫 문자열: 테스트하기 좋은 단어 대신 임의의 문자열을 넣었고, 에이전트는 character counter를 호출해 28 letters라고 답한다.
   2. 간단한 검증: 이어서 세 글자만 입력해 에이전트가 실제로 문자 수 세기를 수행하는지 확인한다.
   3. 의도 추론: 사용자는 “세어라”라고 다시 설명하지 않았지만, 세 글자를 입력하는 맥락만으로 만들어 둔 도구를 써야 한다는 목적을 파악한다.
   4. 실무 의미: 이 데모는 모델이 답을 지어내는 대신 부족한 capability를 도구로 보충하고, 같은 세션에서 그 결과를 활용하는 과정을 보여준다.

2. Strands Agents의 meta-tooling 구조

2.1. 오픈소스 agentic harness와 교체 가능한 모델

1. Strands Agents의 역할

   1. 정체: AWS가 만들고 관리하는 open-source agentic harness이며, LLM을 실행하는 기반 계층이다.
   2. 개발자 대상: 청중 대부분이 개발자라는 확인 뒤 코드 중심으로 구조를 설명한다.
   3. 커뮤니티 방식: AWS가 유지보수하고, 사전 구축된 도구와 커뮤니티가 작성한 도구를 함께 제공한다.

2. 모델 교체의 이점

   1. BYO model: 사용자는 자신의 LLM을 가져와 Strands 구조에 연결할 수 있다.
   2. 아키텍처 보존: 새로운 state-of-the-art LLM이 출시돼도 system prompt, 전체 구조, 애플리케이션 아키텍처를 다시 쓸 필요가 없다.
   3. 실험 가능성: 모델만 교체해 성능을 비교하고 실험할 수 있다.
   4. 통합 범위: MCP를 지원하고 여러 model provider를 제공한다.

3. 최소 진입 코드

   1. 짧은 시작점: agent를 import하고 shell을 import하는 등 대략 다섯 줄의 코드로 기본 구조를 시작할 수 있다.
   2. shell의 의미: 에이전트가 어느 디렉터리에서 실행되는지, 무엇을 실행하는지, 코드베이스가 어디에 있는지 알 수 있도록 환경 접근을 제공한다.
   3. 자기상태 파악: “무엇을 할 수 있나?”라고 질문하면 harness와 도구 환경을 바탕으로 자신의 실행 조건을 파악한다.

2.2. 세 도구와 system prompt

1. 필수 구성요소

   1. editor: 새 도구와 에이전트 파일을 실제로 작성하고 수정한다.
   2. shell: 실행 디렉터리와 코드베이스를 확인하고 필요한 명령을 실행한다.
   3. load_tool: 디렉터리에 생성된 도구를 runtime에 동적으로 로드한다.
   4. system prompt: “좋은 도구”의 모양, 저장 위치, 작성 규칙을 에이전트에게 알려주는 설계 문서다.

2. 동적 로딩의 변화

   1. 초기 방식: 도구 디렉터리에서 로드하도록 load_tools_from_directory=True를 설정하면 런타임 생성 파일을 찾아 실행할 수 있었다.
   2. 도구로 승격: 이 동작을 별도 기능이 아니라 에이전트가 호출할 수 있는 load_tool 자체로 만들었다.
   3. 결과: “스스로 새 도구 다섯 개를 만들고 사용하라”고 요청하면, 작성→저장→동적 로드→사용의 흐름을 에이전트가 수행할 수 있다.

3. 도구 템플릿과 안전한 생성 규칙

   1. 도구 식별: @tool decorator function을 사용해 무엇이 도구인지 표시한다.
   2. 스펙 명시: system prompt에 도구가 어떤 모양이어야 하는지와 어디에 저장할지를 정의한다.
   3. 존재 여부 확인: 같은 이름이나 기능의 파일이 이미 있는지 항상 확인하고, 없을 때만 새 도구를 작성한다.
   4. 역할 분담: editor는 쓰기, shell은 환경 확인·명령 실행, load_tool은 디렉터리에서 새 파일을 가져오는 역할을 맡는다.

2.3. meta-tooling agent의 코드 흐름

1. 프롬프트가 부여하는 정체성

   1. 역할 선언: “너는 runtime에 자체 도구와 custom tool을 만드는 meta-tooling agent다”라고 선언한다.
   2. 작성 계약: 도구 template과 tool specification을 넣어 생성물의 형식을 제한한다.
   3. 운영 규칙: 무엇을 수행해야 하는지와 어느 경로에 써야 하는지를 규정한다.

2. 짧은 orchestration

   1. 구성: system_prompt에 위 규칙을 넣고 세 도구를 연결하면 된다.
   2. 대화 지속: 데모 코드는 사용자가 계속 대화할 수 있도록 chat loop를 실행하는 코드다.
   3. 능력 확장: 사용자가 요청하면 agent는 별도 사전 정의 없이 다섯 개의 임의 도구 같은 새 capability를 생성하고 그 결과를 계속 사용한다.

3. 해결하는 배포 문제

   1. 고정 도메인 예시: 국내선 항공권만 예약하도록 만든 앱에 사용자가 인도에서 홍콩으로 가는 항공권을 요청한다고 가정한다.
   2. 기존 실패: 명시적으로 프로그래밍되거나 학습되지 않은 국제선 capability가 없으면 agent는 포기하거나 오류를 반환한다.
   3. 운영 비용: 실패를 engineering team에 넘기면 수정과 재배포까지 2주 turnaround가 걸릴 수 있다.
   4. meta-tooling의 대안: 실행 중 필요한 연결·변환·조회 도구를 만들고, 요청을 계속 처리하는 적응 계층을 둘 수 있다.

3. 에이전트가 에이전트를 만드는 다중 에이전트 패턴

3.1. 자체 하위 에이전트 생성

1. 능력의 확장

   1. 가능 여부: 도구를 만드는 agent는 자신의 도구만이 아니라 다른 agent도 만들 수 있다.
   2. 구현 방식: 도구 생성 데모와 같은 editor, shell, load_tool 구성과 agent template을 사용한다.
   3. 시연 시점: 발표 후반 데모로 배치해 도구 생성의 다음 단계로 보여준다.

2. agent template

   1. 분해 규칙: 복잡한 요청을 2~4개의 sub-agent로 나누라는 단순한 규칙을 둔다.
   2. 범위 제한: swarm 같은 고급 오케스트레이션은 넣지 않고, 기본 동작을 확인하는 간단한 데모로 유지한다.
   3. 생성 계약: agent 파일의 형태와 따라야 할 규칙을 tool specification으로 system prompt에 넣는다.

3.2. swarm·graph·handoff·workflow

1. swarm

   1. 병렬 협업: 여러 sub-agent가 서로 협력하면서 작업을 병렬로 나눈다.
   2. 역할 분담: 각 sub-agent가 전체 과제의 다른 부분을 맡아 결합된 결과를 만든다.

2. graph

   1. 순차 연결: 한 sub-agent의 결과를 다음 sub-agent에 전달한다.
   2. 의존성 표현: 결과가 노드 사이를 흐르는 구조로 각 단계의 dependency를 드러낸다.

3. handoff와 workflow

   1. handoff: 한 agent가 처리하던 작업을 다른 agent에 넘긴다.
   2. workflow 조합: 병렬 sub-agent 호출, graph의 node 연결, handoff를 한 workflow 안에서 섞을 수 있다.
   3. 자동 구성: 개발자가 직접 모두 배선할 수도 있지만, meta-agent가 이런 패턴 자체를 생성하게 할 수도 있다.

3.3. 하와이 여행 계획 데모

1. 사용자 요청과 자동 분해

   1. 입력: 사용자는 “하와이로 비행할 예정이니 itinerary를 계획해 달라”고만 말한다.
   2. 숨은 요구사항: 사용자는 “자체 agent를 만들어라”거나 특정 규칙을 만들라고 지시하지 않는다.
   3. 자동 생성: 상위 agent는 flight agent, activities agent, itinerary agent라는 세 개의 focus sub-agent를 만든다.
   4. 파일 생성: editor 도구를 세 번 호출해 각 agent 파일을 하나씩 작성한다.

2. 생성된 agent의 실제 호출

   1. flight agent: 항공 이동 관련 정보를 담당한다.
   2. activities agent: 여행지 활동을 담당하며, 실행 중 주요 공항과 좋은 해변을 제시한다.
   3. itinerary agent: 하위 결과를 여행 일정으로 결합한다.
   4. 호출 확인: 실행 로그에서 상위 agent가 activities agent를 실제로 부르는 과정이 확인된다.

3. 실시간 정보의 한계와 확장

   1. 현재 제약: 데모에는 실제 world API에 접근하는 도구가 없으므로 실시간 정보를 읽을 수 없다.
   2. 확장 시나리오: 날씨를 물으면 agent가 최신 날씨를 가져오는 tool을 작성하고, 위치별 추천까지 생성하도록 확장할 수 있다.
   3. 설계 교훈: API 접근 도구를 주면 self-generated agent가 정적인 지식뿐 아니라 외부 최신 데이터도 다루게 된다.

4. self-healing과 production 신뢰성

4.1. 스스로 오류를 수정하는 흐름

1. 오류를 일부러 유도하는 장시간 세션

   1. 공격적 테스트: 더 긴 발표라면 청중에게 일부러 무리한 요청을 시켜 시스템을 깨 보게 한다.
   2. 관찰되는 현상: 많은 오류가 발생하고 agent가 계속 대화를 이어 가면서 토큰을 과도하게 소비할 수 있다.
   3. 구성 조정: 데모에서는 max token 값을 설정해야 할 필요가 드러난다.

2. self-healing 동작

   1. 오류 인식: agent가 실행 중 오류를 내고 있다는 사실을 스스로 감지한다.
   2. 자동 수정: “스스로 고치겠다”고 판단한 뒤 현재 사용 중인 동일한 tool 또는 agent를 수정한다.
   3. 요청 변경: 하와이 대신 다른 장소를 계획하라고 하면 기존 agent를 업데이트해 새 요구에 맞춘다.

4.2. 자율성의 대가

1. 기대하는 능력

   1. 초기 범위 초과: 처음부터 가르치지 않은 capability도 필요한 순간에 만들 수 있다.
   2. 실행 중 복구: 깨진 기능을 on the fly로 고치고, 고정 배포 주기를 기다리지 않는다.
   3. 확장되는 시스템: 도구 생성에서 agent 생성, source code 갱신으로 자율성이 단계적으로 커진다.

2. 신뢰 문제

   1. 무제한 쓰기 권한의 위험: 자체 도구와 agent를 만들 수 있다는 것은 파일을 수정하거나 삭제할 수도 있다는 뜻이다.
   2. 보호해야 할 자산: 애써 구축한 데이터와 코드를 지우거나 잘못된 위치에 쓰게 해서는 안 된다.
   3. 핵심 원칙: “큰 힘에는 더 큰 책임이 따른다”는 말처럼, 자율성은 eval과 guardrail을 전제로 허용해야 한다.

5. evals: 자기수정 에이전트를 믿기 위한 여덟 가지 점검

발표자는 Strands에 총 여덟 가지 eval 관점이 있다고 설명한다. 한 번의 최종 답만 보지 말고 session·trace·tool·inter-agent 전 구간을 평가해야 한다.

5.1. session과 trace의 결과 품질

1. end-goal achievement

   1. 업무 완료 여부: “항공권을 예약해 달라”고 했을 때 실제로 항공권 예약이라는 최종 목표를 달성했는지 평가한다.
   2. 결과 중심성: 그럴듯한 대화가 아니라 사용자가 요구한 작업의 끝까지 도달했는지를 본다.

2. 답의 유용성과 사실성

   1. expected answer type: “내 잔액이 얼마냐”고 물었을 때 잔액 500달러처럼 요청에 맞는 형태의 답을 했는지 확인한다.
   2. hallucination 검증: 500달러가 실제 계좌 값인지, agent가 지어낸 답인지 검증한다.
   3. trace 활용: 최종 문장뿐 아니라 어떤 근거와 호출을 거쳐 그 답에 도달했는지 추적한다.

5.2. tool과 parameter의 정확성

1. 올바른 도구 선택

   1. tool access 평가: 해당 답에 도달하기 위해 올바른 도구를 호출했는지 확인한다.
   2. 오용 탐지: 결과만 맞아 보이더라도 엉뚱한 도구를 사용했다면 신뢰할 수 없으므로 기록하고 평가한다.

2. 파라미터 정확성

   1. 입력 검증: 선택한 도구 내부에서 올바른 parameter를 전달했는지 점검한다.
   2. 구체적 사례: account ID가 123이어야 하는지, 다른 ID여야 하는지를 확인해 계정 혼동을 막는다.

5.3. inter-agent dependency와 전체 trace

1. 전체 결과와 호출 순서

   1. overall outcome/response: multi-agent 시스템의 최종 결과와 응답이 의도한 품질인지 확인한다.
   2. sequence: 서로 다른 도구와 sub-agent가 올바른 순서로 호출됐는지 점검한다.

2. 에이전트 간 메시지

   1. communication 품질: sub-agent 사이에 주고받은 메시지가 충분하고 정확한지 깊이 들여다본다.
   2. end-to-end conversation: session 안의 전체 agent conversation을 합쳐 최종 판단의 근거로 삼는다.

6. guardrails: 실행 환경·도구·권한·관측 가능성

발표자는 네 종류의 guardrail을 제시한다. 자율 생성 capability가 커질수록 아래 통제를 함께 둬야 한다.

6.1. code execution environment 샌드박싱

1. 보통의 컨테이너 격리와 다른 목표

   1. 일반적인 sandbox: agent 자체를 하나의 container 안에 넣어 외부 세계로부터 보호하는 방식이 흔하다.
   2. Strands가 강조한 방식: agent가 실행하는 코드의 environment 자체를 sandboxing해, 코드가 다른 실행 환경을 건드리지 못하도록 한다.

2. 최근 기능과 보호 효과

   1. 기능 출시: 발표 시점 기준 몇 주 전에 Strands가 code execution environment sandboxing 기능을 출시했다.
   2. 오작동 방지: 다른 실행 환경과 코드에 접근하거나, 잘못된 위치에 쓰거나, 의도치 않은 위치에서 삭제하는 일을 막는 보장이 된다.

6.2. tool·permission·access 통제

1. 도구 제한

   1. constrained tools: agent가 사용할 수 있는 도구 목록과 각 도구의 동작 범위를 제한한다.
   2. 최소 권한: 필요한 작업만 수행할 수 있게 쓰기·실행 범위를 축소한다.

2. 사용자와 질문의 제한

   1. 접근 주체: 누가 agent에 접근할 수 있는지 통제한다.
   2. 질문 범위: 어떤 사람이 어떤 종류의 질문을 할 수 있는지 제한한다.
   3. 위험한 요청 차단: 임의 삭제·광범위한 파일 수정처럼 피해가 큰 요청은 권한과 정책으로 막는다.

6.3. observability와 telemetry

1. 평가 데이터의 보존

   1. eval 기록: 앞에서 정의한 평가 결과를 지속해서 남긴다.
   2. telemetry: 도구 호출, 오류, 하위 에이전트 흐름과 실행 결과를 관측 가능한 형태로 수집한다.

2. 신뢰 가능한 운영 판단

   1. 재현 가능성: 무엇을 호출했고 무엇을 수정했는지 확인할 수 있어야 문제를 추적하고 되돌릴 수 있다.
   2. 배포 기준: 평가와 telemetry가 있어야 “처음 배운 것 이상을 스스로 수행하고, 고장 난 기능을 실행 중 복구하는 agentic system”을 운영에 둘지 판단할 수 있다.

7. self-improving agent로 향하는 Strands의 진화

7.1. 도구에서 에이전트와 소스 코드로

1. 세 단계의 발전

   1. 1단계: agent가 자체 도구를 작성한다.
   2. 2단계: agent가 자체 sub-agent를 생성한다.
   3. 3단계: agent가 자신의 source code를 업데이트한다.

2. 유머 섞인 전망

   1. self-improving/self-evolving: 발표자는 이 흐름을 스스로 개선하고 진화하는 agent의 시작이라고 부른다.
   2. 농담: 언젠가 agent가 세상을 장악할 것 같고 자신이 위험해질 것이라는 농담을 던지지만, 현재 단계의 가능성은 놀랍다고 평가한다.

7.2. Strands의 기원과 TypeScript 사례

1. 내부 프로젝트에서 오픈소스로

   1. 약 3년 전: Strands Agents는 agent가 대중화되기 전 AWS 내부에서 먼저 만들어졌다.
   2. 공개 결정: 내부 도구로 두기에는 강력했기 때문에 커뮤니티에 돌려주기로 하고 open-source로 공개했다.

2. 자기 소스 코드 업데이트

   1. Python 버전: 처음 공개한 Strands는 Python 버전이었다.
   2. TypeScript 생성: Python 버전의 Strands가 스스로 Strands의 TypeScript 버전을 작성했다.
   3. 의미: 단순히 새 도구 파일을 만드는 수준을 넘어, 프레임워크 자신의 source code를 갱신하는 사례다.

주요 발언 모음

“But how many agents do you know that can fix code at runtime?”

“Writes its own tools, writes its own agents and fixes itself.”

“You are the meta tooling agent that creates your own tools and custom tools at runtime.”

“With great power also comes greater responsibility.”

“This is the starting of self-improving agents and the self-evolving agents.”

핵심 데이터 & 수치

• 영상 길이: 20분 40초다.
• 초기 meta-tooling 구성: editor, shell, load_tool 세 도구와 system prompt다.
• 데모 agent의 초기 도구 파일: tools 디렉터리에 0개다.
• 계산 데모: 런타임에 math calculator를 만들고 임의의 수의 제곱을 계산한다.
• 문자열 데모: 생성한 character counter가 임의 문자열을 28 letters로 세고 세 글자 입력으로 재검증한다.
• 여행 데모: flight·activities·itinerary 세 sub-agent를 만든다.
• 분해 규칙: agent 생성 template은 요청을 2~4개 sub-agent로 나눈다.
• 평가 관점: session 목표, 답의 유용성·사실성, tool 선택, parameter, multi-agent 결과·순서·메시지를 합쳐 8개 관점으로 점검한다.
• Strands의 역사: agent가 대중화되기 전 약 3년 동안 AWS 내부에서 개발됐다.