46/ 50
＋ 요청의 불확실성을 지키며 영향과 비용을 빠짐없이 짚었다.
－ 일부 상태 처리를 이미 구축된 사실처럼 표현했고 다소 길다.
변경 요청의 실제 비용을 따지는 프롬프트
시간이 아니라 무엇을 다시 해야 하는지로 셉니다. 조용히 깨지는 것을 짚습니다.
| 분류 | 디자인 › 디자인 협업 |
|---|---|
| 태그 | 분석검토질문생성 |
A change was requested. **Work out what it actually costs before I say yes.** 1. **What is actually being asked** — ***restate it.* **Requests arrive as solutions; find the need underneath** 2. **What it touches:** - ***This screen only, or a pattern used elsewhere*** — **a component change is never one screen** - Content that would need rewriting - **Decisions this would reverse**, ***and who made them*** - What is already built 3. **What it costs** — ***in what has to be redone, not in hours.* **"The flow has to be re-tested" is more useful than a number** 4. **What it breaks** — ***states, edge cases, and the accessibility work already done.* **These are what get silently dropped in a rushed change** 5. **Whether there is a smaller version** that addresses the need **Then:** - ***What to ask before agreeing*** — **especially: is this a preference or a problem?** - **What to say if the answer is no**, ***without it being a refusal*** — the alternative, the cost, or the condition - ***What to write down either way.* **An undocumented change becomes the reason something else broke** ⚠️ ***Work only from what I gave you. Do not invent what they meant, and do not assume a design or a constraint I did not state.***
붙여 넣으면 맨 아래에 채울 칸(변경 요청 · 현재 상태)이 나옵니다
어떤 프롬프트인가
변경 요청을 받아들일 때 조용히 깨지는 것들이 있다 — 빈 상태, 엣지 케이스, 이미 해둔 접근성 작업. 급한 변경에서 가장 먼저 사라지는 것들이고 아무도 안 적는다. 이 프롬프트는 비용을 시간이 아니라 "무엇을 다시 해야 하는가"로 세고, 취향인지 문제인지부터 묻게 한다.
모델 비교
ChatGPT가 불확실성을 유지하며 가장 충실하다. Gemini는 구체적이지만 추정과 대비비 오류가 있고, [C]는 누락됐다.
39/ 50
＋ 공용 컴포넌트의 영향과 작은 대안을 간결하게 제시했다.
－ 숨은 필요를 단정하고 오렌지 대비비를 부정확하게 제시했다.
| 기준 | ChatGPT | Gemini | 앞선 모델 |
|---|---|---|---|
| 지시 준수 | 10 | 8 | ChatGPT +25% |
| 정확성 | 9 | 5 | ChatGPT +80% |
| 구체성 | 10 | 9 | ChatGPT +11% |
| 구성·가독성 | 9 | 9 | 동점 |
| 분량 적정성 | 8 | 8 | 동점 |
gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.
답 전문 보기
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
변경 요청: 체크아웃 페이지의 '결제하기' 버튼을 지금보다 눈에 더 띄게 브랜드 오렌지(#FF6B00)로 바꾸고, 버튼 크기도 키워달라는 요청이 대표님한테서 내려왔습니다. 현재 상태: 현재 '결제하기' 버튼은 디자인 시스템의 Primary 컬러(#2563EB, 파란색)를 쓰고 있고, 같은 버튼 스타일(Button/Primary/Large)이 장바구니, 배송지 입력, 회원가입 등 13개 화면에서 공용 컴포넌트로 재사용되고 있습니다. 최근 접근성 감사에서 이 파란색 버튼의 대비비를 4.6:1로 맞춰서 겨우 통과시킨 상태입니다.
1. 실제 요청은 무엇인가
표면적인 요청은 다음 두 가지입니다.
- 체크아웃의
결제하기버튼을 파란색에서 브랜드 오렌지#FF6B00로 변경 - 버튼 크기를 키움
다만 현재 정보만으로는 이것이 해결하려는 문제가 명확하지 않습니다. 실제 필요가 다음 중 무엇인지 먼저 확인해야 합니다.
- 사용자가 버튼을 잘 발견하지 못하는가
- 결제 전환이 낮은가
- 브랜드 노출을 강화하려는가
- 대표님의 시각적 선호인가
즉, “더 눈에 띄어야 한다”는 문제 정의인지, 아니면 색상과 크기에 대한 선호인지 구분해야 합니다.
2. 무엇에 영향을 주는가
화면 범위
요청은 체크아웃 한 화면에서 시작하지만, 현재 버튼은 Button/Primary/Large 공용 컴포넌트입니다.
따라서 공용 컴포넌트 자체를 변경하면 다음 13개 화면에 영향을 줍니다.
- 체크아웃
- 장바구니
- 배송지 입력
- 회원가입
- 그 외 9개 화면
체크아웃에만 적용하려면 공용 컴포넌트 변경이 아니라 별도 변형이나 화면 전용 스타일이 필요합니다. 이것 역시 새 변형을 설계·검토·관리해야 하는 변경입니다.
다시 검토해야 할 콘텐츠
문구 결제하기 자체를 바꾸라는 요청은 없습니다. 따라서 원칙적으로 문구 재작성은 필요하지 않습니다.
다만 버튼 크기가 커지면 다음을 다시 확인해야 합니다.
- 주변 안내 문구와의 간격
- 버튼이 차지하는 공간
- 긴 문구나 다른 언어를 사용할 때의 표시 가능성
- 로딩·오류 상태에서의 레이아웃
되돌리게 되는 결정
현재 뒤집히는 결정은 다음과 같습니다.
- Primary 버튼은 디자인 시스템의 파란색
#2563EB를 사용한다는 결정 Button/Primary/Large를 여러 화면에서 공용으로 재사용한다는 결정- 파란색 버튼의 대비비를 4.6:1로 맞춰 접근성 감사를 통과시킨 결정
각 결정을 누가 내렸는지는 제공된 정보에 없습니다. 따라서 디자인 시스템 담당자, 접근성 감사 승인자, 그리고 공용 컴포넌트를 사용하는 화면 담당자에게 결정권과 영향 범위를 확인해야 합니다. 이번 요청의 발신자는 대표님이지만, 그것만으로 기존 결정의 담당자나 접근성 승인자를 알 수는 없습니다.
이미 만들어진 것
이미 존재하는 작업은 다음과 같습니다.
- 공용
Button/Primary/Large컴포넌트 - 13개 화면에 대한 재사용 구조
- 파란색
#2563EB의 접근성 대비비 4.6:1 검증 결과 - 해당 버튼을 사용하는 각 화면의 배치와 상태 처리
3. 실제 비용
비용은 버튼 CSS를 바꾸는 데 있지 않고, 다음을 다시 검증하고 되돌리는 데 있습니다.
- 공용으로 바꿀 경우 13개 화면의 시각적 적합성 재검토
- 체크아웃과 나머지 화면의 버튼 계층 재검토
- 오렌지
#FF6B00의 글자·배경 대비비 재검증 - 통과하지 못하면 텍스트 색상이나 버튼 표현을 다시 설계
- 버튼 확대에 따른 각 화면의 간격·정렬·레이아웃 재검토
- 기본, hover, focus, disabled, loading, 오류 등 상태 재검토
- 반응형 화면과 콘텐츠가 길어지는 경우 재검토
- 접근성 감사와 키보드 포커스 검증 재수행
- 13개 화면의 회귀 테스트 및 체크아웃 결제 흐름 재테스트
- 디자인 시스템 문서와 사용 규칙 업데이트
특히 #FF6B00이 기존 파란색과 동일하게 접근성 기준을 통과한다고 아직 확인할 수 없습니다. 대비비가 달라질 수 있으므로, 색상을 확정하기 전에 검증이 필요합니다.
4. 무엇이 깨질 수 있는가
- 오렌지 배경과 흰색 글자의 대비가 기준을 충족하지 않을 수 있음
- 버튼 확대 때문에 모바일이나 좁은 화면에서 주변 요소가 밀릴 수 있음
- disabled·loading 상태가 오렌지 색상과 충분히 구분되지 않을 수 있음
- 키보드 focus 표시가 버튼 색상에 묻힐 수 있음
- 장바구니·배송지 입력·회원가입 등에서 기존 Primary의 시각적 의미가 달라질 수 있음
- 공용 변경 시 결제와 무관한 화면까지 브랜드 오렌지로 바뀜
- 화면 전용 변경 시 공용 컴포넌트와 다른 예외가 생겨 유지보수 규칙이 복잡해질 수 있음
- 이미 통과한 접근성 검증 결과를 다시 확인해야 함
5. 더 작은 버전
필요가 “체크아웃에서 결제 버튼을 더 잘 발견하게 하는 것”이라면, 공용 Primary 색상과 크기를 13개 화면에서 모두 바꾸지 않고 다음 방향을 먼저 검토할 수 있습니다.
- 체크아웃에만 별도 변형을 적용
- 기존 버튼 크기는 유지하고, 체크아웃에서만 주변 여백·배치·시각적 강조를 조정
- 오렌지를 쓰더라도 대비비와 focus·disabled·loading 상태를 먼저 검증한 뒤 체크아웃 전용으로 제한
단, 이 방법도 새 변형을 추가하는 것이므로 디자인 시스템에 예외를 만들지, 공식 변형으로 관리할지 결정해야 합니다.
동의하기 전에 물어볼 것
- 현재 실제 문제가 무엇인가요? 사용자가 버튼을 못 찾는다는 데이터나 사례가 있나요?
- 이것은 전환율·발견성 문제인가요, 아니면 대표님의 브랜드 선호인가요?
- 오렌지와 버튼 확대가 반드시 필요한 해결책인가요?
- 변경 범위는 체크아웃만인가요, 13개 공용 사용처 전체인가요?
#FF6B00에서 어떤 글자 색을 사용할지, 대비 기준을 어떻게 검증할지 정했나요?- 공용 컴포넌트를 바꿀 경우 13개 화면의 재검토와 재테스트를 승인한 것인가요?
- 접근성 감사에서 통과한 기준을 유지하는 것이 우선순위에 포함되나요?
- 버튼 크기는 어느 화면과 상태를 기준으로 정하나요?
- 변경의 성공 여부를 무엇으로 판단하나요?
답이 “아니오”일 때 말하는 방식
“요청을 적용하지 않겠다”가 아니라 이렇게 제안할 수 있습니다.
현재 요청은 체크아웃 한 화면의 개선처럼 보이지만, 실제로는 13개 화면에서 사용하는 공용 버튼과 최근 통과한 접근성 기준을 함께 되돌리는 변경입니다. 먼저 오렌지 색상의 대비비와 버튼 확대에 따른 화면 영향을 확인해야 합니다.
문제가 체크아웃에서 버튼이 잘 보이지 않는 것이라면, 공용 컴포넌트 전체를 바꾸지 않고 체크아웃 전용 변형으로 검증해보는 방법을 제안합니다. 다만 브랜드 오렌지를 반드시 공용 Primary로 적용해야 한다면, 13개 화면과 접근성 검증을 다시 진행하는 조건으로 동의하는 것이 안전합니다.
기록할 것
동의하든 보류하든 다음을 문서화해야 합니다.
- 변경 요청자: 대표님
- 요청 내용: 체크아웃
결제하기버튼의 오렌지색 적용 및 크기 확대 - 변경 목적과 성공 기준
- 체크아웃만 변경하는지, 공용 컴포넌트 전체를 변경하는지
- 영향을 받는 13개 화면
- 기존 파란색
#2563EB와 대비비 4.6:1 검증 결과 - 접근성 기준을 유지할지 여부와 재검증 결과
- 기본·focus·disabled·loading 등 상태별 결정
- 버튼 크기 변경으로 재검토한 화면과 레이아웃
- 최종 승인자와 결정일
- 보류했다면 보류 이유와 재검토 조건
- 적용했다면 공용 컴포넌트 변경인지 체크아웃 전용 변형인지
같은 분류의 프롬프트
| UI 디자인 브리프 프롬프트 | |
| 경쟁 화면에서 결정을 읽어내는 프롬프트 | |
| 모호한 디자인 피드백을 해석하는 프롬프트 | |
| 디자인 핸드오프 노트 작성 프롬프트 | |
| 개발 인계 명세 쓰는 프롬프트 |