외주 개발 전 알아야 할 개발 지식과 프로젝트 체크리스트

외주 개발을 준비할 때 발주사가 직접 코드를 짤 필요는 없습니다. 다만 해결할 문제, 우선순위, 완료 기준, 데이터와 운영 위험은 내부에서 결정해야 합니다. 외부 개발사에는 설계·개발·검증처럼 부족한 전문성을 맡기되, 중요한 결정과 지식이 회사 안에 남도록 계약과 협업 방식을 짜야 합니다.

외주 개발에서 회사가 직접 쥐어야 할 것

외주는 핵심 역량인지 아닌지로 단순하게 나눌 일이 아닙니다. 서비스의 경쟁력이 어디에서 나오고, 출시 뒤 얼마나 자주 바뀌며, 장애와 데이터에 누가 책임질지를 기준으로 판단해야 합니다.

제품이 자주 바뀌거나 기술이 곧 경쟁력이라면 내부 제품·기술 책임자의 비중을 높이는 편이 좋습니다. 반대로 필요한 역량과 기간이 분명한 프로젝트라면 외부 전문가가 속도와 경험을 보완할 수 있습니다. 어느 쪽이든 문제 정의와 수용 기준까지 통째로 넘기면 결과를 평가할 기준이 사라집니다.

외주사와 첫 미팅을 준비한다면 다빈치의 외주 개발 업체 미팅 체크리스트도 참고해 보세요.

1. 프론트엔드, 백엔드, DB

• 프론트엔드: 사용자가 보고 조작하는 화면과 그 동작

• 백엔드: 요청을 검증하고 업무 규칙을 처리해 결과를 돌려주는 서버 쪽 구성

• DB: 서비스에 필요한 데이터를 구조에 맞게 저장하고 조회하는 시스템

회원 가입을 예로 들어보겠습니다. 사용자가 프론트엔드 화면에 이메일과 비밀번호를 입력하면 브라우저나 앱은 백엔드에 가입 요청을 보냅니다. 백엔드는 입력값을 검증하고 DB에서 이메일 중복 여부를 확인한 뒤 조건을 충족하면 계정 정보를 저장합니다. 비밀번호는 그대로 보관하지 않고 적절한 방식으로 해시 처리하는 등 별도의 보안 설계가 필요합니다. 프론트엔드와 서버의 역할은 Mozilla MDN의 서버 측 개발 안내에서도 확인할 수 있습니다.

<이미지 출처: Zellwk>

이 세 영역이 언제나 한 서버에 묶이는 것은 아닙니다. 규모와 요구사항에 따라 여러 서비스와 저장소로 나뉠 수 있으므로 견적서에서는 ‘백엔드 개발’이라는 한 줄보다 어떤 기능과 데이터 흐름을 포함하는지 확인해야 합니다.

2. API와 SQL

• API: 서로 다른 소프트웨어 구성 요소가 요청과 응답을 주고받는 규칙과 접점

• SQL: 관계형 DB의 데이터를 조회하고 추가·수정·삭제하는 데 쓰는 언어

프론트엔드와 백엔드는 보통 API로 통신합니다. 다음 예시에서 프론트엔드는 /api/check-email 엔드포인트로 이메일을 보내고 서버가 돌려준 exists 값에 따라 안내 문구를 선택합니다.

// 프론트엔드 예시 코드
fetch('/api/check-email', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ email: 'test@example.com' })
})
.then(response => response.json())
.then(data => {
  if (data.exists) {
    console.log('이메일이 이미 존재합니다.');
  } else {
    console.log('사용 가능한 이메일입니다.');
  }
});

DB 조회는 프론트엔드 코드가 아니라 서버가 담당합니다. 서버는 요청값을 검증한 뒤 데이터 접근 계층이나 SQL을 이용해 중복 여부를 확인하고 결과만 돌려줍니다. API 명세에는 주소와 통신 방식뿐 아니라 입력값, 응답 형식, 오류 코드, 인증 방식도 함께 적어야 합니다.

API 방식과 용어가 더 궁금하다면 API 개념부터 종류, API 활용 서비스 예시에서 이어서 확인할 수 있습니다.

3. 앱, 웹, 웹앱

‘웹앱’은 넓게는 브라우저에서 동작하는 응용 서비스를 뜻합니다. 모든 웹앱이 기기에 설치되지는 않습니다. 설치와 오프라인 기능까지 중요하다면 PWA 요건과 목표 브라우저의 지원 범위를 따로 확인해야 합니다.

무엇을 만들지는 유행하는 기술보다 사용자 환경과 필요한 기기 기능을 기준으로 정해야 합니다. 앱이 적합하다면 모바일 앱 개발 기간과 외주 비용에서 견적에 영향을 주는 요소도 살펴보세요.

4. 자바, 자바스크립트, 리액트, 리액트 네이티브

자바와 자바스크립트는 이름이 비슷하지만 별개의 언어입니다. 자바는 JVM을 통해 여러 운영체제에서 실행할 수 있으며 백엔드와 기업용 시스템을 비롯한 여러 분야에 쓰입니다. 다만 특정 언어만으로 안정성과 확장성이 보장되지는 않습니다. 시스템 구조, 테스트, 운영 방식이 함께 뒷받침돼야 합니다.

자바스크립트는 웹 페이지의 상호작용에 널리 쓰이며 Node.js 같은 실행 환경에서는 서버에서도 사용할 수 있습니다. 타입스크립트는 자바스크립트에 정적 타입 검사 기능을 더해 큰 코드베이스를 관리하는 데 도움을 줍니다.

리액트는 사용자 인터페이스를 구성하는 자바스크립트 라이브러리이고 리액트 네이티브는 React 방식으로 Android와 iOS의 네이티브 화면을 만드는 도구입니다. 코드의 상당 부분을 공유할 수 있지만 카메라, 결제, 알림처럼 플랫폼 기능을 깊게 쓰거나 화면 정책이 다르면 iOS·Android별 코드와 테스트가 필요할 수 있습니다.

<이미지 출처: Stack Overflow>

기술 이름만 보고 개발사를 고르기보다 왜 그 기술이 요구사항에 맞는지 물어보세요. 대안, 선택 이유, 예상 비용, 바꾸기 어려운 지점을 설명할 수 있어야 합니다.

외주 개발을 시작하는 6단계

1. 문제와 완료 기준

기능 목록에 앞서 누가 어떤 문제를 겪고 있는지, 어떤 수치가 달라지면 성공인지 정합니다. 각 기능에는 정상 흐름, 예외 상황, 권한, 성능·보안·접근성 같은 비기능 요구사항, 검수 방법을 붙입니다. 범위가 불확실하다면 MVP로 가장 위험한 가설부터 확인하는 편이 낫습니다.

2. IP와 자산 소유권

‘소스코드 제공’만으로는 충분하지 않습니다. 새로 만든 코드와 디자인의 저작권 또는 이용권, 기존 모듈과 오픈소스 라이선스, 도메인·클라우드·앱스토어·분석 도구 계정, 데이터의 소유와 반출 방식까지 적어야 합니다. 저장소와 주요 서비스 계정은 가능한 한 발주사 명의로 만들고 필요한 권한만 외주사에 부여합니다.

저작권을 이전하지 않는 제품이나 솔루션이라면 소프트웨어 임치를 대안으로 검토할 수 있습니다. 한국저작권위원회의 SW임치는 저작권자의 폐업이나 소스코드 멸실 등 약정한 조건이 생겼을 때 사용권자가 유지보수를 이어갈 수 있도록 소스코드와 기술정보를 제3의 기관에 맡기는 제도입니다. 실제 계약에서는 대상물, 최신본 갱신 주기, 교부 조건을 구체적으로 합의해야 합니다.

3. 아키텍처 결정 기록

서버 구조, 클라우드 서비스, DB, 인증 방식, 외부 API처럼 나중에 바꾸기 어려운 선택은 아키텍처 결정 기록(ADR)으로 남깁니다. ADR에는 결정의 배경, 검토한 대안, 선택 내용, 예상 결과를 적습니다. AWS의 ADR 가이드처럼 결정 기록을 모아 두면 새 담당자나 다른 개발사가 ‘무엇을 썼는지’뿐 아니라 ‘왜 그렇게 정했는지’까지 파악할 수 있습니다.

4. 작동하는 결과물과 검수 증거

마지막 날에 전체 결과물을 한꺼번에 받지 말고 짧은 주기로 작동하는 기능을 시연하고 검수합니다. 각 회차에는 배포 주소, 변경 내역, 테스트 결과, 남은 결함과 위험을 연결합니다. 보안도 납품 직전 점검 항목이 아니라 개발 과정의 요구사항으로 다뤄야 합니다. NIST의 SSDF 1.1은 발주사와 공급사가 보안 개발 활동을 협의할 때 공통 기준으로 참고할 수 있습니다.

5. 인수인계와 운영 책임

인수인계 항목에는 소스코드, 빌드·배포 절차, 환경별 설정 목록, DB 스키마와 마이그레이션, 외부 연동, 모니터링, 장애 대응 절차, 백업·복구 방법, 의존성 목록이 포함돼야 합니다. 비밀번호와 비밀 키 자체를 문서에 적기보다 보관 위치와 권한 이전 절차를 정합니다. CISA가 정의한 SBOM처럼 사용한 소프트웨어 구성 요소와 공급망 관계를 기록하면 취약점이나 라이선스 영향을 추적하기 쉬워집니다.

담당자는 문서만 전달받지 말고 새 환경에서 직접 빌드·배포하고 백업을 복구해 봐야 합니다. 외주사의 도움 없이 재현할 수 있어야 인수인계가 끝납니다. 계약 종료 뒤에는 불필요한 저장소·클라우드·데이터 접근 권한도 회수합니다.

6. 공급업체 전환 계획

공급업체 종속은 특정 기술을 썼다는 사실만으로 판단할 수 없습니다. 데이터 내보내기 형식, 공개된 API와 표준 사용 여부, 인프라 설정의 이식성, 대체 인력의 접근 가능성, 전환에 필요한 비용과 시간이 판단 기준입니다. 계약서에는 종료 시 지원 기간, 자료 전달 기한, 데이터 삭제 확인, 새 공급업체에 설명할 범위를 적습니다.

외주 개발 체크리스트

비전공자가 외주 개발 전에 자주 묻는 질문

코딩을 배워야 외주 개발을 맡길 수 있나요?

직접 구현할 수준의 코딩 지식은 필수가 아닙니다. 대신 사용자 문제와 우선순위, 수용 기준, 데이터·운영 위험을 설명하고 외주사의 제안을 비교할 수 있어야 합니다. 프론트엔드·백엔드·DB·API의 관계를 아는 정도면 대화의 출발점으로 충분합니다.

소스코드만 받으면 인수인계가 끝나나요?

아닙니다. 소스코드와 함께 빌드·배포 절차, 환경 설정, DB 변경 이력, 외부 연동, 계정과 권한, 모니터링·백업·복구 방법, 의존성 목록을 받아야 합니다. 내부 담당자가 새 환경에서 실행과 배포를 재현해 봐야 제대로 검수할 수 있습니다.

외주 개발사를 고를 때 포트폴리오보다 중요한 것은 무엇인가요?

비슷한 결과물을 만든 경험도 중요하지만 요구사항의 빈틈을 질문하는 방식과 기술 선택의 근거, 품질을 증명하는 방법, 지식 이전 계획을 함께 봐야 합니다. 외주 사기와 계약 위험이 걱정된다면 외주 사기 방지 절대 수칙 열 가지도 확인해 보세요.

외주사의 실력은 설명과 인수인계에서 드러납니다

좋은 외주사는 어려운 기술을 늘어놓기보다 선택의 이유와 비용, 위험을 발주사가 판단할 수 있는 말로 설명합니다. 개발이 끝난 뒤에도 회사가 서비스를 운영하고 다음 결정을 내릴 수 있도록 코드와 문서, 계정, 지식을 넘깁니다. 영국 정부의 외부 인력 협업 지침도 공급업체 변경을 고려한 지식 이전 계획과 필요한 접근 권한의 회수를 강조합니다.

다빈치와 외주 개발을 논의할 때도 기능 목록만 보내기보다 해결하려는 문제와 내부 책임자, 희망 일정, 반드시 지켜야 할 조건을 함께 알려주세요. 같은 예산 안에서도 무엇을 먼저 검증해야 하는지 더 구체적으로 이야기할 수 있습니다.

참고한 공식 자료

• Mozilla MDN: 서버 측 개발, JavaScript, PWA

• React 및 React Native 공식 문서

• AWS Prescriptive Guidance: ADR

• 한국저작권위원회: SW임치

• NIST: SSDF 1.1

• CISA: SBOM Resources Library

• GOV.UK Service Manual: 외부 인력과 협업