혼자 개념을 정리하는 것이 협업 준비가 될지 모르겠다고 적어둔 적이 있습니다. 몇 달 지나 그 질문에 답을 내렸고, 부트캠프를 고를 때 세운 세 가지 기준을 정리했습니다.
처음 시작할 때 쓴 글에 이런 문장을 남겨뒀습니다. 개발은 결국 같이 하는 일이라는데, 화면 앞에 혼자 앉아 개념을 정리하는 것이 그 준비가 될지 모르겠다고요. 그때는 당장 답을 낼 수 있는 질문이 아니라고 생각해서 일단 눈앞의 것부터 하기로 했습니다.
몇 달 지나고 나니 답이 나왔습니다. 지금이 같이 해볼 시점입니다.
독학 자체는 나쁘지 않았습니다. 진도를 제 속도로 맞출 수 있었고, 막히면 그 부분만 며칠이고 붙잡을 수 있었습니다. 기초를 다지겠다고 했던 것도 어느 정도는 했습니다.
다만 혼자 하면서 두 가지가 걸렸습니다.
하나는 제 관점 하나로만 판단하고 있다는 점입니다. 개념을 이해하고 코드를 쓰는 것까지는 혼자 할 수 있는데, 같은 문제를 다른 방식으로 푸는 사람들의 관점은 혼자서는 얻을 수 없었습니다. 현직에서 실제로 일하는 사람들이 무엇을 기준으로 선택하는지 알고 싶었습니다. 제가 내린 결론이 맞는지 확인받고 싶었던 것이 아니라, 선택지를 더 많이 알고 나서 고르고 싶었습니다.
다른 하나가 더 컸습니다. 저는 원래 밴드에서든 테마파크에서든 여럿이 붙어서 결과를 만드는 방식에 익숙한 사람이었고, 개발자를 택한 이유 중 하나도 그것이었습니다. 그런데 정작 그 준비를 혼자 하고 있었습니다. 코드 리뷰를 받아본 적도, 남의 코드를 같이 고쳐본 적도 없었습니다. 혼자서 잘 굴러가는 상태가 오히려 준비가 덜 된 상태일 수 있다는 생각이 들었습니다.
그래서 여러 관점을 가진 동료들과 붙어서, 혼자서는 못 볼 것들을 보기로 했습니다.
부트캠프는 많은데 다 비슷해 보였습니다. 그래서 제가 필요한 것부터 정하고 거기에 맞는 곳을 찾았습니다.
1. 팀 프로젝트가 있는가. 애초에 협업을 배우려고 가는 것이니 이게 없으면 의미가 없었습니다. 강의만 듣는 과정이라면 혼자 인터넷 강의를 사는 것과 다를 게 없습니다.
2. 학습 기간이 충분한가. 짧은 기간에 많은 걸 훑는 과정은 결국 각자 알아서 따라오라는 뜻이라고 봤습니다. 기초부터 다지고 싶었기 때문에 시간이 확보된 곳이 필요했습니다.
3. 한 분야만 다루는가. 이 기준이 가장 컸습니다. 요즘 여러 분야를 한 번에 가르치는 과정이 많은데, 짧은 기간에 프론트와 백엔드를 다 배운다는 말이 잘 이해되지 않았습니다. 저는 프론트엔드로 방향을 정한 상태였고, 그 하나를 깊게 보고 싶었습니다.
이 세 가지로 좁히고 나니 선택지가 몇 개 남지 않았습니다.
서류. 학부 기록과 그동안 쓴 자바스크립트 독학 일지, 만들어본 토이 프로젝트, 졸업작품으로 만든 Express.js 기반 API 서버를 정리해서 냈습니다. 대단한 결과물은 아니지만 뭔가를 계속 만들어왔다는 흔적은 됐다고 생각합니다.
코딩 테스트. 미리 공개된 프리코스 내용을 기반으로 나왔습니다. 생각보다 어렵지 않아서 문제를 다 풀었습니다.
면접. 10분 정도 진행됐습니다. 기술을 깊게 물어보는 자리는 아니었고, 이 과정을 끝까지 해낼 사람인지 확인하는 자리였다고 느꼈습니다. 대화하듯 진행해주셔서 편하게 이야기했습니다.
이후 2~3일 만에 합격 연락을 받았습니다. 시작은 3월 7일입니다.
당분간은 블로그 글을 자주 쓰지는 못할 것 같습니다. 대신 프로젝트를 하면서 남길 만한 것이 생기면 그것 위주로 적고, GitHub에는 계속 흔적을 남기려 합니다.
바라는 건 하나입니다. 이 과정에서 성장해서, 더 성장할 수 있는 회사를 만날 기반을 다지는 것. 혼자였다면 몇 배 오래 걸렸을 것들을 여기서 줄일 수 있으면 좋겠습니다.
기초를 다지는 일은 계속할 생각입니다. 처음 글에 적었듯이 밑이 흔들리는 상태로 넘어가고 싶지 않습니다. 다만 이제는 그걸 혼자 하지 않아도 된다는 점이 다릅니다.
메타 태그를 다 넣었는데도 검색 결과는 파란 링크 한 줄뿐이었습니다. 검색엔진이 페이지를 '읽는' 것과 '이해하는' 것은 다른 문제였고, 그 사이를 메우는 게 구조화된 데이터였습니다.
전역 Suspense로 감싸면 경고는 사라지지만, 페이지의 정적 마크업까지 placeholder로 대체됩니다. Next.js 소스코드를 따라가 BailoutToCSRError가 CLIENT_RENDERED 경계로 어떻게 흐르는지 살펴봅니다.
hooks 기반 이벤트 드리븐 위젯을 만들고, 그 과정에서 왜 Electron을 선택했는지, hook과 기록 파일이라는 두 신호를 어떻게 교차 검증했는지 정리했습니다.
문서에는 "queued"라고만 적혀 있습니다. 호출 단위인지 컴포넌트 단위인지 탭 전체인지 알 수 없어서, 30개 요청을 세 가지 방식으로 직접 재봤습니다.
참조형 데이터는 내용이 같아도 주소가 다르면 다른 값으로 취급됩니다. 이 특성이 useEffect 의존성 배열과 React.memo에서 왜 문제가 되는지, useCallback과 useMemo가 무엇을 해결하는지, 그리고 왜 모든 곳에 쓰면 안 되는지 정리합니다.
인앱 브라우저에서 기능이 깨지는 문제와 대용량 목록 렌더링 성능 문제, 두 가지를 실제로 부딪히고 풀어낸 기록입니다.