에이전트 서비스 설계는 자동화가 아니라 판단을 복제하는 일이다

AI를 쓰는데도 일이 줄지 않는 순간이 있다.

글은 빨리 나온다. 요약도 빨리 된다. 코드도 전보다 훨씬 빨리 만들어진다. 고객에게 보낼 문구도 초안은 금방 나온다. 그런데 이상하게도 중요한 일은 계속 사람에게 돌아온다.

AI가 일을 대신해도, 판단이 사람에게만 남아 있으면 대표의 집중력은 회복되지 않는다. 오히려 더 자주 깨질 때도 있다. 결과물이 빨리 나오기 때문에 검수해야 할 것도 더 빨리 쌓인다. 자동화가 일을 줄이는 게 아니라, 판단 요청을 더 많이 만들어내는 것이다.

나는 이 문제를 꽤 오래 붙잡고 있었다.

처음에는 프롬프트 문제라고 생각했다. 더 좋은 프롬프트를 쓰면 되고, 더 좋은 모델을 쓰면 되고, 더 긴 컨텍스트를 넣으면 된다고 생각했다. 어느 정도는 맞았다. 하지만 Callva와 Re-Callva를 만들면서, 그리고 Hermes/Joe 같은 에이전트 운영 시스템을 직접 쓰면서 점점 다른 결론에 가까워졌다.

1. 반복되는 것은 작업이 아니라 판단이었다

전화 AI 서비스를 만들면 겉으로는 기술 문제가 먼저 보인다. 음성을 어떻게 받아올 것인가. STT와 TTS를 어떻게 붙일 것인가. 지연시간을 어떻게 줄일 것인가. 어떤 모델을 쓸 것인가. 실제 전화에서는 1초 차이도 크게 느껴지기 때문에 전부 중요한 문제다.

그런데 고객을 만나고, 스크립트를 만들고, 테스트콜을 돌리고, 실패한 콜을 다시 듣다 보면 다른 문제가 나온다.

어떤 정보는 AI가 말해도 되고, 어떤 정보는 담당자가 확인해야 한다. 어떤 고객은 더 물어봐야 하고, 어떤 고객은 바로 상담 연결 후보로 넘겨야 한다. 어떤 실패는 프롬프트 수정으로 해결되고, 어떤 실패는 고객 DB 자체가 약해서 생긴다. 같은 문장도 어느 순서에 놓이느냐에 따라 전혀 다른 결과가 된다.

처음에는 내가 이 판단을 계속 했다. 고객 말을 듣고, 스크립트를 고치고, 테스트콜을 듣고, 다시 프롬프트를 고치고, 이건 금지 표현이라고 표시하고, 이건 상담 연결 기준이라고 정리했다. 혼자서 영업, 세팅, QA, 고객 응대, 개선을 전부 돌리는 구조였다.

그때 깨달은 게 있다.

AI를 붙여도 이 구조가 그대로면 별로 달라지지 않는다. AI가 초안을 만들고, 내가 검수하고, 내가 고치고, 내가 다음번 기준을 기억해야 한다. 그러면 AI는 생산성을 올려주지만, 내 집중력을 지켜주지는 못한다.

2. Agentic service는 답변하는 서비스가 아니다

예전에 Team Attention에서 Agentic Service Design이라는 주제로 발표한 적이 있다. 그때 내가 쓴 첫 문장은 이랬다.

LLM 붙였다고 agentic 아니에요.

지금도 같은 생각이다. 챗 UI가 있다고 agentic한 것도 아니고, RAG가 있다고 agentic한 것도 아니고, 모델이 API를 호출할 수 있다고 agentic한 것도 아니다. 다 유용한 기능이지만, 그것만으로 서비스가 스스로 배우지는 않는다.

내가 지금 쓰는 정의는 조금 더 단순하다.

Agentic service는 AI가 한 번 답하고 끝나는 서비스가 아니다. 증거를 보고, 판단 후보를 만들고, 필요한 승인을 거치고, 실제 실행에 반영하고, 결과를 다시 배워 다음 판단을 바꾸는 서비스다.

Agentic의 경계는 “AI가 답했는가”가 아니라 “그 답이 다음 실행과 다음 판단을 바꾸는 루프로 들어갔는가”에 있다.

flowchart LR
  A[증거를 본다] --> B[판단 후보를 만든다]
  B --> C[위험도에 따라 승인받는다]
  C --> D[실제 업무에 반영한다]
  D --> E[결과를 본다]
  E --> F[기준을 고친다]
  F --> A

이 루프가 닫혀야 한다.

대부분의 AI 서비스는 앞부분만 있다. 로그를 본다. 요약한다. “이렇게 바꾸면 좋겠습니다”라고 제안한다. 그리고 끝난다. 누군가 그 제안을 복사해서 프롬프트에 넣어야 한다. 누군가 다음번에 기억해야 한다. 누군가 결과가 좋아졌는지 다시 봐야 한다.

보고서는 도움이 된다. 하지만 보고서가 서비스의 행동을 바꾸지는 않는다. 서비스가 실제로 바뀌려면 판단 후보가 승인되고, 승인된 기준이 다음 실행에 들어가고, 그 기준이 실제로 쓰였다는 흔적이 남고, 결과가 다시 돌아와야 한다.

그래서 내가 agentic service를 만들 때 던지는 질문은 바뀌었다.

“AI가 우리 API를 호출할 수 있나?”가 아니다.

“AI가 사람이 보는 증거를 보고, 같은 기준으로 판단 후보를 만들고, 위험한 결정은 멈추고, 승인된 기준만 실행에 반영하고, 그 결과를 다시 배울 수 있나?”다.

3. 사람은 빠지는 게 아니라 좋은 위치로 이동한다

여기서 자주 생기는 오해가 있다. Agentic하다는 말을 들으면 사람들이 사람을 빼는 자동화를 떠올린다. AI가 알아서 다 하고, 사람은 더 이상 관여하지 않는 그림이다.

나는 그 방향이 위험하다고 본다. 특히 고객 응대, 영업, 전화, 결제, 법적 안내, 의료·교육·부동산처럼 실제 사람의 의사결정에 영향을 주는 영역에서는 더 그렇다.

좋은 agentic loop는 사람을 없애는 구조가 아니다. 사람을 더 좋은 위치에 두는 구조다.

나쁜 구조에서는 사람이 중간 노드가 된다. AI가 초안을 만들면 사람이 복사한다. AI가 추천하면 사람이 다시 정리한다. AI가 실패하면 사람이 로그를 뒤져본다. 모든 반복 실행 사이에 사람이 끼어 있다. 그러면 속도도 깨지고, 흔적도 끊기고, 사람의 집중력도 계속 깨진다.

반대쪽 나쁜 구조도 있다. 사람을 너무 빨리 빼버리는 것이다. AI가 만든 가설이 바로 제품 동작을 바꾸고, 고객에게 바로 나가고, 나중에야 문제가 발견된다. 이건 자동화가 아니라 충동에 가깝다.

좋은 구조는 다르다.

사람은 모든 콜, 모든 문장, 모든 로그를 보는 사람이 아니라 기준을 바꾸는 사람, 예외를 판단하는 사람, 위험한 결정을 승인하는 사람이 된다.

Callva/Re-Callva에서 고객이 원하는 것도 결국 이쪽에 가깝다. 고객은 “AI가 다 알아서 해요”라는 말을 사고 싶어 하지 않는다. 고객이 사고 싶은 건 “내가 계속 붙잡고 있지 않아도, 중요한 기준은 지켜지는 상태”다.

4. 스킬은 프롬프트가 아니라 판단 패키지다

이 생각은 Hermes/Joe를 쓰면서 더 선명해졌다.

처음에는 나도 프롬프트를 많이 고쳤다. 어떻게 말하면 더 잘 알아들을까. 어떤 예시를 넣으면 더 좋은 결과가 나올까. 그런데 시간이 지나면서 중요한 건 개별 프롬프트보다 스킬이라는 생각을 하게 됐다.

좋은 스킬에는 단순히 “이렇게 답하라”가 들어가지 않는다. 언제 이 스킬을 써야 하는지, 무엇을 먼저 확인해야 하는지, 어떤 근거를 더 믿어야 하는지, 어떤 실수를 조심해야 하는지, 어디까지 하면 완료라고 볼 수 있는지, 어떤 변경은 사람 승인이 필요한지가 들어간다.

예를 들어 고객 응대 스킬이라면 단순히 “정중하게 답하라”가 아니다. 고객이 실제로 한 말이 무엇인지 먼저 보고, 기존 CRM/리드 상태를 확인하고, 견적이나 가격은 기존 자산에서 가져오고, 없는 숫자는 만들지 말고, 사람이 보낼 최종 문안만 남기는 식의 운영 기준이 들어간다.

이건 프롬프트가 아니다. 작은 운영체제에 가깝다.

내가 요즘 Joe가 내 판단을 잘 소화한다고 느끼는 이유도 모델 하나가 좋아져서만은 아니다. 강한 모델은 중요하다. 하지만 강한 모델이 읽을 수 있는 판단 기준이 없으면 결국 매번 새로 설명해야 한다. 스킬, 메모리, 세션 기록, 레저, 크론, 실행 로그 같은 것들이 엮이면서 “나는 보통 이런 상황에서 이렇게 판단한다”가 시스템에 남기 시작했다.

그때부터 AI는 단순히 답을 잘하는 도구가 아니라, 내 판단 방식을 어느 정도 반복할 수 있는 운영 파트너가 된다.

5. 강한 모델은 모든 곳에 필요한 게 아니다

요즘 내가 많이 생각하는 또 하나의 주제는 모델 라우팅이다.

처음에는 좋은 모델을 많이 쓰면 좋은 결과가 나온다고 생각하기 쉽다. 중요한 일은 전부 가장 강한 모델로 돌리고 싶어진다. 그런데 실제 운영에서는 그렇게 하면 비용도 커지고, 속도도 느려지고, 더 중요한 문제도 생긴다. 강한 모델이 필요 없는 일에까지 들어가면 정작 중요한 판단 지점이 흐려진다.

모든 작업이 같은 종류의 지능을 요구하지 않는다.

여기에 강한 모델이 들어가야 한다.

앞으로 중요한 것은 더 좋은 모델 하나가 아니라, 좋은 모델을 어디에 둘지 아는 감각이라고 본다. 비싼 모델은 모든 일을 처리하는 executor가 아니라, 판단이 비싼 지점에 놓이는 judgment layer에 가까워야 한다.

이건 비용 최적화 이야기가 아니다. 집중력의 배치에 가깝다. 사람도 마찬가지다. 대표가 모든 일을 직접 하면 회사가 느려진다. 하지만 대표가 빠지면 안 되는 결정까지 모두 위임하면 회사가 이상해진다. 에이전트 시스템도 같다. 중요한 것은 얼마나 많이 자동화했느냐가 아니라, 어디에 판단을 남겼느냐다.

6. Callva, Re-Callva, Moidat에서 이 루프가 보이기 시작했다

이 글이 추상적인 시스템 철학으로만 보이지 않았으면 한다. 내가 이 문제를 붙잡은 이유는 실제 제품에서 계속 같은 장면을 봤기 때문이다.

Callva와 Re-Callva는 전화 업무를 다룬다. 고객이 전화를 걸고, AI가 응대하고, 필요한 정보를 받고, 담당자에게 넘기고, 기록이 남고, 다음 행동이 생긴다. Re-Callva는 반대로 AI가 먼저 전화를 걸어 고객의 관심도, 재방문 가능성, 상담 연결 여부를 확인한다.

이 제품의 해자는 “전화하는 AI” 하나가 아니다. 전화 결과가 다음 세팅으로 돌아오는 루프다.

이런 것들이 쌓여야 한다. 쌓이기만 해도 부족하다. 다음 콜에 실제로 반영되어야 한다. 그리고 반영된 기준이 도움이 됐는지 다시 봐야 한다.

Moidat에서도 비슷한 방향을 보고 있다. 사람, 관계, 대화, 일정, 작업, 기록이 흩어져 있으면 AI는 사람의 생활과 일을 이해하지 못한다. 단순히 메신저 요약을 잘하는 것만으로는 부족하다. 어떤 대화가 어떤 사람과의 관계에 붙는지, 어떤 약속이 실제 작업으로 이어지는지, 어떤 기록이 다음 행동으로 남아야 하는지 구조가 필요하다.

아직 모든 루프가 완성됐다고 말하고 싶지는 않다. 그렇게 말하면 과장이다. 더 정확히는, 나는 지금 agentic service의 primitive들을 실제 제품 안에서 쌓아가고 있다. 증거(무슨 일이 있었는지), agent run(어떤 에이전트가 어떤 근거로 판단했는지), suggestion queue(바로 실행하지 않는 후보), 적용 경계(사람이 승인하거나 거절하는 지점), projection(사용자가 일하기 쉽게 보는 표면), background consolidation(흩어진 기록을 다시 정리하는 작업) 같은 조각들이다.

완성된 자기학습 시스템이라고 부르기엔 이르다. 하지만 방향은 분명하다. AI 기능을 붙이는 것이 아니라, 고객 업무가 조금씩 더 잘 돌아가도록 학습하는 운영 루프를 제품 안에 넣는 것이다.

7. AI native 회사의 레버리지는 판단 배치에서 나온다

투자자에게 이 이야기를 한다면, 나는 “AI를 잘 씁니다”라고 말하고 싶지 않다. 그 말은 너무 흔하고 약하다. “에이전트가 많습니다”도 별로 중요하지 않다. 많은 에이전트가 중요한 게 아니라, 어떤 판단을 어디에 배치했는지가 중요하다.

내가 만들고 있는 회사의 운영 레버리지는 더 구체적이다.

이 구조가 잘 작동하면, 사람을 무작정 늘리지 않고도 고객 대응 범위가 넓어진다. 대표가 모든 콜과 모든 고객 세팅을 직접 붙잡지 않아도 된다. 대신 대표의 판단 기준은 더 선명하게 남는다.

나는 이게 앞으로 AI native 회사의 중요한 형태 중 하나라고 본다.

사람이 사라지는 회사가 아니다. 좋은 사람이 더 큰 레버리지를 갖는 회사다. 대표 한 명이 모든 일을 직접 하는 회사도 아니고, AI가 제멋대로 판단하는 회사도 아니다. 사람이 책임질 판단을 선명하게 남기고, 반복 실행과 근거 수집과 초안 생성을 에이전트에게 넘기는 회사다.

8. 앞으로의 에이전트는 뒤에서 배치될 것이다

지금 많은 사람에게 AI 에이전트는 채팅창 안에 있다. 물어보면 답하고, 시키면 해준다. 이 형태는 오래 갈 것이다. 하지만 서비스 안에서 진짜 가치가 생기는 에이전트는 점점 뒤로 들어갈 가능성이 크다.

사용자는 매번 “이걸 해줘”라고 말하지 않을 것이다. 서비스는 이미 쌓인 증거를 보고, 바뀐 상태를 보고, 필요한 판단 후보를 만들고, 안전한 것은 실행하고, 위험한 것은 사람에게 올릴 것이다. 정상 상태는 조용히 지나가고, 실패·예외·중요한 결정만 사람의 주의로 올라올 것이다.

그때 경쟁력은 모델을 붙였다는 사실에서 나오지 않는다. 어떤 증거를 볼 수 있는지, 어떤 기준으로 판단하는지, 어디서 멈추는지, 무엇을 기억하고 무엇을 잊는지, 결과를 어떻게 다시 반영하는지에서 나온다.

나는 그 질문을 계속 제품으로 풀고 있다. Callva와 Re-Callva에서는 전화 업무의 판단 루프로, Moidat에서는 사람과 관계의 운영 표면으로, Hermes/Joe에서는 내 자신의 판단을 복제 가능한 스킬과 루프로 남기는 방식으로.

처음에는 복잡하게 생각했다. 철학도 많이 붙였고, 용어도 많았다. 지금은 조금 더 단순해졌다.

에이전트 서비스 설계는 자동화가 아니다.

사람이 하던 판단을 충분히 명시적으로 만들어서, 어디까지 맡기고 어디서 멈출지 정하는 일이다.

그리고 그 판단이 실제 실행에 들어가고, 결과가 다시 돌아와 다음 판단을 바꿀 때, 비로소 서비스는 agentic해진다.