개발자에서 아키텍트로

📓 독서후기

「개발자에서 아키텍트로」 독서 후기

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

  • 1장. 소프트웨어 아키텍트가 되다
  • 2장. 디자인 싱킹 기초

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

  • 3장. 설계 전략 고안하기
  • 4장. 이해관계자와 공감하기
  • 5장. 아키텍처 핵심 요구사항 알아내기
  • 6장. 아키텍처 선택하기
  • 7장. 패턴으로 기초 만들기
  • 8장. 의미 있는 모델로
  • 9장. 아키텍처 디자인 스튜디오 운영하기
  • 10장. 설계 시각화하기
  • 11장. 아키텍처 문서화하기
  • 12장. 아키텍처 평가하기
  • 13장. 아키텍트에게 힘 실어주기

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

  • 14장. 문제를 이해하고 싶을 때
  • 15장. 해결책을 찾고 싶을 때
  • 16장. 손에 잡히는 설계를
  • 17장. 설계 대안을 평가하고 싶을 때

소프트웨어 구조 설계를 엿보고 싶어 읽기 시작했지만, 단순히 소프트 웨어 설계에 대한 내용뿐만 아니라 개발자로써 많은 생각을 할 수 있었던 서적이었다.

「개발자에서 아키텍트로」 독서 후 개인적으로 인상 깊었던 큰 맥락들만 추려서 간략하게 후기를 남겨보려한다.

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

---

전반적으로 1부는 소프트웨어 아키텍쳐에 대한 깊이있는 내용보다는 “아키텍트”가 팀 내에서 하는 일이 무엇이며, 어떤 위치로 팀에서 존재하는지에 대하여 풀어나간다.

"개발자에서 아키텍트로" 아키텍트는 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람입니다.

“개발자에서 아키텍트로” 아키텍트는 비즈니스 요구사항과 기술 선택을 잇는 일도 합니다.

요즘은 “아키텍쳐”라 따로 불리기 보다는 “시니어 개발자”라고 조금 더 포괄적으로 불리우는것 같다. 설계 능력은 시니어 개발자의 최소 자격요건으로 요구하는 것이 아닐까? 라는 생각이 많이 들었다. (이 책에서도 아키텍쳐는 팀을 리딩하는 역할이라 언급한다.)

단순히 구현만 잘해내는 개발자가 아닌, 비즈니스 요구사항에 알맞는 기술을 선택하기도하며 팀의 기술 부채를 시각화하고 팀을 매니징할 수 있는 능력을 지닌 인재를 요즘 시장에서는 “시니어 개발자”로 부르고 있고 책에서는 “아키텍쳐”라 표현하는 듯 하다.

요즘들어 AI의 보편화로 인해 더욱더 이러한 능력이 부각되고 있는 듯 하다. 이러한 소프트웨어 아키텍쳐에 대한 영역은 더더욱 경험에 기반한 개인의 역량에 의해 결정되다 보니 당연하지 않을까 싶다.

하지만 위에서 언급한 아키텍쳐가 하는 일에 대한 내용은 1부의 내용 중 가장 인상 깊은 구문은 아니었다. 가장 인상 깊었던 구문을 꼽으라면 아래와 같다.

“어떤 팀은 아키텍트가 없다고 말하지만, 자세히 살펴보면 누군가는 아키텍트의 역할을 이미 수행하고 있기도 합니다. (생략) 모든 팀에는 최소한 한 명의 아키텍트가 있습니다. 최고의 팀에는 여러 명이 있습니다.”

“개발자에서 아키텍트로” 팀에서 아키텍트가 되려면

이 구문을 보고 생각이 많아졌다. 우리 팀에는 여러 명의 아키텍트가 존재하는거 처럼보인다. 그렇다면 “최고의 팀인가?”라고 하기엔 아직은 거리가 멀다 생각이 든다. (고군분투하는 팀이지 않을까?)

아무튼 1부에서 가장 생각이 많아지는 구문을 꼽으라면 위 구문을 꼽는다.

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

---

2부를 간략하게 요약하자면, 조직 안에서 최선의 아키텍쳐를 선택하는 방법론과 그렇게하여 선택한 아키텍쳐를 어떻게 꾸준히 평가하며 필요에 따라 유연히 변경해가며 관리해 나갈 수 있는지에 대한 전반적인 소프트웨어 아키텍쳐에 대한 깊은 내용이 나온다. (어려운 내용도 많이 나온다..!)

또한, 역설적으로 설계에 너무 많은 자원(시간, 인력 등)을 투자시 발생하는 부작용에 대해서도 언급하며 “설계 최적점”을 찾는 노력을 강조한다. (다만, 이는 경험에 기댄 의사결정이 많이 필요해보인다.. “주니어 개발자는 어렵지 않을까?” 라는 생각이 들었다. 🥲)

“개발자에서 아키텍트로” 설계를 얼마나 우선해야 하는가

한번 선택된 아키텍쳐는 불변하지 않음을 강조하며 팀의 상황과 기술의 변화를 반영하여 꾸준히 평가하고 관리되어야 하며 필요하다면 언제나 변경될 수 있음을 강조한다.

“개발자에서 아키텍트로” 아키텍쳐 평가하기

잘못된 아키텍처는 한명의 책임자가 책임질 수 있는 상황이 아니게 되므로, 팀 기반의 의사결정이 꼭 필요해보인다. 팀 모두가 설계에 참여할 수 있게끔 소통을 자주하는게 중요해보였다.

🤔 Understanding

간단하게 2부까지의 내용을 요약하여 정리하는 동안 내내 “나는 과연 아키텍트에 가까울까?”라는 생각을 하게되었다.

소프트웨어를 설계하는 능력은 어느덧 개발자(특히, 백엔드 개발자)로 살아남을 수 있는 자격요건 중 필수 조건이 되어버린 듯하다.

다양한 시각을 위해 여러 경험(실패하는 경험 또한 훌륭한 자양분이다.)이 중요하다 생각이 많이 들었다. 물론, 그 경험을 온전히 흡수하여 내것으로 만들수 있느냐는 개인이 지닌 역량마다 편차가 있을꺼라 생각한다.

개발하며 마주하는 여러 고민의 기로들 사이에서 그저 그런 평범한 개발자로 남느냐, 성장하고 도약해서 고급 개발자로 발전하느냐의 차이지 않을까? 싶었다.

아무튼, 다소 내용은 어렵지만 읽고 나니 생각이 많아지는 책이었다.