ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code

이 논문은 AI 가 생성한 코드의 보안 감사를 자유로운 대화형 프로세스가 아닌, 이벤트 소싱과 재생 가능한 검증을 기반으로 한 구조적이고 검증 가능한 감사 아키텍처인 'ESAA-Security'를 제안하여, 불변의 감사 추적과 재현 가능한 위험 평가를 가능하게 합니다.

핵심

이 논문은 **"AI 가 만든 코드를 어떻게 안전하게 검사할 것인가?"**라는 질문에 대한 새로운 해법을 제시합니다.

기존의 방식은 AI(대형 언어 모델) 에게 "이 코드에 버그나 보안 문제가 있니?"라고 그냥 물어보는 것이었습니다. 하지만 이 방식은 AI 가 때로는 중요한 걸 놓치기도 하고, 답변이 일관성 없거나, 나중에 "어떻게 그 결론을 내었는지"를 증명할 수 없다는 문제가 있었습니다.

이 논문에서 제안하는 ESAA-Security는 이 문제를 해결하기 위해 **"자유로운 대화"가 아닌 "엄격한 감사 (Audit) 프로세스"**로 접근법을 바꿉니다.

이 복잡한 개념을 쉽게 이해할 수 있도록 세 가지 비유로 설명해 드리겠습니다.

---

1. 비유: "무작위 대화 vs. 공인된 검사관"

• 기존 방식 (문제점):
  마치 친구에게 "이 집이 안전한지 봐줘"라고 부탁하는 것과 같습니다. 친구가 "음, 문이 잠겨있고 창문도 닫혀 있네. 안전해 보여!"라고 말해줍니다. 하지만 친구가 왜 그렇게 생각했는지, 어떤 창문을 확인했는지, 혹시 다른 구석은 안 봤는지는 알 수 없습니다. 나중에 문제가 생기면 "내가 그걸 확인했어?"라고 다시 물을 수 없습니다.

• ESAA-Security 방식 (해결책):
  이제 **공인된 검사관 (감사관)**을 고용했다고 상상해 보세요.

  1. 정해진 체크리스트: 검사관은 임의로 돌아다니는 게 아니라, '문, 창문, 잠금장치, 전기 배선' 등 정해진 95 가지 항목을 하나씩 확인합니다.
  2. 기록의 의무: 검사관은 각 항목을 확인할 때마다 **"A 문 확인 완료, 잠금장치 정상"**이라고 **변경 불가능한 장부 (이벤트 로그)**에 적습니다.
  3. 검증: 나중에 누군가 이 장부를 다시 펼쳐보면, 검사관이 어떤 순서로 무엇을 확인했는지, 어떤 증거를 바탕으로 결론을 내렸는지 **완벽하게 재현 (Replay)**할 수 있습니다.

2. 핵심 원리: "변경 불가능한 장부 (Event Sourcing)"

이 시스템의 가장 중요한 특징은 **"장부 (로그)"**를 진리로 삼는다는 점입니다.

• 일상적인 비유:
  은행 계좌를 생각해 보세요. 은행은 "지금 잔고가 얼마냐"고 묻는 게 아니라, **"어제 10 만 원 입금, 오늘 5 천 원 출금"**이라는 **모든 거래 내역 (이벤트)**을 저장합니다.
  • 만약 누군가 장부를 고쳐서 "출금이 없었어"라고 거짓말을 해도, 은행은 과거의 모든 거래 기록을 다시 계산해 보면 거짓말이 드러납니다.
  • ESAA-Security 도 마찬가지입니다. AI 가 "이 코드는 안전해"라고 말하더라도, 그 결론에 도달하기까지 어떤 데이터를 보고, 어떤 규칙을 적용했는지가 장부에 꼼꼼히 기록됩니다. 나중에 다시 그 장부를 읽으면 똑같은 결론이 나옵니다.

3. 작동 방식: "4 단계의 엄격한 여정"

이 시스템은 AI 가 코드를 검사할 때 4 단계를 거치도록 설계되었습니다. 마치 수사관이 사건을 해결하는 과정과 비슷합니다.

1. 현장 수색 (Reconnaissance):
   • "이 집 (코드) 은 어떤 구조로 되어 있을까? 누가 들어올 수 있는 문은 몇 개인가?"를 파악합니다.
2. 상세 검사 (Domain Audit):
   • 미리 정해진 16 가지 보안 분야 (비밀번호, 데이터 암호화, AI 보안 등) 에 대해 26 가지 작업을 수행합니다.
   • AI 는 여기서 "자유롭게" 말하는 게 아니라, 정해진 규칙 (계약) 안에서만 답변을 작성합니다.
3. 위험 등급 매기기 (Risk Classification):
   • 발견된 문제들을 "치명적 (Critical)", "높음 (High)", "보통 (Medium)" 등으로 등급을 매기고, **위험 지도 (Risk Matrix)**를 그립니다.
4. 최종 보고서 (Final Reporting):
   • 단순히 "문제 있어요"가 아니라, 어디에 문제가 있고, 어떻게 고쳐야 하는지가 담긴 전문적인 보고서를 작성합니다. 이 보고서는 앞서 기록된 모든 장부 (증거) 를 바탕으로 만들어지므로 신뢰할 수 있습니다.

---

왜 이것이 중요한가요?

• AI 가 코드를 만드는 시대: 요즘은 AI 가 코드를 빠르게 짜주지만, 그 코드가 보안상 얼마나 안전한지는 알기 어렵습니다.
• 증거가 필요한 이유: 단순히 AI 가 "안전하다"고 말한다고 믿을 수 없습니다. 나중에 해킹이 발생했을 때, **"우리가 어떻게 검사했는지, 어떤 증거를 바탕으로 안전하다고 판단했는지"**를 증명할 수 있어야 합니다.
• ESAA-Security 의 역할: 이 시스템은 AI 의 감을 믿는 것이 아니라, **AI 가 수행한 모든 행동을 기록하고 검증 가능한 프로세스로 만드는 "안전장치"**입니다.

요약

이 논문은 **"AI 가 코드를 검사할 때, 그냥 대화하는 게 아니라 변하지 않는 장부에 모든 증거를 기록하는 엄격한 감사 시스템을 만들자"**고 주장합니다.

마치 수사관이 사건을 해결할 때, 추측이 아닌 증거와 기록을 바탕으로 결론을 내리는 것처럼, AI 가 만든 코드의 보안 문제도 재현 가능하고 검증 가능한 방식으로 찾아내자는 것입니다. 이는 AI 시대의 소프트웨어 보안을 단순히 "버그 찾기"가 아닌 "신뢰할 수 있는 감사"로 바꾸는 중요한 전환점입니다.

기술 요약

논문 요약: ESAA-Security (이벤트 소싱 기반 검증 가능한 AI 생성 코드 보안 감사 아키텍처)

1. 문제 정의 (Problem)

AI 보조 소프트웨어 생성은 개발 속도를 획기적으로 높였으나, 기능적으로 올바르더라도 구조적으로 보안이 취약한 시스템을 양산하는 새로운 공학적 문제를 야기했습니다. 기존 LLM(대규모 언어 모델) 을 활용한 프롬프트 기반 보안 검토는 다음과 같은 한계를 가집니다:

• 불균형한 커버리지: 검토 범위가 암묵적이고 일관성이 부족함.
• 약한 재현성: 동일한 프롬프트라도 결과가 달라짐.
• 검증 불가능한 발견: 취약점 발견이 근거 없는 서술에 그침.
• 불변 감사 추적의 부재: 변경 이력을 추적할 수 있는 불변의 감사 로그가 없음.
  특히 'Vibe Coding(감각적 코딩)'과 같은 AI 생성 코드 환경에서는 인증, 권한 부여, 입력 유효성 검사, 비밀 정보 처리 등 다양한 보안 영역에서 취약점이 발생할 위험이 높습니다.

2. 방법론 (Methodology)

ESAA-Security 는 AI 에이전트 기반 보안 감사를 '자유로운 대화'가 아닌 '계약과 이벤트에 의해 통제된 증거 기반 감사 프로세스' 로 재정의합니다. 핵심 아키텍처는 다음과 같습니다:

• 이벤트 소싱 (Event Sourcing) 및 CQRS:
  • 변경 가능한 저장소 스냅샷이 아닌, 부록 전용 (append-only) 이벤트 로그를 진실의 원천 (Source of Truth) 으로 삼습니다.
  • 에이전트는 상태 변경을 직접 수행하지 않고, 구조화된 의도 (Intentions) 를 발행하며, 오케스트레이터 (Orchestrator) 가 이를 검증하고 승인된 이벤트만 로그에 기록합니다.
• 통제된 실행 파이프라인 (Governed Execution Pipeline):
  • 감사는 4 단계로 구성됩니다:
    1. 정찰 (Reconnaissance): 기술 스택, 아키텍처, 공격 표면 식별.
    2. 도메인 감사 실행 (Domain Audit Execution): 플레이북 기반의 16 개 보안 도메인 및 26 개 태스크 수행.
    3. 위험 분류 (Risk Classification): 취약점 인벤토리, 심각도 분류, 위험 매트릭스 생성.
    4. 최종 보고 (Final Reporting): 기술적 수정 방안, 실행 요약, 최종 감사 보고서 생성.
  • 95 개의 실행 가능한 체크 (Executable Checks): 16 개의 보안 도메인 (비밀 정보, 인증, API 보안, AI/LLM 보안 등) 에 걸쳐 정의된 구체적인 체크리스트를 따릅니다.
• 검증 불변성 (Verification Invariants):
  • 작업 전 주장 (Claim-before-work): 작업 수행 전 태스크를 먼저 할당받아야 함.
  • 작업 후 완료 (Complete-after-work): 검증 증거와 함께 완료 상태를 발행해야 함.
  • 상태 일관성 및 잠금 소유권: 에이전트는 자신의 상태와 태스크 소유권을 명시해야 하며, 승인되지 않은 상태 전이는 거부됩니다.
  • 재플레이 (Replay) 및 해싱: 이벤트 로그를 재생하여 현재 상태를 재구성하고 무결성을 검증합니다.

3. 주요 기여 (Key Contributions)

1. 도메인 특화 아키텍처: ESAA 아키텍처를 AI 생성/수정 코드의 보안 감사를 위해 특화시킨 ESAA-Security를 제안합니다.
2. 통제된 감사 파이프라인 정의: 제약된 에이전트 출력, 부록 전용 이벤트 지속, 결정론적 재투영, 재플레이 기반 검증을 결합한 감사 프로세스를 정의합니다.
3. 구체적인 운영 모델: 4 단계, 26 개 태스크, 16 개 도메인, 95 개 실행 가능 체크로 감사를 구체화하여, 체크 레벨의 발견부터 최종 위험 중심 보고서까지 구조화된 산출물을 생성합니다.
4. 평가 프레임워크: 단순 취약점 나열이 아닌, 추적 가능성 (Traceability), 재현성 (Reproducibility), 커버리지 명시성, 산출물 완전성, 수정 방안 유용성을 평가 기준으로 제시합니다.

4. 결과 및 산출물 (Results & Outputs)

• 구조화된 증거: 각 발견 사항은 자유로운 텍스트가 아닌, 체크 식별자, 심각도, 코드 증거, 기술적 설명, 수정 가이드가 포함된 구조화된 객체로 생성됩니다.
• 위험 중심 보고서:
  • 취약점 인벤토리 및 위험 매트릭스: CRITICAL, HIGH, MEDIUM 등 심각도 분류와 CIA(기밀성, 무결성, 가용성) 영향도 분석을 기반으로 합니다.
  • 실행 요약 및 최종 보고서: 0~100 점의 보안 점수와 우선순위 위험을 포함한 관리자용 요약과, 기술적 수정 방안을 포함한 상세 보고서 (Markdown/JSON) 를 생성합니다.
• 감사 가능성: 최종 보고서는 무결성이 검증된 이벤트 시퀀스의 투영 (Projection) 이므로, 그 자체로 감사 가능한 (Auditable by construction) 특성을 가집니다.

5. 의의 및 중요성 (Significance)

• 패러다임 전환: AI 보조 보안 감사를 '프롬프트 엔지니어링'의 문제에서 **'통제된 실행 및 거버넌스'**의 문제로 전환했습니다.
• 신뢰성 확보: LLM 의 설득력 있는 서술이 아닌, 검증된 상태 전이와 이벤트 로그를 기반으로 하므로 감사 결과의 신뢰도와 재현성이 크게 향상됩니다.
• AI 생성 소프트웨어 대응: AI 가 생성하거나 수정한 코드의 빠른 개발 속도에 맞춰, 보안 검증의 속도와 정확성을 동시에 확보할 수 있는 실용적인 프레임워크를 제공합니다.
• 미래 지향성: 단순한 취약점 체크리스트를 넘어, CVSS 통합, 하이브리드 DAST, 규정 준수 매핑 등으로 확장 가능한 기반을 마련했습니다.

결론적으로, ESAA-Security 는 AI 시대의 소프트웨어 보안 감사가 단순한 '발견'을 넘어 '검증 가능한 프로세스'로 진화해야 함을 주장하며, 이를 실현하기 위한 기술적 아키텍처와 운영 모델을 제시합니다.