에이전트는 작업실에 있지, 제품 안에는 없다
에이전트는 점점 더 똑똑해지고 있어요.
그런데 제가 지금까지 실제로 출시한 것들을 돌아보면, 솔직히 인정할 게 하나 있어요. 저는 아직, 제품 ‘안에’ 에이전트가 돌아가는 제품을 만들어본 적이 없어요.
바로 그 간극에 대해 이야기해보려고 해요.
‘에이전트가 루프에 있다’는 말의 두 가지 의미
“agents in the loop”라는 말은 보통 두 가지 중 하나를 가리켜요. 그리고 이 둘은 전혀 다른 이야기예요.
1) 제품을 ‘만드는’ 루프에 에이전트가 들어있는 경우. 이건 제가 매일 살고 있는 세계예요. Claude Code가 코드를 쓰고 저는 리뷰하고, LLM이 이 블로그 글을 번역해주고, 또 다른 LLM이 아키텍처를 같이 고민해줘요. 제품을 ‘만드는 과정’에 에이전트가 박혀 있어요.
솔직히 Claude Code는 제가 써본 ‘에이전트가 루프에 있는’ 제품 중에서도 제일 잘 만든 축이에요. 거기서는 에이전트가 정말로 루프 안에 들어와 있어요. 제가 일하는 루프 안에요.
2) 제품이 ‘돌아가는’ 루프에 에이전트가 들어있는 경우. 출시된 뒤에도, 프로덕션에서 사용자 대신 판단하고 결정하고 움직이는 에이전트가 제품 ‘안에’ 계속 살아 있는 세계예요.
첫 번째는 이미 모든 걸 바꾸고 있어요. 두 번째는, 적어도 저한테는, 거의 시작도 안 한 영역이에요.
제가 실제로 출시한 것들
제가 낸 것들을 하나씩 구체적으로 적어볼게요.
- ai-sota-feed-bot — Claude Code로 만든 첫 제품이에요. 정적 피드 생성기고요. 파이프라인은 에이전트와 함께 만들었지만, 사용자가 보는 건 미리 생성된 콘텐츠예요. 런타임에 에이전트는 끼어들지 않아요.
- 이 블로그 — 같은 구조예요. 모든 글을 에이전트가 다듬고, 번역하고, 포맷팅해요. 하지만 독자가 만나는 건 순수 HTML이에요.
제가 에이전트를 쓰는 방식은 완전히 작업실 쪽으로 치우쳐 있어요. 제품 안에는 없어요.
이대로 쭉 가진 않을 것 같아요
미래는 아무리 봐도 ‘사람을 대신해 움직이는 여러 에이전트’의 시대일 거예요. 일정 잡고, 걸러내고, 협상하고, 요약하고, 가르치고, 개입하고. 데모가 아니라, 사람이 실제로 의지하는 제품의 빠지면 안 되는 부품으로요.
이건 이제 막 시작이에요.
구체적인 초기 사례가 하나 있어요. AWS가 최근 공개한 DevOps 에이전트는 프로덕션 장애를 스스로 조사하고 대응을 끌고 가요. 운영 루프 한복판에 들어와 있는 에이전트예요. 작업실이 아니라요.
앞으로 우리 사회에 새로 열릴 영역이 정말 어마어마해요. 에이전트가 결정을 내리고, 돈을 쓰고, 다른 에이전트와 대화해요. 우리 대부분은—저도 포함해서—이걸 어떻게 만들어야 하는지 아직 잘 모른다고 생각해요.
제품 ‘안에’ 에이전트를 넣는 건 왜 아직 어려울까
제가 자주 보고, 저도 자꾸 빠지는 함정이 있어요.
에이전트를 하나 붙여놓으면, 첫 데모는 진짜 그럴듯해요. 추론처럼 보이는 걸 해내거든요. 저도 감탄하고, 보여드리는 분도 감탄해요.
그런데 이걸 진짜 제품으로 만들려고 하면, 금이 금방 가요.
- 결과물이 너무 복잡하고 너무 두루뭉술해요. 그럴듯하게 들리는데, 사용자가 실제로 원한 작업에 딱 붙지 않아요.
- 검증할 방법이 없어요. 시스템도 자기가 맞게 했는지 모르고, 하루에 요청이 열 개만 넘어가도 사람도 모르게 돼요.
- 비용은 청구서 오기 전까진 안 보여요. 프롬프트 길이, 재시도, 컨텍스트, 툴 루프. 비용은 비선형으로 움직이고, 평범한 대시보드로는 안 잡혀요.
- 성능도 마찬가지예요. 테일 레이턴시, 부분 실패, 타임아웃, 모델 회귀. 평소에 제품을 모니터링하던 방식으로는 잘 잡히지 않아요.
이건 ‘있으면 좋은 것들’이 아니에요. ‘우리 제품 어딘가에 에이전트가 있어요’랑 ‘고객이 이걸 실제로 믿고 써도 돼요’를 가르는 것들이에요.
그리고 지금, 이걸 쉽게 조립할 수 있는 방법은 없어요. 평가 툴, 프롬프트 레지스트리, 트레이싱, 비용 미터, 가드레일—조각들을 꿰매 놓고 이음매가 새지 않길 바라는 수밖에 없어요.
이 조각들이 갖춰지지 않으면, 에이전트 시스템은 프로덕션에서 쓸 수 있는 수준과는 한참 멀어요.
에이전트도 우리가 믿고 쓰는 시스템이 돼야 해요
우리가 매일 쓰고 있는 시스템들—결제, 검색, 메신저, 지도, 추천—은 믿을 수 있고 일관되게 돌아가고 나서야 진짜 인프라가 됐어요.
똑똑한 것만으론 부족했어요. 이런 조건들을 갖춰야 했어요.
- 경계가 분명해야 해요(Bounded). 뭘 하고 뭘 안 하는지 알 수 있어야 해요.
- 관찰 가능해야 해요(Observable). 뭘 하고 있고, 얼마 드는지 보여야 해요.
- 복구 가능해야 해요(Recoverable). 실패해도 말이 되는 결과가 나와야 해요.
- 설명 가능해야 해요(Attributable). 왜 그런 결정을 내렸는지 추적할 수 있어야 해요.
에이전트는 아직 거기 못 왔어요. 모델이 못해서가 아니라, 모델 주변의 시스템이 아직 제품 등급으로는 거의 존재하지 않아서요.
결제나 검색처럼 에이전트가 우리 일상에 들어와 있으려면, 바로 이 레이어가 만들어져야 해요. 일관된 출력, 믿을 수 있는 동작, 관찰 가능한 비용, 복구 가능한 실패.
‘똑똑함’이 아니라 ‘믿을 수 있음’이에요.
그래서 이 섹션을 왜 만들었냐면
Agents in the Loop 섹션은 이걸 위한 자리예요.
에이전트로 코딩을 더 빨리 하는 이야기는 아니에요. 그건 다른 섹션에 어울리고, 거기서도 계속 쓸 거예요.
이 섹션은 에이전트를 작업실에서 제품 안으로 옮기려고 할 때 일어나는 일들에 대한 기록이에요. 뭐가 깨지는지, 어떤 부분이 진짜로 제품을 떠받치는지, ‘프로덕션 등급’이라는 말의 실제 모양이 뭔지, 그리고 제가 그걸 만들어보면서 배우는 것들이요.
정리된 답은 아직 없어요. 대신 간극에 대한 분명한 감각과 몇 가지 가설, 그리고 다음 시대의 제품 만들기가 바로 여기서 정해질 거라는 강한 직감이 있어요.
같이 알아봐요.