MVP 보안 요구사항 체크리스트: 정부지원사업·초기 SaaS 출시 전 인증·권한·데이터·로그 기준

정답부터: MVP 보안은 ‘나중에 붙일 기능’이 아니라 출시 조건입니다
정부지원사업이나 초기 외주개발로 MVP를 만들 때 보안 범위를 무한정 키울 필요는 없습니다. 하지만 인증, 권한, 개인정보 저장, API 접근제어, 파일 업로드, 접속 로그, 백업, 취약점 점검은 출시 후에 고치면 화면 수정이 아니라 구조 변경이 되는 항목입니다. 견적서에 ‘로그인 구현’, ‘관리자 페이지’, ‘DB 구축’이라고만 적혀 있다면 보안 요구사항은 아직 정의되지 않은 상태로 보는 것이 안전합니다.
개인정보를 처리하는 서비스라면 국내 개인정보 보호법상 안전조치의무가 적용될 수 있고, 2026년 기준 개인정보의 안전성 확보조치 기준도 접근권한, 접속기록, 암호화, 재해·재난 대비 같은 운영 항목을 다룹니다. MVP라서 법적·기술적 책임이 사라지는 것은 아닙니다. 다만 대기업 보안 인증 전체를 한 번에 목표로 하기보다, 출시 가능한 최소 안전 기준을 요구사항과 검수표로 고정하는 접근이 현실적입니다. ([law.go.kr](https://law.go.kr/LSW/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1029332029))
이 글의 결론: MVP 보안의 목표는 ‘완벽한 보안’이 아니라 ‘출시 직후 계정 탈취, 권한 우회, 개인정보 노출, 로그 부재, 복구 불가를 막는 것’입니다. 이 다섯 가지를 견적과 검수에 넣으면 출시 후 보안 재공사를 크게 줄일 수 있습니다.
1. MVP 보안 범위를 먼저 나누어야 견적이 흔들리지 않습니다
초기 팀이 흔히 하는 실수는 보안을 ‘기능 목록’ 뒤쪽에 한 줄로 넣는 것입니다. 그러면 개발사는 로그인, 서버 배포, 관리자 메뉴 정도만 구현하고, 비밀번호 저장 방식이나 역할별 권한, 로그 보관, 파일 검증, 백업 복구는 해석 차이로 남습니다. 보안은 별도 기능이 아니라 제품의 모든 흐름에 붙는 검수 조건입니다. 제품 요구사항 전체 틀을 아직 잡지 않았다면 비기능 요구사항 정의서 템플릿과 함께 보는 것이 좋습니다.
| 구분 | 예시 | 최소 보안 수준 |
|---|---|---|
| 데모형 MVP | 랜딩페이지, 클릭 더미, 내부 시연용 프로토타입 | 실제 개인정보를 넣지 않고, 관리자·DB·운영 서버 접근을 제한합니다. |
| 폐쇄 베타 MVP | 초대받은 사용자만 가입, 실제 이메일·업무 데이터 일부 저장 | 인증, 권한, 개인정보 처리방침, 백업, 기본 로그, 취약점 스캔이 필요합니다. |
| 공개 SaaS MVP | 누구나 가입, 팀·조직 단위 데이터, 파일 업로드, 결제·외부 API 연동 | 테넌트 분리, 관리자 MFA, API 권한 검증, 파일 검증, 관리자 감사로그, 장애·침해 대응 절차까지 필요합니다. |
정부지원사업의 경우 사업별 지침과 협약 조건은 반드시 별도로 확인해야 합니다. 다만 실무 검수 관점에서는 ‘개발했습니다’보다 ‘어떤 개인정보를 수집했고, 누가 접근 가능하며, 권한 우회를 어떻게 막았고, 장애 시 어떻게 복구하는지’를 설명할 수 있어야 합니다. 개인정보와 보안 준비 문서는 지원사업 선정 후 개인정보보호·보안 가이드와 연결해 준비하면 산출물 정리가 쉬워집니다.

2. 출시 전 P0 보안 체크리스트: 견적서에 반드시 들어갈 항목
아래 표는 초기 SaaS와 정부지원사업 MVP에서 현실적으로 우선순위가 높은 P0 항목입니다. P0는 ‘있으면 좋은 기능’이 아니라 출시 전 검수에서 실패하면 공개 범위를 줄이거나 출시를 미뤄야 하는 항목입니다. OWASP ASVS는 웹 애플리케이션과 서비스의 보안 요구사항을 설계·개발·테스트 기준으로 제공하고, OWASP Top 10:2025도 접근제어, 보안설정, 공급망, 암호화, 인증, 로깅을 주요 위험 범주로 다룹니다. ([github.com](https://github.com/OWASP/ASVS))
| 영역 | P0 요구사항 | 견적서 반영 문구 | 검수 증거 |
|---|---|---|---|
| 인증 | HTTPS, 안전한 세션·쿠키, 비밀번호 해시 저장, 재설정 토큰 만료, 로그인 실패 제한 | 회원 인증 및 계정 보호 정책 구현 | 비밀번호 평문 미저장 확인, 실패 제한 테스트, 재설정 링크 만료 테스트 |
| 관리자 보안 | 관리자 MFA 또는 강한 2차 보호, 관리자 URL·API 직접 접근 차단 | 관리자 계정 보안 및 접근 제한 구현 | 일반 계정으로 관리자 API 호출 시 403 응답, 관리자 로그인 로그 |
| 권한 | 역할별 권한, 서버 측 권한 검증, 객체 단위 접근제어, 테넌트 분리 | RBAC 및 조직별 데이터 접근제어 구현 | A 사용자가 B 사용자·B 조직 데이터 URL을 호출했을 때 차단 |
| 개인정보 | 수집 항목 최소화, 보유기간, 파기 흐름, 개인정보 처리방침 공개, 민감정보·고유식별정보 처리 여부 확인 | 개인정보 처리 구조 및 정책 페이지 구현 | 수집 항목표, 처리방침 화면, 탈퇴·삭제 테스트 |
| 데이터 보호 | 비밀번호·토큰·API 키 평문 저장 금지, 중요 필드 암호화 또는 마스킹, 운영 DB 접근 제한 | 중요정보 암호화·마스킹 및 비밀관리 적용 | DB 샘플 확인, 관리자 화면 마스킹, 환경변수·시크릿 분리 |
| API·입력값 | 서버 측 검증, 파라미터 바인딩, CORS 제한, 과도한 요청 제한, 에러 상세 노출 방지 | API 입력검증 및 보안 설정 구현 | 잘못된 입력값, 직접 API 호출, 대량 요청 테스트 결과 |
| 파일 업로드 | 확장자·MIME·크기 제한, 실행 불가 저장소, 파일명 재생성, 다운로드 권한 확인 | 파일 업로드 보안 검증 구현 | 스크립트 파일 업로드 차단, 타 사용자 파일 접근 차단 |
| 로그 | 로그인 실패, 권한 실패, 관리자 작업, 데이터 조회·다운로드, 설정 변경, 파일 업로드 기록 | 감사로그 및 보안 이벤트 로그 구현 | 관리자 화면 또는 로그 저장소에서 이벤트 확인 |
| 백업·복구 | 정기 백업, 백업 접근 제한, 최소 1회 복구 테스트, 배포 롤백 절차 | 백업 정책 및 복구 테스트 산출물 제공 | 복구 리허설 기록, 백업 위치·주기 문서 |
| 취약점 점검 | 의존성 스캔, 기본 SAST 또는 코드리뷰, OWASP Top 10 기반 점검 | 출시 전 보안 점검 및 조치 결과서 제공 | 스캔 리포트, 조치 내역, 잔여 위험 목록 |
3. 인증: ‘로그인 됩니다’와 ‘계정이 보호됩니다’는 다릅니다
초기 외주 견적에서 가장 많이 축소되는 영역이 인증입니다. 로그인 화면과 회원 테이블만 있으면 끝났다고 보지만, 실제 출시 조건은 다릅니다. 비밀번호는 평문이나 단순 암호화가 아니라 검증된 단방향 해시와 솔트를 사용해야 하고, 비밀번호 재설정 링크는 일회성·만료 시간을 가져야 하며, 로그인 실패는 일정 기준에서 지연 또는 제한되어야 합니다. OWASP 인증 가이드는 비밀번호 복구, 안전한 비밀번호 저장, 인증 이벤트 로깅을 별도 검토 항목으로 둡니다. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html))
- 일반 사용자: 이메일 인증, 비밀번호 재설정, 세션 만료, 로그아웃 시 세션 무효화, 보안 쿠키 속성을 확인합니다.
- 관리자: 최소한 강한 비밀번호 정책과 MFA 또는 별도 2차 보호를 둡니다. 관리자 계정 공유는 금지해야 합니다.
- B2B SaaS: 초기에는 이메일·비밀번호로 시작하더라도, 기업 고객이 예상된다면 OIDC 기반 SSO 확장 가능성을 설계에 남겨둡니다. 자체 인증 서버와 외부 IdP 선택은 OAuth2·OIDC 인증 서버 설계 가이드에서 더 깊게 볼 수 있습니다.
검수는 간단합니다. 임의 사용자의 세션 쿠키를 조작했을 때 접근이 차단되는지, 만료된 재설정 링크가 실패하는지, 비밀번호가 DB에 복원 가능한 형태로 저장되지 않는지, 관리자 계정이 일반 로그인 흐름과 같은 보호 수준인지 확인하면 됩니다.
4. 권한: MVP에서 가장 비싼 사고는 ‘남의 데이터가 보이는 것’입니다
API 기반 SaaS에서는 화면 버튼을 숨기는 것만으로 권한을 막을 수 없습니다. 프론트엔드에서 버튼이 보이지 않아도 사용자가 직접 API를 호출할 수 있기 때문입니다. 특히 조직, 프로젝트, 문서, 주문, 고객사처럼 ID가 URL이나 API 파라미터로 노출되는 경우 객체 단위 접근제어가 필요합니다. OWASP API Security Top 10 2023에서도 객체 권한, 속성 권한, 기능 권한 문제가 핵심 위험으로 다뤄집니다. ([owasp.org](https://owasp.org/API-Security/editions/2023/en/0x10-api-security-risks/))
| 권한 검수 질문 | 실패 예시 | 통과 기준 |
|---|---|---|
| 다른 사용자의 ID를 URL에 넣으면? | /api/users/123을 124로 바꿔도 조회됨 | 소유자 또는 허용된 역할이 아니면 403 또는 404 |
| 일반 사용자가 관리자 API를 호출하면? | 화면에는 없지만 API 호출로 삭제 가능 | 서버에서 역할을 재검증하고 거부 |
| 다른 조직의 프로젝트 ID를 넣으면? | A 회사 사용자가 B 회사 데이터 조회 | 모든 쿼리에 tenant_id 또는 조직 범위가 강제됨 |
| 권한 변경 이력이 남는가? | 누가 관리자로 승격했는지 모름 | 권한 부여·변경·회수 로그가 남음 |
초기 MVP에서 권한 모델을 지나치게 복잡하게 만들 필요는 없습니다. 대신 ‘owner, admin, member, viewer’처럼 작게 시작하더라도 서버 코드 안에서 일관된 권한 검사 함수를 사용해야 합니다. 기능별 if문을 흩뿌리면 출시 후 권한 예외가 늘어날수록 추적이 어려워집니다.

5. 미뤄도 되는 보안과 미루면 안 되는 보안
예산이 제한된 MVP에서는 보안을 모두 한 번에 구현하기 어렵습니다. 중요한 것은 미룰 수 있는 항목과 절대 미루면 안 되는 항목을 구분하는 것입니다. MVSP는 기업용 제품과 서비스를 위한 최소 애플리케이션 보안 기준을 제시하며, 조달·계약 단계에서도 보안 기준을 간결하게 확인하는 용도로 활용될 수 있습니다. ([mvsp.dev](https://www.mvsp.dev/mvsp.en/))
| 후속 단계로 미룰 수 있음 | 출시 전에 필요함 |
|---|---|
| 모든 고객 대상 SSO | 관리자 MFA 또는 강한 관리자 보호 |
| SOC 2, ISO 27001 인증 준비 | 개인정보 처리방침, 수집 항목표, 접근권한 관리 |
| 전사 SIEM, 고급 이상탐지 | 로그인 실패, 권한 실패, 관리자 작업 로그 |
| 버그바운티 프로그램 | 취약점 제보 연락처와 내부 조치 담당자 |
| 완전 자동화된 키 회전 | 비밀키의 코드 저장소 커밋 금지와 환경별 분리 |
| 대규모 부하·공격 방어 체계 | 기본 rate limit, 파일 크기 제한, API 에러 노출 제한 |
| 정식 외부 모의해킹 연 1회 | 출시 전 의존성 스캔, 기본 취약점 스캔, 권한 우회 테스트 |
단, 공공기관 납품, 금융·의료·교육·아동 데이터, 민감정보, 고유식별정보, 대규모 B2B 고객 데이터가 포함되면 ‘미룰 수 있음’의 기준이 달라집니다. 이 경우 MVP라 하더라도 법무·보안 전문가 검토와 외부 점검을 예산에 넣어야 합니다.
6. 개인정보: 처리방침보다 먼저 데이터 목록을 만드세요
개인정보 처리방침은 출시 직전에 문구를 붙이는 작업이 아닙니다. 먼저 이름, 이메일, 휴대폰번호, 회사명, 직무, 결제정보, 업로드 파일, 상담 내용, 로그 데이터 중 무엇을 수집하는지 표로 정리해야 합니다. 개인정보 보호법 제30조는 처리 목적, 보유 기간, 제3자 제공, 파기, 위탁, 정보주체 권리, 책임자 연락처 등 처리방침 항목을 규정하고, 개인정보보호위원회는 2026년 4월 개정 작성지침을 공개했습니다. ([law.go.kr](https://law.go.kr/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1020398435))
| 데이터 항목 | 수집 목적 | 저장 위치 | 접근자 | 보유·파기 기준 | 보호 조치 |
|---|---|---|---|---|---|
| 이메일 | 가입, 로그인, 알림 | 회원 DB | 사용자 본인, 관리자 일부 | 탈퇴 후 정책에 따라 삭제 또는 분리 보관 | 접근 제한, 로그, 필요 시 마스킹 |
| 휴대폰번호 | 인증, 상담, 배송 등 | 회원 DB 또는 CRM | 운영 담당자 | 목적 달성 후 파기 | 마스킹, 다운로드 제한 |
| 업로드 파일 | 분석, 협업, 증빙 | 오브젝트 스토리지 | 소유자, 같은 조직 권한자 | 프로젝트 삭제 시 삭제 | 권한 URL, 파일 검증, 접근 로그 |
| 접속 로그 | 보안 점검, 장애 분석 | 로그 저장소 | 운영·보안 담당자 | 내부 정책 및 관련 기준에 따라 보관 | 민감정보 미기록, 접근 제한 |
개인정보를 줄이는 것은 가장 강력한 보안 전략입니다. MVP에서 마케팅 욕심으로 생년월일, 성별, 주소, 직무, 회사 규모를 한 번에 받으면 보안·법무·운영 부담이 늘어납니다. 초기에는 회원 식별과 핵심 기능 수행에 꼭 필요한 항목만 받고, 나머지는 유료 전환·계약 단계에서 다시 동의를 받는 구조가 더 안전합니다.
7. API와 파일 업로드: 화면 검수만으로는 부족합니다
초기 SaaS는 대부분 프론트엔드와 API 서버가 분리되어 있습니다. 따라서 검수도 화면 클릭만 하면 안 됩니다. 직접 API를 호출했을 때 권한이 막히는지, 입력값이 서버에서 검증되는지, 에러 메시지가 내부 경로·SQL·스택트레이스를 노출하지 않는지 확인해야 합니다. OWASP 보안 코드리뷰 체크리스트는 서버 측 입력검증, 파라미터화된 쿼리, 안전한 파일 저장, 세션·권한 검증, 비밀관리, 보안 헤더, 의존성 관리를 검토 항목으로 둡니다. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html))
파일 업로드는 특히 조심해야 합니다. 이미지·PDF 업로드라고 해도 확장자만 믿으면 안 됩니다. 허용 확장자와 MIME 확인, 파일 크기 제한, 파일명 재생성, 실행 권한이 없는 저장소 사용, 다운로드 시 권한 재검증이 필요합니다. OWASP 파일 업로드 가이드는 업로드 기능에 인증·권한 검증과 크기 제한이 필요하다고 설명합니다. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html))
- 프로필 이미지만 필요하다면 이미지 리사이징 후 원본을 폐기합니다.
- 고객 문서를 저장한다면 조직별 접근권한과 다운로드 로그를 남깁니다.
- 압축파일을 허용한다면 압축 해제 후 크기와 경로 조작 위험을 별도로 봅니다.
- AI 분석용 문서 업로드라면 모델 API로 전송되는 데이터와 보관 로그까지 개인정보 처리 범위에 포함해 검토합니다.
8. 로그와 백업: 사고를 막는 기능이 아니라 사고 후 회사를 살리는 기능입니다
초기 팀은 로그를 개발 디버깅용으로만 생각하기 쉽습니다. 하지만 고객 문의, 권한 오남용, 계정 탈취, 개인정보 유출 의심, 정산·검수 대응에는 감사로그가 필요합니다. OWASP 로깅 가이드는 입력값 검증 실패, 인증 성공·실패, 권한 실패, 세션 문제, 관리자 권한 사용, 민감 데이터 접근, 데이터 가져오기·내보내기, 파일 업로드 같은 이벤트를 기록 대상으로 제시합니다. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html))
| 로그 이벤트 | 남길 정보 | 남기면 안 되는 정보 |
|---|---|---|
| 로그인 성공·실패 | 사용자 ID, 시각, IP, user-agent, 결과 | 비밀번호, 인증 토큰 |
| 권한 실패 | 요청 사용자, 리소스 ID, 필요한 권한, 결과 | 민감 원문 데이터 |
| 관리자 작업 | 관리자 ID, 대상 사용자, 작업 유형, 변경 전후 요약 | 주민번호·카드번호 등 원문 |
| 데이터 다운로드 | 다운로드한 관리자, 범위, 건수, 사유 | 다운로드 파일 원문을 로그에 중복 저장 |
| 파일 업로드 | 업로더, 파일 ID, 크기, 검증 결과 | 원본 파일명에 포함된 개인정보 전체 |
백업은 ‘클라우드가 알아서 해주겠지’로 끝내면 안 됩니다. DB 자동 백업이 켜져 있어도 복구 권한, 보관 기간, 암호화, 삭제된 데이터 복구 범위, 복구 리허설 기록이 없으면 실제 장애 때 사용할 수 없습니다. MVP라도 출시 전 한 번은 스테이징 환경에 복구해 보는 것이 좋습니다.

9. 외주 계약·검수 때 바로 물어볼 질문 15개
계약 전에는 개발사에게 ‘보안도 해주시죠?’라고 묻지 말고 아래 질문으로 확인해야 합니다. 답변이 모호하면 견적 범위에 들어 있지 않을 가능성이 높습니다. NIST SSDF도 보안 개발 관행이 공급자와 구매자 간 커뮤니케이션에 활용될 수 있다고 설명합니다. 외주개발에서는 이 관점을 요구사항·산출물·검수표로 번역하는 것이 중요합니다. ([csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/218/final))
- 비밀번호는 어떤 알고리즘으로 저장하며, 평문 복구가 불가능한가?
- 로그인 실패 제한과 비밀번호 재설정 토큰 만료가 있는가?
- 관리자 계정은 MFA 또는 별도 보호가 적용되는가?
- 역할별 권한표를 산출물로 제공하는가?
- 프론트 화면이 아니라 서버에서 모든 권한을 검증하는가?
- 다른 사용자·조직의 ID를 직접 호출하는 테스트를 수행하는가?
- 개인정보 수집 항목, 보유기간, 파기 기준을 표로 제공하는가?
- 관리자 화면에서 개인정보 마스킹과 다운로드 제한이 있는가?
- 파일 업로드 확장자, MIME, 크기, 저장 위치, 다운로드 권한을 검증하는가?
- API rate limit, CORS, 에러 메시지 노출 제한이 적용되는가?
- 운영 DB, 서버, 클라우드 콘솔 접근자는 누구이며 퇴사·계약 종료 시 회수되는가?
- 환경변수, API 키, DB 비밀번호가 코드 저장소에 들어가지 않는가?
- 로그인 실패, 권한 실패, 관리자 작업, 데이터 다운로드 로그가 남는가?
- 백업 주기와 복구 테스트 결과를 문서로 남기는가?
- 출시 전 취약점 스캔과 조치 결과서를 제공하는가?
검수 시연은 개발사가 준비한 정상 시나리오만 보지 말고, 실패 시나리오를 직접 실행해야 합니다. 예를 들어 일반 사용자로 관리자 API 호출, A 조직 계정으로 B 조직 프로젝트 조회, 금지 확장자 파일 업로드, 만료된 재설정 링크 사용, 삭제된 데이터를 백업에서 복구하는 테스트를 요청합니다.
10. AgentMit가 보는 현실적인 MVP 보안 구현 순서
AgentMit는 MVP 보안을 과도한 엔터프라이즈 컨설팅으로 시작하기보다, 출시 가능한 최소 안전 기준을 제품 요구사항 안에 넣는 방식으로 접근합니다. BizMit 기반 SaaS, 관리자 대시보드, 업무 자동화, 정부지원사업 MVP를 만들 때도 먼저 기능 목록을 확정한 뒤 보안을 붙이는 것이 아니라, 로그인·권한·데이터·로그·백업을 초기 설계에 함께 배치합니다.
| 단계 | 해야 할 일 | 대표 산출물 |
|---|---|---|
| 1주차 기획 | 데이터 목록, 사용자 역할, 관리자 기능, 외부 API, 파일 업로드 여부 정의 | 보안 요구사항표, 데이터 처리표, 권한 매트릭스 |
| 설계 | 인증 방식, RBAC, 테넌트 분리, 로그 이벤트, 백업 구조 결정 | 아키텍처 다이어그램, API 권한표, 로그 명세 |
| 개발 | 서버 측 권한 검증, 입력검증, 마스킹, 관리자 감사로그 구현 | 소스코드, 테스트 케이스, 관리자 로그 화면 |
| 출시 전 | 권한 우회 테스트, 취약점 스캔, 백업 복구, 개인정보 처리방침 확인 | 검수 체크리스트, 스캔 결과서, 복구 테스트 기록 |
| 출시 후 | 로그 점검, 계정·권한 회수, 보안 패치, 고객 요구 기반 SSO·감사 기능 확장 | 운영 점검표, 보안 개선 로드맵 |
작은 팀에 필요한 것은 ‘보안 용어가 많은 문서’가 아니라 개발자가 구현하고 대표·PM이 검수할 수 있는 기준입니다. AgentMit가 구현 파트너로 참여하는 경우에도 이 체크리스트를 기준으로 인증·권한 설계, 개인정보 처리 구조, 로그·모니터링, 관리자 화면, 출시 전 검수 산출물을 함께 정리합니다.
마무리: 출시 전 보안 체크리스트를 견적서의 일부로 만드세요
MVP의 목적은 시장검증입니다. 그러나 시장검증을 위해 실제 사용자를 받는 순간, 보안은 선택 옵션이 아닙니다. 특히 정부지원사업이나 외주개발에서는 계약서와 견적서에 보안 요구사항이 빠지면 나중에 ‘추가 요청’이 됩니다. 처음부터 P0 보안 항목을 산출물과 검수 기준으로 넣어야 예산과 일정을 통제할 수 있습니다.
오늘 바로 할 일은 세 가지입니다. 첫째, 우리 MVP가 데모형인지 폐쇄 베타인지 공개 SaaS인지 정합니다. 둘째, 개인정보 수집 항목과 사용자 역할을 표로 만듭니다. 셋째, 이 글의 P0 체크리스트를 견적 요청서와 검수표에 붙입니다. 이 정도만 해도 ‘나중에 보강할 보안’이 아니라 ‘출시 가능한 최소 보안’으로 프로젝트를 시작할 수 있습니다.
FAQ
MVP 단계에서도 보안 진단이나 모의해킹을 꼭 해야 하나요?
모든 MVP가 유료 모의해킹까지 필요한 것은 아닙니다. 다만 실제 회원가입, 개인정보 저장, 파일 업로드, 결제, 관리자 화면, B2B 고객 데이터가 있다면 출시 전 최소 취약점 스캔과 권한 우회 테스트는 필요합니다. 공공·금융·의료·아동·민감정보처럼 리스크가 높은 영역은 외부 보안 점검을 예산에 넣는 편이 안전합니다.
외주 견적서에 보안 항목은 어떻게 적어야 하나요?
로그인, 관리자, DB 구축처럼 기능명만 쓰면 부족합니다. 인증 방식, 비밀번호 저장 방식, 권한 모델, API 접근제어, 개인정보 암호화·마스킹, 파일 업로드 검증, 접속·관리자 로그, 백업·복구, 취약점 점검 결과서까지 산출물과 검수 기준으로 적어야 합니다.
초기 SaaS에서 SSO나 MFA는 필수인가요?
일반 사용자 SSO는 고객 요구가 없으면 후속 단계로 미룰 수 있습니다. 그러나 관리자 계정 MFA, 강한 비밀번호 저장, 로그인 실패 제한, 비밀번호 재설정 토큰 만료, 세션 보호는 MVP에서도 우선순위가 높습니다. B2B 엔터프라이즈 고객을 바로 상대한다면 OIDC 기반 SSO를 로드맵에 포함하는 것이 좋습니다.
개인정보가 거의 없으면 보안 요구사항을 줄여도 되나요?
수집 항목이 이메일 정도라면 암호화 범위나 로그 보관 범위는 작게 설계할 수 있습니다. 하지만 계정 탈취 방지, 권한 검증, HTTPS, 비밀번호 해시, 관리자 로그, 백업, 비밀키 관리 같은 기본 항목은 여전히 필요합니다. 개인정보를 적게 모으는 것은 보안 비용을 줄이는 좋은 방법이지만 보안을 없애는 근거는 아닙니다.
정부지원사업 MVP 검수에서 보안 산출물은 무엇을 준비하면 좋나요?
사업별 지침은 다르지만, 실무적으로는 보안 요구사항표, 개인정보 수집·보유 항목표, 권한 매트릭스, 관리자 접근 로그 화면, 취약점 스캔 결과, 테스트 시나리오, 백업·복구 확인 기록, 개인정보 처리방침 공개 화면을 준비하면 설명력이 좋아집니다.
참고한 기준과 읽는 법
- 국내 개인정보 항목은 개인정보 보호법, 개인정보의 안전성 확보조치 기준, 개인정보 처리방침 작성지침을 우선 참고했습니다. 실제 적용 여부와 세부 의무는 처리 데이터, 업종, 위탁 구조, 사업 조건에 따라 달라질 수 있습니다.
- 기술 보안 항목은 OWASP ASVS, OWASP Top 10, OWASP API Security Top 10, OWASP Cheat Sheet Series를 MVP 검수표 형태로 재구성했습니다.
- 초기 B2B SaaS의 최소 보안 기준은 MVSP와 NIST SSDF의 구매자·공급자 커뮤니케이션 관점을 참고했습니다.

