ASPICE는 정말 쓸모없을까?

 

자동차 산업의 트랜드가 SDV (Software Defined Vehicle)로 변화하고, 수많은 차량 제어가 소프트웨어에 의해 이뤄짐에 따라 소프트웨어의 중요성이 높아지고 있다는 점은 더이상 새로운 사실이 아닙니다. 즉, 이제 자동차는 기계적 장치라기보다는 일종의 "움직이는 컴퓨터"에 가까워지고 있죠. 이러한 변화의 중심에서 두 개의 상반된 시선을 마주하게 됩니다.

 

하나는 “속도”를 외치는 개발자들의 시선이고, 또 하나는 “품질”을 지키려는 품질 담당자들의 시선입니다.

 

그리고 그 사이에는 종종 ASPICE라는 이름의 갈등의 축이 놓여 있습니다.

 

그런 와중에 다음과 같은 글을 보며 생각을 정리해 보고자 합니다. (다음 링크는 원문입니다.)

 

The Secret to China and Tesla Speed? - ASPICE. (It’s their gold standard)… | Lukas Timm | 댓글 45

---

한 시니어 개발자의 말: “ASPICE는 쓸데없는 공수 낭비다”

어느 날 한 시니어 개발자와의 대화에서 그는 이렇게 말했습니다.

 

“솔직히 말해서, ASPICE 준수하는 건 너무 비효율적입니다. 가뜩이나 시간도 없는데 언제 문서화하고, 사람이 부족해서 개발하기도 바쁜데, 언제 리뷰하고, 계획서 쓰고, 추적하고… 이 모든 게 개발의 발목을 잡아요.”

 

그렇죠... 개발 현장의 생생한 목소리입니다. 적어도 제가 속한 조직에서 실제 대화의 흐름입니다. 빠르게 움직이고 싶고, 기능을 만들어내고 싶고, 코드에 집중하고 싶은데, ASPICE가 그 속도를 늦추는 장애물로 느껴진다는 것이죠.

 

많은 고민을 하게 만든 목소리인데요. 정말 그런건가? 이게 현실인건가? 하는 고민을 하게 만든 그런...

 

하지만 어딘가 마음 한 구석에서 끓어 오르는 갈증이 다 해소되지 못한 답답함이 있는건 왜 그럴까요?

정말 장애물, 그 이상도 그 이하도 아닌걸까요?

과연 ASPICE는 개발의 발목을 잡는 그런 과거의 유물에 불과할까요?

아니면 우리가 놓치고 있는 본질적인 가치가 있는 걸까요?

 

개발자는 ASPICE를 싫어하지 않는다. ‘느리고 복잡한 ASPICE’를 싫어할 뿐이다

위 원문을 보면, 다음과 같은 내용이 있습니다. 

“China Speed”와 “Tesla Speed”의 비결로서 ASPICE를 꼽았지만, 동시에 이렇게도 말하죠.
“ASPICE isn’t fundamentally wrong—it’s just stuck in the past.”
“Software engineers don’t hate ASPICE. They hate the way it’s implemented.”

 

사실 이 말은 본질을 정확히 꿰뚫고 있다고 보여집니다.

개발자는 품질을 싫어하지 않습니다. 품질을 위한 비효율을 싫어할 뿐입니다.

 

오늘날의 개발자는 DevOps, CI/CD, TDD, BDD, 마이크로서비스, 자동화된 테스트를 통해 더 빠르고, 더 자주, 더 안전하게 소프트웨어를 배포할 수 있는 시대를 살아가고 있습니다. 그런데 ASPICE는 여전히 “리뷰 기록”, “변경 이력”, “구성 항목” 같은 개념을 중심으로 문서 기반의 평가를 요구합니다. 이는 마치 클라우드 시대에 플로피 디스크를 요구하는 격이죠.

 

하지만… 느림이 항상 나쁜 것일까요?

소프트웨어 개발은 본질적으로 사람이 하는 일입니다. 사람은 실수할 수 있고, 기억하지 못할 수 있고, 조직은 이직과 교체의 과정을 겪습니다. 즉, 개발은 지금 잘 돌아가는 것만으로는 부족합니다. “개발 이후에도 잘 돌아갈 수 있는 준비”가 되어 있어야 할 뿐만 아니라, 지금의 개발자가 아니라 미래의 개발자들에 의해서도 "지속적인 유지보수가 이루어질 수 있는 준비"가 필요합니다. 

• 어떤 개발자가 퇴사하더라도 시스템이 유지보수 가능한가?
• 새로운 팀원이 와도 요구사항과 설계 의도를 이해할 수 있는가?
• 리스크가 발생했을 때 원인을 추적하고 재현할 수 있는가?

이러한 질문에 답할 수 있는 구조를 만드는 것, 바로 그것이 ASPICE가 추구하는 “일관된 품질 체계”라고 생각합니다.

 

소프트웨어의 진짜 ‘좋음’이란 무엇인가?

기능이 잘 돌아간다. 속도가 빠르다. 버그가 없다.

이것만으로 과연 좋은 소프트웨어일까요?

 

단기적인 관점에서는 그럴 수 있습니다. 그러나 시간이 지나고, 조직이 바뀌고, 요구사항이 변경되고, 고객 불만이 접수되고, 소송의 리스크가 발생하는 순간, “속도”보다 중요한 것은 “추적 가능성”과 “책임 구조”가 됩니다.

 

이는 특히 자동차 소프트웨어에서 더욱 중요합니다. 단순한 앱 개발과는 달리, 자동차 소프트웨어는 사람의 생명과 직결됩니다. 불완전한 소프트웨어 하나로 사고가 발생하면, 그에 대한 법적, 사회적, 기업적 책임은 엄청나게 큽니다.

 

ASPICE는 통제의 도구가 아니라, 생존의 도구다

ASPICE는 사실 OEM의 프로젝트 통제 수단에서 출발했습니다. 위험을 줄이고, 변경을 관리하고, 책임을 명확히 하기 위한 도구였죠.

 

하지만 지금은 바뀌어야 합니다.

과거의 ‘상명하달식 관리’가 아니라, 현대적인 소프트웨어 엔지니어링에 녹아든 ASPICE로 진화해야 합니다.

• CI/CD 파이프라인과 연동된 자동화된 ASPICE 활동의 근거
• GenAI 기반의 품질 가이드 도우미
• “개발자 친화적인” 품질 툴과 UX

이러한 방식으로 ASPICE가 개발자의 흐름을 끊지 않으면서도 품질을 담보하는 체계로 작동해야 한다는 점은 100% 동의할 수 있습니다. 

 

바쁘고, 인력이 부족하다는 핑계는 대지 말자

대부분의 개발자들은 품질은 종종 “귀찮은 것”으로 여깁니다. 말로는 품질이 중요하다고 말하지만, 정작 프로젝트에서는 시간과 인력이 부족해서 효율적으로 일하는것이 중요하다고 합니다. 하지만 효율이란 베일을 이용하여 품질의 본질을 부족한 일정과 인력 탓으로 돌리려 합니다. 그래서 저는 그것을 "귀찮은 것"으로 여긴다고 생각합니다.

 

하지만 진짜 잘 만든 소프트웨어는 기능 구현 이상의 것을 생각해야 합니다. 

• 유지보수성
• 이식성
• 변경 용이성
• 안전성
• 책임 명확성

이 모든 속성은 좋은 품질 체계 없이는 불가능합니다.

 

느림이 아니라 안정화의 속도로 받아들이자

빠르고 효율적인 개발, 빠르고 효율적인 시험…

이 모두는 중요합니다.

 

하지만 자동차 소프트웨어처럼 생명과 직결된 시스템에서는 소프트웨어 개발 자체가 안정화되는 속도가 진짜 속도라고 생각합니다. 따라서 ASPICE는 소프트웨어 개발 속도를 느리게 만드는 게 아니라, 소프트웨어 개발을 지속가능하게 하며 안정화 시키는 안전장치일 수 있다고 봅니다. 물론, 그 방식은 이제 달라져야 합니다. 과거에 사로잡혀 문서 기반의 심사가 아닌, 새로운 소프트웨어 개발 트랜드에 맞게 변화된 품질 체계로서 말이죠.

 

이를 통해 개발자도, 품질 관리자도, 더 나은 소프트웨어를 위해 같은 방향을 바라볼 수 있어야 합니다.

 

ASPICE, 이제는 개발을 늦추는 것이 아니라 미래를 준비하는 속도다.