AI 자동화가 사고 대응을 어떻게 바꿀지, 인간과의 협력적 에이전트 설계로 위험을 최소화하는 방식을 탐구합니다.
저희는 AI를 활용해 사고 대응자와 협력적으로 작동하는 에이전트성(agency를 지닌) 제품을 만들고 있습니다. 이를 통해 사고 조사 과정이 개선되고, 사고 해결이 더 빨라집니다. “에이전트성”이라는 단어를 이렇게 초반에 쓰게 될 줄 저도 놀랍지만, 다시는 안 쓸 테니 양해 바랍니다.
6개월간 이 주제에 깊이 파고들며 확신이 들었습니다: 사고 대응에서 AI는 도움이 되는 수준을 넘어서 필수가 될 것입니다. 앞으로 점점 더 많은 소프트웨어가 AI와 함께, 그리고 종국엔 AI에 의해 만들어질 것이고, 이에 따라 대응자는 정보와 맥락을 덜 알게 됩니다. 시스템 이해도가 줄고, 소프트웨어의 양은 계속 늘어납니다. 그럴수록 도움을 줄 수 있는 도구의 필요성은 커집니다.
이 방식을 제대로 적용하면 얻을 수 있는 이익도 큽니다. 사고 조치 시간 단축, 고객 영향 최소화, 담당자들의 인지적 부담 감소 등입니다.
하지만 자동화가 늘어나면서 새로운 위험도 생겨납니다. 이 위험의 대부분은 Lisanne Bainbridge의 1983년 논문 자동화의 아이러니(Ironies of Automation)에 잘 나와 있습니다. 해당 논문에서는 도움이 되라고 만든 자동화가 오히려 상황을 더 복잡하게 만들 수 있다고 지적합니다. 반복적인 일이 자동화될수록 인간의 실무 역량은 경험 부족으로 점점 줄어들고, 결국 시스템이 실패(언젠간 반드시!)할 때, 대응자는 준비와 맥락 모두 부족한 상태로 남겨지게 됩니다.
테크 회사에서 일하며 이런 위험이 심각하게 구현되는 것을 아직 본 적은 없지만, 분명한 진실이 담겨 있습니다. 예를 들어, Kubernetes 사고 사례 중에 오퍼레이터들이 무슨 일이 일어나는지도 모르는 경우를 생각하면 금방 감이 옵니다.
✈️ 자동화의 치명적인 부정 효과
2009년, 에어프랑스 447편 항공기는 심한 폭풍우에서 오토파일럿이 해제되자 대서양에 추락했습니다. 평소 자동화에 의존해 비행하던 조종사들은 갑자기 쏟아지는 낯선 경고와 데이터를 제대로 해석하지 못했습니다. 자동화에 의존하면서 수동 조종 기술과 진단 역량이 약화된 것이 비극적인 사고로 이어졌습니다.
저는 사고 대응이 본질적으로 인간의 영역이라고 생각합니다. 모든 예방적 통제가 무너지고, 정상적 운영에서 완전히 벗어났을 때가 바로 사고입니다. 그래서 자동화가 사고를 대체한다는 것은 이해가 가지 않습니다. 인간과 기계가 협력해 해결로 나가는 것이 유일하게 합리적인 접근입니다.
Bainbridge 논문에서 사고 대응 자동화와 매우 관련 깊은 아이디어 몇 가지를 짚어 봅니다.
먼저 저는 과도하게 자동화된 미래상을 경계합니다. AI가 인간 대응자로부터 중요한 업무와 의사 결정을 아예 가져가려고 하는 것입니다. 이 선은 주관적일 수 있지만 실제 예시를 보면 뚜렷이 구분됩니다.
Bainbridge는 여기 대해 직접적으로 언급합니다. "컴퓨터가 [인간]에게 지시하는 것은 부적절하다. 오퍼레이터가 단순한 중계자(transducer)일 뿐이라면 더욱 그렇다"고 말합니다.
즉, AI가 방향을 제시하고 인간이 그저 따라간다면 인간의 판단·맥락·효과성이 모두 사라질 위험이 있다는 뜻입니다.
✅ 수동적으로 사고를 촉진하다가 사고를 키우는 경우
한 엔지니어가 새벽 3시에 호출을 받습니다. 반쯤 잠든 채로, AI가 문제를 진단하고 "암스테르담의 모든 서버를 재부팅"할 것을 "확인"해 달라는 메시지를 봅니다. 이유는? 최근 소프트웨어 변경이 불안정성을 야기했을 수 있고, 과거에도 비슷한 상황엔 재부팅이 해결책이었기 때문.
자고 싶어서, AI가 자신 있어 하니까 딸깍 "확인".
하지만… 실제 문제는 신규 배포가 아니라, 무해한 로그 폭주였습니다(일시적으로 발생한 기능 플래그 변경 때문). 그 재부팅은 실사용자 트래픽까지 끊고, 지역 전반에 경보를 촉발시킵니다. 사소한 소동이 순식간에 대규모 사고로 번집니다.
AI가 잘못된 판단을 한 것은 아닙니다. 제한된 맥락에서 합리적이었습니다. 반면 당신은 생각 없는 버튼 클릭 머신처럼 행동했습니다—판단력, 맥락, 그리고 본능적 “잠깐만…” 경보 모두 날아가 버린 상황입니다.
약간 과장된 시나리오지만, 자신감 있는 AI와 피곤한 인간이 만나 '실질적으로 판단하지 않고' 단순 승인 버튼만 누르는 사고가 언제든 벌어질 수 있습니다.
AI가 매우 설득력 있는 인간다운 글을 쓸 수 있게 된 시대, 상태 페이지 업데이트나 Slack 메시지 전송을 자동화 시스템에 일임하고 싶을 때가 많습니다. 하지만 뉘앙스, 타이밍, 어조가 중요합니다. 너무 잦은 업데이트는 혼란을 부르고, 너무 적으면 신뢰를 잃습니다. 사고 때의 커뮤니케이션엔 판단과 배려가 필요하며, 여전히 인간의 영역입니다.
📢 선한 의도가 가져온 대형 방송 참사
사고가 발생했습니다. 서비스들은 무너지고, 사람들이 우왕좌왕하는 동안 AI 동반자는 바로 상태 페이지에 글을 올립니다. 수많은 가입자가 메일로 알림을 받도록 설정되어 있습니다.
문제는… AI가 모든 맥락을 다 모르고 있다는 것.
애매한 로그 한 줄을 보고 "데이터 유실"을 언급합니다. 그 다음 3시간 동안엔 사고 해결에 매진하느라 인간들도 잠잠합니다. 고객들, 임원들, 그리고 LinkedIn 반이 회사가 망했다는 둥 카더라에 휩싸입니다.
AI는 기술적으로 "커뮤니케이션"이란 명령을 잘 수행했습니다. 하지만 인간적 판단—무엇을 언제 어떻게, 그리고 무엇은 말하지 않아야 하는지—이 모두 빠지면 곧 평판 재앙으로 번질 수 있습니다.
서비스 자동 재시작이나 트래픽 전환은 SRE의 꿈처럼 들릴 수 있습니다. 하지만 만약 상황이 꼬이면, 자동화된 완화 조치가 원래 문제보다 더 파괴적이 될 수 있습니다. 시스템이 인간만큼 충분한 맥락을 갖추지 않기 전까진, 치명적 액션엔 신중해야 합니다.
🔥 완만한 저하에서 총체적 붕괴로
대시보드 페이지로 트래픽이 급증하고, 백엔드 서비스 CPU 사용률이 빠르게 오릅니다. 하지만 팀은 걱정하지 않습니다. 마케팅 이메일이 발송된 영향이기에 예상된 부하고, 서비스는 우아하게 저하되고 있을 뿐입니다.
AI는 이 맥락을 모르고 서비스를 스케일 업하기로 결정합니다. 도움이 되는 듯하지만, 공유 데이터베이스가 감당 못해 전체 서비스가 다운됩니다. 관리할 수 있는 경고가 한순간 대형 사고로 번진 겁니다.
AI의 판단은 논리적입니다. 그러나 전체 맥락—왜 트래픽이 급증하는지, 서비스의 부하 대처 메커니즘, 공유 인프라 영향 등—을 모른 채 행동하면 사소한 일이 대참사로 이어질 수 있습니다.
간소화된 예시지만, 자동화의 한계와 위험한 오버슈팅이 어떻게 발생하는지 잘 보여줍니다.
Bainbridge 논문은 자동화 설계자가 반드시 고민해야 하는 두 가지 질문을 던집니다:
사고 대응의 효과는 반복, 노출, 경험에서 나옵니다. 인간은 특이하고 놀라운 실패 사례를 접하고, 트레이드오프에 대해 논의하고, 시스템 동작에 대한 심적 모델을 쌓으며 성장합니다. 자동화가 몰래 이 경험을 다 가져가 버리면, 성장과 학습, 호기심의 기회도 사라집니다.
이게 바로 장기적 리스크의 정수입니다: 사고가 "자동화로 처리"되는 미래, 대응자가 소외되고, 현장 노하우가 사라지며, 아무도 이해하지 못하는 기계를 감시하기 싫어지는 시대—그러다 자동화가 고장나면, 그간 실력이 깎이고 사라진 인간 역량에 기댈 수밖에 없습니다. 바로 그게 절체절명의 순간이 됩니다.
다행히도 비관론만 있지 않습니다. 저희는 사고 대응에 AI 자동화의 밝은 미래가 있다고 믿습니다—사실 만들고 있으니 당연하다 할 수 있지만, 정말 그렇게 생각합니다.
저는 성공이 몇 가지 핵심 원칙에 달렸다고 봅니다. 이는 시스템의 기술적 구현뿐 아니라 전반적인 사용자 경험(UX)과도 직결됩니다. 저희 내부적으로도 “업무 대체가 아니라 협력적 에이전트”라는 가치에 단단히 뿌리를 내렸습니다. 저희가 추구하는 분위기는 "모든 사고마다 최고의 엔지니어가 함께하는 것"—여기서 '최고'에는 기술, 사회적 역량 모두를 의미합니다.
여기 제가 생각하는 "좋은 미래"의 방향을 소개합니다.
incident.io는 인간의 핵심 의사결정을 자동화로 대체하지 않습니다. 인간이 중심에 남고 AI는 맥락 지원 역할만 수행하도록 하려는 것이 목표입니다.
구체적으로 "숙련된 인간 동료라면 이 상황에서 뭘 해줄까?"를 늘 자문합니다. 추가 인원 투입에서 그 사람이 주도권을 빼앗아버리는 일은 거의 없습니다. 저희 에이전트도 마찬가지로 작동해야 합니다.
❌ 저는 PR을 되돌리고, 프로덕션에 핫픽스까지 했습니다.
✅ 이 PR(#2709)은 이번 사고 직전에 머지되었고, 오류 처리가 잘못 들어가서 이런 경고가 뜰 수 있습니다.
저희는 복잡성과 추론 근거를 숨기는 블랙박스 자동화를 만들지 않습니다—오히려 반대입니다. 협력적 자동화를 구축하면서 신뢰는 가장 큰 허들이며, 투명함이 그 해법이라고 믿습니다.
인간 동료가 그랬듯, 근거를 이해할 수 있으면 잘못된 선택도 납득이 됩니다. 저희의 에이전트가 결론에 이르면, 무엇을, 왜, 어디서 망설였는지 모두 보여줍니다. “그냥 믿어줘” 같은 느낌은 안 줍니다.
❌ 문제의 원인은 service-X입니다. 클릭으로 팀을 호출하세요.
✅ 이 그래프 상으로 service-X의 에러율이 급증하는데, 로그를 보니 14:23부터 ‘timeout’ 에러가 늘어났고, 이게 config 변경과 일치합니다. 맞게 보인다면 아래 버튼으로 팀을 호출할 수 있습니다.
응답자가 AI가 자신만만하다고 무조건 따르지 않도록, 적극적인 관여를 유도할 것입니다. 의미 있는 결정을 내릴 땐 반드시 인간이 개입하고, 책임도 질 수 있어야 합니다. 언어, UX 설계가 이 부분에서 특히 중요합니다.
저희는 필요한 정보는 분명히 알리되, 대화 흐름을 장악하거나 “유일하게 옳은 답”을 암시하지 않으려 합니다. 그저 신뢰할 만한 가설, 관련 데이터, 탐색할 가치가 있는 방향을 제시할 뿐—사람을 '자동운전' 모드로 몰아서는 안 됩니다.
❌ 이건 PR #456의 회귀(regression)입니다.
✅ 한 가능성으로, PR #456에서 이 부분의 재시도 로직이 바뀌었습니다. 이 연관성도 살펴볼 필요가 있을까요?
인간은 수많은 사고 데이터를 뒤져 패턴을 찾는 데 능하지 않습니다—반면 기계는 탁월하죠. 저희의 목표는 적시에 적절한 맥락을 드러내, 응답자가 실시간으로 심적 모델을 쌓고 다듬도록 돕는 것입니다.
AI가 데이터 추출, 종합, 패턴 탐색을 맡음으로써, 인간은 더 어려운 일(판단, 전략적 사고, “이제 무슨 일이 벌어지지?” 같은 질문)에 집중하게 됩니다. 아이러니하게도 맥락 정보를 더 많이 줄수록 대응자는 더 날카로워집니다.
❌ 이 알림은 과거 12번 발생했습니다.
✅ 이 알림은 지난해 2월, 10월 사고 때 나왔는데, 모두 서비스-X의 큐 백로그와 관련이 있었습니다. 또 발생 중인지 확인해보세요. 자세한 내용은 INC-2412, INC-2508을 참고하세요.
자동화의 아이러니는 인간이 수동적으로 머무를 때 나타납니다. 사고 당시 의미 있는 작업을 자동화가 빼앗는 것이 목표라면, 말씀드린 부작용이 충분히 나올 만합니다. 하지만 저희가 만드는 것은 다릅니다.
저희는 인간이 반드시 깊이 관여하길 바라고 있고, 기계와 함께 맥락을 모으고, 문제를 탐색하며, 가설을 세우고, 합리적 해결책을 찾아가야 한다고 기대합니다. 다소 거창한 주장일 수 있지만, 곧 현실로 구현할 계획입니다.
Bainbridge 논문은 자동화의 치명적 함정을 짚습니다. 저희는 이 내용을 읽고, 논의하며, 실전에서 함정을 피해가고 있습니다.
이 설계를 제대로 이뤄낸다면—그리고 저는 그렇게 확신합니다—저희 제품은 단순히 자동화의 함정을 피하는 데서 끝나지 않고, 인간이 어려움에 부딪힐 때 발휘하는 역량을 증폭시켜, 가장 필요한 순간에 타이밍 좋은 조언, 실질적 가설, 핵심 맥락을 제공해 줄 것입니다.
