사이먼 로러, 현대적 엔터프라이즈 아키텍처의 재정의: 결과 중심 설계 강조

사이먼 로러는 GOTO 2025 강연에서 엔터프라이즈 아키텍처(EA)의 현대적 정의에 대한 논의를 시작했다. 그는 배리 오라일리가 '엔터프라이즈 아키텍처는 존재하지 않는다'고 언급했던 것을 인용하며, 전통적인 EA에 대한 회의적 시각이 있음을 인정했다.

이는 현재 엔터프라이즈 아키텍처가 과거의 원칙과 관행만으로는 현대 기업의 복잡성을 해결하기 어렵다는 인식을 반영한다. 로러는 이러한 배경 속에서 새로운 접근 방식의 필요성을 제시하며 강연의 문을 열었다.

사이먼 로러는 현대적 엔터프라이즈 아키텍처가 데이브 팔리의 현대 소프트웨어 엔지니어링 접근법에서 영감을 받았다고 설명했다. 이는 과거의 엔터프라이즈 아키텍처 방식과는 결별하고, '결과'에 초점을 맞추는 새로운 접근 방식임을 시사한다.

로러는 이 새로운 접근법이 단순히 기술적 아키텍처에 머무르지 않고, 실제 비즈니스 가치와 결과물을 만들어내는 데 집중해야 한다고 강조했다. 이는 엔터프라이즈 아키텍처가 단순히 시스템을 설계하고 관리하는 역할을 넘어, 기업의 성과에 직접적으로 기여하는 전략적 도구가 되어야 함을 의미한다.

사이먼 로러는 현대 기업을 위한 엔터프라이즈 아키텍처의 5가지 핵심 요소를 'ABCD' 모델로 제시했다. 'A'는 사람, 가치, 기술을 정렬(Aligning people and value and technology)하는 것을 의미한다. 이는 모든 요소가 한 방향으로 작동하여 시너지를 내는 것을 목표로 한다.

'B'는 '더 나은 가치를 더 빨리, 더 안전하게, 더 행복하게(Better value sooner, safer, happier)' 제공하는 것을 강조하며, 이는 린(Lean) 원칙과 애자일(Agile) 철학을 반영한다. 'C'는 지속적이고 대화적(Continuous and conversational)인 접근을 의미하며, 끊임없는 소통과 피드백을 통해 아키텍처를 발전시켜야 함을 나타낸다. 'D'는 엔터프라이즈 규모에서의 데브옵스(DevOps at enterprise scale)를 지향하며, 개발과 운영의 통합을 통해 효율성을 극대화하는 것을 강조한다. 마지막으로 'E'는 진화하는 엔터프라이즈 아키텍처(Evolutionary enterprise architecture)를 의미하며, 아키텍처가 고정된 것이 아니라 끊임없이 변화하고 적응해야 함을 역설한다.

사이먼 로러는 소프트웨어 엔지니어링의 초기 역사를 설명하며, 1994년 스탠디시 그룹이 발표한 '카오스 리포트'를 언급했다. 이 보고서는 당시 소프트웨어 프로젝트의 약 70%가 실패했다는 충격적인 통계를 제시하며, 기존의 소프트웨어 개발 방식에 대한 근본적인 반성을 촉구했다. 이는 현대적 아키텍처 접근법이 등장하게 된 중요한 배경 중 하나로 작용했다.

사이먼 로러는 과거의 전통적인 소프트웨어 개발 방식이 매우 비효율적이었다고 지적했다. 그는 코드 작성에 들어가기 전 몇 달 동안 계획만 세우고, 코드를 작성하는 데 또 몇 달을 보낸 후, 이를 테스트 팀에 넘겨 몇 달간 테스트를 진행하는 식의 단계별 프로세스가 문제였다고 설명했다.

이러한 방식은 각 단계 간의 단절을 야기하고, 문제가 뒤늦게 발견되어 수정 비용이 크게 증가하는 결과를 초래했다. 로러는 이처럼 긴 주기의 폭포수(waterfall) 모델이 현대의 빠르게 변화하는 비즈니스 환경에는 전혀 적합하지 않음을 강조하며, 새로운 접근 방식의 필요성을 역설했다.

사이먼 로러는 소프트웨어 아키텍처에서 모놀리스(monolith)와 마이크로서비스(microservices)의 구분 자체가 핵심을 놓치고 있다고 강조했다. 그보다는 팀 단위의 소프트웨어 소유권과 독립적인 배포 및 테스트가 훨씬 중요하다고 설명했다.

아키텍처 형태보다는 팀이 자신들의 소프트웨어를 책임지고 개발부터 배포, 운영까지 전 과정을 주도하는 것이 현대적 소프트웨어 개발의 성공 요인이라는 것이다. 이는 팀 중심의 자율성과 책임감을 통해 더 빠르고 효율적인 개발을 가능하게 한다.

사이먼 로러는 현대 엔터프라이즈 아키텍트의 역할을 명확히 재정의했다. 그는 아키텍트가 팀에게 무엇을 해야 할지 지시하는 사람이 아니라, 팀 내에서 팀원들이 올바른 아키텍처 결정을 내릴 수 있도록 돕는 '코치'가 되어야 한다고 설명했다. 아키텍트는 팀의 일원으로서 팀의 역량을 강화하고, 기술적 가이드를 제공하며, 최적의 해결책을 찾도록 지원해야 한다.

이러한 역할 변화는 전통적인 상명하달식 의사결정 구조에서 벗어나, 팀의 자율성을 존중하고 협업을 촉진하는 현대적 조직 문화에 부합한다. 아키텍트는 지식을 공유하고, 경험을 바탕으로 조언을 제공함으로써 팀이 스스로 성장하고 발전할 수 있도록 돕는 역할을 수행한다.

결과적으로 아키텍트의 역할은 기술적 전문성을 바탕으로 팀의 성과를 극대화하고, 조직 전체의 아키텍처 역량을 향상시키는 데 기여하게 된다.

사이먼 로러는 기업 아키텍트가 현대의 복잡한 전체 시스템을 머릿속에 전부 담는 것은 사실상 불가능하다고 지적했다. 대신 아키텍트의 역할은 '사회기술적 아키텍처(sociotechnical architecture)'에 집중해야 한다고 강조했다. 이는 누가 어떤 팀에 속해 있는지, 각 팀이 무엇을 하는지, 그리고 정보가 필요할 때 누구에게 문의해야 하는지 등 팀 간의 관계와 소통 방식에 중점을 두는 접근 방식이다.

로러는 아키텍트가 시스템의 모든 세부 사항을 아는 것보다, 팀들 간의 상호작용과 정보 흐름을 이해하고 최적화하는 것이 더 중요하다고 설명했다. 이는 기술적 요소뿐만 아니라 조직 구조, 커뮤니케이션 패턴 등 사회적 요소까지 고려하는 통합적인 아키텍처 접근법을 의미한다.

이러한 사회기술적 아키텍처는 시스템의 복잡성을 관리하고, 효율적인 협업을 촉진하며, 궁극적으로 기업의 목표 달성에 기여하는 데 필수적인 역할을 한다.

사이먼 로러는 레거시 아키텍처에서 흔히 나타나는 비효율적인 조직 구조의 사례를 제시했다. 그는 UI를 담당하는 팀, API 계층을 담당하는 팀, '그리팅 서비스'를 담당하는 팀, '플래닛 서비스'를 담당하는 팀, 그리고 데이터베이스를 소유한 또 다른 팀이 각각 나뉘어 있는 구조를 예로 들었다.

이러한 계층화된 팀 구성은 특정 기능 구현을 위해 여러 팀 간의 복잡한 협업과 조율을 필요로 하며, 이는 개발 속도를 저하시키고 의사소통 비용을 증가시키는 주요 원인이 된다. 로러는 이러한 구조가 현대의 빠른 개발 환경에 적합하지 않음을 강조하며, 팀 간의 경계를 허물고 기능 중심의 팀 구성을 제안했다.

사이먼 로러는 마이크로서비스나 작은 서비스, 또는 모놀리스 아키텍처 자체를 설계하는 최선의 방식은 아닐지라도, 특히 분산 시스템에서 팀 간의 계층화된 구조는 매우 비효율적이라고 지적했다. 각 팀이 특정 계층만을 담당하는 방식은 서비스 전반에 걸친 변경이 필요할 때 여러 팀의 조율을 요구하며, 이는 필연적으로 개발 속도를 늦추고 복잡성을 증가시킨다.

이러한 계층화는 각 팀의 독립적인 배포와 운영을 방해하며, 문제 발생 시 책임 소재를 모호하게 만들기도 한다. 로러는 분산 시스템 환경에서는 팀이 서비스의 전체 수명 주기를 소유하고 관리하는 것이 훨씬 효율적이라고 강조하며, 전통적인 계층형 조직 구조에서 벗어나야 한다고 역설했다.

사이먼 로러는 아키텍처 복잡성의 비대칭성에 대해 설명했다. 그는 시스템에 새로운 복잡성을 추가하는 것은 비교적 저렴할 수 있지만, 일단 추가된 복잡성을 되돌리거나 제거하는 것은 훨씬 더 많은 비용이 들고 비대칭적이라고 지적했다. 특히 분산 시스템에서는 복잡성을 제거하기 위해 여러 곳에 걸쳐 변경 사항을 적용해야 하므로 그 비용과 노력이 기하급수적으로 증가한다.

이는 아키텍처 결정 시 신중함을 요구하며, 불필요한 복잡성을 처음부터 도입하지 않는 것이 중요함을 시사한다. 복잡성은 기술 부채로 이어지기 쉬우며, 장기적으로 시스템 유지보수와 확장에 큰 걸림돌이 된다. 따라서 아키텍트는 복잡성을 추가할 때 그 가치와 비용을 면밀히 따져봐야 한다.

사이먼 로러는 새로운 서비스 추가 요청이 있을 때, 단순히 '새로운 서비스가 필요하다'고 말하는 것이 아니라, 해당 서비스가 기존 아키텍처에 어떤 복잡성을 추가하는지 면밀히 검토하는 '대화'가 중요하다고 강조했다. 그는 '풀 리퀘스트(pull request)' 제출과 같은 과정을 통해 새로운 서비스가 기존 환경에 가져올 복잡성을 숙고해야 한다고 설명했다.

이는 새로운 서비스가 추가적인 복잡성을 감수할 만큼의 가치를 제공하는지에 대한 질문으로 이어진다. 로러는 아키텍트가 단순히 새로운 기능을 추가하는 것을 넘어, 시스템 전체의 복잡성 관리와 장기적인 유지보수 비용까지 고려해야 함을 역설했다.

사이먼 로러는 플랫폼 전략의 중요성을 강조하며, 기업이 제공하는 표준화된 플랫폼을 사용함으로써 아키텍처 규정 준수(architectural compliance)를 상당 부분 자동으로 보장받을 수 있다고 설명했다. 플랫폼이 이미 대부분의 체크리스트 항목을 충족시키거나 그 중 상당 부분을 해결해 주기 때문에, 개발팀은 별도의 노력을 크게 들이지 않고도 보안 및 아키텍처 표준을 따를 수 있다는 것이다.

이는 개발자들이 핵심 비즈니스 로직에 더 집중할 수 있도록 돕고, 전사적인 아키텍처 일관성을 유지하는 데 기여한다. 로러는 플랫폼 사용이 기업의 전반적인 기술적 건전성과 규정 준수를 위한 효율적인 방법임을 시사했다.

사이먼 로러는 현대적 엔터프라이즈 아키텍트가 단순히 개발(dev) 측면에서만 일하는 것이 아니라고 강조했다. 그는 아키텍트가 서비스 관리 및 서비스 안정성(service reliability) 영역에서 일하는 동료들과 매우 긴밀하게 협력하고 소통해야 한다고 역설했다.

이는 전통적인 사일로(silo) 구조에서 벗어나, 개발과 운영, 안정성을 아우르는 통합적인 관점으로 아키텍처를 접근해야 함을 의미한다. 로러는 이러한 높은 수준의 협업과 정렬이 현대 기업 아키텍처의 성공에 필수적이라고 설명했다.

사이먼 로러는 완전한 제품 팀(full product team)의 본질이 단순히 기술적인 측면에만 있는 것이 아니라, '제품 소유권(product ownership)' 측면도 포함한다고 설명했다. 이는 제품 팀이 단순히 코드를 개발하는 것을 넘어, 제품의 비전, 전략, 사용자 경험, 그리고 시장 출시 후의 성공까지 전반적인 책임을 져야 함을 의미한다.

로러는 기술적 역량과 함께 비즈니스적 통찰력과 제품 관리 능력이 결합될 때 진정한 의미의 제품 팀이 형성될 수 있다고 강조했다. 이러한 접근 방식은 제품이 시장과 사용자 요구에 더 잘 부합하도록 하며, 장기적인 성공을 위한 기반을 마련한다.

사이먼 로러는 시스템의 복잡성에 지속적으로 주의를 기울여야 한다고 강조했다. 만약 그렇게 하지 않으면 엔트로피(entropy)가 시스템을 잠식할 것이라고 경고하며, 복잡성 부채(complexity debt)를 줄이기 위한 지속적인 투자가 필수적이라고 역설했다. 그는 지속적인 개선을 위해 보통 예산의 20%를 할당하는 것을 언급하며, 복잡성 관리가 일회성 작업이 아니라 상시적인 노력과 자원 배분이 필요한 영역임을 명확히 했다.

이러한 지속적인 투자는 시스템의 건강성을 유지하고, 미래의 개발 및 유지보수 비용을 절감하며, 기업의 기술적 민첩성을 확보하는 데 결정적인 역할을 한다. 로러는 복잡성 관리가 단순히 기술적 문제가 아니라, 비즈니스 연속성과 혁신을 위한 핵심적인 재정적 투자임을 시사했다.

사이먼 로러는 약 7년 전 스탠디시 리포트가 발표되었을 때, '프로젝트를 잊고 소프트웨어 개발과 구현에 집중할 때'라고 언급했던 것을 상기시켰다. 그는 기업이 소프트웨어에 비용을 지출할 것임을 이미 알고 있으므로, 더 이상 단기적인 프로젝트에 얽매이지 않고 지속 가능한 제품 중심의 사고방식으로 전환해야 한다고 주장했다.

이는 소프트웨어 개발이 일회성 이벤트가 아니라 지속적인 개선과 가치 창출의 과정이라는 인식을 강조한다. 로러는 프로젝트 중심의 사고방식에서 벗어나 제품의 전체 수명 주기를 책임지는 접근 방식이 현대 기업의 성공에 필수적이라고 역설했다.