출처 : http://osdi.insightbook.co.kr/2013/10/24/01-tj.html

 

널리 알려지지는 않았지만 그 전설 같던 시절이 지나고 이제는 누구나 오픈 소스라는 말을 어디선가 들어봤음직한 시대가 됐다. 오픈 소스로 뭔가를 할 수 있으리라 별로 기대하지도 않았고 리누스 토발즈 자서전 제목처럼 ‘그냥 재미로’ 오픈 소스를 다뤄온 사람들은 지금 무엇을 하고 있을까? 어떤 사람은 오픈 소스 개발이 생업이 되어 즐겁게 일하고 있고, 또 어떤 사람은 여전히 취미로 오픈 소스를 즐기며 산다. 이 인터뷰집은 그 사람들의 이야기 ‘일부’를 다룬 것이다. 

--

src : http://www.bloter.net/wp-content/uploads/2014/09/linux_developer_roundtable_06-765x554.jpg

 

 

프로그래밍은 언제 어떻게 시작했나요?

초등학교 시절 아버지께서 MSX 컴퓨터를 사오셨습니다. 아마 삼성 SPC 모델이었던 것 같습니다. 그때 봤던 잡지 제목은 기억나지 않는데 잡지에 있는 코드를 입력하면 게임이 됐었습니다. 프로그래밍이라고 할 수는 없는데 그렇게 컴퓨터를 처음 접했습니다. 그러고 나서 프로그래밍을 제대로 하기 시작한 것은 고등학교 때였습니다. 학교 컴퓨터실에서 프로그래밍을 했습니다. 그때 터보 C로 탱크 게임을 만들었는데 그게 처음으로 짠, 크기가 어느 정도 되는 프로그램이었습니다. 그 후 대학에 입학했고 전산을 전공했습니다.

1980년대 컴퓨터를 만지기 시작한 사람들에게 MSX에 대한 추억은 일종의 공통 스토리인 것 같습니다. 당시 MSX 컴퓨터엔 롬팩이란 게 있었죠. 그리고 테이프 레코더를 연결해 프로그램을 로드해 쓰기도 했습니다. 지지직거리면서 프로그램 로드하는 데 20분 넘게 걸리기도 했죠. 중간에 끊기거나 잘 안 되기도 했던 기억이 나네요.

 

대학 시절 학교 수업 외에 어떤 프로그래밍을 했나요?

2학년 때부터 리눅스를 쓰기 시작했는데요. 그전까지는 터보 C를 쓰다가 리눅스 환경은 오픈 소스라서 코드를 볼 수 있고 마음대로 만들 수 있어서 리눅스 환경에서 프로그래밍을 시작했습니다. 처음 해본 건 CD 리핑 프로그램의 사용자 인터페이스를 GTK+로 만드는 것이었습니다. 명령행 형태의 cdparanoia로 음반에서 음원을 추출하고 인코더로 MP3를 만들고 CDDB(Compact Disc Database)에서 곡명 같은 정보를 가져와 MP3 태그를 넣는 과정을 GUI로 수행할 수 있게 만든 프로그램이었습니다. 당시에 데비안 개발 버전을 쓰고 있었는데 업데이트만 하면 CD 리핑부터 이것저것 시스템이 정상 작동되지 않는 경우가 많았습니다. 아예 부팅이 안 되기도 했고요. 주말만 되면 그걸 고치는 게 일이었죠. 그러면서 많이 배웠던 것 같습니다. 운영 체제와 아키텍처 책도 여러 권 봤던 것 같습니다.

 

직장 생활도 리눅스 관련 일로 시작했나요?

첫 직장은 아라기술이란 회사였습니다. 웹 캐시와 심층 패킷 검사(deep packet inspection) 솔루션 등을 전문으로 개발하는 회사였습니다. 4학년 때 아르바이트로 일을 시작했습니다. 당시에 판매되던 제품으로 FreeBSD 운영 체제에서 동작하는 재규어 2000이라는 웹 캐시 솔루션이 있었습니다. 처음에 했던 일은 FreeBSD 커널 튜닝 같은 일이었습니다. 그때, 그러니까 1990년대 말만 해도 운영 체제의 SMP(symmetric multiprocessing) 지원이 그다지 좋지 않았습니다. 싼 x86 서버에 CPU가 여러 개 달려 나오기 시작하던 시기였는데 당시 운영 체제가 락을 거는 방식 때문에 문제가 많았습니다. CPU 하나는 바쁜데 나머지 CPU는 논다든지 성능이 잘 나오지 않았죠. 그런 성능 튜닝 일을 1년쯤 했습니다. 그 외에 비동기 I/O 시스템 인터페이스에서 벡터드 I/O(vectored I/O 또는 scatter/gather I/O)를 구현하는 일도 했습니다. 그 후 재규어 3000을 리눅스에서 개발하게 됐고 FreeBSD의 kevent라는 시스템 콜을 리눅스로 이식하면서 리눅스 커널 프로그래밍을 하게 됐습니다.

 

커널 개발자로서 경력이 시작된 시기가 그즈음인가요?

그런 셈이죠. 어릴 때부터 로우 레벨 소프트웨어에 관심이 많았고 좋아해서 그 방향으로 일을 하고 싶었는데 재규어를 개발하면서 많은 경험을 하게 됐습니다. 재규어 3000 개발 시기 경험이 재미있었고 기억에 남는데요. 당시 비동기 모델과 스레드 모델 둘 중 하나를 선택해 개발해야 했는데 비동기 모델은 스레드가 하나만 있고 스레드 하나가 작업을 다 처리하는 모델입니다. select나 kevent를 그럴 때 쓰는데, 어느 작업에 I/O가 있는지 보고 그 I/O를 받아와서 처리하고 그다음 작업을 하는 과정이 반복되는 방식입니다. 당시에는 그 방식에 문제가 좀 있었는데요. CPU가 여러 개이면 스레드도 늘어나게 되는데 스레드 각각을 비동기로 짜려면 복잡해지게 됐죠. 그래서 스레드 모델로 가려고 했는데 1990년대 말에는 대다수 운영 체제의 멀티스레드 지원이 좋지 못했습니다. 스레드를 많이 만들면 운영 체제가 느려졌습니다. 그래서 그 문제를 해결하는 방법으로 kevent 등을 이식하고 그 위에 유저랜드에서 스레드 패키지를 만들었습니다. 비동기인데 그 위에 레이어를 얹어서 스레드처럼 보이게 한 거죠. 그 일을 2~3년 하면서 많이 배웠고 재미도 있었습니다. 그러다가 2000년대 초반에 NPTL(Native POSIX Thread Library)이란 게 나오면서 비동기 모델이 결국 필요가 없어졌습니다. 운영 체제 스케줄러와 스레드 성능이 크게 향상되면서 유저랜드 스레드가 효용이 떨어졌습니다. 좀 슬펐습니다. 열심히 만들었는데 쓸모가 없어졌으니까요.

 

리눅스 커널 개발에는 언제부터 본격적으로 참여했나요?

아라기술에서 5년 정도 일했는데 마지막 2년은 일이 좀 지겹게 느껴졌던 것 같습니다. 그 시기에 심층 패킷 검사 솔루션 개발을 했는데 재미가 없었습니다. 네트워크를 지나는 패킷을 열어서 세션별로 무슨 트래픽이 지나가는지, 어떤 내용인지 등을 검사하는 솔루션인데 지루하다는 느낌이 들었습니다. 그래서 회사를 그만두고 한 2년간 직장 없이 그냥 리눅스 커널을 봤습니다. 그때가 본격적으로 리눅스 커널을 공부하기 시작한 시기였습니다.

 

특별한 목적도 없이 ‘그냥’ 보기 시작했던 건가요?

직장도 없었고 다른 회사를 가도 재미가 없을 것 같았어요. 사용자 대상 서비스에는 관심이 그다지 없었고 별로 할 일이 없는 상황이었습니다. 리눅스 커널을 잘하면 돌파구가 있지 않을까 하는 생각이 들었고 워낙 좋아하기도 하고 이 일을 하고 싶다 보니 공부하게 됐습니다. 소스도 보고 패치도 보내면서 시간을 보냈죠. 처음에는 좀 불안했는데 6개월쯤 지난 후에 하드 디스크 컨트롤러 등을 만드는 실리콘 이미지(Silicon Image)라는 회사에서 연락이 왔습니다. 당시 DVR(digital video recorder)이 막 나온 시기였고 대부분 하드 디스크가 달린 임베디드 리눅스 기기였는데 국내 기업들도 실리콘 이미지의 하드 디스크 컨트롤러를 많이 썼습니다. 장치 드라이버란 게 잘 돌아가기도 하지만 문제가 생길 때면 플랫폼 지원을 해야 합니다. 그런데 실리콘 이미지는 국내에 엔지니어가 없다 보니 리눅스 ATA 드라이버 쪽 활동을 하던 저와 연결이 돼서 실리콘 이미지에서 제게 비용을 주고 제가 시간제로 국내 기업들에 기술 지원을 나가게 됐습니다. 실리콘 이미지의 컨설팅비가 높긴 했지만 일이 가끔 있다 보니 3~4일 일하고 한 달 생활비를 벌어 겨우겨우 지내기도 했습니다. 그렇게 1년 반 정도 일했습니다. 그러다가 당시 SUSE 리눅스의 옌스 악소베(Jens Axboe)라는 리눅스 커널 블록 레이어 메인테이너가 오라클로 이직하면서 SUSE에 ATA 쪽을 맡을 사람이 없어졌고 옌스가 제게 입사를 권해서 2006년부터 SUSE에서 일을 시작하게 됐습니다.

 

그즈음에는 리눅스 커널 소스가 이미 상당히 방대했을 텐데 공부하는 데 얼마나 어려웠나요?

그때나 지금이나 사람들은 대체로 처음에는 관심 있는 부분만 봅니다. 첫 직장에서 네트워크 쪽은 많이 했고 다른 분야를 공부하고 싶어서 ATA를 파고들게 됐습니다. 그 부분만 보면 분량도 그렇게 많지는 않았고요. 그래서 드라이버들이 커널 공부를 처음 시작할 때 좋은 것 같습니다. 예를 들어 스케줄러나 메모리 관리는 대학원에서 석박사 연구를 할 때 주로 다루는 주제이고 경쟁도 치열합니다. 드라이버는 그에 반해 진입 장벽이 훨씬 낮고 하드웨어와 바로 붙어 있는 부분이니까 배우는 것도 많습니다. 커널 공부를 어디서부터 하면 좋겠느냐는 질문을 받으면 흔한 하드웨어 드라이버를 하나 골라서 시작하면 좋다고 답해줍니다.

 

메인테이너 권한은 보통 어떤 식으로 받게 되나요?

기존 메인테이너한테 특별한 일이 없으면 계속 해당 부분을 맡지만 어떤 이유로 일을 할 수 없게 되면 함께 작업하던 사람에게 권한을 주기도 합니다. 제 경우에는 전(前) libata 메인테이너 제프 가르직(Jeff Garzik)이 멘토링을 잘해줬습니다. 리눅스 커널 메일링 리스트에 처음 들어가면 실수에 가혹하고 잘난 척하는 사람들도 있어서 기분 나쁘고 상처도 좀 받습니다(웃음). 다행히 제프 가르직이 방향도 잘 잡아주고 친절하게 대해줘서 늘 고맙게 생각합니다. 그래서 ‘나도 나중에 자리가 잡히면 친절하게 대해야겠다’고 생각했는데 막상 잘 안 되더군요(웃음).

 

현재 어떤 부분들을 맡아서 개발하는 중인가요?

담당하는 부분은 per-cpu memory allocator(이하 per-cpu), workqueue, cgroups, libata 네 가지입니다. 이 네 가지 외에도 새로운 걸 보기를 좋아하는 성격이라 1년 주기로 이것저것 작업을 해봤습니다. 리눅스 커널 개발의 매력인 것도 같습니다. 일반 직장인이라면 맡은 일을 계속해야 하는데 마음대로 다양하게 개발해 볼 수 있어서 좋습니다.

 

workqueue, cgroups 등 개발은 장치 드라이버 개발과는 어떤 면에서 다른가요?

싼 하드웨어 드라이버 개발에서 불편한 점은 하드웨어 품질이 고르지 않다는 것입니다. 몇 만 원도 되지 않는 하드웨어들 중에는 버그와 호환성 이슈 같은 잡다한 문제가 많은 제품이 제법 있습니다. 그런 문제를 찾아 디버깅하려면 하드웨어를 잘 알아야 하는데요. 예를 들어 PCI 버스 컨트롤러 문제, 캐시 일관성(cache coherence) 문제, 이상한 세팅 문제 등 희한한 문제가 많아서 쉽다고 볼 수 없는 것 같습니다. per-cpu 역시 하드웨어에 의존하는 부분이긴 하지만 일반 하드웨어보다는 정교하게 만들어져서 번잡한 문제는 크게 겪지 않습니다. 정확히 기억나지는 않지만 장치 드라이버 개발이 지겨워질 때쯤 블록 레이어에서 개발을 하다가 필요한 기능이 커널의 다른 부분에 없어서 지금 담당하는 부분에 손을 대기 시작한 것 같습니다. per-cpu의 경우는 블록 레이어에서 per-cpu 레퍼런스 카운터를 만들고 싶었는데 당시 동적 per-cpu 할당기가 성능이 좋지 않아서 시작했고, workqueue는 CD-ROM 같은 매체를 자동 마운트하는 상황 등에서 제약 사항이 많아 수정하기 시작했습니다.

 

기존 리눅스 개발자들이 ‘까칠’하다고 하셨는데 자기 분야에 못 보던 사람이 나타나서 코드를 고치겠다고 했을 때 반응이 어땠나요?

무조건 텃세를 부리지는 않습니다. 기본적으로는 열린 커뮤니티이고 제도적인 배타성은 전혀 없습니다. 아무나 와서 참가할 수 있으니까요. 그런데 중간 메인테이너가 할 일은 위에서는 리누스가 노려보고(?) 밑에서는 사람들이 코드를 던지는 상황에서 위험을 관리하는 것입니다. 메인테이너가 위험도가 높은 코드를 받아들이면 리누스가 나중에 질책을 하기 때문에 메인테이너 위치에서는 누군가가 갑자기 나타났을 때 신뢰하기 어렵습니다. 기술적인 능력도 문제지만 변화를 만들어 놓고 중간에 사라져 버린 후 그 코드까지 망가지면 메인테이너가 그 문제를 해결해야 해서 신뢰가 필요합니다. 처음에 작은 기여로 신뢰를 쌓다 보면 개발 주기가 몇 주기 반복된 후, 기술 수준이나 버그 발생시 대응 등에 좋은 평판을 얻게 되고 그런 과정을 거쳐야 좀 더 많은 개발을 할 수 있습니다. 그리고 한 서브시스템에서 그렇게 신뢰를 얻은 후에 다른 서브시스템 개발에 참여하면 사람들과 네트워킹이 생기면서 자기 영역을 점점 더 넓힐 수 있게 되고요. 예를 들어 갑자기 나타나서 커널의 중요한 부분을 개발하겠다고 하면 의심을 받겠지만 드라이버 같은 걸 개발하다가 참여 영역을 넓히기는 쉬운 것 같습니다.

 

한국은 언제 떠나셨나요?

SUSE 입사 후 2010년 초까지 한국에서 재택근무를 했습니다. 평소에 외국에 나가서 살아보면 재미있겠다고 생각했는데 마침 기회가 되어 2010년에 떠나게 됐습니다. ATA 작업을 하다가 독일에 있는 막스 플랑크 중력 물리 연구소(Max Planck Institute for Gravitational Physics)의 물리학자 브루스 알렌(Bruce Allen)이란 분을 알게 됐는데 어느 날 놀러오라고 하더군요. 그렇게 독일에 갔다가 연구소에서 기술 고문(technical advisor)으로 일하게 됐습니다. 현대 물리학에서는 계산을 많이 해서 슈퍼컴퓨터를 사용하는데 제가 일한 연구소도 슈퍼컴퓨터 클러스터를 썼습니다. 연구소의 물리학자들이 제가 보고하는 운영 체제 관련 내용을 이해했는지 모르겠지만 재미있었습니다. 저도 물리학 관련 내용은 이해하지 못했지만요(웃음). 연구소에서 2년 가까이 있는 동안 제가 하고 싶은 일을 많이 할 수 있어서 좋았습니다. 그 후 구글로 이직해 1년 정도 일하다 현재는 레드햇에서 근무하는 중입니다.

 

구글은 어떻게 들어가게 됐나요?

연구소에서 일하는 중에 구글 리크루터의 연락을 받고 면접을 보고 합격해 입사하게 됐습니다. 독일어가 빨리 늘지 않아서 말이 통하는(?) 곳으로 가고 싶더군요(웃음).

 

구글에서도 계속 리눅스 커널 개발을 하셨나요?

예. 구글은 수많은 리눅스 서버를 운영하고 있고 서버에서 돌아가는 리눅스 커널도 직접 관리합니다. 저는 커널 팀에서 스토리지 쪽에 소속되어 있었습니다.

 

독일 연구소에서 독립적으로 일하던 때와 달리 회사의 요구 사항이 늘어난 편이었나요?

꼭 그런 정도까지는 아니었습니다. 구글은 직장치고는 유연성이 높아서 가서 보면 ‘정말 좋구나’ 하는 느낌이 들죠. 그래도 직장은 직장이라서 분기별로 뭘 해야 할지 계획을 세우고 분기 마지막에 계획을 얼마만큼 이뤄냈는지 확인하고 그 일이 구글에 얼마만큼 기여했느냐 설명해야 하는 일은 있습니다. 구글은 서버가 워낙 많기 때문에 한 대당 0.5%만 비용을 아껴도 큰 액수가 절약되거든요. 그런데 약간 재미는 없더군요(웃음). 그래서 레드햇으로 옮기게 됐습니다.

 

구글 같은 초대형 서비스들의 커널에 대한 요구 사항은 주로 무엇인가요?

검색, 지메일 같은 구글의 중요 서비스의 경우 규모도 워낙 크고 데이터 처리량도 어마어마하다 보니 이 서비스들이 어떻게 잘 도느냐가 항상 초점입니다. 예를 들어 사용자가 검색어를 입력하면 내부적으로 몇 단계를 거쳐 검색 결과가 나오는데, 목표가 있습니다. 몇 백 밀리초 이하로 나와야 한다든지 하는 것인데, 각 단계별 소요 시간 같은 데이터를 그래프로 뽑아서 지연 시간이 긴 부분의 원인을 찾아 고칩니다. 보통 I/O 문제일 때가 많습니다. 대다수 수정이 구글 서비스를 위한 것이죠. 또 기계가 많다 보니 전기 요금과 냉각 비용이 지출에서 큰 비중을 차지합니다. 그래서 기계를 효율적으로 쓰고 싶어 합니다. 구글에는 몇 시간씩 도는 배치 작업이 있는가 하면, 검색처럼 사용자 입력에 바로 반응해야 하는 서비스들도 있습니다. 배치 작업은 기계를 최대로 써도 되지만 검색 등은 여유가 있어야 합니다. 단순히 비율로 대수를 나눠 쓰면 비효율적인 면이 커서 자원을 어떻게 배분하느냐가 중요해집니다. 예를 들어 배치 작업이 자원을 다 써버려서 검색 작업이 디스크를 읽느라 느려지면 안 되므로 메모리 사용량도 나누고 CPU나 I/O 우선순위도 조정해야 하는 것이죠. 앞서 말씀 드린 것처럼 기계 한 대에서 조금만 아껴도 합치면 큰돈이 되니까요.

 

마른 수건 쥐어짜기 같군요.

그런 셈이죠(웃음).

 

그래서 재미가 없어진 건가요?

커널 관점에서는 특정 태스크나 워크로드에서 0.5~1% 아끼는 게 전체적인 면에서는 그다지 중요하지 않습니다. 커널 개발 프로젝트 입장에서는 그렇게 아끼는 것보다 장기적으로 봤을 때 코드가 관리, 지속 가능하고 장기 목표를 얼마나 잘 성취할 수 있을까 하는 것이 중요하죠. 아껴서 돈을 버는 게 아니라 프로젝트를 건강하게 오래 유지하는 것이 목표니까요. 서로 목표가 다른 것이라고 볼 수 있습니다. 서비스 제공사는 서비스 개선에 우선순위를 두고 개발하는 것이 중요하지만 저는 아무래도 업스트림 커널 개발자이다 보니 장기적인 목표에 관심이 더 많았습니다.

 

커널 개발자들이 회사에 소속되어 있는 경우가 많은데 업스트림 프로젝트 목표와 회사의 요구 사항 간의 조율은 어떻게 하나요?

구글은 그런 면에서 충돌이 많지 않은 회사라고 볼 수 있습니다. 개발자 개인이 하고 싶은 일을 충분히 할 수 있는 편이기도 하고요. 예전에 비해 지금은 오픈 소스가 워낙 많이 쓰이다 보니 개발자들의 영향력이 강해진 편입니다. 오픈 소스는 특성상 코드가 회사 소유가 아니고 해당 개발자 또는 해당 프로젝트에 속해 있으니까요. 적어도 미국 회사들의 경우 오픈 소스 개발자들은 자율적으로 잘 하도록 미세한 간섭을 하지 않는 편이 효율이 더 높다는 사실을 깨달아가고 있고 오픈 소스 활동을 많이 하는 회사들은 그런 갈등이 별로 없습니다. 한국은 아직도 ‘오픈 소스가 우리 회사에 도움이 어떻게 되는데?’ 하는 인식이 회사에 적지 않게 남아 있는 것 같습니다. 사내에서 그런 인식을 바꾸기 위해 노력하는 것도 중요하지만 여의치 않으면 상황이 더 나은 회사로 옮기는 것도 한 방법일 겁니다.

 

미국 회사에서 개발자들의 영향력을 언급하셨는데 그런 분위기는 어떻게 형성되었나요?

사내에서 개발자의 신분이 낮지 않습니다. 자율성이 보장되고 존중을 받습니다. 구글 같은 회사들에서 개발자 대우 수준이 높아지고 뛰어난 인력들이 입사하면서 다른 회사들도 인력 유치 경쟁에 나서게 되자 점점 좋아진 부분이 많은 것 같습니다. 강압적인 분위기라면 잘하는 개발자들은 다 빠져나갈 테니까요. 개발자가 실력이 있는데 회사에서 대우가 적절하지 않아 개발자들이 계속 빠져나간다면 회사로서는 처우를 개선할 수밖에 없을 겁니다. 게다가 오픈 소스 개발자들은 활동을 하면 커밋 기록이 남아서 자신의 기여가 계속 쌓이게 되고 회사를 옮기기가 어렵지 않으니까요.

 

메인테이너가 되고 나서 달라진 점이 있다면?

평소에 개발을 많이 하고 프로젝트에서 활발히 활동하는 사람이라면 메인테이너냐, 아니냐의 차이는 없는 것 같습니다. 신뢰가 있으니 메인테이너에게 코드를 보내면 대부분 들어가서 큰 차이는 없습니다. 다만 메인테이너가 되고 나서 리누스한테 풀(pull) 요청을 보냈는데 코드가 꼬이면 리누스한테 욕을 호되게 먹습니다. 중간 관리를 잘해야 하는 것이죠. 메인테이너가 아닐 때는 위험한 코드를 마구 짜도 메인테이너가 거부하는데, 메인테이너가 되고 나면 이제 직접 위험도를 관리해야 하고, 제대로 하지 못하면 리누스한테서 싫은 소리를 듣는다는 것이 다른 점이라고 할 수 있습니다.

 

리눅스 커널 개발에 깃(git)이 도입되면서 달라진 점은 무엇인가요?

깃 이전에 쓰던 비트키퍼는 점점 느려지는 단점이 있었습니다. 깃을 쓰면서 확장성도 커지고 개발 속도도 빨라졌습니다. 깃이 메인테이너가 평소에 하는 일과 연관되어 있는데요. 리눅스 커널 개발 프로세스를 대강 살펴보면 우선 트리를 만들고 모아서 머지 윈도(merge window)가 됐을 때 개발 브랜치는 리누스한테 보내고, RC1이 지나고 나면 버그 수정을 모아 보내면서 나중에 합치고 그중에서 백포트가 되어야 하는 것은 ‘stable’로 마킹해서 안정판 관리자 그렉(Greg Kroah-Hartman)에게 보내는 식입니다. 대체로 이런 과정을 깃을 써서 처리합니다. 리눅스 커널 개발 과정과 깃 사용 방법은 함께 변화하고 발전해 오고 있습니다.

 

직접 코드만 짜던 시절과 다른 사람의 코드를 리뷰하거나 거절해야 하는 지금 어느 쪽이 더 재미있나요?

거절의 즐거움이 느껴질 때도 있긴 합니다(웃음). 지금도 코드를 많이 짜고 있는데 리뷰하는 것도 재미있습니다. 일의 종류가 다릅니다. 리뷰할 때는 위험 관리가 굉장히 중요해집니다. 얼마만큼의 위험을 감수할 수 있는지, 얼마만큼 오버헤드가 생길지 예상하는 것 등이 중요하죠. 메인테이너가 아닐 때는 직접 결정하는 게 별로 없으니 그냥 개발해서 코드가 들어가면 들어가는 거고, 아니면 메인테이너 의견대로 고치거나 하면 되는데 지금은 전체적으로 관리하는 게 있으니 메일 등으로 전체 상황을 알리고 방향을 정해서 사람들을 이끌어야 하기도 하는데, 재미있는 과정 같습니다.

 

막대한 양의 메일이 쏟아지는 리눅스 커널 메일링 리스트에서 살아남는 노하우가 있다면.

저한테 직접적으로 중요하지 않은 메일을 읽지 않습니다. 너무 많아서요(웃음). 메일링 리스트 메일을 다 읽는 사람은 극소수입니다. 보통은 전체 메일링 리스트 중에서 자기가 관심 있는 하위 메일링 리스트에 분야별로 가입해 놓고 중요한 것들을 찾아 읽고, 나머지는 LWN에 올라오는 소식들을 읽습니다. 그리고 메일링 리스트를 읽다 보면 기분 나쁜 논쟁들을 보게 될 때가 있습니다. 초창기에는 상처도 좀 받았고 그것 때문에 스트레스 받다 보면 ‘이 일을 계속해야 하나’ 하는 생각이 들기도 했습니다. 기술적인 논쟁이라고는 하지만 개인적인 공격이 섞일 때가 있거든요. 그런데 그걸 너무 심각하게 받아들일 필요는 없습니다. 우선 자신이 하는 일과 자아를 분리할 필요가 있습니다. 개발자들은 대체로 자신이 쓴 코드에 애착도 많고 자기 코드가 공격을 받으면 자신에 대한 공격으로 느끼는 경향이 있는 것 같습니다. 물론 기분이 나쁘지만 거리를 두고 자아에 대한 공격으로 받아들이지 않아야 할 것 같습니다. 개인적인 공격을 받았더라도 그 일이 다른 건으로 이어지는 경우는 별로 없어서 한 번 공격을 받았다고 절망할 일은 아닙니다. 처음에는 상대방의 의견을 좀 들어야 합니다. 기분 나쁘게 표현했든 부드럽게 표현했든 간에 지적한 문제점들은 대체로 맞습니다. 물론 항상 맞지는 않지만 오래 활동하면서 쌓은 지식과 장기적인 계획에 따라 나온 의견이니 겉으로 드러난 표현과는 별개로 요점을 집어내고 확실하지 않은 부분은 다시 물어보고 받아들일 부분은 반영해 다시 보내면 됩니다. 즉 안 좋은 말이 나왔을 때 기분은 분리하고 요점만 잡아서 반영하면 패치가 대부분 들어갑니다. 메인테이너 입장에서는 지적한 문제가 고쳐져 왔으면 그걸로 되거든요. 그러다 보면 신뢰가 쌓이고 마찰도 줄게 됩니다.

 

그동안 개발하셨던 것 중에서 가장 자부심을 느끼는 것은 무엇인가요?

per-cpu를 꼽고 싶습니다. 요즘은 ‘전화기’에도 CPU가 네 개 들어가는 시대인데요. CPU를 보면 레지스터, L1·L2 캐시 등이 있고 메모리가 연결되어 있습니다. 한 CPU가 쓰던 메모리를 다른 CPU가 쓰려고 하면 그 과정이 복잡하고 비싸고 느려집니다. 이런 문제를 해결하는 기법이 여러 가지 있는데 CPU 간에 메모리 공유를 줄이는 것이 중요합니다. CPU별로 메모리를 쓰게 해야 하는데 per-cpu는 문자 그대로 CPU별로 메모리를 할당하는 것입니다. 32바이트를 할당해야 한다면 CPU마다 32바이트씩 할당한 후, 써야 할 메모리를 찾기 쉽도록 인덱싱을 하고 나서 다시 접근이 느려지지 않도록 메모리를 할당할 때 같은 거리로 할당하는 방법 같은 것을 씁니다. 그러면 각 CPU는 기준점에서 자기 거리가 얼마인지 알면 쉽게 원하는 메모리 위치에 접근할 수 있게 됩니다. 또 메모리 접근 방식이 아키텍처마다 달라서 이것저것 고려하면서 작업했던 점이 재미있었습니다.

 

개발 아이디어는 어떻게 수집하시나요?

운영 체제 분야는 학계와 현장이 거리가 커서 학계에서 나오는 논문들이 쓸모가 없을 때가 있습니다. 예를 들면 M:N 스레드 구현을 들 수 있는데요. FreeBSD에서 KSE(kernel scheduled entities)라는 이름으로 구현되기도 했습니다. 논문에서 비롯된 시스템들은 논문 특성상 한정된 범위 내에서 기본 가정을 세우고 그것을 증명하는 방식으로 작성되는 것이 특징입니다. M : N 스레드 방식은 ‘커널 스레드는 비싸고 확장성이 없다’는 가정에서 출발했는데 현실에서는 그 가정이 항상 맞지는 않습니다. NPTL의 경우 커널 스케줄러를 O(1) 방식으로 바꿔 커널 스레드 오버헤드를 낮춤으로써 기존 M : N 스레드의 기본 가정이 성립되지 않는다는 걸 보여주었는데요. 학계 연구와 현장 엔지니어링의 차이를 보여주는 예라고 할 수 있습니다. 저는 아이디어를 현실의 필요에서 얻습니다. per-cpu 같은 경우는 복잡한 아이디어는 아니었고 기존에 정적 할당이란 것을 비슷하게 하고 있었는데 그것을 동적으로 확장한 것입니다. workqueue도 마찬가지였죠. 너무 복잡한 것보다는 목표를 어느 정도 성취할 수 있으면서 간단한 쪽을 선택하는 편이 당연한 것 같습니다. 그래서 아이디어는 현실 요구 사항을 잘 파악하는 데서 온다고 봅니다. 요구 사항을 충분히 파악하면 구현 아이디어는 자동으로 따라오는 경우가 많더군요. 소프트웨어 엔지니어링은 어찌 보면 목공과 비슷한 것 같습니다. 목수가 주어진 나무로 무엇을 어떻게 만들지는 숙련도에 크게 좌우되니까요.

 

요즘 주목하는 요구 사항은 무엇인가요?

cgroups입니다. 클라우드 컴퓨팅이 보급되면서 가상화를 많이 하는데, 가상화의 용도는 한 기계에 여러 종류의 작업을 돌리는 것이라 할 수 있고, 한 기계를 어떻게 나눠 여러 태스크를 ‘잘’ 돌리느냐가 중요해졌습니다. 예전에도 파티셔닝 같은 게 있었지만 그렇게까지 잘 되어 있지는 않았고 널리 쓰이지도 않았습니다. 메모리, CPU, I/O 등을 어떻게 나눠 쓸지는 여전히 개발 중인 분야라 할 수 있습니다. 그래서 재미있습니다.

 

지금 담당하는 분야 외에 도전하고 싶은 분야가 있나요?

per-cpu와 workqueue는 이제 정리가 많이 돼서 어느 정도 궤도에 올랐는데 cgroups는 아직도 엉망이라 현재는 cgroups를 쓸 만한 시스템으로 어떻게 잘 만들 수 있을지 고민 중이고 시간이 걸릴 것 같습니다. 그놈(GNOME) 아시아 행사에서 systemd 개발자 레나르트 푀테링(Lennart Poettering)과 카위 시버스(Kay Sievers)를 만나서 이야기를 나누기로 했는데, cgroups로 자원 관리를 쉽게 할 수 있게 하려면 시간이 더 걸릴 것 같습니다.

 

페이스북, 트위터, 구글 등 대형 서비스들이 리눅스 개발에 준 영향은 어떤 점이 있을까요?

그런 서비스들에서 리눅스를 쓰게 된 이유 중 한 가지는 서버 대수가 많아서 가격이 비싼 상용 운영 체제를 쓰기에는 비용 부담이 크기 때문입니다. 또 소프트웨어 엔지니어 역량을 갖춘 회사들은 굳이 상용 운영 체제 판매사의 기술 지원을 받지 않고 자체적으로 처리해도 되고요. 3~4년 전까지만 해도 리눅스 커널 개발의 초점은 엔터프라이즈 서버였습니다. 어떻게 하면 서버의 성능이나 보안성을 높일 수 있을까 하는 문제 등이 관심이었고 스케줄링이나 메모리 관리 부분 개발도 대체로 그런 측면에 집중됐습니다. 그런 식으로 개발 역량이 엔터프라이즈 쪽에 몰려 있었는데 최근에는 임베디드 비중이 늘고 있습니다.

 

임베디드 쪽에서는 어떤 변화가 있었나요?

전화기 같은 작은 기기에서 효율적인 전원 관리 등이 주 관심 대상이 되는 것 같습니다. 그 외에 모바일 기기의 특성으로 인해 달라지는 부분이 있습니다. 네트워킹 스택의 경우 네트워크 연결이 와이파이에 연결됐다가 이동통신망으로 연결됐다가, 음영 지역에서 끊어졌다가 벗어나면 다시 이어졌다가 하면서 IP 주소가 바뀌기도 하고 애플리케이션들도 연결이 자주 끊기게 됩니다. 보통 지금까지는 애플리케이션이 그런 연결을 다뤄왔는데 모바일 기기에서는 그게 쉽지 않아서 커널 TCP 레이어에서 처리하려는 시도가 있습니다. 연결이 바뀌더라도 애플리케이션 쪽에서는 연결이 유지되는 상태가 될 수 있게 하려는 것이죠. 또 암(ARM) 아키텍처와 관련 드라이버 코드가 더 늘어난 것도 주요한 변화 중 하나입니다. 암 관련 코드가 초기에는 뒤죽박죽이었습니다. 제조사도 여러 군데고 제조사 간 협조가 잘 되는 것도 아니었고 이전(migration)이 중요한 서버 하드웨어와 달리 싸고 교체 주기가 빠른 임베디드 하드웨어는 장기 계획에 따라 개발하는 경우가 많지 않았습니다. 한 IP 블록이 여러 SoC(system on chip)에 들어가면 드라이버를 공유해야 할 것 같은데 제조사마다 해당 코드를 복사, 붙여넣기, 수정해 쓰는 관행 때문에 뒤죽박죽이었던 시기도 있었습니다. 지금은 그런 것들이 상당히 정리된 상황입니다.

 

오늘날 리눅스 커널의 학습 장벽은 어느 정도인가요?

정확히 어느 정도라 말할 수는 없지만 쉽지는 않습니다. 꾸준히 공부할 필요가 있는 것 같습니다. ATA 쪽 드라이버를 보면 드라이버 코드는 작지만 엮이는 부분이 여러 군데입니다. 드라이버와 연결되는 컨트롤러가 있고 컨트롤러는 PCI 버스에 물려 있고 그다음에는 전력 관리도 되어야 하고 블록 레이어와 인터페이싱되는 부분도 있습니다. 하드웨어 측면을 보면 디스크 중에서 ODD 장치들은 SCSI 장치들인데 관련 스펙들도 알고 있어야 하고 연관되어 있는 것들이 많습니다. 하나하나가 학문적으로 대단히 어려운 것은 아니지만 분야가 여러 군데이다 보니 ATA, PCI 등 알아야 할 스펙도 많아서 시간을 많이 들여서 꾸준히 볼 필요가 있습니다. 기반 지식이 형성되면 크게 어려운 것 같지 않습니다.

 

숙련된 커널 개발자가 되는 데 얼마나 걸릴까요?

개인차가 많이 나는 부분 같습니다. 코딩을 어느 정도 한다는 전제하에서 USB나 ATA 같이 크지 않은 부분만 본다고 했을 때 어느 정도 쓸모가 있는 수준까지 습득하려면 전업으로 할 경우 여섯 달이면 되지 않을까 싶습니다. 문제는 (커널 개발이) 누구나 할 수 있는 일은 아니라는 점인데요. 보통 회사에서 사유(proprietary) 소프트웨어를 개발한다고 하면 개발자를 뽑아 그냥 일을 시키면 되지만 오픈 소스 소프트웨어 개발은 회사에서 뽑은 개발자가 코드를 짜도 업스트림 프로젝트에 꼭 반영된다는 보장이 없어서 회사로서는 투자하기 쉽지 않은 면이 있습니다. 그래서 오픈 소스를 많이 쓰는 회사에서는 업스트림 프로젝트에서 이미 활동 중인 사람을 채용하는 경향이 있습니다. 오픈 소스 프로젝트에서 활동 중인 개발자들이 직장을 구하기가 그다지 어렵지 않은 이유도 그 때문이라 볼 수 있습니다. 업스트림에서 함께 일한 개발자들끼리는 서로 직장을 소개해 주기도 하죠. 하는 일은 그대로인데 회사만 옮기는 사람들도 있고요.

 

커널 서브시스템 개발을 돕는 사람은 보통 몇 명인가요?

꾸준히 활동하는 사람은 많지는 않고 서브시스템당 많아도 세 명 정도입니다. 그 외에는 가끔 패치를 보내거나 필요할 때 잠깐씩 왔다가 사라지는 사람들입니다. 스케줄러나 메모리 관리 쪽은 사람이 좀 더 있기는 한데, 메모리 관리의 경우도 부분별로 들어가면 역시 두세 명 정도 개발합니다.

 

같이 개발하기에 적정 인원은 몇 명이라고 생각하시나요?

아무도 없으면 위험하고 힘들기도 하고 일이 생겼을 때 넘겨줄 사람도 필요하니 많으면 좋은데, 실제로는 그렇게 되지 않아서 지속적으로 기여하는 사람이 서너 명만 되어도 좋을 것 같습니다. 3.9 버전 개발 주기인 약 3개월간 패치를 보낸 총 개발자 수가 1300명 정도 됐는데 상위 100명 정도가 전체 패치의 절반 이상을 보냈다는 그래프를 본 기억이 있습니다. 실제로 맡아서 개발하는 사람 수는 그렇게 많지 않은 거죠. 활동을 많이 하는 사람은 100명 안쪽인 것 같습니다.

 

잘하는 사람이 일정 인원 이상 필요한 셈이군요.

전체 인원만 보면 1000명 넘게 참여하니 인력이 넘쳐날 것 같지만 꼭 그렇지도 않은 게, 서브시스템별로 사람이 늘 부족하다는 느낌이 지금도 있고 여전히 인력이 필요한 상황입니다.

 

리눅스 개발은 최종 결정 권한이 흔히 ‘자비로운 종신 독재자(benevolent dictator for life)’라 부르는 한 사람에게 주어진 모델인데 큰 패착 없이 잘 유지되어온 비결은 무엇일까요?

리누스가 독재(?)를 워낙 잘하는데 그 영향이 큰 것 같습니다. 전 세계 이곳저곳에 흩어진 수백 명의 사람들을 일정한 흐름으로 끌고 가는데요. 그렇게 움직일 수 있는 문화를 리누스가 잘 만든 것 같습니다. 어떤 코드를 받아들일 수 있는지, 어느 방향으로 갈 건지, 개발 철학은 어떤지 하는 내용이 이제는 상위 개발자들 사이에서는 상당히 공유된 상태입니다. 이런 공통된 문화가 있어서 코드를 리뷰할 때나 개발 방향을 정할 때나 누군가가 이상하다고 하면 다른 사람들도 이상하다고 할 교감 같은 것이 있습니다. 다양한 사람이 모여 있지만 개발을 관리하는 사람들 간에는 균질한 문화가 형성되어 있는 거죠.

 

명시적 절차보다는 암묵적인 합의나 공감대가 중시되는군요.

예. 뭘 잘못하면 리누스가 화를 내는지 반복 학습이 되어 있죠(웃음). 명시적인 위원회나 절차는 없지만 암묵적인 구조가 잘 만들어진 것 같습니다.

 

약 3개월 간격으로 나오는 커널 최신판을 따라가기란 쉬운 작업이 아닌 것 같습니다.

배포판 개발사들을 보면 잘 따라가는 것 같습니다. 새 배포판을 출시할 때 최신 커널을 탑재하는 배포판도 있습니다. 제때 쫓아가지 않으면 오히려 더 괴롭거든요. 배포판의 경우 선택의 여지가 없는 것 같습니다. 버전 차이가 벌어지면 나중에 감당하기 어렵습니다. 6개월마다 쫓아간다고 할 경우 그사이에 뭔가가 잘못되면 그 기간 안에서 문제를 찾아 고칠 수 있는데 주기가 2년이라면 원래 개발했던 사람이 다른 일을 하고 있을 수도 있고, 그동안 2년 전 코드 중 특정 부분에 의존하고 있었다면 그 부분 때문에 고치지 못하는 상황을 겪을 수도 있습니다. 코드도 많이 바뀌어 있을 테니 2년 전에 고친 부분을 새 버전으로 옮기려면 망망대해에서 헤매는 것 같을 수도 있고요. 그래서 쫓아갈 수밖에 없고 어느 회사든 더 빨리 따라가려고 노력을 많이 합니다.

 

10년 넘게 이 일을 해오셨는데 오픈 소스 개발의 매력은 무엇인가요?

커널 개발을 해왔는데 로우 레벨 소프트웨어를 좋아하는 건 그냥 제 성향인 것 같습니다. 사람에 따라 좋아하지 않을 수도 있고, 응용 서비스 개발을 좋아할 수도 있고요. 넓은 관점에서 오픈 소스 개발에 대해 보자면, 개발자에게 힘이 생기는 것 같습니다. 회사가 소유한 소프트웨어는 프로그래머가 개발을 하다 회사가 프로그래머를 해고하거나 프로그래머가 그만두면 그 코드는 여전히 회사 자산이고 프로그래머는 또 다른 일을 찾아야 하는데 오픈 소스의 경우 개발자가 회사를 그만두거나 옮겨도 회사가 그 코드를 뺏을 수 있는 게 아니고 그 개발자가 계속 관리하는 것이라서 개발자의 힘이 강해지고 회사도 오픈 소스 개발자들을 유연하게 대하게 됩니다. 자기가 하고 싶은 일을 더 많이 할 수 있고 좀 더 자유롭고 유연하다는 면에서 매력적입니다. 또 오픈 소스가 아닌 소프트웨어를 개발하는 경우 출신 국가나 학교 등의 제약을 받기도 하는데 오픈 소스 개발자들은 그런 제약이 거의 없고 출신 학교나 학위에 상관없이 코드 커밋으로 자신의 가치를 증명할 수 있고 회사 선택의 폭이 넓어진다는 장점이 있습니다. 첫 직장 생활에서 아쉬웠던 것 한 가지는 제가 개발한 코드가 널리 쓰이지 않는다는 점이었습니다. 어떤 고객의 요구 사항으로 맞춤 기능을 개발하면 그 기능은 그 고객만 쓰고 마니까요. 약간 재미가 없었습니다. 그런데 지금은 제가 만든 코드가 많이 쓰인다는 점이 매력이 있습니다.

 

미국에서 외국인 노동자로서 삶은 어떤가요?

가족이 한국에 있다는 게 마음에 걸린다는 점을 제외하면 좋습니다. 사람에 따라 맞지 않는 경우도 있긴 하죠. 익숙하지 않으니까요. 외국 생활 첫 1~2년은 좀 힘든 것 같습니다. 한국에서는 다 큰 어른이라고 생각했는데 외국에 나가면 현지 사정을 잘 모르니 낯선 것투성이고 말도 잘 통하지 않아서 힘들죠. 그 시기만 지나면 좋은 것 같습니다. 제 주변에 한국에서 온 친구들이 꽤 있는데 다들 좋아합니다. 한국에 비해 소득도 높고 대우도 좋고 위에서 시키는 대로만 일하는 게 아니라 자기 주도적으로 일할 수 있고 권한도 상당히 주어지고 유연성도 높아서 재택근무나 출퇴근 시간이 자유로운 회사도 많습니다. 엔지니어로서는 자신의 엔지니어링 능력이 높게 평가받는다는 느낌이 들게 되죠. 실제로 그렇기도 하고요. 또 실리콘 밸리 회사들의 경우 기술 경쟁 최전선에 있어서 새로운 걸 시도해 볼 수 있는 기회가 자주 있습니다. 그 외에도 개발을 오래 한 엔지니어들이 많은데요. 60세 넘어서도 개발을 계속하기도 하고 그렇게 경험 많은 선임 엔지니어 군이 형성되어 있고 동료들 중에 똑똑한 사람들도 많고요. 한국에서는 선임 엔지니어 층이 잘 형성되지 않고 있다 보니 맨땅에 박치기하는 일이 반복되고 그런 상황에서 실력 있는 사람들은 주변에 교류할 사람들이 점점 줄어들게 되죠. 그런 면에서 외국에 나갈 기회가 있으면 무조건 나가서 직장 생활을 해보는 것은 경력 관리나 여러 면에서 좋다고 생각합니다.

 

국적이나 국경에 얽매일 필요는 없겠군요.

예. 그게 중요한 것 같습니다. 몇 마디 말로 단기간에 개발자 대우가 개선된다거나 자율성이 주어진다거나 선임 엔지니어 층이 두터워진다거나 하는 식으로 사회가 변할 것 같지는 않은 상황에서 잘하는 개발자들은 외국으로 나가는 수밖에 없는 것 같습니다. 그 편이 개인한테도 좋을 것 같고요. 아직은 국경이나 언어, 문화가 경계이긴 하지만요. 사실 미국도 소프트웨어 엔지니어 대우가 개선된 것은 실력 있는 개발자들이 더 나은 직장을 찾아 떠나기 때문입니다. 뛰어난 개발자들이 더 좋은 회사로 몰리고 구인 경쟁이 생기면서 대우가 좋아지고 상승 작용이 일어나 똑똑한 사람들이 더 많이 모여 업계가 발전하는 선순환이 된 셈이죠. 외국에서 오래 살지 않고 4~5년만 있어도 자기 경력에 훨씬 도움이 되리라 봅니다.

 

현재 쓰시는 개발 도구 또는 환경은 무엇인가요?

이맥스와 C 컴파일러, qemu 정도입니다. 그 외 도구는 많이 사용하지는 않고 디버거도 메모리 주소 맞춰볼 때 주로 쓰는 정도입니다.

 

거의 기본 도구만 쓰는 특별한 이유가 있나요?

디버거나 IDE 같은 도구를 많이 쓰지 않게 되는 이유는 그다지 효율적이지 않고 생산성이 오르지 않아서입니다. 일의 종류가 달라서겠죠. 하이 레벨 언어에서 하는 리팩터링 같은 것이 생각만큼 잘되지도 않고요. 일정 분량의 코드를 쓰는 데 들어가는 노동량이 운영 체제 개발의 경우 상당히 많습니다. 자동화 도구는 대량의 코드를 효율적으로 다뤄야 할 때, 이를테면 잡무를 줄이고 로직에 집중할 때 유용한데요. 운영 체제 개발의 경우 기본 노동량 자체가 많다 보니 자동화 처리로 효과를 볼 수 있는 부분이 상대적으로 미미한 편입니다. 다만 IDE나 valgrind 같은 도구는 잘 쓰지 않지만 커널 안에 들어 있는 개발에 도움이 되는 도구들, 예를 들어 메모리 오염이나 누수 탐지 도구 같은 것은 활용합니다. 운영 체제 이외의 소프트웨어들은 운영 체제와 환경이 있고 그 안에서 실행되면서 주변 도구의 도움을 받을 수 있는 반면, 운영 체제는 기계 위에서 바로 동작하므로 주변에서 도움을 받을 게 없습니다. 디버깅의 경우 기존 디버거는 운영 체제 버그 해결에 그다지 쓸모가 없습니다. 운영 체제 개발에서 까다로운 버그들은 주로 동시성과 관련된 문제이거나 정말 낮은 확률로 발생하는 문제들일 때가 많습니다. 이런 문제들은 디버거를 붙여 봐도 재현하기도, 찾기도 어렵습니다. 디버거로 할 수 있는 건 잘해 봐야 문제가 생긴 후 어떤 문제가 생겼는지 상태를 보는 정도라서 큰 역할을 하는 것 같지는 않습니다. 그래서 커널 안에 도움이 될 도구들을 만들어 놓습니다. qemu의 경우는 qemu에 디버거를 직접 붙이거나 커널을 빌드한 후 설치하지 않고 qemu한테 빌드한 커널 이미지로 부팅을 명령하면 바로 부팅할 수 있습니다. 환경이 다르고 기존 하이 레벨 도구들이 큰 쓸모가 없을 뿐, 종류가 다른 도구들을 쓰고 있습니다.

 

커널 내장 도구들은 어떤 것들이 쓰이나요?

예를 들면 lockdep(locking dependency)이란 것이 있습니다. 커널은 동기화를 많이 하는데 그 과정에서 데드락이 생기기도 합니다. 락이 워낙 많다 보니 어디서 문제가 생길지 알아내기가 쉽지 않습니다. 커널 안에서 lockdep 옵션을 켜면 락이 걸리는 순서(sequence)를 추적해 가능한 모든 조합을 만들어서 데드락이 생기지 않을 부분을 증명하고, 증명되지 않는 부분은 경고 메시지를 띄웁니다. 데드락은 타이밍이 맞아야 발생해서 재현하기가 어려운데 데드락 발생 가능 여부를 증명해 주는 거죠. 리눅스 커널 소스를 보면 이런 도구들이 많은데요. 프로파일링 관련 도구로 perf 라는 게 있습니다. 지금은 사용자 공간에서도 쓸 수 있게 확장되어 있습니다. 외부 도구를 붙여 쓰는 게 적합하지 않을 때가 많다 보니 커널 내부에 도구가 생성돼서 전체적인 인프라스트럭처가 구성되고 있는데 특히 성능 모니터링은 상당히 잘되어 있습니다. 대체로 시스템 동작 중에 시스템을 모니터링할 수 있는 동적 도구들이 유용합니다.

 

C 이외의 언어로 운영 체제를 개발하는 날이 올까요?

자바 같은 언어로 운영 체제를 개발하는 건 현재로서는 무리이고 추상화 수준이 높아져도 C++ 정도가 한계인 것 같습니다. 프로그래밍 언어의 기본적인 기능은 사람이 하고자 하는 일을 컴퓨터가 알아듣는 말로 바꾸는 것인데, 그보다 더 중요한 측면은 같이 일하는 동료 개발자들 사이에서 의사소통 수단이라는 점입니다. 혼자서 프로그래밍을 한다면 상관없겠지만 운영 체제는 워낙 크고 참여자 수도 많다 보니, 1000명 단위죠, 내가 쓴 코드를 다른 사람이 알아볼 수 있어야 하는데요. C++의 문제는 언어가 너무 커서 사람들이 제각각 C++ 사투리를 쓴다는 점입니다. 바벨탑이 되어 버리죠. 서로 말이 통하지 않아 협업에 방해가 되는 사태가 일어나기도 하죠. 그래서 C를 벗어날 일은 별로 없는 것 같습니다. C 이후 C보다 하이 레벨 언어들은 많이 나왔지만 C와 비슷한 로우 레벨은 언어는 나오지 않았는데 만들려는 프로그램의 추상화 레벨에 맞춰 언어를 선택하는 것이니 운영 체제 개발에서 C 이외의 언어로 바뀔 가능성은 낮은 것 같습니다.

 

그동안 겪었던 것 중 최악의 버그는 무엇이었나요?

딱히 떠오르는 건 없는데 디버깅 후 욕이 나왔던 버그는 있었습니다. 개발하다 보면 멍청한 짓을 하는 경우가 있습니다. 코드를 썼는데 괄호를 하나 잘못 썼다든지, 변수를 실수로 덮어쓴다든지 하는 바보 같은 버그들이 있습니다. 얼핏 보면 맞는 것 같은데 그런 식으로 헷갈려 한 줄 틀리고 나서 하루 또는 2~3일씩 보는 버그들이 있습니다. 그런 황당한 것들이 생각이 많이 납니다.

 

오랜 시간 돌려야 발생하는 버그들은 어떻게 해결하시나요?

락 관련 버그들은 잡기가 정말 어려웠습니다. 재현도 잘 안 되고 못 잡을 때도 많고요. 앞서 말씀드린 lockdep의 경우 그런 것을 수학적으로 모든 조합을 구해 알려줘서 약간 수월해졌는데 다른 양상으로 복잡하고 해결 방법이 마땅치 않은 버그들도 있습니다. 예를 들어 컴퓨터가 20일에 한 번씩 죽는데 아무런 로그도 남지 않는 버그들도 있습니다. 어디에서 나오는 버그이고 어떤 패턴으로 실패한다는 것까지만 알아도 관련 코드를 대상으로 실험을 해볼 수 있는데 그런 정보조차 없으니 괴로운 버그입니다.

 

어느 날 홀연히 사라지기만을 빌어야 하는 건가요?

모른 척하고 싶습니다(웃음). 오랫동안 못 잡는 버그들이 약간 있습니다. 또는 들이는 노력에 비해 소득이 없으면 포기하기도 하고요. 거의 쓰이지 않는 오래된 하드웨어 관련 버그들이 그 예입니다.

하드웨어는 몇 년 주기로 버려지는데(?) 소프트웨어는 오래도록 쓰이게 만들어야 한다는 건 나름 고충 같습니다.

하드웨어는 구기종에 결함이 있으면 신기종에서 고쳐서 새로 만드는데 소프트웨어, 특히 운영 체제는 이것저것 지원해야 하는 것이 많아서 옛날에 실수한 것도 계속 끌고 가야 하다 보니 복잡도가 계속 올라가게 됩니다. 하드웨어는 정 안 되면 버리면 되는데 운영 체제는 그렇지 못 하니 힘든 것 같습니다.

 

자신만의 운영 체제를 직접 만들고 싶다는 생각을 해보신적은 없나요?

앞서 재규어 3000을 개발하던 시기에 스레드 패키지를 만들었다고 말씀드렸는데 그 패키지 안에 스케줄러, 메모리 할당기, I/O 이벤트 등이 들어가 있었습니다. 사실 원래는 운영 체제를 만들고 싶어서 재미로 개발했던 것이죠. 하드웨어 위에서도 동작했던 것인데 운영 체제로서 가망성이 높지 않아서 유저랜드 스레드 패키지로 만들어서 재규어 3000에 썼던 거죠. 지금에 와서는 운영 체제 개발을 재미로 할 수는 있겠지만 리눅스만큼 큰 규모로 성공하는 오픈 소스 운영 체제가 나올 가능성은 굉장히 낮은 것 같습니다. 새로운 운영 체제를 만든다고 했을 때 들어가는 비용 대비 효과가 크지 않아서 범용 오픈 소스 운영 체제를 만들기는 현실적으로 어렵다고 봅니다.

 

영향을 가장 많이 받은 개발자를 꼽는다면 누구인가요?

올렉 네스테로프(Oleg Nesterov)라는 개발자를 굉장히 좋아합니다. 운영 체제 개발에서 어려운 문제는 역시 동기화 문제입니다. 락 관련 문제는 lockdep이 대부분 찾아주니 괜찮은데 락 없이 메모리 경계를 써서 CPU마다 메모리 접근 순서를 사용해 동기화하는 경우가 있습니다. 그러면 더 싸고 빠릅니다. 그런데 하다 보면 틀리기 쉽습니다. 보통은 잘되는데 정말 희한한 케이스로 틀리는 경우가 많습니다. 올렉은 그렇게 복잡하게 꼬인 것들을 정말 잘 찾아내는데 가끔은 사람 머리가 아닌 것 같다는 생각이 들기도 합니다. 어떻게 하는지는 잘 모르겠는데 머릿속에서 뭔가 흐름이 다 보이는 게 아닌가 싶습니다. 개발하다 동기화나 메모리 경계 관련 문제가 굉장히 복잡해져서 자신이 없을 때 무조건 올렉에게 물어봅니다. 올렉이 이상이 없다고 하면 자신감이 생깁니다(웃음). 어려운 일이 있을 때마다 도움을 많이 받습니다.

 

자신만의 재충전 방법이 있다면.

산악자전거를 탑니다. 지금 사는 곳에서 가까운 산타 크루즈 지역이 산악자전거로 유명하고 산악자전거 회사와 가게도 많습니다. 일주일에 세 번 탑니다. 함께 타는 사람들의 모임이 있는데 빠지면 벌금 100달러죠(웃음). 한 번 타면 두 시간 정도 탑니다. 그 동네 토박이 중에는 어렸을 때부터 산악자전거를 탄 사람들이 있는데 그래서인지 정말 잘 탑니다. 저보다 잘 타는 50대 어른도 있고요. 한 번 타고 나면 스트레스도 풀리고 체력도 좋아져서 일도 많이 할 수 있게 됩니다(웃음).

 

평소에 집중력이 유지되는 시간은 어느 정도인가요?

긴 편은 아닙니다. 생각을 많이 해야 하는 작업은 그만큼 정신력이 많이 소모돼서인지 긴 시간 일하지 못하는 것 같습니다. 잘 떠오르지 않으면 스트레스도 심하고요. 다만 반복적인 작업은 긴 시간 오래 하는 편이죠.

 

이 분야 일을 시작하는 개발자에게 해주고 싶은 조언이 있다면.

동네가 험해도 상처받지는 마시고(웃음) 꾸준히 참여하다 보면 경험이 쌓이고 신뢰가 생기는 것 같습니다. 사람이 상처를 받고 나면 그 일에 다시 손대기도 싫고 상처 준 사람과 이야기하기도 싫은데 그런 것에 너무 신경 쓰지 말고 꾸준함을 유지하는 것이 중요합니다.

 

어떤 모습의 개발자로 늙어가고 싶으신가요?

휴 디킨스(Hugh Dickens)라는 개발자가 있습니다. 60대 할아버지인데 지금도 현역이고 리눅스 커널 메모리 관리 부분 핵심 개발자입니다. 저도 일하는 게 재미있어서 오래도록 일하고 싶고 나이 들어서도 계속 일할 수 있다면 좋겠습니다. 처음에는 놀랐는데 휴 디킨스 같은 개발자가 꽤 있고 그게 좋은 것 같습니다. 또 카위 시버스가 일하는 모습을 보면 돈을 벌려고 일을 한다기보다는 새로운 것을 만들기를 즐기는 것 같습니다. 자기가 하고 싶은 일을 계속 찾아서 하고, 가고 싶은 콘퍼런스가 있으면 자기 돈 내고 가기도 하고요. 그런 태도가 정말 좋아 보입니다.

 

앞으로 계획이 있다면.

뉴욕으로 이사를 가볼까 생각 중입니다. 이사를 가게 된다면 재택근무를 할 예정이고요. 회사 분위기가 어떤 형태든 일을 제대로 하고 있으면 이사를 가든 출국을 하든 크게 신경을 쓰지 않는 분위기입니다. 직장과 관련해서는 현재 하고 있는 일이나 직장에서 자율성에 만족하고 있어서 당분간은 이직 같은 변화는 생각하고 있지 않고요. 리눅스 커널 쪽으로는 cgroups를 쓸 만한 형태로 만들어 보는 게 중기 목표입니다. 앞서 말씀드린 대로 레나르트와 카위를 만나서 이야기를 나눠봐야 하는데 systemd와 통합하는 것도 고려하고 있습니다. 일단은 커널 쪽에서 인터페이스를 준비하고 있고 그게 맞춰지면 systemd와 통합해서 자동으로 시스템에서 사용될 수 있게 하는 구상을 하고 있습니다. 자원을 배분하려면 시스템에 어떤 서비스가 도는지, 어떤 사용자 세션과 컨테이너가 있는지, 어떤 가상 머신이 실행 중인지 알아야 하고 그래야 그 사이에서 자원을 얼마만큼 쓸지 정해줄 수 있습니다. 그런 것들을 관리하는 게 systemd라서 systemd에 통합하는 게 가장 좋을 것 같습니다. 그렇게 해서 자원을 정적 또는 동적으로 관리할 수 있게 하는 거죠. 그다음 장기 목표는 아직 잘 모르겠습니다.

 

인터뷰이 소개: 허태준

전업 리눅스 커널 개발자가 된 지 9년째이고 현재 레드햇에서 일한다. 원래 운영 체제에 관심이 많아 리눅스 공부와 개발을 시작했는데 이래저래 잘 풀려 자유롭게 하고 싶은 일을 하며 지내고 있다. 오픈 소스가 산업의 중심으로 성장하고 기술 진보의 첨단에 있는 오늘날, 의미 있고 재미있는 일을 찾는 데 오픈 소스 참여만큼 효과적인 길은 드물다고 생각한다.