딱 하루만 비워보세요: AI 보안 해커톤을 직접 열어보고 배운 것들
Jaime Arze · 2026년 6월 5일
보안팀은 새로운 기술을 일단 의심하도록 훈련받습니다. 그게 우리 일이니까요. 위험을 따지고, 떠오르는 위협을 그려보고, 최악을 가정해 대비합니다. 그래서 AI가 등장했을 때도 첫 반응은 똑같았습니다. “또 하나의 방어할 공격 표면(attack surface)이 생겼군.”
맞는 직감입니다. 그런데 그게 전부는 아니죠.
대부분의 팀은 당장의 위협을 막는 전술 업무에 매달립니다. 그 와중에도 보안팀은 늘 일에 파묻혀 삽니다. 처리해도 줄지 않는 알림 큐. 끝없이 쏟아지는 새 시그널과 분류해야 할 CVE들. 일일이 끌어와야 하는 증거 자료들. 그런데 우리가 매일 의심스럽게 들여다보는 그 기술이, 한편으론 한 주에 몇 시간을 되돌려줄 수도 있습니다. 길게는 며칠씩요.
그래서 우리는 갑론을박을 멈췄습니다. 그냥 해커톤을 열었죠. 하루, 네 개 팀, 슬라이드 없음. 규칙은 하나였습니다. “지금 당신을 괴롭히는 진짜 문제를 푸는 무언가를 만들어라.” 그리고 정말 만들어냈습니다. “이런 데 AI를 써야 할 텐데”와 “자, 여기 돌아갑니다” 사이의 거리는 다들 생각보다 훨씬 가까웠습니다.
왜 해커톤이고, 왜 지금인가
AI 도입에는 특유의 조직적 마비가 있습니다. 중요하다는 데는 다들 동의합니다. 프롬프트도 몇 개씩 써봤고 자료도 몇 장 읽어봤죠. 그런데 팀원들이 매일 쓰는 무언가를 실제로 내놓은 팀은 드뭅니다.
해커톤은 그 마비를 단번에 깨뜨립니다. 그것도 아주 싸게요. 로드맵이나 예산을 약속하는 게 아닙니다. 딱 하루와 단순한 전제 하나면 됩니다. 당신이 누구보다 잘 아는 문제를 하나 고르세요. 그리고 시간이 다 가기 전에 어디까지 풀 수 있는지 해보는 겁니다.
들인 것에 비하면 돌려받는 게 훨씬 큽니다. 지금 도구로 실제 풀리는 문제와 그렇지 않은 문제가 뭔지 알게 됩니다. 조용히 이 일을 기막히게 잘하는 팀원이 누구인지도 보이고요. 무엇보다 막연한 불안이 구체적인 증거로 바뀝니다. 결국 조직을 움직이는 건 늘 그 증거뿐이거든요.
이 효과는 팀이 열 명이든 백 명이든 똑같습니다. 규모를 줄여도 방식은 그대로 작동하고요. 세 명짜리 팀도 오후 한나절만 집중하면 진짜 결과물을 들고 나옵니다.
진짜로 굴러가게 만드는 운영법
우리가 배운 것들이 있습니다. 더러는 호되게 배웠고요. 직접 해보실 거라면, 중요한 건 다음과 같습니다.
범위가 전부다. 어떤 팀이 결과물을 내놓느냐는 한 가지로 갈렸습니다. 좁은 문제를 골라 깊게 팠는가입니다. 플랫폼 전체를 만들고 싶은 욕심은 늘 생깁니다. 그리고 그 욕심은 매번 데모를 망칩니다. 코드 한 줄 쓰기 전에 제안서 단계에서 최소 기능 제품(MVP)을 못 박게 하세요. “지표 50개를 보강해 위협 브리핑을 뽑는 스크립트”는 좋은 범위입니다. “자율 SOC”는 아니고요.
만들기 전에 제안서부터 쓰게 하라. 우리는 일주일 전에 짧은 제안서를 받았습니다. 대상 사용자, 어떤 불편을 푸는지, 효과 지표, 쓸 도구. 이게 두 가지를 해줍니다. 먼저, 키보드에 손대기 전에 생각을 정리하게 만듭니다. 또 아직 고칠 시간이 있을 때 리더가 범위 확장(scope creep)이나 권한 누락을 미리 짚게 해줍니다.
타이머가 돌기 전에 도구 접근 권한을 확인하라. 오전 10시에 “API 키 가진 사람이 없네”를 깨닫는 것만큼 스프린트를 빨리 날려먹는 일도 없습니다. 일정에 준비 시간을 따로 넣으세요. 그리고 그걸 선택이 아닌 필수로 다루세요.
중간 점검 지점을 반드시 끼워라. 가장 쓸모 있었던 일정 항목은 오전 중간의 30분짜리 상태 점검이었습니다. 팀마다 지금 뭐가 돌아가는지 보여줬습니다. 가장 큰 걸림돌을 말했고요. 그 자리에서 스폰서한테 범위 결정을 받았습니다. 뒤처진 팀들은 더 열심히 해서 따라잡은 게 아닙니다. 범위를 쳐내서 따라잡았죠. 그 결단이 내려진 자리가 바로 이 점검 지점이었습니다.
멈춰야겠다 싶기 전에 손을 떼라. 우리는 데모 90분 전을 강제 마감으로 정했습니다. 그 뒤에 붙이는 새 기능은 기능이 아닙니다. 위험입니다. 남은 시간은 리허설에 씁니다. 남이 실행해도 안 깨지는지 확인하는 데 쓰고요.
제대로 된 기준으로 심사하라. 우리는 세 가지로 점수를 매겼습니다. 임팩트, 실현 가능성, 혁신성. 가중치도 이 순서였습니다. 임팩트를 일부러 맨 앞에 뒀습니다. 가짜 문제를 푸는 기발한 도구는 쓸모가 없으니까요. 실현 가능성이 둘째인 이유도 분명합니다. “아이디어는 좋은데 출시는 불가능”이 해커톤의 가장 흔한 실패라서요. 혁신성을 맨 뒤에 둔 건, 정작 문제는 안 풀면서 복잡함에만 빠지지 않게 하려는 겁니다.
하루 일정의 깔끔한 골격은 대략 이렇습니다. 범위를 확정하고 역할을 점검하는 짧은 킥오프 → 1차 빌드 스프린트 → 중간 점검 → 더 긴 2차 스프린트 → 준비와 리허설을 위한 강제 마감 → 데모와 심사. 8시간이면 여유롭습니다. 팀이 준비된 채로 들어온다면 6시간으로도 됩니다.
우리가 만든 것들
세 명씩 팀을 짰습니다. 보안 조직 곳곳에서 사람을 모았고요. 평소 같이 일할 일 없던 사람들이 어쩔 수 없이 손발을 맞추도록 일부러 섞었습니다(생각의 다양성, 덕 좀 봤습니다). 그들이 내놓은 결과물입니다.
Atlas — 소유권 해석기(ownership resolver)
문제: 규모가 큰 조직이 대개 그렇듯, 데이터는 여러 시스템에 흩어져 있습니다. 넓은 포트폴리오에 걸친 세세한 제품 질문에 답하려면 여기저기서 맥락을 끌어모아야 하죠. 이런 사내 지식은 값집니다. 하지만 필요할 때 바로 못 꺼내면 팀 간 인수인계나 촉박한 조사 분석이 더뎌집니다.
아키텍처: 네 개 소스를 전부 인덱싱하고 신뢰도 모델로 대조·정리하는 RAG 기반 대화형 에이전트입니다. 네 소스 중 셋 이상이 소유자에 대해 일치하면 높은 신뢰도로 봅니다. 서로 어긋나면 Atlas가 가장 그럴듯한 추정과 함께 그 충돌을 드러냅니다. 그리고 사람이 봐야 한다고 표시합니다. 답은 출처 시스템까지 거슬러 올라가는 인용과 함께 구조화된 형태로 돌려줍니다. 야간 배치는 정규화된 제품 카드를 마크다운으로 다시 만들어둡니다. 팀은 이를 검토한 뒤 공인된 기준 정보(source of truth)로서 아키텍처 산출물 저장소에 커밋할 수 있습니다. 인터페이스는 CLI와 Slack 봇 둘을 계획했고, 당일에는 CLI를 완성했습니다.
스택: 엔티티 해석과 Q&A에는 프런티어 LLM을 썼습니다. 그리고 저장소·소유권 데이터, 주제 전문가(SME) 목록, 행동 기반 소유권 시그널(누가 어떤 제품 질문에 실제로 답하는가), 위험 할당 정보를 위해 소스 관리·문서·팀 채팅·이슈 트래킹 시스템을 끌어왔습니다.
이 팀은 인용 달린 답을 돌려주는 동작하는 CLI를 출시했습니다. 그것도 한 명이 아파서 빠진, 한 사람 부족한 상태로요. Slack 봇과 웹 UI가 다음 차례입니다.
Vendor Assessment Tool — 더 빠른 서드파티 위험 평가
문제: 서드파티 위험 평가는 느리고 거의 다 수작업입니다. 분석가가 벤더 문서를 읽고, 설문지와 맞춰보고, 통제 항목을 매핑하고, 보고서를 씁니다. 그 모든 단계를 서로 따로 노는 파일들 사이에서 손으로 합니다.
아키텍처: 벤더 문서와 설문 응답을 받아 그 둘을 가로질러 추론하는 Claude Code CLI 도구입니다. 그 결과로 구조화된 TPR(서드파티 위험) 평가 보고서를 만들어냅니다. 분석가가 도구를 실행하면 Claude Code가 문서 분석·격차 식별·보고서 작성을 처리합니다. 통제 프레임워크 맥락은 Hyperproof TPRM이 채워주고요. 여기서 진짜 들려줄 이야기는 범위 조정입니다. 이 팀은 원래 IRIS를 제안했습니다. 소스 시스템 여섯 곳에 걸친 8개 에이전트짜리 야심 찬 위협 분석 파이프라인이었죠. 그런데 스프린트 도중 그걸 이 집중된 벤더 평가 한 조각으로 잘라냈습니다. 옳은 판단이었습니다. 바로 해커톤이 가르치려는 그 감각이고요.
스택: CLI에서 도는 Claude Code, 벤더·통제 맥락을 위한 Hyperproof TPRM, 그리고 입력으로 쓴 로컬 벤더 문서·설문 파일.
좁게 잡은 버전은 잘 돌아갑니다. 데모에서 완전한 실시간 평가를 한 번 돌렸습니다. 이 업무를 맡은 분석가는 바로 다음 날부터 쓸 수 있었고요.
EvidenceRelay — 한결 쉬워진 컴플라이언스
문제: 감사 증거 수집은 양 많고 반복적인 일입니다. 증거 요청이 티켓으로 들어옵니다. 그러면 엔지니어가 해당 통제에 맞는 증거 소스로 옮겨가 쿼리를 돌리고, 결과를 캡처해 다시 붙입니다. 분석가에게 더 빠른 길을 쥐여주면 곧장 이득이 되는, 딱 그런 구조적이고 잘 알려진 워크플로죠.
아키텍처: 사람이 직접 트리거하는 멀티 에이전트 파이프라인입니다. SecOps 엔지니어가 티켓을 열고 에이전트를 명시적으로 호출합니다. 절대 자동으로 돌지 않습니다. 에이전트는 티켓을 읽고 알맞은 증거 소스를 찾아 쿼리를 돌려 결과를 가져옵니다. 그다음 감사자(auditor) 역할의 두 번째 에이전트가 그 결과를 독립적으로 검증합니다. 그리고 뭔가 기록되기 전에 신뢰도 점수를 매깁니다. 신뢰도가 낮으면 부분 증거만 채웁니다. 아직 사람 손이 필요한 부분은 분명히 표시하고요. 슬그머니 넘겨짚는 일은 없습니다. 마무리 단계에선 사용한 도구·쿼리·원시 결과·타임스탬프가 담긴 인용 코멘트를 남깁니다. ‘검토 준비됨’ 라벨을 단 뒤, 검토하고 닫을 사람에게 다시 넘깁니다. 이후 증거는 기존 연동을 통해 GRC 플랫폼으로 동기화됩니다. 그 동기화에 필요한 모든 필드도 그대로 보존되고요.
스택: 프런티어 에이전트 SDK, 이슈 트래커에 대한 MCP 연결, 그리고 클라우드 보안·EDR·SIEM 플랫폼에 대한 직접 API 및 MCP 연결. 새 클라우드 인프라는 없습니다. 기존 도구의 API 위에서 돕니다.
이 중 무엇도 프로덕션 시스템은 아닙니다. 하루 만에 만든 개념검증(PoC)이죠. 그런데 몇몇은 완성도가 충분히 가깝습니다. 이제 진짜 질문은 “이게 가능한가”가 아닙니다. “이걸 출시하려면 뭐가 더 필요한가”로 바뀌었습니다. 실제 로드맵의 가치는 바로 그 질문 안에 있고, 우리는 이미 그 답을 풀어가는 중입니다.
결국 남은 것
우리가 가장 크게 얻은 건 도구가 아니었습니다. 이 기술을 쓰는 문턱이 생각보다 훨씬 낮다는 증거였죠. 가로막은 건 대개 실력이 아니라 허락과 시간이었습니다. 우리 팀원들은 이미 문제를 속속들이 알고 있었습니다. 그저 그걸 풀러 갈 하루와, 풀어도 된다는 권한이 필요했을 뿐입니다.
AI의 위협적인 면은 분명 실재합니다. 우리는 그에 필요한 일을 계속할 겁니다. 하지만 기회의 면도 그만큼 실재합니다. 보안팀에게 그걸 그냥 지켜만 볼 여유는 없습니다. 도구를 쥐고 알림 500건을 1차로 걸러내는 방어자를 떠올려 보세요. 그걸 맨손으로 하는 방어자와는 차원이 다릅니다.
팀을 이끄는 분이고 아직 이걸 안 해보셨다면, 조언은 간단합니다. 하루를 비우세요. 사람들에게 공간을 내주세요. 당신이 한 발 비켜섰을 때 그들이 뭘 만들어내는지 보면, 분명 놀라실 겁니다.
EDB Postgres AI와 AI 활용, 더 알아보기
AI를 보안·운영 워크플로에 접목하는 방안이나 EDB Postgres AI가 궁금하시다면 EDB Korea로 문의해 주세요.
- 이메일: salesinquiry@enterprisedb.com
- 전화: 02-501-5113
- 문의하기 →
원문: Just Clear a Day: What We Learned Running an AI Security Hackathon (EDB Blog)
