AI가 만든 웹사이트가 어색한 이유, 디자인 시스템부터 바꾸면 달라지는 것들

AI에게 웹 화면을 맡기면 첫 결과는 꽤 그럴듯합니다. 버튼도 있고, 통계 카드도 있고, 모바일에서 메뉴까지 접힙니다. 문제는 두 번째 화면부터 시작됩니다. 같은 저장 버튼인데 색이 다르고, 같은 오류인데 어떤 곳에서는 빨간 글씨로, 다른 곳에서는 작은 회색 알림으로 표시됩니다. 화면을 하나씩 볼 때는 놓쳤던 차이가 서비스 전체를 열어 보면 드러납니다.

이때 “좀 더 세련되게 만들어 줘”라는 요청을 반복하면 디자인이 좋아질까요? 바뀐 화면 하나는 마음에 들 수 있습니다. 그러나 공통 기준이 없다면 다음 화면에서 같은 문제가 다시 생깁니다. AI 코딩에서 먼저 정해야 할 것은 예쁜 화면의 묘사보다 무엇을 반복해서 사용하고, 무엇을 새로 만들지 않을 것인가입니다.

공유된 VacayBuddy 화면 개편 사례 역시 디자인 시스템을 먼저 정리하고 기존 화면을 옮기는 접근을 소개합니다. 이 글은 그 사례에서 출발하되, 작업 시간이나 토큰 수 같은 확인되지 않은 성과 수치 대신 실제 프로젝트에서 적용할 수 있는 기준과 검증 방법을 정리했습니다. 직접 수행한 개발 후기나 성능 측정 결과를 소개하는 글은 아닙니다.

1. ‘AI 티’보다 먼저 살펴볼 것은 화면 사이의 불일치

그라데이션이나 둥근 카드가 있다고 해서 나쁜 디자인은 아닙니다. 브랜드 성격과 사용 목적에 맞는다면 충분히 좋은 선택입니다. 반대로 장식을 모두 지워도 정보가 찾기 어렵고 버튼의 의미가 모호하다면 좋은 화면이라고 보기 어렵습니다.

문제는 장식의 종류보다 선택의 근거입니다. 이용자가 반복해서 마주치는 요소에 공통 규칙이 없으면 매번 새롭게 해석해야 합니다. 어제는 파란 버튼이 저장이었는데 오늘은 단순 조회라면, 사용자는 색만으로 행동의 중요도를 판단하기 어렵습니다. ‘대기 중’과 ‘실패’를 같은 빨간색으로 표현하면 실제로 조치가 필요한 항목도 눈에 잘 들어오지 않습니다.

AI가 페이지마다 새로운 코드를 만드는 작업 방식에서는 이런 불일치가 누적되기 쉽습니다. 기존 컴포넌트의 위치나 사용 규칙을 제공하지 않은 채 화면만 요구하면, 모델은 해당 요청을 만족시키는 별도 해법을 만들 수 있습니다. 이 현상을 모델의 취향 탓으로만 돌리면 해결하기 어렵습니다. 재사용할 수 있는 코드가 있는지, 작업 시작 전에 그 코드를 읽도록 했는지, 중복 구현을 검사하는지부터 확인해야 합니다.

다만 일관성은 디자인 품질의 한 부분입니다. 모든 페이지의 버튼이 똑같아도 글자가 너무 작거나, 주된 행동을 찾기 어렵거나, 서비스의 개성이 없다면 개선은 끝나지 않았습니다. 일관성은 유지보수의 기반이고, 사용성과 브랜드 표현은 별도로 검토해야 할 과제입니다.

2. 색상표를 만들기 전에 사용자의 일을 세 가지로 줄여 보자

디자인 시스템을 시작한다고 곧바로 색상 수십 개를 정할 필요는 없습니다. 먼저 서비스에서 자주 일어나는 일을 적어 보는 편이 낫습니다. 예를 들어 관리 도구라면 ‘목록에서 대상을 찾기’, ‘상세 내용을 확인하기’, ‘변경을 저장하거나 승인하기’가 핵심 흐름일 수 있습니다. 콘텐츠 사이트라면 ‘원하는 주제 찾기’, ‘본문 읽기’, ‘관련 글로 이동하기’가 중요합니다.

그다음 각 흐름에서 무엇이 가장 먼저 보여야 하는지 정합니다. 목록 화면에서는 검색과 상태 구분이 중요하고, 읽기 화면에서는 제목의 위계와 본문 폭이 중요합니다. 모든 화면 상단에 큰 숫자 카드 네 개를 넣는 방식은 구현하기 쉬워도 실제 이용 목적과 맞지 않을 수 있습니다.

이 단계에서 한 화면의 대표 행동도 정해 두면 좋습니다. ‘신청하기’가 중심인 화면에 같은 강도의 버튼이 여섯 개 있다면 주된 행동이 묻힙니다. 중요한 행동 하나를 강조하고, 보조 행동은 시각적 강도를 낮추는 식으로 역할을 나눕니다. 삭제처럼 되돌리기 어려운 행동은 단지 빨갛게 칠하는 데서 끝내지 말고 확인 절차와 취소 가능성까지 설계해야 합니다.

작은 프로젝트라면 아래 네 가지 질문의 답만 문서로 남겨도 출발점이 됩니다.

• 이용자가 이 화면에서 끝내야 하는 일은 무엇인가?
• 가장 먼저 읽어야 하는 정보와 가장 중요한 버튼은 무엇인가?
• 정보가 없거나 요청이 실패하면 무엇을 보여 줄 것인가?
• 휴대폰 화면과 키보드 조작에서도 같은 일을 끝낼 수 있는가?

3. 디자인 토큰은 색 이름보다 역할 이름으로 관리한다

디자인 토큰은 반복되는 시각적 값을 이름으로 관리하는 방식입니다. 색상, 글자 크기, 간격, 테두리, 모서리 둥글기 같은 값을 한곳에 모아 여러 화면에서 재사용합니다. 중요한 것은 이름에 의미를 담는 일입니다.

‘파랑 600’처럼 색의 위치를 설명하는 이름과 ‘주요 행동 배경’처럼 역할을 설명하는 이름은 용도가 다릅니다. 기본 색상값은 원시 토큰으로 두고, 실제 화면에서는 역할을 나타내는 의미 토큰을 쓰면 변경 영향을 이해하기 쉽습니다. 브랜드 색을 바꿀 때 모든 파란 요소를 일괄 수정하는 대신 주요 행동, 링크, 정보 알림을 구분해서 조정할 수 있습니다.

• 글자: 기본 본문, 보조 설명, 비활성 안내, 반전된 배경 위의 글자
• 배경: 페이지 바탕, 카드 표면, 강조 영역, 선택된 항목
• 상태: 진행 중, 완료, 주의, 실패
• 행동: 주요 버튼, 보조 버튼, 위험한 행동, 키보드 포커스 표시
• 크기: 본문 글자, 설명 글자, 소제목, 페이지 제목, 행간과 읽기 폭

처음부터 가능한 상태를 전부 만들어 둘 필요는 없습니다. 실제 화면에서 쓰이는 역할부터 정하되 같은 이름에 서로 다른 의미를 섞지 않는 것이 중요합니다. 상태를 색만으로 전달하지 않는 원칙도 함께 둡니다. 예를 들어 대기는 색상 배지와 ‘승인 대기’라는 문구를 같이 표시합니다. 색을 구분하기 어려운 사람에게도 의미가 남아야 하기 때문입니다.

다크 모드가 예정돼 있다면 화면마다 색을 뒤집기보다 의미 토큰의 값을 바꾸는 구조가 관리하기 편합니다. 다만 밝은 배경에서 충분했던 대비가 어두운 배경에서도 유지되는지는 다시 확인해야 합니다. 동일한 토큰 이름을 쓴다고 가독성까지 자동으로 보장되지는 않습니다.

4. 컴포넌트는 예쁜 기본 상태보다 예외 상태가 중요하다

버튼과 입력창을 한 번 만들어 두는 것만으로 재사용 체계가 완성되지는 않습니다. 실제 서비스에서는 로딩 중인 버튼, 입력 오류가 있는 필드, 데이터가 없는 목록, 요청에 실패한 상세 화면이 계속 등장합니다. 기본 상태만 정해 두면 AI는 나머지 상태를 화면마다 즉석에서 만들게 됩니다.

버튼 하나를 정의할 때도 역할, 크기, 상태, 문구를 함께 정리하는 편이 좋습니다. 주요 버튼인지 보조 버튼인지, 요청을 보내는 동안 다시 누를 수 있는지, 작업이 끝난 뒤 어떤 메시지가 나오는지까지 포함합니다. ‘확인’처럼 맥락을 모르면 뜻이 불분명한 문구 대신 ‘변경 저장’, ‘신청 승인’처럼 행동을 드러내면 화면을 이해하기 쉽습니다.

입력창은 제목에 해당하는 레이블, 입력 예시, 오류 안내의 위치를 같이 정합니다. 예시 문구가 입력과 함께 사라진 뒤에도 무엇을 입력하는 칸인지 알 수 있어야 합니다. 오류가 생겼을 때는 테두리 색만 바꾸지 말고 무엇을 어떻게 고쳐야 하는지 적어 줍니다.

표는 데이터가 많이 들어왔을 때의 대응을 먼저 생각해야 합니다. 긴 이름, 여러 줄 주소, 비어 있는 값, 행이 하나뿐인 상태를 넣어 봅니다. 모바일에서 모든 열을 억지로 압축할지, 필요한 열을 우선 보여 줄지, 가로 스크롤을 허용할지는 정보의 성격에 따라 달라집니다. 화면을 넘친다는 이유만으로 모든 가로 스크롤을 오류 처리하면 오히려 정보를 읽기 어려워질 수 있습니다.

대표 화면을 만들 때는 예쁘게 보이는 짧은 가상 데이터만 넣지 않는 것이 좋습니다. 긴 한국어 이름과 영어 서비스명, 큰 숫자, 빈 목록, 권한이 없는 상태를 함께 넣으면 실제 사용에서 생길 문제를 더 빨리 찾을 수 있습니다.

5. Tailwind v4에서 기본 테마를 지워도 규칙이 강제되지는 않는다

Tailwind CSS v4는 테마 변수를 통해 사용할 디자인 값을 정의합니다. 공식 문서에는 특정 색상 네임스페이스나 전체 기본 테마를 초기화하고 필요한 값을 다시 선언하는 방법이 안내돼 있습니다. 이 방식은 무심코 기본 팔레트를 가져다 쓰는 일을 줄이는 데 도움이 됩니다. Tailwind 테마 변수 공식 문서

그러나 여기에는 중요한 한계가 있습니다. 기본 테마를 초기화했다고 해서 규칙 밖의 모든 스타일이 금지되는 것은 아닙니다. Tailwind는 대괄호를 사용하는 임의 값과 사용자 정의 CSS도 지원합니다. 인라인 스타일이나 다른 스타일시트로 값을 직접 넣는 경로도 남아 있습니다. 따라서 ‘등록하지 않은 색은 절대로 사용할 수 없다’는 설명은 정확하지 않습니다. Tailwind 사용자 정의 스타일 공식 문서

실무에서는 디자인 설정과 코드 검사 규칙을 함께 사용해야 합니다. 예를 들어 페이지 파일에서 새로운 색상 리터럴을 만들지 않도록 검사하고, 공용 컴포넌트와 테마 파일에서만 예외를 허용하는 방식입니다. 임의 값 전체를 기계적으로 금지하면 필요한 레이아웃까지 막힐 수 있으므로 허용 위치와 사유를 정하는 편이 현실적입니다.

여기서 검사 통과와 좋은 화면은 별개입니다. 등록된 색만 사용했더라도 배경과 글자 조합이 나쁘면 읽기 어렵습니다. 토큰 규칙은 선택지를 관리하는 장치이고, 실제 조합의 품질은 렌더링된 화면에서 확인해야 합니다.

6. AI에게는 스타일 지시와 함께 작업 순서를 전달한다

“미니멀하게”, “요즘 느낌으로”, “AI처럼 보이지 않게”라는 말은 해석의 폭이 넓습니다. 이런 표현만 전달하면 매번 다른 결과가 나오는 것이 이상하지 않습니다. 대신 작업자가 무엇을 먼저 읽고 어떤 조건에서 공용 코드를 수정해야 하는지 적어 주는 편이 재현성이 높습니다.

프로젝트 규칙에는 다음 순서를 담을 수 있습니다. 먼저 디자인 토큰과 기존 컴포넌트 목록을 읽습니다. 요청받은 화면을 만들기 전에 재사용할 요소를 찾습니다. 필요한 기능이 없으면 기존 컴포넌트를 확장할지 새로 만들지 판단합니다. 새 요소는 공용 위치에 추가하고 사용 예시를 남긴 다음 화면에서 불러옵니다. 마지막으로 변경된 화면과 영향을 받는 공용 요소를 검사합니다.

단, 비슷하게 보이는 요소를 무조건 하나로 합치는 것도 좋은 해법은 아닙니다. 결제 완료 알림과 입력 오류 알림은 모양 일부가 같아도 역할과 동작이 다릅니다. 공통 기반을 공유하되 필요한 상태를 명확히 구분해야 합니다. 재사용을 늘리겠다는 이유로 옵션이 지나치게 많은 거대한 컴포넌트를 만들면 수정이 더 어려워질 수 있습니다.

AI의 완료 보고에도 기준을 둡니다. ‘구현 완료’라는 한 줄 대신 재사용한 컴포넌트, 새로 추가한 요소, 실행한 검사, 아직 확인하지 못한 상태를 적게 합니다. 실제로 실행하지 않은 테스트는 통과했다고 쓰지 않게 하고, 화면 확인과 코드 검사를 구분합니다. 이런 보고 방식은 다음 작업에서 무엇을 믿고 이어 갈 수 있는지 판단하는 데 도움이 됩니다.

7. htmx를 쓰면 디자인 시스템도 쉬워질까?

htmx는 HTML 속성으로 요청과 화면 일부 교체를 다루며, 서버 응답은 일반적으로 HTML을 사용합니다. 따라서 서버 템플릿으로 버튼, 표, 알림 같은 공용 조각을 구성하는 방식과 함께 사용할 수 있습니다. htmx 공식 문서

다만 htmx를 선택했다고 컴포넌트 중복이 자동으로 사라지는 것은 아닙니다. 여러 템플릿에 비슷한 HTML을 복사하면 구조가 다시 갈라집니다. 반대로 다른 프런트엔드 방식에서도 공용 컴포넌트와 디자인 토큰을 잘 운영할 수 있습니다. 핵심은 프레임워크 이름보다 시각 규칙과 상태 처리가 어디에 모여 있는지입니다.

서버가 내려주는 부분 화면에서도 로딩, 오류, 포커스 이동을 고려해야 합니다. 버튼을 누른 뒤 목록이 바뀌었는데 키보드 사용자가 다음 위치를 찾지 못한다면 색과 간격이 정돈돼 있어도 사용 경험은 불편합니다. 디자인 시스템에는 정적인 모양뿐 아니라 업데이트가 일어났을 때 사용자가 어떻게 변화를 알아차릴지도 포함해야 합니다.

8. Playwright 스크린샷 검사와 접근성 검사는 다른 일이다

Playwright의 시각 비교 기능은 기준 이미지와 현재 화면의 차이를 찾는 데 유용합니다. 의도하지 않은 간격 변경이나 버튼 위치 이동처럼 화면에 나타나는 변화를 확인할 수 있습니다. 다만 운영체제, 브라우저, 폰트와 실행 환경에 따라 이미지가 달라질 수 있으므로 비교 환경을 맞추는 과정이 필요합니다. Playwright 시각 비교 공식 문서

기준 이미지가 잘못된 화면이라면 테스트도 그 잘못된 화면을 지키게 됩니다. 디자인을 바꿀 때 기준 이미지를 일괄 갱신하기 전에 변경 이유를 확인해야 합니다. 차이가 생겼다는 사실과 문제가 생겼다는 판단은 같지 않습니다.

접근성은 별도 점검이 필요합니다. Playwright 공식 문서는 axe 엔진을 연동하는 방법을 소개하며 자동 검사가 모든 접근성 위반을 찾아내지는 못한다고 설명합니다. 따라서 스크린샷을 찍었다는 이유만으로 대비, 이름표, 키보드 조작까지 모두 검증됐다고 해서는 안 됩니다. Playwright 접근성 검사 공식 문서

프로젝트에 적용할 때는 검사 목적을 나눠 두면 결과가 명확해집니다.

• 기능 검사: 제출과 저장, 취소, 권한 제한이 의도대로 동작하는지 확인합니다.
• 시각 비교: 검토된 기준 화면에서 예상하지 못한 변화가 생겼는지 확인합니다.
• 접근성 자동 검사: 도구가 검출할 수 있는 문제를 찾아 수정합니다.
• 사용자 관점 확인: 키보드만으로 주요 일을 끝낼 수 있는지, 오류에서 회복할 수 있는지 직접 확인합니다.
• 한국어 화면 검토: 이름과 날짜가 부자연스럽게 끊기거나 중요한 안내가 잘리는지 살펴봅니다.

한국어 줄바꿈 문제는 화면 폭과 내용 길이의 영향을 함께 받습니다. 특정 CSS 속성 하나를 전역 적용하는 것으로 끝내기보다, 제목·표·버튼 등 영역별로 넘침과 줄바꿈을 확인하는 편이 안전합니다. 자동 검사를 추가한다면 무엇을 오류로 판단하는지 먼저 정의해야 합니다.

9. 기존 사이트는 한꺼번에 갈아엎지 말고 대표 흐름부터 바꾼다

이미 운영 중인 사이트라면 모든 페이지를 동시에 바꾸는 작업은 부담이 큽니다. 먼저 방문 빈도가 높고 다른 화면의 기준이 될 수 있는 대표 화면을 고릅니다. 목록 하나, 상세 하나, 입력 화면 하나 정도에서 공용 규칙이 충분히 작동하는지 확인합니다.

전환 순서는 ‘기본 토큰 정리 → 공용 요소 구축 → 대표 화면 적용 → 예외 상태 확인 → 나머지 화면 확장’으로 잡을 수 있습니다. 이때 기존 기능을 유지하는 기준도 정해야 합니다. 필터, URL 이동, 오류 처리처럼 디자인과 관계없어 보이는 동작이 개편 과정에서 빠지지 않도록 목록을 남깁니다.

공용 컴포넌트는 한 번 고치면 여러 화면에 영향을 줍니다. 이것은 장점이면서 동시에 위험입니다. 버튼 높이를 바꾼 뒤 좁은 표 안에서 줄바꿈이 생길 수 있고, 모달 폭을 조정한 뒤 모바일 입력창이 밀릴 수도 있습니다. 그래서 대표 화면뿐 아니라 실제 사용처 일부를 함께 검사해야 합니다.

새 규칙으로 옮기지 않은 페이지도 구분해 둡니다. 구형과 신형 스타일이 섞이는 과도기에는 전체 색상 개수만 세어 성과를 판단하기 어렵습니다. 어떤 파일과 화면을 대상으로 측정했는지, 외부 라이브러리와 사용하지 않는 코드는 제외했는지 기록해야 비교가 의미를 가집니다.

10. 좋은 결과를 판단하는 기준은 토큰 수가 아니다

AI로 몇 시간 만에 몇 개의 페이지를 만들었다는 숫자는 눈길을 끕니다. 그러나 프로젝트 규모, 기존 코드 상태, 검증 범위가 다르면 같은 수치로 작업 품질을 비교하기 어렵습니다. 토큰 수도 입력·출력·캐시 사용량을 어떻게 집계했는지에 따라 해석이 달라집니다. 모델 이름 하나로 디자인 개선의 원인을 설명하기도 어렵습니다.

운영자가 확인할 만한 지표는 조금 더 구체적입니다. 새 화면을 만들 때 공용 요소를 실제로 재사용하는지, 같은 상태를 일관되게 표현하는지, 작은 화면에서 핵심 행동을 완료할 수 있는지, 공용 요소 변경 뒤 오류가 늘지 않는지를 봅니다. 필요하다면 작업 완료 시간과 오류 발생 사례를 같은 조건에서 비교합니다.

색상 개수나 코드 줄 수는 보조 지표입니다. 적다고 무조건 좋은 것도, 많다고 무조건 나쁜 것도 아닙니다. 사용자에게 필요한 기능과 표현을 유지하면서 변경할 곳이 명확해졌는지가 더 중요합니다. 코드가 줄었다면 동작이 사라진 결과인지, 중복을 정리한 결과인지도 함께 확인해야 합니다.

마무리: AI에게 더 잘 그리게 하려면 먼저 같은 기준을 보게 해야 한다

AI 코딩의 결과를 안정적으로 개선하는 방법은 요청 문구를 끝없이 다듬는 데만 있지 않습니다. 사용자의 핵심 행동을 정하고, 의미가 있는 디자인 토큰과 공용 컴포넌트를 만들고, 규칙을 벗어난 구현을 검사할 수 있어야 합니다. 그리고 자동 검사가 통과한 화면도 사람이 직접 사용해 봐야 합니다.

처음부터 거대한 디자인 시스템을 구축할 필요는 없습니다. 자주 쓰는 버튼과 입력창, 상태 표시, 목록과 상세 화면부터 시작해도 됩니다. 중요한 것은 필요한 요소가 생길 때마다 각 페이지에서 새로 만드는 습관을 줄이고, 검토된 공통 기준을 조금씩 확장하는 것입니다.

일관된 화면은 출발점입니다. 그 위에 읽기 쉬운 정보 구조, 명확한 행동, 서비스에 맞는 시각적 성격이 더해져야 완성도가 높아집니다. 다음 화면을 AI에게 부탁하기 전, 무엇을 재사용할지부터 정해 보세요. 결과를 고치는 횟수보다 결과가 흔들리는 이유를 줄이는 쪽이 오래가는 개선입니다.