2026년의 Raku — 20년 전에 시작된 언어가, 지금 토대를 갈아 끼우고 있다

이 기사의 사실 확인은 2026년 9월 18일 시점. 마지막 화는 「현재」를 다루므로, 가장 빨리 낡는다. 판 · 일정 · 상황은 rakudo.org와 Rakudo Weekly News에서 확인해 주었으면 한다. 이 주석 자체가, 이 회의 주제의 일부다.

토대를 갈아 끼우는 중

2026년, Raku에서 가장 큰 사건은 새 기능이 아니다. 컴파일러의 토대의 교체다.

이름은 RakuAST.

Rakudo의 컴파일러의, 구문 분석부터 코드 생성까지의 앞단을 다시 만든 것으로, 새로운 grammar를 가지고, Raku의 프로그램을 명시적인 AST(추상 구문 트리)로 나타내는 층을 가진다.

종래의 Rakudo는, 파싱 중에 컴파일러의 중간 표현을 직접 조립하고 있었다. RakuAST는 그 사이에 한 단을 끼운다.

⚠️ 부르는 법이 흔들린다. 공식 공지에서도 「새로운 backend」라고 쓰이는 일이 있지만, 기능적으로는 컴파일러의 프런트엔드의 쇄신이다. 기사로 쓸 때는 「새로운 컴파일러 기반」처럼 역할로 쓰는 것이 안전하다.

왜 만들었는가

Jonathan Worthington이 2020년에 착수했다. The Perl Foundation의 지원을 받은 보조금 프로젝트다.

6화와 11화에 나온 이름이다. 6model을 만들고, MoarVM을 만들고, Cro를 만든 인물이다. Raku의 기술 기반은, 상당 부분이 이 사람의 일로 설명할 수 있다.

동기는 이랬다.

• 중간 표현이 암묵적이어서, 최적화를 넣을 자리가 없었다
• 구문 트리를 객체로 다룰 수 없어서, 매크로나 구문의 내성(introspection)을 구현할 수 없다
• 컴파일러의 구조가 이해하기 어려워, 기여의 장벽이 되고 있었다

즉 「빠르게 한다」보다 먼저, 「손댈 수 있는 형태로 만들기」 위한 공사다.

여기에, 연재를 통해 말하고 싶었던 것의 하나가 있다.

최적화를 넣기 전에, 최적화를 넣을 자리를 만드는 공사가 필요한 경우가 있다.

그리고 그 공사에 6년이 걸렸다. 산출물이 「전과 똑같이 동작하는 것」을 목표로 하는 6년이다. 8화에서 쓴 「15년」과 같은 종류의 시간이다. 밖에서 보면 진척이 보이기 어렵다.

2026년의 일정

시기	내용
2026.09(9월 26일 예정)	RakuAST가 기본값이 된다. 구 기반은 RAKUDO_LEGACY=1로 쓸 수 있다
6.e 릴리스 시(2026년 내 예정)	구 기반을 완전히 삭제

단계를 끊는 법에 낯이 익을 것이다. 10화의 Path-to-Raku.md와 같은 형이다.

기본값을 전환 → 구 버전을 환경 변수로 남긴다 → 판의 구획에서 삭제.

호환성을 끊고 15년을 잃은 경험은, 이 커뮤니티에 파괴적 변경의 작법으로 남아 있다.

무엇이 바뀌고, 무엇이 바뀌지 않는가

바뀌지 않는다 — 이용자가 보는 Raku의 언어 사양은 바뀌지 않는다. 기존 코드가 그대로 돌아가는 것이 목표이며, 생태계의 모듈에 대한 대규모 테스트가 이루어지고 있다.

바뀐다 — slang(문법 확장)은 손볼 필요가 있다. 11화에서 쓴 대로, Raku는 사용자가 문법을 확장할 수 있다. 그 문법의 구조가 바뀌므로, 옛 grammar에 의존한 확장은 그대로는 돌아가지 않는다.

문법을 열기로 정한 언어는, 문법을 바꿀 때 이중의 비용을 치른다. 11화 마지막에 쓴 대가가, 지금 실제로 청구되고 있다.

매크로에 대해 — 여기는 틀리기 쉽다

RakuAST는 매크로 구현의 전제가 되는 기반이다. 그러나 매크로는 6.e에는 들어가지 않는다(2026년 9월 시점의 전망).

「RakuAST가 오니까 매크로를 쓸 수 있다」고 쓰면 오류가 된다. 정확히는 「매크로를 구현할 수 있는 토대가 생겼다. 매크로 자체는 앞으로」.

2026년의 Raku를, 정확히 쓴다

이 연재의 집필 규칙 2조에 이렇게 썼다.

「흥하고 있다」고도 「끝났다」고도 쓰지 않는다. 둘 다 평가이지 사실이 아니다.

그러면 사실은 무엇인가. 표로 만든다.

항목	2026년 9월 시점의 상태
언어 버전	6.d가 기본값. 6.e는 연내 예정, 미릴리스
처리계	Rakudo. 2026.08이 Release #196
컴파일러 기반	2026.09에서 RakuAST가 기본값으로
VM	MoarVM이 사실상 유일
구현의 수	3. Rakudo에 더해, 2026년에 mutsu(Rust)와 Raku++(C++17)가 나타났다
거버넌스	Raku Steering Council
생태계	zef(fez / rea), raku.land. 규모는 작지만 계속
전용 IDE	Comma는 개발 종료
Perl(5 계열)	5.44(2026-07-15). Perl 7은 미릴리스

이 표에서 말할 수 있는 것을 다섯 줄로 정리한다. 이것이 이 연재의 답이다.

1. 월간 릴리스가 196회 계속되고 있다. 계속의 가장 강한 증거다
2. 6년에 걸친 컴파일러 기반 쇄신이 완료되어 가고 있다. 유지보수가 아니라 전진하고 있다
3. 규모는 작다. 전용 IDE는 사라졌고, 모듈 수는 적다
4. 언어 사양은 다음 판으로 향하고 있다. 멈추지 않았다
5. 10년 만에, Rakudo 이외의 구현이 돌아가고 있다. 다음 절에서 다룬다

이 다섯 줄을 나란히 쓰는 것이, 2026년의 Raku에 대한 정확한 기술이다. 어느 한 줄만 인용하면 흥하고 있는 것처럼도 끝난 것처럼도 쓸 수 있다. 그래서 나란히 쓴다.

10년 만에, Rakudo 이외의 구현이 돌아가고 있다

이 연재를 쓰는 도중에 알게 된 것이므로, 정직하게 순서대로 쓴다. 7화에서 「두 번째 구현이 떠난 손실」이라고 썼다. 그 직후에, 두 개가 나타나 있었다.

구현	저자	언어	방식	시작
mutsu	tokuhirom	Rust	바이트코드 VM	2026-02
Raku++(rakupp)	ash	C++17(외부 의존 없음)	손으로 쓴 어휘 · 구문 분석 + 트리 워킹 평가기	2026-07

둘 다 Rakudo의 포크가 아니라, 처음부터 쓰였다. 그리고 양쪽 다 Artistic-2.0, 즉 Perl / Raku와 같은 라이선스를 골랐다.

적합도는 roast로 측정된다

	roast 파일 완전 통과(1,464 중)	개별 테스트
mutsu	1,433(97.9%)	—
Raku++	676(46%)	200,843 / 약 219,610(91%)

이 표가 성립한다는 것 자체가, 7화 주제의 귀결이다.

「Raku를 준수한다」가 주장이 아니라 숫자가 되는 것은, 사양을 산문에서 테스트 스위트로 옮겼기 때문이다. 만약 사양이 Synopsis인 채였다면, 이 두 프로젝트는 「얼마나 Raku인가」를 스스로 신고할 수밖에 없었다.

생태계를 재는 법도 정직하다

양쪽 다 「roast를 통과한다」만으로는 부족하다는 것을 알고 있어서, 실제 모듈이 돌아가는지를 따로 측정하고 있다.

• mutsu: 1,624 distribution 중 **41.2%**가 「rakudo가 통과시키는 모든 테스트 파일」을 통과
• Raku++: 2,529 중 1,006이 자신의 테스트를 통과. 다만 같은 머신에서 Rakudo를 돌리면 1,791밖에 도달 가능하지 않다 (나머지 738은 libgsl · fontconfig · 네트워크가 없어 누구도 통과시킬 수 없다). 그래서 1,006은 「도달 가능의 56%」다.

분모를 먼저 재고 나서 비율을 낸다. 숫자를 다루는 작법으로서 옳다.

개발의 속도

mutsu는 2026년 2월에 시작해, 7개월 반 만에 12,266 커밋 · PR 8,700건 이상에 도달했다. 하루에 약 55 커밋이다.

브랜치 이름을 보면 claude/raku-line-profiler-design-… 같은 형태가 늘어서 있어, 대규모 AI 지원 개발임을 알 수 있다. 다만 엉성하지 않다. 최근 커밋에는 이런 것들이 늘어선다.

docs(adr): record ADR-0106's gates as measured after Slice 2
docs(adr): record the three corrections ADR-0106 Slice 2 forced

ADR로 설계를 남기고, 슬라이스로 쪼개고, 게이트를 실측으로 기록하고, 「구현이 강제한 정정」을 문서로 남기고 있다.

5화에서 이렇게 썼다.

구현은, 읽어서 알 수 있는 오류와는 다른 종류의 오류를 낸다.

mutsu는 그 정정을 버리지 않고 기록하고 있다. Pugs가 roast를 시작한 것과, 형태가 닮았다.

grammar가, 처음으로 밖으로 나가려 하고 있다

Raku++는 내세우는 문구로 이렇게 쓴다.

Raku의 grammar는 .raku 파일 그대로이고, 임의의 호스트 언어가 그것을 구동할 수 있다 — 그에 상당하는 것은 다른 어느 것도 가지고 있지 않다

C API를 하나 마련하고, C++ / Go / JavaScript / Python / Rust / Wolfram으로의 바인딩을 내고 있다. 즉 「Raku의 grammar만을 다른 언어에서 쓴다」를 노리고 있다.

이 회의 마지막에 「grammar는 Raku의 형태 그대로는 퍼지지 않았다」고 쓰지만, 퍼뜨리려는 시도는, 지금 막 시작되었다.

정직한 단서

• 둘 다 production ready가 아니라고 본인들이 명언하고 있다
• mutsu의 알려진 구멍: 미선언 변수를 컴파일 타임에 걸러내지 않는다, 예외 타입이 한정적, 패키지 매니저가 미성숙, RakuAST 미구현
• 숫자는 매일 움직인다. mutsu의 README에는 「적합도는 매일 좋아지고 있다」고 쓰여 있다

⚠️ 여기 든 숫자는 전부 2026년 9월 18일에 각 저장소에서 확인한 것. 인용하려면 다시 측정할 것. 이 연재의 규칙 1조 그대로다.

연재의 논으로서는 어떻게 되는가

7화의 우려는 부분적으로 해소되었다.

단일 구현일 때, 구현의 버그는 「언어의 사양」으로 정착할 수 있다. 구현이 셋이 되면, 어긋남이 「사양의 구멍인가, 구현의 버그인가」로 가시화된다.

그리고 6화의 형이 여기서 효과를 발휘한다.

첫 번째 이용자로는, 범용인 척을 간파할 수 없다.

roast는 10년 넘게, Rakudo라는 한 명의 이용자밖에 갖지 못했다. roast가 얼마나 사양을 포착하고 있는지는, 앞으로 검증된다.

그러면, Raku는 무엇에 맞는가

「작지만 계속되고 있다」는 상태의 기술이지, 쓸 이유가 아니다. 2026년에 Raku를 고를 이유가 있다면 무엇인가를, 측정해서 쓴다.

아래의 숫자는 전부 2026년 9월 18일, macOS / Rakudo Star 2026.08에서 측정했다. 재현 명령을 함께 적는다. 숫자는 낡으므로, 인용할 때는 스스로 다시 측정해 주었으면 한다.

밑바닥에 있는 하나의 판단

Raku의 강점은 개별 기능이라기보다, 전부가 같은 판단에서 나온다.

순순히 썼을 때의 답이 옳은 것에, 성능과 규모를 치른다.

많은 언어는 반대를 골랐다. 싼 답을 기본값으로 하고, 옳은 답은 필요할 때 가지러 가게 한다. Raku는 옳은 답을 기본값으로 했다.

실측 1 — 문자열

입력을 전 언어에서 명시적으로 분해형(e + U+0308)으로 맞춰 비교했다.

raku    -e 'my $s = "noe\c[COMBINING DIAERESIS]l"; say $s.chars, " / ", $s.flip'
python3 -c 's = "noe\u0308l"; print(len(s), "/", s[::-1])'
perl -CS -e 'my $s = "noe\x{0308}l"; print length($s), " / ", scalar reverse($s), "\n"'

언어	길이	반전	가족 이모지 👨‍👩‍👧‍👦 의 길이
Raku	4	lëon	1
Swift	4	lëon	1
Python 3	5	l̈eon ← 분음 부호가 l로 옮겨갔다	7
Perl 5	5	l̈eon ← 위와 같음	7

문자열을 반전한 것만으로 발음 기호가 다른 글자로 옮겨가는 것이, 코드포인트 단위 언어의 기본 동작이다.

다만 Raku만의 특권은 아니다. Swift도 그래핌 클러스터 단위다. Raku가 다른 것은, 이것이 정규표현식과 grammar로 그대로 이어진다는 점이다(11화).

실측 2 — 수치

raku    -e 'say 0.1 + 0.2 == 0.3; say (0.1 + 0.2).WHAT, " ", (0.1 + 0.2).nude'
python3 -c 'print(0.1 + 0.2 == 0.3, 0.1 + 0.2)'

언어	0.1 + 0.2 == 0.3	실제 값
Raku	True	Rat의 3/10(엄밀)
Python 3	False	0.30000000000000004

소수 리터럴이 기본적으로 유리수. Fraction이나 Rational을 가진 언어는 많지만, 리터럴이 기본적으로 그것이 되는 언어는 거의 없다.

명확히 강한 4개 영역

영역	왜	대안과의 차이
파서 / DSL / 독자 포맷 읽기	grammar가 언어 기능(11화)	ANTLR / yacc는 빌드 단계가 필요. Parsec / nom은 호스트 언어의 함수로 쓴다
복잡한 Unicode 텍스트 처리	그래핌 단위 + 그것이 정규표현식으로 이어진다	Swift는 그래핌이지만 정규표현식의 표현력이 다르다. 나머지는 정규화를 직접 돌본다
정확함이 속도보다 중요한 수치 계산	유리수가 기본값, 정수는 임의 정밀도	명시적으로 가지러 가야 한다
다수의 이벤트원을 한 곳에서 묶는 병행 처리	react / whenever가 구문	Go의 select는 channel 한정. RxJS는 라이브러리

이 넷에 공통되는 것은, **「옳은 답이 비싼 영역」**이라는 점이다. Raku가 강한 것은, 거기서 비싼 쪽을 기본값으로 했기 때문이다.

정직한 약점

같은 환경에서 측정했다.

for i in 1 2 3 4 5; do raku -e 'say 1' >/dev/null; done   # 5회 평균

언어	기동 시간(5회 평균)
Raku	138.8 ms
Python 3	38.4 ms
Perl 5	13.9 ms

Perl의 10배다. 원라이너나 셸 스크립트 대용으로는 불리하고, 오래 도는 프로세스라면 상대적으로 문제가 되지 않는다. 이것은 언어 사양이 아니라 구현의 성질로, MoarVM의 기동과 내장 라이브러리의 로드가 이유다.

더해서, 이 회의 표에 쓴 대로 — 전용 IDE는 개발 종료, 모듈 수는 CPAN과도 RubyGems와도 비교가 되지 않는다. (구현의 수에 대해서는, 다음 절에서 정정한다.)

정리

「Raku를 써야 한다」고 말할 수 있는 장면은 적다. 2026년에 신규 프로젝트의 언어로 권하는 것은, 생태계와 인재의 관점에서 어렵다.

말할 수 있는 것은 이쪽이다.

파서를 쓴다, 복잡한 Unicode를 다룬다, 수치의 정확함이 필요하다 — 이 중 어느 하나가 일의 중심에 있다면, Raku는 「다른 언어로 하는 것보다 명백히 편한」 선택지가 된다.

그리고 하나 더, 실무가 아닌 가치가 있다. 언어 설계의 견본시로서는 단연 뛰어나다. 타입 · MOP · 병행 · 문법 확장 · 수치 타워의 실례가 한 언어에 전부 들어 있고, 게다가 설계 판단이 전부 공개되어 있다. 이 연재를 12화 분량 쓸 수 있었던 것은, 그 덕분이다.

다섯 가지 물음으로 돌아간다

연재의 지도에서, 다섯 가지 물음을 세웠다. 답을 맞춰 본다.

1. 왜 호환성을 끊었는가

Perl 5의 근본적인 제약 — 시길의 규칙, bless 기반의 OO, @_에 의한 인자 전달 — 은, 하위 호환성 때문에 바꿀 수 없었다. 그리고 하위 호환성이 무거웠던 것은, CPAN이 있었기 때문이다(2화).

성공한 언어는, 그 성공의 형태에 고정된다.

바꾸고 싶다. 그러나 바꿀 수 없다. 그렇다면 다른 언어를 만들 수밖에 없다.

2. 왜 15년이 걸렸는가

넷 있다(8화에서 총괄했다).

설계가 너무 웅대했다(4화) / 구현 기반의 내기를 빗맞혔다(6화) / 사양이 계속 움직였다(5 · 7화) / 전임 담당자가 얇았다.

태만도 혼란도 아니다. 그리고 MoarVM으로 옮기고 나서는 2년 반 만에 나왔다.

3. 왜 이름을 바꿨는가

「Perl 6」이라는 이름이, 검증되지 않은 주장을 19년 계속 실어 날랐기 때문이다(9화).

삼자가 손해를 보고 있었다. Perl 5는 「끝난 언어」로 보이고, Perl 6은 「미완성 Perl」로 보이고, Perl 5는 버전 번호를 진행할 수 없었다.

그리고 2015년에 완성되었기에, 2019년에 개명할 수 있었다.

4. Perl 5는 무엇을 하고 있었는가

기다리고 있지 않았다. Moose가 나오고, 5.10이 나오고, 연차 릴리스 체제가 되고, 시그니처가 안정화되고, class가 들어왔다. 2026년 7월에 5.44가 나왔다.

이 15년에 가장 손해를 본 것은, Perl 6이 아니라 Perl 5였을지도 모른다. 존재하지 않는 후계에, 15년간 계속 쫓겼기 때문이다.

5. 지금 어떻게 되어 있는가

위의 네 줄대로. 작지만, 계속되고 있고, 전진하고 있다.

이 연재에서 나온 13개의 형

기술 이야기로서 이 연재를 읽는다면, 남는 것은 이것이라고 생각한다. 어느 것이나 Perl / Raku에 고유하지 않다.

#	형	화
1	언어의 근본적인 제약은, 기능을 더해도 풀리지 않는다. 구현을 다시 만들게 된다	1
2	성공한 언어는 성공의 형태에 고정된다. 자산이 클수록 변경 비용이 오른다	2
3	공모가 돌려주는 것은, 해답이 아니라 문제다	3
4	더하는 대상을, 기능에서 규칙으로 끌어올린다	4
5	구현은, 읽어서 알 수 있는 오류와는 다른 종류의 오류를 낸다	5
6	첫 번째 이용자로는, 범용인 척을 간파할 수 없다	6
7	백엔드가 N개 있다는 것과, N개가 검증되어 있다는 것은 다르다	6
8	산문은 전부에 대해 모호하게 말하고, 테스트는 일부에 대해 엄밀하게 말한다	7
9	릴리스란 기능의 추가가 아니라, 바꾸지 않겠다는 약속의 시작이다	8
10	이름은, 붙인 순간의 주장을 동결한다	9
11	개명은 「이름이 묻혀 있는 곳을 전부 세는 작업」이다	10
12	표기법의 길이는, 빈도에 대한 배분이다	11
13	구문 확장의 용이함은, 원래 구문의 작음과 맞바꾼 것이다	11

그리고 마지막으로, 하나 더 덧붙이고 싶다. 이번 회를 쓰면서 알게 된 것이다.

현재에 대해 쓴다는 것은, 언제 조사했는지를 쓰는 것이다.

이 기사의 첫머리에 「사실 확인은 2026년 9월 18일 시점」이라고 썼다. 쓴 것은, 그것이 성실하기 때문이라기보다, 쓰지 않으면 쓸 수 없기 때문이다.

「Raku의 최신판은」이라고 쓰인 기사는, 날짜가 없으면 판단할 수 없다. 낡은 것인지, 새로운 것인지, 어느 쪽이라고도 말할 수 없는지. 날짜 없는 「현재」는, 읽는 사람에게 정보가 아니다.

이 연재가 다룬 40년은, 그것의 거대한 실례이기도 했다. 2000년에 「Perl 6은 몇 년 안에 나온다」고 쓰인 기사는, 쓰인 시점에서는 옳았다. 9화에서 이름에 대해 쓴 것과 같은 구조다.

이름은, 붙인 순간의 주장을 동결한다.

기사도 마찬가지다. 그래서 날짜를 쓴다.

마치며 — 처음의 세 줄로 돌아간다

이 연재는, 세 줄의 결론에서 시작했다.

• Raku는 Perl 6의 새 이름이다. 2019년 10월에 개명했다. 같은 언어다.
• Perl 6은 Perl 5의 다음 버전이 아니었다. 호환되지 않는 별개의 언어로 설계되었고, 그렇게 자랐다.
• Perl(5 계열)은 지금도 현역이다. 2026년 7월에 Perl 5.44가 나왔다. 끝나지 않았다.

12화를 거친 지금, 이 세 줄은 그대로다. 바뀐 것은, 왜 그런지를 알고 있다는 것이다.

그리고 마지막으로 하나만, 사실로서 적어 두고 싶다.

2026년 11월, 도쿄에서, Larry Wall과 Matz가 같은 자리에서 이야기한다. Perl을 만든 사람과, Ruby를 만든 사람이다.

이 연재가 다룬 40년은, Perl이 무엇을 시도하고, 무엇을 포기하고, 무엇을 포기하지 않았는가의 기록이었다. 그 시도의 많은 것은, 다른 언어로 흘러갔다. CPAN은 모든 패키지 저장소의 조상이 되었고, 정규표현식은 업계 표준이 되었고, Moose의 오브젝트 모델은 Perl 5로 돌아갔고, 그리고 grammar는 — Raku의 형태 그대로는, 아직 퍼지지 않았다.

문법을 확장할 수 있는 언어는 다른 데도 있다(11화에서 층별로 늘어놓았다). Racket은 그 층에서 Raku보다 강하다. 그러나 정규표현식의 연장으로 쓸 수 있고, 클래스로서 상속할 수 있는 문법은, 아직 Raku에만 있다.

Raku에만 있는 것이, 아직 Raku에 있다. 그것이 2026년의 현재 위치다.

---

이 연재를 끝까지 읽어 주신 분께 감사드립니다. 사실의 오류 · 갱신의 지적은 환영합니다.