Fighting Slop with Slop — Vaibhav Gupta, Boundary

URL: https://www.youtube.com/watch?v=AMiyLItEtLA 날짜: 2026-07-31 채널: AI Engineer (aiDotEngineer) 처리일: 2026-07-31

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Boundary(BAML 프로그래밍 언어 개발사)의 Vaibhav Gupta는 ==코드 리뷰 없이, 표준화 없이, 각자 원하는 AI 툴로 병렬 작업하는 파격적인 엔지니어링 문화로 지난 3년간 새 프로그래밍 언어(BAML)를 8명 규모 팀이 만들어왔다==고 말한다. "Slop"(읽지 않는 코드)을 없애려 하기보다 오히려 slop을 받아들이고, 그 대신 프로세스·툴링·언어 자체를 slop에 맞게 재설계함으로써 slop과 싸운다는 것이 핵심 주장이다.

• 코드 리뷰 없음, 병렬 작업 강제, AI 사용법 비표준화라는 3대 원칙에도 불구하고 안정적인 프로그래밍 언어를 3년간 성공적으로 개발해왔음
• "Slop은 당신이 읽지 않는 모든 코드"라는 재정의를 통해, 코드 리뷰 부재를 결함이 아니라 현재 개발 방식의 본질적 특성으로 받아들임
• 다만 TypeScript/JavaScript 같은 기존 언어는 애초에 "인간 생산성"을 위해 설계된 것이라 에이전트 시대에는 근본적으로 부적합하며, 이 때문에 slop과의 "전쟁"에서는 결국 질 수밖에 없다고 전망함

발표자는 자신들이 3년간 겪은 "slop과의 전투"를 표준(standards), 디자인(design), 아키텍처(architecture), 신뢰(trust) 네 개의 전투로 나눠 설명하고, 이후 더 근본적으로 언어 자체를 새로 설계해야 한다는 결론으로 나아간다.

---

1. 코드 리뷰 없는 팀의 3대 엔지니어링 원칙

Boundary 팀은 코드 리뷰, 표준화된 AI 사용법, 순차적 작업이라는 전통적 관행을 모두 버리고 3년 전부터 프로그래밍 언어(BAML)를 개발해왔다.

1.1. 파격적인 팀 운영 방식

1. 3가지 원칙

   1. 코드 리뷰 없음: 팀 전체가 코드 리뷰 프로세스 없이 작업한다
   2. 강제 병렬 작업: 모든 엔지니어가 여러 작업을 동시에 병렬로 진행하도록 요구받는다
   3. AI 사용법 비표준화: 어떤 AI 툴을 쓸지 회사가 정하지 않는다 — Claude를 쓰는 사람, Codex를 쓰는 사람, Hacker News에서 방금 발견한 최신 툴을 쓰는 사람이 뒤섞여 있다

2. 왜 이 방식을 택했나

   1. 채용의 현실: 뛰어난 엔지니어를 채용하면 그들에게 "이것만 써라"라고 지시하기 어렵다는 현실적 이유
   2. 역설적 선택: 프로그래밍 언어는 slop이 절대 들어가서는 안 되는 영역(항상 정확히 동일하게 동작해야 하고, 1년 뒤에 설계를 바꿀 수 없음)임에도 이런 방식을 택함

1.2. "Slop"의 재정의

1. Slop이란 무엇인가

   1. 정의: "Slop is just any code you don't read" — 당신이 읽지 않는 모든 코드가 곧 slop이다
   2. 현재가 최선의 순간: "이 순간이 당신 코드베이스에 slop이 가장 적은 순간이다. 소중히 여겨라" — 시간이 갈수록 읽지 않는 코드의 비중은 늘어날 수밖에 없다는 냉소적 통찰

2. 전략의 전환

   1. 멘토 "Slop Sue"의 가르침: "slop을 물리치려면 우리가 slop이 되어야 한다"는 비유로 팀의 접근법을 설명
   2. 맞불 전략: slop을 막으려 하기보다, slop으로 slop과 싸운다 — 즉 AI가 만든 결과물을 검증·관리하는 도구 자체를 AI로 빠르게 만들어 대응

---

2. 전투 1: 표준의 전투 (Battle of Standards)

각기 다른 AI 툴을 쓰는 엔지니어들 사이에서 공통 기준을 어떻게 세울지에 대한 해법.

2.1. architecture.md 파일

1. CLAUDE.md 대신 범용 파일

   1. 모델 중립적 명명: 특정 벤더 이름이 붙은 CLAUDE.md 대신, 어떤 모델이든 이해할 수 있는 이름의 파일(architecture.md)을 사용
   2. 극도로 작고 불변하는 내용만: 이 파일에는 몇 달~몇 년간 바뀌지 않을 내용만 담아야 한다 — Boundary의 경우 컴파일러의 레이어 구조가 이에 해당

2. 불변 규칙(invariant)으로서의 역할

   1. 깊이 제한 규칙: 컴파일러 레이어를 더 깊이 파고들수록, 에이전트가 최소 한 명의 다른 사람과 상의하도록 강제해 속도를 의도적으로 늦춤
   2. 표준화 없는 표준: 이렇게 하면 누구나 원하는 툴을 써도 되지만, 공통된 불변 기준선은 확보된다

---

3. 전투 2: 디자인의 전투 (Battle of Design)

"코드는 slop이어도 되지만, 글은 안 된다"는 팀의 핵심 규칙과 이를 뒷받침하는 도구 체인.

3.1. "Code can be slop, writing cannot" 원칙

1. 규칙의 배경

   1. 완벽한 디자인 문서의 필요성: 코드 자체는 AI가 대충 만들어도 되지만, 설계 의도를 담은 글은 정제되어야 한다는 원칙
   2. 현실과의 괴리: 하지만 이 규칙만 던져놓으면 엔지니어들이 손으로 아름다운 글을 쓸 것이라 기대했으나, 실제로는 그렇지 않았음("sadly not")

2. 자체 디자인 문서 툴 구축

   1. Notion + GitHub 대체 툴: 버저닝, 코멘트 등 필요한 기능을 모두 갖춘 자체 디자인 문서 도구를 만듦
   2. 여전히 사용 안 됨: 툴을 만들어도 사람들이 자발적으로 쓰지 않는 문제가 재발("sadly not")

3.2. Slack 통합과 "필독" 규칙으로 완성

1. Slack 알림 채널

   1. 자동 알림 연동: 디자인 문서가 업데이트될 때마다 Slack 채널에 알림이 뜨도록 통합 툴을 추가로 구축
   2. 가장 인기 있는 채널이 됨: 이 채널이 회사에서 가장 활발한 채널이 됨 — 새벽 2시에 새 문서가 올라오면 3명이 바로 읽기 시작할 정도로 흥미로운 콘텐츠 허브가 됨
   3. Markdown + CLI 기반: 이 모든 시스템은 실제로는 Markdown 파일과 간단한 CLI 스크립트로 구현되어 있어, GitHub 자체를 쓰지 않으면서도 GitHub처럼 동작하게 만듦 — 에이전트가 다루기 쉬움

2. 발표자 자신의 "AI 사이코시스" 에피소드

   1. 하루 10개 디자인 문서: 발표자가 이 툴에 심취해 하루에 디자인 문서를 10개씩 쏟아내기 시작했고, 팀이 그의 slop과 싸우게 되는 역설적 상황이 발생
   2. 최후의 규칙 추가: 결국 "디자인 문서를 올리려면, 사람들이 실제로 읽게 만들어야 한다"는 규칙을 마지막으로 추가하고 나서야 문서 품질이 급격히 높아짐

---

4. 전투 3: 아키텍처의 전투 (Battle of Architecture)

코드베이스 전체의 구조적 일관성(convergence)을 어떻게 지킬 것인가.

4.1. 의존성 그래프 시각화 툴

1. 내부 아키텍처 시각화

   1. 의존성 그래프: 내부 패키지 및 일부 외부 의존성을 포함한 전체 의존성 그래프를 시각화하는 툴을 구축
   2. 시맨틱 경계: 개별 패키지 단위의 시맨틱 경계를 표시해 코드베이스 변화를 관찰할 수 있게 함

2. 불변 규칙을 강제하는 CLI 툴

   1. 깨질 수 없는 invariant: Claude가 새 패키지를 만들거나 느슨한(leaky) 의존성을 추가하면, CI/CD 변경이나 Git 커밋 히스토리를 통해 정확히 어디서 문제가 생겼는지 알 수 있게 하는 CLI 툴을 구축
   2. 성과: 이 결과 지난 3~4개월간 아키텍처를 한 번도 바꾸지 않을 정도로 구조적 안정성을 확보함

---

5. 신뢰의 시스템: 에이전트가 코드를 검증하는 파이프라인

프로그래밍 언어처럼 제네릭, 클로저, 메모리 할당, FFI 경계 등 수많은 불변식을 가진 시스템을 코드를 읽지 않고도 신뢰할 수 있는가에 대한 해법.

5.1. 상시 실행되는 검증 에이전트

1. BAML 프로그램 자동 생성 및 실행

   1. 처음부터 스핀업: 에이전트가 상시로 BAML 프로그램을 처음부터 만들어 실행해보게 함
   2. 전체 Claude 트랜스크립트 분석: 어떤 툴을 썼는지, 무슨 일이 일어났는지 전체 실행 기록을 사람도, 더 중요하게는 에이전트도 검사하게 함

2. 문제 탐지의 두 층위

   1. 정확성 오류 탐지: 언어 자체에서 잘못된 부분(incorrect한 것)을 찾아냄
   2. 효율성 오류 탐지: 한 번의 툴 콜로 끝났어야 할 일이 세 번의 툴 콜이 걸린 것처럼, 비효율(비효율적 tool call 수)까지 찾아냄
   3. 사람과의 협업으로 필터링: 어떤 이슈가 진짜 문제인지, 어떤 것이 할루시네이션인지, 어떤 것이 그냥 "취향(taste)"의 문제인지 사람이 에이전트와 함께 판별

5.2. 데이터 기반 언어 설계 — A/B 테스트

1. 언어 기능의 A/B 테스트

   1. 직관 대신 실측: 어떤 언어 기능이 좋은지 추측하는 대신, 실제로 A/B 테스트해서 어떤 것이 더 적은 툴 콜, 더 적은 에러, 더 정확한 결과를 내는지 결정론적으로 파악
   2. 코드 한 줄 없이 데이터 기반 시스템 구축: 이런 방식으로 사람이 코드를 한 줄도 작성하지 않고도 데이터 기반 의사결정 시스템을 만들 수 있다는 것이 핵심

2. 개발 규모에 대한 통찰

   1. 전통적 방식이었다면: 프로그래밍 언어를 만드는 데 전통적 방식이었다면 8명이 아니라 훨씬 많은 인원, 2년이 아니라 훨씬 긴 시간, 수만 인시(man-hour)가 필요했을 것이고 그래도 결함투성이 시스템이 나왔을 것
   2. 지금은 토큰만 있으면 됨: 오늘날은 그저 수백만 토큰을 소비하는 것만으로 이를 해내고 안정화까지 시킬 수 있다는 것

---

6. 그럼에도 이 전쟁에서는 진다 — 언어 자체의 근본적 결함

Slop과의 전투에서는 이길 수 있어도, 전쟁에서는 진다고 발표자는 단언한다. 그 이유는 기반이 되는 언어들 자체가 애초에 사람을 위해 설계됐기 때문이다.

6.1. TypeScript의 설계 목표와 그 함정

1. "Human productivity"라는 설계 목표

   1. TypeScript의 공식 목표: TypeScript의 핵심 설계 목표는 정확성(correctness)과 생산성(productivity) 사이의 균형을 맞추는 것인데, 여기서 생산성이란 정확히는 "인간의" 생산성을 의미한다는 점을 지적
   2. 사람이 코드를 안 쓰는 세상이라면: 만약 사람이 코드를 전혀 작성하지 않는 세상에서 언어를 설계했다면 절대 하지 않았을 선택들이 핵심 레이어에 들어가 있다는 것

2. 구체적 결함 시연 (라이브 데모)

   1. 정렬 시 문자열 변환: 숫자를 정렬할 때 왜 문자열로 바꾸는지("Why do we turn things to strings when we sort them?") — JS 배열 정렬의 기본 동작이 숫자를 문자열처럼 비교하는 함정을 지적
   2. 예측 불가능한 코드 스니펫: 여러 개의 짧은 코드 조각을 보여주며 무슨 동작을 할지 맞혀보라고 하는데, 언뜻 봐서는 결과를 예측하기 어려운 사례들을 연달아 제시하며 "이것이 언어에 박혀 있는 slop"이라고 강조
   3. 에이전트도 좋아하는 함정: 특정 TypeScript 문법(발표에서 직접 시연, 정확한 코드는 화면 시연으로만 제시됨)을 두고 "내 에이전트가 좋아하는 이 부분도 언어에 박힌 slop"이라고 언급

6.2. 레이어를 계속 쌓아온 역사의 한계

1. 패치의 역사
   1. JavaScript → CoffeeScript → TypeScript: JavaScript가 존재한 뒤 그 위에 CoffeeScript, TypeScript로 계속 레이어를 쌓아왔지만, 그 밑바탕 자체가 이미 깨져 있다는 것
   2. 코드 작성 방식 자체의 변화: 코드를 작성하는 방식 자체가 이제는 예전과 완전히 달라졌는데도, 여전히 같은 기반 위에 패치만 얹고 있다는 문제 제기
   3. 처방: 그래서 fix보다는 처음부터 다시 설계된 "made-up language"(=BAML)가 필요하다는 결론으로 이어짐

---

7. 코드를 읽지 않는 새로운 개발 방식

"코드를 읽지 않는다"는 것이 실제로 어떤 의미인지, BAML 툴링을 통한 라이브 데모로 보여준다.

7.1. 코드 시각화와 실행 트레이스

1. 클릭 기반 코드 시각화

   1. 정확한 라인으로 이동: 코드를 텍스트가 아니라 시각화된 형태로 보고, 클릭하면 관련된 정확한 코드 라인으로 이동
   2. 줌 인/아웃으로 탐색: 더 넓은 시야가 필요하면 줌 인해서 클릭하며 확장, 관심 없는 부분은 "그건 그냥 slop으로 남겨두자"며 넘어갈 수 있음

2. 실행 트레이스 기반 이해

   1. 코드를 안 읽는 세상의 이해 방식: 코드를 다 읽지 않는 세상에서는 실행 트레이스(execution trace)를 보는 것이 유일한 이해 방법이 됨
   2. 시간 소요 지점 파악: 프로그램의 어느 부분에 얼마나 시간이 쓰였는지 정확히 볼 수 있음 — Python/TypeScript에서 이런 트레이싱을 다 하려면 감당이 안 될 정도로 느려짐(untenable)을 지적
   3. 제로 성능 비용: 처음부터(first principles) 설계하면 이 트레이싱을 사실상 성능 비용 없이(zero performance cost) 구현할 수 있음 — 모든 파일에 트레이싱 시스템이 내장되어 Claude가 버그·에러·비효율을 스스로 찾아 최적화할 수 있음

7.2. 에이전트를 위한 툴링 ("Agent-first tooling")

1. grep을 넘어서는 코드 탐색

   1. Ripgrep의 한계: "calculate"를 ripgrep으로 검색하면 사용된 모든 곳이 나오긴 하지만 여러 번의 툴 콜이 필요
   2. "describe" 명령: 대신 함수 이름을 주고 "describe"를 요청하면 docstring, 실제 소스 코드, 사용된 모든 위치가 한 번의 툴 콜로 반환됨 — 여러 번의 툴 콜을 하나로 압축

2. 외부 라이브러리 조회도 동일하게

   1. 웹 검색 대신 직접 질의: 사용 중인 외부 라이브러리에 대해서도 웹 검색 대신 곧바로 물어보면 답이 나오는 구조
   2. "코드가 진실의 원천"이라는 원칙: 발표자가 처음 코딩을 배울 때 얻은 교훈 — 문서(docs)나 README, 아키텍처 파일은 거짓말을 할 수 있지만 코드는 거짓말을 하지 않는다("The code is always the source of truth")

3. 모든 함수를 CLI 명령으로

   1. 즉시 실행 가능한 CLI화: 작성한 모든 함수가 즉시 CLI 명령으로 사용 가능 — 예: add라는 함수는 A, B 파라미터를 가진 CLI 커맨드가 되어 바로 실행 가능
   2. 독립 실행형 바이너리: multiply 같은 함수들도 코드를 실제로 실행하지 않고도 완전한 CLI 바이너리로 패키징됨 — 타입 안전하고 결정론적이며 예측 가능
   3. 크로스 플랫폼 배포: Windows/Mac/Linux는 물론 WASM까지 어떤 아키텍처든 타겟팅해 빌드 가능해, 배포 걱정 없이 에이전트 속도로 움직일 수 있게 됨

---

8. 에러 처리의 근본적 재설계

JavaScript 생태계에서 특히 지저분한 영역인 에러 처리를 BAML이 어떻게 첫 원칙부터 다시 설계했는지에 대한 라이브 데모.

8.1. 기존 에러 처리의 문제

1. 중첩된 try-catch 지옥
   1. 에이전트의 전형적 패턴: 에이전트가 try-catch를 계속 중첩해서 쌓다가 결국 포기하고 console.log로 "에러가 발생했다"고만 찍고 넘어가는 패턴을 지적
   2. Rust를 제외하면 아름다운 에러 처리를 본 적이 없다는 문제의식에서 출발

8.2. BAML의 타입 추론 기반 에러 시스템

1. 에러 타입 자동 추론

   1. divide 함수 시연: divide 함수가 "division by zero" 에러를 던진다는 사실을 코드로 명시하지 않아도 함수가 스스로 안다
   2. 호출 체인 전파: divide를 내부에서 호출하는 calculate 함수도 자신이 "division by zero" 에러를 던질 수 있다는 사실을 자동으로 알게 됨 — 별도 코드 작성 없이 에러 타입이 추론되어 전파됨

2. 컴파일러의 전수적(exhaustive) 검증

   1. 증명 가능한 에러 처리: 에러를 처리했는지 안 했는지 컴파일러가 증명(prove)할 수 있음 — 더 이상 추측이 아니라 보장(guarantee)의 영역
   2. API 계약 위반 감지: "절대 에러를 던지지 않는다"고 명시한 API가 실제로는 처리되지 않은 에러 두 개를 갖고 있다면 시스템이 이를 계약 위반으로 잡아냄
   3. 센티널 값으로 처리: division by zero 에러를 잡아서 0을 반환하도록 처리하면, parse 함수가 더 이상 그 에러를 던지지 않는다는 것이 보장됨으로 바뀜 — 컴파일러와 툴링이 이 보장을 대신 해줌

---

9. 점진적 도입 전략: 언어 전면 교체 없이 쓰는 법

새 언어를 쓰라고 강요하면 오히려 새로운 문제 뭉치가 생길 뿐이라는 반성에서 나온 해법 — 기존 코드를 다시 쓰지 않고도 BAML을 쓸 수 있게 하는 방식.

9.1. 다중 언어에서 직접 호출 가능한 BAML

1. 모든 주요 언어에서 접근 가능

   1. 약 2년 전부터 고민: "독립형(standalone)으로만 쓰는 게 아니라, Python이든 TypeScript든 Rust든 Go든 Ruby든 Java든, 심지어 앞으로 나올 언어에서든 BAML 함수를 즉시 쓸 수 있게 하면 어떨까"라는 질문에서 출발
   2. 타입 세이프한 직접 호출: Python에서 BAML의 calculate 함수를 타입 안전하게 직접 호출하는 예시를 시연
   3. 동기/비동기 모두 지원: calculate뿐 아니라 calculate_async도 함께 제공되어, function coloring 문제 없이 원하는 방식으로 코드를 쓸 수 있음

2. 언어 경계를 넘나드는 람다·제네릭·클로저

   1. with_timeout 시연: 특정 밀리초 안에 작업이 끝나지 않으면 타임아웃되는 with_timeout 함수를 통해, Python 람다(lambda)를 언어 경계 너머로 그대로 전달할 수 있음을 보여줌
   2. 제네릭·클로저도 전달 가능: 제네릭과 클로저까지 언어 경계를 넘어 전달 가능해, 엔지니어가 이를 신경 쓸 필요가 없음
   3. 타입 시스템이 절대 거짓말하지 않음: 에이전트가 무언가를 하더라도 타입 시스템이 진실의 절대적 중심이 되어, 불변식이 코드베이스에 침투하는 것을 막아줌

---

10. 결론: Slop을 이기려면 프로세스 자체를 재설계하라

10.1. 핵심 교훈

1. 전통적 프로세스 없이도 복잡한 시스템을 만들 수 있다

   1. 코드 리뷰 없이도 가능: 코드 리뷰, 표준화된 AI 사용 없이도 병렬로 일하며 복잡한 시스템(프로그래밍 언어)을 만들 수 있음을 실증
   2. 핵심은 신중함: 다만 엔지니어링 팀이 그 아래 시스템을 실제로 어떻게 쓰는지에 대해 극도로 신중하게(thoughtful) 설계해야 한다는 것이 전제

2. 놀라운 성과 사례

   1. BAML로 만든 C 컴파일러: 바로 어제(발표 시점 기준) 한 엔지니어가 순수하게 BAML만으로 부분적인 C 컴파일러(partial C compiler)를 만들었다는 일화 소개
   2. 코드를 읽지 않는 것의 역설적 효과: 코드를 읽지 않기 시작하면서 오히려 엔지니어링 팀이 기존 프로세스의 빈틈을 메울 여력이 생겼다는 통찰

10.2. CI/CD와의 비유 및 최종 메시지

1. CI/CD 도입 초기의 교훈

   1. 처음엔 느려짐: CI/CD가 없던 회사들이 "CI/CD 도입하면 느려진다"고 했지만, 실제로는 3개월 정도 느려진 뒤 훨씬 빨라졌다는 비유
   2. 프로세스는 진화해야 한다: "에이전트 속도로 배포하려면 우리 프로세스도 진화해야 한다"는 메시지

2. 청중에게 던지는 두 가지 과제

   1. 당장 할 일: 각자 돌아가서 "지저분한(sloppy) 툴"을 만들어 시스템과 프로세스를 더 견고하게 만들 것
   2. 더 대담한 사람들에게: 근본적인 기반 시스템(foundation layer)이 왜 깨져 있는지 생각하고 고칠 방법을 상상해볼 것 — 발표자는 "새로운 Git, 새로운 데이터베이스, 그리고 그렇다, 새로운 프로그래밍 언어가 필요하다고 생각한다"며 마무리

---

주요 발언 모음

"To defeat the slop, we must become the slop."

"Slop is just any code you don't read. And whether any of you admit it or not, this is the least amount of slop that your code base will ever have. Cherish it."

"Code can be slop, writing cannot."

"The code is always the source of truth. Don't read anything but the code itself. The docs may lie, the actual description or architecture file or readme file will definitely lie, but the code cannot lie."

"TypeScript's main design goal is to strike a balance between correctness and productivity... what they really mean is human productivity."

"I think we're still going to lose the war."

"I think we do need a new Git. I think we do need a new database, and yes, I think we need a new programming language."

핵심 데이터 & 수치

• 3년: Boundary 팀이 BAML 프로그래밍 언어를 개발해온 기간
• 8명: 전통적 방식이었다면 훨씬 더 많은 인원이 필요했을 것이라고 언급된, 실제 이 프로젝트를 진행한 팀 규모
• 3~4개월: 아키텍처 invariant 툴 도입 이후 아키텍처를 한 번도 바꾸지 않은 기간
• 1일(어제): 한 엔지니어가 순수 BAML만으로 partial C 컴파일러를 만드는 데 걸린 시간
• 15년: 발표자가 소프트웨어에 빠진 지 지난 시간
• 21분 32초: 영상 총 재생 시간 (AI Engineer 컨퍼런스 발표)

결론 및 시사점

1. Slop(읽지 않는 AI 생성 코드)을 없애려 싸우기보다, slop을 인정하고 이를 검증·관리하는 프로세스와 툴(design doc 툴, 의존성 시각화, 실행 트레이스, 에이전트 검증 파이프라인)을 빠르게 구축하는 편이 실용적이다.
2. "코드는 slop이어도 되지만 글(디자인 문서)은 안 된다"처럼, 팀 차원에서 slop이 허용되는 영역과 허용되지 않는 영역을 명확히 구분하는 규칙이 필요하다.
3. architecture.md 같은 작고 불변하는 공통 기준 파일 하나만으로도, AI 툴을 표준화하지 않고서도 팀 전체의 일관성을 확보할 수 있다.
4. 다만 근본적으로는 TypeScript/JavaScript 같은 "사람을 위해 설계된" 언어 자체가 에이전트 시대의 한계이며, 장기적으로는 언어·Git·데이터베이스 같은 기반 시스템 자체를 에이전트 중심으로 재설계해야 한다는 것이 발표자의 최종 진단이다.
5. 기존 코드베이스를 전면 재작성하지 않고도, BAML처럼 다중 언어에서 타입 세이프하게 호출 가능한 방식으로 새 언어를 점진적으로 도입하는 전략이 현실적인 채택 경로가 될 수 있다.