2장. 역량을 높이는 의식적 노력(경쟁력을 갖춘 개발자가 되기 위해 스스로 해야 할 일)

Posted by yunki kim on January 8, 2024

실전에 앞서 익혀야 할 자기주도 학습 방안

본격적인 학습을 위한 몸풀기

  • 입사 후 첫 몇 달간은 상황이 어떻게 돌아가는지를 파악하는 데 집중하자. 설계 회의, 온콜 교대 업무, 운영 이슈, 코드 리뷰 등에 참여하자.

직접 부딪혀보며 배우자

  • 업무 초반 문서를 읽는 것도 중요하지만 실제 코딩을 하고 결과물을 배포하는 것도 중요하다. 실전에서 배울 수 있는 것이 더 많기 때문이다. 내가 맡은 업무가 어떤 영향을 미칠지 최대한 이해해서 적절한 주의를 기울이자.
  • 실수는 피할 수 없다. 누군가가 실수했을 때 그 실수의 파급력을 완화할 수 있는 안전망을 갖추는 것이 팀과 팀장의 역할이다. 실수를 했을 때 자책하는 대신, 기록하고 정진하자.

코드 동작을 이해하기 위해 다양한 실험을 하자

  • 다양한 시도를 해보면서 코드가 어떻게 동작하는지 알아두자. 문서를 그냥 두면 스스로 최신 내용을 반영하지 못하고, 동료들도 기억해 내지 못하는 것이 있을 수 있다.
  • 디버거를 활용해 실행 중인 코드의 현재 상태를 확인할 수 있다.

문서 읽는 습관은 몸에 배야 한다

  • 매주 일정 시간을 할애해 사내, 사외 자료를 읽는 습관을 들이자
  • 팀 문서, 설계 문서부터 시작해서 대략적인 동작을 이해하자. 트레이드오프, 컨텍스트에 대한 논의에 주의를 기울이자.
  • 코드를 읽자. 코드의 이곳저곳을 보면서 주요 기능에 대해 코드의 흐름과 상태를 다이어그램으로 그려보자.
  • 팀의 코딩 스타일과 용어를 익히자.
  • 할 일은 티켓이나 이슈로 관리하자.
    • 팀에 할당된 티켓을 읽어보면 각자 맡은 일과 앞으로 하게 될 일을 알 수 있다.
    • 백로그에서 신규 입사자에게 적당한 티켓을 찾을 수 있다. 오래된 티켓은 크게 세 부류로 나뉜다.
      • 더 이상 필요하지 않은 사항
      • 해겨ㄹ면 좋지만 그다지 중요하지 않은 사항
      • 지금 당장 해결하기에는 업무 규모가 너무 큰 사항
  • 출간 자료와 온라인 자료는 서로 보안 관계이다
    • 도서, 논문은 지식을 깊게 이해하는 데 도움이 된다. 내용은 신뢰성은 높지만 시의성은 떨어진다.
    • 온라인 자료는 신뢰성은 낮지만 최신 트렌드를 파악하는 데 유용하다.

발표 영상을 찾아서 보자

  • 좋은 발표를 찾아보고 나중에 떠올릴 수 있게 내용을 기록하고 익숙하지 않은 개념이나 용어에 대해 다른 자료도 찾아보자.
  • 회사에서 기술 간담회를 운영한다면 참석해 보자.

때로는 밋업과 컨퍼런스도 참여하자

  • 밋업과 컨퍼런스에 참여하는 것은 네트워크를 구축하고 새로운 아이디어를 접할 수 있는 좋은 방법이다. 다만 너무 잦은 참석은 금물이다. 이런 행사의 신호 대 잡음비(signal-to-noise ratio - 모든 콘텐츠 대비 관련된 콘텐츠의 비율)은 상당히 낮다. 대부분의 발표는 나중에 온라인 영상으로 확인할 수 있다.
  • 컨퍼런스는 다음과 같은 세 가지 종류로 나뉜다
    • 학술 컨퍼런스: 콘텐츠는 좋지만 대부분의 시간을 논문을 읽는 데 사용한다.
    • 관심 주제 컨퍼런스: 실용적인 팁을 얻고 경험 있는 실무자를 만날 수 있다는 점이 매력적이다.
    • 벤더 쇼케이스 컨퍼런스: 기술 대기업의 마케팅 방안으로 활용되며 개발자 학습에는 큰 도움이 되지 않는다.

시니어 엔지니어의 업무를 체험하고 협업하자

  • 체험하기는 다른 사람이 업무를 수행하는 동안 따라다니며 기록하고 질문하는 것을 의미한다.
  • 시니어 엔지니어를 따라다니면서 새로운 스킬을 배우고, 일정 전후에 계획과 회고 시간을 마련한다. 그 후 역할을 바꿔서 시니어 엔지니어가 나를 따라다니게 한다. 시니어 엔지니어도 피드백을 제공한다.
  • 짝 프로그래밍은 학습에 도움이 된다.
  • 일부 회사에서는 비기술적 업무자를 따라다니는 것을 권장한다. 이를 통해 고객에 대해 눈을 뜰 수 있는 기회를 얻을 수 있다.

개인 프로젝트 활동에서도 배움을 얻을 수 있다

  • 사이드 프로젝트를 통해 기술과 아이디어를 빠르게 배우고 접할 수 있다.
  • 해결하고 싶은 문제를 찾아내고, 자신이 배우고 싶은 도구를 이용해 그 문제를 해결해 보자. 목표가 있어야 더 오래 몰두하고 더 많이 배울 수 있는 동기를 가질 수 있다

제대로 질문하자

  • 질문을 효과적으로 해야 다른 사람에게 폐를 끼치지 않으면서 빠르게 배울 수 있다. 질문을 할 때는 다음과 같은 절차를 밟아보자.
    • 스스로 문제를 해결해 보자: 스스로 자료를 찾아보고, 단위 테스트를 작성하면서 문제를 해결해 보자. 그러면서 어떤 시도를 왜 있는지, 결과는 어땠는지, 무엇을 배웠는지를 기록하자
    • 제한 시간을 정하자: 스스로 문제를 해결하는 기한을 정해두자. 그래야 학습 효과가 높아지고 부적합한 결론이 도출되는 상황을 방지할 수 있다. 제한 시간이 다 됐다면 도움을 청하자.
    • 자신이 시도한 방법을 공유하자: 질문을 할 때 자신이 시도한 방법과 알게 된 점을 간결히 요약해 설명하자.

동료를 방해하지 말자

  • 사람들이 각자의 업무에 집중하고 있다면 방해하지 말자. 정말 심각한 이슈가 아니라면 절대로 사람들을 방해하지 말자
    • 이를 위해 사내에서 공통적으로 사용하는 방해 금지 시그널이 있으면 좋다.

비동기식 멀티캐스팅 의사소통을 시도하자

  • 질문은 여러 사람(멀티캐스트)이 각자의 상황에 따라(비동기식) 응답할 수 있는 곳에 올리자. 그래야 문제가 해결됐다는 것을 모두가 알 수 있고 질문에 대한 답변도 공유할 수 있다.

동기식 요청은 한 번에 보내자

  • 복잡한 질문은 직접 만나 논의하는 것이 좋다. 그러나 직접 만나는 것은 적인 시간에 많은 것을 전달할 수 있지만 다소 비용이 든다. 동료를 방해해서 동료의 생산성에도 영향을 미친다.
  • 따라서 긴급하지 않는 문제에 대해 의논할 수 있는 별도의 시간을 마련해 기술 리드나 팀장과 논의하자. 이때, 미리 질문을 만들고 조사해두는 것이 좋다.

성장의 장애물을 극복하자

  • 가면증후군 (impostor syndrome)
    • 역량이 실제로는 충분함에도 자신이 맡은 역할에 비해 자신의 역량이 부족하다고 느끼고 불신하는 현상이다. 스스로에 대한 불신은 누구에게나 있는 보편적인 현상이라는 점을 염두에 두자. 자기 인식, 관점의 재구성, 동료와 대호 등 몇 가지 방안을 통해 문제를 해결할 수 있다.
    • 무언가를 달성했다면 그것은 운이 아닌 자신의 실력이다.
    • 칭찬과 성과를 외면하지 말자, 작은 일이라도 기록해두자. 이루고 싶은 일에 대한 계획을 세우고 목표를 이뤘다면 주변에 알려서 자신감을 높이자.
    • 자신이 잘 하고 있는지에 대해 평소 존경하는 사람에게 피드백을 받거나 심리치료를 받아도 좋다.
  • 더닝 크루거 효과
    • 스스로를 과대평가하는 인지적 편견이다. 자신의 생각이 항살 옳다고 확신한다.
    • 이런 현상이 있다면 의식적 호기심을 계발해서 존경하는 엔지니어에게 자신이 잘 하고 있는지를 피드백 받고, 동의하기 어려운 설계 방식에 대해 적극적으로 논의해 보자.

출처 - 필독! 개발자 온보딩 가이드