원하는 답을 끌어내는 지시의 기술

1.1 지시문의 네 기둥 — 역할·맥락·요청·형식

좋은 지시문은 길이가 아니라 구조가 결정합니다. 어떤 관점에서 답할지(역할), 지금 상황이 무엇인지(맥락), 정확히 무엇을 해 달라는 것인지(요청), 결과를 어떤 모양으로 받고 싶은지(형식)를 나누어 적으면 같은 내용이라도 결과 품질이 크게 달라집니다. Claude는 우리 회사 사정을 모르는 신입 동료와 같아서, 사람에게라면 생략할 배경도 적어 줘야 합니다. 특히 형식 지정은 비개발자가 가장 빨리 효과를 보는 부분입니다. "표로", "다섯 줄 요약으로", "임원 보고용 한 장으로"처럼 결과물의 모양을 먼저 정해 두면 다시 고치는 횟수가 눈에 띄게 줄어듭니다.

1.2 큰 요청은 단계로 나눕니다

보고서 한 편을 통째로 요청하면 결과가 어긋났을 때 어디부터 고쳐야 할지 찾기 어렵습니다. 복잡한 일은 사람에게 맡길 때처럼 단계로 나눕니다. 먼저 자료 정리, 다음 목차 잡기, 그다음 부분별 초안, 마지막으로 전체 다듬기 — 단계마다 결과를 확인하고 넘어가면 방향이 틀어져도 일찍 바로잡을 수 있습니다. 긴 자료를 다룰 때는 컨텍스트 윈도우(context window), 즉 Claude가 한 번의 대화에서 기억할 수 있는 분량에 한계가 있다는 점도 나누기의 이유가 됩니다. 핵심 자료부터 순서대로 주고, 단계별 중간 결과를 요약해 다음 단계의 입력으로 삼는 방식이 안전합니다.

1.3 첫 답은 초안입니다 — 고쳐서 받아냅니다

첫 답이 기대에 못 미칠 때 문제는 대개 모델이 아니라 지시문 쪽에 있습니다. 새 대화로 도망가는 대신, 무엇이 아쉬운지 구체적으로 알려 주고 같은 대화에서 다듬는 편이 빠릅니다. "더 짧게"보다 "핵심 수치 중심으로 절반 분량으로", "어색해요"보다 "고객에게 보내는 사과문이니 격식을 더 갖춰 주세요"가 효과적입니다. 잘 나온 결과를 만든 지시문은 따로 저장해 두고 비슷한 업무에 다시 씁니다. 팀 차원에서는 검증된 지시문을 프로젝트의 지침, 곧 시스템 프롬프트(system prompt) 역할을 하는 상시 지침으로 올려 두면 매번 처음부터 다듬는 수고가 사라집니다.

1.4 일의 종류가 다르면 묻는 법도 다릅니다

분석·조사·초안 작성·아이디어 발상은 각각 요구하는 지시가 다릅니다. 분석에는 판단 기준과 데이터를 먼저 줍니다 — 기준 없는 분석 요청은 기준 없는 결론을 낳습니다. 조사에는 출처를 함께 밝히고 확실하지 않은 부분은 모른다고 말하도록 요청합니다. 그럴듯하지만 사실이 아닌 답, 곧 환각(hallucination)을 줄이는 기본 습관입니다. 초안 작성에는 독자·목적·분량을 정해 줍니다. 아이디어 발상은 반대로 조건을 느슨하게 풉니다 — "일단 스무 개, 품질은 나중에"처럼 양을 먼저 요청한 뒤 추리는 쪽이 뻔하지 않은 후보를 얻는 길입니다. 시험에서도 작업 유형별로 알맞은 지시 전략을 고르는 문항이 자주 나옵니다.

! 흔한 함정

• 배경 설명 없이 결론만 요청하기 — Claude는 우리 회사의 사정을 모르므로, 동료에게라면 생략할 맥락도 지시문에 적어야 합니다.
• 첫 답이 어긋나면 곧바로 새 대화를 여는 습관 — 무엇이 아쉬운지 알려 주고 같은 대화에서 다듬는 쪽이 대개 더 빠르고, 시험도 이 판단을 묻습니다.
• 모든 업무에 같은 지시 틀을 재사용하기 — 분석용으로 다듬은 틀로 아이디어 발상을 시키면 좁고 뻔한 답만 돌아옵니다.
• "알아서 잘 정리해 주세요" 같은 기준 없는 지시 — 기준을 주지 않으면 받은 결과를 평가할 기준도 없습니다.