DB 테이블 이름 짓기 — 담긴 것이 아니라 담을 것으로

테이블 이름이 맞는지 확인하려면 안에 뭐가 들어 있는지 열어 보면 된다. 그게 제일 빠르고, 근거도 숫자로 나온다. 그런데 그 방법으로 나온 답이 틀릴 수 있다.

2026-08-13 새벽. 데이터베이스 이름을 종일 정리하고 마지막 하나가 남았다. fair_directory 라는 표. 국내외 행사 일정을 모아 둔 카탈로그다. 이름을 바꿀지 클로드에게 물었다.

정확하게 재고, 틀린 답이 왔다

클로드는 재 보고 답했다. 35줄을 다 열었다.

Art Basel · Frieze · KIAF · 화랑미술제 · Art Jakarta · TEFAF …

전부 아트페어였다. 다른 종류는 한 건도 없었다. 그래서 점수가 붙어 나왔다.

• art_fair_directory — 80점. 담긴 것과 이름이 정확히 맞는다
• exhibition_directory — 45점. 담지도 않는 걸 담는 것처럼 읽힌다
• 그대로 두기 — 60점

두 번째를 낮게 준 근거까지 적혀 있었다. 그날 하루 종일 고친 게 **「이름이 실제보다 넓게 말하는 것」**이었으니, 같은 실수를 반대 방향으로 반복할 순 없다는 것. 논리에 구멍이 없었다.

나는 한 줄로 답했다.

"fair_directory 에 앞으로는 전시도 들어갈 수 있어."

재는 방식이 아니라 재는 대상이 틀렸다

추천이 틀린 게 아니다. 35줄을 다 열었고, 근거를 숫자로 댔고, 반대 실수까지 경계했다. 재는 방식은 맞았다.

틀린 건 무엇을 쟀느냐다. 클로드는 테이블에 지금 들어 있는 것을 셌다. 이름이 가리켜야 할 것은 앞으로 들어올 것이었다. 그리고 그건 데이터베이스를 아무리 뒤져도 안 나온다. 서비스를 어디로 끌고 갈지 정하는 사람 머릿속에만 있다.

갈린 지점은 이름이 기록인가 약속인가다.

담긴 것에 맞추면 이름은 기록이 된다. 지금은 정확한데, 내용이 늘 때마다 다시 틀린다. 담을 것에 맞추면 이름은 약속이 된다. 오늘은 조금 넓지만 다음 달에도 안 틀린다. 표는 늘어나지 줄어들지 않으니, 약속 쪽이 오래 산다.

바꾼 것

하나 — 그 자리에서 exhibition_directory 로 갔다. 45점을 받은 쪽이다. 점수가 틀린 게 아니라 점수를 매긴 전제가 바뀌었다.

둘 — 이름을 정할 때 물어볼 질문을 바꿨다. 「지금 뭐가 들어 있나」가 아니라 **「여기 안 들어올 게 뭔가」**로. 앞의 질문은 조회로 답이 나오고, 뒤의 질문은 사람에게 물어야 답이 나온다. 조회로 답이 나온다는 게 함정이었다 — 답이 나오니까 물어볼 생각을 안 하게 된다.

셋 — 추천에 「무엇을 근거로 쟀는지」를 같이 적게 했다. "80점" 만 적혀 있으면 뒤집을 자리를 못 찾는다. "담긴 35건이 전부 아트페어라서 80점" 이라고 적혀 있으면, 그 전제가 틀렸다는 걸 아는 쪽이 한 줄로 뒤집을 수 있다. 이번엔 그렇게 뒤집혔다.