[네이버 부스트캠프] 웹 풀스택 챌린지 1주차 회고:: 피어피드백/나만의 루틴/줏대

 

*학습 활동 가이드의 콘텐츠 이용 및 보호 수칙을 준수하고, 콘텐츠 유출에 주의해 주세요.

 

해당 포스팅은 경고 문구를 인지한 상태로 작성했습니다.

따라서 구체적인 미션 묘사는 최대한 피하고 있습니다.

---

목차
- TL;DR
- 한 주 돌아보기
- 배운 점
- 개선 점
- 다음 주 목표

 

TL;DR

이번 주는 학습, 설계, 구현 사이에서 줄다리기 하며

챌린지에 적응하고,

나만의 루틴을 한껏 실험한 한 주였습니다.

 

구현에만 집중하지 않고

CS 개념을 깊이 이해하고 설명할 수 있는 학습 중심 접근을 시도했지만,

그 과정에서 루틴 붕괴, 피어피드백 어려움 등 현실적인 문제도 마주했습니다.

 

다음 주에는 완벽보다 학습을 위한 실행 가능한 수준을 목표로,

타협과 집중, 유연함 사이에서 균형을 잡아가려 합니다.

---

한 주 돌아보기

이번 주는 진짜 생활 패턴, 학습, 구현 사이에서 줄다리기한 한 주였다.

구현 난이도가 갑자기 확 어려워진 건 아니다.

 

오히려 베이직 코스에서는 `구현 자체의 실력`을 어느정도 검증한 것 같고,

챌린지에 들어서면서는 CS 비중이 확 늘었다.

 

학습 비중이 크게 늘면서, 구현해야 할 함수 시그니처 양이 많아졌다.

그러다 보니 1주차에서 가장 날 힘들 게 했던 것은 선택과 집중이었다.

 

피어 피드백을 하면서 느낀 점은 , 

내가 다른 분들보다 설계에 정말 많은 시간을 쏟는 편이구나.

 

였다.

 

작년 우테코 지원 당시에는 설계나 언어에 대한 지식이 부족해서,

미션 하나를 수행하면서도 코드를 계속 늘리기만 했던 기억이 있다.

 

도메인 클래스 몇 개만 세워둔 채로 구현을 시작하니까,

구조 없이 왔다갔다하면서 클래스와 로직을 계속 추가하게 됐다.

 

입출력 형식도 설명할 수 없고, 함수 분리도 되지 않으니

결국 내 코드 안에서 길을 잃은 적이 태반이었고,

미션 제출 이틀 전에 울면서 설계를 갈아엎은 적도 있다.

 

올해는 취업 준비와 함께 개인 프로젝트를 주로 진행했다.

그때의 경험 턱에 설계 시간을 유독 길게 잡아가면서 프로젝트를 진행했다.

 

내가 만든 메서드 입출력도 설명 못 하는 나 자신에 대한 깊은 현타가 반복되면서,

시나리오 흐름이 명확해질 때까지는 구현에 손을 대지 않는 방식을 선택했다.

 

이번 챌린지 1주차도 마찬가지였다.

1차 러프 설계를 마치고,

미션에서 필요한 CS 개념을 공부한 뒤,

구조와 흐름을 분석해 2차 설계를 마쳐야만

본격적으로 코드를 짜기 시작했다.

 

덕분에 정오에 미션이 공개되어도,

자정까지 코드를 한 줄도 못 짠 날도 있었다(...)

 

처음 며칠은 슬랙도 자주 확인했는데,

어느 순간 슬랙에 들어가보면 내가 설계만 하고 있던 시점에

이미 구현을 끝낸 분들이 보이기 시작했다.

 

조급한 마음이 들 수 밖에 없었고,

나는 늘 이런 상황에서 문제 상황을 통제하는 쪽을 택해왔다.

 

페이스 유지가 가장 중요한 영역이었기 때문에,

이번에도 슬랙의 `notice` 채널만 제외하고 알람을 꺼두고,

설계가 끝나면 들어가서 확인하는 방식으로 운영했다.

 

이번 주 피어피드백이나 슬랙에서

클래스를 짜다가 중간에 바꿨다.
설계를 처음부터 시작한다.

 

와 같은 비보가 많이 보였다.

 

러닝 바이 두잉.

 

그 비보를 보면서도, 내가 잘 하고 있는 것인지 확신이 안 서기 시작했다.

 

오히려 이렇게 구현을 미루는 것보다,

해보면서 갈아엎으면,

학습 효율이 더 좋지 않을까?

 

챌린지 철학은 분명 러닝 바잉 두잉이었는데,

나는 러닝 바이 러닝 바이 러닝러닝 두잉 ...😅

이게 맞는 방향일까, 고민이 많아졌다.

 

마침 셋째 날에는 자신 있는 주제가 나왔고,

이번엔 제대로 러닝두잉두잉으로 가보자! 했는데... 시간이 터졌다.

 

SRP는 그럭저럭 지켰지만,

코드 비중을 늘리면서 테스트 코드에 해피/엣지 케이스도 넣고

SRP도 함수 단위로 꼼꼼하게 지켜보니 결국 9시가 다 돼서야 제출했다.

 

그러다 수목금 일정이 밀리기 시작했고,

결국 하루 3시간씩 자면서 버티는 해피 챌린지 생활이 시작됐다.

 

그러던 금요일, 부캠라디오에서 Lucy님이 말씀해주셨다.

이번 주가 가장 쉬운 주다.

그 말을 들은 순간,

이제는 진짜 학습과 설계, 구현의 줄다리기를 잡아야겠구나 싶었다.

 

매주 피드백을 하되,

남들 말에 휘둘리지 않고,

나한테 맞는 주간 운영 리듬을 만들자! 라는 다짐이 생겼다.

---

개구리를 이해하려면, 해부하지 말고 만들어봐야 한다. - 니콜라스 네그로폰데 

 

주말 내내 고민한 결과, 이런 생각에 다다랐다.

1. 개념을 온전히 이해했다면 구현은 그렇게 어렵지 않다.
2. 최적화나 완전한 아키텍처 구현은 어렵다.
    하지만, 챌린지 과제의 핵심은 코드를 이해의 수단으로 사용하는 것이다.
    개념 딥다이브와 전체적인 흐름만 구현하면 충분하다.

 

학습에 너무 몰입하다 보면 어쩔 수 없이 루즈해진다.

학습을 두 배 더 많이한다고 해서,

정확히 두 배 더 많은 양을 알고 있는 것도 아니다.

 

첫 2시간은 집중해서 핵심 개념을 익혀보자.

그 이후 시간은 정말 디테일한 부분을 위한 욕심일 수 있다.

 

나는 이렇게 정리했다.

개발자는 트레이드오프의 직업이고,
나아가 자기합리화의 직업이다.

 

생산성을 놓칠 수 없고,

최적화는 끝도 없는 것이니까,

오히려 시간 제한을 두는 게 훨씬 낫다.

 

✔️ 하루 흐름

단계	시간대	설명
문제 조건 해석	12:00 ~ 13:00	핵심 요구사항 분석
러프 설계	13:00 ~ 14:00	흐름 구상, 주요 컴포넌트 정리
CS 딥다이브	14:00 ~ 17:00	관련 개념 학습, 개념화
정밀 설계	17:00 ~ 18:00	클래스, 함수 시그니처, 호출 구조
저녁 및 쉬는 시간
구현	22:00 ~ 04:00	실제 코드 작성

 

💡 모든 문서화는 해당 단계에 병렬적으로 진행한다.

 

물론 스트레칭도 하고, 틈틈이 딴짓도 하다 보면 미뤄지겠지만...

최소한 4시에는 잠 들어서 9시 30분에 시간 맞춰 체크인하는 걸 목표하고 있다.

 

배운 점

이번 주에 가장 크게 배운 건,

피어피드백의 힘이었다.

 

서로 다른 언어와 배경에서 온 사람들과 대화하다 보니

같은 문제를 푸는 방식조차 다르고,

그걸 설명하고 듣는 과정에서 생기는 인사이트가 정말 컸다.

 

예를 들어, 백엔드 경험이 있는 피어분들의 코드는

어떤 관점을 중시하느냐에 따라 구조와 흐름이 달랐다.

 

어떤 분은 데이터 흐름이 선명했고,

어떤 분은 에러 핸들링에 진심이셨고,

어떤 분은 코드의 추상화나 성능 면에 진심이셔서 감탄하게 됐다.

 

피어 피드백을 진행할수록,

나는 뭘 우선순위에 두고 코딩하지?

라는 질문을 자주 던지게 됐다.

 

특히 매일 있는 피어컴파일링 시간에는

내 코드를 설명하는 게 생각보다 훨씬 어려웠다.

 

나조차 다른 분들 코드 로직을 바로 읽기 어렵고,

내 코드를 그대로 설명한다고 해도 이해가 잘 안 될 게 당연하다.

 

그래서 자연스럽게,

어떻게 하면 더 잘 설명할 수 있을까?

시나리오 흐름은 어떻게 시각화하면 좋을까? 를 고민하게 됐다.

 

그 과정에서 이런 방식을 활용하게 됐다.

특히, 후술할 의사 코드는 피어님의 발표에서 인상깊게 봤기 때문에

다음주부터 도입해볼 예정이다.

 

활용한 툴

🧩 Mermaid

Mermaid

- 시각적 다이어그램을 마크다운처럼 쉽게 작성할 수 있는 도구
- 복잡한 로직이나 컴포넌트 간 흐름을 설명할 때 유용

graph TD
A[문제 조건 해석] --> B[1차 설계]
B --> C[CS 개념 학습]
C --> D[2차 설계]
D --> E[구현 시작]

 

🧩 Pseudocode

- 실제 코드처럼 보이지만, 특정 언어에 얽매이지 않고 로직을 설명하는 방식
- 피어분들과 대화할 때 오해 없이 전달 가능

If 사용자가 로그인하지 않은 상태라면
     로그인 페이지로 이동
Else
    메인 페이지로 이동
End If

 

이런 도구들을 알아보는 과정에서,

덕분에 피어컴파일링이 회의가 아니라

진짜 하나의 지식 교류의 장처럼 느껴졌다.

---

특히 인상 깊었던 피어분 한 분이 있었다.

그분은 성능적인 부분을 정말 깊이 고민하셨고,

미션의 제출보다 코드의 방향성과 완성도를 더 우선시하는 모습을 보여주셨다.

 

당장의 제출이 중요한 게 아니라,

내가 이 문제를 어떤 방식으로 해결하고 싶은지가 중요하다는 태도였다.

 

그 모습을 보면서,

아 진짜 개발자는 저런 마인드여야하는구나.

하는 감탄과 함께,

나도 단순히 미션을 해결하기 위한 코드가 아니라

내 기준과 목표를 가진 코드를 짜야겠다는 다짐을 하게 됐다.

 

어려웠던 점

이번 주에 어려웠던 점은 크게 두 가지였다.

 

1. 피어피드백의 어려움

코드 피드백을 받아본 경험은 있는데,

상호 피드백을 진행한 경험은 거의 전무한 수준이다(...)

 

그러다보니, 어떤 방식으로 진행하면 좋을지에 대한 고민이 많았다.

 

하지만...

과제 난이도도 높고 코드 리터러시가 높은 편도 아니어서,

수면 시간이 밀리고 집중력이 떨어지는 순간부터

코드가 눈에 안 들어오기 시작했다.

 

그 상태에서 피어분들이 설명해주시는 로직을 듣다 보면,

중간에 놓치는 포인트들이 자꾸 생기고,

그걸 어디서부터 되짚어야 할지 감이 잘 안 잡혔다.

 

또 하나는,

진짜 궁금해서 묻고 싶은데, 어떻게 표현해야 내 의도가 잘 전달될까?

라는 고민이 컸다.

 

예를 들어 정말 작은 의문이 생겨서 질문을 하려 해도,

혹시라도 공격적인 피드백으로 들리진 않을까,

아니면 이해 부족처럼 비춰지지 않을까 싶어서 괜히 조심스러워졌다.

 

결국 머릿속에서는 CPU에 과부하가 걸린 것처럼

말을 예쁘게 다듬는 데에 너무 많은 리소스를 쓰게 되고,

질문이 입 밖으로 나오기까지 딜레이가 생겼다.

 

그 사이 타이밍을 놓치거나,

아예 포기한 질문도 꽤 있었다.

 

2. 학습 루틴의 붕괴

또 하나 어려웠던 건 학습 시간의 비효율이다.

 

특히 둘째 날, 문제 난이도가 급격히 올라가면서

첫 날 잡아뒀던 학습 루틴이 완전히 무너졌다.

 

밤을 새우는 일이 많아졌고,

중간중간 쪽잠을 자다 보니 하루 흐름이 점점 뒤로 밀리고,

공부는 오래 했는데 남는 건 별로 없는 상태가 반복됐다.

 

특히 새벽 시간대에 집중력이 떨어진 상태에서

CS 개념을 공부하다 보면

분명히 내가 한 시간 전에도 이거 봤는데, 낯설다...

하는 느낌을 자주 받았다.

 

단순히 공부가 안 된다는 게 아니라,

학습을 비효율적으로 반복하게 되는 루프에 빠진 것 같았다.

 

결국 루틴이 무너지면서,

학습 시간은 길어졌지만 효율은 줄어드는 아이러니한 상황이 만들어졌다.

 

다음 주부터는 이 부분을 개선하는 게 가장 큰 목표 중 하나다.

 

개선점

피어피드백 운영 방식 개선

1주차에는 팀빌딩 시간이 따로 없어서

피어피드백 진행 시간에 대한 명확한 규칙이나 합의 없이 그냥 흘러갔던 것 같다.

 

그래서 2주차에는 팀빌딩 시간에 꼭 이 부분을 다같이 이야기해보고,

서로 어떤 기준이나 방식을 가질지,

미리 조율하는 시간을 가지고 싶다.

 

피어피드백은 단순한 리뷰 시간이 아니라,

각자의 문제 접근 방식과 사고 흐름을 공유하는 자리라고 생각하기 때문에

질문 방식이나 코드 공유 방식에 대해 좀 더 정리하고 참여하고 싶다.

 

README 구성 개선

이번 주에 또 하나 느낀 건,

내가 리드미를 짧게 쓴 것 같은데 왜 스크롤이 안 끝나지...?

 

라는 부분이다😅

정말 열심히 설명하다 보니

자꾸 박찬호씨가 빙의된 듯한 분량이 되어버렸다.

 

설명이 구체적인 건 좋은데,

너무 디테일 중심으로 가다 보니 핵심이 뭉개지는 느낌이 있었다.

 

앞으로는 최대한 의사코드와

전체 흐름 중심의 시나리오 설명으로

숲을 먼저 보여주는 방식을 택하려고 한다.

 

또, 이론에 대한 부분은 모두 학습정리.md에 모아 관리하기로 했다.

기존에는 미션 구현에 필요한 이론은 README에도 명시하고,

학습정리에 요약하는 방식으로 진행했는데,

 

새 방식을 선택하면 리드미에는 정말 필요한 핵심 정보만 남기고,

나머지 학습 내용은 분리해서 관리할 수 있으니 훨씬 효율적일 것 같다.

 

하루 루틴 개선안

다음 주부터는 다음과 같은 시간 단위 루틴으로 운영할 계획이다.

단계	시간대	설명
문제 조건 해석	12:00 ~ 13:00	핵심 요구사항 분석
러프 설계	13:00 ~ 14:00	흐름 구상, 주요 컴포넌트 정리
CS 딥다이브	14:00 ~ 17:00	관련 개념 학습, 개념화
정밀 설계	17:00 ~ 18:00	클래스, 함수 시그니처, 호출 구조
저녁 및 쉬는 시간
구현	22:00 ~ 04:00	실제 코드 작성

 

수면은 9시까지 5시간 숙면,

저녁에 쪽잠 보충하는 방식으로 체력도 분산할 계획이다.

 

물론, 앞으로 미션 난이도가 더 올라가면

과제를 완전히 수행하지 못하는 날도 생길 거라고 생각한다.

 

그렇다고 다음날 컨디션을 완전히 망치면,

오히려 전체 리듬이 무너진다.

 

개발자의 소양은, 완벽한 코드를 작성하는 것이 아니라,
70%의 완성도를 정해진 시간 내에 실현하는 능력이다.

 

이 말처럼,

제한된 시간 안에서 우선순위를 정하고,

적절히 타협하는 능력이 진짜 주니어에게 필요한 역량이라고 생각한다.

 

그래서 앞으로는 꼭 시간 단위로 체크하면서,

못 하면 못 한 대로,

그 안에서 최선을 다해 마무리 짓는 방향으로 구현할 계획이다.

 

완벽보다 완료.

 

이걸 마음에 새기고 2주차를 맞이하려 한다.

 

다음 주 목표

이번 주에는 전체 루틴에 적응하면서,

내가 부족한 부분이 어디인지를 꽤 명확하게 파악할 수 있었다.

 

그래서 다음 주에는 타협과 전체 흐름을 키워드로 삼으려고 한다.

나무보다 숲부터 보는 방식을 연습하고,

매일매일 나 자신과 애자일하게 피드백을 주고받는 한 주를 보내고 싶다.

 

물론, 학습 중심으로 가는 방향은 그대로 유지할 생각이다.

하지만 미션을 하나도 구현하지 못하는 상황도 결국 문제라고 생각한다.

 

CS 개념은 깊이보다는 흐름과 맥락을 설명할 수 있는 게 더 중요하다.

나만 이해하는 지식이 아니라, 누구에게든 설명 가능한 지식이 되어야 한다.

 

나는 코드 구현이나 기능 완성 자체보다는,

그 과정을 통해 무엇을 배웠는지에 집중하고 싶다.

 

예를 들어,

개구리를 학습한다는 건
모세혈관까지 다 구현하는 게 아니라,
딱 봐도 개구리처럼 보이고,
개구리의 핵심 특성만 갖추면 되는 것.

 

내 목표는 완벽한 개구리를 만드는 게 아니라,

그 개구리를 통해 흐름을 이해하는 것이다.

 

그래서 다음 주에는 기능 명세를 정리하고,

정해진 시간 안에 일정 수준까지 구현을 마치는 연습을 할 생각이다.

 

이건 타협이라기보다는,

개발자에게 꼭 필요한 선택과 집중의 훈련이라고 보고 있다.

 

주말 내 이런 생각을 계속 했다.

CS를 핥듯이 훑는거보다, 구현을 포기하더라도 CS를 설명할 수 있는만큼 파야하는 거 아닐까?

 

그런데 아무리 고민해봐도,

지금의 목적이 학습이라면,

모든 걸 완벽하게 만들 필요는 없다는 결론에 도달하게 됐다.

 

부스트캠프의 미션은 정답이 있는 과제가 아닌데다,

모두가 서로 다른 목표와 사고 흐름을 가지고 있다.

 

나만의 기준이 무엇보다 중요하다.

 

물론 고집과 줏대는 한끗차이고,

잘못 전달되면 콧대만 높아 보인다는 걸 알고 있다.

 

하지만 나는 개발자가 단순히 빠른 구현만 잘하는 사람이 아니라,

스스로 기준을 정하고,

그 기준에 따라 문제를 풀어갈 줄 아는 사람이라고 생각한다.

 

그래서 이번 주의 핵심 목표는

줏대는 유지하되,
유연하게 타협하면서,
학습과 구현 사이의 밸런스를 맞추는 것.

 

다음 주는 그 균형 잡기에 조금 더 집중해볼 예정이다.