레드라인

Redline

산출물

시안 위에 간격과 크기와 색 값을 숫자로 적어 개발이 그대로 옮길 수 있게 만든 문서입니다.

등장 배경

시안은 그림이고 코드는 숫자입니다. 그림만 넘기면 받는 쪽은 화면을 눈으로 재서 짐작하게 됩니다. 버튼 위 여백이 24였는데 20으로 만들어도 그 자리에서는 아무도 알아채지 못하고, 한 화면 안에서 여백이 16과 18과 20과 24로 섞입니다. 따로 보면 괜찮아 보이지만 화면 열 장을 이어 보면 정돈되지 않은 제품이 됩니다.

이 어긋남은 검수 자리에서 같은 대화로 되풀이됩니다. 디자이너가 여백이 다르다고 말하면 개발자가 몇이어야 하는지 묻고, 답이 시안대로라는 말로 돌아옵니다. 시안에 숫자가 없으면 이 대화는 끝나지 않습니다. 양쪽이 같은 화면을 보면서 서로 다른 기준으로 이야기하고 있기 때문입니다.

그래서 시안 위에 선을 긋고 그 옆에 숫자를 적어 넘기기 시작했습니다. 그 표시를 빨간 선으로 그렸던 관행에서 이름이 왔습니다. 값을 적는 일 자체는 넘기는 쪽의 수고를 늘리지만, 받는 쪽이 짐작하는 구간을 없앱니다.

구성 항목

적는 값은 다섯 묶음입니다.

  1. 간격. 요소 사이의 거리와 바깥 여백입니다. 버튼 위 24, 카드 사이 16처럼 적습니다. 그림을 눈으로 재서는 20인지 24인지 가릴 수 없어서 가장 먼저 적히는 값입니다.
  2. 크기. 너비와 높이와 모서리 둥글기입니다. 숫자만 적지 않고 고정값인지 내용에 따라 늘어나는지를 함께 적습니다. 너비 320이라고만 적으면 글자가 두 줄로 늘어났을 때 어떻게 되는지가 빠집니다.
  3. 색과 글자. 색은 값과 이름을 함께 적습니다. 색 코드만 적어 두면 반년 뒤에 그 색을 바꿀 때 어디를 고쳐야 하는지 찾을 수 없습니다. 색과 간격 같은 값에 이름을 붙여 코드와 공유하는 단위가 디자인 토큰이고, 토큰이 있으면 값 대신 이름을 적습니다. 글자는 크기와 굵기와 행간 셋을 적습니다.
  4. 상태. 평소 모습, 마우스를 얹었을 때, 누르고 있을 때, 눌러도 안 되는 상태, 결과를 기다리는 상태입니다. 한 상태만 그려 넘기면 나머지 넷을 개발자가 정하게 되고, 그 판단은 화면마다 달라집니다.
  5. 좁아질 때의 규칙. 화면 너비가 줄면 무엇이 먼저 줄고 무엇이 두 줄로 내려가는지 적습니다. 배치를 바꾸는 기준점인 브레이크포인트를 함께 적어 두면 어느 너비에서 바뀌는지가 정해집니다.

요즘은 피그마 같은 도구가 시안에서 값을 자동으로 읽어 줍니다. 손으로 선을 긋고 숫자를 적는 일은 거의 사라졌습니다. 다만 도구가 대신해 주는 것은 1번과 2번, 3번의 값 부분까지입니다. 도구는 지금 그려진 한 상태를 읽을 뿐이라, 그려지지 않은 상태와 좁아질 때의 규칙은 여전히 사람이 적어야 합니다. 값을 옮겨 적는 수고가 줄어든 만큼 4번과 5번에 시간을 쓰는 쪽이 지금의 작업입니다.

작성자와 독자

적는 사람은 시안을 만든 디자이너입니다. 실제 색과 서체까지 올린 목업을 끝낸 사람이 이어서 값을 채웁니다. 그린 사람이 아니면 어느 여백이 의도이고 어느 여백이 손이 미끄러진 결과인지 가릴 수 없기 때문입니다.

읽는 사람은 셋입니다.

첫째는 화면을 만드는 개발자입니다. 구현하는 동안 옆에 띄워 두고 값을 옮깁니다. 이 독자에게 필요한 것은 설명이 아니라 찾기 쉬운 숫자라, 값이 화면 위 제자리에 붙어 있는 편이 낫습니다.

둘째는 나온 화면이 시안과 맞는지 보는 사람입니다. 구현 결과를 시안과 나란히 놓고 어긋난 곳을 찾는 디자인 QA에서 레드라인이 판정 기준이 됩니다. 값이 적혀 있지 않으면 이 검수는 느낌을 주고받는 자리가 되고 어느 쪽이 맞는지 정할 근거가 없습니다.

셋째는 반년 뒤의 다른 디자이너입니다. 같은 화면을 열었을 때 왜 24였는지가 남아 있으면 그 값을 그냥 바꾸지 않습니다.

넘기는 자리는 디자인을 개발에 넘기는 과정 전체인 핸드오프입니다. 레드라인은 그 자리에 들고 가는 물건 가운데 하나이고, 무엇이 확정이고 무엇이 아직 아닌지를 말로 전하는 일은 그 자리의 다른 몫입니다.

어디까지 적을지의 선도 미리 그어 둡니다. 재사용 부품과 규칙을 한 기준으로 묶어 둔 것이 있으면 부품 단위 값은 다시 적지 않고 그쪽을 가리킵니다. 같은 버튼 값을 화면마다 적으면 버튼이 한 번 바뀔 때 스무 장이 동시에 어긋납니다.

실무 용례

"이 화면 레드라인 주시면 오늘 붙입니다."

값이 정해져 있으면 구현은 하루 안에 끝난다는 뜻입니다.

"여백 값이 시안마다 달라요. 토큰으로 정리해 주세요."

같은 자리에 쓰이는 값이 흩어져 있으니 이름을 붙여 한 곳에서 관리하자는 요청입니다.

"비활성 상태는 레드라인에 없는데 어떻게 하죠?"

그려지지 않은 상태는 개발자가 정해야 하니 값을 달라는 질문입니다.

페이지덱에서 민서는 문서 공유 화면을 넘기면서 값 대신 토큰 이름으로 적었습니다. 여백 24 자리에 간격 토큰 이름을, 파란색 코드 자리에 주 색상 토큰 이름을 적는 식입니다. 나중에 주 색상을 한 단계 진하게 바꿀 때 시안 스무 장을 다시 손대지 않아도 됩니다.

태오는 넘겨받은 뒤 비활성 상태와 대기 상태가 비어 있다는 것을 먼저 짚었습니다. 그 둘이 없으면 저장 버튼을 두 번 누를 수 있는 화면이 나오기 때문입니다. 민서가 두 상태를 추가한 뒤 구현이 시작됐습니다.

흔한 오해

도구가 값을 읽어 주니 레드라인은 없어진 일이라고 보는 경우가 가장 많습니다. 시안을 눌러 보면 간격과 색이 바로 나오니 그렇게 보입니다. 그러나 도구가 읽는 것은 지금 그려져 있는 한 상태뿐입니다. 눌러도 안 되는 버튼, 목록이 비었을 때의 화면, 글자가 아주 길 때의 처리는 그려지지 않았으면 도구에도 없습니다. 이 구별을 놓치면 넘기는 쪽은 다 넘겼다고 여기고 받는 쪽은 절반을 스스로 정하며, 그 차이가 검수에서 한꺼번에 드러납니다.

모든 값을 빠짐없이 적는 것이 친절하다고 보는 오해도 흔합니다. 받는 쪽이 찾을 일이 줄어드니 좋아 보입니다. 그런데 부품 단위로 이미 정해 둔 값을 화면마다 다시 적으면 같은 값이 두 곳에 살게 됩니다. 버튼 높이를 40에서 44로 바꾼 날, 기준에는 44가 적혀 있고 시안 스무 장에는 40이 남아 있는 상태가 됩니다. 적을 것은 기준 밖의 값과 이 화면에서만 다른 값입니다.

같이 보면 좋은 페이지

  • 디자인 산출물

    레드라인이 네 단계 가운데 전달 단계의 첫 물건인 이유를 봅니다

  • 핸드오프

    이 문서를 들고 가는 자리에서 무엇을 더 전해야 하는지 봅니다

마지막 업데이트 2026-09-26