소프트웨어 아키텍처 The Basics(2판) 리뷰 - 한빛미디어

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

시작하며

연차가 쌓이면서 코드 외적인 것들을 자연스레 신경쓰게 된다. 슬슬 인프라쪽도 더 공부해서 팀원들 도움받지 않고 구축하고 싶었는데 “이 책이 답을 줄 수 있을까?” 기대하며 펼쳤다. 이 책의 내용은 오히려 더 베이스를 이루는 아키텍처들을 다뤘다. 그래서 책을 쭉 봤을 때 내용이 많이 어려웠다. 하지만 여러번 읽다보면 이해가 될 것이라 기대했다.

책에서 소개하는 여러 아키텍처 패턴들은 익숙한 프론트엔드 디자인 패턴과는 사뭇 다른 느낌이었다. 근데 끝까지 읽고 나니 아키텍트들이 어떤 고민을 하고, 어떤 기준으로 결정을 내리는지 조금은 이해할 수 있었다.

하지만 돌이켜 생각해봤을 때 나도 자잘하게 이런 결정들을 했었다.

개발자와 아키텍트는 뭐가 다를까

• “이 함수를 어떻게 짤까?”
• “어떤 라이브러리를 쓸까?”
• “이 버그는 어떻게 고치지?”

책에서는 이런 고민들을 전술적(tactical) 결정이라고 불렀다.

반면 아키텍트는 전략적(strategic) 결정을 한다:

• “우리 시스템에 정말 중요한 건 뭘까?”
• “어떤 구조가 우리 비즈니스에 맞을까?”
• “이 선택을 하면 뭘 포기해야 할까?”

아키텍트는 시스템 전체로 넓게 보는 느낌이다.

예를 들어, 내가 버튼 컴포넌트를 만들 때는 “어떻게 예쁘게 만들지”를 고민한다. 하지만 아키텍트는 “100개 넘는 버튼의 일관성을 어떻게 유지할지”, “각 팀이 독립적으로 개발하려면 어떤 구조가 필요할지”를 고민하더라.

나는 코드 한 줄에 집중하는데, 아키텍트는 시스템 전체를 본다. 줌 아웃의 정도가 다르달까. 그 간격이 생각보다 크다는 걸 이 책을 통해 체감했다.

아키텍트는 번역가다: 기술과 비즈니스 사이

책에서 가장 인상 깊었던 부분 중 하나는 아키텍트의 번역자 역할이구나 싶었다.

개발자는 “React 18로 마이그레이션해야 합니다”, “Redis 캐시를 도입하면 됩니다”처럼 기술 언어로 말한다. 하지만 경영진은 “그래서 매출이 늘어나나요?”, “비용은 얼마나 드나요?”, “언제 끝나나요?”를 궁금해한다.

아키텍트는 이 둘 사이를 연결한다.

“Redis 캐시를 도입하면 페이지 로딩 속도가 2초 빨라집니다. 이는 사용자 이탈률을 15% 줄이고, 월 매출을 약 500만원 증가시킬 수 있습니다. 초기 구축 비용은 2주, 200만원 정도 예상됩니다.”

기술적 결정을 비즈니스 가치로 변환하는 것. “좋은 코드”가 아니라 “좋은 코드가 만드는 비즈니스 임팩트”를 설명해야 한다.

나는 지금까지 “좋은 코드를 짜면 인정받는다”고 생각했다. 근데 실제로는 그 코드가 비즈니스에 어떤 영향을 주는지 설명할 수 있어야 인정받는다는 걸 깨달았다.

“컴포넌트 재사용성을 높였습니다”보다 “개발 시간을 30% 단축해서 기능 출시를 2주 앞당길 수 있습니다”가 더 설득력 있다.

책에서는 이런 소통 능력을 기술만큼이나 중요하게 다룬다. 아무리 좋은 아키텍처를 설계해도, 이해관계자를 설득하지 못하면 실행할 수 없기 때문이다.

실제 회사에서도 기술스택 변경 마이그레이션을 하려고 C레벨을 설득해야 했을 때가 있었는데, 이런 경험을 바탕으로 이해가 됐고 이것은 단순 아키텍트만이 아니라 개발자들도 갈고 닦아야 하는 능력이었다.

모든 결정은 트레이드오프다

책을 읽으면서 계속 “응, 그렇지” 하게 되더라. 책에서 가장 많이 나온 단어가 트레이드오프. 모든 걸 다 잘할 수는 없다.

성능을 올리려면? 코드가 복잡해진다. 보안을 강화하면? 개발 속도가 느려진다. 처음부터 확장 가능하게 만들려면? 초기 비용이 크다. 유연한 구조를 만들려면? 단순함을 포기해야 한다.

항상 뭔가를 포기해야 한다는 걸 머리로는 알았는데, 이렇게 명시적으로 정리해주니까 속이 시원했다.

프론트엔드로 예를 들면, SSR을 도입하면 초기 로딩은 빨라지지만 서버 비용이 증가하고 배포가 복잡해진다. 타입스크립트를 쓰면 안정성은 높아지지만 초기 러닝커브와 설정 비용이 든다.

아키텍트는 “무엇이 우리에게 가장 중요한가?”를 먼저 정한다. 그리고 나머지는 어느 정도 포기한다.

이커머스 사이트라면 성능이 최우선일 수 있다. 0.1초 지연이 매출에 직접 영향을 주니까. 반면 내부 관리 도구라면 빠른 개발과 유지보수성이 더 중요할 수 있다.

완벽은 없다. 그때그때 최선이 있을 뿐이다. 이 문장이 책 전체를 관통하는 메시지라고 생각한다.

기술보다 중요한 것: 소프트 스킬

이 책에서도 소프트 스킬을 강조한다. 아무리 좋은 아키텍처를 설계해도, PM을 설득하지 못하면 실행할 수 없다. CEO에게 비즈니스 가치를 설명하지 못하면 예산을 못 받는다. 팀원들의 협조를 얻지 못하면 혼자 고군분투하다 끝난다.

특히 기억에 남는 건 트레이드오프를 설명하는 법이다. “모든 기능 다 넣어야 해요!”라고 할 때, “안 됩니다”가 아니라 “A를 선택하면 B를 포기해야 하는데, 어떻게 할까요?”처럼 현실적인 대안을 제시하는 것이다. 무조건 받아들이는 것도, 무조건 거절하는 것도 아니고, 함께 최선을 찾아가는 거다.

이런 능력은 지금도, 시니어가 되어서도 계속 필요할 것 같다.

실용적인 조언들

이 책에서 설명하는 20분 규칙은 하루에 딱 20분만 투자해서 새로운 기술들을 훑어보고 판단하는 것이다.

프론트엔드는 트렌드가 빠르게 바뀌니까, 모든 걸 다 깊게 공부할 수는 없다. 하지만 완전히 무시하기도 찝찝하다. 20분 규칙은 그 중간 지점을 찾는 현실적인 방법이다.

또 하나는 생성형 AI 시대의 개발자 역할에 대한 내용이다. AI가 코드를 짜주는 시대지만, “어디에 어떤 코드를 둘지”, “어떤 구조가 맞는지”, “무엇을 포기하고 무엇을 선택할지”는 여전히 사람이 결정해야 한다.

마무리

지금은 컴포넌트나 함수 레벨에서 고민하지만, 점점 더 시스템 전체를 설계하는 쪽으로 생각하려고 한다.

그때 이 책에서 배운 것들이 도움이 될 것 같다. 특히 **“정답은 없다. 항상 트레이드오프다. 그때그때 최선을 찾는 거다”**라는 생각. 완벽을 추구하다가 아무것도 못 하는 것보다, 그때의 최선을 선택하고 나중에 개선하는 게 낫다. 이게 아키텍처의 본질인 것 같다.

어려운 책이었지만, 읽길 잘했다고 생각한다. 읽다보면 더 디테일한 내용들도 이해될 것 같다.

다음 단계로 성장하기 위한 준비를 조금은 한 것 같다.