노노니 | 실전 서비스 기획자의 인사이트 블로그

외주로 서비스를 개발할 때 소스코드만 받으면 된다고 생각하는 경우가 많습니다. 하지만 서비스를 제대로 운영하고 개선하려면 데이터베이스 구조를 이해하는 것이 필수적입니다. 데이터베이스는 서비스의 모든 정보가 저장되는 곳이므로, 어떤 테이블이 있고 각 테이블에 어떤 데이터가 저장되는지 문서로 받아두어야 나중에 문제를 해결하거나 기능을 추가할 때 훨씬 수월합니다.

 

데이터베이스 문서는 필수 산출물

IT 프로젝트는 완료 시 산출물을 제출하게 되어있습니다. 데이터베이스 구조도도 받고 테이블 명세도 받습니다.

데이터베이스 구조도는 ERD(Entity Relationship Diagram)라고도 하는데, 데이터베이스의 테이블들이 어떻게 연결되어 있는지 시각적으로 보여주는 다이어그램입니다. 테이블 명세는 각 테이블의 칼럼 이름, 데이터 타입, 제약 조건 등을 상세히 설명하는 문서입니다.

 

앱 서비스 제작 완료 시 산출물 목록

앱 서비스를 외주로 제작했을 때 받아야 할 산출물은 다음과 같습니다.

소스코드 관련:

• 프론트엔드 소스코드 전체
• 백엔드 소스코드 전체
• 데이터베이스 마이그레이션 파일
• 환경 변수 설정 파일 샘플
• 깃허브 저장소 소유권 또는 소스코드 백업 파일

데이터베이스 관련:

• 데이터베이스 구조도(ERD)
• 테이블 명세서
• 데이터베이스 백업 파일
• 초기 데이터 스크립트

문서 관련:

• 프로젝트 완료 보고서
• API 문서
• 서버 환경 설정 문서
• 외부 서비스 연동 문서

계정 및 설정 정보:

• 서버 접속 정보
• 데이터베이스 접속 정보
• 클라우드 서비스 계정 정보
• 도메인 및 호스팅 정보
• 외부 API 키 및 계정 정보
• 앱스토어 개발자 계정 정보

디자인 관련:

• 앱 디자인 원본 파일(Figma, Sketch 등)
• 아이콘 및 이미지 원본 파일
• 앱 스크린샷 및 프로모션 이미지

 

데이터베이스 구조도의 중요성

데이터베이스 구조도는 서비스의 데이터 설계를 한눈에 파악할 수 있게 해 줍니다. 예를 들어 사용자 테이블과 주문 테이블이 어떻게 연결되어 있는지, 결제 정보는 어느 테이블에 저장되는지 등을 시각적으로 이해할 수 있습니다.

나중에 다른 개발자가 프로젝트를 이어받거나, 새로운 기능을 추가할 때 데이터베이스 구조도가 있으면 훨씬 빠르게 시스템을 이해할 수 있습니다. 구조도 없이 소스코드만 보고 데이터베이스 구조를 파악하려면 시간이 걸립니다.

 

테이블 명세서의 내용

테이블 명세서에는 각 테이블의 상세 정보가 포함됩니다. 테이블 이름, 테이블 용도 설명, 각 칼럼의 이름, 데이터 타입(VARCHAR, INT, DATETIME 등), NULL 허용 여부, 기본값, 인덱스 정보, 외래키 관계 등이 문서화되어야 합니다.

예를 들어 "users" 테이블이라면 id(INT, PRIMARY KEY), email(VARCHAR(100), UNIQUE, NOT NULL), password(VARCHAR(255), NOT NULL), created_at(DATETIME, DEFAULT NOW()) 같은 식으로 모든 칼럼의 정보가 명시되어야 합니다.

 

API 문서의 필요성

백엔드가 있는 서비스라면 API 문서도 필수입니다. 어떤 엔드포인트가 있는지, 각 API가 어떤 요청을 받고 어떤 응답을 주는지, 인증은 어떻게 하는지, 에러 코드는 무엇인지 등이 문서화되어야 합니다.

프론트엔드와 백엔드가 분리된 구조에서는 API 문서가 없으면 두 영역 간 통신을 이해하기 어렵습니다. 나중에 앱을 수정하거나 웹 버전을 추가로 만들 때 API 문서가 있으면 기존 백엔드를 그대로 활용할 수 있습니다.

 

서버 환경 설정 문서

서비스를 운영하려면 서버 환경 설정에 대한 이해가 필요합니다. 어떤 운영체제를 사용하는지, 어떤 웹서버나 애플리케이션 서버가 설치되어 있는지, 방화벽 설정은 어떻게 되어있는지, SSL 인증서는 어떻게 관리하는지 등이 문서화되어야 합니다.

서버에 문제가 생겼을 때 빠르게 대응하려면 이런 정보가 필수적입니다. 외주사가 특별히 커스텀한 설정이 있다면 그 이유와 방법도 함께 문서로 남겨야 합니다.

 

외부 서비스 연동 문서

결제, 문자 발송, 이메일 발송, 지도, 푸시 알림 같은 외부 서비스를 사용한다면 이들이 어떻게 연동되어 있는지 문서가 필요합니다. 각 서비스의 계정 정보, API 키, 웹훅 설정, 테스트 방법 등이 포함되어야 합니다.

외부 서비스가 갑자기 작동하지 않거나 비용 문제가 생겼을 때 어떤 서비스를 사용하고 있는지 알아야 대응할 수 있습니다. 또한 나중에 더 저렴한 서비스로 전환하고 싶을 때도 현재 연동 방식을 이해해야 합니다.

 

관리자 매뉴얼

서비스 규모가 크고 관리 부서가 나뉘어 있으면 관리자 매뉴얼을 요청하기도 합니다. 회원 관리는 어떻게 하는지, 콘텐츠는 어떻게 등록하는지, 정산은 어떻게 처리하는지 등 관리자가 해야 할 모든 작업이 설명됩니다.

스타트업의 경우 창업자가 서비스의 운영자가 되기에 서비스 기획, 서비스 테스트를 해왔다면 서비스의 이용 방식, 관리 방식을 알고 있기에 외주사가 별도의 매뉴얼 작업을 하지 않습니다. 직원을 통하여 운영을 처리해야 하는 경우, 외주 제작사가 운영을 맡지 않는 경우, 서비스 제작의 과정에 전혀 참여하지 않는 이가 운영을 맡는 경우 매뉴얼이 필요합니다.

매뉴얼 작업도 작업이라 외주 비용의 상승 요인이 됩니다.

 

산출물 검수

프로젝트 완료 시 산출물을 체계적으로 검수하기 위해 산출물 리스트대로 제출되었는지 확인합니다.

모든 항목이 완료되고 검수를 통과해야 잔금을 지급하는 것이 안전합니다. 일부 산출물이 누락된 채로 잔금을 지급하면 외주사가 나머지를 제출하는 데 소극적일 수 있습니다.