"로그인 기능 하나 수정했을 뿐인데요..."
단순한 로그인 UI 개선이었습니다.
버튼 색깔을 바꾸고 레이아웃을 조금 수정했을 뿐인데,
72시간 후 결제 시스템 전체가 마비됐습니다.
서비스는 3일간 중단됐고, 손실액은 50억 원을 넘었습니다.
사후 분석 결과는 충격적이었습니다.
로그인 모듈 → 세션 관리자 → 인증 서버 → 결제 보안 모듈.
이렇게 깊은 연쇄 관계를 아무도 완전히 파악하지 못했던 겁니다.
처음엔 간단해 보였던 변경이었는데,
막상 진행하니 예상치 못한 곳에서 문제가 발생했습니다.
"왜 여기까지 영향을 주지?" 하며 당황했습니다.
MIT 연구에 따르면, 소프트웨어 프로젝트 실패의 38%가 의존성 관리 실패 때문입니다.
더 놀라운 건, 개발자의 67%가 자신이 작업하는 코드의 의존성을 절반 이상 모른다는 사실입니다.
우리는 보이지 않는 거미줄 위에서 춤을 추고 있는 셈이죠.
의존성이 보이지 않는 이유
1. 암묵적 의존성의 함정
"이 버튼 색깔 바꾸는데 왜 백엔드 팀 승인이 필요하죠?"
신입 디자이너의 당연한 질문입니다. 그런데 그 버튼은 A/B 테스트 시스템과 연결되어 있고, 분석 대시보드에 영향을 주며, 머신러닝 추천 엔진의 입력값이었습니다.
코드에는 import 문으로 명시적 의존성이 보이지만, 비즈니스 로직의 의존성은 보이지 않습니다.
2. 의존성의 전이성
A가 B에 의존하고, B가 C에 의존하면, A는 C에도 의존합니다.
간단한 수학이지만, 실제 프로젝트에서는 이런 전이적 의존성이 수십 단계를 거치며 복잡하게 얽힙니다. 한 연구에 따르면, 평균적인 엔터프라이즈 시스템은 7단계 이상의 의존성 체인을 가지고 있습니다.
3. 순환 의존성의 악몽
A → B → C → A
이런 순환 구조가 생기면 어디서부터 시작해야 할지 알 수 없습니다. 하나를 수정하면 모든 것을 수정해야 하는 상황이 됩니다.
의존성을 가시화하는 방법
1. 의존성 그래프 그리기
시각화만으로도 절반은 해결됩니다. 복잡한 관계가 한눈에 들어오기 시작합니다.
2. 의존성 매트릭스 작성
| 작업 | UI | Auth | Session | API | DB | Cache |
|---|---|---|---|---|---|---|
| UI | - | ✓ | ||||
| Auth | - | ✓ | ✓ | |||
| Session | - | ✓ | ||||
| API | - | ✓ | ✓ | |||
| DB | - | |||||
| Cache | - |
체크 표시가 많은 행은 많은 것에 의존하고(취약), 체크 표시가 많은 열은 많은 것이 의존합니다(중요).
3. 크리티컬 패스 식별
의존성 체인에서 가장 긴 경로가 크리티컬 패스입니다:
로그인 → 인증 → 세션 → 권한 체크 → API 호출 → DB 조회 → 응답
(2일) (3일) (1일) (2일) (4일) (2일) (1일)
= 총 15일
이 경로의 어느 하나라도 지연되면 전체가 지연됩니다.
의존성 관리 전략
1. 의존성 역전 원칙 (DIP)
고수준 모듈이 저수준 모듈에 직접 의존하지 않도록 합니다:
# ❌ 나쁜 예: 직접 의존
class OrderService:
def __init__(self):
self.db = MySQLDatabase() # 직접 의존
# ✅ 좋은 예: 인터페이스를 통한 의존
class OrderService:
def __init__(self, db: DatabaseInterface):
self.db = db # 인터페이스에 의존
2. 의존성 주입 (DI)
의존성을 외부에서 주입받아 결합도를 낮춥니다:
// 의존성을 외부에서 주입
function createApp(database, cache, logger) {
return {
database,
cache,
logger,
// 앱 로직
};
}
// 테스트 시에는 목(Mock) 객체 주입
const testApp = createApp(mockDB, mockCache, mockLogger);
3. 레이어 분리
의존성이 한 방향으로만 흐르도록 레이어를 분리합니다:
Presentation Layer (UI)
↓
Application Layer (비즈니스 로직)
↓
Domain Layer (핵심 로직)
↓
Infrastructure Layer (DB, 외부 서비스)
상위 레이어는 하위 레이어에만 의존하고, 역방향 의존은 금지합니다.
의존성 리스크 관리
1. 영향도 분석
각 모듈의 의존성 영향도를 점수화합니다:
| 모듈 | 직접 의존 | 간접 의존 | 피의존도 | 리스크 점수 |
|---|---|---|---|---|
| 인증 | 3 | 5 | 8 | 높음(16) |
| UI | 5 | 2 | 1 | 중간(8) |
| DB | 0 | 0 | 10 | 높음(10) |
리스크 점수 = 직접 의존 + 간접 의존 + 피의존도
2. 의존성 차단점 설정
도미노 효과를 막기 위한 차단점을 설정합니다:
class CircuitBreaker:
def __init__(self, failure_threshold=5):
self.failure_count = 0
self.threshold = failure_threshold
self.is_open = False
def call(self, func, *args):
if self.is_open:
return self.fallback_response()
try:
result = func(*args)
self.failure_count = 0
return result
except Exception:
self.failure_count += 1
if self.failure_count >= self.threshold:
self.is_open = True
raise
3. 의존성 모니터링
실시간으로 의존성 상태를 모니터링합니다:
# 의존성 헬스체크 설정
healthcheck:
database:
endpoint: /health/db
timeout: 5s
interval: 30s
cache:
endpoint: /health/cache
timeout: 2s
interval: 10s
external_api:
endpoint: https://api.external.com/health
timeout: 10s
interval: 60s
실전 의존성 관리 도구
1. 코드 레벨 분석
- Madge (JavaScript): 순환 의존성 탐지
- Dependency Cruiser: 의존성 규칙 검증
- JDepend (Java): 패키지 의존성 분석
2. 아키텍처 레벨 분석
- Structure101: 아키텍처 복잡도 시각화
- Lattix: 의존성 매트릭스 관리
- SonarQube: 기술 부채 추적
3. 런타임 분석
- Jaeger: 분산 추적
- Zipkin: 서비스 간 의존성 매핑
- AppDynamics: 애플리케이션 토폴로지
의존성 리팩토링 전략
1단계: 현황 파악
모든 의존성을 문서화하고 시각화합니다.
2단계: 문제 식별
- 순환 의존성
- 과도한 의존 (Fan-out > 5)
- 과도한 피의존 (Fan-in > 7)
3단계: 점진적 개선
한 번에 모든 것을 바꾸지 말고, 가장 위험한 부분부터 하나씩 개선합니다.
4단계: 자동화
CI/CD 파이프라인에 의존성 검증을 추가합니다.
핵심 정리
"측정할 수 없으면 관리할 수 없다" - 피터 드러커
의존성도 마찬가지입니다.
보이지 않으면 관리할 수 없고, 관리하지 않으면 언젠가 폭발합니다.
작은 변경이 시스템 전체를 마비시키는 도미노 효과를 막으려면,
의존성을 가시화하고 관리해야 합니다.
복잡해 보이지만, 한 번 체계를 잡아놓으면 프로젝트의 안정성이 크게 향상됩니다.
기억하세요.
모든 것은 연결되어 있습니다.
그 연결을 이해하고 관리하는 것이 현대 소프트웨어 개발의 핵심입니다.
다음 프로젝트부터 의존성을 시각화하는 것부터 시작해보세요.
작은 노력이 큰 차이를 만듭니다.
복잡한 프로젝트 의존성을 체계적으로 관리하고 싶으신가요? Plexo를 확인해보세요.
