SBCL 2.6.7 공개, 매뉴얼을 REPL 안으로 끌고 온 커먼 리스프 컴파일러

• SBCL 2.6.7이 2026년 7월 28일 나왔음. 이번 릴리스는 “새 문법 대폭 추가” 같은 느낌은 아니고, 매뉴얼 접근성, SIMD 지원, 컴파일러 버그 수정이 중심임

  • SBCL은 Common Lisp의 대표적인 네이티브 컴파일러 구현체라, 릴리스 노트가 거의 컴파일러 내부 변경 로그에 가까움
  • 그래서 웹 프레임워크 릴리스처럼 바로 앱 코드가 바뀌는 뉴스는 아니지만, 런타임·컴파일러 쪽 좋아하는 사람한테는 꽤 맛있는 디테일이 많음

• 제일 눈에 띄는 건 새 contrib 모듈 SB-MANUAL임. SBCL 매뉴얼을 Lisp 정의의 docstring과 연결해, 코드 탐색하듯 매뉴얼을 볼 수 있게 만든 기능임

  • Slime에서 M-.로 정의를 따라가듯 매뉴얼 섹션을 탐색할 수 있고, MGL-PAX 라이브러리로도 브라우징 가능함
  • 기존 공식 매뉴얼은 여전히 Texinfo에서 생성되지만, 내부 docstring은 Markdown의 부분집합을 따르도록 정리됐고 Texinfo 파일도 SB-MANUAL에서 생성되는 구조로 바뀜
  • 별도 프로젝트인 fixnum.com도 SBCL 매뉴얼을 링크가 빽빽한 PDF, HTML, Markdown, plain text 형태로 렌더링해 제공한다고 언급됨

• 문서 기능만 있는 건 아니고, DOCUMENTATION도 DOC-TYPE DECLARATION을 지원하게 됐음

  • Common Lisp에서 선언(declaration) 관련 문서를 더 일관되게 조회할 수 있는 방향으로 간 셈임
  • 매뉴얼에는 선언 전용 인덱스도 따로 생겼고, 문서 오타와 조판 문제도 다수 수정됨

• 플랫폼 지원 쪽에서는 SIMD가 꽤 많이 보강됐음

  • SB-SIMD contrib가 ARM64를 지원하기 시작함
  • x86-64에서는 AVX512 명령어 지원이 추가됨
  • ARM64와 x86-64 양쪽에 SIMD 명령어 지원이 추가로 들어갔고, UTF-8 변환에서도 가능한 경우 향상된 SIMD 루틴을 쓰도록 최적화됨

• ARM64 관련 수정도 중요함. SAP-REF-N 오컴파일이 고쳐졌고, 이건 저수준 메모리 접근 쪽이라 잘못되면 꽤 아픈 종류의 버그임

  • SAP는 SBCL에서 외부 메모리나 시스템 레벨 포인터를 다룰 때 나오는 개념이라, FFI나 런타임 저수준 코드에 영향을 줄 수 있음
  • MULTIPLE-VALUE-CALL 오컴파일도 고쳐졌는데, Common Lisp의 다중 반환값 처리는 언어 핵심 기능이라 이런 버그는 작아 보여도 파급이 큼

• 컴파일러 타입 시스템 관련 버그도 여럿 정리됐음

  • 조건부로 알려진 non-sequence 인자를 가진 CONCATENATE 호출을 컴파일할 때 타입 오류가 나던 문제가 고쳐짐
  • (EQL <complex>) 타입이 타입 시스템에서 숫자로 취급되지 않던 문제도 수정됨
  • quiet NaN, 즉 예외를 바로 터뜨리지 않는 NaN 입력을 LOG에 넣었을 때의 처리도 개선됨

• 성능 최적화는 작지만 여러 군데 깔려 있음

  • 상수 complex number를 로컬 함수에 넘길 때 consing 없이 처리할 수 있게 됨
  • COUNT 컴파일러 변환이 더 다양한 키워드 인자 조합에서도 적용됨
  • SB-ALIEN:DEREF에서 적어도 하나의 중복 명령어를 제거함
  • 컴파일러 내부 sparse set 구현을 실제 워크로드 기준으로 튜닝해 성능을 개선함

• 이 릴리스 노트가 재밌는 건, SBCL이 여전히 “언어 구현체는 매달 이렇게 늙어간다”를 보여준다는 점임

  • 2026년 2.6.x 라인만 봐도 Windows ARM64, LoongArch, FreeBSD PowerPC, RISC-V, ARM64, x86-64 같은 플랫폼 디테일이 계속 나온다
  • 고수준 언어처럼 보여도, 실제 구현체 유지보수는 ABI, NaN, GC, SIMD, FFI, 타입 추론, 파일 인코딩 같은 바닥 공사가 끝없이 이어짐

---

기술 맥락

• 이번 선택의 핵심은 매뉴얼을 별도 문서 사이트에만 두지 않고, Lisp 정의와 연결된 docstring 구조로 가져온 거예요. Common Lisp 개발자는 REPL과 에디터 안에서 정의를 따라가며 작업하는 경우가 많아서, 문서도 같은 흐름에 들어오면 컨텍스트 스위칭이 줄어들거든요.

• SIMD 지원을 ARM64와 x86-64 양쪽에서 넓힌 것도 SBCL 같은 네이티브 컴파일러에는 꽤 중요한 선택이에요. 언어 런타임이 CPU별 명령어를 더 잘 알수록, 문자열 변환이나 숫자 처리 같은 기본 연산에서 라이브러리 코드가 얻는 이득이 커져요.

• 다만 이런 최적화는 항상 트레이드오프가 있어요. AVX512, ARM64 SIMD, MIPS, LoongArch처럼 아키텍처별 경로가 늘어나면 성능 기회는 많아지지만, 오컴파일이나 플랫폼별 회귀를 잡아야 하는 유지보수 비용도 같이 늘어나요.

• 그래서 이번 릴리스의 버그 수정 목록이 길게 보이는 건 나쁜 신호라기보다, 컴파일러가 실제 사용자 코드에서 마주치는 케이스를 계속 흡수하고 있다는 쪽에 가까워요. 특히 MULTIPLE-VALUE-CALL, CONCATENATE, NaN 처리처럼 언어 의미와 최적화가 만나는 지점은 테스트만으로 끝나지 않고 실제 사용 피드백이 중요해요.