by
Jul 19. 2022
인문학적 반도체_5. SW개발(2)
3장. 반도체는 어떻게 만들어지나?
Embedded SW 개발
SoC를 만드는 Fabless기업들은 SoC에서 구동하는 기본적인 SW도 고객사에게 전달해야 합니다.
통상 AP를 만드는 반도체 기업들의 산출물은 다음과 같습니다.
SW를 만드는 개발 방법은 다양합니다. 여러 SW 개발 방법론이 있으며 그 방법론들도 회사마다 다르게 적용하는 경우가 많습니다. 같은 방법론을 적용하고도 회사마다 조금씩 다른 것을 내재화한다고 말합니다만 최대한 발행 산출물을 줄이기 위한 개발자 사이의 암묵적 동의 같아 보입니다.
SW도 SoC처럼 기본적으로 분석 --> 설계 --> 구현 --> 검증 단계를 거쳐 만들어집니다.
이런 개발 단계가 폭포수처럼 위에서 아래로 흐르는 방식이 폭포수 모델입니다.
가장 오래되고 널리 사용되는 개발방식이지만 최종 결과물이 나오기 전에는 어떤 결과물이 나올지 알 수 없다는 단점이 있습니다.
점진적 또는 진화적 개발 방법도 있습니다. 폭포수 모델은 강물을 거슬러 오르는 저 힘찬 연어(노래 제목 같습니다만?)처럼 단계를 거슬러 올라가기에는 부적합합니다. 또한 수시로 변화하는 요구사항을 반영하기도 어렵지요. 이런 단점을 해결하기 위해 나온 개발방식이 점진적(진화적) 개발방식입니다. 흔히들 버전 1, 버전 2, 버전 3 이렇게 sw를 고객사에 release 하는 방식을 의미합니다. 이런 방법으로 SW를 배포하면 몇 가지 기능이 부족하더라도 초기에 사용 또는 교육이 가능합니다. 또한 시스템에서 일어나는 예상하지 못했던 문제를 신속하고 꾸준히 고칠 수 있는 장점이 있습니다. 그러나 버전 관리, 전문적 용어로 형상관리 등 프로젝트 관리가 복잡해지기 때문에 대규모 프로젝트에는 부적합하다는 단점이 있습니다.
요즘 대부분의 스타트업들이 사용하는 애자일(Agile) 방법론도 있습니다.
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일 소프트웨어 개발 선언
대표적으로 스크럼(Scrum), 린( Lean) 방식이 있습니다. 둘 다 핵심은 애자일 이란 단어의 의미처럼 민첩하고 기민하게 sw를 개발하는 것입니다. 스타트업이 많이 사용하는 린 개발 방식은 MVP(Minimum Viable Product)라고 부르는 최소 요건 제품을 최대한 빨리 만들어 고객의 반응을 살피는 것입니다. 고객의 요구사항에 벗어났다고 측정되면 바로 반영하여 개선하여 다시 MVP를 만들고 반응을 측정하고 다시 개선하고를 반복하는 것이지요. 이런 순환 루프를 반복함에 따라 효율적으로 빠르게 고객이 요구하는 제품을 출시할 수 있습니다. 순환 루프를 반복하다 보면 아예 피봇(Pivot)이라는 방향 전환을 결정하기도 합니다.
마지막으로 V-Model이 있습니다.
이 모델은 폭포수 모델에 각 단계별로 테스트 단계가 추가된 모델입니다. 산출물 중심의 폭포수 모델과 다르게 각 개발 단계를 검증하는데 초점을 둔 것이 V-Model입니다.
[ V- Model ]V-Model의 장점은 coding전에 충분한 요구사항 분석과 설계를 할 수 있다는 것입니다. 그럼에도 불구하고 요구사항이 변경되면 대응이 어렵다는 단점이 존재하지요.
아래는 V-Model의 Testing Level을 정의, 목적, 수행주체 등으로 구분하여 설명하였습니다.
V-Moel을 V&V (Verification & Validation) Model로도 부릅니다.
그럼 Verification과 Validation의 차이는 무엇일까요?
Verification은 검증으로 주로 번역하고 Validation은 확인이라고 번역합니다.
Verificaion : Are we building the system right? (우리가 제품을 올바르게 빌드하고 있나?)
Validation : Are we building the right system? ( 우리가 올바른 제품을 빌드하고 있나? )
국내 시중 은행에서 사용하는 캠페인 문구에서도 비슷한 예를 찾아볼 수 있습니다.
Verificaion : Do the thing right (절차에 따라 올바르게 일하라)
Validation : Do the right thing (고객이 만족하는 올바른 일을 하라 )
쉽게 말하자면, Verificaion은 개발자 중심의 시스템 검증 과정이며, 무언가를 만드는 '절차'를 잘 지켰는지를 말합니다. 주로 정적 테스팅 (Static Testing) 기법을 씁니다.
반면 Validation은 사용자 중심의 시스템 검증 과정이라고 할 수 있습니다. 사용자 입장에서 최종적으로 만든 결과물이 잘 나왔는지를 말합니다. 이를 위해 주로 동적 테스팅 (Dynamic Testing) 기법을 씁니다.
결국 Validation을 통과하지 못하면 프로젝트가 성공했다고 말할 수 없는 것입니다.
아래는 Testing종류와 기법에 대한 설명입니다.
