AI 사고는 작은 설계 착각에서 시작된다

제일 먼저 든 생각

AI 도입 실패를 이야기할 때 우리는 자주 “모델이 아직 덜 똑똑해서”라고 말한다. 그런데 이 논문은 조금 다른 방향을 가리킨다. 사고는 거대한 기술 결함에서만 생기지 않는다. 현장의 사람은 정확하고 설명 가능한 도움을 기대했는데, 시스템은 빠르고 단정적인 처리를 주는 식의 작은 어긋남이 누적될 때도 생긴다.

논문이 흥미로운 이유는 직장 AI 사고를 추상적 윤리 담론으로만 다루지 않는다는 점이다. 연구진은 AI Incident Database에서 2013~2025년 사이의 사고 보고를 분석하고, 171개 직무 과업과 12개 산업 부문을 기준으로 AI 시스템의 성향과 노동자가 원했을 성향을 비교했다. 그리고 개발자 선호까지 별도로 물어, “누구의 필요가 설계에 들어갔는가”를 묻는다.

직장 AI 사고를 성능 문제가 아니라 과업-사람-설계의 어긋남으로 읽는 연구 구조.

빠른 AI가 늘 좋은 AI는 아니다

논문이 잡아낸 핵심은 worker-AI misalignment, 즉 노동자가 과업 수행에 필요하다고 느끼는 AI 성향과 실제 시스템 성향의 불일치다. 연구진은 많은 사건에서 노동자가 원한 것은 정밀함(precise), 통찰력(insightful), 개인화(personalised)에 가까웠지만, 실제 시스템은 기본적(basic), 단순한(simple), 일반화된(generalised) 방식으로 작동했다고 정리한다.

“직장 AI 사고의 최대 83%가 노동자와 AI 사이의 어긋남에서 비롯된 것으로 나타났다.”
“We found that as many as 83% of workplace incidents stem from worker-AI misalignments.”

이 문장은 “AI를 더 많이 넣으면 생산성이 오른다”는 단순한 도입 논리를 멈춰 세운다. 같은 자동화라도 과업의 성격에 따라 필요한 성향이 다르다. 법률 리서치에는 실용적이고 정확한 시스템이 필요하고, 사람을 평가하거나 해고와 연결되는 HR 과업에는 빠른 결론보다 설명 가능성과 이의제기 가능성이 필요하다.

개발자의 효율 언어와 현장의 안전 언어

연구진은 197명의 개발자 선호도도 비교했다. 논문은 과업 어긋남의 74%가 개발자 설계 결정과 연결될 수 있다고 조심스럽게 말한다. 여기서 중요한 것은 비난의 방향이 아니다. 개발자가 악의적이었다기보다, 조직의 제품·개발 언어가 “속도, 효율, 자동화 범위” 쪽으로 기울 때 현장의 안전 언어가 빠질 수 있다는 점이다.

논문 속 HR 사례가 특히 걸렸다. HR 노동자는 채용·근태·고용 관련 판단에서 설명 가능하고 열린 시스템을 원했지만, 사고 사례의 시스템은 빠르고 단정적인 방식으로 작동했다. 논문은 아마존 플렉스 운전자 해고 사례를 예로 들며, 알고리즘이 교통·날씨·경로 복잡도 같은 맥락을 충분히 반영하지 못한 채 성과 패턴을 빠르게 판정했다고 설명한다.

“HR 노동자들은 이 과업에서 설명 가능하고 열린 시스템이 필요하다고 보았지만, 사고 사례의 AI 시스템은 그 반대인 빠르고 단정적인 방식으로 설계되어 있었다.”
“HR workers indicated that … they need the system to be explainable and open. Yet … AI systems were designed to be the opposite: fast … and definitive.”

이 대목은 조직 AI 도입 체크리스트에 바로 들어갈 만하다. “이 과업은 자동화 가능한가?”보다 먼저 물어야 할 질문은 “이 과업에서 빠른 결론이 위험해지는 지점은 어디인가?”다.

원문 첫 페이지. 연구는 AI 사고 보고, 노동자 선호, 개발자 선호를 함께 비교한다.

업무에 붙이면: AI 기능표보다 과업 성향표

이 논문을 Deciflow식 작업 메모로 가져오면, AI 도입 검토표를 기능 중심에서 과업 성향 중심으로 바꿔볼 수 있다.

• 이 과업에서 사람은 AI에게 빠름을 원하는가, 정확함을 원하는가?
• 단정적 추천이 필요한가, 여러 가능성을 열어두는 보조가 필요한가?
• 자동화 결과가 사람의 기회·평판·고용에 영향을 주는가?
• 오류가 나면 누가 바로잡을 수 있고, 그 사람에게 근거가 보이는가?

특히 HR, 평가, 성과관리처럼 사람에게 영향을 주는 과업에서는 “처리시간 단축”을 성공지표로 먼저 놓으면 위험하다. 이 논문이 보여준 것은, 적어도 분석된 사고 데이터 안에서는 빠르고 단정적인 AI가 현장의 필요와 어긋날 때 사건으로 이어질 수 있다는 점이다.

오늘 남길 질문

새 AI 도구를 붙이기 전에 기능 요구사항 문서 옆에 한 장을 더 만들자. 이름은 거창하지 않아도 된다. 과업 성향표면 충분하다. 이 과업의 AI는 빠라야 하는가, 설명 가능해야 하는가, 보수적이어야 하는가, 창의적이어야 하는가. 그리고 개발자·관리자·실사용자가 같은 칸에 같은 표시를 하는지 확인해보자.

원문 정보

• 제목: The Quiet Path from Seemingly Minor Design Errors to Workplace AI Incidents
• 저자: Julia De Miguel Velázquez, Sanja Šćepanović, Andrés Gvirtz, Daniele Quercia
• 출처: ACM FAccT 2026 / arXiv
• DOI: 10.1145/3805689.3812396
• arXiv: 2605.21035v1

원문 논문: The Quiet Path from Seemingly Minor Design Errors to Workplace AI Incidents