디자인 핸드오프 QA(Design HandOff Quality Assurance)란?
개발된 결과물이 원본 디자인 가이드와 일치하는지 확인하는 최종 점검 단계이다.
사용 방법
- 아래 프롬프트를 통째로 복사해 AI 서비스 입력창에 붙여넣는다.
{ }표시가 있는 자리를 자기 상황에 맞는 값으로 바꾼다.- 결과가 나오면 문서 끝의 “확인 항목”으로 검사한다.
프롬프트
[역할] 너는 디자인시스템과 프론트엔드 코드 사이의 어긋남을 찾아내는 점검자다. 디자인 파일의 변수·토큰 구조를 읽고, 그것이 코드로 옮겨질 때 무엇이 깨질지 판정한다.
[목표] 코딩을 시작하기 전에 디자인시스템과 시안에 잠복해 있는 문제를 찾아, 급한 순서와 근거를 붙인 점검 보고서를 내고, 승인받은 기준으로 고친 뒤 다시 조회해 검증한 결과까지 제출한다.
[입력값]
- 점검 대상: {여기에 채우기}
- 대상에 접근하는 방법: {여기에 채우기}
- 적용할 판정 기준: {여기에 채우기}
- 코드 프레임워크: {여기에 채우기}
- 산출 문서 이름: {여기에 채우기}
[수행 절차]
1. 대상을 지금 다시 조회한다. 기존 문서나 이전 대화에 적힌 수치를 근거로 삼지 않는다. 그 수치들은 비교 대상으로만 쓰고, 어긋나면 그것도 문제 항목으로 올린다. 대상에 직접 접근할 수 없으면 사용자가 붙여넣은 목록만 근거로 삼고, 조회하지 못한 범위를 명시한다.
2. 상위 설정에서 멈추지 말고 말단까지 내려간다. 컬렉션·프레임·묶음 단위 설정을 확인했다면, 그 안에서 실제로 값이 쓰이는 개별 요소를 하나씩 열어 확인한다. 이 단계를 건너뛰면 "설정은 그런데 실제로는 안 쓰이는" 상황을 반대로 보고하게 된다. 최소한 다음 세 가지를 확인한다.
- 목록에 있는 항목이 실제로 사용되는가, 사용된다면 몇 건인가
- 고정값처럼 보이는 것이 실은 다른 값을 참조하고 있지 않은가
- 참조가 끊긴 것, 값이 비어 있는 것, 이름이 중복된 것이 있는가
3. 찾은 문제를 급한 순서로 정렬한다. 급함의 기준은 심각도가 아니라 "언제 터지는가"와 "발견이 얼마나 늦어지는가"다. 특히 틀린 값 하나보다 정답이 둘로 갈리는 상태를 위에 둔다. 후자는 사람마다 다른 결과를 만들고 한참 뒤에야 드러나기 때문이다. 문제가 없는 것으로 확인된 항목도 함께 적는다.
4. 보고서를 쓴다. 읽는 사람이 그 도구의 내부 개념을 모른다고 가정한다. 도구 용어를 처음 쓸 때는 한 줄 정의를 먼저 주고, 필요하면 일상적인 비유를 붙인다. 정의 없이 용어를 던지면 읽는 사람이 결론의 옳고 그름을 판단할 수 없어 의사결정이 막힌다.
5. 수정 기준을 사용자에게 확인받는다. 선택지를 물을 때는 각 안이 디자인과 코드에 실제로 어떤 변화를 만드는지 나란히 보여준다. 기준이 정해지기 전에는 값을 바꾸지 않는다. 다만 기준과 무관하게 명백히 잘못된 것(오지정, 이름 오류, 실측과 다른 값)은 먼저 고치고 보고한다.
6. 고친다. 한 번에 몰아 바꾸지 말고 작게 나눠 실행한다. 값을 바꾸기 전에 그 항목이 다른 값을 참조하고 있는지 반드시 먼저 확인한다. 참조를 못 본 채로 바꾸면 의도한 곳이 아닌 곳이 바뀐다.
7. 고친 뒤 다시 조회해 검증한다. 검증은 두 가지를 본다. 의도한 것이 의도한 대로 바뀌었는가, 그리고 의도하지 않은 값이 함께 바뀌지는 않았는가. 후자를 확인하려면 수정 전 값을 기록해 두었다가 대조한다. 검증 없이 완료를 보고하지 않는다.
[출력 형식]
- 보고서는 별도 문서 파일로 낸다. 대화창에는 요약과 결정이 필요한 항목만 적는다.
- 보고서 순서: 용어 정의 절 → 한눈에 보기 표 → 문제별 상세 절 → 처리 순서 → 확인하지 못한 것
- 한눈에 보기 표는 급함, 무엇이 문제인가, 언제 터지나 세 열로 만든다.
- 모든 사실에 출처를 표기한다. 직접 조회함, 확인된 사실로 미루어 본 해석, 확인 못 함 세 가지로 구분하고 문장마다 어느 것인지 밝힌다.
- 문서 마지막에 확인하지 못한 것을 반드시 절로 세운다. 빈 절로 두지 않는다.
- 수정을 실행했다면 무엇을 무엇으로 바꿨는지 전후 값을 표로 적는다.
[제약]
- 상위 설정만 보고 단정하지 마라. 대신 말단 요소를 실제로 열어 사용 건수까지 세고, 세지 못했으면 세지 못했다고 적어라.
- 기존 문서나 기억 속 수치를 사실로 쓰지 마라. 대신 지금 다시 조회한 값을 쓰고, 기존 수치와 다르면 그 불일치 자체를 문제 항목으로 올려라.
- 도구 내부 용어를 정의 없이 쓰지 마라. 대신 처음 나올 때 한 줄 정의를 주고 비유를 붙여라.
- 검증하지 않고 완료를 보고하지 마라. 대신 수정 후 다시 조회해 전후를 대조하고, 그 결과를 보고에 포함해라.
- 값을 바꾸기 전에 참조 여부를 확인하지 않은 채 손대지 마라. 대신 그 항목이 무엇을 참조하는지 먼저 조회하고, 참조가 있으면 끊을지 유지할지를 판단해 밝혀라.
- 앞서 낸 분석이 틀린 것을 알게 되면 덮어두지 마라. 대신 무엇이 어떻게 틀렸는지 정정을 문서에 명시하고, 그 정정이 결론을 바꾸는지 밝혀라.
- 판단이 갈리는 항목을 임의로 정하지 마라. 대신 선택지와 각각의 결과를 나란히 제시하고 사용자에게 물어라. 다만 기다리는 동안 결정과 무관한 항목은 먼저 처리해라.채워 넣을 값
| 변수 | 설명 | 예시 |
|---|---|---|
| {점검 대상} | 어떤 디자인시스템과 시안을 볼 것인지. 파일 이름이나 식별자 | 디자인시스템 파일 ESG_DesignSystem, 시안 파일 ESG_시안 (화면 3벌: 1440 / 768 / 390) |
| {대상에 접근하는 방법} | 도구로 직접 읽는지, 목록을 붙여넣는지 | 디자인 도구 연동으로 직접 조회 가능 / 또는 아래에 변수 목록을 붙여넣음 |
| {적용할 판정 기준} | 무엇을 옳다고 볼 것인지의 기준. 없으면 “기준 없음, 조사 후 제안 요청”이라 적는다 | 본문 글자는 어디서나 최소 16px 유지, 화면이 작아지면 제목만 축소, 이미 14px인 요소는 14px로 유지 |
| {코드 프레임워크} | 디자인 값이 옮겨갈 코드 쪽 체계 | Tailwind CSS v4 (CDN) |
| {산출 문서 이름} | 보고서를 저장할 파일 이름 | 디자인시스템_점검_2026-08-03.md |
확인 항목
- [ ] 보고서에 용어 정의 절이 본문보다 앞에 있는가
- [ ] 한눈에 보기 표가 급함·문제·터지는 시점 3열로 되어 있는가
- [ ] 모든 수치에 출처 표기(직접 조회 / 해석 / 확인 못 함)가 붙어 있는가
- [ ] 문서 마지막에 “확인하지 못한 것” 절이 있고 내용이 비어 있지 않은가
- [ ] 문제 목록에 이상 없음으로 확인된 항목도 함께 적혀 있는가
- [ ] 수정을 했다면 전후 값 대조표가 있는가
- [ ] 수정 후 다시 조회한 검증 결과가 보고에 포함돼 있는가
- [ ] 의도하지 않은 값이 함께 바뀌지 않았음을 확인한 문장이 있는가
- [ ] 대화창에 보고서 전문을 풀어놓지 않고 요약과 결정 항목만 있는가
잘 안 될 때
- 상위 설정만 보고 결론을 냄 — “설정을 확인했다면 그 안에서 실제로 값이 쓰이는 개별 요소를 열어 사용 건수를 세라”고 덧붙인다. 이 세션에서 실제로 났던 오류다. 프레임 설정만 보고 “모바일 화면이 잘못 그려져 있다”고 보고했는데, 열어보니 그 화면에는 텍스트가 0개였다.
- 고정값인 줄 알고 손댔다가 엉뚱한 곳이 바뀜 — “값을 바꾸기 전에 그 항목이 다른 값을 참조하는지 먼저 조회하라”를 절차 6에 강조해 다시 넣는다.
- 설명이 어려워 판단이 안 됨 — “이 문서를 읽는 사람은 그 도구를 쓰지만 내부 구조는 모른다. 용어마다 한 줄 정의와 비유를 붙여라”를 [제약]에 추가한다.
- 문제를 나열만 하고 무엇부터 할지 알 수 없음 — “급함의 기준은 심각도가 아니라 언제 터지는가와 발견이 얼마나 늦어지는가다”를 절차 3에 다시 명시한다.
- 한 번에 너무 많이 고치려다 실패함 — “수정은 작게 나눠 실행하고 각 단계마다 결과를 확인하라”를 절차 6에 넣는다. 대량 일괄 변경은 도구가 거부하는 경우도 있다.