앞으로의 또 다른 길

2001년 9월

(이 글은 차세대 소프트웨어의 상당 부분이 왜 서버 기반이 될 수 있는지, 그것이 프로그래머에게 무엇을 의미하는지, 그리고 이러한 새로운 종류의 소프트웨어가 스타트업에게 왜 큰 기회인지를 설명합니다. 이 내용은 BBN Labs에서의 강연에서 파생되었습니다.)

1995년 여름, 제 친구 로버트 모리스(Robert Morris)와 저는 스타트업을 시작하기로 결정했습니다. 당시 넷스케이프(Netscape)의 IPO를 앞둔 홍보 캠페인이 한창이었고, 언론에서는 온라인 상거래에 대한 이야기가 많았습니다. 그 당시 웹에는 손으로 직접 만든 실제 상점이 서른 개 정도 있었을 것입니다. 온라인 상점이 많아지려면 상점을 만드는 소프트웨어가 필요할 것이므로, 우리는 소프트웨어를 만들기로 했습니다.

처음 일주일 정도는 이것을 일반적인 데스크톱 애플리케이션으로 만들려고 했습니다. 그러다 어느 날, 웹 서버에서 소프트웨어를 실행하고 브라우저를 인터페이스로 사용하는 아이디어를 얻었습니다. 소프트웨어를 웹에서 작동하도록 다시 작성해 보니, 이것이 올바른 방향이라는 것이 분명해졌습니다. 소프트웨어를 서버에서 실행하도록 작성하면 사용자뿐만 아니라 우리에게도 훨씬 쉬울 것이었습니다.

이것은 좋은 계획임이 드러났습니다. 현재 야후 스토어로서, 이 소프트웨어는 약 14,000명의 사용자를 보유한 가장 인기 있는 온라인 상점 빌더입니다.

우리가 Viaweb을 시작했을 때, 소프트웨어가 서버에서 실행된다고 말하면 거의 아무도 우리가 무슨 뜻인지 이해하지 못했습니다. 1년 후 핫메일(Hotmail)이 출시되고 나서야 사람들이 이해하기 시작했습니다. 이제는 모두가 이것이 유효한 접근 방식이라는 것을 알고 있습니다. 우리가 했던 일에는 이제 이름이 있습니다: 애플리케이션 서비스 제공업체, 즉 ASP(Application Service Provider)입니다.

저는 차세대 소프트웨어의 상당 부분이 이 모델로 작성될 것이라고 생각합니다. 가장 많은 것을 잃을 수 있는 마이크로소프트(Microsoft)조차도 일부 기능을 데스크톱에서 서버로 옮기는 것이 불가피하다는 것을 아는 것 같습니다. 소프트웨어가 데스크톱에서 서버로 이동하면 개발자들에게는 매우 다른 세상이 될 것입니다. 이 글은 우리가 이 새로운 세상의 첫 방문자로서 목격한 놀라운 점들을 설명합니다. 소프트웨어가 서버로 이동하는 한, 제가 여기서 설명하는 것은 미래입니다.

다음 단계는?

데스크톱 소프트웨어 시대를 되돌아보면, 우리는 사람들이 감수했던 불편함에 놀랄 것입니다. 마치 지금 우리가 초기 자동차 소유자들이 감수했던 것에 놀라는 것처럼 말입니다. 처음 20~30년 동안은 자동차를 소유하려면 자동차 전문가여야 했습니다. 하지만 자동차는 너무나 큰 이점이었기 때문에 자동차 전문가가 아닌 많은 사람들도 자동차를 갖고 싶어 했습니다.

컴퓨터는 지금 이 단계에 있습니다. 데스크톱 컴퓨터를 소유하면, 내부에서 무슨 일이 일어나는지에 대해 원치 않는 많은 것을 배우게 됩니다. 하지만 미국 가구의 절반 이상이 컴퓨터를 소유하고 있습니다. 저희 어머니는 이메일과 계정 관리를 위해 컴퓨터를 사용하십니다. 약 1년 전, 어머니는 애플(Apple)로부터 새 운영체제 버전에 대한 할인 혜택을 제공하는 편지를 받고 당황하셨습니다. 이메일과 계정 관리를 위해 컴퓨터를 사용하려는 65세 여성이 새 운영체제를 설치하는 것에 대해 생각해야 한다는 것은 뭔가 잘못된 것입니다. 일반 사용자들은 “운영체제”라는 단어조차 몰라야 하며, “장치 드라이버”나 “패치”는 더더욱 몰라야 합니다.

이제 사용자들을 시스템 관리자가 되는 수고에서 덜어줄 또 다른 소프트웨어 제공 방식이 있습니다. 웹 기반 애플리케이션은 웹 서버에서 실행되고 웹 페이지를 사용자 인터페이스로 사용하는 프로그램입니다. 일반 사용자에게 이러한 새로운 종류의 소프트웨어는 데스크톱 소프트웨어보다 더 쉽고, 저렴하며, 이동성이 좋고, 신뢰할 수 있으며, 종종 더 강력할 것입니다.

웹 기반 소프트웨어의 경우, 대부분의 사용자는 자신이 사용하는 애플리케이션 외에는 아무것도 생각할 필요가 없을 것입니다. 모든 복잡하고 변화하는 것들은 어딘가에 있는 서버에 앉아, 그런 일에 능숙한 사람들이 유지보수할 것입니다. 따라서 소프트웨어를 사용하기 위해 컴퓨터 자체가 필요하지 않을 것입니다. 필요한 것은 키보드, 화면, 그리고 웹 브라우저가 있는 기기뿐일 것입니다. 아마도 무선 인터넷 접속 기능이 있을 수도 있습니다. 어쩌면 그것이 휴대폰일 수도 있습니다. 무엇이든 간에, 그것은 가전제품이 될 것입니다: 약 200달러 정도의 비용이 들고, 사람들이 주로 케이스의 외관을 보고 선택하는 것 말입니다. 지금 전화기처럼, 하드웨어보다 인터넷 서비스에 더 많은 비용을 지불하게 될 것입니다. [1]

클릭이 서버에 도달하고 돌아오는 데 약 0.1초가 걸릴 것이므로, 포토샵(Photoshop)과 같이 상호작용이 많은 소프트웨어 사용자들은 여전히 데스크톱에서 계산이 이루어지기를 원할 것입니다. 하지만 대부분의 사람들이 컴퓨터를 사용하는 종류의 작업을 보면, 0.1초의 지연 시간은 문제가 되지 않을 것입니다. 저희 어머니는 실제로 데스크톱 컴퓨터가 필요하지 않으며, 어머니와 같은 사람들이 많이 있습니다.

사용자를 위한 이점

제 집 근처에 “불편함보다 죽음을”이라는 범퍼 스티커가 붙은 차가 있습니다. 대부분의 사람들은 대부분의 경우 가장 적은 노력이 필요한 선택을 할 것입니다. 웹 기반 소프트웨어가 승리한다면, 그것은 더 편리하기 때문일 것입니다. 그리고 사용자뿐만 아니라 개발자에게도 그렇게 될 것으로 보입니다.

순수 웹 기반 애플리케이션을 사용하려면 인터넷에 연결된 브라우저만 있으면 됩니다. 따라서 웹 기반 애플리케이션은 어디에서든 사용할 수 있습니다. 데스크톱 컴퓨터에 소프트웨어를 설치하면 해당 컴퓨터에서만 사용할 수 있습니다. 더 나쁜 것은 파일이 해당 컴퓨터에 갇혀 있다는 것입니다. 사람들이 네트워크에 익숙해지면서 이러한 모델의 불편함은 점점 더 분명해지고 있습니다.

여기서 시작점은 웹 기반 이메일이었습니다. 이제 수백만 명의 사람들이 어디에 있든 이메일 메시지에 접근할 수 있어야 한다는 것을 깨닫고 있습니다. 이메일을 볼 수 있다면, 왜 캘린더는 안 될까요? 동료들과 문서를 논의할 수 있다면, 왜 편집할 수 없을까요? 왜 당신의 데이터가 멀리 떨어진 책상 위의 컴퓨터에 갇혀 있어야 할까요?

“당신의 컴퓨터”라는 개념은 사라지고, “당신의 데이터”로 대체되고 있습니다. 당신은 어떤 컴퓨터에서든 당신의 데이터에 접근할 수 있어야 합니다. 아니, 어떤 클라이언트에서든 말입니다. 그리고 클라이언트는 컴퓨터일 필요가 없습니다.

클라이언트는 데이터를 저장해서는 안 됩니다. 전화기처럼 되어야 합니다. 사실 전화기가 될 수도 있고, 그 반대일 수도 있습니다. 그리고 클라이언트가 작아질수록 데이터를 저장하지 않아야 할 또 다른 이유가 있습니다: 들고 다니는 것은 분실되거나 도난당할 수 있습니다. PDA를 택시에 두고 내리는 것은 디스크 충돌과 같지만, 데이터가 증발하는 대신 다른 사람에게 넘어간다는 점이 다릅니다.

순수 웹 기반 소프트웨어의 경우, 데이터도 애플리케이션도 클라이언트에 저장되지 않습니다. 따라서 사용하기 위해 아무것도 설치할 필요가 없습니다. 설치가 없으면 설치 오류에 대해 걱정할 필요도 없습니다. 소프트웨어가 운영체제에서 실행되지 않으므로 애플리케이션과 운영체제 간의 비호환성도 있을 수 없습니다.

설치가 필요 없기 때문에, 웹 기반 소프트웨어를 “구매”하기 전에 시도해 보는 것이 쉽고 흔해질 것입니다. 웹 기반 애플리케이션은 제공되는 사이트에 접속하기만 하면 무료로 시험 운전해 볼 수 있을 것이라고 예상해야 합니다. Viaweb에서는 우리 사이트 전체가 사용자들을 시험 운전으로 안내하는 큰 화살표와 같았습니다.

데모를 시도한 후, 서비스 가입은 간단한 양식(간단할수록 좋음)을 작성하는 것 이상을 요구해서는 안 됩니다. 그리고 그것이 사용자가 해야 할 마지막 작업이어야 합니다. 웹 기반 소프트웨어의 경우, 추가 비용을 지불하거나 어떤 작업도 하지 않고, 어쩌면 알지도 못한 채 새 릴리스를 받아야 합니다.

업그레이드는 지금처럼 큰 충격이 아닐 것입니다. 시간이 지남에 따라 애플리케이션은 조용히 더 강력해질 것입니다. 이는 개발자들의 노력이 필요할 것입니다. 사용자들을 혼란시키지 않으면서 업데이트될 수 있도록 소프트웨어를 설계해야 할 것입니다. 그것은 새로운 문제이지만, 해결 방법이 있습니다.

웹 기반 애플리케이션의 경우, 모든 사람이 동일한 버전을 사용하며, 버그는 발견되는 즉시 수정될 수 있습니다. 따라서 웹 기반 소프트웨어는 데스크톱 소프트웨어보다 훨씬 적은 버그를 가질 것입니다. Viaweb에서는 한 번에 10개 이상의 알려진 버그가 있었던 적이 거의 없었던 것 같습니다. 이는 데스크톱 소프트웨어보다 몇 배나 나은 수준입니다.

웹 기반 애플리케이션은 여러 사람이 동시에 사용할 수 있습니다. 이는 협업 애플리케이션에 명백한 이점이지만, 사용자들이 이것이 가능하다는 것을 깨닫는 순간 대부분의 애플리케이션에서 이를 원하기 시작할 것이라고 확신합니다. 예를 들어, 두 사람이 같은 문서를 편집하는 것이 유용할 때가 많을 것입니다. Viaweb은 여러 사용자가 동시에 사이트를 편집할 수 있도록 했는데, 이는 사용자들이 원할 것이라고 예상해서라기보다는 소프트웨어를 작성하는 올바른 방식이었기 때문이었지만, 많은 사용자들이 실제로 원했습니다.

웹 기반 애플리케이션을 사용하면 데이터가 더 안전할 것입니다. 디스크 충돌이 과거의 일이 되지는 않겠지만, 사용자들은 더 이상 그것에 대해 듣지 못할 것입니다. 그것은 서버 팜 내에서 일어날 것입니다. 그리고 웹 기반 애플리케이션을 제공하는 회사들은 실제로 백업을 할 것입니다. 이는 실제 시스템 관리자들이 그런 일에 대해 걱정할 것이기 때문일 뿐만 아니라, 사람들의 데이터를 잃어버리는 ASP는 매우, 매우 큰 문제에 직면할 것이기 때문입니다. 사람들이 디스크 충돌로 자신의 데이터를 잃어버리면, 화낼 대상이 자기 자신밖에 없기 때문에 그렇게 화를 내지 못합니다. 회사가 그들을 위해 데이터를 잃어버리면, 그들은 훨씬 더 화를 낼 것입니다.

마지막으로, 웹 기반 소프트웨어는 바이러스에 덜 취약해야 합니다. 클라이언트가 브라우저 외에는 아무것도 실행하지 않는다면, 바이러스를 실행할 가능성이 적고, 로컬에 손상될 데이터도 없습니다. 그리고 서버 자체를 공격하는 프로그램은 서버가 매우 잘 방어되어 있음을 알게 될 것입니다. [2]

사용자에게 웹 기반 소프트웨어는 스트레스가 덜할 것입니다. 평균적인 윈도우(Windows) 사용자 내부를 들여다보면, 그러한 설명에 부합하는 소프트웨어에 대한 거대하고 거의 미개발된 욕구가 있을 것이라고 생각합니다. 이것이 해방되면 강력한 힘이 될 수 있습니다.

코드의 도시

개발자에게 웹 기반 소프트웨어와 데스크톱 소프트웨어의 가장 눈에 띄는 차이점은 웹 기반 애플리케이션이 단일 코드 조각이 아니라는 것입니다. 그것은 단일한 큰 바이너리(binary)가 아니라 다양한 유형의 프로그램들의 모음이 될 것입니다. 따라서 웹 기반 소프트웨어를 설계하는 것은 건물을 설계하는 것보다 도시를 설계하는 것과 같습니다: 건물뿐만 아니라 도로, 도로 표지판, 공공시설, 경찰 및 소방서, 그리고 성장과 다양한 종류의 재난에 대한 계획이 필요합니다.

Viaweb에서 소프트웨어는 사용자들이 직접 대화하는 상당히 큰 애플리케이션, 그 프로그램들이 사용하는 프로그램, 문제 발생 여부를 끊임없이 백그라운드에서 확인하는 프로그램, 고장 나면 다시 시작하려고 시도하는 프로그램, 통계를 컴파일하거나 검색을 위한 인덱스를 구축하기 위해 가끔 실행되는 프로그램, 리소스를 가비지 컬렉션하거나 데이터를 이동 또는 복원하기 위해 명시적으로 실행하는 프로그램, 사용자 행세를 하는 프로그램(성능 측정 또는 버그 노출용), 네트워크 문제 진단 프로그램, 백업 프로그램, 외부 서비스 인터페이스, 실시간 서버 통계를 표시하는 인상적인 다이얼 컬렉션을 구동하는 소프트웨어(방문객들에게는 인기가 있었지만 우리에게도 필수적이었음), 오픈 소스 소프트웨어의 수정 사항(버그 수정 포함), 그리고 수많은 구성 파일과 설정들을 포함했습니다. 트레버 블랙웰(Trevor Blackwell)은 우리가 야후에 인수된 후, 상점을 전국에 걸쳐 새로운 서버로 종료 없이 이동시키는 환상적인 프로그램을 작성했습니다. 프로그램들은 우리에게 호출을 보내고, 사용자에게 팩스와 이메일을 보내고, 신용카드 처리업체와 거래를 수행하고, 소켓(sockets), 파이프(pipes), HTTP 요청, SSH, UDP 패킷, 공유 메모리, 그리고 파일을 통해 서로 통신했습니다. Viaweb의 일부는 프로그램의 부재로 구성되기도 했습니다. 유닉스(Unix) 보안의 핵심 중 하나는 사람들이 서버에 침입하는 데 사용할 수 있는 불필요한 유틸리티를 실행하지 않는 것이기 때문입니다.

소프트웨어로 끝나지 않았습니다. 우리는 서버 구성에 대해 많은 시간을 생각했습니다. 우리는 부품으로 서버를 직접 구축했습니다. 부분적으로는 비용을 절약하기 위해서였고, 부분적으로는 우리가 원하는 것을 정확히 얻기 위해서였습니다. 우리는 상위 ISP가 모든 백본에 충분히 빠른 연결을 가지고 있는지 고려해야 했습니다. 우리는 RAID 공급업체와 연쇄적으로 데이트했습니다.

하지만 하드웨어는 단지 걱정거리만은 아닙니다. 하드웨어를 제어하면 사용자에게 더 많은 것을 제공할 수 있습니다. 데스크톱 애플리케이션의 경우, 특정 최소 하드웨어를 지정할 수 있지만, 더 추가할 수는 없습니다. 서버를 관리하면, 관련 하드웨어를 설치하는 한 단계만으로 모든 사용자가 사람들에게 호출을 보내거나, 팩스를 보내거나, 전화로 명령을 보내거나, 신용카드를 처리하는 등의 작업을 할 수 있도록 할 수 있습니다. 우리는 항상 하드웨어로 기능을 추가하는 새로운 방법을 찾았습니다. 이는 사용자들을 기쁘게 할 뿐만 아니라, (데스크톱 소프트웨어를 판매하거나 ISP를 통해 웹 기반 애플리케이션을 재판매하여) 하드웨어를 직접 제어할 수 없는 경쟁업체와 차별화하는 방법이기도 했습니다.

웹 기반 애플리케이션의 소프트웨어는 단일 바이너리가 아니라 프로그램들의 모음이므로, 여러 다른 언어로 작성될 수 있습니다. 데스크톱 소프트웨어를 작성할 때는 기본 운영체제와 동일한 언어, 즉 C와 C++로 애플리케이션을 작성해야만 합니다. 그래서 이 언어들(특히 관리자나 VC와 같은 비기술적인 사람들 사이에서)은 “진지한” 소프트웨어 개발을 위한 언어로 간주되었습니다. 하지만 그것은 단지 데스크톱 소프트웨어가 제공되어야 하는 방식의 부산물일 뿐이었습니다. 서버 기반 소프트웨어의 경우, 원하는 어떤 언어든 사용할 수 있습니다. [3] 오늘날 많은 최고의 해커들은 C와 C++에서 멀리 떨어진 언어들, 즉 펄(Perl), 파이썬(Python), 심지어 리스프(Lisp)를 사용하고 있습니다.

서버 기반 소프트웨어의 경우, 당신이 하드웨어까지 시스템 전체를 제어하기 때문에 아무도 어떤 언어를 사용해야 할지 말할 수 없습니다. 다른 언어는 다른 작업에 적합합니다. 각 작업에 가장 적합한 언어를 사용할 수 있습니다. 그리고 경쟁자가 있다면, “할 수 있다”는 “해야 한다”는 의미가 됩니다(이것은 나중에 다시 다루겠습니다). 왜냐하면 당신이 이 가능성을 활용하지 않으면, 경쟁자들이 활용할 것이기 때문입니다.

우리 경쟁자들 대부분은 C와 C++를 사용했고, 이로 인해 그들의 소프트웨어는 눈에 띄게 열등했습니다. (다른 이유도 있지만) 그들은 CGI 스크립트의 상태 없음(statelessness)을 우회할 방법이 없었기 때문입니다. 무언가를 변경하려면 모든 변경 사항이 한 페이지에서 이루어져야 했고, 하단에 업데이트 버튼이 있었습니다. 제가 다른 곳에서 썼듯이, 많은 사람들이 여전히 연구 언어로 간주하는 리스프를 사용하여 Viaweb 편집기를 데스크톱 소프트웨어처럼 작동하게 만들 수 있었습니다.

릴리스

이 새로운 세상에서 가장 중요한 변화 중 하나는 릴리스를 하는 방식입니다. 데스크톱 소프트웨어 사업에서는 릴리스를 하는 것이 엄청난 고통이며, 회사 전체가 하나의 거대한 코드 조각을 내보내기 위해 땀 흘리고 애씁니다. 그 과정과 결과물 모두에 대해 명백한 비교가 떠오릅니다.

서버 기반 소프트웨어의 경우, 마치 자신을 위해 프로그램을 작성하는 것처럼 거의 즉시 변경할 수 있습니다. 가끔 발생하는 큰 폭발 대신 일련의 점진적인 변경으로 소프트웨어를 릴리스합니다. 일반적인 데스크톱 소프트웨어 회사는 1년에 한두 번 릴리스를 할 수 있습니다. Viaweb에서는 종종 하루에 3~5번 릴리스를 했습니다.

이 새로운 모델로 전환하면, 소프트웨어 개발이 릴리스 방식에 얼마나 많은 영향을 받는지 깨닫게 됩니다. 데스크톱 소프트웨어 사업에서 볼 수 있는 가장 심각한 문제들 중 상당수는 릴리스의 치명적인 특성 때문입니다.

1년에 한 번만 새 버전을 릴리스하면, 버그를 대량으로 처리하는 경향이 있습니다. 릴리스 날짜 한참 전에 코드의 절반이 뜯겨나가고 교체된 새 버전을 조립하여 수많은 버그를 도입합니다. 그런 다음 QA 팀이 투입되어 버그를 세기 시작하고, 프로그래머들은 목록을 따라 내려가며 버그를 수정합니다. 그들은 일반적으로 목록의 끝에 도달하지 못하며, 사실 아무도 끝이 어디인지 확신하지 못합니다. 연못에서 잔해를 낚아 올리는 것과 같습니다. 소프트웨어 내부에서 무슨 일이 일어나는지 결코 제대로 알 수 없습니다. 기껏해야 통계적인 정확성을 얻게 됩니다.

서버 기반 소프트웨어의 경우, 대부분의 변경은 작고 점진적입니다. 그 자체로 버그를 유발할 가능성이 적습니다. 또한 소프트웨어를 릴리스하기 전에 가장 신중하게 테스트해야 할 것이 무엇인지 알 수 있습니다: 마지막으로 변경한 것입니다. 코드를 훨씬 더 확고하게 파악하게 됩니다. 일반적으로 코드 내부에서 무슨 일이 일어나는지 알고 있습니다. 물론 소스 코드를 외우지는 않겠지만, 소스를 읽을 때는 탐정이 미스터리를 풀려고 하는 것처럼이 아니라 조종사가 계기판을 스캔하는 것처럼 읽습니다.

데스크톱 소프트웨어는 버그에 대한 일종의 숙명론을 낳습니다. 버그가 가득한 것을 출시하고 있다는 것을 알고 있으며, 심지어 이를 보완하기 위한 메커니즘(예: 패치 릴리스)도 설정해 두었습니다. 그렇다면 몇 개의 버그가 더 있다고 걱정할 필요가 있을까요? 곧 당신은 망가진 것을 아는 기능 전체를 릴리스하게 됩니다. 애플은 올해 초에 이렇게 했습니다. 그들은 이미 네 번이나 연기된 새 OS를 출시해야 한다는 압박을 느꼈지만, 일부 소프트웨어(CD 및 DVD 지원)는 준비되지 않았습니다. 해결책은? 미완성 부분을 제외하고 OS를 릴리스했고, 사용자들은 나중에 그것들을 설치해야 할 것입니다.

웹 기반 소프트웨어의 경우, 작동하기 전에 소프트웨어를 릴리스할 필요가 없으며, 작동하는 즉시 릴리스할 수 있습니다.

업계 베테랑은 이렇게 생각할 수 있습니다. 작동하기 전에 소프트웨어를 릴리스할 필요가 없다는 말은 그럴듯하게 들리지만, 특정 날짜까지 새 버전을 제공하기로 약속했을 때는 어떻게 되는가? 웹 기반 소프트웨어의 경우, 그런 약속을 하지 않을 것입니다. 버전이 없기 때문입니다. 소프트웨어는 점진적이고 지속적으로 변화합니다. 일부 변경은 다른 변경보다 클 수 있지만, 버전이라는 개념은 웹 기반 소프트웨어에 자연스럽게 들어맞지 않습니다.

Viaweb을 기억하는 사람이라면 이것이 이상하게 들릴 수 있습니다. 우리는 항상 새 버전을 발표했기 때문입니다. 이것은 전적으로 홍보 목적으로 이루어졌습니다. 우리는 업계 언론이 버전 번호로 생각한다는 것을 알게 되었습니다. 그들은 주요 릴리스(버전 번호의 첫 자리가 바뀌는 것)에 대해서는 대대적인 보도를 해주고, 일반적으로 포인트 릴리스(소수점 이하의 숫자가 바뀌는 것)에 대해서는 기껏해야 한 단락 정도만 보도합니다.

우리 경쟁자들 중 일부는 데스크톱 소프트웨어를 제공하고 있었고 실제로 버전 번호를 가지고 있었습니다. 그리고 이러한 릴리스에 대해, 우리에게는 그들의 후진성을 증명하는 것처럼 보였던 단순한 사실만으로도 온갖 홍보를 얻었습니다. 우리는 놓치고 싶지 않아서 우리 소프트웨어에도 버전 번호를 부여하기 시작했습니다. 홍보가 필요할 때, 우리는 마지막 “릴리스” 이후 추가한 모든 기능 목록을 만들고, 소프트웨어에 새 버전 번호를 붙이고, 새 버전이 즉시 사용 가능하다고 보도 자료를 배포했습니다. 놀랍게도 아무도 우리에게 이의를 제기하지 않았습니다.

우리가 인수될 때까지 우리는 이것을 세 번 했고, 그래서 우리는 버전 4였습니다. 제가 기억하기로는 버전 4.1이었습니다. Viaweb이 야후 스토어가 된 후에는 홍보에 대한 절박한 필요성이 사라졌기 때문에, 소프트웨어는 계속 진화했지만 버전 번호라는 개념은 조용히 사라졌습니다.

버그

웹 기반 소프트웨어의 또 다른 주요 기술적 이점은 대부분의 버그를 재현할 수 있다는 것입니다. 사용자 데이터가 디스크에 바로 있습니다. 누군가 소프트웨어를 망가뜨리면, 데스크톱 소프트웨어처럼 무슨 일이 일어나는지 추측할 필요가 없습니다. 사용자가 전화 통화 중일 때 오류를 재현할 수 있어야 합니다. 애플리케이션에 오류 감지 코드가 내장되어 있다면 이미 알고 있을 수도 있습니다.

웹 기반 소프트웨어는 24시간 내내 사용되므로, 당신이 하는 모든 일은 즉시 시험대에 오릅니다. 버그는 빠르게 나타납니다.

소프트웨어 회사들은 때때로 사용자에게 소프트웨어 디버깅을 맡긴다는 비난을 받습니다. 그리고 그것이 바로 제가 주장하는 바입니다. 웹 기반 소프트웨어의 경우 실제로 좋은 계획입니다. 버그가 더 적고 일시적이기 때문입니다. 소프트웨어를 점진적으로 릴리스하면 처음부터 버그가 훨씬 적습니다. 그리고 오류를 재현하고 변경 사항을 즉시 릴리스할 수 있다면, 버그가 나타나는 즉시 대부분의 버그를 찾아 수정할 수 있습니다. 우리는 공식적인 버그 추적 시스템을 사용할 만큼 한 번에 많은 버그를 가진 적이 없었습니다.

물론 변경 사항을 릴리스하기 전에 테스트해야 하므로, 주요 버그는 릴리스되지 않아야 합니다. 불가피하게 빠져나가는 소수의 버그는 경계선 사례와 관련될 것이며, 누군가 불평하기 위해 전화하기 전에 그것을 접하는 소수의 사용자에게만 영향을 미칠 것입니다. 버그를 즉시 수정하는 한, 일반 사용자에게는 훨씬 적은 버그가 발생할 것입니다. 평균적인 Viaweb 사용자가 버그를 본 적이 있는지 의심스럽습니다.

새로 생긴 버그를 고치는 것이 오래된 버그를 고치는 것보다 쉽습니다. 방금 작성한 코드에서 버그를 찾는 것은 보통 상당히 빠릅니다. 버그가 나타나면 소스를 보기도 전에 무엇이 잘못되었는지 아는 경우가 많습니다. 무의식적으로 이미 걱정하고 있었기 때문입니다. 6개월 전에 작성한 코드(1년에 한 번 릴리스하는 경우의 평균)에서 버그를 고치는 것은 훨씬 더 많은 작업입니다. 그리고 코드를 잘 이해하지 못하기 때문에, 지저분한 방식으로 고치거나 더 많은 버그를 도입할 가능성이 높습니다. [4]

버그를 일찍 잡으면 복합 버그도 줄어듭니다. 복합 버그는 두 개의 별개 버그가 상호작용하는 것입니다: 계단을 내려가다 넘어지는데, 난간을 잡으려 하자 난간이 손에 떨어져 나가는 것과 같습니다. 소프트웨어에서 이러한 종류의 버그는 찾기 가장 어렵고, 또한 최악의 결과를 초래하는 경향이 있습니다. [5] 전통적인 “모든 것을 망가뜨린 다음 버그를 걸러내는” 접근 방식은 본질적으로 많은 복합 버그를 낳습니다. 그리고 일련의 작은 변경으로 릴리스되는 소프트웨어는 본질적으로 그렇지 않은 경향이 있습니다. 바닥은 나중에 무언가에 걸릴 수 있는 느슨한 물건들을 끊임없이 쓸어내어 깨끗하게 유지됩니다.

함수형 프로그래밍이라는 기술을 사용하면 도움이 됩니다. 함수형 프로그래밍은 부작용(side-effects)을 피하는 것을 의미합니다. 상업용 소프트웨어보다는 연구 논문에서 더 많이 볼 수 있는 것이지만, 웹 기반 애플리케이션에는 정말 유용하다는 것이 밝혀졌습니다. 전체 프로그램을 순수 함수형 코드로 작성하는 것은 어렵지만, 상당한 부분을 이런 방식으로 작성할 수 있습니다. 이렇게 하면 소프트웨어의 해당 부분을 테스트하기가 더 쉬워집니다. 상태가 없기 때문이며, 이는 작은 수정 사항을 끊임없이 만들고 테스트하는 상황에서 매우 편리합니다. 저는 Viaweb 편집기의 많은 부분을 이 스타일로 작성했으며, 우리의 스크립팅 언어인 RTML을 순수 함수형 언어로 만들었습니다.

데스크톱 소프트웨어 업계 사람들은 이것을 믿기 어려워할 것입니다. 하지만 Viaweb에서는 버그가 거의 게임처럼 되었습니다. 대부분의 릴리스된 버그는 경계선 사례와 관련되어 있었기 때문에, 그것을 접한 사용자들은 고급 사용자, 즉 한계를 넘어서는 사용자들이었습니다. 고급 사용자들은 버그에 대해 더 관대합니다. 특히 당신이 그들이 요구하던 기능을 추가하는 과정에서 버그를 도입했을 가능성이 높기 때문입니다. 사실, 버그가 드물고 그것을 보려면 정교한 작업을 해야 했기 때문에, 고급 사용자들은 버그를 발견하는 것을 종종 자랑스러워했습니다. 그들은 화보다는 승리의 정신으로 지원팀에 전화했고, 마치 우리에게 점수를 딴 것처럼 말했습니다.

지원

오류를 재현할 수 있으면 고객 지원에 대한 접근 방식이 바뀝니다. 대부분의 소프트웨어 회사에서 지원은 고객의 기분을 좋게 하기 위한 방법으로 제공됩니다. 그들은 알려진 버그에 대해 전화하거나, 단순히 무언가를 잘못하고 있어서 당신이 무엇이 잘못되었는지 알아내야 합니다. 어느 경우든 그들로부터 배울 수 있는 것은 많지 않습니다. 그래서 당신은 지원 전화를 개발자들로부터 가능한 한 격리하고 싶은 귀찮은 일로 여기는 경향이 있습니다.

Viaweb에서는 그렇지 않았습니다. Viaweb에서는 지원이 무료였습니다. 고객의 의견을 듣고 싶었기 때문입니다. 누군가 문제가 있다면, 우리는 즉시 그것을 알고 싶었습니다. 그래야 오류를 재현하고 수정 사항을 릴리스할 수 있었기 때문입니다.

그래서 Viaweb에서는 개발자들이 항상 지원팀과 긴밀하게 연락했습니다. 고객 지원 담당자들은 프로그래머들로부터 약 30피트 떨어져 있었고, 진정한 버그 보고가 있으면 언제든지 모든 것을 중단시킬 수 있다는 것을 알고 있었습니다. 우리는 심각한 버그를 고치기 위해 이사회 회의를 떠나기도 했습니다.

우리의 지원 방식은 모두를 더 행복하게 만들었습니다. 고객들은 기뻐했습니다. 지원 라인에 전화해서 중요한 소식을 가져온 사람처럼 대우받는 기분을 상상해 보십시오. 고객 지원 담당자들은 사용자들에게 스크립트를 읽어주는 대신 도움을 줄 수 있다는 점을 좋아했습니다. 그리고 프로그래머들은 모호한 간접 보고만 듣는 대신 버그를 재현할 수 있다는 점을 좋아했습니다.

버그를 즉시 수정하는 우리의 정책은 고객 지원 담당자와 해커 간의 관계를 변화시켰습니다. 대부분의 소프트웨어 회사에서 지원 담당자는 저임금의 인간 방패이며, 해커는 세상의 창조주인 하느님 아버지의 작은 복사본입니다. 버그 보고 절차가 무엇이든 간에, 그것은 일방적일 가능성이 높습니다: 버그에 대해 듣는 지원 담당자는 결국 (아마도 QA를 통해) 프로그래머에게 전달되는 양식을 작성하고, 프로그래머는 그것을 할 일 목록에 올립니다. Viaweb에서는 매우 달랐습니다. 고객으로부터 버그에 대해 들은 지 1분 이내에 지원 담당자는 프로그래머 옆에 서서 “젠장, 당신 말이 맞아, 버그야”라는 말을 들을 수 있었습니다. 해커들로부터 “당신 말이 맞아”라는 말을 듣는 것은 지원 담당자들을 기쁘게 했습니다. 그들은 방금 죽인 쥐를 가져오는 고양이처럼 기대에 찬 표정으로 우리에게 버그를 가져오곤 했습니다. 또한 그들의 명예가 걸려 있었기 때문에 버그의 심각성을 판단하는 데 더 신중해졌습니다.

우리가 야후에 인수된 후, 고객 지원 담당자들은 프로그래머들로부터 멀리 떨어져 이동했습니다. 그때서야 우리는 그들이 사실상 QA였고 어느 정도는 마케팅 역할도 했다는 것을 깨달았습니다. 버그를 잡는 것 외에도, 그들은 사용자들을 혼란스럽게 하는 기능과 같은 모호하고 버그 같은 것들에 대한 지식의 수호자였습니다. [6] 그들은 또한 일종의 대리 포커스 그룹이었습니다. 우리는 그들에게 두 가지 새로운 기능 중 어떤 것을 사용자들이 더 원하는지 물어볼 수 있었고, 그들은 항상 옳았습니다.

사기

소프트웨어를 즉시 릴리스할 수 있다는 것은 큰 동기 부여가 됩니다. 종종 출근길에 소프트웨어에 적용하고 싶은 변경 사항이 떠올랐고, 그날 바로 실행했습니다. 이것은 더 큰 기능에도 적용되었습니다. 어떤 것을 작성하는 데 2주가 걸리더라도(더 오래 걸리는 프로젝트는 거의 없었음), 완료되는 즉시 소프트웨어에서 그 효과를 볼 수 있다는 것을 알았습니다.

다음 릴리스를 위해 1년을 기다려야 했다면, 적어도 한동안은 이 아이디어들 대부분을 보류했을 것입니다. 하지만 아이디어는 더 많은 아이디어로 이어진다는 점입니다. 무언가를 쓰기 위해 앉았을 때, 결국 그 안에 들어가는 아이디어의 절반이 글을 쓰는 동안 떠올랐다는 것을 알아차린 적이 있습니까? 소프트웨어에서도 마찬가지입니다. 하나의 아이디어를 구현하기 위해 노력하면 더 많은 아이디어가 떠오릅니다. 따라서 아이디어를 보류하는 것은 그것을 구현하는 데 드는 지연뿐만 아니라, 그것을 구현함으로써 이어졌을 모든 아이디어를 잃게 만듭니다. 사실, 아이디어를 보류하는 것은 새로운 아이디어를 억제할 수도 있습니다: 새로운 기능을 생각하기 시작할 때, 선반을 보고 “하지만 다음 릴리스를 위해 하고 싶은 새로운 것들이 이미 많이 있어”라고 생각하게 됩니다.

대기업이 기능을 구현하는 대신 하는 일은 계획하는 것입니다. Viaweb에서는 때때로 이 문제로 어려움을 겪었습니다. 투자자와 분석가들은 우리에게 미래에 무엇을 계획하고 있는지 물었습니다. 솔직한 대답은, 우리는 어떤 계획도 없었다는 것이었을 것입니다. 우리는 개선하고 싶은 것들에 대한 일반적인 아이디어는 있었지만, 어떻게 해야 할지 알았다면 이미 했을 것입니다. 다음 6개월 동안 무엇을 할 것인가? 가장 큰 이득이 될 만한 것이 무엇이든 할 것입니다. 제가 감히 이런 대답을 했는지 모르겠지만, 그것이 진실이었습니다. 계획은 선반에 놓인 아이디어의 또 다른 이름일 뿐입니다. 좋은 아이디어가 떠오르면, 우리는 그것을 구현했습니다.

Viaweb에서는 많은 소프트웨어 회사와 마찬가지로 대부분의 코드에는 명확한 소유자가 있었습니다. 하지만 무언가를 소유하면 정말로 소유한 것이었습니다: 소프트웨어 소유자 외에는 아무도 릴리스를 승인(또는 심지어 알 필요도)할 필요가 없었습니다. 고장으로부터의 보호는 동료들에게 바보처럼 보일까 봐 두려워하는 것 외에는 없었지만, 그것만으로도 충분했습니다. 제가 마치 우리가 무심하게 코드를 작성하며 나아갔다는 인상을 주었을 수도 있습니다. 우리는 빠르게 진행했지만, 소프트웨어를 서버에 릴리스하기 전에 매우 신중하게 생각했습니다. 그리고 느리게 움직이는 것보다 주의를 기울이는 것이 신뢰성에 더 중요합니다. 해군 조종사는 주의를 기울이기 때문에, 밤에 흔들리는 항공모함 갑판에 시속 140마일로 40,000파운드짜리 항공기를 평균적인 십대보다 더 안전하게 착륙시킬 수 있습니다.

이러한 소프트웨어 작성 방식은 물론 양날의 검입니다. 좋은, 신뢰할 수 있는 소규모 프로그래머 팀에게는 훨씬 더 잘 작동하지만, 나쁜 아이디어가 아이디어를 낸 사람이 아닌 위원회에 의해 걸러지는 평범한 프로그래머들로 구성된 대기업에는 그렇지 않을 것입니다.

브룩스의 역설

다행히도 웹 기반 소프트웨어는 더 적은 프로그래머를 필요로 합니다. 저는 한때 전체 엔지니어링 부서에 100명 이상의 직원이 있는 중견 데스크톱 소프트웨어 회사에서 일했습니다. 이 중 제품 개발에 종사하는 사람은 13명뿐이었습니다. 나머지는 모두 릴리스, 포팅 등에 종사했습니다. 웹 기반 소프트웨어의 경우, 릴리스, 포팅 등이 없기 때문에 (최대) 13명만 있으면 됩니다.

Viaweb은 단 세 명의 사람이 작성했습니다. [7] 우리는 인수되기를 원했고, 구매자들이 프로그래머가 세 명뿐인 회사에 높은 가격을 지불하기 어려워할 것이라는 것을 알았기 때문에, 항상 더 많은 사람을 고용하라는 압력을 받았습니다. (해결책: 우리는 더 많은 사람을 고용했지만, 그들을 위해 새로운 프로젝트를 만들었습니다.)

더 적은 프로그래머로 소프트웨어를 작성할 수 있다면, 돈 이상의 것을 절약할 수 있습니다. 프레드 브룩스(Fred Brooks)가 _맨먼스 미신(The Mythical Man-Month)_에서 지적했듯이, 프로젝트에 사람을 추가하는 것은 프로젝트 속도를 늦추는 경향이 있습니다. 개발자 간의 가능한 연결 수는 그룹의 크기에 따라 기하급수적으로 증가합니다. 그룹이 클수록 소프트웨어가 함께 작동하는 방식을 협상하는 회의에 더 많은 시간을 보내고, 예상치 못한 상호작용으로 인해 더 많은 버그가 발생할 것입니다. 다행히도 이 과정은 역으로도 작동합니다: 그룹이 작아질수록 소프트웨어 개발은 기하급수적으로 더 효율적이 됩니다. Viaweb의 프로그래머들이 실제로 회의를 했던 기억이 없습니다. 우리는 점심을 먹으러 가는 동안 말할 수 있는 것보다 더 많은 것을 한 번에 말할 필요가 없었습니다.

여기에 단점이 있다면, 모든 프로그래머가 어느 정도 시스템 관리자 역할도 해야 한다는 것입니다. 소프트웨어를 호스팅할 때, 누군가는 서버를 지켜봐야 하며, 실제로 이를 제대로 할 수 있는 유일한 사람들은 소프트웨어를 작성한 사람들입니다. Viaweb의 시스템은 너무 많은 구성 요소를 가지고 있었고 너무 자주 변경되었기 때문에 소프트웨어와 인프라 사이에 명확한 경계가 없었습니다. 그러한 경계를 임의로 선언하는 것은 우리의 설계 선택을 제한했을 것입니다. 그래서 우리는 언젠가(“두어 달 안에”) 모든 것이 안정되어 서버만 담당하는 사람을 고용할 수 있기를 끊임없이 바랐지만, 그런 일은 결코 일어나지 않았습니다.

제품을 계속 적극적으로 개발하는 한, 다른 방법은 없을 것이라고 생각합니다. 웹 기반 소프트웨어는 작성하고, 체크인하고, 집에 가는 그런 것이 아닙니다. 그것은 지금 당신의 서버에서 실행되고 있는 살아있는 것입니다. 나쁜 버그는 한 사용자의 프로세스만 충돌시키는 것이 아니라, 모든 사용자를 충돌시킬 수 있습니다. 코드의 버그가 디스크의 데이터를 손상시키면, 당신은 그것을 고쳐야 합니다. 등등. 우리는 서버를 매분 지켜볼 필요는 없다는 것을 알았습니다(처음 1년 정도 후에는). 하지만 최근에 변경한 것들은 확실히 주시해야 합니다. 밤늦게 코드를 릴리스하고 집에 가지 않습니다.

사용자 관찰

서버 기반 소프트웨어의 경우, 코드와 더 긴밀하게 접촉할 수 있습니다. 사용자들과도 더 긴밀하게 접촉할 수 있습니다. 인튜이트(Intuit)는 소매점에서 고객들에게 자신을 소개하고 집까지 따라가서 관찰하는 것으로 유명합니다. 누군가 당신의 소프트웨어를 처음 사용하는 것을 지켜본 적이 있다면, 그들이 어떤 놀라움을 겪었을지 알 것입니다.

소프트웨어는 사용자가 생각하는 대로 작동해야 합니다. 하지만 사용자들이 무엇을 생각할지, 저를 믿으세요, 그들을 관찰하기 전까지는 전혀 알 수 없습니다. 그리고 서버 기반 소프트웨어는 그들의 행동에 대한 전례 없는 정보를 제공합니다. 당신은 작고 인위적인 포커스 그룹에만 국한되지 않습니다. 모든 사용자의 모든 클릭을 볼 수 있습니다. 사용자의 프라이버시를 침해하고 싶지 않으므로 무엇을 볼지 신중하게 고려해야 하지만, 가장 일반적인 통계 샘플링조차도 매우 유용할 수 있습니다.

사용자가 서버에 있다면, 예를 들어 벤치마크에 의존할 필요가 없습니다. 벤치마크는 시뮬레이션된 사용자입니다. 서버 기반 소프트웨어의 경우, 실제 사용자를 관찰할 수 있습니다. 무엇을 최적화할지 결정하려면, 서버에 로그인하여 무엇이 모든 CPU를 소모하는지 확인하기만 하면 됩니다. 그리고 언제 최적화를 멈춰야 할지도 알 수 있습니다. 우리는 결국 Viaweb 편집기를 CPU 바운드(CPU-bound)가 아닌 메모리 바운드(memory-bound) 상태로 만들었고, 사용자 데이터의 크기를 줄이기 위해 할 수 있는 일이 없었기 때문에(쉬운 방법은 없었음), 거기서 멈추는 것이 좋다는 것을 알았습니다.

서버 기반 소프트웨어에서는 효율성이 중요합니다. 하드웨어 비용을 지불하기 때문입니다. 서버당 지원할 수 있는 사용자 수는 자본 비용의 제수이므로, 소프트웨어를 매우 효율적으로 만들 수 있다면 경쟁업체보다 저렴하게 판매하고도 이익을 얻을 수 있습니다. Viaweb에서는 사용자당 자본 비용을 약 5달러로 낮췄습니다. 지금은 더 적을 것이고, 아마도 첫 달 청구서를 보내는 비용보다 적을 것입니다. 소프트웨어가 합리적으로 효율적이라면 이제 하드웨어는 무료입니다.

사용자 관찰은 최적화뿐만 아니라 설계에도 도움이 될 수 있습니다. Viaweb에는 고급 사용자가 자신만의 페이지 스타일을 정의할 수 있는 RTML이라는 스크립팅 언어가 있었습니다. 우리는 RTML이 일종의 제안 상자가 된다는 것을 발견했습니다. 사용자들이 미리 정의된 페이지 스타일로는 원하는 것을 할 수 없을 때만 RTML을 사용했기 때문입니다. 예를 들어, 원래 편집기는 페이지 전체에 버튼 바를 배치했지만, 많은 사용자들이 RTML을 사용하여 버튼을 왼쪽 측면에 배치한 후, 우리는 그것을 미리 정의된 페이지 스타일의 옵션(사실 기본값)으로 만들었습니다.

마지막으로, 사용자를 관찰함으로써 그들이 어려움을 겪고 있을 때를 종종 알 수 있습니다. 그리고 고객은 항상 옳으므로, 그것은 당신이 고쳐야 할 무언가의 신호입니다. Viaweb에서 사용자를 확보하는 핵심은 온라인 시험 운전이었습니다. 그것은 마케팅 담당자들이 만든 단순한 슬라이드 시리즈가 아니었습니다. 우리의 시험 운전에서 사용자들은 실제로 소프트웨어를 사용했습니다. 약 5분이 걸렸고, 끝에는 실제 작동하는 상점을 구축했습니다.

시험 운전은 우리가 거의 모든 신규 사용자를 확보한 방법이었습니다. 대부분의 웹 기반 애플리케이션에서도 마찬가지일 것이라고 생각합니다. 사용자가 시험 운전을 성공적으로 마치면 제품을 좋아할 것입니다. 혼란스러워하거나 지루해하면 좋아하지 않을 것입니다. 따라서 시험 운전을 통해 더 많은 사람들이 통과하도록 할 수 있는 모든 것은 우리의 성장률을 높일 것입니다.

저는 시험 운전을 하는 사람들의 클릭 경로를 연구했고, 특정 단계에서 그들이 혼란스러워하며 브라우저의 뒤로 가기 버튼을 클릭한다는 것을 발견했습니다. (웹 기반 애플리케이션을 작성해 보면, 뒤로 가기 버튼이 가장 흥미로운 철학적 문제 중 하나가 된다는 것을 알게 될 것입니다.) 그래서 저는 그 지점에 메시지를 추가하여, 사용자들에게 거의 다 끝났으니 뒤로 가기 버튼을 클릭하지 말라고 상기시켰습니다. 웹 기반 소프트웨어의 또 다른 큰 장점은 변경 사항에 대한 즉각적인 피드백을 얻을 수 있다는 것입니다. 시험 운전을 완료하는 사람들의 수가 즉시 60%에서 90%로 증가했습니다. 그리고 신규 사용자 수가 완료된 시험 운전 수에 비례했기 때문에, 그 변경 하나만으로 우리의 매출 성장이 50% 증가했습니다.

돈

1990년대 초반에 저는 소프트웨어가 구독 사업이라는 기사를 읽었습니다. 처음에는 매우 냉소적인 진술처럼 들렸습니다. 하지만 나중에 그것이 현실을 반영한다는 것을 깨달았습니다: 소프트웨어 개발은 지속적인 과정입니다. 사람들이 계속 돈을 지불하도록 새로운 버전을 계속 구매하고 설치하도록 강요하는 대신, 공개적으로 구독료를 청구하는 것이 더 깔끔하다고 생각합니다. 그리고 다행히도 구독은 웹 기반 애플리케이션에 대한 청구의 자연스러운 방식입니다.

애플리케이션 호스팅은 프리웨어로는 채워지기 어려운 영역입니다. 애플리케이션 호스팅은 많은 스트레스를 동반하며 실제 비용이 발생합니다. 아무도 무료로 하고 싶어 하지 않을 것입니다.

기업에게 웹 기반 애플리케이션은 이상적인 수익원입니다. 매 분기를 백지 상태로 시작하는 대신, 반복적인 수익 흐름을 가집니다. 소프트웨어가 점진적으로 진화하기 때문에, 새로운 모델이 실패할까 봐 걱정할 필요가 없습니다. 새로운 모델 자체가 필요 없을 수 있으며, 사용자들이 싫어하는 것을 소프트웨어에 추가하면 즉시 알 수 있습니다. 미수금 문제도 없습니다. 누군가 지불하지 않으면 서비스를 중단하면 됩니다. 그리고 불법 복제 가능성도 없습니다.

마지막 “장점”은 문제가 될 수도 있습니다. 어느 정도의 불법 복제는 소프트웨어 회사에 이점이 됩니다. 어떤 사용자가 어떤 가격에도 당신의 소프트웨어를 구매하지 않았을 것이라면, 그가 불법 복제본을 사용하더라도 당신은 아무것도 잃지 않습니다. 사실 당신은 이득을 얻습니다. 그가 당신의 소프트웨어를 표준으로 만드는 데 도움이 되는 또 다른 사용자이기 때문입니다. 또는 고등학교를 졸업한 후 나중에 구매할 수도 있습니다.

가능할 때, 기업들은 가격 차별(price discrimination)이라는 것을 하고 싶어 합니다. 이는 각 고객이 감당할 수 있는 만큼의 비용을 청구하는 것을 의미합니다. [8] 소프트웨어는 특히 가격 차별에 적합합니다. 한계 비용이 거의 0에 가깝기 때문입니다. 이것이 일부 소프트웨어가 인텔(Intel) 박스보다 선(Sun)에서 실행하는 데 더 많은 비용이 드는 이유입니다. 선을 사용하는 회사는 돈을 절약하는 데 관심이 없으며 더 많은 비용을 안전하게 청구할 수 있습니다. 불법 복제는 사실상 가격 차별의 가장 낮은 단계입니다. 저는 소프트웨어 회사들이 이것을 이해하고 일부 종류의 불법 복제에 대해 의도적으로 눈감아준다고 생각합니다. [9] 서버 기반 소프트웨어의 경우, 그들은 다른 해결책을 찾아야 할 것입니다.

웹 기반 소프트웨어는 특히 데스크톱 소프트웨어와 비교하여 잘 팔립니다. 구매하기 쉽기 때문입니다. 사람들은 무언가를 구매하기로 결정하고, 그 다음에 구매하는 것을 두 개의 별개 단계로 생각할 수도 있습니다. Viaweb 이전에는 저도 그렇게 생각했습니다. 사실 두 번째 단계는 첫 번째 단계로 다시 전파될 수 있습니다. 무언가를 구매하기 어렵다면, 사람들은 그것을 원했는지에 대한 생각을 바꿀 것입니다. 그리고 그 반대도 마찬가지입니다. 구매하기 쉬울 때 더 많이 팔릴 것입니다. 아마존(Amazon)이 존재하기 때문에 저는 더 많은 책을 삽니다. 웹 기반 소프트웨어는 세상에서 가장 구매하기 쉬운 것 중 하나입니다. 특히 온라인 데모를 방금 마쳤다면 더욱 그렇습니다. 사용자들은 신용카드 번호를 입력하는 것 이상을 할 필요가 없습니다. (더 많은 것을 요구하면 위험합니다.)

때때로 웹 기반 소프트웨어는 ISP를 통해 리셀러로 제공됩니다. 이것은 나쁜 생각입니다. 하드웨어와 소프트웨어 모두를 끊임없이 개선해야 하므로 서버를 관리해야 합니다. 서버에 대한 직접적인 통제권을 포기하면 웹 기반 애플리케이션 개발의 대부분의 이점을 포기하는 것입니다.

우리 경쟁자들 중 몇몇은 이런 식으로 자멸했습니다. 제 생각에는 대개 거대한 잠재 채널에 흥분한 정장 차림의 사람들이 들이닥쳐, 그것을 통해 판매하려던 제품을 망칠 것이라는 사실을 깨닫지 못했기 때문입니다. ISP를 통해 웹 기반 소프트웨어를 판매하는 것은 자판기를 통해 스시를 판매하는 것과 같습니다.

고객

고객은 누가 될까요? Viaweb에서는 처음에는 개인과 소규모 회사들이었고, 웹 기반 애플리케이션에서도 이것이 일반적인 규칙이 될 것이라고 생각합니다. 이들은 새로운 것을 시도할 준비가 된 사용자들입니다. 부분적으로는 더 유연하기 때문이고, 부분적으로는 새로운 기술의 낮은 비용을 원하기 때문입니다.

웹 기반 애플리케이션은 대기업에게도 종종 최선의 선택이 될 것입니다(비록 그들이 그것을 깨닫는 데는 시간이 걸리겠지만). 최고의 인트라넷(intranet)은 인터넷입니다. 회사가 진정한 웹 기반 애플리케이션을 사용한다면, 소프트웨어는 더 잘 작동하고, 서버는 더 잘 관리되며, 직원들은 어디에서든 시스템에 접근할 수 있을 것입니다.

이 접근 방식에 대한 반론은 대개 보안에 달려 있습니다. 직원들에게 접근이 쉬우면, 나쁜 사람들에게도 쉬울 것이라는 것입니다. 일부 대형 상인들은 고객의 신용카드 정보가 자체 서버에 더 안전할 것이라고 생각하여 Viaweb 사용을 꺼려했습니다. 이 점을 외교적으로 설명하기는 쉽지 않았지만, 사실 데이터는 거의 확실히 그들 손에 있는 것보다 우리 손에 있을 때 더 안전했습니다. 보안 관리를 위해 더 나은 사람들을 고용할 수 있는 곳은 어디일까요? 서버 운영이 사업의 전부인 기술 스타트업일까요, 아니면 의류 소매업체일까요? 우리는 보안에 대해 더 나은 사람들을 고용했을 뿐만 아니라, 보안에 대해 더 많이 걱정했습니다. 만약 의류 소매업체의 서버가 침해당하면, 기껏해야 한 상인에게 영향을 미치고, 아마도 은폐될 수 있으며, 최악의 경우 한 명이 해고될 수도 있습니다. 만약 우리의 서버가 침해당하면, 수천 명의 상인에게 영향을 미치고, 아마도 CNet 뉴스에 나올 것이며, 우리 사업을 망하게 할 수도 있었습니다.

돈을 안전하게 보관하고 싶다면, 집 매트리스 밑에 보관하시겠습니까, 아니면 은행에 맡기시겠습니까? 이 주장은 서버 관리의 모든 측면에 적용됩니다: 보안뿐만 아니라 가동 시간(uptime), 대역폭(bandwidth), 부하 관리(load management), 백업 등. 우리의 존재는 이러한 것들을 올바르게 수행하는 데 달려 있었습니다. 서버 문제는 우리에게는 큰 금기 사항이었습니다. 장난감 제조업자에게 위험한 장난감, 식품 가공업자에게 살모넬라균 발생과 같았습니다.

웹 기반 애플리케이션을 사용하는 대기업은 그만큼 IT를 아웃소싱하는 것입니다. 극단적으로 들리겠지만, 저는 이것이 일반적으로 좋은 생각이라고 생각합니다. 기업들은 사내 시스템 관리자로부터 받는 것보다 이런 방식으로 더 나은 서비스를 받을 가능성이 높습니다. 시스템 관리자들은 경쟁 압력에 직접 노출되지 않기 때문에 까다롭고 반응이 느려질 수 있습니다. 영업 사원은 고객을 상대해야 하고, 개발자는 경쟁사의 소프트웨어를 상대해야 하지만, 시스템 관리자는 오래된 독신남처럼 자신을 통제할 외부적인 힘이 거의 없습니다. [10] Viaweb에서는 우리를 통제할 외부적인 힘이 충분히 많았습니다. 우리에게 전화하는 사람들은 동료가 아니라 고객이었습니다. 서버가 멈추면 우리는 즉시 움직였습니다. 몇 년이 지난 지금도 생각만 해도 아드레날린이 솟구칩니다.

따라서 웹 기반 애플리케이션은 일반적으로 대기업에게도 올바른 답이 될 것입니다. 하지만 데스크톱 컴퓨터와 마찬가지로 그들은 가장 늦게 그것을 깨달을 것입니다. 그리고 부분적으로는 같은 이유 때문입니다: 대기업에게 더 비싼 것이 필요하다고 설득하는 데 많은 돈을 들일 가치가 있기 때문입니다.

부유한 고객들은 항상 비싼 솔루션을 구매하는 경향이 있습니다. 저렴한 솔루션이 더 나을 때조차도 말입니다. 비싼 솔루션을 제공하는 사람들이 그것을 판매하는 데 더 많은 돈을 쓸 수 있기 때문입니다. Viaweb에서는 항상 이 문제에 직면했습니다. 우리는 여러 고가 상인들을 웹 컨설팅 회사에 빼앗겼습니다. 그 회사들은 그들에게 자체 서버에 맞춤 제작된 온라인 상점을 위해 50만 달러를 지불하는 것이 더 낫다고 설득했습니다. 크리스마스 쇼핑 시즌이 다가오고 서버 부하가 증가했을 때 한두 곳 이상이 발견했듯이, 그들은 일반적으로 더 나아지지 않았습니다. Viaweb은 대부분의 상인들이 얻은 것보다 훨씬 더 정교했지만, 우리는 그들에게 말해줄 여유가 없었습니다. 월 300달러로는 잘 차려입고 권위 있는 목소리를 내는 팀을 고객들에게 프레젠테이션하기 위해 보낼 여유가 없었습니다.

대기업이 추가로 지불하는 비용의 상당 부분은 비싼 것을 판매하는 비용입니다. (국방부가 변기 시트에 천 달러를 지불한다면, 그것은 부분적으로 천 달러짜리 변기 시트를 판매하는 데 많은 비용이 들기 때문입니다.) 그리고 이것이 인트라넷 소프트웨어가 아마도 나쁜 생각임에도 불구하고 계속 번성할 한 가지 이유입니다. 단순히 더 비싸기 때문입니다. 이 딜레마에 대해 할 수 있는 일은 없으므로, 가장 좋은 계획은 먼저 소규모 고객을 공략하는 것입니다. 나머지는 시간이 지나면 따라올 것입니다.

서버의 아들

서버에서 소프트웨어를 실행하는 것은 새로운 것이 아닙니다. 사실 그것은 오래된 모델입니다: 메인프레임 애플리케이션은 모두 서버 기반입니다. 서버 기반 소프트웨어가 그렇게 좋은 아이디어라면, 왜 지난번에는 실패했을까요? 왜 데스크톱 컴퓨터가 메인프레임을 압도했을까요?

처음에는 데스크톱 컴퓨터가 큰 위협처럼 보이지 않았습니다. 첫 사용자들은 모두 해커들이었습니다. 또는 당시에는 취미가들이라고 불렸습니다. 그들은 마이크로컴퓨터가 저렴해서 좋아했습니다. 처음으로 자신만의 컴퓨터를 가질 수 있었습니다. “개인용 컴퓨터”라는 문구는 이제 일상어가 되었지만, 처음 사용되었을 때는 오늘날 “개인용 위성”이라는 문구처럼 의도적으로 대담한 느낌을 주었습니다.

왜 데스크톱 컴퓨터가 장악했을까요? 저는 더 나은 소프트웨어를 가지고 있었기 때문이라고 생각합니다. 그리고 마이크로컴퓨터 소프트웨어가 더 좋았던 이유는 소규모 회사들이 그것을 작성할 수 있었기 때문이라고 생각합니다.

많은 사람들이 스타트업이 초기 단계에서 얼마나 취약하고 불확실한지 깨닫지 못한다고 생각합니다. 많은 스타트업은 거의 우연히 시작됩니다. 직장인이거나 학생인 두 사람이 유망해 보이면 회사로 발전할 수 있는 무언가의 프로토타입을 작성하는 식으로 말입니다. 이 유충 단계에서는 어떤 중요한 장애물이라도 스타트업을 즉시 멈춰 세울 것입니다. 메인프레임 소프트웨어를 작성하는 것은 너무 많은 초기 투자를 요구했습니다. 개발 장비는 비쌌고, 고객이 대기업이기 때문에 그들에게 판매하려면 인상적인 영업팀이 필요했을 것입니다. 메인프레임 소프트웨어를 작성하기 위해 스타트업을 시작하는 것은 저녁에 애플 II(Apple II)에서 무언가를 해킹하는 것보다 훨씬 더 진지한 사업이었을 것입니다. 그래서 메인프레임 애플리케이션을 작성하는 스타트업이 많지 않았습니다.

데스크톱 컴퓨터의 등장은 많은 새로운 소프트웨어를 탄생시켰습니다. 유충 단계의 스타트업에게는 데스크톱 애플리케이션을 작성하는 것이 달성 가능한 목표처럼 보였기 때문입니다. 개발 비용은 저렴했고, 고객은 컴퓨터 상점이나 심지어 우편 주문을 통해 도달할 수 있는 개인이었습니다.

데스크톱 컴퓨터를 주류로 밀어붙인 애플리케이션은 최초의 스프레드시트인 비지칼크(VisiCalc)였습니다. 그것은 다락방에서 일하는 두 사람이 작성했지만, 어떤 메인프레임 소프트웨어도 할 수 없었던 일들을 해냈습니다. [11] 비지칼크는 당시 너무나 큰 발전이어서, 사람들은 그것을 실행하기 위해 애플 II를 구매했습니다. 그리고 이것이 추세의 시작이었습니다: 데스크톱 컴퓨터는 스타트업이 소프트웨어를 작성했기 때문에 승리했습니다.

이번에는 서버 기반 소프트웨어가 좋을 것 같습니다. 스타트업이 그것을 작성할 것이기 때문입니다. 컴퓨터는 이제 너무 저렴해서, 우리가 그랬듯이, 데스크톱 컴퓨터를 서버로 사용하여 시작할 수 있습니다. 저렴한 프로세서가 워크스테이션 시장을 잠식했고(이제는 그 단어를 거의 듣지 못합니다) 서버 시장의 대부분을 차지하고 있습니다. 인터넷에서 가장 높은 부하를 처리하는 야후(Yahoo)의 서버들은 모두 당신의 데스크톱 컴퓨터에 있는 것과 동일한 저렴한 인텔(Intel) 프로세서를 사용합니다. 그리고 소프트웨어를 작성한 후에는 웹사이트만 있으면 판매할 수 있습니다. 거의 모든 우리 사용자들은 입소문과 언론 보도를 통해 우리 사이트로 직접 찾아왔습니다. [12]

Viaweb은 전형적인 유충 단계의 스타트업이었습니다. 우리는 회사를 시작하는 것을 두려워했고, 처음 몇 달 동안은 모든 것을 언제든지 중단할 수 있는 실험으로 여기며 스스로를 위로했습니다. 다행히도 기술적인 장애물 외에는 거의 없었습니다. 소프트웨어를 작성하는 동안, 우리의 웹 서버는 개발에 사용하던 데스크톱 컴퓨터와 동일했으며, 다이얼업 회선으로 외부 세계와 연결되어 있었습니다. 그 단계에서 우리의 유일한 지출은 식비와 임대료였습니다.

이제 스타트업이 웹 기반 소프트웨어를 작성해야 할 이유가 더욱 많아졌습니다. 데스크톱 소프트웨어를 작성하는 것이 훨씬 덜 재미있어졌기 때문입니다. 지금 데스크톱 소프트웨어를 작성하려면 마이크로소프트의 조건에 따라 그들의 API를 호출하고 버그가 많은 OS를 우회해야 합니다. 그리고 성공적인 소프트웨어를 작성하더라도, 당신이 단지 마이크로소프트의 시장 조사를 하고 있었을 뿐이라는 것을 알게 될 수도 있습니다.

회사가 스타트업이 기반으로 삼을 플랫폼을 만들고 싶다면, 해커들 자신이 사용하고 싶어 할 만한 것을 만들어야 합니다. 즉, 저렴하고 잘 설계되어야 합니다. 맥(Mac)은 처음 나왔을 때 해커들에게 인기가 많았고, 많은 해커들이 그것을 위한 소프트웨어를 작성했습니다. [13] 윈도우(Windows)에서는 이런 모습을 덜 볼 수 있습니다. 해커들이 그것을 사용하지 않기 때문입니다. 소프트웨어 작성에 능숙한 사람들은 이제 리눅스(Linux)나 FreeBSD를 실행하는 경향이 있습니다.

우리는 데스크톱 소프트웨어를 작성하기 위해 스타트업을 시작하지 않았을 것이라고 생각합니다. 데스크톱 소프트웨어는 윈도우에서 실행되어야 하고, 윈도우용 소프트웨어를 작성하기 전에 윈도우를 사용해야 했기 때문입니다. 웹은 우리가 윈도우를 우회하고, 유닉스(Unix)에서 실행되는 소프트웨어를 브라우저를 통해 사용자에게 직접 제공할 수 있게 해주었습니다. 그것은 25년 전 PC의 등장과 매우 흡사한 해방적인 전망입니다.

마이크로소프트

데스크톱 컴퓨터가 등장했을 때, IBM은 모두가 두려워하는 거인이었습니다. 지금은 상상하기 어렵지만, 저는 그 느낌을 아주 잘 기억합니다. 이제 무서운 거인은 마이크로소프트이며, 저는 그들이 자신들이 직면한 위협에 대해 IBM만큼 눈이 멀었다고 생각하지 않습니다. 결국, 마이크로소프트는 IBM의 사각지대에서 의도적으로 사업을 구축했습니다.

앞서 저희 어머니가 실제로 데스크톱 컴퓨터가 필요 없다고 언급했습니다. 대부분의 사용자들도 아마 그럴 것입니다. 그것은 마이크로소프트에게 문제이며, 그들도 그것을 알고 있습니다. 애플리케이션이 원격 서버에서 실행된다면, 아무도 윈도우를 필요로 하지 않습니다. 마이크로소프트는 무엇을 할까요? 그들은 데스크톱에 대한 통제력을 사용하여 이 새로운 세대의 소프트웨어를 막거나 제한할 수 있을까요?

제 생각에 마이크로소프트는 자신들이 통제하는 서버와 함께 작동하는 일종의 서버/데스크톱 하이브리드를 개발할 것입니다. 최소한, 원하는 사용자들을 위해 파일은 중앙에서 이용 가능할 것입니다. 마이크로소프트가 피할 수 있다면, 클라이언트에 브라우저만 두고 서버에서 모든 계산을 수행하는 극단적인 방식으로는 가지 않을 것이라고 예상합니다. 클라이언트에 브라우저만 필요하다면, 클라이언트에 마이크로소프트가 필요 없고, 마이크로소프트가 클라이언트를 통제하지 못한다면, 사용자들을 자신들의 서버 기반 애플리케이션으로 유도할 수 없을 것입니다.

마이크로소프트가 지니를 병에 가두는 데 어려움을 겪을 것이라고 생각합니다. 그들이 모든 클라이언트를 통제하기에는 너무 많은 종류의 클라이언트가 있을 것입니다. 그리고 마이크로소프트의 애플리케이션이 일부 클라이언트에서만 작동한다면, 경쟁자들은 어떤 클라이언트에서든 작동하는 애플리케이션을 제공하여 그들을 능가할 수 있을 것입니다. [14]

웹 기반 애플리케이션의 세상에서는 마이크로소프트가 자동으로 차지할 자리가 없습니다. 그들은 자신들의 자리를 만들 수도 있겠지만, 데스크톱 애플리케이션의 세상을 지배했던 것처럼 이 새로운 세상을 지배하지는 못할 것이라고 생각합니다.

경쟁자가 그들을 넘어뜨리기보다는 그들 스스로 넘어질 가능성이 더 큽니다. 웹 기반 소프트웨어의 부상과 함께, 그들은 기술적인 문제뿐만 아니라 자신들의 희망적인 생각에도 직면하게 될 것입니다. 그들이 해야 할 일은 기존 사업을 잠식하는 것인데, 저는 그들이 그것을 감당할 수 있을 것이라고 보지 않습니다. 그들을 여기까지 이끌어온 그 단호함이 이제는 그들에게 불리하게 작용할 것입니다. IBM도 정확히 같은 상황에 처해 있었고, 그것을 극복하지 못했습니다. IBM은 자신들의 현금 창출원인 메인프레임 컴퓨팅을 위협하는 것에 대해 양가적인 태도를 보였기 때문에 마이크로컴퓨터 사업에 늦고 미온적으로 진출했습니다. 마이크로소프트도 마찬가지로 데스크톱을 구하려는 욕구 때문에 방해를 받을 것입니다. 현금 창출원은 당신의 등에 짊어진 엄청나게 무거운 짐이 될 수 있습니다.

아무도 서버 기반 애플리케이션을 지배하지 않을 것이라고 말하는 것은 아닙니다. 누군가는 결국 그렇게 할 것입니다. 하지만 마이크로컴퓨터 초기 시절처럼 유쾌한 혼돈의 좋은 긴 기간이 있을 것이라고 생각합니다. 그때는 스타트업에게 좋은 시기였습니다. 많은 소규모 회사들이 번성했고, 멋진 것들을 만들면서 그렇게 했습니다.

더욱 스타트업답게

고전적인 스타트업은 빠르고 비공식적이며, 적은 인원과 적은 자금으로 운영됩니다. 그 소수의 사람들은 매우 열심히 일하며, 기술은 그들이 내리는 결정의 효과를 증폭시킵니다. 그들이 이기면 크게 이깁니다.

웹 기반 애플리케이션을 작성하는 스타트업에서는 스타트업과 관련된 모든 것이 극단으로 치닫습니다. 훨씬 적은 인원과 훨씬 적은 자금으로 제품을 작성하고 출시할 수 있습니다. 훨씬 더 빨라야 하며, 더 비공식적으로 행동할 수 있습니다. 말 그대로 아파트 거실에 앉은 세 명의 사람들과 ISP에 코로케이션된 서버로 제품을 출시할 수 있습니다. 우리는 그렇게 했습니다.

시간이 지남에 따라 팀은 더 작아지고, 더 빨라지고, 더 비공식적이 되었습니다. 1960년대에는 소프트웨어 개발이란 뿔테 안경을 쓰고 좁은 검은 넥타이를 맨 남자들이 방에 가득 앉아 IBM 코딩 양식에 하루에 10줄의 코드를 부지런히 작성하는 것을 의미했습니다. 1980년대에는 사무실에 청바지를 입고 vt100 터미널에 타이핑하는 8~10명의 팀이었습니다. 이제는 거실에 노트북을 들고 앉은 두 명의 남자입니다. (그리고 청바지는 비공식성의 마지막 단어가 아니라는 것이 밝혀졌습니다.)

스타트업은 스트레스가 많고, 불행히도 이것 또한 웹 기반 애플리케이션에서는 극단으로 치닫습니다. 많은 소프트웨어 회사, 특히 초기에는 개발자들이 책상 밑에서 잠을 자는 등의 기간을 가집니다. 웹 기반 소프트웨어의 놀라운 점은 이것이 기본값이 되는 것을 막을 수 없다는 것입니다. 책상 밑에서 잠을 자는 이야기는 보통 이렇게 끝납니다: 마침내 우리는 제품을 출시했고 모두 집에 가서 일주일 동안 잠을 잤다. 웹 기반 소프트웨어는 결코 출시되지 않습니다. 당신은 원하는 만큼 16시간씩 일할 수 있습니다. 그리고 당신이 할 수 있고, 경쟁자들도 할 수 있기 때문에, 당신은 그렇게 하도록 강요받는 경향이 있습니다. 할 수 있으니, 해야 합니다. 파킨슨의 법칙이 역으로 작동하는 것입니다.

가장 나쁜 것은 근무 시간이 아니라 책임감입니다. 프로그래머와 시스템 관리자는 전통적으로 각자의 걱정거리를 가지고 있습니다. 프로그래머는 버그에 대해 걱정해야 하고, 시스템 관리자는 인프라에 대해 걱정해야 합니다. 프로그래머는 소스 코드에 파묻혀 긴 하루를 보낼 수 있지만, 어느 시점에는 집에 가서 그것을 잊을 수 있습니다. 시스템 관리자는 결코 일을 완전히 떠나지 못하지만, 새벽 4시에 호출을 받더라도 보통 매우 복잡한 일을 할 필요는 없습니다. 웹 기반 애플리케이션에서는 이 두 가지 종류의 스트레스가 결합됩니다. 프로그래머는 시스템 관리자가 되지만, 일반적으로 일을 견딜 수 있게 해주는 명확하게 정의된 한계가 없습니다.

Viaweb에서 우리는 처음 6개월 동안 소프트웨어만 작성했습니다. 우리는 초기 스타트업의 일반적인 긴 시간을 일했습니다. 데스크톱 소프트웨어 회사에서는 이 부분이 열심히 일하는 부분이었겠지만, 사용자들을 우리 서버로 데려온 다음 단계에 비하면 휴가처럼 느껴졌습니다. Viaweb을 야후(Yahoo)에 판매한 두 번째로 큰 이점(돈 다음으로)은 모든 것에 대한 궁극적인 책임을 대기업의 어깨에 넘길 수 있었다는 것입니다.

데스크톱 소프트웨어는 사용자들을 시스템 관리자가 되도록 강요합니다. 웹 기반 소프트웨어는 프로그래머들을 그렇게 강요합니다. 전체적인 스트레스는 줄어들지만, 프로그래머들에게는 더 많습니다. 그것이 반드시 나쁜 소식은 아닙니다. 대기업과 경쟁하는 스타트업이라면 좋은 소식입니다. [15] 웹 기반 애플리케이션은 경쟁자들을 능가할 수 있는 간단한 방법을 제공합니다. 어떤 스타트업도 더 이상을 요구하지 않습니다.

그냥 충분히 좋다

웹 기반 애플리케이션을 작성하는 것을 망설이게 할 수 있는 한 가지는 UI로서의 웹 페이지의 허술함입니다. 그것은 문제라고 인정합니다. HTML과 HTTP에 정말로 추가하고 싶었던 몇 가지가 있었습니다. 하지만 중요한 것은 웹 페이지가 그냥 충분히 좋다는 것입니다.

여기에는 최초의 마이크로컴퓨터와 유사점이 있습니다. 그 기계들의 프로세서는 실제로는 컴퓨터의 CPU로 의도된 것이 아니었습니다. 그것들은 신호등과 같은 곳에 사용되도록 설계되었습니다. 하지만 알테어(Altair)를 설계한 에드 로버츠(Ed Roberts)와 같은 사람들은 그것들이 그냥 충분히 좋다는 것을 깨달았습니다. 이 칩 중 하나를 약간의 메모리(최초 알테어에는 256바이트)와 전면 패널 스위치와 결합하면 작동하는 컴퓨터를 가질 수 있었습니다. 자신만의 컴퓨터를 가질 수 있다는 것은 너무나 흥미로워서, 아무리 제한적이라도 그것을 사고 싶어 하는 사람들이 많았습니다.

웹 페이지는 애플리케이션의 UI로 설계되지 않았지만, 그냥 충분히 좋습니다. 그리고 상당수의 사용자에게는 어떤 브라우저에서든 사용할 수 있는 소프트웨어가 UI의 어떤 어색함도 상쇄할 만큼 그 자체로 충분한 이점이 될 것입니다. HTML을 사용하여 가장 보기 좋은 스프레드시트를 작성할 수는 없겠지만, 여러 사람이 특수 클라이언트 소프트웨어 없이 다른 위치에서 동시에 사용할 수 있거나, 실시간 데이터 피드를 통합하거나, 특정 조건이 트리거될 때 호출을 보낼 수 있는 스프레드시트를 작성할 수 있습니다. 더 중요한 것은, 아직 이름조차 없는 새로운 종류의 애플리케이션을 작성할 수 있다는 것입니다. 비지칼크(VisiCalc)는 결국 메인프레임 애플리케이션의 마이크로컴퓨터 버전이 아니라, 새로운 유형의 애플리케이션이었습니다.

물론 서버 기반 애플리케이션이 웹 기반일 필요는 없습니다. 다른 종류의 클라이언트를 가질 수도 있습니다. 하지만 그것은 나쁜 생각이라고 확신합니다. 모든 사람이 당신의 클라이언트를 설치할 것이라고 가정할 수 있다면 매우 편리할 것입니다. 너무 편리해서 모두가 그렇게 할 것이라고 쉽게 스스로를 설득할 수 있겠지만, 만약 그들이 설치하지 않는다면 당신은 망합니다. 웹 기반 소프트웨어는 클라이언트에 대해 아무것도 가정하지 않기 때문에, 웹이 작동하는 모든 곳에서 작동할 것입니다. 그것은 이미 큰 장점이며, 새로운 웹 장치가 확산됨에 따라 그 장점은 더욱 커질 것입니다. 사용자들은 당신의 소프트웨어가 그냥 작동하기 때문에 당신을 좋아할 것이고, 당신은 모든 새로운 클라이언트에 대해 조정할 필요가 없기 때문에 삶이 더 쉬워질 것입니다. [16]

저는 웹의 진화를 누구보다도 면밀히 지켜봤다고 생각하지만, 클라이언트와 관련하여 무슨 일이 일어날지는 예측할 수 없습니다. 수렴은 아마도 올 것이지만, 어디로? 승자를 고를 수 없습니다. 제가 예측할 수 있는 한 가지는 AOL과 마이크로소프트 간의 갈등입니다. 마이크로소프트의 .NET이 무엇으로 밝혀지든, 그것은 아마도 데스크톱을 서버에 연결하는 것을 포함할 것입니다. AOL이 반격하지 않는 한, 그들은 밀려나거나 마이크로소프트 클라이언트와 서버 소프트웨어 사이의 파이프가 될 것입니다. 마이크로소프트와 AOL이 클라이언트 전쟁에 돌입한다면, 양쪽 모두에서 확실히 작동할 유일한 것은 웹 브라우징일 것이며, 이는 웹 기반 애플리케이션이 모든 곳에서 작동하는 유일한 종류가 될 것임을 의미합니다.

모든 것이 어떻게 전개될까요? 저는 모릅니다. 그리고 웹 기반 애플리케이션에 베팅한다면 알 필요도 없습니다. 아무도 브라우징을 망가뜨리지 않고는 그것을 망가뜨릴 수 없습니다. 웹이 소프트웨어를 제공하는 유일한 방법은 아닐지라도, 지금 작동하고 오랫동안 계속 작동할 방법입니다. 웹 기반 애플리케이션은 개발 비용이 저렴하고, 가장 작은 스타트업도 쉽게 제공할 수 있습니다. 많은 노력이 필요하고 특히 스트레스가 많은 종류이지만, 그것은 스타트업에게 성공 확률을 높여줄 뿐입니다.

왜 안 돼?

E. B. 화이트(E. B. White)는 농부 친구로부터 많은 전기 울타리에 전류가 흐르지 않는다는 것을 알고 즐거워했습니다. 소들은 분명히 그것을 피하는 법을 배우고, 그 후에는 전류가 필요 없다는 것입니다. 그는 “일어나라, 소들아! 폭군이 코를 골 때 자유를 쟁취하라!”고 썼습니다.

언젠가 스타트업을 시작할 생각을 해본 해커라면, 아마도 두 가지가 당신을 막고 있을 것입니다. 하나는 사업에 대해 아무것도 모른다는 것이고, 다른 하나는 경쟁이 두렵다는 것입니다. 이 두 울타리에는 전류가 흐르지 않습니다.

사업에 대해 알아야 할 것은 단 두 가지입니다: 사용자들이 사랑하는 것을 만들고, 쓰는 것보다 더 많이 버는 것입니다. 이 두 가지를 잘하면, 대부분의 스타트업보다 앞서 나갈 것입니다. 나머지는 진행하면서 알아낼 수 있습니다.

처음에는 쓰는 것보다 더 많이 벌지 못할 수도 있지만, 그 격차가 충분히 빠르게 줄어들고 있다면 괜찮을 것입니다. 자금 부족 상태로 시작하면, 적어도 절약 습관을 기르는 데 도움이 될 것입니다. 적게 쓸수록 더 많이 벌기 쉽습니다. 다행히도 웹 기반 애플리케이션을 출시하는 것은 매우 저렴할 수 있습니다. 우리는 1만 달러 미만으로 출시했고, 지금은 훨씬 더 저렴할 것입니다. 우리는 서버에 수천 달러를 써야 했고, SSL을 얻기 위해 수천 달러를 더 써야 했습니다. (당시 SSL 소프트웨어를 판매하는 유일한 회사는 넷스케이프였습니다.) 이제는 우리가 대역폭에만 지불했던 비용보다 적은 비용으로 훨씬 더 강력한 서버를 SSL 포함하여 임대할 수 있습니다. 지금은 멋진 사무실 의자 비용보다 적은 비용으로 웹 기반 애플리케이션을 출시할 수 있습니다.

사용자들이 사랑하는 것을 만드는 것에 대한 몇 가지 일반적인 팁입니다. 먼저 당신 자신이 사용하고 싶을 만한 깔끔하고 간단한 것을 만드는 것부터 시작하십시오. 버전 1.0을 빠르게 출시한 다음, 사용자들의 의견을 면밀히 들으면서 소프트웨어를 계속 개선하십시오. 고객은 항상 옳지만, 다른 고객들은 다른 것에 대해 옳습니다. 가장 미숙한 사용자들은 당신이 단순화하고 명확히 해야 할 것을 보여주고, 가장 정교한 사용자들은 당신이 추가해야 할 기능을 알려줍니다. 소프트웨어가 가질 수 있는 최고의 특성은 쉬움이지만, 이를 달성하는 방법은 사용자 선택을 제한하는 것이 아니라 기본값을 올바르게 설정하는 것입니다. 경쟁사의 소프트웨어가 허술하다고 해서 안주하지 마십시오. 당신의 소프트웨어를 비교해야 할 기준은 현재 경쟁사가 가지고 있는 것이 아니라, 될 수 있는 것입니다. 당신의 소프트웨어를 항상 직접 사용하십시오. Viaweb은 온라인 상점 빌더였지만, 우리는 우리 자신의 사이트를 만드는 데도 그것을 사용했습니다. 마케팅 담당자나 디자이너, 제품 관리자의 직책 때문에 그들의 말을 듣지 마십시오. 좋은 아이디어가 있다면 사용하되, 결정은 당신에게 달려 있습니다. 소프트웨어는 디자인을 이해하는 해커가 설계해야 하며, 소프트웨어에 대해 조금 아는 디자이너가 설계해서는 안 됩니다. 소프트웨어를 구현하는 것만큼 잘 설계할 수 없다면, 스타트업을 시작하지 마십시오.

이제 경쟁에 대해 이야기해 봅시다. 당신이 두려워하는 것은 아마도 당신과 같은 해커 그룹이 아니라, 사무실과 사업 계획, 영업 사원 등을 갖춘 실제 회사들이겠죠? 글쎄요, 그들은 당신보다 당신을 더 두려워하고, 그들이 옳습니다. 두 명의 해커가 사무실 공간을 임대하거나 영업 사원을 고용하는 방법을 알아내는 것이, 어떤 규모의 회사라도 소프트웨어를 작성하는 것보다 훨씬 쉽습니다. 저는 양쪽 모두에 있어봤고, 압니다. Viaweb이 야후(Yahoo)에 인수되었을 때, 저는 갑자기 대기업에서 일하게 되었고, 그것은 허리 깊이의 물속을 달리는 것 같았습니다.

야후를 폄하하려는 의도는 없습니다. 그들은 훌륭한 해커들을 가지고 있었고, 최고 경영진은 정말 유능한 사람들이었습니다. 대기업치고는 예외적이었습니다. 하지만 그들은 여전히 작은 스타트업의 생산성의 10분의 1 정도밖에 되지 않았습니다. 어떤 대기업도 그보다 훨씬 나아질 수는 없습니다. 마이크로소프트가 무서운 점은 그렇게 큰 회사가 소프트웨어를 전혀 개발할 수 있다는 것입니다. 그들은 마치 걸어 다니는 산과 같습니다.

위축되지 마십시오. 마이크로소프트가 할 수 없는 만큼 당신도 할 수 있고, 당신이 할 수 없는 만큼 마이크로소프트도 할 수 있습니다. 그리고 아무도 당신을 막을 수 없습니다. 웹 기반 애플리케이션을 개발하기 위해 누구의 허락도 받을 필요가 없습니다. 라이선스 계약을 하거나, 소매점에서 진열 공간을 얻거나, 애플리케이션을 OS에 번들로 포함시키기 위해 비굴하게 굴 필요도 없습니다. 소프트웨어를 브라우저에 직접 제공할 수 있으며, 아무도 웹 브라우징을 막지 않고는 당신과 잠재 사용자 사이에 끼어들 수 없습니다.

믿지 않을 수도 있겠지만, 약속합니다. 마이크로소프트는 당신을 두려워합니다. 안일한 중간 관리자들은 아닐지라도, 빌 게이츠(Bill Gates)는 그렇습니다. 그는 1975년, 소프트웨어 제공의 새로운 방식이 등장했던 마지막 시기에 당신과 같았기 때문입니다.

각주

[1] 돈의 상당 부분이 서비스에 있다는 것을 깨달은 경량 클라이언트 구축 회사들은 보통 하드웨어와 온라인 서비스를 결합하려고 시도했습니다. 이 접근 방식은 잘 작동하지 않았는데, 부분적으로는 가전제품을 만들고 온라인 서비스를 운영하는 데 두 가지 다른 종류의 회사가 필요했기 때문이고, 부분적으로는 사용자들이 그 아이디어를 싫어했기 때문입니다. 면도기를 무료로 주고 면도날로 돈을 버는 방식은 질레트(Gillette)에게는 통할지 모르지만, 면도기는 웹 터미널보다 훨씬 작은 약속입니다. 휴대폰 단말기 제조업체들은 서비스 수익까지 얻으려 하지 않고 하드웨어 판매에 만족합니다. 인터넷 클라이언트도 아마 이 모델을 따라야 할 것입니다. 누군가 멋진 작은 상자에 웹 브라우저를 넣어 어떤 ISP를 통해서든 연결할 수 있게 판매한다면, 이 나라의 모든 기술 공포증 환자들이 하나씩 살 것입니다.

[2] 보안은 항상 어떤 설계 결정보다도 실수를 하지 않는 것에 더 많이 달려 있지만, 서버 기반 소프트웨어의 특성상 개발자들이 실수를 하지 않는 것에 더 많은 주의를 기울이게 될 것입니다. 서버 침해는 엄청난 피해를 초래할 수 있으므로, ASP(사업을 계속하고 싶다면)는 보안에 신중할 가능성이 높습니다.

[3] 1995년 Viaweb을 시작했을 때, 자바 애플릿(Java applets)은 모든 사람이 서버 기반 애플리케이션을 개발하는 데 사용할 기술로 여겨졌습니다. 애플릿은 우리에게 구식 아이디어처럼 보였습니다. 클라이언트에서 실행할 프로그램을 다운로드한다? 그냥 끝까지 가서 서버에서 프로그램을 실행하는 것이 더 간단합니다. 우리는 애플릿에 시간을 거의 낭비하지 않았지만, 수많은 다른 스타트업들이 이 타르 웅덩이에 유혹되었을 것입니다. 살아남은 곳은 거의 없을 것이고, 그렇지 않았다면 마이크로소프트는 익스플로러(Explorer)의 최신 버전에서 자바를 제거하는 데 성공하지 못했을 것입니다.

[4] 이 점은 트레버 블랙웰(Trevor Blackwell)의 의견이며, 그는 “소프트웨어 작성 비용은 그 크기에 비례하여 선형적으로 증가하는 것 이상입니다. 아마도 이는 주로 오래된 버그를 수정하는 데 기인하며, 모든 버그가 빠르게 발견된다면 비용은 더 선형적일 수 있습니다.”라고 덧붙였습니다.

[5] 찾기 가장 어려운 종류의 버그는 한 버그가 다른 버그를 우연히 상쇄하는 복합 버그의 변형일 수 있습니다. 한 버그를 수정하면 다른 버그가 드러납니다. 하지만 마지막으로 변경한 것이기 때문에 수정 자체가 문제인 것처럼 보일 것입니다.

[6] Viaweb 내부에서 우리는 한때 우리 소프트웨어의 최악의 점을 설명하는 대회를 열었습니다. 두 명의 고객 지원 담당자가 제가 아직도 몸서리치는 내용으로 공동 1위를 차지했습니다. 우리는 두 문제 모두 즉시 해결했습니다.

[7] 로버트 모리스(Robert Morris)는 쇼핑객들이 주문하는 데 사용하는 주문 시스템을 작성했습니다. 트레버 블랙웰(Trevor Blackwell)은 상인들이 주문을 검색하고, 통계를 보고, 도메인 이름을 구성하는 데 사용하는 이미지 생성기와 관리자를 작성했습니다. 저는 상인들이 사이트를 구축하는 데 사용하는 편집기를 작성했습니다. 주문 시스템과 이미지 생성기는 C와 C++로 작성되었고, 관리자는 주로 펄(Perl)로, 편집기는 리스프로 작성되었습니다.

[8] 가격 차별은 너무나 만연해 있어서(소매업자가 구매력을 통해 당신에게 더 낮은 가격을 제공한다고 주장하는 것을 얼마나 자주 들었습니까?) 미국에서 1936년 로빈슨-패트먼 법(Robinson-Patman Act)에 의해 불법화되었다는 것을 알고 놀랐습니다. 이 법은 강력하게 시행되지 않는 것 같습니다.

[9] 나오미 클라인(Naomi Klein)은 _노 로고(No Logo)_에서 “도시 청소년”이 선호하는 의류 브랜드는 소매치기를 너무 열심히 막으려 하지 않는다고 말합니다. 그들의 타겟 시장에서 소매치기들이 또한 패션 리더이기 때문입니다.

[10] 기업들은 종종 무엇을 아웃소싱하고 무엇을 아웃소싱하지 않을지 궁금해합니다. 한 가지 가능한 답변: 경쟁 압력에 직접 노출되지 않는 모든 업무는 아웃소싱하십시오. 아웃소싱함으로써 경쟁 압력에 노출될 것이기 때문입니다.

[11] 두 사람은 댄 브릭클린(Dan Bricklin)과 밥 프랭크스턴(Bob Frankston)이었습니다. 댄은 며칠 만에 베이직(Basic)으로 프로토타입을 작성했고, 그 다음 1년 동안 함께(주로 밤에) 6502 기계어로 작성된 더 강력한 버전을 만들었습니다. 댄은 당시 하버드 비즈니스 스쿨(Harvard Business School)에 있었고 밥은 명목상 소프트웨어 작성 일자리를 가지고 있었습니다. 밥은 “사업을 하는 데 큰 위험은 없었다. 실패하면 실패하는 것이었다. 별거 아니었다.”라고 썼습니다.

[12] 제가 말하는 것처럼 그렇게 쉽지는 않습니다. 입소문이 퍼지는 데는 고통스러울 정도로 오랜 시간이 걸렸고, 우리는 월 16,000달러를 주고 PR 회사 (업계 최고임을 인정합니다)를 고용하고 나서야 많은 언론 보도를 받기 시작했습니다. 하지만 유일한 중요한 채널은 우리 자신의 웹사이트였다는 것은 사실이었습니다.

[13] 맥(Mac)이 그렇게 훌륭했다면 왜 실패했을까요? 다시 비용 때문입니다. 마이크로소프트는 소프트웨어 사업에 집중했고, 애플 하드웨어에 값싼 부품 공급업체들을 대거 투입했습니다. 중요한 시기에 정장 차림의 사람들이 경영권을 장악한 것도 도움이 되지 않았습니다.

[14] 웹 기반 애플리케이션을 돕고, 차세대 소프트웨어가 마이크로소프트에 의해 가려지지 않도록 도울 한 가지는 좋은 오픈 소스 브라우저일 것입니다. 모질라(Mozilla)는 오픈 소스이지만 오랫동안 기업 소프트웨어였기 때문에 어려움을 겪은 것 같습니다. 활발하게 유지보수되는 작고 빠른 브라우저는 그 자체로 훌륭한 것이 될 것이며, 아마도 기업들이 작은 웹 기기를 만들도록 장려할 것입니다.

다른 것들 중에서도, 적절한 오픈 소스 브라우저는 HTTP와 HTML이 계속 진화하도록 할 것입니다(예: 펄(Perl)처럼). 웹 기반 애플리케이션은 링크를 선택하는 것과 링크를 따라가는 것을 구별할 수 있다면 크게 도움이 될 것입니다. 이를 위해 필요한 것은 HTTP의 사소한 개선뿐입니다. 요청에 여러 URL을 허용하는 것입니다. 계단식 메뉴도 좋을 것입니다.

세상을 바꾸고 싶다면, 새로운 모자이크(Mosaic)를 작성하십시오. 너무 늦었다고 생각하십니까? 1998년에 많은 사람들이 새로운 검색 엔진을 출시하기에는 너무 늦었다고 생각했지만, 구글(Google)은 그들이 틀렸음을 증명했습니다. 현재 옵션이 충분히 형편없다면 항상 새로운 것을 위한 공간이 있습니다. 먼저 모든 무료 OS에서 작동하는지 확인하십시오. 새로운 것은 사용자로부터 시작됩니다.

[15] 아마도 개인적인 경험을 통해 이 문제에 대해 누구보다 잘 아는 트레버 블랙웰(Trevor Blackwell)은 다음과 같이 썼습니다:

“저는 서버 기반 소프트웨어가 프로그래머들에게 너무 힘들기 때문에, 대기업으로부터 근본적인 경제적 변화를 야기한다고 더 나아가 말하고 싶습니다. 그것은 프로그래머들이 자신의 회사일 때만 기꺼이 제공할 의지가 있는 종류의 강도와 헌신을 요구합니다. 소프트웨어 회사들은 너무 힘들지 않은 환경에서 일할 숙련된 사람들을 고용할 수 있고, 고난을 견딜 미숙련 사람들을 고용할 수 있지만, 매우 숙련된 사람들이 죽어라 일하도록 고용할 수는 없습니다. 자본이 더 이상 필요하지 않으므로, 대기업은 내세울 것이 거의 없습니다.”

[16] 이 에세이의 원본 버전에서는 자바스크립트(Javascript)를 피하라고 조언했습니다. 그것은 2001년에는 좋은 계획이었지만, 이제 자바스크립트는 작동합니다.

감사합니다. 이 글의 초고를 읽어준 사라 할린(Sarah Harlin), 트레버 블랙웰(Trevor Blackwell), 로버트 모리스(Robert Morris), 에릭 레이먼드(Eric Raymond), 켄 앤더슨(Ken Anderson), 댄 기핀(Dan Giffin)에게; 비지칼크(VisiCalc)에 대한 정보를 제공해준 댄 브릭클린(Dan Bricklin)과 밥 프랭크스턴(Bob Frankston)에게; 그리고 다시 BBN에서 강연하도록 초대해준 켄 앤더슨(Ken Anderson)에게.

이 에세이와 14개의 다른 에세이는 해커와 화가(Hackers & Painters)에서 찾을 수 있습니다.