From 28173cd901d650daba09d3e3ef59e6ecafe9897f Mon Sep 17 00:00:00 2001 From: mononomo Date: Mon, 9 Dec 2024 20:24:26 +0900 Subject: [PATCH 1/8] Create mono.md --- .../mono.md" | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 "ch22.\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" diff --git "a/ch22.\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" "b/ch22.\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" new file mode 100644 index 0000000..8573d0d --- /dev/null +++ "b/ch22.\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" @@ -0,0 +1,86 @@ +# 22. 개발팀을 효율적으로 + +## 22.1 팀경계 + +우리는 경험상 소프트웨어 아키텍트가 개발팀의 성패를 좌우할 만큼 지대한 영향력을 갖고있다고 생각합니다. 스스로 정상 궤도에서 벗어났거나 소프트웨어 아키텍트로 부터 멀어졌다고 느끼는 개발팀은 대부분 시스템의 다양한 제약조건을 제대로 알지 못하고 경험도 없기 때문에 아키텍처를 올바르게 구현하지 못 합니다. + +유능한 소프트웨어 아키텍트는 팀이 올바른 도구와 라이브러리로 무장하여 아키텍처를 잘 구현할 수 있도록 적절한 지침과 제약조건을 제공합니다. + +## 22.2 아키텍트성향 + +### 22.2.1 내 맘대로 아키텍트 + +내 맘대로 아키텍트는 경계를 아주 빡빡하게 설정합니다. 그리고 개발팀이 알아서 쓸법한 오픈소스나 서드 파티 라이브러리를 마음대로 내려 받아 사용하지 못 하게 하면서 개발팀이 언어API를 이용해 모든 것을 처음부터 개발하라고 우깁니다. + +특히, 개발자에서 아키텍트로 전향한 사람들이 이런 아키텍트가 되기 쉽습니다. + +아키텍트는 프로젝트의 복잡성과 팀기술 수준에 따라 내맘대로 아키텍트라는 악역을 맡아야 할 때도 있습니다. + +### 22.2.2 유체 이탈 아키텍트 + +유체 이탈 아키텍트는 꽤 오랫동안(어쩌면 단 한번도 제대로)코딩을 한적이 없는, 아키텍처를 수립할 때 세부 구현사항은 거의 나몰라라 하는 아키텍트입니다. + +유체이탈 아키텍트는 앞절에서 설명했듯이 개발팀 주위에 아주 느슨하게 경계를 설정합니다. + +- 비즈니스영역, 비즈니스문제, 기술을 온전히 이해하지 못 한다. +- 소프트웨어 개발 실무경력이 부족하다. +- 아키텍처 솔루션 구현에 함축된 의미를 전혀 신경쓰지 않는다. + +어쨌든 이런 아키텍트가 되지 않으려면 프로젝트에서 쓰이는 기술에 더 많이 관여하고 비즈니스 문제/영역을 잘 이해하려고 노력해야 합니다. + +### 22.2.3 유능한 아키텍트 + +개발팀을 잘 이끄는 유능한 리더가 되는 것은 일종의 예술입니다. + +## 22.3 얼마나 제어 해야하나? + +팀원 간 친밀도 + +팀원들이 서로 얼마나 잘 알고 있나요? 전에도 프로젝트를 함께한 사람들인가요? 일반적으로 팀원들이 서로 잘아는 사이라면 이미 스스로 조직화하기 시작되므로 제어가 덜 필요하고, 그 반대 일수록 팀원 간 협업을 촉진 하고 팀내 파벌을 없애기 위해 더 많은 제어가 필요합니다. + +팀 규모 + +팀 규모가 어느 정도인가요. 팀이 커질수록 더 많은 제어가 필요하고, 팀이 작을수록 제어가 덜 필요합니다. + +전체적인 경험 + +팀원 중 시니어급은 몇명이나 있나요? 주니어 개발자가 많은 팀은 제어와 멘토링이 더 필요하고, 시니어 개발자가 더 많은 팀은 아무래도 제어가 덜 필요합니다. + +프로젝트 복잡도 + +복잡도가 높은 프로젝트를 수행하려면 아키텍트가 팀에 더 많이 관여하여 갖가지 이슈를 처리해야 할테니 팀에 더많은 제어를 가할 수 밖에 없습니다. 비교적 단순한 프로젝트는 그 자체로 간단하니 별로 제어할 필요가 없겠죠. + +프로젝트 기간 + +프로젝트 기간이 길수록 더 많은 제어가 필요하고 프로젝트 기간이 짧을수록 제어는 덜 필요합니다. + +보통 프로젝트를 처음 시작할때 이팩터들을 토대로 제어 수준을 결정합니다. 그러나 시스템이 진화할 수록 제어 수준도 달라지기 마련이므로 프로젝트 내내 이팩터들을 지속적으로 분석하여 개발팀을 어느 정도까지 제어할지 결정 하는게 좋습니다. + +## 22.4 팀의 이상징후 + +가장 효율적인 개발팀의 규모는 다음 세 가지 팩터에 의해 결정됩니다 + +- 프로세스 손실 + - 기본적으로 프로젝트에 인력을 더 많이 투입할수록 프로젝트를 수행하는 시간이 더 길어진다는 것입니다. + - 프로세스 손실을 방지하려면 팀내부적으로 병렬작업이 가능한 부분을 찾고 팀원들이 각자 별도의 서비스나 애플리케이션 영역에서 작업할 수 있게끔 환경을 제공해야 합니다. +- 다원적 무지 + - 모든 사람들이 자신이 뭔가 너무 뻔한것을 놓치고 있는게 아닐까 두려운 나머지 어떤 표준에 순순히 동의하는 현상입니다. +- 책임 확산 + - 팀 규모가 커질수록 의사소통이 잘 안되는건 모두가 공감하는 팩트입니다. + +## 22.5 체크리스트활용 + +체크리스트는 정말로 효과가 있습니다. + +## 22.6 지침제시 + +유능한 소프트웨어 아키텍트는 다음 질문에 개발자가 먼저 답하도록 유도함으로써 개발팀에 지침을 제시합니다. + +- 제안하신 라이브러리와 기존시스템의 내부 기능사이에 중첩되는 부분이 있나요. +- 제안하신 라이브러리를 반드시 사용해야 하는 당위성은 무엇인가요? + +## 22.7 마치며 + +개발팀을 잘 굴러가게 만들기란 참으로 어렵습니다. + +이런 활동을 하는 아키텍트의 역할에 의문을 제기하고 팀을 효과적으로 만드는 책임을 PM이나 개발 관리자에게 일임하는 사람도 있습니다. 우리는 강력히 반대합니다. From f8eaf81d550ecb03fe1e5c7aa524bd59b6fff032 Mon Sep 17 00:00:00 2001 From: mononomo Date: Mon, 9 Dec 2024 20:24:45 +0900 Subject: [PATCH 2/8] =?UTF-8?q?Delete=20ch22.=EA=B0=9C=EB=B0=9C=ED=8C=80?= =?UTF-8?q?=EC=9D=84=5F=ED=9A=A8=EC=9C=A8=EC=A0=81=EC=9C=BC=EB=A1=9C=20dir?= =?UTF-8?q?ectory?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../mono.md" | 86 ------------------- 1 file changed, 86 deletions(-) delete mode 100644 "ch22.\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" diff --git "a/ch22.\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" "b/ch22.\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" deleted file mode 100644 index 8573d0d..0000000 --- "a/ch22.\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" +++ /dev/null @@ -1,86 +0,0 @@ -# 22. 개발팀을 효율적으로 - -## 22.1 팀경계 - -우리는 경험상 소프트웨어 아키텍트가 개발팀의 성패를 좌우할 만큼 지대한 영향력을 갖고있다고 생각합니다. 스스로 정상 궤도에서 벗어났거나 소프트웨어 아키텍트로 부터 멀어졌다고 느끼는 개발팀은 대부분 시스템의 다양한 제약조건을 제대로 알지 못하고 경험도 없기 때문에 아키텍처를 올바르게 구현하지 못 합니다. - -유능한 소프트웨어 아키텍트는 팀이 올바른 도구와 라이브러리로 무장하여 아키텍처를 잘 구현할 수 있도록 적절한 지침과 제약조건을 제공합니다. - -## 22.2 아키텍트성향 - -### 22.2.1 내 맘대로 아키텍트 - -내 맘대로 아키텍트는 경계를 아주 빡빡하게 설정합니다. 그리고 개발팀이 알아서 쓸법한 오픈소스나 서드 파티 라이브러리를 마음대로 내려 받아 사용하지 못 하게 하면서 개발팀이 언어API를 이용해 모든 것을 처음부터 개발하라고 우깁니다. - -특히, 개발자에서 아키텍트로 전향한 사람들이 이런 아키텍트가 되기 쉽습니다. - -아키텍트는 프로젝트의 복잡성과 팀기술 수준에 따라 내맘대로 아키텍트라는 악역을 맡아야 할 때도 있습니다. - -### 22.2.2 유체 이탈 아키텍트 - -유체 이탈 아키텍트는 꽤 오랫동안(어쩌면 단 한번도 제대로)코딩을 한적이 없는, 아키텍처를 수립할 때 세부 구현사항은 거의 나몰라라 하는 아키텍트입니다. - -유체이탈 아키텍트는 앞절에서 설명했듯이 개발팀 주위에 아주 느슨하게 경계를 설정합니다. - -- 비즈니스영역, 비즈니스문제, 기술을 온전히 이해하지 못 한다. -- 소프트웨어 개발 실무경력이 부족하다. -- 아키텍처 솔루션 구현에 함축된 의미를 전혀 신경쓰지 않는다. - -어쨌든 이런 아키텍트가 되지 않으려면 프로젝트에서 쓰이는 기술에 더 많이 관여하고 비즈니스 문제/영역을 잘 이해하려고 노력해야 합니다. - -### 22.2.3 유능한 아키텍트 - -개발팀을 잘 이끄는 유능한 리더가 되는 것은 일종의 예술입니다. - -## 22.3 얼마나 제어 해야하나? - -팀원 간 친밀도 - -팀원들이 서로 얼마나 잘 알고 있나요? 전에도 프로젝트를 함께한 사람들인가요? 일반적으로 팀원들이 서로 잘아는 사이라면 이미 스스로 조직화하기 시작되므로 제어가 덜 필요하고, 그 반대 일수록 팀원 간 협업을 촉진 하고 팀내 파벌을 없애기 위해 더 많은 제어가 필요합니다. - -팀 규모 - -팀 규모가 어느 정도인가요. 팀이 커질수록 더 많은 제어가 필요하고, 팀이 작을수록 제어가 덜 필요합니다. - -전체적인 경험 - -팀원 중 시니어급은 몇명이나 있나요? 주니어 개발자가 많은 팀은 제어와 멘토링이 더 필요하고, 시니어 개발자가 더 많은 팀은 아무래도 제어가 덜 필요합니다. - -프로젝트 복잡도 - -복잡도가 높은 프로젝트를 수행하려면 아키텍트가 팀에 더 많이 관여하여 갖가지 이슈를 처리해야 할테니 팀에 더많은 제어를 가할 수 밖에 없습니다. 비교적 단순한 프로젝트는 그 자체로 간단하니 별로 제어할 필요가 없겠죠. - -프로젝트 기간 - -프로젝트 기간이 길수록 더 많은 제어가 필요하고 프로젝트 기간이 짧을수록 제어는 덜 필요합니다. - -보통 프로젝트를 처음 시작할때 이팩터들을 토대로 제어 수준을 결정합니다. 그러나 시스템이 진화할 수록 제어 수준도 달라지기 마련이므로 프로젝트 내내 이팩터들을 지속적으로 분석하여 개발팀을 어느 정도까지 제어할지 결정 하는게 좋습니다. - -## 22.4 팀의 이상징후 - -가장 효율적인 개발팀의 규모는 다음 세 가지 팩터에 의해 결정됩니다 - -- 프로세스 손실 - - 기본적으로 프로젝트에 인력을 더 많이 투입할수록 프로젝트를 수행하는 시간이 더 길어진다는 것입니다. - - 프로세스 손실을 방지하려면 팀내부적으로 병렬작업이 가능한 부분을 찾고 팀원들이 각자 별도의 서비스나 애플리케이션 영역에서 작업할 수 있게끔 환경을 제공해야 합니다. -- 다원적 무지 - - 모든 사람들이 자신이 뭔가 너무 뻔한것을 놓치고 있는게 아닐까 두려운 나머지 어떤 표준에 순순히 동의하는 현상입니다. -- 책임 확산 - - 팀 규모가 커질수록 의사소통이 잘 안되는건 모두가 공감하는 팩트입니다. - -## 22.5 체크리스트활용 - -체크리스트는 정말로 효과가 있습니다. - -## 22.6 지침제시 - -유능한 소프트웨어 아키텍트는 다음 질문에 개발자가 먼저 답하도록 유도함으로써 개발팀에 지침을 제시합니다. - -- 제안하신 라이브러리와 기존시스템의 내부 기능사이에 중첩되는 부분이 있나요. -- 제안하신 라이브러리를 반드시 사용해야 하는 당위성은 무엇인가요? - -## 22.7 마치며 - -개발팀을 잘 굴러가게 만들기란 참으로 어렵습니다. - -이런 활동을 하는 아키텍트의 역할에 의문을 제기하고 팀을 효과적으로 만드는 책임을 PM이나 개발 관리자에게 일임하는 사람도 있습니다. 우리는 강력히 반대합니다. From 84879eb06fbed3610dbf5f5f30ca025bcc2e7f72 Mon Sep 17 00:00:00 2001 From: mononomo Date: Mon, 9 Dec 2024 20:25:07 +0900 Subject: [PATCH 3/8] Create mono.md --- .../mono.md" | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 "ch022_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" diff --git "a/ch022_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" "b/ch022_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" new file mode 100644 index 0000000..8573d0d --- /dev/null +++ "b/ch022_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" @@ -0,0 +1,86 @@ +# 22. 개발팀을 효율적으로 + +## 22.1 팀경계 + +우리는 경험상 소프트웨어 아키텍트가 개발팀의 성패를 좌우할 만큼 지대한 영향력을 갖고있다고 생각합니다. 스스로 정상 궤도에서 벗어났거나 소프트웨어 아키텍트로 부터 멀어졌다고 느끼는 개발팀은 대부분 시스템의 다양한 제약조건을 제대로 알지 못하고 경험도 없기 때문에 아키텍처를 올바르게 구현하지 못 합니다. + +유능한 소프트웨어 아키텍트는 팀이 올바른 도구와 라이브러리로 무장하여 아키텍처를 잘 구현할 수 있도록 적절한 지침과 제약조건을 제공합니다. + +## 22.2 아키텍트성향 + +### 22.2.1 내 맘대로 아키텍트 + +내 맘대로 아키텍트는 경계를 아주 빡빡하게 설정합니다. 그리고 개발팀이 알아서 쓸법한 오픈소스나 서드 파티 라이브러리를 마음대로 내려 받아 사용하지 못 하게 하면서 개발팀이 언어API를 이용해 모든 것을 처음부터 개발하라고 우깁니다. + +특히, 개발자에서 아키텍트로 전향한 사람들이 이런 아키텍트가 되기 쉽습니다. + +아키텍트는 프로젝트의 복잡성과 팀기술 수준에 따라 내맘대로 아키텍트라는 악역을 맡아야 할 때도 있습니다. + +### 22.2.2 유체 이탈 아키텍트 + +유체 이탈 아키텍트는 꽤 오랫동안(어쩌면 단 한번도 제대로)코딩을 한적이 없는, 아키텍처를 수립할 때 세부 구현사항은 거의 나몰라라 하는 아키텍트입니다. + +유체이탈 아키텍트는 앞절에서 설명했듯이 개발팀 주위에 아주 느슨하게 경계를 설정합니다. + +- 비즈니스영역, 비즈니스문제, 기술을 온전히 이해하지 못 한다. +- 소프트웨어 개발 실무경력이 부족하다. +- 아키텍처 솔루션 구현에 함축된 의미를 전혀 신경쓰지 않는다. + +어쨌든 이런 아키텍트가 되지 않으려면 프로젝트에서 쓰이는 기술에 더 많이 관여하고 비즈니스 문제/영역을 잘 이해하려고 노력해야 합니다. + +### 22.2.3 유능한 아키텍트 + +개발팀을 잘 이끄는 유능한 리더가 되는 것은 일종의 예술입니다. + +## 22.3 얼마나 제어 해야하나? + +팀원 간 친밀도 + +팀원들이 서로 얼마나 잘 알고 있나요? 전에도 프로젝트를 함께한 사람들인가요? 일반적으로 팀원들이 서로 잘아는 사이라면 이미 스스로 조직화하기 시작되므로 제어가 덜 필요하고, 그 반대 일수록 팀원 간 협업을 촉진 하고 팀내 파벌을 없애기 위해 더 많은 제어가 필요합니다. + +팀 규모 + +팀 규모가 어느 정도인가요. 팀이 커질수록 더 많은 제어가 필요하고, 팀이 작을수록 제어가 덜 필요합니다. + +전체적인 경험 + +팀원 중 시니어급은 몇명이나 있나요? 주니어 개발자가 많은 팀은 제어와 멘토링이 더 필요하고, 시니어 개발자가 더 많은 팀은 아무래도 제어가 덜 필요합니다. + +프로젝트 복잡도 + +복잡도가 높은 프로젝트를 수행하려면 아키텍트가 팀에 더 많이 관여하여 갖가지 이슈를 처리해야 할테니 팀에 더많은 제어를 가할 수 밖에 없습니다. 비교적 단순한 프로젝트는 그 자체로 간단하니 별로 제어할 필요가 없겠죠. + +프로젝트 기간 + +프로젝트 기간이 길수록 더 많은 제어가 필요하고 프로젝트 기간이 짧을수록 제어는 덜 필요합니다. + +보통 프로젝트를 처음 시작할때 이팩터들을 토대로 제어 수준을 결정합니다. 그러나 시스템이 진화할 수록 제어 수준도 달라지기 마련이므로 프로젝트 내내 이팩터들을 지속적으로 분석하여 개발팀을 어느 정도까지 제어할지 결정 하는게 좋습니다. + +## 22.4 팀의 이상징후 + +가장 효율적인 개발팀의 규모는 다음 세 가지 팩터에 의해 결정됩니다 + +- 프로세스 손실 + - 기본적으로 프로젝트에 인력을 더 많이 투입할수록 프로젝트를 수행하는 시간이 더 길어진다는 것입니다. + - 프로세스 손실을 방지하려면 팀내부적으로 병렬작업이 가능한 부분을 찾고 팀원들이 각자 별도의 서비스나 애플리케이션 영역에서 작업할 수 있게끔 환경을 제공해야 합니다. +- 다원적 무지 + - 모든 사람들이 자신이 뭔가 너무 뻔한것을 놓치고 있는게 아닐까 두려운 나머지 어떤 표준에 순순히 동의하는 현상입니다. +- 책임 확산 + - 팀 규모가 커질수록 의사소통이 잘 안되는건 모두가 공감하는 팩트입니다. + +## 22.5 체크리스트활용 + +체크리스트는 정말로 효과가 있습니다. + +## 22.6 지침제시 + +유능한 소프트웨어 아키텍트는 다음 질문에 개발자가 먼저 답하도록 유도함으로써 개발팀에 지침을 제시합니다. + +- 제안하신 라이브러리와 기존시스템의 내부 기능사이에 중첩되는 부분이 있나요. +- 제안하신 라이브러리를 반드시 사용해야 하는 당위성은 무엇인가요? + +## 22.7 마치며 + +개발팀을 잘 굴러가게 만들기란 참으로 어렵습니다. + +이런 활동을 하는 아키텍트의 역할에 의문을 제기하고 팀을 효과적으로 만드는 책임을 PM이나 개발 관리자에게 일임하는 사람도 있습니다. 우리는 강력히 반대합니다. From be884424a55c0dd12eb527c37fc4909e17a8c3a1 Mon Sep 17 00:00:00 2001 From: mononomo Date: Mon, 9 Dec 2024 20:25:23 +0900 Subject: [PATCH 4/8] =?UTF-8?q?Delete=20ch022=5F=EA=B0=9C=EB=B0=9C?= =?UTF-8?q?=ED=8C=80=EC=9D=84=5F=ED=9A=A8=EC=9C=A8=EC=A0=81=EC=9C=BC?= =?UTF-8?q?=EB=A1=9C=20directory?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../mono.md" | 86 ------------------- 1 file changed, 86 deletions(-) delete mode 100644 "ch022_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" diff --git "a/ch022_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" "b/ch022_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" deleted file mode 100644 index 8573d0d..0000000 --- "a/ch022_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" +++ /dev/null @@ -1,86 +0,0 @@ -# 22. 개발팀을 효율적으로 - -## 22.1 팀경계 - -우리는 경험상 소프트웨어 아키텍트가 개발팀의 성패를 좌우할 만큼 지대한 영향력을 갖고있다고 생각합니다. 스스로 정상 궤도에서 벗어났거나 소프트웨어 아키텍트로 부터 멀어졌다고 느끼는 개발팀은 대부분 시스템의 다양한 제약조건을 제대로 알지 못하고 경험도 없기 때문에 아키텍처를 올바르게 구현하지 못 합니다. - -유능한 소프트웨어 아키텍트는 팀이 올바른 도구와 라이브러리로 무장하여 아키텍처를 잘 구현할 수 있도록 적절한 지침과 제약조건을 제공합니다. - -## 22.2 아키텍트성향 - -### 22.2.1 내 맘대로 아키텍트 - -내 맘대로 아키텍트는 경계를 아주 빡빡하게 설정합니다. 그리고 개발팀이 알아서 쓸법한 오픈소스나 서드 파티 라이브러리를 마음대로 내려 받아 사용하지 못 하게 하면서 개발팀이 언어API를 이용해 모든 것을 처음부터 개발하라고 우깁니다. - -특히, 개발자에서 아키텍트로 전향한 사람들이 이런 아키텍트가 되기 쉽습니다. - -아키텍트는 프로젝트의 복잡성과 팀기술 수준에 따라 내맘대로 아키텍트라는 악역을 맡아야 할 때도 있습니다. - -### 22.2.2 유체 이탈 아키텍트 - -유체 이탈 아키텍트는 꽤 오랫동안(어쩌면 단 한번도 제대로)코딩을 한적이 없는, 아키텍처를 수립할 때 세부 구현사항은 거의 나몰라라 하는 아키텍트입니다. - -유체이탈 아키텍트는 앞절에서 설명했듯이 개발팀 주위에 아주 느슨하게 경계를 설정합니다. - -- 비즈니스영역, 비즈니스문제, 기술을 온전히 이해하지 못 한다. -- 소프트웨어 개발 실무경력이 부족하다. -- 아키텍처 솔루션 구현에 함축된 의미를 전혀 신경쓰지 않는다. - -어쨌든 이런 아키텍트가 되지 않으려면 프로젝트에서 쓰이는 기술에 더 많이 관여하고 비즈니스 문제/영역을 잘 이해하려고 노력해야 합니다. - -### 22.2.3 유능한 아키텍트 - -개발팀을 잘 이끄는 유능한 리더가 되는 것은 일종의 예술입니다. - -## 22.3 얼마나 제어 해야하나? - -팀원 간 친밀도 - -팀원들이 서로 얼마나 잘 알고 있나요? 전에도 프로젝트를 함께한 사람들인가요? 일반적으로 팀원들이 서로 잘아는 사이라면 이미 스스로 조직화하기 시작되므로 제어가 덜 필요하고, 그 반대 일수록 팀원 간 협업을 촉진 하고 팀내 파벌을 없애기 위해 더 많은 제어가 필요합니다. - -팀 규모 - -팀 규모가 어느 정도인가요. 팀이 커질수록 더 많은 제어가 필요하고, 팀이 작을수록 제어가 덜 필요합니다. - -전체적인 경험 - -팀원 중 시니어급은 몇명이나 있나요? 주니어 개발자가 많은 팀은 제어와 멘토링이 더 필요하고, 시니어 개발자가 더 많은 팀은 아무래도 제어가 덜 필요합니다. - -프로젝트 복잡도 - -복잡도가 높은 프로젝트를 수행하려면 아키텍트가 팀에 더 많이 관여하여 갖가지 이슈를 처리해야 할테니 팀에 더많은 제어를 가할 수 밖에 없습니다. 비교적 단순한 프로젝트는 그 자체로 간단하니 별로 제어할 필요가 없겠죠. - -프로젝트 기간 - -프로젝트 기간이 길수록 더 많은 제어가 필요하고 프로젝트 기간이 짧을수록 제어는 덜 필요합니다. - -보통 프로젝트를 처음 시작할때 이팩터들을 토대로 제어 수준을 결정합니다. 그러나 시스템이 진화할 수록 제어 수준도 달라지기 마련이므로 프로젝트 내내 이팩터들을 지속적으로 분석하여 개발팀을 어느 정도까지 제어할지 결정 하는게 좋습니다. - -## 22.4 팀의 이상징후 - -가장 효율적인 개발팀의 규모는 다음 세 가지 팩터에 의해 결정됩니다 - -- 프로세스 손실 - - 기본적으로 프로젝트에 인력을 더 많이 투입할수록 프로젝트를 수행하는 시간이 더 길어진다는 것입니다. - - 프로세스 손실을 방지하려면 팀내부적으로 병렬작업이 가능한 부분을 찾고 팀원들이 각자 별도의 서비스나 애플리케이션 영역에서 작업할 수 있게끔 환경을 제공해야 합니다. -- 다원적 무지 - - 모든 사람들이 자신이 뭔가 너무 뻔한것을 놓치고 있는게 아닐까 두려운 나머지 어떤 표준에 순순히 동의하는 현상입니다. -- 책임 확산 - - 팀 규모가 커질수록 의사소통이 잘 안되는건 모두가 공감하는 팩트입니다. - -## 22.5 체크리스트활용 - -체크리스트는 정말로 효과가 있습니다. - -## 22.6 지침제시 - -유능한 소프트웨어 아키텍트는 다음 질문에 개발자가 먼저 답하도록 유도함으로써 개발팀에 지침을 제시합니다. - -- 제안하신 라이브러리와 기존시스템의 내부 기능사이에 중첩되는 부분이 있나요. -- 제안하신 라이브러리를 반드시 사용해야 하는 당위성은 무엇인가요? - -## 22.7 마치며 - -개발팀을 잘 굴러가게 만들기란 참으로 어렵습니다. - -이런 활동을 하는 아키텍트의 역할에 의문을 제기하고 팀을 효과적으로 만드는 책임을 PM이나 개발 관리자에게 일임하는 사람도 있습니다. 우리는 강력히 반대합니다. From d42ae439db6a8e7ee324d1a2083da709fac7024f Mon Sep 17 00:00:00 2001 From: mononomo Date: Mon, 9 Dec 2024 20:25:48 +0900 Subject: [PATCH 5/8] Create mono.md --- .../mono.md" | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 "ch22_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" diff --git "a/ch22_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" "b/ch22_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" new file mode 100644 index 0000000..8573d0d --- /dev/null +++ "b/ch22_\352\260\234\353\260\234\355\214\200\354\235\204_\355\232\250\354\234\250\354\240\201\354\234\274\353\241\234/mono.md" @@ -0,0 +1,86 @@ +# 22. 개발팀을 효율적으로 + +## 22.1 팀경계 + +우리는 경험상 소프트웨어 아키텍트가 개발팀의 성패를 좌우할 만큼 지대한 영향력을 갖고있다고 생각합니다. 스스로 정상 궤도에서 벗어났거나 소프트웨어 아키텍트로 부터 멀어졌다고 느끼는 개발팀은 대부분 시스템의 다양한 제약조건을 제대로 알지 못하고 경험도 없기 때문에 아키텍처를 올바르게 구현하지 못 합니다. + +유능한 소프트웨어 아키텍트는 팀이 올바른 도구와 라이브러리로 무장하여 아키텍처를 잘 구현할 수 있도록 적절한 지침과 제약조건을 제공합니다. + +## 22.2 아키텍트성향 + +### 22.2.1 내 맘대로 아키텍트 + +내 맘대로 아키텍트는 경계를 아주 빡빡하게 설정합니다. 그리고 개발팀이 알아서 쓸법한 오픈소스나 서드 파티 라이브러리를 마음대로 내려 받아 사용하지 못 하게 하면서 개발팀이 언어API를 이용해 모든 것을 처음부터 개발하라고 우깁니다. + +특히, 개발자에서 아키텍트로 전향한 사람들이 이런 아키텍트가 되기 쉽습니다. + +아키텍트는 프로젝트의 복잡성과 팀기술 수준에 따라 내맘대로 아키텍트라는 악역을 맡아야 할 때도 있습니다. + +### 22.2.2 유체 이탈 아키텍트 + +유체 이탈 아키텍트는 꽤 오랫동안(어쩌면 단 한번도 제대로)코딩을 한적이 없는, 아키텍처를 수립할 때 세부 구현사항은 거의 나몰라라 하는 아키텍트입니다. + +유체이탈 아키텍트는 앞절에서 설명했듯이 개발팀 주위에 아주 느슨하게 경계를 설정합니다. + +- 비즈니스영역, 비즈니스문제, 기술을 온전히 이해하지 못 한다. +- 소프트웨어 개발 실무경력이 부족하다. +- 아키텍처 솔루션 구현에 함축된 의미를 전혀 신경쓰지 않는다. + +어쨌든 이런 아키텍트가 되지 않으려면 프로젝트에서 쓰이는 기술에 더 많이 관여하고 비즈니스 문제/영역을 잘 이해하려고 노력해야 합니다. + +### 22.2.3 유능한 아키텍트 + +개발팀을 잘 이끄는 유능한 리더가 되는 것은 일종의 예술입니다. + +## 22.3 얼마나 제어 해야하나? + +팀원 간 친밀도 + +팀원들이 서로 얼마나 잘 알고 있나요? 전에도 프로젝트를 함께한 사람들인가요? 일반적으로 팀원들이 서로 잘아는 사이라면 이미 스스로 조직화하기 시작되므로 제어가 덜 필요하고, 그 반대 일수록 팀원 간 협업을 촉진 하고 팀내 파벌을 없애기 위해 더 많은 제어가 필요합니다. + +팀 규모 + +팀 규모가 어느 정도인가요. 팀이 커질수록 더 많은 제어가 필요하고, 팀이 작을수록 제어가 덜 필요합니다. + +전체적인 경험 + +팀원 중 시니어급은 몇명이나 있나요? 주니어 개발자가 많은 팀은 제어와 멘토링이 더 필요하고, 시니어 개발자가 더 많은 팀은 아무래도 제어가 덜 필요합니다. + +프로젝트 복잡도 + +복잡도가 높은 프로젝트를 수행하려면 아키텍트가 팀에 더 많이 관여하여 갖가지 이슈를 처리해야 할테니 팀에 더많은 제어를 가할 수 밖에 없습니다. 비교적 단순한 프로젝트는 그 자체로 간단하니 별로 제어할 필요가 없겠죠. + +프로젝트 기간 + +프로젝트 기간이 길수록 더 많은 제어가 필요하고 프로젝트 기간이 짧을수록 제어는 덜 필요합니다. + +보통 프로젝트를 처음 시작할때 이팩터들을 토대로 제어 수준을 결정합니다. 그러나 시스템이 진화할 수록 제어 수준도 달라지기 마련이므로 프로젝트 내내 이팩터들을 지속적으로 분석하여 개발팀을 어느 정도까지 제어할지 결정 하는게 좋습니다. + +## 22.4 팀의 이상징후 + +가장 효율적인 개발팀의 규모는 다음 세 가지 팩터에 의해 결정됩니다 + +- 프로세스 손실 + - 기본적으로 프로젝트에 인력을 더 많이 투입할수록 프로젝트를 수행하는 시간이 더 길어진다는 것입니다. + - 프로세스 손실을 방지하려면 팀내부적으로 병렬작업이 가능한 부분을 찾고 팀원들이 각자 별도의 서비스나 애플리케이션 영역에서 작업할 수 있게끔 환경을 제공해야 합니다. +- 다원적 무지 + - 모든 사람들이 자신이 뭔가 너무 뻔한것을 놓치고 있는게 아닐까 두려운 나머지 어떤 표준에 순순히 동의하는 현상입니다. +- 책임 확산 + - 팀 규모가 커질수록 의사소통이 잘 안되는건 모두가 공감하는 팩트입니다. + +## 22.5 체크리스트활용 + +체크리스트는 정말로 효과가 있습니다. + +## 22.6 지침제시 + +유능한 소프트웨어 아키텍트는 다음 질문에 개발자가 먼저 답하도록 유도함으로써 개발팀에 지침을 제시합니다. + +- 제안하신 라이브러리와 기존시스템의 내부 기능사이에 중첩되는 부분이 있나요. +- 제안하신 라이브러리를 반드시 사용해야 하는 당위성은 무엇인가요? + +## 22.7 마치며 + +개발팀을 잘 굴러가게 만들기란 참으로 어렵습니다. + +이런 활동을 하는 아키텍트의 역할에 의문을 제기하고 팀을 효과적으로 만드는 책임을 PM이나 개발 관리자에게 일임하는 사람도 있습니다. 우리는 강력히 반대합니다. From 1a31e1155499676d56815061e9c6369214693a8a Mon Sep 17 00:00:00 2001 From: mononomo Date: Mon, 9 Dec 2024 20:26:57 +0900 Subject: [PATCH 6/8] Create mono.md --- .../mono.md" | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 "ch23_\355\230\221\354\203\201\352\263\274_\353\246\254\353\215\224\354\213\255_\354\212\244\355\202\254/mono.md" diff --git "a/ch23_\355\230\221\354\203\201\352\263\274_\353\246\254\353\215\224\354\213\255_\354\212\244\355\202\254/mono.md" "b/ch23_\355\230\221\354\203\201\352\263\274_\353\246\254\353\215\224\354\213\255_\354\212\244\355\202\254/mono.md" new file mode 100644 index 0000000..535101f --- /dev/null +++ "b/ch23_\355\230\221\354\203\201\352\263\274_\353\246\254\353\215\224\354\213\255_\354\212\244\355\202\254/mono.md" @@ -0,0 +1,65 @@ +# 23. 협상과 리더십 스킬 + +## 23.1 협상과 조정 + +이 능력이 중요한 이유는 소프트웨어 아키텍트가 내리는 거의 모든 결정이 곳곳에서 거친 도전과 반대에 부딪히기 때문입니다. + +협상은 소프트웨어 아키텍트가 지녀야할 가장 중요한 스킬 중 하나입니다. 유능한 소프트웨어 아키텍트는 사내 정치를 이해하고 강력한 협상 및 조정 능력을 발휘하며, 모든 이해관계자들이 동의하는 해법을 찾는 과정에서 맞닥뜨리는 숱한 의견 차이를 극복할 것입니다. + +### 23.1.1 비즈니스 이해 관계자들과의 협상 + +이런 종류의 협상에서 소프트웨어 아키텍트는 자신의 분석결과만을 들이대며 너무 분위기를 강압적으로 몰아가지 않도록 주의 해야합니다. 또 협상하는 중에도 자신이 틀렸음을 입증할 만한 내용을 놓치고 있지는 않나 잘 살펴봐야 합니다. + +- 상황을 더 잘 이해하기 위해 문법과 유행어를 사용하세요. +- 협상에 돌입하기 전, 가능한한 많은 정보를 수집하세요. +- 다른 모든 것이 실패하면 비용과 시간으로 설명하세요. +- 분할 및 정복 규칙을 활용해서 요구사항 또는 필우조건을 검증하세요. + +### 23.1.2 다른 아키텍트들과의 협상 + +아키텍트 간의 열띤 논쟁은 이번이 처음은 아니지만 그렇다고 마지막이 될 것 같아 보이지도 않습니다. 하지만 결국 상대방의 적대감을 조장하여 비협조적인 관계가 형성되고 이는 개발팀에게도 바람직하지 않은 영향을 미칠것입니다. + +- 증명은 언제나 논쟁을 이긴다는 사실을 명심하세요. +- 지나치게 논쟁을 벌이려고 하거나 협상과정에서 개인적인 감정을 드러내지 마세요. 간결 명료한 추론에 차분한 리더십을 더 하면 반드시 협상에서 승리할 것입니다. + +아키텍트 간 논쟁은 늘 있기 마련이지만 차분한 리더십으로 상황에 접근하면 격론이 벌어졌을 때 상대방을 한발 짝 물러서게 할 수 있습니다. + +### 23.1.3 개발자들과의 협상 + +유능한 소프트웨어 아키텍트는 아키텍트라는 직책을 내세워 개발자에게 할 일을 지시하기 보다 외려 그들과 협력하여 존경심을 이끌어냅니다. 그래야 개발팀에 어떤 요청을 하더라도 논쟁을 하면서 서로 얼굴을 붉힐 일이 없습니다. + +따라서 아키텍트로서 존경을 받지 못 하고 결국 팀 자체도 와해됩니다. + +- 개발자가 아키텍처 결정을 수용해서 어떤 작업을 하도록 설득할 때에는 ‘고압적으로 지시’ 하지 말고 왜 그 일을 해야하는지 정당성을 제공하세요. +- 개발자가 아키텍트의 결정에 동의하지 않을 경우 그들 스스로 해결책을 찾도록 유도하세요. + +## 23.2 소프트웨어 아키텍트는 리더다. + +### 23.2.1 아키텍처4C + + + +- 커뮤니케이션 +- 협동 +- 명료함 +- 간결함 + +## 23.3 개발팀과의 융합 + + IT세계에서 회의는 필요악입니다. 회의는 항상 그리고 자주 일어나기 마련입니다. 회의를 제어 해야합니다. + +단순히 정보를 전달할 목적으로 초대하는 경우도 많기 때문에 회의노트는 꼭 필요합니다. 회의하는 이유를 알면 꼭 참석해야 할 회의와 그냥 넘어가도될 회의를 구별할 수 있습니다. + +또 전체 회의는 굳이 참석할 필요가 없는 경우가 대부분입니다. 가능한 한 회의 때문에 시간을 낭비하지 말고 개발팀과 함께 작업하는 시간을 더 많이가지세요. + +- 회의 전에 미리 의제를 요청해서 아키텍트가 그 회의에 정말 참석해야 하는지 여부를 판단하세요. + +## 23.4 마치며 + + From 897cb198147594b443dedb664fe62c1ca7cf5626 Mon Sep 17 00:00:00 2001 From: mononomo Date: Mon, 9 Dec 2024 20:27:54 +0900 Subject: [PATCH 7/8] Create ch24_mono.md --- .../ch24_mono.md" | 130 ++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 "ch24_\354\273\244\353\246\254\354\226\264\355\214\250\354\212\244_\352\260\234\353\260\234/ch24_mono.md" diff --git "a/ch24_\354\273\244\353\246\254\354\226\264\355\214\250\354\212\244_\352\260\234\353\260\234/ch24_mono.md" "b/ch24_\354\273\244\353\246\254\354\226\264\355\214\250\354\212\244_\352\260\234\353\260\234/ch24_mono.md" new file mode 100644 index 0000000..07ffb0e --- /dev/null +++ "b/ch24_\354\273\244\353\246\254\354\226\264\355\214\250\354\212\244_\352\260\234\353\260\234/ch24_mono.md" @@ -0,0 +1,130 @@ +# 24. 커리어패스 개발 + +아키텍트가 되려면 적잖은 시간과 노력이 필요하지만 지금까지 우리가 이 책을 통틀어 설명한 여러 가지 이유때문에 아키텍트가 되고 난 후 커리어패스를 관리하는 것도 쉽지않습니다. + +아키텍트는 커리어내 끊임 없이 배워야합니다. 기술 세계는 현기증이 날 정도로 변화가 빠릅니다. + +날의 이전 동료 한사람은 국제적으로 저명한 클리퍼 전문가였습니다. 그는 거대한 (이젠쓸모없는) 클리퍼 지식체계를 다른 것으로 대체 할 수 없다는 사실을 안타깝게 여기며 이런 생각을 했다고 합니다. + + + +아키텍트는 기술이든 비즈니스든 연관된 자료에 늘 관심을 갖고 개인저장고에 차곡차곡 잘 쌓아 놓아야 합니다. + +여러분이 요즘 연구중인 자료에 대해 동료와 전문가들과 함께 이야기를 나누면 어떤 관심분야에서 활발하게 업데이트 되는 최신 뉴스 피드, 웹사이트, 그룹을 발견하는데 도움이 될 것입니다. 아키텍트는 이런 자료를 활용하여 기술폭을 유지하는 활동에 나름대로 시간을 할애 해야합니다. + +## 24.1 20 분 규칙 + +아키텍트에게는 기술의 깊이 보다 폭이 더 중요하고, 이 폭을 계속 유지하려면 시간과 노력이 필요합니다. + +모두 워라벨을 유지하며 가족들과 더 많은 시간을 보내고, 자녀에게 더 신경을 쓰고, 개인적인 관심과 취미에 시간을 쪼개어 쓰고, 그러면서 동시에 커리어개발에 힘쓰고, 최신 트렌드를 따라가고, 각종 용어들을 이해하느라 고군분투합니다. + +이러한 균형을 유지하는 기술로 20분 규칙이 있습니다. 아키텍트로서 커리어를 유지하기 위해 새로운 것을 배우거나 특정 주제를 깊이 파고드는 시간을 매일 최소 20분은 할애하라는 규칙 입니다. + +여러분이 모른다는 사실을 알고 있는 것들로 격상시키세요. 아니 면 어떤 주제에 관한 지식을 좀 더 많이 얻기 위해20분 동안 집중적으로 파고들 수도 있습니다. 요는, 아키텍트로서 지속적으로 커리어를 개발하고 기술 폭을 넓힐수 있는 시간을 만들어 쓰라는겁니다. + +20분 규칙은 하루가 시작될 때 가장 먼저 실천하는게 좋습니다. + +일 공부한거 → 가비아의 서브도메인 등록 방법은 거지같다. 서브 도메인 등록 원리 + +월 공부한거 → + +화 공부한거 → + +## 24.2 개인 레이더 개발 + +기본 플랫폼은 클리퍼 였는데, 하지만 이 소프트웨어는 일 순간에 사라지고 말았습니다. 회사 경영진은 윈도우가 떠오르는 태양임을 알고 있었지만 업계 시장은 계속DOS 위주였고… 그러다 갑자기 상황이 반전된거죠. 우리는 위 기에 처한 기술의 행진은 무시하라!' 는 값진 교훈을 얻었습니다. + +[DOS 사진 넣기] + +이 사건은 기술거품에 대해서도 시사하는 바가 큽니다. 기술에 지나치게 투자하면 개발자는 *에코챔버 역할을 하는 ****밈버블에 빠지게됩니다. 그러나 무엇보다 이렇게 거품만 잔뜩 끼어있는 삶의 가장 큰 리스크는 삶이 무너지기 시작 할 즈음에서야 모습을 드러내며 개발자는 졸지에 소잃고 외양간을 고치는 신세가 됩니다. + +개발자에게 절실 했던 것은 바로 기술레이더 였습니다. 기술 레이더는 기존 기술과 초기 기술의 리스크와 보상을 평가하는 살아있는 문서를 말합니다. + +* 에코챔버 : 비슷한 성향의 사람과 소통한 결과 다른 사람의 정보와 견해는 불신하고 본인 이야기만 증폭돼 진실인 것처럼 느껴지는 정보 환경을 말한다. + +** 밈버블 : + +### 24.2.1 쏘우트 웍스 기술레이더 + +"당신(연사님)은 기술 동향을 어떻게 따라가십니까?", "다음에 어떤 것을 추구해야 좋을지 어떻게 아시나요?” 닐은 어느 콘퍼런스에 가든지 늘 받게 되는 이런 질문들의 답이 바로 기술레이더임을 깨달았습니다. 사실 이 책을 읽는 여러분도 어떤 형태로든 내부 레이더를 갖고있습니다. + +분면 : 쏘우트웍스 레이더는 대부분의 소프트웨어 개발환경을 다루는 사분면으로 구성됩니다. + +도구 : 소프트웨어를 개발하는 도구. 구름IDE 같은 개발자 도구부터 엔터프라이즈급 통합 도구까지의 모든 도구 + +언어와 프레임워크 : 컴퓨터언어, 라이브러리, 프레임워크 (대부분 오픈소스) + +기술 : 소프트웨어 개발을 전체적으로 지원하는 모든 프랙티스 (예: 소프트웨어 개발 프로세스, 엔지니어 링 프랙티스, 권고) + +플랫폼 : 데이터베이스, 클라우드벤더, 운영체제등의 기술 플랫폼 + +원 : 레이더에는 4개의 원이 있는데, 모두 밖에서 안쪽으로 향합니다. + +보류 : 보류 원의 원래 의도는 '당분간 ( 일단 ) 보류한다'로, 너무 새로운 기술이라 아직 타당하다고 볼 수 없는 기술, 즉 사람들의 관심은 많지만 아직 입증되지 않은 기술을 나타냅니다. 보류링은 점점 진화해서 이제는 ‘이 기술을 갖고 새로운 뭔가를 시작하지말라'는 뜻이 됐습니다. + +평가 : 평 가원은 조직에 어떤 영향을 미칠지 파악하기 위해 탐구해볼 가치가 있는 기술을 가리킵니다. 아키텍트는 개발 스파이크, 연구 프로젝트, 콘퍼런스 세션 등을 통해 기술이 조직에 미치는 영향도를 파악해야 합니다. 실제로 과거 많은 대기업이 모바일전략을 수립할 때 이런 단계를 거쳤습니다. + +시도 : 시도 원은 추구할 가치가 있는 기술을 말합니다. 어떻게 기능을 구현하는지 이해하는 것이 중요하므로 아키텍트, 개발자는 리스크가 적은 파일롯 프로젝트를 수행하면서 실질적인 기술을 습득하는데에 힘써야 합니다. + +채택 : 쏘 우트웍스는 채택원에 속한 기술은 업계에서 반드시 채택되어야 한다고 주장합니다. + +[그림 2 4 - 2 쏘우트웍스 기술 레이더 샘플] + +기술레이더를 개인적으로 사용할 때에는 각분면의 의미를 다음과 같이 바꾸는 것이 좋습니다. + +보류 : 아키텍트는 사용하지 말아야 할 기술, 기법뿐만 아니라 자신이 고치려는 습관도 갖고있습니다. 닷넷 출신 아키텍트는 아무래도 팀포럼에서 최신뉴스나 가십거리를 읽는 일에 길들여져 있는데, 재미로보는건 좋지만 사실 별로 가치 없는 정보들이 많습니다. 이런 항목을 보류원에 두면 아키텍트가 문제가 있는 행동을 할때마다 기억을 되새길 수 있겠죠. + +평가 : 어떤 기술이 좋다는 얘기는 들었으나 직접평가 할 시간은 없었던 유망 기술은 평가원에 두는게 좋습니다. + +시도 : 시도 원은 아키텍트가 규모가 큰코드베이스에서 실험을 하는 것처럼 활발한 연구 개발 활동을 나타냅니다. 이 원에는 아키텍트가 효과적인 트레이드오프 분석을 할 수 있도록 더 깊이 이해하는데 시간을 들일만한 기술들이 있습니다. + +채택 : 채택 원은 아키텍트가 정말로 기대하는 새로운 것들과 특정문제를 해결하기 위한 베스트 프랙티스를 가리킵니다. + +아키텍트는 자신의 기술 포트폴리오를 일종의 자산 포트폴리오처럼 다루어야 합니다. + +아키텍트는 많이 쓰이는 기술과 스킬을 골라 그 수요의 동향을 살펴야 합니다. 오픈소스나 모바일 개발처럼 기술선점을 시도하려는 아키텍트도 있을 것입니다. 아키텍트는 기술 포트폴리오를 확장하는데 시간을 투자 해야합니다. + +### 24.2.2 오픈소스 시각화 비트 + +쏘우트웍스는 뜨거운 성원에 힘입어 기술자가 자신의 레이더를 시각화 할 수 있는 유용한 도구를 출시했습니다. + +[오픈소스 시각화 비트 넣어보기] + +## 24.3 소셜 미디어 활용 + +아키텍트는 자기 레이더의 평가원에 넣을 만한 신기술을 어디에서 찾을까요? + +한 사람이 다른 사람과 접촉하는 네트워크는[그림24-3] 처럼 세 가지 범주로 나뉩니다. + +[그림24-3] + +강한 인맥 : 가족,동료,그리고 개인적으로 계속 연락하고 지내는 사람들입니다. 이 범주에 속할 정도로 가까운 사람들인지는 적어도 지난주에 하루 이상 함께 점심 식사를 했는지 돌아보면 됩니다. + +약한 인맥 : 주변에 있는 지인, 먼 친척, 그리고 일년에 몇번 볼까 말까 한사람들 입니다. + +잠재적 인맥 : 여러분이 아직 한번도 만난적이 없는 사람 + +맥아피가 이런 인맥을 관찰한 가장 흥미로운 사실은, 어떤 사람의 다음 일자리는 강한 인맥 보다 외려 약한 인맥에서 창출될 가능성이 더 높다는 점입니다. 강한 인맥에 속한 사람들은 언제나 가까이 지내는 터라 서로에 대해 많은걸 알고 있지만, 약한 인맥의 사람들은 새로운 잡포지션 제안 등 그사람의 일반적인 경험에서 비롯된 조언을 해줄 수 있습니다. + +## 24.4 종언 + +아키텍처는 물론 삶의 모든것에서 더 나은사람으로 거듭날 ~ 연습입니다 ~ + +아키텍처에는 정답도 오답도 없다. 오직 트레이드 오프만 있을뿐. + +자 , 이제 여러분께 마지막 조언을 하면서 이 책을 마칩니다. 항상 배우고, 항상 연습하고, 아키텍처를 설계 해보시길! + +마지막으로 이 커리어 패스 개발 내용과 별개로 “함께자라기” 라는 책을 여러분이 꼭 읽어 보셨으면 좋겠습니다. + + + + From 228c997f09db5436749f6f17df230d280e14d171 Mon Sep 17 00:00:00 2001 From: mononomo Date: Tue, 10 Dec 2024 19:42:23 +0900 Subject: [PATCH 8/8] Create ch19_mono.md --- .../ch19_mono.md" | 148 ++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 "ch19_\354\225\204\355\202\244\355\205\215\354\262\230_\352\262\260\354\240\225/ch19_mono.md" diff --git "a/ch19_\354\225\204\355\202\244\355\205\215\354\262\230_\352\262\260\354\240\225/ch19_mono.md" "b/ch19_\354\225\204\355\202\244\355\205\215\354\262\230_\352\262\260\354\240\225/ch19_mono.md" new file mode 100644 index 0000000..010f55a --- /dev/null +++ "b/ch19_\354\225\204\355\202\244\355\205\215\354\262\230_\352\262\260\354\240\225/ch19_mono.md" @@ -0,0 +1,148 @@ +# 19.아키텍처 결정 + +아키텍트에게 기대하는 핵심 가치 중 하나는 아키텍처 결정을 내리는 것입니다. 아키텍처 결정을 하려면 충분한 정보를 수집하고 결정을 정당화, 문서화한 다음 이해관계자들과 효과적으로 소통해야 합니다. + +## **19.1** 아키텍처 결정 안티패턴 + +아키텍처를 결정하는 것도 기술입니다. 따라서 아키텍트가 결정을 내릴 때 아키텍처 안티패턴에 빠지는 일도 드물지 않습니다. + +### **19.1.1** ‘네 패를 먼저 보여주지마’ 안티패턴 + +아키텍트가 잘못된 선택을 하는 것을 두려워한 나머지 아키텍처 결정을 회피하거나 미루는 현상을 말합니다. + +이 안티패턴은 두 가지 방법으로 극복할 수 있습니다. 첫째, 어떤 중요한 아키텍처 결정을 내리기 전, 미지막으로 책임질 수 있는 순간까지 기다리는 것입니다. 아키텍트가 자신의 결정을 정당화하고 검증하기 위해 충분한 정보를 수집할 때까지 기다리지만, 개발팀을 마냥 붙잡아 두거나 분석 마비 ****안티패턴에 빠질 정도로 오래 기다리지는 않음을 의미합니다. + +둘째, 개발팀과 지속적으로 협력하면서 아키텍트가 결정한 내용을 원래 의도한 대로 추진합니다. 세부적인 기술에 관한 모든 이슈를 아키텍트 혼자 전부 다 알 수는 없기 때문에 개발팀의 협력은 절대적으로 필요합니다. 그래야 나중에 문제가 생겨도 아키텍트가 아키텍처 결정을 변경하면서 재빠르게 대응할 수 있습니다. + +### 19.1.2 ‘무한반복 회의’ 안티패턴 + +‘네 패를 먼저 보여주지마’ 안티패턴을극복하면 이어서 ‘무한반복 회의’ 안티패턴으로 이어집니다. 사람들이 어떤 결정을 왜 했는지 모르고 주구장창 회의만 계속 하는 것입니다. + +‘무한반복 회의’ 안티패턴이 발생하는 이유는 아키텍트가 자신이 내린 결정을 정당화하는 데 실패했기 때문입니다. 아키텍처 결정을 정당화하려면 그 결정을 내리게 된 기술적, 비즈니스적 근거를 제시하는 것이 중요합니다. + +어떤 아키텍처 결정이건 그것을 정당화할 때에는 비즈니스 가치를 제시하는 것이 중요합니다. 그렇게 해야 그 아키텍처 결정을 정말 다른 무엇보다 우선해야 하는지 한 번 더 돌아볼 수 있습니다. 그럴 만한 비즈니스 가치가 없다면 좋은 아키텍처 결정이 아니니 한발짝 물러나 재고해보는 것이 좋습니다. + +가장 일반적인 비즈니스 정당화로는 비용, 출시 시기, 유저 만족도, 전략적 포지셔닝 등이 있습니다. 이 네 가지 관점에서 비즈니스적으로 정당화할 때에는 무엇이 비즈니스 이해관계자에게 중요한지 숙고해봐야 합니다. + +### 19.1.3 ‘이메일 기반 아키텍처’ 안티패턴 + +아키텍트가 아키텍처 결정을 하고 그 결정을 온전히 정당화한 다음은 ‘이메일 기반 아키텍처’ 안티패턴이 등장할 차례입니다. 사람들이 아키텍처 결정을 놓치거나 잊어버리고 심지어는 그렇게 결정됐다는 사실조차 알지 못해 아키텍처 결정을 구현하지 못하는 상태입니다. 아키텍처 결정을 효과적으로 전달하는 문제와 관련된 안티패턴입니다. + +이 안티패턴을 방지하고 아키텍처 결정을 효과적으로 전달하려면 어떻게 해야 할까요? 첫째, 이메일 본문에 아키텍처 결정을 포함시키지 않습니다. 이메일 본문에 아키텍처 결정을 기재하면 그 결정에 관한 여러 경로의 기록 체계가 파생되고 (정당화 사유를 비롯한) 중요한 세부 사항들이 이메일에서 누락되기 쉬운 까닭에 고질적인 ‘무한반복 회의’ 패턴이 재발합니다. + +둘째, 아키텍처 결정에 정말 관심있는 사람들에게만 통지합니다. 일례로, 이메일 본문에 다음과 같이 쓰면 효과적이겠죠. + +또 아키텍처 결정에 관한 세부 내용을 확인 가능한 링크를 제공하면 모든 정보를 일원화하여 관리할 수 있는 체계가 완성됩니다. + +## **19.2** 아키텍처적으로 중요한 + +아키텍처 결정에 기술적인 내용이 포함되면 그것은 아키텍처 결정이 아니라, 기술 결정이라고 단정짓는 아키텍트들이 많지만 반드시 그런 것은 아닙니다. 아키텍트가 어떤 기술을 사용하기 로 결정을 했고 그 기술을 어떤 아키텍처 특성을 직접 지원하기 위해 선택한 것이라면 이는 아키텍처 결정이 맞습니다. + +그는 아키텍처적으로 중요한 결정이란 구조, 비기능 특성, 의존성, 인터페이스, 구현기술에 영향을 미치는 결정이라고 보았습니다. + +구조는 사용 중인 아키텍처의 패턴이나 스타일에 영향을 미치는 결정들입니다. + +비기능 특성은 개발 또는 유지보수 중인 애플리케이션이나 시스템에 중요한 아키텍처 특성들입니다. 만약 어떤 기술을 선택하느냐에 따라 성능이 달라지고 성능이 애플리케이션의 중요한 팩터일 경우, 이러한 기술 선택이 곧 아키텍처 결정이 됩니다. + +의존성은 전체 확장성,모듈성,민첩성,시험성, 안정성 등에 영향을 미치는 시스템 내부의 컴포넌트와（또는） 서비스 간의 커플링 지점을 가리킵니다. + +인터페이스는 게이트웨이, 통합 허브, 서비스 버스, API 프록시를 통해 서비스와 컴포넌트에 （를） 액세스하고 조정하는 수단을 말합니다. + +구현 기술은 원래 그 자체는 기술적인 것이지만, 아키텍처의 많은 부분에 영향을 미치는 플랫폼, 프레임워크, 도구, 프로세스에 관한 결정입니다. + +## **19.3** 아키텍처 결정 레코드 + +아키텍처 결정을 가장 효과적으로 문서화하는 방법은 바로 아키텍처 결정 레코드 입니다. + +### **19.3.1** 기본구조 + +ADR의 기본 구조는 제목, 상태, 콘텍스트, 결정, 결과, 이렇게 주요 5개 섹션으로 구성됩니다. 여기에 컴플라이언스와 노트라는 추가 섹션을 덧붙입니다. + +![image](https://github.com/user-attachments/assets/278a75da-cbd9-4573-b24b-f35602931f01) + +제목 + +ADR 제목은 일련 번호와 함께 아키텍처 결정을 짤막한 문구로 표현합니다. 예를 들어, 주문 서비스와 결제 서비스가 서로 비동기 메시징을 사용하기로 결정했다면 ‘42. 주문 서비스와 결제 서비스 간의 비동기 메시징 사용’ 정도의 제목을 씁니다. 아키텍처 결정의 성격과 콘텍스트의 모호함을 해소할 수 있을 정도로, 짧고 간결하게 기술합니다. + +상태 + +ADR 상태는 제안됨**Proposed,** 수락됨**Accepted,** 대체됨**Superseded**으로 표시합니다. ‘제안됨’은 해당 결정이 상위 레벨의 의사 결정권자 또는 아키텍처 거버넌스 협의체의 승인을 득해야 하는 상태입니다. ‘수락됨’은 결정이 승인되어 구현할 준비가 된 상태입니다. + +‘대체됨’은 결정이 번복되어 다른 ADR에 의해 대체된 상태로, 이전 ADR 상태는 수락됨 상태여야 합니다. 제안됨 상태의 ADR은 다른 ADR로 대체되는 일 없이 수락됨 상태가 될 때까지 계속 수정됩니다. + +대체됨 상태는 어떤 결정이 내려졌고, 당시 왜 그런 결정을 했는지, 새로운 결정은 무엇이고 어쩌다 변경을 하게 됐는지 등에 관한 이력을 보관하는 강력한 수단입니다. + +일반적으로 어떤 ADR이 대체되면 그 ADR을 대체한 결정이 병기되며, 반대로 다른 ADR을 대체한 결정은 자신이 대체한 ADR이 병기됩니다. 예를 들어, ADR 42는 이미 전에 승인됐지만 이후 결제 서비스의 구현체 및 위치가 바뀌어 두 서비스 간 통신 방식을 REST로 변경하기로 했다면（ADR 68）상태는 다음과 같습니다. + +``` +ADR 42. 주문 서비스와 결제 서비스 간의 비동기 메시징 사용 +상태: 68로 대체됨 +ADR 68. 주문 서비스와 결제 서비스 간의 REST 사용 +상태:수락됨, 42를 대체함 +``` + +이렇게 ADR 42와 ADR 68를 서로 연관 지어 이력을 남기면 나중에 ADR 68에 대해 “메시징을 사용하는 게 어떨까요?” 같은 불필요한 질문이 나올 일은 없겠죠. + +ADR 상태 섹션은 아키텍트 본인이 아키텍처 결정을 승인할 수 있는 기준, 상급 아키텍트의 승인이나 아키텍처 검토 위원회, 또는 다른 아키텍처 관리 협의체의 승인을 받고 진행해야 하는지 등의 문제를 두고 자신의 상사나 수석 아키텍트와 대화를 하도록 만들기 때문에 중요한 측면도 있습니다. + +콘텍스트 + +ADR 콘텍스트 섹션은 불가항력적인 요소를 특정합니다. 다시 말해, ‘어떤 사정 때문에 그렇게 결정할 수밖에 없었나?’입니다. 아키텍트는 이 섹션에서 특수한 상황이나 문제점을 이야기하고 다른 대안에 대해 상술합니다. + +콘텍스트 섹션은 아키텍처를 문서화하는 수단이기도 합니다. 아키텍트는 콘텍스트를 기술함으로써 곧 아키텍처를 기술하는 것입니다. 이는 분명하고 간결하게 특정 아키텍처 영역을 문서화하는 효과적인 방법입니다. + +앞 절의 예로 돌아가 콘텍스트를 읽어보면 이렇습니다. ‘현재 주문의 *총* 결제 금액을 주문 서비스가 처리하려면 반드시 결제 서비스에 정보를 전달해야 하는데 이는 REST 또는 비동기 메시징을 통해 수행할 수 있다’ 이 간결한 한 문장에 시나리오는 물론 대안까지 들어있습니다. + +결정 + +ADR 결정 섹션에는 아키텍처 결정과 그렇게 결정하게 된 사유를 전부 밝힙니다. 마이클 나이가드는 수동적인 어조 대신, 매우 긍정적이고 당당한 어조로 아키텍처 결정을 설명하는 훌륭한 방법을 강조합니다. 예를 들어, 서비스 간에 비동기 메시징을 사용하기로 결정했다면 ‘서비스 간의 비동기 메시징이 최선의 선택이라고 생각합니다’ 보다는 ‘서비스 간에는 비동기 메시징을 사용할 것입니다’라고 기술해야 그 결정을 설명하는 문장으로서 설득력이 있습니다. 전자는 아키텍트의 의견만 기술된 문장으로, 어떤 아키텍처 결정을 했는지, 심지어 정말 그렇게 결정했는지 확실하지 않습니다. + +결정 섹션의 가장 큰 강점은 아키텍트가 방법how보다 이유why에 더 무게를 실을 수 있다는 것입니다. 사실 왜 그런 결정을 내렸는지 이해하는 것이 그것이 어떻게 작동되는지 이해하는 것보다 훨씬 더 중요합니다. 아키텍트와 개발자는 콘텍스트 다이어그램을 보고 작동 원리를 짐작할 수는 있지만 왜 그렇게 결정했는지는 도통 알 수가 없습니다. 결정을 내린 이유와 그런 결정을 할 수밖에 없었던 사연을 알고 나면 사람들은 문제의 맥락을 더 잘 이해하고 행여 다른 문제가 생기지 않도록 리팩터 링을 통해 실수를 예방할 수 있습니다. + +결과 + +ADR 결과 역시 아주 강력한 섹션입니다. 이 섹션에는 아키텍처 결정의 전체적인 영향도를 기술합니다. 아키텍트가 어떤 결정을 하더라도 *좋은* 영향과 나쁜 영향은 공존하기 마련입니다. 아키텍처 결정이 어떤 영향을 미치는지 구체적으로 기술함으로써 아키텍트는 결정의 장점보다 그 영향이 더 중요한지 되돌아보게 됩니다. + +이 섹션은 아키텍처 결정에 관한 트레이드오프는 물론, 분석 결과도 문서화할 수 있으므로 유용합니다. 트레이드오프는 비용 기반일 수도 있고 다른 아키텍처 특성과의 트레이드오프일 수도 있습니다. + +컴플라이언스 + +**ADR**의 컴플라이언스 ****섹션은 표준 섹션은 아니지만 우리는 반드시 추가하라고 권장합니다. 이 섹션은 컴플라이언스 관점에서 아키텍트가 아키텍처 결정을 어떻게 측정/관리하는 게 좋을지 생각하게 만듭니다. 아키텍트는 본인의 결정에 대한 컴플라이언스 체크를 수동으로 할지, 아니면 피트니스 함수로 자동화할지 결정해야 합니다. 피트니스 함수로 자동화할 수 있으면 피트니스 함수를 작성하는 방법, 그리고 컴플라이언스 측면에서 이 아키텍처 결정을 판단하기 위해 코드베이스에 다른 변경은 필요 없는지 등의 내용을 이 섹션에 기재합니다. + +노트 + +노트 섹션 역시 표준 섹션은 아니지만 가급적 추가하는 게 좋습니다. 이 섹션에는 다음과 같이 ADR에 관한 다양한 메타데이터가 포함됩니다. + +- 원저자 +- 승인일 +- 승인자 +- 대체일 +- 최종수정일 +- 수정자 +- 최종수정내역 + +ADR을 （깃 같은） 버전 관리 시스템에 저장할 때에도 저장소에서 지원되지 않는, 부가적인 메타 정보가 있으면 유리하므로 ADR을 어디에, 어떻게 저장하더라도 이 섹션은 추가하는 것이 좋습니다. + +### **19.3.2 ADR** 저장 + +이렇게 작성한 ADR은 어딘가에 저장을 해야 합니다. 저장 위치와 상관없이 각 아키텍처 결정은 자체 파일이나 위키 페이지도 갖고 있어야 합니다. 일부 아키텍트들은 ADR을 소스 코드와 함께 깃 리포지터리에 보관하는 것을 선호합니다. 깃 리포지터리에 ADR을 보관하면 버전 관리 및 추적은 간편하지만, 규모가 큰 조직에서는 몇 가지 주의할 점이 있습니다. + +첫째, 아키텍처 결정을 확인해야 하는데 어떤 이들은 깃 리포지터리에 액세스할 수 없는 경우가 있습니다. + +둘째, 애플리케이션 깃 리포지터리를 벗어난 콘텍스트가 있는 ADR을 깃에 저장하는 것은 적절하지 않습니다. 그러므로 ADR은 위키 （또는 위키 템플릿） 또는 다른 문서 렌더링 소프트웨어 에서 쉽게 접근 가능한 공유 파일 서버의 공유 디렉터리에 저장하는 것이 좋습니다. + +![image](https://github.com/user-attachments/assets/d364e455-e141-431d-8b4f-69c80145b749) + +ADR을 위키에 저장（우리는 이것을 권장합니다）하면 앞서 기술한 것과 동일한 구조가 적용되어 각 디렉터리 가 곧 네비게이션 랜딩 페이지가 됩니다. ADR 하나가 각각의 네비게이션 랜딩 페이지 （application, integration, enterprise）에 단일 위키 페이지로 표시됩니다. + +### **19.3.3 ADR** 로문서화 + +소프트웨어 아키텍처의 문서화는 언제나 어려운 주제입니다. 아직 이렇다 할 소프트웨어 아키텍처 문서화 표준은 없습니다. 어쩌면 그래서 더 더욱 ADR이 필요한 건지도 모르겠습니다. + +ADR은 소프트웨어 아키텍처를 효과적으로 문서화하는 수단으로 활용할 수 있습니다. ADR 콘텍스트 섹션은 아키텍처 결정이 필요한 시스템의 특정 영역을 기술하는 더 없이 훌륭한 장소인 데다 어떤 대안들이 있는지 기술하기에 적절한 곳입니다. 하지만 무엇보다 중요한 섹션은, 아키텍처 결정을 내린 사유가 기술된 결정 섹션입니다.이 섹션 하나만 봐도 ADR은 현존하는 최고의 아키텍처 문서화 포맷입니다. + +### **19.3.4 ADR** 로 표준화 + +이 세상에 표준을 좋아하는 사람이 있을까요? 일반적으로 표준은 그것이 유용해서 라기보다 사람들이 일하는 방식을 통제하는 용도로 더 많이 사용되는 것 같습니다. 그러나 ADR을 표준화하면 이런 나쁜 관행이 바뀔 수도 있습니다. + +ADR 결과 섹션은 어떤 표준이 타당하며 반드시 지켜져야 하는지를 아키텍트 스스로 검증하기에 적합한 기회입니다. 아키텍트는 이 섹션에서 자신이 작성 중인 표준의 의미와 결과가 무엇인지 심사숙고해야 합니다. 이로써 막상 결과를 분석해보니 이 표준은 적용하면 안 되겠다. 결정을 뒤바꿀 수도 있겠죠.