Lisanne Bainbridge의 「The ironies of automation」 2장을 바탕으로, LLM/에이전트 기반 사무직 자동화에서의 UI/UX 문제, 훈련 역설, 그리고 에이전트 리더십 딜레마를 살펴본다.
URL: https://www.ufried.com/blog/ironies_of_ai_2/
이전 글에서는 Lisanne Bainbridge가 1983년에 발표해 큰 주목을 받은 논문 “The ironies of automation”에서 제시한 여러 관찰과, 그것들이 오늘날 LLM과 LLM 기반 AI 에이전트를 활용해 “화이트칼라” 업무를 자동화하려는 시도(여전히 인간이 루프 안에 있어야 하는 시도)에 무엇을 의미하는지 논의했습니다. 우리는 논문의 첫 번째 장인 “Introduction(서론)”의 끝에서 멈췄습니다.
이번 글에서는 두 번째 장인 “Approaches to solutions(해결책에 대한 접근)”을 계속 다루며, 거기서 무엇을 배울 수 있는지 살펴보겠습니다.
하지만 시작하기 전에: 논문에서 제시된 일부 관찰과 권고는 오늘날의 AI 기반 자동화 시도에 적용할 때는 어느 정도 “감안(약간의 소금)”이 필요합니다. 산업 생산 설비를 모니터링할 때는, 무언가 잘못되면 심각하거나 심지어 재앙적인 사고를 막기 위해 사람이 몇 초 안에 조치해야 하는 경우가 자주 있습니다.
따라서 산업 제어 스테이션은 인간 운영자가 이상 징후와 오작동을 가능한 한 쉽게 알아차리고 즉시 대응 조치를 시작할 수 있도록 설계하는 것이 최우선입니다. 잘 알려진 비상 정지 스위치처럼, 눈에 띄는 새빨간 색에 큰 크기로 만들어 손바닥이나 주먹으로도 찰나에 눌러(치듯이) 작동시킬 수 있게 하는 등, 각종 디스플레이와 제어 장치의 설계에 많은 노력이 들어갑니다.
화이트칼라 업무를 자동화하는 AI 기반 솔루션에서는 보통 이런 극단적으로 치명적인 조건을 마주하지는 않습니다. 하지만 그렇다고 논문의 관찰과 권고를 쉽게 치부할 수는 없습니다. 예를 들어:
이 점들(그리고 여기 적지 않았지만 여러분이 머릿속으로 더할 다른 요소들)을 곱씹어 보면, AI 관련 자동화 맥락에서도 인간이 종종 빠르게 결정을 내려야 하고, 대개는 심층 분석을 하기 어렵게 만드는 조건에서 그렇게 해야 한다는 결론에 금방 이르게 됩니다.
또한 상황에 따라 AI 솔루션이 낸 잘못된 결과가 인간 운영자의 눈을 피해버렸을 때 최악의 경우 심각한 결과(예: AI 솔루션의 잘못을 놓쳐 대형 보안 사고가 발생하는 상황)를 초래할 수 있다는 점까지 고려하면, 이 상황은 산업 플랜트의 제어 스테이션 상황과 아주 멀지 않습니다.
요약하면, 필요한 “약간의 소금”은 반드시 더해야 합니다. 즉, 최악의 경우 사과와 오렌지를 비교하는 오류를 피하려면 우리 설정에서 시간 제약이 얼마나 엄격한지 스스로 물어야 합니다. 하지만 일반적으로는 가능한 설정의 전체 범위를 고려해야 하고, 그 범위에는—아마 생각보다 더 자주—인간이 스트레스 상황에서 아주 짧은 시간 안에 결정을 내려야 하는 경우가 포함될 것입니다(그래서 더 위태롭습니다).
이는 Lisanne Bainbridge의 첫 번째 권고로 곧바로 이어집니다:
낮은 확률의 사건을 빠르게 알아차려야 하는 어떤 상황에서도, 운영자에게 인공적인 보조가 제공되어야 하며, 필요하다면 경보 위에 경보(alarms on alarms)까지 제공해야 한다.
즉, 시스템은 인간 운영자가 문제를 가능한 한 잘 감지하도록 최대한 지원해야 하며, 특히 문제가 드물게 발생하는 경향이 있다면 더 그렇습니다. 이는 이전 글에서 논의한 “모니터링 피로(monitoring fatigue)” 문제의 결과이기도 합니다.
이러한 교훈 덕분에, 산업 생산 제어 스테이션의 디스플레이·제어장치·경보 메커니즘의 설계에는 많은 노력이 들어갔고, 인간 운영자가 가능한 한 잘, 스트레스 없이, 신뢰성 있게 일을 할 수 있도록 해왔습니다.
AI 에이전트를 들여다봅시다.
일반적인 발상은 한 사람이 여러 AI 에이전트로 구성된 ‘플릿(fleet)’을 통제한다는 것입니다. 이 에이전트들은 예컨대 코드 작성 같은 작업을 수행하도록 설계됩니다. 때로는 대부분의 에이전트가 범용 “워커(worker)”이고, 어떤 감독자(supervisor)가 일을 쪼개 워커 에이전트에 위임해 조율합니다. 때로는 각 에이전트가 특정 측면을 담당하는 “전문가(specialist)”이고, 일종의 코레오그래피로 협업하거나(혹은 감독자가 역시 오케스트레이션합니다) 함께 일합니다. 범용 워커는 설정이 쉽지만, 전문 워커는 대개 더 정확한 결과를 냅니다.
이런 AI 기반 에이전트는 때때로 오류를 내기 때문에, 인간—우리 예에서는 소프트웨어 개발자—이 에이전트 플릿을 감독하고, 가능하면 에이전트가 하면 안 되는 일을 하기 전에 개입해야 합니다. 그래서 에이전트는 보통 먼저 자신들이 하려는 일을 계획(plan)으로 제시합니다(부수 효과로 이탈 가능성도 줄여줍니다). 그 다음 인간이 계획을 검토해 맞으면 승인하고, 에이전트가 계획을 실행합니다. 계획이 틀리면 인간이 거부하고 재계획을 지시하며, 무엇을 바꿔야 하는지 정보를 제공합니다.
이제 Lisanne Bainbridge의 권고를 이 ‘현재의 모범 사례’(AI 에이전트 플릿 통제 방식)와 비교해 봅시다.
우리가 특별히 다르게 행동하라고 지시하지 않는 한, LLM과 LLM 기반 AI 에이전트는 수다스럽습니다. 게다가 그들은 흔히 확신에 찬 태도로 말합니다. 그래서 당신에게 매우 상세한, 여러 단계짜리 계획을—많은 설명을 곁들여—완전히 확신하는 톤으로 제시합니다. 이런 계획은 종종 50~100줄을 넘고, 때로는 수백 줄이 되기도 합니다.
대부분은 괜찮습니다. 하지만 가끔 AI 에이전트가 일을 망칩니다. 잘못된 결론을 내리거나, 지시받은 내용을 잊고 이탈합니다—자주 일어나는 건 아니지만, 일어납니다. 때로는 문제가 한눈에 보이기도 합니다. 하지만 더 흔한 경우는 123번째 줄 어딘가에 교묘히 숨습니다. “... 그리고 2가 3보다 크므로, 우리는 <중대한 무언가>를 해야 한다는 것이 분명하다” 같은 식으로요. 그런데 에이전트가 늘 쏟아내는 텍스트가 너무 많고, 오류는 그 ‘확신의 벽’ 뒤에 너무 잘 숨겨져 있어서 우리는 놓칩니다. 그리고 에이전트는 중대한 실수를 저지릅니다.
계획에서 그 오류를 놓친 사람을 탓할 수는 없습니다. 문제는, 오류를 거의 내지 않는 시스템에서 오류를 막아야 하는 책임이 있는 사람에게 이것이 아마 가능한 한 최악의 UI/UX라는 점입니다.
“하지만 LLM 기반 에이전트는 항상 오류를 내잖아요?”라고 말할지도 모릅니다. 음, 항상은 아닙니다. 가끔 그렇습니다. 그리고 지시와 에이전트 상호작용의 설정이 좋을수록 오류는 줄어듭니다. 또한 미래에는 더 전문적이고 더 정제된 에이전트가 각자의 전문 영역에서 점점 더 좋아질 것도 기대할 수 있습니다. 그렇더라도, 일관된 정합성을 보장할 수 없는 기반 기술 때문에 완전히 무오류가 되지는 못할 가능성이 큽니다.
인간 관찰자를 위한 UI를 논할 때 우리가 곱씹어야 할 설정은 이것입니다. 즉, 에이전트 플릿이 오류를 ‘드물게’ 내지만, 그래도 문제가 생기면 인간이 모니터링하고 개입해야 하는 설정입니다. 그런 인터페이스가 어떻게 생겨야 하는지는 아직 분명치 않지만, 지금 같은 형태여서는 안 된다는 점만은 확실합니다. 아마도 산업 생산 플랜트 제어 스테이션의 UX/UI 설계 동료들로부터 좋은 통찰을 얻을 수 있을 겁니다. 그저 그들에게 물어보기만 하면…
Lisanne Bainbridge는 이어서 인간 운영자에게 필요한 훈련에 관해 여러 권고를 합니다. 이 또한 매우 풍부한 구절들이며, 이 장 전체를 인용하지 않고는 전달하기 어려운 미묘하지만 중요한 힌트들이 여럿 들어 있습니다. 여기서는 몇 가지만 강조하겠습니다. 그녀는 이렇게 시작합니다:
[이전 절에서 말한 몇 가지 점들은] 수동 기술을 유지하는 것이 중요할 수 있음을 분명히 한다.
그리고 인간 운영자가 정기적으로 통제를 인수해, 즉 기계 대신 스스로 일을 하게 하는 것이 매우 효과적인 훈련 옵션이라고 말합니다. 실제로 손으로 직접 하는 일을 정기적으로 하지 않으면, 인간 전문가의 기술은 놀랄 정도로 빠르게 퇴화합니다.
하지만 정기적으로 작업을 인수하는 것이 불가능한 경우도 있습니다. 예컨대 AI 에이전트를 활용해 (말이 되든 안 되든) 지속적으로 초인적 생산성을 원한다면 말이죠. 그렇더라도 필요 시 인간 운영자가 인수할 수 있어야 합니다. 이런 설정에서는 훈련이 다른 방식으로 이루어져야 하는데, 보통은 어떤 형태의 시뮬레이터를 사용합니다.
하지만 시뮬레이터에는 문제가 있습니다. 특히 인간의 개입이 (필요하고 바람직한 상황이) “예상대로 작동하지 않을 때”에만 요구되는 경우에는 더 그렇습니다:
극단적 상황을 대비한 훈련에 어떤 시뮬레이터를 사용하든 문제가 있다. 알려지지 않은 고장은 시뮬레이션할 수 없고, 예측은 가능하지만 경험해보지 않은 고장에 대해서는 시스템 행동이 알려져 있지 않을 수 있다.
이 문제의 결과는 다음과 같습니다:
이는 훈련이 특정 반응이 아니라 일반적인 전략에 초점을 맞춰야 함을 의미한다…
하지만:
낯선 사건에 대해 운영자가 운영 절차서만 참고해 반응하리라 기대하는 것은 부적절하다. 절차서는 모든 가능성을 다 다룰 수 없으므로, 운영자는 이를 모니터링하고 빈틈을 메울 것이 기대된다.
그 결과 남는 아이러니는:
그러나 운영자를 ‘지시를 따르도록’ 훈련시켜 놓고, 시스템 안에서는 ‘지능을 제공’하도록 하는 것은 아이러니하다.
이 문제는 앞으로 AI 에이전트와 이를 감독하는 인간에게도 닥칠 것입니다. 감독 전문가들은 상황이 꼬일 때, AI 에이전트가 예상치 못한 방식으로 막힐 때 개입해야 합니다. 이는 정규 업무가 아닙니다. 또한 우리가 AI 에이전트가 겪을 것이라 예상해 훈련을 제공할 수 있는 종류의 문제도 아닐 때가 많습니다. 이런 상황은 ‘예상하지 못한’ 비정상 상황이며, 미래에 AI 에이전트가 더 정교하고 전문화될수록, 인간 개입이 필요한 문제는 점점 더 이런 종류가 될 가능성이 큽니다.
질문은 두 가지입니다:
이 질문들은 일종의 역설을 암시하는 듯하며, 두 질문 모두에 대한 답은 전혀 자명하지 않습니다. 현재는 경험 많은 도메인 전문가가 아직 충분해서 이 질문들이 덜 중요하게 느껴질지도 모릅니다. 그러나 시급해진 뒤에야 이 문제를 다루기 시작한다면, 해결은 더 어려워질 것이고—어쩌면 불가능해질 수도 있습니다.
이 고찰을 Lisanne Bainbridge의 말로 마무리해보면:
아마도 마지막 아이러니는, 수동 개입이 드물게 필요한 가장 성공적인 자동화 시스템이 인간 운영자 훈련에 가장 큰 투자가 필요할 수 있다는 점이다.
즉, 몇몇 인간 전문가를 데려다 그들의 업무를 대신하게 된 에이전트를 감독시키는 것만으로는 충분하지 않습니다. 사람에게 추가 투자를 하지 않으면 안 됩니다. 오히려 지속적으로 훈련해야 하며, 에이전트가 더 좋아질수록 감독자 훈련은 더 비싸질 것입니다. AI 에이전트를 돈 절약 수단으로만 생각하는 의사결정자들이 이 아이러니를 알고 있을지 매우 의문입니다.
이 블로그 시리즈 1부의 시작에서 썼듯이, “The ironies of automation”은 매우 풍부하고 밀도 높은 논문입니다. 우리는 아직 논문의 2장 “Approaches to solutions”의 끝에 있을 뿐이며, 논문은 여기서 2.5페이지 정도 진행된 상태입니다. 결론에 이르기까지 또 한 페이지 분량의 3장 “Human-computer collaboration(인간-컴퓨터 협업)”이 남아 있습니다.
이 3장도 여기서 다룬 초점을 훨씬 넘어서는 유용한 조언을 많이 담고 있지만, 여러분이 직접 읽어보시길 권합니다. 앞에서 말했듯, 이 논문은 시간을 들일 가치가 충분합니다.
하지만 이 짧은 시리즈를 마치기 전에, Lisanne Bainbridge가 논문에서는 다루지 않았던 새로운 종류의 딜레마를 언급하고 싶습니다. 산업 플랜트 자동화와 AI 에이전트 기반 자동화는 상황이 조금 달랐기 때문입니다. 다만 이 주제는 방금 다룬 훈련 역설과 잘 맞물리기에 여기 추가합니다.
문제는, AI 에이전트 플릿이 일하는 것을 그저 모니터링하다가 일이 잘못될 때만 개입하는 것으로는 보통 충분하지 않다는 점입니다(적어도 아직은). 앞서 논의한 모든 것이 여전히 적용되지만, AI 에이전트와의 상호작용에는 추가 요소가 있습니다. 우리는 AI 에이전트에 대해 단지 반응적(reactive)일 수 없습니다. 즉, 그냥 지켜보다가 문제가 생길 때만 개입할 수는 없습니다. 대신 추가로 선제적(proactive)이어야 합니다. 즉, 그들을 _지휘_해야 합니다.
AI 에이전트에게 무엇을 할지, 무엇을 하지 말지, 어떤 덩어리를 선택할지 등을 말해줘야 합니다. 이는 기본적으로 _리더십 역할_입니다. 인간을 이끄는 것은 아니지만, 작업의 성격은 꽤 비슷합니다. 결과에 대한 책임은 당신에게 있고, 방향과 제약을 설정할 수는 있지만 작업을 즉시 직접 통제하지는 않습니다. 에이전트와 소통하며 명령, 피드백, 변경된 명령, 다른 제약 설정 등을 통해 ‘올바른 방향’으로 이끌어 간접적으로 통제할 뿐입니다.
이런 기술은 대부분의 사람에게 자연스럽게 주어지지 않습니다. 보통 시간에 걸쳐 개발해야 합니다. 일반적으로 사람을 리더 역할(다른 인간을 이끄는 역할)에 두기 전에, 성공적으로 이끌기 위해 필요한 기술과 도구를 가르치는 리더십 교육을 많이 받습니다. 대부분의 사람에게 이는 필수입니다. 왜냐하면 명령을 ‘받는 쪽’(가장 일반적인 의미의 “명령”)에서 일해오던 사람은 방향과 제약을 ‘설정하는’ 것에 익숙하지 않기 때문입니다. 이는 완전히 새로운 기술이어서 배워야 합니다.
이는 인간을 이끄는 데만 해당하는 것이 아니라 AI 에이전트를 이끄는 데도 해당합니다. AI 에이전트는 인간이 아니므로 리더십의 디테일은 다르겠지만, 필요한 기본 기술과 도구는 같습니다. 참고로, 이것이 바로 LinkedIn 등에서 에이전틱 AI를 찬양하는 사람들이 매우 자주 (인간) 팀을 이끄는 관리자들인 이유 중 하나입니다. 그들에게 AI 에이전트 플릿을 이끄는 일은 매일 하는 업무와 매우 가까워 자연스럽게 느껴집니다. 하지만 현재 그 실무를 하고 있는 사람들에게는, AI 에이전트 플릿을 이끄는 일이 대개 전혀 자연스럽지 않습니다.
그런데도 저는 누군가가 AI 에이전트 플릿과 함께 ‘혼자 남겨지기’ 전에 어떤 형태의 리더십 교육을 받는 경우를 아직 본 적이 없습니다. 이 문제에 대한 논의도 여전히 거의 보이지 않습니다. 누군가 에이전트를 성공적으로 지휘하는 데 어려움을 겪으면 흔한 반응은 “제대로 안 되면 더 좋은 프롬프트가 필요하다”입니다.
미안하지만 그렇게 간단하지 않습니다. 문제는 몇 개의 프롬프트를 최적화하는 것보다 훨씬 큽니다. 문제의 핵심은, 사람들이 어떤 일을 해내는 방식 자체를 완전히 바꿔야 한다는 점입니다. 직접 수행하는 대신, 간접적으로 수행하는 법을 배워야 합니다. AI 에이전트 집단을 효과적으로 지휘하는 법, 즉 그들을 _리드_하는 법을 배워야 합니다.
이는 앞선 주제의 훈련 아이러니에도 추가로 얹힙니다. 미래에는 AI 에이전트 플릿이 충분히 좋아져서 선제적 작업을 생략하고, 반응적 작업—즉 모니터하고 개입하는 부분—에만 집중할 수 있을지도 모릅니다. 하지만 그때까지는, 인간 감독자에게 에이전트를 효과적으로 이끄는 법을 가르쳐야 합니다.
Lisanne Bainbridge의 “The ironies of automation”에서 제시된 여러 아이러니와 역설, 그리고 그것들이 에이전틱 AI에도 어떻게 적용되는지 논의했습니다. 우리는 ‘잊어버림(unlearning)과 회상(recall) 딜레마’와 그것이 다음 세대 인간 감독자에게 의미하는 바를 살펴봤습니다. 모니터링 피로와 상태(status) 문제를 논의했습니다. 현재 AI 에이전트의 UX/UI 결함과 훈련 역설을 살펴봤습니다. 그리고 마지막으로, Bainbridge가 논문에서는 다루지 않았지만 훈련 역설을 보완하는 ‘리더십 딜레마’를 다뤘습니다.
저는 Lisanne Bainbridge의 결론을 인용하며 마무리하고자 합니다:
[…] 시간 압박 없이 일하는 인간은 인상적인 문제 해결자가 될 수 있다. 남는 어려움은 그들이 시간 압박 아래에서는 덜 효과적이라는 점이다. 나는 이 논문이 자동화가 반드시 어려움을 제거하는 것이 아니라는 아이러니와, 그것들을 해결하려면 고전적 자동화보다 더 큰 기술적 기지가 필요할 수 있다는 가능성을 모두 분명히 했기를 바란다.
저 역시 전적으로 동의합니다.
시간이 지나면 “The ironies of automation”이 AI 에이전트를 통한 자동화에도 얼마나 많이 적용되는지, 그리고 40년 넘게 알려진 통찰을 우리가 무시할 수 없다는 점이 더 분명해질 것입니다. 또한 저는 그 아이러니와 역설을 해결하는 해법이 어떤 모습일지 정말 궁금합니다.
그때까지, 이 글이 여러분에게 생각해볼 거리를 조금이나마 제공했길 바랍니다. 아이러니를 어떻게 다룰지에 대한 좋은 아이디어가 있다면, 커뮤니티에 꼭 공유해 주세요. 우리는 공유와 토론을 통해 가장 잘 배웁니다. 그리고 여러분의 기여가, 여기서 논의한 문제들을 해결하는 한 걸음이 될지도 모릅니다…
