brunch

개발자의 일, 회사의 일

IT 개발회사가 굴러가는 방식

by 동그리

"하아, 나도 개발자나 할까?"

첫 회사인 IT 보안 솔루션 회사에서 근무하던중에 한 시스템 엔지니어(SE)에게 들은 말이다.

유지보수중인 고객사에 출장을 다녀와서 사무실에서 코딩하던 나를 물끄러미 보더니 한 말이다.

밖에서 힘든 일이 있었나 보다. 당시 나는 그 정도 인식 밖에 없었다.


당시는 클라우드 환경은 존재하지 않았고, 다양한 필요에 의해서 인터넷 데이터센터(IDC)가 만들어졌다.

그 중에 정보보안을 위해 투자를 할 여력이 있는 전산실을 운용하는 곳은 공공기관, 대기업, 대학 정도였다.

전산실 빼곡히 서버렉, 네트워크 장비가 설치되고 그 한켠에 정보보호 솔루션 장비도 설치된다.

이러한 전산실 유지관리를 위해 네트워크 및 정보보호 엔지니어도 상주한다.


내가 소속되어있던 회사는 이러한 기관에 네트워크 장비, 정보보호 솔루션 장비를 납품하고, 엔지니어를 파견하는 회사였다.

대부분은 출장 형태로 유지관리를 했지만 드물게 상주를 하는 사람도 있었다.


'한강이남의 최고의 보안 회사를 만들겠다'

단지 장비 납품을 주로 하는데 그치지 않고, 정보보호 연구소를 만들어 개발자를 채용한것은 여기 대표의 야무진 꿈이 있었기 때문이지 않을까.

회사에서 주로 취급하던 제품이 주니퍼 등 외산제품이어서 아무래도 국내 실정에 맞지 않는 부분들이 있었다.

그래서 나의 업무는 고객요구에 대한 솔루션이나 연구과제를 위한 프로그램 개발이었다.


장비 납품, 유지관리 등 회사의 주요 비즈니스에 해당하는 역할은 모두 시스템 엔지니어가 했다.

어쩌면 영업 역할까지 도맡아 했을지도 모르겠다. 기술영업으로서의 역량도 필요했었던것으로 기억한다.

그들이 무슨일을 하는지 몰랐던 입사 초기에는 택배 직원인줄 알았을 정도로 제품을 들고 출장가는 일이 많았다.

그에 비해서 연구소 소속 개발자는 사무실에서 개발만 했다. 그 어떤 실적 압박을 받는것으로 보이지도 않는다.

밖에 나가서 제품과 서비스를 고객에게 전달하는 직군에서는 개발자를 부러워 할만 하지 않았을까.


연구소 입장에서도 변명은 있다. 턱 밑까지 차오른 물 위로 숨쉬듯 내 한몸 건사하기 힘들었다.

겨우 겨우 목표로한 개발 일정에 따라 소프트웨어 개발을 하는것이 내가 회사에서 월급받는 의미였다.

학원에서 배운 얄팍한 코딩 지식만 가지고는 보안 솔루션을 개발하는데 턱없이 부족해서 공부를 많이해야했다.


당연히 정시퇴근은 꿈도 꾸지 못했다. 많은 시행착오를 거치며 피로에 쩔어갔다.

회사에서 먹는 저녁은 당연한 일상의 하나로 자리잡았다.

그렇게 고생끝에 프로그램을 만들어도 시장성이 없거나 목표 설정이 잘못되어 폐기되기를 반복했다.

리더나 사수없이 그저 눈앞의 코딩을 할 뿐이었던 주니어 개발자 시절의 내 모습이다.

나의 시작은 실패로 가득했다.


지방 중소기업은 적합한 인재를 구하기 힘들다.

그래서 많은게 부족한 나도 취업해서 개발자 생활을 할 수 있었다.

그 때로부터 세월이 15년 가까이 흘렀다. 많은것이 바뀌었을것 같지만 사실 별로 달라진게 없다.


이제 그리 가볍지 않은 경력이지만 아직 많은 면에서 부족하고 부끄러운 자신과 마주하며 개발을 하고 있다.

그리고 내가 아는한 소프트웨어 개발 현장의 사정도 그리 달라지지 않았다.

세상을 살면서 한가지 깨달은건 '사람사는거 다 똑같다'는 단순한 진리뿐이다.


내가 IT에 입문했을때도 배울게 많았고 젊은 혈기로 많은 기술들을 배워 나갔다.

어느정도 세월이 지난 지금도 내게는 낯선, 많은 기술들이 수십개씩 쏟아진다.


주니어 개발자였을때 보다 책임지거나 신경쓸 이슈는 더 많아졌다.

프로젝트, 인프라, 사업 관련 회의를 하거나 문서를 쓰려면 알아야 할게 많아진다.

AI가 폭발적으로 성장하면서 데이터 리터러시(Data Literacy)도 갖춰야한다.


배워야할게 산더미다. 이제는 솔직히 좀 지친다.

머리 용량이 부족한게 느껴져서 이제는 더 이상 새로운걸 배우고 싶지 않다.

레거시(Legacy)를 무작정 비난하고 새로운 기술을 적극적으로 도입하려했던 내가 부끄러워진다.

'개발자는 평생 배워야 하는 직업이다.'라는 말이 과거에는 도전이라면 지금은 부담으로 다가온다.

벌써부터 힘에 부치는데 지금과 같은 속도로 IT가 발전한다면 세월이 더 흐른뒤에도 포기하지 않을 수 있을까?


모든 직업에는 표면적으로 보이는 이미지와는 다른 이면이 존재한다.

그러나 대부분 대외적인 얕은 이미지만 보고 직업을 결정하는 경우가 많다.

흔히 말하는 '네카라쿠배'와 같은 성공적인 기업들을 선망하며 개발자를 희망하지만 이내 현실과 마주하게 된다.

물론 시스템 엔지니어도 나름의 고충이 있을것이다. 같은 입장에 있어본적이 없으니 이해한다는 말은 하지 않겠다.

내가 힘들때는 상대의 힘든점을 헤아리기 어렵다. 조직이 크고 직군이 다양할수록 그 정도는 심화된다.


회사에는 다양한 일이 있다. 회사마다 사정은 다르기에 모든걸 나열할 수는 없지만 크게 2가지로 나뉜다.

회사가 돈을 버는데 직접적인 영향을 주는 일, 그리고 회사를 유지하는데서 파생되는 일이다.

IT 개발회사에서 소프트웨어 개발이란 돈을 버는 일이다.

고객이 필요한 소프트웨어가 있고 이것을 개발 및 서비스해서 고객에게 가치를 전달한다.


많은 소프트웨어 개발사는 SI 아웃소싱 비즈니스에 의존해서 먹고산다.

서비스나 솔루션 개발이 성장 잠재력은 크지만 무작정 시작해서 성공하기는 쉽지 않기 때문이다.

그만큼 불특정 다수의 고객의 선택을 받기가 어렵고, 시장을 만들고 확장하기가 쉽지 않다.


그에 비해 SI 사업은 고객과 보상이 명확하다.

고객이 필요한 정보시스템(IS)에 대한 요구사항을 정리해서 사업을 만들고 공모한다.

경쟁 입찰을 해서 다양한 평가 항목에서 최고점수를 받은 기업이 선정되어 사업을 수주하고 개발을 진행한다.

소프트웨어 개발에 대한 보상은 제안사가 사업을 수주할 당시에 제안한 금액을 온전히 보상 받는다.


요즘 위시켓 등 프리랜서 플랫폼에서 고객이 프로젝트 개요를 올려놓으면 금액과 함께 제안하는 식이다.

고객의 프로젝트 목적에 가까운 포트폴리오를 쌓고, 신뢰를 줄 수 있다면 규모는 관계 없다.

기업의 SI 제안과 다른점은 제안서를 쓰거나, 경쟁 발표를 하거나 하지 않는다는것 정도일까.


고객의 선택만 받을 수 있다면 도전할 수 있는 조건이 공평한셈이다.

하지만 사업에 대해 제안서를 쓰고, 기업 평가를 받으며, 제안 발표를 하는 등 다양한 과정을 거치는게 어렵다.

기업 자체가 자격을 갖추지 못했거나 경쟁 우위에 선 기업들을 이길 수 없다면 일을 하고 싶어도 할 수 없다.

그래서 보통 중소 SI개발사는 삼O, 농O 등 사업 수주율이 높은 대기업 SI 기업 밑으로 하도급으로 들어간다.


소프트웨어 산업도 긴 시간이 걸리고 비용이 많이 든다는 점에서 건설업의 시스템을 차용해왔다.

그래서 SI를 주로 하는 작은 개발사의 근무환경은 건설업 하도급에서 병 또는 정 단계의 환경과 빼다박았다.

많은 취업 준비생에게 기피대상이 되는 '중소 SI개발사'는 이런곳이다.


직접 고객에게 소프트웨어 개발사업에 대한 제안을 하지 않았으니 다른 기업이나 고객에게 끌려다닐 뿐이다.

인력은 제공하지만 사업에 대한 그 어떤 주도권도 없기 때문에 기계적으로 업무를 수행 할 수 밖에 없다.

회사 업력은 늘어나도 일에 대한 전문성은 쌓이지 않는다.

당연히 구성원인 개발자에 대한 케어나 성장은 꿈도 못 꿀일이다.


핵심인력은 어디든 부족하기 때문에 돌려막기를 한다.

그런데 단가 책정 기준이 투입되는 인력의 '소프트웨어 기술자 등급'을 기준으로 투입기간으로 계산된다.

핵심인력이 없다고 자리를 비워놓으면 고객에게 투입단가 관련 이의제기를 받을 수 있다.

그래서 투입 단가를 맞추기 위해서 등급에 맞지 않는 인력을 허위로 투입하는 일이 생긴다.

이것이 입사했는데 '자리에 앉아만 있으라'라는 SI 개발사의 사정이다.


위의 사례는 SI 개발 업계에 퍼져있는 안좋은 관습중 하나일 뿐이다.

모든 일의 장점과 단점은 비즈니스에서 오기 때문에, 기업의 잘못만으로 돌리기에는 억울할 수 있다.

기업들의 현실적인 사정과 고객의 무리한 요구를 맞기 위한 노력 끝에 정착한 문화가 이렇게 된것 뿐이다.

돌고돌아 피해는 결국 소프트웨어가 필요한 전체 고객에게 돌아간다.


요즘은 이런 문제를 최소화 하기 위해 사업을 발주할때 다양한 제한을 둔다.

하도급을 몇단계 이하로 제한하거나 금지, 견적 증빙을 기술자 투입 단가가 아닌 기능점수(FP)로 하는 등이다.

결과적으로 사업을 수주한 기업에서 책임 시공하도록 한것이다.


이러한 변화가 향후 어떤 결과를 낳을지는 알 수 없지만, 개발자의 처우와 근로환경에 영향을 미칠것은 확실하다.

무엇보다 공장식으로 비슷한 코드만 찍어내던 '전문성 없는' 개발자는 설곳이 점점 줄어들것이다.

사업 내용에 맞는 소프트웨어 감리를 거쳐야하며, 그 기준은 날이 갈수록 높아져 가고 있기 때문이다.

그 기준을 맞추기 위한 개발자 능력수준은 코딩 능력이 전부가 아니다.


개발자의 일은 회사의 일에 따라 간다.

비즈니스 환경에서 오는 어려움을 온전히 개발자가 지게 한다면 일의 품질은 떨어질 수 밖에 없을것이다.

반대로 회사의 품질도 개발자 개개인의 일의 품질에 따라간다는 사실을 기억하자.

자신의 자리에서 최선을 다 했을때, 언젠가 세상은 그 노고를 알아줄것이다.


keyword
이전 05화우리는 모두 서비스직이다