엉클 밥, 밥 아저씨의 클린 아키텍처를 1년에 걸처서 천천히 읽었다. 참 좋은 책이다. 천천히 보기에도 좋고 빨리 보기에도 좋다. 책의 내용에 맞게 책의 구조도 매우 신경 쓴거 같다. 책을 알게 되고 읽어봐야겠다고 생각했던것은 아키텍트 교육을 받을때였는데 이제서야 읽게 되어서 뒤늦게 읽었다고 했다. 표현은 그렇게 했지만 개인적으로 아키텍처에 대해서 진지하게 고민하게 되었을 때 읽게 되어서 천천히 음미할 수 있었고, 책에 나온 사례들에 대해서 더 잘 이해하고 공감 할 수 있어서 더 좋았다. 많은 사람들이 추천하는 책이고, 감명 받은 부분을 정리해놓은 국문 블로그 글도 많아서 그리고 원문 자체가 이미 워낙 간결하게 쓰여 졌기에 따로 정리해 둘 필요가 없을 것 같다. 그래서 블로그에 정리 대신 인상 깊었던 몇개의 내용을 나의 경험을 중심으로 적어볼까 한다. 책에 나온 내용을 내가 경험한대로 정리해서 지난 날을 돌아보려 한다. 흑역사를 통한 성장이랄까ㅎ

소프트웨어는 부드러운것

소프트웨어는 반드시 부드러워야 한다. 다시 말해 변경하기 쉬워야 한다.

책의 가장 앞부분에 나오는 이 한마디에 지난 세월 내가 만든 돌덩이 같은 소프트웨어들이 주마등처럼 머릿속을 스쳐지나간갔다.

나의 주니어 시절엔 아키텍처 어쩌고 저쩌고하는 사람을 접했을때는 솟구처 오르는 화와 함께 '그럴 시간에 새로 하나 만들어도 되겠다'는 생각을 했었다. 실제로 그맘때 내가 만지던 소프트웨어는 단순 유지보수 이상의 확장성을 제공하지 않는 것이 대부분이었다. 물론 새로운 프로젝트에 코드가 재사용되기도 하지만, 확장이나 리펙토링이라는 단어와는 전혀 어울리지 않았다. 그냥 그대로 복사되어 사용되거나, 호환성 따위 생각할 여징없이 새료운 요구사항에 맞게 다시 고쳐서 쓰는 수준이었다. 그것이 현실이었고 TDD 책을 보던 선구자 같던 선배는 얼마 안되서 퇴사하고 미국으로 유학을 떠났다. 그러한 나의 인식 수준은 꽤나 오랫동안 유지되었고, 갑작스럽게 조직이 변경되면서 연구소로 팔려가게 된 후에야 조금씩 생각이 바뀌게 되었다. 바뀌게 된 이유는 여러가지가 있겠지만, 절대적으로 물리적인 시간의 문제가 크다고 생각한다. 변명일지도 모르지만 사업부에 있을 때는 항상 잠잘 시간도 부족했고, 긴급한게 물 밀듯이 밀려오는 일을 처리하기에 급급했다. 대학 졸업 후 딱히 성장 할 틈도 없이 닥치는 대로 일만 하면서 수년을 보내면서 회의가 들기도 했는데, 어쩌면 그렇게 연구소로 팔려간게 참 잘된 일인것 같다. 연구소에 갔을때 처음 몇년은 이렇게 일하고 돈을 받아도 되는가 싶은 생각이 들 정도로 업무 시간이나 양이 줄었다. 하지만 신기하게도 업무양이 줄어든 만큼 성장에 대한 고민도 많이 하고, 시선을 바깥으로 돌려서 외부 기준으로 나의 위치를 평가하게 되고, 또 그 만큼 열심히 성장을 위해 노력하게 되었다. 그때는 내가 잘되야 회사가 잘된다라는 말을 주문처럼 항상 입에 달고 살았다. 내가 건강해야 회사가 건강하다. 내가 행복해야 회사가 행복하다. 나는 진심으로 회사를 위해 노력했다.

지금 생각해보면 사업부에서 상품화 코드를 작업하던 그 소프트웨어는 펌웨어에 가깝다. 실제로 단말의 소프트웨어 업데이트를 펌웨어 업데이트라고 했다.ㅋㅋ 지금은 스마트 폰이 되고 모든것이 변했지만 그 때는 그랬다. 상품화 막바지에 문제가 나오면 코드 한줄 고치는 것도 굉장히 부담스러운 일이었는데, 이제와서 보니 그렇게 변경할 수 없는 것이라면 하드웨어라고 했어야 하는것 아닌가 싶다. 물론 그때는 하드웨어 문제를 소프트웨어로 다 고친다며 하드웨어 팀에 엄청 생생내고 다녔다.ㅋㅋㅋ

소프트웨어는 급격히 변하는 기술이 아니다.

1946년 엘런 튜링이 사용한 소프트웨어 규칙은 여전히 유효하다. 컴퓨터 프로그램은 순차, 분기, 반복, 참조로 구성된다. 그 이상도 이하도 아니다. Sequence, Selection, Iteration, Indirection

소프트웨어 기술은 엄청나게 빠르게 발전하고 변하고 있는것 같은데, 그 중심의 핵심 규칙은 크게 달라지지 않았다.

어느날 후배가 술 먹고 하소연을 한다. 공무원이나 다른 회사 다니는 친구들 보면 입사해서 몇년 동안 배운 다음 그 뒤로는 경력 쌓으면서 여유롭게 일하는게 보통인데 개발자는 아주 공부하다가 죽어난다고 너무 힘들다고 했다. 나도 적극 공감했다. 아이폰이 새로 나오면 사람들은 열광하지만 누군가는 일주일에서 한달 가량 아이폰과 함께 공개된 기술들과 서비스를 공부하고 연구해서 발표하거나, 대응하거나 다음 프로젝트에 활용할 준비를 해야 한다. 구글 I/O도 있고, 아마존 Reinvent, 네이버 Deview, 카카오 if 등에서 새로운 기술들이 아주 쉼없이 공개된다. 물론 개발자들이 늘 새로운 기술을 사용하는 것은 아니지만, 새로운 기술을 계속 공부해서 현업에 적용하기 위한 준비를 해야 하고, 동시에 오래전에 익혔던 기술들은 구식이 되어 버리는 것이 현실이다. 그러다보니 고용시장에서도 경력 개발자의 주요 능력은 오랜 노하우가 아니라 당장 비즈니스에 필요한 요즘 기술을 잘 알고 잘 쓸 줄 아는 사람이다. 오~래된 노하우를 어필할 기회조차 별로 없다.

그렇다고 해서 경험 많은 개발자를 쓸모 없는 짐짝 취급해서는 안된다. 오히려 오래된 기술과 함께 최신 기술을 잘 연마한 노련한 개발자는 일당백 이상의 중요한 역할을 한다. 간단한 문제나 구현은 인터넷이나 커뮤니티를 검색해서 해결할 수 있지만, 전체 시스템에 대한 설계나 문제 대응, 환경 구성은 경험에 따라 역량이 크게 차이가 나기 때문이다.

앞서 언급한 것처럼 소프트웨어의 핵심 규칙은 크게 달라지지 않았다. 버그나 시장문제도 겉모습은 바뀌었을지 몰라도 근원적인 문제 원인은 매우 비슷한 모양을 가지고 있다. 경험 위에 새로운 기술을 받아드린 개발자는 프로그램 전반에 걸처서 중요한 시점에 반드시 빛을 발한다.

아키텍트는 선을 긋고 지키는 사람

소프트웨어 아키턱처는 선을 긋는 기술이며, 나는 이러한 선을 경계라고 부른다. 경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다.

이 책의 가장 큰 매력은 모호하고도 애매한 것을 굉장히 명확하게 설명한다는 것이다. JAVA나 C++, C# 등 다양한 세계에서 조금씩 의미가 다른 단어들 조차 미리 분명히 가정하고 설명을 시작한다. 아키텍처나 소프트웨어의 개변들도 분명하게 설명해주는데, 아키텍처에 대해서도 단호하게 선을 긋는 기술이라고 단정하고 있다. 아키텍처라는 것의 다양한 면과, 여러가지 예외 조건들도 모두 포함하는 다소 두루 뭉실한 설명을 할 수도 있을 텐데, 아주 단호하다. 어쩌면 그 단호함이 아키텍트의 덕목일지도 모르겠다. 프로젝트는 불분명한 것들의 연속일고, 예측하지 못한 문제들의 끝없는 시련을 상대해야 한다. 불확실성 속에서 당황스러운 것은 누구나 마찮가지 겠지만 누군가는 분명하게 선을 긋는 결정을 해야 한다. 때로는 그 선택에 대해서 쓰디쓴 댓가를 치뤄야 할 수도 있고, 다수의 의견에 반하는 외로운 선택을 홀로 지켜가야 할 수도 있다.

여기서 아키텍트를 고집스러운 불통 장군이라고 오해해서는 안된다. 선을 긋고 지키는 일을 혼자만 하는 것도 아니고, 자기 마음대로 긋는 것은 더욱 아니다. 아키텍트는 전체 아키텍처에서 선이 필요한 부분에 대해서 명확히 선을 긋고 팀원들이 아키텍처 설계에 맞게 개발 할 수 있도록 돕는다. 개발되는 모듈은 계속 크기가 커지는데, 팀원들이 각자 맡은 모듈을 개발을 하다가 전체 그림에서 선을 넘게 되는 경우를 잘 파악해서 선을 지킬 수 있게 해준다. 앞장서서 의사 결정을 하기도 하지만 이끌고 간다기 보다 팀원들이 더 잘 마음껏 개발 할 수 있도록 도와주는 역할에 가깝다. 내가 함께 일해 본 아키텍트는 겸손하고, 성실하게 팀원들이 개발에 매진할 수 있도록 해주면서, 필요할 때마다 탄탄한 실력으로 어려운 부분을 해결해 주어서 언제나 팀원들이 든든하게 기댈 수 있었다. 물론 설계 한다고 도형 몇개 그리고 이래라 저래라 공감도 안되는 룰만 엄청 만들면서, 자신의 기술 지식으로 팀원들 위축되게 만들어서 권위를 지키려는 사람도 있었다. 두 팀에서의 성과는 따로 설명이 필요없을 것 같다.ㅎ

테스트는 그저 시스템 컴포넌트일뿐

아주 작은 테스트이든, 아니면 대규모의 fitnesse, cucumber, specflow, jbehave 테스트이든, 이들 테스트는 아키텍처적으로 모두 동등하다.

좋은 아키텍처에 대한 이야기가 나올때 자주 이야기가 되는 것이 TDD와 테스트이다. 테스트하기 좋은 구조가 좋은 아키텍처라는 사실에는 많은 개발자들이 공감을 표하지만 꼭 테스트하기 좋아야만, 높은 테스트 커버리지를 유지해야만 하느냐에 대해서는 많은 논란이 있는 것도 사실이다. 단위 테스트와 TDD의 효용성과 거부감에 대한 이야기도 늘 심심찮게 접할 수 있다. 사실 나도 제작년에 비슷한 경험을 했다. 리더가 제품 레벨에서 인수 테스트를 갖추자고 해서 내가 엄청나게 반발했다. 우리는 제품 레벨의 기기를 가지고 있지도 않고, 단지 실제 제품에 사용될 라이브러리를 개발하는 것인데, 제품 레벨의 통합 테스트를 넘어 에이징 테스트까지 하자고 했다. 나는 나름 아키텍트 역할을 수행하고 있다고 생각해서 단호하게 거절했고, 그보다 무분별하게 추가되는 코드들의 리뷰가 더 중요하다고 했다. 에이징 테스트는 어떻게 막았는데, 이번에는 단위 테스트에다가 통합 테스트 내용을 추가하기 시작했다. 그것도 반복 수행 횟수까지 고정해서 추가하는 바람에 커밋을 하나 작성하고 테스트를 돌려보면 20분이 넘게 소요되었다. 삼천라인도 안되는 간단한 프로그램인데, curl get으로 json 데이터를 가져와서 파싱하는 로직을 열번씩 매번 테스트한다. 그것도 테스트 서버에 직접 물려서 테스트를 하는 바람에 false alert까지 많이 발생했다. 그 때 내가 Mock을 써서 테스트를 분리하고 통합테스트는 통합 서버에서 돌리고, 개발자는 간단한 단위 테스트를 돌리게 하자고 했지만, 테스트에 리소스를 더 쓰려면 에이징 테스트를 만들자고 했다. 설득에 실패한 나는 그 단위 테스트에 고통 받으면서 천천히 다른 모듈을 개발하는 수 밖에 없었다. 한번 수정하면 무조건 20분짜리 테스트를 돌려야 했으므로… 나중에 알게된 사실은 리더가 프로젝트 보고 자료에 단위 테스트, 통합 테스트 커버리지와 갯수를 넣고 TDD를 사용해서 안정성을 높였다고 어필하는 내용으로 파워포인터를 만들어서 제출했다는 것이다.

시간이 지나면서 나는 몇 번을 그 프로젝트에 대해서 다시 생각해 보면서 고민을 해 봤다. 테스트 말고도 여러 문제가 있었지만, 테스트에 대해서 나의 잘못이 크다. 단위 테스트에 Mock을 사용하는 이유에 대해서 적절하게 설명하고, 설득하지 못 했을 뿐만 아니라 단위 테스트와 통합 테스트의 분리는 무리하게 요구해서라도 진행을 했어야 한다. 그리고 에이징 테스트나 인수 테스트를 왜 개발팀에서 하냐고 거부했지만, 프로젝트를 인수할 팀에서 필요가 있다면 차라리 멋있게 잘 만들어서 확실한 장점으로 삼았어도 좋았을 것이다. 유연하지도 못했고 적극적으로 상황을 개선하지도 못했던 내 모습을 반성한다.

이 책에서는 테스트에 대한 많은 이야기를 하지 않고 있다. 하지만 테스트의 설계도 아키텍트가 중요하고, 테스트 역시 비용이 중요하다는 것을 분명히 하고 있다. 테스트 역시 시스템의 일부라는 것은 분명한 사실이고, 아키텍트라면 응당 테스트의 구조에 대해서도 관심을 갖아야 한다. 개발자들이 주로 사용하는 단위 테스트를 구분했어야 하고, 단순히 커버리지와 테스트 시간을 늘리는 것보다 효용성을 고려한 테스트를 구성했어야 한다. 무엇보다 단위, 통합, 인수 이런 용어에 집착하지 말고 열린 마음으로 상황에 맞게 필요한 테스트를 갖추는 데에 주저하지 말았어야 했다.

클린 아키텍처의 HAL

HAL을 제대로 만들었다면, HAL은 타깃에 상관없이 테스트할 수 있는 경계층 또는 일련의 대체 지점을 제공한다.

공감하지만 그 길이 결코 쉽지 않다는 것을 꼭 말하고 싶다. 그렇게 하면 좋고, 하고 싶기도 하지만 비용이 만만치가 않다. 실제로 대체 지점을 사용하는 것보다 테스트용 타깃을 사용하는 것이 비용이 더 적은 경우가 많다. 타깃과 독립적으로 테스트 환경을 갖출 수 있는 것은 분명한 장점이지만 타깃을 대체하는 방법은 타깃이 물리적으로 떨어져 있다거나 사용이 쉽지 않은 경우 매우 요긴하게 사용할 수 있겠지만 타깃의 규모나 제작 비용이 적고 테스트 환경 구성이 어렵지 않다면 적절하게 타협해서 타깃을 사용하는 것도 좋다고 생각한다. 테스트가 그랬듯이 불필요한 원칙이나 규칙을 강조하기 보다는 최종 목표를 위해 유연하게 적용하는 것이 좋다고 생각한다.

좋은 소프트웨어는

이러한 소프트웨어는 올바르게 정의된 경계, 명확한 책임, 그리고 통제된 의존성을 가진 클래스와 컴포넌트로 구성될 것이다.

역시나 간결한 문장으로 단호하게 설명한다. 좋은 소프트웨어의 조건으로 여러가지를 논의할 수 있겠지만 밥 아저씨는 분명하게 비용을 중심으로 이야기한다. 혼자 개발하는 것이 아니고, 함께 개발하는 프로젝트를 중심으로 이야기 한다. 한번 개발하고 끝나는 것이 아니라 상황에 유연하게 대처하는 것을 중심으로 이야기 한다. 좋은 소프트웨어 아키텍처에 대해 정답이 있는 것은 아니지만 적어도 위와 같은 기준으로 볼 때 좋은 아키텍처는 올바른 경계, 명확한 책임, 통제된 의존성을 갖는 형태일 것이다.

개발자라면 알고리즘이나 코딩 대회에서 실력을 겨루고 순위를 매기는 일이 익숙할 것이다. 종종 그 순위에 따라 개발자의 능력이 평가되기도 하는데, 클린 아키텍처에서 말하는 좋은 소프트웨어 개발자는 다른 능력이 더 필요하다. 요구사항을 잘 파악해야하고, 컴포넌트 간의 관계를 이해해야하고, 경계를 지키면서도 책임감 있게 동작하는 모듈에 대한 통찰력을 갖고 개발할 수 있어야 한다. 전자가 전술이라면 후자는 전략이라고 볼 수 있을 것 같다. 둘 다 중요하다. 싸움의 기술도 중요하지만 전쟁은 혼자 싸우는 것이 아니다. 소프트웨어는 혼자 만드는 것이 아니다. 심지어 혼자 만드는 소프트웨어 조차 시간이 지나고 나면 이걸 내가 만들었던가 싶을 때가 많다. 역시 내가 잘 만들어놨구나 싶을 수도 있지만 누가 이따위로 만들어 놨나 생각이 들수도 있다. 누가 언제 개발에 참여해도 쉽게 유지 보수하고 확장할 수 있어야 비용을 절약할 수 있다.

경험에 비춰볼 때, 알고리즘은 이미 공개된 것을 가져다 쓰면 되기에 실제 프로젝트 개발에 큰 영향이 없다는 의견도 있고, 아키텍처 운운하며 그림이나 그리는 일이 개발에 도움이 안된다는 의견도 있다. 각자의 경험에 기반한 의견이기에 맞고 틀리다는 판단을 하고 싶지는 않다. 다만, 소프트웨어가 동작하는 핵심 원리부터 구조 그리고 그 소프트웨어가 동작하는 환경과 사용자에 대한 통찰이 바탕이 되어야 좋은 소프트웨어, 훌륭한 소프트웨어를 만들 수 있다. 따라서 알고리즘도 잘 알아야 하고, 아키텍처에 대한 이해도 높아야 한다.

아키텍처가 전부는 아니다

아키텍처? 나랑 장난하냐? 여긴 스타트업이야. 우리에게 아키텍처를 생각할 시간은 없어. 코드만이 전부야. 제기랄! 살고 싶으면 코딩뿐이야!

책의 부록으로 실린 부분인데 아주 재미있게 읽었다. 아키텍처 고고학이라는 제목 아래 저자의 개인적인 경험을 풀어 놓았는데, 흥미로운 이야기가 많았다. 밥 아저씨라고 해서 진짜 아저씨인줄 알았는데, 내가 태어나기도 전부터 코딩을 하셨다. 생각보다 엄청난 할아버지였다. 영화에서나 보던 그런 기계 장치로 코딩을 하셨고 그때부터 지금까지 소프트웨어를 만지고 계시다니, 소프트웨어의 뭔가 첨단 기술 같은 느낌과 어울리지 않는 이질적인 느낌이 들었다. 그 옛날에도 스타트업이 있었고, 거기에도 죽어라 코드를 만드는 문화가 있었나 보다. 나는 대기업에 있음에도 아키텍처의 비용애 대해서 많은 도전적인 질문을 받는다. 내가 창업을 하면 어떻게 될까. 내가 사장이라면 어떻게 할까. 늘 고민해본다. 결국 창업하게 될 것이기에.ㅎㅎㅎ

내가 사장이라면 제품의 일정, 시간 앞에서 조금은 망설이게 될지는 몰라도 아케텍처를 포기하고 개발에 몰두하지는 않을 것 같다. 그렇다고해서 대기업에서 하듯이 할 수는 없을것 같다. 책에서 말하고 있듯이 어째든 아키텍처는 비용을 줄이기 위함이기에 아키텍처에 대한 투자도 비용으로 함께 산정해야 한다고 생각한다. 그런 역할까지 잘 해낼 수 있는 아키텍트가 필요하고, 아키텍트 마인드를 가지고 있는 개발자가 필요하다. 특히, 구성원들의 능력과 문화가 잘 잡혀있다면 아키텍트를 위한 별도의 노력 없이도 좋은 코드들이 생상될 수 있다고 믿는다. 단기적으로 코드의 양을 늘리는 것이 아니라 좋은 구조를 유지함으로써 비용을 줄이는 방법이기에 전체적인 관점에서 평가가 필요하며, 자연히 전체 프로젝트에 대한 충분한 이해를 바탕으로 평가되어야 한다. 빨리 많이 개발하기 위한 코드 작성량이나 근무 시간 따위의 지표 관리는 잘못된 판단의 시초가 될 수 있다고 생각한다.

파워 포인트 DJ

코드는 한 줄마다 최소한 하나의 설계 원칙을 포함하고 있고, 따라서 코드를 작성하는 사람이 파워포인트 DJ인 나보다 소프트웨어 품질에 훨씬 큰 영향을 줄 것이기 때문이었다.

맺는 말에서 발췌한 것인데, 밥 아저씨의 위치가 변함에 따라 코드를 작성하기보다는 아키텍처에 관련된 문서를 작성하는 일이 많아졌다고 이야기 하고 있다. 다행이도 에자일과 같은 시도가 문서 작성보다는 코드 작성에 더 집중하고 문서가 필요했던 부분들 조차 가능한 코드로 대체할 수 있게 해주었고, 아저씨 역시 파워포인트 DJ로부터 벗어날 수 있게 되었다고 한다. 공감이 많이 되는 부분이었다. 내가 속한 곳도 조직의 상층부로 갈 수록 파워포인트의 힘이 강해지고, 자연스레 파워포인트 디제잉 능력이 중요해진다. 물론 그 중에도 파워포인트의 껍데기보다 컨트체에만 집중하는 피보고자도 있고, 동작하는 프로그램을 기반으로 설명해 달라는 분도 계셨다. 회의가 끝나고는 직접 소스 저장소에 접근해서 훑어 보는 임원도 종종봤다.

반면, 아에 대놓고 파워포인트 DJ를 자처하는 사람도 있었다. 일주일 내내 발표에 사용될 파워 포인트를 손본다. 물론 관련된 코드는 보지 않는다. 심지어 공식자리에서 자기는 코드는 안본다고 텍스트로라도 정리해서 자기한테 보고를 해야 본인의 성과를 확인할 수 있지 코드 작성으로는 뭘하는지 모른다고까지 말했다. 내 귀를 의심했고, 그 팀을 떠나야 겠다고 결심했다. 회의나 보고가 주 업무인 임원도 아니고 열댓명으로 구성된 개발팀의 리더가 그렇게 행동한다니 나머지 개발자들은 황당하기 그지 없었다.

내가 받은 모든 아키텍트 교육에서 현업을 강조한다. 아키텍트는 코드도 직접 접해야 하고, 사용자 분석도 직접 접해야 한다. 코드가 작성되는 형장에서 아키텍트가 가장 강력하게 영향력을 발휘할 수 있고, 사용자를 직접 만나서 이야기를 들을때 감춰진 요구 사항과 기능간의 우선 순위 등을 파악할 수 있다. 기존의 회사 조직에서 리더들의 모습과는 분명 다른 점이 있다. 아키텍트가 리더인 개발팀이라면 더없이 좋겠지만, 상황에 따라서 아키텍트의 자리와 권한을 위임할 수 있어야 한다. 물론 경험상 리더가 순수하게 위임해서 잘 운영되는 경우가 드물다. 우리나라에서는 특히 조직상 서열을 굉장히 중요하기 때문에 그런것 같은데...그런것을 모두 감안한다면 역시 개발팀은 아키텍트를 리더로하는 팀을 꾸리는 것이 최선이라고 생각한다.

마치며

오랜만에 꼼꼼하게 읽어도 지루하지 않은 책을 읽었다. 지난 날의 나의 개인적인 개발 역사가 주마등처럼 지나가는 것 같아서 부끄럽기도 했고 각오를 새롭게 하게 되었다. 고백하건데 나도 아키텍처 입에 올리는 사람을 싫어하는 사람 중 하나 였다. 뒷짐지고 이래라 저래라 하는 사람이라는 생각에 괜히 거부감을 가졌던것 같다. 그것은 나의 무지와 오해에서 비롯한 것이었다. 지금은 누구보다 아키텍트들을 존경한다. 적어도 내 주변에 아키텍트라고 불리는 사람은 오랜 경험과 뛰어난 능력, 겸손하고도 성실한 인품까지 두루 갖춘 사람들이 많기 때문이다.

마지막으로 아키텍처가 왜 논의 되어야 하는지 간결하게 정의한 밥 아저씩의 한 문장을 남겨본다. 아키텍처는 아는척하고 품잡으려는게 아니라 효율을 위한것이었다.

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는데 있다.