글

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 . 다음 표는 기능 목록을 옮긴 것이 아니라, 무엇을 맡기려는지에 따라 선택을 나눈 편집상 판단표다. 제품에서 실행해 얻은 성공률이나 생산성 비교가 아니다. 지금 하려는...
댓글 쓰기
자세한 내용 보기

Copilot 리뷰 처리율은 수정 완료율이 아닙니다: 분모·병합일·봇 PR 해석법

이미지
팀 보고서의 열 이름을 ‘AI 리뷰 수정 완료율’로 바꾸기 전에 멈춰야 한다. GitHub가 2026년 11월 5일 발표한 Copilot usage metrics API의 addressed rate는 개발자가 평가 대상 리뷰 댓글에 대응했는지를 보여준다. ‘다음 PR에서 고치겠다’고 답한 경우도 대응에 들어간다. 따라서 수치가 높아졌다는 사실만으로 현재 코드에서 수정이 끝났거나 결함이 제거됐다고 말할 수 없다. 실무에서 먼저 바꿀 것은 목표 수치보다 보고서의 이름이다. ‘수정 완료율’ 대신 ‘평가된 Copilot 리뷰 댓글 대응 비율’이라고 적고, 실제 수정 완료를 판단할 근거는 별도로 둔다. 이 구분만으로도 후속 작업 약속이 완료 실적으로 섞이는 문제를 줄일 수 있다. 이하의 공식 정의는 선정 단계에 보존한 원문을 기준으로 설명하며, 운영 제안은 편집자 해석으로 구분한다. 분모는 PR도 전체 댓글도 아니라 평가된 댓글이다 기업·조직의 저장소 단위 repos-1-day 보고서에는 copilot_code_review 객체가 들어간다. 핵심 값은 total_comments_evaluated 와 total_comments_addressed 다. 전자는 개발자의 대응 여부를 평가한 Copilot 리뷰 댓글 수이고, 후자는 그 평가된 댓글 중 개발자가 대응한 수다. 공식 비율은 다음과 같다. addressed rate = total_comments_addressed / total_comments_evaluated 백분율로 표시하더라도 분모의 의미는 바뀌지 않는다. 전체 PR 개수나 생성된 모든 리뷰 댓글 수를 대신 넣으면 다른 지표가 된다. 대시보드에는 비율만 띄우지 말고 분자와 분모도 함께 보여주는 편이 낫다. 평가 대상이 적은 구간과 많은 구간을 같은 무게의 성과로 읽지 않기 위해서다. 여러 일자를 합칠 때도 일별 비율의 단순 평균보다는 같은 조건의 댓글 수를 먼저 합쳐 해석하는 방식을 권한다. 이는 집계 설계 제안이지 GitHub가 새로 보장하는 계산...
댓글 쓰기
자세한 내용 보기

같은 요청으로 워크플로가 두 번 시작된다면: 원자적 시작·토큰 보존·해제 경계

이미지
주문 접수 API가 응답하지 않아 클라이언트가 같은 요청을 다시 보냈다. 서버는 먼저 “이 주문을 처리하는 실행이 있나?”를 조회한 다음, 없으면 워크플로를 시작한다. 평소에는 괜찮지만 두 요청이 동시에 조회하면 둘 다 없다는 답을 받고 각각 시작할 수 있다. 조회를 추가했다는 사실만으로 조회와 시작 사이의 틈이 없어지는 것은 아니다. Workflow SDK의 원자적 시작은 이 경계를 바꾼다. 실행을 받아들이는 일과 Hook 토큰을 차지하는 일을 한 단계로 묶는다. 토큰을 가진 소유자가 있으면 중복 요청은 새 실행이 되지 않고 충돌로 돌아온다. 다만 이 보장은 토큰을 붙잡고 있는 동안의 실행 시작에 관한 것이다. 결제·발송 같은 외부 효과까지 무조건 한 번만 일어난다는 뜻은 아니다. 이 글은 공식 문서와 고정된 패키지 선언을 대조한 설계 해설이며, SDK 실행이나 장애 주입 실험 결과가 아니다. 아래 판단표와 도식은 문서의 상태 전이를 독자가 운영 분기로 옮길 수 있도록 새로 정리한 것이다. 1. 조회 결과가 아니라 시작의 소유권을 원자적으로 정한다 2026년 11월 4일 Vercel 발표 는 기존 getHookByToken() 다음 start() 패턴의 중복 시작 경쟁을 설명한다. 두 요청이 같은 조회 결과를 보고 출발할 수 있으므로, “없음을 확인했다”와 “내가 유일한 소유자다”는 다른 주장이다. 원자적 시작에서는 start() 옵션의 experimental_hook.token 에 안정적인 업무 식별자를 넣는다. 주문 ID나 가져오기 작업 ID처럼 같은 일을 재시도할 때도 유지되는 값이 출발점이다. 요청이 올 때마다 무작위 토큰을 새로 만들면, 시스템 입장에서는 서로 다른 일처럼 보인다. 여러 고객이 같은 주문 번호를 쓸 수 있는 서비스라면 업무 범위도 키 설계에서 구분해야 한다. 이 범위 구분은 문서의 업무 키 원칙에서 도출한 편집상 권고이지 SDK가 자동으로 보장하는 권한 검사 기능이 아니다. 그림 1. 조회와 시작의 틈 대신 수락과 토...
댓글 쓰기
자세한 내용 보기

15초 영상을 다시 만들기 전: Gemini Omni 1.2 Flash의 편집·720p 가격 경계

이미지
제품 소개 영상에서 구도는 마음에 드는데 배경만 바꾸고 싶다면, 같은 프롬프트로 처음부터 다시 만드는 것이 유일한 선택일 필요는 없다. Google이 발표한 Gemini Omni 1.2 Flash에서 먼저 볼 변화는 클립 길이만이 아니라 같은 영상을 대화로 이어 고치는 작업 흐름이다. 수정할 요소가 배경이나 조명처럼 좁고 유지할 요소가 분명하면, 전체 재생성보다 대화형 편집을 먼저 비교할 후보가 된다. 반대로 빠른 스포츠 동작이나 복잡한 물리 상호작용이 핵심인 장면은 이번 발표만으로 안정성을 판단하기 어렵다. 이 글은 짧은 영상을 여러 버전으로 만드는 제작자와 개발자가 도입 범위를 정하기 위한 분석이다. Google의 발표와 작성한 작업 예시를 구분하고, 720p 초당 단가를 프로젝트 전체 견적이나 모든 앱의 이용료로 확대하지 않는다. 실제 모델 호출, 생성물 품질 비교, 계정별 이용 가능 여부, 청구 내역은 시험하지 않았다. 무엇이 바뀌었고, 발표 날짜는 언제인가 공식 글의 게시일은 미국 표기 2026년 11월 5일이다. 보존한 원문의 게시 메타데이터를 한국 시간으로 바꾸면 11월 6일 오전 2시이며, 이 글의 예정 공개일인 11월 7일과는 구분된다. Google은 Gemini API와 Gemini for business에서 정식 제공한다고 발표했다. 그렇다고 모든 Gemini 앱 계정이나 구독 등급에서 동시에 쓸 수 있다는 뜻은 아니다. 원문 말미는 제품별 이용 경로와 순차 적용 대상을 따로 설명한다. 기능상으로는 네이티브 생성·편집 길이가 Omni 1.1의 최대 10초에서 1.2 Flash의 최대 15초로 늘었다. 길이는 3초부터 15초까지 1초 단위로 지정할 수 있다. 이것은 한 클립의 길이 범위이지 여러 컷을 조합한 완성 영상의 길이 제한이나, 생성한 결과가 그대로 사용 가능하다는 보장은 아니다. 참조로 넣을 수 있는 짧은 움직임 클립은 최대 3초로 설명되어 있다. 여기서 3초는 입력 참조의 길이이고, 출력 영상의 최대 길이인 15초와 역할이 ...
댓글 쓰기
자세한 내용 보기

PyTorch 코드를 TPU로 옮겼다면: XStack의 새 환경 재실행·원 실험·가중치 검증

이미지
GPU에서 쓰던 PyTorch 학습 저장소를 TPU용으로 바꿨고, 학습 로그에 목표 점수까지 찍혔다. 이제 이관을 끝냈다고 받아도 될까? XStack을 읽을 때 가장 유용한 질문은 어떤 모델이 코드를 많이 바꿨느냐가 아니라, 그 점수가 새 환경에서 원 실험을 수행한 결과인지, 마지막 가중치를 원 모델이 받아들이는지다. 먼저 숫자의 단위를 분리하자. 논문 v1의 최종 결과는 20개 저장소와 일곱 모델–하네스 구성을 조합한 140개 평가 칸 중 44개 통과다. 약 31.43%이며, 140개 서로 다른 저장소나 AI 코딩 전체의 성공률을 뜻하지 않는다. 이와 별개인 ‘수치 기준을 넘긴 102개 결과’는 두 평가 단계에서 나온 결과의 수다. 이 둘을 같은 분모의 퍼널처럼 연결하면 연구가 말하지 않은 성공률을 만들게 된다. [1, §3.1–3.2, Table 4] 이 글의 결과물은 이관 인수용 승인표다. 환경 재실행, 원 실험의 결과 출처, 원 모델 가중치 로딩을 서로 다른 승인 칸으로 남긴다. 논문의 순위를 현재의 구매 추천으로 바꾸거나 TPU 실험을 직접 재현했다고 주장하지 않는다. 1. 이관 결과물을 파일 묶음이 아닌 재실행 계약으로 받기 저자 저장소의 설명에 따르면 제출물에는 환경을 만드는 setup_env.sh , 학습·평가와 지표 출력을 맡는 run_train.py , 원 PyTorch 모델의 파라미터 이름으로 가중치를 내보내는 export_torch.py 가 들어간다. 채점에는 새로 초기화한 TPU를 쓰며, 목표 수치와 모델 판정, 원 모델 가중치 로딩을 따로 확인한다. [2, How it works] 제출 파일 세 개와 인수 증거의 연결. 새 환경의 학습·평가와 원 모델 가중치 로딩은 같은 확인이 아니다. 저자 README를 바탕으로 재구성했다. 출처: github.com/zlab-princeton/XStack/blob/b779f82fc0af90ff6032db9dd45bd3fcbf43fcbd/README.md . 이 구조를 실무에 적용한다면 ...
댓글 쓰기
자세한 내용 보기

localhost 앱을 팀 도구로 옮기기 전: Cursor Apps의 DB·인증·공개 승인 경계

이미지
노트북에서만 열리는 대시보드를 동료가 쓰게 하려면 코드를 만드는 일 다음에 호스팅, 데이터 저장, 로그인, 공개 범위를 결정해야 한다. Cursor가 2026년 11월 5일 발표한 Apps는 Cloud Agent가 이 연결 작업을 맡는 경로다. 다만 “링크가 생긴다”와 “아무나 열 수 있다”, “보안 검사가 있다”와 “업무용으로 안전함이 입증됐다”는 각각 다른 말이다. 공식 발표 와 Apps 문서 를 구분해 보면, 이번 기능을 평가할 질문은 코드 생성 속도보다 팀의 데이터·열람·게시 권한을 어디에 둘 것인가에 가깝다. 내부 버그 접수 도구라면 공개 링크부터 만드는 대신 초대 대상, 저장할 데이터, 게시 승인자를 먼저 정하는 편이 맞다. 아래 판단표와 배포 경계도는 그 결정을 돕기 위한 자체 분석이다. 그림은 공식 UI를 촬영한 화면이 아니라 문서의 관계를 다시 그린 설명도다. 1. 로컬 에이전트가 아니라 Cloud Agent의 앱 배포 경로다 공식 문서는 앱을 만들겠다는 의도를 명시하고 Cloud Agent를 사용하라고 안내한다. 로컬 에이전트에서는 이 기능을 지원하지 않는다. 새로 시작하면 Cursor Origin에 저장소를 만들 수 있고, 기존 GitHub 저장소의 앱 배포도 요청할 수 있다. 이미 돌아가는 localhost 앱을 어떤 환경에서도 그대로 옮겨 준다는 호환성 보장은 아니다. GitLab 등 다른 공급자를 현재 지원한다고 읽어서도 안 된다. 발표에서 다른 git 공급자 지원은 향후 계획으로 구분된다. 문서상 Cursor는 팀 또는 개인을 위한 전용 호스팅 계정을 만들고 다른 팀·사용자의 계정과 격리한다. 데이터베이스가 필요한 앱에는 Postgres를 자동 마련한다. 여기서 “필요하면”이 중요하다. 모든 앱에 데이터베이스가 무조건 생긴다는 뜻도, 기존 사내 데이터가 자동으로 연결된다는 뜻도 아니다. 다른 시스템을 쓰려면 연결 자원과 필요한 비밀값을 별도로 설정해야 한다. 앱 제작과 배포 자원을 맡기는 경로와 팀에 남는 운영 판단은 다르다...
댓글 쓰기
자세한 내용 보기

짧게 생각하라는 지시와 강제 종료는 다르다: 코딩 모델의 최종 답 예산·정답률 손익

이미지
로컬 코딩 모델이 한참 생각하다가 출력 한도에 도달했는데, 정작 가져다 쓸 최종 코드가 없다면 무엇부터 바꿔야 할까요? “짧게 생각하고 답하라”는 프롬프트와, 정해진 시점에 추론 구간을 닫고 답 생성을 이어 가는 디코더 제어는 같은 기능이 아닙니다. 전자는 행동을 요청하고 후자는 전환을 강제합니다. 그리고 답이 나오게 만드는 것과 답이 맞게 만드는 것도 다른 목표입니다. 2026년 11월 4일 제출된 Lukas Twist·Helen Yannakoudakis·Jie M. Zhang의 사전공개 논문은 이 차이를 코딩 과제로 비교합니다. 특히 Qwen3-8B에서 입력·출력·예외 상황·설계 고려사항을 짧게 검토하라는 aspects 지시는 평균 넘침을 크게 줄였지만, 과제별 정답률은 서로 다른 방향으로 움직였습니다. 이 글은 가장 좋아 보이는 평균 하나가 아니라, 프롬프트 변경을 채택할 때 잃을 수 있는 정답까지 함께 살펴봅니다. 동료심사 통과 여부는 확인되지 않았습니다. 논문 v1, §VI-C 1. 최종 답이 없는 실패부터 따로 세기 논문의 reasoning-trace overflow, 여기서는 ‘추론 넘침’은 단순히 생각이 길다는 뜻이 아닙니다. 생성 예산을 모두 사용했는데도 추론 종료 구분자 </think> 가 나오지 않아 최종 답 구간이 비어 있는 경우입니다. 길게 생각한 뒤 정상적으로 코드를 내놓은 생성은 이 실패에 포함되지 않습니다. 반대로 미완성 추론 안에 코드 조각이 있더라도 논문은 이를 최종 답으로 구제하지 않습니다. 명시적 구분자에 따른 판정이라는 조건이 중요합니다. 정의와 판정, §III·§V-D 실무 로그에서도 먼저 세 가지를 구분할 필요가 있습니다. 한도에 닿아 최종 답이 없는 경우, 최종 답은 있지만 테스트에 실패한 경우, 답 작성 중 한도에 닿은 경우입니다. 이들을 모두 ‘모델이 오래 생각함’으로 합치면 프롬프트 실험의 효과를 해석하기 어렵습니다. 마지막 경우는 답을 쓸 공간 자체의 문제일 수 있으므로 추론 종료 여부만 확인...
댓글 쓰기
자세한 내용 보기