안녕하세요~ 테크 기업 전문 취업 전략 컨설턴트이자 생애 로드맵 설계가인, 작가 동사힐입니다. 😊
2021.04.27 - [청년을 위한 취업 전략 & 전술/취업 성공 루틴] - 어떤 개발자와 함께 일하고 싶나요?(feat. 수동 vs 능동)
지난 시간에 능동적 개발자와 수동적 개발자를 비교하는 포스팅을 했습니다.
이때 프로젝트 성공을 위해 개발자에게 꼭 필요한 다섯가지 능력을 간단하게 언급을 했는데요.
오늘은 다섯가지 능력을 자세하게 살펴보도록 하겠습니다.
프로젝트를 성공적으로 수행하기 위해 개발자가 반드시 지녀야 할 다섯가지 능력은 다음과 같습니다.
1️⃣ 개발 기술력
2️⃣ 커뮤니케이션 능력
3️⃣ 리더십
4️⃣ 개방성
5️⃣ 잉여성
그러면 각각의 능력을 하나씩 자세하게 살펴보도록 하겠습니다.
출처는 IT 개발자의 거의 모든 것입니다.
1. 개발 기술력 : 기술로 개발하는 사람
프로젝트에 있어서 개발 기술력의 비중이 20%밖에 안 된다고 하지
만, 그렇다고 개발 기술력이 중요하지 않다는 말은 아니다. 오히려 이
기술력은 프로젝트를 수행할 때 없어서는 안 될 필수 요소이다. 이 기
술력이 부족해서 현업의 요구 사항을 충족시키지 못하면 프로젝트
자체의 존폐 위기를 맞기 때문이다. 그 때문에 개발 기술력은 마치
공기처럼 프로젝트에 기본적으로 녹아들어 있어야 한다. 그럼 이 기
술적인 이슈에는 어떤 것이 있을까?
개발을 수행함에 있어서 기본적으로 개발 툴에 대한 이해도가
높아야 한다. 개발자들은 자신의 분야에서 사용하는 주요 툴뿐만 아
니라, 자신이 주로 사용하지 않는 툴도 다뤄야 하는 경우가 상당히
많다.
개발자에게 개발 기술력이 필요하다는 것에 의문을 제기하는 사람은 없습니다.
그렇다면 도대체 기술력이라는 것은 무엇을 의미할까요?
바로 개발 툴에 대한 이해도를 기술력이라고 할 수 있습니다.
이해도가 높으면, 상황에 따라 유연하고 다양한 코드를 사용할 수 있습니다.
그러나 이해도가 떨어지면, 효율이 떨어지는 코드를 짤 수 밖에 없겠죠.
이러한 이해도는 단순히 개발 툴을 오랜 시간 학습하여 생기는 것은 아니고, 실무에서 다양한 경험을 통해서 성장한다고 볼 수 있습니다.
2. 커뮤니케이션 능력 : 함께 한다
사실 개발자는 기획자가 만들어준 문서와 기획서에 따른 디자인 파
일을 보고 해당 기능을 구현해 넣으면 그만이다. 어떻게 보면 대화조
차 필요 없는 분업화된 시스템이라고 할 수 있겠지만, 이것은 어디
까지나 능숙한 팀원들과 일할 때의 얘기다. 모든 팀원들이 일을 잘하
지는 않기 때문이다. 개발자가 결국 디자인과 기획 문서를 다시 한번
검토해야 한다. 기획안이나 디자인적인 부분을 개발 측에서 모두 수
용할 수 없는 일도 다반사다. 또 개발 일정을 고려하지 않고 적용된
수많은 요구 사항에 대해서는 개발자가 현업에게 논리적 반론을 제
기해야만 한다. 개발자는 이 과정에서 최대한 쉽고 납득할 만한 논리
로 부드럽게 대응하는 것이 중요하다. 기술을 잘 알고 있는 개발자들
은 프로젝트를 같이 수행하는 비개발자들을 어떻게 이해시킬 수 있
을지 고민하게 된다. 그 고민의 과정을 피해 갈 수는 없다. 개발자의
말 한마디 한마디가 문서화될 수 있기 때문에 주의를 기울여야 한다.
프로젝트에서 현업과 개발자는 엄연한 계약 관계이기 때문이다.
개발자는 개발자와도 소통을 하지만, 동시에 비개발자와도 소통을 많이 합니다.
그러다보니 커뮤니케이션 능력은 필수적입니다.
커뮤니케이션 능력은 표현과 이해 능력으로 구분할 수 있습니다.
예를 들어 기획자의 생각을 정확하게 이해하는 것도 커뮤니케이션 능력이죠.
동시에 개발 일정을 고려하지 않고 마구잡이로 요구되는 사항을 논리적으로 거부하는 의사 표시도 커뮤니케이션 능력입니다.
이처럼 실무에서 다양한 상황을 지속적으로 접하면서 커뮤니케이션 능력이 요구됩니다.
따라서 실무에 가기 전까지 다양한 프로젝트 협업 경험을 통해서 커뮤니케이션 능력을 키우도록 해야 겠죠.
잊지 마세요. 프로젝트에서 개발자는 항상 함께 합니다.
3. 리더십 : 실행은 수직적
리더십이 없다면, 팀이 흔들릴 가능성이 커진다. 리더는 다른 말
로 표현하면 손해 보는 자이다. 누군가에게 따르고 싶은 마음을 얻는
사람은 대체로 무언가 가치 있는 유무형의 요소를 나누어 주는 경우
가 많다. 어떤 목적을 가지고 움직이는 팀 안에서 그 목적을 달성하
기 위해 제안된 일거리의 상당수는 담당자가 지정되지 않았거나 그
경계가 애매한 경우가 많다. 이런 요소들은 수면 위로 드러날 때까
지 숨어 있다가 어느 순간 프로젝트 일정을 난도질하는 경우가 많은
데, 이런 요소들을 대가 없이 처리하는 사람이 있다. 이 사람은 위기
를 마주할 때마다 은연중에 모두를 독려하고, 자신을 희생하여 일을
마무리 지어주기도 한다. 리더십이 뛰어난 사람은 그 과제가 끝날 때
드러나기 마련이다. 본인이 미처 자각하지 못했더라도 말이다.
우리나라처럼 개개인의 개발자에게 강하게 의존하는 IT 프로젝
환경에서는 개발자에게 리더십이 필수다. 하지만 프로젝트를 이
끌어가기 위해서는 다른 여러 능력들도 필요하다. 능숙한 개발력과
커뮤니케이션 능력도 동원된다. 그리고 무엇보다 과업을 여유 있게
소화할 수 있어야 프로젝트에서 리더십을 발휘할 수 있다. 프로젝트
에서 동일한 노력을 하고도 리더십을 얻지 못하는 사람들도 있는데
그런 사람들은 과제가 끝나면 만신창이가 돼있다.
리더십이 중요하다는 것은 너무나 당연합니다.
실무에서 프로젝트는 하나의 전쟁입니다.
마감 기한이 있고, 목표가 있으며, 그 목표를 수행할 개발자가 있죠.
그런데 리더십이 없으면 결국 그 전쟁은 패배하게 됩니다.
매일 매일 일정들은 작은 승리를 하더라도,
전략적으로는 패배할 수도 있습니다.
리더십 부재는 그만큼 치명적입니다.
팀원들에게 전체적인 그림을 그려주는 역할을 해야 합니다.
리더십은 필수라고 할 수 있습니다.
4. 개방성 : 새로운 것을 도입하는 용기
예전에 한 중소기업에서 수주한 프로젝트를 수행하던 도중, 자체적
으로 개발한 개발 솔루션을 도입하여 진행한 적이 있다. 해당 프로젝
트는 중요한 고객의 프로젝트였다. 그래서 개발 솔루션을 만든 책임
자가 직접 프로젝트에 투입됐다. 이 솔루션 책임 개발자는 자신이 주
축이 되어 개발한 솔루션에 대단한 자부심이 있어서 많은 이들에게
그 뛰어남을 종종 설파했다. 하지만 프로젝트의 설계 기간에 기초공
사를 진행하는 도중 자체 솔루션에서 제공하는 기능함수들인 API를
이 너무 낮은 레벨로 제작되어 생산성이 떨어지자 이 API를 이용해
좀더 효율적인 API 묶음 클래스를 제작하는 것을 보고 솔루션 책임
개발자는 매우 화를 냈다. 제공되는 API를 이용하여 개발하면 되는
데 왜 또 다른 모듈들을 개발하느냔 말이었다. 그 프로젝트의 새 APT
모듈을 제작하던 실무자인 PL은 이 프로젝트에서만 사용되는 특정
설정들은 모두 공통으로 반복되어 사용되기 때문에 한 번 더 클래스
를 이용해 묶어서 쓸데없이 반복되는 소스코드를 줄여야 한다고 주
장했다. 솔루션 개발자는 이후로도 그 문제에 대해 의견을 굽히지 않
고 사사건건 모듈링을 방해했다. 결국 그 개발자를 본사로 복귀시키
고 나서야 다시 프로젝트가 원활히 진행됐다.
많은 개발자들은 자신이 가진 기술을 맹신하고, 잘 모르는 기술
은 무조건 배척하려는 경향이 있다. 그 마음의 저변에는 다른 라이브
러리나 개발 기술을 도입할 경우 지금도 힘겨운 일정이 더욱더 힘들
어질 수도 있다는 자기방어적인 이유가 섞여 있다. 새로운 것을 받아
들일 때 또다시 공부해야 하는 부담감 때문에 기피하는 경우도 있다.
이는 피해서 될 일이 아니다. 새로운 기술을 도입하거나 개발할
경우 그 기술에 대한 선행 학습은 빼놓을 수 없는 과정이며 그 일정이
나 자원은 마땅히 지원받아야 하는 것들이다. 또 습득한 적이 없는 신
기술을 도입하는 과정은 수많은 위험 요소를 동반하기 때문에 그러한
문제를 빠짐없이 제기하고 해당 자원을 습득한 후 진행하면 된다. 새로
운 것을 도입해보려는 개발자의 용기가 필요할 뿐이다.
누구나 자신이 하던 것을 바꾸라고 하면 자기 방어적인 태도를 보일 수밖에 없습니다.
익숙하던 것을 버리고, 새로운 것을 해야 하니까요.
그런데 이러한 자기방어적 태도를 버려야 하는 사람이 있습니다.
바로 개발자입니다.
아무리 그 전에 어떠한 퍼포먼스를 보였다 하더라도,
새로운 툴이 등장하고, 더 효율 좋은 모듈이 나오기 때문이죠.
벼는 익을수록 고개를 숙인다는 말, 개방성을 상징적으로 드러내는 좋은 말입니다.
5. 잉여성 : 토이프로젝트
개발자라는 직업에서
잉여력이 발휘되는 상황을 생각해보면 답이 쉽게 나온다. 많은 개발
자들은 개발이라는 분야에 대해 제법 즐거움을 느끼고 있다고 말한
다. 결국 개발이라는 행위 자체가 개발자에게는 놀이가 될 수 있다는
이야기다. 이런 개발자들은 시간이 남을 때 휴식을 취하다가 싫증을
느끼면, 평소에 관심은 있었으나 보지는 않았던 신기술 개발 서적을
뒤적거리기 시작한다. 이마저 싫증이 나면 자신이 관심 있던 분야를
기웃거리다가 취미 생활처럼 서비스 개발을 하는 경우가 있다. 개발
자에게 놀이이자 공부인 개발은 남는 시간에 하는 트레이닝이자 새
로운 수익원으로 변모한다. 이 잉여력 넘치는 개발물은 오로지 자기
만의 영역이기 때문에 개발자에게 유쾌함을 안겨준다. 그 개발물은
개인에게 눈에 띄는 실력 향상을 가져다줄 것이다.
실리콘밸리를 봐도, 판교를 봐도, 토이프로젝트에서 시작한 유니콘이 많습니다.
그리고 그러한 잉여적인 활동에서 개발 실력이 늘어나기도 합니다.
놀이가 학습이고, 학습이 놀이인 개발자.
가장 이상적인 개발자의 잉여성 아닐까 싶습니다.
어떠셨나요? 도움이 되셨나요?
그러면 다음에도 더욱 좋은 글로 돌아오겠습니다.
궁금한 사항 있으시면 댓글로 남겨주세요.
도움이 필요하시다면 사연을 적어서 이메일을 보내주세요.
그리고 도움이 되셨다면 공감과 구독 부탁드려요.
이상으로 동사힐이었습니다!
읽어주셔서 감사합니다. 😊
'북로그 > 독서 기록' 카테고리의 다른 글
대기업 인사총괄책임자가 말하는 면접 핵심 전략(feat. 면접왕 이형의 면접 바이블) (0) | 2021.05.12 |
---|---|
세계 최고 기업의 첫 시작은 어땠을까?(feat. 아마존, 나이키 그리고 버크셔해서웨이) (0) | 2021.05.05 |
약자가 강자를 이기는 3가지 방법(feat. 다윗과 골리앗) (0) | 2021.05.03 |
문제를 가져오지 말고, 해결책을 가져오세요(feat. 일 잘하는 사람은 단순하게 말합니다) (0) | 2021.05.01 |
럭키 에비스 맥주 그리고 도미 두 마리(feat. 어른들의 네잎클로버) (0) | 2021.04.26 |
댓글