같은 날, 두 에이전트, 둘 다 움직이지 않았다

일을 하는 것이 직업인 에이전트라면 첫 날부터 움직여야 합니다. 그런데 이번 주에 나온 두 에이전트는 정반대였습니다. 첫 날의 행동은 움직이지 않는 것이었거든요.

오늘(11월 3일) 출시 기사에서 나온 장면입니다. 서로 무관한 두 제품이, 하나는 중국발 오픈소스 시제품이고 다른 하나는 국내 엔터프라이즈 제품인데, 같은 날 같은 기본값을 고랐습니다. 바로 ‘먼저 보고 그 다음에 움직인다’는 값이죠. 우연한 일치일 수도 있고, 업계가 이미 내린 결론일 수도 있는 셈이다. 두 제품을 차례로 보고 그 이유를 추적하면서 답을 찾아보겠다.

글의 핵심 개념을 형상화했습니다.

첫 번째 에이전트, 일을 찾는 것 자체가 직업

딥시크의 에이전트 조직 ‘하네스팀’이 오픈소스 코딩 에이전트 시제품 ‘슈퍼 에이전트’를 위챗으로 공개했다. 깃허브 저장소는 공개 이틀 만에 약 9,500개 스타를 모았다. 어떤 출시 뉴스와 바꿔놔도 화제를 만들 숫자죠. 그런데 이 제품의 설계 핵심은 그 열기와 정반대에 있습니다.

왜 코딩 에이전트가 전인지부터 짚어야 하는가. AI가 생성한 코드의 급증으로 개발자의 검토 부담이 커진 상황에서 나온 제품입니다. 코드 홍수 한가운데서 스스로 일까지 찾아오는 코딩 에이전트는 그 자체로 공격적인 포지션입니다.

구조는 멀티에이전트입니다. ‘메인 세션’이 작업 접수 여부를 판단하고 접수한 작업마다 ‘실행 세션’을 배정해 병렬로 처리합니다. 입구에 교통관제관을 세우고 실제 작업은 차선별로 나누어 맡기는 형태입니다. 그리고 기본값은 ‘관찰’ 모드입니다. 이 모드에서는 선제 작업 후보를 ‘수락 가능’이라고 기록만 합니다. 운영자가 ‘자동’ 모드로 전환해야 비로소 실제 처리에 들어갑니다. 사람이 직접 지목한 요청은 즉시 접수하고 지목하지 않은 대화는 후보로 분류해 수락 대기 상태로 두는 방식입니다. 딥시크가 내세운 핵심 원칙은 ‘사람의 주의는 최소한으로, 가치는 최대한으로’입니다.

이 원칙을 한 번 더 읽어보면 ‘주의는 최소한으로, 가치는 최대한으로’라고 하면 사람은 ‘일하는 것’에 시간을 쓰지 않고 ‘일 후보를 골라내는 것’에만 쓰라는 뜻이 됩니다. 관찰 모드의 산출물은 후보 목록이 핵심입니다. 사람의 역할은 그 목록을 심사하는 것으로 바뀝니다. 에이전트의 가치가 발굴의 질로 재편되는 순간입니다.

아키텍처도 오픈소스 하네스 기반으로, 모든 기능이 플러그인이라 합니다. 업무 메신저, 코드 저장소, 테스트 결과를 에이전트가 스스로 연결해 작업 후보를 선제적으로 발굴하죠. 일을 스스로 찾고 찾아놓고 사람이 버튼을 누르기까지 기다리는 에이전트입니다.

숫자와 설계는 모순되지 않습니다. 이틀 만에 9,500개 스타가 붙은 것은 시장이 ‘스스로 일까지 찾아오는 에이전트’라는 컨셉 자체에는 이미 점수를 줬다는 뜻이니까요. 그런데 컨셉에 점수를 준 바로 그 시장이, 실제 첫 실행은 버튼을 눌르기까지 미루는 설계를 고릅니다. 열기는 출시 숫자에 있고 온건함은 기본값에 있는 것입니다. 업계는 이미 앤트로픽이 지난 6월 슬랙에 공개한 팀 단위 에이전트 ‘클로드 태그’와 이 제품을 비교하고 있습니다. 스케일은 다르지만 자세는 같은 방향입니다.

두 번째 에이전트, 세 단계를 제품 명단에 쓴 회사

같은 날, 베스핀글로벌이 국내 기업을 겨냥한 실행형 AI 에이전트 ‘헬프나우 컴퓨터’를 출시했습니다. 2026년 글로벌 에이전틱 AI 시장은 파일럿을 넘어 실제 업무 실행 단계로 넘어가는 과도기이고 헬프나우 컴퓨터는 통칭 ‘AI 파일럿 트랩’이라 불리는 병목을 실행형 에이전트로 정면 돌파하려는 시도입니다. 베스핀글로벌이 시장에 낯선 이름은 아닙니다. GS인증 1등급을 획득했고, 최근 AWS 서밋에서는 ‘AI 운영’ 전략을 제시하며 기업 AI 운영 시장을 공략해 왔습니다.

헬프나우 컴퓨터는 웹브라우저, 터미널, ERP 같은 기업 시스템을 직접 조작하는 에이전트입니다. 자연어 지시를 작업 순서로 분해해 문서 작성, 데이터 분석, 정보 입력, 업무 신청까지 수행합니다. 밑받침은 에이전트 런타임에 NL2SQL, 코드 생성, 브라우저와 컴퓨터 조작 등 9가지 도구, 그리고 MCP/API 연동입니다. ERP, 그룹웨어, CRM, 전자문서 같은 외부 시스템과 연결해 동작하죠.

도입 로드맵을 보면, 답이 똑같습니다. 관찰(Observe), 보조(Assist), 실행(Execute)입니다. 먼저 보고 옆에서 돕고 마지막에 직접 하는 3단계 점진적 도입 모델이죠. 도입 리스크를 낮추는 실질적 방안으로 평가되는 부분이 바로 여기입니다. 보안은 ISO/IEC 42001 기반이고 RBAC, SSO, 실행기록, 샌드박스, 폐쇄망 옵션까지 갖췄습니다. 실행의 흔적을 로그에 남기는 설계가 기본값입니다. 멀티모델 라인업에는 GPT-OSS, Llama, Qwen, HyperCLOVA X, EXAONE, Gemini가 있고 멀티클라우드 목록에는 AWS, Azure, GCP, OCI, 네이버, 삼성, KT가 나열됩니다. 이 조합은 국내 기업의 벤더 록인 우려를 완화하는 요소로 평가됩니다. 공급은 SaaS 구독과 K8s, 도커 설치형이고 공공은 디지털 전문 계약입니다.

특히 주목할 변화가 하나 더 있습니다. 공공과 금융기관은 폐쇄망과 CSAP 같은 보안 요건이 강해 클라우드 기반 AI 도입에 제약이 컸습니다. 헬프나우 컴퓨터가 폐쇄망 구축 옵션과 CSAP 환경을 지원하면서 그 제약이 열린 것이죠. 활용 영역을 열거하자면 여섯 개입니다. IT 운영과 장애 대응, 공공 민원과 행정, 경영 보고와 데이터 분석, 문서와 계약 검토, 영업과 CRM, 시장 조사입니다.

두 제품을 나란히 세우면, 게이트의 모양에서 또 다른 교차점을 찾을 수 있는 셈입니다. 슈퍼 에이전트의 게이트는 버튼 하나입니다. 관찰 모드에서 자동 모드로, 운영자가 직접 누르는 전환이죠. 헬프나우 컴퓨터의 게이트는 단계 셋입니다. 관찰에서 보조, 보조에서 실행으로, 조직이 시간을 들여 올라서는 로드맵이거든요. 하나는 개인의 스위치이고 다른 하나는 기업의 생애주기입니다. 지켜보는 대상도 다릅니다. 하나는 에이전트가 후보로 올린 작업 목록이고 다른 하나는 에이전트가 남긴 실행기록입니다.

겉으로 보면 중국발 오픈소스 시제품과 국내 엔터프라이즈 제품, 두 개의 다른 형식입니다. 그런데 기본값으로 고른 첫 번째 단어는 둘 다 ‘관찰’이었습니다.

왜 모두 ‘먼저 관찰’인가

그 이유를 가늠할 필요가 없습니다. 이미 통계로 나와 있기 때문입니다.

리눅스재단이 10월에 발표한 보고서에 따르면, 오픈소스 프로젝트 관리자의 59%가 생성형 AI 확산 이후 기여 물량이 늘었다고 답했습니다. 새로 접수되는 코드 변경 요청의 25%는 대량 생성 저품질 결과물, 즉 ‘AI 슬롭’으로 추산했고 대형 프로젝트에서는 31%까지 올라갑니다. 깃허브도 일찍이 반응했습니다. 2월에 외부 이용자의 풀 리퀘스트 생성을 차단하거나 허가한 팀원만 허용하는 기능을 도입했고, 6월에는 AI 에이전트가 만든 요청도 그 상한에 포함시켰습니다. 일을 받는 쪽에 이미 게이트가 서 있는 겁니다.

동시에 일하는 쪽은 기본값을 낮추고 있습니다. 슈퍼 에이전트와 헬프나우 컴퓨터가 바로 그 쪽입니다. 일을 받는 쪽이 상한을 조이고 일하는 쪽이 스스로 발을 꺾습니다. 양쪽이 ‘한 번 지켜보겠습니다’라는 방향으로 움직이니, 이 일치는 우연이 아니라 결론처럼 보입니다.

관심의 중심도 이동했습니다. 에이전트가 일할 수 있는지를 묻는 단계는 지났고 에이전트가 한 일을 검증할 수 있느냐를 묻는 단계입니다. 가트너는 2027년까지 에이전틱 AI 프로젝트의 40% 이상이 예산과 시간 초과로 중단될 것이라고 경고했습니다. 국내 업계에서는 생성형 AI 도입 이후에도 실제 업무 성과로 전환하기 어려운 현상을 ‘AI 파일럿 트랩’이라 부릅니다. 검토 병목은 이미 ‘만드는 것’에서 ‘검증하는 것’으로 옮겨갔습니다.

변경 이력과 책임이 중요한 금융, 제조, 공공 산업일수록 자동 처리 전환 기준과 운영자 승인 절차가 도입의 핵심 쟁점이 됩니다. 기본값이 ‘관찰’이라는 설계가 보내는 시장 메시지도 여기와 같습니다. 에이전트의 자율성이 커질수록 통제, 감사, 승인 체제가 함께 갖춰져야 한다는 것입니다.

국내 기업으로 시야를 옮기면 그림이 더 선명해집니다. 프로덕션 환경에 에이전트를 투입하는 순간, 기업의 손에 주어지는 것이 ‘후보 목록’과 ‘실행기록’이 됩니다. 구체적으로는, 슈퍼 에이전트의 ‘수락 가능’ 기록과 헬프나우 컴퓨터의 실행기록, 단계 승인이 그 예입니다. 이 둘이 곧 국내 에이전트 도입의 새로운 평가 기준으로 자리 잡을 가능성이 큽니다. 모델이 얼마나 똑똑한지를 묻던 시기가, 에이전트가 얼마나 통제 가능하냐를 묻는 시기로 넘어가는 겁니다.

그래서 이상한 상품화가 진행 중입니다. 실행력은 시제품의 속도에서 쏟아져 나오고 그 실행이 언제 일어나고 누가 승인하며 만약의 사고에 누가 책임지는지를 가두는 구조는 제품의 속도에서 지어지고 있습니다. 실행이 스펙시트가 되는 세상에서는 스펙시트로 팔 수 없는 것이 가격표를 갖습니다. 그게 바로 신뢰, 검증, 책임입니다. 이 전장에서 상품인 것은 게이트입니다.

자율도는 옵션이고 기본값은 아니다

같은 날 나온 두 에이전트에 한 가지 질문을 더 붙이면, 그게 곧 기업의 과제입니다. 게이트를 여는 순간, 그 안에서 일어난 실행에 누가 책임지는가. 그리고 그 게이트 자체는 어떤 형태로 존재하는가.

ThakiCloud의 Paxis는 이 뉴스를 바로 그 자리에서 봅니다. Paxis는 ThakiCloud의 에이전트 네이티브 클라우드이며, 이미 정식 제품(v1.1 GA)입니다. 두 출시 제품이 각각 버튼과 단계로 그린 게이트를, Paxis의 설계는 레벨로 그립니다. 자율도는 레벨이거든요. L0에서 L3까지의 자율도 거버넌스가 에이전트가 기본적으로 얼마나 움직이는지 정의하고, 정책 게이트가 그 정책을 넘는 작업을 막습니다. 모든 동작은 감사 로그에 남습니다. 실행은 격리된 샌드박스 안에서만 일어납니다. MCP 커넥터와 스킬 마켓은 도구와 스킬을 일급 리소스로 관리하고, 소버린과 온프레미스 K8s 환경, 작업별 모델 선택인 CostRouter도 표준 사양입니다.

오늘의 기사에서 보인 통증은 정확히 Paxis가 받아들이는 쪽에 위치합니다. AI 슬롭의 홍수는 검증 비용의 이야기이고 40% 프로젝트 중단 경고는 예산과 시간의 이야기입니다. 폐쇄망과 CSAP를 요구한 공공, 금융의 조건은 주권의 이야기입니다. 실행기록, 정책 게이트, 샌드박스가 바로 그 답의 형태입니다. 감사 로그가 ‘누가 허락했는가’를, 격리 샌드박스가 ‘만약의 사고는 어디까지 오는가’를, CostRouter가 ‘이 실행은 얼마나 드는가’를 각각 책임지는 구조니까요. 이 각각이 답하는 것은 같은 질문입니다. 에이전트가 일을 했을 때, 기업이 무엇을, 왜, 누가 허락했는지를 증명할 수 있는가.

두 에이전트는 지금 지켜보고 있는 셈입니다. 일은 스스로 찾는 쪽은 모드 전환을 기다리고 기업 안에 들어가는 쪽은 단계 이동을 기다립니다. ‘움직이면 상품’이라는 시기는 이미 끝났습니다. 기업이 이제 물어야 할 질문은 바뀌어 버렸습니다. ‘일을 하면 누가 책임지느냐’가 핵심인 것입니다. 그 질문은 게이트 앞에서 시작되고 그래서 지금 시장의 정중앙에 서 있습니다.

참고 자료

이 글은 아래 뉴스를 종합해 작성했습니다.

• 컨슈머타임스, AI 코드 홍수 속 딥시크 ‘슈퍼 에이전트’ 공개
• 데이터뉴스, 베스핀글로벌, 실행하는 AI 에이전트 ‘헬프나우 컴퓨터’ 출시