2025년 12월 11일·5분
안전한 소규모 반복을 위한 ‘변경 금지’ 프롬프트 패턴
핵심 UI 흐름, 비즈니스 규칙, 그리고 중요한 동작은 고정하고 한 가지 작은 업데이트만 적용해 다른 부분이 흐트러지지 않도록 하는 '변경 금지' 프롬프트 패턴을 배우세요.
핵심 UI 흐름, 비즈니스 규칙, 그리고 중요한 동작은 고정하고 한 가지 작은 업데이트만 적용해 다른 부분이 흐트러지지 않도록 하는 '변경 금지' 프롬프트 패턴을 배우세요.
“작은” 변경은 좀처럼 작게 끝나지 않습니다. 버튼 레이블 하나만 바꿔 달라고 했는데, 페이지 레이아웃이 밀리거나 폼 검증이 멈추거나 결제 단계의 동작이 달라질 수 있습니다. 앱은 연결된 시스템입니다. UI, 로직, 데이터, 통합이 서로 얽혀 있습니다.
흔한 원인 중 하나는 경계가 불분명한 경우입니다. 요청에 “가입을 더 간단하게 만들어 주세요”라고 적으면, 작업자(사람이든 AI든)가 “간단하게”가 무엇인지 추측해야 합니다. 추측은 필드 제거, 단계 변경, 카피 수정, 검증 재작성 같은 추가 수정을 낳습니다. 또 다른 원인은 숨은 의존성입니다. 작은 UI 변경이 다섯 군데 이상에서 재사용되는 컴포넌트를 건드릴 수 있습니다.
안전한 반복은 의도한 개선 하나는 얻으면서 다른 모든 것은 사실상 동일하게 유지되는 것을 의미합니다. 비기술팀 관점에서는 사용자 흐름이 동일하게 느껴지고, 지원 스크립트가 제품과 맞으며, 리포트가 이해 가능한 상태인 것을 뜻합니다. 기술팀 관점에서는 라우트, 데이터 형태, API 계약, 엣지 케이스 동작에 예기치 않은 변경이 없어야 합니다.
이를 가능하게 하려면 움직이면 안 되는 것을 고정해야 합니다. 실무에서는 보통 중요한 흐름(사용자가 거치는 정확한 단계), UI/UX 세부(레이아웃, 간격, 상호작용), 비즈니스 규칙(가격, 권한, 검증), 데이터 동작(언제 무엇이 저장되는지), 통합(분석 이벤트, 이메일, 결제, 외부 API)을 포함합니다.
이 “변경 금지” 프롬프트 패턴은 추측을 없애고 변경 범위를 제한해서 위험을 줄입니다. 완전한 보장은 아닙니다. 원래 동작이 잘 정의되어 있지 않거나 변경이 공유 컴포넌트를 건드리거나 결과를 검증하지 않으면 변화가 생길 수 있습니다. 목표는 놀라움이 줄고 승인 속도가 빨라지는 것입니다.
변경 금지 프롬프트 패턴은 하나의 특정 업데이트를 요청하면서 다른 모든 것을 명확히 고정하는 간단한 방법입니다. 원하는 한 가지 변경을 적고, 그 업데이트 후 동일하게 유지되어야 할 항목들의 짧은 고정 목록을 적습니다.
이것이 중요한 이유는 모델이 종종 도움이 되려다가 리팩터링, 이름 변경, 파일 재구성 또는 로직 정리를 시도하기 때문입니다. 출력이 여전히 동작하더라도 이런 추가 변경은 버그를 유발하거나 동작을 바꾸거나 리뷰를 어렵게 만들 수 있습니다.
다음 두 요청을 비교해 보세요:
“설정 페이지를 더 좋게 만들어 주세요.” 이 요청은 디자인 변경, 새 카피, 레이아웃 이동, 로직 수정 등을 초대합니다.
“레이아웃, 검증, 저장 동작을 변경하지 말고 ‘Phone’ 레이블을 ‘Mobile phone’으로만 바꿔 주세요.” 이는 좁고, 테스트 가능하며, 안전합니다.
튼튼한 고정 목록은 보통 세 영역을 다룹니다:
이 패턴을 Koder.ai 같은 채팅 기반 빌드 도구에서 사용하면 모델이 광범위한 “개선” 대신 단일 편집에 집중하므로 반복이 더 빨라집니다.
이 패턴은 요청이 작은 계약처럼 읽힐 때 가장 잘 작동합니다: 한 가지 분명한 목표, 동일하게 유지될 고정 목록, 결과를 확인할 몇 가지 검사 항목.
아래 템플릿을 복사해 괄호를 채우세요. 짧지만 구체적으로 적으세요.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -\u003e checkout -\u003e receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
구체적인 예: 체크아웃 버튼 색을 바꾸고 싶다면 목표는 “기본 체크아웃 버튼 색을 #1A73E8로 업데이트”입니다. DO NOT CHANGE 항목에는 전체 체크아웃 흐름, 버튼 텍스트, 가격 계산을 고정해야 합니다.
Koder.ai를 사용하면 이 형식 덕분에 리뷰도 빨라집니다. 수락 전 미리보기와 변경 요약을 수락 기준과 비교하면 됩니다.
작은 변경을 요청할 때 “아무 것도 망치지 마세요”라고만 쓰지 마세요. 사용자가 처음 클릭부터 최종 결과까지 어떤 경로를 거쳐야 하는지 정확히 명시하세요. 전체 앱을 고정하는 것이 아니라, 회귀가 발생하면 피해가 큰 부분을 고정하는 것입니다.
먼저 중요한 흐름을 평이한 언어로 나열하세요: 로그인(비밀번호 재설정 포함), 온보딩, 체크아웃, 설정 등. 각 흐름에 대해 “완료”가 무엇인지 적으세요. 예: “사용자는 이메일+비밀번호로 로그인하고 대시보드로 이동하며 새로고침 후에도 로그인 상태가 유지된다.”
그다음 사람들이 자주 잊는 엣지 케이스를 잠그세요. 뒤로가기 동작은 드리프트의 고전적 원인입니다: “Checkout에서 뒤로가면 Cart로 돌아간다(홈으로 가지 않음), 장바구니 항목은 유지된다.” 오류 상태(“잘못된 비밀번호는 동일한 메시지 표시”), 빈 상태(“프로젝트 없음” 화면 카피 유지), 로딩 상태(“스피너가 200ms 이내에 나타나고 레이아웃 점프 없음”) 등을 명시하세요.
성능과 보안 기대치가 중요하다면 그것들도 고정하세요. 언급하지 않으면 모델이 추가 요청을 넣거나 로깅을 추가하거나 인증 체크를 바꿔 “개선”할 수 있습니다.
짧게 정리하면:
데이터 흐름을 항목별 한 문장으로 구체화하세요. 예: “주소는 Save를 누른 후에만 저장되며 user profile 레코드에 저장되고 로그아웃/로그인 후에도 유지된다.” 이렇게 쓰면 자동 저장, 새 필드 추가, 타이밍 변경으로 인한 문제를 막을 수 있습니다.
UI 드리프트는 모델이 스타일을 정리하거나 컴포넌트 구조를 바꾸면서 발생합니다. 해결 방법은 비즈니스 로직과 동일합니다: 수정할 한 가지를 허용하고 나머지는 고정한다고 명시하세요.
보이는 구조를 고정하세요. 레이아웃(컬럼/로우, 헤더/푸터 위치), 간격 규칙(패딩, 갭, 정렬), 컴포넌트 동작(호버, 비활성 상태, 로딩 스피너, 오류 메시지)을 명시하세요. 특정 컴포넌트의 느낌이 중요하면 그대로 적으세요: “버튼 크기, 모서리 반경, 색상은 정확히 동일해야 합니다.”
반응형 동작도 명확한 규칙이 필요합니다. 모바일을 언급하지 않으면 도구가 이를 ‘개선’할 수 있습니다. 관심 있는 브레이크포인트와 각 브레이크포인트에서의 동작(스택 순서, 숨김 요소, 고정 바, 탭 타겟)을 명시하세요.
또한 문구를 고정하세요. 변경하는 한 문자열을 제외한 모든 카피, 레이블, 플레이스홀더, 도움말 텍스트는 동일해야 한다고 모델에 말하세요. 그래야 의미나 레이아웃을 바꾸는 무심한 재작성으로부터 보호됩니다.
간략한 요청 예시:
가능하면 전/후 스크린샷을 요청하세요. 스크린샷이 없으면 짧은 “UI diff”(무엇이 이동했는지, 무엇이 크기가 바뀌었는지, 무슨 색이 바뀌었는지) 설명을 요청해 승인하기 전에 확신을 가질 수 있게 하세요.
비즈니스 규칙은 작은 UI 변경이 조용한 회귀를 만들기 쉬운 영역입니다. 라벨 업데이트가 계산, 상태 전환, 접근 권한을 바꿀 수 있습니다. 규칙과 데이터 동작은 계약으로 다루세요.
먼저 드리프트가 발생하면 가장 피해가 큰 규칙 몇 가지를 테스트처럼 적으세요: 입력, 출력, 누가 어떤 권한을 가지는지.
“가격을 동일하게 유지” 대신 구체적으로 적으세요:
민감한 규칙에는 해석을 막기 위해 숫자 예시 한 개를 추가하세요. 예: “주문 소계 $120, 할인 10%(세전 적용), 세금 8.25%는 할인된 금액에 적용. 예상 총액 = (120 - 12) * 1.0825 = $116.91. 최종 총액에서만 소수점 2자리 반올림.”
역할 기반 가시성도 적으세요. 예: “지원 담당자는 주문 상태와 고객 이메일을 볼 수 있지만 카드 전체 정보는 볼 수 없다. 환불은 관리자만 가능.”
검증이 중요하면 이를 명시적으로 고정하세요. 트리거와 사용자에게 보이는 메시지를 적으세요: “시작일이 종료일 이후면 저장 금지 및 ‘종료일은 시작일 이후여야 합니다.’ 메시지 표시. 이 문구는 변경하지 말 것.”
앱 외부의 부작용(이메일, 웹훅, 외부 API 호출)이 있다면 그것도 고정하세요: 이벤트 이름, 페이로드 필드, 타이밍(즉시/지연), 멱등성(재시도 시 중복 전송 금지) 등.
작은 업데이트도 작은 계약처럼 다루세요. 이 패턴은 변경이 좁고 나머지는 명확히 고정될 때 가장 잘 작동합니다.
변경을 한 문장으로 작성하세요. “설정 페이지에 다크 모드 전환 토글을 추가”는 테스트 가능하고 명확합니다. “설정 UI 개선”은 그렇지 않습니다. 30초 내 테스트할 수 없으면 여전히 범위가 넓습니다.
사용자 흐름, 핵심 UI 요소, 비즈니스 규칙, 데이터 동작, 동일하게 유지해야 할 API/DB 테이블을 고정 목록으로 작성하세요.
수락 체크와 간단한 테스트 플랜을 추가하세요. 여기서 “내 쪽에서만 동작” 문제를 방지합니다. 새 토글이 보이는지, 기존 설정이 여전히 저장되는지, 페이지의 다른 요소가 이동하지 않았는지 같은 검사를 포함하세요.
편집을 시작하기 전에 어시스턴트에게 제약사항을 다시 반복해 달라고 하세요. 변경될 것과 동일하게 유지될 것을 확인하게 하세요. 요약이 정확하지 않다면 편집을 허락하기 전에 프롬프트를 수정하세요.
가능한 한 최소 구현을 요청하세요: 리팩터 금지, 이름 변경 금지, 포맷팅 패스 금지, 종속성 업그레이드 금지. 한 번의 변경을 사는 것이지 전체 개편을 사는 것이 아닙니다.
짧은 리뷰 체크리스트:
Koder.ai에서 특히 잘 작동합니다: 고정 목록을 Planning Mode에 넣고 어시스턴트가 제약을 에코한 뒤 최소 패치를 생성하게 하세요.
대부분의 “작은” 편집이 잘못되는 이유는 요청이 목표는 보호하지만 동작은 보호하지 않기 때문입니다. 모델은 목표는 달성하되 화면, 로직, 데이터에 조용한 변경을 가할 수 있습니다.
전형적인 함정은 결과만 고정하는 것입니다(“온보딩을 더 부드럽게”). 또 다른 함정은 “모든 것을 동일하게 유지”라고 쓰고 시스템이 그 의미를 알 것이라 가정하는 것입니다.
자주 드리프트를 일으키는 실수:
작은 예시: 버튼을 더 눈에 띄게 해 달라고 요청하고 색은 고정했지만 비활성 상태는 고정하지 않았다면 업데이트가 버튼을 항상 활성화되도록 바꿔 의도치 않은 동작을 만들 수 있습니다.
도움이 되는 방법은 변경을 수락하기 전에 빠른 회귀 검사를 하는 것입니다:
이 중 하나라도 다르면 요청이 고정해야 할 세부를 빠뜨린 것입니다. 잘못된 코드는 아닙니다.
안전한 반복에서 흔한 예는 워크플로우를 변경할 수 없는 작은 UI 다듬기입니다.
시나리오: 설립자가 간단한 가입 화면(이름, 이메일, 회사 규모)과 해당 폼을 제출한 뒤 대시보드로 라우팅되는 기본 버튼을 가지고 있습니다.
정확한 변경 요청(한 문장): “기본 버튼 텍스트를 'Create account'에서 'Continue'로 변경하고 'Company size' 필드를 자유 입력에서 드롭다운으로 변경하세요.”
이제 패턴을 적용해 동일하게 유지해야 할 항목들을 고정합니다:
몇 분 안에 실행할 수 있는 수락 체크:
좋은 어시스턴트 응답은 고정 항목을 반복하고, 애매한 점(예: 드롭다운 옵션과 저장되는 값의 정확한 매핑)을 확인하며 최소 변경만 수행했다고 명시하고 라우팅, 검증 로직, 페이로드 형태는 건드리지 않았음을 밝혀야 합니다.
작은 변경을 수락하기 전에 무심코 생기는 드리프트를 찾는 빠른 점검을 하세요. 목표는 전체 QA가 아니라, "여기서 변경하지 말라"고 적은 항목들이 실제로 동일한지 확인하는 것입니다.
다음 순서대로 검사하면 검토가 차분해지고 회귀를 찾기 쉬워집니다.
고정한 항목이 하나라도 바뀌었다면 되돌리세요. 앱이 “동작한다” 하더라도 레이블 변경, 새 필드 추가, 규칙의 미세한 변화는 모델이 자유를 가졌다는 신호입니다.
요청을 다시 할 때는 더 엄격하게 만드세요: 한 문장으로 단일 변경을 다시 적고, 고정할 흐름과 화면을 이름으로 적고, “스키마 변경 없음, 엔드포인트 변경 없음, X 외 동작 변경 금지”를 추가하세요. Koder.ai를 사용하면 변경 전 스냅샷을 찍어 두면 문제가 생겼을 때 롤백이 한 단계로 끝납니다.
Koder.ai에서 작업 중이라면 이 패턴은 습관처럼 적용하세요: 한 번에 한 가지 변경, 나머지는 잠그고, 문제가 생기면 되돌릴 수 있는 명확한 방법을 확보합니다.
변경을 요청하기 전에 Planning Mode로 전환해 어시스턴트가 범위와 고정 목록을 평이한 언어로 반복하도록 하세요. 어시스턴트에게 두 가지를 반복하게 하세요: (1) 정확한 변경, (2) 고정 목록(플로우, UI 세부, 비즈니스 규칙). 명확하지 않은 점이 있으면 편집 전에 질문하게 하세요.
계획용 프롬프트 예: “내 요청을 반복하세요. 그다음 변경하면 안 되는 항목을 나열하세요. 불확실한 점이 있으면 편집 전에 질문하세요.”
모든 변경 요청을 체크포인트로 다루세요. 변경 전 스냅샷을 만들고, 검증 후 확인되면 다시 스냅샷을 만드세요. 문제가 생기면 롤백이 패치로 덮으려 하는 것보다 빠릅니다.
예: React 화면에서 버튼 레이블을 바꾸는 작은 변경이라도 간격이 밀리거나 자동 리렌더링이 발생하거나 자동화 테스트가 깨질 수 있습니다. 스냅샷을 통해 동작을 비교하고 빠르게 되돌릴 수 있습니다.
간단한 워크플로:
Koder.ai는 웹(React), 백엔드(Go + PostgreSQL), 모바일(Flutter)을 모두 생성할 수 있습니다. 코드가 달라도 패턴은 동일합니다. 동작을 정의하는 부분을 고정하세요, 파일만 고정하지 마세요.
백엔드 엔드포인트를 바꿀 때는 요청/응답 형태, 검증 규칙, 데이터 쓰기를 고정하세요. 모바일 화면을 바꿀 때는 네비게이션 순서, 필드 기본값, 오류 메시지를 고정하세요. 데이터베이스 로직을 바꿀 때는 기존 행의 의미를 고정하고 마이그레이션을 안전하게 처리하세요.
템플릿을 복사해 다음 변경 요청에 하나씩 적용하세요.
하나의 특정 변경사항만 원하고 다른 모든 것이 동일하게 유지되길 바랄 때 사용하세요. 특히 결제, 인증, 청구 등 작은 변화가 실사용자 문제로 이어질 수 있는 흐름에 유용합니다.
앱의 여러 부분이 컴포넌트, 데이터, 규칙을 공유하기 때문에 그렇습니다. 작은 UI 수정이 재사용되는 컴포넌트를 건드리면 다른 화면의 레이아웃이 바뀌거나 검증 로직이 달라지거나 API 페이로드가 변경될 수 있습니다.
한 가지 명확한 목표를 적고, 변경 후 반드시 동일해야 할 항목들을 나열하는 것입니다. 핵심은 동작(플로우, 규칙, 데이터, 통합)과 표시되는 UI 세부를 고정하는 것입니다. 단순히 “망가지지 마”라고 쓰는 것과 다릅니다.
핵심 흐름, 이동하면 안 되는 UI/UX 요소, 비즈니스 규칙, 데이터 동작, 통합 등을 짧고 구체적으로 적으세요. 무엇을 동일하게 유지할지 말할 수 없다면 모델이 추측하게 되고 그 추측이 회귀를 만듭니다.
보호할 범위를 가장 작게 잡으세요. 예: 한 화면의 라벨만 바꾸는 경우 전체 앱을 고정할 필요는 없습니다. 체크아웃 흐름처럼 위험한 부분만 고정하세요.
사용자 여정을 단계별로 적고 “완료”의 의미를 정의하세요. 뒤로가기 동작, 오류 메시지, 빈 상태, 새로고침 동작 같은 흔한 엣지 케이스를 추가하면 실제로 사용자가 느끼는 부분에서 동일성이 유지됩니다.
레이아웃 구조, 간격, 컴포넌트 상태(호버/비활성/로딩), 모든 문구(단 한 문자열을 제외하고)를 명시적으로 고정하세요. 명시하지 않으면 모델이 스타일을 정리하거나 문구를 바꿔 레이아웃이나 의미가 달라질 수 있습니다.
요청/응답 형태, 검증 규칙, 권한, 계산법, 언제 무엇이 저장되는지를 고정하세요. 가격처럼 민감한 규칙은 숫자 예시 하나를 넣어 해석 여지를 없애세요.
빠르게 실행할 수 있는 수락 체크리스트와 변경 요약(diff 스타일)을 요청하세요. 그런 다음 고정한 흐름을 끝까지 실행하고, 최소 하나의 오류 상태를 유발하고, 데이터/통합이 변하지 않았는지 확인하세요.
변경 전 스냅샷을 만들고, 계획 단계에서 범위와 고정 목록을 반복 확인한 뒤 최소 패치를 적용하세요. 검증이 끝나면 다시 스냅샷을 만들어 롤백을 쉽게 하세요.