Agents · ARTICLE · 2026
Agent Skills (GeekNews)
요약
GeekNews에 올라온 "Agent Skills" 항목은 Addy Osmani의 같은 제목 글을 요약하고 독자 댓글 토론을 함께 실은 자료다. 원문이 제시한 설계 원칙과 lifecycle 구성을 정리하는 데 그치지 않고, 저장소의 정량 스펙과 다른 도구로 옮겨 쓰는 경로, 그리고 원문 요약만으로는 드러나지 않는 반론을 한자리에 모았다.
이 페이지가 다루는 대상은 두 겹이다. 하나는 Agent Skills라는 프레임워크의 내용이고, 다른 하나는 그것을 받아든 실무자들의 반응이다. 후자가 이 자료의 고유한 값이다. 원문이 "이렇게 하면 에이전트가 절차를 지킨다"는 처방이라면, 댓글 토론은 그 강제가 실제로 작동하는지를 되묻는다.
읽는 순서로는 원문 정리인 Agent Skills를 먼저 보고 이 페이지를 나중에 보는 편이 낫다. 이 자료는 원문의 주장을 전제로 깔고 그 위에 반론과 실무 비용을 더하는 구조이기 때문이다.
배경
AI 코딩 에이전트는 제약이 없으면 최단 경로로 과제를 끝낸다. GeekNews 요약은 이 기본 행동을 문제의 출발점으로 삼는다. 에이전트의 목표는 코드가 동작하는 상태에 도달하는 것이고, 문서나 증거를 남기는 일은 그 목표에 직접 기여하지 않으므로 생략된다.
경험 있는 엔지니어가 습관적으로 거치는 절차는 그래서 통째로 빠진다. 요약이 지목한 항목은 네 가지다.
| 생략되는 절차 | 하는 일 |
|---|---|
| spec 작성 | 무엇을 만들지와 완료 조건을 먼저 문서로 고정한다 |
| 테스트 | 동작이 의도대로인지를 실행 결과라는 증거로 확인한다 |
| 코드 리뷰 | 변경을 작성자가 아닌 다른 눈으로 검토한다 |
| trust boundary review | 신뢰 경계를 넘나드는 입력과 권한을 점검한다 |
이 네 항목의 공통점은 결과물이 diff에 잘 드러나지 않는다는 것이다. 따라서 최단 경로를 고르는 주체는 이 절차를 우선순위에서 뒤로 미룬다.
Agent Skills는 이 절차를 강제하는 scaffold 프레임워크로 소개된다. scaffold는 모델 주위에 짜 놓은 보조 실행 구조를 뜻한다. 모델 자체를 바꾸는 대신 모델이 따라 걸을 길을 바깥에 깔아 두는 접근이며, 이 점에서 프롬프트 개선과 성격이 다르다.
핵심 개념
스킬은 특정 작업 절차를 담아 에이전트에 결합하는 지침 패키지다. 이 자료에서 스킬은 읽어 두는 참고 문서가 아니라 실행되는 워크플로를 가리킨다. 형식은 frontmatter가 붙은 markdown 파일 한 장이다.
워크플로로 성립하려면 세 요소가 필요하다. 순서가 정해진 step, 증거를 만들어 내는 checkpoint, 그리고 명시적인 exit criteria다. exit criteria는 한 단계를 끝냈다고 선언할 수 있는 종료 조건을 말한다. 이 조건이 문서에 없으면 판단은 에이전트에게 넘어가고, 에이전트는 스스로 충분히 했다고 결론 내린 뒤 다음 단계로 넘어간다.
verification은 에이전트 산출물을 자동으로 검사하는 단계다. Agent Skills는 verification을 선택 항목이 아니라 워크플로의 필수 마무리로 놓고, 통과 여부를 말이 아니라 구체적 증거로 남기도록 요구한다.
progressive disclosure는 필요한 시점에만 정보를 단계적으로 노출하는 설계다. 스킬 20개를 한꺼번에 컨텍스트에 올리지 않고 현재 과제에 맞는 것만 활성화한다. 이 원칙은 뒤에서 다룰 컨텍스트 비용 문제와 직접 연결된다.
스킬의 구조
파일 형식과 실행 단위
스킬 하나는 markdown 파일 하나로 완결된다. 앞머리의 frontmatter가 스킬의 이름과 적용 조건 같은 메타데이터를 담고, 본문이 실행할 절차를 담는다.
이 형식 선택이 뒤에 나오는 이식성과 컨텍스트 비용을 모두 결정한다. markdown 한 장이라 어느 도구에나 넣을 수 있고, 동시에 본문이 길어질수록 컨텍스트를 그만큼 차지한다.
5개 설계 원칙
| 원칙 | 내용 |
|---|---|
| Process over prose | 에세이가 아니라 에이전트가 실행할 수 있는 워크플로로 쓴다 |
| Anti-rationalization table | 흔한 shortcut 변명과 그에 대한 반박을 미리 짝지어 표로 둔다 |
| Verification is non-negotiable | verification을 생략할 수 없게 하고 구체적 증거를 요구한다 |
| Progressive disclosure | 현재 과제 맥락에 맞는 스킬만 단계적으로 노출한다 |
| Scope discipline | 변경 범위를 요청받은 범위 안으로 제한한다 |
다섯 원칙은 서로 다른 종류의 실패를 막는다. process over prose는 지침이 읽히기만 하고 실행되지 않는 실패를 막는다. 산문으로 쓴 좋은 조언은 에이전트에게 참고 자료로만 소비되므로, 순서와 checkpoint를 가진 절차 형태로 바꾸어 둔다.
anti-rationalization table은 shortcut을 정당화하는 변명과 그 반박을 미리 짝지어 둔 표다. 에이전트가 절차를 건너뛸 때 스스로 근거를 만들어 내는 상황을 겨냥하며, 그 근거를 문서 안에서 먼저 반박해 둔다.
verification 원칙과 scope discipline은 워크플로의 끝과 옆을 각각 막는다. verification은 산출물이 증거 없이 완료로 선언되는 것을 막고, scope discipline은 요청하지 않은 파일까지 변경이 번지는 것을 막는다.
progressive disclosure는 나머지 네 원칙을 실행 가능하게 만드는 조건이다. 스킬을 많이 갖출수록 규율은 촘촘해지지만 그만큼 컨텍스트를 소모하므로, 맥락에 맞는 것만 올려야 규모를 키울 수 있다.
lifecycle 단계와 슬래시 커맨드
저장소는 스킬 20개를 6개 lifecycle 단계로 묶고 슬래시 커맨드 7개를 함께 제공한다. 라이선스는 MIT다.
| 단계 | 성격 |
|---|---|
| Define | 무엇을 만들지 정한다 |
| Plan | 작업을 분해하고 순서를 정한다 |
| Build | 구현한다 |
| Verify | 증거로 확인한다 |
| Review | 검토한다 |
| Ship | 배포한다 |
각 단계에 붙는 커맨드 이름은 이 요약에 없다. 원문을 정리한 Agent Skills가 /spec, /plan, /build, /test, /review, /ship 여섯 개로 적는다. 이 요약이 세는 슬래시 커맨드는 7개이므로 단계에 매핑되지 않는 커맨드가 하나 더 있는 셈인데, 그 정체는 이 자료만으로 확인되지 않는다.
Google 엔지니어링 관행 인코딩
스킬이 담는 절차가 새로 만든 규칙이 아니라 이미 검증된 SDLC 관행이라는 점을 근거로 든다. 언급되는 항목은 다음과 같다.
| 관행 | 스킬 안에서의 역할 |
|---|---|
| Hyrum's Law | 관찰 가능한 동작은 결국 누군가 의존하게 되므로 인터페이스 변경을 신중히 다룬다 |
| test-driven development | 구현보다 테스트를 먼저 두어 완료 조건을 코드로 고정한다 |
| Chesterton's Fence | 존재 이유를 모르는 코드는 함부로 제거하지 않는다 |
| trunk-based development | 긴 브랜치 대신 짧은 주기의 통합을 기본으로 삼는다 |
| ~100줄 PR | 사람이 실제로 검토할 수 있는 변경 크기의 상한을 둔다 |
| code-as-liability | 코드는 자산이 아니라 유지와 리뷰 부담이라는 관점을 유지한다 |
이 목록은 scope discipline과 verification 원칙의 근거로도 작동한다. ~100줄 PR과 code-as-liability는 변경을 작게 유지할 이유를 설명하고, test-driven development는 verification이 요구하는 증거의 형태를 구체화한다.
도입 경로
특정 도구 전용이 아니라는 점을 이 요약은 도입 방식별로 나눠 적는다.
| 도입 방식 | 대상 도구 |
|---|---|
| 마켓플레이스 설치 | Claude Code |
| 규칙 디렉터리에 배치 | Cursor (.cursor/rules/) |
| markdown을 그대로 투입 | Gemini CLI, Codex, Aider, Windsurf, OpenCode |
세 방식의 차이는 도구가 제공하는 로딩 장치의 유무에 있다. Claude Code는 설치 경로를 갖추고 있고, Cursor는 규칙 파일을 읽는 약속된 디렉터리를 갖추고 있으며, 나머지 도구는 그런 장치 없이 markdown 본문을 컨텍스트에 직접 넣는다.
세 방식 모두 결국 같은 markdown을 읽는다는 점이 이식성의 근거다. 스킬이 특정 런타임에 묶인 플러그인이 아니라 텍스트 파일이므로, 도구를 바꿔도 자산이 남는다. MIT 라이선스라 사내 저장소에 복제해 고쳐 쓰는 것도 막히지 않는다.
커뮤니티 토론
정량 벤치마크는 없다. 실무자 증언과 댓글 토론이 그 자리를 대신하며, 입장은 네 가지로 나뉜다.
| 입장 | 요지 |
|---|---|
| 찬성 | 프로덕션 배포에서 "의외로 효과적"이었다. 완벽보다 기대값(expected value)이 중요하다 |
| 반대 | 규칙을 적용할지 결정하는 주체가 LLM 자신이라 강제가 실제로 작동하는지 의문이다 |
| 구현 우려 | 800줄을 넘는 스킬이 컨텍스트를 크게 차지하고, 과다 설치는 토큰 낭비다 |
| 중립 | 특정 도구보다 워크플로 구조 자체가 중요하다 |
찬성 논거
찬성 측은 완벽한 준수가 아니라 기대값(expected value)을 기준으로 보자고 말한다. 규칙이 항상 지켜지지는 않더라도 기준선 신뢰도가 올라가는 것만으로 도입할 이유가 된다는 것이다.
사람 팀 관리와의 유비도 근거로 나온다. 엔지니어를 관리할 때 쓰던 관행이 에이전트에도 그대로 통한다는 관찰이다. 사람 역시 절차를 항상 지키지는 않지만, 그렇다고 코드 리뷰 제도를 폐지하지는 않는다.
반대 논거
반대 측의 핵심 지적은 강제의 주체 문제다. 스킬을 적용할지 말지를 판단하는 것이 결국 LLM 자신이므로, 문서로 규칙을 아무리 정교하게 써 두어도 모델이 우회할 수 있다는 것이다.
문서가 복잡해질수록 우회할 여지도 함께 넓어진다는 관찰이 이어진다. 규칙을 촘촘히 만드는 것이 준수율을 자동으로 높이지는 않는다는 뜻이다. 따라서 사람 리뷰는 여전히 필수라는 결론으로 이어진다.
긴 에이전트 세션을 두고 "fake productivity"라는 표현도 나왔다. 오래 실행되는 세션이 실제 성과 없이 바빠 보이기만 할 수 있다는 우려다.
구현 우려
실제 설치 단계에서 나온 우려는 컨텍스트 비용에 집중된다. 스킬 하나가 800줄을 넘기도 해서 컨텍스트를 크게 차지한다. 필요하지 않은 스킬까지 설치하면 토큰과 컨텍스트가 그만큼 낭비된다.
여기서 나온 권고는 사용 방식의 전환이다. 스킬 묶음 전체를 필수 설치 대상으로 다루기보다 참고 패턴으로 다루고, 필요한 것만 골라 쓰는 편이 낫다는 것이다.
frontmatter만 로드하는 방식은 완화책으로 언급된다. 본문 전체가 아니라 메타데이터만 먼저 올려 두면 컨텍스트 오염이 줄어든다.
중립 관찰
중립 측은 도구보다 구조에 무게를 둔다. 어떤 도구를 쓰느냐보다 워크플로를 구조화했다는 사실 자체가 효과의 원인이라는 시각이다.
인프라와 소프트웨어에서 이미 확립된 자동화 원칙과 같은 성격이라는 평가도 함께 나온다. 결론은 조건부 인정이다. 엄격한 프로세스 규율과 함께 갈 때 정당한 생산성 향상으로 볼 수 있다는 것이며, 규율 없이 스킬만 설치하는 경우는 여기에 해당하지 않는다.
컨텍스트 비용과 progressive disclosure의 긴장
커뮤니티가 짚은 800줄 스킬과 컨텍스트 오염 문제는 원문의 progressive disclosure 원칙과 정면으로 부딪친다. 두 주장을 나란히 놓으면 긴장이 분명해진다.
- 규율을 촘촘하게 만들려면 스킬 수와 각 스킬의 길이를 늘려야 한다.
- 스킬을 늘리면 컨텍스트에 올릴 후보가 늘고 토큰 소모가 커진다.
- progressive disclosure는 맥락에 맞는 것만 올려 이 비용을 줄이자고 제안한다.
- 그러나 무엇이 맥락에 맞는지 판단하는 주체 역시 모델이다.
마지막 항목이 반대 측 논거와 같은 지점으로 수렴한다. 규칙 준수 판단과 스킬 선택 판단이 모두 모델 안에서 이루어지므로, 강제와 절약이 같은 신뢰 문제를 공유한다.
frontmatter만 로드하는 방식은 이 긴장을 완화하지만 없애지는 못한다. 어느 스킬의 본문을 실제로 펼칠지는 여전히 선택의 문제로 남는다. 얼마나 갖추고 얼마나 로드할지는 스킬 설계에서 아직 해소되지 않은 문제다.
한계
- 2차 요약이라 원문의 논증 전개가 압축되어 있다. 인용의 정확한 문맥은 원문을 정리한 Agent Skills에서 확인해야 한다.
- 댓글 요약은 발화자와 수치가 특정되지 않는다. "의외로 효과적"이나 800줄 같은 표현의 출처를 개별 발화자까지 되짚기 어렵다.
- 슬래시 커맨드 개수(7개)와 lifecycle 단계 수(6개)가 어긋나지만 그 차이를 설명하지 않는다.
- 도입 효과를 재는 정량 데이터가 없다. 찬성과 반대가 모두 경험 진술에 의존하므로 어느 쪽도 검증되지 않은 상태로 남는다.
핵심 용어
| 용어 | 뜻 |
|---|---|
| anti-rationalization table | shortcut을 정당화하는 흔한 변명과 그 반박을 미리 짝지어 둔 표 |
| exit criteria | 워크플로 한 단계를 끝냈다고 선언할 수 있는 명시적 종료 조건 |
| trust boundary review | 신뢰 경계를 넘나드는 입력과 권한을 점검하는 리뷰 |
| fake productivity | 긴 에이전트 세션이 실제 성과 없이 바빠 보이기만 하는 현상을 가리키는 토론 용어 |
| code-as-liability | 코드는 자산이 아니라 유지와 리뷰 부담이라는 Google의 관점 |
관련 페이지
- Agent Skills: 이 자료가 요약하고 토론하는 원문. 5개 설계 원칙과 단계별 커맨드 매핑의 출처다
- Equipping agents for the real world with Agent Skills: progressive disclosure를 스킬 로딩 구조로 설명한 문서. 여기서 제기된 컨텍스트 비용 문제의 공식 대응에 해당한다
- Agent Skills (agentskills/agentskills): 스킬 폴더 레이아웃 표준. markdown 한 장이라는 형식 전제를 구체화한다
- Agent Skills Overview (agentskills.io): 스킬 포맷의 채택 생태계 정리. 이 자료의 이식 경로 목록과 겹친다
- Loop Engineering (Addy Osmani, 2026-06-07): 같은 저자의 후속 글로, 스킬을 loop 구성 요소로 확장한다
- Beyond the Prompt: Claude Code (Arpan Patel, 2026-05-26): Claude Code에서 verification과 스킬을 실전에 적용하는 가이드
- Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents: harness 변경의 이득을 회의적으로 계측하는 시각. 이 자료의 규칙 우회 회의론과 통한다