FK(외래 키)에 대한 개인적인 생각

개요

백엔드 개발자라면 RDB(관계형 데이터베이스)를 사용해보지 않은 사람은 없을 것이다.

나도 제대로 된 실무를 접한 순간부터 지금까지 만든 모든 서비스에서 RDB를 사용한다.

처음에는 아무 생각 없이 DB 툴의 도움을 받아 연관되는 경우 항상 FK(외래 키)를 설정했고,

3년이 지난 지금까지도 웬만한 경우에는 FK를 설정하는 것을 선호하는 편이다.

 

어느 정도 경력이 있는 백엔드 개발자라면 공감할 것 같은데,

FK를 설정하는 것에 대해 치를 떠는 개발자들이 정말 많다.

 

그럼에도 불구하고 나는 위에 말했듯 FK를 설정하는 걸 선호하는 편인데,

마침 스프링의 대가이신 토비 님께서 정곡을 찌르는 글을 남겨주셨다.

 

이런 좋은 글을 보고,

또한 이 글의 댓글에서의 좋은 토론을 보면서,

기존에 다른 분들과 생각을 나누면서 정리한 내 주관까지 포함하여 글을 작성하고자 마음을 먹었다.

 

FK의 장 · 단점과 반박

FK의 장점은 누가 뭐라고 해도 데이터 정합성이다.

DB에 Unique Key를 걸듯 제약조건을 통해 데이터 정합성을 보장한다.

개발을 하면서 실수로 데이터를 삭제하거나, 잘못 매핑하는 경우를 방지할 수 있다.

 

그렇다면 요즘 안쓰는 추세인 이유가 있듯 FK에는 단점도 명확하다.

아래에서 단점을 나열하고, 나의 기준으로 하나하나 반박해 본다면 아래와 같다.

 

1. 성능 저하

FK가 존재하면 인덱스 유지 비용 및 데이터 조작 시 추가 작업 등으로 인해 성능이 저하된다.

 

이 부분은 반박의 여지가 없이 사실이지만,

우리가 개발을 할 때 FK로 인한 성능을 고려할 만큼 성능이 중요한 개발을 하는 경우가 많을까?

아니면 데이터가 맞지 않는 경우에 대한 대응을 확실하게 해야 하는 개발을 하는 경우가 많을까?

 

개인적으로는 완전히 실시간으로 작업되어야 하거나 용량이 엄청 큰 부분이 아니라면

사용자의 데이터가 잘못되는 경우를 최대한 방지하는 게 좋은 방향이라고 생각하기 때문에

데이터 정합성을 지키는 방향으로 개발 습관을 들이는 게 좋지 않을까 하는 생각이 있다.

 

2. Deadlock 증가

FK를 걸게 되면 조회하는 테이블의 row 뿐만 아니라 해당 row와 연관된 테이블의 row까지도 lock이 전파된다.

따라서 lock에 대해 신경 쓸 부분이 많고, Deadlock이 증가한다.

 

백엔드 개발 시 Deadlock을 경험해 본 사람이라면 공감할 내용일 텐데,

사실 Deadlock을 완전히 없애는 건 불가능에 가깝다.

 

따라서 Deadlock이 발생했을 때를 대비하여

lock 시간 설정, 재시도 로직 등으로 대응하는 경우가 많다.

 

그래서 Deadlock이 발생하더라도 문제가 되지 않도록 설정하는 게 더 중요하다고 보고,

Deadlock을 줄이고 싶다면 Transaction과 관련 없는 부분은 최대한 분리하여

Transaction의 범위를 좁게 설정하는 코딩 습관을 들이는 것이 더 좋은 방향이라고 생각한다.

 

3. 각 DB row를 테스트하기 불편하다.

이 부분은 보통 백엔드 Application에서 테스트 코드를 작성할 때,

데이터를 초기화하거나 변경하고 테스트하려고 할 때 변경에 제약이 걸리는 경우이다.

 

이 부분은 실제로 백엔드 개발하다 보면 불편한 점이 따르기 때문에 공감하는 부분이지만,

데이터를 생성/삭제하는 부분에서 연관관계를 잘 고려하여 세팅했다면 큰 문제가 없을 것이라고도 생각한다.

 

필요하다면 DB 단에서 잠시 FK 체크를 해제하고 데이터를 조작하는 것도 가능하다.

ex) MySQL에서 SET FOREIGN_KEY_CHECKS = 0

 

마찬가지로 테스트 데이터를 세팅하는 경우에도 데이터 정합성을 보장할 수 있기도 하고.

 

내가 FK를 선호하는 이유

결국 "위와 같은 단점들이 데이터 정합성보다 중요한가?"에 대한 대답이 되는데,

토비 님 말씀처럼 가장 중요한 것은 그러한 비용 절감이 필요한 상황인지 판단하는 것이라고 생각한다.

 

대부분의 경우에는 그만큼의 비용 절감이 데이터 정합성보다 중요하진 않을 것이라고 생각하기에,

제약조건을 통한 데이터 정합성과 안정적인 서비스 운영을 위해 FK를 선호하는 편이다.

 

마무리

FK에 대한 생각, 더 나아가 모든 개인의 생각을 존중한다.

다만 모든 경우에 대해 자신의 생각만 옳다고 주장하는 것은 좋아 보이지 않는다.

모든 의견 공유에 대해 경청하는 자세를 가지도록 더 노력하자.