You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _posts/2015-01-16-design-with-code.md
+8-8Lines changed: 8 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -55,15 +55,15 @@ publish: true
55
55
56
56
#### Git
57
57
58
-
이 글을 읽는 비개발자를 위해 잠시 설명하자면 Git은 '버전 관리 시스템'입니다. 계좌에 돈을 이체하거나 출금하면 거래 명세에 몇 시 몇 분에 누가 어떻게 돈을 옮겼는지 기록이 남는 것과 비슷합니다. 코드를 수정하면 그 수정 명세를 볼 수 있고, 그게 어떤 것을 위한 수정이었는지 노트도 남길 수 있습니다. 좀 더 자세한 설명을 원하는 사람들은 [이 문서](http://Git-scm.com/book/ko/v1/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0)를 참고해 보시면 도움이 될 듯합니다. (혹은 지나가는 개발자에게 물어보는 게 빠를 수도 있습니다.) Git은 그 개념을 완벽히 이해하지 않더라도 사용하는 데 큰 지장은 없습니다. ~~(만 부들부들하는 개발자가 있으려나요?)~~ 마치 디자이너가 벡터의 렌더링 방식을 이해하지 못해도 디자인을 하는 데 큰 어려움이 없는 것과 같습니다. ~~(부들부들)~~
58
+
이 글을 읽는 비개발자를 위해 잠시 설명하자면 Git은 '버전 관리 시스템'입니다. 계좌에 돈을 이체하거나 출금하면 거래 명세에 몇 시 몇 분에 누가 어떻게 돈을 옮겼는지 기록이 남는 것과 비슷합니다. 코드를 수정하면 그 수정 명세를 볼 수 있고, 그게 어떤 것을 위한 수정이었는지 노트도 남길 수 있습니다. 좀 더 자세한 설명을 원하는 사람들은 [이 문서](http://Git-scm.com/book/ko/v1/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0)를 참고해 보시면 도움이 될 듯합니다. (혹은 지나가는 개발자에게 물어보는 게 빠를 수도 있습니다.) Git은 그 개념을 완벽히 이해하지 않더라도 사용하는 데 큰 지장은 없습니다. <del>(만 부들부들하는 개발자가 있으려나요?)</del> 마치 디자이너가 벡터의 렌더링 방식을 이해하지 못해도 디자인을 하는 데 큰 어려움이 없는 것과 같습니다. <del>(부들부들)</del>
59
59
60
60
#### GitHub [^6]
61
61
62
62
GitHub이 무엇인진 모르더라도 개발 직군과 밀접히 일하는 디자이너라면 한 번쯤은 들어봤을 겁니다. [GitHub](https://GitHub.com)이나 [BitBucket](https://bitbucket.org)은 버전 관리를 쉽게 해주는 서비스입니다. 디자이너라면 [Pixelapse](https://www.pixelapse.com)의 개발자 버전이라고 생각하면 됩니다. GitHub을 사용하면 코드의 히스토리를 관리하는 것 외에도 `이슈`를 적어 어떤 일을 해야 하는지 효과적으로 정리할 수 있습니다. 일종의 to-do 시스템이라고 볼 수도 있습니다.
63
63
64
64
스포카에선 디자이너가 개발 환경을 갖추기 전부터 크리에이터팀 전원이 이슈 베이스의 업무 프로세스[^7]를 구축하고 있어서 GitHub에서 이슈를 만들고 어사인과 라벨을 설정하는 일은 자유롭게 하고 있었습니다. PR에 대해서는 이슈와 비슷하지만 좀 더 코드와 밀접하게 연결된 무엇이고, 그것에 이슈를 언급하면 레퍼런스가 되며 `merge` 상태가 되면 `완료` 됐다는 정도만 알고 있었습니다.
65
65
66
-
처음 PR을 올리고 머지하는 과정에서는 어떻게 내가 수정한 내용을 PR로 만드는지 헷갈렸습니다. '첫 페이지에 나타나는 초록색 버튼을 누르면 된다'고 외웠는데 그 '초록색 버튼'이 간혹 나타나지 않을 때도 있었기 때문입니다. 그러나 PR을 올린 후에는 이슈를 생성하는 것과 크게 다르지 않으므로 별다른 어려움은 없었습니다.
66
+
처음 PR을 올리고 머지하는 과정에서는 어떻게 내가 수정한 내용을 PR로 만드는지 헷갈렸습니다. '첫 페이지에 나타나는 초록색 버튼을 누르면 된다'고 외웠는데 그 '초록색 버튼'이 간혹 나타나지 않을 때도 있었기 때문입니다. 그러나 PR을 올린 후에는 이슈를 생성하는 것과 크게 다르지 않으므로 별다른 어려움은 없었습니다.
67
67
68
68
#### SourceTree
69
69
@@ -107,7 +107,7 @@ Git이나 GitHub은 디자이너가 잘 이해하지 못해도 사용이 별로
107
107
*`margin``padding`이 간격에 대한 것이라고 이해하고 정확한 차이는 몰랐다.
108
108
*`pseudo class`는 전혀 몰랐다.
109
109
110
-
보면 알겠지만, 아주 기본적인 내용만 이해하고 있었습니다. ‘일주일 만에 배우는 HTML과 CSS’ 같은 기성 강의를 들으면 얻을 수 있는 지식수준이었습니다. ~~(적으면서도 놀랍군요.)~~ 그러므로 아마 백지의 문서에 0번째 줄부터 스타일을 작성하라고 했다면 훨씬 어려웠거나 좌절하고 시도하지 않았을 것입니다. 하지만 기존의 코드를 보면서 이미 작성된 스타일 코드에 값만 바꿔주는 일은 그리 어렵지 않았습니다. 물론 디자이너가 머릿속에서 상상하는 부드러운 모바일 대응과 패러럴랙스 스크롤 같은 것은 구현할 수 없었지만 단지 색상과 보더, 여백 옵션을 수정하는 것만으로도 큰 디자인 개선을 이룰 수 있었습니다.
110
+
보면 알겠지만, 아주 기본적인 내용만 이해하고 있었습니다. ‘일주일 만에 배우는 HTML과 CSS’ 같은 기성 강의를 들으면 얻을 수 있는 지식수준이었습니다. <del>(적으면서도 놀랍군요.)</del> 그러므로 아마 백지의 문서에 0번째 줄부터 스타일을 작성하라고 했다면 훨씬 어려웠거나 좌절하고 시도하지 않았을 것입니다. 하지만 기존의 코드를 보면서 이미 작성된 스타일 코드에 값만 바꿔주는 일은 그리 어렵지 않았습니다. 물론 디자이너가 머릿속에서 상상하는 부드러운 모바일 대응과 패러럴랙스 스크롤 같은 것은 구현할 수 없었지만 단지 색상과 보더, 여백 옵션을 수정하는 것만으로도 큰 디자인 개선을 이룰 수 있었습니다.
111
111
112
112
이렇듯 지식이 부족한데도 문제없이 오히려 순조롭게 도입이 가능했던 이유로 몇 가지를 유추해보면, 아래와 같습니다.
113
113
@@ -157,15 +157,15 @@ Git이나 GitHub은 디자이너가 잘 이해하지 못해도 사용이 별로
157
157
<img src="/images/2015-01-06/right_guide.png"
158
158
style="margin-right:auto; margin-left:auto;" />
159
159
160
-
이런 일이 디자인 시안을 코드로 구현하는 과정에서 비일비재하게 일어납니다.
160
+
이런 일이 디자인 시안을 코드로 구현하는 과정에서 비일비재하게 일어납니다.
161
161
162
162
웹 디자이너가 그래픽 툴에서 선을 하나 그릴 때는 높이 1px 짜리의 길쭉한 박스를 그려 넣으면 됩니다. 무척 쉬운 일이고 그 수정 또한 쉽습니다. 하지만 개발자가 그것을 구현할 때는 그 크기만큼의 `div`에 `padding`과 `margin`을 계산해야 합니다. 그러나 대체로 디자이너들은 `padding`과 `margin`을 **여백**이라는 하나의 개념으로 생각하기 때문에 규칙이 정확하지 않은 시안으로 그것을 정확히 구현하는 데는 한계가 있습니다. 마치 금박을 사용한 인쇄물 시안을 CMYK로만 출력해서 원하는 결과물을 얻어낼 수 없는 것과 같습니다.
163
163
164
164
코드로 디자인을 수정하기 시작하면서 얻은 가장 큰 성과는 구현할 수 있는 규칙을 이해하게 됐다는 점입니다. 나아가 어느 정도 HTML의 구조와 스타일 코드 작성에 눈이 익으니 스스로 규칙을 세울 수 있게 되었습니다. 이렇게 세운 규칙은 그래픽툴 속에서 세운 규칙보다 더 체계적이며 실현 가능하고 문제 상황에 집중되어 있습니다.
165
165
166
166
### 병렬적 사고
167
167
168
-
대부분의 디자인 프로세스는 직렬적으로 진행됩니다.
168
+
대부분의 디자인 프로세스는 직렬적으로 진행됩니다.
169
169
170
170
1. 1차 시안 완성
171
171
2. 2차 시안 완성
@@ -242,7 +242,7 @@ publish 된 결과물이 같아 보이더라도 어떤 방법을 사용했는지
242
242
243
243
믿기 힘들겠지만, 코드로 디자인을 하는 게 그래픽툴로 디자인을 하는 것보다 훨씬 빠릅니다. 구체적으로 표현하면 코드로 한번에 수정이 되는 부분과 그래픽 툴에서 한 번에 수정이 되는 부분이 다른데, 전자가 커버하는 영역이 훨씬 큽니다. 예를 들면 아래와 같은 상황입니다. (그래픽 툴이나, 코드에서나 가장 일반적이고 간단한 상황을 가정했습니다.)
244
244
245
-
- 모든 버튼의 모서리 값을 수정한다.
245
+
- 모든 버튼의 모서리 값을 수정한다.
246
246
- 그래픽 툴: 모든 버튼의 path를 선택한 다음에 모서리 값을 수정한다.
247
247
- 코드: `$button-radius-base` 의 값을 수정한다.
248
248
@@ -275,7 +275,7 @@ publish 된 결과물이 같아 보이더라도 어떤 방법을 사용했는지
275
275
276
276
### 장점 - 가이드의 종말
277
277
278
-
디자이너들이라면 가이드를 치는 스트레스를 모두 알고 있습니다.
278
+
디자이너들이라면 가이드를 치는 스트레스를 모두 알고 있습니다.
279
279
280
280
- 어떤 색상은 Hex로 알려달라고 하고 어떤 색상은 RGBA로 알려달라는데 무슨 차이지?
281
281
- 1~2px 요소는 크기가 작아서 가이드 정보를 쓰기가 애매하군.
@@ -320,7 +320,7 @@ publish 된 결과물이 같아 보이더라도 어떤 방법을 사용했는지
320
320
321
321
코드로 디자인을 하기가 쉽지만은 않습니다. 살면서 한 번도 들어본 적 없는 프로그램들을 익혀야 하고, 예쁘지도 않은 terminal을 보며 얘가 뭐라고 하는 건가 골머리를 싸매야 하기도 합니다. 하지만 이미 많은 디자이너들이 자신이 만든 작업물이 구현되는 과정에 참여하길 원하고 있습니다. 아마 그만큼 많은 개발자들이 이해할 수 없는 가이드를 보며 해독하는 작업에 스트레스를 느끼고 있을 것입니다. 스포카도 그러한 진통을 겪었기에 디자이너도 코드를 다루자는 결단을 내렸고 그 결과는 실로 고무적이었습니다. 디자인/레이블 버그가 점차 사라지는 것을 시작으로 얼마 지나지 않아 생산성을 약 3배 정도[^10] 상승시킬 수 있었습니다. 심지어 디자이너가 코드에 전혀 익숙하지 않았을 때도 전체 생산성은 상승했습니다. 애초에 목적은 '간단한 디자인 버그를 고쳐보자' 정도였지만 지금은 '앞으로 스포카의 스타일 코드는 어때야 하는가'를 고민하면서 되돌아보건데, 코드로 디자인을 한다는 것은 무척 현명한 선택이었습니다.
322
322
323
-
외주로 작업을 한다든 가, 팀간의 구분이 확고한 회사 문화 등 모두가 코드로 디자인을 할 수 있는 환경은 아닐 것입니다. 하지만 지난 일 년 동안 새로운 방식으로 작업함으로써 새로이 느낀 점과 배운 점이 컸기에 좀 더 많은 디자이너, 개발자 그 외에 PM이던가 기획자라던가 혹은 매니저들이 디자인을 하고 그것을 구현하는 방법을 한번 고민해봤으면 하는 바람입니다.
323
+
외주로 작업한다든가, 팀 간의 구분이 확고한 회사 문화 등 모두가 코드로 디자인을 할 수 있는 환경은 아닐 것입니다. 하지만 지난 일 년 동안 새로운 방식으로 작업함으로써 새로이 느낀 점과 배운 점이 컸기에 좀 더 많은 디자이너, 개발자 그 외에 PM이던가 기획자라던가 혹은 매니저들이 디자인을 하고 그것을 구현하는 방법을 한번 고민해봤으면 하는 바람입니다.
324
324
325
325
[^1]: 야심 차게 '코드로 디자인하기'라고 적었지만, 실제로 제가 관여했던 많은 부분은 HTML과 SCSS로 구성된 웹이었습니다. 따라서 본 포스트에는 iOS, Android의 디자인 구현에 대한 내용은 없습니다. 하지만 앞으로도 스포카에서는 디자이너가 HTML, SCSS 이외의 언어를 배워나가며 직접 구현과 배포에 참여할 계획이고, 포스트의 내용도 코드 기반의 환경 도입과 그래픽 툴과의 차이에 집중하고 있으므로 'HTML과 SCSS로 디자인하기'보다는 광의적인 '코드로 디자인하기'라고 지었습니다. 이 글에서 '코드로 디자인을 한다'는 것은 개발부터 배포까지를 모두 뜻합니다.
0 commit comments