소프트웨어 아키텍쳐 101 리뷰
소프트웨어 아키텍쳐 101- 3년차 백엔드 개발자가 배운 아키텍쳐 사고
이 책을 선택한 이유
AI가 코드를 작성하는 시대가 왔다. 요즘 실무에서 LLM을 활용하다 보니 코드 레벨의 구현보다 구조적인 고민을 하는 시간이 늘어났다. 좋은 구조를 채택하면 코드 구현은 상대적으로 쉬워진다. 하지만 구조는 코드보다 변경하기 어렵다. 그래서 요건과 제약, 상황을 고려한 트레이드오프 하에서 ‘좋은 구조’를 택하는 것이 점점 더 중요한 시대가 되었다고 느낀다. 3년차 서버 개발자로서 이런 고민을 해결하고자 『소프트웨어 아키텍처 101』을 집어 들었다. 그리고 이 책을 읽으며 전 회사의 데브옵스 엔지니어분이 계속 떠올랐다. 그분의 많은 언행이 이 책의 영향을 받았을 것 같다는 생각이 들 정도로, 책의 내용과 그분의 업무 방식이 겹쳐 보였다.
리스크 스토밍
데브옵스 엔지니어분은 아키텍트로서 백엔드 개발자들의 기술 실력 향상에 큰 관심을 가지고 있었다. 단순히 “이렇게 하세요”가 아니라 항상 깊이 있는 공부를 강조했다. RESTful 설계를 위해 Roy Fielding의 REST 논문을 읽히는 식이었다. 원론을 알아야 한다는 그분의 철학이 지금은 더욱 이해가 된다.
가장 인상 깊었던 점은 Lucidchart를 활용한 시각화 능력이었다. 시퀀스 다이어그램, 아키텍처 구상도를 그리는 실력이 탁월했고, 이를 통해 팀원들과 공유하고 피드백을 구하며 위험성을 평가했다. 이제 보니 이 과정이 책에서 말하는 리스크 스토밍(Risk Storming)의 실제 예시였던 것 같다. 리스크 스토밍은 아키텍처 설계의 위험 요소를 시각적으로 식별하고 평가하는 협업 기법이다. 그분이 다이어그램을 그리고, 우리와 함께 “이 부분이 병목이 될 수 있다”, “여기서 장애가 발생하면 어떻게 될까” 같은 질문을 주고받던 과정이 바로 그것이었다. 당시에는 그저 꼼꼼한 분이라고만 생각했는데, 이제는 그것이 체계적인 아키텍처 사고 방식이었음을 알게 되었다.
ADR: 왜 이렇게 만들었는가?
개발을 하다 보면 항상 이런 의문이 든다. “이 부분은 왜 이렇게 개발된 거지?” 히스토리를 찾으려 해도 코드 커밋 메시지나 티켓만으로는 맥락을 파악하기 어렵다. 특히 시간이 지나면 당시의 상황, 고려했던 대안, 선택의 이유는 모두 사라진다. 책에서 소개하는 ADR(Architecture Decision Records) 은 이 문제를 해결하는 명쾌한 방법이다.
이는 아키텍처 결정의 맥락(Context), 결정 사항(Decision), 결과(Consequences)를 문서화하는 것이다. 단순한 회의록이 아니라, 왜 그렇게 결정했는지, 어떤 대안을 고려했는지, 그 결정이 어떤 영향을 미칠지를 기록한다. 실무에서 이런 기록이 있었다면 얼마나 좋았을까. 레거시 코드를 보며 “도대체 왜?”를 외치는 대신, ADR을 찾아보고 당시의 맥락을 이해할 수 있었을 것이다. 더 나아가, 그 결정이 현재 상황에서도 유효한지 평가하고, 필요하다면 새로운 ADR을 작성해 아키텍처를 진화시킬 수 있다.
팀 효율과 엔지니어의 자세
책의 후반부는 소프트 스킬에 많은 지면을 할애한다. 이 부분이 예상 밖으로 가장 많은 영감을 줬다. 리스크 분석은 이미 내게 체화된 기술이라고 생각했다. 새로운 기능을 개발할 때 “이게 문제가 될 수 있나?”, “이 API가 스파이크 트래픽을 견딜 수 있나?” 같은 질문을 던지는 것은 일상이었다. 하지만 책은 이를 단순한 개인의 습관이 아니라, 팀 차원에서 체계적으로 수행하는 방법론으로 정리해준다.
팀 효율에 대한 챕터를 읽으면서는 엔지니어이자 팀원으로서의 자세를 다시 생각하게 됐다. 아키텍트는 기술적 결정을 내리는 사람이지만, 동시에 개발자들과 협업하고 그들의 성장을 돕는 사람이다. 현대 사회의 좋은 개발자라면 코드를 잘 짜는 것도 중요하지만, 팀의 기술 수준을 끌어올리고, 좋은 결정을 내릴 수 있는 환경을 만드는 것도 해야 하는 일이라고 생각이 들었다.
아키텍처 카타: 시니어의 사고방식을 엿보다
책의 또 다른 매력은 아키텍처 카타(Architecture Kata) 다. 실전 문제를 제시하고, 독자가 먼저 고민해볼 기회를 준 다음, 저자의 접근 방식을 보여준다. 나는 문제를 보고 “음, 이렇게 풀면 되지 않을까?” 하고 고민했다. 그리고 저자의 솔루션을 보며 “아, 이런 부분도 고려해야 하는구나”, “이 트레이드오프는 생각 못 했네” 하며 배웠다. 마치 시니어 개발자에게 1:1 멘토링을 받는 기분이었다. 이 과정에서 깨달은 것은, 좋은 아키텍처란 정답이 아니라 최선의 트레이드오프라는 점이다. 모든 요구사항을 완벽히 만족하는 아키텍처는 없다. 성능을 택하면 복잡도가 올라가고, 단순함을 택하면 확장성에 제약이 생긴다. 아키텍트는 이런 트레이드오프를 명확히 인식하고, 상황에 맞는 선택을 하는 사람이다.
구조가 먼저, 코드는 그다음
이 책을 읽으며 확신한 것이 하나 있다. 구조를 잘 짜면 코드는 자연스럽게 따라온다. AI 시대에 이것은 더욱 명확해졌다. LLM에게 명확한 구조와 컨텍스트를 주면 놀라운 속도로 코드를 작성해준다. 하지만 구조가 잘못되면? 아무리 코드를 잘 짜도 언젠가 한계에 부딪힌다. 모놀리스로 시작할 것인가, MSA로 갈 것인가. 이벤트 기반 아키텍처를 택할 것인가, 레이어드 아키텍처로 충분한가. 이런 결정은 한 번 내려지면 바꾸기 어렵다. 그래서 초기 설계가 중요하고, 그 설계를 내릴 때 무엇을 고려해야 하는지 아는 것이 중요하다.
3년차 개발자가 아키텍처를 배워야 하는 이유
“아키텍처는 시니어의 영역 아닌가요?” 이런 질문을 받을 수 있다. 나도 처음엔 그렇게 생각했다. 하지만 이제는 안다. 아키텍처 사고는 경력과 무관하게 개발자라면 갖춰야 할 기본 소양이다. 물론 전사 아키텍처를 설계하거나, 수십 개 서비스의 통합을 책임지는 것은 시니어의 몫이라고 생각할 수 있지만, 지금까지의 커리어를 돌아보면 예상대로 일을 맡게 되지 않은 적들이 많았고, 그런 일을 맡게 된 것들이 나를 성장시켜준 행운이라 생각한다.
내가 만드는 API의 구조, 데이터베이스 스키마, 모듈 간 의존성 같은 작은 결정들도 모두 아키텍처다. 이런 결정을 내릴 때 트레이드오프를 인식하고, 명확한 근거를 가지고 선택하는 것. 그것이 아키텍처 사고의 시작이다.
1
2
3
- 코드를 넘어 구조를 보는 법
- 현재가 아닌 미래를 고려하는 법
- 혼자가 아닌 팀과 함께 결정하는 법
마치며
『소프트웨어 아키텍처 101』은 기술서이면서 동시에 사고방식에 관한 책이다. 레이어드, 마이크로서비스, 이벤트 기반 같은 구체적인 아키텍처 스타일도 배우지만, 더 중요한 것은 어떻게 생각하고, 어떻게 결정하며, 어떻게 팀과 협업할 것인가를 배운다는 점이다.
이 책을 읽었던 시간은 과거를 이해하고 미래를 준비하는 시간이었다. 과거에 나는 데브옵스 엔지니어분이 막연하게 매우 꼼꼼하고 프로같다고 생각했다. (때로는 기계같다고도 생각했다) 그리고 나도 언젠가 그런 엔지니어가 되고 싶다고 생각했는데, 그 언행의 원리를 담고 있는 듯한 책을 만나서 매우 재밌게 읽었다. 아키텍처로의 사고를 배우고 싶은 개발자, 시니어로 성장하고 싶은 주니어, 팀을 이끌고 싶은 테크 리드라면 이 책을 권한다.(초반은 고민할 부분이 많아서 읽기 어렵다고 느낄 수 있지만 뒷 부분은 정말 잘 읽혀요)