[서평] 마이크로소프트웨어 390호, 오픈소스의 꿈

[ 읽게 된 동기 ]

IT 트랜드를 익히기 위한 노력.
 

[ 한줄평 ]

오픈소스 세계에 사는 부러운 사람들의 이야기.
 

[ 서평 ]

 
개발자로 일하며 ‘오픈소스’ 에 대해서 들어보지 않은 사람이 있을까? 만약 그렇다면, 아직까지 개발자를 하고 있다면 그 사람은 아마 스마트폰도 모르는 원시시대 개발자일 것이다.
그만큼 오픈소스는 이미 이 바닥에서는 수면위로 올라왔다. 이제는 오픈소스 기업이 어떻게 돈을 버는지도 많은 개발자들이 알고 있으며, 리모트 워크를 즐기는 20대의 젊은 개발자들도 필자의 주변에 하나 둘 생기기 시작했다. 인터넷이 연결되지 않은 환경에서의 개발은 너무도 괴롭고, ‘바퀴부터 만드는’ 행위는 결코 환영받지 못한다.
마이크로소프트웨어 390호, 오픈소스의 꿈 에서는 리눅스 등 OS 부터 Python 등 언어를 거쳐, 오픈스택 등 클라우드 환경은 물론 각종 라이브러리에 이르기까지. 오픈소스 세상에 살고 있는 그들의 살아있는 이야기를 지면에 옮겼다.
 

# 안드로이드 개발자. 오픈소스 위의 개발자.

 
필자는 안드로이드 개발자로 일해왔다.
안드로이드 개발을 하면서 오픈소스를 모른다고 하면 대한민국에 살면서 조선을 모른다고 하는 것과 같은 말이리라. 안드로이드 자체가 오픈소스니 말이다. 그렇다. 삼성, LG 등에 올라가는 안드로이드는 안드로이드 진영에서 배포한 안드로이드를 커스터마이징해 사용하고 있다. 오픈소스란 말이다.
소스가 오픈 되어있는 만큼 ‘안 되는 것’ 은 없다. 모바일 프로젝트를 하다 보면 아이폰 개발자는 ‘안됩니다!’ 라고 딱 잘라 말할 수 있는 반면, 안드로이드 개발자는 ‘아… 그거 좀 곤란한데’ 라고 말하는 것을 쉽게 볼 수 있다. (안드로이드 개발자가 아이폰 개발자보다 피곤한 부분이다.) 각종 제약이 아이폰 보다 덜하기 때문인데 이것은 안드로이드가 태생적으로 오픈소스이기 때문이다.
 
안드로이드 진영은 기본적으로 제공되는 ListView, ImageView 등을 모두 커스터마이징 해 사용할 수 있다. 이는 역시 오픈소스를 아주 손 쉽게 찾을 수 있다는 것을 의미한다. 그렇다. 필자 또한 안드로이드 개발자로 일하며 수 많은 오픈 소스 라이브러리를 사용했다. Http 통신 라이브러리인 Volley, Retrofit 등은 물론이고, 이미지를 처리하는 Picasso, Glide 등. 모바일 프로젝트를 하면서 안드로이드 개발자가 오픈소스 라이브러리를 사용하지 않기는 거의 불가능 하다.
아니, 안 쓰는게 미련한 짓이지.
때문에 오픈소스는 필자에게 매우 익숙한 존재였고, 보다 효율적인 프로젝트를 위해 Http 통신 라이브러리를 비교 분석하는 등 이런 환경을 나름 즐기기도 했었다.
 
오픈소스는 잘 사용하면 참 고마운 존재들이었다. 복잡한 기능이라며 기획자와 잔뜩 싸우고 돌아와 검색을 해보니, 똑같은 기능을 구현해 오픈소스로 풀어놓은 라이브러리가 있었다. 데모를 만들어보고 프로젝트에 적용했더니 완벽히 구현되는게 아닌가? 개발자 입장에서 이토록 땡큐일 수가 있을까?
물론, 많은 개발자가 투입되니 검증이 상대적으로 약하고 이를 발견하지 못하고 배포될 가능성도 있다. 안드로이드에는 어처구니 없는 버그들이 참 많은데, 그 중 제일 화가 나는 것은 환경을 세팅하는 과정에서의 버그다.
 

<필자의 Stackoverflow>

 
기록을 확인하니 무려 2년 6개월 전.
당시 구글은 안드로이드 공식 지원 툴을 이클립스에서 안드로이드 스튜디오로 바꿀 것을 강제화 했고, 어쩔 수 없이 익숙한 이클립스를 버리고 안드로이드 스튜디오로 갈아탔다. 그리곤 저 망할 버그가 나를 계속해서 괴롭혔던 것이다. (오해하지 말자. 지금은 스튜디오에, Intellij 에 무척 익숙해져서 감사히 사용하는 중이다. :D)
이 버그가 망할 버그인 이유는 이 질문이 무려 1만 1천건의 View 를 기록했다는 것이다. 그렇다. 비슷한 현상을 만난 개발자들이 무척 많았다는 것이다. 필자는 이 질문 덕분에 “Famous Question” 이라는 금 뱃지를 받았다.
 

<필자가 받은 Famous Question>

 
이게 오픈소스와 무슨 상관이 있냐고 묻는다면, 저 툴 자체가 오픈소스다. (오픈소스 – 안드로이드 스튜디오) 또한, 안드로이드 자체가 오픈소스이고 버그의 원인인 저 Build Tools 자체 역시 오픈소스인 것이다. 문제는 싱겁게 환경 세팅 문제인 것으로 해결되었지만, 오픈소스라는게 마냥 거창하기만 한 것은 아니라고 말해주고 싶었다.
물론 안드로이드는 지금까지 내 밥벌이였던 고마운 녀석이지만, 단점 역시 확실했었다.
 

# 그대, 오픈소스가 궁금한가?

 
그동안 지난 2017년에 출간한 마이크로소프트웨어를 총 4권 모두 읽었지만, 주변의 후배들에게 읽어보라고 권하고 싶었던 호는 이번 오픈소스 호가 처음이다. 사실, 앞서 보안편은 필자 조차도 너무 어려웠고 검색이나 인공지능은 너무 높은 레벨이라 쉽사리 공감하기 어려운 글들이 많았다.
하지만, 오픈소스 편에는 초보 개발자들도 쉽게 접할 수 있는 내용들이 많았다. 아니, 정확히는 재미난 역사 이야기가 많았다고나 할까?
 
사실, 대부분의 ‘정보’ 들은 온라인에서 다 얻을 수 있을 것이다. 리누스 토발즈가 어떤 제품들을 만들었고, 어떤 철학을 갖는지는 그의 히스토리를 훑어보는게 마소를 읽는 것 보다 나을지도 모르겠다.
하지만, 뭐가 있는지 알아야 찾아볼 것이 아닌가? 앞서 말했듯, 필자는 오픈소스의 대표주자인 안드로이드 진영의 개발자로 일해왔지만 오픈소스가 어느정도 파급력을 떨치고 있는지는 잘 몰랐다. 그저 눈 앞의 일을 하다보면 그렇게 된다.
마소의 이번 호에서는 오픈소스에 대한 전반적인 이야기를 다룬다. 요즘 ‘가즈아~’ 로 핫한 비트코인 그리고 비트코인을 구성하는 블록체인. MS, IBM, AWS 등 대기업들이 왜 이 바닥에서 한 자리를 차지하려 하는지. 한 자리를 차지하기 위한 노력들엔 뭐가 있는지.
 
여기까지는 역시 온라인에서도 찾을 수 있겠다. 하지만, 실제 오픈소스 활동을 하는 일반 개발자들의 이야기. 과거부터 이 활동을 계속해온 개발자는 물론, 이제 시작하는 뉴비들까지.
이러한 정보들 또한 블로그 등을 통해 찾을 수 있겠지만, 앉은 자리에서 별다른 에너지 소비 없이 편안히 읽어내려 갈 수 있는 것은 꽤 큰 이득이다. 필자는 오늘 점심쯤 일어나 빵을 하나 물고 자리에 앉아서 7-8 시간 동안 마소 오픈소스 편을 다 읽었다.
원하는 정보를 찾는 것은 꽤나 큰 에너지를 필요로 한다. 때문에 오픈소스가 뭔지, 오픈소스로 어떻게 돈을 버는지. 진짜 그걸 하는 사람들이 있는지 등을 물어보는 개발자 후배들에게 필자는 편안히 이번 마소 오픈소스 편을 추천해주려 한다.
 
공부합시다! 개발자여.
 
 

[ 인상 깊은 문구 ]

• 마치 군주제, 대통령제, 의원내각제의 설명을 보는 것 같지 않은가? 성공적인 오픈소스 프로젝트는 국가 정치 제도 못지 않은 체계적인 의사결정 시스템을 갖추고 있다.
• 분산 버전 관리 시스템을 적용한 이후 컨트리뷰션이 40% 가까이 늘어났다고 하는 실제 연구사례도 나왔다.
• 기업용 오픈소스로 수익을 내는 대표적인 기업이 래드햇이다. 오픈소스인 리눅스에 다양한 기술 지원과 추가 기능을 더해 기업에게 제공한다. 오픈소스 교육 프로그램도 별도로 운영한다. 래드햇은 시가총액이 15조원, 2015년 매출이 2조원에 이르는 대기업이다.
• 그래서 피아의 민주주의OS팀은 대담한 도전을 한다. 직접 당을 창당했다. 그리고 그 당의 후보들이 당선되면 민주주의OS에 따라서 행동하겠다는 공약을 내걸었다. 그리고 선거에서 1.2%를 득표했다. 비록 의석을 얻진 못했지만, 많은 관심을 받을 수 있는 충분한 표였다.
• 나는 개방형 협업 모델이 아주 중요하고 혁신을 만들어낸다는 점은 동의하지만, 사회 전체가 곧 재편될 것이라는 주장에는 아직 회의적이다. 아직 세상에는 디지털화 되지 않은 재화와 서비스들이 많다. 다른 말로 하면 ‘비트Bit 는 가볍지만 원자Atom는 무겁다’는 의미다.
• 아파치는 미국의 인디언 부족명에서 따왔다고 한다. 아파치 부족은 용맹한 전사를 거느리고 다양한 전략을 구상하는 종족으로 유명했으며, 19세기 미국 군대와 직접 전투를 벌이기도 했다.
• 아파치 라이선스를 따르는 가장 큰 프로젝트는 안드로이드 플랫폼이다.
• PMC 멤버처럼 소스코드에 접근 권한을 가진, 보다 핵심적인 기여자가 되려면 기존 PMC 멤버들로부터 초대를 받아야 한다.
• 리처드 스톨만은 이러한 문화를 ‘요리법을 공유하는 것이 요리의 역사만큼 오래된 것처럼, 소프트웨어를 공유하는 것은 컴퓨터의 역사만큼이나 오래된 것이었다’ 라고 표현했다.
• 자유 소프트웨어 재단은 오픈소스라는 용어에는 ‘자유롭게 사용할 수 있는 권리’가 포함돼 있지 않다고 보고, 자유 소프트웨어라는 용어를 사용하기를 권장한다. GNU 프로젝트 공식 홈페이지에서는 ‘자유 소프트웨어 운동과 오픈소스 운동은 공동체에 있어서 두 개의 정당과 같다’라며 ‘자유 소프트웨어 운동과 오픈소스 운동은 기본 원칙에 대해서 의견을 달리하지만, 모든 현실적인 방안에 대해서는 같은 생각을 갖고 있으며 세부적인 프로젝트에서 같이 협력하고 있다’고 설명하고 있다.
• 과거 일부 사람들은 리처드 스톨만을 ‘사회주의자’라고 표현할 만큼 지나친 이상주의자로 여겼다.
• 오픈소스 정신과 철학으로 거대 기업의 압력에 굴복하지 않았던 이들의 적극적인 투쟁이 지금의 모질라를 만들었다.
• 해커들은 ‘시간이 곧 돈이다’라는 격언에 무조건 동조하지 않는다. 대신 그들은 ‘시간은 나의 삶이다’라는 격언을 더 선호한다. 무언가 박탈당하지 않은, 충실하게 살아가는 현재의 우리 삶이 바로 시간이다.
• 토발즈는 보통 프로그래밍하면서 밤늦도록 일하다가 이른 오후에 잠자리에서 일어났다. 때로는 리눅스를 코딩하다가도 갑자기 컴퓨터를 가지고 놀거나 전혀 다른 일을 하곤 했다. 이러한 자유로운 시간활용은 항상 삶의 개인적 리듬을 올바르게 이해하고 있는 해커들의 전형적인 특성이다.
• 내가 가르치고 또 함께 일하는 사람 중 상당수가 자기 공부에 수동적이라는 사실이다. 내가 대화해 본 사람들은 대개 선생님의 가르침을 기대하거나 이런저런 자격증을 딸 시간이나 금전적 여유를 원했는데, 이런 조건이 갖춰지면 자기 뜻대로 운명이 펼쳐진다고 보는 것 같았다. 이들은 안전하고 전형적인 안내 관광을 떠나려고 돈을 모아 놓고 정기 여객선을 기다리는 사람들이다.
• 지식 노동자의 성공은 현재 아는 사실이 아니라 배우는 방식이 좌우한다.
• 재미있는 것은 블록체인이 비트코인의 바탕이 되는 체계이지만, 블록체인이 만들어지고 비트코인이 만들어진 것이 아니라 비트코인을 만들기 위해 고민하던 중에 블록체인이라는 기술이 탄생했다는 점이다.
• 송금 과정에 있어서의 모든 것이 은행 하나에 집중돼 있다. 이는 바꿔 말하면 은행이 바로 단일 실패 지점이라는 말이다. 컴퓨팅 분야에서 이런 단일 실패 지점 문제를 해결하는 보편적인 방법은 고가용성처리, 쉽게 말해 다중화다. 2중, 3중으로 복제나 분산처리를 해서 단일 실패 지점을 없애는 전략을 취한다. 은행 시스템도 이런 다중화 처리가 돼 있으므로 앞에서 말한 어처구니 없는 불상사는 쉽게 일어나지 않는다.
• 비트코인의 블록 하나에는 평균 약 1800개의 거래 정보가 포함될 수 있으며, 블록 하나의 물리적인 크기는 평균 0.98Mbytes다. 블록은 블록헤더와 거래 정보, 기타 정보로 구성된다.
• 블록체인은 블록으로 이뤄진 링크드 리스트다.
• 뉴턴 역시 네덜란드 튤립 버블, 프랑스의 미시시피 거품과 비견되는 남해 주식회사 거품 사건의 피해자이기도 했다. 뉴턴은 당시 가치로 2만 파운드, 현재 가치로 약 20억원 이상의 피해를 입었다.
• 사우디 전체의 석유가 기초 자산인 사우디 아라비아 국영 석유 회사인 사우디 아람코가 2조달러 가치를 인정받는 것과 비교해 보면, 남해의 당대 주식 가치는 충격적이다. 사우디 아람코보다 남해가 더 비싼 회사였다는 것을 알 수 있다. 주식 시장의 과열을 판단하는 기준 중 하나는 국내총생산과 주식 시장의 크기를 비교하는 것이다. 미국 주식시장 규모가 GDP의 2배, 남해는 당시 영국 GDP의 7배 였다고 한다.
• 몇 가지 간단한 시뮬레이션을 통해 초단타 매매 프로그램을 개발한 경력과 파생에 대한 이해도가 높은 프로그래머가 고의적으로 플래시 크래시를 일으켰을 가능성도 열려 있음을 확인할 수 있었다.
• 왼손에는 오픈소스를, 오른손에는 상업 소프트웨어와 그에 따른 특허를 쥐고 필요한 순간마다 교차하며 그 손을 내밀고 있다. ‘MS는 오픈소스를 사랑합니다’라는 표현이 무의미함의 나락으로 떨어지는 순간이다.
• IBM은 생태계의 성공이 곧 업계의 성공이라고 믿고 있다. 그래서 IBM이 성공하는 것만으로는 충분하지 않다. 건강한 생태계를 갖추려면 관련한 많은 사람들이 성공할 수 있도록 도와줘야 한다.
• 특정인 또는 특정 회사에 의해 진행됐던 오픈소스 프로젝트가 예상치 않은 결과를 맞는 경우는 흔히 접할 수 있다. 최근 페이스북이 ‘Parse’ 프로젝트를 더 이상 진행하지 않기로 해 많은 관련 개발자들을 당황시킨 경우 등.
• 우아한형제들은 오래전부터 배달의 민족 폰트라는 형태로 사회에 기여하는 문화를 가지고 있었다. 그 영향인지 소프트웨어를 오픈소스화하는 결정에 아무런 장애가 없었다.
• 1년여 ‘WoowahanJS’를 운영하면서 지금도 가장 큰 비용이 드는 작업 하나를 꼽으라면 단연 문서화 작업을 꼽고 싶다.
• 꽤 오래전 가상 서버를 여러 대 운영하고 있을 때, 각 서버의 ‘libcurl’ 라이브러리 버전에 차이가 있어 애플리케이션 엔드포인트가 동작하는 방식이 서버에 따라 달라져 디버깅에 애를 먹은 적이 있다.
• 서버리스는 서버 없이 모든 규모의 이벤트에 대해 코드를 실행해 응답하는 클라우드 컴퓨팅 방식이다.
• 현재 아파치 오픈위스크는 아파치 소프트웨어 재단의 인큐베이터 프로젝트로 승인을 받은 상태다. 아파치 프로젝트로 승인받은 오픈소스 프로젝트는 특정 회사에 속한 오픈소스보다 개발자를 모아 생태계를 만들기 쉽다.
• 나같은 평범한 개인도 오픈소스 프로젝트에 공헌을 할 수 있다는 것을 알게된 후, 흥미가 자연스레 붙기 시작했다. ‘개발자를 돕는 개발자’라는 것도 나름의 의미가 부여가 됐다.
• 제디스와 다르게 세속적인 목표로 시작해서인지 중간중간 난관들이 많았고, 그만둘까 생각도 많이 했다. ‘내일부터 하지 말아야지.’라고 마음 먹으면 내가 공헌할 만한 일이 나타나고, 그 일을 통해 계속 의지를 이어갔다.
• 영어 작문과 해석 능력 증진에도 상당히 도움됐다. 역설적이지만 오픈소스 공헌에는 어느 정도의 영어 작문 능력, 그리고 해석 능력이 필요하다. 하지만 해당 조건을 만족하게 되면, 오픈소스 활동을 하면서 작문을 엄청나게 많이 하게 되기 때문에 연습이 되지 않을 수가 없다.
• 유명 오픈소스 프로젝트의 구현을 공부하겠다는 마음가짐으로 시작한 시도들은 전부 실패했다. 대부분 제대로 시도하지도 못했다. 그리고 본인의 조직 내에서 업무 역량과 커리어에 도움을 줄 수 있는 프로젝트를 고르는 것이 바람직하다.
• 기능을 제안하거나 패치를 제출할 때, 본인은 커미터를 설득해야 하는 상황이라는 점도 염두에 둬야 한다. 프로젝트의 명시적.암죽적룰과 코드 스타일을 따르는 것은 필수다.
• 모든 팁에는 우선시 하는 팁이 있다. 바로 ‘꾸준해야 인정받는다’는 것이다. 오픈소스 세계는 신기하게도 속된 말로 ‘뜨내기’들을 잘 알아본다.
• 그로부터 우리는 1개월 뒤 하우리 창업을 통해 본격적으로 안랩과 경쟁 구도를 만들자고 약속했다. 1988년 9월 하우리를 창업하고 두 백신 엔진의 기술적 결합을 통해 바이로봇 엔진을 개발하기 시작했다.
• 키콤백신은 이를 사전에 차단하기 위해 빌드 시점에 모든 엔진이 RSA키를 생성해, 다른 사람이 빌드한 엔진을 구동하지 못하게 하고 있다.
• 또한 iOS 애플리케이션 빌드 서비스를 제공하는 ‘buddybuild’에서 iOS 애플리케이션에서 사용하는 라이브러리를 분석한 결과, 구글과 페이스북의 라이브러리 다음으로 가장 많이 사용된 SDK카 ‘Realm’ 이다.
• 세계적인 트렌드와 비용절감 효과가 크게 부각된 여론 등에 편승해 그 기조가 바뀌기 시작했는데, 이 과정만 살펴봐도 상향식이 아닌 하양식 형태로 오픈소스가 확산됐음을 알 수 있다.
• 아파치 타조는 아파치 소프트웨어 재단에서 최상위 프로젝트로 승격됐고, 올챙이의 엔터프라이즈 버전은 카카오뱅크에 사용되면서 우수성을 인정 받고 있다.
• 하지만 범위를 자바스크립트에 한정해서 보면, 외국의 사례같은 폭 넓고 일반적인 주제를 다루는 모임은 여전히 부족하다. 대부분 특정 기술이나 프레임워크 또는 구글, 페이스북, 네이버 등 특정 회사의 기술만 다루고 있기 때문이다.
• 또 다른 아쉬운 점은 국제적인 레벨의 자바스크립트 콘퍼런스를 주최할 주체가 없다는 것이었다.
• 서울JS에서는 몇가지 형태의 이벤트를 기획하고 있다. 첫번째는 온라인 온리 밋업이다. 특정 기술을 선정해, 관심있는 사람들을 온라인으로 모아 기술 세부 내용을 약 15분 단위로 나눠서 온라인 스트리밍으로 발표하는 방식으로 진행할 예정이다.
• 커뮤니티는 자발적으로 참여하므로 자격에 특별한 제한을 두지 않는다. 하지만 단순히 자격을 갖추고 있다고 해서, 구성원이 되는 것이 아니기 때문에 다른 참여자의 활동을 제한하지 않기 위한 행동 강령을 만들었다.
• 데이터 랭글링은 원천 데이터에서 최초 형태로 자료를 추출해 가공하는 것을 말한다.
• 학교의 튜토리얼에서 제공하는 데이터셋은 대부분 간단한 랭글링으로 끝나지만, 회사에서 다루는 비즈니스 문제는 원천 소스를 가공하는 순간부터 데이터 엔지니어링의 작업이 필요하다.
• 자동차 소프트웨어는 C언어로 구현하는 경우가 많은데, C언어의 꽃이라 불리는 포인터 사용을 제한한다. 전역 변수의 사용 역시 제한한다. 그 이유는 포인터나 전역 변수를 사용하는 편리함보다 이로 인해 발생할 수 있는 메모리 문제나 높은 복잡도를 예방하기 위함이다.
• 오픈소스를 사용하면 더 빠르게 개발할 수도 있고 많은 사람이 참여해 검증된 소스코드를 사용할 수도 있다. 자동차 소프트웨어에 기능 개발에도 적용할 수 있지만, 관련한 오픈소스 프로젝트 수는 많지 않고 적용한 사례도 매우 적다. 앞에서 살펴본 ‘ISO 26262’의 요구 조건 때문이다.
• 정말 훌륭한 기능의 오픈소스가 있어서 새로 개발하는 자동차 소프트웨어에 포함하기로 했다고 가정하자. 개발 완료 후 납품을 위해서 개발 전 과정의 요구조건을 만족했다는 증거를 제출해야 한다. 예를 들어 소스코드가 ‘MISRA C’ 규칙을 만족했다는 증거, 테스트 커버리지를 만족하고 테스트 실패도 없다는 증거, 순환 복잡도, 결합도 기준을 만족했다는 증거를 제시해야 하는데 이 모든 것을 위해서는 ‘ISO 26262’ 기준을 반족한 도구를 사용해야 한다. 이 도구는 대체로 상용 도구고, 비용도 고가다. 필자가 경험한 도구들은 한 개 라이센스 당 몇천만원 수준이었다.
• 소프트웨어 개발 방법으로 애자일이 소개된 것은 이미 10년도 넘었으나, 자동차 소프트웨어 분야는 이제 소개되고 있다. 자동차 산업이 가장 앞선다는 독일에서 3년 전에 관련 콘퍼런스가 시작되고 사례를 공유하고 있다.
• 기계학습이나 딥러닝 자체의 기술은 빠르게 발전하고 보급되고 있으나, 여전히 데이터 부족 현상은 지속되고 있다. 기계가 학습하기 위한 기본이 데이터라는 점에서 심각하게 생각해 볼 이슈다.
• 파일명은 기본적으로 주제어에 대한 한글, 영어, 어휘의 연결을 위한 ‘-‘, ‘+’, ‘_’와 같은 특수 문자, 연도를 표기 위한 숫자를 조합한 형태다. 물론 이렇게 파일명을 표기하면 사람은 읽기 수월할 수 있으나, 기계가 파일명을 읽고 처리하는 것은 쉽지 않다.
• 현재 사용되고 있는 항목명은 공백이나 특수문자가 포함돼있어, 이 항목명들을 수정하지 않고 동일 어휘를 판단하는 것은 정확하지 않다. 실제 파일 데이터는 전체 항목명 중 23%에 해당하는 3만 955개에 공백이 있고, 오픈API 데이터는 약 58%에 해당하는 4만 7001개에서 공백이 발견됐다.
• 블랙덕소프트웨어에서 2017년 1000개 이상의 상용 애플리케이션을 대상으로 조사, 분석한 ‘오픈소스 보안&리스크 분석 보고서’에 의하면, 기업 상용 애플리케이션의 96%가 오픈소스를 활용하고 있었다.
• 수도 장안은 수많은 국가에서 모인 상인들로 늘 붐볐다. ‘장안의 화제’라는 말이 생길 정도였다.
• 위징의 쓴소리를 듣고 와서 칼자루를 쥐며 부르르 떨고 있는 당 태종에게 장손 황후는 이렇게 말해줬다. “축하드립니다. 뛰어난 황제가 되셨습니다. 명군만이 신하들에게 직언을 들을 수 있다고 들었습니다.” 부인의 이런 말을 듣고 태종은 화를 누그러뜨릴 수 밖에 없었다.
• 위키피디아가 부정확하다는 프레임은 잘못됐다는 것이다. 위키피디아와 브리태니커 백과사전을 <네이처>지가 비교를 한 적이 있었다. 두 백과사전에서 과학 분야 항목 42개를 추출해 비교 분석했는데, 놀랍게도 차이는 아주 적었다. 위키피디아에서는 항목 당 부적확한 부분이 4개가 발견됐고, 브리태니커에서는 3개가 발견됐다. 위키피디아의 오류는 사용자들에 의해 수정됐지만, 브리태니커 오류는 그대로였다. 또한 위키피디아에 무작위로 외설적인 콘텐츠를 삽입했는데, 평균 1.7분만에 삭제됐다는 MIT 연구 결과도 나왔다.