Sun이 잘못한 것

AI 요약

Oxide는 연례 행사인 OxCon을 앞두고 과거 컴퓨터 기업을 기리는 로고 티셔츠를 만들었습니다. Sun을 기리는 셔츠는 Sun에 대한 향수를 불러일으켰습니다. 글쓴이는 Sun이 남긴 좋은 유산을 인정합니다. Oxide의 설립 목표도 Sun의 전 CEO Scott McNealy가 남긴 말과 연결되어 있습니다. McNealy는 28년 동안 자녀에게 신문을 부끄러워하며 숨겨야 했던 적이 없었다고 회고했습니다. 글쓴이는 모든 기업이 따라야 할 기준으로 이 말을 제시합니다.

■ Sun이 놓친 것은 사업 운영의 기본입니다

Sun에 대한 향수는 때로 과거를 지나치게 미화합니다. Sun 이후 세대라면 Sun이 무엇을 잘못했는지 물을 만합니다. 글쓴이는 자신도 Sun에서 일한 일을 부끄러워하지는 않았지만, 회사가 저지른 실수 때문에 난처했던 순간은 자주 있었다고 말합니다. 여러 Sun 직원이 각자 다른 실패 원인을 들겠지만, 글쓴이가 15년 전부터 유지해 온 판단은 더 단순하게 정리됩니다. Sun은 사업을 운영하는 기초적인 업무에 흥미를 잃었습니다.

여기서 말하는 운영은 거창한 전략이 아닙니다. 고객 전화를 받고, 고객에게 맞는 제품을 찾고, 가격과 계약을 조율하고, 실제 장비를 전달하는 일입니다. Sun은 이 과정을 점점 중요하지 않게 다뤘습니다. 글쓴이는 전략이 아무리 좋아도 회사가 사업 운영의 기본에 싫증을 내면 성공할 수 없다고 봅니다.

■ OpenSolaris 고객을 놓친 과정입니다

2005년, 한 스타트업이 OpenSolaris로 인프라를 운영하면서 Sun 장비를 대량으로 구매하려 했습니다. Sun이 Solaris를 오픈소스로 공개한 전략이 실제 사업으로 이어질 기회였습니다. 스타트업은 Sun의 소프트웨어를 사용하고 있었고, 빠르게 성장하면서 더 많은 Sun 하드웨어를 필요로 했습니다. 오픈소스 소프트웨어와 상용 하드웨어가 함께 작동하는 사업 모델이 이미 나타난 셈입니다. 훗날 클라우드 컴퓨팅이라고 부르게 될 방식을 개척하던 기업이기도 했습니다.

하지만 스타트업은 Sun의 전화를 받기 어려웠습니다. Sun이 전화를 받았을 때도 고객이 필요로 하지 않는 제품을 팔려고 했습니다. 반면 Dell에서는 한밤중에 웹 양식을 작성하자 다음 날 아침 지역 담당 영업사원 Steve가 전화를 걸었습니다. Steve는 스타트업이 특정 가격 등급에 들어갈 수 있도록 2주도 안 되는 기간에 필요한 절차를 진행했습니다. 데이터센터에 서버를 설치했고, 개인 보증 없이 회사 재무 정보만으로 장비 임대도 성사시켰습니다. 고객은 모든 일의 95%를 Steve가 처리했다고 회고했습니다. 작은 스타트업이 마치 대기업이 된 듯 느꼈고, Steve가 자신들을 위해 일한다고 느꼈습니다.

이 경험은 스타트업이 작성한 블로그 글 ‘The Sun Doesn’t Shine on Me’에 기록됐습니다. 글쓴이는 당시 Fishworks를 막 시작하고 Sun의 버려진 사무실 한쪽을 임시 공간으로 쓰고 있었습니다. 그 글을 읽으며 마음이 무너졌다고 말합니다. Sun이 소프트웨어와 하드웨어 전략에서는 성공할 가능성을 보여줬지만, 고객을 실제 구매로 이끄는 운영에서 실패했기 때문입니다.

■ 전략적 성과를 운영 실패가 뒤집었습니다

OpenSolaris를 사용하던 고객은 Sun이 바라던 이상적인 사례였습니다. Sun의 소프트웨어를 사용하던 기업이 Sun의 하드웨어도 구매하려 했습니다. 그러나 Sun은 고객의 연락을 받지 못했고, 연락이 닿은 뒤에도 적합하지 않은 제품을 제안했습니다. Dell은 기술적 비전보다 영업 실행과 고객 대응에서 앞섰습니다. 결과적으로 거래 기회를 가져간 쪽은 Sun이 아니라 Dell이었습니다.

글쓴이는 Sun이 몇 년 더 존속하는 동안 회사를 되살리려 최선을 다했지만 충분하지 않았다고 말합니다. Sun은 결국 살아남지 못했습니다. 글쓴이는 Sun을 떠난 뒤 바로 그 스타트업에 합류했습니다. Sun이 놓친 고객이었습니다. Dell의 Steve도 나중에 그 스타트업이 채용했고, 몇 년 뒤 글쓴이와 함께 Oxide를 창업했습니다. 한 기업이 놓친 고객과 영업 담당자가 훗날 다른 기업의 출발점이 된 셈입니다.

■ Sun을 기억하는 방식입니다

Oxide가 Sun과 사라진 다른 컴퓨터 기업을 기리는 이유는 단순한 향수 때문이 아닙니다. 잘한 일은 존중하되, 잘못한 일은 반복하지 않으려는 태도입니다. 과거 기업의 기술과 문화를 본받는 일에는 경고도 포함되어야 합니다. 좋은 전략과 기술만으로는 부족합니다. 고객이 연락할 통로를 만들고, 적합한 제품을 제안하고, 계약과 납품을 끝까지 처리하는 운영이 함께 굴러가야 합니다.

■ Lobsters 반응

• @david_chisnall — Sun은 다른 일도 많이 잘못했습니다. 저는 Sun을 외부에서만 봤지만, 수천 마일 떨어진 곳에서도 회사의 기능 장애가 뻔히 보였다면 뭔가를 다르게 해야 했다는 뜻입니다. SPARC는 꽤 탄탄한 아키텍처였고, 레지스터 윈도우의 비동기 스필링 같은 몇 가지를 손봤다면 훌륭한 아키텍처가 될 수 있었습니다. 그런데 Sun은 그렇게 되지 않도록 회사를 구성했습니다. 하드웨어 팀과 소프트웨어 팀이 함께 설계할 수 있었지만, 소프트웨어 팀을 초기에 참여시키는 일은 드물었습니다. SPARC가 명령어 캐시의 브로드캐스트 무효화를 언제 지원했는지는 기억나지 않지만, Solaris가 이미 병목이라고 파악한 뒤에도 오랫동안 지원하지 않았습니다. 실행 가능한 매핑을 사용하는 mmap마다 IPI를 보내고 모든 코어와 랑데부해야 했기 때문입니다. 멀티코어 시스템에서 프로세스 생성 시간이 크게 느려졌고, UNIX는 수명이 짧은 프로세스를 자주 생성하는 방식을 장려합니다. JIT 컴파일러를 추가하면, 음, Java가 있었고 Sun이 Java에 관심이 있었던 것 같은데, 상황은 훨씬 나빠졌습니다. 말기에는 Niagara 팀과 Rock 팀이 SPARC를 맡았습니다. 한 팀은 대규모 멀티코어 및 멀티스레드 시스템으로 확장할 단순한 인오더 코어를 만들었고, 다른 팀은 단일 스레드 성능에 집중했습니다. 두 팀은 서로 다른 시장을 겨냥하고, 장기적으로는 Rock 프로젝트 코어를 소수만 넣고 Niagara 프로젝트 코어를 다수 넣는 이기종 SoC를 만드는 방향을 잡았어야 합니다. 하지만 두 팀은 경쟁 관계로 구성됐고, 공동 관리자로...