Software Architecture: A Mirror Of Organization

Software Architecture

Architecture is the art and technique of designing and building, as distinguished from the skills associated with construction. It is both the process and the product of sketching, conceiving, planning, designing, and constructing buildings or other structures. — Wikipedia

Architecture 란, 통상적으로 건축물 따위의 물리적 구조를 계획, 설계하고 건설하는 과정과 그 결과물을 말한다. 어떠한 목표를 달성하기 위해 구조를 설계하고, 그 구조를 현실화하기 위한 기술적 및 예술적 기법들을 합의를 통해 미리 정의하여 시각화한 것이다. 이는 결과물에 반영되지만 그 결과물에서는 표면적으로 나타나지 않기 때문에 내부적인 기밀 문서로 취급되기 마련이다. 건물이나 반도체, 기계 등의 architecture 는 그 결과물로부터는 유추하기 힘든 경우가 대부분이다. 또한, architecture 는 일반적으로 실제 이를 적용해 결과물을 만드는 실행자와 이를 계획하고 설계하는 기획자가 분리되어있다.

그런데 소프트웨어는 상황이 다르다. 정의 자체에서는 통상적인 의미를 따르지만, 소프트웨어는 그 표면 상에 architecture 를 드러낸다. 또한 architecture 가 기획자에게서 실행자에게 전달되는 단방향적 성격을 갖는 다른 영역들과 달리, 소프트웨어는 개발자에 의해 발견된 문제가 architecture 전체에 영향을 미칠 수도 있는 양방향적 성격을 갖는다. Software architecture 는 개발이 진행됨에 따라 함께 변하는 유동적인 모습을 보이게 된다. 이 독특한 특징은 소프트웨어의 기능 결함을 기술적인 문제 뿐만 아니라, 구조적인 문제, 더 나아가 조직의 문제로까지 연결할 수 있게 만든다. 어떻게 이런 일이 가능할까?

Visibility

전통적인 architecture 는 결과물에 반영되지만, 그 표면에 드러나지는 않는다. 건물이나 반도체 따위의 설계 도면은 내부 문서로 취급되며, 완성된 건물의 내부 구조를 파악하기 어려운 것과 같이, 결과물만으로 architecture 를 유추하기는 매우 어렵다. 그런데 소프트웨어는 그렇지 않다. 코드 그 자체가 설계이자 구현이며, 그 어떤 변환 과정도 거치지 않고 그 자체로 기능하게 된다. 거기에 더해, 텍스트를 기반으로 하고 있기 때문에 그 접근성이 매우 뛰어나다. 추가적인 수단을 통하지 않아도 그 구조를 해석할 수 있는 형태를 취하고 있고, 코드 그 자체가 의사소통의 결과물이기 때문에 software architecture 는 쉽게 해석할 수 있다.

Fluidity

"어떠한 목표를 달성하기 위해 구조를 설계" 하는 architecture 라는 개념은 소프트웨어에서도 동일하다. 하지만 변화하는 목표에 대해 새로운 설계로 대응하는 다른 영역들과 달리, 소프트웨어는 이에 대해 기존의 설계를 수정하여 대응한다. 이전 설계에서 연계 가능성을 염두에 두지 않고 설계된 기능에 대해서 연계 필요성이 추가로 발생한다면, 소프트웨어는 연계 인터페이스를 추가하고 연계를 위해 기존 기능의 설계를 변경하게 된다. Software architecture 는, 이러한 면에서 다른 영역에 비해 유동적인 모습을 보인다.

Bidirectional

Architecture 가 유동적이라는 뜻은, 그 design 이 고정되지 않는다는 말과 같다. Software architecture 의 양방향성은 여기서 드러난다. 앞서 언급한 변화하는 목표는 주로 설계 단계가 아닌 개발 단계 중에 나타난다. Architecture 를 적용하는 실행자가 목표의 변화를 감지하여 설계를 수정해야 하는 것이다. 이런 상황은 앞서 Separation of Concerns 의 결론에서 언급한 바 있다. 설계 과정에서 식별할 수 있는 concern 과 구현 과정에서 발생하는 concern 이 다를 수 있으며, 구현 과정에서 발견된 concern 이 architecture 에 영향을 미칠 수 있다는 것이다. 이 단계에서 조직의 소통 구조 및 능력에 대한 중요성이 부각된다. 효과적인 소통 기반을 갖춘 조직이라면, 실행자와 기획자 사이의 원활한 소통으로 설계를 수정할 수 있고, 더 나아가 설계에 대해 쌍방의 일관적인 이해를 바탕으로 수정 과정이 간소화될 수 있을 것이다. 이런 이해 기반을 갖추기 위해 소프트웨어에서는 ADR (Architectural Decision Record) 이 작성되고 공유되며, 결과와 과정 사이가 단절되지 않고 architecture 의 모습이 product 에 투영된다.

Conway's Law

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin E. Conway, How Do Committees Invent?

1968 년, How Do Committees Invent? 에서 컴퓨터 과학자이자 프로그래머인 Melvin Conway 는 시스템을 설계하는 조직은 자신의 소통 구조와 같은 형태의 결과물을 만들어낼 수 밖에 없다고 주장했다. 그가 주장한 내용은 다음과 같다.

Argument Structure

1. Design as System-Building
   Conway 는 design 의 범위를 소프트웨어 뿐만 아니라 무기 체계 설계, 정책 대안 설립 등 아주 넓게 설정했다. 그는 설계 조직의 목적이 일관적으로 구조화된 정보를 담은 문서를 작성 또는 조합하는 것이며, 그 정보가 곧 System Design 이라고 말한다.

2. The Homomorphism Proof
   그는 이 관계를 수선형 그래프를 통해 수학적으로 제시하고 있다.

   1. Design 에 속한 각각의 하위 시스템들은 저마다 대응하는 design group 을 갖는다.
   2. 두 하위 시스템 사이에 branch (communication) 가 있다면, 대응되는 두 design group 사이에는 인터페이스 명세에 대한 합의 과정이 반드시 존재한다.
   3. 하위 시스템 간에 연결점이 없다면, 대응되는 design group 들 사이에는 합의 과정(연결)이 없었음을 의미한다.

   이는 조직과 시스템 사이에 구조 보존 관계 (homomorphism) 을 만들어낸다.

Conclusion

A design effort should be organized according to the need for communication.

그는 이런 관계에 대한 구체적인 사례를 제시하면서, 설계 작업은 소통의 필요에 따라 구성되어야 한다고 주장했다. 그는 "최초"의 설계는 절대로 최적의 설계가 될 수 없고, 시스템 전반에 영향을 미치는 설계 개념은 언제든지 바뀔 수 있기에 효율적인 설계를 위해서는 조직의 유연성이 중요한 역할을 한다고 덧붙인다.

Conway's Law in Software Architecture

Conway's Law 는 소통 구조와 시스템 구조 사이의 대응 관계를 설명할 뿐, 소통 구조가 직접적인 원인이라고 주장하지는 않는다. 하지만 이는 Conway's Law 에서 정의하는 "시스템 설계"의 범위가 아주 넓기 때문이다. 소프트웨어에서 한해서는 경우가 다르다. 조직과 시스템 사이의 상관관계를 설명하는 성격을 띄는 Conway's Law 는 software architecture 에서는 앞서 언급한 세 가지 특징 — Visibility, Fluidity, Bidirectionality — 에 의해 진단 도구로 탈바꿈하게 된다.

• Visibility 로 인해 조직의 소통 구조가 코드에 그대로 노출되며, 숨길 수 없다. 조직의 dysfunction 은 architecture 에 명시적으로 드러나게 된다.
• Fluidity 로 인해 소통 문제가 개발 과정 내내 누적되며, 초기의 문제를 나중에 고칠 수 없다. Architecture 는 조직의 변화 과정을 기록하게 된다.
• Bidirectional 로 인해 발견된 문제가 architecture 를 변경해야 하는데, 이 과정에서 조직의 소통 능력이 결정적이다. 소통이 단절되면 문제는 architecture 에 반영되지 못하고 기술 부채로 쌓인다.

따라서 software architecture 는 조직의 상황을 그대로 투영하는 거울이 되는 것이다.

Legacy code 가 그 대표적인 사례가 될 수 있다. "작동하면 건들지 말라" 는 불문율을 지닌 legacy code 는 조직에서 소통이 단절된 부분을 명시적으로 보여준다. 충분한 예우를 두지 않은 갑작스런 조직 구조의 변화, 만든 사람의 퇴사 등, 이유는 여러가지가 될 수 있겠지만, legacy 가 되어버린 부분에서의 소통 단절, 즉 지식 전달이 끊어진 상황을 의미하게 된다. 어떤 이유로 어떻게 만들어졌는지 그 내막을 아무도 알지 못하니, 말 그대로 "잃어버린 유산"이 되어버리는 셈이다.

Case Study - Gaming Industry

게임 산업에서는 조직의 문제가 소프트웨어에 영향을 미치는 상황이 두드러진다. 이들은 모두 충분한 자본, 인력, 개발 프로세스를 갖춘 대규모 회사들이다. 그럼에도 불구하고 다음과 같은 실패들이 발생했다.

1. Blizzard

2018년 이후, 블리자드 공동 창립자이자 전 CEO 인 마이크 모하임(Michael "Mike" Morhaime) 의 퇴사를 기점으로 다수의 핵심 인력들이 연이어 이탈하는 상황이 발생했다. 이후 월드 오브 워크래프트, 디아블로 시리즈, 오버워치 2 등 이들의 핵심 IP 들의 지속적인 성과 부진과 전반적친 매출 하락세를 겪고 있다. "그 때 그 블리자드는 이제 없다" 라는 팬들의 실망감과 냉소적인 평가는 비단 회사를 둘러싼 논란들 때문만은 아니다. 재미와 완성도를 최우선으로 생각하던 그들의 장인 정신이 끊어진 것이다.

2. EA - DICE

EA 산하의 개발 스튜디오 DICE 의 대표 프랜차이즈, BattleField 에서도 같은 상황이 발생했다. BattleField 5 시리즈 개발 및 출시 시기와 맞물린 대규모 핵심 개발자의 이탈은 소프트웨어의 품질 저하로 이어졌고, 기능은 작동하지만 "BattleField 답지 않다"는 평가를 받았다. 이 상황은 차기작인 BattleField 2042 까지 이어져 시리즈의 성적 부진을 유발했다.

3. Ubisoft

대규모 인력 이탈이 문제를 초래했던 앞선 두 상황과는 달리, Ubisoft 는 자사의 "오픈월드 공식" 으로 무너졌다. 그들은 성공적인 결과를 낸 게임의 시스템을 공식화하여 모든 게임에 적용했다. 이것은 시스템이 성공한 이유와는 단절된 단순한 형태의 모방이었고, 본질을 잃어버린 맹목적인 반복은 자신의 명성을 깎아내릴 뿐이었다.

이 사례들은 software architecture 가 조직의 건강 상태를 드러낸다는 것을 보여준다. 플레이어들이 "예전 같지 않다"고 느끼는 것은 architecture 에 반영된 조직의 변화를 경험하는 것이며, 기술적으로는 작동하지만 본질을 잃은 게임들은 소통이 단절되어버린 architecture 의 결과이다.

게임 산업에서 이러한 사례들을 쉽게 찾아볼 수 있는 것은 게임이 단순한 기능적 시스템이 아닌 경험적 시스템이기 때문이다. 게임의 개발과 운영 과정 모두에서 "왜"는 이용자의 경험을 설계하고, 동기를 부여하며, 혁신을 이끌어내는 원동력이며, 이 "왜"는 문서화할 수 없는 맥락적 이해를 요구한다. 그리고 이 "왜"는 조직적 소통 능력의 척도가 되는 부분이기도 하다.

Conway's Law In Reverse

이 프로젝트는 학습 및 생각의 "과정"을 어떻게 보여줄 수 있을까를 고민한 결과물이다. 단순한 결과물이 아닌, 어떤 목적으로 무엇을 위해 어떻게 생각하여 행동했는가를 담아내면서도, 사용자들에게 부담을 주지 않으려고 지금의 Timeline — ADR — Article/Playground 로 이어지는 progressive disclosure 구조를 고안해냈다. software architecture 가 갖는 특징들(visibility, fluidity, bidirectional)은 이를 구체화하며 발견했다.

이는 의도된 설계가 아니었다. Article 에 가장 깊이 있는 내용을 담고, 8 ~ 10 분 분량의 긴 글에 대한 거부감을 줄여줄 수 있는 Timeline 형태로 진입점을 제시했으며, 그 목적을 최대한 간결하게 설명할 수 있는 ADR dialog 를 적용했다. 그런데 이것이 우연히 software architecture 의 특징을 통해 의도적으로 나의 생각을 표현한 셈이 된 것이다.

• Visibility: 무엇을 만들었는가가 아니라, "왜" 만들었는가 를 Timeline 과 ADR 로 표현할 수 있었고,
• Fluidity: 변화하는 과정을 담아낼 수 있었으며,
• Bidirectional: 목적의 변화에 따라 architecture 도 변화했다.

조직을 반영하게 되는 software architecture 의 특징을 역이용해 "나"를 드러내는 방식으로 사용한 것이다.

Conclusion

Software architecture 는 조직을 비추는 거울이다. 다른 영역들과는 달리, 의도하든 의도하지 않든 소프트웨어는 이를 설계한 조직의 모습을 그대로 드러낸다. 그렇기에 견고한 소통 구조를 갖춘 조직은 견고한 소프트웨어를 만들어낸다. 하지만 software architecture 의 양방향성은 여기에도 적용된다.

위에서 실패 사례로 언급했던 BattleField 는, 그 최신작인 BattleField 6 에서 엇갈린 평가를 받고 있다. 휴대용 보병 화기의 Cold Launch 과정이나 전차 포탄의 세밀한 분리 과정 구현 등의 군사적 부분의 묘사 및 핵심적인 재미에 있어서 호평을 받는 한 편, 캐릭터의 모션이나 게임 플레이에 영향을 주는 최적화 등에서는 마찰을 빚는 중이다.

그럼에도 소비자들은 이전 작인 BattleField 2042 에 비해 시리즈의 명성을 회복했다는 평가까지 있을 정도로 훨씬 긍정적으로 반응하고 있다. 이는 조직이 부분적으로나마 회복되기 시작했음을 시사한다.

이처럼 소프트웨어는 조직의 내부적인 상태를 외부에서도 어느정도 짐작할 수 있게 해준다. Software architecture 에 대한 전반적인 기록이 남아있는 내부에서는 문제가 발생한 지점을 특정할 수도 있을 것이다. 그 기록이 자세할수록, 해결할 문제를 특정하기까지 걸리는 시간도 줄어들 것이다. 이 기록은 절대적인 진리가 아니다. Software architecture 는 변한다. 그 과정을 자세히 기록하고 중요하게 다룬다면, 이 거울은 명확하게 길을 비춰줄 길잡이가 되어줄 것이다.