요약
Cursor가 Bugbot 같은 자사 에이전트를 만들던 프레임워크 Agent SDK를 정식 공개했습니다.
AI 코드 편집기 Cursor의 개발사가 10월 20일 블로그에 올린 발표입니다. 지금까지는 남의 업무 흐름에 맞춘 제품을 쓰거나 처음부터 직접 만들어야 했으니, 팀 방식에 맞는 에이전트를 코드로 짜서 바로 배포하라는 취지입니다.
왜 중요한가
- 기성 제품과 직접 개발 사이에 중간 선택지가 생겼습니다.
- 에이전트가 코드이므로 프롬프트와 정책 변경도 버전 관리와 코드 리뷰를 거치게 됩니다.
- Cursor가 Bugbot, Security Reviewer, Rollouts를 만든 도구를 그대로 내놓았습니다.
핵심 내용
- 프롬프트는 마크다운, 도구는 TypeScript 함수로 쓰고 평가(evals, 에이전트 동작을 확인하는 시험)와 한 프로젝트에 둡니다.
agent-sdk deploy명령 하나로 빌드하고 주소를 받아 Cursor 서버에서 실행합니다.- 에이전트 하나가 Node 프로세스 하나라서 컨테이너로 묶어 자체 서버에서 돌릴 수도 있습니다.
- GitHub·GitLab·Bitbucket의 풀 리퀘스트(PR) 이벤트를 받아 위험도 판단, 담당 팀 배정, 승인을 맡길 수 있습니다.
- 사내 한 팀은 기록해 둔 교훈과 어긋나는 PR을 짚어 주는 리뷰 에이전트를 하루 만에 만들었습니다.
HN 반응
- 일부 이용자는 AI 도구가 자바스크립트 프레임워크처럼 쏟아져 금방 낡는다며 이번 발표에서 새로운 점이 안 보인다고 했습니다.
- 에이전트를 누가 호스팅하느냐의 경쟁이라 배포 기능이 차별점이라는 의견에는, 오픈AI와 앤트로픽이 이미 비슷한 제품을 내놨다는 반론이 붙었습니다.
저는 이런 회사들 중 어느 한 곳이 진짜 어려운 부분을 내놓아 주기를 아직도 기다리고 있어요.
업무 담당자가 실제로 쓰는 웹 프런트엔드(채팅 UI)는 도메인에 맞게 손봐야 하는 경우가 많습니다. 기성 채팅 UI를 그대로 가져와 그 위에 커스터마이징을 얹어 보려 했지만, 처참하게 실패했어요. 커스텀 요소와 컨트롤러 액션이 달린 인라인 승인 흐름을 띄워야 하는 경우가 있는데, 기존 플랫폼에서는 이걸 어떻게 연결하나요? 방법이 전혀 없습니다. MCP로는 정보 채널은 만들 수 있어도, 특정 도구 호출에 필요한 UI/UX 흐름까지 강제해 주지는 않아요. UX를 타협하든지, chatgpt.com을 처음부터 다시 만들든지 둘 중 하나였고, 결국 후자를 택했습니다.
ChatGPT Apps를 한번 보시면 좋겠어요. 채팅 안에 바로 끼워 넣을 수 있는 React 앱 같은 겁니다. LLM은 앱 자체를 볼 수 없고, MCP가 에이전트에 실제로 보내 주는 내용만 볼 수 있어요. 저희가 고객사와 이렇게 구현해 봤는데 보기에도 아주 좋고, 원하지 않는 한 에이전트가 도구를 호출하지 않아도 일반 UI처럼 온갖 고급 기능을 다 할 수 있습니다.
저는 이 용도로 Tanstack AI( https://tanstack.com/ai )를 쓰고 있습니다. 설정이 정말 쉽고 튼튼해요. 도구 호출, 재연결 처리, 영속성, 컴퓨터 사용, 음성 등의 기반을 제공합니다. 웹에서 작업하신다면 강력히 추천합니다.
https://www.openui.com/ 와 비슷한 건가요, 아니면 좀 더 결정적(deterministic)인 방식인가요?
AI 도구도 드디어 JS 프레임워크식 난립과 잦은 갈아엎기 단계에 들어섰네요.
작년에 저희끼리 하던 농담이, AI와 관련해 배우거나 구현하는 건 뭐든 2주 뒤면 구식이 된다는 거였습니다.
에이전트 워크플로에 새 기능을 직접 만들어 넣으면, 다음 주에 Google의 ADK에 우리가 직접 만들 필요 없이 쓸 수 있었던 기능이 들어오곤 했어요.
이번 릴리스를 읽고 나니 뭐가 특별한지 모르겠습니다. 보도자료에서 눈에 띄는 게 없어요.
그래도 갈아엎기가 심하다는 데는 동의합니다. 경영진 차원에서 소프트웨어 팩토리라는 말이 슬슬 돌고 있는데, 코딩 에이전트의 도움을 받는다 해도 거기에 들이는 큰 노력이 끝날 즈음엔 구식이 되어 있을까 걱정돼요.
10개월 전이라면 동의했겠지만, 지금은 에이전트가 다른 의미입니다. 워크로드를 뜻하죠. 그리고 이제 누가 그런 워크로드를 더 많이 호스팅하고, 이 환경에서 교차 판매와 추가 판매까지 하느냐의 싸움이 벌어지고 있습니다.
그 글의 "Deploy" 섹션이 바로 그 차이를 만들어요.
OpenAI랑 앤트로픽은 이미 1년쯤 전부터 이런 걸 내놓지 않았나요?
네, claude-agents-sdk는 작년 9월쯤 나왔어요.
2026년 10월에 오픈소스 하네스를 안 쓸 이유가 있나요? 진심으로 궁금해서 묻는데, 거기서 얻는 이점이 뭔가요?
저도 오픈소스 하네스를 정말 쓰고 싶어요! 문제는 저한테는 Opus 5.5 / Fable 5.1이 가장 잘 맞는 모델이고, Claude Code Max 구독으로 쓰면 훨씬 싸다는 겁니다. 오픈소스 하네스를 쓰자고 돈을 더 낼 생각은 없어요. 업계가 성숙해질 때까지 기다리면서 Claude Code에 머물고, 도구를 계속 옮겨 다니는 일은 피하려고 합니다.
오픈 하네스에서도 Claude 구독을 아무 문제 없이 쓸 수 있어요!
제가 하나 만들었는데( https://github.com/juggler-ai/juggler ) claude CLI를 자동으로 찾아서 씁니다. 저는 작업의 90%는 그 claude 요금제로 하고, GPT도 조금 쓰는데, claude보다 더 낫고 종속성이 덜한 환경에서 하는 쪽이 그냥 마음에 들거든요.
독점 폐쇄형 하네스에는 사실 해자랄 게 없어요. 갈아타는 건 아주 쉬운데, 그게 가능하다는 걸 사람들이 알아야 합니다!
종속이요? 저는 claude와 codex를 수시로 오가는데, 코드베이스도 스킬도 같고 "메모리"까지 공유해요. 설정하는 데 5분쯤이면 됩니다. 종속은 전혀 없어요.
그건 앤트로픽의 서비스 약관에 어긋나요. 정확히 그렇게 쓰다가 Claude 계정이 정지된 사람들도 있고요.
올해 초에 그 일로 큰 소동이 났던 건, 뭔가(opencode였나?)가 claude CLI인 척하면서 그런 식으로 API를 쓴 탓이었어요. 앤트로픽이 난리를 쳤고, 그러자 GPT 쪽에서 "자체 하네스를 쓰는 건 상관없다"고 하면서 다들 안심했죠. 하네스가 claude CLI를 거치고 꼼수를 부리지 않는 한은요.
맞아요, 앤트로픽에는 Claude CLI 세션을 대신 관리해 주는 "Agent SDK"도 있고, 이걸 쓰는 앱에는 구독 토큰과 별도로 토큰 예산이 따로 있기까지 합니다.
그것도 앤트로픽이 완화했고, Agent SDK 토큰 요금을 쫓아다니는 것도 그만뒀어요. 저는 구독으로 Agent SDK를 일상적으로 쓰는데 별도 예산에서 빠져나가지 않습니다. 약관에도 개인 구독을 상업적 재판매 목적으로 쓰지 말라는 정도로만 두루뭉술하게 적혀 있고요.
Pi는 Claude나 GPT 구독을 쓸 수 있고 아주 잘 동작합니다. 두 구독에 모두 로그인해 두고, 상황마다 가장 잘 맞는 모델로 보내 주는 도구를 직접 만들 수도 있어요. 저는 회사에서 두 곳의 프로 등급 구독을 쓸 수 있고 Claude API 호출용 크레딧도 넉넉합니다. 셋을 모두 쓰는데, 라우터는 JEV로 하고 컨텍스트 관리와 압축은 로컬 모델에 맡겨요. 그랬더니 토큰 사용량이 줄어서 API 호출은 거의 안 쓰는 수준이 됐습니다. 오픈소스 하네스를 처음 시작하는 분께는 oh-mi-pi를 추천해요. 메모리와 컨텍스트 관리 도구가 아주 좋은 게 기본으로 들어 있고 설정도 정말 쉽거든요.
"Claude Pro/Max 앤트로픽 구독 인증은 Claude Pro/Max 계정에서 활성화되어 있습니다. 서드파티 하네스 사용분은 추가 사용량에서 차감되며, Claude 요금제 한도가 아니라 토큰 단위로 과금됩니다."
https://github.com/earendil-works/pi/blob/v0.86.1/packages/coding-agent/docs/providers.md#claude-promax
이제는 그렇지 않다는 건가요?
돈을 더 낼 필요는 없어요. 저도 충동적으로 오픈소스 하네스로 갈아타라고는 안 하겠지만, 쓰시는 하네스나 더 싼 에이전트에서 Claude Code를 헤드리스로 호출하면 되거든요.
참고로 저는 컨설턴트로 일하면서 고객을 대신해 코드를 만들어요. 제게 가장 중요한 건 어느 에이전트가 가장 좋은 코드를 내는지 보려고 여러 모델로 다시 돌려 보지 않고도 코드 품질이 최대한 높은 겁니다. Opus 5.5/Fable 5.1(혹은 다른 모델이든)이 꾸준히 가장 좋은 코드를 내놓는다면, 인지 부담이 줄어드니 모든 작업에 그걸 쓸 거예요.
더 싼 에이전트는 별로 중요하지 않습니다. Max 구독이 100달러인데 제 시급으로 따지면 한 시간도 안 되는 돈이니까요. 어떤 경우에는 고객이 구독료를 대신 내 주기도 하고요.
그래도 Pi나 OpenCode를 쓸 수 있다는 발상은 정말 마음에 듭니다. 저는 터미널을 많이 쓰는 사람이고, 코딩 에이전트가 터미널에 들어오기 전에도 Vim/Tmux/Lazygit 같은 워크플로를 써 왔기 때문에 커스터마이징과 이식성이 좋은 게 좋아요. 다만 지금은 지반이 너무 많이 흔들려서 거기에 끼어들기가 어렵습니다. 기다리는 편이 낫겠어요.
그래도 점진적인 이득을 볼 수 있잖아요. 어쩌면 갈아타는 비용보다 더 클 수도 있고요!
이미 Claude Code를 세팅해 둔 사람이 많고, 새로 뭘 설치하는 것보다 그걸 계속 쓰는 편이 쉽습니다.
많은 사람이 Claude Code의 인터페이스와 명령어 등에 익숙해서 새로운 걸 배우는 비용을 치르고 싶어 하지 않습니다. 이점이 그 갈아타는 비용을 넘어서야 하는데, 과연 그런지는 불분명해요.
Claude Code는 이미 Claude MAX 구독으로 쓸 수 있고[0], 최상위 모델을 엄청난 사용량으로 싸게 쓸 수 있는데 어떤 오픈소스 선택지도 이걸 따라올 수 없습니다. 게다가 대부분의 사람은 이 사용량을 다 쓰지도 않으니 오픈소스 모델을 쓸 실질적인 필요가 없어요.
100% 확인하기는 어렵지만, Claude 자체가 다른 하네스보다 Claude Code와 더 잘 맞는다고 볼 만한 이유가 있습니다.
실제 종속은 없습니다. 내일 Claude Code를 쓰기 싫어지면 다른 걸로 쉽게 갈아타면 돼요. 그러니 구덩이를 파면서 스스로 갇힐까 걱정할 이유가 없고, 따라서 서둘러 벗어날 이유도 없습니다.
[0] 네, 오픈소스 하네스도 Claude MAX 구독을 쓸 수 있습니다. 하지만 오픈소스 하네스의 이런 "이점"이 위의 1, 2, 4번의 비용을 정말 넘어설까요?
이건 거의 정설인 줄 알았는데요. 모든 연구소가 바로 그 이유로 모델과 하네스를 짝지어 둔다는 거요.
Whale Paper. https://arxiv.org/abs/2609.00196
2주쯤 전 EMNLP 발표도 있어요. https://aclanthology.org/2026.findings-emnlp.2207/
네, 저도 그렇게 생각했는데 과장해서 말하고 싶지 않았어요. 그렇다면 대형 연구소의 모델을 쓸 때 오픈소스 하네스를 쓰지 말아야 할 꽤 큰 이유인 셈이네요.
저는 이런 문제를 정면으로 해결하려고 hlock https://docs.hlock.ai/ 을 만들었어요. 하네스 설정을 여러 하네스(오픈소스든 독점이든) 사이에서 옮길 수 있게 해 줍니다.
이 글이 Claude Code가 아니라 Cursor에 관한 거라는 건 아시죠?
저는 기사가 아니라 댓글에 답한 거예요. 그 댓글은 오픈소스 하네스에 대해 묻고 있고, 아마 Cursor만이 아니라 오픈소스가 아닌 모든 하네스와 비교하는 질문일 겁니다.
오픈소스 하네스에는 엄청나게 보조금이 들어간 claude code 구독을 버리고 옮겨 갈 만큼 놀라운 기능이 딱히 없어요. 저는 지시를 입력하면 코드가 나오는 걸로 충분합니다. 점점 더 복잡한 기능이라고 내놓는 것들은 생산성 쇼라는 쪽으로 생각이 기울고 있어요.
맞아요, 너무 웃겨서 죽겠어요. 그 사상가라는 사람들이 앞다퉈 자기 회사를 사실상 앤트로픽이나 OpenAI 같은 곳의 자회사로 만들고 있잖아요. 소프트웨어 전체를 사람이 절대 들여다보지 않는다는 전제로 짜면서요... 결국 앤트로픽 챗봇을 고용해서 전부 맡긴 거나 다름없죠... 그 가격이 오르거나 그 회사들이 망하면, 그렇게 잘난 척하고 으스대던 것과 상관없이 마비되는 회사가 엄청 많을 겁니다. 이 멋진 새 모델들 마케팅의 핵심이 바로 그거라고 생각해요... 회사들이 100% 중독되게 만들고, 어쩌면 그것 없이 일할 사내 인력까지 잃게 만들면... 그다음엔 값이 얼마든 내야 하니까요.
그 사람들은 경력으로 쌓은 실력을 살려서 일반적인 claude 실행을 돌리고 직접 다듬는 것보다, 자기네 "프로세스"에 에이전트를 더 집어넣을 방법과 그게 만든 문제를 또 에이전트로 해결할 방법을 궁리하는 데 더 많은 시간을 씁니다.
엔지니어라는 사람들이 "에이전트" "팀"을 작업에 그냥 풀어놓으면 된다고, 사람이 절대 읽지 않을 1만 줄 넘는 PR을 만들게 놔두고, 그걸 프로덕션에 배포해서 사람이 본 적도 이해하지도 못하는 코드를 돌리면 된다고 말하며 스스로를 완전히 깎아내리는 걸 보면 정말 웃음이 나와요... 제발 돈 줄줄 새는 이 회사들을 떠받들자고 스스로를 깎아내리지 마세요... 그건 도구예요. 강력하긴 하지만 엔지니어는 아니고, 엔지니어는 당신이에요. 도구는 똑똑하지 않고 똑똑한 건 당신이에요. 그러니 빌어먹을 기업 챗봇에게 자기 자리를 내주자고 일부러 주장하지 마세요.
소프트웨어를 그런 식으로 만들 수 있다고 생각하는 회사에서 일해야 한다면 저는 온콜 순번에 들어가는 걸 거부할 겁니다... 그 빌어먹을 물건이 나보다 그렇게 잘나서 검토도 안 한 쓰레기를 프로덕션으로 서둘러 내보내야 한다면, 밤과 주말 온콜 정도는 사람 도움 없이 알아서 해낼 수 있겠죠. 이 열성 신도들한테 프로덕션 온콜 24시간을 전부 봇에게 넘기고, 호출기 순번에 사람은 넣지도 말고 호출도 하지 말자고 해 보세요. 얼마나 많은 사람이 말을 바꾸는지 볼 만할 거예요. 갑자기 진짜 사람이 필요해지죠. 우리가 멍청해서 못 짰던 소프트웨어를 고치려면, 그걸 실제로 짠 봇은 너무 멍청해서 관리를 못 하니까요?
말이 되게 설명해 보세요.
이런 도구로도 수동 모드만 쓰면서 충분히 엄청난 생산성 향상을 얻을 수 있어요. 생성되는 코드를 diff로 읽고, 멍청한 짓을 하면(100% 합니다) 호통을 치고, 예전처럼 사람이 검토할 수 있는 좁은 범위의 티켓과 PR로 일하면 됩니다. 그보다 더 빨리 가야 할 이유가 뭐죠? 그렇게 해서 얻는 건 회사 제품 전체를 다른 회사의 봇이 그날 쏟아내기로 한 결과물에 묶어 두는 것뿐인데요?