Agent SDK

Cursor가 팀별 에이전트를 코드로 정의하고 Cursor 인프라에 배포하는 Agent SDK를 일반 공개했습니다. Git 이벤트에 반응하는 코드 리뷰 에이전트부터 평가와 이벤트 재생을 포함한 업무 자동화까지 지원하며, 자체 인프라에서도 실행할 수 있습니다.

주제: AI 개발 도구 자동화

에디터 노트

배포형 에이전트를 팀 코드로 관리하고 평가와 로그를 함께 제공한다는 점이 이 SDK의 실질적인 제안입니다. PR 이벤트를 처리하는 사례와 약 하루 만에 만든 지식 검토 봇은 적용 방식을 보여주지만, 평가가 어떤 기준과 결과로 이뤄지는지는 공개 내용에 없습니다. 평가 기능이 있다는 사실만으로 업무 정확도가 입증되지는 않습니다. 댓글에서는 자체 코드로 권한과 도구를 통제하려는 요구와 벤더 종속 우려가 함께 나왔습니다. Cursor는 자체 인프라뿐 아니라 컨테이너 기반 자체 실행도 지원한다고 밝혔지만, 관리형 배포의 편의와 벤더 간 이동성은 별개 쟁점입니다. 특히 에이전트 런타임과 이벤트 연동을 직접 구성할 때 줄어드는 운영 부담이 얼마인지, 기존 하네스보다 어떤 평가 결과를 내는지는 자료만으로 비교하기 어렵습니다.

AI 요약

Cursor가 Agent SDK를 일반 공개했습니다. 이 SDK로 팀의 업무 이벤트에 반응하는 에이전트를 코드로 만들고 배포할 수 있습니다. Cursor는 Bugbot, Security Reviewer, Rollouts 같은 관리형 에이전트를 만들 때 사용한 프레임워크라고 설명합니다. 기존 제품의 정해진 업무 흐름을 따르거나 처음부터 모든 것을 만드는 대신, 팀이 직접 에이전트의 동작과 정책을 정의하는 방식입니다.

에이전트 정의와 배포

에이전트 프로젝트에는 지침, 도구 코드, 외부 서비스 연결 정보, 평가 코드가 함께 들어갑니다. 지침은 Markdown으로 작성하고 도구는 TypeScript 함수로 정의합니다. 프로젝트를 일반 소프트웨어처럼 버전 관리하고 변경 사항을 검토할 수 있습니다. 로컬 플레이그라운드에서 에이전트를 실행하고 평가를 반복한 뒤, 프로젝트 디렉터리에서 agent-sdk deploy를 실행하면 Cursor 인프라에 배포됩니다. 명령은 에이전트를 빌드하고 URL을 제공하며 실행을 시작합니다. 시크릿과 연동 설정은 대시보드에서 관리하고, 로컬에서 사용한 로그와 평가, 플레이그라운드도 이어서 사용할 수 있습니다. 자체 인프라에 배포하는 선택지도 있습니다. 각 에이전트는 단일 Node 프로세스로 실행하며 컨테이너에 담을 수 있습니다.

이벤트 기반 코드 리뷰와 에이전트 구성

코드 리뷰 에이전트는 GitHub, GitLab, Bitbucket의 pull request 이벤트에 반응하도록 만들 수 있습니다. 변경 위험도를 평가하고 담당 팀으로 보내거나, 정책을 충족한 변경을 승인하는 작업이 예시로 제시됐습니다. Cursor 내부 팀은 축적된 지식 문서와 충돌하는 변경을 찾는 kb-reviewer를 약 하루 만에 만들었습니다. 이 에이전트는 주 코드베이스의 모든 PR을 확인하고, 기록된 교훈과 모순되는 변경을 표시하면서 근거 문서를 인용합니다. 담당 엔지니어가 보고된 불일치를 해결하도록 안내합니다.

복잡한 작업은 도구와 세션이 다른 전문 에이전트에 넘길 수 있고, 하위 에이전트 여러 개에 나눠 병렬 처리할 수도 있습니다. SDK에는 평가(evals)와 이벤트 재생(event replay)이 포함돼 있습니다. Cursor는 이를 이용해 중요한 업무 흐름이 예상대로 실행되는지 확인하며 빠르게 반복 개발할 수 있다고 설명합니다. PGA Tour는 Agent SDK를 소프트웨어 개발 공장에 사용하고 있으며, 평가 기능으로 작업 속도를 유지한다고 밝혔습니다.

Hacker News 반응

@pscanf — 활용 사례가 많습니다. 다만 앱을 특정 벤더에 묶고 싶지 않으니 OpenResponses 같은 표준이 생기면 좋겠습니다. 제공 기능은 대체로 비슷해 보입니다.
@simianwords — 에이전트 SDK의 API는 도구와 함께 LLM을 실행하는 런타임과 PROMPT.md만으로 구성하면 안 되나요? LangChain 같은 추상화가 더 필요한 이유가 있나요? 결정성을 위한 경계가 필요한가요?
- @ashishmax31 — LLM에 도구를 붙여 실행하는 런타임이 바로 LangChain으로 만드는 부분입니다. 범용 셸과 도구를 제공하는 하네스와 달리, 직접 만든 런타임은 코드로 특정 도구를 제공할 수 있습니다. 사용자의 권한에 맞춰 도구 범위를 제한하는 데 도움이 됩니다.
- @zomtorg — 기업은 제약 없는 LLM과 도구를 그대로 두기 어렵습니다. 업무 단계마다 모델, 도구, 제약, 가드레일을 달리할 수 있어야 합니다. 보안·법무 팀에 데이터 처리와 로그, 에이전트의 예상 밖 행동을 어떻게 통제하는지 설명하기도 편합니다.
@fg137 — 효과가 더 좋은지 입증할 벤치마크도 없이 워크플로 스킬을 만드는 데 많은 시간을 쓰는 사람들이 보입니다.
- @andyfilms1 — 성능 향상이 있다면 특별한 에이전트 간 마법보다 한 작업에 컨텍스트 윈도우를 세 배 할당한 결과일 것 같습니다.
- @kentm — 성능이 더 좋다고 한다면 어떻게 측정하나요?
@gawacer — AI 도구도 이제 JavaScript 프레임워크가 겪은 잦은 교체 국면에 들어섰습니다.
- @fullstackwife — 에이전트는 이제 워크로드를 뜻합니다. 누가 더 많은 워크로드를 호스팅하고 다른 서비스를 교차 판매할지가 경쟁입니다. 글에서 배포 부분이 차이를 만듭니다.
@h0rv — 2026년 10월에 오픈소스 하네스를 쓰지 않을 이유가 있나요? 정말 궁금합니다.
- @csallen — 이미 Claude Code를 설정한 사람은 새 도구를 설치하고 익히는 비용을 감수할 만큼의 이점이 불분명합니다. Claude Max 구독으로 상위 모델을 저렴하게 쓸 수 있고, 내일 다른 도구로 옮겨도 되므로 잠금 효과도 크지 않다고 봅니다.
@everforward — 기존 하네스 상당수는 사람과 상호작용하는 용도라 복잡성이 큽니다. 웹훅으로만 시작하는 에이전트는 UI 기능이 필요 없고, 기본적으로 로컬 상태를 남기지 않는 편이 나을 수도 있습니다. 에이전트 SDK는 더 세밀하게 제어할 수 있지만 비슷한 제품이 매우 많습니다.

원문: Cursor / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗