버그를 의논하던 대화에서 이슈를 열고, 휴대폰으로 변경을 읽다가 데스크톱에서 검토를 마친다. 코드 검토는 여러 화면을 오갈 수 있는 일이 됐다. 이때 파일만 따라오면 충분할까. 왜 바꾸는지, 어디까지 읽었는지, 승인을 막는 조건은 무엇인지도 함께 필요하다.
리니어는 11월 5일 Mobile Diffs를 iOS·안드로이드 앱으로 가져왔다. 같은 날 깃허브는 PR Overview의 공개 미리보기를 시작했고, 뒤이어 채팅 연동과 코드 검토 개요·API 설정을 안내했다. 하나로 묶여 출시된 기능은 아니지만, 검토가 옮겨 다닐 때 어떤 정보를 가까이 두는지 비교하기 좋은 변경들이다.
휴대폰에도 변경한 이유를 함께 가져오기
Mobile Diffs의 Guided Reviews는 큰 PR을 여러 구간으로 나누고 무엇이 왜 바뀌었는지부터 읽게 한다. 검토는 작업을 시작한 이슈나 피드백·버그 보고 옆에 놓인다. 사용자는 같은 자리에서 스레드에 답하고 댓글을 남기거나 에이전트에 수정을 요청할 수 있다. 휴대폰 화면에 파일 목록만 옮기기보다 변경의 이유를 함께 가져오는 방식이다.
미리보기 링크는 diff에서 열어 실제 휴대폰으로 모바일 변경을 살피게 한다. 휴대폰에서 확인한 파일의 열람 상태는 데스크톱에 이어지고 반대 방향도 같다. 어디에서 읽었는지를 다시 맞추는 부담을 줄이려는 구성이다. 리니어가 소개한 팀원의 활용 사례는 회사의 설명이며, 모든 팀에서 검토 품질이나 시간이 개선됐다는 시험 결과로 볼 수는 없다.
최신 앱이 필요하다. 아직 Diffs를 쓰지 않는 워크스페이스에는 관리자가 GitHub 통합의 코드 접근을 업그레이드해야 한다는 조건도 있다. 휴대폰에 검토 화면이 생기는 일과 저장소를 읽을 권한을 마련하는 일은 함께 준비해야 한다.
긴 대화보다 먼저 확인할 병합 조건
GitHub의 새 Overview는 긴 댓글과 타임라인 아래에 있던 병합 상태·다음 행동을 상단의 작은 요약으로 가져온다. 검사·댓글·승인을 곁에서 확인하고, 실패한 검사나 남은 승인처럼 다음 결정에 필요한 세부로 이동하도록 구성했다. 대화 중 해결되지 않은 항목이나 자신이 쓴 댓글을 좁혀 보고 최신순으로 읽는 기능도 포함한다.
이는 사용자가 선택해 들어가는 공개 미리보기이며, 기존 화면으로 돌아갈 수 있다. 초안을 검토 가능 상태로 바꾸거나 PR을 닫는 동작도 사용자의 권한에 따라 달라진다. 요약이 위에 보인다는 사실이 병합 조건이나 승인 책임을 없애는 것은 아니다.
별도로 바뀐 Copilot의 검토 개요는 발견한 항목을 위에 모으고, 건너뛰거나 내용 제외 설정이 적용된 파일을 하나의 검토하지 않은 파일 구역에 묶는다. 파일 이름과 제외 이유 링크를 함께 남긴다. 무엇을 발견했는지와 함께 어디를 읽지 않았는지가 보이면, 요약이 다루는 범위를 판단할 수 있다.
이 요청은 어디에서 시작됐을까
Slack·Teams의 @GitHub는 대화에서 이슈를 만들고 변경을 구현해 PR을 여는 흐름을 제공한다. Teams의 Canvas에서는 구현 계획·코드 변경·미리보기를 대화 옆에서 함께 볼 수 있다고 안내한다. 만들어진 이슈와 PR 설명에는 어느 채팅에서 누구의 요청으로 시작됐는지 귀속 정보를 붙인다.
코드 검토 API의 변경은 다른 층위다. Copilot의 리뷰와 댓글을 구분하는 귀속 필드, 확인 가능한 검토 노력 수준, 댓글의 근거로 보고된 skills·MCP 서버·사용자 지침을 조회할 수 있게 한다. 어떤 설정을 바꿀 수 있는지는 기업·조직·저장소 관리자 역할에 따라 갈리며 기업이 관리하는 설정은 아래에서 덮어쓸 수 없다.
채팅에서 작업을 시작할 수 있어도 API 설정을 바꿀 권한까지 생기는 것은 아니다. 공식 안내는 기업·조직 설정과 저장소 설정의 인증 수단 지원도 다르다고 밝힌다. 실제 연동을 준비할 때에는 어느 역할이 어느 설정을 관리하는지 따로 확인해야 한다.
| 접점 | 먼저 보이는 정보 | 별도로 남는 조건 |
|---|---|---|
| Linear Mobile Diffs | 이슈 맥락·구간별 변경·미리보기 | 앱 버전·저장소 코드 접근 |
| GitHub PR Overview | 병합 상태·차단 조건·다음 행동 | 선택형 공개 미리보기·사용자 권한 |
| Slack·Teams @GitHub | 대화 옆 계획·변경·미리보기 | 생성된 이슈·PR의 요청 귀속 |
| Copilot 개요·설정 API | 발견 항목·검토 제외·코멘트 근거 | 관리 역할·상위 정책·인증 수단 |
이슈 옆에서 이유를 읽고, 변경 구간을 살피고, 남은 검사와 승인을 확인한다. 채팅에서 시작했다면 요청의 출발점도 따라간다. 접점은 달라도 다음 판단에 필요한 정보를 이어 놓으려는 구성이 각 화면에 담겨 있다.
ARCH.B 의견
눈여겨볼 것은 정보를 가까이 놓은 자리다. 리니어는 diff 옆에 요청의 맥락을 두고, 깃허브는 긴 타임라인 위에 병합 조건을 올렸다. 검토하지 않은 파일의 이름과 이유까지 남긴 구성은 짧은 요약이 어디까지 읽은 결과인지 되묻게 한다.
작은 화면을 설계할 때 줄일 정보만 고르다 보면 이런 단서를 놓치기 쉽다. 기기를 옮겨도 왜 시작했고 어디까지 확인했는지가 남는다면 검토를 이어갈 실마리가 생긴다. 에이전트의 댓글과 사람의 승인도 그 흐름 안에서 각자의 이름을 가져야 한다.
