Blade에서 Raku로, 코드베이스 전체를 바꾼 토요일 리네이밍

이름은 약속이다. Raku, 즉 편안함과 안락함과 사람의 손길은 AI 경험이 기계적이지 않고 사람답게 느껴지도록 만들어진 런타임 뒤에 있는 약속이다. 이번 주말 그것이 현실이 되었다.

이 런타임은 내가 만들기 시작했을 때부터 이름이 있었다. 그 이름은 임시였다. 이름 걱정을 멈추고 코드를 쓰기 시작할 수 있게 해주는 그런 종류의 임시 이름이었다. 고를 때부터 그것이 임시라는 것을 알고 있었다. 진짜 이름은 몇 가지가 정리되기를 기다리고 있었다.

이번 주말 그 임시 이름이 벗겨졌다. 이제 이 런타임은 Raku다.

왜 지금인가

세 가지 이유가 있다.

제품 타깃이 안정되었다. 런타임이 AR1+였다가 그다음 AR2 Gen1이었다가 그다음에는 세 가지 서로 다른 하드웨어 경로 중 하나가 될 수도 있었을 때, 디바이스 계열을 따라 이름을 짓는 것은 말이 되지 않았다. 이제 AR 피벗이 자리를 잡았으니, 엔진은 어떤 디바이스에 출시되는지에 의존하지 않는 자신만의 이름을 가질 수 있다.

파트너십 대화가 진지해지고 있다. 진지해지는 파트너십 대화는 코드베이스 안의 임시 이름을 견디지 못한다. 벤더들은 어떤 파일에서는 “BladeRuntime”이라 부르고 다른 파일에서는 “AR1+Runtime”이라 부르는 코드와 파트너십을 맺지 않는다. 리네이밍은 그 대화들이 더 진전되기 위한 전제 조건이다.

브랜드는 뭔가 의미를 가져야 한다. Raku(楽)는 일본어로 편안함, 안락함, 즐거움을 뜻한다. 또한 기계적 정밀함보다 불규칙함과 사람의 손길을 중시하는 일본 다도 도자기 전통의 이름이기도 하다. 이 두 가지 모두 엔진이 무엇을 위한 것인지에 대한 신호다. 만들기 쉽고 기계적이지 않고 사람답게 느껴지는 경험. 한자 楽는 로고에 등장한다. 이 이름 선택은 임의적인 것이 아니다. 회사 정체성의 첫 조각이다.

리브랜딩이 포함한 작업

코드베이스 전체를 훑는 작업이었다. PR 두 개가 연속된 에이전트 실행으로 대부분을 처리했다. 에이전트들이 단순 반복 작업을 처리했는데, 이는 좋은 일이었다. 그 반복 작업이 엄청났기 때문이다. 대략 다음과 같다.

• 코드, 문서, CI에서 “ar1-runtime”에 대한 모든 참조가 “raku-runtime”으로 변경됨
• 브랜딩과 패키징에서 “Blade”에 대한 모든 참조가 “Raku”로 변경됨
• 네이티브 런타임 라이브러리 이름이 ar1plus에서 raku로 변경됨
• 모든 익스포트된 심볼 접두사 업데이트
• 모든 CMake 타깃 이름 업데이트
• 모든 include 경로 참조 업데이트
• 모든 문서 상호 참조 업데이트
• 모든 샘플 앱 readme 업데이트
• 로고와 브랜드 자산 교체

PR 두 개. 그 사이에 대략 백열 개 파일이 손질되었다. 둘 다 빌드를 깨지 않고 머지되었는데, 그것이 중요한 지표였다.

이 방식으로 작업하며 배운 것

각각 에이전트가 만든 코드베이스를 훑을 계획인 사람에게 유용한 세 가지다.

에이전트는 내가 하는 것보다 리네이밍을 더 빠르게 처리하지만, 이슈가 정확할 때만 그렇다. 대부분의 리네이밍을 만들어낸 이슈는 정확히 어떤 심볼이 바뀌는지, 어떤 경로가 바뀌는지, 어떤 문서가 바뀌는지, 그리고 어떤 패턴은 건드리지 말아야 하는지(체인지로그 항목, 과거 결정 기록, 아카이브된 브랜치)를 명시했다. 에이전트는 지시를 따랐다. 결과는 깔끔한 리네이밍이었다. 이틀 전에 시도했던 버전의 이슈는 덜 정확했고, 리네이밍은 에이전트가 지나치게 공격적으로 이름을 바꾼 서른 군데와 함께 돌아왔는데, 여기에는 고고학적 목적으로 남아 있어야 했던 오래된 커밋 메시지 속 참조들도 포함되어 있었다.

리네이밍 PR은 모든 것을 건드리더라도 작게 유지되어야 한다. 리네이밍을 수행한 두 PR은 미묘하지 않았다. 각각 수십 개의 파일을 건드렸다. 하지만 딱 한 가지 일만 했다는 의미에서 작았다. 각 PR은 리네이밍만 있었고, 기능적 변경은 섞이지 않았다. 리네이밍에 기능적 변경 단 하나라도 섞으면 PR을 리뷰할 수 없게 되는데, 인간 리뷰어가 기능적 변경이 정말로 기능적 변경일 뿐인지 확인하기 위해 모든 줄을 읽어야 하기 때문이다. 순수한 리네이밍은 15분 안에 리뷰할 수 있다.

리네이밍이 출시되기 전에 브랜드가 준비되어 있어야 한다. 이번 주말 작업의 절반은 코드베이스 안에 있지 않았다. 새 이름을 고르고, 도메인을 등록하고, 핸들을 확보하고, 한자를 제대로 맞추고, 로고를 디자인하는 일이었다. 코드베이스 리네이밍은 마지막 단계이지 첫 단계가 아니다. 코드베이스 리네이밍을 하고 나서 브랜드가 아직 끝나지 않았다는 것을 깨닫는다면, 또 한 번의 리네이밍 라운드에 발이 묶이게 된다.

바뀌지 않은 것

아키텍처는 바뀌지 않았다. C API는 바뀌지 않았다. 로드맵은 바뀌지 않았다. 제품 타깃은 바뀌지 않았다. 리네이밍 전 주말과 후 주말에 코드베이스를 읽는 사람이라면 같은 일을 하는 같은 엔진을 볼 것이다.

이것이 옳은 종류의 리네이밍이었다. 리다이렉션이 아니라 이름표 변경이었다.

파트너와 빌더가 이 글에서 가져갈 것

지금 이 런타임을 보고 있는 통합 담당자라면, 우리 레포와 패키징에서 “raku-runtime”이 보이는 곳은 어디든 지난 주말까지 다른 이름으로 불리던 그 같은 엔진이다. 호환성 손상은 없다. C API는 변경되지 않았다. SDK 바인딩은 변경되지 않았다. 샘플 앱도 여전히 작동한다.

이 엔진 위에서 출시할 제품 파트너십을 찾고 있다면, 이제 이름은 안정적이다. 대화가 “지금은 이렇게 부르고 있는데,”로 시작할 필요가 없다. “Raku가 무엇이고 무엇을 위해 만들어졌는지 소개하겠다”로 시작할 수 있다.

당신이 AR2 디바이스 팀 내부에서 어떤 런타임을 자사 플랫폼의 타깃으로 삼을지 고민하고 있다면, 이 이름 변경은 이 엔진이 시장에서 어디에 자리 잡고 있는지에 대한 하나의 선언이기도 하다. Raku는 “다 큰 AR1+ 런타임”이 아니다. 그것은 자신만의 논제를 가진 독자적인 것이며, 어떤 하드웨어 파트너가 가장 잘 맞든 그곳에 출시할 의향이 있다. 이 리네이밍은 그 선언의 일부다.

기능적으로 아무것도 바뀌지 않았다는 의미에서 조용한 주말이었다. 옳은 종류의 조용함이었다.