소프트웨어 아키텍트가 알아야 할 97가지

*아키텍트 (Architect) - 아키텍처(Architecture)를 설계 하는 사람
*아키텍처 = 건물의 구조 (서비스의 구조)
*아키텍트 = 건물의 구조를 설계하는 사람 (서비스의 구조를 설계하는 사람)

*이 책은 97명의 선배들의 인터뷰 담겨져 있는 글 입니다. 30% 정도의 내용만이 High Tech 얘기였고 그 외에는 중상 난이도 정도의 기술 얘기, 사람, 리더십, 커뮤니케이션, 설계, 비즈니스에 대한 얘기가 많았습니다. 그 만큼 소프트웨어 개발이 어렵다는 얘기가 아닐까요? 모든 것이 똑똑한 엔지니어 몇 명이 모여 해결할 수 있는 문제 였다면.. ㅠ 우리는 정말 어려운 일을 함께 하고 있습니다.

*한국에서는 흔하지 않은 역할 이지만 해외에서는 ‘아키텍트’ 라는 역할의 개발자들이 많은 것 같습니다. 설계 능력과 트러블 슈팅 능력이 뛰어나신 분들이 주로 맡는 역할 입니다. 그 만큼 소프트웨어의 복잡성에 대해서 이해하고 있고 그 어려움을 적절하게 풀어가려고 하는 좋은 환경이 만들어져 있는 거라 생각합니다.

*이 책을 읽으면서 부러웠던 점은 국내에서도 이런 현실적인 문제점들을 같이 공유하고 해결하려는 노력들이 많이 이루어졌으면 좋겠다는 생각이 참 많이 들었습니다. 아직 국내 IT 환경은 적절한 대우를 받지 못 하는 인력들이 훨씬 많습니다. 또 그런 목소리를 낼 수 있는 공간도 많이 부족하구요. 저의 여러가지 역할 중 한 가지가 이런 운동에 앞서야 하고, 더 강하게 목소리를 내야 한다고 생각하고 있습니다. 이런 운동들이 많아지고 순환이 계속해서 이뤄지면 발전을 이룰 수 있는 토대가 형성될 것이고, 더 좋은 인재들이 발굴되지 않을까요?

----

*고객의 요구사항보다 여러분의 이력에 더 우선순위를 두지 말라.

*가장 큰 문제는 기술이 아니다.
> 프로젝트의 성공과 실패 모두 사람이 만든다, 사람들이 성공하게 만드는 데 무엇이 도움이 되는지 고민해야 한다.

*모든 것은 궁극적으로 실패하게 된다.
> 소프트웨어 내 버그는 무조건 생긴다. 일단 결함이 발생할 수 있다는 것을 인정한다. 결함 모드를 미리 설계할 수 있는 대응력을 길러야 한다.

*정량화시켜라.
> ‘빠르다’, ‘응답성이 좋게’, ‘확장성 있도록’ 은 요구사항이 될 수 없다. 상대방에게 정확하게 요구하자.
> 마찬가지로 ‘빠르다’, ‘응답성이 좋게’, ‘확장성 있도록’ 은 목표가 될 수 없다. 정확하게 상대방을 설득하자.
> 시스템이 이러한 속성들을 포함하도록 하고 균형을 맞추며 정확히 얼만큼의 성능인지 수치화를 할 수 있어야 한다.
> 정량화가 어렵다? 그럼 정량화 할 수 있는 것을 찾아 바꾸거나, 할 수 있는 방법을 고민하는 것이 우선이다.

*한번에 딱 맞는 해결책은 없다.
> 영역에 맞는 감각을 지속적으로 계발하고 연습해야 한다.

*비즈니스 도메인 이해하기
> 기술 뿐 아니라 문제 영역의 비즈니스 도메인도 이해해야 한다.
> 비즈니스 도메인 지식 없이 비즈니스의 문제, 목표, 요구들을 이해하기 힘들다.
> 소프트웨어 아키텍트들은 임원과 비즈니스 사용자와 대화 시 도메인 언어를 사용해야 한다.
> 상담 받는데 이런 것이 불편하지 않을까? 편하지 않을까? -> 상담을 받아 보지 않은 실무자가 어떻게 알 수 있을까?

*운영과 유지 보수에 집중하라
> 유지보수는 어플리케이션 생명주기 중 80% 이상을 차지한다.
> 운영 팀의 학습 비용을 최소화시키는 방향을 항상 염두에 둬야 한다.

*간단한 것은 간단하게 하라
> 오버 엔지니어링을 피하자.
> 엔지니어의 능력 중 (1) 가장 어렵고 (2) 가장 중요하고 (3) 가장 높은 평가를 받을 수 있는 능력은 **적절한** 해결책을 찾는 것 이다.

*탄탄한 비즈니스 사례를 만들어라
> 비즈니스가 우선이다.
> 신뢰를 얻어야 한다.
> 확실한 가치 제안 / 정량화된 측정 지표 제작 / 적절한 일정

*훌룡한 소프트웨어는 만들어지는 것이 아니라 성장하는 것이다
> 동작하는 하나의 작은 시스템에서부터 천천히 개발하고 테스트하고 성장해야 한다.
> 거대한 시스템 설계도를 가지고 시작하는 것은 거의 장점이 없다.

*개발에 있어 형식에 얽매이는 행위야말로 삽질이다
> 이론에만 충실한 방법론자들과 형식에 대한 삽질을 유도하는 팀을 피한다.
> 소프트웨어는 100% 품질을 보장할 수 없다.
> 모든 것은 '필요한 수준’ 의 적정 선 만큼 이루어져야 한다.
> 각자의 경험과 해결책들을 다양하게 소화하고 조화롭게 이끌어가는 것이 중요한 포인트.