Interpreter Skills: Building Workflows for Agents

🖼️ 인포그래픽

생성 예정

🖼️ 4컷 인포그래픽

생성 예정

💡 한 줄 요약

인터프리터 스킬은 에이전트가 지시문만 따르도록 기대하는 방식에서 벗어나, 검토 가능한 TypeScript 모듈로 확정적 절차를 실행하게 해 복잡한 에이전트 워크플로를 더 안정적으로 만들려는 실험이다.

📌 핵심 요약

글은 Deep Agents에 도입된 TypeScript 인터프리터를 바탕으로, 스킬에 실행 가능한 모듈을 포함하는 ‘인터프리터 스킬’을 실험하고 있다고 설명한다.
기존 스킬은 에이전트에게 절차와 제약을 설명하는 지시문 중심 구조였지만, 인터프리터 스킬은 SKILL.md의 지시와 index.ts 같은 실행 코드가 함께 존재해 결정적 절차를 코드로 고정할 수 있다.
에이전트는 해당 스킬이 필요한지 판단하고 입력을 정하며 결과를 해석하지만, 실제 반복 절차·검증·분류·하위 에이전트 호출 같은 부분은 검토 가능한 코드가 담당한다.
GitHub 저장소 triage 예시에서는 열린 이슈·PR·토론을 가져오고, 항목별 하위 에이전트를 실행하고, 큐와 클러스터링 과정을 거쳐 구조화된 결과와 Markdown 보고서를 반환하는 워크플로가 제시된다.
핵심 주장은 프롬프트만으로 절차 준수를 기대하면 긴 작업에서 누락·순서 변경·맥락 압축이 발생하기 쉽기 때문에, 반복적이고 평가 가능한 에이전트 작업은 스킬을 API이자 워크플로 단위로 다루는 방식이 유용하다는 것이다.

🧩 주요 포인트

글은 Deep Agents에 도입된 TypeScript 인터프리터를 바탕으로, 스킬에 실행 가능한 모듈을 포함하는 ‘인터프리터 스킬’을 실험하고 있다고 설명한다.
기존 스킬은 에이전트에게 절차와 제약을 설명하는 지시문 중심 구조였지만, 인터프리터 스킬은 SKILL.md의 지시와 index.ts 같은 실행 코드가 함께 존재해 결정적 절차를 코드로 고정할 수 있다.
에이전트는 해당 스킬이 필요한지 판단하고 입력을 정하며 결과를 해석하지만, 실제 반복 절차·검증·분류·하위 에이전트 호출 같은 부분은 검토 가능한 코드가 담당한다.
GitHub 저장소 triage 예시에서는 열린 이슈·PR·토론을 가져오고, 항목별 하위 에이전트를 실행하고, 큐와 클러스터링 과정을 거쳐 구조화된 결과와 Markdown 보고서를 반환하는 워크플로가 제시된다.
핵심 주장은 프롬프트만으로 절차 준수를 기대하면 긴 작업에서 누락·순서 변경·맥락 압축이 발생하기 쉽기 때문에, 반복적이고 평가 가능한 에이전트 작업은 스킬을 API이자 워크플로 단위로 다루는 방식이 유용하다는 것이다.

🧠 상세 정리

1. 인터프리터 스킬이 제안하는 변화

글의 출발점은 스킬이 더 이상 모델에게 지시를 전달하는 문서에만 머물 필요가 없다는 문제의식이다. 인터프리터 코드가 에이전트 루프와 직접 상호작용할 수 있으면, 스킬은 하위 에이전트를 만들고 작업 그래프를 관리하며 부분 실패를 처리하는 하나의 검토 가능한 워크플로가 될 수 있다. 따라서 스킬은 ‘이렇게 하라’고 설명하는 instruction surface이면서 동시에 런타임이 호출할 수 있는 API surface가 된다. 이 변화는 에이전트 작업 평가 방식도 바꾼다. 단순히 “지시를 대체로 따랐는가”를 묻는 대신, “예상한 함수를 호출했는가”, “올바른 입력으로 절차가 끝까지 실행됐는가”처럼 더 구체적인 질문을 던질 수 있게 된다.

2. Deep Agents의 인터프리터와 문제의 발견

본문은 최근 Deep Agents에 작은 내장 TypeScript 런타임인 인터프리터를 도입했다고 설명한다. 에이전트는 이미 코드를 잘 작성하므로, 인터프리터를 제공하면 여러 단계의 작업 의도를 코드로 직접 표현할 수 있고 그 결과 더 효율적이고 정확하며 예측 가능한 출력으로 이어질 수 있다. 하지만 같은 작업을 여러 번 시켰을 때 에이전트가 매번 서로 다른 유효한 코드 접근법을 만들 수 있다는 점도 관찰됐다. 이런 적응성은 어떤 과제에서는 장점이지만, 이미 검증된 접근법을 반복해야 하는 작업에서는 불안정성이 된다. 그래서 글은 ‘좋은 방법을 새로 생각해내는 것’보다 ‘우리가 작동한다고 아는 방법을 쓰는 것’이 필요한 경우를 문제로 삼는다.

3. 기존 스킬의 역할과 한계

기존의 스킬은 에이전트에게 재사용 가능한 행동을 제공하기 위한 단위로 설명된다. 보통 하나의 디렉터리에 SKILL.md가 있고, front matter에는 스킬의 용도에 대한 짧은 설명이 들어가며, 본문에는 지시사항·맥락·예시·제약·지원 파일이 포함된다. 여기서 중요한 장치는 progressive disclosure다. 에이전트는 모든 스킬 내용을 항상 컨텍스트에 넣지 않고, 먼저 짧은 목록을 보고 관련 스킬을 고른 뒤 필요할 때만 전체 SKILL.md를 읽는다. 이 방식은 스킬을 버전 관리하고 공유하고 평가하기 좋은 배포 단위로 만들지만, 핵심 행동은 여전히 에이전트가 문서를 읽고 절차를 정확히 수행하리라는 기대에 의존한다.

4. 인터프리터의 실행 모델

이 글에서 인터프리터는 harness와 함께 동작하는 TypeScript 런타임으로 정의된다. 에이전트는 이 런타임 안에서 다단계 작업을 코드로 표현할 수 있고, harness는 그 코드가 무엇에 접근할 수 있는지 통제한다. 인터프리터는 TypeScript 값 형태의 작업 상태를 제공하므로 배열은 배열로, 객체는 객체로, 헬퍼 함수는 함수로 턴을 넘어 유지될 수 있다. 에이전트가 모든 중간값을 stdout이나 파일, 모델에게 보내는 메시지로 바꾸지 않아도 된다는 점이 중요하다. 또한 샌드박스처럼 기본적으로 호스트 환경에 무제한 접근하는 것이 아니라, 파일시스템·네트워크·도구·하위 에이전트 접근은 명시적으로 노출되어야 하므로 허용 목록, 계량, 검사가 가능하다.

5. 인터프리터 스킬의 구조

인터프리터 스킬은 기존 스킬의 지시 체계와 실행 가능한 모듈을 결합한다. SKILL.md는 여전히 스킬이 언제 관련되는지, 어떤 import 경로와 사용법과 제약이 있는지 알려준다. 동시에 index.ts 같은 모듈은 인터프리터가 실제로 실행할 수 있는 helper나 workflow를 내보낸다. 예를 들어 table-cleanup 스킬은 validateRows 함수를 export해 필드 정규화, 필수값 확인, 구조화된 오류 반환을 코드로 수행할 수 있다. 이 구조에서 모델은 스킬 적용 여부와 입력, 결과 활용 방식을 결정하고, 모듈은 절차가 실제로 어떻게 실행되어야 하는지를 정의한다. 그래서 결정적인 부분은 컨텍스트 속 느슨한 지시가 아니라 검토·반복 개선 가능한 코드에 놓이게 된다.

6. GitHub 저장소 triage 예시

본문의 핵심 예시는 github-triage 스킬이다. 사용자가 저장소 triage를 요청하면, 에이전트는 프롬프트 지시에서 triage 과정을 매번 재구성하는 대신 스킬 모듈을 import하고 triage 함수를 호출한다. 옵션에 따라 열린 이슈, PR, discussion을 가져오고, 각 항목에 대해 하위 에이전트를 만들어 더 압축된 설명을 생성한다. 그런 다음 하위 에이전트 응답을 큐에 넣고 하나씩 소비하면서, 또 다른 하위 에이전트가 해당 항목을 기존 클러스터에 넣을지 새 클러스터를 만들지 판단한다. 입력은 동적으로 정해질 수 있지만 절차 자체는 고정되어야 하는 유형의 작업이므로, 인터프리터 스킬의 장점이 잘 드러나는 사례로 제시된다.

7. 구조화된 결과와 긴 작업의 안정성

GitHub triage 예시에서 반환값은 단순한 문자열이 아니라 API의 일부로 다뤄진다. result.clusters, result.unassigned 같은 구조화된 데이터가 있고, result.toMarkdown()처럼 모델 친화적인 보고서로 렌더링하는 helper도 제공된다. 에이전트는 이 결과를 계속 활용해 특정 클러스터를 더 깊이 살펴보거나, 후속 하위 에이전트를 만들거나, 필요할 때 compact한 Markdown 보고서를 생성할 수 있다. 글은 이런 작업에서 모델이 시간이 지나며 coherence를 잃기 쉽다고 지적한다. triage는 하나의 결정이 아니라 많은 작은 결정의 연결이며, 300개 항목이 있다면 모델이 모든 부분 상태를 작업 컨텍스트 안에서 계속 유지하고 조율해야 하기 때문이다.

8. 컨텍스트 의존 절차의 취약성

본문은 모델의 재량과 컨텍스트 창에만 의존해 긴 절차를 운용하면 모델이 지름길을 택하거나 절차를 과도하게 압축할 수 있다고 말한다. 특히 작업 컨텍스트의 한계에 가까워진다고 느낄 때 이런 문제가 심해질 수 있으며, 글은 이를 context anxiety라는 표현으로 언급한다. 일반적인 harness에서는 모델이 300개 저장소 항목 각각의 부분 단계를 기억하고 과거 결정을 조정하며 다음 행동을 선택해야 한다. 반면 인터프리터 스킬에서는 모델이 루틴을 한 번 호출하고, 모듈이 300개의 하위 에이전트 작업 생성, 결과 수집, 분류, 클러스터링을 수행한 뒤 compact한 객체를 되돌려줄 수 있다. 이때 모델은 모든 중간 상태를 자신의 작업 컨텍스트에 짊어질 필요가 없다.

9. 워크플로로서의 스킬

글은 코딩 에이전트의 확산과 함께 에이전트에 대한 기본 mental model이 바뀌었다고 설명한다. 이전 세대의 에이전트는 개발자가 사전에 단계 순서를 명시적으로 정하는 workflow-style에 가까웠고, 신뢰성은 실행 경로를 미리 정의하는 데서 나왔다. 현대적 agent harness는 컨텍스트와 모델 재량을 중심에 두며, 모델이 현재 맥락을 보고 다음 행동을 선택한다. 이런 인터페이스는 개발자뿐 아니라 운영자, PM, 도메인 전문가처럼 지시문·파일·체크리스트·예시로 사고하는 사람들에게도 이해하기 쉽다. 그러나 결정적인 agent routine에 대한 필요는 사라지지 않았고, 특정 절차가 올바른 입력으로 끝까지 실행됐는지 확인하려는 요구는 계속 남아 있다.

10. 프롬프트만으로 절차를 보장할 때의 문제

본문은 프롬프트만으로 절차 준수를 기대하는 방식이 취약하다고 지적한다. 에이전트는 단계를 건너뛰거나, 순서를 바꾸거나, 엉뚱한 지시를 만족시키거나, 관련 없는 요청을 절차에 섞거나, 실제 과정을 따르지 않은 채 그럴듯한 결과를 낼 수 있다. 예시로 ‘인보이스를 제출하되 중간에 멈춰 춤추는 고양이 GIF를 만들라’는 요청이 나온다. 인보이스 제출이 프롬프트 지시로만 표현되어 있다면, 에이전트는 그 우회 요청을 같은 작업의 일부로 취급해 인보이스를 반쯤 끝낸 상태로 남길 수 있다. 글의 결론은 결정적인 부분은 코드로 표현하고, 이를 인터프리터 안의 모듈로 노출하며, 에이전트가 언제 호출할지 판단하게 하는 방식이 두 접근의 장점을 결합한다는 것이다.

🧾 핵심 주장 / 시사점

이 글의 핵심은 에이전트 신뢰성을 모델의 ‘성실한 지시 이행’ 문제가 아니라, 검토 가능한 실행 경로와 호출 여부를 평가하는 문제로 재정의한다는 점이다.
인터프리터 스킬은 모델의 적응성과 코드의 결정성을 분리한다. 모델은 언제 무엇을 할지 판단하고, 반복적·절차적·장기 상태 관리가 필요한 부분은 모듈이 맡는다.
긴 작업에서 컨텍스트에 모든 중간 상태를 쌓는 방식은 쉽게 불안정해지므로, 구조화된 결과 객체와 하위 에이전트 orchestration을 코드화하는 접근이 실용적인 대안으로 제시된다.

✅ 액션 아이템

SKILL의 SKILL 신호를 SKILL 기준으로 분해하고, 주요 경쟁사 대비 매출·수요·수익성 논리가 얼마나 검증 가능한지 점검한다.
Agents. Key Takeaways Skills 발언과 SKILL의 투자자 수요를 함께 보며, 상장 가능성과 실제 공개 재무 수치 확인이 필요한 항목을 분리한다.
SKILL 비상장주 수요와 주요 경쟁사 2차시장 반응을 비교해, IPO 일정·철회 가능성·시장 과열 리스크를 별도 체크리스트로 관리한다.