[바이브코딩] 03. Claude 5는 왜 Context Engineering을 이야기할까? - Prompt에서 Context로

TL;DR

Anthropic은 Claude 5 세대 모델을 소개하며 새로운 방향을 제시한다.

Claude Code의 시스템 프롬프트를 대폭 줄였지만 성능 저하는 크지 않았다고 설명한다.

예전에는 규칙을 많이 적을수록 AI가 안정적으로 동작했다.

Claude 5는 다른 방향을 제시한다.

규칙보다 컨텍스트가 중요하다.

이번 글에서는 AI 개발 방식이 Prompt Engineering에서 Context Engineering으로 바뀌는 이유를 정리한다.

ㅁ 이전 글에서 이야기한 Context Engineering

Context Engineering은 이번에 처음 등장한 개념이 아니다.

이전 글에서도 프롬프트의 한계와 컨텍스트의 중요성을 여러 관점에서 정리했다.

ㅇ Context Engineering 관련 글 모아보기

• Prompt Engineering에서 Context Engineering으로 발전하는 과정
• 문서 기반 개발과 Context Engineering의 관계
• SSOT, MECE를 활용한 컨텍스트 구조화
• Garbage Context와 Context Pollution을 줄이는 방법
• Context를 넘어 Harness Engineering으로 발전하는 과정

바이브코딩 시리즈에서도 같은 내용을 이어서 다뤘다.

ㅇ [바이브코딩] 01. AI와 일할 때 왜 문서가 필요할까?

• PRD, UX, 기술 스택, 데이터베이스, 도메인, API의 역할을 구분한다.
• 하나의 결정은 하나의 문서에서 관리한다.
• SSOT와 MECE를 통해 사람과 AI가 같은 기준을 보게 한다.
• 문서를 이전 작업의 결과이자 다음 작업의 컨텍스트로 사용한다.

ㅇ [바이브코딩] 02. AI와 오래 협업하려면 어떻게 해야 할까?

• 하나의 대화에서는 하나의 주제에 집중한다.
• 현재 주제에 맞는 역할과 작업 범위를 지정한다.
• 이미 확정된 문서를 현재 작업의 기준으로 제공한다.
• Plan Mode에서 방향을 논의한 뒤 결정된 내용만 문서로 남긴다.
• 완성한 문서를 다음 대화의 컨텍스트로 사용한다.

기존 글의 핵심은 명확하다.

좋은 프롬프트를 반복해서 작성하는 것보다 AI가 참고할 기준을 구조화하는 일이 중요하다.

 

지금까지는 내가 AI와 협업하며 발견한 필요성을 중심으로 Context Engineering을 정리했다.

이번에는 Claude 5를 만든 Anthropic이 같은 문제를 어떻게 바라보고 있는지 살펴본다.

 

ㅁ Claude 5에서 달라진 것은 무엇일까?

Claude 5가 Context Engineering이라는 새로운 개념을 만든 것은 아니다.

달라진 점은 모델의 능력이 발전하면서 컨텍스트를 구성하는 방법도 바뀌었다는 것이다.

Anthropic은 Claude 5 세대 모델을 적용하며 Claude Code의 시스템 프롬프트를 80% 이상 제거했다고 설명한다.

 

기존에는 모델의 실수를 막기 위해 많은 규칙을 미리 넣었다.

항상 테스트를 작성한다.
코드 리뷰 절차를 따른다.
작업 후 검증한다.
문서를 임의로 변경하지 않는다.
불필요한 주석을 작성하지 않는다.

이런 규칙은 각각 필요할 수 있다.

하지만 모든 작업에 항상 필요한 것은 아니다.

규칙이 많아지면 서로 충돌하기도 한다.

현재 작업과 무관한 정보가 컨텍스트를 차지하기도 한다.

 

Claude 5에서는 모든 규칙을 앞에 넣는 대신, 모델이 주변 코드와 현재 작업을 보고 판단하게 한다.

검증이 필요한 순간에는 검증 절차를 불러온다.

코드 리뷰가 필요한 순간에는 코드 리뷰 Skill을 불러온다.

배포 작업에서는 배포 문서와 설정을 확인한다.

기존 방식

모든 규칙
    ↓
모든 문서
    ↓
사용자 요청
    ↓
작업 수행

Claude 5 방식

사용자 요청
    ↓
현재 작업 판단
    ↓
필요한 문서와 Skill 선택
    ↓
작업 수행

중요한 변화는 컨텍스트의 양이 아니다.

컨텍스트를 불러오는 시점과 구조다.

ㅁ 모든 것을 제공하는 방식에서 필요한 것을 찾는 방식으로

기존 Context Engineering에서는 AI에게 충분한 정보를 제공하는 일이 중요했다.

Claude 5에서는 여기서 한 단계 더 나아간다.

모든 정보를 한 번에 제공하지 않는다.

AI가 현재 작업에 필요한 정보를 선택적으로 찾게 한다.

Anthropic은 이를 Progressive Disclosure라고 설명한다.

Progressive Disclosure는 필요한 정보를 필요한 시점에 점진적으로 공개하는 방식이다.

예를 들어 API를 구현할 때는 다음 정보를 확인한다.

CLAUDE.md
    ↓
PRD
    ↓
API 문서
    ↓
Backend Convention
    ↓
관련 코드와 테스트

배포를 검증할 때는 다른 정보를 확인한다.

CLAUDE.md
    ↓
Verification Skill
    ↓
배포 문서
    ↓
CI/CD 설정
    ↓
테스트 결과

API 구현에 배포 절차 전체를 넣을 필요는 없다.

문서 검수에 데이터베이스 운영 규칙을 모두 넣을 필요도 없다.

현재 작업에 필요한 컨텍스트만 선택한다.

내가 이전 글에서 이야기한 내용은 다음과 같다.

문서를 다음 대화의 컨텍스트로 사용한다.

 

Claude 5가 추가로 강조하는 내용은 다음과 같다.

그 문서를 모두 제공하지 않고, 현재 작업에 필요한 문서만 불러온다.

Context Engineering의 방향이 바뀐 것은 아니다.

적용 방법이 더 구체적으로 발전했다.

 

ㅁ 필요한 정보를 불러온다는 것은 무엇일까?

필요한 정보를 불러온다는 것은 모든 문서를 항상 기억하게 만드는 것이 아니다.

프로젝트 문서를 목적별로 나눈다.

현재 작업과 관련된 문서만 찾아 읽게 한다.

예를 들어 다음처럼 구성할 수 있다.

project/
├── CLAUDE.md
├── docs/
│   ├── product/
│   │   └── PRD.md
│   ├── architecture/
│   │   ├── SYSTEM.md
│   │   └── DATABASE.md
│   ├── development/
│   │   ├── BACKEND.md
│   │   └── FRONTEND.md
│   └── operations/
│       └── DEPLOYMENT.md
└── .claude/
    └── skills/
        ├── code-review/
        ├── document-review/
        └── release-check/

이 구조에서 CLAUDE.md는 모든 내용을 설명하지 않는다.

어디에서 어떤 정보를 찾아야 하는지 알려준다.

ㅁ CLAUDE.md는 규칙집이 아니라 지도다

많은 사람이 CLAUDE.md에 모든 규칙을 넣는다.

하지만 파일이 커지면 문제가 생긴다.

• 현재 작업과 무관한 정보까지 포함된다.
• 중요한 규칙과 사소한 규칙이 섞인다.
• 오래된 내용이 현재 기준과 충돌한다.
• 같은 내용이 여러 문서에 중복된다.
• 유지보수가 어려워진다.

Claude 5에서 CLAUDE.md는 백과사전이 아니다.

프로젝트의 지도다.

프로젝트의 목적
    ↓
공통 작업 원칙
    ↓
문서의 위치
    ↓
작업별 Skill 안내

상세 내용은 각 문서가 담당한다.

CLAUDE.md
    ↓
PRD.md
    ↓
DOMAIN.md
    ↓
API.md
    ↓
DATABASE.md
    ↓
DEPLOYMENT.md

CLAUDE.md는 모든 내용을 담지 않는다.

필요한 컨텍스트로 이동하게 한다.

ㅁ 문서는 SSOT가 되어야 한다

Context Engineering이 제대로 동작하려면 문서를 신뢰할 수 있어야 한다.

같은 요구사항이 여러 문서에 다르게 적혀 있으면 문제가 생긴다.

AI는 무엇을 기준으로 판단해야 할지 알기 어렵다.

그래서 문서는 SSOT 역할을 해야 한다.

예를 들어 다음처럼 기준을 정한다.

제품 요구사항      → PRD.md
사용자 흐름        → UX.md
도메인 규칙        → DOMAIN.md
API 계약           → API.md
데이터 구조        → DATABASE.md
배포 절차          → DEPLOYMENT.md

하나의 정보는 하나의 기준 문서에서 관리한다.

다른 문서에서는 링크로 참조한다.

이 방식은 SSOT와 MECE 원칙과 연결된다.

문서가 중복되지 않아야 한다.

역할도 명확하게 나뉘어야 한다.

그래야 AI도 필요한 컨텍스트를 정확하게 찾는다.

ㅁ Skill은 특정 작업을 위한 절차서다

문서는 프로젝트 정보를 설명한다.

Skill은 특정 작업을 수행하는 방법을 설명한다.

코드 리뷰 Skill에는 다음 절차를 넣을 수 있다.

1. 변경된 파일을 확인한다.
2. 관련 요구사항 문서를 읽는다.
3. 기존 코드 패턴과 비교한다.
4. 오류 가능성과 영향 범위를 확인한다.
5. 테스트 누락 여부를 검토한다.
6. 결과를 정해진 형식으로 작성한다.

 

배포 검증 Skill에는 다른 절차를 넣는다.

1. 변경 범위를 확인한다.
2. 테스트 결과를 확인한다.
3. 환경 변수를 점검한다.
4. 마이그레이션 여부를 확인한다.
5. 롤백 절차를 확인한다.
6. 배포 가능 여부를 판단한다.

이 절차를 매번 프롬프트에 입력할 필요는 없다.

Skill로 분리한다.

필요한 순간에만 불러온다.

Skill은 AI를 위한 표준 작업 절차서다.

ㅁ Prompt보다 중요한 것은 프로젝트 구조다

AI가 장기 프로젝트를 이해하려면 한 번의 멋진 문장으로는 부족하다.

AI가 정보를 찾을 수 있는 구조가 필요하다.

사람이 새로운 프로젝트에 들어가면 다음 순서로 이해한다.

• 프로젝트 소개를 읽는다.
• 시스템 구조를 본다.
• 필요한 문서를 찾는다.
• 관련 코드를 확인한다.
• 작업 절차를 따른다.

AI도 크게 다르지 않다.

좋은 프롬프트 하나로 모든 문제를 해결하려 하면 안 된다.

AI가 필요한 정보를 찾아갈 수 있는 환경을 만들어야 한다.

다음처럼 정리할 수 있다.

Prompt
    ↓
현재 요청을 전달한다.

Context
    ↓
요청을 이해하는 정보를 제공한다.

Structure
    ↓
정보를 찾을 수 있게 한다.

Skill
    ↓
작업 수행 절차를 제공한다.

ㅁ Claude 5는 하나의 모델이 아니다

Anthropic의 글 제목은 The New Rules of Context Engineering for Claude 5 Generation Models이다.

여기서 나는 "Claude 5"를 하나의 모델 이름으로 이해하였다.

하지만 Anthropic이 말하는 Claude 5는 특정 모델 하나가 아니다.

5세대 모델군(Generation Models) 을 의미한다.

현재 기준으로는 다음 모델이 여기에 포함된다.

• Sonnet 5
• Fable 5

즉, Context Engineering에 대한 새로운 권장 사항은 Claude 5 세대 전체를 대상으로 설명하는 내용이다.

반면 Opus 4.8과 Haiku 4.5는 각각 다른 계열의 모델이다.

물론 이 모델들도 Context Engineering을 활용할 수 있다.

하지만 Anthropic이 이야기하는 새로운 설계 철학은 Claude 5 세대를 중심으로 설명된다.

예를 들어 Claude Code에서 모델을 선택하면 다음과 같은 목록을 볼 수 있다.

Sonnet 5
Fable 5
Opus 4.8
Haiku 4.5

 

여기서 Sonnet 5와 Fable 5가 같은 세대에 속한다.

 

ㅁ Claude 5에서는 모델 선택도 영향을 줄까?

Context Engineering 원칙은 Claude 5 세대 모델을 중심으로 설명한다.

현재 기준으로 Sonnet 5와 Fable 5가 해당한다.

모델마다 긴 작업과 컨텍스트 탐색 능력에 차이가 있다.

Sonnet 5는 일반 개발과 문서 작업에 적합하다.

코드 수정과 일상적인 작업에 효율적이다.

Fable 5는 많은 문서와 코드를 장시간 검토하는 작업에 적합하다.

대규모 리팩터링과 긴 작업에 유리하다.

Opus 4.8과 Haiku 4.5도 컨텍스트를 활용한다.

다만 Claude 5의 새로운 작업 방식은 Sonnet 5와 Fable 5를 중심으로 이해하는 것이 자연스럽다.

모델이 좋아도 문서 구조는 필요하다.

모델의 능력이 좋아질수록 규칙을 더 많이 줄 필요는 없다.

판단에 필요한 근거와 구조를 제공해야 한다.

ㅁ AI와 오래 협업하려면 무엇이 필요할까?

AI와 한두 번 대화하는 것은 어렵지 않다.

같은 프로젝트에서 며칠이나 몇 달 동안 협업하는 것은 다르다.

안정적인 작업 흐름이 필요하다.

Plan
    ↓
작업 범위와 방향을 정한다.

Document
    ↓
결정한 내용을 문서에 반영한다.

Implement
    ↓
문서를 기준으로 구현한다.

Verify
    ↓
구현 결과를 검증한다.

Update
    ↓
변경 내용을 다시 문서에 반영한다.

이 과정에서 문서는 단순한 기록이 아니다.

사람과 AI가 함께 보는 기준이다.

대화에서 결정한 내용을 문서에 반영하지 않으면 다음 세션에서 다시 설명해야 한다.

문서로 남기면 모델이나 세션이 바뀌어도 작업을 이어갈 수 있다.

ㅁ 앞으로의 AI 개발자는 무엇을 잘해야 할까?

예전에는 코드를 많이 작성하는 사람이 생산성이 높았다.

생성형 AI가 등장한 뒤에는 좋은 프롬프트 작성 능력이 중요해졌다.

앞으로는 프로젝트 구조와 컨텍스트 설계 능력이 더 중요해질 수 있다.

사람의 역할은 단순히 명령을 작성하는 것이 아니다.

• 판단 기준을 정한다.
• 정보를 기록할 위치를 정한다.
• 문서 사이의 관계를 설계한다.
• 작업 절차를 정의한다.
• 검증 기준을 제공한다.

Prompt Engineer를 넘어 Context Architect의 역할이 필요하다.

ㅁ 마무리

Claude 5가 말하는 Context Engineering은 새로운 프롬프트 작성법이 아니다.

AI와 일하는 방식의 변화다.

예전에는 AI에게 더 많은 규칙을 주는 것이 중요했다.

이제는 AI가 필요한 정보를 찾고 판단할 수 있도록 프로젝트를 구조화해야 한다.

CLAUDE.md는 거대한 규칙집이 아니다.

프로젝트의 지도다.

PRD, UX, 도메인, 데이터베이스, API 문서는 각각 SSOT 역할을 해야 한다.

코드 리뷰, 문서 검수, 배포 확인 같은 반복 작업은 Skill로 분리한다.

좋은 AI 협업은 좋은 프롬프트 하나에서 시작하지 않는다.

잘 정리된 문서와 프로젝트 구조에서 시작한다.

필요한 순간에 적절한 정보를 제공하는 컨텍스트 설계가 필요하다.

앞선 글에서 이야기한 SSOT, MECE, Plan Mode, 문서화는 독립된 개념이 아니다.

모두 AI와 오래 협업하기 위한 Context Engineering의 구성 요소다.

ㅁ 참고 자료

ㅇ Anthropic, The New Rules of Context Engineering for Claude 5 Generation Models

ㅇ [바이브코딩] 01. AI와 일할 때 왜 문서가 필요할까? - SSOT, MECE, 컨텍스트

ㅇ [바이브코딩] 02. AI와 오래 협업하려면 어떻게 해야 할까? - Plan Mode, 문서화, 컨텍스트