솔루션 vs SI vs 서비스

저는 솔루션 회사로 시작해서 SI 회사를 거쳐 지금은 서비스 회사에 재직중입니다. 솔루션이랑 SI 회사는 거의 9년 전후로 다니고 지금은 서비스 회사에 다니면서 느끼는 점들을 정리해 봤습니다. 자신의 분야를 고민하시는 극초년차 또는 진로를 고민하는 전공자 분들은 참고하시면 좋을것 같습니다.

 

솔루션

게임을 CD로 하던 시절입니다. 양말곽 같은데 CD 한장 들어가고 매뉴얼 두권 주는 그런 솔루션인데 CD에는 클라이언트 설치 S/W만 있고 서버는 담당 엔지니어가 설치하는 방식이였습니다. WAS/DB 깔고 SW 설치하고... 이중화 그런건 한 4 ~ 5년 뒤에 얘기나온던 시절입니다(jrun 이라는 was 들어보셨냐요. ㅎㅎ). 그룹웨어 S/W였는데 별별 기능(투표, 사내 공유일 캘린더, 메일, 결재, 게시판 등등)이 다 들어갑니다. 대부분은 쓰지도 않을걸 만들어 넣었습니다... 아 요즘은 흔한 파일 업로드, connection pool 기능도 직접 만들었던 시절입니다.

장점

도메인의 전문성과 기술 베이스가 좋아집니다. 고객보다 더 많이 알아야 하고 다양한 고객들의 사정을 합집합으로 알아야 합니다. 틈틈히 국내외 경쟁사의 기능도 분석해야 하고 그룹웨어의 특성 때문에 그 시절에 개념도 생소한 연동과 규격을 폭넓게 알아둬야 했습니다(LDAP, 문서 중계 개념, XML 기반 오픈 문서, PDF 변환, 엑셀 변환, 메일 규격 등등). 내가 설치/운영하는게 아니다보니 설정 이나 버그 리포팅 기능들도 고려해야 하고 가끔가다 경쟁사 제품 리버스 엔지니어링도 하고, 버전이나 SW별로 OS, DB 등에서의 호환성 테스트도 해야 하고 버전별로 릴리즈노트도 작성해야 하고... 정말 개발한다라는 느낌으로 살았었습니다. 데이터 마이그레이션도 디비 쿼리보다는 어플리케이션으로 만들어 제공했습니다. 

 

일정과 개발방향이 회사 주도로 이뤄 집니다. 솔루션 패치도 여러 고객사의 내용을 듣고 취합해서 우선순위 정하고 일정 정해서 패치 릴리즈 하는 구조였었기 때문에 일정상의 압박이 없어서 하루하루는 괜찮았습니다(정시출근, 정시퇴근, 야근 거의 없음).  야근을 했던게 솔루션 개발 완료 일정이랑 경쟁사 출시 일정 얘기에 달리기 시작하는 이벤트 정도가 있었습니다.

 

회사 차원에서의 장점인데 하나 만들어서 여러군데 판매한다는 점입니다. 나중에 버그 문의 들어왔을때 고객사 얘기를 듣고 우리가 이런데도 납품했었나 싶을정도로 영업쪽에서 알아서 팔고 엔지니어가 알아서 설치하고 쓰는 경우가 많았습니다. 

 

대부분 IT 개발자분들 고객사 분들 만나는거 안좋아하시지요. 고객 만날일도 별로 없습니다. 간혹 고객사가 돈 많이 준다는 명목으로 커스터마이징이라는 이름의 SI를 요구할때 가서 얘기 듣는 경우가 다 였습니다. 그것도 대부분 코어 부분을 건드릴수 없기 때문에 고객사의 레거시와 데이터 연동하는 수준의 개발 부분이였고 고객사도 솔루션의 특성을 알기 때문에 엉뚱한걸 요구하지는 않았습니다.

 

기타 사항으로 제품이 잘팔려서 업계 상위가 되거나 제가 만드는 솔루션을 다른 사람이 알고 있으면 괜히 뿌듯해 집니다.

단점

도메인 중심이다보니 기술면에서는 우물안의 개구리가 되기 쉽습니다. 그리고 솔루션이라는게 하나 개발할때 초기 투자 비용이 높습니다. 그래서 윗선에서는 오랫동안 우려 먹으려고 하니 솔루션의 라이프 사이클이 꽤 길었고 신 기술을 도입하는건 거의 재개발 수준으로 고치는 사안이라 대부분 부결되었습니다. 아마 지금도 솔루션 지향하는 업체들 코드 까보면 예전 방식으로 개발한 업체들 많이 있을겁니다(아직도 이 기술을?). 연차가 점점 늘어날때마다 주변 IT 친구들의 기술 얘기에 불안해 지기 시작합니다. 여기는 이런것도 하는데 난 뭐지? 하면서 기술 도태를 걱정하게 됩니다. 

 

제품 타겟을 잘못 선정해서 실패하는 경우도 많습니다. 간혹 신생 솔루션을 개발할때 고객사 한곳을 타겟으로 잡고 솔루션을 개발한 다음에 그걸 다른 고객사에 적용하는 경우가 있는데 첫번째 고객사의 요구사항이 업계 표준이 아니다보니 거의 재개발 수준으로 손을 본적이 있습니다. 

 

처우도 그닥입니다. 요즘도 그런 느낌이 드는데 국산 솔루션의 인기는 그닥 좋지 않은듯 합니다. 옛날에는 더 했어요. 고객사에서 장비 사면 부록으로 줘야 하는거 아니냐는 얘기도 들어봤습니다. 그러다보면 안팔리거나 싸게 팔리는 경우가 많고 그런 상태에서 개발자의 처우는 좋을리가 없지요. 유지보수 비용으로 근근히 유지를 합니다만, 폭발적으로 시장에서 잘 팔리지 않는 이상 회사가 갑자기 돈을 많이 버는 경우가 거의 없기 때문에 월급 인상도 고만고만 합니다. 또한 시장이 크다고 판단되면 그 비슷한 솔루션 회사가 난립을 하면서 치킨 게임이 시작됩니다. 

 

SI

그렇게 솔루션 회사에서 근 9년 가까이 다니다가 기술 위기, 처우 불만족으로 SI회사로 이직하게 되었습니다. 그리고 나서 또 9년 정도 살게 되었습니다.

장점

이건 그 회사가 수행하는 SI 사업 방향에 따라 차이가 있습니다. 처음에는 모바일 관련 SI 사업만 하다보니 그쪽 전문성만 높아졌었는데 그 이후 돈되는 SI를 다 한다는 형태로 변경되었습니다. 그러다보니 이전 보다 더 많은 기술을 접해 볼수 있었습니다. 주로 대기업 SI를 하다보면 솔루션 개발때보다 더 많은 레거시의 연동과 DB외의 다른 솔루션(redis, kafka 등)을 이용해야 하는 경우가 발생합니다. 고객사에서 요구하는 케이스도 많아지는데 이걸 모른다고 할수 없어서 밤새 공부하고 테스트 해보면서 따라가는 경우가 많았습니다. 따라서 새롭게 판을 다시 짜는것도 용이합니다. 솔루션처럼 라이프 사이클이 긴 것도 아니고 한 프로젝트 끝내고 다음 프로젝트할때 기존 프로젝트에서 잘 구성해 놓은거 가지고 재활용하면서 기존에 못해 본걸 적용하는것도 용이합니다. 

 

대기업의 프로세스와 트렌드를 볼수 있는 점도 장점입니다. 특히 저는 보안 트렌드에 대해서는 대기업이 준비가 잘되어 있다고 생각하고 그걸 배우는게 좋다는 생각을 합니다. 이걸 왜 이렇게 만들어야 하지에 대해 보안 테스트 몇번 해보면 저절로 이해가 가기 시작합니다. 프로세스도 많은 사람들이 효율적으로 움직일때 어떻게 절차를 잡으면 좋을지 참고하기에는 좋은 형태이고 이 부분은 PM을 하게 될때 큰 도움이 됩니다.

 

간혹 한 고객사에 연속적으로 프로젝트를 하게 되면 노하우가 쌓이면서 삶이 편해지는 경우가 많습니다. 신생 업체가 할 경우에 한 달 걸린다면 이쪽은 3주 이하 정도. 그러다가 담당자랑 잘 맞으면 그 회사에 입사하는 경우도 더러 있었습니다(요즘은 중소기업 상생 때문에 인력 땡겨오는게 안되는 대기업도 있다고는 합니다)

단점

이전 글에서도 비슷한 내용을 언급했는데 SI 프로젝트는 고객사가 어디인지 어떤 프로젝트인지에 따라 내가 원하지 않는 방향으로 흘러가는 경우가 많습니다. 대부분 공통점은 고객사가 바라는 일정은 빡빡하고 각기 가지고 있는 프로세스가 있다는 정도? 어떤 곳은 기술 스택을 강제하는 경우가 있습니다. 그러면 저 위에 써놓은 장점은 다 나가리 입니다. 이걸 사전에 알수 있으면 좋을텐데... 대부분 그걸 감지할때는 그 프로젝트에 이름이 올라가서 일을 하고 있을때 입니다.

 

 빡빡한 일정과 맞지 않는 기획 방향에 고뇌하는 경우도 많습니다. 대부분 일정이 순탄치가 않습니다. 고객사 사정(일정, 눈높이)에 따라 갑작스러운 내용 변경, 윗분들 시연 준비, 무리한 일정으로 그냥 돌아가는데 급급한 물건을 만들 경우가 많습니다. 개선? 최적화? 그런건 고객이 해달라고 할때나 할수 있는 일이고 대부분 하자보수 성이라 시간은 많이 주어지지 않습니다. 거의 한번에 기능도 정상, 성능도 어느정도 도는걸 만들어야 '저 친구 일좀 하네?' 소리를 듣게 됩니다(거의 준 슈퍼맨급). 대신 그 이후로는 골치아픈일들이 자기한테 몰리는 느낌이 들기 시작합니다. 반면 여유로운 모습을 보이면 PM의 마음의 소리를 듣게 됩니다. '잰 일이 없나봐? 다른애 업무좀 넘길까?' 

 

기획 부분도 불만족 스러운 부분이 많습니다. 문서를 보고나서 이런 생각이 듭니다. '왜 이렇게 만들어야 하지? 이걸 서버가 버틸수 있을까? 이걸 왜 여기에 다 때려박지?' 라고 이해하기 어려운 기획서에 기획팀과 얘기해도 씨도 안먹히는 경우가 많습니다. 고객사에서 컨펌했는데? 기획회의때 왜 얘기안했어? 이거 바꾸면 일정 틀어지는데? 이 압박에 포기하고 IDE를 열어 돌기만 하면 되는 결과물을 만드는 경우가 많습니다. 그런 프로젝트를 반복하게 되면 저 기획자랑 일 못하겠어요 라는 얘기가 나오거나 그냥 고민안하고 기계처럼 코딩을 하는 자신을 발견하게 됩니다.

 

파견도 빼놓을수 없지요. 대부분의 대기업 프로젝트는 파견이 많습니다. 갑자기 PM이나 팀장이 와서 다음주부터 저 프로젝트에 투입되어야 한다. 라는 얘기를 들으면 퇴근하고 운동하려고 헬스장 끊어 놓은거, 자기개발때문에 어학학원 끊어 놓은거, 거기가 집까지 거리가 회사 대비해서 얼마나 늘어나는지에 대해 고민이 되기 시작합니다.  그런거 없다고 하더라도 결혼하셔서 육아 하시는분들은 부담이 되기 시작합니다. 프로젝트들이 안좋게 돌아가는 경우 야근/주말 출근각이 확정이니까요(요즘은 많이 줄었다고는 들었습니다) 

 

다 그렇지는 않지만 고객사 갑질도 만만치 않습니다. 제가 경험한 프로젝트의 반 이상? 생떼를 쓰는 고객사 담당자 때문에 밥보다 술을 더 많이 먹었던것 같습니다. 이게 사람대 사람의 일 인지라 못버티는 개발자들도 많더군요.

 

이렇게 쓰고 나니 장점보다 단점이 많군요. 이 단점때문에 개발 결과물의 퀄리티가 떨어지고 애착이 없어지기 마련입니다.

서비스

그렇게 살다가 제안을 받아서 서비스 회사로 가게 되었습니다. SI와는 또 다른 세상이더군요.

 

장점

자기 물건이라는 애착이 생기게 됩니다(나만 그런가?) 경쟁 서비스를 보면서 개선사항을 고민하고 사용자 유입량과 사용량을 보면서 이 서비스가 잘되가고 있다는걸 느끼게 되면 기분이 좋아집니다. 그 다음걸 만들기 위한 기술검토나 트렌드 파악에 시간을 들이고 있으면 SI보다 좋다는 생각도 하게 됩니다. 칭찬은 고래도 춤추게 한다라는 말이 있지요. 본인의 서비스가 잘되게 되면 조직 분위기도 좋아지고 사람들이 적극적으로 일하게 되서 사무실 분위기는 좋아 집니다(개인 주관의 생각일지도?)

 

일정/기능에 대해 조율하는것도 수월해 집니다. 어설픈 기능 만들어서 폭망하는니 시간이 좀 걸리더라도 잘 만들어 내자는 분위기도 생성되고 일단 만들고 간을 보자는 형태로 데브옵스도 발생하게 되는데 목표는 확실합니다. 이전 SI처럼 본 기능보다 고객사의 프로세스를 위한 부가 기능을 만드는데 더 치중할 일도 없어서 기능 본연에 집중하게 됩니다.

 

단점

SI때 언급한거랑 비슷한데 PO/기획 잘못 만나면 내가봐도 영 아닌 걸 만드는 경우가 허다합니다. 세상은 넓고 다양한 생각들은 가진 사람들이 많다보니 기능 필요성이나 방향에 대해서도 생각이 제각기 입니다. 뭐 그걸 틀렸다고 보기에도 애매하고... 일단 결과는 고객이 얼마나 쓰느냐로 판단을 할수 밖에 없습니다. 

 

장점이자 단점일수 있겠네요. 잘되면 대박, 못되면 쪽박 입니다. 거기에 몰빵한 업체면 못될때 그렇게 오래 버티질 못합니다. 어느날 월요일 아침에 출근하니 서비스 접자라는 얘기가 나오는 경우도 있었습니다. 그러면서 인원 정리에 들어가게 되면 내가 뭘 잘못했는데 이렇게 된걸까 하는 생각이 들게 됩니다. 자금력 없는 업체에서 서비스 쪽박은 그냥 망하는 거라고 보시면 됩니다. 그걸 탈피하기 위해 SI로 사업전환을 하기도 합니다.  

 

초기 투자 비용도 넉넉하진 않습니다. 그러다보니 가성비 좋고 빠른 개발을 요구하는 경우가 많습니다. 이거 이때 오픈 못하면 망한다라는 PO의 압박도 많습니다. 그러다보니 잘되면야 이런저런 기술도 더 붙일수 있는데 그건 잘 되었을때 얘기고, 초기에는 대부분 기능 위주의 간단한 구조, 저렴한 인프라로 시작하는 경우가 많습니다. 더러 스타트업 계열에서는 개발속도가 빠른 nodejs로 시작하는 곳들도 많이 봤습니다. 아이디어로 승부하는 서비스들은 의외로 그 내부가 단촐한 경우가 많습니다. 

 

제 견해는..

그동안을 회고해보면 개발자 인생 초기에는 경험치를 쌓는데 집중하는게 좋을것 같습니다. 그게 어느 분야가 되었건 갈라파고스 형태로 사는 곳만 피하면 되지 않을까... 대부분의 기술 트렌드나 시장은 평생가는게 없고 그 라이프 사이클도 점점 짧아 지는데 트렌드를 쫓아갈수 있는건 경험에서 쌓은 노하우를 통한 빠른 적응이 답이 아닐까요? 또한 어느 정도 경험치가 쌓여야 자신의 적성에 맞는게 어떤건지 찾을수 있을거라고 생각합니다. 위에 SI파견이 단점이라고 언급하긴 했습니다만 나이 좀 지긋하신 개발자 분중에 그걸 즐기시는 분도 본적 있습니다(한곳에 있는게 식상하고 여기저기 새로운걸 보고 싶다나...). ㅎㅎ.

 

최근 개발자 사이트에 보면 SI는 지옥, 인생은 서비스 회사에서 시작해야 한다라는 개발 진로 관련 글을 많이 봤습니다만, 소리소문 없이 사장되는 서비스도 많이 보고 밑에 팀원들의 전직장 서비스 회사 생활기를 들어보면 서비스 회사에 대한 장미빛 시선은 걱정스럽습니다.