[회고][42Cabi] 배포했다! 그리고...

지난 두 달간 매진한 42Cabi_v3 정식 배포를 잘(아마도) 마쳤다. 20시 42분에 서버가 열리자마자 사물함 현황이 보라색으로 점차 채워져 가는 걸 보고 있으니 정말 뿌듯했다.

회고를 종종 적었지만, 그전까진 기술적 어려움과 해결 과정을 주로 정리했기 때문에 두 달을 마무리하는 오늘은 첫 '팀 프로젝트' 를 진행하며 내가 느끼고 성장한 부분들에 대해 회고해보려고 한다.

🌟 비슷한 경험, 특별한 생각

기술적으로도 물론 많은 것들을 배웠지만, 특히나 '남들과 비슷한 경험을 했을 때, 이걸 어떻게 나만의 무기로 만들 것인가?' 라는 고민을 정말 많이 한 것 같다.

Next.js 나 graphQL 같은 최신 기술이나 react portal, SWR 같이 성능에 특별히 영향을 주는 기술을 사용해본 것은 아니므로 '대단한' 성취가 있었다고 생각하지는 않는다. 남들 다 아는 정도로 나도 얼추 따라잡은 정도? 어디가서 프론트엔드 개발자로 취직하고 '싶다'고 말하기 부끄럽지는 않은 정도다.

그러니 누군가는 특별하지 않은 경험이라고 할 지 모른다. 하지만 내게는 특별한 경험이다. 처음 맞닥뜨리는 상황들과 처음 사용해보는 기술들. 내가 성장한 시간이기 때문이다.

1시쯤 클러스터에 가서 10시가 다 되어 집에 들어올 때까지, 몰아치듯 이슈를 해결하고 코드를 뜯어고치고 하다 보면 사실 집에 오는 길에 머리에 남아있는 건 많지 않다. 분명 하루종일 뭔가 했는데 그게 일목요연하게 머릿속에서 정리되지 않는 건 아주 허탈한 일이다. 그래서 기록을 하기 시작했다. 경험은 비슷했을지 몰라도 받아들이는 방식은 사람마다 다르다. 진부한 말이지만, 그래서 '기록의 중요성'을 정말 크게 느낀 두 달이기도 하다.

'한 일' 보다 '한 생각'

위 이미지의 원본 문서는 여기를 클릭해서 확인할 수 있습니다.

프로젝트 끝자락에 좀 몰아서 하긴 했지만, 문제를 맞닥뜨리고 해결하기까지 내가 어떤 생각의 흐름을 거쳤는지 나누어 정리해 왔다. 문제와 해결만 놓고 보면 대부분의 사람들이 비슷한 방법을 쓴다. 재렌더링이 너무 많이 일어나면 state를 줄이거나 useMemo 등 hook을 사용한다. 그러니 오늘 '한 일'만 쭉 나열해 생각하다 보면 그저 그랬네, 하게 된다.

중요한 건 '한 일'이 아니라 '한 생각'이었다. 왜 그 해결책이었는지, 다른 해결책을 생각해보진 않았는지, 그 해결책의 side effect는 없는지 고민해본 과정이다. 남들과 같은 경험을 해도, 사람마다 각기 풍부하고 다양한 생각을 해볼 수 있다.

자식 컴포넌트의 props를 직접 수정하기 위해 cloneElement() 를 사용하면 된다고 했지만, 왜 메서드를 사용해야만 하는지, 타입 지정으로는 해결되지 않는지, 나아가 JSX가 createElement() 메서드로 트랜스파일되는 과정이 어떻길래 '시그니쳐가 없다'는 에러가 발생하는지 내가 파고들어본 것처럼 말이다.

🧐 맞춰야 하는 것

팀 프로젝트의 특장점으로 돌아가서, 일을 하는 동안에는 내가 해보고 싶은 것들, 내가 옳다고 생각하는 것들을 마냥 해볼 수가 없다. 시간은 한정되어 있고, 정해진 일정이 있기 때문이다. 개인 프로젝트를 하면 내가 해보고 싶은 것들도 다 해보고, 한 가지 문제를 며칠 내내 파고들기도 하고, 아니다 싶으면 갈아엎기도 한다. 기록할 시간도 충분하다.

하지만 팀 프로젝트에는 '맞춰야 하는 것'들이 있다. 타인의 방식이 내 방식보다 조금 비효율적인 것 같아도 일단 그걸로 문제를 빠르게 해결할 수 있다면 받아들여야 한다. 이 기술을 시도해보고 싶어도, 공부하는 데 시간이 든다거나 하는 이유로 그냥 기존 기술을 사용하는 게 비용상 더 이득이라면, 일단 그렇게 해야 하는 때도 있다.

가독성 좋은 코드

비슷한 맥락에서 '가독성 좋은 코드를 짜는 것'이 중요해진다. 내가 모든 코드를 맡아서 짜는 것이 아니기 때문에, 내가 작성해둔 코드를 결국 언젠가는 남이 맡아서 보수하거나 기능을 덧붙이게 된다.

지나치게 단축시켜 놓는 등 일반적이지 않은 로직을 작성하거나, 팀 내에서 얼추 합의된 수준을 벗어난 (나만 아는) 새로운 기술을 집어넣어 뒀거나, 반대로 deprecated 된 기술을 사용했다거나 하면 프로젝트의 전체 비용을 크게 높이는 결과를 낳게 된다.

코드가 조금 길어지는 것 같더라도 조건문과 함수를 적절히 사용해서 로직의 흐름이 누구에게나 잘 이해되도록 작성하는 것도 능력이다. 흔히 잘 아는 것과 잘 가르치는 것은 다른 영역이라고들 한다. 그만큼 지식의 양과 전달력은 비례하지 않는다. 하지만 개발자는 잘 알고 잘 전달해야 하는 것 같다. 그리고 변수명을 이해하기 쉽게 짓자.

PR과 이슈 자세하게 쪼개기

나는 PR과 이슈도 최대한 자세히 적으려고 노력했다. 애초에 내 코드가 가독성이 높을 것이라는 가정을 하지 않았다. 수정된 부분에 대해 정확한 커밋 메세지를 작성하는 것, 최대한 한 번의 PR(또는 커밋)에서는 한 개의 문제만 해결하는 것 등등 기록과 전달에 대한 부분이 개발 과정에서 아주 중요하다는 것을 느꼈다.

자고 일어나면 닫힌 이슈들을 팔로우업하고 새롭게 열린 이슈들을 파악해야 한다. 제대로 파악하지 못하면 브랜치끼리 충돌이 일어나거나 하는 불상사가 발생할 수도 있다. 하지만 커밋과 PR들을 거슬러 올라가다 보면 그냥 코드 diff 만으로 이해하기에는 잘 그림이 그려지지 않을 때도 있었다. 원인과 해결 과정을 자세히 적는 습관은 개발 과정에서 비용을 크게 낮춰줄 수 있다.

👥 개발은 협업이다!

그러니 팀 프로젝트를 통해 느낀 이 모든 점을 한 마디로 정리하면 '개발은 협업'이라는 점이다. 개발자 자소서, 개발자 취업 준비, 개발자 역량 등등 왜 개발 문화에서 협업과 소통 능력이 그렇게 강조되는지 처음엔 충분히 공감하기 어려웠다. 경영이라고 협업과 소통을 안 하는 것도 아니고, 그냥 하면 되는 것 아닌가 싶기도 했다.

이제 와서 이유를 생각해보자면 개발은 코드를 중심으로 소통하기 때문인 것 같다. 말로 적힌 문서보다 프로그래밍 언어로 적힌 코드로 소통하는 상황이 더 많다. 그러니 같은 협업이더라도 소통의 난이도가 더 높다. 프로그래밍 언어는 (당연히) 사람의 말과 다르다. 프로그래밍 언어가 정말 모국어라도 되는 것처럼 '이렇게 작성하면 얼추 알아듣겠지!' 했다간 사소하게 틀어진 이해들이 뭉쳐져 나중엔 거대한 문제가 되어 있을 수 있다.

이에 더해 대부분의 팀 프로젝트는 (역시나 당연히) 개인 프로젝트보다 훨씬 많은 양의 코드를 작성해야 한다. 백엔드와도 소통해야 하고, 같은 팀 안에서도 서로 다른 부분을 맡게 된다. 그냥 부품처럼 내가 맡은 부분만 완성해서 뚝딱 갖다 붙이면 끝나는 게 아니라, 결국 하나의 서비스로 뭉쳐지도록 '잘' 갖다 붙여야 한다. 그 과정에서 '얼추 알아듣겠지' 라고 쉽게 생각했다간 그 코드가 흘러흘러 나중에 나에게 무수한 git blame이 날아들 수도 있다 😅

따라서 나의 의도와 방식을 정확히, 충분히 자세하게 전달하는 것이 정말 중요하다는 것을 경험할 수 있었다.

💬 말 잘하는 법

팀 프로젝트를 해 보면 개발 외적으로도 신경쓸 것들이 정말 많다. 우선 나이와 배경이 각기 다른 팀원들과 원만하게 소통하는 데 많은 노력이 필요하고, 그 과정에서 많이 배우게 된다. 특히 프론트엔드 팀은 다들 나랑 나이차이가 6살 이상이라, 아이디어를 제안하거나 다른 의견을 낼 때 둥글둥글하되 의도는 정확하게 전하기 위해 많은 신경을 썼다.

그도 그럴 것이 나는 이 프로젝트에서 정말 아무것도 아닌, 1인분을 겨우 하는 인력이었기 때문이다. 다른 두 분은 최소한 코딩 경험이 나보다 더 많거나 프론트엔드(리액트)로 풀스택 프로젝트를 해본 적이 있는데, 갓 42서울에 들어와 혼자 뚝딱뚝딱 블로그나 투두리스트 몇 번 만들어본 내가 뭘 더 잘할 수 있다고 딱 잘라 의견을 피력한단 말인가.

자연스럽게 뭔가 생각이 나더라도 한번 더 정제해보는 습관, 다른 사람들의 의견을 먼저 충분히 듣고 말을 더하는 습관을 들였다. 내 의견을 이야기하더라도 먼저 다른 사람의 의견에서 좋았던 점, 혹은 그 의견의 요지를 반영해서 내 의견이 그를 보완할 수 있도록 애둘러 말하는 방법을 익혔다. 두 달 내내 느낀 거지만, "내 코드보다 좋은 코드는 무조건 있기 때문" 이다.

일로 만난 사이

스스로에게 '무슨 말을 이렇게 계산해서 하나' 라는 생각이 들기도 했다. 사실 대학교 팀플 같은 상황이면 이렇게까지 많은 생각을 하진 않았을지도 모른다.

42Cabi 프로젝트는 학교 팀플과는 완전히 다르다. 얼추 비슷한 배경과 비슷한 나이대, 관심사를 가진 사람들이 모인 집단이 아니다. 정말 '일로 만난 사이'다. 자칫 툭툭 던졌다간 결국 나에게 되돌아오게 된다. 온갖 쿠션어를 둘러서 무슨 말을 하려는 건지 모르게 하라는 게 아니라, 예의를 충분히 지킬 만큼 지켜야 한다는 뜻이다.

수평적인 관계일수록 더 의사 전달에 주의를 기울여야 한다는 점은 이전에 스타트업 인턴 때도 느낀 점이다. 누구든 편하게 의견을 낼 수 있다는 점은 큰 장점이지만, 그렇다고 전달하는 방식까지 지나치게 편해졌다간 관계를 경직시킬 수 있다. 수평적이라는 게 다른 팀원들의 경험치나 쌓아온 실력까지 무시할 수 있다는 뜻은 아니다. 나는 나이가 어리고 경험도 적다. 그러니 겸손하고 융통성 있게 행동하는 것은 굉장히 중요하다고 생각했다.

👾 안 되는 것이 있으면 안 된다

마지막 배운 점은 팀 프로젝트보다 '실제 사용되는 서비스'를 만들어본 경험으로부터 얻은 점이다. "있을 거면 되어야 하고, 안 될 것 같으면 없는 게 낫다"는 것.

오늘 정식배포를 위해 지난 2주(10/24 ~ 11/07)동안 베타테스트를 진행했는데, 어쨌든 테스트여도 카뎃들이 짧게나마 사물함을 실제로 빌리고 반납할 수 있도록 정식 서비스와 다름없이 운영되어야 했기에 오히려 오늘보다 베타테스트 날 더 긴장감이 컸다.

프로젝트 초반에는 뭐가 잘 안되더라도 "일단 구현했으면 넘겨~" 할 수가 있었다. 베타테스트 시작이 가까워올수록, 안 되는 것이 있으면 안 됐다. 42서울은 개발을 공부하는 사람들이 모여있는 만큼 개발의 완성도에 더 민감해야 했던 이유도 있다. 작게는 CSS 스타일링이 화면 크기에 따라 조금씩 밀리는 것부터, 크게는 메모장을 수정했는데 새로고침을 한 번 해야만 반영되는 문제 등등...

덧붙이자면 프론트엔드는 리팩토링을 하려다 포기하고 9월 한달 간 서비스를 아예 처음부터 다시 만들었는데, 전부 구현해놓은 다음 '되긴 되는데 잘 안되는 것' 들을 고치는 데 다시 한 달 만큼의 시간이 들더라.

개인 프로젝트를 할 때와는 (당연히) 비교도 안 될 정도로 꼼꼼히 예외 케이스들을 상정하고 미리 대응해야 했다. localStorage나 API body를 뜯어보거나, cookie에 심어지는 인증 token을 고의로 삭제해본다거나 하는 경우를 포함해서 말이다.

최대 3명이 들어갈 수 있는 공유사물함에 4명 이상이 동시에 대여 요청을 보내는 경우, 로그인해서 대여한 후 로그아웃하지 않고 다른 디바이스로 로그인 및 반납한 다음 이전 디바이스에서 새로고침해보는 경우 등 실제 서비스가 아니었다면 내 수준에서 상정해보지 못했을 케이스들을 고민하고 테스트해보는 과정에서 내 코드의 허점을 찾아낼 수 있었다.

사실 서비스의 뼈대를 구현하는 건 사용할 기술 스택의 기본적인 개념들을 이해하는 것만으로도 얼추 가능하다. 서비스를 완성한 다음 없는 버그도 만들어낼 기세로 테스트해봐야 그 개념들을 응용하고 더 깊이 이해할 수 있다는 것을 배웠다.

🎉 마무리

개인적인 웹 프로젝트는 작게 몇 개 시도해봤지만, 왜 팀 프로젝트 경험이 그렇게나 강조되어 왔는지 직접 해보고서야 깨달았다.

사실 5월에 라피신을 갓 마쳤을 때까지만 해도 '난 지금껏 혼자 잘 해왔는데, 꼭 사람들이랑 같이 해봐야만 할까?' 라는 궁금증이 작게나마 남아 있었다. 월등히 늘어나는 작업량과 그로 인한 분업, 효율적인 분업을 위한 협력과 소통 역량까지. 팀 프로젝트를 해봐야만 경험할 수 있는 귀중한 자산들이 있다는 것을 이제는 확실히 알게 되었다.

개발을 대하는 관점 자체가 크게 달라진 두 달이자, 무엇보다 정말 좋은 팀원들과 함께해서 더욱 즐겁고 열정적으로 참여할 수 있었던 프로젝트였다!

---

1인분은 할 수 있을까 자신감 없었던 저를 잘 이끌어주신 팀원들께 감사를 전하며, 이만 회고를 마칩니다. 읽어주셔서 감사합니다 😆