{"title":"Addy Osmani의 Agent Skills — 에이전트에게 시니어 엔지니어링 프로세스를 강제하는 방법","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/agent-skills-addy-osmani/","section":"posts","date":"2026-05-06T12:56:02+09:00","lastmod":"2026-05-06T12:56:02+09:00","description":"Addy Osmani의 'Agent Skills'(2026-05-03)를 했다. 핵심은 에이전트에게 '코드 생성'만 시키지 말고, spec→plan→build→test→review→ship의 시니어 엔지니어링 루프를 워크플로우로 강제해야 한다는 점이다.","summary":"Addy Osmani의 2026년 5월 3일 글 **\u0026ldquo;Agent Skills\u0026rdquo;**는 AI 코딩 에이전트의 본질적 문제를 명확히 짚습니다. 에이전트는 기본적으로 구현 코드만 빠르게 만들고 끝내려 하기 때문에, 시니어 엔지니어가 중요하게 보는 스펙 작성·테스트·리뷰·출시 안전장치를 자주 생략합니다.\n원문: Agent Skills — Addy Osmani\nTL;DR 요약 문제 정의: 에이전트의 기본 보상 신호는 \u0026ldquo;task complete\u0026quot;라서, 검증 가능한 증거 없이도 완료를 선언하기 쉽다. 핵심 해법: \u0026ldquo;규칙 문서\u0026quot;가 아니라 \u0026ldquo;실행 워크플로우\u0026quot;를 SKILL.md로 주입해 단계별 체크포인트와 종료조건을 강제한다. 구조화된 SDLC: /spec → /plan → /build → /test → /review → /ship (+ /code-simplify)로 사람의 시니어 프로세스를 복원한다. 실무 원칙 5가지: process over prose, anti-rationalization table, verification non-negotiable, progressive disclosure, scope discipline. 실행 메시지: 에이전트 시대일수록 \u0026ldquo;diff에 안 보이는 시니어 업무\u0026quot;를 시스템에 박아 넣어야 사고를 줄일 수 있다. 1) Skill의 본질: \u0026ldquo;지식\u0026quot;이 아니라 \u0026ldquo;행동 절차\u0026rdquo; 글에서 Skill은 단순 참고 문서가 아닙니다. 상황에 따라 에이전트 컨텍스트에 주입되는 **작업 절차(runbook)**에 가깝습니다.\n","content":"Addy Osmani의 2026년 5월 3일 글 **\u0026ldquo;Agent Skills\u0026rdquo;**는 AI 코딩 에이전트의 본질적 문제를 명확히 짚습니다. 에이전트는 기본적으로 구현 코드만 빠르게 만들고 끝내려 하기 때문에, 시니어 엔지니어가 중요하게 보는 스펙 작성·테스트·리뷰·출시 안전장치를 자주 생략합니다.\n원문: Agent Skills — Addy Osmani\nTL;DR 요약 문제 정의: 에이전트의 기본 보상 신호는 \u0026ldquo;task complete\u0026quot;라서, 검증 가능한 증거 없이도 완료를 선언하기 쉽다. 핵심 해법: \u0026ldquo;규칙 문서\u0026quot;가 아니라 \u0026ldquo;실행 워크플로우\u0026quot;를 SKILL.md로 주입해 단계별 체크포인트와 종료조건을 강제한다. 구조화된 SDLC: /spec → /plan → /build → /test → /review → /ship (+ /code-simplify)로 사람의 시니어 프로세스를 복원한다. 실무 원칙 5가지: process over prose, anti-rationalization table, verification non-negotiable, progressive disclosure, scope discipline. 실행 메시지: 에이전트 시대일수록 \u0026ldquo;diff에 안 보이는 시니어 업무\u0026quot;를 시스템에 박아 넣어야 사고를 줄일 수 있다. 1) Skill의 본질: \u0026ldquo;지식\u0026quot;이 아니라 \u0026ldquo;행동 절차\u0026rdquo; 글에서 Skill은 단순 참고 문서가 아닙니다. 상황에 따라 에이전트 컨텍스트에 주입되는 **작업 절차(runbook)**에 가깝습니다.\n나쁜 예: 테스트 원칙 2,000자 설명문 좋은 예: 실패 테스트 작성 → 실패 확인 → 최소 구현 → 통과 확인 → 리팩토링 즉, 핵심은 **읽을거리(prose)**가 아니라 **실행 흐름(process)**입니다.\n2) Agent Skills가 인코딩한 SDLC 레포의 20개 스킬은 아래 6단계 라이프사이클로 조직됩니다.\nDefine (/spec) — 무엇을 만들지 명세 Plan (/plan) — 리뷰 가능한 단위로 분해 Build (/build) — 수직 슬라이스로 구현 Verify (/test) — 동작 증거 확보 Review (/review) — 품질·범위·리스크 점검 Ship (/ship) — 안전한 출시 여기에 /code-simplify가 전 단계에 걸쳐 복잡도 통제를 담당합니다.\n포인트는 간단합니다. 좋은 팀이라면 원래 하던 SDLC를 에이전트에게도 동일하게 강제해야 한다는 것입니다.\n3) 성능을 만드는 5가지 설계 원칙 (1) Process over prose 문장을 길게 쓰는 대신, 에이전트가 수행 가능한 순서를 제공해야 합니다.\n(2) Anti-rationalization table \u0026ldquo;이번 건은 작아서 스펙 불필요\u0026rdquo; 같은 자기합리화를 미리 반박 테이블로 넣습니다. 사람/에이전트 모두에게 효과적입니다.\n(3) Verification is non-negotiable 모든 단계의 종료조건을 증거 기반으로 둡니다. 테스트 통과, 빌드 로그, 리뷰 승인 등.\n(4) Progressive disclosure 초기에 모든 규칙을 다 넣지 않고, 현재 단계에 필요한 스킬만 로딩합니다. 토큰 낭비와 성능 저하를 막는 하네스 전략입니다.\n(5) Scope discipline \u0026ldquo;요청받은 것만 수정\u0026quot;을 강제합니다. 주변 리팩토링 확산을 막아 PR을 검토 가능하게 유지합니다.\n4) 왜 Google식 문화가 많이 보이는가 Addy는 공개된 Google 엔지니어링 실천을 다수 반영했다고 설명합니다.\nHyrum’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 핵심은 \u0026ldquo;새로운 이론\u0026quot;이 아니라, 원래 검증된 엔지니어링 규범을 에이전트 런타임으로 이식했다는 점입니다.\n5) 당장 가져갈 수 있는 실천 포인트 팀 AGENTS.md에 anti-rationalization 목록을 만든다. 내부 가이드는 에세이 대신 체크포인트형 워크플로우로 재작성한다. \u0026ldquo;완료\u0026rdquo; 정의에 항상 검증 증거 첨부를 넣는다. 규칙집은 크게 1권이 아니라, 라우팅되는 작은 챕터 집합으로 쪼갠다. 에이전트 운영 원칙으로 아래 5줄을 고정한다: 가정은 구현 전에 드러내기 요구사항 충돌 시 멈추고 확인하기 필요하면 반박하기 단순하고 지루한 해법 선호하기 요청 범위만 수정하기 결론 이 글의 요지는 \u0026ldquo;에이전트를 더 똑똑하게 만들자\u0026quot;가 아닙니다. 에이전트가 건너뛰기 쉬운 시니어 엔지니어링 절차를, 건너뛸 수 없게 시스템화하자입니다. 결국 경쟁력은 모델 성능 자체보다, spec/test/review/ship을 얼마나 일관되게 강제하는 하네스 설계에서 갈립니다.\n","wordCount":468,"tags":["AI","agent-skills","Addy Osmani","SDLC","프롬프트엔지니어링","코드리뷰","테스트"],"categories":["AI"],"frameworks":["Process over prose","Progressive disclosure","Verification-first SDLC"],"mental_models":["Anti-rationalization","Scope discipline","Code as liability"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전트는 기본적으로 '최단 경로로 끝내기'를 선호하므로 스펙·테스트·리뷰를 자동으로 생략한다","Skill은 문서가 아니라 '단계+검증+종료조건'을 가진 실행 워크플로우여야 한다","20개 스킬은 define→plan→build→verify→review→ship의 6단계 SDLC와 slash command로 구성된다","핵심 설계 원칙은 process over prose, anti-rationalization, verification, progressive disclosure, scope discipline","결론적으로 시니어 엔지니어링의 보이지 않는 작업을 에이전트가 건너뛰지 못하도록 하네스에 내장해야 한다"],"related":["posts/agentic-engineering-management","posts/agents-cant-choose-structure-flexibility","posts/probabilistic-engineering-24-7-employee"]}