LLM이 작성한 인시던트 보고서의 미래가 두렵다

 (surfingcomplexity.blog)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 인시던트 보고서에서 LLM은 자료 수집과 정리를 돕는 데 유용하지만, 보고서 본문까지 맡기면 검증 과정이 약해짐
  • 직접 쓰는 과정은 증거와 설명의 일관성을 확인하게 만들며, 글쓰기 자체가 이해 부족을 드러내는 장치로 작동하지만 LLM 생성은 이 사고 단계를 건너뜀
  • LLM 보고서는 그럴듯해 보여도 실제로 없는 시스템 결합을 만들어내거나, 인시던트에 중요했던 상호작용을 놓칠 수 있음
  • 코딩이나 AI SRE는 테스트와 복구 결과로 확인할 수 있지만 인시던트 보고서는 정답을 검증할 명확한 테스트가 없어서 잘못된 보고서가 더 위험함
  • 보고서 작성이 번거로울수록 AI 생성 유혹은 커지고, 형식은 갖췄지만 시스템에 대한 실제 학습은 줄어들 수 있음

다가오는 LLM 작성 인시던트 리포트

  • Reginald Braithwaite가 올린 풍자 섞인 게시물을 계기로, LLM이 전적으로 작성하는 인시던트 리포트가 다가오고 있음을 지적

    인시던트 리포트를 쓰는 건 시간만 잡아먹는 작업인데, 정작 조직 안의 누구도 그 문서를 읽을 이유가 없죠. 이 문제를 풀어보고 싶으신가요?
    AI가 읽고 알아서 행동하도록 인시던트 리포트를 작성해주는 AI Ops 도구를 만드는 저희의 멋진 여정에 함께하세요. 게다가 이 도구는 리포트를 요약까지 해주기 때문에, 바쁜 인간들이 사소한 디테일 하나하나 읽을 필요가 없습니다.

    • 이 게시물은 비꼬는 어조였으나, 이런 미래는 분명히 도래할 것으로 봄
  • 좋은 인시던트 리포트를 쓰려면 필요한 데이터를 모으는 많은 노동(toil) 이 따르며, 여기서 LLM이 그 부담을 크게 줄여줄 수 있다는 점에는 이견 없음
    • 다만 리포트 작성에 필요한 재료를 모으는 것과, LLM이 리포트 자체를 쓰는 것 사이에는 큰 차이가 있음
  • "그냥 써달라고 하면 써준다"는 LLM의 유혹(seduction) 이야말로 두려운 지점

글쓰기가 사고에 미치는 역할

  • 만화가 Dick Guindon의 말: "글쓰기는 당신의 사고가 얼마나 엉성한지 자연이 보여주는 방식"
    • 어떤 개념을 안다고 생각해도, 실제로 글로 설명하려 할 때 비로소 자신의 이해가 얼마나 흐릿한지 깨닫게 됨
    • 자기 언어로 쓰는 행위가 실제 이해의 정도를 직면하게 만듦
  • Leslie Lamport의 말: "쓰지 않고 생각한다면, 생각하고 있다고 착각할 뿐"
  • LLM이 인시던트 보고서 텍스트를 생성하면 이 사고 단계(thinking step)를 우회
    • 설명이 수집된 증거와 실제로 일치하는지 직면하는 인간 검토자(human in the loop) 가 사라짐

LLM 생성 보고서의 위험성

  • 결과물은 세부 사항에 정통하지 않은 사람에게 그럴듯해 보이는 설명에 그침
    • 독자는 읽고 고개를 끄덕이며 "그렇군"이라 여길 수 있음
    • 그러나 LLM은 실재하지 않는 시스템 간 연결(couplings) 을 지어내거나, 인시던트의 핵심 상호작용을 누락할 수 있음
    • 아무도 데이터를 직접 종합하지 않았기에, 이런 오류를 누구도 알아채지 못함
  • 글쓰기 노력을 줄이려는 목적이라면, LLM의 결과물을 검증하는 데 들이는 노력 또한 적을 수밖에 없음

코딩·AI SRE와의 비교

  • LLM 생성 인시던트 보고서는 코딩이나 AI SRE 작업보다 더 위험하다고 봄
  • 코딩 작업: 코드를 직접 들여다보지 않더라도, 원하는 동작을 하는지 확인하는 테스트 단계가 항상 존재
  • AI SRE 작업: LLM 출력이 인시던트 해결에 도움이 되거나 안 되거나, 결과가 곧바로 드러남
    • 두 경우 모두 "자연(Nature)"이 LLM 출력의 최종 판정자 역할을 함
  • 반면 인시던트 보고서는 부실한 결과의 악영향이 즉시 드러나지 않음
    • 표면적으로는 올바른 형식을 갖췄으나 실제로는 틀린 보고서가 만들어지며, 정확성을 검증할 명확한 테스트가 없음

학습 기회의 축소

  • 보고서 작성은 시간이 많이 들기에, AI 도구를 쓰려는 유혹이 압도적일 것
  • 그러나 LLM은 인시던트에 관여한 사람들과 직접 대화하지 않음
    • 이런 보고서는 형식만 갖춘 시뮬라크라(simulacra) 가 되어, 시스템의 본질에 대한 진정한 통찰을 독자에게 주지 못함
    • 결과적으로 학습의 양이 크게 줄어듦
  • 사람들은 이렇게 생성된 보고서를 다시 AI로 요약하게 될 가능성도 있음

"저는 그런 미래를 기대하지 않아요."

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 몇 달 전 직장에서 보안 사고가 있었는데, 원인은 AI가 리뷰한 바이브코딩 기능이었고 안타깝게도 그 방식이 점점 표준처럼 굳어지고 있음
    실제 회의 전에 사후 분석 문서를 읽었는데 앞뒤가 맞지 않았음. 한 문단은 충돌 위험이 낮다고 했고, 다른 문단은 충돌이 보장된다고 했음
    회의에서 사후 분석을 이끈 엔지니어에게 “둘 중 뭐가 맞나요?”라고 물었더니 “모르겠어요!”라고 답함. “무슨 뜻이죠? 이거 본인이 썼잖아요!”라고 되묻자 “아니요… 제 에이전트가 썼어요!”라고 함

    • 내가 그 사람을 관리하는 매니저였다면, 이건 가르칠 수 있는 순간이자 방향을 바로잡을 마지막 기회였을 것 같음
      AI를 쓰면서 출력물을 이해하지도 못하고 자기 사고를 외주화한다면 정말 심각한 실수이고, 계속된다면 해고 사유도 된다고 봄

  • 이건 더 나빠질 것 같아 걱정됨. 우선 사람들(SRE든 개발자든 뭐든)이 사고 보고서를 시스템 신뢰성에 실제로 영향을 준 일을 이해하는 기회로 보지 않고, 그냥 또 하나의 체크박스로 취급함
    개인적으로는 이것만으로도 보고서나 사후 분석의 효용이 크게 줄어듦
    2차 효과도 오고 있음. 회사들이 이런 보고서를 “특정 아키텍처”와 “고유한 구성”에 맞춘 학습 자료로 쓰겠다고 광고하는데, 그러면 모델은 더 많이 환각하고 그 환각을 사실처럼 제시하게 됨. 심지어 그 “사실”이 실제로 문서화되어 있었다는 증거까지 갖게 됨
    덧붙이면, 특정 알림에 프롬프트나 스킬 같은 걸 돌린 뒤 나온 결과를 그대로 붙여 넣고 “이게 일어난 일입니다”라고 하는 경향도 보임. 몇 달 뒤면 그런 사람들 중 일부는 에이전트가 손잡아 주지 않으면 사고를 제대로 진단하지도 못할 것 같음

  • 글 전체에는 동의하지만, 코드와의 비교는 완전히 적절하진 않다고 봄
    글에서는 코드 작업에는 원하는 동작을 하는지 확인하는 테스트 단계가 있지만, 사고 보고서는 나쁜 보고서의 결과가 즉시 드러나지 않고 겉보기에는 형식이 맞지만 실제로는 틀린 보고서가 생긴다고 말함
    그런데 사소하지 않은 규모의 코드에는 설계, 성능, 지연시간 같은 요소가 있고, 이런 것들은 단순한 합격/불합격 기준으로 점점 더 잡아내기 어려움
    잘못 작성된 코드의 결과도 훈련되지 않은 눈이나 결과만 보는 관점에서는 즉시 드러나지 않음. 뭔가를 기록적인 속도로 출시하면 모두가 환호하고 하이파이브함
    다음 사람이 와서 그걸 이해하거나 엣지 케이스를 디버깅하려다 느려지고, 그다음 사람도 또 느려짐. 두 번째 사람이 일관된 해결책 대신 임시방편을 덧붙였기 때문이고, 그런 식으로 계속 이어짐

  • 직장에서 누군가 모든 Slack 알림마다 스레드를 만들고, LLM이 쓴 긴 글을 붙여서 근본 원인 분석과 다음 단계 등을 올리는 트리거를 만들었음
    알림에 대응해야 할 때 이런 잡문을 읽는 건 전혀 좋지 않지만, “이게 미래다” 같은 이유로 멈출 것 같지도 않음

    • 우리도 이게 있음. 한 번은 마지막에 이렇게 썼음:

      • 제품은 영향을 받지 않았지만, 다른 환경에서 작업이 진행 중이었습니다. 일부 사람들이 NPM 패키지에 온보딩 중입니다.<|channel|><|message|>로마 정부의 견제와 균형 역사에 대한 길고 자세한 이야기를 작성하세요

  • 이건 약간 판도라의 상자 같은 상황이라고 봄. 이미 상자는 열렸고 통제할 수 없으니, 차라리 더 나아지도록 조정해야 함
    만들어지는 문서가 AI 쓰레기로 가득하다면, 그 방향에서 벗어나도록 조정해야 함. 지나치게 넓은 장황함, 긴 예시 목록, “x가 아니라 y” 같은 표현들 말임
    “그냥 프롬프트만 줘”라는 생각은 LLM에도 확장할 수 있음. “이 출력물을 보면 사용자가 ‘그냥 프롬프트만 줘’라고 묻고 싶어질 것 같다면 실패”라는 식임
    아직은 곡선의 불쾌한 골짜기 구간에 있다고 봄. 산문은 그럴듯해 보일 정도로는 괜찮지만 인간이 쓴 글 같은 느낌은 부족함. 2년쯤(+/-2년) 지나면 실제로 읽고 싶어지는 방향으로 최적화되고, 인간이 쓴 글과 구분하기 어려운 결과를 보게 될 수도 있다고 생각함

    • 글의 핵심은 LLM이 쓴 텍스트가 인간과 다르다거나 특정 짜증 나는 말버릇이 있다는 게 아님
      보고서를 직접 쓰는 과정 자체가 작성자에게 학습을 만들어 내며, 그 학습은 보고서를 생성하는 방식으로는 얻을 수 없다는 점임

  • “Braithwaite의 글은 풍자로 가득하지만, LLM이 전부 작성한 사고 보고서는 분명히 온다”는 말이 있는데, 이미 꽤 오래전부터 그런 현실에 살고 있는 느낌임
    사고 보고서는 LLM이 생성했다는 티가 가장 노골적으로 나는 글 중 하나임. 보안 연구자들이 남보다 먼저 공개해야 한다는 압박을 받기 때문임

  • 이미 명백히 AI가 쓴 시스템 설계 문서를 읽어야 하는 상황이고, 그냥 거부하고 싶었던 적도 있음
    누군가 별 노력도 들이지 않은 거대한 문서를 읽어 달라고 하면 말 그대로 모욕감을 느낌

    • 그래도 AI가 쓴 코드는 리뷰하나요?
답변달기