딥러닝 시험을 통해 알게 된 10가지 프롬프팅 기법 (실제 개발에서 사용하는 방법)

여러분은 이미 매일 프롬프팅(prompting)을 사용하고 있습니다.

다만, 자신이 무엇을 하고 있는지 그 이름만 모를 뿐입니다.

ChatGPT에 '이 오류를 고쳐줘'라고 입력하거나 Cursor에 '이 함수를 리팩토링해줘'라고 하는 모든 행위가 바로 프롬프팅 기법입니다. 이미 사용하고 있는 것입니다. 다만, 이 작업을 수행하는 10가지 명확한 방법이 있다는 사실과, 그 대부분이 현재 여러분이 하고 있는 것보다 더 좋다는 것을 알려주지 않았을 뿐입니다.

저는 이 모든 것을 딥러닝(Deep Learning) 시험을 위해 공부해야 했습니다. 'SF 소설 추천하기'나 '0°C를 화씨로 변환하기'와 같은 학술적인 예시들로 가득 찬 50페이지짜리 PDF 두 개가었습니다. 기술적으로는 맞지만, 실제로는 쓸모가 없습니다. 아무도 ChatGPT에 접속해서 섭씨 온도를 변환할 일이 없으니까요.

그래서 제가 바랐던 버전은 이렇습니다. 제 강의 계획서의 모든 기법을 개발자로서 실제로 사용할 수 있는 예시와 함께 설명한 것입니다.

목차

• 1. 제로샷 프롬프팅 (Zero-Shot Prompting)
• 2. 퓨샷 프롬프팅 (Few-Shot Prompting)
• 3. 사고의 사슬 프롬프팅 (Chain-of-Thought Prompting)
• 4. 생각의 트리 프롬프팅 (Tree-of-Thought Prompting)
• 5. 역할극 프롬프트 (Role-Playing Prompts)
• 6. 생성된 지식 프롬프팅 (Generated Knowledge Prompting)
• 7. 산파술적 프롬프팅 (Maieutic Prompting)
• 8. 최소에서 최대로 프롬프팅 (Least-to-Most Prompting)
• 9. 형식별 프롬프팅 (Format-Specific Prompting)
• 10. 다중 턴 프롬프팅 (Multi-Turn Prompting)
• 치트 시트 (The Cheat Sheet)
• 🧪 실제 비법: 이들을 결합하기

1. 제로샷 프롬프팅 (Zero-Shot Prompting)

개념: AI에게 무언가를 직접적으로 질문합니다. 예시는 없습니다. 맥락도 없습니다. 설명도 없습니다. 오직 질문만 던집니다.

교과서적 예시:

실패하는 경우: 질문이 사용자의 코드베이스, 아키텍처 또는 모델이 학습하지 않은 어떤 것을 포함할 때입니다. 바로 이때 다음 기법이 필요합니다.

2. Few-Shot Prompting (소수 예시 기반 프롬프팅)

개념: AI에게 원하는 것의 예시 2~5개를 보여주고, 패턴을 파악하여 새로운 입력에 적용하도록 하는 것입니다.

교과서적 예시:

섭씨를 화씨로 변환하세요:
0°C → 32°F
25°C → 77°F
100°C → ?

개발자 예시:

팀을 위해 커밋 메시지를 작성한다고 가정하고, 일관된 스타일을 원할 때:

제가 지금까지 작성한 커밋 메시지입니다:

feat: add user authentication with JWT
fix: resolve null pointer in payment service
refactor: extract validation logic into middleware

이제 다음 내용에 대한 커밋 메시지를 작성해 주세요: API 엔드포인트에 속도 제한(rate limiting)을 추가했습니다.

출력:

feat: add rate limiting to API endpoints

모델은 사용자가 아무것도 설명하지 않아도 접두사 규칙(feat:, fix:, refactor:), 문장 대소문자, 상세 수준 등을 파악합니다.

또 다른 실제 활용: 오래된 API 응답 형식을 새로운 형식으로 변환하는 경우입니다. '오래된 형태 → 새로운 형태'의 예시 3개를 보여주고, 네 번째 오래된 응답을 붙여넣은 후 모델이 이를 변환하도록 합니다. 임시 스크립트를 작성하는 수고를 덜어줍니다.

사용 시점: 일관된 형식 지정, 스타일 매칭, 반복적인 변환 작업. '이 작업을 40번 더 해야 한다'라고 생각할 때 언제든지 사용합니다.

3. Chain-of-Thought Prompting (사고의 연쇄 프롬프팅)

개념: AI에게 결론을 바로 내리도록 하는 대신, 문제를 체계적으로 단계별로 풀어가도록 요청하는 것입니다.

교과서적 예시:

23 × 47은 무엇인가요? 풀이 과정을 보여주세요.

개발자 예시:

이 함수는 할인 후 총 가격을 반환해야 하지만, 일부 입력값에 대해서는 NaN을 반환합니다. 단계별로 무슨 일이 일어나고 있는지 설명해 주세요:

function getTotal(price, discount) {
  const total = price - (price * discount / 100);
  return total.toFixed(2);
...

“단계별로(step by step)” 요청을 하지 않으면, AI는 단순히 “함수는 괜찮아 보입니다.”라고 말할 수 있습니다. 하지만 이 지시어를 사용하면, AI는 엣지 케이스를 추적합니다: “만약 discount가 ‘10%’와 같은 문자열로 전달된다면, 곱셈 결과가 NaN을 생성하고, 이것이 계산 전체에 전파됩니다...”

단계별 분석을 요청하는 것이 반드시 모델의 실제 내부 추론 과정을 드러내는 것은 아닙니다. 하지만 이는 더 검사 가능한 답변을 강제합니다: 명시된 가정, 중간 확인 사항, 고려된 엣지 케이스, 그리고 그 후에야 결론이 나옵니다. 바로 이 구조가 실수를 잡기 쉽게 만듭니다.

실제로 제가 프로젝트의 서비스 워커에서 발생한 clients.matchAll() 레이스 컨디션을 추적했을 때도 마찬가지였습니다. Copilot의 첫 답변은 자신만만했지만 완전히 틀렸습니다. 단순히 “이것을 고쳐줘”라고 요청하는 대신, “이 두 이벤트 사이에서 무슨 일이 일어나는지 단계별로 추적해 줘”라고 요청한 것이 타이밍 버그를 실제로 드러냈습니다.

언제 사용해야 할까요: 디버깅, 코드 리뷰, 그리고 답변 자체보다 그 _추론 과정_이 더 중요한 모든 질문에 사용하세요. AI로부터 자신만만하지만 완전히 틀린 답변을 받은 적이 있다면—아마도 이것이 빠져있었을 가능성이 높습니다.

4. Tree-of-Thought 프롬프팅 (사고의 트리)

개념: AI가 하나의 추론 경로를 따르는 대신, 여러 경로를 병렬로 탐색합니다. Chain-of-thought는 직선입니다. Tree-of-thought는 의사 결정 트리입니다.

교과서적인 예시:

기후 변화의 환경적 및 사회적 영향을 각각 나열하세요.

개발자 예시:

앱에 실시간 알림 기능을 추가해야 합니다. WebSockets, Server-Sent Events, 폴링(polling) 세 가지 다른 접근 방식을 탐색하고, 각 방식에 대해 복잡성, 확장성, 브라우저 지원 측면에서의 트레이드오프를 설명해 주세요. 그런 다음 Node 백엔드를 사용하는 소규모 팀에 가장 적합한 것을 추천해 주세요.

AI가 단순히 하나를 선택하여 그것을 옹호하게 만드는 것(이것이 zero-shot으로 할 일) 대신, 이 프롬프트는 AI가 곧바로 하나의 권장 사항으로 뛰어드는 것을 막고 비교 자체를 명시적으로 만듭니다.

또 다른 실제 활용 사례: 아키텍처 결정. "사용자 세션을 저장해야 해. Redis, 데이터베이스 세션, JWT 토큰을 비교해 줘. 각각에 대해 장점(pros), 단점(cons), 그리고 실패 모드(failure modes)를 나열하고. 마지막으로 MVP를 구축하는 두 명의 팀에게 가장 적합한 것을 추천해 줘."**

사용 시점: AI가 단순히 하나를 고르는 것이 아니라, 여러 유효 옵션들을 비교해야 하는 모든 결정 상황. 기술 스택 선택, 아키텍처 설계 결정, 어떤 서브시스템이 문제인지 확신할 수 없는 디버깅 상황 등.

5. 역할 부여 프롬프트 (Role-Playing Prompts)

개념: AI에게 특정 전문가 역할을 맡도록 지시하는 것입니다. 이것은 단순한 트릭이 아니라, 응답의 깊이와 관점을 실제로 변화시킵니다.

교과서적인 예시:

"당신이 노련한 벤처 캐피털리스트라고 가정해 주세요. 이 스타트업 피치를 검토해 주세요."

개발자 예시:

당신은 코드 리뷰를 수행하는 선임 백엔드 엔지니어입니다. 이 Express.js 라우트 핸들러를 검토하고, 보안 취약점, 성능 문제 또는 아키텍처 관련 우려 사항이 있다면 모두 지적해 주세요. 구체적으로 언급하여 줄 번호를 제시하고 왜 그것이 문제인지 설명해 주세요.

역할을 부여하지 않으면 AI는 정중하고 일반적인 리뷰를 제공합니다. 하지만 역할을 부여하면 실제로 무언가를 잡아내는 선임 개발자처럼 행동하기 시작합니다. "14번째 줄: 사용자 입력을 SQL 쿼리에 직접 삽입(interpolate)하고 있어. 이건 전형적인 SQL 인젝션 벡터야."

저는 또한 취업 시즌에 이 방식을 역으로 사용한 적이 있습니다. "당신은 제품 기반 회사에서 엄격한 기술 면접관입니다. 내 이해도의 허점을 찾을 때까지 이 프로젝트에 대해 후속 질문을 해 주세요." 불편합니다. 하지만 이것이야말로 실제 상황 전에 얻을 수 있는 가장 가까운 무료 리허설입니다.

실제로 도움이 되는 다른 역할:

• _

언제 사용해야 하는가: 코드 리뷰, 이력서 피드백, 면접 준비, 팀원들이 갖지 못한 관점에서 제2의 의견을 얻고 싶을 때. 이 역할은 AI의 초점을 특정 전문가가 중요하게 생각하는 부분으로 좁혀줍니다.

6. 생성 지식 프롬프팅 (Generated Knowledge Prompting)

개념: 실제 작업을 요청하기 전에, 먼저 해당 주제에 대해 AI가 알고 있는 모든 것을 나열하도록 요청합니다. 연구를 먼저 하고, 작성을 나중에 합니다.

교과서적 예시:

"삼림 벌채에 관한 에세이를 작성해 주세요. 먼저 핵심 사실들을 목록으로 만들어 주세요."

개발자 예시:

저희 인증 플로우(authentication flow)에 대한 문서를 작성해야 합니다. 어떤 것도 쓰기 전에:

1. 사용자가 "로그인"을 클릭하는 순간부터 대시보드에 도착할 때까지 발생하는 모든 단계를 나열해 주세요. 토큰 생성, 쿠키 처리, 리디렉션 로직 등을 포함합니다.
2. 이제 그 목록을 기반으로 개발자 문서를 작성해 주세요.

여기서 핵심은 1단계입니다. AI에게 먼저 지식 기반(knowledge base) 생성을 강제함으로써, 글쓰기가 사실적인 토대 위에 놓이게 됩니다. 이것 없이는 AI가 사용자의 특정 플로우를 놓치는 일반적인 문서로 표류하기 쉽습니다.

언제 사용해야 하는가: 문서를 작성하거나, README 파일을 만들거나, 기술 블로그 게시물(아이러니하죠?) 또는 창의성보다 사실적 정확성이 더 중요한 모든 작업에서 유용합니다. "먼저 알고 있는 것을 목록으로 나열하라"는 단계 자체가 자체적인 사실 확인 절차 역할을 합니다.

7. 마이에우틱 프롬프팅 (Maieutic Prompting)

개념: 소크라테스식 방법(Socratic method)에서 이름을 따왔습니다. 질문을 던지고, AI에게 그 자신의 답변을 더 깊이, 그리고 또 더 깊게 설명해 달라고 요청하는 방식입니다. 실제로 이해할 때까지 재귀적으로 질문합니다.

교과서적 예시:

"하늘이 파란 이유를 설명해 주세요. 그런 다음 왜 푸른빛이 더 많이 산란되는지 설명해 주세요."

개발자 예시:

useMemo을 사용하고 있음에도 불구하고 React 컴포넌트가 모든 상태 변경 시마다 재렌더링(re-rendering)하는 이유는 무엇인가요?

이제 useMemo에 의존성 배열(dependency array)이 왜 중요한지 설명해 주세요.

마지막으로 JavaScript 객체의 맥락에서 "참조적 동등성(referential equality)"이 무엇을 의미하며, 이것이 메모이제이션(memoization)을 깨뜨리는 이유는 무엇인지 설명해 주세요.

각 후속 질문은 AI가 한 단계 더 깊이 파고들도록 강제합니다. 세 번째 질문에 이르면, 단순히 '재렌더링되고 있다'는 것을 이해하는 단계를 넘어 JavaScript의 객체 비교 모델이 React의 Reconciliation 알고리즘과 근본적으로 어떻게 상호작용하는지까지 이해하게 됩니다.

언제 사용하나요: 새로운 개념을 배울 때. 첫 번째 답변은 말이 되지만, 뭔가 완전히 이해하지 못한 밑바탕이 있다는 느낌이 들 때입니다. 이것은 '근데 왜?' 기법입니다.

8. Least-to-Most Prompting (최소에서 최대로 프롬프팅)

개념: AI에게 큰 문제를 먼저 하위 문제들로 나누게 한 다음, 순서대로 각 문제를 해결하도록 지시하는 것입니다. 분해하고, 실행합니다.

교과서 예시:

"3x + 5 = 20을 풀기 위한 하위 문제들을 나열한 후, 각각 풀어줘."

개발자 예시:

내 Next.js 앱에 Google OAuth를 추가해야 해. 내가 해결해야 할 모든 하위 문제들을 순서대로 분해해 줘. 그리고 코드와 함께 하나씩 설명해 줘.

출력은 다음과 같은 형태가 될 것입니다:

1. Google Cloud Console 프로젝트 설정 및 자격 증명 확보
2. NextAuth.js 설치 및 구성
3. 인증 API 라우트 생성
4. Google Provider 설정 추가
5. 세션 확인을 통해 라우트 보호
6. 콜백 처리 및 사용자 데이터 저장

그러면 AI가 각 단계를 순차적으로 해결하며, 각 단계는 이전 단계에 기반합니다.

이것은 제가 모든 해커톤 마감 기한을 넘길 수 있었던 기본 원리입니다. '24시간 안에 작동하는 데모 만들기'라는 전체 범위를 보고 패닉에 빠지기보다, 실제 순서가 있는 일련의 과정으로 쪼개는 것이죠.

언제 사용하나요: 이전에 만들어 본 적 없는 기능을 구현할 때. 단순히 "인증을 어떻게 추가해?"라고 물어보는 것(막연한 개요만 얻게 됩니다) 대신, AI에게 실제로 구축 가능한 순서로 제공하도록 강제하는 것입니다.

9. Format-Specific Prompting (형식 지정 프롬프팅)

개념: 원하는 출력 형식을 AI에게 명시적으로 알려주는 것입니다. 글머리 기호(Bullet points), 표(Table), JSON, 마크다운(Markdown), CSV 등 — 형식을 지정하면 AI가 이를 따릅니다.

교과서 예시:

"최고의 영화 5편을 글머리 기호로 나열해 줘."

개발자 예시:

React용 세 가지 상태 관리 라이브러리를 비교해 주세요. 다음 열을 가진 마크다운 테이블로 출력하세요: Library, Bundle Size, Learning Curve, Best For, and Drawback.

또는:

이 오류 로그를 JSON 배열로 변환하여 각 객체에 timestamp, level, message, 그리고 source 필드를 갖도록 하세요.

이것은 가장 과소평가된 기술 중 하나입니다. 대부분의 개발자는 형식을 지정하지 않고 AI의 응답을 재구성하는 데 5분을 허비합니다. 처음부터 알려주세요.

언제 사용하나요: 출력을 특정 형태로 받고 싶은 모든 경우에 해당됩니다. 표, JSON, 코드 블록, 글머리 기호(bullet points), 번호가 매겨진 단계 등입니다. 어차피 출력 형식을 재구성할 거라면 시간을 낭비하는 것입니다.

10. 다중 턴 프롬프팅 (Multi-Turn Prompting)

개념: 대화에서 여러 메시지에 걸쳐 컨텍스트를 구축하는 것입니다. 각 프롬프트는 이전 응답을 기반으로 구축됩니다. 이것이 AI를 검색 엔진에서 협업자로 전환시키는 방법입니다.

교과서적인 예시: