Assumption Inventory Prompt: 코드 작성 전에 숨겨진 요구사항을 포착하세요

It looks like only the source citation was provided. Could you please paste the article text you’d like translated? Once I have the content, I’ll translate it into Korean while preserving the formatting, markdown, and any code blocks.

가정 인벤토리 프롬프트

작업이 명확하다고 생각할 때의 그 느낌, 그런데 기술적으로는 맞지만 전혀 틀린 코드를 배포하게 되는 상황을 아시나요?

보통 코딩 문제는 아닙니다. 가정 문제죠.

LLM에게 무언가를 만들도록 요청하면, 누락된 요구사항을 그럴듯한 기본값으로 기꺼이 채워줍니다. 인간도 똑같이 하지만, 나중에 그걸 두고 논쟁까지 할 수 있다는 부가적인 장점이 있죠.

시간이 지나면서 저는 **“누락된 요구사항”**을 일급 버그로 다루기 시작했습니다. 제가 즐겨 사용하는 해결책은 Assumption Inventory Prompt 라는 간단한 패턴입니다.

작동 방식

어시스턴트를 강제하는 짧은 사전 단계:

1. 가정하고 있는 내용을 나열
2. 위험한 가정을 표시
3. 모호성을 없애기 위해 최소한의 질문을 제시
4. 질문에 답하고 싶지 않을 때 안전한 기본값을 제안

효과: 재작성 감소, “잠깐, 그게 내가 의도한 게 아니야” 라는 상황 감소, 그리고 좋은 코드를 얻는 훨씬 쉬운 경로.

한 문장으로 보는 패턴

솔루션을 만들기 전에 구조화된 가정 목록과 질문을 생성하세요.

이는 명백해 보이지만, 일상적인 프롬프팅에서는 놀라울 정도로 드뭅니다. 대부분의 프롬프트는 “do X”에서 바로 “here’s a solution”으로 넘어가며, X가 무엇을 의미하는지 실제로 정렬하는 부분을 건너뛰곤 합니다.

가정 인벤토리 프롬프트 (복사/붙여넣기)

요구 사항이 불분명할 수 있는 모든 작업에 대한 즉시 삽입 프리앰블로 사용하세요.

Before proposing a solution, do an Assumption Inventory.

1) Restate the goal in 1–2 sentences.  
2) List assumptions you’re making (at least 8). Group them by:  
   - Product/UX  
   - Data & edge cases  
   - Security/privacy  
   - Performance/scale  
   - Ops/maintenance  
3) For each assumption, label it as Low/Medium/High risk.  
4) Ask up to 5 clarifying questions that remove the highest‑risk ambiguity.  
5) If I don’t answer, propose safe defaults and continue.

Then proceed with the solution.

Tip: 질문을 제한하세요. 무제한 질문은 분석 마비를 초래합니다. 다섯 가지 힘 우선순위.

구체적인 예시: “Add audit logging to our API”

Prompt: “Add audit logging to our API. We’re using Node.js and Postgres.”

Assumption inventory 없이 진행하면 중요한 부분(감사 이벤트 정의, 보존 규칙, PII 처리, Correlation ID 등)을 놓친 일반적인 로깅 설정을 얻게 될 가능성이 높습니다.

패턴을 적용하면 숨겨진 결정들을 드러낼 수 있습니다.

좋은 Assumption Inventory의 예

재정의된 목표

• 민감한 API 작업에 대해 변조 방지 및 쿼리 가능한 감사 로그를 추가하고, 디버깅 및 규정 준수에 활용합니다.

Assumptions (예시)

명확히 해야 할 질문 (상위 5개)

1. 도메인에서 “감사 대상”으로 간주되는 엔드포인트/작업은 무엇인가요?
2. 사전/사후 스냅샷이 필요합니까, 아니면 “이벤트 발생” 기록만 충분합니까?
3. 보존 기간은 얼마이며, 불변 저장 보장이 필요한가요?
4. 어떤 PII를 마스킹해야 하며, 마스크 해제된 데이터를 볼 수 있는 권한은 누구에게 있나요?
5. 이미 요청 ID/트레이스 ID가 존재합니까, 아니면 새로 도입해야 합니까?

답변이 없을 경우 적용할 안전 기본값

• 권한이 높은 작업(관리자/청구/역할 변경)만 감사합니다.
• event_type, actor, target, timestamp, request_id를 저장합니다.
• JSON 필드에 대해서는 diff만 저장하고 전체 페이로드 로깅은 피합니다.
• 이메일/토큰을 마스킹하고, 읽기 권한은 관리자에게만 제한합니다.
• 180 일 보존하고, UPDATE/DELETE가 제한된 append‑only 테이블을 사용합니다.

이 시점에서 코드를 생성하는 것이 타당합니다.

왜 이것이 작동하는가 (그리고 어디에서 시간을 절약하는가)

1. “암묵적 컨텍스트”를 명시적 결정으로 전환한다
   LLM은 패턴 매처입니다. 프롬프트가 모호하면 모델은 일반적인 패턴에 따라 빈틈을 채웁니다. 인벤토리는 그 빈틈을 눈에 보이게 합니다.

2. 리뷰를 크게 쉽게 만든다
   가정 목록을 PR 설명이나 티켓에 붙여넣고 다음을 물어보세요:

   • “이 중 어떤 것이 잘못되었나요?”
   • “어떤 것을 다르게 결정하고 싶나요?”
     이는 완성된 구현을 두고 논쟁하는 것보다 훨씬 나은 리뷰 대화입니다.

3. 바쁠 때 안전망을 제공한다
   “안전 기본값” 섹션은 과소평가됩니다. 질문에 답할 시간이 없을 때는 다음과 같은 기본값을 원합니다:

   • 보수적 (데이터 손실/보안 문제 방지)
   • 가역적 (나중에 쉽게 변경 가능)
   • 관찰 가능 (기본값이 잘못됐는지 쉽게 감지 가능)

실제 사용을 위한 두 가지 규칙

규칙 1: 실수가 큰 비용을 초래할 때 사용한다

나는 가정 인벤토리를 다음과 관련된 모든 것에 사용한다:

• 인증/권한
• 금전
• 데이터 마이그레이션
• 사용자‑대면 흐름
• “컴플라이언스와 인접한” 모든 것(감사 로그, 보존, 내보내기)

작은 리팩터링의 경우에는 생략한다.

규칙 2: 인벤토리를 작업에 가깝게 유지한다

별도의 문서가 되어 흐트러지지 않게 하라. 인벤토리를 보관하기 좋은 위치는:

• 코드를 생성한 채팅 스레드의 최상단
• 티켓 설명에
• docs/decisions/ 노트에(팀에 해당 폴더가 있다면)

목표는 추적 가능성이다.

왜 이렇게 했나요? → “X를 가정했기 때문이며, 그 가정이 받아들여졌다.”

일상적인 프롬프트를 위한 가벼운 변형

짧은 버전을 원한다면 다음을 시도해 보세요:

Before you answer, list:
- 5 assumptions you’re making
- 3 things that could go wrong
- 3 questions you’d ask if you had time
Then proceed.

전체 화면 모드 진입
전체 화면 모드 종료

완전하게 자세하진 않지만 빠르고 핵심은 잡아줍니다.

마무리 생각

대부분의 프롬프트 조언은 모델로부터 더 나은 출력을 얻는 데 초점을 맞춥니다.
이 패턴은 출력이 존재하기 전에 better alignment을 얻는 것에 관한 것입니다.

이번 주에 시도해 본다면, 이전에 모호함 때문에 어려움을 겪었던 작업에 적용해 보세요. 당신이 스스로 인지하지 못했던 “high‑risk assumption”을 처음 발견했을 때, 그 가치는 스스로 보상될 것입니다.

원한다면, 곧 수행하려는 애매한 작업을 알려 주세요. 그러면 그 작업에 대한 Assumption Inventory가 어떻게 보이는지 보여드리겠습니다.