IT 인재 육성 노하우

 

초고석 성장한 기업의 Tech Leader가 전하는 IT 인재 육성 노하우 (By Fast campus business)

 

대부분의 산업이 software 기반으로 전환되는 가운데 비즈니스의 성장을 앞당길 수 있는

인재의 몸값도 이전과 비교해 눈에 띄게 치솟았다.

기술도 결국은 사람이 하는 일인지라 software 기술에 대한 투자만큼 사람에 대한 고민도 깊어졌다.

IT인재를 기업에 불러들이고, 오랫동안 머무르며 성장하고 싶게끔 만드는 동인이 무엇일까

 

Microsoft 연례 개발자 컨퍼런스인 Build 2021 에서 software 개발과 관련된 영역이

2020년에서 2030년으로 가면서 5%에서 10%로 성장할 거라 말한다.

10년 내에 2배까지 크게 성장하는 것이다. 더 중요한 사실은 성장 후에도 90%가 남아 있다는 점이다.

즉, 요즘 화두가 된 DX(디지털 전환)는 이제 시작이지 완성되었거나 끝난 게 아니라는 것이다.

 

개발 조직의 성능, 즉 '생산성' 을 향상 시키는 것이 점차 중요해지고 있다.

그런데 개발자를 더 많이 뽑는다고 속도가 빨라지거나 생산성이 급진적으로 향상되는 것은 아니다.

<The Mythical Man-Month> 라는 책을 보면, 'software project가 지연되고 있는데 여기에 개발자를 더 투입하는 건 오히려 프로젝트 완성을 더 늦출 수 있다.' 는 이야기가 나온다.

 

생산성 향상과 병렬 개발과

50명의 개발팀이 10명의 개발팀보다 속도가 5배 빨라야 하는데 그렇지 않다.

병렬로 개발 하려면 a와 b라는 각각의 작은 조직이 구현하는 모듈 간에 의존성 관리가 잘 되어야 한다.

a가 완료되기 전에 b도 계속해서 동시에 개발을 진행할 수 있는 독립적인 개발과 배포 환경이 만들어져야 한다.

그래야만 생산성 높은 병렬 개발이 가능하다.

--> 당연한 이야기이다. 팀 내에서는 어느정도 되는것도 있고 아쉬운 모습도 관찰되고 있긴 하다.

다만, 실 내에서 팀이 다르기에 공유되지 않는 공통 모듈, 공통 기능들, 기타 개발 방식들 등에 따라 아직은 아쉬운 모습이 너무 많다. 아쉬운 모습이 많다는 것은 개선할 수 있는 것이 많다는 것이고 내가 해야 할 일이 많다는 것으로 해석하면 좋은(?) 일이다.

 

품질과 설계 수익 라인

개발 조직이 아닌 타 부서에서는 이런 이야기를 종종 한다. '설계가 중요한 건 알지만 당분간은 사업을 위해 맞춰야 하는 일정이 가장 중요하므로 설계 과정을 간소화해야 한다.'

이렇게 이야기 하는 배경에는 '속도를 내기 위해서는 설계는 희생해야 하는 요소' 라는 생각이 깔려 있다.

Quick & Dirty, 즉 '좋은 설계 없이 개발' 한 경우 일시적으로 속도가 빨라지며 성정하는 걸 볼 수 있다.

하지만 이럴 경우 '기술 부채' 때문에 새로운 기능을 추가하는 속도는 더뎌지고 기술 부채를 탕감하는 데 자원을 낭비하게 된다.

결과적으로 지속적으로 생산성이 떨어지는 양상이 반복된다.

--> 사내 제품들이 최초 설계가 잘못되었고 급하게 진행되었고 사업으로 인해 시작되었고... 코드 품질 또한 일정에 맞춰 개발하느라 엉망이 된 제품들이 있다. 너무 맞는 말이기에 뼈가 아프다.

 

고품질의 소프트웨어는 비용이 높다는 편견

소프트웨어는 사용되기 시작하는 순간부터 변경 요구사항이 나온다는 특징을 지닌다.

내부 품질이 좋으면 변경 요구 사항이 나오더라도 비교적 낮은 비용을 들여 반영할 수 있다.

소프트웨어의 높은 내부 품질에 집중하는 건, 향후에 변경 요구 사항이 발생할 경우 유지보수에 들어가는 비용을 낮춰 생산성 저하가 일어나지 않게 하는데 큰 역할을 한다.

우리가 집중해야 하는 건 유지보수 비용을 낮추기 위해 코드를 이해하기 쉽게 만들어야 한다는 것이고 결국 설계를 잘 해야 한다는 것이다.

소프트웨어 품질에 관해 무언가를 설득해야 할 때는 개발자의 전문성이 아닌 경제적인 관점으로 접근해야 한다.

ex. "높은 내부 품질은 향후 기능 추가할 때 발생하게 될 비용을 낮추는 역할을 하기 때문에 지금 다소 시간이 소요되더라도 이 고통의 시기를 지나면 우리는 더 빠르게

시장 가치 높은 기능들을 출시할 수 있다. 이를 통해 생산성을 높일 수 있다."

 

함께 일하고 싶은 기술 조직이란 어떤 모습일까

혁신을 위해서는 옳고 그름을 따지기 보다는, 구성원 각자의 다양성과 전문성을 존중하며 협력하여 결과물을 만들어내는 역량이 중요해진다.

내가 손해를 조금 보더라도 우리 비즈니스가 잘 성장하고 옆자리의 동료가 잘 되는 일에서 보람과 가치를 느끼는 조직, 그런 사람이 인정 받는 조직인지를 중요하게 생각해야 한다.

새로운 것을 학습하고 학습을 통한 역량 증대를 중시 하고 자기가 알고 있거나 새롭게 알게 된 노하우를 주변에 빠르게 전파하여 함께 잘 되기를 바라는 사람들이 많은 조직이어야 한다.

--> 항상 어떤 선택을 할때 나에게 불리한 조건을 선택해라.. 라는 이야기를 해 주신 분이 있다. 그로 인해 지금까지 항상 그렇게 선택해 왔고 그렇게 하고 있다. 그리고 제품이, 내 팀원이 잘되는 것에 보람과 가치를 느끼고 있는데 퇴사하면 힘이 빠지는 현상도 반복되고 있다. 이걸 어떻게 해결해야 할까 늘 고민이다.

--> 학습을 통한 역량 증대, 빠르게 전파하는 공유 문화를 만드는 것을 중요하게 생각하고 있다. 아직은 많이 부족해 보이지만 훌륭한 팀원들이 있기에 앞으로 더 기대할 수 있을 것 같다.

 

역량이 높은 기술 조직의 기준이 있다면 무엇일까

기한 내 요구사항을 모두 구현하여 잘 동작하면 끝났다고 생각할 수 있고 동작 이후 실제 사용자에게 피드백을 받아 지속적으로 개선할 수 있는 역량을 갖고 있는 조직도 있다.

세밀한 설계보다는 느슨하게 설계해 빠르게 시작하고 다양한 시도를 거쳐 처음의 설계를 순차적으로 견고하게 만들어 나가는게 중요하다.

--> 느슨하다는 표현을 자칫 '대충' 이라고 잘못 이해하면 안된다. 애자일을 말하는 것이며 반복적인 설계/리뷰/프로토타입/테스트 실험등을 통해 견고하게 만드는 것을 정확하게 이해하고 있어야 한다.

 

기술 조직의 역량을 끌어올리기 위해 어떤 노력을 하고 있나

조직 전체가 알아서 스터디하고 문제와 노하우를 공유하며 리뷰하는 문화가 필요하다.

한 팀이 10명이라면 10명 모두 에이스일 필요도 없고 그럴수도 없다.

하지만 이중 2명 정도 에이스가 있다면 팀 전체가 성장하고 높은 수준의 결과물을 낼 수도 있다.

따라서 훌륭한 인재를 채용하는 게 중요하다.

동시에 진짜 중요한 일을 우리 구성원들이 정말 높은 수준으로 매듭 지을 수 있게끔 10~20% 여유를 마련하는것도 필요하다.

회사에서 오늘보다 내일 더 나은 수준의 결과물로 기여할 수 있도록 선순환을 만드는 것도 리더의 역할이다.

 

생산성이 높은 개발 조직을 만들기 위해 어떤 노력이 필요한가

결과가 크게 돌아올 실험들은 대체로 실패할 확률이 높다.

이런 실험을 10개해서 2개만 성공해도 자잘한 액션 10번 하는것보다 훨씬 큰 성과를 기대할 수 있다.

 

좋은 인재를 판단하는 기준이 있다면 무엇인가

복잡하게 얽혀 있는 문제들을 파악하고 직접 해결할 수 있는 사람.

높은 역량을 지닌 인재라면 약점은 조직이 최대한 품어주어 구성원이 지닌 역량과 장점을 발휘해서 비즈니스에 기여할 수 있게 조율하는 방식이 필요하다.

ex) 문제 해결능력이 뛰어난데 성격이 조금 특이해서 커뮤니케이션에 문제가 있다면? 조직 차원에서 최대한 이해하고 장점을 최대치로 발휘할 수 있도록 돕는다.

--> 요즘 채용을 위한 면접을 많이 보게 되는데 좋은 인재를 채용하는 것이 매우 어렵다. 과제도 하고 있고 현장 문제도 하고 있기 때문에 어느 정도 판별에 도움이 되긴 한다. 다만 아직까지 채용과 관련해서 면접관으로 들어가는 사람들의 질문 수준, 태도, 질문 Pool 이 확정되지 않았고 이에 대해서 다같이 모여 고민하고 어떤 사람을 채용하고 싶은가...에 대한 논의를 해서 질문 pool 도 채용 기준 항목에 맞게 분리해서 체계적으로 평가할 수 있는 상황을 만들 필요가 있어 보인다. 재미있게 본 내용은 '성격이 조금 특이해도 문제 해결 능력이 좋다면' 조직 차원에서 어느정도는 이해해 준다는 것인데, 필요한 부분이라고 생각하며 '조금' 이라는 기준을 판단하는 것이 매우 중요해 보인다.

 

개발자가 갖춰야 할 기술

1. 엔지니어링 스킬: 개발 지식, 제품 이해, 개발 사이클..(혼자서 학습하여 채워야 하는 역량, 지속적인 공부)

2. 매니지먼트 스킬: 프로젝트 매니지먼트, 팀 매니지먼트, 프로세스 관리 역량..

3. 비즈니스 스킬: 회사의 HR 시스템 이해, 사업 관리, 회사의 비전과 조직문화 운영 관련 역량..

- 잘못된 사람을 채용하는 것은 기업 입장에서는 그 사람에 지불하는 연봉의 절반 정도에 달하는 손해가 발생한다고 한다.

관리자들은 업무의 1/3 정도는 좋은 사람을 찾고 뽑는 일에 사용해야 한다.. 1/3은 채용 이후 일을 잘할 수 있도록 계속 도와주는 조직 관리 업무로 채워져야 한다. 나머지 1/3은 개인적인 업무를 처리하는데 사용한다.

--> 정답은 없고 위에서 말한 것이 무조건 옳은 것은 아니다. 우리 회사에서의 리더는 개발을 함께 하고 있기 때문에 조정이 조금 필요한 부분도 있어 보인다. 최소한 '팀장' 정도의 소규모 팀 리더는 개발을 함께 한다고 가정하고 업무 분배를 해야 할 듯 하다. 부서장이 될 경우에는 '개발' 을 직접 하는 것을 최소화 해야 하지 않을까.. 생각이 든다.

 

기술 조직의 역량 향상을 위해 리더는 어떤 역할을 하나?

지식, 스킬, 경험 3가지가 구성원의 역량을 이루는 요소라고 생각한다.

새로운 기술을 적용하더라도 전체 프로젝트는 실패하지 않도록 잘 조율해야 한다.

Google 은 전체 리소스의 80%만을 업무에 투자하게 하고 나머지 02%는 다른 일을 하게 한다. 즉 20%는 실패해도 괜찮다는 것이다.

조직의 모든 사람의 모든 업무가 잘 되어야 프로젝트가 성공할 수 있다면, 사실 굉장히 위험한 상태라고 할 수 있다.

조직이 안정적으루 운영되려면 버퍼를 만들고 구성원들이 돌아가며 버퍼가 되어 시장에 등장한 새로운 기술을 적용할 수 있도록 하는게 좋다.

--> 리더로써 버퍼를 너무 주지 못한 상황들이 많았던 것 같다.

 

구성원의 역량 강화를 위해 회사에서는 어떤 노력을 할 수 있을까?

구성원의 교육비나 도서 비용에 대해서는 무제한으로 지원해야 한다. 사내 세미나도 필요하다.

꼭 당장의 업무와 연계되지 않더라도, 요즘 관심 있는 기술 분야나 새로 나온 기술에 관해 구성원들이 돌아가면서 발표하는 자리도 있어야 한다.

스터디 클럽을 운영하는 것도 좋다. (ex. 꼭 봐야 하는 책이 있다면 다같이 모여서 해당 도서에서 다루는 내용에 관해 이야기 나누며 완독할 수 있다)

사내 멘토와 멘티를 신청 받아서 서로 잘 아는 내용에 관해 가르쳐주고 배울 수 있는 환경을 조성할 수도 있다.

--> 몇가지는 현재 우리 회사에서도 하고 있긴 한데 조금 더 활발한 활동이 이루어질 수 있도록 리더로써 해야 할 일이 무엇인지 지속적으로 고민하고 실험해 볼 필요가 있어 보인다.

--> 특히 기술적인 사내 멘토 신청을 통해 팀이 다르더라도 기술 공유할 수 있는 환경을 만들어 주는 것도 좋을 듯 하다.

 

리더로서 일하고 싶은 기술 조직이란 어떤 모습인가?

팀의 목표 의식이 구성원 모두에게 잘 align 되어 있는 조직, 즉 '무엇을 할 것인가' 에 대해 서로 동일하게 이해하고 있어야 한다. 다른 사람 10명이 하나의 목표를 향해 가면서도 각자의 개성을 잃지 않는 조직

제일 중요한 건 한 사람 한 사람의 역량이 뛰어나야 한다.

 

 

위 내용은 패스트캠프에서 진행한 "IT 인재 육성 노하우" 내용 중 일부를 발췌한 것 입니다.

(각 내용별 화살표 내용은 내 생각)