프로젝트의 배경과 목적
보안 취약점과 사고가 반복되어 사람들이 서비스를 안심하고 이용할 수 없게 된다면, 웹 생태계가 무너질 수 있습니다.
사고 이후에도 피해 복구와 재발 방지 조치가 충분히 이루어지지 않으면, 서비스에 대한 불신은 더 커질 수 있습니다. 이러한 불신이 널리 퍼지면 개별 서비스의 피해를 넘어 웹을 통한 거래와 협업, 새로운 서비스의 성장을 위축시킬 수 있습니다. 보안은 웹 생태계의 신뢰와 지속 가능성을 지키기 위한 기본 조건입니다.
이 프로젝트는 서비스 운영자가 보안을 이해하고 실천할 수 있도록, 보안 관리 방법과 지원 방안을 제안하는 문서 프로젝트입니다. 개발·서버 운영·보안 경험이 적은 사람, AI로 서비스를 만든 사람, 전담 보안 인력 없이 서비스를 운영하는 개인과 소규모 조직을 주요 독자로 삼습니다. 보안에 익숙하지 않은 운영자도 무엇을 확인해야 하는지부터 이해하고, 직접 확인할 수 있는 부분과 도움이 필요한 부분을 구분하며, 필요한 조치를 이어 갈 수 있도록 돕고자 합니다.
최근에는 프런티어 모델을 활용해 오랫동안 사용되고 검토된 소프트웨어에서 기존에 발견하지 못한 취약점을 찾아내는 사례가 이어지고 있습니다. 수십 년 동안 남아 있던 결함을 발견한 연구도 공개됐습니다. 오래 사용했고 지금까지 알려진 사고가 없었다는 사실만으로 앞으로의 안전성을 판단하기는 어렵습니다.
도구를 사용하며 여러 단계의 작업을 이어 가는 AI 에이전트는 방어를 위한 점검과 공격에 모두 활용될 수 있습니다. 이를 활용해 공격 대상을 탐색하고 취약점을 분석하는 작업을 자동화한 사례도 보고되고 있습니다.
국내에서도 생성형 AI를 이용해 여러 업체를 해킹한 사건이 확인됐습니다. 이처럼 AI는 공격에 드는 시간과 비용을 줄이고, 공격 대상을 늘리는 데에도 악용될 수 있습니다.
프런티어 모델은 추론을 통해 대상을 분석하고, 시도 결과에 따라 다양한 공격 방법을 선택하고 조정하는 데에도 활용될 수 있습니다. 방문자가 적거나 규모가 작은 서비스도 이러한 공격의 대상이 될 수 있습니다. 운영자가 특별히 주목받을 만한 서비스를 만들지 않았더라도, 외부에 공개된 시스템에 알려진 취약점이 남아 있다면 공격 시도에 노출될 수 있습니다. 개인 프로젝트나 소규모 서비스에도 점검과 업데이트를 이어 갈 방법이 필요한 이유입니다.
한편 AI의 발전으로 서비스 개발의 기술적 진입장벽도 낮아지고 있습니다. 원하는 기능을 자연어로 설명하고, AI가 작성한 코드를 실행해 본 뒤 필요한 수정을 다시 요청하는 방식이 바이브 코딩으로 알려져 있습니다. 이를 통해 코딩을 모르는 사람도 높은 외주 개발 비용의 부담을 줄이고, 자신에게 맞는 서비스를 직접 만들 수 있습니다.
바이브 코딩을 활용하면 반복해서 하던 자료 정리나 보고서 작성을 자동화하고, 개인이나 소규모 조직에 맞는 도구를 만들며, 새로운 서비스 아이디어를 빠르게 시험할 수 있습니다. 개발 경험이 있는 사람도 제한된 시간 안에 여러 아이디어를 구현하고 수정하는 데 AI를 활용할 수 있습니다.
다만 기능을 구현하고 화면이 정상적으로 동작하도록 만드는 과정만으로 보안 관리까지 갖춰지는 것은 아닙니다. 어떤 정보가 저장되는지, 누가 그 정보에 접근할 수 있는지, 외부에 공개하면 안 되는 값이 코드나 설정에 들어 있지는 않은지 별도로 확인해야 합니다. 개인정보가 노출되거나 접근 권한이 잘못 설정되어 있어도 일반적인 사용 과정에서는 문제가 드러나지 않을 수 있습니다.
직접 서버를 구축하고 운영하는 일이 어려워 AI의 도움을 받아 클라우드에 서비스를 올리는 경우도 있습니다. 클라우드는 외부 업체가 제공하는 서버와 저장소 등을 이용하는 방식으로, 직접 관리해야 할 부담을 줄일 수 있습니다.
클라우드에서도 관리 계정이나 인증정보가 탈취되거나 저장소의 공개 범위와 접근 권한이 잘못 설정되면 정보 유출이나 서비스 침해로 이어질 수 있습니다. 클라우드 제공업체의 기반 시설에서 침해사고가 발생해 서비스가 중단되거나 데이터가 훼손될 수도 있습니다.
처음에는 혼자 쓰려고 만든 도구라도 동료와 공유하거나 고객의 요청을 처리하는 데 사용하면서 다루는 정보와 이용자가 늘어날 수 있습니다. 임시로 만든 프로그램이 계속 사용되고, 충분한 검토 없이 실제 업무에 필요한 도구로 자리 잡을 수도 있습니다. 달라진 사용 범위에 맞춰 보안 설정과 관리 방법도 다시 확인할 수 있도록 안내할 필요가 있습니다.
이러한 어려움은 개발 경험이 적은 사람에게만 해당하지 않습니다. 하나의 서비스는 직접 작성한 코드 외에도 여러 구성 요소가 연결되어 동작합니다. 여기에는 운영체제와 그 핵심 부분인 커널, 프로그램을 실행하는 환경, 데이터 저장소와 클라우드 기반 시설 등이 포함됩니다. 개발의 기본 틀을 제공하는 프레임워크와 필요한 기능을 가져다 쓸 수 있는 라이브러리도 구성 요소에 해당합니다. 경험이 있는 개발자도 이 모든 구성 요소의 내부를 직접 검토하기는 어렵습니다.
가져다 쓴 구성 요소가 다른 구성 요소를 사용하는 경우도 많습니다. 개발자가 직접 선택하지 않은 부분까지 여러 단계에 걸쳐 포함되는 것입니다.
겉으로 사용하는 기술의 이름만 알아서는 내부에 무엇이 포함되어 있는지, 새로 발견된 취약점이 어디에 영향을 주는지 파악하기 어렵습니다. 운영자가 직접 관리하는 부분과 외부 서비스 제공자가 관리하는 부분을 구분하고, 문제가 생겼을 때 누가 무엇을 확인해야 하는지도 알아야 합니다.
오래 운영한 시스템에는 다른 어려움도 있습니다. 퇴사·이직이나 담당자 교체를 거치면서 전체 구조와 변경 이유를 아는 사람이 남아 있지 않을 수 있습니다. 외주로 제작한 시스템을 인수하거나 여러 사람이 나누어 관리하는 경우에도 필요한 정보가 흩어질 수 있습니다. 기록이 부족하다면 이후 담당자는 현재 상태를 파악하는 일부터 시간을 들여야 합니다.
개발 당시에는 알려지지 않았던 취약점이 나중에 발견될 수 있으므로, 서비스를 변경하지 않았더라도 확인과 조치가 필요할 수 있습니다. 같은 프로그램을 사용하더라도 버전이나 설정, 외부에 공개된 기능에 따라 영향을 받는 조건이 달라집니다. 보안 공지가 있다는 사실을 아는 것과 그 공지가 자신의 서비스에 해당하는지 판단하는 것은 별도의 일입니다.
운영자에게는 “내 서비스에도 해당하는가”, “무엇을 먼저 확인해야 하는가”, “직접 조치할 수 있는가, 다른 담당자의 도움이 필요한가”를 판단할 정보가 필요합니다. 여러 시스템의 공지를 반복해서 확인하고 현재 구성과 비교하는 작업은 관리 부담으로 이어집니다. 보안 패치, 즉 취약점을 고치는 업데이트가 나와도 이를 모르거나 적용 여부를 판단하지 못하면 실제 조치가 늦어질 수 있습니다.
AI와 자동화는 이러한 반복 확인을 보조할 수 있습니다. 새로 알려진 취약점과 운영 중인 시스템의 정보를 비교하고, 영향을 받을 가능성이 있는 부분과 사람이 추가로 확인해야 할 부분을 정리하도록 돕는 것입니다. 이 프로젝트는 운영자가 보안 공지를 이해하고 필요한 조치를 판단할 수 있도록 돕는 방안을 초안으로 제안하고, 함께 검토하고 논의하고자 합니다.
조치에는 기술적인 판단 외에도 시간과 비용, 담당자의 협조가 필요합니다. 업데이트를 위해 서비스 중단 시간을 정하거나, 변경 후 기능이 정상적으로 동작하는지 확인하고, 문제가 생겼을 때 되돌릴 준비를 해야 할 수 있습니다. 운영자가 의사결정권자에게 조치의 필요성과 미뤘을 때의 영향을 설명하고, 필요한 인력과 시간을 확보할 수 있도록 돕는 일도 지원의 범위에 포함됩니다.
AI로 서비스를 만든 운영자는 보안 점검도 AI에 요청할 수 있습니다. 이때 점검 결과를 어디까지 믿을 수 있는지 판단할 기준이 필요합니다.
AI를 점검에 활용할 때는 가능한 작업과 한계도 분명히 해야 합니다. 모델마다 능력이 다르고, 제공되는 자료와 사용할 수 있는 도구에 따라서도 결과가 달라집니다. AI 제공업체의 이용 정책과 안전 제한에 따라 일부 요청이나 도구 사용이 제한될 수 있으므로, 점검 대상에 대한 권한과 해당 서비스에서 허용하는 작업 범위를 함께 확인해야 합니다.
“취약점을 찾아 주세요”라는 요청만으로는 무엇을 어디까지 확인해야 점검을 마친 것으로 볼 수 있는지가 분명하지 않습니다. AI가 눈에 띄는 항목 몇 가지를 살펴보고 답변을 작성했더라도, 필요한 점검이 모두 수행됐다고 볼 수는 없습니다.
점검할 대상과 항목, 완료로 볼 조건을 정하고 결과를 검토할 절차를 마련할 필요가 있습니다. 이를 처음부터 정하기 어려운 운영자도 참고할 수 있도록, 상황별 확인 질문과 판단 기준을 안내해야 합니다. 혼자 판단하기 어려운 결과를 검토받을 경로도 함께 제시할 필요가 있습니다.
시간과 자원 사용도 함께 고려해야 합니다. 토큰은 AI가 읽고 생성하는 내용의 양을 세는 단위이며, 자료와 검사 결과를 더 많이 처리할수록 필요한 시간과 비용이 늘어날 수 있습니다.
다만 토큰 한도를 넉넉히 설정했다고 해서 AI가 점검을 더 오래 이어 가거나 더 충실한 결과를 내는 것은 아닙니다. 종료 조건이 불분명하면 추가 확인이 필요한 상태에서도 일부 결과만 제시하고 작업을 마칠 수 있습니다.
따라서 사용할 수 있는 시간·토큰·비용의 한도와 계획한 점검을 완료했다고 볼 조건을 구분해야 합니다. 한도에 도달하거나 자료 부족, 도구 오류 등의 이유로 중단했다면 중단 사유와 미확인 항목을 남겨야 합니다. 이후 담당자가 남은 작업을 파악하고 이어 갈 수 있어야 합니다.
자료와 도구, 권한, 작업 순서와 종료 조건을 연결해 AI가 작업을 이어 가도록 돕는 실행 환경을 하네스라고 부르기도 합니다. 이런 환경을 마련할 때에도 운영 목적과 허용된 권한에 맞게 구성하고, AI가 수행한 작업을 사람이 검토할 수 있도록 해야 합니다.
이 프로젝트에서는 점검에 필요한 자료·권한·작업 순서·완료 조건을 정하는 데 도움이 되는 설명과 절차를 다룹니다. 구체적인 도구 구성과 상세 기술 설계는 개별 운영 환경에서 검토할 사항으로 남깁니다.
외부 인터넷과 분리된 환경에서는 내부 서버에서 AI를 실행해 점검을 보조하는 방안도 고려할 수 있습니다. 외부 자료를 바로 검색하기 어려운 만큼, 확인에 필요한 자료를 제공하고 새로운 보안 정보에 맞춰 갱신하는 절차가 필요합니다. 모델이 이미 알고 있는 내용만으로 최신 상황까지 확인했다고 판단해서는 안 됩니다.
자료는 운영자가 이해하고 판단할 수 있는 형태여야 합니다. 전문 용어의 뜻을 풀어 쓰고, 취약점의 영향을 받는 조건과 필요한 조치의 의미를 쉬운 한국어로 설명할 필요가 있습니다. 각 점검 항목이 무엇을 확인하려는 것인지, 확인을 어디서 시작할 수 있는지, 직접 판단하기 어려울 때 누구에게 도움을 요청할 수 있는지도 함께 안내할 필요가 있습니다. 안내한 점검 방법이나 조치를 적용할 수 없는 경우와 추가 확인이 필요한 상황도 함께 밝혀야 합니다. 사람과 AI가 같은 자료와 기준을 참고할 수 있도록 정리하면, 확인 과정에서 생기는 혼선을 줄이는 데 도움이 될 수 있습니다.
점검 결과를 전달하는 방식도 중요합니다. AI의 내부 추론은 모델과 서비스에 따라 공개 범위가 다르며, AI가 제시한 판단 설명이나 근거에도 오류가 있을 수 있습니다. 설명이 자세하거나 자신 있게 작성되어 있다는 이유만으로 실제 점검이 수행됐거나 결과가 정확하다고 판단해서는 안 됩니다.
어떤 자료를 어디까지 확인했는지, 어떤 검사를 실제로 실행했는지, 그 결과가 무엇이었는지를 작업 기록으로 남길 필요가 있습니다. 자료를 읽고 추정한 내용과 검사 도구로 확인한 결과를 구분하고, 확인하지 못한 부분과 사람이 추가로 검증해야 할 항목도 표시해야 합니다.
“문제를 찾지 못했다”는 결과는 이러한 확인 범위와 근거 안에서 해석해야 합니다.
운영자가 가진 지식과 관리 여건은 서로 다릅니다. 필요한 정보를 찾고 이해하는 일부터 담당자에게 확인하고 조치를 이어 가는 일까지, 각 단계에서 필요한 지원도 달라집니다.
이 프로젝트는 이 과정에서 막히는 부분을 살펴보고, 누구나 참고하고 보완할 수 있는 보안 관리 방법과 지원 방안을 제안하고자 합니다. 제안은 실제 운영 환경에 맞춰 검토하고 고쳐 나갈 초안이며, 이용자 보호와 지속적인 보안 관리에 도움이 되는 자료를 만드는 것이 이 프로젝트의 목적입니다.