시행착오 회고: 우리가 놓칠 뻔한 것들
AI 워크스페이스 OS를 만든다고 해서 한 번에 완벽해지지는 않았다. 오히려 구조를 만드는 과정에서 작은 구멍이 계속 발견됐다.
중요한 것은 구멍이 생겼다는 사실보다, 그 구멍을 발견하고 시스템에 반영했다는 점이다.
1. 실패한 기술이 다시 살아나는 문제
과거에 실패한 대안이 있었다. 특정 로컬 생성 모델, 무거운 렌더링 구조, 메모리 한계 등은 이미 보류한 방향이었다.
그런데 AI는 시간이 지나면 그 대안을 다시 제시했다. 마치 처음 듣는 해결책처럼 말이다.
이 문제를 막기 위해 docs/13_LEGACY_INDEX.md 같은 실패 장부가 필요했다.
| 실패한 길도 문서화해야 한다. 그래야 AI가 같은 길을 새 해결책처럼 다시 꺼내지 않는다. |
2. Master PRD가 무엇인지 헷갈린 문제
AutoVideo에는 비슷한 이름의 PRD가 여러 개 있었다.
- 최종으로 봐야 할 Product Bible
- 오염 가능 초안
- 중간 draft
- Custom BYOA 세부 설계 문서
- 실험 중 생성된 찌꺼기 문서
파일명과 타임스탬프만으로는 판단하기 어려웠다. 그래서 문서마다 지위를 붙였다.
| Active Master PRD Superseded Draft Migration Source Quarantined Scratch Deletion Candidate |
이 과정을 통해 배운 것은 명확했다.
| 문서의 내용만큼 중요한 것은 문서의 지위다. |
3. AI_Video_Automation_PRD를 역할 문서처럼 다룬 문제
AI_Video_Automation_PRD.md는 NotebookLM 멀티소스 실험 중 생긴 찌꺼기였다. 그런데 한때 이 문서에도 역할 배너가 붙으면서 정상 문서처럼 보일 위험이 있었다.
결국 이 파일은 Quarantined Scratch / SoT Excluded / Deletion Candidate로 명확히 격리했다.
교훈은 이렇다.
| 폐기 후보도 문서 폴더에 있으면 AI는 근거로 삼을 수 있다. 폐기 후보라면 폐기 후보라고 크게 써야 한다. |
4. 루트 템플릿과 프로젝트 내부 템플릿을 헷갈린 문제
한 번은 템플릿 위치가 헷갈렸다.
| <WORKSPACE_ROOT>/_ai_workspace_template <WORKSPACE_ROOT>/auto-video-tools/_ai_workspace_template |
둘은 다르다. 루트 템플릿이 진짜 원본이고, AutoVideo 내부의 템플릿은 과거 작업 찌꺼기였다.
이 오해 이후 템플릿 원본 위치를 더 명확히 했다.
5. Desktop dump가 쌓인 문제
처음에는 ChatGPT 검토용 dump를 Desktop에 만들었다. 당장은 편했다. 하지만 스프린트가 반복되자 ZIP이 너무 많이 쌓였다.
그래서 _ai_dumps/ 정책으로 바꿨다.
| <WORKSPACE_ROOT>/_ai_dumps/ |
이 폴더는 gitignore로 관리하고, README만 추적한다. 오래된 dump는 7일 기준으로 cleanup한다.
6. 프롬프트가 한 블록으로 안 나간 문제
AG에게 줄 긴 프롬프트가 중간에 깨지는 문제도 있었다. 사용자는 한 번에 복사해서 붙여넣어야 하는데, 프롬프트가 여러 블록으로 나뉘면 전달이 어려웠다.
그래서 AG용 프롬프트는 원칙적으로 한글럭, 즉 하나의 복사 가능한 코드블록으로 제공해야 한다는 규칙이 생겼다.
이건 사소해 보이지만, 실제 작업 속도에는 큰 차이를 만든다.
7. blog PRD가 없는 줄 알았던 문제
blog 프로젝트는 코드가 있었지만, 최신 PRD가 비어 있는 것처럼 보였다. 나중에 보니 Tistory_Auto_Publish_PRD.md라는 비표준 이름의 중요한 PRD 후보가 있었다.
이 파일은 표준 이름이 아니어서 처음에는 시스템에서 잘 안 보였다. 하지만 실제로는 Playwright/RPA 기반 블로그 자동화의 중요한 기획 소스였다.
그래서 Master PRD Registry가 필요했다.
| 파일명이 표준이 아니어도 버리지 않는다. Registry에 편입하고 상태를 부여한다. |
8. “원고 업데이트”를 “실제 발행”으로 오해한 문제
가장 최근의 중요한 교정은 이것이었다.
“기존 블로그 원고 업데이트”는 실제 티스토리나 네이버에 글을 올리라는 뜻이 아니었다. 예전에 작성해 둔 10개 블로그 초안을 지금까지의 작업 결과에 맞게 다시 다듬고, 새 인사이트를 반영해 몇 편을 추가하는 작업이었다.
이 일을 AG에게 맡기면 위험했다. AG는 로컬 실행자이지, 이 대화방의 모든 문맥과 글의 의도를 알고 있는 작성자가 아니다.
그래서 역할을 다시 분리했다.
| AG = 로컬 파일 실행자 ChatGPT = 원고 업데이트 작성자 / 전략 검토자 |
이 모든 시행착오의 공통점
대부분의 문제는 AI가 악의적으로 한 것이 아니다. 문제는 경계가 없었고, 문서의 지위가 불명확했고, 검증이 빠졌다는 데 있었다.
그래서 최종 교훈은 이것이다.
| AI 작업 시스템은 한 번에 완성되지 않는다. 구멍을 발견할 때마다 규칙과 파일에 반영해야 한다. |
체크리스트
시행착오를 줄이려면 다음을 확인하자.
- 템플릿 원본 위치가 명확한가?
- 활성 문서와 참고 문서가 구분되는가?
- 폐기 후보가 SoT에서 명확히 제외되어 있는가?
- project mode와 template mode 검증이 분리되어 있는가?
- 대상 프로젝트 오타를 자동 보정하지 않는가?
- dump 저장소가 정리되어 있는가?
- AG가 할 일과 ChatGPT가 할 일이 나뉘어 있는가?
다음 편 예고
마지막 편에서는 이 구조를 만든 뒤 무엇이 남았는지 정리한다. 이제 다시 제품 개발로 돌아갈 차례지만, 그 전에 PRD와 WIP를 정리해야 했다.