◆ 기민한 설계 / 개발 프로세스
▶ 아키텍처 정의와 Micro Service 도출
● 아키텍처 정의
⊙ Micro Service 외부/내부 아키텍처를 정의하는 공정
⊙ 로버트 c. 마틴은 기술 세부사항은 늦게 결정할 수 있어야 한다고 언급한 바 있는데 이것은 기존의 워터폴한 개발 프로세스에서 강조했던 아키텍처 등의 기술 결정사항이 모두 완벽하게 정의된 후 개발을 해야 한다는 말과 배치됨
⊙ Micro Service를 순수 비즈니스 로직이 존재하는 내부 영역과 기술 영역을 표현하는 외부 영역으로 구분해서 개발하면 외부 영역은 언제든지 교체될 수 있으므로 애플리케이션의 핵심인 내부 영역에 집중하고 외부 영역 즉 아키텍처의 결정사항들은 천천히 결정해도 된다는 의미로 그만큼 애플리케이션은 소프트 즉 유연해야 한다는 말로도 읽힐 수 있음
⊙ 이러한 유연성을 항상 유지해야 한다는 점을 명심하되 최소한의 개발 및 테스트 환경을 먼저 준비하는 것은 스프린트 진행에 효과적인데 그래야만 곧바로 스프린트에서 실제로 돌아가는 애플리케이션을 시연해볼 수 있음
⊙ 최근의 클라우드 PaaS 개발 환경은 개발 환경을 어렵지 않게 빨리 구축할 수 있도록 도와주므로 언제든지 변경 가능하도록 구성하되 구현 기반은 빨리 마련
⊙ 외부 아키텍처로 도커, 쿠버네티스, 스프링 부트 기반과 같이 Micro Service 개발 환경을 미리 결정해 둔다면 빠르게 개발 환경을 구축하고 곧바로 개발 과정으로 진입할 수 있는데 물론 이렇게 정의된 아키텍처는 스프린트 과정을 통해 개선되고, 지속적으로 정제될 것인데 아키텍처나 애플리케이션 구조가 유 연하다면 언제든지 세부사항은 변경될 수 있기 때문
● Micro Service 도출
⊙ 본격적인 Micro Service 개발로 들어가기 위한 스크럼 팀이 개발할 전체 Micro Service들을 파악하는 작업
⊙ 모든 Micro Service를 하나의 스크럼 팀이 개발할 수 없으므로 DDD의 전략적 설계 기법을 활용해 Micro Service를 도출하고 그것들 간의 대략적인 매핑 관계를 정의한 후 Micro Service 개발 우선순위에 근거해 스크럼 팀에 배분해서 스프린트를 진행
⊙ 최종 결과물은 컨텍스트 맵으로 컨텍스트 맵은 식별된 Micro Service 와 그것들 간의 의존관계를 보여줌
▶ 스프린트 내 개발 공정
● Back End 설계 및 개발
⊙ 벡엔드 설계의 시작은 API 설계로 Back End Micro Service가 Front End에 제공할 서비스 명세로 초기에 API 설계를 진행해 Front End 영역과 협의 및 조정해야 하는데 그래야만 Front End 영역도 이를 기반으로 Front End 자체의 설계를 진행할 수 있음
⊙ 다음으로 진행할 Back End 영역의 설계는 정의된 Micro Service 내부 구조에 따라 도메인 모델 과 데이터 모델 을 설계하는 것
⊙ 도메인 모델을 작성하는 활동을 도메인 모델링이라 하는데 이전의 OOAD(Object Oriented Analysis Design) 방식과 다른 점은 OOAD에서는 UML 등을 활용해 설계 모델을 작성하고 이를 소스코드로 변환하는 작업 등을 진행했으나 DDD를 적용하면 별도의 정형화된 모델을 만들지 않고 간략히 도메인 모델 등을 화이트보드나 포스트잇 등의 단순한 도구로 작성해서 공유 한 후 곧바로 소스코드로 도메인 모델을 개발한다는 것
⊙ 예전의 설계 모델의 개념은 MDD(Model Driven Development)의 사례 와 같이 추상적인 모델을 완벽히 만들어 놓고 특정 기술 프로파일이나 프레임워크를 적용해 구체적인 코드를 생성해서 모델과 코드가 단절되는 구조였다면 DDD의 모델링은 자체가 모델의 기본 표현 형식을 그대로 반영해서 코드로 표현되고 개발자는 개발 중에 초기에 설계한 개념대로 개발되고 있는지 확인하기 위해 또는 다른 개발자에게 핵심 도메인 모델을 이해시키기 위해 역공학 도구를 이용해 UML 모델로 역공학해서 볼 수 있기 때문에 DDD의 모델은 코드와 함께 항상 살아 숨쉬게 됨
⊙ MDD 와 DDD
● 프런트엔트 영역 설계 및 개발
⊙ Front End 영역 설계는 UI 레이아웃을 정의하고 Back End의 API를 호출해서 API가 보내준 데이터를 기반으로 이에 어떻게 표현할 것인가를 정의하는 활동
⊙ 사용자가 접근하는 채널에 따라 모바일 앱, 웹 등의 레이아웃 정의가 다양할 수 있고 프런트 아키텍처에 따라 설계 수준 및 방식이 모두 다를 수 있음
⊙ Front End 영역 설계와 개발의 기본적인 활동
→ UI 흐름 정의: 비즈니스 흐름에 따른 UI 흐름을 정의하는데 UI 흐름을 설계한 산출물을 UI 스토리보드 라고도 함
→ UI 레이아웃 정의: 사용자 접점인 사용자 인터페이스를 정의하는 활동으로 디자인을 고려하지 않은 사용자 경험을 고려해서 설계하는데 파워포인트로 작성할 수도 있고 최근에는 발사믹 목업 이나 카카오 오븐 등의 여러 유용한 도구가 많이 사용됨
→ UI 이벤트 및 액션 정의: UI 레이아웃의 구성요소인 컨트롤을 클릭하거나 터치 등의 행위를 했을 때 발생하는 이벤트 및 액션을 정의하는 활동으로 미리 정의된 Back End API 와의 연계를 정의할 수도 있음
→ UI 개발: UI 레이아웃 및 이벤트의 의도에 맞춰 Front End 애플리케이션을 개발하는 활동으로 보통 Front End 아키텍처에서 정의한 UI 프레임워크나 도구를 사용할 수 있음
● 빌드 및 배포
⊙ 기민한 개발을 위해서는 벡엔드와 Front End 개발이 진행되는 과정에서 지속적으로 빌드되고 자동으로 배포되도록 빌드 및 배포 환경을 자동화해야 하는데 스크럼 팀의 구성원은 언제라도 현재 진행된 만큼의 실제로 돌아가는 소프트웨어를 확인할 수 있어야 하는데 데브옵스 인프라 환경이 이를 지원하고 Back End 및 Front End 개발자는 매일 통합 빌드되고 배포되는 개발환경에 익숙해져야 함
⊙ 빌드가 안되거나 배포가 안되는 상황을 방치해서는 안됨
⊙ 아키텍처를 정의할 때 빌드 및 배포 파이프라인이 구성된 상태에서 개발자 입장에서 수행해야 할 빌드 및 배포를 위한 활동
→ 소스코드 리포지토리 구성: Front End, Back End 코드를 위한 소스코드 리포지토리를 구성하는데 SVN, Git, GitHub 등을 이용할 수 있음
→ 통합 빌드 잡(Build Job) 구성: 리포지토리에 존재하는 소스코드를 통합한 후 컴파일 및 테스트해서 바이너리를 만드는 활동을 자동화하는데 어떤 통합 빌드 도구를 선택하느냐에 따라 다양한 방식이 있는데 쉽게 적용할 수 있는 통합 빌드 및 배포 도구로 젠킨스가 있음
→ 컨테이너 생성 파일 작성: 배포 환경을 컨테이너 환경으로 구성할 경우 운영체제와 WAS와 빌드된 애플리케이션을 묶어서 컨테이너 이미지를 생성하는 스크립트를 작성할 수 있는데 도커 컨테이너인 경우 Dockerfile로 작성
→ 배포 스크립트 작성: 자동으로 배포하는 스크립트를 작성하는 활동으로 배포 타깃(Target)에 맞춰 스크립트를 작성하는데 젠킨스에도 배포 기능이 있으며 온프레미스 및 클라우드 서비스 등 어떤 환경이라도 대부분 자동화해서 배포할 수 있음
댓글