프롬프트 엔지니어링 기초: 마법의 주문이 아니라, 재현되는 규칙

프롬프트 팁 모음을 보면 “이 문장을 앞에 붙이면 성능이 3배” 같은 주장이 흔하다. 대부분 재현되지 않는다. 한 번 잘 나온 결과를 프롬프트의 공으로 돌렸을 뿐, 다음 주제에 같은 주문을 붙이면 아무 일도 일어나지 않는다.

반대로 주제를 바꿔도, 모델을 바꿔도 계속 먹히는 것들이 있다. 그것들의 공통점은 하나다. 모델이 알아서 정해야 했던 결정을 사람이 대신 정해주는 것이다. 아래 일곱 가지가 전부 그 형태다.

규칙 1. 역할을 지정한다

원리: 답변의 어휘·깊이·전제를 한 번에 고정한다.

• 나쁜 예: 쿠버네티스 설명해줘
• 고친 예: 쿠버네티스를 도커는 써봤지만 오케스트레이션은 처음인 백엔드 개발자에게 설명해줘.

달라지는 것은 문체가 아니라 생략의 기준이다. 앞의 프롬프트는 독자를 모르니 컨테이너부터 다시 설명하거나 반대로 너무 앞서간다. 뒤의 프롬프트는 “도커는 안다”는 정보 하나로 앞부분을 통째로 건너뛴다.

규칙 2. 출력 형식을 명시한다

원리: 형식을 안 정하면 모델이 정한다. 그리고 대체로 산문으로 정한다.

• 나쁜 예: 이 로그에서 문제점 정리해줘
• 고친 예: 이 로그의 문제점을 표로 정리해줘. 열은 시각 / 증상 / 추정 원인 / 확인 방법 네 개.

표를 요구하면 모델은 네 칸을 다 채우려고 추정 원인과 확인 방법을 따로 생각한다. 형식이 사고를 강제하는 셈이다. JSON, 체크리스트, 3단 구성 어느 쪽이든 마찬가지다.

규칙 3. 예시를 한두 개 준다

원리: 설명 열 줄보다 예시 하나가 정확하다.

• 나쁜 예: 제품명을 깔끔하게 정리해줘
• 고친 예: 제품명을 이렇게 정리해줘. 예) "삼성 갤럭시 S24 울트라 512GB 티타늄" → 브랜드: 삼성 / 모델: 갤럭시 S24 울트라 / 용량: 512GB

“깔끔하게”는 사람마다 다르지만 예시는 하나뿐이다. 형식이 조금이라도 특이하면 설명 대신 예시를 준다. 예시 두 개면 경계 사례까지 잡힌다.

규칙 4. 제약 조건을 건다

원리: 하지 말아야 할 것을 안 적으면 모델은 다 한다.

• 나쁜 예: 이 기능 코드 짜줘
• 고친 예: 이 기능 코드 짜줘. 외부 라이브러리 추가 없이, 기존 utils.py의 함수를 재사용하고, 파일은 새로 만들지 마.

제약은 품질을 떨어뜨리는 게 아니라 다시 손볼 일을 없앤다. 실무에서 결과물을 버리게 되는 이유는 대개 품질이 아니라 “우리 상황에 못 쓰는 형태”라서다.

규칙 5. 단계로 쪼갠다

원리: 한 번에 시키면 중간 단계에서 틀린 채로 끝까지 간다.

• 나쁜 예: 이 설문 응답 500개 분석해서 보고서 써줘
• 고친 예: 1단계로 응답을 5~7개 주제로 분류만 해. 분류 결과를 내가 확인한 다음 2단계를 시킬게.

사람이 중간에 개입할 지점을 만드는 것이 핵심이다. 분류가 틀린 채로 쓰인 보고서는 문장이 아무리 좋아도 처음부터 다시 해야 한다.

규칙 6. 판단 기준을 준다

원리: “좋은 걸로 골라줘”는 기준을 모델이 만든다는 뜻이다.

• 나쁜 예: 이 중에 제일 나은 안 골라줘
• 고친 예: 이 중 하나를 골라줘. 기준은 ① 2주 안에 구현 가능 ② 기존 DB 스키마 변경 없음 ③ 운영 인력 추가 없음. 각 기준별로 점수를 매기고 탈락 이유도 적어줘.

기준을 주면 결론뿐 아니라 탈락 사유가 따라온다. 그게 사람이 실제로 검토해야 하는 부분이다.

규칙 7. 한 번에 끝내지 않는다

원리: 첫 결과는 초안이다. 고칠 지점을 지목하는 게 새 프롬프트를 쓰는 것보다 빠르다.

• 나쁜 예: (결과가 마음에 안 들어 프롬프트를 처음부터 다시 씀)
• 고친 예: 3번 항목이 너무 일반론이야. 우리 상황(사용자 200명, 서버 1대)에 맞게 다시 써줘. 나머지는 그대로 둬.

“나머지는 그대로 둬”가 중요하다. 이 말이 없으면 전체가 새로 쓰이면서 마음에 들었던 부분까지 사라진다.

모델별로 다르게 먹히는 지점

일곱 규칙은 공통이지만 체감은 조금씩 다르다.

프롬프트를 자산으로 관리하는 법

잘 먹힌 프롬프트를 채팅창에 흘려보내는 것이 가장 흔한 낭비다. 세 가지만 해도 달라진다.

• 저장한다. 메모 앱이든 사내 위키든, “작업 이름 → 프롬프트” 형태로 모은다.
• 변수를 표시한다. 매번 바뀌는 부분을 {대상 독자} 처럼 괄호로 남겨두면 재사용이 쉬워진다.
• 왜 고쳤는지 한 줄 남긴다. v2: 형식 안 지켜져서 표 열 이름 명시 같은 메모가 다음 사람(대개 미래의 나)을 살린다.

프롬프트 엔지니어링을 따로 배울 필요는 없다. 다만 잘 된 프롬프트를 버리지 않는 습관은 배울 값어치가 있다.

자주 묻는 질문

프롬프트 엔지니어링을 따로 배워야 하나요?

강의를 들을 필요까지는 없습니다. 이 글의 일곱 가지 규칙이 실무에서 재현되는 거의 전부이고, 나머지는 자기 업무에 맞는 프롬프트를 모아두는 습관의 문제입니다. 모델이 좋아질수록 요령의 값어치는 줄고 요구사항을 명확히 쓰는 능력의 값어치가 커집니다.

긴 프롬프트가 항상 좋은가요?

아닙니다. 길이보다 구조입니다. 형용사를 늘어놓은 열 줄보다 역할·형식·제약 세 줄이 낫습니다. 다만 예시와 제약 조건은 길어져도 값을 하므로, 길이를 줄일 때는 수식어부터 버리세요.

프롬프트만으로 안 되는 일은 무엇인가요?

모델이 모르는 최신 정보, 사내 문서 같은 비공개 자료, 그리고 사실 확인이 필요한 수치입니다. 프롬프트는 모델이 가진 것을 잘 꺼내는 기술이지 없는 것을 만들어내는 기술이 아닙니다. 이 영역은 자료를 직접 첨부하거나 검색 기능을 쓰는 쪽으로 풀어야 합니다.

한글과 영어 중 뭐가 더 정확한가요?

일상적인 지시문은 차이가 거의 없습니다. 다만 전문 용어가 많은 기술 작업은 용어를 영어로 두는 편이 안정적이고, 결과물이 한국어여야 한다면 “답변은 한국어로”라고 따로 적어주는 편이 확실합니다.