Linkedin 사례: 수용률 63.9% 뒤에 숨은 레포의 규칙

”Like”에는 잡히지 않는 진짜 수용률

리뷰 댓글의 ‘엄지척’은 호감의 표시일 뿐, 코드 반영 여부까지 알려주지는 않는다. LinkedIn은 주당 약 7만9천 건의 리뷰를 분석하면서 제안 내용과 병합된 코드를 대조했다. 7일 동안 1,727개 PR에서 표본 댓글 5,230개를 추출해 ACCEPTED, PARTIALLY_ACCEPTED, NOT_ACCEPTED, NOT_ACTIONABLE로 분류한 결과, 수용률은 63.9%였다.

병합 전후의 코드 차이가 판정을 명확히 뒷받침할 때만 LLM 평가기에 High 등급을 부여했다. 전체 판정 가운데 High는 4,711건으로 90.1%였고 Medium은 8.6%, Low는 1.3%였다. 이 방식으로 제안의 정확도와 개발자의 후속 조치, 판정의 신뢰도를 수용률에 반영하되 불확실한 사례는 별도로 남겼다.

AI 코드 리뷰 도구 CodeRabbit도 개발자가 직접 resolve(해결 처리)한 댓글을 수용 사례로 집계하지 않는다.

원클릭 커밋
AI 수정 후 검증
IDE(통합 개발 환경)에서 수정한 뒤 증분 리뷰
개발자 확인

이처럼 실제 처리 여부를 확인할 수 있어야 한다. 심각도와 범주별 수용률은 댓글 수와 함께 봐야 한다. 그래야 제안은 적지만 정확한 도구와 제안은 많아도 대부분 반영되지 않는 도구를 구분할 수 있다. 시험용 작업에 맞춘 공개 벤치마크만으로는 이런 차이를 확인하기 어렵다.

한 모델의 확신 vs. 독립된 모델의 교차검증

LinkedIn이 단일 벤더의 코드 리뷰 도구를 포기한 이유는 세 가지였다. 학습 데이터의 편향으로 같은 결함을 반복해서 놓쳤고 신뢰도가 낮은 경고를 계속 내놓았다. 하나의 규칙 파일만으로는 조직 정책과 레포 아키텍처, 작업별 지침을 따로 관리한 뒤 PR에 맞춰 조합하기도 어려웠다. 더구나 1만 개가 넘는 레포는 중요도와 소유권, 위험 수준이 모두 달랐다.

외부 제품에서는 모델이나 프롬프트 변경 사항을 일부 레포에서 먼저 시험하기 어려웠다. 제공자에게 장애가 생겼을 때 다른 모델로 바꾸는 작업도 쉽지 않았다. 전체 레포의 처리 지연과 경고 수용률, 정확도를 관측하고 자체 평가 결과에 따라 출시를 중단할 장치도 부족했다.

LinkedIn은 서로의 결과를 볼 수 없는 여러 모델과 하네스(모델을 실행하고 도구와 연결하는 실행 틀)를 병렬로 실행했다. 오케스트레이터(여러 모델의 실행을 지휘하는 조정 계층)는 결과 수집과 중복 제거, 교차검증, 규칙 적용, 게시를 맡았다. 두 모델이 같은 문제를 독립적으로 발견하면 신뢰도가 높은 경고로 분류했다. 한 모델만 발견한 문제도 별도의 검증과 중요도 평가를 거쳤다. 다른 모델의 발견 내용을 전달받은 첫 번째 모델이 자신이 놓친 문제라고 인정하는 경우도 있었다.

추가 토큰 사용량과 처리 지연은 중복 제거 단계에서 검증 자료로 활용했다. 조직, 레포, 개별 사례에 적용되는 규칙도 PR마다 조합했다. 플러그인 지침과 OTEL(OpenTelemetry, 시스템 관측 데이터 수집 표준) 메트릭 전환 규칙, 전역 YAML 예외 처리 규칙 등이 이에 해당한다.

Cloudflare도 최대 7개의 전문 리뷰어와 조정자를 운영했다. 불필요한 경고를 막기 위한 기준을 명시해 리뷰 한 건당 평균 발견 건수를 약 1.2건으로 제한했다.

178개 레포가 설정을 네 번씩 고친 이유

LinkedIn에서 저장소별 수용률은 0%에서 100%까지 큰 차이를 보였다. 같은 모델을 써도 저장소의 기준과 허용 범위, 모델이 모르는 내용을 규칙에 얼마나 반영했는지에 따라 결과가 달라졌다. 결제 서비스와 프론트엔드 실험용 저장소에 같은 리뷰 기준을 적용하기는 어렵다.

성숙한 저장소 178곳을 대상으로 GitHub Actions 기반 AI 리뷰를 분석한 연구에서는 82.6%가 선택 매개변수를 조정했고 설정은 평균 네 차례 수정했다.

조정 항목	비율
프롬프트에 문맥 보강	70.1%
LLM 교체	64.6%
입력 설정 수정	47.6%

변경 부분에 직접 의견을 남기는 인라인 리뷰는 파일 단위 리뷰보다 반영률이 높았다. 반면 자동 실행은 반영률과 음의 상관관계를 보였다. 기본 설정과 저장소의 특성에 맞춘 설정이 서로 다른 결과를 낸 셈이다.

로직 오류는 지적의 80%가 받아들여졌고 가장 많은 비중을 차지한 버그 수정은 58.1%, 동시성 버그는 100%였다. 리팩터링은 43.5%, 보안은 40.6%에 머물렀다. 주관적 판단이나 문맥의 영향을 많이 받는 항목은 단정적인 처방을 줄여야 한다. 사람이 발견했지만 AI가 놓친 의견을 분석해 규칙도 계속 보완할 필요가 있다.

받아들여지지 않은 의견 약 46%에는 아키텍처 설계 의도와 사업 우선순위, 팀 관례, 변경된 코드만으로 파악하기 어려운 위험에 관한 판단도 들어 있었다. 수용률은 AI의 정답률이 아니라 제안이 개발자의 행동을 이끌 만큼 유용했는지를 나타낸다. 채택 여부는 사람이 결정한다.

주당 4만 PR 뒤에 숨은 카나리 배포 체계

범용 제품에는 같은 모델이 반복해서 놓치는 문제, 단일 규칙 문서의 한계, 카나리 배포(변경을 일부 대상에만 먼저 적용해 보는 방식)와 장애 전환 체계의 부재가 남아 있다. 전체 상황을 관측하기 어렵고 출시 전 평가도 부족하다. 주당 7만9천 건을 처리하는 환경에서는 불필요한 댓글이 늘어날수록 개발자가 리뷰 도구 자체를 무시하게 된다.

LinkedIn은 이벤트 큐와 쿠버네티스 워커를 이용해 호스트마다 PR 12건을 동시에 처리한다. 7,500개가 넘는 레포에서 매주 4만 건 이상의 PR을 검토하며 완료율은 99.1%다. 지연 시간과 리뷰 수용률, 완료 여부, 서비스 제공자의 장애도 기록한다. 변경 사항은 단계적으로 배포하고 장애가 발생하면 일부 기능을 제한한다. 이벤트는 5초 안에 큐에 등록되고 약 90초 뒤 리뷰가 시작된다. 대부분 10분 안에 끝난다.

버티컬 AI(특정 산업, 업무에 특화된 AI)의 방어력은 범용 모델의 크기보다 데이터 파이프라인에서 나온다. 조직 정책과 레포 관례, 마이그레이션, 플러그인 규칙, 병합 후 수용 결과를 서로 연결한 데이터다. LinkedIn은 SEV0, SEV1(가장 높은 등급의 서비스 장애) 사고에서 얻은 정보를 리뷰 규칙에 반영하는 절차도 구축하고 있다. 지식을 버전별로 관리하고 일부 레포에서 먼저 시험하며 장애가 나면 이전 버전으로 전환한다. 이런 제어 체계는 기본 프롬프트만 제공하는 제품과 도입 기준부터 다르다.

출시 전에는 새 프롬프트와 모델, 하네스를 현행 버전과 블라인드 방식으로 비교한다. 평가 대상의 위치도 서로 바꿔 순서에 따른 편향을 줄인다. 고정된 평가 항목에 가중치를 적용한 총점이 현행 버전보다 높거나 같아야 배포할 수 있다.

출시 후에는 실제로 병합된 코드를 기준으로 수용률을 측정한다. 두 평가 흐름을 대조해 어떤 변경이 성능 저하와 수용률 하락을 일으켰는지 찾고 수정안도 자동으로 제시한다. 성공 지표와 3단 규칙을 정한 뒤 여러 에이전트가 결과를 검증하고 불필요한 댓글을 억제한다. 여기에 카나리 배포, 전체 관측, 장애 전환, 출시 전 평가를 함께 운영하면 같은 모델을 사용해도 레포별 수용률을 조직 평균인 63.9%보다 높일 수 있다.

출처

#기업 AI #언어모델