Plan 9 운영체제임. 유닉스의 후계자에 가장 가까운 시스템으로, "모든 것은 파일"이라는 철학을 한 단계 더 발전시켜 파일을 네트워크로 쉽게 공유하며 분산 시스템을 구축할 수 있었음. Plan 9에서는 원격 리소스 접근이 쉽고 안정적인 반면, 다른 시스템에서는 각 사용 사례마다 호환성이 떨어지는 소프트웨어를 설치해야 했음. 또한 마우스 코딩 기반의 텍스트 편집, 중첩 윈도우 매니저, 시스템 전체에서 텍스트 패턴에 따라 커맨드를 실행하는 Plumber 등 혁신적 UI 기능도 있었음. 분산형 아키텍처 덕분에 오늘날 모바일, 데스크탑, 클라우드, IoT 기기가 상호 연결된 시대에 최적이었을 터였지만, 실제로는 그렇게 설계되지 않은 운영체제에 머물러 있음. 현재는 9front 같은 포크가 살아있지만 Bell Labs의 오리지널은 사라짐. 멸망 원인은 법적 문제(라이선스, 소송 등)로 주요업계 도입이 지지부진했고, 분산 OS를 원하던 시기에 사람들이 로컬 컴퓨터를 선호했으며, 연구용 OS로만 알려져 닷컴 붐을 제대로 활용하지 못했음. 마지막으로 AT&T의 수익원 상실과 Bell Labs의 매각 및 핵심 멤버 이탈도 영향을 줌
Plan 9의 가장 큰 실패 원인은 유닉스와 달리 하드웨어 공급사들이 저렴하게 라이선스 받고 자유롭게 각자 하드웨어용으로 수정할 수 없었던 점임. Bell Labs는 Plan 9을 상업 소프트웨어로 350달러에 팔려고 했고, 이로 인해 산업계에서 제대로 채택되지 못했음. 내가 여러 번 강조했던 글이 있으니 참고를 추천함: 링크1, 링크2, 링크3
Plan 9 파일시스템 프로토콜이 WSL2 내부에서 여전히 살아 있음
왜 다른 유닉스 계열 시스템들은 "모든 것은 파일" 철학을 적극적으로 도입하지 않는지 궁금함
Plan 9에서는 심볼릭 링크 문제를 해결했음
QNX의 Photon 그래픽 인터페이스도 실시간 중심임에도 위젯, 게이지 등 기능이 좋았고, 웹브라우저도 2개나 지원해서 지연이 없었음. 진정한 실시간 운영체제 느낌이었음. 그리고 Copeland라고 불린 Mac OS 8은 오리지널 Mac OS를 현대화하며 커맨드라인이 없는 전통을 유지했음. 커맨드라인이 없으니 모든 기능 설치와 설정이 쉽고 일관적이어야 했고, 만약 모바일 전환기가 있었다면 부드럽게 이행되었을 것으로 생각함. 사실 개발자에게는 실제 버전이 제공되었지만, Apple이 NeXT를 인수해야 했기 때문에 Copeland 프로젝트는 덮어버렸음. 또 트랜잭션 처리 운영체제 개념도 혁신적이었음. IBM의 CICS처럼 프로그램을 불러와 실행 후 종료하는 식이라 유닉스와 리눅스가 기본적으로 터미널 기반 타임쉐어링 시스템이라는 사실과 대조적임. 다음으로 IBM MicroChannel은 메인프레임 채널의 장점을 PC에 적용하려 했으나, 사실상 독점 정책 때문에 실패함. 오늘날 거의 모든 시스템이 비슷한 개념을 써도 OS를 단순하게 만드는 통합 인터페이스로는 역할하지 못하고 있음. 그리고 제대로 동작하는 하이퍼바이저가 탑재된 CPU도 과거 IBM VM 시스템 때와 달리 x86은 각종 레이어가 전부 꼼수임. Motorola 680x0 시리즈는 마이크로컴퓨터 시대의 기반이 되었어야 했지만 MMU 출시가 너무 늦어 맥을 못춤. 모듈라2와 3는 꽤 괜찮았지만 Oberon은 실패했고, DEC도 동반 몰락함. XHTML의 경우 HTML5에서 오류가 공식화되어 오히려 불필요하게 관대해진 파싱 규칙이 도입됐음. 광고나 외부 코드에서 태그 하나만 제대로 닫히지 않아도 전체 페이지가 무의미하게 깨졌음. 마지막으로 Word Lens처럼 스마트폰으로 세상을 보면 기계 번역과 오프라인 처리까지 가능했던 혁신이 있었지만, 구글 번역에 통합되면서 사라졌음
Copland 프로젝트에 대해 사실을 바로잡고 싶음. 이 프로젝트는 심각하게 관리가 부실했고, 새로운 기술도 무분별하게 추가해 피처크립과 안정성 하락이 심각했음. 누출된 빌드를 써보면 기본 데스크탑 기능만으로도 빈번히 멈추고 크래시 남. 1996년 애플 내부에서는 Copland 출시가 불가능하단 결론이 나왔고, 외부 OS 라이선스를 검토하다 NeXT를 인수하게 된 것임. Copland를 없애고 NeXT를 인수한 것이 아니라, Copland가 절대 출시될 수 없는 수준이어서 어쩔 수 없이 내린 결정이었음
XHTML에 몰두했던 시절이 있었으나, 내 통제 밖에 있는 광고 등 일부 태그 하나만 잘못 닫혀도 전체 페이지가 아예 보이지 않고 커다란 에러 메시지만 나타나는 경험을 했음. “Times New Roman으로만 나머지를 출력”하는 접근도 실질적이지 않음. 원천적으로 HTML을 파싱한다면 앞선 위치와 다를 바 없음. 마니아로서 내 쪽 코드는 완벽하게 작성할 수 있지만, 현실적으로 대부분 사람들은 대충 만듦. XHTML이 논리적으로는 그럴듯해 보여도 현실에서는 사람들 특성상 불가능한 접근이었음
XHTML처럼 엄격한 스타일을 좋아할 수 있지만, 실제로 광범위하게 공유되는 웹문서에는 용서 없는 프레임워크가 어울리지 않음. 이어서 파일 형식에 대해 두 가지로 나누면: (1) 소비자가 저자에게 연락할 수 없는 오픈 루프(HTML, pdf, zip, csv 등)에서는 데이터 자체가 형식보다 중요해서 불량 pdf, zip도 읽어야 함. (2) 소비자가 작성자를 제어할 수 있는 클로즈드 루프(프로그램 소스코드 등)는 엄격한 파서가 허용됨. XHTML은 (2)에서나 통할 모델인데 HTML은 (1)임. 내재적으로 폐쇄된 환경(기업 내 문서 등)이 아니라면 XHTML을 적용하기 어려움
HTML5에서 잘못된 태그 오류를 관대하게 허용하는 현상에 비판적임. 다른 형식들은 대부분 첫 오류에서 멈추는데, HTML만 예외임. 이로 인해 보안 취약점이 많아지고 개발자 모두에게 어렵기만 했음. HTML5 파싱 기조는 기존 관성에 젖은 Internet Explorer에 대항하던 사람들이 너무 이상을 추구하거나 표준이란 이름으로 버그를 문서화하는 쪽으로 흘러버렸음. 관련 RFC
태그를 “제대로” 닫으라는 요구는 언어의 진입 장벽을 높일 뿐임. 예전엔 HTML을 손수 작성하다 실수해도 일단 화면에 뭔가는 떴기 때문에 많은 사람들이 도전을 이어갈 수 있었음. 진짜 프로그래밍 언어는 작은 실수에도 끔찍한 에러 메시지를 내뱉어 쉽게 포기하게 만듦. 최근 언어들은 러스트처럼 개선됐지만, XHTML 시절엔 작은 실수도 파악이 쉽지 않았음
Google Wave를 꼽음. 처음 Chris DiBona 시연을 봤는데 정말 멋졌음. 실시간 번역, 다양한 메시징 통합, 오픈 소스로 멋진 기능이 가득했음. 하지만 실제 출시된 Wave는 축소된 버전이었고, 시장도 외면해 매우 아쉬웠음. 결국 JIRA, Slack, 이메일 같은 것으로 남아 Wave의 부재를 절실히 느낌
Google Wave는 기술 스택은 훌륭했지만, UI 설계에서 치명적인 실수를 범함. Wave를 단일 문서가 아니라 여러 개의 개별 항목으로 다뤄, 복잡하게 보이기만 하고 장점이 사라졌음
시연을 보고 감탄했지만 곧 생각해보니 끔찍하다는 결론에 이름. Slack처럼 각 채널 업데이트를 일일이 체크해야 하는데, Wave는 이 구조가 훨씬 복잡해서 절대 따라갈 수 없을 거라 직감했음
Wave의 기술력은 대단했으나, 데모 영상을 다시보면 별로 좋은 제품이 아니란 걸 알 수 있음. 모든 것을 아우르는 올인원 제품을 만들려 했으나 성공하지 못했음. 오히려 이 기술들이 여러 구글 제품에 분산 적용됐고, 기능별로 별도 UI를 둔 게 훨씬 더 직관적임을 알게 됨
친구들과 여행 일정 등 공유 관리에 딱 좋았고, 문서와 링크를 포함한 애드혹 논의에도 Wave의 폼팩터가 효과적이었음. 미래를 보는 것 같아 초보 시절에 서버 관리 플러그인을 직접 만들기도 했음: Wave-ServerAdmin. 16년이 지났으니 이제 아카이브할 때가 된 듯함
실제 오픈소스 Wave 서버를 받아서 뭔가 제품을 만들어볼까 했는데, 가장 큰 한계는 데이터를 영구 저장하지 못함이었음. 이 때문에 내가 볼 때는 미래가 없었고, Wave 팀원의 반응도 현실을 모르고 환상에 빠져 있는 느낌이었음. 그래도 멋진 컨셉임
Adobe Flash / Shockwave는 수십년이 지난 지금도 게임이나 멀티미디어를 만드는 데 이만큼 쉬운 툴은 없음. 인류가 항상 한 방향으로 발전하지 않고 오히려 소중한 무언가는 영원히 잃기도 한다는 걸 상기시켜 줌
초보자에게도 손쉽게 게임을 만들 수 있어서 게임 업계 전체에 신선한 아이디어가 쏟아졌음. 예를 들어 Zachtronics 같은 인디 개발자가 이 방식으로 데뷔함. 반면, 플래시 게임 하나당 수많은 광고와 조악한 플래시 기반 내비게이션이 난무했고, 한때는 레스토랑 웹사이트 전부가 플래시였을 정도로 남용됨. 플래시 기반 동영상 플레이어는 리눅스에서 골치였고, 브라우저에 제대로 된 비디오 지원을 늦춘 주범이었음
플래시는 웹에 재앙이었음. 확대, 텍스트 선택, 뒤로 가기 등 아무것도 안 되는 검은 박스로 존재했음. 죽은 것이 스티브 잡스 최고의 업적으로 느껴질 정도임
Godot가 꽤 근접해 있음. 배우기 쉽고 2D, 3D 모두 지원하며, HTML5/webasm으로 주요 OS와 모바일까지 폭넓게 내보낼 수 있음. 아직 완벽하진 않지만 최근 몇 년간 비약적 발전을 했고, 블렌더처럼 메이저 전환점이 오고 있는 것 같음
Adobe가 보안 문제를 완전히 해결했어도, 애플은 어차피 죽였을 것임. 플래시의 대중적 성공은 애플에겐 위협이었음. HTML canvas 열풍도 잠잠해진 지금까지도 디자이너가 구독 없이 멋진 인터랙티브 디자인을 만들고 어디서든 임베드할 대체재는 여전히 없음
Flash가 너무 남용됐던 게 문제였음. 회사에서 어떤 앱이 끝까지 Flash를 고집해 이유를 찾아보니, 페이지의 단순한 가로 구분선을 Flash로 만든 것이었음. 플래시 드롭다운 메뉴, 자동차 사이트 스플래시 스크린 등 전부 오남용임. 모바일 시대가 오고서야 죽을 수 있었고, 그때는 별로 아쉬워하는 사람도 거의 없었음
killedbygoogle.com에서 볼 수 있는 수많은 구글 서비스들이 있음. 한때 30~40개를 써봤으나 이제 3~4개만 사용함. Google Picasa는 로컬에서 빠르게 사용할 수 있었고, Google Hangouts는 여러 채팅 앱 때문에 혼란스러움. G Suite Legacy는 평생 무료라더니 결국 유료화되어 구글을 떠남. Google Play Music은 업로드한 수천 곡의 MP3가 있었는데 서비스가 종료돼 다시 올릴 생각이 없음. Google Finance, NFC Wallet도 데이터 신뢰가 깨져 이동함. Chromecast Audio는 필요한 딱 한 가지 기능만 했고, 단종 소식에 곧 팔아버림. Chromecast까지 죽었다는 건 쓰는 중에 알게 됨
Google Reader도 영원히 아쉬움. 운영비 부담도 크지 않았을 텐데, 오랫동안 고쳐지지 않아도 아무 불만 없었을 기능이었음. 예전이나 지금이나 RSS는 동일하게 쓰고 있음
Google Play Music에서 업로드한 음악이 전부 사라진 건 아님. 유튜브 뮤직으로 전환한 유저라면 새로 업로드하지 않아도 곡이 전부 이동됨
Chromecast Audio는 여전히 잘 동작함. 단지 더이상 판매하지 않을 뿐이라서, 중고 매물도 항상 살펴보고 있음
피카사의 얼굴 인식은 시대를 앞섰으며 오프라인 패키지가 정말 좋았음. 아쉽게도 마지막 버전엔 얼굴 태그가 랜덤하게 바뀌는 버그가 있어 몇 천 장 가족사진의 인식이 무용지물이 됨. Digikam은 간신히 비슷한 역할을 할 뿐, 대체재로는 미약함
Google Notebook을 종료한 뒤 몇 년 후 Google Keep을 만들었는데, 기능은 거의 같았던 점이 흥미로움
Lytro 라이트필드 카메라는 기술적으로 인상적이었고 두 개 제품도 출시했지만, 프로 사진가용 해상도에는 미달했음. 그러나 Meta Ray-Ban의 라이트필드 디스플레이와 gaussian splats 등의 매체 등장으로 이제는 더 많은 센서 데이터를 활용할 수 있는 시점이 됨. 기술 외적으로는 폴라로이드나 인스탁스 같은 기발한 저해상도 카메라 시장도 크기 때문에, 첫 Lytro는 재미있는 폼팩터로 프린터를 탑재해도 문제없었음
라이트필드는 여러 초점 깊이에서 픽셀을 섞어서 기록하니까 결과적으로 해상도가 일반 카메라보다 떨어질 수밖에 없는 구조임. 제조는 어렵지 않지만 물리적 한계가 아쉬움
요즘은 스마트폰도 이 기능을 일부 구현한 듯함. Lytro 카메라의 등장이 꽤 신났던 기억이 있음
Optane 퍼시스턴트 메모리는 데이터 직접 저장으로 부팅, 앱 로드 없이 바로 이어쓸 수 있는 혁신적인 가치가 있었음. 너무 비싸 실패했지만 그전에도 이미 한계가 분명했음. VM의 메모리 스냅숏, macOS 컨테이너 등 때문에 이 흐름은 완전히 사라지지 않음
3dxpoint 기술에 무한 신뢰를 보냄. 수십 년 간 숙성된 기술이지만, 비즈니스 측에서 세계가 따라오기를 기다릴 인내심이 없었음
기존 시스템 사고방식이 RAM과 디스크 구분에 갇혀, Optane 같은 새로운 하드웨어를 받아들일 준비가 덜 되어 있었음. 그래도 서버 영역에서는 몇몇 응용사례가 나오고, 관련 연구 프로젝트도 많이 등장함
Optane은 기술적으로 굉장했음. 램과 디스크의 경계를 없앨 뻔한 것으로, 한 스틱으로 모든 메모리를 다 쓸 수 있었음
나는 실제로 커널을 Optane 드라이브에 두어 즉시 부팅 체험을 하고 있음
가격 때문만이 아니라, 에코시스템 기반이 충분히 퍼지지 못했고, 기존 사고방식도 준비가 덜 되어 있음. 초기 리습이나 스몰토크처럼 (라이브) 이미지 기반 환경에 더 가까운 모델임. 나 역시 펌웨어와 저용량 Optane이 지원됐던 시스템을 보유하고 있음. 용량은 작고 오래된 OS에 매여 있지만, 실험할 가치가 큼. 램이 충분히 많으면 suspend/resume처럼 흉내도 가능함. SSD 발전과 합치면 속도차가 거의 없어짐. TBW 같은 내구성만 남음. 둘을 혼합해 쓸 수도 있음
Ricochet 네트워크는 전화 회선 시대에 무선 패킷 메시망으로 ISDN급 속도를 제공했던 독특한 시스템임. 23개 도시 네트워크에 $50억을 쏟았지만 고객이 전무했고, 2001년 문을 닫음. 마케팅은 "모바일 전문가"에 집중했으나, 실제로는 더 빠른 인터넷을 바랐던 가정용 시장을 외면함. 오늘날 5G 펨토셀은 물리적 컨셉을 닮았지만, 리던던시와 자가 라우팅 개념이 부족함
Ricochet 모뎀을 정말 사랑했음. 2세대 Ricochet와 파워북을 들고 팔로알토 카페에서 56k 웹브라우징, ssh 세션을 했던 추억이 있음. 아직도 집 어딘가 박스에 있는데, star 모드로 재미 삼아 연결해볼까 고민 중임
98~99년에 샌프란시스코에서 Ricochet 모뎀을 썼음. 10년 뒤 iPhone이 3G 시대를 열었고, 성능 개선도 압도적이었음. 만약 Ricochet가 생존했다면 내 삶이 더 나아졌을까 생각해보면, 오히려 기술 진보가 훨씬 제대로 된 방향으로 갔다고 느껴짐
완전히 잊고 있었던 서비스인데, 생각해보면 그때 정말 뛰어났었음. 나도 4명뿐이던 고객 중 한 명이었나 봄
Microsoft의 Midori는 권한 기반 보안을 추구한 OS였음. 소문에 따르면 Windows 코드 실행이 가능할 정도로 개발됐으나, 내부 정치로 폐기됐다는 이야기도 있음. Fuchsia의 전신 같은 존재임. Midori 위키
Midori가 정말 흥미로웠음. Joe Duffy의 블로그가 그나마 가장 상세한 자료임: Midori 블로그. Microsoft 내부에선 moonshot이자 핵심 인력 유지 프로젝트였다는 평도 있음. 백 명 이상, 아주 시니어 엔지니어 대거 투입됐었음. 일부 연구 성과는 .NET에 활용되어 완전히 다 사라진 건 아님
Windows 코드 실행 소문은 어디서 나온 건지 모르겠음. 공개된 모든 문서에 따르면 Midori는 기존 코드와 완전히 비호환을 추구했음. 내부에서나 이주 꿈을 꾸던 사람이 있었겠지만, 설계 자체가 전환 없는 근본적인 새 시스템임
기술 기초는 흥미롭지만, Microsoft라면 결국 새 전용 문제로 가득 찬 팽창형 소프트웨어가 됐을 듯함. 지금쯤이면 애초에 사용자들이 원하지 않는 스파이웨어와 AI 기능까지 잔뜩 들어있었을 것임
Genode(genode.org)를 아는지 궁금함. Midori와 비슷한 영역에 있고 아직도 활발히 개발되고 있음
Yahoo pipes는 RSS 피드와 커스텀 워크플로우를 만들기에 정말 좋았음. 요즘은 Zapier나 n8n 같은 대체제가 있지만, Pipes를 특히 좋아했음. 그리고 구글 리더에 대한 회고도 동감함
Yahoo Pipes는 인터넷이 나아가야 할 미래였음. 수십 년이 지난 지금도 그런 인터툴 연동이 진짜 unix pipes 수준으로만 겨우 구현됨
직접 써본 적은 없지만, pipes에 대한 긍정적 회고를 들을 때마다 엄청난 도구였음이 느껴짐. 정말 죽은 게 Pipes인지, 아니면 열린 표준과 프로토콜 기반 대중 인터넷이 사라진 건지 모르겠음
Pipes를 사랑했음. 여러 사이트에서 컨텐츠를 모아 pipes로 포맷하고, php 블로그에 RSS로 가져왔음. 하지만 하나 둘씩 사이트들이 RSS 지원을 끊으면서 Pipes도 의미가 잃었고, 결국 종료됨. 한동안 riko라는 파이썬 라이브러리를 써서 비주얼 에디터 없이 비슷한 기능을 썼고, 덕분에 PHP에서 파이썬으로 넘어가는 계기가 됐음
Yahoo! Pipes의 아이디어를 되살리고 싶다면 Node-RED(nodered.org)가 좋은 출발점임. 오픈소스, 탄탄한 API, 10년 이상 축적된 경험, 견고한 백엔드 등 강점이 많음. Node-RED 프론트엔드만 따오는 Browser-Red, Erlang 백엔드로 재구성한 Erlang-Red도 실제 써봄. Node-RED는 모든 노드가 입력포트가 하나거나 없는 반면, Pipes는 여러 입력선이 가능한 차이가 있음. 프론트엔드는 jQuery를 알면 쉽게 익힐 수 있어 좋음. Node-RED나 flow-based programming 관련해서 궁금한 점 있으면 언제든 연락 바람
Hacker News 의견
Plan 9 운영체제임. 유닉스의 후계자에 가장 가까운 시스템으로, "모든 것은 파일"이라는 철학을 한 단계 더 발전시켜 파일을 네트워크로 쉽게 공유하며 분산 시스템을 구축할 수 있었음. Plan 9에서는 원격 리소스 접근이 쉽고 안정적인 반면, 다른 시스템에서는 각 사용 사례마다 호환성이 떨어지는 소프트웨어를 설치해야 했음. 또한 마우스 코딩 기반의 텍스트 편집, 중첩 윈도우 매니저, 시스템 전체에서 텍스트 패턴에 따라 커맨드를 실행하는 Plumber 등 혁신적 UI 기능도 있었음. 분산형 아키텍처 덕분에 오늘날 모바일, 데스크탑, 클라우드, IoT 기기가 상호 연결된 시대에 최적이었을 터였지만, 실제로는 그렇게 설계되지 않은 운영체제에 머물러 있음. 현재는 9front 같은 포크가 살아있지만 Bell Labs의 오리지널은 사라짐. 멸망 원인은 법적 문제(라이선스, 소송 등)로 주요업계 도입이 지지부진했고, 분산 OS를 원하던 시기에 사람들이 로컬 컴퓨터를 선호했으며, 연구용 OS로만 알려져 닷컴 붐을 제대로 활용하지 못했음. 마지막으로 AT&T의 수익원 상실과 Bell Labs의 매각 및 핵심 멤버 이탈도 영향을 줌
Plan 9의 가장 큰 실패 원인은 유닉스와 달리 하드웨어 공급사들이 저렴하게 라이선스 받고 자유롭게 각자 하드웨어용으로 수정할 수 없었던 점임. Bell Labs는 Plan 9을 상업 소프트웨어로 350달러에 팔려고 했고, 이로 인해 산업계에서 제대로 채택되지 못했음. 내가 여러 번 강조했던 글이 있으니 참고를 추천함: 링크1, 링크2, 링크3
Plan 9 파일시스템 프로토콜이 WSL2 내부에서 여전히 살아 있음
왜 다른 유닉스 계열 시스템들은 "모든 것은 파일" 철학을 적극적으로 도입하지 않는지 궁금함
Plan 9에서는 심볼릭 링크 문제를 해결했음
QNX의 Photon 그래픽 인터페이스도 실시간 중심임에도 위젯, 게이지 등 기능이 좋았고, 웹브라우저도 2개나 지원해서 지연이 없었음. 진정한 실시간 운영체제 느낌이었음. 그리고 Copeland라고 불린 Mac OS 8은 오리지널 Mac OS를 현대화하며 커맨드라인이 없는 전통을 유지했음. 커맨드라인이 없으니 모든 기능 설치와 설정이 쉽고 일관적이어야 했고, 만약 모바일 전환기가 있었다면 부드럽게 이행되었을 것으로 생각함. 사실 개발자에게는 실제 버전이 제공되었지만, Apple이 NeXT를 인수해야 했기 때문에 Copeland 프로젝트는 덮어버렸음. 또 트랜잭션 처리 운영체제 개념도 혁신적이었음. IBM의 CICS처럼 프로그램을 불러와 실행 후 종료하는 식이라 유닉스와 리눅스가 기본적으로 터미널 기반 타임쉐어링 시스템이라는 사실과 대조적임. 다음으로 IBM MicroChannel은 메인프레임 채널의 장점을 PC에 적용하려 했으나, 사실상 독점 정책 때문에 실패함. 오늘날 거의 모든 시스템이 비슷한 개념을 써도 OS를 단순하게 만드는 통합 인터페이스로는 역할하지 못하고 있음. 그리고 제대로 동작하는 하이퍼바이저가 탑재된 CPU도 과거 IBM VM 시스템 때와 달리 x86은 각종 레이어가 전부 꼼수임. Motorola 680x0 시리즈는 마이크로컴퓨터 시대의 기반이 되었어야 했지만 MMU 출시가 너무 늦어 맥을 못춤. 모듈라2와 3는 꽤 괜찮았지만 Oberon은 실패했고, DEC도 동반 몰락함. XHTML의 경우 HTML5에서 오류가 공식화되어 오히려 불필요하게 관대해진 파싱 규칙이 도입됐음. 광고나 외부 코드에서 태그 하나만 제대로 닫히지 않아도 전체 페이지가 무의미하게 깨졌음. 마지막으로 Word Lens처럼 스마트폰으로 세상을 보면 기계 번역과 오프라인 처리까지 가능했던 혁신이 있었지만, 구글 번역에 통합되면서 사라졌음
Copland 프로젝트에 대해 사실을 바로잡고 싶음. 이 프로젝트는 심각하게 관리가 부실했고, 새로운 기술도 무분별하게 추가해 피처크립과 안정성 하락이 심각했음. 누출된 빌드를 써보면 기본 데스크탑 기능만으로도 빈번히 멈추고 크래시 남. 1996년 애플 내부에서는 Copland 출시가 불가능하단 결론이 나왔고, 외부 OS 라이선스를 검토하다 NeXT를 인수하게 된 것임. Copland를 없애고 NeXT를 인수한 것이 아니라, Copland가 절대 출시될 수 없는 수준이어서 어쩔 수 없이 내린 결정이었음
XHTML에 몰두했던 시절이 있었으나, 내 통제 밖에 있는 광고 등 일부 태그 하나만 잘못 닫혀도 전체 페이지가 아예 보이지 않고 커다란 에러 메시지만 나타나는 경험을 했음. “Times New Roman으로만 나머지를 출력”하는 접근도 실질적이지 않음. 원천적으로 HTML을 파싱한다면 앞선 위치와 다를 바 없음. 마니아로서 내 쪽 코드는 완벽하게 작성할 수 있지만, 현실적으로 대부분 사람들은 대충 만듦. XHTML이 논리적으로는 그럴듯해 보여도 현실에서는 사람들 특성상 불가능한 접근이었음
XHTML처럼 엄격한 스타일을 좋아할 수 있지만, 실제로 광범위하게 공유되는 웹문서에는 용서 없는 프레임워크가 어울리지 않음. 이어서 파일 형식에 대해 두 가지로 나누면: (1) 소비자가 저자에게 연락할 수 없는 오픈 루프(HTML, pdf, zip, csv 등)에서는 데이터 자체가 형식보다 중요해서 불량 pdf, zip도 읽어야 함. (2) 소비자가 작성자를 제어할 수 있는 클로즈드 루프(프로그램 소스코드 등)는 엄격한 파서가 허용됨. XHTML은 (2)에서나 통할 모델인데 HTML은 (1)임. 내재적으로 폐쇄된 환경(기업 내 문서 등)이 아니라면 XHTML을 적용하기 어려움
HTML5에서 잘못된 태그 오류를 관대하게 허용하는 현상에 비판적임. 다른 형식들은 대부분 첫 오류에서 멈추는데, HTML만 예외임. 이로 인해 보안 취약점이 많아지고 개발자 모두에게 어렵기만 했음. HTML5 파싱 기조는 기존 관성에 젖은 Internet Explorer에 대항하던 사람들이 너무 이상을 추구하거나 표준이란 이름으로 버그를 문서화하는 쪽으로 흘러버렸음. 관련 RFC
태그를 “제대로” 닫으라는 요구는 언어의 진입 장벽을 높일 뿐임. 예전엔 HTML을 손수 작성하다 실수해도 일단 화면에 뭔가는 떴기 때문에 많은 사람들이 도전을 이어갈 수 있었음. 진짜 프로그래밍 언어는 작은 실수에도 끔찍한 에러 메시지를 내뱉어 쉽게 포기하게 만듦. 최근 언어들은 러스트처럼 개선됐지만, XHTML 시절엔 작은 실수도 파악이 쉽지 않았음
Google Wave를 꼽음. 처음 Chris DiBona 시연을 봤는데 정말 멋졌음. 실시간 번역, 다양한 메시징 통합, 오픈 소스로 멋진 기능이 가득했음. 하지만 실제 출시된 Wave는 축소된 버전이었고, 시장도 외면해 매우 아쉬웠음. 결국 JIRA, Slack, 이메일 같은 것으로 남아 Wave의 부재를 절실히 느낌
Google Wave는 기술 스택은 훌륭했지만, UI 설계에서 치명적인 실수를 범함. Wave를 단일 문서가 아니라 여러 개의 개별 항목으로 다뤄, 복잡하게 보이기만 하고 장점이 사라졌음
시연을 보고 감탄했지만 곧 생각해보니 끔찍하다는 결론에 이름. Slack처럼 각 채널 업데이트를 일일이 체크해야 하는데, Wave는 이 구조가 훨씬 복잡해서 절대 따라갈 수 없을 거라 직감했음
Wave의 기술력은 대단했으나, 데모 영상을 다시보면 별로 좋은 제품이 아니란 걸 알 수 있음. 모든 것을 아우르는 올인원 제품을 만들려 했으나 성공하지 못했음. 오히려 이 기술들이 여러 구글 제품에 분산 적용됐고, 기능별로 별도 UI를 둔 게 훨씬 더 직관적임을 알게 됨
친구들과 여행 일정 등 공유 관리에 딱 좋았고, 문서와 링크를 포함한 애드혹 논의에도 Wave의 폼팩터가 효과적이었음. 미래를 보는 것 같아 초보 시절에 서버 관리 플러그인을 직접 만들기도 했음: Wave-ServerAdmin. 16년이 지났으니 이제 아카이브할 때가 된 듯함
실제 오픈소스 Wave 서버를 받아서 뭔가 제품을 만들어볼까 했는데, 가장 큰 한계는 데이터를 영구 저장하지 못함이었음. 이 때문에 내가 볼 때는 미래가 없었고, Wave 팀원의 반응도 현실을 모르고 환상에 빠져 있는 느낌이었음. 그래도 멋진 컨셉임
Adobe Flash / Shockwave는 수십년이 지난 지금도 게임이나 멀티미디어를 만드는 데 이만큼 쉬운 툴은 없음. 인류가 항상 한 방향으로 발전하지 않고 오히려 소중한 무언가는 영원히 잃기도 한다는 걸 상기시켜 줌
초보자에게도 손쉽게 게임을 만들 수 있어서 게임 업계 전체에 신선한 아이디어가 쏟아졌음. 예를 들어 Zachtronics 같은 인디 개발자가 이 방식으로 데뷔함. 반면, 플래시 게임 하나당 수많은 광고와 조악한 플래시 기반 내비게이션이 난무했고, 한때는 레스토랑 웹사이트 전부가 플래시였을 정도로 남용됨. 플래시 기반 동영상 플레이어는 리눅스에서 골치였고, 브라우저에 제대로 된 비디오 지원을 늦춘 주범이었음
플래시는 웹에 재앙이었음. 확대, 텍스트 선택, 뒤로 가기 등 아무것도 안 되는 검은 박스로 존재했음. 죽은 것이 스티브 잡스 최고의 업적으로 느껴질 정도임
Godot가 꽤 근접해 있음. 배우기 쉽고 2D, 3D 모두 지원하며, HTML5/webasm으로 주요 OS와 모바일까지 폭넓게 내보낼 수 있음. 아직 완벽하진 않지만 최근 몇 년간 비약적 발전을 했고, 블렌더처럼 메이저 전환점이 오고 있는 것 같음
Adobe가 보안 문제를 완전히 해결했어도, 애플은 어차피 죽였을 것임. 플래시의 대중적 성공은 애플에겐 위협이었음. HTML canvas 열풍도 잠잠해진 지금까지도 디자이너가 구독 없이 멋진 인터랙티브 디자인을 만들고 어디서든 임베드할 대체재는 여전히 없음
Flash가 너무 남용됐던 게 문제였음. 회사에서 어떤 앱이 끝까지 Flash를 고집해 이유를 찾아보니, 페이지의 단순한 가로 구분선을 Flash로 만든 것이었음. 플래시 드롭다운 메뉴, 자동차 사이트 스플래시 스크린 등 전부 오남용임. 모바일 시대가 오고서야 죽을 수 있었고, 그때는 별로 아쉬워하는 사람도 거의 없었음
killedbygoogle.com에서 볼 수 있는 수많은 구글 서비스들이 있음. 한때 30~40개를 써봤으나 이제 3~4개만 사용함. Google Picasa는 로컬에서 빠르게 사용할 수 있었고, Google Hangouts는 여러 채팅 앱 때문에 혼란스러움. G Suite Legacy는 평생 무료라더니 결국 유료화되어 구글을 떠남. Google Play Music은 업로드한 수천 곡의 MP3가 있었는데 서비스가 종료돼 다시 올릴 생각이 없음. Google Finance, NFC Wallet도 데이터 신뢰가 깨져 이동함. Chromecast Audio는 필요한 딱 한 가지 기능만 했고, 단종 소식에 곧 팔아버림. Chromecast까지 죽었다는 건 쓰는 중에 알게 됨
Google Reader도 영원히 아쉬움. 운영비 부담도 크지 않았을 텐데, 오랫동안 고쳐지지 않아도 아무 불만 없었을 기능이었음. 예전이나 지금이나 RSS는 동일하게 쓰고 있음
Google Play Music에서 업로드한 음악이 전부 사라진 건 아님. 유튜브 뮤직으로 전환한 유저라면 새로 업로드하지 않아도 곡이 전부 이동됨
Chromecast Audio는 여전히 잘 동작함. 단지 더이상 판매하지 않을 뿐이라서, 중고 매물도 항상 살펴보고 있음
피카사의 얼굴 인식은 시대를 앞섰으며 오프라인 패키지가 정말 좋았음. 아쉽게도 마지막 버전엔 얼굴 태그가 랜덤하게 바뀌는 버그가 있어 몇 천 장 가족사진의 인식이 무용지물이 됨. Digikam은 간신히 비슷한 역할을 할 뿐, 대체재로는 미약함
Google Notebook을 종료한 뒤 몇 년 후 Google Keep을 만들었는데, 기능은 거의 같았던 점이 흥미로움
Lytro 라이트필드 카메라는 기술적으로 인상적이었고 두 개 제품도 출시했지만, 프로 사진가용 해상도에는 미달했음. 그러나 Meta Ray-Ban의 라이트필드 디스플레이와 gaussian splats 등의 매체 등장으로 이제는 더 많은 센서 데이터를 활용할 수 있는 시점이 됨. 기술 외적으로는 폴라로이드나 인스탁스 같은 기발한 저해상도 카메라 시장도 크기 때문에, 첫 Lytro는 재미있는 폼팩터로 프린터를 탑재해도 문제없었음
라이트필드는 여러 초점 깊이에서 픽셀을 섞어서 기록하니까 결과적으로 해상도가 일반 카메라보다 떨어질 수밖에 없는 구조임. 제조는 어렵지 않지만 물리적 한계가 아쉬움
요즘은 스마트폰도 이 기능을 일부 구현한 듯함. Lytro 카메라의 등장이 꽤 신났던 기억이 있음
Optane 퍼시스턴트 메모리는 데이터 직접 저장으로 부팅, 앱 로드 없이 바로 이어쓸 수 있는 혁신적인 가치가 있었음. 너무 비싸 실패했지만 그전에도 이미 한계가 분명했음. VM의 메모리 스냅숏, macOS 컨테이너 등 때문에 이 흐름은 완전히 사라지지 않음
3dxpoint 기술에 무한 신뢰를 보냄. 수십 년 간 숙성된 기술이지만, 비즈니스 측에서 세계가 따라오기를 기다릴 인내심이 없었음
기존 시스템 사고방식이 RAM과 디스크 구분에 갇혀, Optane 같은 새로운 하드웨어를 받아들일 준비가 덜 되어 있었음. 그래도 서버 영역에서는 몇몇 응용사례가 나오고, 관련 연구 프로젝트도 많이 등장함
Optane은 기술적으로 굉장했음. 램과 디스크의 경계를 없앨 뻔한 것으로, 한 스틱으로 모든 메모리를 다 쓸 수 있었음
나는 실제로 커널을 Optane 드라이브에 두어 즉시 부팅 체험을 하고 있음
가격 때문만이 아니라, 에코시스템 기반이 충분히 퍼지지 못했고, 기존 사고방식도 준비가 덜 되어 있음. 초기 리습이나 스몰토크처럼 (라이브) 이미지 기반 환경에 더 가까운 모델임. 나 역시 펌웨어와 저용량 Optane이 지원됐던 시스템을 보유하고 있음. 용량은 작고 오래된 OS에 매여 있지만, 실험할 가치가 큼. 램이 충분히 많으면 suspend/resume처럼 흉내도 가능함. SSD 발전과 합치면 속도차가 거의 없어짐. TBW 같은 내구성만 남음. 둘을 혼합해 쓸 수도 있음
Ricochet 네트워크는 전화 회선 시대에 무선 패킷 메시망으로 ISDN급 속도를 제공했던 독특한 시스템임. 23개 도시 네트워크에 $50억을 쏟았지만 고객이 전무했고, 2001년 문을 닫음. 마케팅은 "모바일 전문가"에 집중했으나, 실제로는 더 빠른 인터넷을 바랐던 가정용 시장을 외면함. 오늘날 5G 펨토셀은 물리적 컨셉을 닮았지만, 리던던시와 자가 라우팅 개념이 부족함
Ricochet는 시대를 앞선 멋진 시스템이었음. Joel Spolsky가 남긴 감상도 추천함: Ricochet Wireless 모뎀 리뷰
Ricochet 모뎀을 정말 사랑했음. 2세대 Ricochet와 파워북을 들고 팔로알토 카페에서 56k 웹브라우징, ssh 세션을 했던 추억이 있음. 아직도 집 어딘가 박스에 있는데, star 모드로 재미 삼아 연결해볼까 고민 중임
98~99년에 샌프란시스코에서 Ricochet 모뎀을 썼음. 10년 뒤 iPhone이 3G 시대를 열었고, 성능 개선도 압도적이었음. 만약 Ricochet가 생존했다면 내 삶이 더 나아졌을까 생각해보면, 오히려 기술 진보가 훨씬 제대로 된 방향으로 갔다고 느껴짐
완전히 잊고 있었던 서비스인데, 생각해보면 그때 정말 뛰어났었음. 나도 4명뿐이던 고객 중 한 명이었나 봄
Microsoft의 Midori는 권한 기반 보안을 추구한 OS였음. 소문에 따르면 Windows 코드 실행이 가능할 정도로 개발됐으나, 내부 정치로 폐기됐다는 이야기도 있음. Fuchsia의 전신 같은 존재임. Midori 위키
Midori가 정말 흥미로웠음. Joe Duffy의 블로그가 그나마 가장 상세한 자료임: Midori 블로그. Microsoft 내부에선 moonshot이자 핵심 인력 유지 프로젝트였다는 평도 있음. 백 명 이상, 아주 시니어 엔지니어 대거 투입됐었음. 일부 연구 성과는 .NET에 활용되어 완전히 다 사라진 건 아님
Windows 코드 실행 소문은 어디서 나온 건지 모르겠음. 공개된 모든 문서에 따르면 Midori는 기존 코드와 완전히 비호환을 추구했음. 내부에서나 이주 꿈을 꾸던 사람이 있었겠지만, 설계 자체가 전환 없는 근본적인 새 시스템임
기술 기초는 흥미롭지만, Microsoft라면 결국 새 전용 문제로 가득 찬 팽창형 소프트웨어가 됐을 듯함. 지금쯤이면 애초에 사용자들이 원하지 않는 스파이웨어와 AI 기능까지 잔뜩 들어있었을 것임
Genode(genode.org)를 아는지 궁금함. Midori와 비슷한 영역에 있고 아직도 활발히 개발되고 있음
Yahoo pipes는 RSS 피드와 커스텀 워크플로우를 만들기에 정말 좋았음. 요즘은 Zapier나 n8n 같은 대체제가 있지만, Pipes를 특히 좋아했음. 그리고 구글 리더에 대한 회고도 동감함
Pipes의 역사 아카이브를 꼭 읽어볼 것을 추천함. 실제 개발진들의 회고가 담겨 있음
Yahoo Pipes는 인터넷이 나아가야 할 미래였음. 수십 년이 지난 지금도 그런 인터툴 연동이 진짜 unix pipes 수준으로만 겨우 구현됨
직접 써본 적은 없지만, pipes에 대한 긍정적 회고를 들을 때마다 엄청난 도구였음이 느껴짐. 정말 죽은 게 Pipes인지, 아니면 열린 표준과 프로토콜 기반 대중 인터넷이 사라진 건지 모르겠음
Pipes를 사랑했음. 여러 사이트에서 컨텐츠를 모아 pipes로 포맷하고, php 블로그에 RSS로 가져왔음. 하지만 하나 둘씩 사이트들이 RSS 지원을 끊으면서 Pipes도 의미가 잃었고, 결국 종료됨. 한동안 riko라는 파이썬 라이브러리를 써서 비주얼 에디터 없이 비슷한 기능을 썼고, 덕분에 PHP에서 파이썬으로 넘어가는 계기가 됐음
Yahoo! Pipes의 아이디어를 되살리고 싶다면 Node-RED(nodered.org)가 좋은 출발점임. 오픈소스, 탄탄한 API, 10년 이상 축적된 경험, 견고한 백엔드 등 강점이 많음. Node-RED 프론트엔드만 따오는 Browser-Red, Erlang 백엔드로 재구성한 Erlang-Red도 실제 써봄. Node-RED는 모든 노드가 입력포트가 하나거나 없는 반면, Pipes는 여러 입력선이 가능한 차이가 있음. 프론트엔드는 jQuery를 알면 쉽게 익힐 수 있어 좋음. Node-RED나 flow-based programming 관련해서 궁금한 점 있으면 언제든 연락 바람