6부 32장. 어디까지 맡기고 어디서 사람 개입이 필요한가

에이전트를 도입하면 곧바로 이런 생각이 든다.

"이왕 하는 김에 자동으로 끝까지 돌리면 더 효율적이지 않을까?"

이 생각은 자연스럽다. 실제로 AI는 초안 작성, 분류, 요약, 비교, 정리 같은 일에서 놀랄 만큼 빠르다. 문제는 그다음이다. 초안을 넘어서 발송까지 맡길 것인가, 정리를 넘어서 의사결정까지 맡길 것인가, 제안을 넘어서 실행까지 허용할 것인가.

여기서 많은 사람이 흔들린다. 너무 겁이 많으면 AI가 가진 효율을 놓치고, 반대로 너무 쉽게 믿으면 작은 실수가 큰 사고가 된다. 그래서 에이전트를 잘 쓰는 핵심은 "무엇을 시킬까"만이 아니라 "어디서 멈추게 할까"를 아는 데 있다.

이번 장에서는 그 경계선을 다룬다. 사람의 검토와 승인이 꼭 필요한 지점, 예외 처리 설계가 필요한 순간, 그리고 마지막 책임이 어디에 남는지를 차근차근 살펴보자.

자동화의 유혹은 왜 강한가

자동화는 보기만 해도 기분이 좋다. 버튼 하나를 누르면 자료를 읽고, 정리하고, 초안을 만들고, 메일까지 보내는 흐름은 마치 일이 저절로 굴러가는 것처럼 보인다.

하지만 실제 업무는 컨베이어벨트 위의 공산품 조립과 다르다. 같은 이름의 작업처럼 보여도, 매번 맥락이 다르고, 예외가 섞이고, 누가 받는지에 따라 결과의 의미가 달라진다. 고객에게 보내는 한 문장, 팀에 공유하는 하나의 숫자, 운영 서버에 반영하는 작은 코드 변경 하나가 생각보다 큰 결과를 만든다.

그래서 자동화의 진짜 적은 기술 부족이 아니라 착시다. "지금까지 몇 번 잘됐으니 앞으로도 괜찮겠지"라는 착시, "형식이 멀쩡하니 내용도 맞겠지"라는 착시, "AI가 추천했으니 합리적이겠지"라는 착시가 위험하다.

잘 쓰는 사람은 자동화를 좋아하지만, 자동화의 환상에는 빠지지 않는다. 속도를 얻는 대신 어디서 사람 손이 들어가야 하는지를 같이 설계한다.

먼저 구분해야 할 세 가지 영역

에이전트에게 일을 맡길 때는 작업을 세 구역으로 나눠 생각하면 편하다.

첫째는 완전 위임이 가능한 영역이다. 실수 비용이 낮고, 결과를 쉽게 되돌릴 수 있으며, 기준이 비교적 분명한 일이다. 예를 들어 회의록 초안 정리, 문서 형식 맞추기, 자료 분류, 코드 설명 붙이기 같은 일은 여기 들어가기 쉽다.

둘째는 승인 후 실행이 필요한 영역이다. AI가 준비하고 제안할 수는 있지만, 마지막 버튼은 사람이 눌러야 하는 일이다. 고객 메일 발송, 보고서 외부 공유, 비용 집행, 운영 서버 반영, 채용 연락 발송 같은 일이 대표적이다.

셋째는 사람 판단이 중심이 되어야 하는 영역이다. 이해관계 충돌이 있거나, 법적·윤리적 책임이 크거나, 애매한 맥락 해석이 중요한 일이다. 해고 결정, 의료 판단, 법률 조언 확정, 성과 평가, 민감한 협상, 중요한 채용 판단은 AI가 보조할 수는 있어도 중심이 되면 곤란하다.

이 세 구역을 구분하지 않으면 모든 일이 하나의 질문으로 바뀐다. "AI를 믿을 수 있나?" 하지만 실전에서 더 정확한 질문은 이것이다.

"이 작업의 어느 단계까지는 믿고 맡길 수 있고, 어느 단계부터는 사람이 잡아야 하는가?"

사람이 꼭 개입해야 하는 첫 번째 지점: 목표를 확정할 때

사람들은 종종 실행 단계만 위험하다고 생각한다. 하지만 실제로 첫 번째 위험 지점은 그보다 앞선 목표 설정이다.

에이전트는 주어진 목표를 따라간다. 문제는 그 목표가 애매하거나 잘못되었을 때도, 꽤 성실하게 따라간다는 점이다. 방향이 잘못된 내비게이션이 열심히 안내할수록 더 멀리 가는 것과 비슷하다.

예를 들어 "고객 문의를 효율적으로 처리해 줘"라는 목표는 얼핏 좋아 보인다. 하지만 효율이 응답 속도를 뜻하는지, 해결률을 뜻하는지, 고객 만족도를 뜻하는지에 따라 행동이 달라진다. "지원 비용을 줄여 줘"라는 말도 마찬가지다. 비용 절감만 좇다 보면 장기 고객 관계를 망칠 수 있다.

그래서 목표는 AI가 정교하게 다듬어야 할 것이 아니라, 사람이 먼저 책임 있게 정의해야 할 대상이다. 특히 다음 질문은 사람이 직접 답해야 한다.

• 무엇을 최우선으로 둘 것인가

• 무엇은 절대 희생하면 안 되는가

• 성공은 어떤 상태를 말하는가

• 실패했을 때 감당 가능한 범위는 어디까지인가

목표가 흔들리면 이후 단계의 자동화는 모두 불안정해진다.

두 번째 지점: 되돌리기 어려운 실행 직전

AI가 무언가를 "생성"하는 것과 "실행"하는 것은 전혀 다르다. 문서 초안을 쓰는 일과 그 문서를 실제로 외부에 보내는 일은 같은 흐름 안에 있어 보여도 위험 수준이 완전히 다르다.

실행 직전에는 사람 개입이 필요한 경우가 많다. 특히 한 번 나가면 되돌리기 어렵거나, 수정 비용이 크거나, 신뢰에 영향을 주는 행동은 더욱 그렇다.

예를 들어 다음과 같은 작업은 승인 단계가 거의 필수에 가깝다.

• 고객이나 외부 파트너에게 메시지를 발송하는 일

• 결제, 환불, 예산 집행처럼 금전이 움직이는 일

• 운영 서버 배포, 데이터 삭제, 계정 권한 변경처럼 시스템 상태를 바꾸는 일

• 지원자 탈락 통보, 인사 평가 공유처럼 관계에 영향을 주는 일

이때 중요한 것은 "사람이 마지막에 본다"는 말만 붙이는 것이 아니다. 무엇을 보고 승인할지까지 정해야 한다. 본문만 훑고 승인할 것인지, 근거 자료와 변경 요약을 같이 볼 것인지, 위험 표시가 뜰 때만 추가 확인할 것인지가 분명해야 한다.

승인이 형식만 남고 실질이 사라지면, 사람은 그냥 도장을 찍는 기계가 된다. 그것은 인간 개입이 아니라 인간 장식이다.

세 번째 지점: 예외가 나타났을 때

자동화는 정상 흐름에서는 멋지다. 하지만 진짜 실력은 예외 상황에서 드러난다.

문제는 예외가 특별한 사건처럼 보이지만, 실제 업무에서는 오히려 자주 일어난다는 점이다. 파일 형식이 다르다, 입력값이 빠졌다, 고객 문의가 두 가지 카테고리에 걸친다, 규정과 현실이 충돌한다, 문서는 있는데 최신본인지 확신이 없다. 이런 일이 계속 나온다.

이럴 때 에이전트가 무리하게 계속 진행하면 위험하다. 모르는 것을 아는 척하고, 애매한 것을 한쪽으로 밀어버리고, 이상한 입력을 정상 데이터처럼 처리할 수 있기 때문이다.

그래서 예외 처리의 기본 원칙은 단순하다. 애매하면 사람에게 올려라.

듣기에는 소극적으로 보이지만, 실제로는 가장 강한 설계다. 에이전트가 모든 문제를 해결하는 것이 목표가 아니라, 위험한 문제를 스스로 만들어내지 않는 것이 더 중요하기 때문이다.

좋은 시스템은 예외를 숨기지 않는다. 오히려 이렇게 말할 수 있어야 한다.

"이 경우는 자신이 낮습니다."

"입력 자료가 서로 충돌합니다."

"정책 해석이 필요해 자동 진행을 멈췄습니다."

이 한마디를 할 줄 아는 에이전트가, 끝까지 우겨서 틀린 결과를 내놓는 에이전트보다 훨씬 실무적이다.

네 번째 지점: 이해관계와 가치 판단이 얽힐 때

AI는 패턴을 잘 본다. 그러나 가치 판단의 책임을 져 주지는 않는다. 이 차이를 놓치면 곤란하다.

예를 들어 채용 서류를 정리하고, 이력서를 요약하고, 인터뷰 질문 초안을 만드는 일은 AI가 잘 도와줄 수 있다. 하지만 최종 합격 판단은 전혀 다른 문제다. 여기에는 단순한 정보 비교를 넘어서 팀 구성, 역할 균형, 잠재력 평가, 편향 점검, 법적 책임 같은 요소가 얽힌다.

성과 평가도 비슷하다. AI는 업무 기록을 정리할 수는 있어도, 누군가의 기여를 최종적으로 평가하는 일은 사람 몫이어야 한다. 왜냐하면 평가는 사실 요약이 아니라 관계와 책임이 걸린 판단이기 때문이다.

이해관계가 얽힌 순간부터는 "정답"보다 "정당한 판단 과정"이 더 중요해진다. 그리고 그 과정은 사람이 책임져야 한다.

다섯 번째 지점: 법적, 윤리적, 평판 리스크가 클 때

어떤 영역은 작은 오류도 크게 번진다. 의료, 법률, 금융, 인사, 개인정보, 보안이 대표적이다. 이런 분야에서는 AI가 유용하더라도, 사람 개입이 기본값이어야 한다.

여기서 중요한 것은 AI가 틀릴 수 있다는 사실만이 아니다. 설령 맞는 말을 했더라도, 그 말의 적용 책임이 크다는 점이다. 예를 들어 법률 문서를 요약하는 일과 법적 자문을 확정하는 일은 다르다. 증상을 정리하는 일과 진료 판단을 내리는 일도 다르다.

AI는 초안을 줄 수 있다. 놓친 항목을 알려 줄 수 있다. 비교를 도와줄 수 있다. 하지만 최종 판단과 서명, 승인, 대외적 책임은 사람이 가져가야 한다.

이 지점에서 자주 생기는 오해가 있다. "어차피 사람도 실수하잖아." 맞는 말이다. 하지만 그래서 책임을 지는 구조가 더 중요해진다. 실수 가능성이 있다는 사실이 사람 개입의 필요를 없애는 것이 아니라, 오히려 책임 체계를 더 분명히 만들게 한다.

사람 개입은 느리게 만드는 것이 아니라 사고를 싸게 막는 것이다

사람이 중간에 확인하면 흐름이 끊긴다고 느끼기 쉽다. 실제로 승인 단계가 많아지면 속도는 떨어질 수 있다. 그러나 속도만 보고 판단하면 안 된다.

실무에서는 "조금 느리지만 안전한 흐름"이 "매우 빠르지만 가끔 크게 망하는 흐름"보다 훨씬 낫다. 특히 대외 발송, 배포, 비용, 권한, 평판이 걸린 일은 더욱 그렇다.

중요한 것은 사람 개입을 무조건 많이 넣는 것이 아니다. 싸게 막을 수 있는 지점에 정확히 넣는 것이다. 예를 들어 배포가 끝난 뒤 장애를 복구하는 것보다, 배포 직전 변경 범위를 확인하는 것이 훨씬 싸다. 고객 불만이 커진 뒤 수습하는 것보다, 발송 전 문구를 한 번 더 보는 편이 훨씬 싸다.

인간 검토는 비효율의 상징이 아니라, 손실을 낮추는 장치다.

승인 단계를 어떻게 설계해야 하는가

사람이 승인해야 한다고 해서, 그냥 "승인 버튼"만 만들면 되는 것은 아니다. 승인 설계가 나쁘면 사람은 빨리 누르는 법만 배우게 된다.

좋은 승인 단계에는 세 가지가 필요하다.

첫째, 무엇이 바뀌는지 요약이 보여야 한다. 긴 문서 전체를 다시 읽게 만들면 승인자는 지친다. 변경점, 핵심 판단, 위험 요소가 먼저 보이도록 해야 한다.

둘째, 근거가 연결되어야 한다. 이 결론이 어떤 자료와 규칙에서 나왔는지 따라갈 수 있어야 한다. 근거가 없으면 사람은 감으로 승인하게 된다.

셋째, 승인하지 않을 선택이 쉬워야 한다. 수정 요청, 보류, 되돌리기, 범위 축소가 어려우면 사람은 웬만하면 통과시킨다. 좋은 시스템은 승인보다 보류가 더 자연스러울 때도 있다.

예를 들어 코드 작업이라면 "어떤 파일이 바뀌었는지, 왜 바뀌었는지, 테스트 결과는 어떤지"가 함께 보여야 한다. 고객 응답이라면 "발송 문안, 참조한 고객 이력, 자신 없는 표현, 민감한 부분 표시"가 함께 보여야 한다. 승인자는 결과만 보는 사람이 아니라, 위험을 줄이는 마지막 필터여야 한다.

예외 처리는 정상 흐름보다 먼저 설계하라

많은 팀이 자동화를 설계할 때 정상 흐름부터 생각한다. 자료가 잘 들어오고, 규칙이 잘 맞고, 출력이 예쁘게 나오는 상황 말이다. 하지만 실제 운영에서 더 중요한 것은 실패 흐름이다.

예외 처리를 설계할 때는 이런 질문이 필요하다.

• 입력이 불완전하면 어떻게 할 것인가

• 서로 다른 자료가 충돌하면 무엇을 우선할 것인가

• 자신감이 낮을 때는 멈출 것인가, 후보안을 낼 것인가

• 정책에 걸릴 수 있는 표현을 감지하면 누구에게 넘길 것인가

• 실행 도중 일부만 성공했을 때 어떻게 복구할 것인가

이 질문에 답이 없다면, 자동화는 평온한 날씨에서만 달리는 자동차와 비슷하다. 맑은 날엔 잘 가지만, 비가 오는 순간 위험해진다.

진짜 실전형 에이전트는 잘할 때보다 흔들릴 때의 행동이 더 잘 설계되어 있다.

책임 경계는 반드시 문장으로 적어야 한다

"AI가 한 일이라 어쩔 수 없었다"는 말은 책임 체계가 아니다. 에이전트는 조직 안에서 쓰이는 도구이고, 도구를 선택하고 연결하고 승인 구조를 만든 쪽이 책임을 가진다.

이 말은 AI 탓을 하지 말라는 도덕 강의가 아니다. 운영 원칙의 문제다. 책임 경계가 흐리면 누구도 위험을 제대로 관리하지 않는다.

책임 경계는 최소한 다음처럼 문장으로 적을 수 있어야 한다.

• AI는 초안 작성과 분류를 담당한다.

• 외부 발송 전 최종 검토 책임은 담당자에게 있다.

• 금전 집행과 권한 변경은 관리자 승인 없이는 실행되지 않는다.

• 정책 해석이 필요한 예외는 운영 책임자에게 자동 이관된다.

• 로그와 변경 이력은 사후 검토를 위해 남긴다.

핵심은 간단하다. AI는 작업을 수행할 수 있어도, 책임의 주체가 되지는 않는다. 책임은 사람과 조직이 가진다.

실전 예시 1: 고객 지원 에이전트

고객 지원은 자동화 유혹이 매우 큰 분야다. 문의를 분류하고, FAQ를 찾아 답변 초안을 만들고, 간단한 환불 정책을 안내하는 일은 AI가 꽤 잘한다.

하지만 모든 문의를 자동 발송으로 연결하는 순간 문제가 생긴다. 예를 들어 감정이 격한 고객, 정책 경계에 있는 환불 요청, 법적 분쟁 가능성이 있는 문의는 일반 답변으로 처리하면 안 된다.

이 경우 좋은 경계선은 이렇다. 단순 문의는 AI가 초안을 만들고 자동 발송할 수 있다. 다만 환불, 약관 해석, 강한 불만, 반복 문의, 계정 보안 관련 요청은 사람 검토 대기열로 보낸다. 즉, AI는 속도를 맡고 사람은 관계와 책임을 맡는다.

실전 예시 2: 코딩 에이전트

코딩 작업에서도 경계는 분명해야 한다. 에이전트가 버그 원인을 찾고 패치를 제안하고 테스트를 실행하는 것까지는 매우 유용하다. 하지만 아무 제한 없이 운영 브랜치에 반영하고 배포까지 하게 하면 이야기가 달라진다.

더 안전한 흐름은 이렇다. AI가 원인 후보를 정리하고 수정안을 만든다. 테스트를 실행해 결과를 요약한다. 사람이 변경 범위와 테스트 결과를 확인한다. 그다음에만 병합이나 배포가 이루어진다.

특히 데이터베이스 마이그레이션, 권한 처리, 결제 로직, 보안 관련 수정은 더 강한 승인 장치가 필요하다. 코드 몇 줄이 아니라 서비스 신뢰 전체가 걸려 있기 때문이다.

실전 예시 3: 개인 비서형 에이전트

개인 생산성 도구는 상대적으로 가볍게 보이지만, 여기에도 사람 개입 지점이 있다. 일정 정리, 메모 분류, 할 일 추천은 자동화하기 좋다. 하지만 누군가와의 약속을 확정하고, 중요한 메시지를 대신 보내고, 민감한 대화를 자동으로 작성해 보내는 것은 다른 문제다.

예를 들어 친구에게 보내는 가벼운 일정 조율 메시지는 자동화가 가능할 수 있다. 하지만 거래처 대표에게 보내는 사과 메일, 채용 후보자에게 보내는 제안 메일, 가족 문제와 관련된 민감한 메시지는 반드시 사람이 직접 읽어야 한다.

같은 "메시지 발송"이라도 관계의 밀도와 위험 수준이 다르기 때문이다.

맡겨도 되는 일과 끝까지 봐야 하는 일을 가르는 기준

실무에서 빠르게 판단하려면 몇 가지 질문이 도움이 된다. 아래 질문에 "예"가 많을수록 더 자동화하기 쉽다.

• 성공 기준이 분명한가

• 입력 자료가 비교적 깨끗한가

• 실수해도 되돌리기 쉬운가

• 외부 신뢰나 법적 책임에 직접 닿지 않는가

• 예외가 생겨도 사람에게 넘기기 쉬운가

• 결과 검토 비용이 낮은가

반대로 아래 질문에 "예"가 많을수록 사람 개입을 강하게 넣어야 한다.

• 애매한 해석이 중요한가

• 이해관계 충돌이 있는가

• 돈, 권한, 법적 책임이 움직이는가

• 잘못되면 평판 손실이 큰가

• 한 번 실행하면 되돌리기 어려운가

• 소수의 예외가 아니라 다양한 예외가 자주 나오는가

이 기준은 거창한 이론이 아니다. 현장에서 사고를 줄이는 매우 현실적인 필터다.

자율성은 신뢰가 아니라 검증된 구조 위에서 늘어난다

에이전트를 몇 번 써 보면 잘할 때가 있다. 그러면 사람은 금세 마음이 커진다. "이 정도면 다음 단계도 맡길 수 있겠는데?" 바로 여기서 조심해야 한다.

자율성은 감탄의 크기만큼 늘리면 안 된다. 검증된 범위만큼 늘려야 한다.

처음에는 읽기와 정리만 맡긴다. 그다음 제안까지 맡긴다. 이후 제한된 실행을 허용한다. 마지막으로 승인 기반 자동화를 붙인다. 이때도 로그, 되돌리기, 예외 이관, 테스트 같은 안전장치가 갖춰져 있어야 한다.

쉽게 말해, "잘하네"가 아니라 "반복해도 안정적이네"가 되어야 권한을 늘릴 수 있다.

결국 사람은 어디에 집중해야 하는가

에이전트 시대에 사람의 역할이 사라지는 것은 아니다. 오히려 더 선명해진다.

사람은 이제 모든 문장을 직접 쓰는 존재에서, 목표를 정하고 경계를 그으며 예외를 판단하고 책임을 지는 존재로 이동한다. 손을 덜 쓰는 대신, 더 중요한 판단을 맡게 된다.

좋은 운영자는 AI보다 빨리 쓰는 사람이 아니다. 어디를 자동화하고 어디를 멈출지 아는 사람이다. 에이전트가 아무리 좋아져도 이 역할은 쉽게 사라지지 않는다. 아니, 오히려 더 중요해진다.

왜냐하면 자동화가 강해질수록, 잘못된 자동화의 피해도 커지기 때문이다.

이 장의 정리

에이전트를 잘 쓰는 핵심은 전부 맡기는 데 있지 않다. 어디까지 맡기고 어디서 사람이 들어와야 하는지 구분하는 데 있다.

목표를 정하는 순간, 되돌리기 어려운 실행 직전, 예외가 발생했을 때, 이해관계와 가치 판단이 얽힐 때, 법적·윤리적 책임이 큰 순간에는 사람 개입이 필요하다. 승인 단계는 형식이 아니라 실질이어야 하고, 예외 처리는 정상 흐름보다 먼저 설계해야 하며, 책임 경계는 반드시 문장으로 적어 둘 수 있어야 한다.

자동화의 유혹은 강하다. 하지만 실전에서 오래 살아남는 시스템은 가장 많이 자동화한 시스템이 아니라, 가장 영리하게 사람을 개입시킨 시스템이다.

다음 부에서는 이제 한 걸음 더 나아가, 이런 경계선 위에서 실제 성과를 만드는 방법을 살펴본다. 프롬프트 하나가 아니라 흐름 전체를 설계하는 워크플로의 관점이 왜 중요한지 본격적으로 들어가 보자.