클로드 기초 및 활용 15회: 나만의 디자인 규격 고정하기 — 매번 다르게 나오는 문제 끝내기

어제 만든 것과 오늘 만든 것이 남남처럼 보입니다

13·14회를 따라 해 보셨다면 이런 상황을 만나셨을 겁니다. 어제 만든 카드와 오늘 만든 페이지가 전혀 다른 곳에서 온 것처럼 보입니다. 색도 다르고 글자 크기도 다릅니다.

매번 기준을 적었는데도 그렇습니다. 왜냐하면 매번 조금씩 다르게 적었기 때문입니다. 어제는 "여백 넉넉히"라고 했고 오늘은 "여백 충분히"라고 했다면, 결과도 조금씩 달라집니다.

해결책은 하나입니다. 기준을 말이 아니라 문서로 만들어 두는 것.

오늘의 목표

오늘이 끝나면 할 수 있게 되는 것: 나만의 디자인 규격을 문서로 만들고, 그것을 프로젝트에 붙여 모든 결과물이 같은 얼굴을 갖게 만들 수 있습니다. 그리고 접근성 기준을 그 규격 안에 넣는 법을 알게 됩니다.

왜 규격이 필요한가 — 세 가지 이유

① 일관성. 여러 결과물이 같은 얼굴을 하고 있으면, 그것만으로 완성도가 올라갑니다. 각각은 평범해도 묶어 놓으면 정돈되어 보입니다.

② 판단 절약. 매번 "무슨 색으로 할까"를 고민하지 않아도 됩니다. 정해진 걸 씁니다. 그 에너지를 내용에 쓸 수 있습니다.

③ 기준 보존. 접근성 같은 기준은 매번 기억해서 적어야 한다면 반드시 빠집니다. 규격에 못 박아 두면 잊을 수가 없습니다.

디자인 규격에 들어갈 것들

규격은 길 필요가 없습니다. 한 페이지면 충분합니다. 들어갈 항목은 이렇습니다.

• 색 — 배경, 글자, 강조. 각각 하나씩
• 글자 — 최소 크기, 제목 크기, 글꼴 계열
• 간격 — 요소 사이, 덩어리 안쪽
• 모양 — 모서리 둥글기, 테두리, 그림자 사용 여부
• 금지 사항 — 하지 말아야 할 것들
• 접근성 기준 — 반드시 지켜야 할 최소선

마지막 두 항목이 특히 중요합니다. "하지 말 것"이 명시되어 있으면 결과가 훨씬 안정됩니다.

🔴 실제 사례 — SVIL 고대비 다크 표준

말로만 설명하면 감이 안 오니, 실제로 쓰이는 규격 하나를 통째로 보여 드리겠습니다. 이 시리즈를 만드는 SVIL 연구소가 쓰는 기준입니다.

이 규격은 저시력 사용자가 직접 만들고 매일 쓰는 것이라, 접근성이 장식이 아니라 뼈대에 들어가 있습니다. 그대로 쓰셔도 되고, 참고해서 자기 것을 만드셔도 됩니다.

SVIL 표준 — 색

• 배경: 아주 어두운 회색 계열. 순수한 검정(#000000)은 쓰지 않습니다 — 밝은 글자와의 대비가 너무 강해 눈이 피로해집니다
• 글자: 밝은 회색~흰색 계열. 연한 회색 글자 금지
• 강조: 청록(teal·cyan) 계열 한 가지만
• 금지: 웜톤(주황·금색)이 화면을 지배하는 것, 색을 네 가지 이상 쓰는 것

강조색을 하나로 제한하는 이유는 13회에서 말한 그대로입니다. 다 강조하면 아무것도 강조되지 않기 때문입니다.

SVIL 표준 — 글자

• 본문 최소 16픽셀. 예외 없습니다
• 제목은 본문보다 확실히 크게. 한 단계 차이로는 부족합니다
• 한 줄이 너무 길게 늘어지지 않게 폭을 제한합니다
• 글꼴은 한 계열로 통일. 여러 글꼴을 섞지 않습니다

"예외 없다"는 표현이 중요합니다. 규격에 예외를 허용하면 그 예외가 기본이 됩니다.

SVIL 표준 — 간격과 크기

• 누르는 요소는 충분히 크게 — 손가락으로 정확히 누를 수 있는 크기. 최소 50픽셀 정도를 기준으로 삼습니다
• 항목 사이 여백을 넉넉하게 — 빽빽한 화면은 확대 시 특히 읽기 어렵습니다
• 문단 사이를 분명히 띄웁니다 — 덩어리 구분이 보이게

터치 크기 기준이 규격에 들어 있는 이유가 있습니다. 이건 미관이 아니라 사용 가능 여부의 문제이기 때문입니다.

SVIL 표준 — 접근성 조항

이 부분이 이 규격의 핵심입니다.

• 색만으로 상태를 구분하지 않는다. 반드시 글자 라벨을 함께 붙인다
• 대비가 약한 회색 글자를 쓰지 않는다
• 가로 스크롤이 생기지 않게 한다
• 다크 테마를 기본으로 한다
• 문단 구분과 여백으로 가독성을 확보한다

이 다섯 줄은 취향이 아니라 요구사항입니다. 그래서 규격 문서에 "반드시"라고 적혀 있습니다. 이런 표현 차이가 실제로 결과를 바꿉니다.

내 규격 만드는 법

남의 규격을 그대로 쓰기보다, 자기 것으로 만드는 편이 낫습니다. 만드는 순서는 이렇습니다.

1단계: 지금까지 만든 결과물 중 가장 마음에 드는 것을 하나 고릅니다.
2단계: 클로드에게 그것을 분석시킵니다.
3단계: 나온 분석을 다듬어 규격 문서로 만듭니다.

2단계의 요청문은 이렇습니다.

"이 결과물의 디자인 규칙을 분석해서 재사용 가능한 규격 문서로 정리해 주세요. 색·글자 크기·간격·모양을 구체적인 값으로 적고, 하지 말아야 할 것도 함께 적어 주세요."

규격을 어디에 두나

8회에서 배운 프로젝트가 정답입니다.

프로젝트 지식에 규격 문서를 넣어 두면, 그 프로젝트 안의 모든 대화가 그 규격을 참고합니다. 매번 붙여 넣을 필요가 없습니다.

프로젝트를 쓸 수 없다면 메모장에 저장해 두고 필요할 때 붙여 넣으면 됩니다(12회). 효과는 같고 손이 조금 더 갈 뿐입니다.

따라 하기 ① 규격 초안 뽑기

지금까지 만든 결과물 중 하나를 골라, 앞의 요청문으로 규격을 뽑아 보세요.

나온 결과를 읽어 보면 "내가 이런 규칙을 쓰고 있었구나" 싶은 것들이 보입니다. 무의식적으로 하던 선택이 말로 정리되는 순간입니다.

따라 하기 ② 접근성 조항 추가하기

뽑힌 규격에 앞의 SVIL 접근성 다섯 줄을 그대로 추가하세요. 그대로 복사해도 됩니다.

이 다섯 줄은 어떤 디자인 방향에도 얹을 수 있습니다. 밝은 테마를 쓰든 어두운 테마를 쓰든, 대비를 높이고 색만으로 구분하지 않는 것은 항상 옳습니다.

따라 하기 ③ 프로젝트에 넣기

프로젝트를 하나 만들고(8회) 규격 문서를 프로젝트 지식에 넣으세요.

그리고 프로젝트 지침에 이 한 줄을 적습니다.

"모든 결과물은 프로젝트 지식의 디자인 규격을 따라 주세요."

이 한 줄이 규격을 참고 자료에서 지시로 바꿉니다.

따라 하기 ④ 검증하기

프로젝트 안에서 디자인 지시 없이 무언가를 만들어 보세요.

"우리 팀 일정표를 만들어 주세요."

색과 크기가 규격대로 나온다면 성공입니다. 안 나온다면 규격 문서가 너무 추상적이거나, 프로젝트 밖에서 만든 것입니다.

따라 하기 ⑤ 두 개 만들어 나란히 보기

같은 프로젝트에서 성격이 다른 것 두 개를 만들어 보세요. 예를 들어 일정표 하나, 소개 페이지 하나.

둘을 나란히 놓았을 때 같은 집안 물건처럼 보이면 규격이 작동하는 것입니다. 이게 오늘의 목표였습니다.

자주 겪는 오류 ① "규격을 넣었는데 안 지켜져요"

세 가지를 확인하세요.

① 프로젝트 안에서 만들었는가 — 8회에서 다룬 가장 흔한 실수입니다.
② 규격이 구체적인가 — "여백을 적절히"는 지킬 수가 없습니다. "24픽셀"이라야 지켜집니다.
③ 지침에 따르라고 적었는가 — 자료만 넣어 두면 참고 자료일 뿐입니다. "규격을 따르라"는 문장이 있어야 합니다.

오류 ② "규격이 너무 빡빡해서 답답해요"

모든 것을 못 박으면 결과가 경직됩니다. 6회·8회에서 다룬 문제와 같습니다.

못 박을 것과 남겨 둘 것을 구분하세요.

• 못 박기: 색, 최소 글자 크기, 접근성 조항
• 남겨 두기: 배치 방식, 요소 개수, 세부 표현

기준선은 고정하고 그 위에서는 자유롭게 — 이게 좋은 규격의 모습입니다.

오류 ③ "규격을 바꾸고 싶어졌어요"

당연한 일입니다. 규격은 고정된 법이 아니라 현재의 합의입니다.

바꾸실 때는 기존 문서를 고치세요. 새 버전을 따로 만들어 두 개가 공존하면, 어느 것이 최신인지 알 수 없어집니다(8회에서 다룬 문제입니다).

파일 이름에 날짜를 넣고, 바꿀 때마다 갱신하는 것을 권합니다.

오류 ④ "결과물마다 성격이 너무 달라요"

업무용 보고서와 개인 취미 페이지에 같은 규격을 쓰면 어느 한쪽이 어색해집니다.

이럴 땐 규격을 두 개로 나누세요. 프로젝트를 두 개 만들고 각각 다른 규격을 넣으면 됩니다.

다만 접근성 조항은 양쪽 모두에 넣으세요. 그건 성격과 무관하게 항상 필요합니다.

실전 사례 ① 개인 블로그 규격

블로그를 운영한다면 규격의 효과가 특히 큽니다. 글마다 형태가 다르면 어수선해 보이기 때문입니다.

규격에 넣을 것: 제목 단계 규칙, 문단 최대 길이, 강조 표시 방식, 이미지 자리, 마무리 형식.

그리고 8회에서 배운 대로 프로젝트 지식에 이전에 잘 쓴 글 한두 편을 함께 넣으면, 문체까지 일정해집니다.

실전 사례 ② 팀에서 함께 쓰는 규격

규격 문서의 진짜 가치는 나눌 수 있다는 것입니다.

팀원에게 규격 문서를 주면, 그 사람이 만든 결과물도 같은 얼굴을 갖게 됩니다. 디자인 감각을 나눠 주는 대신 기준을 나눠 주는 것입니다.

이때 중요한 것이 "왜"를 함께 적는 것입니다. "본문 16픽셀 이상 — 저시력 사용자를 포함한 모든 독자의 가독성을 위해." 이유를 알면 규격을 지키게 되고, 새로운 상황에서 판단할 수도 있게 됩니다.

실전 사례 ③ 접근성을 규격에 넣는다는 것의 의미

이 회차를 마무리하며 짚고 싶은 이야기가 있습니다.

접근성은 흔히 "여유가 되면 챙기는 것"으로 취급됩니다. 그런데 여유는 좀처럼 생기지 않습니다. 그래서 매번 빠집니다.

규격에 넣는다는 것은 그 순서를 뒤집는 일입니다. 대비와 글자 크기가 기본값이 되면, 지키기 위해 노력할 필요가 없어집니다. 어기려면 노력해야 하니까요.

그리고 실제로 해 보면 알게 되는 것이 있습니다. 접근성 기준을 지킨 결과물이 대체로 더 읽기 좋습니다. 저시력 사용자만을 위한 배려가 아니라, 피곤한 눈으로 보는 사람, 작은 화면으로 보는 사람, 밝은 야외에서 보는 사람 모두에게 좋습니다.

그러니 이건 양보가 아니라 더 나은 기본값입니다.

제3부를 마치며

13회부터 15회까지, 「클로드로 디자인하기」를 마칩니다.

• 13회 — "예쁘게"를 색·간격·크기·순서로 바꾸기
• 14회 — 용도별로 실제 결과물 만들기
• 15회 — 기준을 문서로 굳혀 계속 쓰기

이 세 회차의 요점은 하나입니다. 디자인은 감각이 아니라 결정의 집합이고, 결정은 말로 옮길 수 있으며, 말로 옮긴 것은 저장하고 재사용할 수 있다는 것입니다.

핵심 정리 3줄

• 매번 다르게 나오는 이유는 매번 다르게 말했기 때문입니다. 기준을 문서로 굳히세요.
• 못 박을 것과 남겨 둘 것을 구분하세요. 색·최소 크기·접근성은 고정, 배치와 표현은 자유.
• 접근성은 규격에 넣어야 지켜집니다. 매번 기억해서 챙겨야 한다면 반드시 빠집니다.

용어 정리

• 디자인 규격 — 색·글자·간격·금지 사항을 적어 둔 한 페이지짜리 기준 문서.
• 고대비 — 글자와 배경의 밝기 차이가 큰 상태. 읽기 쉬움의 기본 조건입니다.
• 터치 타겟 — 손가락으로 누르는 요소의 크기. 너무 작으면 누를 수 없습니다.
• 기준선 — 그 아래로는 내려가지 않는 최소 조건. 예외를 허용하면 무너집니다.
• 규격 공유 — 문서를 넘겨 다른 사람도 같은 결과를 내게 하는 것.

다음 회차 예고와 실습 과제

다음 회차부터 제4부 「클로드 코드 입문」(16~21회)이 시작됩니다. 2회에서 말한 '2층'으로 올라가는 구간입니다. 채팅과 무엇이 다른지, 개발자가 아니어도 쓸 수 있는 이유가 무엇인지부터 시작합니다. 터미널이 무서우셨던 분들을 위해 17회를 통째로 터미널 두려움 없애기에 할애했으니 안심하고 따라오세요.

실습 과제 두 가지

• ① 마음에 드는 결과물 하나를 골라 "디자인 규칙을 규격 문서로 정리해 주세요"를 요청하고, 거기에 접근성 다섯 줄을 추가해 보세요.
• ② 그 규격을 프로젝트에 넣고, 디자인 지시 없이 무언가를 만들어 규격대로 나오는지 확인해 보세요.

만드신 규격 중 "이 조항이 특히 잘 통하더라" 싶은 게 있으면 댓글로 공유해 주세요. 좋은 규격 조항은 그대로 다른 분들에게도 쓰입니다.

본 회차는 2026년 8월 2일 기준입니다. 프로젝트 기능의 제공 여부는 요금제·창구에 따라 다를 수 있습니다. 소개한 SVIL 고대비 다크 표준은 SVIL 연구소가 실제 운용 중인 기준이며, 그대로 쓰시거나 참고해 각자의 규격을 만드셔도 됩니다.

협업문의 : kuroicode@gmail.com
블로그 : https://ghost-production-0ec2.up.railway.app/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/