의지를 구현하는 아키텍처 모더나이제이션

※ 일본의 한 블로그 글을 번역한 포스트로 오역 및 의역, 직역이 있을 수 있습니다. 틀린 내용은 지적해주시면 감사하겠습니다.

 

 

1.  AI 시대에 엔지니어의 역할은 무엇인가

---

최근에는 AI가 코드를 작성하는 시대가 되었다.

과거 → 개발자가 코드를 직접 작성
현재 → AI가 코드를 생성

그래서 개발자의 역할은 점점 다음으로 이동하고 있다.

• 어떤 기술을 선택할 것인가
• 시스템을 어떤 구조로 설계할 것인가
• 이 시스템이 어떤 가치를 만들 것인가

즉

“코드를 작성하는 것”보다
“어떤 시스템을 만들 것인가를 결정하는 것”이 중요해진다

 

 

 

2. 레거시 시스템 문제 (Legacy System)

---

레거시 시스템(legacy system) 은 오래되어 구조가 복잡해진 시스템을 의미한다. 이러한 시스템들은 보통 다음 특징을 가진다.

특징

•  변경이 어렵다
  • 조금만 수정해도 다른 기능이 망가질 수 있음
• 개발 속도가 느리다
  • 코드가 복잡해서 수정하기 어려움
• 운영이 어렵다
  • 문제가 생기면 원인을 찾기 힘듦

이런 상태에서는 아래의 것들이 어려워진다.

• 새로운 기능 추가
• 서비스 확장
• 기술 도입

그래서 레거시 시스템의 경우 시스템을 현대화(modernization) 해야할 필요가 있다.

 

 

3. 아키텍처 모더나이제이션이란 무엇인가

---

아키텍처(Architecture) 는 시스템의 전체 구조와 설계 방식 라고 할 수 있다.

예를 들어 다음의 것들을 의미한다.

• 서비스가 어떻게 나뉘는지
• 데이터가 어떻게 흐르는지
• 시스템이 어떻게 연결되는지

 그렇다면 모더나이제이션은 무엇인가. 오래된 시스템을 현재 환경에 맞게 바꾸는 것을 의미한다. 즉, 아키텍처 모더나이제이션 = 시스템 구조를 새롭게 설계하는 것이다. 하지만 이는 단순한 기술 교체가 아니다.

예를 들어 다음과 같은 것으로 문제가 해결되지 않을 수 있다.

• 서버를 클라우드로 이동
• 프레임워크 교체
• 마이크로서비스 도입

왜냐하면 시스템 문제는 기술이 아니라 구조와 조직 문제일 수 있기 때문이다.

 

 

4. 소시오테크니컬 관점 (Socio-technical)

---

소시오테크니컬(Socio-technical) 은 “사회(조직)” + “기술”이 함께 영향을 준다는 개념으로 정리할 수 있다.

즉 아래의 것들이 모두 연결되어 있다는 것이다.

• 조직 구조
• 팀 구조
• 개발 방식
• 시스템 구조

예를 들어 팀 구조가 다음과 같은 경우

A팀
B팀
C팀

 

시스템도 보통 이런 구조가 된다.

서비스 A
서비스 B
서비스 C

 

그래서 시스템 구조는 조직 구조를 반영한다고 할 수 있으며,  이것을 흔히 Conway’s Law라고 합니다. 따라서 시스템을 바꾸려면 조직도 함께 바뀌어야 한다.

 

 

 

5. 비즈니스 이해 – Event Storming

---

아키텍처를 바꾸기 전에 먼저 해야 할 것은 비즈니스가 어떻게 동작하는지 이해하는 것이다. 여기서 사용할 수 있는 방법은 Event Storming 이다.

Event Storming

이 것은 비즈니스에서 발생하는 사건(event)을 정리하는 하나의 방법이다. 예를 들어 살펴보자. 쇼핑몰 서비스가 존재한다고 하자. 비즈니스에서 실제로 발생하는 사건을 나열하면 다음과 같다.

상품 등록됨
상품 주문됨
결제 완료됨
배송 시작됨
배송 완료됨

 

Event Storming 은 이렇게 비즈니스에서 실제로 발생하는 사건을 나열합니다.이 작업을 통해 서비스 흐름, 시스템 경계, 중요한 도메인을 발견할 수 있다.

 

 

6. 도메인 주도 설계 (DDD)

---

 Event Storming으로 이해한 비즈니스 구조를 기반으로 다음 단계에서 사용하는 방법은 DDD (Domain Driven Design) 이다. 도메인(domain) 은 서비스가 해결하려는 비즈니스 영역으로 정의할 수 있다.

 위에서 살펴보았던 예를 다시 인용하도록 하겠다.  Event Storming으로 사건을 정리한 후 필요한 기능을 정리하면 다음과 같다.

예

• 주문 관리
• 결제 시스템
• 배송 관리

DDD의 핵심은 비즈니스 구조를 중심으로 시스템을 설계한다하는 것이다. 그래서 시스템을 다음과 같이 나눌 수 있다.

주문 도메인
결제 도메인
배송 도메인

 

이렇게 비즈니스 구조를 중심으로 시스템을 설계하게 되면 시스템 이해가 쉬워지고 변경이 쉬워진다.

 

 

 

7. 팀 구조 설계 – Team Topologies

---

다음으로 중요한 것은 팀 구조이다. Team Topologies 개념에 대해서 한 마디로 설명하자면,  시스템 구조에 맞게 팀을 설계하는 방법을 의미한다. 대표적인 팀 유형은 다음과 같다.

Stream-aligned team

제품 기능을 담당하는 팀

예

• 주문 팀
• 결제 팀

Platform team

다른 팀들이 사용하는 공통 플랫폼을 만드는 팀

예

• CI/CD
• 인프라
• 클라우드 플랫폼

Enabling team

기술 지원 팀

새 기술 도입을 도와주는 역할

 

 

8. 조직과 아키텍처를 함께 설계

---

 

소프트웨어 아키텍처와 조직 구조는 함께 설계해야 한다

왜냐하면 앞서 설명해왔듯 시스템 구조, 팀 구조, 개발 프로세스가 서로 영향을 주기 때문이다. 예를 들어, 마이크로서비스를 도입했는데 팀이 하나뿐이라면 실제로는 효과가 없다. 그래서 다음과 같은 흐름으로 설계해야한다.

비즈니스 구조
↓
도메인 설계
↓
시스템 구조
↓
팀 구조

 

 

 

 

9. 아키텍처는 “의지”를 구현한다

---

 

여기서 내가 정의하는 의지(意志)는 회사나 팀이 이루고 싶은 목표이다.  예를 들어 조직이 다음과 같은 목표를 가지고 있다면, 이 목표가 아키텍처에 반영되어야한다.

• 빠르게 기능 출시
• 안정적인 서비스
• 확장 가능한 시스템

목표→ 빠른 개발
설계→ 작은 서비스 + 독립 팀
목표→ 높은 안정성
설계→ 강한 테스트 + 안정적 인프라

즉 아키텍처는 기술 선택이 아니라 조직의 전략을 구현하는 구조이다.

 

 

10. 레거시를 경쟁력으로 바꾸기

---

 레거시 시스템을 단순히 제거하는 것이 아니라 경쟁력으로 바꾸는 것이 목표이다. 방법은 지금까지 설명해왔다.

1. 비즈니스 흐름 이해 (Event Storming)

2. 도메인 설계 (DDD)

3. 팀 구조 설계 (Team Topologies)

4. 시스템 구조 재설계

이렇게 기술 + 조직 + 비즈니스를 함께 바꾸어야 레거시 프로그램이 경쟁력을 갖추게 된다.

 

 

 

11. 마무리

---

1.  AI 시대에는 아키텍처 설계가 더 중요해진다

2.  아키텍처 모더나이제이션은 기술 교체 프로젝트가 아니다

3. 시스템과 조직은 함께 설계해야 한다(소시오테크니컬 관점)

4. Event Storming / DDD / Team Topologies 같은 방법을 사용해 비즈니스와 시스템을 연결해야 한다

5. 결국 아키텍처는 조직의 의지와 전략을 구현하는 것이다.

---

참고자료

https://speakerdeck.com/nwiizo/yi-zhi-woshi-zhuang-suruakitekutiyamodanaizesiyon