딥러닝 시험 공부하다 정리한 프롬프팅 기법 10가지 (10 Prompting Techniques My Deep Learning Exam Taught Me)

DEV Community

10 Prompting Techniques My Deep Learning Exam Taught Me (That I Actually Use Now)

You already use prompting every day. You just don't know the names of what you're doing. Every time...

Dhruv Jani · 2026-10-17

개요 #

ChatGPT에 "이 에러 고쳐줘"라고 치거나 Cursor에 "이 함수 리팩터링해줘"라고 입력하는 것도 이미 프롬프팅 기법입니다. 다만 대부분은 자기가 쓰는 방식에 이름이 있다는 것도, 그보다 나은 방법이 여럿 있다는 것도 모른 채 쓰고 있습니다.

Dev.to 작성자 Dhruv Jani는 딥러닝 시험을 준비하면서 50쪽짜리 PDF 두 개로 프롬프팅 기법을 공부했습니다. 그런데 예시가 하나같이 "SF 소설 추천해줘", "섭씨 0도를 화씨로 바꿔줘" 같은 것이었습니다. 틀린 말은 아니지만, 섭씨 변환하려고 ChatGPT를 여는 사람은 없습니다.

그래서 작성자는 강의계획서에 나온 기법 10가지를 개발자가 실제로 쓰는 예시로 다시 정리했습니다.

질문을 던지는 방식: 기본 기법 #

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

예시나 맥락 없이 바로 묻는 방식입니다.

• 교과서 예시: "SF 소설 추천해줄래?"
• 개발자 예시: "React의 useEffect 클린업 함수는 무슨 역할을 해?", "git rebase와 git merge의 차이를 세 문장으로 설명해줘."

에러 메시지만 붙여 넣고 결과를 기다리는 것도 제로샷입니다. 모델이 수없이 본 질문에는 잘 통합니다. 하지만 질문이 조금이라도 특수해지면 금방 한계가 드러납니다.

• 쓸 때: 간단한 조회, 문법 질문, "X가 뭐 하는 거야" 같은 질문
• 안 통할 때: 내 코드베이스, 내 아키텍처, 모델이 학습하지 않은 내용이 얽힌 질문

2. 퓨샷 프롬프팅 (Few-Shot) #

원하는 결과물의 예시를 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 응답 형식을 새 형식으로 바꿀 때도 쓸모가 있습니다. 변환 전후 예시 세 개를 보여주고 네 번째 응답을 붙여 넣으면 됩니다. 한 번 쓰고 버릴 스크립트를 짤 필요가 없어집니다.

• 쓸 때: 형식 통일, 스타일 맞추기, 반복 변환. "이거 40번 더 해야 하는데" 싶을 때

3. 사고의 사슬 프롬프팅 (Chain-of-Thought) #

결론으로 바로 가지 말고 한 단계씩 따져보게 하는 방식입니다. 교과서에서는 "23 × 47은? 풀이 과정도 보여줘" 같은 예시를 씁니다.

개발자라면 이렇게 물을 수 있습니다. "이 함수는 할인 적용 후 총액을 돌려줘야 하는데, 어떤 입력에서는 NaN이 나와. 무슨 일이 일어나는지 단계별로 짚어줘."

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

"단계별로"라는 말이 없으면 모델은 "함수에 문제가 없어 보입니다"라고 끝낼 수 있습니다. 이 말을 붙이면 경계 사례까지 따라갑니다. 예를 들어 discount에 '10%' 같은 문자열이 들어오면 곱셈 결과가 NaN이 되고, 그 값이 계산 전체로 번진다는 식입니다.

작성자는 단계별 설명을 요청한다고 모델의 실제 내부 추론이 드러나는 것은 아니라고 선을 긋습니다. 그래도 전제, 중간 확인, 고려한 경계 사례, 결론 순서로 답이 정리되니 검토하기가 훨씬 쉽고 실수도 눈에 잘 띕니다.

자기 프로젝트의 서비스 워커에서 clients.matchAll() 경쟁 상태(race condition)를 찾을 때도 이 방법을 썼습니다. Copilot의 첫 답은 자신만만했지만 완전히 틀렸습니다. "고쳐줘" 대신 "이 두 이벤트 사이에 무슨 일이 일어나는지 추적해줘"라고 이벤트 생명주기를 한 단계씩 짚게 하자 타이밍 버그가 드러났습니다.

• 쓸 때: 디버깅, 코드 리뷰처럼 답보다 추론 과정이 중요한 질문. AI가 자신 있게 틀린 답을 내놓은 적이 있다면 아마 이 과정이 빠져 있었을 겁니다.

4. 사고의 나무 프롬프팅 (Tree-of-Thought) #

추론 경로 하나만 따라가지 않고 여러 경로를 나란히 살펴보게 합니다. 사고의 사슬이 직선이라면 사고의 나무는 의사결정 트리입니다.

앱에 실시간 알림을 넣으려고 해. WebSocket, Server-Sent Events, 폴링 세 가지 방식을 각각
복잡도·확장성·브라우저 지원 측면에서 장단점을 설명해줘. 그다음 Node 백엔드를 쓰는
소규모 팀에 어떤 방식이 맞는지 추천해줘.

제로샷으로 물으면 모델은 하나를 골라 그 선택을 변호하기 쉽습니다. 이렇게 물으면 바로 추천으로 넘어가지 않고 비교부터 하게 됩니다.

아키텍처 결정에도 그대로 쓸 수 있습니다. "사용자 세션을 저장해야 해. Redis, DB 세션, JWT를 비교해서 각각 장점·단점·장애 시나리오를 정리하고, 두 명이 MVP를 만드는 팀에 맞는 걸 하나 추천해줘."

• 쓸 때: 기술 스택 선택이나 아키텍처 결정처럼 선택지가 여럿인 문제. 어느 서브시스템이 문제인지 모를 때의 디버깅

5. 역할 부여 프롬프팅 (Role-Playing) #

특정 전문가처럼 행동하라고 지시합니다. 작성자는 이것이 장난이 아니며, 실제로 답변의 깊이와 관점이 달라진다고 말합니다.

너는 코드 리뷰를 맡은 시니어 백엔드 엔지니어야. 이 Express.js 라우트 핸들러에서
보안 취약점, 성능 문제, 아키텍처상 우려를 짚어줘. 해당 줄을 명시하고 왜 문제인지 설명해.

역할이 없으면 무난하고 일반적인 리뷰가 나옵니다. 역할을 주면 꼼꼼한 시니어 개발자처럼 "14번째 줄: 사용자 입력을 SQL 쿼리에 그대로 넣고 있습니다. 전형적인 SQL 인젝션 경로입니다" 같은 지적이 나옵니다.

작성자는 취업 시즌에 이 방법을 반대 방향으로도 썼습니다. "너는 제품 회사의 깐깐한 기술 면접관이야. 내 이해에 빈틈이 보일 때까지 이 프로젝트에 대해 꼬리 질문을 해줘." 불편하긴 해도 실제 면접 전에 무료로 해볼 수 있는 가장 비슷한 리허설이라고 합니다.

그 밖에 쓸 만한 역할도 있습니다.

• "너는 테크 리크루터야. 이 이력서에서 약한 부분이 뭐야?"
• "너는 QA 엔지니어야. 이 함수의 경계 사례를 찾아줘."
• "너는 DevOps 엔지니어야. 이 Dockerfile에서 뭐가 잘못됐어?"

역할을 정하면 그 전문가가 신경 쓸 부분으로 답의 초점이 좁혀집니다.

생각을 끌어내는 방식: 심화 기법 #

Photo by Markus Winkler on Pexels

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

본 작업에 앞서 주제에 관해 아는 내용을 먼저 나열하게 합니다. 조사가 먼저고 글쓰기는 그다음입니다.

우리 인증 흐름 문서를 써야 해. 쓰기 전에:

1. 사용자가 "로그인"을 누른 순간부터 대시보드에 도착할 때까지 일어나는 모든 단계를
   나열해줘. 토큰 발급, 쿠키 처리, 리다이렉트 로직도 포함해서.
2. 그 목록을 바탕으로 개발자 문서를 작성해줘.

핵심은 1단계입니다. 사실 목록을 먼저 만들게 하면 글이 그 목록에서 벗어나지 않습니다. 이 단계를 건너뛰면 우리 흐름과는 상관없는 일반론 문서가 나오기 쉽습니다.

• 쓸 때: 문서, README, 기술 블로그 글처럼 창의성보다 정확성이 중요한 작업. "먼저 아는 걸 나열하라"는 단계가 스스로 사실을 점검하는 역할을 합니다.

7. 산파술 프롬프팅 (Maieutic) #

소크라테스의 산파술에서 이름을 따왔습니다. 질문하고, 그 답을 더 깊이 설명하게 하고, 다시 한 번 더 파고듭니다.

1. "useMemo를 쓰는데도 왜 상태가 바뀔 때마다 React 컴포넌트가 다시 렌더링돼?"
2. "그럼 useMemo에서 의존성 배열이 왜 중요한지 설명해줘."
3. "JavaScript 객체에서 '참조 동일성(referential equality)'이 무슨 뜻이고, 왜 메모이제이션을 깨뜨리는지 설명해줘."

질문 하나마다 한 겹씩 내려갑니다. 세 번째 질문쯤이면 "다시 렌더링된다"는 현상에서 출발해 JavaScript의 객체 비교 방식이 React 재조정(reconciliation) 알고리즘과 어떻게 맞물리는지까지 이해하게 됩니다.

• 쓸 때: 새 개념을 배울 때. 첫 답은 그럴듯한데 그 밑에 아직 모르는 게 있다는 느낌이 들 때 쓰는 "근데 왜?" 기법입니다.

8. 최소-최대 프롬프팅 (Least-to-Most) #

큰 문제를 하위 문제로 쪼갠 다음 순서대로 풀게 합니다. 먼저 분해하고 나서 실행합니다.

"Next.js 앱에 Google OAuth를 붙여야 해. 풀어야 할 하위 문제를 순서대로 모두 나눠주고, 하나씩 코드와 함께 설명해줘."라고 물으면 대략 이런 답이 나옵니다.

1. Google Cloud Console 프로젝트를 만들고 자격 증명 발급
2. NextAuth.js 설치 및 설정
3. 인증 API 라우트 생성
4. Google 프로바이더 설정 추가
5. 세션 확인으로 라우트 보호
6. 콜백 처리와 사용자 데이터 저장

그다음 모델이 각 단계를 순서대로 풀고, 단계마다 앞 단계 위에 쌓아 올립니다.

작성자는 해커톤 마감도 이렇게 버텼다고 합니다. "24시간 안에 동작하는 데모 만들기"를 통째로 바라보며 당황하는 대신, 실제로 따라갈 수 있는 순서로 쪼갰다는 것입니다.

• 쓸 때: 처음 만들어보는 기능을 구현할 때. "인증 어떻게 붙여?"라고 물으면 막연한 개요가 나오지만, 이렇게 물으면 바로 따라 만들 수 있는 순서가 나옵니다.

결과를 다듬는 방식: 형식과 대화 #

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

출력 형식을 명시합니다. 글머리표, 표, JSON, 마크다운, CSV 중 무엇이든 정해주면 모델이 따릅니다.

• "React 상태 관리 라이브러리 세 개를 비교해줘. 열은 라이브러리, 번들 크기, 학습 난이도, 적합한 용도, 단점으로 된 마크다운 표로 출력해."
• "이 에러 로그를 timestamp, level, message, source 필드를 가진 객체들의 JSON 배열로 바꿔줘."

작성자는 이 기법이 가장 과소평가돼 있다고 봅니다. 형식을 정하지 않고 답을 받은 뒤 다시 정리하느라 5분씩 쓰는 개발자가 많다는 겁니다. 어차피 형식을 바꿀 거라면 처음부터 말하는 편이 낫습니다.

10. 멀티턴 프롬프팅 (Multi-Turn) #

여러 메시지에 걸쳐 맥락을 쌓아가는 방식입니다. 프롬프트마다 앞의 답 위에 다음 요청을 얹습니다. 작성자는 이렇게 해야 AI가 검색 엔진이 아니라 협업자가 된다고 말합니다.

• 1턴: "우리 Express 앱 폴더 구조야. (tree 출력 붙여 넣기) 아키텍처를 설명해줘."
• 2턴: "여기에 알림 서비스를 추가하려고 해. 이 구조에서 어디에 두고, 무엇을 import해야 해?"
• 3턴: "기존 서비스들과 같은 패턴으로 그 서비스의 보일러플레이트를 작성해줘."
• 4턴: "__tests__/user.service.test.js의 테스트 스타일에 맞춰서 테스트도 작성해줘."

4턴쯤 되면 모델은 폴더 구조, 아키텍처 패턴, 네이밍 규칙, 테스트 스타일을 모두 알고 있습니다. 한 번의 프롬프트로는 이만큼 맞춤형 결과를 얻기 어렵습니다. 같은 맥락을 매번 새 프롬프트에 붙여 넣고 있다면 멀티턴으로 바꿀 때입니다.

한눈에 보는 요약표 #

진짜 요령은 조합 #

작성자는 교과서가 알려주지 않은 점을 하나 강조합니다. 기법 하나만 골라 계속 쓰는 게 아니라는 것입니다. 잘 쓴 프롬프트는 보통 두세 가지를 섞습니다.

• 사고의 사슬 + 역할 부여: "너는 시니어 엔지니어야. 이 함수를 단계별로 디버깅해줘."
• 퓨샷 + 형식 지정: "내 커밋 메시지 예시 세 개야. 같은 스타일로 다음 다섯 개를 글머리표 목록으로 써줘."
• 지식 생성 + 최소-최대: "Next.js 앱을 AWS에 배포할 때 필요한 걸 모두 나열해줘. 그다음 하위 문제로 나눠서 하나씩 설명해줘."

작성자 말을 빌리면 기법은 재료이고, 어떤 재료를 섞을지 아는 게 실력입니다. 그는 섭씨 변환과 SF 소설 추천으로 가득한 PDF에서 이 내용을 배웠지만, 독자는 내일 바로 터미널을 열어 써볼 수 있는 예시로 익히길 바란다며 글을 마칩니다. 그리고 목록에 없는 자기만의 프롬프팅 요령이 있는지, 이름이 있는 줄 몰랐던 기법이 있었는지 댓글로 알려달라고 덧붙였습니다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.