AI 에이전트 시대의 사람 역할 설계: 검토자, 승인자, 개선 오너를 나누는 법

1. 개요: AI가 일을 해도 책임은 사라지지 않는다

AI 에이전트 데모는 한 번의 좋은 프롬프트로도 그럴싸하게 만들 수 있습니다. 어려운 부분은 그 다음입니다. 에이전트가 실제 업무 흐름에 들어와 회사 맥락을 읽고, 고객에게 나갈 문장을 만들고, CRM 필드를 바꾸고, 메시지를 보내거나 도구 실행을 요청하는 순간부터 운영 문제가 됩니다.

이때 사람 역할이 흐릿하면 안 됩니다. 모두가 "누군가 확인하겠지"라고 생각하면 품질 경계는 아무도 소유하지 않습니다. 모든 행동이 대표 한 명에게 몰리면 에이전트는 멋진 인터페이스를 가진 대기열이 됩니다. 반대로 검토 없이 행동하게 두면 속도는 생기지만 책임은 사라집니다.

그래서 사람 역할 설계는 기술 문제가 아니라 운영 문제입니다. OpenAI Agents SDK 문서는 사람 승인과 guardrail을 구체적인 워크플로우 장치로 다룹니다. NIST AI RMF도 거버넌스, 위험 식별, 측정, 관리를 강조합니다. 쉽게 말하면, 에이전트가 행동하기 전에 누가 무엇을 책임질지 정해야 합니다.

2. 쉬운 용어 정리: 역할표, 검토자, 승인자, 에스컬레이션

역할표는 AI가 업무에 들어왔을 때 누가 무엇을 하는지 적은 간단한 표입니다. 개발자가 아니라 사업 담당자가 읽을 수 있어야 합니다.

업무 오너는 최종 비즈니스 결과를 책임지는 사람입니다. 환불 업무가 잘못되면 AI가 초안을 썼더라도 운영 수정 책임은 이 사람에게 있습니다.

검토자는 품질을 확인하는 사람입니다. 답변, 출처, 트레이스, 변경 필드, 위험도를 보고 "이 결과가 맞고 충분한가"를 판단합니다.

승인자는 실제 영향을 주는 행동을 허락하는 사람입니다. 이메일 발송, 기록 변경, 환불 처리, 배포, 고객 연락처럼 바깥세상에 영향을 주는 행동을 "지금 해도 되는가" 판단합니다.

• 에스컬레이션: 불확실하거나 위험한 건을 억지로 처리하지 않고 더 높은 책임자에게 올리는 경로.
• 감사 기록: 누가 검토했고, 누가 승인했고, 무엇이 바뀌었고, 왜 바뀌었는지 남기는 기록.
• RACI: responsible, accountable, consulted, informed의 약자입니다. AI 도입에서는 복잡한 의식이 아니라 역할 누락을 막는 체크리스트로 쓰면 됩니다.
• 개선 오너: 반복 실패를 SOP, 프롬프트, 권한, 평가 문제, 학습 예시로 되돌리는 사람.

3. 실패 패턴: 사람이 피곤한 감시자가 되는 순간

첫 번째 나쁜 패턴은 "사람=감시자"입니다. 에이전트가 계속 실행되고, 사람은 대기열을 보며 승인 버튼을 누릅니다. 겉으로는 안전해 보이지만 실제로는 승인 연극이 되기 쉽습니다. 사람이 요약만 보고 승인하며, 에이전트가 무엇을 읽었고 무엇을 바꿀지 inspect할 수 없기 때문입니다.

LangChain과 AI 에이전트 관련 Reddit 논의에서도 같은 운영 문제가 반복됩니다. 승인 버튼 자체가 중요한 것이 아니라, 결정 순간에 행동 내용, 이유, 위험, 영향 받는 기록, 롤백 경로가 보여야 한다는 것입니다. 이는 검증된 통계가 아니라 커뮤니티 신호로만 다루지만, 현장의 고통은 일관됩니다.

두 번째 나쁜 패턴은 "사람=뒤처리 담당자"입니다. 에이전트가 실수하고, 사람이 손으로 고치고, 그 수정이 시스템으로 돌아가지 않습니다. 그러면 AI는 더 빠른 혼란을 만듭니다. 수정은 반드시 SOP나 프롬프트, 권한, 평가 문제로 돌아가야 합니다.

• 약한 검토: "이 고객 답변을 승인할까요?"
• 좋은 검토: "이 고객 답변은 이 세 출처를 근거로 하고, 이 두 필드를 바꾸며, 위험도는 이렇고, 롤백 경로는 이것입니다. 승인할까요?"
• 약한 개선: "다음부터 조심하라고 말한다."
• 좋은 개선: "SOP 규칙 하나, 평가 문제 하나, 권한 경계 하나를 추가한다."

4. 역할 1: 업무 오너

업무 오너는 프롬프트를 쓰는 사람이 아닙니다. 비즈니스 결과를 소유하는 사람입니다. 고객지원이라면 지원 리드, 재무라면 컨트롤러, 영업 운영이라면 CRM 오너일 수 있습니다.

오너는 업무 범위, 허용 가능한 오류 수준, 승인 기준, 롤백 규칙을 정합니다. 이 사람이 없으면 AI 프로젝트는 안전하게 확장할 수 없는 기술 실험이 됩니다.

Guildex식 자동화 진단에서는 첫 번째 필드가 업무 오너입니다. "어떤 에이전트를 쓸까"보다 먼저 "에이전트 도입 후 이 업무를 누가 소유할까"를 물어야 합니다.

• 비즈니스 결과와 품질 목표를 소유합니다.
• 업무 범위와 제외 범위를 정합니다.
• 초안 전용에서 검토 후 행동으로 확장할지 결정합니다.
• 에이전트 품질이 나빠졌을 때 롤백 결정을 소유합니다.

5. 역할 2: 검토자

검토자는 일을 판단할 수 있는 사람입니다. 최종 답변에 도장 찍는 관리자와 다릅니다. 검토자는 에이전트가 어떤 경로로 판단했는지 볼 수 있어야 합니다.

좋은 검토 화면에는 입력, 출처, 도구 호출, 초안, 변경 필드, 신뢰도, 위험 라벨, 비슷한 과거 실패가 보여야 합니다. OpenAI의 tracing과 guardrail 패턴도 같은 방향을 가리킵니다. 검토는 실행 맥락이 보이는 상태에서 이루어져야 합니다.

검토자의 일은 모든 것을 다시 쓰는 것이 아닙니다. 실패를 라벨링하는 것입니다. 출처가 틀렸는가, 톤이 틀렸는가, 정책이 빠졌는가, 도구 호출이 불필요했는가. 이 라벨이 개선 루프로 들어갑니다.

• 검토 항목: 출처 정확도, 정책 적합성, 톤, 빠진 맥락, 변경 필드, 위험도, 트레이스 품질.
• 검토 결과: 승인, 수정 요청, 거절, 에스컬레이션.
• 검토 지표: 사람 수정률, 거절 이유, 검토 시간, 반복 실패 유형.

6. 역할 3: 승인자

승인자는 외부 영향을 책임집니다. 이메일 발송, DB 기록 변경, 환불 처리, 파일 삭제, 코드 배포, 고객 연락은 초안 작성과 다릅니다. 이 행동들은 바깥세상에 흔적을 남깁니다.

OpenAI와 Microsoft의 에이전트 프레임워크 문서 모두 도구 호출 전 사람 승인 패턴을 설명합니다. 실무적으로는 민감한 행동 전에 시스템이 멈추고, 행동을 명확히 보여주고, 사람 결정 후 이어서 실행한다는 뜻입니다.

승인자는 모든 작은 단계를 승인할 필요가 없습니다. 승인은 되돌리기 어렵거나, 고객에게 보이거나, 돈과 법무, 보안, 평판에 영향을 주는 행동에 있어야 합니다.

• 답변 초안 작성: 보통 검토자 게이트.
• 답변 발송: 고객 대면이거나 위험하면 승인자 게이트.
• 환불 메모 작성: 검토자 게이트.
• 환불 실행: 승인자 게이트.
• 낮은 위험의 내부 태그 변경: 충분히 검증되면 자동화 가능.

7. 역할 4: 개선 오너

개선 오너는 가장 자주 빠지는 역할입니다. 이 사람은 사람 검토가 사라지지 않고 누적되게 만듭니다. 이 역할이 없으면 모든 수정은 티켓 하나, Slack 스레드 하나, 한 사람의 기억 안에 갇힙니다.

개선 오너는 SOP, 프롬프트, 권한표, 평가 문제집, 점수표, 실패 분류표를 관리합니다. 같은 오류가 세 번 나오면 에이전트에게 더 조심하라고 말하는 것이 아니라 시스템을 바꿉니다.

x-inbox-router에서 잡힌 OpenHarness, 회사 운영체제, skill, MCP 관련 신호도 같은 교훈을 보여줍니다. 모델은 운영체제의 한 부분일 뿐입니다. 지속되는 가치는 모델 주변의 절차에서 나옵니다.

• 새 실패 사례를 기준 문제집에 추가합니다.
• SOP와 프롬프트 지시문을 이름 있는 변경으로 업데이트합니다.
• 근거에 따라 도구 권한을 좁히거나 넓힙니다.
• 매주 반복 패턴을 업무 오너에게 보고합니다.

8. Guildex 역할표

첫 AI 업무에서는 표를 작게 시작하면 됩니다. 업무 하나에 한 줄이면 충분합니다. 목적은 관료제를 만드는 것이 아니라 책임이 보이지 않게 사라지는 것을 막는 것입니다.

첫 줄에는 업무, 에이전트가 맡는 일, 업무 오너, 검토자, 승인자, 에스컬레이션 담당자, 개선 오너, 승인 기준, 롤백 규칙, 주간 지표를 적습니다.

초기에는 한 사람이 여러 역할을 맡아도 됩니다. 문제는 한 사람이 여러 모자를 쓰는 것이 아닙니다. 그 모자의 이름을 아무도 정하지 않는 것이 문제입니다.

• 고객 답변 초안: 지원 리드가 소유, 선임 지원자가 검토, 위험 발송은 대표가 승인, 운영 담당자가 SOP 개선.
• CRM 업데이트: 영업 운영이 소유, 계정 담당자가 검토, 고가치 계정 변경은 매출 책임자가 승인, 영업 운영이 필드 규칙 개선.
• 내부 리서치 요약: 대표가 소유, 운영자가 검토, 외부 행동으로 이어지지 않으면 승인 불필요.

9. 에이전트 확장 전 체크리스트

AI 에이전트를 초안 전용에서 실제 행동으로 넓히기 전에는 역할 질문에 답해야 합니다. 이 업무는 누가 소유하는가. 누가 품질을 판단할 수 있는가. 누가 되돌리기 어려운 행동을 승인하는가. 누가 에스컬레이션을 받는가. 누가 실패 후 시스템을 업데이트하는가.

이 답이 없다면 다음 단계는 더 큰 모델이 아닙니다. 역할 설계입니다. AI는 업무를 빠르게 만들 수 있지만, 역할 설계가 있어야 업무를 통제할 수 있습니다.

• 모든 업무에는 오너가 하나 있습니다.
• 위험한 출력에는 충분한 맥락을 보는 검토자가 있습니다.
• 영향이 있는 행동에는 승인자와 명확한 행동 요약이 있습니다.
• 모든 승인에는 감사 기록이 남습니다.
• 반복 실패는 SOP, 프롬프트, 권한, 평가 문제 중 하나로 돌아갑니다.