회사 지시에만 따르면 바보 개발자가 되는 이유와 탈출법

많은 개발자분들은 개발자로써 실력을 어떻게 키울 수 있는지 혹은 높은 연봉을 어떻게 받을 수 있는지 궁금해합니다. 이 방법을 알기 전에 우리가 먼저 생각해 봐야 할 부분이 있어요. 그것은 바로 “회사에서 시키는 데로 개발만 하면 바보 개발자가 된다”라는 점임입니다. 바보 개발자라. 솔직히 바보 개발자는 아니고요. 조금 더 정확히 말하면 그저 그런 개발자가 될 확률이 높다고 말할 수 있어요.

자, 그렇다면 회사에서 시키는 일만 해서는 뛰어난 개발자가 될 수 없는 이유가 무엇일까요?

그 이유에 대해서 조금 더 짚어 보겠습니다.

 

검증된 소프트웨어 플렛폼(SW 배포판/운영체제)나 하드웨어 부품 사용

회사에서 시키는 데로 일만 하면 뛰어난 개발자가 될 수 없는 가장 큰 이유는 바로 IT 업체에서 대부분 검증된 소프트웨어 플렛폼(SW 배포판/운영체제)나 하드웨어 부품 사용하기 때문입니다. 

많은 IT 업체는 보수적인 관점으로 제품을 개발하려는 경향이 있어요. 그래서 대부분 이미 시장에 출시된 소프트웨어 플렛폼 혹은 하드웨어 부품을 적용하려고 합니다.

그 이유는 무엇일까요? 바로 돈이 많이 들기 때문이죠. 조금 더 고상하게 말하면 개발비가 많이 들다는 것이죠. 

시장에 출시되지 않은 소프트웨어 플렛폼이나 신규 부품(SoC, 메모리, 센서, etc)을 적용하면 다양한 버그를 만날 가능성이 높습니다. 자 한 가지 예를 들어볼게요? 지금 개발하려는 제품이 리눅스 기반 제품입니다. 그런데 선택할 수 있는 리눅스 커널 버전이 4.19 그리고 5.4가 있습니다. 자, 여러분이 IT 업체의 대표라면 두 버전 중 어떤 걸 선택할까요? 그래도 안정된 버전을 선택하겠죠. 자 그런데 주위 개발자들이 5.4 버전에서 여러 가지 버그가 종종 나온다는 이야기를 합니다. 최신 운영체제 커널이니 말이죠.

실제 저도 최신 리눅스 커널 버전으로 프로젝트를 진행한 적이 있는데요. 예상치 못한  오동작을 겪거나 심각한 버그를 만났습니다. 이런 버그를 해결하려면 분야별로 전문가 레벨에 개발자를 보유하고 있거나 스카우팅을 해야 합니다. 

또한 시장에 검증이 안 된 하드웨어 부품을 개발을 할 때도 마찬가지입니다. 기존에 볼 수 없었던 수많은 버그를 만날 가능성이 높죠.

그런데 아직 시장에 출시되지 않은 SW 플렛폼이나 신규 부품을 개발하면 개발자는 역량을 키울 수 있는 기회를 얻게 됩니다. 여러 가지 다양한 문제를 해결하는 과정에서 자신도 모르게 개발 역량이 증진됩니다. 하지만 IT 업체 입장에서는 개발비가 더 들게 됩니다. 그 이유는 실력 있는 개발자를 뽑거나 기존의 직원을 업그레이드 시키려면 교육도 가끔 보내야 하기 때문이죠.

여러분이 IT 업체에서 전체 개발 비용을 관리하는 매니저라면 어떤 결정을 내리겠습니까? 그 IT 업체의 정책에 따라 결정되겠죠. IT 업체가 그 분야에 “최신 기술을 선도하겠다” 혹은 “최고의 제품을 개발하겠다”라는 미션을 갖고 있다면 좀 더 많은 개발비를 책정할 것입니다. 최신 소프트웨어 플렛폼에서 제품을 개발하거나 최신 하드웨어 부품을 적용할 것이죠.  

음 그런데 현실적으로 보면 안타까운 사실은 바로; 

    * 이런 IT 업체는 극소수입니다.

많은 IT 프로젝트가 수주를 따는 입찰 방식으로 진행됩니다. 수주를 따기 위해서 낮은 가격으로 제품의 가격을 제안하는 경우가 많아요. 그 결과 최적의 개발 비용을 선정하게 됩니다.

리스크 최소화

앞서 말했듯이 대부분 IT 업체들은 보수적인 관점으로 SW 플렛폼이나 하드웨어 부품을 선택합니다. 이런 선택을 하는 이유는 바로 돈(개발 비용) 때문이라고 언급했죠.

이처럼 IT 업체가 이미 검증이 안된  SW 플렛폼이나 하드웨어 부품을 선택하지 않는 이유는 위험(리스크)를 피하기 위해서입니다.

이번에는 하드웨어 부품 관점으로 생각을 해볼까요? 

여러분이 IT 업체의 대표인데 제품의 스팩을  맞추기 위해 최신 하드웨어 부품(SoC/메모리/네트워크 부품)을 적용했다고 가정합시다. 그런데 이 하드웨어 부품(SoC/메모리/네트워크 부품) 시장에서 검증된 적이 없습니다. 하지만 어쩔 수 없이 새로운 하드웨어 부품을 선택할 수밖에 없는 상황입니다.

IT 업체의 대표는 불안해합니다.

    * 이거, 아직 검증된 적이 없는 하드웨어 부품인데. 결함이 있으면 어떡하지?

 

그래서 제품을 개발할 때는 상당히 정교하게 테스트를 돌립니다. 이를 안정화 테스트 혹은 신뢰성 테스트라고 부르기도 해요.보름에서 한 달 이상 연속으로 테스트 스크립트를 돌려서 버그를 검출하는 경우도 있습니다.

그런데 문제는 아무리 정교하게 테스트를 돌리고 한 달 이상 테스트를 해도 다음과 같은 문제를 겪게 된다는 것입니다.

    * 하드웨어 부품의 버그를 검출하지 못한다.

 

새로운 하드웨어 부품의 특성을 제대로 알지 못해 테스크 케이스에 빈 공간이 생기는 것이죠. 가끔은 하드웨어 부품 업체가 자신이 하드웨어 버그를 알고 있어도 감추는 경우도 종종 있습니다.

결국, 이런 결함이 있는 제품이 시장에 출시되면 결국 그 책임은 IT 업체 대표가 지게 됩니다.

한 가지 예를 들어 볼까요? 여러분은 IT 업체의 대표인데 '5G 모뎀 장비'를 개발했다 가정합시다. 5G는 새로운 네트워크 기술이라 신규 RF 부품을 적용할 수밖에 없는 상황입니다. 열심히 테스트를 돌려서 5G 모뎀 장비를 납품이나 출시를 했습니다.

그런데 대형 사고가 터졌습니다.

    * '5G 모뎀 장비'에 있는 RF 부품이 타 버린 것입니다.

 

그런데 '5G 모뎀 장비'가 장비실에 있어서 화재가 발생했다는 뉴스를 전해 듣습니다.

상상만 해도 끔찍하지 않나요? 여러분이 쓰고 있는 휴대폰이나 컴퓨터가 갑자기 타버린다 생각해 봅시다. 

충격 그 자체겠죠. '

이처럼 출시한 제품에서 문제가 생기면 당연히 고객의 클레임으로 이어지고 이 모든 책임은 IT 업체가 져야 하는 상황을 겪습니다. 이 과정에서 IT 업체는 심각한 타격을 입게 되죠. "그 업체의 기술력은 허접하다"란 소문이 돌 수도 있겠죠. 그런데 심하면 IT 업체는 아예 망하는 경우도 생깁니다.

그래서 IT 업체는 신규 SW 플렛폼이나 아직 하드웨어 부품을 적용하려 하지 않습니다.

 

회사의 프로젝트만 개발하면 실력이 정체되는 이유

이번에는 개발자의 입장에서 생각해보겠습니다. IT 업체는 보수적인 관점으로 소프트웨어 플랫폼이나 하드웨어 부품을 적용합니다. 그런데 개발자들은 이미 검증된 소프트웨어나 부품을 재사용하는 프로젝트에 투입될 가능성이 높죠. 물론 이런 유형의 프로젝트에 투입된 개발자는 1~3년 정도 개발하면 스스로 개발 역량이 업그레이드된다고 느낍니다. 고생을 하지만 보람도 느낍니다.

 

하지만 문제는 1~3년까지 개발했던 난이도의 프로젝트를 계속 반복한다는 점입니다. 주니어 레벨에서 전문가 레벨로 실력을 키우려면 그래도 난이도가 높은 프로젝트를 맡을 필요가 있어요. 그런데 이미 검증된 소프트웨어나 하드웨어 부품을 튜닝하는,  고만 고만한 프로젝트만 맡아 보면 당연히 실력이 정체되기 쉽죠. 실력이 더 이상 늘지 않습니다.

여러분 스타크래프트를 처음 했을 때 컴퓨터를 이기기 어려웠을 겁니다. 보통 컴퓨터를 이기려면 한 달에서 3개월 정도가 걸리죠. 아마 이때가 스타크래프트가 제일 재미있다고 느끼는 분들도 있을 겁니다. 자, 드디어 3개월 만에 드디어 컴퓨터를 이겼습니다. 그런데 계속 컴퓨터 하고만 게임을 하면 실력이 늘까요? 아마 그렇지 않을 겁니다. 배틀넷에서 고수 개발자와 게임을 해봐야 실력이 늘 것입니다.

IT 프로젝트의 난이도도 이와 같습니다. 난이도가 낮은 프로젝트를 반복하면 이전에 개발했던 코드를 재활용할 가능성이 높아지죠. 심하게 말하면 기술적으로 '날로 먹는다'라고 말할 수 있겠네요.

 

정리 및 마무리

이제 정리를 해볼까요? 회사에서 시키는 대로만 개발만 하면 개발 능력을 어느 정도 이상 끌어올리는 데 한계가 있습니다. 많은 개발자분들이 사실을 알고 있었으면 좋겠습니다. IT 업체가 보수적으로 소프트웨어를 관리하려 하고 이 결과 이미 검증된 소프트웨어 플렛폼이나 하드웨어 부품을 선택할 가능성이 높습니다. 이미 검증된, 안정화된 상태에서 개발을 하므로 개발자의 실력은 어느 정도 수준에서 정체되는 것이죠. 마치 스타크래프트에서 컴퓨터만 상대하는 것과 비슷하죠.

그런데 너무 환경 탓 회사 탓만 하는 게 아닌지 모르겠습니다만, 현실은 이렇습니다. 

 

 

Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자