배움을 원하는 사람

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

raven — Thu, 19 Feb 2026 06:07:29 +0900

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

25년도 6월부터 시작했던 8개월간의 베이직 -> 챌린지 -> 멤버십 과정을 마무리하며, J123_박준호로 지내오던 기간 동안 얻은 경험 + 배운 점들을 정리해 보려고 합니다.

후기가 아닌, 그냥 제가 배운 점들을 나열하는 글이 될 수도 있습니다.

그런데도, 배운 점들을 최대한 자세히 기록해서, 나중에 다시 읽었을 때, 그때의 경험과 배운 점들이 떠오를 수 있도록 작성해 보려고 합니다.

그리고 혹시라도 이 글을 읽는 누군가에게도 도움이 될 수 있다면 좋겠습니다.

> 베이직 후기 바로가기

[네부캠 10기] 웹 풀스택 베이직 후기

우선 저는 이번년도 2월에 4년제 컴퓨터공학과 졸업을 하고 방황하는 상태였습니다. 막연히 하반기 취업을 목표로 두었고, 그 목표를 위해서, 개인 프로젝트도 만들고, 코딩 테스트를 대비하기

r4b2.tistory.com

> 챌린지 후기 바로가기

[네부캠 10기] 웹 풀스택 챌린지 후기

네이버 부스트캠프 챌린지 후기챌린지가 끝나고 한참 지난 이 시점에 이제서야 회고를 적게되었습니다;계기: 전 수료생분들이 기록의 중요성을 언급해주셔서 작성하게 되었습니다. 정말 짧게

r4b2.tistory.com

1. 들어가며 - 지원하게 된 배경과 계기

25년도 2월 대학 졸업 후, 저는 약 4개월간 방황하며 취업 준비를 하고 있었습니다.

혼자서 만들고 싶은 프로그램을 만들기도 하고, 코딩테스트를 위한 알고리즘도 풀어보고, 나름의 노력을 했지만, 시간이 지날수록 한계를 느꼈습니다.

여태까지 해온 것처럼, 혼자서만 하는 코딩은 편했지만, 동시에 제 코드가 우물 안 개구리의 결과물은 아닌지 검증할 길이 없었기 때문입니다.

이렇다고 할 프로젝트 경험도 없었고, 평가할 수 있는 동료도 없었고, 그저 길을 잃은 채 취업이라는 현실과 내가 하고 싶은 개발과 보안 사이에서 방황하던 시기였습니다.

그러던 중 우연히 네이버 부스트캠프 10기 모집 공고를 접하게 되었고, 과감하게 "일단 뭐라도 해보자"라는 마음으로 지원하게 되었습니다.

저는 이전에 주로 타입이 있는 언어(C/C++/C#/Java 등등…)로 윈도우에서 개발해 왔었습니다.

개인적으로 Python이나 JavaScript를 사용해 봤을 때, 이게 얕은 복사인지, 깊은 복사인지, 포인터 참조인지, 함수 포인터인지, 클래스의 참조인지, 인터페이스의 참조인지, 이런 부분들이 명확하게 구분되지 않고, 언어적으로도 명확하게 표현되지 않는 부분들이 많아서, JavaScript나 Python으로 개발하는 것에 대한 어려움이 있었습니다.

따라서 부스트캠프에서는 웹 풀스택을 다루는 만큼, JavaScript, TypeScript를 사용하는 부분이 저에게는 낯설고, 어려운 부분이 많을 것이라는 생각이 들었습니다.

또한 프론트엔드 개발에 대한 경험도 없었고, 프론트엔드 개발이 백엔드 개발보다 쉽다는 편견도 가지고 있었습니다.

HTML/CSS/React 등 프론트엔드 기술을 굳이 배워야 할 필요성을 느끼지 못했고, 프론트엔드 개발이 디자이너에 가까운 영역이라는 생각도 가지고 있었습니다.

이 오만함을 깨부수는 부분은 밑에서 더 자세히 다루도록 하겠습니다.

그런데도 지원하게 된 이유는 다음과 같습니다.

혼자서만 진행하는 만드는 사이드 프로젝트를 떠나서, 동료와 협업을 통해 완성도 높은 결과물을 만들어보고 싶었습니다.
파편화된 지식보다는 체계적이라는 느낌이 드는 커리큘럼을 통해서 공부를 해보고 싶었습니다.
AI가 빠르게 발전하는 시대에, AI를 활용한 개발 경험을 해보고 싶었습니다.
앞으로는 개발자가 특정 분야에만 국한되지 않고, 다양한 분야의 기술과 경험을 갖춰야 할 것으로 판단했습니다.
같은 목표를 가진 동료들과 의사소통하면서 성장해 보고 싶었고, 그 과정에서 제가 부족한 점들을 깨닫고 개선해 보고 싶었습니다.

이 외에도 여러 가지 이유가 있었지만, 가장 큰 이유는 위의 다섯 가지였습니다.

정말 운이 좋게도 베이직 -> 챌린지 과정을 거쳐 멤버십에 입과 하게 되었고, 아래부터는 멤버십 과정에서 제가 배운 점들을 최대한 자세히 기록해 보도록 하겠습니다.

2. 근거 없는 개발 습관을 깨닫다

부스트캠프에 들어와서 가장 먼저 깨달은 점은, 제가 생각보다 근거가 많이 부족한 채로, 그저 관성과 경험에 의존해서 개발해 왔다는 사실이었습니다.

예를 들어, "왜 이 코드를 이렇게 작성했는가" 에 대해서, 명확하게 답할 수 없는 순간들이 많았습니다.

그렇지만 이 과정을 보내면서, 코드에 근거가 필요한 이유와, 기술을 선택할 때도 근거가 중요하며, 그 근거를 타인에게 설명할 수 있어야 한다는 점을 깨닫게 되었습니다.

매주 주어지는 과제를 수행하면서, 새로운 동료들과 함께 코드 리뷰를 하고, 피드백을 주고받으면서, 내가 작성한 코드를 설명해야 했고, 그 과정에서 내가 왜 이런 코드와 기술을 선택했는지 설명하고, 문서화하는게 필수였습니다.

한번은 다른 동료분께서 이런 질문을 해주셨던 적이 있었습니다.

"이 라이브러리는 왜 사용하셨나요 ?"
"이 기술을 선택하신 이유가 무엇인가요 ?"
"왜 이 디자인 패턴을 선택하셨나요 ?"
"왜 이 구조로 코드를 작성하셨나요 ?"

이 질문들을 받았을 때, 나름 합리적인 이유가 있었음에도, 그 이유를 명확하게 설명하지 못했던 순간들이 많았습니다.

그리고 경험에 의거하여 이런 대답을 한 적도 있었습니다.

"이 라이브러리는 제가 예전에 사용해 봤던 라이브러리라서 익숙해서 사용했습니다."
"이러한 문제가 과거에 있었는데, 이 기술을 사용해서 해결한 경험이 있어서 선택했습니다."
"이 디자인 패턴은 제가 이전에 사용해 봤던 패턴이라서 익숙해서 선택했습니다."
"이 구조로 코드를 작성한 이유는, 책임 분리를 좀 해두면 유지 보수하기 편할 것 같아서였습니다."

언뜻 보면 그럴듯한 대답처럼 보이지만, 자세히 들여다보면, 경험에 의존해서 익숙하다는 이유로 기술을 선택했다는 점에서, 근거가 부족하다는 것을 알 수 있었습니다.

이 부분을 보완하기 위해, 자연스럽게 코드에 근거를 갖추는 습관이 생기게 되었고, 기술 선택에서도 근거를 생각하는 습관이 생기게 되었습니다.

결국 개발자는 기술을 선택하는 사람이고, 그 기술을 선택하는 이유와 근거가 명확해야, 다른 사람들과 협업할 때도, 그리고 나중에 내가 다시 코드를 봤을 때도, 이해하기 쉽고 유지 보수하기 쉬운 코드가 될 수 있다고 생각합니다.

그래서 앞으로는 항상 트레이드-오프를 생각하고, 다른 대안은 무엇이 있는지, 그리고 내가 선택한 기술과 패턴의 근거는 무엇인지, 그리고 그 근거를 타인에게 설명할 수 있는지에 대해서 항상 고민하는 개발자가 되고 싶습니다.

3. 바닐라 JS로 이해한 프레임워크/라이브러리의 존재 이유

학습 스프린트 초기 단계에서, Vanilla JS만으로 기능을 구현해야 했습니다.

처음에는 "왜 굳이 편한 도구를 놔두고?" 라는 의문이 들었지만, 직접 부딪히며 겪은 "생산성의 떨어지는 이슈" 와 "복잡한 코드로 인한 유지보수의 어려움" 이 프레임워크/라이브러리가 왜 탄생했는지를 몸으로 뼈저리게 느꼈습니다.

머리로 아는 것과, 직접 삽질하며 몸으로 느끼는 것은 천지 차이였습니다.

대표적으로 프론트엔드 개발에서, 상태 관리와 DOM 조작이 얼마나 복잡하고, 버그가 발생하기 쉬운지 경험하면서, React와 같은 라이브러리가 왜 필요한지를 체감할 수 있었습니다.

데이터가 변할 때마다 화면을 갱신하기 위해 옵저버 패턴을 직접 구현하고, subscribe와 notify를 통해 일일이 변화를 감지해야 했습니다.

데이터가 바뀌면, 특정 태그를 찾아서, innerHTML을 바꿔주고, 이벤트 리스너도 일일이 등록해 줘야 했습니다.

시간이 지나며 코드가 길어질수록 로직은 비대해졌고, 버그도 자주 발생하고, 가독성은 떨어지고, 유지보수는 어려워졌습니다.

더 중요한 문제는 성능이었는데, 데이터 하나를 바꾸기 위해서 무식하게 DOM 전체를 다시 렌더링하는 방식이었기 때문에, 데이터가 많아질수록 성능이 급격히 떨어지는 것을 경험했습니다.

이러한 과정에서, 이래서 React의 Virtual DOM이 필요한 거구나, 상태 관리 라이브러리가 필요한 거구나, 프레임워크가 필요한 거라는 것을 몸으로 느꼈습니다.

백엔드 개발에서도 이와 비슷한 경험이 있었습니다.

http 모듈만으로 서버를 띄우고 요청을 직접 처리하려니, 들어오는 패킷과 요청을 일일이 파싱하고, 라우팅도 직접 구현해야 했습니다.

또한 보안적인 부분도 직접 신경 써야 했는데, CSRF, XSS, SQL Injection과 같은 공격에 대한 방어 코드를 일일이 작성해야 했습니다.

에러처리, 미들웨어, 라우팅, 세션, 쿠키 등 여러 가지 기능을 직접 구현하려니, 코드가 복잡해지고, 버그도 자주 발생하고, 유지보수도 어려워졌습니다.

무엇보다 자유도가 높다 보니, 구조를 어떻게 짜야 할지, 어떤 패턴을 사용해야 할지, 어떤 라이브러리를 사용해야 할지, 이런 부분에서 고민이 많아졌습니다.

따라서 이런 경험을 통해서, 프레임워크나 라이브러리가 복잡한 로직들을 개발자 친화적으로 추상화해서 제공해 주는 이유를 깨닫게 되었습니다.

4. 글쓰기와 문서화의 벽

개발자는 코드로 말한다고들 하지만, 실제로는 글로도 많이 말해야 하는 직업이라는 것을 깨닫게 되었습니다.

학습 스프린트 기간, 저는 PR과 문서에 배운 내용이라던가, 기술 선택의 이유라던가, 왜 이렇게 작성했고, 어떤 고민이 있었는지에 대해서 글로 작성하는 경우가 많았습니다.

제가 생각했던 선택지와 모든 생각들을 글로 작성해서 공유하게 된다면, 다른 사람들도 내가 왜 이런 선택을 했는지, 어떤 고민이 있었는지, 어떤 대안들이 있었는지, 이런 부분들을 이해할 수 있다고 생각했습니다.

하지만 실제로는 제가 구조화한 문서가 나에게는 잘 읽히지만, 다른 사람들에게는 잘 읽히지 않았다는 것을 깨닫게 되었습니다.

제가 쓴 글은 동료를 배려하지 않은 채, 그저 내 생각의 흐름을 그대로 쓴 글이었고, 다른 사람들이 읽기에 이해하기 어려운 암호문일 뿐이었습니다.

설마 이 글도…!? ㅠㅠ

나름 책도 많이 읽고, 글을 많이 읽어봤지만, 글을 잘 쓰는 방법에 대해서는 깊게 고민해 본 적이 없었고, 글쓰기의 중요성도 크게 느끼지 못했던 것 같습니다.

우선 머릿속에 있는 추상적인 개념을 남들이 이해하기 쉬운 언어로 정제해서 꺼내놓는 능력 자체가 부족했다는 것을 깨닫게 되었습니다.

대표적인 오류는 다음과 같습니다.

내가 아는 배경지식을 다른 사람들도 당연히 알고 있을 것으로 생각하는 오류
WHY와 HOW가 뒤섞여서 논리가 명확하지 않고, 생각의 흐름이 뒤죽박죽인 글을 쓰는 오류
줄글로만 장황하게 설명하려니 가독성이 떨어지고, 핵심이 잘 전달되지 않는 오류

이러한 글쓰기의 벽을 깨기 위해서, 글쓰기와 문서화에 대해서도 고민하기 시작했고, 어떻게 하면 다른 사람들이 이해하기 쉬운 글을 쓸 수 있을지도 고민하기 시작했습니다.

그래서 저는 코드를 리팩토링하는 것처럼, 글도 리팩토링하는 습관을 들이려고 노력했습니다.

처음에는 내가 잘 이해할 수 있고, 내 생각의 흐름을 그대로 담아 초안을 작성하고, 이를 AI를 통해서 문장과 표현을 다듬기도 하고, 시간순이나 논리 순으로 재구조화해서 글을 리팩토링하는 과정을 거치면서, 점점 더 읽기 쉽고, 이해하기 쉬운 글을 쓰려고 노력했습니다.

이모지도 절대로 쓰지 않겠다고 생각했지만, 글의 가독성과 이해도를 높이기 위해서, 적절히 이모지를 활용하는 것도 고려하게 되었습니다.

또한 10줄의 텍스트보다, 흐름을 보여주는 다이어그램이 더 이해하기 쉬울 수 있다는 점도 깨닫게 되었습니다.

이 후기 글을 쓰는 와중에도, 장황하게 설명하려는 경향이 있어서, 핵심을 잘 전달하기 위해서, 글을 계속 리팩토링하고 있습니다.

따라서 앞으로도 여건이 된다면, 책이나 기술 블로그, 미디엄 등 여러 가지 자료들을 접하고, 직접 작성해 보기도 하면서 점진적으로 글쓰기와 문서화의 능력을 키워나가고 싶습니다.

5. CS - 이론이 아니라 판단의 근거

네이버 부스트캠프 하면 CS가 빠질 수 없죠.

보통 CS 지식이라고 하면, 면접을 대비한 알고리즘과 자료구조, 그리고 컴퓨터 시스템에 대한 지식을 떠올리기 쉽지만, CS는 실제 개발에서 기술 선택과 설계의 근거가 된다는 점을 느꼈습니다.

코드를 짜다 보면 분명히 막히는 순간이 오게 됩니다.

왜 이 비동기 처리는 순서대로 실행되지 않는 걸까 ? -> 이 부분은 자바스크립트의 이벤트 루프와 태스크 큐에 대한 이해가 필요하구나
왜 데이터가 많아지면 서버가 멈출까 ? -> 이 부분은 메모리 관리와 가비지 컬렉션에 대한 이해가 필요하구나
왜 이 코드는 보안 취약점이 있을까 ? -> 이 부분은 CSRF, XSS, SQL Injection과 같은 공격에 대한 이해가 필요하구나
왜 이 쿼리는 느릴까 ? -> 이 부분은 데이터베이스의 인덱스와 쿼리 최적화에 대한 이해가 필요하구나
왜 로컬에서는 잘 되는데, 배포하면 안 될까 ? -> 이 부분은 네트워크와 배포 환경에 대한 이해가 필요하구나

이런 식으로 여러 가지 문제들을 직접 겪으면서, 실제 개발에도 CS 지식이 필요하다는 것을 몸으로 느꼈습니다.

또한 기술 선택과 설계의 근거에도 CS 지식이 필요한 경우가 많았습니다.

단적으로 RDBMS를 사용할지, NoSQL을 사용할지, 어떤 프레임워크를 사용할지, 어떤 디자인 패턴을 사용할지, 이런 부분에서도 CS 지식이 근거가 되는 경우가 많았습니다.

이 데이터는 정합성이 매우 중요하다 보니, ACID 트랜잭션이 지원되는 RDBMS가 필요하겠구나
이 서비스는 읽기 속도가 중요하고, 데이터가 많아질수록 캐싱 전략이 필요하겠구나
스키마 변경이 잦다 보니 유연한 스키마를 지원하는 NoSQL이 필요하겠구나

이와 같은 경험들이 앞으로는 CS의 중요성이 더더욱 커질 것이라는 생각이 들게 되었습니다.

프레임워크와 라이브러리는 몇 년마다 새로운 것들이 나오고, 트렌드도 빠르게 바뀌고, 언어도 끊임없이 변화하고 있습니다.

하지만 컴퓨터 구조, 네트워크, 운영체제, 데이터베이스, 보안, 알고리즘과 자료구조와 같은 여러 가지 CS 지식은 기술이 바뀌어도 변하지 않는 근본적인 지식입니다.

특히나 요즘같이 AI가 코드를 대신 작성해 주는 시대가 오면서, AI가 짠 코드가 효율적인지 검증하고, 전체 시스템의 아키텍처를 설계하며, 보안 취약점을 찾아내는 능력은 탄탄한 기본기와 CS 지식이 뒷받침되어야 가능하다고 생각합니다.

6. 시간 관리와 자기 객관화

부스트캠프의 스프린트는 짧고, 할 일은 많았습니다.

시간이 제한된 환경은 "나는 이만큼의 일을 하는 데 정확히 몇 시간이 걸리는 사람인가 ?" 라는 자기 객관화를 하게 만들었고, "이 작업은 내가 할 수 있는 작업인가 ?", "이 작업을 하는데 얼마나 시간이 걸릴까 ?", "이 작업을 하는 데 필요한 기술과 지식은 무엇인가 ?" 라는 질문들을 끊임없이 하게 만들었습니다.

처음에는 의욕이 충만했기에, 제 속도를 과대평가했습니다.

"이 정도 기능은 2시간 정도면 다 짜겠군." 이라고 생각했지만, 실제로는 트러블슈팅을 하면서 "이 기능을 완성하는 데 6시간이 걸렸네 ?" 라는 경험을 하면서, 제 작업량과 속도에 대해 객관적인 인식을 하게 되었습니다.

예상치 못한 버그가 발생할 수도 있고, 라이브러리 버전이나 구상했던 설계에서 문제가 생길 수도 있고, 내가 생각했던 것보다 구현이 더 복잡할 수도 있다는 점을 깨달았습니다.

이런 변수들을 계획에 반영하지 않으면, 계획이 무너질 수 있다는 점도 깨달았습니다.

제 계획은 "모든 것이 완벽하게 돌아갈 때" 를 가정한 희망 사항이었던 것 같습니다.

따라서 저는 작업 시간 추정 같은 부분에 대해서도 개발 실력의 한 부분이라고 생각하게 되었고, 앞으로는 작업에 걸리는 시간을 좀 더 객관적으로 추정하는 능력을 키우고 싶습니다.

내가 할 수 있는 작업량이 어느 정도인지 냉정하게 파악하고, 항상 예상치 못한 변수들이 발생할 수 있다는 점을 고려해서, 시간 배분과 계획을 세우는 능력을 키우고 싶습니다.

따라서 제가 수행한 방법은, 무리한 계획을 세우기보다, 여유 있는 계획을 세우고, 내가 확실하게 끝낼 수 있는 범위를 먼저 정하고, 그 범위 내에서 우선순위를 분배하고, 예상치 못한 변수들이 발생할 수 있다는 점을 고려해서, 시간 배분과 계획을 세웠습니다.

비록 계획이 완벽하지는 않았지만, 그래도 이전보다는 좀 더 현실적인 계획을 세우고, 그 계획에 맞춰서 작업을 진행할 수 있었던 것 같습니다.

7. "완성"의 의미 - 미완성은 미완성일 뿐

6번과 이어져서 제가 계획을 세울 때, "완성" 의 의미에 대해서도 고민하게 되었습니다.

한번은 프로젝트를 진행하면서 백엔드 보안과 예외 처리에 과도하게 집착했던 적이 있었습니다.

이 API는 이런 공격에 취약할 수 있으니, 이런 방어 코드를 작성해야겠다.
이 API는 보안이 중요하니, 모든 엣지 케이스에 대해서 예외 처리를 해야겠다.
이 API는 완성도가 중요하니, 모든 케이스에 대해서 테스트 코드를 작성해야겠다.

밤을 새워가면서 최대한 견고한 로직을 짰고, 제가 생각한 모든 시나리오에 대한 예외 처리를 했고, 모든 케이스에 대한 테스트 코드를 작성했습니다.

스스로 "완성" 이라고 생각했지만, 정작 마감 시간이 다가올 때, 프론트엔드에는 작업 시간을 할애하지 못해 화면은 텅 비어 있었고, 제가 할 수 있는 건, Postman으로 API를 호출해서, 제가 작성한 API가 동작하는 것을 보여주는 것뿐이었습니다.

이 미션을 끝내고, 시니어 리뷰어와의 피드백 세션에서 "테오" 님에게 피드백을 받으며 이러한 고민과 고충을 털어놓았던 적이 있었습니다.

teo (teo.v) / 작성글 - velog

개발과 인문학을 좋아하는 시니어 프론트엔드 개발자입니다. 내가 만든 컨텐츠와 개발이 누군가에게 도움이 되기를 바랍니다. 궁금한 점이 있다면 아래 홈페이지 버튼을 클릭해서 언제든지 오

velog.io

테오 님은 "완성" 의 의미에 대해서 이렇게 말씀해 주셨습니다.

테오 님: 완성은 했죠 ?

나: 완성을 못했습니다. 보안과 예외 처리를 완성하려다 보니, 프론트엔드 작업을 못 했어요. 완성했으면 더 좋긴 한데…

테오 님: "그건 "더 좋긴 한데"가 아니에요. 필수입니다.
코드를 80%만 완성했어요는 안 한 거하고 다를 게 없어요.

예외 처리를 투자하고 핸들링을 투자하는 이유는
제품의 완성도를 높이기 위한 겁니다.

완성도를 올리려면 제품이 완성되어 있어야 하고,
완성이 안 되어 있는데 특정 부분만 올렸다고 해서
완성도가 생기는 건 아닙니다.

회사 일이던 개발자로서든, 마감이 있고 코드가 있을 때는
마감이 훨씬 더 중요합니다. 항상 완성을 먼저 생각하세요."

개발자는 항상 저점으로 평가받습니다. 완성하지 못한 부분이 있으면, 완성하지 못한 부분 때문에 평가받게 됩니다.

예를 들어 A라는 은행 앱에서 송금이 잘 안된다면? 어떻게 될까요 ?
아무리 다른 기능이 완성도가 높아도, 송금이 안 된다는 사실 하나 때문에, 그 앱은 "송금이 안 되는 앱"으로 평가받게 될 것입니다.

따라서 저는 이렇게 생각했습니다.

시간의 압박 속에서도, 완성을 최우선으로 생각하고, 완성도를 점차 높여가는 것이 중요하다는 점을 깨달았습니다.

그렇지만 너무 완성에만 집착해서, 코드의 품질이나 보안, 예외 처리, 테스트 코드 작성과 같은 부분들을 너무 소홀히 하는 것도 좋지 않다고 생각합니다.

기술 부채를 잔뜩 쌓아놓고 완성된 제품을 만드는 것은, 오히려 완성된 제품이 없는 것보다도 나쁠 수 있다고 생각합니다.

따라서 너무 어려운 부분이라고 생각이 듭니다. ㅠㅠ

8. 협업의 첫걸음 - 규칙과 컨벤션

처음 그룹 스프린트에서, 팀원들과 협업하면서 여러 가지 컨벤션과 규칙들을 세워보는 경험을 했습니다.

프로젝트 초반에, 팀원분께서 제안하신 컨벤션과 규칙들은 처음에는 저에게 정말 낯설고, 불편한 것들이 많았습니다.

기능 하나 만들 때마다 이슈를 올리고, 브랜치를 따고, PR을 올리고, 리뷰를 받고, 머지를 하는 과정이 너무 번거롭게 느껴졌습니다.
코드 스타일과 커밋 메시지 컨벤션을 지키는 것도 귀찮게 느껴졌습니다.
또한 작은 단위로 커밋을 나누고, 작은 단위로 PR을 올리는 것도 너무 번거롭게 느껴졌습니다.

당시의 저는 프로젝트 경험이 거의 없었고, 혼자서 개발할 때 master 브랜치에 왕창 커밋만 떄리는게 익숙했기 때문에, 이런 협업의 규칙과 컨벤션이 너무 낯설고, 불편하게 느껴졌던 것 같습니다.

처음에는 이러한 규칙에 적응하기 어려워서 "기능 구현하기에도 벅찬데, 이런 형식까지 맞추느라 시간을 태워야 하나 ?", "그냥 빨리 왕창 만들어서 합치고, 다음 기능 만들면 안 되나 ?" 라는 생각이 들었던 것 같습니다.

하지만 프로젝트가 진행되고, 저한테 적응이 되면서, 이러한 규칙들의 진가가 드러나기 시작했습니다.

특히 Husky, ESLint, Prettier가 세팅된 환경은 코드 스타일을 자동으로 맞춰주고, 커밋 메시지 컨벤션을 강제해 주는 덕분에, 코드 리뷰에서 스타일과 컨벤션 문제로 피드백이 오는 일이 줄어들어서, 코드 리뷰가 기능과 로직에 대한 피드백에 집중할 수 있게 되었습니다.

대충 짜도 저장만 하면 줄 간격과 들여쓰기, 세미콜론, 따옴표 등이 자동으로 맞춰지고, Husky가 커밋 전에 린트 돌려서 에러도 잡아주고, 커밋 메시지 컨벤션도 맞춰주니까, 스타일과 컨벤션에 대한 걱정이 줄어들어서, 기능과 로직에 더 집중할 수 있게 되었습니다.

시간이 지나며 코드가 방대해질수록, 불만은 사라지고, 오히려 이러한 규칙과 컨벤션이 없었다면, 코드 스타일이 제각각이고, 커밋 메시지가 제멋대로라서, 코드 리뷰에서 스타일과 컨벤션 문제로 피드백이 계속 왔을 것이고, 기능과 로직에 대한 피드백에 집중하기 어려웠을 것이라는 생각이 들었습니다.

이제는 확실히 알았습니다.

협업에서 규칙은 족쇄를 채우는 게 아니라, "우리 팀이 무너지지 않고 끝까지 달릴 수 있게 해주는 안전장치" 라는 것을요.

9. 생각을 꺼내놓는 법 - 시각화와 정리

저는 부스트 캠프를 진행하면서, 생각의 늪에 빠져있었습니다.

밥을 먹을 때도, 씻을 때도, 심지어 자려고 누운 순간까지도 머리에서는 "이 기능을 어떻게 구현하지 ?", "이 문제는 어떻게 해결하지 ?", "이 기술을 선택하는 이유는 무엇이지 ?", "이 설계는 왜 이렇게 했지 ?" 라는 생각들이 끊임없이 떠올랐습니다.

그러다 보니 자연스럽게 제가 자는 시간 외에는 모든 시간이 코딩이었고, 제 삶은 점점 사라지게 되었습니다.

여기서 문제점은, 생각이 많은 게 문제가 아니라, 설계나 구상이 머릿속에서만 존재하다 보니, 기준 없이 계속 생각이 꼬리에 꼬리를 물고, 생각의 늪에 빠져서, 결국에는 기준 없이 계속 바뀌게 되는 것이었습니다.

"이 구조보다는 이 구조가 더 나을 것 같은데 ?"
"이 라이브러리보다는 이 라이브러리가 더 나을 것 같은데 ?"
"이 디자인 패턴보다는 이 디자인 패턴이 더 나을 것 같은데 ?"
"이 기술 스택보다는 이 기술 스택이 더 나을 것 같은데 ?"
"이 설계보다는 이 설계가 더 나을 것 같은데 ?"

머릿속에서 건물을 짓는다고 생각해 보면, 설계도가 없이 머릿속에서만 건물을 짓는 것과 같았습니다.

생각은 정말 빠르게 시시각각 바뀌기에 마치 휘발성 메모리 같았습니다. ㅋㅋ

이를 어딘가에 저장하지 않다 보니, 제 뇌는 과부하가 걸려 잠을 자도 잔 것 같지 않고, 밥을 먹어도 먹는 것 같지 않고, 씻어도 씻는 것 같지 않은 상태가 계속되었고, 결국에는 최악의 컨디션이 이어져서, 감기를 달고 살았습니다.

앞서 테오 님에게 시니어 리뷰를 받았다고 말씀드렸는데, 그때 테오 님이 해주신 피드백 중에서 가장 기억에 남는 피드백이 바로 "생각을 꺼내놓는 법" 에 대한 피드백이었습니다.

생각을 꺼내놓으세요.

생각이라는 것은 에너지를 정말 많이 쓰는 작업입니다.

오전 9시부터 새벽 3시까지 생각을 그렇게 많이 하는데 안 힘들 리가 없어요.

생각을 좀 놓던지, 아니면 생각을 꺼내놓는 겁니다.

머릿속에 있으면 계속 생각해야 하니까, 꺼내놓기 위해 그림을 그린다거나, 적어본다거나, 형상화하세요.

그 길로 조언해 주신 방법의 하나인 "화이트보드 그리기" 를 시도해 봤습니다.

머릿속을 둥둥 떠다니던 추상적인 로직과 아키텍처와 설계와 기술 선택과 같은 생각들을, 화이트보드에 그려보면서, 생각을 꺼내놓는 연습을 해봤습니다.

플로우차트나, 다이어그램을 그려보고, 마인드맵을 그려보고, 글로도 작성해 보다 보니, 이전보다는 엉켜있던 생각들이 좀 더 명확해지고, 기준이 생기고, 다른 사람들에게도 설명하기 쉬워졌던 것 같습니다.

또한 어제 했던 고민이 화이트보드에 그대로 남아있다 보니, 오늘 다시 처음부터 생각을 다시 하는 게 아니라, 어제 했던 생각에서 이어서 생각할 수 있게 되어서, 생각의 흐름이 끊기지 않고, 생각의 늪에 빠지는 것도 줄어들었던 것 같습니다.

따라서 "생각은 항상 변한다, 그래서 생각을 꺼내놓는 연습을 하자" 라는 교훈을 얻었습니다.

개인적으로 부스트캠프 과정에서 저에게 가장 큰 성장이 아니었을까, 라는 생각입니다.

10. 모두가 같지 않다는 것

개발 외적으로도 깨달은 부분들이 많습니다.

협업 과정에서 다양한 상황들이 있는데, 이는 결국 내가 생각하는 "당연함" 이 타인에게는 "당연하지 않음" 이 될 수 있다는 것을 깨닫게 되었습니다.

프로젝트 초반에는 의아한 상황들이 많았습니다.

"왜 이 부분은 이렇게 하는 게 당연하다고 생각하지 ?"

과거의 저라면 속으로 답답해하거나, 제 의견만이 "정답" 이라고 고집했을지도 모릅니다.

하지만 대화를 나누다 보니 알게 되었습니다.

그 사람의 선택은 틀린 것이 아니라, 저와 살아온 배경과 경험한 프로젝트의 성격이 달랐기에 나온, 그 사람의 맥락에서는 지극히 타당한 결론이었다는 것이라는걸요.

서로 다른 근거와 배경을 가진 사람들이 모였기에 발생하는 자연스러운 상황이었고, 그 상황에서 서로의 의견을 존중하고, 이해하려고 노력하는 것이 중요하다는 것을 깨닫게 되었습니다.

이를 인정하고, 서로의 의견을 존중하다 보니, 갈등이 아닌, 건설적인 토론이 가능해졌고, 시야를 넓히는 경험이 되어서 개인적으로는 정말 큰 성장의 경험이었습니다.

또한 반성하고 배운 점도 있었는데, 열정의 기준에 대한 것입니다.

저는 부스트캠프 기간 제 모든 시간과 에너지를 전부 코딩에 쏟아붓는 열정을 보여주려고 노력했습니다.

그러다 보니 무의식에 제 기준을 타인에게 투영하는 경우가 많았던 것 같습니다.

하지만 어느 순간 이런 생각이 들었습니다.

"내가 이렇게 열심히 하는데, 왜 다른 사람들은 이렇게 열심히 안 하지 ?"
"누군가는 생계를 위해 아르바이트를 해야 할 수도 있고, 말 못 할 개인적인 사정이 있을 수도 있겠다."

저한테는 그저 올인하는게 당연한 열정의 모습이었지만, 다른 사람들에게는 그게 당연하지 않을 수도 있다는 것을 깨닫게 되었습니다.

누군가에게는 주어진 환경에서 시간을 쪼개 참여하는 것 자체가 그 사람이 할 수 있는 최선의 열정의 모습일 수도 있다는 것을 깨닫게 되었습니다.

타인의 노력을 함부로 재단하거나, 타인의 열정을 함부로 평가할 자격은 그 누구에게도 없다는 것을 깨닫게 되었습니다.

따라서 저는 나의 의도가 무엇인지, 내가 왜 이렇게 생각했는지, 나의 상황은 어떠한지 이런 부분들을 당연하게 생각하지 않고, 설명하고 공유하는 노력을 해야겠다는 생각이 들었습니다.

개발자로서의 협업 스킬보다는, 어찌 보면 인간으로서의 협업 스킬에 대한 깨달음이었던 것 같습니다.

11. 방 밖으로 나오다 - 커뮤니케이션의 중요성과 성장

부스트캠프에 들어오기 전에, 제 세상은 제 방이 전부였습니다.

오랫동안 혼자 코딩하다 보니, 낯선 사람을 대하는 것이 어색해졌고, 사회성이라는 근육이 많이 약해졌던 것 같습니다.

실제로 근육도 8kg이 빠졌어요

새로운 사람을 만나는 설렘보다는, "내가 저 사람들과 잘 어울릴 수 있을까", "내가 저 사람들에게 어떻게 보일까", 이런 경계심과 두려움이 더 컸던 것 같습니다.

하지만 부스트캠프라는 환경은 저를 방 안에 가만히 두지 않았습니다.

랜덤으로 매칭되는 피어 세션, 팀 프로젝트, 시니어 리뷰, 그리고 매일매일의 커뮤니케이션이 저를 방 밖으로 나오게 했습니다.

쉴 새 없이 이어지는 모각코와 슬랙 메시지, 기술 토론, 회의 등등 처음에는 이런 상황들이 너무 낯설고, 너무 부담스럽게 느껴져서 텍스트 뒤에 숨기도 했습니다.

하지만 시간이 지나면서, 이런 커뮤니케이션이 저에게도 익숙해지고, 오히려 즐거워지기 시작했습니다.

가장 기억에 남는 순간은 오프라인 만남이었습니다.

매번 줌이나 채팅으로만 보던 동료들을 직접 만나서, 얼굴을 보고, 목소리를 듣고, 대화를 나누는 경험이 특별했습니다.

처음에는 어색했지만, 시간이 지나면서 자연스럽게 대화가 이어지고, 서로의 이야기를 듣고, 개발 이야기도 하고, 인생 이야기도 하고, 주식/코인 이야기(?), 금연 이야기(?), 한탄(?)도 하면서, 정말 소중한 추억이 되었습니다.

아 멤버십 시작 전에 코인 팔껄...

그렇다 보니 제가 놓친 부분이 무엇인지 알게 되었습니다.

코드는 결국 컴퓨터가 실행하지만, 코드를 만드는 건 결국 사람이고, 혼자서 모든 것을 할 수 있는 개발자는 없다는 점입니다.

개발자도 결국은 사람이고, 사람과의 커뮤니케이션이 중요하다는 점입니다.

이제는 방구석에 혼자 코딩하는 개발자가 아니라, 사람들과 함께 협업하는 개발자가 되고 싶다는 생각이 들었습니다.

12. 프론트엔드에 대한 편견을 깨다

나도 모르게 가지고 있던 편견

솔직히 고백하자면, 부스트캠프 입과 전까지는 오만함을 가지고 있었습니다.

"프론트엔드는 백엔드보다 쉬울 것이다."
"프론트엔드는 디자인과 UI에 치중해서, 백엔드보다 기술적으로 깊이가 얕을 것이다."

은연중에 백엔드는 "데이터를 다루는 진짜 엔지니어링" 이고, 프론트엔드는 "화면을 그리는 작업" 이라는 편견이 있었던 것입니다.

복잡한 알고리즘이나 최적화, 시스템, 아키텍처는 백엔드만의 전유물이라고 생각했고, 프론트엔드는 상대적으로 배우기 쉽고, 깊이가 얕다고 멋대로 판단한 저의 오만함이 있었습니다.

이 편견은 아마도 제가 이전에 프론트엔드를 HTML/CSS/JS로 간단하게 레이아웃만 잡는 수준으로만 경험해 보기도 했고, 디자인 감각과 미적 감각이 구린(?) 편이기도 했고, 프론트엔드 개발자들이 디자인과 UI에 치중하는 모습을 보면서, 프론트엔드는 기술적으로 깊이가 얕다고 멋대로 판단했던 것 같습니다.

편견이 깨진 계기

하지만 부스트캠프에서 Vinila JS로 SPA를 직접 구현하고, 복잡한 상태 관리와 DOM 조작을 경험하면서, 프론트엔드 개발이 생각보다 훨씬 더 복잡하고, 기술적으로도 충분히 깊이가 있다는 것을 깨닫게 되었습니다.

서버에서 데이터를 받아오는 시점과 화면에 렌더링 되는 시점이 달라서, 상태 관리가 복잡하다는 점
데이터 하나가 변했을 때, 의존성 있는 컴포넌트들이 어떻게 반응해야 하는지 설계하는 것이 복잡하다는 점
예측 불가능한 사용자 입력과 다양한 브라우저 환경을 모두 고려해서 개발해야 한다는 점
화면의 성능과 사용자 경험을 고려해서 개발해야 한다는 점

코드를 짜면 짤수록 제 머리는 아파졌고, "프론트엔드도 생각보다 훨씬 더 복잡하구나", "프론트엔드도 기술적으로 깊이가 있구나" 라는 생각이 들면서, 제가 가지고 있던 프론트엔드에 대한 편견이 깨지게 되었습니다.

백엔드가 "대용량 데이터와 시스템 안정성, 정합성" 이라는 기술적 도전이 있다면, 프론트엔드는 "사용자 경험과 인터랙션, 다양한 환경에서의 호환성" 이라는 기술적 도전이 있다는 것을 깨닫게 되었습니다.

프론트엔드가 백엔드보다 쉬운 게 아니라, 두 분야가 해결해야 할 문제가 다르고, 각각의 분야가 기술적으로 깊이가 있다는 것을 알았습니다.

이제 저는 프론트엔드 개발자분들을 존경합니다.

그리고 백엔드 개발자로서 프론트엔드의 고충을 이해하게 된 지금, 협업할 때 더 나은 API를 설계하고 더 배려하는 소통을 할 수 있는 기반을 마련했다고 생각합니다.

이러한 깨달음이야말로 진짜 성장이라고 생각합니다.

13. AI 시대의 개발자로서

부스트캠프에서의 AI 활용 경험

부스트캠프 기간 저는 AI를 활용해서 코드를 작성하는 경험을 했습니다.

기존에는 브라우저에서 질문하고 수정하는 용도로만 사용했지만, 챌린지를 기점으로 IDE에서 AI를 활용한다거나, Copilot, Gemini CLI, Claude Code, Codex 같은 다양한 AI 도구들을 활용해서 코드를 작성하는 경험을 했습니다.

복잡한 정규식이나 보일러 플레이트 코드를 생성할 때는 감탄이 나올 정도로 편리했지만, 비즈니스 로직의 미세한 예외 상황이나 전체적인 아키텍처와 프로젝트의 맥락을 놓칠 때는 AI가 작성한 코드가 오히려 더 많은 버그와 문제를 일으키는 경험도 했습니다.

이 과정에서 저는 느꼈습니다. AI는 대신 해주는 게 아니라, 도와주는 도구라는 것을요.

제가 프롬프팅을 얕게 해서 방향을 잘못 잡으면, AI도 같이 엉뚱한 곳으로 달리고, 제가 어물쩡 지시하면 AI도 어물쩡한 코드를 작성하는 경험을 하면서, AI가 도구이긴 하지만, AI를 활용하는 능력 자체도 개발자의 역량이 되어야 한다는 생각이 들었습니다.

앞으로의 개발자가 AI를 활용하는 방법에 관한 생각

앞으로 개발자가 직접 키보드를 눌러 코드를 작성하는 시간은 필연적으로 줄어들 것이라고 감히 예상합니다.

하지만 역설적으로 그렇기에 개발자의 역할은 더욱 중요해지고, 더욱 어려워지고, 경계가 모호해질 것이라는 생각이 듭니다.

더더욱 중요해질 것들

"AI가 짠 코드를 믿을 수 있는가 ?" 라는 질문을 스스로 던져보았습니다.

이 질문에 답하기 위해 생각하다 보니, 저는 개발자의 중요한 역량이 다음과 같이 이동하고 있다는 것을 몸으로 느끼게 되었습니다.

수많은 코드 중에서 현재 상황에 가장 적합한 기술과 패턴이 무엇인지 선택하는 판단하는 능력 (판사)
AI가 쏟아낸 코드 속에서 구멍 난 로직, 놓친 예외 케이스, 테스트 코드, 보안 취약점을 빠르게 캐치하여 수정하고 보완하는 능력 (편집자)
AI에게 두루뭉술하게 지시하는 것이 아니라, 탄탄한 기획을 바탕으로 명확하게 지시하고, 결과를 검토하는 능력 (감독)

AI가 코드를 짜주는 시대에, 왜 우리는 여전히 CS와 아키텍처를 공부해야 할까요 ?

AI는 기능 구현에 필요한 로직과 코드를 작성하는 데는 뛰어나지만, 전체 시스템의 아키텍처를 설계하고, 보안 취약점을 찾아내고, 성능 최적화를 하는 부분에서는 아직은 인간 개발자의 역할이 중요하다고 생각합니다.

아직은 <<<

적합하고 좋은 디자인 패턴과 아키텍처를 모르면, AI가 짜준 스파게티 코드를 그대로 사용하게 됩니다. 보는 눈이 없다면, 좋은 코드를 가져올 수도 없는 것처럼요.

그래서 저는 AI 시대일수록 CS 지식, 디자인 패턴, 아키텍처 설계 능력, 프롬프팅, 기획 같은 "변하지 않는 가치" 가 생존 능력이 될 것으로 생각합니다.

마지막으로, 기술은 어제와 오늘이 다르게 정말 빨리 변화하고 있습니다.

특정 프레임워크나 언어 사용법을 암기하는 것은 어쩌면 이제 큰 의미가 없을 수도 있다고 생각합니다.

중요한 것은 새로운 기술이 나왔을 때, 기존의 지식을 바탕으로 AI를 활용해 얼마나 빠르게 습득하고, 내 것으로 체화해서 실무에 적용할 수 있느냐. 인 것 같습니다.

저는 부스트캠프라는 경험을 통해서 변화를 두려워하지 않는 태도를 갖게 되었고, 앞으로도 저는 AI라는 강력한 도구를 적극적으로 활용하며, 그 도구를 올바른 방향으로 조종하는 현명한 개발자가 되고 싶다는 생각이 들었습니다.

개인적인 의견이니, 너무 심각하게 받아들이지 말아주세요 ㅋㅋ

14. 동료 피드백을 통해 마주한 나

부스트캠프에서는 매주 동료 피드백 세션이 있었습니다.

각자가 자신의 성장과 발전을 위해서, 서로에게 솔직한 피드백을 주고 받는 시간이였습니다.

계속 잘해주세요 부분은 계속 잘하는 부분에 대한 피드백이였고, 더 노력해주세요 부분은 개선이 필요한 부분에 대한 피드백이였습니다.

그래서 제가 받은 모든 피드백들을 가감없이 공개적으로 공유하고, 그 피드백들을 통해서 제가 파악한 나의 상태와 깨달음에 대해서 솔직하게 작성해보려고 합니다.

더 노력해주세요

하신 말씀 중에 백엔드를 프론트에 비해 많이 알고 있어서 먼저 백엔드를 진행하셨다고 했다. 알고 있는 것을 기반으로 진행하는 것도 좋은 방법이겠지만 자신이 더 모르는 부분을 먼저 채우는 것도 좋지 않을까 생각했다. 이런 부분에서 자신이 익숙한 방식보다 새로운 방식을 해보려는 시도가 있었으면 좋겠어서 자기주도적으로 행동하기 항목을 선택했다.
저 자신에게도 해당되는 이야기이지만, 프로젝트를 진행하면서 자신이 알고있는 분야 백엔드 분야만 진행하려는 부분이 있었고 백엔드 구조도 익숙한 스프링 패턴을 사용하셨는데, 새로운 환경에서 어떤 것이 최선인지 더욱 고민해보고 학습의 관점에서 새롭게 접근하는 방식으로 진행해보셔도 괜찮을 것 같습니다.
피어세션에서 학습한 내용이나 구현 과정을 문서화해서 공유해주시면 좀 더 이해하는데 도움이 될 것같습니다.

다양한 접근을 고려하시는 점이 인상 깊었습니다. 다만 말로만 설명을 들었을 때는 이해가 어려웠습니다. 만약 선택지별 장단점을 간략히 글로 정리해 공유해 주신다면, 스크럼의 짧은 시간 안에서도 동료들이 더 잘이해할 수 있을 것 같습니다. 특히 직접 경험하지 못한 입장에서는 한 번 듣고 여러 선택지를 기억하기 어렵기 때문에, 문서화하면 트레이드오프를 함께 논의하는 데 도움이 될 것 같습니다. 또, 변경된 설계 아이디어를 코드에 적극적으로 적용해 보신 점은 매우 좋았지만, 코드의 일부에만 반영된 경우에는 의도를 파악하기어려운 순간이 있었습니다. 이럴 때도 과정을 주석으로 표시해 두면 동료에게 더 명확히 공유할 수 있고, 본인에게도 추후 참고 자료로 유용할 것이라 생각합니다
백엔드 API 구현에 집중하느라 프론트 작업이나 배포 요구사항까지는 손대지 못했다고 솔직히 말씀해주셨기에 “MUST와 Good to have를 구분해야겠다”라는 깨달음을 바탕으로 우선순위를 더 명확히 정하고, 한정된 시간 내에서 반드시 해내야 하는 목표를 먼저 달성할 수 있도록 실행에 옮겨보면 좋을 것 같다는 생각이 들었습니다!
피어세션에서 프론트엔드 지식이 아직 부족하다고 인식하고 계셨음에도, 실제 구현을 진행하는데까지는 이어지지 않은 점이 아쉬웠습니다. 알고 있는 부분이라면 의식적으로라도 시도해 보는과정이 필요하다고 생각합니다. 구현 경험이 부족하면 다른 캠퍼분들이 공유하는 고민이나 인사이트를 충분히 공감하지 못할 수도 있기 때문에, 다음에는 학습과 구현의 균형을 맞추신다면 더 성장이 있을 것이라 생각합니다.

너무 잘하고 계서서 뭐라 말하기 뭐하지만, 굳이 뽑자면 문서 정리만 더 잘되면 좋을 것 같습니다! 본인 만의스타일대로 하시는 것 같긴한데 학습정리가 한파일에 약 1500줄정도라 이걸 따로 파일 분리도 하고 하면더 이해하기 좋을 것 같습니다. 그러면 나중에 보기도 편할것 같아요~!
지난 프로젝트에서도 프론트엔드를 거의 하지 못했던 아쉬움을 표현해주셨고 이번 프로젝트에서는 조금 더깊은 고민을 해보고자 하셨던 것 같은데, 막상 서버 부분과 빌드 및 배포 과정에 신경 쓰시다 보니 실력적으로 부족하다고 생각하셨던 프론트엔드에 시간 투자가 상대적으로 적게 되었던게 아쉬웠던 것 같습니다.
이번 과제에서도 보여주신 것처럼 문제를 끝까지 붙잡고 해결하려는 태도와 깊이 파고드는 집중력은 준호님의 정말 큰 장점이라고 생각합니다. 다만 아쉬운 점을 굳이 찾자면 이번에 TypeScript 설정 문제를 해결하는 데만 5시간이 걸렸다고 하셨는데, 그 때문에 프론트엔드 진도가 상대적으로 늦어진 것 같습니다. 앞으로는 지금처럼 한 문제를 깊이 있게 파는 열정은 유지하면서도, 프론트엔드와 백엔드 두 영역을 조금 더 균형 있게 배분해 진행하신다면 훨씬 더 안정적이고 완성도 높은 결과물을 만드실 수 있을 것 같습니다！

다 잘 해주셨지만, 한가지 생각해보자면 코드를 AI에게 부탁? 하거나 할때 고민했던 흔적이나 고민 내용을 PR에 담아도 좋을 것 같다는 생각이듭니다!
오늘 피어 세션 중에 스스로 코드가 마음에 들지 않는 부분도 많다고 말씀하셨는데, 처음부터 잘 짜는 사람은 없다고 생각합니다. 마스터클래스에서 크롱님이 말씀하신 것처럼, 설계나 구조는 많이 해봐야 하고, 삽질처럼 느껴지는 과정도 결국 더 좋은 선택을 하게 만드는 경험이라고 생각합니다. 그래서 이런 고민과 시행착오는 성장 과정으로 받아들이고 나아가주시면, 훌륭한 개발자가 되어 계실 것 같습니다.
사실 아쉬운 점은 거의 없습니다. 팀활동도 열심히 하시고, 미션에도 진심으로 임하시는 모습이 보였습니다. 그래도 하나를 굳이 꼽아보자면, PR의 내용을 조금 정돈해서 올리시는 것도 좋을 것 같습니다! 고민한 부분이라던가 구현하신 걸 조금 더 구체화해서 문서화해 첨부하시면 이해하기 더욱 편할 것 같습니다. 정리하는 과정에서 혹시모를 실수나 리팩토링 할 부분을 찾을 수도 있지 않을까요?
스크럼때 열심히 참여 해주시고 진행이나 설명 또한 매끄럽게 잘 해주셔서 단점을 말씀드리기 애매할 것 같습니다.

프론트엔드에 익숙하지 않으시다고 하셔서 한번 프론트엔드도 파보시면 잘하실 수 있을것 같습니다.
아쉬운 점이 없는데도 억지로 생각해서 작성한다는 건 활동 취지에 맞지 않다고 생각해요 ㅎㅎ 새벽 늦게까지 구현하는 경우가 있다고 들었었는데, 롱런을 위해서 건강 관리 잘하시면서 진행하셨으면 좋겠습니다!
무리하시지 말고 지금처럼 학습과 구현 균형있게 진행하시면 좋겠습니다

항상 다양한 시도를 하시면서 많은 노력을 하고 계시는 것 같아, 더 말씀드릴 부분은 없는 것 같습니다 :) 피드백 시간에 나왔던 것처럼 학습 정리에 대한 문서 정리만 더 체계화해서 정리하시면 도움이 될 것 같습니다
학습정리를 할 때 너무 텍스트 위주로만 정리된 것 같아 나중에 다시 정리된 내용을 볼 때 피곤함을 느낄 수도 있을 것 같습니다. 물론 텍스트가 편하고 텍스트가 학습이 잘된다고 하시면 무시하시면 좋을 것 같은 조언이지만 설계나 학습 포인트를 직접 그려보거나 잘 정리된 이미지를 보면 이해가 더 잘되고 복습도 잘 될 수 있을 것 같습니다.

다른 것보다 건강, 체력관리를 더 의식하셔야 할 것 같습니다. 열정의 크기만큼 도리어 건강을 해칠까 걱정입니다. 특히 수면은 장기적으로 문제가 생기기 쉬우니 먼저 몸이 상하지 않도록 일정 시간 이상 확보하셔야 합니다
컨디션 관리나 일정 관리 측면에서도 조금 더 여유를 가지신다면 지금의 좋은 흐름을 더 안정적으로 이어갈수 있을 것 같습니다. CS 연결고리 공유 세션에서 준호님의 백엔드 관련 인사이트를 함께 나눌 수 없었던 점이 조금 아쉬웠습니다.
프론트엔드 코드에 아직 어려움을 느끼시는 부분이 보이지만, 직접 부딪혀보면서 경험을 쌓다 보면 빠르게 익숙해질 거라고 생각합니다. 준호님의 사고 깊이와 문제 해결 능력을 보면 충분히 잘 해내실 것이라고 생각합니다. 제 개인적인 생각인데, 프론트는 생각을 많이 하기보다는 그냥 몸소 부딪히며 경험해보는 게 베스트 라고 생각이 듭니다.
부족한 점은 정말 찾지 못했습니다! 백엔드와 프론트엔드 모두 균형 있게 속도를 맞춰가고 계신 것 같아요!! 저도 챌린지 때 밤샘을 자주 했던 사람으로서 한 가지 말씀드리자면(ㅠㅠ), 멤버십에서는 시간 리미트를 정해두고 효율적으로 집중하는 습관을 조금씩 길러보시면 어떤가요? 처음부터 12시까지 이런 건 아니더라도, “3시까지만 하자”처럼 자신만의 기준을 세우는 것도 도움이 될 것 같아요. 개인적으로 저도 잘 못지키고 밤샘을 여전히 하기는 하지만...ㅎㅎ 그래도 의식적으로 하려다 보면 효율적인 시간 관리를 하는 법을 조금씩 배울 수 있는 것 같습니다. 같이 화이팅해봅시다!

PR에서 기술 선택의 이유를 적으실 때 있다/된다/제공한다 정도의 단순 기능 나열 중심으로 정리되어 있어서 선택 배경이나 비교 기준, 왜 그게 본인에게 더 낫다도 판단한 건지에 대한 깊은 고민 과정이 잘 드러나지 않았던 점이 비교적 아쉬웠습니다.
그룹 활동 시간에 건강관리와 컨디션에 대해서 대화를 나누면서 준호님의 수면 시간이 많이 부족하다는 것을 알게되었습니다. 많이 배우려는 의지와 열정 넘치는 모습은 본 받을 점이라고 생각이 됩니다. 하지만 충분한 수면과 휴식 없이 달리는 준호님을 보면서 학습과 성장을 건강하게 지속할 수 있을지 걱정이 되었습니다. 개발자로서 성장해 나가는 과정은 스프린트가 아니고 마라톤과 같다고 생각합니다. 스케줄을 잘 조정해 보시고 수면 시간도 충분히 확보하셨으면 좋겠습니다. 준호님 오래 건강히 뵙고 싶습니다 ㅎㅎ

흠.. 너무 잘해주시고 있어서 뭐가 없지만, 의사 결정(?)이 필요할 때 준호님의 의견을 더 얘기해주면 좋을것 같습니다!
팀에서 어떤 주제에 대해 결정을 내려야할 때, 가끔은 뭐든 좋다고 하시는 경우가 있습니다. 팀을 배려하고 조율하려는 마음에서 비롯된 것이라 감사하게 느끼지만, 준호님의 생각이나 선호하는 방향을 듣고싶을 때도 있어 아쉬운 것 같습니다.
프로젝트에 정말 열심히 참여해주셨다고 생각합니다. 수면 부족이 걱정되긴 하지만, 그로 인해 팀에 지장을 준 적은 없으셨기에 따로 언급할 사항은 없습니다. 다만 건강이 걱정되는 건 사실입니다.

처음에는 늦게 주무시는 것에 걱정이 되었습니다. 안 피곤하시나?, 안 힘드시려나? 하지만 한 번도 회의에 지각하신적이 없으시고, 5주동안 함께 하면서, 이미 늦게 주무시는게 생활패턴으로 굳어지셔서 문제가 없다는 것을 알게되었습니다! 걱정되는 부분이 이거 한 부분이였어서 문제가 없을 것 같습니다!! 앞으로의 부스트캠프 활동도 화이팅입니다!
팀 회고 시간에 프론트 부분이 많이 어렵고, 스스로도 기피하는 것 같다는 말씀을 하셨는데, 스스로에게 회고하신 것처럼 부족한 분야를 더 깊이 파보시는 것도 좋은 경험이 될 것 같습니다!
너무 잘해주셔서 "노력해주세요"라고 말할 부분이 없네요...ㅜㅜ 노력해달라면 개인 건강챙기기 정도입니다.. ㅎ

첫 주 팀 빌딩에서 준호님은 스스로를 소개하시며 "생각에 정리가 필요해 바로 의견을 말하기 어려울 때가 있다"고 말씀하셨습니다. 하나의 주제에 대해서 꼬리를 물며 다양한 시각에서 고려하시기 때문에, 줌 회의처 럼 대화를 주고 받는 환경에서 발언 기회를 놓친다는 인식을 공유해주셨어요. 2주가 지난 지금 돌아보니, 준호님은 충분히 의견을 잘 표현해주고 계시다고 생각합니다. 특히 기술적인 고민에서 빛을 발하시는데, 2주차 데모에서 web12팀에 아이디어를 주신 점이 기억에 남습니다. 제스처 인식이 필요할 때만 관련 모델을 잠시 활성화 방식으로 최적화 할 수 있겠다는 말씀이었습니다. 팀이 고려해보지 못한 기술적인 관점을 앞으로도 자신있게 공유해주시면 좋겠습니다. 우리 팀에서는 AI 비밀번호에 대해 보안적으로 얼마나 의미가 있는지 의견을 나누었을 때가 기억에 남습니다. 익숙하지 않은 주제에 대해서는 편히 꼬리 질문 주셔도 좋겠어요. 준호님 덕에 팀 커뮤니케이션이 풍부해진다고 생각합니다!
이전에 잘 모르는 분야에서는 생각을 오래해야하고 그런 순발력이 좋지 않다는 것을 미리 공유받아 준호님께서 말씀이 적은 것을 이해할 수 있었던 것 같아요. 그래도 말수가 적으시다 보니 준호님의 생각을 깊게 공유받지 못하고 있다는 생각을 종종 했던 것 같습니다. 준호님께서 자신있는 개발이 점점 다가오고 있으니 개발에 관련된 이야기나, 기획, 테스트, 다른 자료들 등등 모두 좋으니 많이많이 공유해주시고 귀찮게 해주셨으면 좋겠습니다!
프로젝트를 진행하면서 준호님께서 컨디션이 좋지 않은 상황에서도 계속 작업을 이어가시는 모습을 자주보았습니다. 그만큼 책임감을 가지고 임해주시는 점은 팀에도 큰 도움이 되었다고 느꼈습니다. 다만 건강도 조금 더 챙기면서 진행하셔도 좋을 것 같다는 생각이 들었습니다. 식사나 휴식도 함께 잘 챙기셔서 더 좋은 컨디션으로 함께할 수 있으면 더 좋을 것 같습니다!

프로젝트를 진행하면서 새벽까지 작업하시는 경우를 여러 번 보았는데, 단기적으로는 큰 기여가 되지만 지속 가능한 개발을 위해서는 건강과 컨디션 관리도 함께 챙기시면 더 좋을 것 같다고 느꼈습니다. 또한 PR을 비교적 큰 단위로 올려주셔서 한 번에 코드 리뷰를 진행하기에 조금 부담이 되었던 경우도 있었습니다. 이미 PR을 작은 단위로 나누려는 노력을 하고 계신 것으로 보이긴 했는데, 이를 조금 더 작은 단위로 나누어 자주 올려주신다면 리뷰 과정이 더 수월해지고, 피드백도 더 빠르게 주고받을 수 있을 것이라고 생각했습니다.
앞으로는 건강관리를 잘 하시면서 개발하셨으면 좋겠습니다! 밤에 충분한 수면과 두끼 정도는 제 시간에 잘 챙겨먹고 하루에 한 번은 밖에 나가 산책을 하는 준호님이 되시길 바랍니다
이번 부스트캠프 활동을 통해 스스로에 대해 더 잘 알게 되었다고 하셔서 기쁩니다. 앞으로 좋아하는 것을 더 즐기며 나아가시길 바랍니다! 식지 않는 열정으로 성취할 것이라고 믿어요. 준호님은 재미와 자극을 추구하는 스스로의 성향을 잘 이용하시는 것 같습니다. 그래서 좋아하는 것의 범위를 늘려보셔도 좋겠습니다. 최종 발표에서 다른 팀에 적극적으로 질문하시는 모습이 인상적이었습니다. 평소 준호님이 관심 갖는 부분에 대한 질문들이었는데요, 관심 주제가 넓어질 수록 더 많은 사람과 풍성한 대화가 가능하다고 생각합니다. 재미있는 것에 열정을 다하는 성향을 이용해 흥미를 확장하며 더 빠르게 성장하실 거라고 믿습니다!

계속 잘해주세요

피어세션때 항상 자신의 고민을 동료들에게 공유하려고 노력하고, 동료들의 고민도 같이 생각해줬습니다. 이와 같은 행동 덕분에 그룹 전체에게 학습태도나 의지같은 부분에서 좋은 영향을 준 것 같습니다.
데일리 스크럼이나 그룹쉐어 등 피어세션을 진행했을 때, 능동적인 태도로 참여해주셔서 팀원들도 좀 더 적극적으로 의견을 낼 수 있었습니다. 다양한 분야에 관심을 갖고 공유해주셔서 시야를 확장할 수 있었습니다.
칭찬보다는 자신을 돌이켜 보게 하는 어쩌면 날 선 말들을 원하시고 더 즐기시는 모습을 볼 수 있었다. 이 모습은 결국 자신의 성장에 대한 끝 없는 욕심과 의지가 있기에 가능하다고 판단했다. 그렇기에 나를 알고 성장하기 항목을 선택했다.

피어세션과 학습 과정에서 다른 캠퍼분들의 PR을 스스로 찾아보며 인사이트를 얻으려는 자기주도적인 태도를 보였고, 동료들이 질문이나 의문을 제기할 때에도 적극적으로 본인의 지식을 공유하셨습니다. 다양한 고민에 공감하며 해결책을 함께 고민하는 적극적인 태도로 동료들에게 도움이 되었다고 생각합니다.
팀 스크럼 시간에 나눈 이야기를 적극적으로 기록해 주신 모습이 인상적이었습니다. 스크럼이 끝나자마자 논의된 주제를 곧바로 정리해 적어 내려가시는 모습에서, 팀원들의 이야기에 경청하신다는 점이 잘 드러났습니다. 평소 다른 동료들의 PR을 꾸준히 읽고, 인상 깊었던 분을 추천해 주신 것도 도움이 되었습니다. 부스트캠프에서는 매일 많은 자료가 쏟아지지만, 가까운 동료의 시선에서 무엇이 의미 있었는지를 직접 들을때 더 큰 자극을 받을 수 있었습니다. 덕분에 스크럼이 단순한 진행 상황 공유를 넘어, 서로의 성장을 풍성하게 나누는 자리로 확장될 수 있었습니다.
준호님은 매 PR 에 진심을 다해서 열정적으로 작성하고 좋은 코드에 진심을 다하시는 태도를 보여주어서 팀에 동기부여와 자극이 많이 되었습니다. 이번주에는 정합성·트랜잭션·SQL 인젝션 위험성·N+1 문제 등 실제 서비스에서 중요한 이슈들을 직접 마주하셨는데 그 과정에서 단순히 동작하는 코드에서 멈추지 않고 서비스 계층의 중복 코드 분리, 유저·라벨 중복 조회 최적화 같은 개선까지 항상 더 나은 코드를 위해 노력하시는 부분이 인상 깊습니다. 단순 구현에 그치지 않고 “왜 이 방식이 좋은지, 어떤 한계가 있는지” 를 꾸준히 고민하십니다. 예를 들어, 이슈 상세/목록 조회 쿼리 설계는 어떻게 할지, 트랜잭션 처리를 어디에서 해야할지, 중복 데이터 조회 최적화는 어떻게 할지 등 실제 개발하면서 마주칠 수 있는 여러가지 고민지점에 대해 정리를 해주시고 이러한 고민들을 피어 피드백 시간에서도 적극적으로 나누어주시면서 "이런 부분은 이런 방식으로도 접근할 수 있구나" 하고 새로운 인사이트와 도움을 많이 받았습니다. 그리고 AI 코드리뷰를 활용해 본인의 부족한 점과 개선 방향을 확인하려는 태도를 보여주셨습니다. 이런 고민과정과 태도 덕분에 준호님이 작성하신 코드는 단순히 기능적으로 돌아가는 것 뿐만 아니라, 점차 더 나은 구조와 안전성을 향해 나아가고 있다는 신뢰를 받았습니다. 클린코드 발표에서 "진심을 다해 작성한 코드가 클린코드" 다 하고 말씀주셨던 부분과도 맞닿아있는 것 같습니다. 또, 본인이 학습한 내용을 공유하고 WHY를 놓치지 않으려는 태도는 팀 전체가 더 깊이 고민하게 만드는 긍정적인 자극이 되었습니다.

이번 과제에서 저는 단순히 000을 구현하는 것이라고 생각했는데, 000를 직접 구현해보고 싶다고 하시면서 그 목표를 이루기 위해 000를 거의 해체하다시피 분석하며 깊게 파고드는 모습이 인상깊었습니다. 또 CI/CD와 빌드 과정까지 학습한 뒤 이를 문서로 정리하고 슬랙에 공유해주셔서 도움이 많이 되었습니다. 덕분에 본인의 학습은 물론이고 팀 전체가 함께 성장할 수 있는 기회가 된 것 같습니다. 이러한 태도는 단순히 주어진 과제를 수행하는 수준을 넘어, 더 나은 코드를 만들고 기술을 깊이 이해하려는 노력이라고 생각합니다!
문제 해결 하실 때, 실제 000를 생각하고 구현하신 부분이 인상적이었습니다. 그 과정에서 정말 많은인사이트를 얻었을 것 같고 000 구조에 대해 더 잘 알게 되었을 것 같습니다. 저도 시간이 남는다면 시도해보고 싶은 부분입니다!
000를 구현하며 단순히 작동하는 000를 구축하는 것이 아닌, 000를 모방한 000를 구축하려고 깊게 학습하고 구현하신 것이 인상적이었던 것 같습니다. 또한 동료들의 작업물을 적극적으로 살펴보고, 도움을 주기 위한 피드백과 질문도 열심히 해주셔서 감사했던 것 같습니다.

모르는 지점이나 연락해야할 상황 혹은 누군가는 먼저 나서야하는 상황에서 항상 자진하여 행동을 해주시며 감사를 표해주셔서 감사했습니다. 이로 인해 지금 제 상황에서 무엇을 할 수 있는가에 대하여 생각해볼수 있었고 피드백을 얻게 된 것 같습니다
먼저 덕분에 한 주 동안 좋은 팀 분위기 속에서 팀활동을 할 수 있었던 것 같아 감사의 말씀을 드립니다! 팀원 개개인의 발표나 이야기를 귀담아 들어주시고 질문도 많이 해주셔서 좋았어요. 특히 이야기가 주제 밖으로 샐 때 중심을 잘 잡아주시고, 팀원이 이야기를 하다가 결론을 정리하지 못했을 때 요약해서 결론과 의견을 다시 한 번 여쭤봐주셔서 배려가 넘치는 분이시라고 생각했습니다! 팀 활동에도 활발히 참여하시고, 미션도 소홀히 하지 않으시는 모습이 인상깊어씁니다. 항상 작은 고민거리도 적어서 기록하시고, 공유해주시려는 모습이 보였습니다. 고민을 많이 적어놓아서 민망하다고 하셨지만, 해당 고민들이 준호님의 성장에 큰 도움이 될 것이라고 생각합니다! 다른 분들 PR을 보는 걸 좋아하신다고 하셨는데, 저도 준호님의 PR을 앞으로 즐겨 찾겠습니다 하하
스스로 작성한 코드에 대해 이해하고 있고 왜 이런 방향으로 구현했고 어떻게 고민했는지를 설명해주셔서 스크럼 때 이해하기 좋았습니다.
준호님께서는 모든 피어분들의 코드 쉐어가 끝나면 한 분씩 꼭 질문과 함께 이야기해볼 만한 점을 꺼내 주시더라구요. 한 분 한 분 집중해서 듣고 계신 느낌이 들어 정말 좋았습니다. 문서화 과정도 네부캠에서 본 분들 중 손에 꼽을 정도로 잘 남겨주신 것 같습니다. 오늘 PR에서 그동안의 고민과 해결 과정을 모아두신 걸 봤는데, 미션 한 주를 정말 알차게 기록해오신 것 같아요. 나중에 돌아보시면 큰 성장의 밑거름이 될 것 같습니다. 이런 부분은 정말 잘하고 계신 것 같고 앞으로도 계속 화이팅입니다. 심심하면 준호님의 고민과 해결 과정을 구경하러 가겠습니다. 추가로 PR에 살짝 일기장처럼 숨어 있는 생각 같은 부분도 재밌게 읽혀서 좋았습니다.

피어 세션 때 항상 먼저 이야기 주제를 던져주시고 편하게 이끌어주셔서 부담 없이 진행할 수 있었습니다. 학습하신 내용도 꼼꼼히 작성해주셔서 많이 참고가 되었던 것 같습니다.
작업하시면서 생각하신 부분을 자연스럽게 PR 에 적으셔서 어떤 고민이 있으셨는지 어떻게 해결했는지 한눈에 확인할 수 있어서 좋았습니다.
배포 스크립트에서 초기화, 롤백, 상태 체크 등 다양한 예외 상황을 고려하신 점과, 피어 세션에서 주도적으로 논의를 이끌며 생각거리를 제공해주신 점이 인상 깊었습니다. 단순히 "동작하는 코드"가 아닌 "안정적인 코드"를 작성하는 것의 가치를 배울 수 있었고, 피어 세션에서도 새로운 관점에서 문제를 바라보는 방법을 배울 수 있었습니다!

피어세션때마다 나눴던 얘기들을 슬랙에 잘 정리해주시고 본인이 가지고 있던 인사이트들을 잘 공유 해주셔서 도움이 정말 많이 되었습니다. 몰랐던 내용을 잘 설명해주시거나 다른 팀원분이 설명해주신 내용을 본인의 지식과 합쳐서 설명해주신 부분이 정말 좋았습니다.
학습과 구현을 하면서 고민 과정과 해결과정을 꼼꼼하게 기록하시는 모습이 인상깊었습니다!! 또 스터디 일지도 토론했던 내용도 잘 정리해주셔서, 피어 피드백 시간들을 다시 되돌아보는데 많은 도움을 받았던 것 같습니다.

고민과 생각을 깊이 하시고 그걸 바탕으로 스스로의 성장 방향을 탐색하시는 모습이 인상 깊었습니다. 스스로를 객관적으로 바라보며 성장 포인트를 찾고자 하는 자세가 앞으로의 성장에도 도움이 될 것 같다고 생각합니다!
가장 열정적으로 임하는 팀원이고, 새로운 기술에 접근하는데 능숙하다는 느낌을 받았습니다. 이미 판단 기준이 있어 주저나 망설임이 없는 것 같습니다. 기술적인 내용에 대해서도 깊이가 있어 항상 고민하고 있다는 말씀에 진실성이 있었습니다. 앞으로 더 무섭게 성장하실 것 같습니다.
준호님은 고민하고 학습한 내용을 요약 정리해서 전달하는 능력이 정말 뛰어나신 것 같아요. 생각이 많고 깊으시다고 하셨는데, 그런 보이지 않는 생각들을 PR로 정리하는 데 10분 정도밖에 걸리지 않는다는 게 정말 놀라웠습니다. 사실 그 말은 생각이 이미 머릿속에서 잘 정리되어 있다는 뜻이기도 하다고 생각합니다. 다른 분의 말씀을 듣고 한두 줄로 요약해서 핵심을 잡는 능력도 정말 인상 깊었어요! 이미 준호님이 하고계신 스스로에게 끊임없이 질문하고 답을 찾아가는 모습이 앞으로도 큰 도움이 될 것 같습니다!
PR에 자신의 생각과 의도를 잘 담아주셔서 코드 작성의 방향과 이유를 명확히 이해할 수 있었고, 코드 외적으로도 준호님의 통찰을 배울 수 있어서 좋았습니다. 또한 Slack이나 줌 회의에서 본인이 얻은 경험을 적극적으로 공유하고, 회의 내용을 정리해 동료들이 더 쉽게 이해할 수 있도록 도와주신 부분이 인상 깊었습니다. 앞으로도 이런 좋은 영향력을 계속 보여주시면 좋겠습니다!

금요일을 포함하여 매일 진행하는 그룹 활동 시간에 준호님은 동료 캠퍼가 발표하는 내용을 집중하여 듣고, 적극적으로 질문하며 관심을 보여주신 모습이 인상 깊었습니다. 이로 인해 미처 생각하지 못했던 부분들을 깨닫게 되었습니다. 그리고 앞으로 어떤 방향으로 공부를 하면 좋을지 정하는데 도움이 되었습니다.
스터디 그룹 활동에서 적극적으로 의견을 공유해주셨던 것 같습니다. 본인이 생각한 의견을 적극적으로 말해주셔서 다양한 관점을 배워갈 수 있었습니다.

000 일부에 000를 도입하는 과정에서 다중 사용자 지원이 어려울 것이라 예상했는데, 실제로 구현해내신 모습이 인상 깊었습니다. 프로젝트 초반 서로 알아가는 시간에 이전 동료로부터 "잠을 좀 자야 할 것 같다"는 피드백을 받았다는 이야기를 들었을 때는 그냥 넘겼는데, 함께 작업하면서 정말 언제 주무시는지 궁금할 정도로 열심히 하셨습니다. 특히 매 회의마다 AI를 활용해 회의 내용을 정리하고 공유해주신 점이 팀 전체의 업무 효율을 높이는 데 큰도움이 되었습니다. 이러한 노력 덕분에 팀원들이 회의 내용을 빠르게 확인하고 후속 작업을 진행할 수 있었고, 프로젝트가 더 원활하게 진행될 수 있었습니다.
책임감을 가지고 맡은 일을 끝까지 해내려는 모습이 인상적이었습니다. 본인의 업무가 아니더라도 팀 전체에 필요한 일을 최대한 하시려고 해주셔서 팀에 큰 도움이 되었습니다. 또한 PR 리뷰에서 받은 피드백을 단순히 반영하는 수준을 넘어, 생소한 분야라도 스스로 학습하고 이해한뒤 코드에 반영하려는 노력이 코드에서 드러났습니다
어려운 문제를 만났을 때나 무슨 일이 있을 때 항상 솔선수범으로 해결해나가려는 모습이 인상적이었습니다. 또한 밤 늦게까지 열정을 불태우면서 문제를 해결해나가는 모습이 대단하신 것 같습니다. 그 문제에 대해서도 잘 설명해주시고 PR에도 잘 나타나서 이해가 잘 되었습니다!!

항상 먼저 솔선수범하여 회의록을 기록해주시고 사소한 문제가 생기면 바로 공유를 해주고 생기는 이유 등도 잘 정리해주셔서 이해가 많이 되었습니다!!
준호님은 코딩에 진심이신 것 같아요. 새벽까지 잠을 마다하고 꾸준히 작업하시는 모습을 보고 결과와 상관없이 큰 동기부여가 됐습니다. 또한 본인이 작성한 코드에 대해 항상 자세히 알려주시려 하고, 팀원들에게 필요한 정보나 진행 상황을 빠짐없이 정리해 전달해주는 역할도 자연스럽게 맡아주셨습니다. 덕분에 팀 전체가 더 효율적으로 협업할 수 있었습니다.
어젯밤 준호님께서 밤을 새워 백엔드 코드 동작을 다듬고 저희에게 상세히 설명해주셨을 때, 덕분에 팀 전체가 live share로 모여 긴 시간을 소비하지 않고 효율적으로 진행할 수 있었습니다. 준호님의 주도적인 작업과 명확한 설명 덕분에 저희가 다른 일들을 할 수 있었어요. 또한 PR 작성 시 리뷰 요구사항을 구체적으로 남겨주신 덕분에 어떤 관점에서 코드를 검토해야 할지 명확히 파악할 수 있어서 리뷰 과정이 훨씬 수월했습니다.

익숙하지 않은 도전에도 선뜻 참여하고 최선을 다하는 모습이 기억에 남습니다. 사용자 테스트 결과에 다음 문장을 남기셨습니다. "인터뷰 이렇게 프리토크식으로 이거저거 다 받아적었는데 잘 모르겠다. 그래도 나름 유용한 것 같다. 이 또한 러바두겠죠. 저는 단순 코더가 적성인가봐요." 이 부분에서 성장 의지가 느껴졌습니다. 팀 활동을 하며 새로운 경험을 하고, 그 결과에 대해서도 솔직히 공유하며 나아가는 모습에서 함께 성장한다는 감각을 받았습니다. "피드백은 늘 환영입니다"라고 자주 말씀하시는 점에서도 성장 의지가 느껴집니다. 준호님으로부터 도전에 열린 자세를 배우고 싶어요.
항상 열린 마음으로 팀원들의 의견을 경청해주시고 준호님의 의견을 논리적으로 정리해서 말씀해주셔서 많은 도움이 되는 것 같습니다. 맡으신 task도 책임감 있게 열정적으로 빠르고 효율적으로 처리해주셔서 팀이 속도감 있게 프로젝트를 진행하는 데 많은 도움이 되었다고 느꼈습니다. 또한, 맡으신 부분을 빈틈없이 깔끔하게 마무리해주신 덕분에 팀이 해당 부분을 신뢰하고 다른 작업에 집중할 수 있었다고 생각합니다. 그리고 슬랙에서도 적극적으로 소통을 이어가 주셔서, 필요한 논의나 공유가 지체되지 않고 원활하게 이루어지는데 많은 도움이 되었습니다.
맡은 일에 최선을 다하고, 의견을 잘 들어주시는 점이 준호님의 강점이라고 생각합니다. 맡은 일에 최선을 다하는 건 당연하다고 생각할 수도 있지만, 그 이상을 하려고 노력하시고 실제로도 그 이상을 해오셔서 놀랐습니다. 아이디어를 생각해오기로 했을 때 늦게까지 고민하시면서 다양한 아이디어를 가져오셨고, 그 중 하나가 채택되었습니다. 프로토타입을 개발할 때도 굴러만 가는 코드를 짜도 상관이 없다고 했는데, 꽤 질이 좋고 확장을 생각한 코드를 뚝딱 짜오신 것도 생각납니다(물론 뚝딱 코드가 나온 게 아니라 다양한 고민을 하셨을 걸 압니다!) 그만큼 맡은 일에 최선 이상을 하시려고 노력하시는 점이 인상깊었습니다. 또 다른 팀원들의 의견을 먼저 충분히 듣고 그 의견에 힘을 실어주시거나, 개선할 점을 짚어주시는 것도 좋았습니다. 의견이 중구난방으로 흩어질 때 쯤 정리가 될 길을 열어주시는 느낌이어서 도움이 많이 되었습니다.

프로젝트를 진행하면서 맡으신 작업을 책임감을 가지고 끝까지 해결하시고 해내시려는 모습이 인상 깊었습니다. 슬랙에서도 팀원들의 질문이 올라올 때마다 빠르게 답변해 주시고, 의견도 적극적으로 공유해 주셔서 팀이 속도감 있게 작업을 진행하는 데 많은 도움이 되었다고 생각합니다. 또한 팀 내에서 기술적인 의사결정이 필요한 상황에서 본인의 의견을 논리적인 근거와 함께 제시해 주셔서, 팀원들이 방향을 잡고 결정을 내리는 데 큰 도움이 되었습니다. 그리고 맡은 작업을 빠르고 깔끔하게 처리해 주셔서 팀원들이 각자의 작업에 더 집중할 수 있었고, 회의 시간에도 팀원들의 의견을 충분히 경청한 이후에 본인의 생각을 정리해서 말씀해 주셔서 팀 회의가 전반적으로 매끄럽게 이어질 수 있었습니다.
협업 경험이 부스트캠프 참여 동기라고 말씀하신 것이 기억에 남습니다. 그룹 프로젝트 전반에서 준호님이 협업을 위해 노력하시는 모습이 보였습니다. PR 메시지를 자세히 적어 주시고 늘 빠른 답변을 주셨어요. 최종 발표 준비를 하며 서비스 사용자를 위한 문서를 상세히 작성하신 부분에서도 협업과 소통에 대한 열정이 느껴졌습니다. 늘 책임감 있게 프로젝트에 참여해주셔서 감사합니다. 준호님을 보며 함께 일하고 싶은 동료가 되기 위해 저도 노력하게 되었어요. 앞으로의 여정 응원합니다!
준호님께서는 어떤 일을 맡으시던지 최선을 다해서 좋은 결과물을 내려고 노력하신 게 보였습니다. 큰 피쳐를 맡으신 날엔 밤을 새서라도 결과물을 가져오시고, 작은 피쳐를 맡으시더라도 코드의 품질을 신경쓰며 세심한 코드를 짜려고 노력하시던 모습이 인상깊었습니다. 덕분에 준호님께서 맡으신 작업은 걱정이 없었고, 준호님 작업물에서 많이 배운 것 같아요. 그리고 저희 넷 중에 가장 말씀이 적으셨던 것 같은데, 이게 과묵하다거나 의견을 내지 않는 것이 아닌 다른 캠퍼들의 말을 경청하고 곱씹어 생각하며 소화하려고 하신다는 게 느껴졌습니다. 이렇게 경청해주는 동료가 있기 때문에 다른 동료들도 가감없이 의견을 이야기하고 그러면서 더 좋은 토론의 장이 되는 것 같아요. 정말 감사했습니다.

피드백을 통해 파악한 나의 상태

동료들의 피드백을 하나하나 곱씹어보며, 저는 제가 미처 알지 못했던, 혹은 애써 외면했던 저의 모습을 알게 되었습니다.

저는 "미완성"을 두려워했습니다.
프론트엔드 작업 비중이 낮았던 이유는 흥미가 없어서도 맞지만, 다른 이유도 있었습니다. 백엔드만큼 능숙하지 못한 제 모습을 보여주는 것이 두려웠고, 그래서 제가 잘하는 백엔드 코드를 더 완벽하게 만드는 데 도피하고 있었습니다. "익숙한 방식보다 새로운 방식을 시도해 보라"는 피드백이 제 방어 기제를 꿰뚫은 말이었습니다.
저는 "효율"보다 "몰입"에 중독되어 있었습니다.
새벽까지 코딩을 했던 건 개발 효율 때문이라기보다, 어려운 문제를 해결했을 때 오는 도파민과 "나 오늘 열심히 살았다"는 자기 만족감이 컸기 때문입니다. 무엇보다 몰입이 정말 즐거웠습니다. 하지만 동료들은 냉정하게 보았습니다. 수면 부족이 장기적으로는 팀의 리스크가 될 수 있다는 것을요.
제 친절함이 때로는 "모호함"이 되었습니다.
팀을 배려해서 "뭐든 좋아요"라고 했던 말들이, 오히려 리더십이 필요한 순간에 팀원들을 헷갈리게 만들었다는 것을 알게 되었습니다. 진정한 배려는 무조건적인 수용이 아니라, 명확한 내 의견을 제시하고 조율하는 것이라는 걸 알았습니다.

나에 대한 깨달음

이 피드백을 통해 저는 저라는 개발자를 어떻게 정의할 수 있을지, 그리고 앞으로 어떤 개발자가 되고 싶은지에 대한 생각을 정리할 수 있었습니다.

내가 잘하는 것:
하나의 문제를 끝까지 파고들어 기어이 원리를 밝혀내는 집요함. 그리고 그 원리를 바탕으로 더 나은 구조와 코드를 만들어내는 개선 의지.
내가 못 하는 것:
머릿속의 복잡한 추상화를 단순한 그림으로 시각화하여 남을 설득하는 능력. 그리고 적절한 시점에 끊고 쉬는 절제력.
내가 좋아하는 것:
"동작하는 코드"를 넘어 "안전하고 논리적인 구조"를 설계하는 것.
내가 싫어하는 것:
"그냥 돌아가기만 하면 되는 코드"를 짜는 것.

앞으로 저는 마라토너가 되려 합니다.

스프린트 구간에서는 전력 질주하되, 쉴 때는 확실히 쉬며 롱런할 수 있는 리듬을 찾겠습니다.

제 머릿속에 있는 수많은 고민과 로직이 동료들에게 닿지 않으면 혼잣말이라는 것을 배웠습니다. 제 생각을 그림으로, 글로 명확히 내보내는 연습을 꾸준히 하겠습니다.

저에게 쓴소리와 응원을 아끼지 않았던 10기 동료 여러분들 덕분에 저는 혼자일 때보다 훨씬 더 많이 성장했습니다.

15. 마치며 - Learning by Doing

내가 정의한 "러닝 바이 두잉"

머릿속에 지식을 쌓아두면 언젠가 쓸 수 있을 거라 믿었습니다.

제가 땀과 눈물로 정의한 Learning by Doing은 "머릿속의 지식이 손끝을 타고 나와, 현실의 문제와 부딪히며 깨지고 다듬어지는 과정" 입니다.

Doing은 모르는 문제에 맨몸으로 부딪히는 용기, 수없이 많은 에러 로그를 마주하는 인내, 그리고 해결해내는 집요함이라고 생각합니다.

Learning은 내가 짠 코드의 이유를 설명할 수 있고, 동료를 설득할 수 있으며, 어제보다 더 나은 구조를 고민하는 치열함이 배움이라고 생각합니다.

부딪히며 배운 지식만이 진짜 내 것이 된다는 사실을 이제는 확실히 알 것 같습니다.

감사 인사

동료분들에게:
방구석에 갇혀있던 저를 세상 밖으로 꺼내주셔서 감사합니다. 밤새워 함께 코드를 고민하고, 때로는 따끔한 피드백으로 저를 일깨워주셔서 감사합니다. 우리 모두 각자의 위치에서 더 멋진 개발자로 다시 만나길 진심으로 응원합니다.
마스터, 리뷰어, 시니어분들에게:
성장에만 집중할 수 있도록, 기술적인 부분뿐만 아니라 멘탈적으로도 든든한 지원군이 되어주셔서 감사합니다. 피드백과 격려 덕분에 저희는 더 높은 곳을 향해 나아갈 수 있었습니다. 또한 기술적으로 피드백과 조언을 아끼지 않으셔서, 저희가 더 나은 개발자로 성장하는 데 도움이 많이 되었습니다.
무대를 만들어준 운영진분들에게:
보이지 않는 곳에서 밤낮없이 애써주신 운영진분들의 노고에 감사드립니다. 덕분에 실패를 두려워하지 않고 마음껏 넘어지며 배울 수 있었습니다.

여러분들 모두 어딘가에서 다시 만나요~~~

읽어주셔서 감사합니다.

[JAVA-자바] 3015번: 오아시스 재결합

raven — Wed, 8 Oct 2025 03:54:18 +0900

소스코드:

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.util.Stack;

public class Main {

  public static void main(String[] args) throws IOException {
    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

    long result = 0;
    int N = Integer.parseInt(br.readLine());
    int[] arr = new int[N];
    for (int i = 0; i < N; i++) {
      arr[i] = Integer.parseInt(br.readLine());
    }

    // key - sameCount
    Stack<int[]> stack = new Stack<>();
    for (int i = 0; i < N; i++) {
      int height = arr[i];
      int sameCount = 1;

      // 스택 맨위가 나보다 작으면, 나는 다 볼 수 있음
      while (!stack.isEmpty() && stack.peek()[0] < height) {
        result += stack.pop()[1];
      }

      // 스택 맨위가 나랑 같으면(같은 키끼리 병합)
      if (!stack.isEmpty() && stack.peek()[0] == height) {
        sameCount = stack.peek()[1] + 1;
        result += stack.pop()[1];

        // 내가 제일 큰게 아니면, 나보다 큰애가 하나는 있음
        if (!stack.isEmpty()) {
          result++;
        }
      } else {
        // 스택 맨위가 나보다 크면, 나는 그 애를 볼 수 있음
        if (!stack.isEmpty()) {
          result++;
        }

      }
      stack.push(new int[]{height, sameCount});
    }

    bw.write(String.valueOf(result));
    bw.close();
    br.close();
  }
}

글의 내용 중 잘못된 점이나 수정이 필요한 부분, 혹은 궁금한 사항이 있다면 언제든 댓글로 남겨주시면 감사하겠습니다.

여러분의 피드백은 더 나은 글을 작성하는 데 큰 도움이 됩니다. 감사합니다.

[JAVA-자바] 2638번: 치즈

raven — Mon, 6 Oct 2025 13:53:16 +0900

소스코드:

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.util.LinkedList;
import java.util.Queue;
import java.util.StringTokenizer;

public class Main {

  public static void main(String[] args) throws IOException {
    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

    StringTokenizer st = new StringTokenizer(br.readLine());
    int height = Integer.parseInt(st.nextToken());
    int width = Integer.parseInt(st.nextToken());

    int[][] board = new int[height][width];
    int total = 0;
    for (int y = 0; y < height; y++) {
      st = new StringTokenizer(br.readLine());
      for (int x = 0; x < width; x++) {
        board[y][x] = Integer.parseInt(st.nextToken());
        if (board[y][x] == 1) {
          total++;
        }
      }
    }

    int time = 0;
    int[] dx = {0, 0, -1, 1};
    int[] dy = {-1, 1, 0, 0};

    while (total > 0) {
      boolean[][] visited = new boolean[height][width];
      int[][] cheese = new int[height][width];

      Queue<int[]> queue = new LinkedList<>();
      queue.add(new int[]{0, 0});

      while (!queue.isEmpty()) {
        int[] current = queue.poll();
        int x = current[0];
        int y = current[1];

        for (int i = 0; i < 4; i++) {
          int nextX = x + dx[i];
          int nextY = y + dy[i];

          if (nextX < 0 || nextX >= width || nextY < 0 || nextY >= height) {
            continue;
          }

          if (visited[nextY][nextX]) {
            continue;
          }

          if (board[nextY][nextX] == 0) {
            // air
            visited[nextY][nextX] = true;
            queue.add(new int[]{nextX, nextY});
          } else if (board[nextY][nextX] == 1) {
            // cheese
            cheese[nextY][nextX]++;
          }
        }
      }

      // del
      for (int y = 0; y < height; y++) {
        for (int x = 0; x < width; x++) {
          if (cheese[y][x] >= 2) {
            board[y][x] = 0;
            total--;
          }
        }
      }
      time++;
    }
    bw.write(String.valueOf(time));
    bw.close();
    br.close();
  }
}

글의 내용 중 잘못된 점이나 수정이 필요한 부분, 혹은 궁금한 사항이 있다면 언제든 댓글로 남겨주시면 감사하겠습니다.

여러분의 피드백은 더 나은 글을 작성하는 데 큰 도움이 됩니다. 감사합니다.

[정보처리기사] 2025-2회차 실기 합격 후기 + 나름의 팁(?)

raven — Tue, 16 Sep 2025 02:20:45 +0900

2트만에 겨우 합격 ㅠㅠ

2025년 정기 기사 2회 (2트)에 턱걸이로 합격하고, 느낀 생각과 경험을 작성해봤습니다.

지난 1회차에서는, 프로그래밍 문제가 좀 꼬여있었고, 합격률이 개편후 역대 2번쨰로 최저로 나왔습니다.

이론은 많이 틀렸지만 프로그래밍 부분에서 겨우 점수를 따내서 합격하게 되었습니다.

개인적으로 이번 회차는 너무 쉬웠다고 생각이 듭니다.

CS지식을 잘 모르는 제가 봐도, 이론이 확실히 기출문제에 비해 쉬워진 것을 느낄 수 있었습니다.

저는 1회차에 50점 초중반으로 불합격 했었는데, 그 당시에는 수제비출판사 2025 정보처리기사 실기 기본서로 약 2주동안 공부했고, 1회차에서 떨어진 후, 별다른 공부를 하지 않았습니다.

네부캠 챌린지10기 과정 도중에 하루정도만 기출을 풀고 시험을 치뤘는데, 운이 매우매우 좋았습니다.

사실 제목에는 팁이라고 적어놨지만, 다른 분들의 자료를 읽거나, 기출문제를 다루는 블로그나, 기출문제를 푸는 사이트를 이용하면서 공부한 부분이 개인적으로 컸다고 생각합니다.

물론 제가 전공자인 덕도 없지않아 있겠지만, 기본적으로는 출제 유형이 어느정도 정의되어있고, 날이 갈수록 이론이 쉬워지고 있다고 느낍니다.

따라서 이론공부를 하지 말라는것은 아니고, 기본적인 이론을 공부한 후, 기출문제를 통해서 출제 유형을 파악하는것이 중요하다고 생각합니다.

그리고 직접 프로그래밍을 해보지 않았다면, 헷갈리거나 어려운 부분들이 프로그래밍 문제에 출제되는 경우가 점점 늘어나는 것 같습니다.

따라서 제가 학습을 진행하면서, 도움을 받았던 블로그들이나, 사이트들을 첨부해놓겠습니다.

요악하자면,

기본적인 이론을 공부한다, 자주 나오는 문제는 꼭 암기한다.
개편 이후의 모든 기출문제를 풀어본다. (최소 3회~5회)
프로그래밍 문제를 직접 코딩해본다. (IDE에서 직접 타이핑해보고, 실행해본다.)
기출문제 풀이 사이트나, 블로그를 참고한다. (블로그나 카페 유튜브에 상당히 잘 되어있습니다)
프로그래밍 부분이 점점 꼬여서 나오는 경향이 있으니, 헷갈리는 개념은, 직접 코딩해보고, 학습하며 익숙해진다.
해당 회차의 기출문제의 난이도가 오락가락 하는 경향이 있으니, 좌절하지 말고 계속 시도한다.
기사자격증이 그렇게 큰 메리트가 있을까 ? 라는 생각이 든다면, 너무 자격증에 메이지 않아도 될 것 같다.
전부를 이해하고, 전부를 암기할 수는 없다. 합격은 60점이니 시간을 효율적으로 사용해 전략적으로 행동한다.

[네부캠 10기] 웹 풀스택 멤버십 4주차 주간 회고

raven — Tue, 16 Sep 2025 01:55:19 +0900

KPT 주간 회고

2025-09-08 ~ 2025-09-12 | 네이버 부스트캠프 멤버십 4주차 회고

Keep

내가 잘하고 있는 부분, 계속 유지할 부분

1) 계획한 방향대로 일관된 수행

백엔드 개발을 80% 이상 완료한 후 프론트엔드 작업을 진행하기로 한 계획을 지켰습니다.
체계적인 접근 방식을 유지하며 단계별로 진행했습니다.

2) 라이프 밸런스 유지 노력

이전 회고에서 언급한 내용들을 실천하고 있습니다.
집안일도 처리하고, 개인적인 휴식시간과 탐구시간을 의도적으로 확보하여 지속 가능한 학습 환경을 만들었습니다.

3) 팀 활동에서 적극적인 지식 공유

이전에 공부했던 주제가 나왔을 때, 최대한 전할 수 있는 것을 전하려고 시도하고 노력했습니다.
아는 부분에 대해서는 설명과 답변을 적극적으로 제공하여 팀에 기여했습니다.

4) 미션 진행 중 개선점 분석과 고민

DB JOIN과 서비스 단에서의 여러 쿼리 조합 방식의 장단점을 분석하고 개선 방법을 검색하며 학습했습니다.
단순 구현을 넘어서 어떻게 개선할지, 어떤 효과가 있을지 분석하고 고민했습니다.

Problem

개선할 부분, 목표 달성을 방해한 요인

1) 프론트엔드 코드 미구현

작업 속도가 생각보다 느려서 프론트엔드를 학습하고 구현하고 싶었으나 전혀 진행하지 못했습니다.
풀스택 과정의 목표에 미치지 못한 상황입니다.

2) 건강 관리 역효과

냉방병과 감기 상태에서 무리하게 운동을 했더니 피로감이 심해졌습니다.
그 결과 수면 시간이 늘어나 작업 시간이 매우 부족해졌습니다.

3) 우선순위 분배 실패

유효성 검사, 권한 체크, 에러 체크 등 보안적 요소들에 과도하게 시간을 투자했습니다.
회원가입이나 API 로직의 외적인 부분에 집중하다 보니 정작 핵심 기능을 구현하지 못했습니다.

4) 학습과 구현의 밸런스 실패

백엔드 부분만 작업했지만, 기존에 알던 지식을 꺼내서 사용했을 뿐입니다.
이렇다 할 CS 학습과 프론트엔드 학습이 전혀 없어 성장이 제한적이었습니다.

5) 회고의 형식적 진행

데일리 회고에 영양가가 없었고 의무적으로 진행해서 부담스러웠습니다.
또한 주간회고를 놓치는 등 회고 자체의 효용성이 떨어졌습니다.

Try

새롭게 도전할 부분, Problem 해결 방향, 다음 주 목표

1) 프론트엔드/백엔드 밸런스 우선 확보

학습과 구현의 밸런스보다는 프론트엔드와 백엔드의 밸런스를 먼저 챙기겠습니다.
풀스택 과정의 취지에 맞게 양쪽 영역에 균형있게 분배하고 행동하겠습니다.

2) MoSCoW 방법론 적용

MoSCoW(Must have, Should have, Could have, Won't have)를 명확하게 판단하고 도출하겠습니다.
핵심 부분에 먼저 시간을 투자하고, 남는 시간을 부가적인 기능에 투자하는 우선순위를 설정하겠습니다.

3) 컨디션 기반 운동 재개

몸이 어느 정도 괜찮아졌으므로 운동을 꾸준히 더 해보겠습니다.
다만 이번에는 현재 컨디션을 정확히 파악하고 무리하지 않는 선에서 진행하겠습니다.

4) 회고 방식 개선

데일리 회고는 중복되는 부분이 많고 의무감이 느껴져서 주간 회고 중심으로 전환하겠습니다.
보다 실질적이고 의미 있는 회고가 되도록 질적 개선에 집중하겠습니다.

[네부캠 10기] 웹 풀스택 멤버십 3주차 주간 회고

raven — Tue, 16 Sep 2025 01:06:44 +0900

KPT 주간 회고

2025-09-01 ~ 2025-09-05 | 네이버 부스트캠프 멤버십 3주차 회고

Keep

내가 잘하고 있는 부분, 계속 유지할 부분

1) 체계적이고 유연한 계획 수립

방향성은 명확하되 조정 가능한 계획서를 작성하여 프로젝트를 진행했습니다.
데이터 모델 설계 -> API 설계 -> 구현 순서로 체계적인 접근을 유지했고, 계획을 따르며 안정적으로 관리했습니다.

2) 선행 학습과 주도적 AI 활용

프로젝트 규모를 고려해 필요 지식과 키워드를 선별하고, 핵심 개념을 먼저 이해한 뒤 진행했습니다.
AI를 활용할 때도 핵심 로직과 설계에서는 제 의견과 의도를 먼저 정리하여 주도권을 유지했습니다.

3) 그룹원과의 적극적 소통

동료들과 코드, 이슈, 고민 등 여러 주제에 대해 논의하며 인사이트를 주고받았습니다.
코드 리뷰 과정에서 적극적으로 의견을 공유하고 그룹 활동을 주도적으로 이끌었습니다.

4) 건강한 라이프 밸런스 의식

의도적으로 비학습 시간을 확보해 낮잠, 집안일 등을 처리하고, 주기적 스트레칭을 실천했습니다.
무리하게 밤을 새우지 않고 컨디션 관리를 우선시했습니다.

Problem

개선할 부분, 목표 달성을 방해한 요인

1) 컨디션 관리의 근본적 한계

주말 수면 리듬 관리 실패로 월요일 컨디션이 저하되었고, 기초 체력 부족으로 낮잠 과다와 피로감이 지속되었습니다.
냉방병으로 추정되는 건강 적신호(졸림, 식욕저하, 콧물)가 학습 집중도를 크게 저하시켰습니다.

2) FE 개발에 대한 막막함과 구현 편중

HTML/CSS와 바닐라 JS로 SPA를 구현하는 것에 부담을 느끼며 회피성 행동을 보였습니다.
BE 구현에만 집중한 나머지 새로운 관점에서의 학습을 충분히 병행하지 못했고, 풀스택 과정의 취지에 어긋날 위험이 있었습니다.

3) 시간 관리와 즉답 능력 부족

PR 마감 시각을 놓치고 피드백 메시지를 확인하지 못하는 등 시간 관리에 실패했습니다.
코드 리뷰에서 설계 선택의 근거를 즉시 명확히 답변하지 못하는 경우가 있었습니다.

4) 완벽주의적 접근

요구사항 전부를 달성하고 싶다는 욕심과 이상과 현실의 간극에서 부담을 느꼈습니다.
선택 옵션인 GitHub 소셜 로그인, 유효성 검사, 에러처리에 과도한 시간을 투입해 전체 진도가 더뎌졌습니다.

Try

새롭게 도전할 부분, Problem 해결 방향, 다음 주 목표

1) 건강 관리 시스템화

기초 체력 증진을 위해 유산소, 팔굽혀펴기, 스쿼트, 플랭크 등 기초 운동 루틴을 마련하겠습니다.
주말 수면 리듬 유지를 위해 일요일 과다 수면을 피하고, 월요일 컨디션을 위한 수면 스케줄을 관리하겠습니다.

2) BE 우선 완성 후 FE 집중 투자

익숙한 흐름(요구사항 도출 -> 데이터 구조 설계 -> API 명세서 작성 -> 구현)으로 백엔드 뼈대를 우선 확보하겠습니다.
그 후 FE 구현과 학습에 전략적으로 시간을 투자하여 웹 풀스택 과정의 취지에 맞게 진행하겠습니다.

3) 알림 체계 강화와 설계 근거 정리

중요 일정에 대해 여러 알림(5개 이상)과 구간별 시간체크를 병행하여 놓치는 일을 방지하겠습니다.
설계와 선택의 근거를 설명할 수 있도록 의식적으로 정리하고 점검하겠습니다.

4) "작은 완성의 집합" 철학

완벽한 구현보다는 작은 목표를 확실히 달성하며, 방향성을 유지한 채 순차적으로 완성해나가겠습니다.
계획 달성 후에도 무리하지 않는 범위에서 다음 작업을 선행하거나 계획을 재배분하겠습니다.

[네부캠 10기] 웹 풀스택 멤버십 2주차 주간 회고

raven — Mon, 1 Sep 2025 03:22:36 +0900

KPT 주간 회고

2025-08-25 ~ 2025-08-29 | 네이버 부스트캠프 멤버십 2주차 회고

Keep

내가 잘하고 있는 부분, 계속 유지할 부분

1) 설계를 지난 주차에 명확히 함

1주차에 FE 작업보다 설계에 집중한 경험이 2주차에 도움이 되었습니다.
데이터 모델과 API 설계를 비교적 체계화해 두어서 구현이 한층 수월했습니다.

2) 가독성 중심의 리팩토링 수행

기능 요구사항을 모두 충족한 뒤, 가독성과 유지보수를 위해 주석을 추가하고 SRP 원칙에 따라 함수를 분리했습니다.
이벤트 위임으로 중복을 줄였고, 공통 로직을 별도 함수로 추출해 재사용성을 높였습니다.

3) 팀 활동에 적극 참여

코드를 먼저 공유하고, 트러블슈팅 과정을 코드와 함께 설명하며 해결 방식을 그룹에게 설명했습니다.
그룹 일지 작성을 열심히 임했고, 진행 상황과 작업 내용을 파악하고, 기록했습니다.

4) 문서 분리 및 정리

README에 섞여 있던 내용을 별도 파일로 분리해 관리했습니다.
API 명세서와 데이터 모델 문서를 각각 독립 파일로 분리해서, 제3자가 보다 쉽게 이해할 수 있게 했습니다.

Problem

개선할 부분, 목표 달성을 방해한 요인

1) CS 학습의 깊이가 충분하지 못함

1주차 회고를 반영해 CS 학습 비중을 높이려 했으나, 구현 막바지에 시간이 부족해 계획만큼 진행하지 못했습니다.

2) 코드&설계 선택에 대한 근거 제시 부족

MVC + Service 계층형 아키텍처를 적용했으나, 익숙함에 기반한 선택이 컸습니다.
해당 아키텍처와 의존성, 장단점을 잘 설명하지 못했습니다.

3) 직접 작성한 코드 비중 감소에 대한 고민

CLI 환경에서 AI를 적극 활용해 흐름&로직&소스 구조를 파악시킨 뒤, 확실한 지시와 설계를 바탕으로 작업을 넘겼습니다.
저는 주로 읽기&수정&재배치&재구조화에 집중했지만,

직접 타이핑한 코드 비중이 줄어드는 것이 장기적으로 괜찮은가 ?
이후 AI 없이도 동일 수준으로 구현이 가능한가 ?
보안 이슈가 큰 실무의 대규모 프로젝트도 같은 방식이 유효한가 ?
등의 우려가 남았습니다.

4) 계획 달성을 위한 과도한 작업

하루 작업량을 소화하지 못한 날에는 계획 이행을 위해 수면을 줄이며 밀어붙인 경우가 있었습니다.
단기 목표는 달성했으나 체력 소모가 컸습니다.

Try

새롭게 도전할 부분, Problem 해결 방향, 다음 주 목표

1) 코드&설계 선택 근거를 학습

로직, 아키텍처, 라이브러리 선택 이유를 근거 자료를 학습해서 설명 가능하도록 하겠습니다.

2) 계획 유연화와 리스케줄링

하루 계획을 지키지 못해도 실패로 보지 않고, 우선순위 재조정&범위 축소&마감 이동 등 리스케줄링을 통해서 대응하겠습니다.

3) 시간&체력 관리의 기준선 설정

계획 미달 시에도 다음 날 컨디션에 영향이 갈 정도의 야간 작업은 피하겠습니다.
최소 수면 시간과 작업 종료 시점을 나만의 기준선으로 설정하겠습니다.

4) 커밋 작성법의 체계화

기능&의도&변경 단위의 커밋 규칙을 학습하고, 실제 작업에 적용되게끔 노력하겠습니다.
이전보다 개선되었으나 아직 부족하므로, 메시지 서식과 단위 기준을 구체화하겠습니다.

추가 내용

다음 주부터 새로운 미션이 시작됩니다.
1,2주차 회고와 학습을 통해 정립된 기준을 바탕으로 더 나은 진행을 목표로 하겠습니다.
AI 코드 리뷰와 현업자 코드 리뷰를 효과적으로 받기 위해, 사전에 문서&근거 자료&리뷰 가이드를 신경쓰겠습니다.

[네부캠 10기] 웹 풀스택 멤버십 1주차 주간 회고

raven — Mon, 1 Sep 2025 02:44:38 +0900

KPT 주간 회고

2025-08-18 ~ 2025-08-22 | 네이버 부스트캠프 멤버십 1주차 회고

Keep

내가 잘하고 있는 부분, 계속 유지할 부분

1) 챌린지 대비 체력 관리를 더 의식적으로 수행함

챌린지 때처럼 몰입하되, 무리한 밤샘이나 과도한 채찍질을 하지 않았습니다.
내가 한 작업은 스스로 인정하며, 모든 시도를 유의미한 행동으로 받아들였습니다.
집안일, 자기 투자 시간 등 일상 루틴에 의도적으로 시간을 배정해 전반적인 균형을 유지했습니다.

2) 과감하게 판단하고 실행함

HTML/CSS 레이아웃 설계에서 고민이 많았으나, "웹 풀스택에서는 FE/BE 모두가 연결되어 있고 필수"라는 점을 받아들였습니다.
요구사항과 직접 연관되지 않은 추가 기능/로직은 과감히 제외하고, 기존에 대충 작성해 둔 FE/BE 코드를 삭제했습니다.
처음부터 다시 학습하며 직접 레이아웃을 배치하고 속성을 적용하는 Learning by Doing을 실천했습니다.

3) 포기하지 않고 학습-구현 사이클을 반복함

초기에는 헤더만 구현하는 데 약 6시간이 소요될 정도로 힘들었습니다.
그러나 공식 문서와 레퍼런스를 확인하고, 필요할 때마다 AI나 구글링하며 계속 작업했습니다.
그 결과 다음 페이지들부터는 속도가 붙었고, 학습과 구현의 사이클을 돌리며 모든 페이지 구성을 마무리했습니다.

Problem

개선할 부분, 목표 달성을 방해한 요인

1) 주간 계획 이행률이 낮았음

초기에 세운 계획을 지키지 못했습니다.
다른 이슈에 신경을 쓰다 보니 계획을 수정하지 않은 채 즉흥적으로 움직였고, 일정이 뒤로 밀렸습니다.

2) 구현을 CS 지식과 충분히 연결하지 못함

체크포인트, 피어 컴파일링, 미션 수행 과정에서 CS 학습으로 확장할 기회가 많았으나, 요구사항 충족에 치우쳐 본질적 원리와 개념 연결이 부족했습니다.

3) 문서화 방식에 대한 확신 부족

PR과 README를 어떻게 구조화하고 어떤 내용을 담아야 하는지 기준이 불명확했습니다.
나에게는 의도가 보이는 문서라도, 제3자가 읽을 때 충분히 명료한지에 대한 의문이 남았습니다.

4) 커밋 단위 설정의 어려움

협업 경험이 부족해 기능 단위 커밋이 익숙하지 않았고, 기준이 모호했습니다.
혼자 작업할 때는 git을 단순 버전관리 도구로만 사용해 온 습관의 영향이 있었습니다.

Try

새롭게 도전할 부분, Problem 해결 방향, 다음 주 목표

1) 계획과 설계에 집중하기

매주 월요일, 한 주의 상세 계획과 설계를 문서로 먼저 기반을 잡겠습니다.
완벽한 계획을 작성하기보다, 수정 가능한 기준선을 마련해 이후 작업과 리스케줄링의 기준으로 삼겠습니다.

2) 방향성을 잃지 않기

즉흥적 선택이 필요할 수 있으나, 기본적으로는 계획서의 방향을 준수하겠습니다.
벗어나더라도 빠르게 원래의 궤도로 복귀할 수 있도록 노력하겠습니다.

3) 구현과 학습 병행하기

무작정 구현을 진행하지 않고, 관련 CS 키워드를 먼저 도출한 뒤 구현&학습을 하겠습니다.
설령 깊은 학습이 당장은 어렵더라도, 키워드 목록을 기반으로 추후 학습을 진행하겠습니다.

4) 문서 작성법 체화하기

좋은 레포와 문서 사례를 참고해 PR/README의 서식&구성을 정리하고, 제3자의 관점에서 핵심 중심으로 작성하겠습니다.
내가 작성한 코드를 모르는 사람이 읽어도 의도를 파악할 수 있도록 노력하겠습니다.

5) 커밋 작성법 정립하기

기능 단위/변경/의도 중심의 커밋 규칙을 학습하고, 실제 작업에 적용하겠습니다.
보다 명확한 커밋 단위와 일관된 커밋 메시지 작성을 통해 문서화의 빈틈을 보완하겠습니다.

추가 내용

멤버십 과정을 챌린지처럼 모든 것을 내던지는 방식으로 접근하지 않겠습니다.
건강 관리, 운동, 집안일, 일상 루틴의 밸런스를 유지하면서 학습과 구현을 지속 가능한 속도로 이어가겠습니다.
균형 잡힌 생활이 장기적으로 더 나은 성과를 만든다는 점을 기억하겠습니다.

[네부캠 10기] 웹 풀스택 챌린지 후기

raven — Sun, 31 Aug 2025 23:38:06 +0900

네이버 부스트캠프 챌린지 후기

챌린지 안내

챌린지가 끝나고 한참 지난 이 시점에 이제서야 회고를 적게되었습니다;

계기: 전 수료생분들이 기록의 중요성을 언급해주셔서 작성하게 되었습니다.

정말 짧게 느껴졌던 4주간의 여정을 보내면서, 과정에서 배우거나 깨달은 점이 정말 많았습니다.
그 내용을 전부는 아니지만, 기억나는 만큼, 최대한 작성해보도록 하겠습니다.

모든 내용은 개인적인 경험/생각에 기반하여 작성되었습니다.

미션

미션은 매일 12시 하루나 이틀 단위로 제공되며, 어느 정도 방향과 작업할 내용을 제시해주지만 전부를 떠먹여주지는 않습니다.

GitHub Gist에 업로드하고, 각자만의 체크포인트를 세워서 하나하나 해치우는 방식으로 진행되었습니다.

레포지토리가 아니라 Gist인 점에서 조금(?) 불편했습니다.

그 과정에서 자신이 학습한 내용과 고민을 녹여내는 것 또한 중요한 부분이었다고 생각합니다.

스터디 그룹

매주 몇 명씩 그룹이 배정되어 한 주간 팀 활동을 진행했습니다.

혼자 개발 외길 인생만 살아온 저로서는 정말 황금 같은 기회였고, 새롭고 유익했습니다.
같은 목표를 향해 같은 주제로 열심히 공부하며 의견을 나누는 경험은 부스트캠프의 가장 큰 장점이라고 생각합니다.

피어 컴파일링

정해진 스터디 그룹끼리 서로의 코드를 컴파일하고 실행한 뒤, 체크리스트에 의거해 작업물을 평가했습니다.
이 과정에서 "이렇게 해석하고 구현할 수 있구나", "이 부분은 이렇게 처리할 수도 있구나"와 같은 좋은 인사이트를 많이 얻었습니다.

동시에 제가 부족한 점과 잘한 점에 대한 기준을 세우고 스스로를 객관적으로 평가할 수 있는 기회가 되었습니다.

피어 세션

각자 요구사항을 어떻게 해석하고 접근했는지, 과정에서 어떤 트러블슈팅을 경험했는지 공유했고, 잡담도 나눴습니다.

특히 저는 이전까지 "왜 이렇게 코드를 작성했는가 ?"라는 질문에 설명하는 능력이 부족했습니다.

그러나 피어 세션을 준비&진행하면서 설명력을 키울 수 있었고, 근거 기반으로 의사결정을 정리해서 말하는 감을 잡을 수 있었습니다.

어떻게 보냈는가

평균적으로 오전 8시 30분에 일어나 새벽 4시까지 작업하는 날이 대다수였습니다.

강제적인 것은 절대 아니었고, 제가 즐겁고 몰입하고 싶어서 그렇게 했습니다.

잠을 안자고 샌적도 많습니다.

다만 몸은 머리와 다르게 따라주지 않았고, 컨디션 저하로 인해 학습과 구현의 품질이 떨어지는 날이 있었습니다.

심지어 미션 하루를 거의 반 포기한 날도 있었습니다.

3주차 막바지쯤 정말 많이 지쳐, 노션에 고민 과정을 적어 슬랙에 공유했는데, 많은 분들께서 위로해주셔서 큰 힘이 되었습니다.
좋은 동료들 덕분에 주말 동안 재충전하고, 4주차 미션을 순조롭게 진행했습니다. (정말 순조로웠을까 ?)

무엇을 깨닫고 배웠는가

1) 큰 덩어리를 작은 덩어리로 쪼개 차근차근 진행하기

챌린지의 하루 단위 미션은 하루 만에 완벽히 학습&구현하기 어려운 난이도였습니다.

운영진분들도 모든 미션을 완벽히 수행하는 것은 불가능하다고 여러 번 말씀하셨습니다.

따라서 거대한 목표를 작은 단위로 쪼개고, 하나씩 완수하면서 학습 -> 구현을 반복하는 전략이 필요했습니다.

작은 단위로 쪼개서 하나씩 완수해 나가며 성취감을 쌓는 것이 다음 단계로 나아가는 원동력이 되었습니다.

마스터님 말씀처럼 구현과 학습 중 어느 한쪽에만 치우치지 않도록 균형을 유지하려고 했습니다.

2) 육체와 정신은 연결되어 있다

저는 스스로를 채찍질하며 미션을 완수하려 애썼습니다.

그 과정에서 평소 생활 리듬이 무너지고, 컨디션이 급격히 저하되면서 학습과 코드의 퀄리티도 하락했습니다.

어느 날은 이틀에 걸친 미션에서 전날 작성한 코드가 너무 엉망처럼 보이고, 자괴감이 들어 거의 진행하지 못하기도 했습니다.

이 날이 앞서 언급한 3주차 막바지였습니다.

몸이 지치니 생각도 부정적으로 흐르더군요. 그래서 육체와 정신은 연결되어 있다는 사실을 체감했습니다. 그때 마스터 JK님의 메시지가 큰 위로와 방향 제시가 되었습니다.

무더운 여름철이라 지치기도 하고 할 일이 줄어들지 않는 것 같아 머리가 아프기도 하죠
이 순간이 학습 과정에서 고점을 지나는 결정적 순간 일 겁니다. 챌린지는 CS를 학습하고, 학습하는 지식을 무언가 직접 만들면서 경험하고 연결하는 순간들의 이어져있습니다.

과정을 어느 하나만 선택하거나 그렇다고 둘 다 완벽해야 한다고 강박을 갖기 보다는
작은 단위로 나누고 반복하고 점차 연결시키는 게 가장 좋기는 합니다.

미션의 요구사항은 학습하고 연습해보기 좋은 내용들이지만 덩어리가 크기 때문에 작은 부분을 찾아내서 작게작게 구현해보는 게 필요합니다. 목표가 그 자체로 크면 다 못하면 실망감도 크기 마련이죠. 그래서 작은 목표를 자주 실행하면서 성취감도 쌓아야 합니다. 그래야 전체 중에서는 못한 게 있더라도 작은 목표를 어느 정도 쌓고 나면 쉴 때도 만족하고 쉴 수 있습니다. 그렇지 않으면 매번 찝찝하거든요.

무엇보다 "내가 한 부분은 인정해주는 자세"가 필요하다는 말씀이 정말 공감되었습니다.

이후 컨디션 회복에 집중하고, 긍정적 사고를 되찾기 위해 노력했고, 끝까지 포기하지 않았기 때문에, 결국 챌린지를 수료할 수 있었습니다.

3) 문서화의 중요성

미션을 단순히 해결하는 것뿐이 아니라, 동료가 이해할 수 있게 고민 과정과 접근 방법, 근거를 문서로 남기는 일이 중요했습니다.

실무를 경험하지 않았지만, 좋은 동료는 "지금 무엇을 하는지 투명한 사람"이라는 글을 본 기억이 있습니다.
하루의 작업을 명확히 설명하고 기술하는 능력은 협업의 기본입니다.

또한 피어 컴파일링과 운영진 평가를 위해서도 문서화는 필수였습니다.

이건 평가하시는 운영진분들도 마찬가지겠죠 ? 하하

4) AI를 활용하는 방법

학습량과 구현량이 방대하다 보니 AI를 적극 활용할 수밖에 없었습니다. 다만 사고를 AI에 맡겨 복사/붙여넣기만 반복하는 방식은 성장을 저해한다고 판단했습니다.

그래서 먼저 머릿속의 설계를 자연어로 문서화하고, 이를 AI와 토론하며 수정&보완한 뒤 구현을 시작했습니다. 구현 중 모르는 부분이 생기면 키워드&자료 추천을 받아 추가 학습을 진행했습니다.

여러 방식이 있겠지만, 저는 이러한 사전 설계 -> 토론 -> 구현 -> 학습의 순환을 꾸준히 유지했습니다.

결론과 나의 생각

지속 가능한 개발자가 되려면, 그 과정을 즐기고, "그냥 돌아가니까 멈춰야지", "늘 하던 방식대로만 하자"가 아니라, 의도적으로 낯선 환경에 자신을 던지고, 다른 시선으로 생각해 보며, 나가 아닌 모두의 성장을 위해 노력해야 한다고 느꼈습니다.

또한 내가 한 작업의 근거를 명확히 설명할 수 있어야 하며, 포기하지 않고 꾸준히 정진하는 자세가 필요하다고 생각합니다.

네이버 부스트캠프의 타이틀을 얻고 싶든, 좋은 기업에 취직하고 싶든, 나의 역량을 높이고 싶든 모두 좋습니다.

그러나 지속 가능성을 위해서는 항상 꾸준하고 성실하게 임하는 태도가 필요합니다.

급변하는 IT 바닥에서 살아남기 위한 필수 역량이라고 생각합니다.

CS 지식도 꼭 열심히 공부하셔야 합니다. (가능하다면 영어도...)

마치며

내가 나에게 수여한 내준내상

기회를 주신 네이버 부스트캠프, 그리고 함께하며 으쌰으쌰한 동료들께 진심으로 감사드립니다.
뒤늦은 챌린지 후기를 쓰며, 앞으로 나아가기 위한 계획과 다짐이 더욱 굳어지는 것을 느낍니다.

언젠가 이 글을 다시 보며, 그 기억이 새록새록 떠오르는 미래의 개발자로 성장해 있기를 내심 기대해봅니다.

함께했던 모든 분들, 하시는 일마다 잘 되시고 원하시는 바를 이루시길 기도합니다. (무교입니다)

읽어주셔서 감사합니다.

[네부캠 10기] 웹 풀스택 베이직 후기

raven — Thu, 10 Jul 2025 15:14:00 +0900

우선 저는 이번년도 2월에 4년제 컴퓨터공학과 졸업을 하고 방황하는 상태였습니다.

막연히 하반기 취업을 목표로 두었고, 그 목표를 위해서, 개인 프로젝트도 만들고, 코딩 테스트를 대비하기 위해 알고리즘도 풀면서 지내왔었습니다.

그러던 과정에서 우연히 부트캠프 관련 공고를 보게되었고, 그 공고가 네이버 부스트캠프였습니다.

기존에 우테코에서 프리코스를 수행한 적이 있었는데, 저에게 크게 도움이 되었다고 느꼈었고, 네부캠도 마찬가지로 모두에게 베이직이라는 경험을 제공해주시고, 절대평가로 입과자를 결정한다는게 매력적이고 도움이 될거라고 생각했습니다.

약 2주동안 미션 한개씩, 총 10개의 미션을 수행했는데, 그 내용과 과정이 전부 흥미로웠습니다.

저는 웹 풀스택 과정으로 JavaScript를 사용했는데, 메인 언어가 아니라서 검색과 AI의 도움을 많이 받았습니다.

기존에는 혼자서만 프로젝트를 하고, 혼자서 공부하다보니, 다른 사람들의 코드를 보거나, 리뷰, 해결방법을 다방면으로 바라보지 못했었는데, 네부캠에서는 그러한 기회의 장을 마련해주셔서 정말 많이 배우고 많이 발전했습니다.

피어 피드백 과정에서 든 생각은

"아 이런식으로도 해석할수있구나", "여기서는 굳이 왜 이런 코드를 사용했을까?" 등 여러가지 느낀점이 많았고,

"역시 세상에는 잘하는 사람들이 많구나", "어딜가든 열심히 잘 하는 사람들은 보이기 마련이구나" 라고 생각했습니다.

결과적으로 저한테 도움이 정말 많이 되었구요.

처음 1주차는 정말 열심히 했던 기억이 있었습니다. 최대한 코드를 깔끔하고 효율적이고 객체지향 방식에 맞게끔 구성한다던가, 시간과 노력을 많이 투자했었습니다.

그러나 2주차에는 개인적인 사정(ㅠㅠ)때문에 1주차보다는 집중과 시간분배가 부족했고, 정보처리기사 실기시험, 개인 포트폴리오, 코딩테스트 대비용 알고리즘, JS학습까지 병행하느라 정신적으로, 육체적으로 정말 많이 지쳤었습니다.

(밥도 잘 못 먹고, 잠도 잘 못 자고 살이 많이 빠졌습니다ㅠ)

그렇지만 최선을 다해서 결국 베이직 과정을 마무리했습니다.

베이직 과정동안 나 자신이 학습하는 방법을 재정비하고, 문제를 분석하고, 해결하고, 판단하고, 작성하고, 문서까지 기술하는 능력을 많이 성장시켰다고 생각합니다. 예를들어 피어리뷰를 진행하면서 다른 사람의 코드를 읽는다거나, 제가 작성한 GIST에 피드백 댓글을 달아주시는 동료분들이나, 수료생들이 문제를 어떻게 접근하고 해결했는지 알려주시는 영상, 자신이 실수한 내용을 댓글로 작성하는 부분, 특히 매 과제마다 회고를 진행하고, 매주 진행하는 회고가 정말 좋았습니다.

제가 전공자라서 잘 모르는 말 일수도 있겠지만, 비전공자분들도 충분히 열정만 있다면 대 AI시대를 활용해서 충분히 가능하다고 생각합니다.

베이직 과정이 종료된 다음 날 문제 해결력 테스트에 응시했습니다.

문제 해결력 테스트에는 구현3문제,서술형1문제,객관식(여러개 선택)15? 문제정도가 나온것같습니다.

구현문제는 간단한 구현문제였습니다.

난이도는 체감상 1번은 브론즈 상위권, 2번은 실버 하위권, 3번은 실버 중하위권 으로 느꼈습니다.

(JavaScript만 아니였다면 주 언어로 휘리릭 빨리 끝냈을텐데..)

그다음 서술형 문제는 특정 자료구조끼리 비교하고 동작을 서술하는 문제였습니다.

마지막 객관식(여러개 선택)들은 간단한 지문이 제공되고, 전반적인 가벼운(비전공자도 알법한) CS지식이였습니다.

시험은 약 3시간정도 진행되었고, 화장실도 불가능했고, 물같은 음료 섭취도 불가능했습니다. 이점 참고하시길 바랍니다.

다음주에 시작하는 챌린지 과정과 정보처리기사 실기시험이 겹쳐있는데, 제 전력을 바쳐서 둘 다 혼내주겠습니다.

결론적으로는 개발자로써 한 단계 성장한 느낌을 받았으며, 정말 유용하고 한번쯤은 해보길 추천하는 과정입니다.

기회주셔서 감사합니다. 열심히 하겠습니다.

(모두 고생하셨고, 모두 화이팅입니다. 개발자로써 열심히 성장해봅시다.)