CodeMate

변경 파일이 많은 PR을 열면 화면 밖 코드까지 렌더링하느라 DOM 요소가 많아졌습니다. 특히 공동 리뷰방에서 PR 화면으로 돌아왔을 때, 처음 확인할 코드 행이 늦게 표시되는 문제가 있었습니다.

파일 목록과 각 파일 제목은 유지하고, Diff 본문은 스크롤로 가까워졌을 때 파싱하고 렌더링하도록 바꿨습니다. IntersectionObserver를 사용해 화면 주변 파일을 준비하되, 선택 중인 파일이나 댓글 작성 중인 파일은 계속 렌더링합니다. 화면 밖 영역에는 높이 추정값을 남겨 스크롤 위치 변화도 줄이도록 했습니다.

PR 제목·상태는 서버에서 먼저 조회하고, 변경 파일은 별도 클라이언트 요청으로 가져오도록 분리했습니다. 이 덕분에 파일 조회가 끝나지 않아도 기본 정보를 표시할 수 있습니다.

운영 PR 1건, 변경 전후 각 20회 순차 측정: PR 복귀 후 첫 코드 행 표시 시간 중앙값이 3.259초 → 2.334초로 약 28.4% 감소했고, 해당 시점의 DOM 요소 수는 18,163개 → 1,766개로 감소했습니다. 다른 PR이나 실제 사용자 전체의 성능을 대표하는 값은 아닙니다.

AI 리뷰 이력 페이지는 통계, 저장소 필터, 리뷰 목록을 병렬로 조회했지만 모든 조회가 끝난 뒤 페이지를 반환했습니다. 목록 조회가 늦어지면 페이지 제목과 이미 준비된 통계도 스켈레톤 뒤에서 함께 기다렸습니다.

페이지 제목과 탭을 먼저 표시하고, 통계·저장소 필터·리뷰 목록을 각각 데이터를 조회하는 Server Component로 분리했습니다. 영역마다 Suspense 경계와 스켈레톤을 두어 목록을 기다리는 동안 준비된 영역부터 서버에서 전송하도록 바꿨습니다.

로컬 프로덕션 빌드, 전후 각 15회 측정: 리뷰 목록 조회에만 동일한 3초 지연을 적용했습니다. Performance 스크린샷의 첫 표시 프레임 기준 중앙값은 통계 숫자 4.522초 → 1.555초(약 3.0초 단축), 저장소 필터를 포함한 필터 폼 **4.522초 → 1.260초(약 3.3초 단축)**였습니다. 목록을 포함한 전체 문서 완료 시간은 약 4.2초로 비슷했습니다.

영역별 Suspense로 나누고 화면 표시 시점을 측정한 과정

원격으로 PR을 검토할 때 상대가 보고 있는 파일과 줄을 말로 맞춰야 했습니다. 대화 중 나온 의견을 실제 PR 리뷰로 남기는 과정도 따로 이어야 했습니다.

파일·스크롤·코드 위치는 방 참여자에게 계속 전달해야 해서 Socket.IO의 방 단위 이벤트로 공유했습니다. 연결이 끊겼다가 돌아오는 경우도 처리해 참여자가 다시 현재 위치를 확인할 수 있게 했습니다. 음성은 브라우저 간 미디어 연결을 다루는 WebRTC를 사용하고, 연결에 필요한 신호만 Socket.IO로 전달합니다. 같은 코드 위치를 보면서 바로 대화할 수 있도록 역할을 나눈 것입니다.

채팅은 저장해 재접속 후에도 확인할 수 있게 했습니다. 논의한 내용 중 사용자가 선택한 일반 리뷰 또는 코드 줄 리뷰만 GitHub PR에 게시하며, 줄 리뷰는 최신 Diff에서 유효한 위치인지 확인합니다.

음성 참여는 리뷰방 참여자로 제한하고 최대 4명까지 연결되도록 구성했습니다. Socket·음성 훅 테스트에서는 참여 권한, 인원 제한, 연결 신호 전달과 종료 시 정리를 확인했습니다. GitHub API 모의 테스트에서는 일반·줄 리뷰 게시, 오래된 코드 위치 거부와 게시 오류 처리를 확인했습니다.

버튼을 비활성화해도 다른 탭이나 여러 클라이언트에서 같은 PR의 AI 리뷰를 동시에 요청할 수 있습니다. 프론트엔드 상태만으로는 중복 작업 생성을 막기 어렵습니다.

화면에는 요청 직후 대기 상태를 표시하고, 서버에서는 진행 중인 작업을 확인합니다. PostgreSQL 부분 고유 인덱스로 한 PR에서 PENDING 또는 IN_PROGRESS 상태인 리뷰가 동시에 한 건만 존재하도록 제한했습니다. 동시 삽입이 충돌하면 진행 중인 작업이 있는 상황으로 처리합니다.