LLM 작업 흐름의 첫 단계: 컨텍스트 수집 패턴 여섯 가지 비교

들어가며: 스펙 이전에 오는 단계

LLM과 수십 번 왕복하는 하루를 보내보면 하나가 분명해진다. 프롬프트의 질보다 컨텍스트 얼라인 비용이 훨씬 크다. 프로젝트 배경, 도메인 용어, 지난 결정, 현재 제약 — 이것들을 매번 다시 설명하는 낭비가 생산성을 조용히 깎아 먹는다.

그래서 실무에서 LLM 협업 흐름은 대개 네 단계로 수렴한다.

컨텍스트 얼라인 → 스펙 작성 → 계획 수립 → 실행

뒤쪽 세 단계에는 이미 정착된 스킬들이 있다. superpowers의 brainstorming·writing-plans·executing-plans가 대표적이다. 그런데 맨 앞 컨텍스트 얼라인 단계는 여전히 전략이 갈린다. "어떤 스킬·워크플로우·지침을 쓰는 게 가장 좋은가"가 열린 질문으로 남아 있다.

이 글은 그 열린 질문에 답하기 위해, 실무에서 선택 가능한 여섯 가지 패턴을 같은 자 위에 올린다. 각 패턴의 작동 원리와 설계 의도를 짧게 분석하고, 네 개의 비교축으로 특성을 대조한 뒤, 상황별 선택 가이드를 제시한다. 마지막에 내가 실제로 굳히고 있는 조합을 공개한다.

1. 여섯 가지 패턴 개요

비교할 패턴을 먼저 간단히 나열하면 이렇다.

1. 정적 규약 파일 — CLAUDE.md / AGENTS.md / .cursorrules
2. 분산 자동 메모리 — Claude Code memory 시스템
3. 코어 스냅샷 번들 — Cline Memory Bank
4. 대화형 정제 — superpowers brainstorming
5. 디스커버리 파이프라인 — BMAD Analyst phase
6. 3-Layer 위키 — llm-wiki (raw → wiki → spec/plan)

각각을 원리, 작동, 설계 의도, 한계 순으로 해부한다.

1-1. 정적 규약 파일 — CLAUDE.md

원리. 프로젝트 루트에 마크다운 파일을 두고, 도구(Claude Code, Cursor, Cline 등)가 세션 시작 시 이 파일을 프롬프트에 자동 주입한다.

작동. 사람이 수기로 쓴다. 커밋 대상이다. 불변에 가까운 프로젝트 규약 — 패키지 매니저, 빌드 명령, 코드 스타일, 디렉토리 구조, 외부 시스템 연동 규칙 — 을 담는다.

설계 의도. "프롬프트보다 파일이 싸다." 매 세션마다 동일한 설명을 반복하는 비용이 파일 유지 비용보다 크다는 전제다. 사람도 읽기 쉽고 버전 관리되므로 드리프트 추적이 가능하다.

한계.

• 선형 텍스트라서 의미별 호출이 안 된다. 파일 전체가 매번 주입된다.
• 작업별 가변 정보(현재 진행 이슈, 최근 결정)를 담으면 정적 규약과 섞여 drift가 커진다.
• 20KB를 넘으면 context bloat이 눈에 띈다.

언제 쓰나. 모든 프로젝트의 베이스. 이것만 있어도 기본 얼라인은 되지만, "이것만"으로 끝내면 스케일 문제가 온다.

1-2. 분산 자동 메모리 — Claude Code memory

원리. 의미별로 분리된 작은 마크다운 파일들을 memory/ 디렉토리에 축적한다. MEMORY.md가 인덱스 역할을 한다. 에이전트가 대화 중 "기억할 만한 것"을 감지하면 적절한 타입으로 자동 저장한다.

작동. 네 가지 메모리 타입이 정의되어 있다.

설계 의도. 정적 규약과 휘발성 컨텍스트를 분리한다. 규약은 CLAUDE.md, 휘발성은 memory. 의미별 분할로 "필요할 때만 해당 메모리를 꺼낸다"는 선택적 호출을 허용한다. 인덱스(MEMORY.md)는 매번 주입하지만, 개별 파일은 관련성이 있을 때만 읽는다.

한계.

• 무엇을 기록할지 에이전트가 판단해야 한다. 학습된 정책이 없으면 놓치거나 넘친다.
• 엔트리 간 충돌 시 자동 화해가 없다. "recall된 메모리가 현재 코드와 맞는지 먼저 검증" 지침에 의존한다.
• Claude Code 전용 포맷. 다른 도구로 이식하려면 수작업.

언제 쓰나. 같은 에이전트와 장기간 작업하는 경우. 내 취향, 반복되는 제약, 피드백 이력이 쌓이면서 가치가 커진다.

1-3. 코어 스냅샷 번들 — Cline Memory Bank

원리. 프로젝트 상태를 여섯 개의 고정 파일로 스냅샷한다. 파일 세트 자체가 표준화되어 있다.

projectbrief.md        프로젝트 목적과 범위
productContext.md      제품이 푸는 문제, 사용자 가치
systemPatterns.md      아키텍처, 주요 결정, 패턴
techContext.md         기술 스택, 의존, 환경
activeContext.md       현재 작업 상태, 최근 변경
progress.md            완료된 것, 남은 것

작동. 매 세션 시작 시 여섯 파일을 전부 읽는다. 작업 종료 전에 변화가 있는 파일을 갱신한다 ("update memory bank" 트리거).

설계 의도. Cline은 "에이전트가 세션 간 아무것도 기억하지 못한다"를 강한 전제로 둔다. 외부 스토리지(파일)에 완전한 프로젝트 표상을 유지하고 매번 다시 올린다. 여섯 파일의 역할 분할은 "무엇을 보존할지"를 표준화해서 에이전트가 놓치지 않게 한다.

한계.

• 매 세션 전체 로드 → 작은 작업에도 무거운 컨텍스트.
• 갱신이 누락되면 코드와 drift. activeContext.md가 가장 자주 틀린다.
• 내용의 신선도 검증 장치 자체는 없고, 갱신 규칙 준수에만 의존한다.

언제 쓰나. 세션이 자주 끊기는 워크플로우(툴 재시작, 에이전트 교체). 프로젝트 규모가 "여섯 파일 안에 담기는" 수준일 때.

1-4. 대화형 정제 — superpowers brainstorming

원리. 아이디어를 설계서로 정제하는 9단계 체크리스트. HARD-GATE로 구현 경로를 차단하고, "한 번에 한 질문" 원칙으로 사용자 과부하를 막는다.

작동 (9단계 요약).

1. 프로젝트 컨텍스트 탐색 (파일, 문서, 최근 커밋)
2. Visual Companion 제안 (필요 시)
3. 객관식/개방형 질문으로 목적·제약·성공기준 파악
4. 2-3개 접근법 + 트레이드오프 제시
5. 섹션별 승인 게이트로 설계 제시
6. 설계 문서 저장
7. self-review
8. 사용자 리뷰
9. writing-plans로 전이

설계 의도. LLM의 action bias 억제. 요청을 받으면 즉시 실행하려는 경향을 물리적으로 차단한다. HARD-GATE는 설계 승인 전까지 구현 스킬을 못 부르게 한다. 체크리스트는 "탐색 → 질문 → 설계 → 문서화 → 검증" 순서를 강제해서 단계 건너뛰기를 막는다.

한계.

• 컨텍스트 수집보다는 설계 합의에 초점. 프로젝트 맥락 자체를 축적하지는 않는다 (1단계 탐색은 일회성).
• 완전 신규 아이디어 발굴(what should we build?)은 다루지 않는다. 이미 "뭘 만들지"는 정해져 있다고 전제한다.
• 한 번의 대화에서 끝나므로 세션 간 지식 누적이 없다.

언제 쓰나. "뭘 만들지는 알지만 어떻게 만들지 합의가 필요할 때." 사실상 컨텍스트 수집 단계의 마지막 구간이자 스펙 단계로 가는 다리다.

1-5. 디스커버리 파이프라인 — BMAD Analyst phase

원리. 애자일 워크플로우의 최상류에 Analyst 에이전트를 둔다. 아이디어 발굴부터 프로젝트 브리프까지를 담당한다. 하위에 bmad-brainstorming, 리서치 하위 스킬을 둔다.

작동.

1. 사용자가 "뭘 만들지" 모를 때 bmad-brainstorming이 다양한 기법(직접 선택 / AI 추천 / 랜덤)으로 아이디어를 발산시킨다
2. 아이디어를 테마로 그룹화하고 우선순위를 매긴다
3. 외부 리서치(시장, 경쟁, 기술)를 수행한다
4. Project brief를 산출한다 → PM이 PRD → Architect가 설계 → Dev가 구현

설계 의도. "what should we even build?"를 명시적인 단계로 만든다. 이후 단계(PRD, 설계, 구현)가 돌아가는 전제인 "아이디어가 정해졌다"를 이 단계가 담보한다.

혼동 주의: 같은 단어를 써도 역할이 다르다. BMAD bmad-brainstorming은 아이디어를 만드는 단계, superpowers brainstorming은 아이디어를 스펙으로 굳히는 단계다. BMAD 체인으로 치면 superpowers의 brainstorming은 Architect 단계에 해당한다.

한계.

• 무거운 체계. 이미 뭘 만들지 명확하면 오버헤드.
• 산출물이 Analyst 세션 문서에 그친다. 장기 기억으로 연결하려면 추가 장치가 필요.
• BMAD 전체 워크플로우에 얽혀 있어 단독으로 뽑기 어렵다.

언제 쓰나. 제로베이스에서 신규 이니셔티브 착수. 기획 단계의 초기 스파이크.

1-6. 3-Layer 위키 — llm-wiki

원리. 지식을 세 층으로 분리한다.

그리고 별도로 specs/·plans/는 작업 산출물 층이다.

작동. 세 개의 오퍼레이션이 있다.

• Ingest: raw/ 원문 → wiki/에 summary + entity/concept 페이지 생성. 기존 페이지가 있으면 병합 (덮어쓰기 금지).
• Query: index.md → 관련 페이지 탐색 → wikilink 따라가기 → 답변 + citations. 재사용 가치가 있는 답변은 comparison/synthesis로 환류.
• Lint: 모순·고아·누락·drift 점검. 8개 항목, 일부 자동 수정. 5개 ingest마다 또는 주 1회.

설계 의도.

• 소유권 분리: 원본은 사람, 요약·구조는 LLM. 누가 뭘 건드려도 되는지 명확.
• Append-only 로그: log.md에 모든 변경이 시간순 기록. 에이전트의 작업 이력이 추적된다.
• Wikilink 그래프: 선형이 아닌 그래프 구조. 양방향 링크. 네비게이션이 탐색적이다.
• 갈등 보존: 모순되는 주장은 > [!warning]로 표기. 삭제 금지. 양쪽 모두 보존.

한계.

• 초기 인프라(index, log, Schema) 세팅 비용.
• ingest가 "진짜 할 만한 가치가 있는 원문"을 요구한다. 잡다한 소스를 쌓으면 신호가 묻힌다.
• 사람이 직접 읽기에 최적화된 건 아니다 (에이전트 소비 우선).

언제 쓰나. 도메인 지식이 장기간에 걸쳐 축적되는 영역. 팀·조직 단위 학습. 외부 자료를 지속적으로 소화해 내 것으로 만들 때.

2. 같은 자 위에 올리기: 네 개의 비교축

축 1 — 소유자

소유자가 다르면 누가 drift 책임을 지는가가 달라진다. 사람 소유면 커밋 리뷰가, 에이전트 소유면 lint/self-review가 검증 포인트가 된다.

축 2 — 시점

• Pre-task: 작업 시작 전부터 준비된 것. CLAUDE.md, Memory Bank, llm-wiki.
• In-task: 작업 중 생성/갱신되는 것. brainstorming, BMAD Analyst.
• Cross-task: 작업을 넘나들며 누적되는 것. Claude Code memory, llm-wiki.

llm-wiki는 pre-task이기도 cross-task이기도 하다. 작업 전에 참조되고, 작업의 산물이 환류로 들어간다. 나머지는 대체로 한쪽에 치우친다.

축 3 — 구조

세 구조가 각각 다른 탐색 비용을 만든다. 단일 파일은 전체 스캔, 번들은 선택적 로드, 그래프는 탐색 네비게이션. 대화 기록 계열은 구조가 없고 그 자리의 산출물이 전부다.

축 4 — 검증 장치

drift가 생기는 걸 막거나 감지하는 기제가 있는가.

검증 장치가 없는 패턴은 커진다. 커지면 거짓말을 한다. 이것이 컨텍스트 수집 패턴의 수명을 좌우한다.

3. 실무 매핑: 상황별 선택 가이드

상황 A — 기존 프로젝트에 Claude 처음 도입

• 최우선: CLAUDE.md 작성. 규약·경로·"절대 하지 말 것" 목록.
• 이후 3-4주: 쓰면서 반복 등장하는 피드백을 Claude Code memory에 축적.
• 위키나 Memory Bank는 아직: 쌓을 것이 없다.

상황 B — 신규 프로젝트 착수

• 초기: BMAD Analyst 또는 bmad-brainstorming — 뭘 만들지 결정.
• 아이디어 확정 후: superpowers 전체 체인 (brainstorming → writing-plans → executing-plans).
• 확정된 결정은 CLAUDE.md로 승격.

상황 C — 도메인 지식 장기 축적

외부 자료(논문, 글, 블로그)를 지속적으로 소화해 팀 자산으로 만드는 포지션.

• 핵심: llm-wiki 3-Layer.
• 보조: 결정/합의는 project 메모리에 별도 기록. 위키와는 다른 축.

상황 D — 세션이 자주 끊김

툴 재시작, 에이전트 교체, 컨텍스트 윈도우 압축이 빈번한 경우.

• 메인: Memory Bank 6파일. 매 세션 시작 시 자동 로드.
• 주의: activeContext.md 갱신이 누락되기 쉽다. 종료 트리거를 명시적으로.

상황 E — 단건 스파이크

1회성 분석, 탐색, 실험.

• CLAUDE.md만으로 충분.
• 굳이 위키에 환류 안 해도 됨. 재사용 가치가 분명할 때만 환류.

4. 내가 굳히는 조합: 세 층의 스택

여섯 패턴 중 하나만 고르는 건 대개 틀린 답이다. 레이어가 다르기 때문이다. 나는 다음 세 층으로 쌓는다.

층 1 — 불변 규약: CLAUDE.md

프로젝트 루트. 규약·경로·빌드 명령·"절대 하지 말 것" 목록. 바뀌지 않는 것만 담는다. 커밋으로 리뷰.

층 2 — 작업 기억: Claude Code memory

내 역할(user), 피드백 이력(feedback), 진행 중인 이니셔티브(project), 외부 시스템 포인터(reference). 에이전트가 자동 저장하고 MEMORY.md로 인덱스. CLAUDE.md가 "규약"이라면 이쪽은 **"현재 상태"**다.

층 3 — 도메인 지식: llm-wiki 3-Layer

도메인의 논문, 외부 글, 지난 분석 결과를 raw/에 수집하고 wiki/로 구조화. specs/·plans/는 필요 시 생성. 장기 자산이다.

상단의 단계 도구: brainstorming

세 층 위에 단계 도구로 brainstorming을 얹는다. 새 작업을 시작할 때 brainstorming이 1-3층의 컨텍스트를 조합해서 설계안을 만든다. brainstorming은 "컨텍스트 저장소"가 아니라 컨텍스트 소비자 겸 정제기로 쓴다.

BMAD Analyst는 일상 흐름에는 과하다. 신규 프로젝트 착수 때만 꺼낸다. Memory Bank는 내 경우 세션 연속성이 충분해서 쓰지 않는다. 도구 특성에 따라 선택하면 된다.

한 그림으로

      ┌─────────────────────────┐
      │  brainstorming (단계 도구) │   ← 컨텍스트 소비자
      └───────────▲──────────────┘
                  │
 ┌────────────────┼────────────────┐
 │                │                │
 ▼                ▼                ▼
CLAUDE.md    memory/*.md     llm-wiki/
(불변 규약)   (현재 상태)      (도메인 지식)
 사람          에이전트         계층 분리

세 저장소가 각자 다른 시간 스케일을 가진다. CLAUDE.md는 분기별, memory는 주별, llm-wiki는 월·분기별로 진화한다. brainstorming은 작업 한 건 단위로 불타고 사라진다.

마무리: 컨텍스트는 코드보다 오래 산다

여섯 패턴은 각기 다른 질문에 답한다.

• CLAUDE.md: 이 프로젝트의 불변 규약은?
• 분산 메모리: 이 사용자의 선호와 이력은?
• Memory Bank: 지금 프로젝트가 어디까지 와 있나?
• brainstorming: 이 아이디어의 설계는?
• BMAD Analyst: 우리가 뭘 만들어야 하나?
• llm-wiki: 이 도메인의 지식은 어떻게 구조화되어 있나?

질문이 다르므로 답을 하나로 묶을 수 없다. 컨텍스트 수집은 단일 스킬의 문제가 아니라 레이어 선택의 문제다. 각 레이어는 다른 시점·소유자·구조·검증 장치를 가진다. 내 작업의 시간 스케일(한 번의 스파이크인가, 장기 축적인가)과 컨텍스트의 휘발성(불변 규약인가, 어제의 결정인가)에 따라 층을 조합한다.

그리고 하나 더. 코드는 6개월 뒤에도 살아 있지만, 그 코드를 왜 썼는지는 대개 사라진다. 컨텍스트 수집 단계는 그 "왜"를 다음 자신에게, 그리고 다음 에이전트에게 남기는 유일한 장치다. 잘 설계된 저장소 한 세트가 몇 시간짜리 재설명을 몇 분짜리 참조로 바꾼다.

가장 좋은 스킬은 하나가 아니다. 가장 좋은 스택이 있을 뿐이다.