<div id="readability-page-1" class="page"><div>
 <h2>에이전트의 다음 진화는 똑똑한 도구에서 온다</h2>
 
 2026년 05월 27일 작성<h2 id="tldr">TL;DR</h2>

<ul>
 <li>지금의 smart pipeline, dumb edge 구조는 SOA가 그랬듯 점차 한계에 닿을 수 있고, 도구 자체가 똑똑해지는 dumb pipeline, smart edge 쪽으로 흐름이 옮겨가지 않을까 싶다.</li>
</ul>

<h2 id="시작하며">시작하며</h2>

요즘 에이전트를 만들거나 사용하는 사람들이 가장 많이 하는 일은 메인 에이전트에 무엇을 더 얹을 것인가다. 스킬을 더 붙이고, 플러그인을 끼우고, MCP 서버를 추가한다. 결국 메인 컨텍스트는 점점 무거워지고, 도구들은 그 컨텍스트가 호출하기 좋은 형태로 깎여 들어간다.

이 그림을 한 발 떨어져서 보면 어디서 본 듯한 모양이 떠오른다. smart pipeline, dumb edge. 모든 지능을 중앙의 파이프라인이 가져가고, 끝단의 도구들은 단순할수록 좋다는 설계 전제. 예전 SOA 시절에 한 번쯤 겪어본 모양과 비슷해 보인다.

<h2 id="1-soa의-데자뷔-지금은-smart-pipeline-dumb-edge">1. SOA의 데자뷔: 지금은 smart pipeline, dumb edge</h2>

SOA(Service-Oriented Architecture) 시절의 ESB(Enterprise Service Bus)를 기억하는 사람이라면 비슷한 감각을 느낄지도 모르겠다. 모든 라우팅, 변환, 오케스트레이션, 프로토콜 매개를 중앙의 버스가 책임지고, 끝단의 서비스들은 가능한 한 얇고 단순하게 유지된다. 이론적으로는 깔끔하다. 그런데 실제로 운영해보면 결국 같은 문제로 돌아가곤 했다. 중앙이 모든 책임을 끌어안는 순간, 그 중앙이 곧 시스템 전체의 복잡도이자 병목이 되기 쉽다.

그래서 업계는 점차 다른 방향으로 옮겨갔다. 카프카 같은 메시지 인프라가 대표적인 예시다. 파이프라인은 의도적으로 단순해지고(dumb pipeline), 도메인 지식과 의사결정은 양쪽 끝의 프로듀서/컨슈머로 밀려난다(smart edge). 중앙이 똑똑하지 않아도 시스템 전체는 똑똑하게 동작할 수 있다는 것을, 한 번쯤 경험해본 흐름이다.

지금의 에이전트 생태계를 보면, 묘하게 그 학습 이전 단계로 돌아가 있는 것 같기도 하다. 메인 에이전트라는 ESB에 모든 도구가 매달려 있는 그림이다.

<h2 id="2-다음-단계는-dumb-pipeline-smart-edge">2. 다음 단계는 dumb pipeline, smart edge</h2>

에이전틱 엔지니어링이 좀 더 성숙해지고, 본격적인 대규모 자동화 단계로 넘어가는 시점이 오면 이 구조는 자연스럽게 뒤집힐 수도 있지 않을까 싶다.

지금처럼 메인 에이전트 한 명이 수십 개의 dumb한 도구를 일일이 챙겨야 한다면, 메인 에이전트의 컨텍스트와 추론 능력이 곧 시스템 전체의 상한이 되기 쉬워 보인다. 도구가 늘어날수록 메인 에이전트의 컨텍스트는 무거워지고, 추론은 느려지고, 처리량도 점차 한계에 가까워질 것 같다. ESB가 커질수록 ESB 자체가 시스템의 병목이 되어가던 곡선과 비슷한 모양이 그려지지 않을까.

반면 각 도구 자체가 정교하게 설계된 버티컬한 에이전트라면 그림은 꽤 달라질 수 있다. 메인 에이전트는 오케스트레이션에만 집중해도 되는 셈이다. 상대적으로 dumb해도 된다는 말은 메인 에이전트가 멍청해진다는 뜻이라기보다는, CPU 바운드에서 IO 바운드로 옮겨간다는 뉘앙스에 가깝다. 무거운 추론을 끝단의 전문 에이전트들이 분산해서 처리하는 동안, 메인 에이전트는 누구를 언제 호출하고 결과를 어떻게 합칠지에 집중하는 식. 처리량은 그렇게 한 단계 점프할 여지가 있어 보인다.

이 그림이 그럴듯하게 굴러가려면 끝단의 도구가 지금처럼 “메인 에이전트가 호출하기 편하게 깎여나간 함수 덩어리” 형태로는 부족할 것 같다. 끝단이 자기 도메인 안에서 스스로 판단할 수 있는 에이전트에 가까워야 그림이 맞아 들어간다. 자기 컨텍스트를 자기가 관리하고, 자기 검증을 자기가 하고, 메인 에이전트의 지능에 기대지 않는 도구들. 앞으로 버티컬한 에이전트 기반의 도구들이 점차 늘어나지 않을까 싶은 이유다.

<h2 id="3-피지컬-ai에서도-같은-방향">3. 피지컬 AI에서도 같은 방향</h2>

이 관점은 피지컬 AI(physical AI)에도 비슷하게 옮겨놓을 수 있을 것 같다.

지금의 로봇 산업이 휴머노이드라는 형태로 수렴하고 있는 큰 이유 중 하나는, 데이터 확보의 용이성이라고 본다. 사람의 동작 데이터가 가장 많고, 사람을 위해 만들어진 환경에 가장 잘 맞는 형태가 휴머노이드라서 그렇다. 휴머노이드가 모든 곳에 가장 효과적인 형태라기보다는, 지금 시점에서 가장 학습시키기 쉬운 형태에 가까운 듯하다.

그런데 인구가 줄고 도심화가 진행될수록 빠르게 가치가 오를 자산은 아마 공간이지 않을까 싶다. 나는 지금 1.5룸에 와이프와 둘이 산다. 둘 다 욕심이 많지 않은 편이라 크게 불편하지는 않지만, 그래도 좁은 건 좁다. 여기에 아무리 좋은 기능을 가진 휴머노이드라도 한 대 더 들어온다면 동선은 둘째치고, 그냥 가만히 서 있기만 해도 숨이 턱 막힐 것 같다. 휴머노이드는 본질적으로 공간과 동선을 꽤 차지하는 폼팩터다.

그럼에도 휴머노이드가 매력적으로 보이는 이유는 비교적 분명해 보인다. 집의 모든 도구가 너무나 dumb하기 때문이다. 냉장고는 음식을 보관할 뿐이고, 세탁기는 빨래만 돌릴 뿐이며, 가스레인지는 불만 켤 뿐이다. dumb한 끝단을 그대로 두고 집을 스마트하게 만들려면, 결국 모든 도구를 사람 대신 조작해줄 수 있는 범용 액추에이터 같은 것이 필요해질 가능성이 크다. 그것의 가장 익숙한 형태가 휴머노이드인 셈이다.

이 그림은 사실상 smart pipeline, dumb edge에 가깝다. 휴머노이드(중앙) + 멍청한 가전들(끝단).

<h2 id="4-smart-edge의-집은-다른-모습이다">4. smart edge의 집은 다른 모습이다</h2>

집의 모든 가전이 API로 제어 가능해지는 시점이 오면, 그림은 꽤 달라질 것 같다.

성인만한 휴머노이드가 굳이 필요하지 않을 수도 있다. 가전들이 자기 도메인 안에서 알아서 동작한다면, 중앙의 로봇이 굳이 사람 흉내를 내며 모든 일을 대신해야 할 이유가 줄어든다. 적당한 어린이 크기의 로봇, 팔이 가끔 늘어나는 정도의 폼팩터면 충분할지도 모른다. 동선을 거의 차지하지 않으면서도 필요한 일은 어느 정도 처리할 수 있는 그림이다.

여기서 한 걸음 더 나아가서, 집의 가전 자체가 본격적으로 smart edge가 되는 모습을 상상해보자.

<ul>
 <li>로봇팔과 각종 레시피·조리법이 내장되어 나오는 주방 어플라이언스</li>
 <li>옷감을 자동으로 인식해서 세탁부터 건조, 빨래 접기까지 처리하는 로봇팔이 달린 세탁건조기</li>
 <li>냉장고가 식재료를 직접 추적하고, 부족한 것은 알아서 발주를 넣는 형태</li>
</ul>

이렇게 되면 집 안의 오케스트레이터가 할 일은 각 스마트 엣지의 결과물을 사람에게 연결해주는 정도로 줄어들지 않을까 싶다. 빨래를 세탁건조기에서 옷장까지 옮기고, 주방에서 만들어진 음식을 식탁까지 옮기는 정도. 사람이 직접 돌아다니는 것보다 조금 편한 정도면 그것대로 충분할 수도 있다.

업무 자동화와 다른 점이 한 가지 있을 것 같다. 집은 사람이 사는 곳이라는 점이다. 업무 영역에서 에이전틱 엔지니어링의 방향은 결국 human in the loop의 제거<a href="#fn:1" rel="footnote">1</a> 쪽으로 향하는 분위기지만, 집에서는 굳이 그럴 필요가 없어 보인다. 사람이 그 공간에 있고, 사람이 결과물을 누리는 주체이기 때문이다.

스마트 엣지들의 결과를 취합하러 돌아다니는 정도의 일이라면, 휴머노이드 한 대가 동선을 가로막으며 모든 일을 대신하는 그림과 트레이드 오프해볼 만하지 않을까 싶다. 좁은 공간을 양보하고 사람 사이즈의 로봇을 들이는 대신, 작은 오케스트레이터와 똑똑한 가전들로 채우는 쪽. 같은 자동화를 다른 공간 비용으로 사는 셈이다.

<h2 id="5-saas-회사들의-자리-headless-saas">5. SaaS 회사들의 자리: headless SaaS</h2>

이 흐름을 다시 소프트웨어 쪽으로 가져오면, SaaS 회사들의 포지셔닝에도 영향이 갈 수 있을 것 같다.

지금까지 SaaS는 자기 도메인 안에서 UI, 워크플로우, 통합, 자동화까지 한 번에 가져가는 모델에 가까웠다. 사용자가 그 SaaS의 화면 안에서 일을 시작해서 끝내도록 만드는 것이 가치였다. 그런데 오케스트레이션의 중심이 사람의 화면이 아니라 메인 에이전트 쪽으로 옮겨가게 된다면, 그 가치 구조도 같이 흔들리지 않을까 싶다.

오케스트레이션 자체는 메인 에이전트(또는 그것을 만드는 소수의 플랫폼 회사)들이 가져가는 그림이 그려진다. 그 위에서 각 SaaS 회사가 의미 있는 자리를 잡으려면, 자기 도메인에 특화된 smart edge가 되는 쪽이 자연스러운 방향이 되지 않을까. 즉 headless SaaS — UI를 들고 사용자 시간을 빼앗는 회사라기보다는, 자기 도메인 안에서 정교하게 동작하는 에이전트형 도구를 메인 에이전트에 공급하는 회사 쪽으로의 이동이다.

오케스트레이션 자체보다, 오케스트레이션이 호출했을 때 진짜로 똑똑하게 일을 해내는 도메인 특화 도구를 만드는 데 집중하는 방향. 한 영역에서 가장 깊은 컨텍스트와 가장 정교한 하네스를 가진 에이전트가 그 도메인의 기본값으로 자리 잡을 수도 있다. 위에서 본 스마트 가전과 비슷한 결의 그림이다.

<h2 id="6-개발자-입장에서-도메인-지식과-forward-deployed-engineer">6. 개발자 입장에서: 도메인 지식과 Forward Deployed Engineer</h2>

이 흐름을 개발자 입장에서 다시 보면, 앞으로 할 일은 결국 자기 도메인의 smart edge를 만드는 일에 가까워지지 않을까 싶다.

모델은 누구나 같은 걸 쓰게 되고, 오케스트레이션 레이어도 점점 평준화될 가능성이 높다. 결국 마지막에 차이를 만드는 부분은 그 도메인을 얼마나 깊이 이해하고 있느냐, 그 이해를 코드와 도구로 얼마나 정교하게 옮겨놓을 수 있느냐에 모일 것 같다. smart edge의 깊이는 결국 도메인 지식에서 나오기 때문이다.

이런 관점에서 보면, 최근 AI 회사들이 AI Deployment Engineer나 Forward Deployed Engineer 같은 롤을 비중 있게 뽑고 있는 것도 꽤 자연스러운 흐름으로 읽힌다. 모델 자체를 더 좋게 만드는 일도 중요하지만, 그 모델을 고객의 도메인 안으로 깊이 들고 들어가서 그 도메인의 smart edge로 빚어내는 사람의 가치가 같이 커지고 있다는 신호로 볼 수 있다. 일반화된 모델 한 개와 도메인이 만나는 지점에서, 그 도메인을 가장 잘 아는 엔지니어가 가장 큰 레버리지를 갖는 시점이 다가오고 있는 셈이다.

<h2 id="마치며">마치며</h2>

지금은 smart pipeline, dumb edge에 가까운 시대 같다. 메인 에이전트가 모든 지능을 짊어지고 있고, 도구들은 그 메인 에이전트의 호출 편의에 맞춰 깎여 있는 형태다. SOA가 그랬던 것처럼, 이 구조도 일정 규모 이상으로 넘어가면 중앙 자체가 병목이 될 수 있지 않을까 싶다.

그래서 다음 단계는 dumb pipeline, smart edge 쪽으로 흐를 가능성이 있어 보인다. 메인 에이전트는 오케스트레이션에 집중하면서 IO 바운드로 가볍게 유지되고, 끝단의 도구들이 각자의 도메인에서 자기 지능을 가지고 일하는 그림. 소프트웨어에서는 버티컬 에이전트와 headless SaaS의 형태로, 피지컬 AI에서는 작은 오케스트레이터와 스마트 가전의 형태로 비슷한 방향을 그릴 수 있을 것 같다.

휴머노이드 한 대로 dumb한 집을 보완하는 그림과, 집 안의 모든 것이 스마트해지면서 작은 오케스트레이터만 남는 그림 중 어느 쪽이 더 자연스러울지는 결국 시간이 답해줄 일이다. 다만 SOA에서 카프카로 한 번 넘어가본 입장에서 보면, 그 답이 어느 쪽으로 기울지 어렴풋이 짐작이 가는 정도이지 않을까 싶다.

<hr>



</div></div>

Haandol

TL;DR
지금의 smart pipeline, dumb edge 구조는 SOA가 그랬듯 점차 한계에 닿을 수 있고, 도구 자체가 똑똑해지는 dumb pipeline, smart edge 쪽으로 흐름이 옮겨가지 않을까 싶다.
시작하며
요즘 에이전트를 만들거나 사용하는 사람들이 가장 많이 하는 일은 메인 에이전트에 무엇을 더 얹을 것인가다. 스킬을 더 붙이고, 플러그인을 끼우고, 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
에이전틱 엔지니어링이 좀 더 성숙해지고, 본격적인 대규모 자동화 단계로 넘어가는 시점이 오면 이 구조는 자연스럽게 뒤집힐 수도 있지 않을까 싶다.
지금처럼 메인 에이전트 한 명이 수십 개의 dumb한 도구를 일일이 챙겨야 한다면, 메인 에이전트의 컨텍스트와 추론 능력이 곧 시스템 전체의 상한이 되기 쉬워 보인다. 도구가 늘어날수록 메인 에이전트의 컨텍스트는 무거워지고, 추론은 느려지고, 처리량도 점차 한계에 가까워질 것 같다. ESB가 커질수록 ESB 자체가 시스템의 병목이 되어가던 곡선과 비슷한 모양이 그려지지 않을까.
반면 각 도구 자체가 정교하게 설계된 버티컬한 에이전트라면 그림은 꽤 달라질 수 있다. 메인 에이전트는 오케스트레이션에만 집중해도 되는 셈이다. 상대적으로 dumb해도 된다는 말은 메인 에이전트가 멍청해진다는 뜻이라기보다는, CPU 바운드에서 IO 바운드로 옮겨간다는 뉘앙스에 가깝다. 무거운 추론을 끝단의 전문 에이전트들이 분산해서 처리하는 동안, 메인 에이전트는 누구를 언제 호출하고 결과를 어떻게 합칠지에 집중하는 식. 처리량은 그렇게 한 단계 점프할 여지가 있어 보인다.
이 그림이 그럴듯하게 굴러가려면 끝단의 도구가 지금처럼 “메인 에이전트가 호출하기 편하게 깎여나간 함수 덩어리” 형태로는 부족할 것 같다. 끝단이 자기 도메인 안에서 스스로 판단할 수 있는 에이전트에 가까워야 그림이 맞아 들어간다. 자기 컨텍스트를 자기가 관리하고, 자기 검증을 자기가 하고, 메인 에이전트의 지능에 기대지 않는 도구들. 앞으로 버티컬한 에이전트 기반의 도구들이 점차 늘어나지 않을까 싶은 이유다.
3. 피지컬 AI에서도 같은 방향
이 관점은 피지컬 AI(physical AI)에도 비슷하게 옮겨놓을 수 있을 것 같다.
지금의 로봇 산업이 휴머노이드라는 형태로 수렴하고 있는 큰 이유 중 하나는, 데이터 확보의 용이성이라고 본다. 사람의 동작 데이터가 가장 많고, 사람을 위해 만들어진 환경에 가장 잘 맞는 형태가 휴머노이드라서 그렇다. 휴머노이드가 모든 곳에 가장 효과적인 형태라기보다는, 지금 시점에서 가장 학습시키기 쉬운 형태에 가까운 듯하다.
그런데 인구가 줄고 도심화가 진행될수록 빠르게 가치가 오를 자산은 아마 공간이지 않을까 싶다. 나는 지금 1.5룸에 와이프와 둘이 산다. 둘 다 욕심이 많지 않은 편이라 크게 불편하지는 않지만, 그래도 좁은 건 좁다. 여기에 아무리 좋은 기능을 가진 휴머노이드라도 한 대 더 들어온다면 동선은 둘째치고, 그냥 가만히 서 있기만 해도 숨이 턱 막힐 것 같다. 휴머노이드는 본질적으로 공간과 동선을 꽤 차지하는 폼팩터다.
그럼에도 휴머노이드가 매력적으로 보이는 이유는 비교적 분명해 보인다. 집의 모든 도구가 너무나 dumb하기 때문이다. 냉장고는 음식을 보관할 뿐이고, 세탁기는 빨래만 돌릴 뿐이며, 가스레인지는 불만 켤 뿐이다. dumb한 끝단을 그대로 두고 집을 스마트하게 만들려면, 결국 모든 도구를 사람 대신 조작해줄 수 있는 범용 액추에이터 같은 것이 필요해질 가능성이 크다. 그것의 가장 익숙한 형태가 휴머노이드인 셈이다.
이 그림은 사실상 smart pipeline, dumb edge에 가깝다. 휴머노이드(중앙) + 멍청한 가전들(끝단).
4. smart edge의 집은 다른 모습이다
집의 모든 가전이 API로 제어 가능해지는 시점이 오면, 그림은 꽤 달라질 것 같다.
성인만한 휴머노이드가 굳이 필요하지 않을 수도 있다. 가전들이 자기 도메인 안에서 알아서 동작한다면, 중앙의 로봇이 굳이 사람 흉내를 내며 모든 일을 대신해야 할 이유가 줄어든다. 적당한 어린이 크기의 로봇, 팔이 가끔 늘어나는 정도의 폼팩터면 충분할지도 모른다. 동선을 거의 차지하지 않으면서도 필요한 일은 어느 정도 처리할 수 있는 그림이다.
여기서 한 걸음 더 나아가서, 집의 가전 자체가 본격적으로 smart edge가 되는 모습을 상상해보자.
로봇팔과 각종 레시피·조리법이 내장되어 나오는 주방 어플라이언스
옷감을 자동으로 인식해서 세탁부터 건조, 빨래 접기까지 처리하는 로봇팔이 달린 세탁건조기
냉장고가 식재료를 직접 추적하고, 부족한 것은 알아서 발주를 넣는 형태
이렇게 되면 집 안의 오케스트레이터가 할 일은 각 스마트 엣지의 결과물을 사람에게 연결해주는 정도로 줄어들지 않을까 싶다. 빨래를 세탁건조기에서 옷장까지 옮기고, 주방에서 만들어진 음식을 식탁까지 옮기는 정도. 사람이 직접 돌아다니는 것보다 조금 편한 정도면 그것대로 충분할 수도 있다.
업무 자동화와 다른 점이 한 가지 있을 것 같다. 집은 사람이 사는 곳이라는 점이다. 업무 영역에서 에이전틱 엔지니어링의 방향은 결국 human in the loop의 제거1 쪽으로 향하는 분위기지만, 집에서는 굳이 그럴 필요가 없어 보인다. 사람이 그 공간에 있고, 사람이 결과물을 누리는 주체이기 때문이다.
스마트 엣지들의 결과를 취합하러 돌아다니는 정도의 일이라면, 휴머노이드 한 대가 동선을 가로막으며 모든 일을 대신하는 그림과 트레이드 오프해볼 만하지 않을까 싶다. 좁은 공간을 양보하고 사람 사이즈의 로봇을 들이는 대신, 작은 오케스트레이터와 똑똑한 가전들로 채우는 쪽. 같은 자동화를 다른 공간 비용으로 사는 셈이다.
5. SaaS 회사들의 자리: headless SaaS
이 흐름을 다시 소프트웨어 쪽으로 가져오면, SaaS 회사들의 포지셔닝에도 영향이 갈 수 있을 것 같다.
지금까지 SaaS는 자기 도메인 안에서 UI, 워크플로우, 통합, 자동화까지 한 번에 가져가는 모델에 가까웠다. 사용자가 그 SaaS의 화면 안에서 일을 시작해서 끝내도록 만드는 것이 가치였다. 그런데 오케스트레이션의 중심이 사람의 화면이 아니라 메인 에이전트 쪽으로 옮겨가게 된다면, 그 가치 구조도 같이 흔들리지 않을까 싶다.
오케스트레이션 자체는 메인 에이전트(또는 그것을 만드는 소수의 플랫폼 회사)들이 가져가는 그림이 그려진다. 그 위에서 각 SaaS 회사가 의미 있는 자리를 잡으려면, 자기 도메인에 특화된 smart edge가 되는 쪽이 자연스러운 방향이 되지 않을까. 즉 headless SaaS — UI를 들고 사용자 시간을 빼앗는 회사라기보다는, 자기 도메인 안에서 정교하게 동작하는 에이전트형 도구를 메인 에이전트에 공급하는 회사 쪽으로의 이동이다.
오케스트레이션 자체보다, 오케스트레이션이 호출했을 때 진짜로 똑똑하게 일을 해내는 도메인 특화 도구를 만드는 데 집중하는 방향. 한 영역에서 가장 깊은 컨텍스트와 가장 정교한 하네스를 가진 에이전트가 그 도메인의 기본값으로 자리 잡을 수도 있다. 위에서 본 스마트 가전과 비슷한 결의 그림이다.
6. 개발자 입장에서: 도메인 지식과 Forward Deployed Engineer
이 흐름을 개발자 입장에서 다시 보면, 앞으로 할 일은 결국 자기 도메인의 smart edge를 만드는 일에 가까워지지 않을까 싶다.
모델은 누구나 같은 걸 쓰게 되고, 오케스트레이션 레이어도 점점 평준화될 가능성이 높다. 결국 마지막에 차이를 만드는 부분은 그 도메인을 얼마나 깊이 이해하고 있느냐, 그 이해를 코드와 도구로 얼마나 정교하게 옮겨놓을 수 있느냐에 모일 것 같다. smart edge의 깊이는 결국 도메인 지식에서 나오기 때문이다.
이런 관점에서 보면, 최근 AI 회사들이 AI Deployment Engineer나 Forward Deployed Engineer 같은 롤을 비중 있게 뽑고 있는 것도 꽤 자연스러운 흐름으로 읽힌다. 모델 자체를 더 좋게 만드는 일도 중요하지만, 그 모델을 고객의 도메인 안으로 깊이 들고 들어가서 그 도메인의 smart edge로 빚어내는 사람의 가치가 같이 커지고 있다는 신호로 볼 수 있다. 일반화된 모델 한 개와 도메인이 만나는 지점에서, 그 도메인을 가장 잘 아는 엔지니어가 가장 큰 레버리지를 갖는 시점이 다가오고 있는 셈이다.
마치며
지금은 smart pipeline, dumb edge에 가까운 시대 같다. 메인 에이전트가 모든 지능을 짊어지고 있고, 도구들은 그 메인 에이전트의 호출 편의에 맞춰 깎여 있는 형태다. SOA가 그랬던 것처럼, 이 구조도 일정 규모 이상으로 넘어가면 중앙 자체가 병목이 될 수 있지 않을까 싶다.
그래서 다음 단계는 dumb pipeline, smart edge 쪽으로 흐를 가능성이 있어 보인다. 메인 에이전트는 오케스트레이션에 집중하면서 IO 바운드로 가볍게 유지되고, 끝단의 도구들이 각자의 도메인에서 자기 지능을 가지고 일하는 그림. 소프트웨어에서는 버티컬 에이전트와 headless SaaS의 형태로, 피지컬 AI에서는 작은 오케스트레이터와 스마트 가전의 형태로 비슷한 방향을 그릴 수 있을 것 같다.
휴머노이드 한 대로 dumb한 집을 보완하는 그림과, 집 안의 모든 것이 스마트해지면서 작은 오케스트레이터만 남는 그림 중 어느 쪽이 더 자연스러울지는 결국 시간이 답해줄 일이다. 다만 SOA에서 카프카로 한 번 넘어가본 입장에서 보면, 그 답이 어느 쪽으로 기울지 어렴풋이 짐작이 가는 정도이지 않을까 싶다.
에이전틱 엔지니어링과 과도기적 기술들 ↩

에이전트의 다음 진화는 똑똑한 도구에서 온다

댓글