을의 Digital Finance 블로그(7)
국내 IT서비스 생태계의 문제점 (갑을병 문화)
국내 IT 서비스 생태계의 문제점 (구매자-판매자, 갑을병 문화)
여느 산업과 마찬가지로 국내 IT서비스 산업에도 구매자(기업)와 서비스 제공자 (SI사업자)가 존재한다. IT의 중요성이 더해지고, Digital 시대에 접어들면서 국내 IT서비스 산업 또한 양적, 질적으로 지속적으로 발전해 왔다. ABCDE 기술의 발전에 따라 전통적인 IT가 아닌 Digital 금융의 중요성이 커지면서, 금융기관(발주자, 甲)과 SI사업자(서비스 제공자, 乙) 간의 전통적인 관계 모델의 유효성이 급격히 저하되고 있다. 본 블로그에서는 현재 상황과 새로운 관계 모델의 가능성에 대해서 고민해 보고자 한다.
구체적인 계획/요건수립이 가능한 문제영역(Simple, Complicated)에서 전통적인 Waterfall 방식은 갑과 을이 협업하여 나름 효율적인 IT시스템을 구축할 수 있게 했다. 하지만 불확실한 복잡한 문제영역 (Complex, Chaotic)한 영역에서는 전통적인 갑과 을간의 이해상충이 더 커지고 효과적으로 협업하기가 너무 힘들어졌다. 국내 IT서비스 산업에서의 경쟁적인 문화, 결과물이 눈에 보이지 않은 SW개발과정의 특수성으로 인하여 IT서비스 생태계의 갑을병 문제가 더 심화되었다. 경쟁수주의 비용압박으로, 하청업체인 '丙' "丁"의 비중이 전체 MM(ManMonth)의 80%를 넘어서고, 대부분은 프리랜서 개발자로 채워지는 상황이 자주 목격된다.
갑을의 이해상충을 기업 차원에서 살펴보면, 궁극적으로 달성하고자 하는 목적부터 다른데 본질적으로 복잡계 영역에 속하는 디지털을 추진하면서는 그 갭이 더 커졌다고 생각된다.
첫째, 갑은 비지니스 성과(Outcome)를 극대화하길 원하지만, 을은 독립회사로서 SI 계약에 의한 매출 극대화가 우선이다. 비지니스 성과인 Outcome은 시스템을 사용하면서, 새로운 고객경험을 제공하거나 매출 증대, 비용 절감, 생산성 향상을 통해 개발 후 달성하는 것이 보통이다. 결국 시스템을 만드는 기간에는 비지니스 결과를 확인하기 어렵고, 기간이 정해져 있는 SI계약에 종료기준으로 성과를 포함하기는 불가능하다. 전략 컨설팅사의 경우, 성과(Performance, Outcome) 기반의 컨설팅 계약을 장기간에 걸쳐 체결하여 운영 결과까지 책임지는 경우가 있는데, 이런 방식을 통해 컨설팅 비용을 할인해서 계약하기도 한다. 반면, SI계약은 컨설팅 대비 계약 규모도 크고, 병정 등 하청업체 비중이 높으며, 갑이 주도하는 운영 과정에 참여하여 기여하는 방식도 찾기 어려워서, 통상 성과기반 SI계약을 체결하기 힘들다.
갑은 을과 리스크를 공유하면서 최종적인 비지니스 결과(Outcome), 또는 산출물인 시스템(Output)에 대해서 지불하고 싶어 하지만, 을은 가능한 리스크를 부담을 줄이면서 주어진 프로젝트 기간과 MM(Manmonth)에 대해서 보상받기를 원한다. 국내에서는 기간과 비용을 전제로 한 turn key 방식의 SI방식이 일반적이어서, 갑은 MM가 초과해도 추가 비용을 부담하지 않으려 한다. 기간이 증가하면, MM가 증가하게 되고, 이는 비용의 증가로 이어지는데, 종종 귀책사유를 두고 갑과 을간에 분쟁이 발생하기도 한다.
둘째, 갑은 역할 구분 없이 같이 일하면서 Agile 하게 실험적으로 접근하고 싶어 하지만, 을은 문서화된 요건에 기반한 예측가능한 프로젝트를 원한다. 통상 디지털 금융 프로젝트들은 갑이 미리 장시간 요건을 정의하고, 아키텍처 검토 등 여러 가지 준비를 하지만, 요건은 가설에 불과하게 된다. 새로 발견한 고객의 요구에 대응하기 위해, 갑은 역할 구분 없이 Agile 하게 일하려고 Daily Scrum, 회고를 위한 미팅을 진행하고자 한다. 하지만 예측가능한 프로젝트를 수행하고자 하는 을 입장에서, 이러한 요건의 변경은 초기에 이미 결정한 기술과 업체를 변경해야 하는 위험요인이다. 나아가 현장의 사무환경은 하도급법에 의해 일하는 공간을 분리하고, 을과 병의 현장대리인을 통해 업무지시가 이루어져야 하는 전혀 Agile 스럽지 않은 환경이다. 오히려 을은 계약상에 정해진 지체배상금, 손해배상 분쟁에 대비하여, 프로젝트 과정에 발생하는 요건,분석,설계 과정의 회의록과 합의, 변경 내용을 이력관리하는 문서의 작성에 과도한 노력을 기울이기도 한다.
셋째, 갑은 지속적으로 투자비용을 절감하고 싶어 하지만, 을은 SI사업의 영속성을 위해 일정 수준이상의 마진과 매출을 확보해야한다. SI사업의 경우, 프로젝트 리스크에 따라 Contingency 비용을 프로젝트 비용에 반영해야 하는데, 기본적으로 SI는 최소 전체비용의 15~20%를 Contingency 비용으로 잡아야 한다. 글로벌 IT회사의 경우, 시스템 산출물이 없는 컨설팅도 최소 10%의 Contingency 비용을 부과하는데, 요건이 불확실하고, 기술 변화속도가 빠른 디지털 SI는 당연히 Contingency 비용이 훨씬 더 높을 수밖에 없다. 나아가 SI사업자 입장에서는, 추가적인 HW, SW의 매출을 포함하여 일정 마진을 확보하기 위해 종종 필요수준보다 넉넉한 아키텍처를 제안하기도 한다.
넷째, 갑은 상황 변화에 맞추어 기술 수준이 높은 다양한 전문가를 원하지만, 을은 사전에 명확한 기술 Spec을 가진 전문가를 정해서 프로젝트에 투입하기를 원한다. 디지털 금융의 문제가 복잡함에 따라, 다양한 요건을 검토하는 갑의 입장에서는 개발자, IT Architect 만이 아니라 AI, 클라우드 등 다양한 전문가의 투입을 필요로 하게 된다. 반면 자사투입률이 20% 미만인 수행사 입장에서는 사전에 미리 정해진 기술요건에 따라 미리 내부 외부 전문가를 선정하고, 프로젝트 투입계획에 반영하는 것이 중요하다.
다섯째, 갑은 시스템 개발뿐만 아니라 운영까지의 전 과정에 관심이 있지만, 을은 통상 시스템 개발기간에 관심이 있다. 갑의 입장에서 시스템은 개발하는 게 중요한 게 아니라, 잘 운영하여 비지니스에 활용하는 것이 중요하다. 장애 없이 운영되는 안정성 확보도 중요하지만, 향후 요건 변경을 쉽게 반영할 수 있는 탄력성, 유지보수 용이성도 중요하다. 이를 위해, 개발된 시스템을 충분히 테스트하고 운영팀이 인수인계할 수 있는 시간을 확보하고, 하자유지보수 기간을 명시하기도 한다. 하지만 발주사 내부에 코드리뷰를 할 수 있는 충분한 개발자가 없는 경우가 많아, 코드 레벨의 품질 검증은 항상 어렵다. 하자 보수 기간을 1년으로 산정해 놓아도, 종종 문제의 원인이 프로젝트 종료 후에 발생한 변경들에 의한 경우도 많아, 귀책사유를 밝혀서 하자 보수의 범위라고 결정하기도 어렵다. 수행사의 경우, 당연히 개발기간 내에 프로젝트를 종료하는 것이 중요하고, 이를 위해 종종 미래의 유지보수를 용이하게 하기 위한 아키텍처적인 의사결정, 코딩 시 탄력적인 옵션을 포함하는 일은 후순위에 그치게 된다.
돌아다보면 추격자 경제 모델을 통해, 성장한 한국은 모든 곳에서 속도 전쟁을 펼쳐왔다. IT개발과정도 예외가 아니어서, 필자도 PM과 수행사 임원으로서 시스템 오픈을 앞두고 야근과 주말 근무를 마다하지 않으며, 귀가하려는 개발자들을 막아서기도 했다. 고객사 임원이 설정한 오픈 시점은 깰 수 없는 전제조건이었고, 무조건 지켜야 할 약속이었다. 통합테스트 중에도 발생하는 요건변경은 수용되어야 했으며, 많은 부분 재작업과 야근으로 이어졌다. 추가적으로 보이지 않는 산출물인 SW영역에서는, 현장의 개발자 본인과 주변 동료 개발자 말고는 산출물의 품질을 정확히 파악하기 어렵다. 그러다 보니 개발진도체크가 매일매일 이루어졌고, 신뢰 관계가 약한 발주사, 수행사간의 관계에서는 결과(Outcome)보다 산출물(Output), 품질(Quality) 보다 투입 MM (Quantity), 야근하는 모습이 더 중요하기도 했다.
갑을병의 문제를 기업 차원을 넘어, 개인 차원으로 살펴볼 때, 가장 큰 문제점은 빠른 시간 내 역량 있는 개발자를 육성하기 어려운 환경이라고 생각한다.
1) 개발자는 주어진 코딩을 수행하고, 기능테스트만 통과하면 되는 수동적인 존재로 키워진다. 프로젝트에 참여하는 개발자 입장에서 살펴보면 고품질의 SW를 개발할 동인, 모티베이션이 거의 없다. 특히 수행사에 소속된 SI개발자 입장에서 보면, 본인이 개발하는 것은 결국 발주한 갑사의 시스템이 된다. 아무리 수처작주를 외쳐도, 어떻게 보면 대리모의 역할을 수행하는 셈이라고 생각한다. 이런 환경에서는 기본적인 작동여부를 검증하는 기능테스트, 성능테스트를 통과하게 되면 그만이라고 생각한다. 발주사가 생각하지 못한 테스트 조건을 만족시켜야 할 이유도 없고, 시간을 견뎌내는 SW 엔지니어링을 할 이유도 없다.
발주사의 개발자는 자신이 직접 최종 결과물인 SW를 유지보수해야 하기도 해서, 개발에 직접 참여하려고 하지만 종종 금융기관 내부의 많은 행정업무 (보고, 결재, 문서화 등)에 시달린다. 반면 수행 원청사에 소속된 개발자는 본인들이 직접 유지보수할 것은 아니지만, 적어도 회사 내에서 개발자 커리어를 가져가려는 개인적인 목적으로 스스로 동기를 부여하기도 한다. 반면 실제 대부분의 개발을 수행하는 하청업체에 소속된 개발자의 경우, 대부분 프리랜서여서 이러한 커리어 개발 목적을 찾기도 어렵다.
2) 을과 병의 개발자는 종종 본인이 수행한 공로가 갑의 공로로 전환되어, 상실감을 느끼고 불공정하다고도 느낀다. 모 금융사에서 CIO 역할을 할 때이다. 가끔 발생하는 장애로 야근을 하고 있는 중에, 어려운 문제가 해결되었다. 해당 직원을 칭찬하고 밤 늦게 퇴근했는데, 며칠 뒤 알아보니 그 해결은 협력사 직원이 한 것이었다. 하지만 시스템적으로는 권한이 없어서, 갑사 직원의 ID, PW를 사용하여 협력사 직원이 수행한 것이어서 당사자들 아니면 모르는 사항이었다. 실제 문제를 해결한 협력사 직원의 상실감이 얼마 컸을지 생각하며 식사를 대접한 적이 있었다. 2010년대 카드사 고객정보 유출사고에 대응하여 정보보안이 강화되자, 실제 을, 병들의 시스템 권한은 더 축소되었다. 결국 더 자주 갑사 직원의 ID, PW를 통해 작업을 할 수밖에 없었다. 금융사의 과도한 권한 제한은 결국 협력사 직원이 더 효율적으로 장애대응을 하고, 더 성장할 수 있는 기회를 박탈하고 있기도 하다.
3) 기술이 정체된 영역에서의 갑을병 문화는 더욱 심하다. 얼마 전 협력사 직원이 갑사 인프라 직원이 주말에 이사하는데 짐을 들어주었다는 이야기를 듣고 놀란 적이 있었다. 대한항공 땅콩회항을 포함해 여러 차례에 걸쳐 사회적을 갑질 문제가 논의되어 사회 전반적으로 충분히 성숙한 갑을 문화로 변화하고 있다고 생각했는데 의외였다. 물론 2000년대처럼 술 접대나 향응이 오간 것은 아니었지만 바람직하다고 볼 수는 없었다. 그런데 가만히 생각해 보니 이해가 가는 측면이 있었다. 협력사 직원은 복수의 HW, SW를 구성하고 구축하는 지난한 작업을 2~3년에 걸쳐 수행했고, 또 이를 안정화시키기 위해 1~2년을 야근과 주말 근무를 마다하지 않았던 직원이었다. 하지만 동일한 구성의 on premise 시스템은 경쟁사에 가도 없었으며, 새롭게 다른 곳에서 시스템 구축과 운영을 해 볼 용기도 적었던 거 같다. 이 상황에서 절대적인 영향력을 행사하는 갑사 직원에게 맞추어 주는 것은 합리적인 선택으로 보였다. 클라우드와 같은 새로운 기술을 맞이할 용기가 없는 IT전문가는 갑을병 문화에 바로 쉽게 순응하게 된다. 사실 새로운 기술을 습득하면, 이직의 기회도 많고 보다 더 많은 선택의 자유를 누릴 수 있지만 그만큼의 노력은 필요하다.
Simple, Complicated 한 문제영역에서 계획된 요건을 납기 내에 약속한 품질로 완성하기 위해서는, 과거 갑을 문화는 어느 정도 효율성을 발휘했다고도 생각한다. 하지만 이제는 따라 할 선진국 시스템, 소위 Best Practice도 줄어들고 있고, 창의와 탐색이 중요해지는 디지털 시대에 전통적인 갑을병 문화는 여러 측면에서 산업화 시대의 유물이 되어 가고 있다고 생각한다.
다음 블로그에서는 이러한 갑을병의 문제를 악화시키는 환경적인 측면인 하도급법, 규제와 보안의 문제영역을 살펴보고자 한다.
