프롬프트는 설계 언어다
프롬프트를 귀찮은 입력이 아니라 새로운 형태의 설계 문서로 바라보는 관점
많은 개발자가 프롬프트를 "AI한테 시키는 말" 정도로 인식한다. 채팅창에 대충 요청을 입력하고, 결과가 마음에 안 들면 "AI가 별로다"라고 판단한다.
하지만 프롬프트를 조금 다른 각도에서 보면, 이것은 귀찮은 입력이 아니라 에이전틱 시대의 새로운 설계 언어에 가깝다.
"AI한테 시키는 말"로 보는 관점의 한계
프롬프트를 단순한 명령으로 취급하면, 피드백 없는 악순환에 빠지는 경향이 있다.
이 루프의 핵심 문제는 피드백이 부재한다는 데 있다. 결과가 나쁠 때 프롬프트를 개선하는 대신, AI 자체를 포기하고 직접 짜게 된다.
반면 프롬프트를 설계 언어로 인식하는 개발자의 작업 흐름은 사뭇 다르다.
결과가 나쁘면 **"내 설계가 부정확했다"**고 판단하고 개선하는 흐름이다. 이것이 설계 사고와 프롬프트의 접점이다.
프롬프트가 대체하는 전통 문서들
프롬프트가 실제로 수행하는 역할을 분석하면, 전통적 개발에서 별도로 관리하던 여러 문서를 하나로 통합한 것임을 알 수 있다.
| 전통적 문서 | 프롬프트에서의 대응 | 예시 |
|---|---|---|
| 요구사항 명세서 | 무엇을 만들지 | "결제 완료 시 이메일 알림 전송" |
| 설계 문서 | 어떤 제약조건 하에서 | "비동기 처리, 재시도 3회, 새 채널 추가 용이" |
| 코딩 컨벤션 | 어떤 스타일로 | "TypeScript, 함수형, 에러는 Result 타입으로" |
| 코드 리뷰 기준 | 무엇을 만족해야 하는지 | "모든 에러 경로에 로깅, 테스트 포함" |
| 테스트 명세 | 어떻게 검증하는지 | "정상 전송, 실패 재시도, 채널 추가 시나리오" |
한 번의 프롬프트에 이 모든 것이 들어가야 한다는 뜻은 아니다. 다만 프롬프트를 작성할 때 이 다섯 가지 관점이 존재한다는 사실을 의식하는 것이 중요하다.
프롬프트의 가치는 AI 결과물에만 있지 않다
좋은 프롬프트를 작성하는 과정 자체가 사고를 명확히 정리하는 과정이다. "AI가 이해할 수 있게 쓰려면" 자연스럽게 모호한 부분이 드러나고, 빠진 제약조건을 발견하게 된다. 이것은 과거의 설계 문서 작성과 동일한 가치를 갖는다.
프롬프트 성숙도의 스펙트럼
프롬프트를 작성하는 능력에는 뚜렷한 성장 단계가 존재한다.
각 레벨의 특징을 구체적으로 비교하면 차이가 분명해진다.
| 레벨 | 이름 | 프롬프트 예시 | AI 결과 품질 | 재사용성 |
|---|---|---|---|---|
| L1 | 명령형 | "로그인 기능 만들어줘" | 낮음 - 가정이 많음 | 없음 |
| L2 | 서술형 | "JWT 기반 로그인. 이메일과 비밀번호로 인증" | 보통 - 기본은 맞음 | 낮음 |
| L3 | 구조형 | CICV 구조로 컨텍스트, 의도, 제약, 검증 포함 | 높음 - 의도 반영 | 중간 |
| L4 | 시스템형 | CLAUDE.md + 태스크 프롬프트 + 패턴 라이브러리 | 매우 높음 - 일관적 | 높음 |
L2에서 L3로의 전환이 가장 큰 분기점이다
대부분의 개발자가 L2에 머무른다. "충분히 설명했는데 왜 AI가 못 알아듣지?"라고 느낀다면 L2 단계에 해당한다. 제약조건과 검증기준을 명시하는 L3로 넘어가면 결과 품질이 극적으로 달라지는 경우가 많다.
성숙도 레벨별 실제 결과 차이
동일한 기능 요청에 대해 각 레벨의 프롬프트가 어떤 결과 차이를 만들어내는지 살펴보면 흥미롭다.
L1 프롬프트와 결과:
파일 업로드 만들어줘.// AI 결과: 기본적이지만 빈약한 구현
export async function uploadFile(file: File) {
const formData = new FormData();
formData.append('file', file);
const res = await fetch('/api/upload', { method: 'POST', body: formData });
return res.json();
}파일 크기 제한 없음, 타입 검증 없음, 에러 처리 없음, 인증 없음 — 프로덕션에 그대로 쓸 수 없는 코드다.
L3 프롬프트와 결과:
[Context]
Next.js 16 App Router 프로젝트. 프로필 이미지 업로드.
AWS S3 버킷 설정 완료. 인증은 middleware.ts에서 세션 기반 처리.
[Intent]
인증된 사용자가 프로필 이미지를 업로드하면 S3에 저장하고,
users 테이블의 avatarUrl을 업데이트한다.
[Constraints]
- 최대 5MB, image/jpeg, image/png, image/webp만 허용
- 파일명은 UUID로 변환
- 기존 이미지 있으면 S3에서 삭제
- 업로드 실패 시 DB 미반영 (트랜잭션)
- presigned URL 방식
[Validation]
- 5MB 초과 시 400 에러
- 비허용 타입 시 400 에러
- 비인증 시 401 에러
- S3 실패 시 DB에 빈 URL 미저장// AI 결과: 제약조건이 모두 반영된 구현
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';
import { PutObjectCommand, DeleteObjectCommand } from '@aws-sdk/client-s3';
const ALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp'];
const MAX_SIZE = 5 * 1024 * 1024; // 5MB
export async function POST(req: NextRequest) {
const session = await getSession(req);
if (!session) return NextResponse.json({ error: '인증 필요' }, { status: 401 });
const { fileType, fileSize } = await req.json();
if (!ALLOWED_TYPES.includes(fileType)) {
return NextResponse.json({ error: '허용되지 않은 파일 형식' }, { status: 400 });
}
if (fileSize > MAX_SIZE) {
return NextResponse.json({ error: '파일 크기 5MB 초과' }, { status: 400 });
}
const fileKey = `avatars/${crypto.randomUUID()}.${fileType.split('/')[1]}`;
// presigned URL 발급
const uploadUrl = await getSignedUrl(s3Client, new PutObjectCommand({
Bucket: process.env.S3_BUCKET,
Key: fileKey,
ContentType: fileType,
}), { expiresIn: 300 });
// 트랜잭션: 이전 이미지 삭제 + DB 업데이트
const prevAvatar = await db.user.findUnique({
where: { id: session.userId },
select: { avatarUrl: true },
});
await db.$transaction(async (tx) => {
await tx.user.update({
where: { id: session.userId },
data: { avatarUrl: `${process.env.CDN_URL}/${fileKey}` },
});
if (prevAvatar?.avatarUrl) {
const prevKey = prevAvatar.avatarUrl.replace(`${process.env.CDN_URL}/`, '');
await s3Client.send(new DeleteObjectCommand({
Bucket: process.env.S3_BUCKET, Key: prevKey,
}));
}
});
return NextResponse.json({ uploadUrl, fileKey });
}같은 "파일 업로드"라는 요청이 프롬프트 성숙도에 따라 완전히 다른 결과를 만들어낸다.
좋은 프롬프트의 구조: CICV 프레임워크
프롬프트를 체계적으로 구성하는 4가지 요소가 있다. Context, Intent, Constraints, Validation의 앞글자를 따서 CICV라 부른다.
1. Context - 컨텍스트
AI가 판단하는 데 필요한 배경 정보를 제공하는 부분이다.
| 포함할 것 | 예시 | 누락 시 위험 |
|---|---|---|
| 프로젝트 상황 | "Next.js 16 App Router 기반 SaaS" | 잘못된 프레임워크 패턴 사용 |
| 기존 코드 구조 | "알림은 현재 동기 처리. lib/notification.ts에 있음" | 기존 코드와 충돌 |
| 기술 스택 | "TypeScript, Prisma, Redis" | 없는 라이브러리 사용 |
| 팀 상황 | "3인 팀, 코드 리뷰 필수" | 과도하게 복잡한 설계 |
2. Intent - 의도
무엇을 달성하려는지 명확히 하는 부분이다. 구현 방법이 아니라 목적이 핵심이다.
| 나쁜 의도 | 좋은 의도 | 차이 |
|---|---|---|
| "Observer 패턴으로 만들어" | "새 채널을 쉽게 추가할 수 있게" | 방법 vs 목적 |
| "Redis pub/sub 사용해" | "알림이 결제를 블로킹하면 안 됨" | 기술 vs 요구사항 |
| "클래스 3개로 분리해" | "각 채널이 독립적으로 실패할 수 있게" | 구조 vs 행동 |
3. Constraints - 제약조건
반드시 지켜야 할 조건과 피해야 할 것을 명시하는 부분이다.
제약조건:
- 알림 전송이 결제 응답을 블로킹하면 안 된다
- 전송 실패 시 최대 3회 재시도
- 각 알림 채널은 독립적으로 실패할 수 있다
- 모든 전송 시도는 로깅되어야 한다
피할 것:
- 외부 메시지 큐는 현재 인프라에 없으므로 사용하지 않는다
- 알림 템플릿 시스템은 이 단계에서 필요 없다4. Validation - 검증기준
결과물을 어떻게 검증할지 미리 정하는 부분이다.
검증기준:
- 결제 API 응답 시간이 알림 전송으로 인해 증가하지 않음
- 이메일 전송 실패 시 슬랙 알림은 정상 전송됨
- 새 채널 추가 시 기존 코드 변경 없이 파일 추가만으로 가능
- 재시도 로직이 지수 백오프로 동작함V를 먼저 생각하면 나머지가 명확해진다
CICV 순서로 작성하되, V를 먼저 생각하면 나머지가 자연스럽게 도출되는 경우가 많다. "이 기능이 성공했다는 것을 어떻게 아는가?"라는 질문에 답할 수 있으면, 의도와 제약조건은 거의 자동으로 따라온다.
CLAUDE.md를 설계 문서로 관리하기
프로젝트 레벨의 프롬프트인 CLAUDE.md는 살아있는 설계 문서 역할을 한다.
CLAUDE.md의 설계 문서적 역할
| 설계 문서 항목 | CLAUDE.md 대응 | 효과 |
|---|---|---|
| 아키텍처 개요 | 프로젝트 구조, 디렉토리 설명 | AI가 파일 위치를 정확히 파악 |
| 코딩 컨벤션 | 스타일 가이드, 네이밍 규칙 | 일관된 코드 스타일 |
| 의사결정 기록 | 기술 선택 이유, 트레이드오프 | AI가 잘못된 기술 제안 방지 |
| 온보딩 문서 | 새 팀원이 알아야 할 컨텍스트 | 새 개발자 + AI 동시 온보딩 |
| 금지 목록 | 하면 안 되는 것들 | 보안/성능 사고 방지 |
주석이 달린 CLAUDE.md 예시
아래는 실전에서 검증된 CLAUDE.md 구조다. 각 섹션의 역할을 주석으로 설명한다.
# CLAUDE.md
## 프로젝트 개요
<!-- AI에게 "왜 이 프로젝트가 존재하는지" 알려준다.
이것이 없으면 AI는 범용적 솔루션을 제안한다. -->
B2B SaaS로 중소기업 회계 자동화를 제공한다.
핵심 가치: 정확성 > 속도. 회계 데이터는 오류 허용 불가.
## 아키텍처
<!-- 디렉토리 구조를 명시하면 AI가 파일을 올바른 위치에 생성한다. -->
- app/: Next.js App Router
- lib/: 비즈니스 로직 (순수 함수 중심)
- services/: 외부 API 연동
- prisma/: DB 스키마와 마이그레이션
## 개발 규칙
<!-- MUST/MUST NOT/SHOULD 구분이 핵심.
AI는 "해도 되고 안 해도 되는 것"을 잘 판단하지 못한다. -->
### MUST (반드시)
- 모든 금액 계산은 Decimal.js 사용 (부동소수점 금지)
- API 응답은 반드시 AppResponse 타입으로 래핑
- DB 쿼리에 반드시 인덱스 힌트 주석 포함
### MUST NOT (절대 금지)
- moment.js 사용 금지 (dayjs 사용)
- any 타입 사용 금지
- console.log 금지 (logger 모듈 사용)
### SHOULD (권장)
- 함수는 20줄 이내 권장
- 복잡한 조건문은 early return 패턴
## 기술 스택과 선택 이유
<!-- "왜"를 적어야 AI가 다른 기술을 제안하지 않는다. -->
- Prisma: 타입 안전한 ORM. Drizzle 대비 팀 숙련도 높음
- Redis: 세션 + 캐시. Memcached 대비 데이터 구조 다양성
- Decimal.js: 회계 정확도. BigInt 대비 소수점 연산 용이
## 알려진 기술 부채
<!-- AI가 이 영역을 건드릴 때 주의하도록 경고한다. -->
- legacy/reports/: 리팩토링 예정. 건드리지 말 것
- utils/date.ts: moment.js 의존. dayjs 마이그레이션 진행중CLAUDE.md는 AI만을 위한 문서가 아니다
CLAUDE.md를 잘 작성하면 새 팀원의 온보딩 문서로도 활용할 수 있다. AI가 이해할 수 있을 만큼 명확하게 쓴 문서는 사람도 이해하기 쉽다. 이것이 프롬프트를 설계 언어로 다루는 것의 부가적 가치다.
문서가 코드를 대체하는 시대: effort frontmatter와 AGENTS.md
2026년 Claude Code v2.1.77 이후, 에이전트의 행동을 제어하는 방식이 근본적으로 바뀌었다. 코드로 에이전트 행동을 정의하는 대신, frontmatter와 마크다운 문서로 선언하는 패턴이 자리잡고 있다.
effort frontmatter — 코드 대신 문서로 설정
---
effort: high
---
# CLAUDE.md
이 프로젝트에서는 보안 관련 코드에 최대한 신중하게 접근합니다.effort frontmatter 하나로 에이전트의 추론 깊이를 조절할 수 있다. 이것은 "에이전트에게 코드로 지시하던 시대"에서 **"문서로 의도를 선언하는 시대"**로의 전환을 상징한다.
AGENTS.md를 인프라로 취급하기
CodeScene의 2026년 연구는 AGENTS.md를 단순한 문서가 아니라 인프라로 취급해야 한다고 강조한다. 코드 건강도가 9.5 이상인 코드베이스에서 AI 에이전트의 성능이 유의미하게 향상되었는데, 이는 AGENTS.md의 품질이 에이전트 성능에 직접적인 영향을 미치기 때문이다.
| AGENTS.md 역할 | 문서로 볼 때 | 인프라로 볼 때 |
|---|---|---|
| 업데이트 빈도 | 분기 1회 | 코드 변경마다 함께 업데이트 |
| 담당자 | 누구나 | 코드 소유자와 동일 |
| 리뷰 대상 | 선택적 | PR 리뷰 필수 항목 |
| 테스트 | 없음 | AI가 규칙을 따르는지 검증 |
| 버전 관리 | 느슨함 | git으로 엄격 관리 |
이 관점은 앞서 다룬 CLAUDE.md 관리와 일맥상통하면서도, 한 단계 더 나아간다. CLAUDE.md가 프로젝트 레벨의 설계 문서라면, AGENTS.md는 에이전트가 프로젝트를 이해하는 방식 자체를 정의하는 인프라 코드다.
Opus 4.6 기본 64k 출력의 의미
Claude Opus 4.6의 기본 출력이 64k 토큰으로 확대되었다. 이는 "AI에게 작은 청크로 나눠서 요청하라"는 기존 습관을 재고해야 한다는 뜻이다. 큰 범위의 의도를 한 번에 전달하고, 큰 범위의 결과를 한 번에 검증하는 워크플로우가 더 자연스럽고 효율적인 경우가 많아졌다.
프롬프트 버전 관리와 반복 개선
프롬프트는 코드처럼 버전 관리할 수 있다. 같은 유형의 작업을 반복할수록 프롬프트는 정교해지는 경향이 있다.
프롬프트 반복 진화 예시
API 엔드포인트 생성 프롬프트가 실패를 거치며 진화하는 과정을 보면 흥미로운 패턴이 드러난다.
v1 — "사용자 목록 API 만들어줘"
- ❌ 페이지네이션 없음
- ❌ 에러 핸들링 없음
v2 — "커서 기반 페이지네이션 추가" + "에러 시 HTTP 상태 코드 반환"
- ❌ 인증 누락
v3 — "CICV 구조로 전환" + "컨텍스트 + 제약 + 검증 포함"
- ✅ 안정적 결과 달성
v4 — "CLAUDE.md에 패턴으로 등록"
- ✅ 팀 전체가 재사용
- ✅ 프롬프트 자산화
프롬프트 진화 기록 관리
프롬프트를 git으로 관리하면 팀 자산이 된다.
project-root/
.prompts/
api-endpoint.md # API 생성 패턴
db-migration.md # DB 마이그레이션 패턴
test-template.md # 테스트 작성 패턴
CHANGELOG.md # 프롬프트 변경 이력<!-- .prompts/CHANGELOG.md -->
## 2025-03-15
- api-endpoint.md v3: 인증 미들웨어 참조 규칙 추가
- 원인: AI가 보호된 라우트에서 인증 체크를 누락하는 패턴 3회 반복
## 2025-03-08
- api-endpoint.md v2: 응답 형식 통일 규칙 추가
- 원인: AI가 매번 다른 응답 구조를 생성흔한 프롬프트 실패 패턴과 개선 방향
실제로 프롬프트가 실패하는 양상에는 반복되는 패턴이 있다.
| 문제 상황 | 분석 | 프롬프트 개선 방향 |
|---|---|---|
| AI가 불필요한 기능을 추가 | 범위가 모호함 | "이 단계에서는 X만 구현" 명시 |
| AI가 잘못된 기술을 사용 | 기술 스택 미명시 | CLAUDE.md에 허용 기술 목록 추가 |
| 코드 스타일이 매번 다름 | 컨벤션 부재 | MUST/MUST NOT 규칙 추가 |
| 테스트가 빠짐 | 검증기준 없음 | Validation에 테스트 요구사항 명시 |
| 에러 핸들링 빈약 | 실패 시나리오 미정의 | Constraints에 에러 케이스 나열 |
| 보안 취약점 발생 | 금지 사항 부재 | MUST NOT에 보안 규칙 추가 |
프롬프트 품질을 구성하는 요소
프롬프트의 품질을 구성하는 핵심 요소를 분석하면 다섯 가지 축이 보인다.
위 차트에서 세 막대는 순서대로 L1/L2, L3, L4 수준의 프롬프트 품질을 나타낸다.
| 평가 기준 | 핵심 질문 | 높은 품질의 지표 |
|---|---|---|
| 명확성 | AI가 한 번에 의도를 파악할 수 있는가? | 추가 질문 없이 실행 가능 |
| 완전성 | AI가 가정을 해야 하는 빈 부분이 있는가? | AI의 가정이 0개에 가까움 |
| 제약조건 | 하지 말아야 할 것이 명시되어 있는가? | MUST NOT 항목이 구체적 |
| 검증성 | 결과물의 성공/실패를 판단할 수 있는가? | 자동화 검증이 가능 |
| 재사용성 | 유사한 작업에 다시 쓸 수 있는가? | 패턴화가 가능 |
프롬프트 설계 능력을 키우는 방법들
역방향 분석
AI가 좋은 결과를 냈을 때, "왜 좋았지?"를 분석하는 접근이다. 어떤 컨텍스트, 어떤 제약조건이 좋은 결과를 이끌었는지 파악한다.
## 역방향 분석 기록
### 2025-03-14 - 결제 웹훅 처리기
- 결과: 한 번에 프로덕션 수준의 코드 생성
- 성공 요인 분석:
1. 기존 웹훅 처리기 코드를 컨텍스트로 제공
2. 멱등성 요구사항을 명시
3. 실패 시나리오 5개를 구체적으로 나열
- 학습: "기존 코드 예시 + 실패 시나리오 나열"이 이 팀의 핵심 패턴실제로 이런 역방향 분석을 축적한 팀에서는, 프롬프트 품질이 빠르게 수렴하는 경향이 관찰되었다.
의도적 축소
처음에 일부러 불완전한 프롬프트를 보내고, 결과에서 누락된 것을 확인하는 방법이다. "내가 명시하지 않으면 AI가 어떤 가정을 하는가"를 학습하는 데 효과적이다.
프롬프트 동료 리뷰
코드 리뷰처럼 프롬프트의 명확성과 완성도를 팀원 간에 리뷰하는 방법이다. 실제로 이를 시도한 팀에서는, 프롬프트의 품질 편차가 줄어드는 효과가 관찰되었다.
| 리뷰 관점 | 핵심 질문 |
|---|---|
| 컨텍스트 충분성 | 이 프롬프트만으로 프로젝트 신규 인원이 이해할 수 있는가? |
| 의도 명확성 | "무엇을"과 "어떻게"가 분리되어 있는가? |
| 제약 완성도 | 하면 안 되는 것이 빠짐없이 나열되어 있는가? |
| 검증 구체성 | 결과물의 합격/불합격을 자동으로 판단할 수 있는가? |
패턴 라이브러리 구축
반복 사용하는 프롬프트를 패턴으로 정리하면 팀 차원의 자산이 된다.
## 팀 프롬프트 패턴
### API 엔드포인트 생성
[Context] 기술 스택, 인증 방식, 관련 모델
[Intent] 어떤 데이터를 어떻게 처리
[Constraints] 페이지네이션, 필터링, 권한, 응답 형식
[Validation] 엣지 케이스 목록
### DB 마이그레이션
[Context] 현재 스키마, 관련 쿼리, 데이터 규모
[Intent] 어떤 변경을 왜 하는지
[Constraints] 무중단 배포, 롤백 가능, 기존 데이터 보존
[Validation] 마이그레이션 전후 데이터 정합성
### 버그 수정
[Context] 증상, 재현 조건, 관련 로그
[Intent] 어떤 동작이 정상인지
[Constraints] 다른 기능에 영향 없을 것, 테스트 추가 필수
[Validation] 재현 시나리오에서 정상 동작 확인이 챕터의 핵심
핵심 관점
프롬프트는 "AI한테 시키는 말"이 아니라 새로운 형태의 설계 문서다. 프롬프트의 품질이 곧 설계의 품질이고, 설계의 품질이 곧 결과물의 품질이다.
프롬프트를 설계 언어로 다루기 시작하면, "AI가 별로다"라는 판단이 "내 설계가 불완전했다"로 바뀌는 경향이 있다. 이 관점 전환이 에이전틱 코딩 생산성의 핵심이다.
다음 장 미리보기
프롬프트가 설계 문서라면, 다음 단계는 그 결과물을 어떻게 검증하느냐입니다. 다음 장에서는 AI 시대의 코드 리뷰가 무엇을 확인해야 하는지 다룹니다.
참고 자료
참고 자료 안내
이 장의 관점과 프레임워크를 뒷받침하는 참고 자료입니다. 본문의 모든 주장이 아래 자료에서 직접 인용된 것은 아니며, 실무 경험과 커뮤니티 사례를 종합한 해석이 포함되어 있습니다.
- White, J. et al. (2023). "A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT." https://arxiv.org/abs/2302.11382
- Anthropic (2025). "Claude Code Memory and CLAUDE.md." https://docs.anthropic.com/en/docs/claude-code/memory
- Anthropic (2025). "Prompt Engineering Guide." https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering
- CodeScene (2026). "AGENTS.md as Infrastructure." https://codescene.com/blog/agents-md-infrastructure
- Anthropic (2026). "Claude Code v2.1.77-81 Release Notes." https://docs.anthropic.com/en/docs/claude-code/changelog