Foreign Key를 안 써야 하는 이유가 뭘까요?

제가 이전에 DB 테이블 칼럼에 NULL 허용을 굳이 하는 이유를 알고 싶다는 글을 썼었습니다.

많은 분들이 분노하고 경험상 온도를 나타내는 칼럼엔 NULL을 허용해야 했다는 분의 글을 보고 그 경우엔 필요하겠다고 답변 달았던 기억이 있습니다.

그 수많은 분노의 글을 보며 제가 느낀 건, 이 분들은 그 답변으로 NULL 자체에 대한 신념을 지켜냈다고 생각하는구나 였습니다. 제가 보기엔 그냥 NULL이 기본값이라 대부분의 사람들이 NULL 허용을 해왔고, 그게 버릇처럼 굳어진 건데 말이죠. 만약 NOT NULL이 기본값이라면 굳이 NULL 허용을 하려고 안했을 거라고 봅니다.

그런데 아마도 그 답변으로 역시 NULL은 필요해라고 생각했겠죠. 그리고 평소처럼 PK나 인덱스가 아닌 모든 칼럼, 특히 추가되는 칼럼은 NULL 허용을 무조건 하는 방식대로 개발할 거라 생각됩니다.

방금 어느 분이 질문한 Foreign Key 써야 하느냐는 질문도 큰 데선 안 쓴다, 경우에 따라 다르다는 답변들 봤습니다. 대부분 정합성이 지켜지기 때문에 굳이 안 쓴다고 하시는데 정합성이 잘 지켜진다면 굳이 안 쓸 이유가 없다고 봅니다. Foreign Key 만들면 메인 테이블과 참조 테이블 사이에서 데이터 추가, 삭제 순서를 지켜야 하고, 특히 DB를 이관할 때 불편한 점이 있는 건 맞습니다.

그런데 그건 특수한 몇 시간의 상황이고 온라인에서 365일 CRUD를 하면서 테이블 간의 정합성을 지키는 게 우선입니다. 부수적인 불편함 때문에 실제 현실에서의 데이터가 어긋날 가능성을 허용하는 건 상식에 어긋난다고 봅니다.

제가 지키는 원칙은 간단합니다. 경우의 수를 줄여야 한다는 겁니다. 경우의 수가 늘어나면 그만큼 비용도 늘어납니다.

만약 DATE 칼럼을 20260426과 같은 문자열 형식으로 한다면 그 칼럼엔 20260229와 같은 잘못된 데이터가 들어갈 가능성은 존재하고, 데이터가 많을 수록, 시간이 오래될 수록 그 확률은 100%에 가까워집니다.

그렇지만 여전히 많은 사람들이 날짜 칼럼을 8자리 문자열로 해야 한다고 합니다. 사실 그건 코볼 시대 때부터 내려오던 미신이라고 봅니다. 오라클 처음 나왔을 때도 당시엔 날짜 관련 함수가 다양하지 않아서 일리가 있긴 했습니다. 그렇지만 요즘의 DB는 날짜 관련 함수가 대부분 완벽하기 때문에 정합성은 물론이고, 월이 바뀌거나 윤년에서도 계산이 안 막힙니다.

많은 분들의 신념이 그냥 예전부터 선배들이 그렇게 하던 거라 익숙하기 때문에 하는 것들이라고 봅니다.

테이블 만들 때 추가로 temp1, temp2, temp3 이렇게 만드는 것도 봤습니다. 물어보면 나중에 필요할 수 있어서 그렇다고 합니다. 필요할 때 적절한 이름의 필요한 데이터 형식으로 추가하면 된다고 하면, 그래도 혹시 모른다고 합니다. 저는 그것도 코볼로 프로그래밍할 때 칼럼을 추가하기 어려웠을 때의 그 풍습이 내려온 거라 봅니다.

TypeScript가 나온 이유도 데이터 형식을 선언함으로써 잘못된 데이터가 들어올 경우의 수를 줄이기 위한 겁니다. JavaScript도 ===을 도입해서 숫자와 문자열의 비교를 막은 것 역시 경우의 수를 줄입니다. Python도 Pydantic, Pylint 같은 기술이나 규칙이 나온 이유 또한 TypeScript처럼 경우의 수를 줄이려는 노력입니다. 최근의 많은 새로운 언어나 DB들이 Not Null을 기본값으로 하고 있는 이유는 Null이라는 경우의 수를 줄이기 위한 노력입니다.

저는 솔루션 업체가 솔루션 만들고 여러 곳에 팔면서 기능별로 개발자를 할당하지 않고, 거래처별로 개발자를 할당하는 게 정말 위험하다고 생각합니다.

예를 들어 A 개발자가 결제 기능을 담당한다면 거래처가 1개에서 10개로 불어나도 한명이 처리 가능합니다. 거래처별로 달라지는 부분만 옵션으로 처리할 수 있기 때문입니다.

그런데 거래처별로 개발자를 할당하면 거래처가 생길 때마다 개발자를 할당해야 합니다. 처음엔 쉽겠지만 솔루션이 여러 버전으로 나눠지면서 경우의 수가 엄청나게 많아집니다. 버그가 생기거나 기능을 추가할 때 모든 거래처에 할당된 각 개발자가 각자의 방법으로 해결해야 합니다.

그 단계에선 더 이상 솔루션이 아니게 되고 회사는 그냥 인력 파견만으로 겨우겨우 먹고 사는 단계에서 더 올라가지 못합니다. 사실 대기업에선 소스를 반출하는 게 어렵고 원격 근무도 허용 안하니 유지보수 인원을 파견해야 하고, 중소기업이라도 거래처마다 요구조건이 워낙 달라 원 소스를 유지하는 게 어려운 게 현실이긴 합니다. 그렇지만 무엇보다 경우의 수가 늘어났을 경우의 위험을 너무 간과하는 것이 근본 원인이라 생각합니다.

그럼 처음으로 돌아가 묻겠습니다. 굳이 Foreign Key를 안 써야 하는 합리적인 이유는 뭘까요?