핀다 정보보안 l 해커보다 먼저 보는 AI 파수꾼
최종 수정일: 9월 4일
여러분은 현재 거주 중인 집에 문이 몇 개 있는지 알고 계실 겁니다. 이런 가정을 해볼까요? 우리 집 현관문이 하나만 있다고 생각했는데, 어느 날 창고와 지하에 문이 하나씩 더 있다는 걸 알게 됐다면 어떨까요? 더구나 그 문이 언제 생겼는지, 지금도 열려 있는지 아무도 모른다면요?
디지털 환경도 이와 비슷합니다. 서비스를 운영하다 보면 새로운 서버가 불쑥 생기고 도메인이 추가되면서 이전에 볼 수 없던 테스트 환경이 조성되곤 합니다. 클라우드에서는 이런 변화가 특히 빠르죠. 어제 없던 자산이 오늘 생기거나 기존에 닫혀 있던 포트가 다시 열릴 수도 있습니다.
핀다 정보보안팀의 ‘ASM(Attack Surface Management) 프로젝트’는 바로 여기서 출발합니다.
💬ASM이란, 외부에 노출된 모든 디지털 접점(도메인·IP·API·웹 주소)을 실시간으로 확인하고 위험을 점검하는 보안 관리 체계입니다.
ASM은 쉽게 말해 ‘바깥세상에서 핀다가 어떻게 보이는지’ 확인하는 시스템입니다. 외부에 노출된 서버와 IP, 도메인, 웹 엔드포인트 등을 찾아내고 스캔한 뒤 그 결과와 이력을 쌓죠. 취약점 정보와 비교해 위험 가능성까지 짚어냅니다. 이미 상용화한 ASM 툴이 많지만, 핀다 보안팀은 ‘바이브 코딩’ 기반으로 필요한 기능을 직접 정의하고 사내 환경에 맞는 시스템을 만들었습니다.
정보보안팀 천성민 님에게 ASM 프로젝트 이야기를 들어봤습니다.
🎤직접 보안 시스템을 구축했다니 대단해요!
성민: 감사합니다. 사실 처음부터 ‘만들 수 있다’고 자신했던 건 아니었어요. 가장 큰 장벽은 개발 자체가 아니라 지속적인 유지보수였어요. 전문 인력과 시간이 필요한 데다, 구축하더라도 이후 누가 관리할지가 문제였죠. 인공지능(AI)을 모듈 단위의 개발 파트너로 활용하면서 이 벽을 상당 부분 허물 수 있었어요. 보안팀의 도메인 지식을 바탕으로 프론트엔드부터 백엔드까지 직접 구현했고 ‘바이브 코딩’으로 속도감 있게 결과물을 만들어낼 수 있었습니다.
🎤프로젝트에 착수한 계기가 궁금한데요.
성민: 핀다는 아마존웹서비스(AWS) 기반 클라우드를 쓰는데, 인터넷데이터센터(IDC) 중심의 온프레미스와 달리 가상 서버가 눈 깜짝할 새 수십 대씩 생겼다 사라져요. ‘우리가 지금 자산을 제대로 알고 있는지’를 자문하는 데서 시작했어요. AWS와 온프레미스를 함께 운영하다 보니 외부에서 실제로 어디까지 접근 가능한지, 어떤 서비스가 열려 있는지조차 정확히 파악하지 못하고 있더라고요. 특히 외부 접근이 차단돼야 할 개발·테스트 목적의 스테이징 환경이 별다른 이유 없이 열려 있기도 했죠.
이런 현황을 한 번이 아니라 주기적으로 점검하는 체계가 필요하다는 게 출발점이었어요. 그렇다고 곧바로 외부 솔루션을 구독하기보다는 핀다의 운영 환경을 정확히 반영할 전용 시스템을 만드는 방향을 잡았죠.
🎤개발 과정을 구체적으로 소개해 주세요.
성민: 먼저 핵심 백엔드와 스캐너 로직의 구현 방향을 정했어요. 무엇을 확인해야 하는지 정하는 일로, 크게 두 갈래였죠. 하나는 네트워크 계층 점검입니다. 보안관제시스템(SIEM)에 모아둔 핀다 AWS 자산 정보를 가져와 IP가 살아 있는지 확인하고, 전체 포트(1~65535)를 하나하나 스캔합니다. 열려 있는 포트에서 어떤 서비스가 돌고 있는지까지 식별하죠.
집에 비유했듯 사람이 사는지 확인하고 문을 전부 두드려 어느 문이 열리는지 세어본 뒤 그 문이 현관문인지 창고 문인지 알아내는 순서죠. 두드렸을 때 응답이 온다는 건 그 자체로 외부에서 접근이 가능하다는 뜻이죠. 이것만으로도 ‘외부에서 어디까지 접근 가능한가’에 대한 답을 얻을 수 있습니다.
다른 하나는 웹 엔드포인트 점검입니다. AWS WAF에 남은 접근 기록에서 실제로 호출된 URL을 추출해 점검 대상으로 삼습니다. 문을 두드리는 데 그치지 않고, 그 안으로 들어가 어떤 방까지 닿는지 확인하는 셈이죠. 핀다는 하나의 도메인 아래 경로별로 서로 다른 서비스가 붙어 있어서 이 부분이 특히 중요했습니다.
보안팀이 잘 아는 영역이라 빠르게 우선순위를 정할 수 있었죠. 이 점검 결과를 기록해 두는 뒷단 역시 함께 만들었습니다. 손님의 주문을 받는 직원(백엔드), 순서대로 일을 소화하는 주방(작업 큐), 결과를 적어두는 장부(데이터베이스)를 갖추는 작업으로, 요구사항이 명확했던 만큼 AI를 활용해 빠르게 만들 수 있었어요.
🎤AI를 곁에 두더라도 비개발자로서 쉽지 않은 여정이었을 것 같아요.
성민: 핀다에 어떤 보안이 필요한지는 보안팀이 가장 잘 알고 있었기 때문에 직접 정의하고 구조화하는 건 어렵지 않았어요. 다만 UI·UX 대시보드를 만들고 내부 시스템을 연동하는 데는 유독 애를 먹었죠. 앞서 만든 기능들을 직접 보고 다룰 수 있는 화면, 식당으로 치면 메뉴판이나 카운터에 해당하는 부분을 만드는 작업이었어요. 위험을 한눈에 파악하기 좋은 구성에는 정답이 없다 보니 계속 들여다보며 다듬어야 했어요.
동시에 이미 만들어 둔 자산 목록 시스템(CMDB)과 ASM을 연결하는 작업도 진행했어요. 사람이 손으로 서버 수를 입력하지 않아도 자동으로 정보를 가져오도록 두 시스템을 연결한 거예요. 여기에 기존에 쓰던 로그 시스템(Splunk)과도 연결해 점검 결과를 원래 보던 화면에서도 함께 확인할 수 있게 했죠.
🎤CMDB. 다소 생소한 개념인데, 부연 설명 부탁드려요!
성민: CMDB는 일종의 핀다 자산 저장소예요. ASM과 헷갈리기 쉬운데, CMDB가 어떤 자산을 운영하는지 정리하는 창고라면, ASM은 그 자산이 외부에서 어떻게 보이고 있는지 계속 확인하는 역할이죠. 이 CMDB도 팀에서 자체적으로 만든 시스템이에요. AWS 환경은 변화가 정말 빨라서 어제 없던 인스턴스나 공인 IP가 수시로 생겨요. 이런 변화를 주기적으로 API로 가져와 정리할 필요가 있어, CMDB를 구성해 Splunk 앱 형태로 운영하고 있습니다.
CMDB가 하루 한 번 AWS 자산 정보를 가져와 Splunk에 쌓아두면, ASM은 그 안에서 외부에 공개적으로 접근할 수 있는 IP를 후보로 올립니다. 앞서 언급한 스캐너가 SIEM에서 자산을 가져오는 흐름이죠. 중요한 건 CMDB에서 넘어왔다고 ASM이 바로 자동 스캔하진 않는다는 점이에요. 운영자가 후보를 검토·승인해야 관리 대상에 포함되죠. CMDB가 ‘우리가 뭘 가졌는지’에 대한 재고 목록이라면, ASM은 그 재고 중 바깥으로 난 창문이 잘 잠겨 있는지 점검하는 활동인 셈이죠.
확인 항목을 정하고 뒷단을 만드는 데 1~2주, 화면을 다듬고 다른 시스템과 연결해 실제로 쓸 수 있는 형태가 되기까지는 한 달 정도 걸렸어요. 현재는 사람이 개입하지 않아도 하루에 한 번 이상 AWS와 온프레미스 자산, 웹사이트 주소 등을 순찰하듯 둘러봅니다. 필요한 기능이 생기면 화면에 추가하고 있어요.
🎤이 프로젝트를 통해 핀다가 얻게 되는 이점이 있을까요?
성민: 우선 비용 절감 효과가 확실해요. IP 256개를 대상으로 하는 스캐닝 라이선스가 연간 2,500만~3,000만 원, 저렴한 제품도 1,000만~1,500만 원 수준이고 매년 구독을 갱신해야 해요. 도메인 수 기준으로 과금하는 SaaS는 벤더가 대부분 관리까지 대신해 주는 만큼 이보다 더 비싸죠. 이를 고려하면 매년 최소 1,000만 원에서 많게는 억 단위까지 절감하는 셈이죠.
아울러 핀다 환경에 맞춘 정밀한 점검 체계를 마련할 수 있었어요. 핀다는 하나의 도메인 아래 여러 URL 경로가 서로 다른 서비스로 연결되는 구조인데 일반적인 스캔 솔루션도, 무료 ASM 서비스도 도메인 단위까지만 점검할 뿐 이 경로까지는 따라가지 않아요. 핀다 내부 사정을 모르니까요. 핀다에선 경로 하나하나가 곧 리스크라, 저희 환경에 맞게 추가로 구현했죠.
가장 큰 성과는 하나의 정보보안 생태계를 구성했다는 점이에요. 원래 CMDB, ASM, SIEM 각각 따로 구독해야 했는데, 핀다는 이 셋을 자체 개발해 서로 연동했어요. CMDB가 매일 가져온 자산 정보로 ASM이 스캔하고 여기서 나온 취약점 정보는 다시 보안 사고 모니터링에 활용되는 식이죠. 상용 도구를 개별 구매했다면 기대하기 어려웠을 연결 체계입니다.
실제로 발견한 것들도 있습니다. 지금 등록된 자산은 91개 정돈데, 대부분 AWS이고 사무실 공인 IP나 온프레미스 자산도 포함돼 있어요. 흥미로운 건 HTTP 상태 코드상 보통 접속이 정상이면 200이 뜨는데, 404(Not Found)도 결국 서버가 응답을 준 것이라 접근이 됐다는 뜻이거든요. 원래대로면 조용히 드롭되거나 타임아웃돼야 할 요청이 그렇지 않은 경우가 있었어요. 이런 디테일까지 잡아내는 게 꼭 필요한 점검이었습니다.
🎤시장 상황은 어떤가요?
성민: 상용 솔루션에 의존하거나 핀다처럼 자체 구축하는 흐름이 공존하고 있어요. 솔루션 대부분이 범용으로 설계돼 URL 경로 단위 점검처럼 필요한 기능을 추가하려면 벤더사의 개발을 기다려야 하는 한계가 있어요. 가격대도 다양하고요. 지속적인 운영이 필요한 핀다에는 결국 엔터프라이즈형을 써야 하죠. 반면 빅테크처럼 엔지니어링 역량이 강한 기업들은 필요한 도구를 직접 만들어 쓰는 사례가 늘고 있고, 그런 경험이 많은 조직일수록 AI로 필요한 기능을 빠르게 구현할 수 있다는 게 경쟁력입니다.
핀다 역시 스타트업이자 핀테크 기업으로서 ‘핸즈온(hands-on)’ 경험이 축적돼 있다는 점이 자체 구축에 유리하게 작용했습니다. 물론 상용 솔루션은 글로벌 위협 인텔리전스나 대규모 자산 자동 발견 등 장점이 있지만, 핀다처럼 내부 환경을 세밀하게 반영하고 빠르게 기능을 개선해야 하는 조직에선 자체 구축이 더 적합할 수 있어요.
🎤향후 어떻게 고도화할 예정인지 설명해 주세요.
성민: 크게 네 방향으로 모색 중입니다.
첫째, 발견 범위 확대입니다. 지금은 등록된 대상과 승인된 후보 중심으로 운영하는데, 앞으로는 인증서 투명성 로그·도메인네임서버(DNS) 정보 같은 외부 정보원을 활용해 노출 후보를 더 넓게 찾아낼 계획입니다. 새로 발급된 인증서에서 핀다 관련 서브 도메인을 찾거나, WAF 접근 로그에서 공식 문서에 없는 관리자 경로나 레거시 API 경로를 후보로 분류하는 식이죠.
둘째, 취약점 정보 연계 고도화입니다. 지금도 미국 취약점데이터베이스(NVD), 사이버인프라보안국(CISA) 악용취약점(KEV), 국제사이버사고대응포럼(FIRST) 악용예측점수(EPSS) 등과 대조하는 흐름이 작동하고 있습니다.
💬NVD란 미국 국립표준기술연구소(NIST)가 운영하는 취약점 데이터베이스로 전 세계에서 보고되는 소프트웨어 취약점(CVE)에 심각도 점수(CVSS) 등 분석 정보를 붙여 정리해 놓은 이 분야의 가장 기본이 되는 목록입니다.
💬CISA KEV란, CISA가 운영하며 NVD에 등록된 수많은 취약점 중 실제 해커가 악용한 사례가 확인된 것만 추려놓은 목록입니다.
💬FIRST EPSS란, 보안 대응 전문가들의 국제 협의체인 FIRST가 만든 지표로 특정 취약점이 앞으로 실제로 악용될 확률을 0~1 사이 점수로 예측해 보여줍니다.
여기에 제품·버전 식별 표준(CPE) 정규화와 오탐 억제를 강화하고 깃허브 오픈소스취약점(Advisory·OSV) 같은 추가 정보원도 연계하려 합니다. 기계가 자동으로 판정하는 게 아니라 보안팀이 판단할 근거를 더 풍부하게 제공하는 방향이에요. 이와 함께 새로 노출된 포트나 인증서·웹 응답 변화를 추적하는 변경 탐지 고도화도 함께 준비하고 있어요.
셋째, 운영 편의성 개선입니다. 중요한 변화가 감지되면 슬랙·이메일로 알리는 기능, 월간 정기 리포트, 자산 중요도 표시나 조치 상태 관리 기능 등을 계획하고 있습니다. 넷째, 노출 자산에 대한 조치 체계 확립입니다. 지금은 발견·알림까지가 중심인데, 앞으로는 노출 건마다 담당자와 조치 기한을 지정하고 재스캔으로 차단을 검증한 뒤에야 종료되는 흐름을 담으려 합니다. 불가피하게 열어둬야 하는 자산은 예외 승인 후 주기적으로 재검토하는 절차도 만들 계획이에요. 그래야 ‘알고는 있지만 방치된 노출’이 쌓이지 않습니다.
자체 개발 도구이기 때문에 이 방향들을 핀다 우선순위에 맞춰 단계적으로 직접 추가해 나갈 수 있다는 게 이 프로젝트의 가장 큰 강점이라고 생각해요. 상용 도구였다면 벤더사에 요청하고 기다려야 했을 부분들을, 바로 만들어 반영할 수 있으니까요. 프로젝트를 사내에 더 널리 공유할 자리도 고민하고 있는데, 정보보안 관점에서도 AI를 활용한 자체 개발이 충분히 가능하다는 걸 보여줄 선례가 될 것 같습니다.
Interviewee 천성민
Interview & edit 김성현
Photo 김성현
