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

들어가며

그룹 활동 측면에서는 수월한 한 주였다. 지난주 겪었던 브랜치 전략 문제를 팀원들과 논의해 개선했고, PR 라벨을 정비하면서 git 관리 효율도 높아졌다. 기능 개발에도 속도가 붙어 2주차 목표를 대부분 달성했고, 미흡한 테스트 코드는 주말 동안 전체 흐름을 점검하며 보완할 예정이다. 목요일에는 지난 겨울부터 진행해온 졸업 프로젝트의 전시가 있었는데, 적은 인원으로 우여곡절이 많았지만 장려상까지 받으며 좋은 결과로 마무리되었다.

세 목표는 이뤘지만 태스크 정의에는 운이 따랐다

이전 브랜치 전략과 새로운 브랜치 전략을 비교하며 장단점을 취합해 개선하고, 누가 맡아서 하더라도 구현이 비슷하게 되도록 태스크를 구체적으로 정의하고, 다 함께 학습하고 공유할 수 있는 환경을 만드는 것이 이번 주 목표였다.

팀원들의 노력 덕분에 세 목표 모두 달성했다. 지난주에 느꼈던 불편한 점들을 개선했고 두 방식을 비교해 정리해두었다. 학습 정리는 강제 사항이 아니어서 자칫 소홀해질 수 있었지만 한 명도 빠짐없이 참여해 의미 있는 내용을 함께 공유할 수 있었다.

태스크를 구체적으로 정의하는 과정이 지난주보다 수월했던 건, 사실 잘했다기보다 운이 좋았던 결과에 가깝다고 생각한다. 지난주보다 설정에 들인 시간은 적었지만 작업 자체가 명확하게 주어져 자연스럽게 진행됐을 뿐이다. 다음 주에는 이런 우연에 의존하지 않고 태스크 설정 과정에 더 신중함을 기하려 한다. 학습 공유는 지난주 고민 끝에 노션에 전용 페이지를 만들어 체계적으로 관리하기 시작했는데, 덕분에 각자 정리한 내용을 쉽게 공유할 수 있었고 단순한 구현을 넘어 개념적인 이해를 다시 생각해볼 기회가 되었다.

다른 팀에서 ADR 방식을 활용해 만든 학습 공유 템플릿을 보고, 논의 끝에 우리 팀에도 이를 적용해보기로 했다. 다만 템플릿과 방식에 지나치게 얽매여 본질인 학습 공유의 의미가 흐려지지 않도록 주의해야 할 것이다.

점진적 설계가 순환 참조로 돌아오다

백엔드 설계는 한 사이클 단위로 필요한 부분만 설계하며 점진적으로 기능을 추가해 나가는 방식을 택했다. 그런데 사이클마다 새 기능이 붙을수록 의존성이 복잡해지고 리팩토링 때 수정할 부분이 많아졌다. 방식 자체에 의문이 들어 피어세션에서 다른 팀의 설계 과정을 물어보니, 다른 팀들은 1주차에 백엔드 기본 모듈 구조부터 확실히 잡은 덕분에 구현이 계획대로 순조롭게 진행되고 있었다.

우리 쪽이 힘들었던 이유는 백엔드 경험이 부족해 전체적인 흐름과 그림을 그리는 것 자체가 쉽지 않았기 때문이다. "그래서 이렇게 되지 않을까요?" 정도의 추상적인 개념만 잡고 시작했고, 설계에 집중하기보다 "이후에 추가하면서 생각해보자"는 식으로 넘어간 지점이 많았다. 시간이 오래 걸리더라도 전체적인 설계를 먼저 마치고 시작했어야 했는데, 뒤늦게 모듈을 추가하면서 순환 참조 같은 여러 이슈가 발생했다. 미리 모듈 간 관계를 고려하고 설계도를 그려봤다면 이런 문제가 줄었을 것이다. 다음부터는 기본 모듈 구조만이라도 미리 설계한 뒤 시작할 계획이다.

피어세션에서는 각 기술마다 고유한 구조 방식이 있다는 이야기도 들었다. Nest.js는 모듈화와 의존성 주입을 중심으로 한 체계적인 아키텍처 철학을 갖고 있고, 이를 따르는 것이 올바른 사용법이다. 단순한 권장사항이 아니라 원칙에 가깝다는 느낌을 받았고, 앞으로 낯선 기술을 도입할 때는 공식 문서를 먼저 살펴보고 그 기술의 철학과 추구하는 방향을 이해한 뒤 적용해야겠다고 생각했다.

CS 지식을 뒤늦게 녹이려니 돌이킬 수 없었다

단순히 작동하는 기능을 만드는 데 그치지 않고, 기존에 학습한 CS 지식을 실제 코드에 녹여내는 것도 목표였다. 절반 정도는 해냈다고 본다. 구현 중 떠오른 CS 지식을 팀원들과 이야기하며 프로젝트에 어떻게 녹여낼 수 있을지 고민했고, 실제 동작 방식과 도입 가능성을 따져가며 선택적으로 적용했다. 특정 기술을 도입했을 때 현재 진행 과정을 모두 뒤엎어야 한다면 현재 방식과의 차이점만 정리했고, 도입 가능하다고 판단되면 적극적으로 시도했다.

나머지 절반이 아쉬운 이유는 이걸 초반에 조사하고 적용했어야 했다는 후회 때문이다. 요구사항이 나왔을 때 무엇을 만들지, 어떤 학습과 기능이 필요한지를 먼저 정리했어야 했는데, 기능을 하나씩 파악하며 그 위주로 설계를 진행했다. 그러다 보니 관련 개념을 충분히 고민할 여유가 없었고, 뒤늦게 적용하려니 돌이킬 수 없게 되었다. 개인 프로젝트든 그룹 프로젝트든 설계 과정은 다르지 않으니, 지금까지 익혀온 설계 과정을 그대로 녹여내야 한다는 걸 다시 확인했다.

어떤 개념들이 사용됐는지 키워드만이라도 정리해두면 좋겠다는 생각이 들었다. 키워드들을 연결해보면 새로운 키워드가 나타나고, 이를 마인드맵처럼 그려보면 전체적인 흐름이 보일 것 같다.

사전 정리와 잦은 공유로 협업의 빈틈을 메우다

지난주보다 원활한 협업을 위해 다양한 시도를 해보고 기록하는 것도 목표로 삼았다. 매일 스크럼 전에 논의할 내용을 미리 정리해두니 회의가 주제에서 벗어나지 않았고, 팀원들도 함께 신경 써준 덕분에 내가 놓친 부분까지 챙길 수 있었다. 개인 작업 시간에는 한 시간마다 슬랙으로 진행 상황을 공유해 서로의 상황과 내가 추가로 할 수 있는 일을 파악했다. 내 일정이 먼저 끝나면 문서 작업을 하거나, 막힌 팀원과 짧게 회의를 잡아 빠르게 해결하며 시간을 낭비 없이 썼다.

데모 시간과 피어세션을 효과적으로 활용하기 위해 팀원들과 데모 시나리오를 기록하고 다른 팀에게 질문할 사항도 정리했다. 특히 부족한 백엔드 부분에 대해 설계 과정, 폴더 구조, DTO 관리 방법, 데이터베이스 선택 이유 등을 질문하고 조언을 구했다. 당장 모든 내용을 적용하기는 어려워도, 이 과정을 통해 그동안 진행해온 방식과 비교하고 다음 프로젝트에서 어떻게 개선할지 함께 논의할 수 있었다.

지난 주차에 협업 과정에서 부족한 부분이 많다고 느껴 더 적극적으로 시도한 것이 주효했고, 모든 팀원이 적극적으로 참여해준 것도 큰 힘이 됐다. 각 팀의 방식이 다르기에 장단점을 파악하며 필요한 부분을 기록하고 팀과 의논해 적용하는 과정에서, 정답은 없으며 우리 팀에 맞는 방법을 선택하고 그 이유까지 함께 생각해보는 것이 중요하다는 걸 느꼈다.

속도보다 얻어야 할 것을 지키며 마지막 주차를 준비하다

적절한 작업 분배, 원활한 소통, 리팩토링, 데모와 피어세션 모두 성공적으로 해냈다. 다른 팀에 비해 작업 속도는 느린 편이지만, 이번 프로젝트에서 얻어야 할 것들을 명확히 선택하고 지켜나가고 있다는 점에서 의미가 있었다. 작업을 큰 단위로 나누고 소통보다 개인 작업에 집중하면 속도가 빨라질 거란 사실을 모두 알고 있지만, 우리의 목표는 그것이 아니기에 지금 방식대로 계속 진행하기로 했다.

다음 주면 어느덧 마지막 개발 주차다. 다음 리팩토링 팀을 위한 인수인계 자료도 준비해야 한다. 이전 담당자의 자료가 잘 정리되어 있어야 다음 담당자가 효율적으로 작업하고 프로젝트의 방향성을 잃지 않을 수 있다고 생각해, 팀 목표와 업무 방식, 프로젝트 진행 상황, 프로젝트 구조 및 아키텍처를 기록할 내용으로 먼저 정리해두었다.

마지막 주차인 만큼 CS 연결고리 퀴즈도 팀원들과 마무리하려 한다. 지금까지 학습한 내용 중 프로젝트에 녹여낸 부분을 뽑아 어떤 방식으로 적용됐고 어떤 이점이 있었는지 기록하고, 반대로 적용하지 못한 내용은 무엇이고 어디에 적용하면 좋았을지도 생각해볼 계획이다. 각자 작성해보고 종합하면 같은 내용을 학습하고도 다르게 생각하는 부분이 드러날 것 같아 궁금하다.

근거가 빠진 말에는 힘이 없다

이번 주에는 시니어 리뷰어분께 피드백을 받으며 부족한 부분을 많이 깨달았다. 특히 행위와 생각에 대한 근거가 부족하다는 지적이 크게 와닿았다. 평소에는 정확한 근거보다 추측에 가까운 말을 했고, 말끝이 항상 흐려졌다. 한 팀원이 제안한 방식을 우리 프로젝트에 적용하기엔 확신이 서지 않아 거절했던 순간이 그랬다. 당시에는 다음과 같이 답했다.

돌아보면 근거가 부족하고 말에 힘이 없었다. 근거를 더 구체적으로 담아 이야기한다면 다음과 같이 할 것이다.

API 호출 함수를 분리하여 관리하는 것은
규모가 커지고 API가 많아질 때 유지보수성과 가독성 측면에서 이점을 가져온다고 생각해요.
 
다만, API 수가 적거나 프로젝트가 작을 때는
많은 파일로 쪼개는 것이 오히려 오버헤드가 될 수 있다고 생각합니다.
 
여러 파일을 오가며 코드를 확인해야 하는 불편함이 발생하고,
단순한 수정인데도 파일 간 이동이 많아지면 오히려 개발 효율이 떨어질 수 있을 것 같습니다.
 
따라서 저희 프로젝트 규모를 생각했을 때는
API 함수들을 하나의 파일에 모아 관리하는 편이 코드 흐름을 한눈에 파악하기 쉽고,
빠르게 수정을 진행할 수 있을 것 같아요.

정리하며

앞으로는 더 많은 근거를 생각하고 지식을 쌓아 설득하는 힘을 길러야 한다. 직장은 학교가 아니다. 내가 명확하게 말하지 않아도 이해하고 받아줄 사람은 없고, 무엇보다 면접관을 설득하지 못하면 입사하지도 못한다. 작은 개념 하나에도 질문을 던지고, 직접 말로 뱉어보며 명확한 근거로 조리 있게 설명하는 습관을 들여가야겠다.