개발을 하다 보면 한 번쯤은 이런 말을 들어봤을 것이다.
"우리도 이거 직접 써보자"
이걸 조금 더 멋있게(?) 표현한 말이 바로 Dogfooding(도그푸딩)이다.
도그푸딩이란
도그푸딩(Dogfooding)은
자신이 만든 제품을 스스로 사용하는 것
을 의미한다.
원래 표현은
“자기 개 사료를 직접 먹어본다(eating your own dog food)”에서 왔다.
조금 직설적으로 말하면 이런 뜻이다.
- 우리가 만든 제품
- 우리가 직접 써보고
- 문제를 발견하고 개선한다
왜 도그푸딩을 할까
이유는 단순하다.
1. 진짜 문제를 발견할 수 있다
사용자 입장에서 써보면 바로 느껴진다.
- 이거 왜 이렇게 불편하지?
- 여기 UX 왜 이럼?
- 속도 왜 이따위지?
-> 로그나 데이터보다 더 빠르게 문제를 찾는다
2. 책임감이 생긴다
남이 쓰는 제품 vs 내가 매일 쓰는 제품
완전히 다르다.
- 버그? 그냥 못 넘긴다
- UX? 그냥 참고 못 쓴다
-> 제품 퀄리티가 자연스럽게 올라간다
3. 의사결정이 빨라진다
회의 없이도 결론이 난다.
"이거 직접 써봤는데 불편함"
→ 바로 수정
-> 데이터보다 강한 직관이 생긴다
그런데, 도그푸딩이 항상 좋은 걸까?
여기서 문제가 생긴다.
최근 글에서는 이런 이야기를 한다.
"도그푸딩만 하면 오히려 망할 수도 있다"
문제 1. 사용자 ≠ 개발자
개발자는 일반 사용자가 아니다.
- 더 똑똑함
- 더 인내심 있음
- 더 많은 맥락을 알고 있음
그래서 이런 일이 벌어진다.
- 개발자: “이 정도면 쓸만한데?”
- 사용자: “이거 못 쓰겠는데?”
-> 착각이 시작된다
문제 2. 익숙함이 문제를 가린다
계속 쓰다 보면 적응한다.
- 불편 → 익숙해짐
- 버그 → 그냥 무시
-> 문제를 “문제”로 인식하지 못한다
문제 3. 내부 최적화 함정
도그푸딩을 하면 이런 방향으로 가기 쉽다.
- 내부 도구에 최적화
- 개발자 워크플로에 최적화
-> 결국 일반 사용자는 더 어려워짐
핵심 비유
해당 글에서 인상적인 비유가 하나 나온다.
“도그푸딩에 질렸다면, 이제는 자기 방귀 냄새를 맡아봐라”
조금 강하지만 핵심은 명확하다.
- 도그푸딩 = 자기 기준
- 방귀 비유 = 완전히 다른 관점
-> 자기 기준만으로는 부족하다
그럼 어떻게 해야 할까
답은 간단하다.
1. 도그푸딩은 기본이다
이건 해야 한다.
- 내부 품질 확보
- 빠른 피드백
2. 하지만 반드시 외부 테스트를 붙여야 한다
- 실제 사용자 테스트
- 베타 사용자
- 로그 기반 분석
-> 현실 검증
3. “이해한다” vs “겪는다”
개발자는 기능을 이해한다.
사용자는 경험을 겪는다.
이 차이를 절대 무시하면 안 된다.
결론
도그푸딩을 한 줄로 정리하면
좋은 시작이지만, 절대 끝이 아니다
진짜 중요한 것
제품은 결국 이걸 기준으로 평가된다.
- 내가 쓰기 좋은가 X
- 사용자가 쓰기 좋은가 O
마무리
도그푸딩은 필요하다.
하지만 그것만 믿으면 위험하다.
진짜 좋은 제품은
내가 아니라, 사용자가 편한 제품이다
