Ask HN: 너무 일찍 중단되거나 종료된 프로젝트가 있나요? 그 이유는?

• 시대를 앞서갔거나 시장이 준비되지 않아 사라진 프로젝트들에 대한 질문과 답들

  그냥 궁금해서요. 누가 이걸 채택할지, 아니면 이 아이디어를 바탕으로 새로운 걸 개발할지 누가 알겠어요.

---

Plan 9 운영체제

• Unix의 진정한 후계자로 평가받았으나 상용화에 실패한 Bell Labs의 분산 운영체제

  • "모든 것이 파일"이라는 철학을 네트워크 공유까지 확장한 혁신적 설계
  • 마우스 코딩, 중첩 윈도우 매니저, Plumber 등 독창적인 UI 기능 제공
  • 모바일, 데스크톱, 클라우드, IoT를 연결하는 분산 환경에 이상적이었으나 채택 실패

• 실패 원인

  • 라이선스 문제와 소송으로 인한 산업계의 외면
  • 중앙 집중식 컴퓨팅이 쇠퇴하고 개인용 컴퓨터가 부상하던 시기와 불일치
  • 연구용 OS로만 포지셔닝하여 .com 붐을 활용하지 못함
  • AT&T의 전화 사업 수익 감소로 Bell Labs가 여러 차례 매각됨
  • Version 3는 박스당 $350에 판매되었으나 비상업적 용도로만 사용 가능
  • 2004년까지 제대로 오픈소스로 공개되지 않음

• 유산

  • 9P 파일시스템 프로토콜은 WSL2, VM 생태계, Kubernetes에서 계속 사용됨
  • 9front 같은 활발한 포크 프로젝트들이 존재
  • Plan 9 Foundation이 오픈소스 코드와 권리를 관리 중

Google의 죽은 프로젝트들

• 30~40개 사용하던 Google 제품이 3~4개로 축소된 사용자의 경험담

  • Google Picasa: 로컬 기반의 빠르고 우수한 사진 관리 도구
  • Google Hangouts: 혼란스러운 메시징 앱 전략의 희생양
  • G Suite Legacy: "영원히 무료" 약속을 파기하고 유료화
  • Play Music: 수천 개의 MP3 파일을 업로드했으나 서비스 종료로 데이터 손실
  • Google Finance: 주식 추적 기능이 있었으나 중단됨
  • Google NFC Wallet: Apple이 같은 기능으로 시장 장악
  • Chromecast Audio: 단일 기능에 충실했으나 중단됨

• Google Reader: 역사상 최악의 비즈니스 결정

  • 장기적으로 유지보수가 거의 필요 없는 서비스였음에도 종료
  • 창업자, CTO, VP of Engineering 등 영향력 있는 사용자층이 많았음
  • Google 제품을 신뢰하지 말라는 교훈을 업계에 남김
  • 서비스 종료가 수백만 달러 절감으로 성과 평가되는 조직 문화의 문제

Adobe Flash / Macromedia Flash

• 15년이 지난 지금도 대체할 만한 도구가 없는 멀티미디어 제작 플랫폼

  • 게임과 멀티미디어 제작을 Lego 블록처럼 쉽게 만들 수 있었음
  • MovieClip, 타임라인 애니메이션 등 직관적인 도구셋 제공
  • HTML Canvas로 대체되었으나 도구의 품질은 비교 불가

• iPhone이 Flash를 죽인 이유

  • 2007년 하드웨어에서 성능 문제와 배터리 소모가 심각
  • Flash가 앱 생태계의 우회로가 될 수 있었기 때문
  • iPhone을 "쓰레기 제품"으로 인식시킬 위험

• 현재 상황

  • Adobe Animate는 JS/Canvas 출력 지원하지만 원작과 다름
  • Ruffle 같은 에뮬레이터로 일부 레거시 콘텐츠 실행 가능
  • Roblox가 어느 정도 비슷한 역할 수행하지만 더 제한적이고 상업적

Microsoft 의 실패한 프로젝트들

• Silverlight: C# 기반의 웹 플러그인

  • JavaScript 대신 완전한 C# 사용 가능
  • 벡터 기반 DPI 인식 UI, MVVM 패턴, 양방향 바인딩
  • Expression Blend를 통한 디자이너-개발자 협업
  • 모든 브라우저에서 완전히 동일하게 렌더링
  • iPhone이 Flash와 함께 Silverlight도 몰락시킴

• Midori: 능력 기반 보안 OS

  • Windows 코드를 실행할 수 있는 수준까지 발전했으나 내부 정치로 중단
  • 많은 연구 성과가 .NET에 통합됨
  • 리텐션 프로젝트(우수 엔지니어 유지용)로 100명 이상 투입

기타

• 애플의 Copland (MacOS 8 프로토타입)

  • 명령줄 없는 현대화된 MacOS 버전
  • 모바일로의 전환을 쉽게 만들 수 있었을 기능들
  • 기능 크립과 불안정성으로 출시 불가
  • Apple의 NeXT 인수를 정당화하기 위해 의도적으로 폐기되었다는 소문

• Songsmith: 멜로디 자동 반주 생성

  • 2009년에 실시간 코드 감지와 반주 생성 기능
  • 현재 Suno, Udio 같은 AI 음악 도구의 선구자
  • 캠프한 프로모션 비디오로 밈이 되었으나 기술력은 뛰어났음

Heroku의 쇠퇴

• 초기의 단순함과 집중도가 성공 요인

  • 단일 언어, 단일 배포 플랫폼, 단일 데이터베이스
  • 의사결정 피로도 최소화
  • 15년 전에 AI가 있었다면 일관된 학습 데이터로 더 효율적이었을 것

• 실패 원인

  • Salesforce 인수 후 거대한 브랜드 배너 추가로 사용자 반발
  • Docker와 Kubernetes의 등장으로 대체 가능해짐
  • 무료 티어 폐지로 많은 고객 이탈
  • 암호화폐로 인한 무료 컴퓨팅 남용 문제

• 현재 상황

  • 일부 사용자는 여전히 프로덕션에서 사용 중
  • Vercel, Coolify, Dokku 등이 유사한 경험 제공

ReactOS - Windows NT 재구현

• 30년 가까이 개발되었으나 여전히 실사용 불가능한 상태

  • Wine + 커널 + 디바이스 드라이버 호환성 + 움직이는 타겟
  • Windows 10 지원 종료를 앞두고도 대안이 되지 못함

• 실패 원인

  • Windows 소스 코드는 잘 문서화되거나 이해되지 않음
  • 클린룸 역공학 원칙상 Windows 코드를 본 사람은 기여 불가
  • Windows XP 소스 코드 유출에도 발전 속도는 여전히 느림
  • Wine, Proton, 가상화 기술이 실용적인 대안으로 자리잡음

Delphi와 Pascal

• 교육용으로 이상적이었던 프로그래밍 언어

  • 초고속 컴파일러로 시행착오 학습에 적합
  • 깔끔한 타입 시스템 (Rust만큼 복잡하지 않음)
  • 프로그래밍 기초 개념 학습에 언어 특화 기능 없이 충실

• 현재 상황

  • Delphi는 버전 13까지 출시되며 건재
  • Lazarus가 오픈소스 대안으로 존재
  • Python이 교육용 언어로 대체했으나 타입 시스템은 혼란스러움

혁신적이었으나 실패한 하드웨어

• MicroChannel (IBM): 채널 기반 주변기기 아키텍처

  • 메인프레임의 채널 개념을 PC에 도입
  • 간단한 채널 프로그램 실행 가능
  • 독점 라이선스로 시장에서 실패
  • 현대 모든 시스템이 유사 기능을 사용하지만 통일된 인터페이스는 없음

• Motorola 680x0: 마이크로컴퓨터 시대의 기반이 될 뻔한 프로세서

  • 1978년 출시되었으나 MMU 출시가 너무 늦음
  • Amiga, 초기 Macintosh의 심장부였음

• Optane 영구 메모리: RAM과 스토리지의 경계를 허문 기술

  • 데이터 구조를 직접 영속화 가능
  • 부팅이나 앱 실행 불필요, 중단한 곳에서 바로 재개
  • 너무 비싸서 실패했지만 기술적으로는 혁명적
  • 비즈니스 의사결정자들의 인내심 부족

• Lytro 라이트필드 카메라: 촬영 후 초점 조정

  • 모든 데이터 캡처 후 초점을 나중에 결정
  • Gaussian splat, Meta Ray-Ban 같은 현대 기술과 완벽히 호환 가능했을 것
  • 전문 사진작가에게 필요한 이미지 품질 미달
  • Polaroid/Instax 같은 노벨티 시장을 노렸어야 했을 것

웹 기술의 논쟁들

• XHTML의 실패

  • 엄격한 파싱으로 HTML의 혼란을 해결하려 함
  • HTML5는 잘못된 HTML의 의미까지 표준화함
  • Postel의 법칙은 틀렸음: 관대한 파싱이 보안 취약점과 호환성 문제 야기
  • "첫 오류에서 멈추고 에러 메시지 표시" 원칙이 더 나았을 것

• 반론: XHTML이 실패한 진짜 이유

  • IE6이 application/xhtml+xml을 지원하지 않음
  • 거의 15년간 IE6 지원 필요
  • JSX, JSON은 엄격한 문법인데도 성공
  • 모든 백엔드 언어는 엄격한 문법 사용
  • 진입 장벽 문제가 아니라 브라우저 지원 문제였음

• HTML의 현실

  • 잘못된 속성 인용으로 전체 페이지가 렌더링 안 될 수 있음
  • 일반인이 작성 가능한 포맷이어야 함
  • HTML은 명령어가 아닌 문서 형식
  • PDF, ZIP, CSV도 손상된 파일을 읽음 (데이터가 포맷보다 중요)

소셜 네트워크와 커뮤니케이션

• Google Wave: 미래를 보여줬으나 너무 일찍 온 혁명

  • 실시간 번역, 다양한 메시징 통합, 풍부한 기능
  • 완전히 오픈소스였음
  • 너무 복잡한 UI로 "중첩된 실시간 업데이트 스레드" 가 압도적
  • 현재 Slack, JIRA, 이메일로 분산된 기능들을 통합했었음

• Vine: TikTok보다 먼저 나온 숏폼 비디오

  • 2013년에 이미 상당한 규모로 성장
  • Twitter가 어떻게 수익화할지 몰라 중단
  • TikTok은 Vine 종료 몇 달 후 출시
  • 정사각형 비디오에 광고 배너만 넣으면 되었는데 기회를 놓침

• Skype: 할머니도 쓸 수 있던 영상통화

  • 전화처럼 간단했지만 국제전화보다 저렴
  • 최고의 P2P 소프트웨어였음
  • Microsoft Teams로 형편없이 대체됨
  • 외부 하드웨어 설정 어려움, 호환성 문제, 예전의 음질 테스트 서비스 없음

운영체제들

• Maemo/MeeGo: Nokia가 밀었어야 할 모바일 리눅스

  • N9은 뛰어난 기기였으나 단 한 대만 출시
  • 해킹 가능, 세련됨, 보안 모두 갖춤
  • 오늘날 Android와 iOS가 아닌 두 개의 주류 모바일 리눅스가 될 수 있었음
  • Sailfish OS로 일부 이어짐

• BeOS: 멀티미디어 최적화 OS

  • BeOS, Amiga 언급까지 스크롤이 길었다는 것이 놀라움
  • Haiku OS로 from-scratch 재구현 진행 중
  • Linux+X+Qt+KDE보다 눈에 띄게 빠르고 반응성 좋음

• OS/2: IBM과 Microsoft의 협업이 낳은 비극

  • 뛰어난 API를 가진 시스템
  • Workplace Shell과 SOM 코드를 공개했다면 다른 운영체제에서 활용 가능했을 것
  • 은행 ATM에서 해킹되지 않고 오래 사용됨

개발 도구들

• Quartz Composer: Apple의 노드 기반 시각적 프로그래밍

  • 패치 기반 비주얼 프로그래밍 환경
  • USB 디바이스 모니터링을 3개 노드로 구현 가능
  • 2016년 이후 업데이트 중단, 최신 OS에서 많은 노드가 깨짐
  • Blender, Unreal Engine의 노드 기반 프로그래밍 인기로 재평가 필요

• Atom 코드 에디터: VS Code의 대안이 될 뻔

  • GitHub가 만든 메인스트림 대안
  • Microsoft가 GitHub 인수 후 Atom의 운명 결정됨
  • Electron의 원조 프로젝트
  • 원 개발자들이 Zed 에디터 개발 중

• Non DAW: 기능별 분리된 DAW

  • 각 기능을 독립 애플리케이션으로 제공
  • 필요한 기능만 쓸 때 다른 기능의 방해 없음
  • 25줄의 예제로 모든 컨셉 소개
  • 메인 개발자가 Microsoft에 고용되어 Rust OSS 작업 중

프로그래밍 언어들

• Elm: 불완전하고 활발히 개발되지 않는 함수형 언어

  • 커스텀 연산자 제거로 모든 코드가 깨지며 momentum 상실
  • Elm Architecture가 너무 경직되어 문제
  • F# (Fable), ReasonML, OCaml (Bucklescript), Haskell, PureScript가 대안

• Opa: 2012년의 타입 기반 Next.js

  • TypeScript 이전에 타입이 있는 풀스택 프레임워크
  • 시장이 서버 측 Node.js에 회의적일 때 출시
  • AGPL 라이선스가 결정타, 나중에 MIT로 변경했지만 두 번째 기회는 없었음

• Austral: 명확한 사고와 독창성을 가진 언어

  • 특이한 명확성을 가진 스펙 제공
  • 작성자가 더 이상 활발히 작업하지 않음
  • 취미 프로그래머에게는 커뮤니티와 생태계 부족

• Ceylon: Red Hat의 JVM 언어

  • Groovy, Kotlin, Scala와 경쟁
  • 익명 유니온 타입, 컴프리헨션, 적절한 모듈 시스템
  • Java 위의 단순 문법 설탕 이상 제공
  • Kotlin과의 경쟁에서 패배, Eclipse에서 방치됨

상업적 실패들

• Google Stadia: 클라우드 게이밍 플랫폼

  • 견고한 스트리밍 플랫폼 구축
  • 흥미로운 게임 부족으로 실패
  • 기존에 다른 곳에서 구할 수 있는 소수의 게임만으로는 부족

• Fire Phone: Amazon의 스마트폰

  • 제로 시장을 타겟팅
  • 회고해보면 성공할 것이라 믿은 것이 믿을 수 없음

• Project Ara: Google/Motorola의 모듈러 스마트폰

  • 커스터마이징 가능한 스마트폰
  • 몇 번의 반복 개발을 더 볼 수 있었으면 좋았을 것
  • 경쟁하기에는 너무 두꺼웠을 것

데이터베이스와 백엔드

• RethinkDB: 실시간 데이터베이스

  • Horizon BaaS로 범위를 확대하다 실패
  • Linux Foundation에서 기술적으로는 존재하지만 momentum 상실
  • 원래 콘셉트는 데모용으로 훌륭했으나 실제 프로덕션 사용 사례 부족

• Yahoo Pipes: RSS와 데이터 흐름 조합 도구

  • 인터넷이 되어야 할 모습을 보여줌
  • 도구 간 연결이 Unix 파이프 수준에만 머물러 있음
  • Zapier, n8n이 현대적 대체재이지만 같은 느낌은 아님
  • Node-RED, Apache Camel, Apache Nifi가 엔터프라이즈 대안

기타 주목할 만한 프로젝트들

• Sandstorm: 2014년의 분산 웹 플랫폼

  • BitTorrent 아이디어 기반
  • 완전히 분산된 웹사이트 코드와 데이터
  • 기존 웹사이트에 통합 가능했음
  • Grain (데이터 격리) 메커니즘이 기존 앱 적응을 어렵게 만듦
  • 앱 포팅보다 플랫폼에서 처음부터 앱 개발에 마케팅했어야 함

• Keybase: 암호화 기반 소셜 네트워크

  • 강력한 암호화와 신원 확인 제공
  • Zoom 인수 후 실질적으로 중단됨
  • FOKS가 원 개발자들의 새 프로젝트

• del.icio.us: 소셜 북마크 서비스

  • 실제 아는 사람들과 북마크 공유
  • 유용한 카테고리 태깅 제공
  • Reddit과 Twitter로 대체됨
  • Pinboard가 유사한 서비스였으나 관리 부족과 창업자의 정치적 견해로 사용자 이탈

[soonil]

추억을 되새기게 하는 기술들이네요

[roxie]

아.. 키베이스 프로젝트 접혔나요??

[click]

vine은 진짜 잘 썼었는데 숏폼시대까지 살아남았으면 숏폼 업계의 선구자로 돈 꽤나 벌렸겠네요

[unknowncyder]

베리즈 웹쉐어?.. 어릴 때 아무 지식 없음에도 상당히 쉽고 편하게 썼던 기억이 있네요

[chicol]

싸이월드가 없네..

[GN⁺]

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 관련해서 궁금한 점 있으면 언제든 연락 바람