커스텀 소프트웨어 발주: 2026 구매자를 위한 7단계 플레이북

커스텀 소프트웨어 발주: 2026 구매자를 위한 7단계 플레이북

커스텀 소프트웨어 발주는 외부 개발사에 맞춤 소프트웨어 제작을 맡기는 과정입니다. 사업 계획, 작업 기술서, RFP, 벤더 평가, 계약, 그리고 마무리를 짓는 인수 테스트까지 모두 포함됩니다. 이것은 제품이 아닙니다. 구매자가 직접 진행하는 구매 프로세스입니다.

검색해 보면 Google은 아홉 개의 도구 카탈로그와 UCLA의 900단어짜리 정책 페이지 하나를 보여줍니다. 정작 프로세스 자체는 다뤄지지 않습니다. 순위에 오르는 글은 도구 벤더가 쓰기 때문입니다. 이 가이드는 두 번째 질문에 답합니다. 아직 세상에 없는 소프트웨어는 어떻게 구매하는가?

핵심 요약:

• 커스텀 소프트웨어 발주는 구매 도구를 사는 것이 아니라, 벤더에게 맞춤 소프트웨어 제작을 맡기는 프로세스입니다.
• 전체 발주 절차는 사업 계획부터 인수 완료까지 7단계이며, 개발 착수 전까지 보통 10~16주가 걸립니다.
• 계약 조항 9개가 예산을 지켜줍니다. 그중에서도 IP 소유권, 인수 기준, 마일스톤 지급이 가장 강력합니다.

커스텀 소프트웨어 발주는 구매 소프트웨어가 아닙니다

구매 소프트웨어는 구매 업무를 자동화하는 도구입니다. 발주서, 승인, 청구, 공급사 카탈로그를 다루죠. 커스텀 소프트웨어 발주는 개발사에 맞춤 소프트웨어 제작을 맡기는 프로세스입니다. 하나는 라이선스를 사는 제품이고, 다른 하나는 계약과 인수 테스트가 따르는 프로젝트입니다. 이 가이드는 후자를 다룹니다.

혼동하는 것도 무리가 아닙니다. 도구 시장은 거대하고 충분히 다뤄져 있으니까요. Art of Procurement의 제공사 디렉터리는 19개 카테고리에 걸쳐 200개 이상의 플랫폼을 나열하고, Brex의 2026 구매 가이드는 거의 4,000단어로 그중 다섯 곳을 비교합니다. 하지만 그 어디에서도 소프트웨어를 처음부터 제작 의뢰하는 방법은 설명하지 않습니다. 이 글이 바로 그 빈틈을 채웁니다.

시작하기 전에: 정말 커스텀이 맞는 구매인가?

커스텀은 소프트웨어가 업무 운영의 핵심이고, 기존 제품으로는 임시방편 없이 워크플로를 맞출 수 없을 때 올바른 선택입니다. 라이선스 제품으로 이미 필요의 80%를 해결할 수 있다면 잘못된 구매입니다. 커스텀 소프트웨어 발주 RFP에 돈을 쓰기 전에 솔직하게 판단하세요.

여전히 어느 쪽인지 모르겠다면 자체 개발 vs 구매 판단 프레임워크가 개발이냐 구매냐를 답해줍니다. 이 가이드는 그다음 질문, 구매로 결정한 뒤 어떻게 진행할 것인가를 다룹니다.

그다음 사업 계획을 문서로 남기세요. 한 장짜리 소프트웨어 구매 근거 템플릿이면 충분합니다.

Problem:       What is broken, in one sentence
Current cost:  What it costs today (hours per week x rate, or lost revenue)
Outcome:       The measurable result the software must produce
Ceiling:       The maximum budget, and the date the money runs out

두 명뿐인 발주라도 서면 발주 정책이 도움이 됩니다. 누가 지출을 승인하고 누가 서명하는지 한 문단으로 정하세요. "대표가 통화 중에 승인했다"는 식의 혼란을 막아줍니다. 이런 혼란이 인수 단계를 망칩니다.

7단계 커스텀 소프트웨어 발주 프로세스

커스텀 소프트웨어 발주 프로세스는 7단계이며, 그중 6단계는 코드를 한 줄도 쓰기 전에 끝납니다. 전체 흐름을 한 줄씩 정리하면 다음과 같습니다.

1. 니즈와 사업 계획: 문제에 돈을 쓸 가치가 있는지 증명합니다
2. 작업 기술서(SOW): "완료"의 정의를 정확히 문서화합니다
3. 시장 조사: 이런 종류의 작업을 하는 벤더 후보를 추립니다
4. RFP / RFQ: 모든 후보에 동일한 브리프를 보냅니다
5. 벤더 평가: 감이 아닌 증거로 응답을 점수화합니다
6. 협상과 계약: 9개 조항을 서면으로 못 박습니다
7. 납품과 인수: 2단계에서 정한 기준으로 테스트합니다

이 기간 범위는 일반적인 SME 프로젝트를 저희가 해석한 것이며, 측정된 벤치마크가 아닙니다. 수의계약 갱신은 3주 만에 끝나고, 규제 산업 입찰은 6개월이 걸립니다.

1. 니즈와 사업 계획

위의 한 장짜리 문서부터 시작하세요. 저희가 맡은 프로젝트 중 이 단계를 건너뛴 경우는 개발 도중에 범위가 다시 정의됩니다. 변경에 문장 하나가 아니라 실제 돈이 드는 시점이죠. 이 문서가 RFP에 제시할 예산 상한선의 기준도 됩니다.

2. 작업 기술서(SOW)

작업 기술서는 사업 계획을 양측이 논쟁할 수 있는 사양으로 바꿉니다. 포함할 기능과 제외할 기능, 연동, 일정, 그리고 납품물을 검증할 인수 기준까지 담습니다. 웹 앱 프로젝트 범위 정의 방법은 여기서 제값을 합니다. 더 빠른 초안이 필요하다면 AI로 요구사항 범위를 잡는 법도 있습니다.

3. 시장 조사

최근에 관련 도메인 레퍼런스를 보유한 벤더 5~8곳의 숏리스트를 만드세요. 비슷한 작업을 납품한 동료에게 묻고, 홈페이지가 아니라 해당 산업의 사례 연구를 확인하세요. 추천 수수료로 순위가 매겨지는 디렉터리는 건너뛰세요.

4. RFP / RFQ

숏리스트의 모든 벤더에 동일한 브리프를 보내고 동일한 응답 형식을 요구하세요. RFP(제안 요청서)는 어떻게 구축할지를 묻고, RFQ(견적 요청서)는 정의된 범위의 비용을 묻습니다. 커스텀 소프트웨어 발주에서는 RFP가 먼저입니다.

5. 벤더 평가

모든 응답을 동일한 스코어카드로 점수화하되, 가격보다 레퍼런스와 코드 감사 권리에 가중치를 두세요. 가장 저렴한 제안은 보통 가장 적은 작업량을 견적에 넣은 제안입니다. 레퍼런스에는 직접 전화하세요.

6. 협상과 계약

당선된 제안에 아래 9개 조항을 덧붙이세요. 인수 기준과 마일스톤 지급을 먼저 협상하고, 가격은 마지막에 하세요. 가격은 움직이기 가장 쉬운 조건이고, 인수는 싸울 가치가 있는 조건입니다.

7. 납품과 인수

납품은 "코드를 보냈다"가 아닙니다. 인수란 소프트웨어가 여러분의 환경에서 SOW의 기준을 통과하고, IP 양도 서명이 끝나고, 소스가 인도된 상태를 말합니다. 그 테스트를 통과할 때까지 마지막 마일스톤 지급을 보류하세요.

실제 견적을 끌어내는 RFP

인수 기준 없는 RFP는 아무도 정의하지 않은 작업에 대한 견적 요청입니다. 아래 뼈대는 모든 구매자가 보내줬으면 하는 커스텀 소프트웨어 발주 템플릿입니다. 복사해서 빈칸을 채우면, 다섯 벤더가 하나의 범위를 견적내지 다섯 개의 추측을 내놓지 않습니다.

CUSTOM SOFTWARE RFP

1. Company context
   Who you are, team size, the system this replaces or connects to

2. Problem statement
   The broken process, what it costs you today, who feels it

3. Scope
   In:  the features and integrations the first release must ship
   Out: anything you have decided to defer

4. Technical constraints
   Stack preferences, hosting rules, compliance (GDPR, HIPAA), SSO

5. Timeline
   Hard dates, and what happens if you miss them

6. Budget range
   A ceiling, not a target. Vendors price to the number you give.

7. Acceptance criteria
   The pass/fail tests the final delivery must clear before sign-off

8. Evaluation criteria
   How you will score responses, and the weight of price vs. references

9. Response format
   Page limits, the questions to answer, and the reply deadline

무엇보다 꼭 넣을 세 가지: 예산 상한선, 인수 기준, 응답 형식. 이 셋이 막연한 피치를 비교 가능한 견적으로 바꿔줍니다.

뺄 세 가지: 구현 방식 지시("마이크로서비스를 쓰세요"), 숏리스트 이전의 NDA, 40페이지짜리 요구사항 부록. 여러분이 사는 것은 결과물이지 아키텍처가 아닙니다.

실무 팁 두 가지: 모든 벤더에 같은 문서를 보내세요. 응답 형식이 통일되어야 스코어카드가 의미를 갖습니다. 그리고 평가 가중치를 RFP 안에 명시하세요. 레퍼런스가 가격보다 비중이 크다는 걸 알면 벤더는 더 날카로운 제안서를 씁니다.

커스텀 소프트웨어 벤더는 어떻게 평가하나?

벤더 평가란 모든 제안서를 동일한, 증거에 가중치를 둔 스코어카드로 점수화해서 그 결정이 재검토에도 버티게 만드는 것입니다. 가격은 대부분의 구매자가 부여하는 것보다 적은 가중치를 받아 마땅합니다. 시장 최저가로 입찰하는 제안서는 보통 가장 적은 작업량을 견적에 넣은 곳입니다. SME 예산에 추천하는 스코어카드입니다.

가중치는 출발점일 뿐입니다. 조정하되 합계는 100으로 맞추고, 제안서를 한 부도 읽기 전에 문서로 고정하세요. 개발사 순위 평가 방법도 같은 원칙을 적용합니다. 개발 서비스에 실제로 포함되는 항목은 견적 항목을 같은 기준으로 비교하는 데 도움이 됩니다.

소프트웨어 인수 실사 체크리스트

계약 전에 상위 2개 벤더에만 이 체크리스트를 돌리세요. 다섯 곳 전부가 아니라요.

• 레퍼런스에 실제 질문으로 확인 (무엇이 깨졌는지, 어떻게 처리했는지, 다시 계약할 건지)
• 코드 감사 권리를 최종 마일스톤 지급 전에 서면으로 합의
• 재무 건전성 확인 (업력, 수익성, 고객 집중도)
• 보안 수준 검토 (SDLC, 접근 통제, 사고 이력)
• 핵심 인력 연속성 확인 (제안 발표 팀이 실제 프로젝트 팀)
• IP 양도 조항은 상대 측 변호사가 아니라 내 변호사가 검토

예산을 지키는 계약 조항 9개

예산을 지키는 조항은 가격이 아닙니다. 인수 테스트입니다. 이 주제에서 Google 상위 10개 중 유일한 기관 페이지인 UCLA의 구매 가이드도 바로 그 아이디어 위에 커스텀 소프트웨어 조언을 세웁니다. 작업 기술서, IP 소유권, 인수 테스트, 보증을 가격 논의 앞에 둡니다. 저희는 그 분류를 상용 구매자를 위한 9개 조항으로 확장했습니다.

소프트웨어 구매 계약서 템플릿을 만들고 있다면, 이 9개 행이 뼈대입니다.

하나라도 빠지면 희망에 돈을 대는 것입니다. 변호사에게 시간이 세 조항분밖에 없다면 1, 2, 3번을 맡기세요.

커스텀 소프트웨어 비용은 얼마이고, 지급은 어떻게 설계해야 하나?

범위가 가격을 정합니다. 그래서 견적이 의미를 갖기 전에 SOW가 먼저 존재하는 것입니다. 공개된 기준점은 ScienceSoft의 추정치로, 엔터프라이즈급 커스텀 구매 소프트웨어에 $200,000~$400,000, 약 10개월을 제시합니다. ScienceSoft는 해당 수치의 315% ROI를 Forrester Total Economic Impact 연구에서 인용합니다.

이 수치는 대규모 엔터프라이즈 구축에 대한 그들의 숫자이지 저희 수치가 아닙니다. 더 작은 SME 구축, 즉 내부 도구나 고객 포털, 모바일 앱은 그 밴드보다 훨씬 아래에 위치합니다. 저희의 SME 해석은 해석으로 받아들이시고, 어떤 수치든 믿기 전에 견적 세 곳을 받으세요. 앱별 기준점은 모바일 앱 비용 상세 분석에서 앱 유형별 구축 비용을 확인할 수 있습니다.

지급 구조는 총액만큼이나 중요합니다.

저희 권장안: 고정 범위에 마일스톤 연동 지급을 기본으로 하세요. 착수금은 20% 이하로, 마지막 회차는 인수 테스트 통과를 조건으로 겁니다. 고정가는 SOW가 적대적 읽기에도 버틸 때만 선택하세요. T&M은 이미 함께 납품해 본 벤더일 때만 선택하세요. 100% 선지급은 절대 안 됩니다. 그 구조는 아래에서 다시 등장합니다.

위험 신호: 커스텀 소프트웨어 발주는 실제로 어떻게 실패하나

100% 선지급은 우선순위를 사주지 않습니다. 납품 리스크 전부를 여러분 쪽으로 옮길 뿐입니다. 아래의 위험 신호는 모두, 다시는 되찾지 못할 협상력을 벤더에 넘깁니다.

• 모호한 SOW. "CRM 만들어 주세요", 기능 목록 없음. 정의되지 않은 항목은 모두 변경 지시서가 되며, 경쟁 없는 가격이 매겨집니다.
• 인수 테스트 없음. "보면 압니다." 그런데 "완료"가 정의된 적이 없으니 영원히 볼 수 없습니다.
• 100% 선지급. 계약 후 현금은 유일한 협상 카드입니다. 첫날 다 써버리면 아무것도 남지 않습니다.
• 변경 통제 없음. 범위가 불어나고, 청구서가 불어나고, 그 증가분에 서명한 사람은 없습니다.
• IP 양도 누락. 소프트웨어를 사놓고도 라이선스로 돌려받은 줄 모릅니다.
• 핵심 인력 조항 없음. 제안을 따낸 시니어 팀이 계약 일주일 뒤 사라집니다.

저희는 분기마다 개발사 입장에서 커스텀 소프트웨어 RFP에 답변하며, 두 가지 패턴이 너무 자주 반복되어 발주 실패의 기본값으로 취급합니다. 인수 기준이 아예 없는 RFP, 그리고 대다수를 선지급하는 지급 일정입니다. 후자는 현금이 들어오는 순간 벤더가 프로젝트 우선순위를 낮출 모든 인센티브를 줍니다. 저희의 해석이며, 측정이 아닌 해석입니다. 가격을 가장 세게 깎는 구매자가 정작 가격을 지켜줄 두 조항, 인수와 마일스톤을 건너뛴 경우가 많습니다.

업계 데이터도 같은 방향을 가리킵니다. The Standish Group은 CHAOS 연구를 통해 30년간 프로젝트 결과를 추적해 왔습니다. 반복되는 발견은, 예산 초과, 지연, 기능 부족 등 문제가 있는 프로젝트가 깨끗한 성공보다 많다는 것이며, 모호한 요구사항과 약한 오너십은 원인 목록 최상위권에 있습니다.

딱 하나만 고친다면 인수 기준을 고치세요. 다른 모든 조항을 집행 가능하게 만드는 조항이 바로 이것입니다.

Techsy의 커스텀 소프트웨어 발주 접근법

저희 인테이크도 테이블 반대편에서 같은 7단계를 따릅니다. 숫자를 견적내기 전에 SOW와 인수 기준부터 작성합니다. 모호한 브리프에 견적을 내는 것이 벤더가 저가 견적을 내고 구매자가 초과 지급하는 원인입니다. 개발은 마일스톤 연동 지급, 주간 데모, 모든 계약에 코드 감사 권리를 포함해 진행됩니다. 인수가 통과되면 여러분은 IP와 저장소를 소유합니다. 라이선스가 아닙니다.

솔직한 한계: 구매를 자동화하는 라이선스 SaaS 도구가 필요하다면 저희는 잘못된 선택입니다. 그것은 제품 구매이지 개발이 아닙니다. 도구 벤더가 더 빠르고 저렴하게 대응합니다. 저희는 소프트웨어가 곧 프로세스이고 IP가 중요한 커스텀 작업을 맡습니다.

프로젝트가 두 번째 범주에 해당한다면, 무료 상담받기.

자주 묻는 질문

소프트웨어 조달이란 무엇인가?

소프트웨어 조달은 소프트웨어를 획득하는 프로세스입니다. 니즈 정의, 옵션 평가, 조건 협상, 납품 인수를 포괄합니다. 라이선스 제품과 커스텀 개발 모두를 다룹니다. 이 가이드는 후자에 초점을 맞춥니다. 사업 계획부터 RFP, 계약, 인수 테스트까지 이어지는 프로세스입니다.

조달의 4가지 유형은?

일반적으로 인용되는 네 가지 유형은 직접 조달(생산 투입재), 간접 조달(운영재와 서비스), 재화 조달, 서비스 조달입니다. 소프트웨어는 간접 조달과 서비스 조달에 걸쳐 있습니다. 라이선스 도구는 간접 구매이고, 커스텀 개발은 재화 납품으로 끝나는 서비스 계약입니다.

구매 소프트웨어와 커스텀 소프트웨어 발주의 차이는?

구매 소프트웨어는 Tradogram이나 Tipalti처럼 구매 워크플로를 자동화하는 도구입니다. 커스텀 소프트웨어 발주는 개발사에 맞춤 소프트웨어 제작을 맡기는 프로세스입니다. 최고의 구매 플랫폼을 찾고 계셨다면 전자이고, 이 가이드는 후자를 다룹니다.

커스텀 소프트웨어 발주에는 얼마나 걸리나?

일반적인 SME 프로젝트 기준으로 사업 계획부터 계약 서명까지, 개발 착수 전에 10~16주를 계획하세요. 벤치마크가 아닌 해석으로 받아들이세요. 수의계약 갱신은 몇 주로 압축되고, 규제 산업 입찰은 6개월을 넘길 수 있습니다.

커스텀 소프트웨어 비용은 얼마인가?

ScienceSoft는 엔터프라이즈급 커스텀 구매 소프트웨어에 $200,000~$400,000, 약 10개월을 추정하며, 315% ROI 수치는 Forrester 연구에서 인용합니다. 더 작은 SME 구축은 그 밴드보다 훨씬 아래에 있습니다. 커스텀 소프트웨어 발주에서는 범위가 가격을 정합니다. 견적이 의미를 갖기 전에 RFP와 SOW가 먼저 존재하는 이유입니다.

커스텀 소프트웨어의 IP는 누가 소유하나?

계약이 말하는 쪽이 소유합니다. 명시적인 직무저작물 또는 IP 양도 조항이 없으면, 벤더가 저작권을 유지하고 소프트웨어를 여러분에게 라이선스합니다. 소유권을 지급과 연동해 서면으로 명시하세요. 최종 지급 시 구매자가 모든 것을 소유하는 방식입니다. 그 이전은 착수금이 아니라 인수 조건부 마지막 회차에 묶으세요. 소프트웨어가 움직일 때만 소유권도 움직이도록 말입니다.

RFP와 RFQ 중 무엇이 필요한가?

RFP(제안 요청서)는 벤더가 문제를 어떻게 풀지를 묻고, RFQ(견적 요청서)는 정의된 범위의 비용을 묻습니다. 커스텀 소프트웨어에서는 RFP를 먼저 보내세요. 벤더가 접근법을 제안해야 가격도 의미를 갖습니다. RFQ는 SOW가 동결된 뒤에 옵니다.

고정가인가, 시간과 재료(T&M)인가?

고정가는 SOW가 빈틈없을 때 여러분을 지켜줍니다. 벤더가 초과 비용을 흡수합니다. T&M은 범위가 진화하는 탐색 중심 작업에 맞지만, 초과 비용 리스크는 여러분이 집니다. 대부분의 SME 구매자는 고정 범위에 마일스톤 연동 지급, 마지막 회차는 인수 테스트 조건부로 진행할 때 가장 좋은 결과를 얻습니다.

작업 기술서에는 무엇이 들어가야 하나?

작업 기술서에는 범위에 포함할 기능과 제외할 기능, 연동, 일정, 납품물을 검증할 인수 기준, 각 산출물에 연동된 지급 마일스톤을 명시해야 합니다. SOW에 없는 항목은 프로젝트에도 없는 항목입니다.

저자 소개

Mert Batur는 Techsy.io의 공동 창업자로, 팀은 B2B 클라이언트를 위한 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 납품합니다. Techsy 팀이 실제 프로덕션에서 사용하는 LLM 도구 스택에 대해 씁니다. 이 가이드의 토대가 된 커스텀 소프트웨어 납품 프로젝트도 RFP 응답부터 인수 완료까지 직접 운영합니다. LinkedIn에서 연결하기.

결론

커스텀 소프트웨어 발주는 협상이 아니라 산출물로 귀결됩니다. 한 장짜리 사업 계획, 인수 기준을 담은 SOW, RFP 뼈대, 스코어카드, 9개 조항 계약서. 이 다섯 문서를 제대로 만들면 벤더와의 대화는 저절로 풀립니다. 7단계를 순서대로 진행하고, 최종 지급은 인수 테스트 뒤에 묶어두세요. RFP에 대한 제3의 의견이 필요하다면 무료 상담받기.