비개발자가 알아야 할 개발 용어 10가지: 외주 발주 전 [2026]

비개발자가 알아야 할 개발 용어는 단어 뜻을 외우기 위한 사전이 아니라 견적·일정·품질·소유권을 검증 가능한 문장으로 바꾸는 도구입니다. MVP·API·프런트엔드·백엔드·데이터베이스·인프라·배포·QA·SLA·맨먼스를 들었을 때 정의만 묻지 말고 이번 계약의 범위·입력·출력·완료 증거·예외·책임자를 되물어야 외주 견적을 비교할 수 있습니다.

같은 MVP도 한 업체는 클릭 가능한 시제품, 다른 업체는 결제·운영·복구까지 가능한 서비스로 견적할 수 있습니다. 같은 API 연동도 화면 연결만 포함할지 인증·재시도·중복 방지·장애 대사까지 포함할지에 따라 범위가 달라집니다. 용어는 수치보다 완료 정의와 붙여 써야 합니다.

맨먼스와 일정은 결과를 보장하지 않습니다. 사람이 늘면 의사소통과 통합 비용도 생기며 외부 심사·데이터 정리·승인이 임계 경로가 될 수 있습니다. 발주자는 기술 구현 방식 대신 사용자가 끝낼 과업, 시스템 상태, 품질 임계값, 회사가 인수할 자산을 계약해야 합니다.

HTTP 의미·버전 규칙·API 계약 표준을 용어의 기준선으로 활용한다#

IETF RFC 9110은 HTTP 요청·응답·메서드·상태 코드의 공통 의미를 정의합니다. Semantic Versioning 2.0.0은 공개 API의 호환 변경을 버전으로 표현하는 규칙을 제안합니다. OpenAPI Specification은 HTTP API의 인터페이스를 기계 판독 가능한 형태로 기술하는 표준입니다. 이 자료들은 특정 프로젝트의 범위·일정·품질을 정하지 않으며 팀이 같은 용어를 다른 의미로 쓸 수 있으므로 계약서에는 프로젝트별 정의와 예시·인수 기준을 별도로 적어야 합니다.

• IETF RFC 9110 HTTP Semantics: HTTP 요청·응답·메서드·상태 코드의 표준 의미
• Semantic Versioning 2.0.0: 공개 API 호환성 변화를 버전으로 표현하는 규칙
• OpenAPI Specification: HTTP API 인터페이스의 기계 판독 가능 기술 표준

용어집·결정 기록·완료 정의·변경 영향표를 하나의 발주 기준선으로 관리한다#

RFP 첫 장에 프로젝트 용어집을 두고 사용자·관리자·주문·결제·완료·오류·MVP·운영 환경처럼 혼동 가능한 말을 정의합니다. 각 용어에는 포함·제외·예시·반례·책임자·근거 문서를 붙입니다. 새 용어는 회의에서만 합의하지 않고 버전 있는 기준선에 반영합니다.

기능 요구는 화면 이름 대신 행위자·사전 조건·입력·정상 결과·실패 결과·권한·로그·복구로 씁니다. API는 스키마·인증·타임아웃·재시도·멱등성·속도 제한·버전 종료를, QA는 기기·브라우저·데이터·성능·보안·접근성 범위와 차단 결함 등급을 적습니다.

견적 비교 때 총액 옆에 가정·제외·외부비용·고객 제공물·인수 자산을 나란히 둡니다. 변경 요청은 원래 기준선과 일정·비용·보안·데이터·운영 영향을 기록하고 승인 전 구현하지 않습니다. 주간 보고는 진척률보다 통과한 시나리오·열린 결정·차단 의존성·복구 시험을 봅니다.

비교 가능한 요구 정의는 개발 외주 RFP 작성법에서 이어서 확인하세요. 기능·계정·운영 인수 기준은 외주 개발 검수 체크리스트를 함께 보세요. 견적서 항목을 읽는 실무 기준은 외주 개발 견적서 읽는 법도 참고할 수 있습니다.

비개발자가 같은 용어로 범위·실패·인수 여부를 판단할 수 있으면 승인한다#

발주 담당자가 MVP·API·배포·QA·SLA·맨먼스를 보고 실제 사용자 과업·포함 환경·실패 처리·완료 증거·제외 범위를 설명할 수 있는지 확인합니다. 서로 다른 업체의 견적을 같은 시나리오와 산출물 표로 다시 써도 공백이 드러나야 합니다.

대체 담당자가 요구·API 계약·테스트 결과·배포·계정·백업을 찾아 정상 릴리스와 롤백을 수행하고 장애 등급에 따라 연락·완화·복구·보고를 실행할 수 있어야 합니다. 용어가 모호해 판단이 갈리면 승인 전에 정의와 예시를 보완합니다.