설치AI로 만든 프론트, AI처럼 안 보이게 — 디자인 시스템을 먼저 만든 이유
저는 백엔드 개발자입니다. Slack 연차·근태 관리 앱(VacayBuddy)의 웹 화면은 Express + EJS로 서버가 그리고, 그 프론트엔드 코드는 대부분 AI에게 맡겨 작성해 왔습니다. 지난 글에서는 그 코드를 htmx로 걷어내며 "화면 상태의 기준은 서버"라는 원칙을 세웠습니다.
로직은 그렇게 정리가 됐는데, 화면을 열어 보면 여전히 한눈에 티가 났습니다. "AI가 만들었네." 파란 정사각형 안에 흰 아이콘이 들어간 통계 카드, 그라데이션 배지, 대문자 ADMIN 라벨, 페이지마다 미묘하게 다른 파란색. 기능은 멀쩡한데 어디서 본 것 같은 화면이었습니다.
이번에 이 화면들을 전부 다시 만들었습니다. 결론부터 적으면 이렇습니다.
디자인 시스템을 먼저 만들어 색·버튼·표 같은 컴포넌트를 정의하고, 필요한 게 생기면 디자인 시스템에 먼저 추가한 다음, 화면은 그걸 가져다 짠다. 그러면 모든 화면의 일관성이 유지되고, 일관성이 유지되면 AI 티가 나지 않는다.
AI 티의 정체는 결국 페이지마다 제각각인 뒤죽박죽이었습니다. 그래서 화면을 하나하나 고치는 대신 기준을 먼저 세웠습니다.
바꾼 페이지는 32개, 쓴 토큰은 약 3억 8천만 개입니다. 자세한 숫자는 6장에서 정리합니다.
환경: Node + Express + TypeScript + EJS + htmx. 이번에 추가한 건 Tailwind CSS v4 하나입니다. 비교 사진은 개편 전 화면과 지금 화면에 같은 가상 조직 데이터를 넣어 같은 구도로 찍었습니다.
1. AI가 짠 화면은 왜 AI처럼 보일까
감으로 말하기 전에 먼저 세어 봤습니다. 우리가 직접 쓴 화면 코드만 대상으로 했고, 외부 라이브러리는 뺐습니다.
| 항목 | 개편 전 | 개편 후 |
|---|---|---|
| 서로 다른 색 | 162개 | 33개 (그중 25개가 디자인 시스템에 정한 색) |
| 그라데이션 | 65곳 | 1곳 (형광펜 표시) |
| 그림자 | 206곳 | 34곳 |
| 글자 크기 종류 | 68종 | 4종 (나머지는 디자인 시스템의 크기) |
| 모서리 둥글기 종류 | 43종 | 11종 |
| 버튼 모양 종류 | 41종 | 8종 |
| 페이지 안에 직접 쓴 스타일 | 498곳 | 24곳 |
개편 후 수치에서는 쓰지 않는 옛 페이지와 디자인 시스템 설명 페이지(색 값을 글자로 보여 주는 문서)를 뺐습니다.
원인은 단순했습니다. AI는 페이지 단위로 만듭니다. "연차 관리 화면 만들어 줘"라고 하면 그 화면 안에서 완결된 코드를 내놓고, 그때마다 가장 그럴듯한 기본값을 고릅니다. 다른 페이지와 맞출 기준이 없으니 페이지마다 서로 다른 색·모서리·버튼을 쓰게 되고, 페이지가 늘수록 뒤죽박죽이 됩니다. 그 기본값과 어긋남이 바로 우리가 'AI 티'라고 부르는 것들입니다.
실제 코드를 열어 보니, 이미 재사용할 수 있는 공용 CSS가 있었는데도 AI가 그때그때 편한 대로 그 자리에서 CSS를 새로 만들어 썼습니다. 그렇게 페이지마다 즉석에서 만든 스타일이 쌓이다 보니, 같은 "승인 대기"가 달력에선 주황, 팀 연차 화면에선 빨강이 됐습니다.
정리하면, 기준이 있는 것과 기준을 반드시 따르게 하는 것은 다른 문제였습니다. 기준을 적어 둬도, 안 따라도 화면이 멀쩡히 돌아가면 AI는 그때그때 편한 값을 씁니다. 사람도 마찬가지고요.
2. 기준 페이지를 먼저 만들고, 모든 화면이 거기서 가져다 쓴다
개편 전에는 페이지마다 그때그때 만들었습니다. 이번에는 순서를 뒤집었습니다. 먼저 기준이 되는 페이지(디자인 시스템)를 하나 만들고, 모든 화면은 그 페이지에 있는 것만 가져다 씁니다. 필요한 게 없으면 화면에서 새로 만들지 않고, 기준 페이지에 먼저 추가한 다음 씁니다.
지난 글의 원칙이 "화면 상태의 기준은 서버"였다면, 이번 원칙은 "화면 모양의 기준은 디자인 시스템"입니다.
2-1. 기준 페이지 — 색·버튼·표·모달을 한 곳에
색, 글자 크기, 버튼, 입력창, 표, 모달, 배지를 전부 한 페이지에 그려 두었습니다. 맨 위에는 이렇게 적혀 있습니다. "새 화면은 여기 있는 값과 컴포넌트만 씁니다. 없는 게 필요하면 먼저 여기에 추가하세요."
AI에게는 이 페이지가 카탈로그이고, 저에게는 리뷰 화면입니다.
2-2. 없는 컴포넌트는 디자인 시스템에 먼저, 화면은 조합으로
예전에는 화면에 필요한 게 있으면 그 화면 안에서 바로 만들었습니다. 그러니 다른 화면에서 비슷한 게 필요할 때마다 조금씩 다른 모양이 새로 생겼습니다.
이번에는 없는 컴포넌트를 화면에서 만들지 않고 디자인 시스템에 먼저 만듭니다. 화면은 디자인 시스템에 있는 컴포넌트를 조합해서 만듭니다.
연차 신청 상세 창이 그 예입니다. "10월 12일 → 14일"을 달력 한 장처럼 보여 주는 날짜 카드가 필요했는데, 디자인 시스템에는 없었습니다. 그래서 날짜 카드를 디자인 시스템에 먼저 추가했고(색·모서리·글자 크기는 이미 있는 값으로만), 신청 상세 창은 이 날짜 카드에 기존 배지·타임라인을 조합해 다시 만들었습니다.
그래서 일관성이 유지됩니다. 새로 만든 컴포넌트도 같은 색·모서리·글자 크기로 만들어지고, 다른 화면에서 날짜 카드가 필요하면 같은 것을 가져다 씁니다. 색도 마찬가지입니다. 예전에는 달력에선 주황이던 "승인 대기"가 팀 연차 화면에선 빨강이었지만, 이제는 어느 화면에서든 같은 색입니다.
이번 작업 중에 이렇게 늘어난 컴포넌트가 직원 목록, 날짜 카드, 태그 입력 같은 것들입니다. 화면이 하나 늘 때마다 디자인 시스템이 조금씩 자랐고, 다음 화면은 그만큼 빨리 만들어졌습니다.
2-3. 기준 밖의 값은 아예 안 나오게 막는다
기준 페이지를 만들어 두는 것만으로는 부족했습니다. 1장에서 본 것처럼, 예전에도 공통 기준은 있었는데 안 따르는 화면이 생겼으니까요.
그래서 기준에 없는 색·모서리·그림자는 써도 화면에 안 나오게 막았습니다. 예를 들어 AI가 습관대로 "Tailwind 기본 파랑"을 쓰면, 그 색 자체가 없어서 버튼에 색이 안 칠해집니다. 화면을 열자마자 이상한 게 보이니 바로 잡힙니다. "쓰지 마세요"가 아니라 "쓸 수 없다"로 바꾼 겁니다.
마지막으로 AI가 작업할 때 읽는 규칙 문서에 이 원칙과 'AI 티' 금지 목록을 적었습니다.
- 새 화면은 디자인 시스템에 있는 것만 쓴다. 없으면 디자인 시스템에 먼저 추가한다.
- 그라데이션, 카드 그림자, 대문자 라벨은 쓰지 않는다. 장식은 형광펜 하나, 한 화면에 핵심 숫자 하나에만.
- 버튼 문구는 동작("승인하기"), 완료 알림은 같은 동사의 과거형("승인했어요").
3. 전환 — 페이지 하나씩 차례로
| 시각 | 한 일 |
|---|---|
| 08:50 ~ 09:57 | 디자인 시스템 만들기 (색·컴포넌트·기준 페이지·자동 검사) |
| 09:59 ~ 11:37 | 페이지 32개 옮기기 |
| 11:40 | AI 규칙 문서 정리 |
| 12:16 ~ 12:30 | 직접 써 보고 낸 피드백 반영 |
모두 합쳐 약 3시간 50분이 걸렸고, 토큰은 약 3억 8천만 개를 썼습니다.
페이지(또는 묶음) 하나씩 차례로 옮겼습니다. 안내 화면처럼 단순한 것부터 시작해 감사 로그, 전자결재, 팀 휴가 달력, 근태, 연차 관리, 설정 순으로 갔습니다. 앞 화면에서 만든 컴포넌트를 뒤 화면이 그대로 가져다 쓰니, 뒤로 갈수록 빨라졌습니다.
htmx와도 궁합이 좋았습니다. 서버가 HTML을 그려 주는 구조라 화면 코드가 템플릿 한 곳에만 있어서, 옮길 곳도 한 곳이었습니다. 페이지마다 따로 들고 있던 모달·알림·확인창 코드도 공용 코드 하나로 합쳤습니다.
그 결과 화면 코드는 2만 4천 줄을 지우고 7천 줄을 썼습니다. 디자인 시스템을 새로 만들고도 전체 코드는 1만 줄 넘게 줄었습니다.
4. 검증 — 잴 수 있는 건 자동으로, 화면은 사람이 본다
브라우저 자동화 도구인 Playwright를 쓰면 디자인 QA도 자동으로 할 수 있습니다. 전환 내내 40개 화면을 데스크톱·모바일 두 크기로 띄워 스크린샷을 찍고, 이런 걸 자동으로 잡았습니다.
- 화면 오류, 불러오지 못한 요청
- 화면이 옆으로 넘쳐 가로 스크롤이 생기는 곳
- 디자인 시스템에 없는 색이 칠해진 곳
- 배경에 비해 너무 흐린 글자
- 한 단어가 두 줄로 쪼개진 곳 (좁은 칸에서 "김하/늘"처럼)
마지막 항목은 한국어 화면에서 특히 중요했습니다. 개편 전 모바일 달력이 정확히 그랬거든요.
그래도 자동 검사가 못 잡는 건 있었습니다. 넓은 모니터에서 달력 오른쪽이 텅 비는 것, 탭 아래에 세로 스크롤바가 생기는 것, 달력의 휴가가 누를 수 있는 것처럼 안 보이는 것, 칩 모서리가 어색한 것. 이건 전부 제가 직접 써 보다가 찾았습니다. 잴 수 있는 건 자동 검사에 맡기고, 스크린샷은 사람이 봐야 합니다.
5. 디자인 시스템만 다듬으면 화면이 따라온다
이 구조의 진짜 이점은 전환이 끝난 뒤에 나왔습니다. 다 옮기고 나서 직접 써 보니 고치고 싶은 게 보였는데, 디자인 시스템 한 곳만 고치면 그 컴포넌트를 쓰는 모든 화면이 한꺼번에 바뀌었습니다.
- "칩(작은 태그) 모서리를 더 둥글게" → 디자인 시스템의 칩 하나만 고쳤습니다. 칩을 쓰는 모든 화면이 같이 바뀌었습니다.
- "넓은 모니터에서 오른쪽만 비어 이상하다" → 공통 화면 틀 한 곳에 "가운데 정렬"을 넣었습니다. 전 페이지가 가운데로 왔습니다.
- "달력의 휴가에 마우스를 올리면 손가락 커서" → 달력 컴포넌트 한 곳만 고쳤습니다.
예전처럼 페이지마다 따로 만들어 두었다면, 같은 수정을 수십 개 파일에서 하나하나 찾아 고쳐야 했을 겁니다. 그리고 그중 몇 개는 분명 빠뜨렸겠죠.
색감도 마찬가지입니다. 아직 디자이너 검토 전인데, 걱정이 덜합니다. 디자인 시스템의 색만 바꾸면 전 화면에 반영되니까요. 디자인 시스템이 좋아지면 화면은 따라서 좋아집니다. 반대로 디자인 시스템이 AI스러우면 모든 화면이 똑같이 AI스러워지니, 사람이 시간을 쓸 곳은 여기입니다.
6. 숫자로 정리
| 항목 | 값 |
|---|---|
| 작업 시간 | 약 3시간 50분 (08:50 ~ 12:40) |
| 바꾼 페이지 | 32개 |
| 쓴 토큰 | 약 3억 8천만 개 |
| 바뀐 코드 | 1만 3천 줄 추가, 2만 4천 줄 삭제 |
모델은 Claude Opus 5.5였습니다. 디자인 시스템과 규칙 문서를 작업 내내 기준으로 두었기 때문에, 페이지를 몇 개째 옮기든 같은 기준으로 만들 수 있었습니다.
마치며
AI에게 프론트를 맡기면서 화면 하나하나를 잘 만들어 달라고 요구하는 건 끝이 없습니다. 페이지마다 그럴듯한 기본값이 새로 들어오고, 그게 쌓이면 뒤죽박죽이 되니까요.
그래서 순서를 바꿨습니다. 디자인 시스템을 먼저 만들어 정의하고, 없는 컴포넌트는 디자인 시스템에 먼저 추가하고, 화면은 그걸 가져다 짭니다. 모든 화면이 디자인 시스템에 정의된 같은 CSS 클래스를 쓰니 일관성이 유지되고, 칩 모서리든 가운데 정렬이든 그 클래스 하나만 고치면 전 화면에 반영됩니다. 기준 밖의 값은 아예 안 나오게 막고, 자동 검사로 한 번 더 확인했습니다.
일관성이 유지되면 AI 티는 나지 않습니다. 그다음부터 제가 시간을 쓴 곳은 화면이 아니라 디자인 시스템이었습니다.
바뀐 화면은 VacayBuddy 블로그 글에서 더 볼 수 있습니다.