[Final Project] 4주의 프로젝트를 마치며

한달이 훌쩍 흘러서 드디어 final project를 마쳤다. 시간도 빨리 흘러갔고 끊임없이 코드를 보고 있으니 코드가 내가 된 것 같고 내가 곧 코드인 상태가 된 후에 끝이 난 것다. 이번 프로젝트는 특히 팀원들과 좋은 시간과 활발한 커뮤니케이션을 할 수 있어서 더욱 기억에 남을 것이다.

1. 아주 험난하지만 꼼꼼한 start

우리 팀은 아이들에게 교육프로그램을 제공하면서 현재 유치원에서 꼭 필요하다고 생각하는 기능을 가진 페이지를 만드는 것을 목적으로 만나게 되었다. 공동의 확고한 목적을 가지고 있으니 페이지를 어떻게 구성해야겠다는 아이디어나 기능의 흐름도는 원활하게 나오게 되었다. 하지만 험난한 과정은 여기서 시작되었다.

기능을 생각해내고 흐름을 만드는 것과 기능을 구현하는 것은 전혀 다른 영역이었다. 우리의 앱은 학부모, 선생님, 원장님의 페이지, 회원가입이 전부 다르게 되어있는데 이렇게 되니 권한에 따라 페이지의 분기가 필요했고 첫번째 프로젝트의 최소 2 배 이상의 작업량을 가지게 되었다.

무엇보다 데이터베이스는 심혈을 기울이게 되었다. 첫번째 프로젝트 때 4명 모두 Front-end에서만 작업했기 때문이다. 그리고 권한이 3개인 만큼 데이터베이스 관리, 관계도 3배 이상 늘어나게 되었다. 따라서 Back-end하시는 분이 최대한 부담을 얻지 않고 클라이언트 측에서도 원활하게 서버요청을 할 수 있도록 API와 SCHEMA 작성에 2일의 시간을 투자하게 되었다.

2. 초기 세팅

1) 첫번째 과감한 결정 => Redux 포기

드디어 초기 세팅 과정으로 들어가는 날. 처음에는 지난번 프로젝트를 고려하여 40개 이상의 state를 다루기 위하여 redux를 사용하기로 결정하고 redux 체제로 세팅하던 중에 문제가 생기게 되었다. store를 어떻게 사용하지? action? reducer?...
분명 sprint 과제로 배웠던 redux였지만 실전에서 사용하기에는 지식이 많이 부족했다. 그랬다고 새로운 지식을 배우고 연습하기에는 빠듯한 시간이라고 생각했다.
그러던 도중 redux를 개발한 개발자 분이 올리신 포스트를 보았다.

https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#.4ucx5na41

나는 함께 작업하는 클라이언트분과 redux 사용에 대해서 논의를 하고 redux를 사용하지 않아도 충분히 state를 관리할 수 있다는 결론을 내렸다. 대신 hooks를 이용해서 state를 효율적으로 관리할 수 있는 방향으로 나아가게 되었다.

2) 타입스크립트, 안전하지만 엄격한 숙제

추가 스택으로 타입스크립트를 사용하기로 결정하였다. 타입에러를 방지하여 디버깅하기에 용이해지고 타입을 한정해줘서 안정성을 높일 수 있기 때문이었다. 단 이 것은 잘 썼을 때의 문제였다.

타입스크립트는 클라이언트 측에 아주 큰 숙제를 주었다. 일단 타입을 한정되어있기 때문에 타입에 어긋나는 코드만 작성하더라도 compiling 오류가 발생하였고 타입을 정해줄 때 추가 코드를 입력해주는 번거로움은 타입스크립트를 충분히 불편해할 수 있는 이유를 만들어주었다.

그럼에도 타입스크립트를 사용하면서 확실히 타입에 대한 에러는 막아주었고 코드의 재작성을 할 필요가 없어 이 방식 나름대로 신속하다는 생각까지 하게 되었다. 또한 내가 작성하는 코드의 타입을 정해줌으로써 서버에서도 잘못된 정보를 받지 못하게 막을 수도 있었다. 비로소 사람들이 사용하는 이유에 대해서 알게 되는 순간이었다.

3. Intro를 비롯한 기능구현

두번째 과감한 선택 : 반응형 Refactoring

인트로 페이지를 비롯해서 회원가입, 로그인 등의 기능을 구현하면서 드는 생각은 첫번째 프로젝트 때보다는 뭐든지 더 잘 만들 수 있겠다는 것이었다. 그래서 현재 보이는 모습에만 집중하였고 완성시켰을 때에 생각보다 할만하다는 여유까지 있었다. 하지만 팀장님이 말씀해주시지 않았다만 내가 맡은 중요한 기능들이 손 쓸 수 없었다고 생각한다.

우리가 만드는 프로젝트는 기본적으로 앱을 더 많이 사용할 것으로 예상하는데 디스플레이를 앱 크기로 줄이니 웹애서 만들었던 위치가 전부 겹치거나 뭉게져서 보여지게 되었다. 기능으로는 충분하지만 UX 부분에서는 반드시 수정해야 할 부분이었다. 그래서 전면 뜯어고치기로 마음먹었다.

화면을 3개로 분기하여 앱 환경(주로 아이폰과 갤럭시 위주로), 13인치 모니터 환경(맥북), 18인치 이상 모니터 환경에서의 css를 달리하여 최대한 다양한 환경에서도 원하는 위치에 보일 수 있도록 설정하였다.

<맨위의 반응형과 대조되는 13, 18인치 모니터 UI>

다행히 기능적인 면에서는 권한이 나뉘어져있는 부분을 제외하고는 어렵지 않았다. Back-end를 맡아주신 팀원님께서 완벽하게 데이터베이스와 서버요청을 구현해주셨기 때문이다. 다만 나에게 아쉬웠던 점은 세부적인 디자인 요소부분이었다. 글의 크기, 색상, 위치 등 미적인 디자인 부분이 많이 미흡했는데 이 부분을 팀장님과의 소통을 통해서 조언을 받으면서 많이 개선하게 되었다. 리스트나 텍스트를 더욱 돋보이게 하는 능력은 나의 과제가 되었다.

4. Feedback

1) 분석의 필요성

이번 프로젝트에서 가장 크게 느꼈던 것은 과감히 포기해야 하는 영역과 유저들이 정말로 원하는 기능을 더 철저하게 분석해야 한다는 것이었다. 생각보다 신경 써야할 부분도 많고 우리가 넘어가도 된다는 부분에서 실수를 가지게 되기 마련이었다. Intro 페이지의 반응형 문제가 이를 반영한다. 유저의 입장에서 생각해보며 개발자에게 편한 프로젝트가 아닌 유저들이 정말로 원하는 것을 포함한 앱을 만들 수 있도록 분석 능력을 기를 것이다.

2) 팀원과의 소통의 중요성

프로젝트는 혼자 하는 것이 아니다는 것을 다시금 느꼈다. 내가 코드 작성이나 css를 보완할 때 부족한 부분이 있다면 팀원이 채워주었고 나 또한 팀원이 도움을 요청할 때에 기꺼이 문제를 함께 해결할 수 있었다. 내가 가지고 있는 문제를 나만 알고 있으면 안되며 팀원에게 적극적으로 소통하면서 문제를 해결하거나 방향을 신속하게 전환하는 것은 프로젝트에서 너무나도 중요한 과정이었다. 내가 어떤 곳에 가든지 팀원의 의견에 귀를 기울이며 내 의견을 주장하여 빠르게 문제를 함께 해결할 수 있는 팀원으로 성장하는 것이 현재 나의 과제 중의 하나이다.

3) Never give up

팀원과 함께라면, stackoverflow나 구글링과 함께라면 내가 해내지 못하는 기능은 없으며 고치지 못할 버그도 없었다. 내가 그 문제를 해결하거나 새로운 기능을 구현해야겠다는 마음가짐이 있다면 나는 내 생각보다 더욱 뛰어난 사람이 될 수 있었다. 앞으로 내가 일할 workplace에서는 이 것보다 훨씬 더 어려운, 복잡한 이슈들이 가득하겠지만 절대 포기하지 않고 팀원과 함께 반드시 해결하겠다는 자세를 가지고 업무에 임하는 잠재력을 가진 개발자가 될 것이다.

5. 기나긴 여정을 마치며

아직도 내가 구현하고 싶은 기능들은 많다. 도전해보고 싶은 부분도 있다.
그리고 내가 현재 해야 할 과제들도 많다.

하지만 두려워하지 않을 것이다. 10년 후에 내 분야에서 이름 있는 전문가가 되겠다는 신념으로 실패를 두려워하지 않고 도전할 것이다.