AI 컨텍스트 엔지니어링: Notion·Claude·Cursor 분담법
AI 컨텍스트 엔지니어링 한 줄 요약
1인 창업자는 컨텍스트를 머리에 다 들고 있을 수 없어요. AI 컨텍스트 엔지니어링은 Notion에 운영 맥락, Claude Code에 실행 규칙, Cursor에 지금 보는 파일 맥락을 맡기는 식으로 기억을 나누는 작업이에요. 셋이 같은
HANDOFF.md를 보면 세션이 끊겨도 어제 한 일을 다시 설명하는 시간이 확 줄어요.
한 달 전에 같은 프로젝트를 Claude Code한테 세 번 설명했어요. 매번 처음부터. 문제는 모델이 나쁜 게 아니라, 제가 컨텍스트를 한 덩어리로 던졌다는 쪽에 가까웠어요. 제품 방향, 고객 메모, 코드 규칙, 오늘 고칠 라인까지 한 채팅에 밀어 넣으니 대화가 길어질수록 답이 어긋나더라고요.
1인 창업자 AI 워크플로우는 팀 워크플로우랑 달라요. 팀은 PM, 개발자, 마케터가 기억을 나눠 갖지만 1인은 그걸 혼자 들고 있거든요. 그러니 Notion은 “왜 하는지”, Claude Code는 “어떻게 고칠지”, Cursor는 “지금 이 줄을 어떻게 바꿀지”로 쪼개야 해요.
이미 Cursor와 Claude Code 사이에서 어느 쪽을 쓸지 고민한 적이 있다면 Claude Code vs Cursor: 가격과 워크플로우 비교를 먼저 봐도 좋아요. 여기서는 선택이 아니라 분담이 핵심이에요. 2026년 5월 기준으로 가격, 쓸 수 있는 환경, MCP(Model Context Protocol, AI 도구를 외부 서비스와 연결하는 표준)까지 같이 정리해볼게요.
1. 1인 창업자에게 AI 컨텍스트 엔지니어링이 다른 이유
1인 창업자의 컨텍스트 문제는 “프롬프트를 더 잘 쓰면 끝”이 아니에요. 제품 이유, 코드 제약, 오늘의 작은 수정이 계속 섞이기 때문에 컨텍스트 자체를 나눠야 해요.
이거 왜 1인에게 더 아플까요?
팀이면 누군가가 회의록을 잡고, 누군가가 이슈를 쪼개고, 누군가가 코드 리뷰를 해줘요. 1인은 그 역할이 전부 한 사람에게 붙어요. 아침에는 결제 화면 문구를 고치고, 점심에는 SEO 제목을 바꾸고, 밤에는 배포 에러를 봐야 하죠. 그러다 Claude Code 세션이 길어지면 “아까 그 결정”이 컨텍스트 중간에 묻혀요.
Anthropic Engineering은 context engineering 글에서 컨텍스트를 프롬프트뿐 아니라 시스템 지시, 도구, 외부 데이터, 대화 기록까지 포함한 토큰 묶음으로 봐요. Chroma의 Context Rot 리포트도 입력이 길어질수록 18개 모델에서 성능이 고르게 유지되지 않는다고 봤고요. 쉽게 말하면, 긴 대화가 항상 똑똑한 대화는 아니에요.
여기서 중요한 건 “큰 컨텍스트 윈도우가 있으니 다 넣자”가 아니에요. 컨텍스트 윈도우는 모델이 한 번에 보는 작업 공간이에요. 넓어도 잡동사니가 많으면 찾는 시간이 늘죠. 그래서 1인은 더 과감하게 나눠야 해요.
| 컨텍스트 종류 | 어디에 둠 | 이유 | 너무 많이 넣으면 |
|---|---|---|---|
| 제품이 왜 존재하는지 | Notion | 운영 판단에 필요 | Claude Code가 코드보다 사업 설명을 읽음 |
| 코딩 규칙과 금지 패턴 | CLAUDE.md |
매 세션 반복 로드 | 비용과 잡음이 늘어남 |
| 지금 고칠 파일 한 조각 | Cursor | 인라인 수정에 적합 | 전체 설계를 놓칠 수 있음 |
| 세션 종료 상태 | HANDOFF.md |
다음 세션 시작점 | 오래된 TODO가 남음 |
자동 생성 컨텍스트 파일이 비용을 늘리는 이유
ETH Zurich SRI Lab의 AGENTS.md 연구는 저장소 단위 컨텍스트 파일이 성공률을 뚜렷하게 올리지 못하면서 추론 비용을 20% 넘게 늘릴 수 있다고 봤어요. 자동 생성 파일을 그대로 두는 게 조심스러운 이유예요. 1인은 비용이 곧 운영 피로거든요.
저도 처음엔 /init이 뱉어준 200줄짜리 CLAUDE.md를 그대로 두고 한 달을 썼는데, 같은 답변에 토큰을 두 배쯤 쓰고 있더라고요. 60줄로 줄인 뒤로는 같은 작업에서 응답이 더 짧고 정확해졌어요. AI 컨텍스트 엔지니어링은 결국 “필요 없는 줄을 버리는 결정”이 절반이에요.
긴 작업은 서브에이전트로 떼어내는 방법도 있어요. 그 패턴은 Claude Code 서브에이전트 만들기 실전 가이드: 자동 위임·비용 절감 세팅까지에서 따로 다뤘고, 여기서는 더 작은 기본 단위부터 잡을게요.
2. Notion·Claude·Cursor 역할 분담표
Notion, Claude Code, Cursor는 서로 대체재라기보다 맡을 기억이 달라요. AI 컨텍스트 엔지니어링에서 도구 선택보다 더 중요한 건, 어느 도구에 어느 기억을 맡길지예요. 1인 운영에서는 “어느 도구가 더 좋나”보다 “어느 맥락을 어디에 둘까”가 먼저거든요.
셋 다 같은 내용을 기억하게 하면 더 편한 거 아닌가요?
처음엔 편해 보여요. 근데 나중에 꼬여요. Notion에 있는 고객 메모를 Cursor 규칙 파일에 붙이고, Claude Code 세션에 가격표까지 넣으면 에이전트가 지금 고칠 코드보다 주변 이야기를 더 많이 읽게 돼요. 반대로 Cursor에 지금 선택한 함수만 주면 빠르지만, 제품 방향은 모를 수 있죠.
2026-05-06 기준으로 각 도구의 쓸 수 있는 환경도 다르게 봐야 해요. 표가 길지만 이걸 한 번 잡아두면 다음에 다른 도구를 같이 살펴볼 때도 그대로 써먹을 수 있어요.
| 도구 | 맡길 컨텍스트 | 쓸 수 있는 환경 | 가격 메모 |
|---|---|---|---|
| Notion | 고객 메모, 운영 판단, 로드맵, HANDOFF 페이지 | Web, Mac·Windows 데스크톱, iOS·Android, Web Clipper, API, Notion MCP | 공식 가격 페이지 기준 Free ₩0, Plus ₩14,000, Business ₩30,000, Enterprise 맞춤 |
| Claude Code | 멀티파일 수정, 테스트 명령, 코딩 규칙, 장기 작업 | CLI, 데스크톱 Code 탭, 웹·모바일 연속 작업, VS Code·JetBrains, Chrome 베타, Slack·CI 쪽 문서 | Pro 월 $20, Max 5x 월 $100, Max 20x 월 $200 |
| Cursor | 선택 영역 수정, 단일 파일 리팩터링, 빠른 코드 탐색 | macOS·Windows·Linux 데스크톱, CLI, Web Agent, 모바일 PWA, Cloud Agents, Marketplace | Hobby Free, Pro 월 $20, Pro+ 월 $60, Ultra 월 $200 |
출처는 각각 Notion 가격·데스크톱·Web Clipper·API 문서, Claude 가격·Max 플랜·Claude Code 데스크톱 문서, Cursor 가격·다운로드·CLI를 봤어요.
저는 이 표를 처음 만든 뒤로 새 사이드 프로젝트를 시작할 때마다 30분 만에 도구별 역할을 배치할 수 있게 됐어요. 그 전엔 매번 30분씩 “Notion에 뭘 두지” 고민했거든요.
역할 분담의 한 줄 원칙
역할은 이렇게 잡으세요.
- Notion: 바뀌어도 코드 실행에 바로 필요 없는 것
- Claude Code: 코드 수정 전에 항상 알아야 하는 것
- Cursor: 지금 보고 있는 파일과 선택 영역
HANDOFF.md: 세션이 끊겼을 때 다음 세션이 바로 읽을 것
Notion을 Claude Projects로 대체하고 싶은 사람도 있을 거예요. 그럴 땐 Claude Projects 활용법: 1인 운영자 루틴 3개로 나누기를 같이 봐요. 운영 지식이 Claude 안에만 있어도 되는 프로젝트라면 Notion보다 가벼울 수 있거든요.
3. 60줄짜리 CLAUDE.md 템플릿
CLAUDE.md는 코드 에이전트가 매번 읽는 프로젝트 규칙 파일로 쓰면 돼요. CLAUDE.md 작성법의 핵심은 “많이 쓰기”가 아니라 “에이전트가 코드만 봐서는 모르는 것만 쓰기”예요.
굳이 60줄로 줄여야 할까요?
줄 수 자체가 마법은 아니에요. 근데 60줄 제한을 걸면 쓸데없는 설명을 버리게 돼요. 폴더 구조, 흔한 테스트 명령, 누구나 아는 프레임워크 설명은 에이전트가 직접 볼 수 있어요. 사람만 아는 이유를 남겨야 하죠.
아래 예시는 일반화한 템플릿이에요. 실제 프로젝트에 맞게 바꾸되, 제품명·고객명·비밀 키는 넣지 마세요.
# CLAUDE.md
## Product Boundary
- This is a solo-run product.
- Prioritize small, reversible changes.
- Do not rewrite the architecture unless asked.
## Current Stack
- Runtime: Node.js 22+
- App: Next.js
- Data: PostgreSQL
- Package manager: pnpm
## Working Rules
- Read `HANDOFF.md` before planning.
- Check the current git diff before editing.
- Keep changes scoped to the requested feature.
- Ask before touching billing, auth, or data deletion paths.
## Code Style
- Prefer existing helpers over new abstractions.
- Keep server-only code out of client components.
- Use typed inputs at module boundaries.
- Add comments only when the reason is not obvious.
## Test Commands
- Type check: `pnpm typecheck`
- Unit test: `pnpm test`
- Lint: `pnpm lint`
- Build: `pnpm build`
## Safety Rails
- Never print secrets.
- Never edit production data from local scripts.
- Never run destructive database commands without approval.
- If a test fails, report the failing command and first error.
## Handoff
- At the end of long work, update `HANDOFF.md`.
- Keep `HANDOFF.md` focused on current state, decisions, and next step.
## Compact Instructions
- Preserve product decisions, failing commands, changed files, and open risks.
- Drop old tool output unless it explains a current failure.
줄 수는 이렇게 체크하면 돼요.
# 컨텍스트 파일 길이 보기
$ wc -l CLAUDE.md HANDOFF.md
42 CLAUDE.md
18 HANDOFF.md
# /context 실행 전후 비교 (Claude Code 안에서)
# Before: 시스템 + CLAUDE.md(200줄) + 도구 정의 → 세션 시작부터 ~28% 사용
# After : 시스템 + CLAUDE.md(42줄) + 도구 정의 → 세션 시작부터 ~14% 사용
42줄짜리 CLAUDE.md로 줄인 다음에는 같은 작업에서 답이 한두 단계 더 정확해지는 게 느껴져요. 줄 수 자체보다, “에이전트가 매번 읽어야 하는 건 사람만 아는 결정”이라는 기준 하나가 박힌 게 더 컸어요.
Claude Code를 처음 세팅하는 단계가 아직 비어 있다면 Claude Code 사용법: 설치부터 첫 실행까지 5분 가이드를 먼저 끝내세요. CLAUDE.md는 설치보다 뒤예요. 순서가 바뀌면 규칙 파일만 예쁘고 실행은 안 되는 상태가 되더라고요.
4. Notion HANDOFF 페이지 구조
HANDOFF.md나 Notion HANDOFF 페이지는 세션 사이의 기억 장치예요. AI 컨텍스트 엔지니어링의 마지막 퍼즐이 바로 이 연결고리고요. 오늘의 목표, 현재 상태, 핵심 결정, 하지 말아야 할 것, 다음 스텝만 남기면 충분해요.
근데 Notion 안 쓰면요?
안 써도 돼요. 같은 내용을 HANDOFF.md로 프로젝트 루트에 두면 거의 같은 효과가 나요. Notion이 좋은 경우는 운영 메모까지 같이 봐야 할 때예요. 고객 피드백, SEO 키워드, 발행 일정처럼 코드 밖의 맥락이 계속 붙는 프로젝트라면 Notion이 편하죠.
| 필드 | 적는 내용 | 예시 |
|---|---|---|
| 현재 목표 | 이번 세션이 끝내야 할 일 | 결제 실패 화면 문구와 로깅 정리 |
| 지금 상태 | 이미 끝난 것과 남은 것 | UI 문구 수정 끝, 테스트 미실행 |
| 핵심 결정 | 나중에 까먹으면 손해인 판단 | 결제 재시도는 다음 배포로 미룸 |
| 시도 금지 | 반복 삽질 방지 | 기존 결제 SDK 교체 금지 |
| 다음 스텝 | 새 세션 첫 명령 | 실패 케이스 테스트부터 돌리기 |
Notion MCP를 처음부터 붙이지 않는 이유
Notion MCP를 붙일 수도 있어요. Notion 공식 문서는 Notion MCP를 Claude Code, Cursor, VS Code, ChatGPT 같은 AI 도구와 연결할 수 있다고 설명해요. 다만 연결 문서를 보면 사용자가 직접 로그인해서 권한을 넘기는 방식(OAuth)이 필요하고, 완전 자동 백그라운드 흐름에는 맞지 않을 수 있어요. 헤드리스 자동화가 필요하면 오래된 오픈소스 서버를 쓸 수 있지만, 공식 문서가 더 이상 적극 관리되지 않는 패키지라고 말해요.
그래서 1인 운영자는 처음부터 Notion MCP를 붙이지 않아도 돼요. 먼저 HANDOFF 페이지를 사람이 직접 갱신하세요. 자동화는 그다음에 붙여도 늦지 않아요. 이 흐름 위에서 루틴을 더 쪼개고 싶다면 Claude Projects 활용법: 1인 운영자 루틴 3개로 나누기가 더 가까워요.
# 새 세션 시작 전에 사람이 보는 순서
open HANDOFF.md
# Claude Code 안에서 첫 요청 예시
# HANDOFF.md를 먼저 읽고, 현재 목표와 다음 스텝만 요약한 뒤 작업 계획을 잡아줘.
저는 이번 봄에 1인 사이드 프로젝트(피코악스 발행 파이프라인)에서 1주일 동안 HANDOFF.md만 손으로 갱신해봤어요. 새 세션을 열 때마다 “어제 어디까지 했더라” 하면서 채팅을 위로 스크롤하던 시간이 거의 사라지더라고요. 30초만 적어두면 5분짜리 재설명을 통째로 줄일 수 있어요. 특히 결제 화면을 한 주 동안 손볼 때, 어제 결정사항을 다시 설명하지 않아도 돼서 첫 1시간이 통째로 살아났어요.
5. MCP 서버 다이어트 체크리스트
MCP 서버는 필요한 도구를 붙일 때 좋지만, 켜둔 도구가 많으면 컨텍스트 윈도우 관리가 어려워져요. 1인은 “항상 켜기”보다 “필요할 때만 켜기”가 맞아요.
MCP는 표준인데 왜 줄이라는 걸까요?
표준이라서 좋은 점이 있고, 표준이라서 다 붙이고 싶어지는 문제가 있어요. Apideck의 MCP 컨텍스트 글은 세 MCP 서버가 200K 토큰 중 143K를 도구 정의로 쓴 사례를 소개해요. 같은 글은 MCP가 CLI보다 4~32배 더 많은 토큰을 쓴 벤치마크도 언급하고요. 이 수치를 내 환경에 그대로 복사하면 안 되지만, “도구 스키마도 컨텍스트를 먹는다”는 경고로는 충분해요.
여기서 최신 Claude Code 문서도 같이 봐야 해요. Claude Code의 작동 방식 문서는 MCP 도구 정의가 기본적으로 지연 로드되고, 특정 도구를 쓸 때 정의가 로드된다고 설명해요. 그래서 지금은 예전 글처럼 “MCP 3개면 무조건 71%”라고 말하면 위험해요. 직접 /context와 /mcp로 봐야 해요.
저는 GitHub·Browser·Notion·Filesystem 4개를 한꺼번에 켰다가 컨텍스트 사용량이 30%대에서 시작하는 걸 보고 충격받은 적이 있어요. 그 뒤로 “Notion만” 또는 “GitHub만”으로 줄였더니, 같은 작업에서 응답 길이가 절반 가까이 짧아졌어요.
체크리스트는 이렇게 가세요.
- 이번 세션에 실제로 쓸 MCP 서버만 켜기
- GitHub, Browser, Notion 중 하나씩만 먼저 붙이기
- 쓰지 않은 서버는 세션 전에 끄기
/context로 무엇이 공간을 쓰는지 보기/mcp로 서버별 비용을 보기- 반복 작업은 MCP보다 CLI나 작은 스크립트가 나은지 따져보기
- 긴 작업은
/compact또는HANDOFF.md로 끊기 - 서로 다른 에이전트가 같은 파일을 만지면 git worktree로 분리하기
# 작업 공간을 분리해서 충돌 줄이기
git worktree add ../my-product-fix-payment -b fix-payment
# 새 작업 공간에서 에이전트 실행
cd ../my-product-fix-payment
claude
MCP 자체를 깊게 파고 싶다면 Claude Code MCP 500K 컨텍스트: 대형 문서·DB 한 번에 읽히기를 참고하세요. 큰 컨텍스트를 쓰더라도 다이어트가 필요하다는 점은 그대로예요. 결국 AI 컨텍스트 엔지니어링은 컨텍스트를 늘리는 작업이 아니라 잘 버리는 작업이에요. 큰 가방을 샀다고 잡동사니를 다 넣을 필요는 없거든요.
자주 묻는 질문
Q1. CLAUDE.md, AGENTS.md, Notion을 1인이 셋 다 써야 하나요?
아니요. 셋 다 컨텍스트 저장소지만 역할이 달라요. CLAUDE.md는 코딩 규칙, Notion은 운영 맥락, AGENTS.md는 여러 에이전트가 같은 규칙을 봐야 할 때만 쓰세요. 셋 다 같은 내용을 넣으면 컨텍스트만 부풀 가능성이 커요.
Q2. /init으로 자동 생성한 파일을 그대로 두면 왜 별로예요?
자동 생성 파일은 에이전트가 코드만 읽어도 알 수 있는 정보를 길게 적는 경우가 많아요. ETH Zurich SRI Lab 연구도 저장소 컨텍스트 파일이 비용을 20% 넘게 늘릴 수 있다고 봤으니, 자동 생성본은 초안으로만 쓰고 30~60줄로 줄이는 편이 나아요.
Q3. Cursor와 Claude Code를 같이 쓰면 충돌하지 않나요?
충돌할 수 있어요. Cursor는 선택 영역이나 단일 파일 수정에 두고, Claude Code는 여러 파일을 오가는 작업에 두세요. 같은 시간에 둘 다 파일을 바꿀 거면 git worktree로 작업 폴더를 나누는 게 편해요.
Q4. MCP 서버는 몇 개까지 켜도 괜찮아요?
정답 숫자는 없어요. 1인 운영이면 처음엔 1~3개만 켜고 /context와 /mcp로 실제 사용량을 보세요. 최신 Claude Code는 MCP 정의를 지연 로드하지만, 서버가 많으면 도구 선택 자체가 헷갈릴 수 있어요.
Q5. 세션이 끊기면 어제 일을 또 설명해야 하나요?
HANDOFF.md를 쓰면 덜 해요. 현재 목표, 지금 상태, 핵심 결정, 시도 금지, 다음 스텝만 적고 새 세션에서 먼저 읽히세요. 오래된 대화 전체를 붙이는 것보다 이 5줄이 더 잘 먹힐 때가 많더라고요.
다음 단계
AI 컨텍스트 엔지니어링은 한 번에 끝나지 않아요. 오늘은 CLAUDE.md를 60줄 이하로 줄이고 HANDOFF.md 5필드부터 만드세요. 그다음엔 Claude Projects 활용법: 1인 운영자 루틴 3개로 나누기로 운영 루틴을 나누고, 제품 전체 흐름은 바이브 코딩 1인 SaaS 로드맵: 도구 선택부터 유통까지 5단계에서 이어가면 돼요.
CLAUDE.md 줄 수 줄여본 분은 댓글에 남은 줄 수랑 제일 버리기 힘들었던 규칙 하나만 남겨주세요.
