AI가 혼자 행동할 때 로그가 전하지 못하는 것
출처: The New Stack
로그는 오랫동안 이상한 구덩이에 머물렀습니다: 기술적으로는 필요하지만 거의 읽히지 않고, 무언가가 깨질 때까지 대부분 잊혀져 있었습니다.
전형적인 패턴은 다음과 같았습니다: 엔지니어링 팀은 로그를 설정했는데, 이는 좋은 관행으로 여겨졌거나 감사가 체크리스트에 포함되어 있었기 때문이었습니다. 로그가 생성되었고, S3 버킷이나 보안 정보 및 이벤트 관리 시스템(SIEM), 서버의 평면 파일 등으로 이동했습니다. 이후 아무도 이를 확인하지 않았습니다. 팀이 소홀한 것이 아니라, 로그가 설계된 목적이 아니었기 때문입니다. 로그는 단순히 타임스탬프와 이벤트 ID, 그리고 의미를 파악하려면 실제 포렌식 수준의 인내심이 필요한 메타데이터의 덤dump였습니다.
아무도 로그를 뒤집는 시기는 사고가 발생한 후뿐이었습니다. 그리고 그때正是 격차가 드러나는 순간이었습니다: “우리는 우리가 해야 할 로그를 제대로 기록하고 있지 않았습니다.” 그 시점에서는 이미 늦었습니다. 공격자는 움직였고, 피해 범위는 불명확했으며, 조사는 불완전한 증거에 기반해 진행되었습니다.
“현재의 문제는 ‘whether you’re generating logs’가 아니라 ‘your logs가 실제로 의미 있는 정보를 제공하는지에 대한 것이다.’”
그 세상은 사라졌습니다. 현재는 로그를 생성하는 것이 아니라, 그 로그가 필요할 때 실제 정보로 telling 수 있는지가 문제입니다.
압력의 출처가 단일 방향에서 온 것이 아니었다
전환은 한 개의 규정이나 한 건의 사고에서 비롯된 것이 아니었습니다. 여러 측면에서 동시에 압박이 쌓이며 발생했습니다.
규제 프레임워크는 단순히 주장만으로는 충분하지 않음을 요구하기 시작했습니다. SEC의 공개 규칙은 공기업들이 보안 사고에 대해 어떻게 얘기해야 하는지 바꾸었습니다. NIS2 지침(EU 2022/2555)은 유럽의 핵심 인프라 전반에 걸쳐 기준을 높였습니다. 한때 로깅 정책 스크린샷으로 충분하다고 생각하던 감사관들은 이제 로그 자체를 보고 싶어 합니다. 로그는 쿼리 가능하고 타임스탬프가 표시되며 특정 이벤트에 연결되어 있어야 합니다.
동시에 개발자와 제품 팀은 사용 중인 도구에 대해 더 어려운 질문을 제기하기 시작했습니다. 엔지니어링 조직 내 보안 인식도 성숙해졌습니다.
신규 벤더를 평가하는 팀에는 보안 지향적인 엔지니어가 포함되며, 단순히 SOC 2 인증 여부만 묻는 것이 아니라 실제 보안 로깅이 어떻게 구현되어 있는지 확인하고자 합니다. 기업 조달도 동일한 흐름을 따릅니다. 보안 검토 설문지는 길어졌고, 법무·컴플라이언스 팀은 벤더 평가 중에 감사 로그 샘플을 인출하기 시작했습니다.
로그가 깨끗하고 내보낼 수 있는 액티비티 로그를 제공하지 못하는 제품은 두 년 전보다는 거래를 잃기 시작했습니다.
그리고는 AI‑ 기반 공격자입니다. 적대자는 지금까지보다 훨씬 빠르게 움직이며 실시간으로 포착하는 것이 점점 어려워지고 있습니다. 로그가 제공하는 것은 그다음 최선의 것: 그들이 어떻게 이동했는지, 무엇을 건드렸는지, 공격 패턴이 어떤 모습이었는지에 대한 기록입니다. 이 기록은 다음 공격을 설계하는 기반이 됩니다.
AI 에이전트는 이미 자원을 프로비저닝하고, 구매를 진행하며, 생산 환경 내 계정 설정을 변경하고 데이터를 삭제하고 있습니다. Gartner의 예측에서는 2028년까지 엔터프라이즈 소프트웨어 애플리케이션의 33%가 에이전트형 AI를 포함할 것이라고 예상합니다. 이는 2024년 less than 1%에 비해 크게 상승한 수치이며, 같은 해에 일상 업무 결정의 15%가 AI 에이전트에 의해 자율적으로 이루어진다고 봅니다.
그 모든 자율적 행동은 한 해 전에는 존재하지 않았던 잠재 감사 로그 항목입니다. 로깅 문제는 이제 인간이 한 일은만 다루는 것이 아니라, 에이전트가 한 일, 그들이 허가를 받은 사람, 그리고 해당 동작이 허용 범위 내에 있었는지 여부를 포함합니다.
데이터는 보안 팀이 느끼고 있던 것을 뒷받침합니다. [Verizon의 2026 데이터 유출 조사 보고서](https://www.verizon.com/business/resources/T161/reports/2026-dbirl-reports/2026- dbir-data-breach-investigations-report.pdf)는 22,000건 이상의 확인된 유출을 분석했으며, 초기 접근 단계에서 취약점 남용이 31%를 차지하고 있어, 보고서 19년 역사상 처음으로 인증 정보 악용을 넘어서게 되었습니다. 서드파티가 침해에 관여한 비율도 전년 대비 60% 상승해 전체 유출의 48%를 차지하게 되었습니다.
초기 접근이 이렇게 빠르고 외부 관계와 많이 연계되어 있을 때, 로깅 인프라가 사후 재구성의 여부를 결정합니다. 대략 3분의 1 정도가 패치하기 전 vulnerablity가 악용된 후 시작되며, 식별된 경우 평균 8개월이 소요됩니다. 로그는 추모서와 추측 사이의 차이를 만듭니다.
로그와 기록의 차이
모든 로깅은 동일하지 않으며, 이 차이는 감사관 앞이나 실제 사고 발생 시 팀이 깨닫기 전까지는 그 중요성을 인지하기 어렵습니다.
표면 수준 로깅은 단순히 “무언가가 일어났다”는 사실을 포착합니다. 진정한 감사 트레일은 전체 맥락을 담아 who가 동작을 수행했는지, 정확히 어떤 것이 변경되었는지, 언제 발생했는지, 요청이 어디서 왔는지, 그리고 시스템 상태가 이전과之后 어떻게 변했는지를 기록합니다.
이벤트 알림과 완전한 액티비티 기록 사이의 차이는 로그가 무엇인가 발생을 확인하는 로그와 실제 재구성이 가능한 로그 사이의 차이입니다.
행위자가 인간이 아닐 때 이 기준은 더 높아집니다. 인간만 있는 환경에서는 주변 행동을 통해 의도를 가끔 재구성할 수 있지만, 자율적으로 동작하는 AI 에이전트의 경우에는 그 맥락이 존재하지 않습니다. 감사 트레일은 유일한 진실입니다. 에이전트 세계에서 완전한 액티비티 기록을 얻으려면 단순히 동작 자체뿐 아니라 에이전트 신원, 시작된 인증 체인, 그리고 제약된 범위도 포착해야 합니다.
“인간만 있는 환경에서는 조사관이 주변 행동을 통해 의도를 재구성할 수 있지만, 자율 AI 에이전트가 동작할 때는 그 맥락은 존재하지 않는다.”
SOC 2는 이를 구체화합니다. 여러 Common Criteria 중 SOC 2 Type II는 시스템 접근 로깅, 데이터 및 구성 변경 추적, 그리고 기록이 변조 방지되며 시간 경과에 따라 보관된 증거를 요구합니다. 단순히 “사용자가 로그인했다”는 기록만으로는 충분하지 않습니다. 사용자, 타임스탬프, IP 주소, 세션 ID, 인증 방법이 표준인지 강화된 것인지 등을 포착하는 로그가 그 기준에 부합합니다.
실질적인 테스트는 간단합니다: 사고가 6개월 전에 발생했을 때, 여러분이 로그를 이용해 보드에 브리핑을 하거나 규제 대응을 하거나 포렌식 조사관에게 넘길 수 있을 정도로 명확한 시퀀스를 재구성할 수 있느냐 하는 것입니다. 답변이 확실하지 않다면 로그는 아직 운영 수준이 아닙니다.
실용적인 보안 로깅은 다음과 같은 필수 조건을 충족해야 합니다. 로그는 변조가 불가능해야 증거로 신뢰받을 수 있어야 하고, 구조화되어 있어 쿼리가 가능해야 하며, 올바른 이벤트를 포착해야 합니다. 여기에는 사용자 동작, 시스템 변경, 접근 권한 부여 및 해제, 설정 수정 등이 포함되며, 단순히 인증 이벤트만 기록하는 것은 충분하지 않습니다.
보존 기간도 중요한 고려사항입니다. 일부 도구는 30일의 핫 스토리지로 충분할 수 있지만, 사용 사례에 따라 조사가 실제로 필요로 하는 6개월 간의 컨텍스트가 있을 수도 있습니다. 모든 플랫폼이 동일하게 처리하지 않습니다. 일부는 계층적 보존 및 차가운 저장소 아카이브를 제공하고, 다른 일부는 기본 창을 초과하는 로그에 접근하기 위해 지원 티켓을 제출해야 합니다. 로그를 쉽게Retrieve할 수 있다면, 사고 및 조사 시 도구의 신뢰도가 상승하고, 이에 의존하는 보안 팀의 경험도 개선됩니다.
