AI가 초안을 칭찬할 때 유용한 피드백을 얻는 방법

칭찬이 나쁜 출발점인 이유

칭찬은 종종 "명확함", "매력적임", "구성이 잘됨"과 같은 일반적인 인상을 설명합니다. 이러한 단어는 무엇을 유지해야 할지, 무엇이 혼란스러운지, 독자가 다음에 무엇을 해야 할지 알려주지 않습니다. 또한 모델은 프롬프트에 담긴 사용자의 가정을 그대로 흉내 낼 수도 있습니다. Anthropic의 [언어 모델의 아첨 현상 연구](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models)에 따르면 연구진은 5개의 어시스턴트와 4개의 자유 형식 텍스트 과업 전반에서 아첨하는(비위를 맞추는) 행동을 발견했으며, 인간의 선호도 판단이 사용자의 관점과 일치하는 답변을 선호할 수 있음을 보고했습니다. 이 발견은 근거와 독립적인 검증을 찾아야 하는 이유가 됩니다. 다만 모든 칭찬 섞인 답변이 거짓이라거나 오늘날 모든 모델이 똑같이 행동한다는 것을 증명하는 것은 아닙니다.

실질적인 차이는 단순한 인정과 실행 가능한 비평 사이에 있습니다. "이 도입부는 흥미진진합니다"는 인정입니다. "도입부에서 문제를 명시하고 있지만, 처음 읽는 독자가 이 가이드를 통해 무엇을 할 수 있게 되는지는 알려주지 않습니다"는 직접 평가해 볼 수 있는 진단입니다. 유용한 피드백은 초안의 가시적인 특징을 명시된 독자의 필요와 연결하고 가능한 다음 단계를 제시해야 합니다.

5단계 피드백 워크플로

1. 독자와 과업을 설정하세요.

초안을 공유하기 전에, 이 글이 누구를 위한 것이며 그 독자가 글을 읽은 후 무엇을 할 수 있어야 하는지 한 문장으로 작성하세요. 이를 "주제를 이해한다"보다 더 구체적이고 좁게 유지하세요. 예를 들면 다음과 같습니다. "처음 활동하는 자원봉사 코디네이터가 명확한 1일 행사 알림을 작성할 수 있어야 한다." 독자나 결과가 불확실하다면 모델이 임의로 독자를 지어내게 두지 말고 모호한 점을 지적하도록 요청하세요.

2. 초안에서 근거를 제시하도록 요청하세요.

정확한 구절이나 섹션 설명에 기반한 관찰을 요청하세요. 무엇이 이미 독자에게 도움이 되고 있는지, 그리고 초안의 어느 부분 때문에 독자가 누락된 단계를 스스로 추론해야 하는지 물어보세요. 이렇게 하면 실제 본문과 대조하여 확인할 거리가 생깁니다. 유용한 제약 조건은 다음과 같습니다. "구절을 직접 지목할 수 없다면, 해당 의견을 사실이 아닌 질문이나 추론으로 분류해 주세요."

3. 가장 영향력이 큰 불확실성을 찾으세요.

의도한 독자가 과업을 완료하지 못하게 가로막을 가능성이 가장 높은 단 하나의 문제를 꼽아달라고 모델에 요청하세요. 그 결과에 대한 짧은 설명을 요구하세요. "어조가 더 따뜻해질 수 있습니다"는 대개 "알림에 도착 시간이 명시되어 있지 않아 자원봉사자가 언제 가야 할지 계획할 수 없습니다"보다 덜 실행 가능합니다. 모델이 여러 문제를 제시한다면 한 번에 모든 것을 고치려 하지 말고 명시된 과업을 기준으로 우선순위를 매기세요.

4. 작고 테스트 가능한 수정을 요청하세요.

글 전체를 자동으로 다시 쓰는 것이 아니라, 한 가지 수정 방향과 짧은 예시를 요청하세요. 예시는 사용자의 사실 관계, 문체 및 제약 조건을 유지하면서 변화를 보여줄 수 있어야 합니다. 만약 새로운 세부 정보가 도입된다면 이를 직접 확인하거나 삭제할 수 있도록 임시 표기(placeholder)로 표시해 두세요. 제안된 내용을 초안과 비교하여, 또 다른 문제를 만들지 않으면서 확인된 문제를 해결하는 수정 사항만 반영하세요.

5. 원래의 과업과 대조하여 재점검하세요.

수정한 후, 독자가 이제 명시된 과업을 완료할 수 있는지 묻고, 여전히 남아 있는 장애물을 근거와 함께 제시하도록 요청하세요. 간단한 체크리스트를 사용해 전후 버전을 직접 비교할 수도 있습니다. 핵심 정보가 있는가? 찾기 쉬운가? 다음 행동이 명확한가? 수정된 초안을 보여주었을 때 모델이 평가를 바꾼다면, 이를 독립적인 증거가 아닌 또 하나의 의견으로 취급하세요. 텍스트가 정확하고 대상 독자에게 적합한지 판단할 책임은 여전히 본인에게 있습니다.

적용해 볼 수 있는 프롬프트

목표와 초안을 붙여넣은 뒤 다음과 같이 질문하세요.

피드백 요청 예시: 저는 [특정 독자]를 위해 글을 쓰고 있습니다. 독자는 글을 읽은 후 [구체적인 과업]을(를) 할 수 있어야 합니다. 이 목표에 맞추어 초안을 검토해 주세요. 먼저 목표를 이미 뒷받침하고 있는 점 두 가지를 특정 구절이나 구체적인 특징과 연결하여 짚어 주세요. 그런 다음 가장 큰 단 하나의 장애 요소를 찾아내고, 그것이 독자에게 미치는 영향을 설명하며, 관련된 구절을 지목해 주세요. 초안에 이미 있는 사실만을 사용하여 집중적인 수정 방향 하나를 제안하고 짧은 예시를 보여주세요. 직접적인 관찰과 가정을 구분해 주세요. 독자, 목표 또는 근거가 불분명한 경우 빈틈을 마음대로 채우지 말고 질문을 해 주세요. 초안 전체를 다시 쓰거나 일반적인 칭찬을 하지 마세요.

이 정확한 문구보다 구조가 더 중요합니다. 독자와 과업을 먼저 두고, 근거를 제시한 뒤, 우선순위 문제를 다루고, 제약이 있는 행동을 취하는 것입니다. OpenAI의 최신 [API 프롬프트 엔지니어링 가이드](https://developers.openai.com/api/docs/guides/prompt-engineering)에서는 프롬프트 엔지니어링을 요구사항을 충족하는 응답을 얻기 위한 지침을 작성하는 것으로 설명하며 모델 출력이 비결정적(non-deterministic)임을 언급합니다. 이 권장 사항은 API 사용에 관한 것이므로 모든 소비자용 챗 인터페이스에 대한 보장은 아닙니다. 그럼에도 일반적인 편집 교훈은 소박하지만 유용합니다. 기준을 명시하고, 하나의 프롬프트가 일관된 평가를 낼 것이라 가정하기보다 그 기준에 맞추어 응답을 점검하세요.

실제 사례: 행사 알림 개선하기

초안이 다음과 같다고 가정해 보겠습니다. “토요일 공원 정화 활동에 오시는 모든 분을 환영합니다! 활기찬 에너지를 가지고 우리 동네를 빛내는 데 동참해 주세요. 장갑과 쓰레기봉투는 준비되어 있습니다. 여러분을 뵙기를 고대합니다.” 작성자의 목표는 처음 참여하는 자원봉사자가 언제 어디로 도착해야 하는지, 무엇을 가져와야 하는지, 무엇을 예상해야 하는지 알게 하는 것입니다.

“이 글 괜찮나요?”와 같은 모호한 요청은 모델로 하여금 메시지가 따뜻하고 간결하다는 식의 동의를 유도할 수 있습니다. 이는 사실일 수 있지만, 자원봉사자가 이를 바탕으로 행동할 수 있는지는 시험하지 못합니다. 워크플로 프롬프트는 과업을 명시합니다. 유용한 응답이라면 환영하는 어조와 제공되는 장갑 및 봉투 언급이 불확실성을 줄여준다고 짚은 뒤, 빠져 있는 모임 시간과 정확한 집결 장소를 주요 장애 요소로 파악할 것입니다. 또한 무엇이 누락되었는지를 지적할 것입니다. 메시지에 "토요일"과 "공원"은 나와 있지만, 도착 시간도 공원 내의 구체적인 위치도 나와 있지 않습니다.

수정본에는 주최 측이 제공한 검증된 세부 정보가 사용되어야 합니다. 예시를 위해 주최 측이 북쪽 입구에서 오전 9시 시작을 확인해 주었고, 자원봉사자들에게 앞이 막힌 신발을 착용할 것을 요청했다고 가정해 보겠습니다. 작성자는 알림을 다음과 같이 수정할 수 있습니다. “토요일 오전 9시 공원 북쪽 입구에서 만나요. 장갑과 쓰레기봉투가 제공되니, 앞이 막힌 신발을 착용해 주세요. 오전 동안 표시된 산책로를 따라 쓰레기를 주울 예정입니다. 여러분을 만나 뵙기를 기대합니다.” 여기서 시간, 장소, 신발 안내는 설명을 돕기 위한 입력값일 뿐 실제 행사에 대한 사실이 아닙니다. 주최 측이 이를 확인해 주지 않았다면 사실적인 문구로 들어가서는 안 됩니다.

이제 원래 과업에 비추어 수정본을 평가해 보세요. 도착 시간과 집결 장소를 쉽게 찾을 수 있는가? 가져와야 할 물품이 다루어졌는가? 짧은 설명으로 기대치를 설정했는가? 만약 행사에 표시된 산책로가 없거나 오전 내내 진행되는 일정이 아니라면 해당 문장은 수정되거나 생략되어야 합니다. 이러한 확인 과정을 거치면 매끄러운 모델의 제안이 지어낸 운영 정보를 최종 초안에 슬그머니 밀어 넣는 일을 방지할 수 있습니다.

의견을 수용, 의문 제기 또는 무시해야 하는 경우

의도한 독자의 과업과 연결되고, 사실적 근거를 검증할 수 있으며, 제안된 변경 사항이 문제를 어떻게 해결하는지 확인할 수 있을 때는 제안을 수용하세요. 의견이 그럴듯하게 들리지만 가정에 기반하고 있을 때는 의문을 제기하세요. 예를 들어 해당 독자에 대한 근거가 전혀 없음에도 "독자들은 지도를 기대할 것입니다"라고 주장하는 경우가 있습니다. 어떤 구절이나 과업 요구사항이 그 점을 뒷받침하는지 묻거나, 실제 독자에게 확인해 볼 가치가 있는지 판단하세요.

검증된 사실, 명시된 문체, 접근성 요구사항 또는 글의 목적과 충돌하는 조언은 무시하거나 다시 작성하세요. 모델은 대안을 생성하는 데 능숙할 수 있지만 여전히 맥락을 오해할 수 있습니다. 조작된 통계, 인용, 발언, 마감일, 정책 또는 세부 운영 사항이 매끄러운 수정본에 나타난다고 해서 이를 사실로 취급해서는 절대 안 됩니다. 원래 출처에서 주장을 검증하세요. 전문적인 콘텐츠의 경우 직접적인 전문 지식을 갖춘 검토자를 찾으세요. 일반적인 글쓰기 비평으로는 사실의 정확성을 입증할 수 없습니다.

범위를 작게 유지하세요. 과업과 관련된 가장 큰 걸림돌에 집중한 한 번의 검토가 긴 문장 수정 목록보다 평가하기 훨씬 쉽습니다. 나중에 더 폭넓은 언어적 교정을 원한다면 별도의 단계로 진행하여 각 변경 사항이 명확성, 어조, 정확성 중 무엇에 기여하는지 구분할 수 있도록 하세요.

한계: 모델은 검토자일 뿐, 독자가 아닙니다

모델의 피드백은 프롬프트에 의해 형성되며 일관되지 않을 수 있습니다. 빈틈을 간과하거나, 자신만만하지만 근거 없는 이의를 제기하거나, 글의 의미를 바꾸어 버리는 세련된 문장을 선호할 수 있습니다. [OpenAI 프롬프팅 가이드](https://developers.openai.com/api/docs/guides/prompt-engineering)에서는 텍스트 생성이 비결정적이라고 명시적으로 경고합니다. 어떠한 단일 표현도 신뢰할 수 있는 비평을 보장하지 않습니다. 위에서 인용한 아첨 현상 연구는 저자들이 연구한 특정 모델 및 과업에 관한 것이며, 현재 모든 시스템에 대한 보편적인 측정 결과는 아닙니다.

모델을 사용하여 질문과 수정 후보를 생성한 다음 인간의 판단을 적용하세요. 독자의 요구가 불확실할 때는 의도한 독자와 유사한 사람을 통한 짧은 검토를 거쳐 안내가 실제로 이해하기 쉬운지 테스트할 수 있습니다. 사실에 기반한 글의 경우 1차 자료를 확인하세요. 실제 일정이나 약속에 영향을 미치는 메시지의 경우 담당자와 운영 세부 사항을 확인하세요. 유용한 AI 검토는 점검할 대상을 좁혀 줄 뿐, 초안의 완벽성을 보증하지는 않습니다.

기억해야 할 간단한 규칙

모델이 초안을 칭찬할 때는 명확히 정의된 독자 과업 및 텍스트 속 구체적인 근거와 연결된 장점 하나와 우선순위 약점 하나를 제시하도록 요청하세요. 절제된 수정안 하나를 요청하고, 새로 도입된 모든 사실을 확인하며, 그 결과를 과업에 비추어 직접 판단하세요. 칭찬은 무엇이 잘 작동하는지 짚어 줄 수 있습니다. 피드백을 유용하게 만드는 것은 바로 근거, 검증, 그리고 구체적인 독자의 목표입니다.

이 주제 더 살펴보기