Cue 배우기 · 작업 기반 튜토리얼

Cue 음성과 Codex로 코드 변경 사항 검토하기

검토자에게 변경 사항의 목적과 유지되어야 할 불변 조건을 전달하세요. 그런 다음 안심시키는 코드 요약이 아닌, 구체적인 근거를 요청하세요.

작성: Cue 제품 팀 (English) · 업데이트: . 제품 소스 검토를 바탕으로 작성되었습니다. 실습과 출력 결과는 설명을 돕기 위한 예시이며 실제 Cue 실행 기록이 아닙니다. 설치된 버전의 컨트롤을 따르세요.

빠른 요약

Cue를 사용해 검토 목표를 포착하고, Codex에서 저장소와 diff 범위를 확인한 뒤 읽기 전용 검토를 요청하세요. 변경된 줄 및 의도된 동작과 비교해 각 발견 사항을 확인하세요. 수정 승인은 검토 요청과 별개의 단계입니다.

준비물: Dictation이 구성된 Cue, Codex 액세스 권한, Git 프로젝트, 의도된 동작이 명확히 정의된 변경 사항. 결과: 우선순위가 지정되고 근거와 연결된 검토 내용 및 다음 수정 작업에 대한 결정(자동 병합이나 보안 인증이 아님).

Cue가 처음인가요? Dictation 설정 으로 말한 내용을 입력하거나, 작업 결과를 요청하려면 Agent 모드 설정을 확인하세요. 시작 전에 설치된 버전의 권한과 단축키를 확인하세요.

입력 방법 선택하기

다른 앱에서 검토할 문제를 발견했을 때 Cue를 활용하세요.명세를 읽거나, 이슈를 확인하거나, 변경된 화면을 사용해 보면서 위험을 알아차릴 수 있습니다. 의도한 동작과 유지되어야 할 조건을 임시 메모에 말로 입력한 뒤 문장을 확인하고 Codex에 전달하세요. Cue는 여러 앱에 흩어진 검토 요청을 정리할 때 유용하지만, 정확한 diff는 여전히 검토 환경에서 선택해야 합니다.

관련 프로젝트, diff, 검토 질문이 이미 Codex에 준비되어 있다면 바로 계속하세요.짧은 요청을 직접 입력하거나 붙여넣고 아래에 설명된 검토 컨트롤을 사용하세요. Cue 없이도 이 실습을 완료할 수 있습니다. 말로 설명하거나 작업 바깥에서 맥락을 모으는 것이 검토 질문을 더 명확하게 만드는 데 도움이 된다면 Cue를 추가할 이유가 있습니다. 검토 품질은 제공한 근거와 검토자의 확인에 달려 있습니다.

Cue Dictation으로 외부 앱에 입력하기

아래 실습에서는 이 방식을 사용합니다. Cue가 포커스된 임시 메모나 지원되는 텍스트 입력란에 말한 내용을 넣습니다. 문장을 확인한 뒤 Codex에 요청서를 명시적으로 보내 읽기 전용 검토를 요청하세요. Cue 커넥터는 필요하지 않습니다. 전달되는 것은 사용자가 제공한 자료뿐이며, 다른 대화, 파일, 권한은 자동으로 따라가지 않습니다.

Cue 안에서 Codex 커넥터 사용하기

이는 Cue에서 외부 Agent를 사용하는 별도의 방식입니다. 먼저 해당 경로의 연결, 로그인 상태, 프로젝트와 권한을 확인하고, 계정과 과금 방식도 확인하세요. Codex 선택 항목이 보인다는 사실만으로 사용 준비가 끝났다고 볼 수는 없습니다. 아래에 설명된 Codex 앱의 검토 패널과 메뉴는 Cue 안의 커넥터를 위한 사용 지침이 아닙니다.

Cue Agent에서 호스팅 모델 사용하기

Cue Agent에게 제공한 원본 자료를 검토 요청서 초안으로 정리하게 한 뒤, 초안을 원본 자료와 대조하세요. Cue Agent에서 OpenAI 모델을 선택해도 Codex가 시작되거나 별도의 Codex 작업에 저장소 접근 권한이 부여되지는 않습니다. 호스팅 모델의 이용 자격과 과금은 Cue 계정을 따르며, 외부 Agent의 접근 권한은 별도로 확인해야 합니다.

작은 패치 검토 실습을 해보세요. Dictation으로 입력한 뒤 텍스트를 명시적으로 전달합니다. 검토 목표를 말한 다음 R-01부터 R-03까지의 자료를 적힌 그대로 첨부하세요. 편집하지 않고 발견 사항만 제시하도록 요청하세요. 각 발견 사항을 정확한 표현식과 문제를 일으키는 입력에 연결하고, 설명용 예시와 실제로 실행한 검증을 구별할 수 있으면 완료입니다.

위험을 발견한 위치에서 검토 질문 포착하기

검토는 단 하나의 질문에 집중할 때 조치를 취하기가 더 쉽습니다. "모두 검토해 줘"라는 요청은 중요하게 생각하는 동작을 놓친 채 스타일 제안만 내놓을 수 있습니다. 더 유용한 음성 요청은 다음과 같습니다. "이 패치는 숫자 0 카운트를 표시하게 해. 누락된 카운트에 여전히 기존의 빈 상태 레이블이 사용되는지 확인해 줘. 아직 아무것도 수정하지는 마."

  1. 사양이나 영향을 받는 화면을 띄워 둔 상태에서 임시 메모장이나 대상 작업 입력란에 포커스를 맞추세요. Cue Settings에 표시된 Dictation 단축키를 누르고, 녹음 상태를 확인한 뒤, 검토 목표를 말하고, 중지한 다음 처리되어 입력된 텍스트를 검토하세요.
  2. 정확한 식별자는 소스에서 복사하여 보존하세요. 전송하기 전에 숫자, 부정 표현, 브랜치 이름의 전사 결과를 검토하세요. Cue Agent가 메모를 정리하도록 하려면 초안 브리프를 요청하고 필요한 발췌본을 명시적으로 제공하세요.
  3. Codex에서 올바른 Git 프로젝트를 여세요. 검토 창에는 Codex의 마지막 응답뿐만 아니라 본인의 수정 사항과 다른 도구의 편집 내용을 포함한 저장소 변경 사항이 표시됩니다. 검토를 요청하기 전에 이 작업에 해당하는 범위가 무엇인지 확인하세요.
  4. 확인된 브리프를 명시적으로 전달하세요. 포커스가 맞춰진 텍스트 작성기에 메모를 붙여넣거나 추가 음성을 받아쓰기할 수 있습니다. Cue의 모델 선택기는 별도의 Codex 작업을 위한 런타임을 선택하거나 액세스 권한을 부여하지 않습니다.

이 수동 경로에서는 Cue와 Codex를 연결하는 커넥터가 필요하지 않습니다. 대신 Cue 내부에서 외부 Agent를 선택하는 경우, 해당 경로의 연결, 로그인, 프로젝트 및 권한을 먼저 확인하세요. Codex 데스크톱 앱의 메뉴가 있거나 이전 대화 기록이 자동으로 수신된다고 가정해서는 안 됩니다. 차이점은 코딩 Agent와 함께 Cue 사용하기를 참조하세요.

발견 사항을 요청하기 전에 정확한 diff 선택하기

Codex 앱의 경우, OpenAI의 코드 검토 문서에서 커밋되지 않은 변경 사항이나 베이스 브랜치 대비 검토 옵션이 포함된 컴포저 내의 /review을(를) 설명합니다. 또한 검토 창에서는 스테이징됨, 스테이징되지 않음, 커밋, 브랜치, 마지막 턴 뷰를 구분합니다. 이는 Cue 명령이 아닌 Codex 앱의 컨트롤이며, 사용 가능 여부는 설치된 버전에 따라 다릅니다.

  • 커밋되지 않은 작업: 스테이징된 파일과 스테이징되지 않은 파일을 점검하세요. 어떤 파일이 범위에 포함되는지, 어떤 기존 변경 사항이 다른 사람의 작업인지 검토자에게 알려주세요. "마지막 턴"이 배포하려는 모든 내용을 다룬다고 가정하지 마세요.
  • 브랜치 변경 사항: 익숙해 보이는 이름이 아니라 실제로 의도한 베이스 브랜치를 선택하세요. 나중에 검토를 재현해야 한다면 베이스 및 헤드 커밋 ID를 기록해 두세요.
  • 단일 커밋 또는 제공된 패치: 커밋 이름을 지정하거나 이를 해석하기에 충분한 주변 구현 코드와 함께 패치를 첨부하세요. 스니펫만 붙여넣는 경우 검토에 스니펫 전용임을 명시하세요.

맞춤형 작업을 진행하려면 아래의 브리프를 붙여넣고 해당 정확한 범위에 대한 읽기 전용 검토를 요청하세요. 기본 제공 검토와 자유 형식 프롬프트는 서로 다른 진입점입니다. 다른 곳에 입력한 제약 조건이 검토에 자동으로 연결되었다고 가정하지 마세요. 검토 작업의 컨텍스트를 확인하세요. 단순히 검토를 실행하기 위해 권한을 비활성화하지 마세요.

실습: 그럴듯한 작은 패치에서 회귀 버그 찾기

이 가상 실습에서는 아주 작은 diff와 동작 계약을 제공합니다. 이는 텍스트 전용 실습으로 검토할 수 있으며, 기록된 Codex 실행 결과가 아니므로 프로덕션 저장소에 액세스할 필요가 없습니다.

소스 R-01 — 계약: 숫자 0 카운트는 반드시 0 results을(를) 표시해야 합니다. nullundefined은(는) 누락을 의미하며 반드시 No count을(를) 표시해야 합니다. 양수 카운트는 계속 표시되어야 합니다. 기타 입력 유효성 검사 및 단수형 문법 처리는 이 작업의 범위가 아닙니다.

소스 R-02 — result-label.mjs의 제안된 diff:

 export function resultLabel(count) {
-  return count ? `${count} results` : 'No count';
+  return count !== null ? `${count} results` : 'No count';
 }

소스 R-03 — 패치 작성자의 주장: "이 패치는 0 카운트를 수정하고 누락된 값은 그대로 유지합니다." 이 문장은 테스트가 실행되었다는 근거가 아니라 확인해야 할 주장으로 취급하세요.

다음과 같이 요청하세요: "R-01을 기준으로 R-02를 검토해 줘. 구체적인 회귀 버그마다 트리거, 변경된 표현식, 실제 동작 대 기대 동작, 그리고 이를 입증할 수 있는 최소한의 확인 방법을 제시해 줘. 확인되지 않은 질문은 별도로 분리해 줘. 수정 사항을 직접 구현하지는 마."

예시 발견 사항: "추가된 조건문은 null을 제외하지만 undefined는 허용합니다. 변경된 함수를 undefined로 호출하면 undefined results이(가) 반환되지만, R-01에서는 No count이(가) 필요합니다. 관련된 변경 코드는 count !== null 식입니다. 0, null, 양수 카운트와 함께 undefined에 대한 확인을 추가하세요." 이 결론은 제공된 JavaScript에서 도출된 것이며, Codex가 이를 발견했거나 테스트했다는 주장이 아닙니다.

이 발견 사항에서 임의로 지어내지 않은 부분을 살펴보세요: 고객 영향 수치, 프로덕션 장애, 확인되지 않은 저장소의 라인 번호, 관련 없는 보안 위험 등이 배제되어 있습니다. 실제 diff에서는 검증된 파일과 라인 범위를 포함하세요. 이 스니펫에서는 소스 위치를 꾸며내는 것보다 정확한 표현식의 이름을 지정하는 것이 더 솔직한 접근 방식입니다.

초점이 명확한 검토 브리프 복사하기

Codex로 전송하기 전에 정확한 범위를 포함하여 대괄호로 묶인 필드를 변경하세요.

작업: 이 변경 사항을 검토해 주세요. 파일을 수정하거나 검토 내용을 게시하지 마세요.
프로젝트: [확인된 저장소]
diff 범위: [커밋되지 않은 파일, 또는 베이스/헤드 커밋 ID]
의도된 동작: [변경 사항이 달성해야 하는 내용]
불변 조건: [변경되지 않고 유지되어야 하는 동작]
소스: [사양 ID, 재현 방법, 관련 파일 또는 패치]
우선순위: 스타일 정리가 아닌, 이 범위 내의 정확성 및 회귀 버그.
각 발견 사항마다 다음을 반환할 것:
- 검증된 파일/라인 또는 제공된 정확한 표현식
- 트리거가 되는 입력값 또는 사용자 작업
- 실제 결과 대 기대 결과
- 변경 사항 및 해당 호출 경로에서 얻은 근거
- 최소한의 재현 방법 또는 회귀 확인 절차
- 지어낸 빈도나 심각도 없는 실제 영향 및 불확실성
질문과 검증되지 않은 가설은 별도 섹션에 작성하세요.
확인 절차가 실행되지 않았다면 그렇다고 밝히세요. 제안된 테스트는 테스트 근거가 아닙니다.
확인된 발견 사항이 더 이상 없다면 범위와 잔여 위험을 명시하세요.
수정, 커밋, 푸시, 병합, 배포를 수행하지 마세요. 다음 지시를 기다리세요.

발견 사항을 무조건적 승인이 아닌 구체적 결정으로 전환하기

각 발견 사항을 원본 소스와 나란히 놓고 읽으세요. R-02의 경우 변경된 함수가 여전히 0과 null을 올바르게 처리하는지 확인한 다음 undefined를 테스트하세요. 건드리지 않은 헬퍼 함수에 대한 발견 사항이 있다면 패치가 거기에 어떻게 도달하는지 설명해야 합니다. 그렇지 않다면 관련 없는 백로그 작업일 수 있습니다. 긴 보고서가 반드시 유용한 검토인 것은 아닙니다.

결과를 명확한 언어로 분류하세요:

  • 확인된 회귀 버그: 계약 및 재현 가능한 케이스로 뒷받침됩니다. 범위가 제한된 수정을 승인할지 결정한 다음, 관련 확인 절차를 다시 실행하세요.
  • 질문: 실제 앱에서 undefined가 해당 함수에 도달할 수 있는지 등 가정을 뒷받침할 출처가 필요합니다. 검토자의 확신이 아니라 호출 경로나 사양을 통해 이를 해결하세요.
  • 범위 외: 유용한 정리 작업은 별도로 기록할 수 있습니다. 현재 패치의 범위가 조용히 확장되어서는 안 됩니다.
  • 확인된 발견 사항 없음: 검토된 범위에서 입증된 발견 사항이 없었습니다. 이것이 정확성에 대한 증명이나 완료된 테스트 스위트, 또는 보안 보장을 의미하는 것은 아닙니다.

수정을 승인하는 경우, 수용된 발견 사항과 불변 조건을 다시 명시하세요. 새로운 diff와 실제 테스트 출력을 점검한 다음 변경된 동작을 검토하세요. 원래의 검토가 나중에 이루어진 편집까지 포괄한다고 생각하지 마세요. 로컬 테스트 통과가 프로덕션 아티팩트에 해당 변경 사항이 포함되었음을 입증하지는 않습니다.

독립적인 검토를 진행하려면 패치 작성자의 설명보다 의도된 동작과 정확한 코드를 먼저 제공하세요. 그래야 검토자에게 동조할 답을 주는 대신 테스트할 구체적인 계약을 제시할 수 있습니다. 완전한 회귀 테스트 실습이 필요하다면 Claude Code 소규모 수정 튜토리얼을 참조하세요.

검토 내용이 모호할 때 대처하는 방법

Codex가 잘못된 파일이나 베이스 브랜치를 검토함

작업을 중단하고 실제로 검토된 내용을 기록한 뒤 올바른 프로젝트와 범위를 선택하세요. 의도한 diff에서 검토를 다시 실행하세요. 다시 확인하지 않고 다른 리비전에 발견 사항을 그대로 복사하지 마세요.

검토자가 테스트를 실행했다고 말하지만 결과 출력을 제공하지 않음

실제 실행 명령, 결과 및 관련 출력을 요청하세요. 이를 제공하지 못하면 해당 확인을 미검증 상태로 표시하세요. 일반적인 승인 환경을 통해 제한된 테스트를 직접 실행하세요. 제안된 명령어를 실행 근거로 받아들이지 마세요.

검토 요청으로 인해 파일 수정이 발생함

추가 조치를 취하기 전에 잠시 멈추고 작업 트리를 살펴보세요. 관련 없는 작업 내용을 보존하고 무엇이 변경되었는지 검토하세요. 취소(Cancel)는 실행 취소(Undo)가 아닙니다. 작업을 재개하기 전에 읽기 전용 범위와 권한을 명확히 하세요.

대화를 기반으로 진행되는 검토의 경우, 출처가 연결된 녹음 컨텍스트를 사용하여 결정 사항과 주의점을 보존하세요. 비공개 회의 전체나 저장소 자격 증명 파일이 아닌, 승인된 발췌본만 전달하세요.

Cue로 시작해 보기

설정된 단축키를 사용하고 Cue Settings에서 활성 모드를 확인하세요. 사용 가능한 앱 컨텍스트와 작업은 권한, 버전 및 계정에 따라 다릅니다. 기밀 자료를 제공하기 전에 개인정보 처리방침 (English)을 확인하세요. 이 가이드는 모든 처리가 기기 내에서만 이루어진다고 보장하지 않습니다.

컴퓨터용 Cue 다운로드 · 현재 요금제 (English)

도움이 필요하거나 오류를 발견하셨나요? Cue 지원팀에 문의 (English)하거나 eli@sophoninc.com으로 이메일을 보내주세요. Cue 버전, 플랫폼, 모드 및 민감한 정보가 제거된 예시를 포함해 주세요. 비밀번호, 토큰 또는 비공개 회의 자료를 보내지 마세요.