AI 코드 리뷰는 GitHub에 PR을 올린 뒤에만 받는다고 생각하기 쉽습니다. Visual Studio의 GitHub Copilot은 커밋 전 로컬 변경도 검토합니다. 편집기에서 수정 내용을 점검하고 커밋한 다음, GitHub PR에서는 Gemini Code Assist로 요약과 리뷰를 받는 순서로 연결하면 됩니다.
다만 Gemini의 GitHub 소비자용 리뷰는 종료됐습니다. 지금 새로 연결할 때는 Google Cloud를 통한 GitHub용 기업 버전의 설정 경로를 이용합니다.
Copilot과 Gemini가 리뷰하는 작업 위치
GitHub Copilot을 Visual Studio에서 쓰면 아직 커밋하지 않은 수정 내용을 작업 중인 편집기에서 검토할 수 있습니다. 코드를 고친 작성자가 커밋 직전에 놓친 부분을 살피기 좋은 자리입니다. 의견을 읽다가 해당 코드로 이동하고, 수정한 결과를 다시 Git Changes에서 확인하는 작업이 이어집니다.
Gemini Code Assist on GitHub는 PR 과정에 참여하는 코드 리뷰어입니다. PR을 자동으로 요약하고 코드 리뷰를 제공하며, 댓글에서 변경 내용에 관한 질문을 받습니다. 저장소와 PR에서 작업에 필요한 정보를 가져와 답변에 활용합니다.
| 항목 | Visual Studio의 Copilot 로컬 리뷰 | GitHub의 Gemini PR 리뷰 |
|---|---|---|
| 실행 위치 | Visual Studio의 Git Changes 또는 Copilot Chat의 Git 에이전트 | 연결된 저장소의 GitHub PR |
| 검토 대상 | 아직 커밋하지 않은 로컬 변경 | PR에 포함된 코드 변경 |
| 결과를 읽는 위치 | Git Changes의 댓글 목록과 편집기의 해당 코드 | PR 요약과 리뷰 댓글 |
| 후속 질문 | Copilot Chat에서 변경 내용이나 리뷰 의견을 질문 | PR 댓글에 /gemini를 붙여 질문 |
커밋을 만들기 직전이라면 왼쪽 경로부터 쓰는 게 자연스럽습니다. 팀원에게 검토를 요청한 PR에서 설명을 주고받으려면 오른쪽 경로가 맞습니다. 이 표의 Copilot 항목은 Visual Studio의 로컬 리뷰를 다루므로, 다른 환경에서 제공하는 Copilot 기능은 해당 환경의 사용 절차로 접근하면 됩니다.
리뷰를 요청할 변경 사항 준비하기
수정 파일과 스테이징 파일을 살펴봅니다
Git은 마지막 커밋 이후 그대로인 파일, 수정했지만 아직 스테이징하지 않은 파일, 다음 커밋에 넣도록 스테이징한 파일을 나누어 관리합니다. Visual Studio에서는 Git Changes의 Changes 영역에서 수정 파일을 살펴볼 수 있습니다. 스테이징까지 마쳐도 커밋하기 전에는 여전히 미커밋 변경입니다.
파일 옆의 더하기 버튼을 누르거나 오른쪽 클릭 메뉴에서 Stage를 선택하면 Staged Changes로 들어갑니다. 이 영역에 모인 변경이 Commit Staged로 만드는 다음 커밋에 포함됩니다. 리뷰할 수정 내용을 살피는 일과 실제로 커밋에 넣을 변경을 고르는 일을 이 창에서 차례로 진행하면 됩니다.
여러 파일을 손봤다면 Open changes summary를 열어 달라진 줄을 한 화면에서 훑습니다. 함수 구현과 관련 테스트를 같이 수정했을 때 각각 어떤 부분이 바뀌었는지 이어서 읽기 좋습니다. 자세한 비교가 필요한 파일은 Changes나 Staged Changes에서 더블클릭해 수정 전후를 줄 단위로 살펴봅니다.
이 단계에서는 이번 작업과 무관한 수정도 함께 찾아냅니다. 예를 들어 함수 동작을 바꾼 작업에 다른 기능의 실험 코드가 섞여 있다면, 어떤 파일을 이번 커밋으로 묶을지 정해 두는 것이 좋습니다. 이미 스테이징한 파일을 빼려면 빼기 버튼으로 스테이징을 해제하고, 필요한 변경만 남긴 뒤 커밋을 진행합니다.
파일 이름도 바꿨다면 순서를 조금 조정합니다. 이름을 바꾼 직후 다른 내용 수정까지 더하기 전에 이름 변경을 스테이징하고 커밋하면, Git이 이를 파일 삭제와 새 파일 추가 대신 이름 변경으로 인식하도록 돕습니다. 이름과 내부 구현을 한꺼번에 크게 바꾸기보다 이동한 파일을 먼저 기록해 두면 이후의 구현 변경도 살피기 편합니다.
Visual Studio에서 Copilot 리뷰를 실행하고 수정하기
리뷰 기능을 켜고 댓글 위치로 이동합니다
GitHub Copilot을 설치한 Visual Studio에서 Tools → Options를 엽니다. 설정 화면에 All Settings가 보이면 All Settings → Preview Features에서 Pull Request Comments를 켭니다. Environment 아래에 설정이 있는 화면에서는 Environment → Preview Features에서 같은 항목을 선택합니다.
Environment 경로를 사용하는 설정에서는 GitHub → Copilot → Source Control Integration으로 이동해 Enable Git preview features도 활성화하고 OK를 누릅니다. 메뉴를 찾다가 막히면 현재 보이는 Options의 분류부터 살피는 것이 빠릅니다. All Settings와 Environment 중 화면에 있는 경로를 따라가면 됩니다.
처음 로컬 리뷰를 써 볼 때는 PR을 올려야 버튼이 생기는 줄 알고 GitHub 쪽 메뉴부터 찾았습니다. 윈도우 데스크톱의 Visual Studio에서 함수 구현과 테스트를 수정해 둔 상태였는데, 편집기를 벗어나기 전에 검토를 끝내고 싶어 Git Changes로 돌아왔습니다. 설정에서 Pull Request Comments를 켠 뒤에는 변경 요약을 열고 리뷰 버튼을 누르는 순서로 바꿨습니다. 그 뒤로는 커밋 메시지를 쓰기 전에 이 창에서 수정 범위부터 살피고 있습니다.
Git Changes 창에서 Review changes with Copilot 버튼을 실행합니다. 댓글 말풍선에 반짝임이 붙은 모양이어서, 파일을 스테이징하는 더하기 버튼과 눈으로 구별할 수 있습니다. 마우스를 올려 버튼 이름까지 읽고 실행하면 다른 기능을 누르는 일을 줄일 수 있습니다.
검토가 끝나면 Git Changes에 리뷰 댓글 수를 보여 주는 링크가 나타납니다. 링크를 누르면 파일별로 묶인 의견을 살펴볼 수 있고, 항목을 더블클릭하면 편집기의 해당 코드 위치로 이동합니다. 파일 이름만 보고 어느 줄인지 다시 찾기보다 파일별 댓글 목록에서 바로 이동하는 쪽이 편합니다.
댓글에는 잠재적인 문제를 짧게 설명한 내용이 표시됩니다. 우선 표시된 줄과 그 위아래 코드를 함께 읽고, 지적한 상황이 실제로 생기는지 살핍니다. 함수 안에서 빠진 처리처럼 보여도 호출하는 쪽에서 이미 조건을 제한하고 있을 수 있으므로, 필요한 부분은 호출부와 관련 테스트까지 이어서 읽습니다.
예를 들어 문자열을 정리하는 함수와 그 테스트를 함께 수정했다고 가정해 보겠습니다. 이번 변경의 목적이 앞뒤 공백을 제거하는 것이라면, 변경 요약에서 구현과 테스트가 그 동작을 함께 다루는지 살핍니다. 그런 다음 리뷰를 요청하고, 의견이 달린 코드로 이동해 설명과 현재 구현을 대조합니다. 여기서 검토할 대상은 댓글 문장의 설득력뿐 아니라, 그 설명이 가리키는 입력과 반환값입니다.
댓글이 빈 문자열 처리에 관해 설명한다면 빈 입력을 받았을 때 요구되는 결과부터 찾아봅니다. 함수가 빈 문자열을 그대로 반환해야 하는지, 호출부에서 입력을 제한하는지에 따라 적절한 수정이 달라집니다. 관련 테스트가 어떤 동작을 기대하는지도 함께 읽어야 제안의 적용 범위를 정할 수 있습니다. 이 예시는 댓글을 읽는 순서를 보여 주는 것으로, 실제 작업에서는 받은 의견에 맞춰 코드와 테스트를 따라갑니다.
수정 제안을 비교하고 테스트한 뒤 반영합니다
리뷰 댓글에서 실행 가능한 코드 수정 제안을 요청하면 인라인 diff로 원래 코드와 제안된 편집, 주변 문맥을 비교할 수 있습니다. 설명만 읽을 때보다 어느 조건문을 바꾸고 어떤 반환값을 남기는지 구체적으로 드러납니다. 제안된 줄만 확대해서 보기보다 기존 흐름 안에 넣었을 때 어떻게 이어지는지 읽는 것이 좋습니다.
이때 편집기에 제안을 넣는 조작과 프로젝트에 맞는 수정인지 판단하는 작업은 차례로 진행합니다. 적용 버튼을 누르기 전에는 요구사항과 기존 동작을 대조하고, 반영한 뒤에는 실행 결과를 테스트합니다. 코드가 짧아졌다는 이유만으로 수정을 선택하기보다 이번 변경의 목적에 맞는지를 기준으로 삼습니다.
앞의 문자열 함수 예시로 돌아가면, 공백을 제거하도록 바꾼 코드에 빈 입력을 처리하는 제안이 추가될 수 있습니다. 그러면 정상 문자열을 넣었을 때의 결과와 빈 문자열을 넣었을 때의 결과를 각각 살핍니다. 공백만 있는 입력도 이번 기능에서 다뤄야 한다면 그 입력에 대한 기대값을 테스트에 담습니다. 이 과정에서 필요한 것은 프로젝트가 요구하는 동작을 유지하면서 지적된 문제를 해결하는 수정입니다.
테스트 파일이 함께 바뀌었다는 사실만으로 구현과 테스트의 관계를 판단하기는 어렵습니다. 함수의 새 동작을 테스트가 실제로 실행하는지, 기대값이 요구사항을 표현하는지까지 읽어야 합니다. 예를 들어 구현을 바꾼 뒤 실패한 테스트의 기대값만 그대로 따라 바꾸면, 원래 유지해야 할 동작을 놓칠 수 있습니다. 반대로 요구사항 자체가 바뀐 작업에서는 이전 기대값을 새 동작에 맞게 고치는 것이 필요합니다.
수정 제안에 도움이 되는 부분과 불필요한 부분이 함께 들어 있다면 필요한 편집만 남깁니다. 빈 입력 처리 때문에 요청한 수정이 함수 이름이나 다른 분기까지 바꾼다면, 각 변경이 이번 작업에 필요한지 살펴보면 됩니다. 제안된 편집을 그대로 유지할 의무는 없습니다. 주변 코드와 맞게 조정한 결과를 대상으로 테스트를 실행합니다.
실제 작업 순서는 다음처럼 잡으면 됩니다.
- 댓글이 지적한 입력과 코드 위치를 살피고, 관련 함수와 테스트에서 기대하는 동작을 대조합니다.
- 수정 제안을 요청한 뒤 인라인 diff에서 원래 코드와 바뀔 코드, 주변 분기를 함께 읽습니다.
- 필요한 편집을 반영하고 관련 테스트를 실행한 다음, 프로젝트에서 요구하는 나머지 검증을 진행합니다.
- Git Changes로 돌아가 최종 변경을 검토하고, 이번 커밋에 넣을 내용만 스테이징합니다.
테스트가 실패하면 실패한 입력과 기대값부터 읽습니다. 제안의 어느 부분이 기존 동작을 바꿨는지 diff와 테스트 결과를 나란히 놓고 추적하면 됩니다. 요구사항을 유지해야 하는 실패인지, 의도한 동작 변경에 맞춰 테스트도 수정해야 하는 실패인지 판단한 뒤 다시 실행합니다. AI가 작성한 코드라는 이유로 이 순서를 줄일 필요는 없습니다.
반영이 끝난 뒤에는 처음 리뷰를 요청했던 시점과 현재 파일의 내용이 달라져 있습니다. 그래서 수정 후 변경 내용 재확인이 필요합니다. Git Changes에서 함수 구현과 테스트 파일을 다시 열어, 채택한 수정과 직접 손본 내용이 의도대로 남았는지 살핍니다. 채팅에서 설명만 받았던 내용과 실제 파일에 들어간 코드도 이때 대조할 수 있습니다.
의견이 없는 실행에서는 Copilot did not comment on any files가 표시됩니다. 이번 실행에서 보여 줄 리뷰 의견이 없다는 뜻이므로, 이어서 준비해 둔 테스트와 변경 내용 검토를 진행합니다. 댓글 개수 대신 수정한 함수의 동작과 테스트 결과를 놓고 커밋 여부를 결정하면 됩니다.
읽은 댓글을 접어 두려면 댓글 상자 오른쪽 위의 위쪽 화살표를 누릅니다. 이 조작은 해당 댓글 상자를 접는 데 사용합니다. Git Changes에서 리뷰 링크 옆의 X를 누르면 리뷰 댓글 전체가 제거되므로, 아직 읽을 의견이 남아 있다면 개별 상자를 접는 쪽이 적절합니다.
끝으로 필요한 변경을 스테이징하고 Commit Staged를 선택합니다. 커밋 메시지는 Staged Changes에 남긴 변경을 설명하도록 작성합니다. 함께 검토했더라도 이번 커밋에서 제외한 파일이 있다면 메시지의 설명 범위도 그에 맞게 좁힙니다. 이렇게 해야 검토한 작업 가운데 무엇을 실제 기록으로 남겼는지 이후 Git 기록에서도 따라가기 쉽습니다.
Copilot Chat에서 변경 내용에 질문 이어가기
리뷰 댓글을 읽고 수정 이유를 더 묻고 싶으면 Copilot Chat으로 이어갑니다. #changes를 참조하면 아직 커밋하지 않은 변경을 대화에 넣어 요약이나 설명을 요청할 수 있습니다. “#changes에서 수정한 함수의 입력과 반환값이 어떻게 달라졌는지 설명해 주세요”처럼 현재 동작을 묻는 질문부터 시작하면 됩니다.
댓글이 짧아 의도가 잘 드러나지 않을 때는 해당 코드 위치를 짚어 질문합니다. “이 리뷰에서 제안한 조건문이 필요한 이유를 현재 함수와 관련 테스트에 연결해서 설명해 주세요”처럼 묻는 방식입니다. 답변을 읽고 코드로 돌아가 실제 처리 순서를 대조하면, 수정안을 적용하기 전에 이유를 검토할 수 있습니다.
이전 작업과 연결된 질문에는 #commit:으로 특정 커밋을 참조합니다. Git 기록에서 하나 이상의 커밋을 선택해 Add to Chat으로 대화에 첨부하는 방법도 있습니다. 현재 변경의 설명에 이전 커밋에서 바꾼 동작이 필요하다면 그 기록을 함께 넣어 질문의 대상을 구체화하면 됩니다.
채팅에서 로컬 변경 리뷰 자체를 시작하는 경로도 있습니다. 에이전트 선택기에서 Git을 고르거나 입력창에 @git을 입력하고 변경 사항 리뷰를 요청합니다. 결과는 Git Changes의 댓글 수 링크와 편집기의 인라인 의견에 나타나며, 채팅에서는 지적한 내용의 설명을 계속 주고받습니다.
GitHub PR에서 Gemini 리뷰와 후속 질문 사용하기
PR 요약을 읽고 코드 의견으로 내려갑니다
Gemini는 GitHub용 기업 버전의 앱 설치와 조직 연결을 끝내고, 대상 저장소의 설정까지 마친 상태에서 사용합니다. 연결된 저장소의 PR 과정에 코드 리뷰어로 참여해 자동 요약과 코드 리뷰를 제공합니다. PR을 진행하면서 필요한 단계에 호출해 검토를 요청할 수 있습니다.
PR 요약에서는 어떤 파일과 동작이 바뀌었는지 전체 범위를 읽습니다. 이어서 개별 리뷰 의견으로 내려가 해당 코드와 제안을 대조합니다. 요약이 변경 목적을 잘 짚었더라도 구체적인 편집을 적용할 때는 함수의 동작과 테스트를 다시 살펴야 합니다.
후속 질문은 PR 댓글에 /gemini 태그를 붙여 작성합니다. “/gemini 이 리뷰에서 지적한 반환값 변경이 호출부에 어떤 영향을 주는지 설명해 주세요”처럼 이미 나온 의견을 대상으로 질문하면 됩니다. 여러 지적이 달려 있다면 파일명과 질문하려는 변경을 함께 적어 대상을 좁힙니다.
Gemini는 답변에 필요한 정보를 저장소와 PR에서 가져옵니다. 그래도 질문하는 쪽에서 변경의 목적과 궁금한 지점을 구체적으로 적어 주면, 반환값을 묻는 것인지 수정 이유를 묻는 것인지 분명해집니다. 팀원이 이어서 읽을 댓글이므로 제안을 반영했다면 어떤 부분을 바꿨는지도 남기는 것이 좋습니다.
PR 안에서 설명을 주고받으면 리뷰 의견과 질문이 같은 작업에 모입니다. 작성자는 제안의 이유를 확인하고, 다른 검토자는 코드와 대화를 함께 읽으며 남은 쟁점을 파악합니다. 답변을 받은 뒤에는 제안된 변경과 실제 PR의 diff를 연결해 검토를 이어갑니다.
Gemini 소비자용 종료와 기업용의 적용 범위
GitHub 소비자용 앱으로 시작하는 예전 설치 글을 따라가면 현재 이용 경로와 어긋납니다. 소비자용은 2026년 6월 18일부터 신규 설치를 완료할 수 없게 됐으며, 2026년 7월 17일부터 앱이 수행하던 모든 코드 리뷰 활동이 종료됐습니다. 기존 소비자용 설치를 유지한 채 리뷰가 다시 실행되기를 기다리는 방식으로는 진행하기 어렵습니다.
GitHub용 기업 버전은 미리보기로 제공되며 GitHub, GitHub Enterprise Server, GitHub Enterprise Cloud를 지원합니다. 조직에서 사용하는 GitHub 환경을 놓고 도입할 대상과 연결 절차를 정하면 됩니다. 이름이 비슷한 Gemini Code Assist Enterprise를 이미 사용 중이어도 GitHub 리뷰 제품의 설정과 이용 조건은 따로 살펴야 합니다.
설치를 맡는 담당자에게는 제품명을 Gemini Code Assist on GitHub로 전달하는 것이 좋습니다. 소비자용 종료 여부와 GitHub용 기업 버전의 설치를 함께 검토할 때는 Google의 GitHub 코드 리뷰 안내에서 지원 환경과 설정 경로를 이어서 볼 수 있습니다.
리뷰에서 빠지는 파일과 저장소 연결 조건
.github/workflows 디렉터리 안의 파일은 Gemini의 요약과 코드 제안 생성에서 제외됩니다. GitHub Actions 작업 정의를 수정한 PR에서는 이 경로의 변경에 별도 검토를 배정해야 합니다. 같은 PR에 애플리케이션 코드와 워크플로 파일이 함께 들어 있어도, 워크플로 변경은 담당자가 직접 diff를 읽는 순서를 남겨 두는 것이 좋습니다.
예를 들어 테스트를 실행하는 애플리케이션 코드와 CI 작업 정의를 함께 수정했다면 두 파일의 관계까지 살핍니다. 테스트 코드가 올바르게 바뀌었는지와 CI가 의도한 명령을 실행하도록 바뀌었는지를 각각 검토합니다. PR 요약을 읽은 뒤 변경 파일 목록으로 돌아가 해당 경로의 수정이 남아 있는지 살피면 검토 대상을 놓치는 일을 줄일 수 있습니다.
저장소 연결에는 Developer Connect가 사용됩니다. GitHub용 기업 버전은 이 연결을 통해 GitHub 저장소와 Google Cloud를 이어 주며, 연결은 us-east1 리전에 생성됩니다. 조직에서 연결 리소스를 확인하는 담당자에게는 이 리전과 생성 경로를 함께 전달하면 됩니다.
새 연결은 Gemini Code Assist의 Agents & Tools 안에 있는 Code Assist Source Code Management에서 만들어야 합니다. 설정 과정에서 생성한 기존 연결에 GitHub 저장소를 추가할 때는 Developer Connect를 사용합니다. 최초 연결을 만드는 작업인지, 이미 만든 연결에 저장소를 더하는 작업인지에 따라 들어갈 위치를 정하면 됩니다.
자주 묻는 질문
Q1. PR을 만들기 전에도 AI 코드 리뷰를 받을 수 있나요?
Visual Studio의 GitHub Copilot으로 아직 커밋하지 않은 로컬 변경을 리뷰할 수 있습니다. 필요한 설정을 켠 뒤 Git Changes의 Review changes with Copilot 버튼에서 실행하고, 결과는 댓글 목록과 편집기에서 읽습니다.
Q2. 리뷰 댓글이 없으면 바로 커밋해도 되나요?
의견이 없다는 표시는 이번 실행에서 표시할 댓글이 없다는 뜻입니다. 프로젝트에 필요한 테스트를 실행하고 실제 변경 내용을 검토한 뒤, 커밋에 넣을 변경을 스테이징해 진행합니다.
Q3. Gemini GitHub 소비자용 앱을 지금 설치할 수 있나요?
소비자용은 신규 설치가 중단됐고 코드 리뷰 활동도 종료됐습니다. 현재 이용할 GitHub용 기업 버전은 Google Cloud를 통한 별도 설치와 저장소 연결이 필요합니다.
Q4. GitHub Actions 워크플로 파일에도 Gemini가 수정 제안을 주나요?
.github/workflows 안의 파일은 요약과 코드 제안 생성에서 제외됩니다. 해당 경로를 수정한 PR은 워크플로 변경을 직접 검토할 담당자와 절차를 함께 잡는 것이 좋습니다.
리뷰 의견을 반영했다면 워크플로 파일의 변경을 별도로 검토하고 프로젝트 테스트를 실행한 뒤, 커밋이나 PR 검토를 이어가면 됩니다.
'AI도구 활용' 카테고리의 다른 글
| Copilot Studio로 코딩 없이 AI 챗봇 만들기 (0) | 2026.09.21 |
|---|---|
| AI 글쓰기 도구로 업무 메모를 보고서로 바꾸는 방법 (0) | 2026.09.13 |
| Tome 슬라이드 정리, AI 발표 자료를 다시 쓰기 좋게 다듬는 방법 (0) | 2026.09.05 |
| Grok AI 사용법, 무료 시작부터 이미지·영상 생성까지 따라하기 (0) | 2026.09.02 |
| Runway 영상 편집 사용법, 배경 제거부터 이미지 영상 만들기까지 (0) | 2026.08.30 |