1. SQL 실행 방식의 이분법, 정적 SQL과 동적 SQL의 개요
가. 정적 SQL (Static SQL)의 정의
프로그램 소스 코드 내에 SQL 문장이 직접 기술되어 있어, 컴파일 시점에 SQL 구조가 확정되는 방식입니다. Embedded SQL이라고도 불립니다.
나. 동적 SQL (Dynamic SQL)의 정의
프로그램 실행 시(Runtime) 문자열 변수에 담긴 SQL 문장을 동적으로 생성하여 실행하는 방식입니다. 조건에 따라 SQL 구문이 가변적으로 변할 수 있습니다.
2. 정적 SQL과 동적 SQL의 상세 비교
두 방식은 성능, 보안, 유연성 측면에서 뚜렷한 상충 관계(Trade-off)를 가집니다.
| 비교 항목 | 정적 SQL (Static SQL) | 동적 SQL (Dynamic SQL) |
| 구문 확정 시점 | 컴파일 시점 (Compile-time) | 실행 시점 (Runtime) |
| 파싱 메커니즘 | 소프트 파싱 위주 (실행 계획 재사용) | 하드 파싱 가능성 높음 (최적화 부하) |
| 성능 (Performance) | 빠름 (이미 최적화된 경로 사용) | 상대적으로 느림 (매번 구문 분석 필요) |
| 유연성 | 낮음 (SQL 구조 변경 시 재컴파일 필요) | 높음 (다양한 검색 조건에 대응 용이) |
| 보안성 | 높음 (SQL Injection 방어 유리) | 낮음 (문자열 결합 시 보안 취약점 존재) |
| 관리 도구 | Pre-compiler (Pro*C 등) | DBMS API (JDBC, ADO.NET 등) |
3. 기술적 핵심 요소: 파싱(Parsing)과 성능 영향
가. 하드 파싱(Hard Parsing)의 문제
동적 SQL에서 바인드 변수($?$)를 사용하지 않고 문자열을 직접 결합할 경우, SQL 문장 자체가 매번 달라져 공유 풀(Shared Pool)의 실행 계획을 재사용하지 못하고 매번 최적화 과정을 거치게 되어 CPU 부하가 급증합니다.
나. 라이브러리 캐시(Library Cache) 활용
정적 SQL은 고정된 텍스트를 가지므로 라이브러리 캐시에서 해당 SQL의 실행 계획을 찾아 즉시 실행하는 소프트 파싱 비율이 높아져 시스템 전체의 확장성(Scalability)이 향상됩니다.
4. 동적 SQL의 보안 위협과 대응: SQL Injection
동적 SQL을 사용할 때 가장 주의해야 할 사항은 사용자 입력값이 SQL 구문의 일부로 해석되어 발생하는 SQL Injection 공격입니다.
대응 방안: 문자열 단순 결합 방식 대신 반드시 **바인드 변수(Parameterized Query)**를 사용해야 합니다. 이는 보안성 확보뿐만 아니라 하드 파싱을 방지하여 성능 최적화까지 동시에 달성하는 핵심 기법입니다.
5. 기술사적 제언: 전략적 SQL 작성 가이드라인
현대적인 개발 환경(Spring-MyBatis, JPA 등)에서는 두 방식의 장점을 혼합하여 사용해야 합니다.
원칙적 정적 SQL 사용: 업무 로직이 정형화된 경우 정적 SQL을 사용하여 데이터베이스 성능을 보장하고 관리 효율을 높여야 합니다.
동적 SQL의 제한적 허용: 다중 조건 검색이나 동적 정렬 등 불가피한 경우에만 사용하되, 반드시 Prepared Statement를 통해 바인드 변수를 처리해야 합니다.
ORM 프레임워크 활용: JPA나 Hibernate와 같은 ORM은 내부적으로 최적화된 동적 SQL을 생성하며 바인드 변수를 기본 적용하므로, 이를 적극 활용하여 개발 생산성과 보안성을 동시에 확보하는 아키텍처 설계가 필요합니다.
기술사는 시스템의 트래픽 특성을 고려하여, 공유 풀 경합(Contention)을 최소화할 수 있는 **'SQL 처리 거버넌스'**를 수립해야 합니다.
댓글 없음:
댓글 쓰기