LLM 운영: 어디까지 맡겨도 되나

맡겨도 괜찮았던 것들

2026년 기준, 실제로 돌리면서 ‘여기는 됐다’고 판단한 영역들.

반복 로그 요약. 에러 패턴 분류, 레벨별 집계, Slack 요약 노티. 사람이 하던 15분짜리 작업이 없어졌다. 오탐이 가끔 나오지만 원본 링크 붙여서 같이 보내면 검증 시간이 크지 않다.
초안 문서 생성. 런북, 온콜 가이드, ADR 초안. 80%는 그냥 쓴다. 나머지 20%는 컨텍스트가 빠져서 손본다. 0에서 시작하는 것보다 훨씬 낫다.
코드 리뷰 보조. PR 설명이 빈 채로 올라오는 거 잡기, 변수명 통일성 지적, 타입 누락 경고. 시니어가 볼 시간을 줄여주는 용도로만 쓴다. ‘이게 맞냐’는 판단은 여전히 사람이 한다.
스크립트 일회성 변환. CSV 컬럼 재정렬, 로그 포맷 변환, JSON → YAML. 검증만 하면 되는 작업들. 직접 짜는 것보다 빠르고, 틀려도 즉시 티가 난다.

공통점은 하나다. 결과가 틀려도 즉시 알아챌 수 있는 작업들. 요약이 이상하면 원본 보면 된다. 초안이 틀리면 고치면 된다. 틀린 게 숨는 구조가 아니다.

반대편. 여기서 맡겼다가 불난 것들 혹은 불 날 뻔한 것들.

장애 판단. 증상 수집, 관련 로그 모아오기, 과거 유사 사례 검색까지는 된다. 근데 ‘지금 롤백할 것인가, 기다릴 것인가’는 못 맡긴다. LLM은 현재 시스템 상태를 실시간으로 모른다. 자기가 모른다는 걸 모를 때가 더 위험하다.
배포 승인. 자동화 파이프라인에 LLM 판단을 끼워 넣자는 이야기가 팀 내에서 나왔다. 안 했다. 롤백 비용이 큰 환경에서 LLM이 ‘괜찮아 보인다’고 한 게 근거가 되면 안 된다.
보안 취약점 최종 판정. SAST 결과 요약은 잘 한다. 근데 ‘false positive인가 진짜 위협인가’ 결론은 못 맡긴다. 맥락(데이터 흐름, 실제 접근 가능성)을 LLM이 다 알 수 없다. 알고 있다고 착각하는 게 더 무섭다.
인프라 변경 직접 실행. Terraform plan 설명은 좋다. terraform apply는 사람이 한다. 이건 원칙의 문제고, 바꿀 생각 없다.

여기서의 공통점도 하나다. 틀렸을 때 즉시 안 보이거나, 복구 비용이 크거나, 책임 소재가 흐려지는 작업들. LLM이 틀린 게 아니라 내가 승인한 거라는 구조가 되어버리면, 사고 났을 때 뭘 고쳐야 하는지 모른다.

막상 몇 달 운영해보면서 머릿속에서 정리된 선 하나.

LLM은 초안 기계이자 검색 보조다. 판단 기계가 아니다.

이게 흔들리는 순간은 정해져 있다. 일이 몰릴 때, 피곤할 때, ‘LLM이 괜찮다고 했는데’라는 말이 편해질 때. 그럴 때 맡기면 안 되는 것까지 맡기게 된다.

실용적으로 팀에 공유한 기준은 이렇다:

이 작업, 결과가 틀렸을 때 5분 안에 알 수 있나?
→ Yes: LLM 써라
→ No: 사람이 최종 확인해라

단순하지만 이게 제일 잘 동작했다. ‘이건 AI가 잘 못 한다’ 식의 기술적 설명보다, ‘틀렸을 때 어떻게 아냐’는 질문이 더 빠르게 판단을 잡아줬다.

cache_control 붙이고 max_retries 설정하는 것만큼이나, 어디에 쓰지 않을지 명시해두는 게 운영 코드다.

다음 한 가지: ‘틀렸을 때 5분 안에 알 수 있나’ 기준을 팀 위키에 실제로 한 줄 써두기.

🛒 이 글과 어울리는 추천 상품

위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.