1. 시스템 프롬프트 설계

시스템 프롬프트는 모델의 기본 성격과 일하는 규칙을 미리 정해두는 자리입니다. 사용자 메시지가 오기 전에 이미 컨텍스트에 깔려 있고, 모든 대화에 영향을 줍니다. 채팅창에서 매번 같은 역할 설명을 반복하기 싫을 때 시스템 프롬프트가 그 수고를 덜어줍니다.

ChatGPT의 "Custom Instructions"와 GPTs, Claude의 "Projects"와 Custom Instructions, Cursor의 Rules, 그리고 API 호출 시의 system 파라미터가 전부 같은 자리입니다.

1.1 자주 쓰이는 골격

# 역할
너는 [역할]이야. [그 역할이 평소에 어떤 시각으로 일하는지].

# 행동 규칙
1 - [반드시 지킬 것]
2 - [반드시 지킬 것]
3 - [반드시 지킬 것]

# 응답 형식
- [형식 규칙]

# 제한 사항
- [절대 하면 안 되는 것]
- [절대 하면 안 되는 것]

# 참고 정보
[모델이 알고 있어야 할 배경 정보]

비어 보이지만, 이 다섯 칸을 채우는 일이 의외로 어렵습니다. 익숙해지기 전엔 빈칸 하나당 한두 줄만 채워도 충분합니다.

1.2 실전 예시

# 역할
너는 위니브의 시니어 프론트엔드 개발자야. Next.js 13+, TypeScript, SCSS를 주로 다루고,
사내 컨벤션을 우선시해.

# 행동 규칙
1 - 코드는 TypeScript로, any 타입은 피해
2 - 컴포넌트는 함수형으로 작성하고 Props 인터페이스를 명시해
3 - 스타일은 SCSS Module을 사용해
4 - 성능에 민감한 부분에는 memo, useMemo, useCallback을 고려해

# 응답 형식
- 코드 변경 시 변경 전/후를 같이 보여줘
- 변경 이유는 한두 문장으로 간결하게

# 제한 사항
- 검증되지 않은 외부 라이브러리는 추천하지 마
- 기존 코드 스타일을 임의로 바꾸지 마

이 시스템 프롬프트를 한 번 만들어 Claude Projects나 Cursor Rules에 박아두면, 그 안에서 시작하는 모든 대화가 위 규칙 안에서 답합니다.

2. RAG, 외부 자료를 끌어다 답하기

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 컨텍스트 엔지니어링의 가장 대표적인 패턴입니다. 한 줄로 줄이면 "질문이 들어오면 관련 자료를 먼저 검색해서, 그 자료를 함께 보여주면서 답하게 한다" 입니다.

2.1 왜 필요한가

모델은 학습 시점 이후의 정보를 모릅니다. 우리 회사 데이터는 학습 시점 이전 것이라도 모를 가능성이 높습니다. 그렇다고 그걸 통째로 매번 컨텍스트에 박아 넣으면 토큰 비용도 비싸고, "Lost in the Middle"로 정확도도 떨어집니다. RAG는 이번 질문에 필요한 부분만 찾아서 넣어주는 절충안입니다.

2.2 다섯 단계

1. 문서 준비. 회사 위키, 메뉴얼, 코드, PDF 등 참조할 자료를 모읍니다.
2. 청크 분할. 자료를 200~1000 토큰 정도의 작은 조각으로 나눕니다. 너무 크면 검색 정확도가 떨어지고, 너무 작으면 맥락이 끊깁니다.
3. 임베딩. 각 청크를 벡터(숫자 배열)로 변환해서 벡터 DB에 저장해둡니다.
4. 검색. 사용자 질문도 벡터로 바꿔서 가장 가까운 청크 몇 개를 꺼냅니다.
5. 컨텍스트 주입. 꺼낸 청크들을 프롬프트에 붙여서 모델에게 함께 보여줍니다.

기획자나 일반 사용자라면 이 흐름을 직접 구현할 일은 드뭅니다. 하지만 회사 도구를 고를 때 "이 도구가 우리 회사 자료를 어떻게 검색해서 모델에 보여주는가"를 묻는 건 결국 위 다섯 단계 중 어느 부분을 어떻게 처리하는지를 묻는 일입니다.

2.3 벡터 DB 없이 흉내내기

회사 자료가 적다면 벡터 DB를 따로 두지 않고도 같은 효과를 흉내낼 수 있습니다. 예를 들어 FAQ 30개 정도라면, 그냥 통째로 프롬프트에 붙여 넣어도 됩니다.

[참조: 우리 서비스 FAQ]

Q: 환불 정책은 어떻게 되나요?
A: 구매 후 7일 이내 전액 환불 가능합니다. 디지털 콘텐츠는 다운로드 전까지 환불 가능합니다.

Q: 구독 해지는 어떻게 하나요?
A: 설정 > 구독 관리에서 해지 가능합니다. 해지 후 남은 기간은 계속 이용 가능합니다.

Q: 팀 플랜 할인이 있나요?
A: 5인 이상 팀 플랜은 20% 할인이 적용됩니다.

[지시사항]
위 FAQ를 참조해 고객 질문에 답해줘.
FAQ에 없는 내용은 "확인 후 안내드리겠습니다"라고 답해줘.

자료가 늘어나서 컨텍스트에 다 못 들어가는 시점이 오면, 그때부터 벡터 DB가 필요해집니다.

3. 컨텍스트를 동적으로 구성하기

작업이 항상 같은 모양이면 시스템 프롬프트 하나로 충분합니다. 그런데 실제 업무는 "이번엔 코드 질문, 다음엔 버그 리포트, 그다음엔 기능 요청"식으로 종류가 섞입니다. 그래서 요청 종류에 따라 컨텍스트 구성을 바꾸는 패턴이 자주 쓰입니다.

3.1 우선순위 정하기

컨텍스트 윈도우는 무한이 아닙니다. 모든 정보를 다 넣을 수 없으니 우선순위가 필요합니다.

1순위 (필수): 시스템 프롬프트, 지금 작업에 직접 관련된 자료
2순위 (중요): 관련 코드·문서, 사내 컨벤션
3순위 (참고): 유사 사례, 배경 지식
4순위 (선택): 관련 이슈, 과거 히스토리

토큰이 빡빡하면 4순위부터 잘라냅니다. 1순위가 들어갈 자리가 부족하면, 그건 컨텍스트 설계가 아니라 작업을 더 잘게 쪼개야 한다는 신호입니다.

3.2 정보 압축하기

같은 정보를 짧게 줄일 수 있다면 그만큼 다른 정보를 더 넣을 여유가 생깁니다.

요약 후 넣기. 긴 문서를 모델에게 먼저 요약시키고, 요약본을 컨텍스트로 씁니다.

[원본 5000자] → AI 요약 → [요약본 500자] 컨텍스트 사용

필요한 부분만 추리기. 파일 전체 대신 관련 함수와 그 의존성만 넣습니다.

파일 전체 300줄 대신, 관련 함수 30줄 + 파일 구조 한 줄 개요

계층적으로 보여주기. 전체 구조는 개요로, 핵심 부분만 상세하게.

프로젝트 구조 개요:
src/
├── components/ (15개 컴포넌트)
├── pages/ (8개 페이지)
└── utils/ (12개 유틸리티)

[상세] src/components/Header.tsx
(전체 코드)

4. CLAUDE.md, AGENTS.md, .cursorrules 같은 프로젝트 컨텍스트

요즘 AI 코딩 도구들은 프로젝트 루트에 있는 특정 파일을 매 세션마다 자동으로 컨텍스트에 포함합니다. 한 번 잘 적어두면 그 프로젝트에서 시작하는 모든 대화에 영향을 줍니다. 컨텍스트 엔지니어링을 사용자가 가장 일상적으로 만나는 형태입니다.

이름은 도구마다 다르지만 역할은 같습니다. "이 프로젝트에서 일할 때 알고 있어야 하는 기본 정보" 를 적는 자리입니다.

4.1 어디까지 적어야 하나

너무 짧으면 효과가 없고, 너무 길면 컨텍스트 윈도우를 잡아먹습니다. 보통 다음 정도가 균형이 좋습니다.

# 프로젝트 개요
- 이게 무슨 서비스고, 누구를 위한 것인지 한두 줄
- 기술 스택과 버전
- 주요 디렉토리 구조 (3~5줄)

# 코딩 컨벤션
- 네이밍 규칙
- 파일 구조 패턴
- 에러 처리 방식
- 자주 쓰는 라이브러리

# 절대 하면 안 되는 것
- 보안 관련 (.env 커밋 금지 등)
- 깨면 안 되는 핵심 동작

# 자주 쓰는 명령어
- 빌드, 테스트, 배포
- 자주 들어가는 디렉토리

# 이 프로젝트의 함정
- 한 번 사고 났던 부분
- 처음 보는 사람이 헷갈리는 부분

마지막 "이 프로젝트의 함정" 칸이 의외로 효과가 큽니다. 신입에게 인수인계할 때 따로 적어주는 그런 정보가 그대로 모델에게도 효과가 있습니다.

4.2 컨텍스트 엔지니어링의 가장 일상적인 모습

CLAUDE.md를 한 번 만들어 본 사람은, 그게 본질적으로 모델을 위한 인수인계 문서라는 걸 금방 깨닫습니다. 새 팀원이 왔을 때 "우리 프로젝트는 이래" 하면서 알려주는 그것과 같습니다. 다만 받는 쪽이 사람이 아니라 모델이라는 차이뿐입니다.

매번 채팅창에 같은 설명을 반복하는 대신, 한 번 잘 적힌 파일을 자동으로 깔아두는 것. 이 단순한 패턴 하나가 같은 도구를 쓰는 다른 회사 대비 결과 품질을 크게 벌립니다. 이어서 이걸 어떻게 활용해서 코드 리뷰, 문서 작성, 고객 응대 같은 실제 업무를 풀어내는지 사례로 살펴봅니다.