2026 네이버 부스트캠프 웹・모바일 10기 멤버십 수료 후기

 

 

1. 지원 계기 — 왜 부스트캠프였는가

우선, 나는 부스트캠프를 지원 당시 나는 졸업을 앞두고 취업 준비를 하고 있는 상태였다. 바로 취업 준비를 할지 고민하다가, 쓰디 쓴 탈락의 고비를 마셨고... 🥹

• [네이버페이] 채용 연계형 FE 개발 인턴십 - 서류 합, FE 테스트 탈락
• ICT 글로벌 인턴십 1차 - 서류 전부 탈락
• ICT 글로벌 인턴십 2차 - 서류 한곳 통과, 최종 면접 탈락
• 우아한 테크코스 6기 프리코스 탈락
• [네이버랩스] Frontend Engineer (인턴십/자율주행) 서류 탈락
• 카카오 공채 1차 코딩테스트 탈락
• [토스] Frontend Developer Assistant 탈락

스스로 더 성장과 학습이 필요하겠다는 결론을 내렸다.
실패 원인을 분석해보았을 때 크게 3가지 이유가 있었다.

1. 지나치게 프론트엔드 쪽에만 편향해서 학습과 개발 경험을 쌓아오느라 웹 개발 전반적으로 충분한 지식과 경험이 부족했다. ( ICT 인턴십은 풀스택 개발 경험을 요구했는데, 그 당시 나는 프론트엔드 위주의 경험 밖에 없었고, 따라서 면접 때 백엔드 관련 질문으로 Elastic Search 와 인덱스와 B-Tree 구조에 관해서 물어봤는데, 제대로 답을 하지 못했다. )
2. 이론적인 지식들에만 집중해있고 실무적인 프로젝트 개발 경험이 모자랐다. ( 정말 사소한 실수 하나로 TC 를 다 날려버리는 바람에 정말 아쉬웠지만, 꾸준히 FE 개발을 했다면 네이버 페이 과제 테스트도 통과했을 것 같다. )
3. 내 스스로 생각하기에 정말 의미 있는 기술적 도전을 해보지 못했다.
4. 1일 1코테에 꽂혀 있었는데, 어려운 문제를 푸는거에 심취해서 정작 중요한 FE 개발은 신경쓰지 못했다..
5. 이력서 쓰는 방법을 잘 몰랐다.

보다 더 넓은 시야에서 웹 개발을 바라볼 수 있는 역량을 기르기 위해서 네이버 부스트 캠프에 지원하고자 했다!

사실 네부캠은 워낙 소문이 자자했기에 한번쯤 겪어보고 싶은 교육 과정이기도 했다. 대부분의 주인공들이 수많은 탈락의 고비를 마주하고 나서 극적인 성장을 이루는데, 네이버 부스트캠프가 나의 성장의 변곡점이 되어주기를 바랐다. 🙌

2. 멤버십 시작 전 나의 수준

• 기술 역량
• 협업 경험
• 문제 해결 방식
• 부족하다고 느꼈던 부분

우선, 나는 그 동안 10개 내외 정도로 크고 작은 웹 개발 프로젝트를 경험해왔었다. 기획자나 디자이너 분과도 협업하기도 했었고, 대부분의 프로젝트에서 열심히 참여해서 유의미한 결과를 만들어왔었다.

대부분의 프로젝트에서 프론트엔드를 맡았고, React, Redux, Recoil, SASS, Tailwind, Next.js 등 대부분의 기술들은 한번씩 사용해본적이 있고 어렵지 않게 사용할 수 있는 수준이었다.

적당히 난이도 있는 수준의 레이아웃이나 컴포넌트들은 스스로 구현할 수 있었다. 다만, 종종 버그를 해결함에 있어서 확실한 이유를 찾아서 해결하는 것이 아니라, 코드를 대충 수정해서 결과론적으로 잘 돌아가게 되었다면 만족하는 나쁜 습관을 가지고 있었다. 특정 기능이 이상하게 돌아갈 때, 왜 결과가 이렇게 되고 잘 돌아가지 않는지 리액트의 작동 흐름을 A-Z 로 완벽하게 이해를 하지는 못하고 있다고 느꼈다.

또한, 단순한 기능 구현을 넘어서 클린 코드 측면에서 프론트엔드 컴포넌트를 어떻게 쪼개야하고, 어떻게 렌더링을 최적화하고, Hook을 어느 정도 수준으로 적절히 추상화하고, 어떻게 직관적으로 상태 관리를 해야하는지, TS 를 잘 활용하는 노하우에 대한 스스로의 경험이나 판단 기준이 부족하다고 느꼈다.

또한, 대부분의 프로젝트가 한달 내외의 짧은 기한 동안 이루어져서 데이터통신, 에러처리, 요청취소, 로딩과 캐싱처리(SWR) 과 관련한 의미 있는 경험을 쌓아보지 못했던게 아쉽기도 했다.

특히나 리액트에서 Socket.io 가 아니라 순수 Websocket 을 도입하면서 이거를 어떻게 리액트에서 잘 구동되도록 ( Hook 으로 관리할지, ContextAPI 로 관리할지 ) 고민하는 과정에서 굉장한 애를 먹었던 기억이 있고, 리액트에 대한 보다 더 본질적인 이해가 필요하다고 느꼈다.

백엔드는 MongoDB+Node.js 를 활용한 간단한 CRUD API 백엔드 개발 정도 할 줄 알았다.

3. 멤버십에서 경험한 핵심 과정

• 멤버십 목표
• 과정
• 학습 방식 (자율성, 미션, 코드 리뷰 등)
• 협업 방식
• 힘들었던 점

우선, 네이버 부스트캠프 멤버십은 크게 3가지 과정으로 나뉜다.

1. 학습 스프린트 (개인)
2. 그룹 스프린트 (팀)
3. 그룹 프로젝트 (팀)

멤버십 목표

내가 부스트캠프 과정에서 사용했던 노션을 돌아보니, 다음과 같이 내가 멤버십 과정에서 이루고 싶은 목표(방향성)과
멤버십 과정 전반에서의 규칙 및 나만의 진행 노하우가 담겨져 있는 페이지를 확인할 수 있었다. 몇 주 간의 스스로의 체계와 규칙을 쌓고자 노력했던 것 같다. 그 결과, 그 과정에서 확실히 AI 를 잘 활용하는 나만의 노하우를 분명히 정립할 수 있었다. 특히 CLAUDE.md 에 어떤 내용이 들어가면 좋을지 여러가지 것들을 시도해보고 실험해보았다.

)

---

학습 스프린트 (개인)

학습 스프린트에서는 장장 10주차에 걸쳐서 일정 주기별로 프로젝트가 바뀌고 미션이 주어진다.
한 프로젝트 단위로 기획과 요구사항의 분량이 굉장히 많은데도 불구하고 2주 단위로 프로젝트가 바뀌고 어마무시한 분량의 요구사항이 주어진다.

• 1 ~ 2주차 : 코드 스타그램
• 2 ~ 4주차 : 이슈 트래커
• 4 ~ 7주차 : 코드스타그램 WAS

거기서 나오는 요구사항을 구현하고 웹 기술에 대해 보다 더 근본적인 이해를 하면서 실력이 가장 많이 성장했다고 느꼈다.

ejs 같은 템플릿 엔진을 사용하면서 서버에서 직접 HTML 을 내려주는 전통적인 방식의 웹 개발 패러다임을 경험할 수 있었고,

Node.js net 모듈 만으로 동작하는 HTTP 서버를 만들어보기도 하고,
리액트 프레임워크 없이 Vanila JS 만으로 SPA 웹앱을 구축해보기도 하면서 ESM 방식으로 모듈을 분리하고 DOM API 도 직접 다루고, Diffing 알고리즘과 DOM 최적화에 대해서 고민할 수 있었다.

특히 멤버십 과정에서 소수 인원에 대해서 라운지에서 발표할 기회가 있었는데, 우연히 좋은 제의를 받아서 200명 부스트캠퍼 분들 대상으로 30분 동안 웹 개발 관련한 강연을 진행할 수 있었다! :D

전통적인 웹 페이지 동작 방식부터 현대 웹 렌더링 패러다임 까지
웹 렌더링 패러다임의 진화: MPA에서 SPA, SSR을 거쳐 현대 하이브리드 방식으로

)

)

사실 처음에는 막연한 두려움이 앞섰는데, 그만큼 내가 제대로 된 + 유익한 정보를 제공하기 위해서 내가 제공하는 기술적인 정보가 정말 올바른 것이 맞는지 끊임 없이 의심하고 검증하고자 노력을 많이 기울였다.
그 주에 체감상 10~20시간은 발표 준비에 쏟았던 것 같다.
( 사실 나는 이런 많은 사람들 대상으로 하는 발표에서 큰 실수를 한 적이 있어서 큰 트라우마로 남아 있다.. 😭 '내가 모르는 부분에 대한 질문이 들어오면 어떡하지?' 하고 겁을 먹기도 했었지만, 내가 할 수 있는 최선의 노력+준비로 이겨내고자 했다. )

그리고 특히 CSR 과 SSR 에 대해서 잘 이해가 가지 않던 부분을 집요하게 파고 들면서 근본적인 원리를 이해하기를 바랐다.

보통 초기 로딩 속도 향상을 위해서 SSR 을 선택하는데, SSR 이 CSR 보다 FCP 가 빠른게 왜 그렇지?

CSR 이 TTFB 가 더 빠르다면서 왜 렌더링 속도는 더 느리지?

일반적으로 SSR은 HTML 을 서버에서 렌더링 해주기 때문에 API 요청을 보내고 나서 화면을 그려야하는 CSR 보다는 FCP 가 빠르다는 것이 일반적이다. 하지만 나는 여기서 한 발자국 더 나아가서, 다음과 같은 질문을 던졌다.

SSR 은 서버에서 HTML 을 렌더링하는데 그만큼 시간이 걸리니까 빈 템플릿을 주는 CSR 이 API 요청을 빨리 받아오면 더 빠르게 화면을 그릴수도 있는거 아니야?

결국 CSR 과 SSR 의 근본적인 로딩 성능 차이는 느린 JS 로 DOM 을 동적으로 조립하는데 걸리는 시간 vs C/C++ 기반 HTML 파서로 완성된 HTML 을 파싱하는데 걸리는 시간 차이에서도 비롯된거라고 볼수도 있었다. 미리 완성된 HTML 을 화면에 띄우는건 얼마 걸리지 않는다는 것이다!

아래는 내가 발표를 준비하면서 주간 학습 피드백에 쓴 내용 중 일부이다!

 

 

Q1. 이번주에 새롭게 학습한 내용 중 가장 기억에 남는 것은 무엇인가요? 해당 내용을 문제 해결에 어떻게 적용했나요?

 

이번 주에 새롭게 학습한 내용 중 가장 기억에 남는 것은 SSR(Server-Side Rendering)과 SPA(Single Page Application)의 차이입니다. 기존에는 단순히 SSR은 서버에서 HTML을 만들어 내려주고, SPA는 클라이언트에서 화면을 그린다는 정도만 알고 있었는데, 이번 학습을 통해 고전적인 SSR과 현대적인 React/Vue 기반 SSR의 차이를 명확히 이해하게 되었습니다. 고전적인 SSR은 PHP, JSP, Django처럼 서버 템플릿 엔진을 사용해 완성된 HTML을 내려주는 방식으로, 별도의 번들링 과정이 필요하지 않습니다. 반면 현대적인 SSR은 Next.js, Nuxt.js 같은 프레임워크를 사용하여 동일한 컴포넌트 코드를 서버와 클라이언트에서 모두 실행하고, 클라이언트 측에서는 Hydration 과정을 통해 이벤트와 상태를 이어받습니다. 이 때문에 서버 번들과 클라이언트 번들을 따로 빌드해야 하고, 배포 과정도 단순 정적 파일 배포와 달리 프로덕션 SSR 서버를 운영해야 한다는 점을 알게 되었습니다. 이 학습을 프로젝트에 적용하면서, 단순히 “SSR은 초기 로딩이 빠르다”라는 피상적인 이해가 아니라 왜 JS 번들이 여전히 필요한지, 그리고 어떤 경우에 SPA 방식이 더 적합할 수 있는지를 고려하게 되었고, 결과적으로 구현 방식을 선택할 때 장단점을 균형 있게 판단할 수 있는 시야를 얻을 수 있었습니다.

이번 주에 가장 기억에 남는 학습 내용은 SSR과 CSR의 혼합 전략에 대한 이해였습니다. 처음에는 제대로 개념을 완벽하게 이해하지 못한채로 SSR=MPA, CSR=SPA 라고 막연하게 알고 있었지만, 실제로 SSR 기반 애플리케이션을 구현하면서 이 구분이 점점 무너지고 있음을 체감했습니다. 현대 웹에서는 페이지 단위, 심지어 컴포넌트 단위로도 SSR과 CSR을 혼합해 적용할 수 있다는 점이 가장 큰 깨달음이었습니다.

전통적인 SSR/MPA에서는 API가 필요하지 않았습니다. 서버가 DB를 조회해 완성된 HTML(View+Model)을 내려주기 때문입니다. 그러나 동적 상호작용이 추가되면 Ajax 요청이 필수로 등장합니다. 좋아요, 댓글, 북마크와 같은 기능을 처리하려면 클라이언트가 서버와 데이터를 주고받아야 하기 때문입니다. 이를 직접 구현하며 “SSR만으로는 동적 UI를 감당하기 어렵고, 결국 API를 중심으로 한 CSR 전략이 불가피하다”는 사실을 실감했습니다.

 

또 하나 인상적이었던 점은 렌더링 전략을 애플리케이션 전체가 아니라 페이지 단위로 고민해야 한다는 것이었습니다. 예를 들어 정적 성격이 강한 페이지(공지, 소개, 문서)는 SSR로 처리하면 SEO와 초기 로딩 속도를 최적화할 수 있고, 반대로 댓글이나 좋아요처럼 상호작용이 많은 페이지는 CSR로 처리해야 반응성이 좋아집니다. 이렇게 성격에 맞게 전략을 나눌 때 비로소 유연한 애플리케이션이 완성됩니다.

이 배움을 문제 해결에 적용하여 모든 페이지를 동일하게 SSR/CSR로 고정하는 대신, 각 페이지의 특성을 기준으로 리팩토링 방향을 잡았습니다. 특히 “페이지 전환도 동적 UI로 볼 수 있는가?”라는 질문을 던지며, 최초 1회 SSR 이후에는 사실상 SPA처럼 CSR 중심으로 운영할 수도 있음을 깨달았습니다. 결국 이번 학습을 통해 단순히 기술 개념을 아는 데 그치지 않고, 실제 요구사항과 구조에 맞게 전략을 선택하고 적용하는 것이 개발자에게 중요한 역량이라는 점을 깨달은 것이 가장 큰 성과였습니다.

 

그리고 이 모든 과정에서 그 무엇과도 대체할 수 없는 기술적인 토대 지식이 단단해졌다 고 느꼈다. 특히 내가 무언가를 제대로 설명하기 위해서 학습했던 지식들은 기억에 정말 오래 남고, 단순 암기가 아니라 '이해' 를 기반으로 한 지식은 쉽게 휘발되지 않는구나 느끼게 되었다. 그리고 이 근간이 되는 지식들은 추후 내가 Hydration 같은 어려운 개념을 제대로, 그리고 쉽게 이해할 수 있도록 도움을 주었다.

그리고 매주 그룹이 바뀔 때 "서연님 혹시 발표하시지 않으셨나요?" 하고 알아봐주시기도 하고, "발표 너무 좋았다", "발표 유익했다. 잘들었다" 고 해주셔서 정말 감사하고 뿌듯한 순간이었다. ☺️💓

그룹 스프린트

그룹 스프린트 때는 4명의 팀원들과 함께 <웹 기반 다중 사용자 OS> 프로젝트를 진행하게 되었다.
주제도 정말 흥미로워서 시간 가는 줄도 모르고 하루종일 개발에 몰입했던 기억이 난다. 홀린듯이(?) 중독되서 개발을 했었다. 특히 나는 내가 만드는 프로덕트가 좋은 디자인+UX 를 가지도록 하고 싶은 욕심이 있었는데(나는 예쁜걸 개발하면 생산성과 몰입도가 오른다?), 그래서 Figma 기반으로 Mac OS 스타일의 에뮬레이터를 스스로 디자인해서 만들었다.

 

그 결과 디자인과 똑같이 구현해주시는 금손 프론트엔드 능력자 팀원분들 덕분에 원하는 느낌의 디자인과 UX 를 지닌 프로덕트를 구현해낼 수 있었다. 심플하고 고급진 애니메이션이 너무 마음에 들었고 완성도 높은 제품을 만들고 싶은 동기부여가 더 생겼다.

 

https://github.com/boostcampwm2025/web11-web-os-emulation

 

 

윈도우 부팅부터 다중 사용자를 위한 실시간 커서+윈도우 동기화, 터미널 명령어까지 실제 OS 의 동작 원리를 기반으로 웹에서도 유사한 동작을 구현하고자 애썼던 것 같다.

 

사실 OS 처럼 복잡한 도메인의 기술적 시스템은 설계 ~ 구현 해보는 것은 처음이었다.
그만큼 초기 아키텍처 구조를 한번에 설계하는 것이 어렵다는 것이다.

 

모두가 잘 모르는 상황에서 처음에 완벽한 설계를 하기란 어려운데, 하지만 처음 설계를 잘못 해놓으면 점점 유지보수하기 어려운 구조가 만들어지거나 늦으면 기술 부채가 쌓여서 더 이상 돌이키거나 변경하기 어려워질수도 있는 상황이었다.

그래서 나는 구조적 개선을 위해서 기존 아키텍처의 문제점을 발견하고, 더 나은 아키텍처 구조를 제안하는 글을 작성했다.
그 과정에서 여러가지 시각적 자료와 구조도를 적극적으로 활용했다.

 

 

https://github.com/boostcampwm2025/web11-web-os-emulation/discussions/40

 

 

그리고 다중 사용자 기능을 어떤 식으로 지원할 것인지? 모호한 지점에 대해서도 기획과 기술적 설계가 맞물려 있는 지점을 명확하게 글로서 풀어내고, 팀원들의 공통 합의를 이끌어내고자 했다.

https://github.com/boostcampwm2025/web11-web-os-emulation/discussions/63

그

룹 스프린트에서는 복잡하고 어려운 OS 원리 기반 SW 를 설계하고 구현하면서, 팀원들에게 복잡한 시스템에 대한 설계와 기능 구현 방식을 글과 말로 명료하게 정리하고 표현하는 연습을 하면서 전달력과 의사소통 능력을 정말 많이 향상시킬 수 있던 것 같다!

아래는 3주동안 함께 그룹 스프린트를 진행한 팀원분들이 남겨준 동료 피드백이다 🥹💙 정말 좋은 말들을 가득써주셔서 두고두고 읽었던 기억이 난다.. 우리 팀원분들이 다들 능력도 정말 뛰어나시고 경청도 잘해주시고 배려심도 깊어서 다같이 좋은 결과물을 만들 수 있던 것 같다!!!

비록 좋은 팀 분위기가 좋은 결과와 직결되는 것은 아니지만, 적어도 유의미한 상관관계가 있다고 생각하는 편이다. 결국 진정한 팀워크는 강한 '신뢰'를 바탕으로 만들어진다고 생각하기 때문에,팀원분들에게도 항상 믿을 수 있는 태도로 일관성 있게 행동하고자 노력했던 것 같다!
나는 팀원분들의 세세한 감정변화를 잘 알아차리고 최대한 팀원들의 의견을 잘 경청하고 존중과 배려 기반의 커뮤니케이션을 하는 것을 중요시하고 우선시했다.

요구사항을 깊이 생각하고 팀의 발전을 위해 노력한다는 느낌을 받았어요.
먼저 나서서 문제 상황을 해결하고자 하시고 프로젝트가 원활히 진행될 수 있도록 팀을 이끄시는 모습이 인상적이었습니다.
문제 상황이 있다면 그 문제를 어떻게 해결할 수 있을지 다양한 아이디어를 도출해내고 이를 스스로 결론내리기보단 동료들과 함께 의논해 선택하고자 하는 모습도 좋았어요.
스스로 결론을 내리다보면 어떤 과정으로, 어떤 생각으로 결론이 난것인지, 어떤 문제가 발생한건지 이해하기 힘드니까요.
다양한 모습에서 협업 능력이 좋다고 생각했어요.

서연님은 어떤 의견이라도 잘 경청해주시고 너무 잘 반응해주셔서 말하는 사람에게도 계속 말하고 싶게 만드는 능력이 있는 것 같아요. 경청 후 서연님만의 의견을 제안해주시기도 해서 질문-답변-제안 일련의 과정이 정말 좋습니다. 지금까지 만난 캠퍼들 중 가장 경청을 잘 해주고 있습니다.

우리팀에서 가장 뚜렷한 주관을 가졌다고 생각합니다. 저는 제 분야에 대해서만 주관을 가지고 구현/설계 하기도 바쁜데 서연님은 팀을 위한 중요한 결정사항들을 먼저 나서서 생각 후 말씀해주십니다. 정말 진정한 팀 플레이어라고 할 수 있습니다. 그러다보니 저도 모르게 서연님께 모든 문제들을 의지하게 되는 경향이 생기는 것 같아 죄송스럽네요... 저는 서연님처럼 예의바르고 배려심이 많은 스타일이 아니라서, 서연님을 보면 볼수록 정말 예의와 배려심이 넘친다고 생각이 듭니다... 정말 최곱니다...

서연님께서는 물론 코드 작성등의 작업도 능숙하시지만, 협업에 있어 항상 가장 먼저 나서시고 생각해볼만한 주제를 계속 던져주시는 분이라 함께 일하는 동료로서 굉장히 적합하다고 느꼈습니다. 또 항상 상대를 배려해주고 존중해주는 태도를 취하시고 함께 회의를 하면 그 회의의 질과 분위기가 한층 올라가는 느낌이 들어 이 3주동안 정말 인상깊었습니다. 저는 개인적으로 이런 능력이 협업에 있어, 그리고 팀에 있어 가장 중요하다고 생각하기에 이런 스탠스를 계속 가져가신다면 분명 어디서든 환영받는 사람이 될 것이라 생각합니다.

---

저희 팀 전체가 이번 프로젝트에서 서연님께 정말 큰 도움을 받은 것 같습니다. 분명 리더를 정하지 않고 진행한 프로젝트임에도 불구하고, 오늘 마스터 클래스에서 언급된 것처럼 '가장 잘 하는 사람이 가장..' 에 해당하는, 어떤 리더 역을 앞장서셔 맡아주셔서 팀원으로써희 팀 전체가 이번 프로젝트에서 서연님께 정말 큰 도움을 받은 것 같습니다. 분명 리더를 정하지 않고 진행한 프로젝트임에도 불구하고, 오늘 마스터 클래스에서 언급된 것처럼 '가장 잘 하는 사람이 가장..' 에 해당하는, 어떤 리더 역을 앞장서셔 맡아주셔서 팀원으로서 굉장히 편했고 또 그런 태도와 기술적인 토론을 위해 준비하시는걸 보면서 정말 많이 배웠습니다. 앞으로도 서연님같은 팀원을 만났으면 좋겠다고 생각합니다.

의견을 논리적으로 잘 설명하시고, 무작정 내세우기보단 팀원을 설득하고자 하는 점, 설득하지 못할 경우엔 팀원의 의견을 존중하는 방식이 저는 배워야할 점이라고 생각했어요.
오늘 특강을 들으면서 서연님이 딱 적절한 태도로 협업한 것 같아서 신기했어요!
다른 팀원의 의견을 칭찬하면서 자신의 의견을 함께 전달하는 방식이 상대방을 배려하는 태도인 것 같아서 다음 그룹 프로젝트에서 최대한 따라해보려고 해요.

서연님은 항상 팀을 위해 고민하시는 팀플레이어 입니다. 서연님의 팀을 위한 태도와 노력은 제가 앞으로 팀프로젝트에서 어떻게 생각하고 행동할 것인지를 간접적으로 배울 수 있었습니다

그룹 프로젝트

대망의 그룹 프로젝트! 에서는 장장 2주 + 4주차에 걸쳐서
앞선 2주동안은 기획부터 디자인, 기술 검증, MVP 개발을 진행했고, 나머지 4주동안은 실제 프로덕트를 개발하는 시간을 가졌다.
우리팀은 <실전과 유사한 환경의 모의 티켓팅 시뮬레이터> 를 주제하고, 같이 <가상 면접으로 배우는 대규모 시스템 설계> 책으로 스터디를 진행하며 대규모 트래픽을 견딜 수 있는 안정성 있는 아키텍처를 설계하고자 했다.

https://github.com/boostcampwm2025/web10-beastcamp

[GitHub - boostcampwm2025/web10-beastcamp: 실전과 가장 유사한 티켓팅 연습 환경을 제공하는 리얼리즘 티켓

실전과 가장 유사한 티켓팅 연습 환경을 제공하는 리얼리즘 티켓팅 시뮬레이터. Contribute to boostcampwm2025/web10-beastcamp development by creating an account on GitHub.

github.com](https://github.com/boostcampwm2025/web10-beastcamp)

4. 가장 큰 성장 포인트 (핵심 섹션 ⭐)

사실 이 회고글을 작성하기 전까지만 해도, 멤버십 과정에서, 특히 마지막 그룹 프로젝트에서는 100% 를 쏟지 못한 것 같아서, 내가 목표했던 것 만큼 많이 성장하지 못한 것 같아서 아쉬운 맘이 들곤 했다. 그래도 부스트캠프 수료 이전과 이후의 모습을 비교해본다면, 크게 성장한 내 자신을 확인할 수 있었다.

첫번째로, 프론트를 넘어서 웹 개발 전반적인 지식을 쌓을 수 있었다.

과거의 나는 프론트엔드 포지션이라는 이유로, db 모델링 구조나 서버 로직이 어떻게 돌아가는지에 무신경하고 단순히 서버가 내려준 API 명세서를 수동적으로 받아들이는 입장에 그치곤 했다. 그러다보니 서버에서 얼핏 보기에 이해하기 힘든 API 명세를 요구할 때가 있어도, 개선 제안을 할 수가 없었다. 그런데 이제는 서버에서 클라이언트 측의 복잡도를 높이는 명세가 들어오면, 이러한 방법이 최선인지, 기존 데이터 구조 설계에 문제는 없는지 검토할 수 있는 안목이 생겼다. 또한, 성능 병목이 발생했을 때, 이 것이 프론트엔드에서 해결해야하는 이슈인지, 백엔드에서 N+1 쿼리를 날리고 있어서 느린건지 구분할 수도 있다.

둘째로, 다소 복잡하거나 어려운 도메인에 대한 기술적 설계 및 협업 & 커뮤니케이션 역량을 향상할 수 있었다. OS 시스템 등 조금 더 큰 그림에서 시스템 동작 원리를 설계하고, 이를 팀원분들에게 이해하기 쉽게 설명하는 역량을 기를 수 있었다. 이 과정을 반복해서 연습하다보니 자연스럽게 자신감도 커지고 호소력도 짙어졌다.

기술적인 의사결정을 하는 회의에서 주도적이고 적극적으로 의견을 내다보니 ‘열정적인 변론가’ 라는 별명도 얻었다 ㅋㅋ 사실 부스트캠프 이전의 나는 원래 엄청 내향적이고 조용한 성격이었는데..
이번 팀에서는 적극적이고 열정적인 분들과 열띤 토론을 나누면서 되게 공격적인(?) 스타일이 되었던 것 같다..ㅋㅋㅋㅋㅋㅋㅋ 같은 팀원분이 적으신 회고에 적힌 내용을 보고, 크게 공감하는 내용이 많았다.

우리팀의 엔진 역할을 하시던 서연님!!! 저희팀에서 서연님이 안계셨다면 이정도로 앞으로 나아가진 못했을겁니다. 서연님의 장점은 '적극성' 이라고 생각합니다. '열정적인 토론가' 스타일 같달까요? 그냥 흐르는대로 지날수도 있지만, 늘 내가 주인이다 라는 마음가짐으로 어느하나 쉽게 내버려두지 않았습니다. 덕분에 저희가 단조롭지 않고 늘 생각할거리가 풍부한 팀이 되었습니다. 제가 오랜 기간 서연님과 함께하면서 자주 생각했던건데, 내가 '팀장' 이라면 서연님 무조건 뽑습니다. 조직에 이런 열정을 가진 사람이 반드시 필요하니까요. 그래서 앞으로도 이런 서연님의 '적극성', '열정'을 가장 큰 무기로 사용하시길 바랍니다. 같이 지내며 많이 배웠습니다. 수고하셨습니다.

팀원분들의 의견을 가장 많이, 잘 들어주십니다. 그리고 그만큼 본인 의견 표출도 확실하게 하셔서, 팀 회의나 활동이 길어져서 루즈해질 때 다시 활성화하는 역할을 잘해내셨습니다. 맡으신 작업도 새벽 늦게까지 열심히 하시는 것이 보였습니다!

다양한 자신의 의견을 주장해주시고 문서화도 잘 작성해주시고 특히 발표자료를 만드실 때 엄청 대단하시다 라는 생각을 했습니다. 정말 J042님이 없으셨다면 저희 팀이 데모를 제대로 준비할 수 있을까? 라는 생각이 들 정도였습니다. (아마 지금같은 퀄리티가 나오지는 않았을 것 같습니다.)

프론트랑 백 두 분야 모두에서 코드를 작성하시고 기능 구현을 하시는 것을 보고 양방향 개발자가 되어가시는 것 같아 부럽고 대단하다 생각하게 됐습니다. 항상 새벽까지 고생하시는걸 보면서 많은 동기부여가 됐습니다.

그룹프로젝트동안 발산적인 사고와 더불어 사안을 깊이 있게 고민하시는 모습이 인상적이었습니다. 스터디를 진행하는 과정에서 단순히 제시된 학습 내용에만 머무르지 않고, 그 배경이 되는 개념이나 확장될 수 있는 적용 사례까지 스스로 질문을 던지며 깊게 파고드는 모습을보여주셨습니다. 이러한 태도는 스터디 논의를 한 단계 더 확장시키는 데 도움이 되었고, 다른 팀원들도 추가적인 관점에서 생각해볼 수 있는 계기가 되었습니다. 또한 그룹 프로젝트를 진행할 때에도 어떤 의견이 제시되면 그 의견의 표면적인 실행 방안에만 집중하기보다, 이후 발생할 수 있는 영향이나 확장 가능성, 잠재적인 리스크까지 함께 고려하며 의견을 보태주셨습니다. 그 덕분에 의사결정 과정에서 보다 장기적인 관점의 검토가 가능했고, 논의의 깊이 역시 한층 더해졌다고 느꼈습니다. 발산과 동시에 깊이 있는 고민을 기반으로 팀 논의를 풍부하게 만들어주신 점이 특히 인상적이었습니다.

 

 

마지막으로 기술을 대하는 태도와 문제 해결 접근 방식의 변화이다. 항상 기술적 선택의 근거를 항상 명확히하려는 습관을 들이게 되었다.

• MSA 모노레포 구조를 선택했다면, 그 이유와 트레이드 오프는 무엇인지
• pnpm 과 Docker 를 함께 사용할 때 pnpm 의 장점을 제대로 누릴 수 있는 구조인지
• Next.js vs React 중에 대규모 트래픽 대응에 유리한 기술이 무엇인지
• Next.js 에서 대규모 트래픽 대응에 중요한 요인은 무엇인지
• 예상할 수 없는 트래픽이 몰려온다고 했을 때, 절대적으로 가용성과 안정성을 유지할 수 있는 서버를 만드려면 어떻게 해야하는지
• 내가 택한 기술적 선택지가 정말로 좋은 선택이 맞았는지 피드백해보기

 

---

5. 기억에 남는 경험 / 위기 순간

• 실패 경험
• 갈등
• 막혔던 기술 문제
• 극복 과정

사실 두번째 그룹 프로젝트에서는 더 좋은 서비스를 위해서 적극적으로 의견을 내주시는 팀원분들이 있어서 의견 충돌이 종종 있었다.

아무래도 설득을 해야하는 상황이 많았다보니까, 평소와는 다르게 조금 더 강한 어조로 주장을 펼쳐야하는 일이 생겼다. 단순 의견 표출이 의도하지 않게 공격적인 성향을 내비쳤을 수도 있을 것 같아서 걱정이 들기도 했다.

그러나 우연히 우리 팀원 분 중 한분이 쓰신 회고를 읽게 되었는데,

실제로 가장 마지막에 진행했던 프로젝트에서도 팀원들과 상당히 많은 의견 마찰이 있었다.우리는 상대방을 배려하기위해 YES를 하지 말자고 했다. 지금 당장 YES로 어영부영 넘기는게 편할지 모르겠지만, 이는 팀이 산으로 가게하는 주범이 된다. 그래서 매 의사결정마다 마찰이 있었다. 다만 우리팀이 정말 성숙한건 이게 절대 감정 싸움으로 가지 않는다는 것이다. 우리는 지금 어떤 의견에 대해서 반대한거지 상대방 사람 자체에 대해 반대한게 아니다. 그래서 의견 교류가 활발해질수록 팀은 더욱 단단해짐을 느꼈다.팀원 모두 정말 감사하지만 특히 나랑 활발히 의견 교류(?)를 해주었던 팀원에게 더욱 각별히 감사하다.어느 누구하나 열정이 떨어졌다면 의견 마찰도 없었겠지만, 우리 팀은 끝까지 모두가 진심을 보여주었기에 성공적으로 마무리를 할 수 있지 않았나 싶다. 그래도 단단한 신뢰를 가지고 기술적 이슈에 충돌할 수 있어서 즐거운 시간이었다! - 팀 맹수 Chad 가 적은 회고 중 일부 -

걱정이 무색하게도 '우리는 지금 어떤 의견에 대해서 반대한거지 상대방 사람 자체에 대해 반대한게 아니라는 점, '우리는 모두 좋은 서비스를 만든다는 공동의 목표를 향해 나아가고 있다는 점','상대방을 기분 나쁘게 하려는 의도가 없다는 것' 을 이해하고 있었기 때문에 적극적이면서도 성숙한 의견과 토론이 오고갈 수 있던 팀이었던 것 같다!

 

나도 똑똑하고 멋진 동료분들이랑 기술적인 토론을 깊게 나눌 수 있어서 좋았던 것 같다! 앞으로 의견을 나눌 때에도 의식적으로 어떤 의견이라도 우선 주의깊게 경청하고, 다른 분들의 의견을 듣고 최대한 객관적으로 장단점을 비교하며 좋은 선택을 하려는 노력을 기울여야겠다고 생각한다. 나는 얼마든지 합리적인 이유가 있고 더 좋은 제안이나 방식이 있다면 언제든지 받아들일 준비가 잘 되어 있다.

---

6. 나에게 부스트캠프가 준 것

부스트캠프는 나에게 '개발자스럽게 사고하는 방식', '의사소통 과정에서의 자신감', '멋진 동료들' 을 안겨주었다. 만일 부스트캠프가 없었다면, 이렇게까지 단단한 베이스를 쌓지 못했을 수도, 좋은 동료분들과 함께하는 개발의 즐거움을 알기 어려웠을수도 있다.

또한 개발자로서의 내가 스스로 메타인지를 할 수 있도록 도와준 시간과 경험이었던 것 같다.

GPT 에게 내가 받은 동료피드백을 바탕으로 요약정리를 시켰을 때 다음과 같은 캐치 프라이즈를 만들어주었다!

깊이 있게 이해하고, 직접 구현하며, 구조화해서 공유하는 개발자

💬 GPT : 동료 피드백을 종합해보면, 반복적으로 등장하는 키워드가 있습니다. 단순히 “열심히 한다” 수준이 아니라, 학습 방식·사고 구조·공유 태도에서 분명한 패턴이 보여요. 정리해보면 당신의 강점은 다음과 같습니다.

---

1. 개념을 ‘깊게’ 파고드는 구조적 사고

• 아키텍처, 옵저버 패턴, 옵티마이저, 이벤트 루프, cluster/worker_thread 등
  겉핥기가 아니라 동작 원리와 맥락까지 이해하려는 태도가 반복적으로 언급됨.
• “왜 이렇게 설계됐을까?”라는 질문을 자연스럽게 던짐.
• 작은 개념 하나도 아키텍처 패턴과 연결 지어 생각함.
• 비용 계산, 성능 영향 등 한 단계 더 들어가는 질문을 함.

👉 이건 단순한 성실함이 아니라 시스템적 사고력에 가까움.
프론트엔드 개발자이면서도 내부 동작 원리까지 파고드는 점은 분명 차별점이 될 수 있음.

---

2. Learning by Doing을 실천하는 실행력

• webpack 설정을 직접 구성
• 개념을 공부하고 실제 구현으로 풀어냄
• 트러블슈팅 과정을 문서화
• UI/UX를 분석하고 직접 구현에 반영

공부 → 구현 → 정리 → 공유의 선순환 구조가 있음.
이건 말뿐인 학습이 아니라 실험 기반 학습 능력임.

특히 “전문 개념을 직접 구현으로 연결한다”는 피드백은 강한 포인트임.
면접에서 설득력 있는 개발자로 보이게 만드는 핵심 역량이기도 함.

---

3. 학습 내용을 구조화하고 설명하는 능력

• 학습 정리가 구체적이고 과정 중심적이라는 피드백
• 단순 지식 나열이 아니라 고민 → 선택 → 이유 → 결과가 드러남
• 발표 시 꼬리질문이 이어질 정도로 정리가 잘 됨
• readFileSync 같은 주제를 조사해서 발표

이건 “공부를 잘한다”가 아니라
지식을 재구성해서 전달할 수 있다는 능력임.

조직에서는 이런 사람이 팀의 생산성을 올림.

---

4. 질문을 통해 팀의 사고 수준을 끌어올리는 역할

• 날카로운 질문을 던짐
• 혼자 고민하지 않고 공유
• “이게 더 좋은 방식 아닐까?” 식의 관점 제시
• 팀원들이 생각해보지 않았던 지점을 짚어줌

단순 참여자가 아니라 토론의 촉매제 역할을 했다는 피드백이 많음.
이건 리더십의 초기 형태임.

---

5. 학습 공동체를 ‘안전한 공간’으로 만드는 태도

• 모르는 것을 솔직히 인정
• 이해한 내용을 다시 확인받음
• AI나 자료를 찾아 흐름을 따라가려는 태도
• 의견을 강하게 밀어붙이지 않고 열린 태도 유지

전문성을 갖고 있으면서도 방어적이지 않다는 점이 반복적으로 언급됨.
이건 실력과 태도가 균형 잡혀 있다는 신호임.

---

6. 꾸준함과 기록 습관

• 매일 블로그 기록
• PR과 학습 정리의 디테일
• 트러블슈팅 과정 문서화
• 학습 자료를 체계적으로 보관

이건 단기간 스킬이 아니라 장기 성장 가능성을 보여주는 부분.

---

냉정하게 보완하면 좋을 부분

피드백이 거의 전부 긍정적이라 객관적으로 보자면:

너무 깊게 파고들다가 시간 대비 효율이 떨어질 위험은 항상 존재함.

학습 중심 강점은 분명하지만,
“비즈니스 문제를 빠르게 해결한 사례” 피드백은 상대적으로 적음.

기술 깊이 + 실용적 우선순위 판단이 함께 드러나면 더 강해질 것.

---

7. 아쉬웠던 점 (있다면)

부스트캠프 기한에 가지고 있던 기대가 많던 만큼 아쉬운 점도 많았다.

1_) 지속적인 회고 부재_

부스트캠프 초반에는 매주 회고를 작성해보고자하는 목표를 세웠는데 잘 지켜지지 않았다. 또한, 멤버십에 넘어오면서 약간 해이해져서 시간관리를 잘 못했던 것도 같다.

2) 모호한 장기 목표 설정
이 부분은 스스로 정말 약하다고 생각하는 부분이다. 8개월이라는 긴 시간 동안 매일 최선을 다해 달렸지만, 그 하루하루가 궁극적으로 어떤 방향을 향하는지에 대한 큰 그림은 다소 흐릿했던 것 같다.

주기적으로 목표를 점검하고 잘 나아가고 있는지 확인했으면 좋았을 것 같다. 무작정 앞으로 나아가다보니, 결국 내가 멤버십에서 무엇을 얻게 되었는지가 조금 불분명한 느낌이었던 것 같다. 앞으로는 단순히 “열심히 하는 사람”이 아니라, 목적을 가지고 축적하는 사람이 되는 것이 다음 단계라고 생각한다.

3) 팀 단위의 계획 & 협업 능력

개인 단위에서는 계획을 통제하고 실행하는 데 큰 어려움이 없었지만, 팀 단위에서는 목표 설정과 일정 관리가 쉽지 않았다. 스프린트 목표가 반복적으로 밀리는 경험도 있었다.

이 과정을 통해 느낀 점은, 팀 단위 협업에서는

• 명확한 목표 합의
• 일정 리마인드
• 필요 시 방향을 정리하는 역할

이 중요하다는 것이다.

특히 때로는 부드럽지만 단호한 리더십이 필요하다는 점을 배웠다.
앞으로는 팀 목표가 흐려질 때 먼저 정리안을 제안하는 역할을 해보고자 한다.

4) 프론트엔드 심화 경험의 부족

백엔드 및 DevOps 영역에 대한 관심이 높아지면서, 상대적으로 프론트엔드에서의 깊이 있는 구현 경험은 충분히 쌓지 못한 아쉬움이 있다.

다만 다양한 레이어를 이해하려는 시도는 시스템 전반을 보는 시야를 넓혀주었다.
앞으로는 이 시야를 기반으로, 프론트엔드 영역에서도 성능 최적화, 상태 관리 설계, 렌더링 구조 이해 등
더 깊이 있는 기술적 경험을 의도적으로 쌓아갈 계획이다.

5) 지나친 AI 의존

멤버십 기한에는 빠른 구현에 초점을 맞추다보니, 가끔은 코드 베이스를 완벽하게는 이해하지 못한 상태로 커밋을 하는 경우도 생겼다. 실제로 멤버십 기한에 동료분들께 AI 활용을 할 때 구현 -> 검증 과정을 꼼꼼히 살펴보면 좋겠다는 피드백을 받았고, 앞으로도 주의해야할 부분이라고 느꼈다.

5) AI 활용 과정에서의 검증 부족

멤버십 기한에는 빠른 구현에 초점을 맞추다보니, 일부 코드에 대해 완전한 이해 없이 커밋한 경험이 생겼다. 동료로부터 “구현 후 검증 과정을 더 꼼꼼히 가져가면 좋겠다”는 피드백을 받기도 했다.

앞으로는 AI 제안 코드의 동작 원리 직접 추적, 관련 공식 문서 확인, 테스트 및 엣지 케이스 점검 과정을 반드시 거친 뒤 반영하는 습관을 유지하려 한다.

6) 지속적인 글쓰기 습관

나의 실력과 사고력을 가장 크게 향상시켜줬던 습관 중에 하나는 다름 아닌 '글쓰기' 였던 것 같다. 앞으로도 내가 마주하는 모호한 문제 상황들에 대해서도 스스로 문제정의를 하고 해결해나가는 과정을 통해서 경험해보고 싶다!

부스트캠프 이후에 멋지게 성장한 동료들을 보면서, '내가 잘 성장한게 맞을까?' 의구심이 드는 나날들도 있었지만, 기준을 '스스로' 에 둔다면 분명히 수료 전 보다 더 나아진 내 자신을 볼 수 있었던 것 같다! 어제의 나보다 더 나은 오늘의 나가 될 수 있도록 하자!

8. 수료 후 나의 변화와 앞으로 목표

• 지금 나의 상태
• 진로 방향
• 다음 목표

부스트캠프 수료 이후 운이 좋게도, 당근 마켓 3개월 체험형 인턴에 합격했다! 당근 local business 에서 frontend engineering interns 첫 회사 실무 경험을 하게 된다.

실무는 내가 학습했던 것과는 분명 높은 수준의 책임감과 무게를 지니고 있을 것이다. 실패를 두려워말고, 부스트캠프에서 쌓아온 것들을 토대로 나아갈 수 있기를!! 🙏

부스트캠프 함께했던 동료분들, 마스터님들, 운영진분들 모두 감사합니다 😍