일부 개발자들은 Claude를 자동 완성(autocomplete)처럼 다룹니다. 코드를 붙여넣고, 코드를 돌려받고, 맹목적으로 반복하는 식이죠. 평범한 응답과 진정으로 훌륭한 응답 사이의 격차는 대개 모델의 문제가 아니라, 여러분이 어떻게 프롬프팅(prompting)하느냐에 달려 있습니다. 여기 API, Claude Code, 또는 claude.ai에서 바로 사용할 수 있는 실제 전/후 사례가 포함된 6가지 구체적인 기술을 소개합니다.

1. 단순한 작업이 아닌 명시적인 성공 기준을 제시하세요

모호한 프롬프트는 모호한 코드를 생성합니다. Claude가 "완료"의 의미를 추측해야 하기 때문이며, 그 추측은 보수적일 수밖에 없습니다.

이전 (Before): "이메일을 검증하는 함수를 작성해줘."

이후 (After):

TypeScript 함수 `validateEmail(input: string): boolean`을 작성하세요.
요구사항:
- RFC 5322와 호환되어야 하지만, TLD가 없는 주소는 거부할 것
...

이제 어차피 다시 작성해야 할 일반적인 정규 표현식(regex) 대신, 여러분의 실제 제약 조건에 부합하는 함수를 얻을 수 있습니다.

2. 코드와 컨텍스트를 XML 태그로 감싸세요

프롬프트에 지시 사항과 붙여넣은 소스 코드가 섞여 있으면, Claude는 특히 파일이 길어질 때 무엇이 무엇인지 혼동할 수 있습니다. 태그는 이러한 모호함을 제거합니다.

<file path="auth/session.ts">
[파일 내용 붙여넣기]
</file>
...

이는 다중 파일 컨텍스트(multi-file context)를 구조화하는 방법이기도 합니다. 파일당 하나의 <file> 블록을 사용하고, 각 블록에 경로를 라벨링하세요.

3. 사소하지 않은 작업에서는 코드 작성 전에 계획을 요청하세요

한 줄짜리 코드를 넘어서는 모든 것—새로운 기능, 리팩터링(refactor), 까다로운 버그—에 대해서는 코드를 작성하기 전에 Claude에게 접근 방식에 대해 추론하도록 요청하세요. 이를 통해 잘못된 가정이 200줄의 코드에 박히기 전에 드러낼 수 있습니다.

이전 (Before): "이 API 엔드포인트에 캐싱을 추가해줘."

이후 (After): "코드를 작성하기 전에, 이 엔드포인트를 캐싱하기 위한 접근 방식을 개요로 작성하세요: 무엇을 캐싱할지, 무효화 전략(invalidation strategy), 그리고 캐시가 어디에 위치할지. 그 다음 구현하세요."

잘못된 가정(예: 특정 필드만 비용이 많이 드는데 "전체 응답을 캐싱"하는 경우)을 PR 리뷰 단계가 아닌 계획 단계에서 잡아낼 수 있습니다.

4. 퓨샷 예시(few-shot examples)를 사용하여 코드 스타일을 고정하세요

Claude의 출력이 여러분의 코드베이스 컨벤션(conventions)과 일치하기를 원한다면, 스타일을 설명하는 대신 패턴을 보여주세요.

이전: "이 엔드포인트에 대한 에러 핸들러를 작성해줘."

이후:

우리 코드베이스의 기존 패턴을 따르세요:

export const getUser = async (req, res) => {
...

좋은 예시 하나가 "사실, 우리 에러 형식을 사용해줘"라고 다시 요청해야 하는 왕복 과정을 아껴줍니다.

5. 하나의 거대한 프롬프트 대신 큰 작업을 체인(Chain)으로 연결하세요

한 번에 전체 기능을 요청하는 것은 내용이 얕거나 일관성이 없는 결과물을 생성하는 경향이 있습니다. 계획(plan), 구현(implement), 검토(review), 수정(fix)과 같이 단계를 나누면 각 단계가 하나의 작업만을 수행하기 때문에 더 강력한 결과를 얻을 수 있습니다.

이전: "우리 API를 위한 속도 제한기(rate limiter)를 만들어줘."

1. "Node/Redis 스택을 위한 2~3가지 속도 제한 전략을 트레이드오프(tradeoffs)와 함께 제안해줘."
2. "슬라이딩 윈도우(sliding-window) 방식을 Express 미들웨어로 구현해줘."
3. "이 미들웨어에서 레이스 컨디션(race conditions)과 엣지 케이스(edge cases)가 있는지 검토해줘."
4. "발견된 문제들을 수정해줘."

각 단계는 그 자체로 검증하기 쉬우며, 이것이 바로 최종 결과물이 견고하게 유지되는 이유입니다.

6. 의도적으로 컨텍스트(context)를 관리하세요 (특히 Claude Code에서)

에이전트(agentic) 세션이 길어질 때 컨텍스트가 무관한 이력으로 가득 차면 성능이 저하됩니다. 예를 들어, 관련 없는 버그 B를 디버깅하는 동안 버그 A를 수정했던 기록이 여전히 컨텍스트에 남아 있는 경우입니다.

• 해결책: Claude Code에서 관련 없는 작업 사이에는 동일한 스레드를 계속 이어가는 대신 /clear를 실행하세요.
• 해결책: 동일한 문제에 대해 Claude를 두 번 수정했는데도 여전히 틀린다면, 세 번째 수정을 시도하는 대신 /clear를 하고 배운 내용을 바탕으로 더 나은 초기 프롬프트를 작성하세요.
• 모든 세션에 적용되어야 하는 지침(코딩 컨벤션, 테스트 명령, 디렉토리 구조 등)은 매 프롬프트마다 반복하는 대신 CLAUDE.md 파일에 넣어두세요.

요약

이 방법들은 마법 같은 프롬프트 템플릿이 아닙니다. 새로운 팀원에게 전달하는 것과 동일한 것들, 즉 명확한 요구사항, 관련 컨텍스트, 기존 패턴, 그리고 행동하기 전에 생각할 여유를 Claude에게 주는 것입니다. 다음 프롬프트에 이 중 하나를 적용해 보고, 사후 정리 작업이 얼마나 줄어드는지 확인해 보세요.