[SI산업 가이드북③] 갑은 SI 프로젝트를 어떻게 만들까?

[IT 입문자를 위한 SI 산업 가이드북①] SI 회사는 가면 안되나요?

[IT 입문자를 위한 SI 산업 가이드북②] 스타트업, SI를 해도 되나요?

[IT 입문자를 위한 SI 산업 가이드북③] 갑은 SI 프로젝트를 어떻게 만들까?

2016년, 카카오톡으로 돈을 보낼 수 있는 세상이 왔습니다.

‘엇, 이건 그동안 없던 개념인데?’

‘이런 아이디어는 도대체 누가 낸 거지?’

‘그리고 누가 만든 거지?’

은행 전산팀 기획자가 물어봅니다.

A은행 : “혹시 그거 어느 업체가 했어요?”

카카오뱅크   : “네? 이거, 우리가 개발했는데요.”

A은행 : “에이, 그래도 전부 다 개발하진 않았을 거잖아요. 누군가 도와줬을 거잖아요.”

카카오뱅크   : “아니요, 이거 처음부터 끝까지 우리가 직접 기획하고 개발한 거예요.”

A은행 : “...”

※ 이 사례는 코어뱅킹 위에 올라간 서비스 이야기였는데, 당시 카카오뱅크 개발자와의 대화를 각색했습니다. 참고로 카카오뱅크의 코어뱅킹은 모 은행의 것을 이식했고, LG CNS가 이를 담당했습니다.

A 은행 담당자는 당연히 SI업체가 개발했을 거라 생각했습니다. 은행 역사상 내부 개발팀을 데리고 있었던 적이 없거든요. 이때까지 은행이 생각한 IT는 수작업을 자동화하는 거였지, 새로운 비즈니스를 만들어내는 건 아니었죠. IT를 바라보는 관점이 아예 달랐던 겁니다.

그런데 이런 건 SI로 할 수 없습니다. 남의 일을 해주는 거라 정확한 “요구사항”이 없으면 업무량이나 일정을 세울 수 없었거든요. 이 경우 도움을 줄 “개발방법론”도 없었습니다. 고객이 하려는 것은 새로운 비즈니스라 어떻게 될지 모르기 때문입니다.

“요구사항”이 두루뭉술하고 개발량도 예측되지 않습니다. 예산도 세울 수도 없고 중간에 여러 번 뒤집힐 수도 있었죠. 이런 일을 SI 기업한테  맡기면 악성 프로젝트로 취급받을 수밖에 없습니다.

“갑”들은 프로젝트 관점을 바꿀 수밖에 없게 되었고, SI 기업도 크게 영향을 받습니다. 이런 “IT 프로젝트의 성격변화”는 “일하는 방법의 변화”로 이어졌고, 뚜렷한 해답을 찾지 못한 SI 기업들의 어려움으로 이어졌습니다.

이번 회차에서는 초보 SI 회사의 이해를 돕기 위해 기존 SI 프로젝트가 어떤 흐름에서 만들어지고 어떻게 진행되게 되는지, 발주자의 관점에서 전체 흐름을 정리해 보겠습니다. 이에 더해 최근의 SI 프로젝트는 왜 이전과 같지 않은지, 왜 이전과 같은 방법론과 관점이 통하지 않게 됐는지 시대적 흐름을 개괄적으로 살펴보겠습니다.

작은 회사들은 프로젝트 절차가 또렷하지 않고 흐릿하기도 합니다. 설명하기 힘드니까 조금 큰 기업으로 설명을 해봅니다. 비교적 발주를 꾸준히 하고 있는 은행을 예로 들어 봅니다. 이것도 산업마다 다르지만 대충 이렇구나 생각하면 됩니다.

1.0 만들기

A사가 새로운 사업을 시작하려고 합니다.

당연히 현재는 없는 시스템이니, 맨땅에서부터 새롭게 만들어야 합니다. 그래서 “신규 구축사업”이라고 부릅니다. 여기선 구분하기 좋게 “1.0 만들기”라고 해보겠습니다.

먼저 어떻게 돈을 벌지 그림을 그립니다. “사업기획”입니다.

은행에서 “보험”을 팔고 싶어 합니다. (이미 은행에서 팔고 있습니다.) 이 단계에선 어디 보험사의 제품을 어떻게 팔지 결정합니다. 수수료율을 정하고 수익률을 정합니다. 그리고 사업을 할지 말지 결정합니다.

그다음 서비스를 어떻게 제공할지 기획합니다. 

누가 어디서 보험 가입을 받을지, 실명 확인은 어떻게 할지, 취소와 환불은 어떻게 해야 할지 등등을 결정합니다. 부서별로 할 일과 인력 계획이 나옵니다. 비로소 비용의 일부가 나옵니다.

자 이젠 시스템이 있어야 합니다. 

어떤 시스템을 만들어야 할지 그림을 그립니다. “시스템 기획”입니다.

앱을 만들지 말지, 서버는 몇 대나 필요한지, 기존 시스템은 어떻게 연동할지 등을 그립니다.

업무량이 예측되고 예산이 나옵니다. 비로소 투자비용이 나오고 손익이 나옵니다.

이제야 사업 계획을 보고합니다.

위로부터 사업 진행 허가가 떨어지면 일을 할 전문 업체를 구합니다.

만들어야 할 “개발항목”들을 나열합니다. “입찰공고”를 띄우고 일할 업체를 선정합니다. 믿을 만한 업체, 좋은 업체가 지원했다면 다행이겠지만 아니라면 다시 공고를 합니다.

“시스템 구현”. 

이때부터 SI 기업들이 하는 일입니다. “분석 - 설계 - 개발 - 구현”으로 이어지는 일반적인 개발과정입니다. “애자일”도 있는데, 이 이야기는 나중에 길게 하겠습니다.

“서비스 오픈”.

이제 보험상품을 팔아야 합니다. 오픈 전에 업무팀을 창구에 배치합니다. 직원들 교육도 시키고  앱 기능이 제대로 동작하는지도 살펴봐야 합니다. 기타 등등 고객 입장에선 이제부터 업무 시작입니다. 아주 긴장된 순간입니다.

반면 SI 기업들은 여기에서 “프로젝트”가 끝납니다. 시스템을 은행에 넘겨주고, 자기 회사로 돌아갑니다. 아주 홀가분해지죠.

※ 여기서 “서비스”란, 고객이 돈을 지불할 수 있게 제공되는 무형의 가치상품을 말합니다. “쿠팡” 같은 대형서비스도 있고, “지식iN”, “토정비결” 같은 작은 서비스도 있습니다.

서비스 운영

사업이 돌아가면 돈을 벌기 시작합니다. 예상한 대로 업무팀과 시스템이 동작한다는 뜻입니다. 고객 민원이 생깁니다. 창구 직원들도 어려움이 생깁니다. 새로운 기능이 필요해집니다. 내부 개발팀이 있다면 그때그때 개발할 수 있습니다. 아니라면 모아둬야 합니다.

어떤 서비스는 새로운 기능을 자주 추가하기도 합니다. 1년 내내 뭔가 해야 하니 상시 개발팀을 만들 수밖에 없습니다. 간혹 일거리가 많아지기도 합니다. 그럴 땐 프리랜서를 고용합니다.

어떤 회사는 운영을 아웃소싱하기도 합니다. 하지만 일 크기가 작아 금액도 작습니다. 큰 문제는 여전히 해결 못합니다. 그대로 쌓아둡니다.

간혹 운영 때문에 SI 회사에 인력 파견을 요청하기도 합니다. 옛날에는 해주는 회사가 많았습니다. 요즘에는 찾아보기 힘듭니다. 회사에 노하우가 쌓이지 않고 직원 관리가 안 되기  때문입니다. 갈수록 찾아보기 힘들 것 같습니다.

“서비스 운영”은 생각보다 여유가 없습니다. 사업 속도 때문에 개발팀 사정을 봐주진 않습니다. 예를 들어 신학기 이벤트를 하려 합니다. 웹 사이트가 준비되지 않았다고 일정을 늦추진 않습니다. 일단 판매를 시작합니다.

일관리, 고객관리 경험이 없는 초보 개발자에겐 이 일을 권하고 싶지 않습니다. 몸과 마음이 망가집니다.

2.0 만들기

이거 안돼요. 저거 안돼요.
이거 되게 해주세요. 저거 되게 해주세요.

사업이 잘 되면 이용자들의 요구사항이 쌓입니다. 사업이 잘 될수록 더 빨리 더 많이 쌓입니다. 1년 정도 지나면 시스템을 대폭 업그레이드 할 수밖에 없습니다. 이 일 저 일 함께 해야 하니,  프로젝트 이름을 하나로 부르기 힘듭니다. 그래서 퉁쳐서 “고도화”라고 부릅니다.

뭘 고치고 뭘 추가할지 숙제를 모아 둡니다. 사용자 행동을 분석해 시장 흐름도 파악해 둡니다. “서비스 전략”을 수정하고 “서비스”를 바꿉니다. 시스템을 여러 개 뜯어고칠 수밖에 없습니다.

내부 개발팀이 있다면 미리 상의하겠지만, 그렇지 않다면 SI 기업부터 정해야 합니다. 상세한 예산과 일정을 수립하고 입찰 공고를 냅니다.

새롭게 수주한 기업이라면 1.0부터 공부를 해야 합니다. 새로운 사업방향을 이해해야 합니다. 지나온 1년의 시간까지 뛰어넘어야 합니다. “업무분석단계”라고 합니다. 하지만 잘 안됩니다. 어렵습니다. 우리 회사를 오랫동안 도와 왔다면 비교적 쉽게 적응하겠지만, 그렇지 않다면 시작부터 실패입니다. 프로젝트 이해도가 낮으니 제대로 만들고 있는지 알 수도 없을뿐더러, 상세하게 감시할 수도 없죠.

2.0을 만드는 건 1.0을 만드는 것보다 4배~5배는 어렵습니다. 시스템이 계속 진화를 해야 한다면 개발팀을 데리고 있는 게 유리합니다. 아니면 계속 복잡해져 프로젝트는 실패하게 되죠.

SM의 부상, ‘개발+운영’이 섞여버린 시대의 등장

그런데 IT 산업의 발전과 함께 프로젝트의 메인 분야가 바뀝니다.  초반에는 거의 모든 기업들이 “신규구축”에 돈을 썼지만, 그다음에는 “운영”에, 그다음에는  “고도화”에 돈을 썼습니다. 요즘 뜨는 큰 프로젝트들은 대부분 “고도화”입니다.

IT 시스템의 초기 발주자는 “은행”과 “공공기관”이었습니다. PC 가 기업현장에 보급되면서 개인별로 일을 할 수 있게끔 프로그램을 만들었습니다. 그래서 대부분의 프로젝트는 “수작업”을 “자동화”하는 것이었습니다.

업무 이해와 분석이 쉬웠습니다. 개발자가 하루 종일 담당자 옆에 앉아 있는 걸로 업무 파악이 되었으니까요.

2000년, 정말 많은 SI 프로젝트들이 발주 됩니다. ATM 기기에서 돈을 뽑을 수 있게 되고, 면허증을 아무 곳에서나 발급받을 수 있게 됩니다. SI 기업들이 정말 바빴습니다.

사회 인프라 전반에 IT시스템이 깔리게 되자, 점차 수작업을 자동화하는 SI는 사라집니다. 대신 만들어 놓은 걸 운영 관리하는 “시스템 운영 (System Management, 이후 SM)” 사업이 등장합니다. 쉬운 현장도 있었지만, 복잡한 현장도 많았습니다. 코드를 고치거나 작은 기능을 추가해 넣습니다. 제휴 사업할 땐 기술지원도 합니다. “운영”과 “개발”을 구분하기 모호한 “섞인 업무”가 시작된 겁니다. 여기서부턴  일하는 방법이 툭 ~ 하고 끊깁니다.

기댈 곳 없는 “운영 개발” 업무

이전까지 “프로젝트”는 “분석 - 설계 - 개발 - 검수” 이렇게 진행했습니다. 건설처럼 “유지보수”, 즉 결함관리 정도로만 접근을 했습니다. “운영”이라는 개념이 없었습니다. 영국의 “리먼” 교수가 “소프트웨어 진화의 법칙”을 정리하긴 했지만, 빠르게 변하는 산업현장을 담지는 못했습니다.

※ Manny Lehman : 1925-2010, Middlesex University 컴퓨터 과학과 교수, 런던

“운영 프로젝트”를 수주한 기업은 처음에는 시스템의 기능 유지, 결함관리 정도만 했습니다. 그런데 점차 “기능개발”업무도 추가되죠. 규제변화에 따른 기능 변경, 개인정보 강화에 따른 “동의절차” 같은 걸 만들게 됩니다. 민원 대응을 위한 “사전공지” 기능도 개발하게 되죠. 즉, 기업 업무가 전산화되면서 이제는 소프트웨어를 바꾸지 않으면 업무진행이 아예 안되는 상황이 된 겁니다.  IT가 “필수업무”가 되고, “운영 업무” 에 “개발 업무”가 추가된 겁니다.

그런데, 이런 일은 단계별로 진행되지 않고 유사성이나 일관성도 없습니다. 그때그때 필요한 일을 하게 되니 작업 시간이 예측되지 않고 일정을 세울 수도 없습니다. 전형적인 SI 유형에는 포함되지 않죠.

“신규 구축”은 “건설”로부터 “프로세스”를 빌려올 수 있었지만, “운영개발”은 빌려올 곳이 없었습니다. 더구나 “운영”은 그 회사의 조직 모습까지 반영합니다. A팀이 해야 할 일과 B팀이 해야 할 일에 따라 기능을 나누어야 했죠. SI회사들은 어떻게 일해야 할지 몰라 혼란스러워했습니다.

하지만, 아웃소싱 시장의 변화는 느렸습니다. SI 기업이 내부 개발팀이 해야 할 일을 버젓이 하고 있었죠. SI 기업은 자기 정체성에 혼란이 옵니다. 남의 회사에 굳이 그렇게 일할 동기도 없고 업무효율화를 추구할 이유도 없는데 그런 역할까지 강요받았던 거죠. 계약기준까지 모호하니 갑질, 조직갈등이 자연스레 생깁니다.

“SI형 개발방법”을 쓸 수 없으니 대체수단으로 DevOps 와 애자일이 뜹니다. 하지만 현장에 맞지 않게 쓰이거나, 공식처럼 쓰이다보니 상황은 여전히 복잡했습니다.

※ 참고글

우리회사는 왜 애자일 전환에 실패했을까? (2021.08.03)

애자일이 정착되기 힘든 이유(2016.01.16)

글로벌 아웃소싱 환경의 변화

이런 변화는 우리만 겪는 게 아닙니다. 글로벌 아웃소싱 시장도 마찬가지입니다. 전 세계 아웃소싱의 메카, 인도를 찾아봅니다. 전 세계의 물량의 57%를 소화하고 있습니다.

표1. IT아웃소싱 기지로서 인도의 경쟁력 약화(대외경제정책연구원, 2007)

아웃소싱 부문의 성장률이 2004년도엔 48%였습니다. 점차 37%, 32%로 둔화됩니다. 전체적으로 SI의 시대에서 SM의 시대로 넘어간 겁니다. 비용절감형 아웃소싱을 할 수 없게 된 거죠. 그러자 인도는 빠르게 SaaS 로 갈아탑니다.

“혁신 창출과 발전” 같은 산업지형의 변화도 이 속도를 한층 더 가속시킵니다. 기술이 복잡하니 클라우드 위에 SaaS로 패키징을 합니다. SaaS 는 CD에 넣기 힘든 제품을 팔기 위한 툴입니다. 주로 기업 인프라를 기능으로 만들어서 팔죠.

DataWeave 같은 이커머스 분석툴, Hasura 같은 데이터 API 툴이 등장합니다. API 테스트툴로 유명한 Postman도 인도 기업입니다. 개발자 시장을 우선적으로 타게팅하죠.

※ 출처:2021년도 인도 SaaS 산업현황 및 트렌드 소개(KOTRA)

갑의 숙제, 효율에서 효과로

이와 같은 변화로 갑의 관점도 바뀝니다. 2000년대 초반, 갑의 숙제는 “효율”을 높이는 거였습니다. “생산성”의 시대였죠. 수작업을 자동화시켜 2명이 할 일을 1명이 하게 만들었습니다. 매출을 늘리는 게 아니라 비용을 줄였죠. 생산을 더 정확하고 빠르게 하다 보니 이익이 늘었습니다.

물론 이 시기에도 “네이버”는 그렇게 하지 않았습니다. “비용”을 줄이는 게 아니라  “매출”을 만드는데 IT기술을 썼죠. “블로그”도 만들고, “지식인”도 만들고, “지도” 도 만들었습니다. 소비자가 더 많은 “광고”를 볼 수 있도록 더 많은 서비스를 만들었죠. “효율”이 아니라 “효과”를 만들어내는 데 개발자를 투입한 겁니다.

사물인터넷, O2O이 등장하자 진짜 “효과”의 시대가 열립니다.

“스타벅스”의 “사이렌 오더”는 주문 대체를 위해 만들어졌습니다. 그런데 비용을 줄이는 게 아니라 매출까지 확대시켰죠. 서서히 증가하던 매출이 2014년(사이렌 오더 출시)를 기점으로  급증합니다.  공격적인 경영에 핵심적인 역할을 한 거죠.

“선불 충전금”을 만들어냅니다. 2023년 1월, 선불충전자수가 천만 명을 넘죠. 3,000억 원 정도의  유보금이 만들어져 무차입 경영을 하게 됩니다. 차입금이 950억 원을 넘은 적도 있었는데 정말 대단한 변화입니다. 이자가 5% 수준이라면 연간 48억 원 정도를 절약한 셈입니다.

흠. 이걸 누가 만들었을까?

물론 사업기획은 “스타벅스 코리아”가 했습니다. 그들이 “갑”이니까요. 그런데, 개발은  “신세계I&C”에서 했습니다.  신세계 그룹의 SI 회사죠. 지금도 IT 운영 및 관리는 신세계I&C가 일임하고 있습니다.

그런데, “사이렌 오더”는 비용을 줄이기 위해 기획된 게 아닙니다. “고객 경험 확대”를 위해  기획되었죠. 스타벅스는 고객과의 스몰토크가 매장 만족도를 높인다고 생각하는데, 주문 과정이 길어져 부정 경험이 늘어나자 그걸 몽땅 앱으로 옮겨 버린 거죠. 대신 “픽업” 단계에 시간을 쓰게 합니다. 빨대를 챙겨주거나 종이 캐리어에 담아주거나 등등을 말이죠.

담당 팀장은 이런 인터뷰를 했죠.

“사이렌 오더는 고객에게 어떤 걸 줄 것인가, 우린 무얼 얻을 것인가. 이걸 치열하게 고민하게 만드는 시스템입니다. 어느 방향으로 갈지 정하고 빠르게 고객 수요를 판단하면서 서비스를  진화시켜나갈 예정입니다.”

IT 기술을 매출을 높이고 시장을 늘리는 데 활용한 겁니다. 온라인 광고가 “광고대행”이라는 온라인 세계만의 사업이었다면, “사이렌 오더”는 “오프라인 기업”이 “세일즈”에 적극 개입시켜, 본업을 화학적으로 변화시킨 케이스입니다.

드디어 시장이 “생산성”이 아니라 “시장 진입 효과”, “시장 재편 효과”로 기술을 다루기 시작한 거죠.

갑의 고민, 불확실성의 시대

하지만, 프로젝트 초반 신세계 I&C 팀은 헤맬 수밖에 없었습니다. 개발이 비즈니스를 몰랐으니까요. 일을 시작하니 또 다른 문제가 있었습니다. POS 기기가 옛날 것이었거든요. 소스도 옛날 거라 새로운 기능을 넣기 힘들었습니다. 데이터 연동도 잘 되지 않았죠.

스타벅스 기획팀은 답답했습니다. 하지만 인내심을 가지고 현장과 협력하고, 개발팀까지 기획을 공유, 교육을 합니다. 그렇게 론칭까지 3년이 걸렸습니다. 대형 프로젝트였죠.

※ 관련기사 :“스타벅스, 한국서 모바일앱 주문 성공하기까지”(zdnet, 2017)

기업들은 이제 비용 줄이기를 기대하지 않습니다. 새로운 시장을 찾고 사업기회를 늘리고자 합니다. 1년짜리 단기 프로젝트가 아니라 4-5년 이상 꾸준히 밀어붙입니다. 이제 IT 업무는 1회성 이 아니라 영속적인 사업행위가 된 거죠.

그러다 보니 이제 IT프로젝트는 “사업적 속성”까지 띠게 됩니다. 바로 “불확실성”입니다.

일이 어떻게 될지 모르겠지만 일단 하는 겁니다. 모호하지만 가야 할 길이니 계속 가는 겁니다. 그러다 보니 “요구사항 명세서”를 적을 수도, “화면정의서”를 만들 수도 없습니다. 불확실할 수밖에 없으니까요.

이렇게 기존의 “소프트웨어 공학”을 적용하기 힘든 곳이 늘어나고 SI 프로젝트를 옛날처럼 할 수 없게 되자, 아웃소싱 부문은 더욱 힘들어집니다. (물론 여전히 기존 방법이 적용되는 현장이 있습니다.)

그러면 어떻게 해야 하나?

이런 아웃소싱 환경의 변화는 “갑” 입장에서도 당혹스럽습니다. 결과물을 얻는 과정이 아주 복잡해졌으니까요. 외주를 주고 기다리면 답이 나오던 그런 시대는 지나갔습니다.

뚜렷한 해결책이 있는 건 아닙니다. “갑”만 잘한다고 해결될 일도, “을”만 잘한다고 해서 해결될 일도 아닙니다. 일종의 구조적인 문제입니다. 

SI 기업들은 아직도 제안서에 20년전 개발방법론을 그대로 적어 놓습니다. 대신 프로젝트를 할 때 유연하게 풀어가죠. 대기업에는 인재들이 많아 비교적 현명하게 풀어갑니다. 하지만, 작은 기업들은 그렇지 않죠. IT프로젝트가 점점 더 어려워집니다.

그래서 다음 회차에는 프로젝트를 어떻게 해야 하는지, 프로젝트 관리자는 어떻게 해야 하는지,  “프로젝트 방법론”의 변화와 노하우에 대해서 이야기를 해보겠습니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.