Hako의 기획 with AI

7장. 도구 환경 구성과 AI 산출물 파이프라인

10 min read

7장. 도구 환경 구성과 AI 산출물 파이프라인

이 장의 목적

문서 구조와 기준을 정했다면, 그것을 실제로 어떻게 운영할지가 남는다. 이 장은 도구 소개가 아니라 운영 흐름 설계를 다룬다. 기준 문서와 실행 문서가 어디서 관리되고, AI가 어디에 투입되며, 한 문서가 어떻게 다음 문서로 이어지는지를 정리한다.

제1절. 도구 환경 구성

1. 왜 도구 구성부터 이야기하는가

도구 구성은 설치 순서의 문제가 아니라 운영 구조의 문제다. 어떤 공간에서 무엇을 관리하고, 어느 단계에 AI가 투입되며, 변경 이력을 어떻게 남기는지가 설계되어야 한다.

2. 네 가지 운영 역할과 도구 선택

산출물 체계가 작동하려면 네 가지 역할이 명확히 분리되어야 한다. 어떤 도구를 쓰는지보다 이 역할 분리가 실제로 지켜지는가가 더 중요하다.

기준 문서 관리 공간: 용어집, 정책 기준, Source of Truth 기준표처럼 여러 과제가 공통으로 참조하는 문서를 모아두는 곳이다. 링크와 연결 관계를 유지하기 좋은 도구가 적합하며, 장기 지식 축적에도 안정적인 환경이어야 한다. (저자는 Obsidian을 사용한다.)

실행 문서 작업 공간: 기획 문서 초안, 사양서, 테스트케이스처럼 특정 과제 단위로 생성·수정되는 실행 문서를 다루는 곳이다. 텍스트 편집, diff 검토, 구조 정리, AI 협업 실행이 가능한 환경이어야 한다. (저자는 VS Code와 AI 코딩 도구를 함께 사용한다.)

AI 초안 생성·변환 파트너: 초안 생성, 구조화, 누락 탐지, 하위 문서 초안 전개에 활용한다. 기준 문서 지정, 승인, 폐기 같은 최종 판단은 PM/PO가 맡아야 한다.

버전 이력 및 승인 관리: 무엇이 승인본이고 무엇이 작업 중인 문서인지 분리하고 변경 이력을 남기는 구조다. 단순 파일 백업이 아니라 운영 기준 관리의 도구로 써야 한다. (저자는 Git 기반 브랜치 전략을 사용한다.)

3. 역할 연결 구조

네 역할이 이어지는 최소 흐름은 다음과 같다.

기준 문서 관리 → 실행 문서 작업 → AI 초안/검토/변환 → 버전·승인 이력 관리

어떤 도구 조합을 쓰더라도, 기준 문서와 실행 문서가 섞이지 않도록 역할이 나뉘는가가 핵심이다.

4. 최소 세팅 기준

4-1. 폴더 구조

프로젝트볼트/
├── _standards/
├── _working/
├── _archive/
└── chapters/
  • _standards/: 승인된 기준 문서
  • _working/: Draft, Review 문서
  • _archive/: 폐기 또는 보관 문서
  • chapters/: 실제 원고와 산출물

4-2. 기준표

source-of-truth-map.md 같은 기준표가 있어야 정보 종류별 최종 기준 문서를 빠르게 확인할 수 있다.

4-3. 상태와 버전 표기

각 문서는 최소한 다음 정보를 보여야 한다.

  • 상태: Draft / Review / Approved / Deprecated
  • 버전
  • owner
  • 승인 정보
  • 영향 문서

4-4. AI 참조 범위

AI에는 Approved 기준 문서와 현재 작업에 필요한 문서만 전달해야 한다. Draft, Review, Deprecated 문서가 섞이면 기준이 흐려진다. 사용하는 도구가 무엇이든 이 원칙은 동일하다.

5. 실무 시작 기준

실무에서는 다음 네 가지만 먼저 갖춰도 운영 품질이 크게 달라진다.

  1. 기준 문서, 작업 문서, 폐기 문서를 물리적으로 분리된 공간에 보관하기
  2. 정보 종류별 최종 기준 문서를 명시한 기준표 초안 작성
  3. 모든 문서에 상태(Draft/Review/Approved/Deprecated)와 버전 표기
  4. Approved 문서만 실행 기준으로 유지하고, 나머지는 작업 공간에 구분 보관

처음부터 완벽할 필요는 없다. 기준 문서 2~3개와 상태 관리만 있어도 AI 혼선의 상당 부분을 막을 수 있다.

제2절. AI 산출물 파이프라인

6. 파이프라인이란 무엇인가

AI 산출물 파이프라인은 개별 문서를 따로 만드는 방식이 아니라, 한 문서가 다음 문서의 입력이 되는 흐름을 뜻한다.

이 흐름이 있어야 문서는 쌓이는 것이 아니라 이어진다.

7. 단계별 흐름

이 책의 기본 파이프라인은 다음처럼 읽을 수 있다.

  1. 입력 구조화
  2. 방향과 범위 정의
  3. 기능 분리와 시나리오 정리
  4. 정책과 흐름, 판단 분리
  5. 구현 조건 구체화
  6. 검증 기준 설계

문서 이름으로 보면 대체로 다음 순서에 가깝다.

BRD/문제정의 → PRD → 정책서/BPMN/DMN → 사양서/프로토타입 → 테스트케이스

8. 각 단계에서 AI와 사람의 역할

AI가 잘하는 일:

  • 초안 생성
  • 누락 항목 탐지
  • 하위 문서 후보 전개
  • 형식 변환과 정리

PM/PO가 책임져야 하는 일:

  • 범위 확정
  • 정책 우선순위 판단
  • 예외 인정 여부 결정
  • 기준 문서 승인
  • 폐기와 변경 통제

9. 세트 크기별 파이프라인 적용

9-1. 3개 세트

최소 입력 구조와 간단한 완료 기준 위주로 간단한 흐름을 만든다. 문서 수는 적지만 범위 고정은 분명해야 한다.

9-2. 10개, 12개 세트

방향, 구현, 검증이 기본적으로 분리된다. 12개 세트에서는 정책서(규칙 레이어)와 프로토타입(경험 레이어)이 추가된다. AI가 한 문서를 다음 문서 초안으로 전개하기 쉬워지는 구간이다.

9-3. 30개, 35개 세트

정책과 운영 연결, 변경 영향 추적, 기준 문서 재사용까지 함께 작동해야 한다. 파이프라인 자체가 운영 구조가 된다.

10. 파이프라인이 무너지는 패턴

다음과 같은 경우 파이프라인은 쉽게 무너진다.

  • Approved 기준 없이 Draft 문서가 입력으로 섞인다
  • PRD가 정책과 사양을 모두 떠안는다
  • 프로토타입이 정책과 사양의 대체물처럼 쓰인다
  • 테스트케이스가 마지막에만 작성된다
  • 변경 영향 문서 연결이 끊긴다

11. 운영 체크리스트

항목확인 기준
기준 문서 분리Approved 기준 문서와 작업 문서가 분리돼 있는가
AI 입력 관리AI에 전달하는 문서 범위가 명확한가
단계별 책임각 단계에서 AI와 사람의 역할이 구분돼 있는가
세트 적합성현재 프로젝트 복잡도에 맞는 세트를 사용 중인가
영향 추적상위 문서 변경 시 하위 문서 영향이 파악되는가

12. 이 장의 핵심 메시지

도구가 중요한 것이 아니라, 기준 문서와 실행 문서가 끊기지 않도록 역할이 분리되고 하나의 운영 흐름으로 연결되어야 한다.

구조와 기준, 세트 선택이 정리되어도 실제 환경에서 분리와 연결이 유지되지 않으면 산출물 체계는 오래 가지 못한다.

그래프 뷰

백링크