Windows 이벤트 로그·ETW 입문 ── 업무 앱의 로그를 OS 표준 체계에 올리기

C#으로 업무 앱이나 Windows 서비스를 개발하다 보면, 대개는 자체 제작한 파일 로거나 Serilog·NLog 같은 라이브러리로 매일의 로그를 출력하게 됩니다. 그렇다면 Windows 이벤트 로그나 ETW(Event Tracing for Windows)는 더 이상 필요 없는 걸까요? 그렇지 않습니다. 이 두 가지는 ‘파일 로그의 대체’가 아니라, 운영 담당자나 OS 표준 도구에서 보이는 또 다른 계층의 기록입니다.

이 글에서는 파일 로그·이벤트 로그·ETW를 구분해서 쓰는 방법부터, .NET에서의 구현 방법, ETW의 최소한의 핵심, 수집·조사 실무, 그리고 현장에서 자주 밟는 함정까지 정리합니다.

1. 먼저 결론

• 세 가지 수단은 대체 관계가 아니라 역할 분담입니다. 파일 로그는 개발자가 나중에 상세 내용을 추적하기 위한 기록이고, 이벤트 로그는 운영 담당자나 OS 표준 이벤트 뷰어·모니터링 도구가 이상을 알아채기 위한 기록이며, ETW는 성능 조사나 재현하기 어려운 결함을 분석하기 위해 온디맨드로 활성화하는 고빈도 트레이스입니다. 기본적으로는 함께 사용하며, 각각에 기록하는 정보량을 다르게 합니다.
• 이벤트 로그에는 ‘기동·정지·치명적 오류’만 기록합니다. 모든 로그를 이벤트 로그에도 흘려보내면, 운영 담당자가 정말로 봐야 할 이상이 파묻힙니다. 파일 로그 쪽은 지금까지처럼 상세하게 출력하면서, 이벤트 로그는 범위를 좁힙니다.
• 이벤트 소스 등록에는 관리자 권한이 필요합니다. EventLog.CreateEventSource는 Windows Vista 이후로 관리자 권한이 없으면 호출할 수 없습니다. 실행 시 최초 접근에서 등록하려는 설계는 피하고, 설치 프로그램에서 미리 등록해 둡니다.¹
• ETW는 ‘상시 수집’이 아닙니다. EventSource로 이벤트를 정의해 두어도, 구독자(dotnet-trace, PerfView, ETW 기반 도구)가 없으면 아무것도 기록되지 않습니다. 성능 분석이나 특정 결함 조사를 할 때만 대상 프로바이더를 지정해 수집하는 것이 기본적인 사용 방법입니다.²
• 메시지는 문자열 연결이나 문자열 보간이 아니라 템플릿 형식으로 작성합니다. logger.LogInformation("Order {OrderId} failed", orderId)처럼 작성하면, 구조화 로그로서 OrderId를 플레이스홀더 이름과 함께 검색할 수 있습니다. 문자열 연결·보간으로 조립하면 이 구조 정보가 사라집니다.³
• 로그 용량이 커지는 문제는 기본값이 작다는 점이 원인이 되기 쉽습니다. 이벤트 로그의 기본 최대 크기는 512KB에 불과하므로, 업무 앱이 이벤트 로그를 일상적으로 사용한다면 명시적으로 확장하고, 상한에 도달했을 때의 동작(덮어쓸지, 버릴지)도 설계 시점에 정해 둡니다.⁴

다음은 판단표입니다.

2. Windows 이벤트 로그의 기초

Windows에는 기본적으로 Application·System·Security라는 3가지 로그가 있으며, Security는 읽기 전용입니다. 업무 앱이나 서비스는 Application 로그, 또는 앱 고유의 커스텀 로그(채널)에 기록합니다. 디바이스 드라이버는 System 로그에 기록하는 것이 관례입니다.⁵

기록의 단위는 ‘이벤트 소스’입니다. 소스는 애플리케이션을 식별하는 이름으로, EventLog.CreateEventSource로 사전에 등록합니다. Windows Vista 이후에는 소스 등록에 관리자 권한이 필요합니다. 이는 소스 이름의 고유성을 확인하기 위해 Security 로그를 포함한 모든 이벤트 로그를 검색해야 하는데, 표준 사용자는 Security 로그에 접근할 권한이 없기 때문입니다.¹

using System.Diagnostics;

// 설치 프로그램이나 설정 처리 안에서, 관리자 권한이 있는 동안 실행한다
const string SourceName = "KomuraSoft.OrderService";
const string LogName = "Application";

if (!EventLog.SourceExists(SourceName))
{
    EventLog.CreateEventSource(SourceName, LogName);
}

소스를 실행 시 최초 접근에서 만들려고 하면, 앱이 표준 사용자로 동작하는 운영 환경에서는 이 호출이 실패합니다. 관리자 권한이 언제 필요한지에 대한 일반론은 「Windows의 관리자 권한이 필요한 시점」에서 정리했지만, 이벤트 소스 등록도 바로 이 패턴에 해당하며, 설치 프로그램에서 등록하고 앱 본체는 등록된 소스에 기록만 하는 것이 안전한 설계입니다.

이벤트에는 ‘레벨’과 ‘이벤트 ID’라는 두 가지 식별 정보가 붙습니다. 레벨은 EventLogEntryType(Information, Warning, Error, SuccessAudit, FailureAudit)이며, 이벤트 뷰어의 아이콘이나 기본 필터에 사용됩니다. 이벤트 ID는 애플리케이션이 정의하는 정수로, 같은 종류의 사건을 나중에 검색·집계하기 위한 키가 됩니다.

3. .NET에서 이벤트 로그에 기록하기

.NET에서 이벤트 로그로 기록하는 경로는 크게 두 가지입니다.

3.1 System.Diagnostics.EventLog를 직접 사용하기

저수준 API로, 세밀한 제어(카테고리, 바이너리 데이터 첨부 등)가 필요한 경우에 적합합니다. .NET(.NET Framework 이외)에서는 System.Diagnostics.EventLog NuGet 패키지 참조가 필요합니다.

using System.Diagnostics;

public sealed class OrderServiceEventLog
{
    private const string SourceName = "KomuraSoft.OrderService";

    public void WriteServiceStarted()
    {
        EventLog.WriteEntry(SourceName, "OrderService를 시작했습니다.",
            EventLogEntryType.Information, eventID: 1000);
    }

    public void WriteFatalError(Exception ex)
    {
        EventLog.WriteEntry(SourceName,
            $"치명적 오류가 발생하여 처리를 계속할 수 없습니다. 자세한 내용은 파일 로그를 확인하세요. {ex.GetType().Name}: {ex.Message}",
            EventLogEntryType.Error, eventID: 1999);
    }
}

3.2 ILogger + AddEventLog 사용하기

이미 ILogger로 구조화 로그를 구성했다면, Microsoft.Extensions.Logging.EventLog 패키지의 AddEventLog를 사용하는 쪽이 기존 로깅 파이프라인에 자연스럽게 올라탑니다. ASP.NET Core나 Generic Host 기반의 Worker Service에서는 Windows에서 동작할 경우 기본적으로 EventLog 프로바이더가 활성화되어 있습니다.⁶

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.EventLog;

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);

builder.Logging.AddEventLog(settings =>
{
    settings.SourceName = "KomuraSoft.OrderService";
    settings.LogName = "Application";
    // 기본 카테고리 필터에 더해, 이벤트 로그에는
    // Warning 이상만 흘려보낸다(상세 내용은 파일 로그 쪽에 맡긴다)
    settings.Filter = (_, level) => level >= LogLevel.Warning;
});

using IHost host = builder.Build();
await host.RunAsync();

EventLogSettings를 생략하면, LogName은 기본값으로 "Application", SourceName은 기본값으로 ".NET Runtime"이 됩니다.⁷ .NET Runtime이라는 범용적인 소스 이름을 그대로 두면, 이벤트 뷰어에서 자신의 앱 로그인지 다른 .NET 앱의 로그인지 구분하기 어려워지므로, SourceName은 반드시 자사 앱용으로 명시하세요.

Windows 서비스나 작업 스케줄러로 동작하는 배치 처리에서는, ‘기동’ ‘정지’ ‘치명적 오류’만 이벤트 로그에 기록하고 그 외의 상세 내용은 파일 로그에 맡기는 것이 실무상의 균형입니다. 서비스로 만드는 방법과 운영은 「Windows 서비스 만드는 방법과 운영」에서, 작업 스케줄러를 통한 실행 문제는 「작업 스케줄러의 작업이 실행되지 않거나 0x1로 종료되는 문제」에서 다루고 있습니다. 두 경우 모두 이상이 발생했을 때 운영 담당자가 가장 먼저 보는 것이 이벤트 로그인 경우가 많으며, 여기에 요점이 남아 있는지에 따라 초기 대응 조사의 속도가 달라집니다.

4. ETW란 무엇인가 ── OS 전체를 관통하는 트레이스 기반

Event Tracing for Windows(ETW)는 커널부터 사용자 모드 애플리케이션까지 공통 기반으로 계측할 수 있는 트레이스 메커니즘입니다. 커널 이벤트(디스크 I/O, 프로세스 생성 등)와 애플리케이션 고유 이벤트를 같은 타임라인 위에서 함께 기록·분석할 수 있다는 것이 가장 큰 특징입니다.⁸

.NET에서는 System.Diagnostics.Tracing.EventSource를 상속한 클래스를 만들어서 독자적인 ETW 프로바이더를 정의할 수 있습니다. ETW는 Publish-Subscribe 방식으로 동작하며, 구독자가 없으면 이벤트가 기록되지 않습니다. 즉 EventSource를 구현해 두는 것만으로는 아무 일도 일어나지 않고, 수집 도구에서 명시적으로 활성화해야 비로소 이벤트가 기록됩니다.²

using System.Diagnostics.Tracing;

[EventSource(Name = "KomuraSoft-OrderService")]
internal sealed class OrderServiceEventSource : EventSource
{
    public static readonly OrderServiceEventSource Log = new();

    [Event(1, Level = EventLevel.Informational, Message = "주문 처리를 시작했습니다. OrderId={0}")]
    public void OrderProcessingStart(string orderId)
    {
        if (IsEnabled())
        {
            WriteEvent(1, orderId);
        }
    }

    [Event(2, Level = EventLevel.Informational, Message = "주문 처리가 완료되었습니다. OrderId={0}")]
    public void OrderProcessingStop(string orderId)
    {
        if (IsEnabled())
        {
            WriteEvent(2, orderId);
        }
    }
}

호출하는 쪽은 다음과 같이 사용합니다. 이벤트를 실제로 기록하기 전에 IsEnabled()로 활성화 여부를 확인해 두면, 수집하지 않을 때의 불필요한 비용을 피할 수 있습니다.

OrderServiceEventSource.Log.OrderProcessingStart(order.Id);
try
{
    ProcessOrder(order);
}
finally
{
    OrderServiceEventSource.Log.OrderProcessingStop(order.Id);
}

이 이벤트를 수집하려면, 크로스 플랫폼 도구인 dotnet-trace를 사용하는 것이 가장 간편합니다.⁹

dotnet-trace collect --providers KomuraSoft-OrderService -- OrderService.exe

수집한 .nettrace 파일은 Visual Studio나 PerfView로 열어서 내용을 확인합니다. 더 본격적인 성능 조사, 예를 들어 커널 이벤트까지 포함한 분석을 하고 싶다면, Windows Assessment and Deployment Kit(ADK)에 포함된 Windows Performance Recorder(WPR)를 사용하고 Windows Performance Analyzer(WPA)로 보는 구성이 됩니다.¹⁰ 다만 이 글의 범위는 ‘ETW로 무엇을 할 수 있고, 언제 사용하는가’까지로 한정하며, PerfView나 WPA를 이용한 상세한 분석 절차까지는 다루지 않습니다. 업무 앱의 개발·유지보수라는 관점에서는, 먼저 자신의 프로바이더를 EventSource로 정의할 수 있고 dotnet-trace로 수집할 수 있다는 것까지만 익혀두면 충분합니다.

5. 구조화 로그의 실무

ILogger의 메시지 템플릿은 {PlaceHolder}라는 이름 붙은 플레이스홀더를 포함한 고정 문자열로 작성합니다. 이는 단순한 형식상의 관례가 아니라, 템플릿 자체를 바꾸지 않고 인수만 전달함으로써 로깅 기반 쪽에서 플레이스홀더 이름과 값의 대응 관계(구조화 데이터)를 유지할 수 있다는 의미를 갖습니다.¹¹

// 권장: 템플릿은 고정, 인수는 따로 전달
logger.LogWarning("Order {OrderId}의 재고 확보에 실패했습니다. 창고={WarehouseId}", orderId, warehouseId);

// 비권장: 문자열 연결·보간은 템플릿과 값의 대응 관계를 깨뜨린다
logger.LogWarning("Order " + orderId + "의 재고 확보에 실패했습니다. 창고=" + warehouseId);
logger.LogWarning($"Order {orderId}의 재고 확보에 실패했습니다. 창고={warehouseId}");

코드 분석기 규칙 CA2254는 이 비권장 패턴(템플릿이 호출마다 바뀌어 버리는 작성 방식)을 감지해 줍니다.³ 호출 빈도가 높은 핫 패스에서는, 추가로 LoggerMessageAttribute를 이용한 소스 생성을 사용하면 박싱이나 템플릿 파싱 비용을 피할 수 있습니다.¹²

using Microsoft.Extensions.Logging;

internal static partial class Log
{
    [LoggerMessage(
        EventId = 2001,
        Level = LogLevel.Warning,
        Message = "Order {OrderId}의 재고 확보에 실패했습니다. 창고={WarehouseId}")]
    public static partial void StockReservationFailed(
        this ILogger logger, string orderId, string warehouseId);
}

// 호출하는 쪽
logger.StockReservationFailed(orderId, warehouseId);

이 구성이라면 같은 로그 호출에서, 파일 로그(Serilog/NLog 등의 싱크)에는 상세 내용을, 이벤트 로그에는 좁혀진 내용을, ETW에는 EventSourceLoggerProvider를 통해 저비용 트레이스를, 각각 나누어 보낼 수 있습니다. ILoggerProvider를 여러 개 등록하고 Filter로 프로바이더별 출력 레벨을 다르게 하는 것이 기본 형태입니다. 자체 제작 로거의 최소 요건은 「자체 제작 로거의 최소 요건과 통합 테스트 체크리스트」, 크래시 시 로그와 덤프를 어떻게 연결해서 남길지는 「Windows 앱 크래시 시 로그와 덤프를 남기는 설계」를 참고하세요.

6. 수집과 조사 ── 기록한 로그를 읽는 쪽의 이야기

이벤트 뷰어에서는 로그 목록에서 ‘필터’ 또는 ‘사용자 지정 보기’를 사용해, 특정 소스·레벨·이벤트 ID만 추출할 수 있습니다. 자주 쓰는 조건은 사용자 지정 보기로 저장해 두면 다음번 조사가 빨라집니다. 사용자 지정 보기는 XPath 쿼리로 정의되며, 예를 들어 특정 이벤트 이름만 추출하는 쿼리는 다음과 같은 형태가 됩니다.¹³

<QueryList>
  <Query Id="0" Path="Application">
    <Select Path="Application">
      *[System[Provider[@Name='KomuraSoft.OrderService'] and (Level=2 or Level=3)]]
    </Select>
  </Query>
</QueryList>

명령줄에서는 wevtutil로 로그 내보내기나 설정 변경을 할 수 있습니다. 장애 조사의 일환으로, 발생 시점 전후의 이벤트 로그를 내보내 지원팀에 전달하는 운영 방식에도 사용할 수 있습니다.¹⁴

:: Application 로그를 통째로 evtx 파일로 내보낸다
wevtutil epl Application C:\logs\application_20260707.evtx

:: 특정 소스의 이벤트만 표시한다(최근 10건)
wevtutil qe Application /q:"*[System[Provider[@Name='KomuraSoft.OrderService']]]" /c:10 /rd:true /f:text

크래시 조사에서는 이벤트 로그·파일 로그·크래시 덤프 세 가지를 시각으로 맞춰보는 것이 기본입니다. 이벤트 로그에 남은 ‘치명적 오류’의 타임스탬프를 기점으로, 같은 시각의 파일 로그 상세 내용과 WER/ProcDump로 수집한 덤프를 대조합니다. 덤프 수집 방법은 「Windows 크래시 덤프 수집 입문 - WER/ProcDump/WinDbg」, 수집한 덤프의 실제 분석 절차는 「WinDbg + SOS로 크래시 덤프 읽기」에 정리해 두었습니다.

7. 함정

• 소스를 등록하지 않은 채로 기록하려다 실패한다. 등록되지 않은 소스 이름으로 RegisterEventSource에 상응하는 호출을 하면, 이벤트 자체는 Application 로그에 기록되지만 대응하는 메시지 리소스 DLL이 없기 때문에 이벤트 뷰어가 설명문을 표시하지 못하고 오류로 표시됩니다.¹⁵ 게다가 실행 시에 CreateEventSource로 자동 등록하려는 설계에서는, 비관리자 사용자로 동작하는 프로세스가 처음 시작될 때 예외로 죽는 사고도 자주 일어납니다. 소스 등록은 반드시 설치 프로그램 쪽에서 완료해 둡니다.
• ‘다른 소스 이름으로도 기록할 수 있어 버리는’ 혼란. 이벤트 로그는 쓰기 권한만 있으면, 앱이 등록한 적이 없는 다른 소스 이름으로도 기록할 수 있습니다. 소스 이름은 컴퓨터에서 고유해야 하지만, 이를 지키는 장치는 OS 쪽에 없고 앱 쪽의 규율에 맡겨져 있습니다.⁵ 지나치게 범용적인 소스 이름(회사명이나 제품명을 포함하지 않는 짧은 이름)을 선택하면, 다른 벤더의 앱과 충돌하거나 의도치 않게 다른 앱의 소스 이름을 그대로 쓰게 되는 원인이 됩니다.
• 로그 용량 증가와 보존 정책. 이벤트 로그의 기본 최대 크기는 겨우 512KB입니다.⁴ 업무 앱이 이벤트 로그를 일상적으로 사용한다면, wevtutil sl이나 설치 프로그램에서 크기를 명시적으로 확장하고, 상한에 도달했을 때 ‘오래된 것부터 덮어쓸지’ ‘새로운 것을 버릴지’를 의식해서 설정하세요. OverwriteOlder는 비권장(deprecated)되어 있어, 지정해도 실질적으로 ‘덮어쓰지 않는’ 동작이 될 수 있다는 점에도 주의가 필요합니다.¹⁶
• 다국어 환경에서의 메시지 표시. 지역화된 메시지 리소스 파일(MessageResourceFile)을 사용하는 구성으로 만든 경우, 그 리소스 DLL이 존재하지 않거나 버전이 다른 환경에서 로그를 표시하면 ‘이벤트 ID ○○의 설명을 찾을 수 없습니다’라는 표시가 됩니다. 전달된 이벤트 로그를 다른 서버에서 보는 경우, 또는 앱을 제거한 후에도 로그만 남아 있는 경우처럼, 이런 문제가 일어나기 쉬운 상황이 있습니다. 문자열을 직접 WriteEntry로 기록하는(리소스 파일을 사용하지 않는) 구성이라면, 이런 종류의 문제 자체를 만들지 않아도 됩니다.
• 권한 부족으로 기록할 수 없는 경우. 자주 오해하기 쉬운데, 소스 등록에는 관리자 권한이 필요한 반면, 등록된 소스에 대한 기록은 표준 사용자도 할 수 있습니다. ‘관리자 권한이 없으면 동작하지 않는다’고 성급하게 결론짓고 앱 전체를 관리자 권한으로 실행하기 전에, 실제로 어느 작업에 권한이 필요한지를 먼저 구분해 보세요.

관련 글

• Windows의 관리자 권한이 필요한 시점 - UAC, 보호 영역, 설계상의 구분 방법
• Windows 서비스 만드는 방법과 운영 ── 작업 스케줄러와의 구분 사용부터 BackgroundService의 서비스화까지
• 작업 스케줄러의 작업이 실행되지 않거나 0x1로 종료되는 문제 ── 원인 구분과 안전한 운영 설계
• 자체 제작 로거의 최소 요건과 통합 테스트 체크리스트
• Windows 앱 크래시 시 로그와 덤프를 남기는 설계
• Windows 크래시 덤프 수집 입문 - WER/ProcDump/WinDbg
• WinDbg + SOS로 크래시 덤프 읽기 ── 수집한 뒤의 실무 분석 입문

관련 상담 영역

합동회사 코무라소프트에서는 Windows 업무 앱의 로그·이벤트 로그·ETW 기반 설계, 장애 조사를 염두에 둔 관측점 설계에 대한 기술 상담을 다루고 있습니다.

• Windows 앱 개발
• 결함 조사·원인 분석
• 기술 상담·설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

파일 로그가 있으면 이벤트 로그는 필요 없나요?

상세한 조사 용도라면 파일 로그만으로 충분한 경우도 많습니다. 다만 운영 담당자가 OS 표준 이벤트 뷰어나 모니터링 도구(작업 스케줄러의 실패 알림, SCOM 등)에서 앱의 이상을 알아챌 수 있게 하려면, 이벤트 로그에 요점만 출력하는 것을 함께 쓰는 것이 실무적입니다. 둘은 대체 관계가 아니라, 서로 다른 별도 계층의 기록이라고 생각해야 합니다.

이벤트 ID의 번호 부여 규칙은 어떻게 정해야 하나요?

정해진 정답은 없지만, 실무에서는 '기능 영역별로 대역을 나눈다(기동 계열은 1000번대, 통신 계열은 2000번대 등)', '한 번 발급한 ID는 의미를 바꾸지 않고 재사용하지 않는다', '결번을 허용한다'는 3가지를 지키면 사고가 줄어듭니다. ILogger의 EventId는 구조화 로그의 검색 키로도 쓰이므로, 나중에 문서화하기 쉬운 번호 부여 방식으로 해두면 유지보수 시에 도움이 됩니다.

Serilog나 NLog를 사용하고 있는데, 이 글의 내용과 어떤 관계가 있나요?

Serilog나 NLog는 ILogger 아래에서 파일·이벤트 로그·ETW·외부 SaaS 등 여러 싱크로 같은 로그를 나누어 보내기 위한 구현 중 하나입니다. 이 글에서 다룬 '이벤트 로그에는 요점만', '메시지 템플릿을 무너뜨리지 않는다'는 설계 방침은, ILogger를 직접 쓰는 경우든 Serilog/NLog를 거치는 경우든 마찬가지로 적용됩니다. 이벤트 로그용 싱크(Serilog.Sinks.EventLog 등)를 쓸지, 표준 AddEventLog를 쓸지는 구현상의 선택입니다.

ETW는 어디까지 배우면 충분한가요?

업무 앱의 개발·유지보수가 주목적이라면, EventSource로 독자적인 프로바이더를 만들 수 있는 것, dotnet-trace로 자신의 프로바이더 이벤트를 수집할 수 있는 것까지만 익혀두면 충분합니다. PerfView를 이용한 콜 스택 분석이나 WPR의 커널 이벤트 수집은 성능 조사를 전문으로 하는 단계에서 배워도 충분한 영역으로, 이 글에서는 의도적으로 범위 밖에 두었습니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.