IF NOT EXISTS 구문 사용시 주의점
-
핵심 질문 "애플리케이션이 시작될 때 IF NOT EXISTS 구문을 사용하여 자동으로 테이블을 생성하도록 설정하는 것이 좋은 아이디어인가요?"
-
결론: "프로덕션 환경에서는 나쁜 아이디어" 작성자는 이 방식이 간단한 사이드 프로젝트나 개인용 스크립트에서는 괜찮을 수 있지만, 실제 서비스(Production) 환경에서는 위험하다고 경고합니다.
-
왜 위험한가? (보안 문제) 과도한 권한 부여: 앱이 시작될 때 테이블을 생성하려면 해당 데이터베이스 사용자는 DDL(데이터 정의 언어) 권한(Create, Drop 등)을 가져야 합니다.
SQL 인젝션 위협: 만약 웹 애플리케이션에 SQL 인젝션 취약점이 있다면, 공격자는 앱의 권한을 이용해 DROP TABLE 같은 명령을 실행하여 데이터를 완전히 삭제할 수 있습니다.
소유권 문제: 앱을 구동하는 사용자가 테이블을 직접 생성하면 그 사용자가 '소유자'가 되어 모든 통제권을 갖게 됩니다.
- 권장되는 해결책 (Best Practices) 작성자는 보안을 위해 역할 분리를 강조합니다.
관리자용 스크립트 분리: 테이블 생성 및 스키마 변경은 애플리케이션 코드와 분리된 별도의 관리용 스크립트(또는 마이그레이션 도구)를 통해 수행하십시오.
최소 권한의 원칙 (Principle of Least Privilege):
App Owner: 스키마를 생성하고 테이블을 소유하는 사용자.
App User: 실제 웹 앱이 사용하는 계정. SELECT, INSERT, UPDATE 등 꼭 필요한 DML(데이터 조작 언어) 권한만 부여하고 DROP 권한은 제외합니다.
세분화된 연결 풀(Connection Pool): 읽기 전용 라우트에는 읽기 권한만 있는 계정을, 수정 라우트에는 업데이트 권한만 있는 계정을 사용하는 식으로 더 엄격하게 관리할 것을 권장합니다.
- 예외 상황 사용자가 전혀 없는 로컬 스크립트나 자동화 도구의 경우, 멱등성(여러 번 실행해도 결과가 같은 성질)을 유지하며 IF NOT EXISTS를 사용하는 방식이 유용할 수 있습니다.
요약하자면: "편의성을 위해 앱 코드 내에서 테이블을 자동 생성하지 마세요. 보안을 위해 DB 관리 계정과 앱 실행 계정을 분리하고, 앱 계정에는 최소한의 권한만 부여하는 것이 정석입니다."