AI 서비스와 AI 에이전트는 다르다 — 호출에서 무인 에이전트까지, 자율성의 나선

AI를 활용한 서비스를 만드는 것과 AI 에이전트를 만드는 것은 다른 일이다. 구분 기준은 제어 흐름을 누가 쥐는가이며, 둘 사이는 6단계 자율성 스펙트럼으로 이어진다. 그리고 완성된 에이전트를 고객에게 제공하는 순간 스펙트럼은 다시 처음으로 감긴다 — 이 글은 그 나선 구조와, 고리를 닫는 조건인 신뢰를 정리한다.

핵심 요약

• “AI 서비스”와 “AI 에이전트”의 구분 기준은 제어 흐름을 누가 쥐는가 — 코드가 AI를 호출하면 서비스, AI가 도구를 호출하면 에이전트
• 한 줄 정의: 서비스는 AI에게 대답을 시키는 것, 에이전트는 AI에게 일을 맡기는 것
• 둘 사이는 단절이 아니라 6단계 자율성 스펙트럼: 모델 호출 → RAG → 챗봇 → 도구 쓰는 챗봇 → 에이전트 → 무인 에이전트
• 에이전트를 고객에게 제공하는 순간 그것은 소비자 관점에서 다시 “호출”이 된다 — 스펙트럼은 직선이 아니라 나선
• 그 고리는 저절로 닫히지 않는다. 루프가 사람 없이 완결될 만큼 신뢰될 때에야 에이전트는 함수가 된다

같은 단어, 다른 물건

고객 미팅에서 자주 벌어지는 장면이 있다. 한쪽은 “우리도 AI 에이전트를 도입했어요”라고 말하는데, 들어 보면 문서 요약 API를 붙인 웹 서비스다. 다른 쪽은 “챗봇을 만들려고요”라고 말하는데, 요구사항을 들어 보면 사내 시스템을 조작하고 결재까지 올리는 자율 에이전트다. 단어가 섞여 쓰이니 견적도, 아키텍처도, 위험 평가도 어긋난다.

이 혼동은 단어의 문제가 아니라 구분 기준이 없어서 생긴다. 기준은 하나면 충분하다.

구분 기준: 제어 흐름을 누가 쥐는가

AI를 활용하는 서비스에서는 개발자가 짠 코드가 흐름을 쥔다. 요청이 오면 내 코드가 돌고, 정해진 지점에서 모델을 호출하고, 응답을 조립해 돌려준다. AI는 그 흐름 속에서 호출당하는 부품이다. 언제, 몇 번 호출될지는 전부 코드에 적혀 있다. 3티어 아키텍처 위에 추론 API를 얹은 대부분의 “AI 기능”이 여기에 속한다.

AI 에이전트에서는 목표를 주면 AI가 다음 행동을 스스로 결정한다. 모델이 도구를 호출하고, 결과를 관찰하고, 다시 판단하는 루프를 돈다. 코드(런타임)가 하는 일은 흐름을 짜는 게 아니라 도구·권한·경계를 제공하고 감독하는 것이다. 여기서 AI는 부품이 아니라 작업자다.

한 줄로 줄이면 — 서비스는 AI에게 대답을 시키는 것이고, 에이전트는 AI에게 일을 맡기는 것이다. 앞은 AI가 호출당하는 쪽이고, 뒤는 AI가 호출하는 쪽이다.

실패 모드의 차이가 특히 중요하다. 서비스의 실패는 나쁜 답변이지만, 에이전트의 실패는 나쁜 행동이다. 파일을 지우고, 잘못된 메일을 보내고, 엉뚱한 곳에 결과를 쓴다. 에이전트 설계에서 승인(approval)과 감사 이력(audit trail)이 아키텍처의 중심이 되는 이유다.

자율성의 스펙트럼: 여섯 단계

현실의 시스템은 이분법으로 깔끔하게 나뉘지 않는다. 특히 챗봇이 중간에 있다 — 서비스처럼 배포되는데 대화형이라 에이전트처럼 보인다. 그래서 이분법 대신 자율성이 올라가는 스펙트럼으로 보는 것이 정확하다.

1. 모델 호출 — 코드가 정해진 지점에서 모델을 부른다. 요약 버튼, 분류 API.
2. RAG — 호출에 검색이 붙는다. 등록된 문서를 근거로 답하게 한다.
3. 챗봇 — 대화 상태가 생긴다. 여전히 읽고 답할 뿐, 세상을 바꾸지 않는다.
4. 도구 쓰는 챗봇 — MCP 같은 도구 연결로 조회·실행 능력이 붙는다. 단 어떤 도구를 언제 쓸지는 아직 좁은 범위다.
5. 에이전트 — 목표를 받아 여러 단계를 스스로 계획하고, 도구 호출 루프를 돌며, 중간에 사람의 승인을 받는다.
6. 무인 에이전트 — 스케줄이나 트리거로 사람 없는 시각에 실행된다. 실패도 사람 없는 곳에서 일어난다.

어디부터 “에이전트”라고 부를 수 있는가? 세 가지 판별 질문이 유용하다.

• 세상에 작용하는가 — 읽고 답하기만 하는가, 파일과 시스템을 바꾸는가
• 여러 단계를 스스로 계획하는가 — 흐름이 코드에 적혀 있는가, 모델이 만드는가
• 사람 없이 진행되는 구간이 있는가

셋 다 “예”라면 확실한 에이전트이고, 그만큼의 통제 장치(권한 경계, 승인 지점, 실행 이력)가 설계에 들어가야 한다.

반전: 에이전트를 제공하는 순간, 다시 호출이 된다

여기서 흥미로운 반전이 있다. 완성된 에이전트를 API로 감싸 고객에게 제공하면 어떻게 되는가?

고객의 코드 입장에서 그것은 그냥 호출이다. 요청을 보내고 결과를 받는 함수. 안에서 루프가 몇 번 돌았는지, 도구를 몇 개 썼는지는 경계 뒤에 숨는다. 스펙트럼의 끝(무인 에이전트)이 다음 층의 처음(호출)으로 감기는 것이다.

즉 스펙트럼은 직선이 아니라 나선이고, “에이전트인가 호출인가”는 시스템의 절대 속성이 아니라 어느 경계에서 보느냐의 속성이다. 한 층의 에이전트는 윗층의 함수다. 에이전트가 서브에이전트를 부하 작업자로 띄우는 구조에서도 같은 일이 일어난다 — 서브에이전트 자신은 루프를 도는 에이전트지만, 부모 에이전트 입장에서는 도구 호출 하나다.

같은 물건이 관점에 따라 세 가지로 불린다. 쓰는 사람에게는 호출이고, 만드는 사람에게는 에이전트이고, 운영하는 사람에게는 직원이다.

호출로 감쌌다고 호출이 되는 것은 아니다

단, 인터페이스가 함수라고 해서 성질까지 함수가 되지는 않는다. 안이 에이전트면 경계 밖으로 새는 속성들이 있다.

• 비결정성 — 같은 입력에 다른 경로, 때로 다른 결과
• 가변 지연시간과 비용 — 루프가 몇 번 도느냐에 따라 널뛴다
• 부분 실패 — “3개 중 2개는 성공”이라는, 일반 API에 없는 실패 모드
• 감사 요구 — “왜 그렇게 했는가”에 답할 실행 이력이 필요하다

에이전트를 서비스로 제공하는 순간 전통적인 서비스 설계 문제(SLA, 비용, 스케일)가 전부 돌아오는데, 그 난이도는 일반 모델 호출보다 훨씬 높다. “에이전트를 호출로 판다”는 것은 인터페이스의 단순화이지, 운영의 단순화가 아니다.

고리를 닫는 것은 신뢰다

마지막 단서가 이 글의 결론이다. 스펙트럼이 처음으로 감기려면 조건이 있다.

사람의 승인이 중간에 필요한 에이전트는 순수한 요청-응답으로 감쌀 수 없다. “사람에게 묻는 순간”이 인터페이스 밖으로 튀어나와야 하므로, 단순 호출이 아니라 세션·웹훅·알림 같은 구조가 필요해진다. 루프가 사람 없이 완결될 만큼 신뢰될 때에야, 에이전트는 함수가 된다.

그리고 그 신뢰는 선언으로 얻어지지 않는다. 권한 경계를 정확히 긋고, 승인 지점을 설계하고, 실행 이력을 확인하는 운영을 반복해서 쌓는 것이다. 에이전트 교육이 “만드는 법”만큼 “멈추는 지점과 확인하는 습관”을 다뤄야 하는 이유이기도 하다.

도입 담당자를 위한 체크리스트

“AI 도입”을 논의할 때, 단어 대신 이 질문들로 시작하면 혼동이 줄어든다.

1. 이 시스템에서 제어 흐름은 누가 쥐는가 — 우리 코드인가, 모델인가?
2. AI가 세상에 작용하는가 — 읽고 답하는가, 바꾸는가?
3. 사람 없이 진행되는 구간이 있는가 — 있다면 실패는 누가, 언제, 어디서 발견하는가?
4. 지금 논의 중인 관점은 누구의 경계인가 — 쓰는 쪽인가, 만드는 쪽인가, 운영하는 쪽인가?
5. 이 에이전트를 “함수”로 취급해도 될 만큼의 신뢰가 쌓였는가 — 그 근거는 실행 이력인가, 데모인가?