SDV 품질과 속도를 잇는 ‘실행가능한 균형’에 대해

 세온이앤에스 정태하 대표            Taeha Chung, CEO of Seon ENS

세온이앤에스는 SDV 전환의 복잡한 퍼즐을 ‘통합·유연·실무’란 원칙으로 풀어내려 한다. 그들은 직접 개발·검증에 참여하며 최신 트렌드를 쫓고, 컨설턴트가 실무 전문가로서 현장에 녹아들어 SDV 시대가 요구하는 실행 중심 파트너가 된다. 전통적인 품질 모델과 DevOps 애자일 개발 방식 사이에서 균형을 찾아내고, 문서 대신 ‘워킹 소프트웨어’로 가치를 증명한다. 기능안전성, A-SPICE, 사이버보안을 하나의 팀으로 묶은 통합 실행으로 중복과 회피를 막는다. 분석적 서구 모델과 맥락형 아시아 사고를 조화시켜 철저한 절차와 현장 적응성을 동시 확보한다. 세온이앤에스의 정태하 대표이사와 이야기를 나눴다. 

글 | 한상민 기자_han@autoelectronics.co.kr







세온이앤에스는 대외적으로 ‘프로세스 컨설팅’ 이미지가 강하지만, 실제론 개발·검증까지 직접 수행하는 조직이죠. 대표님이 말하는 세온이앤에스의 본질적 정체성과 차별점은 무엇인가요? 
정태하         ‘유일’하다고 보긴 어렵고 유사한 곳도 있습니다. 다만 저희의 본질은 ‘기술 컨설팅’이며, 연구개발 현장에서 일하는 분들께 노하우를 전해드려 그분들의 경쟁력을 높이는 것입니다. ‘실무를 알아야 그 기반 위에서 제대로 된 기술 컨설팅을 할 수 있다’고 생각합니다. 
자동차 개발 트렌드의 변화가 워낙 빠르기 때문에 5~6년 전 경험으로는 현재의 개발을 조언할 수 없습니다. 그래서 컨설팅만으로는 한계가 있다고 판단했고 개발과 검증을 직접 병행하고 있습니다. 소프트웨어 인력을 중심으로 실제 개발을 수행하고, 검증을 통해 새로운 기술을 빠르게 익힙니다. 검증은 직접 만들지는 않더라도 기술을 깊게 접할 수 있는 좋은 사다리이자 결국엔 개발로 이어지는 경로이기도 합니다. 현업의 실무자들을 컨설턴트로 키워 그 경험을 바탕으로 컨설팅을 하고, 동시에 개발도 지속해 기술이 낡지 않도록 업데이트하는 것이 바로 세온이앤에스의 정체성이자 차별점입니다.


실제 경험을 강조하셨는데요, 대표님을 포함한 핵심 인력들의 이력과 이런 분들이 함께 모여 일하는 세온이앤에스 조직 문화도 궁금합니다.
정태하        저희팀은 현대기아차그룹의 현대오트론·현대오토에버, 그리고 LG전자, LG이노텍, HL만도, 경신과 같은 티어 1에서 개발을 담당했던 인재들이 주축입니다. “더 깊이 있는 경험을 쌓고 싶다”, “전문성을 키우고 싶다”는 열망이 큰 분들이 합류했죠.
이런 전문가들에게는 지시·보고 중심의 관리 방식이 오히려 발목을 잡을 수 있습니다. 그래서 ‘자율·신뢰·간소화’를 조직 문화의 핵심으로 삼고 있습니다. 예를 들어, 필요한 도구·서비스·출장 여부 등을 구성원이 스스로 판단해 결정합니다. 경비 사용도 먼저 신뢰를 전제로 합니다. 단, 무작정 방임하지 않고 스폿 감사(spot audit)로만 최소한의 점검을 합니다. 또 복잡한 결재·보고 절차를 없애 빠르게 의사결정해 전문가들이 본연의 업무와 역량 개발에 집중하도록 합니다.
물론 인원이 늘면 악용사례가 생길 수도 있는데, 그럴 땐 규정을 늘리기보다는 개인 차원에서 바로잡거나, 필요하다면 각자의 길을 찾는 것이 조직 운영에 더 효율적이라고 생각합니다. 전체 시스템을 복잡하게 만드는 것보다 핵심 가치를 지키면서 문제를 바로잡는 편이 장기적으로 건강하다고 보고 있습니다.

 


문화가 어찌 보면 SDV 전환의 의미와도 맞닿아 있는 듯한데요? 아닌가요? 
SDV 전환과 관련해 여전히 “개념은 알겠는데 현실은 다르다”는 말이 많아요. 대표님은 SDV와 관련해 현장의 실무, 개발과 품질 측면에서 어떤 경험을 하고 있고, 어떤 접근을 해야한다고 생각하시나요?
정태하        소프트웨어 정의 자동차, 즉 SDV(Software-Defined Vehicle)는 사실 용어만 새롭지 그 개념 자체는 십수 년 전부터 예견됐습니다. 제가 2006년 자동차 분야로 왔을 때(항공, 가전 등을 거쳐) “앞으로 자동차는 소프트웨어 비중이 폭발적으로 커진다”는 얘기가 곳곳에 퍼져 있었어요. 그 흐름 속에서 독일 완성차 5사가 손잡고 AUTOSAR나 품질·프로세스 표준인 A-SPICE가 탄생했었죠.
그럼에도 ‘소프트웨어가 개발의 중심’이라는 선언은 실제 현장에 뿌리내리기 쉽지 않았습니다. 완성차와 부품사는 오랜 기간 하드웨어·메커니컬 시스템 중심의 관성과 조직 헤게모니 속에서 움직여 왔어요. “소프트웨어가 중요하다”는 데엔 동의했지만, 기존 프로세스와 문화는 하루아침에 바뀌기가 쉽지 않았죠. 
지금 대기업은 인력 확보·교육·투자 여력이 있어 그 변화 속도에 맞춰 갑니다. 하지만 티어 1, 티어 2는 어렵습니다. 특히 인력난이 심각합니다. 애써 채용해도 경험이 쌓인 인재는 더 좋은 조건을 찾아 떠나버리기 일쑤죠. 결국 소수 인원으로 품질·생산성을 동시에 입증하지 못하면 “소프트웨어 인력은 비용”이라는 인식에서 벗어나기 어렵습니다.
이 지점이 저희 같은 외부 파트너가 기여할 수 있는 부분이라고 봅니다. 말씀드렸듯이 세온이앤에스는 컨설팅만 하는 회사가 아닙니다. 개발·검증까지 함께 수행하면서 같은 10명이 하나가 아닌 두 개 과제를 완수할 수 있도록 역량을 끌어올리는 방법을 직접 보여드립니다. 개발팀이 작은 조직이어도 품질을 담보하며 속도까지 낼 수 있다는 걸 증명하면, SDV 전환은 ‘추상적 구호’가 아니라 즉각적인 비즈니스 가치로 인식됩니다.
많은 기업이 소프트웨어 전담 자회사를 별도로 설립하고 있죠? 기존 하드웨어 급여체계로는 인재를 지키기 어렵고, 동일 조직 내에서 다른 처우를 하면 내부 불균형이 생기죠? 저희는 이런 현실적 고민을 안고 있는 고객에게 “인력·프로세스·문화”를 함께 다듬어 주는 실질적 파트너로 자리매김하려 합니다.
결국 SDV 시대의 핵심은 기술 자체뿐만 아니라 “소프트웨어 조직을 어떻게 만들고, 어떻게 일하게 하느냐”입니다. 하드웨어의 ‘관성’과 소프트웨어의 ‘속도’를 조화시키는 것이 저희가 현장에서 매일 맞닥뜨리는 과제이자 세온이앤에스가 존재하는 이유입니다.


기업이 SDV 전환을 위해 아키텍처를 새롭게 하고 조직도 바꾸지만, 프로세스와 개발 방식은 과거 그대로인 경우도 많아요.
그래서 이 부분을 그들 스스로 지적하고 있기도 하고요. 세온이앤에스는 이런 과도기에 놓인 기업에 대해 어떤 실행 중심의 전략 개입을 제안하십니까?
정태하        SDV를 하기 위해서는 소프트웨어 중심으로 하는 제품, 즉 E/E 아키텍처 같은 부분을 잘 갖추고자 하는데, 문제는 기능들이 점점 더 복잡해지고 다양해지면서 과거의 전통적인 개발 방식이 한계에 부딪힌다는 겁니다. 이미 인터넷이나 컨슈머, 밀리터리, 의료처럼 소프트웨어가 중심적인 도메인들의 사례를 봐도, 전통적인 개발 방식으로는 설명되지 않는 부분들이 많아요. 예를 들어, PDCA(Plan-Do-Check-Act) 같은 프로세스 모델은 사실상 상당히 예측가능하고 결정적인 상황일 때만 효과적인 방법입니다. 그런데 우리가 다루는 시스템이 점점 복잡해지고, 또 정해진 시간 안에 새로운 것을 만들고 통합해서 서비스를 제공해야 하는 환경에서는 이런 예측가능한 프로세스를 적용하기 굉장히 어렵습니다. 이런 문제를 해결하기 위해 기존 소프트웨어 업계가 도입한 게 결국은 애자일(Agile) 방식이잖아요? 빨리 피드백을 받아서 그때그때 어댑티브하게 접근하자는 겁니다. 
하지만 현실은 바뀌지 않았습니다. 여전히 기능 중심 조직이 대부분이다 보니, 크로스 펑셔널 팀이나 멀티디스플린 팀 같은 이름으로 기존의 사일로를 깨고 협업하려는 노력은 하지만 그 문화적 한계 때문에 잘 안되는 거죠. 그러다 보니 예를 들어, 팀 내부의 당사자들끼리 빠르게 결정하고 해결할 수 있도록 몇 개 레벨로 권한을 정리해 즉각적인 의사결정을 내려야 하는 사항들이 모두 팀장이나 실장 레벨까지 올라가버리는 겁니다. 늦어질 수밖에 없죠. 그래서 프로세스나 개발 조직의 일하는 방식을 근본적으로 바꾸지 않으면 안된다는 이야기가 나오는 겁니다. 아마 스스로들 이 문제를 잘 알고 계실 거예요.






구체적으로, SDV 환경에서는 A-SPICE 같은 전통 품질 기준과 DevOps 기반 민첩 개발이 동시에 요구되쟎아요?
이 둘이 충돌할 때, 세온이앤에스는 실제 고객 현장에서 어떤 방식으로 균형을 설계하십니까?
태하        전통적인 개발 프로세스 모델, 예를 들어 A-SPICE나 그 이전의 CMMI 같은 모델을 떠올리면, ‘애자일’과 충돌하지 않을까 걱정할 수 있습니다. 하지만 사실 애자일 방법론은 1990년대 초반 PDCA 기반 프로세스에 대한 반작용으로 등장한 것이지만, 당시 CMM, CMMI를 운용하던 전문가 스스로도 ‘애자일’이 CMMI나 SPICE와 대립하는 개념이 아니라고 인식하며 발전시켜 왔습니다. CMMI나 SPICE 위에 애자일 사고방식을 얹으면 일하는 방식(How)을 더 유연하고 주도적으로 바꿀 수 있다면서 많은 보고서와 백서들을 발표했죠. A-SPICE도 마찬가지로 ‘애자일 SPICE(Agile SPICE)’란 파생 모델을 만들어 배포했고, 소프트웨어 중심 기업 현장에서는 오래전부터 자연스럽게 애자일·DevOps 관행을 SPICE 프로세스와 결합해 활용해 왔습니다. 이렇게 두 가지를 잘 융합하면, “회사의 품질 수준을 어떻게 결정하느냐”라는 의사결정 체계를 유지하는 동시에 개발팀은 DevOps와 애자일로 얻는 속도와 유연성을 놓치지 않는 ‘윈윈’ 구조가 만들어집니다.
과거 현업에 있을 때엔 저도 그랬고 현대오토에버에서 개발 실장을 지냈던 신승환 상무(옆에 배석한)도 프로세스 팀이 “이것부터 지켜라”라고 빡빡하게 간섭하면, “제때 원하는 품질을 맞추기 힘들다”고 불평했었죠. 그런데 꼭 필요한 부분만 최소화해 보완하면 효율적으로 SPICE 평가도 통과하는 동시에 실제 개발 속도와 품질이란 두 마리 토끼를 다 잡을 수 있습니다.
세온이앤에스는 바로 이런 통합 모델을 기반으로 고객사가 SPICE 요구사항을 충족하는 동시에 DevOps의 민첩함을 온전히 누릴 수 있도록 컨설팅과 교육, 실무 가이드를 제공합니다. 이렇게 하면 전통 프로세스에 대한 반감 없이, 개발팀 스스로 더 개방적이고 주도적인 태도로 프로젝트를 이끌어갈 수 있어 궁극적으로는 품질 평가와 비즈니스 성과 모두에서 만족스러운 결과를 얻을 수 있습니다.


‘필요한 만큼만 적용하라’는 말씀인데, 이게 단순 생략이 아니라 무엇을 남기고 무엇을 제거할지 판단하는 실질적인 기준이 중요할텐데요. 그 기준은 실제 프로젝트에서 어떻게 작동합니까? 
정태하        ‘어떤 요소를 유지하고, 어떤 요소를 미뤄둘지’에 대한 명확한 판단 기준이 있어야 한다는 것이 핵심입니다.
A-SPICE 같은 모델은 기본적으로 ‘지속적인 개선’을 강조합니다. 완전히 프로세스를 뒤집는 ‘혁신’은 어렵고 리스크가 크고 조직 문화에도 부담이 큽니다. 그래서 OEM 관점에서도 서플라이어에게 기대하는 것은 레벨 4, 5 수준의 대규모 혁신이 아니라, 레벨 3 정도의 꾸준한 개선 노력입니다. 레벨 2, 3에는 이런 지속적 개선에 대한 요구가 다 들어있고, OEM도 레벨 3만 충족해도 충분히 신뢰를 주고 고도화 단계는 차후로 미룹니다.
기업은 어떻게 하면 될까요? 가령 A-SPICE 요구 프랙티스 100개 항목에서 저희 고객이 이미 70개 항목을 만족하고 있고 30개 항목의 보강이 필요하다면, ‘지금 당장 가장 큰 효과를 낼 수 있는 다섯 가지’를 식별해 우선 실행합니다. 소규모 개선을 빠르게 달성해 조직 성과를 체감하고, 추가 과제에 대한 동기와 리소스를 확보하는게 우선입니다. 
사실 SPICE는 레빌 2 달성 시 X개, 레벨 3 달성 시 X+Y개 등 해당 프랙티스가  한꺼번에 충족돼야 다음 단계로 넘어갈 수 있게 설계돼 있습니다. 하지만 한 번에 모든 프랙티스를  처리하려 하면, 오히려 리소스 과부하로 전체 일정이 지연되고, 세부 항목 하나하나의 품질도 떨어질 위험이 큽니다. 따라서 레벨 2 달성이라는 중장기 목표를 수립했다면 그것은 그대로 두되, 지금 당장 조직에 필요하고 실행할 수 있는 소수의 프랙티스부터 우선 보완하도록 단계적 스코프를 설정합니다. 세온이앤에스는 실무를 알고 있기 때문에 고객과 함께 이를 진단, 식별하고 실행할 수 있습니다. 


고객의 역량, 조직 구조, 프로젝트 성격이 제각각이쟎아요. 세온이앤에스는 교과서적인 기준이 아니라 실제에 따른 커스터마이징을 구현하는거죠? 또, 이런 통합 대응 서비스를 하려면 많은 엔지니어가 투입돼야 할 것 같기도 한데, 실제 그렇지는 않죠? 
정태하        말씀드린 것처럼, 티어 2나 티어 3 서플라이어로 갈수록 인력이 부족합니다. SDV 환경에서는 소프트웨어 중심의 시스템 공학 업무를 모두 수행해야 OEM이 요구하는 개발 프로세스 역량을 충족하면서 딜리버리를 할 수 있는데, 현장에서는 그게 쉽지 않죠. 그래서 저희는 ‘이렇게 하시면 됩니다’라고 말로만 설명하는 것이 아니라, 실제로 직접 일을 해 드립니다. 일감은 많은데 사람이 부족한 고객사의 일부 과제를 저희가 직접 수행해 딜리버리를 제공하고, 검증 인력과 검증 도구를 활용해 테스트·인증까지 완료해 드리면 고객사는 자연스럽게 SDV에 필요한 소프트웨어 중심의 시스템 개발 역량을 갖추게 됩니다. 
대기업도 소량 다품종 개발을 하는 곳은 여전히 인력이 부족하고, 자체 플랫폼을 구축해 개발 생산성을 극대화할 방안이 마련돼 있지 않은 경우도 많습니다. 이런 상황에서 저희가 부족한 부분을 일부 직접 수행합니다. 그러면 저희 컨설턴트도 실무를 지속하면서 현장 감각과 기술 트렌드를 유지할 수 있고, 이를 통해 고객사는 부족한 부분을 외부에서 필요한 만큼 아웃소싱하고 내부 인력은 핵심 역량에 집중해 조직 역량을 강화할 수 있습니다. 그래서 저희는 항상 실무 개발과 검증까지 함께 수행하는 것을 목표로 하고 있습니다.
서비스에 많은 엔지니어 투입이 필요해 보일 수 있지만, 실제로는 그렇지 않습니다. 저희는 50여명 규모의 조직이지만, 내부 전문가들과 자체 개발 프로세스를 바탕으로 고객 요구사항에 맞춰 턴키 형태 또는 모듈 단위로 유연하게 개발 및 검증을 수행하고 있습니다.


    기능안전성도 여전히 하드웨어 기반 논리에 치우쳐 있다는 평가가 있어요. 세온이앤에스는 이를 어떻게 소프트웨어 중심으로 해석하고 전략에 반영하고자 하나요?
정태하        굉장히 좋은 질문인데요, 사실 기능안전성이 하드웨어에 치우쳐 있다는 평가는 꼭 그렇지는 않습니다. 시스템은 하드웨어도 있고 소프트웨어도 있고 지원 요소도 함께 얽혀 있는 덩어리입니다. 다만 그간 하드웨어·메커니컬 파트가 관성처럼 우세하다 보니 소프트웨어 영역이 상대적으로 가려져 왔고, 그래서 ‘SDV’란 용어가 등장했고 소프트웨어 주도적 역할이 필요해진 것이라고 생각합니다.
하지만 시스템을 제대로 개발하려면 소프트웨어만 중심으로 보는 데엔 한계가 있습니다. 소프트웨어만 강조하면 기존 하드웨어·메커니컬 부문에서 반감과 저항이 일어나기도 하고, 기능안전성은 본질적으로는 ‘시스템 중심’ 개념입니다. SDV가 드러냈던 것은 소프트웨어가 가려졌던 그 부분을 다시 전면에 가져오자는 의도입니다.
저희는 기능안전성을 ‘하드웨어 Vs. 소프트웨어’ 구도로 나누지 않고, ‘Vehicle Service를 위한 시스템 엔지니어링’ 혹은 ‘소프트웨어 인텐시브 시스템(Software-Intensive System)’ 관점에서 접근하고자 합니다. 소프트웨어는 중심에 있어야 하지만, 기존 하드웨어·메커니컬 파트를 독립적으로도 살펴 가며 시스템 엔지니어링을 철저히 해야 비로소 완전한 시스템이 나올 수 있다고 봅니다. 여전히 자동차는 기계 장치 위에 소프트웨어를 얹은 종합 장치입니다. SDV만으로 치우치지 않고 하드웨어·메커니컬 부문까지 골고루 엔지니어링하는 것이 미래이며, ‘소프트웨어만으로 다 되겠느냐’란 반작용에도 준비해야 한다고 생각합니다.


유럽에서도 이런 자성이 많은데, 기능안전성뿐 아니라 A-SPICE도 그렇고 Document oriented Over-engineering으로 너무 많은 시간이 지체되는 문제가 심각하다고 합니다. 세온이앤에스는 이를 어떻게 바라보고 있나요?
정태하        이미 답이 나와 있어요. 문서 자체에 목숨 걸기보다는 ‘워킹 소프트웨어’가 더 높은 가치를 지닌다는 것이 애자일의 핵심입니다. 애자일은 명세서나 설계서 같은 문서를 없애자는 게 아니라, 고객이 직접 보고 써보며 피드백할 수 있는 정보 전달 방식에 집중합니다. 예를 들어 화이트보드에 아키텍처 대안을 그려가며 회의하고, 번다운 차트에 할 일을 적어가며 과업을 관리하는 식이죠. WBS(Work Breakdown Structure) 같은 거대 문서 대신 ‘지금 필요한 정보’를 즉각 생성·공유해, 문서가 가지는 부작용을 최소화해 왔습니다.
그런데 지금 자동차 현장에선 A-SPICE나 기능안전성 심사원이 ‘소프트웨어 아키텍처 명세서’ 같은 산출물이 꼭 있어야 한다고 요구하면서 개발 과정에서 이미 자연스럽게 작성된 아키텍처 논의·결정 사항을 다시 문서로 옮기도록 강제합니다. 애초에 명세서나 설계서는 ‘고객 요구를 실제 설계로 옮기기 위한 중간 정보’인데, 그 이름만 따와서 ‘이름이 붙은 문서’를 만들어야 한다고 하는 겁니다. 그러니 엔지니어들은 파워포인트·워드에 담긴 기존 정보를 모조리 뒤져 다시 문서를 쓰고 바쁜 사람들까지 포멀 리뷰에 동원합니다. 그런 결과는 주로 오타, 파일명 오류 같은 형식적 지적이고 기술적 문제는 이미 개발·납품 과정에서 해결돼 사실상 아무 의미가 없습니다. 
평가자가 도메인 맥락을 이해하지 못하면 이런 과도한 상황이 발생합니다. 예를 들어, 바디제어기 전문가가 인포테인먼트 시스템을 함수 단위로 쪼개지 않았다고 지적할 수 있습니다. 인포테인먼트는 컴포넌트 크기와 안전 중요도에 따라 기준이 달라야 합니다. ‘갭 분석’도 마찬가지로, 이를 요청해 놓고 일주일 스폿 진단만 합니다. 진정한 갭 분석은 장기간 현장 관찰과 함께 논의해야 의미가 있어 충분한 커뮤니케이션과 분석 기간 확보가 필수적입니다.


UNECE R155, ISO/SAE 21434 등 사이버보안 규정 대응에서도 이런 형식적인 측면이 나타나나요?
정태하        사이버보안도 기능안전성과 같은 상황입니다. 프로세스와 실제 개발을 연결할 실행 전략이 부재합니다. 그래서 저희는 A-SPICE, 기능안전성, 그리고 사이버보안을 하나로 묶어 제공합니다. 
초기 A-SPICE 심사 때를 떠올려보면, 심사하던 항목이 기능안전성 아이템이어 “어디에 기능안전성에 대한 언급이 있나요”라고 담당자에게 물으면, 답은 늘 “다른 팀에서 처리 중입니다”라고 했습니다. 시스템 명세서나 설계서는 보여주는데, 안전 목표(Safety Goal)나 안전 메커니즘, 검증 계획·교육 등 기능안전성 핵심 내용은 없었죠. 지금도 “나는 SPICE만”, “나는 보안만, “나는 기능안전성만” 담당한다는 식입니다. 결국 같은 정보를 두세 번 확인해야하고, 부서 간 갈등이 생기고, 결국 엉뚱한 사고로 이어집니다. 
세온이앤에스는 이런 문제를 방지하기 위해, 고객사 제품 개발팀 내부에 안전관리자와 사이버보안 담당자, SPICE 컨설턴트와 설계·개발·검증 전 과정을 통합 수행합니다. 물론 기업의 조직 구조상 여전히 칸막이가 남아 있어 쉽지는 않지만, 이런 통합된 실행 전략을 전파하고 현장에서 직접 보여주려 노력합니다. 중복과 회피를 막아야 진짜 안전하고 보안이 확보된 제품이 나올 수 있습니다.






 


비슷한 질문인데요, SDV 시대에 세온이앤에스가 유지하고 있는 핵심 운영 원칙은 무엇입니까?
정태하        SDV 시대에 세온이앤에스가 가장 중요하게 여기는 운영 원칙은 ‘실제 현장에서 작동하는 균형 잡힌 프로세스의 구현’입니다. 아무리 훌륭한 매뉴얼이나 표준이라도 현장에서 실행되지 않으면 소용이 없고, 지나치게 엄격한 포멀리티는 오히려 경쟁력을 갉아먹습니다. 
최근 한 심사 프로젝트에서 ‘변경 요청이 한 건도 없었다’는 답을 들은 적 있습니다. 그럴 수가 없기 때문에 ‘실제 변경 요청 프로세스가 어떻게 이행됐는지 보여 달라’고 요청하니, 고객사는 CAN 시그널 명칭을 바꾼 사례를 내놨는데, 이 명칭 하나 바꾸는 데 결함 보고서를 작성하고 변경 요청을 하고 그 영향 분석을 하고, 그걸 또 형상 검토를 했던 겁니다. 그렇게 할 일이었을까요? 이렇게 되면 개발자들은 CAN 시그널 하나를 수정할 때마다 ‘프로세스를 지켜야 한다’는 압박에 시달리게 되고 프로젝트 일정과 품질은 도저히 유지할 수 없습니다.
A-SPICE나 CMMI 같은 프로세스 모델은 유럽·북미에서 관찰된 ‘프랙티스 집합’을 추상화해 레벨로 정리한 것입니다. 하지만, 이 추상화된 모델을 현장에 적용하는 방법은 정해져 있지 않습니다. 서양의 분석적 사고방식은 ‘사과 하나, 사과 두 개’처럼 명확한 정의를 선호하지만, 동아시아 문화권에서는 전체 맥락을 파악해 자유롭게 판단하는 ‘눈치’가 강점입니다. SDV처럼 복잡하고 빠르게 변화하는 시장에서는, 모든 업무를 작은 단위로 쪼개고 순서대로 처리하는 것은 비효율입니다. 예측가능하고 결정된 절차는 철저히 지키되, 그 외 영역은 조직 문화와 현장 여건에 맞춰 ‘유연·민첩’하게 대응해야 경쟁력을 유지할 수 있습니다.


통합, 유연, 실무! 오늘 인터뷰하는 동안 늘 함께하는 키워드인 것 같습니다. 마지막으로 AEM 독자들에게 한 말씀 부탁드립니다. 
정태하        실무를 아는 전문가가 현장 상황을 충분히 파악한 뒤, 꼭 필요한 만큼만 프로세스를 적용해 최적의 방안을 함께 찾습니다. 이 균형 감각을 유지하려면 컨설턴트와 엔지니어가 SDV 개발·검증의 최신 트렌드를 끊임없이 학습하고 고객 조직에 직접 투입돼 실제로 함께 일하며 개선 포인트를 실시간 반영해야 합니다. ‘실행가능한 균형’이 중요합니다.
실질적인 컨설팅이 끝나면, 그 결과물을 실제 조직에 적용해 발전시켜 나가는 것은 전적으로 고객사 몫입니다. 저희는 필요한 ‘가려운 곳’을 정확히 긁어드릴 뿐이고, 그 경험을 바탕으로 고객사 스스로 프로세스를 성숙시키고 업계의 좋은 관행을 만들어갈 책임이 있습니다. 다행히도, 이런 경험을 쌓은 분들이 저희에게 합류했다가 다시 업계로 돌아가고, 또 다른 회사에서 같은 순환을 이뤄주고 있습니다. 그리고 기업에서도 앞으로 저희와 함께 할 분들이 대기 중이기도 합니다. 이런 순환 구조가 강화될수록 우리 업계 전체의 역량도 함께 성장할 것이라고 기대합니다.

---