서핑베어
홈 › 블로그 › 자체개발 · 구매 · 외주
자체개발, 구매, 외주 — 무엇을 기준으로 고르는가
이 판단을 비용으로 시작하면 대개 틀립니다. 세 방식의 비용 구조가 서로 다른 시점에 발생하기 때문입니다. 먼저 볼 것은 차별성, 변경 빈도, 그리고 사내 역량입니다.
3가지 기준 판단표 흔한 오판
결론부터
기준은 세 개입니다 — 이 기능이 우리 경쟁력의 일부인가, 얼마나 자주 바뀌는가, 그리고 우리가 운영할 수 있는가. 이 세 답이 방식을 거의 정합니다.
비용은 판단 기준이 아니라 판단 후 검증 도구입니다. 방식을 정한 뒤에 12개월 총비용을 계산해 예산과 맞는지 보는 순서가 맞습니다.
세 가지 기준
판단표
| 상황 | 권장 | 이유 |
|---|---|---|
| 표준 업무 + 변경 적음 | 구매 | 가장 저렴하고 빠릅니다. 대부분의 경우가 여기입니다 |
| 표준 업무 + 변경 잦음 | 구매 + 설정/자동화 | 도구를 사고 워크플로로 붙입니다 |
| 차별 업무 + 변경 적음 | 외주 개발 | 한 번 잘 만들면 오래 씁니다 |
| 차별 업무 + 변경 잦음 | 자체개발 (또는 상주 외주) | 변경 속도가 곧 경쟁력입니다 |
| 차별 업무 + 사내 역량 없음 | 외주 + 인수 계획 | 소스·문서·계정 이관 조건을 계약에 넣으세요 |
| 판단이 안 서는 경우 | 구매로 6개월 시험 | 요구사항이 드러난 뒤에 다시 판단합니다 |
흔한 오판 네 가지
결정 후에 하는 검증
방식을 정했으면 12개월 총비용을 계산합니다. 구매는 구독료 + 사용량 + 검수 시간, 외주는 개발비 + 유지보수 + 인프라, 자체개발은 인력 시간 + 인프라 + 기회비용입니다.
그다음 되돌리기 비용을 봅니다. 6개월 뒤 이 결정이 틀렸다면 무엇을 버리게 되는지. 구매는 대개 적고, 자체개발은 큽니다. 불확실성이 높을 때 구매로 시작하는 이유가 이것입니다.
마지막으로 중단 조건을 미리 적습니다. "3개월 뒤 이 지표가 이 수준이 아니면 방식을 다시 검토한다." 이 문장이 없으면 잘못된 방식을 계속 밀게 됩니다.
자주 묻는 질문
기성 도구에 원하는 기능이 하나 없습니다.
그 하나가 경쟁력인지 편의인지 구분하세요. 편의라면 업무 절차를 도구에 맞추는 편이 싸고, 경쟁력이라면 그 기능만 별도로 붙이는 구성을 검토합니다. 하나 때문에 전체를 자체개발하는 것이 가장 비싼 선택입니다.
외주와 자체개발을 섞을 수 있습니까?
흔한 구성입니다. 초기 구축을 외주로 하고 운영·개선을 사내로 가져오는 방식입니다. 성공 조건은 인수입니다 — 문서, 코드 리뷰 참여, 계정 소유권을 계약 단계에서 정하세요.
사내 개발 인력이 있는데도 외주가 낫습니까?
인력이 있다는 것과 여유가 있다는 것은 다릅니다. 현재 업무를 미루고 이 일을 하는 것이 그 인력의 최선인지 따져보세요. 기회비용이 외주비보다 큰 경우가 자주 있습니다.
AI 기능은 대체로 어느 쪽입니까?
기능 자체는 대개 구매입니다. 모델과 도구가 빠르게 좋아지므로 직접 만든 것이 금방 뒤처집니다. 다만 우리 데이터와 업무 절차에 붙는 부분은 남으므로, "모델은 사고 연결은 만든다"가 현실적인 구성입니다.
비용 비교
세 방식의 총비용을 비교하세요
외주 비용 계산기로 기능 범위별 외주 비용 범위를 추정하고, ROI 계산기로 구매 방식의 12개월 총비용과 비교할 수 있습니다.