바이브 코딩 설계 완전 정리

설계 영역에서 모델의 편향은 유난히 뚜렷합니다. 마이크로서비스 분리 방법을 물으면 분리 방법을 알려주고, CQRS 적용을 물으면 적용 방법을 알려줍니다. '지금 규모에서는 하지 않는 편이 낫다'는 답이 먼저 나오는 일은 드뭅니다. 학습된 글 대부분이 그 패턴을 실제로 도입한 조직의 기록이고, 도입하지 않기로 한 결정은 애초에 글로 남지 않기 때문입니다. 그래서 질문을 도입 방법이 아니라 도입하지 말아야 할 조건 쪽으로 던지는 습관이 설계에서는 특히 값을 합니다.

여러 구현 방법 비교 요청이 이 묶음의 기본기입니다. 하나만 물으면 하나만 받는데, 그 하나가 최선이라는 근거는 어디에도 없습니다. 아키텍처 검토에 AI를 활용하라는 이미 그려둔 그림을 놓고 단일 장애점과 확장 병목을 캐묻는 반대 방향의 사용법이고, 데이터베이스 스키마 설계 검토는 그중 실익이 가장 큰 지점입니다. 운영에 올라간 뒤 스키마를 되돌리는 비용을 생각하면 그렇습니다. CQRS 패턴 적용을 AI와 검토하라는 이 셋을 익힌 뒤에 봐야 판단이 섭니다.

캐싱이 대표적인 함정입니다. 조회가 느리다고 하면 캐시 계층과 TTL 설정을 매끄럽게 제안하지만, 무엇을 언제 무효화할지는 도메인 규칙이라 모델이 알 도리가 없습니다. 결제 상태나 권한처럼 몇 초의 스테일 읽기가 곧바로 사고가 되는 데이터에도 같은 제안이 그대로 붙습니다. 캐시는 히트율을 목표로 붙이는 물건이 아니라, 틀린 값을 몇 초까지 견딜 수 있는가를 데이터 종류별로 먼저 답한 다음에 붙이는 물건입니다.