Famo.us, HTML5, 웹이 놓친 가장 흥미로운 가능성
기술의 역사는 대개 승자 중심으로 기록됩니다.
트랜지스터, 클라우드 컴퓨팅, AI. 단순히 “잘 작동한 기술”이 아니라 산업 전체의 판을 바꿔버린 플랫폼, 프로토콜, 제품들이죠. 그런데 그 못지않게 중요한 이야기가 하나 더 있습니다. 너무 일찍 등장했고, 큰 문제를 정확히 짚었고, 많은 주목을 받았고, 심지어 진짜로 의미 있는 해법까지 제시했지만… 결국 실패한 기술의 이야기입니다.
Famo.us는 바로 그런 기술이었습니다.
2010년대 초반 웹 개발을 했던 분들이라면, 당시의 공기를 기억하실 겁니다. HTML5는 단순한 표준 업데이트가 아니었어요. 일종의 약속이었고, 어쩌면 혁명에 더 가까웠습니다. 웹은 이제 “그냥 웹페이지를 보여주는 공간”을 넘어, 풍부한 인터페이스와 자연스러운 애니메이션, 몰입감 있는 상호작용, 네이티브 앱에 가까운 성능까지 제공하는 진짜 애플리케이션 플랫폼이 될 것처럼 보였죠. 그것도 Flash나 Silverlight 같은 플러그인 없이 말입니다.
그 비전은 중요했습니다. 지금도 여전히 중요합니다.
문제는 현실이었죠.
브라우저는 아직 거기까지 준비되어 있지 않았습니다.
Famo.us는 바로 그 틈에서 태어났습니다. 웹이 “되어야 했던 모습”과 2012년 당시 “실제로 할 수 있었던 것” 사이의 고통스러운 간극 말이죠. 이 기술은 브라우저의 일반적인 레이아웃 방식을 우회하고, GPU 가속을 최대한 활용하고, UI를 문서가 아니라 움직이는 장면처럼 다루면서 미래를 조금 더 빨리 끌어오려 했습니다.
잠시 동안은 정말 미래처럼 보였습니다.
하지만 미래는 결국 다른 방향으로 흘러갔습니다.
어떤 기술은 애초에 잘못된 문제를 풀어서 실패합니다. 반면 어떤 기술은 문제는 정확히 맞췄지만, 플랫폼이 아직 준비되지 않았거나 시장이 그 해법을 받아들일 타이밍이 아니어서 실패합니다. Famo.us는 후자에 가까웠습니다.
이 글에서는 Famo.us가 정확히 무엇이었는지, 왜 그렇게 유망해 보였는지, 왜 끝내 무너졌는지, 그리고 2026년의 개발자·창업자·프로덕트 팀이 여기서 무엇을 배울 수 있는지 차근차근 짚어보겠습니다.
Famo.us는 무엇이었나
Famo.us는 2010년대 초반, 웹 앱을 네이티브 앱처럼 더 부드럽고 더 풍부하고 더 반응성 있게 만들고자 했던 흐름 속에서 등장한 브라우저 기반 렌더링 엔진이자 UI Framework였습니다.
핵심 아이디어는 대담했습니다. 브라우저의 일반적인 CSS 레이아웃 모델에 그대로 기대지 않고, 가능한 한 그 시스템을 우회한 다음 절대 좌표 기반의 데카르트 좌표계와 3D 변환 행렬을 이용해 요소를 배치하겠다는 것이었죠. 쉽게 말해, 인터페이스 요소를 문서 안에서 차곡차곡 흐르는 블록처럼 다루지 않고, 하나의 장면 안에 놓인 객체처럼 취급한 겁니다.
이 차이가 정말 중요합니다.
전통적인 웹 레이아웃은 문서 중심입니다. 콘텐츠는 아래로 흐르고, 컨테이너는 자식 요소에 영향을 주고, 브라우저는 그 모든 요소가 어떻게 맞물릴지를 계산합니다. 반면 Famo.us는 다른 방식을 원했습니다. 레이아웃, 크기, 움직임, 애니메이션을 수학적으로 정의하고자 했죠. 구체적으로는 4x4 변환 행렬을 계산해 CSS matrix3d 값으로 출력하고, 그 값을 브라우저가 해석하게 했습니다.
그러니까 Famo.us는 브라우저에게 “이걸 일반적인 페이지처럼 배치해줘”라고 요청한 것이 아니라, 사실상 이렇게 말한 셈입니다.
“각 객체에 어떤 변환이 적용되어야 하는지 정확히 줄 테니, 그대로 그려줘.”
당시 기준으로는 꽤 급진적인 접근이었습니다.
그리고 이 아이디어는 허공에서 나온 게 아니었습니다. 아주 현실적인 고통에서 출발했죠.
왜 HTML5는 그렇게까지 큰 기대를 모았을까
Famo.us를 이해하려면 먼저 2012년 전후 웹 개발 생태계의 분위기를 이해해야 합니다.
HTML5는 단순한 명세 업데이트가 아니었습니다. 웹의 미래 그 자체처럼 여겨졌죠. 많은 개발자들이 HTML5 아래에서 브라우저가 단순한 문서 뷰어를 넘어, 진짜 애플리케이션 실행 환경으로 진화할 것이라고 믿었습니다.
그 약속은 꽤 강력했습니다.
- Flash 없이 풍부한 앱을 만들 수 있다
- Silverlight 없이 인터랙티브한 미디어를 구현할 수 있다
- 하나의 코드베이스로 여러 플랫폼을 커버할 수 있다
- 브라우저 안에서 앱 같은 경험을 제공할 수 있다
- 웹 앱과 네이티브 앱의 격차를 줄일 수 있다
전략적으로 보면 아주 그럴듯했어요. 브라우저가 비디오, 오디오, 저장소, 애니메이션, 그래픽, 고급 상호작용을 자체적으로 다룰 수 있다면, 개발자는 도달 범위도 넓히고 이식성도 높이고 배포 방식도 단순화할 수 있었으니까요.
플러그인도 없고, 앱스토어 심사도 없고, 플랫폼별 네이티브 코드를 따로 만들 필요도 없습니다.
이상적으로는 완벽한 그림이었죠.
실제로 그중 일부는 현실이 됐습니다.
다만 한 번에, 동시에 다 이루어진 것은 아니었습니다.
플러그인 제거와 네이티브급 성능은 같은 문제가 아니었습니다
이건 미묘하지만 아주 중요합니다.
HTML5는 Flash, Silverlight 같은 외부 브라우저 런타임에 대한 의존을 줄이는 데 분명 큰 역할을 했습니다. 호환성, 보안, 표준화, 접근성 측면에서 매우 큰 진전이었죠.
하지만 플러그인을 없애는 것과 네이티브 수준의 성능을 구현하는 것은 전혀 다른 과제였습니다.
전자는 표준화와 브라우저 기능 확장에 달려 있었습니다.
후자는 브라우저 엔진의 성숙도, 렌더링 구조, 애니메이션 스케줄링, GPU compositing, 하드웨어 가속 파이프라인이 실제로 얼마나 견고한가에 달려 있었죠.
2012년 당시에는 그 부분이 아직 따라오는 중이었습니다.
그래서 개발자들은 꽤 난처한 상황에 놓였습니다. 이론적으로는 웹이 이전보다 훨씬 많은 일을 할 수 있게 되었는데, 실제 사용자 경험은 그 기대를 자꾸 깨뜨렸거든요.
앱은 만들 수 있었습니다.
그런데 늘 “좋게” 만들 수 있는 건 아니었습니다.
진짜 문제: 왜 웹 앱은 네이티브처럼 느껴지지 않았나
프론트엔드 성능 문제를 조금이라도 다뤄본 분이라면 이 고통을 이미 알고 계실 겁니다.
사용자는 어떤 앱이 “최신 표준”으로 만들어졌는지에 별 관심이 없습니다. 그보다 중요한 건 체감입니다. 스크롤이 부드러운지, 화면 전환이 버벅이지 않는지, 복잡한 리스트에서 프레임이 떨어지지 않는지, 카드 애니메이션이 매끄럽게 움직이는지, 아니면 무거운 짐을 끌듯 둔탁하게 움직이는지 말이죠.
HTML5 시대 개발자들이 부딪힌 진짜 문제도 바로 이 부분이었습니다.
웹 브라우저는 근본적으로 문서 레이아웃에 최적화되어 있습니다. 즉, 흐름, 블록, 인라인 요소, reflow, repaint 같은 개념을 중심으로 작동하죠. 다시 말해, 페이지를 잘 렌더링하기 위해 설계된 시스템이지, 촉각적이고 역동적인 앱 인터페이스를 위해 처음부터 만들어진 시스템은 아니었습니다.
그래서 개발자들이 브라우저 안에서 네이티브 같은 모바일 경험을 구현하려고 하면 병목이 생겼습니다.
- 레이아웃 재계산 비용
- reflow 비용
- paint 오버헤드
- 애니메이션 스케줄링 한계
- 상호작용이 많아질수록 커지는 렌더링 복잡도
쉽게 비유하면 이렇습니다. 굉장히 똑똑한 워드프로세서를 게임 엔진처럼 쓰려고 하는 느낌에 가깝습니다. 생각보다 멀리 갈 수는 있어요. 그런데 어느 순간 시스템이 본래 무엇을 위해 만들어졌는지 분명하게 드러납니다.
초기 HTML5 앱들이 겪었던 일이 그랬습니다.
큰 기업도 같은 문제를 겪었습니다
이건 스타트업만의 문제가 아니었습니다.
HTML5 한계의 대표적인 사례로 자주 언급되는 것이 Facebook의 초기 모바일 전략입니다. Facebook은 한때 HTML5를 모바일 전략의 중심에 두고, 웹 기술만으로 여러 플랫폼을 커버하려고 했습니다. 전략 자체는 이해할 만했지만, 실제 사용자 경험은 기대에 미치지 못했죠.
마크 저커버그가 “Facebook의 가장 큰 실수는 HTML5에 너무 많은 것을 건 것”이라고 말한 것도 이 맥락에서 자주 인용됩니다.
이 발언은 하나의 상징처럼 작동했습니다. 웹이 가진 전략적 약속은 분명 진짜였지만, 당시 구현 수준만으로는 네이티브 앱과 체감 품질에서 경쟁하기 어려웠다는 사실을 압축해서 보여줬으니까요.
그리고 이 맥락이 중요한 이유는, Famo.us가 공허한 문제를 푼 것이 아니라는 점을 분명히 보여주기 때문입니다. Famo.us는 당시 프론트엔드 업계가 가장 절실하게 느끼던 문제 중 하나에 대응하고 있었습니다.
문제는 개발자들이 야심이 없어서가 아니었습니다. 문제는 사용자는 애플리케이션을 원했는데, 브라우저는 여전히 문서에 최적화되어 있었다는 데 있었습니다.
우연히 렌더링 엔진을 발견해버린 스타트업
Famo.us는 처음부터 거대한 플랫폼 비전을 내세우며 시작한 프로젝트가 아니었습니다.
시작은 훨씬 현실적이었죠.
일종의 우회로였습니다.
이 팀은 원래 BenchRank라는 스타트업 서비스를 만들고 있었습니다. 대략적으로 말하면 LinkedIn과 Hot or Not을 섞은 듯한 개념이었어요. 사람 중심의 프로필과 평판, 사회적 평가 요소가 결합된 서비스였다고 보면 됩니다.
이 제품 아이디어가 시간이 지나며 매끄럽게 보이진 않을 수 있습니다. 하지만 그 과정에서 드러난 기술적 문제는 매우 현실적이었습니다. BenchRank 웹 앱을 개발하면서 이 팀 역시 대형 기업과 작은 팀들이 공통으로 겪던 HTML5 성능 문제에 부딪혔습니다.
보통은 여기서 포기하거나, 적당히 타협합니다.
그런데 이 팀은 실험을 택했습니다.
그 과정에서 흥미로운 브라우저 트릭 하나를 발견합니다. 브라우저의 CSS 3D transform 기능, 특히 matrix3d 경로를 적극적으로 활용하면, 많은 작업을 브라우저의 일반 레이아웃 엔진이 아니라 GPU 쪽으로 넘길 수 있다는 점이었죠.
이 발견이 흐름을 완전히 바꿨습니다.
이 시점부터 더 흥미로운 자산은 원래의 스타트업 서비스가 아니라, 그 서비스를 살려보려다 우연히 얻게 된 렌더링 방식이었습니다.
그래서 팀은 피벗했습니다.
사람의 평판을 다루는 서비스를 만드는 대신, 그 발견을 바탕으로 렌더링 엔진을 만들기로 한 거죠.
한편으로는 아주 전형적인 스타트업의 움직임입니다. 더 유망한 자산 쪽으로 피벗하는 것이니까요. 하지만 다른 한편으로는 꽤 이례적이기도 했습니다. 단순히 타깃 고객이나 기능을 바꾼 게 아니라, 내부에서 사용하던 성능 최적화 해법 자체를 별도의 UI 플랫폼으로 빼낸 셈이니까요.
Famo.us는 실제로 어떻게 동작했나
이제부터가 더 흥미로운 부분입니다.
Famo.us는 웹 UI를 거의 밑바닥부터 다시 생각하려 했습니다.
일반적인 웹 모델: 레이아웃은 브라우저에게 맡긴다
보통 브라우저는 많은 것을 대신 결정해줍니다.
- 요소가 어디에 놓일지
- 요소들이 어떤 흐름으로 배치될지
- 컨테이너가 자식 요소에 어떤 영향을 줄지
- 레이아웃 업데이트가 페이지 전체에 어떻게 전파될지
- 애니메이션이 렌더링 파이프라인과 어떻게 맞물릴지
이건 편리합니다.
하지만 요소가 끊임없이 움직이고, 여러 레이어가 겹치고, 인터페이스가 매우 동적으로 변해야 하는 상황에서는 비용이 커집니다.
Famo.us의 모델: UI를 공간 안의 객체처럼 다룬다
Famo.us는 전통적인 CSS 흐름 기반 레이아웃에서 벗어나, 다음과 같은 요소를 중심으로 UI를 구성하려 했습니다.
- 절대 위치 지정
- 데카르트 좌표계
- 3D transform
- 4x4 행렬
- GPU 친화적인 compositing
즉, “이 박스는 일반적인 문서 흐름 속에 있다”라고 보는 대신, 하나의 장면 안에 정확한 위치·크기·회전·움직임을 가진 객체처럼 취급한 겁니다.
그러면 각 요소의 시각적 상태는 결국 수학적 변환으로 정의됩니다.
Framework는 4x4 행렬을 계산하고, 그 값을 CSS matrix3d 속성으로 출력합니다. 브라우저는 그 행렬을 해석해 화면을 렌더링하죠.
결과적으로 레이아웃, 크기, 애니메이션은 더 이상 선언적인 CSS 박스 규칙의 문제가 아니라, 수학적 변환의 문제가 됩니다.
아주 쉽게 비유하면: 책 쌓기에서 인형극 조종으로
전통적인 CSS 레이아웃은 책을 책장에 꽂는 것과 비슷합니다. 각 요소는 주변 공간에 영향을 주고, 시스템은 순서와 흐름, 그리고 자연스럽게 들어맞는 자리를 중요하게 봅니다.
반면 Famo.us는 무대 위 인형을 줄로 조종하는 방식에 더 가깝습니다. 객체 하나하나를 원하는 위치에 놓고, 돌리고, 움직이고, 애니메이션을 주고, 전체 장면을 직접 안무하듯 설계하는 방식이죠.
제어권은 엄청나게 커집니다.
대신 이제는 당신이 안무가이자, 장치 전문가이자, 무대 엔지니어가 되어야 합니다.
왜 matrix3d가 중요했나
4x4 행렬은 3차원 공간에서 이동, 스케일, 회전, 원근감을 표현하는 데 쓰이는 수학적 구조입니다. CSS matrix3d는 이런 변환을 브라우저에 직접 전달할 수 있게 해줍니다.
Famo.us는 여기에 강하게 기댔습니다. 브라우저의 일반 레이아웃 엔진보다 변환 행렬이 더 중요해지는 구조였죠.
그 덕분에 이 Framework는 다음과 같은 장점을 노릴 수 있었습니다.
- 일부 레이아웃 오버헤드 우회
- reflow보다 compositing 중심 처리 선호
- 더 부드러운 애니메이션
- 공간감과 깊이감을 가진 UI 효과
- 페이지보다 네이티브 장면에 가까운 인터페이스 연출
어떤 종류의 인터페이스에 잘 맞았나
Famo.us는 특히 이런 인터페이스에 잘 어울렸습니다.
- 회전하며 넘어가는 카드 스택
- 깊이감이 살아 있는 레이어 전환
- 3D 공간 안에서 슬라이드·회전·겹침이 일어나는 패널
- 움직임이 많은 터치 인터페이스
- 문서형이라기보다 시네마틱한 느낌의 UI
반대로, 단순한 입력 폼과 라벨 정도만 필요한 화면이라면 다소 과한 선택이었을 겁니다.
하지만 촉각적이고, 움직임이 풍부하고, GPU를 적극 활용하는 인터페이스를 원한다면 상당히 매력적인 방식이었죠.
왜 GPU 가속이 그렇게까지 중요했나
Famo.us의 매력을 이해하려면 당시 시점을 떠올려야 합니다.
2010년대 초반이면 대부분의 소비자 기기에 이미 GPU가 들어가 있었습니다. 그렇다면 GPU 친화적인 렌더링 패턴을 제대로 활용하는 Framework는 아주 강력한 이야기를 할 수 있게 됩니다. 하나의 앱을 만들어도 여러 기기에서 잘 돌아갈 수 있다는 이야기 말이죠.
크로스플랫폼 시대에 이건 엄청 매력적이었습니다.
네이티브 앱은 플랫폼별로 따로 만들어야 했고, 웹 앱은 하나의 코드베이스로 간다는 장점이 있었죠. 다만 그 장점은 성능이 받쳐줄 때만 의미가 있었습니다.
Famo.us는 이런 식으로 말할 수 있게 해줬습니다.
“그래요, 브라우저에는 한계가 있습니다. 하지만 작업을 transform과 compositing 쪽으로 최대한 밀어 넣으면, 그 한계를 우회해서 네이티브에 가까운 부드러움을 만들 수 있지 않을까요?”
이건 기술적으로도 중요했고, 심리적으로도 중요했습니다.
표준이 천천히 따라오길 마냥 기다리지 않아도 된다는 느낌을 줬거든요. 조금은 우회하고, 조금은 밀어붙이고, 조금 더 빨리 도달할 수 있다는 가능성이었습니다.
Famo.us가 팔고 있던 건 단순한 속도가 아니었습니다. 웹이 더 이상 스스로를 변명하지 않아도 된다는 감각이었죠.
왜 개발자와 투자자가 열광했나
2026년 시점에서 보면, GPU 가속 CSS transform을 공격적으로 활용하는 접근 하나에 그렇게 큰 투자가 몰렸다는 사실이 다소 과장돼 보일 수도 있습니다.
하지만 맥락이 전부입니다.
Famo.us는 약 3,000만 달러 규모의 투자를 받은 것으로 알려져 있습니다. 이 숫자는 사람들이 이 기술이 푸는 문제를 얼마나 진지하게 봤는지를 보여줍니다.
당시에는 왜 그렇게 설득력 있었나
2012년에는 지금처럼 React가 UI의 기본 선택지로 굳어지지 않았습니다. 브라우저 compositing 최적화도 지금처럼 일반화되어 있지 않았고요. HTML5는 여전히 개척지처럼 보였고, 웹과 네이티브의 격차도 매우 선명했습니다.
무엇보다 개발자들은 성능의 돌파구를 갈망하고 있었습니다.
그래서 Famo.us는 허풍처럼 보이지 않았습니다.
새로운 모델처럼 보였죠.
그 매력은 단순히 “애니메이션을 더 빠르게 만들 수 있다”는 수준이 아니었습니다. “기존 CSS 사고방식을 통째로 버리고, 더 강력한 렌더링 패러다임으로 갈 수 있다”는 제안이었으니까요.
이건 훨씬 더 큰 이야기입니다.
웹 UI 자체를 다시 상상하게 만드는 제안이었죠.
왜 비전처럼 느껴졌나
Famo.us는 개발자들에게 이런 세계를 상상하게 했습니다.
- 웹 앱이 더 촉각적으로 느껴지는 세계
- 브라우저 UI에 진짜 공간감이 생기는 세계
- 애니메이션이 기본적으로 매끄러운 세계
- 웹이 더 이상 “2등 경험”이 아닌 세계
- 브라우저가 페이지 렌더러가 아니라 앱 런타임처럼 동작하는 세계
이런 가능성은 사람을 끌어당깁니다.
그리고 한동안은 실제로 통했습니다.
공개 지연이 모든 것을 바꿨다
Famo.us는 2012년 9월 TechCrunch Disrupt에서 처음 발표됐지만, 개발자들이 실제로 만져볼 수 있는 수준의 결과물이 나온 건 2014년 6월 무렵이었습니다.
이 간극은 치명적이었습니다.
빠르게 움직이는 플랫폼 생태계에서 2년은 굉장히 긴 시간입니다. 특히나 핵심 가치 제안이 “아직 성숙하지 않은 인프라의 한계를 보완한다”는 데 있을 때는 더 그렇습니다.
그리고 실제로 그 사이, 상황이 바뀌었습니다.
Famo.us가 준비되는 동안 브라우저가 더 좋아졌다
처음 발표된 시점부터 실제 사용 가능한 릴리스가 나오기까지, 브라우저는 꽤 많이 발전했습니다.
특히 Famo.us에게 중요했던 영역이 그렇습니다.
- GPU compositing 개선
- 애니메이션 스케줄링 개선
- transform 기반 렌더링의 보편화
- 예전에는 해킹처럼 보이던 성능 패턴이 점차 일반적인 모범 사례가 됨
즉, Famo.us를 특별하게 보이게 만들었던 트릭 일부가 점점 브라우저의 기본 상식이 되어버린 겁니다.
격차가 줄어든 거죠.
브라우저 자체가 Famo.us가 억지로 끌어내던 방식들을 조금씩 잘하게 될수록, Famo.us의 마법은 덜 특별해 보이기 시작했습니다.
“내일의 플랫폼 약점을 오늘 메우는 제품”이 겪는 저주
여기엔 꽤 아픈 교훈이 있습니다.
당신의 제품이 플랫폼의 미성숙함을 보완하기 위해 존재한다면, 결국 당신은 플랫폼 공급자와 경주하는 셈입니다. 그리고 대개 이 경주는 플랫폼 공급자가 이깁니다.
브라우저는 계속 좋아집니다. 표준은 진화합니다. 엔진은 유용한 패턴을 흡수합니다. 그 순간 한때 유일했던 장점은 생각보다 훨씬 빠르게 사라질 수 있습니다.
Famo.us에서 바로 그런 일이 벌어졌습니다.
너무 일찍 등장했기에 흥미로웠고, 동시에 너무 일찍 등장했기에 웹이 따라잡는 순간 핵심 가치가 희미해졌습니다.
우회로는 플랫폼이 같은 기술을 익히기 전까지는 혁명처럼 보일 수 있습니다.
왜 Famo.us는 결국 힘을 잃었나
Famo.us의 쇠퇴를 하나의 이유로 설명하긴 어렵습니다. 여러 변화가 겹겹이 쌓여 한 방향으로 작용했습니다.
1. 브라우저 성능 개선으로 필요성이 줄어들었다
초기 Famo.us의 가장 큰 강점은 브라우저가 아직 그 정도 성능을 잘 내지 못했다는 점이었습니다.
하지만 브라우저가 compositing과 애니메이션 처리를 개선하면서, 별도의 렌더링 전략이 꼭 필요하다는 절박함이 줄어들었습니다.
2. UI 개발 방식 자체가 바뀌었다
Famo.us가 성숙해지는 동안 프론트엔드 생태계는 필요에 따라 다른 해답들로 재편되고 있었습니다.
복잡한 3D 장면이 필요하다면 Three.js가 점점 더 자연스러운 선택지가 되었고, 일반적인 애플리케이션 UI가 필요하다면 React 같은 선언형 라이브러리가 주류가 되어갔습니다.
이 분화는 Famo.us에 치명적이었습니다.
Famo.us는 원래 애매하게 그 사이 어딘가에 있었습니다. 완전한 3D 엔진도 아니고, 전형적인 선언형 UI 라이브러리도 아니었죠. 분명 강력했지만, 자기 자리가 양쪽에서 압박받기 시작한 겁니다.
3. API가 어려웠다
이건 생각보다 훨씬 큰 문제입니다.
Famo.us는 표현력이 뛰어났고, 개발자에게 깊은 제어권을 줬고, 평범한 CSS 워크플로우로는 다루기 어려운 것들을 가능하게 해줬습니다.
하지만 그걸 잘 쓰려면 다음에 익숙해야 했습니다.
- 수학
- 모션
- 좌표계
- transform
- 브라우저 렌더링 동작
- JavaScript 자체
일반적인 UI 개발팀에게는 꽤 큰 요구사항이죠.
대부분의 프론트엔드 팀은 수학적으로 정교한 표현보다, 출시 속도와 유지보수성, 접근성, 가독성, 상태 관리, 협업, 온보딩, 디버깅 명확성을 더 중요하게 여깁니다.
Famo.us는 익숙한 추상화를 걷어내는 방식으로 더 많은 힘을 줬습니다.
기술적으로는 인상적입니다.
하지만 시장에서는 위험한 선택이기도 했죠.
4. 타이밍이 모멘텀을 죽였다
개발자들이 실제로 이 도구를 사용할 수 있게 되었을 때, 생태계는 이미 다른 방향으로 움직이고 있었습니다. 가장 뜨거운 관심을 받던 시기와 실제 채택이 가능한 시기가 맞지 않았던 거죠.
이런 타이밍 미스는 회복하기 어렵습니다.
제품 관점의 문제: 뛰어난 기술, 어려운 채택
조금 직설적으로 말해보겠습니다.
뛰어난 기술이 곧 뛰어난 제품은 아닙니다.
Famo.us에는 분명 인상적인 엔지니어링 아이디어가 있었습니다. 하지만 제품이 널리 채택되려면 순수한 기술적 능력 이상이 필요합니다.
Framework가 대규모로 성공하려면 소프트웨어를 만들고 유지하는 전체 비용을 낮춰줘야 합니다. 여기서 말하는 비용은 런타임 비용만이 아닙니다. 사람의 비용도 포함됩니다.
예를 들면 이런 것들이죠.
- 신규 개발자가 얼마나 빨리 익힐 수 있는가
- 디버깅이 얼마나 쉬운가
- 정신 모델이 얼마나 직관적인가
- 팀 단위 협업에 얼마나 잘 맞는가
- 일반적인 사용 사례와 얼마나 잘 연결되는가
- 문서와 커뮤니티 지원이 얼마나 풍부한가
- 숙련 인력을 채용하는 비용이 얼마나 드는가
이 지점들에서 Famo.us는 어려움을 겪었습니다.
높은 표현력은 종종 높은 복잡도를 동반합니다
여기에는 중요한 트레이드오프가 있습니다.
좋은 추상화는 어려운 문제를 더 단순한 인터페이스 뒤로 감춰주는 경우가 많습니다. 그런데 Famo.us는 종종 그 반대로 갔습니다. 전통적인 CSS 레이아웃을 좌표 공간 사고방식과 변환 수학으로 대체하면서, 일부 강력한 기능은 쉽게 만들었지만 많은 일상적인 작업은 오히려 더 개념적으로 어려워졌습니다.
특정한 틈새 환경에서는 그럴 만한 가치가 있습니다.
하지만 대중적 채택을 설득하기는 훨씬 어렵습니다.
왜 React가 결국 대세가 됐나
React의 부상은 이 대비를 아주 선명하게 보여줍니다.
대부분의 앱 인터페이스는 화려한 렌더링이 필요하지 않습니다. 예측 가능한 상태 처리, 재사용 가능한 컴포넌트, 이해 가능한 데이터 흐름, 확장 가능한 협업 패턴이 더 중요하죠.
React는 개발자가 UI를 렌더링하기 위해 필요한 모든 변환을 일일이 지휘하도록 만들지 않았습니다. 대신 UI가 어떤 모습이어야 하는지를 기술하게 했죠.
이 차이는 컸습니다.
정말 컸습니다.
비유하자면, Famo.us가 고성능 무대 장치였다면 React는 건축 시스템에 가까웠습니다. 그리고 대부분의 팀에게는 건축 시스템이 더 적합했습니다.
Three.js vs. Famo.us vs. React: 시장은 왜 그렇게 갈라졌나
Famo.us를 이해하는 가장 쉬운 방법 중 하나는, 시장이 결국 어떤 길을 택했는지와 비교해보는 것입니다.
풍부한 3D 인터페이스가 필요했다면: Three.js가 더 자연스러웠다
정말 복잡한 3D 경험이나 GPU를 많이 쓰는 시각 효과가 필요하다면, 개발자들은 점점 Three.js로 향했습니다. 장면, 객체, 공간 상호작용을 더 명시적으로 다룰 수 있는 도구였기 때문이죠.
진짜로 scene graph와 3D 렌더링 로직이 필요한 앱이라면, 전문화된 3D 도구가 더 자연스러운 선택이었습니다.
일반적인 애플리케이션 UI가 필요했다면: React가 더 자연스러웠다
대부분의 제품은 이런 것들이 필요합니다.
- 폼
- 내비게이션
- 테이블
- 리스트
- 버튼
- 상태 전환
- 재사용 가능한 컴포넌트
- 데이터 바인딩
이런 요구는 선언형 컴포넌트 기반 Framework와 훨씬 잘 맞습니다.
그래서 시장은 사실상 이렇게 나뉘었습니다.
- 복잡한 공간적/3D 경험은 Three.js
- 일반적인 앱 UI는 React
Famo.us는 분명 기술적 강점이 있었지만, 점점 자신의 카테고리를 방어하기 어려워졌습니다. 양쪽 모두에게 흥미롭게 보일 정도로 강력했지만, 어느 한쪽을 확실히 장악할 정도로 정렬되어 있지는 않았거든요.
이 모호함이 결국 발목을 잡았습니다.
비즈니스 관점의 문제: 왜 수익 구조가 성립하지 않았나
설령 Famo.us가 기술적으로 더 널리 채택됐다고 해도, 비즈니스 모델은 여전히 어려운 과제를 안고 있었습니다.
브라우저 레이아웃 엔진이나 렌더링 엔진과 유사한 수준의 무언가를 만들고 유지하는 일은 비쌉니다. 정말 비쌉니다.
전성기 기준으로 회사에는 약 25명 정도의 직원이 있었던 것으로 알려져 있고, 창업자는 린 스타트업 방식에 회의적이었다는 이야기도 전해집니다.
그 자체가 무조건 나쁘다는 뜻은 아닙니다. 야심에는 자원이 필요하니까요. 다만 그만큼 압박도 커집니다.
핵심 경제성이 성립하기 어려웠다
민간 기업이 플랫폼 공급자가 무료로 계속 개선하고 있는 인프라를 상업화하려고 할 때는 늘 어려움이 따릅니다.
문제를 단순하게 보면 이렇습니다.
- 브라우저는 이미 존재한다
- 브라우저 팀은 렌더링 동작을 계속 최적화한다
- 표준은 계속 진화한다
- 플랫폼 개선의 혜택은 모두가 공짜로 누린다
이런 상황에서 당신이 “플랫폼의 일시적인 약점”을 보완하는 독자적인 계층을 만든다면, 결국 둘 중 하나는 있어야 합니다.
- 압도적이고 오래 지속되는 기술 우위
- 유통, 워크플로우, 생태계 잠금효과 같은 매우 강한 비즈니스 해자
Famo.us는 둘 다 완전히 확보하지 못했습니다.
수익화 실험도 자연스럽지 않았다
회사는 이런 방식으로 수익화를 시도한 것으로 알려져 있습니다.
- 호스팅
- 모니터링
하지만 이런 시도는 렌더링 엔진이라는 핵심 이야기와 아주 자연스럽게 맞물리지는 않았습니다. 명확하고 지속 가능한 경제적 선순환 구조를 만들지 못한 거죠.
결국 렌더링 엔진에 대한 기대감이 식자, 회사는 엔지니어링 팀 전체를 정리하고 마지막으로 마케팅 사이트용 CMS로 강한 피벗을 시도합니다.
그리고 이것도 실패했습니다.
이 흐름은 꽤 많은 것을 말해줍니다.
회사가 계속 비즈니스 방향을 바꾸고 있다는 건, 핵심 기술 혁신이 끝내 안정적인 시장 정체성으로 이어지지 못했다는 뜻일 때가 많습니다.
Famo.us 방식, 단계별로 다시 보면
Famo.us는 살아남지 못했지만, 그 기술적 논리는 지금 봐도 꽤 배울 점이 있습니다. 브랜드와 과장된 기대를 걷어내고 보면 대략 이런 흐름이었다고 볼 수 있습니다.
1. 레이아웃 병목을 식별한다
첫 단계는 성능 문제가 JavaScript 때문만이 아니라, 브라우저의 렌더링 파이프라인—특히 layout, reflow, painting, 애니메이션 업데이트—에서 오는 경우가 많다는 점을 인식하는 것이었습니다.
지금도 중요한 이유: 오늘날에도 많은 팀이 프론트엔드 성능 문제를 잘못 진단합니다. Framework 오버헤드만 탓하고, layout thrash나 렌더링 비용은 놓치는 경우가 적지 않죠.
2. 문서 흐름에서 transform 중심 레이아웃으로 이동한다
브라우저의 일반적인 흐름 규칙에 모든 것을 맡기는 대신, Famo.us는 요소를 좌표로 정의되는 객체처럼 다뤘습니다.
왜 중요했나: transform 기반 렌더링은 비싼 레이아웃 재계산 비용을 줄이는 데 도움이 될 수 있었습니다.
3. UI 상태를 4x4 행렬로 표현한다
위치, 회전, 스케일, 애니메이션을 수학적으로 계산하고, 그 결과를 matrix3d로 출력했습니다.
왜 중요했나: 공간감 있는 인터페이스와 애니메이션을 GPU 친화적인 모델로 통합할 수 있었기 때문입니다.
4. 레이아웃보다 compositing에 더 의존한다
전략의 핵심은 이거였습니다. 문서 재계산은 덜 하고, transform과 compositing은 더 많이 하자.
왜 중요했나: 잘 작동하면 더 부드러운 애니메이션과 더 유려한 인터페이스를 만들 수 있었습니다.
5. 이 접근을 크로스플랫폼 UI 엔진으로 일반화한다
마지막 단계는 하나의 최적화 기법을 전체 UI 플랫폼으로 확장하는 것이었습니다.
왜 중요했나: 기술적으로 우아한 아이디어가 하나의 흐름이 되느냐, 아니면 대중에게 너무 어려운 도구로 남느냐가 여기서 갈립니다.
그리고 Famo.us는 바로 이 마지막 단계에서 흔들렸습니다.
이 이야기를 설명해주는 실제 사례들
Facebook의 HTML5 중심 모바일 전략
Facebook 사례가 중요한 이유는, 이 문제가 업계 전반의 긴장이었음을 잘 보여주기 때문입니다. 거대한 기업도 웹 기술이 주는 배포력과 크로스플랫폼 이점을 원했지만, 실제 사용자 경험은 네이티브 앱 수준에 미치지 못했습니다.
그래서 “웹을 네이티브처럼 느끼게 만드는 문제”는 더 이상 외면할 수 없는 과제가 됐죠.
BenchRank의 기술 피벗
BenchRank 사례는 스타트업이 처음 만들려던 제품보다, 살아남기 위해 몸부림치는 과정에서 얻은 내부 기술 자산이 더 가치 있어지는 경우가 있다는 점을 보여줍니다.
이런 피벗은 영리할 수 있습니다.
동시에, 그 기술 자산이 흥미롭지만 상업화가 어려울 경우 매우 위험할 수도 있습니다.
플랫폼 비즈니스로서의 Famo.us
Famo.us는 기술적 참신함과 투자자의 기대만으로는 충분하지 않다는 점을 보여줬습니다. 채택이 어렵고, 타이밍이 어긋나고, 플랫폼이 밑에서부터 따라잡아오면 아무리 뛰어난 접근이라도 모멘텀을 잃을 수 있습니다.
마지막 CMS 피벗
마케팅 사이트용 CMS로의 이동은 스타트업의 냉혹한 현실을 잘 보여줍니다. 핵심 제품 가설이 약해지면, 후속 피벗은 원래 차별화의 원천에서 점점 더 멀어지는 경우가 많습니다.
이건 대개 회사가 더 이상 확신을 확장하는 단계가 아니라, 일단 생존 가능한 수익원을 찾는 단계로 들어갔다는 신호입니다.
현대 인프라 플랫폼과의 대비
여기에는 더 큰 업계 차원의 교훈도 있습니다. 2010년대 초반 개발자들의 관심은 주로 렌더링 성능, 즉 “웹을 얼마나 네이티브처럼 보이게 만들 수 있는가”에 쏠려 있었습니다.
하지만 2026년의 대화는 훨씬 더 많이 개발 효율성과 운영 단순성으로 이동했습니다. 배포 자동화, 클라우드 비용 최적화, 인프라 추상화, 저장소 중심 설정, AI 보조 워크플로우, 사용량 기반 과금 같은 것들이죠.
그렇다고 옛 문제가 사라졌다는 뜻은 아닙니다.
개발자가 겪는 고통의 중심축이 바뀌었다는 뜻에 가깝습니다.
무게중심은 이제
“이 UI를 웹에서 믿기 어려울 정도로 좋게 만들 수 있을까?”에서
“소프트웨어를 더 적은 마찰로 더 빠르게 배포하고 운영할 수 있을까?”로 옮겨간 셈입니다.
숫자로 보는 Famo.us
몇 가지 숫자는 이 이야기를 더 선명하게 만들어줍니다.
- 약 3,000만 달러 투자 유치: 시장이 Famo.us를 단순한 호기심 이상으로 봤다는 증거
- 전성기 기준 약 25명 규모의 조직: 플랫폼 수준 기술을 만들고 유지하기 위한 상당한 운영 부담
- 2012년 9월 발표: HTML5 열기가 여전히 정점에 가까웠던 시점
- 2014년 6월 무렵 실제 사용 가능한 릴리스: 거의 2년 뒤, 이미 브라우저 환경이 꽤 변한 이후
- 최종적으로 마케팅 사이트용 CMS로 강한 피벗: 원래의 엔진 가설이 상업적 traction을 잃었다는 신호
이 숫자들은 단순한 사실 이상을 말해줍니다.
투자 규모는 문제가 진짜였다는 걸 말해줍니다.
팀 규모는 야심이 컸다는 걸 말해줍니다.
타임라인은 시장이 그 사이 움직였다는 걸 말해줍니다.
그리고 마지막 피벗은 비즈니스가 끝내 안정적인 정렬 상태를 찾지 못했다는 걸 말해줍니다.
Famo.us의 한계 — 그리고 지금도 중요한 이유
Famo.us에는 현대 팀들이 눈여겨봐야 할 구조적 약점이 몇 가지 있었습니다.
1. 장점이 플랫폼에 흡수될 수 있었다
이건 임시적인 플랫폼 약점을 기반으로 제품을 만들 때 생기는 전형적인 위험입니다. 플랫폼이 진화하면, 당신의 고유한 가치가 사라질 수 있습니다.
현대적 유사 사례로는 AI 플랫폼, 호스팅 플랫폼, 브라우저 API, Framework 툴링의 빈틈을 메우는 도구들이 비슷한 위험을 안고 있습니다.
2. 정신 모델이 너무 어려웠다
어떤 Framework를 제대로 쓰려면 수학, 모션, 물리, 렌더링 동작을 깊이 이해해야 한다면, 그 순간 대중 시장은 빠르게 좁아집니다.
오늘날에도 개념적 난이도가 지나치게 높은 개발 도구는 대체로 대중적 기본값이 되기 어렵습니다.
3. 비즈니스 모델이 기술적 매력과 분리돼 있었다
수익화 시도는 원래 제품 인사이트의 자연스러운 연장선처럼 느껴지지 않았습니다.
지금도 마찬가지입니다. 사용자가 사랑하는 가치와 수익화 방식이 자연스럽게 이어지지 않으면, 그건 전략적 위험 신호일 가능성이 높습니다.
4. 공개 시점이 모멘텀을 약화시켰다
기대감은 먼저 커졌는데 실제 사용성은 너무 늦게 따라오면, 생태계는 당신 없이 재편됩니다.
특히 AI, DevTools, 프론트엔드 인프라처럼 빠르게 움직이는 분야에서는 늦게 완벽하게 나오는 것보다, 조금 부족해도 더 일찍 나오는 편이 나을 때가 많습니다.
그렇다면 Famo.us는 정말 실패였을까?
상업적으로는 그렇다고 볼 수 있습니다.
하지만 역사적으로는 그렇게 단순하지 않습니다.
Famo.us를 그저 또 하나의 기술적 실패작으로만 보는 건 지나치게 단순한 해석입니다.
이 기술은 많은 도구들이 감히 시도조차 하지 못하는 것을 시도했습니다.
미래를 먼저 배송하려 한 거죠.
브라우저와 표준이 천천히 진화하길 기다리는 대신, 현재 브라우저의 한계 위에다 미래형 인터페이스를 먼저 만들어보려 했습니다.
“웹이 이미 우리가 바라는 플랫폼처럼 동작하도록 강제로 밀어붙일 수는 없을까?”
이건 위험합니다. 부서지기 쉽고, 비용이 많이 들고, 확장 가능성이 낮을 수도 있습니다.
하지만 산업은 종종 이런 시도 덕분에 움직입니다.
진짜 유산: 기대치를 끌어올렸다
Famo.us는 개발자들이 “웹이 어떤 감각을 줄 수 있는가”에 대해 갖는 상상력의 범위를 넓혀줬습니다.
이건 결코 작은 기여가 아닙니다.
제품은 실패할 수 있어도, 대화의 수준을 바꿀 수는 있습니다. 기대치를 끌어올릴 수 있고, 어중간한 성능을 덜 받아들이게 만들 수 있고, 더 나은 도구와 더 날카로운 요구, 더 야심찬 인터페이스를 자극할 수 있습니다.
Famo.us는 그 역할을 했습니다.
웹 인터페이스가 꼭 아래로 쌓이는 정적인 상자들의 집합일 필요는 없다는 점을 업계에 다시 상기시켰죠. 더 표현적일 수 있고, 공간감이 있을 수 있고, 유려할 수 있고, 빠를 수 있고, 촉각적으로 느껴질 수 있다는 것을 보여줬습니다.
비록 그 Framework 자체는 살아남지 못했지만, 그것이 키워놓은 기대는 분명 살아남았습니다.
가장 영향력 있는 기술이 꼭 오래 남는 기술인 것은 아닙니다. 때로는 미래가 불가피하다고 느끼게 만든 기술이 더 큰 영향을 남깁니다.
2026년의 팀들이 Famo.us에서 배울 수 있는 것
이 이야기는 단순히 흥미로운 과거사가 아닙니다. 꽤 실용적이기도 합니다.
지금도 유효한 교훈을 정리해보면 이렇습니다.
프론트엔드 개발자에게: 성능도 중요하지만, 사용성도 중요하다
기술적으로 더 뛰어난 렌더링 모델이라도, 일상적인 제품 개발을 지나치게 어렵게 만든다면 이기기 어렵습니다.
Framework를 평가할 때는 이런 질문을 던져야 합니다.
- 이게 실제 사용자 경험을 개선하는가?
- 흔한 작업을 단순화하는가, 아니면 일부 특수 사례만 강하게 만들어주는가?
- 팀이 장기적으로 유지할 수 있는 구조인가?
- 이 정신 모델은 장점인가, 부담인가?
창업자에게: 플랫폼의 빈틈만 믿고 회사를 만들지 마라
당신의 스타트업이 플랫폼이 “지금은 약하기 때문에” 존재한다면, 그 플랫폼이 강해졌을 때 무엇이 남는지 아주 냉정하게 봐야 합니다.
이런 질문이 필요합니다.
- 플랫폼이 따라잡고 나면 무엇이 여전히 가치 있는가?
- 우리의 해자는 기술인가, 워크플로우인가, 생태계인가, 브랜드인가?
- 우리는 제품을 만들고 있는가, 아니면 잠깐 열린 틈에서 relevance를 임대하고 있는가?
프로덕트 리더에게: 타이밍도 전략이다
빨리 나오는 것이 항상 옳진 않지만, 너무 일찍 맞아도 의미가 없고 너무 늦게 맞아도 창을 놓칩니다.
시장이 가장 뜨겁게 반응할 때 제품을 실제로 쓸 수 없다면, 기회를 잃을 수 있습니다. 관심은 식고, 경쟁자는 성숙해지고, 인프라는 밑에서 계속 좋아지니까요.
DevTools를 만드는 모든 사람에게: 추상화의 품질이 전부다
좋은 개발 도구는 단순히 강력한 기능을 제공하는 데서 끝나지 않습니다. 그 힘을 실제로 “쓸 수 있게” 만들어야 합니다.
즉, 인지 부하를 줄이고, 일반적인 워크플로우에 자연스럽게 녹아들고, 마법사급 전문성이 없어도 팀에게 레버리지를 줘야 합니다.
Famo.us는 분명 힘이 있었습니다.
하지만 시장은 힘보다 레버리지를 원했습니다.
큰 그림으로 보면, 왜 이 이야기가 지금도 중요한가
결국 웹은 훨씬 더 강력한 플랫폼이 되었습니다.
브라우저 compositing은 개선됐고, 스케줄링도 좋아졌고, 애니메이션도 발전했고, 렌더링 파이프라인도 성숙했고, Framework도 진화했고, 성능 도구도 좋아졌습니다. 웹과 네이티브의 격차도 예전보다는 많이 줄었죠.
그런 의미에서 Famo.us가 바라봤던 방향 자체는 틀리지 않았습니다.
그저 너무 일렀고, 너무 깨지기 쉬웠고, 지속 가능한 비즈니스로 운영하기가 어려웠을 뿐입니다.
이 차이는 중요합니다.
정말 중요합니다.
어떤 기술은 근본적으로 잘못된 방향이라 실패합니다. 하지만 Famo.us는 그런 경우가 아니었습니다. 실제로 도달할 미래를 가리키며 실패한 기술에 더 가까웠죠. 다만 그 미래 안에서 살아남을 만큼 오래 그 기회를 붙잡지는 못했습니다.
그래서 오히려 더 흥미롭습니다.
오래 남지 않는 도구들이 때때로 진보를 만듭니다.
그 도구들이 다른 모두를 더 나아지게 만들기 때문입니다.
마무리
Famo.us는 웹 역사에서 가장 야심찼던 “아슬아슬한 실패” 중 하나였습니다.
HTML5의 약속과 브라우저의 현실 사이의 간극에서 태어났고, 전통적인 CSS 레이아웃을 우회하고, 작업을 GPU 쪽으로 밀어 넣고, 웹 인터페이스를 네이티브처럼 느끼게 만들려 했습니다. 꽤 큰 투자를 받았고, 많은 주목을 끌었고, UI 렌더링에 대해 진짜로 새로운 모델을 제시했습니다.
하지만 이후 브라우저는 개선됐고, 생태계는 이동했고, React는 떠올랐고, Three.js는 자기 자리를 찾았고, API는 여전히 어려웠고, 비즈니스는 끝내 선명해지지 못했습니다. 그리고 기회의 창은 닫혔죠.
그렇다고 이 이야기를 “멋진 기술이었지만 실패한 회사” 정도로 줄여버리면 아쉽습니다.
Famo.us가 중요했던 이유는, 웹이 단순한 문서 플랫폼을 넘어설 수 있다고 업계에 도전장을 던졌기 때문입니다. 성능, 유동성, 인터페이스 야심에 대한 기대치를 끌어올렸고, 미래를 너무 일찍 배송하려 했기에 취약했지만, 바로 그 취약함이 오히려 이 기술을 더 비전 있게 만들었습니다.
모든 실패한 기술이 막다른 길은 아닙니다. 때로는 그것이 미리 보여주는 예고편일 뿐입니다.
FAQ
1. Famo.us를 아주 쉽게 설명하면 무엇인가요?
Famo.us는 전통적인 CSS 레이아웃을 최대한 우회하고, GPU 친화적인 3D transform과 행렬 기반 배치를 활용해 브라우저 앱을 네이티브 앱처럼 느끼게 만들려 했던 웹 UI Framework이자 렌더링 엔진입니다.
2. 실패했는데도 왜 Famo.us가 중요했나요?
업계의 기대치를 끌어올렸기 때문입니다. 웹이 느리고 문서 같은 경험에 머무를 필요 없이, 더 부드럽고 더 촉각적이고 더 고성능인 인터페이스를 지향할 수 있다는 걸 보여줬습니다.
3. 왜 2010년대 초반 HTML5만으로는 웹과 네이티브의 격차를 해결하지 못했나요?
표준 지원과 런타임 성능은 다른 문제였기 때문입니다. HTML5는 많은 기능을 추가했지만, 당시 브라우저 엔진의 렌더링 구조, 애니메이션 스케줄링, GPU compositing은 아직 충분히 성숙하지 않았고, 그래서 실제 사용자 경험이 네이티브 앱보다 뒤처지는 경우가 많았습니다.
4. Famo.us는 일반적인 프론트엔드 Framework와 무엇이 달랐나요?
대부분의 프론트엔드 도구는 브라우저의 일반적인 레이아웃 방식에 기대지만, Famo.us는 절대 위치 지정, 데카르트 좌표계, 3D transform 수학, CSS matrix3d 출력을 통해 레이아웃과 애니메이션을 더 직접적으로 제어했습니다.
5. Famo.us는 React에 더 가까웠나요, 아니면 Three.js에 더 가까웠나요?
애매하게 그 사이에 있었습니다. 공간감 있고 움직임이 많은 UI 철학은 Three.js와 닮은 면이 있었지만, 동시에 웹 UI 전반을 다루고자 했죠. 하지만 생태계가 성숙하면서 3D는 Three.js가, 일반적인 앱 UI는 React가 더 적합한 선택지가 됐습니다.
6. Famo.us가 힘을 잃은 가장 큰 이유는 무엇이었나요?
하나의 이유로 설명되진 않습니다. 브라우저 성능이 좋아졌고, 실제 공개가 너무 늦었고, React와 Three.js가 더 명확한 카테고리 리더가 되었고, API는 어려웠고, 비즈니스 모델도 끝내 선명해지지 못했습니다.
7. 현대 스타트업 창업자가 여기서 얻어야 할 가장 큰 교훈은 무엇인가요?
플랫폼이 약한 상태에만 기대어 회사를 만들지 말라는 점입니다. 플랫폼 공급자가 당신의 장점을 흡수할 수 있다면, 워크플로우·생태계·유통·비즈니스 모델 같은 더 강한 해자가 반드시 필요합니다.
8. Famo.us와 비슷한 현대 사례가 있을까요?
있습니다. 빠르게 발전하는 플랫폼의 단기적인 약점을 메우기 위해 존재하는 DevTools나 스타트업은 비슷한 위험을 안고 있습니다. 오늘날에는 AI 툴링, 프론트엔드 추상화 계층, 인프라 레이어, 워크플로우 자동화 제품군에서 이런 패턴을 자주 볼 수 있습니다.
'일상 > IT' 카테고리의 다른 글
| PostgreSQL 시계열 데이터 성능 저하 원인과 해결 방법 정리 (0) | 2026.04.10 |
|---|---|
| Google Stitch란 무엇인가요? AI UI/UX 디자인 도구 기능과 활용법 총정리 (0) | 2026.04.08 |
| Next.js 비디오 플레이어 만들기: 업로드, 썸네일 자동 생성, 워터마크까지 한 번에 구현하는 방법 (0) | 2026.04.05 |
| 유니코드 Zalgo 문자란? UI가 깨지는 원리와 보안 위험 완전 정리 (0) | 2026.03.21 |
| Redis란 무엇인가? 구조, 동작 원리, Persistence 전략까지 한 번에 정리 (0) | 2026.03.14 |