2021년 회고

2021년에 아쉬움이 없을 정도로 많은 걸 하지는 않았다. 그래도 2021년 초와 오늘을 비교해 보면 할 수 있는 것의 차이가 많은 것 같다. 어쩌면 실제로 한 것은 많지 않더라도 학습 임계점 중 하나를 넘었을 지도 모른다. 그 때는 어떤 팀이든 협업 프로젝트를 해보고 싶다는 생각이었다. 지금은 잘하는 팀원들을 만나고 싶은 욕구가 있다. 협업 프로젝트는 1년 전이 처음이었다.(사실 처음은 아니지만) 그리고 지금은 돈 받고 프로젝트를 할 수 있을 정도라 생각한다. 실제로 돈 받고 개발하기도 했고...

2021년의 가장 주된 활동은 4~11월 SW마에스트로이다. 그 외에는 1~3월 프로젝트, 7~8월 프로젝트, 8월? UCPC 예선과 본선 그리고 3주 정도의 외주 개발 프로젝트 정도가 있을 것 같다. 추가로 2022년과 이어지는 프로젝트를 시작했다. UCPC 는 사실 내가 무언가를 한 건 아니고 운 좋게 잘하는 분과 같은 팀을 하게 되어 본선까지 가게 되었다. 나는 Android, React, Flutter 개발자 입장에서 기획과 개발에 참여했었고 합치면 약 7~8 명의 디자이너와 협업을 했다. 협업했던 서버는 Node.js, Spring, Django 가 있었고 루비 개발자도 만난 적이 있으나 루비 서버와 협업하지는 않았다.

6월부터는 나름 1일 1커밋을 지키려고 했는데 막상 해 보니 쉽지는 않은 것 같다. 그래도 2020년까지의 커밋 수를 합친 것보다 2021년 커밋수가 더 많다. 그 전에는 개발을 거의 안 하긴 했지만... 2022 년에는 2000 개 이상의 커밋을 남기고 싶다. (물론 커밋 수가 중요한 것은 아니다. 1일 1커밋을 하는 것은 잔디를 채우기위한 목적보다 매일 1커밋 분량이라도 공부하고 있다는 것이 중요하다.)

1년 전에는 공부했던 Android 만 하더라도 제대로 개발할 수 있을 것이라는 확신을 갖지 못 했다. 그러나 지금은 내가 처음 사용하는 프레임워크와 언어를 사용한다 하더라도 1년 전보다 쉽게 개발할 수 있을 것 같다. 1년간 Android, React, Flutter 프로젝트를 경험해 봤고, Node.js 와 Spring 도 프로젝트 경험은 없지만 꾸준히 공부하고 있다. 처음이라도 개발이 쉬워진 이유는 두 가지가 있다. 첫 째는 HTTP 와 서버에 대한 이해도가 높아졌다. 1년 전에는 서버와 어떻게 통신하는지도 제대로 알지 못 했다. 이미지와 JSON 을 동시에 전송하는 것을 성공시키는데 총 10시간이 걸렸다. 그 이후 Flutter 에서 프로필 사진을 변경하는 로직을 구현하는 것은 Flutter 에 대한 이해도가 부족했음에도 UI 작업 및 다른 이벤트 구현을 포함하여 4시간도 안 걸렸던 것 같다. 둘 째로는 다른 언어나 프레임워크에서 사용했던 방법이나 개념을 어렵지 않게 새 프로젝트에 적용할 수 있다. Dart 에서 async await 와 Future 객체를 이용한 비동기 처리는 JS 에서 사용하던 async await 와 Promise 객체와 비슷하다. Android 에서 DI 를 공부할 때 Dagger 와 Hilt 라는 DI 프레임워크는 애노테이션과 리플렉션을 이용하여 IoC 를 제공한다. 이것 또한 Spring 이 DI 를 제공하는 방법과 비슷하다. 그래서 새로운 것을 개발하게 되더라도 얕게나마 넓은 지식을 갖고 있기 때문에 적응하는데 오랜 시간이 걸리지는 않을 것이다. 물론 그 언어스럽게 사용하는 것, 능숙하게 사용하는 것은 훨씬 오래 걸리는 일이다. 코틀린의 DSL 을 다루는 것은 다른 언어를 사용하던 사람은 쉽지 않은 일이다.

 

TL; DR

TL; DL 은 한 번 써보고 싶었다. 아래 내용은 두서 없이 쓰다보니 회고와는 무관한 내용까지 너무 주저리 주저리 써 버렸다.

 

기획

나는 기획, 디자인, 개발 중에서 따지자면 기획이 제일 힘들었다. SW마에스트로는 기획만 한 달 정도 걸렸다. 어떤 프로젝트를 들어가도 "내가 사용자라면 이걸 사용할까?"라고 생각해 보면 보통 아니라는 생각이 들었다. 지금도 기획은 잘 못 할 것 같다. 안 되는 기획은 이유를 찾아낼 수 있을 것 같다. 리서칭도 이젠 어느 정도 할 수 있다. 그러나 그것을 되는 기획으로 바꾸라고 하면 아직 많이 부족하다는 생각이 든다.
프로젝트 전체 기간으로 보면 기획에 들어가는 시간이 그렇게 크지는 않지만 기획이 꼼꼼할수록 그 다음 단계가 빠르고 부드럽게 진행된다는 것을 안다. 잘하는 기획자가 있으면 배우고 싶은 마음도 있지만 기획 단계에서 욕 먹었던 거 생각하면 아직도 조금 어지럽다.

 

디자인

최근에 시작한 프로젝트에서는 내가 디자인을 맡게 되었다. 그동안 프로젝트 경험도 있고 디자인 공부도 조금씩 해 보면서 나도 디자인을 할 수 있겠다는 생각이 들었다. 이 프로젝트에서 맡은 것은 시각 디자인이지만, 디자인의 사전적 의미를 찾아보면 디자인은 설계라는 뜻이다. 컴퓨터 분야에서도 디자인이라는 단어가 많이 나오고 디자인과 개발의 공통점도 많다고 생각한다. 그리고 내가 조금 변태같아서 항상 "그거 그렇게 하는 거 아닌데..." 라는 말을 하고 싶다. 깔 때 까더라도 해보고 까자는 주의여서 이번 기회에 디자인을 경험해볼 생각이다. 디자인을 시작한 지 3일차이지만 이미 상용화된 앱 캡쳐본만 50 장이 넘는다. 버튼을 디자인한다고 치면 비슷한 상황에서 사용할 수 있는 버튼은 10개 이상 찾아서 가장 적절한 버튼을 끼워 넣는 식으로 디자인하고 있고, 나는 미적 감각이 좋은 게 아니기 때문에 내가 임의로 사이즈를 정하면 이상한 모양이 나온다. 그래서 다른 상용 앱들 디자인에서 사이즈를 측정하고 내 디자인에 적절히 녹여낸다.

대충 정리한 거라 부끄럽지만 대략 이런 식이다. 디자인 유튜브로 심심할 때마다 보고 있다. 그 유튜브에서는 모바일 디자인에서 정말 작은 폰트에서도 12 폰트를 사용한다고 했는데, 실제로 사이즈를 확인해 보니 12폰트보다 작은 폰트를 아직까지 못 봤다. 디자인할 때 크기를 항상 100%로 놓고 디자인하는 것은 아니기 때문에 내 감각에 의존하기보다는 데이터를 기반으로 디자인하는 편이다. 꼭 미적 감각 뿐만 아니라 취약 계층에 대한 접근성이나 UX 측면에서도 많이 고려해야 한다.
 "(사용자를) 생각하게 하지 마!" 라는 책은 얇아서 이미 다 읽었고 UX 강의도 하나 듣고 있다. 머리티얼 디자인 스타일 가이드도 읽어볼 생각이다.

컬러랑 글자 사이즈, 폰트, letter spacing 등을 미리 정해놓고 그 안에서만 사용하고 있다. 물론 다른 컴포넌트들도 정리하고 있다. 이렇게 해야 디자인할 때도 편하고 개발할 때도 편하다. 폰트는 사실 크게 고민하지 않고, 영어는 Roboto, 한글은 Noto Sans KR 을 사용했다. 프로젝트 경험을 몇 번 해본 이후에는 디자이너분들께 스타일 가이드를 미리 정리하면 서로가 편하다고 꾸준히 말씀드리고 있다. (반영된 적은 없지만...)

 

개발

1년 전에는 개발에 걸음마를 떼는 수준이었다. 간단한 문제로 몇 시간씩 고민하기도 했다. 물론 지금도 그렇다. 하나의 화면을 만드는 것도 오래 걸렸고 어떻게 만들어야하는지 모르는 경우도 있었다. 사실 알고보면 대부분의 화면의 본질은 네모에서 시작하고 네모에서 끝나는 것인데... 첫 프로젝트는 어떻게든 동작하게 만드는 것에 초점을 두었던 것 같다.

몇 번의 프로젝트를 해 보고 무지성 코딩에 한계를 느꼈다. 의도한 것은 아니지만 Android, React, Flutter 프로젝트 경험이 있다. 2개월 정도 되는 프로젝트들에는 마크업을 포함하여 1만줄 정도 작성하고, 6개월 프로젝트에는 마크업을 포함하여 2만줄 정도 작성했던 것 같다. 모듈화를 잘하면 80줄 이내로 정리할 수 있다고 하는데, 막상 코딩하다가 정신차려보면 300줄을 넘는 경우가 많았다. 특히 어떤 화면에는 정말 많은 기능이 들어가서 한 화면에 거의 10개의 파일(영상 플레이어, css, 녹음기능, 스크립트 렌더링, 드래그 이벤트 등...)로 쪼갰음에도 어떤 파일은 거의 300라인 정도 되었다. 결국 그 화면은 감당하기 힘들 정도로 복잡해졌고 그 이후로는 설계에 더 신중하게 되었다. 물론 개발 뿐만 아니라 기획을 변경하여 해결하는 방법도 그것이 타당하다면 항상 염두에 두어야 한다.

지금은 다시 Android 를 공부하고 있다. 이제는 "어떻게?"보다는 "왜?"라는 질문을 중심으로 개발하기 위해 노력하고 있다. 같은 문제에 대해서 여러 가지 방법을 두고 어떤 방법을 왜 선택할지 고민할 것이다. 예를 들어 Retrofit 을 이용하는 방법에는 Call 객체를 반환하여 큐에 넣는 방법도 있지만, RxJava 를 이용할 수도 있고 Coroutine 을 이용할 수도 있다. 항상 옳은 방법을 선택하려고 하는 것이 아니다. 정답이 아니더라도 내 선택에 고민이 있었고 납득할 만한 이유가 있었음을 보이고 싶다.