로그인 셸을 x86_64 어셈블리로 짰더니 시작 시간이 8마이크로초가 됨

• 한 개발자가 자기 로그인 셸을 x86_64 리눅스 어셈블리로 통째로 다시 짰음. 이름은 bare.

  • 이전에는 Ruby로 만든 rsh를 몇 년 동안 써왔고, 이 버전은 4,048줄에 시작 시간이 약 300밀리초였음.
  • 그다음 Rust로 rush를 만들었고, 4,280줄에 시작 시간이 26밀리초까지 줄었음.
  • 그런데 여기서 멈추지 않고 “키 입력과 커널 사이에 아무것도 없으면?”이라는 질문으로 어셈블리 셸까지 간 것.

• bare는 libc도, 런타임도, 동적 링크도 없음. 그냥 순수 시스템 콜(syscall)로만 돌아감.

  • 바이너리 크기는 126KB.
  • 시작 시간은 8마이크로초.
  • 작성자는 4일 저녁, 총 6시간 정도 Claude Code와 함께 코딩해서 실제 로그인 셸로 쓰기 시작했다고 함.

• 단순 장난감도 아님. 평소 로그인 셸로 쓰기 위한 기능이 꽤 빽빽하게 들어가 있음.

  • Git dirty 상태를 표시하는 동적 프롬프트가 있고, 별도 프로세스를 fork하지 않고 .git/HEAD와 파일 상태를 직접 읽음.
  • 파이프, 리다이렉션, 명령 체이닝, 백그라운드 작업, 작업 제어(Ctrl-Z, fg, bg)를 지원함.
  • $(cmd) 명령 치환, {a,b,c} 브레이스 확장, 글롭, 별칭, 탭 완성, 히스토리 검색, 문법 강조까지 들어감.
  • ~/.bare/plugins/ 안의 실행 파일을 플러그인으로 쓰고, :ask, :suggest 같은 AI 연동도 플러그인으로 처리함.

• 구현 방식은 정말 “셸이 하는 일을 다 직접 한다”에 가까움.

  • read(), write(), fork(), execve(), pipe(), dup2(), wait4(), ioctl()을 래퍼 없이 raw syscall 명령으로 호출함.
  • 터미널 raw mode는 ioctl(TCSETS)로 직접 설정하고, 키 입력은 문자 단위로 처리함.
  • 탭 완성은 opendir 계열 라이브러리 대신 getdents64 시스템 콜로 디렉터리를 스캔함.
  • 히스토리와 설정 파일도 open/read/write 시스템 콜로 직접 다룸.

sequenceDiagram
    participant 사용자
    participant bare셸
    participant 리눅스커널
    participant 자식프로세스
    사용자->>bare셸: 명령 입력
    bare셸->>리눅스커널: fork 시스템 콜
    리눅스커널-->>bare셸: 부모와 자식 흐름 생성
    bare셸->>자식프로세스: execve로 명령 실행
    자식프로세스->>리눅스커널: 입출력과 종료 상태 전달
    bare셸->>리눅스커널: wait4로 결과 대기
    리눅스커널-->>bare셸: 종료 상태 반환
    bare셸-->>사용자: 프롬프트 갱신

• 메모리도 힙을 안 씀. BSS 영역에 버퍼를 정적으로 잡아두고, 커널이 BSS 페이지를 필요할 때 0으로 채우는 방식에 기대고 있음.

  • malloc, brk, 메모리 할당기 초기화 같은 비용이 없음.
  • 대신 버퍼 크기와 상태 관리를 전부 직접 책임져야 함.
  • 편한 추상화가 사라지는 대신, 어디서 비용이 생기는지 눈에 보이는 구조가 됨.

• 글에서 제일 재밌는 부분은 성능보다 학습 경험임. 셸을 어셈블리로 쓰면 리눅스의 귀찮은 진실을 피할 수가 없음.

  • std::process::Command 같은 편의 API가 없으니 fork()가 부모와 자식 두 프로세스에서 각각 반환된다는 사실을 직접 다뤄야 함.
  • 터미널 제어도 라이브러리 함수 하나가 아니라 termios 구조체와 ioctl 번호를 만지는 일이 됨.
  • 텍스트 섹션에 쓰다가 세그폴트가 나고, 프로세스 그룹이 터미널을 소유하지 않아 SIGTTOU로 멈추고, NASM에서 $가 ASCII 36이 아니라 키워드라 터지는 식의 버그를 하나씩 밟았다고 함.

• 물론 대부분의 개발자에게 8마이크로초 셸 시작 시간은 필요 없음. 그래도 이 프로젝트는 “빠르게 만들려면 뭘 더 추가할까?”가 아니라 “뭘 걷어낼 수 있을까?”로 접근한 사례라 흥미로움.

  • Ruby에서 Rust로 간 건 성능 개선.
  • Rust에서 어셈블리로 간 건 집착, 향수, 그리고 AI 코딩으로 어디까지 가능한지 실험한 쪽에 가까움.
  • 작성자는 이 프로젝트를 CHasm, 즉 “CHange to ASM” suite의 첫 프로젝트라고 부름.

기술 맥락

• 여기서 선택한 기술은 x86_64 어셈블리와 리눅스 raw syscall이에요. 왜냐하면 작성자가 셸 시작 시간에서 런타임, libc, 동적 링킹, 메모리 할당기 같은 중간 계층 비용을 전부 걷어내고 싶었거든요.

• Ruby 버전은 편하고 기능도 많았지만 시작 시간이 300밀리초였고, Rust 버전은 26밀리초까지 줄었지만 여전히 libc와 크레이트, 런타임 초기화 비용이 남아 있었어요. bare는 이 대안을 더 밀어붙여서 바이너리 126KB, 시작 시간 8마이크로초라는 극단적인 결과를 만든 거예요.

• 구현은 셸이 보통 라이브러리에 맡기는 일을 전부 직접 처리하는 방식이에요. 명령 실행은 fork와 execve, 파이프는 pipe와 dup2, 작업 제어는 wait4와 시그널 처리, 터미널 raw mode는 ioctl로 다뤄요. 그래서 코드가 13,366줄까지 늘어났지만, 대신 셸의 동작 경로가 거의 그대로 드러나요.

• 이 선택은 실용성과 유지보수성 면에서는 꽤 비싼 선택이에요. 하지만 셸, 터미널, 프로세스, 파일 디스크립터, 리눅스 커널 인터페이스를 깊게 이해하려는 목적이라면 엄청 좋은 실험이에요. 특히 AI 코딩 도구가 이런 저수준 디버깅을 어느 정도 보조할 수 있다는 점도 이 글의 중요한 관찰이에요.