본문 바로가기
생각정리

과락하지 않기

by 향로 (기억보단 기록을) 2024. 9. 2.
반응형

국가기술자격증 시험에는 재밌는 제도가 있다.
평균 60점이 넘으면 시험을 통과할 수 있는데, 나머지 과목들을 모두 100점을 맞아도 한 과목이 40점 이하이면 과락으로 탈락이다.

즉, 5과목 중 4과목이 100점이고 한 과목이 39점이면 평균 87.8점임에도 불합격이다.

모든 과목을 60점이상 맞을 필요는 없지만, 한 과목이라도 40점 이하는 안된다는 이 제도가 스타트업 생활을 하면서 자주 생각하게 된다.


작은 회사에서 큰 회사로 가는 경험을 계속 하다보면 "장점의 극대화 vs 단점의 최소화" 의 결정들을 자주 보게 된다.
주변의 다른 사람들과 비교해 내가 갖고 있는 장점을 더 극대화 하는 것으로 커리어를 발전시켜나갈 것이냐, 아니면 타인에 비해 부족한 점을 채워나갈 것이냐인 것이다.

예를 들어 아직 서비스가 일정 규모이상 크지 않을 때는 기술적 역량이 대단히 뛰어나거나 협업을 굉장히 잘하는 동료를 만날 일이 거의 없다.
하지만, 서비스의 규모가 점점 커지면서 회사가 풀어야할 기술적 문제의 난이도가 높아지면 자연스레 기술적으로 뛰어난 동료들을 만나게 된다.

나보다 나이가 어리고 경력이 낮음에도 어려운 기술적 장애 상황을 척척 해결하거나,
나와 연차가 비슷한데 이미 수많은 경험을 통해 좋은 방향으로 팀에게 기술적 로드맵을 제안하고 실제 결과를 만들어내는 등
전문성이 뛰어난 동료를 만나고 나서 선택의 기로에 빠지게 된다.

그리고 "내가 지금부터 노력해도 저 사람처럼 안될 것 같으니, 저 사람이 갖지 못하는 영역을 개발하자" 의 선택을 하는 경우를 자주 보게 된다.

조직과 팀에 기여하기 위해 본인의 장점을 개량하는 것 자체가 문제가 되진 않는다.
다만, 본인의 부족한 점이 있다면 그에 대해 최소한의 역량까지는 끌어올려야 한다.

  • 커뮤니케이션 역량이 부족해서 항상 협업에 관해서 지적을 받는다면, 달변까지는 아니더라도 동료들이 불편을 느끼지 않을 정도로는 개선해야한다.
  • 매번 본인의 문제를 해결 못하여 항상 주변 동료들의 도움을 받아야만 한다면 스스로 해결할 수 있을 정도까지는 기술적 전문성을 쌓아야 한다.
  • 매번 지각을 하여 항상 회의 시간을 오후에만 잡아야 하는 상황을 유발하고 있다면 아침형 인간까지는 아니더라도 최소한 지각은 하지 않도록 성실함을 가져야 한다.

과락이란, 함께 하는 동료들이 같이 일을 하는데 문제가 없을 정도의 역량을 얘기한다.
그게 기술적 전문성이든, 커뮤니케이션이든, 문서화든 무엇이든 간에 과락이 있으면 안된다.

위와 같은 경우 기술적으로 팀에 기여하지는 못할 것 같아 기술적 전문성을 쌓는 것을 하지 않는 선택을 하면 안된다.

나보다 월등히 뛰어난 사람을 만나 그 사람에 비해 더 잘할 자신이 없어서 그 분야에 대한 발전을 포기하면 절대 안된다.
그때 절대 포기하지 말고 본인의 단점을 최소한의 수준 이상까지는 끝까지 잡고 가야 한다.
그래야만 나의 장점이 단점때문에 희석되지 않는다.
장점을 더 극대화시키려면 장점을 희석시킬정도의 단점은 개선하는 것이 좋다.


호돌맨이나 용근님, 승원님 같은 분들과 함께 일하면서 이들과 비교하여 "내가 가진게 도대체 무엇인가" 하는 고민을 하게 된다.

나이는 더 많고,
개발자로서 기술적 전문성도 이들 보다 더 잘하지 못하는 상황에서 그나마 내가 저들에 비해 장점이라고 내세울 수 있는 것은 문서화, 커뮤니케이션 등의 소프트 스킬이라는 생각이 들었다.

그래서 이 것들을 더 잘하기 위해 노력했냐한다면, 오히려 반대였다.
의도적으로 시간이 될 때마다 기술만 파고들었다.
단점을 개선하기 위해 노력했다.

내 기준에 그들은 대단히 훌륭했기 때문에 그들과 계속 같이 일하고 싶었기 때문이다.
그래서 "저들보다 전문성이 더 뛰어난 개발자가 되어야지" 가 아니라 "저들과 함께 일하는데 방해가 되지 않을정도는 되어야지" 가 되고 싶었다.
(그 정도의 목표도 나에게는 버겁긴했지만 말이다.)

다행히 그런 노력이 통했는지 내가 남들보다 부족하다고 생각했던 기술적 전문성이 나의 장점을 가리진 않았다.
그리고 기술적 전문성을 확보한 뒤부터는 장점이 좀 더 부각되었다.

모든 개발자가 완벽해질 필요는 없다.
다만, 부족한 점이 강점을 가리면 안된다.
함께 일하는 동료들이 자주 이야기하는 피드백이 있다면 그 부분은 일단 고치고, 장점을 더 개선해보자.
그게 오히려 더 장점을 살리는 길이 된다.

반응형