디자인은 통과, 개발에서 무너진 토큰 — 도면과 결과물 사이에서 새는 것들

들어가며 — "디자인은 분명 맞게 했는데요"

이번 주 월요일에 Figma 분석, 그러니까 "만들기 전에 도면 단계에서 기준을 보는" 이야기를 드렸습니다. 핵심은 하나였습니다. "고치는 비용은 단계가 뒤로 갈수록 폭발한다, 그러니 제일 싼 도면 단계에서 잡는 게 이득이다." 오늘은 그 도면 단계를 조금 더 입체적으로, 두 개의 사례로 풀어보려 합니다. 방향이 정반대인 두 이야기를 나란히 놓을 텐데, 그렇게 놓아야만 보이는 결론이 있어서입니다.

하나는 "도면 단계에서 안 잡아서 비싸진" 경우입니다. 디자인에서 미리 봤으면 아주 싸게 끝났을 일을, 안 봐서 개발과 배포가 다 끝난 뒤에 비싸게 고친 이야기입니다.

다른 하나는 "도면은 잘 잡았는데 개발에서 무너진" 경우입니다. 디자인 검수는 통과했는데, 코드로 옮겨지는 과정에서 그 잘 잡은 기준이 다시 어긋난 이야기입니다.

이 둘을 굳이 같이 보는 데는 이유가 있습니다. 월요일에 "설계 시점은 싸게 미리 거른다, 운영 시점은 진짜를 확인한다, 둘은 경쟁이 아니라 분업"이라고 말씀드렸는데, 오늘 두 사례가 정확히 그 분업의 두 얼굴을 보여줍니다. 도면을 안 보면 첫 번째 사고가 나고, 도면만 보고 운영을 안 보면 두 번째 사고가 납니다. 그래서 둘 다 필요하다는 게 오늘의 결론입니다. 한쪽 사례만 보면 "그럼 도면을 봐야겠네" 또는 "그럼 운영을 봐야겠네"로 한쪽으로 기울기 쉬운데, 둘을 같이 봐야 "양쪽 다, 시간 순서로"라는 균형 잡힌 답이 나옵니다.

오늘 이야기도 다 익명입니다. 특정 사업이나 특정 기관을 지적하려는 게 아니라, 디자인과 개발 사이에서 어디서나 반복되는 전형적인 패턴을 하나로 묶어서 봅니다. 그러니 "우리 얘기 아닌가" 싶더라도, 그건 이 패턴이 그만큼 흔하다는 뜻이지 특정 현장을 겨눈 게 아닙니다. "디자인은 분명 맞게 했는데요"라는, 그 흔한 항변에서 출발해보겠습니다.

미리 한 가지 짚어두겠습니다. 이 항변은 대부분 진심입니다. 디자이너는 정말로 자기가 맞게 만들었다고 믿습니다. 거짓말이 아닙니다. 다만 "디자인이 맞다"와 "사이트가 맞다" 사이에는 개발이라는 큰 강이 하나 놓여 있고, 그 강을 건너는 동안 값이 조금씩 샙니다. 그래서 오늘 글은 "누가 잘못했나"를 따지는 자리가 아닙니다. "어디서 새는지, 어떻게 막는지"를 보는 자리입니다. 비난이 아니라 구조의 문제이니까요. 성실한 디자이너와 성실한 개발자가 각자 제 몫을 다했는데도, 그 사이에서 구조적으로 새는 지점이 있다는 이야기입니다.

본론 1 — 도면에서 안 잡아서 비싸진 경우

예쁘게는 만들었는데

어떤 사업에서 디자인을 정말 공들여 만들었습니다. 보기 좋았고, 관계자들 모두 만족했습니다. 그런데 "이게 KRDS 기준에 맞나"는 그 단계에서 따로 보지 않았습니다. "일단 예쁘게 만들고, 기준은 개발이 끝난 다음 검수에서 보자"는 흐름이었습니다. 아주 흔한 순서입니다. 예쁜 화면을 앞에 두고 있으면, 기준 이야기는 왠지 김을 빼는 것처럼 느껴지기도 합니다. 그래서 자연스럽게 뒤로 밀립니다.

문제는 그 예쁜 디자인이 표준을 군데군데 벗어나 있었다는 점입니다. 브랜드 색이 아니라 디자이너가 눈대중으로 찍은 비슷한 색을 썼고, 글자 크기도 표준 단계가 아니라 어중간한 값이었고, 일부 버튼은 손가락으로 누르기엔 작았습니다. 월요일에 본 그 단골 유형들입니다. 하나하나는 사소해서, 예쁜 화면 속에 파묻혀 눈에 잘 띄지 않았습니다. 여기서 잠깐 용어를 정리하겠습니다. 방금 말한 색·글자 크기·간격 같은 것들을 KRDS에서는 "디자인 토큰"이라고 부릅니다. 화면을 이루는 재료를 미리 표준값으로 정해둔 변수라고 생각하시면 됩니다. "이 파랑은 이 값", "본문 글자는 이 크기", "요소 사이 간격은 이 단위" 같은 식으로요. 이 토큰들을 표준값에 맞춰 쓰면 화면 전체가 일관되고, 벗어나면 조금씩 어긋납니다. 오늘 이야기의 주인공이 바로 이 토큰입니다.

사람 눈에는 이런 게 잘 안 보입니다. 표준 파랑과 그 옆의 살짝 다른 파랑을 나란히 놓아도, 대부분은 구별하지 못합니다. 글자 크기가 한 단계 어긋난 것도, 화면만 봐서는 "그냥 그런가 보다" 하고 지나갑니다. 그래서 예쁜 화면은 "예쁘다"는 인상만 남기고, 그 안에 섞인 미세한 표준 이탈은 조용히 통과합니다. 기준은 눈이 아니라 값으로 정해져 있는데, 검토는 눈으로 하니 어긋난 값이 걸러지지 않는 것입니다.

Figma 디자인 파일에서 화면에 쓰인 색·타이포·간격 토큰을 뽑아, KRDS 표준값과 나란히 대조해 적합/부적합 근거를 보여주는 설계 시점 점검 화면. 사람 눈엔 "비슷한 파랑"이지만, 여기서는 "이 값은 표준 색이 아니다"가 값 단위로 갈린다. 도면 단계에서 이런 표준 밖 값을 미리 걸렀으면 아래 사례의 고생이 통째로 없었을 자리 (게재 시 기관명·도메인 블러)

개발이 끝나고 나서야

이 표준 이탈이 개발까지 다 끝나고, 검수 단계에서야 드러났습니다. 그제서야 "어, 이 색 표준 아니네", "이 글자 크기 규격 밖이네"가 우수수 나왔습니다. 그런데 이미 그 디자인대로 코드가 다 짜인 상태였습니다. 색 하나를 바꾸려면 디자인을 고치고, 개발자가 코드에서 그 색을 쓰는 자리를 전부 찾아 바꾸고, 다시 화면마다 테스트를 해야 했습니다. 도면 단계에서 색 팔레트만 표준으로 정리했으면 끝났을 일이, 다 지어진 결과물을 뒤지는 일이 되어버린 것입니다.

월요일에 말씀드린 "단계마다 비용이 뛴다"가 그대로 재현됩니다. 디자인 단계에서 봤으면 지우개로 슥슥 할 일이, 개발이 끝난 뒤에는 벽을 부수고 다시 쌓는 일이 됩니다. 그리고 더 아픈 대목이 있습니다. 일정이 빡빡하면 이걸 다 못 고치고 "일단 오픈하고 나중에 정리"로 넘어간다는 점입니다. 그러면 표준 밖 디자인이 그대로 사용자에게 나갑니다. 고쳐야 한다는 걸 알면서도, 시간이 없어서 못 고친 채로요.

조금 더 구체적으로 말씀드리겠습니다. 문제의 중심은 그 "비슷한 색"이었습니다. 표준 파랑이 아니라 디자이너가 찍은 파랑이 버튼이며 링크며 곳곳에 쓰였는데, 개발자는 디자인에 있는 그대로 그 색을 코드에 박아 넣었습니다. 개발자 입장에선 당연한 일입니다. 디자인이 그 색이라니 그 색을 쓴 것이니까요. 나중에 "표준 색으로 통일하라"는 지적이 오자, 코드 전체에서 그 색 값을 찾아 바꿔야 했습니다. 수십 군데였습니다. 게다가 한 군데를 놓치면 거기만 다른 색으로 남아, 오히려 더 이상해집니다. 도면 단계에서 색 팔레트만 표준으로 정리해 넘겼다면, 개발자는 처음부터 표준 색을 박았을 것이고, 이 뒤늦은 대공사가 통째로 없었을 겁니다.

결국 이 팀은 급한 몇 개만 고치고 나머지는 "다음 유지보수 때"로 미뤘습니다. 그런데 지난주에도 짚었듯, 그 "다음"은 좀처럼 오지 않습니다. 표준 밖 디자인이 그대로 운영에 남았고, 시간이 지나 또 다른 담당자가 그걸 "원래 있던 스타일"인 줄 알고 따라 쓰면서 오히려 퍼졌습니다. 안 잡은 작은 위반 하나가, 손대기 더 어려운 상태로 굳어버린 것입니다. 처음에는 색 한두 개의 문제였는데, 나중에는 "어디가 표준이고 어디가 이탈인지"조차 헷갈리는 상태가 됩니다.

왜 도면 단계에서 안 봤을까

이유는 단순합니다. 도면 단계에서는 "아직 진짜가 아니니까" 기준 검토가 급해 보이지 않습니다. 예쁜 화면에 다들 만족하면 "기준은 나중에"가 자연스럽습니다. 그런데 월요일에 본 것처럼, 비용 곡선과 관심 곡선은 정확히 반대로 움직입니다. 제일 싸게 잡을 수 있는 그 순간에, 관심은 제일 적습니다. 그래서 의식적으로 "지금, 도면에서 기준을 보자"고 정해두지 않으면, 검토는 자동으로 제일 비싼 타이밍까지 밀려갑니다. 누가 게을러서가 아니라, 관심의 자연스러운 흐름이 그렇게 되어 있어서입니다.

여기에는 심리적인 함정도 하나 있습니다. 도면이 예쁘게 잘 나오면, 사람은 그걸 보고 "완성도가 높다"고 느낍니다. 그런데 "예쁘다"와 "표준에 맞다"는 전혀 다른 이야기입니다. 예쁜 화면일수록 오히려 미세한 표준 이탈이 잘 안 보입니다. 전체 인상이 좋으니 세부의 어긋남이 묻히는 것이죠. 그래서 "잘 나온 도면"일수록 방심하기 쉽고, 방심한 채로 개발에 넘어갑니다.

이게 첫 번째 교훈입니다. 도면 단계에서 기준을 안 보면, 그 비용은 사라지는 게 아니라 뒤로 미뤄지고, 미뤄지는 동안 불어납니다. 지금 안 낸 검토 비용은 나중에 몇 배로 청구됩니다. 그 청구서는 대개 오픈 직전, 가장 바쁘고 가장 여유 없는 시점에 날아옵니다.

본론 2 — 도면은 잘 잡았는데 개발에서 무너진 경우

이번엔 디자인을 제대로 봤다

두 번째 사례는 더 잘한 경우입니다. 어떤 팀은 디자인 단계에서 KRDS 기준을 꼼꼼히 챙겼습니다. 표준 색만 쓰고, 글자 크기도 표준 단계에 맞추고, 컴포넌트도 표준대로 그렸습니다. 디자인 검수 자리에서 "기준 다 맞췄네, 통과" 도장을 받았습니다. 월요일 기준으로 보면, 설계 시점을 제대로 해낸 겁니다. 잘한 일입니다. 첫 번째 팀이 놓친 걸 이 팀은 제대로 챙긴 셈이니까요.

그런데 개발이 끝나고 실제 사이트를 열어보니, 그 잘 맞춘 기준이 군데군데 무너져 있었습니다. 분명 도면에서는 표준이었는데, 배포된 화면에서는 표준이 아니었습니다. 도면과 결과물이 어긋난 것입니다.

옮기는 과정에서 토큰이 샌다

무엇이 무너졌는지 하나씩 보겠습니다. 디자인에서는 표준 색을 썼는데, 개발자가 코드에 그 색을 직접 숫자로 박아 넣으면서 살짝 다른 값을 넣었습니다. 디자인에서는 간격이 정해진 단위의 배수였는데, 개발에서 미묘하게 어긋났습니다. 디자인 컴포넌트는 표준이었는데, 개발할 때 비슷하게 새로 만들면서 상태 처리 — 눌렸을 때, 마우스를 올렸을 때, 비활성일 때 — 가 빠졌습니다. 하나하나는 작아 보이지만, 이런 게 여러 화면에 쌓이면 "표준을 지킨 사이트"와 "표준을 지킨 척하는 사이트"의 차이가 됩니다.

디자인 파일 안의 표준 파랑 토큰 칩과, 코드에 손으로 옮겨 적으면서 살짝 값이 어긋난 파랑 칩을 좌우로 놓고, 그 사이 좁은 틈으로 경고색 한 방울이 새어 나가는 개념 도식. 핸드오프 과정에서 벌어지는 토큰 불일치를 한눈에 (Gemini 1:1)

왜 이런 일이 생길까요. 디자인과 코드는 결국 다른 언어이기 때문입니다. 디자인의 "표준 파랑"이 코드로 옮겨질 때, 그 연결이 자동으로 되어 있지 않으면 사람이 손으로 값을 옮깁니다. 그 옮기는 과정에서 손이 미끄러져 실수가 나거나, 편의상 "비슷하니까 이 값으로" 하고 대충 넣게 됩니다. 디자인 토큰이 코드의 토큰과 단단히 연결되어 있지 않으면, 옮기는 단계마다 조금씩 샙니다. 물 한 통을 그릇에서 그릇으로 옮길 때마다 몇 방울씩 흘리는 것과 같습니다. 한 번은 티가 안 나지만, 여러 번 옮기면 눈에 띄게 줄어 있습니다.

여기에 시간 압박이 더해집니다. 개발자는 보통 기능이 제대로 굴러가게 만드는 게 1순위입니다. 색이 표준 파랑인지 그 옆 파랑인지는, 화면에 비슷하게만 나오면 당장 급한 일이 아닙니다. 그래서 "일단 비슷한 값으로 해두고 나중에 정리"가 하나둘 쌓입니다. 그리고 그 "나중에"가 또 오지 않습니다. 디자이너는 자기 도면이 맞으니 됐다고 생각하고, 개발자는 화면이 비슷하게 나오니 됐다고 생각합니다. 둘 다 자기 자리에서는 문제가 없다고 느끼는데, 정작 그 둘 사이의 이음매에서 토큰이 샙니다. 이 시리즈 초반에 본 "각자 자기 자리에선 통과를 줬는데, 합쳐놓으니 그 사이가 비어 있더라"가 디자인과 개발 사이에서도 똑같이 일어나는 것입니다.

그리고 이건 디자인 검수로는 잘 잡히지 않습니다. 검수는 대개 도면을 보는 것이지, 구현된 코드 값을 한 줄 한 줄 대조하는 게 아니니까요. 화면을 띄워놓고 "시안이랑 비슷하네" 하면 통과입니다. 그런데 앞서 말씀드렸듯 사람 눈은 표준 파랑과 그 옆 파랑을 구분하지 못합니다. 그래서 "검수 통과"가 "토큰이 정확하다"를 보장하지 못합니다. 눈으로 비슷하면 통과인데, 기준은 눈이 아니라 값으로 정해져 있으니, 이 둘 사이에 늘 틈이 남습니다. 검수가 통과됐다는 건 "눈으로 봐서 시안과 비슷했다"는 뜻이지, "값이 표준과 일치했다"는 뜻이 아닌 것입니다.

디자인 통과 ≠ 사이트 통과

이게 이 시리즈 초반에 본 그 함정입니다. "디자인 검수 통과"는 도면이 맞다는 뜻이지, 결과물이 맞다는 뜻이 아닙니다. 도면이 아무리 완벽해도, 시공에서 어긋나면 건물은 어긋난 겁니다. 설계도에 문이 정확히 그려져 있어도, 인부가 문을 다른 자리에 달면 그 집은 문이 잘못 달린 집입니다. 설계도를 탓할 수도, 인부를 탓할 수도 있지만, 사는 사람에게는 그냥 "문이 이상한 집"일 뿐입니다. 그래서 이 팀은 디자인을 잘 잡고도, 배포된 운영 사이트를 따로 확인하지 않아서 "통과인데 위반"인 상태에 놓였습니다.

이게 두 번째 교훈입니다. 도면을 잘 잡는 건 필요조건이지 충분조건이 아닙니다. 도면이 좋아야 좋은 결과물이 나올 가능성이 열리지만, 도면이 좋다고 결과물이 저절로 좋아지지는 않습니다. 그 사이에 사람의 손을 거치는 변환이 있고, 변환에는 늘 손실이 따르기 때문입니다. 그래서 도면이 실제로 그대로 구현됐는지는, 도면과 별개로 한 번 더 확인해야 합니다.

본론 3 — 두 사례가 같이 말하는 것

두 이야기를 나란히 놓으면 결론이 분명해집니다. 월요일에 말씀드린 그대로입니다. 설계 시점과 운영 시점은 둘 다 필요하고, 서로의 빈틈을 메웁니다.

첫 번째 팀: 도면을 안 봤습니다 → 설계 시점이 비어서 비싸졌습니다.
두 번째 팀: 도면은 봤는데 운영을 안 봤습니다 → 운영 시점이 비어서 통과인데 위반이 됐습니다.

한쪽만 하면 한쪽에서 샙니다. 도면만 보면 구현 결과를 모르고, 운영만 보면 이미 너무 늦고 비쌉니다. 그래서 가장 좋은 건 둘 다, 시간 순서로 하는 것입니다. 도면에서 싸게 거르고(설계 시점), 배포 후에 진짜를 확인하고(운영 시점). 이 시리즈 초반에 "신규 구축이나 리뉴얼이면 설계와 운영 두 시점을 시간 순서로 보라"고 했던 게 바로 이 이야기입니다. 두 팀의 실패는 방향만 반대일 뿐, 뿌리는 같습니다. "한쪽만 봤다"는 것입니다.

토큰 연결이 핵심 고리

두 번째 사례에서 본 "옮기는 과정에서 토큰이 샌다"는, 사실 디자인과 개발 사이의 핵심 문제입니다. 디자인의 표준 값이 코드로 자동으로 이어지면 샐 일이 적은데, 사람이 손으로 옮기면 샙니다. 그래서 이상적으로는 디자인 토큰과 코드가 하나의 소스로 연결되어 있어야 합니다. 디자인에서 색을 바꾸면 코드의 색도 같이 바뀌는 식으로요. 이렇게 되면 애초에 어긋날 여지가 줄어듭니다. 값을 두 번 적을 일이 없으니, 두 번 적으면서 생기는 실수도 없어집니다.

그런데 현실적으로 그 연결이 완벽하게 갖춰진 경우는 드뭅니다. 규모가 큰 조직에서도 핵심 토큰 일부만 연결해두고, 나머지는 여전히 손으로 옮기는 경우가 많습니다. 그래서 "디자인이 표준에 맞나(Figma 분석)"와 "구현된 게 표준에 맞나(URL 분석)"를 둘 다 보는 것이 안전장치가 됩니다. 둘 사이가 벌어졌다면, 바로 거기가 "옮기다 샌 지점"입니다. 두 시점을 같이 보면 이 틈이 드러납니다. 도면만 봐서는 이 틈이 안 보이고, 운영만 봐서는 "도면에서부터 틀렸는지, 옮기다 틀렸는지"를 구분할 수 없습니다.

분석한 사이트가 KRDS 표준 대비 어느 항목에서 얼마나 어긋났는지를 항목별로 비교해 보여주는 화면. 도면 단계의 토큰 채택률과 구현 단계의 채택률을 같은 잣대로 비교하면 "옮기다 샌 정도"가 드러난다. 디자인은 높은데 구현이 낮으면, 그 차이만큼 옮기는 과정에서 샌 것 (게재 시 기관명·도메인 블러)

이걸 다르게 보면, 두 시점을 비교하는 것 자체가 하나의 진단이 됩니다. 도면은 맞는데 구현이 틀렸으면 → 개발 핸드오프 문제입니다. 도면부터 틀렸으면 → 디자인 단계 문제입니다. 둘 다 맞는데 사용자가 불편하면 → 기준 자체가 그 상황을 미처 못 담은 것입니다. 이렇게 "어느 단계에서 틀어졌나"를 짚으면, 책임 소재를 두고 다투는 대신 "여기를 고치면 된다"는 구체적인 답이 나옵니다. "디자인이 잘못했냐 개발이 잘못했냐"는 감정 싸움으로 흐르기 쉬운데, 두 시점을 같은 잣대로 비교하면 그게 감정이 아니라 데이터의 문제가 됩니다. 이 시리즈 초반에 본 "각자 자기 자리에선 통과를 줬다"는 상황도, 두 시점을 비교하면 "통과들 사이의 어디가 비었는지"가 눈에 보입니다.

참고로 이 "도면 대 구현 비교"는 한 번 하고 끝낼 일이 아닙니다. 운영 사이트는 계속 바뀌니까요(지난주에 다룬 그 이야기입니다). 처음에는 도면과 똑같이 구현됐더라도, 시간이 지나면서 또 벌어집니다. 누군가 콘텐츠를 잘못된 형식으로 올리거나, 급한 수정이 표준을 건너뛰고 들어가면서요. 그래서 이 비교도 주기적으로 하는 게 좋습니다. 도면은 고정되어 있고 구현은 흘러가니, 가끔 다시 맞춰봐야 둘이 벌어지지 않습니다. 도면은 한 번 그리면 그 자리에 있지만, 사이트는 매일 조금씩 움직인다는 점을 기억해야 합니다.

본론 4 — 그럼 두 팀은 어떻게 했어야 했나

두 팀이 각각 무엇을 다르게 했으면 좋았을지 짚어보겠습니다.

첫 번째 팀 — 도면 단계에 기준 검토를 끼워 넣기

이 팀은 디자인 단계에서 기준을 안 봤으니, 거기에 자동 대조를 한 번 끼워 넣었으면 됐습니다. 예쁘게 만드는 것과 기준에 맞추는 것은 별개이니, 디자인이 끝나는 시점에 "표준 색·글자·간격·컴포넌트에 맞나"를 자동으로 확인하는 것입니다. 사람 눈으로는 예쁜 화면 속의 미세한 이탈을 놓치니, 기계 대조가 낫습니다. 이걸 했다면 개발에 넘기기 전에 다 걸러서, 깨끗한 도면을 건넸을 겁니다.

타이밍이 중요합니다. "디자인 완료" 직전, 그러니까 개발에 넘기기 바로 전이 가장 좋습니다. 그때 한 번 자동으로 훑어서 표준 밖 값을 정리하면, 개발자는 깨끗한 도면만 받습니다. 검수 단계를 하나 더 추가하라는 게 아닙니다. 어차피 하는 디자인 마무리 과정에 자동 대조를 한 번 끼우라는 것입니다. 그 한 번이, 개발 후의 몇 배짜리 비용을 막습니다. 지우개로 지울 수 있을 때 지우자는 것이지요.

두 번째 팀 — 배포 후 운영 점검을 추가하기

이 팀은 도면을 잘 잡았으니, 배포 후에 운영 사이트를 한 번 더 봤으면 됐습니다. "디자인 통과"에서 멈추지 말고, 실제로 구현된 사이트를 운영 주소로 확인하는 것입니다(지난 두 주 내내 이야기한 그 운영 시점입니다). 그랬다면 "옮기다 샌" 부분이 드러났을 겁니다. 도면과 운영 결과를 같은 잣대로 비교하면, 어디서 어긋났는지가 보입니다.

사실 이 팀이 빠진 함정이 더 위험합니다. 첫 번째 팀은 "우리가 기준을 안 봤다"는 자각이라도 있지만, 이 팀은 "우리는 제대로 했다"고 굳게 믿고 있었으니까요. 잘했다는 확신이 오히려 운영 점검을 건너뛰게 만들었습니다. 이 시리즈 초반에 말한 "검사 통과의 함정"과 똑같습니다. 통과 도장을 받을수록, 오히려 "그럼 그다음은 누가 봤지?"를 물어야 합니다. 잘한 팀일수록 이 함정에 빠지기 쉬우니, "디자인을 잘했으니 구현도 한 번 확인하자"가 자연스러운 다음 수순이 되어야 합니다. 확신은 좋은 것이지만, 확신이 확인을 밀어내면 곤란합니다.

둘을 합치면

가장 좋은 건 두 팀의 교훈을 합치는 것입니다. 도면 단계에서 Figma 분석으로 싸게 거르고 → 배포 후 URL 분석으로 구현을 확인하고 → 둘 사이가 벌어진 자리를 고칩니다. 이렇게 하면 첫 번째 팀의 "안 봐서 비싸짐"도, 두 번째 팀의 "통과인데 위반"도 둘 다 생기지 않습니다. 두 시점이 서로의 빈틈을 메우니까요. 하나가 앞을 막고, 하나가 뒤를 받칩니다.

왼쪽 도면(설계 시점)과 오른쪽 배포된 사이트(운영 시점)를 하나의 시간 축 위에 놓고, 같은 KRDS 잣대가 양쪽을 각각 재는 개념 도식. 두 잣대의 눈금이 벌어진 구간이 "옮기다 샌 지점"으로 표시되어, 설계와 운영이 경쟁이 아니라 앞뒤를 나눠 맡는 분업임을 한눈에 보여준다 (Gemini 1:1)

이 도식처럼, 설계 시점과 운영 시점은 같은 축의 앞과 뒤일 뿐 서로 다른 잣대가 아닙니다. 같은 KRDS 기준을 만들기 전에 한 번, 만든 뒤에 한 번 대는 것입니다. 그러니 둘의 결과를 나란히 놓으면 눈금이 자연스럽게 비교되고, 벌어진 구간이 곧 고칠 자리로 드러납니다. 두 시점을 따로 사는 게 아니라 한 축에 두는 이유가 여기에 있습니다.

다시 말씀드리지만, 이건 도구를 둘 사야 한다는 이야기가 아닙니다. "설계와 운영, 두 시점을 다 본다"는 원칙이 핵심입니다. 그 원칙만 지키면 됩니다. 직접 두 시점을 챙기든, 도구를 쓰든, 방식은 자유입니다. 오늘 가져가실 건 도구 이름이 아니라, "도면도 보고, 구현도 본다"는 그 태도입니다.

본론 5 — 왜 하필 디자인과 개발 사이에서 잘 새는가

여기서 한 걸음 더 들어가 보겠습니다. 왜 하필 디자인과 개발의 경계에서 이렇게 토큰이 잘 샐까요. 몇 가지 구조적인 이유가 있습니다. 이 이유들을 알면, "그러니까 이 경계를 특히 조심해서 봐야 하는구나"가 납득됩니다.

이유 ① — 두 사람이 서로 다른 것을 본다

디자이너는 화면을 봅니다. 픽셀로 그려진 결과를 눈으로 확인하며 작업합니다. 개발자는 코드를 봅니다. 화면은 그 코드가 만들어낸 결과물일 뿐입니다. 그러니 같은 "표준 파랑"을 두고도, 디자이너는 "이 색으로 보이면 됐다"고 생각하고, 개발자는 "이 숫자를 넣으면 됐다"고 생각합니다. 문제는 "이 색으로 보이는 것"과 "정확히 이 숫자인 것"이 항상 일치하지는 않는다는 점입니다. 눈에는 같아 보여도 값이 다를 수 있고, 값이 조금 달라도 눈에는 같아 보일 수 있습니다. 두 사람이 각자 다른 것을 기준으로 삼으니, 그 사이에 틈이 생깁니다.

이유 ② — 핸드오프는 "번역"이다

디자인을 개발에 넘기는 과정을 흔히 핸드오프라고 부릅니다. 이 핸드오프는 사실 일종의 번역입니다. 디자인이라는 언어로 쓰인 것을 코드라는 언어로 옮기는 작업이니까요. 그리고 모든 번역에는 손실이 있습니다. 아무리 좋은 번역가라도 원문의 뉘앙스를 100% 옮기지는 못합니다. 디자인과 코드 사이도 마찬가지입니다. "이 간격은 대략 이 정도 느낌"이라는 디자인의 뉘앙스가, 코드에서는 정확한 숫자 하나로 확정되어야 합니다. 그 확정 과정에서 원래 의도와 미세하게 어긋나는 일이 생깁니다. 번역이 개입하는 모든 지점이 잠재적인 누수 지점인 셈입니다.

이유 ③ — 급할 때 가장 먼저 희생되는 게 정밀함이다

앞서도 말했듯, 개발자에게는 기능이 굴러가는 게 1순위입니다. 마감이 다가오면 "일단 되게 만드는 것"에 자원이 몰리고, "정확히 표준값인지"는 뒤로 밀립니다. 색이 표준 파랑인지 그 옆 파랑인지는 화면상 차이가 거의 없으니, 급할 때 가장 먼저 타협되는 항목이 됩니다. 그런데 이런 타협이 하나둘 쌓이면, 나중에는 "우리 사이트가 표준을 지키는지 아닌지"를 아무도 자신 있게 말하지 못하는 상태가 됩니다. 급해서 미룬 정밀함이, 나중에 큰 부채가 되어 돌아옵니다.

이유 ④ — 아무도 "사이"를 책임지지 않는다

디자이너는 도면을 책임집니다. 개발자는 코드를 책임집니다. 그런데 "도면이 코드로 정확히 옮겨졌는가", 그 사이는 누가 책임질까요. 명확한 주인이 없는 경우가 많습니다. 디자이너는 "내 도면은 맞았다"고 하고, 개발자는 "나는 도면대로 했다"고 합니다. 둘 다 틀린 말이 아닌데, 결과물은 어긋나 있습니다. 주인 없는 영역에서 문제가 자라는 것입니다. 그래서 이 "사이"를 명시적으로 보는 장치가 없으면, 그 틈은 계속 방치됩니다. 두 시점을 같은 잣대로 비교한다는 건, 바로 이 주인 없는 영역에 눈을 하나 두는 일입니다.

이 네 가지가 겹치니, 디자인과 개발의 경계는 구조적으로 새기 좋은 지점이 됩니다. 누구의 실력 문제도 아니고, 누구의 성의 문제도 아닙니다. 일이 나뉘어 있고, 언어가 다르고, 시간이 없고, 사이의 주인이 없으니 새는 것입니다. 그러니 실력으로 막으려 하기보다, "양쪽을 비교해서 새는 데를 잡는" 구조로 푸는 게 맞습니다. 사람을 갈아 넣는 대신, 단계를 점검하는 것입니다.

본론 6 — 디자인과 개발 사이를 좁히는 실무 팁

오늘의 핵심인 "옮기다 새는 토큰"을 줄이는, 현장에서 바로 쓸 만한 팁 몇 가지를 정리해보겠습니다. 다섯 개를 다 하긴 어려워도, 앞의 둘만 챙겨도 새는 양이 눈에 띄게 줄어듭니다.

① 색·간격은 "값"이 아니라 "이름"으로 넘기기

핸드오프할 때 디자이너가 "이 버튼은 이 색상 코드"라고 색 값을 넘기면, 개발자가 그 숫자를 손으로 박습니다. 그러면 새기 쉽습니다. 대신 "이 버튼은 브랜드 블루 토큰"이라고 이름으로 넘기면, 개발도 그 이름을 쓰게 되고 값이 틀어질 일이 줄어듭니다. 값이 아니라 이름(토큰)으로 소통하는 것이 첫걸음입니다. 이름으로 부르면, 그 이름이 가리키는 값이 하나로 고정되니까요. 디자인 도구의 변수 기능을 쓰면 이게 한결 수월해집니다.

② 토큰을 한 소스로 연결하기

이상적인 건 디자인 토큰과 코드 토큰이 하나의 소스에서 나오는 것입니다. 디자인에서 브랜드 블루를 바꾸면 코드의 브랜드 블루도 같이 바뀌게요. 이러면 애초에 어긋날 수가 없습니다. 완벽하게 구축하려면 품이 들지만, 자주 바뀌는 핵심 토큰 — 브랜드 색, 기본 글자 크기 같은 것들 — 만이라도 연결해두면 새는 양이 확 줄어듭니다. 전부를 연결하지 못하더라도, 가장 중요한 몇 개만 묶어두면 효과가 큽니다.

③ 핸드오프 체크리스트 만들기

디자인을 개발에 넘길 때 확인할 것들을 짧게 목록으로 정해두면 좋습니다. "색은 토큰 이름으로 표기됐나", "상태별(기본·마우스 올림·비활성) 디자인이 다 있나", "모바일 화면도 그려졌나", "터치 대상 크기가 표기됐나" 같은 것들입니다. 이 몇 줄만 있어도 앞서 본 "핸드오프 손실"이 줄어듭니다. 빠뜨리는 게 줄어드니까요. 사람의 기억에 의존하지 말고, 목록에 의존하는 것이 핵심입니다.

④ 배포 후 도면과 비교하기

가장 확실한 건, 배포된 사이트와 원래 도면을 비교해보는 것입니다. 둘이 벌어진 자리가 "옮기다 샌 지점"입니다. 사람이 눈으로 비교하면 미세한 건 못 잡으니, 도면 기준(Figma 분석)과 구현 기준(URL 분석)을 각각 자동으로 보고 그 차이를 확인하는 게 낫습니다. 이게 본론3에서 말한 "두 시점으로 틈 잡기"의 실무 버전입니다. 눈으로 대충 맞춰보는 것과, 값 단위로 대조하는 것은 정밀도가 다릅니다.

⑤ 한 번이 아니라 개편 때마다

이 확인을 개편이나 큰 수정 때마다 습관으로 만들면, 토큰이 새는 걸 그때그때 잡습니다. 안 그러면 샌 게 쌓여서, 나중에는 어디가 표준이고 어디가 샌 건지도 헷갈리는 상태가 됩니다(본론1의 첫 팀처럼요). 자주 볼수록 적게 샙니다. 큰 개편 직후는 특히 새기 쉬운 시점이니, 그때 한 번 맞춰보는 습관이 값어치를 합니다.

이 다섯 개를 정리하면, 앞의 셋(①②③)은 "애초에 안 새게 막는 것"이고, 뒤의 둘(④⑤)은 "그래도 샌 건 잡아내는 것"입니다. 막는 것과 잡는 것을 같이 두면, 어느 한쪽이 뚫려도 다른 쪽이 받쳐줍니다. 완벽하게 안 새게 만드는 건 어려우니, 새더라도 잡히게 해두는 이중 안전장치가 마음을 놓이게 합니다.

본론 7 — 이게 왜 공공 사이트에서 특히 중요한가

지금까지 이야기는 어떤 웹사이트에나 적용됩니다. 그런데 공공 사이트에서는 이 "디자인과 개발 사이의 누수"가 특히 중요해집니다. 몇 가지 이유가 있습니다.

첫째, 공공 사이트는 지켜야 할 기준이 명확하게 정해져 있습니다. KRDS라는 공식 디자인 기준이 있고, 색·타이포·간격 같은 디자인 토큰이 표준으로 규정되어 있습니다. 민간 사이트라면 "우리 브랜드 색은 우리가 정한다"가 되지만, 공공 사이트는 "표준을 따라야 한다"가 됩니다. 그러니 도면에서 표준을 잘 지켰어도 구현에서 어긋나면, 그건 단순한 취향의 문제가 아니라 기준 미준수의 문제가 됩니다. 지켜야 할 선이 분명한 만큼, 그 선을 넘었는지 아닌지도 분명하게 드러납니다.

둘째, 공공 사이트는 여러 부서와 여러 업체가 얽혀 만듭니다. 디자인을 맡은 곳과 개발을 맡은 곳이 다르고, 운영을 맡은 곳이 또 다른 경우가 흔합니다. 손을 거치는 단계가 많을수록, 그 사이사이가 다 잠재적인 누수 지점이 됩니다. 앞서 "핸드오프는 번역"이라고 했는데, 번역을 여러 번 거칠수록 원문에서 멀어지는 것과 같습니다. 그러니 각 이음매를 확인하는 일이 더 중요해집니다.

셋째, 공공 사이트는 사용자 층이 넓습니다. 젊은 사용자만 오는 게 아니라, 고령의 사용자도 오고, 오래된 기기를 쓰는 분도 옵니다. 디자인 토큰이 어긋나 글자 크기가 표준보다 작아지거나, 색 대비가 표준에 못 미치면, 그 영향을 가장 크게 받는 건 이런 사용자들입니다. 도면에서 표준을 지켰다면 이런 분들도 배려된 화면이 나왔을 텐데, 구현에서 어긋나면서 그 배려가 새어버립니다. 표준이 지키려던 사람들이, 누수 때문에 가장 먼저 불편을 겪는 셈입니다.

넷째, 공공 사이트는 오래 삽니다. 한 번 만들면 몇 년을 씁니다. 그 사이 담당자가 바뀌고, 콘텐츠가 쌓이고, 급한 수정이 여러 번 들어갑니다. 처음에는 도면과 똑같이 구현됐어도, 시간이 지나면서 표준을 건너뛴 수정이 하나둘 얹히며 조금씩 벌어집니다. 그래서 "한 번 잘 만들었다"로 끝나지 않고, 도면과 구현의 거리를 주기적으로 다시 좁혀야 합니다. 오래 사는 만큼, 관리도 오래 이어져야 하는 것입니다.

이 네 가지가 겹치니, 공공 사이트에서는 "디자인 통과"에서 멈추면 안 되고, "구현도 표준에 맞나"를 반드시 따로 확인해야 합니다. 기준이 명확하고, 손을 거치는 단계가 많고, 사용자 층이 넓고, 오래 사는 사이트일수록, 두 시점을 같이 보는 일의 값어치가 커집니다.

본론 8 — 두 시점을 언제, 어떤 순서로 배치하나

"설계도 보고 운영도 보라"는 원칙은 분명한데, 막상 현장에서는 "그럼 대체 언제 뭘 보라는 거냐"가 막막할 수 있습니다. 그래서 두 시점을 시간 축 위에 놓고, 어느 지점에서 무엇을 보는지 순서로 정리해보겠습니다. 이걸 한 번 잡아두면, 오늘 이야기가 추상적인 원칙이 아니라 구체적인 일정이 됩니다.

첫 번째 지점은 디자인이 끝나고 개발에 넘기기 직전입니다. 이때가 설계 시점, 즉 Figma 분석의 자리입니다. 여기서 도면의 토큰이 표준 안에 있는지를 한 번 훑습니다. 앞서 본론4에서 말했듯, 검수 단계를 새로 만드는 게 아니라 어차피 하는 마무리 과정에 자동 대조를 한 번 끼우는 것입니다. 여기서 걸러진 표준 밖 값을 정리하면, 개발자는 깨끗한 도면을 받습니다. 첫 번째 팀의 실패는 바로 이 지점을 건너뛰어서 생겼습니다. 지우개로 지울 수 있는 유일한 순간을 흘려보낸 것이죠.

두 번째 지점은 개발이 끝나고 막 배포한 직후입니다. 이때가 운영 시점, 즉 URL 분석의 첫 자리입니다. 도면을 잘 잡았더라도, 그게 코드로 정확히 옮겨졌는지는 여기서 처음 확인됩니다. 본론2의 두 번째 팀은 이 지점을 건너뛰어서 "통과인데 위반"에 빠졌습니다. 잘 만들었다는 확신이 이 확인을 밀어냈던 것이죠. 배포 직후는 아직 콘텐츠가 많이 쌓이기 전이라, 순수하게 "옮기다 샌" 부분만 깔끔하게 드러나는 좋은 시점이기도 합니다. 도면과 이 첫 운영 결과를 같은 잣대로 비교하면, 핸드오프에서 벌어진 틈이 값으로 보입니다.

세 번째 지점은 배포 이후 주기적으로 반복되는 자리입니다. 여기도 운영 시점인데, 성격이 조금 다릅니다. 첫 배포 직후가 "옮기다 샌 걸 잡는" 자리라면, 주기적 점검은 "시간이 지나며 다시 벌어진 걸 잡는" 자리입니다. 콘텐츠가 쌓이고, 담당자가 바뀌고, 급한 수정이 표준을 건너뛰며 들어오는 동안, 처음엔 맞았던 구현이 조금씩 어긋납니다. 그래서 도면과 구현의 거리는 한 번 좁혔다고 끝이 아니라, 주기적으로 다시 좁혀야 합니다. 이 정기적인 시점 비교와 성과 추적을 조직 운영 관점에서 어떻게 세우는지는 11개월차에서 본격적으로 다룹니다.

이 세 지점을 시간 순서로 보면, 설계 시점 한 번과 운영 시점 여러 번이 됩니다. 설계 시점은 만들기 전 한 번, 싸게 미리 거르는 자리입니다. 운영 시점은 배포 직후 한 번, 그리고 그 뒤로 주기적으로, 진짜를 확인하고 변화를 따라가는 자리입니다. 첫 번째 팀은 첫 지점을, 두 번째 팀은 두 번째 지점을 놓쳤습니다. 세 지점을 다 챙기면 두 팀의 실패가 모두 예방됩니다. 그리고 이 배치가 익숙해지면, "언제 봐야 하나"를 매번 고민하지 않아도 됩니다. 넘기기 전에 한 번, 배포 직후에 한 번, 그다음엔 주기적으로 — 이 리듬이 몸에 배면 됩니다.

한 가지 덧붙이면, 이 세 지점을 다 챙긴다고 해서 일이 세 배로 늘어나는 건 아닙니다. 설계 시점의 도면 점검과 운영 시점의 구현 점검이 같은 KRDS 기준을 쓰니, 결과를 읽는 방식이 같습니다. 한 번 읽는 법을 익히면 세 지점 모두에 그대로 적용됩니다. 오히려 각 지점에서 조금씩 걸러두면, 마지막에 몰아서 대공사를 하는 것보다 전체 품이 줄어듭니다. 작게 여러 번 보는 것이, 크게 한 번 뒤집는 것보다 싸다는 것 — 이게 오늘 두 사례가 결국 말하는 것입니다.

그래서 ViewCheck는

ViewCheck가 Figma 분석과 URL 분석을 둘 다 가진 게 이 때문입니다. 따로 노는 도구 둘이 아니라, 설계 시점과 운영 시점을 하나의 흐름으로 잇기 위한 것입니다. 도면은 Figma 분석으로 기준에 맞는지 보고, 구현된 사이트는 URL 분석으로 확인하고, 둘 사이가 벌어진 자리를 짚습니다. 같은 KRDS 기준으로 두 시점을 보니, 결과를 나란히 놓고 비교할 수 있습니다.

오늘 두 사례에 대입하면 이렇습니다. 첫 번째 팀의 "도면 안 봐서 비싸짐"은 Figma 분석으로 도면 단계에서 막고, 두 번째 팀의 "통과인데 위반"은 URL 분석으로 배포 후에 잡습니다. 한쪽만 있으면 한쪽에서 새니, 둘을 같이 두는 것입니다. 거창한 게 아니라, 오늘 이야기한 두 교훈을 그대로 구조로 옮긴 것뿐입니다.

그리고 URL 분석 쪽을 조금 더 말씀드리면, 운영 사이트를 볼 때 ViewCheck는 화면 하나만 훑고 끝내지 않습니다. 색·타이포·간격 같은 디자인 토큰이 표준 안에 있는지를 항목별로 대조하고, 그 밖에도 접근성·성능·보안 같은 스무 개가 넘는 영역을 함께 봅니다. 디자인 토큰만 보는 게 아니라, 사이트의 여러 면을 같은 한 번의 분석에서 확인하는 것이죠. 그중 디자인 토큰(디자인 스타일) 영역이 오늘 이야기한 "옮기다 샌 토큰"을 잡아내는 자리입니다.

한 가지 더 짚어둘 게 있습니다. 사람 눈으로는 표준 파랑과 그 옆 파랑을 구별하지 못한다고 여러 번 말씀드렸는데, ViewCheck는 이걸 값으로 가릅니다. 화면에서 실제로 쓰인 색·크기·간격 값을 뽑아, 표준값과 대조합니다. "비슷하다"가 아니라 "이 값이 맞다/틀리다"로 판정하는 것입니다. 그래서 검수에서 통과된, 눈으로는 안 보이는 미세한 이탈까지 드러납니다.

ViewCheck 디자인 스타일 항목 상세 화면. 특정 색·글자·간격 토큰을 펼치면 그 값이 KRDS 표준값과 나란히 놓여 어디서 어긋났는지가 값 단위로 표시된다. 사람 눈엔 "비슷한 파랑"이지만, 여기서는 "이건 표준 색이 아니다"가 정확히 갈린다 (게재 시 기관명·도메인 블러)

그리고 두 시점이 한곳에 있으면, 본론3에서 말한 "비교 진단"이 쉬워집니다. 같은 기준으로 도면도 보고 구현도 봤으니, 둘을 나란히 놓고 "어디서 벌어졌나"를 볼 수 있습니다. 도구가 따로따로면 이 비교 자체가 또 사람 손일이 됩니다. 결과 양식도 다르고 기준도 다르니 맞춰보는 데 시간이 드니까요. 같은 틀 안에 있으면 그 비교가 자연스럽습니다. 그게 설계와 운영을 따로 사는 것과, 한 흐름으로 두는 것의 차이입니다. 다시 강조하지만 핵심은 ViewCheck가 아니라 "두 시점을 같은 기준으로 비교한다"는 원칙이고, ViewCheck는 그걸 한곳에서 하게 해둔 것뿐입니다.

참고로 이런 세부 분석의 뒤에는 두 개의 엔진이 함께 돕습니다. 하나는 화면의 구조를 읽어 규칙에 맞는지 판정하는 규칙 엔진이고, 다른 하나는 화면을 눈처럼 보고 컴포넌트를 알아보는 시각 AI입니다. 규칙 엔진이 값을 근거로 확정한 판정은, 시각 AI가 임의로 뒤집지 않습니다. 근거로 확정된 건 확정된 대로 두고, 판단이 애매한 자리만 AI가 거드는 구조입니다. 그래서 "값이 이래서 이 판정"이라는 근거가 흔들리지 않습니다. 오늘 이야기한 토큰 대조도, 결국 이 값 기반 판정 위에서 이뤄집니다.

🔐 특허로 지키는 부분

오늘 본 "도면 단계의 디자인 기준 충족도와 운영 단계의 구현 충족도를 같은 척도로 비교해, 둘 사이가 벌어진 '옮기다 샌 지점'을 짚어내는 방법"은 ViewCheck가 출원한 5건의 특허 중 설계·운영 시점 교차 비교, 그리고 시점 비교·정기 추적 주제와 맞닿아 있습니다. 도면과 결과물을 따로따로 보는 건 누구나 합니다. 차별점은, 둘을 같은 KRDS 기준·같은 척도로 정렬해 "어느 단계에서 얼마나 어긋났나"를 값으로 드러내고, 그걸 주기적으로 다시 맞춰 추적하는 절차를 권리로 정리해 둔 데 있습니다.

다만 솔직히 짚어둘 게 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 비교 진단이 실제로 정확하냐는 오늘 본 두 시점 대조가 제대로 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법을 직접 만들고 지켜두었다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 단계임을 정확히 표기합니다. "등록특허"가 아니라 "출원 기술"입니다. 과장하면 오히려 신뢰가 깨지니까요. (특허 출원 기술 / 자체 개발)

마무리

오늘은 도면 단계의 양면을 봤습니다. 도면을 안 보면 비용이 뒤로 밀려 불어나고(첫 번째 팀), 도면만 보고 운영을 안 보면 통과인데 위반이 됩니다(두 번째 팀). 둘 다 "한쪽만" 봐서 생긴 일입니다. 그래서 설계와 운영, 두 시점을 시간 순서로 다 보는 게 답입니다. 특히 디자인 토큰이 코드로 옮겨지는 그 이음매가 잘 새니까, 양쪽을 비교해서 그 틈을 잡아야 합니다.

기억할 한 문장은 이겁니다. "디자인 통과"는 출발 신호이지 도착 신호가 아닙니다. 도장을 받은 그 순간이 끝이 아니라, 그 도장의 유효 범위를 넘어선 곳을 마저 확인하는 일이 남아 있다는 뜻입니다. 도면이 맞아도 강을 건너며 새고, 시간이 지나며 또 벌어집니다. 그래서 도면도 보고, 구현도 보고, 가끔 둘을 맞춰봐야 합니다. 잘 만들었다는 확신이 들 때일수록 한 번 더 확인하는 것이, 오늘 두 팀이 알려준 교훈입니다.

이건 사람을 못 믿어서가 아닙니다. 디자이너도 개발자도 다 제대로 했습니다. 다만 "도면 → 코드"라는 변환은 사람 손을 거치는 한 늘 조금씩 새기 마련이고, 그건 누구의 실력 문제가 아니라 과정의 속성입니다. 그래서 실력으로 막으려 하기보다, "양쪽을 비교해서 새는 데를 잡는" 구조로 푸는 게 맞습니다. 사람을 갈아 넣는 대신 단계를 점검하는 것. 이 시리즈 처음부터 이어진 그 이야기가, 디자인과 개발의 경계에서도 똑같이 적용됩니다.

금요일엔 좀 더 실용적으로 갑니다. Figma 파일에서 KRDS 준수를 실제로 어떻게 보는지 — 토큰을 어떻게 대조하고, 컴포넌트를 어떻게 맞춰보는지 — 그 개요를 정리하겠습니다. 오늘이 "왜 도면도 보고 운영도 봐야 하나"였다면, 금요일은 "도면을 구체적으로 어떻게 보나"입니다. 참고로 Figma 분석의 더 깊은 이야기, 그러니까 세부 작동 방식과 실무 활용은 7개월차에서 본격적으로 다룹니다. 오늘과 금요일은 그 큰 그림의 개요입니다.

오늘도 끝까지 읽어주셔서 고맙습니다. 다음에 누가 "디자인은 분명 맞게 했는데요"라고 하면, 한 번쯤 "그럼 배포된 화면의 값은 어떤가요?"라고 되물어보시면 좋겠습니다. 금요일에 이어가겠습니다.

krds.viewcheck.co.kr