태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Welcome to youlsa's home!



HTML을 만지는 작업은 (특히 프로그래머에게는) 곤혹스러운 작업입니다. 하지만 요즘 추세에 피해갈 수는 없고요. HTML/CSS 작업을 정말 편리하게 할 수 있게 해주는 Zen-coding을 소개할까 합니다.

위의 화면은 emacs에서 Zen-coding mode를 써서 html 코딩을 하는 장면입니다. 맨 위와 같이 뎁쓰별로 명령어들을 써주면 아래와 같이 html 코드가 펼쳐지게 됩니다. html이나 sgml, xml 등을 좀 만져보신 분들을 이것만 봐도 대충 감이 오실 겁니다.

먼저 아래의 비디오를 보시면 좀 더 이해가 쉬울 것 같습니다.

Zen Coding v0.5 from Sergey Chikuyonok on Vimeo.

현재 Zen-coding이 구현된 에디터는 TextMate, Notepad++, Espresso, UltraEdit, BBEdit, Visual Studio등이고요, emacs에는 절반 정도 구현이 되어 있습니다.

하지만, emacs에는  YASnippet와 같은 코드 조각 생성툴들을 함께 써주면 오히려 더 유연하고 편리하게 사용할 수 있습니다.

Comment +1

PCWorld의 리눅스 관련 저술가인 Keir Thomas가 미래(2025년)의 컴퓨팅에 대해 쓴 글의 요약입니다. 재미있는 구석이 있습니다.
 
 

미래의 컴퓨팅 환경은 Good Enough...
 
 2009년의 상황
윈도우 XP에 이르러 유연하고 범용적으로 쓸만한 OS가 완성이 되었습니다.
불황의 여파로 PC 업체들은 그럭저럭 쓰기에 충분한(Good Enough) 저가형 하드웨어들 (넷북, 넷탑 등등)을 내놓아 호평을 받고 있습니다.
 
이미 하드웨어도 소프트웨어도 어느 정도 충분히 쓸만한 것들이 나왔다는 의미입니다.
  
2009년~2025년
사람들이 업그레이드를 안합니다. 하드웨어도 충분히 쓸만하고, 소프트웨어도 충분히 쓸만해서 그렇습니다. 경제 불황의 여파도 있고요..
 
마이크로소프트의 몰락을 재촉한건 결국 윈도우 XP였습니다.
물론 당대에는 베스트 셀러였지만 새 버전의 윈도우로 사람들이 업그레이드를 안합니다.
MS에서 XP에 대한 지원을 끊어버리고 최신 버전의 윈도우로의 업그레이드를 강요하자 사람들이 선택한건 돈이 안드는 우분투 리눅스, 오픈솔라리스, BSD등의 오픈소스 운영체제...
 
이게 가능하게된건 대부분의 컴퓨팅이 웹 브라우저를 통해서 진행되도록 바뀌어왔고, 오픈소스 운영체제들도 그런 용도에 충분할 정도로 발전을 했다는 점입니다.
 
MS는 다급한 마음에 운영체제에 오피스를 포함시켜 거의 무료로 뿌리기 시작했고, 결국 MS의 몰락을 가져오게 된다는...
 
곁다리로... 지능적인 스팸봇의 출현으로 거의 모든 검색 결과가 의미가 없어져 버려서 사실상 구글이 망했다는 슬픈 스토리도...


Thomson씨는 이런 현상을 "Good Enough Revolution"이라고 부르길 원하는 것 같은데요... 몽상이라고 보기에는 너무나 현재의 상황을 잘 보여주는 것 같아 무섭기도 합니다. 앞으로는 PC나 소프트웨어들도 자동차와 같이 한번 사면 업그레이드 없이 10년씩 쓰는 세상이 올지도 모르겠다는 생각이 듭니다.

Comment +2

  • 좀 극단적이기는 하지만 저도 XP를 4년째 사용하고 있으니 그럴듯한 가정이네요.
    위의 예상대로라면 하드웨어 업체도 타격이 있겠습니다.^^.
    좋은 글 잘 보고 갑니다.

  • MP 2009.11.22 20:40 신고

    재미있는 가정입니다.
    사실 XP처럼 잘 만든 OS도 흔치않죠.
    저도 XP지원중단하고 7으로 갈아타야 한다면 우분투에 안착하렵니다.
    오피스가 아쉽긴 하지만 일이야 직장에서 하는거고. 나머지야 뭐...
    그때되면 리눅스에서도 2% 아쉬운 부분들을 채운 소프트웨어들이 많이 있겠죠.

    지금의 우분투는 좀...
    다른건 몰라도, 절전모드만 제대로 동작하게 해줘요... >_<

    -----

    80~90년대에는 게임의 관심도가 높았죠. 새로운 기술과 하드웨어를 시험하는 무대였으니까요. 하지만 지금은 별로... 높아진 그래픽 사양 말고는 참신한 아이디어도 없고, 게임형식도 모조리 한가지로 통일되어가는 듯한 모습인듯 합니다.
    넷북정도의 사양이면 monte carlo 할 목적이 아닌 이상 일상용도로 충분하다고 봅니다. 넷북의 출현은 필요이상으로 높아진 하드웨어 스펙때문에 나온게 아닐까요. (넷북의 원조격이라 할 수 있는 후지쯔 P 시리즈의 가격을 생각해보면... 그당시 화폐가치까지 고려한다면 거의 1/10로떨어진 셈이지요)



위 만화는 http://emptydream.tistory.com/2768 에서 퍼왔습니다. 참 대단한 정부네요. 소프트웨어 개발자들의 경력을 신고받아 국가에서 관리를 하겠다는군요. 

정부 계약 등에서 인건비의 단가를 깎겠다는 이야기로 들리는데요, 사실 그리 놀랍지는 않습니다. 보수 정부의 특징이 원래 국민 전체에 대한 카탈로깅이랄지.. 인덱싱이랄지.. 그런게 기반으로 권력이 나온다고 생각하는 분들이니까요. 70~80년대에 신물나게 경험해온 줄 세우기, 등급 메기기 등을 이 21세기에... IT 기술이 그나마 첨단을 달린다고 하는 대한민국 땅에 다시 한다고 보면 되겠네요. 삼청교육대와 비슷한 느낌이죠. "얘는 A급, 얘는 B급"  

하지만, 시점이 묘한건, 이 대통령의 닌텐도 발언과 비슷한 시기에 이런 제도를 시행하겠다고 하는 점입니다. 물론 별 생각 없이 한 발언일수도 있겠지만 두 사건의 정나미 떨어뜨림 상호 시너지 효과가 참.. 대단한거 같네요. 아마 작년 집권 초에 이런 제도의 준비를 시작했을거 같은데요, IT는 일자리 창출이 안된다는 발언이 있었을 때쯤부터 준비를 하지 않았을까 싶네요. 

그냥 마음이 싸~합니다. 좀 더 지나면 본인의 보유 기술들을 등록하게 하고 그 외의 기술을 이용해서 수행한 프로젝트는 경력에서 제외한다거나 하는 그런 후진적인 모습이 보일까 두렵습니다. 말이 씨가 될까 두렵네요. 

각 분야별로 모두 등록을 받는 날이 올 것 같습니다. 연예인, 교사, 공무원, 미술가 등등등 사회 전 분야에 걸쳐 모두 등록을 하고 등급을 배정 받는 멋진 사회가 눈 앞에 펼쳐져 있습니다. 참 대단하십니다. 


Comment +4




요즘 유행한다는 저사양 고휴대성의 소형 넷북을 하나 장만하게 되었습니다. 그간 사용하던 도시바 다이나북 SS 모델이 요즘 좀 오락가락하고 해서 새 노트북이 필요해서 알아보던 중 다이나북 SS의 휴대성과 활용성(풀사이즈 키보드에 1cm대 두께, 1kg대의 무게, 그러나 800MHz CPU -_-)을 따라갈 만한 모델이 시중에 거의 없어서(또는 비싸서^^) 결국 사양은 떨어지지만 크기가 작은 넷북을 사게 되었습니다. 맨날 아날로그 기기들만 만지느라 디지탈 기기를 사본지가 오래되어서 어떤걸 사는게 좋을지 한참 고민하다가 MSI의 Wind U100을 사게 되었습니다. 이런 저사양의 기기에 윈도우를 설치해서 쓰면 아무래도 속도도 느리고 해서 처음 살때부터 아예 윈도우를 쓸 생각은 하지도 않았습니다. 그리고, 윈도우가 설치된 PC는 가는데마다 찾기가 어렵지 않으니 따로 들고 다닌다고 그리 메리트가 없다는 이유도 있습니다. (쇼핑을 위한 공인인증서만 따로 잘 가지고 다니면 됩니다 ^^)

비교적 고사양
리눅스가 잘 설치되는 넷북을 알아보니 MSI의 Wind와 Dell의 Inspiron Mini가 손에 꼽히는 것 같더군요. 해외에서는 리눅스가 설치된 상태로 판매도 하는 모양인데 우리나라에서는 이들 기기에 각각 윈도우 XP와 비스타 홈 에디션이 설치되어 판매가 되는 것 같습니다. 결국 MSI의 Wind를 선택하게 되었습니다. Wind의 키보드가 PageUp/PageDown이나 Home/End 키를 쓰려면 Fn키를 함께 눌러야 해서 좀 불편한데요, 리눅스에서는 이런 키들 거의 쓸 필요 없으니 전혀 불편함을 모르겠고, 무엇보다 50만원대의 싼 가격인데도 1.6GHz CPU, 2GB 램, 160GB의 예전 같으면 서버로 쓸 정도의 좋은 사양을 가지고 있다는 점이 좋았습니다.

우분투 리눅스
처음 노트북을 받자마자 윈도우 파티션을 밀어내고 우분투 리눅스 8.10(interpid)를 설치했습니다. 설치는 거의 막힘 없이 손쉽게 설치가 되었습니다. 예전에는 X 설정하는 것 부터 터미널 폰트, 각종 드라이버들 설치하는게 참 큰 일이었는데 리눅스가 언제 이렇게 쉬워졌나 싶습니다. 노트북에서 가장 중요하다고 생각하는 하이버네이션도 별다른 설정 없이 잘 동작하네요. 그래서 언제나 그렇듯이 노트북 뚜껑을 덮으면 자동으로 하이버네이션이 동작하도록 설정하였습니다. 예전에는 /etc/acpi 내의 스크립트들을 설정해줬던것 같은데 시절이 변했는지 시스템 메뉴에서 간단하게 설정이 가능하네요.

한가지 문제는 무선랜이 잘 동작을 안했었는데요, 자료들을 찾아보니 U100에는 기기별로 여러가지 종류의 랜카드가 탑재되는 것 같습니다. 그래서 찾아보니(lspci) 제 기기에는 Ralink사 칩셋 기반의 무선랜 카드가 들어있는거 같아서 ralink사의 홈페이지에 올라온 드라이버를 가져다가 빌드해서 올리니 큰 문제 없이 동작을 합니다. 다음의 링크에서 받으면 됩니다. 

그 외에도 msiwind.net에 올라온 내용들을 참고하면 편합니다.요. http://wiki.msiwind.net/index.php/Ubuntu_8.04_Hardy_Heron


풍족한 오프라인 환경
보통 넷북은 간단한 웹 브라우징이나 동영상 감상용으로 쓰는데요, 제 경우에도 비슷하긴 하지만 주된 용도는 프로그래밍입니다. 스타벅스나 전망 좋은 곳에서 프로그래밍 하고 문서 읽는걸 좋아해서 리눅스 탑재 넷북이 제 용도에 딱 맞는 것 같습니다.  

리눅스를 탑재한 넷북이 좋은 이유는 풍족한 오프라인 환경을 꾸미기가 매우 편리하다는 점입니다. 물론 윈도우에서도 가능은 합니다만... 과격 리눅스 근본주의자(?)의 입장에서 봤을 때 뭔가 옳지 않습니다. ^^ 사실 인터넷이 연결된 데스크탑 PC에서 일을 방해하는 요소중 하나가 제게는 인터넷입니다. 코딩을 하다 말고 쇼핑을 하고 있는 자신을 발견할 때 좌절합니다. 여담이지만, 데스크탑에서 레코딩용으로 잘 이용하던 POD XT를 팔아버린 이유도 비슷한데요, 도대체 데스크탑에서는 제대로된 레코딩에 집중을 하기가 어렵습니다. 뭔가 찾아본다는 핑계로 웹 브라우저만 열면 삼천포입니다. ^^ 기능은 딸려도 웹 브라우저가 없는 Boss Micro BR같은 녹음 전용기기가 레코딩 작업 효율은 더 좋은 것 같습니다. 제 주위가 산만해서 그렇기는 하겠습니다만... 이 Wind는 충분한 성능으로 풍요로운 오프라인 환경을 구성해서 하려고 하는 일에 집중할 수 있게 해주는 것 같습니다. 특별히 자세히 보고 싶은 사이트나 웹 문서들이 있으면 wget --mirror로 로컬로 미러링을 해놓고 오프라인 때 자세히 살펴보면 됩니다.

로컬에 아파치 서버도 있고, 각종 python 라이브러리들과 gcc등 온갖 프로그래밍 도구들을 함께 가지고 다니니 뭔가 생각 났을때 즉시 구현해보거나 할 때에도 좋습니다. 무엇보다 emacs가 있으니.. ^^ Wind의 화면이 나름 와이드라서 위의 사진과 같이 emacs의 화면을 양쪽으로 나누어도 꽤 쓸만한 해상도가 나와서 소스를 보는데 별 어려움이 없습니다. 폰트를 약간 줄이니 가로 250글자 정도에 40라인 가까이 표시가 됩니다. 가로로 3등분을 잘라도 80컬럼씩 볼 수 있으니 마치 작은 듀얼 모니터를 쓰는 기분도 납니다. ^^

그리고, 무엇보다 버전관리 시스템들이 요즘에는 분산환경을 너무 잘 지원해줘서 오프라인 상태에서도 버전의 히스토리를 본다거나 commit, update, branch등의 작업이 자유로와서 더욱 좋습니다. wind + emacs + svk 면 거의 24시간 아무데서나 시간 나는대로 프로그래밍에 몰두할 수 있는겁니다.


MSI의 뜻하지 않은 선물
Wind를 구입하고 나서 한가지 생각도 못한 즐거웠던 점이 있었습니다. 구입한 후 MSI 사이트에 들어가보니 BIOS가 업그레이드가 되었는데 BIOS에 오버클럭킹 기능이 추가되었다는 겁니다. 그래서 업그레이드를 해보니 BIOS 메뉴에 24%까지 오버클러킹을 할 수 있는 메뉴가 추가되었습니다. 이걸 설정을 해두고 Ctrl-F10을 누르면 원래 파란색이었던 전원등이 아래와 같이 오렌지색으로 변하면서 속도가 빨라집니다. 사실 하드웨어의 안정성을 최우선으로 해야하는 노트북 제조 회사가 이렇게 오버클럭킹을 공식적으로 지원하기가 쉽지 않을거 같은데요, 기기 가격이 저렴해서 그런지 과감하게 이런 기능을 넣어서 사용자들을 즐겁게 해주네요. 어쨌든 예전에 코원 D2의 대박 펌업들 이후 간만에 기분 좋은 업그레이드였습니다.



당분간은 넷북 덕분에 또다른 지름신이 올 것 같지는 않습니다.

Comment +5

  • 서정호 2009.01.16 10:42 신고

    흐..저도 이거 구입해서 잘 사용중입니다. 전 OSX설치해서 사용중인데 뭐 그럭저럭 잘 돌아가요. 잘 지내시죠?

    • 게을러서 OS/X 안깔았는데, 주변에 보니 우분투 보다 더 쉽게 깔리는거 같아서 놀랍던데... 잘 지내고? ^^

  • 엇 저도 노트북에 우분투 리눅스를 깔아서 사용합니다만..티스토리 스킨도 그렇고 기타도 그렇고 저와 비슷한 점이 많으시네요.^^

  • 작은 화면과 저사양으로 인한 멀티태스킹의 제한도 특정 작업에 몰두하는데 도움이 되는 것 같습니다. 잘 보고 갑니다.^^.

사용자 삽입 이미지

지금까지 Java에 대한 매우 좋지 않은 인식 덕분에 Java에 거의 손을 대지 않았었습니다. FOSS(Free/Open Source Software,자유/오픈소스 소프트웨어)가 아닌 도구를 사용하지 않게 된지 거의 5-6년 정도 된 것 같습니다. 저의 주된 프로그래밍 도구들은 Emacs, C/C++ (GCC), GDB, Python, PHP, BASH 등의 것들입니다. 프로그래머 생활을 처음 시작할 때에는 Visual C++로 대표되는 마이크로소프트의 개발도구들도 사용했었지만 언젠가부터 전혀 사용하지 않게 되었습니다.

SUN에서 드디어 자바를 GPL로 풀기로 결정했다고 합니다. Free Java가 탄생하는 겁니다. 적당한 타이밍에서 10년 정도 뒤쳐진게 아닌가 싶은 생각이 들기는 하지만 지금이라도 Java가 자유롭게 되었으니 다행이라고 생각합니다. 이제야 저도 자바로 뭔가 장난을 쳐보고 싶은 생각이 듭니다. ^_^

자바에 대해 좋지 않은 저의 인식은 주로 몇가지 말초적이고도 이데올로기적인 이유였습니다. 이유들을 간략하게 생각해 봤습니다.

1. “느려~”
이건 첫 인상에 대한 것일수도 있지만 제게는 자바가 너무 느립니다. 특히나 느려터진 브라우저에서 초기화 하는데 하루 종일 걸리는 애플릿들은 정말 충분히 안좋습니다. 열혈 자바 프로그래머들은 자바가 느리다고 하면 절대 그렇지 않다고 일장 연설을 해댑니다만, 자바 느립니다. 몇몇 사용 분야에서 자바가 어느 정도 괜찮은 퍼포먼스를 낸다는 사실은 인정하지만 그래도 자바는 느립니다. 특히나 사용자의 눈과 손가락과 직접 만나는 부분들을 자바로 만들어 놓으면 도대체 이게 뭐 하자는 프로그램인지 모를 지경이 되는 경우가 많습니다. 물론 개념 없이 만들어진 C++ 프로그램보다 개념을 가지고 만든 Java 프로그램이 더 퍼포먼스가 좋기는 합니다.

2. “이거 어린이용 C++인가?”
C++과 거의 비슷하지만 약간씩 다른 문법이 마음에 안듭니다. 어차피 포인터 같은 부분 사용자들이 못쓰게 할 계획이었고 축소 스펙의 언어를 만들려고 마음을 먹었다면 Perl이나 Python 처럼 화끈하게 간단하게 만들던가, 아니면 Basic 같은 쉬운 초보자 대상의 언어의 문법을 가져다 만들었다면 Java를 조금 더 좋아하게 되었을지도 모르겠습니다. 특히 안좋은 점이라고 생각하는 점은 {} 괄호(curly brace)를 그대로 사용하게된 겁니다. {} 괄호들은 베테랑 C/C++ 프로그래머들도 타이핑 하기에 손가락이 힘든 글자들이라는걸 누구나 인정하는데 이걸 그대로 따라한건 21세기 지향 언어로서 참 못할 짓을 한거 같습니다.

3. SUN Microsystems의 삽질.
삽질도 이런 삽질이 없습니다. MS가 자바를 망가뜨리니 MS가 자바에 손대지 못하게 해달라고 소송을 하다니요. 덕분에 MS가 만든 (당시로서는)고성능의 JVM이 윈도우에서 빠져버리게 되었고, 결과적으로 윈도우에서 자바를 사용하기가 한층 더 어려워 졌습니다. 쓰더라도 SUN에서 만든 한글도 잘 안나오고 걸핏하면 죽어버리는 JVM을 설치해야만 했습니다. 지금은 어떤지 잘 모르겠습니다만… 정확한 통계 같은건 없겠지만 이 바보같은 사건으로 잠재적인 자바 프로그래머가 상당수 떨어져 나갔을 겁니다. 웹상에서 이제는 플래쉬에게 추월을 당하는 신세가 됐습니다. 예전같았으면 자바로 작성했을만한 것들이 플래쉬로 만들어져 나옵니다. 윈도우에서도 Java 쓰기가 어렵고 리눅스에서도 apt-get install sun-java 하면 설치가 되었으면 좋겠는데 라이센스 문제로 이것도 안됩니다. 도대체 왜 이런 삽질을 하는지 모르겠습니다.

4. Java 프로그래머들…
Java 개발자들은 보통 두가지 부류로 나뉩니다. C/C++을 사용하던 와중에 좀 더 나은 툴을 찾는 와중에 자바를 발견해서 사용하는 프로그래머와 처음부터 자바만 배운 프로그래머. 한때 웹 열풍을 타고 대량으로 쏟아져 나온 Java 개발자들은 프로그래머에 대한 매우 좋지 않은 이미지들을 심어주기에 충분했다고 봅니다. UNIX 프로그래머들의 기본적인 문제 해결 방식이 K.I.S.S.(Keep It Simple Stupid)인데요, 가능한한 문제를 잘게 쪼개어 최대한 심플하고 직설적인 방법으로 문제를 해결한다는 사고 방식입니다. 어떤 Java 프로그래머들은 문제를 가능한한 복잡해 보이고 뭔가 있어보이는 방식으로 해결하려고 하는걸 볼 수 있습니다. 적당한 비유가 될런지 모르겠지만, 프로그래밍 언어와 그 주변의 라이브러리들은 문제를 해결하기 위한 도구에 불과합니다. 뭔가 일을 할 때, 도구들은 땅바닥에 수평적으로 대충 늘어놓고 적당한 도구들을 줏어서 쓰는 것이 편리하지 수평/수직/트리구조의 깔끔하게 짜여진 진열장에 빼곡히 예쁘게 정리해놓고 나서 상하좌우 관계를 따져 꺼내 쓴다는건 너무 불편한 일 아닌가요? 객체지향의 완결성보다 문제의 해결이 더 중요한 경우도 있다는 점을 알아주면 얼마나 좋을지 모르겠습니다.

5. 고슬링 재수 없다.
이건 근원을 따지자면 우울했던 80년대에 Richard Stallman이 만들어낸 Emacs의 코드를 Gosling이 가져다가 상용으로 팔아먹었던 것으로부터 시작될겁니다. (물론 그 코드 그대로는 아닙니다) 암튼, 그 이후의 고슬링, 참… 재수 없습니다… 특히나 SUN의 CTO로 떵떵거리던 시절 몇몇 인터뷰에서 오픈소스/자유 소프트웨어 진영을 깎아 내리던 그의 발언들은 많은 순수한 마음을 가진 프로그래머들의 가슴에 상처를 주기에 충분했습니다.

6. 진한 커피향?
Java라는 이름도 참… Java의 처음 프로젝트 이름은 오크(Oak)? 뭐 그런 비슷한 이름이었는데요, 갑자기 뜬금 없이 자바라는 이름을 가지게 되다니… 착취당하는 경제식민지의 전형적인 예 중 하나가 커피 산업이라고 하는데, 일단 그게 연상되어 마음이 언짢습니다. 저임금에 커피 수확하는 불쌍한 인도네시아 노동자 몇을 깔고 앉아 한가롭게 커피 향기 맡아가며 프로그래밍 하고 있는거 같은 이미지가 자꾸만 떠오릅니다. -_-; Java가 커피의 향이니 뭐니 하는 이야기를 들으면 엔지니어로써 “그럼 C는 납땜 인두의 향인가?”하는 생각에 “불끈~!”하게 됩니다.

그럼에도 불구하고 Java는 SUN의 강력한 마케팅과 시대적 필요성에 의해 탄생하고 성장해서 소프트웨어 역사에 한 획을 그었습니다. 수많은 소프트웨어들이 자바를 이용하여 만들어지고 있고요. 날이 갈수록 그 사용 범위는 넓어져 갈겁니다. 게다가, SUN의 자바 오픈 발표로 인해 다음 발전 단계로 나아가게 되었습니다. SUN이 마음대로 콘트롤하던 답답한 자바에서 시원시원한 자바로 변모해갈 것입니다.

자유/오픈소스 소프트웨어 프로그래머들의 품에 안기게 된 자바를 진심으로 환영합니다.


Comment +2

사용자 삽입 이미지

Quick-Kill Project Management

출처 : http://www.ddj.com/dept/architect/189401902

실현 불가능한 스케쥴 하에서 소프트웨어 개발 프로젝트를 제대로 진행하기 위한….

Andrew Stellman and Jennifer Greene, Dr. Dobb’s Journal
6/30/2006

이글의 저자인 Andrew와 Jennifer는 O’Reilly 출판사에서 발간된 Applied Software Project Management의 저자이며 공식 홈페이지는 www.stellman-greene.com 이다.

—-

당신이 다섯명으로 구성된 프로젝트 팀을 이끄는 프로젝트 리드 개발자라고 해보자. 당신의 팀은 몇주간 프로젝트를 진행해 왔고 팀의 분위기는 다소 싸늘하게 맛이 가는 상황이다. 팀의 구성원들은 화려한 경력의 아키텍트로부터 갓 대학을 졸업한 초보 개발자까지 다양한 인원으로 구성되어 있다. 당신의 상사가 프로젝트 리드인 당신을 불러놓고 경영진으로부터 압박이 너무 강해 못살겠다고 죽는 소리를 해댄다. 프로젝트가 어제까지 끝이 났어야 했다는 것이다. 실상 이 프로젝트는 어제 끝내기로 아주 오래전에 약속이 된 상태였고 고객이 이 소프트웨어를 제때 사용하지 못하면 어마어마한 손실이 발생하기 때문에 이 프로젝트가 실패하면 아마도 당신과 당신의 상사는 새 직장을 알아봐야 할지도 모르는 상황이 될 것 같다.

이런 고도의 스트레스가 가해지는 프로젝트를 수행하는 팀에게는 프로젝트가 악몽 그 자체이다. 제대로 방향을 잡지 못한 팀원들은 이래저래 잘못된 판단을 하여 일을 망치기 마련이고 책임감 넘치는 프로젝트 리드인 당신은 심각한 디자인 상의 오류를 수정하기 위해 주말동안 40시간을 일해야 했을 것이다. 싸늘한 표정의 경영진과의 미팅이 계속 되게 마련이고 절대 사라지지 않는 버그들이 여기저기 산재해 있으며 너무 많은 밤을 커피/피자와 보내게 되었을 것이다. 더우기 그런 고생 끝에 결국 뭔가 완성해서 납품을 하면 이번에는 고객이 그 소프트웨어를 싫어한다. 버튼을 누를 때마다 새로운 버그들이 나타나기 때문에 고객들은 자신들이 원했던 기능들이 결국에는 거의 구현되지 않았다고 느끼게 될 것이다.

Quick Kill 프로젝트 관리법

많은 팀들이 자신들이 위와 같은 상황에 처해있음을 깨닫게 되고 리드 개발자는 많은 심각한 문제들에 직면하게 될 것이다. 물론 리드 개발자는 직접 팀을 관리할 책임은 없지만 결국 그는 소프트웨어가 완성되도록 할 책임이 있다. 보통 팀 구성원들은 그를 존중하며 그가 결정을 내리면 모두 잘 따를 것이다. 하지만 리드 개발자의 임무는 팀 관리가 아니라 개발이다. 그의 대부분의 시간은 문제의 해결 방법을 찾아내고, 소프트웨어를 설계하고, 코드를 빌딩하는 곳에 써야만 마땅하다.

이상적인 상황이라면 프로젝트의 관리를 위해서 별도의 프로젝트 매니저가 존재하던가 아니면 프로젝트 리드에게 많은 시간이 주어져야 한다. 하지만 대부분의 경우 그러하듯 충분한 시간이나 예산이 주어지지 않았다면? 대부분의 사람들에게 이런 경우에 도대체 무엇부터 시작해야 할지 난감하기는 마찬가지일 것이다. 이 글의 주된 아이디어는 바로 이런 경우를 해쳐나가기 위한 방법에 집중한다. “Quick Kill 프로젝트 관리법”이라고 부르자. 프로젝트의 가장 중요한 문제점들만 집어내어 순식간에 죽여(kill)버리자는 컨셉이다. 다시 말하면 프로젝트 리드가 가장 적은 노력을 기울여 가장 많은 이득을 얻을 수 있는 trade-off 지점을 찾도록 해주자는 것이다.

Quick-kill 프로젝트 관리법에는 프로젝트 리드가 상사와 고객이 원하는 것을 만들어 낼 수 있는 아래와 같은 테크닉으로 이루어진다:

  • 목표(vision)/범위(scope) 정의 문서
  • 작업 분할(Work breakdown structure)
  • 코드 리뷰(Code review)

각각의 테크닉들을 실제 수행하는데에는 많은 시간이 소요되지 않는다. 그러면서도 프로젝트 진행에서 빠지기 쉬운 함정들을 손쉽게 피할 수 있도록 해준다. 이 방법들을 사용하면 프로젝트 리드들은 그럭저럭 괜찮은 결과를 낼 수 있게 된다.

목표/범위 정의 문서(Vision and Scope Document) : 6시간 이내

만약 소프트웨어 팀이 자신들이 작업중인 소프트웨어가 어느 맥락에서 만들어지고 있는지 잘 모르는 경우에는 프로젝트 진행 과정 중에 매우 안좋은 결정을 내리게 되는 경우가 많다. 이런 잘못된 결정은 나중에 바로 잡는데 귀중한 시간들을 소모하게 되고, 바로 잡지 않는다면 고객들의 요구사항을 무시한 것이 될수도 있어 상당한 신뢰를 잃게 되기도 한다. 프로젝트의 범위를 이해하지 않은채 프로젝트에 투입되면 긴급상황이 거듭되는 동안 목표를 잊어버리고 더 안좋은 길로 들어서게 되는 첩경이다. 프로그래머들이 자기 눈 앞에 놓인 문제들은 잘 볼지 몰라도 프로젝트 전체의 맥락은 놓쳐버리게 되는 것이다. 이것은 프로젝트 지연과 프로젝트 실패의 가장 큰 원인이다.

운좋게도 이 문제는 아주 손쉬운 방법으로 해결될 수 있다. 프로젝트의 목표(vision)와 범위(scope)를 문서에 적는 일은 채 하루도 걸리지 않지만 위의 문제들로 인한 프로젝트의 지체 시간을 엄청나게 절약해준다.

이 목표/범위 문서를 작성하는 가장 첫번째 단계는 프로젝트의 직접적인 이해 당사자(stakeholder)들을 만나 이야기를 하는 것이다. 보통 직접적인 이해 당사자가 누구인지 분명하지 않은 경우가 많다. 프로젝트 리드는 먼저 프로젝트에 의해 가장 큰 영향을 받는 사람을 찾아야 한다. 프로젝트를 입안했거나 그 개발 경과에 영향이 있는 사람들을 찾아야 한다. 아니면 가장 쉬운 방법으로 프로젝트가 엉망이 되어 버렸을 때 치명타를 입는 사람들을 찾으면 손쉽다. 대부분의 이해당사자들은 그들이 원하는 요구사항이나 프로젝트의 목표에 대해 프로젝트 리드와 기꺼이 이야기를 나눌 것이다. 그리고, 그것이 당연히 리드 개발자와 그 개발팀이 해야할 일이기도 하다. 보통의 경우 각 이해당사자들이 원하는 요구사항을 취합하는데 한사람당 한시간도 걸리지 않을 것이다.

목표/범위 정의 문서는 간단해야 한다. 한두 페이지를 넘어가서는 안된다. (테이블 1 참조) 프로젝트 이해 당사자들과의 면담을 거쳐 얻어진 요구사항들은 이 문서의 “문제점들” 섹션에 추가한다.

  1. 요구사항들 (Problem Statement)
    1. 프로젝트의 배경(Project Background)
    2. 이해 당사자들(Stakeholders)
    3. 고객들(Users)
  2. 목표(Vision of the Solution)
    1. 목표 명세(Vision Statement)
    2. 기능 명세(List of Features)
    3. 개발하지 않을 기능들(Features That Will Not Be Developed)

테이블 1: 목표/범위 정의 문서 개요.

“프로젝트의 배경” 섹션에는 프로젝트가 해결해야 하는 문제점(problem)의 요약이 들어간다. 그 문제의 간단한 배경 역사에 대한 설명이 있어야 하고 회사가 그 문제점을 해결하기 위한 소프트웨어를 만들게된 이유에 대해 간략히 쓰도록 한다. 이 섹션은 문제점이 왜 존재해왔고 회사에서의 그 문제점의 위상, 이전에 이 문제를 해결하기 위해 있어왔던 프로젝트들과 어느 정도 해결했는지 여부 등을 알 수 있어야 한다.

“이해 당사자들” 섹션은 이해 당사자들을 나열해서 목록을 작성하도록 한다. 이름을 쓸 수도 있고 직책이나 역할을 써도 된다. (”기획팀장”, “대표이사”, “홍길동” 등) 각 이해 당사자에 대해 몇줄 이내로 그들의 요구사항을 적어 두도록 하자. “고객들” 섹션에 대해서도 마찬가지로 작성을 하도록 한다. 고객들도 역시 이름이나 직책 또는 역할로 대신 써도 된다. (”지원팀”, “일반 가정 사용자”, “금성전자” 등등) 고객이 너무 많다면 일일히 모두 적는 것이 비효율적일 수도 있다.

이 문서의 가장 중요한 부분은 고객들과 이해 당사자들의 요구사항 부분이다. 프로젝트의 구성원들이 그 프로젝트를 이끄는 원동력이 무엇인지 이해하지 못한다면 매우 편협한 시각만들 가지고 고객이나 이해당사자들은 별로 중요하지 않게 여기는 일들에 지나치게 많은 시간을 투자하거나 할 가능성이 높다. 좋은 소프트웨어를 만드는 것은 오히려 쉽다. 하지만 “알맞는” 소프트웨어를 만들기 위한 방법은 프로젝트 팀의 모든 구성원들이 자신이 만들어야 하는 소프트웨어를 만드는 이유와 방법을 사전에 이해해야만 하기 때문에 어려운 것이다. 물론 그것이 바로 프로젝트 기회의 목적이기도 하다.

문서의 “목표” 부분은 소프트웨어의 목표를 적는 곳이다. 모든 소프트웨어는 고객이나 프로젝트 이해 당사자의 문제를 해결하기 위해 작성된다. 프로젝트 팀은 이 점을 염두에 두고 목표 명세를 적어 나간다. (요구사항들을 어떻게 해결해줄건지를 적으면 된다) 목표 명세 부분은 프로젝트를 어떻게 완수하는지를 적는 것이 목표다. 프로젝트의 목적에 대해서도 설명이 있어야 한다. 프로젝트에 투여되는 시간과 돈, 리소스에 대한 엄격한 이유가 있어야만 한다.

“기능 명세”와 “프로젝트에서 개발하지 않을 기능들” 섹션은 프로젝트 팀이 무엇을 만들고 무엇을 만들지 않을 것인가에 대한 명세이다. 이 섹션을 쓰기 전에 문서를 모두 작성해 놓고 이 부분에 대하여 허심탄회한 논의를 해야만 한다. 각각의 기능들은 “문제점들” 섹션의 문제점들을 해결하기 위한 것이어야만 한다. 프로젝트 팀들은 종종 ‘당연히 있어야 할 것 같은 기능’이지만 정작 문제의 해결에는 별 도움이 되지 않는 기능들을 추가하는 실수를 범한다. 이런 기능들은 “프로젝트에서 개발하지 않을 기능들” 섹션으로 과감하게 옮겨야 한다.

업무 분할: 2시간

기능 구현을 시작하기 전에 프로젝트 리드는 팀의 구성원들과 함께 각각의 기능에 대한 소요 시간을 추산해야 한다. 많은 개발자들은 일정 추산을 어려워한다. 하지만, 몇가지 방법만 따르면 일정 추산이 상당히 손쉽고 믿을만하게 된다.

일정 추산은 각 프로젝트 구성원들은 프로젝트의 여러가지 측면을 고려해볼수 있는 기회가 되기 때문에 매우 중요하다. 대부분의 프로그래머들은 간단한 작업으로 예상하고 일정을 추산했던 작업이 실은 매우 복잡한 것으로 밝혀져 엄청나게 많은 추가 시간이 소요될 것이란걸 깨닫고 절망했던 기억이 있을 것이다. 게다가 팀 구성원 중 다른 사람이 그 작업이 완료된 후 어떤 작업을 해야 하는 상황이라면 자칫 프로젝트 전체가 혼란에 빠지게 될수도 있다. 일정 추산의 요령은 이런 일반적인 프로젝트 진행상의 재해상황을 피할 수 있게 해준다. 프로젝트의 일정을 추산하기 위해서는 팀이 프로젝트를 완수하기 위한 단계를 미리 파악해놓고 각각의 단계들을 완수하는데 몇일 정도가 소요되는지 추산해야 한다. 정확한 일정을 파악하기 위한 유일한 방법은 팀 구성원 모두가 둘러 앉아 프로젝트의 모든 요소들(특히나 빼먹고 나중에 당황할만한 요소들)을 겁듭 함께 생각해 보는 것이다.

일정 추산을 위한 첫번째 단계는 프로젝트를 여러개의 작업들로 분산하는 것이다. 이것을 업무 분할(work breakdown structure, WBS)라고 부른다. 프로젝트를 작업들로 분산하는데에는 아주 많은 방법들이 있다. 리드 개발자는 팀 구성원들을 모아 적당한 수의 작업들로 프로젝트를 분할해야 한다.

경험적으로 가장 좋은 작업의 수는 프로젝트 당 대략 10-20개 정도의 작업으로 분할하는 것이다. 큰 규모의 프로젝트들(스페이스 셔틀 등)에서는 이 각각의 작업들이 엄청나게 큰 일(유도시스템 테스트 처럼)이 되겠지만 일반적인 소프트웨어 프로젝트에서는 비교적 작은 단위로 떨어지기 마련이다. 이 작업 분할은 보통 한시간 내에 완료할 수 있을 것이다.

팀 멤버들이 이 WBS에 동의했다면 이제 각각의 작업에 대해 일정 추산이 가능해진다. 물론 팀 구성원들이 모두 일정 추산에 필요한 모든 필요한 정보들을 가지고 있는 것은 아닐 것이지만 어쨌든 모두들 구체적인 수치로 일정 추산을 해야만 한다. 일정 추산에 필요하지만 누락된 정보들이 있다면 어느 정도 추정을 해야만 한다. 이렇게 추정에 의한 부분들에는 옆에 빈칸을 함께 남겨두고 나중에 정보들이 보강되면 이 빈칸들이 채워주게 되면 프로젝트의 진행에 따라 일정 추산이 갈수록 더 정확하게 변해갈 것이다.

일정 추산에 있어 추정은 매우 중요한 역할을 한다. 두명의 구성원이 어떤 작업의 소요 시간에 대해 의견을 달리 할 때를 보면 이 두명의 일정 추산이 다른 이유 중 가장 큰 부분이추정의 정도가 다르기 때문인 경우가 대부분이다. 예를 들어, 동일한 목표/범위 정의 문서를 기반으로 작업하고 있는 두 개발자에게 컴퓨터의 시계를 맞추는 모듈의 작성에 있어 일정 추산이 완전히 다르다고 한다면 그 이유는 보통 두 사람의 “추정” 부분이 완전히 다를 수 있다는 것이다. 한 사람은 키보드 커맨드로 시간을 맞추는 커맨드라인 버전의 모듈을 생각했고, 다른 한 사람은 윈도우 제어판에 플러그인 되는 GUI 프로그램 모듈로 추정하고 있었다든지 하는 경우가 될 수 있겠다.

프로젝트 리드는 팀 구성원들 간의 이런 “추정” 부분의 차이를 해소하도록 도우면서 각각의 작업들의 추정시간을 픽스해 나갈수 있을 것이다. 리드는 각각의 작업들을 하나씩 내놓아 팀원들이 각각의 작업들에 대해 추산을 하도록 하자. 이견이 있는 경우는 팀원들의 “추정”이 일치하지 않는 것이므로 프로젝트 리드가 이들을 일치하도록 조정하여 해당 작업의 아래에 “추정”을 적어두도록 한다. 더 많은 “추정”들이 쓰여질수록 팀 구성원들이 프로젝트에 대해 많은 것을 알게 되는 것이다. 이것이 거듭될수록 팀 구성원들의 일정 추산은 갈수록 정확해지게 된다.

결국 최종적으로 WBS는 작업 목록과 각각의 작업의 일정 추산, 작업별 “추정”들로 이루어지게 된다. 10-20개의 작업들에 대해 이런 일정 추산과 “추정”을 집계하는 데에는 대략 1시간 정도가 소요될 것이다. WBS를 작성하고 추정을 하는데 2시간 정도 소요된다. 대부분의 다섯명짜리 프로젝트에서는 이 정도면 충분할 것이다. 프로젝트의 규모가 이보다 훨씬 크다면 프로젝트를 각각 두시간 분량으로 쪼개어 한 조각에 두시간씩 추정을 해나가면 된다.

코드 리뷰: 리뷰당 2.5시간

팀 구성원들은 코드의 샘플을 리뷰하며 결점들을 고쳐 나가게 된다. “결점”이란 프로그래머가 의도한대로 동작하지 않거나 동작하지만 개선되어야만 하는 프로그램의 블럭을 말한다. (예를 들자면 좀 더 보기 좋게 수정되어야 하는 부분이나 좀 더 빠르게 동작해야 하는 부분등)

코드 리뷰를 시행하는 것은 팀이 더 좋은 소프트웨어를 만들도록 하는 효과적인 방법이다. 팀이 버그를 찾아서 수정하도록 하기도 하지만 그보다 초급 프로그래머들이 더 좋은 기술을 연마하도록 하는 기회가 된다. 대부분 프로그래머들은 다른 사람들이 나중에 자신의 코드를 읽을 것이라는 것을 알고 있으면 좀 더 나은 코드를 작성하게 되는 경향이 있다.

코드 리뷰를 하기 위한 첫번째 단계는 리뷰할 코드의 샘플을 선택하는 것이다. 전체 코드를 모두 리뷰하는 것은 불가능하기 때문에 어느 부분을 리뷰할 것인지 골라야만 한다. 리뷰할 코드를 잘 선택해야 코드 리뷰가 효율적이 된다. 상당수의 프로젝트들에 있어 많은 수의 결점들이 특정 핵심 부분에 몰려있는 경우가 대부분이다. 그렇기 때문에 리뷰할 코드를 잘 선택하면 팀 전체의 많은 시간을 절약하게 된다.

보통 프로젝트 리드가 리뷰에 사용할 알맞은 코드를 선택하는 일은 그리 어렵지 않다. 보통 트리키한 알고리즘을 구현한 부분이라던가 복잡한 API나 오브젝트 인터페이스를 사용한 부분, 새로운 기술을 응용한 부분등이 대상이 되는 경우가 많을 것이다. 이런 핵심적인 부분을 리뷰하는 것은 소프트웨어의 동작에 안정성을 위협하는 결점들을 제거할 수 일기 때문에 유용하기도 하지만 결국 그 부분을 유지/보수할 수 있는 인력을 늘린다는 측면에서도 바람직하다.

리뷰를 준비하기 위해서 프로젝트 리뷰는 선택된 코드 블럭을 라인 넘버와 함께 프린트하여 각 프로젝트 구성원들에게 배포한다. 각 구성원들은 각자 30분 정도의 시간을 투자해서 이를 읽어보고 (실행해보면 더 좋고) 검토해보는 시간을 갖도록 하자. 각자 이 코드가 작성자의 의도대로 동작할지에 대한 고찰을 하도록 하자. 코드 동작의 정확성/유지보수성/신뢰성/보안/확장성/재활용성/효율성에 문제가 없는지 염두에 두고 살펴보도록 한다. 이런 각각의 문제점들은 “결점”으로 간주하도록 한다. 모든 팀 구성원들은 가능한 많은 “결점”들을 찾아내어 프린트된 소스에 표시를 하도록 한다.

각자 준비가 끝나면 코드 리뷰 미팅을 개최한다. 코드 리뷰의 시작은 프로젝트 리드가 코드 샘플의 첫번째 블럭을 읽는 것으로 시작한다. 물론 소스를 다 읽는다기 보다는 개략적인 설명과 코드의 작성 목적 등을 설명하는 것이다. 이 설명에 동의하지 않는 구성원이 있다면 코드의 원 작성자가 코드의 작성 목적 등을 자세히 설명하는 시간을 갖도록 하자. 어떤 때에는 다른 구성원이 더 좋은 방법을 내놓을 수도 있다. 작성 목적의 설명을 듣는 것만으로도 많은 문제의 해결책들이 쏟아져 나올 수 있다.

팀 구성원들은 코드 블럭에서 발견한 “결점”에 대해 논의하도록 한다. 이때 프로젝트 리드는 미팅의 중재자 역할을 해야 한다. 누군가 “결점”을 발견하면 리드는 그 것을 즉시 고칠 수 있는지 없는지를 판단한다. 고칠 수 있으면 그 자리에서 고치면 된다. 즉시 고칠 수 없다면 이슈로 열어놓고 나중에 수정하도록 할수도 있다. 각각의 경우에 있어 리드는 스프레드쉬트에 한줄씩 추가하여 리뷰 로그를 작성하도록 한다. 각각의 “결점”에 대해 한줄을 추가하는 것이다. 라인 넘버, 발견자, 해결 방법, 해결 여부 등을 적어 넣으면 된다. 로그의 상단에는 리뷰 미팅이 언제 어떤 코드 블럭을 가지고 행해졌는지 적어 넣도록 하자.

코드 리뷰 미팅은 2시간 이상 소요되어서는 안된다. 만약 그 이상이 소요되었다면 다음번에는 좀 더 짧은 소스를 선택하도록 하자. 코드 리뷰 미팅이 끝나고 나면 프로젝트 리드는 리뷰 로그를 모두에게 보내고 그 수정 작업을 필요한 사람에게 할당하도록 한다. 수정 작업이 끝나고 나면 수정 사항이 제대로 코드에 반영되었는지 리드가 확인하도록 하자.


Comment +0

사용자 삽입 이미지
재미있는 글을 발견해서 옮겨봅니다. 프로그래밍을 하다 보면 우리가 무엇을 위해 이 일을 하고 있는지 망각할 때가 많습니다. 재미가 없다면 도대체 그 일은 해서 무엇하겠습니까? 여기에 Geoff Broadwell이 이야기하는 “재미”를 위해 옵티마이징 하는 몇가지 요령들이 있습니다. 원본은 http://www.oreillynet.com/pub/wlg/7996

===========================
-Ofun
Geoff Broadwell

Oct. 05, 2005 02:05 PM

모든 프로젝트는 개발의 과정에 지향성을 부여하는 목표들이 있게 마련입니다. 어떤 프로젝트들에서는 이런 목표가 코딩 스타일이나 API의 형태들과 같은 묵시적인 방식으로 제시되기도 합니다. Autrijus Tang이 펄6.0 컴파일러를 만들기 위해 Pugs 프로젝트를 시작했을 때 그는 명시적인 목표를 정했습니다: “완전히 재미를 위해서”라는… 어떤 방향으로 최적화를 할 것인지 컴파일러에게 알려주기 위해 사용하는 -O 옵션을 이용해서 -Ofun이라고 재미있게 표현하기도 합니다. 재미를 위해 프로젝트를 옵티마이징 하겠다는 Autrijus의 결심은 아마도 그가 내린 가장 중요한 결정일 것입니다.

어떤 일을 오로지 재미를 위해 하는 것은 많은 이득이 있습니다. Pugs 프로젝트는 시작된지 8개월 만에 100여명의 커미터(committer: 소스를 작업해서 버전관리 시스템에 커밋할수 있는 권한을 가진 사람)가 생겼고, 하루 평균 30회 정도의 커밋이 일어날 정도로 활발한 활동이 생겨났습니다. 다른 많은 프로젝트들과는 달리 이런 커밋들은 몇몇 사람들이 거의 다 해치우는 그런게 아니었습니다. 가장 핵심 프로그래머 3명이 개발해서 커밋한 부분은 겨우 절반 밖에 되지 않습니다. 나머지들은 다양한 사람들이 함께 개발한 것입니다. 50%의 개발자들이 9번 이상의 커밋을, 25%의 개발자가 24회 이상, 10%의 개발자들은 150회 이상의 커밋을 했을 정도로 모두가 신나는 프로젝트였습니다.

팀은 생산적이기만 했던게 아니라 창조적이기까지 했습니다. 처음에는 Haskell로 작성된 단일 인터프리터 기반이었지만 지금은 자바 스크립트, Parrot, Perl 5 등의 컴파일러 기반까지 추가되었습니다. 암호화 알고리즘부터 IRC 로봇까지 수십개의 모듈들이 추가되었습니다. 많은 개발자들이 현재 공식적으로 개발이 진행되고 있는 코드에 다양한 새로운 개념들(continuations, coroutine, self-referential prelude, efficient type inferrence등)을 추가했으며 때로는 그것들이 공식 스펙에까지 들어가게 되기도 하였습니다.

물론 어떤 인지심리학자가 지적했듯이 “재미”야 말로 마음을 집중시키기 위한 가장 좋은 방법이기 때문에 그 결과가 훌륭한건 전혀 놀랄만한게 아닙니다. 개발을 즐기고 있지 않은 개발자들은 작업의 속도가 늦춰지거나 버그 투성이의 코드를 작성하거나, 잘못된 결정을 내리기도 하고 결국에는 프로젝트를 떠나게 되는 경우가 많습니다. 하지만 반대로 이야기 하면 무지막지한 즐거움은 프로그래머들에게 일에 대해 열정을 가지게 하고 결국에는 질적으로나 양적으로 그 결과를 나타나게 됩니다. 그렇기 때문에 재미를 위해 최적화한 작업은 다른 제품들보다 월등한 품질의 것을 만들어 내는데 매우 좋은 방법이 됩니다.

그렇다면 Autrijus의 -Ofun의 비밀은 무엇일까요? 그의 말에 따르면 재미의 핵심요소는 (다소 말초적인) 만족감, 경외감, 탐구심이라고 합니다. 다른 말로 하면 흔히 말하는 이메지니어링(imagineering)입니다. 구체적인 요령을 살펴보도록 하겠습니다.

-Ofun을 유일한 주 목표로 삼아라. - 앞으로 뭔가 비전이나 미션 스테이트먼트를 골라야 할 때 이것을 사용해 봅시다. (만약 관리자들이 허락한다면 당신은 좋은 회사에 다닌다는 의미일 것입니다) 이것 이외의 나머지 목표들은 그냥 부차적인 것으로 치부합니다.

현대적인 버전 콘트롤 시스템을 사용하자. - 이미 버전 콘트롤 시스템을 사용하지 않고 있다면 창피한줄 알기 바랍니다. CVS나 RCS, 소스 세이프와 같은 구식 시스템을 사용중이라면 그보다는 조금 낫지만 어쨌든 창피한 줄 알아야 합니다. 현대적인 버전 콘트롤 시스템은 아토믹 체인지세트를 지원합니다. (한가지의 목표를 위해 이루어진 모든 편집 행위들을 하나의 단위로 묶는 것을 말합니다.), 그리고, 디렉토리 자체나 심볼릭 링크, 태그나 브랜치에 대한 강력한 버전 콘트롤을 지원합니다. (파일이나 디렉토리들이 옮겨지거나 이름이 바뀌어도 변화 사항을 계속 추적이 가능하다는 뜻입니다) 무엇보다 현대적인 버전 콘트롤 시스템이 제공하는 점 중에 가장 좋은 점은 분산화된 환경에서 개발자들이 작업을 진행할 수 있다는 점입니다. 모든 개발자들이 자신의 로컬 컴퓨터나 노트북에 프로젝트에 관련된 파일을 가지고 있으면서 자신이 하고 싶은 작업을 맘대로 할 수 있다는 점입니다. 네트웍에 붙어있지 않은 경우에 오프라인 작업도 가능합니다. 작업한 내용을 합쳐야 하는 경우 개발자들은 중앙 서버나 다른 개발자에게 변화사항들을 보낼수 있습니다. darcs나 git같은 시스템들은 기반부터 분산화되어 있습니다. SVK 클라이언트는 현대적인 버전 관리 시스템인 Subversion 위에서 잘 동작합니다.

혼란스러운 상황을 포용하라 - 현대적인 인터넷 프로젝트들 (보통 Web 2.0이라 지칭합니다)의 경우에 기본 전재는 사용자들을 신뢰할 수 있다고 가정한다는 점입니다. 그리고, 또 한가지는 소수의 불량 사용자들이 입힌 피해를 복구 할 수 있는 도구 또한 사용자들이 가져야만 한다는 점입니다. 개발 프로젝트에 있어서 현대적인 버전 콘트롤 시스템은 “통제된 혼란상황”을 가능하게 해줍니다. 고의든 아니던 뭔가가 잘못되면 다른 개발자가 문제점을 파악해서 수정하기가 수월하게 해줍니다. 이런 안전망이 있기 때문에 사용자들에게 프로젝트의 아주 중요한 부분도 마음대로 건드릴 수 있게 하는 것이 가능한 것입니다.

데드락을 방지할 것 - 프로그래머가 코드를 커밋하는데 방해물이 있어서는 안됩니다. 보통 프로젝트 파일들의 완결성을 위해 사전 코드 리뷰 등의 일들이 행해지기도 합니다. 예를 들어 아토믹 체인지셋을 지원하는 시스템이 있기 전에는 어떤 한가지의 기능추가로 인해 변경된 것들을 취소하기가 매우 어려웠었습니다. 이제는 그런 작업이 쉬워졌습니다. 테스트 수트가 없이 개발을 하는 경우에 한가지 변경점이 어떤 버그를 만들어냈는지 알아내기가 쉽지 않습니다. 하지만 그렇다고 리뷰 과정을 강화하면 결국에는 코드 리뷰 자체 때문에 병목 현상이 발생하게 됩니다. 즉각적인 반응과 즉흥적인 면들이 많이 사라지게 됩니다. 예를 들어 리뷰어들이 너무 바빠지면 프로젝트의 진행이 결과적으로 느려지게 되고, 프로그래머들의 유머이지만 “버스 에러” (프로젝트의 주요 인물이 버스에 치이는 경우를 말합니다)가 일어나면 결국 프로젝트가 영원히 지체되는 경우도 생기게 됩니다.

커미터의 권한을 가능한 광범위하게 부여할 것 - 중앙 핵심 커미터 그룹만으로 프로젝트를 진행한다면 다른 일반 커미터들이 도움을 줄때에 비해서 작업 진행이 더디게 됩니다. 더 많은 커미터들을 얻을수록 프로젝트는 더 빠른 프로젝트 진행과 더 광범위한 아이디어를 얻을 수 있습니다. Autrijus는 다양한 테크니컬 그룹들을 하루 2-3차례 찾으며 커미터를 모으고 사람들의 궁금증을 유발시켜 프로젝트의 인지도를 높이는 활동을 했습니다. 커미터로 등록하는 과정은 쉽고 빨라야만 합니다. Autrijus는 프로젝트가 호스팅 되어 있는 rt.openfoundry.org의 사용자 등록 인터페이스를 수정해서 손쉬운 초대가 가능하도록 했습니다. 이렇게 해서 우연히 만나는 좋은 개발자들로 하여금 프로젝트에 손쉽게 참여해서 공헌할 수 있는 길을 열어 주었습니다. 초대과정이 완전히 자동화 되지 않았더라면 좋은 개발자들을 많이 놓치게 되었을 것입니다. 예를 들어 다른 시간대에 살고 있는 사람들을 초대하는건 힘이 들었을 것입니다.

코드를 가지고 작업하는 것이 아이디어를 가지고 일하는 것보다 재미있다 - 팀이 계속 아이디어를 코드로 녹여내도록 유도해야 합니다. 재빨리 아무렇게나 대충 작성한 코드들도 커밋을 하도록 합니다. 코드가 지저분한 것이 마음에 걸리면 나중에 리팩토링을 통해 깔끔하게 다듬으면 됩니다. 일단은 다른 사람들에게 보여주고 함께 일할 재료를 구비하도록 하는 것이 중요합니다. 현재의 상태에 관계 없이 어쨌거나 가능한 빠른 시점에 사람들에게 공개해서 함께 가지고 놀 수 있도록 해주는 것이 중요합니다. 그런 코드를 사용자들이 손쉽게 다운로드해서 가지고 놀 수 있게 하기 위해서 공개된 버전 콘트롤 서버의 사용이 꼭 필요한 것입니다. Autrijus는 친구들이 대충 작성한 코드를 릴리즈 하기를 주저할 때 그에 대해 토론하고 프로젝트의 홈페이지에 그 링크를 넣을 수 있겠느냐는 말로 용기를 북돋아 주어서 릴리즈를 하도록 한 경우가 많습니다. 프로젝트 전체에 걸쳐 가장 많이 쓰인 말이 바로 “URL?”이라는 질문이었다고 합니다.

두터운 커뮤니티를 만들자 - 이런 일을 하기위해 많은 방법이 존재합니다. 하지만 가장 중요한 점은 솔선수범을 하는 것입니다. 조언을 한다거나 기본적인 질문에 답해주는 것은 항상 해야만 하는 일입니다. IRC와 같이 손쉽게 물어볼 수 있는 채널이 존재해야 합니다. 그리고 또한 질문에 대해 호의적인 태도를 잊지 말아야 합니다. 그리고, 무작위적으로 생기는 재미있는 곁가지들을 인정하고 재미있게 지원해주어야 합니다. 예를 들어 Perl 분야에서의 JAPH, obfu, golf등이 그러한 것들입니다. 그리고, 또 하나의 좋은 방법으로 모든 개발자들이 자신의 이름을 AUTHORS 파일에 넣도록 해주는 것도 효과가 있습니다. (새로 참여한 개발자의 첫번째 커밋으로 이것을 이용하는 것도 좋습니다) 프로젝트가 당신 자신이 들어가서 살고 싶어 마지하지 않는 문화가 되도록 하는 것이 중요합니다.

흥분과 학습은 전염성이다 - Pugs 프로젝트에 일을 한 모든 사람들도 모두 나름대로 학습을 하며 다른 체험을 하며 살고 있는 프로그래머들입니다. 이들끼리 서로간의 지식과 그에 따르는 흥분을 공유하는 것이야말로 재미의 큰 요소입니다. 프로젝트에 참여하는 사람들은 아주 초보자들부터 최고의 테크니션들까지 다양한 사람들이 존재하게 되는데 이런 것들 자체가 재미의 요소입니다. 많이 알수록 더 많이 알고 싶어지는 것이 사람의 기본적인 심성입니다. 역시나 대단한 코드를 만들어내는 중요한 방법중 하나입니다.

많은 프로젝트들은 이런 요소들 중 일부를 “우연히” 성취하게 됩니다. 이것들 모두를 의식적으로 성취하는 프로젝트는 거의 없습니다. Autrijus는 그의 프로젝트를 -Ofun으로 옵티마이징 하기로 결정한 이래로 우리에게 놀라운 선물을 안겨주었습니다. 이제 여러분의 차례입니다.

Geoff Broadwell lives not far from O’Reilly headquarters in Santa Rosa, California, with a wonderful wife and daughter and four extremely spoiled cats. Geoff happily calls Perl the only computer language he ever really loved, having sampled a fair number before and since. He is on a personal mission to prove that dynamic languages are by far the best programming option for almost every purpose, and believes that the ultimate Linux distro of the future will contain little more than a kernel, an OpenGL and X server, the Parrot VM, and many, many Perl scripts.


Comment +2

  • 안녕하세요.^^

    좋은글 잘 읽었습니다.

    "재미"라는 요소를 요즘 잊어 먹고 있었는데...

    재미나는 프로그래밍을 위해서 삽질 고고씽!

  • 좋은글 공유해주셔서 감사합니다.
    원문읽기가 힘들어서 찾았는데 마침 나와서 잘 읽었습니다.

사용자 삽입 이미지
C의 키보드에서 뭔가 잘못된 부분이 있다는 것을 깨닫기는 그리 쉽지 않습니다. 바로 Caps Lock 키인데요, 대/소문자를 lock을 걸어주는 키인데 이게 사실 큰 쓸모가 없습니다. 사용 빈도도 그리 크지 않은데도 키보드 중의 가장 좋은 자리를 차지하고 있지요. 오히려 그 자리에는 Ctrl 키와 같이 많이 쓰이는 키가 오는게 낫지 않을까 생각하는 사람들도 많습니다.

IBM PC가 나오기 이전의 8비트 컴퓨터들이나 워크 스테이션의 키보드들을 보면 PC의 Caps Lock 키의 위치에 콘트롤 키(Ctrl)가 위치하고 있는것을 볼 수 있을 겁니다. vi나 emacs등의 에디터를 써봐도 보통 콘트롤 키가 그 위치에 있고 물결(~)키 위치에 ESC키가 존재한다는 가정 하에 만들어진 키 배치들이라 일반 PC용의 키보드로 vi나 emacs를 사용하면 손이 무척 피곤함을 느낄 수 있을 겁니다.

그래서 해피해킹 키보드 등의 키보드를 사용하거나 아니면 윈도우 레지스트리를 조작해서 Caps Lock 키를 누를 때 콘트롤 키로 동작하도록 매핑해놓고 사용하는 경우가 많습니다. 제 경우에도 그런데요, 그리 복잡하지 않은 방법으로 가능합니다.

윈도우 PC의 경우

위의 압축파일을
다운로드 받아서 압축을 풀면 두개의 파일이 나옵니다. caps_lock_to_control.reg 파일과 remove_scancode_mappings.reg 파일의 두개가 생기는데요, 앞의 파일을 더블클릭한 후 컴퓨터를 다시 부팅해주면 Caps Lock 키가 Ctrl키로 동작하게 됩니다. 나중에 다시 원상복구 하고 싶다면 remove_scancode_mappings.reg 파일을 실행하고 다시 부팅해주시면 됩니다.

리눅스 박스의 경우
X 윈도우의 경우에는 각기 데스크탑 환경에 따라 매핑 프로그램이 제공되는 경우도 있으니 그걸 사용해 주시면 되고요, Xmodmap 설정을 이용하셔도 됩니다. X에서는 손쉽게 할 수 있는거라 여기서는 설명을 생략합니다.

콘솔의 경우가 문제인데요, 보통 /usr/share/keymaps/i386/qwerty/us.map.gz 뭐 이런 파일이 보이는데 이곳에

keycode 58 = Control

이렇게 써주면 Caps Lock 키가 Ctrl키로 동작하게 됩니다.

원래 키보드와 하루 종일 씨름해야 하는게 프로그래머들이라 이런 작은 설정 하나만 바꿔줘도 삶이 얼마나 편해지는지 모릅니다. ^^



Comment +0

MP3 셔플 0.00002

iPod Shuffle을 보고 부러워서 일반 mp3 사용자들도 비슷하게 셔플 기능을 이용할 수 있는 프로그램을 만들어 봤습니다. iTunes에서 만들어놓은 플레이리스트에서 무작위로 원하는 용량만큼의 mp3 곡들을 뽑아서 mp3플레이어나 포켓 PC, PSP등에 복사해주는 프로그램입니다.


필요사항

iTunes가 설치된 윈도우 PC.


사용법은 간단합니다.

1. MP3셔플 0.00002 설치파일을 받아서 설치합니다. (대충 엔터만 치면 다 넘어갑니다.)

사용자 삽입 이미지

MP3shuffle.exe

MP3Shuffle 다운로드


2. “시작 -> 모든 프로그램 -> MP3 셔플 -> MP3 셔플”을 실행합니다.
사용자 삽입 이미지

3. “설정하기”를 누릅니다.
사용자 삽입 이미지

사용자 삽입 이미지

4. 원하는대로 설정을 합니다. 위의 예는 iTunes에 “신나는 노래들”이라고 만들어놓은 플레이리스트의 곡들 중에서 250메가의 파일을 무작위로 골라서 G:\My Music 디렉토리(제 포켓PC의 SD 카드가 마운트되는 곳입니다)에 원래 있던 파일들을 다 지우고 새로 복사해 넣으라는 설정을 해준 예입니다.

5. “MP3 파일들 복사!” 버튼을 누르면 파일이 복사됩니다. 이때 iTunes의 정보들을 가져오기 위해 iTunes가 실행됩니다.

사용자 삽입 이미지

버전별 변화사항

0.00002 (2005/08/29)

  • 한글 폴더로 복사할 때 나던 오류 수정
  • 복사 속도가 10배 빨라졌습니다. -_-;;

0.00001 (2005/08/28)

  • 첫 릴리즈

주의사항

개인적인 용도로 사용하기 위해 대충 만든거라 버그도 많고 디자인도 대충 했습니다. 개선했으면 하는 점들은 알려주시면 시간 되는대로 고치도록 하겠습니다만…

라이센스

그냥 가져다 쓰시면 됩니다. 소스 필요하신 분은 요청하시면 보내드리겠습니다.


Comment +0

사용자 삽입 이미지

한동안 잊고 있었는데 Ubuntu 리눅스 CD 20장 가까이가 도착했네요. 우분투 리눅스는 요즘 들어 최고의 인기를 끌고 있는 데비안 기반의 리눅스 배포본입니다. 그냥 설치만 하면 대부분의 하드웨어들을 제대로 잡아주고요 별다른 신경을 쓸 필요 없이 대부분의 설정이 사용자에게 편리하게 잡혀져 있어서 더욱 인기입니다. 게다가 회사의 정책으로 CD를 전세계로 무료로 원하는만큼 보내주는걸로 더 인기가 있습니다. http://ubuntu.com 에서 오른쪽메뉴의 “Shipit - Free CDs”에서 신청하면 됩니다.

플랫폼 별로 3가지 버전이 있는데 인텔 x86, AMD64, 파워PC(매킨토시)등입니다. 요즘 주변 사람들한테 이걸 나눠주면서 밥을 얻어 먹고 다니고 있지요. ^^


Comment +0

사용자 삽입 이미지

linux 2.6 tux












Joseph Pranevich - jpranevich AT kniggit.net
Translated by Nate Park (박종구) - youlsa AT i-on.net

첫번째 2.4 시스템이 부팅한 것이 엊그제 같은데 시간은 어느덧 흘러 리눅스 2.6이 세상에 나오게 되었다. 이 문서는 i386 플랫폼을 중심으로 리눅스 커널 2.6의 전반적인 면에 대한 설명을 위한 문서이다. 여기에 설명하는 새로운 기능들 중 몇몇은 공식적으로 또는 배포판 관리자들에 의해 커널 2.4로 백포팅(back-porting)된것도 있을 것이다. 그 외에도 커널 2.4의 유지보수 과정에서 추가된 기능들에 대한 설명도 함께 하도록 하겠다.

현재 이 문서는 10여개의 언어에 대한 번역문서가 존재하며 문서의 제일 아랫쪽을 참조해주기 바란다.

지금까지의 이야기들…
리눅스 커널은 리누스 토르발즈가 그의 386 컴퓨터에서 실행가능한 미닉스(minix)와 비슷한 운영체제를 만들기 시작한데서 시작되었다. (처음에 리누스는 운영체제의 이름을 Freax라고 짓고 싶었다고 한다) 싱글 CPU의 i386머신에서만 실행 가능한 리눅스 커널 1.0의 공식 릴리즈는 1994년 3월이었다. 그로부터 1년 후인 1995년 3월에 최초로 i386이 아닌 플랫폼에서 실행가능한 (그러나 여전히 싱글 CPU에서만 동작하는)리눅스 1.2가 릴리즈 되었다. 1996년 6월에 리눅스 2.0이 릴리즈 되었다. 2.0에는 동작 가능한 여러 플랫폼이 추가 되었지만 무엇보다도 다중 CPU를 갖는 머신(SMP)에서 동작하는 최초의 버전이었다. 2.0의 릴리즈 이후 주요 버전의 릴리즈 속도는 다소 늦춰졌다. (리눅스 2.2가 1999년 1월, 2.4가 2001년 1월에 각각 릴리즈 되었다) 하지만 각각의 마이너 버전업은 자주 일어나 지원되는 하드웨어의 범위와 확장성이 개선되어 갔다. (리눅스 2.4는 최초로 ISA 플러그앤 플래이와 USB, PC 카드 등의 기능이 추가되어 최초로 사용자들의 데스크탑에서 쓸만한 버전이었다는 점도 주목할만 하다) 리눅스 2.6은 2003년 12월 17일에 릴리즈 되었다. 2.6은 다양한 추가 기능도 기능이지만 매우 대용량 시스템에서부터 아주 작은 시스템(PDA등)까지 고루 지원한다는 점에 있어서 또 한번의 큰 개선버전이기도 하다.

핵심 하드웨어 지원
리눅스의 가장 강력한 점 중 하나는 그 유연성과 지원 하드웨어의 광범위함에 있다. 이 문서는 i386 기반의 PC에서의 사용에 중점을 맞추고 있기는 하지만 리눅스 2.6의 뛰어난 하드웨어 지원은 짚고 넘어갈만 하다.

축소 - 임베디드 시스템을 위한 리눅스
리눅스 커널 2.6의 중요한 두가지 변화 중 하나는 유씨리눅스(uClinux) 프로젝트를 메인 커널에 병합했다는 것이다. 유씨리눅스 프로젝트는 마이크로 콘트롤러를 위한 리눅스를 제작하는 프로젝트이다. 유씨리눅스는 이미 임베디드 시장에서는 주요 OS중 하나로 인정받고 있기 때문에 메인 커널에 이를 병합 하는 것은 앞으로의 임베디드 시장에서 리눅스의 발전에도 큰 힘이 된다고 볼 수 있다. 일반적인 리눅스 커널과는 달리 임베디드 플랫폼에 사용되는 리눅스 커널은 하드웨어적 제약 때문에 몇가지 제한이 있게 된다. 가장 중요한 점 하나는 MMU(메모리 관리 유닛 - 프로텍티드 모드의 핵심적 기능을 한다)가 없다는 것이다. 물론 그래도 멀티태스킹 운영체제이기는 하다. (메모리 관리 기능이 없을 경우 한 프로세스가 다른 프로세스의 데이타 영역에서 자료를 읽고 쓰거나 심지어는 프로세스 자체를 망가뜨릴 수도 있다) 하지만 이런 경우 멀티 유저 시스템을 구성하기가 곤란해지지만 PDA와 같은 저가형 소형 디바이스들의 경우에는 훌륭한 선택일 수도 있다. 이런 아키텍쳐 변화가 중요한 것은 2.6 이전까지의 리눅스 커널은 사실상 리누스의 초기 작업들이 수행된 인텔 80386 플랫폼의 영향이 상당히 많이 남아 있었다는 점 때문이다.

리눅스 커널 2.6에서 히타치 H8/300시리즈, NEC v850, 모토롤라의 m68k 임베디드 프로세서 등이 추가적으로 지원되기 시작했다. 보통 리눅스 사용자들이 처음으로 사용하는 PDA가 팜 파일럿 계열인 경우가 많기 때문에 모토롤라의 프로세서들은 어느 정도 친숙할 것이다. 모토롤라나 Lineo, Arcturus등의 Dragonball, Cold Fire같은 제품들이 지원된다. 슬프게도 MMU가 없는 예전의 m68k 계열의 CPU들은 지원되지 않는다. (올드맥에 사용되는 CPU이다) 누군가가 취미 프로젝트로 오래된 머신들에 리눅스를 포팅하는 프로젝트를 시작할 수도 있을 것이다.

유씨 리눅스 통합의 일부는 아니지만 리눅스 커널 2.6에는 Axis Communications의 ETRAX CRIS(Code Reduced Instruction Set)가 지원된다. (사실 이 기능은 2.4 릴리즈 이후 유지보수의 과정에서 추가되었다) 이것들은 주로 네트웍 하드웨어에 사용되는 MMU가 포함된 임베디드 프로세서이다. MMU가 포함되지 않은 프로세서에 대한 지원도 외부 프로젝트로 수행되고 있는 것으로 안다.

하드웨어 지원에 덧붙여 메인 커널에 임베디드에 관한 부분을 통합하여 얻게 된 이점들이 여러가지가 있지만 겉으로 보기에는 특별해 보이지는 않지만, 몇몇 변화사항들, 예컨데 스왑 없이도 시스템을 구성할 수 있는 능력 등등이 커널을 더욱 견고하게 만든 점등이 있을 수 있다.

대규모로 — NUMA와 대규모 기계들
리눅스 커널 2.6의 근본적인 두가지 변화 중 나머지 하나는 아이러니하게도 앞의 것과 정반대 방향으로의 확장이다. 리눅스가 더욱 더 대규모 서버에서 사용 가능하도록 하는 방향이다. (큰 시스템들 중 어떤 시스템은 i386 기반이겠지만 어떤 것은 아니다) 이 방향에서의 리눅스의 가장 큰 변화는 NUMA 서버의 지원이다. NUMA(Non-Uniform Memory Access)의 지원은 멀티 프로세싱에 있어서 SMP에서 한걸음 더 나아간 것으로 많은 CPU를 가진 시스템에서 좀 더 효율적으로 동작할 수 있게 해주는 첫걸음이라고 할 수 있다. 다중 CPU 서버에서는 단일 메모리 버스에 여러개의 CPU들이 동시에 억세스를 하게 되는데 여기에서 병목현상이 발생하게 된다. NUMA 서버에서는 이런 문제를 각각의 CPU에게 다른 메모리보다 가까운 메모리를 지정해주도록 함으로써 해결한다. 기술적으로 정확한 표현은 아니지만, 이렇게 상상하면 쉽다. 시스템이 여러장의 카드로 이루어 졌다고 상상해보자. 각각의 카드들은 각각 자신만의 CPU와 메모리, 입출력 장치들을 가지고 있다. 시스템에 이런 카드들이 많이 있다고 생각하면 각각의 CPU는 (물론 다른 카드의 메모리와 통신을 할수도 있겠지만) 자신과 같은 카드에 있는 메모리가 가장 가깝고 속도도 빠를 것이다. NUMA 아키텍쳐는 이런 식으로 타이트하게 구성된 클러스터라고 생각할 수 있다.

이런 NUMA 머신들을 효율적으로 지원하기 위해 리눅스 커널에서는 몇가지 개선사항을 도입하였다. 우선, 리눅스 커널 내부에서 각각의 프로세서와 메모리들, 입출력 장치들의 관계를 알아낼 수 있도록 위상(topology) API들이 추가되었다. 이를 기반으로 커널의 프로세스 스케쥴러는 최대한 효율적으로 가까운 리소스가 어떤 것인지를 이해하고 활용할 수 있게 된다. 추가적으로 많은 NUMA 머신들은 각 노드가 차지하고 있는 메모리 사이에 구멍이 뚫리도록(어드레스 공간이 연속적이 않다는 뜻) 구현되어 있는데 리눅스 커널에서는 이런 비연속적인 메모리도 제대로 다룰 수 있다. 여기에 언급한 것들 말고도 리눅스 커널에는 대용량의 서버들을 제대로 지원할 수 있는 여러가지 개선사항들이 개선되었고 앞으로도 더욱 많은 개선이 있을 것이다.

서브 아키텍쳐(subarchitecture) 지원
앞서의 두가지 변화사항만큼 큰 변화는 아니지만 리눅스 커널의 새 버전에는 더욱 많은 머신에서 리눅스를 실행시킬 수 있도록 해주는 서브 아키텍쳐(subarchitecture)라는 개념이 구현되었다. 이전 버전까지의 리눅스 커널에서는 CPU의 종류와 아키텍쳐의 종류가 일치한다고 가정해왔다. 예를 들어 CPU가 i386이라면 무조건 PC/AT 아키텍쳐 기반의 PC라고 가정을 했던 것이다. 리눅스 2.4에서 이러한 가정이 깨졌는데 SGI의 Visual Workstation때문이었다. CPU만 인텔의 칩이였고 아키텍쳐가 PC와는 완연히 다른 기계이다. (물론 다른 아키텍쳐에서는 그 전에도 이 가정이 깨지긴 했다. m68k 아키텍쳐에서 Amiga, 매킨토시 등이 동시에 지원되는 등의 예가 있었다.) 하지만 리눅스 커널 2.6에서의 큰 변화는 모든 아키텍쳐에 대해 동일한 방법으로 서브 아키텍쳐를 지원할 수 있도록 표준화 되었다는 것이다.

이런 표준화 덕분에 i386에서도 두개의 새로운 플랫폼이 추가 지원된다. 첫번째는 NCR의 Voyager 아키텍쳐이다. 이것은 32개까지의 486-686 CPU를 지원하는 SMP 시스템이다 (현재의 표준인 인텔 MP 스펙이 나오기 전에 나온 시스템이다). 실제 판매된 갯수는 그리 많지 않고 판매된 모든 기계가 지원되는 것은 아니다. (최초에 판매된 머신들은 지원되지 않는다) 새로 추가된 두번째 플랫폼은 NEC가 개발하여 비교적 최근까지 일본 시장에서 독점적 위치를 차지하고 있던 PC-9800이다. PC-9800은 8086에서 시작하여 펜티엄급과 SMP까지 지원되던 성숙한 플랫폼이었다. (물론 리눅스 커널은 80386이상의 머신에서만 동작한다) 미국에는 전혀 소개되지 않았지만 마이크로 소프트의 윈도우 95까지 이 머신에서 동작하도록 포팅되어 판매된 바 있다. 하지만 그 이후에는 표준 PC가 그 자리를 대치해가고 결국 단종되었다.

이런 “약간만 다른” 하드웨어 타입들을 지원할 수 있는 구조 덕분에 앞으로 스토리지 기기라던가 유명 CPU를 사용하는 머신들에 대한 지원이 손쉬워졌다. 하지만 이것이 만능은 아니다. 이런 서브 아키텍쳐는 IRQ 라우팅과 같이 하드웨어의 최하위 레벨의 콤포넌트가 다른 점을 커버하기 위해서 나온 것이다. PC와 거의 동일하지만 아주 약간만 다른 엑스박스에서 리눅스를 돌리는 것과는 다르다는 점을 명심해야 한다.

하이퍼쓰레딩
리눅스 커널 2.6에서의 또다른 큰 진보 중 하나는 하이퍼 쓰레딩의 지원이다. 하이퍼 쓰레딩은 현재 최신 펜티엄 4에서만 지원되고 있으나 다른 곳에서도 지원할 수 있을것이다. 하드웨어 적으로 하나의 CPU를 두개나 그 이상의 CPU로 보이도록 해주는 기술이다. 이것은 어떤 경우에는 큰 퍼포먼스 향상을 불러오지만 스케쥴링의 복잡성이 증가하는 원인이 되기도 한다. 커널의 개선사항중 하나는 이제는 커널이 전 CPU(실제이건 가상이건)에 걸쳐 부하를 분산하고 최적화를 할 수 있다는 점이다. 이전 버전의 리눅스 커널에서는 전체적인 부하를 계산할 수 없어서 한개의 CPU가 혹사당하는 일이 잦았었다. 대단한 점은 리눅스 커널이 시장에서 이 기능을 제일 깔끔하고 지능적으로 지원하고 있다는 점이다. (윈도우 2000 서버는 가짜 CPU들을 볼 수 있으나 가상 CPU로 이용하려면 추가 CPU 라이센스가 필요했다. 마이크로 소프트가 이 기능을 제대로 지원하게 되는 것은 윈도우 XP 부터이다)

리눅스 내부
확장성의 개선
앞서 나열한 NUMA나 하이퍼쓰레딩과 같은 일반적인 기능들 이외에도 리눅스2.6은 인텔 CPU 기반 서버를 십분 활용하게 해주는 기능들을 가지고 있다. 가장 중요한 개선사항은 PAE(Physical Address Extension)이라고 부르는 인텔 하드웨어의 기능이다. 이것은 최신의 32비트 x86 시스템들이 64GB까지의 RAM을 페이지 모드로 읽을 수 있도록 해주는 기능이다. 멀티 CPU 시스템에서의 APIC 지원 개선을 통한 IRQ 밸런싱 기능도 상당히 개선되었다.

새로운 하드웨어 기능 추가 이외에도 내부적 한계치들이 가능한한 최고 수준까지 높여졌다. 예를 들어 유니크한 사용자와 그룹의 수가 65,000에서 40억으로 늘어(16비트에서 32비트로 늘어난 것이다) 리눅스를 파일서버나 인증서버로 활용하는데 지장이 없도록 개선되었다. 프로세스 ID(PID)의 갯수도 32,000개에서 10억개로 증가하여 uptime이 매우 길고 바쁜 서버에서 새로운 프로세스를 생성하는 퍼포먼스가 향상되었다. 열수 있는 최대한의 파일의 갯수는 늘지 않았지만 이전과 같이 미리 원하는 한계치를 지정하지 않아도 자동으로 늘도록 수정되었다. 마지막으로 리눅스 2.6에서 블럭 디바이스들이 64비트를 지원할 수 있도록 수정되었다. i386과 같은 32비트 플랫폼에서도 마찬가지이다. 그래서 일반적인 하드웨어에서 파일 시스템을 16TB 까지 사용할 수 있게 되었다.

리눅스 커널 2.6의 확장성에 대한 개선사항 중 또다른 중요한 점은 커널 자체가 디바이스의 여러 타입을 지원하는 것 뿐만 아니라 한가지 타입의 여러가지 디바이스의 종류를 지원한다는 사실이다. 지금까지의 리눅스들은(사실은 거의 모든 유닉스가 그러하지만) 시스템의 사용자와 프로그램들이 숫자가 메겨진 디바이스 노드와 통신을 하도록 되어 있다. (/dev 디렉토리의 항목들) 이 디바이스 노드들은 255개의 주 디바이스로 제한되고 각각 255개의 부 디바이스로 제한된다. 예를 들어 /dev/sda2라는 디바이스는 첫번째 SCSI 드라이브의 두번째 파티션이라는 뜻인데 주 디바이스 번호가 8이고(SCSI가 다 그렇다) 부 디바이스 번호가 2이다. 다른 타입의 디바이스들은 각각의 주 디바이스 번호와 부 디바이스 번호를 할당 받는다. 하지만 255개 이상의 디바이스가 필요한 서버에서는 난관에 봉착하게 된다. (대형 스토리지 어레이, 프린트 팜 등) 리눅스 2.6에서는 이러한 제한들이 4096 주 디바이스와 각각에 100만개의 부 디바이스를 가질 수 있도록 확장되었다. 현재 나와 있는 최고 사양의 머신들도 아무런 문제없이 지원할 수 있도록 되었다.

상호작용성과 응답성
확장성과 함께 새 버전의 개발과정에서 중요하게 여겨진 것은 시스템의 응답성이다. 이것은 일반적인 데스크탑 사용자뿐만 아니라 고도의 정확성을 요구하는 응용 프로그램에게도 유용하다. 물론 이런 개선에도 불구하고 리눅스 2.6은 여전히 리얼타임 OS는 아니다. 리얼타임 OS가 되기 위해서는 액션에 대한 응답이 정해진 시간 안에 분명히 보장되어야 하고 예측가능해야 한다. 그럼에도 불구하고 이러한 응답성의 개선은 모든 계층의 리눅스 사용자들에게 호평받을 것이다. (물론 리얼타임 OS의 기능을 제공하기 위한 프로젝트가 존재한다. 이 프로젝트는 다음번 메이저 릴리즈에 공식적으로 공표될 것이다)

리눅스 커널 2.6의 가장 중요한 개선 사항중 하나는 드디어 커널 자체가 선점형으로 동작한다는 것이다. 이전 버전의 리눅스에서 커널 자체가 작업을 하는 동안에는 다른 프로세스를 위한 인터럽트를 허용하지 않아왔다. (물론 다중 CPU인 시스템에서는 CPU당 그렇다) 리눅스 2.6에서는 커널 자체가 작업을 하는 도중에도 인터럽트되어 다른 어플리케이션이 자신의 작업을 해나갈 수 있다. 물론 여전히 커널이 처리하는 도중에 인터럽트 되지 않는 작업이 있기는 하다. 하지만 실제 상황에서 너무나 짧은 시간이라 대부분의 사용자들은 그 딜레이를 거의 눈치채지 못할 것이다. 결국, 시스템에 부하가 많이 걸리는 상황에서도 사용자의 입력에 대해 시스템이 매우 빠르게 동작하는 것을 느끼게 될 것이다.

리눅스의 입출력 서브시스템들에 대폭적인 수정이 가해져서 큰 부하 아래에서도 응답성이 좋아지도록 개선되었다. 이것은 I/O 스케쥴러를 재작성하여 구현되었다. I/O 스케쥴러는 특정 시간에 어떤 프로세스가 디바이스들을 점유할 것인지를 결정하는 역할을 하는 커널 내의 루틴이다. 새로 작성된 스케쥴러는 한 프로세스가 너무 오랫동안 대기하지 않도록 효율적인 배분이 가능하게 해준다.

어플리케이션 측면에서 리눅스용 프로그램들의 응답성이 개선되도록 돕기 위해 새로운 futex(Fast User-Space Mutex)가 지원된다. Futex는 여러 프로세스나 쓰레드들 사이에서의 레이스 컨디션(race condition)을 피할 수 있도록 이벤트들을 시리얼라이즈(serialize)되도록 한다. 기존의 Mutex와는 달리 Futex는 절반 정도는 커널에 기반하고 우선순위가 높은 어플리케이션이나 쓰레드가 리소스에 우선적으로 접근할 수 있도록 한다. 프로그램이 태스크들에 우선순위를 먹여 이를 기반으로 Mutex를 걸도록 함으로써 반응시간을 향상 시킬 수 있는 것이다.

위의 것들에 덧붙여 많은 경우에 응답성을 강화해주는 소소한 개선사항들이 포함되어 있다. 이중 하나는 이른바 “Big Kernel Lock”을 제거했다는 것과 파일시스템 미리 읽기의 최적화, 소규모 파일 처리 등등이 그것이다.

기타 개선 사항들
다른 오픈소스 프로젝트들도 그렇듯이 리눅스는 오픈 스탠다드를 지향한다. 커널 2.6의 주요 개선 사항중 하나는 쓰레드 구조의 변경을 통해 POSIX 쓰레드 라이브러리(NPTL)을 돌릴 수 있다는 것이다. 이것은 많은 쓰레드를 동시에 돌리는 펜티엄 프로나 그 이상의 프로세서에서 큰 퍼포먼스 개선효과를 보여주며, 아마도 엔터프라이즈 시장에서 가장 각광 받을 개선사항일 수 있을 것이다. (사실 레드햇은 이미 이 기능을 2.4로 백포트(backport)하여 레드햇 9와 어드밴스드 서버 3.0에 포함시켰다) 이 변화는 쓰레드 그룹, 각 쓰레드의 로컬 메모리, POSIX 스타일의 시그널 등과 같은 리눅스 쓰레드의 새로운 컨셉들을 포함한다. 한가지 단점은 몇몇 버전의 Sun Java와 같이 예전의 리눅스를 기준으로 작성된 어플리케이션들이 제대로 동작하지 못할수도 있다는 것이다. 하지만 장점이 워낙 크기 때문에 대부분의 문제 어플리케이션들도 결국에는 새 커널을 제대로 지원할 것이다.

모듈 서브시스템과 통합 디바이스 모델
요즘의 운영체제들은 수많은 종류의 내부/외부 버스와 디바이스들을 다루어야만 한다. 새 버전의 리눅스에서 이 점이 대폭 보강된 것도 그리 놀라울 일은 아니다. 모듈 로더뿐만이 아니라 하드웨어에 대한 이해방식 자체도 상당한 변화가 있다. 변화된 부분은 우스울 정도로 간단한 것부터 시작해서 (드라이버 모듈이 이전에는 “.o”확장자를 가졌는데 이제는 커널 오브젝트를 뜻하는 “.ko”로 바뀐 것) 크게는 통합 디바이스 모델(unified device model)의 도입까지이다. 모두 안정성의 개선과 이전 버전의 한계를 극복하기 위한 방향으로 작업이 진행되었다.

모듈 서브 시스템의 안정성을 강화하기 위해 많은 큰 변화사항들이 존재한다. 모듈을 내리는(unload) 경우 모듈이 사용중인 와중에 내리게 되는 경우를 줄었다. 이전에는 대부분 시스템 크래쉬를 유발하는 경우가 많았었다. 안정적으로 돌아가야 하는 서버들을 위해 모듈을 내리는 기능을 아예 꺼버릴 수도 있게 했다. 추가적으로 각 모듈이 자신이 어떤 하드웨어를 지원하는지 알도록 하고 이를 공표할 수 있는 공표하는 표준절차가 마련되었다. 이전 버전의 리눅스에서는 각 모듈이 자신이 지원하는 하드웨어가 무엇인지는 알고 있었지만 이 정보가 모듈 밖에서는 공유되지 못했었다. 이 개선사항 덕분에 레드햇의 kudzu와 같은 하드웨어 관리 프로그램들이 좀 더 지능적으로 개선될수 있게 되었다. 공식적으로는 지원되지 않으나 거의 비슷한 구조를 가진 하드웨어에 대해 드라이버에게 특정 하드웨어에 대해 강제로 동작하도록 하는 것이 가능해졌다.

새 커널 버전에서는 모듈 로딩 이외에도 디바이스 모델 자체가 상당한 변화를 겪었다. 정해진 디바이스를 감지하는 등의 단순한 역할만을 행하는 모듈 로더와는 달리 디바이스 모델은 시스템 내의 하드웨어 전반에 대한 책임을 지는 좀 더 깊은 개념이다. 리눅스 2.2 이전에는 모듈 레벨에서만 모든 것을 판단하는 통합 디바이스 모델의 가장 간단한 서포트만이 존재했었다. 지금까지는 이러한 구조로도 충분했으나 ACPI등 최신 하드웨어 기능들을 모두 이용하기 위해서는 각 디바이스가 사용하는 리소스만 아는 것으로 충분하지 않다. 디바이스가 사용하는 버스의 종류라던가 가지고 있는 부디바이스의 종류나 현재의 전원공급 상태, 충돌시 사용 리소스를 바꾸어야 하는지 여부 등의 여러가지 상태들을 파악하고 있어야만 한다. 심지어는 현재의 디바이스에 알맞은 모듈이 이미 로드되어 있는지 여부도 파악할 수 있어야만 한다. 리눅스 커널 2.4에서 PCI와 PC 카드, ISA, PnP 버스들을 동일한 인터페이스로 묶을 수 있는 통합 인터페이스가 도입되었다. 리눅스 2.6에서는 새로운 형식의 커널 오브젝트(kobject)를 통해 시스템의 디바이스 지원을 한 차원 높이 끌어올리고 있다. 레퍼런스 카운팅이나 전원 관리, 유저 스페이스(user-space)와의 연결 방법 제공 등 더 나은 통합된 인터페이스를 제공한다.

디바이스들에 대한 자세한 정보가 커널에 모두 제공되므로 랩탑이나 데스크탑 컴퓨터들에 대한 좀 더 심도 깊은 지원이 가능해졌다. 가장 좋아지는 부분은 PC카드나 USB, Firewire, 핫플러그 PCI등의 핫 플러그(hot plug)기기들에 대한 부분이 될 것이다. 되돌아 생각해보면 리눅스 2.2 이전까지는 이런 종류의 하드웨어 지원이 전무했었다. 근래에는 핫 플러그 방식으로 동작하는 기기가 예외적인 상황이 아니라 일반적인 경우가 되었으므로 새로운 디바이스 관리 시스템에서 기존의 디바이스와 핫 플러그 디바이스의 차이점을 제거하는 것이 꼭 필요했다. 커널의 서브 시스템에서 부팅시에 찾아낸 디바이스와 실행중에 찾아낸 디바이스의 차이점을 차별하지 않음으로써 핫 플러그 방식의 디바이스를 처리하는 방식이 간단해졌다. 이번 버전에서 새로 작성되고 개선된 부분은 전원 관리에 대한 부분이다. 최근에 새로운 표준으로 사용되는 ACPI(Advanced COnfiguration and Power Interface)는 지난 버전에 약간 엉성한 방식으로 지원됐었다. 이전의 표준이었던 APM(Advanced Power Management)와는 달리 ACPI를 사용할 때에는 OS가 모든 디바이스들에게 전원 공급 상태를 바꾸도록 통보해야 한다. 하드웨어 전체에 대한 정보를 모두 파악하고 있지 않다면 커널이 이런 통보 작업을 하는 것이 불가능할 것이다. 이 두가지 예로 든 것들 이외에도 통합의 효과로 이득을 보는 몇몇 분야들이 있다. 하드웨어의 연결시험(auditing)이나 감시 등이 그것이다.

마지막으로 (그리고 가장 중요한지도 모르지만) 시스템 파일시스템가 분화된 것이 중요한 변경사항이다. 시스템 파일 시스템은 “sysfs”라고 부르는데 프로세스는 ‘proc’, 디바이스들은 ‘devfs’, UNIX98 수도터미널(pseudo-terminal)들은 ‘devpts’이다. /sys에 마운트되는 이 파일 시스템은 커널이 디바이스를 어떻게 보는지 그대로 보여준다. (물론 예외도 있다) 검색된 디바이스의 속성의 갯수를 포함해서 디바이스의 이름과 IRQ, DMA, 전원 공급 상태 등의 사항들을 커널이 어떻게 파악하고 있는지 알 수 있다. 물론 이런 변화는 단기적으로는 혼란을 초래할 수도 있지만 결국에는 잘 이전될 것이다. 약간의 과도기가 있을 것이다.

시스템 하드웨어 지원
리눅스가 주류로 나아가면서 각각의 커널에서 지원하는 디바이스들이 비약적으로 늘고 있다. 비교적 새로운 기술(USB 2.4등)이나 기존의 오래된 기술들(MCA 2.2등)도 포함된다. 커널 2.6이 발표되면서 리눅스가 지원하지 않는 하드웨어는 비교적 적다. 하지만 아직도 지원되지 않는 PC 하드웨어들이 있다. 그렇기 때문에 유연성을 향상시키기 위해 새로운 기능을 추가하기 보다 i386 하드웨어의 지원이 개선되는 것이다.

내장 디바이스
프로세서의 타입과 거의 동일한 수준으로 비슷한 것이 시스템이 어떤 버스를 사용하고 있는지 여부이다. PC 업계에는 예전의 ISA를 비롯하여 현재의 외부 시리얼 장치나 와이러리스 버스에 이르는 필요 이상으로 많은 종류의 버스가 혼재되어 사용되고 있다. 리눅스는 언제나 최신의 버스나 디바이스가 발표되고 인기를 끌게 되면 즉시 이를 차용하여 지원하도록 하고 있지만 비교적 덜 인기가 있는 기술에 대해서는 조금은 느린 대응을 보이고 있다.

리눅스의 시스템 내부 디바이스에 대한 지원은 비교적 공명정대하다. 가장 좋은 예가 ISA 플러그앤 플레이에 대한 지원이다. 리눅스는 커널 2.4 이전까지는 어떠한 PnP에 대한 지원도 제공하지 않았었다. 하지만 이 지원은 PnP BIOS의 지원이 구현되면서 모두 지원되기 시작했다. 디바이스 이름에 대한 데이타베이스나 기타의 호환성에 대한 것들이 변화되면서 그렇게 되었다. 결과적으로는 이제 리눅스는 진정한 플러그앤 플레이 운영체제가 되어 버렸다. 다른 오래된 버스들, 예컨데 MCA나 EISA등이 모두 새로운 디바이스 모델에 포함되어 한꺼번에 구현된 것이다. 커널 2.6에서는 PCI(Peripheral Component Interconnect) 서브 시스템의 개선 사항에 포함하여 몇가지 이슈들이 개선되었다. 핫 플러그 PCI, 전원 관리, 다수 AGP의 지원, 등이다. 마지막으로 이런 버스들과 함께 리눅스 2.6에서는 “legacy” 버스라는 개념을 포함한다. 이것은 각각의 버스에 대해 거의 반드시 있을만한 디바이스에 대한 정보를 미리 가지고 있는 것이다. 예를 들자면 PC에서는 온보드 시리얼 포트, 패러렐 포트, PS/2 포트등이 어떤 버스에나 거의 반드시 포함되어 있는 디바이스들이다. 물론 이런 지원을 하기 위해서는 펌웨어를 억세스 하는 등의 좀 더 복잡한 작업이 수반되지만 일반적으로는 새로운 드라이버 패러다임에 걸맞는 방식으로 모든 디바이스들을 제어하도록 하는 수단이 된다.

외장 디바이스
최근의 개발 과정 동안 약간 오래된 내부 디바이스 버스들에 대한 새로운 기능추가가 좀 덜했던 것은 사실이지만 새로운 외장 하드웨어에 대한 지원은 그렇지 않다. 이쪽으로 가장 중요한 개발 사항 중 하나는 USB 2.0 디바이스에 대한 지원이다. 이들 디바이스들은 고속 USB 디바이스라고 불리는데 480Mbps의 속도가 나와 이전의 12Mbps로 동작하던 USB 디바이스들과 대조를 이룬다. 이것과 관련된 최신 표준인 USB OTG(USB On-the-go)는 현재 리눅스 2.6에서는 지원되지는 않는다. (이것은 PC를 끼지 않고 디지탈 카메라를 프린터에 연결하는 등의 일을 가능하게 해준다) (이에 대한 패치는 존재하지만 아직 메인 커널에는 통합되지 않았다) 이외에도 USB 디바이스들을 파악하는 루틴이 새로 작성되어 동일한 타입의 디바이스가 여러개일 때에도 잘 동작하도록 수정되었다. 이런 큰 변화들 말고도 리눅스 유저들을 위해 USB 디바이스들의 안정성, 호환성이 향상되도록 개발 과정에서 많은 배려가 있었다.

이런 것들과 정반대의 방향에서, 리눅스 2.6에서는 리눅스 시스템이 USB 호스트가 아닌 USB 디바이스로 동작하는 것이 가능하도록 하는 부분이 추가되었다. 예를들어 리눅스 기반의 PDA가 PC에 연결되어 제대로 동작할 수 있도록 하는 등의 일들을 위한 기반이 마련되었다. 임베디드 디바이스에서 리눅스가 제대로 사용되기 위해 꼭 필요한 기능이라고 할 수 있다.

무선 디바이스
최근 몇년간 무선 디바이스들의 사용이 인기를 끌기 시작했다. 어떨 때에는 케이블이라는 것이 과거의 유물이고 몇년 안에 사라질 것처럼 생각되기도 한다. (물론 전원 케이블은 예외이다) 무선 디바이스에는 가장 흔히 쓰이는 네트웍 디바이스 부터 PDA와 같은 기기까지 포함한다.

무선 네트웍 분야에서 디바이스들은 보통 장거리 (아마추어 무선을 통한 AX.25) 디바이스와 단거리 (802.11 등) 디바이스로 나뉜다. 이들 각각의 디바이스들에 대한 지원은 리눅스 커널의 초창기인 1.2 시절부터 시작되었으며 커널 2.6에서 새로 갱신되었다. 가장 큰 변화는 단거리 무선 인터넷 기기들이 모두 “wireless”라는 부 시스템과 API로 통합되었다는 사실이다. 이런 통합은 디바이스의 종류별로 다른 설정을 해주어야 하는 문제를 해결하여 모든 디바이스에 대해 동일한 동작을 하는 사용자 프로그램의 작성을 가능하게 해준다. 이런 통합 이외에도 디바이스의 동작 상태 변경에 대한 통지라던가(로밍과 같은) 무선 디바이스에서 일어나는 주기적인 딜레이에 대한 TCP 차원의 처리와 같은 개선사항들이 포함되었다. 커널 2.4 사용자들로부터 무선 디바이스의 지원에 대한 요구가 많기 때문에 이들 많은 개선사항들이 2.4로 백포트 되어있기도 하다.

일반적인 무선 디바이스 분야에서 IrDA와 같은 디바이스에 대해 전원 관리라던가 커널 드라이버 모델로의 통합과 같은 개선사항이 있다. 그리고, 블루투스 디바이스들에 대한 지원에 비약적 향상이 있었다. 블루투스는 IrDA와 비슷하기는 하나 시거리가 확보되지 않아도 사용 가능한 단거리 저전력형 무선 디바이스 통신 방식이다. 프로토콜로서의 블루투스는 PDA나 핸드폰, 프린터, 자동차용 디바이스들과 같은 어떤 분야에서도 사용될 수 있도록 설계된 프로토콜이다. 프로토콜 자체는 두가지 방식으로 이루어져 있는데 오디오 데이타와 같이 손실 가능성 데이타를 전송하는데 주로 쓰이는 SCO(Synchronous Connection Oriented)방식과 정밀한 데이타 전송이 필요한 부분에 쓰이는 L2CAP(Logical Link Control and Adaptation Protocol)이 그것들이다. L2CAP 프로토콜은 많은 서브 프로토콜(sub-protocol)들을 지원한다. (포인트 투 포인트 네트워킹을 위한 RFCOMM, 이더넷과 같은 네트워킹을 위한 BNEP등) 블루투스를 활용하기 위한 리눅스의 지원은 날이 갈수록 향상되어가고 있고 소비자들이 더 많은 블루투스 디바이스들을 사용하게 되면 될수록 그 지원도 향상될 것이다. 최초의 블루투스 지원은 커널 2.4에서 시작되었다는 점도 특기할 만 하다.

블록 디바이스 지원
스토리지 버스
IDE/ATA(integrated DRive Electronics/Advanced Technology Attachment)나 SCSI(Small Computer System Interface)와 같이 스토리지 전용으로 사용되는 버스들은 커널 2.6 개발 과정에서 메이저 업데이트가 있었다. IDE 서브 시스템에 대한 부분이 가장 중요 한데. 확장성에 대한 문제들을 여러가지 다른 제약점을 해결하기 위해 커널 2.6의 개발 과정에서 완전히 새로 작성되었다. 예를 들어 이제 CD/RW 드라이브들은 이전 버전에서와 같이 SCSI 에뮬레이션을 통해 동작하는게 아니고 직접 디바이스와 통신할 수 있도록 개선되었다. 그리고 150MB/sec의 속도를 갖는 시리얼 ATA(S-ATA)디바이스들에 대한 지원이 추가되었다. SCSI 측면에서는 넓은 지원 범위와 확장성을 위한 여러가지 개선사항이 추가되었다. SCSI-2 멀티패스(multi-path) 디바이스에 하나의 디바이스에 2LUN을 갖는 경우에 같이 예전 방식에 대한 대한 지원도 추가되었다. (SCSI-2는 1994년으로 거슬러 올라가는 SCSI 표준의 이전 표준이다) 그리고 이제 리눅스도 윈도우와 같이 미디어의 교환을 감지해낼 수 있도록 개선되어 완전히 표준을 따르지 않는 디바이스들과도 호환성을 유지할 수 있도록 했다. 이들 기술들이 시간이 흐름에 따라 안정화 되어가기 때문에 이들에 대한 리눅스의 지원도 안정화 되어가고 있다.

물론 그 자체로는 스토리지 버스가 아니지만 리눅스는 EDD(Enhanced Disk Device) BIOS를 직접 지원할 수 있게 되었다. EDD BIOS는 바이오스가 알고 있는 시스템에 연결된 모든 디바이스에 대한 정보를 가지고 있다. (IDE와 SCSI를 모두 포함하여) 게다가 설정사항과 기타 정보들만 가지고 오는 것이 아니라 몇가지 장점들을 더 제공한다. 예를 들어, 새 인터페이스는 리눅스가 부팅할 때 어느 디스크 디바이스를 이용했는지를 알아낼 수 있게 하는 등의 새로운 인터페이스를 제공한다. 리눅스 설치시 어느 부분에 리눅스 부트 로더를 설치할 것이지를 지능적으로 결정하게 해주는 등의 좀 더 지능적인 설치 프로그램을 작성할 수 있게해준다.

이런 변화 사항들 이외에도 모든 버스 디바이스 타입들이 리눅스의 새로운 디바이스 모델 서브 시스템으로 통합 되었다는 점이 중요하다. 어떤 경우에는 이런 통합이 좀 우스워 보일수도 있을 것이고, 또 다른 어떤 경우에는 좀 더 심각한 변화사항들이 있는 경우도 있을 것이다. (예를 들어 디바이스가 수정이 필요한지 등에 대한 감지를 하는 로직 자체도 변화될 필요가 있다)

파일 시스템
리눅스에서 블럭 디바이스 시스템을 사용하는 부분은 당연히 파일 시스템을 얹어서 쓰기 위해서이다. 리눅스 커널 2.4 이후로 많은 부분에서 광범위한 개선이 있었다. 그중 가장 중요한 점들은 확장 속성(extended attribute)의 지원과 POSIX 스타일의 억세스 콘트롤 방법이다.

일반적인 리눅스 시스템에서 ext2나 ext3 시스템을 사용한다. (ReiserFS가 세번째로 많이 쓰인다) 이들이 사용자들이 가장 많이 사용하는 시스템이기 때문에 개발 과정에서도 이들에 대한 개선 사항이 가장 많았다. 이들에 대한 가장 중요한 개선점은 확장속성(또는 메타데이타라고도 부른다)에 대한 지원이었다. 각각의 파일에 대한 속성들을 파일 시스템 내에 저장해 두는 것이다. 이들 속성 중 몇가지는 시스템이나 root 에 의해서만 읽고 쓸수 있도록 된다. 윈도우나 맥 OS와 같은 다른 운영체제들은 이미 이러한 기능을 사용하고 있다. 불행하게도 기존의 유닉스용 프로그램들은 이들 정보를 제대로 인식하거나 사용하지 못하는 경우가 많아 (tar등) 이들을 업데이트 해주지 않으면 안된다. 확장 속성이 이용된 가장 첫번째 분야는 POSIX 스타일의 억세스 콘트롤을 위한 부분이었다. 이것은 유닉스 스타일의 권한 체계보다 좀 더 확장되어 세밀한 권한 설정이 가능하도록 하는 시스템이다. ext3에 대한 이런 변화 말고도 몇가지 변화된 부분들이 있는데 저널링을 사용할 때 커밋(commit)시간을 전원 관리등을 설정해서 사용하는 노트북 유저들을 위해 튜닝될 수 있도록 수정되었다. 이 정보들은 파일 시스템 내에 저장되어 마운트 할 때마다 새로 지정해줄 필요가 없다. 그리고 디렉토리 내부의 파일 검색을 좀 더 빠르게 하기 위해 디렉토리가 인덱스 되었다는 표시를 해둘 수가 있다.

리눅스의 고전적 파일 시스템 이외에도 리눅스 커널은 XFS등과 같이 새로운 파일 시스템에 대한 지원도 포함한다. 이 파일 시스템은 Irix 시스템에서 기본으로 설정되는 XFS 파일 시스템에서 나온 것이고 블럭 레벨에서 호환성이 있다. ext3나 Reiser와 같이 루트 디스크에 쓰일 수 있고 확장 속성이나 ACL과 같은 새로운 기능들을 지원한다. 많은 배포본들이 리눅스 2.4 기반에 이 파일 시스템을 지원하기 시작했다. 하지만 어떤 파일 시스템이 최후의 승자가 될지는 아직 더 지켜봐야 할 것이다.

이외에도 리눅스는 파일 시스템 내부나 외부적으로 독점 운영체제와의 호환성을 개선시키기 위한 많은 개선사항이 있다. 우선 리눅스 2.6은 MS 윈도우의 논리 디스크 매니저(Logical Disk Manager)를 지원한다. 이것은 다이나믹 디스크라고 불리는 기능이다. 윈도우 2000이후 버전의 윈도우에서 파티션의 크기 조정을 자유롭게 하기 위해 새로 도입한 파티션 테이블 방식이다. (물론 리눅스 배포본에서 이 시스템을 사용할 것 같지는 않다) 리눅스 2.6은 또한 NTFS 파일 시스템에 대한 지원 부분을 완전히 재작성 하여 NTFS 볼륨에 대한 읽기 쓰기가 가능해졌다. (물론 쓰기에 대한 부분은 아직은 실험적이고 점진적으로 개선될 것이다.) 마지막으로 리눅스는 FAT12에 대한 지원 부분이 개선되어 몇몇 이 포맷을 사용하는 mp3 플레이어에 생기는 문제점들이 개선되었다. 확장속성 지원이 HPFS 파일 시스템에도 포함되었다. 이전 버전에서도 그랬지만 리눅스는 2.6에서도 다른 운영체제와 잘 섞여 사용할 수 있는 “스위스 군대 칼”과 같은 존재로서의 위상을 강화해 나가고 있다.

이들 변화 사항 말고도 리눅스 파일 시스템에 대한 많은 변화가 있었다. 할당량(Quota) 지원 부분이 좀 더 많은 사용자들을 지원하기 위해 재작성되었고, 각각의 디렉토리들이 동기적으로 동작할 수 있도록 개선되었다. (이것은 메일 시스템이나 디렉토리 기반의 데이타베이스 등의 시스템에 유용한데 디스크가 손상된 경우의 복구에 좋다) CD-ROM 등에 쓰이는 ISO9660 파일 시스템에서 투명한 압축이 지원되며 메모리 기반의 파일 시스템인 hugetlbfs가 새로 추가되어 공유 메모리 데이타베이스에 대한 지원이 강화되었다.

입출력 지원
대부분의 컴퓨터 시스템들은 외부와 연결될 때 그리 중요해 보이지 않는 입출력 장치로 연결된다. 이에는 마우스와 키보드, 사운드 카드, 비디오 카드, 조이스틱과 같은 디바이스들이 포함된다. 리눅스 2.6 개발 과정 중에 많은 기기들에 대한 지원이 추가되었지만 기본적인 디바이스들은 그 이전부터 이미 지원되어 왔고 이미 충분히 안정적이다. 외부 버스 지원과 Bluetooth 지원 등과 같은 부분의 개선 덕분에 디바이스들에 대한 지원이 확장되게 되었다. 많은 부분에서 큰 개선이 있었다.

HID(Human Interface Devices)
커널 2.6의 내부 변화중 가장 큰 것들 중 하나가 바로 휴먼 인터페이스 레이어가 재작성된 것이다. 휴먼 인터페이스 레이어는 리눅스 시스템에 대한 사용자들의 접점을 규정하는 가장 핵심이 되는 부분이다. 커널 새 버전에서는 이 레이어에 대해 이전 버전보다 더 큰 작업이 행해졌고 더 모듈화 되었다. 이제는 디스플레이와 같이 필수적이라고 생각했던 것들이 없어도 시스템 구성이 가능하다. 철저하게 모듈화 되어서 그렇다. 이런 모듈화의 가장 큰 장점은 임베디드 디바이스에 대한 개발이 손쉬워졌다는 것이다. 넣고 싶은 기기를 넣고 빼고 싶은 기기를 뺄 수 있으며 대신 네트웍이나 시리얼 포트를 통해서 제어한다던지 하는 일들이 가능해졌다. 하지만 사용자들의 측면에서는 다른 측면에서의 장점이 생긴다. 예를 들어 PC를 가지고 있다면 무조건 표준 AT(i8042)기반의 키보드가 있어야 한다던지 하는 기본 전제를 무시할 수 있게 된 것이다.

리눅스의 모니터 출력을 지원하는 부분에도 많은 변화가 있었다. 물론 커널 내부의 프레임버퍼 서브 시스템을 사용하는 경우에만 해당되는 경우가 대부분이지만. (인텔 기반의 리눅스 시스템들은 대부분 그렇지 못하다) 필자 개인적 의견으로는, 이 기능의 가장 좋은 점은 부팅 시에 귀여운 팽귄 로고가 24bpp의 해상도로도 지원될 수 있게 된 점이다. 그리고, 콘솔 자체도 리사이즈 되거나 회전할 수 있게 되었고(PDA등에서 유용할 것이다) 좀 더 많은 하드웨어를 지원한다. 마지막으로, 리눅스 커널에 VESA(Video Electronics Standard Association) 모니터들에 대해 그들의 기능에 대한 쿼리를 날릴 수 있다. 물론 이런 일들은 XFree86에서는 이미 하고 있던 일들이기는 하다.

이런 큰 변화점들 말고도 리눅스 2.6은 또한 사용자와 상호작용하는 측면에서 작은 변화들을 많이 포함하고 있다. 예를 들어, 터치 스크린이 이제 지원된다. 마우스와 키보드 드라이버들도 표준화 되어 동일한 디바이스 노드를 가지게 되었다.(예를 들어 마우스는 /dev/input/mouse0) 복잡한 마우스들(휠이 여러개라던가)도 이제 지원된다. PC 키보드 매핑에 대한 부분도 개선되어 표준 윈도우 키보드도 지원된다. XBox 게임패드등 조이스틱에 대한 지원도 많은 드라이버들이 나와주어서 상당히 개선되었다. 포스 피드백 지원도 포함되었다. 마지막으로, Tieman Voyager 브라이유(braille) 점자 TTY 디바이스에 대한 지원이 포함되었다. (이 기능은 리눅스 2.4에도 백포팅 되었을 정도로 중요한 기능이다)

한가지 덧붙이면, 리눅스에는 로컬 키보드를 갖지 않은 시스템을 위한 “시스템 리퀘스트(system request)”인터페이스에 작은 변화가 생겼다. 시스템 리퀘스트(sysrq) 인터페이스는 시스템 관리자가 콘솔에서 디버깅 정보를 얻고 시스템을 리부팅 하고 파일 시스템을 읽기 전용으로 마운트 해서 여러가지 일들을 할 수 있도록 만들어졌다. 리눅스 2.6에서 키보드 등이 없는 시스템을 지원하므로 이들 이벤트들을 /proc 파일 시스템을 통해 발생시키도록 할 수 있게 되었다. (물론 시스템이 멈추거나 한 경우에는 별 도움이 안되겠지만)

오디오 & 멀티미디어
리눅스 2.6으로 넘어오면서 사용자들이 가장 기다렸던 추가 기능 중 하나가 ALSA(Advanced Linux Sound Architecture)이다. 이전의 사운드 시스템인 OSS(Open Sound System)이 그동안 사용되어 왔지만 몇가지 구조적 제약사항들 때문에 대치되게 되었다. 첫번째 개선사항은 기반부터 철저하게 쓰레드와 SMP에 안전하도록 설계되었다는 점이다. 이전에는 데스크탑은 무조건 CPU를 하나만 갖는다는 가정 하에 동작하도록 되어 있었다. 더욱 중요한 점은 대단히 모듈화 되어 새로운 사운드 카드의 지원도 손쉬워 졌다는 점이다. 물론, 내부가 아름다와 졌다고 해도 외부에 보이는 기능 개선이 없다면 사용자 측면에서는 별 의미가 없을 것이다. 새로운 사운드 시스템은 상당히 많은 강력한 기능들을 가지고 있다. 가장 큰 기능들을 꼽아보면 새로운 사운드 디바이스(USB오디오나 MIDI디바이스)들에 대한 지원, 전이중(full-duplex) 재생과 녹음 기능, 하드웨어 믹싱, 사운드 디바이스들의 통합 작동 등등이다. 오디오 기능에 대한 매니아이건 MP3만 듣는 정도의 사용자이건 무척 환영할 만한 기능들이다.

간단한 오디오 재생뿐 아니라 근래의 사용자들이 원하는 기능들은 상당히 다양하다. 웹캠, 라디오 또는 TV 어댑터, 디지탈 비디오 레코더 등도 포함된다. 이 세가지 경우에 대해 리눅스 2.6에서의 지원이 개선되었다. 리눅스에서 이전에도 이미 라디오 카드나 TV 튜너, 비디오 카메라 등을 지원해왔으나 극히 최근의 일이다. Video4Linux(V4L)이라고 불리는 이 시스템에 많은 개선사항이 추가되어 최신버전에서는 API의 정리작업이 수행되었고 좀 더 많은 기능들이 추가되었다. 새로운 API는 이전 버전의 API와 호환되지 않아 이전 버전의 API를 사용하는 응용 프로그램은 새로 업그레이드 해야 한다. 또다른 특기사항을 리눅스 2.6에서는 디지탈 비디오 방송(DVB) 하드웨어에 대한 지원을 포함한다. 셋탑 박스 등에서 사용하는 이런 하드웨어는 리눅스 시스템을 Tivo와 같은 디바이스로 변신시킬 수 있는 기능을 제공한다.

소프트웨어 개선사항들
네트워킹
항상 최신의 네트워킹 지원이 리눅스의 가장 중요한 인기 포인트 중 하나였다. 리눅스는 이미 TCP/IP(v4 & v6), Apple Talk, IPX등과 같이 가장 인기있는 네트웍 프로토콜들을 지원한다. (지원하지 않는 것들 중에는 NetBEUI같은것도 있기는 하다) 다른 서브 시스템들의 변화와 마찬가지로 네트웍 하드웨어에 대한 변화들은 지극히 내부의 일이고 겉에서는 잘 알아차리기 힘들다. 하부 구조들은 디바이스 모델과 디바이스 드라이버들이 새로이 업데이트 된데에서 많은 장점을 얻었다. 예를 들어, 리눅스는 현재 여러 네트웍 디바이스 드라이버들이 사용하던 MII(Media Independent Interface 또는 IEEE802.3u) 서브 시스템을 가지게 되었다. 이 새로운 서브 시스템은 각각의 디바이스들이 조금씩 다르게 다루던 부분들을 모두 수정하게 된다. 다른 변화들은 ISDN 업데이트와 같은 것들이 있다.

소프트웨어 측면에서 가장 큰 변화중 하나는 IPsec 프로토콜의 지원이다. IPsec 또는 IP Security라는 프로토콜은 IPv4와 IPv6에서 네트웍 프로토콜 레벨에서 암호화 보안을 사용 가능하게 해주는 프로토콜의 집합이다. 보안 기능이 프로토콜 레벨에 들어가기 때문에 응용 프로그램들에서는 이것들을 의식해서 새로 작성하거나 할 필요가 없다. 이것은 SSL이나 터널링/보안 프로토콜과 동일한 개념이지만 그보다 좀 더 저수준이다. 현재 커널에서 지원하는 암호화는 SHA(Secure Hash Algorithm)나 DES(Data Encryption Standard)등을 포함한다.

프로토콜의 다른 부분에서는 리눅스는 멀티 캐스트 네트워킹에 대한 지원이 강화되었다. 멀티캐스트 네트웍은 한개의 패킷을 보내면 여러 대의 컴퓨터에서 그 패킷을 받게 되어 있는 네트웍이다. (기존의 포인트-투-포인트 방식의 네트웍과 비교해 생각해보라) 이는 Tibco와 같은 메시징 시스템이나 오디오/비디오 컨퍼런스 소프트웨어에 사용된다. 리눅스 2.6은 MLDv2(Multicast Listener Discovery)와 IGMP3(Internet Group Messaging Protocol)과 같은 몇가지의 SSM(Source Specific Multicast) 프로토콜들을 지원한다. 이들은 Cisco와 같은 하드웨어 네트워킹 벤더들에 의해 지원되는 표준 프로토콜 들이다.

리눅스 2.6은 또한 LLC 스택을 분리구현했다. LLC는 Logical Link Control 프로토콜(IEEE 802.2)인데 NETBeUI나 IPX, Appletalk과 같은 몇몇 일반적인 고수준의 네트웍 프로토콜의 기반을 이루는 저수준 프로토콜이다. 변화의 일부로는 IPX, Appletalk, 토큰 링 드라이버들이 새 서브시스템의 이득을 보기 위해 새로이 작성되었다. 외부 프로젝트로 NetBEUI 프로토콜 스택을 작성하는 프로젝트가 진행되고 있는데 이것이 커널 내부로 병합될지는 두고 봐야 할 것이다.

이것들 이외에도 작은 변화들이 상당히 많다. IPv6에 많은 변화들이 가해졌고 토큰 링 네트워크에서도 동작하게 되었다. 리눅스의 NAT/masquerading 지원은 다중 접속을 필요로 하는 프로토콜들(H.323, PPTP등)에 대해서도 잘 지원하도록 수정되었다. 리눅스에서 VLAN을 설치하는 것은 이제는 더 이상 “실험적”이라고 할 수 없다.

네트웍 파일 시스템
리눅스의 유연한 네트웍 프로토콜 지원의 상단에는 역시나 유연한 네트웍 파일 시스템 지원이 존재한다. 네트웍 파일 시스템을 노출(export)하고 마운팅하는 것은 커널이 직접 관리하는 고수준의 네트웍 동작이다. (역시 비슷하게 응용 프로그램에서 파일처럼 사용하게 되는 네트웍 블록 디바이스들은 2.6에서 그리 큰 변화가 있지 않았다) 그외의 네트웍 동작들은 대부분 사용자 스페이스로 밀려갔고 커널 개발자들의 영역에서 다소 멀어졌다.

리눅스와 유닉스 호환 운영체제의 세계에서 가장 중요한 네트웍 파일 시스템은 NFS(Network File System)이다. NFS는 매우 복잡한 파일 공유 프로토콜이며 유닉스에 깊은 뿌리를 박고 있는 파일 시스템이다 (특히나 썬의 솔라리스에서의 구현은 더 그렇다) NFS는 TCP나 UDP등을 사용할 수 있지만 몇가지 별도의 RPC(Remote Procedure Call)를 기반으로 동작하는 서브 프로토콜들도 필요로 한다. 이것들은 인증을 위한 “mount” 프로토콜과 파일 록킹을 위한 NLM(Network Lock Manager)등을 포함한다. (일반적인 구현 버전들은 대부분 또다른 RPC 기반의 프로토콜인 NIS에 인증등의 기능을 의지한다. NIS와 그 비슷한 것들은 보안상 그리 안정적이지는 않기 때문에 리눅스 머신에서는 일반적으로 많이 쓰이지는 않는다) NFS가 널리 쓰이는 인터넷 프로토콜의 위치를 차지하지 못한 것은 그 복잡함 때문일 것이다.

리눅스 2.6에서는 NFS는 많은 개선이 있었다. 가장 큰 개선이라면 서버나 클라이언트에 새로운 NFSv4 프로토콜을 실험적으로 지원한다는 것이다. (이전 버전의 리눅스에서는 v2나 v3만 지원했었다) 새 버전은 좀 더 강력하고 안전한 암호에 기반한 인증을 지원하며 좀 더 지능적인 록킹(locking)과 가짜 파일 시스템(pseudo-filesystem)을 지원한다. NFSv4의 모든 기능이 아직 구현되지는 않았지만 지원 자체가 제법 안정적이어서 중요한 서버에서도 사용될 수 있을 만큼의 안정성을 보인다. 추가적으로 리눅스의 NFS서버 구현은 좀 더 확장성 있게 설계되었다 (64배 더 많은 동시 사용자와 더 큰 요청 큐를 가진다). 그리고 좀 더 완전하고(TCP와 UDP상에서 동작), 좀 더 유연하며, 좀 더 쉽게 유지보수가 가능하다. (시스템 콜이 아닌 nfsd 파일 시스템을 통해서 가능하다) 별도로 분리된 lockd와 nfsd, 지원되는 인터페이스에 대한 zero-copy 네트워킹 등의 숨겨진 변화들도 많다. NFS는 시스템 관리자가 커널의 lockd 포트 번호를 할당할 수 있도록 하여 비교적 손쉽게 보안을 강화할 수 있도록 하였다. NFS 클라이언트 사이드는 또한 캐쉬 구조와 UDP를 통한 연결 콘트롤, 기타 TCP에 가해진 개선사항등 하부의 RPC 프로토콜에서 이득을 본다. 리눅스에서 NFS 볼륨을 루트 파일 시스템으로 사용하는 것은 (디스크 없는 시스템과 같이) TCP 상의 NFS가 지원되도록 개선되어 가능하도록 되었다.

이와 같은 유닉스 스타일의 네트웍 파일 시스템 이외에도 리눅스 2.6에서는 윈도우 스타일의 네트웍 파일 시스템에 대해서도 많은 개선이 있었다. 윈도우 서버군에서 표준으로 사용하는 공유 파일 시스템인 SMB 프로토콜에 대한 지원이 더 강화되었다. 물론 윈도우 2000에서는 SMB 프로토콜보다 좀 더 개선된 버전인 CIFS(Common Internet Filesystem)이라는 것이 표준화 되었다. 이 업그레이드는 프로토콜 자체가 특정 시점에 엉망이 되는 것을 막고 좀 더 잘 동작하도록 하는데 목표가 있다. (프로토콜 자체가 많이 개량되어 결국 어떤 시점에서부터 윈도우 NT나 윈도우 2000과 윈도우 95/98/ME와 호환이 되지 않게 되었다) CIFS는 그 목적 이외에도 유니코드 지원, 파일 록킹 기능 개선, 하드 링크, NetBIOS에 대한 의존성 제거, 그리고 윈도우 사용자들을 위한 몇몇 기능 개선이 추가되었다. 그래서 한동안 리눅스 사용자들은 CIFS와 제대로 공유할 수 없었으나 리눅스 2.6부터는 CIFS에 대한 지원이 완전히 재 작성되어 완벽하게 호환이 된다. 리눅스 2.6에는 SMB와 CIFS 프로토콜의 확장인 SMB-UNIX 익스텐션에 대한 지원이 추가되어 Samba와 같은 SMB서버에 윈도우 파일 타입이 아닌 파일 타입(디바이스 노드나 심볼릭 링크 등)을 지원할 수 있게 되었다. 근래에는 드물게 리눅스는 노벨 넷웨어에 대한 지원도 빼먹지 않았다. 리눅스 2.6에서는 내장된 NCP(Netware Core Protocol) 파일 시스템 드라이버를 통해 256개 까지의 공유를 마운트 할 수 있다.

리눅스 2.6은 하나의 로지컬 볼륨에 존재하는 파일들이 여러개의 노드들에 분산되어 있을 수 있는 비교적 새로운 종류의 분산 네트워크 파일 시스템을 지원한다. 리눅스 2.4에서 지원이 시작된 CODA 파일 시스템 이외에도 AFS와 InterMezzo에 대한 지원이 추가되었다. AFS는 Andrew Filesystem(CMU에서 개발되어 이름이 저렇다)은 아직은 매우 제한적이고 읽기 전용으로 밖에 동작하지 않는다. 두번째 새로 지원되는 파일 시스템인 InterMezzo(역시 CMU에서 개발되었다)는 리눅스 2.6에서 지원되기 시작했는데 비접속 기능(로컬에서 동작하도록 하는)과 같은 높은 수준의 기능들의 동작이 가능하며 반드시 디스크의 공간이 존재해야만 하는 종류들의 응용 프로그램에 사용될 수 있다. 물론 여러대의 시스템, 노트북이나 PDA 또는 데스크탑 컴퓨터 등에서 서로의 파일 내용을 싱크할 수 있는 기능도 내장되어 있다. 새로운 파일 시스템을 지원하기 위한 프로젝트들이 존재한다.

기타 기능들
보안
리눅스 2.6에서 새로 부각된 부분이지만 주목을 많이 못받고 있는 분야가 보안 관련 분야이다. 가장 기본적으로 근래에는 커널 기반의 보안(유닉스에서의 root 사용자의 권한) 자체도 모듈화 되어서 여러가지 보안 모델 중 하나가 되어 버렸다. (어쨌거나 현재까지 기본적으로 제공되는 모델이고 새로운 모델에 대해서는 어떻게 만들 수 있는지 보여주는 것에 불과하다) 이런 변화중 하나로 커널의 모든 부분이 대단히 세부적인 억세스 콘트롤 기반을 기초로 사용하도록 수정되었다. 물론 대부분의 리눅스 시스템들은 이러한 root 기반의 보안 모델을 계속 사용하겠지만 이런 기본적인 부분들이 없이도 시스템이 구성될 수 있다. 또 다른 보안 관련 변화 중 하나는 바이너리 모듈(하드웨어 개발 업체에서 제공하는 드라이버와 같은)들이 더 이상 시스템의 시스템 콜 테이블을 수정하여 시스템 콜을 오버로딩할 수 없도록 수정되었다는 점이다. 이것은 오픈 소스가 아닌 모듈들이 커널이나 기타 GPL 기반의 소프트웨어에 보안상의 헛점을 만드는 것을 더 이상 용납하지 않는다는 점에서 보안이 한층 강화됨을 뜻한다. 또 하나의 보안 관련 변화 사항은 리눅스 커널이 이전에 사용되던 하드웨어 변동에 기반한 엔트로피 풀 방식의 랜덤 넘버 제네레이터 대신 하드웨어 랜덤 넘버 제네레이터를 사용할 수 있게 되었다는 것이다. (몇몇 프로세서에 내장되기 시작했다)

리눅스의 가상화
리눅스 2.6의 가장 재미있는 새 기능중 하나는 유저 모드(user-mode) 아키텍쳐를 채용하기 시작했다는 것이다. 이것은 리눅스를 리눅스 자체로 포팅해서 리눅스 상에서 리눅스가 실행된다는 의미이다. 리눅스의 새 인스턴스는 완전히 보통의 응용 프로그램인 것 처럼 실행되게 된다. 응용 프로그램 내부에서 가짜 네트웍 인터페이스나 파일 시스템, 호스트의 디바이스와 통신하도록 만들어진 특수한 디바이스 드라이버를 통해 디바이스를 지원할 수 있게 된다. 이것은 (profiling등) 개발을 위해서나 보안 분석을 위해서 대단히 바람직한 것으로 밝혀졌다. 물론 상당수의 사용자들은 이런 기능을 필요로 하지 않겠지만 대단히 멋진 기능임에 틀림이 없다. (친구들을 감동시켜 보라!)

랩탑 지원
앞서 이야기 한 일반적인 지원들(APM, ACPI, 무선 네트웍 지원등) 이외에도 리눅스는 랩탑 사용자들을 위해 두가지의 분류하기 어렵지만 유용한 새로운 기능들을 제공한다. 첫번째는 소프트웨어 서스펜드 기능 기능(software-suspend-to-disk)이다. 아직은 약간의 버그가 남아 있지만 많은 경우 별다른 문제 없이 사용이 가능한 수준이다. 또 하나의 기능은 시스템 전원이 연결 되어 있는지 여부에 따라 프로세서의 속도를 자동으로 바꾸어 주는 기능이다.

설정 관리(Configuration Management)
리눅스 2.6은 몇몇 작은 기능 개선을 가지고 있다. 주로 개발자들이 커널의 문제에 대해 디버깅을 할 때 큰 도움을 받을 기능이지만 여러대의 서버를 관리해야 하는 관리자들을 위해서도 유용한 기능이다. 간단하게 이야기 해서 커널에 커널 파일 자체의 설정 파일을 내장시킬 수 있다. 여기에는 커널 설정의 각종 옵션들에 대한 정보들이 함께 기록되며, 어떤 컴파일러가 사용되었는지와 기타 동일한 커널을 컴파일 하기 위해 필요한 여러 환경들을 담고 있다. 이 정보들은 /proc 인터페이스를 통해 살펴볼 수 있다.

기존 응용 프로그램 지원
리눅스 커널 2.6이 메이저 업그레이드이긴 하나 사용자 응용 프로그램에서 변화시켜야 할 부분의 거의 없는 것이나 마찬가지이다. 하나의 예외는 쓰레딩에 대한 부분이다. 어떤 응용 프로그램들은 2.4나 2.2에서는 허용되었으나 그 이후에는 허용되지 않는 작업을 하는 경우가 있을 수 있다. 이것들은 어쨌거나 예외적으로 취급해야 한다. 물론 모듈 유틸리티와 같은 저수준에서 동작하는 프로그램들도 동작하지 않을 것이다. 추가적으로, /proc과 /dev에 존재하는 몇몇 파일들과 그 형식이 변화되어 여기에 의존적으로 작성된 응용 프로그램들은 제대로 동작하지 않을 가능성이 있다. (새로운 /sys 버추얼 파일 시스템으로 많은 부분들이 옮겨져서 그렇기도 하다. 호환성을 위해서 /dev 디바이스 이름들도 쉽게 설정할 수 있기는 하다)

이런 것들에 추가적으로 많은 부분이 변경되었다. 첫번째로 리눅스 2.0 이나 그 이전에 만들어진 스왑 파일들은 새로 포맷을 해야 한다. (스왑 파일에는 별다른 중요한 내용이 저장되지는 않기 때문에 대부분의 경우 문제가 되지는 않을 것이다) 아파치나 Zeus등의 웹서버들이 커널 수준의 속도에 접근 할 수 없도록 막는 병목이 제거 되었으므로 커널이 웹 페이지를 직접 서비스 할 수 있는 kHTTPd 데몬이 제거 되었다. Dos/윈도우에서 대용량 하드디스크의 사용을 위한 OnTrack이나 EzDrive등의 디스크 매니저에 대한 자동 감지 기능이 제거 되었다. 마지막으로 플로피 디스크에서 부팅을 하기 위한 특수한 형태의 커널 부트 섹터가 제거되었다. 이제는 SysLinux를 사용해야 한다.

마치며
이 문서는 BitKeeper의 changelog와 소스 여기 저기를 뒤져보고 메일링 리스트의 내용들을 검토하고 Google과 Lycos의 검색 결과를 이리저리 뒤져보아서 작성한 문서이다. 그래서 혹시 잘못된 내용이 포함되어 있거나 중요한 내용이 빠져있거나 필자가 오해하고 있는 부분이 있을 수 있다. 혹시라도 잘못된 내용을 찾게 된다면 필자의 이메일인 jpranevich at kniggit.net 으로 메일을 보내어 수정해주기 바란다.

이 문서의 새 버전은 항상 http://kniggit.net/wwol26.html 에 올려놓고 있다.

번역
이 문서는 영어 이외에도 아래와 같이 여러가지 언어로 번역되어 있다.

불가리어 - http://kniggit.net/wwol26bg.html (Ivan Dimov)
중국어 - http://www-900.ibm.com/developerWorks/cn/linux/kernel/l-kernel26/index.shtml (Stone Wang, et. al.)
체코어 - http://www.linuxzone.cz/index.phtml?ids=10&idc=782 (David Haring)
프랑스어 - http://dsoulayrol.free.fr/articles/wonderful_2.6.html (David Soulayrol)
헝가리어 - http://free.srv.hu/b/e/behun/pn/modules.php?op=modload&name=News&file=index&catid=&topic=12 (Ervin Novak) (아직 미완성.)
이탈리아어 - http://www.opensp.org/tutorial/vedi.php?appartenenza=42&pagine=1 (Giulio Ciuffi Vampa)
포르투갈어 (BR) - http://geocities.yahoo.com.br/cesarakg/wwol26-ptBR.html (Cesar A. K. Grossmann)
러시아어 - http://www.opennet.ru/base/sys/linux26_intro.txt.html (Sergey Prokopenko)
스페인어 - http://www.escomposlinux.org/wwol26/wwol26.html (Alex Fernandez)
독일어로 작성된 요약본이 2003년 9월자 LanLine 잡지에 실렸다. 어딘가 요약본이 아닌 문서가 돌아다니고 있는것 같지만 정확한 링크를 잘 모르겠다. 다른 언어로 작성된 번역본이 있다면 필자에게 알려주기 바란다.

——————————————————————————–

This document is Copyright 2003 by Joseph Pranevich. Redistribution online without modification is permitted. Offline distribution (in whole or in part) is also encouraged, but please email me first to discuss the details. Translations are also encouraged; please email me though so that I can help coordinate.

——————————————————————————–

Copyright 2004 by Nate Park

——————————————————————————–
이 문서를 복제 수정 배포하는 것은 자유입니다. 원저자와 번역자에 대한 언급만 있다면 말이지요.

Comment +0

티스토리 툴바