EP10. 구조 기반 생성 원리
Ep8과 Ep9에서 우리는 Learning Pipeline의 철학과 스킬을 살펴봤다. Education → Knowledge Capture → Reflection. 질문으로 배우고, 무지를 기록하고, 면접관이 확인하는 순환.
이제 Cocrates의 두 번째 핵심 활동으로 넘어간다. Artifact Generation Pipeline — 구조 기반 산출물 생성.
기억하자. 기본적으로 AI가 작업을 수행한다. 그리고 당신은 **AI-native Engineer(팀장)**로서 AI가 만들어 낸 결과를 검토하고 결정하는 사람이다. AI가 모든 것을 대신해 주는 시대에, 당신의 가치는 'AI가 하는 일을 얼마나 잘 검토하고, 판단하고, 결정하느냐'에 달려 있다.
Learning이 "무지를 인식하고 지식을 확장하는 방법"이었다면, Generation은 "AI가 제안한 구조를 내가 검토·승인하고, 그 구조로 결과물을 만드는 방법" 이다.
🚨 "그냥 작성해줘"의 함정
AI에게 "보고서 작성해줘"라고 요청했다. 5초 만에 30페이지짜리 보고서가 뚝딱 나왔다. 읽어보니 빈약하다. 논리는 비약하고, 섹션마다 깊이가 들쭉날쭉하다. 다시 만들라고 할 수도 없고, 어정쩡하게 수정하며 시간을 보낸다.
이 문제의 원인은 무엇일까?
구조 없이 생성했기 때문이다.
구조 없이 생성된 산출물이 가진 문제는 세 가지다.
첫째, 일관성과 논리가 부족하다. 전체를 관통하는 하나의 흐름 없이, AI가 그 순간 가장 그럴듯하다고 생각하는 내용을 나열한다. 섹션마다 깊이가 다르고, 앞뒤가 맞지 않는 주장이 등장한다.
둘째, 사용자가 산출물을 이해하고 설명할 수 없게 된다. AI가 만든 결과물을 보고 "음, 괜찮네" 하고 넘어간다. 그런데 누군가 "왜 이 부분이 이렇게 구성되었죠?"라고 물으면 대답할 수 없다. 그 구조를 당신이 설계한 것이 아니라 AI가 임의로 결정했기 때문이다.
셋째, 검토가 불가능한 블랙박스가 탄생한다. 검토하려면 기준이 있어야 한다. 구조가 없다면 무엇을 기준으로 검토해야 할까? "그럴듯해 보이는지" 말고는 판단할 방법이 없다.
이게 '그냥 작성해줘'의 실체다. '그냥 작성해줘'는 사실 '아무렇게나 작성해줘'와 다를 바 없다.
🏗️ ASR — 무엇이 유리그릇인가
"좋아, 구조를 먼저 설계해야 한다는 것은 알겠다."
하지만 '구조'라는 말은 너무 추상적이다. 마치 "잘 살아라"라는 말처럼, 방향은 맞지만 구체적인 실천이 떠오르지 않는다.
여기서 핵심 개념이 등장한다. ASR(Architecturally Significant Requirement) — '구조적으로 중요한 요구사항'.
ASR은 최종 산출물의 구조, 구성, 품질에 실질적인 영향을 미치는 요구사항이나 설계 결정을 말한다. 원래 소프트웨어 아키텍처에서 나온 개념이지만, 문서, 발표자료, 블로그 시리즈 등 모든 산출물 유형에 적용된다.
ASR이 중요한 이유는 이것이다. ASR을 검토하고 설계하지 않으면 AI는 생성 단계에서 침묵의 기본값(Silent Default) 으로 채운다. AI가 "적당히 괜찮은 방식"으로 결정해 버리는 것이다. 문제는 그 기본값이 당신의 의도와 다를 수 있다는 점이다. 그런데 당신은 그 사실조차 모른다. 결과물을 보고 "뭔가 이상한데?"라고 느끼지만, 정확히 무엇이 이상한지 지적할 수 없다.
🏠 전원주택 비유 — 침묵의 기본값이 만드는 비극
이사를 앞두고 있다. 짐을 박스에 넣어야 하는 상황이다.
이삿짐센터 직원에게 "잘 넣어줘" 라고 말한다. 직원은 자신의 방식대로 넣는다. 중요한 유리그릇이 박스 아래에 깔리고, 무거운 책이 그 위에 올려진다.
직원은 나쁜 의도가 없었다. 그냥 자기 방식대로 한 것뿐이다. 하지만 당신이 생각한 '잘 넣는 것'과 직원의 '잘 넣는 것'은 달랐다.
이것이 침묵의 기본값이다. 당신이 명확하게 지시하지 않으면, AI는 자신의 기본값으로 채운다. 그리고 그 기본값은 당신의 의도와 다를 수 있다.
'구조'란 바로 이런 것이다. 중요한 것이 어디에 위치할지, 어떻게 배치될지를 결정하는 일. ASR은 '무엇이 유리그릇인지' 식별하는 작업이다.
이제 좀 더 구체적인 예시를 들어보겠다. 전원주택을 짓는다고 상상해 보자.
여러분은 건축가에게 말한다. "우리 가족 생활 패턴에 가장 적합한 주택을 설계해 주세요."
건축가는 여러 가지를 결정해야 한다. 1층으로 지을까, 2층으로 지을까? 지붕을 올릴까, 옥상을 둘까, 옥탑방을 둘까?
이 각각이 Concern(관심사) 이자 ASR이다. 건물의 구조와 사용성에 실질적인 영향을 미치기 때문이다.
상황 1 — 사용자가 명확하게 요구한 경우:
"2층에 옥탑방으로 지어주세요." 이미 결정이 내려져 있다. ADR이 필요 없다. Spec에 바로 기록하면 된다.
상황 2 — 사용자가 결정을 위임한 경우:
"우리 생활 패턴에 가장 적합한 것으로 결정해 주세요." 이것이 ADR이 필요한 상황이다. 건축가는 각 선택지의 장단점을 분석하고, 사용자의 생활 패턴에 가장 적합한 것을 권장한다. 사용자는 이 분석을 검토하고 결정을 내린다.
🔄 4단계 파이프라인
이 과정을 Cocrates의 Artifact Generation Pipeline으로 표현하면 이렇게 된다.
ASR 식별 → ADR → Spec → Generation & Verification
1단계 — ASR 식별: AI가 "이것이 중요합니다, 저것도 중요합니다"라고 ASR을 던져 준다. 당신의 역할은 중요한 것과 중요하지 않은 것을 구별하는 분별력을 발휘하는 것이다. AI가 모두 중요하다고 말하는 것 중에서 진짜 구조에 영향을 미치는 것을 골라내고, 나머지는 과감히 제쳐둔다. 이 단계가 없으면 AI가 모든 것을 중요하게 여겨 파이프라인이 무거워지거나, 모든 것을 스스로 결정해 버린다.
AI-native Engineer로서 가져갈 역량: 중요한 ASR과 덜 중요한 요구사항을 구별하는 분별력
2단계 — ADR (대안 분석 & 결정): AI가 Concern별로 대안을 분석하고 장단점을 정리해 제안한다. 당신의 역할은 AI의 분석과 제안이 정말 최적인지 분석/판단/결정하는 판단력을 발휘하는 것이다. "이 분석이 충분한가? 다른 대안은 없을까? AI가 놓친 관점은 없나?"를 질문하고, 최종 결정을 내린다. ADR은 '내가 왜 이렇게 결정했는지'를 기록하는 감사 추적이다.
AI-native Engineer로서 가져갈 역량: AI의 분석을 평가하고 최적을 판단·결정하는 판단력
3단계 — Spec (결정 통합): AI가 ADR에서 승인된 모든 결정을 하나의 문서로 통합해 Spec을 작성한다. 당신의 역할은 더 빠진 것은 없는지, 추가로 검토해야 할 것은 없는지, 이 Spec으로 최종 산출물이 어떻게 나올지 예상하는 통찰력을 발휘하는 것이다. Spec을 읽고 "이대로 생성하면 어떤 부분이 문제가 될까?"를 미리 본다. 빠진 내용이 발견되면 ADR로 돌아가 검토하고 Spec에 추가한다. Spec은 자체 완결적이어야 하며, Spec 하나만 읽으면 무엇을 만들지 완전히 이해할 수 있어야 한다.
AI-native Engineer로서 가져갈 역량: Spec의 완전성을 검토하고 결과물을 예상하는 통찰력
4단계 — Generation & Verification: AI가 Spec을 기준으로 산출물을 생성한다. 당신의 역할은 결과물을 맹신하지 않고 검증하는 태도를 유지하는 것이다. Spec의 항목 하나하나를 결과물과 대조한다. 생성 과정에서 Spec에 없던 설계 결정이 결과물에 포함되었는지도 발견한다. 이것을 Undocumented ASR이라고 한다. Undocumented ASR이 발견되면, 이는 ADR 단계에서 검토되지 않은 결정이므로 다시 ADR로 보내 검토해야 한다.
AI-native Engineer로서 가져갈 역량: 결과물을 맹신하지 않고 검증하는 태도
💡 이 파이프라인이 당신에게 주는 것
이 파이프라인의 핵심은 이것이다. 당신이 모든 단계에서 주체적으로 참여한다는 것.
AI가 대신 검토하지 않는다. 당신이 결정하고, 당신이 검토하고, 당신이 승인한다. AI는 그 과정을 돕는 도구일 뿐이다.
구조 기반 생성의 첫걸음은 '구조가 모호하다는 사실을 인정하는 것' 에서 출발한다. 모호함을 인정하고, 중요한 관심사를 식별하고, 선택지를 분석·결정하고, 결정을 명세로 통합한 뒤, 그 명세를 기준으로 생성하고 검증한다.
이것이 Cocrates가 '산출물 생성'이라는 단순해 보이는 작업을 이렇게 복잡하게 만드는 이유다. 하지만 이렇게 만들어야 당신이 이해하지 못한 채로 결과물을 받아들이는 일이 없기 때문이다.
📌 오늘의 핵심
- AI가 작업을 수행하고, 당신(AI-native Engineer)이 검토하고 결정한다. 당신의 가치는 AI가 제안한 것을 얼마나 잘 평가하고 최종 판단을 내리느냐에 있다.
- ASR 단계에서 필요한 역량은 분별력 — AI가 던져 주는 ASR 중 진짜 중요한 것과 그렇지 않은 것을 구별하는 능력.
- ADR 단계에서 필요한 역량은 판단력 — AI가 분석·제안한 결정이 정말 최적인지 평가하고, 필요하면 추가 질문을 던져 더 나은 결정을 이끌어 내는 능력.
- Spec 단계에서 필요한 역량은 통찰력 — AI가 통합한 Spec에 빠진 것은 없는지, 이 Spec으로 결과물이 어떻게 나올지 예상하는 상상력/통찰력.
- Generation / Verification 단계에서 필요한 역량은 검증 태도 — 결과물을 맹신하지 않고 확인하는 태도. 산출물은 내가 책임진다.
스스로에게 질문하자.
- AI에게 요청할 때, 나는 '팀장'으로서 AI가 제안한 구조를 검토하고 있는가, 아니면 AI의 첫 제안을 그대로 받아들이고 있는가?
- AI가 "이것이 중요합니다"라고 말한 모든 것이 정말로 중요한가? 나는 중요한 것과 중요하지 않은 것을 구별하고 있는가?
🎬 다음 편 예고
오늘 우리는 Artifact Generation Pipeline의 원리를 배웠다. ASR, ADR, Spec, Verification — 각 단계가 왜 필요한지, 무엇을 위한 것인지 알게 되었다.
다음 편에서는 이 파이프라인을 구성하는 네 개의 스킬 — adr-writing, spec-writing, spec-driven-generation, spec-driven-verification — 의 내부 구조를 상세히 살펴본다. 각 스킬이 실제로 어떻게 동작하고, 어떤 워크플로우로 구성되어 있는지, SKILL.md 파일을 직접 열어보듯 설명하겠다.
이 시리즈는 Cocrates Harness 프레임워크를 소개합니다. Cocrates는 소크라테스식 대화로 사용자가 주도권을 잡고 성장하도록 설계된 에이전트 하네스입니다.