개발새발 민다니

[그림으로 이해하는 가상화와 컨테이너] 물리 서버 한 대를 쪼개 쓴다고? 가상화 기초 지식

밍동망동 — Wed, 25 Mar 2026 16:06:59 +0900

[인프라 찍먹하기] 프론트 개발자, 드디어 도커의 문을 두드리다.

네, 부스트캠프가 끝나고 두 달동안 설렁설렁 놀다가

다시 마음을 잡게 된 취준생 민다입니다

이력서를 쓰는게 이렇게 어려운 일인 줄 몰랐네요...

시간 가는 줄 모르고 문서 정리하고, 여행 다녀오니 두달이 훌쩍 지난 거있죠...?

이대로는 안 될 것 같아서 매주 주제를 정해 학습해보려고합니다.

이번 주 주제는 바로 가상화와 컨테이너에요!

최근 업무 자동화 툴인 n8n에 관심이 생겨서,

사이드프로젝트 에러 해석 자동화툴을 만들고 있었는데요.

코드와 정책을 수립하고나니, 최종적으로 제 앞길을 가로막는 장벽을 마주치게 되었어요.

먼저 도커를 설치하고 컨테이너를 띄우세요...

서버 이야기만 나오면 저는 그냥 AI 따라무새가 되곤 했거든요.

더 이상 피할 수 없다는 결론에 도달했습니다.

코드를 누가 짜주건, 결국 내 코드가 어떤 환경에서 돌아가는지 설명하고 책임질 줄 알아야하잖아요?

그래서 이 책을 집어 들었습니다.

매일 한 장씩 학습하며 저만의 언어로 정리해보려고 해요.

오늘의 주제는 제 1장, 가상화 기초 지식입니다.

1. 가상화, 거대한 고철 덩어리에 영혼을 불어넣다!

예전의 데이터 센터는 거대한 물리 서버들의 집합소였다고 해요.

서버 한 대를 사면 그 위에는 딱 하나의 운영체제만 올릴 수 있었던거죠.

그런데 이 경우엔 아주 큰 문제가 발생하는데요,

아무리 비싼 고성능 서버를 사봤자,

우리가 돌리는 프로그램이 서버 힘의 10%도 채 사용하지 못해

그 막강한 성능을 만끽하지 못한다는 점이에요.

결국 나머지 성능은 전기 먹고 노는 셈이죠.

서버는 마치 대형 트럭과 같은 녀석이라,

일단 부팅하는 것만으로도 엄청 연료를 소모하거든요!

일을 얼마나 시키든,

서버를 킨 순간 기본 전력이라는 고정비가 전체 비용의 대부분을 차지하게 됩니다.

그렇다고 서버 한 대에 여러 프로그램을 억지로 쑤셔넣다가

프로그램끼리 충돌나면 전체가 뻗는 상황이 발생하겠죠...

하드웨어 가상화

이 문제를 위해 나오게 된 개념이 바로 가상화입니다!

쉽게 말해, 물리적인 하드웨어와 소프트웨어를 분리하는 마법이죠.

실제 기계가 한대여도,

소프트웨어 층을 더 쌓아서 여러 대의 독립된 컴퓨터가 있는 것처럼 속이는 것입니다.

이런 가짜 컴퓨터들을 우리가 가상 서버(VM)이라고 불렀던거죠.

가상 서버 덕분에...

1. 효율성
노는 자원 없이 물리 서버 한 대를 꽉꽉 채워 사용할 수 있음
2. 유연성
새로운 서버가 필요할 때 기계를 주문하지 않아도,
새로운 가상서버를 클릭으로 만들 수 있음
3. 가용성
물리 서버 한 대에 문제가 생기더라도,
그 위에 돌던 가상 서버들을 살아있는 다른 물리 서버로 옮길 수 있음.
서비스 중단의 두려움에서 해방!

2. 인프라 전체를 뒤덮은 가상화의 매력

가상화는 서버에만 국한된 개념은 아니에요.

현대의 데이터 센터는 컴퓨팅 자원부터 네트워크,

저장소까지 모든 인프라 구성 요소를

소프트웨어로 논리적으로 분리해 관리하거든요.

서버 가상화

물리 서버 한 대의 자원(CPU, 메모리 등)을 나누어

여러 대의 가상 머신을 구동하는 기술이에요!

예를 들어, 맥북 환경에서 개발하고 있어도

VMware나 VirtualBox를 통해

가상 윈도우를 동시에 띄워 윈도우 전용 테스트가 가능한 셈이죠.

네트워크 가상화

물리적인 케이블 연결 상태와 관련 없이,

소프트웨어 설정을 통해 논리적인 네트워크 망을 구성할 수 있어요!

같은 사무실 안의 공용 와이파이를 사용하더라도,

사내 업무용 망
외부인 전용 망

을 논리적으로 차단해 서로 간의 데이터 접근을

차단하고 보안을 강화할 수 있게 되었죠.

VLAN(가상 랜)이나 SDN(소프트웨어 정의 네트워크)을 사용해

하나의 물리 스위치에서도 독립된 여러 개의 네트워크 분리가 가능해졌어요!

스토리지 가상화

여러 개의 물리적 저장 장치를 하나의 거대한 논리적 저장 풀로 통합할 수 있어요.

물론, 반대로 쪼개어 관리할 수도 있구요!

씬 프로비저닝이라는 기술을 사용하는데,

사용자에게는 실제 물리 용량보다 큰 가상 용량을 할당하고,

실제 데이터가 저장될 때만 물리 공간을 소비하게 만드는거에요.

그러니까, 사용자에게 기본 10GB 제공이라고 표시하더라도,

실제로는 사용자가 업로드한 용량만큼만 물리 디스크 공간을 점유해

자원 낭비를 최소화하는 방식인거죠.

데스크톱 가상화

사용자의 데스크톱 환경 역시 중앙 서버에 가상화해 구축할 수 있어요!

예를 들어, 보안이 엄격한 금융권에서는

개인 PC에 데이터를 남기지 않게 하기 위해,

서버에 구축된 가상 PC에 접속해 업무를 수행하는 방식인거죠.

이 때, 모든 연산과 데이터 저장은 서버에서만 이루어지고

사용자 기기에는 화면 정보만 전송되게 되어요.

3. 가상화에서 클라우드로!

가상화가 물리 서버를 쪼개는 정교한 기술이라면,

클라우드는 이 기술을 누구나 쉽고 빠르게 이용할 수 있게 만든 서비스입니다!

사실 우리가 클라우드를 사용하는 이유는 명확한데요,

귀찮고 복잡한 건 하기 싫기 때문입니다.

예전에는 서비스 하나 만들려고

서버 장비를 직접 주문하고,
데이터 센터에 입주시키고,
OS를 설치

해야 했는데요.

이제는 AWS 같은 클라우드 업체가 미리 가상화한 자원을

손가락 몇 번으로 빌려 쓰기만 하면 되거든요.

여기서, 클라우드의 핵심 전략인 분산처리가 등장합니다.

예전에는 물리 서버를 늘리는 게 힘들었는데,

가상화 기술을 통해 EC2를 복제하기 쉬워졌으니,

여러 가상에 일을 나눠주는 방식이 선호되게 되었거든요.

스케일 업
기존에 구동 중인 가상 서버(EC2 등)의 하드웨어 사양을 높이는 수직 확장 방식
CPU의 코어 수를 늘리거나 메모리 용량을 증설해 처리 능력을 강화한다.

관리는 단순하지만 물리 서버의 하드웨어 한계를 넘을 수 없어 비용 효율이 떨어진다.

스케일 아웃
동일한 사양의 가상 서버 대수를 늘리는 수평 확장 방식
가상화 기술은 서버 이미지를 복제해 새 인스턴스를 생성하는 데 최적화되어,
스케일 아웃을 구현하기에 가장 적합한 환경을 제공한다.

서버 한 대에 장애가 발생해도 다른 서버의 서비스를 유지할 수 있어 고가용성 확보에 유리하다.

분산처리
스케일 아웃으로 늘어난 여러 대의 서버에 업무를 나누어 할당하는 일련의 과정이다.
서버 대수를 늘린다고 성능이 좋아지는 건 아니고,
유입 트래픽을 각 서버에 골고루 배분하는 로드 밸런싱 기술이 뒷받침 되어야 한다.

분산처리는 가상화 기술을 통해 다수의 논리적 자원을
하나의 거대 서비스로 안정적으로 지탱하게 만드는 운영 원리다.

뭐, 그렇게 비싼 고성능 서버 한 대를 키우는 스케일 업 방식보다

저렴한 가상 서버를 여러 대 늘려서

공평하게 일 시키는 스케일 아웃이 대세가 된거죠.

사용자가 갑자기 몰려와도 서버 한 대 더 복제해버리면 되거든요!

4. 가상화는 언제나 정답이 될 수 없다.

이번 장에서 배운 내용 중 가장 신기한 사실인데요,

가상화가 모든 상황에서 정답은 아니라고 하네요!

가상화 역시 오버헤드의 마수에서는 벗어나지 못했다고 합니다.

물리 서버와 내 서비스 사이에

가상화 소프트웨어라는 중간 관리자가 끼어 있다 보니,

명령을 전달할 때마다 미세한 지연 시간이 발생하는데,

결과적으로 성능을 쥐어짜내야 하는 특수 서비스라면

물리 서버에 직접 올리는 방식이 더 빠를 수도 있는거죠.

가상화의 편리함을 누리는 것과,

순수 물리 서버의 속도를 취하는 것은 결국 선택의 문제인 셈인 겁니다!

5. 그래도 우리 집 대문은 스스로 잠가야 한다.

뭐, 클라우드를 사용하게 되면...

클라우드 업체가 털리면 큰일 나는 위험이 있긴 한데요.

솔직히 말해서 개인이 직접 서버 보안 설정을 하는 것보다는

AWS 같은 글로벌 기업의 물리적 보안 시스템을 믿는 게 낫죠.

보안 전문가가 24시간 교대로 데이터 센터를 지키지 않을까요?

다만, 그럼에도 불구하고.

클라우드 업체는 인프라 자체의 탈취는 철저히 막아줍니다만,

그 서버의 대문을 열어둘지 말지는 우리의 책임으로 남아있습니다.

포트 설정을 엉망으로 하거나,

비밀번호를 허술하게 관리해서 생기는 문제는

당연히 우리 책임이겠죠!?

가볍게 1장을 마무리했습니다.

역시 그림으로 배우니 이미지가 잘 그려지네요.

저는 부스트캠프에서 VM을 사용했을 때,

AI로 이 사용법만 따라쳤지 솔직히 이게 뭔지도 몰랐거든요.

제가 뭘 하고 있는지 몰랐어요 하하하하하하하하

가상화는 자원을 아끼는데다,

현대 IT 서비스가 중단 없이 발생할 수 있게 만들어주는거군요!

근데 그럼 가상 서버에 OS를 매번 설치해야 하나요?

그마저 나에게는 너무 어려운 일이다.

OS는 관심 없고 앱만 격리해서 돌리고 싶은데~~~

바로 내일 학습해서 낋겨와보겠습니다 ㅎㅎㅎㅎ

[네이버 부스트캠프] 웹・모바일 10기 후기 공유 - 나의 코드가 누군가의 기록이 되기까지

밍동망동 — Thu, 19 Feb 2026 09:59:31 +0900

"완벽한 코드"라는 환상을 깨다

드디어 멤버십이 끝났다!

6개월이 진짜 순식간에 지나간 것 같은데,

블로그 쓰려고 지난 미션들을 쭉 훑어보니까 와 나 진짜 굴렀구나 싶어 새삼 체감이 된다.

솔직히 후기에 뭘 써야 할지 고민이 많았는데,

음... 정리해보자면 이번 부캠을 통해 내가 얻은 가장 큰 수확은 '현실성'이었던 것 같다.

부캠 시작 전, 소위 말하는 책 한 두 권 읽은 상태일 때는 아키텍처에 대한 환상이 좀 심했다.

현업은 진짜 장난 아니겠지? 엄청난 체계랑 무결한 아키텍처가 딱 잡혀있을 거야!

같은 막연한 몽상들. 그래서 멤버십 초기에는 아키텍처에 꽤나 집착했다.

리팩토링도 코딩하면서 자연스럽게 녹여내면 됐을 텐데,

괜히 아키텍처 정리한답시고 하루를 통째로 고민하는 데만 써버리기도 했다.

그런데 프로젝트를 하나씩 거치면서 깨달았다.

정답 같은 구조를 찾는 것보다 중요한 건 지금 우리 상황에서 가장 효율적인 게 뭘까를 고민하는 거였다.

~~필요하다고 생각할 때 분리하기!~~

~~안 쓰는 폴더가 너무 많다.~~

책 속의 완벽한 예제보다, 지금 내 옆의 동료와 빠르게 맞춰볼 수 있는 코드가 더 가치 있지 않을까...ㅎ

진짜 개발, 생각보다 별거 없다!

기술의 매몰에서 비즈니스의 이해로

부스트캠프 멤버십은 크게 세 가지 단계로 나뉜다.

개인의 역량을 끌어올리는 클론 코딩 챕터,

팀원들과 시스템의 하부를 파고드는 그룹 스프린트,

그리고 기획부터 배포까지 온전히 우리만의 서비스를 만드는 그룹 프로젝트까지.

6개월이라는 시간 동안 이 커리큘럼을 따라가다 보면,

기술을 대하는 관점이 강제로(?) 변할 수밖에 없는 순간들이 온다.

나 역시 그랬다.

첫 번째 챕터인 클론 코딩 챕터를 진행할 때만 해도 나는 기술 그 자체에 완전히 매몰되어 있었다.

당시의 나에게 '좋은 개발자'란 남들이 모르는 최신 라이브러리를 능숙하게 다루고,

누가 봐도 결벽증이 느껴질 만큼 깔끔하게 코드를 분리하는 사람이었다.

그래서일까, 당시의 내 코드들은 지나칠 정도로 파편화되어 있었다.

폴더 구조를 짜고, 컴포넌트를 원자 단위로 쪼개고, 처음 써보는 툴을 설정하는 데만 수 시간을 보냈다.
~~(+컴포넌트를 쪼개는데 익숙치 않아서 오히려 헷갈리는 구조가 나온 것은 덤이다.)~~
정작 그 기술이 이 서비스에 왜 필요한지에 대한 고민은 뒷전인 채로 말이다.

두 번째 챕터인 그룹 스프린트는 내게 또 다른 벽이었다.

내 가장 취약점이었던 CS 지식에 파묻혀 지내다 보니, 아키텍처를 고민할 여유조차 없었다.

하지만 역설적으로 그 시기를 지나며 '기본기'의 중요성을 뼈저리게 느꼈다.

화려한 도구보다 중요한 건 결국 시스템이 어떻게 돌아가는지 이해하는 것이구나!

본격적인 고민은 세 번째 그룹 프로젝트(LOCUS)에서 폭발했다...

9주(인터미션 포함)라는 시간 동안 미친 듯이 개발을 밀어붙이다 보니,

내가 그동안 지향했던 '완벽한 코드'의 허점이 하나둘 보이기 시작했다.

가장 큰 깨달음은 '일관성의 부재'였다.

어떤 부분은 강박적일 정도로 디테일하게 타입을 분리해뒀는데,

또 어떤 부분은 마감 기한에 쫓겨 일관성 없이 덕지덕지 코드를 붙여넣고 있었다.

~~지키지 말거 하지도 말자...~~

특히 타입(Type) 관리에 대한 회의감이 컸다.

코드의 재사용성과 일관성을 지키겠다고 모든 타입을 별도의 파일로 빼서 관리했는데,

이게 막상 유지보수를 하려니 독이 됐다.

읽을 때는 코드가 짧아서 보기 편할지 몰라도,

수정할 때는 정의를 찾으러 수많은 파일을 오가야 하는 비효율을 마주한 것이다.

결국 코드는 짧은 게 장땡이 아니라,

적절한 위치에 응집되어 있어야 한다는 당연한 사실을 수천 줄의 코드를 짜고 나서야 몸으로 배웠다.

라이브러리 채택 기준에 대해서도 생각이 많아졌다.

요즘처럼 LLM이 코드를 뚝딱 짜주는 시대에,

라이브러리를 가져다 쓰는 것과 직접 바닐라로 구현하는 것 사이의 손익계산은 정말 어렵다.

번들링 사이즈나 트리셰이킹 같은 성능 지표를 정량적으로 측정해보지 못한 채,

그저 "공부가 되니까 쌩코딩이 낫겠지"라며 고집했던 부분들이 지금 와서 보니 비즈니스적인 속도 측면에서는 아쉬움으로 남는다.

다음 프로젝트에서는 일일이 측정해봐야할 것 같다...ㅎㅎ

이제 기술은 더 이상 숭배해야 할 대상이 아니라, 문제를 해결하기 위한 '도구'일 뿐인 것 같다.

지금의 나에게 가장 필요한 건 새로운 기술을 배우는 게 아니라,

내가 쓴 코드가 왜 그 자리에 있어야 하는지 설득력 있게 정리하는 시간이다.

한편으로는 걱정도 된다.

수료 후 마주할 현업의 세계에는 내가 고민했던 것보다 훨씬 더 복잡하고 묵직한 '레거시 코드'들이 산더미처럼 쌓여있을 텐데,

과연 내가 그걸 다 파헤치고 뜯어볼 수 있을까?

솔직히 막막한데, 한 편으로 모든 것을 내가 책임질 부분이 아니라는 점에서 안심이 된다.

그게 팀의 의의라고 생각되기 떄문이다.

이제는 조금 더 유지보수와 비즈니스의 가치를 고민하는 '현실적인' 개발을 추구하게 될 것 같다.

침묵 속에서 배운 협업의 무게
그룹 스프린트: Web 22팀

두 번째 챕터였던 그룹 스프린트는 솔직히 고백하자면 나에게 '침묵의 시간'이었다.

평소에도 CS 지식이 부족하다고는 생각했지만,

시험이 끝나면 휘발되어버리는 얕은 지식으로는 이 거대한 미션의 벽을 넘기 힘들었다.

1도 모르는 상태에서 의견을 냈다가 그 결과에 책임을 지지 못할까 봐 겁이 났고,

결국 나는 팀원들의 속도에 몸을 맡긴 채 소위 '버스'를 타게 되었다. ^^..

지금 생각하면 참 양심 없는 선택지였나 싶어 팀원들에게 죄송한 마음이 크다...ㅋㅋㅋㅋ

하지만 마냥 손을 놓고 있을 수는 없어서, 내가 할 수 있는 최선인 '문서화'에 모든 에너지를 쏟았다.

논의된 내용을 정리하고 히스토리를 남기는 일이라도 완벽하게 해내야 내 몫을 조금이나마 한다고 생각했기 때문이다.

~~근데 그 마저도.... 후반부에 가서......~~

실무 개발에서 한 발짝 떨어져 '문서화'와 '진행 상황'을 관찰하다 보니

평소에는 보이지 않던 것들이 눈에 들어오기 시작했다.

바로 프로젝트 매니징(PM)과 기술 리딩에 대한 가치였다.

당시 Web22 팀원들은 하나같이 실력이 뛰어나고 열정적이라 프로젝트 기간을 초과한 적이 없었다.

하지만 다른 팀들의 진행 과정을 지켜보며 이런 생각이 들었다.

만약 이 고급 인력들을 더 효율적으로 활용할 수 있는 정교한 체계와 스프린트 관리가 있었다면,

우리는 어디까지 더 나갈 수 있었을까?

더... 더 짜내기...!

이때부터 PM이라는 직책에 대해 진지하게 고민하게 된 것 같다.

개발자끼리 모여 사이드 프로젝트를 한다면,

기술을 가장 잘 아는 사람이 비즈니스와 일정에 맞춰 업무를 쪼개고 분배하는

'기술 기반의 리딩'이 도움되지 않을까라는 생각이 생겼다.

프론트부터 백엔드까지 전체적인 흐름을 건드려보는 경험을 하다 보니,

단순히 내 코드 한 줄 짜는 것보다 '팀 전체의 리소스를 어떻게 최적화할 것인가'에 대한 궁금증이 생기기 시작한 시점이었다.

특히 챕터 막바지의 2주간의 리팩토링 기간은 정말 '빡셌다'.

이미 돌아가는 코드를 다시 뜯어고치고,

보이지 않는 구조적 결함을 찾아내는 과정은 개발 그 이상의 인내심을 요구했다.

사실 그때 도저히 안 돌아가던 부분들은 우리 팀의 의인 정훈님이 다 해결해 주셨다.

당시에는 "이건 한 명이 집중해서 도맡아 하는 게 효율적이겠다"라고 판단해서

가장 신뢰할 수 있는 분께 맡겼던 건데...

그룹 프로젝트까지 다 끝난 지금 시점에서 돌아보니,

그때 짊어졌던 무게가 얼마나 무거웠을지 짐작이 가서 엄청난 죄책감이 몰려온다...

밤늦게까지 이어지는 디버깅에 지칠텐데도, 끝내 해결해주신 열정에...!

다시 한번 압도적 감사를 드립니다...!

내가 모르는 CS 지식을 붙잡고 끙끙댈 때 묵묵히 정리해주시고,

각자의 위치에서 1인분 이상을 해내준 팀원들이 있었기에 그 험난한 스프린트를 무사히 완주할 수 있었다...!

Web 22팀, 다시 한 번 모두 고생 많으셨습니다!

개발, 그 이상의 가치를 디자인하다
그룹 프로젝트: Locus

마지막 챕터인 그룹 프로젝트 '해핑' 팀에는 프론트를 전공한 사람이 나밖에 없었다.

자연스럽게 프론트 리드와 디자인 툴을 도맡게 됐는데,

피그마는 멤버십에 와서 처음 만져보는 툴이었다.

학생 계정으로 사용할 수 있는 사람이 적다 보니 '일단 내가 해보겠다'고 나섰지만, 과정은 순탄치 않았다.

프롬프트가 원하는 대로 나오지 않아 울면서 오전 데일리스크럼 때 SOS를 쳤던 기억이 난다.

7시간쯤 헤매고 나서야 겨우 감을 잡았고, 그렇게 5시간을 더 쏟아부어 첫 디자인을 완성했다.

디자인 '찍먹'이었지만, 사용자에게 보여지는 화면 하나를 만드는 데 얼마나 많은 고민과 시간이 들어가는지 절실히 깨달았다...

~~일단 디자인 일관성이 없음~~

하지만 진짜 문제는 디자인보다 일정 산정에 있었다.

프론트 작업량이 많다는 건 알았지만, "다 쳐낼 수 있다"고 과신한 게 화근이었다.

내 부족함 때문에 시연이 터질 뻔한 적이 한두 번이 아니었고,

결국 문서화나 코드 퀄리티는 뒷전인 채 자책하며 개발하는 시간이 길어졌다.

죄송...해요....

이 과정에서 매니징과 기술 리딩의 분리에 대해 깊이 고민하게 됐다.

우리 팀은 테크 리더와 UI/UX, 기획 담당을 나눴는데,

팀 프로젝트 특성상 기획은 어느 한 명이 좌지우지하기보다 모두의 의견을 취합해야 하는데다,

프로젝트 아이템 선정이 늦어져서 UI/UX 디자인이 세세한 기획 정책보다 선행됐다는 문제가 있었다.

그래서 'PM'이라는 직책을 골랐으면 어땠을까 싶다.

한 명은 전체적인 일정 조율과 병목 구간 해결에 집중하는 PM 역할을 맡는 게 추후 프로젝트에서 효율적이었을 것 같다.

저번 그룹 스프린트에서는,

기술을 아는 사람이 PM을 맡아야한다고 생각했었는데,

그룹 프로젝트에서는 두 직군의 차이가 극명하게 보여서

오히려 별도로 가져가야한다는 생각이 들었다.

테크 리더: 최악의 상황을 가정해 과할 정도의 방지책과 무결한 아키텍처를 고민해야 하는 역할.
PM: 비즈니스적 현실과 타협해야 하는 역할. 기간 내에 프로젝트를 완수할 수 있도록 조율해야 한다.

개발자끼리 모여 PM을 뽑는다면,

프로젝트 흐름에서 한 발짝 떨어져 객관적으로 볼 수 있는 사람이 맡는 게 맞지 않을까? (인프라 담당이었던 아리...!?)

무엇보다 이번 프로젝트를 통해 기술보다 무서운 '사회생활'의 무게를 배웠다.

일정이 밀려 밤샘 작업이 이어지자 내 표정 관리가 전혀 되지 않았던 것이다.

팀 분위기를 저하시킨 것 같아 뒤늦게 식은땀이 흐른다.

동네 친구들마저 지적할 정도였으니,

옆에서 내 눈치를 봤을 팀원들에게는 정말 죄송한 마음뿐이다...

죄송합니다 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

멤버십 기간 동안 살도 많이 쪘는데,

이제는 운동하며 체력도 기르고 무엇보다 '건강한 마인드'를 탑재해야겠다고 다짐했다.

실력보다 중요한 건, 어떤 상황에서도 팀원들과 웃으며 소통할 수 있는 여유구나...!

다음 커밋(Commit): 사용자 경험을 설계하는 개발자

멤버십의 마침표를 찍었지만, 개발자로서의 커밋은 이제부터가 진짜 시작이다.

수료 후 며칠간 잠만 자며 체력을 회복할 줄 알았는데, 막상 마주한 현실은 이력서 퇴고의 늪이었다...ㅋㅋㅋ

상반기 내에 '인턴십 합격'이라는 결과를 내기 위해,

지금은 이력서를 버전별로 리스트업하며 나만의 강점을 다듬는 중이다.

특히 이번에 이력서 리뷰를 받으며 새로 깨달은 점이 있다.

바로 자격증...!

예전에는 컴퓨터학부의 자격증이, 어떠한 개발 실력을 증명한다고 생각하지 못했다.

그런데 막상 서류를 채우다 보니 나의 성실함과 기본 지식을 증명하는

객관적인 지표로서 자격증이 없다는 게 생각보다 의아한 포인트가 될 수 있겠더라...

그래서 상반기 중으로 정보처리기사 등 관련 자격증을 추가로 취득해 볼 생각이다ㅎㅎ

또, 단순히 글로 나열하는 포트폴리오를 넘어 나만의 색깔을 보여줄 수 있는 포트폴리오 사이트제작에 집중하려고 한다.

프론트엔드 개발자로서 단순히 기능 구현에 그치지 않고,

사용자 경험(UX)과 비즈니스적 가치를 고민하는 나의 지향점이 잘 녹아든 사이트를 만드는 것이 목표다...!

물론 그 틈틈이 휘발된 CS 지식을 다시 채우고, 코딩 테스트 공부도 병행해야 한다.

해야 할 일이 산더미처럼 쌓여 있지만,

부캠 6개월의 몰입을 경험해 본 지금의 나는 예전보다 훨씬 단단해진 느낌이다.

어찌 됐건 남은 상반기 동안은 정말 '쇼부'를 본다는 생각으로 치열하게 살아보려 한다!

코드가 단순히 동작하는 것을 넘어, 비즈니스와 사용자를 먼저 고려하는 개발자.

그게 이번 부스트캠프 10기가 나에게 남겨준 가장 소중한 이정표이자, 내가 나아갈 방향이다ㅎㅎ

이제 진짜 미친듯이 개발한다!

죽겠다....

밍동망동 — Sat, 13 Dec 2025 17:00:25 +0900

와.......

진짜 주말 회고를 이렇게 빼먹다니....

ㅋ.....

근데 지금도 쓸 짬이 안남...

[네이버 부스트캠프] 웹 풀스택 멤버십 #2:: git stash로 파일 15개 날리고 배운 것들

밍동망동 — Sun, 31 Aug 2025 02:51:23 +0900

이번 주는, 그냥 한 마디로 말하면 개처럼 망한 주였다.

스스로도 밤을 새가며 어떻게든 해보려 했지만,

돌아보면 딱히 해결된 것도 없고 손에 잡히는 결과도 없다.

그런데... 차라리 망할거면 지금같은 초반에 망하는 게 낫다.

앞으로 가야 할 길이 훨씬 길기 때문에,

여기서 정신 차리는 계기가 된 것만으로도

의미 있었다고 믿고 싶다.

목차
1. 이번 주 요약
2. 작업 명세
3. 회고:: 잘한 점과 아쉬운 점
4. 다음 주 계획
5. 짧은 다짐

1. 이번 주 요약

이번 주 내내 머릿속을 복잡하게 했던 건

다름 아닌 속도와 비교였다.

다른 사람은 이미 저만치 가 있는 것 같고,

나만 제자리에 멈춘 느낌.

거기에다 요즘 부캠 라디오나 커뮤니티에서 계속 나오는

AI 활용, Claude, MCP 세팅, 프롬프트 엔지니어링 같은 말들이

내 머릿속을 더 복잡하게 만들었다.

나도 뭔가 해야 할 것 같은 압박감이 들었다.

그래서, 직접 AI와 도구를 미션에 적용하는 실험에 들어갔다.

특히 Cursor를 설치하고,

기존 프로젝트를 레이어드 아키텍처로 리팩토링해보려 했는데...

이게 진짜 문제의 시작이었다.

문제 상황

Step 1:: 미션 요구사항의 절반을 레이어드 아키텍처로 리팩토링했다.
Step 2:: 레이어드 아키텍처의 흐름을 충분히 이해했다고 판단했다.
Step 3:: 커서에게 남은 페이지의 리팩토링을 부탁했다.

리팩토링 도중 예상하지 못한 파일 충돌과 오류가 생기고,

핵심 데이터 일부가 손상됐다.

머지 마감은 다가오는데, 해결은 안되고...

결국 불완전한 상태로 PR을 날리고 말았다.

이후 워킹 디렉토리가 오염된 상황에서

브랜치를 따고 진행하다 보니 git stash와 rebase 과정에서

stash 항목 15개가 증발하는 참사가 생겼다.

날라가자마자 일단 그냥 다 던지고 싶었음

결과적으로 이번 주 대부분의 시간은

구현이 아닌 다른 문제를 해결하는 데 쏟았고,

눈에 보이는 성과가 없을 뿐 아니라 프로젝트가 터졌다.

~~npm start가 안 돌아가는데 구현할 의지가 사라진 건에 대하여~~

그리고 정말 중요한 한 가지.

나는 아직 바닐라 JS도 잘 못하는데,
왜 자꾸 다른 언어에 눈 돌리려고 했을까

이 경험을 통해 얻은 인사이트는 다음과 같았다.

도그를 이해 없이 쓰면 독이 될 수 있다.
내가 부족하다는 걸 인정하자.
위를 보며 코딩하지 말고, 하나하나 쌓아올리자.

나도 빨리 잘하고 싶다는 마음을 누군들 안 갖겠나싶지만,

역시 기초가 부족한 사람은 애써봐야 결국 무너지게 되는 것 같다.

AI도, 결국엔 내가 어떤 문제를 해결하고 싶은지가 명확할 때만 도움이 되는거지,

그 자체가 목적이 되면 오히려 방해가 된다.

~~그리고 생각보다 AI한테 프롬프트를 공들여 작성하는 게 정말 귀찮다.~~

그리고 미션 진행 관점에서 느낀 것도 많다.

커밋 단위를 나누는 기준이 헷갈렸다.
지금은 하나의 기능을 세부 단계로 나눠 커밋하는 방향을 고민 중
시맨틱 태그, SEO, 최적화...
다 중요하지만 일단은 기능 구현이 우선이다.
리팩토링은 나중에!
자꾸 리팩토링하다가 기능도 안 끝나고 하루가 지나가는 중
완벽하게 다 이해하고 코딩하겠다는 마인드,
결국 아무것도 안 하게 만든다.

결론적으로, 이번 주는 욕심이 많았고,

방향도 잃었고, 어찌됐건 배운 게 있으니 뭐라도 된 거 아닐까.

초심을 다시 붙잡게 되는 주였다.

2. 작업 명세

이번 주는 학습한 주제 자체는 다양했지만,

전반적으로 삽질과 실패의 시간이 많았다.

평일

Cursor IDE 리팩토링에 사용해보기
Git stash/rebase 브랜치 관리 실험
레이어드 아키텍처의 구조 이해 및 도입
SEO & 시맨틱 태그에 대한 조사와 실험

주말

노션 템플릿 설정
프론트엔드 성능 최적화 가이드 완독

특히 기억에 남는 건

미들웨어/라우터/컨트롤러/서비스 계층의 분리 개념을 실감한 순서이다.

지난 주까지만 하더라도 라우터와 미들웨어,

컨트롤러의 역할이 다 비슷하게 느껴졌다.

그런데 직접 구현해보면서 구조가 어떻게 흘러가는지를 체감하게 됐고,

SRP(단일 책임 원칙)을 실감하며

기능별로 쪼개고 역할을 명확히 하는 설계가 생각보다 중요하다는 걸 배웠다.

또한, 구글 검색 엔진을 학습하며 보게 된 오피셜이 상당히 인상 깊었다.

시맨틱 태그가 SEO에 미치는 영향이 생각보다 미미하다는 사실이었는데,

따라서 SEO는 코드 가독성과 유지보수정도에만 의의를 두자는 의도로 공유했다.

다만 레딧에서 꽤 반발이 많은 오피셜이었기 때문에,

맥락을 함께 공유하는 것의 중요성을 느낀 순간이었다.

여담으로, 이번에 만난 피어분들은 유독 문서화를 정말 잘 하시는 분들이었는데

본받고자 나도 금요일 주간 회고가 끝나자마자 노션 템플릿을 정리하기 시작했다.

이 자리를 빌려 감사드립니다 ‍♀️

3. 회고:: 잘한 점과 아쉬운 점

잘한 점

무너지지 않고 뭐라도 시도했다.
실패를 부정하지 않고 기록으로 남겼다.
도구와 기술 한계를 체험으로 학습했다.
아키텍처 구조에 대한 이해가 깊어졌다.
일주일동안 개발 서적 하나를 완독했다.
부족한 점을 인식했다.

아쉬운 점

AI나 도구에 의존하면서 사고하지 않는 개발에 빠졌다.
리팩토링이나 최적화에 집착하다 정작 동작하는 코드를 완성하지 못했다.
조금 더 유의미한 PR을 작성하지 못했다.
학습이 깊이 없이 얇게 퍼져있었다.
계획의 20% 정도밖에 달성하지 못했다.
깃의 이해가 부족한 상황에서 무리한 실험을 진행했다.

무엇보다도 느낀 건,

나의 완벽주의적 태도가 문제 해결의 발목을 잡고 있다는 것.

완벽하지 않은데 대체 왜...

이해가 충분히 되지 않으면 손을 못 대는 습관이

결국 실행력을 떨어뜨렸다는 걸 이번 주에 체감했다.

4. 다음 주 계획

다음 주는 기초와 흐름에 집중할 계획이다.

뽀모도로 방식으로 시간 단위로 작업 분리
기능 구현 우선 → 리팩토링은 남는 시간에 진행
매일 아침 작업 태스크 정리 후 진행
하루 하나씩 면접 예상 질문 정리하기
다른 피어 분들의 코드를 분석하고 PR 리뷰 꼼꼼히 읽기
커밋 단위를 조금 더 세세하게 잡기

AI나 도구는 필요할 때 정확히 사용할 수 있도록

나 스스로의 기초 체력을 먼저 기를 생각이다.

아마 단순한 테스트나 문서화정도를 부탁하지 않을까.

일단 결제도 했고...

특히, 이해가 덜 되어도 일단 구현해보고,

결과를 통해 다시 이해해보고자 한다.

모각코에서 뽀모도로 학습 적용 후기를 한 피어님께 들었는데,

학습과 구현을 따로 나누지 않고 번갈아가며 자연스럽게 연결하는

이 학습 방식이 아주 유용해보였다.

~~저는 여러분들의 재능을 열심히 훔쳐가고 있습니다~~

5. 짧은 다짐

이번 주는 실력보다 큰 꿈을 꾸다 넘어진 한 주였다.

하지만 넘어진 김에 마음도 좀 고쳐먹었다.

처음엔 솔직히 부스트캠프를 취업을 위한 스펙용으로 봤지만,

지금은 개발 자체에 대한 몰입이 더 커지고 있다.

사실, 의도적으로 멋있어보이는 코드, 좋아보이는 코드에 집착했다.

누가 잘 보지도 않는데 괜히 완벽하지 않은 모습을 숨기고 싶었던걸까?

하지만 멘토분들의 겸손한 모습,

나와 동일한 고민을 느끼고 있는 동료들을 보며 이렇게 생각했다.

완벽한 만족은 없는거구나.
모두가 서로의 장점을 부러워하고 있다면,
나도 누군가에게 그런 사람이 될 수 있겠구나.

나만 이런 거 아니잖아.

이번 주에야 제 밑바닥을 인정하게 됐다.

이제야 진짜 내 속도에 맞게, 제 방향으로 나아갈 준비가 된 것 같다.

그리고 마지막으로 다짐해본다면...

손을 먼저 움직이고
실패를 두려워하지 않고
도구보다 흐름을 이해하며
매일 한 줄이라도 쌓아가는 개발자

나도 그렇게 변해갈 수 있을 거라 믿는다.

근데 블로그 글은 항상 써놓고 보면 길지도 않은데 왜 이렇게 오래 걸리는걸까?

[네이버 부스트캠프] 웹 풀스택 멤버십 #1:: 검색엔진 최적화와 PRG 패턴의 발견

밍동망동 — Mon, 25 Aug 2025 00:16:16 +0900

챌린지 1주차가 끝났다.

한 주 동안 가장 많이 붙잡고 있던 키워드는

다름 아닌 SEO 최적화였다.

처음엔 웹을 만든다는 게

단순히 페이지를 구현하는 일이라고 생각했지만,

금세 깨달았다.

결국 웹의 가치는

얼마나 많은 사람이 찾아오는가에 달려있고

그 첫 관문이 검색엔진 노출이라는 것을.

이런 느낌이다

목차
1. #Week1 목표: 시맨틱 태그와 SEO
2. 학습과 구현, 단일 책임은 잠시 미뤄두다.
3. PRG 패턴을 접하다.
4. #Week1 평가
5. 다음 주 전략
6. 한 주를 마치며

엄밀한 의미에서 이번 주 학습한
Lighthouse, PageSpeed, Search Console은
코드 실행 병목을 추적하는 프로파일링 도구는 아닙니다.

다만 이번 글에서는 편의상,
웹 성능/SEO를 측정하는 모든 도구를 통칭해
프로파일링 도구라고 언급하고 있습니다.

1. #Week1 목표: 시맨틱 태그와 SEO

이번 주는 HTML 시맨틱 태그를 적극적으로 사용하고,

그 결과를 실제 프로파일링 도구로 측정하는 데 집중했다.

사실 시맨틱 태그라는 단어는 오래 전부터 들어왔지만,

정작 HTML을 배우기 시작할 때

제일 먼저 다루는 건 div와 span이다.

웹 개발을 처음 접했을 당시,

그 둘을 간신히 익히고,

flex와 grid로 레이아웃을 잡는 데 익숙해질 즈음에야

이제는 시맨틱 태그를 써야 한다는 사실을 깨달았다.

<header>
  <h1>개발새발 민다니</h1>
</header>
<main>
  <article>
    <h2>첫 번째 글</h2>
    <time datetime="2025-08-20">2025년 8월 20일</time>
    <p>내용…</p>
  </article>
</main>
<footer>© 2025 minda</footer>

이처럼 단순히 구조를 나누는 것 이상으로,

검색엔진에게 문서의 의미를 알려주는 역할이 있다는 걸 알게 되니

매일이 새롭게 배우는 것들로 이루어져 있었다.

특히 time 태그 하나만 추가해도

검색엔진이 문서의 작성일을 인식할 수 있고,

이는 곧 신뢰도 평가에 반영된다는 사실은

정말 전공 수업에서 단 한 번도 들어보지 못한 지식이었다.

이번 주는 그래서,

SEO 최적화를 위한 태그 설계 → 구글 크롬 기준 프로파일링 → 점수 확인

을 주요 루틴으로 삼았다.

백엔드 요구사항은 과감히 미뤄둔 채,

프론트만이라도 제대로 해보자는 각오였다.

2. 학습과 구현, 단일 책임은 잠시 미뤄두다.

다만, 단일 책임 원칙은 과감히 지키지 않았다.

두 가지 이유에서 비롯된 문제 때문이다.

첫 째, SEO 측정에서 JavaScript가

오히려 방해 요소가 될 수 있다고 생각했기 때문이다.

스크립트가 언제 실행되느냐(defer, async 여부)에 따라

검색엔진 크롤러가 페이지를 제대로 읽지 못할 수도 있다는 우려가 있었다.

<script src="main.js" defer></script>

이 한 줄의 defer가 크롤러에게는

페이지 렌더링 지연으로 작용할 수 있다.

그렇다면 차라리 JS 의존성을 최소화하고,

정적인 시맨틱 구조를 우선 다지는 편이 낫다고 판단했다.

둘 째, 요구사항이 SSR에 가깝게 읽혔는데

2주차에 CSR 구조로 전환될까봐 약간의 잔머리를 썼다.

아키텍처를 지금 당장 세분화하다

유지보수에 많은 시간을 들이게 될 것 같아서...

최소한의 디렉토리,

단순한 라우터로만 페이지 이동을 처리했다.

// 단일 책임을 고려하지 않은 임시 라우터
app.get('/about', (req, res) => {
  res.render('about');
});

규모가 작기 때문에 읽기는 편한데,

확실히 단일 책임은 엿 바꿔먹은 디렉토리 구조긴 하다.

그래도 이번 주의 핵심은 어디까지나 SEO였으니,

방향성은 맞았다고 위안 삼았다

3. PRG 패턴을 접하다.

이번 주 눈에 띈 학습은

PRG(Post-Redirect-Get) 패턴이었다.

다양한 분야를 학습했지만,

처음 접한 개념이라 유독 기억에 남는다.

로그인이나 회원가입처럼,

폼 전송 후 새로고침이 일어나면

POST 요청이 반복되는 문제가 있다.

// 잘못된 처리 (forward)
app.post('/login', (req, res) => {
  res.render('home'); 
  // 새로고침 시, POST가 그대로 반복되어 중복 로그인 시도 발생
});

이게 문제가 되는 이유는 간단하다.

GET, PUT, DELETE 같은 메서드는

멱등성을 가진다.

즉, 동일한 요청을 여러 번 보내도 서버의 상태가 변하지 않는다.

예를 들어,

GET /user/123   # 같은 사용자 조회 → 항상 같은 결과
DELETE /user/123   # 같은 자원 삭제 요청 → 결과는 "삭제됨"으로 동일

하지만 POST는 멱등성이 없다.

같은 요청을 두 번 보내면

회원가입이 두 번 처리되거나 결제가 중복 발생할 수 있다.

POST /order
Body: { "item": "book", "count": 1 }

# 두 번 전송 시 → 책 두 권 결제 처리

이 문제를 해결하는 고전적인 방법이 바로 PRG 패턴이다.

// PRG 패턴 적용
app.post('/login', (req, res) => {
  // 로그인 로직 처리
  res.redirect('/home'); // POST → Redirect → GET
});

POST 요청은 한 번만 처리하고,

그 결과 페이지를 GET으로 다시 불러오게끔 하는 방식이다.

사용자가 새로고침을 누르더라도

다시 실행되는 건 GET 뿐이므로 서버 상태가 중복 변경되지 않는다.

회원가입 후 → 회원가입 완료 페이지로 리다이렉트
결제 후 → 주문 내역 페이지로 리다이렉트

현업에서 자주 보는 UX 흐름이

사실은 멱등성을 보장하기 위한 안전장치였다는 사실을 알게 되니

상당히 인상 깊어 머릿 속에 오래 남은 것 같다.

4. #Week1 평가

뿌듯한 점은 분명했다.

첫 주차임에도 배포까지 진행했고,

프로파일링 도구를 직접 돌려 성능 점수를 확인했다.

정량적인 지표로 내 코드를 설명할 수 있겠다는 작은 자신감이 생겼다.

다만 아쉬운 점은 개념 정리의 부족이다.

백엔드 도메인이 특히 생소하다 보니,

설계에 시간이 오래 걸리고 정리는 늘 뒷전으로 밀렸다.

결국 학습 성과 대비 기록이 부족했고,

발표 자료도 잘 준비하지 못했다.

그냥 앞으로는 공유 목적으로 학습 파일들을 정리해나간다고 생각하면서

기록에 조금 더 신경 쓰는 게 어떨까 싶다.

5. 다음 주 전략

다음 주는 SEO를 더 실행해볼 생각이다.

세 가지 측정 도구 중에, 가장 많은 영역을 측정해주는

Google Search Console의 색인이 제때 잡히지 않더라도,

최적화 기법을 발표용으로 정리할 예정이다.

~~사실 발표 주제가 Google Seach Console인데 측정에 며칠씩 걸리는 건에 관하여...~~

또, 백엔드에는 레이어드 아키텍처를 시도해볼 예정이다.

controllers/ -> 요청 핸들링
services/ -> 비즈니스 로직
repositories/ -> 데이터 접근

더 멋있는 아키텍처도 많지만,

규모가 작은 프로젝트라 과하게 느껴질 경우가 많아

레이어드 아키텍처를 선택하게 됐다.

이것도 좀 계층이 많긴 하지만,

라우터와 컨트롤러를 구분하는 감을 잡기 위해 시도해보려 한다.

6. 한 주를 마치며

불과 1주가 지났을 뿐인데 전과 후의 밀도가 달라졌다.

챌린지에서 그저 문제를 풀던 날들과 달리,

멤버십은 과제 하나를 붙잡고 깊게 들어가니

올해 가장 치열한 학습이 된 듯하다.

아직은 모르는 게 더 많고,

단순한 구현조차 버거울 때가 많다.

하지만 프로파일링 점수를 보며,

내가 개선할 수 있는 여지가

눈앞에 보인다는 사실만으로도 즐겁다.

앞으로의 21주,

코드를 더 섹시하게 짜는가보다는,

문제 해결력과 공유할 수 있는 인사이트를 남기는 데 집중하고 싶다.

결국 중요한 건 완벽한 설계가 아니라,

계속 배우고 나누며 앞으로 나아가는 태도이지 않나 싶다.

[네이버 부스트캠프] 웹 풀스택 챌린지 회고:: 나를 죽이지 못하는 고통은 날 더 강하게 만들 뿐이다.

밍동망동 — Sun, 17 Aug 2025 23:38:03 +0900

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

해당 포스팅은 경고 문구를 인지한 상태로 작성하였으나,
위반 사항이 염려되는 부분이 있다면 바로 수정하겠습니다.

풀로 지은 집, 벽돌로 지은 코드

챌린지 과정이 끝났다.

3주차까지는 시원섭섭했지만,

4주차에는 기력이 조금씩 떨어져서 빨리 끝났으면 좋겠다는 마음도 들었다

돌이켜보면 챌린지 기간의 목표는 많고 많았다.

사실 매주차 달라졌던 것 같다.

첫 주차에는 리팩토링과 가독성 있는 코드에 신경을 썼다.

하지만 마지막 주차에는 오히려 리팩토링을 고려하지 않는 코드를 의도적으로 작성했다.

완벽한 설계란 없다는 걸 깨달았기 때문이다.

다시 수정할 작업에 시간을 쓰는 것이,

그렇지 않을 때보다 더 큰 대가를 요구한다는 걸 직접 경험했다.

처음에는 전체 흐름을 잡으려고 노력했다.

기능을 얕게라도 쌓아 숲을 그리려 했지만, 너무 얕다 보니 금세 문제가 생겼다.

아기돼지 삼형제가 떠오른 순간이었다.

그래서 무작정 막내 돼지가 되어보려고 했다.

그러다보니 오히려 오버 엔지니어링에 빠져버렸다.

리팩토링, 테스트 코드까지.

나름 정성껏 쌓아올렸건만, 중요한 사실을 간과했다.

내 설계는 완벽하다는 착각 속에서 이상한 곳만 보강해나갔던 것이다.

코드에 흑백은 없으며, 트레이드 오프의 미학이거늘

저건 틀렸다고 단정해나간 게 패착인 것 같았다.

3주차부터는 조금씩 균형을 찾았다.

2일에 하나의 프로젝트를 끝내는 것에 적응하는게

체력적으로 정말 힘들었지만,

~~첫 날 잘못하면 겉잡을 수 없어...~~

학습과 코딩 사이에서 나름의 균형을 잡아나가는 연습을 했던 것 같다.

그리고 4주차. 드디어 감이 잡혔다.

내 생산성이 어느 정도인지,

시간 안에 무엇을 할 수 있고 어디까지가 한계인지 알게 됐다.

조건을 모두 만족하진 못했지만,

내가 해낼 수 있는 최선은 보여줬다.

그러다보니 어느새 챌린지는 끝나 있었고,

한 달이 지나버렸다.

작은 하마가 남긴 독기

챌린지가 끝나고 내게 남은 것이 무엇인지 돌아봤다.

실력?

물론 실력이 늘었다면 최고겠지만, 정직하게 말하면... 뭔가 독기가 가득 남은 것 같다.

매일 같이 내 한계를 체험했다.

머리로 알고 있는 것과, 실제로 만들어내는 건 차원이 달랐다.

니콜라스 네그로폰테가 개구리를 이해하려면 개구리를 만들어봐야 한다고 했던 말처럼,

정말 하루하루 그 말이 이해되는 나날이었다.

오늘은 이게 뭐야... 하고 내 코드에 절망했다가,

내일은 그래도 내가 만들었잖아? 라며 뿌듯해졌다가,

그런 기복이 반복되다 보니 3주차쯤부터 뭔가 기묘한 독기가 생겼다.

그런데 이게 또, 소년만화 주인공이 각성해서 울트라 모드로 돌변하는 그런 느낌은 아니었다.

몇 년 전 유행했던 작은 하마 짤처럼...

뽀짝하고 위협되지 않는 그런 독기.

시험 기간 새벽에 강의실에 남아,

에너지 드링크를 한 캔 마신 수준의 분노랄까.

미션을 무찌르러 가는 나

그래도 이건 꽤 소중하다.

내 안에 자그마한 불씨가 남아서 다음 날에도 일어나게끔 해줬으니까.

어쩌면 챌린지 기간에 얻은 것 중 가장 값진 것일지도 모른다.

실력은 조금씩 나도 모르는 새에 올라가겠지만,

이 독기는 한동안은 계속 연료처럼 매일같이 타오를 것이다.

오답을 쪼개먹으며 정답에 다가가기

문제 해결력이란 말의 의도를 파악하기 위해 매일같이 조금 고민을 해봤다.

AI 시대를 살아가는 개발자는 상당히 과도기적인 시점에 있다.

잘못하면 기술에 매몰돼버리고, 반대로 고집스럽게 거부하면 뒤처질 수 있다.

그래서 나는 어떻게 해야 올바른 방향을 잡을 수 있을까?를 매일 고민했다.

사실 솔직히 말하면, AI를 안 썼다고는 할 수 없다.

오히려 대부분의 문제는 AI의 도움 없이는 통과하지 못했을지도 모른다.

테스트 코드 작성, 디버깅, 환경설정까지.

특히 첫 세팅이나 에러 로그 파악은 AI의 도움 없이는 훨씬 시간이 걸렸을 것이다.

@pettydust

그렇다고 주객이 전도되지 않기 위해, 나만의 루틴을 만들었다.

먼저 미션이 공개되면 전체적인 틀과 흐름을 그렸다.

필요한 기능과 단계를 task 단위로 쪼개고, 각 단계에 선행돼야 할 학습을 따로 정리했다.

옵시디언을 열어 나만 알아볼 수 있는 간단한 메모를 쌓아두는 방식이었다.

예를 들어 1단계가 파일 파싱 로직 구현이라면,

그 밑에 정규 표현식 연습, 파일 입출력 기본 API 복습 같은 미니 태스크를 붙여두는 식이다.

이렇게 하면 단계를 밟을 때마다 공부할 것 → 구현할 것이 자연스럽게 연결됐다.

결과적으로 웬만한 미션은 순차적으로 진행할 수 있었다.

1단계를 완성하고 단위테스트까지 통과하면, 그 뒤에 2단계를 붙이는 식이다.

물론 2단계 코드가 1단계에 전혀 영향을 미치지 않는 건 아니었지만,

어제 만든 게 오늘 바로 무너지는 악몽은 피할 수 있었다.

다만 나는 전체 개념을 어느 정도 훑어야 마음이 놓이는 타입이라,

처음엔 항상 40%쯤 학습해둔 상태에서 구현을 시작했다.

그러다 보니 시간에 쫓겼다.

특히 3주차까지는 개념 반, 구현 반을 병행하면서 늘 허덕였다.

4주차에 와서는 전략을 바꿨다.

아예 학습-구현-테스트를 스탭별로 쪼개, 눈앞에 있는 단계만 집중했다.

이렇게 하니까 오히려 시간이 남았다.

조금 늦게 깨달은 점이라 아쉽지만, 덕분에 나와 맞는 학습법을 찾았다.

언제나 과정은 결과보다 값진 것 같다.

@pettydust

AI 활용, 어떻게 했나

AI를 단순히 정답 생성기로 쓰진 않았다.

그보다는 검색 가이드로 활용했다.

예를 들어 어떤 최적화 개념이 필요할 때,

국내 블로그만 봐도 구현이 가능한 경우가 많았다.

하지만... 개념 자체를 깊게 이해하는 데는 부족했다.

그럴 때 AI에게 이렇게 물었다.

지금 나는 이런 상황인데, 이러한 개념이 필요해.
관련해서 구글링하기 좋은 키워드를 추천해줄래?

AI가 제시한 키워드로 다시 구글링하면,

내가 몰랐던 영문 레퍼런스나 더 정제된 공식 문서를 찾을 수 있었다.

영어가 약하다 보니, 내가 직접 치던 검색어보다

훨씬 더 구체적인 결과가 나온 경우가 많았다.

특히 레퍼런스를 직접 달라는 요구는 종종 404로 끝났기 때문에

검색 키워드 브레인스토밍 도구로 사용하는 편이 훨씬 유용했다.

챌린지 생활의 꿀팁

한 가지 예상하지 못한 문제는 코드 저장 방식이었다.

챌린지 과제는 모두 Gist로 제출했어야 하는데, Gist는 디렉토리를 지원하지 않는다.

파일이 늘어날수록 내 파일 어디 갔지? 하며 헤매기 일쑤였다.

슬랙에서 한 피어분이 알려준 팁이 정말 유용했는데,

바로 디렉토리 이름을 파일명 앞에 붙이는 것이다.

예를 들어,

`src/index.js` → `src-index.js`
`test/index.js` → `test-index.js`

이렇게 해두면 Gist에서도 유사한 파일이 한눈에 보여서,

작업 속도가 훨씬 빨라졌다.

개인적으로 이게 챌린지 생활 최대의 꿀팁이라고 생각한다

AI와 함께한 디버깅

코드를 짜는 과정에서 AI는 또 다른 역할을 했다.

특히 성능 피드백에서 큰 도움을 받았다.

예를 들어,

이 구현 방식이 병목을 일으키지 않을까?
이 코드에서 동시성 문제가 생길 여지가 없을까?

이런 질문을 던지면 AI가 정확히 해결책을 주지는 않더라도,

최소한 아닌 경우를 빠르게 제거해줬다.

마치 수학문제에서 보기 다섯 개 중 세 개는 지워주는 느낌이랄까?

undefined 에러처럼 눈에 잘 안 보이는 버그도,

AI가 의심할 부분을 짚어주면 디버깅 시간을 크게 줄일 수 있었다.

물론 아직 AI가 완전하지 않아 해답은 내가 찾아나가야 했지만,

가지치기와 방향 제시의 역할은 확실했다.

부엉이에게 길을 물으며

AI를 정답을 주는 도구가 아니라,

문제 해결 여정에서 방향을 잡아주는 부엉이처럼 사용하도록 노력했다.

문제 해결력이란건 결국,

모르는 걸 어떻게든 풀어내는 힘이라고 생각한다.

AI는 그 힘을 키워주는 보조바퀴에 가깝다고 생각한다.

내가 직접 밟아나간 시행착오와 AI가 보여준 가지치기 사이에서,

비로소 나는 문제 해결 감각을 배워나간 것 같다.

메일보다 먼저 온 여름 하늘

챌린지 생활이 끝나고 나니 마음 한 구석이 텅 빈 듯했다.

끝나길 바라던 순간이었는데, 막상 끝나버리니 이게 진짜 맞나? 싶었다.

그래봤자 한 달이지만 매일 하루하루를 꽉 채웠던 터라,

삶의 큰 부분이 갑자기 사라진 기분이었다.

사실 나는 글을 다듬고 메시지를 정리하는 일을 오래 해왔다.

교지 편집부, 대학교 공식 홍보서포터즈에서 활동하며

어떤 주제든 설득력 있게 어필하는 건 자신 있었다.

그래서 코드 자체는 완벽하지 않아도

핵심을 짚고 나를 표현하는 데 강점이 있다고 믿었다.

하지만 그런 자부심은 3주차부터 무너졌다.

부족한 설계력이 드러나면서 결국 진심 모드로 각성할 수밖에 없었고,

마지막 날에는 늦잠을 자 미션을 날려먹는 실수까지 했다.

릴레이 프로젝트는 없겠지하고 방심한 게 문제였다.

이 사건 이후로는 모든 Slack 알림을 모바일에도 무조건 켜두기로 했다.

뒤늦게 제출하긴 했지만 이미 마감은 지나 있었고

토요일에 Gist 정리를 마친 뒤부터는 기다림이 견디기 힘들었다.

불안핑이 될 게 뻔했기에, 미리 비행기 표를 예약해뒀고,

일요일 새벽 짐을 싸서 삿포로로 떠났다.

불안핑과 삿포로의 하늘

결과는 잠시 잊고 하루 종일 걸었다.

하루 종일 걷기만 했다.

토요일까지 밤새 코드를 짜고 README를 정리하던 내가,

다음 날 오전부터 전혀 다른 도시를 걷고 있다는 사실만으로도

이미 기분이 환해졌다.

무엇보다 하늘이 너무 예뻤다.

여름이 다 갔다고 아쉬워할 틈도 없을 만큼,

그동안 못 본 하늘이 한꺼번에 보상이라도 하듯 펼쳐졌다.

노트북을 하루종일 열지 않아도 된다는 사실이 이렇게 행복할 줄이야.

완벽한 리프레시였다.

하늘을 보며 걷다 보니,

합격하든 떨어지든 결과를 겸허히 받아들일 마음이 생겼다.

만약 떨어진다면 인턴십 준비, 개인 프로젝트 정리, 팀 활동...

하반기를 어떻게 보낼지 차분히 계획까지 세워봤다.

기다림의 끝

여행 넷째 날, 카페에서 점심을 기다리던 중

강한 직감이 들어 메일을 열어봤다.

cafe nu @北海道札幌市豊平区豊平6条3-5-11

제목을 본 순간부터 지난 두 달이 파노라마처럼 스쳐 지나갔다.

혹시 모른다는 생각에 메일을 열어봤고,

결과는 합격이었다.

의외로 환호보다는 안도감에 가까운 감정을 느꼈다.

여행을 즐기며 나를 증명해주는 건 메일 제목 한 줄이 아니라,

책상 앞에서 하루하루 버텨온 시간이라고 마음을 정리했기 때문일까.

그래서 합격 소식이 여름 하늘만큼이나 은은하고 담담하게 다가왔다.

이제, 그 시간을 어떻게 이어갈지가 더 중요한 숙제로 남았다.

아직 미완의 문장

챌린지 동안 나는 나 자신을 끊임없이 몰아붙였다.

덕분에 분명 성장했지만, 지속 가능하기엔 조금 가혹했던 것도 사실이다.

특히 구현에 급급하다 보니 성능적인 부분을

제대로 살피지 못한 게 가장 아쉬움으로 남았다.

동시성 문제나 병목이 일어나는 순간에도,

끝내 최적화까지는 닿지 못한 경우가 많았다.

애초에 처음부터 좋은 구조로 완벽하게 짜려는 태도가 오히려 발목을 잡았던 것 같다.

이제는 구현부터 하고,

프로파일링을 통해 개선해나가는 흐름이 더 정석이라는 걸 배웠다.

나는 그동안 열심히 했다, 이 부분에 집중했다 같은 정성적인 말로 코드를 설명해왔다.

앞으로는 성능 수치, 테스트 결과, 리팩토링 전후 비교 같은 정량적인 언어로도

내 코드를 이야기할 수 있는 개발자가 되고 싶다.

또 하나의 도전은 함수형 프로그래밍이다.

아직 제대로 이해하지 못했기 때문에, 더 원초적인 언어인 하스켈 책을 집어 들었다.

부스트캠프 멤버십 학습 스프린트 기간 안에

이 부분을 파고들며, 얻은 인사이트를 동료들과 공유하고 싶다.

개발의 미덕이 나눔에 있다고 생각한다.

특히 챌린지 기간 동안 많은 피어 분들에게 도움을 받으며 이 부분을 여실히 느끼게 됐다.

이제는 내가 가진 것을 돌려주고 싶은 마음이 들어, 조금 더 열심히 공부하게 됐다.

@pettydust

그렇게 또 한 걸음을 내딛는다.

완벽하지 않아도, 균형을 잡아가며, 때로는 삐끗하더라도.

결국 중요한 건 계속 배우고 나누며 앞으로 나아가는 것이다.

그리고 마지막으로, 내 안의 작은 하마가 말한다.

날 죽이지 못하는 고통은 날 더 강하게 만들 뿐이다.

우아한 마침.

[네이버 부스트캠프] 웹 풀스택 챌린지 3주차 회고:: 리팩토링 집착, 성능, 패러다임, 동시성 지옥

밍동망동 — Sat, 9 Aug 2025 23:12:06 +0900

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

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

따라서 아쉽지만,

구체적인 미션 묘사나 상황 설명은 최대한 피하고 추상적으로 작성하고 있습니다.

목차
- TL;DR
- 3주차, 그리고 멘탈 붕괴
- 리팩토링 집착과 시간 관리
- 동시성, 성능... 새로운 벽
- 패러다임보다 문제 해결
- 균형 무너짐과 깨달음
- 마치며
- 다음 주 목표

TL;DR

3주차는 시간이 미친듯이 터졌다.

얼마나 터졌냐면,

주말에 뻗었기 때문에 4주차에 몰아 회고를 작성할 정도였다.

구현과 학습을 모두 잡으려다 둘 다 놓쳤고,

특히 리팩토링을 구현과 동시에 진행하는 습관이 시간을 갉아먹었다.

미션의 수준이 업그레이드되면서,

동시성을 생각하지 않을 수 없었고 성능 역시 측정해나가야 했다.

결국 2주차까지 나름대로 쌓아왔던 균형이 완전히 무너졌다.

리팩토링 시간을 줄이고,

패러다임에 얽매이지 않고 문제 해결 중심으로 접근했다면 뭔가 달라졌을까?

3주차, 그리고 멘탈 붕괴

3~4주차는 이틀에 한 가지 문제를 구현하는 방식으로 진행됐다.

이 일정이 여유롭게 느껴져서 첫 미션은 설계만 진행한 기행을 부려봤다.

결론부터 말하면 이렇게 하지 마세요...ㅋㅋㅋㅋ

완벽한 설계란 것은 없습니다.

설계에 공을 너무 들이는 게 좋지 않은 선택으로 느껴졌다.

변수는 항상 존재하고, 모든 조건을 예측할 수 없었기 때문이다.

결국 설계가 길어지면 길어질수록

남은 하루에 리팩토링/테스트까지 다 진행할 수 밖에 없..었다...

특히, 릴레이 프로젝트나 슬랙 자료 준비, 피어세션까지 겹치면서

무조건 진행해야 한다는 압박감이 커져갔다.

~~컨디션이 터져서 슬랙 발표는 포기하게 됐다~~

이럴꺼면 왜 밤을 샜지...

리팩토링 집착과 시간 관리

이번에 어떻게 해야 시간 관리를 잘 할 수 있었을까에 대해

정말 많이 자문하며 내 안에서 답을 찾아나갔다.

문제의 핵심은 동시에 하려는 습관이었다.

중복 코드를 유틸로 뺴고, 액션과 계산 로직을 분리하고,

단위 테스트까지 붙이는 건 좋은 습관이라 생각한다.

하지만 이번 주처럼 처음부터 끝까지 쌓아올려가는 개발 환경에서는

코드가 계속 수정/폐기될 수밖에 없었다.

결국 그 습관이 내 발목을 잡아버린 것이다 ‍♀️

첫날은 완성보다 동작 위주로 구현하고,

둘째 날에 개선과 리팩토링을 대대적으로 시행하는 전략이 오히려 더 잘 맞았다.

근데 이 사실은 4주차에 깨달았다. 이때는 그냥 멘탈이 터져서...

뭐랄까, 3주차에서 아쉬웠던 점은 유연한 타협에 대한 부분이다.

리팩토링 집착이 구현 속도를 늦추고, 오히려 멘탈을 갉아먹는 원인으로 변했다.

좋은 개발자라면 트레이드 오프를 통해

조금 더 유연하게 사고해야 했을 터인데,

조금 늦게 알아차린 것 같아 아쉽다.

리팩토링 집착이 구현 속도를 늦추고,

이 신념이 멘탈을 갉아먹는 원인이 됐다.

동시성, 성능... 새로운 벽

미션이 복잡해질수록 동시성과 비동기 처리에 대한 고려를 안할 수 없었다.

JavaScript를 처음 마주할 때부터,

JS의 꽃은 비동기 처리에 있다는 말을 주구장창 들었는데...

사실 Promise, async/await 같은 비동기 개념은 알고 있었지만

동시 접근 제어를 다뤄본 경험은 거의 없었다.

미션 난이도가 상승하면서,

이 조건에서는 동시 접근하게 되면 깨지지 않나? 라는 의문이 들 수 밖에 없었다.

문제는, 한 데이터에 여러 로직이 접근할 수 있는 상황을 해결해본 경험이 없단 것이다.

어떤 락을 걸어 충돌을 막으면 좋은지,

혹은 안전하게 병행 처리를 해야할지 결정하는 부분이 너무 어려웠다.

node.js는 멀티쓰레드를 지원하지만,

JS는 언어 레벨에서 싱글 스레드로 동작하니...

사실 조금 더 딥하게 들어가면 Node.js는 내부적으로 libuv 라이브러리를 이용해

백그라운드에서 멀티스레드 스레드 풀을 운용한다.

파일 읽기, 네트워크 요청, 압축/암호화 같은 작업이

이 스레드 풀에서 병렬 처리되는데,

이게 겉에서 본 모양새는 JS 코드 자체가 여러 일을 하는 것처럼 보인다.

여기에 Node.js 10 이후 도입된 Worker Threads까지 더해지면,

아예 JS 코드 자체를 여러 스레드에서 병렬 실행할 수도 있다.

근데 JS는 싱글 스레드인데, 이거 써도 되나?

아무튼... 요 애매한 특성 때문에 비동기와 동시성이 머릿속에서 종종 뒤섞였다.

처음엔 같은 개념인 줄 알았단 말이다.

여기에 성능 최적화와 동시성 처리 문제까지 얽히면서

프로파일링과 모니터링의 필요성을 절감했다.

CLI 환경과 실시간 처리가 고도화될수록

리눅스 환경이 훨씬 유리하지 않을까하는 결론에도 이르렀다.

시스템 콜 추적, 리소스 사용량 분석, 스케줄러 동작 관찰 등.

현업과 가까운 조건에서 실험할 수 있기 때문이다.

패러다임보다 문제 해결

객체지향 패러다임을 고집한 것도 발목을 잡았다.

이제와서 생각해보면, 굳이 그럴 필요가 있었나 싶다.

사실 JavaScript의 클래스는 문법적 설탕에 불과하다.

결국 내부적으로는 프로토타입 기반 객체로 변환되는데...

패러다임은 필요할 때 꺼내쓰는 도구처럼 사용해야했지 않았나 싶다.

하지만 나는 어느샌가 패러다임을 위한 코드를 짜고 있었고,

이게 꽤 불필요한 시간 소모를 일으키지 않았나 싶다.

메서드 한 두개는 그냥 바로 require 방식을 잘 이용하면

클래스처럼 보이게 만들 수도 있었을텐데.

module.exports = {
  greet(name) {
    return `Hello, ${name} `;
  }
};

const greetBot = require('./greetBot');
console.log(greetBot.greet('mindaaaa');

앞으로는 문제를 해결하기 위해 패러다임을 선택하는 방향으로 전환하고싶다.

균형 무너짐과 깨달음

정말 아쉬웠던 점은,

2주차까지 잡았던 학습과 구현 사이의 균형이

3주차에 완전히 깨졌다는 점이다.

지나고보니 이 부분에서 오히려 성장한 것 같지만.

당시엔 이게 너무 슬펐다 진짜.

@pettydus

학습량이 많아질수록 압도당하는 느낌을 매일같이 받았고,

중간에 불필요한 설계와 준비에 매몰되면서 야크털을 열심히 깎았다.

완벽한 설계는 없다.

오히려 숲의 윤곽만 잡고 구현하며 보완하는 편이 효율적이었는데,

당시엔 그런 인사이트를 얻을 수 없었다.

다만 한 가지, 과도한 사전 대비는 답이 아니었다.

마치며

나의 네부캠 3주차는 힘들었다.

정말 힘들었다.

그리고, 그만큼 명확한 교훈을 얻었다.

1. 리팩토링과 구현은 분리할 것
2. 패러다임보다 문제 해결 중심으로 접근할 것
3. 설계는 충분히만 하면 된다. 나머지는 구현하며 보완하자.

4주차는 그래서 이게 왜 필요한가?라는 질문을

코드 전반에 던져나가며 진행할 생각이다.

다음 주 목표

@pettydus

1. 첫날 동작 구현을 최대한 끝내놓기
둘째 날은 리팩토링과 테스트에 집중하기
두 영역을 구분해 진행하자
2. 성능 최적화 기초를 학습하자
3. 구현 목적과 필요성을 명확히 하는 습관을 들이자

[네이버 부스트캠프] 웹 풀스택 챌린지 2주차 회고:: 학습과 구현/오버엔지니어링/발표/피어피드백 방식

밍동망동 — Sun, 27 Jul 2025 17:12:36 +0900

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

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

따라서 아쉽지만 구체적인 미션 묘사나,

상황 설명은 최대한 피하고 추상적으로 작성하고 있습니다.

목차
- TL;DR
- 1주차 회고를 작성하며
- 균형과 학습, 내가 택한 균형에 대해
- 리드미의 진화: 길이보다 흐름
- 피어피드백, 나눔이 주는 성장
- 컨디션 관리 실패와 인사이트
- 완성 너머의 실험을 향해
- 마치며
- 다음주 목표

TL;DR

2주차는 한 주 내내

학습과 구현의 균형, 리듬 조절, 자기 기준 정립을 실험한 시간이었다.

학습량과 몰입도는 좋았지만,

과욕이 화를 부른 순간도 있었고,

그 과정에서 컨디션 관리가 문제 됐다.

1주차에서 세운 계획은 대체로 잘 지키고자 노력했고,

특히 README 정리는 꽤 만족스러운 수준으로 디벨롭했다.

다음 주는 학습 중심으로 무게를 더 옮겨,

완료에 초점을 두지 않고 깊은 실험을 할 계획이다.

1주차 회고를 적용하며

1주차 회고에서 세운 목표는 세 가지였다.

학습 중심 README 구성
피어피드백 방식 개선
루틴화된 하루 속에서 구현 우선 전략

이번 주차는 그 방향성을 기억하며 챌린지를 진행했고,

실제로 모든 과제를 마감 시간 내 제출하는 데 성공했다.

특히 README 작성에 있어서,

시나리오 기반 흐름 설명에 코드를 곁들이면서

분량은 줄이고 명료함은 올릴 수 있었다.

하지만 피어피드백을 진행하면서,

내가 너무 구현 쪽에만 집중하고 있다는 생각이 들었다.

지난 주와는 정말 상반된 결론에 다다른 것인데,

다른 피어분들은 학습 중심의 깊은 탐구를 통해

미션 하나를 수행하더라도

개념을 온전히 녹여내는 방식으로

접근하는 모습을 보여주셨기 때문이다.

구현과 학습, 내가 택한 균형에 대해

2주차 챌린지에서는

구현과 학습을 6:4로 시간을 분배해,

구현에 조금 더 무게를 두어 작업했다.

학습에 배정된 시간이 상대적으로 적었기 때문에

CS 개념은 최대한 딥다이브할 수 있도록 노력했다.

국내 자료보다 영어 공식 문서나 논문,

해외 커뮤니티의 논쟁 글을 적극적으로 찾아보며 학습했고,

학습의 질 자체는 지난 주보다 훨씬 깊었다고 생각한다.

그러나 그 내용을 구현에 100% 녹이는 방법은 선택하지 않았다.

완성보다 완료에 초점을 두었기 때문이다.

최적화나 구조화보다, 흐름 이해 중심의 구현을 시도했다.

즉 학습을 위한 교구로써 코드를 대했다.

그래서 대개의 미션에서

함수형이나 객체지향을 엄격하게 고려하기보다는,

과제를 시간 안에 효율적으로 구현하고자 했다.

이 선택이 나쁘지 않다고 생각했지만,

다른 피어 분들의 코드와 발표 섹션을

듣고 나니 다시금 고민이 생겼다.

나도 더 깊이 실험해봐야 하는 것은 아닐까?

리드미의 진화: 길이보다 흐름

이번 주차에서 가장 뿌듯한 변화는 README 였다.

이번 주차에는 핵심 흐름 중심으로 README를 작성하면서,

코드 첨부를 최소화하고 서사 중심으로 설명하는 방식을 택했다.

특히 피어분에게 받은 피드백 덕에,

파일 구조를 tree 명령어로 정리해 보여주는 방법을 활용하며

가독성과 전달력을 한층 더 높일 수 있었다.

이 방식은 향후 챌린지 마무리까지도 유지해보고 싶은

좋은 루틴으로 당분간 자리 잡을 예정이다.

피어피드백, 나눔이 주는 성장

이번 주 피어분들과의 피어활동은 지난 주보다 훨씬 원활했다.

이전 팀에서의 각자의 경험을 공유하면서

룰을 설정할 수 있었기 때문이다.

정해진 룰 아래에서 피드백이 진행되니,

한 시간 안에서 양질의 대화가 많이 나왔던 것 같다.

한 가지 추가적으로,

릴레이 프로젝트에서 만난 피어 분께서

공유해주신 방법이 무척 인상 깊어

다음 만날 피어분과 적용하고 싶었던 방식이 있다.

바로 지식 공유 중심의 피드백 운영 방식이다.

기존까지 진행해왔던 발표 중심 피드백이 아니라,

각자의 학습 맥락이나 궁금한 점을 나누는 경험 공유형 피드백 방식이다.

단순한 코드 리뷰를 넘어

문제 해결 과정, 선택의 이유, 우선순위 판단 기준 등을

나눌 수 있어 더욱 풍성한 피드백 시간을 가질 수 있는 것 같다.

별도의 진행자나 발표자를 지정하지 않고,

모두가 발화자가 되어 의견을 나누는 식의 피드백에 가깝다.

다음 주는 이 방식을 팀에서 도입해보고 싶다.

문제 난이도가 점점 높아지면서,

미션을 하루 안에 해결하지 못하는 상황이

많은 피어들에게 발생하고 있고,

지금 이 시점에서 코드 리터러시보다 중요한 것은

각자의 사고 과정과 관점의 교류이지 않을까하는

생각이 강하게 들었기 때문이다.

컨디션 관리 실패와 인사이트

이번 주 가장 아쉬웠던 점은 컨디션 관리였다.

월요일부터 설계에 4시간 이상 투자하며

과도하게 추상화를 진행하다보니

결국 오버 엔지니어링에 빠졌다.

아키텍처를 적용해보겠다는 욕심은 좋았지만,

실제 구현은 번거로웠고,

조립 과정에서 디버깅 난이도까지 올라가면서

결국 마감 실패로 이어졌다.

이번 주차는 수면 부족으로 루틴이 한껏 무너졌다.

잠이 부족하니 집중력이 떨어지고,

집중력이 떨어지니 작업 시간이 길어지고,

결국 피로가 누적되는 악순환이 반복됐다.

어떻게든 구현 완료에 집중했기 때문에

코드 퀄리티가 떨어지고,

동시에 시간을 너무 투입하면서

다음날까지 계속 컨디션에 악영향을 받게 됐다.

이건 단거리 달리기가 아니라 마라톤에 가깝다.

앞으로는 구현 성공보다 다음 날의 컨디션에 조금 더 우선순위를 둘 것 같다.

몰입하되, 구현 성공 여부에 강박적으로 집착하는 것은 좋지 않아보인다.

적어도 6시간동안 수면하며,

학습과 구현을 2타임으로 분리하고,

실패하더라도 적시에 멈추는 용기도 가질 것이다.

완성 너머의 실험을 향해

다음 주는 비율을 다시 조정할 계획이다.

구현:학습 = 4:6
학습을 더 하류까지 나아가자.
구현은 실험 도구에 가깝다.
객체지향과 함수형을 혼용해 시도하자.

그리고, 부캠 라디오 발표 세션 참여를 목표로 삼았다.

이번 주는 공유할 콘텐츠나 시간이 부족했지만,

다음 주는 꼭 학습 내용을 발표해보고 싶다.

그동안 피어 분들에게 알게 모르게

은 인사이트와 도움을 받았으니,

이번엔 내가 나눌 수 있는 사람이 되고 싶다는 바람을

이 발표 세션을 통해 실천해보고 싶다.

마치며

개발은 흑백의 세계가 아니라 회색의 균형 위에 서야 한다.

한 주를 마무리하며 떠오른 말이다.

완벽한 학습도, 완벽한 구현도 없다.

중요한 건 지금의 시행착오 속에서 내 기준을 정립해나가는 것이다.

그리고, 나만의 속도로 성장해야 한다.

그냥, 기 죽지 말고.

오만해지지도 말고.

끝까지 가보려고 한다.

다음 주 목표

깊은 개념 학습과 라디오 발표 준비
수면 시간 확보와 루틴 안정화
피어피드백 운영 방식에 관한 실험

3주차에서는 한층 더 유연해진 내가 되길 바라며.

아자아자

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

밍동망동 — Sun, 20 Jul 2025 21:11:04 +0900

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

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

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

목차
- 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

Create diagrams and visualizations using text and code.

mermaid.js.org

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

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를 설명할 수 있는만큼 파야하는 거 아닐까?

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

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

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

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

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

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

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

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

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

스스로 기준을 정하고,

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

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

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

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

[네이버 부스트캠프] 10기 웹 풀스택 베이직 문제 해결력 테스트 후기

밍동망동 — Mon, 14 Jul 2025 11:38:15 +0900

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

해당 포스팅은 저 경고 문구를 마음 깊이 새기며 작성했습니다.

구체적인 문항 묘사를 최대한 피하려고 노력하면서도,

다음 베이직 코스를 준비하는 여러분께 도움이 되었으면 하는 마음으로

준비 과정부터 도움될만한 팁까지 최대한 구체적으로 작성해보겠습니다.

하지만!

제가 또 다시 인지하지 못하는 동안 규칙을 어겼다면...

호다닥 삭제하겠습니다⚡️

10기는 문제 해결력 테스트를 한 번만 본다구요?

그렇다.

10기부터는 문제 해결력 테스트를 딱 한 번만 치르면 된다.

이전 기수를 직접 경험해보지 못해 확실하지 않지만,

시기상 1차와 3차 테스트가 생략되고 2차만 남은 것 같다.

나 또한 2차 테스트 기준으로 후기를 찾아봤고 대강 맞는거같다.

덕분에 챌린지에 입과한 후에는 테스트 부담 없이

미션에만 집중할 수 있겠다는 점이 매력적으로 다가왔다.

운동도 하고, 잠도 조금 더 잘 수 있을 것 같은 느낌?

실제로 베이직 코스 때는 문제 해결력 테스트 준비로

운동도 거의 못하고 근육도 많이 빠졌다

내 근육...

하지만 실제로 문제 해결력 테스트를 응시해보니

아침마다 준비한게 확실히 도움 많이 됐다.

테스트가 줄어서 준비를 덜 한다구요?

문제 해결력 테스트가 한 번으로 줄면서,

다른 기수보다 조금 더 많은 문제가 출제된 것 같다.

시험은 총 16문제로,

코드 구현 3문제
서술형 1문제
객관식 12문제 _모두_고르시오_

해당 형태로 출제됐다.

특히 이번 기수는 인터넷 검색이 불가했기 때문에 준비 방식에 대해 고민이 많았다.

이전 기수와는 달리 학습 자료도 없었다.

딱히 뭐부터 준비해야 할지도 모르겠고,

설상가상으로 베이직 코스 미션에 대한 욕심이 점점 커지면서...

다들 나처럼 뭐부터 준비해야할지 모르겠지...?

라는 다소 무책임한 안도감으로 별다른 준비 없이 시험 당일을 맞이하게 됐다.

사실 베이직 미션을 꾸준히 하면서

이정도면 기본 역량은 체크됐겠지!

하는 자만도 있었던 것 같다.

전날 밤새는 멍청이가 있다구요?

그래놓고 전날 갑자기 불안감이 몰려오기 시작했다.

갑자기 베이직 문제들을 한 번에 정리하고 CS 면접 책을 읽기 시작하다가,

5시간도 못 잔채로 아침부터 광역버스로 2시간 이동해 본가에서 시험을 치뤘다.

독립된 공간이 필요한데 자취방은 인터넷이 안 터져서...ㅎ

그 결과,

1번 문제를 제외하고 지문 해석이 잘 되지 않았다.
지문이 생각보다 길어서 약간 비문학 독해처럼 느껴지는 비중이 컸다.
잠이 부족한 상태에서 이런 유형은 정말 치명적이다.

문제가 크게 변경되지 않는거같은데 꼭 잠을 푹 자면 좋을거같다.

그리고 CS 면접 책은 딱히 도움되지 않았다.

그냥 정처기 시험 같은 느낌이긴 했는데...

그래서 몇 솔했나요?

그동안 내가 봐왔던 코딩 테스트는 IDE 사용이 모두 허용됐었다.

외부 익스텐션도 AI만 아니면 웬만큼 사용 가능했던지라

스펠링이나, 디버깅툴의 도움을 많이 받아왔다.

문제는 이번 테스트에서는 프로그래머스 이외의 모든 환경이 금지됐다는 것...

워낙 당연하게 누려왔던 것들이라 웹 에디터로만 문제 푸는 환경 자체가 굉장히 낯설었다.

자동완성도 없고, 익숙한 익스텐션도 못 쓰고,

첫 번째 구현 문제는 솔직히 베이직 코스에 임했던 모두가 동의하겠지만

거저 먹는 문제였다고 생각했는데,

undefined 에러 하나가 도저히 안 잡혀서

1시간 30분을 그대로 날려버렸다.

구현 문제 2개에 손도 못 댔는데 30분의 시간이 남자

잠을 못 잤음에도 불구하고 초인적인 집중력이 발휘됐다.

이런 느낌으로...ㅋㅋㅋ

체감상 1.7솔정도 했던 것 같지만,

사실 소수점은 큰 의미가 없지 않을까라는 생각으로 그냥 1솔이라 생각하고 있다.

베이직 OT 당시에 코치님께서 문제 해결력 테스트만으로 선발하지 않으며,

베이직 코스의 모든 과정을 지원서부터 총합하여 본다고 하셔서

그냥 남은 일주일은 잤다. 정말 푹.

수요일에 메일이 도착했다.

그리고... 해냈다.

포스팅을 작성하게 된 이유, 다음 기수에게 전하고 싶은 말.

커뮤니티가 차단되어 있다 보니

다른 분들이 얼마나 풀었는지는 정확히 모르겠다.

하지만 혹시 이 글을 본 다음 기수의 누군가가

테스트를 너무 못 봤는데 괜찮을까?

하는 마음이 든다면, 희망을 가졌으면 좋겠다.

테스트 준비를 많이 하지 않았고, 컨디션도 망쳤고, 환경도 불편했지만,

그럼에도 베이직 동안 쌓은 꾸준함과 최선을 다한 기록이 결국 나를 도왔다.

만약 베이직 코스 미션과 테스트 사이에서 저울질하고 있다면...

물론 둘 다 하면 좋겠지만,

나처럼 베이직 코스에 조금 더 집중해도 될거같다.

팁

- 딱히 알고리즘이 필요한 문제가 나오지 않는다.
변수 이름에 시간 쏟지 말자.
- 코딩 문제 난이도는 대체로 프로그래머스 Lv.2 수준이다.
문항별 체감 난이도: Lv.1 → Lv.3 → Lv.2
- 객관식이 생각보다 오래 걸림
모두 고르시오 유형에 배점이 별도로 공개되어있지 않아서 버릴 수 없음.
- 에디터 환경이 불편하다!
자동완성이나 확장 기능이 없으며
디버깅 훈련도 꼭 실제 환경에서 연습하는 걸 추천한다.
- 가능하다면 프로그래머스나 구름 IDE에서 연습해보는 것 추천!

완벽한 준비는 못했지만,
완성된 사람보다 완주한 사람이 되자는 마음으로 임했다.

중요한 건 전 과정에서 얼마나 집중했는가라고 생각한다.

두 마리 토끼를 잡기 힘들다면 베이직 코스에 조금 더 집중하는 편이 좋을거같다.