[회고] 해,커리어

해커톤을 끝낸 뒤 바로 회고하고 싶었지만, 졸업을 하려면 더는 오픽을 미룰 수 없어 이제야 해커톤 회고를 작성한다.
기왕 작성할 거 제대로 해보자 싶어, 이 기회에 티스토리 블로그도 개설했다. 막상 개설했는데 어떻게 쓰는 건지 잘 모르겠다.

Overview

• 개발자 2명 디자이너 2명
• 개발 쪽은 서버, 프론트로 나누어 담당, 디자인 쪽은 각각 '기획·UI' , '마케팅·브랜딩' 위주로 담당
• 그중에서 기획이랑 UI 디자인 위주로 담당
• 총 370팀 중 50팀 안에 선정되어 예선 진출

 

좋았던 점

좋았던 점이라고 하면 당연 팀원들과 함께 하나의 서비스를 만드는데 몰입했던 경험이다. 이전 프로젝트에서 함께 했던 팀원들에게도 실망했지만 나 스스로에게도 많이 실망하면서 줄곧 '나는 사람을 싫어해'라는 다소 중2병스로운 생각을 하고 살았는데, 졸업 전에 정말 좋은 사람들과 함께 돈 주고도 살 수 없는 소중한 경험을 할 수 있었다.

팀소개마저 즐거웠다

피그마를 이용해서 제대로 된 협업을 해본 것도 좋은 경험이었다. 기존에도 피그마로 공유를 하긴 했지만, 실시간으로 소통을 해본 적은 없었다. 처음에는 내가 작업하는 걸 실시간으로 보고 계시다는 게 부담스럽기도 했는데 중간중간 서로 파이팅하기도 하고, 궁금한 점은 그냥 바로 질문할 수 있어서 점차 장점이 크다고 느꼈다.

예전에 XD로 작업하고, PPT에서 스토리보드로 일일이 만들어서 공유했던 것에 비하면 그 수고도 덜했다. 실제로 우리팀은 발표 자료도 모두 피그마로 만들었는데, 만들 때도 카톡으로 공유할 필요 없이 바로바로 동시에 작업할 수 있어서 편했다. 물론 아래처럼 스토리보드로 만들어서 공유하는 게 더 정확했겠지만...

이번에는 정말 시간이 없었기 때문에 프레임 위에 메모 형식으로 바로바로 남기고, 필요한 경우는 아예 프레임 자체 옆에 플로우 차트처럼 흐름을 그려 표현하기도 했다. 최대한 단시간에 정보를 전달하기 위해서 선택한 방법이긴 한데, 좋은 방법인지는 모르겠다. 추후에 개발자 분께 물어볼 기회가 있으면 물어봐야겠다.

프레임 위에 메모	플로우 차트처럼(?) 구성

 

 

 

배운 점

항상 해결해야 하는 문제를 먼저 생각하자
해커톤이나 팀 프로젝트를 하면서 항상 마주하는 문제는 아이디어를 먼저 생각하는 것이다.

'이런 게 있으면 좋을 것 같아!' 하고, 아이디어에 문제를 끼워 맞추는 식이다.

SK LOOKIE활동에서 사회 문제를 정의하고 그에 대한 솔루션을 도출해보면서 그리고 그런 방법에 대한 교육을 들으면서 문제정의의 중요성을 알 수 있었다. 모든 서비스는 문제에서 시작해야 한다. 물론 솔루션이 먼저 떠오를 순 있지만, 이는 단지 가설일 뿐 솔루션이 정말 이 문제를 해결할 수 있는지, 정말 이 문제를 해결할 수 있는지 계속 의심하며 증명하는 과정을 거쳐야 한다.

이렇게 말해 놓고, 나도 아이디어를 먼저 떠올리는 실수를 범했고 프로젝트 진행하면서 '그래서 우리는 무슨 문제를 해결하고자 하는 거지?'라는 의문을 내내 가지고 있었다. 처음으로 어떤 앱 서비스를 만들지 다 같이 이야기하는 과정에서 자칫하면 딴 길로 새기가 참 쉬운 것 같다. 물론 이를 보완하기 위해서 내내 노력하기도 했다.

다음에도 또 프로젝트를 할 기회가 있다면, 아래의 글처럼 아이디어 제안자를 모집하고 제안자는 '시장 조사(경쟁 서비스), 페인 포인트, 핵심 기능'을 바탕으로 한 자신의 아이디어를 팀원들에게 공유하고 설득하는 방법을 도입하면 좋을 것 같다.
https://brunch.co.kr/@vicotorlee/159

팀 사이드 프로젝트 할 때 알면 좋은 것들

 

바로바로 질문하자

또한 이전 프로젝트에서 스스로에게 실망했던 부분을 최대한 극복하려고 노력했다. 기존에는 회의할 때, 하고 싶은 말이 있어도 바로 하지 않고 문제점과 그에 따른 해결책을 PPT나 프로토타입으로 정리한 다음에야 공유를 하는 습관이 있었다. 그러다 보니 빠르게 진행해야 하는 프로젝트 특성 상 이미 개발에 들어간 뒤, 뒤늦게 문제점을 제시하는 일이 많았다. 그러다보니 반영도 잘 되지 않고, 비효율적이었다. 그래서 이번에는 의문이 생기면 최대한 회의할 때 궁금한 점, 추후에 문제가 될 것 같은 점은 바로바로 질문하려고 했다. 결론적으로는 훨씬 더 효율적이었고, 문제에 대해 이야기를 나누는 과정에서 머릿속에 어느 정도 같은 생각을 공유할 수 있었던 것 같다. 문제는 다 같이 해결하는 것임을 배웠다.

 

 

후회가 남지 않도록 최선을 다하자

기존 프로젝트들에서는 나쁜 마음일 수도 있지만 조금은 계산적으로 행동했던 것 같다. 이게 도움이 될까? 포트폴리오에 넣을 수 있을까? 횟수는 몇 번 되지 않지만, 그런 마음으로 참가했던 프로젝트들은 끝나고 나서 너무 후회스러웠다. 그래서 이번에는 정말 아무런 계산 없이 누군가와 무언가를 즐겁게 만드는 것에 집중했던 것 같다. 물론 팀원들이 보기에는 그렇지 않았을 수도 있지만, 내적으로는 최대한 이렇게 하려고 노력했다.

 

 

 

디바이스 대응에 대해서도 생각하는 계기, 무조건 구체적으로 공유하자

사실 그동안은 거의 대부분 360 x 640으로 디자인을 진행하고 개발 쪽으로 넘겨줬었는데, 개발자 분께서 디바이스 크기가 달라질 때 어떻게 되는지 알려달라고 하셔서 처음으로 가변 영역과 아닌 영역에 대해서 공유하는 기회를 가질 수 있었다. 

 

작업을 하면서 항상 내 머릿속으로는 어디가 가변 영역이고 늘어나면 어떻게 되면 좋을 것 같다는 생각을 가지고 있었지만 한 번도 공유해본 적은 없었는데, '알아서 해주시겠지'라는 생각을 가지고 있었던 것 같다. 하지만 이번 기회를 통해서 내가 구체적으로 공유하지 않는 이상 개발자분은 알기 어렵고, 그게 개발자분들이 개발을 하는 걸 더 비효율적으로 만든다는 것을 알게 되었다 ㅠㅠ

 

문득 오래전에 인상 깊게 읽었던 글이 생각났고, 이 글을 참고해서 아주 간단하게라도 가변 영역 등등에 대해서 공유할 수 있었다. 

https://brunch.co.kr/@dalgudot/101

04화 [실무편] 회원가입을 쉽게 만드는 UI/UX 디자인은?

 

이 경험을 통해서 내가 실무에 필요한 것들은 생각보다 더 많이 놓치고 있었다는 생각이 들었고, UI에 대해서도 더 공부해야겠다고 생각했다.

가변영역과 비가변영역(?) 공유

 

 

아쉬웠던 점

스스로 뾰족하지 못했던 점

아쉬운 점은 사실 너무 많지만, 글을 쓰다가 지쳐서 하나만 쓰려고 한다. 스스로 끝까지 뾰족하게 문제를 정의하고 디자인하고 발표자료를 만들었는가?라고 물으면, 정말 많은 부분에서 아쉬움이 많이 남는다.

 

앞으로 개선할 방향

 

디자인 시스템 만들기
빠르게 개발해야 하는 해커톤의 특성상 UI를 새로 만들 시간조차 없었다. 특히 우리 팀은 팀빌딩이나 아이디어 회의를 한다고 1주~2주를 거의 썼기 때문에 디자인할 시간이 촉박했다. 그때, 기존에 이전 해커톤 때 만들어 놓았던 디자인 시스템을 요긴하게 쓸 수 있었다. Google Material Guide 2.0과 밀리의 서재 디자인 시스템을 참고해서 만들어놨었고, 물론 아주아주 부족하지만 작업을 빠르게 하는데 많은 도움이 됐다. 다만 와이어 프레임을 그리는 단계부터 피그마에 미리 등록해놓고, 작업했으면 더 효율적이었을 것이라 생각한다. 아이콘 같은 경우도 이때까지 프로젝트하면서 썼던 아이콘을 바탕으로 필요한 것들만 새로 더 작업해서 시간을 줄일 수 있었다.

사실 이거 두 개가 다였다... 그래도 도움이 됐다

 

조금 뒤늦게 작업했던 컴포넌트 정리

실제 실무에서는 어떨지 모르겠으나, 개발을 빨리 시작해야 하는 단기간의 프로젝트에서는 개발자분들이 '와이어프레임' 상태에서 개발하는 경우가 많이 있었다. 추후에 정확한 컴포넌트나 아이콘들을 전달했을 때, 우선순위에 밀려 반영이 되지 못하는 경우도 있었다.
개발자분들은 이미 와이어프레임 보고 만들고 있었는데, 계속 수정을 요청하는 것도 죄송한 일이었다...

개인적인 의견으로는 물론 와이어프레임 이후에 다시 제대로 디자인을 거쳐 최종본을 전달하는 게 가장 좋겠지만, 단기간에 개발을 하려면 어쩔 수 없는 부분인가 싶기도 하다. 그래서 단기간 프로젝트를 위한 기본적인 디자인 시스템이나 컴포넌트 (검색창, 버튼 등등) 은 미리 가지고 있어야겠다고 생각했고, 검색이나 설정 등 일반적인 기능들을 서비스마다 분석해서 공부해볼까 한다.


그리고 오늘 마침 아토믹 디자인이라는 개념을 접하게 되었다. 느리더라도 계속 공부하고 차근차근 만들어보겠다.
https://bradfrost.com/blog/post/atomic-web-design/

Atomic Design