Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

AI 가 장애 알림을 먼저 받고 원인 후보를 짚어주고 조치까지 끝내주는 환경이 되면, 그 시스템을 몇 년째 운영해 온 엔지니어의 감각은 그 사이에 어디로 가는 걸까요?

안녕하세요? 정리하는 개발자 워니즈입니다. 이번 글에서는 AI SRE 가 장애 처리를 대신 맡을 때 엔지니어 쪽에 조용히 쌓이는 이해 부채라는 개념을 원문 근거로 정리하고, 여기에 필자가 개인 블로그 자동화 파이프라인에서 실제로 겪은 검증 실패 한 건을 붙여서 이 부채가 장애 대응 바깥에서도 똑같은 모양으로 쌓인다는 것을 확인해 보려고 합니다.

한 줄 요약. AI SRE 는 평균 복구 시간을 줄여주는 대신 엔지니어가 시스템 작동 방식을 몸으로 익힐 기회를 같이 줄이고, 그 상태가 길어지면 정작 복잡한 장애에서 대응이 더 느려질 위험이 생깁니다. 원문이 내놓은 처방은 항공업계처럼 정기적인 모의훈련을 제도로 박아 두는 것이고, 필자의 검증 사례가 덧붙이는 것은 산출물 검사에 사실 확인 층이 없으면 오류가 그대로 통과한다는 점입니다.

목차

1. AI SRE 와 이해 부채는 무엇을 말하나요?
2. 자동화가 좋아질수록 왜 더 숙련된 사람이 필요할까요?
3. 항공업계는 같은 문제를 어떻게 풀었는가
4. 직접 확인 1: 문서 작성에서도 같은 부채가 쌓였다
5. 직접 확인 2: 검사기는 왜 거짓 6건을 통과시켰을까요?
6. 직접 확인 3: 이 글에서 확인 불가로 남긴 것
7. AI SRE 를 쓰면서 이해 부채를 줄이는 훈련 설계
8. AI SRE 로 안 되는 것과 오해하기 쉬운 것
9. 정리: 누구에게 맞고 누구에게는 굳이인가

1. AI SRE 와 이해 부채는 무엇을 말하나요?

여기서 말하는 AI SRE 는 특정 제품 이름이 아니라, 장애 감지부터 원인 후보 추정과 조치 제안까지를 사람 대신 수행하는 도구 계층을 가리키는 말로 쓰겠습니다. 예전에는 알림이 오면 사람이 대시보드를 열고 로그를 훑고 최근 배포를 뒤지면서 가설을 세웠는데요, AI SRE 가 붙으면 그 과정의 결과물만 요약된 형태로 사람 앞에 도착합니다.

이해 부채는 Sylvain Kalache 가 쓴 comprehension debt 를 우리말로 옮긴 표현입니다. 기술 부채가 나중에 갚아야 할 코드의 빚이라면, 이해 부채는 지금 이해하지 않고 넘긴 시스템 지식이 나중에 이자를 붙여 돌아오는 빚이라는 뜻으로 읽히는 것 같습니다.

원문이 세운 주장은 다섯 줄로 정리됩니다.

• AI SRE 가 장애 처리를 자동화하면 평균 복구 시간은 짧아집니다. 대신 엔지니어가 시스템 작동 방식을 체득할 기회는 줄어듭니다.
• 자동화가 발전할수록 엔지니어에게는 더 높은 숙련도와 의도적인 훈련이 요구됩니다. 원문은 이것을 자동화의 역설이라고 부릅니다.
• 경험이 쌓이지 않은 상태에서 복잡한 장애를 만나면 대응 시간이 오히려 늘어날 위험이 있습니다.
• 항공업계가 조종사에게 요구하는 것처럼 엔지니어도 장애 조사와 압박 속 판단과 의사소통을 모의훈련으로 연습해야 합니다.
• AI 가 붙여 주는 진단 설명을 읽는 것만으로는 직접 경험을 대체할 수 없습니다. 이해 부채를 줄이려면 정기적인 실습이 필수입니다.

필자가 이 글을 굳이 옮겨 적는 이유는 주장 자체가 새롭기 때문이 아닙니다. 자동화를 도입한 조직이 측정하는 지표와, 자동화가 실제로 깎아 먹는 능력이 서로 다른 축에 있다는 점을 이만큼 또렷하게 지적한 글을 최근에 보지 못했기 때문입니다.

2. 자동화가 좋아질수록 왜 더 숙련된 사람이 필요할까요?

직관적으로는 반대일 것 같습니다. 도구가 알아서 해 주니 사람은 덜 알아도 된다는 쪽이 자연스러운데요, 원문은 정확히 그 직관이 틀린 지점을 자동화의 역설이라는 이름으로 짚습니다.

이유는 자동화가 처리하는 사건과 사람에게 남는 사건이 균등하게 나뉘지 않는다는 데 있는 것 같습니다. 자동화는 빈도가 높고 패턴이 반복되는 장애를 먼저 흡수하고, 사람 앞에는 빈도가 낮고 전례가 없고 여러 계층이 동시에 얽힌 사건만 남습니다. 그러니까 사람이 다루는 문제의 평균 난이도는 자동화가 잘 될수록 올라갑니다.

문제는 그 어려운 문제를 풀 감각이 쉬운 문제를 반복해서 겪는 과정에서 만들어졌다는 것입니다. 자동화가 쉬운 문제를 다 가져가 버리면 어려운 문제를 풀 사람이 자라날 훈련장이 같이 사라지는 셈인데요, 이것이 세 번째 주장인 대응 시간 역전 위험으로 이어집니다.

오른쪽 열이 왼쪽 열보다 재무제표에 잘 잡히지 않는다는 점이 이 문제의 실무적 난점이라고 생각합니다. 평균 복구 시간은 대시보드에 숫자로 뜨는데, 조직의 시스템 감각이 얼마나 얇아졌는지는 다음 대형 장애가 오기 전까지 아무 지표에도 나타나지 않습니다.

이 감각을 지키는 방법은 결국 자동화가 대신 처리해 주는 부분을 사람이 다시 손으로 재보는 습관인 것 같습니다. 인프라 장애가 아닌 자리에서도 같은 습관이 통하는데요, Claude Code 플러그인 토큰 줄이기 3단계 에서는 AI 도구가 대신 처리해 주는 토큰 사용량을 사람이 직접 측정해 본 사례를 다뤘습니다. AI SRE 환경에서 이해 부채를 줄이는 훈련도 방향은 같습니다. 자동화가 대신 삼켜 버린 부분을 사람이 주기적으로 다시 손으로 재보는 것입니다.

3. 항공업계는 같은 문제를 어떻게 풀었는가

원문이 항공업계를 끌어오는 대목이 이 글에서 가장 설득력 있는 부분이었습니다. 항공기 엔진은 이미 사람이 손댈 일이 거의 없을 만큼 신뢰도가 올라갔는데, 그렇다고 조종사 훈련을 줄이지는 않았다는 것이 핵심입니다.

세 숫자를 나란히 놓으면 논리가 한 줄로 이어집니다. 사건은 10만 시간에 한 번도 안 오지만 오는 순간 주어진 시간은 117초이므로, 훈련을 사건 빈도에 맞추면 아무도 준비되지 않은 상태가 되고 그래서 6개월이라는 고정 주기를 규정으로 박아 둔 것입니다.

AI SRE 를 도입한 조직에도 같은 비대칭이 생깁니다. 자동화가 잘 돌면 사람이 직접 원인을 파야 하는 사건은 드물어지는데요, 그 드문 사건은 하필 가장 복잡한 사건이고 대응에 주어진 시간은 짧습니다. 훈련을 사건 빈도에 맞추면 준비가 안 되는 구조라는 점에서 항공업계와 조건이 같은 것 같습니다.

4. 직접 확인 1: 문서 작성에서도 같은 부채가 쌓였다

여기까지는 원문 요약입니다. 필자가 이 주제를 그냥 넘기지 못한 것은 장애 대응이 아니라 문서 작성에서 정확히 같은 일을 겪었기 때문인데요, 2026년 9월 8일에 개인 블로그 자동화 파이프라인을 점검하다가 확인한 내용입니다.

외부 AI 도구가 만든 기술 분석 문서 한 건을 공식 문서와 로컬 실측으로 하나씩 대조했습니다. 어떤 제품이었는지는 이 글의 논지와 무관하므로 적지 않겠습니다. 문제는 제품이 아니라 그 산출물을 받는 쪽에 검증 층이 없었다는 것이기 때문입니다.

거짓 6건의 성격은 세 종류로 갈렸습니다. 첫째는 존재하지 않는 설정 파일의 세팅 가이드였고, 둘째는 그 환경에서 재현이 불가능한 실험 로그였는데 리눅스 전용 도구의 출력을 macOS 실행 결과로 제시한 형태였습니다. 셋째는 제품 출시 시점이 약 1년 어긋난 서술이었습니다.

읽는 동안에는 이 문서가 이상해 보이지 않았다는 점이 필자에게는 가장 불편한 부분이었습니다. 문장은 매끄럽고 구조는 정연하고 경로와 명령이 구체적이어서 오히려 신뢰가 갔는데요, 틀린 부분을 잡아낸 것은 공식 문서를 열어 항목별로 대조한 다음이었습니다.

5. 직접 확인 2: 검사기는 왜 거짓 6건을 통과시켰을까요?

이 사례에서 진짜 발견은 거짓 6건이 아니라고 생각합니다. 그 문서가 기존 검사 단계를 전부 통과할 수 있는 상태였다는 것이 발견이었습니다.

당시 파이프라인에는 검사 층이 이미 여러 개 있었습니다. 형식 검사와 보안 검사와 SEO 검사가 각각 자기 기준으로 원고를 훑고 통과 여부를 알려 주는데요, 이 층들을 나란히 적어 보고 나서야 무엇이 빠져 있는지가 보였습니다.

세 층은 모두 성실하게 동작했고 자기 임무도 정확히 수행했습니다. 다만 세 층이 공통으로 묻는 것은 글이 규격에 맞는가였고, 글이 사실인가를 묻는 단계는 어디에도 없었습니다. 검사기가 초록불을 켰다는 사실이 내용이 참이라는 뜻으로 읽히기 쉽다는 점에서, 이 구조는 오류를 걸러 내는 대신 오류에 보증서를 붙여 주고 있었던 것 같습니다.

검증 층이 비어 있는데 자동화가 잘 돌고 있다고 믿는 구조는 이번이 처음 겪은 것도 아닙니다. 블로그운영 카테고리에 적어 둔 제 블로그 글 절반 이상이 구글 색인에 없었습니다 에서 다룬 사례도 자동화가 정상 작동한다고 믿고 있었지만 실제로는 글 절반이 색인에서 누락된 상태였습니다. 검증하지 않으면 문제를 감지하지 못한다는 점에서, 이 글의 사실 검사 층 부재와 정확히 같은 구조입니다.

이 지점에서 이해 부채와 연결됩니다. 자동화가 산출물을 계속 만들어 주면 그 산출물을 의심하고 대조하는 능력은 따로 훈련하지 않는 한 자라지 않고, 그 상태에서는 오류가 있어도 감지되지 않습니다. AI SRE 가 장애 원인을 설명해 줄 때 그 설명이 맞는지 판단하는 능력도 정확히 같은 자리에 있는 것 같습니다.

AI 도구에 작업을 맡길 때 생기는 다른 종류의 위험은 Claude Code 프롬프트 인젝션 막는 4가지 에서 따로 정리해 두었는데요, 그 글이 다루는 것이 입력을 오염시키는 공격이라면 이 글이 다루는 것은 출력을 검증하지 않는 습관입니다.

6. 직접 확인 3: 이 글에서 확인 불가로 남긴 것

실패한 검증도 지우지 않고 적어 두겠습니다. 이 글을 쓰면서 확인하고 싶었지만 확인할 수단이 없었던 항목이 세 가지 있습니다.

• AI SRE 도입 조직의 대응 시간 역전이 실제로 관측되었는지는 확인하지 못했습니다. 원문의 세 번째 주장은 위험 서술이고, 필자에게는 이를 검증할 조직 단위 데이터가 없습니다.
• 이해 부채를 수치로 재는 방법도 확인하지 못했습니다. 평균 복구 시간처럼 지표화된 사례를 찾지 못했고, 없는 지표를 만들어 적는 것은 이 글의 규칙에 어긋납니다.
• 필자가 겪은 검증 실패가 다른 환경에서도 같은 비율로 재현되는지는 미확인입니다. 표본은 문서 한 건과 주장 9건이므로 비율을 일반화할 근거가 되지 못합니다.

세 항목을 미확인으로 남기는 편이 그럴듯한 숫자를 적는 것보다 이 글의 논지에 오히려 맞는다고 생각합니다. 검증되지 않은 문장을 검증된 것처럼 적는 습관이 이 글이 지적하는 바로 그 문제이기 때문입니다.

7. AI SRE 를 쓰면서 이해 부채를 줄이는 훈련 설계

원문의 처방은 정기적 실습이고, 필자의 사례가 덧붙이는 처방은 검증 층을 절차로 만드는 것입니다. 두 처방을 합쳐서 AI SRE 를 이미 쓰고 있는 팀이 무엇을 고정할 수 있는지 정리해 보았습니다.

여기서 필자가 가장 저렴하다고 보는 것은 세 번째 진단 대조입니다. 새 훈련 프로그램을 만들지 않아도 되고, 이미 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번 항목에 미확인으로 남겨 두었습니다.

The post [AI Now] AI SRE 도입하면 쌓이는 이해 부채 appeared first on WONIZZ.LOG.