부스트캠프 웹・모바일 9기 멤버십
부스트캠프 멤버십 과정을 수료했다.
이렇게 학습의 방향성을 잃고 방황하던 중, 앞으로 걸어갈 길을 명확히 하고자 입과했던 약 5개월 간의 부스트 캠프 과정이 마무리 되었다.
멤버십 과정 동안의 기억이 휘발되기 전에 내가 느끼고 배웠던 것들을 기록하고자 한다.
1차 학습 스프린트
4주 동안 주어진 기능 명세에 따라, UI부터 API까지 모두 직접 개발하는 과정이었다.
React, NestJS, MySQL 등 프로젝트에서 흔히 사용되는 기술 스택이 아닌, 더욱 기초적인 VanilaJS, ExpressJS, lowDB를 사용해야 하는 제약을 제외하면, 전반적으로 캠퍼가 원하는 방향으로 개발을 진행할 수 있었다.
나는 지금까지 백엔드 개발을 주로 학습해왔기 때문에, 평소 관심이 있었던 템플릿 엔진에 대해 학습하고 싶었고, 이를 위해 SSR 구조의 설계로 스프린트를 진행했다.
✅ 시야를 넓게
API 위주의 개발만을 하다가, 웹 서비스 전체를 개발하려고 하니 고민되는 부분이 한둘이 아니었다.
어떤 기능 하나를 구현하더라도 이를 클라이언트에서 처리해야 할 지, 서버에서 처리해야 할 지에 대한 고민이 늘 따라다녔다.
그런 고민을 글로 남기기도 하며, 서버에만 국한되어있던 시야를 웹 서비스 전체로 넓힐 수 있었다.
[아키텍처] 활동 기록 데이터는 어디서 처리하는 것이 좋을까 ?
2차 학습 스프린트
4주 동안 순수 JS만으로 WAS를 구현하는 과정이었다.
HTTP Request를 직접 파싱하고 비즈니스 로직과 매핑하거나, ORM 없이 DB와 상호작용하는 로직을 구현해야 했다.
✅ 학습은 깊게
WAS를 처음부터 구현하기 위해서는 생각보다 많은 것들을 학습하고 고민해야 했다.
- HTTP Message의 구조와 각 부분의 역할
- 여러 Chunk로 나뉘어 전송되는 Multipart 형식의 HTTP Request를 처리하는 방법
- Redirect 동작 과정
- 프레임워크가 HTTP Request와 API를 매핑하는 방법
- 프레임워크가 DI를 처리하는 방법
- 프레임워크가 미들웨어(필터)를 처리하는 방법 등등 …
지금까지 다수의 프로젝트를 진행하며, 기술을 공부할 때 사용법 위주로 학습을 해왔다.
하지만, WAS를 구현하기 위해 동작 원리를 탐구하는 과정에서 동작 원리에 대한 이해의 중요성을 깨달을 수 있었다.
기술의 사용법은 무궁무진하고, 유사한 기능의 도구들 또한 굉장히 많다.
동작 원리를 이해하지 못하면, 늘 달라지는 상황에 맞추어 적절한 방식으로 응용할 수 없고, 여러 대안 중 적절한 도구를 선택할 수 없다.
반대로 동작 원리를 이해하면, 도구의 제약으로부터 벗어날 수 있겠다는 것을 느꼈다.
✅ 좋은 코드
멘토님, 동료 캠퍼들과 코드 리뷰를 진행하며, 좋은 코드에 대해 깊게 고민해볼 수 있었다.
좋은 코드의 기준은 상황에 따라 늘 달라지고, 다양한 코드 작성 방식들이 trade-off 관계에 있음을 이해해야 한다는 생각이 들었다.
이전에는 ‘어떻게 코드를 작성하는 것이 정답일까 ?’ 에 대해 고민했었지만, 최근에는 ‘이런 방식엔 어떤 장단점이 있을까 ?’ 에 대해 고민하고 있다.
매일 주고 받았던 코드리뷰
멘토님의 정성스러운 코드리뷰 🥲
하지만, 어떤 상황이든 기본적으로 지켜져야 할 원칙도 있었다.
피드백을 받는 과정에서 지속적으로 언급되는 내용들이 있었고, 이를 정리해본 결과 6가지의 기본적인 원칙을 추출할 수 있었다.
- 정상적으로 동작해야 한다.
- 일관성이 지켜져야 한다.
- 관심사가 묶여야 한다.
- 스코프를 신경써야 한다.
- 이해하기 쉬워야 한다.
- 확장성이 있어야 한다.
코드를 작성할 때마다 이 원칙들을 상기하고, 최대한 지키려고 노력하고자 한다.
그룹 프로젝트
마지막으로 6주 간의 그룹 프로젝트를 진행했다.
우리 팀은 “실시간”이라는 주제를 희망하는 팀원들로 구성되어있었고, 최종적으로 실시간 프로젝트 일정 관리 서비스인 Harmony를 개발하게 되었다.
우리 팀은 명확한 근거 기반의 기술 선택, 꼼꼼한 문서화를 목표로 프로젝트를 진행했다.
Harmony Github 바로가기
Harmony Notion 바로가기
✅ “팀” 프로젝트
처음 프로젝트를 진행할 때는 어떤 기술적 도전을 해야 할 지에 대해서만 집중했었다.
하지만, 프로젝트를 진행하면 할 수록 팀 프로젝트에는 팀 프로젝트에서만 할 수 있는 경험이 분명히 있다는 생각이 들었다.
- 나를 포함한 팀원들이 컨벤션을 잘 지킬 수 있는 환경 구성
- Lint, Pretier 설정과 husky를 활용한 컨벤션 검사 자동화
- 다른 팀원의 작업 내용도 내가 맡은 부분만큼 이해하고 문제에 대응할 수 있도록 환경 구성
- 재사용성이 높고, 코드 전반에 걸쳐 사용되는 기능은 페어 프로그래밍 진행
- 과반수 이상의 코드 리뷰와 approve를 받아야 머지 할 수 있도록 설정
- 같은 파트 팀원의 pr은 필수적으로 코드 리뷰 진행
- 학습 정리 공유를 통해, 팀 단위의 학습에 드는 시간을 줄여 생산성 향상
위와 같이 다양한 협업 방식에 대한 경험을 할 수 있었고, 이는 팀 프로젝트를 바라보는 시각이 달라지게 된 계기가 되었다.
✅ 좋은 협업
6주 간 매일 10시간 이상 협업을 진행하며, 좋은 협업에 대한 생각을 많이 하게 되었고, 나름의 깨달음을 얻었다.
1. 적극적인 의견 제시
분위기가 안좋아질까봐, 좋은 게 좋은 거니까 그냥 넘어가지 말고 나에게 필요한 게 있거나 잘못 되었다고 생각하는 게 있다면 적극적으로 주장하자.
그 사이를 함께 조율할 수 있는 게 커뮤니케이션을 잘 하는 것이지, 그런 일이 발생하지 않도록 하는 건 회피일 수도 있다.
2. 생산성
기본적으로 여러 명이 함께 일하면 설계 및 구현에 대해 논의하거나, 의견을 조율하는데 시간이 걸리다 보니, 혼자 일하는 것보다 생산성이 떨어질 수 있다.
처음에는 더 안정적인 의사 결정과 제품의 퀄리티를 높일 수 있는 방식이니, 생산성 저하는 어쩔 수 없는 일이라고 생각 했었다.
하지만 여기서 멈추지 않고, 빠른 의사 결정을 통해 생산성까지 높일 수 있는 방식으로 일할 수 있어야 진짜 좋은 협업이 아닐까.
그래서 앞으로 …
많이 배우고, 많은 경험을 했지만 실력이 느는 것 이상으로 나의 부족함과 마주하게 된 시간이었다.
나는 지금 절망의 계곡에 있는 것 같다.
하지만, 성장하기 위해서는 부족함을 아는 것이 먼저이지 않을까.
이제 깨달음의 오르막을 오르는 일만 남았다.
