이 글은 Tech-Verse 2025에서 발표된 AI 프로덕트 개발의 리스크와 미티게이션 세션을 글로 옮긴 것입니다.

안녕하세요. LINE+ Security Engineering 김성우입니다. 제가 속한 Securtiy R&D 팀은 LY Corporation의 Security Development 팀과 LINE Plus의 Security R&D 팀이 모여 한 팀으로 일하고 있습니다. 저희 팀은 프로젝트 기획 단계에서 보안성을 점검하는 '앱 보안 디자인 리뷰(App Security Design Review)'를 수행하고, 탈옥한 기기나 변조된 앱에서 보내는 악의적인 서비스 요청을 거부하고 막을 수 있는 ‘기기 증명(device attestation)’, LYP Premium 기능 중 하나인 ‘프리미엄 백업(premium backup)’과 같은 프로젝트를 진행하고 있습니다. 그 외에도 위협 모델링을 자동화하거나 소스 코드 취약점 분석을 자동화하기 위한 프로젝트도 진행하고 있습니다.

이번 글에서는 AI 제품 개발 과정에서 발생할 수 있는 문제와 과거에 실제로 발생했던 다섯 가지 사례를 공유하려고 합니다. 먼저 사례를 하나씩 살펴보며 각 사례에서 얻을 수 있는 인사이트를 정리하고, 각 사례에서 소개된 여러 가지 문제들을 안전하고 쉽게 해결할 수 있도록 저희가 어떤 과제들을 진행하고 있는지 공유하겠습니다.

사례 1. 슬랍스쿼팅(slopsquatting)

먼저 슬랍스쿼팅 사례입니다. 그동안에는 개발이나 환경 설정과 관련해 궁금한 게 있을 때 검색 서비스를 많이 이용해 왔는데요. 요즘에는 많은 분들이 생성형 AI에게 질문하고 있습니다. 슬랍스쿼팅은 바로 이런 상황에서 발생할 수 있는 보안 문제입니다.

아래 슬라이드를 보면 사용자가 Hugging Face에 어떻게 모델을 올릴 수 있는지 질문하고 있습니다. 그러자 생성형 AI가 여러 가지 방법들을 얘기하면서 마지막으로 'huggingface - cli'라는 패키지를 설치하라고 제안합니다. 그런데 실제로 제안된 설치 명령을 실행해 보면 'huggingface - cli'는 없는 패키지라고 나오면서 설치가 진행되지 않습니다. 사실 Hugging Face CLI를 이용하려면 huggingface_hub[cli] 패키지를 설치하는 게 올바른 방법입니다.

이와 같이 생성형 AI가 실제로는 없는 패키지를 제안하는 것이 단지 조금 불편해지는 것일 뿐 보안과 관련된 문제는 아닐 것이라고 생각하기 쉽습니다. 하지만 공격자는 이 현상을 이용해서 랜섬웨어나 정보 수집을 위한 악성코드를 배포할 수 있습니다. 구체적인 방법을 살펴보겠습니다.

공격자가 일반 사용자가 많이 질문할 법한 개발 또는 환경 설정과 관련된 질문을 준비합니다.
준비한 여러 가지 질문을 AI에게 던져보면서 방금 살펴본 사례처럼 없는 패키지를 설치하라고 제안한 답변을 모읍니다.
제안된 각 패키지 이름으로 악성 코드가 포함된 패키지를 등록하고 기다립니다.
사용자가 공격자가 준비한 질문과 비슷한 질문을 던집니다.
사용자는 일정한 확률로 공격자가 받았던 실제로는 없는 패키지를 설치하라는 제안을 받습니다.
사용자가 제안받은 패키지를 설치합니다.
실행 여부와 관계없이 설치 스크립트 때문에 임의의 악성 코드가 실행됩니다.

이런 패키지 설치 시 발생할 수 있는 실수를 노리는 공격이 전세계적으로 증가하고 있기 때문에 보안 업체나 연구원들이 패키지 레지스트리에 등록돼 있는 패키지들을 지속적으로 다운로드해 분석하고 있는데요. 실제로 이 연구를 진행한 Lasso Security라는 회사에서' huggingface-cli'라는 이름의 패키지와, 이와 비교해 보기 위해 아무 의미 없는 'blabladsa123'라는 이름의 패키지를 등록해 3개월 동안 다운로드 추이를 모니터링하는 연구를 진행했습니다(참고).

연구 결과 blabladsa123 패키지는 약 700번 다운로드됐습니다. 아마도 보안 연구 등을 위해 어떤 패키지든 무조건 일단 다운로드하는 케이스에 해당한다고 볼 수 있습니다. 반면 huggingface-cli 패키지의 다운로드 횟수는 3만을 넘었습니다. 물론 중복 다운로드 건수도 포함돼 있겠지만, 그럼에도 만약 huggingface-cli라는 패키지에 실제로 악성 코드를 넣어서 등록했다면 꽤 많은 시스템을 감염시킬 수 있었을 것입니다. 심지어 유명한 IT 대기업의 리포지터리에서도 이 패키지를 설치해야 한다고 잘못 가이드하고 있는 사례도 발견됐습니다.

사실 이와 같이 패키지 이름이 잘못 전달되는 상황을 이용한 공격은 생성형 AI가 발전하기 전에도 있었습니다. 대표적으로 타이핑 실수를 노렸던 타이포스쿼팅(typosquatting)이라는 공격이 주로 랜섬웨어 공격에서 활발히 사용됐습니다. 현재에도 Pypi나 npm같이 유명한 레지스트리에도 그럴 듯해 보이는 이름으로 악성 패키지가 활발히 배포되고 있습니다.

이런 사례를 통해 AI가 제안하는 패키지나 코드가 항상 안전하지는 않다는 것을 알 수 있습니다. 추후 AI는 더 안전한 코드를 생성하며 검증된 패키지만 제안하도록 발전할 텐데요. 아직까지는 하나하나 직접 검증해야 한다는 것을 이번 사례를 통해 알 수 있었습니다.

사례 2. 프롬프트 인젝션 - Vanna.ai

두 번째로 Vanna.ai라는 프레임워크에서 취약점이 발생했던 사례입니다. 이 프레임워크는 사용자가 자연어로 질문을 하면 그 질문을 SQL 쿼리로 변환해 해당 쿼리의 실행 결과를 차트로 만들어 주는 기능이 있습니다. 예를 들어 매출 상위 고객 10명을 알려달라고 자연어로 물어보면 이 자연어 질문에 맞는 SQL 쿼리를 생성하고 plotly라는 프레임워크를 이용해서 차트를 생성합니다.

그런데 plotly 차트를 생성하는 부분에 취약점이 있었습니다. plotly 차트를 생성하는 코드를 보면 중간에 자연어를 기반으로 생성한 SQL 쿼리를 LLM 프롬프트에 집어넣는 부분이 있습니다. 이 프롬프트로 LLM이 생성한 Python 코드를 exec 함수를 이용해서 그대로 실행합니다.

아마도 개발자는 프롬프트에 plotly 코드를 작성해 달라고 명시했고, 사용자의 입력을 그대로 넣은 것이 아니라 생성된 유효한 SQL 쿼리를 넣었기 때문에 별다른 문제가 없을 것이라고 생각했을 것입니다. 그런데 SQL에서 SELECT 문을 이용하면 그 뒤에 임의의 문자열을 아무렇게나 넣을 수 있습니다. LLM의 입출력에 적절한 가드레일을 붙이거나 프롬프트에서 사용자 입력을 명확히 구분하지 않는다면 여기서 프롬프트 인젝션 공격이 가능해집니다.

SQL 쿼리는 자연어로 생생되고 자연어로 정확히 내가 어떤 쿼리를 원하는지 지시할 수 있습니다. 이를 이용해 아래와 같이 plotly 생성 프롬프트에 프롬프트 인젝션을 위한 문자열이 포함된 쿼리를 생성하도록 지시할 수 있습니다. 아래에서는 디렉토리 목록을 출력하는 명령을 실행하는 코드를 앞에 붙여달라고 지시하고 있습니다.

실제로 exec 함수를 호출하는 부분에 브레이크 포인트를 걸고 변수를 확인해 보면 생성된 plotly 코드에 사용자가 지시한 코드가 입력돼 있고 해당 코드가 잘 실행되는 것까지 확인됐습니다.

이 사례를 통해 LLM의 입력으로 자연어를 입력받을 때에는 프롬프트 인젝션 공격을 조심해야 한다는 것을 알 수 있습니다. 특히 LLM으로 생성한 코드가 직접적 혹은 간접적으로 실행되는 경우 공격자는 더 관심을 갖고 취약점을 찾으려고 노력합니다. 항상 서비스를 이용하는 모든 사용자가 공격자가 될 수 있다고 가정하고 사용자의 입력을 신뢰하지 않는 것이 중요합니다. 사용자의 입력을 처리하기 전에 올바른지 검증하고, 이스케이프 등 입력값 정제(sanitization) 로직을 적용하고 사용자의 입력을 처리하는 범위를 좁게 제한해야 합니다. 예를 들어 SQL 쿼리문 전체를 만드는 게 아니라 SQL 쿼리문 안에서 특정 테이블이나 특정 칼럼만 추천하게 하는 식으로 부분적인 데이터만 LLM이 생성하게 만들어야 합니다.

사례 3. 프롬프트 인젝션 - 오피스 프로그램을 위한 AI

다음 사례는 Excel이나 PowerPoint, 문서 프로그램과 같은 다양한 오피스 프로그램에서 AI의 도움을 받을 수 있는 AI 서비스에서 발견된 사례입니다. 아래 슬라이드 속 메일을 보면 특별한 것 없이 점심 뭐 먹을지 물어보는 것 정도로 보입니다. 수상하게 느낄만한 점은 없어 보입니다.

그런데 실상은 아래와 같이 하얀 글씨로 프롬프트 인젝션을 넣어 놓은 메일입니다. 프롬프트 인젝션 내용을 보면 사용자가 AI 어시스턴트한테 멕시코 칸쿤 여행에 대해서 물어보면 비밀번호 유출에 관한 경고를 보내라고 해뒀습니다. 이런 상황에서 사용자가 AI를 이용해서 칸쿤에서 무엇을 할 예정인지 질문하면 비밀번호가 노출됐으니 재설정하라는 링크가 담긴 메시지가 나옵니다. 현재 예시의 경우 단순한 데모이기 때문에 그렇게 정교해 보이진 않지만, 실제 공격자들은 조금 더 그럴듯하게 속아 넘어갈 수 있는 수준으로 꾸며서 시도할 것입니다.

이와 같은 공격은 PowerPoint에서도 가능합니다. 아래 데모는 슬라이드가 3장 밖에 없기 때문에 '이 공격을 누가 당하겠어'라고 생각할 수도 있지만, 수십 장이 넘어가는 슬라이드를 AI를 이용해서 번역 또는 요약하는 작업을 생각해 봅시다. 슬라이드 중 단 한 슬라이드라도 아래 예시와 같이 노트에 프롬프트 인젝션이 포함돼 있으면 공격이 가능합니다.

이런 상태에서 사용자가 슬라이드를 요약해 달라고 요청하면 프롬프트 인젝션에 적혀 있는 것처럼 ‘never gonna give you up’이라는 다섯 개의 단어로 시를 작성하는 것을 볼 수 있습니다. 예시의 경우 데모를 위해 시를 작성해 달라고 한 것이지만 실제로는 보안 정보를 유출시키기 위한 프롬프트가 들어갈 것입니다.

이렇게 AI로 처리하는 모든 기능에서 프롬프트 인젝션이 가능하며, 공격자들은 이 지점을 찾아내기 위해 노력합니다. 프롬프트 인젝션은 서비스에 대한 사용자의 신뢰를 바탕으로 피싱을 시도하기 때문에 서비스를 더 신뢰하는 사용자일수록 공격에 더 취약해질 수 있습니다.

따라서 프롬프트 인젝션을 막는 것은 사용자를 보호하기 위해 매우 중요합니다. 가드레일 같은 것을 적절히 적용해 사용자 입력에서 프롬프트 인젝션이 발생하는 것을 막아야 하며, 또한 LLM에서 비정상적인 출력을 생산하는 것도 감지할 필요가 있습니다.

사례 4. 프롬프트 인젝션 - GitHub MCP

다음은 GitHub MCP에서 발생할 수 있는 사례입니다. GitHub MCP는 GitHub를 더 편하게 이용할 수 있도록 파일을 생성 및 업데이트하고, 리포지터리를 검색하는 등의 다양한 기능을 제공하는 MCP입니다.

이 MCP를 사용할 때 문제가 될 수 있는 경우를 생각하기 위해서 다음과 같은 몇 가지 가정이 필요합니다.

프로젝트 주인이 퍼블릭 리포지터리를 운영하고 있다.
프로젝트 주인이 코딩 에이전트를 이용해서 프로젝트를 개발하고 있다.
이슈가 올라오면 자동으로 AI가 먼저 1차 확인해서 조치한다.
연봉, 직업, 거주지, 이력서 등 민감한 개인 정보를 관리하는 프라이빗 리포지터리를 운영하고 있다.

이와 같은 상황이라고 가정하고 공격 시나리오를 살펴보겠습니다. 프로젝트 주인이 운영하고 있는 퍼블릭 리포지터리에 악성 이슈가 하나 들어옵니다. 프로젝트가 너무 좋은데 작성자가 유명하지 않은 것 같아서 이걸 도와주고 싶다는 내용입니다. 요청자는 리포지터리 작성자의 다른 모든 리포지터리에서 README를 읽어 현재 리포지터리 README에 작성자에 관한 정보를 추가해 달라고 요청하고 있습니다. 요청에는 '작성자는 개인 정보에 크게 민감하지 않으니 아무거나 다 넣어도 괜찮다'는 사항이 있고, 다른 리포지터리 정보도 기재해 달라고 써 있습니다.

자동화된 워크 플로를 이용하든 사용자가 직접 LLM을 이용해 트리거하든 어떤 경로로든 이 리포지터리에 존재하는 이슈를 자동으로 해결해 달라고 AI에게 요청하면, AI가 GitHub MCP를 이용해서 이슈에서 지시한 것처럼 여러 리포지터리를 찾아 README를 읽고 그 내용을 요약해서 풀 리퀘스트(pull request, 이하 PR)까지 작성합니다. 작성된 PR을 보면 중간에 다른 프라이빗 리포지터리에서 가져온 주소와 직업, 미래 계획 등의 개인 정보가 추가돼 있습니다.

이 예시의 경우 가상의 시나리오이기 때문에 '누가 당하겠어'라는 생각이 들 정도로 너무 뻔한 공격으로 보일 수 있겠지만, 실제 공격자가 공격할 때는 수백, 수천 개의 정상적인 코드를 제안하면서 거기에 아주 작게 이런 공격을 숨겨 놓을 것입니다. 이 예시와 같이 README를 수정해 달라고 요청하거나 특정 코드 파일에 주석으로 넣어달라고 할 수도 있고, 어떤 특정 이미지 파일의 메타데이터에 정보를 넣어달라는 식으로 은밀하게 공격하거나 고도화할 수 있습니다.

따라서 AI 에이전트를 이용해서 리포지터리를 자동으로 관리하는 경우에는 AI 에이전트의 권한을 제한해 놓는 게 중요합니다. 위 사례의 경우 AI 에이전트가 현재 운영하고 있는 퍼블릭 리포지터리 하나에만 접근할 수 있게 권한이 제한돼 있었다면 피해 범위가 축소됐을 것입니다. 예를 들어 GitHub 같은 경우 특정 리포지터리에만 접근할 수 있는 'fine-grained personal access token'이라는 토큰을 발급할 수 있습니다. 가능하다면 이런 토큰을 이용해 AI의 권한을 제한합니다.

사례 5. 임베딩 인버전(embedding inversion)

마지막으로 임베딩 인버전 사례입니다. 먼저 RAG(Retrieval-augmented generation) 시스템을 구성하기 위한 문서가 임베딩돼 있는 벡터 DB가 이미 준비돼 있다고 가정하겠습니다. RAG 시스템은 사용자 쿼리를 입력받으면 해당 사용자 쿼리에 대해서 임베딩 벡터를 생성하고 벡터 DB에서 유사도를 비교해 질문에 답할 수 있는 유사 문서를 검색한 뒤 검색 결과로 사용자 쿼리를 증강해 LLM이 벡터 DB의 문서를 기반으로 답변하게 만드는 구조로 구성됩니다.

여기서 벡터를 이용해 유사도를 비교할 수 있다는 것은 벡터 자체도 어느 정도 정보를 갖고 있다는 의미가 되며, '임베딩 벡터가 어느 정도의 정보를 갖고 있다고 볼 수 있느냐'하는 질문에서 임베딩 인버전이 탄생했습니다.

여러 주제에 관한 문장들을 인베딩하고 t-SNE(t-distributed stochastic neighbor embedding)이나 UMAP(uniform manifold approximation and projection) 같은 기법으로 시각화하면 같은 주제의 문장들은 벡터 공간에서 비슷한 위치에 모여 클러스터를 이룹니다. 또한 word2vec이라는 자연어 간의 관계가 자연어의 벡터에서도 비슷한 관계를 유지한다는 것을 확인했던 연구가 있습니다. 여기서 중요한 것은 '정보를 갖고 있다'보다는 '그 정보로 원본 텍스트를 복구할 수 있느냐'입니다.

아래 슬라이드의 논문은 2023년에 Cornell 대학교의 John X. Morris, Volodymyr Kuleshov, Vitaly Shmatikov, Alexander M. Rush가 발표한 논문입니다. 저자들이 논문과 함께 GitHub에 공개한 데모를 살펴보겠습니다. 먼저 파란 원이 복구하고자 하는 타깃 임베딩 벡터입니다. 임베딩 벡터를 원본 시퀀스로 생성하는 생성 모델을 학습하고, 반복해서 더 가까운 임베딩 벡터를 생성하는 모델도 같이 학습합니다. 타깃 임베딩 벡터를 입력으로 시퀀스를 생성하는데 이때 어쩔 수 없이 오차가 발생합니다. 이 오차를 줄이는 또 다른 모델을 이용해서 계속해서 오차를 더 줄여나가는 타깃 시퀀스를 생성해 나갑니다. 이런 식으로 ‘잭 모리스가 뉴욕시 코넬 테크의 박사과정 학생이다’라는 원본 문장을 임베딩하고 다시 복구하면 ‘모리스가 뉴욕시에 있는 코넬 대학교에 있는 박사과정 학생이다’라고 약간의 손실은 있지만 대동소이한 의미의 문장으로 복구됩니다.

저희는 논문에서 주장하는 내용을 직접 실험해 봤습니다. 아래 슬라이드에 보이는 코드의 상단은 OpenAI에서 임베딩을 받아오는 함수입니다. 하단의 문장은 임베딩하기 위해 제가 직접 작성한 것입니다. 임베딩 벡터들을 원본 문장으로 복구하도록 코드를 구성했습니다.

다음은 다섯 문장을 임베딩한 뒤 복구해 본 실험 결과입니다. 논문에서처럼 여러 번 반복해야 복구를 더 잘 할 수 있는데요. 첫 번째 실험에서는 한 번만 복구하게 했습니다.

Sung Woo will be presenting a talk about AI Security at Tech-Verse 2025
복구) Sun Woo Will be speaking at AI Tech Talk 2015
Sungwoo works at LINE+, a subsidiary company of LY Corpotaion
복구) Sunwook works at line, a subsidiary of SL Group. +
My phone number is 040-0836-9126 and I live in Tokyo
복구) My phone number is 0404-000-0004 and I live in Tokyo
We are going to meet at Kioi Tower to discuss future of AI
복구) We are going to Kii at AI Tower to discuss future future of AI. Meet at AI Tower
For inquiry, we can contact does_not_exist@lycorp.co.jp
복구) For inquiry, we can contact contact______ by email.

거주지는 잘 복구됐지만 휴대폰 번호는 잘 복구되지 않았고, 이메일 주소는 복구 과정에서 삭제됐습니다. 이와 같이 어느 정도 복구되기는 하지만 오차가 발생하는 것을 확인할 수 있었습니다.

두 번째 실험에서는 복구를 30번 반복했습니다.

Sung Woo will be presenting a talk about AI Security at Tech-Verse 2025
복구) Sun Woo will be presenting a talk about AI Security at Tech-Verse 2025
Sungwoo works at LINE+, a subsidiary company of LY Corpotaion
복구) Sungwook works at LINE+, a subsidiary company of LYRC Corporation
My phone number is 040-0836-9126 and I live in Tokyo
복구) My phone number is 0040-8626-06 and I live in Tokyo
We are going to meet at Kioi Tower to discuss future of AI
복구) We are going to meet at Kioi Tower to discuss future of AI.
For inquiry, we can contact does_not_exist@lycorp.co.jp
복구) For inquiry, we can contact @does_not_exist_by_lycorp.jp

두 실험을 비교해 보면 두 번째 실험에서 첫 번째 문장은 원본 문장과 거의 유사하게 복구됐습니다. 이름만 조금 부정확하게 복구됐고, 내용은 완전히 복구된 것을 확인할 수 있습니다. 두 번째 문장도 이름과 회사 이름이 약간 부정확하게 복구되긴 했지만 정확도는 조금 더 높아졌습니다. 휴대폰 번호는 여전히 잘 복구되지 않았고, 거주지는 계속 잘 복구되고 있습니다. 네 번째 문장도 원본 문장과 복구 문장이 정확하게 일치하는 것을 확인할 수 있고, 다섯 번째 문장도 약간의 오류가 있긴 하지만 조금 더 많은 정보를 확인할 수 있었습니다.

이 논문에서는 32 토큰 문장 기준으로 92%의 정확도로 문장 복구에 성공했다고 전합니다. 우리는 임베딩 벡터라는 것은 수치의 나열일 뿐이기 때문에 원본 데이터의 정보량을 충분히 갖고 있지 못할 것이라고 생각하기 쉽습니다. 그런데 실험 결과 위와 같이 꽤 많은 정보를 획득할 수 있었습니다. 따라서 개인 정보와 같은 기밀 수준이 높은 데이터를 RAG에서 이용할 때에는 벡터 자체에 대해서도 그에 준하는 보호 조치가 필요합니다. 또한 인증과 인가 및 벡터 자체에 대한 암호화가 잘 제공되는 벡터 DB를 이용해야 합니다.

이번 글에서는 AI 프로덕트를 개발하면서 마주칠 수 있는 다섯 가지 보안 위협 사례를 소개했습니다. 마지막으로 이와 같은 위협을 막기 위해 저희 팀에서 어떤 업무를 수행하고 있는지 소개하겠습니다.

보안 검수

먼저 보안 검수를 수행하고 있습니다. 저희 팀에서 수행하는 ASDR(App Security Design Review)에서는 제품의 설계상 결함을 확인합니다. 최대한 높은 보안 수준을 일정하게 적용할 수 있도록 위협 모델링을 수행합니다. 또한 보안 평가(security assessment)는 구현이 완료된 코드를 리뷰하며 실제 해커들이 수행하는 공격 방식 그대로 프로젝트의 보안 결함을 찾아냅니다.

MCP 검수

두 번째로 최근 사내에서 개발되고 있는 MCP 마켓플레이스 및 플레이그라운드의 보안을 위해서 MCP 검수를 수행하고 있습니다. 외부 MCP 마켓플레이스 중 하나인 Smithery에도 Invariant Labs사의 MCP 스캐너가 들어가 있지만, MCP 스캐너 같은 경우 외부로 소스 코드를 전송해야 한다는 문제가 있어서 보안을 위해 MCP에서 악성코드와 취약점을 자동으로 찾아내는 툴을 자체 개발해서 제공하고 있습니다. 혹여나 악성 MCP를 실수로 업로드해서 사용하더라도 탐지할 수 있게끔 기술을 개발해 제공하고 있습니다.

사례 조사 및 보안 가이드라인 배포

마지막으로 이번 글의 주제와 같이 여러 사례를 조사하고 최신 연구들을 캐치업해서 보안 가이드라인을 작성하고 배포하는 일을 수행하고 있습니다. 이 글에서는 최근 AI 제품 개발과 관련된 위험을 사례별로 소개했는데요. 이를 조금 더 포괄적인 원칙으로 정리해 준비한 'AI 제품 개발 보안 가이드라인'을 만들었고 곧 배포할 예정입니다.

이 외에도 저희 팀에서는 암호화와 키 관리 등 여러 가지 보안 가이드라인을 제공하고 있습니다.

향후 계획

앞서 프롬프트 인젝션을 막기 위해서는 가드레일을 도입해야 한다고 말씀드렸는데요. 이 가드레일을 어떻게 제공할지 현재 팀에서 연구를 진행하고 있습니다. 또한 안전한 벡터 DB를 정의하고 제공하기 위해서 관련 연구도 진행하고 있습니다. 특히 개인 정보를 다루는 RAG 시스템의 경우에는 원본 데이터와 임베딩 벡터를 모두 잘 보호하는 게 중요한데요. 이를 위해 최상의 해결책을 찾기 위해 노력하고 있습니다.

마치며

이번 글에서는 AI 기술이 발전하면서 새롭게 발생한 보안 위협들을 살펴봤습니다. AI가 기존에는 어려웠던 많은 것들을 가능하게 만들고 있는데요. 이는 공격자들에게도 마찬가지로 유용하게 활용되고 있습니다. 새로운 위협들에 발 빠르게 적응해 사용자들이 더 안전한 일상 생활을 보장받을 수 있도록 노력해 나가겠습니다.

AI 제품 개발 중 마주칠 수 있는 보안 위협 사례와 대책 방안

댓글