소프트웨어 아키텍처 2.0

소프트웨어 아키텍처 2.0 - 루크 호만 지음, 김인기 옮김/에이콘출판

성공한 소프트웨어란 무엇인가?

저자는 시장에서 선택을 받은 소프트웨어를 성공한 소프트웨어라고 정의한다. 기술에 집착하는 개발자들이 만드는 소프트웨어는 그 자체로 훌륭할 수는 있지만, 성공한 소프트웨어의 범주에 포함하기는 어렵다. 결국은 기업이 지속되기 어렵기 때문이겠지.

성공한 소프트웨어를 만들기 위해서는

개발부서와 마케팅부서의 조화가 필요하다. 저자는 제품 개발에 있어서 마키텍트와 타키텍트의 조합으로 시장 상황에 맞춰 대응해 나가는 것이 중요하다고 강조한다.
당연하고 중요한 주제이기는 하지만, 현실에서는 정말 어려운 문제 아닐까? 회사 내에서 마케팅, 또는 영업부서와 개발부서 간의 파워는 보통 한쪽에 편중되어 있을 것이다. 그러다 보니 경쟁의식이나 책임 문제, 불공평한 보상, 피해의식 등 상호 협조를 방해하는 많은 이슈가 있을 것 같다. 이를 해소하고 성공한 소프트웨어를 만들기 위해서는 강력한 리더쉽이 뒷받침되어야 할 것 같다.

인상깊은 이야기

일반적으로 시스템과 관련해 보안을 100% 보장하지 못한다면 아무 의미가 없다고 말한다. 보안을 보장하기로 했다면, 반드시 모든 것을 보장해야 한다.
"우리 소프트웨어가 정말 안전하기는 하지만, 당신이 원한다면 잠시 보안을 깨뜨리겠습니다"라고 말하면 안 된다. 그 대신, "우리는 당신의 실수로 인한 피해를 최소화하도록 돕겠습니다. 하지만 우리 소프트웨어는 너무 보안이 철저해서 우리조차도 그것을 깰 수 없습니다"라고 말해야 한다. 이것이 더 우수한 기술적인 메시지인 동시에 훨씬 우수한 마케팅 메시지다. 

잠시라도 보안을 깨드리면 안되는 이유다. 편의를 제공하는 것이 결국은 제품의 질을 떨어뜨리는 바보 같은 행동이구나.

2009년도에 읽었더라면

아마도 2009년도에 처음 책이 나온 것 같다. 그 때 읽었더라면 그간 개발해 왔던 것들이 조금은 더 나은 모습이지 않았을까 하는 아쉬움이 든다.




30
기술과 비즈니스 사이의 상호관계를 관리하는 것이 이 책에서 반복하는 주제다

1장 소프트웨어 아키텍처

31
Myron Ahn의 소프트웨어 아키텍처 정의
소프트웨어 아키텍처는 다음 항목들, 즉 시스템에 존재하는 중요한 모듈, 프로세스, 데이터, 그리고 이들의 구조, 이들 사이의 정확한 관계, 이들을 어떻게 확장하고 수정하는지 그리고 이들이 어떻게 확장되거나 수정되기를 바라는지에 대한 설명, 그리고 이를 위한 기반 기술, 시스템의 수용력과 유연성을 정확히 추론하는 방법, 시스템의 구현계획과 수정계획을 수립하는 방법들의 집합체다.

39
소프트웨어 아키텍처의 초기 버전은 어린이에 비유할 수 있다. 모든 것이 갖춰져 있지만 어딘가 미숙하고 불안하다. 시간이 지나면서, 또 계속 사용하고 출시 사이클을 반복하면서, 아키텍처는 성숙해지고 견고해진다. 사용자와 개발자 모두가 소프트웨어의 능력을 확신하게 되고, 동시에 그 한계도 이해하고 받아들이게 된다. 이 과정은 솔직하기로 약속한 상태에서, 성공을 위해 변화를 만들고, 이 변화에 대답하는 과정이라고 비유할 수 있다. 물론 미숙한 아키텍처가 어떤 피드백도 얻지 못하고 잊힐 수도 있다. 가장 큰 결정권자는 시장(market)이다.

40
이력서 주도형 디자인(resume-driven design)

46
아키텍처의 질적 저하는 아주 간단하게 시작된다. 어떤 주요 기능에 대한 시장의 압력이 높지만 그 기능을 위해 필요한 수용력이 없을 때, 다른 상황에서는 현명했던 엔지니어링 책임자가 필요한 수용력이 없을 때, 다른 상황에서는 현명했던 엔지니어링 책임자가 필요한 아키텍처 수용력의 보강 없이, 강제로 개발팀을 독려해서 요구된 기능만 구현하려고 한다.
(생략)
결론은 팀이 기술적인 부채를 감수하고 새로운 기능을 구현할 경우, 미래에 반드시 그것을 갚아야 한다는 것이다. 이 부채의 원금은 적절한 기반 수용력을 만드는 데 필요한 비용이다. 그 비용은 절대 사라지지 않는다.


2장 제품개발 첫걸음

61
제품관리란 성공하는 솔루션을 만들고 유지하는 데 필요한 활동들의 광범위한 집합이다.

62
기술만으로는 성공할 수 없다. (생략) 제품관리가 중요한 이유는 기술적으로 올바른 제품을 만드는 것만으로는 불충분하기 때문이다. 제품이 확실하게 성공하려면, 가격 정책을 수립하는 일부터 유용한 협력자 관계를 수축하는 일에 이르기까지, 복잡하고 서로 밀접하게 연관된 활동들을 주관하는 역할이 필요하다. 이런 핵심적인 활동 중 어느 하나라도 소홀히 하면 제품이 실패할 위험이 있다.

82
S자 제품 채택 곡선
혁신자(innovator) -> 얼리어답터(early adoptor) -> 전기 다수(early majority) -> 후기 다수(late majority) -> 지각 수용자(laggards)


3장 마키텍처와 타키텍처의 차이점

93
타키텍트는 전통적인 소프트웨어 아키텍트, 또는 최고 기술자
마키텍트는 제품 마케팅 관리자, 비즈니스 관리자, 또는 시스템을 책임지는 프로그램 관리자
타키텍처는 개발자가 시스템의 아키텍처를 생각할 때 사용하는 생각의 틀이다.
마키텍처는 비즈니스적인 관점에서 바라본 시스템 아키텍처다.

102
마키텍트와 타키텍트가 각기 다른 미래를 추구한다면 전체 시스템은 실패할 것이다.

111
버그는 심각성과 우선순위라는 두 가지 기준으로 구분해야 한다. 심각성은 버그가 고객에게 전다라는 파급효과를 말한다. 우선순위는 그것을 해결해야 하는 중요성을 말한다.


4장 비즈니스 모델과 라이선스 모델의 공생

113
비즈니스 모델은 당신의 제품이나 서비스를 이용하는 고객에게 과금하는 방식이다. 즉 당신이 돈을 버는 방식이다. 소스트웨어에 대한 모든 비즈니스 모델은 라이선스 모델과 연관돼 있다. 라이선스 모델은 약정과 이용조건(또는 권리와 제약조건)으로 구성된다. 이 약정과 이용조건은 사용자(고객)에게 비즈니스 모델이 정의하는 방식대로 소프트웨어를 이용하도록 허용하기 위한 것이다.


5장 기술 도임

172
기술을 효과적으로 도입하려면 마키텍트와 타키텍트 모두가 그 위험과 이득을 완전히 이해해야 한다. 이런 이해가 있어야 유리한 협상 고지를 점유할 수 있고, 좀 더 유리한 약정을 이끌어낼 수 있다.


6장 이식성

179
이식성은 언제나 돈에 관계된 문제다.


182
표준화되고 공동 사용 가능한 서브 시스템 간의 통신에는 XML을 사용하라

이식성이란 명목으로 특정 플랫폼에 한정적인 우수한 기능을 감추지 마라

189
이식 가능한 애플리케이션을 만들어야 하는 사업적으로 유효한 이유는, 오직 그렇게 했을 때 이익을 낼 수 있다는 것 뿐이다. 마키텍트는 보통 매출을 모델링하는 데는 능하지만, 이식 가능한 애플리케이션을 만들기 위해 필요한 비용을 모델링하는 데는 능하지 못하다.

이식 가능한 애플리케이션을 만드는 일은 생각보다 어렵다. 그리고 기대하는 것보다 오랜 시간이 필요하다.


7장 배치 아키텍처

207
배치 아키텍처는 고객이 사용할 수 있도록 시스템을 배치하는 방식을 말한다. 일반적으로 다음과 같은 선택이 있다.
- 고객 사이트
- ASP (application service provider)
- MSP (managed service provider)
- xSP (변형된 형태의 service provider)
- 웹 서비스
복합 모델, 즉 시스템의 일부는 고객 사이트에 배치되고 일부는 서비스 제공자 측에 배치되는 형태가 점점 더 일반화 되고 있다.


8장 통합과 확장

211
통합(integration)은 기대제품을 만들기 위해 당신의 시스템을 다른 시스템과 일할 수 있게, 또는 실제 일을 하도록 만드는 것이다(이는 보통 프로그램적인 방법으로 이뤄진다).
확장(extension)은 보강제품을 만들기 위해 시스템을 확대하는 것을 말한다. 플러그인 아키텍처처럼 잘 정의된 방법으로 새로운 기능을 시스템에 추가하는 과정이다.

227
여러 번의 출시를 거쳐 API를 안정화하기
제품을 처음 몇 번 출시할 때 필요한 API를 예측하기는 어렵다. 그리고 처음부터 적절한 API를 갖추기는 거의 불가능하다. 몇 번의 출시가 지난 후에야 주어진 타깃시장에 알맞게 API를 안정화할 수 있다. 이 사실을 고객에게 미리 공지해둬라.

246
당신의 애플리케이션을 통합/확장하기 위해 고객에게 제공하는 모든 수단을 주의 깊게 관리해야 한다. 반드시 안정된 상태에 이른 후에 공개해야 한다.


9장 브랜드와 브랜드 요소

247
성공하려면 브랜드 정책이 필수적이다. 당신은 훌륭한 기술을 만들 수 있다. 심지어 훌륭한 솔루션도 만들 수 있다. 하지만 성공하는 솔루션은 성공하는 브랜드가 있어야 빛이 나고, 그로부터 도움을 받는다.
브랜드 요소는 제품 구석구석에 분포해 있다. 그리고 다소 놀랍게도 아키텍처의 일부며, 관리할 필요가 있다.


10장 사용성

259
성공하는 솔루션은 사용하기 좋은 솔루션이다. 사용자는 그것을 가지고 필요한 작업을 쉽고 효과적으로 오류 없이 해낼 수 있으며, 자신이 원하는 바를 별다른 장애 없이 이룰 수 있다.

사용성은 무척 방대한 주제이다. 배치 아키텍처, 통합/확장 아키텍처, 운영, 유지보수, 설치, 업그레이드, 성능, 확장성 등 다양한 분야에서 의미를 갖는다.

276
마키텍트가 진정으로 원하는 것이 빠른 시스템일까? 대부분의 경우에는 분명히 사실이다. (생략)
마키텍트가 진정으로 원하는 바는 자신 있게, 신뢰할 수 있게, 그리고 무엇보다 정확하게 성능에 관한 질문에 대답하는 것이다.
- 시스템이 지원할 수 있는 동시 사용자/커넥션/세션의 숫자는 얼마나 되는가? 각 컴포넌트에 걸리는 부하는 얼마나 되는가?
- 현재의 하드웨어가 얼마나 많은 트랜잭션을 처리할 수 있는가(하드웨어의 상세 사양이 제공된다는 가정하에서)?
(생략
고객은 성능에 대해 상세히 질문하지 않는다. 대신 그들은 자신의 필요와 자신의 환경에 대한 대략적인 이해만을 갖고 질문한다. 그리고 필요한 인프라를 구축할 수 있도록 도움을 요청한다. 마키텍트에게는 대답할 수 있는 어떤 방법이 필요하다.

278
사용성에 관한 영원한 충고 중 하나는, 시스템이 즉각 응답할 수 없다면 그 대신 어떤 피드백 메커니즘을 제공해야 한다는 것이다. 일반적으로 좋은 사용자 피드백과 문제/애플리케이션/시스템의 복자성 사이에는 강한 상관관계가 있다.


11장 설치

287
사용성 전문가들이 컴퓨터나 기타 장치를 처음 접하는 어떤 사람의 경험을 설명하기 위해 OOBE(out of box experience: 첫인상)란 용어를 만들었다.

299
사용자는 매뉴얼을 읽지 않는다.

반드시 설치와 삭제 모두를 철저하게 테스트해야 한다.


12장 업그레이드

313
업그레이드 과정에서 고객의 데이터를 절대 폐기하지 않도록 하라.


13장 설정

323
설정은 사용성의 핵심적인 측면이다. (-설정용이성)


14장 로그

336
운영 효과와 로그 파일에 관련된 주변 환경을 검토하라. 디스크 용량 부족 같은 모든 오류 상황에 대처할 수 있는지 확실히 하라.


15장 출시관리

340
출시관리(release management)는 제품을 원하거나 필요로 하는 고객에게 올바른 제품이 전달되도록 보장하는 것이다. 출시관리는 그것을 보장하기 위해 제품을 식별하고, 조직화하고, 통제한다. 제품에 기술적인 라벨을 붙이고, 이들 라벨을 SKU나 제품 넘버를 이용해 적절한 백오피스 시스템에 통합시킨다.


16장 보안

359
소프트웨어 보안의 특별한 점은, 무언가를 쉽게 만드는게 아니라 어렵게 만든다는 것이다.

372
라이선스를 체크하기 위해 단지 Boolean 값을 리턴하는 코드를 사용하면 안된다.
단순한 예/아니오 질문을 던지는 대신, 애플리케이션 실행에 필요한 데이터를 암호화해서 서명된 라이선스에 저장하는 방식이 더 안전하다. 이런 작업을 초기화 루틴이나 애플리케이션의 서브 컴포넌트를 등록하는 루틴처럼 중요한 함수에서 수행한다.

375
보안을 달성하는 기술은 보통 공개된 수학적 알고리즘을 기반으로 한다. 또는 기초 로직이 공개된 알고리즘을 기반으로 한다.
비밀스런 알고리즘을 쓰면 안된다. (2차 세계대전 - 독일의 이니그마 머신) 일반적으로 모호함을 통한 보안은 가장 약한 보안 형태 중 하나다. 비밀스런 알고리즘이 밝혀질 수도 있고, 리버스 엔지니어링될 수도 있으며, 유출될 수도 있기 때문이다. 컴퓨터 성능이 놀라울 정도로 향상되면서, 어떤 알고리즘도 무차별 대입법(brute force)을 사용하는 크래킹 시도로부터 안전하지 않다.
알고리즘을 감추는 방법보다 좋은 선택은 공개된 알고리즘 중에서 훌륭한 것을 선택하는 것이다. 공개 알고리즘은 지속적인 검증 아래에 놓여 있다.
표준 알고리즘과 비밀키를 사용하라. 최소한 광자 컴퓨터(quantum computer)가 대중화되기 전까지, 당신은 안전하다.

376
백도어는 통상 형편없는 방식으로 구현되며, 아주 쉬운 해킹 대상이 된다. 결과적으로 보안상 아주 큰 시간과 노력의 손실을 초래한다.

377
일반적으로 시스템과 관련해 보안을 100% 보장하지 못한다면 아무 의미가 없다고 말한다. 보안을 보장하기로 했다면, 반드시 모든 것을 보장해야 한다.
"우리 소프트웨어가 정말 안전하기는 하지만, 당신이 원한다면 잠시 보안을 깨뜨리겠습니다"라고 말하면 안 된다. 그 대신, "우리는 당신의 실수로 인한 피해를 최소화하도록 돕겠습니다. 하지만 우리 소프트웨어는 너무 보안이 철저해서 우리조차도 그것을 깰 수 없습니다"라고 말해야 한다. 이것이 더 우수한 기술적인 메시지인 동시에 훨씬 우수한 마케팅 메시지다.