안녕하세요 제우님 질문 남겨주셔서 감사합니다. 하나하나 나눠서 설명드려보도록 할게요.

1. 근본적인 아키텍처에 어떤 문제점이 생기는지, 잘 모르겠습니다.

이거는 비지니스 요구사항에 따라 스키마 변경이 야기하는 다양한 문제입니다. 즉 테이블 구조 변경이 요구사항을 모두 처리하지 못하는 상황이 예시가 될 꺼 같아요.

예를 들어 is_vip, is_blocked, is_verified, is_dormant ... 이런 식으로 컬럼이 계속 추가되면 테이블이 비즈니스 로직의 변화에 종속되고, 나중에 "이 컬럼이 왜 있지?"를 추적하기 어려워집니다. 즉 확장성과 유지보수성 에 집중한 문제로 이해하시면 됩니다.

2. ALTER로 스키마를 변경하는 것으로 문제가 야기되는 부분이 정확히 어떤 부분이라고 생각하시는지 궁금합니다. 이미 많은 레코드가 있는 테이블의 스키마를 변경함으로써 생겨나는 I/O 부하를 생각하시는 걸까요?

맞게 이해하신겁니다. Lock을 유발하는게 문제인거에요. MySQL InnoDB 기준으로 컬럼 추가 시 Online DDL이 지원되긴 하지만, 상황에 따라 테이블 전체를 리빌드 할 수 있죠. 그러면 수천만 건 테이블이면 이 작업 자체가 수십 분이고, 그 동안 쓰기가 블로킹되거나 서비스에 영향을 주는 부분을 피해갈 수가 없어요. 이게 Boolean 컬럼이 추가될 때마다 이 비용이 반복되면 문제가 되겠죠.

3. I/O 비용의 증가가 발생한다는 부분은 2번에서의 비용 증가를 말씀해주신 걸까요? SELECT 비용 증가라면 사실 저장해야 하는 정보가 늘어나면서 자연스러운게 아닌가 싶은데 어떤 관점에서의 문제를 짚어주신 건지 궁금합니다.

뭐 부하는 어떻게든 발생 가능한 구조로 이해하시면 됩니다. SELECT 부분에 대해서도 페이지 단위로 인한 부하가 있을 수 있고, 저장하는 정보가 많아지니깐 사실상 매우 자연스러운 행동이죠 다만 Boolean 컬럼의 특성상 대부분 NULL 또는 false인 경우가 많아서 실제로 의미 있는 데이터 밀도가 낮은데 row 크기만 커지는 비효율이 생길 수 있다는 부분도 같이 얻어가보시면 좋지 안흥ㄹ까 싶어요.

4. 논리 모델 vs 물리 모델, 그리고 세 가지 기법

네 이해하신 방향이 틀리지 않습니다. 다시 정리해보죠.

논리 모델은 "어떤 데이터를 저장할 것인가"이고, 물리 모델은 "실제 DB에 어떻게 저장할 것인가"로 생각을 하시면 됩니다. 이 상황에서 Boolean 속성이 많아지는 문제를 논리 모델 레벨에서 "이 엔티티는 여러 속성을 가진다"로 정의 할 수 있고, 물리 모델 레벨에서 그걸 어떻게 테이블로 구현할지를 선택하는 단계를 거치는 거죠.

이 떄 구현 방법은 3가지가 있을겁니다.

• One Table per Anchor: 기본 테이블 하나에 핵심 속성만 두는 방식

• Side Table: Boolean이나 부가 속성을 별도 테이블로 분리 (ex. user_flags 테이블)

• EAV (Entity-Attribute-Value): user_id | attribute_name | value 형태로 속성 자체를 행으로 저장

그래서 제가 말씀드리고 싶은 부분은 무작정 Boolean을 추가하는건 논리 모델을 그대로 물리 모델로 박아버리는 행위라고 말씀드리고 싶었어요. 뭐 상황에 따라서 나쁜 선택은 아닐 수 있다고는 생각합니다. 하지만 과연 이 방식이 가장 좋은 방식인가?? 이건 제가 판단하기에는 어려운 부분일꺼 같네요.

질문에 답이 좀 되셨을까요?? 혹시 추가적인 질문이 있다면 남겨주세요!! 좋은 하루보내세요~~