AI 에이전트, SaaS를 죽이지 못한다
AI 에이전트, SaaS를 죽이지 못한다
Sleepy.md 작성
AI 에이전트가 대중화되면서 갑자기 SaaS의 종말을 논하는 목소리가 나오기 시작했습니다. 이러한 두려움은 이해할 만합니다. 모델이 코드를 작성하고, 버그를 찾고, 도구를 호출하고, 워크플로를 처음부터 끝까지 완료할 수 있다면, 누가 소프트웨어 좌석에 대해 계속 비용을 지불하려고 할까요?
이러한 불안감은 2026년 초에 공개 시장으로 번졌습니다. Anthropic이 Claude를 위한 새로운 에이전트 도구링과 플러그인을 출시한 후, 엔터프라이즈 소프트웨어 가치 평가는 크게 재조정되었습니다. 이는 "소프트웨어가 끝났다"는 이유보다는 투자자들이 UI가 사라지고 워크플로가 자율 시스템에 흡수되는 세상을 잠시 상상했기 때문입니다(소프트웨어 매각에 대한 Axios 보도 및 Anthropic의 엔터프라이즈 플러그인에 대한 Axios 보도 참조).
암호화폐 영역에서도 비슷한 논쟁이 벌어지고 있습니다. 다만 그 결과는 훨씬 더 중요합니다.
블록체인에서 에이전트는 단순히 작업을 완료하는 것을 넘어 자산을 이전할 수 있습니다. 에이전트에게 거래에 서명할 수 있는 능력을 부여하는 순간, "SaaS는 죽었다"는 단순한 주장에서 보안 사고로 이어질 수 있습니다. 현실은 이렇습니다. AI 에이전트는 암호화폐 SaaS를 재편할 것이지만, 그것을 죽이지는 못할 것입니다. 오히려 진정한 인프라, 진정한 보안, 진정한 신뢰가 무엇인지에 대한 기준을 높일 것입니다.
1) 암호화폐에서 "에이전트"는 소프트웨어를 대체하는 것이 아니라 소프트웨어의 목적을 바꿉니다.
대부분의 SaaS 비관론은 직접적인 대체 가정을 합니다.
- 이전 세계: 사용자가 SaaS UI의 버튼을 클릭합니다.
- 새로운 세계: 에이전트가 버튼을 클릭합니다.
- 결론: SaaS 계층은 쓸모없어집니다.
하지만 암호화폐 제품은 단순한 "UI"가 아닙니다. 그것들은 되돌릴 수 없는 조치에 대한 안전 장치입니다. 즉, 보관 경계, 정책 제어, 감사 추적, 오류 격리 등입니다. 에이전트는 의도를 자동화할 수 있지만, 기본 시스템은 여전히 다음과 같은 기능을 제공해야 합니다.
- 안정적인 데이터 액세스 (인덱싱, RPC, 가격 책정, 위험 신호)
- 결정론적 실행 환경 (API, 스마트 계약, 서명 흐름)
- 필요한 경우 규정 준수 및 감사 가능성 (기관 워크플로, 재무 자동화)
- 안전 제어 (한도, 승인, 시뮬레이션, 롤백 전략 - 온체인에서 롤백이 "불가능"하더라도 예방은 여전히 필요합니다.)
다시 말해, 에이전트는 SaaS를 없애는 것이 아니라 SaaS를 "워크플로 UI"에서 "검증 가능한 인프라"로 전환시키는 것입니다.
이는 특히 2025-2026년 암호화폐 트렌드에서 두드러집니다. 온체인 활동의 대부분은 조합 가능하고(composable), 도메인 간(cross-domain) (L2 + 브릿지 + 인텐트), 그리고 점점 더 기관 지향적(institutional-facing) (스테이블 코인 레일, 토큰화된 실물 자산, 재무 자동화)이 되고 있습니다. 이러한 문제는 "프롬프트 한 번"으로 해결될 문제가 아니라 시스템 문제입니다.
2) 난관: 개인 키 (그리고 왜 에이전트가 더 중요하게 만드는가)
AI 에이전트는 "다음에 무엇을 할지 알아내는 것"에 능숙합니다. 개인 키는 "그것을 할 수 있는 권한이 있음을 증명하는 것"에 관한 것입니다.
이것이 바로 암호화폐가 웹2와 크게 달라지는 지점입니다. 웹2에서는 에이전트가 종종 철회 가능한 권한으로 작동할 수 있습니다. 즉, 토큰을 회전시키거나, 계정을 잠그거나, 요금을 취소할 수 있습니다. 온체인에서는 서명된 거래가 최종적입니다. 에이전트가 프롬프트 주입, 도구 오염, 공급망 공격 또는 단순한 불일치로 인해 손상되면 그 피해는 즉각적입니다.
따라서 질문은 다음과 같습니다.
서명자는 누구인가?
만약 당신의 대답이 "에이전트"라면, 당신은 제품을 설계하는 것이 아니라 확률적 시스템에 보관을 위임하고 있는 것입니다.
대신 업계의 방향은 계층적 권한 부여로 수렴되고 있습니다.
- 스마트 계정 / 계정 추상화를 통해 코드로 정책을 표현합니다 (지출 한도, 세션 키, 화이트리스트). 좋은 시작 참조는 EIP-4337 (계정 추상화)입니다.
- 에이전트가 행동을 제안하지만 실행은 정책에 의해 제한되는 인텐트 기반 실행.
- 고위험 작업에 대한 인간 개입 승인.
- 에이전트 런타임에서 개인 키를 강력하게 격리하기 위한 하드웨어 기반 서명.
이것이 바로 암호화폐 보안이 협상 불가능한 영역으로 남아 있는 이유입니다. 에이전트는 초안을 작성하고, 계획하고, 최적화할 수 있지만, 최종 서명은 보호되어야 합니다.
3) "SaaS 소멸"은 사실 "SaaS UI 소멸"이며, 암호화폐는 환영해야 합니다.
암호화폐에서 UI는 종종 가장 약한 고리입니다.
- 사용자는 calldata를 파싱할 수 없어 악성 거래를 승인합니다.
- 잘못된 체인에 서명합니다.
- 손상될 수 있는 프런트엔드를 신뢰합니다.
- 주소를 맹목적으로 복사합니다.
- 서명 전에 결과를 시뮬레이션하지 않습니다.
AI 에이전트는 원시 거래 의도를 이해하기 쉬운 요약으로 번역하고, 비정상적인 승인을 감지하며, 결과를 자동으로 시뮬레이션함으로써 UX를 극적으로 향상시킬 수 있습니다.
하지만 이것이 SaaS를 제거하는 것은 아니며, SaaS 가치를 새로운 기본 요소로 전환합니다.
에이전트가 의존하게 될 새로운 암호화폐 SaaS 기본 요소
- 서비스로서의 거래 시뮬레이션 (사전 실행 분석, 최악의 시나리오 결과, MEV/슬리피지 위험)
- 정책 엔진 (허용/거부 규칙, 임계값, 화이트리스트, 시간 잠금)
- 구조화된 지갑 권한 (세션 키, 범위 지정된 허용, 철회 흐름)
- 모니터링 + 경고 (온체인 "SIEM 유사" 파이프라인, 비정상 감지)
- 증명 및 감사 계층 (누가 어떤 정책으로 어떤 맥락에서 승인했는지)
에이전트는 이러한 서비스를 지속적으로 호출할 것입니다. 오히려 에이전트 워크플로는 SaaS 사용을 증가시킵니다. 왜냐하면 더 많은 작업, 더 많은 거래, 그리고 더 많은 안전 장치 수요를 창출하기 때문입니다.
4) 에이전트 공격은 가상적인 것이 아닙니다. 프롬프트 주입은 "거래 주입"이 됩니다.
에이전트와 연결된 암호화폐 앱을 구축하는 경우, 이제 고전적인 AI 위협이 직접적으로 재정적 손실로 이어지는 세상에 살고 있습니다.
두 가지 실용적인 원칙이 도움이 됩니다.
원칙 A: 모델을 신뢰하지 않는 것으로 취급하십시오.
에이전트가 적대적인 입력으로 조작될 수 있다고 가정하십시오. 시스템은 다음을 시행해야 합니다.
- 도구 호출에 대한 명시적 허용 목록 (어떤 계약, 어떤 메서드, 어떤 체인)
- 최대 지출 한도
- 엄격한 출력 스키마 (자유 형식 실행 금지)
- 서명 전 필수 시뮬레이션 및 확인
일반적인 보안 배경에 대해서는 웹 보안 커뮤니티의 사고방식이 유용합니다. OWASP Top 10을 참조하십시오.
원칙 B: 모든 위험한 조치에 대해 강화된 서명 경계를 요구하십시오.
다음과 같은 서명 경계를 원할 것입니다.
- 에이전트 런타임 외부
- 악성 코드에 대한 내성
- 대상, 금액 및 네트워크를 명시적으로 확인
- 인간 확인을 위해 설계된 것
이것이 바로 자체 보관 관행, 특히 하드웨어 지갑이 에이전트 시대에 덜 중요해지는 것이 아니라 오히려 더 중요해지는 이유입니다.
5) 2026년 "암호화폐 SaaS" 회사를 위한 의미
대시보드, 분석, 재무 운영, 포트폴리오 자동화, 규정 준수 도구 등 SaaS처럼 보이는 암호화폐 제품을 운영하고 있다면, 기회는 "에이전트와 경쟁하는 것"이 아니라 에이전트 네이티브 인프라가 되는 것입니다.
간단한 재포지셔닝이 종종 효과적입니다.
- ~에서: "우리는 사람들을 위한 대시보드를 제공합니다."
- ~로: "우리는 에이전트와 사람들을 위한 안정적이고 정책 제한이 있는 실행 및 위험 계층을 제공합니다."
통제력을 잃지 않고 에이전트 네이티브가 되기 위한 체크리스트
- 결정론적 API 노출: UI 자동화보다 구조화된 엔드포인트를 선호합니다.
- 기계 판독 가능한 위험 출력 제공: 차트뿐만 아니라 명시적인 신호(예: 높은 슬리피지 위험, 안전하지 않은 승인 범위)를 반환합니다.
- 정책 제어 우선 출시: 한도, 역할 기반 승인, 체인 허용 목록.
- 감사 가능성 설계: 분쟁에서 살아남는 로그 ("에이전트가 왜 그렇게 했는가?").
- 스마트 계정 및 범위 지정된 권한 지원: 따라서 자동화가 기본적으로 안전하도록 합니다.
- 계획과 서명 분리: 에이전트가 제안하도록 하고; 실행에는 강화된 서명을 요구합니다.
이것은 DevOps 진화와 같은 이야기입니다. CI/CD는 소프트웨어 팀을 죽이지 않았습니다. 오히려 팀이 더 규율 있게 되도록 강요했습니다. 에이전트는 암호화폐 SaaS를 죽이지 않을 것입니다. 그것은 암호화폐 SaaS를 더 안전하고, 더 조합 가능하며, 더 책임감 있게 만들도록 강요할 것입니다.
6) OneKey는 어떻게 작동하는가 (AI가 "생각"을 할 때)
AI가 더 많은 계획과 자동화를 수행한다면 공격 표면이 확장됩니다. "두뇌"(에이전트)는 다음과 같은 것에 노출될 것입니다.
- 브라우저, 플러그인 및 신뢰할 수 없는 웹 콘텐츠
- 도구 API 및 타사 서비스
- "유용한 지침"으로 위장한 프롬프트 주입 시도
- 자동화 파이프라인의 손상된 종속성
그렇기 때문에 서명 장치는 격리되어야 합니다.
OneKey와 같은 하드웨어 지갑은 최종적이고 강화된 승인 계층 역할을 할 수 있습니다. 즉, 에이전트는 서명되지 않은 거래를 준비할 수 있지만, 개인 키는 오프라인 상태로 유지되고 인간은 서명 전에 장치에서 확인합니다. 실제로 이것은 자동화의 이점을 유지하면서 자체 보관을 보존하고 "에이전트-를-보관자" 위험을 최소화하는 가장 깔끔한 방법 중 하나입니다.
온체인 자동화를 실험하고 있다면, 에이전트가 거래 의도를 생성하고, 스택이 시뮬레이션 + 정책 확인을 실행하며, OneKey가 최종 서명을 수행하는 워크플로를 채택하는 것을 고려하십시오.
결론: SaaS는 죽는 것이 아니라 성숙하도록 강요받고 있습니다.
"AI 에이전트가 SaaS를 죽인다"는 매력적인 슬로건이지만, 암호화폐는 그 단점을 명확하게 합니다.
- 에이전트는 실행 볼륨을 증가시키므로 인프라 수요가 증가합니다.
- 키와 서명은 자동화가 없앨 수 없는 강력한 보안 경계를 만듭니다.
- 성공적인 제품은 워크플로를 검증 가능하고 정책 제어가 가능한 기본 요소로 전환하는 제품이 될 것입니다.
2026년에 문제는 암호화폐 SaaS가 살아남을 것인가가 아닙니다. 문제는 당신의 스택이 소프트웨어가 단순히 사람들에게 봉사하는 것을 넘어 실제 돈을 가진 자율 운영자들에게 봉사하는 세상에 준비되었는가 하는 것입니다.
