Chapter 2. Architectural Thinking

책(Mark Richards, Neal Ford, 『Fundamentals of Software Architecture』 2장)은 아키텍처 사고를 단순히 ‘아키텍처를 생각하는 것’이 아니라 아키텍처 관점에서 사물을 바라보는 것으로 정의한다. 책이 드는 구성 요소는 네 가지다.

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

2.1 Architecture vs Design

책이 설명하는 전통적인 역할 모델에서는 아키텍트가 내린 결정을 개발팀이 단방향으로 받아들인다. 아키텍트가 개발팀과 단절되어 있으므로, 구현은 원래 의도에서 멀어지기 쉽다.

책은 그 대안으로 아키텍트와 개발자가 양방향으로 소통하는 구조를 제시한다. 아키텍트가 멘토링과 코칭을 반복하면서 개발팀의 설계 과정 중간중간에 피드백을 줄 수 있어야 한다.

2.2 Technical Breadth

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

책은 지식을 이 세 범주로 나눈다. 개발 초심자 시절에는 내가 알고 있는 것의 범위를 넓히는 데 집중한다. 그러다 지식이 너무 방대하다는 것을 알게 되고, 기술 뉴스 등으로 키워드만 습득하게 된다. 그래서 ‘내가 모른다는 사실을 아는 것’이 점점 늘어난다.

개발자는 내가 알고 있는 것에 대해 깊은 전문성을 가져야 한다. 그러나 아키텍트가 되면 필요한 지식의 성격이 달라진다고 책은 말한다. 아키텍트의 가치는 대부분 기술을 폭넓게 이해하고 그 기술로 특정 문제를 해결하는 데서 나온다. 그래서 한 가지 문제만 해결하는 전문 지식보다, 한 문제를 해결할 수 있는 다섯 가지 솔루션을 아는 것이 더 중요하다.

아키텍트는 기술적인 제약 아래에서 어떤 기능이 가장 알맞은지 결정해야 하므로, 폭넓은 솔루션을 두루 알고 있어야 한다. 그래서 책은 어렵게 얻은 전문성을 일부 희생하더라도 포트폴리오를 넓히는 데 시간을 쓰는 편이 낫다고 본다. 그대로 남는 기술도 있지만 나머지는 조금씩 퇴화한다는 것도 받아들여야 한다.

내 메모: 이를 위해 기술 뉴스나 컨퍼런스, 세미나에서 최신 기술의 키워드와 사례를 알아 두려고 한다.

개발자 -> 아키텍트

개발자가 아키텍트로 전환하려면 우선 관점부터 바꾸어야 한다. 책은 이 전환이 어렵기 때문에 두 가지 역효과가 나타난다고 설명한다.

• 아키텍트가 되어 다양한 분야에서 전문성을 유지하려고 하나, 어느 하나 성공하지 못한 채 그러는 도중 지쳐 버린다.
• 김빠진 전문성(stale expertise): 자신의 낡은 정보가 아직도 첨단 기술인 양 착각한다.

‘꽁꽁 언 원시인’ 안티패턴

이는 실무에서 종종 볼 수 있는 패턴인데, 어떤 아키텍처든 언제나 가장 비합리적인 관심사로 회귀하려는 아키텍트가 이에 해당한다. 이 안티패턴은 과거의 나쁜 결정이나 예기치 못한 사고에 파묻혀 버려 그 이후로 극도의 경계심을 갖게 된(= 보수적인) 아키텍트에서 두드러진다. 진짜 기술 리스크와 리스크처럼 보이는 기술 리스크의 차이를 이해하는 것은 아키텍트가 평생 학습해야 할 주제이다.

내 메모: 실무에서도 리더가 오래된 기술이나 아키텍처를 선호하는 경우를 자주 봤다. 반대로 너무 트렌디한 기술을 좇다가 유지보수에 역효과가 나기도 한다. 그래서 기술 제안은 열린 마음으로 듣되, 최종 결정은 신중하게 하려고 한다.

2.3 트레이드오프 분석

책의 관점에서 아키텍처의 모든 결정은 트레이드오프다. 그래서 “It depends”라고 답할 수밖에 없다. 배포 환경, 비즈니스 동인, 회사 문화, 예산, 기간, 개발자 기술셋 같은 여러 요인이 답을 바꾼다.

아키텍처는 정답도, 오답도없다. 오직 트레이드오프만 있을 뿐.

2.4 비즈니스 영향요소의 이해

책은 아키텍처 사고에 비즈니스 영향 요소를 이해하고 요구사항을 아키텍처 특성(성능, 확장성, 가용성처럼 기능 외에 시스템이 갖춰야 할 성질)으로 해석하는 일이 포함된다고 본다. 그러려면 어느 정도의 비즈니스 도메인 지식을 갖추고, 비즈니스 핵심 인사들과 협력적인 관계를 유지해야 한다.

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

책은 모든 아키텍트가 코딩을 하면서 어느 정도의 기술 깊이를 유지해야 한다고 말한다. 다만 균형을 잘못 잡으면 병목 트랩에 빠진다. 책은 그 함정을 피하려면 크리티컬 패스(보통 시스템 전반을 제어하는 하부 프레임워크 코드)의 소유권을 아키텍트가 갖지 말고 다른 개발자가 맡도록 하라고 권한다.

책이 제안하는 코딩 실무 능력 유지 방법

• 개념 증명(POC, 기술이 의도대로 동작하는지 작게 만들어 확인하는 것)을 자주 한다. 각 제품을 응용한 예제 코드를 짜 보고 실행 결과를 비교한다. 다만 발표용 코드가 아니라 프로덕션 수준의 코드를 작성하는 게 좋다. POC 코드가 다른 사람에게 샘플이나 레퍼런스가 되기 때문이고, 나쁜 코딩 습관이 손에 배기 전에 좋은 코드를 쓰는 습관을 들일 수 있기 때문이다.
• 개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채 스토리나 아키텍처 스토리에 전념하는 것이다. 이런 스토리는 보통 우선순위가 낮기 때문에 그냥 한 번 해봐도 큰 문제가 되지 않는다.
• 이터레이션을 하면서 버그를 잡는 일 역시 개발팀을 도와 코딩 실무 능력을 유지하기에 좋은 방법이다.
• 간단한 커맨드라인 도구나 분석기를 만들어 개발팀의 일상 업무를 간소화, 자동화하는 것도 코딩 실무 능력을 유지하며 개발팀을 더욱 능률적으로 만드는 일석이조의 방법이다.
• 아키텍처 규칙이 지켜지는지 자동으로 확인하기 위해 피트니스 함수(아키텍처 특성을 검사하는 자동화된 테스트나 검사)를 작성하는 것도 방법이다.
• 코드 리뷰를 자주 하는것도 큰 도움이 된다.

내 메모: 보통 개발팀의 리더급 인원이 아키텍트 역할을 맡는 것 같다. 이 장을 읽고 나니 회사 팀장님이 지향하던 방향이 무엇이었는지 어느 정도 이해가 된다.

참고

• Mark Richards, Neal Ford, 『Fundamentals of Software Architecture』, O’Reilly, Chapter 2 “Architectural Thinking” (책 소개 사이트)