혼자서 만들고 싶은 프로그램을 만들기도 하고, 코딩테스트를 위한 알고리즘도 풀어보고, 나름의 노력을 했지만, 시간이 지날수록 한계를 느꼈습니다.
여태까지 해온 것처럼, 혼자서만 하는 코딩은 편했지만, 동시에 제 코드가 우물 안 개구리의 결과물은 아닌지 검증할 길이 없었기 때문입니다.
이렇다고 할 프로젝트 경험도 없었고, 평가할 수 있는 동료도 없었고, 그저 길을 잃은 채 취업이라는 현실과 내가 하고 싶은 개발과 보안 사이에서 방황하던 시기였습니다.
그러던 중 우연히 네이버 부스트캠프 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가 동작하는 것을 보여주는 것뿐이었습니다.
이 미션을 끝내고, 시니어 리뷰어와의 피드백 세션에서 "테오" 님에게 피드백을 받으며 이러한 고민과 고충을 털어놓았던 적이 있었습니다.
테오 님: 완성은 했죠 ?
나: 완성을 못했습니다. 보안과 예외 처리를 완성하려다 보니, 프론트엔드 작업을 못 했어요. 완성했으면 더 좋긴 한데…
테오 님: "그건 "더 좋긴 한데"가 아니에요. 필수입니다.
코드를 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은 내가 짠 코드의 이유를 설명할 수 있고, 동료를 설득할 수 있으며, 어제보다 더 나은 구조를 고민하는 치열함이 배움이라고 생각합니다.
부딪히며 배운 지식만이 진짜 내 것이 된다는 사실을 이제는 확실히 알 것 같습니다.
감사 인사
동료분들에게: 방구석에 갇혀있던 저를 세상 밖으로 꺼내주셔서 감사합니다. 밤새워 함께 코드를 고민하고, 때로는 따끔한 피드백으로 저를 일깨워주셔서 감사합니다. 우리 모두 각자의 위치에서 더 멋진 개발자로 다시 만나길 진심으로 응원합니다.
마스터, 리뷰어, 시니어분들에게: 성장에만 집중할 수 있도록, 기술적인 부분뿐만 아니라 멘탈적으로도 든든한 지원군이 되어주셔서 감사합니다. 피드백과 격려 덕분에 저희는 더 높은 곳을 향해 나아갈 수 있었습니다. 또한 기술적으로 피드백과 조언을 아끼지 않으셔서, 저희가 더 나은 개발자로 성장하는 데 도움이 많이 되었습니다.
무대를 만들어준 운영진분들에게: 보이지 않는 곳에서 밤낮없이 애써주신 운영진분들의 노고에 감사드립니다. 덕분에 실패를 두려워하지 않고 마음껏 넘어지며 배울 수 있었습니다.
