4  주니어 개발자

먼저, 새로운 삶에 오신 것을 환영합니다! 질문하십시오! 어떤 기술적인 질문이든 편하게 물어볼 수 있는 직장 동료를 찾으십시오. 질문한다는 이유로 누구도 여러분을 기분 나쁘게 만들도록 내버려 두지 마십시오. 멍청한 질문이란 없습니다. 많이 질문하십시오. 다이어그램을 그리십시오. 코드를 읽으십시오. 여러분의 가정을 다시 점검하십시오. 숨을 돌리십시오. — Scott Hanselman

유해한 직장을 제외하면, 주니어나 신입 개발자를 알고서 채용하는 대부분의 고용주는 자신이 무엇을 감수하는지 잘 알고 있습니다. 바로 여러분이 새 직장에서 성공하는 데 필요한 모든 교육과 지원을 제공하는 것입니다! 사실, (드물지만) 일부 고용주는 오히려 주니어 채용을 선호하기도 합니다. 주니어는 선입견이 없고 그들의 방법론에 맞게 길러질 수 있기 때문입니다.

4.1 자신만의 리듬 찾기

주니어 개발자로서 여러분의 일은 역량과 실행력을 기르는 것입니다. 항상 답을 갖고 있는 것보다 좋은 질문을 하는 것이 더 중요합니다. 시간이 지나면 고용주가 믿고 의지하는, 충분한 근거를 갖춘 의견을 낼 수 있게 될 것입니다.

지금은 아무것도 몰라도 되는 시기입니다. 1년 뒤에 묻는 것보다 지금 묻는 편이 낫습니다. “모르겠습니다”나 “무슨 뜻인지 좀 더 자세히 설명해 주시겠습니까?”라는 말을 자주 하십시오. “제 방문은 언제나 열려 있습니다”라는 말을 문자 그대로 받아들이십시오. 호기심을 마음껏 따르십시오. 똑똑하게 질문하십시오. 그들은 여러분을 가르쳐야만 합니다. 실제로 일부 시니어 개발자는 무언가를 쉽게 설명하는 능력과 주니어를 멘토링하는 능력으로 평가받습니다. 배운 것을 마음 깊이 새기는 것으로 그 호의에 보답하십시오.

무지를 힘으로 바꾸는 더 많은 방법은 램프셰이딩(장 34)을 참고하십시오!

도움을 구하는 강력하면서도 은근한 방법은 멘토나 동료에게 페어 프로그래밍을 하자고 요청하는 것입니다. 처음에는 어색하게 느껴질 수도 있지만, 동료가 문제를 해결하는 방식을 가까이에서 지켜보면 언제나 미묘한 요령과 비법을 배울 수 있고, 동료는 여러분이 어디에서 실수하는지 파악하여 보통 코드 리뷰에서 얻을 수 있는 것보다 더 많은 맥락을 알려줄 수 있습니다. 삼투 작용처럼 자연스럽게 스며드는 지식 전달은 놀라울 만큼 강력하고 생산적입니다. 이 관행은 매우 유익하기 때문에 일부 회사(Pivotal 등)는 익스트림 프로그래밍 실천법의 일환으로 항상 페어 프로그래밍을 하는 정책을 채택하기도 했습니다. Google 최고의 엔지니어 두 사람인 Jeff Dean과 Sanjay Ghemawat은 DEC 시절부터 MapReduce와 TensorFlow를 만들기까지 줄곧 페어로 일했습니다. 그렇게까지 할 필요는 없지만, 일반적으로 대부분의 주니어 개발자는 동료와 “페어링”하면서 엄청난 도움을 받으므로, 아직 회사에서 이를 일상적인 관행으로 삼고 있지 않다면 페어 세션을 요청하십시오.

동료들이 어떻게 생각하고 일하는지 잘 파악하게 되면, 실제로 머릿속에서 그들을 “에뮬레이트”하기 시작할 수 있습니다. 어떤 작업에 접근할 때 “$COWORKER라면 어떻게 할까?”라고 자문해 볼 수 있습니다. 이전 직장에는 훌륭한 코드 리뷰 피드백 등급 체계가 있었지만, 저는 동료들이 제기할 법한 우려 사항을 염두에 두고 제 코드를 미리 스스로 리뷰함으로써 코드 리뷰의 지연 시간을 더욱 줄일 수 있다는 것을 알게 되었습니다. 팀에서 효과적인 코드 리뷰를 위한 아이디어가 더 필요하다면, Google의 코드 리뷰 가이드라인이 공개되어 있습니다. 경험이 쌓일수록 예전에 했던 작업도 다시 검토해야 하며, 미래의 자신을 위한 가독성과 확장성을 고려해 코드에 주석을 달고, 문서화하고, 설계하는 방식을 어떻게 더 개선할 수 있을지 생각해 보아야 합니다.

문제 해결 능력을 기르십시오. 그리고 우리 모두 지금의 여러분처럼 고생했다는 것을 이해하십시오. 시간을 내어 디버거 사용법을 익히십시오. 디버거는 새롭거나, 문서화되지 않았거나, 문서화가 부실한 코드베이스를 탐색할 때나 이상한 문제를 디버깅할 때 꽤 유용합니다. Stack Overflow나 GitHub 이슈에서 답을 찾지 못하더라도 포기하지 마십시오. 때로는 잠깐 휴식을 취하거나 고무 오리에게 문제를 설명해 보는 것만으로도 문제를 해결할 수 있습니다!

상대가 여러분을 도울 수 있도록 돕는 법을 이해하십시오. 리드에게 “막혔습니다. 하지만 X, Y, Z를 시도해 보았습니다. 혹시 조언해 주실 만한 것이 있을까요?”라고 말하는 것이 “이건 제 능력 밖입니다.”라고 말하는 것보다 훨씬 낫습니다. 이슈나 버그 리포트를 작성할 때는 좋은 제목을 쓰고, 핵심 정보를 먼저 제시하고, 오류 메시지와 환경/패키지 버전을 묻기 전에 포함하고, 이슈의 최소 재현 사례를 제공하고, 무엇을 시도했고 무엇을 기대했는지 설명함으로써 상대가 여러분을 도울 수 있도록 도우십시오. 스크린숏 한 장이 천 마디 말을 대신한다면, GIF를 녹화하거나 짧은 설명 영상을 만드는 것은 그보다 훨씬 많은 것을 전달할 수 있습니다. 더 자세한 내용은 “좋은 질문은 어떻게 하나요?”에 관한 StackOverflow의 가이드를 참고하십시오.

어떤 개발자들은 정반대의 문제에 빠집니다. 자신감이 부족한 것이 아니라 자신감이 지나치게 많은 것입니다. 더닝-크루거 효과는 실재합니다. 자신이 모른다는 사실조차 모르는 것이 있다는 점을 기억하십시오. 새로 들어와서 이전 사람들은 모두 바보였고, 모든 것이 용납할 수 없는 기술 부채이며, 이론상으로는 자신이 모든 것을 고칠 수 있다고 느끼기 쉽습니다. 체스터턴의 울타리는 이해하지 못하는 것과 마주쳤을 때 먼저 그 이면의 이유를 이해해야 한다는 점을 일깨워 줍니다. 자신의 코드와 사랑에 빠지지 마십시오. 자신의 해결책과 사랑에 빠지지 마십시오. Clean Code를 읽고 모든 것에 적용하고 싶어질 수도 있지만, 결국 그것이 실제 세계에서는 도움이 되지 않는다는 사실을 깨닫게 될 것입니다.

여러분은 선배 동료들에게서 많은 것을 배워야 하지만, 동시에 그들도 틀릴 수 있다는 것을 이해해야 합니다. 예전에 한 상사가 제게 “React는 클래스를 사용하니까 객체 지향이다”라고 말한 적이 있는데, 그때 저는 그가 React를 얼마나 잘못 이해하고 있는지 깨달았습니다. 이 혼란스러운 초기 시기를 헤쳐 나가려면 판단력과 이해력, 그리고 설득력을 길러야 합니다.

4.2 실수하기

당신은 반드시 크게 실수하게 됩니다. 실수를 할지 말지가 아니라 언제 하느냐의 문제입니다. 괜찮습니다. 살아남을 수 있습니다. 우리 모두 그런 경험이 있습니다.

실수를 절대 하지 않는 것이 여러분의 일은 아닙니다. 여러분이 저지르는 어떤 실수에서든 여러분과 회사가 모두 회복할 수 있도록 하는 것은 여러분의 선배와 관리자가 할 일입니다. 한 주니어 소프트웨어 개발자는 실수로 출근 첫날 회사의 프로덕션 데이터베이스를 날려 버렸고, CTO로부터 법적 책임을 묻게 될 것이라는 말을 들었습니다. 비슷한 장애를 일으킨 적이 있는 사람들이 남긴 이야기와 모든 답글을 읽어 보십시오. 그들은 모두 살아남아 그 이야기를 전하고 있습니다.

시니어 개발자들이 저지른 실수를 몇 가지만 꼽아 보면 다음과 같습니다:

괜찮습니다. 당신은 살아남을 것입니다.

“실수하는 것은 인간이지만, 일을 제대로 망치려면 컴퓨터가 필요합니다.” - Bill Vaughan

4.3 가치 더하기

기본적인 책임을 잘 해내고 있다면, 여러분에게 주어지는 일이 무엇이든 수락하는 편이 좋습니다. 감당할 수 있는 것보다 많은 일을 떠안게 되면, 여러분을 도와주거나 일이 잘못되어 갈 때 개입하는 것은 매니저나 팀의 책임입니다. 동시에, 맡기로 한 일은 반드시 잘 해내십시오. 결국 여러분의 퍼스널 브랜드는 여러분이 하는 일 그 자체입니다.

안전지대를 벗어나는 일을 하는 것이 두렵게 느껴질 수도 있지만, 성장하려면 그런 일에 능숙해져야 합니다. “이것이 제가 하는 일입니다”라고 말하며 가면 증후군에 맞서십시오.

일을 만들어 내는 사람이 아니라 일을 흡수하는 사람이 되도록 노력하십시오. 관리자와 프로덕트 오너에게 그들이 맡은 일 중 무엇을 덜어 줄 수 있는지 먼저 나서서 물어보십시오. 여러분의 일은 그들을 지원하는 것입니다. 그들이 좋아 보이면 여러분도 좋아 보입니다. 라이언 홀리데이는 이를 캔버스 전략이라고 부르며, 해리 트루먼은 이를 더 간결하게 표현합니다. “공을 누가 차지하든 신경 쓰지 않는다면 놀라울 만큼 많은 것을 이룰 수 있습니다.” 물론 이용당하고 있다고 느낀다면 그만두십시오.

할 일이 떨어졌을 때 그냥 기다리기만 하면 게으르고 의욕이 없어 보입니다. 주도적으로 움직이십시오. 할 일은 언제나 더 있습니다.

아무도 하고 싶어 하지 않는 일을 하는 것이 결국 여러분을 없어서는 안 될 사람으로 만들어 주는 경우가 꽤 많습니다. A) 그 일은 반드시 해야 하는 일이고, B) 아무도 그 일을 하고 싶어 하지 않기 때문입니다. 그 일을 하는 영리한 방법을 찾아낸다면, 그것으로 커리어를 쌓거나 (스타트업을 차릴) 수도 있습니다!

중요한 주의 사항: 다른 사람들이 여러분을 이용하도록 내버려 두지 마십시오. 가능하다면 프로젝트를 전략적으로 고르고(전략 섹션 참고), 성과를 거두었을 때는 내부와 외부 모두에 자신을 알리십시오.

테스트는 이것의 가장 흔한 예입니다. 실제로 새 직장에서 시작하는 정말 좋은 방법은 테스트 작성을 자원하는 것입니다:

  • 테스트는 아무리 많아도 충분하지 않습니다. 테스트할 것은 언제나 더 있고, 테스트를 더 빠르게 만들 수도 있으며, 도움이 되지 않는 테스트를 제거하거나 교체할 수도 있습니다.
  • 동료들이 고마워할 것입니다. 테스트는 사용자에게 드러나지 않기 때문에 대충 넘어가기 쉬운 부분이지만, 테스트의 가치는 누구나 알고 있습니다.
  • 코드베이스를 익히십시오. 코드를 테스트하려면 코드의 어느 부분을 테스트해야 하는지 이해해야 합니다. 이것은 과학이 아니라 예술입니다 - 코드베이스 전체를 단위 테스트로 뒤덮으면 피상적인 코드 커버리지는 많이 얻겠지만, 사소한 세부 사항 하나만 바뀌어도 리팩터링할 것이 많아지고, 프레임워크 테스트도 상당 부분 중복하게 됩니다. 널리 통용되는 조언은 “테스트를 작성하십시오. 너무 많이는 말고요. 대부분은 통합 테스트로.”입니다. 이는 마이클 폴란의 유명한 인용구를 본뜬 것입니다.
  • 무엇도 망가뜨릴 수 없습니다. 오히려 정반대로, 테스트는 코드를 더 견고하게 만듭니다!
  • 제품이 어떻게 작동하는지에 대해 몰랐던 것들을 배우게 됩니다. 제품을 사용할 때는 여러분 같은 사용자가 보는 것만 보게 됩니다. 코드를 들여다보면 처리되고 있는 온갖 엣지 케이스와, 그것을 가능하게 만든 지저분하고 땜질식인 코드까지 모두 보게 됩니다!

사람들은 Netflix, Ionic, PayTM 등에서 이 전략을 활용해 회사 생활을 훌륭하게 시작했으며, 여러분도 그렇게 해야 합니다.

여러분의 코드는 여러분이 일하는 비즈니스의 맥락 안에서만 가치를 가집니다. 최종 사용자의 입장에서 제품을 처음부터 끝까지 이해하십시오. 함부로 짐작하지 말고, 의문이 들 때는 질문을 해서 확실하게 정리하십시오.

원하는 것을 요청하십시오. 회사의 전략적 우선순위를 더 잘 알게 되고, 여기에 더해 자신이 무엇을 선호하고 무엇에 뛰어난지 스스로 더 잘 알게 되면, 프로젝트를 선택할 때 수동적인 태도에서 능동적인 태도로 나아가기 시작할 수 있습니다. 지금 하고 있는 일이 앞으로의 커리어가 될 필요는 없으며, 구직자로서 방향을 바꾸는 것보다 회사 내부에서 초점을 바꾸는 편이 훨씬 쉽습니다. 회사의 다른 개발자들이 어떻게 일하는지 이해할 수 있도록 다른 직무를 접할 기회를 적극적으로 찾고, 회사에 큰 영향을 미칠 핵심 프로젝트에 참여할 수 있는 자리에 자신을 두십시오. 매니저와의 1:1 면담에서 활용할 수 있는 다른 커리어 개발 질문을 몇 가지 소개합니다.

4.4 지식 넓히기

첫 직장을 구했다고 해서 배움을 멈추는 것은 아닙니다. 이전에 시작했지만 끝내지 못했던 모든 공부를 계속 이어 가야 합니다! 이제 어느 정도 경제적 안정을 얻었으니, 지식의 빈틈을 메울 시간적 여유가 생겼습니다.

  • 기술 서적은 처음부터 끝까지 읽으십시오. 트윗과 내용 없는 블로그 글이 넘쳐나는 세상에서, 책은 진지한 기술 논의가 메마른 사막 속 전문 지식의 오아시스입니다. 튜토리얼을 끝없이 하나씩 따라가기만 하는 “튜토리얼 함정”을 조심하십시오. 중요한 몇 가지를 깊이 파고드십시오. CS 지식의 빈틈을 메우고 싶다면, 컴파일러부터 람다 대수까지 모든 것을 다루는 The Imposter’s Handbook을 구하거나 TeachYourselfCS를 살펴보십시오.
  • 프레임워크/라이브러리 소스 코드를 읽으십시오. 전문가의 코드를 여러분의 코드와 비교해 보면 많은 것을 배울 수 있습니다 - 튜토리얼에서 일반적으로 가르치는 방식과 의도적으로 다르게 작성된 부분을 찾아보고, 왜 그렇게 했는지 질문해 보십시오.
  • 더 많은 언어와 프레임워크를 배우십시오. 기술에 베팅하기를 배울 때는 노출 요법이 효과가 있습니다! (장 24)
  • 사용하는 모든 도구의 지적 역사를 배우십시오. 그 이전에는 무엇이 있었습니까? 무엇이 그 도구들을 탄생시켰습니까? 누가 그 도구들을 만들었습니까? 그들은 지금 무엇을 하고 있습니까? 도구를 알라(장 11).
  • 사실, 프로젝트보다 사람을 팔로우하기 시작하십시오. 그들의 과거와 멘토를 추적하십시오. 그들은 오늘 무엇을 작업하고 있습니까? 그들이 내려놓은 것을 집어 드십시오(장 19).
  • 유용한 사이드 프로젝트(장 37)를 계속 만드십시오.

모든 것을 외우려 하지 말고, 모든 것을 머릿속에 담아 둘 수 있다고 믿지도 마십시오. 치트시트와 저장소와 블로그 글을 만들기 시작하여 지식을 오픈 소스하십시오(장 13).

무언가를 정말로 배웠는지는 배운 것을 가르칠 수 있을 때 비로소 알 수 있습니다. 글을 쓰고 말하는 과정에서 안다고 생각했지만 실제로는 몰랐던 것들을 발견하게 될 뿐 아니라, 특정 주제에 관해 아는 모든 것을 담은 유용한 자료를 한데 모으게 되며, 이 자료는 나중에 다시 꺼내 볼 수 있습니다(그리고 실제로 꺼내 보게 될 것입니다!).

배운 것을 가르치는 방법은 다음과 같습니다:

  • 발표하십시오. 직장에서, 밋업에서, 가족에게, 반려견에게, 자신의 YouTube 채널에서 스스로에게라도 하십시오. 당신이 내향적이라는 것은 상관없습니다. 저도 그렇습니다. 개발자의 90%도 그렇습니다(실제 수치는 모르지만, 아주 많습니다). 남은 경력 내내 기술에 관한 공개 발표를 피할 수 있다고 생각하십니까? 그것이 언젠가는 쉬워질 것이라고 생각하십니까? 하루 종일 혼자 틀어박혀 있으면 더 빨리 배울 것이라고 생각하십니까? 발표하십시오. 발표를 하면 직접 위험을 감수하고 판에 뛰어들 수밖에 없습니다. 그로 인해 겪는 창피함은 일시적일 뿐입니다. 사실 그것은 당신을 더 나아지게 만드는 원동력이 됩니다. 발표를 망칠까 봐 걱정되십니까? 걱정하지 마십시오. 분명히 망칩니다! 누구에게나 어느 정도의 형편없는 발표는 있기 마련입니다. 그런 발표는 나중에(선택의 여지가 없을 때) 하는 것보다 일찍(별로 중요하지 않을 때) 해치워 버리는 편이 낫습니다. 형편없는 발표를 연속으로 10번 하고도 나아지지 않을 수 있는지 한번 해 보십시오. 발표하십시오.
  • 업계 사이트에 기고하기. Dev.to처럼 누구나 글을 올릴 수 있는 커뮤니티 공간에서 시작해도 좋지만, 결국에는 엄선된 글만 싣고 동료 검토를 거치는 업계 사이트에 글을 게재하는 것을 목표로 삼아야 합니다. 프런트엔드 개발자라면 CSS Tricks, Smashing Magazine, A List Apart 같은 곳이 이에 해당합니다. 이러한 기고는 이력서에 올릴 훌륭한 항목이 될 뿐만 아니라, 수준 높은 글 한 편을 완성하는 과정에서 그 무엇과도 비교할 수 없을 만큼 지식(그리고 그에 따라 평판)이 쌓입니다. (장 18에서 돈을 받고 글을 쓰는 방법을 확인하십시오!)
  • 블로그. 블로깅은 허락이 필요 없는 학습의 궁극적인 형태입니다. 자신의 도메인에서 자신이 정한 방식대로 공개적으로 배우기를 실천할 수 있습니다. 브랜드나 분야 전문성을 쌓고 싶다면 특정 주제에 집중해서 글을 쓰십시오. 그러면 사람들이 여러분의 작업을 알아보고 새 글을 받아 보려고 구독하기 시작할 것입니다.
  • 질문에 답하기. 믿기 어렵겠지만, 여러분은 자신의 관심사와 스스로 던지는 질문에 의해 한계가 정해집니다. 모른다는 사실조차 모르는 것들이 있습니다. 블로그 글 아이디어를 얻고 혼자 배울 때보다 더 빨리 배우는 한 가지 방법은 다른 사람의 질문에 답하는 것입니다. StackOverflow, 트위터, Reddit, 그리고 GitHub 이슈에는 도움을 구하는 사람들이 무수히 많습니다. 질문에 답하는 연습을 하면 질문에 답하는 실력이 늘기도 하지만(키 입력을 아끼십시오! 자주 하는 답변은 블로그 글로 정리해 두십시오!), 동시에 한 번도 던져 볼 생각을 하지 못했던 질문을 발견하게 됩니다. 이런 질문들은 앞으로 하게 될 일에서 마주치는 경우가 많습니다. “인터넷에서 도움이 되는 사람이 되는 것”의 또 다른 이점은 해당 커뮤니티의 메인테이너들에게 눈에 띄어 도움을 달라는 요청을 받게 된다는 것입니다.

“한 사람이 가르치면 두 사람이 배웁니다.” - 로버트 하인라인

이 모든 공개적으로 배우기는 여러분의 인맥을 쌓는 데에도 도움이 됩니다. 인맥에서 얻는 이점은 시간이 지날수록 복리처럼 불어나므로, 일찍 시작하는 편이 좋습니다.

마지막으로, 면접 감각을 계속 날카롭게 유지해야 합니다. 이 직장이 마지막 직장이 아닐 것입니다. 주변을 살펴보고 1년에 한 번은 면접을 보십시오. 대안이 그저 지금 다니는 직장에 남는 것일 때, 네트워킹부터 회사 선택, 협상에 이르기까지 모든 면에서 우위를 점할 수 있습니다.