AI로 만든 앱에 별도의 품질 기준이 필요한가
NIST Secure Software Development Framework 1.1은 특정 언어나 코딩 도구가 아니라 소프트웨어 개발 생명주기 전반에 적용하는 보안 개발 관행을 제시합니다.[1] OWASP ASVS 5.0 역시 애플리케이션을 어떤 도구로 작성했는지가 아니라 인증과 권한, 입력, 데이터 보호, 의존성, 로깅 같은 기술적 통제가 제대로 작동하는지를 검증합니다.[6] 프레임워크가 1.2 초안으로 넘어가고[2] 생성형 AI와 이중용도 파운데이션 모델을 위한 커뮤니티 프로파일이 따로 나와 있어도[3] 검증 관행 자체가 도구별로 갈라지지는 않습니다.
AI 코딩은 이 기준을 대체하지 않습니다. 대신 여섯 질문을 더 일찍 드러냅니다. 작성자가 코드와 설정의 모든 동작을 설명할 수 있는가. 인증과 권한이 화면이 아니라 서버에서도 적용되는가. 어떤 외부 패키지와 API가 추가됐는가. 비밀정보가 브라우저나 저장소, 로그에 노출되지 않는가. 성공 경로뿐 아니라 실패와 재시도, 중복 요청도 설계됐는가. 배포 후 문제를 발견하고 원상태로 복구하는가입니다.
DORA의 2025년 연구는 AI를 조직의 기존 강점과 약점을 함께 증폭하는 요소로 설명합니다.[5] NIST의 2026년 AI 보조 코딩 논의도 비협상적인 제약조건과 도메인 규칙을 명시적으로 제공하는 접근을 제안합니다.[4] AI가 쓰였다는 이유로 검증 원칙이 바뀌는 것이 아니라, 암묵적으로 남겨 둔 요구와 제약을 명시할 필요가 더 커지는 쪽에 가깝습니다.
기능 목록보다 실패 경계를 먼저 그린다
검증 범위를 정하기 전에 각 기능에 일곱 질문을 붙여 봅니다. 답이 사용자·조직·금전·외부 시스템의 경계를 하나라도 넘는다면, 화면에서 정상 작동하는지만 확인해서는 부족합니다.
직접 API를 호출하거나 식별자를 바꿔 보고, 같은 요청을 반복해 보고, 외부 시스템이 늦게 응답하거나 실패하는 상황까지 확인해야 합니다. 바이브코딩 앱의 검증 범위는 코드를 누가 썼는지가 아니라 이 경계를 몇 개 넘는지가 정합니다.
확인할 질문 | 검증이 깊어져야 하는 조건 |
|---|---|
| 누가 이 기능을 실행할 수 있는가 | 익명 사용자, 일반 사용자, 다른 조직 사용자, 관리자 사이의 경계가 있다 |
| 누구의 데이터와 상태를 다루는가 | 개인정보, 다른 사용자의 데이터, 조직별 데이터, 중요 업무 기록을 읽거나 바꾼다 |
| 외부 효과가 발생하는가 | 결제, 환불, 메시지 발송, 외부 API 갱신, 파일 삭제처럼 앱 밖에 결과가 남는다 |
| 실패를 되돌릴 수 있는가 | 삭제·이체·발송·권한 변경처럼 자동 취소가 어렵거나 원상복구 방법이 불분명하다 |
| 같은 요청이 반복되면 어떻게 되는가 | 새로고침, 재시도, 네트워크 시간 초과, 작업 재실행이 중복 결과를 만든다 |
| 문제를 알아차릴 수 있는가 | 사용자 신고 전에는 실패·오용·누락을 발견할 로그와 알림이 없다 |
| 복구할 수 있는가 | 백업은 있지만 복원 절차가 검증되지 않았거나 변경 전 상태로 돌아갈 방법이 없다 |
정상 흐름 너머의 예외까지 확인 — 구현된 동작에서 요구사항을 복원하고 입력과 권한, 외부 호출의 예외 경로를 실행해 확인합니다.
검증 깊이를 세 단계로 나누는 법
여기서 말하는 세 단계는 앱 전체의 출시 판정이 아닙니다. 각 위험 영역에서 어느 수준까지 증거를 확보해야 하는지를 구분하는 방법입니다.
출시 차단 수준의 영역은 정상 경로만 통과해서는 안 됩니다. 권한 없는 요청, 변조된 값, 중복 요청, 시간 초과, 부분 실패, 복구 경로까지 실제로 실행한 증거가 필요합니다. 후속 개선 가능은 검증하지 않아도 된다는 뜻이 아닙니다. 해당 위험 영역이 기능상 존재하지 않거나, 필수 통제가 이미 검증된 뒤 남은 개선만 뒤로 미룰 수 있다는 뜻입니다.
- 출시 차단 수준으로 검증
- 해당 기능을 외부에 노출하기 전에 반드시 확인해야 하는 범위입니다. 실패하면 계정 탈취와 권한 상승, 타인 데이터 노출·변경, 금전 손실, 비밀정보 유출, 되돌리기 어려운 외부 효과가 발생합니다.
- 조건부로 추가 검증
- 기본 통제는 동작해도 사용 방식이나 규모에 따라 범위를 넓혀야 하는 구간입니다. 다중 조직과 여러 역할, 소셜 로그인, 구독 결제, 대량 작업, 비동기 처리, 외부 사업자 장애가 조건으로 붙습니다.
- 후속 개선 가능
- 최소 안전 기준이 이미 충족됐고 남은 개선이 접근 통제와 데이터 무결성, 금전 효과, 탐지, 복구의 성패를 바꾸지 않는 경우이며, 검증하지 않아도 된다는 뜻은 아닙니다.
열두 위험 영역을 어떻게 가르나
아래 매트릭스는 OWASP ASVS 5.0과 OWASP Top 10:2025, API Security Top 10:2023, 웹 보안 테스트 가이드 4.2의 위험·검증 항목을 출시 전 범위 결정에 맞게 재구성한 것입니다.[6][9][10][8] 세 단계의 명칭과 분류 방식은 OWASP나 NIST의 공식 점수 체계가 아니라 이 글의 의사결정 틀입니다.
위험 영역 | 출시 차단 수준으로 검증 | 조건부로 추가 검증 | 후속 개선 가능 |
|---|---|---|---|
| 인증 | 계정이나 보호 기능이 있다면 가입·로그인·로그아웃·세션 만료와 폐기·계정 복구·인증 우회·사용자 열거 가능성을 확인한다. 인증이 필요한 API를 세션 없이 직접 호출해도 거부돼야 한다. 관리자나 민감 기능에는 위험에 맞는 재인증이 필요하다. | 소셜 로그인·OIDC·SSO, 계정 연결, 여러 기기 세션, 인증수단 변경, 복구 수단 분실, 장시간 세션을 쓰면 관련 실패·탈취 시나리오를 더한다. | 패스키 확대, 세션 관리 화면, 로그인 안내 문구는 기본 인증·복구·세션 통제가 검증된 뒤에 진행한다. |
| 권한 | 여러 사용자·조직·역할·비공개 객체가 있으면 수평·수직 권한 상승을 직접 검증한다. URL이나 객체 ID를 바꾸고 API를 직접 호출해도 다른 사용자·조직 데이터에 닿거나 관리자 기능을 실행하지 못해야 한다. 권한은 서버에서 기본 거부로 적용한다. | 공유 링크, 소유권 이전, 역할 위임, 지원 담당자의 사용자 대행, 대량 조회·수정, 조직 이동이 있으면 상태 전환 전후의 권한을 더 확인한다. | 역할 관리 화면의 편의성이나 권한 설명 개선은 서버 권한 모델과 감사 기록이 검증된 이후로 미룬다. |
| 데이터 읽기·변경·삭제 | 개인정보·조직 데이터·업무 기록을 다루거나 데이터를 바꾸고 지운다면 소유권, 조직 격리, 입력 검증, 동시 수정, 부분 실패, 트랜잭션 처리, 삭제 범위와 복원 가능성을 확인한다. 읽기·쓰기·삭제 권한은 각각 따로 검증한다. | 가져오기·내보내기, 대량 수정, 보존 기간, 데이터 이전, 검색 색인·캐시와 원본의 정합성, 여러 시스템 간 동기화가 있으면 예외와 재처리 범위를 넓힌다. | 임시 저장 이력, 변경 비교 화면, 편리한 복원 화면은 데이터 무결성과 실제 복구 경로가 확보된 뒤에 개선한다. |
| 결제·금전 효과 | 결제, 환불, 포인트·크레딧, 유료 권한 부여가 하나라도 있으면 금액·통화·주문 소유자 검증, 클라이언트 값 변조, 중복 제출, 재시도와 시간 초과, 멱등성, 웹훅 위변조·재전송, 환불·보상, 거래 대사를 검증한다. 결제 성공 화면만으로는 부족하다. | 구독 갱신, 부분 환불, 쿠폰, 세금, 일할 계산, 결제수단 변경, 미수금, 취소 분쟁이 있으면 상태 조합과 회계·권한 정합성을 더 검증한다. | 영수증 화면, 결제 분석 대시보드, 안내 문구는 거래 무결성과 중복 방지, 대사 구조가 검증된 뒤에 개선한다. |
| 외부 API | 외부 API가 인증·결제·핵심 데이터·메시지 발송·외부 상태 변경에 관여하면 인증정보 범위, 요청·응답 검증, 시간 초과, 재시도, 중복 처리, 웹훅 검증, 실패 시 내부 상태, 비정상 응답과 부분 성공을 확인한다. 외부 응답을 믿고 내부 권한이나 금액을 정하지 않는다. | 사업자 장애, 요청 제한, API 버전 변경, 샌드박스와 운영 설정 분리, 장애 시 대체 경로와 기능 축소가 필요하면 추가 검증한다. | 부가 정보 조회처럼 실패해도 핵심 상태가 바뀌지 않는 연동은 격리된 실패 처리가 검증된 뒤 사용자 안내나 대체 화면을 개선한다. |
| 비밀정보·자격증명 | 운영 API 키, DB 자격증명, 서명키, 관리자 토큰이 있다면 소스코드·저장소 이력·브라우저 번들·오류 응답·로그에 노출되지 않는지 확인한다. 개발·검증·운영 환경을 분리하고 최소 권한과 폐기·교체 경로를 검증한다. | 단기 자격증명, 자동 교체, 비밀정보 인벤토리, 긴급 접근, 여러 테넌트·서비스별 키 분리가 필요하면 수명주기 검증을 넓힌다. | 만료 알림, 교체 자동화, 관리 메타데이터 개선은 안전한 주입·분리·폐기 기준이 검증된 뒤에 진행한다. |
| 의존성 | 인증·암호화·결제·파일 처리 같은 핵심 경로의 패키지 출처가 불분명하거나, 실제 호출 가능한 경로에 알려진 중대한 취약점이 있거나, 설치 스크립트가 과도한 동작을 하면 해결 전까지 깊게 검증한다. 빌드 재현성과 잠금 파일·산출물의 일치 여부도 확인한다. | 간접 의존성 인벤토리, SBOM, 사설 레지스트리, 업데이트 정책, 라이선스, 유지보수 중단, 패키지 이름 혼동과 공급망 변경을 더 확인한다. | 취약점 현황 대시보드나 업데이트 자동화는 알려진 중대한 문제와 핵심 의존성 출처를 처리한 뒤에 개선한다. |
| 사용자 입력 | 입력이 DB·HTML·파일·명령·외부 URL·다른 사용자 화면·외부 도구로 전달되면 서버 측 검증, 출력 맥락별 인코딩, 쿼리 파라미터화, 업로드 제한, SSRF, 입력 크기와 자원 제한, 비정상 업무 흐름을 확인한다. 브라우저의 입력 제한만 믿지 않는다. | 리치 텍스트, 파일 압축·변환, URL 가져오기, 다국어·유니코드, 대량 입력, 사용자 간 콘텐츠 공유, 자동화된 반복 요청이 있으면 검증을 넓힌다. | 도움말, 클라이언트 측 즉시 검증, 입력 편의 기능은 서버 검증과 안전한 처리 기준이 확보된 뒤에 개선한다. |
| 관리자 기능 | 관리자 화면이나 운영 API가 있으면 일반 사용자와 분리된 서버 권한, 민감 작업 재인증, 역할 변경·대량 수정·삭제의 감사 기록, 세션·CSRF 방어, 긴급 계정과 복구 절차를 확인한다. 숨겨진 URL은 접근 통제가 아니다. | 역할 위임, 고객지원 대행, 사용자 가장, 대량 내보내기, 일괄 권한 변경, 승인 흐름이 있으면 행위 주체와 승인·취소·감사 범위를 더 검증한다. | 관리자 검색·필터·리포트 편의성은 접근 통제와 감사 가능성이 검증된 뒤에 개선한다. |
| 백그라운드 작업 | 작업이 데이터 변경·삭제, 결제, 권한 부여, 메시지 발송, 외부 동기화를 수행하면 중복 실행 방지, 멱등성, 재시도와 지연 간격, 부분 실패, 동시 실행, 실패 작업 격리·재처리, 실행 권한과 결과 추적을 확인한다. | 예약 시간대, 지연 실행, 순서 뒤바뀜, 과거 데이터 채우기, 대량 재처리, 외부 할당량, 워커 재시작 후 복구가 있으면 관련 시나리오를 더한다. | 작업 현황 화면과 운영 자동화는 실패 감지와 안전한 재처리 경로가 확보된 뒤에 개선한다. |
| 로그·모니터링 | 인증 실패, 권한 거부, 관리자 작업, 결제·환불, 데이터 삭제, 중요 백그라운드 작업 결과는 추적할 수 있어야 한다. 요청과 작업을 잇는 식별자, 필요한 경보, 로그 보호가 있어야 하며 비밀번호·토큰·민감한 개인정보는 기록하지 않는다. | 보존 기간, 이상 탐지, 담당자 호출, 조직별 감사, 외부 서비스 상태와의 상관관계, 대규모 로그 비용을 더 설계한다. | 더 풍부한 대시보드와 분석 지표는 최소 탐지·감사·알림 기준이 동작한 뒤에 개선한다. |
| 롤백·복구 | 파괴적 데이터 변경, 호환되지 않는 DB 마이그레이션, 중요 설정·자격증명 변경이 있다면 이전 산출물과 설정 복원, 백업 복구, 데이터 정합성 확인, 전진 복구, 외부 효과의 보상 절차를 실제로 확인한다. 백업이 있다는 사실만으로는 부족하다. | 기능 플래그, 카나리, 부분 롤백, 작업 재생, 외부 사업자 장애 시 기능 축소, 복구 중 사용자 커뮤니케이션이 필요하면 범위를 넓힌다. | 검증된 수동 복구 절차의 자동화나 복구 시간 단축은 현재 경로가 실제로 동작하고 피해를 제한할 때 후속 개선으로 남긴다. |
매트릭스를 실제 검증 범위로 바꾸는 순서
첫째, 기능이 아니라 행위와 자산을 적습니다. 회원 기능, 결제 기능처럼 화면 이름만 적지 않고 행위자와 읽는 데이터, 바꾸는 상태, 외부 효과, 실패 시 영향으로 분해합니다. 이렇게 적어야 인증과 권한, 데이터, 금전, 외부 API, 백그라운드 작업이 한 기능 안에서 어떻게 이어지는지 보입니다.
둘째, 적용되지 않는 영역은 N/A로 명시합니다. 모든 앱에 열두 영역이 똑같이 있지는 않습니다. 로그인도 데이터 저장도 없는 정적 소개 페이지라면 인증과 권한, 결제는 N/A입니다. 그러나 문의 폼이 있다면 사용자 입력과 외부 메일 API, 비밀정보, 남용 방지는 여전히 적용됩니다. 반대로 베타 서비스라고 이름 붙였더라도 실제 사용자 계정과 개인정보, 결제가 있다면 관련 영역을 N/A로 처리하지 못합니다.
셋째, 각 영역에서 가장 깊은 적용 조건을 따릅니다. 평균 점수를 계산하지 않습니다. 결제가 안전해도 관리자 권한이 무너져 있으면 그 위험은 상쇄되지 않습니다. 일반 사용자의 프로필 수정은 단순한 데이터 변경처럼 보입니다. 그런데 요청의 사용자 ID를 바꿔 다른 사람의 프로필까지 수정된다면 권한과 데이터 격리를 함께 깊게 검증해야 합니다.
넷째, 정상·오용·실패·복구 증거를 각각 만듭니다. 정상 입력과 정상 권한에서 의도한 결과가 나오는가, 권한 없는 사용자와 변조된 요청이 거부되는가, 시간 초과와 중복 요청, 외부 장애, 부분 실패가 안전하게 처리되는가, 문제가 생긴 뒤 탐지하고 재처리하거나 복구하는가입니다. 자동화 스캐너는 넓은 범위의 후보 문제를 찾는 데 유용하지만 주문 소유자 검증이나 중복 환불, 조직 간 데이터 격리, 백그라운드 작업의 부분 실패처럼 업무 의미를 단독으로 증명하지는 못합니다. ASVS는 검증할 요구사항을 정하는 기준으로, 웹 보안 테스트 가이드는 실제 공격·오용 시나리오를 설계하는 기준으로 쓰는 편이 적절합니다.[7][8]
기능 | 행위자 | 읽는 데이터 | 바꾸는 상태 | 외부 효과 | 실패 시 영향 |
|---|---|---|---|---|---|
| 주문 결제 | 로그인 사용자 | 상품·주문·결제 상태 | 주문 상태·유료 권한 | 결제 승인·웹훅 | 중복 과금, 권한 미부여, 타인 주문 접근 |
| 관리자 환불 | 관리자 | 고객·주문·결제 정보 | 환불·주문 상태 | PG 환불 요청 | 무권한 환불, 중복 환불, 내부 상태 불일치 |
| 예약 알림 작업 | 백그라운드 워커 | 예약·연락처 | 발송 상태 | 메시지 발송 | 중복 발송, 누락, 개인정보 로그 노출 |
출시 판단까지 이어지는 검증 — 핵심 흐름을 검증하고 실행 결과와 남은 조건을 출시 판단의 근거로 연결합니다.
검증할 수 없다면 기능의 영향부터 줄인다
소규모 팀은 모든 기능을 처음부터 가장 깊게 검증하기 어렵습니다. 이때 안전한 방법은 고위험 기능을 그대로 공개한 채 테스트를 줄이는 것이 아니라, 그 기능이 만들 수 있는 영향을 실제로 제한하는 것입니다.
실제 결제 대신 샌드박스나 수동 입금 확인만 씁니다. 데이터 변경 기능을 읽기 전용으로 묶고 실제 개인정보 대신 가상 데이터로 운영합니다. 공개 가입 대신 서버에서 강제되는 초대 목록을 쓰고 외부 발송과 삭제 작업에 관리자 수동 승인을 둡니다. 대량 작업과 자동 재시도를 끄고 위험한 관리자 기능은 첫 버전에서 뺍니다.
이 제한은 화면 문구가 아니라 서버와 운영 설정으로 강제돼야 합니다. 아직 베타이니 사용자가 조심하라는 안내는 접근 통제나 데이터 보호를 대신하지 못합니다.
자주 생기는 범위 결정 오류
첫째는 화면 수를 테스트 범위로 쓰는 것입니다. 화면이 하나뿐이어도 그 화면이 관리자 권한으로 데이터를 지우거나 결제를 실행한다면 깊은 검증이 필요합니다. 반대로 정보만 읽는 여러 화면은 범위가 좁습니다.
둘째는 로그인을 확인하고 권한까지 확인했다고 생각하는 것입니다. 로그인은 사용자가 누구인지 확인하는 과정입니다. 그 사용자가 특정 주문과 파일, 조직, 관리자 기능을 쓸 수 있는지는 별도의 권한 문제입니다. 특히 API의 객체 ID나 조직 ID를 바꾸는 테스트가 빠지기 쉽습니다.
셋째는 외부 API가 성공하는 경우만 확인하는 것입니다. 외부 API의 진짜 위험은 느린 응답과 중복 콜백, 모호한 성공 상태, 일부 작업만 끝난 경우에 드러납니다. 결제와 발송, 데이터 동기화처럼 외부 효과가 있는 연동은 실패 후 내부 상태까지 확인해야 합니다.
넷째는 AI에게 자기 코드를 다시 검토하게 한 결과를 최종 증거로 쓰는 것입니다. AI의 설명과 검토는 검토 후보를 넓히는 데 쓸 수 있습니다. 그러나 같은 코드와 같은 가정에 기대는 자기 검토는 권한 우회와 실제 운영 설정, 외부 API의 중복 처리, 복구 가능성을 독립적으로 증명하지 못합니다.
검증 범위는 기술 출처가 아니라 실패 결과에서 시작한다
바이브코딩 앱이라는 이유로 모든 기능을 최고 수준으로 검증할 필요는 없습니다. 반대로 빠르게 만들었다는 이유로 인증과 권한, 데이터, 결제, 외부 연동, 복구를 간단한 체크리스트로 끝내서도 안 됩니다.
앱이 경계를 넘을수록 검증은 깊어집니다. 다른 사용자나 조직의 경계를 넘는가, 중요한 데이터를 읽고 바꾸거나 지우는가, 돈이나 되돌리기 어려운 외부 효과를 만드는가, 비밀정보나 관리자 권한을 다루는가, 실패를 발견하고 원상태로 돌아갈 수 있는가입니다.
이 질문에 답하면 검증 범위가 정해집니다. 그 결과로 확보한 증거를 놓고 실제 출시 여부를 판단하는 일은 출시 판정이 맡는 다음 단계입니다.
