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

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

 

드디어 멤버십이 끝났다!

 

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기가 나에게 남겨준 가장 소중한 이정표이자, 내가 나아갈 방향이다ㅎㅎ

 

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