[SI 산업 가이드북⑥] 1억 넘는 ‘진짜 프로젝트’는 어떻게 할까?

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

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

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

[IT입문자를 위한 SI산업 가이드북④] SI에서 발전된 폭포수, 애자일 바로 알기

[IT입문자를 위한 SI산업 가이드북⑤] SI 초보라면 이 8가지는 알고 하자

[IT입문자를 위한 SI산업 가이드북⑥] 1억 넘는 ‘진짜 프로젝트’는 어떻게 할까?

이번 회차에선 조금 큰 프로젝트를 다루어봅니다. 금액은 1억 원 정도라고 합시다.

1억 원이면 “진짜 SI 프로젝트” 중에선 가장 저렴한 사이즈입니다. 

그러면 “가짜 SI 프로젝트”도 있냐고요? 1천만 원짜리 이하라고 할까요? 

우스갯소리입니다. 1천만 원짜리 이하 사업도 엄연한 수주형 아웃소싱 사업입니다.

다만 가격이 싸다 보니 일하는 방식이 전통적인 소프트웨어 공학에서 꽤 벗어나 있습니다. 그래서 1억 원 이상 프로젝트를 “진짜 SI 프로젝트”라고 표현해 봤습니다.

낮은 가격대에선 대부분 “갑”이 약자입니다. 고객이 이런저런 요구사항을 내기보다 공산품을 사는 거죠. 복잡한 요구사항을 내지 않기 때문에 갑을 갈등이 적은 편입니다. 물론 없지는 않습니다.

하지만, 1억 원 정도로 가격이 올라가면 상황이 달라집니다. “갑”은 뚜렷하게 원하는 것이 있습니다. 1억 원이 가벼운 돈은 아니니까요. “꽤 복잡해” 라고 말할 수 있는 수준으로 갑이 아주 까다로워집니다.

정리합니다. 여기서 중요한 건 1억 원이라는 액수가 아니라 이 금액대가 “갑”이 “까다로워지는 지점”이라는 겁니다. 누군가에게는 그게 5천만 원이기도 하고, 2천만 원이기도 합니다.

고객 상황 예상해 보기

1억 원짜리 발주자는 개인이 아닙니다. 그러기엔 큰돈이니까요. 대부분 기업입니다. 

수익을 올리기 위해 새 사업을 만들거나, 자동화를 통해 비용을 줄이려고 하죠.

그런데, 비용을 줄이려고 할 땐 고객이 까다롭지 않습니다. 효과가 검증된 걸 사야 하니 남들과 비슷한 걸 사죠. 반면 새로운 걸 만들려고 할 땐 좀 까다로워집니다. 남들과는 다른 걸 만들어야 하니 비슷하지만 뭔가 다른 걸 원하게 되죠. 아이디어만 있는 경우도 있고, 이미 사업이 진행 중인 경우도 있습니다.

전자의 케이스는 실패 확률이 높습니다. 고객이 이 사업을 해본 적이 없다면 더욱 그렇겠죠. 어디로 가야 할지 갑도 모르고 을도 모르니까요. 이 이야기는 기니까 다음에 하겠습니다.

후자 케이스는 대부분 프로젝트가 무난히 끝납니다. 고객이 뚜렷한 목표 의식을 가지고 있으니까요. 대부분 담당자 1명은 있습니다. 관리할 사람 하나 없이 1억 원이나 태울 사장님은 없거든요.

담당자가 개발자일 수도 있고 아닐 수도 있습니다. 하지만 대부분 외주 의뢰 경험이 없습니다. 성공 경험이 있었다면 아마 발주 금액이 대부분 더 컸을 겁니다. 아래 상황으로 정리해 봅니다.

첫째, 개발자 또는 개발팀이 없습니다.

본업이 개발회사가 아닌 거죠. 마케팅 대행사라면 영업맨이 우선입니다. 광고를 수주해야 먹고 살 수 있으니까요. 충분한 영업 인력이 우선이고 개발팀은 가능하면 일회성으로만 투자합니다.

둘째, 새 기술에 대한 전문성이 부족합니다.

AI 챗봇을 만들어보고 싶은데 아는 사람이 회사 내에 없습니다. 당장 3개월 이내 작은 챗봇을 만들어야 하는데 이걸 만들 사람이 팀 내에 없는 거죠. 이때 아웃소싱을 하기도 합니다.

셋째, 그냥 일손이 부족합니다.

발주사는 지금 “서비스 2.0”을 만들고 있습니다. 3명이면 충분할 줄 알았는데 해보니 작업량이 많군요. 6명 분량이라 3명을 아웃소싱합니다. 프리랜서를 구할 수도 있지만, 통째로 아웃소싱하기도 합니다.

셋 다 상황이 달라 대처방안도 다른데요. 이번 글에서는 첫 번째 사례로 이야기를 풀어봅니다.

“제휴 마케팅 사이트”를 만들어 주세요 

이전 글의 프로젝트와 비슷한 “쇼핑몰” 사례를 생각해 봅시다. 다만 발주 금액이 1억 원 정도 되면 일반 쇼핑몰은 아닙니다. 특별한 로직을 넣고 싶은 거겠죠. 그만큼 비싸졌으니까요. 옛날 경험을 각색해서 정리해 봅니다.

제목은 이렇습니다. “ABC 쇼핑몰 - 인플루언서를 위한 쇼핑몰 플랫폼”

발주자는 ABC 쇼핑몰(가칭) 회사 사장님입니다.

인플루언서 광고는 사실 이미 인스타그램이 하고 있습니다. 비즈니스 계정을 만들면 사진에 해시태그를 넣어 자기 쇼핑몰과 연결할 수 있죠. “언더아머” 같은 대형 스포츠 의류 회사는 잘 하고 있습니다.

그런데 ABC 쇼핑몰은 좀 다르게 하고 싶습니다. 인플루언서만을 위한 일종의 “광고 쇼핑몰”이죠.

인플루언서가 쇼핑몰에서 마음에 드는 제품을 선택하고 본인 채널에 광고를 걸어줍니다. 팔로워들이 광고를 클릭, 구매를 하면 인플루언서가 수수료를 받습니다. 즉, 인플루언서가 광고 영업맨이 되는 거죠. ABC 쇼핑몰은 가게 사장님들로부터 광고 주문만 받아오면 됩니다.

예상되는 시나리오를 정리해 봅니다.

[표1] 예상 사용자 시나리오

인터넷 쇼핑몰과 비슷한데 어딘가 조금 다르죠? 그런데, 이거 눈에 익습니다.

혹시 본 적 있지 않으세요? 네, 바로 “쿠팡 파트너스” 입니다.

“쿠팡 파트너스”에선 블로거나 인스타그래머들이 쇼핑몰 제품 링크를 게재해주고 수수료를 받습니다. 이런 걸 전문용어로는 “제휴 마케팅” (Affiliate Marketing)이라고 하죠. 알고 보니 이 프로젝트는 제휴마케팅 사이트를 만드는 거였습니다.

※ 참고 글: 쿠팡 파트너스는 어떻게 돈이 될까?

프로젝트의 ‘진짜 시작 지점’

오픈된 소스 코드는 없습니다. 돈 되는 코드는 공개하지 않거든요. 경쟁자를 늘리게 되니까요. 

맨땅에서 개발해야 합니다. 차별화된 기능도 만들어야 하죠. 이 정도 크기라면 프로젝트 기간이 보통 6개월 정도 됩니다.

초보 SI 기업이라면 개발량을 가늠하기 힘듭니다. 비즈니스 디테일을 모르니 모호한 게 많죠. 

고객도 이 사업이 처음이라면 모르는 부분이 많을 수 있습니다. 기능을 예상보다 2배 이상 만들어야 할 수도 있죠. 가능하면 SI 기업에게 반제품 코드라도 있으면 좋겠습니다. 코드를 재활용하면 생산속도나 코드 퀄리티가 올라가니까요. 몰랐던 업무도 코드 안에 포함되었다면 더 이득일 수 있죠.

반면, “갑”은 대부분 프로젝트 관리 경험이 없습니다. 그러면 이렇게 말할 수 있죠. 

“그냥 쿠팡 파트너스처럼 만들어 주세요.”

SI 기업은 놀랍니다. ‘달랑 1억 원 주면서 10억 원짜리를 만들어달라 하는구나.’

이렇게 오해가 시작되면 프로젝트는 처음부터 어긋나기 시작합니다.

참고로, 쿠팡은 2010년 당시 30억 원으로 시작했습니다. 소셜커머스가 핵심인 만큼 대부분의 투자금은 IT 시스템을 개발하는 데 쓰였죠. 지금은 훨씬 더 많은 돈을 쓰고 있습니다. IT 투자액이 2022년에는 9,287억 원이었다고 하네요. 뭘 만들었는지는 모르지만 그만큼의 일을 했다는 뜻입니다. 사내 개발자 수는 2,300명 정도라고 합니다. 매일 2,300명이 일을 해야 시스템이 유지, 발전된다는 뜻이죠. 

※ 참고 기사: 작년 IT투자액, 압도적 1위 “쿠팡”, 꼴찌는 “티몬” (2023.7.4)

쿠팡 인프라는 복잡합니다. 로켓배송 때문에 유통까지 붙어있으니까요. 대용량, 분산처리 등 고수준의 기술구조가 복잡하게 얽혀 있습니다. 업무 범위도 넓죠. 머신러닝과 CRM, 광고 플랫폼까지 붙어 있으니까요.

모르긴 몰라도 “쿠팡 파트너스”를 개발하는데 1억 원은 넘게 들었을 겁니다. 즉, “고객”이 상상한 “쿠팡 파트너스”와 실제로 운영 중인 “쿠팡 파트너스”는 비슷하지만 완전히 다른 시스템이라는 거죠. 비슷한 “제휴 마케팅” 시스템이어도 규모가 완전히 다릅니다. 이걸 이해하지 못하면 SI 기업은 낮은 돈에 비싼 인프라를 구축하다 망할 수 있습니다.

즉, SI 기업은 “갑”의 높은 기대치, 현실 인식 부족, 짧은 프로젝트 기간, 또는 부족한 사업경험 등을 끌어안고 일을 시작해야 합니다. 네, 바로 여기가 이 프로젝트의 진짜 시작 지점이죠.

고객사와 SI 기업의 ‘자격’

고객의 기대치는 높습니다. 곧 100억 원을 벌 수 있다고 믿죠. 반면, 시스템 구축에 대해서는 알지 못합니다. 진짜로 “성공한 비즈니스 모델”과 “성공한 플랫폼 기능”을 1억 원에 원할 수 있습니다. 현실 인식이 부족한 겁니다.

어떤 고객은 “시스템”만 만들어지면 100억 원을 벌 수 있다고 생각합니다. 심지어는 시스템을 오픈한 후 돈을 벌어 잔금을 치르겠다는 분들도 있죠. 낙관적이고 불확실합니다.

현실은 고객 기대와 다르게 돌아갑니다. 사업이 펑크나기도 하고, 기대만큼 돈이 안 될 수도 있습니다. 금방 경쟁자가 쫓아올 수도 있고요. SI 사업은 시스템을 만들어주고 그 대가로 돈을 버는 것입니다. 고객의 흐름에 동화되어 이리저리 끌려다니면 이도저도 안 됩니다. 너무 많은 불확실성에 사업을 맡겨버리게 되니까요.

그렇기 때문에 프로젝트에 지원하면서 제일 먼저 확인해야 할 것이 있습니다. 바로 “고객 상태”입니다.

금액이 1억 원 정도인 경우에도 생각보다 서투른 고객들이 발주할 때가 많습니다. 그래서 고객상담을 통해 이것저것을 확인합니다. 대화가 통하는 상대인지, 프로젝트 대금은 있는지, 만들고 싶은 것이 정확히 있는지 등등 말이죠.

이 단계에서 프로젝트를 정상적으로 진행할 수 있다는 확신이 들지 않는다면 프로젝트를 포기합니다. 대부분 처음 생각한 게 맞습니다. 뭔가 불안한 부분이 있다면 그 일이 일어날 확률이 높습니다. 즉, 이 요건들은 “고객”이 최소한 갖춰야 하는 “고객의 자격”입니다. 준비사항이라고도 할 수 있죠.

반면 SI 기업이 가지고 있어야 하는 최소한의 자격도 있습니다. 바로 목표한 시스템을 만들 수 있는 “업무경험”과 “기술력”입니다. 결과물을 만들 능력을 말합니다.

업무경험이란 사업경험이 아니라 시스템 개발경험을 말합니다.

“제휴 마케팅 사업을 해보았는가?”가 아니라 “제휴 마케팅 시스템을 개발해 보았는가?”입니다. 이건 개발 프로젝트를 진행하는 능력입니다. “과정”을 만들어내는 힘이죠.

“제휴 마케팅 시스템”은 여러 이해관계자를 대상으로 합니다. 광고주에게는 광고 수익률(ROAS), 결제 금액, 광고 스케줄링 등을 보여줘야 하죠. 인플루언서들에겐 광고 노출률, 정산금액 등을 보여줘야 합니다. 전체적으로 이어지는 프로세스와 상호작용해야 하는 기능들이 있죠.

이런 이야기를 처음부터 해야 한다면 개발 기간이 길어집니다. 고민의 깊이가 얕다면 프로세스 오류가 날 확률도 커지죠. 시스템이 정산 일자를 지키지 못하거나, 정산 내역을 임의로 바꾸기도 합니다.

SI 기업이 관련 업무경험이 있다면 실패경험까지 녹인 기존 코드를 가지고 있을 확률이 큽니다. 고객의 실패 확률이 줄어들죠.

또한 필요한 기능을 만들어 낼 기술력이 있어야 합니다. 광고 클릭을 높이려고 링크를 일부러 반복해서 누르거나, 프로그램을 통해 반복호출하면 “부정탐지”로 인식하고 무효화시킬 수 있어야 하죠. 나름 꽤 복잡한 로직이 들어가야 합니다. 공격방식이 진화한다면 방어방식도 진화해야 하죠.

헤비 인플루언서가 광고 링크를 무지막지하게 많이 만들 수도 있습니다. 갑자기 엄청난 양의 트래픽이 몰려들 수도 있고요. 이에 대응하려면 대량의 데이터에 대한 처리 기술이 있어야 합니다. 인프라 기술 난이도도 꽤 높아지죠.

SI 기업의 업무경험과 기술력은 한가지 목표를 만족시켜야 합니다. 고객이 제휴 마케팅을 시작할 수 있어야 한다는 겁니다. 즉, 프로젝트의 발주 목표입니다. 고객 상담은 고객과 SI기업이 이걸 서로 확인하는 단계입니다.

이 프로젝트, 할까? 말까?

그런데 이런 일을 한 번도 해본 적 없는 기업이 이 프로젝트를 수주할 수 있을까요?

단호하게 말할 수 있습니다. “아니오!”

기술력이 있어도 일을 맡길 고객이 없습니다. 같은 값이면 경험 있는 기업을 선택하거든요. 간혹 기회가 오기도 하지만 기대하지 않는 게 좋습니다.

그렇다면 경험 없는 기업은 어떻게 경험을 얻어야 할까요?

일반적으로 유사 프로젝트의 서브 참여자로 들어가야 합니다. 그런데 이런 기회를 얻기 쉽지 않죠. 메인 참여자 입장에선 경쟁자를 늘리는 거니까요. 그래서 대부분 경험이 없는 기업은 관련 프로젝트 경험자를 직원으로 뽑습니다. 그 사람을 중심으로 개발팀을 꾸리죠. 아쉬운 부분이 있을 수도 있지만, 1억 원 정도의 일을 반복적으로 하기에는 나쁘지 않습니다.

프로젝트를 맡았다면, 어떤 어려움이 있을까요?

이건 장점이자 단점입니다. 대부분의 고객에겐 이미 유사 경험이 있습니다.
1억 원짜리 프로젝트를 발주할 정도면, 고객이 원하는 요구수준이 구체적으로 있는 편입니다. 그래서 시시콜콜한 부분까지 챙기죠. 프로젝트가 실패할 확률은 낮아지지만 업무 조율이 까다로워집니다. 예상치 못한 곳에서 고집을 부리기도 하고, 프로젝트 기간이 길어지기도 하죠.

그렇다고 고객에게 정답이 있는 건 아닙니다. “쿠팡 파트너스”를 직접 해본 게 아니라면 말이죠.

딱 그 일을 해본 게 아니라면 디테일은 모를 수 있습니다. 그래서 “갑”의 요구사항을 검증 없이 받아들이면 안 됩니다. 적절한 해결책이 아닐 수도 있고 전체적으로 봤을 때 모순된 기능일 수 있습니다.

이런 어려움을 어떻게 극복해야 할까요?

수십번 강조해도 지나치지 않는 게 있습니다. 바로 눈높이를 맞추는 겁니다. 프로젝트 시작 전 고객과 최종 목표의 이미지를 맞춥니다. 가능하면 가격 이야기도 합니다. “AI 챗봇은 아니에요. 그건 좀 비쌉니다. 다만 룰 기반 세팅이면 이 가격에 가능해요. 이러이러한 기능이 다릅니다.” 등등.

고객은 처음 보는 회사를 덜컥 신뢰하지 않습니다. 자신에게도 중요한 일이니까요.

꽤 많은 경우 자기 인맥을 이용해 교차 검증을 합니다. 그래서 비교 검증해 볼 수 있는 시간과 정보를 충분히 줘야 합니다.

이 단계는 매우 중요합니다. 고객과 기본 신뢰가 형성되는 기간이기 때문입니다. 목표 결과물은 공산품이 아니라 커스텀 제품입니다. 따라서 생각지 못한 곳에서 시간이 길어집니다. 신뢰가 없다면 대화할 수 없고, 대화할 수 없다면 개발량, 개발기간, 요구수준 등을 조율할 수 없습니다.

프로젝트를 수주하는 과정이 이런 과정입니다. 생각보다 길고도 복잡한 과정이죠. 

그래서 일을 수주하고 잘 끝냈다는 것 자체로 그 업체는 검증된 업체라는 뜻입니다.

‘갭’을 줄이는 프로젝트 관리

1억 원짜리 프로젝트는 어떻게 관리해야 할까요?

생각보다 고객은 준비되어 있지 않습니다. 그렇다고 해서 요구사항이 없진 않죠.

프로젝트 규모에 비해 1억 원은 그다지 큰 돈이 아닐 수 있습니다. 기간과 작업량에 한계가 있죠. 그래서 우선순위 관리를 잘해야 합니다. 이때 목표관리, 기대치 관리, 보고관리를 모두 포함해야 합니다.

프로젝트를 시작하면서 챙겨야 할 것들을 정리해 봅니다.

가장 먼저 해결해야 할 문제는 이겁니다. “무엇을 만들 것인가?”. 무얼 만들 건지 구체적으로 정해서 나열합니다. 고객이 이해할 수 있는 용어로 정리합니다. “요구사항 수집 단계”라고 합니다.

다만 고객은A 를 A’ 라고 말할 수도 있습니다. 그대로 수용하면 엉뚱한 걸 만들게 됩니다. 다시 물어보며 정답을 찾아갑니다. “인터뷰 스킬”, “커뮤니케이션 스킬”이 필요합니다.

고객이 모르고 기능을 이야기하지 않을 수도 있습니다. 특히 회원가입, 알림, 비밀번호 찾기 같은 기능일 겁니다. “당연히 있겠거니” 하고 넘어갑니다. 하지만, 찾아서 개발 목록에 넣어야 합니다. “소프트웨어 개발관점”에서 만들어야 할 것을 재정리하는 겁니다. “요구사항 분석”이라고 합니다.

이 정도가 정리되면 무얼 만들 수 있을지 비로소 전체 그림을 그릴 수 있게 되었습니다. “설계”라고 합니다. 처음부터 모든 게 선명하게 정리되진 않습니다. 갑도 모르고 을도 모르는 부분이 있으니까요.

그렇다면 얼마나 자세하게까지 정리해야 할까요? 

SI 프로젝트팀의 책임자가 작업량과 일정을 추정할 정도입니다. 요구사항 문서, 설계문서 등을 말하는 게 아닙니다. 결국 책임자의 모호함을 걷어내고 자신감을 만들어내지 못한다면, 뭔가 빼먹은 겁니다. 이야기해서 풀어야 할 것을 못푼 거죠.

고객도 전체 작업량과 일정을 대략 이해하고 있어야 합니다. 그들의 지적 호기심을 채워준다는 뜻이 아닙니다. 이렇게 개발된다면 사업을 런칭할 수 있을지 고객도 확신해야 한다는 뜻입니다.

대부분 프로젝트의 결과물은 “기대치”보다 낮아집니다. 반면, 고객의 “기대치”는 “사업 시작요건”에 맞추어져 있죠. 그래서 타협이 불가능한 마지노선이 있습니다. 고객이 이 부분까지 확인하고 목표 수준을 받아들여야 합니다.

프로젝트를 한다는 건 초반에 꽤 빡세게 계획을 세웠음에도 불구하고, 등장하는 여러 가지 상황들을 조율한다는 뜻입니다. 고객과의 인식 차이는 쉽게 줄어들지 않습니다. 시스템을 만드는 사람과 사업을 하는 당사자들은 입장이 다르니까요.

그래서 프로젝트 진행 중에도 이런 갭들을 꾸준히 줄여가야 합니다. 그게 “보고관리”입니다. 

여기서 핵심은 보고 행위가 아닙니다. 그런 갭이 줄었냐, 갈등이 해결되었냐 하는 겁니다. 

프로젝트의 진행을 막고 있는 장애물들을 하나씩 걷어 나가는 과정이 “프로젝트 관리”입니다.

이런 규모의 프로젝트에선 정형화된 “관리 문서” 요구가 크지 않습니다.

그래서 여러 가지 업무 도구들을 활용하여 작업 효율을 높입니다. 디자인 할 때는 “Figma”, 업무 우선순위를 정할 때는 “트렐로”, 공동문서를 관리할 때는 “노션” 등을 쓰죠.

프로젝트 팀원 구성하기

처음 해보는 일이라면 반드시 길잡이가 필요합니다. 눈에 안 보이는 함정들이 많거든요.

모든 개발자가 “제휴 마케팅 플랫폼”을 알 수는 없습니다. 하지만, 팀 내에 최소한 1명이라도 전문가가 있어야 합니다. 길잡이가 없다면 프로젝트는 100% 헤매게 될 겁니다.

대부분의 SI기업들은 “관련 프로젝트 경험자”를 고용하는 걸로 일을 시작합니다. 고용에 성공했다면, 그 사람을 중심으로 팀을 꾸리죠. 가능하면 미리 팀을 구성합니다. 닥쳐서 하게 되면 생각보다 일이 잘 안 돌아갑니다.

이때 엄청나게 뛰어난 기술을 가진 개발자를 뽑아야 할까요?

회사를 책임지는 복잡한 기능들은 고객사가 직접 개발합니다. 경쟁사에 유출될 수 있으니까요. 

간혹 대범하고 순진하게 핵심기술을 아웃소싱 하는 경우도 있지만 여기선 제외하겠습니다.

그래서 대부분의 SI 프로젝트들은 업무 프로세스를 아웃소싱하는 경우가 많습니다. 기술 난이도가 낮고 (고객의) 경쟁사에 유출되어도 타격이 적으니까요. 이런 작업은 대부분 평이한 기술들로 이루어지기 때문에, 커뮤니케이션 스킬이 좋거나 이해력이 빠른 개발자를 선호하는 편입니다. 물론 제품을 계속 연구∙개발해야 하는 기업이라면 훌륭한 연구개발자를 따로 관리합니다.

SI 기업의 경쟁력은 어디서 나올까?

기업의 생존 부등식입니다. “가치 > 가격 > 원가”.

소비자는 가격보다 만족감이 크다고 기대할 때 돈을 씁니다. 생산자는 판매 가격보다 제작원가가 낮아서 이윤을 남길 수 있을 때 제품을 만듭니다. 한양대 윤석철 교수님의 “프린시피아 매니지멘타”라는 저서에 정리된 내용입니다. 기업이 생존하는 가장 기본 원리입니다.

잘하는 SI 기업은 1억 원을 받고 2억 원어치 기능을 제공해 줍니다. 반면, 개발 원가는 1억 원 이하로 낮춥니다. 

아니, 그게 정말 가능한 일인가요? 만들어야 할 기능들이 이미 개발되어 있으면 가능합니다.

아니, 어떻게 미리 기능을 만든단 말인가요? 했던 일을 자꾸 또 하면 이미 만들어져있게 됩니다.

즉, 기능이 이미 만들어져 있으니 전체 시간이 많이 줄어들고, 더 많은 기능을 제공할 수도 있죠.

더구나 오래 재활용된 기능이라면 에러가 날 확률도 낮습니다. 즉, 회사의 기술력이자 전문성이죠.

좋은 SI 기업일수록 비슷한 프로젝트를 계속 수주합니다. 전문성을 올리죠. 한 번 활용한 소스코드는 잘 정리해서 재활용률을 높입니다. 조립식 모듈처럼 활용할 수 있게 프레임워크까지 만들죠. 생산성이 높아지는 겁니다.

어떤 기업들은 오픈 소스를 곧잘 활용합니다. 손쉽게 복잡한 기능 모듈을 구사할 수 있으니까요.

이런 베테랑 기업이 있다면 신생 SI 기업은 수주 경쟁에서 이기기 힘듭니다. 즉, 이것이 SI 기업의 경쟁력이 됩니다.

마치며

고객이 아무것도 준비가 되어 있지 않은 초보자이면서 덜컥 1억 원이나 준비한 경우, 

고객이 이런 프로젝트를 많이 뛰어봐서 풍부한 진행경험이 있는 경우, 

고객이 큰 프로젝트의 일부를 그냥 개발만 맡긴 경우, 

일을 통짜로 맡기는 “도급형태”부터 회사로 출근해서 “상주”를 하는 경우까지.

커스텀 시장은 고객상황이 너무 다양해서 그 패턴을 정형화하기 힘듭니다.

그리고 이 정도 규모면, SI기업의 대응방식도 자유로워 더욱 정형화하기 힘듭니다. 

그래서 “이 시장은 이래요. 이렇게 일하시면 되요.”라고 말하기 어렵습니다.

그럼에도 글로 케이스 하나를 정리하면서 프로젝트를 할 때 어떤 것을 신경쓰게 되는지 살펴봤습니다.

프로젝트를 진행하다 보면 기술적 갈등을 해결하는 방법들도 있는데 여기선 정리를 못했습니다. 다음에 기회가 되면 다루겠습니다.

다음 번엔 “은행 차세대 프로젝트” 같은 대형 SI 프로젝트들은 어떻게 진행되는지 정리해 보겠습니다.

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