AI가 97% 확신한다면, 서버를 격리해도 될까?

AI 의사결정의 신뢰성과 보안을 위한 AWS 아키텍처

핵심 메시지: AI가 반환한 확률은 판단을 지원하는 신호이지 실행 권한이 아니다. 신뢰할 수 있는 자동화는 입력의 무결성, 독립적인 검증, 권한 분리, 감사 추적, 사람의 통제를 함께 설계할 때 가능하다.

생성형 AI를 처음 서비스에 도입할 때 고민은 주로 답변의 품질이었다. 질문에 적절히 응답하는가? 부정확한 정보를 만들어 내지는 않는가? 하지만 AI가 보안 경보를 판단하고 시스템에 직접 조치를 요청하는 단계에서는 질문이 달라진다. “이 답변이 맞는가?”를 넘어 “이 판단을 실행해도 되는가?”가 더 중요해진다.

예를 들어 한 AI가 보안 이벤트를 분석한 뒤 다음과 같은 결과를 반환한다고 가정해 보자.

{
  "action": "isolate_instance",
  "target": "i-0example1234567890",
  "confidence": 0.97
}

구조화된 응답이라 자동화 코드에 연결하기는 쉽다. 그러나 97%라는 수치만으로 실제 침해 여부가 검증되거나 해당 인스턴스를 격리할 권한이 정당화되는 것은 아니다. 판단에 사용된 로그가 변조되었거나, 대상 서버가 업무상 중요한 프로덕션 시스템이라면 오탐 한 번이 서비스 장애로 이어질 수 있다. 여기서 97%는 설명을 위한 가상의 예시이며 Jev의 실측 정확도나 보안 성능을 뜻하지 않는다.

이 글은 IBM Technology의 영상 The Problem with Jev: Can You Trust AI Decisions?에서 제기한 질문을 출발점으로 삼는다. Jev의 내부 구현이나 실제 취약점이 발견되었다고 주장하는 글은 아니다. 대신 AI 의사결정을 신뢰 가능한 시스템으로 만드는 제어 장치를 AWS에서 어떻게 설계할 것인가에 집중한다.

1. Jev가 보여주는 변화: 텍스트 생성에서 의사결정으로

TypeSafe AI의 Jev는 회사가 System One Model이라고 부르는 접근법의 모델이다. 서비스나 애플리케이션이 상황 정보와 집중된 질문을 전달하면, 모델은 선택지·점수·예/아니요 확률 등 타입이 정해진 결정 결과를 반환하도록 설계됐다. 개발사는 이를 소프트웨어의 분기 로직에 직접 연결할 수 있다는 점을 강조한다. TypeSafe AI의 Jev 소개 · TypeSafe AI 공식 발표

일반적인 LLM 기반 업무 흐름에서는 자연어 응답을 해석하거나 특정 스키마로 변환하는 단계가 자주 필요하다. Jev와 같은 결정 모델은 애초에 구조화된 출력을 중심으로 설계됐다는 점에서 다르다. 다만 이것은 제품과 사용 목적의 차이이지, 모든 LLM이 구조화된 결과를 만들지 못한다는 의미는 아니다.

비교 항목	일반적인 LLM 활용 패턴	Jev와 같은 구조화된 결정 모델
주로 기대하는 출력	설명문·요약·대화 또는 구조화된 결과	선택·점수·확률 등 타입이 정해진 결정
애플리케이션 연결	응답 해석 또는 구조화 출력 검증	타입 검증 후 분기 로직에 연결
보안상 핵심 질문	생성된 내용이 정확한가?	판단의 근거가 타당하고 실행이 허용되는가?
공통적으로 필요한 통제	입력 검증, 접근 제어, 운영 모니터링	입력 검증, 접근 제어, 운영 모니터링

여기서 타입 안정성(Type Safety)과 사실의 정확성(Accuracy)은 서로 다른 속성이다. action 필드에 미리 정의한 문자열만 들어왔다는 사실은 그 조치가 옳다는 증거가 아니다. 개발사가 강조하는 확률 보정(calibration) 역시 실제 운영 데이터에서 별도로 검증해야 하며, 개별 요청의 결론을 설명하거나 입증해 주지는 않는다.

2. Confidence ≠ Evidence: 높은 확신이 곧 검증은 아니다

모델이 반환하는 confidence: 0.97은 모델이 표현한 확신 또는 확률 추정값이다. 이를 곧바로 “이 사건은 97%의 확률로 실제 공격이다” 또는 “동일 조건에서 항상 97% 정확하다”고 해석해서는 안 된다. 확률 수치가 실제 빈도와 잘 맞는지 확인하려면 운영 데이터와 정답 레이블을 활용한 별도의 calibration 및 정확도 평가가 필요하다. 데이터 분포가 바뀌면 과거 검증 결과도 약해질 수 있다.

보안 운영에서는 점수보다 다음 정보가 더 중요할 수 있다.

근거의 출처: 탐지 결과가 GuardDuty에서 왔는가, 외부 로그에서 왔는가? 출처를 검증할 수 있는가?
근거의 독립성: 서로 다른 두 신호라고 해도 사실은 동일한 원본 로그에서 파생된 것은 아닌가?
근거의 최신성과 무결성: 데이터의 수집 시각, 변조 가능성, 누락 여부를 확인했는가?
업무 영향: 격리 대상이 개발용 EC2인가, 고객 트래픽을 처리하는 프로덕션 서버인가?
실행 권한: 판단을 내리는 모델과 조치를 실행하는 주체의 권한이 분리되어 있는가?

즉, 모델은 유용한 판단 신호를 제공할 수 있지만, 증거 수집·사실 확인·실행 승인까지 혼자 맡아서는 안 된다. NIST AI Risk Management Framework 역시 신뢰 가능한 AI를 정확성뿐 아니라 안전성, 보안·복원력, 투명성, 책임성 등 여러 특성의 조합으로 다룬다. NIST AI RMF

3. AI 의사결정 시스템의 공격 표면은 어디에 있을까?

위험을 AI 모델 자체의 오류로만 이해하면 중요한 부분을 놓친다. 실제 자동화는 이벤트 수집 → 데이터 가공 → 모델 판단 → 정책 검증 → 권한 행사라는 여러 신뢰 경계를 지난다. 공격자는 이 경계 가운데 가장 약한 곳을 노릴 수 있다.

위협	예시 상황	필요한 대응
입력 데이터 오염	보안 로그·메타데이터가 변조되어 정상 서버가 의심 대상으로 분류됨	출처 검증, 교차 확인, 원본 보존
간접 프롬프트 인젝션	LLM 기반 에이전트가 외부 텍스트의 지시를 명령처럼 해석함	비신뢰 데이터와 지시의 분리, 도구 권한 제한
과도한 실행 권한	AI 판단이 광범위한 IAM 권한을 가진 실행 경로로 곧바로 전달됨	최소 권한, 허용된 Runbook, 독립적 정책 게이트
판단 기준 변화	모델 버전 또는 입력 분포가 바뀌면서 오탐률이 서서히 상승함	성능·드리프트 모니터링, 버전 고정, 재검증
감사 공백	실행 결과는 남았지만 어떤 근거로 격리했는지 재구성할 수 없음	상관관계 ID와 증거 참조를 포함한 별도 감사 기록

여기서 프롬프트 인젝션은 주로 지시를 해석하는 LLM·에이전트 구성에 해당하는 위협이며, Jev의 특정 취약점이라고 단정할 근거는 없다. 반면 입력 무결성, 과도한 권한, 검증 없는 자동 실행 문제는 모델의 종류와 관계없이 발생할 수 있다. OWASP의 Excessive Agency 지침도 과도한 기능·권한·자율성을 제한하고, 영향이 큰 조치에는 독립적 승인 경로를 두라고 권고한다. OWASP LLM06: Excessive Agency

특히 위험한 시나리오는 개별 판단이 명백히 틀린 경우만이 아니다. 오탐률이 조금씩 높아져도 각각의 판단은 그럴듯해 보일 수 있다. IBM 영상이 강조하는 Observability는 단지 메트릭 수집이 아니라, 왜 특정 조치가 실행됐는지 사후에 재구성할 수 있는 능력에 가깝다.

4. AWS 아키텍처: AI 판단과 실행 사이에 검증 계층 두기

이제 보안 이벤트를 분류한 뒤 EC2 격리 여부를 결정하는 상황을 가정해 보자. 아래 아키텍처는 Jev의 공식 AWS 레퍼런스 구현이나 실제 구축 사례가 아닌 설계 예시다. 모델은 TypeSafe API와 같은 외부 결정 모델 또는 조직이 선택한 다른 모델로 대체할 수 있다.

참조 아키텍처 구성

단계	AWS 서비스	핵심 통제
1. 탐지·수집	Security Hub CSPM → EventBridge	이벤트 필터링, 멱등성
2. 입력·자산 검증	Lambda + DynamoDB	출처·최신성·중복·독립 증거 확인
3. AI 판단	Model Adapter Lambda → 결정 모델	최소 데이터 전달 및 출력 스키마 검증
4. 실행 정책 판정	Policy Gate + Step Functions	독립 정책, 고위험 조치 승인 분기
5. 승인·제한된 실행	Step Functions → Systems Manager Automation	사람 승인, 제한된 Runbook, 최소 권한
6. 관측·감사	CloudWatch + CloudTrail + S3	결정 및 정책 로그와 AWS API 감사 연계

그림을 대신한 아키텍처 표: 모든 단계는 동일한 decision_id로 연결한다. 운영 배포 검증이 아닌 설계 예시다.

4.1 탐지와 이벤트 수집: Security Hub CSPM + EventBridge

Amazon GuardDuty 등 탐지 서비스에서 생성된 결과가 Security Hub CSPM에 집계되는 구성을 생각해 보자. Security Hub CSPM은 신규 또는 업데이트된 finding을 EventBridge로 전달할 수 있다. EventBridge 규칙은 필요한 이벤트만 필터링해 검증용 Lambda 또는 Step Functions 워크플로로 전달한다. AWS 공식 문서: Security Hub CSPM의 EventBridge 통합

Security Hub CSPM에서 제공하는 Security Hub Findings - Imported 이벤트를 대상으로 하는 패턴은 다음과 같이 작성할 수 있다.

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"]
}

주의할 점: 이 예시는 Security Hub CSPM 이벤트용 패턴이다. 새 Security Hub의 Findings Imported V2는 다른 detail-type을 사용하므로 혼용하거나 두 규칙을 중복 활성화하면 같은 사실에 대한 중복 처리가 발생할 수 있다. 또한 이벤트 재전송을 고려해 finding ID·업데이트 버전·조치 유형을 조합한 멱등성 키를 DynamoDB 등에 기록해야 한다. CSPM 이벤트 형식 · Security Hub V2 이벤트 형식

4.2 입력 검증과 증거 보강: AWS Lambda + DynamoDB

Lambda는 모델을 호출하기 전에 필수 필드, 계정/리전, 리소스 ID, 이벤트 생성 시각, 허용된 소스, 중복 여부를 확인한다. 여기서 Security Hub finding 하나를 그대로 ‘독립적인 증거 두 개’로 취급해서는 안 된다. 가능하다면 다른 수집 경로의 텔레메트리, 자산 중요도, 현재 EC2 상태를 확인해 증거의 출처·일관성·최신성을 점검한다.

이 단계에서 감사용 decision_id를 생성하고 원본 finding의 참조를 보존한다. 모델에는 최소한의 필요한 정보만 전달하고, 개인정보·비밀값·자격 증명은 제거하거나 마스킹한다. 외부 모델 API를 사용할 경우 네트워크 송신 경로, 데이터 처리 정책, 비밀 키 저장(예: AWS Secrets Manager)을 함께 검토해야 한다.

4.3 AI는 제안하고, 정책은 승인한다: Model Adapter + Policy Gate

모델 Adapter Lambda는 입력을 모델 전용 형식으로 변환하고, 반환값을 허용된 스키마로 검증한다. 이후 정책 게이트는 모델이 제안한 action을 독립적으로 평가한다. 이를테면 개발 환경의 알림은 자동 처리할 수 있지만, 프로덕션 EC2의 네트워크 격리는 사람이 확인하도록 정할 수 있다.

조건	기본 처리 예시
출력 형식이 잘못됐거나 근거가 누락됨	실행 금지, 보안 담당자 검토 큐로 전달
일반 알림 또는 티켓 생성	정책 검증 후 자동 실행 가능
개발 환경의 격리 요청	자산 허용 목록·독립 증거·사전 승인된 Runbook 확인
프로덕션 서버 격리, 권한 회수 등 고영향 조치	모델 점수와 무관하게 사람의 승인 필요
모델 API 장애 또는 정책 판단 불가	자동 조치 대신 알림·수동 조사 경로로 전환

다음은 정책 분리의 개념을 보여주는 Python 예시다. 실제 배포에서는 인증된 자산 메타데이터, 재검증 가능한 증거, IAM 통제와 함께 구현해야 한다.

def authorize_model_proposal(proposal: dict, context: dict) -> str:
    allowed = {"notify", "isolate_instance"}
    action = proposal.get("action")
    confidence = proposal.get("confidence")

    if action not in allowed:
        return "REJECT"
    if type(confidence) not in (int, float) or not 0 <= confidence <= 1:
        return "REJECT"
    if not context.get("verified_inputs", False):
        return "HUMAN_REVIEW"
    if not context.get("independent_evidence", False):
        return "HUMAN_REVIEW"

    # 저위험 알림만 자동 실행한다.
    if action == "notify":
        return "AUTO_NOTIFY"

    # 운영 자산에 대한 격리는 확률과 관계없이 승인받는다.
    if context.get("environment") == "production":
        return "HUMAN_REVIEW"

    # 비운영 환경의 격리 역시 사전 승인된 워크플로에서만 실행한다.
    if not context.get("approved_runbook", False):
        return "HUMAN_REVIEW"
    return "APPROVED_RUNBOOK_ONLY"

이 코드에서 confidence는 유효성 검사는 하지만 독자적인 실행 허가 조건으로 사용하지 않는다. 예를 들어 0.97이라는 숫자만으로 프로덕션 서버 격리를 통과시킬 수 없다. 실제 자동화 허용 수준은 위험 수용 기준과 과거 운영 데이터 평가를 통해 정책 소유자가 결정해야 한다.

4.4 인간 승인과 안전한 실행: Step Functions + Systems Manager

AWS Step Functions Standard Workflow를 사용하면 단계별 상태 전이를 관리할 수 있다. 고영향 작업은 .waitForTaskToken 콜백 패턴으로 승인을 기다렸다가 인증된 승인 시스템이 SendTaskSuccess 또는 SendTaskFailure를 호출하도록 구성할 수 있다. 이때 task token은 권한을 가진 비밀값이므로 공개 URL이나 일반 로그에 노출하지 않아야 하며, 승인자의 신원·역할·만료 시각·대상 리소스를 별도로 검증해야 한다. Step Functions 콜백 패턴 · AWS 인간 승인 예제

승인 이후에는 임의 셸 명령을 실행하기보다 검토된 Systems Manager Automation Runbook으로 조치 범위를 제한하는 편이 안전하다. 실제 EC2 격리에서는 네트워크 설정 변경이 기존 연결이나 복구 경로에 미칠 영향도 사전 평가해야 한다. 실행 IAM Role은 허용된 리소스와 작업에만 접근하도록 최소 권한으로 구성하고, 승인과 실행 권한을 분리한다. AWS 보안 사고 대응 참고 설계

4.5 Observability와 Audit Trail은 별도로 설계한다

여기서 가장 중요한 것은 세 가지 기록을 구분하는 것이다.

기록 계층	목적	AWS 서비스 예시
의사결정 기록	어떤 입력·근거·모델·정책으로 어떤 판단이 나왔는가	Lambda 구조화 로그, DynamoDB, Amazon S3
워크플로 기록	어느 단계에서 검증·승인·거절·실행됐는가	Step Functions Standard 실행 이력, CloudWatch Logs
AWS API 감사	누가/어떤 역할이 어떤 AWS API를 호출했는가	AWS CloudTrail

CloudTrail만 활성화한다고 AI의 판단 근거가 자동으로 기록되지는 않는다. 모델의 내부 판단 근거를 재현할 수 없더라도, 적어도 시스템이 모델에 어떤 데이터를 전달했고 어떤 정책을 적용했는지는 애플리케이션 계층에서 남겨야 한다. Step Functions Standard는 실행 이력을 기록하지만 이력 보존 기간에는 제한이 있으므로 장기 감사 요건은 별도 저장으로 충족해야 한다. 중요 감사 기록은 버전 관리와 S3 Object Lock 같은 변조 방지 통제도 검토할 수 있다. Step Functions 로깅 · CloudTrail 연동 · S3 Object Lock

다음은 한 번의 판단에 연결해 저장할 예시 감사 이벤트다. evidence_refs에는 원본 데이터 전체를 복제하기보다 접근 제어된 보관 위치나 해시를 참조하는 방식을 권장한다.

{
  "decision_id": "dec-example-001",
  "finding_id": "finding-example-001",
  "model": {"provider": "example", "version": "pinned-version"},
  "proposal": {"action": "isolate_instance", "confidence": 0.97},
  "evidence_refs": ["s3://audit-bucket/evidence/a.json"],
  "policy_version": "policy-2026-10",
  "policy_result": "HUMAN_REVIEW",
  "approved_by": null,
  "execution_status": "NOT_EXECUTED",
  "trace_id": "trace-example-001"
}

메트릭 역시 단순 요청 수와 처리 시간에 그쳐서는 안 된다. 오탐률, 승인 반려 비율, 사람의 재판단 비율, 입력 검증 실패율, 모델 버전별 점수 분포, 근거 누락 비율, 미처리 승인 건수, 사고 후 복구 시간을 모니터링해야 한다. 실제 레이블이 수집되는 시점이 늦다면 지연을 감안한 품질 평가 프로세스를 따로 두는 것이 필요하다.

5. 운영 도입 전 점검할 7가지 질문

모델 응답이 아니라 확인 가능한 원본 증거를 기준으로 실행하는가?
같은 원본에서 파생된 신호를 독립된 증거로 잘못 계산하고 있지 않은가?
AI 모델과 최종 실행 주체의 권한이 분리되어 있는가?
프로덕션 격리·권한 회수 등 고영향 조치에 승인 또는 사전 승인된 통제가 있는가?
중복 이벤트·모델 장애·입력 검증 실패 시 안전한 수동 경로가 있는가?
decision_id로 입력, 모델 버전, 정책 버전, 승인자, AWS API 실행을 연결해 추적할 수 있는가?
모델과 데이터의 변화가 운영 오탐률 및 비즈니스 영향에 미치는 효과를 지속적으로 측정하는가?

이 질문 중 여러 개에 답할 수 없다면 자동 조치 범위를 넓히기보다 우선 관찰 모드(Shadow Mode)로 모델 판단과 담당자 결정을 비교하는 편이 합리적이다. 이후 저위험 알림부터 자동화하고, 검증된 Runbook을 거쳐, 영향이 큰 조치에 대해서만 명확한 승인 절차를 적용하는 식으로 단계적으로 확장할 수 있다.

6. 결론: 모델의 판단을 신뢰하지 말라는 뜻이 아니다

Jev와 같은 구조화된 의사결정 모델은 AI를 소프트웨어의 자동화 흐름에 연결하는 흥미로운 방향을 보여준다. 하지만 타입이 명확한 결과와 높은 확률이 안전한 실행을 보장하는 것은 아니다. 모델이 정해진 출력 형식에 맞게 답했는지와 실제 현실을 올바르게 판단했는지, 그리고 그 판단을 실행해도 되는지는 별개의 질문이다.

따라서 목표는 모델을 무조건 불신하는 것이 아니라, 모델이 틀려도 시스템이 안전하게 동작하도록 설계하는 것이다. 입력은 검증하고, 서로 독립적인 증거를 확인하고, 의사결정과 실행 권한을 분리하고, 고위험 작업은 승인 경로를 거치며, 전 과정을 감사할 수 있어야 한다.

IBM 영상의 마지막 메시지를 AWS 운영 관점으로 바꾸면 이렇게 정리할 수 있다.

AI가 어떤 결정을 내렸는가보다, 우리는 그 결정의 근거와 실행 과정을 검증할 수 있는가가 중요하다.

참고자료

IBM Technology, The Problem with Jev: Can You Trust AI Decisions? (2026-10-20)
TypeSafe AI, What is Jev? 및 Introducing System One Models & Jev
NIST, AI Risk Management Framework
OWASP, LLM06:2025 Excessive Agency
AWS, Security Hub CSPM and EventBridge
AWS, Step Functions Service Integration Patterns
AWS, Step Functions Logging to CloudWatch Logs
AWS, S3 Object Lock

작성 기준일: 2026년 10월 27일. 서비스 기능·이벤트 형식·권한 설정은 실제 운영 계정의 구성 및 사용하는 AWS 제품 버전에 맞춰 검증해야 한다.