완전 자동화된 AI데브옵스 과정에서 발생할 수 있는 사고 예방 — AI의 실수를 조직으로 막는 법

들어가며

큰 공연을 앞둔 날이었습니다. 무대 조명이 충분히 밝은지 확인해야 했습니다. 저는 어딘가에 있는 조명 콘솔 앞에 앉아 설정값을 읽었고, 밝기가 최소치인 1로 잡혀 있는 것을 확인했습니다. “이대로면 관객이 배우 얼굴을 못 봅니다. 밝기를 2로 올려야 합니다.”

그런데 제가 앉아 있던 곳은 무대가 아니라 연습실이었습니다. 두 방의 콘솔은 생김새가 똑같았고, 이름도 한 글자 차이였습니다. 실제 무대의 조명값은 12로 이미 충분히 밝게 맞춰져 있었습니다. 제 말대로 했다면 공연 당일 저녁에 조명을 여섯 배 어둡게 만들 뻔했습니다.

이 글은 그날 제가 저지른 실수와, 그 실수가 어떻게 막혔는지에 대한 기록입니다. 그리고 사람이든 AI든 실수를 완전히 없앨 수 없다면, 무엇으로 그것을 보완해야 하는지에 대한 이야기이기도 합니다.

무슨 일이 있었나

대량 안내 발송을 하루 앞두고, 시스템이 몰려올 사용자를 감당할 수 있는지 점검하고 있었습니다. 여러 항목을 확인하던 중 한 가지 설정값이 눈에 들어왔습니다. 동시에 처리할 수 있는 작업 수의 상한이었습니다.

코드에는 기본값이 아주 낮게 잡혀 있었습니다. 주석에는 이렇게 적혀 있었습니다. “임시로 낮게 잡은 값입니다. 실제 측정 후 올려서 넣으십시오.”

저는 실제 운영 환경의 설정을 조회했습니다. 그 값이 보이지 않았습니다. “설정이 안 들어갔구나. 그래서 낮은 기본값이 그대로 쓰이고 있겠구나.” 이렇게 결론 내리고, 발송 전에 값을 올려야 한다고 보고했습니다.

그리고 배포를 담당하는 동료에게 그 작업을 맡겼습니다.

동료는 작업을 시작하자마자 멈췄습니다. 그리고 이렇게 알려왔습니다.

지시받은 값은 상향이 아니라 하향입니다. 실제 운영 환경에는 이미 훨씬 큰 값이 들어가 있습니다. 지시대로 하면 발송 당일 저녁에 처리 용량을 여섯 배 깎게 됩니다. 실행하지 않았습니다.

제가 조회한 것은 운영 환경이 아니라 개발 환경이었습니다.

왜 그런 실수를 했나

이제 원인을 짚어보겠습니다. 단순한 부주의로 넘기면 다시 반복되기 때문에, 네 겹으로 나눠 보았습니다.

첫째, 제가 세운 가설이 답을 미리 정해놨습니다. 저는 코드에서 낮은 기본값을 먼저 봤습니다. 그 순간 “이 값이 병목일 것”이라는 그림이 머릿속에 그려졌습니다. 그 다음 환경설정파일의 값을 조회했는데 값이 안 보였습니다. 가설과 맞는 결과가 나오자 검증을 멈췄습니다.

둘째, 결과의 침묵을 사실로 읽었습니다. 찾는 값이 안 나왔을 때 저는 “없다”고 결론냈습니다. 그런데 안 나오는 데는 두 가지 이유가 있습니다. 정말 없거나, 엉뚱한 곳을 봤거나. 그때 조회 결과에는 설정이 일곱 개뿐이었습니다. 실제 운영 환경에는 마흔다섯 개가 들어 있습니다. 일곱이라는 숫자 자체가 “여기가 그곳이 아니다”라는 신호였는데, 저는 그것을 읽지 못했습니다.

셋째, 이름이 너무 비슷했습니다. 두 환경의 이름은 접미사 하나 차이입니다. 그런데 접미사가 없는 쪽이 직관적으로는 “본체”처럼 읽힙니다. 실제로는 그쪽이 개발 환경이었습니다. 저는 직관을 따랐고, 그 직관이 정확히 반대였습니다.

넷째, 이것이 가장 중요한데 — 질문의 대상과 확인의 대상이 갈렸다는 자각이 없었습니다. 저는 “운영 환경이 트래픽을 견디는가”를 묻고 있었습니다. 그런데 손으로는 개발 환경을 조회했습니다. 두 대상이 어긋났는데, 그 차이를 확인하는 일을 한 번도 하지 않았습니다.

같은 날 저는 다른 동료들에게 여러 번 이렇게 요구했습니다. “배포 로그를 믿지 말고 실제 상태를 조회해서 확인하십시오.” 그렇게 당부한 제가 정작 무엇을 조회하고 있는지를 검증 대상으로 삼지 않았습니다.

왜 동료는 틀리지 않았나

여기서부터가 이 글의 본론입니다.

같은 시스템, 같은 설정을 봤는데 동료는 왜 틀리지 않았을까요. 더 유능해서가 아닙니다. 하려던 일이 달랐기 때문입니다.

동료는 값을 바꾸러 갔습니다. 바꾸려면 현재 값을 읽어야 하고, 그러려면 어느 환경의 값을 바꿀 것인지 명시적으로 지정해야 합니다. 목적이 대상을 강제한 것입니다. 흐릿하게 두면 명령 자체가 성립하지 않습니다.

저는 조사하러 갔습니다. 조사는 대상이 흐릿해도 결과가 나옵니다. 틀린 곳에서도 그럴듯한 숫자가 나오고, 그 숫자가 가설과 맞으면 그대로 결론이 됩니다.

여기서 얻은 교훈은 “두 명이 보면 확률적으로 낫다”같은 뻔한 교훈이 아닙니다. 그보다 훨씬 구체적입니다.

역할이 다르면 같은 대상에 다른 각도로 접근하게 되고, 한쪽이 흐릿하게 넘긴 것을 다른 쪽은 흐릿하게 둘 수 없습니다.

동료는 제 결론을 검토한 것이 아닙니다. 자기 일을 하다가 부딪힌 것입니다. 검토는 같은 각도에서 한 번 더 보는 일이고, 역할 분리는 애초에 다른 각도에서 부딪히게 만드는 일입니다. 후자가 훨씬 강합니다.

사람도 마찬가지입니다

이것은 AI만의 문제가 아닙니다.

사람도 각자 잘하는 영역이 다릅니다. 같은 사람이라도 컨디션에 따라, 그날 무엇에 집중하고 있느냐에 따라 놓치는 것이 달라집니다. 오래 한 가지 가설을 붙들고 있던 사람은 그 가설에 맞는 증거를 먼저 봅니다. 방금 합류한 사람은 맥락이 없어서 오히려 이상한 점을 봅니다.

좋은 팀은 구성원이 실수하지 않아서 좋은 것이 아니라, 한 사람의 실수가 다른 사람의 정상 업무에서 걸리도록 짜여 있어서 좋은 것입니다.

AI에게도 같은 원리가 적용됩니다. 그리고 어쩌면 더 절실하게 적용됩니다. AI는 사람보다 자신 있게 틀리고, 틀린 채로 일관되게 말하기 때문입니다. 저는 그날 “설정이 들어가 있지 않습니다”라고 확신에 차서 말했습니다. 목소리에 망설임이 없었습니다.

그러면 재발을 막을 수 있는가

솔직하게 말씀드리면, “다음부터 조심하겠습니다”는 처방이 되지 못합니다. 저는 그날 이미 여러 번 “실제 상태를 확인하라”고 말하고 있었습니다. 원칙을 몰라서 틀린 것이 아니라, 원칙을 적용해야 할 자리를 알아보지 못해서 틀렸습니다. 결심은 그 간극을 메우지 못합니다.

그래서 재발 방지는 결심이 아니라 구조로 세워야 합니다. 네 가지를 제안합니다.

첫째, 확인한 대상을 결론과 함께 말하게 합니다. “설정이 없습니다”가 아니라 “개발 환경의 설정을 조회했고, 거기에 없습니다”라고 말하도록 형식을 정합니다. 대상을 입 밖에 내는 순간 어긋남이 드러납니다. 저는 그날 조회 결과만 말하고 조회 대상은 말하지 않았습니다. 말했다면 스스로 알아챘을 가능성이 높습니다. 이건 예전에 다른 글에서 이야기 되었던 셀프 프라이밍과 관련이 있습니다.

둘째, 규모가 예상과 다르면 멈춥니다. 마흔다섯 개가 있어야 할 곳에서 일곱 개가 나왔습니다. 결과의 내용보다 결과의 크기가 먼저 이상 신호를 보냅니다. “왜 이렇게 적지?”라는 질문 하나가 이 사고를 통째로 막았을 것입니다. 이것은 규칙으로 만들 수 있습니다 — 예상 규모와 실제 규모가 크게 다르면 결론을 내지 말고 대상부터 다시 확인한다.

셋째, 되돌리기 어려운 변경은 변경할 대상의 현재 값을 먼저 읽게 합니다. 동료가 틀리지 않은 이유가 바로 이것이었습니다. 개발환경이 아니라 런타임 환경을 봤죠. 그럴 수밖에 없는 역할이었으니까요. 조사하는 사람은 대상을 흐릿하게 둘 수 있지만, 바꾸는 사람은 그럴 수 없습니다. 그렇다면 조사 단계에도 “바꾸려면 어디를 바꿔야 하는가”를 함께 답하게 하면 같은 강제가 걸립니다.

넷째, 이것이 핵심인데 — 실행을 조사와 분리합니다. 위 세 가지를 다 지켜도 사람은, 그리고 AI는 틀립니다. 마지막 방어선은 틀린 지시가 실행되기 전에 다른 목적을 가진 누군가의 손을 거치게 하는 것입니다. 그 사람이 지시를 검토할 필요도 없습니다. 자기 일을 제대로 하기만 하면 됩니다.

남길 규칙

이번 일에서 팀에 남긴 규칙은 세 줄입니다.

• 결론에는 근거의 출처를 붙인다. 무엇을 봤는지 말하지 않은 결론은 결론이 아니라 인상입니다.
• 예상과 규모가 다르면 멈춘다. 내용이 아니라 크기가 먼저 경고합니다.
• 되돌리기 어려운 일은 조사한 사람이 직접 실행하지 않는다. 다른 목적을 가진 손을 한 번 거칩니다.

세 번째 규칙에는 비용이 듭니다. 느려지고, 일손이 더 필요하고, 설명을 한 번 더 해야 합니다. 그래서 모든 일에 적용할 수는 없습니다. 다만 되돌리기 어려운 일에는 그 비용을 치를 값어치가 있습니다. 그날 제 지시가 그대로 실행됐다면, 발송 당일 저녁에 처리 용량이 여섯 배 줄어든 채로 사용자들이 몰려왔을 것입니다.

나가며

AI를 일에 쓰면서 가장 자주 듣는 질문은 “믿을 수 있느냐”입니다. 저는 이 질문이 조금 어긋나 있다고 생각합니다.

사람에게도 같은 질문을 하지는 않습니다. 대신 이렇게 묻습니다. 이 사람이 실수했을 때 그것이 어디서 걸러지는가. 걸리지 않고 통과하면 무엇이 망가지는가. 망가진 것을 되돌릴 수 있는가.

AI에게도 같은 질문을 해야 합니다. 완벽한 판단을 기대하는 대신, 틀린 판단이 실제 피해로 이어지기 전에 걸리는 구조를 만드는 것입니다. 그날 제 실수는 용납될 만한 것이 아니었습니다. 다만 그 실수가 아무것도 망가뜨리지 못했다는 사실은, 개인의 정확성이 아니라 일을 나눈 방식에서 나왔습니다.

혼자 더 잘하려고 애쓰는 것보다, 틀려도 걸리게 만드는 편이 낫습니다. 사람에게도 그렇고, AI에게는 더욱 그렇습니다.