[SI 산업 가이드북⑨] IT 아웃소싱을 잘 관리하는 3가지 방법

지난 편에 “갑은 SI 프로젝트를 어떻게 만들까?”에 대해서 정리를 했습니다.

이 글은 “을”(SI 기업)이 “갑”을 이해하기 위한 배경지식이었습니다. 

이번에는 “갑”이 “갑”을 이해하기 위한 내용을 정리해 봅니다. 대상은 초보자 “갑”입니다.

SI 프로젝트의 갑은 큰 기업에도 있지만, 작은 기업에도 있습니다. 막 창업한 사장님은 무섭습니다. 여기저기에서 무작정 외주업체에 일을 맡기면 안 된다고 하니까요.

하지만 어찌해야 할지 모르겠습니다. 갑은 노하우를 서로 공유하지 않으니까요. 회사도 다르고 상황도 다르고 예산 규모, 시점 모두 달라서 정리된 이론이나 체계가 없습니다. 당연히 배울 수 없죠.

그러나 갑이 잘해야 프로젝트가 잘 끝납니다. 돈을 투자하고 끝까지 책임지는 주인이니까요. 주인이 잘해야 일꾼도 잘하는 법입니다. 

베테랑 갑들은 너무나도 잘 아는 내용입니다. 하지만 전통산업에는 이를 모르는 분도 많아 이 글을 썼습니다. 도움이 되면 좋겠습니다.

※ 전통산업(Traditional Industry)이란, 오랜 역사를 가지고 우리 사회를 지탱하는 제조업 및 기간산업 등을 지칭하는 의미로 쓰였습니다.

IT 아웃소싱은 누가 할까?

“스타일난다”를 아시나요?

IT 업계 사람들은 잘 모를 수 있지만, 패션 업계의 네이버 정도로 취급됩니다. 젊은 여성들을 위한 패션 상품과 악세사리를 파는 곳입니다. 지금은 모두에게 익숙한 개념이지만 회사가 문을 연 2004년 당시로선 신선했습니다.

22살 여대생이 2004년에 시작한 회사는 2018년 로레알에 6천억 원을 받고 매각됩니다. 대표는 완전히 돈방석 위에 올라앉았죠. 당시 스타일난다의 매출은 2,000억 원, 영업이익은 400억 원(영업이익률 20%)이었습니다. 어마어마하죠.

비슷한 사례로 무신사가 있습니다. 2001년 프리챌 커뮤니티에서 시작했죠. 신발 사진을 무진장 많이 찍어 올리던 게 계기가 되었습니다. 2023년 매출이 8,829억 원, 영업이익 370억 원이었습니다.

무신사는 개발팀을 100명 이상 데리고 있습니다. 반면 스타일난다는 개발팀을 운영하지 않았죠. 어느 게 더 좋다고 말할 순 없습니다. 각자 일장일단이 있죠. 여기에선 “스타일난다”를 예로 들어봅니다.

이 사업에는 IT가 반드시 필요합니다. 인터넷 쇼핑몰이니까요. 하지만 이 회사가 IT 사업을 하고 싶은 건 아닙니다. 좋은 물건 많이 팔아서 이익을 남기는 걸 하고 싶었죠.

패션이니만큼 유행 상품이 주력입니다. 재고를 많이 확보할 이유가 없죠. 다품종 판매 전략으로 인기 상품은 후딱 팔고 비인기 상품은 떨이를 합니다.

독립 쇼핑몰이 있어야 하고 기술 변화도 적절히 따라가야 합니다. IT의 역할이 작지는 않았죠.

반면 제품 회전이 빠르니 복잡한 개인화, 재고관리 등은 필요 없습니다. 이런 측면에서는 IT의 중요성이 떨어집니다.

그래서 “스타일난다”는 풀 아웃소싱 전략을 취합니다. 개발팀을 운영하지 않고 카페24에 모든 걸 맡겨 버리죠. 2010년 중국 시장을 공략할 때도 카페24를 활용합니다. 그러다 보니 위챗페이, 알리페이 등을 쉽게 붙일 수 있게 됩니다. 다음 해 매출이 677억 원에서 1,151억 원으로 늘어나죠. 큰 노력 없이 2배 성장해 버리죠.

굳이 개발팀을 운영하지 않고도 돈을 번 겁니다. 효과적인 아웃소싱 전략을 선택한 거죠.

IT 아웃소싱을 왜 할까?

왜 기업들은 직접 개발팀을 만들지 않고 SI를 발주할까요?

개발자들은 잘 이해하지 못합니다. 자기 걸 자기가 개발하는 게 너무 당연하거든요.

하지만 현실은 그렇지 않습니다. 국내 GDP를 보면 소프트웨어 세상은 전체 세상의 3.3% 정도밖에 안 되죠. 2021년 기준 “전체 산업 : 소프트웨어 산업 = 2,080조 원 : 68조 원”이었으니까요.

※ 2021년, 미국은 5.8% 정도 ($22조 9,395억 : $13,345억), 유럽은 4% 정도였습니다. ($21조 5,183억 : $8,868억)

GDP는 우리가 쓴 금액을 기준으로 합니다. 누군가 썼다는 건 누군가 벌었다는 뜻이니까요. 소프트웨어 산업의 총생산액이라는 건, 누군가 소프트웨어 구매나 아웃소싱에 쓴 금액을 의미합니다.

참고로 은행이 IT를 이용해 돈을 번 건 소프트웨어 산업이 아닙니다. 금융 산업이죠.

IT가 본업이 아닌 경우

즉, 96.7%의 세상은 IT와 관계없거나 IT를 이용하는 산업활동이라는 뜻입니다. 물론 유통, 제조, 금융, 국방 등 전통산업도 이제는 IT가 없으면 안 됩니다. 하지만, 소프트웨어 개발이 본업은 아니죠.

예를 들어 현대자동차가 소나타 생산라인 시스템을 매달 뜯어고친다면 소비자는 납득할 수 없습니다. 다음 달 바뀔 것을 이번 달에 사지는 않을 테니까요.

결과의 동일성과 프로세스의 항상성이 중요하다면, 자꾸 뭔가 고치는 것보다 한 번 구매해서 오래 쓰는 게 중요합니다. 개발팀을 만들어 빠르게 대응할 필요가 없죠. 전산실 같은 관리팀이 더 중요해집니다.

대기업만 그런 것은 아닙니다. 스타트업도 마찬가지입니다. “빠른 개발”과 “웹 서비스의 빠른 변화” 등이 경쟁력이 아니라면 처음부터 개발팀을 꾸리지는 않습니다.

전문성이 없는 경우

IT 회사라도 전문성이 없는 분야에선 아웃소싱을 합니다.

“케이뱅크”는 2017년 KT가 오픈한 인터넷은행입니다. 새로 시작한 은행이니 맨땅에서 출발해 다른 은행 수준까지 모든 걸 구현해야 했죠. 인가에서 인증까지 1년, 시간이 짧았습니다.

그래서 코어뱅킹은 국내 회사 솔루션을 구매하고, 정보계 등 단위시스템은 아웃소싱을 했죠. 그 비용으로만 첫해에 900억 원을 씁니다.

KT에는 KTDS라는 커다란 SI 회사가 있습니다. 하지만 금융 쪽 경험이 전혀 없었죠. 그래서 중요한 일임에도 불구하고 외부에 아웃소싱을 맡깁니다.

기업시장에서 전문성이란 일반적으로 “비즈니스 전문성”을 말합니다. 기업시장은 “기술”을 사는 게 아니라, “비즈니스가 포함된 기술”을 사는 거거든요. 연구개발 시간을 줄이고, 검증된 제품을 통해 성공 가능성을 높이는 겁니다. 솔루션을 개발하는 게 아니라 사업을 하는 게 목표니까요.

이 외에도 아웃소싱을 하는 다양한 이유가 있습니다. “비용 절감, 출시 기간 단축, 넓은 전문가 풀, 용이한 인력 조정” 등. 다 맞는 말인데, 아웃소싱을 할 수밖에 없는 가장 큰 이유를 보여주는 것이 위 두 가지, 스타일난다와 케이뱅크의 사례입니다.

전통산업이 존재하는 한 IT 아웃소싱, SI는 사라질 수 없습니다. 앞으로도 사라질 수 없죠. 소비자의 성향이 다양한 만큼 비즈니스의 세계도 다양하니까요.

IT 아웃소싱, 어떻게 해야 할까?

그러면 아웃소싱을 어떻게 해야 할까요?

“갑은 요구사항만 말하면 끝 아닌가요? 일은 수행사가 다 해줄 텐데요.”

갑 역할을 이렇게 아는 사람들이 많습니다. IT 아웃소싱에 대한 이해 부족 때문입니다. SI 산업이 급성장했던 2000년대에는 이런 일이 어느 정도 가능했습니다. 양질의 개발자들이 넘쳤거든요. 갑이 부족해도 개발자들이 몸을 갈아넣어서 그걸 메꾸었죠. 지금은 아닙니다.

지금은 상황도 복잡해지고 기술도 복잡해졌습니다. “갑”이 잘해야 합니다. 아주 잘해야 합니다. 하지만 이런 인식을 바로 잡을 기회가 없습니다. “갑 개발방법론” 같은 게 없으니까요. 그냥 잘못된 채로 흘러가는 겁니다.

아래는 IT 아웃소싱 모델의 여러 유형을 나타낸 표입니다.

“전담팀 보강형”은 추가설명이 필요합니다. “전담팀 보강형”은 전산실 담당자가 유지 보수할 때 많이 쓰입니다. 하는 일이 뻔한데 구체적인 요구사항을 확정 지을 수는 없을 때죠. 요구사항이 아니라 업무 범위로 기준을 정하고, “기간 x 투입 인력수 x 등급별 대가”로 계약합니다.

ISP(전략계획) 같은 고급 프로젝트에도 많이 쓰입니다. 역시 요구사항을 확정 지을 수 없거든요. 다만 기본 단가를 높게 쳐줍니다.

이처럼 “관계 기반” 모델은 기본적으로 오너십이 “갑”에게 있습니다. “갑”이 해야 할 일을 외부 전문가를 활용해 업그레이드하는 거죠. “갑”이 아무것도 모르거나 바쁘지 않으면 아무런 성과도 얻지 못합니다. 사이즈가 작아 대부분 “갑”도 1인이 관리하죠.

잘하는 갑에게 붙여주면 아주 효과적입니다. “갑”의 능력을 증강시켜 주니까요. 반면, 못하는 갑에게 붙여주면 아주 망하는 겁니다. 역시 “갑”의 능력을 증강시켜 주니까요. 잘하는 노하우 같은 건 없습니다. 그냥 담당자 개인 성향과 자질에 의존하죠.

“프로젝트 기반형”은 목표가 명확하고 어떻게 해야 할 지 잘 알 때 씁니다. 한시적으로 많은 전문가가 필요하기 때문이죠. 기간, 예산이 정해져 있기 때문에 요구사항이 명확합니다. 

장기간 프로젝트에는 유리하지 않습니다. 2~3년 이상이면 주변 상황이 변해버리거든요. 보통 3개월, 6개월, 1년짜리를 많이 합니다.

다만 큰 회사의 경우 업무 조율 때문에 일이 단방향으로 흘러갑니다. 여러 부서가 합의한 상황을 뒤집기 어려우니까요. 책임질 사람이 모호하거나 사라져 버린 경우도 있습니다.

“과업 기반 모델”도 잘 살펴보면 결국 “갑”이 일을 다 해야 합니다. 시스템 구현과 개발을 외주로 돌릴 뿐, 과업을 계획하고 진행시키고 책임지는 일까지 모두 “갑”이 해야 합니다.

여기서 일을 진행시킨다는 건 전체 관점의 일을 말합니다. 요즘은 레거시 없는 곳이 없어서 새 시스템이 만들어지고 있는 동안에도 레거시를 계속 건드려줘야 하거든요. 내부 레거시는 “갑”의 일이죠.

이해를 돕기 위해 꽤 잘 알려져 있으면서 복잡했던 사례를 분석해 봅니다.

신한은행 차세대 프로젝트

2021년 신한은행이 1,800억 원짜리 프로젝트를 런칭합니다. 코어뱅킹을 유닉스에서 리눅스 운영체제로 바꾸는 차세대 프로젝트였죠. 큰 결정인데 목표가 있었습니다.

영업을 좀 더 강화하고 싶었던 것입니다. 대면, 비대면 업무를 통합하고, 고객이 지점 아무 데나 가도 진행하던 대출을 이어서 할 수 있게 했습니다. 그렇게 은행원들이 지점 밖에서도 영업할 수 있게 했죠. 전반적으로 금융 업무에 대한 고객경험(CX)을 개선하고 싶었던 겁니다. 그래서 시작한 디지털 전환 사업이었죠.

계획을 세우는 데만 5개월에 9억 원을 씁니다. ISP 사업은 “EY한영”이 수행했죠. EY한영은 회계법인이지만, IT 컨설팅부터 프로젝트 관리까지 다 합니다.

※ ISP : Information Strategy Planning, 정보전략계획. 기업이 사업을 위해 IT 관련 중장기 미래 전략을 세우는 것을 말한다.

결과물로 42개월에 걸쳐 3,000억 원을 투자하자는 계획이 나옵니다. 변경 범위가 넓으니 단위 프로젝트를 단계적으로 오픈할 계획을 세우죠. 기술적으로는 LG CNS의 도움을 많이 얻습니다.

최종적으로 다음 내용이 제안요청서에 담겼습니다.

표2. 신한은행 “더 넥스트” 제안요청서 주요 과업 <출처: 신한은행>

꽤 구체적이지 않나요? 

또한 제안 평가를 할 때 가격 점수보다 “정성 평가”를 높입니다. 가격 경쟁이 아니라 실력 수주를 할 수 있게 만들었죠.

“제안요청서”도 일부 기업에만 배포합니다. 기업비밀이 노출될 수 있거든요. 대기업들은 이렇게 많이 합니다.

제안 업체 선정 과정이 섬세하죠? 절대 허투루 준비하지 않았습니다. 목표와 과정을 정교하게 계획하고 역량 있는 SI 기업들과 의논을 했죠.

누가 했을까요? “갑”이 다 했습니다. 아무도 가르쳐주지 않았겠지만, 저걸 다 챙겨서 했습니다. 

혼자 했을까요? 아닙니다. 이 사업의 시작은 진옥동 당시 신한은행장이었습니다. 이 업적을 인정받아 지금은 신한금융지주 회장이 되었죠. 회사 전체가 나서서 했던 겁니다.

구축 프로젝트는 LG CNS가 수주합니다. PMO는 여전히 EY한영이 맡았죠. 계획을 함께했던 기업들이 선정된 겁니다. 그림 그린 기업이 끝까지 책임 지게 만들었죠.

이후 “갑”은 놀았을까요? 아닙니다. 신한은행 내부에서 일어나는 일은 전부 “갑”의 일이거든요.

레거시와 통합하거나 데이터를 이전시켰습니다. 갑의 직원들이 해야 하는 일이죠.

업무 역할 정리와 조직 분리도 합니다. “디지털혁신단”을 신설해 AI 전략을 추진하게 만들었죠. CEO가 결정해야 하는 일입니다.

이런 프로젝트에서 “갑”이 안 바쁘면 이상한 겁니다. IT 프로젝트의 주인은 “갑”입니다. 수행사의 역할은 손과 두뇌를 빌려주는 거죠. 갑은 시스템이 완성되기 전에 사업운영 준비를 마쳐야 합니다.

준비 과정에서 갑이 안 바쁘다면 시스템이 완성되어도 사업을 시작할 수 없죠.

프로젝트 운영 단계

운영 단계로 넘어가면 “갑”의 역할이 더 중요해집니다. 이제 내부 요청에 직접 답을 해야 하니까요. 질문을 넘길 SI 팀이 없죠.

게다가 이제부턴 새로운 시스템이 돌아가는 겁니다. 아무도 모르는 일이 태반이죠. 

이제부터 일어나는 모든 일은 세상에서 처음 일어나는 일입니다. 물어볼 사람도 없죠. 

오직 “갑”이 능동적, 창의적으로 문제를 풀어가야 합니다.

시스템이 만들어졌다고 사업이 저절로 이루어지는 건 아닙니다. 사업 성과를 만들어 내려면 회사도 부담 백배죠.

IT 아웃소싱을 잘하는 방법

초보 “갑”들은 이런 질문을 합니다.

“어떻게 하면 프로젝트를 잘 끝낼 수 있을까요?”

“어떻게 하면 사업을 잘 지원할 수 있을까요?”

“도대체 무엇을 챙겨야 할까요?”

“저희가 알아서 다 해줍니다. OO님은 그냥 앉아서 쉬세요.”

이건 SI 영업맨들이 옛날에 했던 말입니다. PM들은 이런 말 안 합니다. “갑”의 역할이 얼마나 중요한지 아니까요. 요즘은 “영업맨”도 이렇게 말하지 않습니다. 시절이 많이 변했죠.

좋은 파트너

프로젝트 진행 과정은 눈에 보이지 않습니다. 아무리 보고를 잘 받아도 정말 제대로 진행되는지는 알 길이 없죠. 결국 수행사에 의지할 수밖에 없습니다.

성공적인 아웃소싱의 핵심은 좋은 수행사를 만나는 겁니다. 좀 허무한 결론이지만 그게 전부입니다. 그게 안 되면 아무리 좋은 이론도 말짱 꽝이죠.

그런데 대기업이면 다 좋은 수행사일까요? 프로젝트 금액이 크면 좋은 기업들이 올까요?

아닙니다. 좋은 파트너란 이 일에 맞는 경험과 실력을 가진 사람을 보유한 기업입니다. 결국 사람이 전부인 거죠.

어떻게 해야 그런 기업을 만날 수 있을까요? 말이 아니라 결과를 만들어내는 기업 말이죠. 역시 허무한 결론이지만, 평소에 부지런히 실력 있는 SI 기업들을 만나고 일을 해보는 수밖에 없습니다. 

시간과 노력이 걸리는 일입니다. 그래서 큰 프로젝트를 하려면 평소에 차근차근히 준비해야 하죠.

좋은 파트너를 만난 다음은 어떻게 해야 할까요? 가만히 있으면 될까요? 아닙니다.

프로젝트에는 항상 새로운 문제들이 등장합니다. 시간만 충분하다면 대부분 해결할 수 있는 일들이죠. 하지만 항상 시간이 부족해서 사고가 납니다. “을”이 미리 알고 나서도 제때 보고하지 못한 거죠. “갑”과의 관계가 불편하거나 공격받을 가능성이 있기 때문에 보고를 안 한 겁니다.

그래서 프로젝트의 시작은 편하게 대화할 수 있는 관계를 만드는 겁니다. 그게 문제에 대처할 시간을 미리 확보하기 위한 핵심 요령이죠.

이 모든 것 이전에 가장 중요한 게 있습니다. 

바로 “갑”이 자기 역할과 책임을 올바로 인식하는 겁니다. 

간혹 상황이 어려워지면 책임을 피해 도망 다니는 “갑”이 있습니다. 책임질 사람이 없으니 일 마무리가 되지 않죠. 상황은 더욱 악화됩니다. 

갑질하는 “갑”도 있습니다. “을”을 윽박지르는 걸로 문제를 해결하려 하죠. 하지만, 문제는 해결되지 않습니다. 윽박지르지 않았던 게 문제의 원인은 아니니까요.

책임질 일은 빨리 책임지고 다음 단계로 넘어갑니다. 윽박지르지 않고 문제 원인을 찾아 제거하고, 재발하지 않도록 조치합니다. 그게 갑이 해야 할 일입니다.

시간과 노력을 들여 좋은 수행사를 찾습니다. 그다음 좋은 파트너가 되어 줍니다. 아주 평범한 이야기입니다만, 그게 “갑”이 프로젝트를 준비하는 과정입니다. 시간과 노력이 꽤 들어갑니다.

기대치 관리

“갑”은 회사 내부의 “기대치” 관리를 잘해야 합니다. 나의 기대치 아닙니다. CEO, 임원 등 의사결정권자들의 기대치입니다.

돈을 쓰는 데는 다 이유가 있습니다. 1억 원에는 1억 원, 10억 원에는 10억 원만큼의 효과를 기대합니다.

하지만 일은 항상 계획대로 되지 않습니다. 그래서 돈 쓰는 사람들의 기대치를 잘 관리해야 합니다.

“기대치”는 “목표”와 다릅니다. 기대치는 목표보다 앞에 있습니다. 

“비대면 거래관리를 위해 코어뱅킹을 업그레이드하는 것”, 이건 목표입니다. 

“영업점이 비대면 업무처리를 가능하게 하는 것”, 이게 기대치입니다.

기대치는 제품이 아니라 회사 내부의 변화입니다. 의사결정권자가 그 수준을 정합니다. 그런데 회사에는 의사결정권자가 한 명이 아닙니다. 여러 부서에 걸쳐 있습니다. 쉽게 정리되지 않습니다. 그래서 기대치는 시간을 두고 조율해야 합니다. 프로젝트 시작 전에 말이죠.

수준과 내용 조절은 비교적 가능합니다. 하지만 숙제가 생기면 까다로워집니다. 부서끼리 양보할 수 없는 한계선이 생깁니다. “기대치 관리”는 이런 걸 확인하는 과정입니다.

조율에는 시간이 오래 걸립니다. 새로운 업무 지침을 만들거나 규정도 개정해야 합니다.

비대면 계좌 개설을 한다고 합시다. 개인정보 확인은 휴대폰 인증만 할지, 은행 계좌 인증은 안 할지, 신용불량자에게도 개설을 허용할지, 대포통장은 어떻게 확인하고 막을지 등등을 살펴봐야 합니다.

코드를 어떻게 부여해야 할지는 개발회사의 몫이지만, 정책 결정은 “갑”의 몫입니다. 정책 결정을 하지 못하면 개발이 진행되지 않습니다. 그런데 정책 결정에는 후속 업무가 발생합니다. 비대면 계좌 개설 관련 새로운 정책이 나오면 후속 업무는 프로젝트 담당자가 아니라, 계좌 담당 부서에서 정리해야 합니다. 시간이 걸리겠죠.

프로젝트를 하다 보면 이런 일들이 엄청 많습니다. 즉 “기대치 관리”란 단순한 의견 조율이 아니라, 예산, 기간, 목표 수준, 업무 변화 등을 결정하는 예측 작업입니다.

1,000억 원짜리 프로젝트에만 해당하지 않습니다. 1천만 원짜리 프로젝트에도 이런 일이 있습니다.

“소프트웨어 개발”을 아웃소싱할 수 있지만, “사업 준비”는 아웃소싱할 수 없습니다.

결과물 관리

DB 설계서, API 정의서, 소스코드 등 산출물은 중요합니다. 진행 여부를 확인할 수 있는 양적 결과물이기 때문입니다. 그런데, 산출물을 챙긴다는 건 단순히 “문서” 파일을 받는다는 게 아닙니다.

산출물은 문제 풀이 과정의 결과물입니다. 산출물을 만들라는 건 그 “문제 풀이 과정”을 하라는 뜻입니다. DB 설계서가 나오려면 DB 설계라는 과정이 있어야 합니다. 

코드 데이터는 어떻게 만들지, 회원 정보는 어디서 가져올지, 신용정보는 어디서 연동할지 등을 먼저 협의해야 합니다.

그러려면 담당 부서와 회의를 해야 합니다. 이 회의를 주최해야 할 사람이 “갑”입니다. 

그런데, “갑”이 정직원이라 해도 그런 복잡한 데이터가 어디에 있는지 모를 수 있습니다. 새로 만들어야 할지 기존 데이터를 재활용할지도 결정하지 못합니다. 삭제 시점이나 폐기에 관한 룰도 정해야 합니다.

당연히 1시간 만에 결정되지 않습니다. 이런 조율 시간을 고려해서 프로젝트 일정에 반영해야 합니다. 

ERD, 프로세스 정의서, 클래스 다이어그램? 문서 양식의 이름은 중요하지 않습니다. 산출물을 만들기 위해 “필요한 행동을 제대로 했냐?”가 중요합니다.

제 경험에서 나온 예시입니다. 꽤 큰 유통회사였습니다. A 시스템을 업그레이드할 생각이었습니다. DBA가 기초데이터를 B 시스템에서 추려 넣어줘야 했습니다. SI 개발자는 보안 이슈로 필요한 기능만 개발하면 되었습니다.

그런데 DBA가 테이블 정의서도 데이터 구조도 주지 않았습니다. 그래서 말했습니다.

“제가 할게요. API만 열어주세요.” API도 없습니다. 

“아, 그럼 특정 계정에 View Table만 열어주세요. 제가 할게요”. 이제 DBA가 휴가 가고 없습니다. 

정리된 엑셀 파일도 없고, 위키도 없습니다.

당연히 이 프로젝트는 우여곡절을 많이 겪었습니다. 당시 꽤 주목을 받는 이름있는 기업이었습니다.

‘큰 기업은 잘하고 있겠지?’ 그렇지 않습니다. 산출물을 관리한다는 건 할 일을 점검하고 준비한다는 뜻입니다. “개발”은 아웃소싱할 수 있습니다. 하지만, “내부업무”는 아웃소싱할 수 없습니다. 대부분의 프로젝트는 “개발”이 50, “사업관리”가 50입니다.

마치며

회사마다 프로젝트마다 상황이 다릅니다. “갑”이 해야 할 일도 다릅니다. 그래서 위에 설명한 상황이 얼마나 도움이 될지 확신은 못 하겠습니다.

‘큰 프로젝트는 저렇게 하는구나.’

‘저런 일들이 일어나는구나.’

이 정도로만 이해해 주시면 좋겠습니다. 막연하게 프로젝트에 들어가기보다 어느 정도 감 잡을 수 있는 정도로만 이해되기를 바랍니다. 

1천만 원짜리 프로젝트도 비슷합니다. 이슈의 크기에 차이가 있을 뿐, 저런 일들이 일어나야 합니다.

아웃소싱은 사라지지 않을 겁니다. 기업시장, 공공시장 등 비 IT 산업은 아웃소싱을 할 수 밖에 없습니다.

그런데 아웃소싱의 “갑”을 위한 이론, 업무 체계는 없습니다. 회사마다 상황이 달라서 앞으로도 없을 것 같습니다. 하지만 요점은 있습니다. 잊지 말았으면 합니다.

아웃소싱은 “갑”이 하는 거대한 프로젝트의 일부분일 뿐입니다. 부족한 IT 역량을 전문가의 손에서 빌리는 겁니다. 끊임없이 소통하고 점검해야 일이 제대로 끝납니다.

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