Vibe Programming Lab

말로 “이 부분을 바꿔 줘”라고 했을 때, 입력창에 문장만 생기는가, 아니면 코딩 에이전트에게 일이 전달되는가. 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 . 다음 표는 기능 목록을 옮긴 것이 아니라, 무엇을 맡기려는지에 따라 선택을 나눈 편집상 판단표다. 제품에서 실행해 얻은 성공률이나 생산성 비교가 아니다. 지금 하려는...

팀 보고서의 열 이름을 ‘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. 조회와 시작의 틈 대신 수락과 토...

제품 소개 영상에서 구도는 마음에 드는데 배경만 바꾸고 싶다면, 같은 프롬프트로 처음부터 다시 만드는 것이 유일한 선택일 필요는 없다. 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초와 역할이 ...

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 . 이 구조를 실무에 적용한다면 ...

노트북에서만 열리는 대시보드를 동료가 쓰게 하려면 코드를 만드는 일 다음에 호스팅, 데이터 저장, 로그인, 공개 범위를 결정해야 한다. 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 실무 로그에서도 먼저 세 가지를 구분할 필요가 있습니다. 한도에 닿아 최종 답이 없는 경우, 최종 답은 있지만 테스트에 실패한 경우, 답 작성 중 한도에 닿은 경우입니다. 이들을 모두 ‘모델이 오래 생각함’으로 합치면 프롬프트 실험의 효과를 해석하기 어렵습니다. 마지막 경우는 답을 쓸 공간 자체의 문제일 수 있으므로 추론 종료 여부만 확인...

노트북을 닫은 뒤에도 코딩 작업이 계속된다면 편리하다. 하지만 화면이 꺼졌다는 이유로 사용량도 멈추는 것은 아니다. GitHub가 2026년 11월 3일 발표한 JetBrains Air의 Copilot 연동에서 먼저 읽어야 할 부분은 에이전트 선택 화면보다 어디서 사용량을 확인하고, 누가 추가 사용을 막을 수 있는가 다. 핵심은 간단하다. Air Teams의 Copilot 클라우드 작업은 JetBrains AI 크레딧이 아니라 기존 GitHub Copilot 플랜을 사용한다. 그런데 Air의 거버넌스·분석 기능에는 Copilot 사용량이 포함되지 않으며, Air 안에서 Copilot 지출 상한을 설정할 수도 없다. 기존 구독을 연결한다는 말은 무료·무제한이라는 뜻이 아니다. 이 구분을 놓치면 작업 관리 화면이 곧 비용 통제 화면이라고 오해하기 쉽다. 실행 화면과 비용 관리 화면은 같은 것이 아니다 Air는 공식 GitHub Copilot CLI를 ACP(Agent Client Protocol)로 연결한다. 새로운 별도 모델을 발표한 것이 아니라, Copilot 에이전트를 Air의 작업 흐름에서 선택하고 결과를 검토하는 연동이다. 로컬 IDE 작업과 Air Teams 클라우드 작업은 진입 조건부터 구분해야 한다. Air에서 작업을 시작할 수 있다는 사실과, 그 작업의 지출을 Air에서 제한할 수 있다는 사실은 다르다. 실행·관측·기능 차단은 별개의 역할이다. 관리자 비활성화는 금액 상한이 아니며 진행 중 작업의 즉시 취소 효과를 입증하지 않는다. 출처: github.blog/changelog/2026-11-03-github-copilot-is-now-available-in-jetbrains-air . 다음 표는 공식 기능 설명을 팀의 도입 판단으로 바꾼 편집상 운영안이다. 제품이 이 역할 분담이나 자동 예산 차단을 대신 설정해 준다는 뜻은 아니다. 판단할 질문 공식 안내에서 확인되는 경계 팀에서 미리 정할 운영안 어느 구독을 쓰는...

시스템 지침에 “한국어로 답하라”라고 적었는데 응답이 어긋나면, 모델부터 바꾸고 싶어진다. 하지만 지침이 모델까지 도착하지 않았다면 모델 교체는 원인과 다른 곳을 고치는 일이 된다. Simon Willison의 Python 라이브러리 LLM 0.37.1은 바로 이 구분이 필요한 요청 구성 결함을 수정했다. 여기서 LLM은 대규모 언어 모델 일반을 뜻하는 말이 아니라, 해당 이름의 CLI·Python 라이브러리다. 핵심은 특정 조합이다. Python API의 prompt() 나 chain() 에 system= 과 messages= 를 함께 넘길 때, prompt.messages 로 요청을 구성하는 모델에서 시스템 지침이 빠지던 문제가 수정됐다. 기본 OpenAI Chat 모델도 이 경로에 포함된다. 모든 지침 불이행을 설명하는 버그나 모델 자체의 지능 향상으로 읽어서는 안 된다. 공식 릴리스 가 명시한 범위다. 1. 코드의 인자와 실제 전달 메시지를 나눠 본다 system=에 문자열이 있다는 사실과 실제 요청의 첫 메시지가 system이라는 사실은 다르다. 애플리케이션이 별도로 보관한 지침, 라이브러리 내부의 메시지 목록, 어댑터가 만든 요청 본문은 서로 다른 관찰 지점이다. 앞 단계의 값이 정상이라는 이유만으로 다음 단계도 정상이라고 결론 내릴 수 없다. 함수에 지침을 적은 사실만으로 실제 요청에 포함됐다고 단정할 수 없다. 릴리스 범위를 해석한 원본 도식이다. 출처: github.com/simonw/llm/releases/tag/0.37.1 . 이번 수정에서 먼저 확인할 것은 답변의 문체가 아니라 요청 구성이다. 함수 인자를 기록한 로그만 보지 말고, 사용 중인 어댑터가 어떤 입력에서 요청을 만드는지 확인해야 한다. 그 어댑터가 prompt.messages 를 사용한다면 실제 목록에 role: system 이 포함되는지가 중요한 증거다. 제공자마다 표현 방식이 다를 수 있으므로 모든 API가 반드시 같은 JSON 구조를 가진다고 일반화하지 않는다....

AI 코딩 도구가 기능을 만들면서 새 npm 의존성을 추가했고, 로컬에서는 실행되는데 Vercel 배포만 실패했다면 무엇부터 고쳐야 할까. 캐시가 오래됐다고 생각해 같은 커밋을 다시 빌드하기 전에, 오류가 지목한 패키지 이름과 버전을 먼저 확인하는 편이 낫다. 이번 변경은 단순한 다운로드 장애가 아니라, 특정 의존성 버전의 설치를 중단하는 보안 판단과 관계가 있기 때문이다. Vercel은 2026년 11월 2일 발표에서 npm 차단 검사를 의존성 설치 전과 설치 중으로 확장했다고 설명했다. 이미 설치된 의존성과 함수 출력물에 대한 배포 전 검사도 유지된다. 이 글의 질문은 “모든 npm이 안전해졌나”가 아니다. 차단된 빌드를 만났을 때 무엇을 수정해야 하고, 이 보호 장치를 어디까지 믿을 수 있는지가 핵심이다. 설치가 끝난 뒤만 보는 검사가 아니다 공식 발표의 구분은 세 시점으로 읽을 수 있다. 설치 전에는 지원되는 lockfile을 확인하고, 빌드 캐시에서 의존성을 복원하는 경우도 포함한다. 설치 중에는 영향을 받는 공개 npm 다운로드를 차단한다. 이후에는 기존의 설치된 의존성·함수 출력물 검사도 이어진다. 아래 그림은 그 관계를 정리한 자체 도식이지 실제 빌드 화면이나 실행 로그가 아니다. 검사 시점을 구분하면 실패가 어느 단계의 보호와 관련되는지 읽을 수 있다. 지원 lockfile·공개 npm이라는 범위를 유지한 자체 도식이며 실제 실행 로그는 아니다. 출처: vercel.com/changelog/blocking-malicious-npm-packages-before-and-during-installation . 개발자에게 중요한 변화는 실패를 만나는 위치가 앞당겨질 수 있다는 점이다. 설치 스크립트가 실행된 다음 배포 직전에 문제를 알게 되는 것과, 설치 전에 문제가 있는 버전을 발견하는 것은 대응 순서가 다르다. 다만 발표의 “악성 설치 스크립트 실행 방지에 도움”이라는 설명을 모든 설치 스크립트의 완벽한 차단 보장으로 바꿔 읽어서는 안 ...