소프트웨어 개발, 외주 개발, 실패하는 이유는 한방에 최종 그림을 받으려 하기 때문

소프트웨어 개발은 다른 어떤 제품보다도 중간 커뮤니케이션이 중요하다.

만드는 과정이 눈에 보이지 않기 때문에 상상하는 모습만 던져놓고 개발 완료 후 결과물을 보면 분명히 마음에 들지 않게 나온다.

 

회사내 자체 제품 개발이든, 외주 개발이든 이런 실수를 하는 경우가 많다.

하얀 종이에서 시작해서 개발이 완료된 후에 완성된 작품이 짠 하고 그려져 있기를 원한다.

하지만 그 결과물은 내가 생각했던 것과는 완전 다른 수준일 가능성이 크다.

 

그래서 실패 확률을 줄이기 위해 현업에서는 매일 매일 커뮤니케이션을 하고,

중간 결과물을 놓고 계속 조정하는 과정을 거친다.

 

외주 개발도 마찬가지여야 한다.

단, 외주를 의뢰하는 클라이언트측은 전문가가 아닌 경우가 대부분이므로

개발사에서 적극적으로 소통하고 중간 중간 결과물을 들이밀어야 한다.

오류를 빨리 찾을 수록 해결 비용도 낮아지는 것은 당연한 이치다.

클라이언트도 빨리 멋진 최종 모습을 보고 싶겠지만 그게 불가능하다는 것을 인정하고 개발 과정에 적극적으로 참여해야 한다.

최종 사용자에게 멋진 모습을 보여주려면 나와 개발사가 지저분하고 불편한 모습을 놓고 소통하며 만들어 나가야 한다.

 

스케치 단계(~10%)

처음에 하얀 종이를 받았다면 여기에 스케치를 한다.

이 때는 선도 거칠고, 형태도 대충 그려져 있다.

하지만 어떤 구조를 거쳐 그림이 완성될지 가늠해 볼 수 있다.

이렇게 러프한 스케치 단계에서 부터 커뮤니케이션을 하면서 최종 결과물에 대한 기대치를 서로 동일하게 맞춰 나가야 한다.

클라이언트 입장에서도 스케치 단계에서부터 적극적으로 참여하여 피드백을 제시해야 한다.

전체 개발 완성도로 따졌을 때 이 단계는 한 10%정도 될까말까 한 상태다.

UI, UX도 목업 버전으로 들어가 있어 외형적으로는 볼품없는 모습으로 보인다.

이 단계는 전체 뼈대를 맞춰나가는 단계다.

어떤 페이지가 존재하고, 어떤 경로로 이동하는지를 판단하는 과정이다.

건물로 치면 뼈대 구조물을 세우는 작업이고, 그림으로 치면 연필 하나로 쓱쓱 스케치 하는 단계다.

생각한게 이게 아니라면 지우개로 지우고 다시 선을 그리면 된다.

이 때 수정하는 작업은 별로 비용이 들지 않는다. 그냥 스케치 하는 과정 중에 하나이다.

 

색상 입히기(~15%)

기본 스케치를 통해 구도와 방향성이 잡히면 여기에 대략적으로 색상을 입혀본다.

이 때도 소통은 필수다.

내가 원하는 색과 개발사가 원하는 색은 다를 수 있기 때문이다.

또한 이런색을 원했는데 직접 실물을 보니 전혀 다른 느낌이 날 수도 있다.

이 단계에서 이런 문제점을 캐치한다면 수정하는 비용은 크지 않다.

UI컬러 테마는 어떤 색으로 잡고, 버튼 사이즈, 전반적인 뷰의 모습등을 논의하여 맞춰 나간다.

물론 이 때도 목업 버전이 사용되고 한두 페이지 정도는 최종 모습을 만들어 볼 수는 있다.

하지만 아직도 결과물은 볼품 없고 투박하고 거칠다.

이 물건이 과연 쓸만하게 나올까 싶은 걱정이 있겠지만 현재는 극초반 과정이므로 불안해하지 않아도 된다.

 

 

본 작업 들어가기(~90%)

이렇게 기본 스케치와 색상에 대한 서로의 공감대가 형성되었다면 본격적인 작업에 들어간다.

거칠게 작업했던 UI/UX도 부드럽게, 완성도 있게 다듬고

임시로 작성했던 코드도 깔끔하게 구조화 하고,

정식 버전에서 사용할 데이터 구조까지 확정짓는다.

목업 데이터, 목업 서버로 구현했던 부분들도 정식 개발에 들어간다.

물론 이 과정에서도 꾸준히 커뮤니케이션 해야 한다.

거의 최종 모습에 근접할 정도까지 서로 생각하고 있는 바를 다 쏟아내어 맞춰야 한다.

최종 제품의 90%까지 완성한다는 목표로 작업에 들어간다.

수치로 딱 자를수는 없지만 개발단계가 5~10% 진행 될 때 마다 커뮤니케이션을 해야 나중에 말썽이 없다.

이 과정에서는 작은 구간별로 만들고 돌아가고, 다시 또 만들고 돌아가고 하는 일이 반복될 수 있다.

하지만 이미 스케치와 기본 색감은 맞춰놓은 상태이므로 조금씩이지만 진전이 되는게 보일것이다.

다시말하지만 중간에 '어 이게 아닌 것 같은데' 라는 생각이 들면 바로바로 묻고 해결해야 한다.

잘 되겠지 하고 그냥 놔뒀다간 나중에 큰 비용을 다시 치뤄야 한다.

 

폴리싱(~100%)

마지막으로 폴리싱이 남았다. 마지막 다듬는 단계다.

여기까지 왔으면 지금 보는 모습이 거의 최종 모습에 가까워져 있을 것이다.

그동안 5~10%단위로 계속 소통해오며 기대치를 맞춰왔기 때문이다.

이 단계에서는 미처 확인하지 못했던 불편 사항이라던가, 깔끔하지 못한 부분, 좀 더 매끄러웠으면 하는 부분을 작업한다.

더이상 큰 구조 수정은 불가능하다. 특히 코드에 영향을 미칠만한 수정은 피해야 한다.

안전하게 격리화된 부분만 수정할 수 있다.

UI색상 교체라던가, 폰트 교체, 텍스트 문구 변경등 이미 구조가 짜여져 있고 그 위에 얹기만 하는 부분들은 작업 가능하다.

하지만 폰트를 바꿨더니 UI가 엉망이 되는 경우도 있으므로 이 또한 급격한 변화는 불가능하다.

버튼 위치를 바꾸는등 레이아웃 교체는 신중히 해야한다.

쉽게 되는 경우도 있지만 코드 구조까지 다 바꿔야 한다면 시간과 비용이 늘어날 것이기 때문이다.

 

이렇게 간략하게만 봐도 4~5단계가 필요하다.

각 단계별로 5~10% 진행될 때 마다 소통하는 것 또한 필수이다.

전체적으로 보면 30일을 작업한다고 했을 때 최소 3일에 한번씩은 의견 교환이 필요하다고 본다.

총 10번정도는 의사소통을 하는 셈이다.

현업에서는 거의 매일 체크를 하지만 외주 개발인 경우 그게 불가능할 수 있으므로

최소한 일주일에 두번은 진행상황을 파악하는 것이 좋다.

프로젝트 기간이 두달, 세달 이어진다면 수십번 이상 소통해야 하는 것이다.

만약 이런 과정을 거치지 않고 초기 미팅, 중간 미팅, 마지막 미팅 이렇게 간략하게 끝내려고 한다면

결과물은 마음에 들지 않게 나올것이다.

 

물론 개발사에서는 자주 커뮤니케이션 하는걸 싫어할 수 있다.

나도 개발자이지만 작업하는 중간 중간에 대응하는건 작업 효율을 갉아먹는 것이라는걸 너무나 잘 알고 있다.

그래서 클라이언트 보다는 개발사가 적극적으로 나서서 소통하는게 중요하다고 본다.

어느 시점에 어느 부분을 논의 해야 할지는 개발 지식이 있는 쪽이 더 잘 알기 때문이다.

억지로, 마감 맞추려고 허둥지둥 준비하는게 아니라 그 때 그 때, 클라이언트가 귀찮을정도로 나서야 한다.

 

클라이언트 또한 가만히 앉아서 보고서로 보고 받는다는 생각은 버려야 한다.

그건 나중에 정리해서 줘도 늦지 않는 것이고,

중간 커뮤니케이션은 직접 전장에 뛰어들어 날아오는 총알을 피해가며 진흙탕 속에서 소통하는거라고 생각해야 한다.

결정권자는 그만큼 피곤한 것이다.

하지만 나중에 돈 날리는 것 보다는 중간에 피곤한게 훨씬 낫다고 본다.

 

소프트웨어 개발이 기존의 전통적인 제조, 건설등과 다른 부분은 개발 과정이 눈에 보이지 않는다는 것이다.

건물을 짓는 것을 보면 땅을 파고, 기초를 다지고, 뼈대를 세우고, 살을 붙이는 과정이 눈에 보인다.

숨기고 싶어도 숨길 수가 없다.

소규모 인테리어도 마찬가지다. 초반에 철거가 끝나면 그 뒤로는 다시 철거 과정으로 돌아가지 않는다.

도배, 장판, 타일, 페인트 모두 순서가 정해져 있다.

그리고 각 공정마다 큰 변수가 없다면 미리 정해진대로 일정이 진행된다.

특별한 작업이 아닌 이상 일이 규격화 되어 있고 사회 전반적으로 그동안 쌓인 노하우가 많기 때문에 예측 가능한 것이다.

 

하지만 소프트웨어 개발은 개인에서부터 대규모 업체까지 누구나 작업할 수 있다.

규모가 크다고 체계가 있는 것도 아니고, 개인이라고 엉망으로 작업하는 것도 아니다.

개발 과정 또한 눈에 보이지 않아 개발사에서 결과물을 보여주기 전 까지는 제대로 되고 있는지 확인할 길이 없다.

건물이라면 10층 빌딩을 발주했는데 2층짜리 벽돌집이 나오는 경우는 없을 것이다.

하지만 소프트웨어 개발은 얼마든지 이런 상황이 나올 수 있다.

똑같은 결과물을 놓고 내가 볼 땐 2층 벽돌집이지만 개발사는 10층 건물이라고 말하는 상황이 발생할 수 있다.

 

그래서 소프트웨어 개발이 어려운 것이고, 이런 조율과정을 전문적으로 하는 직군도 있다.

작은 규모에서는 개발자나 기획자가 하기도 하고, 큰 회사는 전문적인 PM이 있다.

이런거 다 신경쓰고 싶지 않고 돈을 더 들이더라도 알아서 해주길 바라는 경우라면 그런 부분을 케어해주는 업체를 쓰면 된다.

중간 커뮤니케이션 다 해주고, 결과물 검수 해주고, 클라이언트와 개발사 왔다갔다 하면서 프로젝트 진행을 다 맡아서 해주는 경우도 있다. 하지만 내 물건을 만들거라면 내가 제일 신경을 많이 써야 하는건 당연한 사실이다.