다듬을지 새로 시작할지 판단하기

대화가 좋은 결과를 내지 못할 때 많은 사용자는 처음부터 다시 시작하기보다 계속해서 문제를 해결하려고 합니다. 이것이 바로 매몰 비용의 함정입니다. 대화에 더 오래 시간을 쏟을수록 대화를 포기하기가 더 어렵게 느껴집니다.

하지만 때로는 좋은 결과를 얻는 가장 빠른 방법이 대화를 닫고 더 나은 최초 프롬프트를 작성하는 것입니다. 언제 그렇게 결정해야 하는지를 아는 것은 프롬프트 설계의 핵심 능력입니다.

같은 오류를 두세 번 수정했는데도 모델이 계속 그 오류로 되돌아간다면 새로 시작해야 한다는 강력한 신호입니다.

일반적인 예시는 다음과 같습니다.

• 글머리표로 작성해 달라고 했지만 모델이 산문으로 작성하고, 이를 수정해도 다시 산문으로 작성합니다
• 기술 분야 독자를 지정했지만 초보자 수준의 설명을 계속 사용합니다
• 면책 문구를 넣지 말라고 했지만 계속 추가합니다

반복적으로 되돌아가는 현상은 대개 해당 지침을 대화 중간에 추가할 것이 아니라 최초 프롬프트에 포함해야 한다는 뜻입니다.

때로는 모델이 사용자가 설명한 작업을 정확히 수행하지만, 작업 설명 자체가 잘못된 경우가 있습니다. 실제로는 Y가 필요했는데 X를 요청한 것입니다.

예를 들어 "핵심 주장의 요약"을 요청했지만 실제로는 "주장의 약점을 파악하는 비판적 분석"이 필요했을 수 있습니다. 아무리 후속 프롬프트를 보내도 제대로 작성된 요약을 비판적 분석으로 바꿀 수는 없습니다. 처음부터 문제 설정이 잘못되었기 때문입니다.

결과가 능숙하지만 엉뚱하다면 최초 프롬프트를 다시 작성해야 합니다.

첫 번째 프롬프트에 잘못된 가정, 결함이 있는 전제 또는 부정확한 문맥이 포함되어 있었다면 그 위에 구축되는 모든 내용이 영향을 받습니다.

예시는 다음과 같습니다.

• 대상 독자를 잘못 설명하여 그들을 위한 내용을 다섯 차례에 걸쳐 생성했습니다
• 부정확한 제약 조건을 제시했습니다("API가 REST 기반이라고 가정"했지만 실제로는 GraphQL입니다)
• 모델의 문제 설정 방식에 영향을 주는 잘못된 배경 정보를 제공했습니다

대화 중간에 잘못된 전제를 수정하는 것은 신뢰하기 어렵습니다. 수정된 전제로 처음부터 새로 시작해야 합니다.

긴 대화에서는 시간이 지남에 따라 응답 품질이 저하되는 경우가 있습니다. 모델은 다음과 같은 변화를 보일 수 있습니다.

• 문맥 창이 가득 차면서 더 짧고 덜 자세한 응답을 생성합니다
• 앞서 한 말과 모순되기 시작합니다
• 일관성 부족이나 반복이 점점 심해집니다

이는 프롬프트의 문제가 아니라 문맥 창의 문제입니다. 새로운 대화를 시작하고 지금까지 정해진 내용을 압축한 요약으로 제공하는 것이 올바른 해결책입니다.

모든 불완전한 응답이 처음부터 다시 시작해야 할 이유가 되는 것은 아닙니다. 다음과 같은 경우에는 수정합니다.

• 내용은 대체로 정확하지만 형식을 바꿔야 합니다
• 전체 응답이 아니라 특정 부분 하나만 개선하면 됩니다
• 이미 생성된 내용을 이어서 늘리거나 확장하고 싶습니다
• 오류가 사소하고 명확한 후속 요청 한 번으로 해결할 수 있습니다

일반적인 기준은 다음과 같습니다. 모델이 목표를 이해했고 내용도 대부분 양호하다면 수정합니다. 목표 자체를 오해했다면 새로 시작합니다.

수정할지 새로 시작할지 결정하기 전에 다음과 같은 진단 질문 하나를 스스로에게 던져 보세요.

"문제가 결과물에 있나요, 아니면 최초 프롬프트에 있나요?"

• 결과물에 문제가 있음 → 후속 요청으로 수정합니다
• 최초 프롬프트에 문제가 있음 → 프롬프트를 다시 작성하여 새로 시작합니다

이 질문은 증상만 다루지 않고 근본 원인을 찾게 합니다. 대부분의 매몰 비용 상황은 최초 프롬프트에 결함이 있는데도 사용자가 결과물을 계속 수정하려고 하는 경우입니다.

새로 시작하기로 했다면 단순히 표현만 바꾸지 말고 프롬프트를 다시 설계해야 합니다. 실패한 대화에서 얻은 정보를 활용하세요.

• 어떤 제약 조건을 포함하는 것을 잊었나요?
• 어떤 가정이 잘못되었나요?
• 어떤 부분이 모호해서 모델이 잘못된 방향으로 갔나요?
• 어떤 예시나 형식 명세가 오해를 막을 수 있었나요?

실패한 대화는 최초 프롬프트에 무엇이 빠져 있었는지 알려 주는 귀중한 피드백입니다. 새로운 프롬프트는 이러한 부족한 부분을 직접 해결해야 합니다.

대화를 닫기 전에 실제로 유용했던 부분을 추려 내세요.

• 보존하고 싶은 부분, 표현 또는 아이디어를 복사합니다
• 좋은 결과를 만들어 낸 제약 조건이나 지침을 기록합니다
• 모델이 생성했고 마음에 들었던 예시나 비유를 저장합니다

새로 시작한다고 해서 모든 내용을 버려야 하는 것은 아닙니다. 원하는 문체의 참고 자료나 예시로 유용한 부분을 새로운 프롬프트에 붙여 넣을 수 있습니다.

Python 애플리케이션에서는 대화 품질 신호를 추적하여 언제 자동으로 reset할지 결정할 수 있습니다.

다음과 같은 머릿속 의사결정 트리를 사용하세요.

1. 2회 이상 수정했는데도 모델이 같은 오류를 반복하나요? → 새로 시작합니다
2. 최초의 문제 설정이나 전제가 잘못되었나요? → 새로 시작합니다
3. 문맥 창 때문에 품질이 저하되고 있나요? → 요약과 함께 새로 시작합니다
4. 내용은 대체로 맞지만 형식 변경이나 사소한 확장이 필요한가요? → 수정합니다
5. 전반적으로 좋은 응답에서 한 부분만 약한가요? → 해당 부분을 수정합니다

일반적으로 전환 기준은 수정 시도 세 번 정도입니다. 구체적인 후속 프롬프트를 세 번 보냈는데도 문제가 해결되지 않았다면 문제는 최초 프롬프트에 있습니다.

숙련된 소프트웨어 엔지니어를 대상으로 데이터베이스 색인을 설명하는 기술 블로그 글을 작성해 달라고 모델에 요청했습니다. 하지만 모델은 데이터베이스가 무엇인지 처음부터 설명하는 초보자용 글을 생성했습니다. 기술 분야 독자라는 점을 두 번 수정해서 명시했지만, 두 번 모두 초보자용 내용이 조금 줄었을 뿐 숙련자 수준의 깊이에는 이르지 못했습니다.

가장 좋은 조치는 무엇인가요?

핵심 규칙은 다음과 같습니다. 문제가 출력에 있으면 다듬고, 문제가 원래 프롬프트에 있으면 새로 시작합니다.

새로 시작해야 한다는 가장 강력한 신호 세 가지는 여러 번 수정한 뒤에도 같은 오류가 반복되는 경우, 원래의 문제 설정이 잘못된 경우, 초기 전제가 잘못된 경우입니다. 긴 대화에서 품질이 저하되는 것은 대개 컨텍스트 창 문제이며, 이 경우에도 요약과 함께 새로 시작해야 합니다.

실패한 대화도 결코 헛되지 않습니다. 이를 피드백으로 활용해 더 나은 초기 프롬프트를 작성하십시오.