제품화 경험에 대한 후기
근 한 달 간을 프로젝트에 매달려 보냈다. 결과물은 어떨까. 생각했던만큼 양적으로 풍성한 결과가 나오진 않았다. 노트에 필기를 정리할 때를 생각해보자. 초반에는 별다른 생각이 들지 않는다. 하지만 시간이 지날 수록 현재 필기의 전체적인 형태가 눈에 들어오고 아쉬운 부분들이 보이기 시작한다. 나의 첫 프로젝트 진행도 같았다. 기능을 추가하는 시간만큼이나, 아쉬운 부분을 발견하고 수정 및 보완하는 시간의 아주 컸다. 개발자는 창조적인 직군이라고 생각했는데, 내 예상과는 좀 달랐다는 것이다. 오늘은 프로젝트 출시가 거의 마무리된 지금, 프로젝트 진행을 되돌아보며 느꼈던 것들을 정리하는 시간을 가질 것이다.
1. 책임감 있는 코드를 작성
코드를 작성해나가다 보면 '코드 이렇게 짜도 되나?' 싶은 순간에 자주 직면하게 된다. 내가 작성한 코드에서 왜인지 모를 위화감이 느껴지는 순간 말이다. 대게 비효율적인 코드를 작성했다는 것을 직감한 순간이다. 개발경험이 전무하지 않다면 이런 순간은 어느정도 직감할 수 있다. 지식의 부재는 자신이 잘 알고 있기 때문이다. 중요한 것은 이 상황에서 어떤 선택을 하느냐이다.
코드를 고치지 않아도 동작에 문제는 없지만, 성능 저하나 가독성이 떨어지는 코드를 프로젝트에 잔존시킬 수 있는 상황. 누구나 이런 상황을 직면하지만, 누구나 개선하는 방향을 선택하진 않는다. 동작에 문제는 없으니까 말이다. 그리고 필자는 '이러한 상황을 극복할 마음가짐이 어느정도 있느냐' 가 좋은 개발자로 성장하느냐-마느냐를 결정하는 큰 당락이라고 생각했다. 필자는 아직 주니어의 주니어 수준이라 이번 프로젝트 진행에 있어 이런 상황들을 많이 직면했다. 결과적으로 필자는 모든 문제를 개선으로 이어나가진 못해서 떳떳할 순 없었다. 하지만 떳떳할만큼은 아니더라도 프로젝트 덕분에 '더 나은 코드를 작성하기 위해 끙끙대는 시간'을 많이 가질 수 있었다. 그리고 이하의 느낀 점이 있다.
(1) 코드를 작성해나가는 시간보다
(2) 더 나은 코드로 수정하기 위해서 고군분투하는 시간이 더 큰 발전을 제공한다.
(3) 그리고 이러한 과정은 많은 시간과 에너지를 요한다.
(4) 하지만, 문제를 피하지 않고 돌파하는 사람(개발자)이 되고 싶다.
그리고 개발자에겐 Git이 있다. 처음엔 '코드를 잘못 건드렸다간 지금까지 한게..'라는 걱정이 들었다. 더 나은 코드를 작성하는 것을 회피했었다. 하지만 Git의 reset/revert 기능에 익숙해져가면서 이런 걱정은 무의미하다는 것을 깨달았다. 마음껏 시도해보고, 안되면 이전의 작업 상태로 되돌리면 된다. 중요한 것은 해당 코드를 개선하는 것이 얼마나 가치 있는지 판단하는 능력과 게으름을 이겨내는 것. 그뿐이다.
(5) 책임감 있는 코드
마지막으로 '책임감 있는 코드'는 경제적 손실이 발생했을 때 내가 책임지겠다 그런 의미가 아니다. 물론 책임은 져야지 충분히 개선할 수 있었을 법한 코드를 무시하고 지나치는 개발자로 성장하고 싶지 않다는 것이다. 코드에서 성능 저하나 가독성의 여지를 발견했을 때 이에 대해 최소한 고민과 개선을 시도하는 개발자가 되고 싶다. 그것이 '책임감 있는 코드를 작성하는 개발자'가 아닐까 하는 생각이 든다.
2. 불필요한 코드를 덜어내는 것
'반성 식탁'은 취업 포트폴리오에 들어갈 프로젝트다. 그렇기 때문에 현업에서 많이 사용되는 기술 스택 또는 라이브러리를 최대한 많이 적용해봐야 하나? 라는 고민을 상당히 했다. 지금은 그것에 대해 NO라고 말하고 싶다. 개발을 잘하려면 어떤 것이 중요한지에 대한 생각을 해봤기 때문이고, 내가 내린 결론은 불필요한 과정을 덜어내는 것이라고 생각한다.
코드 작성을 블로그 글 작성에 비유해보자. 무언가를 작성하는 행위임은 동일하므로, 두 결과물 모두 가독성을 판단할 수 있다. 파악하기 쉽고 읽기 쉬운 블로그 글은 '필요한 내용만 쓰여진 글'임에 모두가 동의할 것이다. 하지만 처음부터 필요한 부분들만 골라서 글을 작성해내기란 사실 상 불가능하다. 그렇기에 글 작성에서 '늘리기보다 줄이기'가 더 중요하다는 것 같다. 이러한 점에서 코드 가독성도 같다고 생각한다. 불필요한 코드는 제거하고 필요한 코드만 남기는 것.
포트폴리오 경험에 있어 다양한 라이브러리들을 경험해보는 것은 중요하다. 다양한 기능도 중요하다. 하지만 '꼭 필요한 기능들만 잘 만들어 놓는 것'과 '필요한 라이브러리만 적용하는 것'도 프로젝트와 앞으로의 개발에 있어 정말 중요하다고 생각했다. 더군다나 나는 아직 기본에 충실하기 마저도 어렵다. 프로젝트 진행에 있어 억지로 불필요한 라이브러리를 적용하는 시간보다, 필요한 것에 집중하는 시간이 더 가치가 있다고 느꼈기 때문이다. 그리고 라이브러리 사용에 있어 중요한 것은
(1) 특정 라이브러리의 사용 목적을 파악하고
(2) 해당 목적이 나의 프로젝트에 적용시켜야하는 타당성이 있는지 판단하여
(3) 나의 프로젝트에 적용시키기 위해 코드를 분석할 수 있는 능력이라고 생각한다.
(4) 그리고 이러한 능력은 다양한 라이브러리 경험을 통해 배울 수 있기 때문에
(5) 앞으로 다양한 라이브러리를 경험하고 알아가 볼 생각이다.
3. 모르는 것을 인정합시다.
코딩이라는 것을 접한지 1년이 되어 간다. 1학기 자료구조 과제 기간에도 원없이 코딩했고, 이번에 프로젝트를 진행하면서도 원없이 코딩했다. 꽤나 바쁜 1년을 보내게 되면서 개발이 다른 일들과 다른 이유를 알게 됐다. 개발은 공부를 끝없이 해야하는 일이라는 것이다. 그리고 공부하려면 모르는 것을 인정하는 것이 첫번째로 선행돼야 한다. '아 글쎄. 이대로도 괜찮아~' 하며 살아온 나에겐 해당 습관을 들이는 것이 상당히 어려웠다. 이번 '반성 식탁' 프로젝트도 그랬다.
처음에는 '반성 식탁'에 MVVM 패턴이 아닌 MVC 패턴을 적용하려고 했다. MVC 패턴을 비하하는 것이 아니다. MVC를 적용해도, 이대로도 괜찮다고 생각했다. 하지만 실상은 괜찮지 않았다. 8월에 MVC 패턴으로 진행했던 프로젝트에서 액티비티/프래그먼트의 코드가 비대해져 불편함을 겪었었지만, 그래도 괜찮다고 생각했다. 그러다가 문제를 회피하는 내 모습을 발견했고 회의감이 들었다. 이후 프로젝트에 MVVM을 적용했다. 막상 해보니 그리 어렵지도 않았다. 프로젝트 코드 관리 경험도 월등히 좋아졌고, 이후 프로젝트를 진행함에 있어서 MVVM 패턴은 큰 도움이 되었다. 모르는 것을 인정하고 프로젝트는 발전했다.
(1) 귀찮음을 이겨내고 모르는 것을 인정하는 것
(2) 모르는 것을 인정하고 배움을 시작하면서 발전하는 것
(3) 단지 코딩을 한다기보다 정신 수양을 하는 기분이 들 때도 있었다. (좋은 쪽으로)
(4) 쉽진 않겠지만, 모르는 것을 인정하는 것에 더욱 익숙해지고 싶다.
4. UX 개선
일단 이번 프로젝트에 있어 가장 큰 수확은 앱 개발의 재미를 느낀 것이다. 특히 UX 개선에서 가장 큰 흥미나 성취감을 느낄 수 있었다. UX는 사용자가 제품/서비스를 사용하면서 느낄 수 있는 종합적 만족이다. 그렇다. 앱 개발의 특정 요소에서 재미를 느꼈다기보단 전반적인 앱 사용성이 증가될 때마다 큰 성취나 희열을 느꼈다. 이에 대해선 특별한 이유를 모르겠다. 앱이 발전하는 만큼 나도 발전하고 있다고 느끼게 돼서일까. 나만의 서비스를 만들고 있다는 점에도 애착이 갔던 것 같다. 따라서 이후 취직할 회사를 선택하는 과정에서도 '내가 사용할 앱 서비스를 기획하는 회사인가' 를 크게 고려할 것 같다.
앞으로의 계획
일단 두 번째 업데이트를 준비하고 있다. 다음과 같은 기능을 추가하려 준비 중이다.
1. 카테고리 추가
반성도 여러 가지 종류의 반성이 있을 것이다.
(1) 평소에 해결하지 못 했던 '습관'이라거나
(2) 나처럼 계획적인 소비를 하지 못한 사람들을 위해 '소비' 카테고리
(3) 자신의 건강을 챙기지 못하는 사람들을 위한 반성 카테고리인 '건강'이라거나
물론 전부 내 얘기다. 아무튼 다양한 종류의 반성 경험을 공유하는 SNS 서비스인만큼, 반성 카테고리 기능 추가는 필요하다고 생각한다.
2. 앱 내 리뷰
리뷰에 피드백과 함께 동기부여 메세지를 적어주면 몇몇 메세지를 선택해 앱에 반영할 예정이다. 그러기 위해선 리뷰 과정의 귀찮음을 줄이는 것이 필요하다고 생각했다. 따라서 앱 내 리뷰 기능을 앱에 추가할 것이다.
3. 댓글 알림
'반성 식탁'은 SNS 서비스이고 서로의 반성에 피드백(댓글)을 주고받으며 성장한다. 따라서 댓글을 달면 알림이 뜨는 기능을 구현할 예정이다. 그리고 이와 함께 댓글 기능도 자연스럽게 수정할 예정이다.
4. UI 개선
좋은 UI를 설계하는 것만큼 어려운 것이 또 없다. 현재 1.0.0 버전인 프로토 타입 버전의 UI도 어느정도 개선을 했다고 하지만 아직 성에 차지 않는다. 솔직히 말하면 못 생겼다.. 최대한 더 나은 UI를 고안해 적용해 볼 생각이다. 하지만 UI는 언제나 마음에 드는 적이 없다. ㅠㅠ
