Copilot diff·terminal·browser workflow: AI 코드 리뷰를 한 화면에서 끝내는 법

AI 코딩 에이전트가 만든 코드를 검토할 때 가장 위험한 습관은 “그럴듯하니까 merge”다. 반대로 가장 피곤한 습관은 diff는 IDE에서 보고, 테스트는 터미널에서 돌리고, UI는 브라우저에서 확인하느라 계속 탭을 옮겨 다니는 것이다. GitHub는 Copilot app에서 diff, terminal, browser 패널을 나란히 두고 agent-generated code를 검토하는 흐름을 소개했다. 핵심은 도구 기능 자체보다 리뷰 루프를 짧고 반복 가능하게 만드는 데 있다.

검색 의도는 실용적이다. “Copilot diff terminal browser workflow”를 찾는 개발자는 새 UI 소개보다 실제로 어떤 순서로 확인해야 안전한지 알고 싶어 한다. 이 글은 GitHub가 제시한 세 질문, 즉 “무엇이 바뀌었나”, “실행되는가”, “정말 동작하는가”를 팀 워크플로우로 바꾸는 방법에 초점을 둔다.

AI 코드 리뷰가 기존 리뷰보다 더 까다로운 이유

사람이 만든 PR은 보통 의도와 배경이 있다. 이슈, 커밋 메시지, 동료와의 대화가 남는다. AI 에이전트가 만든 변경은 다르다. 코드가 많아 보이고 테스트도 추가돼 있을 수 있지만, 왜 그 방식으로 고쳤는지 설명이 부족할 때가 많다. 더 큰 문제는 에이전트가 주변 코드를 과감하게 건드린다는 점이다. 작은 UI 수정 요청이 라우팅, 타입 정의, 테스트 fixture까지 바꾸는 경우가 있다.

그래서 AI 코드 리뷰는 “코드 스타일 검토”가 아니라 “작업 결과 검증”에 가깝다. diff만 봐서는 충분하지 않다. 실행해야 하고, 화면을 확인해야 하고, 실패했을 때 다시 지시해야 한다. 이 루프가 길면 개발자는 귀찮아서 중간 검증을 생략한다. 한 화면에서 diff, terminal, browser를 다루는 흐름은 이 생략을 줄이는 데 의미가 있다.

1단계: diff에서 변경 범위를 먼저 잠근다

처음 볼 것은 결과 화면이 아니라 diff다. 이유는 간단하다. 에이전트가 요청 밖의 파일을 건드렸는지 먼저 알아야 한다. GitHub 글에서 diff panel은 추가·삭제·변경 라인을 보여주고, 사용자가 accept, comment, 재수정을 선택할 수 있는 통제 지점으로 설명된다.

실무에서는 diff를 볼 때 다음 순서가 좋다.

1. 요청과 직접 관련 없는 파일이 바뀌었는지 확인한다.
2. 설정 파일, lockfile, migration 파일이 바뀌었다면 이유를 확인한다.
3. 테스트 파일이 추가됐는지 보되, 테스트가 실제 버그를 잡는지 확인한다.
4. 삭제된 코드가 dead code인지, 아직 참조되는 코드인지 검색한다.
5. 에러를 숨기기 위해 try-catch나 optional chaining만 늘린 것은 아닌지 본다.

특히 설정 파일 변경은 조심해야 한다. AI 에이전트는 빌드를 통과시키려고 lint rule을 낮추거나 타입 체크를 우회하는 식의 수정을 제안할 수 있다. diff에서 이걸 못 잡으면 terminal 단계에서 “일단 통과”처럼 보인다.

2단계: terminal에서 프로젝트 명령을 그대로 실행한다

두 번째는 실행이다. GitHub는 Copilot app 안의 terminal panel에서 프로젝트 명령을 직접 실행할 수 있다고 설명한다. 여기서 중요한 원칙은 “새로운 검증 명령을 invent하지 말고, 팀이 이미 쓰는 명령을 실행한다”는 것이다.

예를 들어 Next.js 프로젝트라면 보통 다음 순서가 현실적이다.

• npm run lint 또는 pnpm lint
• npm run typecheck
• 변경 범위와 관련된 unit test
• UI 변경이면 dev server 실행
• API 변경이면 integration test 또는 smoke test

AI가 만든 코드에 대해 전체 테스트를 매번 돌리기는 어렵다. 그렇다고 아무 테스트도 돌리지 않으면 위험하다. 그래서 팀별로 “agent change minimum gate”를 정해두는 편이 좋다. 예를 들어 프론트엔드 UI 수정은 lint, typecheck, 해당 route 수동 확인을 필수로 하고, 결제·인증·권한 변경은 관련 테스트와 리뷰어 승인을 추가한다.

terminal 단계에서 실패가 나오면 바로 고치라고 시키기 전에 로그를 읽어야 한다. 에이전트에게 “이 에러 고쳐”라고만 던지면 원인을 우회할 가능성이 있다. 대신 “테스트 실패 원인을 설명하고, 변경 범위를 최소화해서 수정해”처럼 조건을 붙인다.

3단계: browser에서 사용자 흐름을 확인한다

UI가 있는 변경은 브라우저 확인이 마지막 관문이다. GitHub는 browser panel과 Pick & Polish 도구를 통해 화면에서 요소를 선택하고 다시 조정할 수 있다고 설명했다. 이 기능을 쓸 때는 예쁜지보다 흐름이 깨졌는지 먼저 봐야 한다.

확인할 항목은 다음과 같다.

• 처음 진입 화면이 깨지지 않는가.
• 버튼 클릭, 입력, 저장, 취소가 정상 동작하는가.
• 로딩·빈 상태·에러 상태가 보이는가.
• 모바일 폭에서 레이아웃이 무너지지 않는가.
• 기존 핵심 플로우가 새 변경 때문에 느려지지 않았는가.

AI가 만든 UI는 happy path만 그럴듯한 경우가 많다. 데이터가 없을 때, 권한이 없을 때, API가 실패할 때, 긴 텍스트가 들어올 때의 화면을 꼭 봐야 한다. 브라우저 패널이 한 화면에 붙어 있으면 이 확인을 덜 미루게 된다.

팀 워크플로우로 바꾸는 방법

도구가 있어도 팀 규칙이 없으면 검증 품질은 들쭉날쭉하다. AI 코드 리뷰용 체크 템플릿을 PR 본문이나 Copilot 작업 지시문에 넣어두는 것이 좋다.

예시 템플릿은 이렇다.

• 변경 목적: 한 문장으로 요약.
• 변경 범위: 수정된 파일과 이유.
• 실행한 명령: lint/typecheck/test/dev server 결과.
• 수동 확인: 확인한 route, 브라우저 폭, 주요 플로우.
• 남은 위험: 테스트하지 못한 영역, 리뷰어가 봐야 할 부분.

이 템플릿은 에이전트에게도 유용하다. 작업이 끝난 뒤 스스로 어떤 검증을 했는지 정리하게 만들면 리뷰어가 diff를 보기 전에 위험 지점을 알 수 있다.

자주 하는 실수

첫 번째 실수는 diff를 보기 전에 화면부터 보는 것이다. 화면이 잘 나오면 변경 범위를 놓치기 쉽다. 두 번째 실수는 테스트 통과를 신뢰하고 수동 확인을 생략하는 것이다. 테스트가 없는 영역은 통과할 수밖에 없다. 세 번째 실수는 에이전트가 고친 실패를 그대로 믿는 것이다. 실패를 고치면서 assertion을 약하게 만들었는지 확인해야 한다.

네 번째 실수는 리뷰 기준을 작업마다 새로 만드는 것이다. AI 작업은 반복될수록 검증 규칙이 중요해진다. 매번 감으로 보면 어떤 PR은 과검증하고 어떤 PR은 대충 넘긴다. 최소 게이트를 정해두면 속도와 안전성이 같이 올라간다.

실행 체크리스트

• AI 코드 변경은 항상 diff → terminal → browser 순서로 본다.
• diff에서 요청 밖 파일, 설정 파일, lockfile, 테스트 약화 여부를 먼저 확인한다.
• terminal에서는 팀이 실제로 쓰는 lint, typecheck, test 명령을 실행한다.
• 실패 수정 지시에는 “변경 범위 최소화”와 “원인 설명”을 포함한다.
• UI 변경은 happy path뿐 아니라 빈 상태, 에러 상태, 모바일 폭을 확인한다.
• PR 본문에 변경 목적, 실행 명령, 수동 확인, 남은 위험을 남긴다.
• 반복 작업에는 agent change minimum gate를 문서화한다.

Copilot app의 diff·terminal·browser 패널은 편의 기능처럼 보이지만, 본질은 AI 코드 검증 루프를 짧게 만드는 것이다. 좋은 팀은 에이전트가 코드를 빨리 쓰게 만드는 데서 멈추지 않는다. 빨리 검증하고, 작게 고치고, 안전하게 merge하는 루프를 만든다.