회사 기술 블로그에 오랜만에 '아키텍처 설계 워크숍'이라는 주제로 글을 썼습니다. 올초에 새로운 프로젝트에 들어가기 전에 팀 공동으로 아키텍처를 설계하는 활동을 한 달간 진행한 제 경험을 정리한 글

회사 기술 블로그에 오랜만에 '아키텍처 설계 워크숍'이라는 주제로 글을 썼습니다. 올초에 새로운 프로젝트에 들어가기 전에 팀 공동으로 아키텍처를 설계하는 활동을 한 달간 진행한 제 경험을 정리한 글입니다. 팀 프로젝트를 할 때는 아키텍처를 한 사람이 독점할 수 없습니다. 공동의 규칙을 모두가 따르지 않으면 설계의 일관성이 쉽게 깨져버립니다. 깨진 일관성 사이로 파편화가 들어옵니다. 프로젝트에 참여하는 구성원이 많아질수록 파편화는 빨리 퍼집니다. 결국은 한 배를 탄 동료와 어떻게든 발을 맞춰야만 하는데, 이게 참 어렵습니다. 나 혼자 어찌 할 수 없는 아키텍처 설계라는 건, 어쩌면 구성원이 공동의 규칙을 합의하는 사회적인 활동일지도 모르겠습니다. 그렇다면 아키텍처를 개인이 아닌 팀이 함께 힘을 모아 설계를 한다면 어떨까요? 이 글의 주제인 아키텍처 설계 워크숍은 이런 고민에서 태어났습니다. 팀 프로젝트를 하며 다음의 문제를 경험하고 계신 분들이 읽어보시면 좋을 것 같습니다. - 쏟아지는 요구사항을 모두 만족시키려고 하면서 시스템의 복잡도가 너무 높아졌다. - 아키텍처를 논의할 때 내가 아는 설계 지식을 충분히 동료에게 설명하고 설득하지 못했다. - 반대 의견을 가진 동료와 대립하다가 지쳐서 그때그때 적당히 일관성 없는 합의를 했다. - 설계 규칙을 효과적으로 공유하지 못하여 규칙을 따르지 않는 코드가 시스템에 빠르게 퍼져 제어할 수 없는 지경에 이르렀다.