AI 코딩 에이전트가 매번 신입사원처럼 시작하는 이유와 Sonar Vortex의 해법

Killian Carlsen-Phelan은 자신을 독립적인 코드 검증 플랫폼 Sonar 소속이라고 소개했다. 그는 이번 발표가 에이전트형 코딩 루프 안으로 검증을 옮기는 데 초점을 맞춘다고 말했다.

Carlsen-Phelan은 지난 두어 해 동안 모두가 에이전트형 코딩 도구를 써 왔고, 이것이 개발 속도를 높였다고 말했다. 그러나 IDE에서 새 에이전트 세션이 시작될 때마다 에이전트는 신입사원처럼 처음부터 시작한다. 프로젝트의 기존 관례, 코딩 가이드라인, 미리 정의된 아키텍처 규칙을 알지 못한다.

그는 기능 구현을 맡기면 이것이 문제가 된다고 말했다. 예를 들어 새 API 엔드포인트를 만들라고 하면, 에이전트는 기존 엔드포인트가 어떻게 동작하는지 코드를 검색해 알아내야 한다. 그는 이 과정을 주사위 굴리기에 비유했다. 맥락을 빨리 모을 수도 있고, 저장소 전체를 뒤져야 할 수도 있으며, 후자는 시간과 토큰을 소모한다. 그는 이것이 해결 가능한 문제라고 말했다.

Carlsen-Phelan은 모든 코드베이스에는 문제가 있다고 말했다. 에이전트가 그 문제를 복제하고 기존 패턴을 되풀이할 가능성이 매우 높다는 것이다. 또한 에이전트가 새 문제를 만들어 내고 그것이 잡히지 않으면, 코드 품질을 유지하는 것은 사실상 불가능하다고 덧붙였다.

Carlsen-Phelan은 Sonar Vortex를 Sonar의 해법으로 제시했다. 그는 이를 사용 중인 어떤 코딩 에이전트에도 연결되는 플러그인으로 설명했다. 에이전트가 코딩을 시작하기 전에 프로젝트를 알게 해 준다는 것이다. 또 에이전트가 스스로를 결정론적으로 검증해 코드베이스에 새 문제를 넣지 않도록 할 수 있다고 말했다.

그는 녹화된 사례를 소개했다. 코딩 에이전트가 2분도 안 되어 작은 기능을 작성했다. 발표자는 에이전트에게 자신을 위한 테스트 스위트를 만들라고 지시했지만, 에이전트는 Vortex가 잡아낸 보안 문제를 도입했고, 그 문제가 해결될 때까지 에이전트는 반복 수정해야 했다. 문제는 로그 파일을 임시 파일로 압축 해제하면서 그 임시 파일의 권한을 명시적으로 설정하지 않은 것이었다. 그는 이런 유형의 문제는 테스트를 작성하기도, 찾아내기도 어렵고, 시니어 리뷰어조차 명시적으로 찾으려 하지 않으면 놓칠 것이라고 말했다.

Carlsen-Phelan은 이 과정에서 느끼는 답답함이 Sonar가 수집한 데이터로 뒷받침된다고 말했다. 그에 따르면 Sonar는 개발자 1,100명 이상을 조사했고, 96%가 AI가 생성한 코드를 완전히 신뢰하지 않는다는 결과를 얻었다. 그중 48%는 푸시하기 전에 코드를 완전히 검증한다고 답했다.

그는 이것이 우려스럽다고 말했다. 검증되지 않은 코드가 프로덕션으로 나가는 상황이라는 것이다.

Carlsen-Phelan은 에이전트는 코드를 빨리 쓰지만, 재작업이 팀을 늦춘다고 말했다. 풀 리퀘스트 단계에서야 문제를 잡으면 이미 일정이 뒤처진 상태가 된다는 것이다. 그는 이를 애니메이션으로 설명했다. 공처럼 표시된 에이전트가 격자 위를 움직이는데, 각 칸이 파일이고 에이전트는 움직일 때마다 새 파일을 확인한다. 하단의 막대는 검색에 쓰인 토큰, 즉 돈과 시간을 나타낸다.

그는 에이전트가 무언가를 잘못하면 팀은 풀 리퀘스트에서야 그것을 알게 된다고 말했다. 리뷰는 실패하고, 작업은 다시 에이전트에게 돌아가며, 엔지니어는 계속 대응해야 한다는 것이다.

Carlsen-Phelan은 Vortex를 쓰면 에이전트가 무언가를 쓰기 전에 프로젝트의 코딩 가이드라인과 코드가 어떻게 연결되는지 보여주는 지도를 얻는다고 말했다. 여기에는 아키텍처 가이드라인, 애플리케이션에서 승인된 라이브러리, 특정 프로젝트의 코딩 표준이 포함된다.

그는 개발자가 이러한 관례와 규칙을 설정하며, 이 정보가 있으면 에이전트가 토큰과 맥락을 낭비하지 않고 관련 파일로 곧장 간다고 말했다.

Carlsen-Phelan은 에이전트가 작업하는 동안 SonarQube가 그 코드를 검사한다고 말했다. 에이전트가 자신의 도구로 하는 편집마다 빠른 검사가 실행된다. 에이전트가 턴을 끝내기 전에는 보안 문제와 파일 간 데이터 흐름을 보는 더 깊은 검사를 실행하도록 되어 있다. 문제가 발견되면 에이전트에게 돌아가고, 에이전트가 코드를 고치면 Vortex가 다시 검사한다.

그는 이것이 Claude Code, Codex, Antigravity 등 현재 사람들이 쓰는 에이전트와 함께 작동한다고 말했다. 자체 에이전트, 오픈소스 에이전트, 덜 알려진 도구를 쓰는 경우에는 Sonar가 설정 가능한 MCP 클라이언트를 제공한다고 덧붙였다.

Carlsen-Phelan은 핵심은 Vortex를 에이전트에 쉽게 연결할 수 있다는 점이라고 말했다. Sonar가 제공하는 CLI와 MCP 도구를 기반으로 만들어졌으며, SonarQube를 에이전트 안으로 끌어와 에이전트가 쓰기 전에 프로젝트를 알게 한다는 것이다.

그는 Sonar의 수치를 인용했다. Vortex는 평균 36% 적은 토큰을 쓰며, 특히 기존 코드베이스 리팩터링 같은 작업에서 줄어드는 폭이 두드러진다. Sonar에 따르면 이를 사용하는 사람들은 프로덕션 장애가 44% 줄었다. 또 이 도구는 오탐률이 매우 낮아 코딩 세션을 어지럽히지 않는다고 말했다.

Carlsen-Phelan은 목표가 에이전트를 안내하고 그 변경을 검증하면서, SonarQube의 기존 분석을 이 과정에 가져오는 것이라고 말했다. 그는 SonarQube가 거의 20년 동안 존재해 왔으며, 많은 팀이 보안, 유지보수성, 데이터 흐름 문제를 결정론적으로 분석하기 위해 돌리는 파이프라인 단계라고 설명했다. 그래프를 구축하고 코드를 깊이 분석한다는 것이다.

그는 이 지식이 Sonar 서버에서 유지되며, 이제는 처음부터 맥락으로 에이전트에게 제공될 수 있다고 말했다. CI 파이프라인에는 이미 SonarQube 스캔이 돌아가고 있고, Vortex는 그 스캔이 학습한 내용을 재사용하므로 한 파일에 대한 검사도 나머지 코드를 함께 고려한다고 덧붙였다.

Carlsen-Phelan은 전날 밤 녹화해 둔 작업을 보여주었다. 그는 아무 조작 없이 세션에서 SonarQube가 시작되었고, CLI와 훅 시스템이 감지되었으며, 비밀 정보 탐지가 켜져 있었다고 말했다. 그는 이에 대해 자세히 다루지는 않겠다고 하면서도, 비밀 정보 유출은 막기 가장 쉽고 동시에 비용이 가장 큰 문제 중 하나이며, 이 플러그인은 GitHub와 에이전트 컨텍스트 메모리로의 비밀 정보 유출을 막는다고 말했다.

그는 프롬프트에 Sonar 지침을 붙여 넣지 않았으며 이 지침은 자동으로 로드되었다고 말했다. 작업은 로그 파일을 임시 파일로 압축 해제하고, 같은 파일을 계속 재사용하도록 하며, 재사용됨을 증명하는 테스트를 작성하라는 것이었다.

Carlsen-Phelan은 한 줄의 코드를 쓰기 전에 에이전트가 Sonar에 두 가지를 묻는다고 말했다. 이 클래스가 어디에 있는가, 그리고 이 프로젝트의 Java 코딩 가이드라인은 무엇인가. 답은 Sonar 맥락 탐색을 통해 온다고 했다. 에이전트는 작업하도록 요청받은 단일 GC 로그 파일 주변의 상위 및 하위 아키텍처, 기존 패턴, 가이드라인을 받는다는 것이다.

그는 Sonar가 기본적으로 Java 프로젝트의 기본 가이드라인을 강제하며, 고객의 요구사항도 처음부터 주입할 수 있다고 말했다. 또 모델 선택을 제외하면, 에이전트가 시작할 때 받는 맥락과 조종 정보가 에이전트 성능을 좌우하는 가장 큰 지렛대이며, 앞단에서 더 많이 작업할수록 나중의 재작업과 수정이 줄어든다고 강조했다.

Carlsen-Phelan은 애니메이션처럼 파일을 하나씩 뒤지는 대신, 에이전트가 그냥 지도를 받는다고 말했다. 그는 이것을 Vortex가 수행하는 가이드 단계라고 설명했다. 에이전트는 기존 테스트를 살펴보고 어떻게 작동하는지 알 수 있으며, 빠르게 구현 단계로 넘어갈 수 있다는 것이다.

그는 작업이 몇 초밖에 걸리지 않았지만 기능에 따라 다를 수 있다고 말했다. Vortex 없이 같은 기능을 실행하면 에이전트가 grep으로 주변을 뒤지며 상황을 파악해야 하므로 더 오래 걸린다고 말했다.

Carlsen-Phelan은 에이전트가 구현을 실행하며 자신의 테스트 스위트 안에 임시 파일을 만들었다고 말했다. 그는 화면에서 그 임시 파일을 짚었다. 이후 에이전트는 자신의 테스트 결과를 확인하고, 변경된 두 파일 모두에 Sonar 검사를 실행했으며, 테스트 결과를 확인하는 메시지와 Vortex 분석이 나타났다.

그는 파일을 편집하거나 추가할 때마다 Vortex 분석이 실행되며, 사용자가 이를 강제할 필요가 없다고 말했다. 이것이 팀이 자동화된 워크플로에 더해야 할 신뢰의 층이며, 문제가 새로 들어오지 않도록 보장한다고 설명했다. 그는 이것이 AI가 AI를 검사하는 것이 아니라고도 주장했다. AI가 AI를 검사하는 것은 문제가 들어오지 않도록 하는 가장 신뢰하기 어려운 방법 중 하나라는 것이다. 에이전트는 자신이 만든 코드와 리뷰를 비스듬히 생각할 수 있고, 다른 AI 에이전트는 기존 코드를 리뷰할 때 놓치거나 환각을 일으킬 가능성이 크다고 말했다. 결정론적 계층은 같은 코드에 분석을 돌릴 때마다 같은 결과를 내므로, 이것이 지침을 신뢰할 수 있고, 통제 가능하며, 규정을 준수하게 만든다고 말했다. 그는 Sonar가 Guitar라는 AI 리뷰 도구도 제공하지만, 이번 발표에서는 다루지 않는다고 덧붙였다.

Carlsen-Phelan은 Vortex 분석이 실행되자 여섯 개의 지적 사항을 잡아냈다고 말했다. 에이전트는 그중 두 개는 방금 쓴 줄에 있고, 네 개는 기존 코드에 있다고 말했다.

그는 Vortex가 시끄럽게 굴도록 설계되지 않았으며, 팀이 한 문제를 찾았는데 세 가지를 더 고쳐야 한다고 말하는 식이 아니라고 설명했다. 새 코드에 대해서는 수정을 강제하고, 기존 문제에 대해서는 인지할 수 있도록 드러내어, 팀이 원하면 나중에 고칠 수 있게 한다는 것이다.

Carlsen-Phelan은 지적 사항 중 하나가 앞서 언급한 보안 문제였다고 말했다. 에이전트는 로그를 기본 임시 폴더에 넣으면서 누가 읽을 수 있는지 지정하지 않았고, 많은 서버에서 그 폴더는 공유된다. 이후 에이전트가 수정을 했다.

Vortex가 다시 실행되자, 임시 파일이 여전히 공유 디렉터리에 있으므로 문제가 실제로 해결되지 않았다고 판단했다. 그는 첫 번째 수정은 Java 기본값에 의존했지만, Mac과 Linux에서는 기본값이 이미 소유자만 접근할 수 있다고 설명했다. 그러나 Sonar가 설정한 규칙은 권한을 명시적으로 설정할 것을 요구한다는 것이다. 그는 Sonar는 보안이나 품질을 타협하지 않는다고 말했다.

Carlsen-Phelan은 에이전트가 마침내 수정을 구현할 수 있었고, 실행될 때마다 Vortex 분석이 다시 시작되었다고 말했다. 그는 팀이 풀 리퀘스트에 문제가 들어오는 것을 원하지 않는다고 말했다. 초기에 문제를 잡을수록 문제의 범위가 작아지고, 수정에 드는 시간, 돈, 에너지가 줄어든다는 것이다.

그는 터미널 세션을 이렇게 요약했다. 에이전트가 먼저 Sonar에 물었고, Sonar가 문제를 표시하면 에이전트가 이를 고치고 자신의 코드를 계속 보완했다. 마지막에는 깊은 데이터 흐름 분석이 수행된다. 그는 혜택으로 왕복 리뷰 감소, 즉시 이루어지는 수정, 더 안전한 코드, 수정에 쓰는 시간과 돈 감소, 자동화된 에이전트 워크플로를 신뢰할 수 있어 개발자가 더 많은 시간을 확보하는 것을 꼽았다. 그리고 질문은 아래층 Sonar 부스에서 받겠다고 말하며 마쳤다.