빠르게 성장하는 슈퍼루키로 거듭나기

11. 빠르게 성장하는 슈퍼루키로 거듭나기

---

  최근 좋은 기회를 얻어 다음주부터 2개월간 인턴으로 출근(재택근무)하게 되었다. 인턴이 되어 가장 좋은 점은 기술적인 어려움에 봉착했을 때 나와 비슷한 일을 겪었을 선배 개발자가 생긴다는 점이다! 이런 좋은 환경의 기회를 놓치지 않고 최대한 성장하기 위해 '빠르게 성장하는 슈퍼루키로 거듭나기'라는 영상을 보게되었다.

 

* 프론트엔드 개발자로 성장하기

[슈퍼루키로 거듭나기위한 3요소]
  1. 환경
  2. 리뷰
  3, 기술(記述)

  위 영상은 슈퍼루키로 거듭나기 위해 3가지 요소를 강조한다. 바로, 환경, 리뷰, 기술이다.

 

1. 환경

프론트엔드 로드맵: https://roadmap.sh/frontend

  프론트엔드 개발자가 알아야할 로드맵을 본 적 있는가? 인터넷의 동작방법부터 빌드 툴까지 알아야할 것이 어마무시하게 많다. 이들을 도장깨기 하듯이 하나하나 마스터하기에는 양도 너무 많고, 개념을 마스터했다는 것 자체가 모호하기 때문에 사실상 불가능하다. 따라서 우리(신입 개발자)는 전체를 훑으며 기초를 다지고 각각의 깊이를 더해나가는 전략을 취하는 것이 더 유효한 방법이 된다.

 

  자연스럽게 기술의 전체를 훑을 수 있는 방법은 무엇일까? 바로 평소에 다양한 키워드들을 주워듣고 킵하여 나만의 DB를 만드는 것이다. 예를 들어 개발 문서, 주간 회의 혹은 선배들과의 대화에서 처음 듣는 용어들이 있을 것이다. 이러한 단어들을 일단 기록해놓는 것이다. 단어를 기록할 때 무엇에 관련된 개념인지, 어떤 맥락에서 등장했는지, 이를 알기위해 무엇을 찾아봐야할지 정도를 함께 적는다. 그 후에 해당 키워드와 관련된 실전 문제에 맞부딪치게 되었을 때 해당 기록을 이용하여 심화지식까지 마스터한다.

 

  이러한 방식을 취하는 이유는 사람은 문제에 봉착했을 때 간절해지기 때문이다. 평소에 어떤 키워드에 대해 공부를 해도 크게 와닿지 경우가 많다. 그러나 내가 당장 실무에서 구현해야하는 것이라면 몰입해서 지식을 공부할 것이다. 따라서 나만의 키워드 DB와 더불어 문제에 봉착할 수 있는 환경에 나를 넣어야할 필요가 있다. 특히, 프론트엔드는 웹 애플리케잉션의 구조설계부터 개발/테스트/빌드, 배포 자동화 도구 까지 전체적인 프로세스를 담당하게 되므로 이러한 전체 프로세스를 경험할 수 있는 환경이 필요하다. 이러한 환경은 평소 나의 담당 프로젝트나 사이드 프로젝트, 해커톤, 공모전이 이에 해당한다.

 

2. 리뷰

[멘토가 있으면 좋은 이유]
  1. 힌트, 가이드라인, 핵심만 알아도 기술에 대한 러닝커브가 감소.
  2. 선배가 개발하는 방법, 생산성을 높이는 방식을 습득가능

  초심자가 방황하는 이유 중 하나는 메타인지의 무재이다. 즉, 내가 뭘 모르는지 모르는 것이다. 이럴 때 나와 비슷한 어려움을 겪었을 멘토를 활용하여 해결할 수 있다. 특히, 코드리뷰를 배움의 장으로 활용하는 것이 좋다.

 

[코드리뷰 목적]
  1. 시나리오 체크, 로직 점검, 버그 가능성 제보, 오타 발견, 코드 규칙 위반 사례 확인 등
  2. 작성된 코드에 대한 더블 체크
  3. 좋은 코드를 보고 배울 수 있는 기회
  4. 작성된 코드에 대해 책임을 함께 진다는 의미
  5. 구현 과정에서 궁금증이나 어려움을 공유할 수 있는 창구

  코드리뷰는 버그, 성능이슈가 발생할만한 코드를 찾아주는 것이 전부는 아니다. 특히 신입은 구현 과정에서 겪는 궁금증이나 어려움을 공유하는 용도로 사용해도 좋다!

 

3. 기록

[TIL 기록이 좋은 이유]
  1. 오늘 알게된 내용을 문서화
  2. 이해에 구멍이 있었던 부분 점검하고 채워 넣기
  3. 난항을 겪고 있는 문제를 정리하기
  4. 꾸준하게 문서화 작성 스킬 향상, 부담 경감
  5. 배움의 시각화를 통한 성취감 획득

  배운 건 기록하고, 기록한 건 공유하는 것이 좋다. 영상에서는 TIL을 추천한다. TIL은 Today I Learned의 약자로 오늘 배운 내용을 문서화하는 것이다. 예를 들어 코드리뷰에서 새롭게 알게 된 개념을 퇴근 전에 TIL로 정리하는 식이다. 

 

  기록을 공유하는 이유는 무엇일까? 글을 쓸 때 혼자 보는 문서보다 오픈된 공간에 다른 사람도 내 문서를 볼 것이라는 가정한 문서를 대하는 자세에는 차이가 생긴다. 예를 들어 팀원들이 내 TIL을 구독한다면, 자연스럽게 좀 더 체계적, 정리된 형태로 글을 쓰게 된다. 더불어 다른 파이팅 넘치는 동료 개발자의 TIL을 구독하다보면 눈높이가 맞는 지식 창구로 사용할 수 있고, 나에게 동기부여가 되기도 한다.

 

  기록은 TIL, 블로깅 뿐만이 아니다. 코딩을 하며 자연스럽게 작성하는 Pull Request 또한 문서이다. PR은 분석과 진단, 의사결정과정, 구현 사례(코드)를 갖춘 완결성있는 문서이다. 따라서 개발 히스토리 & 튜토리얼이 되며, 팀 내에서 두고두고 공유되며 읽히게 된다.

 

기술 소식지: https://github.com/naver/fe-news/
지식 블로그: https://d2.naver.com/
널리 접근성 세미나: https://nuli.navercorp.com/
개발자 컨퍼런스: https://deview.kr/

  여러 기술 공유 채널을 보는 것도 도움이 된다. 1에서 말했던 키워드를 수집할 수 있기도 하다. 

 

 

 

---

 

12. 상반기 네이버 인턴을 돌아보며

---

  추가적으로 위 영상도 살펴보았는데 위 영상에서 도움이 되었던 부분은 다음과 같다.

 

1. Pull Request

  1. 작은 단위로 PR하자
  2. PR 시에 관련 내용을 잘 정리하자

 

2. 코드리뷰

  1. 사소한 코드리뷰로 감정이 상하지 않게 하자.
  2. 버그, 성능이슈가 발생할만한 코드를 찾아주자.
  3. 4번이 어렵다면 클린코드, 코드를 실제로 테스트해서 문제가 없는지 확인해주기 정도도 가능하다.

 

3. 커뮤니케이션

  1. 애매한 용어 사용을 자제하자.
  2. 글로 의견을 전달하게 된다면 너무 딱딱한 표현은 피하자.
  3. 내가 말하고 싶은 내용 보다는 상대방이 궁금해하는 내용을 고민하고 이해하기 쉽게 전달하자.

    ex. 주간회의: 현재 인턴과제가 어떻게 되가니 => 일정 + 구현관련 이슈(상대가 궁금한 것)

 

4. 질문과 이슈 공유하기

  1. 질문에 충분히 고민한 흔적이 드러나도록 하자
  2. 질문을 하기 전에 질문할 내용을 문서화해두면 피드백받기도 쉽고, 내용도 명확해진다.

    - 질문에 대한 배경지식, 문제를 해결하기 위해 생각했던 것들...
  3. 직접 질문하기 어렵다면 고민을 잘 전파해보자

    - 현재 하고 있는 일을 잘 전파하여 피드백을 받자

       ex. Pull Request, 주간회의 때 어떤 어려움이 있는지 고민을 드러내자.

 

5. 테스트 도입

  1. 개발이 진행되고 피드백을 받다보면 기능/로직을 변경할 가능성이 높다.

  2. 인턴 과제는 특히나 초반에 모든 경우의 수를 알아내기 어려움으로 기능/로직이 변경될 가능성이 높다.

  3. 테스트가 있다면 기능을 변경한 후 다른 사이드 이펙트가 없는지 확인하기 한결 수월하다.

  4. 테스트 도입이 부담된다면 단위 테스트만이라도 도입하자.