내가 매일 사용하는 10가지 프롬프트 패턴

지난 화요일, 나는 데이터베이스 스키마 (database schema)에 대해 Claude와 40분 동안 논쟁을 벌인 후에야 내가 이미 무엇을 시도했었는지 모델에게 말하지 않았다는 사실을 깨달았습니다. 나는 문제를 설명했고, 모델은 내가 이미 제외했던 똑같은 세 가지 제안을 내놓았습니다. 내가 반박하자, 모델은 사과하며 똑같은 세 가지 제안의 변형들을 다시 주었습니다. 실제 내가 처한 상황에서 시작하는 대신 제로(zero) 상태에서 시작했기 때문에 전체 세션은 쓰레기 같았습니다. 나는 탭을 닫고 첫 번째 메시지를 다시 작성했고, 6분 만에 작동하는 해결책을 얻었습니다. 대부분의 사람들이 프롬프트를 작성하는 방식과, 모델을 실제 맥락 (context)이 필요한 협업자 (collaborator)로 대할 때 실제로 작동하는 방식 사이의 그 격차 — 이것이 바로 이 포스트의 주제입니다.

패턴 1 & 2: 이미 시도한 내용을 먼저 제시하고, 자신을 묶고 있는 제약 사항을 명시하라

이 두 가지 패턴은 거의 항상 함께 사용되므로, 별개의 것이라고 주장하지 않겠습니다.

시도했던 이력 없이 문제를 설명하면, 모델이 당신의 막다른 길을 다시 발견하도록 강요하는 셈이 됩니다. 모든 개발자는 이 좌절감을 알고 있습니다. 버그를 설명하면 월요일에 이미 시도했던 해결책을 받고, 그걸 시도했다고 설명하면 변형된 것을 받고, 그것 또한 시도했다고 설명하는 — 이는 재귀적인 낭비입니다. 해결책은 초기에 잔인할 정도로 솔직해지는 것입니다: "X가 필요합니다. 이미 A와 B를 시도했습니다. A는 [구체적인 이유] 때문에 실패했습니다. B는 [제약 사항] 때문에 고려 대상이 아닙니다. 둘 중 어느 것도 제안하지 마세요."

제약 사항 (constraint) 레이어가 나머지 절반입니다. 모델은 기본적으로 낙관주의자입니다. 모델은 세 개의 새로운 의존성 (dependencies)과 인증 레이어 (auth layer)의 리팩토링 (refactor)이 필요한, 구조적으로 깨끗하고 완벽하게 테스트 가능한 해결책을 제시할 것입니다. 당신이 이틀 안에 배포해야 하고, 의존성을 추가할 수 없으며, 코드가 2019년에 마지막으로 Python을 만졌던 사람도 읽을 수 있어야 한다고 말하지 않는 한 말이죠. 제약 사항은 정답에 대한 제한이 아니라, 정답 그 자체입니다. 제약 사항을 앞부분에 배치하지 않으면, 기술적으로는 옳지만 상황적으로는 쓸모없는 제안들을 거절하는 데 세션을 허비하게 될 것입니다.

패턴 3 & 4: 출력 우선, 추론 후순위 — 그리고 재작성 대신 차이점(Diff)만 요청하기

동전의 양면과 같습니다. 필요 없는 설명을 요구하는 것을 멈추고, 작은 변경이 필요할 때 전체 재작성(Rewrite)을 요구하는 것을 멈추십시오.

"출력 우선, 추론 후순위 (Output first, reasoning after)"는 프롬프트가 다음과 같이 끝나야 함을 의미합니다: "코드를 먼저 제공하고, 그 다음 명확하지 않은 부분만 설명해 주세요." 모델의 기본 동작은 설명하고, 주의 사항을 언급한 뒤, 결과물을 생성하는 것입니다. 이는 학습할 때는 괜찮습니다. 하지만 무언가를 구축(Building)할 때는, 한 단락의 정당화 글을 읽기 전에 결과물(Artifact)을 즉시 확인하고 평가하고 싶을 것입니다. 설명은 언제든 나중에 요청할 수 있습니다. 순서를 바꾸는 것은 비용이 들지 않으며, 요청하지 않은 문맥을 읽어야 하는 수고를 덜어줍니다.

"차이점만 요청 (Diff only)"는 더 적게 사용되는 패턴입니다. 만약 200줄짜리 함수가 있고 그중 한 분기(Branch)의 에러 핸들링(Error handling)을 바꾸고 싶다면, 함수 전체를 재작성해 달라고 하지 마세요. 이렇게 말하십시오: "변경되는 라인과 그 주변의 즉각적인 문맥만 보여주세요. 나머지는 다시 생성하지 마세요." 이는 두 가지 효과를 줍니다. 첫째, 모델이 건드리지 말아야 할 부분을 몰래 바꾸는 그럴싸해 보이는 전체 재작성을 생성하는 대신, 문제를 국소화(Localize)하도록 강제합니다. 둘째, 검토(Review)를 빠르게 만듭니다. 전체 재작성이 타겟팅된 차이점(Diff) 방식에 비해 미묘한 회귀(Regression)를 유발한 횟수는 비교조차 되지 않을 만큼 많습니다.

패턴 5 & 6: 적대적 루프 (Adversarial Loop) — 스틸맨(Steelman) 후 공격

이것은 제가 아키텍처 결정(Architecture decisions)을 내릴 때 가장 많이 사용하는 패턴이며, 적어도 수십 번의 잘못된 결정을 막아주었습니다.

1단계: 모델에게 현재 접근 방식에 대해 스틸맨(Steelman)을 해달라고 요청하십시오. "장단점이 무엇인가요?"라고 묻지 마세요. 그런 질문은 위원회가 작성한 듯한 균형 잡힌 목록만을 가져다줄 뿐입니다. 대신 당신이 이미 하고 있는 방식에 대해 _"가능한 가장 강력한 논거(Strongest possible argument)"_를 만들어 달라고 요청하십시오. 이렇게 하면 당신이 과소평가하고 있을지도 모르는 진정한 장점들을 모델이 표면화하도록 강제할 수 있습니다.

2단계: 모드를 전환합니다. "이제 당신은 이와 똑같은 패턴에 데인 적이 있는 회의적인 시니어 엔지니어(Skeptical senior engineer)입니다. 무엇이 망가질까요? 2차 실패(Second-order failures)는 무엇인가요? 새벽 2시에 울리는 온콜(On-call) 알람은 어떤 모습일까요?"

이 두 가지의 결합에서 진정한 가치가 발생합니다. 먼저 '스틸매닝 (Steelmanning)'을 한다는 것은 모델이 기본값으로 "몇 가지 우려 사항이 있습니다"라고 답변한다고 해서 좋은 아이디어를 그냥 버리지 않는 것을 의미합니다. 그다음 '공격 (Attacking)'을 한다는 것은 첫 번째 시도에서 그럴듯하게 들렸다고 해서 취약한 계획에 확신을 갖지 않는 것을 의미합니다. 저는 되돌리기 어려운 모든 기술적 결정에 이 방식을 적용합니다.

빠른 변형 버전은 다음과 같습니다: "이 결정이 6개월 뒤에 후회할 실수가 되려면, 어떤 상황이 전제되어야 할까요?" 이 단 하나의 질문은 제가 작성했던 그 어떤 프롬프트보다 더 빠르게 수많은 나쁜 아이디어들을 제거해 왔습니다.

패턴 7 & 8: 네거티브 스페이스 프롬프팅 (Negative Space Prompting) 및 컨텍스트 리셋 (Context Resets)

네거티브 스페이스 (Negative space): 원하는 것을 설명하는 대신, 원하지 않는 것을 구체적으로 설명하십시오. "기술 블로그 포스트를 작성해 주세요. 불렛 포인트 (bullet points)를 사용하지 마세요. 섹션을 수사적 질문으로 시작하지 마세요. 'leverage', 'robust', 또는 'seamless'라는 단어를 사용하지 마세요. 섹션 끝에 해당 섹션을 요약하지 마세요."

이것은 마이크로매니징 (micromanagement)처럼 들릴 수 있습니다. 실제로 그렇습니다. 하지만 이는 해당 유형의 작업에서 이 모델이 실제로 보여준 특정 실패 모드 (failure modes)에 기반한 타겟형 마이크로매니징입니다. 모델은 강력한 기본값 (defaults)을 가지고 있습니다. 네거티브 스페이스 프롬프팅은 600단어짜리 시스템 프롬프트 (system prompt)를 작성하지 않고도 이를 정교하게 무력화하는 방법입니다.

컨텍스트 리셋 (Context resets)은 이것의 방어적인 버전입니다. 긴 대화는 표류합니다. 모델은 당신의 이전 메시지, 수정 사항, 무심코 던진 예시들로부터 프레이밍 (framing)을 흡수합니다. 메시지 15번째에 도달하면, 당신은 더 이상 신선한 추론 엔진과 대화하고 있는 것이 아닙니다. 지난 한 시간 동안 당신이 가졌던 미완성된 생각들을 모두 흡수한 엔진과 대화하고 있는 것입니다. 답변이 모호해지거나, 순환 논리에 빠지거나, 이상할 정도로 저자세로 변하는 것을 감지하면, 저는 새 채팅을 엽니다. 그리고 해결된 사실과 현재의 질문만을 명시한 뒤 깨끗하게 다시 시작합니다. 컨텍스트 (Context)가 항상 자산인 것은 아닙니다.

패턴 9 & 10: 체인 오브 드래프트 (Chain-of-Draft) 및 러버 덕 인버전 (Rubber Duck Inversion)

Chain-of-draft (초안 연쇄): 거친 초안(rough) → 구조화(structured) → 최종안(final). 첫 번째 시도부터 완성된 결과물(artifact)을 요구하지 마세요. 거친 뼈대(skeleton)를 먼저 요청하세요. 그것을 검토한 다음, 다음과 같이 말하세요: "다른 부분은 모두 자리 표시자(placeholder)로 남겨두고, 섹션 2만 내용을 채워주세요." 그 다음 최종 작업을 진행합니다. 복잡한 작업에서 한 번에 완벽하고 다듬어진 결과물을 얻으려고 노력하는 것은, 마치 설계도를 구상하는 동안 건설업자에게 집을 지어달라고 요청하는 것과 같습니다. 집은 지어지겠지만, 당신이 원했던 집은 아닐 것입니다.

러버 덕 인버전 (Rubber Duck Inversion)은 10번째 패턴이며 아마도 가장 기이한 패턴일 것입니다. 제가 기술적인 문제 때문이 아니라, 실제로 무엇을 하려고 하는지 갈피를 잡지 못해 진정으로 막혔을 때, 저는 상황을 설명하고 다음과 같이 끝맺습니다: "해결책을 주지 마세요. 제가 실제로 무엇을 필요로 하는지 가장 명확하게 해줄 질문 세 가지만 저에게 던져주세요." 저는 소크라테스식 문답법 (Socratic method)을 외주 주는 것입니다. 모델은 질문 뒤에 숨겨진 질문을 식별하는 데 능숙합니다. 그 세 가지 질문에 대해 모델에게 (또는 그냥 스스로에게) 답변하는 것은 보통 어떤 직접적인 답변을 듣는 것보다 저를 더 빠르게 막힌 상태에서 벗어나게 해줍니다.

빠른 참조 체크리스트 (Quick-Reference Checklist)

프롬프트를 보내기 전에 다음 사항을 검토하세요:

• 내가 이미 시도했던 것과 그것이 왜 실패했는지 명시했는가?
• 실제로 구속력을 갖는 제약 조건(constraints)을 명시했는가?
• 설명보다 결과물(output)을 먼저 요청했는가?
• 이것이 내가 '재작성(rewrite)' 작업으로 잘못 프레임화하고 있는 '차이점(diff)' 작업인가?
• 공격하기 전에 이것을 철강론(steelman, 상대의 논리를 가장 강력한 형태로 재구성하는 것) 해야 하는가?
• 내가 원하는 것을 설명하고 있는가, 아니면 원하지 않는 것을 설명하고 있는가?
• 이 컨텍스트 윈도우(context window)가 신뢰할 수 있을 만큼 신선한가, 아니면 리셋이 필요한가?
• 내가 최종 결과물(artifact)을 요청하고 있는가, 아니면 내가 조종할 수 있는 초안(draft)을 요청하고 있는가?
• 내가 무엇을 원하는지 알고 있는가, 아니면 명확하게 하는 질문을 먼저 요청해야 하는가?

열 가지가 아니라 아홉 가지입니다. 열 번째는 상황에 따라 다르기 때문입니다. 모델이 경로를 벗어나고 있다고 판단되면 당신의 직관을 믿고 대화를 끊으세요.

AI Handler가 이를 접근하는 방식

AI Handler를 구축하는 과정은 상당 부분 이러한 패턴들을 프롬프트 수준이 아닌 인프라스트럭처 (Infrastructure) 수준에서 인코딩하는 작업이었습니다. AI Handler에서 실행하는 모든 세션은 동일한 문제에 대해 이전 세션에서 이미 시도했던 내용에 대한 구조화된 컨텍스트 (Context)를 포함하고 있습니다. 따라서 패턴 1은 자동으로 적용됩니다. 프로젝트에 설정한 제약 사항 (Constraints)은 해당 프로젝트의 모든 프롬프트로 전파됩니다. 기본 출력 순서(아티팩트 우선, 요청 시 추론 수행)를 설정할 수 있습니다. 적대적 검토 (Adversarial review)를 매번 기억해서 수행해야 하는 작업이 아니라, 클릭 한 번으로 실행 가능한 모드로 저장할 수 있습니다.

이 도구의 이면에 있는 통찰은 평범한 AI 워크플로우 (Workflow)와 뛰어난 워크플로우 사이의 격차가 모델의 성능 때문인 경우는 거의 없다는 점입니다. 그것은 일관되게 적용된 프롬프트 규율 (Prompt discipline)의 차이입니다. 대부분의 사람들은 기억력과 습관에 의존하기 때문에 이를 일관성 없게 적용합니다. AI Handler는 이러한 규율을 기본값 (Default)으로 만듭니다.

AI Handler는 제가 구축하고 있는 통합 AI 워크플로우 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.