코드 읽는 Human

자비로운 종신 독재자(Benevolent Dictator for Life).. IT업계에서  이런 명칭을 사용할 수 있는 몇몇 분들이 있습니다. 이번에 소개하는 패트릭 볼커딩도 그중 한 분입니다. 그는 1993년 리눅스 슬랙웨어 배포판을 만들고, 지금까지 계속 개발을 이끌며, 종속성 문제 해결 및 슬랙웨어를 유닉스와 비슷하계 유지 보수하고 있습니다. 살아있는 역사의 증인이죠... 슬랙웨어... 제가 개인적으로 좋아하는 리눅스 배포판이기도 합니다. 

패트릭 볼커딩은 66년생으로 버지니아에서 태어났습니다. 아버지가 미 해군 소속 치과의사였지만 어린 시절을 노스 다코다에서 보냈습니다. 7살이던 73년도에 노스다코다 주립대 컴퓨터학과를 견학갔다가 메인프레임을 만나게 되죠. 컴퓨터에 대한 관심은 폭발했지만, 가정형편때문에 컴퓨터를 장만하지 못했던 패트릭은 열심히 전자공학을 공부합니다. 릴레이 회로를 직접 만들었답니다. 그러다가 애플2, TRS-80 같은 개인용 컴퓨터가 출시되었고, 컴퓨터 가게를 하도 자주 가서 단골이 된 패트릭은 BASIC을 독학한 후 가게에서 쓸만한 간단한 데모 프로그램을 만듭니다. 그 덕분에 가게에 떳떳하게 무제한 입장 가능!! 

그의 첫 컴퓨터는 애플2+였다고 합니다. 이후 90년까지 애플컴퓨터만 사용했는데, 92년 운명적으로 리눅스를 만납니다. 볼커딩은 85년 보스턴대학교에서 컴퓨터공학 학위 취득후 무어헤드 주립대(현 미네소타 주립대)에서 컴퓨터 과학을 공부하고 있었습니다. 볼커딩은 인공지능 수업을 듣고 있었는데, LISP으로 수업을 진행했습니다. 볼커딩은 프로젝트에 사용할 저렴한 LISP 인터프리터를 찾다가 초기 리눅스 배포판중 하나인 SLS를 다운로드 받아 사용하게 됩니다.

하지만 SLS는 잘못된 파일권한, 불안정한 네트워크 구성으로 크래시가 자주 발생했는데, 볼커딩은 소스코드를 재 컴파일하면서 안정성을 높여가는 작업을 진행하죠.  교수님이 "새로운 컴퓨터에 설치 디스크를 수정해서 이런 수정 사항들이 바로 적용되도록 할 방법이 있을까요?"라고 던진 질문이 슬랙웨어의 시작이었습니다.(교수님 왜 그러셨어요? 차라리 대학원 진학하라고 하시지. 아 이미 대학원생이구나. )

1993년 SLS의 품질 문제를 해결하기 위하여 직접 리눅스 배포판을 만들기로 결심합니다. 초기에는 소스코드에서 소프트웨어를 수동으로 패치킹하는 방식의 사용자 정의 설치 스크립트를 작성했고, 유즈넷 comp.os.linux 그룹의 피드백을 받아 시스템을 개선해 나갑니다. 1.0 이  AT&T에 처음 배포된 후 높은 인기를 누리며 초기 사용자를 끌어 모았습니다.

그는 지금도 슬랙웨어를 유지 관리하고 있습니다. 현재 슬랙웨어는 15.1이 최신 버전입니다. :)

무언가를 좋아하고, 사랑하고, 참여하고, 공유하는 과정.. 리눅스의 철학과 딱 맞는 것 같아서 소개해 보았습니다. 

1992년, 핀란드에서 누군가가 UNIX 클론을 만들려는 프로젝트가 진행 중이라는 소식을 처음 들었습니다. 당시 저는 16MHz 386/sx에서 OS/2를 사용하고 있었는데, 괜찮은 운영체제였지만 제가 정말로 원했던 건 UNIX 계열 운영체제였습니다.

사용자의 의도를 미리 짐작하려 들수록 오히려 장벽이 생긴다고 생각합니다. 그래서 최대한 단순하게 유지하는 것을 선호합니다. 

저는 당장 눈앞의 목표에 집중하는 것을 선호합니다. 그 목표들이 달성되면 다음에 무엇을 해야 할지 명확해집니다. 슬랙웨어 개발은 ​​계획적인 설계라기보다는 진화의 과정에 가까웠습니다.

2016년 2월 8일. 새로운 시스템 프로그래밍 언어 하나가 공개됩니다. 이름은 Zig. C의 단순함을 계승하면서도 현대적인 개발 경험을 제공하겠다며 시작된 이 언어는 Bun, Ghostty 등과 같은 프로젝트의 기반이 되며 빠르게 존재감을 키워갑니다. 이번에 소개할 IT 인물은 Zig를 만든 오픈소스 소프트웨어 개발자이자 Zig 소프트웨어 재단 의장인 앤드류 켈리(Andrew Kelley)입니다.

앤드류 켈리는 음악을 좋아하는 개발자였는데요. 자신의 관심사를 해결하기 위하여 실시간 오디오를 세밀하게 낮은 수준까지 제어할 수 있는 음악 스튜디오 프로그램을 개발합니다. 이 프로젝트는 제네시스 디지털 오디오 워크스테이션이 되는데요. 라이브 공연에서도 오디오 끊김 없이 계속 제어할 수 있으려면 높은 안정성과 최소한의 지연시간이 보장되어야 했습니다. 그러려면 하드웨어와의 직접적인 상호작용이 필수였겠죠.  이런 기능을 구현하기 위해 켈리는 C/C++을 주로 사용합니다. 결국 기존 소프트웨어에 만족하지 못한 켈리는 직접 크로스 플랫폼 오디오 추상 계층 라이브러리인 libsound.io를 개발합니다. 이 과정에서 기존 언어와 라이브러리에 대한 불편함을 느끼게 됩니다.

켈리는 애리조나 주립 대학교에서 전산학 학사학위를 취득한 후 다양한 회사를 거치면서 분산시스템, 오디오 처리, 클라우드 서비스, 개발 도구 개발을 경험합니다. Zig는 이러한 그의 폭넓은 실무 경험 위에서 설계된 언어입니다.

이후 데이팅 플랫폼인 OkCupid에 근무하면서 기존 레거시 코드를 유지관리하면서 Zig 개발을 이어갑니다. 하지만 직장생활과 오픈소스 개발을 병행하는 것은 쉽지 않지요. 2018년 6월 켈리는 OkCupid를 사임하고 Zig개발에 전념합니다. 켈리는 Zig가 C언어를 버리는 언어가 아니라 C를 더 안전하게 사용할 수 있는 프로그래밍 언어가 되기를 바랬습니다. 그래서 Zig의 지향점으로 C ABI와의 완벽한 호환성, NULL 포인터 대신 선택적 타입 사용, 오류 공용체를 사용하는 오류 처리 시스템, 대안적 표준 라이브러리, C 전처리기 대체 등을 내세웠습니다. 그래서 Zig의 대표적인 슬로건이 "감춰진 제어 흐름도 없고, 감춰진 메모리 할당도 없다(No hidden control flow, no hidden memory allocations)입니다. 발전을 거듭하던 Zig는 2020년 3월 24일 C/C++ 코드 컴파일할 때 GCC나 Clang을 대체하는 강력한 컴파일러로 자리매김하게 됩니다. 이후 켈리는 Zig의 비동기 입출력을 개선하고 있습니다.

켈리는 AI에 대해 상당히 비판적인 입장을 밝혀왔습니다. AI를 사용한 PR은 받지않는다는 정책을 밝혔죠. 그는 AI가 생성한 코드는 리뷰 비용만 증가시키는 경우가 많은데, 오픈소스의 경우 메인테이너의 시간이 가장 중요한 자원이기 때문에 AI 생성 코드는 거부한다고 이야기했습니다. 또한 오픈소스의 목표 중 하나는 개발자를 성장시키는 것인데 코딩 AI에 의존한 기여는 그에 부합하지 않는다는 것이었죠. 모든 프로젝트가 코딩 AI에 대해 동일한 정책을 따를 필요는 없겠지만, 프로젝트를 관리해야 하는 책임자의 시간과 교육이라는 가치를 어떻게 균형 있게 볼 것인가에 대해서 기업 입장에서도 생각해 볼 주제라 생각됩니다.

Andrew Kelley는 새로운 언어를 만든 사람중 한 명이라기보다는 시스템 프로그래밍은 단순해야 한다는 철학을 일관되게 실천해 온 개발자입니다. Zig가 앞으로 얼마나 성장할지는 알 수 없지만, 적어도 그가 던진 '복잡성을 줄이고 예측 가능성을 높이자'는 문제의식만큼은 앞으로도 오래 이야기될 것 같습니다.(Zig로 개발된 Bun은 최근 Rust로 다시 작성되었습니다.)

힙은 조지아 공대(조지아테크)에서 전기공학을 전공하고, 듀크대학에서 음성 자연어 대화 처리 시스템에 대한 연구를 수행한 후  전산학 박사 학위를 받습니다. 이후 AT&T 벨 연구소에서 스태프 엔지니어로 C/Unix 프로그래밍 관련 업무를 담당했으며, 이후 DARPA  및 제너럴 다이나믹스사 등 회사 고객에 맞춤화된 솔루션은 전문적으로 제공하는 Hipp, Wyrick & Company, Inc(줄여서 Hwaci라 쓰고, 와치라 읽습니다)를 설립합니다.

HWACI사는 2000년 봄 미 해군의 유도미사일 구축함 프로그램용 소프트웨어 개발 계약을 따냅니다. 이런 종류의 프로젝트에서는 데이터를 처리하기 위해 데이터베이스 시스템이 필요합니다. 기존에는 인포믹스와 같은 RDBMS를 따로 구축하여 사용했는데, 해군 함정에서 사용하기는 너무 번거로웠죠. 그래서 미 해군은 관리부담을 최소화시킨, 별도의 설정 작업 없이 배포할 수 있으면서도 안정적인 성능을 제공하는 내장가능한 SQL 데이터베이스 엔진을 요구합니다. 힙은 이 과제를 수행하기 위해 공개 도메인 데이터베이스를 개발하는데, 이것이 바로 SQLite의 시작입니다.

원래 미 해군이 개발하던 소프트웨어는 DDG-79 오스카 오스틴 전함에 탑재될 예정이었습니다. 이런 전함은 매우 크고 복잡한 시스템이빈다. 따라서 각 부품의 연결 정보 등을 기반으로 바뀌는 환경에 대해 바로 대응할 수 있는 제어/판단 시스템이 필요합니다. 그런 시스템의 기반에는 전함의 배관 정보 및 밸브 정보 등이 저장되어야 합니다. 그렇다고 전함에 DBMS를 설치하면 프로그램을 사용할 사용자 말고 DBA도 탑승해야 합니다. 그렇지 않으면 프로그램을 실행했는데 "데이터베이스에 연결할 수 없습니다"라는 경고창이 표시될 테니깐요. 이 문제를 해결하기 위해 리처드 힙이 뛰어듭니다.

미 해군의 요구사항은 SQLite의 핵심 기능이 됩니다. 서버리스 방식으로 작동하므로 별도의 서버 프로세스를 실행하지 않고 애플리케이션에 라이브러리 형태로 내장됩니다. 설정 파일도 지원되지만, 별도의 설정을 하지 않아도 내장하면 바로 사용할 수 있습니다. 데이터베이스 기능을 제공하지만 라이브러리의 크기는 900KB 보다 작은 크기로, 소형 단말에서도 자유롭게 사용할 수 있습니다. 그 덕분에 SQLite는 iOS/AOS 스마트폰, 웹 브라우저, 자동차, 의료기기 등 수많은 애플리케이션에 내장되어 역사상 가장 많이 배포된 데이터베이스 엔진으로 자리잡게 됩니다.

SQLite로 알려진 힙이지만, 여러 다양한 소프트웨어 프로젝트도 진행합니다. 그중에서 Fossile SCM은 git과 유사한 분산 버전 관리 시스템 소프트웨어입니다. SQLite 개발도 Fossil 기반으로 진행됩니다. 또한 Tcl 스크립트 언어의 발전을 위해 주요 확장 기능과 도구를 개발해 오고 있습니다. 트리 위젯, 노트북 위젯, HTML 위젯 등 다양한 Tcl/Tk 모듈을 개발해 왔습니다. (TCL의 아버지 존 아우스트하우트 이야기도 읽어보세요.)

복잡함은 당신의 적입니다. 최대한 단순하게 유지하세요
처음 떠오르는 해결책을 바로 사용하지 마십시오, 문제를 좀 더 생각해 보면 더 나은 접근 방법을 찾을 수 있는 경우가 많습니다.
코드, 특히 데이터 구조와 변수 정의에 대해 꼼꼼히 주석을 다세요. 다른 사람이 읽고 이해하여 유지 관리할 수 있는 코드를 작성하세요. 내용을 명확히 설명하세요.
테스트를 고려하여 설계하세요. 작동하는 소프트웨어를 작성하는 것만으로는 충분하지 않습니다. 검증이 쉽고, 작동 여부를 금방 테스트할 수 있는 소프트웨어를 작성해야 합니다.
(좋은 소프트웨어 설계 원칙에 대한 질문에 대한 답변)

인공지능은 분명 유용합니다. 앞으로 인공지능의 새로운 활용법이 발견될 것이고, AI기술은 귀중한 시간 절약 도구가 될 것이라고 확신합니다. 하지만 인공지능이 세상을 완전히 장악할 것이라는 종말론적 예측에는 회의적입니다.

문제를 만드는 것보다 더 많은 문제를 해결하세요.
할 수 있는 한 많은 문제를 해결하세요. 작은 일부터 시작하세요. 침대를 정리하고, 쓰레기를 주워 쓰레통에 버리고, 가게 계산원에게 친절하게 대하세요. 이런 작은 일들은 더 큰 문제를 해결하는 데 좋은 연습이 됩니다. 작은 일들에 익숙해지면 더 큰 문제에 도전해 보세요. 가족과 친구를 돕고, 고객을 돕고, 지역 사회에 기여하세요. 문제를 일으키는 것보다 더 많이 해결할 수 있다면, 직업, 친구, 사랑, 행복이 부족할 일은 없을 것입니다.

진정으로 자유롭고 싶다면 스스로 행동해야 한다는 뜻입니다.

풀 리퀘스트(PR)는 공짜가 아닙니다. 사실상 제게 요구를 하고 있는 겁니다. 이렇게 멋진 기능을 내가 개발했으니, 당신이 그걸 유지보수하고 문서도 작성하고 테스트하면서 계속 유지보수해 주길 바라는 겁니다. 
리누스가 한 명언이 있습니다. Free라는 단어는 무료 맥주를 의미하거나 표현의 자유를 의미할 수 있습니다. 하지만 또다른 Free가 있습니다. '내가 공짜 강아지를 한마리 입양해 줄게" 
풀 리퀘스트는 누군가가 당신에게 강아지 한마리를 입양해 주는 것과 같습니다. 당신은 그 강아지를 버릴 수도 없습니다. 도덕적인 책임감 때문에 강아지가 죽을 때까지 돌봐야 합니다.
나는 그런 공짜 강아지를 원하지 않습니다.

 당시 전문가들에게 물어보면 "불가능해. 절대 안 될 거야. 말도 안 되는 생각이야."라고 했을 겁니다. 다행히 저는 그런 전문가들을 알지 못했고, 그래서 그냥 해냈습니다. 이런 일도 종종 일어나는 거죠. 제 생각에는 전문가들의 말에 너무 귀 기울이지 말고, 스스로 이치에 맞는 일을 하는 게 중요한 것 같습니다. 문제를 해결하세요.