LLM에 로그를 넣기 전에 소음부터 걷어내기, 오픈소스 ctrlb-decompose

요즘 장애가 나면 로그를 복사해서 LLM에 붙여넣고 '왜 죽었는지 찾아줘'라고 물어보는 게 자연스러운 풍경이 됐어요. 그런데 이렇게 해보신 분들은 다 아는 문제가 있죠. 로그가 조금만 길어지면 컨텍스트 한계에 걸리고, 토큰 비용이 훅 뛰고, 무엇보다 수만 줄의 반복되는 로그 속에서 모델이 정작 중요한 단서를 놓치기도 해요. ctrlb-decompose는 바로 이 지점을 겨냥한 오픈소스 도구인데요. LLM에 로그를 보내기 전에 '소음'을 걷어내는 전처리기예요.

핵심 아이디어: 로그는 사실 '템플릿 + 변수'예요

이 도구의 발상을 이해하려면 로그의 구조부터 볼 필요가 있어요. 로그는 언뜻 제각각으로 보이지만, 사실 대부분 코드 어딘가의 출력문에서 나온 거잖아요. 'User 1234 logged in from 10.0.0.5' 같은 줄은 'User <아이디> logged in from <IP>'라는 고정된 틀에 변수만 바뀌어 찍힌 거예요. 그래서 수십만 줄짜리 로그 파일도 실제 템플릿의 종류는 수십에서 수백 개에 불과한 경우가 많아요.

이걸 이용하면 로그를 획기적으로 압축할 수 있어요. 같은 템플릿의 줄들을 하나로 묶고, '이 패턴이 몇 번 나왔는지'와 대표 샘플, 그리고 변수 값의 분포만 남기는 거죠. 예를 들어 헬스체크 성공 로그 8만 줄은 '이 패턴 8만 회 발생' 한 줄로 접히는 거예요. 이렇게 하면 두 가지 효과가 생겨요. 첫째, LLM에 보내는 토큰이 크게 줄어요. 둘째, 이게 더 중요한데, 신호가 도드라져요. 장애 분석에서 진짜 단서는 대개 '평소에 없던 처음 보는 에러 한두 줄'이거든요. 반복 로그에 파묻혀 있던 그 한 줄이, 압축하고 나면 자연스럽게 눈에 띄는 위치로 올라오는 거예요. 사람이 로그를 볼 때 grep으로 아는 패턴을 걸러내며 범위를 좁혀가는 과정을, LLM에 넘기기 전에 자동으로 해주는 셈이죠.

참고로 이런 접근이 완전히 새로운 건 아니에요. 로그에서 템플릿을 자동으로 추출하는 기법은 '로그 파싱'이라는 이름으로 학계에서 오래 연구돼 왔고, Drain 같은 알고리즘이 대표적이에요. 새로운 건 이 기법을 'LLM에 보내기 전 전처리'라는 맥락으로 가져왔다는 점이에요. 압축의 목적이 저장 공간 절약에서 '토큰 예산 안에서 신호 밀도 높이기'로 바뀐 거죠.

업계 맥락: 로그 전처리가 곧 비용 문제가 된 시대

이 도구가 나온 배경에는 AIOps라고 불리는 흐름이 있어요. Datadog, Elastic 같은 옵저버빌리티 업체들이 앞다퉈 AI 장애 분석 기능을 붙이고 있고, 사내에서 인시던트 봇을 직접 만드는 팀도 늘고 있죠. 그런데 이런 시스템의 운영 비용은 결국 'LLM에 뭘 얼마나 보내느냐'로 결정돼요. 원본 로그를 통째로 넣으면 분석 한 번에 상당한 비용이 나가지만, 전처리로 토큰을 수십 분의 일로 줄이면 같은 예산으로 훨씬 자주, 넓게 분석을 돌릴 수 있어요. 로그 전처리가 단순한 성능 최적화가 아니라 비용 구조의 문제가 된 거예요.

한국 개발자에게 주는 시사점

사내 장애 대응 봇이나 에러 알림 채널에 LLM 요약을 붙여봤거나 붙일 계획이라면, 이런 전처리 계층은 바로 적용해볼 만해요. 파이프라인에서 로그를 LLM에 넘기기 직전 단계에 하나 끼워 넣는 구조라 도입 부담도 작고요. 꼭 이 도구가 아니어도, Drain3 같은 파이썬 라이브러리로 비슷한 전처리기를 직접 만들어보는 것도 좋은 공부가 돼요. '원본을 다 넣는 것보다 신호 밀도를 높여서 넣는 게 낫다'는 원칙은 로그뿐 아니라 문서 검색, 코드베이스 분석 등 LLM에 큰 데이터를 물리는 모든 작업에 통하는 감각이거든요.

마무리

정리하면, ctrlb-decompose는 '로그는 템플릿의 반복'이라는 오래된 통찰을 LLM 시대의 토큰 절약과 신호 강화에 연결한 도구예요. 여러분은 장애 분석에 LLM을 어떻게 쓰고 계신가요? 로그를 통째로 넣어보신 분들, 비용이나 품질 면에서 어떤 경험을 하셨는지 나눠주시면 재밌을 것 같아요.