[전자신문] 보안의 출발점은 기록이다

By PLURA 2026-04-05

2025년 국내 해킹 사건들을 돌아보면, 대응 과정에서 반복적으로 드러난 공통점이 있습니다.
사고가 접수되고, 조사가 시작되고, 수개월이 지난 뒤 결과가 발표됩니다.
그런데 정작 발표의 핵심은 놀라울 만큼 비슷합니다.

“로그가 충분하지 않아 정확한 조사에 한계가 있었다.”

이 한 문장은 단순한 실무상의 아쉬움이 아닙니다.
지금 우리의 정보보안 체계가 어디에서 무너지고 있는지를 보여 주는 핵심 진단입니다.

공격은 분명히 발생했습니다.
시스템은 침해되었습니다.
때로는 개인정보가 유출되었고, 때로는 중요 시스템이 장악되었습니다.

하지만 정작 우리는 그 다음 질문에 제대로 답하지 못합니다.

누가 들어왔는가
언제 들어왔는가
어떤 계정을 사용했는가
어떤 내부 경로를 이동했는가
실제로 무엇을 조회했고, 무엇을 외부로 반출했는가

사건은 있었지만, 사건을 설명할 근거가 없는 것입니다.

이것이야말로 오늘날 정보보안의 가장 큰 취약점입니다.

왜 해킹보다 더 심각한 문제가 ‘설명할 수 없음’인가

많은 조직은 해킹을 “막지 못한 사건”으로만 이해합니다.
물론 침해 자체도 심각합니다.
그러나 실제로는 그 다음 단계가 더 치명적일 수 있습니다.

공격을 당한 뒤에도 그 실체를 설명하지 못하는 상태입니다.

설명하지 못하면 판단할 수 없습니다.
판단할 수 없으면 대응할 수 없습니다.
대응할 수 없으면 같은 공격은 반복됩니다.

결국 로그가 부족한 사고 대응은 다음과 같은 구조로 흘러갑니다.

침해 정황은 존재한다.
일부 흔적은 발견된다.
하지만 전체 흐름은 보이지 않는다.
그래서 다수의 결론이 추정에 머무른다.
재발 방지 대책도 원인 중심이 아니라 일반론으로 끝난다.

이런 방식으로는 결코 보안 수준이 올라가지 않습니다.
사고를 겪고도 배우지 못하기 때문입니다.

배우지 못하는 이유는 단순합니다. 기록이 없기 때문입니다.

정보보안의 출발점은 제품이 아니라 로그다

보안 업계는 오랫동안 수많은 제품과 개념을 이야기해 왔습니다.

방화벽
웹방화벽
EDR
백신
인증
망분리
SIEM
SOAR
XDR
SASE
ZTNA

이 모든 것이 무의미하다는 뜻은 아닙니다.
분명 각각의 역할이 있습니다.

하지만 그 어떤 제품도 기록이 없는 환경에서는 결정적인 한계를 가질 수밖에 없습니다.

왜냐하면 보안의 핵심 판단은 결국 로그에서 시작되기 때문입니다.

해킹이 실제로 있었는가
데이터 유출이 있었는가
내부 확산이 있었는가
관리자 권한 탈취가 있었는가
대응이 적절했는가

이 모든 질문은 로그를 근거로 답해야 합니다.

로그가 없으면 분석은 추정이 됩니다.
로그가 부족하면 대응은 감에 의존하게 됩니다.
로그가 부정확하면 경영진 보고, 고객 통지, 법적 대응, 재발 방지 모두 흔들립니다.

그래서 정보보안의 출발점은 제품 도입이 아니라,
무엇을 남길 것인지 먼저 정하는 일이어야 합니다.

로그는 자동으로 남지 않는다

많은 사람들이 여기서 중요한 오해를 합니다.

“시스템은 원래 로그를 남기는 것 아닌가?”

부분적으로는 맞습니다.
하지만 정말 필요한 수준의 보안 로그는 대부분 자동으로 충분히 남지 않습니다.

운영체제, 서버, 애플리케이션, 웹 서비스는
관리자가 직접 다음을 결정해야 합니다.

어떤 이벤트를 감사할 것인지
어떤 수준까지 기록할 것인지
얼마나 오래 보관할 것인지
어떤 형식으로 수집할 것인지
어떤 시스템과 연계해 분석할 것인지

즉, 로그는 자연스럽게 생기는 결과물이 아니라
의도적으로 설계하고 설정해야 확보되는 데이터입니다.

이 차이를 이해하지 못하면 사고가 나더라도 남는 것은 아주 단편적인 흔적뿐입니다.

예를 들어 운영체제에서 다음과 같은 항목이 충분히 기록되지 않으면,
공격자의 실제 행위를 재구성하기 어렵습니다.

계정 생성 및 사용
권한 상승 및 권한 변경
프로세스 실행
서비스 등록 및 변경
예약 작업 등록
원격 접속 흔적
파일 접근 및 실행
명령행 인자(Command Line)
네트워크 연결

이 중 하나라도 빠지면 분석의 연결고리가 끊어집니다.

해킹은 이제 ‘URL 한 줄’로 설명되지 않는다

웹 서비스 영역은 더 복잡합니다.

과거에는 접근 로그의 URL, IP, 상태 코드 정도만 봐도
일부 공격의 흐름을 파악할 수 있었습니다.
그러나 지금의 공격은 그렇게 단순하지 않습니다.

오늘날 공격자는 다음과 같은 영역에 흔적을 숨깁니다.

HTTP 요청 본문(Request Body)
JSON / GraphQL / API 호출 데이터
파일 업로드 내용
인증 토큰 사용 흐름
응답 데이터(Response Body)
비정상 다운로드 패턴
세션 및 권한 오용 흔적

즉, 단순한 access log만으로는 실제 공격 행위를 이해하기 어려운 시대가 되었습니다.

예를 들어 공격자가 정상 로그인 이후에
대량 조회, 비정상 다운로드, API 오용, 데이터 수집을 수행했다면
URL 몇 줄만으로는 이를 판별하기 어렵습니다.

또한 웹쉘 업로드, 인증 우회, 계정 탈취 기반의 내부 조회,
세션 재사용 같은 행위도 요청·응답의 맥락을 함께 봐야 드러나는 경우가 많습니다.

그래서 이제 웹 보안에서 중요한 질문은 단순합니다.

우리는 요청과 응답의 실제 행위를 볼 수 있도록 기록하고 있는가.

이 질문에 답하지 못하면
웹 서비스 보안은 겉으로만 운영되는 경우가 많습니다.

기록이 없으면 사고 조사는 왜 반복해서 실패하는가

각 기관과 기업은 오랫동안 제각기 다른 방식으로 로그를 운영해 왔습니다.

어떤 곳은 운영체제 기본 로그만 남기고,
어떤 곳은 웹 접근 로그만 남기고,
어떤 곳은 보관 기간이 너무 짧고,
어떤 곳은 중앙 수집은 하지만 필요한 필드가 빠져 있습니다.

그 결과 해킹이 발생하면 항상 비슷한 문제가 되풀이됩니다.

초기 침투 지점은 추정만 가능하다.
계정 탈취 여부를 확정하기 어렵다.
내부 확산 범위를 좁히지 못한다.
데이터 유출 여부를 증명하지 못한다.
정확한 피해 범위를 특정하지 못한다.

이 상태에서는 정부 조사도, 자체 조사도, 외부 감사도 모두 한계를 가질 수밖에 없습니다.

사고는 분명히 존재했는데
그 사고를 설명할 근거가 없기 때문입니다.

우리는 많은 실수와 실패를 통해 교훈을 쌓아 왔다고 말합니다.
하지만 사이버보안에서는 그 축적이 제대로 이루어지지 못하는 경우가 많습니다.

왜냐하면 교훈은 기억으로 남는 것이 아니라
기록을 통해 재구성되어야 하기 때문입니다.

지금 부족한 것은 장비가 아니라 ‘표준 로그 기준’이다

지금 현장에서 정말 필요한 것은
새로운 유행어를 입힌 솔루션 이름이 아닙니다.

더 먼저 필요한 것은
무엇을 기록해야 하는지에 대한 표준입니다.

국가 지침과 각종 인증 기준에는 대체로
“로그를 관리해야 한다”는 문장이 들어 있습니다.
하지만 현장에서는 이것만으로 충분하지 않습니다.

현장에 필요한 것은 선언이 아니라 기준입니다.

예를 들어 다음과 같은 질문에 답할 수 있어야 합니다.

운영체제에서는 무엇을 기록해야 하는가

계정 생성, 삭제, 활성화, 비활성화
관리자 권한 부여 및 변경
프로세스 실행과 명령행 인자
원격 로그인 및 인증 실패
서비스/드라이버 등록 및 변경
예약 작업, 지속성 확보 행위
중요 파일 접근 및 변경
대량 파일 접근 및 압축/전송 행위

웹 서비스에서는 무엇을 기록해야 하는가

요청 본문(Request Body)
응답 결과(Response)와 주요 반환 정보
로그인, 세션 발급, 권한 상승 흐름
파일 업로드 및 다운로드
비정상 API 호출 패턴
대량 조회, 대량 응답, 반복 요청
데이터 유출 의심 행위
관리자 기능 호출 이력

분석을 위해 어떤 관점이 필요한가

단순 이벤트 수집이 아니라 공격 행위 중심
MITRE ATT&CK 등 실제 전술·기술 기준 반영
탐지뿐 아니라 사후 조사까지 고려한 필드 설계
장기 보관과 재검색이 가능한 구조

이러한 기준이 없으면 조직마다 로그 수준이 달라지고,
결국 사고 대응 품질도 들쭉날쭉해질 수밖에 없습니다.

정부가 먼저 해야 할 일은 인증 강화가 아니라 로그 가이드라인이다

지금 필요한 정책 전환은 분명합니다.

인증 항목을 더 늘리는 것보다 먼저, 표준 로그 가이드라인을 마련해야 합니다.

왜냐하면 인증이 강화되어도
정작 사고를 분석할 수 있는 기록이 없다면
그 보안은 실제 침해 대응 관점에서 매우 취약하기 때문입니다.

표준 로그 가이드라인은 최소한 다음 방향을 포함해야 합니다.

1. 운영체제 로그 기준의 구체화

운영체제 보안 로그는 단순 시스템 이벤트 수준이 아니라
실제 공격 행위 재구성이 가능한 수준으로 정리되어야 합니다.
MITRE ATT&CK 같은 실제 공격 프레임워크를 기준으로
어떤 행위를 반드시 남겨야 하는지 정의해야 합니다.

2. 웹 로그 기준의 현실화

오늘날의 공격은 URL만으로 보이지 않습니다.
따라서 요청 본문, 응답 데이터, 인증 흐름, 다운로드 행위 등
실제 공격과 유출 분석에 필요한 웹 로그 기준이 포함되어야 합니다.

3. 유출 분석 중심의 기록 항목 확대

단순 침입 탐지만으로는 부족합니다.
파일 접근, 다운로드, 대량 전송, 외부 반출 정황 등
사고 이후 “무엇이 실제로 나갔는가”를 설명할 수 있는 기준이 필요합니다.

4. 선언형 지침이 아니라 실행 가능한 기준 제시

“로그를 남겨라”가 아니라
어떤 이벤트를, 어떤 필드로, 어떤 기간 동안, 어떤 방식으로
수집·보관·분석해야 하는지까지 구체화해야 합니다.

이 기준이 마련되어야
보안 정책이 현장에서 실제로 작동하기 시작합니다.

보안 수준은 장비 숫자가 아니라 증명 능력으로 결정된다

많은 조직이 보안 수준을
도입한 제품의 개수나 예산 규모로 설명하려고 합니다.

하지만 침해사고 앞에서는 훨씬 더 본질적인 질문이 남습니다.

우리는 무엇을 기록하고 있는가
우리는 무엇을 분석할 수 있는가
우리는 무엇을 증명할 수 있는가

바로 이 세 가지가 실제 보안 수준을 결정합니다.

장비가 많아도 기록이 없으면
공격 경로를 설명하지 못합니다.

솔루션이 화려해도 분석 근거가 없으면
유출 범위를 특정하지 못합니다.

인증을 통과해도 증명 자료가 없으면
사고 대응은 결국 추정과 해명 수준에 머무를 수밖에 없습니다.

그래서 보안의 수준은 장비 숫자가 아니라
증명 가능한 기록의 수준으로 판단해야 합니다.

2025년의 교훈은 분명하다

2025년의 여러 해킹 사건은 우리에게 같은 질문을 남겼습니다.

“우리는 정말 사고를 이해할 수 있을 만큼 기록하고 있었는가?”

이 질문에 자신 있게 답할 수 있는 조직은 많지 않을 것입니다.

보안을 잘한다는 것은
제품을 많이 도입했다는 뜻이 아닙니다.

보안을 잘한다는 것은
사고가 발생했을 때 다음을 설명할 수 있다는 뜻입니다.

최초 침투 경로
공격자 행위 흐름
사용된 계정과 권한
내부 이동 범위
실제 유출 정황
대응 조치와 재발 방지 근거

이 모든 설명은 로그 위에서만 가능합니다.

결국 2025년이 남긴 가장 큰 교훈은 이것입니다.

우리는 공격을 막는 기술만이 아니라, 공격을 이해할 수 있는 기록 체계부터 다시 세워야 한다.

맺음말

이제는 원리로 돌아가야 합니다.

보안의 제1원칙은 기록입니다.
로그가 있어야 공격을 이해할 수 있습니다.
로그가 있어야 유출을 증명할 수 있습니다.
로그가 있어야 대응도 가능해집니다.

보안을 다시 세운다는 것은
제품 하나를 더 도입하는 일이 아닙니다.

그보다 먼저
무엇을 남길 것인가를 정하는 일입니다.

지금 정부와 기업이 가장 먼저 해야 할 일도 여기에 있습니다.
추상적인 선언이 아니라,
현장에서 실제로 작동할 수 있는 표준 로그 가이드라인을 마련해야 합니다.

해킹은 앞으로도 계속될 것입니다.
문제는 해킹 그 자체만이 아닙니다.

해킹을 당한 뒤에도 아무것도 설명하지 못하는 구조를 더 이상 반복해서는 안 됩니다.

보안의 출발점은 기록입니다.
그리고 기록 없는 보안은, 결국 설명할 수 없는 보안입니다.

함께 읽기

[전자신문] 지금 해킹을 이해하려면, LOLBAS부터 다시 봐야 한다

📰 원문 뉴스

이 글은 아래 전자신문 기고문을 바탕으로 PLURA-Blog 형식에 맞게 확장·재구성한 내용입니다.

전자신문 : 2026-03-18 온라인판
https://www.etnews.com/20260318000409