Intro

나는 오늘 내 인생 처음으로 가장 긴 기간의 Project를 마쳤다. 사실 그 긴 기간이 4주라 다른 사람들이 보기에는 참으로 짧은 시간일 것이다. 하지만 나에게는 가장 어렵고도 힘든 시간이었다. 물론 즐거운 순간도 여럿 있었다. 오늘 이 Project를 마무리하면서 느낀 감정들을 풀어내보려 한다.

Project의 시작

First Project가 2주만에 끝이 났다. 사실 발표라고 할 것도 없고 그냥 서로 보고 칭찬해주고 끝이었다. 그리고 팀도 해체되었다. 나는 팀이 그렇게 되는 것을 Project 마지막이 되어서야 알게 되었고,(팀원분들이 다른 분들과 Final을 하기로 내정이 되어있으셨다.) 그 날부터 새로운 팀원을 찾아 나섰다. First 때 같이 Back-end를 했던 한 분과는 계속 팀을 하기로 했고, 둘 다 Back-end 쪽을 더 공부하는 것을 희망해서 Front-end를 희망하시는 분을 팀으로 모시고자 백방으로 뛰어다녔다. 그렇게 한 분과 연이 닿아 세 명이서 함께 프로젝트를 시작하게 되었다.

처음 팀원들과 마주하고, 내가 팀장이 되었고 아이디어 회의를 시작했다. 여러 아이디어가 나왔다. 유력한 후보로는 당근마켓같은 지역내에서 중고물품 또는 전자제품 등을 빌려주는 아이디어와 기르고 싶은 습관을 등록해놓고 하루에 한 번씩 체크를 하는 서비스를 생각했다. 우리팀은 이 두 서비스 중에 실제로 출시되었을 때 일어날 문제들에 대해 생각했고, 중고물품 공유 서비스는 아직 한국 사회에서는 힘들다 판단. 습관 서비스로 결정을 내리고 기획을 시작했다. 기획 단계는 철저하게 할수록 좋다고 생각했다. Figma를 이용해 서로 공유하며, 아이디어를 Fix시키고 WireFrame, DB Schema, 사용할 스택 등 고민을 많이 했다고 생각했지만 프로젝트 기간 중 기획에 더 시간을 쏟을 걸 그랬다는 생각을 많이 할만큼 부족했다. 그래서 내가 팀장으로서 좀 더 제대로 기획을 했어야 했나 생각이 들어서 팀원들에게 미안한 감이 있다.

서비스 소개

습관나무 서비스는 평소 기르고 싶었던 습관을 등록하고 하루하루 체크해 나가며, 자신의 것으로 체득하는 것을 도와주는 서비스다. 하루하루 체크할 때마다 달력 옆 캔버스에서 나무들이 자라나며, 만약 처음 습관을 기르고자 한 날로부터 28일이 지난 후 달성률이 90%이상이라면 MyPage내의 나만의 숲에서 성공한 습관의 개수만큼 다 자란 나무들을 볼 수 있는 서비스이다. 이를 통해 습관을 기름과 동시에 나무도 키우는 두 가지 성취감을 모두 맛 볼 수 있다.

Stack 공부 시작

이를 구현하기 위해 First Project가 끝나고 난 뒤 잠깐의 시간동안 Final을 같이하기로 한 분과 다음 프로젝트 때 사용할 스택에 대해 미리 고민 하는 시간을 가졌다. 안전성을 더하기 위해 Front, Back 모두 Typescript는 써야할 것이라고 생각했다. 그럼 Back-end에서 Typescript를 express에 쓸 것이냐라고 생각했을 때, 우연히 한 유투버의 Nestjs 강의를 보게 되었다. Nestjs는 Typescript를 적극 도입하고 있고, 유효성검사, OOP에 알맞은 구조적 짜임새 등이 눈길을 끌었다. Module을 통해 비슷한 기능을 하는 것들을 하나로 캡슐화하고 재사용할 수 있게 한다. 그리고 Guard를 통해 요청이 들어왔을 때 요청을 보낸 사용자가 검증된 사용자인지 확인하고 검증된 사용자만 그 다음 요청을 수행하게 한다. 또, Pipe를 이용해 Validation을 간편하게 할 수 있다. Typescript를 사용하여 안정성을 높였고, Express보다 구조가 복잡하긴 하지만 nodejs의 라이브러리도 모두 사용가능하고, 코드의 구조가 OOP에 적합하기에 깔끔한 코딩을 위한 공부에도 많은 도움이 될 것으로 판단하였고 이번 프로젝트에 사용하기로 결정했다. 이는 Express기반으로 사용이 가능한 건 물론이고, Fastify를 통해서도 구현 가능하다. Express기반으로 사용할 때, 속도 저하의 위험이 있다. Fastify를 사용했을 때, Express기반일 때 보다 2배이상의 속도에 대해 강점이 있다. 하지만 알아보던 중 Fastify는 Express에 비해 커뮤니티가 소수고, 이제 처음 스택을 공부하고 적용해보려는 우리에게 문제해결에서 도움이 될 만한 자료들이 많지 않다는 것을 알게되었고, 일단은 속도문제를 갖고있지만 사용해보기도했고, 커뮤니티도 많이 활성화 된 Express기반으로 개발을 하기로 했다. 그렇게 Nestjs는 약간의 강의와 공식문서를 통해 공부를 했고, 문제는 Typescript였다.

Typescript는 기존 Javascript의 모호함을 잡아주는 보조 역할을 해 안정성을 높여준다. 컴파일 단계에서 에러를 잡아주므로 버그가 고객에게까지 가지 않는다는 점도 높이 평가받고 있다. 하지만 이를 어떻게 배워야할 지 공식문서만 보고 많은 타입들을 다 익히고 적용하는 것이 가능할 지 고민했다. 그 결과 대략적인 타입들을 공부하기 위해 인터넷 강의를 결제했고, 주말을 이용해 개략적인 내용들을 파악하고 공식문서를 통해 배운것들을 복습하고 적용시켜나가기로 했다. 4주라는 시간안에 하나의 결과물이 필요했기에 가능했던 결론이었던 것 같다. 프로젝트가 끝났으니 조금 더 깊이있게 Typescriptf를 공부할 것이다.

Coding

그렇게 스택에 대한 공부를 하고, 코딩을 시작했다. Back-end 부분은 TypeORM의 관계설정 부분과 Passport를 이용한 카카오 로그인 부분을 제외하고는 문제없이 진행 되었다.

TypeORM 관계설정

일대다 설정을 할 때, 일인 테이블에 @OneToMany 데코레이션을 사용하고, 다인 테이블에 @ManyToOne 데코레이션을 사용하면 다인 테이블에 Column이 생성된다고 나와있고, 실제로 생성되는 것을 확인했다. 하지만 Query를 할 때, 되지 않는 오류를 맞닥뜨렸다. StackOverFlow검색 결과 ManyToOne을 사용할뿐만 아니라 @Column 데코레이션을 통해 Column을 직접 생성해줘야한다는 것을 보았고, 해결이 되었다.

카카오 로그인

Passport를 사용하여 인증을 할 경우, 라이브러리 없이 구현한 경우와는 조금 달랐다. Authenticate Code를 받아와 Token을 요청하는 클라이언트의 요청이 Passport의 전략안에 들어있는 느낌이었다. Callback을 서버로 보내고 서버에서 다시 요청을 보내는 구조로 되어있었다. 그리고 first 때 사용자 정보를 받아오기위해 요청을 한번 더 보냈었다. 하지만 이번에는 한번에 정보까지 받아왔다. 뭔가 간편하면서도 이게 왜 되는건지 이해할 수 없는 순간이 있었다. 이렇게 편하니까 라이브러리를 쓰는건가? 싶기도 했다. 그러나 Client에서 요청을 보낼 때 axios를 사용하다보니 카카오 내에서 CORS에 걸렸다. 그래서 그 문제는 검색을 통해 <a>태그를 이용해 요청을 보내는 것으로 해결했다.

이렇게 두 문제를 잘 해결했고, 서버의 API는 2주차에 모두 완성이 되었고, 혼자서 고군분투하고 있는 Front-end 쪽에 힘을 싣기로 하였다.

일단 Front-end 쪽은 혼자서 하고 계셨기 때문에 CSS며 React며 정리가 하나도 되어 있지 않았다. 그래서 먼저 Typescript를 적용한 React로 전환이 필요했다. 그리고 우리는 Redux를 사용하지 않고 Hooks 를 통해 상태관리를 하기로 해서, 여러가지 필요한 상태들을 어디서 관리를 해야할 지 많은 고민이 필요했다.

그리고 가장 큰 문제는 나무를 어떻게 그려주는 것이냐 였다. Front-end를 맡아주신 팀원분께서 캔버스를 사용하여 단계별로 나무가 자라는 모습을 보여주려 했으나 단계별로 구현해내는 것이 쉽지 않다고 하셨다. 우리 서비스에 가장 핵심이 되는 기능이었으므로 어떻게든 해내고 싶었다. 그 기능을 구현하기 위해 며칠을 거기에만 매진하시다 팀원분이 아프시기까지 했다. 그래도 포기할 수 없어 유튜브에서 canvas로 나무 그리기 영상들을 보고 코드도 따라쳐보고 하다가 조건문을 통해 나무의 크기를 조절할 수 있다는 것을 봤고, 팀원들과 공유하여 함께 우리 코드에 적용할 방법을 고민한 결과 현재는 달성률에 따라 나무를 자라게 할 수 있게 되었다.

그렇게 큰 고비를 넘기게 되었고, 처음에 우리가 기획했던 Bareminimum단계의 기능들은 모두 구현할 수 있었다.

마무리

이번 프로젝트는 아쉬움이 많이 남는다. 좀 더 잘하고 싶었던 마음이 커서였을까? 아니면 내가 팀장으로써 역할을 제대로 못했다고 생각해서일까? 아쉬움과 화도 많이 난다. 결과물을 보고 좀 더 잘 할 수 있지 않았을까? 라는 생각이 많이 든다. 사실 프로젝트의 결과물은 디자인으로써 많이 평가되는 듯 해서 많이 아쉽다. 다른 팀에는 미술을 공부하신 분도 계시고 디자인 하시던 분도 계시고 그 분들과는 차이가 날 수 밖에 없기 때문에 아쉬울 뿐이다. 물론 어떤 기능을 담고있는지도 중요하겠지만 처음으로 보여지는 부분은 디자인적 요소가 많이 개입을 하기 때문에 어쩔 수 없다고 생각한다. 그리고 우리 팀원들도 모두 대단한 사람들이다!!

이번 프로젝트를 하면서 개발자로써, 그리고 인간으로써 많이 성장한 느낌이다. 지금까지 나는 좋은 성과물을 내기 위한 팀장은 아니었다. 그냥 좋은 사람으로 남고자 하는 팀장이었다. 그게 가장 후회된다. 강하게 얘기할 때는 강하게 얘기할 줄도 알아야 한다. 마냥 좋은 게 좋은 게 아니다. 또 한 번 배웠다. 그리고 개발자로써도 많은 것을 배울 수 있었다. 새로운 스택도 공부를 했고, Back-end 뿐만 아니라 Front-end의 즐거움도 느낄 수 있었다. CSS를 하며, 보여지는 즐거움을 알았다. 또한 Nestjs, Typescript를 사용함으로써 OOP에 대한 개념도 더 확립할 수 있었다. OOP가 왜 확장성이 있고 재사용성이 높다고 하는지도 실전을 통해 알 수 있었다. 여기서 끝이 아니라 앞으로도 좀 더 깊이있는 공부를 할 것이라는 다짐도 새겼다. 그래도 4주간 주말도 없이 노력했던 나에게 고생했다고 말해주고 싶다. 그리고 왜 개발자가 되려고 했는지 다시 한번 새기게 되는 날이기도 하다. 사람들이 필요로 하는 그리고 좀 더 편했으면 하는 서비스를 제공하고 사용하는 사람들의 즐거움이 내 즐거움이 되는 그런 모습이 상상만으로도 웃음지어 진다.

끝