They optimized for LLMs, not just Google.

FAQs. Comparison pages. Transparent pricing. LinkedIn presence. These aren't vanity plays. They're what gets you cited in ChatGPT, Gemini, and Claude when your buyers are researching, your investors are looking, and your future hires are deciding where to work.

Download the free AEO Playbook for Startups from HubSpot and get the exact checklist. Five minutes to read.

Unlock the playbook

요즘 여러분도 일상 업무에서 OpenClaw나 Hermes Agent 같은 개인 AI 에이전트를 쓰고 계시는 분 많이 계실 것 같습니다 - 계속 쓰시든, 아니면 한 번쯤 써 보셨든지간에요. 이런 몇몇 에이전트들은 이미 꾸준한 사용자층을 확보했고, 그 사용자들 중에 젠슨 황(Jensen Huang) 같은 사람도 들어 있죠.

이 에이전트들이 작동하는 데 중요한 요소 중 하나가 바로 재사용 가능한 스킬(reusable skills)입니다. 여기서 스킬이라고 하면, ‘에이전트가 도구를 어떻게 쓰고, 워크플로우를 어떻게 구성하고, 판단을 어떻게 내리고, 반복되는 작업을 어떻게 해결할지를 정의하는 지침 패키지’라고 정리할 수 있겠습니다.

그리고 이제 이 ‘스킬’은 에이전트의 행동을 컨트롤하는 핵심 기제(mechanism)가 되고 있는데요. 예전에는 에이전트 성능을 높인다고 하면 대체로 프롬프트 엔지니어링(prompt engineering)이라든가 컨텍스트 엔지니어링(context engineering)을 떠올렸지만, 이제는 그것만으로 충분하지 않죠. 스킬 자체가 추가적인 컨텍스트와 지식을 담기 시작했기 때문이예요.

그렇다면, 자연스럽게 스킬 자체는 어떻게 최적화할 수 있을까 하는 질문이 따라오겠죠.

지금 대부분의 스킬은 사람이 직접 작성하거나, LLM이 한 번 생성하거나, 시행착오를 거쳐서 조금씩 다듬는 방식으로 만들어집니다. Hermes 같은 경우에는 물론 사용 중에 스킬을 개선하는 방향을 보여 주고 있지만, 넓게 보면 아직 스킬 개선은 필요할 때마다 그때 그때 손보는 수준에 머물러 있습니다.

최근에는 스킬을 더 체계적으로 스스로 개선할 수 있게끔 하려고 하는 몇 가지 방법론이 등장했습니다. 방향은 세 갈래인데요.

첫 번째는 하나의 스킬을 대상으로 합니다. 에이전트가 그 스킬을 사용해서 작업을 수행하게 하고, 성공과 실패를 분석한 뒤에, 실제로 성능이 좋아지는 수정만 남기는 방식입니다.

두 번째는 스킬 하나가 아니라 전체 스킬 라이브러리를 봅니다. 시간이 지나면서 중복되거나 낡거나 서로 맞지 않게 된 스킬들을 정리하고, 더 안전하게 조합될 수 있도록 유지관리하는 접근이예요.

세 번째는 소프트웨어 엔지니어링 에이전트에 초점을 맞춥니다. 여기서는 단순히 스킬을 많이 넣는 것이 아니라, 작업 성공률을 높이면서도 비용은 줄일 수 있는 스킬 묶음을 찾는 것이 중요하구요.

오늘은 이 세 가지가 각각 어떻게 작동하는지 간단하지만 단계별로 한 번 살펴보겠습니다. 여러분의 에이전틱 워크플로우(agentic workflows)에 적용해 볼 만한 아이디어도 함께 얻기를 바라면서요.

스킬 엔지니어링은 아직 초기 단계이고, 아직 많은 사람들이 이 흐름에 충분히 주목하고 있지는 않습니다만, 에이전트의 시대에 핵심적인 도구가 될 거라고 믿습니다.

오늘 에피소드에서는 아래와 같은 내용을 다룹니다:

먼저 핵심 개념부터 정리해 보겠습니다. 여기서 말하는 엔지니어링(engineering)은 에이전트를 둘러싼 전체 운영 환경을 어떻게 설계하느냐의 문제를 해결하는 범위를 이야기하는데요. 이 관점에서 우리가 다룰 수 있는 층위는 세 가지입니다.

프롬프트 엔지니어링, 이미 여러분 모두에게 익숙한 개념이죠?

특정한 요청을 잘 수행하도록 좋은 지시문을 작성하는 거죠. 모델에게 원하는 바를 말하고, 필요하다면 역할을 부여하고, 제약조건을 넣고, 예시를 주고, 출력 형식을 정하고, 성공 기준을 알려줍니다.

예를 들자면 이런 식입니다.

“이 논문을 쉬운 말로 요약하되, 방법론에 집중하고, 핵심 시사점 다섯 가지를 뽑아 줘.”

핵심적인 특징이라면, 프롬프트 엔지니어링은 대체로 국소적이고, 그 순간의 작업에 맞춰진 방식입니다. 지금 이 작업을 더 잘 수행하도록 모델을 돕는 거라는 겁니다.

하지만 아무리 지시문을 잘 써도, 필요한 컨텍스트가 빠져 있으면 한계가 있습니다. 프롬프트가 완벽해도 모델이 올바른 문서, 도구, 메모리, 작업 상태를 가지고 있지 않다면 여전히 실패하기 쉽죠. 그래서 두 번째 층위가 필요합니다.

컨텍스트 엔지니어링은 실행 시점(runtime)에 모델 주변의 환경을 올바르게 구성하는 작업입니다.

여기에는 시스템 메시지, 도구 설명, 검색된 문서, 메모리, 예시, 현재 작업 상태, 이전 행동, 제약 조건, 권한, 때로는 토큰·시간·도구 호출 예산까지 포함됩니다.

다시 말해서, 모델이나 에이전트가 행동하거나 응답할 때 무엇을 알고 있어야 하고, 무엇에 접근할 수 있어야 하는지를 설계하는 일이라고 하면 될 것 같습니다. 그리고 이 컨텍스트는 아래와 같은 이유 때문에 반드시 최적화해야 합니다:

자, 그리고 이제 가장 새로운, 최신의 층위가 등장하죠.

스킬 엔지니어링(skill engineering)은, 에이전트가 발견하고, 적용하고, 개선하고, 버전을 관리하고, 다른 작업으로 전이(transfer)할 수 있는 재사용 가능한 능력 패키지(reusable capability packages)를 만드는 일이라고 정의하는게 좋겠습니다.

그렇지만 좀 더 쉽게 말하면, 스킬은 작은 절차(mini-procedure)입니다. 에이전트에게 무엇을 해야 하는지만 알려주는 것이 아니라, 그 일을 다음에도 다시 할 수 있도록 어떻게 해야 하는지까지 알려줍니다.

그래서 스킬은 일회용 프롬프트보다 소프트웨어 아티팩트(software artifact)에 더 가깝습니다. 프롬프트는 보통 하나의 상황을 위해 작성되지만, 스킬은 여러 상황을 맞닥뜨려도 잘 적용할 수 있게끔 설계됩니다. 테스트할 수 있고, 유지보수할 수 있고, 여러 에이전트가 공유할 수도 있고, 워크플로우가 바뀌면 업데이트할 수도 있습니다.

스킬의 이런 특성은, 에이전트가 더 오래 실행되는 시스템으로 바뀔수록 특히 중요해집니다. 에이전트가 같은 워크플로우를 반복할수록, 그 워크플로우에 안정적인 형태를 부여할 수 있다면 그 가치가 커지기 때문입니다. 스킬 라이브러리는 에이전트가 더 일관적으로 행동할 수 있게 해 주고, 에이전트의 행동을 더 잘 들여다볼 수 있게 해 주고, 시간이 지나도 개선하기 쉽게 해 줍니다.

하지만 다른 면도 있어요. 스킬이 에이전트 스택의 일부가 되면, 당연히 스킬 자체도 오류, 오용, 공격의 새로운 대상이 됩니다. 바로 이 지점이 다음에 살펴볼 내용이기도 하구요.

에이전트 스킬을 개선하려는 여러 종류의 시도 중에서도, Microsoft의 최근 연구 하나가 특히 눈에 띄는데요. 거기서 제안한 게 바로 SkillOpt입니다. SkillOpt는 “에이전트 스킬을 위한 체계적이고 제어 가능한 텍스트 공간 옵티마이저(systematic controllable text-space optimizer for agent skills)”라고 정의하고 있는데요.

SkillOpt는 스킬 문서 자체를 훈련시킬 수 있는 대상으로 봅니다. 그리고 “agents → skills → self-improving workflows”라는 파이프라인을 만듭니다.

SkillOpt가 흥미로운 이유는, 에이전트 모델의 가중치는 그대로 둔 채 에이전트가 사용하는 외부 스킬 텍스트만 개선한다는 점인데요. 다시 말해서 SkillOpt는 프롬프트를 한 번 잘 쓰거나, 스킬을 그때그때 다시 작성하는 방식에 기대지 않습니다. 대신 에이전트가 실제 작업에서 어떻게 성공하고 실패하는지를 반복적으로 확인하고, 그 결과를 바탕으로 스킬 문서를 조금씩 고쳐 나갑니다. 그리고 검증 과정에서 실제로 성능이 좋아진 수정만 남깁니다.

이렇게 만들어진 최종 스킬은 사람이 읽고 이해할 수 있는 문서로 남습니다. 다른 작업에도 다시 사용할 수 있고, 모델 자체를 다시 학습시킬 필요도 없습니다. 그래서 성능을 높이면서도 fine-tuning에 드는 비용과 복잡성을 줄일 수 있습니다.

SkillOpt는 다음과 같은 흐름으로 작동합니다.

이 워크플로우를 짧게 정리하면 이렇습니다.

SkillOpt는 스킬 작성을 통제된 최적화 루프로 바꿉니다. 에이전트를 실행하고, 증거를 수집하고, 성공과 실패를 되짚어 본 뒤, 제한된 범위 안에서 텍스트 수정안을 제안합니다. 그런 다음 보류해 둔 작업에서 수정안을 검증하고, 해로운 변경은 거부하고, 가장 좋은 스킬만 재사용 가능한 아티팩트로 내보냅니다.

그리고 중요한 세부사항이 하나 더 있습니다.

SkillOpt는 더 긴 훈련 epoch 동안 어떤 변화가 일어나는지도 추적합니다. 하나의 epoch이 끝나면, 이전 스킬과 새 스킬을 같은 작업에서 비교해서 무엇이 좋아졌는지, 무엇이 나빠졌는지, 무엇이 여전히 실패하는지, 무엇이 계속 잘 작동하는지 확인합니다.

이 과정이 있어야 옵티마이저가 가장 최근 배치에만 과민하게 반응하지 않고, 장기적으로 유용한 교훈을 유지할 수 있다는 것이죠.

Microsoft에서는 한 번에 스킬이 지나치게 많이 바뀌지 않도록 제한하기도 하고, 거부된 수정안을 기록해서 옵티마이저가 나중에 비슷한 실수를 피하도록 하고, 훈련 epoch에 걸쳐서 업데이트를 천천히 해서 유용한 패턴이 사라지지 않게끔 합니다.

Microsoft 연구진은 SkillOpt를 여섯 개 벤치마크, 일곱 개 대상 모델, 세 가지 실행 환경에서 평가했습니다. 실행 환경은 direct chat, Codex, Claude Code였구요.

결과는 꽤 뚜렷했습니다: SkillOpt는 테스트된 52개 설정 모두에서 단독 최고 성능을 냈거나, 최고 성능과 같은 수준의 결과를 보였습니다.

정리하면, SkillOpt는 스킬이 스스로 개선될 수 있다는 가능성을 꽤 설득력 있게 보여 줍니다.

핵심은 모델을 다시 학습시키지 않는다는 점입니다. SkillOpt는 고정된 에이전트 주변에 있는 지시 파일, 즉 스킬 문서를 개선합니다. 그리고 좋아 보이는 수정안을 모두 받아들이는 것이 아니라, 실제 검증에서 성능이 좋아진 변경만 남깁니다. 그 결과 작고, 읽을 수 있고, 다시 사용할 수 있는 스킬이 만들어집니다. fine-tuning 없이도 성능을 끌어올릴 수 있다는 점이 SkillOpt의 가장 큰 장점입니다.

물론 한계도 분명합니다. 이 방법을 실제로 쓰려면 다음 조건들을 함께 봐야 합니다.

그래서 다음 질문이 자연스럽게 이어집니다. 스킬 하나가 아니라, 스킬 라이브러리 전체를 관리해야 한다면 어떻게 해야 할까요?

Emory University와 University of Illinois Urbana-Champaign의 연구진은 이 문제를 스킬 하나가 아니라 스킬 라이브러리 전체의 문제로 봤습니다. 에이전트가 사용하는 스킬이 많아질수록, 그 스킬들을 시간이 지나면서 계속 정리하고 관리해야 한다고 본 것이겠죠.

그리고 이 프레임워크가 바로 SkillOps입니다. 이름이 비슷하지만 SkillOpt와는 많이 다릅니다.

SkillOps가 다루는 문제는 아주 현실적입니다. 스킬 하나만 따로 보면 별문제가 없어 보일 수 있지만, 에이전트가 점점 더 많은 스킬을 쓰기 시작하면 라이브러리 전체는 서서히 복잡해집니다. 비슷한 스킬이 중복되고, 오래된 스킬이 남고, 서로 맞지 않는 스킬들이 함께 검색될 수도 있습니다. 그렇게 되면 에이전트가 필요한 스킬을 찾기 어려워지고, 여러 스킬을 안전하게 조합하기도 어려워지고, 결국 라이브러리 자체를 신뢰하기 힘들어질 수 있죠.

그래서 SkillOpt가 하나의 스킬 문서를 더 잘 훈련하는 방법이라면, SkillOps는 여러 스킬이 쌓인 전체 생태계를 관리하는 방법에 가깝습니다.

작동 방식도 이 관점에서 이해하면 쉽습니다. 에이전트가 스킬 라이브러리를 사용하기 전에, SkillOps가 먼저 라이브러리를 점검합니다. 어떤 스킬이 중복되는지, 어떤 스킬이 위험한지, 어떤 스킬에 검증 절차가 빠져 있는지 살펴본 뒤에, 필요한 부분을 고치고 더 정리된 버전의 라이브러리를 돌려줍니다.

중요한 점은, 이 과정에서 downstream agent의 내부 코드를 바꿀 필요가 없다는 겁니다. 에이전트는 원래 쓰던 라이브러리 대신, SkillOps가 정리해 둔 라이브러리를 사용하면 됩니다.

그리고 SkillOps의 흥미로운 점은, 이 스킬 라이브러리를 단순한 목록으로 보지 않고 Hierarchical Skill Ecosystem Graph, HSEG라는 구조로 표현한다는 겁니다. 이름은 조금 어렵지만, 핵심은 간단합니다. 스킬 하나하나를 따로 보는 것이 아니라, 스킬들이 서로 어떤 관계를 맺고 있는지까지 함께 보는 겁니다.

이 파이프라인을 조금 더 자세히 살펴보겠습니다.

Hierarchical Skill Ecosystem Graph, 즉 HSEG는 두 개의 층으로 구성됩니다.

먼저 Internal Skill Graph가 있습니다. 여기서 SkillOps는 각 스킬을 다섯 부분으로 구성된 구조화된 contract로 표현하는데요:

이 구조가 중요한 이유는, SkillOps가 어떤 스킬이 실제로 사용 가능한지, 그리고 다른 스킬과 호환되는지 확인하는 방법이기 때문입니다.

그 다음, SkillOps는 External Graph-of-Graphs를 구성하는데, 여기서는 스킬들이 서로 다른 관계로 연결됩니다.

SkillOps의 주요 워크플로우는 Task-Time Loop와 Library-Time Loop라는 두 개의 교대 루프로 구성됩니다.

Task-Time Loop는 실제 작업을 실행할 때 작동하는 루프입니다.

새로운 작업이 들어오면, SkillOps는 먼저 스킬 라이브러리에서 이 작업에 쓸 만한 후보 스킬들을 찾아냅니다. 여기서 중요한 것은 단순히 관련 있어 보이는 스킬을 고르는 데서 끝나지는게 아니고, 이 스킬들이 실제로 함께 이어져서 하나의 작업 흐름을 만들 수 있는지도 확인합니다.

확인하는 내용은 다음과 같습니다.

중간에 빠진 부분이 있으면 SkillOps는 계획에 필요한 단계를 추가할 수 있습니다. 예를 들어 중간 결과가 올바른지 확인해야 한다면 validator를 넣고, 어떤 스킬의 출력 형식이 다음 스킬과 맞지 않는다면 adapter를 넣어 형식을 맞춥니다.

이렇게 조립된 skill subgraph가 실제로 실행됩니다. 실행 중 어떤 스킬이 실패하면 SkillOps는 그 자리에서 local repair를 시도합니다. 실패한 스킬을 대체 가능한 다른 스킬로 바꾸거나, 관찰된 오류 trace를 바탕으로 스킬을 고칠 수 있습니다. 복구가 어렵다면 실패 내용을 기록해서, 나중에 라이브러리를 정리하고 개선할 때 사용할 수 있도록 남겨 둡니다.

Library-Time Loop는 작업 하나를 실행하는 과정이 아니라, 스킬 라이브러리 전체를 관리하는 단계입니다.

작업이 끝나면 SkillOps가 실행 로그를 살펴보는데, 어떤 스킬이 실제로 쓰였는지, 어디서 실패했는지, 어떤 스킬이 다른 스킬과 잘 맞았는지 같은 기록을 바탕으로 각 스킬의 contract를 다시 정리합니다. 그런 다음에 라이브러리 전체를 다섯 가지 기준으로 점검합니다.

이 진단 결과를 바탕으로 SkillOps는 라이브러리를 정비하는데요, 중복된 스킬은 합치고, 실패 위험이 큰 스킬은 고치고, 최근 작업에서 거의 쓰이지 않는 스킬은 retire할 수 있습니다. 필요한 경우에는 validator를 추가해서 결과 검증 절차를 보강하고, 스킬 간 형식이 맞지 않을 때는 adapter를 넣어 서로 연결될 수 있게 만듭니다. 또 특정 작업 인자에 맞춰서 parameterized skill을 실제로 사용할 수 있는 형태로 구체화할 수도 있습니다.

그래서, SkillOps의 전체 흐름은 일종의 ‘자기 유지관리 생태계’에 가깝습니다. Task-Time Loop는 현재 라이브러리로 당장의 작업을 해결하고, Library-Time Loop는 그 실행 기록을 다시 학습 재료로 삼아서 라이브러리를 더 깨끗하고, 더 안전하고, 더 재사용하기 쉬운 상태로 유지하는 겁니다.

현재 구현의 장점은 대부분 rule-based라는 점입니다. 시스템은 실행 로그처럼 관찰할 수 있는 신호를 바탕으로 라이브러리를 정비합니다. 덕분에 library time의 유지관리 과정에서는 추가로 LLM을 호출하거나 하는 일이 없고 토큰을 거의 쓰지 않습니다.

그렇다면 SkillOps는 실제로 에이전트 성능을 얼마나 끌어올릴 수 있을까요?

연구진은 ALFWorld에서 SkillOps를 평가했는데, ALFWorld는 에이전트가 여러 단계를 거쳐서 집 안의 물건을 찾고, 옮기고, 조작하는 작업을 수행하는 벤치마크입니다. 여기서 SkillOps는 79.5%의 task success를 기록했습니다. 기존 baseline보다 8.8%포인트 높은 결과였고, 더 흥미로운 점은 task-time LLM call 없이 이 성능을 냈다는 것입니다.

또 하나 눈에 띄는 점은 ‘확장성’인데요, SkillOps는 스킬 라이브러리가 200개에서 2000개로 커져도 성능이 무너지지 않았습니다. 가장 큰 규모의 라이브러리에서도 80.5%의 task success를 기록했고, 그 다음으로 좋은 baseline보다 여전히 31포인트 이상 앞섰습니다.

물론, 한계점은 있죠.

물론 SkillOps에도 한계는 있습니다.

우선, SkillOps는 구조화된 skill contract를 전제로 합니다. 각 스킬이 언제 쓰일 수 있고, 무엇을 만들고, 어떻게 검증해야 하는지, 어떤 방식으로 실패할 수 있는지가 어느 정도 정리되어 있어야 합니다. 그런데 실제 배포 환경에서는 이런 정보가 처음부터 깔끔하게 정리되어 있지 않은 경우가 많죠.

또 하나는 검증 범위입니다. SkillOps가 더 넓은 환경에서 얼마나 잘 작동하는지 보려면, 실제로 오래 실행되는 에이전트의 로그를 대상으로 더 많은 테스트가 필요합니다.

rule-based 유지관리 루프에도 장단점이 있습니다. 비용이 낮고 예측 가능하다는 점은 장점이지만, 스킬 사이의 충돌이 단순한 형식 문제를 넘어서 의미나 의도 차원에서 발생하는 경우에는 놓칠 수 있습니다. 이런 경우에는 더 강력한 추론을 해야 할 수도 있겠죠.

그럼에도 SkillOps의 장점은 분명합니다.

SkillOps는 스킬 라이브러리를 그냥 지침 모음으로 보지 않고, 시간이 지나면서 정리하고, 고치고, 폐기하고, 다시 조합해야 하는 소프트웨어 시스템처럼 다룹니다. 덕분에 라이브러리를 더 깨끗하게 유지할 수 있고, 스킬들을 더 안전하게 연결할 수 있고, retrieval agent도 필요한 스킬을 더 쉽게 찾아 쓸 수 있습니다.

또 하나 중요한 점은 SkillOps를 plug-in layer로 붙일 수 있다는 것입니다. 기존 에이전트의 내부 로직을 바꾸지 않아도 됩니다. 에이전트는 원래 라이브러리 대신 SkillOps가 정리해 둔 라이브러리를 사용하면 됩니다.

자, 그럼 마지막으로, 조금 더 앞서 나온 연구이긴 하지만 여전히 흥미로운 또 다른 접근 방법 하나를 살펴보겠습니다.

또 다른 흐름은 SkillMOO입니다. 영국, 독일, 중국 연구진이 제안한 방법으로, 특히 소프트웨어 엔지니어링 에이전트에 초점을 맞춥니다.

SkillMOO가 출발하는 문제의식은 단순합니다. 에이전트 스킬을 평가할 때 작업 성공률, 즉 pass rate만 보면 충분하지 않다는 것입니다.

어떤 스킬은 에이전트가 문제를 더 잘 풀게 만들 수 있습니다. 하지만 그 과정에서 더 많은 컨텍스트를 넣고, 더 많은 토큰을 쓰고, 실행 시간도 늘릴 수 있습니다. 다시 말해서 성능은 올라가지만, 비용도 함께 증가할 수 있다는 거죠.

그래서 SkillMOO는 스킬 최적화를 multi-objective optimization problem, 즉 다목적 최적화 문제로 봅니다.

목표는 pass rate를 높이되, inference cost가 불필요하게 커지지 않도록 하는 것입니다. 결국 SkillMOO는 “성능은 높이고, 비용은 낮추는” 쪽에 가장 가까운 스킬 묶음을 찾는 방법이라고 이해하시면 될 것 같습니다.

SkillMOO는 skill bundle을 다룹니다. 여기서 skill bundle은 코딩 에이전트가 특정 작업을 수행할 때 함께 사용하는 스킬 묶음을 말하는 것이구요.

이 방법에는 두 가지 종류의 에이전트가 등장합니다.

SkillMOO의 워크플로우는 여러 개의 후보 bundle을 만드는 데서 시작합니다. 보통 사용 가능한 skill pool에서 서로 다른 조합을 뽑아 초기 후보군을 구성하게 되구요.

그 다음 task solver가 각 후보 bundle을 사용해서 소프트웨어 작업을 실행하고, 몇 가지 신호를 기록합니다.

그 다음으로, skill optimizer가 이 기록을 바탕으로 bundle의 수정안을 제안합니다. 예를 들면 다음과 같은 방식입니다.

이렇게 수정된 bundle은 새로운 후보가 됩니다. 그리고 같은 task solver가 다시 그 후보를 평가합니다.

중요한 부분은 그 다음인데, 바로 여러 개의 후보 중 무엇을 선택할 것인가의 문제죠.

SkillMOO는 여기서 NSGA-II라는 고전적인 multi-objective evolutionary algorithm을 사용합니다. 쉽게 말하면, 하나의 기준만 보고 고르는 게 아니라 두 가지 목표를 동시에 보는 것인데, pass rate는 높이고, inference cost는 낮추는 방향입니다.

조금 더 정확히 말하면, SkillMOO는 Pareto-efficient skill bundles를 찾습니다. 어떤 bundle은 성능을 더 높일 수 있지만 비용도 더 듭니다. 반대로 비용을 줄이면 성능이 조금 떨어질 수 있습니다. SkillMOO는 이 둘 사이에서 더 이상 쉽게 개선하기 어려운 균형점을 찾으려고 하는 방법입니다.

결국 이 과정의 목적은 분명합니다. 여러 skill bundle 중에서 실제로 배포할 만한 가치가 있는, 가장 높은 조합을 고르는 겁니다.

연구진이 SkillMOO를 SkillsBench의 16개 소프트웨어 엔지니어링 작업 전체에 적용해 봤다고 하는데, 이 가운데 실제로 의미 있는 통과 결과가 나온 12개 작업을 기준으로 보면, SkillMOO는 11개 작업에서 가장 높은 pass rate를 기록했습니다.

성과도 꽤 분명했습니다. SkillMOO는 pass rate를 최대 +21%포인트 높였고, 상대 개선율로 보면 최대 +131%까지 끌어올렸습니다. 동시에 inference cost는 최대 31.7% 줄였습니다.

여기서 중요한 메시지는 이거예요:

좋은 skill bundle은 스킬을 많이 넣는다고 만들어지는게 아니라, 오히려 불필요한 것을 덜어내고, 필요한 것만 남기고, 비용까지 함께 고려할 때 더 좋은 결과가 나올 수 있다는 겁니다.

예를 들면 이런 거예요:

흥미로운 점은, 좋은 후보로 남은 스킬 묶음들을 분석했을 때 새 스킬을 추가하는 방식은 pass rate를 높이지 못했다는 겁니다. 더 많이 넣는다고 더 잘하는 것이 아니라, 오히려 불필요한 스킬을 덜어내고 조합을 정리하는 쪽이 더 효과적이었습니다.

이 부분이 바로 SkillMOO의 장점을 잘 보여 줍니다. SkillMOO는 스킬 최적화를 단순히 “성능을 올리는 문제”로 보는 게 아니라, 실제로 배포할 수 있는 조합을 찾는 문제로 봅니다. 그래서 성능 뿐 아니라 비용도 함께 따지는 겁니다. 이렇게 보면 스킬을 계속 덧붙이는 것보다, 무엇을 남기고 무엇을 빼야 하는지가 더 중요해지죠.

물론 아직 한계는 있습니다. 이번 평가는 SkillsBench 안의 16개 작업을 바탕으로 이루어졌습니다. 다른 종류의 소프트웨어 작업에서도 같은 결과가 나올지는 더 확인해야 하구요.

또, SkillMOO의 실험에 주로 GLM-5 모델이 사용되었는데, 같은 방식이 GPT, Claude, 또는 다른 코딩 에이전트에서도 그대로 통할지는 아직 확실하지 않습니다.

마지막으로 edit-pattern 분석도 조심해서 봐야 합니다. 이 분석을 보면, 어떤 편집이 좋은 결과와 함께 나타났는지를 보여 주기는 하지만, 그런 방식의 편집이 언제나 성능 개선의 직접적인 원인이라고 증명한 것은 아닙니다.

이 세 가지 방법론에서 우리는 무엇을 배울 수 있을까요?

먼저 각 방법이 잘 맞는 상황이 조금씩 다르다는 점을 잘 알아두어야 할 것 같습니다:

하지만, 그보다 더 크고 중요한 메시지는 이겁니다:

스킬은 이제 에이전트 주변에 붙는 보조 지침이 아니라, 하나의 독립적인 엔지니어링 계층이 되어 가고 있습니다. 그리고 이 계층은 전체 아키텍처 안에서 훈련할 수 있고, 유지관리할 수 있고, 최적화할 수 있는 대상이라는 겁니다.

오늘 기억해 둘 만한 핵심 포인트는 아래와 같습니다:

‘스킬 엔지니어링’, 이제 막 독특한 자기만의 최적화 스택을 만들어 가기 시작한 새로운 영역이라고 할 수 있습니다. 앞으로 에이전트 기술 스택의 핵심을 차지할 거라고 생각되는 스킬 엔지니어링, 계속 흥미를 가지고 관찰해 볼 필요가 있을 것 같습니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!