프롬프트 엔지니어링 (역할 부여, 구조화, Chain of Thought)

프롬프트 엔지니어링 (역할 부여, 구조화, Chain of Thought)

솔직히 저는 꽤 오랫동안 프롬프트를 잘못 쓰고 있었습니다. "이 코드 고쳐줘", "이 기능 만들어줘" 수준의 요청을 던지고, 결과가 이상하면 그냥 답답해하며 같은 질문을 다시 보내는 패턴을 반복했습니다. AI가 잘못하는 줄 알았는데, 문제는 제 질문 방식에 있었습니다. 프롬프트를 어떻게 구성하느냐에 따라 같은 모델에서도 결과가 완전히 달라진다는 걸 뒤늦게 깨달았습니다.

역할 부여, 왜 이게 먼저여야 하는가

처음에 저는 역할 부여(Role Prompting)가 일종의 말장난처럼 느껴졌습니다. "시니어 Python 개발자로서 답해줘"라고 쓴다고 해서 뭐가 달라지겠냐는 생각이었습니다. 그런데 직접 써보니 달랐습니다. 역할이 없는 질문에는 개론 수준의 답변이 돌아오는 경우가 많았고, 역할을 명시했을 때는 에러 원인 추정, 코드 개선 우선순위, 운영 환경을 고려한 판단 같은 실제로 쓸 수 있는 답변이 나왔습니다.

여기서 역할 부여란, AI에게 특정 전문가의 관점과 사고 방식을 가정하게 만드는 기법입니다. 쉽게 말해, "이 질문에 어떤 배경지식을 가진 사람으로서 접근해라"고 맥락을 심어주는 것입니다. 저는 보안 관련 코드 리뷰를 요청할 때 "보안 감사 전문가로서"라는 역할을 붙이는데, 이렇게 했을 때 SQL 인젝션이나 인증 취약점에 대한 언급이 눈에 띄게 늘었습니다. SQL 인젝션(SQL Injection)이란 악의적인 SQL 코드를 입력 필드에 삽입해 데이터베이스를 무단으로 조작하는 공격 기법으로, 역할 없이 질문했을 때는 이 부분이 간과되는 경우가 많았습니다.

역할 부여가 효과적인 이유는 모델이 응답의 깊이와 관점을 조정하기 때문입니다. 역할이 없으면 모델은 가장 보편적인 답을 선택하고, 역할이 있으면 해당 전문가가 우선적으로 고려할 사항을 앞세웁니다. 같은 코드를 두고 "리뷰해줘"와 "시니어 DBA 역할로 성능 관점에서 리뷰해줘"의 차이는 생각보다 상당합니다.

구조화된 출력, 실전에서 가장 자주 쓰는 방법

역할을 정했다면, 다음은 출력 포맷을 명시하는 차례입니다. 제가 팀 노션에 프롬프트 템플릿을 정리하기 시작하면서 가장 먼저 표준화한 것이 바로 이 부분이었습니다. "원본 쿼리 / 문제점 / 개선된 쿼리 순서로 정리해줘"처럼 출력 구조를 지정하면, 답변을 읽으면서 제가 원하는 정보를 찾는 시간이 크게 줄어들었습니다.

구조화된 출력 요청에서 제가 가장 효과적이라고 느낀 방식은 부정 지시어(Negative Instruction)를 함께 쓰는 것입니다. 부정 지시어란 "~하지 마"처럼 원하지 않는 요소를 명시적으로 제거하는 표현 방식입니다. "설명 없이 코드만 줘", "주석 달지 마", "배경 설명 생략하고 결론부터 줘" 같은 지시가 여기 해당합니다. 특히 코드 작업에서는 설명이 길어질수록 오히려 핵심을 찾기 어려워지는 경우가 있어서, 부정 지시어가 실질적인 도움이 됩니다.

제가 실전에서 가장 자주 쓰는 공식을 정리하면 다음과 같습니다.

• 역할 명시: 어떤 전문가로서 답할지 먼저 정한다
• 목적 기술: 무엇을 해결하고 싶은지 한 문장으로 쓴다
• 제약 조건: 어떤 방법은 쓰지 말아야 하는지 명시한다
• 출력 형식: 어떤 순서와 구조로 답해야 하는지 지정한다

이 네 가지를 조합하면 "시니어 DBA 역할로, 이 쿼리의 성능 문제를 분석해줘. 인덱스 변경 없이 쿼리 자체만 최적화하는 방향으로, 원본 쿼리 / 문제점 / 개선된 쿼리 순서로 정리해줘" 같은 프롬프트가 됩니다. 이 방식으로 작성한 프롬프트는 팀 내에서도 재사용하기 쉬워서, 비슷한 작업을 반복할 때 매번 새로 고민하지 않아도 됩니다(출처: Anthropic Prompt Engineering Overview).

Chain of Thought와 Few-shot, 복잡한 문제일수록 빛을 발한다

단순한 요청에는 앞의 두 가지만으로도 충분하지만, 복잡한 로직 설계나 버그 분석에서는 Chain of Thought(CoT)가 달라집니다. CoT란 모델이 답을 바로 내놓는 대신, 문제를 단계별로 풀어가도록 유도하는 기법입니다. "단계별로 생각해줘" 또는 "추론 과정을 먼저 설명한 뒤 결론을 내줘"라는 지시가 이에 해당합니다.

제가 처음 CoT를 써봤을 때 솔직히 예상 밖이었습니다. 단순히 "생각 과정을 보여줘"라는 말 한 마디가 버그 분석의 품질을 이렇게까지 높일 수 있다는 게 신기했습니다. 모델이 중간 과정을 명시하면서 스스로 오류를 잡아내는 경우가 실제로 있었고, 덕분에 저도 어느 단계에서 로직이 잘못됐는지 파악하기가 훨씬 수월해졌습니다. 구글이 발표한 CoT 관련 연구에서도 복잡한 추론 과제에서 CoT 없이 질문했을 때보다 정확도가 유의미하게 높아진다는 결과가 보고된 바 있습니다(출처: Google Research).

Few-shot prompting은 제가 코드 생성에서 가장 효과를 본 기법입니다. Few-shot prompting이란 원하는 결과물의 예시를 한두 개 먼저 보여주고 나서 실제 요청을 하는 방식입니다. 예시가 없으면 모델은 자신이 생각하는 가장 일반적인 형태로 코드를 만들어 내는데, 예시를 주면 제가 원하는 네이밍 컨벤션, 함수 구조, 에러 처리 방식까지 반영된 코드가 나옵니다. 특히 팀 내에서 코드 스타일을 통일해야 할 때 유용하게 썼습니다.

한 가지 솔직하게 덧붙이자면, 프롬프트 엔지니어링이 현재 과도하게 포장되어 있다는 느낌을 지우기 어렵습니다. 고연봉 직종처럼 소개되는 경우도 있지만, 모델이 발전할수록 복잡한 프롬프트 기술 없이도 원하는 결과를 얻기 쉬워지는 방향으로 진화하고 있습니다. 지금의 프롬프트 스킬은 어디까지나 과도기적 역량일 가능성이 있습니다. 더 근본적으로 중요한 것은 "내가 무엇을 원하는지 명확히 아는 능력"이고, 이건 AI가 없어도 개발 현장에서 요구사항을 명세하고 문제를 분해하는 능력과 본질적으로 같습니다.

프롬프트를 잘 쓰는 것은 분명 도움이 됩니다. 하지만 그것이 기술적 사고력을 대체하지는 않는다는 점, 결국 프롬프트를 잘 쓴다는 것은 자신이 원하는 것을 정확히 정의하는 훈련과 같다는 점을 기억하면서 접근하면 더 실용적으로 활용할 수 있을 것입니다.

---

참고:

1. Anthropic, Prompt Engineering Overview, https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
2. OpenAI, Prompt Engineering Guide, https://platform.openai.com/docs/guides/prompt-engineering
3. Lilian Weng, Prompt Engineering (Blog), 2023, https://lilianweng.github.io
4. DAIR.AI, Prompt Engineering Guide, https://www.promptingguide.ai
5. Learn Prompting, Open Source Guide, https://learnprompting.org