사용자 만족을 위한 자동차 제어 소프트웨어 요구사항 개발 - Kano 모델 활용

반응형

1. 자동차 제어 소프트웨어, 무엇이 사용자를 만족시키는가?

요즘 자동차를 떠올리면 단순히 이동수단이라는 말로는 설명이 부족합니다. 스마트폰처럼 똑똑해진 네비게이션, 운전자 없이 스스로 멈추고 가는 크루즈 기능, 부드럽게 연결되는 전기 모터의 가속감까지. 이 모든 것 뒤에는 복잡하고 정교한 자동차 제어 소프트웨어가 숨어 있습니다.

 

그렇다면, 이렇게 복잡한 소프트웨어가 사용자에게 ‘좋다’, ‘편하다’는 느낌을 주는 건 어떤 순간일까요? 기본 기능이 잘 작동하는 것만으로는 충분하지 않습니다. 우리가 “이 차 괜찮네!“라고 느끼는 건, 기대한 것보다 더 부드럽게 반응하거나, 생각지도 못했던 편리함을 느꼈을 때입니다. 예를 들어, 가속 페달을 밟았을 때 원하는 만큼 자연스럽게 반응하거나, 주차 보조 기능이 매끄럽게 차를 세워줄 때 말이죠. 반대로, 조금이라도 삐걱거리거나, 반응이 느리면 아무리 좋은 스펙을 갖춘 차량이라도 아쉬움을 느끼게 됩니다.

 

결국 핵심은 소프트웨어 품질과 사용자 기대가 어떻게 만나는가에 달려 있습니다.

 

소프트웨어 품질이라고 하면 보통 신뢰성, 반응성, 효율성 같은 딱딱한 용어들이 떠오릅니다. 물론 이런 것들도 중요하죠. 시스템이 고장 나지 않고, 빠르게 반응하고, 에너지를 적게 쓰는 건 기본 중의 기본입니다. 하지만 사용자는 그런 기술적 디테일을 알지 못합니다. 대신, “생각보다 조용하네”, “부드럽게 출발하네”, “스마트 크루즈가 믿음직스럽네” 같은 체감하는 감성적 경험으로 품질을 느낍니다.

 

즉, 개발자나 엔지니어 입장에서 볼 때 소프트웨어 품질은 기술적인 결과물이지만, 사용자 입장에서는 ‘느낌’과 ‘경험’으로 받아들여지는 겁니다. 특히 최근 자동차 시장은 사용자의 기대가 정말 높아졌습니다. “차가 움직이기만 하면 된다” 수준이 아닙니다. “내가 원하는 만큼, 원하는 순간에 정확하게 반응해 줘야 해” 같은, 더 섬세하고 민감한 기대를 가지고 있습니다.

 

이렇게 보면, 소프트웨어 개발에서 중요한 건 단순한 기능 구현이 아닙니다. 당연히 기대하는 기본 요구(Must-Be)를 확실히 충족시키는 것, 그리고 예상치 못했던 매력적인 경험(Attractive Quality)을 어떻게 줄 것인가가 진짜 승부처가 되는 거죠.

 

이 숨겨진 기대와 만족 포인트를 찾고, 체계적으로 다루기 위해 활용할 수 있는 여러 방법 중 하나가 바로 Kano 모델(Kano Model)입니다.

 

2. Kano 모델이란 무엇인가?

우리가 일반적으로 제품을 만들거나 소프트웨어를 개발할 때, “좋은 기능을 많이 넣으면 사용자들이 만족하겠지”라고 생각하기 쉽습니다.
하지만 실제 세상은 그렇게 단순하지 않습니다. 어떤 기능은 분명히 추가했는데도 고객이 별로 감흥을 느끼지 않는 경우가 있고, 어떤 기능은 굉장히 사소해 보였지만, 뜻밖에 큰 반향을 일으키기도 합니다. 때로는 기능이 늘어날수록 만족도가 떨어지는 신기한 현상도 나타납니다.

이런 복잡한 현실을 깔끔하게 설명해주는 게 바로 “Kano 모델(Kano Model)” 이라고 할 수 있습니다.

Kano 모델은 1980년대 초, 일본 도쿄과학대학(東京理科大学)의 노리아키 카노(Noriaki Kano) 교수가 제안한 이론입니다. 카노 교수는 기존 품질 관리 방법론이 고객 만족을 충분히 설명하지 못한다고 보고, 제품/서비스가 고객에게 주는 만족도를 새로운 방식으로 분석하고자 했습니다.

핵심 아이디어는 아주 간단합니다.

“모든 기능이 만족에 똑같이 기여하는 것은 아니다.”

 

그리고 고객 만족은 단순히 “기능이 있느냐 없느냐”만으로 설명할 수 없고, 어떤 기능이 어떤 방식으로 제공되느냐에 따라 만족의 형태도 완전히 달라진다는 점을 강조했습니다.

Kano 모델은 제품이나 소프트웨어의 기능을 고객 만족(Customer Satisfaction)이라는 축과 기능 충족(Functionality Fulfillment)이라는 축으로 구분합니다.

• 가로축(X축): 기능이 얼마나 잘 제공되고 있는가 (충족 수준)
• 세로축(Y축): 고객이 느끼는 만족도 (만족 ⇆ 불만족)

Kano Diagram

또한 위 그림에서 보는바와 같이 이 두 가지 축을 기준으로, 다양한 기능이나 특성을 5가지 유형으로 나눌 수 있습니다:

 

2-1. Must-Be (필수 품질, 기본 기대를 충족하는가) : 이 유형은 절대 놓치거나 빠뜨리면 안됩니다.

이건 "당연히 있어야 하는" 기본 중의 기본입니다. 즉, 필수 품질은 잘 지켜져도 사용자 입장에서는 특별히 만족을 느끼진 않지만, 충족하지 못한다면 사용자 불만이 폭발합니다. 

 

2-2. One-Dimensional (성능 품질, 성과에 따라 만족이 비례하는가) : 이 유형은 끊임없이 최적화 해야 합니다.

이건 충족 정도에 따라 만족도가 비례해서 올라가는 품질입니다. 잘하면 잘할수록 좋고, 못하면 못할수록 안 좋은 것이지요. 예를 들면, 연비가 좋아질 수록 사용자는 만족도가 올라가며, 차량 응답 속도가 빨라질 수록 더 좋아하는 것이지요. 결국 이 품질은 "더 좋은 성능 = 더 높은 만족"이라는 관계를 가집니다. 그래서 개발할 때 성능 최적화의 목표가 뚜렷해 집니다.

 

2-3. Attractive (매력 품질, 예상 밖의 감동을 주는가) : 이 유형은 놀라움(감동)을 주기 위해 끊임없이 발굴하고 설계해야 합니다.

매력 품질은 Kano 모델을 사용함에 있어 아주 중요한 포인트라 할 수 있습니다. 사용자는 요구하지 않았지만, 제공되면 감동하는 요소들입니다. 예를 들어 터치 한번으로 차량 공조 시스템을 자동으로 최적화 하는 기능이나 차량 시동 시, 좌석 포지션이 자동으로 조절되는 맞춤 기능 등이 있습니다. 

자동차 제어 소프트웨어에서 이런 Attractive 품질을 잘 심으면, "와, 이 차 진짜 디테일하다" 라는 평가를 받을 수 있을것 입니다. 이때 흥미로운 점은 이런 매력 품질은 있으면 감동 포인트가 될 수 있지만, 없다고 해서 고객이 불만을 표시하지는 않는다는 것입니다. 하지만 있으면 감동과 함께 강한 충성심을 기대할 수 있게 된다는 점에서 아주 중요한 포인트라 할 수 있습니다.

 

2-4. Indifferent (무관심 품질, 있어도 별반 영향을 주지 않는가) : 이 유형은 쓸데없는 개발 리소스를 낭비하지 않게 조심해야 합니다.

이건 있어도, 없어도 사용자 입장에서 별로 관심 없는 것입니다. 예를 들어 소프트웨어 아키텍처가 최신 아키텍처인지 아닌지, 어떤 회적화 알고리즘을 사용했던지 등 이것은 사용자에게는 전혀 중요한 이슈가 아닙니다. 결국, 개발 리소스를 무관심 품질에 너무 많이 쓰는 건 효율적이지 않습니다.

자동차 제어 소프트웨어를 개발할 때도 이런 항목들은 꼭 필요한 기술적 요구는 충족하되, 사용자 기대를 넘어서는 과도한 투자는 피하는게 좋습니다. 

 

2-5. Reverse (역효과 품질, 오히려 있으면 불만족을 유발하는가) : 이 유형은 반드시 제거되어야 합니다.

마지막으로 이건 조금 위험한 영역입니다. 있으면 오히려 싫어하는 기능입니다. 즉, 사용자는 "차라리 없는게 낫다"고 느끼는 품질 속성입니다. 가령 자동차 제어에서 운전자 개입을 지나치게 제한하거나, 너무 과한 안전 경고로 스트레스를 주는 경우가 Reverse 품질로 전락할 수 있습니다. 이런 기능은 잘못 설계하면, 오히려 고객 불만을 초래하니 아주 신중하게 다루어야 할 것입니다.

 

3. 요구사항 개발을 위한 Kano 모델 활용

3-1. 신규 기능을 도출하기 위한 방법으로의 Kano 모델 활용

자동차 제어 소프트웨어를 설계할 때, 기존에 없던 신규 기능을 기획하거나 차량 차별화를 위해 “새로운 사용자 경험”을 만들어야 할 때가 많습니다. 이때 Kano 모델은, 숨겨진 기대(Attractive 품질)를 발굴해 고객에게 깜짝 놀랄 경험을 주는 기능을 도출하는 데 큰 도움이 됩니다. 또한 이는 기존 스펙을 개선하는데 그치지 않고, 완전히 새로운 고객 가치를 창출할 수 있는 방법입니다.

 

그럼 이 숨겨진 기대를 발굴하는 것은 어떻게 할 수 있을까요?

절차	내용
1단계: 사용자 기대 리스트업	사용자 입장에서 원하는 것, 기대하는 것, 불편해하는 것을 최대한 많이 수집합니다(기대 리스트 작성). 또한 단순히 “필요한 기능”이 아니라 숨은 기대, 무의식적 욕구까지 찾아내는 것이 목표입니다.
2단계: Kano 분류	수집한 사용자 기대 리스트를 Kano 모델의 다섯 가지 품질 유형(Must-Be, One-Dimensional, Attractive, Indifferent, Reverse) 중 어디에 해당하는지 분류합니다.
3단계: Attractive 품질 집중 발굴	사용자에게 감동을 줄 수 있는 숨은 기대(Attractive Quality)를 선별하고, 신규 기능 아이디어로 발전시킵니다.
4단계: 기능 구체화	발굴된 신규 아이디어를 실제 설계 가능한 수준으로 구체화하여, 요구사항 문서에 반영합니다. 예를 들어 “부드러운 출발”이라는 기대를 "초기 토크를 일정 곡선에 따라 부드럽게 제어하는 알고리즘” 같은 형태로 기술 요구사항화합니다.

■ 1단계: 사용자 기대 리스트업 예시

• 직접 인터뷰: 실제 사용자나 타깃 고객 그룹을 대상으로 심층 인터뷰를 진행합니다. 단순한 Yes/No 질문이 아니라, “어떤 상황에서 불편했나요?” 같은 오픈형 질문을 사용합니다.
• 사용자 행동 관찰: 테스트 드라이브, 시뮬레이터 체험 등에서 고객의 행동을 관찰해 “말로 표현하지 않은” 니즈를 찾아냅니다.
• VOC(Voice of Customer) 데이터 분석: 기존 제품 관련 불만, 개선 요청, 포럼, 리뷰 글 등을 분석합니다.
• 시장/경쟁 제품 분석: 타사의 신기능이나 반응이 좋은 기능을 벤치마킹하여 고객 기대의 방향성을 추정합니다.

■ 2단계: Kano 분류 예시

• 쌍방향 질문 방식(Paired Questions)을 이용하여 분류기준(Must-Be/One-Dimensional/Attractive/Indifferent/Reverse)을 이용하여 판단합니다:
  • “이 기능이 있으면 어떻게 느끼십니까?”
  • “이 기능이 없으면 어떻게 느끼십니까?”
• 또는 전문가 그룹(개발자, 기획자, UX 디자이너)이 논의하여 직관적으로 초기 분류를 수행할 수도 있습니다.

■ 3단계: Attractive 품질 집중 발굴 예시

• Attractive 품질 리스트업: 2단계에서 Attractive로 분류된 기대사항만 따로 정리합니다.
• 기술 검토 및 아이디어 확장:
  • 현재 기술로 실현 가능한가?
  • 조금 더 개선하면 새로운 부가가치를 만들 수 있는가?
• 사용자 시나리오 구상: 해당 기능이 제공될 때 사용자 경험(UX)이 어떻게 달라질지 구체적으로 상상해봅니다.

■ 4단계: 기능 구체화 예시

• 기능 요약 정의: 기능 이름, 간단한 설명 작성
• 시나리오 명세: 사용자가 언제, 어떻게 이 기능을 경험하는지를 서술합니다.
• 기능 요구사항(FRS) 작성:
  • 입력(Trigger)
  • 처리(Process)
  • 출력(Output)
  • 예외처리(Abnormal case)
• 비기능 요구사항(NFR) 추가: 반응속도, 안정성, 사용성 등에 대한 조건도 함께 정의합니다.
• 우선순위 설정: 신규 기능의 시장 경쟁력, 기술 난이도, 개발 비용 등을 종합적으로 고려하여 우선순위를 부여합니다.

---

3-2. 기존 요구사항을 개선하기 위한 방법으로의 Kano 모델 활용

이미 존재하는 기능이라도 시간이 지나면서 사용자 기대 수준은 변합니다. 이때 Kano 모델을 활용하면, 현재 기능이 여전히 Must-Be인지, One-Dimensional 성능이 충분한지, 혹은 Attractive 요소가 필요한지를 재평가할 수 있습니다.

절차	내용
1단계: 기존 기능 리스트업	현재 제품(또는 소프트웨어)이 충족하고 있는 기능 요구사항과 비기능 요구사항을 모두 정리합니다. 어떤 기능들이 지금 제공되고 있는지, 어떤 품질 특성을 보장하고 있는지를 명확히 파악하는 것이 목표입니다.
2단계: 사용자 피드백 수집	기존 기능에 대한 사용자의 실제 인식을 확인합니다. 어떤 기능이 고객 기대를 충족시키고 있고, 어떤 기능이 만족을 주지 못하거나, 새로운 기대 수준에 미치지 못하고 있는지 파악합니다.
3단계: Kano 재분류	기존 기능을 현재 고객 인식 기준으로 Kano 품질 유형(Must-Be, One-Dimensional, Attractive, Indifferent, Reverse)으로 다시 분류합니다. 과거 Must-Be였던 기능이 Indifferent로 바뀌었거나, 과거 Attractive였던 기능이 One-Dimensional로 바뀌었을 수 있음을 포착합니다.
4단계: 개선 방향 도출	Must-Be 품질이라면 결함 없이 확실하게 구현되어야 하고, One-Dimensional 품질이라면 성능(반응속도, 정확도 등)을 높여야 하며, Attractive 품질로 확장할 수 있다면 작은 추가 기능을 기획합니다.

 

■ 1단계: 기존 기능 리스트업 예시

• 요구사항 명세서(Requirement Specification)를 재검토하여 기능 목록을 정리합니다.
• 테스트 케이스를 분석하여 현재 검증되고 있는 기능 목록을 보완합니다.
• 기능별 고객 VOC(Voice of Customer) 데이터를 함께 수집해 관련 문제점이나 개선점을 파악합니다.

■ 2단계: 사용자 피드백 수집 예시

• 고객 만족도 조사(Questionnaire): 기능별 만족도와 중요도를 동시에 조사합니다.
• 운전자 인터뷰 및 사용성 평가: 실제 차량 운전자, 테스트 드라이버 대상으로 기능별 사용 경험을 인터뷰합니다.
• 시장 조사/경쟁 분석: 경쟁 차량의 유사 기능과 고객 반응을 분석합니다.

■ 3단계: Kano 재분류 예시

• Kano 질문지를 기반으로 기능별 사용자 반응을 분석합니다.
  • “이 기능이 있으면 어떤가요?”
  • “이 기능이 없으면 어떤가요?”
  • 이때 단순히 기능 자체가 존재하는지 여부가 아니라, 기능의 품질 수준이 기대를 충족하는지가 중요합니다.
• 또는 내부 전문가 그룹이 사용성 피드백을 기반으로 판단할 수 있습니다.

■ 4단계: 개선 방향 도출 예시

 

• Must-Be 기능: 기본 기능이지만 고객 불만이 발생하고 있다면 신뢰성, 반응성 강화 필요 (예: 브레이크 보조 제어의 지연 개선)
• One-Dimensional 기능: 성능을 계속 향상시켜야 함 (속도, 정확도, 에너지 효율 등) (예: 고속 주행 시 차선 유지 성능 강화)
• Attractive 기능: 기존 매력 요소를 유지하거나, 새로운 요소를 추가하여 차별화 지속 (예: 주차 보조 기능에 “자동 주차 공간 선택” 기능 추가)
• Indifferent 기능: 개발 리소스를 줄이거나, 기능 삭제를 고려
• Reverse 기능: 오히려 불편을 주는 기능은 제거하거나 수정

---

3-3. 리버스 엔지니어링을 통한 기존 기능의 요구사항화 방법으로의 Kano 모델 활용

때로는 기존 시스템이나 경쟁사 제품을 벤치마킹(Reverse Engineering)하여 명시되지 않았던 기능 요구사항을 새로 정의해야 할 때가 있습니다. 이때 Kano 모델은, 단순히 “카피(copy)“가 아니라, 어떤 요소를 명확한 요구사항으로 만들고, 어떤 요소는 과감히 버릴지를 판단하는 기준이 됩니다.

절차	내용
1단계: 기능 분석	분석 대상 시스템의 기능과 특성을 세부적으로 기록합니다. 즉, 어떤 시스템(또는 제품)을 분석할 것인지, 그리고 어떤 기능들을 리버스 엔지니어링할 것인지를 명확히 설정합니다.
2단계: 사용 경험 시뮬레이션	대상 기능이 실제로 어떤 동작을 수행하고, 사용자에게 어떤 경험을 주는지를 체계적으로 분석합니다.
3단계: Kano 품질 유형 매칭	분석된 기능을 Must-Be, One-Dimensional, Attractive, Indifferent, Reverse로 분류하여 어떤 기능을 요구사항화할지, 어떤 부분을 차별화할지 전략을 세웁니다.
4단계: 요구사항 문서화	리버스 엔지니어링으로 얻은 기능들을 실제 설계/개발에 활용할 수 있도록 구체적 요구사항(FRS, Functional Requirement Specification)으로 정리합니다.

 

■ 1단계: 기능 분석 예시

• 분석 대상 차량 모델 또는 시스템 명확화: 예: 경쟁사의 최신 SUV 모델의 차선 유지 보조(LKA) 시스템
• 주요 기능 범위 설정: 주요 기능, 부가 기능, 경계 조건(Boundary Conditions)을 구분합니다.
• 관찰 또는 문서 분석: 실제 제품 운전, 사용자 매뉴얼, 기술 문서, 특허/논문 등 참고

■ 2단계: 사용 경험 시뮬레이션 예시

• 기능 동작 플로우 기록: 상태(State)와 트랜지션(Transition)을 기록합니다. (예: LKA 활성화 → 차선 이탈 감지 → 조향 보정 → 운전자 경고)
• 입력/출력 파악: 입력: 센서, 운전자 조작 / 출력: 경고음, 디스플레이, 차량 제어 동작
• 사용자 경험(UX) 관찰: 기능이 활성화/비활성화되는 시점 / 운전자가 느끼는 자연스러움, 개입 정도, 불편함

■ 3단계: Kano 품질 유형 매칭 예시

• Kano 질문법 간접 적용:
  • “이 기능이 있으면 사용자가 어떤 반응을 보일까?”
  • “이 기능이 없으면 사용자 불만이 생길까?”
• 기능별로 대략적인 Kano 유형을 추정합니다.

■ 4단계: 요구사항 문서화 예시

 

• Must-Be, One-Dimensional 기능: 명확하고 구체적인 요구사항으로 문서화합니다.
• Attractive 기능: 선택적 강화 항목으로 기획하여, 추가 개발 시 고려합니다.
• Indifferent/Reverse 기능: 기본 요구사항에서 제외하거나, 불필요한 기능은 명시적으로 배제합니다.

---

3-4. 서로 다른 제어기간 협조제어를 협의하는 방법으로의 Kano 모델 활용

자동차 제어 소프트웨어는 보통 여러 ECU(제어기)가 협력해서 작동합니다. 예를 들면, 엔진 제어기(ECU), 변속기 제어기(TCU), 차체 제어기(VCU) 등이 하나의 운전 동작을 위해 협조해야 하죠. 이때 서로 다른 제어기관(Subsystem) 간 협의가 필요한데, 각 제어기관이 기대하는 협조 레벨이 다를 수 있습니다.

 

여기에서도 Kano 모델을 활용하면 협조 제어에 필요한 요구사항의 우선순위를 명확히 정할 수 있습니다.

절차	내용
1단계: 각 제어기의 협조 요구사항 수집	각 제어기관이 시스템 협조를 위해 필요로 하는 구체적인 기대사항과 요구사항을 수집합니다. 협조를 위한 필수 신호, 기능적 동작, 품질 기대를 명확히 합니다.
2단계: 협조 요구사항 기능 단위 정리	수집한 협조 요구사항을 기능(Function) 단위로 명확히 정리하고, 상호작용(Interaction) 흐름을 구조화합니다.
3단계: 협조 요구사항 Kano 품질 유형 분류	각 협조 동작/기능을 Kano 품질 유형으로 분류하여, 개발 및 협의 시 우선순위를 전략적으로 정할 수 있게 합니다.
4단계: 협의 우선순위 및 협력 전략 수립	Kano 분류에 따라 협조 요구사항의 우선순위를 설정하고, 제어기관 간 협의와 구현 전략을 효율적으로 계획합니다.
5단계: 최종 요구사항 문서화 및 합의	협의된 협조 요구사항을 정식 문서화하여 개발팀, 검증팀, 품질팀 모두 일관된 이해를 갖도록 합니다.

 

■ 1단계: 각 제어기의 협조 요구사항 수집

• 각 제어기관 담당자 인터뷰: 기능 요구사항, 데이터 송수신 요구, 반응 시간 목표, 제어 책임 범위 등을 파악합니다.
• 기존 인터페이스 문서 분석: 신호 정의서(Signal Specification), 통신 프로토콜 사양서 참고.
• 협조 요구 시나리오 수집: 정상 동작 뿐만 아니라, 고장모드(Fail-safe) 상황에 대한 협조 요구도 함께 수집합니다.

■ 2단계: 협조 요구사항 기능 단위 정리

• 기능 흐름 정리 (Input → Process → Output): 협조 제어가 이루어지는 과정별로 입력, 처리, 출력 흐름을 명확히 구분합니다.
• 인터페이스 시퀀스 다이어그램 작성: 각 제어기관 간 신호 송수신, 타이밍, 이벤트 트리거 관계를 그림으로 표현합니다.
• 타임라인/상태전이 모델링: 제어 협조가 시간/상태에 따라 어떻게 변화하는지를 시각화합니다.

■ 3단계: 협조 요구사항 Kano 품질 유형 분류

• Kano 질문 적용:
  • “이 협조 기능이 없으면 시스템 기본 동작이 어려운가?” → Must-Be
  • “이 협조 기능의 품질 수준에 따라 만족도가 달라지는가?” → One-Dimensional
  • “이 협조 기능이 있으면 놀라운 경험을 줄 수 있는가?” → Attractive

■ 4단계: 협의 우선순위 및 협력 전략 수립

• Must-Be 협조 기능: 제일 먼저 명확한 합의를 이루어야 합니다. 협력계약 수준(SLA)에 명시합니다.
• One-Dimensional 협조 기능: 정량적 성능 목표를 설정하고, 공동 개발 또는 단계적 개선 계획을 수립합니다.
• Attractive 협조 기능: 일정과 리소스를 고려해 선택적으로 구현 여부를 검토합니다. 고급 트림 모델용 기능 등.

■ 5단계: 최종 요구사항 문서화 및 합의

• 협조 제어 기능 요구사항 명세 작성:
  • 기능 정의
  • 입력/출력 신호 정의
  • 정상 및 예외 흐름 시나리오
  • 품질 유형(Kano 분류) 명시
• 합의 문서 작성:
  • 책임 분담표(RASCI Matrix)
  • 통신 장애 대응 방안
  • 요구사항 변경관리 프로세스(Change Management Process) 포함

 

4. Kano 모델 적용 시 주의해야 할 점

4-1. 기술적 제약 조건과의 균형

통상 Attractive 품질 요소(예: 부드러운 자동 주차, 부드러운 변속 보정)를 추가하고 싶어도, 실제로는 제어기의 연산 능력, 통신 대역폭, 하드웨어 스펙, 안전 인증 기준(ISO 26262 등) 등과 같은 기술적 제약 때문에 쉽게 구현할 수 없는 경우가 많습니다.

그런데 무리하게 매력적 기능을 넣으려다 보면 시스템 안정성이나 기본 성능(Must-Be 품질)이 훼손될 수 있습니다. 구현 자체는 가능하더라도 비용과 일정이 폭발적으로 증가할 위험이 있기 때문입니다.

 

그렇다면 어떻게 대응하면 좋을까요? 먼저 Attractive 품질 기능은 반드시 기술적 Feasibility 검토를 거쳐야 합니다. 그리고 기술 리소스 한계 안에서 점진적 적용을 검토합니다 (예: 일부 트림, 일부 주행 상황 제한 적용). 마지막으로 기능안전(Safety)과 충돌하는 경우에는, 매력 품질을 희생하더라도 기본 안전성과 신뢰성을 우선시합니다.

“좋아 보인다고 다 넣지 말고, 현실 가능한 범위 안에서 꿈꿔야 한다.”

 

 

4-2. 필수 품질과 매력 품질 간의 트레이드오프 관리

소프트웨어나 제품 설계에서는 리소스(개발 인력, 시간, 비용)가 항상 한정되어 있습니다. 이럴 때 흔히 겪는 딜레마가 바로 이겁니다:

• 기본 동작(Must-Be)을 더 튼튼히 만들까?
• 아니면 사용자 감동(Attractive)을 노려볼까?

왜 주의해야 하나?

• 필수 품질(Must-Be)이 허술하면, 매력적 기능이 아무리 많아도 고객은 불만족합니다.
• 그러나 필수 품질만 충족하고 Attractive 품질을 소홀히 하면 차별화된 사용자 경험을 만들기 어렵습니다.

어떻게 대응할까?

• Must-Be 품질을 최우선으로 완성합니다. (안정성, 신뢰성 확보)
• 그 다음에, One-Dimensional 품질 성능 개선을 적정 수준까지 진행합니다.
• 최후로, 여력이 된다면 Attractive 품질을 추가합니다.
• 리소스가 부족할 경우, **Attractive 품질은 모듈화(옵션화)**해서 순차 개발하는 전략을 씁니다.

“기본이 무너지면 감동도 없다. 필수 품질을 다진 다음에 매력을 쌓자.”

 

 

4-3. 사용자 기대치 변화에 따른 지속적 요구사항 업데이트 필요성

오늘 Attractive로 분류했던 기능이, 내일은 One-Dimensional, 모레는 Must-Be로 변하는 일이 빈번하게 발생합니다.

→ 시간이 지나면서 “당연히 있어야 할 것(Must-Be)“로 변화)

 

왜 주의해야 하나?

• 시장과 기술은 빠르게 변합니다.
• 경쟁사가 먼저 Attractive 품질을 구현하면, 사용자 기대 수준은 순식간에 올라갑니다.
• Kano 분류를 초기 설정만 믿고 고정해버리면,
• 제품/소프트웨어가 빠르게 시대에 뒤처질 수 있습니다.

어떻게 대응할까?

• 정기적인 사용자 만족도 조사를 시행합니다. (적어도 연 1~2회)
• 기능별 사용자 체감 리서치를 반복 수행해 품질 유형 변화를 추적합니다.
• 신규 트렌드(신기술, 경쟁사 신기능)가 등장할 때마다
• Kano 분류 재검토 워크숍을 진행합니다.
• Agile 개발 방법론을 도입해 요구사항을 지속적으로 진화시킵니다.

“사용자 기대는 살아 움직인다. 정기적으로 체크하고, 요구사항을 유연하게 업데이트해야 한다.”

 

---

마치며...

요구사항을 작성하는 데 있어 고객 만족을 추구하는 것은 단순한 목표가 아니라, 제품과 소프트웨어의 궁극적인 가치 실현을 위한 핵심적인 활동입니다.

그러나 고객 만족을 지향하는 과정에서 우리는 근본적인 질문과 마주하게 됩니다.
“고객을 만족시키기 위해 우리는 무엇을 해야 하는가?”, 그리고
“그 답을 어떻게 찾아낼 수 있을까?”

이 질문에 대해 단 하나의 정답은 없습니다.
상황에 따라, 고객층에 따라, 기술 수준에 따라 달라질 수밖에 없습니다. 그러나 다양한 방법 중 하나로, 고객 기대를 체계적으로 분석하고 분류할 수 있도록 돕는 방법이 바로 Kano 모델입니다.

Kano 모델은 고객의 명시적 요구뿐 아니라, 숨겨진 기대와 예상치 못한 만족 요소까지 포착할 수 있도록 설계된 구조적 접근법입니다.

이를 활용하면 우리는 고객 만족을 막연한 감이 아닌, 구체적인 설계 목표와 요구사항으로 연결지을 수 있습니다. 그리고 이를 통해
“고객 만족을 위해 무엇을 해야 하는지”, “어떤 기능이 고객 경험을 결정짓는지”에 대한 보다 명확한 답을 찾아나갈 수 있을 것이라 믿습니다.