외주 프로젝트, 견적은 어떻게 산정할까?

"이거 만드는 데 얼마예요?"

4년간 외주 개발을 하면서 가장 많이 받은 질문이다. 그리고 솔직히, 여전히 쉽지 않은 질문이기도 하다. 수십 번의 프로젝트를 거치면서 나름의 기준이 생겼지만, 매번 새로운 프로젝트는 새로운 고민을 안겨준다.

개발 견적이 어려운 건, 같은 기능이라도 구현 방법에 따라 공수가 천차만별이기 때문이다. 예를 들어 "로그인 기능"을 만든다고 해보자.

단순히 "로그인"이라고 해도 이렇게 변수가 많다. 클라이언트 입장에서는 그냥 "로그인"인데, 개발자 입장에서는 2일 짜리 작업이 될 수도 있고 2주짜리 작업이 될 수도 있다.

그래서 견적을 내려면 먼저 요구사항을 명확하게 정리하는 과정이 필수다. 이건 4년이 지난 지금도 변하지 않는 원칙이다.

2021년 처음 시작했을 때, 나는 견적 산정에 대해 아무것도 몰랐다. 첫 프로젝트는 시간당으로 계산하면 최저임금에도 못 미치는 금액을 받았다. "경험 쌓는 거니까"라고 합리화했지만, 솔직히 그냥 몰라서 그랬다.

두 번째, 세 번째 프로젝트도 마찬가지였다. 클라이언트가 "이 정도면 얼마예요?"라고 물으면 어림짐작으로 대답했다. 당연히 프로젝트 중간에 "이건 견적에 포함된 건가요?"라는 대화가 오갔다.

그때 배운 교훈이 있다. 애매한 견적은 양쪽 모두를 불행하게 만든다.

4년간의 시행착오 끝에 정착한 방식은 이렇다.

먼저 기능 목록을 상세하게 정리한다. 클라이언트와 미팅하면서 "정확히 뭘 원하시는 건가요?"를 끈질기게 물어본다. 귀찮아 보일 수 있지만, 이 과정을 생략하면 나중에 더 큰 문제가 생긴다.

기능 목록이 정리되면, 각 기능별로 예상 작업 시간을 산정한다. 그리고 총 시간에 일당을 곱한 뒤, 반드시 30~50% 버퍼를 추가한다. 예상보다 오래 걸리는 건 개발의 본질이다. 버퍼 없이 빠듯하게 잡으면 100% 후회한다.

마지막으로 견적서에 포함되는 것과 포함되지 않는 것을 명확하게 적는다. "추가 수정은 몇 회까지", "이런 기능은 별도 비용" 같은 조건들. 이게 나중에 분쟁을 막아준다.

경험이 쌓이면서 깨달은 건, 투명한 견적이 오히려 신뢰를 만든다는 것이다. 처음에는 "이렇게 상세하게 쓰면 클라이언트가 깎으려 하지 않을까?" 걱정했다. 하지만 반대였다.

견적의 근거가 명확하면, 클라이언트도 "아, 이래서 이 금액이구나"라고 이해한다. 오히려 뭉뚱그려서 "총 얼마입니다"라고 하면 "왜요? 비싸지 않아요?"라는 질문이 돌아온다.

물론 상세 견적을 보고 "이 기능은 빼주세요"라고 하는 경우도 있다. 하지만 그건 좋은 신호다. 클라이언트가 정말 필요한 게 뭔지 명확해지는 과정이니까.

견적 관련 질문을 너무 많이 받다 보니, 아예 도구를 만들어봤다. 주요 기능을 선택하면 대략적인 개발 비용과 기간을 알려주는 산정기다.

물론 이건 어디까지나 참고용이다. 실제 견적은 프로젝트의 구체적인 요구사항에 따라 달라진다. 하지만 "대충 이 정도 규모면 얼마나 들까?"라는 감을 잡는 데는 도움이 된다.

궁금하신 분들은 단테 컴퍼니 견적 산정기를 한번 사용해 보시길 바란다.

4년 동안 수십 개의 프로젝트를 하면서 나만의 기준이 생겼다. "이 정도 규모면 대충 얼마"라는 감각. 이건 글로 설명하기 어렵고, 직접 부딪히면서 배우는 수밖에 없다.

다만 한 가지 확실한 건, 너무 싸게 받으면 안 된다는 것이다. 싸게 받으면 클라이언트도 그만큼의 가치로 취급하고, 나도 동기 부여가 안 돼서 퀄리티가 떨어진다. 적정한 가격을 받아야 서로 만족할 수 있는 결과물이 나온다.

비슷한 고민을 하는 분들에게 도움이 됐으면 좋겠다.

다른 글