Arc 멤버들에게 보내는 편지
(browsercompany.substack.com)Arc 멤버들에게
- The Browser Company는 Arc에 올인했다가 갑자기 Dia라는 새로운 것을 만들기 시작함
- 겉보기에는 갑작스러워 보일 수 있음. Arc는 추진력이 있었고, 많은 사람들이 좋아했음. 그러나 내부에서는 결정이 보기보다 느리고 신중했음.
- 왜 이 회사를 시작했는지, Arc에서 얻은 교훈이 무엇인지, 어떤 일이 일어났는지, 그리고 왜 Dia가 다음 단계인지를 해명하려 함
- 무엇이 잘못되었나
- 왜 Arc를 만들게 되었나
- Arc의 부족한 부분
- Dia를 Arc에 내장하지 않은 이유
- Arc를 오픈소스화 할 것인가
- Dia를 만들며
무엇이 잘못되었나
- 모든 것을 다시 시작할 수 있다면 어떤 것을 바꿀 것인가?
-
1년 전에 Arc 개발을 그만두었을 것
- 성장, 사용자 유지, 사용 방식 등 - 우리가 내린 모든 결론은 이미 데이터에서 확인할 수 있었음
- 다만 부정하고 있었을 뿐
-
더 빨리, 더 많이 AI를 받아들였을 것
- 강박관념에 사로잡혀 있었음
- ChatGPT를 가지고 놀았지만, 그것은 업무가 아닌 순수한 호기심 때문
- 업계의 과대광고와 자신이 그것에 기여하는 방식도 싫었음
- 유행어들, 자만심이 AI에 대한 호기심에서 자신을 물러나게 만들었음
- Arc Max 출시가 얼마나 조심스러웠는지를 보면 알 수 있음
-
Act II 영상을 보면 Arc에 AI를 도입한다고 발표했으나, Arc Explore라는 프로토타입 데모만 남김.
- 이 아이디어는 Dia와 다른 AI 제품들의 방향성이 됨
- 우리가 앞서있었다는 말이 아니라, 우리의 직감은 마음이 따라잡기 전부터 AI에 있었다는 말임.
- 강박관념에 사로잡혀 있었음
-
다르게 소통했을 것
- 우리는 항상 우리의 타겟층을 많이 신경썼음.
- 어떤 때는 우리가 너무 투명했음
- 공유할 세부사항 없이 Dia를 발표한 것
- 어떤때는 투명하지 못했음
- 유저들이 물어보는 것을 알고 있었지만 답변이 너무 오래 걸리는 것
-
1년 전에 Arc 개발을 그만두었을 것
- 몇 년 전, 멘토가 책상에 이런 포스트잇을 붙였음: "진리가 너희를 자유케 하리라"(The truth will set you free)
- 가장 후회하는 것이 있다면, 이것을 더 많이 사용하지 않은 것
- 이 에세이는 우리의 진실임
- 공유하기 불편하지만, 정성을 다해 좋은 의도로 썼음을 알아주었으면 함
왜 Arc를 만들게 되었나
- 다른 질문에 답하기 위해서(왜 Dia로 방향을 바꾸었나, Arc를 오픈소스화 할 수 있을까 등) 과거 배경을 약간 알아야 함
- The Browser Company를 시작하게 된 신념 - 브라우저는 우리 삶에서 가장 중요한 소프트웨어지만 그에 맞는 관심을 받지 못하고 있음
- 2019년에도 이미 모든 것이 브라우저에서 돌아가고 있었음
- 내 와이프는 테크 분야에서 일하지 않는데도 하루종일 크롬에서 살고 있었음
- 6살 조카는 완전히 웹 앱으로 학교를 다님
- 클라우드 매출 급증, 브라우저 기반 스타트업, 브라우저 확장 프로그램을 통한 암호화폐, 새로운 경험을 제공하는 WebAssembly등 거시적인 트렌드도 모두 같은 방향을 향함
- 그때에도 가장 지배적인 OS는 윈도우나 macOS가 아니라 브라우저인 것 같았음, 그러나 크롬과 사파리는 발전하지 않았음
- 이게 우리가 Arc를 만든 이유
- 업무, 여가생활, 브라우저에서 보내는 모든 시간을 "인터넷 위의 당신의 집"처럼 만들고 싶었음
Arc의 부족한 부분
- 몇 년동안 Arc를 만들면서, 우리가 "새로움 세금(novelty tax)" 이라고 부르는 것을 마주하게 됨
- 많은 사람들이 Arc를 좋아해 줌, 일관성과 유기적인 성장의 혜택을 누림
- 그러나 대부분의 사람들에게는 Arc가 너무 달랐고, 조금의 편리함을 위해 너무 많은 것을 배워야 하는 것 같았음
-
"첫날 정체" 가 너무 심했음 - 며칠 후에도 머무른 사람들은 매니아층이었음
- 통계는 우리가 만들고 싶었던 대중적인 제품보다는 동영상 편집기같이 전문적인 부분에 특화된 도구같아 보였음
- 핵심 기능과 핵심 가치에 대해 응집력이 부족했음
- 실험적이었고, 이것이 매력이었지만, 또한 복잡성이기도 했음
- 일일 활성 사용자중 5.52% 만이 두 개 이상의 Space를 사용함
- 4.17% 만이 Github Live Folders를 포함한 Live Folders를 사용함
- 우리가 가장 좋아하는 기능 중 하나였던 캘린더 미리보기는 0.4% 였음
- 브라우저를 바꾸는 것은 큰 일임
- Arc에서 우리가 좋아했던 작은 기능들은, 어떤 사람들에게는 충분하지 않았고 대부분의 사람들에게는 받아들이기 어려웠음
- 반면에, Dia의 핵심 기능인 탭과 대화하기나 개인화 기능들은 각각 일일 활성 사용자의 40%와 37%가 사용함
- 받아들이기는 어렵지만 Arc와 Arc Search는 너무 진보적이었음
- 의미는 있었으나, 결론적으로 우리가 원하는 규모의 개선은 아니었음
- 대중적인 제품으로 성공할 수도 없었음
- 원래의 사명을 진지하게 생각했다면 진정으로 새로운 것을 만들 수 있는 기술적 돌파구가 필요했음
- 2023년에, 브라우저만큼이나 낡은 카테고리들이 위협받는 것을 보았음
- ChatGPT와 Perplexity가 Google의 자리를 위협함
- Cursor는 IDE를 재창조함
- 이 두 가지(검색 엔진과 IDE)는 사용자들이 수십 년동안 같은 방식으로 해온 것들
- 그리고 갑자기 변화를 받아들이기 시작함
- 바로 이 시점이 우리가 원했던 것 - 사용자의 방식을 바꾸고 브라우저의 진정한 재창조로 이끌 수도 있는 근본적인 변화
- 왜 그냥 Arc 사용에 돈을 받고 수익성 있는 사업을 시작하지 않았냐 묻는다면
- 만약 우리의 목표가 작고 수익성 있는 회사를 꾸려 좋은 팀과 충성스런 고객들을 만드는 것이라면, 가장 흔한 소프트웨어인 웹 브라우저의 계승자를 만들려고 시도하지조차 않았을 것임
- 우리의 목표는 항상 더 컸음: 사람들에게 진짜 영항을 줄 수 있는 좋은 소프트웨어를 만드는 것
- Arc가 부족하게 느껴진다면, 그것을 뛰어넘는 새로운 것을 만들면 되는 것 아닌가?
Dia를 Arc에 내장하지 않은 이유
- Dia와 Arc가 서로 다른 제품이라는 이해하기까지 여름 내내 고민했음
- 시작하면서, 우리는 다방면으로 Dia를 Arc를 고치기 위한 기회로 생각하고 접근함
-
새로움보다 단순함
- 일찍이 Scott Forstall은 Arc가 마치 색소폰같이 강력하지만 배우기 어렵다고 말함
- 그리고 요청함: 누구나 앉아서 연주할 수 있는 피아노처럼 만들 것
- 이것이 Dia의 아이디어임: 익숙한 인터페이스 뒤에 복잡성을 숨기는 것
-
속도는 더 이상 거래가 아님 - 기반임
- Arc는 부풀었음 - 너무 많은 것을 너무 빠르게 만들었음
- Dia를 설계 관점부터 새롭게 시작하며, 처음부터 퍼포먼스를 중시함.
- TCA와 SwiftUI를 버린 것이 Dia를 가볍고, 빠르고, 반응성있게 만들었음
-
보안을 제일 먼저, 중요하게
- Dia는 다른 종류의 제품임
- 이를 충족하기 위해 보안 엔지니어링 팀을 1명에서 5명으로 늘림
- 레드 팀, 버그 바운티, 내부 감사에 투자함
- 목표는 소규모 스타트업의 표준을 제시하는 것
-
새로움보다 단순함
- 이 모든 것들이 제품의 기초가 되어야 하는 요소들 - 사후 고려사항이 아님
- 지난 여름에 Arc 2.0이 진정한 Arc 2.0인지에 대한 경계를 넓히면서, Arc에 패치로 해결하기에는 너무 큰 단점들이 있으며 새로운 유형의 소프트웨어를 빠르게 구축하려면 새로운 유형의 기반이 필요하다는 것을 알게 됨
Arc를 오픈소스화 할 것인가
-
팩트는 이것이 복잡하다는 것임
-
Arc는 단순한 Chromium 포크가 아님
- ADK(Arc Development Kit) 라고 부르는 내부 SDK로 돌아감
- 전 iOS 엔지니어들이 네이티브 브라우저 UI를 빠르게, C++를 건드리지 않고도 프로토타이핑할 수 있게 해줌
- 그것이 많은 브라우저들이 새로운 것을 감히 시도하지 못하는 이유이기도 함
- 대가가 너무 큼, 너무 복잡함
-
ADK는 또한 Dia의 기반이기도 함
- 때문에 Arc를 언젠가는 오픈소스화 하는 것에 긍정적이지만, ADK를 오픈소스화하지 않고서는 할 수 없음
- ADK는 여전히 회사의 핵심 가치임
-
절대 안될거라는 말은 아님
- 언젠가 ADK를 공개하는 것이 우리 팀과 주주들을 위험에 빠뜨리지 않는 날이 온다면, 우리는 기쁘게 우리가 만든 것을 세상에 공개할 것임
-
또한 알아둬야 할 것: Arc를 지원 종료하려 하는 것은 아님
Dia를 만들며
- Dia는 Arc와 Arc의 단점에 대한 우리의 리액션이 아님
- 전기 조명 시대의 시작에 양초 사업에서 손을 떼는 이유를 정당화하는 에세이를 쓰는 것
- 전기 지능은 이미 있으며. 그 순간에 맞춰 우리가 만들어야 할 제품의 종류를 근본적으로 바꿔야 함
-
전통적인 브라우저들은 죽을 것, 검색 엔진과 IDE가 그랬던 것처럼
- 검색이나 코딩을 멈춰야 한다는 말이 아님
- 그저 검색이나 코딩을 하는 환경이 매우 다를 것이라는 것
- 고전 브라우저, 검색엔진, IDE가 아무리 정교하게 만들어졌다고 해도 양초처럼 느껴질 것
- 우리는 양초 사업에서 벗어나고 있고, 여러분도 그래야 함
- "그래서 The Browser Company는 더 이상 브라우저를 만들지 않는 건가요?" 그렇게 믿는 게 좋음
- 인공지능 브라우저는 웹 브라우저와는 다를 것임
- 이것을 그 어느 때보다 확신하며, 이미 세 가지 측면에서 그 변화를 목격하는 중임
-
웹 페이지는 더 이상 주 인터페이스가 아니게 될 것
- 전통적인 브라우저는 웹페이지를 불러오도록 만들어짐
- 그러나 점점, 웹페이지 - 앱, 글, 파일들은 AI 챗 인터페이스와 부르는 도구가 될 것임
- 여러 방면으로 챗 인터페이스는 이미 브라우저처럼 동작함
- 검색하고, 읽고, 생성하고, 답변함
- API, LLM, 데이터베이스와 상호작용함
- 사람들은 수 시간을 챗 인터페이스 안에서 보냄
-
웹이 사라지는 것은 아님 - 적어도 당분간은
- Figma와 New York Times의 중요성은 줄어들지 않음
- 웹페이지는 대체되지 않고 필수적인 도구로 남을 것
- 탭은 소모품이 아니라 핵심 컨텍스트임
-
새로운 인터페이스가 익숙한 인터페이스에서부터 시작됨
- 모두의 컴퓨터 사용 방식은 훨씬 빠르게 변화하고 있음
- 동시에 기존의 방식을 완전히 버리는 데는 훨씬 더 멀었음
- Cursor는 이 정설을 증명함: 작년의 획기적인 AI 앱은 AI 네이티브로 설계된 오래된 IDE였음
- OpenAI는 Codex가 작동하고 있음에도 불구하고 Windsurf를 인수하면서 이 이론을 확인함
- 다음은 AI 브라우저라고 믿고 있음
-
웹 페이지는 더 이상 주 인터페이스가 아니게 될 것
- 이것이 우리가 Dia를 만드는 이유임
- 실패하거나, 부분적으로만 성공하고 승리하지는 못할 수도 있음
- 그러나 이것에 대해서는 확신함: 5년 후에는 데스크탑에서 가장 많이 사용되는 AI 인터페이스가 과거의 기본 브라우저를 대체할 것임. 오늘날처럼 몇 개가 있을 수도 있지만 (크롬, 사파리, 엣지 등)
- 중요한 것은 다음 크롬이 지금 만들어지고 있다는 것임. 그것이 Dia이든 아니든.
개인적으로 Arc가 이슈화가 될 때 시도해 보여고 했었는데 우선 윈도우 지원이 너무 늦게 나왔고, 다운로드는 이메일을 제공한 사람들에게만 CBT 형태로 나왔고 별로 빠릿하지도 않고 브라우저 작동 방식이 햇갈려서 며칠 써보다가 말았던 기억이 나네요.
그러다 최근에 Zen 브라우저가 나와서 거기로 갈아탔습니다. Arc와 비슷한 탭 관리 방법을 가지고 있으면서도 오픈 소스였고, Firefox 기반이라 MV2 폐지에 벌벌 떨 필요도 없었고, 윈도우 지원이 바로 있다는 등의 장점이 있어서요.
""첫날 정체" 가 너무 심했음 - 며칠 후에도 머무른 사람들은 매니아층이었음"
왜냐하면 크롬이랑 별 다를게 없었으니까요. 그냥 기본으로 확장 프로그램 깔려서 나오는 크롬 느낌.
크롬에서는 물론이고 파이어폭스에서조차도 확장 프로그램 몇 개로 거의 비슷한 경험을 할 수 있습니다.
Dia 브라우저도 이때까지 공개된 정보로는 그냥 AI 딱지 붙여서 쏟아져 나오는 "새로운" 프로그램들과 다를 것이 없네요.
사실 저도 결국 크롬으로 돌아와서 뚜렷이 기억나지 않았습니다만, '이젤'같은 기능은 타 브라우저에서 그 정도로 네이티브하게 표현하지는 못할 것 같습니다. 다른 댓글에서 좋은 대화 나눠주셔서 덕분에 잘 배웠습니다. 좋은 댓글 감사드립니다.
Chrome 설치 후 직접 테스트해봤습니다.
제가 가장 핵심적인 요소라고 생각하는 기능 중 하나는 수직 탭인데, Vertical Tabs라는 확장 프로그램을 통해서 크롬에서도 사용할 수 있네요. 탭 컨트롤이나 그룹도 보여주고요. 다만 확장 프로그램인 만큼 크롬의 수평 탭 UI를 지워주진 않습니다. 별 문제야 없지만 개인적으로는 보기에 조금 거슬리긴 하네요.
Split View라는 기능은 하나의 브라우저 윈도우에서 두 개 이상의 탭을 동시에 보여주는 기능입니다. 크롬에서는 Split Screen for Google Chrome이라는 확장 프로그램이 유명한 것 같은데, 설치해서 사용해보니 선택한 비율로 윈도우를 추가로 생성, 재배치 해주네요.
Arc는 하나의 윈도우에서 2개의 탭 마치 하나의 탭처럼 보여주는 반면 이 확장 프로그램은 아예 윈도우를 2개로 만들어버리니, Split View로 보던 도중 다른 탭을 보게 될 때도 레이아웃이 그대로 유지되니 상당히 번거롭고 불편한 느낌입니다.
Space는 큰 기준으로 탭을 나누고(저는 보통 Home/Study/Work로 나눕니다) 단축키/버튼 하나로 간단하게 탭 목록을 전환하며 사용하는 기능입니다. 또한 Gmail, Calendar와 같이 모든 Space에서 접근할 수 있는 탭도 만들 수 있습니다.
크롬에 프로필 기능이 있긴 하지만, 아예 새로운 윈도우로 열릴 뿐더러 모든 프로필에서 접근 가능한 탭을 만드는 방법은 안보이네요.
또한 Space는 기본적으로 확장 프로그램과 쿠키 등을 공유하는 일종의 "큰 탭 그룹"일 뿐이고 선택적으로 확장 프로그램과 쿠키를 공유하지 않는 컨테이너로써 작동하도록 할 수 있지만, 프로필은 무조건적으로 확장 프로그램과 쿠키 등을 공유하지 않는 컨테이너로써 작동하고요.
위 기능들은 제가 Arc와 Zen 브라우저에서 가장 즐겨쓰는 기능들입니다.
제가 Zen 브라우저를 메인으로 쓰고 나서부터는 크롬을 거의 사용하지 않아 이번에 테스트 겸 짧게 써보고 작성한 거라 혹시 제가 놓친 부분이 있을 수 있다면 알려주시면 감사하겠습니다.
저도 써 보았던 기능들이네요.
저는 파이어폭스를 사용하는데 수직 탭이나 Space 기능은 기존에 사용하던 Sidebery (+ Multi account containers) 확장 하나로 충분히 커버된다는 인상이었습니다.
창 분할 기능은 이미 불편하다고 말씀하시긴 했지만 저같은 경우 OS 차원의 기능을 즐겨썼습니다. 윈도우 맥은 단축키 두세번으로 쉽게 분할 가능하고 리눅스 DE에서는 그보다도 간편하거든요.
물론 브라우저에 통합된 매끄러운 UX라고 볼 수도 있겠지만, 개인적으로는 큰 매력을 느끼진 못했습니다.
Arc나 Zen처럼 기존 브라우저에 편의 기능을 얹는 방식은 오랜 시간 브라우저를 사용하며 개인적으로 작성하고 구축한 환경에 비해 특별히 낫다고 느끼기 어려웠고요.
처음 브라우저 환경을 꾸리는 사용자에게는 좋은 출발점이 될 수도 있겠죠.
하지만 브라우저에 큰 관심이 없는 사람들은 그냥 크롬을 계속 쓸 것이고 관심 있는 사용자들은 이미 각자 최적화된 환경을 만들어놨을 겁니다.
결국 타깃 사용자층이 애매하다는 인상을 받았습니다.
저도 정말 오랫동안 크롬을 써왔지만, 제 크롬/파이어폭스에서의 사용 경험은 항상 20% 정도 부족한 느낌이었습니다.
확장 프로그램으로 최대한 제가 원하는 환경을 구성해도 불편한 점이 계속해서 있었고, 계속해서 부족한 점을 채워줄 브라우저를 찾아다니면서 깃허브에 있던 미완성 브라우저까지 직접 빌드해 사용해 보았습니다만,
Arc의 첫 경험은 완벽한 브라우저였고, Arc가 생각하는 웹 브라우징 경험에 의해서 생겨나는 새로운 기능들은 제 웹 브라우징 방식을 완전히 바꿔놓았습니다.
다만 말씀해주신 것처럼 이미 기존 브라우징 환경에 어느정도 만족하고 확장 프로그램을 사용해 본인에게 최적화된 환경을 만들어놓은 사람들에게는 Arc의 환경이 딱히 매력적이지 않을 수도 있었겠네요.
새로운 시각을 제공해주셔서 감사합니다.
브라우저는 정말 개인적인 만족이 필요한 환경이니만큼 사용자 입장에서 취향에 따라 Arc/Zen을 선택해 사용하는것은 당연한 일이라고 생각합니다.
제가 맨 처음 댓글에서 생각했던 것은 글이 제작사 내부 인원들을 위해 쓰여진 만큼 회사의 입장에서 타겟층이 어떻게 될까? 를 생각하면서 썼던 것이었는데 글이 부족했던 것 같네요.