[Review] 소프트웨어 아키텍처 스터디 - 1주차 후기

# 아키텍처와 설계, 그 모호한 경계에 대하여

가장 먼저 논의된 주제는 아키텍처(Architecture)와 설계(Design)의 차이였습니다.


아키텍처는 한 번 결정하면 변경하기 어렵고, 최소 3~5년 정도의 긴 호흡을 바라보고 결정하는 거시적인 구조를 의미합니다. (예: 모노레포 도입 여부, 배포 플로우 등 )


설계는 컴포넌트 명명이나 함수 분리처럼 상대적으로 변경이 용이한 세부적인 작업을 뜻합니다.


하지만 실제 현업에서는 이 둘이 스펙트럼처럼 연결되어 있어 명확히 나누기 어렵다는 점에 모두가 공감했습니다. 특히 '도메인'에 대한 이해가 이 둘 사이의 간극을 메워주는 핵심 요소로 꼽혔습니다.

# 아키텍처를 구성하는 4가지 차원

# 동변성(Connascence): 변화의 전파를 관리하는 법

정적 동변성 (코드 수준에서 파악 가능)

• 
  
  • 이름(Name): 여러 컴포넌트가 엔티티의 이름에 합의해야 하는 가장 기초적인 결합입니다. 현대적인 IDE 도구로 가장 쉽게 리팩터링할 수 있어 가장 바람직한 유형으로 꼽힙니다.
    
    타입(Type): 변수 타입에 대한 합의가 필요하며, 정적 타입 언어에서는 컴파일러가 이를 잘 잡아줍니다.
    
    의미 동변성(Meaning): 특정 값의 의미에 합의해야 하는 경우로, '규약 동변성'이라고도 합니다. 상수 대신 하드코딩된 '매직 넘버'를 사용하는 것이 대표적인 사례입니다.
    
    위치 동변성(Position): 인자의 순서 등 값들의 순서에 합의해야 합니다. 예를 들어 updateSeat("14D", "Ford")에서 인자 순서가 바뀌면 타입이 같더라도 논리적 오류가 발생합니다.
    
    알고리즘(Algorithm): 여러 컴포넌트가 특정 알고리즘(예: 서버-클라이언트 간 보안 해싱)에 합의해야 하는 경우로, 정적 동변성 중 가장 강도가 높습니다.
  • 
    

동적 동변성 (런타임에 실행해봐야 파악 가능)

• 실행 순서(Execution): 여러 컴포넌트의 실행 순서가 중요한 경우입니다. 예를 들어 이메일 전송 전 반드시 발신자/수신자 속성을 먼저 설정해야 하는 규칙 등이 해당합니다.
• 
  
• 타이밍(Timing): 실행 타이밍이 결과에 영향을 미치는 경우로, 분산 시스템의 경합 조건(Race Condition)이 대표적인 예입니다.
• 
  
• 값 동변성(Values): 여러 값이 서로 의존하여 함께 변경되어야 무결성이 유지되는 관계입니다. 트랜잭션 내에서 여러 DB의 값을 일관되게 갱신해야 하는 상황을 떠올리면 쉽습니다.
• 
  
• 신원 동변성(Identity): 여러 컴포넌트가 동일한 엔티티를 참조하고 공유해야 하는 경우입니다.
  
  
  가급적 동적 동변성보다는 정적 동변성을 유지하되, 가급적 보다 덜 해로운 동변성으로 교환해나가는 것을 지향해야 합니다.
  
  
  
  

• # 응집도와 결합도 : 좋은 코드의 척도

• 
  
• 좋은 아키텍처를 판별하는 기준인 응집도와 결합도에 대해 깊이 있는 토론이 이어졌습니다.
  
  응집도(Connascence)는 기능적 응집부터 우발적 응집까지 7가지 단계를 살펴보며, 변경의 이유가 동일한 것끼리 뭉쳐야 한다는 점을 확인했습니다.
  
  
  결합도와 '주 시퀀스와의 거리': 추상도와 불안정도를 축으로 하는 그래프를 통해 '고통 영역(추상도는 낮지만 인기가 많아 고치기 힘든 코드)'과 '무용 영역'을 정의했습니다.
  
  

  

  
  
  

  

  
  
  
  참여해주신 진원님께서 "구체적일수록 나를 가져다 쓰는 애가 없어야 좋고, 추상적일수록 인기가 많아야 한다"는 직관적인 표현으로 이해를 할 수 있도록 표현하여 주셨습니다.
  
  
  

• # 실무 사례: 결제 모듈의 진화 과정

• 
  
• 참석자 진원님의 결제 모듈 리팩토링 경험은 이론이 실제에 어떻게 투영되는지 보여주는 좋은 예시였습니다.
  
  - 1차: 단순히 기능 동작에만 집중.
  
  - 2차: 동시성, 보안, 경고성(예: 외부 서버 장애 시 대응) 특성 추가.
  
  - 3차: 확장성과 테스트성을 고려하여 디자인 패턴과 추상화 적용.
  
  교훈: 처음부터 완벽한 아키텍처를 설계하기보다는, 기능을 구현하며 점진적으로 개선해 나가는 과정이 중요합니다.
  
  

• # 그 외에도...

• 
  현업에서의 설득: 아무리 논리적인 아키텍처라도 팀장이나 C-레벨을 설득하지 못하면 실행할 수 없습니다. "이 추상화가 어떻게 비즈니스적으로 돈이 되는가"를 설명하는 능력이 개발자에게도 필요합니다. 이에 관한 전략들에 대해 함께 고민해보고 공감하는 시간을 가졌습니다.
  
  명명 규칙의 인지 부하: `!isInvalid`와 같은 이중 부정문은 인지적으로 부하를 주므로 가능하면 긍정문으로 작성하는 것이 아키텍처적(변경 용이성 측면)으로 유리하다는 흥미로운 논의가 있었습니다.
  
  
  AI의 역할: 아키텍처 설계는 도메인 이해도가 필수적이기에 아직 AI가 완전히 대체하기 어려운 영역이지만, 코드 리뷰 봇 등을 통한 거버넌스 자동화에는 적극 활용될 수 있습니다. 그 외에도 현업에서의 AI 활용 팁에 대한 잡담을 나누었습니다.
  
  
  
  

• # 마치며

• 아키텍처는 정답이 없는 트레이드오프(Trade-off)의 연속입니다. 내가 무엇을 얻기 위해 무엇을 포기했는지를 명확히 인지하는 것, 그것이 아키텍트로서 성장하는 첫걸음임을 배운 시간이었습니다.
  
  
  회차에서는 2주 차 계획에 따라 또 다른 풍성한 이야기를 나눌 예정입니다!
  
  - Ch.8 컴포넌트 기반 사고
  - Ch.9 아키텍처 스타일의 기초
  - Ch.10 계층형 아키텍처 스타일
  - Ch.11 모듈형 모놀리스 아키텍처 스타일
  
  
  

  

  
  
  
  [참고자료]
  - 건축으로 이해하는 소프트웨어 아키텍처 | 설계와 아키텍처의 차이점