에이전트 스킬
TMT시니어 엔지니어의 일 대부분은 diff에 드러나지 않는 부분입니다. 스펙. 테스트. 리뷰. 스코프 관리. 검증할 수 없는 것은 출시를 거부하는 태도. AI 코딩 에이전트는 기본적으로 이런 부분을 건너뜁니다. Agent Skills는 이 부분을 선택 사항이 아니게 만들기 위한 제 시도입니다.
어떤 AI 코딩 에이전트든 기본 동작은 “완료”까지 가는 가장 짧은 경로를 택하는 것입니다. 기능을 요청하면, 그 기능을 구현해 줍니다. 스펙이 있는지 묻지 않고, 구현 전에 테스트를 작성하지도 않고, 변경이 신뢰 경계를 넘는지 고민하지도 않으며, PR을 리뷰어가 어떻게 볼지 살피지도 않습니다. 코드를 만들어내고, 끝났다고 선언한 뒤, 다음으로 넘어갑니다.
이건 시니어 엔지니어라면 누구나 커리어 내내 피하는 법을 배워온 실패 패턴과 같습니다. 어떤 작업이든 시니어 버전에는 diff에 드러나지 않는 일이 포함됩니다. 가정사항을 드러내고, 스펙을 작성하고, 작업을 리뷰 가능한 덩어리로 쪼개고, 지루한 설계를 택하고, 결과가 옳다는 증거를 남기고, 사람이 실제로 리뷰할 수 있을 정도의 크기로 변경을 잘라내는 일들 말입니다. 이런 단계들이야말로 신뢰할 수 있는 소프트웨어를 규모 있게 배포하는 엔지니어와, 장애를 일으키는 코드를 밀어 넣는 사람을 가르는 핵심입니다.
에이전트가 이런 단계를 건너뛰는 이유는, 주니어가 그럴 법한 이유와 같습니다. 눈에 잘 보이지 않기 때문입니다. 보상 신호는 “작업 완료”에 꽂혀 있지, “작업 완료 + 설계 문서 존재”에는 꽂혀 있지 않습니다. 그래서 우리는 시니어 엔지니어가 두르는 비계(scaffolding)를 다시 덧대야 합니다.
Agent Skills는 제가 생각한 그 비계입니다. 방금 26K 스타를 넘겼으니, 저만 이런 걸 원했던 건 아닌 것 같습니다. 이 글은 README에서 충분히 다루지 못한 부분, 즉 각 설계 선택이 존재하는 이유, 그것이 표준 SDLC와 구글이 공개한 엔지니어링 관행에 어떻게 대응되는지, 그리고 설령 단 하나의 스킬도 설치하지 않더라도 여러분이 이 프로젝트에서 무엇을 가져가야 하는지에 대해 다룹니다.
“스킬”이 실제로 의미하는 것
Claude Code / Anthropic 문맥에서 “스킬(skill)”이라는 단어는 꽤 많은 역할을 맡고 있어서, 정확히 짚고 넘어가는 게 좋습니다. 스킬은 상황에 맞을 때 에이전트 컨텍스트에 주입되는 프론트매터가 달린 마크다운 파일입니다. 시스템 프롬프트 조각과 런북(runbook) 사이 어디쯤에 위치한 존재죠.
스킬은 레퍼런스 문서가 아닙니다. “테스트에 대해 알아야 할 모든 것” 같은 내용을 때려 넣는 자리가 아닙니다. 스킬은 워크플로입니다. 에이전트가 따르는 일련의 단계이며, 증거를 남기는 체크포인트가 있고, 명확한 종료 조건으로 끝나는 절차입니다.
이 구분이 전부라고 해도 과언이 아닙니다. 테스트 모범 사례를 2,000단어짜리 에세이로 써서 에이전트 컨텍스트에 넣으면, 에이전트는 그걸 읽고 그럴싸한 텍스트를 생성한 뒤 실제 테스트는 건너뜁니다. 반대로 워크플로를 넣으면(실패하는 테스트를 먼저 쓰고, 실행해서 깨지는 걸 확인하고, 통과에 필요한 최소한의 코드를 작성하고, 다시 실행해 통과를 확인한 뒤, 리팩터링하는 식으로), 에이전트가 실제로 수행할 일이 생기고, 여러분은 그 결과를 검증할 수 있는 단서를 얻게 됩니다.
프로세스를 글보다 앞에 둘 것. 레퍼런스가 아닌 워크플로. 종료 조건이 있는 단계 vs 그런 거 없는 에세이. 이 작은 차이가 쓸모 있는 스킬과 그럴듯한 마크다운 파일을 가르는 기준입니다. 그리고 이건 왜 수많은 “AI rules” 레포들이 실제 현장에서는 아무 일도 하지 못하고 끝나는지 설명해 주기도 합니다. 그 “룰”들이 사실상 전부 에세이이기 때문입니다.
스킬들이 인코딩하고 있는 SDLC
레포에 있는 스킬 20개는 여섯 개의 라이프사이클 단계에 맞춰 정리되어 있고, 그 위에 일곱 개의 슬래시 커맨드가 올라가 있습니다. Define(/spec) 단계에서 “무엇을 만들지”를 결정합니다. Plan(/plan)은 작업을 쪼개는 단계입니다. Build(/build)는 기능을 세로 슬라이스로 구현합니다. Verify(/test)는 제대로 동작하는지 증명합니다. Review(/review)는 그 사이로 빠져나간 것들을 잡아냅니다. Ship(/ship)은 안전하게 사용자에게 전달하는 단계입니다. /code-simplify는 전체를 관통하는 역할을 합니다.
이건 우연이 아닙니다. 제대로 돌아가는 모든 엔지니어링 조직이 돌리고 있는 SDLC와 사실상 같습니다. 쓰는 단어만 조금 다를 뿐입니다. 구글은 이를 디자인 문서 → 리뷰 → 구현 → 가독성 리뷰 → 런치 체크리스트라고 부릅니다. 아마존은 “워킹 백워즈(working backwards) 메모와 바 레이저(bar raiser)”라는 이름을 씁니다. 건강한 팀이라면 어디나 이런 루프를 자기 언어로 갖고 있습니다.
AI 코딩 에이전트에서 새로워진 점은, 대부분의 에이전트가 기본값으로 이 단계들 대부분을 건너뛴다는 사실입니다. 기능을 요청하면 구현을 받고, 스펙, 플랜, 테스트, 리뷰, 런치 체크리스트는 아예 생기지 않습니다. 스킬은 시니어 엔지니어가 스스로를 밀어 넣는 그 단계들을 에이전트도 밟게 만드는 장치입니다. 이 단계를 건너뛰고 코드를 배포하는 순간 사고가 나는 거니까요.
복잡한 기능 하나를 구현하는 데 최대 열한 개의 스킬이 순서대로 동작할 수 있습니다. 작은 버그 픽스라면 세 개 정도만 쓰일 수도 있죠. 어떤 스킬이 적용될지는 라우터(using-agent-skills)가 결정합니다. 중요한 건 이 워크플로가 “추측한 스코프”가 아니라 “실제 스코프”에 맞춰 확장된다는 점입니다.
실제로 일을 하는 다섯 가지 원칙
이 프로젝트에서 진짜 하중을 떠받치는 설계 결정은 다섯 가지입니다. 나머지 시스템은 전부 여기서 파생됩니다.
1. 글보다 프로세스
이미 이야기했습니다. 워크플로는 에이전트가 실제로 행동에 옮길 수 있지만, 에세이는 그렇지 않습니다. 인간 팀에서도 마찬가지입니다. 팀 핸드북이 200페이지라면, 시간에 쫓기는 상황에서 그걸 읽을 사람은 없을 겁니다. 반대로 소수의 워크플로와 체크포인트로 정리되어 있다면, 사람들은 실제로 그걸 돌립니다.
2. 합리화 방지 테이블(Anti-rationalization tables)
이 프로젝트에서 가장 독특한 설계이자, 제가 다른 팀들이 꼭 가져갔으면 하는 부분입니다.
각 스킬에는, 에이전트(혹은 지친 엔지니어)가 워크플로를 건너뛰기 위해 늘어놓을 만한 흔한 변명들과, 거기에 대응하는 반박이 표 형태로 들어 있습니다. 원본에 가깝게 몇 가지 예를 들어 보겠습니다.
- “이 작업은 너무 단순해서 스펙이 필요 없어요.” → 그래도 수용 기준(acceptance criteria)은 필요합니다. 다섯 줄이면 충분하죠. 0줄은 안 됩니다.
- “테스트는 나중에 쓸게요.” → “나중에”라는 말이 문제의 핵심입니다. 그 “나중”은 오지 않습니다. 실패하는 테스트를 먼저 쓰세요.
- “테스트도 다 통과했는데, 그냥 배포하죠.” → 통과한 테스트는 증거이지, 증명이 아닙니다. 런타임은 확인했나요? 사용자 관점에서의 동작은 검증했나요? 사람이 직접 diff를 읽어봤나요?
이게 통하는 이유는, LLM이 합리화에 정말 능하기 때문입니다. 모델은 “이 특정 작업에는 굳이 스펙이 필요 없는 이유”나, “이번 변경은 리뷰 없이 머지해도 괜찮은 이유”를 그럴듯하게 설명하는 문단을 얼마든지 만들어 냅니다. 합리화 방지 테이블은, 에이전트가 아직 입 밖에 꺼내지도 않은 거짓말에 대해 미리 써 둔 반박입니다.
이 패턴은 인간 팀에도 똑같이 유용합니다. 대부분의 엔지니어링 퇴행(engineering decay)은 누군가 “대충 하자”고 작정해서 생기지 않습니다. 그보다는 사람들이 “하기 싫은 부분을 건너뛰어도 될 것 같은, 그럴싸한 핑계”를 받아들이면서 생깁니다. 팀이 자기들의 합리화를 문서화해 두면, 그런 합리화가 줄어듭니다.
3. 검증(Verification)은 협상 불가
모든 스킬은 구체적인 증거로 끝납니다. 테스트가 통과했다. 빌드 아웃풋이 깨끗하다. 런타임 트레이스가 기대한 동작을 보여준다. 리뷰어가 승인했다. 이런 것들입니다. *“대충 맞는 것 같다”*는 언제나 불충분한 결론입니다.
이건 Anthropic의 하니스(harness)가 실패에서 복구할 수 있게 만드는 같은 원칙이며, Cursor의 planner/worker/judge 분리가 실제로 버그를 잡아내게 하는 원칙이기도 하고, 어떤 장기 실행 에이전트든 복구 가능하게 만드는 원칙이기도 합니다. 에이전트는 생성기(generator)에 불과합니다. 작업이 끝났다는 사실을 알려 줄 별도의 신호가 필요합니다. 스킬은 이 신호를 모든 워크플로 안에 녹여 둡니다.
4. 점진적 공개(Progressive disclosure)
세션 시작 시점에 스킬 20개 전부를 컨텍스트에 한꺼번에 올리지 마세요. 현재 단계에 따라 필요한 스킬만 활성화해야 합니다. 작고 메타한 스킬 하나(using-agent-skills)가 라우터 역할을 하며, 지금 작업에 어떤 스킬이 적용될지를 결정합니다.
이건 하니스 엔지니어링의 교훈을 스킬 단위로 적용한 것입니다. 컨텍스트에 올라가는 토큰 하나하나는 어딘가의 성능을 조금씩 떨어뜨립니다. 따라서 지금과 관련 있는 것만 불러오고, 나머지는 디스크에 둡니다. 점진적 공개는 5K 토큰짜리 슬롯 안에 스킬 20개짜리 라이브러리를 집어넣으면서도, 모델 품질을 망치지 않는 방법입니다.
5. 스코프 규율(Scope discipline)
메타 스킬에는 제가 가능하다면 모든 에이전트에 기본값으로 박아 두고 싶은 규칙이 들어 있습니다. “요청받은 것만 건드려라.” 인접한 시스템을 멋대로 리팩터링하지 말 것. 충분히 이해하지 못한 코드를 삭제하지 말 것. TODO를 지나가다 보였다고 파일 전체를 갈아엎지 말 것.
말로 하면 너무 당연해 보이지만, 실제로 에이전트가 “버그 하나를 고친다”면서 관련 없는 파일 세 개를 현대화하겠다고 나서는 장면을 보고 나면, 이게 결코 자명한 문제가 아니라는 걸 알게 됩니다. 스코프 규율은 에이전트가 만든 PR이 실제로 머지 가능한지, 아니면 되돌려야 하는지의 가장 큰 분기점입니다. 그리고 이 원칙은 구글의 코드 리뷰 규범과도 그대로 맞닿아 있습니다. 구글에서는 “한 PR에 여러 일을 섞었다”는 이유만으로도 리뷰어가 PR을 막을 수 있습니다.
구글 DNA
이 스킬들은 Software Engineering at Google과 구글의 공개 엔지니어링 문화에서 나온 관행들로 꽉 차 있습니다. 의도적인 선택입니다. 구글 규모의 소프트웨어를 가능하게 만드는 것들 상당수는 이미 문서화되어 있고 공개돼 있습니다. 그리고 그건 에이전트가 가장 먼저 건너뛰기 쉬운 부분이기도 합니다.
각 스킬이 어떤 관행을 인코딩하고 있는지, 일부만 짚어 보겠습니다.
api-and-interface-design에는 Hyrum’s Law가 녹아 있습니다. API의 관찰 가능한 모든 동작은 언젠가 누군가에 의해 의존될 것이니, 그 전제를 깔고 설계해야 한다는 법칙이죠.test-driven-development에는 **테스트 피라미드(~80/15/5)와 비욘세 법칙(Beyoncé Rule)**이 담겨 있습니다. “마음에 들었다면, 테스트를 붙였어야지.” 인프라 변경만으로는 버그를 잡을 수 없습니다. 버그를 잡는 건 테스트입니다.- 테스트에서는 DRY보다 DAMP를 택합니다. 구글의 테스트 철학은, 어느 정도의 중복을 감수하더라도 테스트 코드는 사양(spec)처럼 읽혀야 한다고 분명히 말합니다. 지나치게 추상화된 테스트 코드는 잘 알려진 안티 패턴입니다.
code-review-and-quality에는 약 100줄 단위의 PR 사이즈와 Critical / Nit / Optional / FYI 심각도 레이블이 들어 있습니다. 구글의 코드 리뷰 규범에서 그대로 가져온 것입니다. PR이 너무 크면, 제대로 리뷰되지 않고 통째로 도장만 찍힙니다.code-simplification에는 **체스터턴의 울타리(Chesterton’s Fence)**가 들어 있습니다. 왜 세워졌는지 이해하기 전에는 울타리를 치우지 말라는 원칙이죠.git-workflow-and-versioning에는 **트렁크 기반 개발(trunk-based development)과 원자적 커밋(atomic commits)**이 담겨 있습니다.ci-cd-and-automation에는 **Shift Left와 기능 플래그(feature flags)**가 들어 있습니다. 문제는 가능한 한 빨리 잡고, 배포와 릴리스를 분리하라는 원칙입니다.deprecation-and-migration에는 코드는 자산이 아니라 부채라는 관점이 녹아 있습니다. 남겨 둔 한 줄, 한 줄이 앞으로도 계속 유지보수해야 할 대상이 되기 때문에, 표면적 크기를 줄이는 쪽을 택하라는 뜻입니다.
이 중 어느 것도 새로운 아이디어는 아닙니다. 포인트는, 이런 것들이 에이전트의 기본값에는 들어 있지 않다는 점입니다. 프런티어 모델은 학습 데이터 어딘가에서 “Hyrum’s Law”라는 문구를 분명히 봤겠지만, 그렇다고 해서 새벽 3시에 여러분의 API를 설계할 때 그 법칙을 자동으로 적용해 주지는 않습니다. 스킬은 그 법칙을 실제 설계 자리에서 강제로 끌어다 쓰게 만드는 장치입니다.
실제로 어떻게 써야 할까
대략 세 가지 모드가 있고, 커밋 수준이 커질수록 숫자가 커집니다.
모드 1: 마켓플레이스에서 설치하기. Claude Code를 쓰고 있다면 다음과 같습니다.
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills이렇게 하면 /spec, /plan, /build, /test, /review, /ship, /code-simplify 같은 슬래시 커맨드를 쓸 수 있고, 에이전트가 컨텍스트를 기반으로 알아서 적절한 스킬을 활성화합니다. 대부분의 사람에게는 이 경로로 시작하는 걸 추천합니다.
모드 2: 원하는 도구에 마크다운 그대로 넣기. 스킬은 프론트매터가 있는 평범한 마크다운 파일입니다. Cursor 사용자는 .cursor/rules/에 파일을 넣습니다. Gemini CLI도 나름의 설치 방식이 있습니다. Codex, Aider, Windsurf, OpenCode, 시스템 프롬프트를 받을 수 있는 어떤 도구든 이 파일을 읽을 수 있습니다. 중요한 건 도구가 아니라 그 아래에서 돌아가는 워크플로입니다.
모드 3: 스펙처럼 읽기. 설치를 전혀 하지 않더라도, 스킬들은 “AI 에이전트와 함께 좋은 엔지니어링을 한다는 게 무엇인지”를 문서화한 스펙입니다. code-review-and-quality.md를 읽고, 거기에 나오는 다섯 축 프레임워크를 팀의 코드 리뷰 프로세스에 적용해 보세요. test-driven-development.md를 읽고, “정말 테스트를 먼저 써야 하냐”를 두고 주니어와 벌어지는 다음 논쟁을 정리해 보세요. 메타 스킬을 읽고, 거기 나오는 다섯 가지 “협상 불가” 항목을 그대로 여러분의 AGENTS.md에 베껴 넣으세요.
개인적으로 이 세 번째 모드에서 시작하는 걸 권합니다. 지금 팀이 겪는 고통과 가장 가까운 스킬 네다섯 개를 고르세요. 어떤 워크플로를 “반드시 지켜야 할 것”으로 만들지 정하고, 그다음에 런타임을 설치하든, 직접 구현하든, 그 워크플로가 지켜지게 만드는 쪽으로 움직이면 됩니다.
설치하지 않더라도 가져갈 만한 것들
AI 코딩 에이전트를 아예 쓰지 않더라도, 이 프로젝트에서 꼭 챙겨 갔으면 하는 패턴 몇 가지가 있습니다.
팀 차원의 합리화 방지(Anti-rationalization) 연습. 팀이 스스로에게 들려주는 거짓말들을 적어 두세요. “출시만 하고 테스트는 나중에 고치자.” “이 정도 변경에 디자인 문서까지는 과하잖아.” “모니터링도 있는데 뭐.” 그리고 각각에 대응하는 반박을 짝지어 두세요. 이걸 AGENTS.md나 엔지니어링 위키에 넣어 두면, 논쟁 거리가 줄어들고, 금요일 오후에 피곤한 상태로 내리려던 “한 번만 대충 하자” 결정을 한 번 더 걸러 줄 겁니다.
내부 문서에는 글보다 프로세스를. “우리가 X를 어떻게 하는지”라는 제목으로 2,000단어짜리 문서를 쓰고 있다면, 지금 여러분이 쓰고 있는 건 레퍼런스입니다. 그걸 체크포인트가 있는 워크플로로 바꾸세요. 문서 분량은 400단어 정도로 줄어들 것이고, 사람들은 실제로 그걸 실행할 겁니다. 온보딩 가이드, 런북, 에이전트 스킬을 막론하고 내부 문서라면 어디든 적용되는 이야기입니다.
검증을 “작업 종료”의 하드 조건으로 만들기. 에이전트, 엔지니어, 자기 자신 모두에게 “증거를 남기는 것”을 모든 작업의 마지막 단계로 삼으세요. 증거는 작업이 끝났다는 걸 보여 주는 그 무엇이든 됩니다. 초록불 테스트 실행 결과, 스크린샷, 로그, 리뷰 승인 등. 이게 없으면, 그 작업은 끝난 게 아닙니다. *“대충 맞는 것 같아 보여서”*는 절대 루프를 닫는 조건이 될 수 없습니다.
어떤 룰북이든 점진적으로 공개되게 만들기. 50페이지짜리 핸드북을 쓰지 마세요. 상황에 따라 그때그때 맞는 짧은 챕터로 안내해 주는 작은 라우터를 쓰세요. AGENTS.md든, 런북이든, 인시던트 플레이북이든, “압박이 큰 상황에서 누군가가 실제로 읽어야 하는 문서”라면 모두 여기에 해당합니다.
메타 스킬에서 그대로 가져올 만한 다섯 가지 협상 불가 항목. 제가 어떤 AGENTS.md에도 당장 넣고 싶은 문장들입니다.
- 만들기 전에 가정사항을 드러낼 것. 묵묵히 잘못된 가정을 품고 가는 것이 가장 흔한 실패 패턴입니다.
- 요구사항이 충돌하면 멈추고 질문할 것. 추측하지 말 것.
- 필요하다면 반대 의견을 낼 것. 에이전트(든, 엔지니어든)는 예스맨이 아닙니다.
- 똑똑해 보이는 해법보다 지루하고 자명한 해법을 택할 것. 영리함은 비싼 자원입니다.
- 요청받은 것 외에는 건드리지 말 것.
이 다섯 줄이면 괜찮은 엔지니어링 문화의 밑그림은 그려집니다. 어떤 걸 설치하든 말든, 이건 바로 가져다 쓸 수 있습니다.
하니스 안에서의 위치
더 넓게 보면, 스킬은 에이전트 하니스 엔지니어링의 한 레이어입니다. 하니스는 모델과, 그 모델을 둘러싸고 여러분이 구축하는 모든 것까지를 포함합니다. 스킬은 그중에서 재사용 가능한 워크플로 덩어리로, 점진적으로 시스템 프롬프트 안에 펼쳐지는 형태를 띱니다. AGENTS.md(계속 업데이트되는 룰북), 훅(hooks: 결정론적으로 규칙을 강제하는 레이어), 툴(에이전트가 실제로 취할 수 있는 액션), 세션 로그(지속 가능한 메모리)와 나란히 서 있는 구성 요소죠. 각 레이어에는 맡은 일이 있습니다. 스킬은 그중 “시니어 엔지니어의 프로세스” 역할을 담당합니다.
스킬의 중요성은 장기 실행 에이전트에서 훨씬 커집니다. 채팅 스타일 에이전트보다 말이죠. 러닝 타임이 길어질수록, 작은 지름길 하나가 키워 내는 문제도 같이 커지기 때문입니다. 10분짜리 세션에서 테스트를 건너뛴 에이전트는 버그 하나를 남깁니다. 30시간짜리 세션에서 테스트를 건너뛴 에이전트는, 런 끝자락에 “도대체 처음에 무얼 하려던 거였지?”라는 상태에서 파헤쳐야 하는 디버깅 발굴 작업을 남깁니다. 러닝 타임이 길어질수록, 시니어 엔지니어의 비계를 “권장 사항”이 아니라 “강제 사항”으로 만드는 게 중요해집니다.
스킬 포맷의 이식성도 의미가 있습니다. 동일한 SKILL.md 파일 하나가 Claude Code, Cursor(규칙으로), Gemini CLI, Codex, 그리고 시스템 프롬프트 컨텐츠를 받는 어떤 하니스에서도 그대로 동작합니다. 워크플로는 한 번만 쓰고, 실행 환경이 그걸 강제하게 만들 수 있습니다. 이게 프론트매터가 달린 마크다운 포맷이, 일회성 프롬프트 엔지니어링으로는 얻을 수 없는 이점입니다.
맺으며
제가 이 프로젝트에서 사람들이 가장 가져갔으면 하는 건, 스킬 그 자체보다도 이 프레이밍입니다.
AI 코딩 에이전트는 “diff에는 드러나지 않는 일에 대한 본능이 전혀 없는, 엄청나게 유능한 주니어 엔지니어”입니다. 가정사항을 드러내고, 변경 크기를 조절하고, 스펙을 쓰고, 증거를 남기고, 리뷰할 수 없는 변경은 머지하지 않겠다고 버티는 그 시니어스러운 일들은, 에이전트가 특별히 못해서가 아니라 여러분이 “건너뛰지 못하게 만들어 주지 않으면” 당연히 건너뛰게 되어 있는 부분입니다. 우리의 일은, 점점 더, 이 규율을 에이전트가 스스로 포기할 수 없도록 인코딩해 두는 쪽으로 옮겨가고 있습니다.
스킬은 그 방법 중 하나의 모양입니다. 합리화 방지 테이블. 점진적 공개. 글이 아니라 프로세스. 종료 조건으로서의 검증. 이미 효과를 검증한 구글식 관행들을 휴대 가능한 형태로 옮겨 둔 것들.
여러분은 제가 만든 버전을 그대로 설치해도 되고, 직접 버전을 만들어도 됩니다. 어느 쪽이든 교훈은 같습니다. 시니어 엔지니어가 맡아온 일의 핵심은 이제 선택 사항이 아니며, 그 “엔지니어”가 인간이든 모델이든 마찬가지라는 점입니다.
레포는 github.com/addyosmani/agent-skills에 있습니다(MIT). 더 넓은 비계 그림은 Agent Harness Engineering과 Long-running Agents를 참고하세요.