AI로 만든 화면에 사고가 나면 누구 책임일까요?

AI로 만든 화면에 사고가 나면 누구 책임일까요? 결론부터 말하면, AI 때문에 경계가 흐려진 팀일수록 일 하나마다 최종 책임자 한 명의 이름을 먼저 적어 두는 것이 가장 값싼 처방 중 하나라고 생각합니다.

예를 들어 PM이 AI 도구로 결제 화면을 직접 만들었고, 개발자가 겉으로 보기에 문제없다고 넘겼고, 디자이너가 화면을 확인했다고 해 봅시다. 나중에 다른 사용자의 주문 내역이 보이는 문제가 나오면 세 사람은 각자 “내가 본 부분은 괜찮았다”고 말할 수 있습니다. 물론 가상의 상황입니다. 그런데 이 장면이 낯설지 않다면 팀에 이미 같은 구멍이 있다는 뜻입니다.

요즘 이런 일이 늘 거라는 이야기가 여기저기서 보입니다. 모던그로스스택이라는 행사 후기 기사에는 직무의 경계가 없어지거나 희미해진다는 기조연설 대목이 나옵니다. 여러 AI 에이전트가 분석과 실행을 맡고 사람은 결과를 보고 최종 의사결정만 내리게 될 거라는 얘기입니다. 실행이 흩어질수록 사람에게 남는 일은 “마지막 판단”입니다. 그렇다면 그 마지막 판단을 누가 하는지가 분명해야 합니다.

경계는 사라지는 게 아니라 다시 그어진다는 글도 있습니다. yceffort라는 개발자의 블로그 글인데, 경계는 도구가 만든 칸막이였을 뿐이고 누가 만들 수 있느냐와 무엇이 맞느냐를 판단하는 것은 다른 문제라는 얘기입니다. 여기에 책임을 얹으면 이야기가 선명해집니다. 만드는 일은 누구나 하기 쉬워졌지만, 맞다고 말하는 일에는 여전히 이름이 필요합니다.

바이브 코딩의 위험을 다룬 IT 매체 기사도 그 차이를 보여 줍니다. 치명적인 취약점은 API 인가 로직과 비즈니스 로직에서 나왔고, SQL 인젝션 같은 오랜 결함은 오히려 잘 피했다는 내용입니다. 화면과 코드는 그럴듯하게 나오는데, “이 사용자가 이 데이터를 봐도 되는가” 같은 우리 서비스의 규칙은 그럴듯한 코드만으로는 맞는지 알 수 없는 영역 같습니다. 그러면 만든 사람과 책임지는 사람이 갈라지기 쉽습니다. AI가 만들었든 PM이 만들었든, 그 규칙이 맞다고 판단해 내보낸 사람이 따로 있어야 합니다.

오히려 위험한 쪽은 모두가 일부씩 보는 구조라고 생각합니다. 셋이 봤으니 안전하다는 느낌은 사고가 나는 순간 셋 다 조금씩만 책임이 있다는 말로 바뀌고, 그러면 아무도 고치는 결정을 내리지 않기 쉽습니다. 필요한 것은 더 많은 회의가 아니라 마지막 판단의 주인입니다.

방법은 오래전부터 있었습니다. 프로젝트 관리에서 쓰는 RACI 표의 A(Accountable, 최종 책임자)는 업무별로 반드시 한 명만 지정하라고 합니다. 애플은 회의 액션 목록의 항목마다 옆에 DRI(Directly Responsible Individual, 직접 책임자)를 적는다고 알려져 있습니다. 이름은 이 두 곳에서 같은 자리에 놓입니다. 일이 하나 생기면 그 옆에 사람 한 명.

여기서 조심할 점이 있습니다. 팀이나 직무는 이름이 아닙니다. “개발팀”, “기획”이라고 적는 순간 다시 빈칸이 됩니다. 한 명이라는 말은 혼자 일하라는 뜻이 아닙니다. 함께 만드는 사람은 여럿이어도 마지막에 맞다 틀리다를 말하고, 틀렸을 때 되돌릴지 정하는 사람만 한 명이면 됩니다. 그리고 그 사람은 만든 사람일 필요가 없습니다. 오히려 만든 사람이 AI일 때 이 원칙이 가장 필요합니다.

이번 주에 진행 중인 일 하나만 골라 보시기 바랍니다. 그 일이 잘못됐을 때 최종 책임자의 이름을 지금 바로 적을 수 있나요? 두 명이 떠오르거나 아무도 떠오르지 않는다면, 경계가 흐려지는 자리에서 가장 먼저 채워야 할 빈칸을 찾은 것입니다.

경계는 흐려져도 이름은 또렷해야 합니다. 책임의 범위를 어떻게 나누는지가 더 궁금하시다면 PM과 PL 차이는 뭘까요?에서 PM과 PL의 책임 범위 차이를 함께 살펴보세요.