레퍼런스 아키텍처와 표준 아키텍처의 차이

아키텍처 기본

최근 방산 관련 업체에서 아키텍처 표준화 교육을 진행하고 있습니다.

교육을 준비하는 과정에서 “레퍼런스 아키텍처”와 “표준 아키텍처” 간의 차이, “표준 아키텍처”와 “아키텍처 표준화” 간의 차이에 대한 질문이 있어서 이번 글에서는 “레퍼런스 아키텍처”와 “표준 아키텍처” 간의 차이에 대해서 알아보겠습니다.

레퍼런스는 한글로 “참고”, “참조”라는 의미로 설계 업무에서 사용할 때는 “기준”, “원칙을 만들 때, 이것을 실제로 적용하는 과정에서 도입하기 쉽고 따라 하기 쉽게 예시로 만들어둔 결과물을 의미합니다. 레퍼런스 아키텍처는 보통 선행 프로젝트의 아키텍처 산출물을 후속 프로젝트에서 활용할 수 있도록 정제해 놓은 설계 산출물을 의미합니다.

1. 레퍼런스 아키텍처는 일반화 과정을 거치지 않아도 된다.

보통의 레퍼런스 아키텍처는 프로젝트 결과물 자체로 정리된 경우가 대부분이지만, 커스터마이징 하기 쉽게 정제를 해놓거나 아키텍처 산출물 템플릿만 정리하는 경우도 있습니다. 그래서, 남겨두어야 할 영역과 신규로 작성해야 할 영역의 구분이 모호하죠. 경험적으로 활용하거나, 아니면 후속을 진행하는 설계자의 재량에 따라서 활용 효과가 달라는 문제가 있습니다.

반면에 표준 아키텍처는 그 자체가 기준이기 때문에 후속 프로젝트에서 사용할 수 있도록 일반화해놓고, 표준화된 영역과 신규로 작성해야 할 영역의 구분이 명확합니다. 아니, 신규로 작성해야 할 영역을 제외하고는 다른 부분은 유지하도록 강제화해야 합니다. 이를 위해서는 표준 아키텍처는 과거에 적용 실적이 충분하고, 미래에도 일정 기간 동안 적용해야 하기 때문에 일반화 과정을 거쳐야 합니다.

2. 레퍼런스 아키텍처는 품질을 보증하진 않는다.

레퍼런스 아키텍처는 그것을 따라서 만드는 시스템의 품질을 보증하진 않습니다. 과거보다 뛰어날 수도 있고, 떨어질 수도 있습니다. 이 또한 활용하는 사람의 역량, 활용하는 방식에 따라서 달라집니다. 그렇다면 결과물의 품질도 보증하지 않는데 레퍼런스 아키텍처를 활용하는 의미가 있을까요? 보통 레퍼런스 아키텍처는 과거의 산출물을 재사용하여 맨땅부터 시작하는 경우보다도 접근성이 높아지고 시간이 단축된다는 측면과 함께 개선의 기준점을 제시한다는 의미가 있습니다. 맨땅부터 새롭게 만든다면 비교할 대상이 없으나, 레퍼런스 아키텍처를 활용하면 그것보다 잘 만들어야 한다는 기준점이 생기는 것이죠.

표준 아키텍처는 그것을 따르는 시스템이 갖는 최소 수준의 품질을 보증해야 합니다. 표준화 활동 자체가 그렇습니다. 표준화를 하는 이유는 그것을 따르면 갖추게 될 최소한의 기준을 제공하는 겁니다. 기복이 없다는 표현을 하죠. 반복해서 작업을 할 때 변동, 편차가 작은 경우를 기복이 없다고 표현하죠. 표준화는 기복이 없는 것을 추구합니다. 기복이 없으면 예측이 가능하고, 예측이 가능하면 관리를 할 수 있습니다. 표준 아키텍처도 동일합니다. 표준 아키텍처를 활용하면 기복이 없어야 합니다. 그런 상황을 위해서 이전 수행한 여러 차례 활용 사례를 분석한 후에 표준 아키텍처라는 것을 만들었겠죠.

3. 레퍼런스 아키텍처는 작성/적용 등 관련 프로세스가 없거나, 표준화하지 않아도 된다.

레퍼런스 아키텍처는 수시로 바뀔 수 있고, 정해진 프로세스가 아니더라도 변경할 수 있습니다. 현재 프로젝트가 우수 사례로 꼽힐 정도로 제대로 수행했다면, 기존의 레퍼런스 아키텍처를 대체할 수도 있겠죠. 시점이나 절차는 표준화되어있지 않아도 됩니다.

반면에 표준 아키텍처는 정해진 프로세스를 통해서만 바꿀 수 있어야 합니다. 아무리 신규로 수행한 프로젝트가 우수해도 그것을 일반화하기 위해서는 검증이 필요합니다. 표준화에서는 반짝 스타는 필요가 없습니다. 순간적으로 치고 올라온 베스트셀러보다는 지속적으로 성과를 내는 스테디셀러가 표준화 대상으로 적합합니다.

4. 레퍼런스 아키텍처는 선택, 적용에 대한 강제하지 않는다.

레퍼런스 아키텍처는 강제하지 않습니다. 선택의 자유, 적용의 자유가 있는 편입니다. 활용할 수 있으면 좋겠지만, 활용하지 않는다고 하여 뭐라고 하거나 제약을 걸지 않습니다. 그래서, 관리하는 주체도 따로 없는 것이 일반적입니다. 굳이 있다면 레퍼런스 아키텍처를 만든 프로젝트 당사자나 팀이 되겠죠.

반면에 표준 아키텍처는 강제화해야 합니다. 준수해야 하는 프로세스가 있고, 그것을 관리하는 조직이 있습니다. 그리고, 일반화를 해야 하고 정해진 절차로 변경을 해야 하므로 거버넌스를 가진 조직이 별도로 있어야 합니다. 표준 아키텍처를 처음 만들었거나, 처음 적용한 부서가 아닐 가능성이 높겠죠. 특정 개발 부서나 팀이 그 역할을 맡게 되면 과적합화 되어 표준 아키텍처는 표준으로 활용하기가 어렵게 됩니다.

5. 레퍼런스 아키텍처는 새로운 레퍼런스 아키텍처로 대체되고, 그 종류를 관리하지 않아도 된다.

앞서 레퍼런스 아키텍처는 새로운 레퍼런스 아키텍처로 대체된다고 말했습니다. 사실 대체가 안 돼도 굳이 종류를 관리할 필요는 없습니다. 상황에 맞게 적용하면 되니까요.

반면에 표준 아키텍처는 그 종류를 철저히 관리해야 합니다. 많으면 많을수록 관리해야 하는 로드가 크게 들게 됩니다. 만약 표준 아키텍처가 지향해야 하는 기준점이 높아져야 한다면 거버넌스를 가진 조직의 주도로 일부 개정을 하거나, 최적화를 통해서 표준 아키텍처 자체를 변경해야 합니다. 이런 작업을 해야 하는 데 종류가 많다면 무리가 있겠죠?

위와 같은 차이로 인하여 일반적으로 레퍼런스 아키텍처를 활용하다가 어느 정도 성숙도가 올라가면 표준 아키텍처로 전환하는 것이 일반적입니다. 물론, 시스템의 생애 주기가 짧은 경우나 변화가 심한 경우에는 레퍼런스 아키텍처가 표준 아키텍처로 전환되지 않는 경우도 있겠죠.

중요한 것은 위와 같은 차이로 인하여 표준 아키텍처에는 거버넌스 요소가 필수라는 겁니다. 제가 예전에 교육을 할 때 이렇게 말한 적이 있습니다. “관리하지 않는 표준화는 단지 공허한 외침일 뿐이고, 실행하지 않는 표준화는 겉보기 좋은 껍데기일 뿐이다.”

다음엔 “표준 아키텍처”와 “아키텍처 표준화”의 차이에 대해서 알아보겠습니다.