본문 바로가기

댓글0
번역beta

Translated by kakao i

번역할 언어 선택

뷰 본문

탈잉

수많은 스타트업이 실패하는 이유

‘Standish Group International, Inc’에서 발표한 통계에 따르면 IT 프로젝트의 16.4% 정도만 성공한다.

2,614 읽음
댓글0
번역beta

Translated by kakao i

번역할 언어 선택


20여 년간 IT 관련 일을 해오면서 수많은 스타트업이 생겨나는 것을 봐왔습니다. 지금 이 순간에도 생겨나고 있겠죠. 하지만 성공하는 곳은 극히 일부였습니다.

실제로 ‘Standish Group International, Inc’에서 발표한 통계에 따르면 IT 프로젝트의 16.4% 정도만 성공한다고 하니, 제가 현장에서 느끼고 봐 왔던 것이 어느 정도 근거가 있다는 말이죠.

그렇다면 나머지 83.6%는 왜 성공하지 못하는 걸까요?

실패에는 비즈니스 모델, 팀빌딩, 리더십, 사업관리, 의사결정 과정 등 다양한 원인이 있겠지만, 제가 생각하는 IT 개발 실패의 고질적인 문제은 아래와 같습니다.



1. 프로젝트 관리 개념 부족

많은 IT 스타트업들이 실패하는 이유를 '개발 기술에 대한 지식 부족'으로 생각합니다. 하지만 이는 정답이 아닙니다.


실제로 전에 H 은행 차세대 인터넷뱅킹 시스템을 개발할 때, 인터넷뱅킹과 개발 기술을 잘 아는 사람이 PM(Product Manager)를 했다가 실패를 한 적이 있습니다. 결국 PM은 교체되었죠.


그런데 새로운 PM은 인터넷뱅킹 관련 기술을 전혀 모르는 사람이었습니다. 하지만 그 프로젝트를 성공시켰습니다. 오로지 프로젝트 관리 기법으로 말이죠.


결국, 내가 개발을 잘 아느냐보다는 프로젝트를 얼마만큼 잘 관리할 수 있느냐가 핵심이 되는 것입니다. 프로젝트 관리라는 것이 막연해 보이지만, 사실은 위험관리만 잘해도 개발 성공 확률을 높일 수 있습니다.


팁을 하나 드리자면, 개발 진행 상황을 점검할 때 부종적인 일이나 행동이 2번 이상 반복이 되면, 이슈로 등록을 해서 관리에 들어가야 합니다. 예를 들면, 일정 지연이나 반복되는 오류 발생, 반복되는 소통 오류와 같은 것이 있을 수 있습니다.

2. 불명확한 비즈니스 모델

프로젝트 관리를 아무리 잘하더라도 비즈니스 모델이 명확하지 않으면 개발에도 영향을 줍니다. 비즈니스 모델이 불분명하면, 완벽한 개발이 들어간 서비스가 오픈되어도 사용자들은 이용하지 않습니다.


바로, Product-Market-Fit에 문제가 있는 것이죠. 대부분의 창업자들은 자신의 BM(Business Model)이 Product-Market-Fit에 부합한다고 자신합니다. 하지만 여기서 문제가 발생하는 경우를 저는 꽤 자주 보았습니다. 


이렇게 개발된 소프트웨어나 플랫폼 자체는 기능적으로 완벽할지 몰라도, 사용자가 불필요하게 느낀다면 그 제품은 ‘무쓸모’가 되는 것이죠.

이런 상황이 되면 많은 스타트업들이 고객의 피드백을 받기 시작합니다. 무엇이 문제인지 고객입장에서 들어봐야 하니까요.

하지만 이렇게 되면 개발 요건이 변경되고 설계도가 바뀌게 됩니다. 그러면 당연히 프로그램 소스를 계속 변경하게 되겠죠. 이 작업이 반복되면 소프트웨어 소스는 내부적을 꼬이게 되고, 전에 없던 오류는 점점 늘어나게 될 것입니다.  물론, 이런 잦은 변화에도 잘 대응할 수 있는 경험 많은 개발팀을 만나게 되면 이런 문제는 극복할 수 있습니다.

한 가지 팁을 드리자면, 이런 상황에서는  개발팀을 선택하실 때 SI(System Integration) 경력만 있는 팀보다는 솔루션 개발 및 운영을 오래 한 팀을 선택하는 것이 안정적입니다. SI 프로젝트는 기본적으로 주어진 요건에 최적화하여 개발되는 반면, 솔루션 개발 및 운영은 기능이 계속 변화할 것을 고려해서 설계하고 개발하는 특성이 있기 때문입니다.
3. 비즈니스 모델의 개발 요구사항 연결 실패

비즈니스 모델이 검증되어 명확하다고 하더라도, 제대로 개발 요구사항이 전달되지 않으면 비즈니스 모델과 결과물 간에 Mismatch가 발생하게 됩니다.


이럴 때는 비즈니스 모델에 참여하는 이해관계자(고객)들 간의 Action과 Reaction 그리고 Benefit에 대한 것을 명확히 정리하는 것이 우선입니다. 그런 다음 서비스를 이용할 사용자들에 대한 정책도 같이 정의가 되어야 비로소 정확한 개발 요구사항이 될 수 있습니다.


그런데 안타깝게도 개발 설계가 들어가기 전에 이런 과정이 제대로 되는 것을 별로 보지 못했습니다. 이런 핵심 과정이 누락이 되어 개발에 착수하게 되니, 비즈니스 모델과 개발 결과물이 따로 놀 수밖에 없는 것이죠.

4. 미처 생각하지 못한 운영체계

비즈니스 모델도 완벽하고 정확하게 Matching 되는 개발 결과물이 나왔다면 성공적으로 서비스 런칭을 할 수 있을 것 같습니다.  하지만 여기서 문제가 발생합니다.

보통 IT 플랫폼 서비스의 경우, 제대로 된 매출이 발생하기 위해서 상당히 많은 사용자가 접속해야 합니다. 그럼 아래와 같은 문제가 발생하게 됩니다.

- 엄청난 인터넷 트래픽 발생 : Scale-out 가능한 시스템 구조로 미리 설계되어 있어야 함

- 사용자들의 다양한 반응 : 불만, 의견, 요구사항 등 피드백을 처리할 수 있는 고객대응 체계 갖추어져 있어야 함

- 예상치 못한 피봇 : 비즈니스모델은 늘 변하기 때문에 이에 대응할 수 있는 상품 개발/운영관리 체계 갖추어져 있어야 함

- 끊임 없는 시스템 기능개선 발생 : 안정적인 시스템 변경개발 관리체계 갖추어져 있어야 함

- 끊임 없는 시스템 보안위협 발생 (시스템은 항상 내가 원하는대로 안전하게 움직이지 않습니다) : 지속가능한 보안대응체계 갖추어져 있어야 함

즉, 개발을 완료하고 런칭을 했다고 해서 샴페인을 터트리기에는 아직 이릅니다. 운영 모드로 들어가면 생각지도 못했던 상황들이 발생하게 되고, 그에 맞게 대응해야 합니다.


그래서 비즈니스 모델에서 개발로 이어지는 과정에서 이러한 운영 측면도 고려하여 개발요구사항에 포함되어야 합니다. 실제 IT 플랫폼을 개발하여 운영한 경험이 없다면 알기 힘든 것들이기도 합니다. 




혹시, 스타트업에서 일하고 있는데 아래와 같은 문제가 있나요?

20년 이상 22개 이상의 프로젝트 경험과 70여 팀 이상을 코칭해온 다양한 노하우를 가진 전문가의 도움을 받아보세요!


▼ 코칭 받으러 가기 ▼

실시간 인기

    번역중 Now in translation
    잠시 후 다시 시도해 주세요 Please try again in a moment