1억 원짜리 소프트웨어는 고객의 무엇을 바꿔야 할까

기업용 소프트웨어를 만들다 보면 계약 규모를 생각하게 된다. 제품을 계속 개발하고 고객 환경을 지원하려면 사업이 유지돼야 하고, 어떤 고객에게 어떤 가치를 제공해야 더 큰 계약으로 이어지는지도 늘 고민한다. 솔직히 말하면 나는 큰 계약을 만들고 싶다.

근데 공급자가 원하는 계약 금액과 고객이 지불할 이유는 별도로 설명해야 한다. 이 글은 그 두 번째 설명을 끝까지 해보는 글이다. 가상의 숫자로 투자 대비 효과를 계산하고, 그 계산이 어디서 멈추고 무엇을 더 세야 하는지 적는다.

공급자의 계약 금액과 고객의 지불 이유는 왜 따로 설명해야 하나?

두 숫자가 다른 사람의 질문에 답하기 때문이다. 우리가 얼마나 오래 개발했는지, 기능이 몇 개 있는지는 제품을 이해하는 정보가 된다. 구매 담당자에게 필요한 건 그 비용을 지불한 뒤 자신의 조직에서 무엇이 달라지는가다. 그 담당자는 조직 안에서 도입 이유를 설명해야 하는 사람이고, "기능이 많다"는 그 설명에 쓸 수 없다.

그래서 가치를 가능한 한 실제 업무의 언어로 바꿔야 한다. 매번 배포 전에 사람이 모으던 근거를 더 쉽게 확인할 수 있는가. 변경 요청과 실제 배포 내용이 일치하는지 검토할 수 있는가. 인수인계 때 이전 결정을 다시 조사하는 일을 줄일 수 있는가. 이런 변화가 어느 팀에서 얼마나 자주 필요한지까지 알아야 가치에 가까워진다.

도입 비용에는 무엇을 넣어야 하나?

구매 가격만이 아니다. 설치와 연계, 교육, 전환 기간의 업무 부담, 유지보수, 인프라와 내부 운영 시간이 들어간다. 그리고 기존 도구를 계속 쓸 경우 발생할 비용도 같은 기간과 같은 범위로 비교해야 한다. 어느 한쪽의 비용만 자세히 세면 판단이 기울어진다. 새 도구의 비용은 잘게 세고 기존 도구의 비용은 "이미 있으니 공짜"로 두는 계산이 특히 흔하다.

투자 대비 효과는 실제로 어떻게 계산되나?

가정을 명시하고 끝까지 곱해보면 된다. 아래 숫자는 CollabOps의 가격표도 아니고 고객 실측 성과도 아니다. 고객과 투자 대비 효과를 논의할 때 어떤 가정을 확인해야 하는지 보여주기 위한 예시다.

이 가정이면 연간 확보하는 업무 여력은 20회 × 2시간 × 12개월, 즉 480시간이다. 시간당 5만 원으로 평가하면 연간 2,400만 원, 3년간 7,200만 원이다. 3년 총비용 1억 8,000만 원과 나란히 놓으면 이 한 항목만으로는 절반에도 못 미친다.

여기서 멈추면 안 된다. 이 결과가 말해주는 건 제품의 가치가 아니라, 배포 한 번의 작업 시간이라는 항목 하나가 원래 전체 그림의 일부라는 사실이다. 같은 자리에서 함께 세야 할 항목이 있다.

• 중복 도구의 정리. 이슈 트래커, 저장소, CI 서버, 승인 워크플로우를 따로 운영하면 라이선스와 서버와 관리하는 사람이 각각 든다. 이 비용은 기존 환경 쪽 열에 들어가야 한다.
• 감사와 인수인계에 드는 시간. "이 배포에 어떤 변경이 들어갔고 누가 승인했는가"를 여러 화면을 열어 복원하는 시간은 배포 1회당 2시간과는 별개의 항목이다. 감사 대응이 있는 조직일수록 크다.
• 장애 시 변경 맥락을 복원하는 시간. 문제가 생겼을 때 어떤 변경이 언제 나갔는지 찾는 시간은 장애의 길이를 직접 늘린다.
• 연결부에 드는 시간. 이슈와 저장소와 파이프라인과 배포 도구 사이를 사람이 손으로 잇는 시간이다. 개별 도구 조합에서는 이 연결부마다 누군가가 상태를 옮겨 적고 확인한다. 저장소, 변경 요청, 파이프라인, 배포 기록이 처음부터 한 평면에 있으면 이 항목 자체가 사라진다. 우리가 통합 플랫폼을 만드는 이유가 정확히 이 열에 있다.

반대 방향의 질문도 같은 자리에서 해야 한다. 이 고객에게 제안한 제품과 도입 범위가 맞는가. 적용되는 팀이 하나뿐이라면 범위를 줄이는 게 맞을 수 있다. 가격을 정당화하기 위해 근거가 약한 효과를 더하는 것은 계산을 정교해 보이게 할 뿐 도움이 되지 않는다.

시간 절감을 금액으로 환산할 때 무엇을 조심해야 하나?

확보한 업무 여력의 평가액과 실제 인건비 절감을 구분해야 한다. 위 계산의 7,200만 원은 확보한 시간의 평가액이지, 인건비 지출이 그만큼 줄었다는 뜻이 아니다. 확보한 시간으로 미뤄둔 일을 처리하거나 품질을 개선했다면 그 결과를 따로 확인해야 한다.

한 가지 더. 승인 대기처럼 흐르기만 한 시간과 사람이 실제로 일한 시간을 섞어서 계산하면 안 된다. 대기 시간이 줄어드는 것도 가치지만, 그건 리드타임의 항목이지 작업 시간의 항목이 아니다. 둘을 한 숫자로 합치면 나중에 고객이 실측했을 때 맞지 않는다.

장애와 보안 사고의 위험을 줄이는 가치는 어떻게 넣나?

발생 확률과 감소 효과에 근거가 있을 때만 넣는다. 한 번의 사고가 클 수 있다는 사실만으로 제품의 효과를 정할 수는 없다. 어떤 실패 경로를 줄이는지, 현재 그 실패가 얼마나 발생하는지, 제품이 실제로 개입할 수 있는 범위가 어디까지인지가 있어야 한다. 확률과 감소 효과를 모르는 상태에서 큰 피해 금액을 곱하면 계산이 정교해 보일 뿐이다.

그래서 이 항목은 PoC에서 측정할 대상으로 남겨두는 게 낫다. 승인 뒤 코드가 바뀌는 경우가 얼마나 있었는지, 배포된 결과물과 검증한 결과물이 달랐던 경우가 있었는지 같은 것들이다. 금융권 배포 통제와 4-eyes에서 다룬 통제 항목들이 여기에 들어간다.

PoC에서는 무엇을 측정해야 하나?

현재의 업무부터 기록한다. 같은 유형의 작업에 누가 얼마나 관여하는지, 어디서 재작업이 생기는지, 어떤 자료를 찾는 데 시간이 드는지. 그다음 적용한 업무의 범위와 조건을 맞춰 비교한다. 이미 다른 개선 활동으로 줄어든 시간을 우리 제품의 효과로 다시 계산하지 않는 것도 중요하다.

고객과 합의할 질문은 간단하다. 무엇이 얼마나 달라지면 도입을 검토할 가치가 있는가. 그 차이를 어떤 기록으로 확인할 것인가. 개선이 나오지 않으면 범위와 접근을 어떻게 바꿀 것인가. PoC가 이 질문에 답하면 구매 논의에 쓸 수 있는 근거가 남는다. BD 없이 엔터프라이즈 영업에서 PoC를 첫 관문으로 두는 이유를 적었는데, 이 계산이 그 관문의 내용이다.

1억 원짜리 소프트웨어가 바꿔야 할 것은 결국 무엇인가?

담당자가 조직 안에서 도입 이유를 설명할 수 있는 상태다. 그 설명에는 우리가 제공하는 기능이 아니라 실제로 바뀐 업무와 확인 가능한 기록이 들어가야 한다. 배포 전 근거를 모으는 시간, 감사와 인수인계에 드는 시간, 장애 때 맥락을 복원하는 시간, 그리고 도구 사이를 사람이 잇던 연결부. 이 항목들이 표에 함께 올라가야 1억 원이라는 숫자와 고객의 업무가 같은 계산 안에 놓인다.

1억 원짜리 소프트웨어가 해결해야 할 문제는 고객마다 다르다. 그래서 가격을 이야기할수록 고객의 업무를 더 구체적으로 이해해야 한다. 내가 원하는 계약 규모를 고객이 확인할 수 있는 변화로 번역하는 일은 영업이 아니라 제품을 만드는 일의 일부다.