Amazon VPC 네트워킹 원리와 보안
데이터 중심 애플리케이션 설계 2판
2025-02-13: 요즘 개발자를 위한 시스템 설계 수업
시스템 설계는 AI 시대에 개발자로서 관심가져야 할 부분이기도 하고 종립님의 리뷰에서도 좋은 평가를 받았길래 읽어보았다.
데이터 중심 애플리케이션 설계 2판과 같이 읽으면서 겹치는 부분도 있어 상호보완적으로 읽기 좋았다.
이 책은 시스템 설계의 정의부터 분산 시스템을 이루는 특징과 필요성 그리고 분산 시스템의 근본적 한계인 CAP, (CAP의 확장인) PACELC, 비잔티움 장군 문제, FLP까지 설명하여 시스템 설계 입문으로 읽기 굉장히 친절하다고 느꼈다.
FLP: 합의가 끝날 수 있나? 보장 불가 (비동기 + crash)
비잔티움: 배신자가 있어도 합의 가능한가? n > 3f 일 때만 가능
CAP: 네트워크 파티션 단절 발생시 무엇을 포기하나? C 또는 A
PACELC: 정상일 때도 트레이드오프가 있나? L 또는 C
- 설계 단계에서는 데이터 흐름을 이해하는 것이 제일 중요하다.
- 데이터 구조, 수집, 저장, 처리, 검색 (DDAI에서와 동일한 강조였다.)
- 분산 시스템에서의 데이터 읽기, 쓰기 옵션
- 직렬 동기 쓰기, 직렬 비동기 쓰기, 병렬 비동기 쓰기, 메시징 서비스 쓰기
- 하나의 레플리카에서 읽기, 일부 레플리카에서 읽기, 모든 레플리카에서 읽기
- 강한 일관성과 최종적 일관성
- 일관된 해싱을 보장하기 위한 방법
- 링 모양 해싱 + 가상 노드 사용
- DNS의 재귀적 쿼리와 반복적 쿼리 방법
- 로드밸런서가 사용하는 알고리즘
- 전송 계층과 응용 계층의 로드밸런서 특징
- 데이터 복제 전략
- 주 노드와 보조 노드로 구성된 주-종 모델, 또는 모든 노드가 대등한 역할을 하는 동등 모델
- 힌트 전달 방식을 통해 특정 노드에 장애가 발생하더라도 복구 가능
- 분산 캐싱의 장점과 한계점
가상 면접 사례로 배우는 대규모 시스템 설계 기초 1,2권을 읽기 전에 이 책을 통해 분산 시스템에 대한 내용을 이해하는 것이 도움될 것 같다.
2025-01-29: 엔터프라이즈 애플리케이션 아키텍처 패턴
회사에서 애플리케이션 아키텍처를 고민하는 상황이 있어서 고전인 이 책이 떠올라 읽어보았다. 지금 읽기에는 조금 주저하게 되긴 했지만, 오래전부터 많이 들었던 단어들과 패턴에 대해 더 자세하게 이해할 수 있는 계기가 되어서 좋았다.
이 책에서 크게 두 가지 관점을 얻었다.
- 도메인 논리의 구조를 이해하고 무엇이 적절한가? -> 트랜잭션 스크립트, 도메인 모델, 테이블 모듈
- 데이터 접근 전략의 트레이드오프 -> 테이블/행 데이터 게이트웨이, 활성 레코드, 데이터 매퍼
그리고 이 패턴들이 배치되는 두 계층의 책임을 명확히 구분한다.
- Domain Layer : 시스템이 존재하는 이유, 즉 "비즈니스가 요구하는 것"을 표현한다. 계산, 유효성 검증, 비즈니스 규칙 판단을 담당하며, 데이터가 어디에 저장되는지 화면에 어떻게 보이는지 모른다.
- Data Source Layer : 도메인 객체와 외부 자원(DB, 파일, 외부 API) 사이의 통신을 담당한다. SQL 실행, 커넥션 관리, 결과를 도메인 객체로 변환하며, 비즈니스 규칙을 모른다.
이 책을 읽고 멀티모듈과 순수 도메인 모듈에 대해 더 우호적이게 된 것 같다. 트랜잭션 스크립트와 데이터 게이트웨이를 이용해서 데이터 원본을 호출하는 경우도 어느 정도의 복잡성을 해결할 순 있지만, 복잡한 도메인에서는 도메인 모델과 데이터 매퍼 패턴을 이용해서 영속성에 대한 의존을 끊는 것이 더 적절하다고 설명한다. 인메모리 객체가 영속성 데이터베이스 구조에 대해 알고 있으면 한 쪽의 변화가 다른 쪽에 영향을 미치게 된다. 이 두 계층은 변경의 이유가 서로 다르기 때문이다.
그렇다고 시스템 복잡도가 낮은 도메인에 적용하게 되면 불필요한 복잡도를 야기한다. 이 책을 통해 이런 트레이드오프를 간접적으로 경험할 수 있어 좋았다. 백엔드 팀에서도 순수 도메인 모듈에 대한 찬반이 대립 중인데, 계속 고민해 볼 영역인 것 같다.
고민거리
클래스 간 참조와 테이블 간 참조는 서로 방식이 다르다.
팀과 팀원이 1:N으로 존재하는 경우, 클래스에서는 팀이 팀원을 컬렉션으로 보유할 수 있다. 하지만 테이블에서는 팀원이 팀을 참조해야 한다.
이런 차이를 데이터 매퍼 영역에서 숨겨주는 것이 RDB 관점으로 개발하는 사고를 줄일 수 있지 않을까 생각해본다.
성능을 위한 비정규화나 테이블 분할처럼 도메인 로직과 무관하게 스키마가 바뀌는 경우도 있다. 이런 변경이 도메인까지 전파되지 않으려면 결국 두 계층의 분리가 필요하다.
한편으론, 테이블이 수정되는 경우는 도메인이 변경되는 것이 당연한 것 아닌가 싶기도 하다. 한번 직접 부딪혀봐야 감이 잡힐 것 같다.
2025-01-15: 일론 머스크
현재 다니고 있는 회사의 CTO님에게 추천받아서 읽어보았다.
"요즘은 개발자가 개발만 잘해서 경쟁력을 가질 수 없다. 사업에 대한 아이디어와 공감, 그리고 생각의 전환에 대한 고민이 필요하다." 라는 주제로 이야기를 나누다가 관련해서 추천해주실 만한 책이 있는지 여쭤보게 됐고, 그렇게 이 책을 알게 됐다.
이전 회사의 대표님도 일론 머스크의 팬이었는데, 책을 읽으면서 이전 회사와 대표님의 업무 방식이 떠올랐다.
이 책은 일론 머스크의 어린 시절부터 Zip2, 페이팔, 테슬라, 스페이스X, 뉴럴링크, 보링 컴퍼니, 그리고 트위터 인수까지의 여정을 다룬다.
복잡한 가족 관계, 경영 스타일, 극단적인 리스크 감수, 피포위 심리 등 머스크의 성격을 깊이 있게 들여다볼 수 있다.
대단한 사람이라는 사실은 자명하다. 하지만 직원들에게 가혹하고, 주변 사람들에게 상처를 주는 모습, 그리고 트위터 인수 과정에서 퇴직금과 스톡옵션 지급을 피하기 위해 인수 일정을 앞당긴 행동을 보면서 존경과 불편함을 동시에 느꼈다.
돌이켜보면 나는 후광효과에 빠져 있었던 것 같다. 부, 업적, 명성이 곧 그 사람의 인격이나 도덕성까지 보증한다고 무의식적으로 생각했기 때문이다.
그럼에도 확실하게 배울 점은 제1원칙 사고다. "원래 그렇게 해왔으니까"라는 유추적 사고를 거부하고, "이것이 정말 필요한가? 왜 그런가?"를 끝까지 파고드는 것이다..
- 모든 요구사항에 의문을 제기하라. 타당한 이유인가? 관행이나 약속, 규정 때문인가?
- 이 요구사항을 준 사람의 이름이 누구인가?
- 부품이든 프로세스든 최대한 제거할 수 있는가? 자동화할 수 있는가?
- 빠르게 움직이고, 날려버리고, 반복하라.
또한 곱씹어보게 되는 말들도 있었다.
"제거한 부분의 10퍼센트 이상을 복원할 필요가 없다면 충분히 제거하지 않은 것이다.""틀려도 괜찮다. 다만 잘못된 것을 옳다고 우겨서는 안 된다.""모든 기술 관리자는 실무 경험을 갖춰야 한다."
돌아보면, 나도 항상 최대한 정확하게, 리스크를 최대한 줄이기 위해 시간과 비용을 과하게 들인 경험이 있다.
완벽한 설계를 위해 트레이드오프를 피하려 했던 순간들. 이 책을 읽으면서 때로는 빠르게 시도하고, 부수고, 다시 반복하는 것도 필요하다는 걸 느꼈다.
다 읽고나니 CTO님이 왜 이 책을 추천해주셨는지 알 것 같다.
개발만 잘하는 것을 넘어서, 당연하게 여겨왔던 것들에 의문을 던지고, 더 본질적인 문제를 파고드는 사고방식.
존경과 불편함을 동시에 느끼게 한 책이지만, 일과 삶을 대하는 자세와 생각하는 방법을 배울 수 있었던 것 같다.