프롬프트 엔지니어링

프롬프트 엔지니어링이란?

프롬프트 엔지니어링이 자리 잡으면 팀의 대화부터 바뀝니다. '그 AI 별로더라'로 끝나던 평가가 '어떤 지시문으로 물었는지 화면 좀 보여달라'로 넘어갑니다. 결과의 책임이 모델이 아니라 지시문 쪽으로 옮겨오는 것이 이 기술의 실질입니다. 잘 다듬은 지시문은 개인의 감각이 아니라 팀이 복사해 쓰는 문서 자산으로 남아, 누가 돌려도 비슷한 수준의 결과가 나옵니다.

실무에서는 지시문을 세 층으로 나눠 보면 정리가 쉽습니다. 매번 바뀌지 않는 회사 소개·톤·금지어는 시스템 프롬프트에, 이번 건의 목적과 대상은 사용자 프롬프트에, 판단 기준이 애매한 작업은 예시 2~5개를 붙이는 few-shot으로 처리합니다. 계산이나 다단계 추론은 '단계별로 따져본 뒤 결론만 출력하라'처럼 과정을 요구하면 오답이 눈에 띄게 줄어듭니다. 다만 프롬프트로 풀 수 있는 범위와 그 바깥은 구분해야 합니다. 내부 문서를 근거로 답해야 하면 RAG, 말투와 형식을 대량으로 고정해야 하면 파인튜닝 쪽이 맞고, 지시문만 고쳐서는 없던 사실이 생겨나지 않습니다.

현장에서 가장 흔한 오해는 '잘 듣는 주문'만 모으면 된다는 생각입니다. 커뮤니티에서 퍼온 문장을 붙여 넣고 결과가 시원찮으면 또 다른 문장을 찾는 식인데, 정작 우리 고객과 제약 조건은 한 줄도 안 적혀 있는 경우가 많습니다. 길이만 늘리는 것도 함정이라, 참고자료를 스무 장씩 붙이면 핵심 지시가 묻혀 엉뚱한 항목을 요약해 옵니다. 모델이 업데이트되면 기존 프롬프트가 깨진다는 점도 놓치기 쉬워, 분기마다 대표 프롬프트 5~10개는 다시 돌려보는 편이 안전합니다. 마지막으로 고객 명단이나 미공개 실적을 그대로 붙여 넣는 습관은 성능 문제가 아니라 보안 사고로 돌아옵니다.