[네이버부스트캠프 웹・모바일 10기] 멤버십 18주차 회고
- 네이버부스트캠프
- 회고
들어가며
그룹 프로젝트 2주 차까지 기획과 검증을 마치고, 이번 주부터 본격적인 개발에 돌입했다. 새로운 협업 규칙들과 오랜만의 개발 환경이 처음엔 다소 낯설었지만, 예상보다 빠르게 적응할 수 있었다. 팀원들도 각자 맡은 업무에 적극적으로 임해주었고, 시간이 지날수록 팀 전체의 속도도 붙기 시작했다. 개발 첫 주치고는 만족스러운 출발이었다.
이번 주에는 도움이 정말 많이 된 활동들도 있었다. 2시간 동안 진행한 기술 공유 세션에서 이번 주 핵심 작업과 학습한 내용들을 팀 내에서 나누었고, 주간 회고 시간에는 잘된 점과 아쉬웠던 점을 함께 이야기하며 개선 방향을 논의했다. 처음에는 코딩 시간이 줄어드는 것이 부담스러울 수도 있었지만, 오히려 이런 시간들이 훨씬 더 값지게 느껴졌다. 누군가 이 시간을 없애자고 한다면 아쉬울 정도로 소중한 경험이었다.
할 일 목록이 아닌 목적과 스토리로 목표를 세우다
이번 주 목표는 다음과 같았다.
- Vercel CD, 전체 CI/CD 구축, 서버 인프라 NCP 이전
- API 명세 작성, socket 이벤트 상수 패키지 정리와 문서화
- 강의실 생성/진행 페이지를 포함한 전체 페이지 UI 구현
- 지표 설계, 모니터링 도입 후 대시보드 세팅
- 전체 아키텍처 구조 정리, mediasoup와 AI의 NCP 연동
많은 부분을 달성했지만 모든 목표를 마무리하지는 못했다. 그런데 돌아보니 무엇을 놓쳤나보다 목표를 어떻게 세웠나가 더 마음에 걸렸다. 충분한 논의 없이 '이번 주엔 이걸 해야겠다'는 작업 목록을 나열한 수준에 그쳤고, 태스크들은 하나의 방향으로 모이지 못했다. 그러다 보니 남은 건 '무엇을 더 잘할 수 있었나'가 아니라 '못한 걸 마저 해야겠다'는 생각뿐이었고, 목표가 다음 주를 위한 피드백으로 이어지지 못했다.
영역별로 나열하는 대신 목적과 스토리를 중심으로 묶었다면 어땠을까.
이렇게 묶으면 각 작업이 하나의 서비스 경험을 완성하는 과정으로 이어진다. '데모 시연을 위하여'라는 목적이 있으면 '데모에서 꼭 보여줘야 하는가'라는 질문으로 우선순위를 가를 수 있고, 사용자 입장의 완결성을 검증할 기준도 생긴다. 다음 주에는 '남은 UI를 구현한다' 대신 '데모 시연을 위하여 강의실 입장부터 나가기까지의 흐름을 완성한다'처럼 목표를 세워보려 한다. 주간 목표가 분명하면 이번 주처럼 생각나는 대로 움직이지 않고, 진행 상황에 맞춰 일간 목표도 구체적으로 세울 수 있을 것이다.
안건 없는 회의가 시간을 잡아먹다
목요일에 다른 캠퍼가 회의 시간에 딴소리하는 팀원, 고칠 수 있을까요 | 요즘IT라는 글을 공유해줬다. '개발팀의 시간은 곧 비용입니다', '준비되지 않은 회의'라는 도입부부터, 다른 이야기로 논의 시간이 줄어 급한 결정을 내린다는 대목까지 공감되는 내용이 많았다. 놀랍게도 글에 나온 예시 상황은 모두 겪어본 적이 있었다. 학부생 시절의 나는 눈치를 많이 보면서도 표정을 숨기지 못하는 타입이라, 안건에서 벗어나면 표정은 굳었지만 분위기를 망치고 싶지 않아 아무 말도 못 했다. 결국 시간에 쫓겨 안건은 급하게 결정되고 뒤늦게 문제가 터지는 일이 반복되었다.
부스트캠프를 거치며 많이 개선되었다고 생각하지만, 이번 주에도 회의 안건이 명확하지 않을 때가 많았다. 스크럼이 끝나고 안건이 없어도 아무것도 정하지 않은 채 줌을 나가는 게 이질적으로 느껴져 회의를 이어갔고, 그렇게 영양가 없는 고민으로 10~20분은 낭비되지 않았을까 싶다. 앞으로는 전날 어떤 이야기가 오가야 하고 무엇을 확정해야 하는지 안건을 미리 정리하고, 정할 내용이 없다면 회의를 빠르게 끝낼 것이다.
글에서 특히 어렵게 다가온 부분은 가치를 알게 하기, 즉 전체의 목표와 개인의 목표가 다를 때 이 충돌을 해결하는 방법이었다. 공적인 공간에서는 아닌 것은 아니라고 단호하게 설득할 줄 알아야 하는데, 그러려면 상대방의 맥락과 회의 전체의 흐름을 멀리서 넓게 바라볼 줄 알아야 해서 쉽지 않다. 글의 말미에도 나오듯, 회의에 대한 무언가 생각이 들 때는 다른 사람들의 말과 시선보다 회의 시스템 자체를 돌아봐야 한다.
벌어지는 간극을 기술 공유로 메우다
운이 좋게도 경험 많고 실력도 뛰어난 팀원들을 만나 프로젝트를 진행하고 있다. 처음에는 못 따라가면 어쩌지 하는 막연한 고민이었는데, 개발이 진행될수록 점차 구체화되어갔다. 마지막 프로젝트인 만큼 각자 지향하는 분야의 태스크를 가져가면서 전문성에 맞는 다양한 도구와 서로 다른 개발 스타일이 더해졌고, 다른 팀원들의 작업을 살펴보려던 시도는 어느 순간 내 손에 담을 수 없을 만큼 범위가 커져버렸다. 프론트엔드를 지향해온 탓에 백엔드 지식은 부스트캠프에서 경험한 개발과 배포에 멈춰 있었고, 모니터링 같은 영역은 다른 팀원의 도움을 받아 겨우 따라잡고 있다. 그렇게 다른 팀원들과의 간극이 벌어진 느낌이 들었다.
이전 프로젝트에서는 오로지 내 할 일만 해왔기에 다른 파트는 전혀 신경 쓰이지 않았는데, 이번은 달랐다. 프로젝트에 대한 애정도 있고 전체 흐름을 이해해보자는 개인적인 목표가 있었기 때문이다. 끝날 때쯤엔 어느 정도 꼭 이해하고 싶다는 갈망과, 내 태스크도 벅찬데 가능할까 싶은 불안함이 공존했다.
이 간극을 줄이기 위한 방법은 기술 공유가 활발하게 이루어지는 것이라고 판단했다. 검색해서 찾은 글보다 직접 개발하는 우리가 쓴 글이 가장 이해하기 좋은 자료이고, 기술 내용이나 트러블슈팅, 적어도 전체 흐름 정도만 공유해도 간극을 줄일 수 있을 것이다. 다행히 팀원 모두가 열심히 기록하고 공유해줬다. 앞으로도 매주 기술 공유 시간을 가지며, 이해되지 않는 부분은 문서를 읽고 질문하면서 프로젝트에 대한 확실한 이해를 안고 마무리 짓고자 한다.

정리하며
잘하는 부분을 더 잘하게 만들어라는 말을 많이 듣는다. 그러기 위해 앞으로 나아가고 있는데 문득 그렇다면 못하는 부분은 어떻게 해야 하는 걸까 하는 생각이 들었다. 당연히 못하는 부분도 잘하게 만들어야 하지만, 느끼기로는 잘하는 것과 못하는 것을 끌어올리는 방법이 조금씩 다른 것 같다. 해오던 방식을 못하는 부분에도 동일하게 적용하려 하니 쉽지 않은 부분이 있었다. 그래서 상황에 따라 다른 전략이 필요하다고 보고, 이번에는 부족한 부분들을 팀 내 기술 공유를 통해 보강해보려 한다. 생각만큼 잘될지는 모르겠지만 한번 도전해보려 한다.
반대로 팀에 기여할 수 있는 방법은 무엇일까, 팀 내에서 나만이 가지고 있는 것은 무엇일까 고민해봤을 때 목소리라고 생각했다. 팀에서 주로 말을 건네고 회의를 진행하는 것이 나이니, 내 목소리가 팀에 영향을 준다는 뜻이다. 그렇다면 상황 판단력을 키우고 전체적인 그림을 볼 줄 알아야 한다. 더 넓게 팀의 계획을 다잡고 방향을 이끌어야 한다. 잘못된 방향으로 간다면 당연히 팀원들이 잘 고쳐줄 것이라 믿지만, 그러기 위해서는 우선 방향을 제시하고 나아가야 한다. 더 멀리서 팀을 바라보고 미래를 내다보려 해보자. 지금까지 잘해왔고 앞으로도 잘할 수 있을 것이다.