목차
안녕하세요, 케이트리솔루션입니다.
계약서에 적힌 기능은 하나도 빠짐없이 만들었습니다. 일정도 지켰고 오류도 없습니다. 그런데 오픈하고 나니 결과물을 본 대표님이 묻습니다.
“왜 이렇게 나왔죠?”
개발 외주에서 드물지 않게 벌어지는 장면입니다. 저는 이 문제의 원인이 실력이나 계약서보다 결정권자와 실무자 사이의 균형에 있다고 봅니다. 무엇을 결정권자가 정하고, 무엇을 실무자에게 맡길지가 어긋나면 계약을 다 지켜도 아무도 만족하지 못하는 결과물이 나옵니다.
저는 인하우스 개발자로 일했고, 창업한 뒤로는 개발 외주로 컨설팅, 홈페이지, 플랫폼, 서비스 제작을 해 왔습니다. 회사 안에서도, 회사 밖에서도 비슷한 문제를 봤기 때문에 양쪽 이야기를 함께 해 보겠습니다.
인하우스 개발팀에서 흔히 생기는 일
회사 안의 개발팀에서 자주 보는 경우가 있습니다. 대표님이 기획, 디자인, 개발의 세부 사항까지 직접 정하는 구조입니다.
처음에는 실무자들도 의견을 많이 냅니다. 이 방법이 더 나을 것 같다, 이건 나중에 문제가 될 것 같다고 건의합니다. 그런데 그 의견이 반영되지 않고 결정이 혼자 내려지는 일이 반복되면 상황이 달라집니다.
대표님은 A라는 기능을 원합니다. 실무자 눈에는 A를 만들 때 함께 따라오는 문제들이 보입니다. 그 이야기를 꺼내면 돌아오는 답은 이렇습니다.
“그건 지금 중요한 게 아니에요. 일단 진행합시다.”
정책과 비즈니스 모델이 일주일이 멀다 하고 바뀌는 경우도 그렇습니다. 지난주에 정한 요금 방식이 이번 주에 달라지고, 회원 등급이나 이용 규칙도 다시 정해집니다. 사업 초기에 시장 반응을 보며 정책을 자주 바꾸는 것 자체는 자연스러운 일입니다. 다만 화면 몇 개만 고치면 될 것처럼 보여도 개발 쪽에서는 그렇지 않습니다. 정책이 바뀌면 데이터 구조와 계산 로직, 이미 쌓인 데이터까지 함께 손봐야 합니다.
실무자들은 그때마다 이런 이야기를 합니다. 이 방향으로 확정하기 전에 기존 데이터를 어떻게 할지 먼저 정해야 한다, 이렇게 덧대면 다음에 바뀔 때 더 고치기 어려워진다. 문제는 정책이 바뀐다는 사실이 아니라, 일정이 급해 이런 정리 없이 일단 돌아가게만 만들고 넘어가는 일이 반복될 때 생깁니다. 바뀐 정책 위에 또 다른 정책이 덧대어지고, 나중에는 어떤 규칙이 지금 유효한지 코드만 봐서는 알기 어려운 상태가 됩니다.
이렇게 미뤄 둔 문제가 기술 부채로 쌓입니다. 그리고 나중에는 결정권자가 만들라는 대로 만들었는데도 서비스가 제대로 돌아가지 않는 일이 생깁니다. 지시대로 만들었으니 실무자 잘못이라고 하기도 어렵고, 원하는 걸 말했을 뿐이니 대표님 잘못이라고 하기도 애매합니다. 원인은 결정권자가 직접 정할 일과 실무자에게 맡기고 의견을 반영해야 할 일 사이의 균형이 맞지 않았다는 데 있습니다.
그래도 내부 개발팀이라면 회복할 여지가 있습니다. 하루 종일 같은 공간에 있으니 언제든 다시 이야기하고 고칠 수 있기 때문입니다.
개발 외주에서는 이 문제가 훨씬 커집니다
외주로 넘어가면 같은 문제가 큰 리스크가 됩니다.
발주사가 세부 구현까지 “이렇게 만들어 주세요, 저렇게 만들어 주세요”라고 직접 정하는 경우를 생각해 보겠습니다. 수주사 실무자의 의견이 반영될 여지가 없다고 느끼면, 결국 이렇게 정리하게 됩니다.
“원하시는 대로 만들어 드리겠습니다.”
그리고 정말 말한 그대로만 만듭니다. 계약상으로는 아무 문제가 없습니다. 만들기로 한 기능도 전부 만들었습니다. 그런데 오픈하고 나면 빠진 기능, 부족한 기능이 보이기 시작합니다. 아무도 그 기능을 계약서에 적지 않았기 때문입니다.
오류는 여기서 이야기하지 않겠습니다. 오류는 어떤 경우에도 생기면 안 되는 것이고, 수주사가 책임져야 할 부분입니다. 여기서 말하는 건 오류 없이 계약대로 다 만들었는데도 생기는 문제입니다.
좋은 것만 모았는데 왜 결과물이 이상할까?
여러 분야의 실무자가 함께 하는 프로젝트에서도 비슷한 일이 생깁니다. 기획, 디자인, SEO, 개발 담당이 각자 있는데도 세부 결정이 실무자와의 논의 없이 한 곳에서만 나오는 경우입니다.
홈페이지로 예를 들면 이렇습니다.
- A 사이트에서 좋아 보이는 기획
- B 사이트에서 좋아 보이는 기획
- C 사이트에서 좋아 보이는 디자인
- D 사이트에서 좋아 보이는 인포그래픽
하나하나는 다 좋은 것들입니다. 그런데 이걸 한 사이트에 전부 섞으면 방향을 잃은 결과물이 나옵니다. 각 사이트의 기획과 디자인은 그 사이트의 목표에 맞춰 만들어진 것이라, 떼어 와서 붙이면 서로 어울리지 않습니다.
그래서 중간에서 방향을 잡고 조율하는 과정이 꼭 필요하고, 이건 수주사가 해야 할 일이기도 합니다. 수주사가 “요청하신 건 다 만들어 드렸습니다”에서 멈추면 아무도 조율하지 않은 채 프로젝트가 끝납니다. 요청을 그대로 만드는 것만으로는 수주사도 할 일을 다 했다고 보기 어렵습니다.
분쟁은 완성된 결과물을 처음 볼 때 시작됩니다
이 상황의 마지막 장면은 대개 비슷합니다. 중간 과정에서 방향을 함께 확인할 기회가 없었다면, 완성된 결과물을 보고 나서야 원하던 방향이 아니었다는 걸 알게 됩니다. 최종 결정권자인 대표님이 결과물을 처음 보는 시점이 마지막이라면 더 그렇습니다.
“왜 이런 결과물이 나왔죠?”
이때부터 논란이 커지고 분쟁으로 번집니다.
- 발주사: 이건 우리가 원한 게 아니다. 다시 만들어 달라.
- 수주사: 계약서에 있는 건 다 만들었다.
누가 옳은지를 따지기 시작하면 풀기 어렵습니다. 계약은 정상적으로 끝났는데 한쪽만 만족하거나, 둘 다 만족하지 못하는 프로젝트가 됩니다. 그래서 이 문제는 끝나고 나서 따지기보다 시작하기 전에 막는 게 훨씬 낫습니다.
결과가 좋았던 프로젝트는 무엇이 달랐나
반대로 개발 외주를 하면서 가장 좋았던 경험도 있습니다. 공통점은 분명했습니다.
발주사가 궁극적으로 해결하고 싶은 목표가 무엇인지 처음부터 자세하게 공유해 줬습니다. 저는 개발에 들어가기 전에 많은 시간을 들여 소통하고, 협의하고, 확인하고, 피드백을 받았습니다.
그렇게 하면 두 가지가 함께 됩니다. 먼저 발주사가 말한 기능은 그대로 들어갑니다. 그리고 미리 들은 요구 사항이 충분히 모여 있으니, 개발자 입장에서 앞으로 운영에 필요한 확장 기능이나 고도화 방향까지 처음부터 대비해 둘 수 있습니다. 시키는 것만 만드는 게 아니라 이 서비스가 앞으로 어떻게 쓰일지를 알고 만들게 되는 겁니다.
이런 프로젝트는 마무리가 훨씬 수월합니다. 오픈하고 나서 빠진 기능을 두고 다툴 일이 줄어듭니다.
발주사가 정할 것, 실무자에게 맡길 것
정리하면 역할을 이렇게 나누는 게 좋습니다.
| 구분 | 발주사(결정권자) | 수주사(실무자) |
|---|---|---|
| 맡는 것 | 해결하고 싶은 목표, 큰 방향성 | 그 목표를 이루는 구체적인 방법 |
| 해야 할 일 | 목표와 배경을 자세히 공유 | 개발 전에 충분히 묻고 확인하고 제안 |
| 피해야 할 일 | 세부 구현을 근거 없이 지시 | 요청받은 것만 만들고 조율하지 않기 |
인하우스 개발팀이라면 대표와 실무자 사이의 균형이, 개발 외주라면 발주사와 수주사 사이의 협업 구조가 이 표의 역할 나눔과 같습니다.
개발을 맡기기 전에 확인할 것
케이트리솔루션이 아니더라도, 개발을 맡기실 때는 아래를 먼저 확인해 보세요.
- 실제로 일할 실무진이 누구인지 파악했는가
- 우리가 해결하고 싶은 목표를 기능 목록이 아니라 문제로 설명했는가
- 개발에 들어가기 전에 충분히 묻고 확인하는 과정이 일정에 들어 있는가
- 실무진이 다른 의견을 냈을 때 들어 볼 준비가 되어 있는가
- 최종 결정권자가 결과물이 완성되기 전에 방향을 확인하는가
실무진은 그 일을 업으로 해 온 사람들입니다. 어떻게 만들지는 어느 정도 맡겨 주시고, 왜 만드는지를 크게 공유해 주시는 게 결과적으로 원하는 결과물에 가장 가깝게 가는 길입니다. 목표를 문서로 정리하는 방법은 요구사항 정의서 글에 따로 정리해 두었습니다.
자주 묻는 질문
맡기면 개발사가 마음대로 만들지 않을까요?
맡긴다는 건 결정을 넘긴다는 뜻이 아닙니다. 목표와 방향은 발주사가 정하고, 그 목표를 이루는 방법을 실무자가 제안하게 하는 것입니다. 제안을 듣고 판단하는 건 여전히 발주사입니다. 개발사를 고를 때 제안과 질문을 많이 하는 곳인지 함께 보시면 좋습니다.
참고 사이트를 보여 주는 건 좋지 않은가요?
참고 사이트는 원하는 분위기를 전달하는 데 아주 좋습니다. 다만 “이 사이트의 이 부분을 그대로”를 여러 곳에서 모으기보다, 그 사이트의 어떤 점이 좋았는지를 말해 주시는 편이 낫습니다. 그래야 실무자가 우리 서비스의 목표에 맞게 조율할 수 있습니다.
마치며
계약서대로 다 만들었는데 아무도 만족하지 못하는 프로젝트는 양쪽 모두에게 손해입니다. 좋은 결과물은 한쪽이 지시하고 다른 쪽이 따르는 구조보다, 목표를 공유하고 각자 잘하는 영역을 맡는 구조에서 나옵니다.
해결하고 싶은 문제가 있다면 기능 목록이 정리되지 않았어도 괜찮습니다. 아래 문의 폼에 지금의 고민을 남겨 주시면 개발에 들어가기 전에 무엇을 정해야 할지부터 함께 이야기해 보겠습니다.