오늘 리뷰할 책은 개발자에서 아키텍트로 라는 책이다.

뭔가를 만들때 어떤 구조로 개발할지에 따라 생산성과 퍼포먼스나 여러가지 요소가 결정된다. 이 책에서는 단순 개발자에서 소프트웨어 아키텍트가 되기까지 필요한 다양한 지식들과 실무적인 방법과 노하우를 알려주는 책이다.

디자인 띵킹부터 시작해서 다양한 방법론과 사례들을 소개해준다. 그래서 그런지 생각보다 책이 그렇게 읽기 힘들지 않았고 수월하게 읽을 수 있었다.

​

책 구성이 좀 특이한게 약간 교과서 처럼 되어있다. 개념을 알려주고 그에 대한 평가와 사례연구들, 마지막 요약으로 구성되어 있다. 읽는데 크게 무리 없이 내용을 계속 정리해갈 수 있어서 도움되었던 것 같다.

​

가끔 이걸 어디서부터 어떻게 해야할지 막막할때가 가끔 있었는데, 그럴때가 생긴다면 여기서 배운 기법들을 사용해서 정리하고 설계해보면 될 것 같다.

​

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

​

책의 특징

책에 대해 소개하기 전에, 우선 본인은 주니어 개발자의 시각으로써 해당 책을 읽었음을 전하고 싶다.
소프트웨어 아키텍트가 되기 위한 주제이기 때문에, 소프트웨어 아키텍트로써의 관점, 주니어 개발자로써의 관점, 팀/기술 리더로써의 관점에서 보는 것이 다 다를 수 있기 때문이다.

이를 감안하고 주니어 개발자로써 본 책은 아래의 특징은 이러하였다.

[책의 설명 방식]
해당 책은 주제가 주제인 만큼, 소프트웨어 아키텍처로써 어떤 것들을 고려해야하는지, 어떻게 관리해야하는지 등을 기술하고 있다.

그렇기 때문에, 책의 내용은 이론적인 면이 많을 수 밖에 없다. 그런 상황에서 최대한 해당 내용이 왜 중요한지,
"~~이렇게 힘들기 때문에, ~~게 하면 안좋고, ~~여야 이러한 장점이 있다." 이러한 설명들로 독자들을 이해시킨다.

물론 이를 포함하여 그 후에 나오는 이론적인 내용들까지 설명들은 더할 나위 없이 친절하고 설득적이다.

설명들이 재미있고 매우 잘 읽히는 수준까지는 아니지만, 주제가 주제인 만큼 그 안에서는 최대한 밸런스를 맞춘 느낌이 들었다

소프트웨어 프로젝트를수행해 본 사람이라면 그 험난한 과정과 다양하게 발생하는 문제의 역동성을 익히 알고 있을 것이다. 프로젝트를성공적으로 이끌기 위해 많은 연구가 있어왔고, 여러 방법론의 형태로 프로젝트 수행에 대한 가이드라인과지침을 제시하고 있다. 대상 시스템과 목적, 기능은 다 제각각이지만프로젝트를 수행하는 주체는 사람이고, 그 프로젝트에 참여하고 있는 사람들이 어떤 역할을 하느냐에 따라프로젝트의 성패가 결정된다고 해도 과언이 아니다.

소프트웨어의 개발에는코딩이 필수적이지만, 코딩만 잘 하는 사람만으로는 소프트웨어 프로젝트가 성공하기 어렵다. 프로젝트를 성공으로 이끌기 위해서는 프로그래밍뿐 아니라 엔지니어링 관점에서 문제를 제기하고 이를 관리할 수있어야 한다. 이를 맡는 것이 소프트웨어 아키텍트이다. 소프트웨어아키텍트는 여러 이해관계자와의 협업을 통해 비즈니스 목표 달성을 위해 노력하고, 프로젝트의 큰 그림을그리며, 소프트웨어 설계에 있어 이상과 현실 사이의 균형을 찾는 부단한 싸움을 하고, 기술 부채를 관리하며, 팀 전체의 설계 역량을 키우는 역할을 수행한다.

소프트웨어 프로젝트에참여하는 개발자가 아키텍트로서의 안목과 역량을 갖게 되면 그 프로젝트의 성공 가능성은 매우 높아질 것이다. 마이클킬링의 ‘개발자에서 아키텍트로’는, 책 제목처럼 개발자가 아키텍트로 성장하는 과정을 담고 있다. 더나은 개발자, 아키텍트가 되기 위해 필요한 설계 원칙과 적용 방법, 설계자다운사고방식과 인간중심적인 접근 방법, 팀원과 협업하며 소프트웨어를 설계하는 방법 등을 통해 더 나은 소프트웨어를만들고, 프로젝트를 성공으로 이끄는 아키텍트로 성장하도록 돕는다.

책은 크게 세부분으로 구성되어 있는데, 1부에서는 소프트웨어 아키텍트와 소프트웨어 아키텍처에 대해 다룬다. 2부는 아키텍처를 설계하고, 이해관계자와 소통하고, 핵심 요구사항을 분석하여 설계에 반영하는 방법과 함께 아키텍처 패턴과 설계를 시각화하고 문서화 하는 방법에대해 알아본다. 끝으로 3부에서는 아키텍처 설계에 도움이되는 38가지 팀 활동을 소개한다.

복잡한 소프트웨어아키텍처를 실제 상황에 적용할 수 있도록 쉬운 언어로 잘 설명하고 있어 소프트웨어 엔지니어링 훈련에도 유용하다.아키텍트가 되고 싶은 개발자 뿐 아니라 팀의 생산성을 높이는 활동을 하고 싶은 이들에게도 추천한다.

**한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

1. 이번에 읽게 된 책은 ‘개발자에서 아키텍트로’입니다. 기획자를 위한 책이 아니데, 한빛미디어 <나는 리뷰어다>에서 신청 가능한 책들 중 읽어보면 기획서를 쓸 때 도움이 되겠다 싶어서 신청 했는데 선정되어 읽어볼 수 있게 되었습니다. 프로그래머가 아니다 보니 책의 내용을 완전히 이해할 순 없었지만 ‘개발자에서 아키텍트’라는 제목에서 말하는 아키텍트(Architect)라는 것이 기획과 유사한 부분이 있어 개발을 이해하는데에는 도움이 되었습니다.

2. 책 ‘개발자에서 아키텍트로’는 크게 3개 파트로 나뉘어져 있습니다.

- Part 1. 소프트웨어 아키텍처

이 책의 첫 파트이기도 한 ‘소프트웨어 아키텍처’는 소프트웨어 아키텍처의 업무와 역할에 대한 이야기를 먼저 꺼냅니다. 도입부로 이 책이 말하고자 하는 소프트웨어 아키텍처에 대해 일목요연하게 설명하고 있습니다. 뿐만 아니라 아키텍처가 어떤 식으로 사고를 하는지 ‘디자인 싱킹 기초’라는 부분을 할애해 설명해주는데, 개념적으로 쉽게 접근할 수 있도록 이해를 돕습니다.

- Part 2. 아키텍처 설계의 기초

‘아키텍처 설계의 기초’는 문자 그대로 아키텍처가 소프트웨어 설계를 위한 기초 단계에서 해야 할 것들을 이야기합니다. 설계 계획을 어떻게 세울 것인지, 이를 이해관계자들과 공감하여 설득시키는 방법과 스펙(요구사항)을 알아내고 이를 운영해나가는 과정에 필요한 것들(아키텍처 선택, 기초 설계, 복잡도 관리 모델, 설계 시각화, 문서화, 평가)을 각 챕터로 구분하여 설명합니다.

- Party 3. 아키텍트의 은빛 도구상자

마지막은 은빛 도구상자라는 표현처럼 아키텍트가 어떤 문제를 직면했을 때 이를 해결하기 위한 다양한 방법론을 제시합니다. 1) 문제를 이해하고 싶을 때, 2) 해결책을 찾고 싶을 때, 3) 손에 잡히는 설계를 만들고 싶을 때, 4) 설계 대안을 평가하고 싶을 때. 4가지 상황에 각각에 활용할 수 있는 방법을 6~10개씩 제시함으로써 자신에게 맞는 방법을 찾거나, 이를 융합해 자신만의 방법을 만들어낼 수 있을 듯 합니다.

책은 단순히 활자로만 가득한 것이 아니라 도표를 적극 활용해서 프로그래밍에 대한 이해도가 낮은 제가 보더라도 어느 정도는 아키텍트의 역할과 필요성, 그리고 실제 어떤 일을 하는지 이해할 수 있을 정도로 쉽게 설명됩니다. 무엇보다 사례를 예시로 들어 챕터 마지막마다 이야기를 해주어서 마치 실제 아키텍트가 일하는 과정을 경험해볼 수 있는 느낌을 줍니다.

3. 아래는 제가 책을 읽어보고 (기획자로서) 인상 깊었던 구절들을 정리한 것입니다.

- 넓은 의미로 보면 시스템은 기술만 의미하지 않습니다. 사람, 프로세스, 비즈니스 요구사항, 그리고 다양한 기술, 비기술적인 의미가 소프트웨어 시스템에 뒤섞여 있습니다. 아주 간단한 설계라도 결과에 광범위한 영향을 줄 수 있습니다. 아키텍트는 작은 설계 결정 사항이 가져 올 미래도 예측하면서 넓은 의미의 시스템 관점도 가져야 합니다.

- 문제를 이해하려면 이해관계자들이 중요하게 생각하는 비즈니스 목표와 품질 속성도 조사해야 합니다. 그리고 어떻게 팀을 운영하고 설계할 때 트레이드오프와 우선순위를 결정하는지도 배워야 합니다.

- 제약은 이미 정해져서 변경이 불가능한 설계상의 의사결정을 의미합니다. 아키텍트 스스로 선택해서 만드는 제약도 있습니다. 대부분의 소프트웨어 시스템은 제약이 그리 많지 않습니다. 제약은 선택지를 줄이지만, 잘 선택된 제약은 문제를 단순하게 만들고 이로써 만족스러운 아키텍처가 나오기도 합니다. 하지만 때로는 요구사항을 도저히 충족시키지 못하는 지옥을 만들기도 합니다.

- 아이디어를 공유하는 최선의 방법은 아이디어를 손에 잡힐 듯하게 만드는 것입니다. 아키텍처를 개념적으로만 이야기하면 대부분 이해하지 못합니다. 하지만 아키텍처를 보여주면 보는 사람이 자신의 이해력에 맞추어 스스로 탐색하고 이해할 수 있습니다. 개발자들은 잘 알고 있습니다. 아직 구체적이지 않은 아이디어를 이야기할 때는 화이트보드 앞에 서서 스케치하면서 이야기하면 좋습니다. 아이디어를 그리기 시작하면 상상의 눈높이가 맞춰집니다.

- 아무것도 기록하지 않은 상태에서는 모든 요소가 다 명확하다고 믿곤 합니다. 하지만 펜을 들고 종이에 적는 순간 얼마나 생각이 모호했는지 깨닫습니다. 아키텍처를 명세서로 옮겨야만 아이디어를 더 단단하게 만들 수 있으며, 무엇을 아는지, 무엇을 안다고 착각했는지, 무엇을 모르는지 제대로 파악할 수 있습니다.

4. 아키텍트라는 것이 소프트웨어 아키텍트만 있는 것은 아닙니다. 모든 일이든 팀으로 하는 일이라면 실제 작업에 들어가기 전에 실수나 실패를 최소화하기 위한 계획들을 세우게 되는데 책 '개발자에서 아키텍트로'는 이 설령 프로그래밍을 하는 개발자가 아니더라도 계획을 수립하고 실제 수행하는 과정에서 유용한 팁들을 많이 제공하고 있습니다. 소프트웨어 아키텍트를 목표로 하거나 하게 된 사람들 뿐만 아니라 그들이 일하는 방식, 혹은 IT 업계에서 일을 하고 있는 사람이라도 업계에 대한 지식을 넓히는데 도움이 될 수 있는 책이라 판단합니다.

이번에 리뷰한 책은 "개발자에서 아키텍트로" 라는 책입니다.

아키텍트는 말 그대로 설계를 담당하는 직무로, 건축물을 설계하고 그 설계대로 공사를 하듯

프로그램도 설계를 하고 그 설계대로 프로그래밍을 하게 됩니다.

흔히 말하는 코딩은 아키텍트가 만들어 놓은 개발문서 혹은 설계문서를 토대로 프로그램을 만들어나가는 과정입니다.

즉, 아키텍트는 프로그램의 설계도면을 그리는 과정을 담당하며, 개발자는 벽돌을 직접 쌓아가며 프로그램을 만들어나가는 사람입니다.

대부분의 사람들을 개발자에서 시작하여 아키텍트까지 커리어를 쌓아가며 차근차근 나아갑니다.

저도 마찬가지로 개발자 3년차이며, 아직 개발자로서도 미숙하지만 어쩌다보니 아키텍쳐도 일부 담당해야하는 상황이 왔습니다.

그 때 때마침 이 책을 읽게 되었고, 막막히기만한 아키텍쳐라는 앞날에 어느정도 로드맵을 잡아볼 수 있었습니다.

이 책은 크게 3파트로 나누어져 있습니다.

첫번째 파트는 소프트웨어 아키텍트가 무엇인지 소개하는 파트이며,

두번째 파트는 본격적으로 소프트웨어 아키텍쳐를 설계하고 고객과 소통하며, 팀원들과 프로젝트를 해쳐나가는 직접적인 과정을

이론을 바탕으로 설명해주는 파트이며,

마지막으로 세번째 파트는 실제 프로젝트 팀에서 실행해볼 수 있는 활동들을 제시해주고 방향을 잡을 수 있도록 도와주는 파트입니다.

현재 첫번째 파트와 두번째 파트 까지 아주 재미있게 잘 읽었고, 세번째 파트는 아직 읽는 중이며, 

책에서 제시한 활동들은 아직 실행보진 못하였지만, 만약 헤드아키텍트가 된다면 꼭 팀원들과 함께 진행해보려고 합니다.

개발자에서 아키텍트로 전향하고 싶으신 분, 이제 막 아키텍트가 되어 무엇을 해야 하는지 방황하시는 분들께 강력 추천하는 책입니다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

한 줄 요약 : 하드스킬과 소프트스킬 개발에 좋은 참고서

이 책은 회사에서 기능 개선 할 때 유용하게 봤던 책이다.

기능 개선은 고려해야 하는 부분은 크게 세 가지가 있다.

1. 현재 기능의 동작을 보장할 것


2. 고객사/내부 직원의 개선/수정 요구사항을 반영할 것


3. 향후 시스템 개선에 문제가 없도록 시스템을 구성할 것

시스템 개발 초기에는 기능 수정이나 추가할 때 큰 부담이 없다.

시간이 흐르며 시스템 코드는 복잡해지고, 기능 추가/수정은 어려워지기 시작한다.

복잡도가 높아진 것이다.

이런 상황에서 문제가 생긴다면 개발자로서, 제품의 담당자로서(=고객사 문의 담당자) 두 가지 역할을 병행하게 된다.

이런 고민을 해결하기위해 팀장님께 도움을 구하고, 선배에게도 도움을 구했지만 정답은 없었다.

사용자/담당자마다 바라보는 시각이 다르고, 원하는 것도 달랐기 때문이다.

결국 기능 개선의 담당자는 다른 선배 개발자와 팀장님이 리드하게 됐다.

하지만 잠깐동안 막막함을 느끼고 있을 때 이 책은 이런 답답함을 느낄 때 좋은 참고서가 되었다.

<개발자에서 아키텍트로>는 마이클 킬링이 쓴 <Design It!>의 번역서다.

부제에 ‘38가지 팀 활동을 활용한 실전 소프트웨어 아키텍트 훈련법’이라고 되어 있다.

내가 생각하는 아키텍트(또는 시니어 개발자)는 기술적인 능력인 하드스킬뿐만 아니라 소프트스킬이 중요하다. 기술 관점과 사용자 관점을 동시에 고려해야 아키텍처라는 하나의 시스템을 디자인 할 수 있기 때문이다.

특징 1. 아키텍처 패턴을 학습할 수 있다.

한 회사/서비스를 개발하다보면 어떤 아키텍처가 좋을지, 신중하게 선택한 아키텍처를 어떻게 적용해야할지 막막함을 느낀다. 하지만 지금까지 수많은 소프트웨어들이 개발되었기에 어느정도 정형화된 구조가 생겼고, 이런 정형화된 구조를 '패턴'이라고 한다. <개발자에서 아키텍트로>의 CHAPTER 7 패턴으로 기초 만들기에서 10가지의 샘플 패턴을 설명해준다.

10가지의 패턴의 특징과 장단점, 구성을 학습하며 개발하려는 시스템에 적합한지 고민해보기 좋다. 

특징 2. 사례 연구를 통해 이미지 트레이닝을 할 수 있다 

각 챕터의 마지막에는 '사례연구 : 라이언하트 프로젝트'를 통해 실제로 프로젝트에 적용했을 때 이야기를 를 통해 엿볼 수 있다. 지루한 이론만 다루는 것이 아니라서 읽으면서 재미있었고, '이런 상황이 있을 수 있겠구나'하는 생각도 해볼 수 있었다.

특징 3. 팀에 적용가능한 활동과 도구를 소개한다

<개발자에서 아키텍트로>는 책 전체에서 시스템 설계를 위한 목표 설정, 요구사항 분석, 실제 참고할 수 있는 아키텍처 패턴, 협업 및 문서화를 위한 방법과 활동, 인수인계까지 A to Z를 알려준다. 그리고 책의 후반부에선 위의 활동들을 할 때 적용하면 좋은 도구와 활동 35가지를 소개한다.

이론을 알더라도 이것을 팀원들과 원만하게 적용할 수 있을지 여러 활동들을 보며 고민해볼 수 있다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

리뷰를 위해 한빛미디어에서 책을 제공받았지만 주관적인 생각을 그대로 적었습니다.

현업의 개발자들도 알면 도움이 되는 다양한 아키텍처들이 쉽게 서술되어 있습니다.

소프트웨어 아키텍트?

보통 개발자를 소프트웨어 엔지니어라고 부르는 것으로 알고 있습니다.

개발자로 처음 일을 하게 되면 소프트웨어 설계보다는 기능 구현에 초점을 맞추어진 업무들을 받게 됩니다.

그렇게 기능 구현을 해 나가다 보면 만들고 있는 프로젝트의 구조를 하나하나 보게 되고 결국엔 전체적인 구조를 알게 될 것입니다.

전체적인 구조를 알게 되면 감탄을 할 수 도 있고 개선할 부분이 보일 수 도 있습니다.

이는 숲 그림에서 나무 하나를 확대해 본 상태에서 점점 축소하여 많은 나무들이 곧 숲으로 보이게 되는 것과 비슷하다고 생각합니다.

그렇게 소프트웨어 엔지니어에서 점진적으로 아키텍트가 되어 가는 것이지요.

그렇지만 개발 실력도 정량적일 수 없듯이 설계 실력도 정량적일 수 없다고 생각합니다.

그 이유는 소프트웨어에 정답은 없고 해결해야 될 문제와 그것을 처리하기 위해 주어진 시간, 자본이라는 제한이 있고 그 속에서 최선과 차선, 그리고 효율을 따져 상황에 맞게 설계할 수밖에 없기 때문입니다.

위에서 말씀드린 부분은 개발과 설계에 대한 부분뿐입니다. 이것이 제가 알고 있던 아키텍트였고 제가 가고자 하는 길이었습니다.

그런데 이 책을 보고 안 그래도 험난해 보였던 산이 눈앞을 막고 눈을 멀게 하는 듯한 벽처럼 느껴지게 되었습니다.

그 이유는 소프트웨어 아키텍트가 하는 일의 범위가 엄청났기 때문입니다.

저자가 말하는 소프트웨어 아키텍트가 하는 일을 나열해 보겠습니다.

1. 
   엔지니어링 관점에서 문제 정의하기
   


2. 
   시스템은 분리하고 책임은 위임하기
   


3. 
   큰 그림 그리기
   


4. 
   품질/속성의 트레이드오프 고려하기
   


5. 
   기술 부채 관리하기
   


6. 
   팀의 아키텍처 설계 역량 키우기
   

사실 이 목록을 보고 떠오른 것은 CTO였습니다.

정답이 없는 일들도 있고 자신만이 아닌 팀 전체를 고려해야 하는 일도 있습니다.

정말 쉽지 않은 일들만 있지만 이 책 "개발자에서 아키텍트로"를 보신다면 걱정하시지 않아도 될 것 같습니다.

그 이유는 저자가 타칭 소프트웨어 아키텍트이며 수많은 경험을 토대로 단계적으로 설명해주기 때문입니다.

또한 개발, 설계뿐만이 아니라 팀 단위, 프로젝트 단위 등 다양한 위치에서 어떤 식으로 생각하고 행동하면 아키텍트에 가까워질 수 있는지 까지 실 사례를 통해 배울 수 있습니다.

어떻게 보면 커리어 스킬과 소프트 스킬을 합쳐놓은 책이라고도 볼 수 있겠네요.

저자의 노하우가 아주 많이 담긴 책이지만 방법론(?)이 그렇듯 알고 있는 것과 내 상황에 적용하기는 하늘과 땅 차이입니다. 그나마 이 책이 추상적이지 않고 실천해 볼만한 것들을 설명해주기 때문에 해볼 만한 것 같습니다.

그러니 꼭 읽고 괜찮은 내용이 있으시다면 우리 팀에는 어떻게 적용할 수 있을지 고민해보고 혼자가 어렵다면 팀원, 팀장님께 한 번 함께 해주시기를 요청드려보는 것은 어떨까요?

100%를 목표로 하는 것도 좋겠지만 지쳐 쓰러질 확률 또한 100%에 가깝다고 생각합니다.

그러니 우리 팀에 당장 적용해볼 수 있는 것, 해볼 만한 것 들을 위주로 먼저 적용해보고 점진적으로 해야 할 것, 해내야 할 것 등으로 발전해 나아가는 방법도 좋을 것 같습니다.

저는 개인적으로 문서화를 먼저 조금씩이라도 적용해 나아가고자 합니다. 화이팅 :)

최근 아카텍쳐, 아키텍트 관련 책을 연달아 보게 되었다, 성격이 다소 다른...

[서평][컴퓨터공학] 소프트웨어 아키텍처 101 / 한빛비디어

IT개발자로 커리어를 쌓다보면 요구사항을 실체화 하는 작업에서 시작해서 설계와 관련된 부분에 조금씩 관여하게 된다. 더 나아가서는 아키텍쳐 관련 부분에까지 이르게 되는 경우도 있다. 물론 체계와 역할과 권한이 자리잡아 있는 큰 조직에서는 그렇게까지 하는 경우가 그리 많지 않지만 작은 조직에서는 연차가 높아질 수록 이것저것 다해야하는데 작은 조직에서 이러한 부분에 세심한 커리어 개발이 가능한 테크트리가 있거나 하지는 않는다.

개발자를 아키텍트로 이끄는 것을 표방하는 책이 한권 있다.

책은 3부로 구성되어 있다.

 - 1부 : 소프트웨어 아키텍트 역할 및 아키텍쳐

 - 2부 : 아키텍트 설계에 필요한 하드/소프트 스킬

 - 3부 : 38가지 아키텍트 활동 

개인적으로는 1, 2부 내용은 다소 좀 부족한것 같기도 하고 내용 전개가 재미지게 매끄럽게 흐르지 않는다, 그래도 아키텍트라는게 생소한 사람에게는 역할에 대해서 이해하는데 어느정도 도움이 될꺼라 생각한다.

내가 생각하는 이 책의 가치는 3부 내용이 아닐까 싶다. 아키텍팅을 위해 아키텍트가 할 수 있는 활동들에 대하나 구체적인 활동방법을 38가지나 소개하고 있다.

PM 관련 여러 지식체계 그리고 애자일이나 스크럼 등등의 방법론 등에 한두단락의 설명으로 끝나는 여러 활동들에 대한 구체적인 방법이 정리되어 있다.

여기서 설명하는 방법들은 아키텍트 뿐만 아니라 PM/PL 또는 관리자들이 업무를 수행할때 그대로 또는 이를 응용해서 활동하면 효과적인 내용들이다, 적용하기 따라서 다방면으로 응용이 가능하다.

다만 아키텍트, 아키텍처에 대해서 이 책 한권으로는 다소 부족하고 '소프트웨어 아키텍처 101' 등 추가적인 학습과 활용을 하게 된다면 개발자에서 한단계 성숙한 역할을 수행하게 될 수 있지 않을까?

※ 본 리뷰는 IT 현업개발자가, 한빛미디어 책을 제공받아 작성한 서평입니다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

솔루션즈 아키텍트로 일하면서 고객분들의 요구사항을 듣고 그들의 아키텍처에 도움이 될 수 있는 정보를 제공하려고 노력하고 있지만 실무에서 같이 일하고 있는 것이 아니기 때문에 아무래도 도메인 지식이나 현재 고객들이 가지고 있는 고충을 명확히 이해하는 것이 쉽지 않다는 것을 느끼고 있다. 또한 아키텍트로써의 역할을 잘 수행하고 있는지 의문이나 불안감이 들거나 조급함이 생기는 경우가 많았다.

책 내용 중 팀에 아키텍트라는 직함이 없더라도 누군가는 그 역할을 하고 있는 사람이 있을 수 있고 소프트웨어 아키텍처에 영향을 주고 있다면 아키텍트라고 볼 수 있다는 말처럼 아키텍트는 멀리 있는 것이 아니고 지금의 나 일 수도 있다. 그런 측면에서 이 책에서 설명하는 지침들은 소프트웨어 개발을 하는 누구에게나 적용할 수 있다는 의미이기도 하다. 그런면에서 어떻게든 아키텍처에 영향을 주고 있기 때문에 아키텍트라는 직함에 자신감을 가져도 될 것 같다는 생각을 했다.

또한 큰 문제를 작게 나누고 관리하기 쉽게 만든다는 것에 크게 공감이 되었다. 내가 생각 했을 때 소프트웨어 아키텍트의 가장 중요한 역할인 것 같고, 이걸 잘하는 사람들과 함께 프로젝트를 진행했을 때 성공 확률이 높았던 것 같다. 내가 항상 생각해오던 것도 지속적인 작은 성과를 만들수록 더 열정적이게 되고 재미도 느낄 수 있다는 것이었고, 이로 인해 결국에는 프로젝트도 성공적으로 진행할 수 있을 것이라 생각한다.

책을 읽으며 아키텍트는 모든 기술에 통달한 현자가 아니라는 말에 약간의 위안을 얻었다. 최근에 알아야할 기술들이 여러 분야에 걸쳐 많이 있었고, 이를 다른 사람들에게 가이드해야할 일들이 있었다. 최대한 나 혼자서 해결하려고 했기 때문에 이로 인한 부담감이 상당히 컸었고, 스트레스도 받았었다. 사내에 각 분야의 전문가들이 많기 때문에 그런 분들께 도움을 받고 나니 굉장히 오래 걸릴 수 있는 일도 빠르게 처리되었고, 만족도 또한 더 높았다. 이런 과정들을 겪고 나니 내가 잘하는 것도 중요하지만 주변에 좋은 동료들과 협업하고, 인맥을 쌓아가는 것이 중요하다는 것을 깨달았다. 책에서 얘기하는 커뮤니케이터의 역할에 포함되는 것 같기도 하다.

불확실한 요소도 없고 의문도 없는 소프트웨어라면 애초에 아키텍트가 필요없다라는 말처럼 현재 내게 주어진 업무가 불안하고 정답을 모르겠고 하는 것은 당연하다는 것을 항상 마음에 새기고 가설과 검증을 반복해가며 하나씩 해나가야겠다는 생각이 들었다. 이 책을 읽으며 많이 배운 것도 있지만 무엇보다 마음의 위안을 얻었던 것이 가장 컸다. 아키텍트를 목표로 삼고 있거나 현재 불확실한 업무로 인해 불안감을 갖고 있는 개발자들에게 강력히 추천한다.

책소개



<이 리뷰는 한빛미디어 '나는 리뷰어'로 부터 도서를 지원받아 작성되었습니다.>

책소개

개발자에서 아키텍트로 거듭나기! 초보 아키텍트를 위한 실전 입문서

이 책은 개발자에서 아키텍트로, 변화의 첫걸음을 내딛는 이를 위한 실전 입문서다. 설계를 위한 필수 지식, 아키텍처 패턴, 모델, 설계 방법론, 커뮤니케이션 노하우를 상세히 소개한다. 문제 상황에서 팀원들과 해볼 수 있는 38가지 팀 활동을 소개하며 실무 적응 능력을 키워준다.

아키텍처를 잘 모르는 개발자라면, 이 책을 읽으며 개발 업무의 구조를 이해하는 실력을 향상할 수 있다. 현업 아키텍트라면, 결정사항을 잘 설명하여 팀을 이끌고 이해관계자와 소통하는 능력을 키울 것이다. 이 책과 함께 프로젝트와 팀을 성공으로 이끄는 훌륭한 아키텍트로 거듭나길 바란다.

https://www.hanbit.co.kr/store/books/look.php?p_code=B1705050272 

목차

목차는 다음과 같이 구성되어 있다.

소프트웨어 아키텍처를 다루고 있는 Part.1

 - 아키텍트가 하는 일, 아키텍처가 무엇인지 등에 대해서 다룬다.

아키텍처 설계 기초를 다루고 있는 Part.2

- 설계 전략과 이해관계자와 공감하기 등 요구사항 알아내고 선택, 평가 등에 대한 내용을 다룬다.

아키텍트의 은빛 도구상자 Part.3

- 문제 해결에 대한 방법(공감대를 형상하는것 등) 중에서 요구사항을 이해하고 찾는 방법에 대한 내용을 다룬다.

리뷰

책에서는 소프트웨어 아키텍트를 다음과 같이 설명하고 있다.

프로그래밍 외에도 여러가지 책임을 가지며, 엔지니어링 관점에서 문제를 정의한다고 설명합니다. 언제나 늘어나는 기술 부채를 관리해야하며 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람.

그렇다면 소프트웨어 아키텍처란 무엇일까?

한 소프트웨어를 어떻게 구성해야 하는지 그리고 필요한 품질 속성을 어떻게 증진해야하는 지에 대한 중요한 결정들과 다른 소프트웨어와는 구별되는 특징들을 모아놓은 집합이다.

책을 읽다보니 나도 아키텍트인 순간도 있을 수 있고 동료가 아키텍트인 상황도 있을 수 있다는 생각이 들었다. 우리는 어느순간 아키텍트일 수 있는게 아닐까? 라는 생각이 들었다. 그만한 책임이 따르겠지만책을 통해 아키텍트에 적응한다면 흉내는 내볼 수 있지 않을까? 라는 생각도 들었다.

디자인 싱킹(Design Thinking)이라는 내용도 나온다. 

- 문제를 해결하려는 과정이리기보다는 문제와 해결책 그리고 이에 영향을 받는 사람들의 관점에 대해 생각하는 방식

디자인 싱킹에는 4가지 원칙이 있다고 한다.

- 인간중심의 원칙

- 모호함의 원칙

- 재디자인의 원칙

- 촉각의 원칙

또한 책에서는 사례를 통해 단계별로 내용을 설명하고 있다. 그렇기 때문에 조금더 내용을 알기 쉬운것 같다.

좋았던 점

라이언하트라는 사례를 통해 아키텍트로 성장하는 과정에 대해서 차근차근 알아가 볼 수 있다는 점이 좋았다. 사례를 들어서 설명해주다보니 이해가 조금 더 쉽게 되는 느낌이었다. 

그림이 가독성이 엄청 좋다. 그림들 자체가 아기자기 하지만 내용들을 모두 담고 있다보니 그림만 봐도 내용이 잘 보여서 책을 읽을 때 너무 좋았다. 

이 책은 개발자의 관점에서 아키텍트로 성장하고자 하는 사람들에게 추천한다. 읽어보면 아키텍트가 고려해야할 부분이 생각보다 많다는것을 알게 되는 한편으로 책을 내용을 적용하다보면 아키텍트에 다가갈 수 있지 않을까 라는 생각이 든다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

왜 아키텍트가 되어야 하는가?

현재의 나는 소위 말하는 임베디드 개발자로서 근무를 하고 있다. 제조업 기반의 회사 제품에 들어가는 소프트웨어를 개발하는 것을 보면, 모든 회사가 그런지는 모르지만 개발 과정이 상당히 직선적이다. 소프트웨어의 근간이 되는 요구사항은 막막하고, 뼈대가 되는 아키텍처는 막연하다. 부품이나 제조 공정에 대해선 명확한 용어가 정의되어 있고 프로세스도 철저하지만, 소프트웨어에 대해선 모듈, 기능, 알고리즘, 로직 같은 용어들이 산발적으로 나오며 개발 프로세스는 "밑바닥부터 시작하는 딥러닝" 시리즈처럼 백지에서 출발해 최종 기능까지 단숨에 도달하고자 한다. 또한 개발 문화가 상당히 폐쇄적이라 오픈 소스에 대해 상당히 비관적이고 사용을 꺼려한다.

이번에 한빛미디어에서 제공받은 책은 마이클 킬링의 <개발자에서 아키텍트로>이다.  앞서 말했듯이 현재 일 하고 있는 곳에서는 프로그래밍 언어를 어느 정도 숙지하고 있으면 바로 개발자로서 업무를 시작하는 환경이기 때문에, 대체로 소프트웨어 엔지니어링을 접하기 어려운 상황이다. 특히 나를 포함한 수많은 사람들이 아키텍처를 제안하지만, 개발 업무에 도움이 되기 위한 아키텍처는 없고 보고를 위한 도형의 집합인 경우가 대부분이다. 따라서 이 책을 받으며 도대체 아키텍처라는 것은 무엇이고, 어떻게 해야 소프트웨어를 쌓아 올릴 때 유용하게 활용할 수 있을 까에 대한 답을 알 수 있지 않을까 기대되었다.

<개발자에서 아키텍트로>의 구성

먼저 <개발자에서 아키텍트로>는 다음 세 개의 파트로 이루어져 있다.

• 소프트웨어 아키텍처


• 아키텍처 설계의 기초


• 아키텍트의 은빛 도구 상자

책의 제목처럼 개발자에서 아키텍트로 가기 위해선 우선 아키텍트가 무엇을 하는지, 어떤 사고를 통해 아키텍트가 될 수 있는지를 알아야 한다. 그다음엔 아키텍트로서 할 수 있는 업무들을 기초적인 내용을 토대로 순차적으로 알아야 한다. 그리고 다양한 문제 상황에 대해 해결을 위한 활동들을 활용할 줄 알아야 한다. <개발자에서 아키텍로>는 앞서 말한 이런 내용들을 세 개의 파트로 풀어냈다. 

누구에게 필요한가?

이 책은 이제 막 개발을 시작해 문법은 어느 정도 익숙해진 개발자들이라면 이 책을 통해 시야를 넓히는 데 사용하면 좋을 것 같다. 어느 정도 실제 업무의 예시에 가까운 "사례 연구: 라이언 하트 프로젝트"가 매 챕터마다 존재하여 간접 경험을 쌓거나 책의 내용을 이해하는데 도움을 많이 준다. 너무 막연한 내용이라고 넘겨짚는 것보단 다양한 사례 연구나 활동 내용을 보며 이해해본다면, 하나의 '기능'만 개발하는 신입 개발자에서 큰 그림을 그리며 앞으로 어떤 일을 하면 좋을지 구상할 수 있는 중견 개발자로 성장해 나아갈 수 있는 발판이 될 것이다.

또한 개발자에서 관리자로 넘어가는 시점에 있는 사람에게 역시 큰 도움이 될 것이다. 막연하게 개발 과정에서 익혔던 설계 기술들을 정확하게 정의된 용어를 통해 다시 학습을 하며 개발자로서 쌓아왔던 역량이 앞으로 무궁무진하게 활용될 수 있을 것이라 생각한다. 물론 아직 나는 이제 막 신입 티를 벗은(?) 상황이다 보니 경력이 더 쌓인다면 어떤 일을 하는지는 정확하겐 알진 못한다.

아쉬운 점

이 책의 아쉬운 점을 꼽자면 다양한 아키텍처 패턴에 대한 책이라 생각하였지만, 그렇지 못했다는 것이다. 물론 이는 어떤 의미로는 장점에 가깝다. 여러 아키텍처에 대한 디자인 패턴들을 단순히 나열하기만 한 책이었다면, 읽기 위한 노력이 더 많이 필요했을 것이다. 또한 내용들이 와닿기보단 막연함으로 머릿속에 들어오지 못하였을 것 같다.

출처: https://jaksam.tistory.com/43 [작삼심일의 블로그]

많은 시간 개발을 하면서 시스템 아키텍처에 대해서 생각을 안해왔던것은 아니었다. 하지만 그런 지식들은 공부를 해서 생기는게 아니라 실제 경험으로 해봐야만 알수 있다는 생각을 많이 했었다. 그런데 요즘드는 생각은 이론으로 알고 실제 경험을 하면 더 많은것을 할수 있고 더 잘 할수 있을거라는 생각이 많이 들었다. 그래서 최근 책을 고를때에 아키텍트 관련 서적을 많이 골랐던것 같다.

개발을 하다가 나이 먹으면 아키텍트를 해야 한다 라는 그런 의견(?) 들이 많긴 한데 개발자에서 아키텍트로 간다는 것은 생각처럼 당연하지도 않고 쉽지도 않다. 지금도 물론 개발도 하고 아키텍트 역할도 하고 있지만 솔직히 그게 아키텍트로서의 역할이 맞는지, 아니면 개발자인지 구분이 안간다. 

그리고 매번 같은 방법, 같은 형식으로만 생각하다 보니 우물 안에 개구리처럼 생각이 닫혀버린 느낌이 많이 들었다. 아마도 관련 지식과 경험의 부족이라고 생각이 든다. 그래서 "개발자에서 아키텍트로" 되기 위해서는 어떤 것들이 필요한지 책을 통해서 조금이나마 알아가보기로 했다. 

이 책은 총 3개의 챕터로 구성이 되어있다.

1부. 소프트웨어 아키텍처

소프트웨어 아키텍처가 어떤 일을 하는 사람인지 알아보는 챕터이다. 그리고 디자인 마인드셋 (이해하기, 평가하기, 탐색하기, 실현하기)은 무엇인 알려준다. 

2부. 아키텍처 설계의 기초

2부에서는 1부에서 말한 마인드셋 영역별로 아키텍처 설계를 어떻게 해야 하는지 기초 지식에 대해서 알아볼 수 있다. 요구사항 분석부터 설계, 패턴, 시각화, 문서화, 그리고 평가까지 기본적으로 알아야 할 내용들이 담겨있다. 그리고 요구사항 분석 이전에 이해관계자들과는 어떻게 대화를 해야 하는지도 알려준다. 

아래 그림은 아키텍처 패턴 부분에서 설명에 추가되어있는 그림과 표이다. 실체 패턴이 어떻게 구성되는지 알수있고 각 컴포넌트들이 어떤 역할을 하고 있는지 쉽게 알수 있다. 

3부. 아키텍처의 은빛 도구상자

3부는 지금까지 배운 내용에 대한 실습 과제를 해보는 부분이다. 총 38가지의 주제를 가지고 팀 활동을 해볼수 있다. 그리고 팀 활동도 위에서 말한 마인드셋 영역별로 4가지 주제를 가지고 나눠져 있다. "문제를 이해하고 싶을때", "해결책을 찾고 싶을때", "손에 잡히는 설계를 만들고 싶을때", "설계 대안을 평가하고 싶을때". 

활동의 목적이 무엇인지, 그리고 이 활동을 함으로써 얻을수 있는 장, 단점, 시간, 절차, 예시까지 아주 꼼꼼히 설명이 되어있다. 그리고 설계에 대한것 뿐만 아니라 앞에서 말한 4가지 주제에 해서도 활동이 있기 때문에 책에서 읽은 부분들을 충분히 경험해 볼수 있다. 

개발자가 아키텍트 역량을 키우기 위해 어떻게 해야 하는지 업주적인 내용부터 기술적인 내용까지 두루 살펴볼수 있는 책이다. 그리고 실습해볼수 있는 주제들을 통해 책의 이론을 경험해 불수 있다는 것이 무엇보다도 좋은 부분이었던 것 같다.

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

예전에 팀장과 미래에 대해 얘기를 나누며 관리 업무를 극도로 싫어하는 나에게 제시한 미래가 아키텍트였다.

문제는 지금까지 아키텍트 업무를 전업으로 하는 사람과 교류할 기회가 없어,나에게는 그냥 구호뿐인 미래였다.

그런 와중에 이 책을 접하게 되었다.

사실 책을 받으면서 기대는 아키텍트로서 갖춰야 할 기술적인 내용이 좀 나오기를 바랬는데,

아키텍트 패턴에 대한 내용은 일부이고, 

대부분은 아키텍트 설계를 진행하는 과정을 주로 다뤄, 학부 때 소프트웨어 공학책을 다시 보는 느낌이었다.

생각해보면 아키텍트의 일은 소프트웨어의 구조를 설계하고 이를 엔지니어들과 함께 만들어가는 역활이니 아키텍트만의 기슬은 없을 수 밖에 없다.

일단 책은 아키텍트로 설계의 시작부터 시스템을 완성할 때 까지 아키텍트들이 해야할 업무와 방식을 자세히 나열해 주었다.

물론 이에 대해서도 많은 방법이 있기에 자세한 내용을 다 다루지는 못하고 각주로 참고할 만한 자료들을 나열해 주었는데,

그래도 간단한 사례 예시로 , 각주 참조 없이도 간단하게 나마 이해할 수 있게 해 주었다.

책을 모두 읽고 드는 생각은 아키텍트 입문서로서는 참 좋은 책이다 라는 느낌이 든다.

그리고 대부분의 예시가 도커, 클라우드등 현재 각광받는 기술을 예시로 들어 

학부때의 따분했던 소프트웨어 공학 책보다는 즐겁게 읽혀진다.

하지만 이 책은 아키텍트가 되기위한 걸음마를 내딛기 위한 책이지,

완결서라는 생각은 조금 위험할 수 있다.

어쨋든 나의 아키텍트에 대한 목마름을 해소할 수 있는 꽤 괜찮은 책이었다.

나처럼 아키텍트의 꿈이 있는 사람이라면 적극 추천하고 싶다.

1.인트로

많은 사람들이 기본적인 아키텍트를 알고 있을 것이다. 취직을 하면 대부분의 설계가 완성된 것에 기능만 추가하는게 대부분이라, 설계를 해본 사람은 드물다. 처음 취직할때부터 아키텍트로 가는 경우는 거의 없고, 개발자 일을 하다가 아키텍트로 전향하는 경우가 많다. 나도 아키텍트에 대해 관심이 많고, 전체적인 팀매니저를 하려면 필수적인 지식이라 관심을 갖고 있었는데 이번 기회에 책을 읽게 되었다.

2.메인 내용

[PART 1 소프트웨어 아키텍처]

CHAPTER 1 소프트웨어 아키텍트가 되다

CHAPTER 2 디자인 싱킹 기초

[PART 2 아키텍처 설계의 기초]

CHAPTER 3 설계 전략 고안하기

CHAPTER 4 이해관계자와 공감하기

CHAPTER 5 아키텍처 핵심 요구사항 알아내기

CHAPTER 6 아키텍처 선택하기

CHAPTER 7 패턴으로 기초 만들기

CHAPTER 8 의미 있는 모델로 복잡도 관리하기

CHAPTER 9 아키텍처 디자인 스튜디오 운영하기

CHAPTER 10 설계 시각화하기

CHAPTER 11 아키텍처 문서화하기

CHAPTER 12 아키텍처 평가하기

CHAPTER 13 아키텍트에게 힘 실어주기

[PART 3 아키텍트의 은빛 도구상자]

CHAPTER 14 문제를 이해하고 싶을 때

CHAPTER 15 해결책을 찾고 싶을 때

CHAPTER 16 손에 잡히는 설계를 만들고 싶을 때

CHAPTER 17 설계 대안을 평가하고 싶을 때

책의 짜임새는 매우 잘 짜여져 있다. 처음에 소프트웨어 아키텍터의 본질과 어떤 것을 하는지에 관한 설명을 하고, 본격적으로 아키텍처 설계의 기초부터 알려준다. 마지막으로는 실제로 생각해볼 수 있는 아키텍처 아이디어를 주면서 직접 생각해볼 기회도 줘서 따라가기 편했다.

그리고 자칫 이해를 못하면, 뒤에 내용도 다 헷갈릴 가능성이 높지만 그림과 하이라이트를 통해 이해하기 쉽게 구성을 했다. 그리고 처음부터 설계하는 것이 아닌 나중에 추가적으로 설계하거나 수정하는 경우에 사용할 수 있는 팁들도 많이 있어서 좋았다.

3.나의 생각

많은 개발자들이 아키텍처 설계에 관심이 별로 없고, 실제로 체감할 일도 별로 없다고 느꼈었다. 그래서 관련 자료도 적고 실제로 공부할 수 있는 수단도 적었다. 나는 창업을 하면서, 실제로 설계를 해보면서 다양한 삽질을 해보았다. 그래서 얼마나 정보가 적고, 실전에서 쓰이는 지식과의 괴리가 많은지 체감을 해봤다. 

이 책은 그런 접근성면에서는 매우 좋았다. 기초부터 잘 정리되어 있어서 따로 많이 찾아보지 않아도 좋았다. 책의 페이지수가 좀 많지만, 언제나 그러듯, 필요한 부분만 잘 사용하면 될 것 같다. 아키텍트 진로에 관한 책이 별로 없는데, 관심이 있다면 정말 유용한 책인 것 같다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."



이번에 리뷰하게 된 도서는 "개발자에서 아키텍트로" 이다.

우선 이 책을 선택하게 된 이유는 아래와 같다.

어느정도 현업에서 개발을 진행하다 보면 아키텍처를 고민하게 되는 상황을 필연적으로 마주치리라고 본다.

처음에는 이미 만들어져있는 제품 코드를 유지보수하는 상황에서는 새로 설계할 일이 많지 않기 때문에 아키텍쳐에 대한 고민을 할 일이 별로 없는것 같다.

하지만 점점 시간이 지남에 따라 새로운 프로젝트를 진행하게 되며 그 규모가 작을 수도 클 수도 있지만 새로 만들어야 하는 상황을 마주하게 된다.

그럴때면 대학시절 배웠던 소프트웨어 공학 전공 과목이 떠오르게 된다.

그때는 내용들도 딱딱했던 기억이며, 그 내용들을 내가 언제 어떻게 사용할 수 있을지 감이 오지 않았던 것이 사실이었다.

하지만 현업에서 지내다보면 학부시절에 배웠던 사항들을 다시금 들춰보게 되는 타이밍들이 있는 것 같다.

이렇게 신규 개발을 진행해 나가야 하는 과정이 필요한 시기에 이 책을 읽게 된다면

큰 도움이 될 것 같다는 느낌이 들어 선택하게 되었다.

과연 선택은 옳았을까?

일단 도움이 되는 것 같다. 라는게 나의 의견이다.

이 책은 대학 전공 서적과는 다르게 읽다보면 실전적인 느낌을 계속해서 받게 되었다. 물론 대학 시절의 나와 현업에 있는 지금의 내가 다르기 때문에 느낀것일 수 도 있지만 내용 자체가 딱딱하지 않고 잘 읽혀졌다.

초반에는 소프트웨어 아키텍쳐에 대한 설명을하고 중반에는 아키텍쳐 설계에 대한 기초 설명으로 어떤식으로 접근해야 하는지 차근차근 설명해준다.

그리고 마지막 후반에는 38가지 활동을 통하여 아키텍쳐 설계에 대한 실천적인 내용들을 설명하고 있다.

사실 이 책을 읽는다고 해서 아키텍처 설계 능력이 올라가는 것은 아니라고 본다.

간략하게 설명을 하고 있지만 내용은 방대하기 때문에 쉽게 볼 책은 아니라는 생각이다. 그리고 개발만 했었더라면 들어보지 못한 용어들도 많고 설계에 대한 생각의 깊이와 넓이를 많이 확장해야 겠다는 느낌을 받았다.

확실히 아키텍트로 넘어가거나 아키텍처 설계를 해야 하는 상황이 되면 개발관점보다는 훨씬 넢은 시각에서 봐야 한다는 것을 이 책을 통하여 느낄 수 있었다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공 받아 작성된 서평입니다."



개발자에서 아키텍트로

마이클 킬링 지음

이 책을 읽어야 할 대상은 분명하다. 아키텍쳐를 진짜로 고민하는 사람.

개발자나 그저 막연히 아키가 하고 싶어서 보려고 한다면 비추다.

마치 대학 학부수업 느낌이 들 것이다. 코딩이라던가 실습예제 같은 것을 기대했다가는 영락없이 책꽂이로 직행이다. 대학교재 바로 옆자리로. 사진 찍은 골동품 교과서 『소프트웨어 아키텍처 이론과 실제』 옆이라면 더 좋을 것이다.

추천의 글을 보면 뭔가 있을 것 같은 기대감이 올라온다. 그러나 솔직히 지루하다. 우리나라에서 이렇게 프로젝트 하는 경우가 일년에 몇 개나 있을까? 다른 리뷰어들의 글을 보면서 진짜 저렇게 많은 사람이 높은 평점을 주는 이유가 뭘까 궁금했다. 내 내공은 아직 멀었나보다.

또 하나 아키텍트의 역할과 To-do list를 제시했지만, PM이나 PL 역할과 너무 중첩된다. 국내 어떤 프로젝트에서 PM, PL 제쳐놓고 아키가 나서서 이해관계자나 ASR을 분석하고 있나? 20년 넘게 프리랜서로 경험했던 것들은 너무 뻔한 국한된 프로젝트들 뿐이었나?

이 책을 비난하는 것은 아니다. 어쨌든 건질만한 것들은 있다.

우리가 아키텍쳐를 너무 우습게 생각하고 있었다는 것, 점점 사라져가는 아키 포지션이 그래도 가치가 있다는 것, 골동품처럼 생각했던 아키텍처 패턴을 떠올릴 수 있었다는 교훈은 남는다. 책꽂이를 장식하던 『소프트웨어 아키텍처 이론과 실제』를 소환한 것도 단발성이지만 의미는 있었는데, 요 골동책보다는 훨씬 간결하고 이해가 쉽기 때문이다.

제대로 된 소프트웨어 팀을 만든다면 이렇게 해보고 싶다는 생각이 들기는 하다. 초중급 수준의 개발자라면 이 책보다는 디자인 패턴 관련 책이 더 적당할 것 같다.

※ 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.



PART1 소프트웨어 아키텍처

CHAPTER 1. 소프트웨어 아키텍트란 무엇이며, 소프트웨어 아키텍트가 하는 일에 대해서 설명합니다. 

소프트웨어 아키텍트는 팀에서 독특한 위치에 있습니다. 

아키텍트는 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람입니다. 

또한 소프트웨어가 비즈니스 목표에 부합하도록 만드는 사람입니다. 코딩은 하지만 알고리즘이나 코드를 짜기보다는 더 크고 많은 것을 설계합니다.

CHAPTER 2. 디자인싱킹은 소프트웨어를 개발하는 데서 기술과 사람을 잇는 방법을 알려줍니다. 

PART2 아키텍처 설계의 기초

CHAPTER 3. 설계 전략 고안하기에서는 아키텍처를 설계할 때 디자인 마인드셋을 적용하고 생각-실행-확인 사이클을 거치면서 어떤 부분에 초점을 맞춰야 할지 배웁니다. 

CHAPTER 4. 이해관계자와 공감하기 - 이해관계자란 어떤 소프트웨어에 관심이 있거나 관여된 사람을 일컫습니다. 이해관계자가 누구인지 알아내고 그들의 요구를 이해하는 일이 아키텍트의 역할이기도 합니다. 

CHAPTER 5. 아키텍처 핵심 요구사항 알아내기 - 챕터4에서는 이해관계자를 중심에 두고 누가 소프트웨어에 영향을 미치고 왜 우리가 그들을 중요하게 생각해야 하는지 알아봤습니다. 이번 장은 소프트웨어 아키텍처 관점에서 '무엇을'에 해당하는 요구사항을 알아봅니다. 

CHAPTER 6. 아키텍처 선택하기 - 이번 장에서는 핵심 요구사항을 이용해 구조를 어떻게 선택하고 의사결정을 해나가는지에 대해 알아봅니다. 

CHAPTER 7. 패턴으로 기초 만들기 - 어떤 소프트웨어 시스템이든 작은 주제의 패턴을 모아놓고, 그 위에서 전체 디자인을 결정합니다. 패턴을 사용하면 팀원들에게 소프트웨어 아키텍처를 설득하기 편해집니다. 패턴을 사용하면 수고스러운 노력을 직접 기울이지 않고도 다른 사람들의 지혜를 얻을 수 있습니다. 이 번 장에서는 가장 자주 사용하는 패턴 몇 가지를 알아보고, 이를 요구사항에 어떻게 적용하는지 소개합니다. 

CHAPTER 8. 의미 있는 모델로 복잡도 관리하기 - 소프트웨어 복잡도가 점차 증가할때 쯤에는 몇가지 선택지가 있습니다. 요구사항을 수정하거나 코드의 일정 부분을 덜어내서 다시 소프트웨어를 좀 더 작게 만들 수 있습니다. 이번 장에서는 여러 요소를 쌓아올리면서 의미 있는 모델을 만드는 방법과 이를 통해 더 수월하게 아키텍처를 파악하는 방법에 대해 알아봅니다. 

CHAPTER 9. 아키텍처 디자인 스튜디오 운영하기 - 이 장에서는 아키텍처 디자인 스튜디오를 계획하고 운영하는 방법에 대해 알아봅니다. 먼저 디자인 스튜디오의 개요부터 짚어본 후, 디자인 스튜디오를 쉽게 꾸리는 방법을 배울 것입니다. 

CHAPTER 10. 설계 시각화 하기 - 챕터 10에서는 아키텍처 다이어그램을 그리는 방법을 배우고 개발들과 수월하게 대화하는 방법에 대해서 알아봅니다. 

CHAPTER 11. 아키텍처 문서화 하기 - 훌륭한 문서는 업무 계획의 근간이 되며, 커뮤니케이션 보충 자료이자 협업 도구이기도 합니다. 설계 의사 결정을 할때 모두에게 공통의 인식을 심어주어서 더 나은 품질의 소프트웨어를 만들 수 있게 합니다. 

CHAPTER 12. 아키텍처 평가하기 - 이 장에서는 아키텍처에 성적표를 부여하는 방법에 대해서 알아봅니다. 평가의 피드백은 팀을 교육하고, 설계 시 의사결정을 보강하고, 배포의 위험을 줄이고, 아키텍처를 개선하는 데 사용 할 수 있습니다. 

CHAPTER 13. 아키텍트에게 힘 실어주기 - 이 번 장에서는 멋진 소프트웨어 아키텍처를 함께 설계하면서 팀을 성장시키고 역량을 강화하는 방법을 배웁니다. 

PART 3. 아키텍트의 은색 도구상자 

CHAPTER 14. 문제를 이해하고 싶을 때 - 문제 해결을 위한 공감대가 형성되면 이해관계자들에게 적극적으로 정보를 수집하고 문제를 정의해갑니다. 공감대를 형성한다는 건 요구사항을 정의하는 것보다 한 단계 더 높은 차원의 일입니다. 이해 관계자가 누군지 알

아내고, 시스템의 비즈니스 목표를 확인하고, 아키텍처의 특성에 맞추어 요구사항을 파악합니다. 

CHAPTER 15. 해결책을 찾고 싶을때 - 이 장에서 소개하는 활동은 아키텍처를 설계하며 여러 대안을 만들 때 유용합니다. 아키텍처로 발전할 수 있는 구조를 탐색하고, 실제로 구현해낼 엔지니어링 접근법을 찾아낼 수 있습니다.

CHAPTER 16. 손에 잡히는 설계를 만들고 싶을때 - 이 장에서 다루는 활동들의 결과물은 아키텍처를 실물로 만드는데 큰 도움이 될 것입니다. 결과물은 혼자서 직접 만들 수 있지만, 때로는 다른 사람과 짝을 지어 하거나 큰 그룹으로 협업할때 더 재미있고 유익할 수 있습니다.

CHAPTER 17. 설계 대안을 평가하고 싶을때 - 이 장에서 소개하는 활동은 팀원들과 아키텍처의 다양한 측면을 살펴보고 정보를 모아서 적절한 조치를 취하고자 할때 유용합니다. 아키텍처를 얼마나 잘 이해했는지 확인하거나, 설계의 대안을 선택하거나, 다음에 수행할 작업을 결정해야 할 때 활용하면 좋습니다. 

끝으로

소프트웨어 아키텍처는 멋진 소프트웨어를 만드는 단단한 기반입니다. 훌륭한 아키텍처가 소프트웨어 성공을 보장하지는 않지만 최소한 실패의 가능성을 적게 만들어줄 것입니다. 소프트웨어 개발자라면 소프트웨어 아키텍처에 대해 꼭 알아야 합니다. 이 책에서 훌륭한 소프트웨어 아키텍처를 어떻게 설계하는지 배우게 될 것입니다.

이 책으로 설계자다운 사고방식과 인간중심적인 접근 방법을 배울수 있을 뿐만 아니라 팀원 간에 협업하면서 소포트웨어를 설계하는 방법도 배울 수 있습니다. 소프트웨어 아키텍처라면 이 책을 통하여 기술과 현실을 효과적으로 배우게 될것입니다.



한빛미디어에서 낸 해외 번역서다.

소프트웨어를 만드는 단단한 기반인 아키텍트를 설계하고 적용하는 방법을 소개한다.

1부는 소프트웨어 아키텍트가 하는 일을 소개하고 정의한다.

2부는 아키텍처를 설계하고 핵심적인 요구 사항을 알아내어 설계에 반영하는 방법을 알아본다.

3부는 아키텍트를 설계하여 구체화하고 해결하기 위한 38가지 팀 활동을 소개한다.

나는 소프트웨어 아키텍트에 대한 지식이 부족하기 때문에 1부 1장부터 차근차근 읽어나가면 된다.

쉬운 설명과 내부 구성이 맘에 든다.

학교에서 설계 부분을 듣긴 했지만, 기본부터의 체계적인 공부는 안 해보았다. 책을 보니까 학교에서 안 배운 내용들이 많아서 구멍 난 지식을 채우는 것 같다.

감각적으로 알고 있었지만 이름을 몰랐던 개념을 확인하고, 알고 있던 지식과 실제 지식과의 차이를 발견할 수도 있었다. 개발자가 되기 위한 공부는 끝이 없다.

인상깊은 부분

공감은 곧 디자인을 이끄는 힘입니다. 이해관계자가 누구인지 명확하게 인식하고, 그들이 소프트웨어로 얻고자 하는 바를 정확히 알면 더 좋은 설계 결정을 할 수 있습니다. - 89p

이 책은 다른 번역서와 비교하면 친숙한 느낌이다. 익숙한 종이 재질과 인디자인이 그렇게 느끼게 해준다.

책의 특징으로 장마다 위에 제목과 함께 이해하기, 탐색하기, 평가하기, 실현하기로 분류가 되어있다.

책의 일부 사진

소프트웨어 아키텍처는 개발자라면 꼭 알아야 합니다. 더 뛰어난 개발자, 아키텍트, 기술 리더로 거듭나기 위해서는 다양한 아키텍처를 알아야하며 또한 잘 설계할 수 있어야 합니다.

​

​

이 책은 초급 개발자에게는 자신의 프로그램을 더 나은 설계로 완성할 수 있게 도와주며, 시스템 관리자나 시니어 개발자에게도 인사이트를 부여해줍니다.

​

​

책의 구성은 소프트웨어 아키텍트를 정의하는 것에서 시작하며, 디자인 싱킹에 대한 개념도 다루고 있습니다. 마음에 들었던 부분은 아키텍처를 설계하며 문제 상황을 마주했을 떄, 해결책을 찾아야 할 떄, 설계를 더 구체화하고 싶을 때 해볼 수 있는 활동을 소개해주고 있습니다.

​

​

해당 과정을 통해서 빠른 피드백과 반복을 활용하고, 높은 품질을 달성할 수 있는 기대감을 맛보았습니다. 애자일 이전, 레거시 소프트웨어 개발에서의 성공적이지 않았던 사례가 해당 과정을 통해서 성공 할 수 있기를 기대합니다.

 입사해서 처음으로 아키텍트분들이 많은 프로젝트에서 일하게 되었다. 그러면서 자연스럽게 아키텍트라는 직군에 대한 관심이 많아졌다. 하지만 회사에서 아키텍트팀이 사라졌기도 하고, 원래부터 팀간의 이동은 어디서나 힘든 일이었다. 점차 연차가 늘어나면서 아키텍트와 비슷한 일을 하고 있지만 아키텍트라고 부르기에는 어딘가 어색한 부분이 많았다.

 이 책은 그런 개발자에서 아키텍트로의 전환할 수 있는 다양한 훈련법을 알려준다. 또한 프로젝트에서 시스템 구조를 설계하고, 공통기능을 구현하는 일이 아니라 아키텍트가 어떤 일을 하고 있으며, 많은 고민해야 할 것들에 대해서 알려준다. 마지막에서는 38가지의 훈련법을 통해서 아키텍트로서 한걸음 더 다가가게 해 준다.

 아키텍트를 꿈꾸는 개발자분들은 이 책을 통해서 연습하기를 바래본다. 

  "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

두께는 여자 엄지 손가락 너비 정도. 팔랑 팔랑 얇은 종이라 무게는 생각보다 있습니다. 책을 펼쳐두어도 넘어가지 않습니다. (코딩 관련 책이 이럼 좋을텐데...)

책은 아래와 같이 총 세개의 파트로 나뉘어 집니다.

​

파트1. 소프트웨어 아키텍처

파트2. 아키텍처 설계의 기초

파트3. 아키텍트의 은색 도구상자

​

파트1은 아키텍처란 무엇인지, 왜 해야 하는지, 어떻게 아키텍터가 될 수 있는지에 대한 짧은 내용으로 이루어 집니다.

메뉴얼을 스킵하고 바로 도구를 사용하는 것을 즐기는 분들이라면 바로 파트 3로 넘어가서 바로 아키텍터로서 아키텍처를 만들어 가는 방법을 적용하는 방법을 학습할 수 있습니다. 설계 과정의 요약본으로 실습으로 빠르게 어떻게 하는 것인지 감을 잡을 수 있습니다. 이후 2장을 참고하여 하나하나 필요한 내용들을 알아보는 것도 성질 급한 사람들에겐 이책을 읽는 좋은 방법이리라 생각합니다.

​

순서대로 읽을 경우 아키텍처는 무엇인지, 설계를 하나하나 어떻게 해나가야 하는지 하나하나 정성스럽게 배워갈 수 있습니다.

​개인적으로는 3장의 실습 부분 하나를 읽고 2장을 넘어 가는 것도 나쁘지 않은 순서라고 생각하지만, 그부분은 읽은 부분의 취향에 알맞게 읽으면 된다고 생각합니다.

​쉽게 읽히는 내용으로 예시와 하나 하나 읽어 나가보면 비교적 빠르게 읽어 나갈 수 있습니다. 그래서 번역체가 아닌 정성스러운 문구와 읽기 쉬운 문장 구성이 번역에 많은 신경을 썼다는 것을 느낄 수 있었습니다.

​

"38가지 팀 활동을 활용한 실전 소프트웨어 아키텍트 훈련법"이라는 소제목 처럼 하나씩 읽어나가면 아키텍터라는 것이 무엇인지 체감하고 실전에서 사용할 수 있는 진짜를 얻을 수 있습니다.

​

레벨 상관없이 프로그램을 하고 싶은 사람이라면 누구든, 프로젝트를 리더를 하는 누구든, 프로젝트를 팔로워 하는 누구든 개발자로서는 한번은 읽어 보고 옆에 두고서 언제나 필요할 때 마다 읽어보기를 권하고 싶은 좋은 책입니다.

​

* 별점: 4/5 점

​

  최근 팀장 직책을 맡게 되어서 기술서적보다는 설계나 관리에 관한 책을 좀 읽으려고 한다. 개발자로 사회생활에 첫 발을 내딛고 업무를 하다 보면 코더, 개발자, 프로그래머, 아키텍트 등 현재 자신의 모습과 자신이 되고자 하는 미래의 모습에 대해 고민하게 된다. 경험이 부족해서 시야가 좁을 수도 있지만, 내가 알기로는 한국에서는 개발 업무 자체가 속도가 굉장히 빠르고 설계보다는 결과물에 더 집중하는 것 같다. 지금도 오래되고 꽤 규모가 있는(규모가 큰 게 맞을까?) 솔루션을 개발하고 유지 보수하는데, 아무리 분석하고 설계해서 개발을 하더라도 초기에 만들어진 기능이나 코드 덕에 이계 한계에 다다랐다고 생각 중이다. 대화의 스킬이나 설득력이 부족해서 개발팀의 입장을 대변하는 건 참 어려운 것 같다. 하지만 이런 상황일수록 구조나 기능, 로직에 대한 설계가 중요한 게 아닌가 싶다. 하여튼 이런저런 이유로 아키텍트는 참 매력 있는 것이라고 생각을 했고 과연 책에서는 어떤 내용을 알려줄까 하는 궁금증이 생겼다.

  기대와는 다르게 책을 읽을수록 뭔가 잘 읽히지 않는다는 생각이 들었다. 용어나 개념, 접근법 등이 생소했을까? 이미 업무를 하며 녹아들어있는 부분인 것 같으면서도 이게 맞는지 아닌지 판단하기 어려운 부분도 있었다. 이렇게 판단하기 어려운 부분은 책을 제대로 이해했는지 의구심을 갖게 하고 더욱 읽기 힘들게 만들었다. 책 후반부에서는 분석이나 설계에 필요한 여러 가지 활동에 대해 설명해준다. 이 부분도 마찬가지로 이해가 쉽지 않다. 어떤 방법에 대해서 설명은 해주는데 목적과 수행하는 근거가 다소 부족한 것 같다. 다행히 챕터의 뒷부분에서 사례연구를 통해 이해가 좀 되긴 했지만 양이 턱없이 부족했다고 생각한다. 본인이 예시 등을 통한 설명에 익숙해서 그렇게 생각했을 수도 있다.

  어렵긴 했지만 공감되는 부분도 꽤 있었다. 분석을 오래 하면 좋지만, 쉬운 말로 가성비가 최적을 이루기 위해 고민해야 할 적당한 시점 - 균형 -에 대한 이야기가 대표적이다. 또 문제 해결을 위해 설계에 신경 써야 할 설계자의 태도에 대한 부분도 있다. 초기에는 적극적인 설계로 위험 요소를 줄이고 기준점 - 이것도 균형이 중요하겠다 - 이 지나면 수동적으로 모니터링해야 한다는 내용이다.

  업무를 하다 보면 개발팀 외부에서 여러 가지 요구 사항이 나오고 이걸 다 해야 할지 말아야 할지 고민이 많이 된다. 핵심 요구 사항을 알아내는 방법을 설명해주면서 제약으로 선택지를 줄이는 것에 대한 내용이 나온다. 할지 말지 고민하다 보면 결론 내기가 쉽지 않다. 하지만 이런 방법들에 대해 인식하고 있다면 훨씬 쉽게 결정을 할 수 있을 것 같다.

  아직 설계 방법 등에 대해 많이 경험해보질 않아서 전반적으로 어렵게 느껴졌을 수도 있지만 많은 방법을 알려주고 있는 만큼, 고민하는 것보다 여러 가지 방법을 하나씩 따라서 실행해보고 잘 맞는 방법을 찾는다면 좋은 아키텍트가 될 수 있지 않을까 하는 생각이 든다.

* 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

아키텍트가 팀의 유일한 설계 권력자 역할을 맡는 게 아니라, 팀이 스스로 결정을

내리는 데 필요한 지식의 기술을 주입해 주는 사람이 되어야 합니다.

이 책을 신청한 이유 

최근 들어 회사 내에서도 팀장을 하면서 아직 개발 업무를 지속적으로 하고 있고 또한 설계업무도 같이 하다 보니 좀 더 효율적으로 

애플리케이션 및 인프라에 대해서도 효과적으로 설계를 할 수 있을지 또한 현재 돌아가는 시스템을 좀 더 효율적으로 개선해 나갈 수 있는

노하우가 필요해서 신청을 하게 되었습니다.

​

​

이 책의 구성

​

1장은 소프트웨어 아키텍처에 대한 내용 

​

2장은 디자인 싱킹 기초 

​

3장은 설계 전략 고안하기 

​

4장 이해관계자와 공감하기 

​

5장 아키텍처 핵심 요구 사항 알아내기 

​

6장 아키텍처 선택하기

​

7장 패턴으로 기초 만들기 

​

8장 의미 있는 모델로 복잡도 관리하기 

​

9장 아키텍처 디자인 스튜디오 운영하기 

​

10장 설계 시각화하기 

​

11장 아키텍처 문서화하기 

​

12장 아키텍처 평가하기 

​

13장 아키텍처에게 힘 실어주기 

​

14장 문제를 이해하고 싶을 때 

​

15장 해결책을 찾고 싶을 때

​

16장 손에 잡히는 설계를 만들고 싶을 때 

​

17장 설계 대안을 평가하고 싶을 때

​

개인적으로는 파트 2장의 7장 패턴으로 기초 만들기와 10장의 설계를 시각화하기, 11장의 아키텍처 문서화하기

내용이 좀 더 저한테는 더 의미 있게 읽었습니다. 다양한 패턴에 대한 예시 또한 그림으로 잘 표현되어 있어서 더욱더 이해하시기에 좋습니다.

마지막으로

일단 이 책을 읽으면서 커뮤니케이션이 또한 중요하다고 생각하고 또한 책에서도 쉬운 말을 사용하고 전문용어를 피하라는 내용도 있었고 

​

뭐든지 좋은 아키텍처는 설계한 내용을 어떻게든 잘 팀원들에게 전달을 하고 서포트를 잘해주는 것이 중요하다고 생각합니다.

​

이 책에 나온 여러 패턴 및 기법과 노하우를 통해서 좀 더 효율적인 서비스를 운영할 수 있도록 노력할 것이고 또한 팀원들에게도 추천을 해주고 싶습니다.

“훌륭한 아키텍처가 소프트웨어의 성공을 보장하지는 않지만, 나쁜 아키텍처는 필연적으로 실패를 가져 온다.” 라는 말로 저자는 이 책을 시작 한다. 그리고 개발자라면 소프트웨어 아키텍처에 대해 꼭 알아야 한다고 한다.

p.34 소프트웨어 아키텍트

소프트웨어 아키텍트가 하는일

소프트웨어 아키텍트는 모든 이해관계자와 협업 하면서 비즈니스 목표와 요구사항을 만들어 간다. 소프트웨어 시스템을 구현 가능한 작은 조각으로 나누는 동시에 전체 시스템이 일관성 있게 동작 하도록 큰 그림을 그린다. 또한 품질에 영향을 주는 다양한 품질 속성(Quality Attribute)  사이에서 균형을 잡아가며 어쩔 수 없이 늘어나는 기술 부채(Technical Debt) 도 관리 한다.

위에서 이야기한 소프트웨어 아키텍트가 하는일 이라는 문장이 이해가 되지 않는 나 같은 사람에게 반드시 이 책을 추천 한다.

단순히 소프트웨어 아키텍트가 하는일을 소개하는 문장에서 부터 알아들을 수 없는 단어들이 속출 한다. 특히 품질 속성이라는 굉장히 어색한 단어는 책을 읽는 내내 등장 하는데 (왜냐면 중요하니까!) 초반에는 무슨 말인지 이해하기가 어려웠다. 

품질 속성 정의하기(5.2) 에 가서야 겨우 품질 속성이 무엇인지에 대해서 설명 하고 있고 실제 요소들이 나온다. 그리고 품질 속성 레이다 차트를 만드는 부분(활동 6) 에 가서야 좀더 상세하게 이해 할 수 있었다.

p. 268 품질 속성 레이다 차트

중요하게 생각하는 기준에 따라 시스템이 어떻게 다를 수 있는지 시각적으로 비교할 수 있다.

책의 구성

책은 아래의 순서로 구성 되어 있다. 1부의 소프트웨어 아키텍트가 하는 일(1.1) 에 대한 설명으로 시작해서 2부에서는 실제로 아키텍처 설계를 위한 전략(3), 핵심 요구사항 알아내기(5) , 주요 패턴 설명(7)  그리고 멋진 다이어그램 그리기 (10.2) 를 통해 다이어그램으로 아키텍처를 사실적으로 시각화 하여 보여주는 방법에 대해 이야기 한다.

1부

소프트웨어 아키텍트가 하는 일을 소개, 소프트웨어 아키텍처를 정의

2부

본격적으로 아키텍처를 설계, 이해관계자와 소통, 아키텍처 핵심 요구사항을 찾아내 설계에 반영

3부

아키텍처를 설계하며 문제 상황을 마주했을 때, 해결책을 찾아야 할 때, 설계를 더 구체화하고 싶을 때 해볼 수 있는 38가지 팀 활동을 소개

개발자에서 소프트웨어 아키텍트로

개발자에서 소프트웨어 아키텍트가 되고자 하는 이에 대한 조언은 1.3 팀에서 아키텍트가 되려면 이라는 부분에서 다루고 있다.

저자는 개발자에서 아키텍트로 성장하고 있는지 측정해 보고 싶다면 프로젝트 포트폴리오를 만들어 보라고 말한다. 소프트웨어 시스템을 만들 때마다 어떤 역할을 했든지 간에, 참여했던 소프트웨어 시스템에 대해 간략히 정리하고 개발하면서 배운점을 정리 하는 활동은 소프트웨어 아키텍트에게 필수적이다.

프로젝트 포트폴리오 정리를 위한 주요 질문사항

1) 이해관계자들은 누구였고 주요 비즈니스 목표는 무었이었는가?
2) 최종적으로 어떤 결과가 나왔는가?
3) 어떤 기술을 사용했는가?
4) 가장 큰 리스크는 무엇이고, 어떻게 극복했는가?
5) 다시 시작할 수 있다면 어떤 점을 다르게 하겠는가?

감상평

두께도 얇은 편이고 편집도 깔끔하여 보기에는 쉬웠지만, 내용은 전체적으로 쉽지 않은 책이다. 

하지만, 말로 이해하기 어려운 부분도 책의 그림 이나 다이어그램, 표의 적절한 사용으로 이해하는데 도움을 많이 주었다. 

사례연구로 나오는 라이언하트 프로젝트는 뜬구름 잡기 같던 아키텍처 설계를 좀 더 구체화된 시선으로 볼 수 있도록 해주었다.

3부의 아키텍트의 은색 도구상자는 충분히 확인 하여 실무에서 사용할 수 있는 방안을 생각해보는 중이다. 특히 고객과의 인터뷰 같은건 매번 하는 작업 이지만, “활동4 이해관계자 인터뷰” 에서 처럼 목표와 질문목록 그리고 실행단계를 구분하여 작업해본적은 없었기에 책의 내용을 실천하여 작업을 수행해 보고 싶다.

소프트웨어 아키텍트가 뭐하는 포지션인지 모르는 사람에게 꼭 추천 하는 바이다. 

팀에 아키텍트가 없다면... “네, 축하 합니다. 이제 당신이 하면 됩니다.!”

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

프로그래밍 면접을 볼 때 어느 정도 연차가 되면 시스템 디자인에 대한 시간이 들어간다. 매니저나 그 이상의 직급에서는 코딩 인터뷰보다 더 많은 시간이 할당되는 경우도 봤다. 코딩 인터뷰와 가장 큰 차이점은 딱 맞아 떨어지는 정답은 없다는 점이다. 그래서 대부분의 회사에서 시스템 디자인 인터뷰에 대해서 안내할 때 “정답이 있는 건 아니다"라는 이야기를 한다. 하지만 또 어느 정도는 납득할 수 있고 수긍할 수 있는 아키텍처라는 게 존재하고 그래서 아키텍처에도 패턴이 있다. 하지만 이 패턴을 외운다고 해도 바로 옳은 답을 할 수 있진 않다. 그래서 아키텍처는 어렵고 경험이 필요하다.

이 책은 아키텍트가 되려면 어떻게 해야 하는지 여러가지 측면에서 다루는 데 다른 책들과는 특히 구분되는 면은 비기술적인 면도 중요하게 다룬다는 점이다. 예를 들어 4장은 “이해관계자와 공감하기”, 5장 “아키텍처 핵심 요구사항 알아내기”는 시스템의 관계자들과 협의를 하고 무엇을 최선으로 할지 결정하는 방법을 설명하는 데 다른 아키텍처 관련 서적에서는 쉽게 보기 힘든 부분이다. 실제로 업무를 하면 다른 부서의 매니저들이나 개발자들 뿐만 아니라 product owner와 같은 비즈니스 관련자들과 협의가 개발 방향에 큰 영향을 미친다. 이 때 어느 정도의 트레이드 오프를 통해 개발쪽에서 원하는 설계 방향을 유지하면서 비지니스 목표 달성에 협조하는 게 설계를 하는 사람의 몫이 된다.

또 다른 특징은 문서화를 강조한다는 점이다. 10장 “설계 시각화하기”, 11장 “아키텍처 문서화하기”를 통해 체계적인 문서화로 아키텍처 설계의 결과뿐만 아니라 과정도 같이 보여줘야 한다고 설명한다. 맥락이 없이 결론만 보게 되면 과정에서 논의되었지만 어떤 이유로 배제되었던 다른 아키텍처를 다시 설명해야 할 수도 있고, 다른 목표와 상충되어 일단은 포기하고 가기로 했던 부분을 왜 빠뜨렸냐고 묻는 사람이 생길 수도 있는데, 이런 불필요한 낭비를 줄일 수 있다는 점에서 아키텍처 문서화 역시 중요하다.

마지막으로 Part 3 “아키텍트의 은색 도구상자"에 있는 여러가지 활동이 독특한데, 모든 활동을 따라할 필요도 없고 가능하지도 않겠지만, 체계적인 회의를 하고 싶을 때 도움이 될 자료들이 많이 있다. 이런 개발과 무관해 보이는 업무 방식이 실제로는 잘 활용하면 업무 생산성을 높이는 데 도움이 된다는 점을 감안하면 여기 나오는 여러가지 활동을 잘 사용하면 아키텍처 설계뿐만 아니라 일반적인 개발 업무에서도 도움이 될 거 같다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다

설계를 해보신 적 있으신가요?

회사에 취업하고 개발을 하다가 설계로 넘어가는 케이스가 많습니다.

설계 경험이 부족하면 일을 맡았을 때 어려운 상황에 부딪히게 됩니다.

개발자에서 설계 쪽 일을 하고자 하는 분들에게 추천하고 싶은 책이 있습니다.

소개할 책은 ‘개발자에서 아키텍트로’입니다.

이 책을 통해 설계자로 변화하는 첫걸음이 되시길 바랍니다.

1) 소프트웨어 아키텍트란

소프트웨어 아키텍트는 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람입니다.

아키텍트는 코딩이나 알고리즘을 짜기보단 설계를 주로 합니다.

소프트웨어 아키텍트는 비즈니스 목표와 요구사항을 만드는데요.

프로덕트 매니저, 프로젝트 매니저, 모든 이해관계자와 협업을 합니다.

아키텍트의 중요한 역할은 팀원들을 설계과정에 참여 시켜 팀의 설계역량을 끌어올려야 합니다.

아키텍트가 되려면 팀에서 활동한 것을 설명을 잘해야 합니다.

이해관계자의 니즈가 파악하며 설계를 이끌어 내야 합니다.

또한 가장 큰 리스크는 무엇이었으며 극복한 방법도 말할 수 있어야 합니다.

2) 훌륭한 소프트웨어 만들기

훌륭한 소프트웨어를 만들려면 어떻게 해야 할까요?

큰 문제를 작게 나누고 관리하기 쉽게 만들 수 있어야 합니다.

소프트웨어 개발은 사람 간의 커뮤니케이션이 중요합니다.

시스템을 총체적으로 설명할 수 있어야 합니다.

사람들이 협업하려면 프로젝트에 대한 이해가 필요합니다.

설명을 이해하고 있어야 협업하여 일할 수 있습니다.

소프트웨어 아키텍처는 기본적인 개념과 필수 단어를 통해 대화가 가능해야 합니다.

Ps

이 책을 통해 소프트웨어 아키텍트가 어떤 일을 하는지 배울 수 있습니다.

아키텍트에 대한 기본지식과 설계에 대해 자세히 알려줍니다.

아키텍처 패턴 다이어그램으로 설명하므로 이해하는 데 도움 될 것입니다.

프로젝트와 팀을 성공으로 이끌어줄 38가지 팀 활동도 소개해줍니다.

아키텍트가 되고 싶은 분들에게 이 책을 추천합니다.

한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다.

개발을 진행할 때 아키텍칭은 정말로 중요하다.

아키텍칭 없이 시작한 개발과 아키텍칭을 충분히 진행하고 개발에 착수한 개발물의 결과는 상당한 차이가 있기 때문이다.

가령 10만 줄에 달하는 프로젝트를 진행할 때, 추후의 기능 확장성과 각 컴포넌트 간의 의존성 그리고 스케일 아웃 등의 관계를 고려하지 않고 코드를 짠다면, 이 프로젝트가 2년, 3년 후에 휴지통에 처박히는 것은 어찌 보면 당연한 수순이기 때문이다.

또한 어찌 보면 아키텍칭은 관련 소프트웨어의 수명과 연관되어 지속적이고 꾸준히 이뤄져야 할 요소이다. 즉 프로젝트가 처음 시작할 때 단 한 번만 수행하고 끝나는 행위가 아닌, 개발 중에도 서비스 중에도 수시로 아키텍처적인 고민과 개선이 이뤄져야만 한다.

이러한 관점에서 봤을 때, 개발자와 아키텍칭 사이의 관계는 결국 때려야 땔 수가 없는 관계다. 개발이 이뤄진다면 곧 그와 관련된 간단한 명세가 적어도 하나쯤은 있어야 함을 의미하기 때문이다.

이러한 관점에서 보았을 때, 개발자로써 아키텍트를 어떻게 이해야 할지, 혹은 아키텍트만 전문적으로 하는 직군의 업무를 꿈꿀 때 기본적으로 알아야 하는 지식과 이를 활용할 수 있는 가이드가 있다면 상당한 도움이 될 것이란 생각이 들었다.

그렇기에 이번에 "개발자에서 아키텍트로"라는 책을 한빛미디어 리뷰 도서로 신청하였고, 관련 내용을 간략하게나마 정리해보았다.

【책의 구성】 '개발에서 아키텍트로"의 책의 구성은 어떠한가?.

이 책은 총 3개의 파트로 구성되어 있다. 1파트는 "소프트웨어 아키텍처"에 관한 내용을 다루고 있고 2파트는 "아키텍처 설계의 기초"에 대해서 다루고 있다. 3파트는 "아키텍트의 은색 도구상자(실버 블렛)"에 대해서 정리되어 있다.

솔직히 파트 3은 간략하게 한번 읽어보고 필요할 때마다 참고하여 실무에 적용하면 좋을 것이란 생각이 들었다. 아~ 이런 방법이 있구나. 정도로 이해하고 추후 필요할 때 도입하는 형태로 말이다. (왜냐하면 해당 사항들은 지식을 전달하기보단 책의 소주제에서 설명하는 것처럼 "문제를 이해하고 싶을 때", "해결책을 찾고 싶을 때"와 같이 특정 상황에 놓였을 때 이를 해결하기 위한 실천 방향 (액티비티)에 관한 가이드이기 때문이다.)

파트 1은 말 그대로 "아키텍트"는 무엇을 하는 사람이고 무엇을 해야 하는지에 대해서 설명하고 있다. 거의 모든 책들의 시작과 유사하다. 다만 조금 다른 점이 있다면 "아키텍트"로써 문제를 해결해야 할 때, 어떤 접근법으로 접근하면 좋은지에 대해서 술 해져있다. 그런데 문제는 내용이 솔직히 좀 뻔한 것들이었다. 학부에서 소프트웨어 설계 혹은 소프트웨어 개발론에 관한 전공 과목을 한 번쯤 들어본 사람이라면 누구든 이해할 수 있는 내용들이다. 솔직히 약간 진부한 감이 없잖아 있는 파트이다.

파트 2의 내용이야말로 이 책의 핵심이라 할 수 있다. 아키텍처에 관한 설계와 이에 대한 기초에 대해서 정리하고 있는데, 내용을 이해하기엔 크게 어려움이 없다. 솔직히 기획자나 디자이너도 읽어두면 좋을 것이란 생각이 든다.

해당 파트의 각 챕터별 내용을 간략하게나마 몇 가지 요약하면 다음과 같다

3 챕터 : 설계 전략 고안하기

 이 장에서 가장 인상적이었던 내용은 설계를 굉장히 디테일하게 한다고 해서 프로젝트 개발 기간이 짧아지진 않는다는 것이었다. 오히려 설계 기간이 너무 길면 길수록 이에 따라 프로젝트 개발 기간이 늘어난다는 그래프 자료가 상당히 인상적이었다.

그렇다면 얼마만큼의 시간을 설계에 투자해야 가장 효율적인 일정 산정이 가능할까? 답은 없다였다. 왜냐하면 개발하려는 소프트웨어의 목적과 취지가 다양하며 또한 개발과정에서 사용되는 소프트웨어 개발론적 접근 방식 역시 상당히 다양하다.

위의 조건으로만 보아도 이를 특정 시간만큼만 설계하면 최상의 효율적인 일정을 산출할 수 있다고 말하는 것은 사기에 가깝다고 할 수 있다.

단, 관련 프로젝트를 사전에 진행해본 유경험자가 있고 이에 대한 각 구성원들의 방향성이 어느 정도 뚜렷한 상태라면 이를 위해서 적정 수준의 설계를 진행한 후, (필자의 경우, 본 프레임이라고 한다(bone frame)) 개발을 진행하며 유연한 자세로 프로젝트의 아키텍칭에 대처하는 것도 하나의 좋은 방법이 될 수 있을 것이란 생각이 들었다.

4 챕터 : 이해관계자와 공감하기

 "공감은 설계를 이끄는 힘이다" 이 챕터에서 가장 마음에 드는 문구였다. 맞는 말이다. 개발이건 뭐건 우리가 일하는 이유는 커스터머 즉 고객의 고충을 공감하고 이를 해결해 주는 것에 있는 것이다. 결국 이해관계자들 간의 요구 사항과 각각의 상충되는 필요사항을 적절히 융화하여 그들 모두를 최대한 만족시킬 수 있는 결과물을 도출하는 것이 분야를 막론하고 우리가 일하는 목적인 것이다.

이 장에서는 이러한 이해관계자들 간의 요구를 적절히 파악하기 위해서 "이해관계자 맵"을 활용할 것을 권장하고 있다. 처음에는 무엇인가 했는데, 결국 관계도를 그리는 것이었다. 각 이해관계 그룹 간에 필요한 내용들을 그래프로 잘 표시하고 각 그룹의 요구 사항을 잘 도식화하여 이에 대한 궁극의 공감점을 형상하는 방법을 이해시키는 것의 해당 챕터의 목적이라 할 수 있을 것이다.

하지만 이해관계자의 도표를 잘 그리고 그들의 요구 사항을 잘 도식화했다고 해서 이에 만족하고 끝내서는 안됨을 명심하도록 하자.

앞서 언급한 것과 같아 고객은 그들의 고충이 해결되길 원하는 것이지, 이해당사자들 간에 각자의 요청 사항만을 탁상공론으로 끝내길 원하지 않는다는 사실을 말이다.

10 챕터 : 설계 시각화하기

 "여러분이 만든 상상 속으로 끌여들이세요". 모든 아이디어는 결국 추상화를 통해 그림으로 보다 직관적으로 표현이 가능하다. 말로 설명하는 것은 직관성이 부족하므로 그림으로 그려서 그 의미를 보다 구체화하여 전달하면 훨씬 이해하기에 좋다.

단, 여기서 우리가 명심해야 할 사항이 있다면, 그림을 잘 그릴 필요는 없다는 점이다. 오직 의미를 잘 전달할 수 있는 수준의 그림이면 된다. 졸라맨 스타일이건 피카소가 울고 갈 정도의 걸작 수준의 그림이건 오직 구성원 간의 컨센서스를 맞추기 위한 의미만을 잘 전달할 수 있으면 되는 것이다. 따라서 그림을 잘 그리는 것보단, 의미를 잘 전달하는 데에 중점을 두는 스케치법을 익혀두도록 하자.

【 "개발자에서 아키텍트로"를 읽고서…….】

 이번 도서를 리뷰를 읽으며 가장 와닿았던 점은 아키텍칭은 한 번하고 끝나는 것이 아니라는 점이었다. 시대가 변하면 새로운 기술도 나오고 그에 맞는 다양한 개발 방법론이 재기된다. 그렇기에 이에 맞게끔 서비스 구조는 수시로 그 구조의 형태를 바꿔가며 시대에 맞게끔 탈바꿈해야만 한다. 만약 이런 과정을 반복하지 않게 되면.. 결국 그 코드와 프로젝트는 레거시 괴수로 변해 엄청난 리소스를 잡아먹게 될 것이 자명하기 때문이다.

어느 분야가 되었건 어느 산업이 되었건 지속적인 공부와 자기 개발은 필수가 된 시대인 것 같다. 평생직장이라는 말은 이제 거의 옛말이 되었고 직업과 일하는 형태도 지속적으로 변화하고 있는 것이 지금의 세계이다.

그렇기에 서두에서 언급한 것과 같이, 자신의 미래와 패스를 너무 자세히 설계하기보단 가장 중요한 구심점을 세우고 그것을 중심으로 어느 정도 유연하게 현실을 파악하고 적응하는 것이 필요해 보인다.

만약 본인의 직업이 프로그래머라면 위의 소양은 반드시 갖춰야 할 것이란 생각이 든다.

 #본 도서는 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

###### 감사합니다 ######



아키텍트는 어떤 업무를 하나요?

개발자에서 아키텍트를 고려하는 사람들도 많습니다. 그런데 정작 경력만으로는 만족할 수 없을 때가 많습니다. 그래서 다시 처음부터 공부하기는 버겁습니다. 그런데 그렇게 전반적인 내용을 알 수 있는 책이 이번에 나왔습니다.

한 컷 한 컷 내용에 의미가 있습니다.

이 책에 대하여

소프트웨어 아키텍트가 하는일

초보 아키텍트를 위한 실전 입문서

엔지니어링의 위험 요소

 이해관계자와 이해관계자의 요구

 스케치

2부 아키텍처 설계의 기초

설계 전략 고안하기

 위험분석 할당 시간

 디자인 마인드셋

 실현하기, 평가하기, 탐색하기, 실현하기

 실행하기, 확인하기, 생각하기

 이해관계자 맵

이해관계자와 이해관계자 요구

큰 그림 그리기 

 프로젝트 포트폴이오 정리 시 질문

 4가지 마인드셋

 콘웨이 법칙

"설계 조직의 커뮤니케이션 구조는 곧 제품을 설계할 때의 한계를 정의한다"

 계산기 애플리케이션

 아키텍처 영향

 데이터 기반 웹 애플리케이션 아키텍처 패턴

 컴퍼넌트 구성

 의사결정

 포트와 어댑터

 발생/구독 패턴 예시

 웹 서비스 상호작용 뷰(동적 모델링)

 아키텍처 서술 방법

해당 책은 매달 접하는 나는 리뷰어다 책을 통하여 접하게 됩니다.

 아키텍처에 대한 정의와 실제 적용되는 내용입니다. 실제로 두고 두고 천천히 보면서 익혀도 되는 책이기도 합니다.

'개발자에서 아키텍트로' 이 책을 조금 더 일찍 출간되어서 읽었다면 어땠을까?

아키텍트 역량을 향상시키고 아키텍트로 성장하기 위해 준비 중인 개발자로써 이 책을 읽은 건 기분 좋은 일이다.

약 4년 전 사내에서 Architect 양성을 위한 교육 및 자격 이수 과정에 지원 및 선발되어 교육을 받은 적이 있었다.
해당 교육은 Architect로써 필요로 하는 기본 역량과 함께 프로젝트를 진행하는 것이었다.

이 교육 전에는 Architect라면 오로지 설계하는 사람으로만 알았지, 그 외에 많은 정보가 없었다.
그랬기에 교육 내용은 더욱 충격적이였을지도 모른다. 사실 디자인 패턴이나 아키텍트 패턴 등은
다양하게 접하면서 어느 정도 익숙해져있는 상태였다. 그랬기에 교육 이수 또한 자신있었다.

하지만 교육은 내 생각과는 달랐다. Architect 로써 가져야 하는 역량은 소프트웨어 설계 능력만이 아니였다.
처음 프로젝트를 시작하며, 이해관계자들간의 관계와 그들이 요구하는 사항에 대해 분석해야 한다.

말은 쉽다. '분석하면 되잖아?' 하지만, 이해관계자들은 정확히 자신이 원하는게 무엇인지 알지 못하는 경우가 많다.
버튼이 있었으면 좋겠고, 이뻤으면 좋겠고... 빨랐으면 좋겠고.. 이런 내역들을 모아서 설계하기란 쉽지 않다.
그래서 Architect의 역할이 매우 중요하다. 이해관계자들이 원하는 걸 정확하게 이끌어 내는 방법이 필요하고,
그렇게 모은 정보를 토대로, 제한사항부터, 요구사항 분석과, 기능적/비기능적 요구사항으로 분류하기 시작한다.
그리고 요구사항을 만족할 수 있는 품질속성을 정의하고, 검증을 하기 위핸 방안을 생각한다.
위의 과정들이 잘 끝나야지만, 시스템 / 소프트웨어적으로 설계를 시작할 수 있다.

하지만 이런 내용을 쉽게 접하고 역량을 쌓기란 쉽지 않다. (나는 그랬다.)
이런 내용을 알기 쉽게 정리하고 실습을 할 수 있는 책이 한국어 번역되었다는 것은 기쁜 일이다.
만약 내가 교육에 입과하기 전에 이 책이 출간 되었으면 훨씬 더 많은 도움을 받았을 것 같다.

물론 지금은 자격을 이수하고, 사내에서 Associate Architect 라는 자격으로 활동을 하고 있다.
추후 S/W Architect 인증까지 받고자 하는 목표가 있기에 지금도 꾸준히 관련된 지식을 쌓으려고 노력 중이다.

이 책이 좋은 점은 위에서 말한, 이해관계자들부터, 품질속성, 시스템 설계, 평가까지 다양한 내용을 모두 다루고 있기 때문이다.
그렇기에 Architect 를 꿈꾸고 목표로 하는 현업개발자, 대학생들은 꼭 한번 읽어보길 추천한다.

사실 처음에는 무슨 말인가 이해가 쉽지 않을 수 있다. Architect 책인데, 절반 이상이 UML, 설계 등의 내용보다
다른 내용이 훨씬 많고, 처음보는 내용이라 이해가 어려울 순 있다.

하지만 알면 충분히 큰 도움이 될 거라 생각한다.

물론 아쉬운 건 깊이가 깊지는 않다는 것이지만, 그거야 뭐, 깊이까지 바란다는건 욕심이 과한거라 생각한다.
욕심부리다 체할 수도 있으니까.. 첫 발은 뗀다는 정도까지만 생각하자.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

어떻게 하면 구현할 수 있을까?

더 좋은 방법이 있지 않을까?

개발을 업으로 하다보면 흔히 하는 생각이다.

하지만 개발자로 일하다 보면 어느순간 구현하는 것보다 다른일이 더 많다(혹은 중요하다)고 생각하는 순간이 온다.

그러면 이런 생각을 더 많이 하게 되는것 같다.

왜 이런 코드들이 필요할까?

꼭 이렇게 해야 할끼?

어떻게 코드를 짜야 할까?

기능을 구현보다 다른 부분에 신경이 쓰이기 시작했다면 이제 시니어가 되어가고 있다고 생각한다.

대부분의 개발자들이 처음 일을 시작한 초짜시절에는 주어진 일을 처리하는데에 매달리다보니 주변을 둘러볼 여유가 없었을 것이다.

나도 마찮가지였다. 단지 주어진 임무를 완수하면 최고라고 생각했었다.

그러다 언젠가 현업사용자를 만족시켜야 한다는 생각을 갖게 됐다.

원하는 기능을 만들어주는 것이 우선이겠지만, 그 좀더 편하게 혹은 맥락에 맞는 기능을 추가 해줄때 사용자들을 더욱 만족시켜줄 수 있었던것 같다.

그렇게 개발하다보니 단순히 필요한 기능보다 더 많은 것을 생각하게 되었다.

아래 그림을 일찍 깨닫는것이 좋은 개발자로 가는 지름길이라 생각한다.

불행하게도 나는 이걸 좀 늦게 깨달았다.

사실 내가 짜는 코드, 만들고 있는 S/W에는 많은 사람들이 얽혀 있다.

이들의 원하는 바가 다 다른 경우가 대부분이다.

저자는 이해관계자들 사이에서 최적의 길을 찾는 사람이 아키텍트라 말하고 있다.

그리고 그 일을 도와줄 여러 사례와 기법을 소개하고 있다.

주니어 개발자라면 한번쯤 읽어보시길 추천한다. 여러모로 앞날에 도움이 되리라 생각한다.

시니어 개발자거나 PO라면, 여러 엑티비티를 소개한 3부만 읽어보아도 좋은 책이다.

세상에는 많은 기술들이 소개되어있고, 빠르게 발전하고 있다.

그런 많은 기술들 중에서 현재 상황에서 적절한 것을 제안하고, 팀을 끌고 갈수 있는 능력이야 말로 개발자로서 롱런하기 위한 핵심능력이 될 것이다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

2021년 6월에 출간된 <개발자에서 아키텍트로>에 대해 알아보겠습니다. 이 책의 역자이신 '김영재'님의 페이스북에서 이 책이 출간된다는 소식을 듣고 개인적으로 기대하고 있던 책입니다. 

이 책의 저자는 마이클 킬링이며, 역자는 김영재 님입니다. 번역은 김영재 님이 많은 고민을 하며 번역한 것을 알고 있었고, 제가 읽기에 매끄럽게 잘 읽혔으니 대부분 번역 품질에 대한 문제를 겪진 않을 것으로 생각합니다. 

<개발자에서 아키텍트로>는 약 400여 페이지로 구성되어 있어 휴대하면서 읽을 수 있는 책입니다. 또한, 이 책은 전차잭으로도 만나볼 수 있음으로 전자책 뷰어가 있으신 분은 전자책으로 보셔도 좋을 것 같습니다. 
 

이 책의 매력은?

일반적으로 아키텍트가 지녀야 할 능력은 다양합니다. 자신의 분야에서 누구에게나 인정을 받을 수 있는 능력을 기본으로 갖춰야 합니다. 이 책의 주제인 소프트웨어 아키텍처로 보면 훌륭한 코딩 실력일 것입니다. 이뿐만 아니라, 아키텍처는 기본 소양과, 지식(기술), 경험 등이 필요합니다. 

<개발자에서 아키텍트로>는 3개 파트와 17개의 챕터로 구성되어 있습니다. 두 번째 파트에서는 아키텍처가 지녀야 할 기본 소양과 지식 등을 소개하고, 세 번째 파트에서는 상황에 필요한 해법을 찾기 위한 다양한 방법론을 소개합니다. 이미 활용하고 있던 지식/도구도 있었고, 이 책으로 새로 배운 지식/도구도 있었습니다.

이 책은 아키텍처로 나아가는 입문서라고 볼 수 있습니다. 하지만 이 책에서 다루는 내용은 개인적인 의견으로 가볍지 않다고 생각합니다. 모든 분야든지 기본이 제일 중요하듯이 이 책에서 다루는 내용을 자신의 것으로 만들기에는 많은 노력과 훈련이 필요합니다. 서두르지 말고 환경에 알맞게 조금씩 적용해 나간다면 아키텍처로 성장하는 자신의 모습을 볼 수 있을 것입니다.

마치면서

<개발자에서 아키텍트로>를 읽는 과정은 즐거웠습니다. 이 책을 읽으면서 평소 고민했었던 부분에 대한 해법을 얻기도 했고, 평소 깊게 생각하지 못했던 부분도 깨닫게 되었습니다. 저자의 의견과 방법에 공감을 느낀 부분도 있고, 도입을 해야 하는 부분도 있었으며, 다르게 생각한 부분도 있었습니다. 

이 책에서 저자가 전달하고자 하는 내용을 기반으로 조직에 알맞게 개선하고, 적재적소에 적용하면 좋은 결과를 얻을 수 있을 것 같습니다. <개발자에서 아키텍트로>는 소프트웨어 아키텍처에 대해 배우고 싶은 분들에게 괜찮은 지침서가 될 것으로 생각합니다. 좋은 책을 출간해 주셔서 감사드립니다. 

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

잘 만들어진 소프트웨어는 결국 유지보수를 하거나, 소프트웨어를 확장할 때 판가름된다. 처음부터 마감일에 쫓겨 변화에 유연한 대응이 힘든 구조로 작업이 진행되기도 하고, 그 당시에는 최적의 설계라고 여겨졌으나, 시간이 지나서 보니 유연하지 못한 부분이 보이기도 하는 등 그만큼 좋은 설계를 하는 것은 어렵다. 하지만 어느 연차 이상이 되면 아키텍처를 설계하는 능력이 요구되기도 하고, 연차가 쌓이며 스스로의 작업물에 대해 그 필요성을 느끼게 되기도 한다. 

이 책의 저자 또한 반강제로 아키텍트가 되었다고 말하고 있는데 그렇게 덜컥 소프트웨어 아키텍트가 된 사람의 입장에서 아키텍트가 어떤 일을 하는 지, 왜 소프트웨어 아키텍트를 더 잘 알아야하는지에 대해 각각 개발자와 기술 리더 관점에서 집요하다 싶을만큼 차근차근 전달해간다.

​

처음에 소프트웨어 아키텍트를 디자인 패턴과 같은 코드 설계 관점과 유사한 것으로 생각하고 이 책을 펼쳤기에, 예제 코드보다 이론에 가까운 내용으로 가득차있어 반전을 느꼈다. 이 또한 읽는 나 역시 소프트웨어 아키텍트에 대한 명확한 개념이 없다는 것을 반증하고 있다고 생각한다.

​

저자가 말하는 아키텍트는 결국 이해관계자, 사용자와 닿아있다. 높은 품질을 달성하는 여러 설계 기법이 소개되지만 이는 결국 효율적인 협업의 방식을 말하는 것과도 유사하다고 여겨졌다. 어떻게 팀을 이끌어야 하는지, 어떻게 자신이 만든 소프트웨어를 설명해야 하는 지 등 각자의 현재 위치에서 더 효율적으로 일을 할 수 있도록 시야를 넓히는 관점에서 읽어보면 좋을 책이다.

​

​

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

< 개발자에서 아키텍트로 > | 마이클 킬링 지음 | 김영재 옮김 | 한빛미디어

소프트웨어 아키텍트의 역할은 중요하지만 아키텍트에 대해 제대로 설명하는 책을 별로 보지 못한 것 같다. 이런 상황에서 이 책은 소프트웨어 아키텍트가 무엇인지와 어떤 역할을 해야 하는지를 잘 설명해 주고 있다.

소프트웨어 아키텍트는 단순한 프로그램 매니저가 아니라 소프트웨어가 언제 어떻게 전달되는지를 결정하는 사람이다. 또한 소프트웨어가 비즈니스 목표에 부합하도록 만드는 사람이며, 코딩을 하지만 알고리즘이나 코드를 짜기 보다는 더 크고 많은 것을 설계하는 사람이다. 여러가지 역할에 대한 책임을 지며 동시에 모든 소프트웨어 개발 업무의 중심에 있는 사람으로 볼 수 있다.

소프트웨어 아키텍트는 엔지니어링 관점에서 문제를 정의하고, 시스템은 분리하고 책임은 위임한다. 시스템에 대한 큰 그림을 그리고 품질과 속성의 트레이드오프를 고려하는 사람이다. 기술 부채를 관리하고 팀의 아키텍처 설계 역량을 키우는 사람이다.

이 책은 크게 3부분으로 구성되어 있다. 1부는 소프트웨어 아키텍처에 대한 기본 개념을 설명한다. 소프트웨어 아키텍처의 핵심적인 원리와 설계의 기초를 다룬다. 2부에서는 아키텍처 설계의 기초에 대해 설명한다. 1부에서 설명한 디자인 싱킹의 원칙과 마인드셋을 기반으로 소프트웨어 아키텍처에 이러한 원칙을 적용하는 방법을 설명한다. 3부에서는 아키텍트의 핵심 역할 중의 하나인 이해 관계자의 의견을 받고 동료들의 생각을 정리하는 자신만의 도구상자를 만드는 방법을 설명한다.

아키텍처 설계를 위해서는 다양하고 복잡한 과정을 거치게 된다. 실제 잘 드러나지 않은 무엇인가를 구체화시켜야 한다. 이 책은 아키텍처 설계를 위한 다양한 방법을 소개하고 실제 사례 연구를 샘플로 추가하고 있다. 아키텍처 설계를 위해 가장 먼저 해야하는 일은 설계 전략을 고안하는 것이다. 만족스러운 설계와 설계의 최적점을 찾는 방법에 대해 잘 설명하고 있다. 위험을 관리하기 위해 어떻게 위험을 처리해야 하는지, 그리고 이를 바탕으로 실제 설계 계획을 세우는 방법을 설명하고 있다.

아키텍처 설계시 이해관계자와의 공감은 필수적이다. 이해관계자 맵을 만들고 비즈니스 목표를 공유하는 것이 중요하다. 그 이후에는 아키텍처의 요구사항을 파악하고 기능적인 요구사항과 아키텍처에 영향을 미치는 요소를 잘 선별해야 한다. 이 과정을 거쳐 아키텍처를 선택하고 아키텍처 디자인을 하게 된다. 아키텍처를 문서화하고 평가하는 과정도 필수적이다.

실제 프로젝트에서 유용하게 활용할 수 있는 다양한 방법론과 내용이 잘 설명되어 있는 책으로 생각된다. 이론적인 내용과 실제 업무에 적용할 수 있는 내용이 적절히 조화가 되어 있어서 현업에 적용해 보는 것도 무리없이 가능하다고 생각된다. 소프트웨어 아키텍트를 꿈꾸는 개발자, 그리고 소프트웨어 아키텍처를 설계하는 개발자라면 곁에 두고 종종 참고할 만한 책이라고 생각된다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

안녕하세요~ 오늘 살펴볼 책은 <개발자에서 아키텍트로 38가지 팀 활동을 활용한 실전 소프트웨어 아키텍트 훈련법> 입니다.

먼저 이 책은 굉장히 어렵습니다.

하지만 확실합니다.

여러분들을 발전시켜준다는 것입니다. 더 중요한 것이 있습니다. 올바른 방법과 사례를 보여줄 것입니다.

본격 책을 한번 살펴보도록 하죠.

책에서 보시면 사실 챙겨야 될 문장과 무기들이 너무나도 많습니다.

중요한 것은 어떤 문장을 챙겨갈 것인가입니다.

저는 이 책에서 중요한 노트와 그림을 챙겨가기로 했습니다.

아직 아키텍트가 되기위한 준비가 되지는 않았지만 그 준비과정으로 이 책은 큰 도움을 줄 것이라 확신합니다.

우리는 개발을 하면서, 설계를 하면서 완성도와 정확도를 지켜야합니다.

거기서 발생할 수 있는 원칙이 있습니다.

이 책에서 소개되는 패턴과 원칙은 사례중심적이기 때문에 직접 실무에 적용해볼만 합니다.

책에서 제시하는 방법들은 사실 개별적으로 적합하지 않을 수도 있습니다.

문제는 뭐냐하면 책에서 제시되는 내용을 적용해볼 수 있냐입니다.

일단 적용해보면서 자신의 팀에, 자신에게, 회사에 적합한지 끊임없이 테스트해보는 것입니다.

책에서 다뤄지는 내용을 oop관련 내용, 기술관련 내용도 있으므로 어느정도 프로그래밍 언어에 대한 경험이 있으신 분들에게 추천드립니다.

10독을 권하며 지속적으로 책을 보시면서 자신의 경험에 대조해보길 바랍니다.

[한빛미디어에서 제공 받은 '나는 리뷰어다' 2021년 6월 도서 리뷰입니다]

'분석', '설계', '구현', '테스트', '유지보수'

대학생때부터 배우게 되는 애자일 방법론의 단계이다.

첫 프로젝트를 진행하면서 느낀건, '귀찮다' 였고,

두번째 프로젝트를 진행하면서 느낀건, '이런 틀이 있으니 진행이 수월하군' 이었다.

하지만 다양한 프로젝트를 진행하면서 실전에서 바로 적용 가능한

'프로토타이핑'을 선호하게 되었다.

이처럼 다양한 방법론과 진행방법이 존재한다.

개인적으로 진행하는 프로젝트라면 어떠한 방법론을 이용하든

본인에게 맞는것을 선택하면 되겠지만

팀을 결성하고, 언젠가 팀의 중책을 맡게 될 경우가 생길텐데

이 때 팀을 잘 꾸려가고 프로젝트를 잘 이끌어나가기 위한 직책,

'아키텍트'에 관한 이야기를 다룬 책 '개발자에서 아키텍트로' 을 소개한다.

이 책에서는 일단 아키텍트가 무엇인지부터 설명한다.

'프로그래밍 관리와 전체 시스템이 일관성 있게 동작하도록 하고 품질에 영향을 주는 품질 속성 균형을 잡아야 한다.'

한마디로 말하면

'두루두루 잘해야 한다.'

라는 것이다.

대학 컴퓨터(또는 정보)과에서는 아래와 같은 과목들을 배운다.

'소프트웨어 공학'

'시스템 분석 설계'

프로그램을 어떻게 만들어야 좀 더 완성도 있게 만들 수 있는지에 대한 방법론과

프로그램 개발 시 어떤식으로 진행해야 효율적인 개발이 될 수 있는지에 대한 내용을 배운다.

코딩 실력과 더불어 이런 지식들을 합쳐 만들어진 직함이라고 생각하면 될 것 같다.

- 아키텍트에게 필요한 기술을 차례로 진행

목차를 보고 원하는 내용만 봐도 상관없지만

처음으로 아키텍트를 접하는 개발자라면 차례대로

아키텍트의 능력을 기르게끔 해준다.

마치 스무고개 문답을 하듯 내용이 진행되는데,

아키텍트란 무엇인가? -> 아키텍트를 좀 더 쉽게 접근하려면? -> 아키텍트에게 필요한 능력은?

같이 초반부에는 '아키텍트'라는 것에 대해 익숙해지게끔 하고

문서화, 문제 이해와 해결과 같은 실력이 요구되는 능력을 후반부에 배치해서

실전에 필요한 능력을 알려준다.

또한 새로운 장 시작면에는 제목과 함께 진행하는 주제가 어떤 단계에 해당하는지

'이해', '탐색', '평가', '실현' 4단계로 디자인 마인드셋을 보여주어

사람들이 저마다 어떻게 문제를 푸는지 엿볼 수 있다.

책의 내용을 크게 아래와 같이 3PART로 나눈다.

1PART :  아키텍트에 대해 정의

2PART : 아키텍트가 하는 일

3PART : 실전에서 아키텍트

각 파트별로 어떤 단계에 해당하는지 간략하게 보여줌으로써

진행도를 알게되고 발전하는 느낌을 받게 될 것 같다.

- 꼭 알아야 하는 문장에 색상 표시

새롭게 배울 때 불편한 것 중에 하나를 꼽자면 모르는 단어가 나왔을 때

'이정도라면 독자는 당연히 알겠지' 라며 자연스레 사용될 때일 것이다.

이 책에서는 처음 나오는 단어나 생소한 단어에 푸른색 표시를 주어 강조하고

해당 단어에 대해 설명을 한 뒤 내용을 이어간다.

번역서이기 때문에 한글로만 나타낼 수도 있는데 한글단어 옆에 영어 원문을 표시함으로써

의미가 모호한 단어일 경우 직접 찾아볼 수도 있다(번역가님의 멋진 배려!).

- 실전에서 일어날만한 문제에 대해 접근

1, 2파트에서 아키텍트에 대해 알게되었다면 마지막 파트에선 팀에서 해볼만한 활동을 보여준다.

38가지로 나눠 문제집의 '실전문제' 같은 형식으로 직접 팀에서 해볼 수 있게끔 구성 되어있다.

- 그래서...

이 책을 한마디로 요약하자면 '어렵다'였다.

처음보는 용어들도 많고, 신경써야 할 것도 많고...

아직 리더의 역할을 맡을 시기가 아니라서 그런가보다 했는데,

이 책에 이런말이 나온다.

'만일 여러분의 팀에 아키텍트가 없다면... 네, 축하합니다. 이제 당신이 하면 됩니다!'

우리가 학생으로써 보호받다가 갑자기 어른이라며 사회에 대한 책임을 요구받았을때 처럼

아키텍트는 차근차근 준비를 하다가 맡게 되는 것 보단 어느순간 갑작스레 맡게 되는 경우가 많다는 것이다.

개발자는 개발에 대한 능력이 중요하다고 믿고 있다.

이 책을 읽은 다음에도 변함이 없다.

하지만 많은 경험을 한 뒤 어떤 팀을 맡게 되는 리더가,

어떤 프로젝트를 맡는 책임자가 되는 순간은 찾아온다.

갑작스레 찾아올 미래에 당황하지 않고

멋진 어른으로써 당당하게 아키텍트라는 명함을 달 때를 위해

많은 개발자들이 이 책을 한번쯤은 읽어보면 좋을 것 같다.

[주요 내용]

- 소프트웨어 아키텍처란 무엇이고 아키텍트는 무슨 일을 하는가

- 디자인 싱킹과 디자인 마인드셋을 활용한 아키텍처 설계 전략

- 이해관계자와 비즈니스 목표를 명확하게 파악하고 이해하기

- 아키텍처 핵심 요구사항을 파악하고 품질 속성 정의하기

- 자주 사용하는 아키텍처 패턴과 사용법

- 아키텍처 모델을 활용해 시스템 복잡도 관리하기

- 아키텍처 디자인 스튜디오 운영하기

- 설계를 시각화하고 아키텍처 문서화하기

- 아키텍처를 평가하고 피드백을 반영해 개선하기

- 적절하게 설계 권한을 위임하며 팀의 역량 높이기

- 현업에서 바로 활용 가능한 38가지 팀 활동

[대상 독자]

- 개발자에서 아키텍트로 커리어를 변경하고 싶은 사람

- 소프트웨어 아키텍처를 제대로 이해하여 실무 개발 능력을 향상하고 싶은 사람

- 소프트웨어의 전체 구조 및 개발 과정 전체를 이해하고 싶은 신입 개발자

- 소프트웨어를 둘러싼 다양한 이해관계자들의 관점을 이해해보고 싶은 사람

[개발 경력별 이 책의 활용법]

- 신입 개발자: 단순히 코드를 짜는 일을 뛰어넘어, 소프트웨어 개발 및 프로젝트이라는 숲을 보며 시야를 넓혀보세요.

- 5년 이하 경력의 개발자/아키텍트: 흔히 쓰는 패턴, 모델, 설계 방식을 이해하고, 아키텍처를 시각화하고 문서화하는 방법을 배우세요. 사람들과 협업할 때 어려움을 겪는다면, 사례 탐구와 경력 있는 아키텍트들의 기고문을 통해 지혜로운 방법을 찾아보세요.

- 10년 이상 경력의 개발자/아키텍트: 아키텍트로서 프로젝트를 직접 이끌거나 개발 팀장의 역할을 수행해야 하나요? 팀원 및 이해관계자와 제대로 커뮤니케이션 하는 방법을 익혀보세요. 문제를 해결하기 위해 해볼 만한 활동을 찾아보고 책에서 소개하는 방법을 직접 따라해보세요. 금세 해결책을 찾을 수 있을 겁니다.

[서평]

1부에서는 소프트웨어 아키텍트가 하는 일을 소개하며, 소프트웨어 아키텍처를 정의합니다. 2부에서는 본격적으로 아키텍처를 설계하고, 이해관계자와 소통하며, 아키텍처 핵심 요구사항을 알아내 설계에 반영하는 방법을 알아봅니다. 아키텍처 패턴은 물론 설계를 시각화하고 아키텍처를 문서화 하는 방법도 다룹니다. 3부에서는 아키텍처를 설계하며 문제 상황을 마주했을 때, 해결책을 찾아야 할 때, 설계를 더 구체화하고 싶을 때 해볼수 있는 38가지 침 활동을 소개합니다. 필요한 부분을 골라 읽어도 좋지만, 개발자에서 아키텍트로 첫걸음을 시작하는 분이라면 처음부터 순서대로 읽기는 것을 추천 합니다. 팀에서 해볼 만한 활동을 찾는다면 3부를 훑어보며 고라봐도 좋겠습니다. 

이 책은 화이트보드 앞에 서서 복잡한 질문에 여러 가지 도형과 선을 그리면서 답변해야 하는 사람들에게 어울립니다. 또한 소프트웨어 설계를 처음 접하는 사람에게도 좋은 안내서가 될것입니다. 이책의 앞부분에서는 기본 지식을 정리하고, 그다음에는 훌륭한 소프트웨어 아키텍트라면 알아야 할 핵심 지실을 하나씩 설명하고 있습니다. 책을 읽다보면 느낌으로는 알고 있었지만 이름을 몰랐던 개념을 확인 할수 있고, 알고 있던 내용과 실제 지식 간의 차이를 발견할수 있습니다. 개발하는데 왜 필요한지 설명 할수 있게 되면서 다른 사람들을 설득하거나 팀을 더 잘 이끌 수도 있습니다. 아키텍트로 이런류의 책을 이미 읽어본 독자라면, 팀을 이끄는 새로운 관점을 배울수 있을 것입니다. 주니어 개발자라면 자신이 만들려는 소프트웨어를 더 잘 설명 할수 있을것이고, 또한 이책은 개발자이자 미래에 아키텍트가 될 사람을 가르치고 이끌어 설계 과정에 온전히 참여하도록 하는데 초점이 맞춰져 있습니다. 경험이 부족한 동료와 함께 시스템을 설계해도, 안전하고 생산적인 결과를 낼 수 있게 하는 여러 가지 협력적인 설계 방법도 배울수 있습니다.

소프트웨어 아키텍처에 대해 배우고 싶은 개발자라면 좋은 지침서가 될 것이라 생각합니다. 

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

[ 선택 이유 ] 

이제 자바스크립트 코드는 좀 눈에 들어온다. 그래서 요새는 구조, 아키텍쳐에 대해 고민을 하고 또 설계하고 있다.

업무에서도 슬슬 설계관련된 것을 하다보니 부족한 점이 많이 보이는데, 대부분 물어보니 하면서 배우는 거라고 하시더라.

하지만 나는 하면서 배우는 것도 좋지만, 일단 어느정도 기초지식과 배경을 가지고 시작하는 것을 선호한다. 그래서 책이 필요했고 읽게 되었다.

[ 본문 ] 

일단 내가 느끼기에 책이 난해하다. 프로그래밍 언어처럼 확실한 구조를 지닌 문법을 가지고 있는 것도 아니요.

언어가 가진 특별한 특징도 없다. 그래서 나에게 난해하다

그나마 다행인점은 난해할 거같은 나같은 독자를 위해 라이언하트 프로젝트를 통해 사례를 들고 어떤식으로 구체화해가는지 확장해간다.

이 책을 읽고 난후 나는 어느정도 규모있는 기능을 구현하고자 할때 좀더 신중해졌다.

설계<->구현<->유지보수의 시간분할은 필연적이다. 하지만 나는 설계는 그렇게 중요하지 않다고 생각했다. 전체적인 구조는 머리속으로 빠르게 그리고 그 시간에 구현을 하는게 올바른 개발자라고 생각했지만 요새 규모가 있는 개발을 하다보니 나는 똑똑하지 않는 개발자라는 확신??이 들었다.

그래서 설계가 필요하고 정리가 필요하다. 그런만큼 이 책은 많은 도움이 되었다.

내가 생각하는 개발자는 총 5단계가 있다. 1단계 낫휴먼부터 (초급,중급,고급) 5단계 개발자까지이다.

그중에 2단계가 초급 개발자의 단계인데, 기능을 구현하라고 하면 어떻게든 구현해오는 단계이다.

3단계는 기능을 구현하면서 유지보수, 리펙토링, 협업을 신경쓰는 단계이다.

이 책은 2->3단계으로 가는 길을 넌지시 알려주는 책이다. 이번 책을 읽고 협업을 하고 싶은 개발자가 되길 스스로 기대한다.

   개발을 하다 보면 프로젝트에 참여한 아키텍트를 보면서 나도 언젠가는 될 수 있을까? 라는 생각을 가지거나 아키텍트의 높은 연봉을 부러워하기도 합니다. 혹은 별로 하는 것도 없는데 돈만 많이 받아간다고 생각될 수도 있습니다.

   그러나 어느정도 개발경력이 쌓이고 난 후에도 아키텍트가 되려면 어떤 것을 알아야 하고, 어떻게 공부해야 할 지 알려주는 사람도 없고 관련내용을 찾아보기가 쉽지 않습니다. 이 책은 설계를 위해서 필요한 내용이나 pattern, design, 방법론 등을 알려주는 입문서입니다.

   책을 절반 정도 읽게 되면 PART 3에서 38개의 활동을 소개합니다. 문제를 이해하고 싶고, 해결하고 싶고, 실제 아키텍처를 만들 때, 평가하고 싶을 때 등 4가지로 분류해서 각 10가지 정도의 내용을 알려줍니다. 쉽게 말씀드리면 이론 반 실무 반 정도로 구성되어 있다고 볼 수 있습니다.

   아키텍처에 대한 교육을 듣거나 아키텍트였거나 활동 중인 분들의 이야기를 들어보면 아키텍트를 하기 위해선 폭넓은 지식이 필수적이지만 그보다 더 중요한 것이 다양한 경험이라고 합니다. 실제로 설계할 때나 고객들과의 의사소통 시 일반적이지 않은 경우들을 마주하게 되고, 그것을 잘 해결하고 해결한 경험을 가지고 있는 것이 곧 그 사람의 실력이자 연봉이라고 합니다.

   이 책에서 모든 이론을 소개해주는 것은 아니지만 아키텍트를 수행하기 위해서 고려해야 할 요소들에 대해서 알려주어 길잡이 역할을 한다고 볼 수 있을 것 같습니다. 그리고 이론을 소개한 후에는 항상 “사례 연구”로 실제 사례처럼 비유하여 서술하고, “마무리”를 통해서 요약 정리해줍니다.

   또한 모든 경우를 소개하는 것은 아니지만 절반 정도의 분량을 할애하여 아키텍트를 수행하면서 고민하거나 수행해야 할 경우에 대해서 미리 알려주어 훈련해볼 수 있게 해 줍니다. 이 책의 특징이자 장점이라고 생각합니다. 아키텍트가 되고 싶다면 그냥 읽고 넘기지 말고 꼭 해보시기 바랍니다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

저자: 마이클 킬링

옮김: 김영재

#책소개

개발자에서 아키텍트로 거듭나기! 초보 아키텍트를 위한 실전 입문서

이 책은 개발자에서 아키텍트로, 변화의 첫걸음을 내딛는 이를 위한 실전 입문서다. 설계를 위한 필수 지식, 아키텍처 패턴, 모델, 설계 방법론, 커뮤니케이션 노하우를 상세히 소개한다. 문제 상황에서 팀원들과 해볼 수 있는 38가지 팀 활동을 소개하며 실무 적응 능력을 키워준다.

아키텍처를 잘 모르는 개발자라면, 이 책을 읽으며 개발 업무의 구조를 이해하는 실력을 향상할 수 있다. 현업 아키텍트라면, 결정사항을 잘 설명하여 팀을 이끌고 이해관계자와 소통하는 능력을 키울 것이다. 이 책과 함께 프로젝트와 팀을 성공으로 이끄는 훌륭한 아키텍트로 거듭나길 바란다.

라고 교보문고가 소개하더이다.

# 이 책의 특징

1. 상세하면서도 일목요연하게 쓰여있다.

사실 책을 읽는 순서는 딱히 정해져있지 않다.. 웬만해서는

하지만 무엇인가 순차적으로 정보를 줄 때에는 정방향 구성을 하기 마련이고 

그렇게 되면 앞을 읽지 않았을 때 뒷 내용이 전혀 이해가 되지 않는 경우도 발생하는데..?

그리고 앞에 내용이 있다지만 그것도 어디에 있는지 몰라서 고생하는 경우가 있는데..

이 책은 골라 읽어도, 순차적으로 읽어도 한 눈에 들어오는 구성을 가지고 있다.

2. 적절한 예시

구조적 관점에서 바라본다는 것이 새롭지 않으면서도 새로운 분야인데적절한 예시로 이해를 도왔고 중간 중간 용어 설명이나 보충 설명들이 실제 공부하다보면 생기는 의문점이라책만으로도 해결이 되는 것이 맘에 들었다.

#후기

사실 아키텍쳐 분야가 더 돈 많이 번다.

어셈블리어가 공부하려는 사람은 적지만 정말 필요한 것처럼..

밑바닥이 불편해보이지만 아주 필요한 부분이다.

피라미드랄까..? 제일 낮은 곳에 위치하지만 윗부분을 전부 떠받치는 것은 밑부분이다.

무엇인가 만들 때도 마찬가지이다.

설계가 제일 중요하다.

요구 사항을 모두 충족시키면서도 일어날 수 있는 모든 상황에 대해서 한 번 생각해보고실제 어떻게 구현하면 유지보수가 편해지고 호환성이 좋아 아무 곳에서 실행되는.. 그런 프로그램을 만들기 위해서는 설계이 전체의 7할 이상의 시간을 쏟아부어야 한다.

솔직히 이 책을 읽는다고 갑자기 아키텍쳐에 관한 전문지식이 생기거나 그러는 것은 아니다.다만 이러한 관점도 있구나 하면서 새로운 관점을 머리에 입력되는 것은 사실이다.이는 실제 아키텍쳐를 설계하게 될 때에도 도움을 줄 것이며 내가 개발할 때 무엇을 염두하고 하느냐에 도움을 주기 때문에 코딩 스타일이 효율적으로 바뀔 수도 있다고 생각한다.

물론 내 생각.

아래 만화를 보면서 설계의 중요성을 알아보자.사실

아래는 언어 별 특징을 알려주는 프로그래밍 만화지만... 안타까운건 자기가 아는 언어만 이해한다는 거..ㅎ

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."