[한영자막] 36%에서 100%로: 자기 개선 에이전트는 어떻게 스스로 스킬을 작성할까요? — Runlayer Rafal Wilinski

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

자기 개선 에이전트는 실행 경험을 재사용 가능한 스킬로 작성하며, Runlayer는 이를 적용한 특정 과제에서 성공률이 36%에서 100%로 높아졌다고 소개한다.

📌 핵심 요점

1. 스킬은 에이전트가 필요할 때 읽는 업무 플레이북이다. 처음에는 짧은 설명만 제공하고, 관련성이 있을 때 전체 내용을 컨텍스트에 넣는 점진적 공개 방식으로 작동한다.
2. 장시간 추론 능력만으로는 신뢰성을 확보하기 어렵다. 잘못된 방향으로 시작하면 도구 호출과 비용이 늘어나므로, 회사의 실제 업무 절차를 담은 스킬이 초기 경로를 안내해야 한다.
3. MCP는 도구의 실행 능력뿐 아니라 스킬을 전달하는 배포 계층으로 활용할 수 있다. 중앙 서버에서 검색, 역할별 제공, 정책 적용을 관리하면 여러 클라이언트가 같은 지식 기반에 접근할 수 있다.
4. 자기 개선의 핵심은 실행 기록에서 절차를 추출하는 것이다. 성공 기록은 작동하는 방법을 남기고, 실패 기록은 누락된 가드레일과 예외 조건을 드러내어 스킬 개선에 활용된다.
5. Runlayer는 Chromium 포크를 AWS Lambda에서 실행하는 과제에서 스킬 재사용 후 성공률이 36%에서 100%로 상승했다고 설명한다. 이 순환을 전사적으로 확장하면 한 에이전트의 경험을 조직 전체가 재사용할 수 있다는 것이 발표의 주장이다.

🧩 배경과 문제 정의

Rafal Wilinski는 Runlayer의 창립 엔지니어로 자신을 소개하며, 이전에는 Zapier의 에이전트와 AI 팀을 이끌었다고 설명한다. 발표의 질문은 에이전트 한 개의 성능 개선을 넘어, 문제 해결 경험이 회사 전체에 축적되는 자기 개선 구조를 만들 수 있느냐는 것이다.

어려운 문제를 해결해도 디버깅 과정과 판단 근거가 다음 작업이나 세션 종료와 함께 사라지면 같은 탐색을 반복하게 된다. 반대로 회사 고유의 절차를 플레이북으로 남기면 다른 사람과 에이전트가 이를 재사용할 수 있다. 발표자는 스킬, MCP 배포, 실행 기록에서 절차를 추출하는 메커니즘을 연결해 이 문제를 풀자는 접근을 제시한다.

🕒 시간순 섹션별 상세정리

1. 개인의 개선을 조직의 지식 축적으로 확장하기

• 발표는 자기 개선 에이전트에 네트워크 효과를 결합해, 회사 전체가 지속적으로 개선되는 구조를 만들자는 제안으로 시작한다. [00:19]
• 어려운 문제를 해결할 때마다 방법을 팀에 남기면 비슷한 문제를 처음부터 풀 필요가 없지만, 실제로는 디버깅과 추론의 지식이 작업 전환이나 세션 종료와 함께 사라진다고 지적한다. [01:14]
• 발표자는 이러한 지식 축적을 구현할 기본 요소가 이미 갖춰져 있다고 주장한다. [01:19]

2. 발표자 소개와 스킬의 작동 방식

• Rafal은 Runlayer의 창립 엔지니어이며, 이전에는 Zapier의 에이전트와 AI 팀을 이끌면서 실제 운영에 쓸 수 있는 에이전트를 만드는 데 집중했다고 보여준다. [01:42]
• 모델, 프롬프트, 도구, 실행 환경 등 여러 개선 수단 중 이번 발표에서는 접근하기 쉬운 스킬에 초점을 맞춘다. 스킬은 관련 지식이 필요할 때 에이전트가 읽는 플레이북이다. [02:15]
• 점진적 공개는 처음에 스킬의 요약만 보여주고, 필요할 때 전체 내용을 컨텍스트에 넣어 에이전트의 작업 경로를 바꾸는 방식이다. [02:39]

3. 더 오래 추론하는 에이전트에 필요한 업무 맥락

• 독립적으로 작업을 수행할 수 있는 시간을 측정하는 벤치마크를 언급하며 모델의 다단계 작업 능력이 좋아지고 있다고 보여준다. 다만 작업 완료는 여전히 확률의 문제다. [03:24]
• 긴 작업 시간은 잘못된 가설을 따라 수백 번의 도구 호출을 반복할 가능성도 키운다. 스킬은 초기 방향을 안내해 시간, 토큰, 비용의 낭비를 줄이는 역할을 한다. [04:13]
• 배포 롤백의 스크립트·기능 플래그 순서나 이탈 위험 고객에게 쓰는 표현처럼 회사 내부에 축적된 절차가 중요하다. 발표자는 이런 맥락과 플레이북의 부재를 기업 AI 시도가 실패하는 이유로 본다. [05:00]

4. 스킬 확산을 가로막는 세 가지 문제

• 스킬 생태계는 마크다운, JSON, CLI, Git 저장소 등 개발자에게 익숙한 방식에 치우쳐 있어, 비기술 인력이 스킬을 만들고 공유하기 어렵다고 보여준다. [05:45]
• 외부 스킬 설치에는 프롬프트 주입, 높은 실행 권한을 요구하는 스크립트, 다른 사람의 API 키 같은 위험이 섞일 수 있다고 경고한다. Runlayer는 매일 수천 개의 스킬을 검사한다고 드러낸다. [06:18]
• 문제 해결 뒤 유용한 플레이북을 남기는 데 시간과 노력이 들며, 모든 LLM 클라이언트가 스킬을 지원하지도 않는다. 마케팅·인사·법무·재무 부서가 사용하는 환경까지 고려해야 한다. [07:09]

5. MCP를 스킬의 배포 계층으로 활용하기

• 스킬은 일을 수행하는 방법에 관한 지식을 제공하고, 도구는 실행 능력을 제공한다. 발표자는 둘을 대체 관계로 보기보다 MCP로 스킬까지 전달할 수 있다고 보여준다. [07:51]
• 원격 MCP 서버를 회사의 기준 지식 저장소로 삼으면 클라이언트가 스킬을 검색하고, 서버가 정책과 역할에 따라 적절한 버전을 제공할 수 있다. Runlayer는 내부에서 약 6개월간 이 방식을 사용했다고 드러낸다. [08:18]
• skills over MCP 작업 그룹도 언급한다. 정확한 API는 아직 확정되지 않았지만 MCP로 조직 전체에 지식을 전달하는 방향을 제시한다. [08:40]

6. 클라이언트 호환성과 중앙 관리

• 발표 시점의 공식 사양 방향은 MCP 리소스에 기울어 있지만, 리소스 지원이 고르지 않아 Runlayer는 도구 방식으로 제공한다고 보여준다. [08:51]
• 발표자는 MCP 배포가 개발자용 환경을 넘어 여러 클라이언트에 스킬을 전달해 비기술 인력의 접근 문제를 줄일 수 있다고 본다. [09:18]
• 중앙 API를 두면 AI 도입 책임자가 회사에서 공유하고 배포하는 지식을 한곳에서 관리할 수 있다. [09:29]

7. Voyager가 보여준 재사용 가능한 절차 지식

• 발표자는 2023년 GPT-4 출시 이후의 Voyager 연구를 자기 개선의 참고 사례로 보여준다. Minecraft 탐색 과정에서 모델 가중치를 바꾸지 않고도 능력을 축적했다고 보여준다. [10:27]
• 핵심은 스킬 라이브러리다. 발견으로 이어진 도구 호출을 코드 형태의 레시피로 저장해, 제작대나 다이아몬드 곡괭이가 필요할 때 다시 찾아 사용할 수 있었다. [11:08]
• 탐색의 결과를 버리지 않고 재사용 가능한 절차 지식으로 바꿔야 한다는 것이 발표자가 이어받으려는 원리다. [11:18]

8. 성공과 실패 기록에서 스킬을 추출하기

• Runlayer는 에이전트가 실제 업무를 수행한 뒤, 여러 도구 호출이 포함된 유용한 성공 기록을 프런티어 LLM에 전달해 스킬을 추출한다고 보여준다. [11:38]
• 실패는 빠진 가드레일, 필요한 라이브러리, 예상하지 못한 예외 조건을 드러내므로 스킬을 다듬는 중요한 신호가 된다. [12:05]
• 성공과 실패 기록을 모두 추출 메커니즘에 공급해 신뢰성과 견고성을 높이며, 이 과정이 사람의 개입 없이 비동기적으로 작동한다고 드러낸다. [12:33]

9. 성공률 36%에서 100%로 상승한 사례

• Chromium 포크를 AWS Lambda에서 실행하는 과제에서 초기 성공률은 36%였으며, 발표자는 이를 실제 운영에 충분하지 않은 수준으로 평가한다. [12:54]
• 자기 개선 기능을 켠 뒤 한 실행이 해결 방법을 찾아냈고, 이를 재사용 가능한 스킬로 만들어 이후 실행에 포함하자 성공률이 100%로 올랐다고 보고한다. [13:14]
• 좋은 스킬은 탐색 공간을 좁혀 불필요한 도구 호출과 분기 탐색을 줄이고, 토큰과 비용을 절약한다고 보여준다. [13:42]

10. 모델 의존을 줄이고 조직의 개선 순환 만들기

• 발표자는 프런티어 모델의 지능을 빌려 쓰는 자원으로 본다. 접근 가능한 동안 유용한 절차를 발견하고 보존해 회사의 업무 수행 방식을 담은 카탈로그를 만들자는 제안이다. [14:25]
• 스킬, MCP 배포, 계속 갱신되는 중앙 지식 저장소를 모든 에이전트와 클라이언트에 연결하면 조직 차원의 자기 개선 순환으로 확장할 수 있다고 보여준다. [15:12]
• 비슷한 실행들을 묶어 스킬을 추출하고 프롬프트 주입·개인정보 등을 검사한 뒤 라이브러리에 넣어 배포한다. 이후 같은 문제가 생기면 데이터베이스 재시작이나 운영 환경 롤백 절차를 다시 탐색할 필요 없이 플레이북을 활용할 수 있다. [16:17]

11. 내부 경험을 경쟁력으로 축적하기

• 발표자는 누구나 같은 모델에 접근하고 소프트웨어를 재현하기 쉬워질 때 기업의 방어력이 어디에서 생기는지 질문한다. [16:51]
• 회사가 어렵게 얻은 교훈을 관리되는 지식으로 축적하고 전사에 공유하는 순환이 구성원 전체의 역량을 높이는 경쟁력이 될 수 있다고 주장한다. [17:15]
• 이러한 지식 축적은 모델 성능 변화에 대응하고 모델을 바꾸지 않고도 비용을 낮추는 수단이며, 경쟁사가 복제하기 어려운 내부 문화와 정체성에 연결된다는 말로 마무리한다. [17:35]

🧾 결론

• 자기 개선은 모델 가중치를 바꾸는 방식 외에도, 실행 경험을 절차 지식으로 보존하고 다음 작업에 적용하는 방식으로 구현할 수 있다.
• 스킬 생성, 중앙 라이브러리, MCP 배포를 연결해야 개별 에이전트의 학습이 조직의 지식 축적으로 이어진다.
• 발표자가 제시한 100% 성공률은 특정 과제의 결과다. 일반적인 신뢰성 보장으로 확대하기 전에 평가 조건과 재현성을 확인해야 한다.
• 조직의 어려운 문제 해결 경험을 지속적으로 축적하는 체계가 모델 교체나 성능 변화에 대응하는 자산이 될 수 있다.

📈 투자·시사 포인트

• 기업용 AI의 가치는 모델 접근성 외에도 내부 절차를 포착하고 재사용하는 능력에서 평가할 수 있다. 발표자는 이를 경쟁사가 복제하기 어려운 지식 기반의 방어력으로 본다.
• 스킬 배포와 거버넌스는 비개발 부서까지 AI 활용을 넓히는 기반이다. 중앙 검색, 역할별 제공, 정책 적용을 함께 살펴볼 필요가 있다.
• 비용 효율은 모델 단가뿐 아니라 불필요한 탐색과 도구 호출을 얼마나 줄이는지에 달려 있다. 발표에서는 절감 규모를 수치로 제시하지 않는다.
• 스킬 라이브러리의 양보다 검증과 갱신 체계가 중요하다. 프롬프트 주입과 개인정보를 검사하면서 새로운 예외 조건을 반영하는 구조가 운영 품질을 좌우할 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 36%에서 100%로 상승한 사례의 실행 횟수, 평가 기간, 성공 판정 기준, 독립 검증 여부는 제공되지 않는다. 다른 과제에서도 같은 개선이 나타나는지는 확인이 필요하다.
• 성공·실패 기록을 활용한 스킬 개선이 사람의 개입 없이 작동한다고 설명하지만, 실패 원인 판별과 잘못된 절차의 확산을 막는 구체적인 검증 방식은 공개되지 않는다.
• 발표 시점에는 skills over MCP의 정확한 API가 확정되지 않았고, MCP 리소스 지원도 클라이언트마다 다르다고 설명한다. 실제 도입 시 사용할 클라이언트의 지원 범위를 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복적으로 어려움을 겪는 업무 하나를 선정하고, 스킬 적용 전후의 성공률·도구 호출 수·토큰 사용량·비용을 같은 조건에서 비교한다.
• 성공과 실패의 실행 기록을 함께 보존하고, 재사용할 절차·누락된 가드레일·예외 조건을 스킬 초안으로 정리한다.
• 중앙 스킬 라이브러리와 MCP 배포를 시험하면서 검색 품질, 역할별 접근, 버전 제공, 실제 클라이언트 호환성을 점검한다.
• 생성되거나 외부에서 가져온 스킬을 배포하기 전에 프롬프트 주입, 개인정보, 실행 권한과 비밀정보 포함 여부를 검토한다.

❓ 열린 질문

• 실패 기록에서 유용한 교훈과 잘못된 추론을 어떻게 구분하며, 어떤 기준을 충족해야 스킬을 조직 전체에 배포할 수 있을까?
• 비슷한 실행 기록을 묶고 기존 스킬을 갱신할 때, 충돌하거나 오래된 절차는 어떻게 처리할까?
• 스킬이 축적될수록 검색과 선택의 정확도는 어떻게 유지하며, 조직 전체의 비용 절감과 성공률 개선을 어떻게 측정할까?