호구가 겪은 외주 개발사 이야기 -1화-

 2012년 야심차게 준비한 아이디어를 들고 당당하게 방문한 대구의 SI 업체에서 처음 들어보는 다양한 용어들과 당시 엄청나게 비쌌던 견적과 어설펐던 창업에 대한 이야기다.

개발이라는 것을 실제 사업(BM)에 기반하여 해보는건 처음이라, 학교때 아는 선배가 팀장으로 있는 업체를 찾았다.

그곳에서 나의 아이디어를 한시간가량 설명을 했고, 그걸 들은 담당자는 우선 난색을 표했다.

 

”어떤걸 만들기를 원하세요? 설명해주신게 이해가 안되요.”
- 이 말을 하기전 메인 개발자는 다된다고 이야기를 했다.

 

그때 빨리 던지고 자리를 일어서야 했다… 하지만 그때는 그런 상황도 처음이었고 당황하면 왠지 지는것 같아 미친듯이 우리 아이디어의 정당성과 명확함을 설명하려 애썼다.

어떠한 사업아이템이든 설명에 3분이상 걸리면 이미 글렀다고 생각했어야 했다.

이미 그때부터 내 아이디어는 아직 미완이었다는 사실을 인정하기 싫었는지 변명같은 답변만 늘어놓았다.

그리고 기나긴 실랑이 끝에 ’구현가능정의서’라는 hwp로 된 정체불명의 문서하나를 받게 된다.

지금 들여다보면 이 문서가 개발자에게 어떤 의미의 문서였는지 이해가 된다. 무엇을 어떻게 만들고 싶냐는 원초적인 의문에 정말 원초적으로 답하는 문서이다.

개발사에서 제시한 구현가능 정의서

여기서 잘못된 상황이 하나가 있다. 그 개발사에서는 기획자에 대한 M/M를 넣지 않았고 누군가 그 기획을 해주어야만 가능한 상황이었다는 사실을 뒤늦게 알았다.

무식하게 페이지 하나하나를 다 그리고 내용을 넣고 전달을 했다. 하지만 정작 필요했던 문서였는지는 모르겠다. 지금 생각하면 아래의 문서들이 필요했을 것이다.

 

1. 사업기획서 RFP 형식
2. 요구사항 정의서
3. 화면기획서(SB)
4. 서비스 정책서
5. 필드 정의서

적어도 위에 문서들이 정리가 되었어야 이후 개발에서 빠그러진 상황을 커버할 수 있었을 것이다. 그리고 최소한 꼭 받았어야 하는 산출물은 다음과 같다

 

1. 프로그램 목록
2. 수용합의서
3. ERD

적어도 위에 문서를 받음으로써 내가 확인할 수 있는 사항은 개발사가 내 요구사항을 이해를 했느냐? 또 그 요구사항을 적절하게 설계했느냐? 그리고 내 요구사항을 견적에 대비하여 어디까지 구현해 줄 것이냐? 적어도 이정도는 내 돈을 들여서 내 자식이라 생각하는 플랫폼에 대한 열정이 있었어야 했지만 당시 그 순간은 너무 몰랐고 몰랐던것은 내 잘못이었다.

 

 

적다보니 글이 길어진다. 자꾸 과거를 후회하는 식의 표현이 될까 썼다 지웠다를 반복하는 시점에서 최대한 잘 다듬어 올리고 싶은 마음에 회차를 나누어 정리할까 한다.

이 글은 가슴으로 느껴 머리로 적는 글이 되었으면 한다.