Engineering Practice
코드 리뷰를 하지 않고, 모든 엔지니어가 병렬로 작업하며, AI 도구 사용에 표준을 두지 않는다. 이 세 가지 규칙으로 3년째 프로그래밍 언어를 만들고 있는 팀이 있다. 규칙을 뒤집은 자리에 무엇을 대신 놓았는지가, 사람이 코드를 다 읽지 않는 시대의 엔지니어링 설계도에 해당한다.
발표는 슬롭(slop)을 한 문장으로 규정한다. 슬롭은 읽지 않은 코드다. 버그가 있는 코드도, 지저분한 코드도, 성능이 나쁜 코드도 아니다. 아무도 눈으로 확인하지 않은 채 저장소에 들어간 코드가 슬롭이다.
이 정의는 겉보기에 소박하지만 논쟁의 판을 갈아엎는다. 품질이라는 속성을 코드에서 떼어내 사람과 코드의 관계로 옮겨놓기 때문이다. 같은 파일이 어제는 슬롭이었다가 오늘 누군가 읽으면 슬롭이 아니게 된다. 반대로 정적 분석을 모두 통과하고 테스트 커버리지가 90퍼센트인 코드도, 아무도 읽지 않았다면 슬롭이다.
발표자가 여기에 붙인 관찰이 더 날카롭다. 지금 여러분의 코드베이스가 앞으로 가질 수 있는 슬롭의 최소치라는 것이다. 생성량은 계속 늘어나고, 사람이 읽는 속도는 늘지 않는다. 그러므로 읽지 않은 코드의 비율은 단조 증가한다. 이 추세를 되돌리려는 시도는 실패가 예정되어 있고, 남는 선택은 비율을 관리 가능한 형태로 바꾸는 것뿐이다.
슬롭을 읽지 않은 코드로 정의하는 순간, 슬롭 제거는 목표에서 탈락한다. 사람의 독해량을 늘려 대응하는 전략이 산술적으로 불가능해지기 때문이다. 남는 전략은 두 가지다. 읽지 않아도 되는 영역을 명시적으로 구획하는 것, 그리고 그 영역 안에서 위반이 발생하면 사람이 아니라 기계가 먼저 알아채도록 만드는 것이다.
발표 전반에 등장하는 도구들은 전부 이 두 가지의 변형이다. 팀이 버린 것은 리뷰라는 활동이 아니라, 리뷰의 대상이 코드 라인이어야 한다는 전제다.
첫 번째 충돌은 표준화에서 일어났다. 우수한 엔지니어를 채용하면 그들에게 도구를 지정할 수 없다. 누구는 Claude를, 누구는 Codex를, 누구는 어제 뉴스에서 본 도구를 쓰겠다고 한다. 팀이 택한 해법은 규약을 도구 위에 세우지 않고 도구 아래로 내리는 것이었다.
구체적으로는 아키텍처를 기술한 파일 한 장을 저장소에 두었다. 특정 벤더의 규약 파일 이름을 쓰지 않고, 어떤 모델이든 그냥 이해할 수 있는 형식을 골랐다. 조건은 두 개다. 극단적으로 짧아야 하고, 몇 달에서 몇 년 동안 바뀌지 않을 내용만 담아야 한다. 컴파일러를 만드는 팀이므로 그 내용은 컴파일러의 계층 구조였다. 여기에 절차적 마찰 하나를 덧붙였다. 컴파일러의 깊은 층을 건드릴 때는 에이전트가 최소한 한 사람과 상의하게 한다. 의도적으로 속도를 떨어뜨리는 장치다.
벤더별 규약 파일에 팀의 관행을 적어두는 방식은 도구가 하나일 때만 성립한다. 도구가 세 개면 규약도 세 벌이 되고, 세 벌은 반드시 서로 어긋난다. 규약을 모델 중립 형식으로 한 장에 모으면 도구 선택이 개인의 취향 문제로 격하되고, 그때 비로소 "AI 사용에 표준이 없다"는 선언이 방임이 아니라 설계가 된다.
파일을 짧게, 그리고 잘 안 바뀌는 것만 쓰라는 제약은 문서 관리 요령이 아니라 컨텍스트 예산 관리다. 모든 에이전트 호출마다 읽히는 문서라면, 길이는 곧 반복 비용이고 변동성은 곧 신뢰도 하락이다. 자주 바뀌는 규칙을 여기에 적으면 에이전트는 낡은 규칙을 근거로 자신 있게 틀린 코드를 쓴다.
두 번째 충돌은 설계 문서였다. 팀의 규칙은 단순하다. 코드는 슬롭이어도 되고 글은 슬롭이면 안 된다. 물론 규칙을 선포하는 것만으로 사람들이 손으로 아름다운 문서를 쓰지는 않는다. 그래서 팀은 문서 도구를 직접 만들었다. 노션과 깃허브가 설계 문서 용도로 하던 일을 대체하는 도구로, 버전 관리와 코멘트가 되고 뒤에서는 마크다운 파일과 간단한 CLI 스크립트로 돌아간다. 깃허브 흉내를 내지만 깃허브는 아닌 구조라, 에이전트도 같은 경로로 문서를 다룰 수 있다.
도구를 만들었다고 사람들이 쓰지는 않았다. 팀은 그 위에 알림 연동을 하나 더 얹었다. 설계 문서가 갱신될 때마다 채널에 알림이 뜨게 한 것이다. 이 채널은 곧 사내에서 가장 활발한 채널이 되었다. 새벽 두 시에 누군가 새 설계 문서를 올리면 곧바로 세 사람이 읽기 시작한다. 발표자의 설명은 담백하다. 앞으로 바뀌지 않을 것에 관한 글이 원래 가장 재미있다는 것이다.
그다음 대목이 이 발표에서 가장 정직한 부분이다. 도구를 만든 당사자가 스스로 과열되어 하루에 설계 문서를 열 건씩 쏟아냈고, 팀은 이번에는 대표의 슬롭과 싸우게 되었다. 그래서 마지막 규칙이 추가된다. 설계 문서를 올리려면 사람들이 실제로 그것을 읽게 만들 책임을 발행자가 진다. 이 규칙 이후 문서 품질이 급격히 올라갔다.
이 일화는 AI 도구 도입 조직에서 반복되는 실패 형태를 압축한다. 문서를 쓰기 어려워서 문서가 부족했던 것이 아니었다. 쓰기 비용이 사라지자 부족은 즉시 과잉으로 뒤집혔고, 병목은 작성에서 독해로 옮겨갔다. 그런데 조직의 규칙은 여전히 작성 쪽에 붙어 있었다.
팀의 처방이 흥미로운 것은 문서 수를 제한하지 않았다는 점이다. 대신 읽힘을 발행자의 비용으로 계상했다. 출력에 과금하는 대신 상대의 주의력 소비에 과금한 것이고, 그 결과 발행자는 스스로 검열한다. 문서 개수 상한이나 승인 절차 같은 통제 장치보다 이 편이 규모에 잘 견딘다.
세 번째 충돌은 아키텍처 수렴이었다. 코드베이스를 방치하면 경계가 무너진다. 팀은 여기서도 도구를 만들었다. 내부 의존성과 일부 외부 의존성을 함께 그리는 그래프 시각화 도구로, 코드베이스가 변하는 모습을 지켜볼 수 있고 패키지 단위의 의미 경계를 표시한다.
더 중요한 것은 그 위에 얹은 CLI다. 특정 불변식이 깨질 수 없음을 보장하는 검사기를 만들어두면, 에이전트가 새 패키지를 만들거나 경계를 새는 의존성을 추가한 순간 CI 또는 커밋 이력이 어디서 무엇이 깨졌는지 정확히 알려준다. 발표자는 이 장치 덕분에 지난 3~4개월간 아키텍처를 한 번도 바꾸지 않았다고 말한다.
사람이 하는 코드 리뷰는 본질적으로 확률적 표본 검사다. 변경량이 늘면 표본 비율이 떨어지고, 승인률은 올라간다. 반대로 경계 위반 검사기는 전수 검사이며 변경량이 늘어도 비용이 늘지 않는다. 즉 이 팀은 리뷰를 없앤 것이 아니라 변경량에 비례하는 검사를 변경량과 무관한 검사로 교체했다.
남는 질문은 사람에게 무엇이 남는가다. 답은 불변식을 정하는 일과 검사기를 작성하는 일이다. 이 두 가지는 위임할 수 없다. 검사기가 잘못된 불변식을 강제하면 전수 검사라는 성질이 오히려 해가 되기 때문이다. 시니어 엔지니어의 산출물이 승인 도장에서 검사기 코드로 이동한다는 뜻이며, 이것이 이 발표에서 가장 이식성이 높은 부분이다.
설계 문서와 아키텍처 검사기가 있다 해도, 프로그래밍 언어를 만드는 팀이 읽지 않은 코드를 그대로 출시할 수 있는지는 별개의 문제다. 언어에는 지켜야 할 불변식이 지나치게 많다. 제네릭, 클로저, 메모리 할당, 외부 함수 인터페이스 경계가 모두 그렇다. 발표자는 파이썬조차 25년이 지난 지금도 버그가 있다는 점을 지적하며, 신뢰의 근거를 다른 데서 찾았다고 말한다.
팀이 만든 것은 에이전트가 상시로 자기 언어의 프로그램을 작성하게 하는 시스템이다. 에이전트가 무언가를 처음부터 만들어 보게 하고, 그 과정의 대화 기록 전체를 남긴다. 어떤 도구를 어떤 순서로 호출했고 무엇이 일어났는지가 모두 남는다. 사람이 그것을 검사할 수도 있지만, 더 중요한 것은 다른 에이전트가 검사한다는 점이다.
검사의 기준이 정확성에만 있지 않다는 점이 핵심이다. 언어 문법상 무엇이 틀렸는지만 보는 것이 아니라, 한 번의 도구 호출로 끝낼 일을 세 번에 걸쳐 한 지점까지 찾아낸다. 그렇게 모인 후보 문제를 사람이 함께 걸러 어느 것이 실재하고 어느 것이 환각이며 어느 것이 취향의 문제인지 판정한다. 그리고 다시 에이전트가 수정안을 만들어 처리한다.
여기서 한 걸음 더 나아간 대목이 이 발표의 실질적 기여다. 어떤 언어 기능이 좋은지 추측하는 대신 A/B 테스트를 한다. 도구 호출 수가 적은 쪽, 오류가 적은 쪽, 올바른 결과를 낸 쪽을 측정해 결정한다. 코드를 한 줄도 쓰지 않고 데이터 기반 시스템을 만들 수 있다는 것이 발표자의 요지다. 이 방식은 이후 제품화되어, 수천 개의 시뮬레이션 에이전트를 자기 언어에 계속 던져 언어·오류 메시지·CLI·에이전트 지침 중 어디가 쓰기 어려운지 찾아내는 상시 설비로 운영되고 있다. 지침 버전별로 에이전트의 성공 속도를 비교하는 별도 페이지까지 공개되어 있다.
지금까지 언어와 API의 사용성 논쟁은 대체로 취향 싸움이었다. 좋은 오류 메시지, 직관적인 문법, 낮은 인지 부하 같은 표현은 반증이 불가능했다. 에이전트를 사용자로 두면 이 논쟁이 성립하는 방식이 달라진다. 도구 호출 횟수, 첫 시도 성공률, 재시도 횟수는 모두 세어지는 값이고, 표본을 수천 개로 늘리는 비용도 낮다.
다만 계량화에는 대가가 따른다. 최적화 압력은 측정되는 지표에만 걸리고, 지표 밖의 성질은 조용히 희생된다. 도구 호출 수를 줄이는 방향으로 언어를 다듬으면 한 번에 많은 일을 하는 큰 연산이 늘어날 수 있고, 그것은 사람이 읽을 때의 명료성이나 부분 실패 시의 진단 가능성과 상충할 수 있다. 이 발표에서 사람이 환각과 취향을 걸러내는 단계를 남겨둔 이유가 여기에 있으며, 그 단계는 자동화하기 가장 쉬운 동시에 가장 먼저 사라질 위험이 큰 지점이다.
발표의 후반은 방향을 바꾼다. 앞의 도구들로 슬롭과의 전투에서는 이길 수 있지만 전쟁에서는 질 것이라는 전망이다. 이유는 우리가 딛고 선 기반 자체가 이미 새고 있기 때문이다. 발표자가 예로 든 것은 TypeScript다.
TypeScript의 설계 목표는 정확성과 생산성 사이의 균형이다. 여기에 각주가 하나 붙는다. 그 생산성은 사람의 생산성이다. 사람이 코드를 한 줄도 쓰지 않는 세계를 전제로 언어를 설계한다면 결코 넣지 않을 기능들이 있다는 것이 그의 주장이고, 시연으로 든 것은 자바스크립트의 오래된 기본값들이다. 정렬할 때 값을 문자열로 바꿔 비교하는 동작이 대표적이다. 좋든 싫든 언어 자체에 슬롭이 박혀 있고, 그런 도구로 시스템을 만들면 시스템에도 슬롭이 남는다.
이어지는 지적은 계보에 관한 것이다. 자바스크립트가 먼저 있었고, 그 위에 CoffeeScript가, 그 위에 TypeScript가, 지금은 또 다른 계층이 얹히고 있다. 그러나 아래에 있는 것이 이미 깨져 있고 코드를 쓰는 방식마저 달라졌다면, 무엇을 위해 계속 덧대는가.
동적 타입, 암묵적 형 변환, 검사 없는 캐스팅은 결코 실수로 들어간 기능이 아니다. 사람이 타입을 손으로 적는 데 드는 시간과 학습 비용을 아끼려는 의도적 교환이었고, 사람이 코드의 유일한 저자였던 시기에는 합리적인 거래였다.
거래의 한쪽 항이 무너지면 결론도 바뀐다. 타입을 적는 비용이 사실상 0에 가까워지고 코드 작성자가 사람이 아니라면, 관용성이 절약해 주던 것은 더 이상 절약할 가치가 없고, 관용성이 허용하는 잘못된 상태는 그대로 남는다. 보조금이 순비용으로 전환되는 국면이다. 언어 설계의 손익 계산 자체가 다시 열렸다는 것이 이 발표가 던지는 가장 큰 주장이며, 뒤집어 말하면 기존 언어 생태계도 같은 계산을 다시 해야 한다는 압력을 받는다는 뜻이다.
발표 후반의 시연은 BAML을 대상으로 한다. 이 이름은 원래 LLM 호출을 타입 있는 함수로 다루는 좁은 목적의 언어에 붙어 있었으나, 지금은 튜링 완전한 범용 언어로 확장되어 있다. 공개된 설계 문서의 표현을 빌리면, TypeScript처럼 읽히면서 그 함정이 없는 언어를 지향한다. 발표에서 시연된 항목과 공개 문서에 정리된 설계 결정을 함께 놓으면 다음과 같다.
any가 없고 검사 없는 캐스팅을 쓸 수 없다. 알 수 없는 값은 기대하는 타입임이 증명된 다음에만 그 타입으로 쓸 수 있다. 조건 분기 밖에서 같은 접근을 시도하면 컴파일되지 않는다. 잘못된 상태를 표현조차 못 하게 만들면, 에이전트가 그 상태를 만들어도 출시되지 않는다는 논리다. 패턴 매칭도 같은 계열이다. typeof와 속성 존재 확인이 뒤섞이던 자리를 하나의 매칭 구문이 대신하고, 컴파일러가 모든 경우를 다뤘는지 검증한다.
발표에서 가장 강한 인상을 남긴 시연이 이 부분이다. 0으로 나누기 에러를 던지는 나눗셈 함수가 있으면, 그 함수는 자기가 무엇을 던지는지 별도 선언 없이 안다. 그 함수를 호출하는 상위 함수도 같은 에러를 던질 수 있음을 안다. 에러 유형이 추론되므로 에러를 처리했는지 여부를 컴파일러가 증명할 수 있고, 절대 에러를 던지지 않는 함수라는 계약도 검증 대상이 된다. 처리하지 않은 에러가 남아 있으면 그 계약은 성립하지 않는다고 컴파일러가 알려주고, 예외를 잡아 기본값을 돌려주도록 고치면 그 순간 계약이 성립한다. 도달할 수 없는 처리 분기가 있으면 그것도 경고로 잡힌다.
병렬 실행을 위해 함수마다 비동기 표시를 전파시키는 관행을 버리고, 경량 스레드를 띄우는 방식을 택했다. 어떤 함수든 그 자리에서 병렬로 띄울 수 있고 호출 경로 전체를 고칠 필요가 없다. 공개 문서에 실린 벤치마크는 다음과 같다.
| 실행 환경 | 소요 시간 | CPU 사용 |
|---|---|---|
| Bun, 단일 스레드 | 8.2초 | 1코어 |
| BAML, 단일 스레드 | 6.8초 | 1코어 |
| BAML, 병렬 16 | 0.87초 | 약 10코어 |
발표에서 문자열 검색 도구를 대신하겠다고 제시한 것이 정의 조회 명령이다. 함수 이름을 주면 해석된 정의, 의존 관계, 그리고 그 함수가 실제로 쓰이는 모든 위치를 돌려준다. 여러 번의 도구 호출로 재구성해야 했던 정보를 한 번에 얻는다는 것이 요지이고, 특히 참조 목록이 있으면 에이전트가 이미 있는 구현을 못 보고 비슷한 함수를 또 만드는 사고를 줄일 수 있다. 같은 방향의 결정으로, 디렉터리 구조 자체가 네임스페이스이며 임포트 구문이 없다. 변경이 국소에 머물게 해서 에이전트가 무관한 파일을 잔뜩 열어 컨텍스트를 오염시키는 일을 막는 설계다.
코드를 이해하는 마지막 수단은 실행이다. 그래서 모든 함수를 인자와 도움말이 붙은 CLI 명령으로 즉시 실행할 수 있게 했다. 파일을 만들지 않고 짧은 식을 그 자리에서 평가하는 경로도 있다. 여기서 한 단계 더 나아가면 선택한 함수들만 묶어 독립 실행 바이너리로 뽑을 수 있고, 다른 아키텍처를 대상으로 빌드할 수도 있다. 공개된 비교에서 이 바이너리는 12.1MB인데, 자바스크립트 엔진 전체를 품는 비교 대상은 63.1MB다.
발표자가 코드를 읽는 대신 보여준 것은 코드베이스 전체를 훑는 시각화였다. 클릭하면 정확한 코드 줄로 이동하고, 확대하면 더 넓은 범위를 펼치며, 어느 부분은 그냥 슬롭으로 두고 지나가겠다고 결정할 수 있다. 전부 이해하는 것이 아니라 이해할 부분을 선택하는 방식이다. 그리고 실행 중인 파이프라인에서는 전체 실행 트레이스를 얻는다. 코드를 다 읽지 않는 세계에서 코드를 이해하는 유일한 방법은 실행 트레이스이며, 프로그램의 어느 부분에 시간이 얼마나 들었는지를 보는 것이라는 주장이다. 파이썬이나 TypeScript에서 모든 것을 추적하면 감당할 수 없이 느려지지만, 처음부터 설계하면 성능 비용을 사실상 0에 가깝게 만들 수 있다는 설명이 따라붙는다. 그리고 그 추적 시스템은 사람만 쓰는 것이 아니라 에이전트가 순회하며 버그와 비효율을 찾아 스스로 최적화하는 입력이 된다.
발표자는 새 언어를 권하는 사람에게 돌아오는 반론을 스스로 꺼낸다. 새 언어는 새로운 문제 한 무더기를 가져온다는 것이다. 세상의 모든 코드를 새 시스템으로 옮겨 쓰라고 요구하면 슬롭과의 전쟁에서 진다는 판단 아래, 팀은 2년 전부터 다른 경로를 준비했다. 파이썬, TypeScript, Rust, Go, 루비, 자바 등 기존 언어 안에서 BAML 함수를 그대로 호출하는 방식이다. 시연에서는 파이썬에서 함수를 타입 안전하게 호출하고, 동기와 비동기 두 형태를 모두 얻었다. 나아가 언어 경계를 넘어 람다와 클로저, 제네릭을 넘기는 것까지 보여준다. 타임아웃을 보장하는 함수에 파이썬 람다를 넘기는 식이다. 요점은 엔지니어가 경계 문제로 씨름하지 않게 하는 것이고, 더 중요하게는 에이전트가 무언가를 할 때 타입 시스템이 거짓말하지 않는 유일한 기준점으로 남게 하는 것이다.
임포트 없는 네임스페이스, 정의 조회 명령, 함수 단위 실행, 국소적 편집, 짧은 아키텍처 파일은 서로 다른 기능처럼 보이지만 목적이 하나다. 에이전트가 판단에 필요한 사실을 얻기 위해 파일을 통째로 읽지 않게 하는 것이다. 지금까지 언어 설계의 제약은 실행 성능, 컴파일 시간, 메모리, 사람의 학습 곡선이었다. 여기에 한 번의 판단에 몇 토큰이 필요한가라는 항목이 추가되었다.
이 항목은 기존 언어에 사후적으로 붙이기가 매우 어렵다. 임포트 구문을 없애거나 참조 그래프를 언어 차원에서 보장하는 일은 문법과 모듈 시스템의 근간에 손대는 작업이기 때문이다. 새 언어가 주장할 수 있는 우위가 있다면 문법의 우아함보다 이쪽일 것이다.
발표의 논지는 일관되지만, 근거의 성질은 항목마다 다르다. 구분해 두는 편이 낫다.
먼저 표본의 특수성이다. 이 팀이 만드는 것은 컴파일러다. 한 번 잘못 정한 설계를 한 달 뒤나 1년 뒤에 바꿀 수 없고 매번 정확히 같게 동작해야 하는 대상이며, 발표자 본인이 슬롭이 들어설 여지가 전혀 없는 영역이라고 표현한다. 이런 도메인에서는 불변식이 사전에 존재하고 명문화도 가능하다. 반면 요구사항이 분기마다 흔들리는 업무 시스템에서는 불변식 자체가 협상 대상이며, 검사기를 쓰려면 그 협상을 먼저 끝내야 한다. 코드 리뷰를 없애는 부분만 떼어 옮기면 검사기 없는 무검증 상태가 된다.
다음은 수치의 출처다. 8명 규모로 2년 안에 안정적인 언어를 냈다는 것, 한 엔지니어가 하루 만에 부분적인 C 컴파일러를 이 언어로 만들었다는 것은 모두 발표자 본인의 진술이며 외부 검증이 불가능하다. 반대로 언어의 기능 목록과 벤치마크 수치는 공개 문서에 명시되어 있어 확인이 가능하다.
세 번째는 성숙도다. 이 언어는 스스로 1.0 이전이라고 밝히고 있다. 패키지 관리자가 아직 없어서, 의존성과 공급망 위험이 한 갈래 줄어드는 대신 재사용 가능한 패키지 배포 방식은 여전히 설계 중이다. 발표 뒤에도 여러 기능은 예정 상태로 남아 있다. 생성된 코드를 기대하는 시그니처에 맞춰 컴파일하고 타입 오류를 에이전트에게 되돌려주는 반사 기능, 실행 범위 안에서 네트워크나 셸 호출을 대체하는 범위 한정 모킹은 공개 문서가 방향만 제시한 미구현 항목으로 표기하고 있다.
네 번째는 평가의 순환이다. 자기 도구로 자기 언어를 평가하는 설비는 언어의 사용성을 측정하지만 프로그램의 정확성을 측정하지는 않는다. 에이전트가 더 빨리 성공하는 언어와 사람이 나중에 유지보수할 수 있는 언어는 같은 값이 아니며, 지금 공개된 지표는 전자에 관한 것이다.
발표는 특정 도구를 따라 만들라는 권유로 끝나지 않는다. 각자 돌아가서 이런 엉성한 내부 도구를 만들라는 것, 그리고 용감한 사람은 기반 계층이 어디서 깨져 있는지 다시 생각해 보라는 것이 결론이다. 새로운 버전 관리 시스템, 새로운 데이터베이스, 새로운 프로그래밍 언어가 필요하다는 주장으로 발표를 닫는다. 여기서 몇 갈래의 전망을 끌어낼 수 있다.
가장 먼저 움직일 것은 사람의 역할이다. 변경량이 계속 늘어나는 조건에서 사람의 승인은 병목이자 형식이 된다. 그 자리를 대체하는 것은 불변식을 정하는 일, 검사기를 작성하는 일, 그리고 트레이스를 읽는 일이다. 시니어 엔지니어의 성과 지표가 리뷰 건수에서 검사기 커버리지로 옮겨가는 조직이 먼저 나타날 것으로 본다. 지금 사내 도구를 자체 제작한 이 팀의 방식이 곧 상용 도구로 흡수될 개연성도 높다. 의존성 경계 검사와 에이전트 기록 분석은 특정 언어에 종속되지 않는 기능이기 때문이다.
기반부터 다시 만들자는 주장은 설득력이 있지만, 언어 채택의 역사적 기저율은 신규 언어에 불리하다. 성공한 사례들은 대개 기존 자산을 버리지 않게 해 준 경우였고, 그 점에서 이 언어의 승부처는 문법이 아니라 기존 언어에서 호출되는 경계다. 한 함수씩 옮길 수 있다는 점, 생성된 타입이 파이썬의 데이터 모델로 그대로 나타난다는 점이 실제 채택 곡선을 결정할 것이다.
동시에 반대 방향의 압력도 예상된다. 기존 생태계는 언어를 바꾸는 대신 엄격 모드, 타입 게이트, 린트 규칙, 에이전트 전용 하위 집합으로 방어할 것이다. 수적으로는 이쪽이 다수 시나리오가 된다. 흥미로운 지점은 그 방어의 설계도 결국 이번 발표가 지적한 항목들을 따라간다는 것이다. 검사 없는 캐스팅 금지, 예외의 타입화, 도달 불가 분기 경고는 새 언어의 전유물이 아니다.
에이전트 성공률과 도구 호출 수가 공개 지표로 자리 잡으면, 언어와 프레임워크는 그 숫자로 경쟁하게 된다. 그 결과는 양면적이다. 반증 가능한 논의가 가능해지는 것은 이득이고, 지표에 과적합된 설계가 등장하는 것은 손실이다. 벤치마크가 공개되고 스스로를 그 위에서 평가하는 설비까지 공개된 지금, 다음 단계는 제3자가 같은 척도로 여러 언어를 비교하는 시도가 될 것이며 그때부터 이 논의가 검증 가능해진다.
가장 크게 남는 문제는 발표가 스스로 답하지 않은 부분이다. 사람이 코드를 읽지 않는 관행이 정착하면, 사고가 났을 때 원인을 규명하는 능력이 조직에서 서서히 사라진다. 실행 트레이스와 프로파일러가 그 능력을 대체할 수 있다는 것이 이 발표의 베팅이고, 컴파일러가 어떻게 동작하는지 모르면서도 우리는 이미 컴파일러를 신뢰하고 있다는 비유가 그 근거로 제시된다. 코드는 신뢰의 문제이며, 생성된 코드를 아직 신뢰하지 못하는 이유는 그 아래의 시스템이 충분히 견고하지 않기 때문이라는 것이다.
비유는 정확하지만 조건이 하나 빠져 있다. 컴파일러에 대한 신뢰는 수십 년의 사용 이력과 광범위한 테스트, 그리고 무엇보다 결정론적 동작 위에 쌓인 것이다. 아직 1.0에 이르지 않은 언어와 확률적으로 출력을 만드는 모델의 조합에 같은 수준의 신뢰를 배정할 근거는 아직 축적되지 않았다. 그 축적을 앞당기려는 시도가 바로 수천 개의 에이전트를 상시로 던지는 설비이며, 그 설비가 실제로 신뢰를 대신 쌓아 줄 수 있는지가 이 노선의 성패를 가른다.
이 발표에서 가져갈 것은 특정 언어의 선택이 아니다. 코드 리뷰를 없애도 되는 팀이 있다는 결론도 아니다. 검증이라는 기능은 사라지지 않고 어딘가로 이동해야 하며, 그 이동처를 정하는 일은 여전히 사람의 몫이라는 것이다. 이동처를 정해 두지 않은 채 리뷰만 없애면 남는 것은 슬롭이고, 이동처를 정해 두면 읽지 않은 코드도 자산이 된다. 지금이 코드베이스에 슬롭이 가장 적은 시점이라는 발표자의 말은 경고가 아니라 일정 통보에 가깝다.