답이 아쉬울 때 — 원인을 짚고 흐름을 다듬는 법

7.1 왜 이런 답이 나왔을까 — 증상부터 구분하기

결과가 아쉬울 때 가장 흔한 실수는 같은 요청을 그대로 다시 보내는 것입니다. 먼저 증상을 구분해야 처방이 나옵니다. 사실이 아닌 내용을 그럴듯하게 지어내는 환각(hallucination)인지, 지시가 모호해 방향이 어긋난 것인지, 근거 자료를 주지 않아 일반론만 받은 것인지에 따라 고치는 방법이 다릅니다. 지시가 문제라면 요청을 더 구체적으로 다시 쓰고, 자료가 문제라면 근거 문서를 첨부합니다. 대화가 길어져 앞의 내용이 밀려났다면 컨텍스트 윈도우(context window)의 한계를 의심하고 새 대화를 여는 것이 답일 수 있습니다. 수정은 한 번에 하나씩 — 그래야 어떤 변경이 효과를 냈는지 확인할 수 있습니다.

7.2 첫 답은 초안 — 피드백으로 다듬기

Claude의 첫 답은 완성본이 아니라 초안으로 보는 편이 정확합니다. 다듬을 때는 "다시 써 줘" 같은 막연한 요청 대신 무엇이 어떻게 아쉬운지 구체적으로 말합니다. "두 번째 문단이 너무 기술적이니 경영진이 읽을 수준으로 풀어 주세요", "표는 유지하고 요약만 세 줄로 줄여 주세요"처럼요. 원하는 결과물의 견본이 있다면 함께 붙여 주는 것도 효과적입니다. 다만 수정을 여러 번 거치며 실패한 시도가 대화에 쌓이면, 그 흔적이 다음 답까지 끌어내리기도 합니다. 이럴 때는 지금까지 확인한 요구사항을 정리해 새 대화에서 처음부터 요청하는 쪽이 오히려 빠릅니다.

7.3 한 번 통한 방법을 팀의 자산으로 — 업무 흐름 최적화

문제를 고치는 데서 멈추지 않고, 통했던 방법을 재사용할 수 있게 정리하는 것이 최적화의 핵심입니다. 매번 같은 배경 설명을 반복하고 있다면 그 내용을 프로젝트(Projects) 지침이나 시스템 프롬프트(system prompt)로 옮겨 두고, 잘 다듬어진 요청문은 팀이 공유하는 템플릿으로 만듭니다. 작업 성격에 맞춰 모델을 고르는 것도 최적화입니다 — 단순 분류나 요약처럼 빠르게 많이 처리할 일과, 심층 분석처럼 품질이 우선인 일은 어울리는 모델이 다릅니다. 마지막으로 걸린 시간과 결과 품질을 전후로 비교해 보면, 어떤 개선이 실제로 효과가 있었는지 감이 아니라 근거로 판단할 수 있습니다.

! 흔한 함정

• 아쉬운 답이 나왔을 때 원인 구분 없이 같은 요청을 그대로 재전송하기 — 같은 입력은 대체로 비슷한 결과로 이어집니다.
• "더 잘 써 줘" 같은 막연한 피드백 — 무엇이 왜 아쉬운지 말하지 않으면 다듬을 방향이 전달되지 않습니다.
• 실패한 시도가 쌓인 긴 대화를 계속 붙들기 — 요구사항을 정리해 새 대화로 옮기는 편이 빠를 때가 많습니다.
• 한 번 성공한 요청문을 점검 없이 모든 업무에 그대로 적용하기 — 작업 유형이 바뀌면 다시 검증해야 합니다.