2025년 10월 16일·8분
AI로 구축한 앱의 보안: 보증, 격차, 가드레일
AI로 구축된 애플리케이션에서 무엇을 약속할 수 있고 무엇을 약속할 수 없는지, 보안 맹점은 어디에 숨어 있는지, 더 안전하게 배포하기 위한 실용적인 가드레일을 안내합니다.
AI로 구축된 애플리케이션에서 무엇을 약속할 수 있고 무엇을 약속할 수 없는지, 보안 맹점은 어디에 숨어 있는지, 더 안전하게 배포하기 위한 실용적인 가드레일을 안내합니다.
“AI로 구축한 애플리케이션”은 몇 가지 의미를 가질 수 있으며, 이 글에서는 그 용어를 넓게 사용합니다. 포함되는 사례는:
목표는 단순합니다: 완벽한 안전을 주장하지 않으면서 위험을 줄이는 것. AI는 개발과 의사결정을 가속하지만, 실수가 발생하는 방식과 전파 속도를 바꿉니다.
상시 보안 전담 인력이 없거나(또는 보안 지원은 있지만) 실제 릴리스 현실에 맞는 실용적인 지침이 필요한 창업자, 제품 책임자, 엔지니어 팀을 위해 작성했습니다.
현실적으로 어떤 “보안 보증”을 주장할 수 있고 무엇을 주장해서는 안 되는지, AI 지원 개발에 적용할 수 있는 경량 위협 모델, 그리고 LLM이 코드·의존성·도구·데이터에 관여할 때 흔히 생기는 맹점들을 알게 됩니다.
또한 지루하지만 효과적인 가드레일들(아이덴티티·접근 제어, 테넌트 격리, 비밀 처리, 안전한 배포 워크플로우, 모니터링 및 남용 제어)을 살펴봅니다.
이 글은 준수(compliance) 가이드도, 보안 리뷰의 대체물도, 어떤 앱이든 마법처럼 안전하게 만드는 체크리스트도 아닙니다. 보안은 사람(교육과 소유), 프로세스(검토와 릴리스 게이트), 도구(스캐너, 정책, 로그)에 걸친 공유 책임입니다. 목표는 그 공유 책임을 명확하고 관리 가능하게 만드는 것입니다.
AI로 구축한 앱에 대한 보안 “보증”은 종종 명시적이라기보다 암묵적으로 받아들여집니다. 팀은 “모델이 비밀을 노출하지 않는다”거나 “플랫폼이 컴플라이언트하다”는 말을 듣고 이를 전면적 보장으로 오해하곤 합니다. 기대치가 현실에서 멀어지는 지점입니다.
다음과 같은 주장(또는 추정)을 자주 보게 됩니다:
이들 중 일부는 부분적으로 사실일 수 있지만 보편적이긴 드뭅니다.
진짜 보증은 경계가 있습니다: 어떤 기능에, 어떤 설정에서, 어떤 환경에서, 어떤 데이터 경로에, 그리고 얼마나 오랫동안 적용되는지. 예를 들어 “우리는 귀하의 데이터를 학습하지 않는다”는 것과 “우리는 보유하지 않는다”는 것은 다릅니다. 또 둘은 “관리자가 실수로 노출할 수 없다”와도 다릅니다. “기본적으로 안전”은 스타터 템플릿에는 적용될 수 있지만, 여러 번의 반복 후 생성된 모든 코드 경로에 적용되진 않을 수 있습니다.
유용한 사고방식: 보증이 특정 토글을 켜는 것, 특정 방식으로 배포하는 것, 혹은 특정 통합을 피하는 것에 달려 있다면 그것은 전면적 보증이 아니라 조건부 보증입니다.
벤더는 기능을 제공할 수 있지만, 결과는 여전히 귀하의 위협 모델, 구성, 운영 규율에 달려 있습니다.
측정할 수 없다면 그것은 보증이 아닙니다.
검증 가능한 것을 요구하세요: 서면 보관 기간, 문서화된 격리 경계, 감사 로그 범위, 침투 테스트 범위, 그리고 책임 분담(벤더가 무엇을 보호하고 귀사가 무엇을 보호해야 하는지)의 명확한 구분.
Koder.ai 같은 분위기 코딩 플랫폼(에이전트가 배후에서 작동하는 채팅 기반 앱 생성)을 사용한다면 같은 관점으로 보세요: “우리가 생성해준다”는 것을 가속화로 취급하고 안전 주장으로 보지 마세요. 유용한 질문은: 어떤 부분이 표준화되고 반복 가능한가(템플릿, 배포 파이프라인, 롤백)이고 어떤 부분이 여전히 자체 통제가 필요한가(권한 부여, 테넌트 스코핑, 비밀, 검토 게이트)입니다.
40페이지짜리 문서가 없어도 더 나은 결정을 내릴 수 있습니다. 경량 위협 모델은 단순히 다음의 공유 지도입니다: 누가 앱과 상호작용하는가, 무엇을 보호해야 하는가, 그리고 무엇이 잘못될 수 있는가—특히 코드와 워크플로가 부분적으로 AI에 의해 생성될 때.
변경을 만들거나 작업을 트리거할 수 있는 당사자를 나열하세요:
이 질문은 대화의 초점을 맞춰줍니다: “어떤 행위자가 어떤 권한으로 무엇을 할 수 있는가?”
노출되거나 변조되거나 사용 불가가 되면 피해가 큰 소수의 항목을 고르세요:
입력이 경계를 넘는 장소를 나열하세요:
새 기능마다 이 빠른 점검을 사용하세요:
이는 전체 보안 검토를 대체하지는 않지만 변경 비용이 낮을 때 가장 위험한 가정을 드러내 줍니다.
AI는 작동하는 코드를 빠르게 초안화할 수 있지만 “작동한다”가 곧 “안전하다”는 뜻은 아닙니다. AI로 만든 앱에서 많은 보안 실패는 특이한 해킹이 아니라 평범한 버그와 불안전한 기본값입니다. 모델은 그럴듯함과 속도를 최적화할 뿐 조직의 보안 기준을 따르지는 않습니다.
인증과 권한부여가 흔한 실패 지점입니다. 생성된 코드는 다음과 같은 문제를 낳을 수 있습니다:
isAdmin: true 같은 클라이언트 제공 필드를 신뢰하고 서버 측 검사를 하지 않는 경우.입력 검증도 자주 문제입니다. 코드가 정상 경로를 검증하지만 엣지 케이스(배열 vs 문자열, 유니코드 트릭, 매우 큰 입력)를 놓치거나 문자열을 SQL/NoSQL 쿼리에 이어붙이는 경우가 있습니다. ORM을 쓰더라도 동적 필터를 조합하면서 안전하지 않은 쿼리가 만들어질 수 있습니다.
암호화 오용은 다음 형태로 나타납니다:
모델은 공개 예제를 닮은 패턴을 재현하는 경향이 있습니다. 그 결과 얻는 코드는:
안전한 템플릿부터 시작하세요: 인증, 로깅, 에러 처리, 안전한 기본값이 미리 적용된 승인된 프로젝트 골격을 마련합니다. 그런 다음 인증 흐름, 권한 검사, 데이터 접근 계층, 비밀을 다루는 모든 보안 관련 변경에 대해 사람의 검토를 요구하세요.
사람에만 의존하지 않는 자동화된 검사를 추가하세요:
Koder.ai로 앱(React 프런트엔드, Go 백엔드, PostgreSQL)을 생성한다면 템플릿을 계약으로 취급하세요: 일단 deny-by-default 권한, 테넌트 스코핑, 안전한 헤더, 구조화된 로깅을 템플릿에 넣고 AI가 그 경계 안에서 작업하게 하세요. 또한 플랫폼 기능(스냅샷, 롤백)이 운영 위험을 줄여주지만 롤백을 예방과 혼동하지 마세요.
보안 회귀는 종종 ‘작은 리팩터’로 옵니다. 몇 가지 높은 효과의 테스트를 두세요:
AI가 기능을 빠르게 만들어줄 수 있지만, 당신이 배포하는 ‘앱’은 대개 타인의 코드 스택입니다: 오픈소스 패키지, 컨테이너 베이스 이미지, 호스티드 DB, 인증 제공자, 분석 스크립트, CI/CD 액션. 속도에는 장점이 있지만 의존성이 약한 고리가 되면 취약점이 됩니다.
일반적 AI 생성 앱은 소량의 커스텀 코드와 수백(또는 수천)의 전이적 의존성을 가집니다. 여기에 OS 패키지가 포함된 도커 이미지와 설정이 보안인 관리형 서비스가 더해지면 당신은 여러 릴리스 주기와 당신이 통제하지 못하는 보안 관행에 의존하게 됩니다.
간단하고 강제 가능한 통제부터 시작하세요:
명확한 패치 주기를 정하세요(예: 의존성 주간 업데이트, 중요한 CVE는 즉시 대응). 취약점이 프로덕션에 영향을 주면 신속히 업그레이드할 브레이크 글래스 경로(사전 승인 단계, 롤백 계획, 온콜 담당자)를 정의하세요.
마지막으로 명확한 소유권을 지정하세요: 각 서비스는 의존성 업그레이드, 베이스 이미지 갱신, SBOM 및 스캔 상태 유지 책임을 지는 명명된 담당자가 필요합니다.
프롬프트 인젝션은 공격자가 앱이 모델에 제공하는 컨텐츠(채팅 메시지, 지원 티켓, 웹페이지, PDF 등)에 지시문을 숨겨 모델의 의도를 덮어쓰려는 행위입니다. “되돌아 말하는 신뢰할 수 없는 텍스트”로 생각하면 됩니다. 전통적 입력 공격과 다른 점은 모델이 공격자의 지시에 따라 행동할 수 있다는 것입니다—특히 모델이 도구(검색, DB 쿼리, 이메일 전송, 코드 실행 등)를 사용할 수 있을 때 위험합니다.
전통적 입력 공격은 파싱을 깨뜨리거나 알려진 인터프리터(SQL, 셸)를 악용하려 합니다. 프롬프트 인젝션은 의사결정자(모델)를 노립니다. 앱이 모델에 도구를 제공하면 공격자는 모델을 유도해 그 도구를 위험하게 사용하게 하려 합니다.
모델에 전달하는 모든 입력(가져온 문서, 스크랩한 웹페이지, 붙여넣은 메시지 포함)을 신뢰 불가로 처리하세요.
lookup_order(order_id) 같은 고정된 연산을 선호.프롬프트 인젝션이 “LLM 사용 금지”를 의미하진 않습니다. 모델이 사회공학에 속을 수 있음을 전제로 설계하라는 뜻입니다.
AI로 구축한 앱은 텍스트를 여기저기 옮기며 작동하는 경우가 많습니다: 사용자 입력이 프롬프트가 되고, 프롬프트가 도구 호출이 되고, 결과가 응답이 되며 많은 시스템이 각 단계를 조용히 저장합니다. 이는 디버깅에 편리하지만 민감 데이터가 의도보다 넓게 퍼지는 일반적 경로이기도 합니다.
명백한 곳은 프롬프트 자체입니다: 사용자가 송장, 비밀번호, 의료 정보, 내부 문서를 붙여넣습니다. 그러나 덜 명백한 누수는 더 심각합니다:
프라이버시 위험은 “저장되었나?”뿐 아니라 “누가 볼 수 있나?”입니다. 명확히 하세요:
시스템별 보존 기간을 문서화하고 “삭제된” 데이터가 캐시, 벡터 인덱스, 백업 등을 포함해 실질적으로 제거되는지 확인하세요.
수집을 줄이고 누가 읽을 수 있는지 좁히는 데 집중하세요:
반복 가능한 경량 점검을 만드세요:
AI로 만든 프로토타입은 ‘작동’하는 시점이 안전해지기 전인 경우가 많습니다. LLM이 UI, CRUD 엔드포인트, DB 테이블을 빠르게 생성할 때 인증 관련 가정은 초기에 라우트, 쿼리, 데이터 모델에 새겨집니다. 나중에 인증을 덧붙이면 끼워넣기 식 수정이 되어 지저분해집니다.
인증은 ‘이 사용자는 누구인가?’(로그인, 토큰, SSO)에 답합니다. 권한은 ‘이들이 무엇을 할 수 있는가?’(권한, 역할, 소유권 검사)에 답합니다. AI로 생성된 앱은 인증(로그인)을 구현하지만 모든 엔드포인트에 일관된 권한 검사를 놓치는 경우가 많습니다.
최소 권한(least privilege)에서 시작하세요: 새 사용자와 API 키는 가장 작은 권한 집합으로 기본 설정하세요. 명시적 역할(e.g., viewer, editor, admin)을 만들고, 권한 있는 행동은 단순히 “로그인” 상태가 아니라 admin 역할을 요구하게 하세요.
세션 관리에 대해선 단명 액세스 토큰을 선호하고 리프레시 토큰을 회전하며 비밀번호 변경이나 의심스러운 활동 시 세션을 무효화하세요. 긴 수명 비밀을 로컬 스토리지에 두지 마세요; 토큰을 현금처럼 다루세요.
멀티테넌트(여러 조직, 팀, 워크스페이스) 앱이라면 격리는 서버 측에서 강제해야 합니다. 안전한 기본값은: 모든 쿼리는 tenant_id로 스코프되고, tenant_id는 클라이언트가 변경할 수 있는 요청 파라미터에서 가져오지 않습니다.
권장 가드레일:
배포 전 각 새 라우트에 대해 다음을 점검하세요:
/resource/123에 접근할 수 있는가?tenant_id를 신뢰하는가?이 중 하나만 고친다면: 모든 엔드포인트가 인증된 식별자에서 유래한 테넌트 스코핑과 함께 일관되게 권한을 시행하도록 하세요.
AI는 빌드를 가속하지만 미완성 변경 배포, 키 유출, 자동화에 과도한 권한 부여 같은 흔한 ‘이런 실수’로부터는 보호하지 않습니다. 몇 가지 기본 가드레일이 대부분의 피할 수 있는 사고를 막아줍니다.
개발, 스테이징, 프로덕션을 다른 URL 정도로 여기지 말고 별개의 세계로 취급하세요.
개발은 실험, 스테이징은 프로덕션과 유사한 설정·데이터 형태로 테스트(실제 고객 데이터 아님), 프로덕션은 실사용자 대상입니다.
이 분리는 다음과 같은 사고를 방지합니다:
개발이 프로덕션을 가리키기 어렵게 만드세요: 각 환경에 다른 계정/프로젝트, 다른 DB, 다른 자격증명 사용.
신뢰할 수 있는 규칙: 공개 이슈에 붙여넣지 않을 것을 프롬프트에도 붙여넣지 마세요.
비밀을 저장하지 마세요:
대신 시크릿 매니저(클라우드 시크릿 스토어, Vault 등)를 사용하고 런타임에 주입하세요. 장수 API 키 대신 단명 토큰을 선호하고, 주기적으로 교체하며 노출 의심 시 즉시 회수하세요. 누가/무엇이 언제 비밀에 접근했는지 감사 추적을 남기세요.
적절한 곳에 마찰을 추가하세요:
Koder.ai 같은 플랫폼에서 빠르게 반복한다면 소스 코드 내보내기를 보안 이야기의 일부로 다루세요: 자체 스캐너를 실행하고 자체 CI 정책을 적용하며 배포 전에 독립 검토를 수행할 수 있어야 합니다. 또한 계획 모드 같은 기능은 에이전트가 코드 변경이나 통합 연결을 시작하기 전에 명시적 설계와 권한 경계를 강제하여 도움이 됩니다.
하나의 사고방식만 채택한다면: 실수는 발생할 것이라 가정하고, 환경·비밀·배포 흐름을 설계해 실수가 무해한 실패가 되도록 하세요.
“테스트에서는 잘 작동했다”는 AI로 구축한 앱에 대해 약한 보안 논리입니다. 테스트는 보통 예상된 프롬프트와 정상 동작에 대한 검증만 합니다. 실제 사용자는 엣지 케이스를 시도하고 공격자는 경계를 탐색하며 모델 동작은 새 프롬프트·컨텍스트·의존성 변화로 달라질 수 있습니다. 런타임 가시성이 없으면 앱이 조용히 데이터를 누출하거나 잘못된 도구를 호출하거나 부하에서 실패 열림(fail open) 상태가 되는지 알 수 없습니다.
초기에 엔터프라이즈 SIEM이 필요하진 않지만 다음 질문에 일관되게 답할 수 있는 추적이 필요합니다: 누가, 어떤 데이터를 사용해, 어떤 도구로, 어떤 결과를 냈는가?
필수 로그와 지표:
민감 필드는 기본적으로 로그에서 제외하세요(비밀, PII가 포함된 원시 프롬프트). 디버깅을 위해 프롬프트를 로그해야 한다면 샘플링하고 강하게 마스킹하세요.
경량 탐지를 먼저 도입하세요:
남용은 정상 트래픽처럼 보이다가 갑자기 달라집니다. 실용적 통제:
이번 주 하나만 구현한다면: 인증 + 도구 호출 + 데이터 접근의 검색 가능한 감사 기록과 비정상적 스파이크에 대한 알림을 만드세요.
"출시할 만큼 안전"은 "취약점이 전혀 없다"를 의미하지 않습니다. 팀과 고객이 받아들일 수 있는 수준으로 가장 가능성 높고 영향력 큰 위험을 줄였고, 문제가 생기면 감지하고 대응할 수 있어야 합니다.
앱에 대해 현실적인 실패 모드를 짧게 정리하세요(계정 탈취, 데이터 노출, 위험한 도구 행동, 예기치 않은 비용). 각각에 대해: (1) 출시 전에 어떤 예방책이 필요한가, (2) 어떤 탐지가 필수인가, (3) 복구 목표는 무엇인가(얼마나 빨리 피해를 멈출 수 있나)를 정하세요.
상위 위험과 완화책을 평범한 언어로 설명할 수 없다면 출시 준비가 되지 않은 것입니다.
작고 실제로 끝낼 수 있는 체크리스트를 사용하세요:
기본을 문서화하고 연습하세요:
스냅샷과 롤백을 지원하는 플랫폼(Koder.ai 포함)은 사고 대응을 빠르게 만들 수 있지만, 무슨 일이 롤백을 촉발하는지, 누가 실행하는지, 롤백이 실제로 위험 행동을 제거했는지 검증하는 절차가 있어야 합니다.
정기 작업을 예약하세요: 의존성 업데이트 월간, 접근권 검토 분기별, 도구·데이터소스·테넌트 추가 시 위협 모델 갱신. 사고나 근접 사고 후에는 블레임 없는 리뷰를 하고 교훈을 구체적 백로그 항목으로 바꾸세요—모호한 알림이 아니라 실행 가능한 작업으로.
어떤 “보증”도 범위가 있다고 보세요. 물어보세요:
이를 측정할 수 없다면(로그, 정책, 문서화된 경계) 보증이라고 주장하기 어렵습니다.
보안 기능(SSO, 암호화, 감사 로그, 비밀 스캐닝)은 능력입니다. 결과는 실제로 약속할 수 있는 것(테넌트 간 접근 없음, 비밀 노출 없음, 무단 내보내기 없음)입니다.
결과를 얻으려면 기능이 다음을 충족해야 합니다:
간단한 절차로 충분합니다:
이 정도면 변경 비용이 낮을 때 가장 위험한 가정을 드러내기에 충분합니다.
일반적인 실패는 특이한 것이 아니라 평범한 실수입니다:
isAdmin)를 신뢰하는 코드.완화책: 안전한 템플릿, 보안에 민감한 변경사항에 대한 필수 인간 검토, 자동화된 검사(SAST/DAST + 권한 관련 테스트).
강제 적용 가능한 통제부터 시작하세요:
운영 습관: 패치 주기(예: 주간, 중요 CVE는 즉시)와 서비스별 책임자 지정.
프롬프트 인젝션은 모델을 조종하려는 악의적 내용입니다. 모델이 도구(DB, 이메일, 환불, 배포 등)를 쓸 수 있다면 위험은 훨씬 커집니다.
실용적 방어책:
lookup_order(id)).보호해야 할 것은 ‘저장되었는가’ 뿐만 아니라 ‘누가 접근할 수 있는가’입니다. 일반적 누수 지점:
노출 감소: 데이터 최소화, 로깅 전 과감한 마스킹/편집, 엄격한 접근 제어, 시스템별 보존 정책 문서화(백업 포함 가능하면 삭제 준비 테스트).
서버 측에서 격리를 강제하세요:
tenant_id로 스코핑되어야 합니다.tenant_id는 요청 본문에서 가져오는 것이 아니라 인증된 세션에서 유래해야 합니다.IDOR 테스트: 사용자가 다른 테넌트의 /resource/{id}에 접근할 수 없는지 확인하세요(유효한 ID를 추측하더라도).
세 가지 규칙을 따르세요:
운영적으로는 접근 기록(감사 기록)을 추적하고, 주기적으로 교체하며, 노출이 의심되면 즉시 회수/교체하세요.
배포 전 최소한의 신호:
“누가 어떤 도구로 어떤 데이터를 처리했는가”에 빠르게 답할 수 없다면 사고 대응은 느리고 추측성으로 흐릅니다.