Hacker News 의견들

• Jeff Bezos가 고객센터에 직접 전화해 10분 넘게 기다렸다는 일화가 있음
  나도 예전에 관료주의와 정치 싸움이 심한 회사에서 일했음. 회의 중 실제 앱을 열어 문제를 보여주면, 슬라이드로만 예쁜 그림을 보여주던 리더들이 당황했음. 결국 나는 현실을 보여준다는 이유로 내부의 ‘적’이 되었음

  • 나도 정부 기관 같은 극단적 관료 조직에서 일함. 현장 엔지니어용 앱의 SSO가 깨져 있었는데, PM은 “Apple과 Google 문제”라며 책임을 회피했음. 결국 Edge 브라우저에서만 되는 우연한 해결책을 찾았고, 정책 충돌로 또 막혔음. 내부 위키를 보니 이 문제는 내가 입사하기 11개월 전부터 기록돼 있었음
  • 이런 상황이 이해가 안 됨. 왜 창업자 출신의 C-suite가 직원들과 직접 대화하지 않는지 의문임. 미 해군 원자로 부대에서는 매년 제독이 직접 함선을 돌며 병사들과 이야기함. Admiral Zumwalt는 이런 대화로 70가지 제도를 개선했음
  • Oracle Cloud Infrastructure 초기 시절, Larry Ellison 앞에서 라이브 데모를 했던 경험이 있음. 대부분 슬라이드만 보여주던 다른 팀과 달리, 실제 동작을 보여줬더니 Larry가 크게 감명받았음. 언제부터 기업들이 현실 대신 ‘슬라이드 세계’로 빠지는지 종종 생각함
  • 네가 묘사한 회사 문화가 Amazon식 문화와 닮았다는 점이 흥미로움
  • Bezos가 고객센터에 직접 전화하던 시절은 이미 지났음. 기업이 너무 커지면 CEO가 직접 그런 일을 할 필요가 없어짐

• 예전 직장에서 VP of Product가 “eat your own dogfood”라는 표현이 ‘역겹다’며 “drink your own champagne”으로 바꾸자고 했음. 하지만 나는 일부러 불편한 표현이 공감대를 만든다고 생각함. 고객의 입장에서 제품을 조기에 체험하는 게 핵심임

  • 이 표현의 기원은 80~90년대 VC들이 쓰던 “Will the dogs eat the dog food?”에서 비롯됨. Microsoft 임원에서 시작됐고, Marc Andreessen도 Mixpanel을 두고 같은 표현을 썼음 (GeekWire 기사 참고)
  • 나도 이 표현이 거북하다고 느낀 적은 없음. 다만 기사 제목이 너무 저속한 유머라 처음엔 읽기 싫었음
  • “dogfood”가 맞는 이유는, 우리가 제품의 직접 대상이 아닐 수도 있기 때문임. 즉 “이걸 내 개에게 먹일 수 있겠는가?”라는 질문임
  • 사냥 유튜버가 자신과 개에게 같은 음식을 만들어 먹는 걸 봤음. 도구로서의 개와의 신뢰 관계를 보여주는 좋은 예임
  • 나는 “champagne” 쪽이 더 좋다고 느낌. 정제되고 매력적인 제품을 목표로 한다는 의미가 명확하기 때문임

• 나는 고객센터가 나쁠 거라고 항상 기대치 낮게 접근함. 오래 걸리더라도 인내심으로 버티는 게 요령임. 아버지는 여전히 돈을 낸 만큼 서비스를 못 받으면 분노함. “이 통화 녹음되고 있죠?”라고 말하는 걸 즐김

  • 최근 iPhone의 자동 대기 기능 덕분에 Delta 항공과의 2.5시간 대기 중에도 편하게 기다릴 수 있었음. 덕분에 통화할 때 상냥하게 대했더니 업그레이드까지 받았음
  • 고객센터 직원은 대부분 저임금 감정노동자임. 화를 내기보다 협력하는 게 낫다고 생각함. 예전에 Comcast에 전화했을 때 농담을 던졌더니 엔지니어가 직접 연락해 문제를 해결해줬음

• “Eat your own dog food and smell your own farts”라는 문구가 기억에 남음. 전자는 제품을 직접 써보라는 뜻, 후자는 고객지원·결제 등 숨겨진 부분까지 체험하라는 의미임

  • 하지만 “fart” 비유는 논리적으로 맞지 않다고 느낌. 개 사료는 실제로 팔지만, 방귀를 모아 팔진 않음. 게다가 사람은 자기 냄새엔 둔감하니 품질 개선에 도움이 안 됨
  • 게다가 “sniff your own farts”는 이미 ‘자기 기만에 빠지다’는 부정적 의미로 쓰임. dogfooding은 칭찬이지만, 이건 반대임

• 저자는 dogfooding을 고객지원 맥락에서 신성시하지만, 대기업에서는 고객지원이 제품의 일부로 간주되지 않음. Facebook이나 Google 직원이 일반 고객센터를 이용하지는 않음

  • 내가 일하는 회사는 다름. 직원이 문제를 발견하면 고객과 같은 티켓 시스템으로 직접 신고해야 함
  • 그래서 “smelling your own farts”라는 표현이 여기서 맞아떨어짐

• dogfooding은 강제로 해야 할 때가 많음. 하지만 잘못하면 실제 사용자와 다른 문제를 해결하게 됨.
  우리 팀은 법률 문서용 워드프로세서 Tritium을 만들고 있는데, Word처럼 쓰면 방향이 흐려짐. 그래서 블로그 글에서 이 균형에 대해 썼음.
  이런 이유로 B2B SaaS에서는 상용 소프트웨어가 오히려 QA에 유리하다고 느낌

• 작은 회사는 직접 고객의 고통을 느끼는 구조라서 문제 해결이 빠름. 반면 대기업은 각자의 역할이 너무 작아 고객 영향이 보이지 않음. 그래서 지표화된 피드백 시스템으로 대체하지만, 신호 손실이 큼

  • 그래서 고위 리더가 직접 제품을 써보고 고객과 대화하는 게 중요함. 부서 간 사일로와 관료 장벽을 뚫을 수 있는 유일한 방법임
  • 나도 작은 회사에서 고객지원 팀을 관리하지만, 요즘 엔지니어링 팀의 무책임이 걱정임. 기술 부채와 일정 압박을 이유로 고객 문제를 외면함. Jira에 세부 항목만 늘리고 실제 dogfooding은 하지 않음

• 나에게 dogfooding은 단순한 충성심이 아니라, 개발 중인 제품을 직접 써보며 테스트하는 과정임. 즉, 제품이 가장 거칠 때 스스로 먹어보는 행위임

• 개발자와 아키텍트가 자신이 만든 시스템의 운영에 책임을 지지 않을 때 문제가 생김. 이건 “no skin in the game”의 전형임

  • 아마도 그건 moral hazard라고 부를 수 있을 것임 (위키피디아 링크)

• 고객센터 경험 중 가장 어이없던 두 가지

  1. 자동차 보험 해지 전화를 했는데, 중동에서 귀국하는 법 같은 불필요한 안내를 길게 들었음
  2. 인터넷이 두 주째 끊겼는데, 상담원이 스트리밍 번들 업셀링을 시도함.
     대부분의 문제는 형편없는 셀프서비스 웹사이트 때문임. 단순한 정보만 제공해도 콜센터 비용을 크게 줄일 수 있음
  • 나도 비슷한 경험이 있음. 10분 기다린 끝에 다른 부서로 돌려보내더니 다시 처음 메뉴로 돌아왔음. 완전한 Kafka식 순환 구조였음. 두 헬프데스크를 합치면서 데이터 접근이 막혀버린 결과였음.
    심지어 경쟁사 헬프데스크가 더 유용했음. 하지만 독점 구조라 이용할 수 없었음