개밥먹기의 전설들: 스티브 잡스가 iPhone에 스크래치를 낸 이유

토요일 아침의 긴급 소집

2007년, iPhone 출시를 몇 주 앞둔 어느 토요일 아침이었습니다.

스티브 잡스가 애플 임원들을 긴급 소집했습니다. 그의 손에는 프로토타입 iPhone이 들려 있었는데, 화면에 흉측한 스크래치가 나 있었죠.

"플라스틱 스크린은 안 된다. 유리로 바꿔야 한다."

"하지만 출시까지 몇 주밖에..."

"그럼 출시를 늦춰라. 유리 아니면 출시 안 한다."

무슨 일이 있었던 걸까요? 잡스는 자신의 iPhone을 주머니에 넣고 다니다가 열쇠와 부딪혀 스크래치가 생긴 걸 발견한 겁니다. 직접 써보지 않았다면 절대 발견하지 못했을 문제였죠.

결국 애플은 코닝의 고릴라 글래스를 급하게 도입했고, 이것이 오늘날 우리가 아는 스마트폰의 표준이 되었습니다.

이게 바로 "개밥먹기(Dogfooding)"의 힘입니다.

개밥먹기? 그게 뭔데?

개밥먹기(Dogfooding, 또는 "Eating your own dog food")는 자신이 만든 제품을 직접 사용하는 것을 뜻합니다.

이 이상한 이름의 유래는 1970년대로 거슬러 올라갑니다. 배우 론 그린(Lorne Greene)이 출연한 알포(Alpo) 개 사료 광고에서 "이 사료가 너무 좋아서 내 개들에게도 먹인다"고 말한 것에서 시작됐죠. 또 다른 설로는 칼 칸(Kal Kan) 애완동물 사료 회사 사장이 주주총회에서 자사 개 사료 캔을 직접 먹어서 품질을 증명했다는 이야기도 있습니다.

이 표현이 테크 업계로 건너온 건 1988년입니다. 마이크로소프트의 폴 마리츠(Paul Maritz)가 "Eating our own Dogfood"라는 제목의 이메일을 보내면서 시작됐죠. 당시 마이크로소프트는 네트워킹 시장에서 Novell에게 밀리고 있었습니다.

"우리에게 고객이 없으면, 우리가 직접 고객이 되어야 한다."

이후 마이크로소프트는 내부 테스트 서버의 이름을 아예 "\dogfood"로 짓고, 직원들이 자사 제품을 사용하게 만들었습니다. 그리고 결국 Novell을 제치고 시장 1위가 되었죠.

전설의 개밥먹기 마스터들

스티브 잡스: 새벽 2시의 전화

스티브 잡스는 개밥먹기의 살아있는 전설이었습니다.

그는 자신이 만든 모든 애플 제품을 일상적으로 사용했습니다
주말이나 밤에 제품을 쓰다가 문제를 발견하면 즉시 엔지니어들에게 전화했습니다
한 엔지니어의 증언: "새벽 2시에 잡스한테 전화 와서 앱이 0.5초 늦게 뜬다고 고치라는 소리 들었다"

그는 자신의 iPod과 iTunes에 방대한 음악 라이브러리를 가지고 있었고, 직접 사용하면서 "3번 클릭으로 원하는 곡에 도달해야 한다"는 원칙을 만들었습니다. 이 원칙은 애플 제품 디자인의 핵심이 되었죠.

미야모토 시게루: 테이블 뒤집기의 달인

닌텐도의 미야모토 시게루는 잡스 못지않은 개밥먹기의 대가입니다.

슈퍼 마리오 64 개발 때의 일입니다.

개발 초기에 그는 몇 달 동안 마리오의 점프 감각만 테스트했습니다. 매일 직접 플레이하며 "점프가 0.1초 더 높아야 한다", "착지 시 반응이 이상하다"고 세밀하게 조정했죠.

"마리오를 움직이는 것 자체가 재미있어야 한다."

젤다의 전설: 시간의 오카리나 개발 중에는 더 극적인 일이 벌어졌습니다.

거의 완성 단계에서 게임을 직접 플레이해본 미야모토가 "재미없다"고 판단했습니다. 그는 던전 순서와 구조를 통째로 바꾸라고 지시했죠.

팀원들: "출시일이..." 미야모토: "재미없으면 의미없다. 늦춰도 된다."

이것이 일본 게임 업계에서 악명 높은 "ちゃぶ台返し(테이블 뒤집기)"입니다.

70대가 된 지금도 그는 계속합니다.

젤다: 브레스 오브 더 와일드 개발 중, 그는 게임을 처음부터 끝까지 여러 번 플레이했습니다.

"내가 여기서 저 산에 가고 싶었는데 갈 수 없었다. 고쳐라."

플레이어가 어디로 가고 싶어하는지, 무엇을 시도하고 싶어하는지 직접 느껴야만 알 수 있다는 게 그의 철학입니다.

다른 기업들의 개밥먹기

마이크로소프트: 2만 대 규모의 실험

마이크로소프트는 개밥먹기의 원조답게 가장 체계적으로 운영합니다.

모든 직원이 자사 제품(Windows, Office, Teams 등)을 의무적으로 사용
2005년 InfoWorld의 조사: 2만 개 이상의 노드로 구성된 글로벌 네트워크를 99% Windows로 운영 중
2014년에는 "Microsoft Elite Program"을 만들어 Xbox까지 포함한 모든 제품의 개밥먹기를 중앙화

그런데 실수도 있었습니다.

마이크로소프트의 내부 이메일 시스템은 원래 Unix(Xenix)로 돌아가고 있었습니다. "왜 마이크로소프트가 Unix를 쓰냐"는 비판이 쏟아지자, 황급히 Microsoft Exchange로 갈아탔죠.

1993-1996년 마이그레이션 기간의 내부 테스트 환경 코드명이 뭐였을까요? 네, "Dogfood"였습니다.

Lyft: CEO도 운전대를 잡는다

라이드쉐어 회사 Lyft의 개밥먹기는 독특합니다.

모든 직원은 분기당 최소 4시간을 Lyft 드라이버로 일해야 합니다.

CEO 로건 그린(Logan Green)도 예외가 아닙니다. 임원진도, 엔지니어도, 마케팅 팀도 모두 핸들을 잡고 손님을 태웁니다.

왜일까요? 앱을 만드는 것과 실제로 사용하는 것은 완전히 다르기 때문입니다. 밤늦게 취한 손님을 태우고, 복잡한 도심을 헤매고, 앱의 내비게이션이 이상한 곳으로 안내하는 걸 직접 경험해야 진짜 문제를 알 수 있습니다.

Facebook: 아이폰 직원들에게 안드로이드폰을 쥐여주다

2012년, Facebook의 안드로이드 앱은 최악이었습니다. 느리고, 버그 투성이였죠. 반면 iOS 앱은 찬사를 받고 있었습니다.

문제는? Facebook 직원 대부분이 아이폰 유저였던 겁니다.

누구도 안드로이드 앱의 문제를 제대로 경험하지 못하고 있었죠.

해결책은 간단했습니다. 직원들에게 안드로이드폰으로 바꾸도록 장려(반강제)했습니다. 그 결과 안드로이드 앱의 품질이 급격히 개선되었습니다.

Apple: 타자기 추방령

1980년 2월, 애플 사장 마이클 스콧(Michael Scott)은 사내 메모를 발송했습니다.

"즉시 적용!! 타자기를 더 이상 구매, 임대 등을 금지한다 [...] 우리는 타자기가 구식이라고 믿는다. 고객을 설득하기 전에 내부에서 먼저 증명하자."

목표: 1981년 1월 1일까지 애플에서 모든 타자기 제거.

이게 바로 애플 초창기의 개밥먹기였습니다. 자신들이 만든 컴퓨터를 직접 쓰지 않으면서 어떻게 남들에게 팔 수 있겠습니까?

개밥먹기의 어두운 면: 실패 사례들

Google+: 경영진이 외면한 SNS

Google+가 왜 실패했을까요?

기술적으로는 괜찮았습니다. Facebook에 대항할 만한 기능들도 있었죠. 하지만 결정적인 문제가 있었습니다.

구글의 경영진 자체가 Google+를 쓰지 않았습니다.

자기들이 만든 소셜 미디어 플랫폼을 사용하지 않는 사람들이, 어떻게 사용자들이 원하는 게 뭔지 알 수 있었겠습니까?

이것을 업계에서는 "fishfooding(물고기에게 개 사료를 먹이기)"의 실패라고 부릅니다. 제품을 잘못된 사람에게 테스트한 거죠.

Facebook: 개밥먹기의 역설

2021년 10월 4일, Facebook이 6시간 동안 다운되었습니다.

아이러니하게도, 문제의 원인 중 하나가 지나친 개밥먹기였습니다.

Facebook은 자사 인프라에 대한 자부심이 대단했습니다. 내부 이메일, 메신저, 심지어 전자 도어락까지 모두 Facebook 시스템으로 돌렸죠.

결과는? 시스템이 다운되자 엔지니어들이 서버실에 물리적으로 접근할 수 없었습니다. 문이 안 열렸거든요. 문 잠금장치도 Facebook으로 돌아가고 있었으니까요.

개밥먹기는 좋지만, 백업 플랜은 있어야 합니다.

개발자의 함정: 터널 비전

개발자가 자기 제품을 직접 쓰는 게 항상 좋은 건 아닙니다.

문제는 개발자는 일반 사용자가 아니라는 것입니다.

개발자는 제품의 모든 숨겨진 기능을 알고 있습니다
버그가 나도 "어, 이거 알려진 문제야"라고 넘어갑니다
복잡한 UI도 "익숙해지면 괜찮은데?"라고 생각합니다

이것이 "터널 비전"의 함정입니다.

Linux 데스크톱 개발에 참여한 Havoc Pennington의 말입니다:

"Linux '데스크톱' 개발에 진지한 팀이라면, 터미널 사용을 금지해야 한다. 물론 우리 중 누구도 이렇게 하지 않았고, 그게 결과물을 설명해준다."

CLI에 익숙한 개발자들이 터미널 없이는 살 수 없으니, 일반 사용자 관점에서 GUI를 만들지 못한다는 뜻이죠.

왜 개밥먹기가 중요한가?

1. QA팀이 못 잡는 버그를 찾는다

Garmin, Microsoft 같은 거대 기업들도 버그 투성이 제품을 출시한 적이 많습니다.

왜? 아무리 철저한 테스트도 실제 사용 환경을 완벽히 재현할 수 없기 때문입니다.

직원들이 실제로 제품을 쓰면서 일을 하면, QA 랩에서는 절대 발견할 수 없는 문제들을 찾아냅니다.

2. 고객 공감 능력이 생긴다

제품을 만들기만 하는 것과 직접 사용하는 것은 완전히 다릅니다.

고객의 불편함, 좌절감, 기쁨을 몸소 체험해야만 진짜 이해할 수 있습니다.

3. 마케팅 효과

"우리도 우리 제품을 씁니다"는 강력한 메시지입니다.

반대로, IBM이 내부에서 Microsoft Word를 주로 쓴다는 게 1990년대에 알려졌을 때? 참담한 스캔들이었죠. 자기네 워드프로세서를 자기들도 안 믿는다는 뜻이니까요.

4. 빠른 반복과 개선

개발자가 직접 사용자라면, 피드백 루프가 즉각적입니다.

문제 발견 → 인식 → 수정까지의 시간이 극적으로 줄어듭니다.

올바른 개밥먹기를 위한 원칙

1. 개발팀만 테스트하지 마라

개발팀은 제품을 너무 잘 알기 때문에 나쁜 테스터입니다.

다양한 부서의 직원들을 참여시키세요. 영업팀, 마케팅팀, 총무팀까지.

2. 진짜 사용자처럼 사용하라

Coca-Cola가 사무실에서 Pepsi를 금지하는 건 개밥먹기가 아닙니다.

실제 업무에 사용해야 합니다. 그냥 구색 맞추기로 실행하는 건 의미 없습니다.

3. 외부 테스트도 병행하라

개밥먹기는 만능이 아닙니다.

직원들은 아무래도 편향되어 있습니다. 베타 테스트, 사용자 연구 등을 함께 진행해야 합니다.

4. 백업은 있어야 한다

Facebook의 실수에서 배우세요.

모든 걸 자사 제품으로만 돌리면, 한 번의 장애가 재앙이 됩니다.

마치며: 개밥은 맛있어야 한다

개밥먹기의 핵심은 간단합니다.

자기가 만든 개 사료를 먹을 자신이 없다면, 개에게도 먹이지 마라.

스티브 잡스는 iPhone을 주머니에 넣고 다녔습니다. 미야모토 시게루는 70대에도 자신의 게임을 처음부터 끝까지 플레이합니다. Lyft의 CEO는 직접 운전대를 잡습니다.

그들은 자신의 제품을 사랑하고, 사용하고, 그 과정에서 개선합니다.

당신이 만든 제품을 당신은 매일 사용하고 있나요?

만약 아니라면, 그 이유를 진지하게 생각해봐야 합니다.

결국 최고의 제품은 만드는 사람이 진짜로 쓰고 싶은 제품입니다.

P.S. 요즘은 "개밥먹기"라는 표현이 너무 거칠다고 해서 "샴페인 마시기(Drinking your own champagne)"나 "아이스크림 먹기(Eating your own ice cream)" 같은 순화된 표현을 쓰기도 합니다. 하지만 역사와 임팩트를 생각하면 역시 "개밥먹기"가 제맛이죠.

P.P.S. 2024년 7월 CrowdStrike 대란 이후, CEO가 미국 의회에서 증언하며 "개밥먹기를 더 강화하겠다"고 약속했습니다. 전 세계 수백만 대의 컴퓨터를 다운시킨 뒤에야 개밥먹기의 중요성을 깨달은 거죠. 교훈: 개밥은 미리미리 드세요.