CLAUDE CODE

포인트 컬러 고르는 법: 웹사이트 색 조합 9가지를 같은 화면에 칠해 본 기록 (바이브코딩 UI 색상)

포인트 컬러(accent color) 고르는 법을 웹사이트 색 조합 9가지로 직접 확인했습니다. 같은 화면에 색만 바꿔 칠하고 명도 대비를 잰 뒤, Claude에게 색 규칙을 줬을 때와 안 줬을 때 만든 랜딩 페이지까지 비교했습니다.

작성자 샘호트만 (Sam Hottman)작성 2026년 10월 31일읽기 21분

색은 줄이고 포인트 컬러 딱 하나만이라는 제목과 60-30-10, 대비 4.5:1, 다크 모드, OKLCH 칩 옆에 같은 가계부 랜딩 화면을 색 과다 버전과 코발트 블루 포인트 하나 버전으로 겹쳐 세운 대표 이미지

얼마 전 바이브코딩 디자인 레퍼런스 사이트 글에서 AI에게 레퍼런스를 보여 주면 결과가 달라진다는 이야기를 했습니다. 바이브코딩(코드를 직접 짜지 않고 AI에게 말로 시켜서 서비스를 만드는 방식)으로 만든 화면이 밋밋해지는 이유는 여러 가지인데, 그중 손대기 가장 쉬운 게 색이라고 생각합니다.

그래서 최근 짧은 영상(쇼츠·릴스)에서 "사이트에 색을 많이 쓸수록 오히려 밋밋해 보인다, 포인트 컬러 하나만 바꿔 보라"는 이야기를 했습니다. 다만 영상은 40초가 안 되는 길이라 세 조합을 보여 주는 데서 끝났고 고르는 법은 담지 못했습니다.

이번 글에서는 포인트 컬러가 무엇인지부터 정리하고 영상 속 세 조합에 여섯 조합을 더해 같은 화면에 칠해 보겠습니다. 그다음 명도 대비를 재서 글자가 읽히는지 확인하고 마지막으로 Claude에게 색 규칙을 줬을 때와 안 줬을 때 만든 랜딩 페이지를 비교해 보겠습니다. 목업과 그림은 전부 스크립트로 직접 렌더했고 수치도 직접 계산한 값입니다.

(작성일 2026-10-31 기준입니다. 대비 기준은 웹 접근성 국제 기준인 WCAG(Web Content Accessibility Guidelines) 2.2를 따랐습니다. 목업 속 "moa"는 이전 글에서도 썼던 가상의 서비스 이름이고 실제 서비스가 아닙니다.)

사용 도구 및 준비물

Claude Code Playwright WCAG 2.2 명도 대비 기준

포인트 컬러란?

포인트 컬러(accent color)는 화면 대부분을 차지하는 차분한 색들 위에 아주 조금만 얹어서 눈길을 한곳으로 모으는 색입니다. 교과서에 형광펜을 긋는 것과 비슷합니다. 중요한 줄에만 그으면 다시 펼쳤을 때 거기부터 보이지만 모든 줄에 그으면 아무 데도 안 그은 것과 같아집니다.

이 비율을 숫자로 말할 때 자주 나오는 게 60-30-10 규칙입니다. 바탕색 60%, 보조색 30%, 포인트 색 10%로 나누라는 경험칙입니다. UX 리서치 회사인 NN/g(Nielsen Norman Group)의 색 활용 글에서도 이 규칙을 소개하면서 포인트 색은 주 CTA(사용자가 눌렀으면 하는 핵심 버튼)처럼 가장 돋보여야 할 곳에 아껴 두라고 합니다. 원래는 인테리어 쪽에서 쓰던 말이라고 합니다(벽 60, 가구 30, 소품 10). 다만 누가 처음 만들었는지 1차 출처는 찾지 못했습니다. 실험으로 검증된 법칙이라기보다 출발점으로 쓰는 어림셈 정도로 보는 게 맞는 것 같습니다.

포인트 색이 눈에 띄는 이유는 심리학에서 폰 레스토프 효과(Von Restorff effect, 고립 효과)라고 부르는 현상으로 설명합니다. 비슷한 것들 사이에서 하나만 다르면 그 하나가 더 잘 기억된다는 내용입니다. 1933년 Hedwig von Restorff가 비슷한 항목 목록 속에 다른 항목 하나를 섞어 기억 실험을 한 게 출발점입니다. 디자인 원칙을 모아 둔 Laws of UX 페이지는 여기서 실무 조언을 두 가지 끌어냅니다. 강조끼리 경쟁하지 않게 아껴 쓸 것, 그리고 대비를 색으로만 주지 말 것(색을 구분하기 어려운 사람이 있으니까)입니다. 둘 다 아래에서 직접 확인해 보겠습니다.

영상에서는 이 원리를 이렇게 보여 줬습니다. 스카이 블루와 화이트로 만든 숙소 예약 앱 위에 핫핑크를 얹는 장면입니다.

마지막 프레임을 보면 핫핑크가 칠해진 곳은 "Book now" 버튼, "Only 2 left" 배지, 하트 세 군데뿐입니다. 나머지는 전부 스카이 블루와 화이트입니다.

영상 속 세 조합

영상에 나온 세 조합을 하나씩 정지 화면으로 보겠습니다. 화면 속 서비스(Driftnest, Mixvane, Brightlane)는 영상을 위해 만든 가상의 제품이고 왼쪽은 바탕 두 색만 쓴 장면, 오른쪽은 포인트를 얹은 장면입니다.

첫 번째는 스카이 블루·화이트 위에 핫핑크입니다. (왼쪽과 오른쪽은 영상 속 다른 장면이라 화면 위치가 조금 다릅니다.) 스카이 블루는 카테고리 칩이나 로고처럼 "이 서비스의 색"을 보여 주는 데 쓰였고 핫핑크는 예약과 관련된 것에만 쓰였습니다.

두 번째는 미드나잇 블랙·일렉트릭 블루 위에 오렌지입니다. 왼쪽만 봐도 깔끔하지만 세 요금제 중 무엇을 눌러야 할지는 잘 안 보입니다. 오른쪽은 Pro 요금제의 버튼과 배지가 오렌지로 바뀌면서 시선이 가운데 카드로 모입니다.

세 번째는 딥 블루·화이트 위에 버블검 핑크입니다. 이 조합은 바탕이 진한 색이라 흰색이 보조색 역할을 합니다. 핑크 버튼의 글자를 흰색이 아니라 딥 블루로 쓴 이유는 아래 대비 부분에서 설명하겠습니다.

그런데 60-30-10대로라면 포인트가 화면의 10%쯤 돼야 합니다. 실제로 얼마나 칠해졌는지 궁금해서 재 봤습니다. 화면을 OKLCH 색 공간(사람 눈 기준으로 밝기·채도·색상을 나눈 표기, 아래에서 다시 설명합니다)으로 바꾼 뒤, 포인트 색과 색상각이 15° 안쪽이고 채도가 일정 이상인 픽셀만 셌습니다.

조합	포인트를 칠한 곳	포인트 색 픽셀 비율
1. 스카이 블루·화이트 + 핫핑크	예약 버튼, 배지, 하트	3.8%
2. 미드나잇 블랙·일렉트릭 블루 + 오렌지	추천 요금제 버튼, 배지, 가격 밑줄	1.2%
3. 딥 블루·화이트 + 버블검 핑크	시작 버튼, New 배지	1.2%

10%는커녕 1~4%였습니다. 그래도 화면을 처음 봤을 때 눈이 가는 곳은 셋 다 포인트 쪽이었습니다. 60-30-10의 10은 "이만큼 칠하라"는 목표라기보다 "이 이상은 칠하지 말라"는 상한선으로 읽는 편이 실제와 맞는 것 같습니다.

새로 더한 여섯 조합

영상 속 세 조합만으로는 분위기가 한쪽(파랑 계열 + 핑크·오렌지)에 몰려 있어서 여섯 조합을 더 만들었습니다. 비교가 공정하려면 화면은 같고 색만 달라야 해서 가상의 가계부 서비스 moa의 랜딩 화면 하나를 HTML로 짜 두고 색만 바꿔 끼웠습니다.

화면마다 세 가지 버전을 렌더했습니다.

2색만: 바탕과 보조색 두 가지만 씀. 시작 버튼도 보조색
포인트 하나: 같은 화면에서 시작 버튼, 금요일 막대, "이번 달 아낀 돈" 숫자 세 곳만 포인트 색으로 바꿈
색 과다: 로고, 제목 강조, 배지, 버튼, 막대마다 다른 색을 씀 (바이브코딩으로 만든 사이트에서 자주 보는 모습을 흉내 냄)

먼저 두 바탕색만 쓴 화면과 포인트를 더한 화면입니다.

왼쪽도 단정하긴 한데 어디부터 봐야 할지 단서가 없습니다. 오른쪽은 체리 레드가 들어간 세 곳(시작 버튼, 금요일 막대, +₩128,400)이 먼저 들어오고 그다음에 제목을 읽게 됩니다. 바뀐 건 요소 세 개의 색뿐입니다.

다음은 영상 첫 문장("색을 많이 쓸수록 오히려 밋밋해 보인다")을 확인해 본 화면입니다.

왼쪽은 화려한데 막상 눌러야 할 버튼이 잘 안 보입니다. 보라 버튼 옆에 주황 카드, 초록 글자, 분홍 숫자가 같은 세기로 소리를 내고 있어서 그렇습니다. 폰 레스토프 효과는 "다른 하나"가 있어야 작동하는데, 전부 다르면 다른 게 없어집니다. 밋밋해 보인다는 말은 색이 적어서가 아니라 어디에도 무게가 실리지 않아서 생기는 느낌인 것 같습니다.

이걸 조금 더 객관적으로 보려고 디자이너들이 쓰는 흐려 보기 테스트(화면을 흐리게 만들어서 그래도 남는 곳을 보는 방법)를 해 봤습니다.

흐린 화면에서 "포인트 하나" 버전은 파란 버튼과 파란 막대가 또렷하게 남습니다. "색 과다"는 색 덩어리가 여기저기 남아서 어디가 중요한지 오히려 더 헷갈립니다. "2색만"은 큰 카드 머리만 남고 버튼은 사라집니다.

이제 새로 만든 여섯 조합을 하나씩 보겠습니다. 번호는 영상 속 세 조합 다음부터 4~9번으로 붙였고 색 띠의 60·30·10은 역할 표시일 뿐 실제 면적은 위에서 잰 것처럼 포인트가 훨씬 적습니다.

4번 크림·세이지 그린·체리 레드는 카페나 리빙, 동네 가게처럼 따뜻한 분위기에 어울린다고 봤습니다. 세이지 그린은 채도가 낮은 초록이라 체리 레드와 부딪히지 않고 받쳐 주는 쪽입니다.

5번 차콜 블랙·쿨 그레이·라임은 개발자 도구나 핀테크 쪽 느낌입니다. 바탕 두 색이 거의 무채색이라 라임 하나만 색이 있고, 그래서 아홉 조합 중 포인트가 가장 세게 튑니다.

6번 화이트·네이비·옐로는 교육·금융·공공 서비스에서 많이 보이는 믿음직한 조합입니다. 다만 노랑은 흰 바탕 위에서 글자로 쓰면 거의 안 읽혀서 면으로만 쓰고 그 위 글자는 네이비로 했습니다.

7번 오트밀·에스프레소·코발트 블루는 개인적으로 아홉 개 중 가장 마음에 들었습니다. 따뜻한 갈색 계열 바탕에 차가운 파랑이 들어가니 잡지나 쇼핑몰처럼 정돈된 느낌이 납니다.

8번 라벤더 그레이·잉크 퍼플·탠저린은 커뮤니티나 이벤트 페이지처럼 조금 들뜬 분위기에 맞습니다. 이 조합은 아래 대비 부분에서 약점이 하나 나옵니다.

9번 오프화이트·잉크 블랙·일렉트릭 바이올렛은 포트폴리오나 AI 서비스에서 요즘 자주 보이는 조합입니다. 흑백에 가까운 화면이라 바이올렛이 어디에 있는지 바로 보입니다.

아홉 개를 한 장에 모았습니다. 같은 화면이라 색만 비교하기 좋습니다.

복사해서 쓰실 수 있게 HEX 값(색을 여섯 자리 코드로 적은 것)을 표로 정리했습니다.

번호	바탕 (60)	보조 (30)	포인트 (10)	어울리는 곳
1	화이트 `#FCFFFF`	스카이 블루 `#0593C6`	핫핑크 `#D83995`	산뜻한 서비스·여행
2	미드나잇 블랙 `#02070A`	일렉트릭 블루 `#0297DE`	오렌지 `#FC734D`	다크 테크·크리에이터 툴
3	딥 블루 `#09318D`	화이트 `#FFFFFF`	버블검 핑크 `#FD91CC`	SaaS·협업 툴
4	크림 `#F4EEDF`	세이지 그린 `#8FA68B`	체리 레드 `#D2203D`	카페·리빙·로컬 브랜드
5	차콜 블랙 `#17181B`	쿨 그레이 `#8E9197`	라임 `#C6F43D`	개발자 도구·핀테크
6	화이트 `#FBFCFE`	네이비 `#16235C`	옐로 `#FFD12E`	교육·금융·공공
7	오트밀 `#EFE8DC`	에스프레소 `#3B2A20`	코발트 블루 `#2F5BEA`	에디토리얼·커머스
8	라벤더 그레이 `#ECE9F3`	잉크 퍼플 `#2B2540`	탠저린 `#FF7A1A`	커뮤니티·이벤트
9	오프화이트 `#F6F5F1`	잉크 블랙 `#141414`	일렉트릭 바이올렛 `#6E3BFF`	포트폴리오·AI 서비스

목업에서도 포인트 색 면적을 재 보니 아홉 장 모두 2.3%였습니다(세 곳만 칠했으니 당연히 같습니다). 영상 속 화면의 1~4%와 비슷한 범위입니다.

아홉 개를 놓고 보니 공통점이 하나 보였습니다. 바탕 쪽 색과 포인트 색이 색상환에서 꽤 멀리 떨어져 있다는 점입니다. 이것도 OKLCH 기준으로 재 봤습니다.

바탕에 색이 있는 일곱 조합은 포인트가 색상환에서 84~178° 떨어져 있었습니다(180°가 정반대 색, 흔히 말하는 보색입니다). 그중 거리가 가장 가까운 3번(84°)은 대신 밝기 차이가 0.43으로 컸습니다. 진한 딥 블루 위에 밝은 핑크라서 그렇습니다. 반대로 1번과 2번은 색상 거리는 멀지만 밝기 차이가 0.01, 0.07로 거의 없습니다. 이게 아래에서 문제가 됩니다.

정리하면 포인트 색은 바탕과 색상이 멀거나, 색상이 가깝다면 밝기라도 크게 달라야 튀는 것 같습니다. 5번과 9번처럼 바탕이 무채색(검정·회색·흰색)이면 어떤 색을 올려도 포인트가 되니 처음 시도하기에는 이쪽이 가장 쉽습니다.

명도 대비와 다크 모드

눈에 띄는 색을 고르다 보면 놓치기 쉬운 게 글자가 읽히는지입니다. 여기서 쓰는 잣대가 명도 대비(contrast ratio)입니다. 두 색의 밝기 차이를 1:1(같은 밝기)부터 21:1(흰색과 검정)까지 숫자로 나타낸 값입니다.

1. 글자 대비

WCAG 2.2의 1.4.3 항목은 일반 글자는 배경과 4.5:1 이상, 큰 글자는 3:1 이상이어야 한다고 정합니다. 큰 글자는 18pt 이상이거나 14pt 이상의 굵은 글씨인데, W3C 해설 문서는 이를 화면 기준 약 24px, 굵게 약 18.5px로 적고 있습니다. 버튼 모양이나 아이콘처럼 글자가 아닌 UI 요소는 1.4.11 항목에서 3:1을 요구합니다.

영상 속 세 포인트와 새 조합의 노랑을 이 기준으로 재 봤습니다.

눈에 띄는 색일수록 함정이 많았습니다. 오렌지와 버블검 핑크는 흰 글자를 얹으면 2점대로 떨어집니다. 그래서 영상 속 화면에서도 오렌지 버튼에는 어두운 글자를, 핑크 버튼에는 딥 블루 글자를 썼습니다. 의외였던 건 핫핑크입니다. 흰 글자(4.25)도 검은 글자(4.44)도 4.5에 조금씩 모자랍니다. 밝기가 딱 중간이라 어느 쪽 글자를 얹어도 대비가 애매하게 나옵니다.

아홉 개 포인트 색 전부를 정리하면 이렇습니다.

번호	포인트 색	흰 글자	검은 글자(#111111)	버튼 글자는
1	핫핑크 `#D83995`	4.25	4.44	크게·굵게 쓰거나 색을 조금 어둡게
2	오렌지 `#FC734D`	2.73	6.92	검은 글자
3	버블검 핑크 `#FD91CC`	2.08	9.08	어두운 글자 (딥 블루 5.50)
4	체리 레드 `#D2203D`	5.23	3.61	흰 글자
5	라임 `#C6F43D`	1.28	14.75	검은 글자
6	옐로 `#FFD12E`	1.46	12.96	어두운 글자 (네이비 10.08)
7	코발트 블루 `#2F5BEA`	5.52	3.42	흰 글자
8	탠저린 `#FF7A1A`	2.61	7.24	검은 글자
9	일렉트릭 바이올렛 `#6E3BFF`	5.63	3.36	흰 글자

핫핑크는 색상과 채도는 그대로 두고 밝기(OKLCH의 L)만 0.61에서 0.59로 낮추면 #D1318F가 되고 흰 글자 대비가 4.62로 기준을 넘습니다. 눈으로 보면 거의 차이가 없는 수준인데 숫자는 통과합니다.

8번은 다른 쪽에서 걸렸습니다. 탠저린 버튼 위 검은 글자는 7.24로 충분한데, 버튼 자체와 라벤더 그레이 바탕의 대비가 2.18이라 1.4.11의 3:1에 못 미칩니다. 버튼 글자는 잘 읽혀도 버튼 모양이 바탕에 살짝 묻힐 수 있다는 뜻입니다. 바탕을 조금 더 진하게 하거나 버튼을 흰 카드 위에 올리는 쪽이 안전할 것 같습니다.

2. 색으로만 구분하지 않기

WCAG 1.4.1 항목은 정보를 전달하거나 행동을 유도할 때 색 하나에만 기대지 말라고 합니다. 이유는 간단합니다. Colour Blind Awareness 자료에 따르면 남성 약 12명 중 1명, 여성 약 200명 중 1명이 색각 이상이고 미국 국립안과연구소(NEI)도 남성 약 12명 중 1명이라고 적고 있습니다.

위에서 1번과 2번의 밝기 차이가 거의 없다고 했는데, 포인트 색과 보조색 사이의 명도 대비로 보면 1.21:1과 1.19:1입니다. 밝기만 남기면 어떻게 보이는지 흑백으로 바꿔 봤습니다.

흑백으로 보면 1번과 2번은 포인트 버튼과 보조색 카드 머리가 비슷한 회색이 됩니다. 색으로는 확 튀던 핫핑크와 오렌지가 밝기로는 거의 구분되지 않는 겁니다. 7번은 흑백에서도 버튼과 카드 머리가 확실히 다릅니다. (흑백 변환은 색각 이상을 그대로 흉내 낸 건 아니고, 밝기 차이를 눈으로 확인하는 정도의 간이 테스트입니다.)

그래서 포인트 색에는 색 말고도 단서를 같이 주는 게 좋습니다. 버튼이면 버튼 모양과 "무료로 시작하기 →" 같은 글자, 숫자면 굵기와 크기, 막대면 위에 숫자 라벨을 다는 식입니다. 위 목업들도 포인트 색을 빼도 버튼은 버튼처럼 보이게 만들어 두었습니다.

3. 다크 모드

다크 모드에서는 같은 포인트 색이 다르게 행동합니다. Google의 Material Design 다크 테마 가이드(Codelab과 Wear OS 색 문서)는 어두운 바탕에서 채도 높은 색을 그대로 쓰지 말라고 합니다. 어두운 면 위에서는 글자 대비를 맞추기 어렵고 색이 떨려 보여 눈이 피로하다는 이유입니다. 대신 한 단계 밝고 덜 진한 톤을 권합니다.

9번 조합을 다크 모드로 뒤집어서 확인해 봤습니다. 잉크 블랙을 바탕으로, 짙은 회색을 보조색으로 바꾸고 바이올렛은 그대로 둔 것과 밝기만 올린 것을 비교했습니다.

원래 바이올렛 #6E3BFF는 검은 바탕(#141414)과 대비가 3.27이라 버튼이 어둠에 반쯤 묻힙니다. 색상과 채도는 두고 OKLCH 밝기만 0.545에서 0.66으로 올린 #8B78FF는 5.46이 나오고 같은 바이올렛인데 훨씬 또렷합니다.

여기서 OKLCH를 쓴 이유를 짧게 적어 두겠습니다. 흔히 쓰는 HSL은 숫자상 밝기가 같아도 노랑과 파랑이 눈에는 전혀 다른 밝기로 보입니다. OKLCH의 L은 사람 눈이 느끼는 밝기에 맞춰 설계된 값이라 "색은 그대로, 밝기만 조금 올려" 같은 조정을 할 때 색이 틀어지지 않습니다. Tailwind CSS도 v4부터 기본 팔레트 전체를 OKLCH로 바꿨다고 합니다. (OKLCH가 완벽하게 균일한 건 아니고, HSL보다 사람 눈에 훨씬 가깝다 정도로 이해하시면 될 것 같습니다.)

AI에게 색 맡기기

여기까지 정리하고 나니 궁금해졌습니다. 바이브코딩할 때 색을 따로 말하지 않으면 AI는 색을 어떻게 쓸까요? 그리고 위에서 정리한 규칙을 몇 줄로 붙이면 얼마나 달라질까요?

같은 랜딩 페이지 요청을 Claude Code에 두 번 넣어 봤습니다. Claude Code 2.1.316을 화면 없이 실행하는 모드(claude -p)로 돌렸습니다. 모델은 따로 지정하지 않았는데 Claude Opus 5.5로 돌았고 매번 새 세션이었습니다. A에는 아래 요청만 넣었습니다.

가계부 앱 'moa'의 랜딩 페이지를 HTML 파일 하나로 만들어줘. 상단 메뉴, 히어로(제목·설명·시작 버튼), 기능 소개 3개, 요금제 2개(무료·프로), 맨 아래 가입 유도 영역까지 넣어줘. 폭 1280px 화면 기준. 외부 이미지·외부 폰트 없이 CSS는 <style> 안에. 설명 없이 완성된 HTML 코드 블록 하나만 출력해.

B에는 같은 요청 뒤에 색 규칙 네 줄을 붙였습니다. 위 7번 조합(오트밀·에스프레소·코발트 블루)을 그대로 썼습니다.

색 규칙:

색은 세 가지만 쓴다. 바탕 #EFE8DC(오트밀)이 화면의 대부분, 보조 #3B2A20(에스프레소)는 글자·카드 머리·아이콘, 포인트 #2F5BEA(코발트 블루)는 아주 조금만.

포인트 색은 사용자가 눌렀으면 하는 곳(주 시작 버튼, 프로 요금제 버튼)과 핵심 숫자 한 곳에만 쓴다. 제목·배경·장식·아이콘에는 쓰지 않는다.

이 세 색의 명도만 바꾼 색(테두리·흐린 글자용)은 써도 되지만, 다른 색상이나 그라데이션은 추가하지 않는다.

포인트 색 위 글자는 대비 4.5:1 이상이 되게 한다.

결과 HTML은 손대지 않고 브라우저(Chromium, 폭 1280px)에서 그대로 열어 전체 화면을 찍었습니다. 그리고 화면에 보이는 요소 하나하나의 글자색·배경색·테두리색을 읽어서 채도가 있는 색(OKLCH 채도 0.06 초과)이 칠해진 요소를 색 계열별로 셌습니다. 아이콘 하나는 1개로 셌습니다.

솔직히 A는 예상과 달랐습니다. 영상에서 말한 것처럼 색을 마구 쓸 줄 알았는데, Claude는 초록(#1B7F5B) 하나를 브랜드 색으로 정하고 꽤 단정하게 만들었습니다. 문제는 그 초록을 쓴 곳입니다. 로고, 상단 "무료로 시작" 버튼, 작은 배지, 제목의 "한눈에.", 히어로 시작 버튼, 체크 아이콘들, 프로 요금제 테두리와 "추천" 배지, 연간 가격, 맨 아래 버튼까지 초록이 칠해진 요소가 36개였습니다. 차트에는 파랑·노랑·주황이 12개 요소에 더 들어갔습니다. 버튼 네 개가 전부 같은 초록이라 어느 것이 주인공인지 구분이 없습니다. 색은 하나인데 포인트는 없는 화면입니다.

B는 코발트 블루가 히어로 시작 버튼, "14%" 숫자, 프로 요금제 버튼 세 곳(요소로는 4개)에만 들어갔습니다. 맨 아래 가입 버튼은 일부러 에스프레소로 칠해서 주 시작 버튼과 겹치지 않게 했습니다. CSS 맨 위에는 색 변수를 먼저 선언하고 주석에 대비값까지 적어 두었습니다.

HLJS CSS

:root {
  /* 기본 3색 */
  --oat: #EFE8DC;            /* 바탕: 화면의 대부분 */
  --espresso: #3B2A20;       /* 글자 · 카드 머리 · 아이콘 */
  --cobalt: #2F5BEA;         /* 포인트: 주 시작 버튼 · 프로 버튼 · 핵심 숫자 1곳 */

  /* 위 3색에서 명도만 바꾼 파생색 (색상·채도 유지) */
  --oat-light: #FBF9F6;      /* 코발트 위 글자 (대비 5.2:1) */
  --espresso-soft: #74523E;  /* 흐린 글자 (오트밀 위 대비 5.7:1) */
}

(B가 만든 코드에서 색 변수 부분만 옮기고 나머지 파생색 몇 줄은 줄였습니다.) 주석의 대비값이 맞는지 직접 계산해 보니 5.25와 5.71로 맞았습니다.

아쉬운 점도 하나 있었습니다. B는 히어로 옆 카드에 "가입자 12,480명의 실제 지출 기록 기준"이라는 문구를 지어 넣었습니다. 색과는 상관없지만 가상의 서비스에 근거 없는 숫자를 넣은 것이라 실제 서비스였다면 지워야 합니다. 바이브코딩으로 만든 페이지는 색만큼이나 이런 문구도 한 번씩 확인해야 할 것 같습니다. (A는 4분 18초, B는 6분 50초 걸렸습니다.)

이 실험으로 보면 AI에게 색을 맡길 때 중요한 건 "무슨 색"보다 "어디에 칠할지"였습니다. 색 이름만 주면 AI는 그 색을 브랜드 색으로 보고 여기저기 칠합니다. 칠할 곳과 칠하지 말 곳을 같이 적어 줘야 포인트가 됩니다. 아래는 위 규칙을 다른 조합에도 쓸 수 있게 빈칸으로 바꾼 버전입니다.

색 규칙:

색은 세 가지만 쓴다. 바탕 [HEX]가 화면의 대부분, 보조 [HEX]는 글자·카드 머리·아이콘, 포인트 [HEX]는 아주 조금만.

포인트 색은 사용자가 눌렀으면 하는 곳(주 버튼 1~2개)과 핵심 숫자 한 곳에만 쓴다. 제목·배경·장식·아이콘에는 쓰지 않는다.

세 색의 명도만 바꾼 색은 써도 되지만, 다른 색상이나 그라데이션은 추가하지 않는다.

포인트 색 위 글자는 대비 4.5:1 이상이 되게 한다. 다크 모드가 있으면 포인트 색을 한 단계 밝게 한 값을 따로 둔다.

하나 더 조심할 게 있습니다. 디자인 시스템마다 "포인트 색"을 부르는 이름이 다릅니다.

디자인 시스템	포인트 색 역할	주의할 점
Material Design 3	primary(눈에 띄는 버튼·활성 상태), tertiary(대비되는 강조용)	역할이 여러 개로 나뉨
Apple HIG	accent color (macOS에서 버튼·선택 하이라이트·사이드바 아이콘)	사용자가 시스템에서 다른 색을 고르면 그 색이 우선
shadcn/ui	`--primary`	`--accent`는 메뉴 hover 같은 은은한 배경용
Tailwind CSS	이름 없이 팔레트로 제공 (v4부터 OKLCH)	역할은 직접 정해야 함

특히 shadcn/ui(Theming 문서)가 헷갈립니다. 이름이 --accent라서 포인트 색 같지만 실제로는 메뉴 하이라이트나 hover된 줄처럼 은은한 배경에 쓰는 값이고 기본값도 거의 흰색(oklch(0.97 0 0))입니다. 버튼 색은 --primary가 맡습니다. shadcn/ui로 만든 프로젝트에서 "accent 색을 코발트 블루로 바꿔 줘"라고 하면 AI가 이름만 보고 --accent를 바꿀 수 있고, 그러면 버튼은 그대로인데 메뉴 hover 배경이 코발트 블루로 칠해집니다. 이런 프로젝트에서는 "--primary를 코발트 블루로"라고 변수 이름까지 짚어 주는 게 안전합니다.

개인적인 생각 & 한계점

색 조합을 고르는 건 결국 취향이라 정답은 없는 것 같습니다. 다만 이번에 아홉 개를 같은 화면에 칠해 보면서 포인트 색은 무슨 색을 고르느냐보다 어디에 칠하느냐가 결과를 더 크게 바꾼다는 걸 느꼈습니다. 위 실험에서 A의 초록도 색 자체는 괜찮았습니다. 서른여섯 군데에 칠해서 포인트가 아니게 됐을 뿐입니다.

상황별로 제가 고르는 순서를 적어 보겠습니다.

1. 이미 브랜드 색이 있는 경우 - 브랜드 색을 버튼마다 칠하지 말고 보조색(30) 자리에 둡니다. 포인트는 색상환에서 브랜드 색과 멀리 떨어진 색 중에서 하나 고릅니다. 위 표를 보면 일곱 조합 중 여섯 개가 116° 이상 떨어져 있었습니다.

2. 색을 처음 정하는 경우 - 위 아홉 개 중 서비스 분위기에 맞는 걸 하나 골라 HEX 세 개를 그대로 프롬프트에 넣습니다. 고르기 어렵다면 5번이나 9번처럼 바탕이 무채색인 조합부터 시작하는 걸 추천합니다. 어떤 포인트를 올려도 잘 튀어서 실패할 일이 적습니다.

3. 다크 모드까지 지원해야 하는 경우 - 포인트 색을 라이트용과 다크용 두 벌로 정해 둡니다. 9번 조합에서는 OKLCH 밝기만 0.1 남짓(0.545 → 0.66) 올린 값으로 충분했습니다.

그리고 어떤 경우든 마지막에 대비는 꼭 한 번 재 보시는 걸 권합니다. 눈으로 보기에 잘 보이는 핫핑크도 숫자로는 기준에 못 미쳤습니다.

한계도 적어 두겠습니다.

목업은 가계부 화면 한 장이고 아홉 조합은 제 취향으로 고른 것입니다. 검증된 정답 조합이 아니라 출발점으로 봐 주시면 좋겠습니다.
포인트 면적은 포인트 색과 색상각이 15° 안쪽인 픽셀을 센 값이라 그림자나 글자 테두리가 섞이면 조금씩 달라질 수 있습니다.
대비는 현재 기준인 WCAG 2.2 공식으로 계산했습니다. 다음 버전인 WCAG 3.0은 작성일 기준 아직 초안(2026-09 Working Draft)이고 대비 계산 방식도 정해지지 않아서 앞으로 기준이 바뀔 수 있습니다.
흑백 테스트는 색각 이상을 그대로 흉내 낸 시뮬레이션이 아닙니다.
Claude 실험은 A·B 각 1회입니다. 같은 요청도 돌릴 때마다 결과가 달라서 "색 규칙을 주면 항상 이렇게 된다"고 일반화하긴 어렵습니다.
폰 레스토프 효과는 기억 실험에서 나온 개념이라 "포인트 색을 쓰면 클릭이 늘어난다"는 근거는 아닙니다. 이 글에서도 클릭률을 잰 적은 없습니다.
마지막으로 제 영상도 완벽하진 않았습니다. 1번 화면의 "Book now" 버튼은 핫핑크 위 흰 글자라 엄밀히 따지면 큰 글씨 기준(3:1)에만 맞습니다. 다음에 이 조합을 쓸 때는 위에서 찾은 #D1318F로 바꿀 생각입니다.

이 글을 마치며 & Reference

기회가 되면 다음 글에서는 이번에 정한 색 규칙을 디자인 규칙 파일로 묶어서 Claude Code가 매번 지키게 하는 방법을 다뤄 보겠습니다. 프롬프트에 매번 붙여 넣는 것보다 파일 하나로 두는 쪽이 오래 쓰기 편할 것 같습니다.

색 다음으로 화면 인상을 크게 바꾸는 건 폰트인데, 이건 모션그래픽 폰트 조합 글에서 무료 폰트 짝 65개를 직접 입혀 보며 정리했습니다. AI에게 디자인 규칙을 주는 도구 쪽은 Claude Code 프론트엔드 디자인 도구 글을 같이 보시면 좋습니다.

WCAG 2.2 Understanding: Contrast (Minimum) : 글자 대비 4.5:1·3:1 기준과 "큰 글자"의 정의. px 환산(약 24px, 굵게 약 18.5px)도 여기 해설에 있음
Laws of UX: Von Restorff Effect : 폰 레스토프 효과 정의와 실무 조언. 강조를 아껴 쓰고 색에만 기대지 말라는 내용이 짧게 정리되어 있음
NN/g: Using Color to Enhance Your Design : 60-30-10 규칙을 UI 맥락에서 소개한 글(Kelley Gordon, 2021). 포인트 색은 주 CTA에 아끼라는 조언
Google Codelab: Design a dark theme with Material and Figma : 다크 테마에서 채도 높은 색이 떨려 보이는 이유와 대신 쓸 톤
shadcn/ui Theming : --primary와 --accent의 용도 차이를 표로 정리한 문서. shadcn/ui로 바이브코딩한다면 한 번 보는 걸 권함
Evil Martians: OKLCH in CSS : HSL 대신 OKLCH를 쓰는 이유. 밝기만 조정할 때 왜 색이 안 틀어지는지 그림으로 설명