기술을 익혀나가는 과정

1. 사용할 수 있게 된다. 2. 왜 사용해야 하는지 이해한다. 3. 어떠한 구조로 구현되는지 이해한다. 4. 필요에 맞게 변형하거나 재창조 할 수 있다. 실무자 입장에서는 보통 2번에서 멈추는게 효과적일 때가 많습니다. 좋은 구조와 성능을 위해서라면 3번까지도 내려가야 할 필요가 있습니다. 대신 4번의 영역에 도달할 일은 잘 없습니다. 괜히 컴퓨터공학에서 Abstraction이라는 개념이 중요한게 아니죠. (예전에는 무조건 3번까지는 경험해야한다고 생각했는데 제품 중심의 빡빡한 개발 사이클 속에서는 어려울 수도 있다고 느꼈습니다) 재밌는 건 제가 아는 테크 스폐셜리스트들은 다들 업무 외적으로 3,4번까지 파고드는 과정을 즐긴다는 것입니다. 그리고 그것을 많이 반복해서 그런지 그 속도가 매우 빠릅니다. 게다가 가끔 실무에서 4번의 영역이 필요할 때 그걸 맡게 되는건 스폐셜리스트들이죠. 경험의 부익부 빈익빈 현상이 발생합니다. 저는 처음 일을 시작할 때부터 운이 좋게도 그러한 스폐셜리스트를 만날 수 있었고, 멋지다고 생각해 따라해 보려고 노력했었습니다. 물론 저는 업무와 얼라인 되지 않으면 효율이 극도로 떨어지는 사람이라 그리 오래 지속되지는 못했지만요. 대신 4번의 과정까지 필요한 상황이 있다는 걸 인지하고 있고 필요하면 나도 할 수 있다는 자신감은 남게 되었습니다. 그리고 그것들이 이후 커리어를 쌓아나갈 때 많은 도움이 되었다고 생각합니다. 오늘 이 글을 쓰게 된 건 저와는 다르게 이러한 스폐셜리스트들을 만나지 못한 주니어분들도 있을 수 있기 때문입니다. 그리고 본인은 몰랐지만 업무 외적으로도 기술을 깊게 파보는 것을 즐기는 스폐셜리스트 성향의 사람일 수도 있구요. 혹시 이번 주말에 또 어떤 프레임워크를 새로 익혀볼까 고민하고 계시다면, 그보다는 잘 알고 있다 생각하는 프레임워크의 소스를 받아서 분석하는 시간을 가져보는 건 어떨까요?

다음 내용이 궁금하다면?

또는

이미 회원이신가요?

2023년 3월 9일 오후 2:47

 • 

저장 28조회 3,249

댓글 2