출력 계층의 문제: AI 속도가 품질 게이트(Quality Gates)를 더 중요하게 만드는 이유

에이전트가 코드를 배포하는 속도가 빨라질수록, 슬롭(slop, 저품질 코드)도 더 빠르게 쌓입니다. 해결책이 속도를 늦추는 것이 아닌 이유를 설명합니다.

AI 생산성에 관한 이야기 중에는 다음과 같은 버전이 있습니다. 에이전트가 코드를 작성하고, 인간이 디프(diff, 변경 사항)를 검토하며, 모두가 더 빠르게 배포한다는 것입니다. 깔끔하고, 명확하며, 낙관적인 이야기입니다.

문제는 중간 단계인 "인간이 디프를 검토한다"는 부분이 첫 번째 단계와 같은 속도로 확장되지 않는다는 점입니다. 에이전트의 출력(output)은 압축되었습니다. 하지만 인간의 주의력(attention)은 그렇지 않습니다.

Claude Code나 Cursor를 사용하는 개발자가 과거 일주일이 걸리던 작업을 오후 한때에 생성할 수 있게 되었을 때, 검토 대기열(review queue)이 더 빨리 비워지지는 않습니다. 오히려 더 큰 디프, 더 많은 수정 파일, 한 번에 머릿속에 담아야 할 더 넓은 표면적(surface area)으로 가득 차게 됩니다. 실행 계층(execution layer)은 빨라졌지만, 판단 계층(judgment layer)은 이전과 동일한 크기입니다.

이것을 우리는 출력 계층의 문제(output layer problem)라고 부릅니다. 즉, 코드가 생성되는 속도와 코드를 얼마나 철저하게 평가할 수 있는지 사이의 간극입니다. 그리고 바로 이 지점에서 놀라울 정도로 많은 양의 슬롭(slop)이 조용히 운영 환경(production)으로 유입됩니다.

속도가 붙었을 때 슬롭(slop)이 나타나는 양상

AI가 생성한 코드는 주니어 개발자의 코드가 나쁜 방식과는 다르게 나쁩니다. 보통 5분 안에 잡아낼 수 있는 명백한 논리적 오류나 누락된 예외 케이스(edge cases)를 가지고 있지는 않습니다. 컴파일도 잘 됩니다. 테스트도 통과합니다. 언뜻 보기에는 완벽하게 합리적인 코드처럼 보입니다.

대신, AI 생성 코드는 유지보수를 위해 작성되지 않은 코드 특유의 구조적 특징을 보이는 경향이 있습니다:

• 서사적 주석 (Narrative comments): 코드가 '왜' 그렇게 작동하는지가 아니라, 코드의 각 줄이 '무엇'을 하는지를 설명하는 주석 — 이는 모델이 문서를 작성하는 대신 이야기를 들려주고(narrating) 있었다는 증거입니다.
• 일반적인 명명 (Generic naming): 단일 함수 맥락에서는 말이 되지만, 시간이 지남에 따라 파일 전체의 가독성을 떨어뜨리는 이름 지정.
• 삼켜진 예외 (Swallowed exceptions): 에러 핸들링(error handling)이 임시로 구현(stubbed)된 후 완료되지 않은 경우 — catch 블록은 존재하지만 그 내부에서 아무 일도 일어나지 않습니다.
• TypeScript 전반에 흩어진 as any 및 @ts-ignore: 모델이 제대로 해결하고 싶지 않은 타입 복잡성(type complexity)에 부딪혔을 때 나타나는 현상.
• 남겨진 TODO 스텁 (TODO stubs): 에이전트(agent)가 컨텍스트(context)나 확신이 부족하여 어려운 부분을 미루어 둔 채 남겨둔 자리.

이 중 어느 하나도 개별적으로는 치명적이지 않습니다. 하지만 에이전트들이 대량으로 코드를 작성하는 코드베이스(codebase) 전체에서 이들이 모이면, 진정으로 다루기 어렵고 비용이 많이 드는 무언가로 복합되어 나타납니다. 이는 단일 파일이 고장 났기 때문이 아니라, 작은 품질 결함들이 축적된 무게가 시스템 전체를 변경하기 더 어렵게 만들기 때문입니다.

이것이 바로 '바이브 코딩(vibe coding)'의 낙관론이 간과하는 부분입니다. 소프트웨어를 구축하는 것은 이제 빨라졌습니다. 하지만 소프트웨어를 실행하고, 유지보수하며, 진화시키는 것은 여전히 예전과 같은 작업이며, 입력되는 재료가 구조적으로 일관되지 않을 때 그 작업은 더욱 어려워집니다.

리뷰 병목 현상은 실재하며, 점점 악화되고 있습니다

AI 보조 코딩(AI-assisted coding)을 본격적으로 도입한 팀의 테크 리드(tech lead)라면, 아마 이미 이를 느끼고 있을 것입니다. PR(Pull Request)은 더 커졌습니다. Diff(차이점)는 더 길어졌습니다. 엔지니어들은 더 많은 결과물을 내놓고 있지만, 여러분은 그들이 만들어내는 것을 따라잡기 위해서만이라도 — 실제 신중하게 평가하는 것은 고사하고 — 리뷰에 더 많은 시간을 쓰고 있습니다.

본능적으로는 더 빠르게 리뷰하려 하게 됩니다. 명백한 것들은 훑어보고, 로직에 집중하며, 나머지는 테스트가 잡아낼 것이라고 믿는 식입니다.

문제는 사용되지 않는 export, 과도하게 큰 함수, 사소한 주석, 안전하지 않은 타입 단언 (unsafe type assertions), 삼켜진 예외 (swallowed exceptions)와 같은 aislop 플래그 패턴들이 바로 빠른 리뷰 과정에서 대충 훑고 지나가게 되는 바로 그 요소들이라는 점입니다. 이것들은 버그가 아닙니다. 정확히 말하면 틀린 것도 아닙니다. 그저 정성스럽게 제작된 것이 아니라 생성된 코드에서 남은 구조적 잔여물일 뿐이며, 코드베이스를 작업하기 훨씬 더 어렵게 만들 때까지 조용히 축적됩니다.

AI가 생성한 결과물을 빠르게 리뷰하며 지나가는 방식은 출력 계층 (output layer) 문제를 해결하지 못합니다. 그저 문제를 미루는 것뿐입니다.

품질 게이트 (Quality gate)가 실제로 변화시키는 것

결정론적 품질 게이트 (deterministic quality gate)는 엔지니어링적 판단을 대체하는 것이 아니라, 이를 보호합니다.

aislop이 리뷰에 도달하기 전 PR (Pull Request)을 스캔하면, 기계적인 문제들은 이미 드러나고 점수가 매겨집니다. 리뷰어는 이를 직접 찾아낼 필요가 없습니다. 이미 결과물에 포함되어 있기 때문입니다. 자동 수정 가능한 문제들은 이미 사라진 상태입니다. 인간 리뷰어에게 남는 것은 실제로 인간이 필요한 영역, 즉 아키텍처 결정, 비즈니스 로직, 그리고 시스템이 왜 그렇게 작동하는지 알아야만 이해할 수 있는 트레이드오프 (tradeoffs)입니다.

이것이 바로 AI 보조 코딩 (AI-assisted coding)을 대규모로 실제로 작동하게 만드는 분업 방식입니다. 에이전트 (Agents)는 실행을 담당합니다. 결정론적 도구 (Deterministic tooling)는 구조적 품질 검사를 담당합니다. 인간은 컨텍스트가 없는 도구들이 내릴 수 없는 판단 (judgment calls)을 담당합니다.

중간 계층이 없다면, 리뷰어가 기계의 업무(400줄짜리 diff에서 as any나 TODO 스텁을 확인하는 일)를 대신하거나, 혹은 업무를 수행하지 않는(겉보기에는 괜찮아 보이지만 조용히 코드베이스를 저하시키는 PR을 승인하는 일) 상황에 직면하게 됩니다. 에이전트의 출력량이 증가함에 따라 두 가지 옵션 모두 지속 가능하지 않습니다.

아무도 말하지 않는 복합적인 문제

여기에는 직접적으로 언급할 가치가 있는 2차 효과 (second-order effect)가 있습니다.

에이전트(Agents)는 단순히 새로운 코드를 작성하는 것에 그치지 않습니다. 그들은 생성할 내용의 맥락을 이해하기 위해 기존 코드베이스(codebase)를 읽습니다. 만약 코드베이스에 구조적 슬롭(structural slop) — 일관성 없는 명명 규칙, 주석 처리된 데드 코드(dead code), 의도를 나타내지 못하는 일반적인 변수명 등 — 이 쌓여 있다면, 에이전트는 이를 무엇이 허용 가능한지에 대한 학습 신호(training signal)로 사용합니다.

다시 말해, 슬롭(Slop)은 에이전트에게 더 많은 슬롭을 생산하도록 가르칩니다. 품질 게이트(quality gate)를 통해 유지 관리된 코드베이스는 그렇지 않은 코드베이스보다 실질적으로 더 나은 에이전트 결과물을 만들어냅니다. 에이전트가 학습할 수 있는 더 나은 패턴이 존재하고, 에이전트를 혼란스럽게 할 모호한 사례가 더 적기 때문입니다.

이것이 슬롭을 조기에 잡아내야 한다는 복리(compounding)의 논거입니다. 이는 단지 현재의 PR(Pull Request)에 관한 문제가 아닙니다. 그 이후에 오는 모든 PR의 품질 하한선(quality floor)에 관한 문제입니다.

"좋은 코드"가 무엇인지 명문화하기

이 글에 영감을 준 기사 — Braze의 Jon Hyman과 Stack Overflow의 Jody Bailey가 출연한 Leaders of Code 팟캐스트의 내용 — 는 향후 몇 년간 가장 중대한 엔지니어링 과제 중 하나가 숙련된 엔지니어의 지식을 그들의 머릿속에서 꺼내 에이전트가 사용할 수 있는 형태로 만드는 것이 될 것이라는 점을 지적합니다.

이는 아키텍처 결정(architectural decisions)과 비즈니스 맥락(business context)에도 해당됩니다. 코드 품질 표준(code quality standards)에도 마찬가지입니다.

현재 대부분의 팀이 수용 가능한 코드에 대해 느끼는 기준은 시니어 엔지니어의 머릿속과 코드 리뷰(code review)의 비공식적인 피드백 루프 속에 존재합니다. 에이전트가 이러한 표준을 위반할 때, 리뷰어가 주의를 기울이고, 서두르지 않으며, 차이점(diff)이 주의 깊게 분석하기에 너무 크지 않다면 리뷰어가 이를 잡아낼 수 있습니다.

품질 게이트는 해당 표준을 외재화(externalises)합니다. 이는 특정 리뷰 사이클의 리뷰어의 주의력에 의존하지 않고도 기준을 명시적이고, 일관되며, 강제할 수 있게 만듭니다. 이것은 시니어 엔지니어의 판단을 대체하는 것이 아닙니다. 그 판단을 지속 가능하고 확장 가능하게 만드는 방법이며, 에이전트의 결과물이 증가함에 따라 정확히 일어나야 하는 일입니다.

이를 어떻게 활용할 것인가

만약 여러분이 Claude Code, Codex, Cursor 또는 기타 다른 AI 코딩 어시스턴트 (AI coding assistant)를 유의미한 규모로 사용하는 팀을 운영하고 있다면, 나중이 아닌 지금 바로 실행해야 할 세 가지 작업이 있습니다.

기준 점수 (Baseline score)를 설정하세요. 현재 코드베이스에서 npx aislop scan을 실행하십시오. 결과로 나오는 모든 것이 여러분의 현재 기준 점수, 즉 팀이 그동안 작업해 온 방식에서 누적된 구조적 부채 (structural debt)입니다. 측정하지 않은 것은 개선할 수 없습니다.

기준점뿐만 아니라 새로운 추가 사항에 대해서도 게이트 (Gate)를 설정하세요. CI 게이트 (CI gate)의 가치는 모든 것을 한꺼번에 고치는 데 있는 것이 아닙니다. 기존 부채를 점진적으로 해결하는 동안 새로운 슬롭 (slop, 부실한 코드)이 쌓이는 것을 방지하는 데 있습니다. 임계값 (threshold)을 설정하고, 설정을 커밋하며, 그 기준 미달인 머지 (merge)를 차단하십시오. 새로운 에이전트 (agent)의 출력물은 리뷰 (review) 단계에 도달하기 전에 검사됩니다.

실패한 결과물을 에이전트에게 다시 전달하세요. aislop이 자동 수정이 불가능한 문제를 발견하면, npx aislop fix --claude 명령어를 통해 해당 문제를 코드를 작성한 에이전트에게 직접 보내 두 번째 패스 (second pass)를 수행하게 합니다. 이는 리뷰어의 업무를 늘리는 것이 아니라, 사람이 확인하기 전에 루프 (loop)를 닫는 작업입니다.

실행 계층 (execution layer)은 극적으로 빨라졌습니다. 하지만 판단 계층 (judgment layer)은 여전히 인간의 규모에 머물러 있습니다. 품질 게이트 (quality gate)는 이 두 계층이 나중에 수정하기에 비용이 많이 드는 방식으로 괴리되지 않도록 유지해 주는 역할을 합니다.

aislop은 AI가 생성한 코드의 점수를 매기기 위한 무료 오픈 소스 CLI입니다. 1초 미만의 실행 속도를 자랑하며, 결정론적 (deterministic)이고, 시작하는 데 별도의 설정이 필요하지 않습니다. 리포지토리에서 실행하기 →, Github →