내 실력은 어느 정도 일까? - 주니어 개발자의 고민

The Ostervold Ovservatory

 

어제 일을 시작한지 얼마 되지 않은 따끈한 주니어 개발자와 대화를 나눌 일이 있었다.

 

그의 가장 큰 고민은 자기 실력이 어디까지인지 가늠이 되지 않는 것이었다.

 

그로 인해 파생되는 부가 걱정들이 더 있었다.

• 지금 하는 프로젝트를 기간 내에 성공적으로 완료할 수 있을까?
• 산출물을 내가 원하는 수준까지 만드려면 기간이 얼마나 걸릴까?
• 배우는 것과 일하는 것을 병행하는 것이 맞을까?

대부분 '나는 할 수 없을꺼야'라는 부정적 결론을 이끌어내는 질문들이었다.

 

 

내가 그 분에게 실력 가늠을 위해 권했던 것은 업무 일지를 기록하는 것이었다.

 

아주 자잘한 것까지 내가 할 일, 하고 있는 일, 해낸 일, 하지 못한 일을 기록하는 것.

 

나의 개발 발자취를 남기는 것은 내 실력 파악을 위한 주요한 자료가 된다.

 

이 기록들이 쌓이면 나의 능력을 파악하는데 용이한 것 뿐 아니라 회사에 나의 업무 내용을 어필하기에도 좋다.

 

결국 내 능력은 '나'를 통해 어필되기 때문에 그렇다. (제 3자를 고용해서 쓰지 않는 한)

 

업무 일지를 통해 내가 기간 내에 해낸 일과 나의 장점을 찾는 안목을 길러내야 한다.

 

 

주니어 개발자들에게 개발 능력은 흔히 개인 개발자의 (기간 내에 완성된) 멋진 산출물로 수렴되는 것 같다.

 

물론 글 읽는 이가 존 카맥이나 제프 딘 같은 슈퍼 천재 프로그래머라면 가능할 것이다. (슈퍼 존경을 드립니다..)

 

하지만 나 같은 일반인 개발자라면 저런 생각의 위험성을 아래의 예를 들어 알리고 싶다.

 

 

첫째, 현 시대에 어떤 프로그램도 오롯이 개인이 만들기 어려우며, 그렇게 되어서도 안 된다.

 

프로그래밍에서 활용하는 기본 라이브러리 (입출력, 포맷 변환, 시간 등)만 해도 이미 누군가가 개발해 놓은 것이다.

 

수십년간 발전해 온 소프트웨어 개발의 기본 원리는 기능의 계층을 분리하고

각 계층의 책임을 정의하여

다른 계층에서 이를 신경쓰지 않도록 하는 것이다.

 

기본적인 예시로 OSI 7 계층 모델이나 운영체제, 프로그래밍 언어 등이 있겠다.

 

즉, 그렇게 다른 누군가가 잘 개발해놓은 것을 그의 관점으로 올바르게 활용하는 것이 개발자로써 올바른 태도인 것이다.

 

 

둘째, 자신의 능력을 먼저 파악하지 못하면 스스로 기간 내 완수 여부를 확신할 수 없다.

 

내 스스로에 대한 이해도가 높고 주어진 과업도 세분화 할 수 있다면 그 중 내가 할 수 없는 부분을 빨리 캐치할 수 있다.

 

내가 할 수 없거나 경험 상 시간이 많이 걸리는 부분은 리스크 그 자체이기 때문에 사전에 논의되어야 한다.

 

나의 역량이 업무를 수행하면서 커질수도 있지만 이는 어디까지나 불확실한 미래에 대한 위험한 가정이다.

 

이런 불확실성으로 업무를 수행하는 중에 나를 소모하게 될 가능성이 높아진다.

 

 

셋째, 나의 신뢰도가 하락할 수 있다.

 

위의 문제가 내면에 대한 것이라면 이건 외부의 시선으로 나를 볼 때의 신뢰도를 의미한다.

 

한 번의 실패는 용납이 될지 몰라도 여러 번의 실패가 중첩된다면 그로 인한 나의 신뢰도 하락은 아주 치명적일 것이다.

 

 

넷째, 소통 능력 또한 개발자의 중요한 덕목 중 하나이다.

 

혼자 무언가를 뚝딱 만들어 온 이력은 결코 소통 능력에 있어 긍정적인 지표가 될 수 없다. 

 

 

개발자의 실력은 산출물을 만드는 과정에서 나온다.

 

또한 처음 만들어진 산출물을 최적화 하고 다듬는 과정에서도 실력이 발휘된다.

 

그 과정들을 업무 일지를 통해 기록해서 내 실력을 나에게 체화시키자.

 

체화된 실력을 이력서에 반영해보자.