주요 콘텐츠로 건너뛰기

About architecture

문제점들​

일반적으로 아키텍처 논의는 프로젝트가 커지고 개발 생산성이 크게 저하되거나 진행이 지연될 때 제기됩니다.

Bus-factor & 온보딩​

프로젝트 구조와 아키텍처를 일부 기존 팀원들만 이해하고 있습니다.

예시:

  • 신규 팀원이 독립적으로 업무를 하기까지 시간이 오래 걸립니다
  • 아키텍처 설계 원칙이 없어, 개발자마다 다른 방식으로 문제를 해결합니다
  • 거대한 모놀리스에서 데이터와 흐름을 추적하기 어렵습니다

암묵적인 부작용과 예측 불가능한 영향​

개발이나 리팩터링 과정에서 작은 변경이 전체에 영향을 주는 부작용이 자주 발생합니다.
(모듈 간 의존성이 얽혀 있어, 한 부분을 수정하면 다른 부분이 함께 깨질 수 있습니다.)

예시:

  • 기능 간 불필요한 의존성이 생깁니다
  • 한 페이지의 상태(store) 변경이 다른 페이지 동작에 예기치 않은 영향을 줍니다
  • 비즈니스 로직이 여러 곳에 흩어져 있어 흐름을 추적하기 어렵습니다

제어되지 않는 로직 재사용​

기존 로직을 재사용하거나 수정하기 어렵습니다.

보통 두 가지 대표적인 문제 상황이 나타납니다:

  • 재사용할 수 있는 코드가 있음에도 각 모듈을 매번 처음부터 새로 구현합니다.
  • 반대로, 거의 한 곳에서만 쓰이는 코드까지 무분별하게 shared 폴더에 옮겨져, 사실상 쓸모없는 공용 모듈이 쌓입니다.

예시:

  • 같은 계산, 검증 로직이 여러 군데에서 반복 구현되어, 수정할 때 모든 위치를 일일이 고쳐야 합니다
  • 동일한 버튼이나 팝업 컴포넌트가 스타일, 동작만 조금 다른 여러 버전으로 중복 존재합니다
  • 유틸 함수들이 규칙 없이 계속 쌓여, 어떤 함수가 있는지 찾기 어렵고 중복도 많습니다

요구사항​

이상적인 아키텍처를 위한 핵심 요구사항은 다음과 같습니다.

note

여기서 "쉽다"라는 표현은 "대다수의 개발자들이 합리적인 시간 내에 이해하고 적용할 수 있다"는 의미입니다.
모든 상황에 완벽히 맞는 아키텍처는 없기 때문에, 실용적인 합의가 중요합니다.

명시성​

  • 프로젝트 구조와 아키텍처를 누구나 쉽게 이해하고 설명할 수 있어야 합니다.
  • 아키텍처는 프로젝트의 비즈니스 도메인과 가치를 반영해야 합니다.
  • 계층 간 의존 관계와 영향 범위가 명확해야 합니다.
  • 중복된 로직을 쉽게 식별할 수 있어야 합니다.
  • 핵심 로직이 프로젝트 전반에 분산되지 않도록 관리해야 합니다.
  • 불필요한 추상화나 복잡한 규칙은 최소화해야 합니다.

제어​

  • 새로운 기능을 빠르게 개발하고, 문제를 쉽게 해결할 수 있어야 합니다.
  • 프로젝트의 전반적인 개발 흐름을 체계적으로 관리할 수 있어야 합니다.
  • 코드의 확장성, 유지보수성, 제거 용이성이 보장되어야 합니다.
  • 기능 단위로 명확한 경계와 격리가 필요합니다.
  • 컴포넌트는 쉽게 교체, 삭제할 수 있어야 합니다.

적응성​

  • 다양한 규모와 성격의 프로젝트에 적용 가능해야 합니다.
    • 기존 시스템 및 인프라와 무리 없이 통합될 수 있어야 합니다.
    • 프로젝트 전 주기(초기, 운영, 확장)에서 일관되게 적용 가능해야 합니다.
  • 특정 기술 스택이나 플랫폼에 종속되지 않아야 합니다.
  • 병렬 개발과 팀 확장이 원활해야 합니다.
  • 비즈니스 요구사항과 기술 환경 변화에 유연하게 대응할 수 있어야 합니다.

참고 자료​