칸드로이드 저널- "Beyond Android" 
GNU libc의 전환점 - lwn.net 번역
작성자
작성일 2012-04-06 (금) 07:08
ㆍ추천: 0  ㆍ조회: 4397      
IP: 125.xxx.222
 
출처 : http://lwn.net/Articles/488847/
 

A turning point for GNU libc (GNU libc의 전환점)

                                                                - 2012.3.28, Jonathan Corbet
 
 
커널이 리눅스 시스템의 코어가 될 수는 있지만, 사용자와 애플리케이션은 커널과 직접적으로 대면하지는
않는다. 대신에, 커널과의 모든 상호작용은 C 라이브러리를 통해 관리된다. 이러한 C 라이브러리는 커널이
제공하는 기능들에 대한 인터페이스들을 포함하며, 표준을 준수하고 있다. 다양한 C 라이브러리들이
존재하지만, 임베디드 분야 이외의 대부분의 리눅스 시스템은 GNU C 라이브러리를 사용한다. 흔히들
이것을 "glibc"라 부른다. glibc 이면에는 흥미로운 개발 프로젝트 역사가 있다.  이것은 지난 3월 26일 glibc
운영위원회의 해산과 함께 새로운 전환점을 맞이하고 있다.
 
초기에, GNU 프로젝트는 절대적으로 중요한 몇몇 프로젝트에 집중할 수밖에 없었다. 이것이 바로 GNU 우산
속에서 최초로 릴리즈된 첫번째 프로그램이 Emacs였던 이유이다. 일단 핵심이 제자리를 잡았지만,  개발자들은
새로운 시스템을 만들기 위해 그밖의 몇몇 컴포넌트들이 필요하다는 사실을 깨달았다. C 라이브러리는
이러한 목록중에서 가장 부각되는 것이었다. 그래서, 1987년에 Roland McGrath가 GNU C 라이브러리 개발을
시작했다. 1988년에 시스템들이 그것을 기반으로 만들어질 수 있는 정도로 충분히 많이 진행된 것처럼 보였다.
 
1991년에 리눅스 커널이 나오면서, 최초의 리눅스 배포판을 만들기 위해 GNU libc는 그밖의 많은 GNU 컴포넌트들
처럼 필수적인 요소였다. 그러나 GNU libc가 좋은 시작점이긴 했지만, 다음과 같은 것 또한 바로 명백해졌다.
(1) 여전히 많은 작업이 필요하다는 것, 그리고 (2) GNU 프로젝트 관리 스타일이 고전적인 방법이어서, 작업을
해서 합치는 것이 어렵다는 것이었다. 그래서 리눅스 초기에는, GNU C 라이브러리를 복제해서 리눅스에 제한된
버전인 "Linux libc"가 사용되었으며, 리눅스 배포판과 함께 배포되었다.
 
GNU 프로젝트는 리눅스가 이러한 시기에 모든 것을 만들기 위해 노력했던 시스템이었다는 사실을 다소 느리게
알아차렸다. 그들은 리눅스가 그것을 사용하지 않음에도 불구하고 자신만의 C 라이브러리르 계속 개발했다.
초기에 거의 모든 작업은 Roland가 했다. 하지만 천천히 다른 공헌자들이 나타났다. Ulrich "Uli" Drepper에 의한
첫번째 공헌이 1995년 9월에 이루어졌다. 1997년 초에 첫번째 glibc 2.0 릴리즈가 나왔다. 그때까지는 대부분의
커밋들이 Ulrich에 의해 이루어졌다.(가끔은 코드들이 다른 곳에서 왔음에도 그러했다.)
 
리눅스 libc는 그럭저럭 유지관리되어왔지만, 광범위한 양의 신규 개발 작업은 없었다. 사실 glibc 2가 많은
면에서 더 나은 C 라이브러리였기 때문에, 이것을 명확히 할 시점이 되었다. 리눅스 배포자들은 
GNU 라이브러리로 다시 바꿀 때가 되었다는 결론에 이르렀다. 모든 실용적인 목적차원에서, 간단히 리눅스
libc 프로젝트를 포기했다. (레드햇 5.0과 데비안 2.0 릴리즈에서 보였던 것 처럼) 수반되는 변화를 겪어야
했던 이들에게 있어서 그것은 여전히 몸서리치는 경향이 있었다. 프로그램들이 빌드되지 않고 버그가 많았던
시기가 있었다. 그러나 결국 상황은 진정되었고, 그 이후 glibc는 대부분의 리눅스 배포판에서 표준 C 라이브러리가
되었다.
 
Glibc는 오늘에 이르기까지 다양한 속도로 발전해 왔다. 대부분의 이 시간동안 큰 작업들이 Ulrich Drepper에
의해 이루어졌다. 프로젝트의 git 저장소에서 발견된 (1995년 이후의 변경된) 거의 19,000 커밋 중에서
12,000건 이상이 Ulrich에 의해 이루어졌다. 다른 이들에게 미루고자 하는 의지가 없었기 때문에, Ulrich는 빠르게
glibc에 대한 의사결정자가 되었다. 2001년 FSF는 몇가지 통제 단서를 두면서 그 프로젝트의 운영위원회를
공식화하였다. 하지만 대부분의 통제권은 Ulrich의 손에 남겨졌다. 2008년에 Roland는 그 상황을 이런 방식으로
설명했다.
 
      drepper, roland는 커밋에 대한 포괄 재량권을 갖는다. (이것은 Uli가 원하지 않는 것을 내가 커밋했을 때,
      그가 나의 생각에 영향을 행사할 수 있다는 것을 의미한다. 그것은 Uli가 거절한 어떤것을 커밋하기 위해
      여러분이 나에게 로비할 수 있다는 것을 의미하지 않는다.)
 
네명의 다른 개발자들(Andreas Jaeger, Jakub Jelinek, Richard Henderson, Andres Schwab)은 승인 후 커밋
능력을 가졌다. 하지만 그 승인은 결국에는 Ulrich에 의해 이루어졌다. 아무도 Ulrich가 glibc 프로젝트를 관리
하는 방법에 대한 불만을 찾기 위해 드려다 보고 있을 필요는 없었다. 그는 어리석은 짓을 용인할 사람이 결코
아니었다. 그리고 분명히 그는 수많은 바보들에 의해 둘러싸인 자신을 발견했다. glibc내에 변화를 만들고자 하는
시도는 종종 심각한 논쟁을 일으키거나 또는 단순히 무시되었다. 개발자들은 어떤 것을 이루는데 자주 좌절했으며
쉽게 포기했다. 가끔 Ulrich의 태도를 비난하는 것은 쉽다. 하지만 또한 누군가는 그가 했던 모든 작업의 흔적을
잃지 않아야 했다. 이것은 glibc에 대한 꾸준한 개선과 (Ingo Molnar에 의해 이뤄진 Native POSIX Thread Library
와 같은) 기능상의 큰 도약, 많은 수정들을 포함했다. Ulrich의 작업은 우리들 시스템 전체를 더 좋게 만들었다.
 
그럼에도 불구하고 그 작업으로 인해서, Ulrich는 glibc 프로젝트를 환영받지 못한 공간으로 바꾸었던 불쾌한
메인테이너로써 널리 비춰졌다. glibc가 실제로 대성당 스타일 프로젝트, 즉 매우 안락한 사제직과 더 넓은 세상의
필요에 대한 자각과 흥미의 결핍, 기타 등등 과 크게 연관된 여러개의 문제를 가지고 있다는 것을 지적하는 것과
같은 도전을 누군가가 할 필요는 없었다. 언젠가는 glibc와 관계된 여러 개발자들에게 이 프로젝트가 단일한
제어보다는 보다 더 오픈된 프로젝트가 될 필요가 있다는 것이 외견상으로 명확해 질 것이기 때문이다. 여러
변화들이 프로젝트를 그 방향으로 이끌기 위해 이루어졌다.
 
2009년 5월에 소스 코드 관리가 Git로 변한 것이 그러한 하나의 변화다.  그 시점에, 저장소는 비핵심
메인테이너가 브랜치를 유지할 수 있도록 좀 더 많이 오픈되었다. Ulrich는 그 결정에 반대했지만 Roland는
다음과 같이 대응했다.
 
      보수적인 막연한 근거 또는 기본적인 불신때문에, 커뮤니티의 나머지 사람들이 협업을 개선하고자
      하는 것을 사소하게 생각하지 않았으면 합니다.
 
프로젝트는 분리된 릴리즈 브랜치를 생성하기 시작했으며, 그 책임자로 Ulrich가 아닌 다른 사람이 임명되었다.
제한적으로 접근되던 "libc-hackers" 메일링 리스트는 사용되지 않았고 문을 닫았다. 사적인 테스트 환경의 종류로써
페도라의 사용은 상황이 자주 바뀌면서 중단되었다. 그리고 강력한 시도가 더 많은 개발자를 격려하고 더 많은
코드를 모으기 위해 이루어졌다. 그 결과 아래와 같이 보이는 릴리즈 기록을 갖게 되었다.
 
     Release       Date         Changes 
     2.3         2002-10-03      3204 
     2.4         2006-03-06      5276 
     2.5         2006-09-29        348 
     2.6         2007-05-15        357 
     2.7         2007-10-18        446 
     2.8         2008-04-12        281 
     2.9         2008-11-13        293 
     2.10       2009-05-09        344 
     2.11       2009-10-30        408 
     2.12       2010-05-03        389 
     2.13       2011-01-17        261 
     2.14       2011-05-31        256 
     2.15       2011-12-23        582

 
(2.15 일자는 그 릴리즈가 태크가 붙었던 때이다. 어떤 이유에서든, 발표가 몇개월 늦어졌다) 2.15 릴리즈는 개발
버전을 부여함에 있어서, 소수점 아래를 다 사용한 이후 버전을 증가시키는 것을 제안하고 있다. 확실히, 2006년에
중간 규격 릴리즈가 시작된 이후 이것이 가장 큰 숫자이다. 2.15 이후의 활동은(이 글의 작성 시점에, 483 커밋)
최근의 역사적인 표준들 때문에 계속 높아졌다. 아마도 더 효과적으로, 오직 이러한 커밋의 약 25%가 Ulrich에 의해
이뤄졌다. 2.10에서 2.14까지의 변화의 60% 이상이 그가 담당했던 것이 비하면, 중요한 변화가 일어났다는 것을
보여준다.
 
또한 중요한 것은 Ulrich가 2010년 9월 레드햇을 떠났다는 사실이다. 그의 LinkedIn 페이지에 따르면, 그는 이제
골드만 삭스의 기술 파트 부사장이다. 누구든 쉽게 그의 새로운 자리가 glibc 유지보수와 관련없는 요구사항만을
가지고 있을 것이라고 상상할 수 있을 것이다. 그러므로 참여가 줄어든 것은 전혀 놀라운 것이 아니다. 중요한 것은
기강을 바로 잡는 것보다 성장하는 커뮤니티이다.
 
3월 26일에 Roland가 더이상 glibc 운영위원회가 필요하지 않다고 발표했을 때, 이러한 경향이 정점에 이르렀다.
 
      최근의 자원봉사자들의 노력이 다시 고무되면서, 개발자 커뮤니티가 이제 그 자체를 통제할 수 있게 되었다.
      그러므로 운영위원회는 만장일치로 해산하기로 결정했다. 프로젝트의 방향과 정책은 이제 glibc 개발에 참여
      하는 사람들의 합의에 의해 직접적으로 통제될 것이다.
 
Glibc는 GNU 우산하의 프로젝트로 남을 것이다. Roland,Joseph Myers, Carlos O'Donell 이 공식적인 GNU
메인테이너가 될 것이다. 그러나 그 역할이 그들에게 어떤 특수한 의사 결정 힘을 주지는 않을 것이다. 그러한 힘은
전체로써 프로젝트 개발 커뮤니티에 의해 행사된다는 것을 의미한다. David Miller(활동적인 glibc 공헌자)는
이 변화를 바로 축하했다.
 
      만약 여러분이 과거에 glibc에 공헌하기를 시도했고 그리고 무례하게 취급되었고 그래서 포기했다면,
      나는 여러분이 돌아와서 다시 시도하길 격려한다. 이제 상황은 많이 달라졌다. 내가 약속한다.

 
David는 또한 공헌에 대한 그밖의 가능한 장애물(FSF의 저작권을 부여하는 요구사항) 또한 보유할 수 있는
솔루션의 형식은 미확정이지만 작업중이라는 것을 암시했다. 그밖의 개발자들은 이미 EGLIBC 복제에서 있는
변화들 중 일부를 glibc 메인라인에 다시 합치는 작업과 오래된 버그들을 다시 보는 것, 그리고 변경 요구들에 대해
이야기하고 있다.
 
그러므로 GNU C 라이브러리 프로젝트는 새로운 장으로 이동되었다. 긴 역사속에서 처음으로 이곳에 있게 되었으며,
그것이 다시 단일 개발자의 제어하에 있게 되지는 않을 것이다. 이곳에서 어떤 일이 일어날지 들여다보는 것은
흥미있는 것이 될 것이다. 만약 그 프로젝트가 강건한 커뮤니티 통제를 확립하고 공헌자에 대한 적대적 이미지를
없애는데 성공한다면, 개발 속도는 상당히 회복될 것이다. glibc가 그렇게 많은 시스템에서 점유했던 중요한 위치를
고려할 때, 이러한 변화는 거의 틀림없이 좋은 것이다.
이름아이콘 들풀
2012-04-06 07:11
안드로이드도 궁극적으로 glibc와 같은 오픈 커뮤니티에 의해 통제구조가 확립되길
기대해 봅니다.
   
이름아이콘 이광우
2012-04-06 18:08
사람들을 이끄는 힘은 공동체 구성원들이나 기여자들이 공유할 수 있는 철학이 아닐까 생각합니다. 그래서.. IT철학과목도 필요해요. ^^;
들풀 lwn.net의 글들을 요즘 열심히 읽어보고 있는데, 기술은 기술대로 어렵고,
오픈소스에 대한 가치는 가치대로 어렵다는 생각이 많이 들었습니다.~~
천천히 좀 더 많은 역사적인 사실에 대한 이해와 기술에 대한 깊이있는 탐구가
필요하다는 생각이 많이 들었습니다.~
4/6 18:20
   
이름아이콘 인베인
2012-04-11 11:01
LWN에 친숙해지는 자, 미래를 얻게 될겁니다.
그리고, LWN을 구독하는 (as a 후원자)자 더 많은 지식을 얻게 될 겁니다.
   
 
덧글 쓰기 0
3500
※ 회원등급 레벨 0 이상 읽기가 가능한 게시판입니다.