여전히 중요한 프롬프트 엔지니어링의 기본기

프롬프트 엔지니어링에는 평판 문제가 있습니다. 온라인에 떠도는 조언의 절반은 미신입니다. 어느 한 모델에서 한 번 통했던 마법 같은 문구와 의식이 어느새 법칙으로 일반화된 것이죠. 나머지 절반은 진짜 유용하지만 지루합니다. 이 글은 그 지루한 절반에 관한 이야기입니다. 모델과 버전이 바뀌어도 계속 통하는 기본기, 즉 이 시스템들이 실제로 우리가 준 텍스트를 어떻게 사용하는지를 반영하는 원칙들 말입니다.

왜 기본기가 잔재주를 이기는가

언어 모델은 컨텍스트에 담긴 모든 것, 즉 지시사항, 예시, 입력값을 바탕으로 응답을 생성합니다. "프롬프트 작성"이란 결국 이 컨텍스트를 잘 배열해서 가장 가능성 높은 다음 문장이 우리가 원하는 답이 되도록 만드는 기술입니다. 특정 모델의 버릇에 묶인 잔재주는 모델이 바뀌면 깨집니다. 반면 명확하게 쓰기, 예시 제공하기, 과제 구조화하기 같은 기본기는 어떤 유능한 모델에서든 원하는 출력의 가능성을 높여주기 때문에 계속 통합니다. 기본기를 다듬으면 잔재주가 필요할 일은 거의 없습니다.

1. 과제와 출력에 대해 구체적으로 말하라

가장 흔한 실패는 명세 부족입니다. "이거 요약해 줘"라는 말은 모델에게 수십 가지 결정을 떠넘깁니다. 얼마나 길게, 누구를 위해, 어떤 어조로, 무엇에 초점을 맞춰서. 명시되지 않은 결정 하나하나가 동전 던지기입니다. 실제로 원하는 것을 말하세요. "비기술직 관리자를 위해 비용과 리스크에 초점을 맞춰 세 개의 글머리 기호로 요약해 줘." 구체적이라는 건 장황한 게 아닙니다. 동전 던지기를 없애는 것입니다.

출력 형식에도 똑같이 적용됩니다. 특정 구조, 즉 목록, 표, JSON, 정해진 필드 집합이 필요하다면 명시적으로 말하고 그 형태를 보여주세요. 모델은 내용을 읽지 못하듯이 형식에 대한 당신의 마음도 읽지 못합니다.

2. 설명하지 말고 보여줘라

예시는 프롬프트 작성에서 가장 효율이 높은 도구입니다. 입력과 원하는 출력을 보여주는 잘 만든 예시 한두 개는 설명 한 문단보다 더 많은 것을 전달합니다. 패턴을 묘사하는 대신 직접 시연하기 때문이죠. 이를 흔히 few-shot 프롬프팅이라고 부르는데, 통하는 이유는 간단합니다. 명확한 예시는 목표 패턴을 자명한 다음 문장으로 만들어 줍니다.

실무 팁 두 가지. 예시는 까다로운 경우를 포함해 실제 입력을 대표하도록 만드세요. 쉬운 경로만 다루는 예시는 쉬운 경로만 가르칩니다. 그리고 예시끼리 일관성을 유지하세요. 서로 모순되는 예시는 도움보다 혼란을 줍니다.

3. 모델에게 생각할 여유를 줘라

추론이 필요한 모든 것, 즉 여러 단계의 문제, 분석, 판단에서는 답을 즉시 요구하는 것보다 먼저 차근차근 풀어보게 하는 편이 더 나은 답을 내는 경우가 많습니다. 모델이 최종 답에 확정하기 전에 단계별로 추론하게 하면 바로 그 품질이 까다로운 과제들에서 품질이 개선되는 경향이 있습니다. 원리는 직관적입니다. 첫 토큰에서 답을 확정하는 모델은 수정할 수 없지만, 먼저 추론하는 모델은 수정할 수 있습니다.

실무 버전은 이렇습니다. 어려운 과제에서는 결론만이 아니라 추론을 먼저 요구한 뒤 결론을 요구하세요. 쉬운 과제에서는 건너뛰세요. 추론 단계는 토큰과 지연 시간을 잡아먹으며, 단순 조회에는 필요하지 않습니다.

4. 지시사항을 제 위치에 두어라

구조가 중요합니다. 지시사항을 입력과 명확히 분리하세요. 제목, 구분자, 라벨이 붙은 섹션을 활용해서, 무엇이 명령이고 무엇이 처리할 데이터인지 모델이 구분할 수 있게 하세요. 프롬프트가 지시사항과 내용을 하나의 텍스트 덩어리로 뭉쳐 놓으면 모델은 어느 쪽이 어느 쪽인지 추측해야 하고, 때로는 잘못 추측합니다. 약간의 구조가 그 모호함을 없앱니다.

시스템 차원의 지시사항(역할, 규칙, 제약)은 일반적으로 앞쪽에 평이하게 진술하는 것이 좋습니다. 처리할 입력은 입력이라고 명확히 표시하는 것이 좋습니다. 이 분리는 입력 안의 내용이 실수로 지시사항으로 읽히는 부류의 실패도 막아줍니다.

5. 실패 모드를 제약하라

모델은 답하지 말아야 할 때조차 답합니다. 과제에 "답 없음"의 경우가 있다면, 즉 정보가 없거나 요청이 범위를 벗어난 경우라면 명시적으로 말하세요. "텍스트에 답이 없으면, 명시되어 있지 않다고 답하라." 이 지시가 없으면 모델은 그럴듯한 추측으로 빈자리를 채웁니다. 원하는 실패 모드를 명명하면 자신만만한 날조가 정직한 "찾을 수 없음"으로 바뀝니다.

6. 실제 예시로 반복 개선하라

미신과 엔지니어링의 가장 큰 차이는 측정입니다. 인상적인 출력 하나로 프롬프트를 판단하지 마세요. 다양한 실제 입력 몇 개를 모아 프롬프트를 전부 돌려보고 결과를 읽으세요. 한 번에 하나씩만 바꾸세요. 시연 하나에서 가장 빛난 버전이 아니라 집합 전체에서 더 나은 버전을 유지하세요. 화려하지 않지만 이것이 게임의 전부입니다. 실제 사례 스무 개에서 이기는 프롬프트가 한 번 눈을 사로잡은 프롬프트를 이깁니다.

대체로 무시해도 되는 것

떠도는 조언 상당수는 잡음입니다. 명확함은 더하지 않고 길이만 늘리는 정교한 "페르소나", 미신적인 문구, 무관한 과제 사이에 그대로 복사된 경직된 템플릿 같은 것들이죠. 어느 것도 신뢰할 만하지 않습니다. 어떤 기법을 원하는 출력의 가능성을 높인다는 관점으로 설명할 수 없다면, 당신만의 평가로 입증되기 전까지는 미신으로 취급하세요.

정리

좋은 프롬프트 작성은 잔재주 보따리가 아닙니다. 명확함(무엇을 어떤 형태로 원하는지 정확히 말하기), 시연(예시 보여주기), 구조(지시사항을 입력과 분리하기), 측정(실제 사례로 반복 개선하기)입니다. 이 기본기들은 시스템이 컨텍스트를 사용하는 방식에 거스르지 않고 부합하기에 여러 세대의 모델을 거치며 살아남았습니다. 이것들을 잘 익히면 더 화려한 무언가가 필요할 일은 거의 없습니다.