2019.09.03

애자일 개발 시 아키텍처 표준 문제에 대처하는 방법

Isaac Sacolick | InfoWorld
많은 애자일 리더와 팀이 애자일 개발 시 데이터와 아키텍처의 패턴과 표준을 어떻게 정의하고 준수할지 문제에 직면한다.
 
ⓒ Getty Images Bank

애자일팀은 일반적으로 2~4주 동안 지속하는 스프린트로 작업하고, 제품 소유자는 보통 우선시되는 기능을 통해 백로그를 한도 이상으로 예약하기 때문에 데이터와 기술 표준을 지키기가 쉽지 않다. 실제로 표준을 만드는 데는 상당한 시간이 필요하고 이를 준수하려면 팀이 충분한 시간을 갖고 기술적 이행을 계획해야 한다.

1회의 스프린트로 실행하고 다음 것만 계획하는 애자일팀은 표준을 이용해 개발 계획을 구성하는 데 어려움을 겪기 쉽다. 그러나 문서화된 표준을 준수하거나 이를 쉽게 참조할 수 없으면 팀의 효율성이 낮아지고 신규 개발자에게 최고의 아키텍처와 데이터 우수 사례에 대해 교육하기도 어려워진다. 마치 지도나 GPS 없이 숲속을 헤매는 것과 같다. 다음 기점에 도달할 수도 있지만 마을로 돌아가기 위한 최적의 경로를 걷고 있는지는 알 수 없다.

주의가 필요한 데이터 및 아키텍처 문제
이를 해결하는 데 있어서 데이터와 아키텍처 표준을 2개의 카테고리로 분류하는 것이 도움이 될 수 있다.

- 표준 아키텍처: 데이터 모델, 데이터 파이프라인, 마이크로서비스 아키텍처를 가능하게 하는 기술, 표준화된 CI/CD(Continuous Integration and Continuous Delivery) 파이프라인, 신규 기술 중심의 개념 증명 등이 있다. 이를 위해서는 초기 엔지니어링 작업이 필요하다.
- 표준 활동: 명명 관례, 요건 시험, 마이크로서비스 인터페이스 표준, 사용성 패턴 등을 포함한다. 이를 통해 애자일팀은 표준 기능을 이행하고 기술 부채를 해결하는 방법에 대해 배울 수 있다. 또한 데이터 모델을 확장하거나 CI/CD 파이프라인 개선을 검증하거나 새로운 마이크로서비스 종점을 문서화하는 방법을 정의하는 프로세스 표준도 포함될 수 있다.

표준을 위해 엔지니어링 작업이 필요한 경우 이를 애자일 백로그에서 EPIC, 기능, 스토리로 정의하고 적절한 팀에 할당하는 것이 가장 좋다. 이런 팀은 다른 애플리케이션 개발팀을 고객으로 여기고 작업을 중심으로 수용 기준을 정의해야 한다. 이 개발의 제품 소유자는 애자일팀이 쉽게 사용할 수 있는 구성요소를 제공하기 위해 노력하고 비즈니스 가치를 제공하는 데이터, 애플리케이션, 솔루션 설계자가 된다.

한편, 표준이 개발팀에 데이터 및 아키텍처 안내를 제공하는 경우 이런 표준은 개발자가 사용자 스토리를 구성하는 방식의 기초를 구성해야 한다. 이를 위해 팀은 이런 표준에 대한 강력한 실용적 지식과 함께 팀 리더 및 구성원이 사용할 수 있는 편리한 지식 베이스를 구축해야 한다.

애자일 개발은 지속적인 계획이 필요
많은 애자일팀이 스프린트 시작 시 계획 회의를 연다. 그들은 우선순위 사용자 스토리를 검토하고 예측하며 스프린트 중 이에 집중한다. 그러나 이런 접근방식은 팀의 우선순위가 기존의 애플리케이션을 조금 개선하는 것일 경우에 유효하다. 새로운 기능을 개발하고 데이터 및 아키텍처 표준에 맞추고 싶다면 적시 기획으로는 충분하지 않다. 팀이 스프린트가 시작되기 직전에 한 번 모여 사용자 스토리를 검토하고 이행을 표준에 맞추기에는 시간이 부족하다. 따라서 표준을 추구하는 팀은 더 일찍 계획해야 한다. 필자는 스프린트 시작 시 회의를 팀이 개발할 스토리를 최종화 하는 '약속 회의'라고 부른다. 이런 스토리의 이행을 계획할 때의 핵심은 1회 이상 계획 회의를 진행하는 것이다.

이상적인 것은 팀이 EPIC, 기능, 사용자 스토리를 지속해서 검토하는 지속적인 애자일 계획을 수립하는 것이다. 더 많은 계획 시간이 필요한 더 복잡한 작업 항목은 예약된 이행 이전에 1회 이상의 스프린트로 계획해 팀이 엄격한 개발 계획을 완수할 수 있도록 한다. 작은 항목은 이 과정을 더 빠르게 거칠 수 있다. 가장 중요한 것은 회의를 더 일찍 진행하면 팀의 시간 압박이 감소하기 때문에 이행을 계획할 충분한 시간이 있어 표준을 고려할 가능성이 높아진다는 것이다.

기준 아키텍처와 데이터 모델을 개발
애자일팀을 통합하는 방법은 기존의 상태, 단기적인 미래의 상태, 장기적인 목표를 설명하는 기준 아키텍처와 데이터 모델을 개발하는 것이다. 이 다이어그램은 개발팀을 위한 로드맵으로 작용해 이행과 아키텍처 및 데이터 표준을 일치시키는 가장 좋은 방법을 보여준다.

문서화된 기준 아키텍처는 현재 상태와 미래 상태를 구분하는 색상 코드와 기타 기호로 구성된 단일 페이지 다이어그램이다. 이를 하나의 페이지에 넣으려면 설계자가 관련된 구성요소의 범위를 정의하고 1개 이상 애플리케이션의 E2E(End to End) 서비스를 규정해야 한다. 기준 데이터 모델에는 조직에서 데이터를 사용하는 방식에 따라 여러 다이어그램이 포함될 수 있는데, 예를 들면 다음과 같다.

- 비즈니스 독립체, 관계, 필수 트랜잭션을 설명하는 개념 데이터 모델
- 데이터 레이크나 데이터 웨어하우스에 집중되고 분석, AI 실험, 데이터 시각화를 위해 사용되는 분석 모델
- 데이터 소스, 로드한 데이터에 대해 수행하는 필수 변형, 데이터가 저장되는 1차 데이터베이스를 보여주는 데이터 통합 모델
- 마이크로서비스와 기타 API가 데이터베이스와 연결되는 방식을 보여주는 서비스 모델

이런 다이어그램은 애자일팀에게 표준과 미래의 설명을 이해하는 시작점 역할을 한다. 설계자는 API 문서, 데이터 사전, 각 아키텍처 및 데이터 구성요소에 대한 전문적인 주제 목록 등 추가적인 세부사항으로 이를 보완해야 한다.

표준을 참조하는 수용 기준 작성
사용자 스토리는 요건의 정체성, 이유, 대상을 설명해야 한다. 이때 제품 소유자가 스토리 이행 방법을 문서화하지 않는 것이 좋다. 이것은 설계자, 소프트웨어 개발자, 시험자가 정의할 일이기 때문이다. 대신 팀은 책임지고 기능을 제공하고 이행이 아키텍처, 데이터, 보안, 데브옵스, 기타 표준을 충족하는 데 집중하도록 해야 한다. 단, 표준 및 기준 아키텍처를 문서화하는 것만으로는 그 준수성을 확보하기 어렵다. 팀은 코드 개발 및 릴리즈 완료의 부담이 너무 크므로 표준 검토가 항상 최우선순위가 아닐 수 있다. 설계자는 사용자 스토리 검토, 팀과의 회의를 통한 교훈 공유, 스토리에 수용 기준을 작성해 이행과 적절한 표준의 일치 등을 담당해야 한다.

또한 소프트웨어 개발 관리자는 팀이 우수 사례를 준수하고 이행이 미래의 아키텍처 및 데이터 표준과 일치하도록 팀과 수용 기준 및 표준에 관해 논의해야 한다. 대기업이라면 애자일팀이 데이터 및 아키텍처 표준에 따르도록 여러 접근방식을 고려해야 한다. 표준 정의, 스프린트 사전 계획, 아키텍처 지향적인 수용 기준 작성, 책임 정의 등이다. 이런 방식은 팀이 아키텍처와 일치하는 새로운 기능을 제공하는 방법의 하나다. ciokr@idg.co.kr


2019.09.03

애자일 개발 시 아키텍처 표준 문제에 대처하는 방법

Isaac Sacolick | InfoWorld
많은 애자일 리더와 팀이 애자일 개발 시 데이터와 아키텍처의 패턴과 표준을 어떻게 정의하고 준수할지 문제에 직면한다.
 
ⓒ Getty Images Bank

애자일팀은 일반적으로 2~4주 동안 지속하는 스프린트로 작업하고, 제품 소유자는 보통 우선시되는 기능을 통해 백로그를 한도 이상으로 예약하기 때문에 데이터와 기술 표준을 지키기가 쉽지 않다. 실제로 표준을 만드는 데는 상당한 시간이 필요하고 이를 준수하려면 팀이 충분한 시간을 갖고 기술적 이행을 계획해야 한다.

1회의 스프린트로 실행하고 다음 것만 계획하는 애자일팀은 표준을 이용해 개발 계획을 구성하는 데 어려움을 겪기 쉽다. 그러나 문서화된 표준을 준수하거나 이를 쉽게 참조할 수 없으면 팀의 효율성이 낮아지고 신규 개발자에게 최고의 아키텍처와 데이터 우수 사례에 대해 교육하기도 어려워진다. 마치 지도나 GPS 없이 숲속을 헤매는 것과 같다. 다음 기점에 도달할 수도 있지만 마을로 돌아가기 위한 최적의 경로를 걷고 있는지는 알 수 없다.

주의가 필요한 데이터 및 아키텍처 문제
이를 해결하는 데 있어서 데이터와 아키텍처 표준을 2개의 카테고리로 분류하는 것이 도움이 될 수 있다.

- 표준 아키텍처: 데이터 모델, 데이터 파이프라인, 마이크로서비스 아키텍처를 가능하게 하는 기술, 표준화된 CI/CD(Continuous Integration and Continuous Delivery) 파이프라인, 신규 기술 중심의 개념 증명 등이 있다. 이를 위해서는 초기 엔지니어링 작업이 필요하다.
- 표준 활동: 명명 관례, 요건 시험, 마이크로서비스 인터페이스 표준, 사용성 패턴 등을 포함한다. 이를 통해 애자일팀은 표준 기능을 이행하고 기술 부채를 해결하는 방법에 대해 배울 수 있다. 또한 데이터 모델을 확장하거나 CI/CD 파이프라인 개선을 검증하거나 새로운 마이크로서비스 종점을 문서화하는 방법을 정의하는 프로세스 표준도 포함될 수 있다.

표준을 위해 엔지니어링 작업이 필요한 경우 이를 애자일 백로그에서 EPIC, 기능, 스토리로 정의하고 적절한 팀에 할당하는 것이 가장 좋다. 이런 팀은 다른 애플리케이션 개발팀을 고객으로 여기고 작업을 중심으로 수용 기준을 정의해야 한다. 이 개발의 제품 소유자는 애자일팀이 쉽게 사용할 수 있는 구성요소를 제공하기 위해 노력하고 비즈니스 가치를 제공하는 데이터, 애플리케이션, 솔루션 설계자가 된다.

한편, 표준이 개발팀에 데이터 및 아키텍처 안내를 제공하는 경우 이런 표준은 개발자가 사용자 스토리를 구성하는 방식의 기초를 구성해야 한다. 이를 위해 팀은 이런 표준에 대한 강력한 실용적 지식과 함께 팀 리더 및 구성원이 사용할 수 있는 편리한 지식 베이스를 구축해야 한다.

애자일 개발은 지속적인 계획이 필요
많은 애자일팀이 스프린트 시작 시 계획 회의를 연다. 그들은 우선순위 사용자 스토리를 검토하고 예측하며 스프린트 중 이에 집중한다. 그러나 이런 접근방식은 팀의 우선순위가 기존의 애플리케이션을 조금 개선하는 것일 경우에 유효하다. 새로운 기능을 개발하고 데이터 및 아키텍처 표준에 맞추고 싶다면 적시 기획으로는 충분하지 않다. 팀이 스프린트가 시작되기 직전에 한 번 모여 사용자 스토리를 검토하고 이행을 표준에 맞추기에는 시간이 부족하다. 따라서 표준을 추구하는 팀은 더 일찍 계획해야 한다. 필자는 스프린트 시작 시 회의를 팀이 개발할 스토리를 최종화 하는 '약속 회의'라고 부른다. 이런 스토리의 이행을 계획할 때의 핵심은 1회 이상 계획 회의를 진행하는 것이다.

이상적인 것은 팀이 EPIC, 기능, 사용자 스토리를 지속해서 검토하는 지속적인 애자일 계획을 수립하는 것이다. 더 많은 계획 시간이 필요한 더 복잡한 작업 항목은 예약된 이행 이전에 1회 이상의 스프린트로 계획해 팀이 엄격한 개발 계획을 완수할 수 있도록 한다. 작은 항목은 이 과정을 더 빠르게 거칠 수 있다. 가장 중요한 것은 회의를 더 일찍 진행하면 팀의 시간 압박이 감소하기 때문에 이행을 계획할 충분한 시간이 있어 표준을 고려할 가능성이 높아진다는 것이다.

기준 아키텍처와 데이터 모델을 개발
애자일팀을 통합하는 방법은 기존의 상태, 단기적인 미래의 상태, 장기적인 목표를 설명하는 기준 아키텍처와 데이터 모델을 개발하는 것이다. 이 다이어그램은 개발팀을 위한 로드맵으로 작용해 이행과 아키텍처 및 데이터 표준을 일치시키는 가장 좋은 방법을 보여준다.

문서화된 기준 아키텍처는 현재 상태와 미래 상태를 구분하는 색상 코드와 기타 기호로 구성된 단일 페이지 다이어그램이다. 이를 하나의 페이지에 넣으려면 설계자가 관련된 구성요소의 범위를 정의하고 1개 이상 애플리케이션의 E2E(End to End) 서비스를 규정해야 한다. 기준 데이터 모델에는 조직에서 데이터를 사용하는 방식에 따라 여러 다이어그램이 포함될 수 있는데, 예를 들면 다음과 같다.

- 비즈니스 독립체, 관계, 필수 트랜잭션을 설명하는 개념 데이터 모델
- 데이터 레이크나 데이터 웨어하우스에 집중되고 분석, AI 실험, 데이터 시각화를 위해 사용되는 분석 모델
- 데이터 소스, 로드한 데이터에 대해 수행하는 필수 변형, 데이터가 저장되는 1차 데이터베이스를 보여주는 데이터 통합 모델
- 마이크로서비스와 기타 API가 데이터베이스와 연결되는 방식을 보여주는 서비스 모델

이런 다이어그램은 애자일팀에게 표준과 미래의 설명을 이해하는 시작점 역할을 한다. 설계자는 API 문서, 데이터 사전, 각 아키텍처 및 데이터 구성요소에 대한 전문적인 주제 목록 등 추가적인 세부사항으로 이를 보완해야 한다.

표준을 참조하는 수용 기준 작성
사용자 스토리는 요건의 정체성, 이유, 대상을 설명해야 한다. 이때 제품 소유자가 스토리 이행 방법을 문서화하지 않는 것이 좋다. 이것은 설계자, 소프트웨어 개발자, 시험자가 정의할 일이기 때문이다. 대신 팀은 책임지고 기능을 제공하고 이행이 아키텍처, 데이터, 보안, 데브옵스, 기타 표준을 충족하는 데 집중하도록 해야 한다. 단, 표준 및 기준 아키텍처를 문서화하는 것만으로는 그 준수성을 확보하기 어렵다. 팀은 코드 개발 및 릴리즈 완료의 부담이 너무 크므로 표준 검토가 항상 최우선순위가 아닐 수 있다. 설계자는 사용자 스토리 검토, 팀과의 회의를 통한 교훈 공유, 스토리에 수용 기준을 작성해 이행과 적절한 표준의 일치 등을 담당해야 한다.

또한 소프트웨어 개발 관리자는 팀이 우수 사례를 준수하고 이행이 미래의 아키텍처 및 데이터 표준과 일치하도록 팀과 수용 기준 및 표준에 관해 논의해야 한다. 대기업이라면 애자일팀이 데이터 및 아키텍처 표준에 따르도록 여러 접근방식을 고려해야 한다. 표준 정의, 스프린트 사전 계획, 아키텍처 지향적인 수용 기준 작성, 책임 정의 등이다. 이런 방식은 팀이 아키텍처와 일치하는 새로운 기능을 제공하는 방법의 하나다. ciokr@idg.co.kr


X