AI 보안 해커톤 운영 가이드: 하루 만에 보안 PoC를 만든 방법

Jaime Arze · 2026년 6월 5일

보안팀은 새로운 기술을 먼저 의심하도록 훈련받습니다. 위험을 분석하고, 새롭게 등장하는 위협을 예측하며, 최악의 상황에 대비하는 것이 보안팀의 역할이기 때문입니다. 따라서 AI가 등장했을 때의 첫 반응도 크게 다르지 않았습니다. “또 하나의 방어해야 할 공격 표면(Attack Surface)이 생겼군.”

이러한 판단은 틀리지 않습니다. 하지만 AI가 보안팀에 미치는 영향은 새로운 위협의 등장만으로 설명되지 않습니다.

많은 보안팀은 당장의 위협을 차단하는 전술적 업무에 매달려 있습니다. 처리해도 줄지 않는 알림 대기열, 계속해서 들어오는 새로운 시그널과 분류해야 할 CVE, 여러 시스템에서 일일이 가져와야 하는 증거 자료가 대표적입니다.

그런데 보안팀이 매일 의심의 눈으로 바라보는 AI가 이러한 반복 업무를 줄이고, 매주 몇 시간에서 길게는 며칠까지 업무 시간을 되돌려줄 수도 있습니다.

그래서 우리는 AI 도입을 둘러싼 논쟁을 잠시 멈추고 AI 보안 해커톤을 열었습니다. 하루 동안 네 개 팀이 참여했고, 발표용 슬라이드는 만들지 않았습니다. 규칙은 하나였습니다. “현재 당신을 괴롭히는 실제 문제를 해결할 수 있는 무언가를 만들어라.”

그리고 팀들은 실제로 작동하는 결과물을 만들어냈습니다. “이런 업무에 AI를 활용하면 좋겠다”는 아이디어와 “여기 실제로 작동하는 도구가 있다”는 결과물 사이의 거리는 모두가 예상했던 것보다 훨씬 가까웠습니다.

AI 보안 해커톤이 필요한 이유

AI 도입 과정에서는 특유의 조직적 마비가 발생합니다. AI가 중요하다는 사실에는 대부분 동의하고, 프롬프트를 작성하거나 관련 자료도 읽어봅니다. 하지만 팀원들이 매일 사용할 수 있는 실제 도구를 구현한 조직은 많지 않습니다.

해커톤은 이러한 정체 상태를 비교적 적은 비용으로 빠르게 해소할 수 있습니다. 장기 로드맵이나 대규모 예산을 먼저 확정할 필요도 없습니다. 하루와 단순한 전제 하나면 시작할 수 있습니다. 팀이 누구보다 잘 이해하고 있는 문제를 하나 선택하고, 정해진 시간 안에 어디까지 해결할 수 있는지 확인하는 방식입니다.

투입한 시간에 비해 얻을 수 있는 결과는 큽니다. 현재 사용할 수 있는 도구로 실제 해결 가능한 문제와 그렇지 않은 문제를 구분할 수 있고, 팀 내에서 AI 도구를 능숙하게 활용하는 인재도 발견할 수 있습니다. 무엇보다 AI에 대한 막연한 불안과 기대를 구체적인 증거로 바꿀 수 있습니다.

이러한 방식은 팀 규모와 관계없이 적용할 수 있습니다. 열 명이나 백 명으로 구성된 조직뿐만 아니라 세 명으로 구성된 소규모 팀도 오후 한나절 동안 집중하면 실제 결과물을 만들어낼 수 있습니다.

AI 보안 해커톤을 실제로 운영하는 방법

해커톤을 직접 진행하려면 문제의 범위, 사전 준비, 중간 점검 및 마감 기준을 명확하게 설정해야 합니다. 우리가 시행착오를 통해 배운 핵심 운영 원칙은 다음과 같습니다.

해결할 문제의 범위를 좁게 설정하기

범위가 전부입니다. 어떤 팀이 결과물을 완성하는지는 좁은 문제를 선택해 깊이 파고들었는지에 따라 달라졌습니다. 플랫폼 전체를 만들고 싶은 욕심은 언제나 생기지만, 지나치게 넓은 범위는 데모 완성을 방해합니다.

코드 작성을 시작하기 전에 제안서 단계에서 최소 기능 제품(Minimum Viable Product, MVP)을 명확히 정의해야 합니다. 예를 들어 “지표 50개를 보강해 위협 브리핑을 생성하는 스크립트”는 적절한 범위지만, “자율 SOC를 구축한다”는 목표는 하루짜리 해커톤 범위로 적합하지 않습니다.

개발 전에 짧은 제안서 작성하기

만들기 전에 제안서부터 작성하게 해야 합니다. 우리는 해커톤 일주일 전에 대상 사용자, 해결하려는 불편, 효과를 판단할 지표, 사용할 도구가 포함된 짧은 제안서를 받았습니다.

이 과정은 참가자가 개발을 시작하기 전에 문제와 해결 방법을 구체적으로 정리하도록 돕습니다. 또한 아직 수정할 시간이 남아 있을 때 리더가 범위 확장(Scope Creep)이나 누락된 접근 권한을 미리 확인할 수 있게 합니다.

시작 전에 도구 접근 권한 확인하기

타이머가 시작되기 전에 도구 접근 권한을 확인해야 합니다. 스프린트가 시작된 뒤 API 키나 시스템 접근 권한이 없다는 사실을 발견하면 상당한 시간을 잃게 됩니다.

일정에 별도의 준비 시간을 포함하고, API 키와 데이터 소스, 개발 도구 및 대상 시스템에 대한 접근 권한 확인을 필수 절차로 운영해야 합니다.

중간 점검에서 범위 다시 조정하기

중간 점검 지점을 반드시 포함해야 합니다. 가장 유용했던 일정은 오전 중간에 진행한 30분간의 상태 점검이었습니다. 각 팀은 현재 작동하는 기능과 가장 큰 장애물을 공유했고, 필요한 범위 조정 결정을 스폰서에게 바로 요청했습니다.

뒤처진 팀들은 더 많은 업무를 수행해서 일정을 따라잡은 것이 아닙니다. 해결 범위를 줄여서 따라잡았습니다. 이러한 결정을 실제로 내리는 자리가 바로 중간 점검이었습니다.

데모 전에 개발을 강제로 마감하기

멈춰야겠다고 느끼기 전에 개발을 중단해야 합니다. 우리는 데모 시작 90분 전을 강제 마감 시점으로 정했습니다. 이 시점 이후에 추가하는 새로운 기능은 가치보다 위험을 더할 가능성이 큽니다.

남은 시간은 리허설과 안정성 확인에 사용했습니다. 개발자가 아닌 다른 사람이 실행하더라도 결과물이 정상적으로 작동하는지 검증하는 시간도 포함했습니다.

임팩트와 실현 가능성을 중심으로 심사하기

실제 목적에 맞는 기준으로 결과물을 심사해야 합니다. 우리는 임팩트, 실현 가능성, 혁신성이라는 세 가지 기준으로 점수를 매겼으며, 가중치도 이 순서로 적용했습니다.

임팩트를 가장 중요한 기준으로 설정한 이유는 존재하지 않는 문제를 해결하는 기발한 도구에는 실질적인 가치가 없기 때문입니다. 실현 가능성을 두 번째 기준으로 둔 이유도 명확합니다. “아이디어는 좋지만 실제 출시는 불가능한 결과물”이 해커톤에서 흔히 발생하는 실패이기 때문입니다.

혁신성을 마지막 기준으로 배치한 것은 팀이 실제 문제 해결보다 기술적 복잡성에 빠지는 상황을 방지하기 위해서였습니다.

하루 일정 구성하기

하루 일정은 범위 확정과 역할 점검을 위한 짧은 킥오프, 1차 빌드 스프린트, 중간 점검, 더 긴 2차 스프린트, 준비와 리허설을 위한 강제 마감, 데모 및 심사 순서로 구성할 수 있습니다.

전체 일정은 8시간이면 충분하며, 각 팀이 필요한 준비를 마친 상태로 참여한다면 6시간으로도 진행할 수 있습니다.

해커톤에서 만든 AI 보안 PoC

우리는 세 명씩 팀을 구성하고 보안 조직의 여러 영역에서 참가자를 모았습니다. 평소 함께 일할 기회가 적었던 구성원을 의도적으로 섞어 서로 다른 관점과 전문성을 활용할 수 있도록 했습니다. 다음은 해커톤에서 구현한 결과물입니다.

Atlas: 소유권 해석기

문제: 규모가 큰 조직에서는 데이터가 여러 시스템에 분산되어 있습니다. 광범위한 제품 포트폴리오에 관한 세부 질문에 답하려면 여러 시스템에서 관련 맥락을 수집해야 합니다. 이러한 사내 지식은 가치가 높지만 필요할 때 즉시 찾지 못하면 팀 간 인수인계나 촉박한 조사·분석 업무가 지연됩니다.

아키텍처: Atlas는 네 개의 데이터 소스를 모두 인덱싱하고, 신뢰도 모델을 사용해 정보를 대조·정리하는 검색 증강 생성(Retrieval-Augmented Generation, RAG) 기반 대화형 에이전트입니다.

네 개 소스 중 세 개 이상이 특정 소유자에 대해 일치하면 높은 신뢰도로 판단합니다. 데이터가 서로 일치하지 않으면 Atlas는 가장 가능성이 높은 추정 결과와 함께 충돌 내용을 표시하고, 사람의 검토가 필요하다는 사실을 알립니다.

답변은 출처 시스템까지 추적할 수 있는 인용과 함께 구조화된 형태로 제공됩니다. 야간 배치는 정규화된 제품 카드를 마크다운으로 다시 생성합니다. 팀은 이를 검토한 후 공인된 기준 정보(Source of Truth)로 사용할 수 있도록 아키텍처 산출물 저장소에 커밋할 수 있습니다.

인터페이스는 CLI와 Slack 봇 두 가지를 계획했으며, 해커톤 당일에는 CLI를 완성했습니다.

스택: 엔티티 해석과 질의응답에는 프런티어 LLM을 사용했습니다. 저장소·소유권 데이터, 주제 전문가(Subject Matter Expert, SME) 목록, 행동 기반 소유권 시그널, 위험 할당 정보를 활용하기 위해 소스 관리·문서·팀 채팅·이슈 트래킹 시스템의 데이터를 가져왔습니다. 행동 기반 소유권 시그널은 실제로 누가 특정 제품 관련 질문에 답하는지를 나타냅니다.

이 팀은 인용이 포함된 답변을 제공하는 실제 작동 가능한 CLI를 완성했습니다. 팀원 한 명이 아파서 참여하지 못한 상황에서도 결과물을 구현했습니다. Slack 봇과 웹 UI는 다음 개발 단계로 계획되어 있습니다.

Vendor Assessment Tool: 더 빠른 서드파티 위험 평가

문제: 서드파티 위험 평가는 속도가 느리고 대부분 수작업으로 진행됩니다. 분석가는 벤더 문서를 읽고 설문지와 비교한 다음, 통제 항목을 매핑하고 보고서를 작성합니다. 이러한 과정은 서로 분리된 파일 사이에서 수작업으로 수행됩니다.

아키텍처: Vendor Assessment Tool은 벤더 문서와 설문 응답을 입력받아 두 자료를 기반으로 추론하는 Claude Code CLI 도구입니다. 분석가가 도구를 실행하면 Claude Code가 문서 분석, 격차 식별 및 보고서 작성을 처리하고, 구조화된 서드파티 위험(Third-Party Risk, TPR) 평가 보고서를 생성합니다. 통제 프레임워크에 관한 맥락은 Hyperproof TPRM을 통해 제공됩니다.

이 사례에서 주목할 부분은 범위 조정입니다. 이 팀은 처음에 여섯 개의 소스 시스템에 걸쳐 8개의 에이전트를 사용하는 야심 찬 위협 분석 파이프라인인 IRIS를 제안했습니다.

그러나 스프린트 도중 범위를 집중적인 벤더 평가 기능 하나로 축소했습니다. 이는 올바른 판단이었으며, 해커톤을 통해 익혀야 하는 중요한 문제 해결 방식이기도 합니다.

스택: CLI에서 실행되는 Claude Code, 벤더 및 통제 맥락을 제공하는 Hyperproof TPRM, 입력 자료로 사용한 로컬 벤더 문서와 설문 파일로 구성했습니다.

범위를 좁혀 구현한 버전은 정상적으로 작동했습니다. 데모에서는 완전한 실시간 평가를 한 차례 실행했으며, 해당 업무를 담당하는 분석가는 바로 다음 날부터 이 도구를 사용할 수 있었습니다.

EvidenceRelay: 감사 증거 수집 간소화

문제: 감사 증거 수집은 작업량이 많고 반복적인 업무입니다. 증거 요청이 티켓으로 들어오면 엔지니어는 해당 통제에 맞는 증거 소스로 이동해 쿼리를 실행하고, 결과를 캡처한 뒤 다시 티켓에 첨부합니다.

이는 분석가가 더 빠르게 업무를 수행할 수 있도록 지원하면 즉각적인 이점을 얻을 수 있는 구조적이고 잘 알려진 워크플로입니다.

아키텍처: EvidenceRelay는 사람이 직접 트리거하는 멀티 에이전트 파이프라인입니다. SecOps 엔지니어가 티켓을 열고 에이전트를 명시적으로 호출해야 하며, 자동으로 실행되지는 않습니다.

에이전트는 티켓 내용을 읽고 적절한 증거 소스를 식별한 다음, 쿼리를 실행해 결과를 가져옵니다. 이후 감사자(Auditor) 역할을 담당하는 두 번째 에이전트가 해당 결과를 독립적으로 검증하고, 정보가 기록되기 전에 신뢰도 점수를 부여합니다.

신뢰도가 낮으면 확인된 부분의 증거만 입력하고, 사람의 검토가 필요한 부분을 명확하게 표시합니다. 확인되지 않은 내용을 임의로 추정하지 않습니다.

마지막 단계에서는 사용한 도구, 쿼리, 원시 결과 및 타임스탬프가 포함된 인용 코멘트를 남깁니다. 이후 ‘검토 준비됨’ 라벨을 추가하고, 최종 검토와 티켓 종료를 담당하는 사람에게 다시 전달합니다.

검토된 증거는 기존 연동을 통해 GRC 플랫폼으로 동기화되며, 동기화에 필요한 모든 필드도 그대로 보존됩니다.

스택: 프런티어 에이전트 SDK, 이슈 트래커에 대한 MCP 연결, 클라우드 보안·EDR·SIEM 플랫폼에 대한 직접 API 및 MCP 연결을 사용했습니다. 새로운 클라우드 인프라는 구축하지 않았으며, 기존 도구에서 제공하는 API를 기반으로 작동합니다.

이 도구들은 아직 프로덕션 시스템이 아니라 하루 만에 만든 개념검증(Proof of Concept, PoC)입니다. 그러나 일부 결과물은 실제 출시를 검토할 수 있을 만큼 완성도에 가까워졌습니다.

이에 따라 핵심 질문도 “이것이 가능한가?”에서 “실제로 출시하려면 무엇이 더 필요한가?”로 바뀌었습니다. 실제 로드맵의 가치는 이 질문에 있으며, 우리는 이미 그 답을 찾아가는 중입니다.

AI 보안 해커톤이 남긴 핵심 교훈

이번 해커톤에서 얻은 가장 큰 결과는 개별 도구가 아니었습니다. AI 기술을 실무에 적용하는 문턱이 예상보다 훨씬 낮다는 사실을 확인한 것이 더 중요한 성과였습니다.

팀을 가로막고 있었던 것은 대부분 기술 역량의 부족이 아니라 시도할 수 있는 권한과 시간이었습니다. 팀원들은 이미 해결해야 할 문제를 자세히 이해하고 있었습니다. 필요한 것은 문제 해결에 집중할 하루와 이를 시도해도 된다는 권한이었습니다.

AI가 초래하는 보안 위협은 분명히 존재하며, 우리는 이에 대응하기 위한 업무를 계속할 것입니다. 그러나 AI가 제공하는 기회도 마찬가지로 현실적입니다. 보안팀은 이러한 변화를 지켜보기만 할 수 없습니다.

도구를 활용해 알림 500건을 1차로 분류하는 보안 담당자와 모든 알림을 수작업으로 처리하는 담당자의 업무 방식에는 큰 차이가 있습니다.

아직 AI 보안 해커톤을 진행하지 않은 팀 리더라면 조언은 간단합니다. 하루를 확보하고 팀원들에게 문제 해결에 집중할 수 있는 공간과 권한을 제공해 보세요. 리더가 한 걸음 물러났을 때 팀이 만들어내는 결과물은 예상보다 훨씬 구체적일 수 있습니다.

AI 보안 해커톤 FAQ

AI 보안 해커톤은 무엇인가요?

AI 보안 해커톤은 보안팀이 실제 업무에서 겪는 문제를 선택하고, AI 도구를 활용해 제한된 시간 안에 해결 가능한 PoC를 구현하는 집중형 행사입니다. 이 사례에서는 하루 동안 네 개 팀이 참여해 실제로 작동하는 결과물을 만들었습니다.

하루 만에 보안 PoC를 만들려면 범위를 어떻게 정해야 하나요?

플랫폼 전체가 아니라 하나의 명확한 업무를 선택해야 합니다. 개발 전에 대상 사용자, 해결할 문제, 효과 지표, 사용할 도구 및 MVP 범위를 짧은 제안서로 정리하면 범위 확장을 줄일 수 있습니다.

AI 보안 해커톤 전에 무엇을 준비해야 하나요?

API 키, 데이터 소스, 개발 도구 및 대상 시스템에 대한 접근 권한을 미리 확인해야 합니다. 참가팀은 해결할 문제와 MVP 범위를 사전에 정하고, 해커톤 당일에는 바로 구현을 시작할 수 있는 상태로 참여하는 것이 좋습니다.

AI가 감사 증거 수집을 완전히 자동화하나요?

EvidenceRelay 사례에서는 사람이 티켓에서 에이전트를 명시적으로 호출해야 하며 자동으로 실행되지 않습니다. 두 번째 에이전트가 결과를 검증하고 신뢰도가 낮은 항목은 사람의 검토가 필요한 부분으로 표시합니다.

해커톤 결과물을 바로 프로덕션에 적용할 수 있나요?

이 글에서 소개한 결과물은 하루 만에 만든 PoC이며 프로덕션 시스템은 아닙니다. 다만 일부 결과물은 실제 출시를 위해 추가로 필요한 요건을 검토할 수 있을 만큼 완성도에 가까워졌습니다.

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)