소프트웨어 아키텍처 101 - CHAPTER 2 아키텍처 사고

• 아키텍처 사고(architectural thinking): 아키텍처적인 눈으로, 즉 아키텍처 관점에서 사물을 바라보는 것
• 아키텍트의 사고 방식
  • 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하려면 개발팀과 어떻게 협력해야 할 지 아는 것.
  • 어느 정도 기술 깊이를 유지하면서 폭 넓은 기술 지식을 확보하는 것.
  • 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고, 조율하는 것.
  • 비즈니스 동인(business driver)의 중요성을 이해하고 그것을 아키텍처 관심사로 해석할 줄 아는 것

2.1 아키텍처 대 설계

아키텍트처럼 사고한다는 건 비즈니스와 기술 문제를 해결하기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 긴밀하게 통합한 솔루션을 모색하는 것.

제대로 된 아키텍처를 만들려면 반드시 아키텍트와 개발자를 가르는 가상의 물리적 장벽을 허물고 두 팀이 양방향으로 소통하는 관계를 정립해야 합니다. 아키텍트, 개발자 모두 활발히 소통하면서 아키텍트는 팀 내 개발자를 멘토링/코치하는 역할도 수행할 수 있도록 가상의 동일한 팀에 소속되어 있어야 합니다(그림 2-3).

소프트웨어 프로젝트를 성공으로 이끌려면 아키텍트와 개발팀이 똘똘 뭉쳐야 합니다. 아키텍처, 설계 모두 소프트웨어 프로젝트 생명 주기의 일부로서 항상 서로 동기화되어야 성공할 수 있습니다.

2.2 기술 폭

• 내가 알고 있는 것: 전문 기술자가 일상 업무 수행에 사용하는 기술, 프레임워크, 언어, 도구
• 내가 모른다는 사실을 아는 것: 전에 한 번 들어봤거나 얕은 지식은 갖고 있지만 실무 경험은 거의 전무한 기술
• 내가 모른다는 사실조차 모르는 것: 기술자가 해결하려는 문제에 완벽한 정답임에도 불구하고 그 존재조차 알지 못하는, 절대 다수의 기술, 도구, 프레임워크, 언어

아키텍트의 가치는 대부분 기술에 대한 폭넓은 이해와 그 기술을 사용해서 특정한 문제를 해결하는 것입니다. 즉, 아키텍트는 어느 한 가지 문제만 해결 가능한 한 가지 전문 지식보다는, 문제를 해결할 수 있는 다섯가지 솔루션을 알고 있는 게 더 중요합니다.

아키텍트에게는 깊이보다 폭이 더 중요합니다. 아키텍트는 기술적인 제약 하에 어떤 기능이 가장 알맞는지 결정해야 하므로 아주 폭넓은 솔루션을 두루 꿰고 있어야 합니다. 따라서 아키텍트는 어렵게 얻은 기술을 일부 희생하더라도 자신의 포트폴리오를 넓히는 데 시간을 투자하는 게 더 현명합니다.

개발자에서 아키텍트로 자리를 옮긴 경우라면 지식 습득에 관한 기존 사고 방식을 바꾸는 게 좋습니다. 깊이와 폭 사이에서 지식 포트폴리오의 균형을 맞추는 일은 모든 개발자가 커리어 내내 고민해야 할 문제입니다.

2.3 트레이드오프 분석

아키텍트처럼 생각하는 것은 기술 여부와 상관없이 모든 솔루션의 트레이드오프를 분석하여 최선의 솔루션을 결정하는 것입니다.

아키텍처는 모든 게 다 트레이드오프입니다.

아키텍처 사고는 어떤 솔루션의 장점도 보면서 그와 연관된 단점이나 트레이드오프가 없는지 분석합니다.

여러 솔루션 중 택일하는 것은 언제나 비즈니스 동인, 환경 등 다양한 팩터에 좌우됩니다.

2.4 비즈니스 동인의 이해

아키텍처 사고는 성공적인 시스템 구축에 필요한 비즈니스 동인을 이해하고 요구사항을 (확장성, 성능, 가용성 등의) 아키텍처 특성으로 해석하는 것입니다.

2.5 아키텍처와 코딩 실무 간 균형 맞추기

코딩 실무와 소프트웨어 아키텍처의 균형을 맞추는 것도 아키텍트가 극복해야 할 어려운 일 중 하나입니다.

코딩 실무와 소프트웨어 아키텍처의 균형을 맞추는 첫번째 팁은, 병목 트랩(bottleneck trap)에 빠지지 말라는 것입니다.

아키텍트는 풀타임 개발자가 아니므로 개발자의 역할과 아키텍트 역할의 균형을 잘 맞춰야 합니다.

아키텍트로서 병목 트랩에 안 빠지려면 먼저 크리티컬 패스와 프레임워크 코드는 다른 개발팀 사람에게 넘기고 비즈니스 기능을 코딩하는 작업에 집중에서 1~3회 이터레이션을 수행하는 것이 좋습니다. 이렇게 하면 세 가지 측면에서 긍정적인 효과가 있습니다.

• 아키텍트는 더 이상 팀의 병목점이 되지 않고 프로덕션(production) 코드를 실제로 작성하는 실무 경험을 쌓게 됩니다.
• 크리티컬 패스와 프레임워크 코드를 개발팀에 분산시키고 소유권을 부여함으로써 시스텤에서 가장 어려운 부분을 더 잘 이해할 수 있습니다.
• 개발자들이 프로세스, 절차, 개발 환경, 어느 부분에서 가장 큰 고통을 겪고 있는지 몸소 체험할 수 있습니다.

아키텍트가 개발팀과 함께 코드를 개발할 수 없는 경우 코딩 실무 능력을 유지하는 방법.

• 개념 증명(POC, Proof-Of-Concept)를 자주 해 보는 것입니다.
• 기술 부채(technical debt) 스토리나 아키텍처 스토리에 전념. 버그 잡기.
• 간단한 커맨드라인(command-line) 도구나 분석기를 만들어 개발팀의 일상 업무를 간소화, 자동화 하는 것. 아키텍처 컴플라이언스 보장을 자동화하기 위해 피트니스 함수를 사용하는 것.
• 자주 코드 리뷰를 하는 것.

요약

2.1 아키텍처 대 설계

• 아키텍처와 설계의 차이를 이해하고, 이를 통합한 솔루션을 찾는 것이 중요.
• 아키텍트와 개발자 간 활발한 소통이 필요하며, 아키텍트는 개발자를 멘토링할 수 있어야 함.
• 아키텍처와 설계는 프로젝트의 성공을 위해 항상 동기화되어야 함.

2.2 기술 폭

• 아키텍트는 깊이보다는 폭넓은 기술 지식이 중요.
• 기술에 대한 넓은 이해와 여러 솔루션을 통해 문제를 해결할 수 있는 능력이 필요.
• 기술 포트폴리오를 넓히고, 지식의 균형을 맞추는 것이 중요.

2.3 트레이드오프 분석

• 모든 솔루션은 트레이드오프가 있으며, 이를 분석해 최선의 선택을 하는 것이 아키텍트의 역할.
• 비즈니스 동인, 환경 등 다양한 요인을 고려해 솔루션을 선택해야 함.

2.4 비즈니스 동인의 이해

• 비즈니스 동인을 이해하고, 이를 아키텍처 특성으로 해석하는 것이 성공적인 시스템 구축의 열쇠.

2.5 아키텍처와 코딩 실무 간 균형 맞추기

• 아키텍트는 코딩 실무와 아키텍처의 균형을 잘 맞추어야 함.
• 팀의 병목이 되지 않도록 크리티컬 패스와 프레임워크 코드를 팀에 분산해야 함.
• POC나 기술 부채, 코드 리뷰 등을 통해 코딩 실무 능력을 유지할 수 있음.