AI 코딩 도구는 강해지는데, 왜 웹사이트는 여전히 보기 좋지 않을까? AI 코드 생성부터 UI 디자인까지 완전 해결책

W3C는 일반 텍스트의 명암 대비를 최소 4.5:1로 안내합니다. W3C의 텍스트 대비 기준을 보면, 보기 좋은 화면은 코드가 정상적으로 작동하는 것만으로 완성되지 않습니다. AI 코드 생성은 지시받은 코드를 만들 수 있지만 시각적 우선순위와 일관된 디자인을 알아서 정하지는 않습니다. 이번 주에는 핵심 페이지 하나를 골라 디자인 규칙을 적고, 화면 캡처를 비교하며 고쳐 보세요.

이 글은 AI 코딩 도구로 웹사이트를 만들었지만 화면이 만족스럽지 않은 개발자를 위한 안내입니다.
전담 디자이너 없이 제품 화면을 준비하는 창작자도 적용할 수 있습니다.
작은 팀에서 프로토타입을 만들고 검수하는 경우에도 작업 순서와 기준을 함께 정할 수 있습니다.

AI 코드 생성은 빠른데 화면이 어색한 이유

페이지가 작동한다는 것은 버튼이나 링크가 의도한 동작을 한다는 뜻입니다. 시각적으로 잘 정리되었다는 뜻은 아닙니다. 두 결과가 갈라지는 것은 대개 AI의 취향보다 작업 조건이 모호하기 때문입니다.

목표가 흐리면 우선순위도 흐려집니다. “세련된 소개 페이지를 만들어 주세요”만 전달하면 도구는 세련됨을 판단할 기준을 받지 못합니다. 누가 방문하는지, 방문자가 무엇을 먼저 해야 하는지, 첫 화면에서 어떤 내용을 읽어야 하는지 빠지면 제목과 장식 요소가 비슷한 비중으로 놓일 수 있습니다.

페이지 전체가 아닌 부분별 생성은 일관성을 깨뜨립니다. 카드나 버튼을 따로 추가할 때마다 여백, 모서리, 글자 크기가 달라지면 각각은 무난해 보여도 한 사이트처럼 느껴지지 않습니다. 여러 화면을 차례로 생성하는 경우에도 먼저 정한 규칙을 다시 전달하지 않으면 같은 문제가 생깁니다.

실제 문구와 화면 크기를 뒤늦게 넣으면 레이아웃이 흔들립니다. 짧은 임시 문구를 기준으로 만든 화면은 긴 제목이나 실제 설명을 넣었을 때 줄바꿈과 높이가 달라집니다. 따라서 문제를 “AI가 미적으로 부족하다”로 뭉뚱그리기보다 구조, 시각적 위계, 간격, 구성 요소의 일관성을 각각 살펴야 합니다.

AI 코딩 도구가 기능은 정상인데 화면은 어색하게 만드는 원인

화면 하나에서 아래 항목을 비교해 보세요. 제목과 본문이 눈에 띄게 구분되는지, 주요 버튼이 다른 요소보다 먼저 읽히는지, 카드 사이의 여백이 일정한지, 같은 역할의 구성 요소가 같은 모양인지 확인합니다. 특정 요소 하나의 색이나 그림자를 바꾸기 전에, 이 기준 가운데 어디가 어긋났는지 찾아야 수정 목표를 정할 수 있습니다.

AI 코딩 도구에 전달하기 전 정할 UI 방향

AI 코딩 도구에 화면을 만들라고 하기 전에 방문자와 페이지의 역할을 적어 두세요. 예를 들어 제품 소개 페이지라면 방문자는 누구인지, 첫 화면에서 제품이 해결하는 문제가 무엇인지, 방문자가 다음으로 어떤 행동을 해야 하는지를 먼저 정합니다. 그 답이 있어야 제목, 설명, 버튼의 배치와 비중을 선택할 수 있습니다.

이어서 원하는 시각적 분위기를 구체화합니다. “고급스럽게”처럼 사람마다 다르게 해석할 말만 쓰지 말고, 참고 화면에서 가져올 요소와 가져오지 않을 요소를 구분합니다. 예를 들어 “제목은 짧고 크게, 본문은 차분하게, 강조색은 주요 버튼에만 사용하며, 장식보다 제품 화면을 먼저 보여준다”처럼 관찰 가능한 설명으로 바꾸면 됩니다.

첫 화면에서 방문자가 가장 먼저 읽어야 할 내용을 문장으로 써 보세요. 그다음 페이지 구조 초안을 만들고, 실제 문구를 넣었을 때도 그 순서가 유지되는지 확인합니다. 참고 자료를 쓸 때는 화면 전체를 복제하라고 요청하기보다 여백, 글자 배치, 색 사용처럼 참고할 특징을 지정하세요.

AI 코딩 도구에 UI 디자인 요구를 실행 가능한 지시로 바꾸는 법

지시는 화면에서 확인할 수 있는 조건을 포함해야 합니다. 다음처럼 작성할 수 있습니다.

이 페이지의 주요 이용자는 제품 도입을 검토하는 방문자입니다. 첫 화면에는 문제 설명, 제품을 보여 주는 이미지, 하나의 주요 행동 버튼을 둡니다. 제목과 설명의 중요도를 구분하고, 강조색은 주요 버튼에만 씁니다. 본문과 버튼 문구에는 제공한 실제 텍스트를 사용합니다.

“더 보기 좋게 고쳐 주세요”라는 요청보다 무엇을 어디에 두고 무엇을 강조할지 분명합니다. 화면 초안이 나오면 첫 화면의 내용 순서가 방문자의 목표와 맞는지 검토합니다. 틀린 경우에는 색을 손보기 전에 정보의 순서부터 바꾸세요.

디자인 규칙을 화면 구성 요소에 연결하기

시각적 방향을 정했다면 반복해서 쓸 수 있는 규칙으로 바꿉니다. 색상은 역할을 붙여 구분합니다. 예를 들어 배경, 본문, 보조 설명, 주요 행동에 각각 어떤 색을 쓸지 정합니다. 색상 값을 무작정 늘리기보다 실제 화면에서 맡는 역할을 먼저 적으세요.

글자도 제목, 본문, 보조 정보, 버튼처럼 역할별로 정합니다. 간격은 아무 때나 임의로 정하지 않도록 몇 가지 반복 규칙으로 묶습니다. 레이아웃에서는 주요 내용이 시작되는 위치와 열의 정렬 기준을 맞춥니다. 버튼, 입력란, 카드에는 기본 상태뿐 아니라 마우스를 올렸을 때, 키보드로 선택했을 때, 비활성 상태도 함께 정의합니다.

명암은 실제 문구와 배경의 조합으로 확인해야 합니다. W3C 기준은 일반 텍스트에 최소 4.5:1, 큰 텍스트에는 최소 3:1의 대비를 제시합니다. 대비 기준의 적용 조건을 확인하고, 색상만 보고 읽기 쉽다고 판단하지 마세요.

규칙 목록만 있고 실제 화면 구성 요소에 적용되지 않았다면 디자인 시스템이 완성된 것이 아닙니다. 같은 역할의 버튼과 카드가 화면마다 같은 규칙을 따르는지 확인하세요.

화면이 좁아질 때 배치를 어떻게 바꿀지도 미리 정해야 합니다. CSS 미디어 쿼리는 화면 조건에 따라 스타일을 적용하는 방법을 제공합니다. MDN의 미디어 쿼리 안내를 참고해 어떤 조건에서 열 수를 줄이고 메뉴를 바꿀지 결정하세요. 너비가 줄었을 때 내용이 잘리거나 가로 스크롤이 생기는지도 살핍니다. W3C의 화면 재배치 기준은 좁은 화면에서 내용을 가로로 넘기지 않고 읽을 수 있는지 확인하는 데 도움을 줍니다.

초안부터 최종 화면까지 진행하는 순서

아래 흐름은 한 번에 모든 디자인 문제를 해결하려는 방식이 아닙니다. 각 단계에서 확인할 항목을 좁혀 다음 단계로 넘어갑니다.

• 페이지의 주요 이용자와 완료해야 할 행동을 한 문장씩 적습니다.
• 실제 문구를 기준으로 페이지의 정보 순서를 정하고, 제목·설명·주요 행동의 위치를 표시합니다.
• 핵심 화면 하나의 시각 방향을 먼저 정합니다. 참고할 색, 글자 분위기, 간격과 참고하지 않을 요소를 함께 씁니다.
• 반복해서 쓸 색상 역할, 글자 역할, 간격 규칙, 레이아웃 기준을 정해 AI 코딩 도구에 전달합니다.
• 첫 화면에 규칙을 적용하고, 공통 버튼이나 카드가 같은 모양과 상태를 유지하는지 확인합니다.
• 실제 문구와 이미지를 넣은 뒤 화면이 넘치거나 내용의 순서가 바뀌는 곳을 수정합니다.
• 화면이 좁아졌을 때의 배치와 주요 상호작용을 확인하고, 남은 문제를 항목별로 고칩니다.

각 단계의 수정 요청은 검증할 수 있게 쓰세요. “첫 화면에서 주요 행동이 더 잘 보이도록 버튼 색만 바꿔 주세요”처럼 대상과 변경 범위를 제한하면 결과를 비교하기 쉽습니다. 구조를 바꿔야 한다면 색상과 글자 크기를 한꺼번에 손대지 말고 구조부터 정리합니다.

화면 캡처 피드백으로 고치는 방법

캡처를 만들 때는 임시 문구 대신 실제 제목과 설명을 넣고, 확인할 화면 크기를 정합니다. 캡처를 보며 제목과 본문의 위계, 왼쪽 정렬선, 요소 사이의 간격, 색의 대비, 글자 크기, 한 화면에 들어간 정보량을 차례로 살펴보세요. 먼저 눈에 띈 문제를 하나의 수정 목표로 바꾸고, 변경 전과 변경 후의 캡처를 비교합니다.

예를 들면 “화면이 답답합니다” 대신 “제목과 첫 설명 사이의 간격을 넓히고, 보조 설명의 크기를 낮춰 주요 버튼이 먼저 보이게 해 주세요”라고 요청할 수 있습니다. 수정 결과에서 실제로 버튼이 먼저 보이는지, 다른 요소의 정렬이 흐트러지지 않았는지 확인합니다.

AI 코딩 도구로 화면 캡처를 활용해 점진적으로 개선하기

한 번의 요청에 “색을 바꾸고, 글자를 키우고, 여백을 줄이고, 모바일 배치도 고쳐 주세요”를 모두 넣으면 무엇이 문제를 해결했는지 판단하기 어렵습니다. 이번 차례에는 정렬만 고치고 다음 차례에는 글자 위계를 살펴보는 식으로 목표를 나누세요. 요청을 반영한 뒤 같은 화면과 같은 문구로 다시 캡처하면 변경 효과를 비교할 수 있습니다.

텍스트 가독성은 화면 확대만으로 해결되지 않을 수 있습니다. W3C는 문자 간격과 줄 간격을 사용자가 조정했을 때도 콘텐츠가 손실되지 않는지 확인하는 기준을 안내합니다. 텍스트 간격 관련 설명을 참고해 줄이 겹치거나 버튼 안의 문구가 잘리지 않는지도 점검하세요. 키보드로 이동할 때 현재 위치가 보이는지, 움직이는 장식이 불편을 주지 않는지도 확인할 수 있습니다. 각각 초점 표시 기준과 움직임 줄이기 설정에 대응하는 방법을 참고하세요.

게시 전 눈으로 확인할 항목

기능 목록만 점검하면 시각적 결함을 놓칠 수 있습니다. 실제 문구와 주요 행동 경로를 사용해 다음 항목을 직접 확인하세요.

• [ ] 핵심 페이지에서 방문자가 먼저 읽어야 할 내용이 가장 먼저 보입니다.
• [ ] 같은 역할의 제목, 버튼, 카드가 페이지 사이에서 같은 규칙을 따릅니다.
• [ ] 텍스트와 배경의 대비를 실제 색 조합으로 확인했습니다.
• [ ] 화면 너비가 바뀌어도 본문이 잘리거나 의도하지 않은 가로 스크롤이 생기지 않습니다.
• [ ] 긴 제목과 실제 설명을 넣어도 줄바꿈, 버튼, 카드 높이가 어색해지지 않습니다.
• [ ] 키보드로 주요 동작에 접근할 때 현재 선택 위치가 보입니다.
• [ ] 버튼이나 링크를 누르거나 선택했을 때 상태 변화가 명확합니다.
• [ ] 화면의 장식 효과가 움직임을 줄이는 설정과 충돌하지 않습니다.

작은 화면에서 누를 요소가 너무 작지 않은지도 확인하세요. W3C의 기준은 예외 조건을 제외하고 클릭 대상이 최소 24 × 24 CSS 픽셀인지 살펴보도록 안내합니다. 클릭 대상 크기 설명을 기준으로 버튼과 주변 간격을 검수하되, 실제 사용 흐름에서도 누르기 쉬운지 확인해야 합니다.

이 항목을 통과하면 “더 고급스럽게” 같은 막연한 표현 대신 어떤 문제가 해결되었는지 설명할 수 있습니다. 반대로 핵심 내용이 먼저 보이지 않거나, 화면 크기에 따라 내용이 잘리거나, 주요 동작을 알아보기 어렵다면 아직 수정할 목표가 남아 있습니다.

다음 작업 환경을 고르는 기준

로컬 컴퓨터에서 작업하면 이미 쓰는 편집기와 파일에 바로 접근하기 쉽습니다. 다만 다른 기기에서 같은 화면을 확인하려면 별도 미리보기 환경을 준비해야 할 수 있고, 팀에서 한 장비를 함께 쓰면 작업이 겹칠 수 있습니다. 일반 서버는 웹 애플리케이션을 실행하는 데 쓸 수 있지만, Mac 전용 도구가 필요한 빌드나 검수까지 같은 방식으로 해결한다고 단정할 수는 없습니다.

따라서 먼저 화면 규칙과 검수 절차를 정하고, 작업 환경은 실제로 필요한 도구와 협업 방식에 맞춰 선택하세요. 임시로 원격 Mac에서 개발하거나 빌드해야 한다면, 개인 장비를 계속 공유하는 방식보다 필요한 기간에 Mac 환경을 빌려 쓰는 편이 작업을 분리하고 호환성 문제를 줄이는 데 유리할 수 있습니다. 다만 장기간 꾸준히 무거운 작업을 하거나 물리 장비에 직접 연결해야 한다면 소유 장비가 더 적합할 수 있습니다. 원격 환경의 지원 범위를 확인하려면 Hashvps 고객 지원 안내를 살펴보고, 필요한 작업이 가능한지 먼저 대조하세요.

AI 에이전트를 개발 환경에 추가할 계획이라면 화면 생성 문제와 실행 환경 선택 문제를 구분하는 것도 좋습니다. 기능이나 구성 방식을 확인할 필요가 있을 때는 Hashvps의 OpenClaw 안내를 참고하세요. 우선 이번 주에는 핵심 페이지 하나를 고르고, 디자인 규칙을 적용한 뒤 같은 문구와 화면 크기로 캡처를 비교해 보세요. 보기 좋은 화면은 한 번의 요청이 아니라, 확인 가능한 기준에 따라 고친 결과입니다.