AI 에이전트 운영 설계: 업무 층위별 배치와 인간 승인 기준부터 정하는 법

개발팀이 AI 에이전트를 도입할 때 처음 받는 요청은 대개 비슷합니다. “PR을 더 많이 만들게 해 달라”, “장애 대응을 자동화하자”, “사내 문서를 찾아 답하게 하자”는 식입니다. 그러나 이 요청을 곧바로 모델 선정이나 도구 구매로 옮기면, 얼마 지나지 않아 다른 문제가 생깁니다. 같은 업무인데 어떤 사람은 고가 모델을 길게 쓰고, 어떤 에이전트는 필요 없는 도구 설명과 대화 이력을 반복해서 읽으며, 누가 결과를 승인해야 하는지도 모호해집니다.

에이전트를 많이 쓰는 조직의 경쟁력은 가장 좋은 모델을 확보하는 데서만 나오지 않습니다. 업무의 위험도와 반복성에 맞춰 에이전트를 배치하고, 작업 단위별 비용과 품질을 측정하며, 사람이 개입할 지점을 운영 규칙으로 고정하는 데서 나옵니다.

요구사항 단계에서 CTO와 개발 리더가 먼저 정할 일은 “어떤 에이전트를 도입할까”가 아닙니다. 어떤 업무를 어느 수준까지 맡기고, 실패했을 때 누가 어떤 근거로 멈추거나 승인할 것인가입니다.

업무를 네 가지 층으로 나누면 도입 순서가 보인다

모든 에이전트 업무를 같은 통제 방식으로 운영할 수는 없습니다. 개발자가 터미널에서 탐색적으로 쓰는 코딩 세션과, 모든 PR에 자동으로 댓글을 다는 코드 리뷰 봇은 위험도와 비용 구조가 다릅니다.

요구사항을 정할 때는 업무를 다음 네 층으로 구분해 보는 편이 좋습니다.

1. 개인 보조 세션 개발자, 분석가, 운영자가 대화형 도구를 직접 사용합니다. 코드 초안, 문서 요약, 테스트 아이디어, 로그 탐색처럼 결과를 사용자가 즉시 검토하는 업무가 여기에 맞습니다. 자유도는 높지만 세션마다 작업 범위와 비용이 달라집니다.

2. 팀 규칙이 붙은 스킬 세션 개인 도구에 저장소 규칙, 테스트 명령, 문서 검색 방식, 배포 금지 구역 같은 팀 지침을 붙입니다. 반복되는 작업의 품질 편차를 줄이기 좋습니다. 다만 스킬이 늘수록 관리 대상도 늘므로, 누가 만들고 수정하며 폐기하는지 정해야 합니다.

3. 요청형 실행 에이전트 사용자가 티켓이나 채널에서 업무를 요청하면 클라우드 환경에서 에이전트가 실행합니다. 예를 들어 실패한 CI 원인 분류, 정해진 형식의 운영 리포트 생성, 데이터 조회 초안 작성이 가능합니다. 실행 권한과 데이터 범위를 역할별로 분리해야 합니다.

4. 관리형 업무 에이전트 코드 리뷰, 보안 점검, 정형 문서 대조처럼 입력과 산출물이 비교적 정해진 업무를 지속적으로 처리합니다. 이 층에서는 “PR 한 건당 비용”, “검토 건당 오류 탐지율”, “처리 지연시간”처럼 업무 단위로 성과를 측정할 수 있습니다. 운영 규모가 커질수록 이 층의 가치가 커지지만, 충분한 검증 데이터와 승인 절차가 먼저 필요합니다.

처음부터 네 번째 층을 목표로 삼을 필요는 없습니다. 업무 규칙이 아직 사람 머릿속에만 있거나, 예외 처리가 매번 다르다면 개인 보조 또는 스킬 세션으로 시작하는 편이 안전합니다. 반대로 입력 형식, 허용 행동, 성공 조건이 명확한 반복 업무는 관리형 에이전트 후보가 될 수 있습니다.

첫 대상 업무는 생산성보다 실패 비용으로 고른다

에이전트 도입 후보를 고를 때 “시간이 많이 드는 업무”만 보면 판단이 부족합니다. 시간은 많이 들지만 잘못 처리했을 때 되돌리기 쉬운 업무와, 한 번의 오류가 고객·보안·재무 문제로 이어지는 업무를 구분해야 합니다.

초기 후보는 아래 조건을 많이 만족할수록 적합합니다.

• 입력 자료와 완료 기준이 어느 정도 정형화돼 있다.
• 결과를 사람이 짧은 시간 안에 확인할 수 있다.
• 오류가 나도 되돌리거나 재처리할 수 있다.
• 에이전트가 접근할 데이터와 실행 권한을 좁게 제한할 수 있다.
• 사람이 하던 처리 결과나 과거 사례가 남아 있어 평가 기준을 만들 수 있다.

예를 들어 테스트 코드 초안, 이슈 분류, 문서 내 항목 추출, 알려진 패턴의 코드 리뷰는 초기 검증 대상으로 삼기 쉽습니다. 반면 고객 계정 변경, 결제 처리, 운영 환경 배포, 인사·계약 판단처럼 실행 결과가 외부에 바로 영향을 주는 업무는 에이전트가 제안하고 사람이 승인하는 구조부터 검토해야 합니다.

여기서 중요한 것은 업무의 이름이 아닙니다. “장애 대응 자동화”도 로그 요약과 담당 팀 추천까지만 맡기면 보조 업무가 될 수 있지만, 롤백과 트래픽 차단까지 수행하면 고위험 실행 업무가 됩니다. 요구사항 문서에는 에이전트의 업무명을 쓰는 데서 멈추지 말고, 읽을 수 있는 정보, 제안할 수 있는 행동, 독자 실행 가능한 행동, 인간 승인이 필요한 행동을 각각 적어야 합니다.

요구사항에는 품질 기준과 중단 기준을 함께 넣는다

에이전트 프로젝트가 흐려지는 이유는 “잘 동작한다”는 표현이 너무 넓기 때문입니다. 개발 리더는 기능 요구사항과 함께 평가 가능한 품질 기준을 작성해야 합니다.

관리형 에이전트라면 다음 산출물을 요구사항 단계에서 준비할 수 있습니다.

산출물	결정할 내용
업무 경계 정의서	시작 조건, 입력, 산출물, 금지 행동, 종료 조건
평가 세트	과거 티켓, PR, 문서, 장애 기록 등 실제 업무를 대표하는 익명화·권한 검토 자료
채점 기준	정확성, 누락, 잘못된 경고, 처리 시간, 인간 수정량
승인 매트릭스	자동 완료, 사후 검토, 사전 승인, 실행 금지의 구분
실패 처리 흐름	재시도 조건, 사람에게 넘길 조건, 기록 보존 방식
비용 측정 명세	업무당 비용, 실패 재시도 비용, 모델·도구·세션별 사용량

코드 리뷰 에이전트라면 “버그를 많이 찾는다”보다 더 구체적으로 정해야 합니다. 유효한 지적 중 실제 문제의 비율은 높은지, 알려진 문제를 얼마나 놓치는지, 개발자가 무시하는 경고가 얼마나 많은지, 리뷰가 PR 병합을 늦추지는 않는지를 함께 봐야 합니다. 하나의 점수만 높아도 운영 품질이 좋다고 말하기 어렵습니다.

중단 기준도 사전에 합의해야 합니다. 예를 들어 특정 유형의 오류가 반복되거나, 인간 검토자가 수정하는 비율이 높아지거나, 비용 증가가 업무 처리량 증가를 크게 앞지를 때는 확대를 멈추고 원인을 분석합니다. 이 기준이 없으면 팀은 사용량이 늘었다는 이유만으로 성공이라고 판단하기 쉽습니다.

비용은 토큰 총액이 아니라 업무 흐름에서 추적한다

AI 비용을 월별 청구서 총액으로만 보면, 무엇을 줄여야 하는지 알기 어렵습니다. 비용은 사용 인원, 세션 수, 세션 안에서 오가는 횟수, 요청당 입력·출력 크기, 모델 단가가 함께 만든 결과입니다. 도입 확대 자체가 문제인지, 에이전트가 불필요하게 탐색과 재시도를 반복하는지가 이 분해 없이는 보이지 않습니다.

특히 다음 신호는 운영 초기에 확인할 가치가 있습니다.

• 사용자가 요청한 업무보다 에이전트의 탐색·재시도 횟수가 빠르게 늘어난다.
• 사용하지 않는 도구의 설명과 스키마가 매 세션에 포함된다.
• 긴 로그, 대형 파일, 도구 응답이 이후 모든 대화에 반복 전달된다.
• 작은 하위 작업에도 고성능 모델이 기본 배정된다.
• 에이전트가 필요한 내부 문서나 데이터 위치를 몰라 여러 시스템을 돌아다닌다.

우버는 에이전트 사용자가 크게 늘어난 기간에도 비용을 안정적으로 관리하기 위해, 실제 업무 기반 벤치마크로 모델을 비교하고 세션의 입력 토큰, 도구 스키마, 반복 탐색을 줄이는 방식에 집중했다. 다만 특정 조직에서 보고된 비용 절감 폭을 다른 조직의 목표치로 삼을 수는 없습니다. 코드베이스 크기, 데이터 접근 방식, 모델 계약, 작업 난이도가 다르기 때문입니다.

적용할 원칙은 수치가 아니라 측정 방식입니다. 개인 대화형 세션은 사용자 경험과 총량을 중심으로 보고, 관리형 에이전트는 처리 건당 비용과 품질을 함께 봅니다. 비용이 높은 세션을 무조건 막기보다, 왜 비쌌는지와 그 비용이 사람의 작업 시간을 얼마나 줄였는지를 구분해 판단해야 합니다.

인간 승인은 마지막 안전장치가 아니라 작업 설계의 일부다

승인 절차를 “에이전트가 다 만든 뒤 사람이 최종 확인하는 단계”로만 생각하면 검토자가 과부하에 빠질 수 있습니다. 사람이 무엇을 검토해야 하는지, 어떤 정보가 있어야 빠르게 판단하는지까지 설계해야 합니다.

권한 수준은 다음처럼 나눌 수 있습니다.

• 자동 처리: 결과가 내부 초안에만 반영되고 쉽게 되돌릴 수 있는 작업
• 사후 표본 검토: 정형 업무를 처리하되 일정 기준에 따라 사람이 결과를 점검하는 작업
• 사전 승인 후 실행: 코드 병합, 외부 시스템 변경, 고객 영향 작업처럼 실행 전에 책임자가 확인해야 하는 작업
• 제안만 허용: 법률·인사·재무 판단, 고위험 운영 조치처럼 에이전트가 결론이나 실행을 독자적으로 내리면 안 되는 작업

승인 화면이나 PR에는 결과만 보여주지 않는 편이 좋습니다. 에이전트가 사용한 근거, 변경 범위, 실행한 도구, 남은 불확실성, 실패하거나 건너뛴 단계도 함께 보여줘야 합니다. 승인자는 답을 다시 만드는 사람이 아니라, 근거와 영향 범위를 보고 책임 있는 결정을 내리는 사람이어야 합니다.

작은 관리형 업무 하나로 운영 체계를 시험한다

첫 프로젝트에서 목표로 삼을 것은 전사 에이전트 플랫폼이 아닙니다. 반복되고 측정 가능하며 되돌릴 수 있는 업무 하나를 골라, 배치·평가·비용·승인의 연결이 작동하는지 확인하는 일입니다.

요구사항 워크숍에서는 다음 순서로 결정해 볼 수 있습니다.

1. 후보 업무를 나열하고, 오류 영향과 되돌리기 가능성을 기준으로 제외할 업무를 먼저 정합니다.
2. 남은 업무 중 과거 결과를 확보할 수 있는 한 건을 고릅니다.
3. 에이전트가 읽는 데이터와 실행 권한을 최소 범위로 제한합니다.
4. 사람의 기존 결과와 비교할 평가 세트, 품질 기준, 중단 기준을 만듭니다.
5. 자동 처리와 인간 승인의 경계를 문서와 시스템 권한에 모두 반영합니다.
6. 업무당 비용, 품질, 재작업, 승인 소요 시간을 같은 대시보드에서 검토합니다.
7. 기준을 충족한 뒤에만 유사 업무로 범위를 넓힙니다.

에이전트 수를 늘리기 전에, 한 업무가 실패했을 때 누가 무엇을 보고 멈출 수 있는지부터 확인해 보십시오. 그 답이 문서와 권한 설정, 측정 지표에 남아 있다면 다음 에이전트를 늘릴 때도 통제력을 잃지 않을 가능성이 높습니다.