EP11. 구조 기반 생성 스킬
Ep7부터 Ep10까지, 우리는 Cocrates의 내부 구조를 깊이 탐구했다. Agent가 어떻게 라우팅하는지, Skill이 어떻게 동작하는지, Architecture-Driven Generation의 원리와 Intent-To-Skill Routing의 메커니즘을 살펴봤다.
원리(Why)는 충분히 이해했다.
그렇다면 이제 질문이 바뀐다.
"원리는 알겠다. 그런데 Cocrates는 실제로 어떤 스킬들을 가지고 있고, 각각은 언제 어떻게 사용되는 걸까?"
오늘은 그 질문에 답한다. Ep11부터 Ep13까지는 구조 기반 생성 파이프라인을 구성하는 핵심 스킬들을 하나씩 해부한다. 오늘은 그중에서도 가장 중요한 4대 핵심 스킬과 전체 흐름을 조망한다.
🎯 "A를 생성해줘" — Cocrates의 내부 판단
Cocrates가 "A를 생성해줘"라는 요청을 받았을 때, 내부적으로 어떤 판단을 할까?
첫 번째 질문: "A를 생성하는 전용 스킬이 있는가?"
예를 들어, "블로그 시리즈를 생성해줘" 라고 요청했다면 blog-series-authoring 스킬이 있다. 있으면 그 스킬을 사용한다. 간단하다.
두 번째 질문: "전용 스킬이 없다면?"
이때 Cocrates는 spec-driven-generation이라는 범용 스킬로 폴백(fallback)한다. 이 스킬이 바로 구조 기반 생성 파이프라인의 핵심이다.
그런데 spec-driven-generation은 단순히 "자, 만들어!"가 아니다. 내부적으로 더 세밀한 판단을 한다.
세 번째 질문: "Spec이 명확한가?"
명확하지 않다면? 여기서부터 진짜가 시작된다. Cocrates는 사용자와 함께 다음 과정을 밟는다.
- ASR(Architecturally Significant Requirements) 식별 — 이 생성물의 구조에 영향을 미치는 핵심 요구사항이 무엇인지 찾는다.
- ADR 작성 — 각 ASR에 대해 후보 대안을 검토하고 결정을 내린다.
- Spec 작성 — 모든 ADR의 결정을 하나의 자체 완결적인 문서로 통합한다.
- Spec 완성 확인 — Spec이 충분히 구체화되었는지 검증한다.
- 비로소 생성 — Spec이 완성된 후에야 생성 단계로 넘어간다.
이 과정이 바로 Cocrates가 "일단 만들어 보고 보자"를 절대 허용하지 않는 이유다.
🏛️ 4대 핵심 스킬 — Cocrates 생성 엔진의 4개 기둥
Cocrates의 구조 기반 생성 파이프라인은 4개의 스킬로 구성된다. 이 4개가 Cocrates 생성 엔진의 핵심이다.
① adr-writing — 결정을 설계하라
ADR(Architecture Decision Record)은 단순한 의사결정 문서가 아니다. 하나의 Concern = 하나의 ADR이라는 원칙 아래, 설계 결정을 기록하고 감사 추적을 남긴다.
핵심 규칙:
- 최소 2~3개의 실질적 대안을 비교한다.
- 각 대안의 장단점을 명확히 분석한다.
- 상태는
proposed→ 승인 →approved로 전환된다. - 거절된 대안도 기록에 남긴다. *"왜 이 방법을 선택하지 않았는가"*가 미래의 소중한 자산이 된다.
왜 중요한가? ADR이 없으면 결정의 근거가 사라진다. 나중에 *"왜 이렇게 만들었지?"*라는 질문에 답할 수 없게 된다.
② spec-writing — 살아있는 명세서
Spec은 ADR의 결정을 통합한 자체 완결적인(Self-Contained) 문서다.
핵심 규칙:
- ADR 링크 금지. Spec 하나만 읽으면 전체를 이해할 수 있어야 한다. *"ADR 3번을 보세요"*는 안 된다.
- 검증 가능한 문장. *"성능이 좋아야 한다"*가 아니라 *"1초에 1000건의 요청을 처리해야 한다"*처럼 통과/실패를 판단할 수 있어야 한다.
- 살아있는 문서. 요구사항이 변하면 Spec도 변한다. Spec은 한 번 쓰고 버리는 문서가 아니다.
③ spec-driven-generation — Spec만이 유일한 근거
생성 단계의 철칙은 단 하나다. Spec만이 유일한 근거다.
Spec에 없는 내용은 생성하지 않는다. AI의 직감이나 경험으로 추가하지 않는다. Spec이 부족하면 Spec을 보강할 뿐, 임의로 생성하지 않는다.
이 철칙을 지키기 위해 Cocrates는 ASR Readiness Gate를 운영한다. 8가지 보편 범주를 점검하여 Spec이 충분히 준비되었는지 확인한다.
Spec > 프롬프트. 프롬프트가 아무리 정교해도 Spec을 대체할 수 없다. Spec은 검증 가능하고, 변경 이력이 있으며, 재현 가능하다. 프롬프트는 휘발성이다.
④ spec-driven-verification — 생성의 끝이 아니라 순환의 시작
검증은 단순한 테스트가 아니다. 두 가지 목적을 가진다.
목적 1 — Deviation 확인: 생성된 결과물이 Spec과 일치하는가? 일치하지 않는 부분(Deviation)을 찾아낸다.
목적 2 — Undocumented ASR 발견: Spec에 명시되지 않았지만 생성 결과에 구현된 구조적 결정을 찾아낸다. 이것은 실패가 아니다. 오히려 Spec을 더 완벽하게 만들 기회다.
그리고 검증이 끝난 후에도 사용자 검토 게이트가 기다린다. AI가 검증했다고 끝이 아니다. 사용자가 최종 승인해야 한다.
💡 오늘의 깨달음: 스킬은 AI의 전문화된 역할
Cocrates의 스킬 시스템을 이해하면서 얻는 가장 큰 깨달음은 이것이다.
스킬은 AI에게 전문화된 역할을 부여한다.
adr-writing이 있다는 것은 AI가 아키텍트로서 결정을 설계할 수 있다는 뜻이다.spec-writing이 있다는 것은 AI가 명세서 작성자로서 문서화할 수 있다는 뜻이다.spec-driven-generation이 있다는 것은 AI가 엔지니어로서 명세에 따라 구현할 수 있다는 뜻이다.spec-driven-verification이 있다는 것은 AI가 QA 엔지니어로서 검증할 수 있다는 뜻이다.
하나의 AI에게 모든 역할을 맡기는 것이 아니라, 역할별로 전문화된 스킬을 부여하고, 그 스킬이 정해진 절차에 따라 일한다. 이렇게 함으로써 일관된 품질과 예측 가능한 결과를 보장한다.
📌 오늘의 핵심
- Cocrates의 생성 파이프라인은 2단계 판단을 거친다. A 전용 스킬이 있는가? → 있다면 사용, 없다면 spec-driven-generation 폴백 → Spec이 명확한가? → 명확하지 않다면 ASR → ADR → Spec 작성 선행
- 4대 핵심 스킬이 생성 엔진의 4개 기둥이다. adr-writing(결정 설계), spec-writing(명세 통합), spec-driven-generation(명세 기반 생성), spec-driven-verification(검증과 순환)
- Spec > 프롬프트. 명세는 검증 가능하고, 변경 이력이 있으며, 재현 가능하다. 프롬프트는 휘발성이다.
스스로에게 질문하자.
- Cocrates의 4대 핵심 스킬을 말할 수 있는가?
- spec-driven-generation이 폴백으로 동작할 때의 내부 판단 과정을 설명할 수 있는가?
- Spec이 ADR 링크를 금지하는 이유는 무엇인가?
🎬 다음 편 예고
오늘 우리는 Cocrates가 어떤 스킬들로 구조 기반 생성 파이프라인을 구성하는지 전체를 조망했다.
그런데 한 가지 의문이 남는다.
"만약 내가 필요한 스킬이 Cocrates에 존재하지 않는다면 어떻게 해야 할까?"
예를 들어, "정기적인 코드 리뷰 리포트를 생성하는 스킬" 이 필요하다고 해보자. Cocrates에 그런 스킬은 없다. 어떻게 해야 할까?
다음 편, Ep12의 주제는 바로 이것이다. "스킬 자체가 없을 때, 스킬을 만드는 방법."
Cocrates는 이것을 위해 generating-skill-creation이라는 메타-스킬을 제공한다. 스킬을 만드는 스킬의 더 깊은 세계로, 다음 편에서 함께 들어가 보자.
이 시리즈는 Cocrates Harness 프레임워크를 소개합니다. Cocrates는 소크라테스식 대화로 사용자가 주도권을 잡고 성장하도록 설계된 에이전트 하네스입니다.