Codex AI 에이전트로 생각 정리 → 강의 자산화 시스템 만들기 프로젝트 기획 과정 정리

1. 문제 정의: 왜 이 시스템이 필요한가

1) 기존 방식의 병목

아이디어/설명을 떠올릴 때는 빠르게 나오는데,
- 정리(문서화),
- 강의 구조화(커리큘럼/레슨화),
- 저장/버전관리,
- 반복 생산
  이 과정이 귀찮고 끊기기 쉬움.
웹 UI에서 대화 → 복사 → 파일 저장/다운로드 과정을 반복하면,
- 작업 흐름이 끊기고
- 누락/중복이 생기고
- “쌓이는 자산”이 아니라 “흩어진 대화”로 남음.

2) 요구 조건(사용자 목표)

VS Code + Codex 확장을 중심으로,
- 채팅하듯 입력하되
- 파일 읽기/쓰기 기반으로
- 지침(프롬프트/규칙)을 지식 파일로 고정하고
- 결과물을 자동으로 폴더에 축적하고 싶다.
특히 Suno 강의 제작에서,
- 즉흥적으로 떠드는 원본을
- 정리된 소스(카드)로 바꾸고
- 필요하면 그 카드들을 조합해 강의를 만든다.
강의는 “완벽한 완성본”보다 짧고 실행 위주, 핵심 1개 중심으로 누적한다.

2. 핵심 개념: 이 시스템은 “대화형 + 파일 기반 에이전트”다

1) 네가 선택한 방식의 정체

Codex(IDE 에이전트)를 웹 UI처럼 대화로 쓰되,
동시에 프로젝트 폴더를 작업 공간으로 써서,
- 원본/정리본/카드/산출물이 파일로 남도록 한다.
규칙은 AGENTS.md로 고정한다.
- README는 “참고 문서”일 뿐, 자동 규칙 파일로 취급되지 않을 수 있음.
- 핵심 규칙은 AGENTS.md에 넣는 것이 안정적이다.

3. 시스템 목표(산출물 정의)

이 시스템은 입력 1건을 다음 산출물로 만든다.

RAW 파일(원본 저장)

내가 채팅에 마구 입력한 내용을 빠짐없이 저장하는 파일
목적: 재가공/재정리/검증 가능성 확보(“원천 데이터”)

CARD 파일(핵심 1개씩 분해)

RAW에서 “결론/핵심”을 기준으로 최대 3개까지 카드 생성
각 카드에는:
- 핵심 1개
- 추가 내용
- 세부 디테일
- needs_input(추가로 내가 말해야 할 질문)
- “내 말투 문장” (스크립트에 바로 쓸 문장)

PARK 파일(보류/초과/미분류)

카드 3개 제한 때문에 남는 내용
또는 지금 당장 카드로 만들기 애매한 내용
목적: 중요한 소재가 버려지지 않도록 보관

4. 운영 원칙(MVP 핵심 결정 사항)

결정 A) ORIG(원문) 단계를 버리고 “RAW + CARD”로 간다

ORIG → RAW → CARD 3단계는 추적성은 좋지만 운영 부담이 커질 위험이 큼.
그래서 최종 결론: RAW와 CARD만 유지.
- RAW는 “원본(날것)을 빠짐없이” 저장하는 역할까지 포함.

결정 B) 카드 생성은 최대 3개로 제한한다

입력이 길어질수록 무한 분해가 가능하지만,
- 초반에는 복잡도가 폭발하기 쉬움.
그래서 max 3 cards + 나머지는 PARK로 보내는 구조로 단순화.

결정 C) 원본 수정 후 카드 업데이트(Resync)는 가능하되, 안전장치를 둔다

원본(RAW)을 내가 직접 수정하는 경우가 생김.
그래서:
- raw_id가 지정되면 해당 RAW를 다시 읽고 카드 파일을 업데이트한다.
- 덮어쓰기/경계 애매함이 있으면 “옵션 제시 후 사용자 선택”으로 진행한다.

결정 D) “정리/저장” 요청은 자동 실행하되, 위험할 때만 확인(조건부 확인)

매번 확인하면 귀찮아져서 시스템이 안 돌아갈 수 있음.
그래서:
- 신규 RAW 생성처럼 안전한 작업은 자동 진행(기본 옵션 2)
- 덮어쓰기/경계 애매/코스 미지정 같은 위험 상황만 옵션 질문

5. 확장 요구: 한 워크스페이스에서 여러 강의(코스)를 운영한다

초기에는 Suno 코스만 있었지만, 실제로는 강의가 여러 개로 늘어날 수 있음.
따라서 구조를 멀티 코스 저장소로 확장했다.

멀티 코스 추천 구조(MVP)

온라인코스제작/
  AGENTS.md
  _templates/
    inbox_template.md
    card_template.md
    park_template.md (optional)
    chat_command.md (optional)
  courses/
    suno/
      inbox/
      cards/
    openclaw/
      inbox/
      cards/

코스 선택 규칙(중요)

매 저장/정리 작업은 “어느 코스에 저장할지” 결정해야 한다.
선택 우선순위:
1. 사용자 메시지에 course=<slug>가 있으면 그 코스
2. 메시지에 경로가 포함되어 코스가 암시되면 그 코스
3. 둘 다 없으면 한 번만 질문하고 파일 저장은 보류

6. 파일 규칙: 이름/ID/업데이트 정책

1) 파일명 규칙(표준)

RAW: RAW_YYYYMMDD_###.md
CARD: CARD_<raw_id>_01.md ~ CARD_<raw_id>_03.md
PARK: PARK_<raw_id>.md

2) 업데이트(Resync) 규칙

사용자가 raw_id=RAW_...를 명시하면:
- 해당 RAW를 다시 읽고
- 같은 파일명(CARD_<raw_id>_01~03)을 유지한 채 내용을 업데이트
카드가 줄어들면:
- 남는 카드 파일은 유지하되 status: deprecated 처리(템플릿 frontmatter가 있을 때)
- 핵심은 PARK로 이동

3) “빠짐없이”에 대한 현실적 처리

AI가 “완벽히 누락 없음”을 100% 보장한다고 가정하지 않는다.
대신 정책으로 누락을 줄인다:
- RAW에는 원문을 가급적 그대로 저장
- 애매한 부분은 삭제하지 않고 needs_input으로 질문화

7. 템플릿 설계(데이터 확장 포함)

사용자는 “날짜/주제 등 확장 가능한 구조”가 필요하다고 명시했다.
따라서 RAW/CARD는 frontmatter(YAML) 기반 메타데이터를 가진다.

RAW 템플릿 핵심 필드

raw_id, date, topic, tags, style_notes, created_at, updated_at

CARD 템플릿 핵심 필드

card_id, raw_id, title, status(active/deprecated), tags, prerequisites/related(선택)

8. 채팅에서의 실제 운영: 입력/명령 UX 설계

문제: “그냥 막 입력하고 마지막에 정리해”만으로 항상 잘 될까?

기본 상태에서는 불확실할 수 있다(경계/의도 파악 문제).
해결:
- RAW 경계를 표시하는 최소 규칙을 권장하거나
- 지침에서 RAW 경계 규칙을 명시한다.

RAW 경계 인식 우선순위(지침에 반영)

<<< >>> 블록
RAW: 이후 텍스트
그렇지 않으면 “마지막 줄이 단독 명령(정리해)”일 경우 그 줄만 제외

트리거 전략(최종)

트리거 없는 대화는 저장하지 않는다(불필요한 파일 생성 방지).
사용자가 “정리/저장”을 말하면 그때 RAW+CARD를 만든다.
다만 “대화가 길어져 전체를 정리”하는 케이스는 컨텍스트 누락 위험이 있어,
- 체크포인트 저장 같은 보완 옵션을 제안했으나
- 현재 MVP는 “사용자가 정리 요청 시점에 처리”로 유지.