변경 예산 프롬프트: AI 지원 코딩에서 스코프 크리프 방지

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you requested.

아이디어

해결책을 요청하기 전에, 모델이 따를 수 있는 예산을 정의하세요:

• 수정할 파일 최대 개수 (예: 2)
• 변경할 라인 최대 개수 (예: 30)
• 새로운 의존성 금지
• 이름 변경 / 새 모듈 추가 금지
• 공개 API 안정성 유지

예산을 설정하면 어시스턴트가 “가장 깔끔한” 아키텍처 대신 가장 작은 실현 가능한 패치를 찾게 됩니다. 이는 AI‑지원 코딩에 대한 WIP 제한과 비슷합니다: 움직이는 부품이 적을수록 숨겨진 오류가 줄어듭니다.

복사/붙여넣기 템플릿

여기에 언제든지 사용할 수 있는 템플릿이 있습니다:

Task: 

Change budget:
- Touch at most  files
- Change at most  lines (excluding formatting)
- No renames
- No new dependencies
- Keep function signatures stable unless explicitly required

Output format:
1) Brief plan (2‑4 bullets)
2) Patch (diff)
3) Why this stays within budget
4) What to test (commands + key cases)

두 가지 중요한 세부 사항

1. 무엇이 제외되는지 정의 (예: “포맷팅 제외”)하여 불필요하게 예산을 낭비하지 않도록 합니다.
2. diff를 강제합니다. diff는 “예산 위반”을 명확히 드러냅니다.

예시 1: 리팩터 없이 버그 수정

Say you have a Node/Express handler that occasionally returns a 500 when the DB returns null.

Bad prompt

Fix this handler.

Better prompt (with budget)

Task: Prevent 500s when user is missing. Return 404 instead.

Change budget:
- Touch at most 1 file
- Change at most 12 lines
- No new dependencies
- No renames

Output: diff + tests

Code:

The budget pushes the model toward:

• A guard clause (if (!user) return res.status(404)…)
• A minimal test case

…and away from:

• “Let’s introduce a UserService class”
• Reworking middleware
• Reformatting the whole file

Example 2: Add a feature flag safely

Feature flags는 또 다른 범위‑확장 유인책입니다: 어시스턴트가 설정을 중앙화하거나, 라이브러리를 추가하거나, 전체 플래그 시스템을 구축하고 싶어합니다. 작은 토글만 필요하다면, 이를 제한하세요:

Task: Add an env flag NEW_CHECKOUT=1. If enabled, route /checkout to NewCheckoutPage.

Change budget:
- Touch at most 2 files
- Change at most 25 lines
- No new packages
- Do not change existing routes

Output: diff + rollback note

예상되는 결과는 하나의 조건 분기와 짧은 메모가 될 것입니다:

• 어떻게 활성화/비활성화하는지
• 변수가 없을 때 어떤 일이 일어나는지

바로 이것이 당신이 원하는 것입니다.

Example 3: “성능 향상” 전체를 다시 쓰지 않고

Performance prompts are dangerous because they invite broad rewrites. Instead of:

Make this faster.

Try:

Task: Reduce allocations in parseCsvRow().

Change budget:
- Touch at most 1 file
- Change at most 20 lines
- Keep behavior identical (including edge cases)

Also provide:
- A micro‑benchmark snippet
- A note on complexity tradeoffs

You’re telling the assistant: 로컬에서 최적화하고, 벤치마크로 검증하며, 전체 시스템을 재설계하지 말라.

왜 작동하는가 (기계적으로)

대부분의 어시스턴트는 가능한 다음 단계를 생성하면서 솔루션 공간을 “검색”합니다. 제약이 없을 경우, 전역적으로 “멋진” 코드를 향해 흐르게 됩니다:

• symmetry
• “clean architecture”
• new abstractions

예산이 들어가면 목표 함수가 바뀝니다. 모델은 minimal edits와 low‑risk diffs를 최적화하기 시작하는데, 이는 다음과 연관되는 경향이 있습니다:

• fewer regressions
• easier review
• easier rollback

실제로는 human ergonomics도 개선됩니다: 작은 diffs는 빠르게 스캔할 수 있기 때문입니다.

Make it even tighter: a two‑pass workflow

작업이 까다로울 때는 두 번에 걸쳐 진행합니다:

1. Plan pass (예산 제한): 3개의 핵심 항목으로 구성된 계획과 가정 목록을 요청합니다.
2. Patch pass (예산 제한): 차이점(diff)을 요청합니다.

이렇게 하면 버릴 코드를 작성하는 데 시간을 낭비하지 않고 오해를 초기에 잡아낼 수 있습니다.

Plan prompt

Before coding: propose a plan that stays within the change budget.
List assumptions and unknowns.
If the budget is unrealistic, say so and propose the smallest budget increase.

이 “예산 협상”은 매우 중요합니다. 경우에 따라 12줄만으로는 충분하지 않을 수 있으며, 미리 그 사실을 알아두는 것이 좋습니다.

Common failure modes (and fixes)

1. The assistant reformats everything.
   Add: “필요하지 않은 경우 형식을 변경하거나 변수 이름을 바꾸지 마세요.”

2. It blows the budget anyway.
   Add: “예산을 초과할 수 없으면 중단하고 예산 확대 허가를 요청하세요.”

3. It makes invisible behavior changes.
   Add: “동작은 동일하게 유지되어야 합니다; 작은 테스트 매트릭스를 포함하세요.”

4. It ‘fixes’ by deleting code paths.
   Add: “기능을 제거하지 마세요; 기존 브랜치를 보존하세요.”

다음 프롬프트를 위한 빠른 체크리스트

• 가장 작은 허용 가능한 결과는 무엇인가요?
• 절대 변경되지 않아야 할 것은?
• 오늘 검토할 수 있는 최대 diff는 얼마인가요?
• 어떤 결과물을 원하시나요 (diff, 테스트, 명령어)?

이 질문들에 답하면 가장 좋은 의미에서 지루한 패치를 받게 됩니다.

Change Budget Prompt는 어시스턴트의 창의성을 제한하는 것이 아니라, 엔지니어링 현실에 맞추는 것입니다: 작고 검토 가능한 변경 사항을 배포.