IEEE 1471로 설계하는 소프트웨어 아키텍처 문서

아키텍처 문서를 이해관계자의 질문에 맞추는 방법

IEEE 1471은 소프트웨어 집약적 시스템의 아키텍처 설명을 위한 권장 실행 표준으로 2000년에 처음 발표됐다. 시스템 구조를 어떤 방식으로 기술할지에 대한 지침을 제공하며, 개발 과정에서 아키텍처 문서를 일관된 형태로 관리하도록 돕는다.

표준은 2000년 IEEE Computer Society에서 처음 발표된 뒤 2007년 ISO/IEC 42010으로 국제 표준화됐다. 2011년 개정을 거쳐 ISO/IEC/IEEE 42010으로 발전했으며, 현재 소프트웨어와 시스템 공학 분야에서 아키텍처 설명의 표준으로 널리 사용된다.

구조만이 아니라 설계와 진화를 지배하는 원칙

IEEE 1471에서 아키텍처는 "시스템의 기본 구조로, 구성요소와 그 관계, 환경, 그리고 시스템의 설계와 진화를 지배하는 원칙"이다. 따라서 아키텍처는 컴포넌트 배치나 기술 스택만을 의미하지 않는다. 시스템을 어떤 관점으로 이해하고 발전시킬지까지 포함한다.

이 정의를 문서화에 적용하려면 누가 시스템에 관여하는지, 각자가 무엇을 우려하는지부터 정리해야 한다.

이해관계자(Stakeholder): 시스템에 이해관계를 가진 개인, 팀, 조직 또는 기타 단체
관심사(Concern): 이해관계자가 시스템에 대해 가지는 관심 영역(성능, 보안, 확장성 등)

이해관계자와 관심사를 분명히 식별해야 아키텍처 설계가 누구의 어떤 문제를 해결하는지 드러난다.

뷰와 뷰포인트로 복잡성을 나누기

뷰(View)는 전체 아키텍처를 특정 관점에서 보여 주는 부분적 표현이다. 뷰포인트(Viewpoint)는 그러한 뷰를 만들 때 사용하는 패턴, 템플릿, 관례의 집합이다. 서로 다른 이해관계자의 관심사를 같은 방식으로 다루지 않기 위해 이 구분이 필요하다.

⤢✕

관심사가 먼저 있고, 이를 다루기 위한 뷰포인트를 선택한 뒤, 해당 방식으로 뷰를 작성한다. 이 연결이 끊기면 문서는 남지만 각 문서가 어떤 의사결정을 지원하는지는 불명확해질 수 있다.

문서에는 무엇을 남겨야 하는가

IEEE 1471에 따른 아키텍처 문서는 다음 내용을 갖춘다.

문서 식별 정보: 문서 이름, 버전, 작성자, 날짜 등
이해관계자와 관심사 식별: 시스템과 관련된 모든 이해관계자와 그들의 관심사 목록
뷰포인트 선택: 관심사를 해결하기 위한 적절한 뷰포인트 선택
뷰 개발: 각 뷰포인트에 따른 시스템 뷰 개발
일관성 평가: 다양한 뷰 간의 일관성 확인 및 충돌 해결
근거 문서화: 아키텍처 결정에 대한 이유와 대안 분석

특히 근거를 남기는 일은 설계 결과를 기록하는 것과 다르다. 왜 그 결정을 내렸는지와 어떤 대안을 검토했는지를 함께 기록해야 후속 개발자와 유지보수 팀이 설계 의도를 따라갈 수 있다.

금융 시스템과 레거시 현대화에서의 활용

대형 은행의 핵심 뱅킹 시스템 개발에서는 IT 부서, 사업부, 고객, 규제 기관, 보안 팀 등을 이해관계자로 식별할 수 있다. 이들이 요구하는 성능, 보안, 규제 준수, 확장성, 재해 복구는 서로 다른 관심사다.

이를 다루기 위해 기능 분해를 위한 논리적 뷰, 동시성과 성능을 위한 프로세스 뷰, 하드웨어 배치를 위한 물리적 뷰, 모듈 구성을 위한 개발 뷰, 데이터 보호 메커니즘을 위한 보안 뷰를 구성할 수 있다. 모든 이해관계자의 요구사항을 이처럼 문서화하면 개발 과정에서 생길 수 있는 오해와 불일치를 크게 줄일 수 있다.

레거시 시스템 현대화에서는 기존 아키텍처를 IEEE 1471 형식으로 역공학(reverse engineering)하고, 새 아키텍처 설계에도 같은 표준을 적용할 수 있다. 여러 뷰를 통해 복잡한 마이그레이션 경로를 표현하면 이해관계자 간 의사소통을 명확히 하는 데 도움이 된다.

⤢✕

문서화가 제공하는 운영상의 이점

이 프레임워크는 기술 관점에만 머물지 않고 비즈니스, 운영, 보안 관점까지 함께 다룬다. 그 결과 개발자와 비기술적 이해관계자 사이의 의사소통을 촉진하고, 각자의 요구사항이 아키텍처에 반영됐는지 확인할 수 있다.

대규모 시스템은 여러 뷰로 나누어 다루므로 특정 관심사에 집중하기 쉬워진다. 변경이 발생했을 때도 어떤 뷰와 관계에 영향이 있는지 분석하기 수월하다.

뷰포인트를 체계적으로 정의해 두면 유사 프로젝트에서 접근 방식을 재사용할 수 있다. 조직 안에서는 아키텍처 지식의 축적과 표준화가 가능해지고, 프로젝트마다 일관된 문서화 방식을 유지할 기반도 생긴다.

프로젝트 규모에 맞춰 적용하기

모든 프로젝트에 IEEE 1471의 형식을 완전하게 적용하는 것은 과도할 수 있다. 프로젝트의 규모와 복잡성에 맞춰 문서화 수준을 조정하고, 소규모 프로젝트에서는 핵심 개념만 선택적으로 적용할 수 있다.

애자일이나 데브옵스 같은 개발 방법론과 결합할 때는 문서화와 민첩성 사이의 균형이 필요하다. 점진적으로 도입해 조직 문화에 맞춰 조정하는 방식이 적합하다.

CASE 도구와 모델링 도구는 문서화 효율을 높이는 데 사용할 수 있다. 협업 플랫폼과 연계하면 실시간 업데이트와 공유가 가능하며, 아키텍처 저장소(repository)를 구축하면 뷰포인트와 패턴의 재사용도 촉진된다.

마이크로서비스와 클라우드 환경에서도 유효한 관점

IEEE 1471의 원칙은 마이크로서비스 아키텍처에도 적용된다. 관심사 중심 접근은 서비스 경계를 정의하는 데 활용할 수 있고, 서비스 간 인터페이스와 의존성은 별도 뷰로 표현할 수 있다. 배포 전략 역시 분산 시스템의 복잡성을 관리하는 하나의 관심사다.

⤢✕

클라우드 기반 시스템에서는 기존 관점에 더해 탄력성(Elasticity) 뷰, 비용 최적화 뷰, 멀티 테넌시 뷰, 보안 컴플라이언스 뷰가 필요할 수 있다. 각각 자동 확장 메커니즘, 리소스 사용 패턴과 비용 구조, 데이터 격리와 공유 메커니즘, 규제 요구사항 충족 방안을 다룬다.

문서의 형식이 목적이 되지 않도록

포괄적인 아키텍처 문서화에는 상당한 시간과 노력이 든다. 즉각적인 개발 속도와 균형을 맞추기 어렵고, 작은 조직은 리소스 제약 때문에 완전한 구현이 어려울 수 있다.

시스템이 바뀔 때마다 모든 뷰를 최신 상태로 유지하는 일도 과제다. 코드와 문서가 불일치할 수 있으므로 자동화된 문서 생성 및 검증 도구가 필요하다.

문서화 자체가 목적이 되면 실질적 가치를 잃을 위험이 있다. 실제 개발에 도움이 되는 수준을 유지하면서 "충분히 좋은(good enough)" 문서화 수준을 판단해야 한다. IEEE 1471은 완벽한 형식을 요구하는 도구라기보다, 조직 규모와 프로젝트 특성, 개발 문화에 맞춰 아키텍처 사고와 의사소통을 정돈하는 프레임워크로 활용할 때 가치를 발휘한다.