[소프트웨어 아키텍처] 아키텍처 결정 안티패턴

아키텍트에게 기대하는 핵심 가치 중 하나는 아키텍처 결정을 내리는 것 입니다. 아키텍처 결정을 위해서는 충분한 정보 수집과 결정을 정당화, 문서화한 다음 이해관계자들과 효과적으로 소통을 해야 합니다.

아키텍처 결정 안티패턴

프로그래머 앤드류 케이니그의 경우 안티패턴이란 좋은 생각처럼 보이지만 이내 곧 곤경에 빠뜨리는 애물단지라고 정의하였습니다. 부정적인 결과를 내는 반복 가능한 프로세스라고 정의하는 이들도 있습니다. 자주 발생하는 안티패턴은 3가지로 정의할 수 있는데 “네 패를 보여주지마”, “무한 반복 회의”, “이메일 기반 아키텍처” 를 꼽을 수 있습니다.

‘네 패를 먼저 보여주지마’ 안티패턴

해당 패턴은 아키텍트가 잘못된 선택을 하는 것을 두려워한 나머지 아키텍처 결정을 회피하거나 미루는 현상을 말합니다.

해당 아키텍처는 2가지 방법으로 극복 할 수 있습니다.

첫째, 어떤 중요한 아키텍처 결정을 내리기 전, 마지막으로 책임질 수 있는 순간까지 기다리는 것 입니다. 아키텍트가 자신의 결정을 정당화하고 검증하기 위해 충분한 정보를 수집할 때까지 기다리지만, 개발팀을 마냥 붙잡아 두거나 분석 마비 안티패턴에 빠질 정도로 오래 기다리지 않게 합니다.

둘째, 개발팀과 지속적으로 협력하면서 아키텍트가 결정한 내용을 원래 의도한 대로 추진합니다. 세부적인 기술에 관한 모든 이슈를 아키텍트 혼자 전부 다 알 수는 없기 때문에 개발팀의 협력은 절대적으로 필요합니다. 그래야 나중에 문제가 생겨도 아키텍트가 아키텍처 결정을 변경하면서 재빠르게 대응할수 있습니다

‘무한반복 회의 패턴’ 안티패턴

사람들이 어떤 결정을 왜 했는지 모르고 주구장창 회의만 계속 하는 것 입니다.

무한 반복 회의 패턴이 발생하는 이유는 아키텍트가 자신이 내린 결정을 정당화하는 데 실패했기 때문 입니다. 아키텍처 결정을 정당화하려면 그 결정을 내리게 된 기술적, 비즈니스적 근거를 제시하는 것이 중요합니다. 예를 들어 기술적인 근거는 있으나 비즈니스적 근거를 내리지 못한다면 해당 패턴은 계속 발생 할 수 있을것 입니다. 비즈니스적 근거를 만족하지 못한다면 한발짝 물러나 보는것도 좋습니다.

가장 일반적인 비즈니스적 정당화는 비용, 출시시기, 유저 만족도, 전략적 포지셔닝 등이 있습니다. 그리고 이런 비즈니스적 정당화 내용도 우선순위를 정해야 합니다. 비즈니스 고객이 출시시기가 중요한데 비용을 따져서 이야기를 하면 바람직하지 않습니다.

‘이메일 기반 아키텍처’ 안티패턴

사람들이 아키텍처 결정을 놓치거나 잊어버리고 심지어는 이렇게 결정됐다는 사실조차 알지 못해 아키텍처 결정을 구현하지 못하는 상태 입니다. 즉, 아키텍처 결정을 효과적으로 전달하는 문제와 관련된 안티패턴 입니다.

해당 안티패턴을 극복하는 방법은 2가지 입니다.

첫째, 이메일 본문에 아키텍처 결정을 포함시키지 않습니다. 이메일 본문에 아키텍처 결정을 기재하면 그 결정에 관한 여러 경로의 기록 체계가 파생되고 중요한 세부 사항들이 이메일에서 누락되지 쉽습니다. 그래서 본문엔 계략적인 내용만 작성하고 상세내용은 위키 페이지 링크든 파일첨부등을 이용하여 전달 합니다.

둘째, 아키텍처 결정에 정말 관심 있는 사람에게만 전달 합니다. 아키텍처 결정이 수신자에게 직접적인 영향도가 없다면 굳이 관계 없는 사람을 성가시게 할 필요가 없습니다.