React Native - TODO 개인 프로젝트 후기

준비

2017년 2월에 본격적으로 웹 개발 공부를 시작하고, 2017년 8월 부터 개발자가 되었습니다. 회사 업무를 하다보니 1년이 지나고 어느새 2년차 주니어 프론트엔드 개발자라는 타이틀을 얻게 되었습니다. 사실 연차는 시간이 지나면서 자동으로 늘어가는 것이지만, 제가 그에 걸맞는 능력을 가지고 있는지가 큰 부담으로 다가 왔습니다. 핑계일지도 모르지만, 회사에서 퇴근하면 여태 일하고 왔다는 변명과 함께 아무것도 안하고 잠에 들기 일쑤였으니까요. 이대로 5년, 10년이 지나면 어떤 모습일까 라고 생각해보면 뭐... 썩 좋은 모습은 아니겠죠?

뭐라도 해야된다는 압박감만 있었던 건 아닙니다. 새로운 기술이 출시될 때마다, 개발자 특유의 호기심은 늘 있었고, 관련 포스팅이나 공식 문서를 많이 읽었으니까요. 회사에서 늘 하던 것 말고 나의 방식으로 프로젝트를 도전해보고 싶다! 라는 생각도 많았습니다.

 

이런 저런 이유와 함께 막막함 반, 새로운 기술에 대한 흥미 반으로 다시 개인프로젝트를 시작했습니다. 프로그래밍 공부를 처음 시작했을때도 토이 프로젝트를 많이 진행 했지만, 제대로 끝난건 손에 꼽을 정도였습니다. 그래서 이번 프로젝트는 '획기적인 아이디어를 구현하고 싶다!' 가 아니라, '내가 사용해보고 싶은 기술을 써보자!'가 목표가 되었습니다. 그리하여 리액트 네이티브를 사용하여 간단한 TODO 어플리케이션을 만들어 보게 되었습니다.

시작

원래는 기획없이 머릿속에 생각나는 대로 개발하고 수정하는 방식을 선택했는데, 초기에 잘 진행되다가 엎어진 프로젝트가 많던 관계로, 시작하기 전에 주요 기능과 페이지를 적었습니다. 쓰고 싶었던 기술 스택과 유저 플로우, 목적 등 어느정도 적어 놓으니까 생각이 정리되는것 같았습니다. 그래도 평소 습관 때문에, 기획이고 뭐고 빨리 개발하고 싶은 마음에 빨리 정리하고 개발하러 가긴 했지만요.

뒤쪽에서 언급할테지만, 이 때 기획을 대충 해놓은게 나중에 큰 독으로 돌아왔습니다. 예전보다는 많이 나아졌지만, 기획에 없던 애매한 부분때문에 시간을 많이 잡아먹었거든요.

결과

  

로그인/회원가입

      

TODO/Timeline

좋았던 점

1. 새로운 기술들의 사용

처음 시작할때 부터 이것은 꼭 써봐야지 했던 기술들을 나열했습니다. react-native는 물론이고 node에서 ORM, redux, present-container 패턴 등을 써보면서, 기존 기술이 가지고 있던 문제점을 어떻게 극복 할 수 있었는지 생각해보게 되었습니다. 새로운 기술에 대한 갈증이 채워졌던건 덤이구요.

2. TDD 사용

개인적으로 TDD에 관심이 많았습니다. 그러다가 인프런에서 김정환님의 TDD 강의를 보게 된 후에 이번 프로젝트에서는 꼭 TDD를 사용해야겠다! 라는 생각이 들었습니다. 물론 프로젝트를 진행하면서 TDD를 완벽하게 사용한것은 아닙니다. 정확하게 따지고 보면 테스트 모듈을 사용한 것이니까요. 그래도 이번 경험을 통해 테스트를 통해 예측할 수 없는 에러를 방지하고,신뢰성을 높일 수 있다는 것은 깊이 공감할 수 있었습니다.

3. 구글링의 기술 강화

뜬금 없는 포인트에서 좋았던 점입니다. 회사에서 작업할때는 문제가 되는 사항은 다 비슷비슷해서 이제는 왠만하면 무엇이 문제인지 잘 알거든요. 그런데 개인 프로젝트에서는 아무래도 처음 사용해보는 것들이 많은지라, 검색을 엄청나게 많이 했습니다. 그러다 보니 자연스럽게 구글링 기술이 조금 더 좋아 진것같아요. 역시 개발자는 구글을 잘 써야한다는 걸 다시 한번 느끼게 되었습니다.

4. Node로 API 서버구축

평소에도 서버쪽은 잘 건드릴 일이 없었습니다. 이번에 API 서버를 node로 구축하면서 둘의 관계에 대해 많이 고민했던것 같아요. 결론은 서버가 클라이언트에 맞추거나 클라이언트가 서버에 맞추는게 아닌, 기획에 맞춰야하는 거라고 생각합니다. 기획을 대충대충한 저로써는 후반부에서 이 사실을 뼈저리게 다가왔습니다.

아쉬웠던 점

1. 부실한 기획

계속 이야기가 나오지만, 처음에 준비를 제대로 안하니 뒷부분에서 수습이 어려웠습니다. 물론 모든 부분을 고려해서 기획하기는 어렵겠지만, 정의되지 않은 부분이 나오니 API 작성도 애매해졌고, 그만큼 시간을 잡아 먹게 되었습니다. 만약 다음에 다른 프로젝트를 진행한다고 했을 때, 구색을 갖춘 Design Doc을 만들고 시작해야겠습니다. 

2. 디자인

디자이너가 아니지만, 그래도 예쁜게 최고 아니겠습니까. 그런 생각으로 후반부에는 주객이 전도된 채로 디자인에 주구장창 매달렸습니다. 그러다보니 스타일 사이즈는 점점 커졌고, 변경되는 부분이 많아져 중복 코드도 늘어났습니다. 중복코드가 생길때 마다 상위 디렉토리에 묶어서 사용해야했지만, 나중에 하지라는 안일한 생각으로 결국엔 너저분한 코드가 완성되었네요. 기술 부채는 눈덩이 처럼 커집니다. 클린 코드에서 언급한, 떠난 자리를 깨끗하게 하는 보이스카우트 규칙을 다시 한번 생각해 봐야겠습니다.

3. 귀찮음

귀찮음은 만악의 근원입니다. 

서버든 클라이언트든 Typescript를 사용하려 했지만, 조금 귀찮아서 서버에는 적용하지 않았습니다. 덕분에 Typescript의 필요성에 대해 절실하게 느끼게 되었습니다. 마찬가지로 react-native에 sass를 적용하려 했지만 모듈 설치하고 설정하는 부분이 싫어서, 이번에는 그냥 사용해보지 뭐! 하고 그냥 진행해본 결과, 한 파일내에 디자인 코드까지 엄청 나게 많은 코드가 들어가게 되었습니다. Typescript와 sass이 개발 생산성 향상에 엄청난 도움을 준다는 교훈을 얻었다고, 긍정적으로 생각하겠습니다. 하지만 귀찮음은 꼭 고쳐야겠습니다.