💡 핵심 인사이트
파서(Parser)는 사용자가 날린 SQL 문장을 데이터베이스가 이해하기 전에 가장 먼저 맞이하여, 문법에 오류가 없는지 검사하고 쪼개는 '검문소' 역할을 합니다.
텍스트 형태의 SQL을 기계가 다루기 쉬운 자료구조인 **'파스 트리(Parse Tree)'**로 변환하여 옵티마이저에게 넘겨주는 것이 주 임무입니다.

Ⅰ. SQL 처리 과정에서의 파서의 위치

사용자가 DB 클라이언트를 통해 SELECT * FROM EMp; 라는 텍스트를 전송하면, DBMS 내부에서는 다음과 같은 순서로 처리가 일어납니다.

  1. 파서 (Parser): 문법 검사 및 파스 트리 생성 (여기!)
  2. 옵티마이저 (Optimizer): 파스 트리를 받아 최적의 실행 경로(실행 계획) 탐색
  3. 실행기 (Executor): 스토리지 엔진에 데이터를 가져오라고 실제 명령 수행

Ⅱ. 파서(Parser)의 3단계 검증 과정

파서는 들어온 SQL 문장을 잘게 쪼개어(Tokenize) 꼼꼼하게 검사합니다.

1. 구문 분석 (Syntax Check)

  • 오타 및 문법 검사입니다. SQL 키워드 철자가 맞는지, 순서가 올바른지 확인합니다.
  • 예시: SELCT * FORM EMP; ➔ SELCT라는 키워드가 없고 FROM이 FORM으로 오타가 났음을 0.1초 만에 잡아내어 Syntax Error를 뱉어냅니다.

2. 의미 분석 (Semantic Check)

  • 문법은 맞지만, 실제로 그 데이터가 존재하는지 논리적으로 검증합니다.
  • 이때 파서는 메모리에 있는 **데이터 딕셔너리 캐시(메타데이터)**를 뒤져서 확인합니다.
  • 검사 내용:
    • EMP라는 테이블이 이 DB에 진짜로 존재하는가?
    • * (모든 컬럼)에 권한이 있는가? 사용자가 이 테이블을 조회할 권한(Grant)이 있는가?
  • 예시: 문법은 완벽하지만, 회사 DB에 EMPLOYEE 테이블은 있어도 EMP 테이블이 없다면 "Table or view does not exist" 에러를 냅니다.

3. 공유 풀(Shared Pool) 검사 - 소프트 파싱 vs 하드 파싱

파서는 완벽히 검증된 SQL 문장을 해시 함수로 돌려 고유한 ID를 만듭니다. 그리고 메모리의 '라이브러리 캐시(Library Cache)' 영역을 훑어봅니다.

  • 소프트 파싱 (Soft Parsing): 누군가 과거에 나와 토씨 하나 안 틀리고 똑같은 SQL을 날린 적이 있어서, 그 결과물(파스 트리와 실행 계획)이 캐시에 남아있다면? 옵티마이저를 거칠 필요 없이 캐시에서 실행 계획을 바로 훔쳐와서 즉시 실행합니다. (극도로 빠름)
  • 하드 파싱 (Hard Parsing): 처음 보는 낯선 SQL이라면, 뼈대인 **파스 트리(Parse Tree)**를 새로 생성하여 옵티마이저에게 넘겨줍니다. 옵티마이저는 수만 가지 경우의 수를 계산하느라 CPU를 엄청나게 소모하게 됩니다.

Ⅲ. 실무적 의의: 바인드 변수의 중요성

SELECT * FROM EMP WHERE ID = '1' 과 SELECT * FROM EMP WHERE ID = '2' 사람이 보기엔 같은 쿼리지만, 파서는 글자가 다르므로 이를 전혀 다른 쿼리로 인식하여 무거운 하드 파싱을 두 번 수행합니다.

이런 참사를 막기 위해 실무 개발에서는 SELECT * FROM EMP WHERE ID = ? 형태의 **바인드 변수(Bind Variable, Prepared Statement)**를 사용합니다. 파서는 뼈대가 같으므로 한 번만 하드 파싱을 하고, 이후에는 ?에 값만 바꿔 넣으며 초고속 소프트 파싱으로 넘깁니다.

📢 섹션 요약 비유: 파서는 공항의 출입국 심사대입니다. 여권의 영문 철자가 맞는지(구문 분석), 지명수배자 명단에 있는지(의미 분석)를 철저히 검사합니다. 그리고 통과된 사람이 과거에 온 적 있는 단골(소프트 파싱)이면 프리패스 문으로 바로 통과시키고, 처음 온 사람(하드 파싱)이면 지문 등록부터 보안 검색(옵티마이저)까지 복잡한 절차를 밟게 넘깁니다.