프롬프트 엔지니어링 (역할 부여, CoT, 팀 적용)

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

"AI한테 그냥 말하면 되는 거 아닌가?" 하고 가볍게 생각했습니다. 그런데 막상 써보니, 같은 질문도 어떻게 구성하느냐에 따라 결과물이 완전히 달랐습니다. 프롬프트 엔지니어링이 단순한 테크닉이 아니라 '명확하게 생각하는 능력'이라는 걸 실감한 건 꽤 시간이 지난 뒤였습니다.

역할 부여와 CoT, 실제로 써보니 달랐습니다

처음에 변화가 느껴진 건 Role Prompting, 즉 역할 부여 기법을 쓰기 시작했을 때였습니다. Role Prompting이란 AI에게 특정 페르소나를 지정해 응답의 전문성과 일관성을 끌어올리는 방식입니다. "코드 리뷰해줘"라고 했을 때와 "당신은 10년 경력의 Python 시니어 개발자이며, 보안과 성능 최적화에 전문성이 있습니다. 아래 코드의 보안 취약점과 성능 병목을 지적하고 개선 방안을 제시해주세요"라고 했을 때, 결과물의 깊이가 전혀 달랐습니다. 역할이 구체적일수록 AI가 그 역할에 맞는 언어와 수준으로 응답한다는 걸 직접 수십 번 비교해보고서야 체감했습니다.

다만 역할 부여를 남발하면 역효과가 나기도 했습니다. 지나치게 좁은 역할을 주면 AI가 그 역할 밖의 맥락을 무시하는 경향이 생겼습니다. "보안 전문가"로만 설정하면 코드 가독성이나 유지보수 문제는 언급하지 않는 식이죠. 역할은 출발점이지, 답변의 경계선이 아닙니다. 이 점을 처음에 몰랐다가 몇 번 의도치 않게 편향된 피드백을 받았습니다.

그다음으로 제가 자주 쓰게 된 건 Chain of Thought(CoT) 프롬프팅입니다. CoT란 AI 모델이 문제를 단계별로 추론하도록 유도해 복잡한 다단계 문제를 더 정확하게 해결하도록 돕는 기법입니다. 단순히 다음 단어를 예측하는 방식에서 벗어나, 중간 추론 과정을 명시적으로 생성하게 만드는 것이 핵심입니다. "단계별로 생각해봐(Let's think step by step)" 같은 트리거 문구 하나만 넣어도 응답의 질이 달라집니다.

솔직히 이건 예상 밖이었습니다. "새 기능을 지금 개발해야 할까?"라고 물으면 단순한 예/아니오가 나오지만, 현재 기술 부채 현황을 분석하고, 기능의 비즈니스 임팩트를 추정하고, 리소스 대비 ROI를 계산한 후, 최종 권고안을 제시하라고 단계를 명시했을 때는 실제 의사결정에 쓸 수 있는 수준의 분석이 나왔습니다. IBM 공식 문서에 따르면 CoT는 산술, 상식, 기호 추론 등 다단계 문제에서 LLM의 정확도를 크게 향상시킨다고 명시하고 있습니다.

구조화 프롬프팅도 빼놓을 수 없습니다. 구조화 프롬프팅이란 XML 태그, 번호 리스트, 구분자 같은 마크업 요소를 활용해 입력을 명확하게 구분함으로써 AI가 각 섹션의 역할을 혼동 없이 처리하도록 돕는 방식입니다. 긴 문서를 태그로 구분해주면 AI가 각 부분의 맥락을 훨씬 정확하게 파악했습니다. 시스템 프롬프트가 길어질수록 이 구조화 작업이 필수라는 걸 뼈저리게 느꼈습니다.

효과가 입증된 핵심 기법들을 정리하면 이렇습니다. Role Prompting은 구체적인 페르소나와 전문 영역을 명시할수록 응답 품질이 올라갑니다. Chain of Thought(CoT)는 단계별 추론 지시로 복잡한 문제의 정확도를 높입니다. Few-shot 기법은 예시를 2~3개 제시해 원하는 출력 형식을 사전에 학습시킵니다. 구조화 프롬프팅은 태그와 구분자로 입력의 각 역할을 명확히 분리합니다.

CoT를 팀에 적용하며 배운 것들

프롬프트 엔지니어링을 혼자만 쓰다가 팀으로 확장했을 때, 예상치 못한 문제가 생겼습니다. 팀원마다 AI에게 요청하는 방식이 제각각이었고, 같은 업무인데도 결과물의 질이 사람마다 달랐습니다. 그래서 Notion에 '프롬프트 라이브러리'를 구축했습니다. 자주 쓰는 역할 정의, 형식 템플릿, CoT 예시를 팀이 함께 공유하고 개선하는 방식으로 운영하니, 팀 전체의 AI 활용 수준이 눈에 띄게 빠르게 올라갔습니다.

특히 Few-shot 기법이 팀 운영에서 힘을 발휘했습니다. Few-shot 기법이란 AI에게 원하는 입출력 예시를 2~3개 미리 보여줌으로써, 별도의 긴 설명 없이도 원하는 형식과 수준의 응답을 유도하는 방법입니다. 팀 내에서 잘 만들어진 프롬프트 예시를 공유하자, 새로 합류한 팀원도 금방 비슷한 수준의 결과물을 뽑아낼 수 있었습니다. 팀 도입 시 가장 빠른 효과를 보이는 지점이었습니다.

다만 프롬프트 라이브러리를 운영하면서 한 가지 문제가 생겼습니다. 팀원들이 라이브러리에 있는 프롬프트를 맥락 없이 복붙하기 시작한 거죠. 프롬프트 엔지니어링의 핵심이 "지금 내가 원하는 게 뭔가"를 명확히 아는 것인데, 복붙은 그 생각 자체를 건너뜁니다. 결국 좋은 프롬프트 라이브러리는 결과물을 제공하는 곳이 아니라, 사고 방식의 예시를 제공하는 곳이어야 합니다. 이걸 뒤늦게 깨닫고 라이브러리에 "이 프롬프트를 왜 이렇게 썼는지" 설명을 추가했습니다.

한 가지 덧붙이고 싶은 건, OpenAI o1 모델처럼 CoT 추론이 이미 내장된 모델들이 등장하면서 기법의 의미가 조금씩 달라지고 있다는 점입니다. 이런 모델들은 별도 프롬프트 없이도 연쇄적 사고가 작동하기 때문에, 프롬프트 설계보다는 '무엇을 원하는지 명확히 아는 것' 자체가 더 중요해지고 있습니다. Anthropic의 공식 프롬프트 엔지니어링 문서에서도 명확한 지시와 구조화된 입력의 중요성을 강조하고 있습니다.

프롬프트 엔지니어링이 마치 별도의 전문 직군처럼 과장되는 경향이 있는데, 제 경험상 이건 좀 다릅니다. 결국 핵심은 '명확하게 생각하고 명확하게 쓰는 능력'이고, 이는 글쓰기나 기획 역량과 본질적으로 같습니다. 기술로 숭배하기보다 '좋은 의사소통의 확장'으로 바라볼 때, 오히려 더 실용적으로 활용할 수 있었습니다.

결국 프롬프트 엔지니어링에서 가장 먼저 물어야 할 질문은 "어떤 기법을 쓸까?"가 아니라 "내가 원하는 게 정확히 뭔가?"입니다. 그 질문에 명확하게 답할 수 있다면, 역할 부여든 CoT든 자연스럽게 따라옵니다. 지금 AI 활용이 잘 안 된다고 느끼신다면, 프롬프트 기법을 더 배우기보다 자신이 원하는 결과물을 글로 정확하게 써보는 연습부터 시작해보시길 권합니다.

---

참고:
카카오클라우드 블로그 — "프롬프트 엔지니어링이란 ③ - 고급 기법 (CoT, ToT, ReAct)": https://blog.kakaocloud.com/87
IBM — "생각의 사슬(CoT) 프롬프트란 무엇인가요?": https://www.ibm.com/kr-ko/think/topics/chain-of-thoughts
Botpress KO — "Chain-of-thought 프롬프트란 무엇인가요?": https://botpress.com/ko/blog/chain-of-thought
SK devocean — "고급 프롬프트 엔지니어링으로 GPT 앱을 만들어보자!": https://devocean.sk.com/blog/techBoardDetail.do?ID=167731
Anthropic 공식 — 프롬프트 엔지니어링 개요: https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview