작성자 주: “데이터를 삭제하거나, 돈을 쓰거나, 방향을 바꿀 때만 사람에게 묻는다”는 원칙을 바탕으로, Agent 자동화 시스템에서 인간의 결정이 필요한 경계를 정하는 3가지 판단 기준과 승인 채널 설계, CI 검증 역할 분담을 살펴봐요.
Agent가 “대화를 나누는 도구”에서 “일을 대신하는 도구”로 바뀌면, 실행 자체보다 언제 멈춰야 하는지 정하는 일이 더 어려워져요. 승인 단계를 너무 많이 두면 자동화가 “사람이 확인 버튼을 누르는 일”로 전락하고, 너무 적게 두면 데이터 오삭제나 통제되지 않은 지출 한 번으로 몇 달간의 효율성 향상이 물거품이 될 수 있어요. 이 글에서는 Agent는 언제 멈춰서 사람에게 물어야 할까라는 질문을 중심으로, 여러 상황에 적용할 수 있는 인간의 결정 경계 설계 방법을 소개해요.
이 글은 “AI는 위험하니 조심해야 한다”는 막연한 이야기가 아니에요. 공개된 실제 시스템에서 출발해요. 콘텐츠 제작자 카즈크는 약 1년에 걸쳐 Agent 자동화 시스템을 구축했고, 데이터 삭제, 지출, 방향 변경이라는 세 가지 핵심 결정에만 Feishu 카드로 승인을 요청해요. 이 원칙을 판단 기준으로 정리하고 승인 채널 설계 방법도 함께 살펴봐요.
이 글에서 얻을 수 있는 것: 어떤 작업을 Agent에 자율적으로 맡기고 어떤 작업은 사람이 확인해야 하는지 판단할 수 있어요. 자동화 흐름을 방해하지 않으면서 위험에도 대비할 수 있는 승인 채널을 설계하는 방법도 알아봐요.
Agent는 언제 작업을 멈추고 사람에게 물어야 할까? 3가지 결정 지점
카즈크의 시스템은 사람의 개입을 세 가지 상황으로 제한해요. 아래 표는 각 결정 지점과 그에 따른 위험을 정리한 것이에요.
| 결정 지점 | 대표적인 작업 | 위험의 본질 | 사람이 필요한 이유 |
|---|---|---|---|
| 데이터 삭제 | 데이터베이스 레코드 정리, 파일 삭제, 이전 버전 덮어쓰기 | 되돌릴 수 없음 | 실행 후 복구 비용이 매우 높거나 복구가 불가능할 수 있어요 |
| 비용 지출 | 유료 서비스 호출, 리소스 구매, 모델 사용량 대량 소진 | 자금 유출 | 실제 비용이 발생하며 반복 실행으로 비용이 커질 수 있어요 |
| 방향 변경 | 콘텐츠 주제 조정, 제품 전략 변경, 기존 규칙 수정 | 목표에 영향 | Agent는 비즈니스 맥락을 충분히 파악하거나 가치 판단을 내리기 어려워요 |
4계층 아키텍처에서 살펴보는 Agent의 인간 의사결정 경계
공개된 요약에 따르면 카즈크의 시스템은 ‘사람이 업무를 시작하는 지점을 없애는 것’을 핵심으로 해요. 사람이 매번 작업을 지시하는 대신, 이벤트가 발생하면 Agent가 일하기 시작하는 방식이에요. 시스템은 총 4개 계층으로 구성되며, 사람의 결정은 맨 마지막 계층에 배치돼 전체 흐름의 ‘가속 페달’이 아닌 ‘브레이크’ 역할을 해요.
| 계층 | 담당 역할 | 공개된 구현 방식 |
|---|---|---|
| 자동화 플랫폼 | 이벤트 트리거와 Agent 스케줄링 통합 관리 | rules.json에서 규칙을 한곳에 설정 |
| Agent 실행 계층 | Agent 작업 실행 | 로컬 Mac Mini에서 실행 |
| CI 플랫폼 | 리뷰, 검사, 병합, 배포, 검증의 5단계 수행 | 자체 구축 |
| 페이슈 의사결정 계층 | 중요한 결정을 사람이 내리도록 요청 | 페이슈 카드 |
이 구조에는 중요한 설계 원칙이 담겨 있어요. 대부분의 ‘올바른가’에 관한 문제는 CI 플랫폼이 자동으로 검증하고, ‘해야 하는가’에 관한 문제만 사람에게 넘기는 거예요. 전자는 객관적인 기준으로 확인할 수 있지만, 후자는 선택과 책임이 따르기 때문이에요. 이것이 인간 의사결정 경계를 나누는 핵심 기준이에요.
다만 원본 자료는 요약문에 불과해요. 페이슈 카드의 구체적인 항목, 사람이 결정하는 빈도와 응답 시간, ‘방향 변경’의 정확한 정의는 공개되지 않았어요. 이후에 소개하는 카드 설계와 판단 기준은 이 원칙을 바탕으로 확장한 제안이며, 원래 시스템을 그대로 설명한 내용은 아니에요.
Agent가 언제 멈추고 사람에게 물어야 할까: 세 가지 판단 기준
“데이터 삭제, 비용 지출, 방향 변경”은 좋은 출발점이지만, 실제 시스템에는 이보다 훨씬 다양한 작업이 있어요. 이를 가역성, 비용 영향, 방향성이라는 세 가지 기준으로 정리하면 새로운 작업도 빠르게 분류할 수 있어요.
기준 1: 가역성으로 결과를 되돌릴 수 있는지 판단하기
가역성은 “잘못했을 때 되돌릴 수 있는가”를 따져보는 기준이에요. 초안 작성, 브랜치 생성, 테스트 환경에서 스크립트 실행은 모두 되돌릴 수 있는 작업이에요. 잘못되면 버리고 다시 하면 되죠. 반면 운영 데이터를 삭제하거나, 외부에 이메일을 보내거나, 콘텐츠를 정식으로 발행하는 일은 되돌리기 어렵거나 일부만 되돌릴 수 있어요. 실행하는 것보다 복구하는 데 드는 비용이 훨씬 크죠.
판단이 어렵다면 구체적으로 물어보세요. Agent가 작업 직후 실수를 발견했을 때, 복구하는 데 얼마나 많은 시간과 인력이 필요할까요? 답이 감당할 수 있는 범위를 넘는다면 해당 작업은 승인을 받도록 해야 해요.
기준 2: 비용 영향에 따라 예산 승인 절차가 필요한지 결정해요
비용 영향은 ‘이번에 얼마를 쓰는가’뿐 아니라 ‘비용이 불어날 가능성이 있는가’도 포함해요. Agent의 가장 큰 재정적 위험은 반복 실행에서 발생하는 경우가 많아요. 재시도 로직이 잘못 작성되거나 트리거 조건이 너무 광범위하면 몇 시간 동안 모델 호출이 반복될 수 있어요. 한 번의 비용이 낮더라도 통제할 수 없이 반복되면 감당하기 어려워질 수 있죠.
따라서 예산 임곗값을 설정하는 편이 실용적이에요. 단일 지출과 누적 지출이 임곗값 이내라면 자율적으로 실행하고, 초과하면 멈춰서 사람에게 물어보는 거예요. Agent가 여러 대규모 언어 모델을 호출해야 한다면 APIYI apiyi.com 같은 통합 인터페이스 플랫폼을 이용할 수 있어요. 사용량이 한곳에 집계되므로 여러 업체의 관리 화면을 오가며 확인하지 않아도 누적 비용을 임곗값과 비교하기 편해요.
기준 3: 방향성에 따라 목표의 책임 주체를 결정해요
방향성은 세 가지 기준 중 가장 모호해요. 해당 작업이 ‘우리가 어디로 향하는가’를 바꾸는지를 뜻해요. 예를 들어 콘텐츠 주제 선정 전략을 수정하거나, 규칙 설정을 조정하거나, 제품 우선순위를 바꾸는 일이에요. Agent는 주어진 목표 아래에서 최적의 경로를 찾는 데는 능하지만, 목표 자체를 바꿔야 하는지 판단하는 데는 능하지 않아요. 비즈니스 맥락, 브랜드에 대한 판단, 책임 부담이 필요하기 때문이에요.
실무에서는 이렇게 구분할 수 있어요. 어떤 작업이 Agent 자신의 규칙이나 목표를 수정하거나(예: rules.json의 트리거 조건 변경), 그 결과가 이후 수많은 작업의 전제가 된다면 ‘방향을 바꾸는 일’로 봐요.
| 기준 | 저위험 특성 | 고위험 특성 | 권장 처리 방식 |
|---|---|---|---|
| 가역성 | 초안, 브랜치, 테스트 환경, 클릭 한 번으로 롤백 가능 | 삭제, 덮어쓰기, 외부 공개, 메시지 전송 | 고위험은 반드시 승인 |
| 비용 영향 | 단일 비용이 낮고 누적 비용이 예산 이내 | 임곗값 초과, 반복 실행으로 비용 증가 가능 | 임곗값 이내는 자율 실행, 초과 시 승인 |
| 방향성 | 정해진 목표에 따라 실행 | 규칙, 목표 또는 장기 전략 수정 | 모두 사람이 결정 |
| 종합 판단 | 세 항목 모두 저위험 | 어느 하나라도 고위험 | 한 기준이라도 고위험이면 멈춰서 사람에게 확인 |
승인 절차가 너무 많거나 적을 때의 대가
경계를 정하는 핵심은 두 가지 실패 사이에서 균형을 찾는 거예요. 승인 절차가 너무 많아도, 너무 적어도 Agent 자동화 프로젝트는 실패할 수 있지만 실패하는 방식은 달라요.
| 상황 | 대표적인 양상 | 직접적인 결과 | 장기적인 영향 |
|---|---|---|---|
| 승인 절차가 너무 많음 | 단계마다 확인 창이 뜨고 카드가 쌓임 | 자동화가 ‘사람이 버튼을 누르는 일’로 변질됨 | 승인 피로가 쌓여 내용을 보지 않고 동의하게 됨 |
| 승인 절차가 너무 적음 | 중요한 작업도 자율적으로 실행함 | 실수로 삭제하거나, 예산을 초과하거나, 목표에서 벗어남 | 사고 한 번으로 시스템에 대한 신뢰가 무너짐 |
| 경계가 적절함 | 세 가지 고위험 상황에서만 멈춤 | 사람은 정말 판단이 필요한 일만 처리함 | 신뢰가 쌓이면서 점차 권한을 위임할 수 있음 |
승인 절차가 너무 많을 때 가장 눈에 띄지 않는 위험은 ‘승인 피로’예요. 매일 수십 장의 확인 카드를 받다 보면 내용을 보지 않고 동의하는 습관이 생기기 쉬워요. 승인은 있으나 마나 해지고, 누군가 검토한다고 착각하기 때문에 승인 절차가 없는 것보다 오히려 위험할 수 있어요. 카즈크 시스템이 ‘세 가지 상황에서만 사람을 찾도록’ 제한한 이유도 매번 요청받을 때마다 진지하게 검토할 수 있도록 하기 위해서예요.
Agent의 사람 결정 경계 빠르게 시작하기: 5단계로 승인 경로 구축하기
다음은 승인 경로를 처음부터 설계하는 단계예요. 특정 프레임워크에 종속되지 않으므로 원하는 이벤트 스케줄링 도구와 메신저 플랫폼을 사용해 구현할 수 있어요.
1단계: Agent의 모든 동작 파악하기
파일 읽기와 쓰기, 레코드 삭제, 외부 API 호출, 메시지 전송, 설정 변경 등 Agent가 사용할 수 있는 모든 도구와 동작을 나열하세요. 각 항목에 세 가지 기준에 따라 태그를 붙여 ‘동작 위험 목록’을 만드세요. 이 목록은 이후 모든 규칙의 기초이자 팀이 경계를 논의할 때 사용할 수 있는 공통 기준이 돼요.
두 번째 단계: 규칙을 한곳에서 관리하기
카즈크가 rules.json으로 트리거와 스케줄링을 통합 관리하는 방식처럼, ‘어떤 작업에 승인이 필요한지’도 각 에이전트의 프롬프트에 흩어 놓지 말고 한곳에서 설정하세요. 설정을 통합하면 두 가지 장점이 있어요.
- 감사 가능: 현재 어떤 작업에 사람의 확인이 필요한지 누구나 볼 수 있어요.
- 조정 용이: 승인 기준을 강화하거나 완화할 때 한 곳만 수정하면 돼요.
다만 이 설정을 수정하는 것 자체가 ‘방향 변경’에 해당하므로, 반드시 사람이 직접 처리해야 해요.
세 번째 단계: CI가 먼저 자동 검증하도록 하기
사람에게 확인을 요청하기 전에 자동화 검사를 통해 확인 가능한 항목을 모두 점검하세요. 카즈크의 CI 중간 플랫폼은 검토, 검사, 병합, 배포, 검증의 다섯 단계로 구성돼 있어요. 따라서 사람이 최종 판단을 내릴 때는 형식 오류나 테스트 실패 같은 기본적인 문제가 이미 걸러진 상태예요. 사람이 기계를 대신해 검사하거나, 기계가 사람을 대신해 판단해서는 안 돼요.
네 번째 단계: 의사결정 카드 설계하기
다음은 의사결정 카드에 관한 설계 제안으로, 원래 시스템의 세부 사항은 아니에요. 핵심은 사람이 수십 초 안에 판단할 수 있도록 하는 거예요.
- 무엇을 할지 한 문장으로 설명: 예를 들어 “3월 이전의 초안 기록 3건을 삭제합니다”라고 적어요.
- 해당하는 위험 유형: 되돌릴 수 없는 작업인지, 예산 초과인지, 방향 변경인지 표시해요.
- 영향 범위와 금액: 데이터 몇 건이 영향을 받는지, 예상 비용은 얼마인지 알려줘요.
- Agent의 판단 이유와 근거: 왜 이 작업을 하려는지, CI 검증 결과는 어떤지 보여줘요.
- 명확한 조작 버튼: 동의와 거부 버튼을 제공하고, 필요하면 “수정 후 실행”도 추가해요.
다섯 번째 단계: 타임아웃과 기본 동작 정의하기
사람이 항상 온라인 상태일 수는 없어요. 카드가 처리되지 않을 때 얼마 후 타임아웃으로 볼지, 이후 기본 동작을 “실행하지 않음”으로 할지 “제한된 방식으로 실행”할지 미리 정해야 해요. 데이터 삭제나 비용 지출 같은 작업은 기본값을 “실행하지 않음”으로 설정하세요. 작업이 기다리더라도 응답이 없다는 이유로 승인된 것으로 간주해서는 안 돼요.
🚀 빠른 시작: 프로토타입 단계에서는 먼저 통합된 모델 진입점을 사용해 “Agent 실행 → CI 검증 → 카드 승인”의 전체 흐름을 구축해 보세요. APIYI apiyi.com을 통해 다양한 주요 모델을 호출하면 승인 로직을 바꾸지 않고도 모델을 전환하면서 승인 요청 빈도와 판단 이유의 품질을 비교할 수 있어요.
CI 검증과 사람의 최종 결정, 어떻게 나눌까요?
많은 팀이 궁금해해요. CI가 확인할 수 있다면 왜 사람이 필요할까요? 두 주체가 답하는 질문이 다르기 때문이에요. 아래 표에서 역할의 경계를 정리했어요.
| 단계 | 답하는 질문 | 판단 기준 | 담당 |
|---|---|---|---|
| 심사 / 검사 | 결과물이 규격에 맞는가 | 규칙, 테스트, 형식 | CI 플랫폼 |
| 병합 / 배포 | 다음 단계로 넘어갈 수 있는가 | 모든 검사 통과 여부 | CI 플랫폼 |
| 검증 | 결과가 실제로 적용됐는가 | 사후 검증 | CI 플랫폼 |
| 데이터 삭제 / 비용 지출 / 방향 변경 | 이렇게 해야 하는가 | 비즈니스 판단과 책임 | 사람의 결정 |
| 모델 호출 소스 | 어떤 모델을 쓰고 비용은 얼마나 들이는가 | 예산 한도 | 설정 규칙 + 사람의 최종 대응. APIYI apiyi.com을 통해 사용량을 집계할 수 있음 |
자주 묻는 질문 FAQ
Q1: Agent의 인간 의사결정 경계란 무엇인가요?
Agent가 자율적으로 실행할 수 있는 작업과 사람의 확인이 필요한 작업을 구분하는 기준이에요. 경계 안에서는 Agent가 자유롭게 실행하고, 경계에 도달하면 멈춰서 사람에게 결정을 맡겨요. 보통 되돌릴 수 있는지, 비용에 미치는 영향, 방향성이라는 세 가지 기준으로 정해요.
Q2: 사람의 승인과 CI 자동 검사는 어떻게 다른가요?
CI는 규칙과 테스트를 바탕으로 “맞는가”에 답하며, 기계가 처리하기에 적합해요. 사람의 승인은 비즈니스 판단과 책임을 바탕으로 “해야 하는가”에 답해요. 전자는 최대한 자동화하고 후자는 꼭 필요한 경우로 좁혀야 해요. 둘을 함께 활용해야 빠르면서도 안정적으로 운영할 수 있어요.
Q3: ‘방향 변경’처럼 모호한 범주는 어떻게 정의하나요?
원본 자료에는 저자가 구체적으로 어떻게 정의했는지 나와 있지 않아요. Agent 자체의 규칙이나 목표를 수정하는 작업, 그리고 그 결과가 이후 수많은 작업의 전제가 되는 작업은 모두 ‘방향 변경’으로 취급하는 것을 권장해요. 구분이 모호하다면 우선 승인 대상으로 분류한 뒤, 실제 상황에 맞춰 점차 권한을 위임하세요.
Q4: 어떤 상황에 사람의 의사결정 지점이 가장 필요한가요?
주로 다음과 같은 상황이에요.
– **데이터 정리 작업**: 만료된 기록이나 파일을 정기적으로 삭제할 때
– **콘텐츠 자동 발행**: 외부에 공개하기 전 최종 확인할 때
– **대량 모델 호출**: 반복 실행으로 비용이 크게 늘어날 수 있는 유료 호출
– **정책 관련 조정**: 콘텐츠 주제 방향이나 스케줄링 규칙 등을 수정할 때
Q5: Agent의 대규모 언어 모델 호출 비용은 어떻게 관리하나요?
단건과 누적 비용에 각각 예산 한도를 설정하는 것이 좋아요. 한도 내에서는 자율적으로 실행하고, 초과하면 승인을 요청하는 방식이에요. 모델 호출을 APIYI apiyi.com과 같은 통합 인터페이스 플랫폼으로 모으면 사용량을 한곳에서 확인할 수 있어 한도와 비교하고 모니터링과 사후 분석을 하기도 쉬워요.
Q6: 설정한 승인 경계가 적절한지 빠르게 확인하려면 어떻게 하나요?
먼저 소규모 실제 작업으로 시험 운영하면서 매일 승인 요청 횟수, 거부율, 평균 응답 시간을 기록하세요. 승인 요청은 많은데 거부율이 매우 낮다면 경계가 지나치게 엄격한 거예요. 반대로 문제가 사후에 발견된다면 경계가 너무 느슨한 거예요. 초기에는 APIYI apiyi.com에서 여러 모델로 같은 작업을 각각 실행해 승인 요청이 발생하는 차이를 살펴볼 수도 있어요.
Q7: 이 방식의 한계는 무엇인가요?
사람의 승인은 담당자가 접속해 응답해야 하므로 심야나 공휴일에는 작업이 밀릴 수 있어요. 카드에 담긴 정보가 불충분하면 사람도 잘못 판단할 수 있고요. 또한 이 글의 근거가 된 원본 자료는 요약본이라, 승인 없이 잘못 실행된 사례나 구체적인 보호 메커니즘의 세부 내용은 공개되지 않았어요. 실제 적용 시에는 자체 시스템에 맞춰 타임아웃, 로그, 롤백 메커니즘을 추가해야 해요.
Agent는 언제 멈추고 사람에게 물어야 할까요? 핵심 요점 Key Takeaways
- 핵심 원칙: 데이터 삭제, 비용 지출, 방향 변경의 세 가지 상황에서만 사람에게 물어 각 승인이 제 역할을 하도록 해요.
- 세 가지 판단 기준: 되돌릴 수 있는지, 비용에 어떤 영향을 주는지, 방향을 바꾸는지 살펴 새로운 작업을 빠르게 분류해요.
- 명확한 역할 분담: CI는 “올바른가”를, 사람은 “해야 하는가”를 판단하며 서로를 대체하지 않아요.
- 승인 피로 주의: 승인이 너무 많으면 습관적으로 동의를 누르게 돼, 승인이 아예 없는 것보다 더 위험할 수 있어요.
- 보수적인 기본값: 제한 시간 안에 처리되지 않은 고위험 작업은 기본적으로 실행하지 않아요.
- 통합 접점: APIYI apiyi.com을 통해 여러 모델을 한곳에서 호출하면 비용 임계값을 관리하고 모델을 비교하기 쉬워요.
정리
Agent가 언제 멈추고 사람에게 물어야 하는지는 결국 효율과 위험 사이에 명확한 경계를 긋는 문제예요.
- 세 가지 의사결정 지점에서 시작해요: 데이터 삭제, 비용 지출, 방향 변경으로 대부분의 고위험 상황을 다룰 수 있어요.
- 세 가지 기준으로 확장해요: 되돌릴 수 있는지, 비용에 어떤 영향을 주는지, 방향을 바꾸는지 따져 어떤 새로운 작업에도 경계를 적용해요.
- 기계 검증으로 부담을 줄여요: CI가 기초적인 문제를 걸러내고, 사람은 판단이 필요한 일만 처리해요.
경계는 한 번 정하면 끝나는 게 아니라 신뢰가 쌓이면서 점차 완화할 수 있어요. 처음에는 엄격한 경계로 시험 운영하고, 데이터를 바탕으로 어디까지 권한을 넘길지 결정해 보세요. 구축과 조정 단계에서는 APIYI apiyi.com을 통해 여러 모델을 통합 연동하고, 각 모델이 승인 과정에서 어떻게 작동하는지 빠르게 검증할 수 있어요.
📚 참고 자료
- 数字生命卡兹克이 공유한 1년간 다듬은 Agent 자동화 시스템 아키텍처: 이 글의 원칙과 아키텍처 정보 출처
- 링크:
aihot.news/items/dzwfvd9xp6v4qaj6olxezpier - 설명: 자동화 중간 플랫폼, Agent 실행, CI 중간 플랫폼, Feishu 의사결정으로 구성된 4계층 아키텍처와 “데이터 삭제, 비용 지출, 방향 변경 시에만 사람을 찾는다”는 원칙을 소개해요. 요약 자료이므로 자세한 내용은 원문을 확인해야 해요.
작성자: APIYI 기술팀
기술 교류: APIYI apiyi.com 홈페이지에서 연락해 Agent 자동화와 사람과 AI의 협업을 실제로 적용한 경험을 나눠주세요. 더 많은 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
