← 목록으로

AI에 대한 고찰과 보안업계의 한계

[AI] AI 보안 · 작성: 2026-10-15 15:26:32 · 수정: 2026-10-16 11:47:30 · 조회 84

목차

이 글은 대한민국만이 아니라 전 세계 보안 업계가 겪고 있는 고충, 그리고 하루가 다르게 발전하는 AI와 그에 따라 더 무거워진 보안의 의미를 정리해 보려고 쓴다.

1. 영화 속 해커와 현실의 보안#

보안이라고 하면 사람들은 어두운 방에서 키보드를 두드리며 순식간에 서버를 뚫는 장면을 떠올린다. 현실의 보안은 그런 모습과 거리가 멀고, 대부분의 사람은 자기 계정이나 개인정보가 침해당한 뒤에야 그 중요성을 체감한다. 그때 나오는 질문이 있다. 왜 방어를 제대로 하지 못했는가.

이 질문은 정당하다. 보안은 지켜야 하는 일이고, 지키지 못했다면 업계가 먼저 돌아봐야 한다. 그래서 이 글은 "어쩔 수 없었다"를 말하려는 글이 아니다. 왜 이런 일이 반복되는지, 업계 안에서는 무엇이 모자란지 짚어보려는 글이다.

우선 보안이라는 이름 아래 하는 일이 생각보다 다양하다. 전문 보안업체와 계약하고, 개인정보보호법과 정보통신망법 같은 법령을 해석해 사규에 제대로 반영했는지 점검하는 일이 있다. 들어오는 공격을 탐지하고 보고하는 체계를 만드는 일도 있고, 직접 공격을 수행해 어디가 취약한지 확인하는 일도 있다. 공격의 메커니즘을 분석해 정상 사용자의 신호와 공격자의 신호를 구분하는 일이 있고, 랜섬웨어 같은 파일 암호화 공격에 빠르게 대응하는 연구도 있다. 이 밖에도 수십 가지 분야가 있다.

문제는 이 일들이 하나로 이어져 있어야 방어가 완성된다는 점이다. 법령 해석, 탐지, 점검, 대응 중 어느 하나라도 비어 있으면 공격자는 그 틈으로 들어온다. 밖에서는 보안을 한 덩어리로 보지만, 안에서는 각자 자기 영역만 보다가 영역 사이의 틈을 놓치는 경우가 많다. 사고가 났을 때 업계가 받는 비판의 상당 부분은 이 틈에 대한 것이고, 그 비판에서 우리가 자유로울 수는 없다.

2. 돈을 쓰는 직군이라는 낙인#

그런 구조에서 보안은 "돈을 벌어오는 직군"이 아니라 "돈을 쓰는 직군"으로 취급받는다. 틀린 말만은 아니다. 보안을 잘해 놓는다고 해서 매출이 오르지는 않으니, 회사 입장에서는 굳이 보안에 많은 인력을 둘 이유가 없어진다. 잘 막으면 아무 일도 없었던 것처럼 보이고, 못 막았을 때만 이름이 나온다. 성과가 눈에 보이지 않으니 예산은 사고가 난 뒤에야 늘어나고, 그 전에는 비용으로만 분류된다. 이것이 보안 업계가 오랫동안 안고 있던 한계다.

3. 바이브 코딩이 바꿔놓은 것#

그런데 최근 이 한계를 더 키우는 변화가 생겼다. 바이브 코딩이 등장하면서 프로그램을 만드는 문턱이 크게 낮아졌고, 많은 서비스와 도구가 빠르게 시중에 나오고 있다. 만드는 사람이 늘어난 것은 좋은 일이다. 다만 AI가 짜준 코드를 그대로 배포하는 경우가 많아지면서, 입력값 검증이나 인증 처리 같은 기본적인 부분이 빠진 채 공개되는 서비스도 같이 늘어난다. 코드를 직접 이해하지 못한 채 배포하면 취약점이 어디에 있는지 만든 본인도 알기 어렵다.

공격하는 쪽도 같은 도구를 쓴다. AI를 이용해 취약점을 찾고 공격 코드를 만드는 사람이 생기고 있고, 예전에는 상당한 경험이 있어야 가능했던 일의 진입 장벽이 낮아지고 있다. 취약한 서비스가 쏟아지는 속도와 그것을 노리는 속도가 같이 빨라졌는데, 보안이 이 속도를 따라가고 있는지는 솔직히 의문이다. 내가 이 글을 쓰게 된 이유가 이것이다.

4. 공격하는 쪽의 한계#

먼저 공격자 관점(Offensive) 보안의 문제부터 보자. 가장 근본적인 문제는 공격 표면(attack surface)이 너무 다양하다는 것이다. 시스템적인 보안을 최대한 갖춰 놓았다고 해도 공격자는 거기서 멈추지 않는다. 연동된 third-party 서비스, 물리적인 침투, 사람을 속이는 사회공학(social engineering)처럼 소프트웨어 바깥의 경로까지 시도해 보고, 어디가 약한지 하나하나 드러내야 진짜 점검이라고 할 수 있다. 실제 공격자는 가장 단단한 문을 두드리지 않고 가장 약한 쪽으로 들어오기 때문이다.

문제는 이 모든 것을 점검하려면 시간과 사람이 많이 든다는 점이다. 모의해킹이나 점검은 기간이 정해져 있고 인건비가 크게 들기 때문에, 기업 입장에서는 부담스러운 비용이 된다. 그래서 정부가 지정한 인증심사나 법정 점검만 받고 넘어가는 곳이 적지 않다. 인증은 정해진 항목을 충족했는지 확인하는 체계라서, 항목에 없는 경로나 여러 약점을 엮어 들어오는 공격은 걸러내기 어렵다. "인증을 받았다"가 "안전하다"로 읽히는 순간 점검은 형식이 되어 버린다.

기간이 정해져 있다는 것은 점검의 질에도 영향을 준다. 공격자는 시간 제한 없이 몇 달이고 한 서비스를 파고들 수 있지만, 점검하는 사람에게는 몇 주가 주어지고 그마저 범위(scope)가 정해져 있다. 운영 중인 서비스에 영향을 주면 안 되니 위험한 시도는 빼야 하고, 계약 범위 밖의 third-party는 아예 건드릴 수 없다. 낮은 위험도로 보이는 취약점 여러 개를 엮어 큰 사고로 이어가는 연쇄 공격은 시간이 가장 많이 필요한 영역인데, 이런 부분이 가장 먼저 잘려 나간다. 점검 결과는 그 시점의 스냅샷일 뿐이라서, 보고서를 받은 다음 날 코드가 바뀌면 이미 다른 시스템이 된다.

점검하는 사람 자신의 부담도 있다. 새로운 기술이 나올 때마다 매주 새로 공부해야 하고, 웹과 클라우드, 모바일에 이어 AI 모델과 에이전트까지 대상이 계속 넓어지는데 정립된 방법론이 아직 없는 영역도 많다. 취약점을 찾아 보고해도 개발 일정에 밀려 조치가 안 되고 보고서만 쌓이는 경우도 있다. 연구자 입장에서는 허가 없이 시도하면 법적 위험이 있어서, 합법적으로 시도해 볼 수 있는 무대(버그바운티, 계약된 점검)가 한정적이라는 점도 한계다.

5. 방어하는 쪽의 한계#

방어자 관점(Defensive)에서는 상황이 더 팍팍하다. 며칠 간격으로 새로 등록되는 CVE를 확인해서 우리 환경에 해당하는지 판단해야 하고, 동시에 위협 행위자들이 어떤 방식으로 움직이는지 분석해 그에 맞는 대응책을 마련해야 한다. 거기에 현재 체계의 부족한 부분을 개선할 준비도 같이 해야 한다.

여기에 AI가 변수를 하나 더 얹었다. 예전에는 어색한 번역투 때문에 걸러지던 피싱 메일이 이제는 자연스러운 한국어로 들어오고, 같은 악성코드도 조금씩 변형을 만들어 내기 쉬워져서 시그니처 기반 탐지가 점점 덜 통한다. 방어 쪽에서도 AI로 로그를 요약하고 경보를 분류하려는 시도가 있지만, 그 결과를 그대로 믿을 수는 없어서 결국 사람이 다시 확인해야 하고, 그 확인에 쓸 사람은 늘 부족하다. 공격자는 한 곳만 뚫으면 되지만 방어자는 모든 곳을 지켜야 하는데, 그 비대칭이 AI 때문에 더 벌어지고 있다.

6. 그럼에도 AI를 먼저 익혀야 하는 이유#

그럼에도 필자는 20~30대 취준생이나 현업자라면 AI를 더 빠르게 습득해야 한다고 생각한다. AI가 나온 뒤 가장 크게 타격을 입은 직군의 신입 채용 공고를 보면 흐름이 보인다. 채용 건수 자체가 줄었고, 요구하는 능력도 달라졌다. 예전처럼 특정 언어나 도구를 다룰 줄 아는지를 보는 것이 아니라, 한 문제를 얼마나 깊게 파고들 수 있는지, AI를 얼마나 잘 활용해 봤는지, 그걸로 무엇을 직접 만들어 봤는지를 본다. 기술 하나를 익히는 일은 AI가 대신해 주기 시작했으니, 사람에게 남는 것은 질문을 던지는 깊이와 도구를 다루는 감각이다.

보안도 다르지 않다. 공격자가 AI로 속도를 올리는데 점검하는 사람이 수작업으로만 버티면 격차는 벌어질 뿐이다. 반대로 CVE 선별, 로그 분석, 반복적인 점검 항목을 AI에 맡기고 사람은 연쇄 공격이나 범위 밖 경로처럼 시간이 가장 많이 드는 곳에 집중할 수 있다면, 앞서 말한 한계 중 몇 가지는 줄일 수 있다. 결국 AI를 두려워할 것이 아니라 먼저 익혀서 그 속도를 우리 쪽으로 가져와야 한다. 한때 IT 강국이라 불리던 이 나라가 그 이름을 다시 찾으려면, 지금 이 전환기에 서 있는 사람들이 AI를 얼마나 빨리 자기 것으로 만드느냐에 달려 있다고 본다.

7. 맺으며#

공격과 방어 양쪽 모두 따라가기 바쁜 구조이고, 그 속도를 AI가 더 끌어올리고 있다. 보안을 비용으로만 보는 시선이 바뀌지 않으면 이 격차는 줄어들기 어렵다. 하지만 같은 AI가 그 격차를 좁히는 도구이기도 하다. AI를 쓰는 사람이 늘수록 보안은 선택이 아니라 기본 조건이 되어야 하고, 그 기본을 지킬 사람은 AI를 먼저 익힌 사람이 될 것이다. 이 글이 그 이야기를 시작하는 데 작게나마 보탬이 되었으면 한다.

댓글 0

아직 댓글이 없습니다.

마크다운 지원 · 최대 3,000자

AI 보안 카테고리의 글 (9/9)

  1. Prompt Injection: LLM 애플리케이션의 새로운 공격 표면
  2. OWASP LLM Top 10: LLM 애플리케이션 취약점 한눈에 보기
  3. AI 모델 공급망 공격: 신뢰할 수 없는 모델 파일의 위험
  4. Adversarial Examples: 사람 눈에는 안 보이는데 AI는 속는 입력
  5. 모델 추출과 멤버십 추론: AI 서비스에서 새어 나가는 것들
  6. AI 오케스트레이션(멀티 에이전트)의 보안 문제
  7. LLM 탈옥(Jailbreak) 기법과 방어
  8. RAG와 하네스 엔지니어링: 검색 증강 생성 파이프라인을 감싸는 실행 스캐폴드
  9. AI에 대한 고찰과 보안업계의 한계
← RAG와 하네스 엔지니어링: 검색 증강 생성 파이프라인을 감싸는 실행 스캐폴드