모두의 AI, 민원부터 은행 업무까지? 내가 가장 우려하는 것은 해킹 위험이다
모두의 AI, 민원부터 은행 업무까지? 내가 가장 우려하는 것은 해킹 위험이다
정부가 추진하는 ‘모두의 AI’가 내세우는 기능은 상당히 매력적이다. 단순히 질문에 답하는 챗봇을 넘어 민원 신청부터 각종 예약, 행정 업무 처리까지 AI가 대신 수행하도록 하겠다는 구상이다.
은행 업무까지 지원할 수 있다면 어떨까? 사용자가 원하는 일을 설명하기만 하면 AI가 필요한 정보를 찾고, 신청서를 작성하고, 예약을 진행하고, 정해진 절차에 따라 업무를 처리하는 것이다.
이런 서비스가 제대로 구현된다면 국민의 시간과 수고를 크게 줄일 수 있을 것이다. 특히 한국의 법령과 행정 절차, 기관별 시스템에 특화한다면 해외의 범용 AI가 쉽게 따라오기 어려운 영역도 만들어낼 수 있다.
하지만 나는 기능이 얼마나 화려한지보다 한 가지 문제가 더 걱정된다.
국민의 행정과 금융 업무를 대신 처리하는 AI가 공격당한다면, 그 피해는 어디까지 번질 수 있을까?
네이버가 탈락했던 사업과 이번 사업은 구분해야 한다
먼저 관련 사실부터 짚어보자.
2026년 1월, 정부의 ‘독자 AI 파운데이션 모델’ 사업에서 네이버클라우드는 중국 알리바바의 Qwen 모델에서 인코더와 가중치를 활용한 부분 등이 독자성 기준에 부합하지 않는다는 판단을 받아 1차 평가에서 제외됐다. 단순히 중국 모델을 미세조정했다는 이유만으로 탈락했다고 설명하면 정확하지 않다.
이 사업과 ‘모두의 AI’는 별개의 사업이다. 네이버는 모두의 AI 사업에서 탈락한 것이 아니라 참여하지 않기로 했다.
여기서 내가 궁금한 점은 따로 있다. 정부가 독자적인 AI 기술을 확보하는 것도 중요하지만, 국민의 실제 업무를 대신 처리하는 서비스를 만들려면 모델의 성능 외에도 해결해야 할 문제가 많다는 것이다.
AI가 말을 잘하는 것과 행정 업무를 안전하게 실행하는 것은 전혀 다른 문제다.
IP 주소 하나가 곧 해킹은 아니다. 진짜 위험은 연결된 권한이다
내가 특히 우려하는 것은 서버 보안이다.
인터넷에 연결된 서버는 외부에서 접근할 수 있는 주소를 갖는다. 서버의 IP 주소가 알려졌다는 사실만으로 해킹이 가능한 것은 아니다. 방화벽과 접근 제어, 인증, 보안 패치 등이 제대로 적용돼 있다면 IP 주소만으로 침입할 수는 없다.
하지만 문제는 그 서버가 무엇과 연결돼 있느냐다.
일반적인 웹사이트가 공격당하면 게시글 변조, 개인정보 유출, 서비스 중단 등의 피해가 발생할 수 있다. 물론 이것만으로도 심각한 문제다.
그런데 AI 에이전트가 민원 시스템이나 금융 서비스와 연결돼 있고, 그 과정에서 본인 인증 정보나 업무 처리 권한을 갖고 있다면 이야기가 달라진다.
공격자가 AI 서비스의 서버를 장악하거나 인증정보를 탈취하고, 그 서버가 가진 권한을 악용할 수 있다면 단순한 웹사이트 침해를 넘어 다른 시스템까지 피해가 확산될 가능성이 생긴다.
예를 들어 AI가 사용자를 대신해 민원 신청을 제출할 수 있도록 권한을 갖고 있다고 가정해 보자. 공격자가 그 권한을 탈취하거나 AI의 실행 절차를 악용한다면 사용자가 의도하지 않은 신청이나 변경이 발생할 수 있다.
금융 업무라면 피해가 더 직접적일 수 있다. 계좌 조회 권한과 송금 권한은 위험 수준이 다르고, 정보를 읽을 수 있는 권한과 실제 거래를 실행할 수 있는 권한도 엄격하게 구분해야 한다.
물론 실제로 이런 피해가 발생하려면 구체적인 취약점이나 권한 악용 경로가 있어야 한다. AI 서버가 인터넷에 연결됐다는 이유만으로 국가 행정망이 자동으로 뚫리는 것은 아니다.
내가 우려하는 것은 바로 이 연결 구조다.
전국의 행정망과 연결된다면 위험을 보는 기준부터 달라져야 한다
여기서 말하는 행정망은 하나의 거대한 네트워크를 뜻하지 않는다. 기관별로 시스템과 보안 경계가 다르며, 모든 시스템이 서로 직접 연결돼 있는 것도 아니다.
그럼에도 여러 기관의 민원 시스템을 하나의 AI 서비스에서 이용할 수 있도록 연결한다면, 그 연결 지점은 중요한 보안 경계가 된다.
AI가 직접 접근할 수 있는 시스템은 어디까지인가? 어떤 인증정보를 보관하는가? 한 기관에서 발생한 보안 사고가 다른 기관으로 확산되지 않도록 분리돼 있는가?
이 질문에 대한 답이 명확해야 한다.
특히 국민의 개인정보와 행정 기록을 다루는 서비스라면 일반적인 상업용 챗봇보다 훨씬 엄격한 보안 기준을 적용해야 한다. 공격자가 AI를 속여 잘못된 행동을 유도하는 문제, 탈취된 계정이나 인증정보를 이용하는 문제, 외부 시스템의 권한을 악용하는 문제를 함께 고려해야 한다.
AI의 답변이 틀리는 것과 AI가 잘못된 행정 절차를 실제로 실행하는 것은 피해의 성격이 다르기 때문이다.
그렇다면 어떻게 막아야 할까?
AI 서비스가 행정 업무를 수행한다고 해서 모든 시스템에 직접 접근할 수 있도록 만들어서는 안 된다.
첫째, AI 서비스와 행정기관의 핵심 시스템 사이에 명확한 보안 경계를 둬야 한다. AI 서버가 침해되더라도 그 권한만으로 다른 시스템까지 접근할 수 없도록 네트워크와 권한을 분리해야 한다.
둘째, AI에 필요한 최소한의 권한만 부여해야 한다. 민원 정보를 조회하는 기능이 있다고 해서 민원을 임의로 변경하거나 제출할 권한까지 줄 이유는 없다. 조회, 작성, 제출, 취소, 금융 거래 권한을 구분해야 한다.
셋째, 중요한 작업은 사용자의 명시적인 확인을 거쳐야 한다. 신청서 초안을 만드는 것과 실제로 제출하는 것을 분리하고, 송금처럼 금전적 피해가 발생할 수 있는 업무에는 별도의 인증과 승인 절차를 적용해야 한다.
넷째, 모든 실행 기록을 남겨야 한다. 누가 어떤 요청을 했고, AI가 어떤 정보를 사용했으며, 어떤 작업을 실행했는지 추적할 수 있어야 한다. 이상 징후가 발견되면 권한을 즉시 차단하고 피해를 조사할 수 있는 체계도 필요하다.
다섯째, 출시 전에 실제 공격을 가정한 보안 검증이 필요하다. 모델 자체의 안전성만 확인할 것이 아니라 외부 시스템과 연결된 전체 구조를 대상으로 침투 테스트, 권한 오용 테스트, 장애 복구 테스트를 진행해야 한다.
이런 대책이 있다고 해서 위험이 완전히 사라지는 것은 아니다. 다만 AI가 가진 권한과 공격이 성공했을 때의 피해 범위를 제한하는 데 필수적인 조치들이다.
빅테크가 못 해서 안 하는 것일까?
글로벌 빅테크 역시 에이전트 기술을 개발하고 있다. 웹을 탐색하고 여러 단계의 작업을 수행하는 기술도 이미 등장했다.
그렇다고 모든 기업이 정부 민원이나 은행 거래를 제한 없이 대신 처리하도록 허용하는 것은 아니다.
기술적으로 가능한 일과 대규모 서비스에서 안전하게 제공할 수 있는 일 사이에는 차이가 있다. 개인정보 유출, 잘못된 거래, 권한 탈취, 법적 책임과 같은 위험은 서비스의 규모가 커질수록 더 중요해진다.
그렇기 때문에 빅테크가 이런 기능을 전면적으로 제공하지 않는 이유를 기술력 부족 하나로 설명할 수는 없다. 안전성과 책임, 사업 전략, 규제 등 여러 요인이 작용할 수 있다.
국내 서비스도 마찬가지다. 한국의 행정 절차에 특화된 AI를 만드는 것은 충분히 의미 있지만, 특화된 모델을 확보했다고 해서 보안과 책임 문제가 저절로 해결되는 것은 아니다.
나는 기능보다 보안 설계를 먼저 보고 싶다
‘모두의 AI’가 국민 누구나 편리하게 이용할 수 있는 서비스로 자리 잡는다면 환영할 일이다. 복잡한 행정 절차를 줄이고, 필요한 지원 제도를 찾아주며, 반복적인 업무를 대신 처리하는 것은 분명 가치가 있다.
하지만 서비스가 민원 신청을 넘어 예약, 개인정보 조회, 금융 거래까지 처리하게 된다면 그만큼 높은 수준의 검증이 필요하다.
특히 확인하고 싶은 것은 네 가지다.
- AI가 침해당했을 때 다른 행정 시스템으로 피해가 확산되지 않도록 설계돼 있는가?
- 개인정보와 인증정보는 어디에 보관되며, 누가 접근할 수 있는가?
- AI가 사용자의 의도와 다른 작업을 실행했을 때 어떻게 중단하고 복구하는가?
- 잘못된 신청이나 금융 거래가 발생했을 때 누가 책임지고 피해를 구제하는가?
이 질문에 대한 구체적인 답을 확인하기 전에는 화려한 기능 소개만으로 서비스의 안전성을 판단하기 어렵다.
나는 ‘모두의 AI’라는 구상 자체를 부정하려는 것이 아니다. 오히려 국민의 실제 업무를 대신할 AI라면 일반적인 챗봇보다 훨씬 더 높은 기준을 충족해야 한다고 생각한다.
AI가 국민의 일을 대신할수록, AI가 가진 권한은 더 엄격하게 제한돼야 한다.
편리함은 눈에 보이지만 보안 사고의 위험은 평소에 잘 보이지 않는다. 그리고 사고가 발생한 뒤에는 이미 늦을 수도 있다.
모두의 AI가 정말 국민을 위한 서비스가 되려면, 무엇을 대신 처리할 수 있는지뿐 아니라 어떤 일이 있어도 접근해서는 안 되는 시스템이 무엇인지부터 분명하게 밝혀야 한다.
AI Knowledge Hub
댓글 (1개)
글의 방향에 전적으로 동의합니다. 다만 하나 보태자면 — AI 에이전트가 '쏙쏙 빼갈 수 있는 구조'는 구조화된 데이터(JSON-LD, 마크다운 frontmatter)를 의미합니다. 이걸 설계할 때 접근 권한(read-only)을 분리해 두면, AI에게 정보를 열어주면서도 사이트 자체의 쓰기 권한은 침범당하지 않습니다. 구조 설계와 보안 설계를 동시에 생각하면 좋겠습니다.