EP10. 구조 기반 산출물 생성 활동
🏛️ "그냥 작성해줘"가 낳는 블랙박스와의 결별
"보고서 하나 작성해줘."
최신 AI 모델들은 이 짧은 한마디에 수초 만에 수십 페이지짜리 그럴듯한 문서를 뚝딱 출력해 냅니다. 제목, 목차, 본문까지 외형은 완벽하죠. 하지만 찬찬히 읽어보면 고개를 가로젓게 됩니다. 논리는 군데군데 비약해 있고, 섹션마다 깊이는 제각각이며, 전체를 관통하는 예리한 시선이 결여되어 있기 때문입니다. "더 자세하게 써줘"라고 다시 시켜봐야 양만 늘어날 뿐, 본질적인 갈증은 해소되지 않습니다.
소크라테스식 학습 활동이 인간의 메타인지를 자극하는 과정이었다면, Cocrates의 두 번째 거대한 축인 산출물 생성 파이프라인은 이 무지성 생성 플로우를 원천 차단하기 위해 설계되었습니다. Cocrates는 단호하게 말합니다. 좋은 산출물은 오직 견고한 구조 위에서만 탄생하며, 그 구조는 인간의 명확한 '결정'들의 집합이어야 한다고 말이죠.
🏗️ '그냥 작성해줘'의 실체: 아무렇게나 작성해줘
집을 지어달라는 요청을 받은 건축가가 아무것도 묻지 않고 벽돌부터 쌓아 올린다면 어떻게 될까요? 일주일 뒤 완성된 집은 그럴듯해 보일지 몰라도, 화장실 창문이 거실을 향해 뚫려 있거나 현관문이 2층에 달려 있는 해괴한 꼴이 될 것입니다.
구조적 설계 없이 AI에게 생성을 위임하는 것은 이와 똑같은 도박입니다. 구조가 결여된 산출물은 필연적으로 세 가지 치명적인 문제를 낳습니다.
- 논리와 일관성의 붕괴: AI는 문맥상 그 순간 가장 그럴듯한 문장을 나열할 뿐이므로, 앞뒤 문맥이 충돌하거나 섹션 간의 밸런스가 사정없이 무너집니다.
- 책임의 상실: 타인이 "왜 이 보고서는 이런 흐름으로 전개되죠?"라고 물었을 때, 당신은 대답할 수 없습니다. 구조를 당신이 아니라 AI가 임의로 결정했기 때문입니다.
- 검토 불가능한 블랙박스화: 기준(설계도)이 없으니 결과물이 실제로 잘 뽑혔는지 검증할 방법이 없습니다. 그저 '문장이 매끄러운가'라는 표면적 껍데기만 쳐다보게 됩니다.
🔍 모호한 구조를 실체화하는 열쇠: ASR (구조적 요구사항)
"좋아, 구조를 먼저 설계하라는 방향은 맞는데... 대체 '무엇을' 설계해야 하지?"
'구조'라는 말은 너무나 추상적입니다. 이 안개를 걷어내기 위해 Cocrates가 도입한 핵심 개념이 바로 ASR(Architecturally Significant Requirement, 구조적으로 중요한 요구사항)입니다. 최종 산출물의 구성, 품질, 전개 방식에 실질적인 지각변동을 일으키는 핵심 제약조건들을 뜻합니다.
- 보고서의 ASR: "이 문서의 최종 최종 데스크는 C레벨 임원이다" → 요약의 밀도와 두괄식 전개 구조를 결정.
- 발표 자료의 ASR: "발표 제한 시간은 정확히 10분이다" → 슬라이드의 총개수와 거버닝 메시지의 한계를 규정.
- 테크 블로그의 ASR: "타깃 독자는 주니어 개발자들이다" → 기술 용어의 해설 깊이와 비유의 비중을 결정.
만약 이 ASR을 명시적으로 합의하지 않고 넘어가면, AI는 이 공간을 '침묵의 기본값'으로 채워버립니다. AI 본인 마음대로 "적당하고 무난한 방식"을 택해 결정짓는 것이죠. 이삿짐을 쌀 때 "무엇이 깨지기 쉬운 유리그릇인지(ASR)" 알려주지 않으면, 직원은 자신의 기본값대로 무거운 책 아래에 유리그릇을 깔아 뭉개버릴 것입니다.
🏡 전원주택 건축으로 보는 4단계 레이어
Cocrates가 산출물을 빌드업하는 과정은 전원주택을 짓는 정교한 아키텍처 공정과 완벽히 닮아있습니다.
[Concern / ASR 식별] ─→ [ADR: 대안 분석 및 결정] ─→ [Spec: 설계도 통합] ─→ [Generation & Verification]
- 1단계. Concern / ASR 식별 (관심사 도출): "1층으로 지을 것인가, 2층으로 지을 것인가?", "지붕인가, 옥상인가, 옥탑방인가?"와 같이 구조를 좌우할 굵직한 관심사를 수면 위로 올립니다.
- 2단계. ADR (Any Decision Record, 대안 분석): 사용자가 결정을 위임한 영역에 대해 최소 2~3가지의 명확한 선택지를 펼쳐놓고 장단점을 비교합니다. (예: 1층은 공사비가 싸지만 넓은 땅이 필요하고, 2층은 조망이 좋지만 노약자에게 불편함). 유저는 이 비교표를 보고 최종 결정을 내리며, 이 결정의 역사가 기록됩니다.
- 3단계. Spec (사양 명세서): 이미 확정된 요구사항과 ADR을 통해 내려진 모든 결정들을 모아 자체 완결적인 하나의 설계도로 통합합니다. 이 명세서 하나만 있으면 이전의 기나긴 대화를 다 뒤져보지 않아도 완벽하게 시공할 수 있는 상태가 됩니다.
- 4단계. Generation & Verification (시공 및 검증): 사용자의 최초 프롬프트가 아니라, 철저히 최종 승인된 Spec을 유일한 헌법으로 삼아 텍스트를 출력합니다. 출력이 끝나면 Spec의 항목들과 일일이 대조하며, 설계도에 없던 AI의 임의적 결정(Undocumented ASR)이 밀수입되지는 않았는지 촘촘하게 검증합니다.
📝 세 줄 요약
- "그냥 써줘"는 AI에게 "아무렇게나 써줘"라고 방임하는 것과 같습니다. 구조 없는 생성은 통제 불가능한 블랙박스를 만듭니다.
- 침묵의 기본값(Silent Default)을 깨부수어야 합니다. 산출물의 성격을 결정짓는 핵심 제약조건(ASR)을 식별하고, 최선의 선택을 고민하는 과정(ADR)이 반드시 선행되어야 합니다.
- Cocrates는 인간을 소외시키지 않습니다. 모든 빌드업 단계마다 사용자가 직접 검토하고, 결정하고, 승인하는 '설계도의 주인' 역할을 되찾아 줍니다.
🎬 다음 편 예고
산출물을 찍어내기 전에 왜 이토록 깐깐한 아키텍처 파이프라인을 거쳐야만 하는지 그 근본적인 '왜'를 짚어보았습니다.
그렇다면 이 파이프라인을 실질적으로 굴리는 네 가지 전담 부대 스킬들(adr-writing, spec-writing, spec-driven-generation, spec-driven-verification)의 구체적인 내부 템플릿과 규칙은 어떻게 생겼을까요? 다음 에피소드에서는 각 스킬이 모호함을 걷어내고 완벽한 문서를 시공해 내는 구체적인 '어떻게(How)'를 전격 공개합니다!
"글을 쓰기 전에 구조를 쥐어 짜내십시오. 구조가 무너지지 않는다면, 그 위의 콘텐츠는 결코 흔들리지 않습니다."
이 시리즈는 Cocrates Harness 프레임워크를 소개합니다. Cocrates는 소크라테스식 대화로 사용자가 주도권을 잡고 성장하도록 설계된 에이전트 하네스입니다.