Wicked Problem이란 무엇인가?
Wicked Problem(사악한 문제)은 1973년 도시계획학자 Horst Rittel과 Melvin Webber가 처음 정의한 개념으로, 명확하게 정의하기 어렵고 완벽한 해결책이 존재하지 않는 복잡한 문제를 의미합니다. 이들은 도시 계획의 복잡성을 설명하면서 이 용어를 만들었지만, 오늘날에는 소프트웨어 개발부터 기후 변화까지 다양한 분야에서 활용되고 있습니다.
이러한 문제들이 가진 핵심적인 특징들을 살펴보면, 먼저 문제 자체를 정의하기가 모호하며 문제를 완전히 이해하려면 해결책을 시도해봐야 한다는 순환적 특성이 있습니다. 또한 정답이 하나로 정해져 있지 않고 ‘맞다/틀리다’가 아닌 ‘더 낫다/덜 낫다’로만 평가할 수 있다는 점에서 전통적인 문제 해결 방식과 구별됩니다. 더욱이 해결책을 시도해보기 전까지는 그 효과를 알 수 없으며, 각 시도는 되돌릴 수 없는 결과를 낳기 때문에 실험의 비용이 매우 높습니다.
각 문제가 독특하고 반복 불가능하여 과거의 해결책을 그대로 적용할 수 없다는 점도 중요한 특징입니다. 마지막으로 이해관계자마다 문제를 다르게 인식하고 서로 상충되는 요구사항을 제시한다는 점에서 합의 도출 자체가 하나의 도전이 됩니다.
라이트 형제의 교훈: 빠른 반복의 힘
라이트 형제가 1903년 12월 17일 최초의 동력 비행에 성공한 비결은 경쟁자들보다 훨씬 빠른 반복 주기에 있었습니다. 이들의 성공 스토리는 단순한 행운이나 천재성의 결과가 아니라, 체계적인 실험과 학습의 산물이었습니다. 당시 스미소니언 협회의 막대한 지원을 받던 Samuel Langley는 5만 달러라는, 오늘날 가치로 환산하면 150만 달러가 넘는 거대한 예산으로 ‘Great Aerodrome’을 개발했습니다. 그는 완벽한 이론적 계산과 정밀한 설계를 통해 단번에 성공하려 했지만, 1903년 10월 7일과 12월 8일 두 차례 모두 포토맥 강에 추락하는 실패를 겪었습니다.
반면 라이트 형제는 오하이오주 데이턴에서 운영하던 자전거 가게의 수익으로 충당한 1,000달러 미만의 예산으로 전혀 다른 접근을 택했습니다. 그들은 1900년부터 1902년까지 노스캐롤라이나의 키티호크에서 매년 수개월씩 머물며 1,000회 이상의 글라이더 비행을 수행했고, 직접 제작한 풍동에서 200개 이상의 날개 형태를 체계적으로 테스트했습니다. 각 실험은 작고 빠르게 실패했지만, 매번 중요한 데이터와 통찰을 제공했습니다. 양력과 항력의 관계, 날개의 비틀림 제어, 러더의 역할 등 비행의 핵심 원리들을 하나씩 실증적으로 발견하고 개선해 나갔습니다. 이들의 성공은 비행이라는 거대한 wicked problem을 작은 실험들로 나누어 빠르게 가설을 검증하고 학습한 결과였습니다.
애자일: Wicked Problem 해결의 체계화
애자일 방법론은 이러한 “빠른 반복을 통한 학습”이라는 원칙을 소프트웨어 개발에 체계적으로 적용한 것입니다. 2001년 2월, 유타주 스노버드 스키장에 모인 17명의 소프트웨어 개발자들이 작성한 애자일 선언문은 단순한 방법론의 제안이 아니라 패러다임의 전환을 알리는 신호탄이었습니다. 그들은 수십 년간 소프트웨어 산업을 지배했던 폭포수 모델의 근본적 한계를 지적하며 각자 시도해왔던 새로운 접근법들을 확신하게 되었고 이러한 공식적인 선언을 통해 그 필요성을 역설했습니다.
폭포수 모델은 건축이나 제조업에서 차용한 방법론으로, 요구사항 분석에서 시작해 설계, 구현, 테스트, 유지보수로 이어지는 순차적 단계를 따릅니다. 이러한 접근법은 요구사항이 명확하고 변경이 적은 상황, 예를 들어 교량 건설이나 대형 건물의 설계처럼 물리적 법칙과 규정이 명확한 영역에서는 여전히 효과적입니다. 그러나 대부분의 소프트웨어 개발은 근본적으로 다른 특성을 가지고 있습니다.
첫째, 사용자조차 자신이 진정 원하는 것이 무엇인지 실제 제품을 사용해보기 전까지는 명확히 알지 못합니다. 둘째, 기술 환경이 프로젝트 진행 중에도 급격히 변화하여 초기 설계가 쓸모 없어지는 경우가 빈번합니다. 셋째, 비즈니스 요구사항이 시장 상황과 경쟁 환경에 따라 지속적으로 진화합니다. 이런 특성들 때문에 소프트웨어 개발 자체가 전형적인 wicked problem의 성격을 띠게 되는 것입니다.
스타트업과 애자일의 만남
실리콘밸리의 성공한 스타트업들이 애자일을 적극 도입한 이유는 명확합니다. 그들이 해결하려는 문제 자체가 전형적인 wicked problem이었기 때문입니다. 이들은 기존 시장에 존재하지 않던 새로운 가치를 창출하려 했고, 그 과정에서 끊임없는 실험과 학습이 필요했습니다.
Spotify는 2006년 스웨덴의 작은 스타트업으로 시작했을 때, 음악 스트리밍이라는 개념 자체가 생소한 시대였습니다. 당시 대부분의 사람들은 여전히 CD를 구매하거나 불법 다운로드를 통해 음악을 소비하고 있었습니다. Spotify의 초기 버전은 단순한 음악 재생 기능만을 제공했지만, 사용자들의 행동 패턴을 면밀히 관찰하고 분석하면서 플레이리스트의 중요성을 발견했습니다. 이후 머신러닝 알고리즘을 활용한 Discover Weekly 같은 개인화 추천 서비스를 개발했고, 이는 음악 소비 방식을 근본적으로 변화시켰습니다. 각 기능은 수천 명의 사용자를 대상으로 한 A/B 테스트를 통해 검증되었고, 데이터가 긍정적인 결과를 보여주는 기능만이 전체 사용자에게 배포되었습니다.
Netflix의 변신은 더욱 극적입니다. 1997년 DVD 우편 대여 서비스로 시작한 이 회사는 블록버스터와 같은 거대 경쟁자들과 맞서야 했습니다. 하지만 지속적인 실험과 피벗을 통해 2007년에는 스트리밍 서비스를 도입했고, 2013년 House of Cards를 시작으로 오리지널 콘텐츠 제작에 진출했습니다. 각 전환점마다 작은 실험으로 시작했다는 점이 중요합니다. 스트리밍 서비스는 처음에 기존 DVD 대여 고객들에게 무료 부가 서비스로 제공되었고, 사용자들의 반응을 보며 점진적으로 확대되었습니다.
자동차 산업에서 애자일이 주목받는 이유
자동차 산업은 100년 이상 하드웨어 중심의 개발 방식을 고수해왔습니다. 전통적인 V-사이클 모델은 시스템 요구사항 정의부터 시작해 컴포넌트 설계, 구현, 통합 테스트를 거쳐 최종 검증에 이르는 체계적이고 순차적인 프로세스였습니다. 이러한 접근법은 엔진 설계나 섀시 개발처럼 물리 법칙에 기반한 명확한 사양이 존재하고, 변경 비용이 막대한 영역에서는 여전히 유효하며 필수적입니다.
그러나 SDV(Software-Defined Vehicle) 시대가 도래하면서 자동차 산업의 근본적인 패러다임이 변화하고 있습니다. 테슬라가 2012년 Model S를 출시하며 OTA(Over-The-Air) 업데이트를 도입한 것은 단순한 기능 추가가 아니라 자동차의 정의 자체를 바꾸는 혁명적인 변화였습니다. 차량이 판매된 후에도 지속적으로 기능을 추가하고 개선할 수 있다는 것은, 자동차를 고정된 하드웨어 제품에서 진화하는 소프트웨어 플랫폼으로 재정의한 것입니다.
새로운 유형의 문제들이 등장하고 있습니다:
E2E(End-to-End) 자율주행은 자동차 산업이 직면한 가장 복잡한 wicked problem입니다. “완전 자율주행이 어떤 모습이어야 하는가?”라는 질문에는 명확한 답이 없습니다. 각 나라마다 교통 문화가 다르고, 도로 인프라의 수준이 천차만별이며, 날씨와 지형 조건도 극도로 다양합니다. Waymo는 구글의 자율주행 프로젝트로 2009년부터 개발을 시작했지만, 15년이 지난 지금도 여전히 피닉스, 샌프란시스코 등 제한된 지역에서만 상용 서비스를 제공하고 있습니다. 이들은 수백만 마일의 실제 도로 주행과 수십억 마일의 시뮬레이션을 통해 지속적으로 시스템을 개선하고 있습니다.
인포테인먼트 서비스는 스마트폰 생태계에 익숙한 현대 소비자들의 높아진 기대치를 충족시켜야 하는 과제를 안고 있습니다. Mercedes-Benz의 MBUX나 BMW의 iDrive 같은 시스템들은 이제 단순한 내비게이션과 오디오 재생을 넘어, AI 음성 비서, 증강현실 내비게이션, 개인화된 추천 서비스 등을 제공합니다. 이러한 기능들은 정기적인 소프트웨어 업데이트를 통해 지속적으로 개선되고 있으며, 사용자들의 피드백과 사용 패턴 데이터를 기반으로 진화하고 있습니다.
커넥티드 서비스는 차량을 독립된 제품이 아닌 거대한 모빌리티 생태계의 일부로 만들고 있습니다. 실시간 교통 정보, 주차장 예약, 전기차 충전소 안내, 차량 공유 서비스 등은 모두 외부 시스템과의 지속적인 연결과 데이터 교환을 필요로 합니다. 이러한 서비스들의 요구사항은 시장 상황, 규제 변화, 새로운 파트너십 등에 따라 수시로 변경되며, 유연한 대응이 필수적입니다.
애자일이 효과적인 조건
자동차 산업에서 애자일이 성공적으로 작동하기 위해서는 특정한 조건들이 충족되어야 합니다. 이는 단순히 방법론을 도입하는 것을 넘어, 조직 구조와 문화, 기술 아키텍처까지 포함하는 전방위적인 변화를 필요로 합니다.
1. 팀 단위 의사결정 권한
Wicked problem을 해결하기 위해서는 빠른 피드백 루프가 필수적이며, 이는 팀이 기술적 결정을 자율적으로 내릴 수 있을 때만 가능합니다. 전통적인 자동차 회사의 위계적 의사결정 구조에서는 작은 변경사항도 여러 단계의 승인을 거쳐야 하며, 이는 애자일의 핵심인 빠른 반복과 학습을 불가능하게 만듭니다. 성공적인 애자일 팀들은 제품 책임자(Product Owner 혹은 Product Manager)에게 충분한 권한을 부여하고, 팀 내에서 기술적 결정을 내릴 수 있는 자율성을 보장받습니다.
2. 소프트웨어 중심 문제
ADAS(Advanced Driver Assistance Systems) 기능들처럼 하드웨어 변경 없이 소프트웨어 알고리즘만으로 구현 가능한 영역에서 애자일의 효과가 극대화됩니다. 차선 유지 보조, 적응형 크루즈 컨트롤, 자동 긴급 제동 등의 기능들은 기존의 카메라, 레이더, 라이다 센서들과 전자 제어 장치들을 활용하여, 소프트웨어 업데이트만으로 지속적인 개선이 가능합니다. 반면 배터리 관리 시스템이나 전력 변환 장치처럼 하드웨어의 물리적 특성과 밀접하게 연관된 영역에서는 애자일 적용이 제한적일 수밖에 없습니다.
3. 모듈화된 아키텍처
AUTOSAR Adaptive Platform과 같은 서비스 지향 아키텍처(SOA)는 각 기능을 독립적인 서비스로 구현할 수 있게 하며, 이는 애자일 개발에 필수적인 유연성을 제공합니다. 각 서비스는 명확하게 정의된 인터페이스를 통해 통신하며, 다른 서비스의 내부 구현에 영향을 받지 않습니다. 이러한 아키텍처는 여러 팀이 동시에 독립적으로 작업할 수 있게 하며, 각 팀은 자신의 속도로 개발과 배포를 진행할 수 있습니다.
Volkswagen CARIAD의 구조조정이 시사하는 점
폭스바겐 그룹의 소프트웨어 자회사 CARIAD는 2020년 야심차게 출범했지만, 얼마 지나 지 않아서 대규모 구조조정을 단행해야 했습니다. ID.3와 ID.4의 소프트웨어 문제로 차량 출시가 수개월씩 지연되었고, 초기 구매자들은 불완전한 소프트웨어로 인한 다양한 문제들을 경험해야 했습니다. 이러한 문제들은 단순한 버그가 아니라, 레거시 하드웨어 플랫폼 위에 현대적인 소프트웨어 아키텍처를 억지로 올리려 한 구조적 문제에서 비롯되었습니다.
CARIAD의 실패에서 얻을 수 있는 중요한 교훈은, 소프트웨어 중심 접근법이 기존의 하드웨어 중심 사고방식과 충돌할 때 발생하는 문제들입니다. 각 브랜드(아우디, 포르쉐, 폭스바겐 등)가 독자적인 요구사항을 제시하면서 공통 플랫폼 개발이 극도로 복잡해졌고, 이는 개발 지연과 비용 증가로 이어졌습니다.
레가시와의 조율 전략
이러한 실패 사례들로부터 배울 수 있는 것은, OEM들이 애자일 도입 시 레가시 시스템과의 조율을 얼마나 신중하게 고려해야 하는지입니다. 성공적인 전환을 위해서는 다음과 같은 전략적 접근이 필요합니다:
1. 점진적 분리 전략
마틴 파울러가 제안한 Strangler Fig Pattern은 레거시 시스템을 한 번에 교체하는 대신, 새로운 기능을 점진적으로 추가하면서 기존 시스템을 서서히 대체하는 방식입니다. 이는 마치 무화과나무가 숙주 나무를 감싸며 자라다가 결국 대체하는 것과 유사합니다. 이 접근법은 리스크를 최소화하면서도 지속적인 개선을 가능하게 합니다.
2. API 기반 경계 설정
레거시와 애자일 영역 간에 명확한 API 경계를 설정하는 것이 중요합니다. 잘 정의된 인터페이스는 두 영역이 독립적으로 진화할 수 있게 하며, 한쪽의 변경이 다른 쪽에 미치는 영향을 최소화합니다. 이는 마치 두 개의 다른 언어를 사용하는 팀이 통역사를 통해 소통하는 것과 같습니다.
3. 이중 속도 IT
가트너가 제안한 Bimodal IT 개념은 안정성이 중요한 영역(Mode 1)과 혁신이 중요한 영역(Mode 2)을 분리하여 운영하는 것입니다. 안전 관련 시스템은 전통적인 방식으로 개발하되, 인포테인먼트나 커넥티드 서비스는 애자일로 개발하는 식입니다. 이는 마라톤 선수와 단거리 선수가 각자의 방식으로 훈련하는 것과 유사합니다.
4. 레거시 리팩토링 투자
애자일 전환과 병행하여 레거시 시스템을 체계적으로 리팩토링하는 장기적 투자가 필요합니다. 이는 오래된 건물을 리모델링하는 것처럼, 구조를 유지하면서도 현대적인 요구사항을 충족시키도록 개선하는 과정입니다.
ASPICE®와의 조화: Agile SPICE®
많은 자동차 업계 관계자들이 우려하는 핵심 질문은 “애자일을 도입하면 ASPICE® 심사를 받을 수 없는 것 아닌가?”입니다. ASPICE®(Automotive SPICE®)는 자동차 산업의 소프트웨어 개발 프로세스 표준으로 확고히 자리 잡았으며, 특히 안전이 중요한 시스템에서는 ASPICE® Level 2 이상의 성숙도가 필수적으로 요구됩니다. 표면적으로 보면, 상세한 문서화와 순차적 프로세스를 강조하는 ASPICE®와 가벼운 문서화와 반복적 개발을 추구하는 애자일은 양립할 수 없어 보입니다.
그러나 intacs(International Assessor Certification Scheme)가 개발한 Agile SPICE® 프레임워크는 이 두 접근법이 충분히 조화를 이룰 수 있음을 구체적으로 보여줍니다. 이 프레임워크의 핵심은 애자일의 실천법들을 ASPICE®의 요구사항과 체계적으로 매핑하여, 두 방법론의 장점을 모두 취할 수 있도록 하는 것입니다.
프로세스 호환성의 구체적 실현
Agile SPICE®는 전통적인 ASPICE® 프로세스들과 일대일로 대응되는 애자일 프로세스들을 정의합니다. 예를 들어, AGL.1(Agile Work Management)은 MAN.3(Project Management)과 대응되는데, 이는 단순한 이름 바꾸기가 아니라 애자일의 철학을 유지하면서 프로젝트 관리의 본질적 목적을 달성하는 방법을 제시합니다. 전통적인 간트 차트와 상세한 프로젝트 계획서 대신, 제품 백로그와 스프린트 계획, 번다운 차트가 계획과 추적의 역할을 수행합니다.
마찬가지로 AGL.2(Partner Collaboration Management)는 ACQ.4(Supplier Monitoring)와 연결되어, 공급업체와의 협력을 애자일 방식으로 관리하는 방법을 제시합니다. 정기적인 스프린트 리뷰와 데모를 통해 공급업체와의 소통을 강화하고, 문제를 조기에 발견하여 해결할 수 있습니다.
품질 보증 메커니즘의 재해석
애자일의 반복적 접근법이 오히려 품질을 향상시킬 수 있다는 점이 Agile SPICE®의 중요한 통찰입니다. Definition of Done(DoD)과 Definition of Ready(DoR)는 전통적인 품질 게이트의 역할을 더욱 효과적으로 수행합니다. 각 스프린트마다 동작하는 소프트웨어를 제공한다는 원칙은, 문제를 조기에 발견하고 수정할 수 있게 합니다.
스프린트 리뷰와 회고(Retrospective)는 지속적인 프로세스 개선의 메커니즘을 제공합니다. 이는 ASPICE®가 요구하는 프로세스 개선 활동을 더욱 빈번하고 실질적으로 만듭니다. 페어 프로그래밍과 코드 리뷰는 동료 검토 요구사항을 자연스럽게 충족시키며, 자동화된 테스트와 CI/CD 파이프라인은 검증 활동의 객관적 증거를 지속적으로 생성합니다.
결론: 균형과 선택의 지혜
SDV 시대의 자동차 산업은 이제 하드웨어 중심의 예측 가능한 개발에서 소프트웨어 중심의 불확실성 관리로 패러다임이 전환되고 있습니다. 이는 단순한 기술의 변화가 아니라, 사고방식과 조직 문화, 비즈니스 모델까지 포함하는 근본적인 변혁입니다. 테슬라의 성공은 이러한 전환이 단순한 선택이 아닌 생존의 문제임을 명확히 보여주었고, 전통적 OEM들도 이제는 변화의 필요성을 절감하고 있습니다.
애자일은 이러한 전환기에 필수적인 방법론이 되어가고 있지만, 그것이 만병통치약은 아닙니다. 중요한 것은 각 조직과 프로젝트의 특성을 깊이 이해하고, 그에 맞는 현명한 적용 전략을 수립하는 것입니다.
1. 문제의 성격을 정확히 파악하라
해결하려는 문제가 진정한 wicked problem인지, 아니면 명확히 정의 가능한 문제인지를 먼저 구분해야 합니다. 브레이크 시스템의 제동 거리 최적화처럼 물리 법칙에 기반한 명확한 문제는 전통적 방법론이 더 적합할 수 있습니다. 반면 음성 인식 어시스턴트의 사용자 경험 개선처럼 지속적인 학습과 개선이 필요한 영역에서는 애자일이 강력한 도구가 됩니다.
2. 하이브리드 접근을 두려워하지 마라
현실적으로 순수한 애자일이나 순수한 V-사이클 모두 한계가 있습니다. 시스템 레벨에서는 V-사이클의 체계성을 유지하되, 소프트웨어 기능 개발에서는 애자일의 유연성을 활용하는 하이브리드 모델이 많은 경우 최선의 선택입니다. 이는 양자택일의 문제가 아니라, 각 방법론의 Balancing과 장점을 적재적소에 활용하는 지혜의 문제입니다.
3. 조직 문화 변화에 투자하라
기술적 방법론보다 더 중요한 것은 조직 문화의 변화입니다. 빠른 실패와 학습을 장려하는 문화, 팀에 대한 신뢰와 권한 위임, 투명한 커뮤니케이션과 협력의 문화 없이는 어떤 방법론도 성공할 수 없습니다. 이는 하루아침에 이루어지는 것이 아니라, 지속적인 노력과 리더십의 헌신이 필요한 장기적 과제입니다.
4. 규제 준수를 혁신의 기회로 삼아라
자동차 산업의 엄격한 규제 요구사항은 제약이 아니라 품질 향상의 기회가 될 수 있습니다. ISO 26262, ASPICE®, 사이버보안 규정 등을 충족시키는 과정에서 개발 프로세스가 더욱 견고해지고, 제품의 안전성과 신뢰성이 향상됩니다. Agile SPICE®와 같은 프레임워크를 활용하면, 규제 준수와 혁신적 개발을 동시에 달성할 수 있습니다.
5. 레거시 시스템과의 공존을 현명하게 관리하라
전통적 OEM들에게 레거시 시스템은 부담이자 자산입니다. 수십 년간 검증된 안정성은 유지하면서도, 새로운 기술과 방법론을 도입할 수 있는 전략적 접근이 필요합니다. 점진적 마이그레이션, API 기반 분리, 이중 속도 운영 등 다양한 전략을 상황에 맞게 활용해야 합니다.
라이트 형제가 수천 번의 실험을 통해 하늘을 날 수 있는 방법을 발견했듯이, 자동차 산업도 지속적인 실험과 학습을 통해 모빌리티의 미래를 만들어갈 수 있을 것입니다. 중요한 것은 완벽한 계획을 세우는 것이 아니라, 불확실성을 인정하고 빠르게 학습하며 적응하는 능력입니다.
Wicked problem을 해결하는 유일한 방법은 시작하고, 실험하고, 학습하는 것입니다. 애자일은 그 여정을 위한 나침반이 될 수 있으며, 자동차 산업의 미래는 이러한 접근법을 얼마나 현명하게 활용하느냐에 달려 있습니다.
참고문헌
- https://www.stonybrook.edu/commcms/wicked-problem/about/What-is-a-wicked-problem
- https://en.wikipedia.org/wiki/Wright_brothers
- https://agilemanifesto.org/history.html
- https://en.wikipedia.org/wiki/Spotify
- https://en.wikipedia.org/wiki/Netflix
- https://insight.sbdautomotive.com/Automotive_OTA_updates.html
- https://en.wikipedia.org/wiki/Waymo
- https://media.mbusa.com/releases/human-like-conversations-with-your-mercedes-benz-enabled-by-mbux-voice-assistant-and-ai-driven-knowledge-feature
- https://www.motozite.com/blog/digital-titans-clash-mbux-vs-idrive-vs-mmi-crowning-indias-ultimate-luxury-infotainment-system-2025/
- https://germanautopreneur.com/p/cariad-volkswagen-software-failure-lessons
- https://intacs.info/spice-news-reader/assmodel/agile-spice/agile-spice-an-intacs-add-on-for-aspice