Boundary 팀, AI 생성 부실 코드 '슬롭'에 맞서는 전략 공개: 코드 리뷰 대신 AI 검증, 고품질 문서화, 그리고 BAML

Boundary 팀은 코드 리뷰를 하지 않고 모든 엔지니어가 작업을 병렬로 진행하도록 요구합니다. 또한, AI 사용 방식에 대한 표준화 없이 각 엔지니어가 원하는 AI 도구를 자유롭게 사용하도록 합니다. 이는 전통적인 개발 방식과는 다른 접근 방식으로, 빠른 개발 속도를 추구하는 팀의 문화를 반영합니다.

이 방식은 AI가 생성하는 코드의 품질이 균일하지 않다는 문제를 내포하지만, 팀은 이를 다른 방식으로 해결하고 있습니다.

Boundary 팀은 AI가 생성하는 부실한 코드를 뜻하는 '슬롭(Slopp)'과의 전쟁에서 승리하기 위한 역설적인 전략을 제시했습니다. 즉, 슬롭을 이기려면 우리 스스로가 슬롭이 되어야 한다는 것입니다. 이는 AI의 빠르고 비정형적인 생성 방식을 수용하고, 이를 다시 AI의 힘으로 통제하고 개선하겠다는 의미를 담고 있습니다.

팀에는 코드가 '슬롭'일 수 있지만 글쓰기는 완벽해야 한다는 간단한 규칙이 있습니다. 여기서 글쓰기는 주로 설계 문서를 의미합니다. 코드가 완벽하지 않아도 작동하는 데는 문제가 없지만, 설계 문서가 부실하면 팀원들이 시스템을 이해하고 협업하는 데 큰 어려움을 겪기 때문입니다.

이는 AI가 생성한 코드의 잠재적 불완전성을 인정하면서도, 시스템의 전반적인 이해와 유지보수를 위한 핵심적인 기준을 제시하는 것입니다. 고품질의 설계 문서는 팀원들이 복잡한 시스템을 효율적으로 탐색하고 이해하는 데 필수적인 요소로 작용합니다.

설계 문서의 높은 품질을 유지하기 위해 팀은 마지막 규칙을 적용했습니다. 바로 설계 문서를 게시하려면 다른 사람들이 실제로 읽고 검토해야 한다는 것입니다. 이 규칙 덕분에 팀은 엄청나게 높은 품질의 설계 문서를 갖게 되었습니다.

이러한 검토 과정은 문서의 명확성, 정확성, 그리고 완전성을 보장하며, 팀원 간의 지식 공유를 활성화하는 중요한 역할을 합니다. 아무도 읽지 않는 문서 대신, 실제로 팀의 협업을 돕는 살아있는 문서가 되도록 하는 전략입니다.

Boundary 팀은 AI가 생성한 코드를 다른 AI 에이전트들이 끊임없이 검증하는 시스템을 구축했습니다. 이는 사람이 직접 코드 리뷰를 하는 대신, AI의 속도와 효율성을 활용하여 코드의 품질을 유지하려는 시도입니다. 에이전트들은 코드의 잠재적인 문제점이나 비효율성을 지속적으로 찾아내고 개선합니다.

이 시스템은 '슬롭'을 이기기 위해 스스로 '슬롭'이 되는 전략의 핵심 부분으로, AI의 장점을 극대화하여 개발 프로세스를 자동화하고 최적화합니다.

AI 에이전트 시스템은 단순히 코드 문제를 감지하는 것을 넘어, 문제 해결을 위한 최적의 방안을 찾기 위해 A/B 테스트를 활용합니다. 어떤 언어 기능이 더 좋았는지, 어떤 기술이 더 효과적인지 추측하는 대신, 다양한 해결책을 적용해보고 실제 성능을 비교합니다. 이를 통해 도구 호출이 적고, 오류가 적으며, 올바른 결과를 생성하는 결정론적인 해결책을 찾을 수 있습니다.

이러한 A/B 테스트 방식은 AI가 생성하는 코드의 비결정론적인 특성을 보완하고, 실제 운영 환경에서 가장 효율적이고 안정적인 코드를 선택할 수 있게 합니다.

AI 엔지니어들은 '슬롭'과의 개별적인 전투에서는 승리하기 시작할 수 있다고 언급했습니다. AI 에이전트와 체계적인 검증 시스템을 통해 부실한 코드를 제어하고 개선할 수 있다는 자신감을 내비친 것입니다. 하지만 그럼에도 불구하고, 팀은 여전히 전체적인 '전쟁'에서는 질 수도 있다고 경고합니다. 이는 AI 생성 코드의 근본적인 문제와 기존 프로그래밍 언어의 한계가 여전히 남아있기 때문입니다.

강연자는 인간이 코드를 한 줄도 작성하지 않는 세상을 가정한다면, 기존 프로그래밍 언어에는 설계상으로 절대 하지 않을 일들이 존재한다고 지적했습니다. 이는 언어 자체에 내재된 '슬롭'을 의미하며, 개발자들이 좋든 싫든 받아들여야 하는 부분이라고 설명했습니다. 예를 들어, JavaScript와 같은 언어는 빠르게 발전했지만, 그 기반에는 AI 시대에 맞지 않는 설계적 한계가 있다는 것입니다.

이러한 내재된 슬롭은 AI가 코드를 생성하고 활용하는 데 있어 근본적인 장애물로 작용하며, 새로운 언어 설계의 필요성을 제기하는 배경이 됩니다.

기존 프로그래밍 언어에 대한 해결책으로 TypeScript나 CoffeeScript처럼 덧씌우는 방식은 한계가 있다고 지적했습니다. JavaScript와 같은 언어가 존재하고 그 위에 시스템을 구축했지만, 근본적인 문제는 밑바탕이 이미 고장 나 있다는 것입니다. 현재는 코드를 작성하는 방식 자체가 달라졌기 때문에, 기존의 고장 난 시스템을 계속 패치하기보다는 근본적으로 다른 언어를 시도해야 할 시점이라고 주장했습니다.

이는 AI 시대의 요구사항에 맞춰 처음부터 재설계된 새로운 프로그래밍 패러다임이 필요하다는 의미입니다. 기존 언어의 한계를 뛰어넘어 AI 에이전트의 효율성과 안정성을 극대화할 수 있는 언어에 대한 비전을 제시합니다.

코드를 직접 읽지 않는 세상에서 코드를 이해하는 유일한 방법은 실제 실행 추적을 통해서라고 설명했습니다. 이는 프로그램의 어떤 부분에 얼마의 시간이 소요되었는지 정확히 확인하는 방식으로, 코드의 내부 동작을 시각적으로 파악하고 병목 현상을 식별하는 데 도움이 됩니다. 특히 AI가 생성한 복잡하거나 익숙하지 않은 코드를 이해하는 데 매우 유용합니다.

이 방식은 전통적인 코드 리딩 방식에서 벗어나, 실행 경로와 성능 데이터를 기반으로 코드의 흐름을 파악하는 새로운 접근 방식을 제시합니다.

Boundary 팀은 처음부터 시작한다면 사실상 제로 성능 비용으로 추적 시스템을 만들 수 있다고 강조했습니다. 이 시스템은 사람뿐만 아니라 AI 에이전트를 위해 구축되었기 때문에, Claude와 같은 에이전트가 모든 파일의 추적 시스템을 탐색하여 버그, 오류, 비효율성을 찾아 코드를 최적화할 수 있습니다.

이는 에이전트가 개발 프로세스에 깊숙이 통합되어, 코드 품질을 지속적으로 향상시키고 개발 효율성을 높이는 중요한 기반이 됩니다. 성능 저하 없이 코드의 모든 단계를 추적할 수 있어 AI의 진단 및 최적화 능력을 극대화합니다.

에이전트 중심 툴링의 모습에 대해, grep과 같은 전통적인 코드 검색 대신 AI에게 코드를 설명해 달라고 요청할 수 있다면 어떨지 제시했습니다. 예를 들어, 'calculate를 설명해 줄 수 있나요?'라고 물으면, AI는 해당 함수의 모든 독스트링과 실제 소스 코드는 물론, 내부적으로 사용된 모든 곳까지 알려줄 수 있습니다. 이는 개발자가 코드를 일일이 탐색할 필요 없이, AI의 도움을 받아 빠르고 정확하게 코드의 기능과 작동 방식을 이해할 수 있게 합니다.

이러한 방식은 AI를 단순한 코드 생성 도구가 아닌, 코드 이해 및 분석의 핵심 파트너로 활용하여 개발 워크플로우를 혁신할 수 있는 잠재력을 보여줍니다.

작성하는 모든 함수를 즉시 간단한 CLI(명령줄 인터페이스) 명령으로 사용할 수 있게 된다면 어떨지 상상해보라고 제안했습니다. 예를 들어, 'add' 함수를 실행하면 'add'가 A와 B 매개변수를 가진 CLI 명령이 되어 빠르게 실행하고 결과를 확인할 수 있습니다.

이러한 접근 방식은 개발자가 코드를 실행하기 위해 별도의 환경 설정이나 복잡한 단계를 거칠 필요 없이, 마치 운영체제 명령처럼 쉽게 함수를 호출하고 테스트할 수 있게 합니다.

보유한 모든 CLI 도구를 완전한 독립 실행형 CLI 바이너리로 묶어 실제 코드를 실행하지 않고도 바로 실행할 수 있는 방안을 제시했습니다. 이는 함수가 번들로 포함된 완전한 CLI 바이너리가 되는 형태입니다. 이를 통해 에이전트가 무슨 일이 일어나는지 일일이 grep할 필요 없이 매우 빠른 툴링을 구축할 수 있게 됩니다.

이 시스템은 모든 것이 타입 안전하고, 결정적이며, 추측 가능하게 만들어 AI 에이전트가 코드를 더욱 효율적이고 안정적으로 다룰 수 있도록 돕습니다. 배포 및 실행의 간소화를 통해 개발 및 테스트 속도를 획기적으로 향상시킬 수 있습니다.

자바스크립트와 같은 언어에 깊숙이 박혀 있는 '죄악' 중 일부, 특히 오류 처리와 같은 중요한 문제들을 고칠 수 있다면 어떨지 질문했습니다. Rust와 같은 일부 언어를 제외하고는 오류 처리가 아름다운 경우를 찾아보기 어렵다고 지적했습니다. 에이전트들이 try-catch를 중첩하고 결국 포기하며 단순히 오류를 로깅하는 방식으로 처리하는 것을 비판하며, 처음부터 오류 처리를 제대로 할 수 있는 세상의 필요성을 강조했습니다.

이는 기존 언어의 설계적 한계를 극복하고, 오류를 예측하고 안정적으로 처리할 수 있는 새로운 언어 시스템의 필요성을 부각합니다.

BAML 시스템에서는 오류 유형을 추측할 필요 없이 자동으로 추론합니다. 오류를 포착하거나 처리할 때 완전한 보장을 할 수 있으며, 컴파일러가 오류 처리 여부를 증명할 수 있습니다. 이는 더 이상 오류에 대해 추측할 필요가 없으며, 알 수 없는 것이 없고 증명이 보장된다는 것을 의미합니다.

이러한 강력한 타입 시스템과 컴파일러 지원은 런타임 오류의 위험을 크게 줄이고, AI 에이전트가 더욱 신뢰할 수 있는 코드를 생성하고 처리할 수 있는 기반을 마련합니다.

코드는 신뢰의 문제라고 강조했습니다. LLM(대규모 언어 모델) 코드를 맹목적으로 사용하지 않는 이유는 아직 신뢰하지 않기 때문이며, 그 근간 시스템에 충분한 엄밀함이 없기 때문이라고 설명했습니다. 반면 BAML은 처음부터 신뢰를 최우선으로 설계되어, 강력한 타입 시스템과 검증을 통해 코드의 안정성과 예측 가능성을 높입니다.

이러한 신뢰의 차이는 AI 생성 코드를 실제 프로덕션 환경에서 활용하는 데 있어 BAML이 가지는 핵심적인 강점입니다.

BAML의 모든 함수가 사용자가 선택한 언어에서 즉시 접근 가능하다면 어떨지 제시했습니다. 예를 들어, 파이썬에서 BAML의 계산 함수를 직접 호출하는 것이 완전히 타입 안전하게 이루어집니다. 이는 BAML이 다양한 프로그래밍 언어와의 상호운용성을 강력하게 지원하며, 각 언어의 타입 시스템 내에서 BAML 함수를 안전하게 사용할 수 있음을 의미합니다.

이러한 유연성은 개발자들이 기존의 언어 환경을 유지하면서도 BAML의 강력한 기능을 활용할 수 있게 하여, AI 통합 개발의 장벽을 낮춥니다.

BAML에서 가장 중요한 것은 에이전트가 어떤 작업을 수행할 때, 타입 시스템이 결코 거짓말을 하지 않는다는 점입니다. 타입 시스템은 코드베이스에 불변량이 침투하는 것을 막는 절대적인 진실의 중심이 됩니다. 이는 코드의 일관성과 예측 가능성을 보장하며, AI 에이전트가 생성하거나 사용하는 코드의 신뢰성을 극대화합니다.

이러한 강력한 타입 시스템은 '슬롭'과의 전쟁에서 BAML이 승리할 수 있는 핵심적인 근거가 됩니다.

에이전트의 속도에 맞춰 제품을 출시하려면 우리의 프로세스가 진화해야 한다고 강조했습니다. 현재의 개발 방식으로는 AI 에이전트가 제공하는 속도와 효율성을 온전히 활용하기 어렵기 때문입니다. 또한, 현재의 코드베이스가 가질 수 있는 '슬롭'의 양은 가장 적은 수준이므로, 이를 받아들이고 맞서 싸우기 시작해야 한다고 촉구했습니다.

이는 AI 시대의 개발 환경 변화에 맞춰 사고방식과 작업 방식을 근본적으로 개선해야 한다는 메시지를 담고 있습니다. AI를 단순한 도구가 아닌, 개발 프로세스의 핵심 동력으로 인식하고 적극적으로 활용하려는 의지를 보여줍니다.