[소프트웨어 아키텍처 101] 파트3

19장. 아키텍처 결정

아키텍처 결정을 하려면 충분한 정보를 수집하고 결정을 정당화, 문서화 한 다음 이해관계자들과 효과적으로 소통해야 한다.

아키텍처 결정 안티패턴

아키텍처를 결정하는 것도 기술이다. 아키텍처 결정에도 안티패턴이 있다.

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

잘못된 선택을 하는 것을 두려워해 결정을 회피하거나 미루는 현상이다.
이는 두 가지 방법 극복할수 있다.

첫째, 중요한 아키텍처 결정을 내리기 전 마이작으로 책임질수 있는 순간까지 기다리는 것이다.
결정을 정당화하고 검증하기 위해 충분한 정보를 수집할때 까지 기다리지만, 너무 오래 기다리게 하지 않음을 의미한다.

둘째, 개발팀과 지속적으로 협력하며 결정한 내용을 원래 의도한 대로 추진한다.

'무한반복 회의' 안티패턴

어떤 결정을 왜 했는지 모르고 주구장창 회의만 계속 하는 것이다.
이런 현상이 발생하는 이유는 아키텍트가 내린 결정을 정당화 하는데 실패했기 때문이다.
아키텍처 결정을 정당화 하려면 결정을 내리게 된 기술적, 비즈니스적 근거를 제시하는 것이 중요하다.

기술적인 명분이 충분하더라도, 비즈니스적으로 정당화 하는것도 중요하다.
어떤 아키텍처 결정이건 정당화 할때는 비즈니스 가치를 제시하는 것이 중요하다.
비즈니스 가치가 없다면 아무리 기술적으로 좋은 아키텍처와 결정이라고 하더라도 다시 생각해 보는 것이 좋다

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

아키텍처 결정을 놓치거나 결정됐다는 사실조차 알지 못해 아키텍처 결정을 구현하지 못하는 상태.
이메일은 훌륭한 소통 수단이지만 문서 저장 체계로는 좋지 않다.

이메일 본문에는 아키텍처 결정의 본질과 맥락 정도만 언급하고 세부 정보는 다른 기록 시스템에 보관하여 링크만 제공한다

20장. 아키텍처 리스크 분석

모든 아키텍처는 리스크를 갖고 있다.
아키텍처 리스크 분석은 아키텍트의 핵심 활동 중 하나로, 리스크를 꾸준히 분석하여 내부 결함을 바로잡고 리스크를 줄이는 일이다.

시스템의 모든 리스크를 아키텍트 혼자 결정할 순 없다.
아키텍트 한 사람이 리스크 영역을 빠짐없이 살펴볼 수도 없고, 전 부분을 완벽하게 알고 있는 아키텍트도 없어 리스크 스토밍을 하는 것이 좋다.

리스크 스토밍은 특정 범위 내에 있는 아키텍처 리스크를 찾아내는 협력적은 활동이다.
일반적인 리스크 영역으로는 검증되지 않은 기술, 성능, 확장성, 가용성, 데이터 소실, 단일 장애 지점, 보안 등이 있다.

21장. 아키텍처 도식화 및 프레젠테이션

아키텍트로서 성공하려면 무엇보다 효과적인 의사 소통이 중요하다.
아무리 훌륭한 아이더를 갖고 있다 해도 이해관계자들이 납득하지 못하면 빛을 볼수 없다.

아키텍처를 도식화 하고 프레젠테이션 하는 일은 아키텍트의 핵심 소프트 스킬이다.

아키텍처를 시각적으로 기술할 때는 아키텍처를 다른 관점에서도 바라보아야 한다.
예를 들어 전체 아키텍처 토폴로지를 개관한 다음, 개별 파트를 하나씩 파헤쳐 상세 설계를 나타낸다.

프레젠테이션시에는 한번에 전부를 보여주는게 아닌, 점진적으로 빌드함으로써 필요한 만큼의 정보만 쌓아 올려야 한다

22장. 개발팀을 효율적으로

소프트웨어 아키텍트는 개발팀이 아키텍처를 올바르게 구현하도록 안내할 책임이 있다.

팀 경계

아키텍트가 제약조건을 너무 많이 설정하면 개발자는 환멸감을 느껴 더 좋은 환경을 찾아 떠난다.
반대로 너무 느슨하게 적용하면, 중요한 아키텍처 결정을 모두 위임하게 되는데 이것도 좋지 않다

팀이 올바른 도구와 라이브러리를 사용하여 아키텍처를 구현할 수 있도록 적절한 지침과 제약조건을 제공한다.
팀이 용도에 맞는 도구와 기술을 보유하고 있는지 확인하고 목표를 달성하는데 걸림돌이 될 만한 요소를 제거한다

얼마나 제어해야 하나?

좋은 아키텍트가 되려면 얼마나 제어를 해야할까?
다음 팩터들과 밀접한 연관이 있다

팀원 간 친밀도

팀원들이 서로 잘 아는 사이라면 스스로 조직화하기 시작하므로 제어가 덜 필요하다.
반대일수록 팀원 간 협업을 촉진하고 팀내 파벌을 없애기 위해 더 많은 제어가 필요하다.

팀 규모

팀 규모가 커질수록 더 많은 제어가 필요하다

전체적인 경험

팀원 중 시니어가 많을 수록 제어가 덜 필요하다

프로젝트 복잡도

복잡도가 높을 수록 팀에 더 많은 제어가 필요하다

프로젝트 기간

프로젝트 기간이 길수록 더 많은 제어가 필요하다

 

23장. 협상과 리더십 스킬

협상과 조정

비즈니스 이해관계자들과의 협상

• 상황을 더 잘 이해하기 위해 문법과 유행어를 사용하라
• 협상에 돌입하기 전 가능한 많은 정보를 수집하라
• 다른 모든 것이 실패하면 비용과 시간으로 설명하라
• 분할 및 정복을 활용해 요구사항 또는 필요 조건을 검증하라

다른 아키텍트들과의 협상

• 증명은 언제나 논쟁을 이긴다
• 지나친 논쟁이나 개인적 감정을 드러내지 말라. 간결명료한 추론에 차분한 리더십을 더해라

개발자들과의 협상

• 고압적으로 지시하지 말고 일을 해야하는 정당성을 제공하라
• 아키텍트의 결정에 동의하지 않을 경우 스스로 해결책을 찾도록 유도하라

소프트웨어 아키텍트는 리더다

소프트웨어 아키텍트는 개발팀을 이끌고 아키텍처를 구현하는 리더이다.
유능한 소프트웨어 아키텍트가 되는 50% 정도는 효과적인 대인 관계 스킬, 조정 능력, 리더십에 있다.

아키텍처 4C

많은 아키텍트가 복잡하게 만드는 잘못을 행한다.
이를 방지하는 방법은 커뮤니케이션, 협동, 명료함, 간결함을 실천한다

실용적으로 행동하되 비전을 가져라

실용적이면서 동시에 비전을 가져야 한다.
문제 해결 과정에서 끊임없이 상상력과 지혜를 발휘하면서도 실용적인 부분과의 적절한 균형점을 찾으려 노력한다.

모범을 보여 팀을 리드하라

직책을 들이대지 않고 솔선수범하여 리드한다.
대부분의 사람들은 기술 문제를 해결하는 건 대인 관계 기술과 아무 관계 없고 기술 지식만 연관되어 있다고 생각한다.
물론 기술 지식은 반드시 필요하지만 이는 입루에 불과하다.
기본적으로 팀을 이끌어 가는 것은 인간 관계 기술이다.