수동 관계 발견은 확장되지 않는다. SQL조차도 아니다.

Source: Dev.to

쌍별 비교 폭발

대부분의 팀이 명시적으로 적어두지 않는 수학부터 시작해 보겠습니다.

다음과 같은 경우:

• 100개의 테이블
• 각 테이블당 50개의 후보 필드

총 5,000개의 필드가 됩니다.

잠재적인 관계를 확인하려면 테이블을 비교하는 것이 아니라 필드를 비교하게 됩니다. 즉:

5,000 × 5,000 = 25,000,000

개의 가능한 비교가 존재합니다.

검색 공간을 적극적으로 축소하더라도 숫자는 여전히 가혹합니다. 대규모 기업은 시스템 전반에 걸쳐 수만 개의 필드를 운영하는데, 수동 탐색으로는 조합적 증가를 따라잡을 수 없습니다.

무차별 비교가 실현 불가능한 이유

가장 단순한 접근법은 명백합니다:

“필드 간 값을 비교해서 일치하는 것을 찾아보자.”

소규모에서는 작동합니다. 실제 규모에서는 붕괴됩니다.

• 전체 스캔은 비용이 많이 듭니다
• 고유 값이 폭발적으로 늘어납니다
• 네트워크와 컴퓨팅 비용이 급증합니다
• 실행 시간이 예측 불가능해집니다

많은 환경에서 전체 비교는 단순히 느린 것이 아니라 운영상 불가능합니다. 그래서 팀들은 “더 정확할지라도” 이를 조용히 피합니다.

“그냥 수동 샘플링”이라는 허위 약속

대처하기 위해 팀은 타협합니다. 샘플링을 합니다:

• 100행
• 1,000행
• “대표적이라고 생각되는 것”

그리고 겹치는 부분을 눈으로 확인합니다. 실용적으로 보이지만 새로운 문제군을 만들게 됩니다.

• 작은 샘플은 드물지만 중요한 관계를 놓칩니다
• 우연히 겹친 부분을 의미 있게 해석합니다
• 부정적인 결과는 결론을 내리기 어렵게 합니다
• 언제 신뢰도가 충분한지 아무도 모릅니다

수동 샘플링은 통계적 근거가 없고, 재현성이 없으며, 방어 가능한 종료점이 없습니다. 이는 계산 한계를 인간 편향으로 대체하는 것입니다.

SQL은 강력하지만 잘못된 추상화

SQL은 알려진 로직을 실행하는 데 뛰어납니다. 알려지지 않은 구조를 발견하도록 설계된 것은 아닙니다. 관계 발견은 다음과 같은 질문을 합니다:

• 어떤 필드가 전혀 관련이 있을 수 있을까?
• 이 관계는 어떤 종류인가?
• 신호는 얼마나 강한가?
• 이것이 포함, 동등, 혹은 우연인가?

이것들은 쿼리 문제가 아니라 추론 문제입니다. 즉석에서 SQL을 사용해 해결하려는 것은 스프레드시트로 컴파일러를 역공학하는 것과 같습니다.

관계 발견은 알고리즘적 문제

대규모에서는 관계 발견이 다음을 요구합니다:

• 원시 비교가 아닌 특징 추출
• 무차별이 아닌 지능형 가지치기
• 직관이 아닌 확률적 추론
• 일회성 분석이 아닌 재현성

이 때문에 수동 접근법이 실패하는 것이 아니라, 엔지니어가 비효율적이라서가 아니라 문제 자체가 다른 클래스에 속하기 때문입니다. 팀이 관계 발견을 알고리즘적 역량으로 다루지 않고 수동 작업으로 남겨두는 한, SQL은 디버깅 보조 도구에 머물 뿐이며, 추측은 계속될 것입니다.