Path to Raku — 19년 쓴 이름을 바꿀 때, 무엇을 세는가
2019년 8월, Elizabeth Mattijsen이 이슈를 올렸다. 제목은 「Perl 6이라는 이름에 담긴 Perl이, 혼란을 부르고 짜증나게 한다」. 10월, Larry Wall이 개명을 승인한다. 그리고 공개된 이행 계획서 Path-to-Raku.md는, 개명을 선언이 아니라 체크리스트로 만들었다. 파일 확장자, 환경 변수, IRC, 해시태그, 301 리다이렉트, 그리고 언어 사양 안에 묻혀 있던 이름.
지난번, 이름이 부채가 되는 조건을 썼다. 이번에는 상환의 작업 이야기다.
이번 회의 소재는 다행히도, 전부 공개되어 있다. 이슈도, 논의도, 이행 계획서도, GitHub에서 읽을 수 있다. 「19년 쓴 이름을 바꾼다」는 작업의 일차 자료가 남아 있는 것은, 상당히 드물다.
problem-solving이라는 저장소
Perl 6 커뮤니티는, 언어나 커뮤니티의 큰 문제를 논의하기 위한
전용 저장소 perl6/problem-solving(현 Raku/problem-solving)을 가지고 있었다.
구조는 2단계로 되어 있다.
- 이슈로 「문제」를 제기한다
- 합의가 형성되면
solutions/아래의 문서로 해결책을 쓰고, PR을 낸다
문제와 해결책을 나누는 것이, 이 구조의 핵심이다. 「무엇이 문제인가」로 합의한 뒤에 「어떻게 풀 것인가」를 논의한다.
이것 자체가, 참고할 만한 거버넌스의 형태라고 생각한다. 기술적인 논의는 종종, 문제에 대한 합의가 없는 채로 해결책을 다투는 것으로 무너진다. 「당신의 안에 반대다」가 「애초에 문제라고 생각하지 않는다」인지 「문제지만 푸는 법이 다르다」인지, 구별되지 않은 채 진행된다.
Issue #81
2019년 8월, Elizabeth Mattijsen(lizmat)이 이슈를 올렸다. 제목은 이렇다.
“Perl” in the name “Perl 6” is confusing and irritating (「Perl 6」이라는 이름에 담긴 “Perl”이, 혼란을 부르고, 짜증나게 한다)
문제로 제기된 것은, 이름 그 자체가 아니다. 이름에 담긴 “Perl”이라는 말이다.
이것은 정확한 문제 설정이었다. 지난번 쓴 대로, 부채를 낳고 있던 것은 「6」이라는 숫자만이 아니라, 「Perl」+「6」이라는 조합이 실어 나르는 「Perl 5의 다음 버전」이라는 주장이었기 때문이다.
이 이슈는 큰 논의가 되었다. 찬성도 반대도 나왔다. 그리고 최종적으로, 이름을 나눈다는 방향으로 합의가 형성된다.
후보 이름이 여럿 있던 가운데, Raku가 선택되었다. 1화에서 쓴 대로, 처리계 이름 Rakudo(駱駝道 / 楽土)에서 유래한 이름이다. 이미 10년 넘게 쓰여 온 이름의 일부를 취한다는 선택으로, 완전히 새로운 말을 만드는 것보다 연속성이 있다.
Larry Wall의 승인
2019년 10월, Larry Wall이 개명 PR을 승인했다.
그때 인용한 것이, 새 포도주를 낡은 가죽부대에 담아서는 안 된다는 성서의 비유다.
I am in favor of this change, because it reflects an ancient wisdom…
새 술에는 새 부대가 필요하다 — 새로운 언어에는 새로운 이름이 필요하다, 는 논리다.
여기가 중요한 것은, 창시자 자신이 「이것은 Perl 5의 연속이 아니다」라고 인정한 점이다. 지난번 쓴 「개명은 패배로 보인다」「창시자가 붙인 이름이었다」는 19년 정체의 이유 둘이, 이 하나의 승인으로 동시에 풀렸다.
Path-to-Raku.md — 이행 계획서
합의 후, solutions/language/Path-to-Raku.md로 구체적인 이행 절차가 쓰였다.
이 문서의 가치는, 개명을 「선언」이 아니라 「실행 가능한 체크리스트」로 만든 데 있다.
「이름을 바꾸기로 했습니다」로 끝내지 않고, 어디에 이름이 묻혀 있는지를 열거하고, 언제 무엇을 할지를 정했다.
단계를 끊었다
| 단계 | 내용 |
|---|---|
| 합의 직후 | 문서의 문구 치환, 저장소 이름 검토, IRC 채널, 도메인의 301 리다이렉트 |
| 6.e 전후 | 파일 확장자의 변경, 새로운 명명 규약의 채용 |
| 6.f | 옛 확장자 · 옛 환경 변수에 비권장 경고 |
| 6.g | 비권장인 것을 삭제 |
한 번에 전환하지 않고, 언어 버전의 구획에 맞춰 단계적으로 옮긴다.
이것은 8화에서 쓴 「릴리스란 약속이다」의 응용이다.
파괴적인 변경은, 약속의 이음매에 둔다.
6.f에서 경고를 내고, 6.g에서 지운다. 사용자는 자기 코드에 use v6.e;라고 쓰여 있으면,
언제 무엇이 일어날지를 예측할 수 있다.
호환성을 끊고 15년이 걸린 경험을 가진 커뮤니티다운 판단이다.
이름이 묻혀 있던 곳
계획서가 열거한 곳을, 층별로 다시 늘어놓으면 이렇게 된다.
언어 사양 안
| 대상 | 옛 | 새 |
|---|---|---|
| 메서드 | .perl |
.raku |
| 동적 변수 | $*PERL |
$*RAKU |
| 클래스 | Perl |
Raku |
여기가 가장 의외인 곳이다. .perl은, 값을
「그대로 평가하면 원래대로 돌아오는 문자열」로 만드는 메서드다
(Ruby의 inspect, Python의 repr에 해당).
언어 이름이, 메서드 이름으로서 문법 안에 묻혀 있었다. 그래서 개명은 언어 사양에까지 미쳤다.
파일시스템
| 종류 | 옛 | 새 |
|---|---|---|
| 스크립트 | .p6 / .pl6 |
.raku |
| 모듈 | .pm6 |
.rakumod |
| 문서 | .pod6 |
.rakudoc |
| 테스트 | .t6 |
.rakutest |
실행 환경
| 대상 | 옛 | 새 |
|---|---|---|
| 라이브러리 경로 | PERL6LIB |
RAKULIB |
| 설치 위치 | PERL6_HOME |
RAKUDO_HOME |
| 실행 파일 | perl6 |
rakudo(raku / perl6은 symlink) |
네트워크와 커뮤니티
| 대상 | 변화 |
|---|---|
| 도메인 | perl6.org → raku.org, docs.perl6.org → docs.raku.org(301 리다이렉트) |
| GitHub org | perl6/ → Raku/ |
| IRC | #perl6* → #raku* |
| 해시태그 | #perl6 → #rakulang |
| 모듈 | 저자에게 저장소 이름 · README · META6.json의 갱신을 권장 |
301을 골랐다
사소하지만, 실무적으로 중요한 판단이 있다. 옛 도메인의 리다이렉트에 301 Moved Permanently를 고른 것이다.
302(일시적)가 아니라 301(영구적)로 함으로써, 19년 분량의 피링크 평가를 새 도메인으로 이어받으려 하고 있다.
지난번 「검색이 분단되었다」고 썼다. 그것은 완전히는 막지 못했지만, 막으려 한 흔적이 여기에 있다. 문서의 URL도 동등한 새 URL로 리다이렉트하고, 왜 이동했는지를 설명하는 페이지를 준비하고 있다.
갑자기 깨뜨리지 않는다
호환성에 대한 배려도 명기되어 있다.
perl6실행 파일은 symlink로 남긴다$*PERL/Perl클래스는 당분간$*RAKU/Raku의 별칭으로- 확장자의 변경은 6.e에 맞추고, 경고는 6.f, 삭제는 6.g
「오늘부터 전부 바꾼다」가 아니다.
개명이란 무엇을 하는 작업인가
여기서 일반화한다. 이 연재의 열한 번째 형이다.
개명은 「이름을 바꾸는 작업」이 아니라, 「이름이 묻혀 있는 곳을 전부 세는 작업」이다.
Path-to-Raku.md의 가치는, 바로 그 열거에 있다. 세어 보면, 이름은 6개의 층에 묻혀 있었다.
- 언어 사양(
.perl메서드,$*PERL,Perl클래스) - 실행 환경(환경 변수, 실행 파일 이름, 설치 경로)
- 파일시스템(확장자)
- 네트워크(도메인, 리다이렉트)
- 커뮤니티(IRC, 해시태그, 조직 이름, 콘퍼런스 이름)
- 생태계(모듈 이름,
META6.json, README, 서적, 과거의 기사)
그리고 6번째는 자신들의 관리 아래에 없다. 남의 저장소, 남의 블로그, 출판된 서적. 개명 작업은, 자신이 바꿀 수 있는 범위에서 끝나지 않는다.
이 절차는 재사용할 수 있다
이것은 개명에 한정되지 않는다. 큰 파괴적 변경을 실시할 때의 절차로서, 열거 → 층별로 분류 → 단계를 끊는다 → 호환의 기한을 정한다는 그대로 쓸 수 있다.
반대로 말하면, 열거를 하지 않은 채 단계만 끊으면 실패한다. 「우선 쉬운 곳부터」라고 시작해서, 언어 사양 안에 이름이 묻혀 있었다는 것을 나중에 알아차리는, 하는 형태로.
조직의 이름도 움직였다
개명은 언어만으로 끝나지 않았다.
| 대상 | 변화 |
|---|---|
| The Perl Foundation | **The Perl and Raku Foundation(TPRF)**이라는 별칭을 채용(정식 등록은 2022년 여름으로 알려짐) |
| 콘퍼런스 | The Perl Conference → The Perl and Raku Conference |
| 거버넌스 | Raku Steering Council을 설치(최초 선거는 2020년, 투표는 9월 20일 마감) |
재단도 콘퍼런스도, 분리가 아니라 병기를 골랐다. 「별개의 언어지만, 같은 가족」이라는 것이, 개명 후의 공식적인 관계다.
그리고 Raku Steering Council의 설치는, 개명과 나란히 중요한 변화였다. 그때까지 Larry Wall이라는 BDFL에 묶여 있던 의사 결정이, 선거로 뽑히는 합의체로 옮겨졌다.
흥미로운 것은, Perl 5 쪽에서도 같은 시기에 같은 일이 일어나고 있다는 점이다. Perl Steering Council이 만들어져, pumpking(개인인 릴리스 책임자) 체제에서 합의제로 이행했다.
2019~2021년에, 두 언어가 각각, 창시자 / 개인에서 합의제로 옮겼다.
개명이 일으킨 것인지, 같은 세대교체가 양쪽에 온 것뿐인지는, 단정하지 않는 편이 좋다. 다만 같은 형태의 변화가 양쪽에서 일어난 것은 사실이다.
다음 회(11화): 정규표현식을 언어 기능으로 승격시킨다. 여기서부터는 언어로서의 Raku 이야기다. grammar — Raku에서 가장 다른 언어에 없는 것을 본다.