dogfooding

Dogfooding 은 자사 제품이나 서비스를 직원들이 일상적으로 사용하고 제품의 문제점을 확인하는 것을 말하는 것으로 사용자 관점에서 제품의 품질과 UX를 확인하는 것입니다.

기업 IT환경이 모바일과 웹 기반으로 전환되면서 개발자들 스스로 사용자 입장에서 자신들이 만든 제품이나 서비스를 체험하고 개선해야 하는 과정들이 필요하게 되었습니다.

특히 모바일 단말 환경이나 웨어러블 장치들 경우에는 개발자 입장에서도 UX (User Experience)에 대한 테스트가 많이 필요하게 됩니다.

이런 분위기 때문인지 최근에 종종 접하게 되는 단어가 바로 Dogfooding 입니다.

1988 년, 마이크로 소프트의 매니저였던 Paul Maritz 가 “Eating our own Dogfood”이라는 제목의 내부 이메일에서 테스트 매니저 Brian Valentine에게 직원들이 자사 제품을 더 쓰도록 강요하면서 많이 유명해진 말입니다.

Dofooding 이란?

최근에는 구글에서도 자사의 새로운 제품과 서비스들를 직원들이 실험하는 것으로 알려지기도 하였습니다.

하지만 이 이야기의 시작은 애완견 사료 제조업체인 마스(Mars)의 경영진이 실제로 오래전부터 자기들이 생산하는 개 사료를 직접 먹은 것에서 비롯되었습니다.

Eating your own dog food, also called dogfooding, is a slang term used to reference a scenario in which a company uses its own product to test and promote the product.

위키페디어 – https://en.wikipedia.org/wiki/Eating_your_own_dog_food

위키페디어를 의역하자면 개 사료를 먹으라는 뜻의 dogfooding은 자사의 제품을 직원들이 직접 사용 해보고 개선시키는 방법을 일컫는 속어라고 정의되어 있습니다 .

제품이나 서비스 개발에서 있을 수 있는 다음과 같은 문제점 때문입니다.

  • 개발자는 사용성 및 일반 사용자의 지식량을 고려하지 않고 기능을 개발
  • 소프트웨어의 릴리즈를 정식 버전이 아닌 베타판 수준으로 발표
  • 자사에서 제품을 만드는 환경과 시스템으로만 구축 및 테스트

Dogfooding 이 필요한 이유는 무엇일까요?

하지만 유명 쉐프들이 집에서는 요리를 하지 않거나 자신 만든 음식은 먹지 않는 것와 개발자들이 자신이 만든 제품이나 서비스를 사용하지 않는 것은 비슷한 이유일 것입니다.

Dogfooding과 같이 협오스러운 단어까지 쓰면서 제공자가 직접 사용해야 하는 이유는 무엇일까요?

첫 번째, 개발자 스스로 불편한 진실을 봐야 한다는 것입니다. 내가 작성한 소프트웨어는 완전하다(?)고 생각하겠지만, 개밥을 먹는 순간 불편한 진실을 봐야 하는 것입니다.

일반적으로는사용자가 버그 리포트를 해서 시작되는 패치 프로세스가 아닌 개발자 스스로 버그를 찾고 패치하는 것이기 때문에 가장 빠른 패치 방법일 것입니다.

두 번째, 개발자는 편이성과 사용자의 수준을 고려하지 않고 기능을 추가하는 경우가 많기 때문입니다.

개발자는 항상 베타 버전에서만 테스트하기 때문에 사용자의 실질적인 불편을 지나치는 경우도 있습니다. 서비스의 개선 측면에서 매우 좋은 방법일 것입니다.

마지막으로 개발자가 해당 분야의 가장 전문가라는 것입니다.

테스트 데이터 구성이나 QA 프로세스 등에 대한 복잡한 절차 없이 해당 서비스의 최고 전문가가 직접 서비스의 문제점을 확인하는 것입니다.

Dogfooding 의 효과

그렇다면 Dogfooding 의 효과는 어떤 것이 있을 까요?

  • 사용자의 생생한 목소리를 직접 들을 수 있는 것입니다.
  • 테스트와 직접 사용하는 것은 다른 것이기 때문에 제품 개선 사이클이 향상 됩니다.
  • 제공하는 서비스나 제품에 대한 애착이 커지게 됩니다.

하지만 사용자의 불편만 쫓다 보면 외형만 집중하기 때문에 서비스 내실은 약해질 수 있습니다.

개발팀 스스로가 제품의 로드맵이나 기능 개선에 신경을 쓰지 못하고 사용자 기능에만 촛점을 맞추게 됩니다.

개발팀과 품질관리팀 그리고 고객대응팀 등의 전문적인 역할이 애매해 지면서 개발팀의 부담이 커지게 되는 문제가 발생할 수 있습니다.

개발팀의 일정 계획에 혼란이 올수도 있습니다.

Dogfooding이 단점이 없는 것은 아니지만 개발팀 스스로 문제를 찾고 개선해 나가는 것이 제품이나 서비스의 완성도를 높이는 데 가장 효율적인 방법일 것입니다.

아무리 뛰어난 쉐프라고 하더라도 가끔은 본인이 만든 음식을 먹어보는 여유가 필요하지 않을까요?

References & Related Links