기본 콘텐츠로 건너뛰기

카노 모델과 피쳐 크리프(Feature creep)

피쳐 크리프라는 말이 있다.

자세한 것은 위키피디아에게 물어보라.

Feature creep is the proliferation of features in a product such as computer software. Extra features go beyond the basic function of the product and so can ...


구글신에게 물어봐도 무슨 예기인지 아주 친절하게 알려주는 수많은 웹페이지를 볼 수 있다. 그만큼 아주 유명한 단어 중 하나이다.

결론적으로 말하면 피쳐 크리프란 개발 중 이런 저런 이유로 원래 계획과 상관 없이 덕지 덕지 붙게 되는 기능들을 말한다.

이러한 경우를 우리는 주변에서 아주 쉽게 경험할 수 있다.

그리고 그러한 경우 대부분 공통적으로 하는 말이 사용자를 위해서이다.

하지만 정작 개발과정에서 사용자의 의견이 반영되는 경우는 거의 없다.

테스터 뿐만 아니라 개발에 관련된 모든 사람들은 가장 최우선적으로 고려해야할 사람은 사용자이다.

하지만 개발 과정에서 사용자와 접촉할 수 있는 기회는 매우 제한적이다. 그리고 그러한 정보의 공유 역시 매우 제한적인 것이 현실이다.

마케팅 부서 또는 UX 관련 부서에서 진행 된 사용자 조사를 우리는 얼마나 신뢰할 수 있을까?

사용자로부터 데이터를 얻어내는 방법은 무수히 많은 방법들이 있다.

그중에서 이번에는 카노 모델이라는 것에 대해 소개해 보고자 한다.

카노 모델이라 하면

2009년 3월 31일 ... 카노 모델은 각종 소비자 조사 방법과 연구를 통해 얻어진 '소비자의 목소리'(Voice of Consumer)를 분석하는 틀로 이용된다. ...


을 참고해 보시기 바란다.

사실 카노 모델은 매우 유명한 모델 중 하나로 구글신에게 물어보시면 매우 많은 정보를 얻을 수 있다.

테스팅의 우선순위를 정하기 위한 리스크 분석 이전에 이러한 모델을 통하여 기능의 우선 순위를 먼저 정한다면 개발 뿐만 아니라 테스팅에 있어서 리소스의 낭비를 줄일 수 있다.

카노 모델에서는 기능을 필수 기능, 선형 기능 그리고 감동을 주는 기능으로 구분한다.

대부분의 경우 이러한 기능 구분을 기획자의 직관이나 어설픈 설문 조사 등으로 대체되는 경우가 많지만 중요한 것은 사용자로부터 직접 이러한 데이터를 받아내야 한다는 것이다.

솔직히 사용자가 만족하는 제품의 개발은 돈이 많이 들어간다..

필수 기능은 말 그래도 필수 적으로 필요한 기능들이다. 선형 기능은 다다익선인 기능들을 말한다. 즉 품질이 나아질 수록 고객 만족도도 증가하는 기능들이다. 감동을 주는 기능들은 있어도 그만 없어도 그만이라고 할 수 있다. 하지만 있다면 고객으로부터 돈을 더 받아 낼 수 있는 기능들이다. 감동을 주는 기능들은 고객이 직접 확인 하기 전까지는 그런 기능들이 자신에게 필요한지 확신을 하지 못하기 때문에 미지의 수요라고도 한다.

예를 들면, 최근 스마트폰이 각광을 받으면서 뜨거운 감자로 올라온 것이 일반 기능폰에 와이파이가 있는가? 없는가? 이다.

지금으로서는 와이파이는 감동을 주는 기능이다. 와이파이가 있다면 일부 얼리어답터나 누군가는 감동을 받고 손전화를 질러버릴 것이다. 하지만 얼마 지나지 않아 시장이 변한다면 와이파이는 선형 기능을 될 것이다. 와이파이가 있는 모델은 시장에서 더 많은 점유율을 차지할 것이다. 그렇게 시간이 지나고 나면 언젠가는 와이파이는 필수 기능이 될 것이고 와이파이가 없는 손전화는 도태될 것이다.

그럼 이러한 기능들을 사용자로부터 어떻게 얻어낼 수 있을까?

카노는 두가지 질문을 통해 결정하는 방법을 제안하였다.

첫번째 질문은 해당 기능이 존재하여 기분이 어떻겠는가? 이고 두번째 질문은 없다면 어떤 기분이겠는가?를 묻는 것이다.

그리고 각각의 질문에 1부터 5까지 점수를 매기도록 한다.

1점은 만족한다
2점은 그럴거라고 예상했다.
3점은 잘 모르겠다.
4점은 그렇더라도 쓸 수는 있다.
5점은 그렇게 되면 불만이다

라는 식으로 정의를 내린다.

이렇게 되면 사용자가 내릴 수 있는 답변의 수는 25가지가 된다.

그렇다면 각각의 답변에 따라 기능을 결정할 수 있는 표를 생각해 보자.

   없다면    
   만족예상
중립
감내
불만족
 존재한다면 만족
 재검토
감동감동감동
선형
  예상 역기능무관심무관심
무관심
필수
  중립 역기능무관심무관심무관심필수
  감내 역기능무관심무관심
무관심
필수
  불만족 역기능역기능
역기능
역기능
재검토

예를 들어 당신이 지금 일종의 퍼즐 게임을 만든다고 가정해 보자.

만약 난이도에 대한 기능에 대해 카노 모델을 통해 사용자 조사를 위해 설문지를 돌린다면

난이도라고 커다란 질문을 던진다면 사용자로부터 정확한 답변을 얻기 힘들 수 있다.

사용자에게 전달할 질문은 적당한 숫자여야 하지만(너무 많으면 설문 응답이 저조해진다.) 너무 적은 질문은 기능의 단위를 너무 커지게 해서 나중에 분석에 어려움이 있다.

난이도를 상, 중, 하로 구분해서 질문을 만들어 보자.

컴퓨터와 낮은 난이도 게임을 할 수 있다면?
컴퓨터와 난은 난이도 게임을 할 수 없다면?

이런 식으로 하나의 기능에 세트로 된 질문지를 작성하면 된다.

위와 같은 질문에 만약 사용자가

낮은 난이도 게임을 할 수 있다는 것에 예상을
낮은 난이도 게임을 할 수 없다는 것에 불만족을 선택한다면

낮은 난이도 게임은 필수 기능이 되는 것이다.

그런데 수많은 사용자(대략 30~40명 정도면 적당하다고 볼 수 있다. 하지만 고객이 누구냐에 따라서 설문 응답자는 적절하게 조절하면 된다. 설문 응답자 수보다 중요한 것은 고객을 누구로 정의하냐는 문제이다.)에게 응답을 받게 되면 같은 기능에 대해 2가지 응답이 나올 수도 있다.

예를 들어 높은 난이도 게임에 대해 무관심과 필수 기능 2가지가 나올 수도 있다. 이런 경우는 어떻게 해석할 수 있을까? 각각의 답변군에 대해 다시 한번 분석해 본다면 사용자 부류에 따라 구분되기도 한다.

즉, 데이터를 수집하는 것보다 해석하는 것에 좀 더 주의를 기울여야 하고 그보다는 사전에 설문에 대하 사용자 부류의 선정에 더 신중해야 한다.

무관심은 말 그대로 사용자가 그다지 관심이 없는 기능들이다. 피쳐 크리프를 통해 추가된 기능들은 대부분 무관심으로 분류되는 경향이 크다.

역기능이나 재검토가 사용자 의견으로 나오는 경우는 드물지만 그런 의견이 나온다면 역기능은 없애버려야 할 기능이고 재검토는 기능에 대해 사용자가 잘못 이해하고 있는 경우가 크기 때문에 기능을 다시 정의 내릴 필요가 있다.

카노 모델은 단순하고 간편하지만 사용자로부터 아주 의미 있는 데이터를 추출해 낼 수 있는 좋은 방법 중 하나이다. 하지만 간편하고 쉽다고 하더라도 사용자에 대한 이해와 정의가 부족하다면 이러한 데이터의 신뢰도는 급격히 떨어지게 된다.

사용자 조사는 사실 어떤 방법을 사용하더라도 신뢰도를 100% 얻는다는 것은 불가능하다. 그렇기 때문에 단 0.001%의 신뢰도라도 향상시킬 수 있도록 끊임없는 노력이 필요하다.

테스터 역시 회사의 직원이 아닌 사용자가 되기 위한 노력을 게을리 하지 말아야 한다. 테스터가 사용자의 눈을 잃어버리는 순간 그 테스터는 더 이상 테스터가 아니다.

우리 나라는 많은 경우 테스터의 기술이나 능력을 중요시 하는 경우가 많다. 그런것도 중요하지만 더 중요한 것은 테스터가 사용자의 입장을 얼마나 잘 대변해 주는가이다.

사용자와 접촉하고 사용자를 이해하고 사용자를 위한 노력을 게을리 하지 않는 테스터가 많아졌으면 하는 바램이다.

댓글

  1. trackback from: 카노 모델과 MMORPG
    카노 모델(Kano Model) 에서는 제품의 특성을 아래와 같이 3 가지로 나눈다.

    당연한 품질요소(Must-Be Quality Element) - 없으면 제품의 가치가 없는 것. 자동차의 핸들, 바퀴

    일차원적 품질요소(One-Dimensional Quality Element) - 충족되면 좋고, 없으면 불만이 생기는 품질 요소. 자동차의 연비, 승차감, 에어백

    매력적 품질요소(Attractive Quality Element) - 없어도...

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

결국 테스팅은 어렵다

 AI 코딩 에이전트와 대형 언어 모델(LLM)이 코드를 순식간에 쏟아내고 테스트 스크립트까지 자동으로 만들어주는 시대가 되면서, 일각에서는 "이제 테스팅도 버튼 하나 누르면 끝나는 쉽고 단순한 일 아닌가?"라는 착각에 빠지곤 합니다. 하지만 품질 전문가 매슈 하이저(Matthew Heusser)가 자신의 블로그 Quality Remarks에 기고한 "Turns Out Testing is Hard" 아티클은, 기술이 아무리 화려하게 발전하더라도 소프트웨어의 '진짜 품질'을 검증하는 일은 여전히 지독하게 어렵고 복잡하다는 현실을 서늘하게 되짚어 줍니다. (출처: Quality Remarks - Turns Out Testing is Hard / Matthew Heusser) https://qualityremarks.com/turns-out-testing-is-hard/ 이 아티클이 말하는 핵심은 간단합니다. 단순한 스크립트 실행이나 표면적인 기능 작동 여부를 확인하는 '체크(Checking)'는 AI나 도구를 통해 얼마든지 자동화하고 속도를 높일 수 있지만, 시스템의 숨겨진 리스크를 탐색하고 비판적으로 질문을 던지는 '진짜 테스팅(Testing)'의 난이도는 오히려 이전보다 더 올라갔다는 점입니다. AI 코딩 에이전트가 단 몇 초 만에 수백 줄의 코드를 생성을 해내면서 당장 눈앞의 기능은 돌아가는 것처럼 보입니다. 하지만 그 이면에서는 오작동이 일어날 수 있는 엣지 케이스, 시스템 간의 미묘한 맥락 단절, 그리고 나중에 거대한 장애로 돌아올 인지부채가 순식간에 쌓여갑니다. 매슈 하이저는 왜 테스팅이 여전히 지독히 어려운 과제로 남아있는지 몇 가지 근본적인 이유를 제시합니다. 첫째, '모호함과의 싸움'입니다. 소프트웨어 요구사항은 언제나 비어있는 행간과 모호함을 품고 있습니다. AI는 주어진 텍스트 그대로 명시적인 조건만 테스트하지만, 실제 인간 테스터는 명시되지 않은 사용...

비츠 스튜디오 버즈 플러스(투명) 사용 후기

제 내자분은 아직도 유선 이어폰을 쓰고 있습니다. 그게 좋다고 하시더라구요. 작년에 혹시나 해서 앤커 사운드코어 라이프Q35를 구매해서 조공해봤지만 결국은 안쓰시더라구요. 그래서 작년 추운 겨울에 제가 귀마게 용으로 잘 사용해왔는데.. 여름이 되니.. 와.. 이건 너무 덥고 무거워서 못쓰겠더라구요. 아이폰도 사고 애플 워치도 샀으니.. 다음은 에어팟인데.... 노이즈 캔슬링이 된다는 에어팟 프로 2는 ... 네... 너무 비싸더라구요... 이건 내자분께 얘기해봐야 결제가 될리가 없어서... 고민하고 있던차에.. 네.. 저는 봐버리고 말았습니다. 비츠 스튜디오 버즈 플러스의 그 영롱한 투명 버전의 자태를... 급 뽐뿌가 왔지만.. 여전히 20만원의 고가더라구요... 초기 출시 시기에 이벤트로 16만원 정도 했던거 같은데.. 그정도 가격이면 선 결제 후 보고 하면 될거 같은데.. 20만원은 너무 너무 비싸서 침만 삼키던 차에.. 당근에 15만원에 올라온 물건을 덥석 물었습니다. 애플 뮤직 6개월 프로모션 코드도 사용하지 않은 따끈따끈한 제품이라서 그냥 질렀습니다. 이상하게 인터넷이 실제 리뷰 게시물을 찾기 힘들어서.. 고민을 잠깐 했지만.. 그 투명하고 영롱한 자태에 그만... 어쨌든 구매하고 한달 정도 사용해본 후기를 간단하게 남겨봅니다. 1. 노이즈 캔슬링은 기대한 것과는 좀 다르고 앤커 사운드코어 라이프Q35 정도 되는 것 같습니다. 노이즈 캔슬링은 활성화하면 이게 소리를 막아준다기보다는 주변의 작은 소음만 제거해준다고 생각하시면 됩니다. 그러니까 옆에서 소근 거리는 소리나 선풍기 바람 소리 같은 작은 소리들이 사라지고 음악 같은 내가 듣고자 하는 소리가 굉장히 뚜렸해지만 지하철 안내 방송 같은 조금 큰 소리는 그냥 들립니다. 그래서 주변음 허용 모드를 켜보면 너무 시끄러워서 안쓰게 되더라구요. 전 에어팟 프로 2를 사용해 본적이 없어서 비교할 수는 없지만.. 아주 못쓸 정도의 성능은 아니라고 생각됩니다. 2. 저는 귓구멍이 너무 작아서 XS...

에이전틱 AI 프로젝트에서 테스터의 5가지 핵심 원칙

AI 코딩 에이전트와 자율형 에이전트가 빠르게 개발 워크플로우에 통합되면서, 단순히 코드를 잘 짜는 것을 넘어 '에이전트와 어떻게 협업하고 통제할 것인가'가 개발자와 아키텍트들의 가장 큰 화두로 떠올랐습니다. 윤석찬 님의 아티클 "AI 에이전트 시대, 개발자는 어떻게 일해야 하는가? – 프론티어 엔지니어링의 10가지 원칙"은 에이전틱 AI 시대에 엔지니어가 마주하는 패러다임 변화와, 실무 현장에서 일하는 방식을 어떻게 재정의해야 하는지 아주 명확한 가이드라인을 제시해 줍니다. (출처: channy.creation.net - 윤석찬 님의 블로그) https://channy.creation.net/blog/1989 비록 대규모 에이전트 오케스트레이션이나 초거대 인프라 시스템을 개인이 직접 구축하고 운용하는 것은 비용적·기술적으로 현실적인 한계가 있습니다. 하지만 개인 프로젝트에서 AI와 바이브 코딩(Vibe Coding)을 활용하며 겪었던 맥락 손실, 환각, 통제 불능의 경험들을 떠올려보면, 이 아티클이 제시하는 10가지 프론티어 엔지니어링 원칙은 소규모 개인 개발 환경에서도 대단히 깊은 공감을 불러일으킵니다. 이 글은 단순히 "AI 도구를 잘 쓰자"는 수준에 머무르지 않습니다. AI 에이전트가 생성해내는 불확실성 속에서 인간 엔지니어가 시스템의 맥락을 주도하고, 오작동을 제어하며, 품질의 키(Steering Wheel)를 쥐기 위한 구조적 사고법을 다룹니다. 그렇다면 프론티어 엔지니어링의 원칙을 바탕으로, 시스템의 신뢰성과 안전성을 검증해야 하는 테스터는 과연 어떤 실무 원칙을 세워나갈 수 있을까요? 윤석찬 님이 제시한 엔지니어링 원칙을 테스팅 관점으로 재해석해 보면, 다음과 같은 5가지 원칙으로 정리할 수 있을 것 같습니다. 1. 결정론적 검증에서 '경계선 및 허용 오차(Boundary)' 테스팅으로 전환하라 에이전트 기반 시스템은 같은 입력을 주어도 매번 다른 추론 경로를 거치는 확률적(Stoc...