따라하기 쉽지 않았던 Automotive SPICE


DO-178C를 좀 보다가 과거에 아쉬웠던 부분이 생각나서 좀 적고자 한다. HCA 프로젝트를 할 때의 이야기를 좀 하자면, 그 당시 Base practice를 어떻게 구현할지에 대해서 고민이 많았는데, 특히 Software를 Architecture를 설계하고 Unit design을 설계하고 그들간의 추적을 하라는 부분이었다.

솔직한 고백을 하자면,Requirement로부터 Architecture를 추적한다는 것이 일반적인 방법론같은 것으로 하는 것은 좀 어려웠다. 나름 customizing에 의해서 고객맞춤형이 되어야 할 필요가 있었다. 종종 단일 사이즈로만 나와서 알아서 입으라는 식으로 판매되는 옷도 있지만,  이건 좀 그렇게 하기 어려웠다.

하지만, 약간의 가정과 전제사항을 기반으로하여 구현하기 위한 방안을 수립했다. 그리고 컨설팅 때 그것을 설명했다.

나의 가정과 전제사항은 당연히 그 회사의 아키텍처와는 맞지 않았고, 자연스럽지는 않았다. 내가 설명한 부분에 대해서 다들 이해하고 있는 것 같은 인상을 나에게 주었지만, 내가 봤을 때 그들이 하는 문서화를 봐서는 이해하고 있다고 생각되지 않았다.

DO-178C의 소프트웨어 개발의 방법론과 ISO26262 혹은 Automotive SPICE의 방법론은 좀 차이가 있다. 같은 듯 보이지만, 디테일 하게 들어가면 상당한 차이가 있다. 그 중 하나가 설계와 구현시 추적관련 실행 및 테스트 케이스에 대한 것이다.

소프트웨어 아키텍처? 중요하긴 하다. 아키텍처를 어떻게 잡느냐에 따라서 소프트웨어의 여러 품질 속성을 지킬 수도 있고, 지키지 못하고 난잡하게 되는 것을 막을 수 없게 되기도 한다. 문제는, 소프트웨어 요구사항이 아키텍처 설계와 추적관리를 한다거나 설계로부터 단위설계 및 구현 및 단위 시험의 부분이 좀 부자연스럽다는 것이다.

어떤 점에서일까?

사실, A-SPICE의 활동들은 억지로 하라고 하면 할 수는 있다. 고객이 원한다는데 못할 이유가 있겠는가? 그렇게 해야 납품하는 것을 허락하겠다는데, 어쩔 수 없지 않은가? 그런데, 소프트웨어의 개발방식이 단위 설계까지 한다는 것이 사실 그닥 자연스럽지는 않다는 것이 내 생각이다.

이 얘기를 공식석상에서 이야기를 하니까, 누군가 나에게 이런식으로 얘기를 하더라.
“잘 모르시는 것 같은데, 이 분야에서는 다들 그렇게 하고 있어요”

못한다는 것을 말하고 싶은 것이 아니라, 그런식을 하는 것이 자연스러워 보이지는 않는다는 것이 내 말의 의미이다. 너무나도 작위적이고 부자연스럽다는 말이다. 그렇게 하라고 하면 못하는 건 아니다. 다만 너무 불편한 느낌이다.

그런식의 프로세스는 리팩토링 같은 것은 생각할 수 없다. 그런 활동 자체가 용납이 되지 않는 프로세스라고 생각된다. 그리고 기본적으로 waterfall style의 개발 활동이 아닌가 생각한다. (waterfall이나 v나 도찐개찐이라고 본다면 말이다.)

식사를 할 때 절도있게 식사를 해야 하며, 팔은 직각상태를 유지해야 한다는 규칙을 준수하고 식사를 해야 하는 상황과 비슷한 느낌이다. 뭐 그렇게 밥을 못 먹겠느냐만은 상당히 불편하고 우스꽝스러운게 사실 아닌가? (물론 개인적 취향에 따라 다를 수 있다.)

내가 이 글을 올리면 그렇지 않다고 항변할지도 모르겠다. 내 대답은 “사람마다 style이 다른 거니까 편할대로 하면 되니 그게 편하면 그렇게 하세요” 이다. 다른 사람이 볼땐 팔을 직각으로 한 채로 식사를 하는 것이 편할 수도 있지 않겠는가? 어쩌면 A-SPICE의 base practice가 정말 편한사람이 있을지도 모른다. 누구는 난 군대체질이라고 말 하는 사람이 있고, 아닌 사람이 있듯이..

A-SPICE를 하는 목적이 좋은 제품 잘 만들어보자고 하는거니까, 몸에 맞으면 다행이고, 안 맞으면 뭐 굳이 하나하나 다 따라해야 할 필요는 없지 않을까 싶다.

핵심은 목표(빠른 납기, 높은 생산성, 최적의 품질, 높은 고객 만족 등등의 조합)를 달성하기 위한 여러 좋은 사례들 중에 자신이 맞는 것을 선택해서 하는 것일 것이다. 그런점에서 silver bullet은 없다고 생각한다. customizing이 필수적. 하지만 실제 컨설팅 현장 가서 그런소리 하면 준비안해왔다고 고객이 화를 낸다는…

 

 

 

도메인 지식만 알고 있으면 요구사항 작성에 문제가 없는가?


요구사항 없이 개발했던 프로젝트를 개선할 수 있는 기회가 있었다.

그 프로젝트의 프로세스는 코딩하고 수정하기 수명주기를 사용하고 있었고, 코드는 찰떡같이 하나로 붙어 있어서 컴포넌트로 분리하는 외과적 수술을 하는 것도 불가능했다.

사실 해보려고 했다. 하지만 전역변수들이 촘촘하게 여러 function들을 묶어주는 미세혈관 같은 역할을 해서, 그것들을 하나하나 장인정신으로 떼어내는 것은 정신나간짓이라고 판단되었다. 2달정도 해봤는데 성과는 없었다. 10달 더 작업해도 결과는 같을 것 같았다.

제품의 구현 기준 혹은 출시 기준을 수립하기 위한 작업으로 방향을 바꿨다. 요구사항이라는 것이 과거에는 1차원적이거나 2차원적이라고 생각했다. 즉 sentence들이 1차원 혹은 2차원적으로 차곡차곡 쌓아서 틀에 넣고 찍으면 요구사항이 될 것으로 생각했다.

물론 그것도 요구사항이 되기는 한다. 다만 그것을 읽고 ‘내가 방금 읽은 것이 뭐였더라?’라고 깨닫게 되는 요구사항이 될 가능성이 높다는 것이다.

그런데 내가 내린 결론은 다음과 같다. 요구사항을 어떻게 정의하고 구조화하느냐에 따라서, 어떻게 concept을 잡느냐에 따라서 설계의 방향과 개발 일정에도 영향을 미칠 수 있음을 깨닫게 되었다는 점이다.

이런 생각을 하게 된 두 가지 사례가 있었다.

체계 개발 프로젝트(시스템들로 이루어진 시스템 개발)에서, 거대 시스템을 sub-system으로 나누고 그것을 기반으로 WBS를 만든다. 체계 Concept이 planning에 영향을 준 것이다.

코딩을 보고 reverse로 개념을 추출하는 도중 concept이 구조화되지 않아서 이것을 3차원적으로 입체적으로 구성하였다. 그러다보니 설계가 변경되어야 할 필요가 생겼다. 추가하거나 삭제한 concept은 없지만, 구성을 변경하니, 설계가 달라져야 할 필요가 생겼다. Concept은 어느 정도 설계의 guideline을 제공해 준다.

이 글의 결론이다. 도메인 지식만 가지고는 문서가 나오지 않는다. 머릿속에서 1차원 혹은 2차원 수준으로 맴돌고 있는 개념을 추출해서 그것을 3차원으로 구조화 할 수 있는 능력이 있어야 한다.

꼭 개발 능력이 절대적으로 필요한 건 아닌데, 요구사항 작성하면서 약간의 설계 제약 혹은 설계의 가이드라인을 제시하게 되기 때문에 구현관점에서 터무니 없는 요구사항이 되지 않으려면 ‘약간’은 필요하다.

다른 식으로 표현하자면, 요구사항을 잘 정리하는 능력이 필요하다. 도메인 전문가가 못하면 요구사항 분석가가 갖춰야 할 능력이다.