[소프트웨어 아키텍처 101] 챕터 2. 아키텍처 사고

아키텍처 사고

아키텍트는 개발자와 사뭇 다른 관점에서 주변을 바라본다. 기상학자와 아티스트가 구름을 바라보는 관점이 다른 것과 같은 이치이다. 이것을 **아키텍처 사고(architectural thinking)**라고 한다. 그러나 안타깝게도 아키텍처 사고를 그냥 아키텍처를 생각하는 것정도로 단순하게 여기는 아키텍트가 참으로 많다.

아키텍트의 사고 방식은 크게 네 가지로 나뉜다.

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

2.1 아키텍처 대 설계

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

 

위의 그림과 같은 전통적인 아키텍트와 개발자의 역할 모델은 문제가 많다.

아키텍트가 내린 결정이 개발팀에서전혀 쓸모가 없는 경우가 있음에도 불구하고, 개발팀이 아키텍처를 변경하기로 결정한 내용이 다시 아키텍트에게 전달되는 일은 거의 없다.

제대로 된 아키텍처를 만들려면 반드시 아키텍트와 개발자를 가르는 가상의 물리적 장벽을 허물고 두 팀이 양방향으로 소통하는 관계를 정립해야 한다.

변화에 둔감하고 융통성 없는 구식 폭포수 모델과 달리, 요즘 시스템 아키텍처는 매 프로젝트 단계마다, 또는 매 이터레이션마다 끊임없이 변화하고 발전하기 때문에 소프트웨어 프로젝트를 성공으로 이끌려면 아키텍트와 개발팀이 똘똘 뭉쳐야 한다. 아키텍처, 설계 모두 소프트웨어 프로젝트 생명 주기의 일부로서 항상 서로 동기화되어야 성공할 수 있다.

2.2 기술 폭

기술 세부의 범위 또한 개발자와 아키텍트가 다르다. 업무를 진행하기 위해 기술 깊이를 확보해야 하는 개발자와 달리, 소프트웨어 아키텍트는 아키텍트답게 사고하고 아키텍처 시각을 유지하기 위해 상당한 기술 폭을 갖춰야 한다.

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

아키텍트에게 깊이보다 폭이 더 중요하다. 아키텍트는 기술적인 제약 하에 어떤 기능이 가장 알맞는지 결정해야 하므로 아주 폭넓은 솔루션을 두루 꿰고 있어야 한다.

커리어 내내 자신의 기술을 갈고 닦아온 개발자가 아키텍트로 전환하려면 우선 관점부터 바꾸어야 한다. 많은 사람들이 이것을 어려워하기 때문에 결국 두 가지 역효과가 일어난다.

• 아키텍트가 되어 다양한 분야에서 전문성을 유지하려고 하나, 어느 하나도 성공하지 못한 채 지레 지쳐버린다.
• 김빠진 전문성(stale expertise)이 나타난다.
  • 자신의 낡은 정보가 아직도 첨단을 달리고 있는 것처럼 그릇된 인식에 사로잡히게 된다.

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

'꽁꽁 언 원시인' 안티패턴

꽁꽁 언 원시인 안티패턴(Frozen Cavenman Anti-Pattern은 야생에서 자주 볼 수 있는 행위와 연관된 안티패턴이다. 어떤 아키텍처든 언제나 가장 비합리적인 관심사로 회귀하려는 아키텍트가 이 안티패턴에 해당된다.

이 안티패턴은 일반적 과거의 나쁜 결정이나 예기치 못한 사고에 파묻혀 버려 그 이후로 매사 극도의 경계심을 갖게 된 아키텍트에서 두드러진다. 리스크 평가는 중요하지만 현실적으로 해야 한다. 진짜 기술 리스크와 리스크처럼 보이는 기술 리스크의 차이를 이해하는 것은 아키텍트가 평생 학습해야 할 주제이다. 아키텍트답게 생각하려면 '꽁꽁 언 원시인'의 사고 방식과 경험을 극복하고 다른 솔루션을 찾아보면서 더 적절한 질문을 해야 한다.

2.3 트레이드오프 분석

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

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

배포 환경, 비지니스 동인, 회사 문화, 예산, 기간, 개발자 스킬 세트 등 여러 팩터들이 영향을 미친다. 아키텍처가 참 어렵다는 말이 나오는건, 저마다 다른 환경, 상황, 문제를 안고 있기 때문일 것이다.

클로저 프로그래밍 언어의 창시자인 리치 히키(Rich Hickey)는 이런 말을 남겼다.

프로그래머는 장점은 잘 알지만 트레이드오프는 하나도 모른다. 아키텍트는 둘 다 잘 알아야 한다.

소프트웨어 아키텍처는 만사가 트레이드오프(장점과 단점)를 갖고 있다는 점이 중요하다.

아키텍트다운 사고란, 이런 트레이드오프를 분석하고 '신장성(extensibility)과 보안 중에 어느 것이 더 중요한가?'를 떠올려보는 것이다. 여러 솔루션 중 택일하는 것은 언제나 비즈니스 동인, 환경 등 다양한 팩터에 좌우된다.

2.4 비지니스 동인의 이해

아키텍처 사고는 성공적인 시스템 구축에 필요한 비지니스 동인을 이해하고 요구사항을 (확장성, 성능, 가용성 등의) 아키텍처 특성으로 해석하는 것이다. 따라서 어느 정도의 비지니스 도메인 지식을 갖고서 비지니스 핵심 인사들과 원만하고 협력적인 관계를 유지해야 하는 아키텍트 업무는 결코 만만하지 않다.

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

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

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

병목 트랩은 아키텍트가 프로젝트의 크리티컬 패스(임계 경로, 최장 경로)에 있는 코드의 소유권을 갖고 있는 경우 발생한다. 아키텍트는 풀타임 개발자가 아니므로 개발자 역할과 아키텍트 역할의 균형을 잘 맞춰야 한다.

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

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

만약, 아키텍트가 코드를 개발할 수 없을 경우 실무 능력을 유지하는 방법은 네 가지로 요약할 수 있다.

첫째, 개념 증명(proof-of-concept, POC)를 자주 해보는 것이다.

POC는 아키텍트가 소스 코드를 직접 작성해보면서 구현 상세를 생각하게 되므로 아키텍처 결정을 검증하는 데 유용하다.

POC 작업을 할 때에는 가능한 프로덕션 수준의 고품질 코드를 작성하는 게 좋다.

아키텍트가 쓰고 버리려고 작성한 POC 코드가 소스 코드 저장소에 커밋되면 이것이 레퍼런스 아키텍처가 되거나 다른 사람들이 따라하는 좋은 샘플이 되는 경우가 많다. 또, 아키텍트는 프로덕션 품질의 POC 코드를 작성해보면서 나쁜 코딩 습관이 점점 더 손에 배기 전에 잘 짜인 양질의 코드를 작성하는 습관을 들이게 된다.

또 다른 방법은 개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채 스토리나 아키텍처 스토리에 전념하는 것이다.

이런 스토리는 보통 우선순위가 낮기 때문에 해당 이터레이션 내에 아키텍트가 끝내지 못한다고 해서 세상이 종말을 맞게 되는 것도 아니며 이터레이션 성공에도 영향을 미치지 않는다.

이터레이션을 하면서 버그를 잡는 일 역시 개발팀을 도우며 코딩 실무 능력을 유지하기에 좋은 방법이다. 아키텍트에게 내키지는 방법은 아니지만, 이 과정에서 코드베이스 또는 아키텍처에 존재하는 이슈나 약점을 발견할 수도 있다. 간단한 커맨드 라인 도구나 분석기를 만들어 개발팀의 일상 업무를 간소화, 자동화하는 것도 코딩 실무 능력을 유지하며 개발팀을 더욱 능률적으로 만드는 일석이조의 방법이다.

실무 능력을 유지하는 마지막 방법은 자주 코드 리뷰를 하는 것이다.

물론, 아키텍트는 실제로 코딩을 하는 사람은 아니지만 적어도 소스 코드에 관여하는 사람들이다. 코드 리뷰를 수행하면 아키텍처 컴플라이언스를 보장할 수 있고 경험이 많지 않은 팀원을 멘토링하고 코치할 기회가 생기는 등 여러모로 장점이 많다.

느낀점

• 아키텍트로서 일한다면, 어디에 집중해야 하는지 감이 잡히는 것 같다.