머피의 법칙
안윤호 (아마추어 커널 해커) 2005/09/06
필 자는 머리가 아플 때면 아더 블로크의 『머피의 법칙』이라는 책을 보곤 한다. 요즘같이 더울 때 책이나 코드와 눈싸움을 벌이다보면 머리가 더 아파지곤 한다. 이 책을 처음 본지는 10여년이 지났다. 책에 빠져들어 머리를 식히고 있노라면 종종 세상은 ‘머피의 법칙’에 지배된다는 생각이 들곤 한다. 물론 이 법칙은 수식으로 입증된 것이 아니기 때문에 종교적인 교리와 마찬가지로 인정하는 사람과 인정하지 않는 사람으로 구별된다. 그것은 믿음체계에 대한 문제이다. 그러나 적어도 필자의 머릿속에서 ‘머피의 법칙’은 ‘무어의 법칙’이나 ‘멧카프의 법칙’처럼 잘 들어맞는 법칙이다. 무어와 멧카프의 법칙도 수식으로 입증된 법칙이 아니라 경험적인 추정이다. 주관적이고 심리학적인 세상에서 ‘머피의 법칙’은 잘 들어맞는다. ‘머피의 법칙’의 눈높이는 사람들의 눈높이다.
잘못될 가능성이 있는 것은 잘못된다
필자는 개발과정에서 일이 잘 풀리기 보다는 잘 안되는 경우가 더 많았고 몇 번의 시도 끝에 한두 번 정도 간신히 시험구현하고 다시 여러 번의 예외발생을 일으킨 후 디버깅 끝에 일을 마치게 된다. 그 때마다 머피의 법칙을 떠올리곤 했다. 전자기계의 프로토타입을 만들던 예전보다는 많이 편해진 편이었다. 전선 하나의 디버깅에 하루를 보내지 않아도 되었다. 수십 개의 TTL은 하나의 칩으로 변했고 잡다한 배선은 데이터와 컨트롤 버스로 변했다. 시스템의 복잡성은 증가했지만 칩으로 들어간 시스템은 그럭저럭 동작했다. 에러는 계속 존재했다. 별 문제가 없다고 계속 사용하던 드라이버의 버그 패치가 몇 번이나 있었던 것을 나중에 알게 되는 경우도 있었다.
시스템도 사용자도 프로그래머도 둔하기는 마찬가지였다는 것을 알게 된다. 만약 중요한 시스템에서의 문제였다면 하는 걱정도 잠시 들기는 하지만 곧 잊어버리곤 했다. 잘못될 소지가 있었던 것이지만 위험이 깔려 있는 길거리를 무사히 걸어 다녔던 것처럼 운이 좋았다고 할 수 있다.
사람들은 일이 잘 안되는 많은 이유가 머피의 법칙 때문이라고 한다. 필자 역시 어느 날인가부터 머피의 법칙을 믿게 되었다. 실험실에서 며칠 동안 만든 회로와 소프트웨어는 아무런 문제가 없어 보이다가 적용의 순간 연기를 내거나 에뮬레이터 상에서는 개별적으로는 문제가 없어도 조합하면 다운이 되는 신비로운 에러들이 있었다. 머피의 법칙이 적용되기 시작한 것이다. 법칙은 소프트웨어 시연회에서도 적용되었다.
우리가 머피의 법칙으로 알고 있는 것은 보통 첫 번째 법칙이다. 사람들은 머피의 법칙들에 얼마나 많은 발전형과 확장형, 그리고 예외가 있는지 잘 모른다. 머피의 법칙은 상당히 복잡하게 얽혀 있다. ‘머피학’이라는 첫 장의 첫 법칙은 “잘못될 가능성이 있는 것은 잘못된다”로 시작하는 진짜 머피의 법칙이다. 그 밑에는 발전형들이 등장한다. “무슨 일이든지 생각한 것보다는 시간이 더 걸린다”, “몇 가지 잘못될 가능성이 있을 때는 위험성이 가장 큰 것이 보통 잘못될 가능성이 가장 크다”, “절대로 안전한 것은 만들 수가 없다. 왜냐하면 생각지도 못한 것들을 어리석은 자는 생각해 내기 때문이다”, 그리고 다시 확장과 예외들이 나온다(머피의 법칙은 1940년대 에드워드 공군기지에 잠시 머물렀던 엔지니어 머피가 잘못될 가능성이 있는 것은 잘못된다는 한 마디를 하면서 시작되었고 비슷한 경험적인 법칙들이 추가되었다).
법칙들의 충돌
머피의 법칙에 따르면 일들은 잘못되기 마련이다. 일들은 의도하지 않던 이상한 방향으로 튀어나가게 되어 있다. 기계건 소프트웨어건 조직이건 마찬가지이다. 그래서 ‘머피의 법칙’이라는 책에는 응용 머피학과 고등 머피학, 머피 경제학, 엔지니어링과 디자인 등에 대한 세부 항목이 있다. 때로는 법칙들마저 서로 충돌한다. ‘머피학’에는 ‘소드의 법칙’이라는 것이 있는데 이 법칙은 “무슨 일인가를 해보려고 하면 무엇이건(생물이건 무생물이건) 뜻하지 않은 것이 개입하여 훼방을 놓는다. 그럼에도 불구하고 때로 무슨 일이 이루어지는 것은 훼방을 놓으려는 그 무엇인가도 또 다른 무엇에게서 간섭을 받기 때문이다”라고 한다.
어쩌면 그럴지도 모른다. 일을 진행하는 것은 이러한 간섭 사이에서 일을 만들어 나가는 것이다. 그래서 잘 안될 것 같은 일들이 가끔씩 이루어지기도 한다. 일들이 초기에 많은 시간과 시행착오를 거치면서 간신히 자리를 잡아나가는 것은, 일을 하다 보니 머피의 법칙에 약간의 공백이 생기기 때문일 것이다(킬러앱스들이 빠르게 자리를 잡는 일은 일종의 예외이다). 그래서 흔히 말하는 ‘삽질’이라는 것을 하다보면 머피의 수많은 법칙들을 우회하는 경우가 생기는 것이다. 머피의 법칙 신봉자의 입장에서 보면 그렇다.
애초에 생각했던 아이디어들이 구현되며 예측하지 못한 일들에 의해 방해받을 때면 사람들은 종종 머피의 법칙을 떠올린다. 현실은 복잡한 것이다. 때로는 머피의 법칙이 적용될 것을 어느 정도 미리 고려하는 일이 더 현실적 예측이다. 소프트웨어 엔지니어링에 관한 책들이나 유명한 프로그래머들의 일화들에서 “실패로부터 배워라” 또는 “오류로부터 배워라”는 경구는 오류와 예측하지 못한 일들이 항상 우리와 함께 한다는 사실을 알려준다. 아울러 현실적이고 실용적인 엔지니어링의 범위와 철학을 정한다. 머피의 법칙을 인정하고 믿으면 터무니없는 일들이 일어나더라도 놀라지 않는다. 그것은 일종의 법칙이기 때문이다. 복잡하게 꼬인 일들은 머피의 법칙이 개입될 가능성이 그 만큼 많다.
가끔씩 필자는 이 책을 혼자서 보기에는 아깝다는 생각을 하곤 했다. 특히 공학에 종사하는 사람들에게는 많은 생각거리를 제공한다는 점에서 그랬다. 같이 일하는 프로그래머들에게는 『머피의 법칙』을 사서 나누어 준 적도 있었다. 문제가 생기면 머피의 코드로 이야기하는 편이 토론이 쉬웠던 적도 있다.
법칙들
책에 나오는 어떤 법칙들은 상당히 인상적이다. 예를 들어 잘못되는 것들은 잘못된다는 ‘머피학’ 쪽의 법칙들이 그렇다. 독자들이 경험한 법칙인지도 모른다:
- 스코트의 제1법칙 : 아무리 잘못된 것도 옳게 보이는 수가 있다.
- 스코트의 제2법칙 : 잘못되었다고 해서 고치고 나면 본래의 것이 옳았다는 것을 깨닫게 된다. [발전형] 고친 것이 잘못되었다는 것을 발견하더라도 본래대로 되돌릴 수는 없다.
- 머피의 법칙의 확장 : 계속되며 무엇인가가 잘못될 때에는 최악의 과정을 밟아가며 잘못되어 간다. [가투소의 확장] 너무나 최악이라고 해서 더 이상 나빠질 수 없는 일이란 없다.
- 보르고프스키의 법칙 : 우연에 대한 대책은 없다.
- 힉돈의 법칙 : 뛰어난 판단력은 쓰라린 경험에서 생긴다. 그리고 그 경험은 형편없는 판단력에서 생긴다.
- 아리스토텔레스의 금언 : 사람들은 불가능해 보이는 가능성보다 가능해 보이는 불가능성을 더 선호한다.
디즈레일리는 “잘못은 흔히 성공보다 더 성실할 때가 있다”라는 격언을 남겼다. 일이 잘못되는 경우 문제의 원인에 대해서는 간과하며 결과에 집착하는 경우가 있다. 결국 잘못되는 원인이 있는 것인데 그 원인을 발견하려는 강력한 동기를 제공하는 시작은 실패와 에러에서 나올 것이다. 물리학자 닐스보어는 “전문가라는 것은 온갖 실패를 경험해 본 사람이다”라는 말을 한 적도 있다. 결국 오류와 실패는 항상 일어나며(그것은 법칙이다. 잘못되는 것들은 잘못된다!) 겁내거나 피해야 하는 일은 아니라는 것이 머피의 중요한 결론인지도 모른다. 어떤 법칙들은 사람들이 이해의 문제와 익숙한 사실에 고착하려는 경향에 대한 비평들이다:
- 부커의 법칙 : 실용 1근은 이론 1톤의 가치가 있다.
- 스미스의 법칙 : 핵심문제는 해결할 수 없다.
- 거짓말 법칙 : 어느 시대에나 명백한 거짓말을 믿는 사람이 있다.
- 바러크의 고찰 : 망치를 든 사람에게는 모든 것이 못으로 보인다.
- 루드니키의 원리 : 완전하게 이해한 사람만이 설명할 수 있다, 따라서 다른 누구도 그것을 이해할 수 없다.
컴퓨터의 세계에서도 사물에 대한 이해는 고착된다. 패러다임 고착과 교조화에 대해서도 생각해 볼 여지가 많다. 망치를 든 사람에게 모든 것이 못으로 보이는 것처럼 특정한 프로그래밍 패턴에 고착되거나 도를 넘어서는 주장에 대해서까지 따라다니는 현상에 대해서도 생각해 볼 여지가 많다. 때로는 그 근거가 제대로 된 이해와 초기의 디자인 목표에 대한 검토가 없이 맹목적인 경우도 있다. 일에 쫓기고 유행을 따르다보면 이상한 패러다임에 ‘올인’하게 되는 경우도 있을 수 있다. 이 경우에는 잘못될 가능성이 높은 것이다. 머피의 법칙 중에는 컴퓨터와 엔지니어링에 관한 내용도 있다:
- 신뢰성 결여의 법칙 : 오류는 인간의 본질, 실제로 일을 망치는 것은 컴퓨터
- 레이의 정밀도의 규칙 : 마이크로미터로 측정하여, 분필로 표시하고, 도끼로 자른다.
- 수리의 법칙 : 고장나지 않은 것은 수리할 수 없다.
- 랩의 무생물 생식의 원칙 : 조립과 반복을 여러 번 반복하면 마침내 두 개가 된다.
- 와인버그의 제1법칙 : 프로그래머가 프로그램을 작성하듯이 건축가가 건물을 짓는다면 맨 처음 날아온 딱따구리에 의해 문명은 붕괴될 것이다.
- 루바르스키의 사이버네틱스 곤충학법칙 : 버그는 늘 한 마리가 더 있다.
- 스타인벡의 시스템 프로그래머를 위한 지침 : 대응 방법을 모르는 에러는 테스트해서는 안된다.
- 길브의 신뢰성 결여의 법칙 :
1. 컴퓨터도 신뢰할 수 없지만 인간은 더욱 신뢰할 수 없다.
2. 인간의 신뢰성에 의존하는 시스템은 신뢰할 수 없다.
3. 발견되지 않은 에러는 무한하다. 그러나 발견 가능한 에러는 찾아낼 수 있으므로 당연히 유한하다.
4. 신뢰성을 높이는 투자는 투자액이 수정비용을 초과하거나 누군가가 “좀더 나은 일을 해야 한다”고 역설할 때까지 계속 늘어난다.
- 매뉴베이의 제2법칙 : 사람들은 실제로 무엇이 필요한지는 몰라도 무엇이 필요하지 않은 지는 확실히 알고 있다.
머리를 짜내어 만든 기발한 아이디어들, 새로운 개념을 도입한 급진적 디자인들, 새롭고 혁신적이라고 주장하는 소프트웨어들, 그리고 중요하다고 하는 도구들이 널려 있지만 이들 중 대다수는 살아남지 못한다. 설익고 다듬어지지 않은 제품들도 마찬가지다. 단순 간단하며 구현이 쉬운 아이디어들이 생존성이 높다. 초기의 이상이 아무리 우수한 것이라도 구현이 잘못되면 개념은 자리를 잡지 못한다. 우연과 행운 그리고 사람들의 수용가능성을 통과해야 아이디어는 현실로 자리를 잡는다. 모든 사물은 잘못될 가능성이 있고 여러 가지 머피의 법칙들을 통해 검증된다.
만약 머피의 법칙이 없다면 비현실적으로 복잡한 다이어그램으로 이루어진 소프트웨어들이 스스로 붕괴되지도 않고 수도 없이 많아져 소프트웨어의 제작자와 사용자를 괴롭힐 것이지만 복잡한 물건들은 스스로 망가지거나 사용자들이 정이 떨어져 버리기 때문에 널리 퍼지지 못한다. 너무 정교한 프로토콜들로 이루어진 시스템 역시 살아남기 힘들다. 배우기가 어렵고 귀찮기 때문이다. 참으로 다행한 일이다. 인기가 없어져 불필요하게 다른 사람들을 괴롭히지 않아도 될 것이다. 컴퓨터 업계에는 오류투성이인 사람들에 의해 머피의 법칙이 적용된다. 그러니까 모두 다 중요한 것은 아니다. 스터전의 법칙(세상의 90%는 쓰레기)처럼 무시해도 되는 일이 많은 것이다.
필자는 네트워크나 운영체제론에 그리고 소프트웨어 개발론에 대한 머피의 법칙들이 더 나올 것으로 생각한다.
다른 엔지니어링이나 현실의 체계들처럼 IT 업계도 완숙한 단계를 향해 나아가는 중이다. 초기와 같은 기적이나 폭발적인 성장은 점차 줄어들게 되고 복잡하며 층층시하의 레이어를 갖는 엔지니어링과 복잡한 개발 단계가 기다리고 있다. 새롭다거나 재미는 없지만 일들은 무한히 복잡해진다. 그러나 이들도 머피의 법칙을 통과해야 한다. 재미가 줄고 있다는 것이 가장 큰 문제이긴 하지만 정보산업은 중요한 인프라가 되었다. 완숙한 업계는 변화와 재미가 없어진다. 야심적이지만 완숙하지 않은 개발자들의 생태계가 점차 국한된다는 사실이다. 이들에게는 규격화되고 조직의 일부로 기능해야 하는 역할이 점차 재미가 없어진다는 문제가 있다. 체제 순응적인 사람들에게는 더 편한 생태계인지도 모른다.
점차 인공적으로 변해가는 복잡하고 치열한 세상의 뒤에는 이런 변화를 싫어하는 수없이 많은 사람들이 있지만 변화의 속도는 빨라지고 사람들의 바람은 세상의 변화에 떠밀려서 공허하게 들린다. 복잡하고 빠른 것이 좋은 것처럼 보이는 일상의 그림자에서 사람들은 좀 더 간단하고 편한 것을 좋아하게 된다. 사람들의 마음속에 남아 있는 좀 더 느린 시절, 조금 더 느슨한 시대를 바라고 있건만 그 바람은 문화의 코드로는 존재할지 몰라도 산업의 코드는 아니다. 잊혀지고 흐릿해진 기억에 채색되어 예전의 것들은 아름답게 보일 때가 많다. 예전이 좋았다기보다는 재미없는 현실에 무의식이 반발하는 것이다. 사람들의 본성은 너무 복잡하고 정교해지면 정이 떨어지게 된다.
복잡한 것들이 한없이 많아질 것 같은 세상을 막아주는 법칙들 중에는 머피의 법칙들이 있다. 잘못될 수 있는 것은 잘못된다. 너무 복잡한 IT 산업과 기술은 잘못은 아니더라도 좋은 것은 아니다. 언젠가 뛰어난 엔지니어가 나타나 일들을 간단하게 만들어 줄 때까지 일들은 계속 복잡해진다. 아니면 너무 복잡해서 개발자들이 그전에 개발을 포기해 버릴 수도 있다.
머피 류의 법칙은 무척 많아서 책 한 권을 가득 채울 수 있을 정도다. 이상한 일들을 겪거나 이해할 수 없는 일들이 벌어질 때 얻은 깨달음들이 정리되어 머피의 법칙이라는 책을 점차 두텁게 한다. 머피의 법칙이 IT 개발자들에게 얼마나 그리고 어떻게 적용될 것인지는 더 두고 볼일이다.
시스템과 유닛들
머피의 법칙을 피하는 것은 불가능하나 일을 간단하게 만드는 것은 큰 문제를 해결하는 좋은 방법이었다. ‘분할하여 정복하라(divide and conquer)’와 같은 접근법처럼 큰 문제를 잘게 쪼개다보면 잘 못될 수 있는 것들이 줄어든다. 때로는 간단하고 명확한 지침들을 만들어 놓는 것도 좋은 방법이다. 거대한 빌딩의 설계는 복잡할 지라도 실제로 시공은 비교적 단순한 표준 부품들을 조합하여 이루어지듯이 대단해 보이는 것들이 실제로는 간단한 빌딩 블럭인 표준적 컴포넌트들을 사용하여 만든다. 현장에서 가설하는 전화선이 복잡하지 않은 것처럼 시멘트의 시공이 복잡하지 않은 것처럼 간단한 프로토콜을 갖는 요소들의 성공들은 도처에 널려 있다.
개개의 요소들이 머피의 법칙을 통과했기 때문에 조합의 방법만 성공적이라면 시스템은 큰 문제가 없을 가능성이 높다(개별적인 요소가 성공적이라고 해서 조합된 시스템이 안정적인 것은 아니지만). 그전에 없던 새로운 요소를 도입하면 다시 머피의 법칙을 통과해야 한다(머피 시스테맨틱스의 기본 정리인 “새로운 시스템은 새로운 문제를 낳는다”와 같은 법칙이 적용될 수 있겠다). 지속적인 혁신과 발전은 머피의 세계로의 초대나 마찬가지였는데 필자의 머릿속에 떠오르는 대표적인 케이스는 리눅스이다. 에릭 레이먼드가 『성당과 시장』에서 말하듯이 리눅스와 같은 시스템 개발은 초유의 일이었다.
필자는 얼마 전 유영창 님의 『리눅스 디바이스 드라이버』라는 책을 감수한 적이 있다(개인적으로는 나름대로 중요한 책의 작성에 참여하게 되어 아마추어 커널 해커로서는 큰 즐거움이었다). 커널 코드를 훑어보는 것이 힘든 일이긴 했지만 책을 감수하면서 리눅스 커널에 대한 도큐먼트들을 다시 한 번 리뷰할 기회가 있었다. 도큐먼트의 양이 방대한 유닉스는 상당히 복잡한 시스템이다. 유닉스의 사촌인 리눅스는 수없이 많은 프로토콜로 이루어져 있고 이 프로토콜들은 다시 여러 번의 수정과 변경을 거쳐서 다시 만들어진 것이다. 코드마다 버전마다 하나의 역사와 생명이 있다고 할 수도 있을 것이다.
운영체제는 복잡한 것이다. 잘못될 요소는 어디에나 있다. 크게 탈이 나지 않으면서 필요한 기능을 추가하고 성능을 개선하는 일은 쉽지가 않은 일이다. 리눅스는 대표적인 케이스였다. 혁신적인(revolutionary) 기능을 위해 욕심을 부리기보다는 진화적(evolutionary)인 방법을 채택해야 하고 한 시스템이 마음에 들지 않는다고 대대적인 변화를 일으키기도 쉽지 않다. 뛰어난 커널 해커가 있어도 커널의 분기인 포킹(forking)을 일으키는 일은 권장할 수 없었다. 어떤 부분은 특허권에 접촉될 소지도 있었다.
진화적 개발의 리눅스는 사용해가며 필요할 때마다 평가와 변화를 지속해온 시스템으로 잘못 되어가는 요소를 없애가면서 발전해왔다. 쉽게 말하면 불필요한 변화마저도 수용해온 시스템이다. 머피의 법칙이 적용되는 것을 구태여 피하려고 하지도 않았다. 쉬운 일은 아니었다. 중요한 디바이스 드라이버가 몇 년 동안 지지부진하게 개발되는 경우도 있고 드라이버의 개발자끼리 싸움이 일어나 베타 상태를 몇 년 동안이나 유지하는 경우도 있다. 드라이버는 그렇다 치고 커널의 중요한 컴포넌트에 대한 접근철학에 대해서도 몇 년 동안 이메일로 설전을 벌이기도 했다.
가상 메모리(Virtual Memory)의 경우가 심한 경우였는데 다른 운영체제에 비해서 별로 세련되지도 않은 VM 디자인을 갖고 주요 개발자들이 대치했다(초기 디자인은 더 엉성했다). 그 와중에 몇 명은 개발에서 손을 떼기도 했다. 이런 식으로 세월을 보내다 보니 개발자들도 지치고 말았다. 잘못될 것은 잘못될 것이 없을 만큼 고쳐지다 보니 어느 정도 세련된 모습의 커널 2.6이 나오면서 구체적인 모습을 드러냈다.
VM을 고치다보니 파일 시스템도 고쳐야 했고 하는 김에 파일의 캐싱 메커니즘도 고쳐야 했으며, VM 구조는 또 다시 바뀌었다. 보텀하프(Bottom Half)와 타이머의 구조도 처음부터 몇 번을 고쳤는지 모른다. 여러 가지의 보텀하프 구현이 다 이상했기 때문에 잘못되지 않을 때까지, 중간에 사용한 편법 또는 임시방편의 구현들을 포기하는 일까지 포함해서 개발자들은 필요할 때마다 해당 부분을 고치고 다시 고치고를 반복했다.
저널링 파일 시스템에 대한 논쟁이나 쓰레드의 구현을 위한 경쟁도 있었으며 디바이스 드라이버는 그때마다 조금씩 바뀌곤 했다. 네트워크에 해당하는 커널 코드는 그 와중에 또 완전히 변경되었다. 커널에 관련된 업무를 하는 사람들은 정신이 없어지기 딱 알맞은 상황이었다. 몇 년 동안 이런 일이 지속되었다. 관심을 기울이며 상황을 지켜보긴 했으나 나중에는 무슨 작업들이 있었는지조차 기억이 나지 않을 정도로 혼란스러웠다.
커널 2.4는 거의 시험장이나 마찬가지였다. 잘못될 것들은 대부분 잘못되었고 시행착오를 거치면서 다시 잘못되었지만 개발자들은 리눅스를 계속 애용했다. 개발할 내용들은 미리 알려져 있었고 고쳐야 할 점이 있다는 사실도 잘 알았기 때문에 API를 계속 바꾸어가면서 사용해도 별 문제는 없었다. 사용자들은 자세한 내막을 잘 몰랐기 때문에 불안해 할 요소도 없었다. 게다가 레드햇 같은 업체들이 리눅스 배포판의 장점을 계속 강조했기 때문에 사용자들은 특별히 불안해 할 일은 없었다.
머피의 용어로 말하면 ‘지렁이 깡통을 따다’라고 할 수 있는 지리한 작업은 개발자들의 진을 빼기에 충분한 작업이었다. 하나의 가이드 역할을 할 수 있는 『리눅스 커널의 이해』라는 책의 1판이 나올 때는 2.2를 기준으로 했으나 실제로 커널은 2.4로 옮겨졌고 기본적인 사항들을 빼고는 큰 도움을 주지 못했다. 변화가 심하다보니 2.4 기준의 제2판이 나오자 커널은 2.6으로 넘어가 앞서 말한 내용들의 변화에 의해 역시 결정적인 도움을 주지는 못했다.
이 정도가 되면 유닉스의 장점이라고 할 수 있는 ‘아름답고 간결하며 우아한 시스템’ 같은 슬로건과는 거리가 멀다고 할 수 있다. 오류를 껴안고 산다고 할 수 있을 정도로 문제투성이였던 것이다. 개발 과정도 혼란스러웠다. 그럼에도 불구하고 앞서 말한 와인버그의 법칙처럼 딱따구리가 날아와 커널 시스템을 붕괴시키는 일도 없었다.@
Posted by 나그대로
이올린에 북마크하기
이올린에 추천하기
VirtualBox UserManual.pdf
WeatherScreenlet.py
ubuntu_usplash_grub.xpm.gz
