- 빅픽처 인터랙티브 프론트엔드(Frontend) 챕터 소속 박성렬 개발자
뜻을 모르겠습니다. 잘 생각해보면 알아차릴 수 있는 것도 아닙니다. 답답해서 지식인에 물어보고 싶다는 생각도 듭니다. 모로 누워서 뒤척이다가 어영부영 밤이 넘어갑니다. 차라리 듣지나 말았을걸. 의도가 분명하지 않은 표현들은 늘 당혹스럽습니다. 그게 무의식의 하수구에서 끌어올려 별 생각없이 내뱉은 아주 하찮은 소리였을지라도요.
표현은 왜곡되고 말들은 엇나갑니다. 의사소통이 많은 곳에서는 그만큼 많은 오해가 발생합니다. 개발팀은 말할 것도 없습니다. 그 중에서도 하물며 서로 말하는 방식이 다른 디자인과 프론트엔드(FE)와 디자인은 최악의 관계가 될 가능성이 매우 높습니다. 디자인의 언어만으로는 의도를 명확하게 전달하기 어렵기 때문입니다. 디자인과 웹은 서로 다른 언어를 사용하여 소통합니다. 이번 글을 통해서 figma(이하 피그마)라는 웹 디자인 도구를 통해 어떻게 서로 다른 두 부서가 소통할 수 있을지 고민해 보았습니다.
다음 이야기에 나올 내용을 이해하기 위해서 먼저 설명할 것이 있습니다.
알파벳 이해하기
아래에서 픽셀과 벡터를 설명합니다. 알고 계신 분은 건너 뛰셔도 좋습니다.
여기 세 개의 원이 있습니다. 이것을 말로 나타내면 아래와 같습니다.
화면 가운데에 원이 있고, 그 옆에 원이 하나씩 더 있다.
한글로 설명하면 조사가 붙기 때문에 조금 복잡합니다. 영어로 바꿔 보겠습니다.
circle's on center with two other circles on both side.
이것을 좀더 쉽게 기호처럼 만들면 아래와 같이 됩니다.
circle→center
two other circle→both side
이 과정이 필요한 이유는, 위치를 설명하기 위한 것과 상관 없는 언어적인 조미료가 너무 많기 때문입니다.
픽셀
우리에게 좀더 익숙한 비트맵(bitmap) 혹은 픽셀(pixel) 방식으로 다시 표현해 보겠습니다. 포토샵에서 사용하는 방식으로 이해하시면 될 것 같습니다. 위에서 모양을 비슷하게 만들어 놓았기 때문에 좀 더 이해하기 쉬워졌습니다.
(공간이 가로 3 x 세로1일 때)
circle1 → (가로 1, 세로 1)
circle2 → (0,1)
circle3 → (2,1)
각 세 지점에 점을 찍었고 위치는 처음에 그렸던 원들과 동일합니다. 다만 필요 없는 조사를 걷어내고 전부 숫자로 대신했을 뿐입니다. 이것이 일반적으로 디자인이 이야기하는 언어입니다.
벡터
꼭 필요한 것은 아니지만, 웹을 본격적으로 이해하기 전에 상대적으로 비교하기 위한 대상으로 벡터도 소개하겠습니다. 일러스트레이터에서 사용되는 방식입니다.
벡터는 모든 위치를 상대적인 개념으로 설명합니다.
circle 1 → center
circle 2 → circle 1에서 circle 1의 크기만큼 왼쪽으로 이동
circle 3 → circle 1에서 circle 1의 크기만큼 오른쪽으로 이동
여기서 circle 1의 위치와 크기가 중심이기 때문에, circle 1이 커지거나 이동하면 나머지도 똑같이 따라 움직입니다. 모든 것이 상대적이기 때문에 공간의 크기는 중요하지 않습니다.
일러스트레이터에서는 Artboard라는 것을 통하여 화면의 크기를 상대적인 크기로 제한(clipping 혹은 masking)하는 눈속임을 보여주지만, 실제로는 그 너머의 공간에서도 그림은 계속 그려질 수 있습니다.
픽셀과 벡터는 모두 똑같은 대상을 나타냅니다. 그런데 묘사하는 방식과 공간이 전혀 다릅니다. 위의 개념을 네 개의 점을 표기한 도식으로 다시 한 번 정리해보도록 하겠습니다.
- 픽셀은 가로 좌표와 세로 좌표로 위치를 나타냅니다.
- 벡터는 가로와 세로를 상대적으로 참조하여 위치를 나타냅니다. 위의 그림은 기준이 공간에 있는 픽셀과 비교하기 위하여 공간을 기준으로 했을 경우를 나타낸 것입니다.
위의 그림을 보고 아래의 웹을 보시면 전혀 다르다는 것을 느끼실 수 있습니다.
웹 HTML
사실 이것도 똑같은 위치에 있는 네 개의 점을 나타낸 것입니다.
그런데 어떻게 된 일인지 좌표가 하나도 없습니다! 브라우저의 크기는 항상 변화하기 때문입니다. 포토샵이나 일러스트레이터에 비견하여 말하자면, 캔버스의 크기가 매번 변하면 그림의 요소가 크기에 따라 알아서 자리를 찾아가는 말도 안되는 상황인 것입니다.
위의 그림을 웹의 언어로 설명해 보겠습니다.
parent box의 크기→브라우저의 크기와 같다.
parent box의 흐름(flow)→안에 품고 있는 것들이 왼쪽에서 오른쪽으로 배치된다.
점의 이름은 child box로 부른다.
child box의 형태→ 원(circle)의 모양을 하고 있다.
child box의 가로 크기→ parent box의 1/3 크기이다.
child box의 세로 크기→ parent box의 1/2 크기이다.
child box1→parent box안에 첫 번째로 들어간다.
child box2→parent box안에 두 번째로 들어간다.
child box3→parent box안에 세 번째로 들어간다.
child box4→parent box안에 네 번째로 들어간다.
이것이 일반적으로 웹(HTML)에서 사용되는 표현 방식입니다. 혹은 박스 모델이라고도 합니다. 똑같은 네 가지 점의 위치를 그리는데, 분명히 픽셀도 아니고, 벡터도 아닌 전혀 다른 방식입니다. 심지어 좌표도 없습니다.
웹은 기본적으로 좌표가 없습니다. 대신 모든 것을 흐름(flow)으로 정의합니다. 모든 점, 선, 원은 사각형의 박스 형태입니다. 오로지 그 박스들을 어떤 흐름으로 배치하는가에 따라 레이아웃이 바뀔 뿐입니다.
경우에 따라서 좌표도 사용할 수는 있습니다. 많이 사용하지는 않습니다. 웹에서 좌표는 예외적인 기술법입니다. 브라우저 안의 공간은 비트맵과 달리 언제든 변화할 수 있으면서도, 벡터처럼 무한하지도 않고 유한합니다. 웹은 우리가 알던 픽셀이나 벡터와는 온전히 다른 세계이기 때문입니다.
💡 픽셀≠벡터≠웹
주연배우 등장
그래서 필요한 것이 🎨UI 디자인 도구입니다. 안타깝지만 대체로 실무에서 UI 디자인 도구는 공유와 미리보기가 가능한 일러스트레이터 정도로 사용되는 경우가 많습니다. 유튜브에서 현역 디자이너의 디자인 도구 사용 케이스를 수집해 보았더니 실제로 x년차로 소개되는 디자이너들도 UI 디자인 도구를 일반적인 그래픽 편집 도구처럼 사용하는 경우가 더 많았습니다.
UI 디자인 도구로 웹을 말하는 방법을 거의 모르는 경우가 대부분입니다.
🏭빅픽처 인터랙티브는 UI디자인 도구 중에 피그마를 사용하고 있습니다. 피그마가 뛰어난 디자인 UI 도구인 이유는 여러가지가 있지만, 무엇보다 Auto Layout 등의 기능을 통하여 웹에 가장 근접한 방식으로 표현이 가능한 부분이 가장 큰 장점입니다.
잠시 전에 웹 언어로 보여드렸던 내용을 그대로 피그마로 묘사해 보겠습니다.
첫 번째 문장입니다.
parent box의 크기→브라우저의 크기와 같다.
먼저 Frame을 이용하여 Artboard를 표현합니다.
Frame도구로 사각형을 그립니다. 이 사각형이 Artboard이자 브라우저 화면이 됩니다.
사각형 도구를 선택하여 Frame안에 사각형을 그려줍니다.
방금 그린 사각형을 선택하고 화면 오른쪽의 Design탭에 있는 Constraint 항목에서 사각형의 크기가 브라우저의 크기와 일치하도록 설정합니다.
- Left and right 를 선택하면 브라우저(Frame)의 왼쪽 끝과 오른쪽 끝 위치가 바뀌었을 때 사각형의 너비도 함께 바뀝니다.
- Top and bottom 을 선택하면 브라우저의 위와 아래가 변동한 만큼, 사각형의 폭도 함께 바뀝니다.
이렇게 세팅하면 Frame을 움직였을 때 사각형이 가로 세로 모두 Frame의 크기를 반영하게 됩니다. Frame의 크기를 직접 변경해보면 알 수 있습니다.
다음에 표현할 내용은 아래와 같습니다.
💬 parent box의 흐름(flow)→안에 품고 있는 것들이 왼쪽에서 오른쪽으로 배치된다.
아까 그린 상자를 흐름을 가지고 자식을 품을 수 있는 부모(parent) 상자로 만들어 주어야 합니다. 아까 만든 상자를 선택한 뒤, Design 항목의 Auto Layout오른쪽에 있는 더하기 표시를 누릅니다.
그러면 화면이 아래와 같이 변하면서 흐름을 가지게 됩니다.
화살표(↓→)는 흐르는 방향을 나타냅니다. 웹에서 가장 흔한 두 가지 흐름입니다.
- 위에서 아래로(top to bottom)
- 왼쪽에서 오른쪽으로(left to right)
제일 오른쪽에 있는 상자를 클릭하면 흐름에 정렬을 섞을 수도 있습니다. 화면의 가운데에 위치해야 하므로, 가운데를 클릭하여 가운데 정렬로 만들어 줍니다.
이렇게 설정할 경우 해당 상자 위에서 다른 그림을 그리거나, 밖에 있는 요소들을 상자 안으로 드래그하면 자식(child)이 되어서 자동으로 흐름을 타게 됩니다.
한 편, 오른쪽 Design 탭에 Resizing이 새로 생긴 것을 볼 수 있습니다. 자식 객체를 가지게 되면서 크기 기준을 자식에 맞출 것이냐, 객체 자신만의 크기 기준을 가질 것이냐를 선택할 수 있게 됩니다. 상자의 크기 기준이 Hug Content로 되어있는데, 이것을 Fixed width, Fixed height로 변경해 줍니다. 상자의 크기를 자식 컴포넌트에 맞추(Hug Content)지 않고, 상자의 크기를 보존하도록 합니다.
작업이 완료되면 frame을 왼쪽의 Layer화면에서 더블 클릭해서 이름을 parent box로 바꾸어줍니다.
다음 표현할 내용은,
점의 이름은 child box로 부른다.
child box의 형태→ circle의 모양을 하고 있다.
child box1→parent box안에 첫 번째로 들어간다.
입니다.
먼저 위에서 사각형 도형을 처음에 그린 것과 같은 방법으로, parent box 안에서 동그라미를 하나 그립니다. 그러면 위치가 자동으로 가운데로 이동합니다. 도형이 이미 흐름을 타기 시작했기 때문입니다. 만약 가운데 정렬을 하지 않았다면 기본 정렬된 위치(보통은 왼쪽 위)로 자동으로 정렬됩니다.
이 도형 위에서 오른쪽 버튼을 클릭하여 이름을 가진 컴포넌트로 만들어줍니다.
정상적으로 컴포넌트로 변경되었다면 왼쪽 Layers 화면에서 보라색 마름모꼴로 보입니다.
여기서 Ellipse를 더블 클릭하여 이름을 child box로 변경합니다. 그러면 child box 라는 이름을 가지고, 원 모양의 형태를 가진 컴포넌트가 됩니다. 크기도 조절해야 하지만 크기는 일단 중요한 요건이 아니기 때문에 무시하고, 흐름만 보여드리도록 하겠습니다.
child box2→parent box안에 두 번째로 들어간다.
child box3→parent box안에 세 번째로 들어간다.
그 다음 child box를 마우스로 선택한 뒤에 Ctrl+C, Ctrl+V 또는 Cmd+C, Cmd+V 로 복사 붙여넣기를 두 번 하면 컴포넌트가 복사됩니다.
꽉 찬 마름모는 원본 컴포넌트를 뜻하고, 속이 비어있는 마름모는 복사된 컴포넌트를 뜻합니다. 원본 컴포넌트를 변경하면, 복사된 컴포넌트도 함께 변경됩니다.
여기서 다시 화면을 보시면 아무것도 하지 않았는데 어느새 자동으로 세 지점이 정렬되어있는 것을 보실 수 있습니다.
흐름에 따라 왼쪽에서 오른쪽으로 자동으로 정렬된 것입니다.
흐름을 만들고, 세 가지 자식 컴포넌트를 부모 컴포넌트의 흐름을 타게 만들었습니다. 이제 웹으로 말하는 방법을 배웠습니다.
나니아의 옷장 열기
이제 실무 예제를 보면서 웹으로 FE에게 말하는 것이 어떤 의미인가를 살펴보도록 하겠습니다.
먼저 구글 홈페이지를 보겠습니다.
구글 홈페이지를 흐름으로 나타내면 아래와 같이 됩니다. 실제로는 조금 더 복잡하지만, 이해를 돕기 위해 가장 큰 흐름만 나타냈습니다.
- 흐름1: 제일 위에 있는 상자는 오른쪽에서 왼쪽으로 가는 흐름이 있습니다. 이 상자의 크기는 세로로는 고정이지만, 가로로는 브라우저 상자(Frame)을 따라갑니다. 흐름 1은 흐름 2를 따라가는 하나의 요소이기도 합니다.
- 흐름2: 중앙 흐름입니다. 흐름1과 흐름3을 포함하고 있습니다. 위에서 아래로 내려가는 흐름입니다.
- 흐름3: 중간에 있는 상자는 중앙에서 정렬한 상태로 부터 시작하여, 왼쪽에서 오른쪽으로 가는 흐름입니다. 흐름 3도 흐름 2를 따라가는 하나의 요소입니다.
흐름의 형태만 풀어보면 아래와 같은 그림이 됩니다.
말로 풀어보면 복잡하지만, 가로나 세로로 화면을 늘려보면 왜 그런지 간단합니다.
좌표를 가지지 않고, 오로지 흐름과 정렬로만 표기했기 때문에 화면이 늘어났을 때 원하는 방향으로 화면이 변하도록 유도할 수 있습니다. 너비가 변하는 브라우저의 모든 화면에 대하여 대응하는 방법을 알려줄 수 있는 것입니다.
반대로 흐름을 사용하지 않고 FE와 의사소통 했을 때는 FE가 흐름을 마음대로 상상하게 됩니다. 실제 화면으로 보이는 것과 흐름이 완전히 다를 수 있습니다. FE는 오로지 그림을 보고 상상하기 때문에, 흐름 3을 아래처럼 엉뚱한 모양으로 상상할 수 있습니다.
결과적으로 원래 화면은 작업 요청과 동일합니다. 그러나 화면이 늘어났을 때는 전혀 다른 모습이 됩니다. FE는 이것을 예상하지 못하고 있다가 QA 작업에서 마주합니다. 그리고 수정에 별도의 시간을 소모하게 됩니다. 이것이 FE가 흔히 저지르는 뇌피셜로 인한 실수입니다. 시간상 더 많은 예를 보여드릴 순 없지만 이 과정에서 정말 기상천외한 오판이 자주 일어납니다. 혹은 FE의 판단이 디자인이 요청한 것과 일치했지만, 디자인이 흐름을 잘못 이해하여 실제로 구현한 뒤에서야 흐름에 맞지 않는 것을 알게 되는 경우도 있습니다.
피그마는 결국 웹의 언어를 이용하여 흐름의 착각을 방지하기 위해 고안된 도구입니다.
저기 지금 선 넘으셨는데요...
우려스럽기도 합니다. 어쩌면 FE의 일을 디자인에게 넘기는 것이 아닌지. 피그마의 이런 기능 사용을 요구하는 것은 부서의 책임을 전가하는 일일지도 모릅니다. 하지만 흐름을 디자인이 직접 주체가 되어 통제하는 것은 여러 장점이 있습니다.
- 다른 화면 사이즈에 대한 대응 요청이 들어왔을 때, Frame의 크기만 조절해서 빨리 대응할 수 있다.
- 최대한 좌표의 사용을 제한하여, FE의 설계 난이도를 대략 예측해볼 수 있다. 디자인 실현에 얼마나 많은 비용이 들어갈지 예측할 수 있다. 흐름의 복잡도는 단순히 제작 시간 뿐만 아니라, 브라우저의 다운 용량이나 웹사이트 속도에도 영향을 준다.
- 컨텐츠의 크기를 화면 Breakpoint가 아닌 다른 임의의 화면 사이즈에 제대로 대응하도록 설정했는지 Frame의 크기를 조절하여 미리 확인해볼 수 있다. *컨텐츠의 크기가 Breakpoint와 충돌하는 일이 의외로 비일비재하다
이러한 명제는 어쩌면 FE와 디자인은 처음부터 뗄 수 없는 관계라는 상징일 수도 있습니다. 흐름을 디자인에 반영하기 위한 충분한 경험이나 기술력이 없는 디자이너는 FE의 도움을 받을 수 있고, 디자인 단계부터 자연스럽게 FE와의 협업이 이루어지는 그림을 그려볼 수도 있습니다.
이러한 별도의 디자인 도구를 이용하여 웹 언어로 의사소통하는 목적은 일을 더 하기 위해서가 아닙니다. 오히려 불필요한 잔업을 줄이기 위해서 입니다.
별로 현실적인 이야기가 아닐 수도 있습니다. 판교와 구로의 일화를 들어본 IT 종사자라면 다 아는 이야기입니다. 민첩(lean)한 개발과정이 반드시 명확한 계획 수립에서 이루어지는 것이 아닐수도 있다는 것. 우리가 멋지다고 생각한 앱들이 때로는 악바리에 가까운 근성과 저돌성으로 완성되기도 한다는 것을요. 대부분의 아주 훌륭한 앱은 아마도 황당한 일정과 "그딴거 할 시간 없어!"라고 악다구니를 부리는 통에서 태어났을 것입니다. 슬프지만 일이란 원래 그런게 아닐까 싶기도 합니다. 웹 디자이너들이 피그마를 웹을 위한 소통의 도구로 생각하지 못했던 것도 마찬가지일 것입니다.
우리는 언제나 혼란스럽고 바쁜 일과 와중입니다. 소통이 모자란 것은 누구의 잘못도 아니라고 말하고 싶습니다. 이런 소통방식과 언어가 항상 선택지로 존재하고 있단 걸 알고만 있어도 좋을 것 같습니다. 혹여나 뜻을 찾아 한참동안 헤맸던 말이, 그 이상했던 작업지시가, 사실은 여러분을 위한 애정이나 우정의 표현일지도 모르니까 말입니다. 어떤 표현의 뜻을 안다는 것은 그래서 중요합니다. 잠결에 뒤척이며 누군가를 미워할 일은 없어야 하니까요.
'레벨업의 테크노트' 카테고리의 다른 글
[프론트엔드]Node.js 메모리 누수 탐지하기 (36) | 2022.01.17 |
---|---|
[애자일로 빅픽처를 그리다] 데이터 대시보드 (2) | 2022.01.17 |
[프론트엔드] ClientOnly 컴포넌드 개발 여행 (13) | 2022.01.12 |
[프론트엔드]웹 표준 지키기 - 포커스 표시기 (2) | 2022.01.12 |
[프론트엔드]Vue build time 최적화 해보기 feat.Vite - 2탄 (3) | 2022.01.11 |
댓글