외주개발 업체 포트폴리오 검증 방법: 견적보다 먼저 확인해야 할 레퍼런스 체크리스트
답은 간단합니다. 외주개발 업체의 포트폴리오는 ‘화면이 예쁜가’가 아니라 ‘우리와 비슷한 데이터 흐름, 관리자 업무, 배포·운영 조건을 끝까지 처리해본 적이 있는가’로 검증해야 합니다. 견적서를 보기 전에 최소 네 가지 증거를 확인하세요. 첫째, 유사 서비스 구조입니다. 둘째, 해당 업체가 실제로 맡은 범위입니다. 셋째, 출시 후 운영·유지보수 경험입니다. 넷째, 소스코드·서버·문서·검수 기준을 남길 수 있는 산출물 관리 능력입니다.
많은 발주자가 포트폴리오를 볼 때 업종명과 디자인만 봅니다. 예를 들어 ‘예약 서비스 개발 경험 있음’이라는 문구만 보고 우리 서비스도 가능하다고 판단합니다. 하지만 실제로는 단순 예약 폼인지, 결제 승인과 취소, 노쇼 처리, 관리자 승인, 문자·카카오 알림, 정산, 환불 로그까지 포함된 예약 시스템인지에 따라 난이도가 완전히 달라집니다. 외주개발 업체 포트폴리오 검증의 핵심은 결과물 이미지가 아니라 운영 구조의 유사성을 확인하는 것입니다.
포트폴리오 이미지만 믿으면 실패하는 이유
포트폴리오는 판매 자료입니다. 잘 만든 화면, 대표 고객사 로고, 짧은 프로젝트 설명은 업체의 첫인상을 판단하는 데 도움이 됩니다. 그러나 실제 개발 리스크는 대부분 화면 뒤에 숨어 있습니다. 로그인 권한이 어떻게 나뉘는지, 결제 실패 시 어떤 상태값이 남는지, 관리자가 데이터를 잘못 수정했을 때 복구 가능한지, 외부 API 장애가 발생하면 사용자에게 어떤 메시지를 보여주는지, 배포 중 문제가 생기면 이전 버전으로 돌아갈 수 있는지 같은 질문은 포트폴리오 썸네일만으로 알 수 없습니다.
특히 MVP, SaaS, 관리자 시스템, 예약·매칭·결제 서비스, CRM, 업무 자동화, AI 기능이 포함된 서비스는 단순 화면 개발이 아닙니다. 사용자의 입력이 데이터베이스에 저장되고, 관리자 화면에서 처리되며, 알림과 결제, 권한, 로그, 정산, 통계, 외부 API까지 연결됩니다. 따라서 ‘비슷한 앱을 만들어봤다’는 말보다 ‘비슷한 업무 흐름을 어디까지 구현했고, 출시 후 어떤 운영 이슈를 처리했는가’가 더 중요합니다.
좋은 포트폴리오 검증 질문은 ‘이런 디자인 가능하세요?’가 아니라 ‘이 업무가 실패했을 때 시스템이 어떻게 대응합니까?’에 가깝습니다.
1차 검증: 업종이 아니라 서비스 구조로 분류하기
외주개발 업체를 비교할 때 가장 먼저 할 일은 포트폴리오를 업종별로 보지 않는 것입니다. 병원, 교육, 커머스, 부동산, 제조 같은 업종명은 참고 정보일 뿐입니다. 실제 개발 난이도는 서비스 구조가 결정합니다. 아래 표처럼 우리 서비스가 어떤 구조에 가까운지 먼저 분류한 뒤, 업체 포트폴리오가 그 구조와 맞는지 확인해야 합니다.
| 서비스 유형 | 겉으로 보이는 기능 | 실제로 확인할 구조 | 검증 질문 |
|---|---|---|---|
| 회사 홈페이지·랜딩페이지 | 소개, 문의, 게시판 | CMS, SEO, 폼 저장, 알림, 관리자 수정 권한 | 기존 URL 이전, 리다이렉트, 검색 노출, 문의 데이터 관리는 어떻게 했나요? |
| 예약 서비스 | 날짜 선택, 예약 신청 | 예약 상태, 결제, 취소·환불, 알림, 관리자 승인, 재고·좌석 관리 | 예약 취소 시 결제, 알림, 관리자 로그가 어떤 순서로 처리되나요? |
| 매칭 플랫폼 | 회원 가입, 검색, 신청 | 회원 유형, 매칭 조건, 승인·거절, 메시지, 신고, 정산 | 공급자와 수요자 권한, 분쟁 상황, 거래 취소 처리는 어떻게 설계했나요? |
| B2B SaaS | 로그인, 대시보드, 구독 | 고객사별 데이터 분리, 역할 권한, 요금제, 감사 로그, 관리자 콘솔 | 회사별 데이터가 섞이지 않도록 어떤 구조를 사용했나요? |
| AI 자동화 기능 | 문서 요약, 챗봇, 추천 | 프롬프트 관리, API 비용 제한, 결과 검수, 로그, 개인정보 처리 | AI 응답 오류나 비용 급증을 어떻게 감지하고 차단하나요? |
이 분류를 하지 않고 견적을 받으면 업체마다 전혀 다른 범위를 기준으로 가격을 제시합니다. 한 업체는 관리자 시스템과 배포 자동화를 포함하고, 다른 업체는 사용자 화면만 포함할 수 있습니다. 겉으로는 같은 ‘MVP 개발’ 견적이지만 실제 납품물은 크게 다를 수 있습니다. 견적 요청 전에 기능 범위를 정리하는 방법이 필요하다면 요구사항 명세서 템플릿과 실전 예시를 함께 참고하면 좋습니다.
업체에 요청해야 할 포트폴리오 증거 자료
포트폴리오 검증은 무리하게 영업비밀을 요구하는 일이 아닙니다. NDA 때문에 고객사명이나 소스코드를 공개할 수 없는 경우도 많습니다. 대신 마스킹된 자료, 범위 설명, 운영 산출물처럼 공개 가능한 증거를 요청할 수 있습니다. 신뢰할 수 있는 업체라면 보안 범위 안에서 자신의 역할과 결과물을 설명할 방법을 갖고 있습니다.
- 프로젝트 개요: 서비스 유형, 개발 기간, 참여 인원, 출시 여부, 운영 기간
- 담당 범위: 기획, UI 디자인, 프론트엔드, 백엔드, 관리자, 배포, 유지보수 중 실제 수행한 영역
- 유사 기능: 로그인, 결제, 예약, 매칭, 권한, 통계, 알림, 파일 업로드, 외부 API 연동 등 우리 서비스와 겹치는 기능
- 관리자 화면: 사용자 관리, 콘텐츠 관리, 주문·예약 관리, 권한 관리, 로그, 엑셀 다운로드 등 운영 기능의 캡처 또는 설명
- 기술 구조: 사용 기술, 서버 구성, 데이터베이스, 외부 API, 배포 방식, 모니터링 방식
- 운영 증거: 유지보수 티켓 예시, 장애 대응 프로세스, 배포 기록, QA 체크리스트, 사용자 매뉴얼
- 인수인계 산출물: Git 저장소, 환경변수 목록, 서버 계정 구조, DB 백업 방식, 관리자 매뉴얼, 배포 문서
여기서 중요한 것은 ‘자료를 얼마나 많이 주는가’보다 ‘자료가 서로 연결되는가’입니다. 예를 들어 포트폴리오에는 결제 기능이 있다고 되어 있는데 관리자 화면에서 결제 취소 내역을 조회할 수 없고, 유지보수 범위에도 결제 장애 대응이 빠져 있다면 실제 운영 경험이 부족할 가능성이 있습니다.
레퍼런스 체크는 누구에게, 무엇을 물어봐야 하나
레퍼런스 체크는 단순히 이전 고객에게 ‘만족하셨나요?’라고 묻는 절차가 아닙니다. 만족도는 주관적이고, 프로젝트 상황마다 다릅니다. 대신 일정, 범위 변경, 커뮤니케이션, 품질, 출시 후 대응이라는 다섯 영역을 구체적으로 확인해야 합니다. 고객사 직접 연락이 어렵다면 업체 PM이 실제 사례를 기준으로 답변하게 하고, 가능한 범위에서 증거 자료를 요청하세요.
| 검증 영역 | 질문 예시 | 좋은 신호 | 주의 신호 |
|---|---|---|---|
| 일정 관리 | 초기 일정과 실제 출시 일정이 얼마나 달랐나요? | 지연 원인, 변경 범위, 의사결정 기록을 설명한다 | 무조건 고객 탓, 기획 탓으로만 돌린다 |
| 범위 관리 | 중간에 기능 추가가 생겼을 때 어떻게 처리했나요? | 추가 견적, 일정 영향, 우선순위 조정 기준이 있다 | 처음에는 다 된다고 하고 나중에 비용을 요구한다 |
| 품질 관리 | 검수 중 발견된 오류는 어떻게 추적했나요? | 이슈 보드, 테스트 케이스, 재현 절차를 사용한다 | 카카오톡 메시지로만 버그를 처리한다 |
| 운영 대응 | 출시 후 장애나 문의가 생겼을 때 대응 방식은 어땠나요? | 긴급도 기준, 담당자, 응답 채널, 조치 기록이 있다 | 유지보수 계약 전에는 거의 대응하지 않는 구조다 |
| 인수인계 | 소스코드, 서버, DB, 문서는 어떤 형태로 넘겼나요? | 저장소, 계정, 배포 문서, 관리자 매뉴얼을 남긴다 | 소스 전달은 가능하지만 실행 방법은 설명하지 못한다 |
레퍼런스가 너무 완벽하게만 들린다면 오히려 추가 질문이 필요합니다. 실무 프로젝트에는 거의 항상 범위 변경, 일정 조정, 검수 오류, 운영 문의가 발생합니다. 좋은 업체는 문제가 없었다고 말하는 업체가 아니라 문제가 생겼을 때 어떻게 기록하고 해결했는지 설명할 수 있는 업체입니다.
비전문가도 할 수 있는 기술 역량 검증 질문
창업자, 마케터, PM, 운영자가 개발 언어와 프레임워크를 모두 알 필요는 없습니다. 대신 업무 흐름을 기준으로 질문하면 됩니다. ‘React 잘하세요?’보다 ‘사용자가 결제 후 예약을 취소하면 어떤 데이터가 바뀌고, 관리자는 어디서 확인하나요?’가 훨씬 좋은 질문입니다. 실무 경험이 있는 개발사는 비전문가에게도 흐름 중심으로 설명할 수 있습니다.
1. 데이터 흐름 질문
- 회원가입부터 결제, 예약, 취소까지 데이터가 어떤 순서로 저장되나요?
- 관리자가 사용자 정보를 수정하면 변경 이력은 남나요?
- 엑셀 다운로드나 대량 업로드 기능에서 개인정보는 어떻게 제한하나요?
- 삭제된 데이터는 완전 삭제인가요, 복구 가능한 상태인가요?
2. 관리자 시스템 질문
- 슈퍼관리자, 운영자, 정산 담당자, 콘텐츠 담당자의 권한을 다르게 줄 수 있나요?
- 운영자가 실수로 중요한 값을 바꾸면 누가 언제 바꿨는지 확인할 수 있나요?
- 관리자 화면은 사용자 서비스와 같은 서버를 쓰나요, 별도 접근 제한이 있나요?
- 관리자 기능은 MVP 1차 범위에 어디까지 포함하는 것이 적절한가요?
3. 배포·운영 질문
- 개발 서버, 테스트 서버, 운영 서버를 어떻게 구분하나요?
- 배포 실패 시 이전 버전으로 되돌릴 수 있나요?
- 장애가 발생하면 어떤 로그와 모니터링 화면을 보고 원인을 찾나요?
- 서버 비용, 도메인, 클라우드 계정은 누구 명의로 운영하나요?
4. 보안·개인정보 질문
- 개발자가 운영 DB의 개인정보를 직접 볼 수 있나요?
- 비밀번호, API 키, 결제 키 같은 민감 정보는 어디에 저장하나요?
- 외주 개발사가 개인정보 처리 업무를 맡는 경우 계약서와 처리방침에 어떤 항목이 필요할까요?
- 취약점이나 보안 패치가 필요한 라이브러리는 어떻게 확인하나요?
NIST SSDF와 OWASP ASVS 같은 공개 기준은 보안 개발과 애플리케이션 검증을 체계적으로 설명하기 위해 만들어졌습니다. 발주자가 모든 항목을 직접 적용할 필요는 없지만, 결제·개인정보·권한·API가 포함된 서비스라면 업체가 최소한 보안 요구사항, 취약점 대응, 배포 전 검수 방식을 설명할 수 있어야 합니다.
MVP, SaaS, 관리자 시스템별로 보는 ‘진짜 유사 경험’
포트폴리오의 유사성은 업종이 아니라 운영 복잡도로 판단해야 합니다. 다음 기준을 적용하면 업체의 경험이 우리 프로젝트와 실제로 맞는지 더 빨리 확인할 수 있습니다.
MVP 개발 외주
MVP는 모든 기능을 적게 만드는 일이 아니라, 검증에 필요한 핵심 흐름을 끊기지 않게 만드는 일입니다. 예를 들어 매칭 서비스 MVP라면 회원가입, 프로필 등록, 검색, 매칭 신청, 관리자 승인, 알림 정도가 핵심일 수 있습니다. 반대로 쿠폰, 리뷰, 포인트, 추천 알고리즘은 2차 범위일 수 있습니다. 업체가 MVP 경험이 있다고 말한다면 ‘무엇을 제외했는지’를 물어보세요. 좋은 MVP 개발사는 만든 기능보다 미룬 기능을 더 논리적으로 설명합니다.
B2B SaaS 개발 외주
SaaS는 단순 웹앱보다 권한과 데이터 분리가 중요합니다. 고객사별 데이터가 분리되어야 하고, 관리자와 일반 사용자의 권한이 달라야 하며, 요금제나 사용량 제한이 필요할 수 있습니다. 업체 포트폴리오가 SaaS라고 되어 있다면 고객사, 사용자, 역할, 권한, 감사 로그, 요금제 변경, 데이터 백업을 어떻게 처리했는지 확인하세요. SaaS 구조를 더 깊게 검토해야 한다면 기존 글 다중 테넌시 데이터 모델링 가이드도 함께 볼 만하지만, 이 글의 핵심은 업체가 그 구조를 실제로 설명할 수 있는지입니다.
관리자 시스템 개발 외주
관리자 시스템은 외주개발 실패가 가장 자주 드러나는 영역입니다. 사용자 화면은 완성되어 보이는데 운영자가 주문을 취소하지 못하거나, 회원 상태를 바꾸지 못하거나, 정산 데이터를 다운로드하지 못하면 출시 후 운영이 멈춥니다. 포트폴리오에 사용자 화면만 있고 관리자 화면 설명이 없다면 반드시 추가로 물어봐야 합니다. 관리자 시스템은 선택 기능이 아니라 운영 비용을 결정하는 핵심 기능입니다.
예약·매칭·결제 서비스
이 유형은 상태 관리가 중요합니다. 예약 신청, 결제 대기, 결제 완료, 관리자 승인, 취소 요청, 환불 완료, 노쇼, 정산 완료처럼 상태가 바뀌는 흐름이 많습니다. 업체가 유사 경험이 있다면 화면 캡처보다 상태 전이표, 관리자 처리 흐름, 실패 케이스 처리 방식을 설명할 수 있어야 합니다. 결제 연동 자체보다 결제 이후의 예외 처리가 더 어렵습니다.
AI 기능과 업무 자동화
AI 기능은 데모가 쉬운 편입니다. 문서 요약, 챗봇, 자동 분류는 짧은 시연으로 그럴듯하게 보일 수 있습니다. 그러나 실서비스에서는 API 비용, 응답 지연, 잘못된 답변, 민감 정보 입력, 로그 보관, 사람 검수, 프롬프트 변경 관리가 문제가 됩니다. 업체가 AI 기능 포트폴리오를 제시한다면 ‘모델을 붙였다’보다 ‘운영 중 비용과 오류를 어떻게 관리했는가’를 확인해야 합니다.
납기 리스크를 판단하는 포트폴리오 질문
납기 리스크는 업체가 바쁘냐 아니냐만으로 결정되지 않습니다. 범위가 불명확하고, 검수 기준이 없고, 의사결정자가 늦게 답하고, 관리자 기능이 뒤늦게 추가되고, 외부 API 심사가 지연되면 일정은 쉽게 무너집니다. 따라서 포트폴리오 검증 단계에서 일정 관리 방식을 확인해야 합니다.
- 프로젝트 시작 전에 기능 목록과 화면 목록을 어디까지 확정했나요?
- 디자인 확정 전 개발을 시작했을 때 어떤 문제가 있었나요?
- 외부 API, 결제, 문자, 지도, 본인인증 같은 연동 심사는 누가 챙겼나요?
- 중간 검수는 몇 회로 나누었고, 어떤 산출물을 기준으로 확인했나요?
- 출시일이 고정된 프로젝트에서 기능을 줄이는 의사결정을 해본 적이 있나요?
- 발주자의 피드백 지연이 생기면 일정표에 어떻게 반영하나요?
업체가 모든 질문에 ‘다 가능합니다’라고만 답한다면 안심하기 어렵습니다. 현실적인 업체는 일정에 영향을 주는 요소를 먼저 짚습니다. 결제 심사, 앱스토어 심사, 개인정보 처리방침, 관리자 권한 정책, 외부 API 발급, 데이터 이관처럼 발주자가 준비해야 하는 항목을 초기에 알려주는 업체가 납기 리스크를 더 잘 관리합니다.
외주개발 업체 포트폴리오 비교 매트릭스
여러 업체의 제안서를 받았다면 아래 기준으로 점수화해 보세요. 점수는 1점부터 5점까지 주되, 모르는 항목은 0점으로 두는 것이 좋습니다. 답변이 없는 항목을 평균에 포함하면 실제 리스크가 가려집니다.
| 평가 항목 | 5점에 가까운 상태 | 1점에 가까운 상태 | 확인 자료 |
|---|---|---|---|
| 유사 구조 경험 | 우리와 비슷한 데이터 흐름과 관리자 기능을 설명한다 | 업종명만 비슷하고 기능 구조 설명이 없다 | 화면 흐름도, 관리자 캡처, 기능 목록 |
| 담당 범위 명확성 | 기획, UI, 프론트, 백엔드, 배포 중 실제 역할을 구분한다 | 협력사 작업과 자체 작업을 섞어 말한다 | 프로젝트 범위표, 참여 인력 설명 |
| 운영 안정성 | 배포, 장애 대응, 로그, 백업, 유지보수 절차가 있다 | 출시 이후는 별도 문의라고만 답한다 | 운영 문서, 티켓 예시, 배포 기록 |
| 보안·개인정보 | 권한, 민감정보, 테스트 데이터, 취약점 대응을 설명한다 | 보안은 나중에 하면 된다고 말한다 | 보안 체크리스트, 계정 정책, 접근 통제 |
| 검수·인수인계 | 검수 기준, 테스트 케이스, 소스·서버 인수인계 범위가 명확하다 | 완성되면 넘겨준다는 식으로만 답한다 | 검수표, 저장소 구조, 배포 문서 |
| 커뮤니케이션 | 정기 회의, 이슈 보드, 변경 요청 프로세스가 있다 | 메신저 대화에 의존하고 기록이 남지 않는다 | 회의록 예시, 이슈 관리 방식 |
총점이 가장 높은 업체가 무조건 정답은 아닙니다. 프로젝트 성격에 따라 가중치를 달리해야 합니다. 랜딩페이지 리뉴얼은 디자인과 CMS 운영 경험의 비중이 높습니다. 결제 서비스는 상태 관리와 장애 대응 비중이 높습니다. B2B SaaS는 권한, 데이터 분리, 관리자 시스템, 유지보수 역량이 더 중요합니다. 정부지원사업 MVP라면 납기와 산출물, 비용 집행 증빙을 맞출 수 있는지도 함께 봐야 합니다.
계약 전 반드시 연결해서 확인할 항목
포트폴리오 검증은 계약 검토와 분리되어서는 안 됩니다. 포트폴리오에서 확인한 장점이 계약서와 산출물 범위에 반영되지 않으면 나중에 분쟁이 됩니다. 예를 들어 업체가 관리자 시스템 경험을 강조했더라도 계약서 기능 목록에 관리자 권한, 로그, 엑셀 다운로드, 운영 매뉴얼이 없다면 납품 범위가 아닐 수 있습니다.
- 과업 범위: 사용자 화면, 관리자 화면, API, 배치 작업, 알림, 통계, 데이터 이관을 기능 단위로 적었는가
- 검수 기준: 어떤 조건이면 완료로 볼지, 버그 수정은 몇 차까지 포함하는지 정했는가
- 소스코드와 저작재산권: 저장소 접근, 소스 전달 시점, 저작재산권 양도 또는 이용허락 범위를 명확히 했는가
- 서버·도메인·클라우드 계정: 발주자 명의로 만들지, 업체 명의로 운영하다 이전할지 정했는가
- 개인정보 처리: 개발·운영 과정에서 개인정보를 처리한다면 위탁 계약, 접근 권한, 처리방침, 파기·반환 기준을 확인했는가
- 유지보수: 무상 하자보수와 유상 유지보수, 기능 추가, 장애 대응의 범위를 구분했는가
- 하도급·외부 인력: 실제 개발자가 누구인지, 재위탁 여부와 책임 소재가 명확한가
공공 소프트웨어 사업 관련 지침은 과업내용 확정과 변경, 계약서 기재사항, 하도급 관리 등을 중요하게 다룹니다. 민간 외주개발에서도 이 관점은 유용합니다. 계약 단계에서는 외주개발 계약서 필수 조항 체크리스트를 함께 확인하고, 개발 종료 전에는 외주개발 인수인계 체크리스트로 소스코드, 서버, DB, 배포, 운영 문서까지 점검하는 것이 안전합니다. 법률·개인정보·저작권 조항은 프로젝트 상황에 따라 달라질 수 있으므로 필요한 경우 전문가 검토를 받는 것이 좋습니다.
포트폴리오 검증에서 보이는 위험 신호
다음 신호가 보인다고 해서 반드시 나쁜 업체라는 뜻은 아닙니다. 다만 서비스가 결제, 개인정보, 관리자 운영, SaaS 구조를 포함한다면 추가 검증 없이 계약하기에는 위험합니다.
- 포트폴리오가 이미지 중심이고 실제 담당 범위를 설명하지 못한다
- 라이브 서비스 여부, 운영 기간, 유지보수 범위를 말하지 않는다
- 관리자 화면이나 백엔드 구조에 대한 질문을 계속 피한다
- 모든 기능을 짧은 기간에 가능하다고 말하면서 제외 범위가 없다
- 견적서가 ‘웹 개발 일체’처럼 한 줄로 되어 있고 산출물이 없다
- 소스코드 전달, 서버 계정, DB 백업, 배포 문서에 대한 답이 모호하다
- 보안과 개인정보 질문에 ‘출시 후 처리하면 된다’고 답한다
- 하도급이나 프리랜서 투입 여부를 명확히 공개하지 않는다
- 커뮤니케이션 도구가 메신저뿐이고 이슈 관리 방식이 없다
- 레퍼런스 고객 연락이 불가능하다면서 대체 증거도 제공하지 않는다
특히 ‘저희 솔루션으로 빠르게 커스터마이징합니다’라는 제안은 장단점이 있습니다. 빠른 출시에는 도움이 될 수 있지만, 소스코드 소유권, 기능 확장성, 데이터 이전, 특정 업체 종속 가능성을 확인해야 합니다. 솔루션 기반 개발을 선택한다면 계약서에 수정 가능 범위와 해지 시 데이터·소스·계정 이전 조건을 더 명확히 적어야 합니다.
견적 요청 전 발주자가 준비해야 할 체크리스트
좋은 업체를 고르려면 발주자도 비교 가능한 질문을 준비해야 합니다. 준비가 부족하면 업체마다 다른 전제를 두고 견적을 내고, 결국 가장 저렴한 견적이 좋아 보입니다. 하지만 실제로는 빠진 기능이 많을 수 있습니다. 최소한 아래 항목은 정리한 뒤 포트폴리오와 견적을 요청하세요.
| 준비 항목 | 작성 예시 | 왜 필요한가 |
|---|---|---|
| 서비스 목표 | 3개월 안에 예약 MVP를 출시해 유료 예약 100건 검증 | 기능 우선순위와 납기 판단 기준이 된다 |
| 사용자 역할 | 일반회원, 파트너, 운영자, 슈퍼관리자 | 권한과 관리자 기능 범위가 결정된다 |
| 핵심 흐름 | 회원가입 → 예약 신청 → 결제 → 관리자 승인 → 알림 → 취소 | 유사 포트폴리오를 구조 기준으로 비교할 수 있다 |
| 필수 기능 | 로그인, 예약, 결제, 취소, 관리자 예약 관리, 알림 | 견적의 포함·제외 범위를 명확히 한다 |
| 데이터 항목 | 이름, 연락처, 예약일, 결제금액, 취소사유 | 개인정보, DB 설계, 관리자 검색 기준이 정해진다 |
| 참고 서비스 | 유사 서비스 2~3개와 마음에 드는 화면·흐름 | 업체가 디자인보다 기능 구조를 이해하기 쉬워진다 |
| 검수 기준 | 결제 성공·실패·취소 케이스가 테스트되어야 완료 | 완료 기준을 두고 분쟁을 줄인다 |
| 출시 기한 | 지원사업 최종 보고 전 베타 오픈 필요 | 범위 축소와 일정 버퍼 판단이 가능하다 |
이 체크리스트는 업체를 압박하기 위한 문서가 아닙니다. 오히려 좋은 업체가 정확한 견적과 일정을 제시할 수 있도록 돕는 자료입니다. 준비된 발주자는 포트폴리오를 더 날카롭게 볼 수 있고, 업체도 불확실성을 줄일 수 있습니다.
30분 포트폴리오 검증 미팅 진행안
업체 미팅 시간이 길 필요는 없습니다. 다만 질문 순서가 중요합니다. 아래 흐름으로 30분만 진행해도 단순 영업 설명과 실제 역량을 어느 정도 구분할 수 있습니다.
- 0~5분: 우리 서비스 핵심 흐름 설명 — 사용자 역할, 핵심 기능, 출시 목표를 짧게 공유합니다.
- 5~12분: 가장 유사한 포트폴리오 1개 선택 — 업체가 직접 가장 유사한 사례를 고르게 합니다. 왜 유사한지 설명하게 하세요.
- 12~20분: 담당 범위와 관리자 기능 확인 — 실제 구현 범위, 백엔드, 관리자, 배포, 유지보수 참여 여부를 묻습니다.
- 20~25분: 예외 상황 질문 — 결제 실패, 예약 취소, 권한 오류, 외부 API 장애, 데이터 삭제 같은 상황을 하나 골라 처리 방식을 확인합니다.
- 25~30분: 산출물과 다음 단계 확인 — 견적 전 필요한 자료, 산출물, 계약 범위, 유지보수 조건, 인수인계 방식까지 확인합니다.
미팅 후에는 반드시 같은 양식으로 업체별 답변을 정리하세요. 기억에 의존하면 말이 부드러웠던 업체가 더 좋아 보입니다. 실제 의사결정은 답변의 구체성, 산출물의 존재, 리스크를 먼저 말하는 태도, 우리 서비스 구조와의 유사성을 기준으로 해야 합니다.
AgentMit이 도울 수 있는 지점
외주개발 업체를 고르는 일은 단순히 개발자를 찾는 일이 아닙니다. 어떤 범위를 1차로 만들고, 어떤 기능을 미루며, 관리자 시스템을 어디까지 넣고, 출시 후 운영을 어떻게 이어갈지 결정하는 일입니다. AgentMit은 저렴한 코딩 인력 제공보다 요구사항 정리, MVP 범위 설정, UI·백엔드·관리자 시스템, 자동화, AI 기능, 배포와 유지보수까지 연결해 검토하는 방식으로 프로젝트를 봅니다.
이미 여러 업체의 포트폴리오와 견적을 받은 상태라면, AgentMit 또는 BizMit 상담에서 범위가 과도한지, 관리자 기능이 빠져 있는지, 운영 리스크가 숨어 있는지 함께 리뷰할 수 있습니다. 특히 정부지원사업 MVP, SaaS 프로토타입, 예약·매칭·결제 서비스, 내부 업무 자동화, AI 기능이 포함된 서비스는 초기에 구조를 잘못 잡으면 재개발 비용이 커질 수 있습니다.
포트폴리오 검증 이후 실제 개발 범위 리뷰가 필요하다면 BizMit 서비스 안내를 확인하거나 AgentMit 개발 상담으로 현재 기능 목록과 참고 서비스를 공유해 주세요. 상담의 목표는 무조건 개발을 크게 만드는 것이 아니라, 지금 단계에서 반드시 만들어야 할 것과 다음 단계로 미뤄도 되는 것을 구분하는 데 있습니다.
참고한 기준과 출처
이 글은 외주개발 실무 관점에 더해 공개 표준과 국내 법령 정보를 참고했습니다. 법령과 계약 해석은 프로젝트 조건에 따라 달라질 수 있으므로 최종 계약 전에는 최신 조문과 전문가 검토를 확인하세요.
- 국가법령정보센터, 소프트웨어사업 계약 및 관리감독에 관한 지침 — 과업내용, 계약, 하도급, 관리 기준 참고
- 국가법령정보센터, 개인정보 보호법 제26조 — 개인정보 처리 위탁과 수탁자 관리·감독 관점 참고
- 국가법령정보센터, 저작권법 — 소스코드와 프로그램 저작재산권 계약 검토 관점 참고
- ISO/IEC/IEEE 29148:2018 — 요구사항 공학과 검수 기준 문서화 관점 참고
- NIST Secure Software Development Framework — 보안 개발 프로세스 검증 관점 참고
- OWASP Application Security Verification Standard — 웹 애플리케이션 보안 검증 요구사항 참고
- Google SRE, Service Level Objectives — 운영 안정성과 서비스 지표 관점 참고
FAQ
Q1. 외주개발 업체 포트폴리오는 몇 개 정도 확인해야 하나요?
개수보다 유사도가 중요합니다. 최소 2~3개 프로젝트를 보되, 업종이 같은지보다 회원가입, 결제, 예약, 관리자 권한, 데이터 처리, 배포·운영 구조가 우리 서비스와 비슷한지 확인해야 합니다.
Q2. 레퍼런스 연락처를 업체에 요청해도 되나요?
요청할 수 있습니다. 다만 NDA나 고객사 정책 때문에 직접 연락이 어려울 수 있으므로, 라이브 서비스 URL, 마스킹된 관리자 화면, 산출물 목록, 유지보수 티켓 예시, 담당 범위 확인서 같은 대체 증거를 함께 요청하는 방식이 현실적입니다.
Q3. 비전문가도 개발사의 기술 역량을 검증할 수 있나요?
가능합니다. 기술명보다 업무 흐름을 질문하면 됩니다. 예를 들어 예약 취소 시 결제 환불, 알림, 관리자 로그가 어떻게 연결되는지, 배포 실패 시 원복 절차가 무엇인지, 개인정보가 포함된 테스트 데이터는 어떻게 분리하는지 물어보면 실무 경험을 판단할 수 있습니다.
Q4. 견적이 가장 저렴한 업체를 선택하면 안 되나요?
단순 랜딩페이지나 일회성 프로토타입은 저가 견적도 선택지가 될 수 있습니다. 하지만 결제, 개인정보, 관리자 시스템, SaaS, 반복 운영이 있는 서비스라면 포트폴리오 증거와 운영 경험이 부족한 저가 견적은 오히려 재개발 비용을 만들 수 있습니다.
Q5. 정부지원사업 MVP도 포트폴리오 검증이 필요한가요?
필요합니다. 지원사업은 선정 이후 일정과 정산 기한이 정해지는 경우가 많아 납기 리스크가 더 크게 작용합니다. 업체가 유사 MVP를 정해진 범위 안에서 출시하고, 산출물과 비용 증빙, 유지보수 범위를 정리해본 경험이 있는지 확인하는 것이 좋습니다.
