부트캠프에서 공부하는 당신을 위한 편지
한 달 동안 멘토링 프로그램에서 멘토로 활동하며 정리한 생각을 공유합니다.
시작하며
저도 아직 배울 것이 많은 n년차 개발자이지만, 우연한 계기로 한 달 조금 넘는 시간 동안 부트캠프에서 공부 중인 분들을 위한 멘토링 프로그램에 멘토로 참여했습니다.
제 코가 석 자일 수 있으나, 제가 개발자로 살면서 배우게 된 생각들을 다른 분들과도 공유하고 싶어서 “부트캠프에서 공부하는 당신을 위한 편지”라는 글을 써보려고 해요.
이 글은 제 자신에게 다시 채찍질하는 편지이기도 합니다 😇😇😇😇
TL;DR;
- 모르는 건 모른다고 하고, 이해한 척 넘어가지 말자
- 에러를 많이 만난 만큼 성장한다
- 디버깅 방법을 물어보자
- 신뢰할 수 있는 출처는 공식 문서다
- 알게 된 것은 동료와 공유하자
- 포트폴리오는 많은 기능이 아닌 적합하고 좋은 코드로 작성되었는지가 중요하다
- 왜 그 기술스택을 선택했는지 기록하자
- 지원하지 않으면 합격률은 0%이다모르는 건 모른다고 하고, 이해한 척 넘어가지 말자
제 이야기를 조금 해볼게요. 제가 처음 부트캠프에서 자바스크립트를 배울 때, 저는 타입이 무엇인지도 제대로 인지하지 못했고 반복문도 제대로 쓰지 못해서 혼자서 멍청한 나를 탓하면서 엉엉 울면서 공부했습니다.
근데 모르겠는 부분 그 한 고비를 넘기니, 다른 부분을 이해하는 속도가 빨라지더라고요. 그 한 고비를 넘기 위해, 부트캠프 동기들에게 계속 물어보고, 건너건너 아는 개발자에게 DM으로 연락드려서 물어보기도 했어요. 진짜 딱 그 한 고비를 넘기 위해 모르는 건 모른다고 스스로 인정하고, 질문을 시작해보면 어떨까요?
‘나는 모르는 건 모른다고 하는데?’ 라고 생각하실 수 있어요. 지금보다 더 많이 주니어 시절에 ‘OOO 라이브러리 써보신 적 있으세요?’라고 질문을 받으면, TODO 리스트 정도는 만들어봤거나, 사이드프로젝트 때 조금 깔짝여봤으니까 ‘네, 써본 적 있어요’라고 대답했는데, 지금은 ‘아니오, 사이드 프로젝트 정도로는 써봐서 약간 경험만 해본 정도이지 잘 아는 수준은 아니에요’라고 대답하는 빈도가 더 늘어난 거 같아요. 써봤다고 말하는 건 정말 회사 제품개발할 때 써봤고, 다른 라이브러리와 비교가 가능한 수준으로 공부했을 때 써봤다고 말할 수 있는 것 같아요.
👤: OOO 라이브러리 써보신 적 있으세요?
👩🏻💻(과거의 나): 네, 써본 적 있어요 (사이드 프로젝트에서)
👩🏻💻(현재의 나): 아니오, 사이드 프로젝트 정도에서만 써봐서 잘 몰라요.
보통 이렇게 말하면, 그 라이브러리에 대해 잘 아시는 분이 쭉~ 한 번 설명을 해주시기도 해요. 제가 잘 모른다고 말을 했으니까요. 그러면 그걸 들으면 제가 모르는 게 확실히 맞았구나!라고 다시 한 번 더 배우게 됩니다. 벼는 익을 수록 고개를 숙인다라는 말이 괜히 있는 게 아니더라고요.
에러를 많이 만난 만큼 성장한다
예전에는, 뭐만 하면 에러를 만나는 제가 싫더라고요. 하필 또 에러는 빨간색으로 뜨는 경우가 많잖아요? 🥹
제가 부트캠프에서 React를 배우는 첫 시간이었던 것 같아요. 그 때 저의 하루를 다 잡아먹었던 첫 이슈는 부모 컴포넌트 안에서 선언한 상태값을 자식 컴포넌트에서 어떻게 setState를 할 수 있지?라는 간단한 이슈였습니다. props로 setState를 하는 함수를 전달해서 호출하면 되는 무척이나 간단한 방법을 몰랐거든요. React에서 상태가 단방향으로 흘러간다는 원리를 알면 쉽게 풀 수 있는 문제인데, 그걸 깨달으면서 또 한 번 성장했습니다.
하나 더 경험을 이야기해보자면, webpack을 제가 직접 설정해보고 싶어서 도전한 적이 있었는데, 그 때 정말 많은 빨간색 에러를 만났어요. 문서대로 잘 한 것 같은데 npm run build를 실행하면, 빌드를 못하겠다고 뭐라뭐라 에러메시지가 뜨니까 답답하고 짜증나고 절망적이고, 고작 라이브러리 하나 잘 못다루는 제가 싫어지더라고요. 많은 에러를 만났던 이유는 webpack이 번들러라는 사실을 제대로 이해하지 못한 상태에서 설정파일을 냅다 쓰려고 하니, 번들러가 친절하게 이 경로에서 어떤 파일 때문에 번들을 하지 못했다고 알려주는 걸 이해하지 못했던 거죠.
저는 지금도 정말 많은 에러를 만나고 있어요. “이게 왜 안되지…”하면서 여러 번 시도해도 안되면, 동료들과 몹프로그래밍(mob programming) 을 합니다.
에러를 만나면 괴로우실 거에요. 하지만 의미 없는 삽질은 없습니다! 여러분이 에러를 해결하기 위해 시간이라는 값을 지불하고 얻게 되실 성장은 엄청날 겁니다! 에러를 많이 만나려면? 당연히 개발을 많이 해봐야겠죠!
디버깅 방법을 물어보자
지금의 문제만 해결되면 마음이 평안해질 것 같을 때가 있어요. 그런데 아마도 그렇게 한 번 그냥 넘어가게 되면 나중에 본인의 발목을 붙잡을 수 있고, 기출변형 문제가 나오면 못풀게 될 거에요.
한 가지 문제를 너무 오래 붙잡고 있어도 좋지 않지만, 결과만 알고 넘어가는 것은 좋지 못한 성장을 이룹니다. 더 많이 성장할 수 있는 기회를 놓칠 수 있어요.
나의 빠른 성장을 위해서는 누군가의 경험을 얻어야 합니다. 그래서 시니어가 있는 회사에 들어가고 싶은 욕구가 있을 수 있고, 여러 명의 개발자가 있는 회사로 가고 싶을 수도 있어요. 그러기 위해서는 디버깅 방법을 꼭 물어보시면 좋습니다. “이거 어떻게 디버깅 하셨어요?”라고요!
어떤 문제가 있을 때 OO 라이브러리를 쓰면 쉽게 해결될 수도 있고, 지금 어떤 코드 한 줄만 넣으면 이슈가 해결될 수도 있어요. 근데 그게 정말 최선의 방법일까요? 정말 해결한 걸까요?
물고기를 잡았다는 게 중요하지 않고, 어떻게 물고기를 잡았는지를 알아야 다음에 또 잡을 수 있다고 생각해요.
이게 좋은 이야기인지 누구나 다 알겠지만, 사실 디버깅 방법을 물어볼 수 없는 경우도 많아요. 부트캠프에서 공부하면 주변 동료들도 다 똑같이 모르는 상황일 수 있거든요 😇
멘토를 구하실 수 있다면 멘토를 구하는 게 가장 좋고, 그러기 어려운 상황이라면 stackoverflow에 질문을 올리는 방법도 있고, 저 같은 경우에는 구글링하면서 비슷한 디버깅을 해본 사람이 있으면 그 글에 댓글로 질문을 던졌고, 현업에 있는 사람을 수소문해서 연락해서 DM으로 여쭤보거나, 직접 찾아가서 만나서 여쭤봤었어요. 요즘에는 유튜브에도 정말 좋은 영상이 많은 것 같아요.
신뢰할 수 있는 출처는 공식 문서다
저도 여전히 구글링을 많이 합니다. 모르는 것이 여전히 있고, 베스트 프랙티스를 찾기 위해 어느 정도 시간을 할애하고 있어요.
하지만 부트캠프에서 공부하는 여러분들이 제대로 잘 성장하기 위해서는 신뢰할 수 있는 출처는 공식 문서라는 사실을 기억하시면 좋을 것 같아요. 많은 개발자들이 기술 블로그를 작성하고 있어요. 공부한 것들을 기록하고, 자신의 경험을 공유하기 위해서요.
하지만 개발 트렌드는 빠르게 바뀌고 있고, 라이브러리의 버전들은 올라가고 있습니다. 찾아보신 블로그 글은 최신 버전에 대한 정보가 아닐 수도 있고, 해당 기술(또는 라이브러리)에서 권장하는 방식이 아닐 수도 있어요.
처음 문서를 읽어보려고하면, 무슨 말인지 도통 알기 어려울 수 있어요. 그럴 때는 한글로 된 블로그글에서 힌트를 얻고, 영어로 된 블로그글에서 예시 코드를 살펴보면서 감을 익힌 후에 문서를 읽어보시길 권합니다. 가급적 최근에 작성된 글들을 읽으시는 것이 도움되실 거에요. 특정 라이브러리들은 버전이 올라가면서 이전 버전들과는 완전하게 달라지는 breaking changes가 있을 수 있거든요.
특정 이슈에 대해서 공부하는 중에 문서에 내용이 빈약하다면, 그 오픈소스의 github으로 들어가서 issue 탭에서 글을 검색해봐도 좋아요. 메인테이너나 컨트리뷰터가 관련해서 답변을 달아놓은 경우가 있고, 로드맵을 가지고 있는 라이브러리의 경우에는 향후에 어떤 기능이 추가될 것인지가 기재되어 있거든요. 가장 확실하고 신뢰할 수 있는 정보인거죠!
알게 된 것은 동료와 공유하자
취업시장에 야심차게 뛰어들었을 때 여러분들과 경쟁관계를 이루게 될 사람들은 다양한 부류입니다.
- 다른 부트캠프의 수료생들
- 1~2년 사이의 실무경력을 쌓았는데, 더 좋은 또는 나은 처우를 받을 수 있는 회사로 이직하려는 중고(?) 신입들
- 전공자/유사계열 전공자이고, 개발자로 취업을 하려는 졸업생들
- N년차 이상의 경력직이라고 불리울만한 경력 개발자
- 다른 직무 현업 개발자인데, 직무를 바꿔보려는 개발자
개발자 모집공고를 내면 신입도 지원을 하고, 경력자도 지원을 합니다. n년차 이상을 우대한다라고 써있어도 신입들도 지원을 합니다. 회사 안에서는 칼 같지는 않아도 목표 채용인원을 어느 정도 마음에 두고 있기 때문에, 여러분들이 경쟁할 부류는 상당히 다양합니다.
취업이 목표여서 부트캠프에서 공부를 시작했는데, 어떤 친구는 정말 괴물 같이 잘하는데, 나는 그지 같다면(?) 내가 알게 된 것을 그 잘하는 친구에게는 공유하고 싶지 않을 수도 있는데요. 그 작은 세상에서 만난 사람들과 경쟁관계를 유지하시기에는 자신의 성장 속도가 저해될 수 있습니다.
서로 알게 된 것은 공유하며, 같이 성장하는 것이 윈윈하는 길이에요. 현업에 있는 많은 개발자들도 스터디를 합니다. 서로 아는 것을 공유하고, 서로의 시간을 아끼고, 지속적으로 공부하고 있어요.
포트폴리오는 많은 기능이 아닌 적합하고 좋은 코드로 작성되었는지가 중요하다
마음이 조급해지면 나타나는 부작용 중 하나는 포트폴리오에 최대한 많은 기능을 넣고 싶어진다는 것입니다.
많은 기능이 담겼고, 심지어 좋은 코드로 작성되었다면 뛰어난 개발자로 당연히 인정해야 합니다. 그런데 부트캠프에서 공부하는 수강생들의 현실은 (저도 그랬지만) 아직 나의 배움은 짧다고 느껴지는데 무언갈 만들어 내야만하니 마음이 조급해질 수 밖에 없을 거에요.
마음이 조급해지면 나타나는 부작용 중 하나는 포트폴리오에 최대한 많은 기능을 넣고 싶어진다는 것입니다. 많이 넣으면 있어 보이는 포트폴리오가 될 것 같고, 면접에서 나를 빛나게 해줄 것 같으니 이 부작용을 많은 사람들이 겪죠 🤓
100개의 기능이 있는 앱을 만든 사람과 React 라이브러리에 bugfix로 컨트리뷰터 경험이 있는 사람이 있을 때, 여러분은 어떤 사람에게 좀 더 관심이 가실 것 같나요? 저는 후자에 관심이 가요.
물론 100개의 기능을 만드는 것은 엄청난 것이고, 그 코드가 우아한 코드라면 당연히 전자에 관심이 갈 것 같아요. 하지만 제가 생각하기에는 회사에서는 보통은 한 번에 작은 단위의 피쳐(기능)를 만들기 때문에, 그 작은 피쳐 하나를 잘 만들 사람을 뽑고 싶고, 그런 경험을 가진 사람을 선호할 것 같아요. 그래서 후자의 사람에게 좀 더 관심이 갈 것 같습니다. 코드 퀄리티를 기대해볼 수 있을 것 같거든요.
무엇보다 코드퀄리티가 중요하고, 많은 기능보다 완성도가 중요합니다. 꼭 우리 프로젝트에 필요한 기능일지 검토해보실 때에는, 그 기능이 정말 이 프로젝트의 주제에 필요한 기능인지 그리고 그 기능을 넣음으로써 우리가 어떤 기술적 역량을 뽐낼 수 있을지 생각해보셨으면 좋겠습니다.
왜 그 기술스택을 선택했는지 기록하자
왜 그 기술스택을 선택했나요? 라는 질문을 받으면, ‘사람들이 많이 써서요’라는 답변은 틀린 이야기는 아닌데 조금 아쉬움이 남는 것 같아요.
제가 부트캠프에서 공부하는 기간 중에는 아직 생각(?)을 할 수 없는 단계였던 것 같아요. 그런 것을 생각해야하는지도 모르고 살았던 것 같아요. 하지만 많은 회사에서 채용과정에서 기술 스택의 선택 이유를 질문할거에요. 여러분은 어떻게 답변하실건가요?
멘티분들에게 제가 어떤 기술스택/라이브러리를 선택하는 이유를 한 번 말씀드린 적이 있는데, ‘사람들이 많이 쓴다’라는 것은 제가 그 기술을 선택한 이유 중 하나일 뿐이에요.
예를 들어서 제 생각으로는, 우리 서비스가 SEO가 꼭 필요한 서비스이고, Open Graph 태그가 여러 경우로 표현될 수 있어야 한다면, SSR이나 SSG의 방식이 적합할 수 있다고 판단해볼 수 있고, 그 방식을 구현하기 위한 몇 가지의 기술스택 후보를 선정한 뒤, 여러 가지를 비교해서 최종적으로 A라는 프레임워크(또는 라이브러리)를 선택하는 의식의 흐름이 좀 더 자연스러운 기술스택의 선택과정일 것 같아요. 비교를 하기 위해 여러 라이브러리를 직접 사용해볼 것 같고요. 그 후보들을 비교하는 과정 중 참고해볼만한 사항 중 하나가 사람들이 많이 쓰는지일 것 같아요. 커뮤니티가 크다는 것은 관련된 생태계가 잘 갖춰져있을 수 있고, 유지보수가 잘 이루어질 수 있으니까요.
사람들이 많이 써도 내가 만드려는 서비스/기능에 하나씩 안맞는 부분이 있을 수도 있어요. 그럴 땐 내가 직접 구현을 할지, 특정 라이브러리를 가지고 와서 랩핑해서 사용을 할 것인지, 기능 구현을 포기할지(?) 고민하는 과정을 거치게 되겠죠.
부트캠프에서 일단 그 스택을 가르쳐주니까, 아는 게 아직은 이것밖에 없다보니까, 나에게 선택권이 별로 없을 수도 있습니다. 😇
하지만, 이제 이 글을 읽은 후에는 작은 라이브러리 하나를 설치할 때 한 번 고민을 해보실 수 있지 않을까요? 상태관리 라이브러리로 Redux가 정말 최선일까요? recoil, zustand, mobx, react 에서 제공해주는 context API 등등 다양한 후보가 있는데, 정말 Redux가 최선일까요?
지원하지 않으면 합격률은 0%이다
제가 서울대에 가지 못한 이유는 지원을 안했기 때문이라 생각합니다 🥹
대학원서를 접수하는 것과는 다르게, 회사에 지원하는 것은 개수 제한도 없습니다. 지원하지 않으면 합격률은 0%입니다.
그런데 불합격이 두려워서, 불합격하면 다시 재지원했을 때 불이익이 있을까봐 지원을 하지 않는 경우가 많은 것 같아요. 많은 회사가 불합격 후 재지원을 하기까지 쿨타임(3~6개월 정도 응시를 못하는 기간)이 존재하기 때문에 한 번의 지원이 매우 소중하게 생각되는 점은 충분히 이해하고 있어요. 혹시라도 가고 싶은 회사에 탈락했다면, 성장한 뒤에 다시 지원하면 됩니다. 성장하지 않은 상태로 로또 당첨되면 좋겠다는 마음으로 계속 지원하는 것은 역효과가 날 것 같아요.
부트캠프에서 수료를 앞두고 계신 분들이 이 글을 읽으신다면 드리고 싶은 말씀이 있어요. 정말 가고 싶은 회사다면 그 회사를 내가 면접볼 회사들 중 마지막 그룹에 배치하는 것도 좋은 방법이에요. 혹시라도 지원하기엔 아직은 준비가 너무 안된 것 같이 느껴진다면, 그 회사에서 진행하는 행사가 있다면 참여해보고, 그 회사에 근무하는 개발자를 링크드인 같은 곳에서 수소문해서 어느 정도의 기술역량을 가진 사람을 선호하는지 물어보는 것도 좋을 것 같아요.
채용공고를 볼 때는 다 뽑을 것 같지만, 신입을 뽑을 여력이 되는 회사도 있고, 여러 사정상 신입이 아닌 경력을 선호하는 회사도 있어요. 직접 질문을 하는 방법은 이런 소소한 정보도 얻을 수 있을 거라서 저는 링크드인을 최대한 활용해보시는 방법을 추천합니다 👍
마치며
무조건 주눅들 필요도 없고, 근본 없이 자신감을 가지셔도 곤란합니다.
당연해보이는 이야기이고, 사실 생각하면 누구나 알 수 있는 내용을 적은 것 같아서 조금은 걱정이지만, 부트캠프에서 공부 중인 분에게 조금이라도 도움이되셨으면 하는 마음입니다.
취업/이직 시장에서는 여러분도 저의 경쟁자이지만 🤓 좋은 경험을 서로 나누고 같이 성장하고 싶습니다. 같이 일할 수 있다면 더 좋고요!
결국에는 모두가 원하는 만큼 성장하는 개발자가 되길 바라겠습니다.
읽어주셔서 감사합니다!
