SYS.4

SYS.4와 SYS.5는 이전 글에서도 말했듯이 Verification을 위한 것이다. 그니까 SYS.4의 경우 SYS.3에서 의도한 내용들이 모두 반영이 되었으며 실제 테스트를 하였을 떄 문제가 없는지를 검증을 해주는 단계이다.

 

그럼 SYS.3가 무슨 의도를 가지고 활동을 했었는지를 고민하면 SYS.4에서 할 일들도 명확해진다. 

SYS.3에서 시스템 아키텍처는 아이템을 여러 기능별 엘리먼트로 분화 시킨다고 했다. 분화 시켰다는 것은 복잡한 체계를 특정 기준에 따라서 따로 따로 분리를 시켰다는 것이고 여기까지의 해위는 정적인 형태이지만 실제 자동화 방식으로 움직이는 제품은 동적인 형태이므로 이 엘리먼트들 간에는 어떤 절차에 따른 신호가 주고 받아져야 자동화가 가능한 것이라고 했다. 

 

※ 여기서 잠깐 검증을 한다는 것의 의미는 자기가 설계한 의도가 그대로 반영이 되었는지를 확인하는 것이라는 것을 먼저 확실히 한다.

 

자, SYS.3 에서 설계한 의도 중 확인을 해야하는 것은 무엇이 있을 수 있겠는가?

먼저 다양하게 분화 시킨 엘리먼트들이 그 각각의 특징을 고스란히 잘 가지고 있는지 확인하는 것이다. 여기서 각 엘리먼트들의 특징은 각 엘리먼트를 블랙박스로 보고 각 엘리먼트의 바로 외부의 특징만 보면된다.

 

왜 그러냐하면 예를 들어 지금 숲을 상상해 봐라 그리고 그 숲 안에는 소나무 무리, 참나무 무리 동백 꽃 나무 등등 여러 종류의 식물들로 구성되어 있다. 그리고 그 안에는 소나무를 좋아하는 벌레 및 동물이 있고 참나무를 좋아하는 벌레 및 동물이 있고 마찬 가지로 다른 식물들도 그러하다. (참고로 나는 나무 별로 분화 시킨 것은 정적 구조를 나타내는 아키텍처 분화라고 생각하고 그 각각의 나무에서 살아가는 곤충 및 동물들은 다른 나무로 옮겨가면서 나무의 번식을 돕는 동적인 형태에 속한 놈들이라고 생각한다. 즉 나무라는 엘리먼트 간의 신호(나무의 수분= 물론 나무의 종류에 따라 수분이 달라질 테고 이를 신호의 Type이라 봐도 무방할 듯)를 주고 받게 하는 것을 곤충 및 동물(나무의 수분을 옮기는 동적인 인터페이스 역할)이 하고 있는 것이다.)

 

처음 숲 이라는 시스템을 분화 시키기 전 까지는 그냥 하나의 숲이고 이 복잡성을 줄이기 위해 숲을 여러 엘리먼트로 분화 시키겠다면 여러분은 본능적으로 나무의 종류별로 분화 시킬 것이다.지금 당신, 당신은 숲을나무 단위로 분화 시킬 때 나무의 겉 모습만 보고 아주 쉽게 분화 시켰다 소나무 및 참나무 등의 내부 속을 파헤쳐서 그 안의 특성을 보고 분화 시킨 것이 아니다. 이처럼 분화 시킨 엘리먼트의 정체성을 확인을 할 때는 블랙박스 형태로 그 엘리먼트의 겉 형태의 특징만 파악하면 된다.

 

그 다음으로 SYS.3에서 설계한 의도를 확인해야 하는 것은 위에서 나누어진 엘리먼트들을 점진적으로 합쳐서 다시 본래의 숲까지 만들어 가는 과정에 처음 본래의 숲이 정확하게 나오는지를 확인하는 것이다. 즉 서로 다른 종류의 나무 엘리먼트를 합쳐서 작은 숲을 만들고 작은 숲끼리 합쳐서 좀 더 큰 숲을 만들고 그래서 결국 원본 설계한 대로의 본래의 숲이 나오게 하는지 검증을 해야 하는 것이다. 근데 누군가는 이거 그냥 설계도 있으니까 원본 숲이 나오게 조합만 맞추면 되는 거 아니야? 이럴텐데 (이게 흔히 말하는 빅뱅 방식의 통합) 이건 사실 미친짓이다. 왜냐하면 애초에 우리는 우리가 설계한 하는 것이 너무 복잡하여 그것을 쪼개어 단순화(분화) 시켜서 설계한 것인데 이 단순화 된 설계들 조차도 실제에서 설계 의도대로 작동하는 지 알 수 없기 때문에 검증을 하는 것인데 그 단순화 시킨 것들 하나 하나 먼저 검증을 하지 않고 한 번에 본 원래 숲의 형태로 합쳐서 검증을 하겠다? 이건 그냥 애초에 맨 처음의 검증의 의도를 까먹은 것이나 마찬가지인 모순이다. 

아무튼 그렇기 때문에 우리는 분화 시킨 엘리먼트들을 순차적으로 하나씩 통합을 해서 그 작은 단위부터가 문제가 없음을 확인을 한 후에 마지막 본래 원형인 숲을 검증해야지 비로소 모든 설계한 의도들이 잘 반영이 된 것이라는 것을 연역적으로 알 수 있다.

 

이를 실무적 내용으로 옮겨 설명을 하자면

 

에이스파이스에서는 통합을 전략적으로 하길 원한다.(탑다운, 바텀업 방식 같은) 

그리고 추가적으로 도중에 설계 변경이 생길 것을 대비하여 회귀 전략을 짠다(변경에 의한 영향을 받을 것 같은 부분만 테스트 하겠다는 의미)

또한  실무에서는 설계한 의도를 검증하기 위해 그 의도를 검증할 수 있을 테스트 케이스를 짜는데 이 테스트 케이스는 아키텍처를 단순화 할 수록 많이 쪼개지게 되고 그렇기 때문에 이를 검증하기 위한 테스트 케이스는 어마무시하게 많기 떄문에 너무 많은 공수가 들어 나름의 전략을 가지고 전략은 모든 것을 커버할 수 있도록 테스트 케이스를 만들어 대비하지만

실제 조금씩 통합하면서 검증할 때 사용하는 테스트 케이스는 꼭 필요할 것 같은 것으로 추려서 사용하는데 이를 test set(선택된 테스트 케이스라고 함)