알리레자 아들타바타바이, Gitar의 창립자 및 CEO – 인터뷰 시리즈

Ali-Reza Adl-Tabatabai는 Gitar의 창립자 겸 CEO로, Uber, Google (GOOGL ), Facebook (META ), Intel (INTC ), AMD, IBM 등에서 경력을 쌓은 베테랑 엔지니어링 리더입니다. 2023년 Gitar 설립 전에는 Uber의 시니어 엔지니어링 디렉터였고, 그 전에는 Google에서 대규모 사이트 신뢰성 엔지니어링을 이끌었습니다.

그의 경력 초기, 그는 인텔 랩과 페이스북의 HipHop VM 팀에서 컴파일러 기술, 가상 머신, 병렬 컴퓨팅 시스템, 하드웨어 최적화에 대해 작업했으며, 스탠퍼드 대학교에서 고급 컴파일러 설계를 가르쳤습니다. 그의 장기간의 프로그래밍 언어, 인프라스트럭처 신뢰성, 개발자 툴링, 대규모 시스템 아키텍처 배경은 그를 AI 기반 소프트웨어 엔지니어링 랜드스케이프의 진화에서 중요한 인물로 만들었습니다.

Gitar는 AI 지원 개발이 낳은 문제, 즉 기업 시스템으로 유입되는 방대한 기계 생성 코드의 검증과 보안에 집중합니다. AI 에이전트가 코드 리뷰, CI/CD 실패 조사, 버그와 취약점 식별, 수정 제안을 자동화하고 GitHub, GitLab, Jenkins, Jira, Slack 등 기존 워크플로에 직접 통합됩니다. 회사는 코드 생성 경쟁보다 신뢰성과 보안을 유지하는 에이전트형 품질 게이트에 초점을 둡니다.

우버, 구글, 인텔 랩스에서 엔지니어링을 이끌었으며, 대규모 개발자 플랫폼 및 인프라스트럭처를 작업했습니다. 그 경험이 어떻게 Gitar를 설립하게 했는지, 코드 생성 대신 코드 유효성 검사를 중점으로 하는 이유는 무엇입니까?

우버, 구글, 페이스북, 인텔 랩스에서 개발자 플랫폼을 다양한 규모로 작업했으며, 동일한 교훈이 반복되었습니다. 개발자 경험은 경쟁 우위입니다. 훌륭한 도구는 최고의 엔지니어를 끌어들이고 유지하며 회사가 빠르게 움직일 수 있도록 합니다. 개발자는 빠르고, 노이즈가 없는 도구를 원하며, 그들이 흐름을 유지하고 노동을 자동화할 수 있도록 합니다. 그러나 개발자 툴링은 깊게 단편화되어 있으며, 대부분의 회사는 일관된 경험을 함께 조립하기 위해 엄청난 엔지니어링 자원을 소모합니다. 저는 직접 그것을 해결하는 데 많은 레버리지가 있다는 것을 보았습니다.

AI는 방정식을 변경합니다. 개발자 워크플로우의 더 많은 부분을 자동화할 수 있게 됩니다. 코드 생성은 이미 잘 다루어졌지만, 그것은 병목을 다운스트림으로 이동시켰습니다. 즉, 유효성 검사, 리팩토링, 유지 관리를 위한 코드를 생산하는 것입니다. 그것이 Gitar가 집중하는 부분입니다. AI가 더 많은 코드를 작성할수록, 생성이 아닌 신뢰성, 정확성, 유지 관리가 귀중한 자원이 됩니다. 코드 유효성 검사는 AI 생성 코드가 실제로 안전하게 프로덕션에 도달하는지 결정하는 워크플로우의 부분입니다.

AI 생성 코드의 부상으로, 많은 팀은 현재 코드 과부하를 처리하고 있습니다. 이 문제는 오늘날 기업 내에서 얼마나 중요한가요? 팀은 어디에서 가장 어려움을 겪고 있나요?

변화는 코드를 작성하는 것이 아닙니다. 이미 팀이 흡수할 수 있는 속도보다 빠르게 진행되고 있습니다. 무엇이 바뀐 것은 모든 후속 작업입니다. AI 도구는 끊임없이 풀 리퀘스트를 생성하며, 팀이 검토할 수 있는 속도보다 빠르게 생성됩니다. 이것은 시스템의 일부가 설계된 출력 수준에 대처하지 못하게 만듭니다.

모든 변경은 여전히 검증을 통과해야 합니다. 코드 리뷰, CI, 보안 검사와 승인은 AI가 코드를 더 빨리 만든다고 사라지지 않습니다. 관리 가능한 흐름이던 것이 백로그로 바뀌고, 팀은 아이디어가 아니라 신뢰성에서 막히게 됩니다.

현재 마찰은 생성이 아니라 위험을 들이지 않고 코드를 마무리하는 과정에 있습니다.

산업은 주로 코드 생성을 더 빠르게 하는 데 초점을 맞추었습니다. 유효성 검사가 무시된 이유는 무엇이며, 왜 지금 더 중요해지고 있나요?

코드 생성 이후의 시스템이 같은 속도로 진화하지 않았기 때문입니다. 출력이 늘면 풀 리퀘스트가 커지고 잦아지며 CI 실패가 쌓이고, 모든 변경을 깊게 볼 시간이 없어 리뷰 주기가 압축됩니다.

엔지니어가 품질에 무관심해서가 아니라 물량이 타협을 강요하기 때문에 품질이 떨어집니다. 플랫폼 팀은 파이프라인과 실패 분류를 떠안고, 시니어 엔지니어는 로그를 모아 진단하고 안전한 병합을 결정하는 조정자가 됩니다.

팀은 어느 쪽도 만족스럽지 않은 선택에 놓입니다. 빨리 통과시킨 뒤 회귀를 처리하거나, 품질을 지키기 위해 속도 저하를 받아들여야 합니다. 이 긴장이 지금 여러 엔지니어링 조직에서 나타납니다.

Gitar는 코드 검토, 테스트, CI 워크플로우를 처리하기 위해 AI 에이전트를 사용합니다. 이러한 에이전트는 전통적인 정적 분석 도구 및 규칙 기반 파이프라인과 어떻게 근본적으로 다르나요?

차이는 미세하지 않습니다. 실제 에이전트는 단순히 프롬프트에 반응하는 것보다 더 많은 것을 수행해야 합니다. 멀티스텝 작업을 처리하고, 계획하고, 도구를 사용하고, 컨텍스트를 유지하며, 작업을 앞으로 이동시킬 수 있어야 합니다.

대부분의 시스템은 이 기준에 미치지 못합니다. 출력을 만들지만 실행을 관리하지 못하며, 실제 워크플로에 넣으면 격차가 드러납니다. 복잡성을 줄이기보다 관리해야 할 또 하나의 계층을 추가하는 경우가 많습니다.

그래서 대화의 초점은 “에이전트가 있는가”에서 “어떤 일을 실제로 신뢰성 있게 맡길 수 있는가”로 이동하고 있습니다.

신뢰는 소프트웨어 개발에서 자동화의 주요 장벽입니다. Gitar는 어떻게 유효성 검사 프로세스가 팀이 의존할 수 있을 만큼 신뢰할 수 있는지 보장합니까?

작업을 작은 단계로 나눕니다. 명확한 경계를 정의합니다. 출력을 지속적으로 유효성 검사합니다. 위험이 있는 결정에서 인간을 참여시킵니다.

에이전트는 코드 리뷰를 통해 규모가 커질수록 놓치기 쉬운 문제를 드러내고, CI 실패를 분석해 관련 오류를 묶고 유력한 근본 원인을 제시합니다. 수정안을 제안하거나 통제된 방식으로 적용할 수도 있습니다.

이로써 엔지니어의 수동 분류 작업이 줄어듭니다. 사람을 루프에서 제거하는 것이 아니라 시간을 쓰는 위치를 바꾸며, 대부분의 시스템은 완전 자율이 아닌 체크포인트와 함께 작동합니다.

플랫폼을 사용하면 팀이 자신의 에이전트를 만들 수 있습니다. 기업의 채택을 위한 사용자 지정은 얼마나 중요합니까? 가장 흥미로운 사용 사례는 무엇입니까?

사용자 지정은 기업의 채택에 필수적입니다. 모든 플랫폼 팀은 CI를 자신의 회사에 특정 요구 사항에 맞게 맞춤 설정하기 위해 상당한 자원을 투자합니다. 이것은 전통적으로 맞춤 설정, 구성, 툴 통합, 로그 처리, 덕트 테이프와 같은 것을 필요로 합니다. Gitar는 이 작업을 축소합니다. 플랫폼 팀은 자연어 프롬프트를 사용하여 맞춤 설정 검사를 작성할 수 있으며, 이는 전통적인 프로그램 분석으로는 어려운 또는 불가능한 것을 유효성 검사할 수 있도록 합니다.

Gitar는 이 작업을 압축합니다. 플랫폼 팀은 자연어 프롬프트로 사용자 지정 검사를 작성해 번역이 모호한 UI 문자열이나 AGENTS.md 업데이트처럼 기존 분석으로 어려운 항목을 검증할 수 있습니다. PR과 Jira 연결, 미해결 리뷰 티켓 생성, 불안정 테스트 재실행, 요약에 작업 목록 추가도 자동화할 수 있습니다.

가장 흥미로운 사례는 우리가 예상하지 못한 것들입니다. 각 팀은 자신의 코드베이스와 문제를 가장 잘 알고 있으므로, “CI가 X를 확인해 주면 좋겠다”는 요구를 짧은 프롬프트로 만들 수 있게 하면 기본 제품으로는 생각하지 못한 작업까지 즉시 자동화합니다.

현대 엔지니어링 팀은 깃허브, 깃랩, 지라와 같은 복잡한 툴 스택에 의존합니다. 기존 워크플로우에 통합하는 것이 중요합니까?

채택은 개발자가 이미 일하는 곳에서 이루어져야 합니다. 새 화면이나 대시보드, 더 많은 도구 전환은 원하지 않습니다. 기존 흐름을 더 빠르고 조용하게 만들어야 하므로 GitHub, GitLab (GTLB ), Jira 등과의 깊은 통합이 전략 그 자체입니다.

하지만 목표는 통합을 넘어섭니다. PR 리뷰, 티켓 연결, 후속 작업, 불안정 테스트 재시도 등 도구 사이의 워크플로를 백그라운드에서 자율적으로 처리합니다. 에이전트가 리뷰 피드백과 CI 실패를 직접 수정하고, 팀 정책을 만족하는 변경의 승인과 병합까지 맡게 됩니다.

최종 상태는 개발자가 로그인하는 새 도구가 아니라 기존 도구가 스스로 더 많은 일을 하여, 개발자가 판단이 필요한 업무에 집중하는 것입니다.

사람의 코드 리뷰가 결국 예외가 될 수 있다고 했습니다. 조직이 이 전환을 신뢰하려면 무엇이 필요합니까?

신뢰는 한 번에가 아니라 단계적으로 쌓입니다. 조직은 자신의 코드에서 AI가 실제로 중요한 버그와 취약점을 찾아내고 사용자 정의 규칙을 정확하고 폭넓게 시행하는지 확인해야 합니다. 이후 자율 병합까지는 신뢰가 높아지는 네 단계로 진행됩니다.

첫 단계는 탐지입니다. 에이전트가 오탐률을 낮게 유지하면서 실제 문제를 찾는다는 확신이 생기면, 중요 문제를 발견한 PR을 자동으로 차단하게 합니다.

두 번째는 수정입니다. AI가 문제를 표시하는 데 그치지 않고 고쳐서 PR 차단을 풀고 사람 개입 없이 CI를 통과시킵니다. 다른 것을 깨뜨리지 않고 정확하게 해결할 수 있어야 합니다.

세 번째는 승인입니다. 에이전트가 안정적으로 PR을 통과시키는 것을 확인하면 조직이 정의한 규칙 아래 AI가 승인하도록 합니다. 자동 승인 조건을 명시적으로 통제할 수 있어야 안전합니다.

네 번째는 병합입니다. 팀이 허용한 조건 아래 AI가 변경을 반영합니다. 병합 충돌을 정확히 해결하고 회귀나 main 브랜치 손상을 일으키지 않아야 합니다. AI 생성 코드가 늘수록 충돌 빈도도 증가하므로 이 기준은 특히 중요합니다.

AI를 기본 리뷰어로 전환하는 것은 한 번의 믿음이 아니라, 증거가 쌓일 때마다 한 계단씩 오르는 과정입니다.

AI가 코딩 과정의 더 많은 부분을 맡을수록 향후 몇 년간 시니어 엔지니어의 역할은 어떻게 바뀔까요?

시니어 엔지니어는 이미 로그를 결합하고 문제를 진단하며 무엇을 안전하게 병합할지 결정하는 조정 역할로 이동하고 있습니다. 원래 계획된 역할이 아니라 시스템이 부하를 견디지 못해 생긴 대응입니다.

에이전트가 반복 검증을 맡을수록 엔지니어는 루프에 남되 더 높은 수준으로 이동합니다. 수동 분류 대신 무엇을 왜 출시할지 결정하는 데 더 많은 시간을 씁니다.

Gitar는 최근 플랫폼 확장을 위해 900만 달러를 조달했습니다. 자본의 우선순위와 향후 12~18개월의 성공 기준은 무엇입니까?

자본은 두 가지 우선순위를 위해 사용됩니다. 첫 번째는 시장 진출입니다. 우리는 기업으로의 움직임을 확대하고 개발자 인식을 높이기 위해 투자합니다. 두 번째는 제품입니다. 우리는 완전히 자율적인 코드 유효성 검사 및 품질을 위한 우리의 비전을 구축하기 위해 계속해서 작업합니다.

향후 12~18개월의 성공은 의미 있는 기업 고객들이 코드베이스 전체에서 Gitar를 실행하고, 개발자 커뮤니티가 AI 기반 코드 검증의 기본 선택으로 인식하며, 에이전트가 시간이 지날수록 리뷰·수정·병합을 더 많이 자동화하는 것입니다. 검증이 병목이 아니라 AI 개발을 안전하게 확장하는 장치가 되어야 합니다.

인터뷰에 감사드립니다. 더 많은 정보를 원하는 독자는 Gitar를 방문하십시오.