작성한 질문수 1

1

안녕하세요. 오승환님

모든 곳에서 다 FK를 빼고 사용하는 것은 아니고, 다음과 같은 이유로 FK를 빼는 경우들이 있습니다.

1. 운영이 불편함

배치, 데이터 이관, 테스트 셋업할 때 INSERT/DELETE 순서 맞춰야 하고, 조금만 꼬이면 제약 위반으로 실패합니다. FK 끄고 작업하는 일이 많아집니다.

2. 스키마 변경이 무거워짐

부모 테이블 구조 바꾸려면 자식 FK 드롭 → 작업 → 재생성하는 과정이 필요합니다.

3. 확장성 — DB 분리 대비

MSA로 쪼개면 DB 레벨 FK는 못 씁니다. 어차피 애플리케이션이 정합성을 책임져야 하니, 처음부터 그 구조로 갑니다.

하지만 트레이드오프를 고려해야 합니다.

FK를 빼면 운영 유연성과 확장성을 얻고, 대신 정합성 책임이 애플리케이션으로 넘어옵니다. 모든 검증 로직을 명확하게 애플리케이션 로직에서 책임져야 하는데, 시간이 지날수록 보통 잘 오염되고, 이상한 중복 데이터나, 자식이 반드시 필요한데 없는 경우가 발생합니다. 이 문제 때문에 또 방어 코드를 추가해야 하는 경우들도 생깁니다.

제가 추천하는 방법은 '기본적으로는 FK를 사용해 데이터 무결성을 보호하되, 시스템의 규모와 도메인 특성에 맞춰 유연하게 제거하는 것'입니다.

실무적인 관점에서 다음과 같이 접근해 보시길 권장합니다.

• 정합성이 최우선인 코어 도메인 (결제, 정산 등): 데이터가 틀어질 때의 비즈니스 리스크가 매우 크므로 DB 레벨의 FK 제약조건을 굳건히 걸어두고 2중, 3중으로 보호하는 것이 좋습니다.

• 대규모 트래픽 및 유연성이 필요한 도메인: 잦은 스키마 변경과 성능 최적화가 중요하거나, 향후 MSA 분리가 예상되는 서비스라면 FK를 물리적으로 제거하여 운영의 유연성을 확보합니다.

• 논리적 관계 유지 및 보정 배치: DB에서 물리적인 제약조건CONSTRAINT)은 제거하더라도, ERD 상의 논리적 연관관계는 명확히 남겨두어야 합니다. JPA 같은 ORM을 사용한다면 애플리케이션 레벨에서 연관관계를 철저히 매핑하여 검증하고, 주기적으로 백그라운드 배치(Batch)를 돌려 고아 데이터나 정합성이 깨진 데이터를 모니터링하고 정리하는 안전장치를 함께 마련하는 것이 좋습니다.

결국 서비스 규모가 커지고 아키텍처가 복잡해질수록 무결성 유지의 책임은 DB에서 애플리케이션으로 넘어오게 됩니다. 현재 프로젝트의 단계, 트래픽 규모, 그리고 팀의 방어 코드 작성 역량을 종합적으로 고려하여 적절한 트레이드오프를 선택하시길 바랍니다.

감사합니다.

0

안녕하세요, 인프런 AI 인턴입니다. 오승환님.

실제 실무에서 외래키(FK) 제약조건을 설정하지 않는 이유에 대해 궁금해 하시는군요. 외래키 제약조건 없이 설계를 하는 이유는 주로 성능과 설계의 유연성 때문입니다. 다음 링크들을 통해 관련 설명을 확인하실 수 있습니다:

1. 외래키를 사용에 대해서

   • 이 게시물에서는 외래키가 없어도 JPA가 동작할 수 있으며, 외래키를 사용하지 않음으로써 데이터베이스 간의 관계를 더 유연하게 관리할 수 있음을 설명합니다.
     

2. 서비스에서 외래 키 사용에 대해 질문 드립니다

   • 실무에서 왜 외래키를 사용하지 않는지에 대한 논의가 이루어지며, 외래키 없이도 필드 수준에서 관계를 유지하는 방법 및 이점에 대해 설명합니다.
     

데이터베이스에서 외래키 제약조건을 사용하지 않으면, 데이터 무결성을 보장하기 위해 프로그래밍 측면에서의 추가적인 관리가 필요한 반면, 성능상의 이점과 설계적 유연성을 확보할 수 있다는 장점도 있습니다. 외래키 없이도 연관 관계를 유지할 경우, 업데이트나 삭제 시 다른 테이블에 영향을 미치지 않기 때문에 설계가 유연해질 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.