이해관계자와 Concern

학습 목표

소프트웨어 아키텍처의 이해관계자(stakeholder) 를 식별할 수 있다.

Concern(관심사)과 quality attribute의 관계를 설명할 수 있다.

이해관계자마다 다른 관점이 나오는 이유를 설명할 수 있다.

concern을 분리하고 충돌을 조율하는 것이 아키텍트 역할임을 설명할 수 있다.

문제 상황

• PM은 "이번 분기 출시", 개발은 "기술 부채 상환", 운영은 "장애 없이"
  • 회의마다 우선순위가 달라 결론이 안 난다
• "마이크로서비스로 가자" vs "모놀리스로 빠르게"
  • 누구의 concern을 반영한 제안인지 불분명하다
• 보안팀은 모든 API에 mTLS, 제품은 온보딩 마찰 최소화
  • 둘 다 맞는 말인데 구조에서 어떻게 맞출지 모른다

아키텍처 정의와 트레이드오프를 봤다. 이번 편은 누가 무엇을 걱정하는지를 구조 결정의 입력으로 본다.

1. 이해관계자란

시스템의 성공·실패에 이해관계가 있는 사람·조직이다. 코드만 보고 아키텍처를 짜면 나중에 반려된다.

이해관계자	대표 concern
비즈니스 / 제품	출시 속도, 시장 적합성, 비용, 규제 준수
개발 / 엔지니어링	변경 용이성, 테스트, 생산성, 기술 스택
운영 / SRE	가용성, 복구 시간, 관측성, 용량
보안 / 컴플라이언스	기밀성, 접근 통제, 감사, 데이터 거주
최종 사용자	응답 속도, 신뢰성, UX
데이터 / 플랫폼	일관성, 파이프라인, 거버넌스

• 한 사람이 여러 역할을 할 수 있다
• 아키텍트는 특정 팀 대변인이 아니라 concern을 균형 짓는 역할에 가깝다

2. Concern과 품질 속성

Concern — "우리는 X가 걱정된다" (출시 일정, 99.9% 가용성, GDPR)

Quality attribute (아키텍처 특성) — concern을 측정·설계 가능한 형태로 만든 것

Concern (말)	Quality attribute (설계)
"느리다"	latency p99, throughput
"자주 죽는다"	availability, MTTR
"바꾸기 힘들다"	modifiability, coupling
"해킹당할 것 같다"	confidentiality, integrity

• 아키텍처 결정은 모호한 요구가 아니라 측정 가능한 품질 목표로 번역될 때 논의가 진행된다
• 모든 품질을 동시에 극대화할 수 없다 → 트레이드오프

3. 관점(Perspective)이 다른 이유

같은 시스템을 보면서 보는 단위가 다르다.

• 비즈니스 — 기능 단위, 매출·리스크
• 개발 — 모듈·API·배포 단위
• 운영 — 서비스·인스턴스·알람·런북

예: 결제 지연 1초

• 제품: 전환율 하락
• 개발: DB 쿼리·동기 호출 체인
• 운영: DB CPU, connection pool, 캐시 hit rate
• 아키텍처 문서는 한 관점만 쓰면 다른 이해관계자가 읽지 않는다
• 뷰(view) — 4+1, C4 등은 관점별 표현을 위한 도구 (이후 편에서 확장)

4. Concern 분리

한 컴포넌트·한 팀이 모든 concern을 떠안으면 결합도가 폭발한다.

• 관심사 분리(Separation of Concerns)
  • 인증 vs 주문 vs 결제 vs 알림을 경계로 나눔
  • 레이어드 아키텍처, 헥사고날, MSA는 concern 분리의 다른 형태
• 단일 책임은 클래스 수준이, concern 분리는 시스템 수준에 가깝다

잘못된 신호	분리 필요
결제 로직에 이메일 발송·로그 포맷이 섞임	도메인 vs 인프라
한 DB에 모든 서비스가 직접 쓰기	데이터 소유권
배포 한 번에 전체 모놀리스	배포 단위 concern

5. 충돌과 조율

이해관계자 concern은 충돌한다. 그게 정상이다.

충돌	한쪽	다른 쪽	아키텍처 응답 예
속도 vs 안정	빠른 출시	철저한 테스트	점진적 배포, feature flag
보안 vs UX	강한 인증	낮은 마찰	OAuth + PKCE, 단계적 인증
일관성 vs 가용성	강한 트랜잭션	분산 가용	saga, eventual consistency
비용 vs 성능	작은 인스턴스	낮은 지연	캐시, autoscaling 정책

• 아키텍트는 승자를 정하는 게 아니라 명시적 트레이드오프를 기록한다
  • ADR(Architecture Decision Record): 맥락, 결정, 대안, 결과
• "모두 만족"은 없다. 누가 무엇을 얼마나 포기하는지 합의한다

6. 정리

• 아키텍처는 기술만이 아니라 이해관계자 concern의 균형이다
• concern → 품질 속성으로 번역해야 설계·측정이 가능하다
• 관점이 다르면 같은 버그도 다른 이름으로 불린다
• 분리·조율이 아키텍트의 일상이다

다음에 다룰 것

• 아키텍처 품질 속성
• 성능, 가용성, 확장성, 보안, 유지보수성, 테스트 용이성

---

해당 내용은 Fundamentals of Software Architecture (Mark Richards, Neal Ford) 및 Software Architecture in Practice, 4/E (Bass, Clements, Kazman) 의 내용을 기반으로 합니다.