프로젝트 핵심 과제들

떡상 프로젝트는 네카라쿠배 프론트엔드 온라인 스쿨을 수료 후, 수료생들 중 나와 같은 생각을 가진 팀원 넷이 모여 포트폴리오용 프로젝트를 완성하고자 시작되었다.

주제는 금융 & 증권 정보를 제공하는 외부 API를 사용해 지수나 주가같은 데이터, 차트, 뉴스 등의 정보를 제공하는 사이트를 목적으로 하였다.

떡상이라는 이름은 최근 금융가에서 많이 사용되는 은어로, 가치가 짧은 기간안에 폭발적으로 증가하는 현상을 나타내는 단어로 팀원들 각각의 개발자로서의 가치가 떡상하길 바라는 마음을 담아 짓게 되었다.

첫 기획 회의에서 팀원끼리 합의한 프로젝트의 핵심 과제는 다음과 같았다.

React, NextJS, Redux 등 프론트엔드 트렌드 기술 익히기
TypeScript를 사용하여 정적 스크립트를 사용한 프로젝트 안전성 높이기
Canvas API 사용 차트 구현하기 (라이브러리 사용 X)
RTL&Jest를 사용한 TDD 적용해보기
Websocket 적용하여 실시간 데이터 렌더링하기

난관 및 아쉬웠던 점

먼저, 떡상 프로젝트는 처음부터 체계적인 계획을 갖고 진행된 프로젝트는 아니었다. 나의 경우, 취업용 포트폴리오로서 활용한다는 목적이 가장 큰데 반해, 어떤 팀원은 특정 기술을 적용한 프로젝트를 해보고 싶다 혹은 처음 써보는 기술을 배우는 목적으로 활용하고 싶다거나 하는 등 지향점이 달랐다.

결국 이 부분에 대해서 나는 다음과 같이 타협할 수 밖에 없었다.

2월 이내에 프로젝트를 마치고 하차한다는 점(3월 부터 본격적인 취준 활동에 들어가기 위함.)
하차하기 전 핵심 과제 부분을 최대한 구현 후 완성된 형태를 갖추는 것

비록 완벽한 프로젝트라고 하기 어렵지만 내 부족했던 점과 성과를 기록으로 남겨 더 나은 개발자로 성장하기 위해 이렇게 회고를 작성한다.

1. 신기술 적용의 어려움

빠르게 변하는 트랜드

웹 프론트엔드를 공부하면서 많이 들었던 이야기가 기술 트렌드의 변화가 무척 빠르다는 것이었다. 그 말을 처음 들었을 때는 체감하지 못했지만 신기술을 적용한 프로젝트를 진행하면서 그 말이 어떤 의미인지를 깨달을 수 있었다.

단적인 예로, next.js의 Link 컴포넌트를 사용해 queryString을 포함해 페이지를 routing해야하는 경우가 있었다. useRouter Hook을 사용하면 간단히 해결할 수 있던 문제였지만 처음에는 모르고 Class Component가 대세인 시절 방식을 적용하여 구현했던 적이 있었다. 내가 참고했던 소스는 불과 1~2년전 방식이었음에도 그 사이에 더욱 편하고 쉬운 방법이 생긴것이었다. 오늘은 이게 최선이라고 생각했던 코드가 내일은 구닥다리 코드가 될 수 있다는 말이 어떤 느낌인지 체험할 수 있었다.

정보 공유를 통한 퍼포먼스 향상

이번 프로젝트에서는 Next.js, TypeScript, Redux Toolkit 같은 현업에서 실제로 사용중인 트렌드적인 기술들과 RTL&Jest 등 테스트도구를 사용해보려는 노력을 했다. 따라서 초기에 기술에 적응하는 시간이 필요했고, 숙련도 문제로 퀄리티도 썩 좋다고 할 순 없지만 우리가 필요로 하는 기능을 막히는 부분 없이 성공적으로 시간내에 마무리했다는 점에서 그 의의를 두기로 했다.

또한 이러한 이슈로 팀원들 모두에게 정보 공유가 원활히 이뤄져야할 필요성이 있었고 Github의 Wiki를 활용해 트러블슈팅 혹은 기술 공유 내용을 정리하여 이러한 문제점을 해소할 수 있었다.

떡상 프로젝트 위키

Home · DDSS-FE/DDuck-SSang Wiki

2. 반쪽짜리 TDD

TDD 도입 계기

초기 기획단계에서 프로젝트에 TDD를 적용하자는 의견에 나는 반신반의했다. 가장 큰 이유는 TDD를 경험해보지 못한 사람으로서의 두려움과 걱정이었고, 두번째 이유는 TDD가 왜 필요한지에 대한 이해 부족이었다. 그보다 다른 주력 기능을 더 배우고 사용하는데 집중하는것이 낫지 않을까라는 생각도 있었다. 그러나 프로젝트를 마친 지금에야 Test 코드의 필요성과 TDD의 강력한 장점에 대해 다시 생각해보게 되는 경험이었다.

떡상 프로젝트에서는 React Testing Library와 Jest를 사용해 Unit Test를 진행했다. Cypress 같은 대안도 있었지만 TDD에 익숙하지 않은 우리들은 Unit Test을 중점적으로 개발하는 것을 우선순위로 삼아 진행했다.

TDD의 어려움

도구의 사용법이나 테스트 코드를 작성하는 방법은 반복을 통해 어떻게든 헤쳐나갈 수 있었지만 가장 큰 문제점은 어떤 테스트를 어디까지 할 지에 대한 기준을 명확하게 파악하기가 어려운 점에 있었다. 누구도 제대로된 TDD를 경험해본 적이 없으니 어떻게 보면 당연했다.

결국 컴포넌트에서 Props를 제대로 받아왔는지, Fetch한 데이터가 제대로 렌더링 되는지, 단순한 이벤트가 제대로 동작하는지 수준의 간단한 테스트에 그쳤고 그마저도 시간이 부족해 모든 커버리지를 테스트하긴 어려웠다.

TDD의 장점

그러나 이런 반쪽짜리 TDD라도 확실한 장점을 몸소 체험할 수 있었다. 이전에는 단순히 요구사항과 기능만을 놓고, 막연한 구상을 통한 개발을 진행했다면, TDD를 적용하고 나선 필요한 기능을 단계적으로 구현하게 되어 좀 더 체계적인 개발이 가능했다. 뿐만 아니라 리팩토링, 디버깅을 할 때도 테스트 코드를 통해 어디가 잘못됐는지 쉽게 파악할 수 있다는 강점을 체험해볼 수 있었다.

성과 및 만족스러웠던 점

위와 같은 아쉬웠던 점도 분명 있었지만, 많은 기술적 성장을 이룰 수 있던 프로젝트였기에 그 성과를 요약해보자면 다음과 같다.

실무같은 환경에서 작업

기획이 끝나고 본격적인 작업에 들어갔을 때 팀원들은 게더타운에 모여 매일 10~7시까지 실제 회사에서 일하듯 업무 환경을 갖췄다. 오전 미팅에서 현재 진행 상황과 TodoList를 공유하고, 해산 직전 다시 한번 작업 내용과 전달 사항을 공유하는 스프린트를 반복했다. 또한 Github를 적극 사용해 Issue와 PR 기반으로 각자 짧은 코드 리뷰를 진행함으로써, 버전 충돌과 버그를 최소화하는 작업 환경을 갖출 수 있었다.

TypeScript의 도입

TDD와 마찬가지로 TypeScript의 도입은 하나의 도전 과제였다. 개인 프로젝트에서 사용해본 적은 있지만 이렇게 그룹 프로젝트 규모의 프로젝트에 적용하는 것은 이번이 처음이었고, 게다가 TypeScript와 최신 기술들과 접목하는 것은 산 넘어 산이라는 느낌이었다. 그러나 그 과정 정도 하루 이틀 지나기 시작하자 당연하게 여겨졌고, ESLint와 눈싸움을 하며 Type들을 완성해가는 과정을 통해 프로젝트는 안전성을 더해갔다. 비록 아직 Type을 좀더 효율적으로 만들거나 깔끔하게 정리하는 테크닉은 미숙하지만, 앞으로 Type이 없는 코드가 더 어색해지는 날이 오지 않을까라는 생각이 든다.

페어 프로그래밍의 효과

떡상 프로젝트 팀원으로 모인 4명은 각자 나이도 다르고 환경도 다르지만 프론트엔드 개발자가 되기 위해 네카라쿠배 스쿨이라는 교육과정을 같이 수료한 인원들이었다. 따라서 처음 프로젝트를 같이 하려고 했을 때 합을 맞추기가 쉽지 않았다. 배움의 범위도, 숙련도도, 목표도 제각각이었기 때문이다. 그러나 이러한 차이점을 극복하기 위해 우리는 공동의 목표를 세우고 페어 프로그래밍을 통해 이를 해결하고자 했다.

나와 페어를 짠 L군은 나보다 React나 TypeScript에 대한 경험은 없었지만 Test 코드에 대한 경험이 풍부했다. 그래서 같이 TDD를 진행할 때 L군이 Testing 코드를 가르쳐주고 내가 Component 및 기능 개발을 서포트하는 식으로 진행했다. 확실히 자신이 잘하는 분야를 파트너에게 가르쳐주는 식으로 진행하니 서로의 약점이 보완되고 전반적인 퍼포먼스도 향상하는 효과를 누릴 수 있었다.

결론

4주 간의 짧다면 짧고 길다면 긴 시간동안 협업하고 의견을 나누며 하나의 프로덕트를 마치기 위한 과정을 겪었다. 혼자서 진행했다면 놓쳤을 부분을 여럿이서 머리를 맞대고 함께 해결하는 과정을 통해 또 한번 성장할 수 있었다고 생각한다. 앞으로도 이와같은 프로젝트를 더 많이 진행하게 될텐데 그때는 이번에 깨달은 나의 부족한 부분을 채운 상태로 임해 더 나은 퍼포먼스를 발휘할 수 있기를 기대한다.