-
Notifications
You must be signed in to change notification settings - Fork 2
광현's 6주 회고
네부캠에 참여하기 전부터 저는 협업 역량을 저만의 차별점으로 만들고자 노력해왔습니다. 단순히 코드를 작성하는 것을 넘어 팀원들과 효과적으로 소통하고 함께 성장하는 개발자가 되고 싶었습니다. 이번 6주 프로젝트는 그동안 쌓아온 이 역량을 실전에서 검증하고 더욱 발전시킬 수 있는 완벽한 기회였습니다.
프로젝트 초반은 예상보다 더 큰 도전이었습니다. 서로 다른 생각을 가진 4명의 팀원들이 하나의 방향을 향해 나아가는 과정에서 많은 어려움이 있었습니다. 각자 자신의 방향으로 팀을 이끌려는 상황이 자주 발생했고, 이로 인해 초기 진행 속도는 더뎠으며 심리적 피로도도 적지 않았습니다. 하지만 팀원 모두가 '같은 방향을 바라보는 것'의 가치를 믿었기에 포기하지 않고 계속 노력했습니다. 그 결과 1-2주차의 더딘 걸음이 3-4주차에 이르러서는 놀라운 속도로 발전했습니다. 이 과정에서 저는 의견을 효과적으로 전달하는 방법을 배웠고, 진정한 의미의 협업이 무엇인지 깨달을 수 있었습니다.
이번 프로젝트를 통해 배운 "상대방의 이해를 먼저 구하는" 소통 방식을 더욱 발전시키고자 합니다. 단순히 의견을 주고받는 것을 넘어, 팀원들의 생각을 더 깊이 이해하고 효과적으로 방향성을 통일할 수 있는 커뮤니케이션 기술을 발전시키고 싶습니다. 특히 기술적 토론 상황에서 팀원들의 다양한 관점을 이끌어내고 조율하는 능력을 더욱 키우고자 합니다. 이를 통해 팀의 시너지를 극대화하는 협업 리더로 성장하는 것이 목표입니다.
베이직부터 챌린지, 멤버십까지 이어지는 과정에서 코드에 대한 설명의 중요성을 깊이 느꼈습니다. 단순히 '동작하는 코드'가 아닌, '왜 이렇게 구현했는지'를 명확히 설명할 수 있는 개발자가 되고 싶었습니다. 모든 의사결정과 구현에 명확한 근거가 있는 코드를 작성하는 것이 목표였습니다.
기술 스택 선택부터 아키텍처 설계, 세부 코드 구현까지 모든 과정에서 '근거'를 중요시했습니다. 예를 들어, 채팅 기능을 구현할 때 Redis 대신 인메모리 방식을 선택한 것도 철저한 분석 결과였습니다. 단일 인스턴스 환경에서 데이터 일관성 보장이 크게 중요하지 않았고, 6주라는 제한된 시간 내에 빠른 구현이 필요했기 때문입니다. 코드 리뷰 문화를 통해 팀원들과 각자의 구현 근거를 공유하며 서로의 시각을 넓힐 수 있었습니다. 이 과정에서 코드의 품질을 높이는 동시에 다양한 관점에서 문제를 바라보는 능력도 키울 수 있었습니다.
코드와 아키텍처 설계에 대한 근거를 더욱 체계적으로 정립하고 문서화하는 것을 목표로 합니다. 기술 스택 선택과 아키텍처 결정 과정에서 얻은 인사이트를 팀 내부에서 공유하는 것을 넘어, 기술 블로그나 컨퍼런스 발표 등을 통해 외부와도 공유하고 싶습니다. 또한 코드 리뷰 문화를 더욱 발전시켜, 팀원들과 함께 성장할 수 있는 학습 환경을 만들어가고자 합니다. 이를 통해 기술적 의사결정의 깊이를 더하고, 더 견고한 시스템을 설계할 수 있는 개발자로 성장하고자 합니다.
네부캠의 커뮤니티 이벤트에서 들은 "개발자는 문제를 정의하고 해결하는 사람"이라는 말에 큰 영감을 받았습니다. 단순한 코더가 아닌 진정한 개발자로서, 주어진 문제를 정확히 파악하고 제한된 시간 내에 최적의 해결책을 찾아내는 능력을 키우고 싶었습니다.
영상이라는 새로운 도메인에 대한 도전은 쉽지 않았습니다. 처음에는 각 기능의 구현 시간을 예측하는 것조차 어려웠습니다. 이를 해결하기 위해 우리는 프로토타입 개발과 학습을 병행했고, 이를 바탕으로 팀만의 가설을 세웠습니다. 중요한 것은 오랜 고민보다는 빠른 검증이었습니다. 여러 가설 중 가장 적절해 보이는 것을 선택하고 바로 검증하는 방식을 택했습니다. 이런 결단력 있는 접근 덕분에 시간 지연을 최소화할 수 있었고, 5주차에 이르러서는 초기 백로그의 대부분을 완료할 수 있었습니다. 이는 우리 팀에게도 놀라운 성과였습니다.
프로토타입 기반의 빠른 검증 방식을 더욱 체계화하여, 새로운 도메인에 접근할 때 활용할 수 있는 프레임워크로 발전시키고 싶습니다. 특히 초기 학습 단계에서의 시간 비용을 최적화하는 방법을 연구하고, 팀 전체의 학습 효율성을 높일 수 있는 방안을 모색하고자 합니다. 또한 "빠른 의사결정"과 "품질 보장" 사이의 최적의 균형점을 찾는 노하우를 발전시켜, 어떤 상황에서도 효과적으로 문제를 해결할 수 있는 개발자로 성장하고 싶습니다.
- Mediasoup 포트 매핑 문제
- swagger 같은 응답 코드에 다양한 응답 보여주기
- Sudo가 계속 비밀번호를 요청함
- Docker 이미지가 너무 크다
- Git action에서 도커 이미지 빌드 시간을 단축시켜보자
- Docker compose를 이용해서 메모리 사용률을 줄여보자
- 방송 녹화 시 CPU 과부하 문제를 해결해보자
- Release 브랜치? 너 필요해?
- 로딩이 너무 짧아…!
- NestJS ORM으로 무엇을 사용해야 할까?
- WebRTC를 이용한 1:N 스트리밍 서비스에서 시그널링 서버가 필요할까?
- 실시간 채팅 구현: 인메모리 방식을 선택한 이유
- MySQL 아키텍처 개선: DB 의존성 분리와 서버 역할 명확화
- 브라우저 창이 최소화되면 비디오 송출이 안된다…!
- Mediasoup 기본 개념
- DLTS와 Signaling
- Tell, Don't Ask (TDA) 원칙이란
- VPC(Virtual Private Cloud) 학습 정리
- 순환참조: A 서비스 ‐ B 서비스 vs. A 서비스 ‐ B 레포지토리
- Dto 메서드 전략
- WebRTC란?
- 자바스크립트 패키지 매니저(npm, yarn, pnpm)
- shadcn/ui을 이용해 UI 개발 생산성 높이기
- React 이벤트 핸들러 네이밍(on vs handle)
- React-router-dom의 createBrowserRouter을 사용해보기
- fetch vs axios