이론보다는 실질적인 사례를 살짝 들여다보면서 소프트웨어 아키텍처가 무엇인지 함께 살펴보겠습니다! 이 블로그는 연재 성격으로 계속 추가될 예정이며, 다양한 형태의 소프트웨어 아키텍처 뿐만 아니라, LLM(Large-Language Model)을 포함한 인공지능 아키텍처(AI Architecture), 전통적인 의도적 아키텍처(Intentional Architecture)와 대비되는 애자일 아키텍처(Agile Architecture) 등 변화하는 디지털 시대(Digital Age)의 소프트웨어 아키텍처 진화를 포괄해서 살펴볼 것입니다.
많은 사람들이 알고 있는 이야기부터 시작해보겠습니다.
아마존(Amazon)은 많은 사람들이 알고 있는 기업 중 하나입니다. 사람에 따라 아마존을 온라인 서점으로 알고 있거나, 클라우드 서비스(Cloud Service)의 리딩 기업으로 알 수도 있고, 전세계에 걸쳐 다양한 사업에 관심을 가지고 있는 글로벌 문어발 기업으로 느끼는 사람도 있을 것입니다.
어쨌든 아마존은 1994년에 인터넷에서 책을 파는 아이디어로 제프 베조스(Jeff Bezos)가 워싱턴에서 설립한 회사로, 전자상거래 서비스를 세상에 빠르게 내놓은 기업 중 하나입니다.
아마존은 1990년대의 늘어나는 물류 수요 대응을 위해 SOA(Service Oriented Architecture)를 기반으로 비즈니스 변화에 따른 대응 프로세스 체계를 지속적으로 개선시켜왔습니다. 이 후 아마존은 기존 SOA 체계를 더욱 작고(Micro) 민첩한 형태로 만들어 크거나 작은 시장 또는 조직의 전략적 변화에 전체 시스템이 빠르게 적응할 수 있도록 각 서비스 별 독립적인 대응체계를 구축할 수 있도록 진화시켰습니다. 이를 MSA(Micro-Service Architecture)라 부르며, 그 변화 대응 체계가 이제는 아마존만이 아닌 전세계의 소프트웨어 아키텍처를 변화시키고 있습니다.
마이크로서비스 아키텍처는 기존의 다양한 마이크로 서비스를 오케스트레이션(Orchestration)하여 빠르게 새로운 서비스를 시장에 출시하는데 도움을 줍니다. 이때 그림 1에서 보는 것처럼 각각의 마이크로서비스는 파편화되어 있으며 서비스별로 독자적인 저장공간(Repository)를 갖고 있습니다. 통합된 R-DB를 기반으로 한 비즈니스 서비스 형태를 가진 우리나라의 많은 정보 시스템들과는 근본적으로 다른 아키텍처입니다.
MSA와 같은 소프트웨어 아키텍처에는 EDA(Event-Driven Architecture), Orchestration, Choreography, CQRS(Command and Query Responsibility Segregation), Architecture Pattern과 같은 아키텍처 관련 용어나, DDD(Domain-Driven Design), Event-Storming, Emergent Design과 같은 설계 관련 용어, Refactoring 등과 같은 소스코드 구조화, Load Balance, API Gateway, Security 등 효율적 운영을 위한 다양한 개념들이 존재합니다.
다만, 너무 많은 것을 다루어 지루한 글을 만드는 것보다는, 이번 첫 연재에서는 소프트웨어 아키텍처에 관련된 핵심만을 일부 제시하면서, 중요한 의미를 살짝 소개하고, 향후 연재를 시작하기 위한 출발점 수준으로 제한 시키고자 합니다.
잠시 눈을 병원 산업(Healthcare Industry)쪽으로 돌려, 실제 사례를 살펴보겠습니다.
현대인들이라면 대부분 크거나 작은 병원에 방문해본 경험을 갖고 있을 것입니다. 병이 없어도 코로나19 백신을 맞으려 병원에 가거나, 검진을 위해 병원에 방문할 수도 있습니다. 우리나라에도 많은 병원이 있고, 혜화동에 있는 서울대학교 병원이나, 분당에 소재한 분당서울대학교 병원을 방문해본 사람도 있을 것입니다. 이들 병원에는 병원정보시스템(HIS: Healthcare Information System)이 있어 의사의 진료, 의무 기록, 원무 등 다양한 의료 관련 활동에 대한 서비스를 제공합니다.
필자는 많은 프로젝트에 참여해왔고, 그 중에는 의료 프레임워크를 만드는 프로젝트에서 총괄PM 및 아키텍트(Chief Architect) 역할을 수행한 경험도 있습니다. 이 프로젝트의 결과로 만든 HSF(Healthcare Software Framework)는 이후 분당서울대학교 병원의 차세대, 서울대학교 본원의 차세대 구축 등에 활용되었고 이후 몇 개국에 수출되었습니다. 그 프레임워크의 내부를 살짝 들여다보겠습니다.
그림 2는 지식경제부로부터 지원금(120억)을 받기 위해 제안 팀을 꾸려 HSF라는 프레임워크를 제안할 당시, 그렸던 그림입니다. 한 달이 넘게 걸린 제안 작업 후, 직접 제안 발표를 했고, 수주했습니다. 그림의 가장 상위에는 다양한 사용자들이 보면서 사용할 수 있는 애플리케이션 레이어, 두번째는 의료 분야의 다양한 서비스들을 포함하는 레이어, 세번째는 데이터 처리/관리, 소프트웨어 개발 및 운영에 필요한 기술 레이어가 있으며, 제안의 범위는 서비스 레이어와 기술 레이어였습니다. 이후 각 병원들은 이 프레임워크를 사용해서, 병원 시스템에 관계된 다양한 사용자 요구에 맞춘 애플리케이션들을 만들고 병원 내부 정보 시스템 환경과 통합하여 차세대 시스템을 빠르게 구축할 수 있었습니다.
이때 서비스 레이어에 들어갈 서비스는 국내의 7개 병원으로부터 공통적인 의료 서비스를 식별하여 정의하였고, 모든 서비스들을 SOA에 기반을 두고 설계하고 구현 및 검증하였습니다.
그림 3을 보면, 유스케이스 정제를 기반으로 서비스를 도출한 것으로 보입니다. 하지만, 이보다 더 중요한 과정은 겉으로 잘 드러나 있지 않습니다. 그림의 중간을 보면 기능과 데이터의 상호교류 분석 과정이 나오는데, 이때 병행했던 것이 다양한 병원 내 사용자들이 사용하는 클라이언트(Client)에서 전산실 및 연계된 시스템을 구성하는 서버(Server)로의 모든 트랜잭션(Transaction)을 분석하는 것이었습니다. 트랜잭션들을 처리하거나 처리된 후의 상황에서, 어떤 기능이 어떤 데이터와 함께 활용되는지에 대한 정보는 보다 유연한 시스템을 만들기 위한, 즉 느슨하게 결합된(Loosely Coupled) 시스템을 만드는데 가장 중요한 요인이었다고 생각합니다.
MSA와 같은 좋은 아키텍처를 만들어가고 싶은 사람이라면, 기술도 중요하겠지만, 트랜잭션에 좀 더 많은 관심을 갖고, 비즈니스 관점에서 어떤 서비스들이 어떤 데이터들과 활용이 되는지, 트랜잭션 관점에서 서비스들을 어떻게 구분하고 독립적으로 개발 및 운영할 수 있는지 등에 대한 많은 관심을 가질 필요가 있습니다.
기술 레이어에는 서비스들을 관리하는 SOA 프레임워크 뿐만 아니라, 개발/실행/운영 관련 다양한 서비스, 병원 애플리케이션을 만들 때 쓰기 위한 다양한 UI Control들과 UI를 생성할 수 있는 서식 생성기, 보안과 관련된 다양한 서비스도 포함되어 있습니다.
특히, 소프트웨어 개발 과정에서는 생산성과 효율적 품질 관리는 매우 중요하기 때문에, 기술 레이어에는 코드 생성과 같은 개발자 생산성을 위한 기능들과 오류 재현 등 검증 및 개선에 관한 여러 기능들을 포함시켰습니다.
아키텍처 요구사항에는 일반적으로 성능, 보안, 안정성 등 다양한 품질 속성(Quality Attribute)가 존재합니다. 특히 클라우드 네이티브가 중요해지면서 통합용이성(Integrity)과 배포용이성(Deployability)과 같은 새로운 품질 속성들도 등장하고 있는 상황입니다.
이 당시 만들었던 헬스케어 프레임워크도 다양한 품질 속성들을 관리했고, 특히 수출을 위한 차별적 품질 속성으로 사용자 친화적인 특성을 선정하였습니다. 사용성을 프레임워크에 내재화 시키기 위해 그 당시 서울대학교 융복합대학원의 UX Lab을 맡고 있는 이중식 교수님을 직접 찾아가 부탁을 했고, 박사 및 대학원 과정 여러 인력이 1년간 프레임워크에 UX 관련 특성을 반영하였습니다.
분당서울대병원 34개과를 포함한 병원 전체 프로세스 및 다양한 사용자를 분석하는 과정에서 8개의 페르소나(Persona)를 정의했고, 제품이 지향하는 UX 개념과 개념을 실현시키기 위한 UX 시나리오, 다양한 화면 프로토타입 개발과 피드백, 탭(Tab)과 다양한 크기의 모니터 조합 등에 대한 분석 과정을 거쳐 선정된 결과들을 프레임워크에 반영하였습니다.
그림 6을 보면 소프트웨어 아키텍처가 왜 중요한지를 간단히 느껴볼 수 있습니다. 소프트웨어 아키텍처는 앞에서 언급한 비즈니스 관점의 의료 서비스 레이어를 만들고, 품질과 생산성을 제공하기 위한 기술 레이어를 만드는 복잡한 과정을 효율적으로 통합하고 있습니다. 즉, 기술 아키텍처(Technical Architecture), 데이터 아키텍처(Data Architecture), 비즈니스 서비스(Business Service), UI 컨트롤 등 다양한 서비스 및 아키텍처, 그리고 기술적 요소들을 통합하는 역할을 하고 있습니다.
이처럼 소프트웨어 아키텍처는 복잡한 비즈니스 및 기술적인 요건들을 효율적으로 개발 및 통합하고, 사용자들이 편하게 쓸 수 있는 시스템을 만들어줄 뿐만 아니라, 향후 안정적으로 운영할 수 있는 진화 가능한 시스템이 되는 기반을 만들어 주는 역할을 합니다.
최대한 이론을 배제하고, 사례를 통해 아주 간단하나마 소프트웨어 아키텍처에 대한 느낌을 전달해보았습니다. 향후에도, 사례를 포함한 소프트웨어 아키텍처에 관한 다양한 이야기를 공유할까 합니다. 이것으로 첫 블로그를 마치겠습니다.
