Rocky 's Blog

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

  • 네이버부스트캠프
  • 회고
2025. 11. 15.
게시글 썸네일

회고를 시작하며


이번 주는 어떻게 보냈는가?

그룹 활동 측면에서는 수월한 한 주였다. 지난주 겪었던 브랜치 전략 문제를 팀원들과 논의해 개선했고, PR 라벨을 정비하면서 git 관리 효율도 높아졌다. 기능 개발에서도 팀원들 모두 속도가 붙어 2 주차 목표를 대부분 달성했다. 테스트 코드가 미흡한 부분은 주말 동안 전체 코드 흐름을 다시 점검하며 보완할 예정이다.

목요일에는 학교 졸업 작품 전시가 있었다. 지난 겨울부터 진행해온 졸업 프로젝트가 드디어 마무리되었다. 적은 인원으로 개발하면서 우여곡절도 많았고 힘든 순간도 있었지만, 좋은 결과물로 이어져 장려상 까지 받게 되었다. 그동안의 경험들을 되돌아보며 차근차근 정리해두려 한다.

목표 설정


이번주의 목표는 무엇이었는가?
  • 이전 브랜치 전략과 새로운 브랜치 전략을 비교하며 장단점을 취합하여 개선하기
  • 누가 맡아서 하더라도 구현이 비슷하게 되도록 태스크 구체적으로 정의해보기
  • 다 함께 학습하고 공유할 수 있는 환경 만들기
  • 목표가 실제로 잘 이루졌는가?

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

    목표가 잘 이루어진 이유가 무엇일까?

    이번 주는 태스크를 구체적으로 정의하는 과정이 평소보다 수월했다. 지난주보다 설정에 들인 시간은 적었지만, 작업 자체가 명확하게 주어져 자연스럽게 진행될 수 있었다. 다만 이는 잘했다기보다 운이 좋았던 결과에 가깝다고 생각한다. 다음 주에는 이런 우연에 의존하지 않고, 태스크 설정 과정에 더 신중함을 기하려 한다.

    지난주에는 학습 공유를 어떻게 효과적으로 활용할지 고민하다가, 이번 주에는 노션에 전용 페이지를 만들어 체계적으로 관리했다. 덕분에 각자 정리한 내용을 쉽게 공유할 수 있었고, 단순한 구현을 넘어 개념적인 이해를 깊이 있게 다시 생각해볼 수 있는 기회가 되었다.

    한 걸음 더 나아가서

    다른 팀에서 ADR 방식을 활용해 만든 학습 공유 템플릿을 보았다. 작성된 내용을 읽어보니 흐름이 명확해 글이 매우 읽기 편했다. 팀원들과 함께 내용을 살펴보고 논의를 거친 끝에, 우리 팀에도 이를 적용해보기로 했다. 다만, 템플릿과 방식에 지나치게 얽매여 본질인 학습 공유 의 의미가 흐려지지 않도록 주의해야 할 것이다.

    점진적 설계 방식의 한계


    설계 과정에서의 목표는 무엇인가?

    한 사이클 단위로 각 단계에서 필요한 설계를 진행하며 점진적으로 기능을 추가해 나간다. 전체적인 흐름을 빠르게 잡기보다는, 현재 필요한 기능을 중심으로 설계를 진행하며 점진적으로 완성도를 높이고자 했다.

    목표가 실제로 잘 이루졌는가?

    점진적으로 기능을 추가해나가는 방식을 꾸준히 이어왔다. 하지만, 매 사이클마다 새로운 기능을 추가하다 보니 의존성이 복잡해지고 리팩토링 과정에서 수정할 부분이 많아졌다. 이런 방식이 적절하지 않다고 느껴 피어 세션에서 다른 팀의 백엔드 설계 과정을 물어보았다.

    다른 팀들은 우리와는 달리, 1주차 초기 설계 단계에서 백엔드 기본 모듈 구조를 먼저 확실히 잡은 후 진행했다. 그 결과 구현이 계획대로 순조롭게 진행되는 모습을 보였다. 그러한 이유와 다른 설계 관련 사항들도 물어보았는데, 아무래도 목표 설정이 잘못되었던 것 같다.

    목표가 잘 이루어지지 않은 이유가 무엇일까?

    다른 팀에 비해 백엔드 경험이 부족해 전체적인 흐름과 그림을 그리는 것이 쉽지 않았다. 그래서 이렇게 되지 않을까요? 같은 추상적인 개념만 잡고 시작했던 것 같다. 또한 설계에만 집중하기보다 이후에 추가하면서 생각해보자 는 식으로 정리하고 넘어갔다.

    시간이 오래 걸리더라도 전체적인 설계를 먼저 마치고 시작했어야 했다. 우리는 뒤늦게 모듈을 추가하면서 순환 참조 같은 여러 이슈가 발생했다. 미리 모듈 간 관계를 고려하고 설계도 그려봤다면 이런 문제가 줄었을 것이다. 다음부터는 기본 모듈 구조라도 미리 설계한 후 시작할 계획이다.

    한 걸음 더 나아가서

    피어세션에서 각 기술마다 고유한 구조 방식이 있다는 이야기를 들었다. 예를 들어 Nest.js는 모듈화와 의존성 주입을 중심으로 한 체계적인 아키텍처 철학이 있고, 이를 따르는 것이 올바른 사용법이다.

    이는 단순한 권장사항이 아니라 원칙에 가깝다는 느낌을 받았다. 다음부터는 낯선 기술을 도입할 때 공식 문서를 먼저 살펴보고, 그 기술의 철학과 추구하는 방향을 이해한 뒤 적용하는 것이 도움이 될 것 같다.

    알고있는 지식을 어떻게 적용할 것인가?


    구현하는 과정에서 목표는 무엇인가?

    단순히 작동하는 기능을 만드는 데 그치지 않고, 기존에 학습한 CS 지식을 실제 코드에 녹여내자.

    목표가 실제로 잘 이루었는가?

    50% 라고 생각한다. 50% 성공한 이유 는 구현 중 떠오른 CS 지식을 팀원들과 함께 이야기하며 프로젝트에 어떻게 녹여낼 수 있을지 고민했기 때문이다. 실제 동작 방식과 프로젝트 도입 가능성을 따져가며 선택적으로 적용했다. 예를 들어, 특정 기술을 도입했을 때 현재 진행 과정을 모두 뒤엎어야 한다면 현재 방식과의 차이점만 정리했고, 도입 가능하다고 판단되면 적극적으로 시도했다.

    반대로 50% 실패한 이유 는 초반에 이를 조사하고 적용했더라면 더 좋았을 것이라는 생각 때문이다. 팀 내부적으로 미리 조사해보고 적용 방안을 고민하는 시간을 가졌더라면 뒤늦은 수정도 줄고 개선할 수 있는 부분도 많았을 것이다.

    목표가 잘 이루어지지 않은 이유는 무엇인가?

    요구사항이 나왔을 때 설계 순서를 정리하고 시작했어야 했다. 예를 들어, 현재 만들고자 하는 것은 무엇인지어떤 학습이 필요한지어떤 기능이 사용되는지 를 순차적으로 정리하며 나아갔어야 했다. 하지만 우선 기능을 하나씩 정리하며 프로젝트를 이해해보자는 식으로 접근했고, 이후 해당 기능 위주로 설계를 진행했다.

    따라서 관련 개념을 찾아보는 시간이 부족했고, 이에 대해 충분히 생각해볼 여유도 없었다. 뒤늦게 적용하려니 돌이킬 수 없는 상황이 되었다. 생각해본다면, 이전 개인 프로젝트와 지금의 그룹 프로젝트 모두 설계 과정은 크게 다르지 않다. 단지 개인이냐 팀이냐만 다를 뿐이다. 지금까지 익혀온 설계 과정을 잘 녹여내야 한다.

    설계의 중요성을 간과하지 말자. 올바른 설계가 있어야 구현이 제대로 따라올 수 있다. 어떤 개념들이 활용될지 파악하는 시간도 필요하다. 그렇지 않다면 이전부터 걱정해온 공장처럼 찍어내는 개발과 무엇이 다르겠는가.

    한 걸음 더 나아가서

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

    더 나은 협업을 위하여


    협업 과정에서의 목표는 무엇인가?

    지난주보다 더 원활하고 효율적인 협업을 위해 다양한 시도를 해보고 기록하자.

    목표가 실제로 잘 이루졌는가?

    매일 스크럼 전에 논의할 내용을 정리했다. 간략하게라도 어떤 순서로 이야기를 진행할지 생각해봤고, 이를 통해 회의 주제에서 벗어나지 않고 효율적으로 진행할 수 있었다. 다른 팀원들도 이런 부분을 신경 써줘서 내가 놓친 부분까지 챙길 수 있었다.

    개인 작업 시간에는 한 시간마다 슬랙에서 진행 상황을 공유하기로 했다. 서로의 진행 상황을 파악하고 내가 해야 할 일과 추가로 할 수 있는 일을 파악할 수 있었다. 예를 들어, 내 일정이 먼저 끝나면 문서 작업을 추가로 하는 등 시간을 효율적으로 활용했다. 또한 어려움을 겪는 팀원이 있으면 짧게라도 회의를 잡아 빠르게 해결해나갔다. 다음 회의 시간 설정에도 도움이 많이 되어 중간에 시간이 낭비되지 않았다.

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

    목표가 잘 이루어진 이유가 무엇일까?

    이전 주차에 협업 과정에서 부족한 부분이 많다고 느껴 더 적극적으로 시도했다. 또한 모든 팀원이 적극적으로 참여해줘서 잘 이루어질 수 있었다. 피어세션을 통해 다른 팀의 진행 과정을 참고하거나 조언을 구할 수 있는 점도 큰 도움이 되었다.

    특히 피어세션 초반부에 각 팀의 진행 과정을 물어보곤 하는데, 모든 팀의 방식이 다르기에 장단점을 파악하며 필요한 부분을 기록하고 팀과 의논해 적용하는 과정이 유익했다.

    한 걸음 더 나아가서

    각 팀은 개인들이 모여 다양한 방법을 시도할 것이고, 그 방법에는 정답이 없다. 장점만 있는 것이 아니라 단점도 분명히 존재한다. 이러한 점을 유의하며 우리 팀에 맞는 방법을 선택하는 것이 중요하다. 그리고 그렇게 선택한 이유도 함께 생각해보면 좋을 것이다.

    다음 주에 시도해볼 내용


    이번 주를 정리해보자면?

    적절한 작업 분배, 원활한 소통, 리팩토링, 데모와 피어세션 모두 성공적으로 이루었다. 다른 팀에 비해 작업 속도는 느린 편이지만, 우리 팀이 이번 프로젝트에서 얻어야 할 것들을 명확히 선택하고 지켜나가고 있다는 점에서 의미가 있다.

    작업을 큰 단위로 나누고 소통보다 개인 작업에 집중한다면, 속도가 빨라질 것임을 모두 알고 있고 이야기도 나눴다. 하지만 우리의 목표는 그것이 아니기에 모두가 이에 맞춰 잘 진행하고 있다고 생각한다.

    다음 주를 위해서 준비한 내용이 있어?

    다음 주면 어느덧 마지막 개발 주차다. 이에 따라 다음 리팩토링 팀을 위한 체계적인 정리 작업도 슬슬 준비해야한다. 실제 업무 환경을 고려하면, 이전 담당자의 인수인계 자료가 잘 정리되어 있어야만 다음 담당자가 효율적으로 작업할 수 있고, 프로젝트의 방향성을 잃지 않을 수 있다. 이러한 과정도 개발 과정의 중요한 일부라고 생각한다.

    이를 위해 기록할 내용을 먼저 정리했다.

    1. 팀 목표와 업무 방식
    2. 프로젝트 진행 상황
    3. 프로젝트 구조 및 아키텍처
    다음 주에 새롭게 시도해 볼 내용이 있어?

    마지막 주차인 만큼 CS 연결고리 퀴즈를 팀원들과 마무리하려 한다. 지금까지 학습한 내용을 바탕으로 프로젝트에 녹여낸 부분을 뽑아보자. 어떤 방식으로 적용되어 있고 이를 통한 이점은 무엇인지 기록해보려 한다. 반대로 적용하지 못한 내용은 무엇이고, 어디에 적용하면 좋았을지, 어떻게 적용할 수 있었을지도 생각해보자.

    한편으로는 각자 작성해보고 종합하면 어떨까 싶기도 하다. 함께 학습하고 적용한 내용이지만 분명 다르게 생각하는 부분이 있을 것 같아 궁금하다. 다른 사람의 생각에 묻어가기보다 각자 생각한 내용을 정리해보고 비교하며 이 부분까지는 생각 못 했는데? 하는 부분을 찾아보는 것도 좋을 것 같다.

    회고를 마치며


    시니어 피드백의 영향

    이번 주에는 시니어 리뷰어 분께 피드백을 받으며 부족한 부분을 많이 깨달았다. 특히 행위와 생각에 대한 근거가 부족하다는 지적이 크게 와닿았다. 평소에는 정확한 근거보다는 추측에 가까웠고, 말의 끝이 항상 흐려졌다.

    예를 들면, 한 팀원이 제안한 방식이 우리 프로젝트에서 이 방식이 과연 적합한지 확신이 서지 않아 거절했었다.당시 다음과 같이 답변했었다.

    Notion image

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

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

    조금 더 근거를 두고 조리있게 말하는 연습을 해야겠다. 또, 직접 말로 뱉어보며 습관을 들여보려 한다.

    더 잘할 수 있는 부분

    설득하자. 설득해보자. 그러기 위해 더 많은 근거를 생각하고, 더 많은 지식을 쌓자. 직장은 학교가 아니다. 내가 명확하게 말하지 않아도 이해하고 받아줄 친구는 없으며, 무엇보다 면접관을 설득하지 못하면 입사하지도 못한다. 작은 개념 하나에도 질문을 던지고 명확한 근거로 설명할 수 있는 능력을 키우자. 하나씩 연습해가자.