AI VIDEO BRIEFING
AI 코딩 슬롭 대응 전략: 코드 리뷰 없이도 무너지지 않는 팀의 엔지니어링 규칙 정리
AI 에이전트가 쏟아내는 '슬롭' 코드를 또 다른 에이전트로 검증한다. 코드 리뷰를 없앤 팀이 설계 문서와 불변 규칙, 실행 추적만으로 프로그래밍 언어를 3년간 만들어 온 방법을 정리했다.

핵심 메시지
쉽게 이해하기
Boundary의 바이바브 굽타는 AI Engineer 무대에서 자기 팀의 엔지니어링 방식을 이렇게 소개했다. 코드 리뷰가 없고, 모두가 여러 작업을 동시에 진행하며, 어떤 AI 도구를 쓸지에 대한 표준도 없다는 것이다. 그런데 이 팀이 3년째 만들고 있는 결과물은 '한 번도 틀리면 안 되는' 프로그래밍 언어다. 그는 슬롭(대충 만들어진 산출물)을 이기려면 슬롭이 되어야 한다는 역설적인 전략을 택했다고 설명한다.
표준을 강요하는 대신 그들이 택한 것은 '불변 규칙'이다. 특정 도구에 종속된 설정 파일 대신 어떤 모델이든 이해할 수 있는 작은 아키텍처 문서를 두고, 여기에는 몇 달·몇 년이 지나도 바뀌지 않을 컴파일러 계층 구조만 적는다. 대신 글은 엄격하게 관리한다. 설계 문서 전용 도구를 만들고 문서가 갱신될 때마다 사내 채널에 알림이 뜨게 하자, 새벽 2시에 올라온 문서를 곧바로 읽는 사람이 생길 만큼 문서가 팀의 중심이 됐다.
문서가 늘어나면서 발표자 자신이 하루에 열 건씩 설계 문서를 쏟아내는 문제가 생기자, 문서를 올리려면 실제로 읽어 줄 사람을 확보해야 한다는 규칙을 추가했다. 아키텍처도 같은 방식으로 지킨다. 의존성 그래프를 시각화하고 특정 규칙이 깨지지 않는지 검사하는 CLI 도구를 CI에 붙여 두면, 에이전트가 새 패키지를 추가하며 경계를 무너뜨릴 때 커밋 이력에서 바로 드러난다.
핵심은 검증 자체를 자동화한 부분이다. 이 팀은 에이전트가 자사 언어 BAML로 프로그램을 계속 만들게 하고, 그 과정의 대화 기록과 도구 호출 내역을 다른 에이전트가 검사하게 한다. 무엇이 틀렸는지뿐 아니라 '한 번이면 될 일을 세 번 호출했다' 같은 비효율까지 찾아내고, 사람은 그중 진짜 문제와 환각을 가려낸다. 나아가 언어 기능 후보를 실제로 비교해 도구 호출이 적고 오류가 덜 나는 쪽을 고르는 식으로, 코드를 직접 짜지 않고도 데이터에 기반한 판단을 내린다.
그럼에도 그는 '전투는 이겨도 전쟁은 질 수 있다'고 말한다. 타입스크립트의 설계 목표가 정확성과 생산성의 균형이지만 그 생산성은 결국 인간의 생산성이며, 정렬할 때 값을 문자열로 바꾸는 자바스크립트의 오래된 습관처럼 언어 바닥에 이미 슬롭이 깔려 있다는 것이다. 그래서 그가 보여 준 대안은 코드를 시각화해 필요한 부분만 펼쳐 보고, 성능 부담이 거의 없는 실행 추적으로 시간이 어디에 쓰였는지 파악하며, 함수 설명과 사용처를 한 번의 호출로 받아오는 에이전트 친화적 도구들이다.
주요 인사이트
- 표준화를 포기하는 대신 '변하지 않는 것'만 명시하는 접근은, 팀원마다 다른 AI 도구를 쓰는 현실에서도 코드베이스가 흩어지지 않게 하는 현실적인 절충안이다.
- AI가 만든 산출물을 사람이 전부 읽는 대신 에이전트에게 검사시키고 사람은 '진짜 문제인지'만 판정하는 구조는, 검토 비용을 늘리지 않고 품질을 지키는 방식이다.
- 도구 호출 횟수나 오류 발생률처럼 에이전트가 남긴 흔적을 지표로 삼으면, 설계 결정을 취향이 아니라 측정값으로 판단할 수 있다.
- 에러가 발생할 수 있다는 사실을 함수가 스스로 알고 상위 함수까지 전파되면, 컴파일러가 예외 처리 누락을 증명해 줄 수 있어 에이전트가 남발하는 무의미한 예외 처리를 막을 수 있다.
- 발표자는 새 언어로 모든 코드를 다시 쓰라고 요구하는 대신 파이썬·타입스크립트 등 기존 언어에서 그대로 호출할 수 있게 만드는 쪽을 택했다. 새 기술의 도입 장벽을 낮추는 전형적인 방법이다.
자주 묻는 질문
코드 리뷰를 없앴는데 어떻게 품질을 유지하나요?
사람의 리뷰 대신 세 가지 장치를 씁니다. 몇 달간 바뀌지 않는 최소한의 아키텍처 문서, 의존성 규칙이 깨지면 CI에서 걸리는 검사 도구, 그리고 에이전트가 만든 코드와 실행 기록을 다른 에이전트가 검사해 문제를 뽑아내는 파이프라인입니다. 사람은 그 결과 중 실제 문제와 환각을 가려내는 역할을 맡습니다.
'슬롭'이란 무엇을 뜻하나요?
발표자는 슬롭을 '읽지 않는 코드'라고 정의합니다. AI가 대량으로 코드를 생성하면서 아무도 전부 읽지 않는 코드가 늘어나는데, 지금 코드베이스가 앞으로 가질 슬롭 중 가장 적은 수준이므로 이를 인정하고 대응 체계를 만들자는 주장입니다.
왜 기존 언어로는 부족하다고 보나요?
타입스크립트의 설계 목표가 정확성과 생산성의 균형인데 그 생산성은 인간 기준이라는 점을 짚습니다. 사람이 코드를 한 줄도 쓰지 않는 세상이라면 애초에 하지 않았을 설계가 언어 바닥에 남아 있고, 그 위에 도구를 아무리 얹어도 한계가 있다는 것입니다.
실행 추적이 왜 중요하다고 말하나요?
코드를 전부 읽지 않는 세상에서는 프로그램을 이해하는 유일한 방법이 실제 실행 흔적이기 때문입니다. 어느 구간에 시간이 얼마나 쓰였는지 남기고, 그 기록을 에이전트가 따라가며 버그와 비효율을 찾아 개선할 수 있게 하자는 취지입니다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗