일하는 AI 에이전트, 설계하는 사람

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

저자 : 최윤석
출간 : 한빛미디어, 2026

요즘은 누구나 자기에게 맞는 AI 에이전트를 찾아 각자의 방식으로 일에 들인다. 어떤 팀은 코딩 에이전트로 시작하고, 어떤 팀은 노코드 자동화 도구로 시작한다. 어디를 봐도 정해진 정답은 없고, 저마다 부딪혀 가며 스스로 답을 찾아가는 중이다. 에이전트를 다루는 책도 크게 두 갈래로 나뉜다. 에이전트가 무엇이고 어떻게 돌아가는지를 설명하는 책, 그리고 에이전트로 무엇을 다뤄야 하는지를 이야기하는 책이다. 이번 책은 후자에 가깝다. 개발은 익숙하지만 도입 회의에서 권한이나 승인, 책임 이야기가 나오면 말이 줄어드는 개발자의 눈으로, 조직에서 에이전트를 들여올 때 무엇을 먼저 정해야 하는지 따라가 본다.

에이전트에게 '업무'를 맡기는 방법

저자는 첫머리에서 이 책이 '에이전트를 만드는 방법이 아니라 일을 맡기는 방법'을 다룬다고 밝힌다. 시연을 본 다음 날 책상 앞에서 나오는 질문, 그러니까 어떤 업무부터 맡길지, 어디까지 자율에 두고 어디서 사람이 확인할지, 결과는 무엇으로 검증하고 잘못되면 누가 책임지는지가 책 전체를 끌고 가는 질문이다.

읽으면서 가장 먼저 멈칫했던 건 실패 원인에 대한 진단이었다. 저자는 에이전트 프로젝트가 실패하는 흔한 원인으로 기술 팀이 무엇이 가능한지는 알지만 무엇이 실제로 가치 있는지는 모르는 채 프로젝트를 진행하는 상황을 꼽는다. 고객 문의 메일을 자동으로 분류해 배분하는 시스템을 만들었는데 담당자들이 거의 쓰지 않는 경우가 있고, 더 시급한 문제는 분류 이후 담당자가 어떻게 대응하느냐였다는 예시가 뒤따른다. 도입 회의에서 개발자는 보통 '가능한가'에 답하는 자리에 앉는데, 이 책은 그 시선을 업무와 책임 쪽으로 돌려놓는다. 앞으로는 기능 요구사항을 받아 들기 전에 그 업무를 매일 하는 사람이 실제로 어디서 막혀 있는지부터 물어보려고 한다.

개입 구조와 권한 단계

맡기는 정도와 개입하는 방식을 서로 다른 축으로 나눈 설명은 읽자마자 머릿속이 정리되는 느낌이었다. 업무 하나를 에이전트에게 맡기는 비율이 자율성 단계라면, 결정 하나가 실행될 때 사람이 승인할지, 지켜보다 개입할지, 완전히 맡길지는 개입 구조다. 저자는 '설계의 단위는 업무가 아니라 업무의 조각'이라고 말한다. 같은 고객지원 에이전트 안에서도 문의 분류는 자동으로 두고, 보상이 걸린 답변 초안은 상담사 승인을 받게 하고, 전체 운영은 관리자가 오류율을 보다가 임계값을 넘으면 멈추는 식이다.

업무 조각마다 사람의 승인, 사람의 감독, 완전 자율 중 어느 구조를 고를지에는 판단 순서도 있다. 먼저 법령과 조직 정책, 개인정보, 이의 제기 가능성이라는 관문을 통과해야 하고 그다음 실패의 비용, 되돌릴 수 있는지, 얼마나 빨리 반응해야 하는지, 결과를 검증할 수 있는지를 따진다. '고위험 결과를 어떤 방식으로도 검증할 수 없다면, 그 업무는 자율 실행으로 넘기지 않습니다.' 승인은 자동화의 병목이 아니라 품질을 높이는 장치라는 관점도 이어진다. 환불 5만 원 이하, 구매 후 14일 이내, 이전 환불 이력 없음처럼 기준을 정해 두면 대부분은 자동으로 처리하고 사람은 예외에 집중할 수 있다.

자동 처리와 사람 승인의 경계를 정하는 기준은 권한 설계로 그대로 이어진다. 저자는 권한을 조회, 수정, 삭제·고위험, 최고위험의 네 단계로 나누고 단계마다 사전 검증, 사람 검토, 이중 승인, 만료 정책을 다르게 건다. '자동화되는 것은 사전검증까지입니다. Delete 이상의 작업은 사전검증을 통과하더라도 인간 승인 없이 실행되지 않습니다.' 역할 기반 권한은 개발자에게 익숙하지만 어디부터 사람이 서명해야 하는지를 금액과 대상으로 정하는 일은 정책의 영역이라는 걸 이 표를 보며 새삼 깨달았다. 징계 면담이나 고객 갈등 중재처럼 기술적으로 가능해도 조직적으로 맡기지 않을 일을 미리 정해 두라는 조언도 함께 있다. 그리고 이 모든 설계의 바탕에는 사람이 루프 밖에 있다고 해서 책임 밖에 있는 것은 아니라는 원칙이 깔려 있다. 최종 결정을 내린 사람은 에이전트가 결정했으니 책임이 없다고 말할 수 없고 결정에 이르는 과정도 기록해 두라고 한다.

다음에 설계 문서를 쓸 때는 기능 단위가 아니라 업무 조각 단위로 자동 처리할 곳과 사람이 승인할 곳을 표시해 보고 싶어졌다. 권한 단계 한 열만 더해 두어도 보안팀이나 현업과 나누는 대화가 막연한 우려에서 구체적인 조건으로 바뀔 것 같다.

운영 기록으로 넓히는 위임 범위

개입 구조와 권한을 정했다면 다음은 에이전트의 결과를 믿을 근거를 쌓는 문제다. 저자는 에이전트에 대한 신뢰를 두고 '여기서 신뢰란 인상이 아니라 기록'이라고 말한다. 업무 유형별 오류율과 예외 처리 결과를 재면서 위임 범위를 넓혀 가라는 것이다. 운영에 올리기 전 점검표에는 기능 테스트 말고도 승인을 거부했을 때 워크플로우가 실제로 멈추는지, 담당자가 개입하고 중단하는 방법을 아는지, 장애 연락 체계가 문서로 있는지가 들어 있다. '훌륭한 비상 정지 기능도 사용 방법을 모르면 소용이 없습니다.' 투입도 전체 업무의 10~~20%에서 시작해 50~~70%를 거쳐 넓혀 간다.

품질 지표에서도 저자는 무엇을 측정할지보다 측정 결과를 누가 검토할지를 먼저 묻는다. 누가 성과를 정기적으로 검토하는지, 누가 워크플로우를 고칠 권한을 갖는지 답이 없으면 문제가 쌓여도 아무도 모른다고 한다. 검증 강도도 요청의 위험도에 따라 다르게 걸고 신뢰도가 낮은 결과는 추가 검증을 하거나 에스컬레이션으로 돌린다.

파일럿에서 프로덕션으로 넘어가는 대목은 특히 인상 깊었다. 저자는 중단 기준 없이 몇 달씩 늘어지는 무한 PoC를 경계하며 'PoC 단계에서 실패를 발견하는 것은 큰 성공입니다'라고 말한다. 파일럿 이후에는 기술 성숙도, 운영 준비도, 비즈니스 준비도를 차례로 통과해야 하는데, 가동률과 감사 로그 같은 기술 항목 옆에 사용자 교육, 이해관계자 서명, 별도 예산 같은 항목이 나란히 놓여 있다. 기능은 잘 돌아가는데 왜 출시가 안 되는지에 대한 답이 이 게이트에 있었다.

운영 전 점검표와 전환 게이트는 개발자에게 익숙한 배포 체크리스트에 사람과 조직 항목을 덧붙인 것에 가깝다. 지금 쓰고 있는 릴리스 체크리스트에 승인 거부 테스트나 담당자 교육 여부 같은 항목을 몇 줄 더하는 것부터 해 볼 생각이다.

부서별 역할과 책임

저자는 부서별 역할을 RACI 표 한 장으로 정리한다. 요구사항 정의의 실행과 최종 책임은 현업에 있고 IT와 보안은 그 자리에서 자문 역할이다. 반대로 기술 평가와 보안 검토, 모델과 도구 정책, 운영 모니터링에서는 IT와 보안이 책임을 진다. 법무는 개발이 한참 진행된 뒤가 아니라 킥오프부터 들어와야 하고 에이전트의 신원도 사람 직원과 같은 체계로 등록하고 폐기하라고 한다. 통제만 강조하지도 않는다. 'IT 승인 절차가 너무 느리면 현업이 외부 AI 도구를 개인 계정으로 사용하는 섀도 AI 현상이 발생'한다는 경고처럼 통제와 속도를 같이 설계하라는 쪽이다.

업무 사례는 고객지원, 문서와 지식, 내부 운영, 전자상거래, 연구와 분석과 코딩 다섯 영역을 같은 틀로 보여 준다. 영역마다 에이전트가 맡는 일과 사람이 남는 자리, 처음 시도하기에 알맞은지를 함께 적어 두었다. 개발자에게 가장 가까운 코딩 사례에는 '에이전트가 생성하고 개발자가 승인한 코드의 책임은 개발자에게 있다는 원칙을 팀 정책으로 명시해야 합니다'라는 문장이 있다. 도입 뒤 가장 자주 보고되는 문제로 리뷰 부담이 시니어에게 몰려 효과가 개인 생산성에만 머무는 상황도 함께 짚는다.

부서별 역할을 나눈 RACI 표를 우리 팀 기준으로 한 번 채워 볼 참이다. 그러면 개발자가 결정해야 하는 자리와 자문만 하면 되는 자리가 나뉠 것 같다. 도입 회의에서 모든 질문에 혼자 답하려 애쓰기보다 요구사항은 현업에, 법적 판단은 법무에 맡기고 기술 평가와 권한 설계에 집중하면 된다는 점이 오히려 마음을 가볍게 해 줬다.

코파일럿형 도입과 일곱 가지 질문

저자는 앞으로 완전 자율 에이전트보다 사람 옆에서 돕는 코파일럿형 도입이 훨씬 빠르게 퍼진다고 본다. 도입 저항이 낮고, 책임 구조가 분명하고, 성과를 기존 지표로 바로 잴 수 있고, 신뢰를 조금씩 쌓을 수 있어서다. 전면 자율이 더딘 이유도 기술 성숙도만이 아니라 규제, 사고 대응 체계, 노동 관계 같은 구조적 제약에 있다고 본다. 에이전트가 잘못 실행했을 때 누가 언제 알아차리고 어떻게 되돌리며 피해를 어떻게 줄일지 미리 정해 두지 않으면, 자율의 수준을 올릴수록 위험도 같이 커진다는 것이다.

책은 일곱 가지 질문으로 끝난다. 해결하려는 업무 문제를 구체적으로 정의했는지, 에이전트의 범위와 역할 경계를 정했는지, 안전장치와 성공 지표를 도입 전에 마련했는지, 팀과 조직의 거버넌스 체계를 정의했는지 같은 질문이다. 저자는 'AI 에이전트를 가장 잘 활용하는 사람은 코드를 제일 잘 짜는 사람이 아닙니다'라고 덧붙인다. 개발자로서 조금 뜨끔했지만 책을 덮고 나서도 가장 오래 남은 문장이었다.

깊이 파고드는 기술서는 아니다. 대신 표마다 바로 들고 갈 수 있는 기준이 정리되어 있어서 거버넌스를 따로 공부해 본 적 없는 개발자에게 조직 도입의 길라잡이로 쓰기 좋다. 에이전트 도입 논의에 불려 가기 시작한 중간 연차 개발자에게 권한다.