AI agent 를 운영팀이 직접 만들 수 있을까

이 질문이 결제·정산 현장에서 특히 날카로운 이유

우리 팀은 세 명이서 결제 연동, 정산 자동화, 운영 지원을 모두 커버한다. 개발과 운영 사이에 벽이 없다는 건 좋게 말하면 빠른 의사결정이고, 솔직하게 말하면 한 사람이 여러 역할을 동시에 해야 한다는 뜻이다. 이 구조에서 자동화는 선택이 아니라 생존 조건에 가깝다.

함께 일하는 운영 파트너사로부터 "개발자 없이도 AI 에이전트를 만들 수 있냐"는 질문이 들어왔을 때, 우리가 먼저 한 일은 그 파트너사의 반복 작업 목록을 꺼내 보는 것이었다. 매일 오전 이메일로 들어오는 정산 예외 건 확인, PG사별 수수료 차이를 시트에 정리하는 작업, 환불 요청 분류와 담당자 배분—이 세 가지만 해도 하루 평균 2.5시간이 소요되고 있었다. 여기서 핵심은 이 작업들이 "반복적"이라는 점이 아니라, "규칙으로 설명 가능한가"라는 점이다. 결제·정산 도메인은 규칙이 명확한 동시에 예외도 많다. 그 경계를 어디에 긋느냐가 노코드 자동화의 성패를 결정한다.

노코드 도구가 실제로 커버할 수 있는 범위

현재 시장에 나와 있는 노코드·로우코드 에이전트 도구들—Make, n8n, Zapier AI, Dify 등—은 3년 전과 비교해 체감상 다른 수준에 와 있다. 이메일 수신 → 내용 파싱 → LLM 분류 → 결과를 지정 시트에 기록 → 슬랙 알림 발송까지, 이 플로우는 코드 한 줄 없이 완성된다. 우리가 파트너사와 함께 만든 환불 요청 분류 에이전트가 정확히 이 구조였다.

LLM을 붙이는 것도 이제는 API 키 입력과 프롬프트 작성이 전부다. 여기서 흥미로운 역전이 일어난다. 프롬프트 품질을 결정하는 건 프로그래밍 지식이 아니라 도메인 이해와 글쓰기 능력이다. "환불 사유가 '상품 불량'인 경우에는 CS팀으로, '단순 변심'은 정산팀으로, 그 외는 보류로 분류하라"는 지시를 정확하게 쓸 수 있는 사람은 개발자가 아니라 그 업무를 직접 해온 운영 담당자다. 우리가 함께 작업한 파트너사 운영팀은 프롬프트 초안을 우리보다 빠르게, 더 정확하게 작성했다. 이건 과장이 아니다.

실제로 막히는 지점과 수치로 본 트레이드오프

문제는 "예상하지 못한 상황"에서 발생한다. 환불 요청 분류 에이전트를 2주 운영했을 때 오분류율이 초반 약 8%에서 4주차에 3%대로 내려갔다. 하지만 그 3%의 케이스가 실제로는 가장 손이 많이 가는 건이었다. PG사가 응답 형식을 갑자기 바꾸거나, 동일 거래에 대해 취소와 부분 환불이 동시에 들어오는 케이스, 이메일 본문이 이미지 스캔본으로 첨부된 경우—노코드 플로우는 이 상황에서 그냥 멈추거나 조용히 오류를 흘려보냈다.

두 번째 벽은 외부 시스템 연동이다. 파트너사가 사용하는 사내 정산 시스템은 REST API가 없고 엑셀 파일 업로드 방식으로만 데이터를 받는다. Zapier는 이 시스템을 모른다. 웹훅도 없다. 이 지점에서 노코드는 멈춘다. 결국 우리가 Python 스크립트 80줄짜리 얇은 레이어를 만들어서 파일 생성·업로드를 자동화했고, 그 스크립트를 n8n에서 HTTP 요청으로 호출하는 구조를 붙였다. 이 작업에 반나절이 걸렸는데, 이 반나절이 없었다면 전체 자동화는 완성되지 않았다. 노코드는 90%를 커버하지만, 나머지 10%가 전체를 무력화할 수 있다.

HEDVION이 파트너사와 실제로 구성한 협업 구조

우리가 선택한 접근은 "운영팀이 완전히 독립해서 만드는 것"이 아니라 "운영팀이 유지·확장할 수 있는 구조를 우리가 기초 공사로 깔아두는 것"이었다. 구체적으로는 세 단계로 나눴다.

첫째, 외부 시스템 연동과 에러 핸들링은 우리가 코드로 처리하고 API 엔드포인트나 웹훅으로 노출시킨다. 운영팀 입장에서는 "이 주소로 요청을 보내면 결과가 온다"는 블랙박스만 알면 된다. 둘째, 분류 로직·프롬프트·조건 분기는 운영팀이 노코드 UI에서 직접 수정한다. 셋째, 결과 검증 루틴—매일 오전 10시에 전날 처리 건과 수동 처리 건을 비교하는 요약 리포트—도 자동화해서, 에이전트가 이상하게 동작하면 운영팀이 스스로 인지할 수 있게 했다. 이 구조가 안착된 이후 파트너사 운영팀은 실제로 우리 개입 없이 두 가지 플로우를 추가로 만들었다. 하나는 PG사별 정산 지연 알림, 다른 하나는 월말 수수료 정리 리포트 자동 발송이다.

기술보다 어려운 것: 자동화 설계 역량

여러 번의 지원을 통해 얻은 가장 중요한 결론은 이것이다. 자동화의 진짜 병목은 코드가 아니라 "무엇을 자동화할 것인가"를 결정하는 역량이다. 이 역량은 세 가지로 분해된다.

첫째, 자동화 가능한 작업을 식별하는 능력. 운영팀이 "우리 업무는 다 케이스 바이 케이스라 자동화가 안 된다"고 말할 때, 그 말은 대부분 절반만 맞다. 전체 케이스의 70-80%는 실제로 규칙으로 설명된다. 나머지 20-30%가 예외처럼 느껴지는 이유는 그게 더 기억에 남기 때문이다. 둘째, 작업의 범위와 예외를 명확하게 쓰는 능력. "환불 요청을 처리한다"는 정의는 자동화 요건이 아니다. "이메일 제목에 '환불' 또는 '취소'가 포함되고, 본문에 주문번호가 있으며, 요청 금액이 원금의 100% 이하인 경우"가 자동화 요건이다. 이 문장을 쓰는 연습이 없으면 에이전트는 만들 수 없다. 셋째, 결과 검증 루틴을 설계하는 능력. 에이전트가 조용히 틀린 결과를 냈을 때 이를 잡아내는 구조 없이 자동화를 믿는 것은 위험하다. 우리가 직접 운영하는 정산 자동화에도 매일 아침 전일 처리 건의 합산 금액과 PG사 정산 데이터를 교차 검증하는 체크가 있다. 이게 없었다면 우리도 몇 번은 사고가 났을 것이다.

지금 바로 써먹을 수 있는 실행 시사점

노코드 AI 에이전트 도입을 검토 중인 운영팀이라면 아래 순서로 움직여라.

1단계: 작업 목록 대신 규칙 목록을 먼저 써라. 반복 작업을 나열하는 게 아니라, "이 작업은 A이면 B를 한다"는 형태로 규칙을 작성해본다. 규칙으로 쓸 수 없는 작업은 현시점에서 자동화 대상이 아니다. 억지로 넣으면 나중에 더 큰 수작업이 생긴다.

2단계: 외부 시스템 연동이 필요한지 먼저 확인하라. 연동이 필요하다면 그 부분은 개발 지원 없이 해결이 안 된다. 이걸 먼저 파악해야 일정과 범위를 현실적으로 잡을 수 있다. 연동이 필요 없는 작업—이메일 분류, 데이터 요약, 슬랙 알림—부터 시작하면 첫 성공 경험을 빠르게 만들 수 있다.

3단계: 검증 루틴을 에이전트와 동시에 만들어라. 자동화 플로우를 배포하는 날, 그 결과를 사람이 확인하는 루틴도 함께 만든다. 처음 2-4주는 에이전트 결과와 수동 처리 결과를 나란히 두고 오분류율을 측정한다. 이 숫자가 허용 범위 안에 들어올 때 수동 검증 비중을 줄여간다. 이 과정을 건너뛰면 에이전트를 믿을 수가 없고, 믿을 수 없으면 자동화의 의미가 없다.

4단계: 첫 버전에서 완전 자동화를 기대하지 마라. 우리가 실제로 운영 중인 자동화도 대부분 "80% 자동 처리 + 20% 사람 확인" 구조다. 100%를 목표로 설계하면 예외 처리 비용이 기하급수적으로 늘어난다. 처음에는 반자동으로 시작하고, 운영 데이터가 쌓이면 범위를 늘리는 것이 실패 없이 안착시키는 방법이다.

코드 없이 AI 에이전트를 만들 수 있냐는 질문의 정확한 답은 이것이다. 가능하다. 단, 외부 연동이 없고, 예외 범위가 좁고, 검증 루틴이 있을 때. 이 세 조건 중 하나라도 빠지면 노코드는 시작점이 되지 종착점이 되지 않는다.