주요 콘텐츠로 건너뛰기

About architecture

문제점들

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

Bus-factor & 온보딩

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

예시:

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

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

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

예시:

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

제어되지 않는 로직 재사용

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

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

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

예시:

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

요구사항

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

note

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

명시성

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

제어

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

적응성

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

참고 자료