상반기 회고

본 문서는 21년 3월 말부터 9월초까지 했던 1.7 버전 개발에 대한 회고입니다.

서론

올해 3월 말, 앱의 사용성과 리텐션 개선 그리고 향후 방향성에 대해 회의를 가졌습니다.

당시 Dreamfora 앱은, 사용자의 데이터를 20초마다 서버에 업데이트 하는 방식으로 되어있었고, local database 와의 연동이 안되어 앱을 중간에 종료하면 작성하던 데이터가 증발하는 버그가 있었습니다.

그리고 생산성 도구 앱 치고는 뎁스가 꽤 깊고, 홈 화면의 비중이 높아서 (모든 기능이 홈을 거쳐가야 했음), 디자인의 변화도 필요한 상황이었습니다.

우리 팀은, 크게 두 가지의 개선안을 내놓았고 방향성을 잡았습니다.

1. 데이터가 날아가는 일은 반드시 없어야한다. 기존의 서버 중심의 앱에서, 로컬DB 기반의 앱으로 가되, 백업/복원 기능을 추가한다.
2. 앱의 페이지 뎁스를 줄이고 쉬운 사용성을 주기 위해, Bottom Navigation Bar (하단 탭) 기반의 디자인으로 변경한다.

그렇게 대대적인 개편을 시작하였습니다.

본론

기존 앱과는 전혀 다른 앱을 만들어야했기에 아에 빈 레포지토리와 새로운 Xamarin 프로젝트를 생성하여 작업하기 시작했습니다. 당시 GitHub에 대한 지식은 거의 없다고 해도 무방할 정도로 무지했습니다. branch는 작업자 별로 나눠서 작업하는 줄, issue는 조직이 클 때만 필요한 줄 알았습니다. 그러나 앱 개선이 시급했고 개발을 빨리 해야하는 상황이라 다 치우고 일단 개발을 시작했습니다.

당시 저는 입사한지 3달밖에 안된 상황이라 아직 모르는 것이 많았습니다. 그래서, 집에서 Xamarin 문서를 찾아보며 만들어보고, 오픈소스를 찾아보며 적용해보고.. 손에 익숙해지면 회사에서는 공부했던 것을 적용해서 코드를 작성했습니다. 디자인 작업을 먼저 시작했었는데, 하나 하나가 전부 챌린지였습니다. Sticky view, Bottom sheet, Infinity scroll, Circular progressbar, ... 오픈 소스 많이 찾아봤긴한데, 역시 자마린! 없습니다...거의 직접 만들었습니다. (rg.plugins.popup은 정말 좋더군요 팝업은 이걸로 해결했습니다.)

그 때 중간에 스크럼이라는 것이 생겼습니다. 매일 오후 1시 30분에 팀원이 모여서 30분에서 1시간 정도 지금까지 한 일, 할 일을 말하고, 협의할 사항을 논의했습니다. 그 때 의논한 것들을 바탕으로 디자인을 하고, 저는 그 파일을 전달받아서 개발하는 방식이었죠. 지금보면 그 때 나왔던 내용들이 앱에 적용된 것들이 많습니다. 거의 새로운 앱을 만드는 것이었기에 논의할 것도 많고 협업할 사항도 많았는데, 스크럼 덕분에 속도감 있게 진행할 수 있었습니다. 서로가 무엇을 하는지 말을 하면서 대략 알 수 있어서, 소통의 부재로 인한 답답한 점도 해소하고 오해를 차단할 수 있는 장점도 있었습니다.

팀원들 한 분 한 분 함께 작업한다는 느낌을 자주 받았습니다. 특히 먼저 자원해서 QC를 매번 해주신 덕분에 에러도 즉각 잡으면서 빠르게 개발했습니다. 그래서인지 초반에 계획했던 MVP 보다 더 나은 모습으로 짧은 시간 안에 완성할 수 있었던 것 같습니다. 8월 쯤 로컬 데이터베이스 작업할 때, 제 사수이신 Chase와 함께 했던 짝코딩도 잊지 못할 좋은 경험이었습니다.

---

그러나, 빠르게 개발하는 것은 좋았지만 돌아보면 아쉬운 것들이 있습니다.

첫 째, 이슈 트래킹.

누가, 어떤 제안을 하였고, 어떻게 어디까지 개선을 했으며, 나중에 그 내용을 변경하려고 할 때 왜 변경하는지, 무엇이 더 나아지고 그로 인해 어떤 문제가 생길 수 있는지 등의 사항들이 로깅이 되지 않았습니다. 말로 주고 받은 것들이 두뇌 데이터베이스에 저장되었죠. 혹은 산발되어 여기저기 슬랙, 엑셀 등에 저장되었습니다. 한 곳에 정리가 되지 않다 보니 휘발된 소중한 의견들이 많았고, 잊어버려서 같은 내용으로 회의를 하는 등의 허비하는 시간도 있었습니다. 어떤 이슈에 대해서 서로 생각하는 것이 다르고 오해가 생길 수 있었습니다.

또, 버그와 개선 사항 등의 의견들이 구두로 전달되는 일이 많았습니다. 저는 그런 내용들을 자체적으로 우선순위 논의 없이 듣자마자 개발할 때도 있었고 (특히 버그), 제 개인 업무 todo에 없는 내용 중엔 실수로 까먹어서 처리하지 못하고 나중에 발견되는 일도 있었습니다. 이럴 땐 너무 죄송하더라구요.

그리고 기획이나 디자인이 변경되었을 때 그 이유에 대해 직접 물어봐야 하는 일이 생겼고, 건별로 트래킹이 되지 않다보니 특정 건의 기획이 변경되었을 때 직접 전달 받지 않으면 인지하지 못할 때도 꽤 있었습니다. 추가로, 중복적인 회의와 코드 작성으로 인해 가끔 정신적, 육체적 스트레스가 쌓였습니다.

둘 째, 일정 관리.

큰 그림이 정확하게 그려지지 않은 채 페이지별, 기능별로 살을 붙이다보니, 어디까지 해야할 지, 어느 순간에 끊고 얼마나 걸리는 지가 감이 잡히지 않았습니다. 물론 개발 일정을 산정하고 정확히 맞추는 일은 매우 어렵다고 들었습니다.

(사진, '최고의 엔지니어를 쫓아내는 방법') [GN#115] 최고의 엔지니어를 쫓아내는 방법 | GeekNews

그러나 지금 처리하고 있는 이슈가 끝날 때까지 다른 건이 기다리는 상황이 종종 있었고, 지금 개발하는 것들이 일정이 늘어지면 초조해지고 마음이 급해졌습니다. 다른 팀원들에게 개발팀에 대한 신뢰를 떨어트렸을 수도 있었을 것 같습니다. 그리고 이런 것들보다 더 치명적인 것은, 코드 퀄리티가 떨어진다는 느낌을 받았습니다. 물론 고민 할 수 있는 시간 한도 내에선 최선을 다해 코드를 작성하였지만, 좀 더 고민했으면 더 깔끔하고 좋은 코드가 나왔을 것 같습니다.

만약 전체적인 개발 일정과 그 난이도, 현재 진행사항 그리고 앞으로 계획된 일정 등이 체계적으로 잘 정리되어 있고 실시간으로 팀원들에게 공유되었다면, 저는 좀 더 편안한 마음으로 프로그래밍할 수 있고, 다른 분들께서도 자유롭게 의견을 제시할 수 있으며, 개발 일정에 대해 신뢰를 드릴 수 있었을 것 같습니다.

그래도, 열정적이고 멋진 팀원들 덕분에 다행히 일정 차질 없이 프로덕트가 나왔습니다.

셋 째, 형상 관리

당시 제게 Git은 백업용이었습니다(...) 브랜치명은 dev-nathan-xxx 였습니다.

지금 생각해보면 노답이였던, 당시 제가 진행했던 개발 프로세스 예시입니다.

1. 세팅 페이지 UI 작업을 한다.
2. amplitude 코드를 삽입한다.
3. 갑자기 어디선가 들려오는 '어?' 소리... 빠르게 버그를 해결한다.
4. 이 쯤 커밋으로 백업(...)한다. 대충 작업별로 분리해서.
5. 같은 브랜치에서 투데이 페이지 UI 작업을 한다.

... 반복..

답답했습니다. 중간에 조지면 손가락이 바빠졌습니다. 방금 짠 코드를 주석처리하고, 이전에 잘 돌아가던 코드를 찾아서 복붙해서 다른 코드랑 잘 돌아가나 빌드해보고... 뭔가 단단히 잘못된다는 생각을 갖고 코딩을 했었죠. 그래도 시간이 아까우니 그냥 그대로 했습니다. 차라리 좀 돌아서 가더라도 , 먼저 Git을 확실히 배우고 할 걸 하는 아쉬움이 있습니다. (이후에 작성하겠지만 다행히 지금은 좀 나아졌습니다.)

결론

그렇게 빠르게 5달이 지났고, 그럴싸한, 만족할만한 앱이 나오게 되었습니다. 리텐션도 조금씩 개선되는 것이 보이고, 리뷰도 변화하였습니다. 9월, 다 마치고 앱 심사를 누른 순간 긴장이 확 풀리던 그 느낌을 잊을 수 없습니다.

1.7 업데이트 이후, 새로운 기능 추가와 버그 수정을 계속해서 진행하고 있습니다. 중간중간 들었던 세부적인 개발 고민들은 언젠가 따로 서술하려고 합니다.

프레임워크 얘기는 빠질 수 없는데, 개발하면서 Xamarin에 대한 신뢰를 많이 잃었습니다. 정말 상식적으로 되어야만 하는 것이 안될 때가 많았습니다 (예: Label에 CharacterSpacing이 들어가면 이모지 안나옴). 디자인적으로 타협을 봐야하는 상황을 많이 만났었고, Native면 간단하게 쓸 수 있는 기능(예: Drag&Drop sorting)도 직접 구현하느라 공수를 많이 소모했습니다. 이제 곧 Xamarin이 아닌 다른 플랫폼으로 포팅을 할 예정인데, 같은 Cross Platform인 Flutter나 RN도 솔직히 걱정이 많이 됩니다. 결국 우리만의 복잡한 UI를 구현하기 위해선 Native단까지 가서 Android, iOS 둘 다 작업해야하는 일이 생길 것 같습니다. 하지만 또 Native를 선택하자니 Android와 iOS 각자 개발해야한다는 고민이 있지요. 이 부분에 대해서는 좀 더 공부하고 개발팀이 함께 고민하여 회사의 상황에 맞게 선택해야 할 것 같네요.

이번에 또 들었던 느낌이 있습니다. 프론트엔드 부분을 거의 혼자 했다고 해도 무방할 정도인데, 개발을 하면서 상당한 책임감과 부담감이 있었습니다. 하지만 개인적으론 이런 느낌이 되게 재밌고 기분 좋았습니다. UI와 기능을 하나 하나 만들 때마다, '어떻게 하면 사용자가 좀 더 편하게, 좋게 사용할 수 있을까?' 하는 고민을 많이 했습니다. 회사에 대한, 어떤 업무적인 책임감이 아니라, 순전히 고객을 만족시키기 위한 책임감이어서 좋았습니다. 나중에 이 앱을 런칭하면 내가 만든 것들을 사용자가 보고, 클릭 할 생각에 설렜습니다.

하면서 제게 부족한 점이 정말 많다는 것도 깨달았습니다. Git이며 디자인패턴이며 배우고 싶은 것들이 많이 보였습니다. 그래도 저보다 경험이 훨씬 많고 똑똑하신 David와 Chase 덕분에 여러가지를 배울 수 있었습니다. 나중에 합류하신 Pyro 께도 많이 배우고 있습니다. 제 부족함을 느끼면서, 항상 배움의 자세를 가지고 겸손해야겠다는 생각을 했습니다.

아무튼 생각했던 게 진짜 진짜 많았는데 막상 글로 쓰려고 하니 쉽지 않네요 ㅎ 짧다면 짧고, 길다면 긴 시간동안 치열하게 고민했었고 열심히 개발했습니다. 주변의 훌륭한 동료들과 함께 할 수 있어서 든든하고 즐거웠습니다. 지금까지 한 것보다 앞으로 할 것들이 훨씬 많기에, 여기서 만족하지 않고 더욱 정진하려고 합니다. 

---

GitHub 도입과 활용법, 장점

지표 개선과 주변의 칭찬들로 보상 받는 기분이 들었지만, 위에서 서술한 아쉬웠던 점들을 반드시 해결해야만 했습니다. 어떻게 하면 효율적인 협업 환경과 개발 문화를 잘 구축할 수 있을 지 고민하는 중에, 9월 첫 주 Pyro가 합류하였습니다. 덕분에 Git을 제대로 배울 수 있었고, 우리 팀에도 도입할 수 있었습니다. 지금은 시도해보고 익숙해지는 단계이지만 잘 정착시켜서 좋은 문화를 만들고 싶습니다.

현재 드림포라 개발팀과 기획팀이 사용하고 있는 GitHub 활용법에 대해서는 다음 포스트에서 말씀드리겠습니다. 추가로 Git을 제대로 배우면서 개발 습관도 개선이 되는 것을 느꼈는데, 이 내용도 함께 작성하도록 하겠습니다.