부스트캠프 웹·모바일 7기 - 함께 하기, 빠르게 실패하기

2022년 7월 18일 부스트캠프 웹·모바일 7기 캠퍼가 되어 챌린지, 멤버십 과정을 거치고 수료를 했다. 올해의 반을 부스트캠퍼로서 활동하며 스스로가 크게 성장했음에 확신한다. 그만큼 이번 회고에서 하고 싶은 말이 너무나 많지만, 멤버십 과정의 그룹 프로젝트에 대해 중점으로 회고하겠다.

함께 하기

그룹 프로젝트 시작이 다가왔을무렵 팀 모집이 시작되었다. 팀을 모집하지 않으면 랜덤으로 팀 구성이 이루어지는데, 수동적으로 마냥 기다리기는 싫었다. 조금이라도 나의 팀 플레이 가치관과 부합하는 사람들과 6주라는 시간을 함께 하고 싶었다. 그러나 팀원을 모집하기에 내세울 특별한 아이디어가 없었다. 그래서 '나'라는 사람이 왜 개발자를 꿈꾸는지 어떤 개발을 하고 싶은지를 내세웠다.

고맙게도 세 캠퍼분들이 연락을 주셨고, 함께 하게 되었다. 그리고 우리는 가장 먼저 팀의 룰을 설정했다.

설정한 룰이 프로젝트를 진행하면서 추가되기도 했다. 한 예시로, 각자 자신이 맡은 업무를 수행하며 그에 매몰되는 경우가 빈번히 생겼기에 이를 예방하고자 '티타임' 이라는 룰을 중간에 도입했다. 매일 오후 4시에 휴식겸 자유롭게 소통하는 30분의 시간을 가지면서, 어려움을 느껴 고민하고 있는 부분을 공유하여 더 빠른 문제 해결을 도모했다. 또한 환기하는 시간이 됨으로써 현재 업무에 매몰되지 않도록 방지했다.

반대로 룰을 수정하거나 제외하기도 했다. 특정 룰이 오히려 팀의 프로젝트 비용을 소모하게 했기 때문이다. 우리는 프론트엔드와 백엔드를 2명씩 전담하여 개발을 진행했는데, 그럼에도 모두가 모든 코드에 대한 이해를 갖추기를 원했다. 그에 따라 모든 팀원이 PR 코드를 확인하고 승인해야지만 merge가 되도록 했는데, 이 때문에 업무가 지체되는 경우가 빈번히 생겼다. 그래서 후반에는 각자 담당한 파트(프론트엔드/백엔드)의 인원에게만 리뷰를 받고, 다음날 오전 스크럼에서 다른 파트 팀원들에게 최대한 공유하는 형식으로 변경했다.

팀에 효율적인 협업 룰을 설정하는 것은 참 어려운 것 같다. 큰 도움이 되기도 하지만 때로는 스트레스가 되기도 한다. 하지만 이번 프로젝트를 하면서 팀의 룰을 설정하는 것은 꼭 필요한 일이라고 느꼈다. 마치 학창 시절에 학교에서의 교내 규칙이 있던 것처럼, 구성원 모두가 통일된 규칙을 따라야지 팀이 건강한 방향으로 나아갈 수 있다. 그래서 이처럼 필수시되는 협업 룰을 어떻게 해야 더욱 효율적으로 세우고 실천할 수 있을지 이번 프로젝트를 마친 후 크게 고민이 된다. 나는 정답을 도출할 수 없는 고민을 할 때, 가장 먼저 손이 가는 것이 바로 '책'이다.

조금의 힌트 또는 다른 발상을 얻을 수 있지 않을까 기대하는 마음으로 '함께 자라기 (김창준)' 책을 샀다. 책도 물론 유익하지만 가장 좋은 방법은 역시 직접 경험해보는 게 아닐까. 얼른 또 다른 팀에 소속해봄으로써 많은 협업 경험을 해보고 싶다.

빠르게 실패하기

개발 프로젝트를 하면서 완벽할 수는 없다. 더군다나 주니어 개발자(예비 개발자)인 나로서는 많은 실패를 겪는다. 많은 실패 경험은 후에 '나'와 '팀'에게 큰 도움이 될 수 있다고 생각한다. 선순환이 이루어지는 것이다.

* 프론트엔드 테스트 실패

여태껏 프론트엔드 개발을 하며 테스트 코드를 작성해본 적이 없다. 그래서 이번 프로젝트의 기술적 도전 중 하나로 프론트엔드 테스트를 꼽았다. 이에 따라 테스트 전략도 야심 차게 짰다. 팀이 소모할 수 있는 비용을 따져가며 열심히 설정한 전략이었지만 한 가지 큰 실수를 했다.

'무엇을', '어떻게' 테스트할지에만 집중했고, '언제' 테스트할지 전혀 생각하지 않았던 것이다. 이 때문에 내가 기획한 프론트엔드 전략이 개발 중 테스트에 대한 부담을 과하게 줄여버렸다. '언제' 테스트할지에 대한 테스트 룰이 없었기에 테스트에 대한 고려를 배제해버린 채 feature 개발에 매몰된 것이다.

이 것을 깨달았을땐 너무나 늦었었다. 당장 급히 구현해야 하는 feature가 넘쳐났기에 테스트 비용을 소모할 여력이 없었다. 결국 기술적 목표 중 하나였던 프론트엔드 테스트는 실패했다. 원인은 그저 프론트엔드 테스트에 대한 학습이 부족했던 것이고, 부족한 것은 앞으로 조금씩 채워가면 된다.

프론트엔드 아키텍처 실패

프로젝트를 진행하며 프론트엔드 아키텍처에 대한 문제점을 느꼈다. 개별 API 코드를 각 컴포넌트에서 불러와 사용하기에는 데이터 조작 로직이 분산되게 된다. 이는 API 코드에 대한 변경 사항이 생길시 각 컴포넌트의 관련 로직을 모두 수정하는 등 유지 보수하기 좋지 않다.

따라서 우리는 React Query Hooks(useQuery, useMutation)을 이용하여 비동기 API fetching 및 요청 데이터 조작 로직을 함께 담은 커스텀 Hook으로 분리했다. 하지만.. 개발을 진행하다보니 배드 스멜이 자꾸만 느껴졌다. 그렇게 직면한 문제들은 아래와 같다.

1. API 코드 하나에 매핑되는 React Query 커스텀 Hook을 매번 작성하는 것에 대한 번거로움
2. React Query 커스텀 Hook 내, 요청 데이터 변환 로직 존재
3. useQueries Hook을 사용할 때, 작성한 React Query 커스텀 Hook 재사용 불가
4. React Query 커스텀 Hook을 필요한 컴포넌트마다 import 함으로 인한 리팩토링 효율 저하

프로젝트는 끝이 났지만 문제 해결을 위한 고민을 계속해서 하고 있다. 현재 생각 중인 방법은 아래와 같다.

1. React Query 모듈화를 커스텀 Hook이 아닌 useQuery, useMutiation의 인자를 정의한 객체(또는 객체를 리턴하는 함수)로 관리
2. SOLID 원칙의 단일 책임 원칙 적용 (+ useQuery Hook option의 select 사용)
3. SOLID 원칙의 의존성 역전 원칙 적용

추가적으로 컴포넌트 아키텍처에 대한 문제점도 느꼈다.

모든 컴포넌트에 대한 재사용성을 고려하며 flat하게 관리하다보니 특정 컴포넌트를 찾는데 불편함이 크게 느껴졌다. 심지어 위 이미지는 몇가지 컴포넌트를 common 디렉토리로 분리하여 줄어든 양상이다. 또한 잘못된 관심사 분리로 재사용이나 확장할 수 없는 컴포넌트들도 많아졌다.

이 문제에 대한 해결 방법으로 아토믹 디자인에 대해 알게 되었다. 클린 아키텍처에 대한 학습 후 아토믹 디자인에 대한 학습도 해보자!

프론트엔드 테스트, 아키텍처 등과 같은 실패를 거듭하면서 '나'와 '팀'이 성장한다. 진부하지만 실패는 성공의 어머니니까. 앞으로도 계속해서 시도하고 빠르게 실패하자.

.

.

.

앞으로 스스로의 힘 만으로 어떻게 지속 성장할지에 대해 고민이 된다. 한편으로는 설렌다. 중요한건 여기서 멈추지 않고 꾸준히 나아가는 것이다. (중요한건 꺾이지 않는 마음..😆) 나의 성장에 기회의 장이 되어준 부스트캠프에 너무나 감사하다. 이 기세를 이어 계속해서 화이팅하자 🔥