본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 05. 21. 06:21

로그 데이터에 대한 AWS Nova 벤치마킹: ChatGPT-3.5와의 비교

요약

본 연구는 로그 데이터 분석을 위해 AWS Nova Micro 모델의 성능을 기존 ChatGPT-3.5-turbo와 비교 평가했습니다. 실험 결과, 최신 소형 모델인 Nova Micro가 과거의 대형 모델인 GPT-3.5에 필적하는 성능을 보이면서도 비용 측면에서는 입력 토큰당 14배 더 저렴한 경제성을 입증했습니다.

핵심 포인트

  • AWS Nova Micro는 로그 파싱, 분석, 예측 등 주요 로그 분석 작업에서 GPT-3.5-turbo와 경쟁 가능한 성능을 보여줌
  • Nova Micro의 입력 토큰당 비용은 GPT-3.5-turbo 대비 14배 저렴하여 경제적 효율성이 매우 높음
  • Nova Micro는 128,000 토큰의 컨텍스트 윈도우를 지원하여 대규모 로그 데이터 처리에 유리함
  • 로그 데이터 분석 벤치마크를 통해 소형 모델(SLM)의 실무 적용 가능성을 확인

Benoit Gaudin 작성. 이 포스트는 로그 데이터 (log data) 분석을 위한 대규모 언어 모델 (LLMs)의 활용을 탐구합니다. 이를 위해, 우리는 2023년 Intel 연구원인 Priyanka Mudgal과 Rita Wouhaybi가 수행했던 'An Assessment of ChatGPT on Log Data' 벤치마크의 일부를 재현했습니다. 초기 벤치마크는 ChatGPT-3를 사용했지만, 우리의 연구는 AWS Nova Micro 모델을 평가합니다. 우리의 목표는 더 최근에 출시된, 더 작고 저렴한 모델들이 몇 년 전의 ChatGPT-3 성능에 필적하거나 이를 능가할 수 있는지 평가하는 것입니다. 경제적 측면은 특히 흥미롭습니다. Nova Micro의 입력 토큰 (input token)당 비용은 2년 전 GPT-3.5-turbo보다 14배 더 낮습니다. 벤치마크 설정 (Benchmark Setup). 원본 벤치마크는 네 가지 카테고리로 그룹화된 10개의 연구 질문에 대해 GPT-3.5-turbo를 평가했습니다: 로그 파싱 및 분석 (Log Parsing & Analytics) — 모델이 로그를 파싱하고 오류, 근본 원인 (root causes), 보안 이벤트 및 이상 징후 (anomalies)를 식별할 수 있는가? 자주 사용되는 API를 식별할 수 있는가? 예측 (Prediction) — 과거 로그를 기반으로 미래의 로그 이벤트를 예측할 수 있는가? 요약 (Summarization) — 단일 및 다중 로그 메시지를 요약할 수 있는가? 일반 역량 (General Capabilities) — 대량의 로그 데이터를 처리할 수 있으며, 어떤 메시지 길이를 처리할 수 있는가? 실험에는 Loghub 컬렉션의 데이터셋 — 다양한 시스템 (Windows, Linux, 모바일, 분산 시스템 등)에서 추출한 2,000개의 레이블이 지정된 로그 메시지가 사용되었습니다. 우리의 실험은 동일한 방법론과 동일한 19개의 Loghub 데이터셋을 재사용하되, 다음과 같은 차이점이 있습니다: 우리는 GPT-3.5-turbo 대신 AWS Nova Micro를 평가했습니다. 우리는 처음 세 가지 카테고리 (7개 질문)에 집중했습니다 — 네 번째 카테고리는 컨텍스트 윈도우 (context window) 크기를 다루는데, 이는 더 이상 의미 있는 차별화 요소가 아닙니다 (GPT-3.5-turbo: 16,385 토큰; Nova Micro: 128,000 토큰). 원본 벤치마크가 여러 입력 크기를 테스트했던 것과 달리 (예:

5, 10, 50개의 로그 항목), 모델에게 가장 많은 컨텍스트를 제공하기 위해 최대치(50개)만을 사용했습니다. 결과는 원본과 동일한 프롬프트를 사용하여 사람이 수동으로 평가했습니다.

카테고리질문프롬프트설명
로그 파싱 (Log Parsing)Q1이 로그 메시지에서 로그 템플릿(template)과 변수(variables)를 추출하세요.모델이 로그 파싱을 얼마나 잘 수행하는가?
로그 분석 (Log Analytics)Q2에러와 경고를 요약하고 근본 원인(root cause)을 식별하세요.원시 로그(raw logs)에서 에러와 근본 원인을 추출할 수 있는가?
로그 분석 (Log Analytics)Q3호출 빈도가 가장 높은 API를 횟수와 함께 보여주세요.고급 분석(advanced analytics) 작업을 수행할 수 있는가?
로그 분석 (Log Analytics)Q4악성 사용자, URL, IP 및 연결 상태가 있습니까?보안 정보(security information)를 추출할 수 있는가?
로그 분석 (Log Analytics)Q5다음 로그 메시지에서 이상 징후(anomalies)를 탐지하세요.이상 징후를 탐지할 수 있는가?
로그 분석 (Log Analytics)Q6이 로그 메시지들을 기반으로 다음 10개의 로그 이벤트를 예측하세요.미래의 이벤트를 예측할 수 있는가?
로그 요약 (Log Summarization)Q7로그 메시지를 요약하세요.단일 로그 메시지를 요약할 수 있는가?

결과: AWS Nova Micro의 성능

프롬프트정답률비고
로그 템플릿 및 변수 추출17/19 (89%)HDFS 로그에서 실패함; ID가 항상 정확하게 분류되지는 않음
에러 요약 및 근본 원인 식별10/19 (53%)Hadoop 로그에서 경고를 잘못 보고함; HPC에서 타임스탬프와 에러 코드를 혼동함; HealthApp 및 Mac 로그에서 문제를 과다 보고함
호출 빈도가 가장 높은 API 표시4/19 (21%)카운팅(counting)이 매우 어려움; 많은 데이터셋에 API 관련 항목이 부족함; 모델이 말이 안 되는 결과를 과다 보고함
악성 사용자, URL, IP 탐지18/19 (95%)높은 정확도를 보이나, 샘플링된 로그에 명백한 보안 문제가 없었기 때문에 일반적인 사례로 결론짓기는 어려움
이상 징후 탐지9/19 (47%)무관한 기준에 따라 이상 징후를 보고함 (예:

항목이 "샘플의 끝부분에 발생"하거나 "반복적"이라는 기준에 따라 보고함) | 다음 10개 로그 이벤트 예측 | 0/19 (0%) | 극도로 반복적인 로그의 경우에도 ID와 타임스탬프(timestamps)를 정확하게 예측하지 못함 | 단일 로그 메시지 요약 | 16/19 (84%) | 전반적으로 좋은 결과임; 이름이 지정된 필드(named fields)가 없는 익숙하지 않은 로그 형식의 경우 어려움이 있음 | 요약하자면, 우리의 평가는 기존 벤치마크의 결과를 확인해 줍니다: ChatGPT-3와 유사하게, Nova Micro는 로그 데이터를 파싱(parsing)하고 요약(summarizing)하는 데 뛰어난 성능을 보입니다. 다른 유형의 분석 — 카운팅(counting), 이상 징후 탐지(anomaly detection), 예측(prediction) — 은 LLM(Large Language Models)에게 여전히 어려운 과제로 남아 있습니다. 악성 콘텐츠 탐지 결과(95%)는 강력해 보이지만 주의가 필요합니다: 샘플링된 데이터셋에 명확하게 악성인 항목이 포함되지 않았기 때문입니다. 모델은 여기서 오탐(false positives)을 생성하지 않았으며, 이는 그 자체로 가치가 있습니다 — 특히 오탐이 흔했던 이상 징후 탐지와 비교했을 때 더욱 그렇습니다. 이 벤치마크는 이제 로그 데이터의 파싱과 요약을 훨씬 더 비용 효율적인 방식으로 달성하는 것이 가능하다는 것을 보여줍니다. | 데이터셋에 대한 고찰 | Loghub 컬렉션은 재현 가능한 벤치마킹을 위해 매우 귀중합니다. 이것이 없다면 의미 있는 교차 벤치마크 비교는 불가능할 것입니다. 그렇긴 하지만, 데이터셋에는 주목할 만한 몇 가지 한계가 있습니다. Bronto에서는 CDN 로그, 웹 액세스 로그(web access logs), AWS CloudTrail 감사 로그(audit logs), 애플리케이션 로그와 같이 실제 운영 환경에서 흔히 쓰이는 로그 유형을 자주 다룹니다. LLM은 이러한 형식이 널리 문서화되어 있고 구조화되어 있기 때문에 이를 잘 이해하는 경향이 있습니다. 구조화된 로그(Structured logs)는 상황을 크게 변화시킵니다. 합성된 구조화된 CDN 로그 데이터(실제 사례 기반)에 대해 Q2 및 Q3 프롬프트를 실행했을 때, 모델은 실질적으로 더 나은 성능을 보였습니다: Q2(오류 식별)의 경우, 모델은 필드 이름에

Q3(가장 많이 호출된 API)의 경우, 모델은 reqPath 필드가 API 엔드포인트(API endpoints)를 나타낸다는 것을 정확히 식별하였으며 상위 결과들을 정확하게 추출했습니다. 개수 세기(Counting)는 모든 데이터셋 유형에 걸쳐 일관된 약점으로 남아 있습니다. Q3에서 가장 흔한 API 호출 횟수를 제공해야 할 때, 모델의 계산 값은 데이터셋에 관계없이 빈번하게 부정확합니다. 추가적인 관찰 사항으로는, 몇몇 Loghub 데이터셋(HPC, HealthApp, BGL, Proxifier)은 Nova Micro가 이에 대한 확실한 사전 지식(prior understanding)을 갖지 못할 정도로 충분히 생소한 것으로 보입니다. 이 시스템들에 대한 샘플 로그 생성을 요청했을 때, 출력 결과가 실제 Loghub 데이터와 닮지 않았는데, 이는 모델이 익숙하지 않은 영역에서 작동할 때 신뢰도가 떨어진다는 것을 시사합니다.

결론
이 벤치마크는 AWS Nova Micro를 사용하여 2023년 ChatGPT 로그 분석 연구를 재현했습니다. 결과는 놀라울 정도로 유사하지만, 한 가지 큰 차이점이 있습니다: 토큰당 비용(cost per token)이 14배 더 낮습니다. 로그 데이터는 엄청난 양으로 유명하다는 점을 고려할 때, 이러한 비용 차이는 로그 분석 파이프라인에서 LLM(Large Language Models)을 실제 운영 환경(production)에 사용할 때 매우 중요합니다. 또한 Loghub 데이터셋은 대부분의 실제 운영 로깅 시스템이 생성하는 데이터를 완전히 대표하지는 않습니다. 웹 액세스(web access), CDN, 애플리케이션, 감사(audit)와 같은 실제 로그는 더 구조화되어 있고 LLM에게 더 친숙한 경향이 있으며, 이는 벤치마크 점수가 시사하는 것보다 더 나은 성능으로 이어집니다. 우리는 LLM이 실제 관측성(observability) 데이터의 대부분을 차지하는 일반적이고 구조화된 로그 형식을 분석하는 데 있어, 특히 운영 로깅 시스템을 개선할 수 있는 진정한 잠재력을 가지고 있다고 믿습니다.

Bronto의 AI 기능 살펴보기

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0