프론트엔드 팀을 위한 쉬운 안내서

AI 도우미에게 건네는
꼼꼼한 화면 작업 설명서

Superloopy 프론트엔드 스킬은 Codex나 Claude Code 같은 AI가 화면을 만들거나 고칠 때 따르는 설명서예요. 어려운 말은 빼고 식당 홀 이야기와 웹 화면 예시로 차근차근 풀어 볼게요.

한 줄 요약 어떤 화면인지 먼저 확인하고 필요한 안내서만 펼쳐요. 우리 디자인 기준을 따르고 진짜로 그려진 화면으로 확인한 뒤 영수증을 남겨요.
  • Superloopy v0.23.1 기준
  • 예시: 웹 화면, 360px 휴대폰

먼저

단어 세 개만 알고 시작해요

프론트엔드는 식당의 홀이에요

손님은 홀에 앉아 메뉴판을 보고 주문해요. 앱에서는 사람이 보고 누르는 화면이 홀이에요. 웹 페이지, 데스크톱 앱, 휴대폰 앱 화면이 모두 여기에 들어가요.

이 스킬은 웹, 데스크톱, 휴대폰과 태블릿, 앱 안에 들어간 웹, Qt 화면을 맡아요.

스킬은 AI에게 주는 작업 설명서예요

새로 온 홀 직원에게 “우리 가게는 이렇게 손님을 맞아요”라고 적은 종이를 건네는 것과 같아요. AI는 이 설명서를 읽고 적힌 순서대로 일해요.

실제 파일: skills/superloopy-frontend/SKILL.md

Superloopy는 증거를 챙기는 도구 상자예요

AI가 “다 고쳤어요”라고 말로만 끝내지 않고 진짜로 그려진 화면 같은 증거를 보여 주게 만드는 도구 상자예요. 프론트엔드 스킬은 이 상자에 든 도구 중 하나예요.

저장소: github.com/beefiker/superloopy

손님 화면을 쓰는 사람
보고 누르기클릭, 입력, 터치
홀 화면 (프론트엔드) AI 도우미가 스킬 설명서를 보며 일해요
주문서API 요청
주방 서버 (백엔드)

큰 그림

스킬은 이렇게 일해요: 8단계

스킬이 켜지면 AI는 매번 같은 순서로 일해요. 번호를 눌러 한 단계씩 살펴보세요. 단계마다 쉬운 설명, 웹 화면 예시, 스킬 원문을 우리말로 옮긴 문장이 있어요.

1단계

이름을 불러야 깨어나요

쉽게 말하면강아지가 자기 이름을 들어야 달려오는 것처럼, 이 스킬도 이름을 불러야 깨어나요. 대화에 UI, 화면, 버튼, React 같은 단어가 나온다고 저절로 켜지지 않아요. 깨어나면 첫 줄에 SUPERLOOPY FRONTEND ENABLED라고 적어서 알려 줘요.

  • Codex에서는 $superloopy:superloopy-frontend 뒤에 할 일을 적어요.
  • Claude Code에서는 /superloopy:superloopy-frontend 뒤에 할 일을 적어요.
  • 화면 일을 부탁하는 말 맨 앞에 loopy나 루피를 붙여도 돼요.
  • 이미 돌고 있는 Superloopy 루프가 화면 일을 이 스킬에 넘겨주기도 해요.

이 말에 깨어날까요? 눌러 보세요

위 문장 중 하나를 눌러 보세요.

2단계

어떤 화면인지 확인해요

쉽게 말하면손님을 받기 전에 홀부터 둘러봐요. 몇 명이 앉는 자리인지, 아이 의자가 있는지, 메뉴판은 어떤 말로 적혀 있는지요. AI도 고치기 전에 누가 어떤 기기에서 쓰는 화면인지부터 확인해요.

  • 지금 화면에서 문제를 먼저 재현하고 같이 망가질 수 있는 옆 화면도 적어 둬요.
  • 아는 것은 증거, 짐작은 추측, 모르는 것은 모름으로 나누고 얼마나 확실한지도 적어요.
  • 저장소를 먼저 살펴요. 답에 따라 길이나 결과가 달라질 때만 묻고 질문이 여럿이면 한 번에 물어요.

확인 메모

  1. 누가, 무엇을 하려는지 휴대폰으로 상품을 찾는 손님이 검색어를 보며 입력해요. (증거: 신고 스크린샷) 처음 결제하는 손님이 카드 정보를 넣고 결제를 끝내요. (추측: 실패율 자료 없음, 확실도 낮음)
  2. 기기와 환경 휴대폰 Chrome, 360px 화면 (프로젝트 지원 목록에서 확인) 휴대폰과 데스크톱 브라우저. 지원 목록은 browserslist 설정에서 확인
  3. 화면의 종류 로그인 없이 보는 공개 웹 페이지 로그인 뒤에 보는 웹 화면. 결제 대행사 창이 안에 들어와요
  4. 누가 그리고 무엇을 읽는지 브라우저가 HTML로 그려요. 스크린 리더는 HTML 구조를 읽어요
  5. 누가 무엇을 맡는지 검색 폼 마크업과 src/app.css 결제 폼 컴포넌트, 결제 상태는 서버가 맡아요
  6. 프레임워크와 버전 HTML과 CSS뿐이에요 package.json에 고정된 버전을 공식 문서와 맞춰 봐요
  7. 배포, 업데이트, 저장 경계 바뀌지 않아요. 영수증에 한 줄로 적어요 결제 중 새로고침해도 입력이 남는지, 새 버전이 나가는 방법
  8. 입력, 언어, 보조 기술, 확인 수단 바뀌지 않아요. 영수증에 한 줄로 적어요 키보드, 터치, 스크린 리더, 한국어와 영어, 실제 브라우저 자동화로 확인 가능

좁은 수정 · 기존 영수증에 짧게 적고 UX_CONTRACT.md는 만들지 않아요.

3단계

맞는 안내서만 펼쳐요

쉽게 말하면홀 직원 교육서는 한 권이 아니에요. 매장, 배달, 공항 지점 안내서가 따로 있죠. AI도 화면의 종류에 맞는 안내서만 펼쳐요. 어떤 화면이든 공통 안내서(UX)는 먼저 읽어요.

화면의 종류를 골라 보세요 (여러 개 골라도 돼요)

공통 UX사용자, 흐름, 화면 상태, 접근성, 증거 계획
웹브라우저, 반응형, 진짜 브라우저로 확인
직접 그리는 화면캔버스나 엔진이 글자와 입력을 맡을 때
데스크톱창, 메뉴, 단축키, 설치와 업데이트
휴대폰·태블릿터치, 화면 가장자리, 회전, 접근성 설정
앱 안의 웹앱 껍데기와 웹 화면 사이의 다리
QtQt 버전, Widgets와 Quick, Qt 전용 확인

화면의 종류를 고르면 펼칠 안내서에 불이 들어와요.

실제 표는 더 자세해요. Qt는 Widgets와 Quick, 데스크톱과 휴대폰, 웹어셈블리 조합마다 줄이 따로 있어요. 대상이 여럿이면 공통 안내서는 한 번만 읽고 대상마다 증거를 따로 남겨요.

4단계

바뀐 만큼만 더 펼쳐요

쉽게 말하면메뉴에 새 음식이 들어오면 그 음식을 맡을 사람만 불러요. 접시 색만 바꾸는데 직원을 전부 부르지는 않죠. 화면 일도 이번에 바뀌는 것에 따라 안내서를 더 펼쳐요.

이번에 무엇이 바뀌나요? (여러 개 골라도 돼요)

배치영역, 크기, 스크롤 주인, 넘침, 읽는 순서
움직임반복, 중간에 끊기, 움직임 줄이기 설정
그림 먼저시안이 방향인지 승인된 기준인지 나누기
뻔한 AI 디자인 검사가짜 자료, 습관처럼 고른 기본값
한 번 다듬기방향을 읽고 딱 한 번만 다듬기
리디자인주소, 메뉴 이름, 폼 이름 지키기
더 펼치지 않음바뀌지 않은 이유를 한 줄로 적어요

바뀌는 것을 고르면 더 펼칠 안내서에 불이 들어와요.

웹에서 움직임이 바뀌면 웹 전용 움직임 안내서도 더해요. 로그인 뒤에 쓰는 제품 화면이나 회사 내부 화면에는 뻔한 디자인 검사와 다듬기를 펼치지 않아요.

5단계

디자인 기준을 따라요

쉽게 말하면가게마다 접시, 앞치마, 인사말 규칙이 있어요. 새 직원이 마음에 드는 접시를 사 와서 쓰면 안 되죠. AI도 프로젝트가 이미 정한 디자인 기준을 따라요.

기준을 다루는 약속

  • 기준은 프로젝트에 이미 있는 것이에요 (토큰 파일, 디자인 시스템 등)
  • 기준에 없는 색이나 간격이 필요하면 기준에 먼저 더해요
  • DESIGN.md는 기준이 없거나 연결표가 필요할 때만 써요
  • 두 번째 기준을 따로 만들지 않아요
  • 한 화면의 겉모습은 한 시스템이 맡아요
  • 운영체제가 정하는 글꼴과 색은 그대로 둬요

허락이 필요한 일: 새 패키지

“GitHub처럼 보이게 해 줘”는 Primer를 설치할 이유가 아니에요. 비슷해 보이는 것은 계약이 아니거든요. 프로젝트가 이미 쓰고 있거나, 앱이 들어가는 곳이 요구하거나, 사용자가 분명히 고르거나, 규정이 정했을 때만 그 디자인 시스템을 따라요. 필요한 패키지가 없으면 영향부터 설명하고 허락을 받아요.

공식 디자인 시스템은 부품을 줄 뿐이에요. 앱의 접근성까지 저절로 지켜 주지 않아요.

글자, 접근성 이름처럼 모양이 바뀌지 않는 좁은 수정이면 디자인 문서를 새로 만들지 않아요. 이렇게 이유와 함께 적어요.

Design impact: unchanged — aria-label만 고침, 모양 그대로

6단계

쓰던 도구로 만들어요

쉽게 말하면손에 익은 도구를 두고 새 도구를 사 오면 다들 헷갈려요. AI도 프로젝트가 쓰던 프레임워크, 스타일 방식, 아이콘을 그대로 써요.

  1. 쓰던 구조 그대로지금의 구조와 스타일 방식을 지켜요.
  2. 패키지는 허락 받고새 의존성은 설명하고 허락을 받은 뒤에만 더해요.
  3. 있던 것부터아이콘과 스타일은 이미 있는 것을 먼저 써요.
  4. 모든 상태로딩, 빈 화면, 오류, 다시 시도, 중복 제출까지 실제 주인에 맞춰 만들어요.
  5. 움직임 조심너비, 높이 같은 배치 속성은 애니메이션하지 않고 움직임 줄이기 설정을 지켜요.
  6. 크루에게 나누기나눠 맡길 때는 필요한 요구와 토큰을 같이 건네고 가져온 증거로 판단해요.
8가지 규칙 카드로 보기

7단계

대상마다 따로 확인해요

쉽게 말하면같은 음식이라도 매장에서 먹을 때와 배달할 때는 따로 확인하죠. 매장에서 맛있었다고 배달 포장까지 괜찮은 건 아니에요. 화면도 대상마다 증거가 따로 있어야 해요.

  • 확인할 브라우저와 화면 폭은 우리 대상에서 정해요. 390, 768, 1280px은 참고 표본일 뿐이에요.
  • 웹의 최소 확인은 배포용 빌드, 바뀐 흐름, 옆 화면 회귀, 지원하는 진짜 브라우저 하나예요.
  • 모양이 바뀌면 진짜로 그려진 화면을 찍고 VISUAL_QA.md를 써요. 동작만 바뀌면 동작 증거로 충분해요.

대상을 눌러 확인해 보세요

한 대상이 다른 대상을 대신 증명하지 못해요. 같은 파일 하나를 두 대상의 증거로 쓰는 것도 Superloopy 검사에서 막혀요.

8단계

영수증을 남겨요

쉽게 말하면가게에서 물건을 사면 영수증을 받죠. 나중에 누가 “정말 샀어요?”라고 물으면 보여 줄 수 있어요. AI도 화면 일을 마치면 무엇을 어디서 어떻게 확인했는지 남겨요.

프론트엔드 작업 영수증

실행마다 폴더 하나: .superloopy/evidence/frontend/<실행 id>/

실행 id20261013T070825Z-search-button-overflow

모양이 바뀌면 VISUAL_QA.md에 적는 것

기준과 실제 대상
무엇과 비교했고 어떤 화면을 찍었는지 적어요.
상태와 화면 폭
빈 화면, 오류, 입력 중 같은 상태와 실제 화면 폭을 적어요.
브라우저, OS, 입력 방식
어떤 브라우저 빌드에서 어떤 입력으로 확인했는지 적어요.
보인 차이, 원인, 결과, 한계
무엇이 달랐고 왜 그랬는지, 결론과 확인하지 못한 점을 적어요.

루프 없이 혼자 돌렸다면 AI 답변의 마지막 줄을 이렇게 끝내요.

SUPERLOOPY_EVIDENCE: .superloopy/evidence/frontend/<실행 id>/VISUAL_QA.md

실행 폴더는 스킬에 든 evidence-root.mjs가 만들어요. 이름 규칙이 정해져 있어서 어느 운영체제에서도 같은 경로가 돼요. 루프가 돌고 있으면 loop guide가 알려 준 목표와 기준 id로 증거를 연결해요. 루프가 없는데 루프 상태를 지어내지 않아요.

증거가 만들어지는 과정 자세히 보기

직접 보기

화면 버그 하나가 고쳐지는 과정

연습용 웹 프로젝트에서 실제로 돌린 결과로 장면을 만들었어요. 명령 출력과 스크린샷은 실제 결과예요. AI와 나눈 말과 확인 메모는 이해를 돕기 위해 꾸몄어요.

신고된 버그

휴대폰에서 검색 버튼 때문에 입력창이 찌그러져요

버튼 글자 ‘지금 바로 전체 상품 검색하기’가 줄바꿈 없이 한 줄을 다 차지해요. 360px 화면에서는 입력창이 좁아져서 안내 문구가 ‘상품명을 입’에서 잘려요.

확인 전

부탁하기

1단계

개발자가 스킬 이름을 불러 부탁해요. 스킬이 깨어나 첫 줄에 신호를 보내고 도우미 스크립트가 든 스킬 폴더 위치를 알려요.

나$superloopy:superloopy-frontend 휴대폰(360px)에서 상품 검색 버튼 글자 때문에 입력창이 찌그러져요. 실제 화면으로 확인하고 고쳐 주세요.

AI
SUPERLOOPY FRONTEND ENABLED
FRONTEND_SKILL_DIR=/Users/me/.codex/plugins/cache/beefiker/superloopy/0.23.1/skills/superloopy-frontend

어떤 화면인지 확인하기

2단계

저장소부터 살펴요. 공개 웹 페이지예요. 브라우저가 HTML로 그려요. 이 프로젝트의 디자인 기준은 DESIGN.md예요. 버튼 하나를 고치는 좁은 수정이라 UX_CONTRACT.md는 만들지 않아요.

## 확인 메모
- 사용자: 휴대폰으로 상품을 찾는 손님 (증거: 신고 스크린샷)
- 대상: 공개 웹 페이지, 휴대폰 Chrome 360px
- 디자인 기준: DESIGN.md (색 5개, 간격 기본 4px)
- 옆 화면: 데스크톱 1280px 검색 폼
- 크기: 좁은 수정, 기존 영수증에 짧게

맞는 안내서 고르기

3단계4단계

웹 페이지라 공통 UX와 웹 안내서를 펼쳐요. 버튼 폭과 줄바꿈이 바뀌니 배치 안내서를 더해요. 움직임은 그대로이고 홍보 페이지가 아닌 제품 화면이라 다른 안내서는 펼치지 않아요.

펼침     ux.md, web.md, layout.md
안 펼침  motion-core.md   움직임은 그대로
안 펼침  anti-slop.md     홍보 페이지가 아닌 제품 화면

진짜 화면으로 재현하기

규칙 27단계

처음에는 Chrome headless로 360px을 찍었는데 버튼이 오른쪽 끝에서 잘려 보였어요. 화면 폭을 직접 물어보니 500이었어요. 500px로 그린 뒤 360px만 잘라 낸 사진이었던 거예요. 진짜로 360px로 그리는 브라우저로 다시 찍었어요.

$ "Google Chrome" --headless=new --window-size=360,740 --dump-dom file:///tmp/fe-w.html
<html><head><script>document.write("w="+innerWidth)</script></head><body>w=500</body></html>

$ chrome-headless-shell --hide-scrollbars --window-size=360,740 --screenshot=shots/before-360.png file://<project-root>/index.html
9885 bytes written to file shots/before-360.png
360px 화면의 상품 검색. 파란 버튼이 한 줄을 다 차지해서 왼쪽 입력창이 좁아지고 안내 문구가 ‘상품명을 입’에서 잘렸어요.
고치기 전, 진짜 360px 화면 (위쪽만 잘라 보여 줘요)

디자인 기준 검사

5단계

버튼 색도 살펴봐요. 스킬에 든 토큰 검사가 DESIGN.md에 없는 색 #3b82f6을 찾아냈어요. 기준에 있는 --color-primary를 써야 해요.

$ node "$FRONTEND_SKILL_DIR/scripts/ds-compliance.mjs" DESIGN.md src/tokens.css src/app.css
{
  "ok": false,
  "design": "DESIGN.md",
  "base": 4,
  "declaredColors": 5,
  "counts": {
    "undeclared-color": 1
  },
  "violations": [
    {
      "file": "src/app.css",
      "line": 4,
      "kind": "undeclared-color",
      "value": "#3b82f6",
      ...
    }
  ]
}
# 종료 코드 1

원인 고치기

6단계

원인은 줄바꿈을 막은 버튼이에요. 버튼이 줄어들 수 있게 하고 폭은 40%까지로 막아요. 한국어 단어는 쪼개지 않고 줄을 바꾸게 해요. 색은 기준의 토큰으로 바꿔요. 쓰던 CSS 한 줄만 고쳐요.

 /* src/app.css 4번째 줄 */
-.search button { flex: 0 0 auto; white-space: nowrap; padding: 12px 16px; font-size: 16px; color: var(--color-on-primary); background: #3b82f6; border: 0; }
+.search button { flex: 0 1 auto; max-width: 40%; white-space: normal; word-break: keep-all; padding: 12px 16px; font-size: 16px; color: var(--color-on-primary); background: var(--color-primary); border: 0; }

같은 조건으로 다시 찍기

7단계

같은 브라우저, 같은 360px로 다시 찍어요. 버튼 글자가 두 줄로 바뀌고 입력창 안내 문구가 다 보여요. 그다음 두 사진을 비교해요.

고치기 전: 버튼이 한 줄을 차지해 입력창 안내 문구가 잘렸어요.
고치기 전
고친 뒤: 버튼 글자가 ‘지금 바로 전체 / 상품 검색하기’ 두 줄로 바뀌고 입력창에 ‘상품명을 입력하세요’가 다 보여요.
고친 뒤
$ node "$FRONTEND_SKILL_DIR/scripts/visual-diff.mjs" shots/before-360.png shots/after-360.png --json
{
  "dimensionsMatch": true,
  "width": 360,
  "height": 740,
  "diffPixels": 16864,
  "diffRatio": 0.0633033033033033,
  "similarityScore": 94,
  "alphaChannelIntact": true,
  "hotspots": [
    { "gridX": 5, "gridY": 1, "x": 225, "y": 92, "width": 45, "height": 93, "diffRatio": 0.6734299516908212 },
    ...
  ]
}
# 바뀐 칸 8개가 모두 gridY 1, 검색 폼 줄이에요

점수는 판정이 아니에요

규칙 8

94점은 “얼마나, 어디가 달라졌는지”만 알려 줘요. 이 스크립트는 점수가 몇 점이든 종료 코드 0으로 끝나요. 판정은 사람이 두 화면을 보고 내려요. 같은 화면을 두 번 찍으면 100점이 나오는 것도 확인했어요.

$ node "$FRONTEND_SKILL_DIR/scripts/visual-diff.mjs" shots/before-360.png shots/before-360-again.png --json
{
  "dimensionsMatch": true,
  "width": 360,
  "height": 740,
  "diffPixels": 0,
  "diffRatio": 0,
  "similarityScore": 100,
  "alphaChannelIntact": true,
  "hotspots": []
}

스크립트 머리말에도 적혀 있어요: “이 JSON은 리뷰할 곳을 겨누는 증거일 뿐 판정이 아니다. 99점도 가짜나 깨진 화면을 숨길 수 있다.”

디자인 기준 다시 검사

5단계

색을 토큰으로 바꾼 뒤 같은 검사를 다시 돌려요. 이번에는 통과예요.

$ node "$FRONTEND_SKILL_DIR/scripts/ds-compliance.mjs" DESIGN.md src/tokens.css src/app.css
{
  "ok": true,
  "design": "DESIGN.md",
  "base": 4,
  "declaredColors": 5,
  "counts": {},
  "violations": []
}
# 종료 코드 0

실행 폴더에 모으기

8단계

실행마다 폴더를 하나 만들고 전후 사진, 비교 결과, VISUAL_QA.md를 거기 모아요. 끝으로 파일이 모두 폴더 안에 제대로 있는지 확인해요.

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" create search-button-overflow
.superloopy/evidence/frontend/20261013T070825Z-search-button-overflow

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" verify .superloopy/evidence/frontend/20261013T070825Z-search-button-overflow VISUAL_QA.md before-360.png after-360.png visual-diff.json
.superloopy/evidence/frontend/20261013T070825Z-search-button-overflow
# VISUAL_QA — 검색 버튼 라벨 (360px)

- Viewport: 360x740, chrome-headless-shell (innerWidth=360 확인)
- Before: before-360.png — 라벨이 한 줄을 차지해 입력창이 ~104px로 눌리고 placeholder가 "상품명을 입"에서 잘림
- After: after-360.png — 라벨이 두 줄로 줄바꿈, 버튼 폭 40% 상한, placeholder 전체 노출
- visual-diff.json: similarityScore 94, hotspot 전부 검색 폼 행
- 토큰: ds-compliance ok=true (#3b82f6 → var(--color-primary))
- 판정: PASS (사람 눈으로 두 스크린샷 비교 후 기록)

루프에 연결하고 영수증 남기기

8단계

이번엔 Superloopy 루프 안에서 했어요. 기준 C001은 CSS 규칙을 확인하는 명령으로, C002는 VISUAL_QA.md 파일로 증명해요. 파일 증거에는 “명령으로 다시 돌릴 수 있으면 그게 더 좋다”는 경고가 붙어요.

$ superloopy loop prove -- node scripts/check-button-fit.mjs
superloopy prove: G001/C001 -> pass (.superloopy/evidence/G001-C001-capture.txt)

$ superloopy loop evidence --goal-id G001 --criterion-id C002 --status pass \
    --artifact .superloopy/evidence/frontend/20261013T070825Z-search-button-overflow/VISUAL_QA.md
superloopy evidence: G001/C002 -> pass

$ superloopy loop check
superloopy check: ok
Evidence summary: 2 artifact-backed criteria, 0 unresolved, 0 invalid

Warnings:
- manual-proof: G001/C002 is passed with artifact-only proof; prefer command-backed proof when feasible.

$ superloopy loop finish --evidence "C001 check-button-fit pass; C002 VISUAL_QA.md at 360px" \
    --artifact .superloopy/evidence/gate.json --notes "criteria reviewed"
superloopy finish: complete
일꾼 답변의 끝
버튼 글자가 360px에서 두 줄로 바뀌었어요. 전후 스크린샷을 남겼어요.
SUPERLOOPY_EVIDENCE: .superloopy/evidence/frontend/20261013T070825Z-search-button-overflow/VISUAL_QA.md

증거가 만들어지는 과정과 생김새 자세히 보기

명령 출력과 스크린샷은 Superloopy v0.23.1로 연습용 웹 프로젝트에서 실제로 실행한 결과예요. 대화 문장과 확인 메모는 이해를 돕기 위해 꾸몄어요. VISUAL_QA.md는 두 스크린샷을 보고 직접 썼어요.

SUPERLOOPY · THE CREW

일을 나눠 맡는여섯 명의 크루.

큰 작업은 여섯 역할로 나눠요. 각자 한 가지 일만 맡고 끝나면 증거 영수증을 남겨요.

06 ROLES, ONE LOOP

THE CREW DOES THE WORK. THE LOOP CHECKS IT. 올리면 반짝여요 · 누르면 뒤집혀요

증거

증거는 이렇게 만들어지고 이렇게 생겼어요

AI가 “화면 고쳤어요”라고 말하는 것만으로는 아무것도 증명되지 않아요. 프론트엔드 스킬은 실행마다 증거 폴더를 하나 만들고 진짜로 그려진 화면과 확인 기록을 거기 모아요. 이 장의 출력은 Superloopy v0.23.1을 연습용 웹 프로젝트에서 실제로 실행해서 얻은 그대로예요.

쉽게 말하면여권 사진은 사진관에서 실제 얼굴을 찍어야 해요. 그림을 그려 내면 받아 주지 않죠. 화면 증거도 같아요. 진짜로 그려진 화면이어야 하고 어디서 어떻게 찍었는지 적혀 있어야 해요.

1만들어지는 과정

실행 폴더를 하나 만들어요

스킬에 든 evidence-root.mjs가 UTC 시각과 짧은 이름을 붙인 폴더를 만들어요. 이름은 영문 소문자와 숫자를 하이픈 하나로 이은 48자 이하예요. 그래서 맥, 윈도우, 리눅스 어디서나 같은 경로가 돼요.

스크립트는 스킬 폴더(FRONTEND_SKILL_DIR)에 들어 있어요. 우리 프로젝트 쪽에는 없어요. 폴더 id를 따로 지어내지 않고 스크립트가 돌려준 경로를 그대로 써요.

실제 실행

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" create search-button-overflow
.superloopy/evidence/frontend/20261013T070825Z-search-button-overflow

실제 실행: 대문자와 밑줄이 든 이름

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" create Search_Button
evidence-root: slug must be 1-48 lowercase ASCII letters/digits joined by single hyphens and must not be a Windows reserved name
# 종료 코드 2

진짜로 그려진 화면을 찍어요

배포용 빌드를 우리 대상의 진짜 브라우저로 열고 찍어요. 찍기 전에 화면 폭이 정말 그 폭인지도 확인해요.

이번에 실제로 겪은 일이에요. macOS의 Chrome 155 headless는 360px을 달라고 해도 500px로 그린 뒤 잘라 냈어요. 그 사진에서는 버튼이 끝에서 잘린 것처럼 보였고 고친 뒤에도 망가진 것처럼 보였어요. 폭을 확인하지 않았다면 틀린 증거를 남겼을 거예요. 이 연습은 headless 셸로 찍었어요. 실제 일에서는 지원 대상 목록에 있는 진짜 브라우저 빌드로 찍고 그 빌드 번호를 적어요.

실제 실행: 화면 폭 물어보기

$ "Google Chrome" --headless=new --window-size=360,740 --dump-dom file:///tmp/fe-w.html
<html><head><script>document.write("w="+innerWidth)</script></head><body>w=500</body></html>

$ chrome-headless-shell --window-size=360,740 --dump-dom file:///tmp/fe-w.html
<html><head><script>document.write("w="+innerWidth)</script></head><body>w=360</body></html>

실제 실행: 진짜 360px로 찍기

$ chrome-headless-shell --hide-scrollbars --window-size=360,740 --screenshot=shots/after-360.png file://<project-root>/index.html
11277 bytes written to file shots/after-360.png

전후를 비교해서 볼 곳을 찾아요

visual-diff.mjs는 두 PNG를 비교해서 다른 픽셀 수와 8×8 칸 중 많이 달라진 곳을 알려 줘요. 이번 변경은 바뀐 칸이 모두 검색 폼 줄이었어요. 다른 곳은 그대로라는 뜻이에요.

점수가 몇 점이든 종료 코드는 0이에요. 차이를 담은 그림 파일도 만들지 않아요. 판정은 사람이 화면, 글자, 상태, 포커스, 넘침을 직접 보고 내려요.

실제 실행: 안티에일리어싱 차이를 32까지 봐줄 때

$ node "$FRONTEND_SKILL_DIR/scripts/visual-diff.mjs" shots/before-360.png shots/after-360.png --tolerance 32
{
  "dimensionsMatch": true,
  "width": 360,
  "height": 740,
  "diffPixels": 8746,
  "diffRatio": 0.03283033033033033,
  "similarityScore": 97,
  "alphaChannelIntact": true,
  "hotspots": [
    { "gridX": 3, "gridY": 1, "x": 135, "y": 92, "width": 45, "height": 93, "diffRatio": 0.4632850241545894 },
    ...
  ]
}

실제 실행: PNG가 아닌 파일

$ node "$FRONTEND_SKILL_DIR/scripts/visual-diff.mjs" shots/before-360.png index.html
Not a PNG file (bad signature).
# 종료 코드 1

디자인 기준에 없는 값을 찾아요

ds-compliance.mjs는 DESIGN.md에 적힌 색과 간격 기본값을 읽어요. 그리고 고친 파일에서 기준에 없는 hex 색과, 여백·간격·위치 속성에 쓴 px 값 중 기본값의 배수가 아닌 것을 찾아요. 0과 1px은 늘 괜찮아요.

스크립트 머리말에 적혀 있듯 색과 간격 일부만 보는 검사예요. 통과해도 CSS 변수와 색 함수, 글꼴, 컴포넌트 규칙, 접근성, 디자인 시스템을 잘 쓰는지는 증명하지 않아요. 검사를 돌리려고 DESIGN.md를 새로 만들지도 않아요.

실제 실행: 고치기 전과 후

$ node "$FRONTEND_SKILL_DIR/scripts/ds-compliance.mjs" DESIGN.md src/tokens.css src/app.css
{ "ok": false, ... "counts": { "undeclared-color": 1 }, "violations": [ { "file": "src/app.css", "line": 4, "kind": "undeclared-color", "value": "#3b82f6", ... } ] }
# 종료 코드 1

$ node "$FRONTEND_SKILL_DIR/scripts/ds-compliance.mjs" DESIGN.md src/tokens.css src/app.css
{ "ok": true, "design": "DESIGN.md", "base": 4, "declaredColors": 5, "counts": {}, "violations": [] }
# 종료 코드 0

본 것을 VISUAL_QA.md에 적어요

모양이 바뀌었거나, 동작이 화면 상태나 배치를 바꿨을 때 써요. 기준, 실제 대상, 상태, 화면 폭, 브라우저와 OS와 입력 방식, 보인 차이, 원인, 결과, 한계를 적어요.

눈에 보이는 결과가 없는 동작 변경이면 꾸밈용 스크린샷 대신 동작이나 접근성 증거를 남겨요.

연습용으로 두 스크린샷을 보고 쓴 VISUAL_QA.md

# VISUAL_QA — 검색 버튼 라벨 (360px)

- Viewport: 360x740, chrome-headless-shell (innerWidth=360 확인)
- Before: before-360.png — 라벨이 한 줄을 차지해 입력창이 ~104px로 눌리고 placeholder가 "상품명을 입"에서 잘림
- After: after-360.png — 라벨이 두 줄로 줄바꿈, 버튼 폭 40% 상한, placeholder 전체 노출
- visual-diff.json: similarityScore 94, hotspot 전부 검색 폼 행
- 토큰: ds-compliance ok=true (#3b82f6 → var(--color-primary))
- 판정: PASS (사람 눈으로 두 스크린샷 비교 후 기록)

실제 실행: 폴더 안 파일 확인

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" verify .superloopy/evidence/frontend/20261013T070825Z-search-button-overflow VISUAL_QA.md before-360.png after-360.png visual-diff.json
.superloopy/evidence/frontend/20261013T070825Z-search-button-overflow

루프가 있으면 기준에 연결해요

loop guide가 돌려준 목표와 기준 id에 증거를 하나씩 연결해요. 명령으로 확인할 수 있는 기준은 loop prove로, 파일로만 남는 증거는 loop evidence로 연결해요.

파일 증거에는 “명령으로 다시 돌릴 수 있으면 그쪽이 낫다”는 경고가 붙어요. 끝낼 때 Superloopy가 다시 돌려 볼 수 있는 건 명령 증거뿐이거든요. 루프가 없을 때는 이 명령들을 쓰지 않아요.

실제 실행

$ superloopy loop prove -- node scripts/check-button-fit.mjs
superloopy prove: G001/C001 -> pass (.superloopy/evidence/G001-C001-capture.txt)

$ superloopy loop evidence --goal-id G001 --criterion-id C002 --status pass \
    --artifact .superloopy/evidence/frontend/20261013T070825Z-search-button-overflow/VISUAL_QA.md \
    --notes "360px before/after screenshots compared; label wraps, input no longer crushed"
superloopy evidence: G001/C002 -> pass

$ superloopy loop check
superloopy check: ok
Evidence summary: 2 artifact-backed criteria, 0 unresolved, 0 invalid

Warnings:
- manual-proof: G001/C002 is passed with artifact-only proof; prefer command-backed proof when feasible.

C001을 증명한 명령의 기록 (G001-C001-capture.txt)

status: pass
exitCode: 0
command: ["node","scripts/check-button-fit.mjs"]
[stdout]
PASS button may shrink (flex-shrink 1)
PASS button width capped (max-width)
PASS label may wrap (no nowrap)
PASS Korean words kept whole (keep-all)

끝내기 전에 한 번 더, 마지막엔 영수증 줄

loop finish는 명령으로 연결한 기준을 그 자리에서 다시 돌려 보고 지금도 통과해야 끝내요. 이번에도 check-button-fit.mjs를 다시 돌려 같은 PASS 네 줄을 얻었어요.

일꾼 에이전트는 답변 마지막 줄을 SUPERLOOPY_EVIDENCE: <경로>로 끝내요. 줄이 없거나 증거 폴더 밖을 가리키면 루프가 세 번까지 다시 일하게 해요.

실제 실행

$ superloopy loop finish --evidence "C001 check-button-fit pass; C002 VISUAL_QA.md at 360px" \
    --artifact .superloopy/evidence/gate.json --notes "criteria reviewed"
superloopy finish: complete
# 다시 돌린 기록: .superloopy/evidence/audit/G001-C001-rerun.txt (status: pass)

실제 실행: 영수증 줄이 있을 때와 없을 때

$ echo '{"hook_event_name":"SubagentStop","agent_type":"forge","last_assistant_message":"Button label now wraps at 360px; screenshots attached.\nSUPERLOOPY_EVIDENCE: .superloopy/evidence/frontend/20261013T070825Z-search-button-overflow/VISUAL_QA.md"}' | superloopy hook subagent-stop
# 출력 없음: 받아 줬어요

$ echo '{"hook_event_name":"SubagentStop","agent_type":"forge","last_assistant_message":"Done, the button looks fine now."}' | superloopy hook subagent-stop
{"decision":"block","reason":"Superloopy evidence receipt missing or invalid.\nAttempt 1 of 3. ..."}

2생김새

폴더 모양 (실제 결과)

.superloopy/
├── audit-state.json  끝낼 때 다시 돌린 기준과 입력 해시
├── brief.md          루프에 준 부탁
├── goals.json        목표와 기준, 기준마다 연결된 증거
├── ledger.jsonl      무슨 일이 언제 있었는지 한 줄씩
├── subagent-stop/    일꾼 재시도 횟수
└── evidence/
    ├── G001-C001-capture.txt  C001 명령의 실행 기록
    ├── gate.json     loop finish가 남긴 게이트 요약
    ├── report.md     끝낸 뒤 쓴 증거 보고서
    ├── audit/
    │   └── G001-C001-rerun.txt  끝낼 때 다시 돌린 기록
    └── frontend/
        └── 20261013T070825Z-search-button-overflow/
            ├── VISUAL_QA.md      C002에 연결
            ├── before-360.png    고치기 전
            ├── after-360.png     고친 뒤
            └── visual-diff.json  비교 결과
  • 실행 폴더 이름은 <UTC 시각>-<짧은 이름>이에요.
  • 슬라이드 스킬도 같은 스크립트로 .superloopy/evidence/slides/ 아래에 폴더를 만들어요.
  • visual-diff.json은 스크립트 출력을 직접 파일로 저장한 거예요. 스크립트는 파일을 쓰지 않아요.

VISUAL_QA.md에 담기는 것

  1. 어디서실제 대상, 브라우저 빌드, OS, 입력 방식, 화면 폭이에요.
  2. 무엇과 비교기준이 된 화면이나 승인된 시안, 그리고 상태예요.
  3. 무엇이 보였나보인 차이와 그 원인이에요.
  4. 결론과 한계결과, 그리고 확인하지 못한 점이에요.

Qt 화면이면 Qt 버전, 스타일, 화면 배율, 그래픽 백엔드, 찍은 방법 같은 칸이 더 붙어요.

루프 쪽 기록: gate.json (실제 결과)

{
  "status": "passed",
  "createdAt": "2026-10-13T07:10:01.394Z",
  "artifacts": [
    ".superloopy/evidence/G001-C001-capture.txt",
    ".superloopy/evidence/frontend/20261013T070825Z-search-button-overflow/VISUAL_QA.md"
  ],
  "summary": {
    "goals": { "total": 1, "pending": 0, "in_progress": 1, "complete": 0, "failed": 0, "blocked": 0 },
    "criteria": { "total": 2, "pass": 2, "pending": 0, "fail": 0, "blocked": 0 },
    "aggregateComplete": false
  },
  "notes": "criteria reviewed"
}

완료로 기록되기 바로 전에 찍은 요약이라 in_progress로 보여요. 완료는 바로 다음 장부 줄에 적혀요.

장부: ledger.jsonl (실제 결과, 줄임)

{"at":"2026-10-13T07:08:53.591Z","kind":"plan_created","mode":"light","goals":1}
{"at":"2026-10-13T07:08:53.600Z","kind":"goal_started","goalId":"G001","attempt":1}
{"at":"2026-10-13T07:09:53.749Z","kind":"evidence_passed","goalId":"G001","criterionId":"C001",...}
{"at":"2026-10-13T07:09:57.582Z","kind":"evidence_passed","goalId":"G001","criterionId":"C002",...}
{"at":"2026-10-13T07:10:01.394Z","kind":"quality_gate_passed","artifact":".superloopy/evidence/gate.json",...}
{"at":"2026-10-13T07:10:01.537Z","kind":"aggregate_completed","goalId":"G001","status":"complete",...}
{"at":"2026-10-13T07:10:01.546Z","kind":"evidence_report_written","artifact":".superloopy/evidence/report.md",...}
evidence_passed
기준 하나에 증거가 연결된 순간이에요.
quality_gate_passed
끝낼 때 다시 돌려 본 검사가 통과했어요.
aggregate_completed
모든 목표가 끝났다고 기록했어요.

3증거를 지키는 장치

일부러 틀리게 해 봤어요. 아래 출력도 모두 실제 결과예요.

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" create con
evidence-root: slug must be 1-48 lowercase ASCII letters/digits joined by single hyphens and must not be a Windows reserved name

거절con, nul, com1 같은 이름은 윈도우에서 폴더로 만들 수 없어요. 어느 운영체제에서나 같은 경로가 되도록 처음부터 막아요.

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" create x mobile
evidence-root: lane must be frontend or slides

거절폴더 종류는 frontend와 slides 두 가지예요. 휴대폰 화면도 frontend 아래에 모아요.

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" verify .superloopy/evidence/frontend/20261013T070825Z-search-button-overflow ../../gate.json
evidence-root: evidence file escapes its run root: ../../gate.json

거절실행 폴더 밖에 있는 파일은 그 실행의 증거로 셀 수 없어요.

$ node "$FRONTEND_SKILL_DIR/scripts/evidence-root.mjs" verify .superloopy/evidence/frontend/today-search VISUAL_QA.md
evidence-root: evidence root must match .superloopy/evidence/<frontend|slides>/YYYYMMDDTHHMMSSZ-<portable-slug>

거절손으로 지은 폴더 이름은 받아 주지 않아요. 스크립트가 만든 이름 규칙을 따라야 해요.

$ echo '{"hook_event_name":"SubagentStop","agent_type":"forge","last_assistant_message":"SUPERLOOPY_EVIDENCE: /etc/hosts"}' | superloopy hook subagent-stop
{"decision":"block","reason":"Superloopy evidence receipt missing or invalid.\nAttempt 2 of 3. ..."}

거절영수증 줄이 있어도 증거 폴더 밖을 가리키면 받아 주지 않아요. 앞에서 영수증 없이 끝내려 한 것까지 세어서 두 번째 시도로 기록됐어요.

코드에서 확인한 장치같은 실행 폴더가 이미 있으면 새로 만들지 않아요. 경로 중간에 링크(심볼릭 링크)가 있거나 비어 있는 파일은 증거로 받지 않아요. 이 세 가지는 이번에 직접 돌려 보지는 않았어요.

증거가 증명하는 것과 증명하지 못하는 것

여권 사진은 그날 얼굴을 보여 줘요. 그 사람이 친절한지는 알려 주지 않죠. 화면 증거도 같아요.

코드가 확인해요
  • 실행 폴더의 이름과 자리가 규칙에 맞는지 봐요.
  • 증거 파일이 그 폴더 안에 있고 비어 있지 않은지 봐요.
  • 루프 안에서는 끝낼 때 명령으로 연결한 기준을 다시 돌려서 지금도 통과하는지 봐요.
  • 일꾼의 영수증 줄이 증거 폴더 안 실제 파일을 가리키는지 봐요.
확인하지 못해요
  • VISUAL_QA.md의 판정이 맞는지는 보지 않아요. 사람이나 AI가 쓴 기록이에요.
  • 비교 점수가 높다고 화면이 멀쩡하다는 뜻은 아니에요.
  • 토큰 검사를 통과해도 디자인 기준 전체를 지켰다는 뜻은 아니에요.
  • 스크린샷은 그 순간의 모습만 보여 줘요. 키보드 이동, 스크린 리더, 움직임은 따로 확인해야 해요.

이 스킬이 AI가 지어내는 말을 없애 주지는 못해요. 대신 어디서 무엇을 찍고 어떤 명령을 돌렸는지 적게 하니까, 리뷰어가 같은 화면을 열어 보면 금방 가려낼 수 있어요.

웹 프로젝트라면

.superloopy/를 .gitignore에 넣어 두면 증거는 각자 컴퓨터에만 남고 PR diff에는 들어가지 않아요. 리뷰어와 나누고 싶다면 VISUAL_QA.md 요약과 전후 스크린샷을 PR 본문에 붙여 주세요.

실행 환경: Superloopy v0.23.1(커밋 12b65e5)의 evidence-root.mjs, ds-compliance.mjs, visual-diff.mjs와 src/cli.js를 연습용 git 프로젝트에서 Node 22.19로 직접 실행했어요. 스크린샷은 연습용으로 chrome-headless-shell 151에서 360×740으로 찍었어요. 스킬이 요구하는 ‘지원하는 진짜 브라우저’ 확인을 대신하지는 않아요. 화면에는 설치된 superloopy 명령 이름으로 적었고 절대 경로와 긴 JSON은 줄였어요. 시각은 UTC예요.

심장

8가지 규칙, 카드로 보기

스킬 안내서에서 가장 자주 쓰이는 규칙 여덟 개를 골랐어요. 카드를 누르면 뒷면에 실제 규칙과 웹 화면 예시가 나와요. 앞면은 열 살 동생에게, 뒷면은 옆자리 동료에게 설명하듯 적었어요.

1

눌리는 버튼은 진짜로 일해야 해요

엘리베이터 버튼에 불만 들어오고 엘리베이터가 오지 않으면 고장이죠. 불이 들어온 건 끝난 게 아니에요.

한 줄 규칙보이고 눌리면, 결과도 진짜로

실제 규칙: 보이는 버튼은 약속한 결과를 낸다

보이고 눌리는 버튼은 약속한 결과를 실제로 내야 해요. 핸들러를 부르거나, 토스트나 스피너를 띄우거나, 가짜 어댑터에 닿은 것은 끝난 게 아니에요. 저장이 확정되기 전에 성공이라고 알리지 않아요. 거짓 성공은 나중에 갚을 UX 빚으로 넘길 수 없어요.

웹 화면 예시“저장했어요!” 토스트가 떴는데 API는 500을 돌려줬다면 결함이에요. 입력은 그대로 두고 실패를 보여 주고 다시 시도할 수 있게 해요.

2

확인할 화면은 우리 대상에서 골라요

시험 범위는 우리 교과서에서 정해요. 남들이 많이 푼 문제집에서 정하지 않죠.

한 줄 규칙390, 768, 1280은 표본이지 증명이 아니에요

실제 규칙: 확인 범위는 대상에서 끌어낸다

브라우저, OS, 입력 방식은 browserslist 같은 설정, 패키지 조건, 제품 지원 정책에서 정해요. 화면 폭은 실제 브레이크포인트, 컨테이너, 내용이 가장 길거나 짧을 때에서 정해요. 390, 768, 1280px은 쓸모 있는 표본이지만 어디서나 통하는 증명은 아니에요. 웹의 최소 기준은 배포용 빌드, 바뀐 흐름, 옆 화면 회귀, 지원하는 진짜 브라우저 하나예요.

웹 화면 예시브레이크포인트가 900px이면 768px이 아니라 900px 바로 아래와 위에서 확인해요.

3

모양이 바뀐 곳만 다시 재요

벽지만 바꿨다고 집 설계도를 다시 그리지 않아요. 방을 넓혔다면 다시 재야죠.

한 줄 규칙배치가 바뀔 때만 배치 확인, 스크롤 주인은 하나씩

실제 규칙: 배치는 모양과 이동이 바뀔 때만

글자, 색, 접근성 이름, 데이터, 동작만 바뀌면 Layout impact: unchanged와 이유를 적어요. 영역, 크기, 스크롤, 넘침, 읽는 순서가 바뀌면 배치 안내서로 확인해요. 할 일이 다른 스크롤 영역이 여럿인 건 괜찮지만 주인이 따로 없는 이중 스크롤은 결함이에요. 멈춘 스크린샷으로는 스크롤 주인과 이동 순서를 증명하지 못해요.

웹 화면 예시메일 목록과 읽기 창이 따로 스크롤되는 건 괜찮아요. 페이지가 스크롤되는데 모달 본문도 이유 없이 따로 스크롤되면 결함이에요.

4

멈춘 사진으로는 움직임을 증명 못 해요

공을 잘 차는지는 사진 한 장으로 알 수 없어요. 차는 모습을 직접 봐야 하죠.

한 줄 규칙반복, 중간에 끊기, 되돌리기까지 해 봐요

실제 규칙: 정지 화면은 움직임의 증거가 아니다

기본, 반복, 중간에 끊기, 거꾸로, 목표 바꾸기, 취소, 움직임 줄이기 설정까지 실제로 해 봐요. 빠르게 두 번 눌러도 명령이 두 번 들어가면 안 돼요. 중간에 끊으면 애니메이션 콜백 대신 가장 최근의 실제 상태로 끝나야 해요. 움직임을 줄인 설정에서도 결과, 상태, 포커스는 그대로 전해져야 해요.

웹 화면 예시애니메이션이 있는 “장바구니 담기”를 두 번 빨리 눌러도 하나만 담겨야 해요. prefers-reduced-motion에서는 가로로 흐르는 섹션이 보이는 세로 목록으로 바뀌어야 해요.

5

점수를 위해 경험을 깎지 않아요

달리기 기록을 위해 코스를 줄이면 반칙이죠. 기록은 다리를 키워서 줄여야 해요.

한 줄 규칙Lighthouse 점수 꼼수 금지

실제 규칙: 점수는 구조에서 얻는다

INP를 위한 애니메이션 빼기, LCP를 위해 대표 이미지를 자리표시로 바꾸기, JS 끄기, 검사를 피하려 display:none 쓰기는 고침이 아니라 실패예요. 개발 서버나 headless 셸 점수 대신 진짜 브라우저로 배포용 빌드를 재요. 3~5번 재서 중앙값을 쓰고 원본 JSON을 남겨요. 한 번 재고 이겼다고 하지 않아요.

웹 화면 예시대표 이미지 때문에 LCP가 느리다면 이미지 파이프라인과 번들 나누기로 고쳐요. 페이지는 빠르면서 기능도 그대로여야 해요.

6

홍보 페이지엔 진짜 자료만 써요

가게 앞 사진은 우리 가게 음식이어야 해요. 남의 가게 사진을 걸면 안 되죠.

한 줄 규칙지어낸 숫자와 가짜 화면 금지, 다듬기는 한 번

실제 규칙: 정직한 자료, 그리고 한 번의 다듬기

진짜 제품 화면인 척하는 div 목업, 허락 없는 로고와 지어낸 지표·후기, 내보낸 자리표시 문구는 결함이에요. 습관처럼 나오는 보라색 그라데이션, 반사적으로 고른 기본 글꼴, 어두운 배경 위 가운데 정렬 히어로 같은 기본값은 일부러 바꾸거나, 그렇게 둔 근거를 적어요. 다듬기는 방향을 한 번 읽고 딱 한 번만 해요. 다듬는 척하며 리디자인을 끼워 넣지 않아요.

웹 화면 예시“10,000개 팀이 써요” 문구와 가짜 로고가 늘어선 랜딩 페이지라면 빼거나 진짜로 허락받은 자료로 바꿔요.

7

살아 있는 사이트는 몰래 바꾸지 않아요

가게 인테리어를 새로 해도 주소와 간판은 손님에게 알리고 바꾸죠.

한 줄 규칙주소, 메뉴 이름, 폼 이름은 허락 받고

실제 규칙: 운영 중인 사이트의 약속을 지킨다

URL 구조와 slug, 주요 메뉴 이름, 폼 필드 이름, 로고와 법적·동의·쿠키 문구는 분명한 허락 없이 바꾸지 않아요. 원래 보라색인 브랜드는 보라색으로 남아요. 제안하기 전에 REDESIGN_AUDIT.md부터 써요. 손대는 순서는 글꼴, 간격, 색, 움직임, 히어로, 블록 통째 교체예요.

웹 화면 예시스타일만 바꾸다 name="email_address"를 email로 바꾸면 그 이름을 쓰던 연동이 깨질 수 있어요. 쓰는 쪽을 먼저 찾고 허락을 받아요.

8

만든 그림은 방향이지 정답이 아니에요

요리 잡지 사진은 참고예요. 똑같은 접시가 주방에 있다는 뜻은 아니죠.

한 줄 규칙시안은 방향, 그림 속 글자는 문구가 아니에요

실제 규칙: 참고 그림의 권한부터 나눈다

참고 그림이 지금 화면의 작은 변경인지, 탐색용 시안인지, 승인된 구현 기준인지 먼저 나눠요. 그림을 만든 것과 승인받은 것은 달라요. 생성한 그림 속 글자는 문구의 근거가 아니에요. 그림이나 스크린샷은 쓰기 쉬움, 접근성, 브랜드, 읽는 순서, 구현이 맞다는 증거가 못 돼요. 픽셀 비교도 다른 곳을 찾을 뿐 판정하지 못해요.

웹 화면 예시생성한 히어로 시안에 없는 메뉴와 숫자가 그려져 있으면, 승인된 배치와 구성만 가져오고 지어낸 버튼과 숫자는 버려요.

퀴즈

멈춤 퀴즈: AI라면 계속할까요, 멈출까요?

스킬은 허락 없이 넓히거나 증거 없이 끝내지 않도록 만들어졌어요. 상황을 읽고 골라 보세요.

0 / 8 맞혔어요

  1. “GitHub처럼 보이게 해 줘”라는 부탁을 받았어요. 프로젝트는 Primer를 쓰지 않아요.

    비슷해 보이는 것은 계약이 아니에요. “GitHub처럼”만으로는 Primer를 들일 이유가 되지 않아요. 브랜드 참고 자료 하나를 분위기 참고로만 쓰고 지금 쓰는 디자인 기준 안에서 만들어요.

  2. 이미 Primer React를 쓰는 프로젝트인데 필요한 패키지 하나가 없어요. npm install을 바로 할까요?

    새 패키지는 영향을 설명하고 분명한 허락을 받은 뒤에만 설치해요. 조언만 부탁받았다면 확인한 명령 하나를 보여 주기만 하고 실행하지 않아요.

  3. 스킬 이름도 루피도 없이 “설정 화면 UI가 좀 이상해요”라는 메시지가 왔어요. 프론트엔드 스킬을 켤까요?

    UI라는 단어나 눈에 보이는 증상만으로는 켜지지 않아요. 같은 문장이라도 맨 앞에 루피를 붙이면 켜져요.

  4. 아이콘 버튼의 aria-label이 틀려서 고치기로 했어요. DESIGN.md, 스크린샷, VISUAL_QA.md가 꼭 있어야 할까요?

    모양이 바뀌지 않는 좁은 수정이에요. Design impact: unchanged와 Visual evidence: not applicable를 이유와 함께 적고 동작·접근성·회귀 증거만 남겨요.

  5. 회사 내부 관리자 화면의 표 스타일을 다듬어요. 홍보 페이지용 ‘뻔한 AI 디자인 검사’와 다듬기를 꼭 돌려야 할까요?

    그 두 안내서는 홍보, 캠페인, 새 디자인 방향일 때만 펼쳐요. 로그인 뒤나 회사 내부 제품 화면은 지금의 디자인 시스템과 제품 관례를 따라요.

  6. 홍보 사이트를 리디자인하면서 메뉴 이름 “Pricing”을 “Plans”로 바꾸고 URL도 짧게 줄이려고 해요.

    URL과 주요 메뉴 이름은 몰래 바꾸면 안 되는 것들이에요. 겉모습을 크게 바꾸자는 말이 구조를 바꿔도 된다는 허락은 아니에요.

  7. Lighthouse 성능 점수가 84예요. 대표 영상을 정지 이미지 자리표시로 바꾸면 90을 넘겨요.

    점수를 위해 대표 이미지를 자리표시로 바꾸는 건 꼼수로 정해져 있어요. 90 아래는 외부 요인이 기록되고 받아들여지지 않는 한 막혀요. 점수는 구조에서 얻어요.

  8. Tauri 데스크톱 앱의 메뉴를 바꿨어요. 안쪽 웹 화면은 Chrome에서 스크린샷까지 통과했어요. 이제 끝났다고 할까요?

    웹 화면의 증거가 앱 껍데기를 대신 증명하지 못해요. 메뉴는 앱이 맡으니 앱 자동화 기록과 기기 정보가 따로 있어야 해요.

증거 읽기

증거를 정직하게 읽는 여섯 가지 습관

스킬은 무엇이 무엇을 증명하지 못하는지도 분명하게 적어 둬요. 리뷰할 때 바로 쓸 수 있는 것만 골랐어요.

비교 점수는 판정이 아니에요

99점도 가짜 화면이나 깨진 화면을 숨길 수 있어요. 점수는 어디를 볼지 알려 줄 뿐이에요. 화면 흐름, 글자와 번역, 상태, 포커스, 줄바꿈과 넘침, 움직임 줄이기 설정은 직접 봐요.

"similarityScore": 94,
# 종료 코드 0: 점수가 몇 점이든 같아요

사진은 그 순간만 증명해요

스크린샷은 그려진 상태를, 검사기는 자기가 검사하는 규칙만 증명해요. 키보드로 이동하는 순서, 스크롤 주인, 움직임은 사진으로 알 수 없어요.

캔버스 화면은 더 그래요. 사진만으로는 동작, 글자 입력, 스크린 리더가 읽는 내용을 알 수 없어요.

승인된 디자인이 쓰기 쉬운 화면은 아니에요

승인된 디자인은 의도한 겉모습과 그대로 만들었는지를 증명해요. 쓰기 쉬운지, 접근성, 성능, 개인정보, 플랫폼에 맞는지는 따로 확인해야 해요.

전문가가 훑어본 검토도 추측 증거예요. 실제 사용자가 해냈다는 증거는 아니에요.

공식 디자인 시스템도 접근성을 대신 지켜 주지 않아요

공식 시스템은 부품을 줄 뿐이에요. 설치하거나 옮긴 뒤에는 이름표, 의미 구조, 키보드, 포커스, 대비, 화면 상태를 우리 대상에서 다시 확인해요.

흉내 낸 화면은 한 칸씩 올려요

가짜 데이터나 흉내 낸 환경에서 된 기능은 진짜 대상에서 새 증거가 나왔을 때만 진짜로 올려요. 바로 옆 기능이 증명됐다고 따라 올라가지 않아요.

증명할 길이 없으면 확인 못 함이라고 적어요

증명할 방법이 없으면 막혔다고 하거나 확인 안 됨으로 남겨요. 더 그럴듯한 다른 증거로 바꿔치지 않아요. 받아들인 UX 빚이라도 실패나 미확인을 통과로 바꾸지 못해요.

효과

정말 효과가 있나요?

솔직하게 답할게요. 프론트엔드 스킬을 썼을 때 화면이 얼마나 나아지는지 잰 결과는 아직 저장소에 없어요.

지금 있는 것

  • 로컬 실험 한 번. Superloopy 프론트엔드 방식, Impeccable, 둘을 합친 방식을 같은 랜딩 페이지 과제로 비교하는 실험을 설계했어요. 그 실험은 합친 방향(새로움보다 읽기 쉬움을 앞에)을 고르는 데 쓰였어요. 결과 화면, 점수, 평가 출력은 공개하지 않았고 출시 증거로 쓰지 않는다고 적혀 있어요.
  • 테스트. 스킬 파일이 제대로 묶였는지, 경로 표를 바르게 고르는지 확인하는 테스트가 있어요. 이 테스트는 이 스킬로 만든 화면이 쓰기 쉬운지는 증명하지 않아요.
  • Qt Kanban 예제. Qt 경로로 만든 실행 가능한 시제품 예제예요. 제품 수준의 증거도, 전후 비교도 아니에요.
  • 이 페이지의 실행 기록. 스크립트 세 개와 루프가 이 페이지에 실린 대로 동작하는 건 직접 돌려서 확인했어요.
  • 재지 않은 것화면 결함이 줄었는지, 리뷰가 빨라졌는지, 시간이나 토큰이 얼마나 더 드는지 잰 결과가 없어요.
  • 싣지 않은 것로컬 실험의 숫자는 출시 증거로 쓰지 않으니 여기에도 싣지 않았어요.
  • 확인한 것잘못된 폴더 이름, 폴더 밖 파일, 영수증 없는 끝내기를 실제로 막는 걸 직접 봤어요.
  • 짐작대상마다 증거를 따로 모으니 확인할 일은 늘어날 거예요. 얼마나 느는지는 재지 않았어요.

설명서가 잘 묶였는지는 검사했지만 이 설명서를 따른 화면이 정말 더 좋아졌는지는 아직 아무도 재지 않았어요.

시작하기

우리 프로젝트에서 써 보기

  1. 설치해요 (한 번만)

    codex plugin marketplace add https://github.com/beefiker/superloopy
    codex plugin add superloopy@beefiker

    Codex를 다시 켜고 훅 승인을 물으면 승인해요. 설치가 잘 됐는지는 superloopy doctor --json으로 확인해요. Node.js 22 이상이 필요해요.

    /plugin marketplace add beefiker/superloopy
    /plugin install superloopy@beefiker
    /reload-plugins

    Claude Code 안에서 차례로 입력해요. Claude Code 2.1.280 이상이 필요해요. 훅 승인을 물으면 승인해요.

  2. 이름을 불러 부탁해요

    화면 버그 고치기 (Codex)

    $superloopy:superloopy-frontend 360px 휴대폰에서 검색 버튼 글자 때문에 입력창이 찌그러져요. 실제 화면으로 재현하고 고쳐 주세요.

    기능 더하기 (Claude Code)

    /superloopy:superloopy-frontend 설정 화면에 알림 끄기 스위치를 추가해 주세요. 우리 디자인 토큰을 쓰고 키보드 조작과 스크린 리더 이름까지 확인해 주세요.

    루프로 맡기기

    루피 상품 목록의 빈 상태와 오류 상태를 실제 브라우저에서 확인하고 고쳐 주세요.

    디자인 기준이 어디 있는지(토큰 파일, 디자인 시스템, DESIGN.md) 알려 주면 AI가 덜 헤매요.

    새 패키지가 필요하면 AI가 먼저 물어봐요. 허락하기 전에는 설치하지 않아요.

  3. 영수증을 받아요

    끝나면 실행 폴더 경로와 마지막 줄 SUPERLOOPY_EVIDENCE: ...를 받아요. 모양이 바뀐 일이면 VISUAL_QA.md와 전후 스크린샷부터 보면 빨라요. 비교 점수보다 화면을 직접 열어 보세요.