AI 코딩 에이전트를 위한 스킬 프레임워크(Skill frameworks)의 인기가 폭발적으로 증가하고 있습니다. 2026년 7월 기준으로, Superpowers는 약 256,000개의 GitHub 스타를 보유하고 있으며, Matt Pocock의 스킬은 약 176,000개, Agent Skills는 약 79,000개를 보유하고 있습니다. 이 세 가지 모두 구조화된 Markdown 지침을 에이전트에게 제공함으로써 AI 에이전트가 더 나은 코드를 작성할 수 있도록 하겠다고 약속합니다.

하지만 더 많은 관심을 기울여야 할 근본적인 문제가 있습니다. 이 프레임워크들의 행동 제어 계층(behavioral control layer)은 Markdown 파일에 작성된 평범한 영어(문학가들이

만약 스킬 파일에 구현 전에 반드시 테스트를 작성해야 한다와 같은 지침을 작성한다면(예시), 에이전트는 컴파일러가 타입 주석을 실행하는 방식대로 그 지침을 실행하지 않습니다. 대신, 에이전트는 그 지침을 확률적으로 해석합니다. 동일한 지침이라도 다른 실행에서, 다른 상황에서, 또는 에이전트가

Anti-rationalization tables (에이전트 기술(Agent Skills)에서 사용됨)은 흔히 발생하는 변명들을 사전에 반박함으로써 이 문제를 해결하려고 시도합니다. 하지만 그 반박(rebuttals) 역시 산문(prose)이며, 동일한 확률적 시스템에 의해 해석됩니다. 당신은 표류(drift)를 제거한 것이 아닙니다. 그 표류와 논쟁하기 위해 더 많은 산문을 추가했을 뿐입니다.

3. 상관된 검증기 실패 (Correlated Verifier Failure)

이것은 가장 날카로운 문제이며, 무시하기 가장 어려운 문제입니다.

대부분의 에이전트 프레임워크는 검증(verification) 단계를 포함합니다. 에이전트는 테스트를 실행하거나, 코드를 리뷰하거나, 기준에 따라 출력을 확인합니다. 하지만 검증 단계 역시 산문 형태의 지침을 읽는 LLM이라면, 당신의 검증기는 행위자(actor)와 동일한 표류의 영향을 받게 됩니다. 당신은 가드레일(guardrail)을 구축한 것이 아닙니다. 서로를 확인하는 두 명의 표류자를 만든 것입니다.

여기서 "상관된(Correlated)"이라는 의미는 행위자와 검증기가 동일한 실패 모드(failure modes)를 공유한다는 것을 뜻합니다. 즉, 동일한 모델, 동일한 프롬프트 컨텍스트(prompt context), 또는 목표에 대한 동일한 오해를 공유합니다. 그런 일이 발생하면, 그들은 틀린 정답에 대해 서로 동의할 것입니다. 검증기가 행위자와 동일한 방향으로 실패하기 때문에, 결코 오류를 잡아낼 수 없습니다. 이는 LLM-as-judge 평가에서 알려진 문제로, 판사(judge)와 피판사(judged)가 편향(biases)을 공유할 때 신뢰성 문제가 발생한다는 사실이 문서로 입증되어 있습니다.

이것이 산문 제어(Prose Control)가 무용하다는 뜻인가요?

아닙니다. 그리고 바로 이 지점에서 양극단의 견해를 모두 거부하는 것이 중요합니다.

결정론적 강제(Deterministic enforcement)는 전통적인 엔지니어링조차 충족하지 못하는 순수성 테스트입니다. 코드 리뷰(Code review)는 인간이 해석하는 프로세스입니다. QA 테스트도 오류가 있을 수 있습니다. CI 파이프라인은 잡아야 하는 것이 아니라, 잡도록 설정된 것을 잡습니다. 피처 플래그(Feature flags)는 잘못 설정될 수 있습니다. 이 중 어느 것도 형식적으로 검증(formally verified)된 것이 없습니다. 우리가 이것들을 사용하는 이유는 그것들이 수학적 보증을 제공하기 때문이 아니라, 오류를 잡아낼 확률을 올바른 방향으로 이동시키기 때문입니다.

스킬 프레임워크 (Skill frameworks) 역시 다른 계층에서 동일한 일을 수행합니다. 만약 TDD 스킬이 에이전트가 테스트를 작성할 확률을 낮음에서 높음으로 이동시킨다면, 그것은 의미 있는 개선입니다. 그것이 보증(guarantee)은 아닙니다. 하지만 인간의 코드 리뷰 준수(compliance) 또한 보증은 아닙니다. 문제는 그 확률의 이동이 토큰 오버헤드 (token overhead)를 정당화할 수 있는지이며, 이 질문은 아직 경험적으로 답변되지 않았습니다.

정직한 주장은 더 좁습니다: 산문 기반의 제어 (prose-based control)는 프로덕션 시스템 (production systems)을 위해 유용하지만 불충분하다는 것입니다. 그것은 확률 분포를 유용한 방향으로 이동시키지만, 보증을 제공하지는 않습니다.

Anthropic이 실제로 권장하는 것

Anthropic의 자체 가이드인 Building Effective Agents가 여기서 시사하는 바가 큽니다. 그들의 핵심 권장 사항은 대부분의 스킬 프레임워크가 하는 일과 정반대입니다:

"우리는 가능한 한 가장 단순한 해결책을 찾고, 필요할 때만 복잡성을 높일 것을 권장합니다. 이는 에이전트 시스템을 아예 구축하지 않는 것을 의미할 수도 있습니다."

그들은 잘 정의된 작업(well-defined tasks)에 대해서는 에이전트(자율적이고 모델 주도적인 루프)보다 워크플로우(예측 가능하고 결정론적인 파이프라인)를 선호한다고 설명합니다. 그들은 특히 다음과 같이 경고합니다: "에이전트 시스템은 종종 더 나은 작업 성능을 위해 지연 시간(latency)과 비용을 희생하며, 이러한 트레이드오프 (tradeoff)가 언제 타당한지 고려해야 합니다."

최첨단 성능을 달성한 그들의 SWE-bench 에이전트는 의도적으로 스캐폴딩 (scaffolding)을 최소한으로 유지했습니다. 프롬프트는 짧았습니다. 모델에게는 도구와 스스로의 접근 방식을 선택할 자유가 주어졌습니다. 그들은 산문 형태의 지침을 쌓아 올리지 않았습니다. 모델에게 명확한 목표와 명확한 도구를 제공하고, 모델이 작동하게 두었습니다.

이는 "모든 것을 Markdown으로 인코딩하라"는 철학과 정반대입니다. Anthropic의 자체적인 증거는 산문이 많아지는 것이 아니라, 적을수록 더 나은 에이전트 행동을 만들어낸다는 것을 시사합니다.

실제 가드레일 (Guardrails)의 모습

이 비판은 실질적인 격차를 드러냅니다. 현재의 프레임워크들은 행동 제어를 위해 산문 (Prose)에 의존하고 있습니다. 드리프트 (Drift)와 재해석에 대응하는 실제 가드레일 (Guardrails)을 원한다면, 확률적 계층 (Probabilistic layer) 위에 결정론적 메커니즘 (Deterministic mechanisms)을 계층화해야 합니다. 실제 사례는 다음과 같습니다.

컴파일된 스키마 검증 (Compiled schema validation). 에이전트에게 "이 필드들을 포함한 유효한 JSON 객체를 반환해"라고 말하는 대신, API 경계에서 JSON 스키마 강제 (JSON Schema enforcement)를 사용하십시오. 에이전트는 유효한 JSON을 반환하거나 에러를 받게 됩니다. 여기에는 산문에 의한 해석이 개입되지 않습니다. Spring AI의 validateSchema()가 정확히 이 역할을 수행합니다. 이는 컴파일된 스키마를 바탕으로 응답을 검증하고, 에러를 모델에 다시 전달하여 재시도하게 합니다.

경계에서의 타입 체크 (Type checking at boundaries). 에이전트가 코드를 작성한다면, 타입 체커 (Type checker)는 결정론적인 게이트 (Gate) 역할을 합니다. 타입이 통과하지 못하면 코드는 병합되지 않습니다. 이는 에이전트의 해석과는 독립적입니다. TypeScript, Java의 컴파일러, Rust의 소유권 검사기 (Borrow checker) 등이 이에 해당합니다. 이들은 확률적이지 않기 때문에 진정한 가드레일입니다.

독립적인 검증 도구로서의 테스트 스위트 (Test suites as independent verifiers). 잘 작성된 테스트 스위트는 결정론적인 명세 (Specification)입니다. 에이전트의 코드가 테스트를 통과하면 명세를 충족하는 것이고, 실패하면 충족하지 못하는 것입니다. 핵심은 테스트가 코드를 작성한 동일한 에이전트에 의해 생성되는 것이 아니라, 에이전트의 구현과 독립적으로 작성되어야 한다는 점입니다. CI에서 실행되며 스킬(Skills)이 올바르게 라우팅되는지 확인하는 Agent Skills의 평가 프레임워크 (Eval framework)는 이 방향으로 나아가는 단계입니다. 하지만 이는 에이전트의 출력이 아닌 스킬을 테스트하는 것입니다.

불변의 감사 로그 (Immutable audit logs). 에이전트가 자신이 무엇을 했는지 보고하는 것에 의존하는 대신, 모든 도구 호출 (Tool call), 모든 파일 변경, 모든 명령 실행을 추가 전용 로그 (Append-only log)에 기록하십시오. 이것이 드리프트 (Drift)를 방지하지는 못하지만, 사후에 드리프트를 감지할 수 있게 해줍니다. 에이전트가 수행했다고 말한 내용과 실제로 수행한 내용을 비교(Diff)할 수 있습니다.

중요 경로(Critical paths)를 위한 Non-LLM 검증기(Verifiers). 프로덕션 시스템을 위한 가장 실용적인 접근 방식은 다음과 같습니다: 패턴 매칭(Pattern matching)과 연구에는 LLM을 사용하되, 중요한 동작을 자율적으로 실행하게 해서는 절대 안 됩니다. LLM은 제안(Propose)하고, 결정론적 시스템(Deterministic system)이 처리(Dispose)합니다. 거래 실행, 코드 병합(Code merge), 또는 프로덕션 배포(Production deployment)의 경우, 최종 결정은 LLM에 의해 주도되어서는 안 됩니다.

솔직한 평가

AI 에이전트 프레임워크를 둘러싼 논쟁에는 두 가지 극단이 있으며, 둘 다 틀렸습니다.

극단 1: "산문 제어(Prose control)가 곧 엔지니어링이다." 전통적인 정의에 따르면 그렇지 않습니다. 엔지니어링은 재현성(Reproducibility), 검증 가능성(Verifiability), 그리고 독립적인 강제성(Independent enforcement)을 요구합니다. 산문 형태의 지침은 이 중 어느 것도 제공하지 않습니다. 마크다운(Markdown) 파일의 집합을 "소프트웨어 개발 방법론(Software development methodology)"이라고 부르는 것은 "방법론"이라는 단어의 의미를 한계치까지 늘리는 것입니다.

극단 2: "산문 제어는 쓸모없다." 그렇지 않습니다. 이는 확률론적 시스템(Probabilistic systems)을 조종하기 위한 불완전하지만 유용한 접근 방식입니다. 구성 관리(Configuration management)가 결정론적 시스템(Deterministic systems)을 조종하기 위한 불완전하지만 유용한 접근 방식인 것과 같습니다. "유용함"과 "충분함" 사이의 간극이 바로 실제 작업이 이루어져야 하는 지점입니다.

솔직한 입장은 다음과 같습니다: 현재 존재하는 스킬 프레임워크(Skill frameworks)는 프로덕션 엔지니어링이 아니라 R&D 도구입니다. 이들은 확률 분포를 유용한 방향으로 이동시킵니다. 하지만 보장(Guarantees)을 제공하지는 않습니다. 인간의 검토가 남은 실패를 잡아낼 수 있는 작업에는 사용할 가치가 있습니다. 하지만 관리되지 않은 채 실행되는 작업에는 위험합니다.

살아남을 프레임워크는 산문 계층(Prose layer)과 함께 결정론적 가드레일(Deterministic guardrails)(타입 체크(Type checking), 컴파일된 스키마(Compiled schemas), CI 게이트(CI gates), 독립적인 테스트 스위트(Independent test suites), 불변 로그(Immutable logs))을 일급 시민(First-class citizens)으로 통합하는 프레임워크가 될 것입니다. 산문은 에이전트에게 무엇을 시도할지 알려줍니다. 결정론적 계층은 무엇이 허용 가능한지를 강제합니다. 이러한 통합이 존재하기 전까지, 이를 "엔지니어링"이라고 부르는 것은 희망 사항에 불과합니다.

출처:

출처:

• Building Effective Agents - Anthropic
• Raising the Bar on SWE-bench Verified with Claude 3.5 Sonnet - Anthropic
• Superpowers - GitHub (obra/superpowers)
• Agent Skills - GitHub (addyosmani/agent-skills)
• Matt Pocock's Skills - GitHub (mattpocock/skills)