아키텍처 변경의 영향을 어떻게 분석하나요?

Question

IT Interview Practice · Accepted Answer

**요구사항, 계약, 데이터, 운영 의존성**을 따라 효과를 추적해 변경을 분석합니다. 기존 요구사항과 새 요구사항의 정확한 차이부터 시작하세요. “더 큰 규모 지원”이나 “실시간으로 전환”은 안전하게 평가하기에는 너무 모호합니다.

## 의존성 그래프 따라가기

```text
[Changed requirement] --> [Affected business flow]
                                  |
                         [Interface contracts]
                           /              \
                    [Consumers]       [Data/state]
                           \              /
                       [Operations + tests]
```

추적 기록과 인터페이스 카탈로그를 출발점으로 삼고, 배포된 설정, 실제 트래픽, 시스템 소유자의 지식과 대조해 검증합니다. 문서에는 배치 작업, 내보내기, 다른 팀이 소유한 소비자가 빠질 수 있습니다.

## 예시: 더 빠른 재고 가시성

원래 합의는 시간마다 재고를 갱신하는 것이고, 제안된 요구사항은 1분 이내 가시성이라고 가정해 보세요. 장애 중에도 적용되는지, 사용자에게 필요한 것이 추정치인지 확정적인 예약인지 명확히 합니다.

ERP의 변경 게시 능력, 하위 API 할당량, 캐시 수명, 최신성 표시, 보고 가정을 살펴보세요. 소스가 시간마다 한 번만 갱신된다면 포털의 새로 고침 간격을 바꿔도 요구사항을 만족할 수 없습니다. 분석 결과 소스 기능이나 비즈니스 목표를 바꿔야 한다는 결론이 나올 수 있습니다.

## 실행 가능한 평가 만들기

- 간접 소비자를 포함해 영향받는 구성 요소와 소유자를 나열합니다.
- 호환 가능한 변경과 조율된 배포가 필요한 계약 또는 데이터 모델 변경을 분리합니다.
- 이전 부하 테스트나 복구 추정처럼 변경으로 무효가 되는 증거를 식별합니다.
- 낙관적인 추측 대신 의사결정 기준을 두고, 모르는 부분을 확인할 실험을 제안합니다.
- 새 형식으로 기록된 데이터의 처리까지 포함해 마이그레이션, 배포, 롤백 단계를 정의합니다.

롤백에는 특별한 주의가 필요합니다. 애플리케이션 코드를 되돌려도 데이터 변환이나 외부 부작용이 반드시 취소되는 것은 아닙니다. 역방향 마이그레이션이 안전하지 않다면 순방향 복구 계획과 운영 비용을 설명하세요.

## 면접 평가 요소

대안, 가정이 포함된 작업량 범위, 각 선택의 비즈니스 결과를 제시하세요. 뛰어난 아키텍트는 요청한 결과에 더 넓은 변경이 필요한 이유를 설명하고, 명시적 제한이 있는 더 작고 실현 가능한 결과를 제안할 수 있습니다.

의존성 그래프 따라가기

예시: 더 빠른 재고 가시성

실행 가능한 평가 만들기

면접 평가 요소

관련 질문