맞춤형 소프트웨어 개발 비용을 실제로 결정하는 것들

“맞춤형 소프트웨어 개발 비용”을 검색하는 분들은 대개 견적표에 나오는 숫자를 기대합니다. 이해합니다 — 숫자가 있어야 예산을 세우고 비교할 수 있으니까요. 하지만 저희는 랜딩 페이지에 숫자를 걸지 않습니다. 그렇게 하는 스튜디오는 여러분의 프로젝트가 아니라 임의의 자리표시자를 견적내는 것입니다.

이건 회피가 아니라 정직한 답입니다. 맞춤형 소프트웨어의 가격은 소프트웨어 자체의 속성이 아니라, 그 소프트웨어를 만드는 과정에서 내려지는 결정들의 결과이기 때문입니다. 실제로 숫자를 움직이는 요인은 다음과 같습니다.

범위가 가장 먼저 움직이는 변수이고, 여러분이 직접 통제할 수 있는 변수입니다

“고객 포털”이라는 말은 로그인 페이지와 신청서 한 장을 의미할 수도 있고, 역할별 권한, 감사 로그, 데이터 내보내기, 아직 정하지도 않은 세 개 시스템과의 연동을 의미할 수도 있습니다. 둘 다 실재하는 프로젝트이고, 둘 다 첫 메일에서는 똑같이 “포털”이라고 불립니다.

그래서 숫자보다 디스커버리 워크숍이 먼저입니다. 영업 절차가 아니라, 범위가 단어에서 벗어나 실제 문서 — 화면, 권한, 데이터 흐름, 포함되는 것과 명시적으로 제외되는 것 — 로 바뀌는 지점입니다. 이 단계를 건너뛰면 나오는 숫자는 소수점을 단 추측일 뿐입니다.

팀 규모와 반복 횟수, 시간이 아니라

“시간당 비용”이라는 표현은 작업량이 고정되어 있고 그것을 단가로 나눈다는 전제를 깔고 있습니다. 실제로는 그렇지 않습니다. 같은 기능을 시니어 한 명이 열 주에 걸쳐 만드는 경우와, 다섯 명이 세 주 만에 만드는 경우는 총 비용이 비슷하게 나올 수 있지만 그 과정은 완전히 다릅니다 — 그리고 소규모 팀 쪽이 더 일관된 결과물을 내는 경우가 많은데, 인원이 적을수록 인계 지점이 줄고 사양이 흐트러질 여지도 줄기 때문입니다.

저희는 의도적으로 팀을 작게 유지합니다. 통화에 참여하는 사람이 곧 코드를 작성하는 사람인 경우가 대부분입니다. 이건 조직 철학이 아니라, 그렇지 않으면 청구서에는 “프로젝트 관리”로 잡히지만 여러분의 소프트웨어에는 기능으로 나타나지 않는 한 겹을 없애는 방법입니다.

인원수보다 반복 주기가 더 중요합니다. 2주마다 실제로 동작하는 화면을 보는 것은 슬라이드 자료를 보는 것과 다릅니다. 2주 차에 잘못된 가정을 잡아내는 것과 10주 차에 잡아내는 것의 차이는, 어떤 가격표에도 적히지 않는 가장 큰 비용 변수입니다.

숫자 안에 실제로 들어 있는 것

요인	무엇을 바꾸는가
사용자 역할과 권한 단계 수	데이터 모델 복잡도, 테스트 범위
기존 시스템과의 연동	사전 조사 시간, 오류 처리, 모니터링
리포팅과 데이터 내보내기 요구사항	쿼리 복잡도, 화면 설계 범위
데이터 저장 위치 / EU 개인정보 규정 제약	호스팅 선택, 로그 기록 방식과 위치
기존 운영 시스템을 대체하는지 여부	마이그레이션 계획, 병행 운영 기간

이 중 특별히 이국적인 항목은 없습니다. 숫자가 의미를 갖기 전에 진지한 제안서라면 당연히 답해야 하는 평범한 질문들일 뿐입니다.

단계별 고정가, 또는 리테이너

범위가 문서로 정리되고 나면 정직하게 가격을 매기는 방식은 두 가지입니다. 단계별 고정가는 유료 디스커버리 이후 제시되며, “이 스프레드시트를 대체한다”, “이 예약 도구를 출시한다”처럼 명확한 종착점이 있는 프로젝트에 적합합니다. 월 단위 역량 리테이너는 출시 후에도 계속 진화하는 제품에 맞습니다. 질문이 “언제 끝나는가”가 아니라 “이번 분기에 팀의 시간이 얼마나 필요한가”이기 때문입니다.

어느 쪽이 절대적으로 더 저렴한 것은 아닙니다. 서로 다른 질문에 대한 답일 뿐입니다. 하나는 도착지의 가격이고, 다른 하나는 지속적인 역량의 가격입니다. 잘못된 방식을 고르면 — 작업 자체가 잘못 산정돼서가 아니라 가격 모델이 문제의 형태와 맞지 않아서 — 맞춤형 소프트웨어 프로젝트가 끝없는 청구서로 변합니다.

프로젝트 중간에 요구사항이 바뀌면

범위를 문서로 고정했다고 해서 바뀌지 않는다는 뜻은 아닙니다. 실제로는 거의 항상 바뀝니다 — 화면을 실제로 써보고 나서야 빠진 단계나 잘못된 가정이 보이기 때문입니다. 문제는 변경 자체가 아니라 변경을 처리하는 방식입니다. 고정가 단계 안에서 범위가 늘어나면 일정과 비용도 그만큼 같이 늘어나야 하는데, 이걸 미리 합의하지 않는 계약은 나중에 “이것도 당연히 포함된 거 아니냐”는 분쟁으로 번집니다.

제대로 된 제안서는 변경 요청을 처리하는 절차를 미리 정해둡니다. 요청이 들어오면 먼저 영향을 받는 일정과 비용을 숫자로 제시하고, 승인 후에만 작업을 시작하는 식입니다. 이렇게 하면 변경이 막히는 게 아니라 투명해질 뿐입니다 — 그리고 이미 합의한 범위 안에 “어차피 비슷한 거니까” 하며 욱여넣으려는 압박도 줄어듭니다. 상대에게 물어볼 만한 질문은 “범위가 바뀌면 어떤 절차를 거치는가”입니다. 답이 “그때그때 맞춰드립니다”뿐이라면, 그 유연함의 비용은 결국 다른 항목에서 청구됩니다.

연동이 단일 기능보다 숫자를 더 크게 움직입니다

다른 시스템이 굳이 대화할 필요 없는 독립형 도구는 만들기 가장 저렴한 종류의 맞춤형 소프트웨어입니다. 경계를 전적으로 통제할 수 있기 때문입니다. 하지만 ERP를 읽거나 CRM에 다시 기록하거나 결제 시스템과 데이터를 맞춰야 하는 순간, 비용은 화면이 아니라 상대 시스템의 API — 또는 API의 부재 — 로 옮겨갑니다.

문서화가 잘 된 ERP·CRM과의 미들웨어도 만들어봤고, 예약된 파일 내보내기가 유일한 안정적 인터페이스인 시스템과도 작업해봤습니다. 둘 다 해결 가능하지만 비용이 같지 않고, 실제로 상대 시스템이 무엇을 제공하는지 확인하기 전까지는 알 수 없습니다. 판단이 개입하지 않는 단순 반복 작업이라면 AI 자동화를 어디서 시작할지 먼저 검토하는 쪽이 더 저렴할 때도 있습니다.

소유권도 비용을 결정하는 요소입니다

소스 코드, 저장소 접근 권한, 문서화를 언급하지 않는 견적은 완전한 견적이 아닙니다 — 출시 이후 무슨 일이 벌어지는지를 결정하는 부분이 빠진 것입니다. 소유하지 않는 소프트웨어는 단계만 하나 더 붙은 구독 서비스입니다. 이후의 모든 변경은 코드를 쥐고 있는 쪽이 정한 요율로, 그 경로를 통해서만 이루어집니다.

저희는 프로젝트 끝이 아니라 매 마일스톤마다 전체 소스와 저장소, 문서를 전달합니다. 이건 친절이 아니라 “맞춤형”이라는 말이 원래 의미해야 하는 바입니다. 소프트웨어를 들고 떠날 수 없다면, 맞춤형 소프트웨어를 산 게 아니라 남의 소프트웨어에 대한 접근권을 산 것입니다.

정직한 질문의 버전

검색창에 입력되는 질문은 “맞춤형 소프트웨어가 얼마인가”입니다. 답할 수 있는 질문은 “이 특정 소프트웨어가, 이 특정 사용자를 위해, 기성 도구가 할 수 없는 무엇을 하는가”입니다. 역할, 연동, 리포팅, 호스팅 제약 등 나머지는 모두 그 답에서 자연스럽게 도출되고, 가격도 마찬가지입니다.

문제의 형태를 이미 알고 계시다면 디스커버리 대화 한 번이 검색보다 훨씬 빠르게 실제 숫자를 드립니다. 아직 모르신다면 그것도 괜찮습니다 — 그게 디스커버리의 존재 이유입니다. 저희가 만든 소프트웨어의 사례는 work 페이지에서, 맞춤형 소프트웨어에 대한 접근 방식은 서비스 페이지에서 더 볼 수 있습니다.

범위가 정해지기 전에 받은 가격은 견적이 아니라, 그것을 실제로 만들어 줄 대화를 기다리는 자리표시자일 뿐입니다.

그 대화는 문의 페이지에서 시작할 수 있고, 비용은 들지 않습니다.