AI 가 장애 알림을 먼저 받고 원인 후보를 짚어주고 조치까지 끝내주는 환경이 되면, 그 시스템을 몇 년째 운영해 온 엔지니어의 감각은 그 사이에 어디로 가는 걸까요?
안녕하세요? 정리하는 개발자 워니즈입니다. 이번 글에서는 AI SRE 가 장애 처리를 대신 맡을 때 엔지니어 쪽에 조용히 쌓이는 이해 부채라는 개념을 원문 근거로 정리하고, 여기에 필자가 개인 블로그 자동화 파이프라인에서 실제로 겪은 검증 실패 한 건을 붙여서 이 부채가 장애 대응 바깥에서도 똑같은 모양으로 쌓인다는 것을 확인해 보려고 합니다.
한 줄 요약. AI SRE 는 평균 복구 시간을 줄여주는 대신 엔지니어가 시스템 작동 방식을 몸으로 익힐 기회를 같이 줄이고, 그 상태가 길어지면 정작 복잡한 장애에서 대응이 더 느려질 위험이 생깁니다. 원문이 내놓은 처방은 항공업계처럼 정기적인 모의훈련을 제도로 박아 두는 것이고, 필자의 검증 사례가 덧붙이는 것은 산출물 검사에 사실 확인 층이 없으면 오류가 그대로 통과한다는 점입니다.
목차
- AI SRE 와 이해 부채는 무엇을 말하나요?
- 자동화가 좋아질수록 왜 더 숙련된 사람이 필요할까요?
- 항공업계는 같은 문제를 어떻게 풀었는가
- 직접 확인 1: 문서 작성에서도 같은 부채가 쌓였다
- 직접 확인 2: 검사기는 왜 거짓 6건을 통과시켰을까요?
- 직접 확인 3: 이 글에서 확인 불가로 남긴 것
- AI SRE 를 쓰면서 이해 부채를 줄이는 훈련 설계
- AI SRE 로 안 되는 것과 오해하기 쉬운 것
- 정리: 누구에게 맞고 누구에게는 굳이인가
1. AI SRE 와 이해 부채는 무엇을 말하나요?
여기서 말하는 AI SRE 는 특정 제품 이름이 아니라, 장애 감지부터 원인 후보 추정과 조치 제안까지를 사람 대신 수행하는 도구 계층을 가리키는 말로 쓰겠습니다. 예전에는 알림이 오면 사람이 대시보드를 열고 로그를 훑고 최근 배포를 뒤지면서 가설을 세웠는데요, AI SRE 가 붙으면 그 과정의 결과물만 요약된 형태로 사람 앞에 도착합니다.
이해 부채는 Sylvain Kalache 가 쓴 comprehension debt 를 우리말로 옮긴 표현입니다. 기술 부채가 나중에 갚아야 할 코드의 빚이라면, 이해 부채는 지금 이해하지 않고 넘긴 시스템 지식이 나중에 이자를 붙여 돌아오는 빚이라는 뜻으로 읽히는 것 같습니다.
원문이 세운 주장은 다섯 줄로 정리됩니다.
- AI SRE 가 장애 처리를 자동화하면 평균 복구 시간은 짧아집니다. 대신 엔지니어가 시스템 작동 방식을 체득할 기회는 줄어듭니다.
- 자동화가 발전할수록 엔지니어에게는 더 높은 숙련도와 의도적인 훈련이 요구됩니다. 원문은 이것을 자동화의 역설이라고 부릅니다.
- 경험이 쌓이지 않은 상태에서 복잡한 장애를 만나면 대응 시간이 오히려 늘어날 위험이 있습니다.
- 항공업계가 조종사에게 요구하는 것처럼 엔지니어도 장애 조사와 압박 속 판단과 의사소통을 모의훈련으로 연습해야 합니다.
- AI 가 붙여 주는 진단 설명을 읽는 것만으로는 직접 경험을 대체할 수 없습니다. 이해 부채를 줄이려면 정기적인 실습이 필수입니다.
필자가 이 글을 굳이 옮겨 적는 이유는 주장 자체가 새롭기 때문이 아닙니다. 자동화를 도입한 조직이 측정하는 지표와, 자동화가 실제로 깎아 먹는 능력이 서로 다른 축에 있다는 점을 이만큼 또렷하게 지적한 글을 최근에 보지 못했기 때문입니다.
2. 자동화가 좋아질수록 왜 더 숙련된 사람이 필요할까요?
직관적으로는 반대일 것 같습니다. 도구가 알아서 해 주니 사람은 덜 알아도 된다는 쪽이 자연스러운데요, 원문은 정확히 그 직관이 틀린 지점을 자동화의 역설이라는 이름으로 짚습니다.
이유는 자동화가 처리하는 사건과 사람에게 남는 사건이 균등하게 나뉘지 않는다는 데 있는 것 같습니다. 자동화는 빈도가 높고 패턴이 반복되는 장애를 먼저 흡수하고, 사람 앞에는 빈도가 낮고 전례가 없고 여러 계층이 동시에 얽힌 사건만 남습니다. 그러니까 사람이 다루는 문제의 평균 난이도는 자동화가 잘 될수록 올라갑니다.
문제는 그 어려운 문제를 풀 감각이 쉬운 문제를 반복해서 겪는 과정에서 만들어졌다는 것입니다. 자동화가 쉬운 문제를 다 가져가 버리면 어려운 문제를 풀 사람이 자라날 훈련장이 같이 사라지는 셈인데요, 이것이 세 번째 주장인 대응 시간 역전 위험으로 이어집니다.
| 자동화가 줄여 주는 것 | 자동화가 오히려 요구하는 것 |
|---|---|
| 반복 장애의 평균 복구 시간 | 남은 비정형 장애를 풀 더 높은 숙련도 |
| 새벽 호출과 단순 조치의 피로 | 의도적으로 설계된 훈련 시간의 확보 |
| 초기 원인 후보를 좁히는 손품 | AI 진단을 의심하고 검증하는 별도 능력 |
| 조치 절차를 기억해야 하는 부담 | 절차가 통하지 않을 때의 판단과 의사소통 |
오른쪽 열이 왼쪽 열보다 재무제표에 잘 잡히지 않는다는 점이 이 문제의 실무적 난점이라고 생각합니다. 평균 복구 시간은 대시보드에 숫자로 뜨는데, 조직의 시스템 감각이 얼마나 얇아졌는지는 다음 대형 장애가 오기 전까지 아무 지표에도 나타나지 않습니다.
이 감각을 지키는 방법은 결국 자동화가 대신 처리해 주는 부분을 사람이 다시 손으로 재보는 습관인 것 같습니다. 인프라 장애가 아닌 자리에서도 같은 습관이 통하는데요, Claude Code 플러그인 토큰 줄이기 3단계 에서는 AI 도구가 대신 처리해 주는 토큰 사용량을 사람이 직접 측정해 본 사례를 다뤘습니다. AI SRE 환경에서 이해 부채를 줄이는 훈련도 방향은 같습니다. 자동화가 대신 삼켜 버린 부분을 사람이 주기적으로 다시 손으로 재보는 것입니다.
3. 항공업계는 같은 문제를 어떻게 풀었는가
원문이 항공업계를 끌어오는 대목이 이 글에서 가장 설득력 있는 부분이었습니다. 항공기 엔진은 이미 사람이 손댈 일이 거의 없을 만큼 신뢰도가 올라갔는데, 그렇다고 조종사 훈련을 줄이지는 않았다는 것이 핵심입니다.
| 원문이 제시한 수치 | 값 | 이 수치가 말하는 것 |
|---|---|---|
| 현대 터빈 엔진의 비행 중 정지 빈도 | 엔진 비행 10만 시간당 1회 미만 | 사람이 개입할 사건 자체가 극히 드물어졌다 |
| TransAsia Airways Flight 235 추락까지 걸린 시간 | 117초 | 그 드문 사건이 오면 판단 시간은 2분이 채 안 된다 |
| 미국 FAA 규정상 기장의 반복 교육 주기 | 6개월마다 | 그래서 훈련을 빈도가 아니라 제도로 고정한다 |
세 숫자를 나란히 놓으면 논리가 한 줄로 이어집니다. 사건은 10만 시간에 한 번도 안 오지만 오는 순간 주어진 시간은 117초이므로, 훈련을 사건 빈도에 맞추면 아무도 준비되지 않은 상태가 되고 그래서 6개월이라는 고정 주기를 규정으로 박아 둔 것입니다.
AI SRE 를 도입한 조직에도 같은 비대칭이 생깁니다. 자동화가 잘 돌면 사람이 직접 원인을 파야 하는 사건은 드물어지는데요, 그 드문 사건은 하필 가장 복잡한 사건이고 대응에 주어진 시간은 짧습니다. 훈련을 사건 빈도에 맞추면 준비가 안 되는 구조라는 점에서 항공업계와 조건이 같은 것 같습니다.
4. 직접 확인 1: 문서 작성에서도 같은 부채가 쌓였다
여기까지는 원문 요약입니다. 필자가 이 주제를 그냥 넘기지 못한 것은 장애 대응이 아니라 문서 작성에서 정확히 같은 일을 겪었기 때문인데요, 2026년 9월 8일에 개인 블로그 자동화 파이프라인을 점검하다가 확인한 내용입니다.
외부 AI 도구가 만든 기술 분석 문서 한 건을 공식 문서와 로컬 실측으로 하나씩 대조했습니다. 어떤 제품이었는지는 이 글의 논지와 무관하므로 적지 않겠습니다. 문제는 제품이 아니라 그 산출물을 받는 쪽에 검증 층이 없었다는 것이기 때문입니다.
| 검증 결과 등급 | 건수 |
|---|---|
| 사실 | 0건 |
| 부분사실 | 2건 |
| 확인불가 | 1건 |
| 거짓 | 6건 |
| 검증한 기술 주장 총계 | 9건 |
거짓 6건의 성격은 세 종류로 갈렸습니다. 첫째는 존재하지 않는 설정 파일의 세팅 가이드였고, 둘째는 그 환경에서 재현이 불가능한 실험 로그였는데 리눅스 전용 도구의 출력을 macOS 실행 결과로 제시한 형태였습니다. 셋째는 제품 출시 시점이 약 1년 어긋난 서술이었습니다.
읽는 동안에는 이 문서가 이상해 보이지 않았다는 점이 필자에게는 가장 불편한 부분이었습니다. 문장은 매끄럽고 구조는 정연하고 경로와 명령이 구체적이어서 오히려 신뢰가 갔는데요, 틀린 부분을 잡아낸 것은 공식 문서를 열어 항목별로 대조한 다음이었습니다.
5. 직접 확인 2: 검사기는 왜 거짓 6건을 통과시켰을까요?
이 사례에서 진짜 발견은 거짓 6건이 아니라고 생각합니다. 그 문서가 기존 검사 단계를 전부 통과할 수 있는 상태였다는 것이 발견이었습니다.
당시 파이프라인에는 검사 층이 이미 여러 개 있었습니다. 형식 검사와 보안 검사와 SEO 검사가 각각 자기 기준으로 원고를 훑고 통과 여부를 알려 주는데요, 이 층들을 나란히 적어 보고 나서야 무엇이 빠져 있는지가 보였습니다.
| 검사 층 | 이 층이 묻는 질문 | 거짓 6건을 잡는가 |
|---|---|---|
| 형식 검사 | 분량과 소제목 구조가 규격에 맞는가 | 못 잡는다 |
| 보안 검사 | 공개하면 안 되는 정보가 섞였는가 | 못 잡는다 |
| SEO 검사 | 키워드와 링크가 기준을 채웠는가 | 못 잡는다 |
| 사실 검사 | 이 문장이 실제로 참인가 | 층 자체가 없었다 |
세 층은 모두 성실하게 동작했고 자기 임무도 정확히 수행했습니다. 다만 세 층이 공통으로 묻는 것은 글이 규격에 맞는가였고, 글이 사실인가를 묻는 단계는 어디에도 없었습니다. 검사기가 초록불을 켰다는 사실이 내용이 참이라는 뜻으로 읽히기 쉽다는 점에서, 이 구조는 오류를 걸러 내는 대신 오류에 보증서를 붙여 주고 있었던 것 같습니다.
검증 층이 비어 있는데 자동화가 잘 돌고 있다고 믿는 구조는 이번이 처음 겪은 것도 아닙니다. 블로그운영 카테고리에 적어 둔 제 블로그 글 절반 이상이 구글 색인에 없었습니다 에서 다룬 사례도 자동화가 정상 작동한다고 믿고 있었지만 실제로는 글 절반이 색인에서 누락된 상태였습니다. 검증하지 않으면 문제를 감지하지 못한다는 점에서, 이 글의 사실 검사 층 부재와 정확히 같은 구조입니다.
이 지점에서 이해 부채와 연결됩니다. 자동화가 산출물을 계속 만들어 주면 그 산출물을 의심하고 대조하는 능력은 따로 훈련하지 않는 한 자라지 않고, 그 상태에서는 오류가 있어도 감지되지 않습니다. AI SRE 가 장애 원인을 설명해 줄 때 그 설명이 맞는지 판단하는 능력도 정확히 같은 자리에 있는 것 같습니다.
AI 도구에 작업을 맡길 때 생기는 다른 종류의 위험은 Claude Code 프롬프트 인젝션 막는 4가지 에서 따로 정리해 두었는데요, 그 글이 다루는 것이 입력을 오염시키는 공격이라면 이 글이 다루는 것은 출력을 검증하지 않는 습관입니다.
6. 직접 확인 3: 이 글에서 확인 불가로 남긴 것
실패한 검증도 지우지 않고 적어 두겠습니다. 이 글을 쓰면서 확인하고 싶었지만 확인할 수단이 없었던 항목이 세 가지 있습니다.
- AI SRE 도입 조직의 대응 시간 역전이 실제로 관측되었는지는 확인하지 못했습니다. 원문의 세 번째 주장은 위험 서술이고, 필자에게는 이를 검증할 조직 단위 데이터가 없습니다.
- 이해 부채를 수치로 재는 방법도 확인하지 못했습니다. 평균 복구 시간처럼 지표화된 사례를 찾지 못했고, 없는 지표를 만들어 적는 것은 이 글의 규칙에 어긋납니다.
- 필자가 겪은 검증 실패가 다른 환경에서도 같은 비율로 재현되는지는 미확인입니다. 표본은 문서 한 건과 주장 9건이므로 비율을 일반화할 근거가 되지 못합니다.
세 항목을 미확인으로 남기는 편이 그럴듯한 숫자를 적는 것보다 이 글의 논지에 오히려 맞는다고 생각합니다. 검증되지 않은 문장을 검증된 것처럼 적는 습관이 이 글이 지적하는 바로 그 문제이기 때문입니다.
7. AI SRE 를 쓰면서 이해 부채를 줄이는 훈련 설계
원문의 처방은 정기적 실습이고, 필자의 사례가 덧붙이는 처방은 검증 층을 절차로 만드는 것입니다. 두 처방을 합쳐서 AI SRE 를 이미 쓰고 있는 팀이 무엇을 고정할 수 있는지 정리해 보았습니다.
| 항목 | 무엇을 하는가 | 왜 필요한가 |
|---|---|---|
| 고정 주기 | 사건 빈도가 아니라 달력 기준으로 실습 일정을 잡는다 | 항공업계가 6개월 주기를 규정으로 둔 이유와 같다 |
| 재현 실습 | 지난 장애를 다시 열어 사람이 처음부터 원인을 찾아 본다 | 자동화가 흡수한 쉬운 사건을 훈련장으로 되돌린다 |
| 진단 대조 | AI 가 낸 원인 설명을 근거 문서와 항목별로 맞춰 본다 | 설명을 읽는 것과 검증하는 것은 다른 능력이다 |
| 압박 연습 | 시간 제한과 보고 대상을 둔 상태로 판단과 공유를 연습한다 | 실제 장애에서 판단만큼 의사소통이 걸린다 |
여기서 필자가 가장 저렴하다고 보는 것은 세 번째 진단 대조입니다. 새 훈련 프로그램을 만들지 않아도 되고, 이미 AI 가 내놓고 있는 산출물을 놓고 근거를 한 번 더 열어 보는 절차 한 줄만 추가하면 되기 때문입니다.
도구를 새로 붙이기 전에 확인할 것들을 정리한 Claude Code 플러그인 설치 전 확인 3가지 와 묶어서 보시면, 도입 단계에서 미리 정해 둘 수 있는 항목이 생각보다 많다는 것을 확인하실 수 있을 것 같습니다.
8. AI SRE 로 안 되는 것과 오해하기 쉬운 것
이 글이 AI SRE 를 쓰지 말자는 이야기로 읽히면 곤란할 것 같습니다. 평균 복구 시간 단축은 실제 이득이고 새벽에 사람을 깨우는 횟수가 줄어드는 것도 분명한 이득인데요, 아래 항목들은 그 이득으로 덮이지 않는 자리입니다.
- AI 의 진단 설명이 직접 경험을 대체하지 못합니다. 원문의 다섯 번째 주장이고, 필자가 겪은 검증 실패도 설명을 읽는 것과 사실을 확인하는 것이 다른 활동임을 보여 줍니다.
- 자동화가 훈련을 대신 설계해 주지 않습니다. 자동화는 사건을 흡수하는 쪽이고, 흡수된 사건을 훈련용으로 되돌리는 것은 사람이 절차로 정해야 하는 일입니다.
- 규격 검사 통과가 내용의 참을 보증하지 않습니다. 형식과 보안과 SEO 검사가 전부 초록불이어도 기술 주장 9건 중 사실이 0건일 수 있다는 것을 필자가 직접 확인했습니다.
- 지표 개선이 능력 유지의 근거가 되지 않습니다. 평균 복구 시간이 좋아지는 동안 시스템 감각이 얇아지고 있어도 그 사실은 어느 대시보드에도 나타나지 않습니다.
특히 마지막 항목이 위험합니다. 도입 효과를 보고할 때 쓰는 숫자와 도입 부작용이 나타나는 축이 서로 다르기 때문에, 효과 보고가 잘될수록 부작용을 논의할 자리가 사라지는 구조가 만들어지기 쉽습니다. 그래서 이 항목은 지표를 보는 사람이 따로 챙기지 않으면 아무도 꺼내지 않게 됩니다.
9. 정리: 누구에게 맞고 누구에게는 굳이인가, 그리고 필자의 결론
이 글의 논지를 한 문단으로 줄이면 이렇습니다. AI SRE 는 반복 장애를 흡수해 평균 복구 시간을 줄여 주지만 그 과정에서 엔지니어가 시스템을 체득할 기회도 같이 줄이고, 그렇게 쌓인 이해 부채는 가장 어려운 장애가 왔을 때 이자를 붙여 청구됩니다.
지금 이 문제를 챙길 필요가 큰 쪽은 자동화 도입 이후 사람이 직접 원인을 파는 일이 눈에 띄게 줄어든 팀입니다. 여기에 더해 산출물 검사가 형식과 보안 위주로만 구성되어 있고 사실 확인 단계가 없는 팀이라면, 훈련보다 검증 절차 한 줄을 먼저 넣는 편이 효과가 빠를 것 같습니다.
아직 굳이일 수 있는 쪽은 자동화 범위가 알림 집계와 요약 수준에 머물러 있어서 원인 판단을 여전히 사람이 하고 있는 팀입니다. 이 경우에는 훈련장이 아직 사라지지 않았으므로, 이해 부채 대책보다 자동화 범위를 어디까지 넓힐지 정하는 결정이 먼저 오는 것이 맞다고 생각합니다.
그리고 필자의 결론
자동화를 늘릴지 말지가 아니라, 늘린 만큼 무엇을 훈련으로 되돌릴지를 같이 정해야 합니다. 이 글을 쓰면서 가장 선명해진 것은 원문의 항공업계 수치가 아니었습니다. 거짓 6건을 잡아낸 것이 결국 사람이 공식 문서를 하나씩 열어 본 행위였다는 사실입니다. 도구가 답을 만들어 주는 속도는 이미 충분한데, 그 답을 의심하는 절차는 아무도 만들어 주지 않습니다.
그래서 필자는 네 가지 처방 중 진단 대조 한 줄을 개인 파이프라인에 먼저 넣었습니다. 훈련 주기나 모의 장애는 팀 합의가 필요하지만 근거 대조는 혼자서도 오늘 넣을 수 있고, 실제로 이번에 그 한 줄이 거짓 6건을 걸러냈습니다.
나머지 세 가지는 아직 넣지 않았습니다. AI SRE 를 실제 운영에 붙여본 적이 없어서 어느 시점에 필요해지는지 판단할 근거가 제게 없습니다. 그 판단은 도구를 붙인 뒤 첫 장애를 겪어 보고 다시 쓰겠습니다.
이 글이 근거로 쓴 1차 출처
- Sylvain Kalache, AI 가 장애를 처리할수록 엔지니어는 시스템 감각을 잃는다: 원문 보기
- 국내 소개 및 논의: GeekNews 해당 토픽 (2026년 9월 5일)
본문의 항공업계 수치 세 개와 원문 주장 다섯 개는 위 1차 출처에 근거합니다. 검증 결과 9건은 필자가 2026년 9월 8일 개인 블로그 자동화 파이프라인에서 macOS 환경으로 직접 대조한 결과이고, 그 밖에 확인 수단이 없던 항목은 6번 항목에 미확인으로 남겨 두었습니다.