[개발사 생존기] 완료금편 #2 / 4

저번 글에 이어 이번 글에서는 완료금이란 무엇이고 왜 받을 수 없는 지와 더 나아가 어떻게 하면 완료금을 잘 받을 수 있는 지에 대해 제 경험을 공유해보죠.

사실 망하는 길로만 이어져 있을지도...

벌써 주제를 보시면 정답은 없다는 것을 아실 수 있습니다. 저도 고작 구멍 가게 규모의 경험이다 보니 이게 일반적으로 다른 분들에게 도움이 될지 잘 모르겠습니다.

1편이 완료금이 안 들어올 때의 대처 방법이었다면,
2편은 개발이라는 특성 자체가 완료를 어렵게 만드는 내용입니다.

워낙 개발사란 범위가 넓기 때문에, 먼저 제 구멍 가게에 대해 잠시 설명 드려야 할 듯합니다.

완제품 만드는 개발사와 부분 코드를 만드는 개발사

개발물을 완료시킨다! 라는 주제 이전에 개발물이란 무엇인가? 을 정의해야 합니다.

개발사에 따라 엔드유저용인 완전한 프로그램으로 보는 경우와 어떤 프로그램의 일부로 보는 경우가 있습니다.

예를 들어 SI 구멍 가게의 경우 전체를 만들지 않습니다. 일부에 참여하여 일부의 코드를 생산하면 되죠.
하지만 저 같은 경우는 완제품을 수주하여 만들어 공급합니다. 회사가 작으니 이 규모에서 소화 가능한 범위의 일을 받아 그 전부를 만드는 거죠.

후자의 경우 단지 개발 코드를 작성하는 것 만으로는 제품이 만들어지지 않습니다. 기획, 디자인 등 제품 전체에 들어가는 모든 것을 만들 능력이 있어야 합니다.

나는 개발자인데 개발만 하고 싶은데!

라는 경우를 먼저 생각해보죠. 만약 코드만 다루는 개발사를 차리는 경우,

1. 완제품을 만드는 회사가 따로 있다는 것이고
2. 이 경우 긴밀한 협조가 필요하기 때문에 대부분 파견을 요구 받습니다.

즉 코드만 제작하는 대신 인하우스를 포기하고 파견사업이 될 가능성이 높습니다. 근데 파견이라는 건 작은 개발사 오너 입장에서 두 가지로 귀결됩니다.

1. 파견 보낸 직원이 잘하면 갑님이 그 직원을 뽑아가버려 인력손실이 날 것입니다. 보통 갑님은 구멍가게의 모든 조건보다 우월한 조건을 그 개발자에게 제시할 수 있습니다.
2. 파견 보낸 직원이 잘못하면 갑님이 열받아서 사장을 들어오라고 할 것입니다. 그럼 회사는 다른 모든 업무가 정지되고 곧 망합니다.

따라서 우아하게 코드만 만드는 개발사가 정말 좋은 거냐, 그리고 잘 운영할 수 있을 거냐? 라고 제게 물어보시면

굉장히 힘들고 수 많은 개발사가 2년 안에 없어지는 걸 매년 보고 있다

고 말씀드릴 수 있겠습니다. 파견을 가도 되는 경우는 경험 상 두 가지 뿐입니다.

1. 오너라기보단 직원이 없는 프리렌서 상태다.
2. 동업자 그룹으로 창업해서 한 지붕에 있어 서로들 파견나가 돈을 벌어온다.

두 개다 크게 보면 다 오너가 파견 나가있는 상태라고 할 수 있겠네요 ^^;

직원을 파견 보내면 망하는 느낌입니다. 만약 파견을 보내도 괜찮은 회사라면?

제게는 인력공급 회사가 되어 걍 주문에 맞게 사람만 파견하는 형태의 조직 외에는 잘 그려지지 않습니다.
실제로 이런 파견 회사가 엄청 많다는 것도 현실이지만 인력파견업이 개발자가 잘할 수 있는 분야는 아닌 느낌입니다.

캬..이러면 파견이 가능할지도...

그래서 저는 과감하게 파견과 코드만 만드는 개발사를 포기하고

완제품을 만드는 인하우스 개발사

를 회사의 방향으로 설정했습니다. 이 길이 어려워도 어짜피 앞의 선택지로 가면 망할 뿐이다! 라고 제 허접한 머리에서는 결론을 내린 것이죠. 이후 글의 모든 내용은 완제품을 만드는 인하우스 구멍가게를 기준으로 전개합니다 ^^
먼저 제가 완료금 못 받는 이유를 찾는 방법부터 말씀드리죠.

완료금을 못 받는 이유를 찾는 방법

우선 완료금을 받을 수 없는 이유는 여러 단계로 이루어져 있다는 사실을 이해해야 합니다.

그 단계 중 첫 번째 단계는 개발물 자체가 완료되지 않은 상황입니다.

개발물이 완료되어도 완료금을 회수하지 못할 많은 이유가 있습니다만(이건 3, 4편에서 다루고) 우선 완성이 안되는 이유를 알아야겠죠.

회사 다닐 때는 완료되지 않는 이유를 주로 자신 외부에서 찾습니다.

개발조직이 나빠서, 팀원 중 구멍이 있어서, 팀장이 엄해서, 회사의 스케쥴이 살인적이어서...등 회사 안 쪽을 다 찾고 나면 그 다음으로는 회사 밖을 찾습니다.

고객이 그지 같아서, 업계가 이상해서, 이번 계약 건이 잘못되서 등. 하지만 그 뒤로도 더 큰 범위로 잘못된 곳을 찾죠.

한국 IT생태계의 문제 때문에, xx년생들은 힘든 이유가 따로 있어서, 정부의 이번 시책이 큰 문제로 갖고 있어서, 더 나아가 헬조선이라서 등.

이게 옳지 않다거나 잘못 되었다는 게 아닙니다.

단지...오너가 되어서 그렇게 생각하고 있으면 누군가 봉급을 주지 않는다는 점이 핵심입니다. 해서 문제를

자기에게 있다라고 봐야 하는가?

라고 질문하면 그건 뭔가 다른 관점에서의 반대편을 찾은 것입니다. 제 생각에 오너가 직시해야 할 상황은

어떻게 해결할 수 있는가?

입니다. 나 때문이든 고객 때문이든 그건 중요치 않고 오직 해결을 할 수 있는 방향으로 문제를 정의해야 했습니다.
이러한 기본 관점을 전재로 개발물이 완료되지 않는 이유를 되짚어보고 해결책까지는 아니더라도 저의 좌충우돌기를 공유할까 합니다.

저도 제 맘대로 해보고 싶습니다만...

완료가 여러운 개발물의 특성과 대처

회사에서 직원으로 일하고 있을 때는 전체의 일부를 담당하기 때문에 자신이 하는 일이 가장 중요하고 어려우며 양도 젤 많다고 느끼기 마련입니다. 하지만 하나의 완제품을 제작해보면 보다 객관적으로 분량이 많은 곳과 난이도 있는 곳을 알 수 있습니다.

리소스

우선 분량으로 가장 많은 건 다름 아닌 리소스 입니다. 10메가짜리 앱을 만든다면 그 중 코드라는 건 고작 500k 입니다. 나머지는 이미지, 텍스트, 영상, 사운드 등의 리소스가 차지합니다. 이 리소스 관리를 제대로 못하면 적시에 제품이 완성되지 않습니다. 근데 이런 컨텐츠에 가까운 리소스는 왜 일정에 맞게 생산되지 않는 걸까요?

보통 가장 큰 이유는 고객사와 같이 만들기 때문이었습니다. 문건이 되었든 로고이미지가 되었든 고객사에게 받아야하는 게 많습니다. 하지만 고객사는 적시에 주는 법이 없습니다. 그렇다고 그것 때문에 일정이 미뤄지는 걸 수용하고 싶어하지도 않습니다(이걸 욕할게 아니라 인정해야 합니다 ^^)

따라서 리소스를 적시에 생산하여 일정에 차질이 안생기게 하는 요령은

어쨌든 다 내가 만들고 고객에게는 컴펌만 받는다!

입니다.

1. 개인정보보호정책도 업계 표준으로 일단 가져다 놓고 니들이 딴 거 안주면 이거다.
2. 회사 로고도 대충 보고 그리던가 검색에 나온 이미지로 쓰면서 니들이 딴 거 안주면 이거다.

대충 이런 식입니다. 이렇게 하려면 평소에 개발물 하나에 필요한 기본적인 리소스들을 항상 보유하고 있는 편이 낫습니다. 해서 저는 회사 nas에 많은 리소스(문서, 사운드, 영상, 이미지들..)를 갖고 있는 편입니다.

게다가 리소스는 전부 자신이 만들 수 없습니다. 영상회사, 사운드회사, 디자인회사, 법률회사 등과 일하게 됩니다.
우선 컨텐츠 부분에서 적시에 컨텐츠를 만들고 싶다면 직접 만들진 못해도 수정은 할 수 있어야 합니다.

예를 들어 웹사이트의 디자인을 디자이너에게 의뢰했다고 해보죠. 그럼 디자이너에게 결과물을 수령하는 방법은 굉장히 다양할 것입니다.

1. 퍼블리싱된 결과대로 png, jpg로 일일히 잘라서 받기
2. PSD나 AI로 받기
3. 제플린으로 받기

우선 1번의 경우를 생각해보면 퍼블리싱하다가 조금만 변경되어도 디자이너에게 수정요청을 해야 합니다. 그럼 디자이너는 이미지를 잘라서 주는 과정에서 커뮤니케이션으로 일정이 소진됩니다.

2번으로 받는 경우는 어떨까요?
그럼 본인이 이 psd로부터 jpg나 png로 이미지를 잘라낼 능력이 있어야 할 것입니다. 대신 디자이너는 크리에이티브만 신경쓸 수 있어 빨리빨리 디자인 작업이 진행될 뿐 아니라, 퍼블리싱 쪽에서도 수시로 사정에 맞춰 이미지를 잘라내면서 작업할 수 있을 것입니다.

더 나아가 3번을 선택한다면 디자이너도 개발자도 크게 신경쓰지 않고 툴이 적당히 정리해준 자료를 기반으로 개발하게 될 뿐 아니라 디자이너의 수정 내용도 즉시 변경된 형태로 보고 되고 개발자도 이걸 보면서 수정하면 그만입니다.

제 경험 상 많은 개발자는 당연히 1번을 선호하려고 합니다.

다 모르겠고(==귀찮고) 나에게 정리된 리소스가 와야한다. 난 코드 외엔 아무것도 모른다.

이게 말이죠 회사 다닐 땐 그래도 상관없는데, 개발사를 차리고 나면 이걸 견지할 때마다 어마한 디자이너 공수 비용과 일정이 늘어지는 걸 경험할 수 있습니다. 결국 2번 이후의 선택지를 고르게 되고 어느 새 포샵도 잘하고 일러도 잘하고 제플린 참 좋네~ 이러는 단계로 가야 먹고 살만해 집니다.

제 경험을 간단히 추리자면 다음과 같네요.

• 이미지를 만들진 않지만 포샵으로 그걸 잘라내거나 좀 변경할 수는 있다.
• 동영상을 만들진 않지만 프리미어로 그걸 잘라내거나 좀 변경할 수는 있다.
• 3D모델을 만들진 않지만 맥스나 마야로 포즈 좀 바꾸거나 조명을 조정해서 렌더링할 수는 있다.

즉 간단히 말해

x를 만들진 않지만 y로 x를 변경하거나 조정할 수는 있다.

이게 안되면 리소스에서 엄청난 일정이 소요되어 적시 납품이 물 건너 가버렸습니다.
이걸 할 팀원을 구성하시든, 아니면 본인 이하 전원이 이 능력을 갖추시든 쨌든 이 역량을 갖는 걸 추천 드립니다.

리소스가 마감 때 철야를 부릅니다...

뷰 개발

코드 외적인 리소스를 해결했으면 이제 코드에 집중할 수 있습니다. 헌데 대부분의 개발 프로젝트에서 멋진 아키텍쳐, 서버파트의 복잡한 비지니스로직 같은 게 중요하다고 생각해오셨을 겁니다. 딱히 틀린 말은 아니지만 물리적인 양을 보면 압도적으로 뷰입니다. 해서 반드시 뷰를 해결할 방법을 강구해야 합니다.

일반적으로 뷰 개발은 서버 개발과 굉장히 다른 부분이 하나 있습니다. 바로 라운드 트립 입니다. 서버에서 최종적으로 생성된 뷰는 그대로 클라로 전송되기 때문에 다음 턴에 라운드 트립이 발생하고 그 과정에서 상태를 재정비하거나 메세지의 연속성을 나눌 수 있는 찬스가 많습니다(요청, 응답이라던가)

헌데 뷰는 끝없이 유저 인터페이스와 상호작용하면서 빈번한 클라 내의 라운드 트립이 발생하기 때문에 MVC같은 게 금새 헬이 됩니다. 게다가 서버의 복잡한 비지니스 로직 이상으로 렌더링 시스템을 효율적으로 사용하는 것도 굉장한 난이도입니다.

1. 안정적이고 모델에 기반하여
2. 정확하고 신속하게(성능) 그려질 뿐 아니라
3. 잦은 인터렉션 후에도 안정적으로 유지되고
4. 특정 상태에 대한 복원이나 수정도 손쉬운

뷰 솔루션을 확보하지 못하면 엄청난 인력을 뷰에 소모하여 적자를 보거나 적시 납품이 불가능해집니다.
특히 위의 조건을 다 갖춰도 가장 중요한 게 하나 더 있습니다.

고객은 뷰를 수시로 수정한다

라는 점입니다. 그것도 기저 구조에서 스킨까지 전 아키레이어에서 발생합니다. 뷰 솔루션은 반드시 수정에 강해야합니다. 반드시 대량의 뷰를 안정적이고 신속하게 개발할 수 있는 방법을 강구하시길 권합니다.

5%의 어려운 부분

경험 상 일을 수주해보면 95%의 할만한 부분과 5%의 극강의 난이도로 된 부분이 있다는 생각을 항상 합니다.

그 5%부분은 난이도가 높아서 꽤 실력 있는 개발자가 아니면 아무리 시간을 투입해도 해결되지 않습니다.
그럼 고객은 그 부분 때문에 완료를 인정하지 않게 됩니다. 왜냐면 바로 그 어려운 5%야말로 외주를 맡긴 이유라서 아무리 95%가 되어있어도 인정할 수 없는 경우가 대부분이기 때문입니다.

이 5%부분이 굉장히 심각해서 제 주변의 많은 개발사는 주로 끝에 끝에 끝까지 해결하지 못해 회사가 문닫는 경우가 많습니다. 이는 개발사 뿐만이 아닙니다. 많은 스타트업들이 돈도 있고 오너가 인맥도 있으며 비지니스 모델이나 마케팅 역량이 좋은데도 그 5%를 해결 못해 제품 출시가 안되어 결국 모든 돈을 다 탕진하고 망하는 경우가 제 경험 상엔 오히려 대부분을 차지합니다.

잔챙이들이 여럿 모여봐야 소용없습니다. 이 난이도는...

저희 고객 역시 그렇습니다. 주로 이런 구멍 가게에 찾아오실 때는 번지르르한 큰 개발사에서 중견 개발사까지 싹 돌아보면서 의뢰했으나 그 5%가 해결 안되어서 갸들과는 소송 중이고 다 털리고 난 뒤 남은 돈이라도 긁어모아 어디서 소문듣고

니들이 이거 만들 수 있다며?

이러고 오시는 경우가 대부분입니다. 제가 만약 그 5%를 해결할 방법이 없었다면 별 수 없이 개발사 접었어야 했을 거라 생각합니다. 2017년에 일어났던 현실 세계의 5%를 몇 가지 소개하겠습니다.

• 태반 우커머스로 되지만 이 여행사의 특수한 환경 때문에 기능이 하나 들어가는데 그게 거의 전면 재구축하여 플러그인을 재작성하게 만든다.
• 리액트에 머티리얼 테마로 뷰를 깔았는데 주문페이지의 특수한 뷰가 해결되지 않아 애니메이션 스택부터 재구축하여 퍼포먼스를 확보해야 한다.
• 접속 중인 AP나 라우터의 mac주소로부터 자신의 네트웍을 인식하는 솔루션인데 iOS가 이를 못쓰게 막아서 해결방법을 강구해야 한다.
• 원래 공장자동화 시스템의 일부로 내부 스토리지에서 c++로 돌던 건데 웹으로 모니터링하고 싶다. 근데 1초에 2메가 이상의 로우데이터가 쉬지않고 365일 들어온다.

보통 이렇죠. 돈되고 쉬워보였는데 그 5% 때문에 갑자기 헬로 변하거나 크게 개발비용이 들어가는 일로 변신합니다.

오너는 자신 또는 회사 전체(많아야 5명)를 이용해 이러한 문제를 정해진 예산과 일정 안에 해소해야 합니다.

우선 당연히 이걸 해소할 능력자가 사내에 존재해야 합니다. 이 부분을 외주 줘봐야 소용없습니다(그쪽도 해결 못합니다 ^^)

하지만 그 능력자가 사내에 있어도 여전히 문제가 해결된 것은 아닙니다. 그 능력자는 보통 희귀하기 때문에 구멍 가게에 여러 명 있을 확률이 거의 없습니다(사실 이 능력이 있으면 창업이 가능하거든요 ^^)

그래서 그 능력자가 곧 회사의 병목 지점이 됩니다. 모든 프로젝트가 다 끝나있고 그 능력자가 해결할 5%만 대기하는 상태로 빠지는 거죠.

게다가 5%라는 게 양도 적은 것은 아닙니다.

예산 규모에 따라 5%라 할지라도 양이 많을 수 있습니다. 헌데 여러 프로젝트의 5%가 전부 한 사람에게 몰리게 되면 그 사람도 지쳐서 그만두고 회사도 전부 돈이 거기에 묶이게 됩니다. 마치 개발사란..

계약하는 건마다 일정 내에 불치병 치료제를 만드는데 성공시키기

같은 거랑 비슷한 상황입니다. 불치병 치료제를 연구한다고 정해진 시간 내에 만들어지는게 아닌데도 계약서엔 완료일이 명시되어있는 거죠.

제가 보기엔 이게 바로 진정한 개발 계약의 의미입니다 ^^; 따라서 개발물을 완료시키려면

1. 능력자가 손쉽게 5%를 해결하는 환경을 갖추던가
2. 능력자를 여러 명 데리고 있던가

위의 두 가지 중 적어도 한 가지 혹은 두 개 다를 해야 합니다. 보다 구체적으로 알아보죠.

1번을 구축하려면 능력자를 최대한 모든 업무에서 배제 시켜야 합니다.

한 명이 아쉬운 구멍 가게에서 이 결정이 쉽지 않습니다. 그렇지만 능력자를 보호하는데 실패하면 모든 계약이 완료되지 않을 것입니다. 따라서 능력자는 5%문제에만 집중할 수 있게 회사 전체 모양까지 다 바꾸시는 걸 권합니다. 만약 오너가 그 회사의 능력자인 경우도 동일합니다.

어떻게든 5% 문제에만 집중할 수 있는 환경을 구축해야만 하고, 만약 다른 게 우선 순위를 갖으면 굉장한 확률로 망하게 될거라 예상됩니다 ^^

2번은 모순되지만 해결해야 하는 어려운 과제입니다. 능력자는 보통 큰 회사에 가거나 자기 회사를 차립니다.
근데 어떻게 구멍 가게에서 능력자를 보유할까요?

(네 생각하시는 그겁니다^^)

살을 주고 뼈를 얻으세요. 실제 회사의 소유권 일부를 넘기거나 수익을 쉐어하거나 어떤 형태든 상관없습니다. 이면계약서를 쓰셔도 괜찮구요. 그 능력자가 여기에 있는게 더 나은 이유를 금전적으로 확립시켜 주는 수 밖에 없습니다.

니가 어딜가든 여기가 더 좋은 곳이다

를 제안해야만 능력자를 데리고 있을 수 있습니다. 제 생각에 예외는 없습니다 ^^

헌데 구멍가게에 그럴 여유가 많을리가 없죠. 따라서 지분을 나눌 파트너도 한 두 명이 한계고 큰 돈을 보장해줄 수 있는 대상도 한 명 정도가 한계네요. 신중히 고르고 다 년간 외부에서 검증하여 회사에 능력자를 합류 시키세요.

저도 약하고 머리 나쁘고 눈빛도 사납고 분위기 못 읽어요, 하지만...

일단 저는 이 방법 밖에 모르겠습니다. 저도 위의 방법으로 저희 CTO를 얻고 언제나 조직 운영에서 CTO가 핵심 5%에 집중할 수 있게 연구하고 실행하고 있습니다(짜피 이 글 전체가 제 경험인지라 ^^)

결론

이번 글에서는 개발이 완료되지 않는 개발 자체의 특성을 설명드렸습니다. 솔루션까지는 아니더라도 저는 어떻게 극복하고 있는지도 살짝 말씀드려봤습니다.

3편에서는 개발이 완료되지 않는 사내의 문제와
4편에서는 개발이 완료되지 않는 고객의 문제를

공유해드릴까 합니다. 많이 많이 보팅해주세요~ 댓글도 많이 달아주시고 ^^

P.S 그리고 전 그냥 development 태그로 계속 가려고 합니다. 영어의 숲에 홀로 한글로 된 포스팅인 것도 맘에 들고 전부 부동산 개발이나 토지 개발 사이에 IT개발사 얘기가 껴있는 것도 뭔가 맘에 드네요 ㅋㅋ