AI를 오래 써본 사람일수록 비슷한 장면을 반복해서 만납니다.처음엔 꽤 잘 맞습니다. 내 문체도 따라오고, 맥락도 제법 이해합니다. 그런데 대화가 길어질수록 흐려집니다. 내가 어떤 기준으로 판단하는 사람인지, 무엇을 중요하게 보는지, 어떤 방식으로 일하는지 다시 설명해야 합니다. 여기서 문제는 프롬프트가 짧아서가 아닙니다. 문제는 필요한 정보가 필요한 순간에, 필요한 형태로 로딩되지 않는다는 것입니다. 이 글의 핵심도 바로 여기에 있습니다. 프롬프트보다 중요한 것은 컨텍스트 구조이며, 해법은 거대한 데이터베이스보다 잘 설계된 파일 시스템에 가깝다는 주장입니다.
1. 문제는 질문이 아니라 구조다
기존 방식은 대체로 이렇습니다.
[거대한 시스템 프롬프트 1개]
├─ 내 소개
├─ 내 목표
├─ 내 문체
├─ 내 연락처
├─ 미팅 기록
├─ 콘텐츠 규칙
└─ 우선순위 체계
↓
정보 과다
규칙 충돌
주의력 분산
중간 맥락 망각
겉으로 보기에는 정보가 많을수록 좋아 보입니다.하지만 실제로는 반대입니다. LLM은 유한한 컨텍스트 안에서 모든 정보를 똑같이 다루지 못합니다. 결국 다 넣는다고 다 잘 쓰는 것이 아니라, 오히려 핵심 규칙이 묻히고 현재 작업과 무관한 정보까지 함께 경쟁하게 됩니다. 그래서 중요한 건 더 많이 넣는 것이 아니라, 지금 필요한 것만 정확히 보이게 만드는 것입니다.
2. 해법은 ‘단계적 로딩’이다
이 글이 제안하는 구조는 단순합니다.
[사용자 요청]
↓
"블로그 써줘" / "미팅 준비해줘" / "이번 주 우선순위 정리해줘"
↓
[1단계: 라우팅]
무슨 작업인지 판별
↓
[2단계: 모듈 지침]
이 작업에서 어떤 규칙으로 행동할지 결정
↓
[3단계: 실제 데이터]
필요한 파일만 마지막에 로딩
↓
[AI 실행]
핵심은 처음부터 모든 파일을 다 읽지 않는 것입니다.먼저 작업 종류를 판별하고, 다음으로 그 도메인의 규칙을 불러오고, 마지막에 실제 로그와 템플릿, 기록을 읽습니다. 이 3단계 구조 덕분에 AI는 “전체를 다 아는 상태”가 아니라 “지금 이 작업에 필요한 정보만 정확히 보는 상태”로 일하게 됩니다. 글에서는 이를 Progressive Disclosure, 즉 단계적 노출 구조로 설명합니다.
3. 이 시스템은 파일 몇 개가 아니라 ‘작동 원리’다
구조를 더 단순하게 그리면 이렇습니다.
→ 이 요청이 무엇인지 판별하는 라우터
CONTENT.md / OPERATIONS.md / NETWORK.md
→ 각 도메인에서 어떻게 행동할지 정의하는 모듈 지침
JSONL / YAML / Markdown
→ 실제 로그, 설정, 기록, 템플릿, 리서치 데이터
여기서 중요한 건 파일명이 아니라 역할 분리입니다.
- 라우팅 파일은 “무슨 일인가”를 판단합니다.
- 모듈 지침은 “어떻게 행동할 것인가”를 정합니다.
- 실제 데이터 파일은 “무엇을 참고할 것인가”를 제공합니다.
즉, 정보 저장과 실행 규칙이 분리되어 있습니다.그래서 AI는 무작정 많은 문서를 읽는 대신, 먼저 방향을 잡고 그다음 좁혀 들어갑니다. 이게 성능과 일관성을 동시에 높이는 구조입니다.
4. 거대한 프롬프트를 버리고, 계층을 만든다
이 시스템의 또 다른 축은 지시 체계의 계층화입니다.
[Repository Level]
→ 전체 지도, 온보딩, 공통 원칙
↓
[Brain Level]
→ 핵심 규칙, 의사결정 테이블
↓
[Module Level]
CONTENT.md / NETWORK.md / OPERATIONS.md
→ 도메인별 행동 규칙
왜 이게 중요할까요.콘텐츠 작성 규칙과 네트워킹 규칙과 운영 규칙을 한 문서 안에 다 넣으면, AI는 어느 상황에서 어떤 규칙이 우선인지 헷갈리기 쉽습니다. 반면 레벨을 나누면 적용 범위가 분명해집니다. 특정 모듈만 바꿔도 다른 영역까지 흔들릴 가능성이 줄어듭니다. 결국 이 구조는 정보 정리가 아니라 규칙 충돌 방지를 위한 설계입니다.
5. 파일 시스템이 곧 메모리다
이 글에서 가장 흥미로운 대목은 여기입니다.
[Git Repository]
├─ Markdown → 서술형 지식, 템플릿, 보이스 가이드
├─ YAML → 목표, 설정, 규칙, 계층 구조
└─ JSONL → 로그, 사건, 의사결정, 실패 기록
이 구조는 왜 강력할까요.
Markdown = 사람이 읽기 쉽다
YAML = 구조를 표현하기 쉽다
JSONL = 한 줄씩 쌓기 쉽다
즉, 이 시스템은 “AI가 읽기 좋은 포맷”과 “사람이 관리하기 좋은 포맷”이 겹치는 지점을 택합니다.별도 데이터베이스, 벡터 스토어, 복잡한 파이프라인 없이도 파일 자체가 기억 장치가 될 수 있다는 발상입니다. 특히 JSONL의 append-only 구조는 과거 기록을 통째로 덮어써서 날려버리는 위험을 줄이는 안전장치로 설명됩니다.
6. 중요한 건 ‘사실 메모리’가 아니라 ‘판단 메모리’다
보통의 세컨드 브레인은 이렇게 끝납니다.
[사실 저장]
- 무슨 일이 있었는가
하지만 이 글의 시스템은 여기서 멈추지 않습니다.
[사실 + 판단 저장]
- experiences.jsonl → 어떤 일이 중요했는가
- decisions.jsonl → 왜 그렇게 결정했는가
- failures.jsonl → 무엇이 잘못됐는가
이 차이는 작지 않습니다.사실만 가진 AI는 일반론을 말합니다. 하지만 판단 기록까지 가진 AI는 “이 사람이 어떤 기준으로 선택하는가”를 참고할 수 있습니다. 즉, AI가 내 파일을 갖고 있는 것과, 내 판단 방식을 참고할 수 있는 것은 전혀 다른 수준입니다. 이 구조는 개인 지식관리 시스템을 메모장 수준에서 운영체제 수준으로 끌어올립니다.
7. 분리해서 저장하되, 연결해서 사고한다
이 시스템은 파일을 잘게 나누지만 사고는 끊지 않습니다.
contacts.jsonl
↑ contact_id
interactions.jsonl
↓
예를 들어 이런 흐름입니다.
"Sarah와 미팅 준비"
1) contacts에서 Sarah 조회
2) interactions에서 과거 대화 확인
3) todos에서 남은 액션 확인
4) 미팅 브리프 생성
즉, 파일은 분리되어 있지만 reasoning은 연결됩니다.데이터베이스 없이도 참조 키를 통해 관계형 사고가 가능하도록 설계한 것입니다. 이 구조가 중요한 이유는 분류가 목적이 아니기 때문입니다. 목적은 연결된 판단입니다.
8. 지식과 프로세스는 섞지 않는다
이 글은 또 하나의 중요한 구분을 제안합니다.
[Files] = 무엇을 알고 있는가
[Skills] = 그 일을 어떻게 수행하는가
그리고 스킬도 둘로 나눕니다.
Reference Skills
→ 자동 로딩
→ 보이스, 금지 패턴, 기본 일관성 담당
Task Skills
→ 수동 호출
→ 특정 작업 절차를 정밀하게 강제
이 구분이 좋은 이유는 분명합니다.매번 문체를 유지하는 일과, 이번 작업을 정확한 절차로 처리하는 일은 성격이 다릅니다. 하나는 일관성의 문제이고, 다른 하나는 정밀성의 문제입니다. 이것을 한 덩어리로 넣지 않고 역할별로 분리해야 AI가 덜 흔들립니다.
9. 결국 이 시스템은 ‘일하는 루프’를 만든다
이 글은 글쓰기 한 편에서 끝나지 않습니다.
아이디어
↓
리서치
↓
아웃라인
↓
초안
↓
편집
↓
발행
↓
프로모션
↓
성과 기록
↓
주간 리뷰
↓
다음 실행 조정
이 흐름이 중요한 이유는 단순합니다.AI를 “대답 잘하는 도구”에서 “운영을 보조하는 시스템”으로 바꾸기 때문입니다. 결과물 하나를 만드는 것이 목적이 아니라, 목표 → 실행 → 측정 → 리뷰 → 다음 행동으로 이어지는 루프를 만드는 것이 목적입니다. 개인 CRM, 콘텐츠 파이프라인, 주간 회고 자동화가 모두 이 안에서 연결됩니다.
10. 이 글이 남기는 가장 실무적인 교훈
마지막 교훈만 압축하면 이렇습니다.
처음 실수
- 스키마가 너무 복잡했다
- 보이스 가이드가 너무 길었다
- 모듈 경계가 모호했다
- append-only를 늦게 강제했다
수정 후 원칙
- 필드는 핵심만 남긴다
- 중요한 규칙은 앞에 둔다
- 모듈 경계는 로딩 결정이다
- append-only는 안전장치다
이건 단순한 정리 요령이 아닙니다.AI 시대의 시스템 설계 원칙에 가깝습니다. 길고 풍부한 문서가 항상 좋은 것이 아니라, 짧지만 우선순위가 분명한 구조가 더 강합니다. 정보량보다 배치가 중요하고, 저장보다 호출 방식이 중요합니다.
마지막 도식
Prompt Engineering
= 질문을 더 잘 쓰는 기술
Context Engineering
= AI가 더 잘 판단하도록
정보를 구조화하는 기술
이 글의 본질은 여기에 있습니다.앞으로 AI 활용의 격차는 누가 더 멋진 프롬프트를 쓰느냐보다, 누가 자신의 판단 기준, 작업 흐름, 금지 패턴, 기록 습관을 더 구조화하느냐에서 벌어질 가능성이 큽니다. 결국 개인 지식관리 시스템은 노트를 많이 쌓는 일이 아닙니다. 내가 일하는 방식을, AI가 읽을 수 있는 구조로 다시 설계하는 일입니다.
의견을 남겨주세요