Chapter 2. Architectural Thinking
아키텍처 사고란, 단순이 ‘아키텍처를 생각하는 것’이 아니라 아티텍처적인 눈으로 아키텍처 관점에서 사물을 바라보는 것이다.
- 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하려면 개발팀과 어떻게 협력해야할 지 아는 것
- 어느 정도 기술 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것
- 다양한 솔루션과 기술 간의 트레이드 오프를 이해하고, 분석, 조율하는 것
- 비즈니스 동인(business driver)의 중요성을 이해하고 그것을 아키텍처 관심사로 해석할 줄 아는 것
2.1 Architecture vs Design
전통적인 아키텍트와 개발자의 역할 모델에서는 아키텍트가 내린 결정을 개발팀에서 단방향으로 받아들이는 구조이다. 이 경우에는 아키텍트가 개발팀과 완전히 단절되어 있기 때문에 원래의 의도와는 멀어질 가능성이 크다.
반면에, 제대로 된 아키텍처를 만들려면 반드시 아키텍트와 개발자가 양방향 소통을 할 수 있는 구조이어야 한다. 아키텍트가 멘코링/코치를 반복하면서 개발팀의 설계 과정 중간중간에 피드백을 줄 수 있어야한다.
2.2 Technical Breadth
- 내가 알고 있는 것: 기술, 언어, 프레임워크, 도구
- 내가 모른다는 사실을 아는 것: 한 번 들어봤거나 얕은 지식은 갖고 있지만 실무 경험은 전무한 기술
- 내가 모른다는 사실조차 모르는 것: 엔지니어가 해결하려는 문제에 완벽한 정답임에도 불구하고 그 존재조차 알지 못하는 기술
개발 초심자 시절에는 내가 알고 있는 것의 범위를 넓히는데 집중한다. 그러다보면 너무 방대한 지식이 넘쳐난다는 것을 알게되고, 기술뉴스 등을 통해 키워드만 습득하게 된다. 그러다보면 ‘내가 모른다는 사실을 아는 것’이 점점 늘어날 수 밖에 없다.
내가 알고 있는 것에 대해서는 전문성을 가지고 깊이가 있어야 한다. 그러나 개발자가 아키텍트가 되면 지식의 성격이 달라진다. 아키텍트의 가치는 대부분 기술에 대한 폭넓은 이해와 그 기술을 사용하여 특정한 문제를 해결하는 것이다. 즉, 아키텍트는 어느 한 가지 문제만 해결 가능한 전문 지식보다는, 문제를 해결할 수 있는 다섯 가지 솔루션을 알고 있는게 더 중요하다.
아키텍트에게는 깊이보다 폭이 더 중요하다. 아키텍트는 기술적인 제약 하에 어떤 기능이 가장 알맞는지 결정해야 하므로 아주 폭넓은 솔루션을 두루 꿰고 있어야 한다. 따라서 아키텍트는 어렵게 얻은 기술을 입루 희생하더라도 자신의 포트폴리오를 넓히는 데 시간을 투자하는게 더 현명하다. 그대로 남아있게 될 기술도 있지만 나머지는 조금씩 퇴화할 수 있음을 알아야한다. -> 💡 이를 위해 기술뉴스나 컨퍼런스, 세미나를 통해 최신 기술의 키워드와 사례를 알아두어야 한다.
개발자 -> 아키텍트
개발자가 아키텍트로 전환하려면 우선 관점부터 바꾸어야 한다. 하지만 이는 어려우므로 두 가지 역효과가 나타난다.
- 아키텍트가 되어 다양한 분야에서 전문성을 유지하려고 하나, 어느 하나 성공하지 못한 채 그러는 도중 지쳐 버린다.
- 김빠진 전문성(stale expertise), 자신의 낡은 정보가 아직도 첨단 기술인양 착각한다.
‘꽁꽁 언 원시인’ 안티패턴
이는 실무에서 종종 볼 수 있는 패턴인데, 어떤 아키텍처든 언제나 가장 비합리적인 관심사로 회귀하려는 아키텍트가 이에 해당한다. 이 안티패턴은 과거의 나쁜 경정이나 예기치 못한 사고에 파묻혀 버려 그 이후로 극도의 경계심을 갖게 된(= 보수적인) 아키텍트에서 두드러진다. 진짜 기술 리스크와 리스크처럼 보이는 기술 리스크의 차이를 이해하흔 것은 아키텍트가 평생 학습해야 할 주제이다.
-> 💡 실무에서도 리더가 종종 old fashioned 기술이나 아키텍처를 선호하는 경향이 많다. 반면에, 너무 트렌디한 기술을 좇아가다가 유지보수에 역효과를 가져다주기도 한다. 따라서 기술 결정은 열린 마음으로 진심을 다해 수용하면서도 최종 결정은 신중하게 할 필요가 있다.
2.3 트레이드오프 분석
아키텍처는 모든게 다 트레이드오프이다. “It depends”라고 말할 수 밖에 없는게 사실이다. 배포 환경, 비즈니스 동인, 회사 문화, 예산, 기간, 개발자 기술셋 등 여러 팩터들이 영향을 미친다.
아키텍처는 정답도, 오답도없다. 오직 트레이드오프만 있을 뿐.
2.4 비즈니스 영향요소의 이해
아키텍처 사고는 성공적인 시스템 구축에 필요한 비즈니스 영향 요소를 이해하고 요구사항을 아키텍처 특성으로 해석하는 것이다. 따라서 어느 정도의 비즈니스 도메인 지식을 갖고서 비즈니스 핵심 인사들과 원만하고 협력적인 관계를 유지해야 한다.
2.5 아키텍처와 코딩 실무 간 균형 맞추기
모든 아키텍트는 코딩을 하면서 어느 정도의 기술 깊이는 유지해야 한다. 코딩 실무와 소프트웨어 아키텍처의 균형을 맞추는게 중요한데, 이를 위해서는 병목 트랩에 빠지지 말고 크리티컬 패스(보통 시스템 전반을 제어하는 하부 프레임워크 코드)의 소유권을 가지지말고 다른 개발자가 담당하도록 하는것이 좋다.
아키텍트가 코딩 실무 능력과 기술 깊이를 유지하는 방법
- 개념 증명(POC)를 자주 해보는 것이다. 실제로 각 제품을 응용한 예제 코드를 짜보고 실행 결과를 비교해보는 것이다. 다만, 단순한 세미나 발표용이 아니라 프로덕션 수준의 고품질 코드를 작성하는 게 좋다. POC 코드가 다른 사람들에게 좋은 샘플이나 레퍼런스가 되기도 하며, 직접 작성해보면서 나쁜 코딩 습관이 점점 더 손에 배기 전에 잘 짜인 양질의 코드를 작성하는 습관을 들이게 된다.
- 개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채 스토리나 아키텍처 스토리에 전념하는 것이다. 이런 스토리는 보통 우선순위가 낮기 때문에 그냥 한 번 해봐도 큰 문제가 되지 않는다.
- 이터레이션을 하면서 버그를 잡는 일 역시 개발팀을 도무여 코딩 실무 능력을 유지하기에 좋은 방법이다.
- 간단한 커맨드라인 도구나 분석기를 만들어 개발팀의 일상 업무를 간소화, 자동화하는 것도 코딩 실무 능력을 유지하며 개발팀을 더욱 능률적으로 만드는 일석이조의 방법이다.
- 아키텍처의 컴플라이언스 보장을 자동화하기 위해 피트니스 함수를 사용하는 것도 방법이다.
- 코드 리뷰를 자주 하는것도 큰 도움이 된다.
-> 💡 보통 개발팀의 리더급 인원이 아키텍트를 담당하는 것 같다. 회사의 팀장님이 지향하던 방향이 뭔지 대충은 알 것 같다.