09중급과정180분 (이론 45 + 실습 135)

프로덕션 품질

“남에게 보여줄 수 있는 수준으로”

02이 차시를 마치면

1.색·타이포·간격처럼 반복되는 디자인 값을 디자인 토큰으로 뽑아 한 곳에서 관리할 수 있다.
2.화면마다 다르게 만들어진 버튼·입력창 등 컴포넌트의 일관성을 점검하고 정리할 수 있다.
3.명도 대비·키보드 탐색·대체 텍스트 등 접근성 기본 항목을 점검하고 고칠 수 있다.
4.AI가 생성한 코드에서 입력 검증·인증·시크릿·의존성 관련 흔한 취약점을 찾아 점검 리포트로 정리할 수 있다.
5.느린 지점을 성능 점검으로 찾아내고 우선순위를 매길 수 있다.

03왜 필요한가

기본과정을 마치고 서비스를 배포한 지 몇 주가 지났다. 이제 이 링크를 회사 동료나 잠재 고객에게 보여줘야 하는 순간이 왔다. 그런데 막상 화면을 다시 살펴보니 버튼 색이 페이지마다 미묘하게 다르고 여백도 들쭉날쭉하다. 모바일에서는 버튼이 눌리는지조차 헷갈리는 곳도 있다. 무엇보다 이 코드 대부분을 AI에게 빠르게 요청해서 만들었기 때문에, 어디에 보안 구멍이 있을지 스스로 확신이 서지 않는다.

화면마다 색과 버튼 스타일이 조금씩 달라 하나의 서비스처럼 보이지 않는다.
키보드만으로 조작이 안 되거나 스크린리더가 읽지 못하는 요소가 있어도 만든 사람은 알아채기 어렵다.
AI가 짜준 코드에 입력 검증이 빠지거나 API 키가 그대로 박혀 있어도 동작만 하면 그냥 넘어가게 된다.
첫 화면이 느려도 '일단 되니까'로 넘기다가, 정작 보여주는 자리에서 로딩만 하염없이 보게 된다.

04개념 설명

디자인 토큰 — 값이 아니라 이름으로 관리한다

색상 하나를 코드 곳곳에 #3B82F6 같은 값으로 직접 박아두면, 나중에 메인 컬러 하나만 바꾸려 해도 화면 수만큼 찾아 고쳐야 한다. 디자인 토큰은 'primary', 'spacing-md'처럼 이름을 먼저 정하고, 실제 값은 한 곳(변수 파일)에서만 관리하는 방식이다.

이 과정의 문서·슬라이드가 색·타이포·간격을 tokens.css 하나로만 관리하는 것과 같은 원리다. 토큰화가 끝나면 브랜드 컬러가 바뀌거나 다크모드를 추가할 때도 파일 하나만 고치면 전체 화면에 반영된다.

값을 직접 박아두면

#3B82F6을 코드 곳곳에

바꾸려면 화면 수만큼 찾아 고쳐야 한다

토큰으로 관리하면

'primary'라는 이름으로 참조

파일 하나만 고치면 전체에 반영된다

색 팔레트는 3~5개로 제한하고 역할(주요·보조·경고·배경)을 이름으로 붙인다
제목·본문·캡션의 글자 크기를 몇 단계로 고정한다(타이포 스케일)
여백과 간격은 4px 또는 8px의 배수로 통일한다

컴포넌트 일관성 — 같은 역할은 어디서나 같은 모습이어야 한다

버튼, 입력창, 카드처럼 반복해서 쓰이는 요소가 화면마다 조금씩 다르면 사용자는 무의식적으로 '이거 같은 서비스가 맞나'라는 인상을 받는다. AI에게 화면을 하나씩 따로 요청하면 이런 미세한 불일치가 특히 쌓이기 쉽다.

해결책은 복잡하지 않다. '주요 버튼', '보조 버튼', '위험 동작 버튼'처럼 역할별로 이름을 붙여 정의해두고, 새 화면을 요청할 때마다 새로 만들지 말고 기존 정의를 참조하라고 AI에게 명시하면 된다.

화면마다 따로 요청하면

버튼 모양이 조금씩 달라진다

같은 서비스가 맞나 싶은 인상을 준다

역할별로 정의해두면

"기존 버튼 스타일을 따라줘"

새 화면에서도 일관된 모습을 유지한다

버튼은 역할(주요/보조/위험)별로 스타일을 통일한다
같은 역할의 요소는 새로 만들지 않고 기존 컴포넌트를 재사용한다
새 화면을 요청할 때 '기존 버튼/입력창 스타일을 따라줘'라고 명시한다

접근성 기본 — 이 차이가 사용 가능과 불가능을 가른다

접근성은 특별한 소수만을 위한 배려가 아니다. 햇빛 아래에서 화면을 보는 사람, 마우스 없이 키보드만 쓰는 사람, 화면을 보지 않고 음성으로 듣는 사람 모두가 접근성의 영향을 받는다. 글자와 배경의 명도 대비가 낮으면 누구에게나 읽기 힘들고, 키보드로 이동이 안 되면 그 기능은 일부 사용자에게 아예 존재하지 않는 것과 같다.

모든 접근성 기준을 이번 차시에서 다 충족할 필요는 없다. 가장 흔히 놓치는 세 가지 — 명도 대비, 키보드 탐색, 대체 텍스트 — 부터 우선 점검한다.

점검 항목	확인할 것
명도 대비	글자와 배경이 뚜렷이 구분되는가
키보드 탐색	Tab만으로 모든 기능에 닿는가
대체 텍스트	의미 있는 이미지에 alt가 있는가

본문 텍스트와 배경의 명도 대비를 확인한다
마우스 없이 Tab 키만으로 모든 기능에 도달할 수 있는지 확인한다
의미를 전달하는 이미지에는 대체 텍스트(alt)를 넣는다

AI 생성 코드의 단골 취약점 — 빠르게 만든 코드는 검증이 생략되기 쉽다

AI는 '일단 동작하는 코드'는 잘 만들지만, '공격받았을 때도 버티는 코드'까지 알아서 챙겨주지는 않는다. 특히 네 가지가 반복해서 나타난다 — 입력 검증 누락, 허술한 인증·권한 확인, 코드에 그대로 박힌 시크릿, 오랫동안 업데이트되지 않은 의존성이다.

이 네 가지는 이름만 알아도 절반은 점검할 수 있다. 나머지 절반은 AI에게 '이 관점으로 내 코드를 훑어봐 달라'고 구체적으로 요청하는 것이다 — 막연히 '보안 점검해줘'라고 하면 막연한 답만 돌아온다.

취약점	점검
입력 검증 누락	서버에서도 한 번 더 검증
허술한 인증 · 권한	서버 쪽에서 다시 확인
코드에 박힌 시크릿	환경변수로 분리
오래된 의존성	알려진 취약점 주기적 확인

사용자 입력은 화면(프론트엔드)뿐 아니라 서버에서도 한 번 더 검증한다
로그인 여부와 권한은 서버 쪽에서 다시 확인한다
API 키·비밀번호는 코드가 아니라 환경변수로 분리한다
의존성 목록에 알려진 취약점이 있는지 주기적으로 확인한다

05실습 가이드

1. 디자인 토큰 뽑아내기
- 지금 서비스에서 실제로 쓰이는 색상 코드, 글자 크기, 여백 값을 화면별로 캡처하거나 개발자 도구로 확인해 목록으로 정리한다.
- P9-1 프롬프트로 AI에게 이 목록을 색·타이포·간격 토큰으로 정리해달라고 요청한다.
- 결과를 하나의 변수 파일(CSS 변수 등 프로젝트에서 쓰는 방식)로 저장한다.
예상 결과 — 색·타이포·간격 값이 이름 붙은 토큰으로 정리된 파일 하나가 생긴다.
안 될 때 — 화면마다 값이 너무 제각각이면 한 번에 통일하려 하지 말고, 가장 자주 쓰는 값(주요 버튼 색, 기본 여백)부터 토큰으로 뽑는다.
2. 토큰을 코드에 적용하기
- AI에게 코드에 직접 박혀 있는 색상·간격 값을 1단계에서 만든 토큰으로 하나씩 치환해달라고 요청한다.
- 화면 단위로 나눠 적용하고, 적용할 때마다 화면을 눈으로 확인한다.
- 치환 전후 스크린샷을 나란히 남겨 비교한다.
예상 결과 — 화면의 겉모습은 그대로인데, 코드 안의 값은 토큰 이름으로 바뀌어 있다.
안 될 때 — 치환 후 레이아웃이 깨지면 한 번에 되돌리지 말고, 방금 바꾼 화면 하나만 P9-5(복구 프롬프트)로 원인을 짚어가며 고친다.
3. 컴포넌트 일관성 점검하기
- P9-2 프롬프트로 AI에게 프로젝트 전체에서 버튼·입력창·카드가 몇 가지 스타일로 흩어져 있는지 스캔해달라고 요청한다.
- 역할이 같은데 스타일이 다른 곳을 목록으로 받는다.
- 가장 널리 쓰이는 스타일을 기준으로 통일하고, 나머지를 그 컴포넌트로 교체한다.
예상 결과 — 버튼·입력창 등 반복 요소가 역할별로 하나의 스타일로 정리된 목록이 나온다.
안 될 때 — 스캔 결과가 너무 많아 감당이 안 되면 사용자가 가장 자주 보는 화면 3개부터 우선 정리한다.
4. 접근성 기본 점검 — 대비와 키보드
- P9-3 프롬프트로 AI에게 주요 화면의 텍스트-배경 명도 대비를 점검해달라고 요청한다.
- 마우스를 치우고 Tab 키만으로 로그인, 글쓰기 등 핵심 동작을 끝까지 수행해본다.
- 이동이 안 되거나 순서가 이상한 지점을 메모한다.
예상 결과 — 대비가 낮은 지점과 키보드로 도달 안 되는 지점이 목록으로 정리된다.
안 될 때 — Tab으로 이동은 되는데 지금 어디에 있는지 안 보이면, 포커스 표시(테두리 등)가 빠진 것이다. 이 부분도 AI에게 함께 고쳐달라고 요청한다.
5. 접근성 — 대체 텍스트 점검
- 화면에 있는 이미지·아이콘을 훑어보며 정보를 담고 있는지, 장식용인지 구분한다.
- 정보를 담은 이미지에 대체 텍스트가 있는지 확인하고, 없으면 AI에게 문맥에 맞는 문구를 요청한다.
예상 결과 — 정보를 전달하는 이미지에는 모두 대체 텍스트가 붙는다.
안 될 때 — 이미지가 너무 많아 하나씩 확인하기 어렵다면, 코드에서 alt 속성이 비어있거나 없는 이미지를 AI에게 먼저 찾아달라고 한다.
6. AI 생성 코드 보안 점검 — 입력 검증과 인증
- P9-4 프롬프트로 AI에게 입력 검증 누락과 인증·권한 확인 허점을 기준으로 코드를 훑어달라고 요청한다.
- 특히 로그인·결제·글쓰기처럼 사용자 입력이 들어가는 지점을 우선 확인한다.
- 발견된 항목을 심각도(높음/중간/낮음)로 나눠 리스트를 만든다.
예상 결과 — 입력 검증·인증 관련 취약점 후보 목록이 심각도와 함께 정리된다.
안 될 때 — AI가 '문제없다'고만 답하면 로그인·결제처럼 구체적인 화면 이름을 짚어 다시 물어본다. 막연한 질문에는 막연한 답만 온다.
7. 시크릿과 의존성 점검
- 코드 전체에서 API 키, 비밀번호, 토큰이 문자열로 그대로 박혀 있는 곳이 있는지 AI에게 찾아달라고 요청한다.
- 찾은 값은 환경변수로 옮기고, 이미 커밋된 이력이 있다면 별도로 표시해둔다(10차시에서 다룬다).
- 사용 중인 라이브러리(의존성) 목록에 알려진 취약점이 있는지 확인한다.
예상 결과 — 코드에 하드코딩된 시크릿이 없고, 의존성 취약점 여부가 확인된 상태가 된다.
안 될 때 — 이미 커밋 이력에 시크릿이 남아 있다면 지금 지워도 이력에는 남는다. 해당 키를 즉시 재발급(폐기)하는 것이 더 확실한 대처다.
8. 성능 점검하고 우선순위 정하기
- P9-6 프롬프트로 AI에게 첫 화면 로딩, 이미지 용량, 불필요한 재요청 등 성능 관점에서 점검해달라고 요청한다.
- 발견된 항목을 '지금 고칠 것'과 '나중에 고칠 것'으로 나눈다.
- 지금까지의 디자인 토큰·컴포넌트 정리·접근성·보안·성능 점검 결과를 하나의 문서(디자인 시스템 + 보안 점검 리포트)로 모은다.
예상 결과 — 성능 점검 결과가 우선순위와 함께 정리되고, 오늘 산출물인 디자인 시스템 문서와 보안 점검 리포트가 완성된다.
안 될 때 — 무엇부터 고칠지 판단이 안 서면, 사용자가 가장 자주 보는 화면과 가장 많이 이탈하는 지점부터 우선순위를 매긴다.

06실전 프롬프트

P9-1디자인 토큰 정리 요청

사용 시점 — 실습 1단계 — 화면에서 반복되는 색·글자 크기·간격 값을 토큰으로 뽑을 때

지금 이 프로젝트 화면들에서 쓰고 있는 색상 코드, 글자 크기, 여백 값을 정리했어.

[색상 값 목록 붙여넣기]
[글자 크기 목록 붙여넣기]
[여백/간격 값 목록 붙여넣기]

이 값들을 비슷한 것끼리 묶어서
'primary', 'spacing-md' 같은 이름을 붙인 디자인 토큰으로 정리해줘.

그리고 [CSS 변수] 형태로 한 파일에 정리해서,
앞으로는 값 대신 이 이름을 가져다 쓰도록 만들어줘.

기대 결과 — 값들이 의미 있는 이름으로 그룹핑된 토큰 파일 초안을 받는다.

P9-2컴포넌트 일관성 스캔 요청

사용 시점 — 실습 3단계 — 버튼·입력창 등 반복 요소의 스타일 차이를 점검할 때

내 프로젝트 전체 코드를 훑어보고
버튼, 입력창, 카드처럼 반복해서 쓰이는 요소들이
지금 몇 가지 스타일로 흩어져 있는지 찾아줘.

같은 역할(예: 제출 버튼)인데 스타일이 다른 곳이 있으면
어느 파일, 어느 화면인지 짚어서 목록으로 알려줘.

그리고 가장 많이 쓰이고 있는 스타일을 기준으로 통일한다면
어떻게 바꾸면 될지 제안해줘.

기대 결과 — 역할별 스타일 불일치 목록과 통일 방안을 받는다.

P9-3접근성 기본 점검 요청

사용 시점 — 실습 4~5단계 — 명도 대비, 키보드 탐색, 대체 텍스트를 점검할 때

내 서비스의 주요 화면([로그인, 목록, 상세 화면 이름])을
접근성 관점에서 점검해줘.

1. 텍스트와 배경의 명도 대비가 부족한 곳이 있는지
2. 이미지 중에 대체 텍스트(alt)가 없는데 정보를 담고 있는 것이 있는지
3. 키보드(Tab 키)만으로 이동했을 때 순서가 이상하거나 막히는 곳이 있는지

찾은 문제를 화면별로 정리하고,
심각한 것부터 순서대로 고치는 방법도 알려줘.

기대 결과 — 화면별 접근성 문제 목록과 우선순위별 수정 방법을 받는다.

P9-4AI 생성 코드 보안 취약점 점검 요청

사용 시점 — 실습 6~7단계 — 입력 검증·인증·시크릿·의존성 관점에서 코드를 점검할 때

내 프로젝트 코드를 아래 네 가지 관점으로만 점검해줘.

1. 사용자 입력을 서버에서 검증하지 않고 그대로 쓰는 곳이 있는지
2. 로그인 여부나 권한 확인 없이 실행되는 기능이 있는지
3. API 키나 비밀번호가 코드에 문자열로 그대로 박혀 있는지
4. 오래 업데이트되지 않은 라이브러리가 있는지

각 항목마다 발견한 위치와 심각도(높음/중간/낮음)를 표로 정리해주고,
심각도 높은 것부터 고치는 방법을 알려줘.

기대 결과 — 네 가지 취약점 관점별로 위치와 심각도가 정리된 점검 리포트를 받는다.

P9-5토큰 적용 후 화면이 깨졌을 때 복구용

사용 시점 — 실습 2단계 — 값을 토큰으로 치환한 뒤 레이아웃이나 색이 의도와 다르게 바뀌었을 때

방금 색·간격 값을 토큰으로 바꿨더니
[어느 화면, 어느 요소]가 이렇게 이상해졌어.

[스크린샷 설명 또는 달라진 부분]

바꾸기 전 값: [원래 값]
바꾼 후 값: [토큰 이름 또는 값]

어느 부분이 잘못 매칭됐는지 먼저 설명하고,
바로 되돌릴 수 있는 방법도 같이 알려줘.

기대 결과 — 잘못 매칭된 지점 설명과 되돌리는 방법을 받는다.

P9-6성능 점검 요청

사용 시점 — 실습 8단계 — 로딩 속도와 리소스 사용을 점검할 때

내 서비스의 첫 화면([페이지 이름])이 뜨는 데 걸리는 시간과
불필요하게 큰 이미지나 반복 요청이 있는지 점검해줘.

발견한 문제를
1) 지금 바로 고칠 수 있는 것
2) 나중에 여유 있을 때 고쳐도 되는 것
으로 나눠서 알려주고, 각각 왜 그렇게 나눴는지도 설명해줘.

기대 결과 — 성능 문제 목록이 우선순위(지금/나중)와 이유가 함께 정리되어 나온다.

07이것만은 주의

토큰으로 한 번에 다 바꾸다 화면이 통째로 깨진다

무슨 일이 생기나 — 값을 토큰으로 치환하는 작업을 전체 화면에 한 번에 적용하면, 어느 부분이 잘못 매칭됐는지 찾기 어려워지고 전체 화면이 동시에 무너질 수 있다.

대처 — 화면 단위로 나눠서 적용하고, 적용할 때마다 눈으로 확인한다. 문제가 생기면 P9-5로 방금 바꾼 부분만 짚어 되돌린다.

보안 점검 리포트를 받고도 실제로는 안 고친다

무슨 일이 생기나 — AI가 취약점 목록을 정리해줘도, 목록만 문서로 남기고 실제 코드 수정으로 이어지지 않으면 아무것도 바뀌지 않는다.

대처 — 심각도 '높음'으로 표시된 항목만이라도 이번 차시 안에 실제로 고치고, 고친 뒤 다시 점검을 요청해 확인한다.

접근성 자동 점검 결과를 전부라고 믿는다

무슨 일이 생기나 — AI나 도구가 짚어주는 대비·구조 문제를 다 고쳤다고 해서 실제 사용성이 보장되는 건 아니다. 자동 점검이 놓치는 문제(의미 없는 탐색 순서, 헷갈리는 문구)도 있다.

대처 — 자동 점검 결과를 고친 뒤, 실제로 마우스 없이 키보드만으로 핵심 기능을 끝까지 한 번 수행해본다.

시크릿을 코드에서 지워도 유출이 끝났다고 생각한다

무슨 일이 생기나 — 커밋 이력에 한 번이라도 올라간 API 키나 비밀번호는, 지금 코드에서 지워도 저장소 이력을 뒤지면 여전히 찾을 수 있다.

대처 — 코드에서 지우는 것과 별개로, 해당 키·비밀번호는 발급처에서 즉시 재발급(폐기)한다.

의존성을 한꺼번에 최신 버전으로 올린다

무슨 일이 생기나 — 오래된 라이브러리를 한 번에 전부 최신 버전으로 업데이트하면, 미처 발견 못한 호환성 문제로 멀쩡하던 기능이 갑자기 망가질 수 있다.

대처 — 취약점이 있는 것부터 하나씩 올리고, 올릴 때마다 핵심 기능이 그대로 동작하는지 확인한다.

08자가 점검

0 / 6 완료0%

색·타이포·간격이 토큰으로 정리되어 한 파일에서 관리된다
역할이 같은 버튼·입력창이 화면마다 같은 스타일로 통일됐다
주요 화면에서 키보드만으로 핵심 기능을 끝까지 수행할 수 있다
입력 검증·인증·시크릿·의존성 네 가지 관점의 점검 리포트를 만들었다
심각도 높은 취약점을 실제로 고쳤다
성능 점검 결과를 우선순위별로 정리했다

09과제

자신이 배포한 서비스(또는 기본과정에서 만든 프로젝트)를 대상으로, 이번 차시의 다섯 가지 점검(디자인 토큰, 컴포넌트 일관성, 접근성, 보안 취약점, 성능)을 실제로 수행한다. 발견한 문제 중 최소 3개는 이번 차시 안에 직접 고친다.

제출 형식 — ① 디자인 토큰 파일 또는 정리 문서 ② 컴포넌트 일관성 점검 전후 스크린샷 ③ 접근성·보안·성능 점검 리포트 ④ 실제로 고친 항목 3개와 수정 전후 비교를 하나의 문서로 정리해 제출한다.

10더 알아보기

웹 접근성 지침(WCAG) 요약 자료 — 명도 대비·키보드 탐색 기준의 최신 권고 확인용
OWASP 취약점 목록 — 입력 검증·인증 등 흔한 취약점 유형을 더 폭넓게 확인할 때

디자인 토큰: — 색·타이포·간격 같은 디자인 값에 이름을 붙여 한 곳에서 관리하는 방식.
명도 대비: — 텍스트와 배경 밝기의 차이. 낮으면 읽기 어렵다.
의존성: — 프로젝트가 가져다 쓰는 외부 라이브러리. 오래 방치되면 알려진 취약점이 남아있을 수 있다.

다음 차시 예고 — 다음 차시에서는 지금 만든 것을 나 혼자만 아는 상태에서 벗어나, 팀이 이어받아 운영할 수 있는 형태로 만드는 법을 다룹니다 — 배포 자동화, 롤백, 온보딩 문서까지 이 과정의 마지막 산출물을 완성합니다.