에이전트의 다음 진화는 똑똑한 도구에서 온다
TL;DR
- 도구가 늘수록 메인 에이전트의 판단 부담도 커질 수 있다.
- 나는 전문 도구가 자기 판단과 검증을 맡는 쪽으로 발전할 것이라고 생각한다.
시작하며
요즘 에이전트를 만들거나 사용하는 사람들이 가장 많이 하는 일은 메인 에이전트에 무엇을 더 얹을 것인가다. 스킬을 더 붙이고, 플러그인을 끼우고, MCP 서버를 추가한다. 결국 메인 컨텍스트는 점점 무거워지고, 도구들은 그 컨텍스트가 호출하기 좋은 형태로 깎여 들어간다.
이 그림을 한 발 떨어져서 보면 어디서 본 듯한 모양이 떠오른다. smart pipeline, dumb edge. 모든 지능을 중앙의 파이프라인이 가져가고, 끝단의 도구들은 단순할수록 좋다는 설계 전제. 예전 SOA 시절에 한 번쯤 겪어본 모양과 비슷해 보인다.
1. SOA의 데자뷔: 지금은 smart pipeline, dumb edge
서비스 지향 아키텍처인 SOA(Service-Oriented Architecture)에서 여러 서비스의 통신을 중재하던 ESB(Enterprise Service Bus)가 떠오른다. 라우팅과 변환, 호출 순서와 프로토콜 변환을 중앙의 버스가 책임지고 끝단의 서비스는 단순하게 유지하는 구성이다.
그런데 운영하다 보면 중앙에 책임이 모인 만큼 복잡도도 커진다. 중앙의 처리 능력과 변경 비용이 전체 시스템의 병목이 되기 쉽다.
다른 선택은 중앙에는 메시지 전달을 맡기고, 업무 판단은 메시지를 보내고 받는 서비스에 두는 것이다. 카프카 같은 메시지 인프라를 이런 방식으로 사용할 수 있다. 이것이 내가 여기서 말하는 dumb pipeline, smart edge다. 카프카를 쓴다고 자동으로 책임이 분리되는 것은 아니고, 업무 규칙을 어느 서비스에 둘지 설계해야 한다.
지금의 에이전트 생태계를 보면, 묘하게 그 학습 이전 단계로 돌아가 있는 것 같기도 하다. 메인 에이전트라는 ESB에 모든 도구가 매달려 있는 그림이다.
2. 다음 단계는 dumb pipeline, smart edge
자동화 규모가 커지면 끝단의 도구가 판단을 더 많이 맡는 구조가 유리해질 것이라고 생각한다.
메인 에이전트가 수십 개 도구의 호출 순서와 결과를 일일이 판단한다면, 도구가 늘수록 처리할 문맥도 늘어난다. 중앙의 ESB가 많은 책임을 맡다가 병목이 되는 모습과 비슷하다.
각 도구가 특정 업무에 전문화된 버티컬 에이전트라면 그 업무의 판단과 검증을 맡길 수 있다. 메인 에이전트는 어떤 도구를 호출하고 결과를 어떻게 합칠지에 집중한다.
이를 연산을 기다리는 CPU 바운드에서 외부 작업의 응답을 기다리는 IO 바운드로 옮겨가는 것에 비유할 수 있다. 실제 성능을 측정한 구분은 아니며, 메인 에이전트가 직접 수행할 추론이 줄어든다는 뜻이다.
이렇게 위임하려면 끝단의 도구도 자기 컨텍스트와 검증 체계를 가져야 한다. 다음 행동을 매번 메인 에이전트에게 물어본다면 판단 부담을 나눈 효과가 작아진다.
3. 피지컬 AI에서도 같은 방향
물리적인 환경에서 동작하는 피지컬 AI(physical AI)를 보면서도 비슷한 구성을 상상하게 됐다.
나는 휴머노이드가 주목받는 이유 중 하나가 사람의 동작 데이터와 생활 환경을 활용하기 쉽다는 점이라고 생각한다. 다만 학습에 유리한 형태와 실제 집에서 쓰고 싶은 형태가 같을지는 별개다.
그런데 내가 사는 집을 생각하면 공간부터 걱정된다. 나는 지금 1.5룸에 와이프와 둘이 산다. 둘 다 욕심이 많지 않은 편이라 크게 불편하지는 않지만, 그래도 좁은 건 좁다.
여기에 아무리 좋은 기능을 가진 휴머노이드라도 한 대 더 들어온다면 동선은 둘째치고, 그냥 가만히 서 있기만 해도 숨이 턱 막힐 것 같다.
다만 가전을 지금 모습 그대로 쓴다면, 사람 대신 문을 열고 물건을 옮기고 버튼을 누를 장치가 필요하다. 여러 가전을 조작할 수 있는 휴머노이드가 매력적인 이유도 여기에 있다고 생각한다.
이 그림은 사실상 smart pipeline, dumb edge에 가깝다. 휴머노이드(중앙) + 멍청한 가전들(끝단).
4. smart edge의 집은 다른 모습이다
집의 모든 가전이 API로 제어 가능해지는 시점이 오면, 그림은 꽤 달라질 것 같다.
가전들이 자기 업무를 알아서 처리한다면 중앙의 로봇이 직접 조작할 일도 줄어든다. 어린이 크기에 필요할 때 팔을 늘리는 정도의 로봇으로 필요한 일을 처리할 수 있을지 궁금하다.
여기서 한 걸음 더 나아가서, 집의 가전 자체가 본격적으로 smart edge가 되는 모습을 상상해보자.
- 로봇팔과 각종 레시피·조리법이 내장되어 나오는 주방 어플라이언스
- 옷감을 자동으로 인식해서 세탁부터 건조, 빨래 접기까지 처리하는 로봇팔이 달린 세탁건조기
- 냉장고가 식재료를 직접 추적하고, 부족한 것은 알아서 발주를 넣는 형태
이 가정에서는 집 안의 오케스트레이터가 빨래를 세탁건조기에서 옷장으로 옮기고, 주방에서 만든 음식을 식탁으로 옮기는 일을 맡는다. 조리나 세탁의 세부 판단은 가전이 처리한다.
집에서는 사람이 일부 일을 맡는 선택도 괜찮다고 생각한다. 업무 자동화에서는 사람의 반복 개입을 제거하는 방향에 관심이 있지만1, 집에서는 내가 편하게 생활하는 것이 목적이기 때문이다.
내 집에서는 작은 로봇과 똑똑한 가전의 조합을 먼저 고려하고 싶다. 사람 크기의 로봇 한 대가 얼마나 많은 일을 해주는지만큼, 매일 차지하는 공간과 동선도 중요하기 때문이다.
5. SaaS 회사들의 자리: headless SaaS
소프트웨어에서도 도메인별 도구가 판단을 맡게 된다면 SaaS 회사가 제공하는 가치가 달라질 수 있다.
사용자가 SaaS의 화면에서 업무를 시작하고 끝낸다면 UI와 워크플로우가 중요하다. 메인 에이전트가 여러 SaaS를 호출해 업무를 처리한다면, 각 서비스는 화면 밖에서도 자기 기능을 제공해야 한다.
메인 에이전트가 여러 서비스를 조합하는 역할을 맡는다면, SaaS 회사는 자기 도메인에 특화된 smart edge를 제공하는 데 집중할 수 있다. 사용자가 직접 화면을 조작하지 않아도 메인 에이전트가 기능을 호출하는 headless SaaS 형태다.
나는 여러 도구를 조율하는 부분과 함께, 호출받은 업무를 스스로 처리하고 검증하는 전문 도구를 만드는 데도 관심이 있다. 특정 업무의 규칙과 예외를 잘 다루는 서비스라면 메인 에이전트가 반복해서 선택하는 도구가 될 수 있다. 위에서 상상한 스마트 가전과 비슷한 역할이다.
6. 개발자 입장에서: 도메인 지식과 Forward Deployed Engineer
개발자로서 내가 관심을 두는 일도 자기 도메인의 smart edge를 만드는 일이다.
같은 모델과 비슷한 오케스트레이션 도구를 쓴다면, 어떤 업무를 어디까지 맡길 수 있는지가 차이를 만들 것이라고 생각한다. 도메인의 규칙과 예외를 코드와 도구, 검증에 옮기는 능력이 필요한 이유다.
고객의 현장에 들어가 문제를 해결하는 AI Deployment Engineer나 Forward Deployed Engineer 역할에도 관심이 간다. 모델을 고객의 데이터와 업무에 연결하고, 그 업무를 끝낼 수 있는 도구로 만드는 일과 맞닿아 있기 때문이다.
마치며
SOA에서 카프카로 넘어가며 중앙이 맡던 책임을 나눴던 경험 때문에, 에이전트에서도 전문 도구가 자기 판단과 검증을 맡는 쪽에 관심이 간다.
어느 정도 규모에서 이 구조가 더 나을지는 실제 업무로 확인해야 한다. 그래도 개발자로서는 메인 에이전트에 지시를 더 얹는 일과 함께, 내가 아는 업무를 스스로 끝낼 수 있는 도구로 만드는 일에 시간을 쓰고 싶다.