1. 배경
- 올해 내가 가장 관심 있었던 개발 관심사는 무엇이었을까.
- 최근 AI 컨텐츠가 물밀듯이 나오고 있는데, 뒤쳐지는 것은 아닌가 걱정되어 회고 해보니
- 아키텍처에 앞도적으로 많은 관심과 시간을 소비했다.
- 아키텍처에 대해 공부를 한 이유와 지난 7개월의 인사이트를 남겨본다.
빠르게 훑어 읽어본 아키텍처 서적
2. 아키텍처란?
아키텍처는 시스템의 토대이자, 팀의 나침반이며, 미래를 여는 설계 언어다.
- 무릇, 소프트웨어에는 시스템적으로 구조적인 형태가 있다.
- 이러한 구조적 형태를 아키텍처라 하며 아키텍처는 ‘어떤 품질 속성’을 목표한다.
- 품질 속성에는 성능, 테스트 가능성, 확장성, 재사용성, 유지보수성, 적응력 같은 것이 있다.
- 모든 품질을 만족하는 은총알은 없다. 상황에 맞는 trade off만이 있을 뿐이다.
- 한번 정해진 아키텍처는 프로덕트 전반의 코드 배치, 팀 협업 등 모든 개발 영역에 큰 영향을 미친다.
- 아키텍처에는 지켜야하는 제약 조건이 따른다. (ex. 계층형 아키텍처는 계층끼리 단방향 의존, 하향식 의존을 따른다, MSA에서 프론트 N개 직업 연결하지 않는다..). 제약이 지켜지지 않으면 품질 속성을 잃을 수 있다.
- 아키텍처 변경은 큰 비용이 필요하다,
잘 정돈된 아키텍처는 잘 정돈된 도로 같은 것 아닐까
클린 아키텍처(엉클밥) - 아키텍처의 의미
3. 망가진 아키텍처 (큰 진흙 공 패턴)
“레거시에도 철학이 있는데 저희 서비스는 철학이 없어요.” - 동료 개발자 김00님
망가진 아키텍처는 이런 모습 아닐까
- 내가 경험한 프로젝트도 예외가 아니다.
- 아키텍처에 제약이나, 목표하는 품질 속성이 없었고 이미 아키텍처로 부를 수 없는 상황이었다.
- 기능 개발할때 평균 1.5배-2배는 더 일하게 만들었다.
4. 왜 아키텍처가 망가질까
사실 아키텍처가 망가지는 것은 너무 쉽다.
친절하게 아키텍처 설계 의도, 철학을 공유해주는 시니어는 존재하지 않았다.
1-2년 후에 시니어는 이직하고, 혼자 남은 주니어는 이해 없이 일정에 쫒겨 기능을 찍어낸다.
몇년 지나고 보니 프로덕트는 ‘너무 급하게 만들어서’, ‘잘 모를때 만들어서’ 레거시가 되어 있다.
레거시를 만든 직원은 다른 프로젝트로 차출 되어 사라진다.
- 아키텍처가 망가지는 이유
- 지금은 이상해도 과거에는 최선의 아키텍처인 경우가 있다.
- 서비스, SW, 조직의 성장으로 특이점이 넘어 기술부채가 된 경우
- 속도가 모든 것을 이길 때
- 전략 없이 당장의 기능 출시만 이어가서 방향 설정을 하지 못한 경우
- 너무 빠른 요구사항/정책 변경
- 사람이 너무 자주 바뀌는 경우
- 처음 만든 사람이 떠난 뒤에 설계 의도 단절
- 잦은 이직
- 외주 사용 (외주는 회사의 장기 설계 계획을 알 수 없고, 관심도 없다.)
- 개발자의 경험 부족, 리소스 제한
- 팀 구성원 전체 이해도 높지 못하면 순식간에 망가진다.
- 팀의 평균 숙련도가 중요하다.
- 설계 원칙, 철학은 생략하고 “기능이 되게 하는 것”만 집중
개발자에서 아키텍트로 - 아키텍처 설계는 팀 활동이 되야한다.
5. 망가진 아키텍처를 고치는 법
- 결국 망가진 아키텍처가 가져오는 고통은 사업팀, 운영팀도 아닌 ‘개발팀’만 느낀다.
- 코드를 짜는 개발팀이 코드 방향을 결정하는 최종 권한을 가지고 있다.
- 내가 고치려고 해본 노력들을 작성해 본다.
사전조건
- 주어진 업무를 쳐내면서 팀 동료들의 충분한 신뢰를 확보한 상황
1) 공통 개념의 부재 매우기
- Object Oriented(객체지향설계), DDD(Domain Driven Design) 개념 전파하기
- 추상화, 주요 관심사, 공통의 디자인 재료가 된다.
- 코드를 작성에 옳고/그름의 기준으로 동작하는 정신 모델로 OOP와 DDD를 선택한다. (이래야 시스템 디자인 이야기를 리뷰에서 할 수 있다.)
- 객체지향, DDD 주제로 스터디를 만들어서 조용하게 스며들게 한다. (같이 스터디 하신 분들은 모르셨겠지만, 다 계획이 있었다...)
팀원 다같이 외부 세미나를 수강
2023년, 2025년 객체지향 사내스터디 주도
2) 팀이 공통적으로 가지고 있어야할 규칙을 만든다.
- 이렇게하면 이러이러해서 안좋다고 한 글이 있던데(글 첨부) 이번에 이러이러하게 해보면 어떨까요? 로 제안하듯이 코드 리뷰 형태로 스며들게 한다.
- 동의를 얻어 적용된 것은 문서로 정리해서, ‘문서로 한번 만들어 봤어요!’ 라고 말하여 코드 리뷰 규칙으로 박제한다.
규칙 예시.. 코드리뷰할때 위반 발생하면 링크 재사용
3) 제약 조건 강제화
- 경계 조건 강제화
- ArchUnit으로 의존 방향 강제화
- Spring Modulith 적용
- SonarCube, Linter 기능 사용
- 언어 접근자 활용
- feature by layer 전략으로 패키지 구성하여 코드 캡슐화
만들면서 배우는 클린 아키텍처 - ❌ 좋지 않은 패키지 구조 - 작은 프로젝트에 적합
만들면서 배우는 클린 아키텍처 - ✅ 가독성 좋은 패키지 구조
4) 벤치마킹 (다른 회사는 어떻게 접근하는지 참고)
결론
- 아마 망가진 아키텍처의 경험이 너무 좋지 못해서, 올바른 아키텍처에 대한 열망이 컸던거 같다.
- (요즘은 팀장님의 아키텍처 설계를 보며 아키텍처의 힘을 다시금 느낀다. 참 감사하다)
- 아키텍처 제약 사항을 꼭 지키자.
- 팀이 공유하는 규칙이 생기고 익숙해지는 것이 함께 성장하는 것 아닐까. (같이 지키자)
- 일터(코드베이스)가 원하는 방향으로 가고 있다는 점에서 스스로의 만족이 가장 크다.
- 계층형 아키텍처은 3계층, 4계층, 완화된 아키텍처 등 같이 변경돤 종류가 있다. (https://yeoon.tistory.com/197)