Rocky 's Blog

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

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

회고를 시작하며


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

이번 주에는 기존에 익숙했던 리액트와 Tailwind CSS 를 활용했기에 작업 시간이 크게 길어지지 않았다. 덕분에 서버와 배포 관련 학습에 더 많은 시간을 할애할 수 있었고, 특히 데이터베이스 설계를 처음부터 직접 그려보며 차근차근 진행해 나갔다.

다른 캠퍼분들과 주변 지인들에게 적극적으로 조언을 구하고 피드백을 받았다. 작업물을 설명하는 과정에서 스스로 부족한 점을 발견하고 점검하는 기회가 되었다. 물론 여전히 놓치는 부분도 있었지만, 이전에 비해 실수가 눈에 띄게 줄어들어 뿌듯했다.

오프라인 가보니 어땠어?

지난주에는 오프라인의 장점을 충분히 살리지 못해 아쉬웠다. 이번 주에는 모르는 내용을 스스로 충분히 고민한 뒤, 캠퍼들과 적극적으로 대화하며 이해의 폭을 넓히려고 노력했다.

이번 미션에서 클라우드 개념이 부족해 배포 과정이 어렵게 느껴졌고, AWS 사용 역시 생소했다. 특히 컨테이너 라는 개념 자체보다 컨테이너를 띄운다 와 같은 표현이 더 혼란스러웠는데, 동료 캠퍼분과 이야기를 나누며 하나씩 의문을 풀어갈 수 있었다.

인상 깊었던 점은 단순히 이번 프로젝트에 국한되지 않고, 실제 프로덕션 환경이나 다음 그룹 프로젝트에서도 Nginx를 사용할 것인지트래픽이 몰린다면 어떤 부분에서 어떻게 대응할 것인지 와 같은 상황까지 함께 고민했다는 것이다. 비록 모든 내용을 완벽히 소화하지는 못했지만, 전체적인 흐름과 핵심 키워드를 파악하면서 배포 과정이 한결 수월해졌다.

팀 동료들과의 시간은 어땠어?

이번 주 팀 빌딩 시간에 그룹원들과 이야기를 나누며 차분한 분위기에서 무난하게 진행될 것 같다는 첫인상을 받았다. 하지만 일주일을 함께 보내보니 차분함 속에 열정이 가득한 분들이었고, 그 덕분에 그룹 활동이 매우 즐거웠다.

슬랙에 캔버스를 만들고, 질문들을 모아둔 뒤 줌을 통해 피어 리뷰를 진행했다. 첫 주라 코드 작성량은 많지 않았지만, 궁금한 점이 많이 올라오면서 활발한 피드백이 이루어졌다. 질문을 남기고 답변하는 과정에서 서로의 생각을 다시 점검하는 좋은 계기가 되었다.

Notion image

위 사진은 실제로 내가 남긴 질문이다. 이를 시작으로 다른 서비스에서는 현재 프로젝트와 어떻게 다를까? 와 같은 주제로 논의가 확장되었고, 서비스 특성에 따라 달라지는 설계 방식에 대해 생각해보는 시간을 가질 수 있었다.

이번 주차에 배운점

이번 주차에 진행한 내용 중 새롭게 알게 된 점은?

이번 미션은 리액트를 사용하는 첫 번째이자 마지막 미션이다. 특히 리뷰어분께서 FE 개발자이시기에 프론트엔드 작업에 더욱 신경을 썼다. 평소 하던 방식대로 진행하되, 이렇게 하는 게 맞나? 라는 의문이 들었던 부분들, 특히 컴포넌트 파일 분리 와 디자인 패턴 도입 에 대한 궁금증을 질문으로 남겼고, 이에 대해 리뷰어분으로부터 많은 피드백을 받을 수 있었다.

어떤 문제점들이 있어서 고민을 하게 되었는가?

작은 프로젝트나 예제 코드를 따라 할 때는 각 컴포넌트를 하나의 파일로 생성하는 방식으로 진행했다. 그러나 프로젝트 규모가 커질수록 컴포넌트와 파일 수가 급격히 늘어나면서 관리가 어려워졌다. 단순히 파일을 분리하는 것만으로는 효율적인 관리가 힘들다는 것을 체감했고, 명확한 폴더 구조와 체계적인 컴포넌트 그룹화가 필요하다는 생각이 들었다.

내가 생각했던 해결책은?

컴포넌트와 파일을 어떻게 관리해야 할까에 대해 정말 많은 고민을 했다. 고민 끝에 생각한 해결책은, 특정 컴포넌트에 종속되어 외부에서 사용되지 않는 컴포넌트들을 같은 파일 내에 위치시키는 것이었다.

예를 들어, ---Item 컴포넌트가 오직 ---List 컴포넌트 내부에서만 쓰인다면 이 둘을 한 파일에 함께 두는 방식이다. 하지만 이런 방법이 올바른 접근인지 확신이 서지 않아 리뷰어분께 질문을 남기게 되었다.

어떤 피드백을 받았는가?

리뷰어분께서는 작은 컴포넌트들을 추상화 계층에 맞추어 나누는 경우도 있다고 말씀하셨다. 예를 들어,

// as-is
<div>...</div>
<SearchBar />
<p>...</p>

// to-be
<Something />
<SearchBar />
<MyText />

이처럼 코로케이션이 유리한 경우라면 같은 폴더 내에 컴포넌트를 선언하는 것도 충분히 좋은 방법이라고 하셨다. 다만, 무엇보다 중요한 것은 팀 간 컨벤션과 약속이며, 이를 해치지 않는 선에서 각자가 관리하기 편한 방식을 채택하는 것이 최선이라는 점을 강조하셨다.

추가로 다음과 같은 컴포넌트 분리 기준을 제시해 주셨다.

  1. 다른 팀원이 봤을때 이해하기 편한지
  2. 불필요한 리렌더링 방지
  3. 유지보수하기 편한지
그렇다면 앞으로는 어떻게 적용해볼 것인가?

확정된 정답을 찾기보다는, 개인이나 팀 모두가 동의하고 명확히 이해할 수 있는 기준을 세우는 것이 가장 중요하다고 느꼈다. 성능 최적화는 개인의 노력이 필요한 부분이지만, 협업을 고려한 효율적인 구조 설계에 더 많은 관심을 기울여야겠다는 생각이 들었다. 다음 주가 되기 전까지 나만의 컴포넌트 분리 기준을 체계적으로 정리해볼 계획이다.

아쉬웠던 점


가장 아쉬웠던 부분은 무엇인가?

이번 주에는 AWS 를 활용해 배포를 진행했다. 주로 블로그 글을 참고하며 차근차근 따라가다 보니 배포 자체는 성공할 수 있었다. 하지만 과정 중간중간 깊이 생각하고 고민하는 시간이 부족했다는 아쉬움이 남는다.

어떤 부분이 부족했다고 느끼는가?

예를 들어, 이번 미션에는 도커를 사용하지 않는다 는 요구사항이 있었다. 나는 요구사항에 맞춰 구현을 완료했지만, 미션을 마친 후에야 왜 도커를 사용하지 말라고 했을까? 라는 의문이 들었다. 만약 요구사항의 의도를 미리 고민해보았다면 학습 방향성을 더 명확하게 설정하고, 배포 과정에서 얻을 수 있는 인사이트를 놓치지 않았을 것이다.

앞으로의 계획은 무엇인가?

앞으로는 요구사항을 단순히 따라가기보다, 그 요구사항이 왜 주어졌는지 의도를 먼저 생각해보려 한다. 미션을 통해 성장할 수 있도록 설계된 방향이 분명 존재할 것이다. 이를 놓치지 않고 매번 점검하며, 요구사항의 의도를 파악하는 습관을 길러가고자 한다.

다음 주에 시도해볼 내용


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

이번 주에는 노션으로 태스크를 관리했다. 하지만 앞으로 진행할 그룹 프로젝트를 고려했을 때, GitHub 로 태스크를 관리하는 것이 더 적합하다고 판단했다.

주말 동안 다른 캠퍼들의 GitHub 태스크 관리 방법을 참고해 나만의 프로젝트 관리 방식을 정해볼 계획이다. 그룹 프로젝트 전에 효율적이고 효과적인 태스크 관리 경험을 미리 쌓는 것이 목표이며, 여러 캠퍼분들의 방식을 살펴보며 장점들을 조합해 나갈 예정이다.

다음주에 새롭게 시도해 볼 내용이 있어?

리액트 컴포넌트와 타입 관리 방식은 개발자마다 취향과 경험이 다르다고 생각한다. 정답은 없겠지만, 더 효과적인 방법을 찾기 위해 다른 캠퍼분들의 PR 을 자주 살펴보며 폴더 구조와 파일 역할에 대한 인사이트를 얻을 것이다. 예를 들어, 왜 이런 구조를 선택했는지각 폴더와 파일의 역할을 명확히 하기 위해 어떤 방법을 사용했는지 등을 배우면서 나만의 기준을 세워나가고자 한다.

회고에 대한 회고


광범위한 내용들을 모두 흡수할 수 있을까?

회고를 작성하면서도 느꼈지만, 이번 주에 배운 내용이 많아서 주말이나 미션 기간 동안 모두 습득하기는 어려울 것 같다. 분야도 다양하고 각 내용이 특정 개념에 국한되지 않고 광범위하기 때문에, 이를 어떻게 정리하고 학습할지 고민이 되었다.

결론적으로는 각 주제별로 고민과 학습 방향을 따로 정리해 두기로 했다. 연말과 연초의 인터미션 기간을 활용해 이들을 집중적으로 공부하면 좋을 것 같다.

더 잘할 수 있는 부분

이번 달 목표 중 하나였던 vite.config 와 tsconfig.json 설정을 공식 문서를 참고하며 학습했다. 다양한 설정값과 각각의 예시 상황을 생각하며 정리했다. 그러나 이번에 모노레포를 적용하는 과정에서는 배운 내용을 제대로 활용하지 못한 것 같다. 배운 내용을 실제 프로젝트에 적용하는 과정이 또 다른 어려움으로 다가왔다.

앞으로는 이전 프로젝트들을 살펴보며 설정값이 어떻게, 왜 사용되었는지 확인해볼 생각이다. 기본 설정값들은 쉽게 간과되기 쉬운데, 이런 부분들을 다시 한번 짚고 넘어가면서 더 깊이 이해해보면 좋을 것 같다.