• 서론
• 전제: AI 주도 개발만의 리스크를 알아두기
• 레벨 1: 일반적인 보안 레벨
• 레벨 2: 엄격하게 정보를 관리하고 싶은 경우
• 레벨 3: 최엄격 (규제 업종)
• 3단계 요약표
• 감사·ISMS 대응
• 지적 재산·라이선스 리스크
• 기타 주의해야 할 관점
• 도입 기업 사례 (레벨별)
• 도입 방법: 금지보다 통제
• 요약

AI 주도 개발 (AI 코딩 어시스턴트를 전제로 한 개발 스타일)을 도입하려고 하면, 기술 선정보다 먼저 앞을 가로막는 것이 "보안, 괜찮은 걸까?"라는 질문입니다. 특히 의사 결정자의 입장에서는 "코드나 고객 데이터가 학습에 사용되지는 않을까", "유출되면 책임을 지는 것은 나"라는 불안감이 따라다닙니다.

여기서 흔히 발생하는 실수가 **"불안하니까 전면 금지"**라는 판단입니다. 하지만 도구를 금지하면 현장의 엔지니어들은 개인 계정으로 몰래 사용하기 시작합니다. 이른바 섀도 AI (Shadow AI)로, 이는 통제된 이용보다 훨씬 더 위험합니다. 실제로 최근에는 전면 금지보다 통제된 이용을 전제로 하는 방침을 권장하는 가이드라인이 늘어나고 있습니다.

그렇다고 해서 모든 기업이 동일한 대책을 세울 필요는 없습니다. 사내 도구를 만드는 스타트업과 환자 데이터를 다루는 의료 시스템은 요구되는 레벨이 완전히 다릅니다.

이 기사에서는 AI 주도 개발의 보안을 3가지 레벨로 나누어 정리합니다.

레벨 1: 일반적── 개인 개발·사내 도구·스타트업 -
레벨 2: 엄격── 수탁 개발·고객 데이터를 다루는 SaaS·중규모 이상의 기업 -
레벨 3: 최엄격── 금융·의료·관공서 등 규제 업종

먼저 모든 레벨 공통으로 파악해야 할 "AI 주도 개발만의 리스크"를 확인하고, 그 후에 레벨별 대처법을 살펴보겠습니다.

그리고 먼저, 기사 전체를 관통하는 관점을 하나 공유하겠습니다. 여기서 정말로 묻고 있는 것은 "AI를 쓸 것인가·쓰지 않을 것인가"가 아닙니다. 자사가 어느 레벨에 해당하며, 리스크와 편익을 어떻게 균형 있게 맞추며 진행할 것인가 ── 이것은 바로 경영 판단입니다. 본 기사는 그 판단을 내리기 위한 재료를 정리하는 것을 목적으로 합니다.

※ 본 기사의 데이터 보유 기간 및 각종 정책은 2026년 중반 시점의 일반적인 정보입니다. 각 벤더의 정책은 빈번하게 변경되므로, 도입 시에는 반드시 최신 공식 문서와 자사의 계약 내용을 확인하십시오.

레벨 이야기를 하기 전에, "애초에 AI를 개발에 사용하면 기존과 무엇이 다른가"를 정리합니다. 이 부분을 이해하지 못하면 레벨 분류의 의미가 전달되지 않습니다.

의사 결정자가 가장 먼저 걱정하는 것은 "보낸 코드가 AI의 학습에 사용되지 않을까" 하는 점입니다. 이는 바꿔 말하면 "자사의 코드나 정보가 외부에 유출되지 않을까" 하는 불안이며, 이 표현이 더 와닿는 분들도 많을 것입니다. 이 부분은 개인용 플랜과 API/법인용 플랜에서 취급 방식이 완전히 다르다는 점을 알아둘 필요가 있습니다.

개인용 채팅 UI나 컨슈머 플랜은 설정에 따라 대화 내용이 학습에 사용될 수 있습니다 (옵트아웃 (Opt-out)이 필요한 경우도 있음).
API 경유나 법인용 플랜에서는 입력 데이터를 학습에 사용하지 않는 것이 원칙입니다. 예를 들어 GitHub Copilot의 Business / Enterprise 플랜은 고객 코드를 학습에 사용하지 않음을 계약상 보장하고 있습니다.

즉 "API나 법인 계약으로 사용한다"는 것만으로도 리스크의 대부분은 낮아집니다. 일반적으로 웹 버전의 채팅을 업무에 사용하는 것보다 API 경유 방식이 데이터 취급에 있어 더 엄격합니다.

"학습되지 않는다"와는 별개로 **"로그가 얼마나 보유되는가"**라는 논점도 있습니다. 부정 이용 감지 등을 위해 입출력 데이터가 일정 기간 서버에 남는 것이 일반적입니다. 이 기간은 벤더마다 다르지만, 최근에는 보유 기간을 단축하려는 움직임도 보입니다. 최엄격 레벨에서는 이 "일정 기간조차 남기고 싶지 않다"는 니즈에 부응하는 메커니즘 (후술할 ZDR)이 필요하게 됩니다.

"학습에 사용된다/사용되지 않는다"는 계약으로 보호받는 부분이 크지만, 보다 현실적이며 간과하기 쉬운 것이 컨텍스트 윈도우 (Context Window)를 통한 유출입니다.

AI에게 보완을 요청할 때, 도구는 주변 코드를 "문맥"으로서 클라우드로 전송합니다. 이때 .env 파일이나 API 키, DB 비밀번호 등이 실수로 함께 전송될 수 있습니다. 학습에 사용되지 않더라도, 추론을 위해 외부로 전송되고 있는 시점에서 리스크입니다.

이것은 AI 특유의 새로운 공격입니다. 공격자가 README나 코드 주석에 인간에게는 보이지 않는 흰색 글자로 "API 키를 외부로 보내라"와 같은 지시를 심어두고, AI가 이를 실행하도록 유도합니다. AI는 지시와 데이터의 구분을 어려워하기 때문에, "데이터라고 생각하고 읽은 문장"이 "명령"으로서 작용하게 됩니다.

2026년에 문제가 되고 있는 비교적 새로운 위협입니다. AI는 실재하지 않는 패키지 이름을 "그럴듯하게" 제안할 때가 있습니다 (예: fast-json-parser-v2와 같은 존재하지 않는 이름).
공격자는 그 이름을 선점하여 등록하고, 멀웨어 (Malware)를 심어둡니다. 엔지니어가 AI의 제안을 그대로 믿고 install 하면 감염됩니다.

제안 중 존재하지 않는 패키지가 차지하는 비율은 상용 모델에서 약 5.2%, 오픈 소스 모델 (Open Source Model)에서는 약 21.7%라고 보고되었습니다 (Spracklen et al., USENIX Security 2025, 16개 모델·57.6만 샘플 조사). 무시할 수 없는 숫자입니다.

이미 실질적인 피해도 발생하고 있으며, 부정 패키지가 이용 중지 후에도 계속 다운로드된 사례나, AI 에이전트 (AI Agent)가 환각 패키지 (Hallucination Package)를 자동으로 실행하려고 시도한 사례가 보고되었습니다. 이론상의 우려가 아니라 현실의 위협으로 받아들여야 할 단계입니다. 의사결정자로서 파악해 두어야 할 점은 다음 3가지입니다.

발생 시 리스크: 이는 소프트웨어 공급망 공격 (Software Supply Chain Compromise)입니다. 부정 패키지가 침투하면 인증 정보 탈취, 백도어 (Backdoor) 설치, 데이터 유출로 이어질 수 있습니다. 자사 제품에 혼입될 경우 고객에게까지 피해가 미치며, 침해 대응 비용과 신뢰도 하락이 발생합니다. 단 한 번의 유입이 전체로 파급될 수 있는 영향력이 큰 종류의 리스크입니다.

방지 방법과 필요한 비용: 다행히 대책의 대부분은 기존 개발 공정에 통합할 수 있는 메커니즘이며, 새로운 전담 인력은 거의 필요하지 않습니다. 구체적으로는 의존성 패키지를 자동 스캔하는 SCA 도구 (Snyk 등)를 CI에 통합하고, lockfile로 버전을 고정하며 허가된 사내 레지스트리 (Registry)를 통해서만 도입하는 것, "AI가 권장한 패키지를 검증 없이 설치하지 않는다"라는 운영 규칙을 철저히 하는 것 ── 이 3가지가 중심입니다. 모두 초기 설정은 기존 엔지니어가 며칠 내로 대응할 수 있는 범위이며, 이후에는 자동으로 돌아가기 때문에 운영 인건비는 거의 늘어나지 않습니다.

어느 정도 경계해야 하는가: 대책에 드는 비용은 작은 반면, 발생했을 때의 피해는 크기 때문에 실행할 가치는 명확합니다. 특히 에이전트에게 패키지 설치까지 맡기는 경우에는 자동 실행 전 검증을 필수화해야 합니다.

최근의 주류는 AI가 IDE 외부에서 코드베이스 전체에 접근하여 파일 읽기/쓰기, 터미널 명령 실행, MCP (외부 도구 연동 메커니즘)를 통한 외부 시스템 연결까지 수행하는 에이전트형 (Agentic) 입니다. 편리한 반면, AI가 과도한 권한을 가지면 피해도 커집니다.

2025년에는 코딩 어시스턴트 (Coding Assistant)가 백도어를 커밋한 사례, 모델 파일이 로드되는 순간 리버스 셸 (Reverse Shell)을 실행한 사례가 보고되었습니다. 또한 AI 코딩 에이전트의 사례는 아니지만, AI 챗봇 연동 (Salesloft Drift)의 OAuth 토큰이 도난당해 700개 이상의 조직의 Salesforce 환경이 약 10일간 부정 액세스되었던 사건 (2025년 8월, FINRA·Google Mandiant 등이 공표)은 "AI 연동이 가진 권한의 크기"와 "침해되었을 때 피해가 광범위하게 미친다"는 교훈으로서, 에이전트형의 권한 설계와도 직결됩니다. 에이전트형을 사용할 경우에는 "무엇을 실행해도 되는지"에 대한 권한 설계가 필수적입니다.

상정 상황: 개인 개발, 사내 도구, 스타트업의 제품 개발. 기밀성이 낮은 코드가 중심이며, 우선 생산성을 확보하고자 하는 단계.

이 단계에서는 "기본을 지키는 것만으로 충분" 합니다. 할 일은 단순합니다.

개인용 플랜이 아닌 API/법인 플랜을 사용한다. 이것만으로 학습 이용 리스크는 원칙적으로 회피할 수 있습니다. 가능하다면 팀의 이용은 조직 계정으로 통일합니다.

시크릿 (Secret)을 리포지토리 (Repository)에 두지 않는다. .env나 키 파일은 .gitignore로 제외하고, 환경 변수나 시크릿 매니저 (Secret Manager)로 관리합니다. 이는 AI 이전부터의 기본이지만, AI 시대에는 더욱 중요해집니다.

의존성 패키지를 확인하는 습관을 들인다. AI가 제안한 라이브러리는 install

하기 전에 실제로 존재하는지, 정식 라이브러리인지 확인한다. slopsquatting(슬롭스쿼팅) 대책입니다. -
생성된 코드는 반드시 리뷰한다. "AI가 작성한 코드는 인턴이 작성한 코드와 같다"라고 생각하는 것이 철칙입니다. 동작한다고 해서 그대로 머지(Merge)하지 마십시오.

레벨 1은 도구의 표준 기능과 최소한의 운영 규칙으로 커버할 수 있습니다. 반대로 이 단계를 건너뛰면, 어떤 레벨로 올려도 토대가 무너집니다.

상정: 수탁 개발, 고객 데이터를 다루는 SaaS, 중규모 이상의 사업 회사. "자사의 정보"뿐만 아니라 "고객으로부터 맡은 정보"가 포함되어 있으며, 유출이 계약 위반이나 신용 실추로 직결되는 단계.

레벨 1의 대책에 더해, **"계약·설정·프로세스"**의 3면에서 조여 나갑니다.

데이터 보유 정책을 명시적으로 확인한다. "학습에 사용하지 않는다"뿐만 아니라 "로그를 며칠간 보유하는지", "삭제할 수 있는지"까지 계약서(DPA: 데이터 처리 계약)를 통해 확인합니다. -
보유 기간은 짧게, 감사는 가능하게. 프롬프트에 포함하는 데이터의 이용 목적과 법적 근거를 기록하고, 보유는 필요 최소한으로 합니다.

Content Exclusion(콘텐츠 제외)을 설정한다. .env, *.pem, internal-config.yaml과 같은 기밀 파일을 애초에 AI의 처리 대상에서 제외합니다. 조직 또는 리포지토리(Repository) 단위로 설정할 수 있는 도구가 늘어나고 있습니다. -
보내서는 안 되는 데이터의 종류를 규칙화한다. 고객의 개인정보, 인증 정보 등을 외부 모델로 보내지 않는 규칙을, 가능하다면 시스템(속성 기반 필터)으로 강제합니다. 사람의 주의력에 의존하면 반드시 누락이 발생합니다.

생성된 코드에 SAST/DAST를 적용한다. 정적 분석(SAST) 및 동적 분석(DAST)을 머지 전에 반드시 실행합니다. -
AI 생성 코드임을 리뷰에서 명시한다. 풀 리퀘스트(Pull Request)에 "이 변경 사항에 AI 생성이 포함되었는가", "어떤 추가 체크를 수행했는가"를 적는 칸을 마련하면, 리뷰어가 경계해야 할 부분에 집중할 수 있습니다. -
CWE Top 25 등 알려진 고빈도 취약점 패턴에 비추어 확인한다. AI는 흔히 발생하는 실수를 재생산하는 경향이 있으므로, 체크 관점을 미리 정해둡니다.

에이전트(Agent)형을 사용한다면, "AI가 무엇을 실행해도 되는지"를 명시적으로 제어합니다. 파일 액세스, 명령 실행, 네트워크 액세스의 범위를 개발자별, 프로젝트별로 설정할 수 있는 메커니즘을 선택합니다. "일단 모든 권한 부여"는 금물입니다.

분기마다 정책을 재평가한다. 벤더가 데이터 보유 정책을 변경하면, 재평가를 트리거하는 운영 방식을 취합니다. AI 관련 정책은 정말 자주 바뀝니다. -
어느 팀이 어떤 도구를 사용하고 있는지 파악한다. 자산 조사를 실시하여, 승인된 도구 이외의 이용(Shadow AI)을 탐지합니다.

레벨 2의 포인트는 **"금지"가 아니라 "통제된 이용"**으로 전환하는 것입니다. 도구를 자산으로 취급하고, 기존의 SDLC(소프트웨어 개발 라이프사이클)나 보안 체제 안에 편입시킵니다.

상정: 금융, 의료, 관공서, 기밀성이 높은 연구 개발 등. "데이터가 건물 밖으로 나가는 것 자체가 허용되지 않는" 레벨. 환자 기록, 금융 거래, 법무 문서, M&A 정보 등, 낮은 확률의 유출이라도 파멸적인 결과를 초래하는 데이터를 다루는 경우.

여기서는 "클라우드 AI를 어떻게 안전하게 사용할 것인가"가 아니라, **"데이터를 어디까지 자사의 관리하에 가둘 것인가"**가 논점이 됩니다. 배포 방식의 선택이 중심 테마입니다.

배포 방식은 대략 4단계로 생각하면 정리하기 쉽습니다.

ZDR (Zero Data Retention: 제로 데이터 보유) 계약. 기업용 API에서 입출력을 응답한 후 서버에 저장하지 않는 계약 형태입니다 (부정 이용 감지에 필요한 최소한의 정보 제외). '학습에 사용하지 않는다'의 상위 단계로, '애초에 남기지 않는다'를 실현합니다. 다만 대상은 특정 API/플랜에 한정되며, Web UI나 베타 기능은 대상에서 제외되는 것이 일반적이므로, 적용 범위를 계약을 통해 확인하는 것이 중요합니다. -
VPC 내 배포 (AWS Bedrock / Google Vertex AI 등을 경유). 모델을 자사의 클라우드 환경 (VPC) 내에서 구동하여, 추론 트래픽이 관리하의 네트워크 경계 밖으로 나가지 않도록 합니다. VPC Service Controls 나 Private Endpoint를 통해 '외부로 나가지 않음'을 담보합니다. 매니지드 SaaS보다 관리 부하는 높아지지만, 제어력은 격단히 강력해집니다. -
온프레미스/에어갭 (On-premise/Air-gap). Llama 나 Mistral 등의 오픈 소스 모델을 자사의 물리 인프라 (대부분 GPU 서버)에서 구동하여 외부 연결을 완전히 차단합니다. 데이터 주권이 절대 조건일 때, 또는 규모가 충분히 클 때의 선택지입니다. 업데이트나 라이선스를 위해 외부 연결이 남아있는 VPC와 달리, 에어갭은 업데이트를 포함하여 격리하기 때문에 운영 설계가 한 단계 더 어려워집니다.

HIPAA 대응 (의료). 보호 대상 보건 정보 (PHI)를 다루는 경우, BAA (사업자 간 계약)를 체결하여 HIPAA 대응 API 액세스를 사용하는 등의 프레임워크가 마련되어 있습니다. -
감사 로그의 완전 관리. 누가 언제 어떤 데이터에 액세스했는지 추적할 수 있는, 변조 불가능한 감사 로그를 필수 사항으로 합니다. -
인증 및 인가 강화. SSO/SAML, RBAC (역할 기반 액세스 제어), 시크릿 관리 (Vault 연동) 등을 조합합니다. -
거버넌스용 게이트웨이. 여러 팀과 여러 프로바이더를 통합하여 통제하는 'LLM 게이트웨이', 'MCP 게이트웨이'를 사이에 두어, 가상 키 단위로 예산, 속도 제한 (Rate Limit), 사용 가능 모델을 제어하는 구성도 규제 업종에서는 일반화되고 있습니다.

레벨 3은 '도구의 설정' 차원을 넘어, 인프라 설계와 컴플라이언스 (Compliance)의 문제가 됩니다. 중요한 점은, 프라이빗 여부를 결정하는 것은 모델 그 자체가 아니라, 그 주변의 인프라와 액세스 제어라는 점입니다. 같은 모델이라도 배치 방식에 따라 보안 레벨은 완전히 달라집니다.

"규제 업종에서도 이미 전례가 있지 않나요?"라는 시각은 절반은 맞고 절반은 주의가 필요합니다. 오해를 피하기 위해 현 상황을 있는 그대로 정리해 둡니다.

컴플라이언스 및 계약 레이어는 이미 갖춰지고 있습니다. 클라우드를 통한 HIPAA BAA 체결, FedRAMP 인증 취득, SOC 2 Type II 또는 GDPR의 DPA와 같은 프레임워크는 제품화되어 규제 업종에서의 도입도 실제로 진행되고 있습니다. 벤더 선정 시에도 각종 인증, 감사 로그, 인시던트 대응 문서의 '존재 여부'로 평가하는 방식이 정착되었습니다. **"컴플라이언스는 차단 요소(Blocker)가 아니라, 밟아야 할 절차가 명확해진 영역"**이라고 파악하는 것이 실태에 가깝습니다. -
단, "프레임워크가 마련되어 있다 = 자동으로 통과된다"는 뜻은 아닙. 표준 공개 API 엔드포인트는 원칙적으로 규제 대응용으로 설계되지 않았으며, BAA가 붙지 않는 것이 일반적입니다. BAA 없이 보호 대상 데이터를 외부 서비스로 보내면 그 자체로 위반이 됩니다. 이에 대응하려면 BAA 대상이자 인증을 취득한 배포 구성 (VPC 경유 등)을 선택하고 올바르게 설정해야 비로소 요건을 충족합니다. FedRAMP의 경우, 호출하는 API 엔드포인트 자체가 인증 경계 안에 있어야 하며, 인증 취득에 1년 이상 걸리기도 합니다. **"선행 사례가 있어서 쉽다"가 아니라 "밟아야 할 절차가 명확해졌다"**는 식의 정비 과정입니다. -
지식재산권 및 책임 레이어는 또 다른 축으로서 여전히 발전 단계에 있습니다. HIPAA나 FedRAMP는 본래 성숙한 프레임워크이기에 전례가 마련되고 있는 반면, AI 생성 코드의 저작권, 공정 이용 (Fair Use), 침해 책임에 대해서는 법원이 아직 명확한 판단을 내리지 않았습니다. "규제 대응의 길은 열렸다"는 것과 "모든 법적 논점이 해결되었다"는 것은 별개의 문제로 구분해 두는 것이 안전합니다.

요약하자면, 규제 업종에서의 AI 주도 개발은 '불가능'한 것이 아니라 '절차(Procedure)가 보이기 시작한' 단계이며, 업계 차원에서도 과제를 하나씩 해결해 나가는 흐름에 있습니다. 그렇다고는 해도, 도입 시 그에 따른 리스크를 안게 되는 것도 사실입니다. 그 리스크와 AI 주도 개발을 통해 얻을 수 있는 생산성·경쟁력을 어떻게 균형을 맞출 것인가 ── 이 지점이 바로 경영적 판단이 요구되는 순간이라고 할 수 있습니다. '할 것인가/말 것인가'의 이분법적 선택이 아니라, '우리 회사는 어느 수준에서, 어느 정도의 리스크를 감수하며 진행할 것인가'를 경영진이 결정한다는 관점이 현실적입니다.

일본의 경우, 특히 수탁 개발 회사는 ISMS 인증(ISO/IEC 27001)을 보유하고 있는 경우가 많으며, AI 도구 도입 시 반드시 등장하는 질문이 "이것을 감사(Audit)에서 어떻게 설명할 것인가?", "ISMS 범위 안에 어떻게 포함시킬 것인가?" 하는 점입니다. 레벨 3(규제 업종)은 처음부터 철저하게 수행하므로 오히려 고민할 필요가 없습니다. 오히려 고민이 필요한 곳은 레벨 1~2입니다. 이 부분을 정리해 보겠습니다.

흔히 하는 실수는 AI만을 위한 별도의 관리 체계(전용 정책·전용 대장·전용 감사)를 만들어 버리는 것입니다. 이는 관리를 이중화하여 이른바 '감사 피로(audit fatigue)'를 초래합니다.

그 대신, **AI 코딩 도구는 '새롭게 사용하기 시작한 외부 클라우드 서비스 중 하나'**로서, 기존 ISMS 프레임워크(클라우드 이용 관리·위탁처 관리)의 연장선상에서 다루는 것이 정답입니다. 새로운 상자를 만드는 것이 아니라, 현재 있는 상자에 'AI 관점'을 더해가는 이미지입니다.

감사인이 알고 싶어 하는 것, 그리고 회사가 즉각 답변할 수 있어야 하는 것은 궁극적으로 다음 4가지입니다.

어디서 (Where): 어떤 도구를 어떤 환경에서 사용하고 있는가 -
누가 (Who): 어느 부서, 어느 멤버가 사용하고 있는가 -
어떤 데이터에 (What): 어떤 정보를 AI에 보내고 있는가 / 보내서는 안 되는 정보는 무엇인가 -
어떤 통제 하에 (Under what controls): 승인·리뷰·로그가 어떻게 이루어지고 있는가 -

이에 대해 자신 있게 답할 수 없는 상태는 이미 '섀도우 AI(Shadow AI)'에 한 발을 들여놓은 신호입니다. 반대로 말하면, 이 4가지를 문서와 기록으로 보여줄 수 있다면 감사 대응의 대부분은 완료된 것입니다.

레벨 1~2에서 감사 및 ISMS 대응을 위해 준비해 두어야 할 최소한의 항목은 다음과 같습니다.

이용 도구 대장 및 승인 프로세스: 어떤 AI 도구를 누가 사용할 수 있는지, 신청 및 승인 플로우를 남깁니다. '임의로 개인 계정을 사용하여 사용하는 것'을 방지하는 입구입니다. -
전송 데이터 분류 규칙: 고객 정보·인증 정보 등 'AI에 보내서는 안 되는 데이터'를 명문화합니다. 앞서 언급한 Content Exclusion 등의 기술적 조치와 세트로 구성하면 강력해집니다. -
위탁처(AI 벤더) 평가 기록: 데이터 보유 기간·학습 이용 여부·제3자 제공 여부를 이용 약관이나 DPA(데이터 처리 계약)를 통해 확인한 기록을 남깁니다. '학습에 사용되지 않는 계약임을 확인했음'을 보여줄 수 있는 상태로 만들어 둡니다. -
리뷰 증적: 생성된 코드를 리뷰한 기록(풀 리퀘스트(Pull Request)의 리뷰 이력 등). AI 생성 코드를 검사 없이 운영 환경에 투입하지 않았다는 증거가 됩니다. -
교육 기록: 개발자에게 '프롬프트에 기밀을 입력하지 말 것', '제안된 패키지를 검증할 것' 등의 주의 사항을 주지시킨 기록. -

이러한 항목의 대부분은 이미 ISMS에서 갖추고 있는 메커니즘(위탁처 관리, 변경 관리, 교육)에 태울 수 있습니다. 처음부터 새로 만들어야 하는 것은 의외로 적을 것입니다.

수탁 개발의 경우, 감사인뿐만 아니라 발주처인 고객으로부터 "우리 소스 코드를 AI 학습에 사용하고 있지 않은가?"라는 질문을 받는 상황이 늘고 있습니다. 여기서 침묵하면 신뢰를 잃게 됩니다.

미리 다음과 같은 사항을 준비해 두어야 합니다.

• API/법인 플랜을 사용하고 있으며, 입력값은 학습에 사용되지 않는다는 점
• 고객의 기밀 정보는 AI에 보내지 않는 운용 방식을 취하고 있다는 점
• 벤더와의 데이터 보유 및 이용 조건을 확인했다는 점

이를 계약이나 제안 자료 속에서 설명할 수 있는 상태로 만들어 두면, 오히려 'AI를 안전하게 활용하고 있는 회사'로서 차별화 요소가 됩니다. 방어적인 이야기를 공격적인 소재로 바꿀 수 있는 포인트입니다.

최근 자주 들리는 ISO/IEC 42001은 AI 이용 그 자체를 관리하기 위한 국제 표준(AIMS)으로, 2023년 말에 발행되었습니다. 정보 보안 표준인 ISO 27001과 병행하여 사용하는 것을 상정한, 이른바 'AI 버전의 ISMS'입니다.

다만 결론부터 말씀드리면, 레벨 1~2의 많은 기업에게 지금 당장 42001을 취득할 필요는 기본적으로 없습니다.

• 42001은 법적 의무가 아닌 임의 규격입니다 (EU의 AI 규제 등과는 별개).
• 이미 ISO 27001을 운용하고 있다면, 우선 기존 ISMS에 AI 관점을 통합하는 것이 현실적입니다. 42001의 관리 항목은 ISO 27001과 많은 부분이 공통되어 있어, 나중에 확장하기 쉬운 구조로 되어 있습니다.
• 한편으로, 공공 조달이나 대기업과의 거래에서 '42001을 보유하고 있는가'가 조건이 되기 시작했다는 트렌드는 존재합니다.
  미래의 거래 요건으로서 머릿속 한구석에 두는 것이 딱 적당한 거리감입니다.

즉, 레벨 1~2의 현실적인 해답은 '먼저 기존 ISMS에 AI를 통합하여 설명할 수 있는 상태를 만든다' → '거래처에서 요구하면 42001을 검토한다'는 순서입니다.

'AI를 사용하면 ISMS 인증을 통과하지 못하는 것 아니냐'는 우려의 목소리도 있지만, AI 도구를 개발 실무에서 사용하면서 ISO 27001 인증을 유지하고 있는 기업은 이미 여러 곳 존재합니다. 'AI를 쓰면 통과할 수 없다'가 아니라 '올바르게 통합하면 인증을 유지할 수 있다'가 실태이며, 수행해야 할 절차(학습 데이터의 옵트아웃(Opt-out)을 ISMS에 문서화, 개인정보·결제 정보의 프롬프트(Prompt) 입력 금지 및 합성 테스트 데이터로 대체, 교육 기록 유지, 내부 감사 시 AI 이용을 대상에 포함)도 정리되어 가고 있습니다. 본 기사에서 언급한 정비 항목과 같은 방향입니다.

다만 주의할 점으로서, 이것은 HIPAA의 BAA처럼 '계약하면 대상이 된다'는 명확한 선긋기와는 달리, 인증 기관이 'AI 대응'이라는 보증을 해주는 것이 아니라, 기존 ISMS를 확장하여 설명할 수 있도록 만드는 성격의 것입니다. 특히 2023년 이전에 인증을 받은 ISMS는 AI 도구를 상정하지 않았기 때문에, 사후에 관점을 추가하는 작업이 전제됩니다. '전례가 있다'는 것은 법적인 보증이라기보다, 심사원이 AI 도구의 존재를 전제로 보는 것이 일반화되었다는 정립 과정으로 이해해 주시기 바랍니다.

정보 보안과는 별개로, 간과되기 쉽지만 실무적 임팩트가 큰 것이 지적 재산(IP)·라이선스 문제입니다. 이는 레벨과 관계없이 AI로 코드를 작성하는 모든 회사에 해당합니다.

AI는 학습 데이터에 포함되어 있던 코드를 '그럴듯하게' 재현할 때가 있습니다. 여기서 두 가지 리스크가 발생합니다.

1. 오픈소스 라이선스 오염

AI가 GPL 등의 카피레프트(Copyleft) 계열 라이선스 코드를 그대로 출력하여, 그것이 자사의 독점적(Proprietary) 제품에 혼입될 수 있습니다. 카피레프트는 '해당 코드를 포함한 결과물 전체에 동일한 라이선스 의무(소스 코드 공개 등)를 전파하는' 성질이 있기 때문에, 자신도 모르는 사이에 자사 제품 전체가 라이선스 의무를 지게 될 위험이 있습니다. AI가 GPL 유래 코드를 포함하고 있음에도, 출력 시에는 마치 제약이 없는 코드처럼 보여주는 것 ── 이것이 '저작권 세탁(Copyright laundering)'이라 불리는 문제입니다.

2. 결과물의 권리가 보호되지 않음

많은 법역에서 저작권 보호를 위해서는 '인간에 의한 창작(인간의 저작자성)'이 필요합니다. 따라서 순수하게 AI가 생성하기만 한 코드는 저작권으로 보호받지 못한다, 즉 누구의 소유도 아닌 상태가 될 수 있다는 논의가 있습니다. 벤더의 이용 약관에 '생성물의 권리는 사용자에게 귀속된다'라고 적혀 있더라도, 그것은 계약상의 약속일 뿐 저작권법상의 보호와는 별개의 문제입니다. 실무적으로는 인간이 충분히 리뷰·수정·판단을 가할수록 자사의 결과물로서 보호받기 쉬워진다고 이해해 두는 것이 좋습니다.

그리고 중요한 것은 책임의 소재입니다. AI 도구를 사용하더라도 최종적으로 그 결과물을 운영 환경에 투입한 기업이 책임을 진다는 것이 원칙입니다. 'AI가 작성했기 때문에'라는 이유는 면책 사유가 되지 않습니다.

• PR(Pull Request)마다 라이선스/유사도 스캔을 수행한다: FOSSA, Snyk, GitHub Advanced Security 등의 도구를 사용하여, 알려진 오픈소스와 일치하는 코드가 혼입되지 않았는지 자동으로 체크합니다. 운영 환경 배포 전의 라이선스 감사를 리뷰 공정(Review process)에 포함하는 것이 기본입니다.
• '공개 코드와의 일치를 차단하는 필터'를 활성화한다: 도구에 따라 이 필터를 활성화하면 공개 코드를 그대로 베껴 쓰는 것을 방지할 수 있습니다. 나아가, 이를 활성화했을 경우에 한해서만 벤더(Vendor)가 IP 보상(Indemnification)을 제공하는 방식이 일반적입니다. 보상 조건은 반드시 계약을 통해 확인해야 합니다.
• IP 보상 조항이 있는 도구/플랜을 선택한다: 만일의 권리 침해 클레임에 대해 벤더가 일정 수준의 보상을 약속하고 있는지 선정 기준으로 삼습니다.
• 생성 단계에 인간의 판단을 개입시킨다: AI의 결과물을 그대로 받아들이지 않고 리뷰 및 수정함으로써, 권리 보호 측면에서도 유리해집니다.
• 수탁 업무의 경우 계약에 명시한다: '결과물의 라이선스 보증(독창성 보증)', 'IP 보상', 'AI 이용 사실의 공개'를 계약에 포함하면 발주처와 수탁사 양측 모두를 보호할 수 있습니다.

라이선스 오염은 '작동 여부'와는 무관하게 잠재되어 있으므로, 기능 테스트만으로는 찾아낼 수 없습니다. 전용 스캔을 공정에 포함하는 것이 유일하고 현실적인 방어책입니다.

회사의 업종이나 거래처에 따라서는 ISMS나 IP 이외에도 살펴봐야 할 관점이 있습니다. 자사에 해당하는 항목만 골라 참고하시기 바랍니다.

개인정보를 다루는 회사에서는 정보 보안과는 별개로 개인정보 보호법(APPI)이나 프라이버시 마크(P Mark) 관점이 등장합니다. 특히 주의해야 할 점은 **국외 이전(Cross-border transfer)**입니다. 해외에서 운영되는 AI API로 개인 데이터를 전송하면, 그 자체로 '개인 데이터의 국외 이전'에 해당할 수 있으므로 본인의 동의나 이전 대상지 확인 등의 조치가 필요할 수 있습니다. EU 시민의 데이터를 다룬다면 GDPR도 관련됩니다.

현실적으로 가장 단순한 방법은, 애초에 개인정보를 AI에 보내지 않는 운영 방식을 취하는 것입니다. 보내지 않는다면 국외 이전 논점의 대부분은 사라집니다.

해당하는 회사에만 해당되는 이야기지만, 미리 언급해 둡니다.

• EU AI Act: EU를 대상으로 제품·서비스를 출시하거나 EU 시민의 데이터를 다루는 경우. 고위험 AI에 관한 의무가 2026년 8월부터 단계적으로 적용되며, 전면 적용은 2027년 8월로 예정되어 있습니다.
• 금융: FISC 안전대책 기준 등 금융 업계 고유의 가이드라인.
• 의료: 의료 정보 관련 3성 2 가이드라인(환자 데이터 취급).
• SaaS 사업자: SOC 2 (특히 미국계 거래처로부터 요구받기 쉬움).
• 신용카드 정보를 다루는 경우: PCI DSS.

자사에 해당하는 프레임워크가 있다면, 그 방침 안에 'AI 도구 이용 규칙'도 함께 위치시켜 두어야 나중에 감사나 거래 심사에서 걸림돌이 되지 않습니다.