Create toss-daily-log-4.md

Author: junhyukhan

content/posts/toss-daily-log-4.md

@@ -0,0 +1,25 @@
++++
+title = 'Toss Daily Log 4'
+date = 2024-12-20T23:38:09+09:00
+draft = false
+tags = ['event']
++++
+
+## 프로젝트 구조 변화
+
+어제 살펴본 프로젝트 구조를 유지보수, 개발자 생산성, 확장성 측면에서 개선하기 위해 어떤 구조를 적용 시킬 수 있을까?
+
+현재는 ifr 모듈에서 작업을 하고 나서, jenkins에서 파이프라인을 돌린 후, 메인 애플리케이션의 파이프라인을 돌린다. 문제는 ifr을 수정하는 인원이 우리 팀 내에도 많고, 타업무에서도 각자 ifr을 돌린 후 메인 애플리케이션을 또 돌리기 때문에, 빌드 파이프라인이 불필요하게 돌아가는 경우가 많다.
+
+이는 **Build Coupling**이 높다고 표현할 수 있다. 각 Ifr 모듈의 변화를 적용하기 위해서는 모듈을 우선 빌드 한 후, 메인 애플리케이션을 (이 순서대로) 빌드 해야한다.
+변경을 할 때마다 여러 프로젝트를 다시 빌드 해야하기 때문에 이는 개발자 생산성에 큰 타격을 준다.
+
+높은 Build Coupling을 낮추기 위해서 무엇을 할 수 있을까?
+
+한가지 방법은 각 업무를 각각 standalone service으로 바꾸는 것이다. API specification만 처음에 잘 정의한다면 비교적 코드 변경이 적은 메인 애플리케이션은 다시 빌드를 안하고 각 업무 서비스만 다시 빌드하면 된다. 각 Ifr 서비스는 메인 애플리케이션에서 사용 할 수 있는 REST 엔드포인트를 노출시켜주기만 하면 된다.
+물론 이 방법은 프로젝트 구조의 복잡성과 운영 비용을 높이고 서로 네트워크를 해야하기때문에 장애 대응에도 어려움을 줄 수 있어서 현실적으로 불가능하다.
+
+
+
+
+