"이펙티브 소프트웨어 아키텍처" 리뷰

 

 

평소에 이펙티브 시리즈(이펙티브 자바, 이펙티브 코틀린, 이펙티브 소프트웨어 테스팅 ...)를 유익하게 읽었기에 해당 도서도 재밌을 것 같아서 제공받아 읽어보게 되었습니다.

지금 당장 아키텍트 레벨로 실무를 담당하지는 않지만, 결국 시간이 지나면서 큰그림(?)을 보는것이 중요하기 때문에 여러 인사이트를 얻을 것을 기대하고 있습니다.

 

해당 도서는 소프트웨어 복잡성을 관리하는 것이 아키텍처의 핵심 가치임을 강조하고 있습니다. 아키텍트는 요구사항의 변화와 기술 변동성에 유연하게 대응할 수 있어야 하며, 핵심은 결국 단순함이라고 거듭 강조하고 있습니다.

 

문서화는 필수적이며, 최신 상태를 유지하지 않더라도 없는 것보다 훨씬 낫다고 얘기합니다. 또한 정보 아키텍처와 용어집 관리로, 시간이 지나도 필요한 정보를 체계적으로 찾을 수 있도록 해야 한다고 합니다.

 

 

1장, 소프트웨어 아키텍처

아키텍처가 제공하는 가장 핵심적인 가치를 하나만 뽑자면 복잡성 관리라고 말할 수 있습니다.

복잡성은 소프트웨어의 가장 큰 적이며, 체계적인 아키텍처 설계야말로 이를 방어할 수 있는 최선의 방법이라고 할 수 있습니다.

아키텍처 vs 설계
- 복잡한 시스템에는 설계가 수백~수천 개가 있으며, 대부분 계층적으로 구성됩니다.
- 설계는 상위 설계에 부합해야 하며, 다른 요소와 조화를 이루어야 합니다. 설계는 동시에 전부 완성될 수 없으며 계속되는 지속적인 과정인 것입니다.
- 아키텍처는 지속적으로 이러한 설계를 관리합니다.

 

결국 시스템 진화를 관리할 수 있는 것이 아키텍처의 핵심적인 역할이라고 할 수 있습니다.

궁극적으로 소프트웨어 개발에서 아키텍처의 역할은 전체적인 시각에서 시스템을 의도적으로 바라보는 것입니다.

 

2장, 맥락

아키텍처 팀은 시스템이 구현할 콘셉트와 시스템에 기대되는 신뢰도, 그 외 아키텍처적으로 중요한 요구 사항을 조율해야 합니다.

콘셉트: 소프트웨어가 구현해야 하는 논리적 모델이지만, 구현하는 데 필요한 세부 사항은 포함하지 않는 개념으로 인터페이스/추상화의 느낌?

신뢰도: 사용자가 예상한 대로 제품이 동작하는지 파악하는 일련의 특성, 신뢰성, 복원력, 성능, 확장성 포함

 

3장, 변화

아키텍처 설계는 잠재적으로 나타날 수 있는 모든 시스템의 구현을 담고 있습니다.

시스템 변경이 아키텍처에 얼마나 영향을 미칠지는 어느 정도 작업을 진행한 뒤에야 알 수 있다는 것이 문제입니다.

이를 해결하려면 아키텍처와 설계의 구분보다 변경 자체를 관리하는 데 집중해야 합니다.

아키텍트는 미래에 어떤 요구 사항이 주어질 지 예측할 수 있는 감각이 있어야 하며, 이것으로 향후 변화에 대응할 수 있는 아키텍처를 만들 수 있습니다.

→ 감각이라는 것이 결국 어느정도의 경험/훈련 등이 필요한 영역이지 않을까...?

 

기술 중심의 시스템 변화는 부정적인 결과를 가져올 수 있으며, 이유는 다음과 같습니다.

• 새로운 기술은 실패할 수 있습니다. 이전 기술보다 성능/기능이 개선되지 않고 오히려 더 나빠질 수 있습니다.
• 새로운 기술이 소폭의 개선만 가져올 수 있습니다. 신규 프로젝트에는 적합할 수 있지만, 기존 시스템에서는 전환 비용을 고려한 분석이 필요합니다.

이와 달리 기술 중심의 변화가 제품 중심의 변화와 일치하지 않더라도 투자할 가치가 있는 경우도 있습니다.

• 새로운 기술은 효율성, 성능, 개발 속도, 기타 주요 지표에서 상당한 개선을 가져올 수 있습니다.
• 새로운 기술 도입은 시스템 작업에 관심 있는 인재를 모집하거나 유지하는 데 필요할 수 있습니다.
  • 동기 부여, 넓은 시장 풀, 시니어, 커뮤니티 등등

→ 매우 공감하는 부분, 새로운 기술이 당연히 완벽하지는 않더라도 기존의 문제를 해결하기 위해 나온 것이고, 적합한 환경이라면 개발자의 동기 부여 측면도 무시하지는 못할 것 같다.

 

가끔은 ‘미래를 대비한다’는 명목으로 시스템 복잡성을 높이는데, 미래에 있을 변경을 예측하고 준비하여 향후 작업 비용을 줄이겠다는 의도로 시작합니다. 하지만 문제는 미래를 정확히 예측하기가 매우 어렵다는 점이고, 예측과 다르면 복잡성만 늘어날 뿐입니다. 필자 경험에 따르면 시스템은 단순함을 유지할 때 불확실한 미래에도 잘 대비할 수 있었으며, 이것으로 이후 모든 작업을 훨씬 더 쉽게 할 수 있었습니다.

→ 이 부분도 어느정도의 경험이 있어야 판단이 가능할 것 같고, (맞아가며? 삽질하며?) 몸으로 익히는것도 어느정도 필요할 것 같다.

 

시스템을 단순하게 유지하려면 지속적으로 주의해야 하고, 이를 위해 원칙 기반으로 하여 강력한 제약을 설정할 수 있는 기본 구조가 필요하며, 모든 시스템 변경을 기본 구조에 맞추어 평가해야 합니다.

→ 원칙 기반에서 설정할 수 있는 원칙들에 대해서는 설명하고 있지 않은데, 어떤 것들이 있을까..? 가령 문서화 템플릿/코드 리뷰/테크 스펙/ 컨벤션, 1on1 등등..?

 

3.7 점진적 배포

건강한 시스템에서는 대규모 변경이 드물게 간헐적으로 발생해야 합니다. 대부분의 변경은 더 좁은 범위에서 더욱 효과적으로 빠르게 해야 하며, 점진적으로 배포하는 것이 가장 바람직합니다.

→ 모든 업무의 기본은 문제를 좁은 범위로 적절히 분리하는 데 있는 것 같다. 최근 작업에서도 기존 업무 일정이 지연되면서 추가 업무까지 함께 배포하게 되었고, 이로 인해 변경 범위가 커지면서 추가 업무에서 이슈가 발생한 케이스가 있었다. 앞으로는 항상 생각은 하지만, 더 의식적으로 문제를 작은 단위로 나누어, 효과적으로 빠르고 안정적으로 처리하는 것을 목표로 삼아야겠다.

 

4장, 프로세스

이전 시스템의 아키텍처를 이해하는 것은 해당 소프트웨어 제품을 이해하는 것만큼이나 중요합니다.

프로젝트에서는 문서화보다 동작하는 코드를 만드는 일을 훨씬 더 중요하게 생각하여, 특별한 동기나 인센티브가 없다면 시간과 비용이 발생하는 문서화 작업에 공들이지 않습니다.

현재 시스템 상태를 제대로 파악하지 않고 작업을 진행하면 두 가지 유형의 실패를 초래할 수 있습니다.

1. 제안된 변경 사항이 제대로 작동하지 않거나, 예상보다 훨씬 더 많은 비용과 노력을 투자하는 문제
2. 이러한 문제가 구현 과정에서 뒤늦게 발견되거나 시스템 장애가 발생할 때까지 명확하게 드러나지 않는 경우

→ 개인적으로는 문서가 최신화가 되어있지 않고, 잘못된 정보가 있더라도 없는것보다는 훨씬 낫다고 생각한다. 과거 굉장히 오래된 서비스를 유지보수하면서 문서가 부재한 상황에서 업무를 진행하다 보니 문서화의 중요성을 굉장히 체감하여 적극적으로 문서를 남기려고 노력하는 편이다.

 

5장, 설계

좋은 아키텍처는 제약을 부여하고 선택지를 줄임으로써 설계 효율성을 높입니다.

 

6장, 의사결정

담당 엔지니어에게 의사결정을 내리도록 위임할 수 있는 것은 여러 이점을 제공합니다. 팀 내 다른 구성원에게는 기회가 됩니다. (경험 자체에 대한 학습 기회 제공)

→ 굉장히 좋은 방법이라고 생각한다. 담당 엔지니어에게 성장/경험의 기회 제공, 리드(리더)는 위임을 통해 리소스 절약 등

 

필자 경험상 의사 결정을 명확하게 하는 데 문서화하는 것만큼 좋은 것은 없는 것 같습니다. 단순히 생각할 때는 분명해 보였던 것이 글로 옮기면서 흐트러진 적이 한두 번이 아니었습니다.

결정을 내리기 전에 문서화를 고려하면 해결해야 할 우려 사항, 질문에 답을 쉽게 찾을 수 있습니다.

• 변경 제안서, 아키텍처 명세서, 설계 문서, 비전 문서 등

의사 결정 체크 리스트

• 추가 정보는 도움이 되는가?
• 그동안 어떤 일이 일어났는가?
• 얼마나 많은 의사 결정을 하고 있는가?
• 아무것도 하지 않을 경우 비용은 얼마인가?
• 변경을 수용할 수 있는가?
• 결정을 잘못 내렸을 때 비용은 얼마인가?
• 얼마나 더 확신할 수 있는가?
• 이 결정은 내 책임인가?
• 일관성이 있는가?
• 문서화할 수 있는가?

 

8장, 커뮤니케이션

문서화는 효과적인 커뮤니케이션 기초를 마련합니다. 글로 작성하면 대화나 발표에 애매하게 전달된 부분을 좀 더 명확하게 할 수 있습니다.

과도한 커뮤니케이션은 오히려 서로를 이해하는 것을 방해할 수 있습니다. 보통 다음과 같은 상황에서 발생합니다.

• 정보가 체계적으로 정리되어 있지 않거나,
• 쉽게 찾을 수 없을 때, 용어가 일관성 있게 사용되지 않을 때,
• 최신의 정확한 정보를 과거의 정보와 구분할 수 없을 때

→ 개인 경험에 의하면 용어가 일관성 있게 사용되지 않을 때, 불필요한 커뮤니케이션 비용이 발생했던 적이 많았던 것 같다. 이를 해결하려면 동료들과 자주 Sync 를 맞추는 것도 좋은 방법일 것 같고, 용어 모음집 등의 일관성 있는 약속을 가져가는것도 괜찮을 것 같다.

 

커뮤니케이션으로 시스템 개념이 제대로 전달되었는지 확인하는 가장 효과적인 방법은 상대방이 자신이 이해한 내용을 다시 설명하게 하는 것입니다. 지속적이고 끊임없는 커뮤니케이션을 통해 공통의 이해를 만드는 것이 굉장히 중요합니다.

→ 이거, 굉장히 추천하는 방법이고 개인적으도 많이 활용(?) 하는 방법이다. 커뮤니케이션 뿐만 아니라 질문을 할 때도 스스로 정리를 하는 시간을 가지면 그 과정에서 답을 찾을 때도 있고, 서로 이해도가 동일하기에 오버 커뮤니케이션이 없어지는 점도 있다.

 

팀을 새로 구성했을 때는 대화를 하면서 팀원 간 유대감을 쌓는 데 부수적인 이득을 얻을 수 있습니다.

→ 현재 팀에서도 유대감을 쌓기 위해 3주마다 팀원들끼리 1on1을 진행하고 있는데 나름(?) 도움이 되는 것 같다.

 

대화가 어떻게 진행되든 문서로 기록한 뒤 검토 및 합의를 하기 전까지는 그 어떤 결정도 최종적인 것으로 간주해서는 안 됩니다. 회의 당시 모든 사람의 의견이 일치했다고 하여 최종 결정하면 이후 문제가 발생할 수 있습니다.

• 대화 중 의견이 합의된 것처럼 보여도 실제로는 그렇지 않을 수 있습니다.
• 대체로 어떤 결정이든 회의에 참여했던 사람들보다 더 많은 사람에게 영향을 미치게 됩니다.

→ 나의 고질적인 문제 중 하나였던 것 같은데, 회의 당시에 완벽하게 이해를 하지 못하고 넘기는 경우가 종종 있었다. 하지만 현재는 이럴 경우 회의가 끝나고 나서 대화의 연장선으로 내가 이해한 내용을 정리해서 남기기도 하고, 회의가 끝나고 추가적으로 질문을 하여 반드시 이해하고 넘기려고 하는 편이다.

 

이미 만든 산출물을 최대한 활용하고, 산출물을 제대로 정리하지 않아 발생하는 문제를 방지할 수 있게 팀 내에 정보 아키텍처를 만들고 관리해야 합니다. 정보 아키텍처란, 정보를 체계적으로 조직하여 쉽게 활용할 수 있도록 하는 것입니다. 즉 산출물을 어디에 어떻게 저장하고 정리하여 필요할 때 쉽게 찾고 사용할 수 있도록 하는 것

→ 정보 아키텍처라는 용어는 처음 들었지만, 굉장히 중요한 사항이라고 생각한다. 정보(문서화)는 시간이 지나면서 당연하게 많아질텐데, 결국 중요한 것은 많아지는 정보 속에서 필요한 정보를 쉽게 찾을 수 있는가? 이다.

 

정보 아키텍처를 구축하려면 팀에서 작성하는 문서를 분류하는 것부터 시작하면 좋습니다. (분류 카테고리?)

• 백로그 항목 (to-do 리스트)
• 명세서 (라이브러리, 서비스, 애플리케이션 등 시스템 요소에 대한 공싱적인 설명)
• 변경 제안서 (시스템 아키텍처나 설계에 대한 추가, 삭제, 변경 사항을 제안하는 문서 = 테크스펙?)
• 표준 문서 (모든 아키텍처와 설계 작업이 준수해야 하는 표준)
• 가이드 (시스템 구성 요소에 대한 개념적 설명 제공)
• 비전 문서
• 프레젠테이션 (시스템 전체, 일부 요소에 대해 실시간으로 설명하거나 논의한 내용을 기록한 문서)
• 카탈로그와 용어집
• 노트, 블로그 게시물, 추가 등등

 

가능하다면 각 자료의 사용량 통계도 수집해 보길 바랍니다. 포괄적이고 정확한 문서에는 엄청난 가치가 있습니다.

→ 이러한 생각은 못했었는데, 문서의 통계를 수집해 보는 것도 좋은 방법일 것 같다.

 

이름의 일관성과 직관성은 매우 중요하며, 이를 뒷받침할 간결하고 명료한 정의도 반드시 필요합니다.

각 용어 정의를 작성하는 데는 두 가지 목적이 있습니다.

• 용어가 모호하거나 오해가 발생했을 때 이를 해결하는 기준
• 중요한 점은 개념을 명확히 정리하도록 만드는 것

용어집은 다른 문서 안에 자연스럽게 통합될 때 가장 효과적으로 작동합니다.

→ 커뮤니케이션이 비효율적으로 발생하는 경우 중 하나가, 서로 다른 이해도를 가졌을 때가 많은 것 같다. 예를 들면 발급/발행/생성 등 동일한 개념인데 서로 다른 용어를 쓰는 경우 '저 분이 쓰는 용어가 내가 생각하는 용어와 동일한가?' 와 같은 경우... 결국 이러한 경우 공통의 Sync를 맞추기 위해 용어집을 관리하는 것이 좋은 방법일 것 같다.