어셈블리의 온기 속에서: 웹 서버를 밑바닥부터 구축하기

고수준 프레임워크, 클라우드 네이티브 추상화, 그리고 AI가 생성한 코드가 지배하는 시대에, 웹 서버를 완전히 어셈블리로 작성하는 행위는 실용적인 엔지니어링 선택이라기보다는 디지털 퍼포먼스 아트에 가깝게 느껴집니다. 개발자 imtomt가 진행하는 프로젝트인 ymawky ("yuh maw kee"라고 발음)는 모든 편의 계층을 제거하고 오직 ARM64 어셈블리와 직접적인 시스템 호출(syscall)만을 사용하여 기능적인 정적 파일 웹 서버를 구축합니다.

대부분의 현대 개발자들에게 커널은 운영 체제에 의해 관리되며 libc와 같은 표준 라이브러리를 통해 접근하는 먼 존재입니다. 이러한 라이브러리를 완전히 우회함으로써, ymawky는 소프트웨어가 실제로 하드웨어 및 OS와 어떻게 통신하는지에 대한 마스터클래스 역할을 하며, 생산성 지표보다 장인 정신과 깊은 기술적 호기심이 우선시되는 "해커" 정신을 상기시켜 줍니다.

ymawky의 아키텍처

ymawky는 syscall-only, no-libc, fork-per-connection 서버로 설계되었습니다. 이는 모든 들어오는 요청에 대해 서버가 연결을 처리하기 위해 새로운 프로세스를 생성한다는 것을 의미하며, 이는 저수준 환경에서 상태 관리를 단순화하는 고전적인(비록 항상 확장 가능하지는 않더라도) 동시성 접근 방식입니다.

핵심 기능

어셈블리로 작성되었음에도 불구하고, 이 서버는 정적 파일 호스트로서 놀라울 정도로 기능이 완벽합니다:

HTTP 메서드 지원: GET, PUT, DELETE, OPTIONS, 및 HEAD 요청을 처리합니다.
고급 GET 기능: Range: bytes= 요청을 지원하여 비디오 스크러빙 및 부분 콘텐츠 전달(HTTP 206)을 가능하게 합니다.
원자적 업로드(Atomic Uploads): PUT 요청은 임시 파일에 작성한 후 이름을 변경하는 방식으로 처리되어, 동시 업로드 시 파일이 손상되거나 부분적으로 작성되는 것을 방지합니다.
MIME 타입 감지: 서버는 파일 확장자를 분석하여 .wasm, .webp, .mp4, .pdf 등 모든 파일에 대해 올바른 Content-Type을 제공합니다.
보안 가드레일: 일반적인 취약점을 방지하기 위해, 서버는 경로 탐색(path traversal) 감지( .. 차단)를 구현하고, PATH_MAX를 초과하는 경로를 거부하며, 심볼릭 링크를 거부하기 위해 O_NOFOLLOW_ANY를 사용합니다.

방어적 설계

어셈블리로 작성하는 것은 종종 메모리 안전성 문제를 야기합니다. 작성자는 다음과 같은 여러 "안전" 기능을 구현하여 이를 완화했습니다:

타임아웃 메커니즘: Slowloris 스타일의 서비스 거부(DoS) 공격을 방어하기 위해, 서버는 10초 이내에 데이터를 받지 못하거나 전체 헤더가 도착하는 데 너무 오래 걸리는 경우 연결을 닫습니다.
리소스 제한: MAX_PROCS 제한(기본값 256)을 통해 서버가 시스템의 PID 공간을 고갈시키는 것을 방지합니다.
입력 검증: 첫 16바이트 이내에 경로가 없는 요청은 즉시 거부됩니다.

이식성의 도전 과제

ymawky의 가장 눈에 띄는 측면 중 하나는 macOS에 대한 깊은 종속성입니다. 작성자는 이식성을 확보하려 시도했지만, 구현 노트를 통해 Unix 계열 커널 간의 극명한 차이를 드러냅니다.

예를 들어, macOS는 시스템 호출 번호에 x16을 사용하고 호출을 위해 svc #0x80을 사용하지만, Linux는 x8과 svc #0을 사용합니다. 심지어 fork()와 같은 기본적인 작업조차 두 시스템에서 서로 다른 레지스터에 다른 값을 반환합니다. 또한, 이 프로젝트는 renameatx_np()와 같은 macOS 전용 기능과 작성자가 libc 트램펄린을 완전히 건너뛸 수 있게 해주는 독특한 sigaction 구조를 활용합니다.

커뮤니티 멤버 @mappu가 언급했듯이, 이는 저수준 프로그래밍의 중요한 현실을 강조합니다: "macOS의 syscall은 안정성이 보장되지 않습니다... 안정적인 syscall 번호는 Linux의 전유물입니다. 다른 모든 곳에서는 축복받은 시스템 라이브러리를 사용합니다."

커뮤니티의 성찰: 예술 vs. 유틸리티

이 프로젝트는 LLM 시대에 수동 코딩의 역할에 관한 Hacker News 커뮤니티의 철학적 논쟁을을 불러일으켰습니다.

일부 개발자들은 이 프로젝트를 "vibe coding"에 대한 필요한 반항으로 보았습니다. @stbev가 말했듯이, 순리에 역행하는 것에는 깊은 만족감이 있습니다:

"I want to feel challenged again. I know it's crazy, and by no means useful. 실용적이지 않다는 것을 알고 있습니다. 하지만 정말 기분이 좋습니다."

다른 이들은 이러한 종류의 수동 노동을 사라져가는 예술 형식으로 애도했습니다. @rdevilla는 관찰된 관점의 변화를를 통해 말했습니다: "10년 전에는 이런 것을 만들 수 있는 엘리트한 사람에게 굽신거렸을 것입니다. 오늘날에는 그저 'LLM이 이것을 작성하는 데 얼마나 걸렸을까요?'라고 생각합니다."

하지만, 지배적인 정의는 Go나 Python의 몇 줄 코드로 할 수 있는 일을 수행하기 위해 수천 줄의 어셈블리를 매핑하는 데 필요한 순수한 결단력에 대한 경탄입니다. 이는 고수준 언어가 소프트웨어 배포의 how를 제공하는 반면, 어셈블리는 컴퓨터가 실제로 어떻게 작동하는지에 대한 why를 제공한다는 점을 상기시켜 줍니다.

결론

ymawky는 프로덕션 환경을 위한 도구가 아닙니다. 이는 교육적 연습이자 애정의 산물입니다. 이는 네트워킹, 파일 I/O, 및 프로세스 관리의 기본 원칙이 현대적인 프레임워크를 사용하든 레지스터 간에 바이트를 수동으로 이동시키든 관계없이 일정하다는 것을 보여줍니다. 그렇게 함으로써, 작성자(및 독자)에게 절대적인 기술적 제어권을 추구함으로써 얻는 의미를 있는 데로써 제공합니다.