brunch

[개발이야기] 외주 개발 견적서,백엔드 공수 산출 기준

외주 개발 견적서, API 개수 기준으로 산출하는 게 맞을까?

by 개발개발빔

5년 차 개발자로 일하다 보면, 주변에서 종종 듣는 질문이 있어요. 바로 아래와 같은데요.

"외주 개발 견적서는 도대체 어떻게 계산해요?"


그럴 때 가장 많이 등장하는 두 가지 기준이 바로

‘API 개수 기준’과 ‘DB 설계 기준’입니다.


이 두 방식은 각각의 장단점이 있고, 상황에 따라 적절하게 적용해야 합니다.

이번 글에서는 실제 개발 현장에서 어떤 기준이 왜 선택되는지, 그리고 각각이 어떤 장단점을 가지는지 정리해보려고 해요.


milles-studio-G8sb4t7-npw-unsplash.jpg

API 개수 기준 견적산출 장점: 정량적이라 설명하기 쉽다.

많은 외주 개발사에서 초기에 견적을 산출할 때 API 개수 기준을 사용해요.

왜냐하면 API는 기능 단위로 나눌 수 있어서, 개발 범위를 정량화하기 쉽기 때문이죠.

예를 들어 이런 식이에요.

로그인 API

회원가입 API

상품 리스트 조회 API

장바구니 담기 API


이렇게 쪼개보면 클라이언트 입장에서도 어떤 기능이 필요하고, 그 기능 하나하나가 비용으로 어떻게 연결되는지 감을 잡을 수 있어요. 그래서 개발이 익숙하지 않은 스타트업 대표나 마케터도 API 단위 견적은 쉽게 이해하죠.


API 기준 견적 산출 장점

클라이언트와 소통이 쉽다

기능 단위로 분리돼 있어 빠르게 견적서를 만들 수 있다

기능 추가/삭제 시 견적 변경이 유연하다


API 기준 견적 산출 단점

API 개수가 같아도 난이도나 로직 복잡도는 천차만별이다

데이터 모델링이 복잡한 프로젝트에서는 기능 단위만으로는 부족하다


curated-lifestyle-rSyw7Qv0nFg-unsplash.jpg

DB 설계 기준 견적 산출 : 구조적인 이해가 필요한 방식

반면에 DB 설계 기준은 기능보다는 시스템의 ‘데이터 구조’를 기준으로 견적을 계산해요.

즉, 어떤 테이블이 있고, 테이블 간의 관계가 어떻게 구성되어 있는지를 보고 난이도와 작업량을 예측하죠.

예를 들어, 단순 게시판 시스템이라도

사용자 테이블

게시글 테이블

댓글 테이블

첨부파일 테이블 이런 관계가 얽혀 있고, 여기에 복잡한 쿼리나 검색 기능이 들어가면 API 개수는 적더라도 작업 난이도는 높아지죠.


DB 설계 기준 견적 산출 장점

시스템의 확장성, 유지보수 난이도까지 고려한 견적이 가능하다

로직 복잡도를 반영할 수 있어 개발사 입장에서는 리스크 관리가 된다

초기에 구조가 잘 잡히면 변경 요소가 줄어든다


DB 설계 기준 견적 산출 단점

클라이언트가 이해하기 어려울 수 있다

기획이 명확하지 않으면 설계 자체가 불안정해진다

설계에 시간이 오래 걸릴 수 있다


실제 현장에서는 어떻게 결정할까?

ahmet-kurt-ehbR49Wo_NY-unsplash.jpg

실무에서는 사실 이 두 가지를 혼합해서 사용해요.

클라이언트와의 커뮤니케이션 초기에는 API 개수 기준으로 빠르게 범위를 정의하고,

내부적으로는 DB 구조를 기반으로 난이도를 판단해 리소스를 배분하죠.

예를 들어, 아래와 같은 방식으로 견적서를 작성합니다. (아래는 예시입니다)

전체 API 수: 25개 (기본 1개당 20만원)

관리자 페이지: 5개 기능 (기본 1개당 30만원)

복잡한 테이블 관계 (이력 관리, 트랜잭션 처리 포함): 추가 300만원

테스트/QA 리소스: 별도 100만원


이런 식으로 기능 중심 + 구조 중심 + 리스크 관리가 동시에 이뤄지는 방식이에요.

고도화된 프로젝트일수록 단순한 API 개수로는 견적을 낼 수 없거든요.


결국 중요한 건 "기준"보다 "이해"다

nordwood-themes-ubIWo074QlU-unsplash.jpg

정확한 견적을 위해 중요한 건 특정 기준을 고집하는 게 아니라,

클라이언트의 비즈니스 목표와 시스템 구조에 대한 이해예요.

"우리 서비스는 빠른 MVP가 중요하다"
→ API 개수 기준이 적합할 수 있어요.
"장기적으로 내부 ERP와 연결해야 한다"
→ DB 설계를 중심으로 견적을 짜는 게 낫습니다.

견적서를 잘 쓰는 건 단순히 숫자를 나열하는 게 아니라,

상황에 맞는 기준을 제안하고, 그 기준을 설명할 수 있는 것이에요.


외주 개발, 똑똑한개발자와 함께하세요.

똑똑한개발자 홈페이지.png

지금까지 API 개수 기준과 DB 설계 기준을 중심으로 외주 개발 견적 산출 방식에 대해 이야기해봤어요.

현장에서는 이 둘을 적절히 섞는 하이브리드 방식이 점점 보편화되고 있고,

무엇보다 중요한 건 클라이언트와 개발자 간의 신뢰와 커뮤니케이션입니다.


만약 여러분이 지금 외주 개발을 고민하고 있다면,

이해력 있는 파트너와 함께하는 게 가장 중요한 포인트예요.

그런 의미에서, 실무 감각과 소통 경험이 풍부한 개발사가 필요하다면 똑똑한개발자를 추천드려요.


똑똑한개발자 홈페이지 :


keyword
작가의 이전글트래픽 급증,대비 안 하면 이렇게 됩니다 (실제 사례)