스타일 수렴: 버튼 하나에 CSS 여덟 벌은 그만
AI에게 기능을 열 개 연달아 시키면, 거의 똑같이 생긴 버튼 클래스가 여덟 개 쌓입니다. 재사용을 못하는 게 아니라, 대화가 새로 열릴 때마다 이미 있는 걸 모르는 거예요. 이 레슨에서는 스타일이 왜 증식하는지, 어떻게 깔끔히 걷어내는지, 어떤 차이는 남겨야 하는지 이야기합니다.
아래는 실제 프로젝트의 반복을 흉내 냅니다. 「기능 하나 더」를 누를 때마다, 새 대화를 열어 AI에게 페이지를 하나 시키는 것과 같아요. 버튼을 매번 어떻게 다루는지, 아래 숫자 네 개가 어떻게 오르는지 보세요.
프로젝트는 아직 비어 있어요. 아래 버튼을 눌러 반복을 시작하세요.
여덟 라운드 뒤에 이 버튼 더미를 보면, 뭘 고쳐야 할지 구분이 안 돼요 — 그게 「제각각」의 손맛이에요.
스타일을 반복해서 만드는 건 모델이 게으른 게 아니라, 구조적인 이유 세 가지가 겹친 결과예요. 이유를 알아야 어디에 게이트를 둘지 보입니다.
당신 CSS가 눈앞에 없어요
새 대화를 열면 컨텍스트에는 이번에 준 파일 몇 개만 있어요. 프로젝트에 이미 .btn-primary가 있다는 걸 알 길이 없으니, 요구대로 새로 씁니다.
새로 쓰는 게 옛것을 읽는 것보다 싸요
기존 스타일을 이해하려면 관련 파일을 다 봐야 하고, 고치면 다른 곳이 깨질까 봐 걱정해야 해요. 새 클래스 이름은 리스크 제로, 읽기 비용 제로 — 그건 AI의 최적해이지, 당신의 최적해가 아니에요.
망칠까 봐, 옆에 하나 더 둬요
그림자가 있는 버튼이 필요하면 원래 걸 고치기보다 .btn-primary-new를 씁니다 — 남이 쓰는 스타일을 고치는 건 고위험이라, 안전하지만 증식하는 길을 고른 거예요.
세 이유 모두 같은 곳을 가리켜요: 「이미 뭐가 있는지」 목록이 없어요. 이 목록을 프로젝트 규칙 파일에 넣으면 매 라운드 보이니까, 증식이 멈춥니다. 8강에서 환경 사실을 Rule에 적는 것과 같은 이치예요. 이번엔 적는 자산이 스타일일 뿐이에요.
이미 흐트러진 프로젝트를 한 번의 리팩터로 깨끗이 만들 수는 없어요. 아래 네 단계로 가세요. 각 단계에서 멈춰 검증할 수 있어요.
목록부터, 보기만 하고 고치지 말 것
AI에게 프로젝트 스타일을 전부 훑게 하고, 중복 목록을 받아요: 같은 컨트롤을 구현하는 클래스가 몇 개인지, 색값과 모서리 반경이 얼마나 흩어져 있는지. 이 단계에서는 코드를 건드리지 마세요. 빚이 얼마인지 먼저 보세요.
token을 정하고, 매직 넘버를 몇 단으로 접기
목록에서 실제로 쓰는 값만 골라 작은 변수 세트로 고정해요: 주색상, 의미 색, 모서리 반경 두세 단, 간격 네 단, 컨트롤 높이. 단은 적어야 해요. 적어야 지킬 수 있어요.
나눠 병합, 한 번에 컨트롤 하나
버튼 먼저, 검증; 카드 다음, 검증; 그다음 입력창. 배치마다 따로 커밋하면, 문제 나도 그 배치만 롤백할 수 있어요. 수렴은 동등 치환이에요. 눈으로 보면 달라지면 안 됩니다 — 진짜 모양을 바꿀 거면, 그건 다른 일이에요.
게이트를 두어, 내일 다시 자라지 않게
규칙 파일에 이렇게 적어요: 「새 스타일을 쓰기 전에 token과 공용 컴포넌트를 먼저 검색. 있으면 재사용하고, 없을 때만 새로 만들되 뭘 찾아봤는지 밝힐 것」. 이 게이트가 없으면 석 달 뒤에 또 걷어내야 해요.
수렴이 과해지기 쉬운 지점은, 있어야 할 차이까지 밀어 없애는 거예요. 실제 스타일 차이 다섯 쌍입니다. 손 미끄러져 쌓인 것과, 이유가 있는 것을 직접 가려 보세요.
합칠지 말지는 한 마디만 물으면 돼요: 이 차이, 뭐라고 부르나요? 이름이 나오면 남겨요 — 「보조 버튼」「위험한 동작」「터치 타깃 하한」「팝오버는 카드보다 한 단 위」. 이건 디자인 결정이고, 이유만 주석에 적으면 됩니다. 이름이 안 나오면 합쳐요 — 2px 차이나는 모서리 반경 두 개, 눈으로 안 가려지는 파랑 두 개. 그건 아무것도 아니에요. 그때 그냥 쓴 거예요.
미학 편의 일관성 레슨에도 같은 말이 있어요: 차이는 죄가 아니고, 이유가 없는 게 죄예요. 그 레슨은 디자인 쪽에서 변수표를 어떻게 정하는지 말하고, 이 레슨은 코드가 이미 흩어졌을 때 어떻게 거두는지 말해요. 둘을 같이 보세요. 하나는 기준을, 하나는 수술 방안을 줍니다.
함께 읽기: 미학 엔지니어링 · 일관성: 시스템감은 어디서 오나 (token을 어떻게 정할지) · 이전 레슨 PlayGround (수렴한 컴포넌트를 어디서 조율할지)
한 번에 전량 리팩터
AI에게 「사이트 스타일을 한 번에 맞춰 줘」라고 하면, 파일 60개를 고친 diff가 옵니다. 검토도 못 하고 배포도 못 해요. 언제나 컨트롤 단위로 나누세요.
겸사겸사 비주얼을 고침
수렴 중에 AI는 모서리 반경과 배색을 「겸사겸사 최적화」하는 일이 많아요. 그러면 페이지가 달라진 게 병합 버그인지, AI의 미적 즉흥인지 구분이 안 됩니다. 수렴은 동등 치환만 하세요.
token을 너무 잘게 쪼갬
모서리 반경 12단, 회색 9종이면 정하지 않은 것과 같아요 — 다음에 또 고르게 되고, 고르면 틀립니다. 「거의 고를 게 없을 때」라야 구속력이 생겨요.
AI는 존재한다고 알려 주지 않은 것을 재사용하지 않아요. 스타일이 증식하는 뿌리는 매 라운드 기억을 잃는 것이라, 해법은 두 쪽입니다: 이미 흐트러진 것은 컨트롤 단위로 token에 담고, 앞으로는 규칙 하나로 막아요 — 쓰기 전에 먼저 검색. 페이지 위쪽 Skill이 바로 이 두 쪽의 실행판이에요. Agent에게 복사해 주면, 바로 고치는 대신 빚 목록부터 내놓습니다.
함께 쓸 규칙은 저장소 itshen/xs_vibe_rules의 「새 기능은 먼저 중복을 확인할 것」 한 조항을 참고하세요. 이 레슨은 그걸 기능에서 스타일까지 연장합니다.