SI회사에 입사하기 전 읽으면 좋은 글 - SI의 단점

 이 글은 제가 SI회사를 다니며 겪은 일을 기반으로 작성 된 매우 주관적인 글입니다. SI업계를 곡해하기 위한 글이 아니며, SI업계를 바라보는 여러가지 시선 중 하나 일 뿐입니다.

용어 정리

SI: System Integration의 줄임말. 전산시스템을 필요로 하는 곳으로부터 하청을 받아, 시스템의 기획, 개발, 유지보수, 운영 등을 대신 해주는 업종이다.

Waterfall: 순차적인 소프트웨어 개발 프로세스를 뜻한다. 자세한 것은 여기를 확인.

갑: SI프로젝트를 발주하는 회사. 주로 ‘발주사' 또는 ‘고객사'로 불린다.

을: SI프로젝트를 수주하는 회사. 큰 규모의 SI업체(삼성SDS, LG CNS, SK C&C 등)가 주로 해당되며, ‘수행사'라고 불린다.

이전 글에서 이어집니다.

단점1 - Waterfall 방법론의 문제점

 SI프로젝트는 폭포수 방법론의 단점을 그대로 답습한다. 갑은 본격적으로 개발이 시작되기 전까지 요구사항을 제대로 내놓지 못한다. 실체가 없는 상태에서 요구사항을 내는 것은 매우 힘든 일인데, 심지어 갑은 제대로 준비를 안해온다. 현행 시스템(AS-IS)에서 딱히 바꿔야할 이유를 찾지 못하는 것 같았다. 즉, 프로젝트에 동기부여가 전혀 안되어있다는 뜻이다.

  Waterfall의 구조적 문제, 그리고 갑의 준비 미흡으로 을은 분석/설계 단계 때 제대로 요구사항을 정의하지 못한다. 그러다가 개발단계에 와서야 요구사항이 수시로 바뀌기 시작한다. 그렇다고해서 시스템 오픈일자가 변경되지 않는다. 결국, 프로젝트의 구조적 문제를 을과 을의 협력사에 소속된 개발자(병정무..)들이 뒤집어 쓰는 구조이다. 더 큰 문제는 여기서 하는 일이 개발자의 기술적 성장에 큰 도움이 되지 않는다는 것이다.

단점2 - 제한된 개발자의 역할

 인건비만 수백억이 들어가는 큰 프로젝트를 정해놓은 시간에 맞추어 완성하는 것은 정말 어렵다. 게다가 대부분 외주 개발자로 구성된 인력으로 완성하는 것은 더 어렵다. 그렇다보니 거의 모든 SI 프로젝트는 매우 보수적으로 신기술을 적용한다. 그리고 기술 표준을 통일하고 엄격하게 제어하는 편이다. 개발자가 기술적인 부분을 전혀 신경쓰지 못하게 한다. (보통 이러한 것들을 담당하는 사람을 ‘아키택트’)라고 한다.

 그렇다면 개발자는 뭘 하느냐? 비즈니스 로직을 구현하는데만 집중한다. 그러다보니 if-else, for, while 정도의 문법만 알아도 일하는데 전혀 지장이 없다. 각종 IT 학원에서 3~6개월만 수업을 듣고 취업할 수 있는 비밀이 여기에 있다. 기술적인 진입 장벽이 낮다는 것은 거꾸로 얘기하면 기술적으로 성장하기에 매우 어렵다는 뜻이다.

단점3 - 기술을 경시하는 분위기

 외주받아 일하는 을과 그들의 협력사는 ‘납기준수'에만 집중하게 된다. 그래서 대부분의 SI 개발자들은 ‘할당량의 완성'에만 집중한다. 유지보수는 본인의 몫이 아니니까. 게다가 갑은 이러한 ‘도덕적 해이'를 단속할 능력이 전혀 없다. 여태까지 외주로만 해결했고, 결과만 확인했으니까. 

 이러한 이유로 사람들이 ‘제조업 마인드'를 갖게된다. '제조업 마인드'가 나쁜 것이 아니다. 하지만 소프트웨어 개발자와 관리자에게는 매우 나쁘다. 관리자의 관리 포인트는 '개발자가 얼마나 효율적으로 일하는가?' 보다는 '몇 명의 개발자가 일하는가?'가 된다. 건설업에서 쓰이는 ‘단가', ‘공수', ‘납기' 라는 용어가 자연스럽게 쓰인다. 

 가장 큰 문제는 소프트웨어의 동작 과정에는 상대적으로 덜 신경쓴다는 것이다. 오로지 소프트웨어가 예상했던 동작을 하는지에만 초점을 맞춘 테스트가 진행된다. 더 깔끔하고, 효율적인 소스코드를 만들기 위한 노력은 거의 하지 않는다. 나 혼자서라도 효율적인 소스코드를 만들기 위해 노력한 적이 있었는데, 관리자가 그런 나를 보더니 “너가 지금 일이 적구나.”라는 식의 이야기를 들은 적도 있다. 이런 분위기에서 기술역량을 신장할 수 있을까?

단점4 - 열악한 근무환경

  짧으면 6개월에서 길면 3년 정도 프로젝트가 진행되는데, 갑은 외주 직원에게 안락한 사무실을 제공할 리가 없다. 게다가 을의 입장에서도 한푼이라도 더 아껴서 개발자를 더 뽑는 것이 낫다는 마인드를 갖고 있어서, 이른바 ‘닭장'에서 근무를 하게 된다. 사내 카페, 휴식공간은 언감생심. 다닥다닥 붙어서 일하다 보니, 컴퓨터와 사람이 내뿜는 열기에 사무실은 항상 덥고 건조하다.(내가 근무하던 곳은 11월까지 에어컨을 틀었다.) 환절기마다 감기를 달고 사는건 기본이다.

 내가 경험한 프로젝트의 경우엔 한정된 공간에 너무 많은 사람을 넣다보니, 화장실이 미어터졌다. 약 200명이 근무하는데(대부분 남자) 화장실이 3칸이었다. 물론 화장실이 작은게 아니고 사무실에 책상을 정원 이상으로 과하게 넣은거다.

SI프로젝트의 사무실 전경. 이정도면 진짜 양호한거다. 앞뒤 간격이 꽤 널널하니까...

사진 출처: http://www.ddaily.co.kr/news/article.html?no=154681

단점5 - 업무에 방해가 될 정도의 보안

 정말 많은 보안프로그램을 설치해야한다. 보안프로그램이 램을 잔뜩 잡아먹으니 업무가 잘 안되는 것은 당연하다. 더 큰 문제는 보안프로그램이 호환되어야 하므로, 윈도우7 32bit가 강제된다.(최근 64bit도 허용하는 추세) 내가 경험한 프로젝트에서는 보안 프로그램이 너무 많아 Idle상태에서도 2.9기가바이트를 잡아먹었다. 32bit면 RAM 4기가바이트가 한계인데.. 

단점6 - 문서작업이 너무 많다.

 업무에 있어서 문서는 매우 중요하다. 이 사실을 잘 이해하고 있지만 SI 프로젝트는 문서가 너무 많다. 비유를 하자면  ‘내가 지금 딴짓을 하지 않고 열심히 일하고 있습니다~’ 를 문서로 일일이 증명하는 느낌이다. 다시 말하면 어차피 나중에 안찾아볼 1회성 문서가 대부분이다. 나는 단위테스트를 성공했다는 콘솔 덤프를 첨부하는 문서를 작성할 때 자괴감이 많이 들었던 것 같다. 그래도 어쩌겠는가. 갑은 그 문서를 받아봐야만 안심하는데.

단점7 - 대한민국 특유의 갑질 문화

 SI 프로젝트에서 워낙 광범위하게 작용하는 단점이라서 딱히 설명할 길이 없다. 일부 대한민국 국민들은 “내가 서비스에 대한 금전을 지불했다는 것"을 이유로 서비스 제공자에게 지불한 것 이상의 서비스를 요구한다. SI 프로젝트에서도 마찬가지다. 할당량을 채우지 못했다는 빌미로 추가근무를 종용하는 것은 기본이다. 당연히 수당은 한푼도 없다.

단점8 - 이러한 단점들을 고칠 생각이 없다.

 위와 같은 단점들은 대한민국 SI의 기형적인 구조에서 기인한다. 갑은 IT개발자를 직접 고용하는 것을 꺼린다. ‘기술은 당연히 외주를 줘야지'라고 생각한다. 을은 오로지 ‘더 낮은 발주 비용'을 무기로 다른 을과 경쟁한다. 어차피 경쟁 업체도 비슷한 결과물을 만들 것이고, 해당 시스템의 미래와 성장 방향에 대해서는 전혀 관심이 없기 때문이다. 이렇게 품질을 기반으로 한 경쟁이 억제된다. 최종 상품을 만들어 시장의 선택을 받는 경쟁이 사라지고, 시스템 기획부터 완성까지의 원청 vs 하청 관계에 의존적인 사업이 된다.

 문재인 정부가 들어서면서 52시간 근무제도가 법제화 되었다. 아니나 다를까 IT서비스 업계에서는 52시간 근무 특례업종지정을 요청했다. (관련 기사) 무조건 낮은 비용으로 수주해서 부족한 비용은 개발자의 공짜 야/특근으로 메꾸다가, 발등에 불이 떨어지니 ‘업계 특성'을 부르짖는 저열한 모습을 보여줬다고 생각한다.

 내가 생각했을 때, SI 개발자는 기술역량 향상을 통한 커리어 개발에 적합하지 않은 직업이다. 게다가 SI는 근무 환경도 좋지 못하고, 고객을 상대해야한다는 점도 나와 맞지 않았다. 간단하게 얘기하면 실력도 안늘고 워라벨도 별로였다. (내가 열정과 참을성이 부족한 것일수도 있다.) 내가 이런 분위기를 바꾸면 좋겠지만, 주니어 개발자 한명이 대한민국 SI를 바꾸기엔 너무 버겁더라.

-끝-