[네이버부스트캠프 웹・모바일 10기] 멤버십 15주차 회고

  • 네이버부스트캠프
  • 회고
2025-12-06

들어가며

그룹 스프린트라는 5주간의 여정이 끝났다. 좋은 팀원들을 만나 길면서도 짧게 느껴진 시간 동안 매주 이전 주차의 경험을 바탕으로 새로운 시도를 이어갔고, 예전보다 훨씬 많은 작업과 회의를 소화했다. 자정이 넘어서까지 작업한 날도 있었지만 그 과정이 힘들기보다 즐겁고 보람찼다. 함께 성장하며 개발 자체에 대한 즐거움을 다시 느낄 수 있었다.

분위기를 띄우는 힘을 방향을 잡는 힘으로

3주차쯤, 분위기가 좋은 것과 협업을 잘하는 것은 다르다는 생각에 부딪히며 자신감이 줄어든 시기가 있었다. 팀 분위기를 띄우는 데는 자신 있었지만 이 능력이 실질적인 협업에 도움이 되는지 의문이 들었고, 오히려 집중도를 떨어뜨려 진행 속도를 늦출 수 있다는 생각에 스스로 자제하려 했다. 그러나 프로젝트를 진행하며 생각이 바뀌었고, 이 강점으로 팀의 흐름과 분위기를 동시에 살릴 방법을 찾아가기 시작했다.

팀의 분위기를 만드는 일은 각자의 모습을 하나로 모아 둥근 형태로 만들어가는 일이라고 생각했다. 처음에는 모두가 제각각의 모양을 가지고 있지만, 서로 다른 면을 맞추고 다듬어 하나의 둥근 원으로 만드는 과정이 내가 가진 강점이었다. 다만 둥근 원은 방향이 올바르면 속도가 붙으며 좋은 협업으로 이어지지만, 잘못된 방향으로 굴러가면 그만큼 멀리 벗어나 원래 길로 돌아오기 어려워진다.

제각각의 모양 맞추고 다듬기 팀 하나의 둥근 원 올바른 방향 잘못된 방향 속도가 붙어 좋은 협업으로 멀리 벗어나 돌아오기 어려움
둥글게 모인 팀은 어느 쪽으로든 빠르게 구른다. 그래서 분위기만큼 방향이 중요했다.

그래서 좋은 분위기를 유지하되 그 에너지가 올바른 방향으로 향하도록 이끄는 것이 앞으로 더 키워야 할 능력이라고 판단했다. 분위기에만 집중하면 본래 목표에서 멀어질 수 있으니, 언제든 다시 길로 돌아올 수 있는 길잡이가 되기 위해 방향성을 잃지 않으려 한다.

목표는 테스트, 회고는 리팩토링

그룹 프로젝트를 진행하며 협업도 일종의 코딩과 같다는 생각을 하게 됐다. 이전 학습 스프린트처럼 이번에도 팀이 매주 목표를 정하고 회고했는데, 이 과정이 테스트 코드의 실행과 닮아 있었다. 매주 세운 목표가 하나의 테스트라면 한 주간의 작업은 그 테스트를 통과하기 위한 실행이었고, 회고는 테스트가 통과됐는지를 확인하는 과정이었다. 통과하지 못했다면 이유를 분석해 다음 주 목표와 계획에 반영했다.

주간 목표 설정 코딩의 테스트 작성 한 주를 시작 한 주간의 작업 코딩의 테스트 실행 한 주를 마치고 주간 회고 코딩의 통과 여부 확인 통과하지 못하면 원인을 분석해 다음 주 목표에 반영
목표를 먼저 세우고 회고로 확인하는 한 주는, 테스트를 먼저 쓰고 통과 여부로 코드를 고치는 흐름과 같은 모양이었다.

코딩에서 테스트가 중요하듯 목표 설정 역시 협업의 품질을 보장하는 핵심 요소라고 생각한다. 핵심 기능이 제대로 작동하는지는 물론 예외적인 상황까지 점검해야 하고, 문서화나 학습 공유처럼 보이지 않지만 중요한 요소도 빠뜨리지 않아야 한다.

회고에서 가장 많이 돌아본 부분은 회의 방식이었다. 오랜만에 경험한 협업 프로젝트였던 만큼 팀의 진행 방식이 잘 이루어지고 있는지 많이 고민했는데, 간혹 회의가 돌고 돌아서야 결론에 도달하는 경우가 있었다. 명확한 결정 구조가 부족하거나 우선순위와 설계 방향이 모호했기 때문이라고 보고, 매주 회고에서 어떤 부분에서 불필요한 반복이 생겼는지 분석해 다음 회의에서 개선할 구체적인 실행 방안을 세웠다.

이 과정은 리팩토링과 닮아 있었다. 결과는 같더라도 불필요한 절차를 줄이고 효율적인 흐름으로 개선해나간다는 점에서 그랬다. 정기적인 리팩토링이 코드의 품질과 생산성을 높이듯, 주기적인 회고는 협업의 효율과 팀의 안정성을 높인다. 매주 꼬인 부분을 풀며 점차 더 효율적이고 안정적인 회의 문화로 발전시킬 수 있었다는 점이 큰 의미로 남았다.

문서화는 기록이 아니라 협업의 일부였다

협업 과정에서는 수많은 논의가 오간다. 규칙과 컨벤션 같은 큰 틀의 합의부터 하루 동안의 회의록이나 작업 기록까지 그 단위도 다양하다. 이번 그룹 스프린트를 진행하며 문서화가 단순히 기록을 남기는 행위가 아니라 협업의 품질을 높이는 핵심 과정임을 여러 관점에서 깨달을 수 있었다.

먼저 팀 내부에서 결정된 내용을 기록하고 관리하는 일이 중요하다. 어떤 이야기를 나눴었죠, 이 부분은 어떻게 하기로 했죠 같은 질문을 주고받을 수는 있지만, 답변을 기다리는 동안 지연이 생기고 이 질의응답 자체가 누군가에게는 또 다른 태스크가 된다. 반면 문서를 항상 최신 상태로 유지하면 필요한 정보를 즉시 찾아볼 수 있고, 한 번에 이해하지 못한 내용도 반복해서 읽으며 차근차근 이해할 수 있다. 개발에서 오버헤드를 줄이려는 것처럼, 협업에서도 문서화로 소통의 오버헤드를 줄이는 습관이 필요하다.

문서화는 팀 내부만을 위한 작업도 아니다. 이력서에 포함된 링크로 프로젝트를 살펴보는 면접관이나 다른 사람의 작업에서 인사이트를 얻으려는 개발자처럼, 팀 외부의 사람이 사전 지식 없이 문서를 찾아올 수 있다. 그렇기에 팀원 간 이해를 돕는 구조와는 별개로, 외부인이 처음부터 맥락을 따라갈 수 있도록 프로젝트의 배경과 전반적인 흐름을 차근차근 제시하는 방식이 필요하다고 생각했다.

문서화는 나 자신을 위한 과정이기도 했다. 머릿속에서는 정리되어 있다고 느껴도 막상 써 내려간 뒤 다시 읽으면 무슨 말인지 이해하기 어려울 때가 있다. 그럴 때마다 진짜 하고 싶은 말과 전달하려는 핵심이 무엇인지 스스로에게 물었고, 그 과정에서 생각이 정리되고 이해도가 깊어지며 나만의 언어로 풀어내는 연습이 됐다.

문서화 결정과 논의를 기록 기다림 없이 조회 처음부터 따라가기 다시 읽으며 점검 팀 내부 질문 대신 바로 찾아봄 팀 외부 면접관, 참고하려는 개발자 나 자신 생각이 정리되고 이해가 깊어짐
한 번 남긴 기록이 팀원의 질문을 줄이고, 외부인의 길잡이가 되고, 쓰는 사람의 생각까지 정리한다.

시간이 지나도 읽히는 문서의 조건

최종 보고서를 제출하고 시간이 지나 내가 작성한 부분을 다시 읽어보니 아쉬운 점이 눈에 띄었다. 작성 당시에는 머릿속에 정보가 많아 어떤 내용을 담으려 했는지 명확했지만, 맥락이 사라지고 나니 문서만으로는 내용을 온전히 이해하기 어려웠다.

그래서 문서에 담아야 할 세 가지를 정리했다. 첫째, 독자가 기본적인 맥락을 파악할 수 있도록 작성 배경과 핵심 내용에 대한 간단한 설명이 먼저 와야 한다. 둘째, 본문은 불필요하게 함축하거나 생략하지 않고 시간이 지나 다시 읽어도 문서만 보고 이해할 수 있을 만큼 구체적으로 풀어 써야 한다. 셋째, 전체 내용이나 장단점, 향후 고려사항을 정리하는 결론이 있어야 완성도 높은 문서가 된다.

이번에 작성한 리팩토링 문서를 다시 구상한다면 배경, 해결 방향 설정, 구현 및 해결 과정, 개선 결과, 추가 고려사항, 결론 순으로 정리할 것 같다. 배경에는 어떤 문제와 불편함이 있었는지, 해결 방향에는 어떤 기술을 왜 선택했는지, 구현 단계에는 고민과 트러블슈팅 과정을 담는다. 개선 결과는 전후 변화를 수치나 지표로 보여주고, 추가 고려사항에서는 트레이드오프와 사용자 규모가 커질 때의 대응, 다른 대안 기술을 검토한다. 이런 구조라면 리팩토링의 의도와 성과가 명확하게 드러날 것이다.

맥락 읽기 전에 배경을 잡게 구체적인 본문 다시 읽어도 문서만으로 이해되게 결론 정리와 다음 고민까지 1. 배경 어떤 문제와 불편함이 있었나 2. 해결 방향 어떤 기술을 왜 골랐나 3. 구현 및 해결 과정 고민과 트러블슈팅 4. 개선 결과 전후 변화를 수치로 5. 추가 고려사항 트레이드오프, 규모, 대안 6. 결론 전체 내용 정리
여섯 단계는 결국 맥락, 구체적인 본문, 결론이라는 세 조건을 차례로 채우는 순서다.

개념을 아는 것과 구현에 녹이는 것은 달랐다

이번 그룹 스프린트에서 가장 잘했다고 느낀 부분은 3주에 걸쳐 특정 CS 개념을 학습하고 팀원들과 공유한 과정이었다. 첫째 주에는 외부 자료를 참고하기보다 각자의 기억과 이해를 최대한 끌어내 조합하며 개념을 정리했다. 서로 알고 있는 부분이 다르고 때로는 모두가 모르는 개념도 있어 부족한 점이 많았지만, 오히려 그 과정에서 학습에 대한 자극과 동기를 얻었다.

둘째 주에는 개념 학습과 자료 조사를 병행했다. 각자 찾아본 내용을 공유하며 하나로 정리했고, 이해가 충돌하는 부분은 함께 다시 찾아보며 정확히 짚었다. 학습 도중 새롭게 떠오른 문제들은 꼬리를 물며 논리적으로 연결해 해결하려 했다.

마지막 주에는 학습한 개념을 실제 프로젝트에 어떻게 녹여냈는지를 논의했는데, 개념을 아는 것과 그것을 구현에 적용하는 것은 전혀 다른 문제였다. 내가 인식하지 못한 부분에서 개념이 활용되고 있었고, 알고 있던 방식이 실제 코드에서는 다르게 쓰이기도 했다. 왜 이렇게 설계했는지를 서로 묻고 답하며 지식과 구현을 연결하려 노력했다.

1주차 2주차 3주차 각자의 기억 조합 외부 자료 없이 자료로 확장 개념 학습, 자료 조사 충돌하면 함께 다시 확인 코드로 연결 프로젝트 코드와 연결 왜 이렇게 설계했는지 개념을 아는 단계 구현에 적용하는 단계 전혀 다른 문제
학습의 기준이 머릿속 기억에서 자료로, 자료에서 실제 코드로 옮겨가며 개념이 구현과 이어졌다.

이 과정에서 대학 전공 강의 자료를 여러 번 다시 꺼내봤다. 그때 좀 더 공부했더라면 하는 아쉬움도 들었지만, 배운 기억이 남아 있고 다시 참고할 자료가 있다는 것 자체가 감사한 일이라고 관점을 바꿨다. 이제는 개념을 외우고 시험을 준비하는 것이 아니라, 익힌 개념을 어디에 활용할 수 있을지, 이미 쓰고 있는 방식이 어떤 이론에 기반한 것인지 고민하며 학습하려 한다. 필요할 때마다 돌아가 공부하고 적용해본 경험은 예전보다 훨씬 오래 기억에 남을 것이다.

지적 대신 질문으로, 승인은 공동의 책임으로

부스트캠프 이전까지 코드 리뷰를 해본 경험은 단 한 번뿐이었다. 돌이켜보면 그때의 리뷰가 정말 리뷰였는지 잘 모르겠다. 잘못된 부분을 짚을 때도 도움이 되기보다 틀렸다는 사실 자체에만 초점이 맞춰져 있었고, 때로는 나조차 완전히 이해하지 못한 문장으로 포장된 피드백을 남겼다. 성장보다 겉모습에 더 신경 쓴 리뷰였던 셈이다.

이번에는 부족한 점을 지적하기보다 질문을 중심으로 리뷰를 진행했다. 생각한 방향을 제시하거나 다르게 구현한 이유를 묻고, 이해되지 않는 코드에는 직접 질문을 남겼다. 더 나은 방법이 떠오르면 근거를 제시하며 함께 논의했다. 리뷰를 통해 무심코 작성했던 코드를 새로운 시각에서 바라볼 수 있었고, 다른 사람만이 볼 수 있는 세밀한 관점을 공유받을 수 있었다.

시니어 리뷰에서 "이해가 완벽하지 않은 부분이라도 일단 승인을 하고 나중에 학습해도 될까요"라고 질문한 적이 있다. 리뷰어는 승인을 했다면 그 코드의 책임은 모두에게 있다고 답했다. 코드를 승인한다는 것은 동의 버튼을 누르는 행위가 아니라 그 코드의 동작과 결과에 대한 공동의 책임을 지겠다는 의미였다. 이후 문제가 생기더라도 누군가를 탓하기보다, 함께 승인한 코드로서 팀 전체가 문제를 인식하고 개선해야 한다는 점을 깨달았다.

기억보다 추론, 의무보다 호기심

"사람은 기억을 못한다. 하지만 추론은 잘한다"는 시니어 리뷰에서 가장 인상 깊었던 문장이다. 이 말로 추상화에 대한 질문이 추상화를 해야 하는가에서 추상화했을 때 그 장점을 어떻게 극대화할 수 있는가로 확장됐다. 이전에는 코드를 감추고 싶다는 이유만으로 함수를 만들었지만, 함수 이름이 명확하지 않으면 의도를 알기 어렵고 결국 파일을 일일이 찾아가야 해서 추상화의 의미가 사라진다. 좋은 함수 이름은 함수의 역할뿐 아니라 전달받는 매개변수까지 자연스럽게 추론하게 만들고, 이런 설계가 누구나 쉽게 읽을 수 있는 코드로 이어진다고 느꼈다.

이름이 모호할 때 (예시) process(a, b, c) 의도를 몰라 파일을 열어 본문 확인 매번 반복하면 추상화의 의미가 사라짐 이름이 명확할 때 (예시) formatDate(date) 이름만 보고 역할과 매개변수를 추론 본문 없이도 누구나 쉽게 읽는 코드
함수 이름이 추론의 단서가 되어야, 감춘 본문을 다시 열어볼 필요가 없어진다.

백엔드나 배포처럼 익숙하지 않은 분야에 대한 두려움도 컸다. 프론트엔드도 충분히 공부하지 못했는데 이 부분까지 언제 배우나 싶어 조언을 구하자 "재미로 소비하듯 공부하라"는 답이 돌아왔다. 우선순위는 낮을 수 있어도 모르는 채로 넘어가서는 안 되는 부분이니, 학습에 매몰되지 말고 호기심을 가지고 가볍게 넓혀두라는 의미였다.

밥을 먹으며 유튜브를 보듯, 쇼츠 영상을 넘겨보듯 자연스럽게 접하다가 왜 이렇게 동작하는지, 이 방식의 장점은 무엇인지 같은 단순한 호기심에서 조금씩 깊이 들어가는 방식이다. 넓게 알아두면 나중에 다시 찾아갈 수 있는 지점이 생긴다는 말이 특히 인상 깊었다. 덕분에 학습에 대한 마음가짐이 한결 가벼워졌고, 공부는 해야 하는 것이 아니라 즐길 수 있는 것이라는 관점을 다시 느꼈다.

궁금증이 학습의 방향이 되다

협업을 진행하며 혼자서는 얻을 수 없었던 경험을 많이 했다. 평소에는 공식 문서나 특정 자료를 참고해 하나의 방식에 맞춰 코드를 작성했지만, 이번에는 다른 사람들의 코드를 보며 왜 이렇게 작성했는지 끊임없이 질문하는 과정에서 새로운 시각을 얻었다. 팀원마다 다른 의견 속에서 더 나은 방식을 택하고 서로를 설득해 하나로 합치는 법도 깊이 고민했다. 낯설고 두려웠던 백엔드와 배포도 도전하며 자신감을 얻었고, 이제는 두려움보다 호기심이 더 크다.

학습 방식도 달라졌다. 이전에는 주말마다 학습할 주제를 따로 정해 계획적으로 공부했다면, 이번에는 프로젝트 속에서 자연스럽게 생겨난 궁금증을 중심으로 학습을 이어갔다. 프로젝트와 직접 맞닿은 주제이니 더 깊이 고민하게 됐고, 의무감이 아니라 더 알고 싶다는 호기심으로 공부했다. 앞으로도 프로젝트에서 생긴 질문을 학습의 방향으로 삼아 스스로 성장의 루프를 만들어가려 한다.

자료 공유를 넘어 함께 설명하는 시간으로

이전까지의 팀 프로젝트에서는 함께 성장한다는 말을 각자가 한 프로젝트 안에서 따로 성장한다는 의미로 이해했다. 그래서 학습 내용을 나누기보다 자신의 학습을 이어가기에 바빴다. 이번에는 새로 배운 내용을 팀원들과 나누고 이해를 돕기 위해 문서로 정리하는 과정을 즐기게 됐고, 나 역시 팀원들에게서 많은 것을 공유받고 배웠다.

다만 자료 공유가 곧바로 성장으로 이어진다고는 생각하지 않는다. 공유된 자료가 있어도 확인하지 않거나 대충 읽고 넘기는 경우는 충분히 있고, 적어도 나는 그랬다. 어느 순간부터 슬랙에 캠퍼들이 공유하는 자료를 잘 확인하지 않게 됐다. 이번 경험으로 느낀 것은 자료를 공유하는 것보다 함께 설명하고 대화하는 시간이 훨씬 효과적이라는 점이다. 줌이나 대면으로 강제로라도 듣게 되면 자연스럽게 호기심이 생기고 질문으로 이어졌고, 이를 반복하니 학습 효과가 깊어졌다.

자료만 공유할 때 슬랙에 자료 공유 링크만 전달 각자 알아서 확인 관심이 줄면 대충 읽고 넘김 함께 설명할 때 줌, 대면으로 설명 듣다 보면 호기심이 생김 궁금한 점을 질문으로 이어짐 반복할수록 학습 효과가 깊어짐 이어지는 흐름, 연결됨(초록색) 끊기는 흐름, 실패(빨간색)
혼자 읽는 자료는 읽고 끝나지만, 함께 듣는 설명은 질문으로 이어져 다시 대화를 부른다.

다음 그룹 프로젝트에서는 팀원들이 동의한다면 프로젝트와 직접 연관된 주제로 기술 공유 시간을 정기적으로 마련하고 싶다. 슬랙에 올라오는 자료도 다시 관심을 가지고 읽고, 궁금한 점은 적극적으로 질문하려 한다. 그동안 좋은 기회들을 놓쳤다는 아쉬움이 남는다.

정리하며

멤버십을 시작한 이후로 한 걸음 물러서서 스스로를 돌아보는 회고를 꾸준히 이어왔다. 하루하루, 주차별로는 깨닫지 못했던 변화들이 5주를 한 번에 되돌아보니 보였다. 그동안 정말 많은 것을 배우고 변하기 위해 노력해왔다. 단기간에 이런 경험을 할 수 있었던 것이 감사하고, 그 길을 함께 걸어준 팀원들에게도 감사하다.

다음 주면 마지막 그룹 프로젝트가 시작된다. 이렇게 밀도 높은 협업을 오래 경험할 기회가 또 있을까 싶어, 마지막인 만큼 쏟아낼 수 있는 것을 모두 쏟을 각오로 임하려 한다. 팀원들과 공통된 목표를 세우고 끝까지 함께 달려가며 성취의 기쁨을 나누는 것이 가장 큰 목표다. 프로젝트가 마무리되는 날 함께 웃으며 소주잔을 부딪힐 수 있다면 그 어느 때보다 행복할 것 같다.