지금까지 코드 품질은 사람이 코드를 읽어서 지켰습니다. 그런데 에이전트가 하루에 수십만 줄을 쏟아내기 시작하면, 읽어서 지키는 방식은 무너집니다. 검사는 코드가 아니라 에이전트를 둘러싼 울타리로 옮겨가는 중입니다.

구글 엔지니어 Addy Osmani가 세 편의 글에 걸쳐 이 변화를 정리했습니다. 핵심 문장은 하나입니다. 이제 소프트웨어 품질은 에이전트 주위에 어떤 제약을 세워두느냐에 달렸다는 것. 여기에 개발자 Fabien Sanglard가 자기 취향을 파일 하나에 새겨 반복 잔소리를 끝낸 사례를 겹치면, 흐름이 손에 잡힙니다.

출처: Agentic Code Quality – Addy Osmani

코드 리뷰가 확장되지 않는다

사람이 코드를 한 줄씩 읽어 검토하는 방식은, 에이전트의 생산량 앞에서 한계에 부딪힙니다. 읽어야 할 코드가 너무 많은 겁니다. 그래서 품질 확인은 코드 자체가 아니라 에이전트를 감싼 하네스와 환경, 운영체제 쪽으로 옮겨갑니다.

Osmani는 이 제약들을 ‘품질 게이트’라고 부릅니다. 단위 테스트와 인수 테스트는 물론, 일부러 버그를 심어 테스트가 잡아내는지 보는 변형 테스트, 복잡도나 아키텍처 규칙을 강제하는 린트 도구가 모두 여기 들어가죠. 에이전트가 무엇을 제안하든, 그 제안이 프로덕션으로 넘어가도 될 만큼 안전하고 정확한지를 이 게이트들이 판정합니다.

그렇다면 코드를 아예 안 읽어도 될까요. Osmani가 인용한 판단 기준은 이렇습니다. 읽기를 건너뛰어도 괜찮은 건 사용자가 없거나 버릴 코드, 프로토타입처럼 위험이 낮은 경우뿐이라는 것. 위험이 올라가면 누군가는 코드를 읽어야 합니다. 매 변경을 당신이 읽지 않는다면, 그 자리는 제약이 대신 읽어야 하죠.

어디에 사람을 남길 것인가

Osmani는 보통 다섯에서 열 개의 에이전트를 동시에 굴린다고 합니다. 여기서 그는 작업을 둘로 나눕니다. 정지 조건과 제약이 분명해 완전히 맡겨도 되는 작업, 그리고 곁에서 지켜보며 직접 리뷰해야 하는 작업.

사람의 판단은 사라지는 게 아니라 자리를 옮깁니다. 무엇을 왜 만들고 시스템을 어떻게 설계하며 품질 기준을 어디에 둘지, 그 결정이 앞단에 사람 몫으로 남는 겁니다. 뒷단에서는 에이전트가 내놓은 증거를 보고 위험을 가늠하며, 무엇을 프로덕션에 내보낼지 사람이 책임집니다. 검사를 아무리 많이 붙여도 그 자체가 품질을 보장하진 않기에, 신호 대 잡음이 좋은 지점을 골라야 하죠.

그가 특히 강조하는 건 ‘자동 방어가 깨지는 지점’입니다. 자동화된 견제가 더는 작동하지 않거나 유지보수의 트레이드오프를 따져야 하는 곳, 바로 거기에 사람의 주의를 몰아주라는 겁니다.

취향을 파일에 새긴다

추상론 옆에는 복사해 쓸 수 있는 실물이 하나 있습니다. Fabien Sanglard의 경험담이죠. 그는 2025년 중반만 해도 컴파일조차 안 되던 LLM 코드가, 2026년에는 까다로운 버그까지 잡아내는 걸 지켜봤습니다. 문제는 품질이었습니다. 주석도 구조도 없는 스파게티 코드가 쏟아졌죠.

세션마다 “매직 넘버 쓰지 마라”, “짧은 함수명을 써라” 같은 지적을 되풀이하던 그는, 이 잔소리를 파일 하나에 모으기로 합니다. 코딩 도구가 세션을 시작할 때 자동으로 읽어들이는 agent.md입니다. 여기에 스타일 규칙을 적어두면, 매번 반복하지 않아도 그 취향이 프롬프트에 실려 들어가죠.

그의 규칙은 짐작이 갑니다. 사람이 읽을 글은 최소한의 단어로, 매직 넘버는 상수로, 조건문엔 이른 반환으로, 버그 수정은 테스트부터. 다만 그도 못을 박습니다. 이건 마법이 아니라고. LLM은 여전히 환각을 일으키니 검증은 남고, 대신 그의 관심이 코드 스타일에서 아키텍처와 설계로 옮겨갔다는 것.