Q07. 웹의 요청·응답 본문 분석은 AI 보안의 핵심으로 보이는데, 왜 지금까지 이런 내용을 접하지 못했을까요?

By PLURA

A. 기술적 문제가 아니라, 구조적·인식적 한계 때문입니다. 🔥

이 질문의 배경에는 이미 앞선 Q&A에서 다룬 두 가지 오해가 자리하고 있습니다.

1️⃣ 개인정보 이슈에 대한 오해 (Q3)

많은 조직은
“요청본문·응답본문 로그를 수집하면 개인정보 문제가 발생한다”고 인식해 왔습니다.

하지만 Q3에서 설명했듯이, 이는

  • 마스킹
  • 부분 수집
  • 조건부 저장

등의 기술적 설계로 충분히 해결 가능한 과제입니다.

즉, 개인정보 이슈는
불가능한 문제라서 배제된 것이 아니라, 설계 논의가 부족했기 때문에 회피된 문제였습니다.

2️⃣ 로그량에 대한 오해 (Q1)

또 다른 이유는
“이전에는 없던 로그를 수집하면 시스템이 감당하지 못할 것”이라는 우려입니다.

하지만 현재의 서버 환경은:

  • 고효율 CPU
  • 대용량 Memory
  • 고속 SSD 기반 스토리지

를 기본 전제로 설계됩니다.

이러한 환경에서는
요청·응답 본문 로그 수집은 성능·비용 측면에서 더 이상 제약 요인이 아닙니다.

즉, 이 문제 역시
과거 환경 기준의 인식이 현재까지 관성적으로 이어진 결과입니다.

3️⃣ 컴플라이언스(ISMS)의 구조적 한계

ISMS와 같은 보안 컴플라이언스에서는
일반적으로 다음과 같이 요구합니다.

“로그를 저장하고, 관리하라.”

하지만 중요한 점은,
‘어떤 로그가 침해 대응에 필요한 로그인가’에 대한 논의가 거의 없었다는 사실입니다.

그 결과:

  • 웹 access.log
  • 방화벽 로그
  • 장비 이벤트 로그

가 ‘로그를 하고 있다’는 증빙 수단으로 자리 잡았고,
웹의 요청·응답 본문 데이터는 논의의 대상에서 자연스럽게 제외되었습니다.

4️⃣ 심리적 요인: 타당성의 착각 (Illusion of Validity)

여기에는 한 가지 중요한 인지적 편향이 작용했습니다.

타당성의 착각(Illusion of Validity)은
Daniel Kahneman이 설명한 대표적 편향 중 하나로,
정보의 실제 정확성이나 완전성보다
겉으로 보이는 일관성과 그럴듯함 때문에
사람이 과도한 확신을 가지게 되는 현상입니다.

즉,

데이터가 충분해서 신뢰하는 것이 아니라,
충분해 보이기 때문에 신뢰해 버리는 것입니다.

  • 정의:
    정보의 출처나 정확성보다,
    그 정보가 그럴듯한 패턴을 보일 때 과도한 확신을 갖는 편향

  • 로그 환경에서의 작용:
    웹 access.log는
    타임스탬프, IP, URL, 상태 코드(200 OK 등)라는
    전형적인 ‘전문적인 로그 형식’을 갖추고 있습니다.

그 결과 개발자와 운영자는
이 형식이 주는 신뢰감에 의해,

“이 정도 로그면 충분하다”

고 판단하게 되고,
정작 가장 중요한 요청·응답 본문 데이터가 빠져 있다는 사실을 간과하게 됩니다.

access.log와 본문 로그는 무엇이 다른가요?

구분 access.log 중심 요청·응답 본문 로그 포함
알 수 있는 것 시간, IP, URL, 상태 코드 실제 입력값, 응답 내용, 행위 맥락
공격 탐지 수준 접속 흔적 확인 공격 의도와 페이로드 확인
사고 설명 가능성 제한적 훨씬 높음
AI 분석 적합성 낮음 높음

즉, access.log는
“누가 어디에 왔는가” 정도는 보여주지만,
본문 로그는
“무엇을 하려고 했는가”를 보여줍니다.

보안에서 중요한 것은
바로 이 두 번째입니다.

실제로 어떤 문제가 생기나요?

예를 들어 access.log만 남아 있는 환경에서는
다음과 같은 상황이 자주 발생합니다.

  • /api/login 에 요청이 있었던 것은 아는데
    어떤 파라미터가 들어왔는지는 모름
  • /upload 에 POST 요청이 있었던 것은 아는데
    악성 스크립트가 포함됐는지는 모름
  • 상태 코드는 200인데
    실제로 어떤 응답이 반환됐는지는 모름

결국 사고가 나면
운영팀은 이렇게 말하게 됩니다.

“요청은 있었는데,
정확히 무슨 일이 있었는지는 알 수 없습니다.”

이 순간,
로그는 남아 있지만
분석할 정보는 없는 상태가 됩니다.

정리하면

웹의 요청·응답 본문 분석이 논의되지 못했던 이유는
기술이 부족해서가 아닙니다.

  • 개인정보 문제는 설계로 해결 가능
  • 로그량 문제는 이미 기술적으로 극복
  • 컴플라이언스는 로그의 ‘존재’만 요구
  • access.log는 타당성의 착각을 유발

결국 문제의 본질은 하나입니다.

우리가 무엇을 로그로 남겨야 하는지에 대한
합의와 정의가 없었기 때문입니다.

그래서 이제 무엇을 해야 할까요?

이제 필요한 것은
더 많은 장비가 아니라,
더 정확한 로그 정의입니다.

최소한 다음 질문에는 답해야 합니다.

  • 어떤 요청을 남길 것인가?
  • 어떤 응답을 남길 것인가?
  • 어떤 필드는 마스킹할 것인가?
  • 어떤 이상 행위가 발생하면 더 깊게 저장할 것인가?

즉, 보안은
“로그를 저장하고 있다”는 사실보다,

정말 공격을 설명할 수 있는 로그를 남기고 있는가
를 먼저 물어야 합니다.

“로그"에 대한 추가 논의는 아래 글을 참고해 주세요.

📚 로그 분석으로 해킹 조사하기는 신화(Myth)?
https://blog.plura.io/ko/column/myth/

Tags