시작하며.
프로젝트가 이제 마무리되어 간다. 결과물을 내기까지 총 6일, 목표했던 3일이 딜레이 됐다.
하루는 코테와 스터디로 인해, 하루는 갑작스러운 일정으로 인해 딜레이 됐지만... 그럼에도 하루가 딜레이 됐음은 부정할 수 없는 사실이다.
일정 산정도 못하는 개발자라니. 아직도 멀었다.
그러나, 나는 부정적인 열등감에서, 오히려 승부욕과 열정의 원동력을 얻는다.
이 제작기 역시 그런 나의 부족함을 이겨내던 순간들을 기록하며 승화하고자, 간만에 글로 남긴다.
하루짜리 조촐한(?) 와이어프레임은 여기에 있다.
1. 구현의 원천으로 삼는 와이어프레임
이번에 느꼈던 놀라운 것은, 바로 와이어프레임을 만들면서 느낀, 디자인에 관한 것이다.
사실 이번에 포트폴리오를 제작하던 초기에, 나는 오만했다.
워낙 마크업은 많이 해봤고, 실제로 빠르게 끝내는 게 장점이라는 칭찬도 현업에서 들었기에, 이번에도 금방 끝내겠거니 싶었는데, 막상 들어가니 엄청 허우적 댔다.
당시를 재현하자면, 다음과 같은 의식의 흐름이 존재했다.
- 오, 이거 구현하면 재밌겠는데? (아이디어)
- 이거 구현해보자! (실행)
- 뭔가... 막상 넣어보니 별로네...? (문제)
- 뭐가 문제일까... 다른 웹사이트 참고해볼까? (해결과정)
- 잠깐, 이런 느낌으로 구현하면 좀 더 낫겠다. 다시 구현하자! (새로운 문제 정의 😭)
자, 살펴 보자. 어떤 게 문제였을까?
내가 내린 결론은... 1번과 2번 사이가 문제였다.
💡 아이디어가 옳다고 해서, 결과물에 항상 옳은 것이 아니다.
예전에 린터와 포맷터에 대해 소홀히 한 때가 있었다.
사실, 그냥 막 쓰면 되는 거 아닌가? 싶었다. 일단 돌아가면 그만이라고 생각했었으니 말이다.
하지만 일하면서, 문제가 복잡해질 수록, 코드 양은 늘어났고, 일관성 없는 코드는 가독성을 현저히 떨어뜨렸다.
이 문제도 이런 느낌을 많이 받았다.
💡 아! 일관성은 당장 느끼지 못해도, 언젠가의 결정을 위해 필요한 거구나.
그렇기에 일관성 있는 디자인의 중요성을 느꼈다.
목표를 정의할 수 있는 근거이자, 원천이 될 수 있기 때문이다.
아무리 새로운 아이디어가 나를 유혹해도, 원칙과 철학이 있다면 흔들리지 않는다.
즉, 정확하게 내가 해야 할 게 무엇인지 알 수 있고, 안정적인 개발을 할 수 있다는 것이다.
그래서 내 애플리케이션을 엎고 다시 와이어프레임을 만들어 보았다.
분명, 새로운 것들이 보이기 시작했다.
- 어... 이거 뭔가 현재의 화면과 너무 안 맞는 느낌인데.
- 여기가 유독 너무 튀네. 좀 줄여 볼까?
- 잠깐, 나 너무 디자인이 복잡해. 이 애플리케이션이 보여줄 '컨셉'은 뭐지?
- 너무 크기들이 들쑥날쑥해. 따로 디자인 시스템을 정의해줘야겠다.
사실, 반나절이면 끝날 줄 알았는데, 하루가 겨우 되어서야 마무리할 수 있었다.
그만큼, 디자인에 대한 일관성을 지키기가 어렵다는 것을 여실히 체감했다.
사실, 기가 빨렸다. 개발해야 하는데, 디자인이나 하고 있다니라고 생각했다.
💡 하지만, 정말 신기하게도 10일이 걸려 엎은 프로젝트를 단 6일만에 새로 정의하고, 구현했다.
사람의 직감은 이성을 흔들게 하고, 직감의 원천은 경험이다.
난 디자인을 일관성 있게 하나하나 계획하고 구현한다는 것이 엄청 중요하다는 것을 직접 느낄 수 있었다.
이제 가식 없이 말할 수 있다.
일관성 있는 UX를 위해 오늘도 고민하는 디자이너, 기획자 분들 모두 존경한다...
2. 트레이드 오프의 근거가 되는 디자인
와이어프레임이 주는 일관성의 힘은, 트레이드 오프를 고려할 때 진가가 드러난다.
사실, 완전히 모든 와이어프레임 그대로 구현하지는 않았다. 배치는 거의 비슷하나, 픽셀 단위는 좀 많이 다르다.
'와이어프레임도 못 맞춘 게 자랑이야?!'라고 말씀해주신다면 할 말 없다.
그럼에도 변명을 하자면, 단 3일 안에 모든 구현을 해야 한다면, 어느 정도 리소스에 대한 트레이드 오프를 고려해야만 했다.
- 내가 포기한 것은 '픽셀 단위까지의 같은 결과물'이고,
- 이를 대가로 얻는 것은 '3일 안에 애플리케이션을 만드는 것'이었다.
그렇다. 이번 프로젝트의 핵심은 바로 트레이드 오프를 얼마나 빠르게 조정할 수 있느냐였다.
여기까지 당차고 좋았다. 막상 맞기 전 까지는
다시 그럼에도 마주한, "막상 구현하니 별로인데...?"
안타깝게도, 내 와이어프레임은 단 하루만에 만든 거라 굉장히 부실하다.
(심지어 디자인의 '디'자도 잘 모르니, 얼마나 부실할지... 더이상 말을 잇지 못한다.)
그렇기에, 나는 와이어프레임을 구현하는 내내 구현물에 대한 실망감을 마주했다.
이는 뷰포트를 늘이고 줄였을 때 가장 잘 드러났다.
나는 개발할 때, 일부러 뷰포트를 9999 * 9999까지 조정해본다.
항상 최악의 경우에서 사용자가 볼 수 있는 것까지 생각해야 하기 때문이다.
이번에는 안타깝게도 1440 x 1024 기준에서 와이어프레임을 작성해서, 다시 반응형이나 적응형으로 작업해야 하지만... 이를 위해서라도 좀 더 다음에 작업하기 쉬운 쪽으로 접근해야 하기 때문이다.
가장 큰 문제는 캔버스를 그릴 때였다.
나는 이번에 공부해보고 싶었던 Canvas API로 애니메이션을 작업했는데, 문제는 연산이 꽤 많이 들어갔다. 따라서 9999 * 9999로 했을 때, 엄청나게 느린 단점이 존재했다.
따라서 나는 마침내 약 6시간 고민하다가, 이 애니메이션을 포기했었다.
약 2주간 걸쳐 만든 애니메이션이 날아가버린 순간이었다.
그래서 삭제하려던 찰나, 문득 생각했다.
- 나는 왜 와이어프레임을 놔두고 이상한 작업을 하려 했지?
- 잠깐, 너 지금 대안 있어? 그 대안은 현재 와이어프레임 대비 왜 타당한 거야?
'막연한 별로'라는 생각에, 똑같은 실수를 되풀이 할 뻔했다.
그럼에도 성장함을 느낄 수 있었던 건, 다시 그 실수를 되풀이 하지 않고, 현재 와이어프레임을 기반으로 대안을 찾아나갔다는 것이었다.
결국 이 디자인 내에서 너무 벗어나지 말아야 된다는 원천이 있었기에, 실수하지 않았다.
나는 고민 끝에 다음과 같은 2가지 대안을 찾게 되었다.
- 애니메이션을 포기하고, 그저 정적인 상태로 보여줄 것.
- 화면의 크기를 컨테이너 안에 감싸서 더 커지지 않게 제한해줄 것.
결과적으로 나는 후자를 선택했다. 전자를 선택하면, 굳이 내가 만든 애니메이션보다는 '이미지'로 하는 것이 훨씬 보기가 낫다고 판단해서다.
결국 와이어프레임이 있었기에 더 빠르게 결정하고 구현할 수 있게 됐다.
오히려, 일관성 있는 와이어프레임을 기반으로 해답을 찾아 나가니, 디자인이 문제가 아닌, 반응형 뷰포트를 고려하지 않은 초기 환경 설정의 문제점임을 알게 됐다.
💡 혼자서 구현하는 도중 별로라고 생각하면, 자책하며 바로 코드를 삭제하지 말자.
어쩌면 진짜 문제는, 디자인이 아닌 다른 문제일 수 있다.
3. 와이어프레임을 설계하면서, 자연스레 결과물에 대한 철학이 생긴다.
와이어프레임을 작성하는 순간을 고백하자면, 마치 일련의 스톱모션을 찍는 듯한 느낌이다.
모든 결과물들을 하나하나, 눈으로 기억하고, 사소한 배치라도 한 번 더 생각하게 된다는 것이다.
그렇게 모든 애플리케이션의 화면들의 찰나들을 눈으로 기록하다, 뭔가 거슬린다면 이를 수정하고 다시 반영한다.
그러다 보면서 느낀 건데, 일관성이라는 것은 처음부터 있던 것이 아니라 계속해서 만들어지는 것이라는 것을 느꼈다.
마치 컴포넌트를 조립해 하나의 페이지를 만드는 아토믹 디자인처럼 말이다.
아마 다수의 사람들이 공감하겠지만, 컴포넌트를 만드는 것은 무섭다. 적어도 나는 그렇다.
구현이 어려워서가 아니다. 그건 사실 진짜 문제가 아니다.
내가 진짜 무서워하는 이유는, 언제 다시 재사용될지를 예상하고 하나하나 시나리오를 계획해야 한다는 점에 있어서다.
그렇기에 나는 확신이 서지 않는 이상 컴포넌트를 먼저 잘 만들지 않는다.
일단 기존 것을 최대한 재사용하며 구현하되, 해당 코드가 반복되어 재사용될 것 같다면 쪼개는 방식을 택한다. 결국 모든 것은 구현하면서 형성되기도 한다.
와이어프레임도 비슷한 느낌이 들었다. 처음부터 "이것이 일관성!"하면서 나오는 게 아니다.
일단 그저 적절한 컨셉 하나만 딱 정해서, 이를 밀고 나가다 보면 어느 정도 내가 타협이 되지 않는 순간들이 생기는 것을 느꼈다. 그것을 우리는 원칙과 철학이라고 하고, 원칙과 철학이 모여 일관성을 만든다.
그런 철학이 생기고 나니까, 새롭게 내 뇌를 침투(?)하는 번잡한 아이디어들이 많이 사라지게 됐다.
나중에는 정말 필요한 순간에, 필요한 아이디어 만을 반영함으로써, 좀 더 빠른 개발이 가능하게 됐다.
결국, 내가 부족했던 것은 내 애플리케이션 디자인에 대한 철학과 확신이었고, 이는 와이어프레임을 통해 검증하며 생기게 되었다.
💡 내가 잘하고 있는 것인지 판단하고 싶을 때, 와이어프레임을 하나하나 만들고 살펴 보자. 흐름을 놓친다면 그곳이 문제일 확률이 높다.
🌈 마치며
사실 하나하나 모두 기획하고 만든 경험이 부족했다. 거의 1년 만인가...?
그렇지만 시행착오를 모두 겪어가며, 내 나름대로의 개발 철학을 세우는 것 같아 기분이 좋았다.
잘 만든 프로젝트 하나가, 열 프로젝트 부럽지 않다고 했다.
난 여러 개는 정을 주지 못할 것 같고, 이 프로젝트 하나 제대로 마무리 하며 다시 새로운 개발 경험을 향해 새출발하려 한다.
이 글은 그런 미래의 나를 위해, 미리 남겨놓는 글이다.
🔥 내 앱의 조잡한 디자인에 상처를 받는다면, 이 글을 다시 보자. 이상!
.jpg)