사용자는 애플리케이션의 20%만 신경 쓴다

• 대부분의 사용자는 애플리케이션 기능중 자신에게 필요한 20% 정도만 활용하는데, 그 20%는 사용자마다 다름
• 나머지 80% 기능은 방해 요소로 여겨지기도 하며, 오히려 불편이나 불만을 유발함
• 틈새 시장을 정확히 겨냥하면 강력한 사용자 기반을 구축할 수 있음
• 대기업이 무시한 20%를 잘 해결해 충성도 높은 시장을 만든 Kagi, Figma, Notion 같은 사례는 새로운 시장 기회를 보여줌
• VS Code, Slack, Discord는 확장성과 개인화를 통해 사용자가 스스로 자신만의 20%를 최적화하도록 지원함
• 핵심은 모든 사람을 위한 제품이 아니라, 각자가 원하는 부분을 깊이 만족시켜주는 도구를 만드는 것이며, 이것이 기능 비대화 문제를 피하는 길임

---

어린 시절 경험과 소프트웨어의 사용 방식

• 필자는 어릴 때 2GB 저장 공간을 관리하기 위해 쓸데없는 파일을 지우며 컴퓨터를 자주 망가뜨림
  • .ini 파일 같은 중요 시스템 파일을 지운 뒤에는 Windows와 Office 97을 처음부터 다시 설치해야 했음
• 아버지는 Excel 설치를 꼭 챙기라고 강조했지만, 필자에게 Excel은 Word에서 표를 붙여넣기 위한 도구에 불과했음
• Excel의 수많은 기능 중 오직 표 복사/붙여넣기만이 본인에게 의미 있었음
• 지인도 Excel을 가계부로만 사용해보았고, 다른 기능들은 손대지 않았음

모두의 다른 20%

• 소프트웨어 사용에는 '80/20 법칙'이 존재함: 대부분의 사용자는 전체 기능의 20% 만 사용함
• 하지만 각 사용자가 집중하는 20%는 서로 다르며, 본인이 쓰는 부분이 가장 중요하다고 생각함
  • 예: Word에서 표 작성은 쓰지만 메일 머지는 쓰지 않음, Excel에서 피벗 테이블은 쓰지만 스크립트는 쓰지 않음, PowerPoint에서 애니메이션은 안 씀
• 새로운 기능 추가나 UI 변경 업데이트로 인해 애플리케이션이 느려지거나 불필요한 기능이 늘어났다고 느껴 불만이 생김
• 사용하지 않는 80%의 기능이 오히려 20%의 워크플로우를 방해하는 요소로까지 여겨질 수 있음

완벽한 결과에 대한 갈망

• 이런 현상은 Microsoft뿐만 아니라 다른 IT 기업에도 동일하게 나타남
• 예를 들어 Google Search에서 정확한 키워드 검색을 원할 때, 불필요한 관련어 검색 결과가 오히려 불만으로 이어짐
• 기업 입장에서는 "1%의 사용자 요구"로 치부할 수 있지만, 10억 명의 1%는 천만 명이라는 거대한 시장임
• Kagi는 Google이 간과하는 작은 시장에 특화하여 개인정보를 보호하고 광고 없는 품질 중심의 검색이라는 차별화로 시장을 공략했음
• 거대 기업의 빈틈을 공략하면 작은 사용자 그룹을 만족시키는 틈새 시장 형성이 가능해짐
• 모든 사람을 만족시킬 필요는 없고, 특정 집단의 20% 경험을 완벽히 만족시키는 전략을 수립하는게 가능

잊혀진 20% 찾기

• 많은 혁신적인 기업들이 거대 기업이 놓치는 특정 사용자 집단을 집중적으로 공략함
• Figma는 협업 디자인 부분에서 Adobe를 뛰어넘는 것에 집중했고, Notion도 특정 이용자 요구에 최적화된 하이브리드 도구로 자리잡음
• 성공한 소프트웨어는 시간이 지나며 기능이 늘어나지만, 이 과정에서 특정 사용자들의 20%가 묻혀버리는 틈새가 생김
• 오픈 소스 소프트웨어는 특정 워크플로우에 특화된 커스텀 빌드를 만들 수 있어 이 분야에서 강점 발휘
  • 예시로 Blender에서 아키텍처 시각화만을 위한 경량 버전 개발이 가능함

올바른 20%를 위한 설계

• 이 철학은 VS Code에서 잘 구현됨
  • 기본 기능은 단순한 텍스트 편집에 집중하나, 확장 프로그램을 통해 각자 원하는 개발 환경을 구성할 수 있음
  • 모든 사용자가 자기만의 20%를 커스터마이즈할 수 있는 구조임
• Slack의 Integration, Discord의 봇도 같은 원리로 사용자가 직접 경험을 맞춤화할 수 있도록 지원함
• 애초에 모든 사용자의 20%를 예측하기는 힘들지만, 확장성과 커스터마이징을 제공하면 각자의 최적 활용이 가능함

결론: 모든 사용자를 위한 제품보다는, 각자의 '필요한 20%'에 집중

• 모든 기능을 다 잘하려다 보면 결국 무거워지고 불만이 늘어나는 소프트웨어 형태로 귀결됨
• 각각의 기능이 해당 기능을 찾는 특정 사용자에게 완벽하게 작동하는 데 집중하는 것이 중요함
• 사용자는 어차피 전체 기능 중 일부만 사용할 것이므로, 특정 기능을 정말 뛰어나게 만드는 데 집중하는 것이 오히려 효과적임
• 소프트웨어가 예측하지 못한 방식으로 활용될 수 있음을 인정하고, 이 다양성을 수용하는 맥락에서 기획 필요함
• 모든 부분을 사용자에게 강요하지 않고, 진정 사랑받는 부분에만 집중해 개발하는 것이 더 큰 만족으로 이어짐

[GN⁺]

Hacker News 의견

• 내가 일했던 한 SaaS 회사에서는, 사용자들이 실제로 사용하는 기능의 일부만을 기준으로 분석을 시도했던 적이 있음. 몇 가지 핵심 사용자 유형에 맞춰 제품 복잡성을 줄이고, 성가신 기능도 없애고자 했음. 결과적으로 로그인 화면을 제외하면, 모두 각자 중요하게 생각하는 20%가 전혀 달랐음. 분석 결과는 가중치를 둔 무작위 추출과 다를 바가 없었음

• 정말 공감함. 그런데 엔터프라이즈 고객에게 제품을 판매하기 시작하면 상황이 완전히 바뀜. "위생적 기능" 하나 부족하면 거래가 무산될 수 있음. 그리고 각 엔터프라이즈마다 꼭 필요한 기능이 다 다름. 위생적 기능은 화장실처럼 누구나 필요로 하는 최소 필수 요소를 비유함

  • 지금까지 같은 제품을 두 번 팔아본 적이 없다는 느낌임. 제품 로드맵은 내가 마지막으로 누구와 대화했는지에 따라 정해짐. 고객이 없으면 안 된다고 강조했던 5,000개의 '필수' 기능을 거의 프로덕션 수준으로 유지하는 기술부채로 고생하고 있음. 하지만 실제론 고객이 거의 사용하지 않음
  • 화장실은 요즘 대부분 표준이지만, 디지털 제품에서는 전혀 그렇지 않음
  • "화장실... 하루 3분만 사용"이라고 했는데, 진지하게 건강검진을 권장하고 싶음

• Spolsky 블로그 글들을 떠올리게 하는 비슷한 글임
  strategy-letter-iv-bloatware-and-the-8020-myth
  simplicity

  • Joel Spolsky의 글들이 세월이 흘러도 정말 유효하다는 것에 놀라움을 느낌. 일부는 후에 틀린 것으로 드러나기도 했지만(그래픽 카드가 얇은 마진의 사업이 될 거라고 예측했던 것 등 참고), 대부분은 지금도 진리임. 심지어 당시보다 더 설득력이 있을 수 있음
  • 두 번째(단순성) 글과 정말 비슷함. 저자가 이런 고전 포스트를 몰랐을 수도 있음. 요즘 세대는 그런 고전을 잘 안 읽는 것 같음. 참고로 Joel Spolsky, Steve McConnell, Don Norman 등 여러 명이 개발 직업에 대해 깊이 고민하고 그 생각을 기록해둠. 한 번쯤 읽어볼 만함

• 개인적인 취미 앱을 직접 만들어 봤는데, 종종 다듬어서 공개해보고 싶다고 생각함. 하지만 내 앱을 홍보하거나 알릴 의지가 전혀 없어서 공개 자체가 의미가 없다고 여김. 사실 더 큰 이유는 내가 직접 사용하지 않는 나머지 80% 기능을 구현할 의지가 없기 때문임

• 마케팅 쪽에서 Modified Pareto라는 개념이 있음. 80/20이 아니라 60/20임. 20%의 헤비유저가 60%의 제품 가치를 소비하고, 80%의 라이트유저는 40%를 소비함. 무시하기에 작은 비중이 아니므로, 가벼운 사용자도 반드시 신경 써야 함
  value-paretos-bottom-80

  • 이런 원칙을 진리로 보기보다는 반복되는 피드백 루프의 일부로 보는 것이 항상 흥미로움.
    1. 관찰: 80% 사용자가 소프트웨어 40%만 사용함
    2. 결론: 그 60% 중 일부를 잘라내자
    3. 관찰: 80% 사용자가 남은 40% 중 일부만 사용함
    4. 결론: 다시 자르자...
       이런 식임. 실제로는 사용자가 소프트웨어가 자신의 문제를 해결할 수 있다고 '인지'하는 게 훨씬 더 중요함. 만약 돈을 쓰게 만들고 싶으면, 소프트웨어가 잠재적으로 사용자의 다양한 문제도 해결할 수 있다는 느낌을 줘야 함. 그런 다양한 문제는 사용자가 직접 사용하지 않는 기능이더라도 해당될 수 있음. 예를 들어 3D 소프트웨어에서 본 리깅 시스템은 2% 사용자가 1%의 시간밖에 안 쓸지라도, 그 기능 없으면 아예 제품을 검토조차 안 하는 사람들이 있을 수 있음

• 내 작업물이 실제로 어떻게 쓰일지 예측하는 데 소질이 없어서, 흔히 "Desire paths"로 비유되는, 드러난 경로에 길을 닦는 방식만 선호함
  the-road-most-traveled-by-paving

  • IT 정책과 거버넌스도 이런 Desire path 기반으로 작성하라고 추천함. 다만 환경이 복잡해질 경우 확장성이나 비용 측면에서 문제가 생길 수 있음
  • 이건 현실 세계에서 이루어지는 텔레메트리(사용자 행태 추적)와 비슷하고, 선택적으로 빠져나갈 방법이 없음. 만약 선두주자가 아니라면 남이 걸어 놓은 길만 따라갈 수도 있음

• "기능이 늘어나는 걸 막기보다는, 소프트웨어가 상상도 못했던 방식으로 사용될 수 있다는 걸 받아들여야 한다"는 내용에 공감함. 그래서 나는 상호운용성(interoperability)이 소프트웨어의 가장 중요한 요소라고 생각함. 본문의 주요 문제는 소프트웨어별, 버전별 파일 포맷의 폐쇄성이라는 인식을 받음. 나는 도구 여러 개를 조합해서 사용하는 걸 꺼리지 않지만, 도구들이 파이프라인에서 잘 협업을 못한다는 게 문제임. Unix의 꿈은 정말 어렵다는 생각임

• 어느 정도 규모가 있는 앱에서 모든 기능이 100% 활용되는 일은 거의 없음. 내 경험상 거의 모든 애플리케이션에는 10~30% 정도 완전히 활용되지 않는 부분이 있음. 이는 주로 개발팀 빼고는 아무도 알기 힘든 방식이거나 워크플로우가 형편없고 비효율적이거나, 혹은 너무나 기본적인 기능이라 실제로 필요한 회사는 그 소프트웨어를 구입할 경제력이 아예 없을 정도임

• 맞음, 하지만 많은 사용자가 각자 다르게 중요하게 여기는 20%의 기능이 있으니, 모든 기능을 유지해야 지금의 사용자 수를 지킬 수 있음. 그래도 유지보수나 개발에 많은 시간을 잡아먹는, 거의 안 쓰이는 기능을 없애면 ROI가 상승함

• 하지만 사용자들은 반드시 같은 20%를 중요하게 생각하는 건 아님. 또 한 가지 생각해볼 점은, 사용자는 실제로 앱을 사용해 보기 전엔 어떤 기능이 있는지 잘 모름. 설치 결정은 앱에 실제로 있는 기능이 아니라, 설치 전 스스로 기대하는 기능에 기반해서 이뤄짐. 이게 중요한 차이임. 기능에 노력을 들여도, 실제로는 유저를 확보한 뒤에야 결실을 얻게 됨.
  MVP(최소 기능 제품) 만들 때 특히 중요한데, 대부분의 경우 설치와 지속 사용을 막는 건 기능의 부족이 아님. 보통은 메시지 전달, 마케팅, 혹은 아예 사용자가 끌릴 만한 가치가 없는 경우임. 기능을 마구 추가해도 이런 문제는 해결 안 됨. 이건 단순해 보여도 많은 회사가 놓치는 부분임.
  가장 단순한 MVP는 일단 아무것도 구현하지 않아도, 사람들이 사전 등록하도록 유도하는 것부터임. 이런 방식으로 메시지가 제대로 전달되고 있는지 검증할 수 있음. 가입 후 실망한다면, 최소한 메시지는 잘 전달된 셈임.
  다만 이렇게 하면 MVP가 약속한 만큼 완성돼 있지 않은 상태로 출시하게 되고, 미완성된 약속으로 실망감을 줄 위험이 생김. 또, 많은 기능이 사실 없어도 그만인 경우가 많은데, 특히 SaaS에서는 실제로 돈을 지불할 만큼 필수적이지 않은 기능이 많음. 고객의 요구사항을 곧바로 필수 요건으로 받아들이는 대신, 그들이 진짜로 '가치' 있다고 생각하는지, 실제로 비용을 지불할 의사가 있는지, 정말 중요한 고통점을 해결하는지 등을 꼭 명확히 파악해야 함. 고객의 요청이 왜 나왔는지를 이해하는 게 곧바로 그 기능을 만드는 것보다 훨씬 더 중요함

  • "사용자들이 같은 20%를 중요하게 생각하는 게 아니라"라는 한 문장만 보고 긴 댓글을 쓴 건지 궁금함
  • "사용자들이 같은 20%를 중요하게 생각하는 게 아니라"가 바로 이 글의 핵심임