Addy Osmani의 2026년 5월 3일 글 **“Agent Skills”**는 AI 코딩 에이전트의 본질적 문제를 명확히 짚습니다. 에이전트는 기본적으로 구현 코드만 빠르게 만들고 끝내려 하기 때문에, 시니어 엔지니어가 중요하게 보는 스펙 작성·테스트·리뷰·출시 안전장치를 자주 생략합니다.
원문: Agent Skills — Addy Osmani
1) Skill의 본질: “지식"이 아니라 “행동 절차”
글에서 Skill은 단순 참고 문서가 아닙니다. 상황에 따라 에이전트 컨텍스트에 주입되는 **작업 절차(runbook)**에 가깝습니다.
- 나쁜 예: 테스트 원칙 2,000자 설명문
- 좋은 예: 실패 테스트 작성 → 실패 확인 → 최소 구현 → 통과 확인 → 리팩토링
즉, 핵심은 **읽을거리(prose)**가 아니라 **실행 흐름(process)**입니다.
2) Agent Skills가 인코딩한 SDLC
레포의 20개 스킬은 아래 6단계 라이프사이클로 조직됩니다.
- Define (
/spec) — 무엇을 만들지 명세 - Plan (
/plan) — 리뷰 가능한 단위로 분해 - Build (
/build) — 수직 슬라이스로 구현 - Verify (
/test) — 동작 증거 확보 - Review (
/review) — 품질·범위·리스크 점검 - Ship (
/ship) — 안전한 출시
여기에 /code-simplify가 전 단계에 걸쳐 복잡도 통제를 담당합니다.
포인트는 간단합니다. 좋은 팀이라면 원래 하던 SDLC를 에이전트에게도 동일하게 강제해야 한다는 것입니다.
3) 성능을 만드는 5가지 설계 원칙
(1) Process over prose
문장을 길게 쓰는 대신, 에이전트가 수행 가능한 순서를 제공해야 합니다.
(2) Anti-rationalization table
“이번 건은 작아서 스펙 불필요” 같은 자기합리화를 미리 반박 테이블로 넣습니다. 사람/에이전트 모두에게 효과적입니다.
(3) Verification is non-negotiable
모든 단계의 종료조건을 증거 기반으로 둡니다. 테스트 통과, 빌드 로그, 리뷰 승인 등.
(4) Progressive disclosure
초기에 모든 규칙을 다 넣지 않고, 현재 단계에 필요한 스킬만 로딩합니다. 토큰 낭비와 성능 저하를 막는 하네스 전략입니다.
(5) Scope discipline
“요청받은 것만 수정"을 강제합니다. 주변 리팩토링 확산을 막아 PR을 검토 가능하게 유지합니다.
4) 왜 Google식 문화가 많이 보이는가
Addy는 공개된 Google 엔지니어링 실천을 다수 반영했다고 설명합니다.
- Hyrum’s Law
- 테스트 피라미드(약 80/15/5)
- DAMP over DRY(테스트 가독성 우선)
- 작은 PR 선호(약 100줄 규모)
- Chesterton’s Fence
- Trunk-based development, atomic commit
- Shift Left, feature flag
- Code as liability
핵심은 “새로운 이론"이 아니라, 원래 검증된 엔지니어링 규범을 에이전트 런타임으로 이식했다는 점입니다.
5) 당장 가져갈 수 있는 실천 포인트
- 팀 AGENTS.md에 anti-rationalization 목록을 만든다.
- 내부 가이드는 에세이 대신 체크포인트형 워크플로우로 재작성한다.
- “완료” 정의에 항상 검증 증거 첨부를 넣는다.
- 규칙집은 크게 1권이 아니라, 라우팅되는 작은 챕터 집합으로 쪼갠다.
- 에이전트 운영 원칙으로 아래 5줄을 고정한다:
- 가정은 구현 전에 드러내기
- 요구사항 충돌 시 멈추고 확인하기
- 필요하면 반박하기
- 단순하고 지루한 해법 선호하기
- 요청 범위만 수정하기
결론
이 글의 요지는 “에이전트를 더 똑똑하게 만들자"가 아닙니다. 에이전트가 건너뛰기 쉬운 시니어 엔지니어링 절차를, 건너뛸 수 없게 시스템화하자입니다. 결국 경쟁력은 모델 성능 자체보다, spec/test/review/ship을 얼마나 일관되게 강제하는 하네스 설계에서 갈립니다.