에이전트 붐을 '유저들의 반란'으로 읽는 프레임

AI 에이전트 붐이 사실은 테크 업계에 대한 유저들의 반격이라는 해석이 있음. 그동안 소프트웨어 회사들이 유저를 어떻게 다뤄왔는지에 대한 누적된 분노가 에이전트 열풍으로 표출됐다는 프레임. 처음엔 좀 과한 해석 같았거든요. 그런데 따져보니 일리 있는 부분이 꽤 있더라고요. 동시에 동의 안 되는 지점도 명확함.

본문 들어가기 전에 짧게 짚고 갈 용어 셋. 에이전트는 단발 응답이 아니라 작업을 분해해서 단계별로 실행하는 LLM 사용 방식. 이메일 자동 답장, 코드 자동 작성·실행, 외부 API 호출 같은 걸 알아서 처리함. 토큰은 LLM이 처리하는 텍스트 단위인데, 에이전트는 시도-실패-재시도를 반복해서 토큰 소모량이 일반 챗봇보다 훨씬 큼. 비결정적 동작은 같은 입력이어도 매번 결과가 달라질 수 있다는 뜻. 전통적 소프트웨어와 가장 다른 부분.

테크 업계가 유저에게 해온 것들#

이 프레임의 출발점이 흥미로움. 테크 업계가 유저를 다루는 방식에 일정한 서사가 있다는 거.

• "유저는 자기가 뭘 원하는지 모른다" — 헨리 포드의 (사실은 출처 불분명한) "더 빠른 말 어쩌고" 인용을 방패로 삼는 패턴
• "유저는 충분히 똑똑하지 않다" — UI가 미로면 유저 교육으로 해결하려 함
• "유저는 잘 속는다" — 보안 사고는 유저 책임, 회사는 면책
• "유저는 너무 복잡하다" — 유저 페르소나로 단순화하고, 거기 안 맞으면 알아서 적응
• "테크는 신뢰할 만하다" — Cambridge Analytica, CrowdStrike 사태, Log4J 같은 실제 사고들은 어떻게 설명할 건데?
• "테크가 발전 속도를 정한다" — 유저는 따라오기만 하라
• "테크 리더들이 진짜 전문가들이다" — 코딩을 신비화함
• "테크가 호환성·경계를 정할 권리가 있다" — walled garden을 유저 보호로 포장

이 중에 특히 와닿은 건 페르소나 부분이었음. 평균치 만들어서 거기 안 맞는 사람은 알아서 적응하라는 게 십수 년 동안 업계 표준이었거든요. 접근성도 다양성도 다 부차적 문제로 밀림. 한국 SaaS도 똑같음. 기능 요청 넣으면 "검토 후 향후 릴리즈에 반영" 답이 오고 끝. 그게 몇 년이 가는지...

그래서 에이전트가 그 답인가#

여기서부터 동의가 안 됨.

논리는 이렇게 흐름. 테크 업계가 유저를 무시해왔다 → 이제 유저들이 직접 도구를 만들 수 있게 됐다 → 에이전트가 그 분노의 출구다. 매끄럽긴 한데, 현실에서 에이전트 쓰는 사람들 분포를 보면 약간 다른 그림이 나오더라고요.

기술자들이 더 많이 쓰는 중. 비개발자가 자기 워크플로우 자동화하려고 에이전트 쓰는 비율보다, 이미 개발자/기술자인 사람이 자기 일 효율화하려고 쓰는 비율이 훨씬 큰 듯. 정확한 수치는 모르겠고 직접 잰 것도 아닌데, 주변 분위기랑 컨퍼런스 발표 분포만 봐도 그래요. 즉 "유저들의 반격"이라기보단 "기술자들의 도구 진화"에 가까움.

기업 도입 동기는 더 명확함. 회사가 에이전트 도입할 때 동기는 "유저 권한 부여"가 아니라 인력 절감이거든요. 이거 정반대 방향임. 콜센터를 에이전트로 대체할 때 누가 이득 보는지 생각해보면 답 나옴.

진짜 일반 유저들은? 챗봇 형태 LLM은 폭발적으로 쓰는데, 자율 실행 에이전트는 일반 유저 진입이 아직 한정적임. 토큰 비용도 한몫하고요.

(잠깐 옆길로) 한국에선 좀 다르게 작동함#

walled garden 얘기 나온 김에 한 호흡. 카카오톡, 네이버 같은 플랫폼이 유저 가두는 거 한국에서 다들 익숙하잖아요. 데이터 백업도 거의 안 되고 다른 서비스로 이전도 어렵고. "테크가 유저를 인질로 잡는다"는 부분이 한국에선 더 노골적으로 작동해온 듯.

근데 그래서 한국 유저들이 에이전트에 더 큰 기대를 갖느냐? 그것도 아니더라고요. 오히려 더 보수적임. 익숙한 도구를 그냥 쓰는 게 편하니까. 이 차이가 뭔지는 별도 글감으로 둬야 할 듯.

어두운 면, 이 부분은 거의 동의#

세부에선 동의 안 되지만 에이전트의 한계 짚는 부분은 거의 다 맞다고 봄.

유지보수가 안 됨. 에이전트 돌리는 동안 LLM 버전 바뀌고, 연결한 외부 API deprecate되고, 의존하는 라이브러리 깨짐. 일반 유저가 이걸 다 감당하는 건 무리. 회사 다닐 때 인하우스 자동화 만들어놓고 유지보수 못 해서 1년 안에 죽이는 케이스 많이 봤거든요.

보안 위험이 구조적임. 이메일 자동 답장 에이전트가 해킹되면 피싱 링크 자동으로 박는 시나리오가 가능함. 에이전트 자체가 attack vector가 되는 구조라는 지적은 정확하더라고요.

숨겨진 비용. 무료처럼 보이지만 토큰은 시도-실패 반복하면서 빠르게 누적됨. 진지하게 쓰려면 곧 유료 플랜으로 넘어가야 하는 단계로 빨리 가는 듯.

비즈니스 모델 부재. LLM 자체에도 적용되는 얘긴데, 에이전트는 그 위에 또 한 층이라 더 불안정. 가격 정책이 한 달 안에 바뀌어도 이상하지 않은 시기예요.

이거 그냥 취미용임. 회사 핵심 인프라로 깔아놓고 "이게 우리 시스템이에요" 말하면 안 되는 단계. (에이전트 권장 사용 패턴은 Anthropic 공식 docs 같은 데서 확인할 수 있음.)

큰 그림은 받아들일 만함#

세부 동의 안 되는 거 빼고 큰 프레임은 의미 있다고 봄. 에이전트 열풍이 단순 hype가 아니라 어떤 누적된 불만의 표현이라는 거. 받아들일 만한 분석임.

특히 마지막에 던진 "테크가 어떻게 바뀌어야 하는가" 부분 — 의사결정 투명화, 버그 수정 약속, "추후 검토" 캔드 답변 추방, 유저가 자기 워크플로우를 직접 빠르게 프로토타입할 수 있는 환경 — 이건 SaaS 만드는 입장에서도 공감 가는 가이드라인이에요. 지난번에 AI 에이전트가 프로그래머를 대체하지 않는다는 글에서 비슷한 톤으로 쓴 적 있는데, 이쪽은 좀 더 큰 시야에서 본 거라 보완재 같은 느낌.

한계 / 직접 검증 못한 부분#

이 프레임의 약점은 통계·수치 근거가 거의 없다는 거. "에이전트 도입이 유저 불만에서 비롯됐다"는 큰 주장에 비해 뒷받침 데이터가 약함. 단일 사례나 발화자 한 명 인용이 많고, 큰 가설을 받쳐줄 정량 자료가 거의 없음.

내가 이걸 다 검증하고 쓰는 건 아니거든요. 흥미로운 프레임이라는 거지 모든 주장이 사실이라는 게 아닌. 안 써본 에이전트 플랫폼들 실제 사용 분포는 더 봐야 할 듯하고, 한국 시장 데이터는 거의 없어서 추측 영역이 큼.

정리#

에이전트 붐을 "유저들의 반란"으로 보는 프레임은 큰 그림으론 일리 있지만 디테일에선 빈틈이 꽤 큼. 진짜 유저 반란이라기보단 기술자들의 도구 진화에 가깝고, 일반 유저까지 가려면 비용·안정성·보안 문제가 다 풀려야 하는 단계임. 그래도 핵심 메시지 — "유저들의 누적된 불만에는 이유가 있고, 테크 업계는 그걸 인정해야 한다" — 이건 SaaS 만드는 사람으로서 새겨들을 만함.