본문 곳곳에서 바로잡은 오해를 한곳에 모았다.
처음 공부할 때 가장 많이 헷갈리는 것들이고,
실무에서 잘못된 결정으로 이어지기 쉬운 것들이다.
각 항목은 본문에서 이유와 함께 설명하므로
궁금하면 해당 장을 펼치면 된다.
읽는 방법은 두 가지다.
처음이라면 그냥 훑어보고 넘어가도 된다.
나중에 설계를 앞두고 판단이 서지 않을 때
이 목록을 다시 보는 쪽이 더 도움이 된다.
| 이렇게 알기 쉽다 | 실제로는 | 다루는 곳 |
|---|
| Data Product = Data Mesh | 데이터 제품은 개념, 데이터 메시는 운영 방식이다. 메시 없이도 제품은 만들 수 있다 | 13장 |
| CQRS = DB 두 개 | 읽기와 쓰기의 책임을 나누는 것이다. 같은 DB에서도 가능하다 | 9장 |
| CQRS = Event Sourcing | 함께 쓰는 경우가 많을 뿐 서로 다른 패턴이다 | 9장 |
| REST = CRUD | CRUD는 흔한 관례일 뿐이다. 주문 취소처럼 CRUD로 담기 어려운 업무가 많다 | 8장 |
| FaaS = Serverless | FaaS는 서버리스의 한 형태다 | 부록 C |
| MDM = 데이터 통합 | 모으는 것보다 무엇이 같은 대상이고 어떤 값을 믿을지 정하는 일이 핵심이다 | 18장 |
| MDM = 데이터 프로덕트 | MDM 결과를 데이터 프로덕트로 제공할 수 있을 뿐 같은 개념이 아니다 | 18장 |
| 통합 뷰 = MDM | 통합 뷰는 값을 나란히 보여 주고, MDM은 어느 값이 기준인지 판단한다 | 18장 |
| 비즈니스 역량 = Bounded Context | 무엇을 할 수 있는가와 어디까지 같은 모델을 쓰는가는 다른 질문이다 | 5장 |
| DB 변경 = 비즈니스 이벤트 | 잔액이 줄었다는 사실만으로는 주문인지 조정인지 알 수 없다 | 10장 |
| 데이터 민주화 = 보안 완화 | 셀프서비스와 적절한 통제는 함께 간다 | 15장 |
| API = 동기 통신 | 요청을 받고 나중에 처리하는 비동기 API도 있다 | 12장 |
| 이렇게 알기 쉽다 | 실제로는 | 다루는 곳 |
|---|
| Single Source of Truth = 회사 전체 숫자를 하나로 | 정의마다 권위 있는 출처를 정하는 것이다. 매출도 여러 정의가 모두 옳을 수 있다 | 14장, 18장 |
| Ubiquitous Language = 전사 용어 통일 | Context 안에서 일관되면 된다. Context가 다르면 같은 단어가 다른 뜻일 수 있다 | 13장 |
| Data Mesh = 데이터를 팀별로 나누는 것 | 네 가지 원칙이 함께 있어야 한다. 나누기만 하면 새로운 사일로가 된다 | 3장, 23장 |
| 분산 = 각자 마음대로 | 도메인 자율성과 공통 거버넌스는 함께 간다 | 6장 |
| 복사하면 소유권도 넘어온다 | 원본의 책임은 그대로다. 다만 새로 계산한 값에는 새 소유자가 생긴다 | 6장 |
| Raw Data는 쓸모없다 | 재처리, 장애 복구, 감사에 필요하다. 소비자에게 그대로 던지는 것이 문제일 뿐이다 | 14장 |
| 마이크로서비스는 작을수록 좋다 | 크기가 아니라 경계가 기준이다 | 9장 |
| 데이터가 있으면 쓸 수 있다 | 어디 있고 무슨 뜻이며 믿을 수 있는지 알아야 쓸 수 있다 | 15장 |
| 이벤트는 공짜다 | 중복·순서·재처리·운영이라는 새로운 복잡성이 따라온다 | 12장 |
| Data Lake가 문제를 해결한다 | 저장 문제는 풀지만 소유권과 품질 문제는 남는다 | 2장 |
| GraphQL은 REST 위에서만 동작한다 | DB, gRPC, 캐시 등 다양한 소스를 쓸 수 있다 | 9장 |
| 이렇게 알기 쉽다 | 실제로는 | 다루는 곳 |
|---|
| 모든 것을 이벤트로 만들어야 한다 | 단순한 시스템에서는 얻는 것보다 운영 비용이 클 수 있다 | 11장 |
| 모든 내부 통신은 Gateway를 거쳐야 한다 | Gateway는 주로 외부 진입점에서 쓴다 | 12장 |
| 실시간으로 만들 수 있으면 실시간이어야 한다 | 실시간성을 높이면 비용과 난이도도 함께 오른다 | 12장 |
| 모든 데이터를 MDM으로 관리해야 한다 | 여러 시스템이 공통으로 쓰고 틀리면 영향이 큰 데이터에만 적용한다 | 18장 |
| 마스터 ID를 모든 시스템이 써야 한다 | 로컬 ID를 유지하고 매핑만 관리해도 된다 | 18장 |
| 운영 시스템은 MDM을 직접 호출해야 한다 | 핵심 거래 경로에 두면 MDM 장애가 곧 서비스 장애가 된다 | 18장 |
| 데이터 프로덕트는 원천 DB를 직접 읽어야 한다 | 신뢰할 수 있는 상위 데이터 프로덕트를 입력으로 써도 된다 | 13장 |
| 다른 도메인 DB는 절대 읽으면 안 된다 | 핵심 비즈니스 로직이 남의 내부 구현에 의존하지 않는 것이 원칙이다 | 7장 |
| 데이터 프로덕트에는 CQRS가 필요하다 | 쓰기 구조와 조회 구조가 크게 다를 때 쓸모가 있다 | 13장 |
| Bronze / Silver / Gold를 따라야 한다 | 널리 쓰이는 패턴일 뿐 필수 구조가 아니다 | 14장 |
| 모든 데이터에 같은 품질 수준이 필요하다 | 정산 금액과 행동 로그에 같은 기준을 적용할 이유가 없다 | 16장 |
| 처음부터 완벽히 자동화해야 한다 | 무엇이 반복되는지는 운영해 봐야 알 수 있다 | 23장 |
| 아키텍트는 모든 기술의 전문가여야 한다 | 전문가와 협력해 전체를 연결하는 능력이 더 중요하다 | 23장 |
| 이렇게 알기 쉽다 | 실제로는 | 다루는 곳 |
|---|
| 저장 기술을 바꾸면 데이터 관리가 된다 | 메타데이터, 소유권, 품질, 거버넌스가 함께 필요하다 | 2장 |
| Kafka를 쓰면 이벤트 기반 아키텍처다 | 설계·소비·스키마·중복·순서·장애 처리까지가 EDA다 | 11장 |
| DLQ를 만들었으니 실패는 처리된다 | 아무도 보지 않는 DLQ는 쓰레기통이다 | 11장 |
| Schema Registry가 있으면 안전하다 | CI에서 호환성을 검증하고 변경 정책을 함께 적용해야 한다 | 10장 |
| 카탈로그를 사면 거버넌스가 된다 | 책임자와 합의된 정의가 먼저다 | 16장 |
| 머신러닝을 쓰면 MDM이 완성된다 | 데이터 모델·품질 규칙·오너십이 먼저 마련되어야 한다 | 18장 |
| Service Mesh가 서비스 구조를 정리해 준다 | 통신의 복잡성을 다룰 뿐 잘못 그은 경계는 고쳐주지 않는다 | 4장 |
| 거버넌스는 기술 프로젝트다 | 역할·책임·프로세스가 함께 바뀌어야 하는 조직 변화다 | 16장 |
| 이렇게 알기 쉽다 | 실제로는 | 다루는 곳 |
|---|
| 도메인 구조에 정답이 있다 | 자율성과 통제 사이에서 조직에 맞는 균형을 찾는 일이다 | 21장 |
| 중앙집중이냐 탈중앙화냐를 골라야 한다 | 그 사이에 여러 형태가 있고 한 회사 안에서 섞어 쓸 수 있다 | 23장 |
| 도메인은 Peer-to-Peer로 연결해야 한다 | 공통 플랫폼이나 이벤트 플랫폼을 거쳐도 된다 | 21장 |
| 이력 관리에는 정해진 방식이 있다 | 현재 상태만 중요한지, 과거까지 필요한지에 따라 다르다 | 13장 |
| CI/CD 브랜치 전략에는 표준이 있다 | 작게 바꾸고 자주 통합하고 자동으로 검증하는 것이 핵심이다 | 23장 |
| 이렇게 알기 쉽다 | 실제로는 | 다루는 곳 |
|---|
| 아키텍처는 설계하면 끝난다 | 설계·실행·운영·피드백·개선이 계속 반복된다 | 22장 |
| 데이터 아키텍처는 완성할 수 있다 | 비즈니스와 기술이 계속 변하므로 변화에 대응하는 구조를 만드는 일이다 | 23장 |
| 메타데이터는 한 번 정리하면 된다 | 담당팀도 테이블도 정의도 바뀐다. 메타데이터 자체도 낡는다 | 15장 |
| 플랫폼 팀이 다 해 주면 된다 | 모든 요청이 몰리면 플랫폼 팀이 새 병목이 된다 | 22장 |
| 거버넌스는 중앙이 통제하는 것이다 | 여러 팀이 안전하고 일관되게 일하도록 돕는 것이 목적이다 | 22장 |
| 아키텍트는 규칙을 집행한다 | 위험을 설명하고 대안을 제시해 좋은 결정을 돕는 역할에 가깝다 | 23장 |