Cursor와 통화하면 코드도 바뀔 수 있습니다: 받아쓰기·작업 전달·로그인·보존 조건

말로 “이 부분을 바꿔 줘”라고 했을 때, 입력창에 문장만 생기는가, 아니면 코딩 에이전트에게 일이 전달되는가. Cursor의 새 음성 통화를 고를 때 먼저 나눌 질문이다. 전자는 전송 전 검토 단계가 남는 받아쓰기이고, 후자는 에이전트가 음성으로 답하면서 코딩 작업도 넘기는 양방향 대화다. 같은 마이크 주변에 있는 기능이라도 작업이 시작되는 경계가 다르다.

문장을 고친 뒤 직접 전송해야 하는 작업은 받아쓰기부터, 진행 중인 코딩 작업을 말로 감독하고 후속 지시를 전달할 작업은 음성 통화부터 검토한다. “손을 쓰지 않고 입력한다”보다 “누가 작업 지시를 전달하는가”로 선택하면 잘못된 기대를 줄일 수 있다.

Cursor는 2026년 11월 6일 Voice Chat with Agents를 발표했다. 아래는 11월 7일 수집·보존한 공식 발표와 문서를 기준으로 한 해설이다. 11월 8일은 이 글의 공개 예정일이지 기능 발표일이나 예약 완료일이 아니다. 이 글은 공식 발표와 보존한 사용 문서를 분석한 것이며 실제 계정의 통화·코드 변경·보존 동작이나 성능을 시험한 결과가 아니다.

1. 받아쓰기는 검토할 문장, 통화는 작업을 전달하는 대화다

기존 릴리스에서 Voice Mode라고 불렀던 것은 받아쓰기다. 공식 문서는 받아쓰기가 음성을 채팅 입력창의 텍스트로 바꾸고, 사용자가 검토한 뒤 전송한다고 설명한다. 새 음성 통화는 에이전트가 말로 답하며, 현재 채팅의 코딩 에이전트에게 작업이나 후속 지시를 보낼 수 있다. 단순한 이름 변경으로 묶으면 안 된다. [1][2: Voice chat and dictation]

입력창의 문장을 사용자가 검토·전송하는 받아쓰기와 음성 에이전트가 코딩 작업을 전달하는 통화의 차이

받아쓰기와 통화는 전송 주체가 다르다. 공식 문서를 재구성한 자체 비교도이며 실제 UI나 실행 결과가 아니다. 출처: cursor.com/docs/agent/voice-chat.

다음 표는 기능 목록을 옮긴 것이 아니라, 무엇을 맡기려는지에 따라 선택을 나눈 편집상 판단표다. 제품에서 실행해 얻은 성공률이나 생산성 비교가 아니다.

지금 하려는 일 먼저 검토할 경로 그 이유와 남는 판단
오류 설명을 길게 말한 뒤 표현·민감정보를 고쳐 보내기 받아쓰기 텍스트가 입력창에 생긴 뒤 사용자가 검토·전송한다. 전송 전 검토가 중요한 목적에 맞는다.
진행 중인 수정의 상태를 묻고 추가 지시를 말로 전달하기 음성 통화 말로 답변을 받고 현재 채팅의 코딩 에이전트에게 후속 작업을 넘길 수 있다. 작업 범위는 따로 정한다.
변경 diff만 설명받기 통화의 조회 기능 검토 diff·실행 상태·에이전트 조회는 읽기 전용이다. 통화 전체를 읽기 전용으로 오해하지 않는다.
업무용 코드를 처음 맡기기 권한·승인 범위부터 확인 말로 전달했다는 이유로 쓰기나 실행 승인 검토를 생략하지 않는다는 운영 제안이다.

예를 들어 “오류 메시지를 정리해서 보고문 초안을 만들고 싶다”는 요구와 “실패하는 테스트를 고치고 진행 상황을 알려 달라”는 요구는 다르다. 앞의 경우에는 말한 내용을 검토할 기회가 중요하고, 뒤의 경우에는 작업 전달과 결과 확인이 중요하다. 이는 선택 기준을 설명하는 가상 사례이며 실제 통화 기록이 아니다.

2. 읽기 전용 조회와 코드 변경 위임은 한 통화 안에 공존한다

문서의 How it works는 음성 에이전트가 diff, 실행 상태, 에이전트 정보를 읽는 조회를 read-only라고 설명한다. 동시에 현재 채팅의 코딩 에이전트에 작업과 후속 지시를 전달할 수 있다고 명시한다. 따라서 “음성 기능은 읽기 전용이라 코드가 바뀌지 않는다”는 결론은 틀리다. 읽기 전용이라는 수식은 해당 조회에 붙는 것이지 통화의 모든 행위에 붙는 것이 아니다. [2: How it works]

사용자와 Grok Voice의 양방향 음성 및 선택한 모델의 코딩 에이전트로 이어지는 작업 전달 관계

듣기·말하기는 Grok Voice, 코딩은 채팅에서 선택한 모델이 맡는다. 조회의 읽기 전용과 코드 변경 위임은 다르며 승인 정책의 보장은 아니다. 출처: cursor.com/docs/agent/voice-chat.

모델도 두 역할로 나눠 읽어야 한다. Grok Voice는 듣기와 말하기를 담당한다. 채팅의 코딩 에이전트는 사용자가 이미 선택한 모델을 계속 쓴다. Grok Voice 도입을 코딩 모델의 일괄 교체라고 소개할 근거는 없다. 또한 공식 설명의 짧은 진행 음성은 전체 서면 답변과 항상 같은 길이가 아니다. 코딩 에이전트가 짧은 음성 업데이트를 선택하고, 그 턴에 별도 음성 업데이트를 쓰지 않으면 서면 답변을 읽는다고 안내한다. [2: Models / FAQ]

팀에서 도입한다면 “설명만 요청하는 단계”와 “수정을 맡기는 단계”를 운영상 나누는 편이 합리적이다. 수정 요청 뒤에는 실제 diff와 필요한 테스트 결과를 기존 리뷰 절차에서 확인한다. 이것은 이 글의 권고이며, 특정 승인 설정이 기본으로 켜진다거나 통화가 별도의 보안 장벽을 만든다는 제품 보장이 아니다.

3. 버튼이 없을 때와 버튼은 있는데 실패할 때는 다르다

지원 경로는 Agents Window, IDE, 웹, Cursor iOS 앱이다. 기본 시작 조건은 에이전트가 대기 상태이고 채팅 입력창이 비어 있는 것이다. IDE에서는 채팅에 메시지가 최소 하나 있어야 한다. 에이전트가 실행 중이면 같은 위치를 Stop이 사용한다. 옆의 마이크 버튼은 받아쓰기이므로 파형 모양의 Start voice chat과 구분해야 한다. [1: Start a call][2: Start a voice chat]

버튼 부재와 로그인 오류 및 마이크 차단을 구분하는 네 단계 진단표

버튼 노출은 통화 자격의 증거가 아니다. 공식 시작·FAQ 조건을 편집상 진단 순서로 재구성했으며 실제 계정의 장애 재현이 아니다. 출처: cursor.com/docs/agent/voice-chat.

증상을 다음 순서로 나누면 로그인 문제를 버튼 배치 문제로 오인하지 않을 수 있다. 순서는 공식 조건을 재구성한 진단 제안이지 실제 계정의 장애를 재현한 결과가 아니다.

  1. 버튼 자체가 없다면 입력창의 텍스트와 에이전트 실행 상태를 먼저 본다. IDE에서는 기존 메시지 유무도 확인한다.
  2. 채팅 종류를 확인한다. FAQ는 Subagents와 Project workers, 보관된 채팅, Claude Code 채팅, 다른 팀원이 소유한 채팅에서 버튼이 숨겨진다고 명시한다. IDE에서는 스트리밍 중인 클라우드 에이전트와 받아쓰기가 꺼진 상태도 제외 조건이다. 해당하지 않으면 Cursor 업데이트를 확인하라는 안내가 이어진다.
  3. 버튼은 보이는데 Realtime voice requires sign-in으로 실패하면 Cursor 계정 로그인을 확인한다. API 키로 인증한 세션은 통화를 시작할 수 없다. 버튼이 로그아웃·API 키 상태에서도 보일 수 있으므로 버튼 노출이 이용 자격의 증거는 아니다.
  4. 마이크가 차단됐다는 안내라면 운영체제나 브라우저 설정의 마이크 접근을 확인한다. 계정 로그인과 마이크 권한은 서로를 대신하지 않는다.

FAQ에서 Project worker 채팅에 시작 버튼이 숨겨진다는 조건과, 연결된 통화에서 Project의 다른 worker로 이동할 수 있다는 설명은 진입 단계가 다르다. “worker로 전환할 수 있으니 모든 worker 채팅에서 통화를 시작할 수 있다”고 확대하지 않는다. [2: How it works / Requirements / FAQ]

4. 약 10분은 최대 통화 시간이 아니며, ZDR에는 모드 조건이 붙는다

Call limits의 기본 종료 조건은 사용자의 침묵이 약 10분 이어지고 에이전트가 진행 중인 작업도 없는 경우다. 두 조건을 떼어 “통화는 최대 10분”이라고 쓰면 의미가 바뀐다. 일일 통화 제한도 있지만, 보존한 문서는 정확한 일일 분량·횟수나 요금제별 상한을 제시하지 않는다. 무제한·무료라고 가정하거나 임의의 할당량을 채울 근거가 없다. [2: Call limits]

약 10분 침묵과 진행 작업 없음의 결합 조건, 미기재 일일 할당량, Privacy Mode 조건부 ZDR을 나눈 표

약 10분은 기본 무작업·침묵 종료 조건이지 최대 통화 시간이 아니다. 일일 제한의 수치는 미기재이며 ZDR 설명은 Privacy Mode가 켜졌을 때에 한한다. 출처: cursor.com/docs/agent/voice-chat.

Privacy Mode가 켜졌을 때 음성 통화가 zero data retention으로 동작한다는 것은 공식 문서의 설명이다. 모든 계정과 모든 모드가 무조건 무보존이라는 뜻으로 바꿔서는 안 된다. 문서는 통화 대화록이 채팅에 나타나며, 클라우드 에이전트의 대화록은 Privacy Mode가 아닌 경우 통화 중 다른 기기로 동기화된다고도 설명한다. 이 설명만으로 실제 데이터 경로나 조직의 보존·감사 요구 충족까지 독립 검증됐다고 볼 수 없다. [1: Powered by Grok Voice][2: How it works / Privacy]

업무 도입 판단에서는 세 줄을 따로 남기는 것이 유용하다. 첫째는 사용할 계정과 마이크 접근 상태, 둘째는 코딩 작업을 맡길 범위와 결과 검토 방식, 셋째는 Privacy Mode 상태와 조직이 허용하는 입력 정보다. 이것은 공식 설정 화면의 새 체크박스 목록이 아니라 이 글의 운영상 정리다. 일일 한도의 수치는 확인 전까지 미확인으로 남기는 편이 정확하다.

5. 도입의 기준은 음성 품질보다 작업 경계다

받아쓰기는 말한 문장을 검토해 보내는 경로이고, 통화는 말로 응답받으며 작업을 전달하는 경로다. 단순히 타이핑을 줄이고 싶은지, 코딩 작업을 대화로 감독하려는지부터 나누면 된다. 통화가 맞는 경우에도 지원 화면, 시작 조건, 계정 로그인, 마이크 권한, 조회와 작업 전달의 차이, Privacy Mode의 조건은 각각 남는다.

이번 발표를 “에이전트가 말한다”로만 읽기보다 “말한 요청이 어디까지 작업으로 이어지는가”로 읽는 것이 실용적이다. 음성의 편의가 생겨도 코드 변경의 검토 책임이나 확인되지 않은 사용 한도까지 사라지는 것은 아니다.

함께 읽을 글

출처와 확인 범위

[1] Cursor, Voice Chat with Agents — https://cursor.com/changelog/voice-chat — 발표 표시일 2026-11-06, 보존 시각 2026-11-07 08:02:53 KST.

[2] Cursor Docs, Voice chat — https://cursor.com/docs/agent/voice-chat — Start a voice chat, How it works, Models, Requirements, Call limits, Privacy, Voice chat and dictation, FAQ. 2026-11-07 08:02:53 KST 보존본 기준이며 문서에 없는 일일 할당량이나 계정별 동작을 보충하지 않았다. 도해 네 장은 이 근거를 재구성한 자체 설명도이며 실제 UI·측정 결과가 아니다.

댓글

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다