Gautam Korlam, Sonar 수석 엔지니어 – 인터뷰 시리즈

Gautam Korlam, Sonar 수석 엔지니어, 는 개발자 인프라, 코드 품질, 자동화 및 AI 지원 소프트웨어 개발에 초점을 맞춘 경력을 가진 베테랑 소프트웨어 엔지니어이자 기술 리더입니다. Sonar에 합류하기 전에 그는 Gitar를 공동 설립하고 CTO로 재직하며 코드 리뷰 자동화, 지속적 통합(CI) 실패 진단, 근본 원인 파악 및 수정 생성을 목표로 하는 AI 기반 플랫폼을 구축했습니다. Sonar는 2026년 5월 Gitar를 인수했으며, Korlam과 Gitar 팀은 Sonar의 보다 포괄적인 코드 검증 플랫폼의 일환으로 기술 개발을 지속하기 위해 합류했습니다. Gitar 이전에 Korlam은 Uber에서 거의 10년간 근무하며 모바일 플랫폼 팀의 창립 엔지니어에서 수석 엔지니어까지 성장했습니다. 재직 기간 동안 그는 Uber의 중앙 개발자 인프라를 구축·확장하고, 대규모 모노레포 및 빌드 시스템 프로젝트를 이끌었으며, 원격 개발 환경 및 CI/CD 도구를 개발하고, StarCoder, OctoCoder, Code Llama와 같은 오픈소스 대형 언어 모델을 실험하여 Uber 코드베이스 내 AI 지원 코딩을 향상시켰습니다. 그의 초기 경력으로는 Lookout에서의 엔지니어링 역할, UC Santa Barbara에서의 연구 작업, 그리고 Microsoft와 Oracle에서의 인턴십이 포함됩니다.

Sonar는 코드 검증, 자동 코드 리뷰, 코드 품질 및 애플리케이션 보안에 중점을 둔 소프트웨어 기업입니다. 대표 제품인 SonarQube 플랫폼은 개발자가 작성한 코드와 AI가 생성한 코드를 분석해 버그, 취약점, 유지보수성 문제 및 기타 품질 이슈를 프로덕션에 도달하기 전에 식별합니다. 클라우드, 자체 관리형, 통합 개발 환경 워크플로우 등 다양한 형태로 제공됩니다. Sonar에 따르면 자사의 기술은 700만 명 이상의 개발자와 22,000개 고객이 사용하고 있으며, 매일 7,500억 라인 이상의 코드를 분석합니다. Gitar 인수로 AI 기반 코드 리뷰와 수정 기능이 추가되어 SonarQube 검증 엔진과 코드 리뷰, CI 실패 조사, 수정 제안·적용이 가능한 에이전트 도구가 결합되었습니다. 이는 소프트웨어 개발이 점점 AI 중심으로 전환되는 흐름에 부합합니다.

당신의 경력은 Uber의 모바일 및 개발자 인프라 구축에서 시작해 오픈소스 대형 언어 모델을 코드베이스에 적용한 뒤, Gitar를 공동 설립하고 인수 후 Sonar에 합류하는 여정이었습니다. 이러한 경험이 코드를 생성하는 것이 문제의 일부에 불과하고, 이를 신뢰성 있게 검증하는 것이 더 어려운 과제라는 믿음에 어떻게 영향을 주었나요?

Uber에서는 누가 배포할지를 결정하는 시스템, 즉 모노레포, 빌드, CI 대기열, 테스트 스위트 등을 담당했습니다. 변경을 더 쉽게 만들수록 그 기계에 가해지는 압력이 커집니다. 예측하지 못한 방식으로 서비스가 서로 상호작용하게 되고, 변경이 안전하게 병합될 수 있는지 확인하려는 엔지니어가 늘어나게 됩니다.

그 후 자체 코드베이스에 모델을 학습시키는 작업을 했는데, 여기서 비대칭성이 명확해졌습니다. 모델은 빠르게 설득력 있는 구현을 만들어낼 수 있지만, 그 구현이 실제 프로덕션 시스템에 맞는지, 팀이 실제로 사용하는 관례를 따르는지, 두 서비스 간에 문제를 일으키지 않는지를 확인하는 데는 훨씬 더 많은 시간이 걸리며, 대부분의 작업이 사람에게 돌아갑니다. Gitar는 바로 그 문제를 해결하기 위해 탄생했으며, Sonar가 17년 넘게 해오던 분석 작업과도 일맥상통합니다.

AI 기반 코드 리뷰는 결정론적 분석을 대체하기보다 보완해야 한다고 주장하셨습니다. 반복 가능하고 규칙 기반 분석이 가장 효과적인 문제 유형은 무엇이며, 전통적인 기법으로는 해결하기 어려운 영역은 어디인가요?

규칙 기반 분석은 코드 자체만으로 판단 가능한 속성에 적합합니다. 오염된 입력이 싱크에 도달하거나, 누락된 경로에서 발생하는 null 역참조, 하드코딩된 자격 증명, 알려진 CVE가 있는 의존성, 허용되지 않은 레이어를 넘는 import 등은 매 실행마다 동일한 결과를 제공하고, 왜 경고가 발생했는지 바로 지적할 수 있기 때문에 이 레이어에서 강제 적용됩니다.

하지만 규칙이 다루지 못하는 것은 의도입니다. 파서는 사용자에게 보여지는 문자열이 번역 시 모호해질 수 있다는 점이나, 변경이 티켓을 닫는다고 주장하면서 실제로는 티켓 요구사항의 절반만 구현했는지, 새로운 재시도 루프가 서비스 전체의 백프레셔 처리 방식과 충돌하는지를 알려주지 못합니다. 차이와 이슈, 전체 코드베이스 컨텍스트를 함께 읽는 모델은 이러한 점들을 제시할 수 있으며, 이는 사람의 검토를 위한 발견으로 제시되어야지 최종 판결로 제시돼서는 안 됩니다.

AI 시스템은 비즈니스 로직, 개발자 의도 및 아키텍처 트레이드오프를 평가할 수 있지만, 그 결론은 확률적입니다. 개발 팀이 이러한 컨텍스트 기반 추론을 활용하되 AI 리뷰어의 결과를 절대적으로 옳다고 받아들이지 않으려면 어떻게 해야 할까요?

AI 리뷰는 기존 체크가 놓치는 문제—논리 오류, 의도와 맞지 않는 동작, 자체적으로는 괜찮아 보이지만 특정 시스템에서는 잘못된 변경—에 대해 가치를 발휘합니다. 이러한 결론은 확률적이므로 의사결정 입력의 하나로 활용돼야 하며, 최종 결정이 되어서는 안 됩니다. 팀은 병합 전 deterministic 제어(자동화 테스트, CI 검증, 보안 스캔, 정책 체크, 그리고 변경을 담당하는 사람)를 유지함으로써 경계를 잡습니다. AI는 수정안을 제시하거나, 팀이 정의한 가드레일 안에서 자동으로 구현할 수 있지만, 그 변경도 사람이 작성한 코드와 동일한 검증을 통과해야 하며, 기계가 생성했다는 이유만으로는 예외가 주어지지 않아야 합니다.

우리 자체 구현에서도 같은 경계를 적용합니다. 모델은 발견을 제안하고, 리뷰 판정은 그 발견들의 상태를 기반으로 코드에서 계산됩니다. 해결 과정도 동일합니다. diff에서 해당 코드가 사라지면 이는 파싱된 diff에 대한 deterministic 체크이며, 모델이 이미 해결된 diff를 다시 “미해결” 상태로 만들 수 없습니다.

일반적인 원칙은 확률적 레이어에 대해 잘못될 수 있는 작업만 맡기고, 상태 머신은 deterministic하게 유지하며, 책임은 팀에 두는 것입니다. 신뢰를 얻는 방법은 누군가가 검증하고 제어할 수 있는 증거를 제공하여 매 실행마다 동일하게 동작하도록 하는 것입니다.

Sonar는 컨텍스트 인식 풀 리퀘스트 리뷰와 deterministic 분석, 품질 게이트를 결합하고 있습니다. 효과적인 다층 검증 프로세스는 어떻게 구성되어야 하며, 서로 다른 레이어가 작업을 중복하거나 개발자를 과도한 발견으로 압도하지 않도록 어떻게 상호 작용해야 할까요?

Deterministic 분석과 품질 게이트는 협상 여지가 없는 항목을 담당하며, 병합 차단의 기준이 됩니다. 컨텍스트 기반 리뷰는 변경이 주장하는 대로 동작하는지, 코드베이스에 적합한지, 특정 위험이 사람의 주의를 끌 만큼 가치가 있는지를 판단합니다.

발견이 너무 많으면 거의 발견이 없는 경우와 동일하게 무시됩니다. 우리는 리뷰어 간에 중복을 제거하고, 검증할 수 없는 후보는 제외하며, 신호가 강한 발견에 집중합니다. 규칙 측면에서는 모델이 실행되기 전에 현재 diff에 규칙이 적용되는지 판단하는 프레디케이트가 있어 대부분의 규칙은 대부분의 변경에 비용을 발생시키지 않습니다. 모든 내용은 개발자가 이미 열어 놓은 풀 리퀘스트에 그대로 표시됩니다.

코드와 풀 리퀘스트를 생성하는 에이전트가 늘어남에 따라 소프트웨어 리뷰와 검증이 새로운 병목 현상이 될까요? 리뷰 프로세스 중 어떤 부분을 자동화하고, 어떤 결정은 숙련된 엔지니어에게 남겨야 할까요?

리뷰와 검증은 이미 병목이 되었습니다. 실제로 우리 2026 State of Code Developer Survey에 따르면 팀은 작업 주당 약 1/4을 AI 출력 확인 및 수정에 소비한다고 보고했습니다. 이 때문에 개발자의 48%만이 커밋 전에 AI 생성 코드를 항상 확인하고, 대부분(96%)은 기능적으로 정확하다고 완전히 신뢰하지 않는 것으로 나타났습니다.

자동화 가치가 있는 작업은 기계적이고 지루한 일입니다: 수천 줄 로그를 읽지 않도록 CI 실패를 근본 원인까지 추적하고, 리베이스 후에도 발견이 여전히 적용되는지 판단하고, 실패를 재현하고, 명백한 수정을 작성하는 일 등입니다. 엔지니어는 의도, 설계, 그리고 특정 변경에 충분한 증거가 무엇인지에 대한 판단을 유지해야 합니다. 선임 엔지니어가 저녁에 로그를 읽어 9가지 실패 중 어떤 것이 중요한지 판단한다면, 이는 판단이라기보다 트리아지이며, 바로 우리가 대신해 줘야 할 작업입니다.

AI 코드 리뷰 시스템은 문제를 식별하고, 수정을 제안하며, 지속적 통합 파이프라인에 대한 변경을 검증할 수 있습니다. 자동화된 수정 시스템이 회귀를 도입하거나 빌드 성공만을 좁게 최적화하지 않도록 어떻게 방지할 수 있나요?

가장 중요한 것은 초록(성공) 상태를 최종 합격 기준으로 삼지 않는 것입니다. 통과된 빌드가 의미하는 것은 기존 테스트가 실패하지 않았다는 것뿐이기 때문입니다.

우리 자체 수정 시스템에 적용하는 제약 대부분은 범위에 관한 것입니다. Gitar는 깨진 CI를 고치고, 자체 푸시 전 커밋이 초록인지 확인한 뒤에만 책임을 집니다. 두 번의 후속 커밋 이후에는 멈추며, 빨간 빌드에 계속 매달리지 않습니다. 실패가 변경과 무관한 플리키 테스트나 인프라 일시적 오류라면, 수정 경로가 아니라 재시도 경로를 택합니다. “테스트가 실패하지 않게 만들라”는 목표는 능력 있는 에이전트가 가장 피하고 싶은 것입니다.

그 이후 변경은 Gitar가 제어하지 않는 레이어를 통과해야 합니다. SonarQube는 자체 기준으로 결과를 평가하고, 품질 게이트는 병합 여부를 결정하며, 정책은 팀이 소유합니다. 또한 우리는 변경이 구현한다고 주장하는 이슈와 대조해 확인합니다. 요구사항 추출은 완성 판단과 별도로 유지되어, 티켓에 남겨진 요구사항이 구현된 것으로 착각되지 않게 합니다.

효과적인 AI 코드 리뷰는 저장소의 관례, 의존성, 아키텍처 및 제안된 변경의 목적을 이해해야 합니다. AI 리뷰어가 유용한 결정을 내리기 위해 필요한 컨텍스트는 무엇이며, 조직은 시스템이 진화함에 따라 그 컨텍스트를 어떻게 정확하게 유지할 수 있을까요?

단순히 diff를 읽는 수준을 넘어, 숙련된 리뷰어처럼 추론할 수 있을 만큼 충분한 컨텍스트가 필요합니다. 여기에는 변경 목적, 관련 코드 경로와 타입 정보, 의존성, 테스트 동작, 저장소 관례, 그리고 팀이 기대하는 아키텍처 경계가 포함됩니다.

이 컨텍스트는 코드와 함께 살아 있어야 합니다. 규칙과 리뷰 가이드를 저장소에 버전 관리하고, 서비스나 관례가 바뀔 때 업데이트하며, 아키텍처와 정책 결정에 대한 소유권을 명확히 해야 합니다. 그렇지 않으면 AI 리뷰어가 개별적으로는 설득력 있어 보이지만, 전체 시스템과 충돌하는 제안을 만들 수 있습니다.

Deterministic 분석은 일관되고 감사 가능한 결과를 제공하고, 대형 언어 모델 기반 리뷰는 실행마다 달라질 수 있습니다. 규제 혹은 보안이 중요한 환경에서 AI 생성 발견을 어떻게 문서화·재현·관리해야 할까요?

감사 로그에는 리뷰된 변경, AI 발견, 내린 결정, 그리고 결과를 검증하는 데 사용된 독립적인 증거가 모두 기록되어야 합니다. 팀은 AI를 활용해 리뷰와 수정 속도를 높이면서도, 시행 및 승인 결정은 정의된 정책과 인간 책임에 기반하도록 유지할 수 있습니다.

엔지니어링 리더는 AI 코드 리뷰가 실제로 소프트웨어 개발을 개선하고 있는지 판단하기 위해 어떤 지표를 사용해야 할까요? 리뷰 시간, 누수된 결함, 오탐률, CI 실패, 기술 부채, 개발자 신뢰 등 중 무엇을 우선시해야 할까요?

우선 결과에 집중해야 합니다. AI 시스템이 생성한 댓글 수가 아니라 풀 리퀘스트에서 병합까지 걸리는 시간, CI 실패 진단에 소요되는 시간, 첫 번째 검증 시 수정이 통과되는 비율, 그리고 이슈가 이후 단계나 프로덕션에 얼마나 많이 넘어가는지를 측정합니다.

그 다음에는 오탐 및 무시 비율, 재오픈된 이슈, 최근 병합된 변경으로 인한 회귀, 그리고 발견이 실질적으로 활용 가능한지에 대한 개발자 피드백을 살펴봅니다. 적절한 지표 조합은 팀마다 다르지만, 핵심 질문은 동일합니다: 재작업과 리뷰 대기 시간을 줄이면서 안전하고 신뢰할 수 있는 소프트웨어 기준을 낮추지는 않았는가?

앞으로 소프트웨어 개발이 에이전트가 코드를 생성·리뷰·테스트·수정하는 연속적인 루프가 되고, 이를 deterministic 가드레일이 제어하는 형태가 될 것으로 보십니까? 그런 환경에서 인간 소프트웨어 엔지니어의 역할과 필요한 역량은 어떻게 변할까요?

그 루프는 이미 존재하고, 팀은 보통 탐지 → 수정 → 정책에 따른 승인 → 병합 순서로 고정된 흐름을 따릅니다. 아무도 마지막 단계로 바로 뛰어들지 않으며, 진행을 이끄는 증거는 벤치마크가 아니라 자체 코드베이스입니다. 저는 병합 단계가 가장 흥미로운데, 커밋 처리량이 증가하면 충돌 빈도도 올라가고, 이는 전체 시스템의 처리량을 높이는 핵심 요인이기 때문입니다.

가치가 상승하는 역량은 루프 주변에 위치합니다. 에이전트가 여러분의 설명을 문자 그대로 받아들이기 때문에 문제와 제약을 정확히 정의하는 능력이 더욱 중요해집니다. 또한 어떤 증거가 충분히 변화 통과를 허용하는지 결정하는 일도 필요합니다. 이는 예전에는 사람의 머릿속에 있던 습관이었지만 이제는 자동화가 적용할 수 있는 정책으로 문서화해야 합니다. 나머지는 시스템 설계—자동화 작업이 닿을 수 있는 범위를 한정하고, 에이전트가 제어하지 않는 무언가가 결과를 검증하도록 하며, 문제가 발생했을 때 책임을 추적 가능하게 하는 것입니다. 엔지니어는 구현을 만드는 데 쓰는 시간을 줄이고, 무엇이 존재해야 하는지, 그 작동을 증명하기 위해 어떤 근거가 필요한지 결정하는 데 더 많은 시간을 할애하게 될 것입니다.

멋진 인터뷰에 감사드립니다. 더 알고 싶으신 독자분들은 Sonar를 방문해 주세요.