발표에서 확인된 핵심 사실

시스템 장애가 터지고 나면 쏟아지는 로그 데이터와 씨름하며 보고서를 써야 하는 지루한 시간이 찾아온다. 이 고통스러운 과정을 LLM(거대언어모델)에게 전담시키면 보고서는 빠르게 완성되지만, 정작 글을 쓰며 고민하는 사고 단계는 통째로 사라진다.

직접 보고서를 작성하는 행위는 수집한 증거와 설명이 서로 맞는지 확인하는 검증 장치다. 글을 쓰다 막히는 지점이 곧 내가 시스템을 제대로 이해하지 못한 부분임을 알려준다. LLM이 보고서를 대신 생성하면 인간 검토자는 증거와 설명의 불일치를 직접 마주하고 고민할 기회를 잃는다.

LLM은 장애 상황에 직접 참여한 사람들과 대화하며 맥락을 파악하지 않는다. 그렇게 만들어진 결과물은 겉모습만 그럴싸한 시뮬라크라(실제 존재하지 않는 대상의 복제물)가 될 가능성이 크다. 결국 조직원들이 시스템의 본질을 꿰뚫어 보는 통찰력을 기를 기회와 실제 학습량은 줄어든다.

Reginald Braithwaite는 AI Ops(인공지능 기반 IT 운영) 도구가 리포트를 쓰고 요약해 주는 미래를 풍자했다. 바쁜 사람들이 세부 사항을 읽지 않아도 되는 상황을 비꼰 것이지만, 이는 LLM이 보고서 작성을 완전히 대체하는 시대가 가까워졌음을 보여준다.

생성 보고서는 그럴듯해 보이지만 허위 정보를 포함하거나 핵심

자동화가 주는 시간 단축은 공짜처럼 보이지만, 검증이라는 숨은 비용을 지불하지 않으면 치명적인 결과로 돌아온다. 시스템 장애 후 쏟아지는 수많은 로그와 데이터를 일일이 대조해 보고서를 쓰는 과정은 지루하고 고통스럽다. LLM이 이 작업을 대신하면 증거와 설명이 일치하는지 확인하는 사고 단계가 생략된다. 이 과정에서 실제로 존재하지 않는 시스템 간 결합(소프트웨어 구성 요소들이 서로 연결된 상태)을 지어내거나 인시던트 해결에 중요했던 상호작용을 놓친다. 데이터를 직접 종합하며 논리를 세운 것이 아니기에 작성자는 이런 오류를 알아채기 어렵다.

코딩이나 AI SRE(시스템 안정성을 유지하고 복구하는 작업)는 정답을 확인할 명확한 기준이 있다. 코드는 테스트 코드를 돌려보고, SRE 작업은 시스템이 실제로 복구됐는지 즉시 확인하면 된다. 하지만 보고서는 정답을 검증할 테스트가 없다. 겉모습은 완벽한 형식을 갖췄더라도 내용은 틀린 보고서가 만들어질 위험이 크며, 그 부작용은 즉시 나타나지 않는다. 보고서는 코딩처럼 실행 버튼을 눌러 정답 여부를 가릴 수 있는 장치가 없기에 표면적인 완성도에 속아 잘못된 분석 결과를 그대로 수용할 가능성이 크다.

실무에서는 LLM을 보고서 본문을 작성하는 도구로 쓰기보다 데이터 수집과 정리 단계까지만 활용하는 기준을 세워야 한다. 사실 관계를 확정하고 논리를 연결하는 최종 단계에서는 사람이 직접 개입해야 허위 정보의 함정을 피할 수 있다. 데이터 정리라는 단순 반복 작업은 AI에게 맡기되, 결론을 내리는 판단은 사람이 맡는 역할 분담이 필요하다. 이렇게 해야만 AI가 만들어낸 그럴듯한 거짓말에 속지 않고 정확한 인시던트 분석 결과를 남길 수 있다.

시스템 장애 후 쏟아지는 로그 데이터를 정리해 보고서를 쓰는 과정은 지루하고 고통스럽습니다. 하지만 LLM이 보고서를 대신 쓰면 증거와 설명의 일관성을 따지는 사고 과정이 생략되어, 실재하지 않는 시스템 결함을 그럴듯하게 지어낼 위험이 큽니다. 코딩이나 AI SRE 작업은 테스트와 복구 결과라는 명확한 판정 기준이 있지만, 보고서는 정답을 검증할 테스트가 없기 때문입니다.

LLM을 보고서 본문 작성이 아닌 데이터 수집과 정리 단계까지만 활용하는 실무적 기준을 세워야 합니다. 편리함에 속아 검증 단계를 생략하는 순간, 보고서는 기록이 아니라 소설이 됩니다.