- LLM 코딩 도구의 잦은 오류를 사람이 모두 검토하면 된다는 해법은 코드 리뷰의 처리 한계 때문에 품질과 생산성을 함께 보장하기 어려움
- 경험적 연구에 따르면 효과적인 리뷰는 한 번에 1시간·400 LOC 정도가 상한이며, 이를 넘으면 피로와 집중력 저하로 결함 탐지 효과가 빠르게 감소함
- 이 기준을 적용하면 LLM이 작성한 400 LOC마다 숙련 개발자의 집중 검토 1시간이 필요해, 현실적인 일일 처리량은 1,000 LOC 미만일 수 있음
- 인간은 LLM 생성 코드에서 결함을 덜 찾으면서도 더 강한 확신을 보인다는 초기 증거가 있어, 검토만으로 오류를 충분히 걸러낼 수 있다고 보기 어려움
- LLM 코드의 결함 탐지율·검토 속도·일일 지속 가능량을 직접 측정하고 재현하는 경험적 연구가 있어야 도구의 실효성을 일화가 아닌 근거로 판단할 수 있음
LLM 코딩 도구를 회의적으로 보는 이유
- 문제의 초점은 지식재산권, 생태적 비용, 자원 소비나 LLM 결과물이 전부 형편없다는 평가에 있지 않음
- 현재의 과학적 근거만으로는 LLM 코딩 도구가 개발자의 코드를 더 좋거나 빠르게 작성하도록 돕는 방식을 확인하기 어려움
- 옹호론은 관련 문제와 증거를 직접 다루지 않으며, 회의론에 대한 반박이 오히려 문제를 강화하기도 함
- 약 1년 전에 작성된 글이라 현재는 거의 대체된 Coding Assistants라는 표현을 사용하지만, 생성형 AI의 다양한 코딩 용례를 모두 포괄할 다른 용어를 찾지 못해 그대로 유지함
‘인턴’ 비유와 전면 검토 해법
- LLM 코딩 도구는 작동 구조와 상호작용 인터페이스 등의 이유로 비교적 높은 오류 위험을 가짐
- 환각이나 오타를 만들 수 있음
- 요청과 관계없는 결과를 내거나 다른 경로로 작업을 진행할 수 있음
- 사용자는 이런 도구를 종종 인턴에 비유함
- 결과가 어느 정도 잘못됐을 것으로 예상해야 함
- 무엇을 하는지 제대로 이해하지 못한 채 작업한다고 간주해야 함
- 널리 쓰이는 대응은 인턴이나 주니어 개발자의 코드처럼 숙련된 사람이 결과를 전부 리뷰하는 방식임
- 인간이 더 잘 알고 최종 책임도 진다는 전제에 기반함
- 코드베이스에 들어가는 모든 코드는 원래 리뷰 대상이라는 논리도 뒤따름
LLM 감독에 필요한 리뷰 수준
- 업계와 연구 문헌에서 리뷰는 서로 다른 여러 실무를 포괄함
- 가볍고 여러 사람에게 분산된 리뷰는 변경 사항에 관한 지식을 공유하고 표면적인 규칙을 적용하는 데 유용하지만, LLM 코드를 감독하는 기준으로는 부족함
- 과거의 위원회식 검토처럼 몇 시간 동안 모든 줄을 고통스럽게 확인할 필요까지는 없지만, 상당히 깊고 완전한 코드 리뷰가 필요함
- LLM이 복잡한 코드를 작성할 수 있고 소프트웨어의 세부 사항에 결함이 숨어 있으므로 가벼운 확인만으로는 충분하지 않음
코드 리뷰가 맞닥뜨리는 경험적 한계
- 경험적 연구에서 확인된 효과적인 리뷰의 주요 한계는 다음과 같음
- 한 번의 리뷰 세션이 1시간을 넘으면 지나치게 길어짐
- 그 시간에 효과적으로 검토할 수 있는 양은 최대 400 LOC 정도임
- 1시간을 넘긴 리뷰는 코드 크기와 관계없이 효과가 빠르게 체감함
- 이미 대부분을 검토했기 때문만은 아님
- 높은 집중도를 1시간 유지하면 피로와 지루함이 생겨 휴식이 필요해짐
- 1시간짜리 세션 사이에 필요한 회복 시간을 조사한 연구는 찾지 못함
- 극단적인 상한으로 하루 몇 차례를 가정할 수 있음
- 평균적인 가능 횟수로 하루 2회 정도가 제안되지만 확정된 수치는 아님
- 시간당 검토 가능한 코드 줄 수는 코드의 맥락과 종류, 검토자의 경험과 지식에 따라 크게 달라짐
- 절대적인 기준은 아니지만 400 LOC/H보다 빠른 리뷰가 결함을 효과적으로 찾아 표시한 사례는 경험적 데이터에서 거의 없어, 이를 실효성 있는 최대 속도로 볼 수 있음
LLM 코드에 적용한 처리량 계산
- LLM 코드의 문제를 리뷰로 해결하려면 최선의 경우에도 생성된 400 LOC마다 숙련 개발자 1시간이 필요함
- 개발자에게 허용되는 리뷰 세션은 주당 약 10~40회이며, 각 세션 사이에는 길이를 알 수 없는 회복 시간이 필요함
- 회복 시간은 적어도 1~2시간일 수 있지만 이를 뒷받침하는 직접 연구는 없음
- 이런 집중 시간은 회의, 설계, 장애 대응, 직접 작성할 코드에 대한 사고에도 쓰여야 함
- 최상의 경우 LLM을 이용하는 개발자가 작성·검토·커밋할 수 있는 양은 하루 수천 LOC임
- 현실적인 시나리오에서는 일일 처리량이 1,000 LOC 미만일 수 있음
- 여기에는 보일러플레이트, 테스트, 마이그레이션, 설정 파일이 모두 포함됨
- 단일 테스트 파일도 400 LOC를 넘을 수 있음
- 코드 대부분이 단순하고 검토하기 쉬운 최상의 조건에서도 리뷰가 생산성 향상의 상한선으로 작용함
인간 코드와 LLM 코드의 리뷰 차이
- 기존 근거는 사람이 작성한 코드의 결함을 인간 리뷰어가 찾는 상황에서 나왔으며, LLM 코드에도 같은 효율이 적용된다는 증거는 없음
- 초기 증거에서는 LLM 생성 코드를 검토한 사람이 더 적은 결함을 발견하면서도 모든 결함을 찾았다는 확신은 더 강해지는 경향이 나타남
- 인간 작성자와 인간 리뷰어의 조합보다 LLM 코딩 도구와 인간 리뷰어의 조합이 더 낮은 품질의 결과를 만들면서도, 후자의 리뷰어가 자신의 성과를 더 높게 평가할 수 있음
- 전면 리뷰는 LLM의 생산성 이점을 제한할 뿐 아니라, 빈번한 오류를 실제로 해결한다는 확실한 근거도 부족함
결함 수정 전부터 발생하는 비용
- 이 계산에는 발견된 결함을 수정하는 비용이 포함되지 않음
- 전문 개발자가 업무 환경에서 코드를 검토하고 문제를 표시하는 능력과 비용만 다룸
- LLM이 만든 결함의 수나 심각도와 관계없이 생성 코드를 검토하는 비용은 발생함
- LLM 코딩 도구가 매우 높은 품질의 코드를 만들더라도 모든 결과를 검토한다는 조건에서는 동일한 비용과 생산성 한계가 남음
검토하기 어려운 코드를 맡기는 모순
- LLM 옹호론은 사람이 작성하기 고통스러운 코드를 도구가 대신 생산할 수 있다는 점을 장점으로 내세움
- 한 사례는 앞으로 필요한 Bash 코드의 100% 를 LLM이 작성하도록 제안함
- 셸 스크립트는 파싱이 느슨하고 의미가 과도하게 중첩돼, 구두점 하나의 오타가 무해할 수도 있고 컴퓨터 전체를 삭제하는 결과로 이어질 수도 있음
- 이런 코드는 오류를 만들기 쉽고 이해와 검토가 어려우며, 치명적인 실수를 알아차리기도 어려움
- 무작위로 오류를 내는 도구에 가장 검토하기 어려운 코드를 맡긴 뒤 인간이 확인하면 된다는 방식은, LLM 출력이 실제로 효과적인 검토 대상인지 먼저 입증하지 못함
- 검토가 오류를 해결하는지, 충분한 생산성 향상이 남는지 답하지 않은 채 가장 검토하기 어려운 코드를 대표 활용 사례로 삼는 것이 문제임
검증해야 할 실증 과제
- 첫 번째 과제는 인간 리뷰어가 LLM 생성 코드의 결함을 얼마나 잘 찾는지 측정하는 것임
- 결함 탐지 능력
- 리뷰 속도
- 하루 동안 지속할 수 있는 리뷰량
- 인간 작성 코드를 대상으로 한 연구처럼 인간이 LLM 코드를 리뷰하는 데이터가 필요함
- 기존 실험과 경험적 데이터는 규모와 맥락이 제한적이므로 더 많은 재현 연구가 요구됨
- 현재의 과학적 데이터는 인간이 LLM 결과를 잘 검토하지 못하거나 그 문제를 탐지하기 어렵다는 쪽을 가리킴
- LLM이 탐지를 회피하도록 훈련된다는 특성과 일치할 수 있음
- 기존 결과가 우연이었을 가능성도 검증해야 함
- 두 번째 과제는 LLM 생성물 리뷰가 인간 작성물 리뷰와 질적으로 다른 문제인지 확인하는 것임
- 기존 코드 리뷰 연구가 적용되지 않을 정도로 차이가 크다면 현재의 비판 논리는 무너질 수 있음
- 다만 초기 증거는 LLM 생성 코드의 리뷰가 더 쉽기보다 더 어려울 가능성을 가리키며, 이 경우 비판은 오히려 강화됨
일화가 아닌 전문 도구의 실증 평가
- 코드 리뷰에 관해 알려진 사실을 고려하면, 현재 인터페이스와 절차를 사용하는 LLM 도구가 전문 개발자에게 어떤 이익을 주는지 확인하기 어려움
- 공급업체가 근거와 충돌하는 도구와 절차를 반복해서 제공하는 것보다, 문제를 다루지 않은 채 회의론자를 비정상적으로 취급하는 태도가 더 큰 불만의 대상임
- TDD, 타입 시스템, 테스트·개발 조직 분리, CI/CD, DevOps에서도 경험적 증거보다 일화가 우세하는 양상이 반복돼 왔음
- “이번에는 내게 효과가 있었다”는 사례에 기대는 대신, 코드 리뷰의 경험적 근거가 만들어진 방식을 따라 실제 연구를 수행해야 함
- LLM 코딩 도구를 전문적인 개발 도구로 다루려면 인간공학과 경험적 증거를 중심으로 효과와 한계를 검증해야 함