프로젝트 진행을 준비중인데., 함께 일하는 동료가 질문을 했다.
“레거시 시스템들은 모두 축약어로 되어 있던데., 새로 생성하는 디비 설계 시 축약어를 써야 할까요?”
“그 축약어가 사람이 인지하기 쉽던가요? 어렵던가요?”
“어렵죠. ERD 논리모델로 봐야 이해가 되는데., 이게 현행화가 안되어 있는 경우가 많아요.”
이런 대화를 나누다가 문득 궁금해졌다. Gen AI가 활발하게 사용되고 있는 2025년 왜 우리는 이런 이야기를 해야 하는가? 그래서 찾아본 내용을 글로 정리한다.
데이터베이스(DB) 설계는 모든 프로덕트의 뼈대다. 그러나 테이블명과 컬럼명을 정할 때, 축약어를 사용할지 풀네임을 사용할지 의견이 갈린다. 현재 트렌드는 무엇이고, 왜 이런 논쟁이 생겼는지 살펴보자.
축약어의 기원과 이유
과거에는 시스템 자원의 한계와 데이터베이스 성능 최적화가 중요한 이슈였던 시절이 있었다. 특히 초기 컴퓨터 환경에서는 저장 공간이 부족했고, 네트워크 속도나 처리 능력이 제한적이었기 때문에, 테이블이나 컬럼 이름을 짧게 줄여서 사용하는 것을 선호했다.
예를 들어, cust(customer), addr(address), emp(employee)와 같은 축약어가 널리 사용되었다. 이렇게 축약어를 사용함으로써 데이터베이스의 공간을 절약하고 코드의 길이를 줄일 수 있었던 것이다.
하지만 이 방식에는 문제가 있었다. 축약어가 지나치게 많거나 모호하게 사용되면, 새로 투입되는 사람은 이를 이해하기 어려워지는 문제가 있다. 또한, 데이터베이스의 구조가 점점 복잡해지고 많은 데이터가 관리되는 상황에서 직관적인 이름이 더욱 중요한 요소로 떠오르게 되었다.
즉, 축약어는 효율성을 상징했지만, 가독성을 희생시켰다.
현재 트렌드
현재는 데이터베이스 테이블과 컬럼 이름을 지을 때, 명확하고 직관적인 이름이 중요시되고 있다. 이는 소프트웨어 개발의 전반적인 변화와 관련이 있다. 코드가 길어지고 복잡해지는 만큼, 개발자들은 가독성 높은 코드 작성을 추구한다. 데이터베이스 설계도 마찬가지로 직관적인 이름을 통해 사람들이 편의를 고려하는 방향으로 바뀌고 있다.
예를 들어, cust_name, usr_addr 처럼 축약어를 사용하기 보다는, customer_name과 user_address 처럼 풀네임을 사용하는 것이 일반적이다. 이렇게 하면 컬럼이나 테이블을 이해하는데 더 직관적으로 파악할 수 있어 유지보수와 디버깅이 훨씬 수월하다.
이렇게 바뀐 이유는 아래와 같다.
가독성 우선: 현대 개발은 협업과 유지보수가 핵심이라, 사람이 쉽게 이해하는 이름이 선호된다. 더군다나 Gen AI의 시대에서 말이다.
기술 진화: PostgreSQL은 63자, 오라클은 30자까지 식별자를 지원하며, 성능 차이는 미미하다. 축약의 필요성이 줄었다.
문서화 감소: 풀네임은 자체 설명적이기에 별도 명세서 없이도 이해가 가능하다.
클린 코드 철학의 확산: “클린 코드” 철학은 코딩 시 직관적이고 읽기 쉬운 코드를 작성하는데 초점을 맞추고 있다. DB 설계도 예외는 아니다.
협업 및 확장성: 프로덕트가 점점 커짐에 따라 다른 사람이 이해하기 쉬운 이름이 더욱 중요해졌다. 축약어가 많으면 혼란을 초래할 수 있다.
그러나 레거시 시스템이 많은 곳은 아직도 축약어의 잔재가 남아있다. 혹은 도메인별 관습이 강한 경우에도 축약어가 남아 있는 경우가 있다.
결론
데이터베이스 설계에서 이름 짓기는 단순히 개인적인 취향의 문제가 아니다. 시간과 기술의 발전에 따라 더 이상 축약어만을 고집하기보다는 직관적이고 명확한 이름을 사용하는 것이 더욱 중요해졌다.
물론, 간단한 약어는 여전히 유용할 수 있지만, 그 사용은 줄어들고 대신 풀네임을 사용하여 가독성과 유지 보수성을 높이는 것이 꽤 오래전부터 트렌드로 자리잡고 있다.
끝으로,
이 글을 읽는 분들은 https://vertabelo.com/blog/database-naming-convention/ 링크를 참고해서 최악을 피했으면 좋겠다.
