스타트업, SI개발자를 채용해도 될까?

 

 

SI 하다가 "스타트업”으로 가는 개발자.

그런 사람을 채용해야 하는 CEO를 위한 글이다.

 

성공한 경험도 있고, 실패한 경험도 있다.

원인과 결과는 매우 닮아 있었다.

실패도 재현가능하고 성공도 재현가능하다.

 

미리 알면 피해갈 수 있다는 뜻이다.

사례 하나에 불과하겠지만, 도움이 되면 좋겠다.

 

서비스 만들기

인프라부터 서비스까지 만들어야 했다.

서비스를 운영해서 돈까지 벌어야 했다.

“User”를 모으고 Activity 를 만들어내야 했다.

 

맨땅에서 시작하다보니 경험있는 친구들이 필요했다. 

흔한 사업이 아니다보니

경험 가진 친구를 구하기 힘들었다.

 

일부라도 해봤던 친구들을 구해야 했다.

SI 분야 밖에 없었다.

 

다행히 모두 좋은 친구들이었다.

태도까지 굉장히 훌륭했다.

빠른 성과와 목표달성에 아주 잘 훈련되어 있었다.

 

집중력도 높았다. 

척하면 척이라 일할 맛도 났다.

뭐가 안될 것 같은 상황에서도 어떻게든 만들어갔다. 

짧은 시간 안에 꽤 근사한 시스템이 만들어졌다. 

 

프로젝트가 끝나자

문제는 그 다음이었다. 

프로젝트가 끝나자 모든게 멈추어버렸다.

이 친구들이 목표를 상실한 것이다.

 

SI만 하던 친구들이라 

시스템 오픈은 곧 프로젝트 종료를 의미했다.

그 누구도 오픈 이후를 겪어본 적이 없었던 거다. 

 

하아…

많은 이야기를 나누었지만,

설득시키는데는 실패했다.
고집을 부리거나 한 건 아니다.

그냥 모르는 영역이었다.

모르는 영역을 설득하기란 생각보다 어렵다.

이후로는 누군가를 설득하지 않게 되었다.

 

그렇게 우리 사업은 실패해갔다.

구축은 성공적으로 했지만,

운영과 사업에는 실패한거다.

 

일하는 방법의 차이

SI는 남에게 일을 시키는 거다.

무엇을 개발해달라고 할지 주문서로 만들어야 한다.

"요구사항정의서"가 개발일의 시작점이 된다.

 

내 서비스는 다르다.

일 시킬 사람이 없고, 내가 직접 해야 한다.

무엇을 개발할지 직접 정리하면 된다.

 

간단히 만들고 싶은 걸 적고,

바로 어떻게 만들지를 결정하면 된다.

Backlog 와 Specification 이다.

 

SI는 남에게 보여줘야 하기 때문에

파워포인트와 엑셀에 정리를 한다.

내 서비스는 내가 볼거니까

간단히 “구글문서도구”에 정리하면 된다.

 

어려운 말로 하면

"Requirement Engineering",

"Scrum" 등등이라고 하는데… 

설명하면 기니까 일단 넘어가자.

 

욕구

세상에 없는 걸 만들거나,

아무도 해본 적이 없는 걸 만들때는

나의 욕구가 일의 시작점이 된다.

아무런 욕구가 아니라, 훈련된 욕구여야 한다.

 

욕심, 희망, 꿈이 아니라

“욕구”라고 표현한 이유도 있는데,

일단은 넘어가자. 

 

그런데 이 친구들은 욕구를 가져본 적이 없었다.

욕구를 끌어내고,

구체적인 그림으로 그리고,

시장을 조사한 후 할일을 정해서

개발스펙으로 작성해보는 것.

그 일을 훈련해 본적이 한번도 없었던 거다.

 

음.

정말 어려운 벽에 부딪혔다.

 

스타트업

한 사람이 모든 걸 통제하는 방식은 생각보다 효율적이다.

하지만 언제나 효과적이진 않다.

적정규모를 넘어서면 빠른 속도로 효과를 상실한다.

각 부서가 효율적으로는 일하긴 하지만,

돈을 전혀 못버는 비효과적인 조직으로 바뀌어버리고 만다.

 

그래서 대부분의 스타트업은 효과성을 증명한 다음 

효율성을 높이는 방법으로 진화해간다.

이거 헷갈리는 CEO들이 생각보다 많다. 

 

암튼 One man Leading 방식을 사용하려면

리더가 지시받는 자보다 더 많이 알아야 하고,

판단은 틀리지 않아야 하며,

여러가지 변수도 함께 고려한 것이어야 한다.

모든 걸 알고 있어야 하는

Super Micro Managing 방식인 것이다.

 

그러려면 리더가 그 일에 정통한 사람이어야 한다.

하지만 새로운 사업이라면 그런 사람이 없다.

사장도 사실 사장일 뿐 그냥 초보자에 불과하다.

모든 창업이 다 그렇다고 봐야 한다.

 

그럴 땐 다수의 힘을 쓸 수 있어야 한다.

다수의 힘이란 다양성에서 나오는 에너지를 말한다.

 

그런데 다수의 힘에선

부정에너지도 나오고 긍정에너지도 나온다.

잘 통제되지도 않는다.

 

다소 새로운 훈련방식이 필요한데,

이런 걸 "기업문화"라고 한다.

 

각자가 자신의 전문성에 자부심을 느끼면서

자기계발을 통해 나오는 아이디어가

새로운 일에 잘 반영되고,

그걸 조직원들끼리 잘 관찰해서

서로 도움을 주는 방식으로 일이 되는 것.

요즘말로 "집단지성"이라고 한다.

 

"진짜 이런게 가능해?"

"응, 가능해. 더구나 적지 않아."

내 눈에 안보이니까 그런 회사가 없는 줄 안다.

하지만 있다. 적지 않다.

 

100점짜리 회사는 이론속에서만 존재한다.

60점짜리 회사는 많다.

그 정도만 되어도 회사는 꽤 잘 굴러간다.

 

시작

스타트업의 시작은 누가 뭐래도 "Why?" 다.

"Why" 를 풀려면 “Who”를 생각해야 한다.

당연히 “Whom”, “How”, “When”도 생각해야 한다.

그게 집중이다.

모든 사람을 타겟으로 하지 않고,

돈 줄 사람을 먼저 타겟해야 한다.

 

온라인 서비스에도 “Where”가 있다.

“네이버에서 검색하다가”

“구글에서 검색하다가”

“스마트폰에서 다른 앱을 보다가”

이런게 Where 다.

 

아쉽게도 SI 친구들은 이런 것과는 거리가 멀다.

“욕구”는 “사업계획서”나

정제된 형태의 “개발요구사항정의서”로만

전달받기 때문이다.

 

SI 친구들이 나쁘다는 게 아니다.

굉장히 복합한 인프라시스템을

단시간 내에 만들어야 한다면,

SI 업체에 의뢰하는게 백배 더 낫다.

 

이것도 나중에 길게 한 번 이야기하겠다.

 

하지만 서비스 실험이 동반되는 사업이라면

SI 에만 있었던 친구들을 쓰는 건 굉장히 위험하다.

 

무엇이 중요할까?

스타트업이라면 어떻게 해야 할까?

 

SI개발자를 스타트업에 쓰는 일은

이 경험 이전에도 있었고, 이후에도 있었다.

성공한 적도 있고, 실패한 적도 있다.

 

CEO가 개발을 잘 알고 있고,

개발자를 잘 이해하고 있다면 비교적 큰 문제가 없다.

 

하지만, 그렇지 않다면 사람을 가려야 한다.

"반드시" 그렇게 일하는 개발자를 뽑아야 한다.

 

이게 안되어서

개발자로부터 배신당했다고 생각하는

CEO 분들을 몇 분 뵈었다.

 

사실 SI 냐 아니냐는 "핵심판단기준"이 아니다.

"어떻게 훈련된 사람이냐."

이게 더 중요하다.

 

뭔가를 만들려면

그걸 만들고 싶어하는 개발자와 일을 해야 한다.

 

"뭘 할 줄 아세요?"

이건 단순히 만드는 게 목적일 때 하는 질문이다.

 

스타트업이라면 이런 질문이 더 어울린다.

"뭘 하고 싶으세요?"

"왜 하고 싶으세요?"

 

※ 요약

개발자의 세계도 넓다.

맞는 개발자를 찾아야 한다.

또는 맞는 개발자가 되어야 한다.

(해보면 어렵지 않다.)

 

끝.