Sql 처리기 - Sql Processor 프로젝트 (구현 설명 중점)

https://github.com/IMGyuGo/sqlProcessor

GitHub - IMGyuGo/sqlProcessor: sqlProcessor (Sql 처리기) - 팀원 : [김규민, 김세민, 김규태, 남동현]

위 주소는 C 기반 미니 SQL 처리기와 이를 시각화한 웹 데모 버전입니다.

C엔진이 INSERT, SELECT, 단순 WHERE AND/OR 까지 처리하고 이를 React가 CLI / Parse Tree / Service 3패널로 직관적으로 보이게 한 프로젝트입니다.

 

SQL 처리기란?

SQL 문자열을 받아서 -> Parsing -> Execute -> 결과 반환 하는 시스템

[ 입력 SQL ]
↓
[ Parser ]
↓
[ Executor ]
↓
[ Storage ]
↓
[ Return Result ]

 

참고 :
상용 DBMS는 Optimizer, Transaction같은 더 많은 계층으로 이루어지지만, 이번 프로젝트는 Parser, Executor, Storage 중심으로 구현하였습니다.

 

Why?

"SQL은 자주 쓰이지만, 내부 동작은 블랙 박스처럼 사용자가 알 필요가 없습니다. 하지만 직접 구현해봄으로써 실제 로우레벨단에서의 SQL 처리가 어떻게 이루어지는지 확인도 가능했고, CS 기초에 대한 이해의 폭을 더 넓힐 수 있는 좋은 경험이라고 생각했습니다."

 

프로젝트 목표와 범위

INSERT/SELECT, 단일 profiles 테이블안의 정해진 컬럼들(스키마), CSV 저장소(Table Storage)로 실제 처리기가 어떻게 잘리고 어떻게 작동이 되는지 내부 로직을 직관적으로 시각화하고 서비스화 시켜보기

 

아키텍처

브라우저 -> 백엔드 Bridge -> C 엔진 -> 백엔드 Response -> UI 갱신

┌─────────────────────────────────────────────────────────────────┐
│                         Browser (React)                         │
│  ┌─────────────────┬──────────────────┬──────────────────────┐  │
│  │   CLI Panel      │   Parse Tree     │   Date Match App    │  │
│  │   xterm.js       │   ReactFlow      │   Profile Matcher   │  │
│  │   터미널 입력    │  SQL 구조 시각화 │     매칭 서비스      │  │
│  └────────┬─────────┴────────┬─────────┴──────────┬──────────┘  │
│           │ WebSocket        │                    │ HTTP POST   │
└───────────┼──────────────────┼────────────────────┼────────────┘
            │                  │                    │
            v                  v                    v
┌─────────────────────────────────────────────────────────────────┐
│                    Backend (Node.js:3001)                       │
│                                                                 │
│   /ws/terminal ──── PTY Shell ──── C Engine (REPL mode)         │
│   /api/query  ──── Spawn Process ── C Engine (File mode)        │
│                         │                                       │
│              responseProtocol.js                                │
│              C 출력 → JSON 변환                                 │
└─────────────────────────┬───────────────────────────────────────┘
                          │
                          v
┌─────────────────────────────────────────────────────────────────┐
│                     C SQL Engine                                │
│                                                                 │
│   main.c ─→ parser.c ─→ executor.c ─→ storage.c                 │
│    입구       SQL 분석     실행          CSV 읽기/쓰기           │
│                                            │                    │
│                                            v                    │
│                                   data/profiles.csv             │
└─────────────────────────────────────────────────────────────────┘

 

핵심 구현

이 프로젝트의 핵심 구현은 SQL 문장을 화면에서 입력받는 데서 끝나지 않고, 실제로 실행된 결과가 다시 웹 UI에 반영되는 전체 파이프라인을 구성한 데 있다. 즉, 웹은 단순히 결과를 흉내 내는 역할이 아니라, C 기반 SQL 엔진과 연결된 실행 흐름을 시각화하는 역할을 맡는다.

1. C 기반 SQL 파서와 실행기 구현

먼저 엔진에서는 SQL 문장을 해석하는 파서와, 해석된 결과를 실제로 수행하는 실행기를 분리해 구현했다. Parser는 INSERT와 SELECT 문장을 구분하고, 테이블 이름, 값 목록, 선택 컬럼, WHERE 조건을 읽어 내부 Statement 구조체로 정규화한다. 이 과정에서 문법 오류나 지원하지 않는 문장은 초기에 걸러지도록 설계했다.

이후 실행기는 Parser가 만든 구조를 바탕으로 스키마를 조회하고, 값 개수나 컬럼 이름 유효성 검증 후, 저장소 계층에 실행을 위임한다. 이렇게 파싱과 실행을 분리함으로써 문법 해석과 데이터 처리의 책임을 나누었고, 이후 기능 확장 시에도 구조적으로 대응할 수 있도록 했다.

2. CSV를 활용한 파일 기반 저장소 설계

저장소는 CSV 파일을 사용하도록 구성했다. 현재 프로젝트는 profiles(name, mbti, hobby) 스키마를 기준으로 동작하며, 엔진은 테이블 파일이 없을시 자동 생성, INSERT 시에는 한 줄씩 데이터를 추가하고, SELECT 시에는 파일을 순차적으로 읽어 조건에 맞는 행만 결과 집합으로 반환한다.

물론 이는 상용 데이터베이스처럼 인덱스나 최적화 기능을 제공하는 구조는 아니다. 그러나 SQL 처리기의 핵심 책임인 스키마 검증, 데이터 저장, 조건 필터링, 결과 반환의 흐름을 직접 구현했다고 생각한다.

3. Node.js 백엔드를 통한 엔진 브리지 구성

웹 애플리케이션과 C 엔진을 연결하기 위해 백엔드에는 브리지 계층을 두었다. 사용자가 입력한 SQL은 백엔드에서 임시 SQL 파일로 저장되고, 이후 컴파일된 C 엔진 바이너리를 실행하는 방식으로 처리된다. 엔진이 출력한 stdout과 stderr는 다시 백엔드에서 수집되며, 이를 프런트엔드가 사용할 수 있는 JSON 형태로 변환한다.

이 과정에서 success, queryType, message, rows, parseTree 같은 응답 구조를 명확히 정의했다. 특히 텍스트 기반 엔진 출력을 웹 친화적인 JSON 방식으로 변환해 구조화된 응답 프로토콜로 변환한 점은, 시스템 통합 측면에서 이 프로젝트의 중요한 구현 포인트라고 볼 수 있다.

4. 하나의 쿼리가 세 개의 패널을 동시에 갱신하도록 통합

브라우저에서는 하나의 SQL 실행 결과가 CLI 패널, Parse Tree 패널, Service 패널에 동시에 반영되도록 상태를 통합했다. 사용자가 쿼리를 실행하면, CLI 패널은 실행 흐름을 보여주고, Parse Tree 패널은 현재 쿼리의 구조를 시각화하며, Service 패널은 같은 결과 데이터를 바탕으로 실제 서비스 화면을 갱신한다.

이 설계의 의미는 단순히 화면을 나눠 보여주는 데 있지 않다. 하나의 SQL 문장이 파싱 결과와 서비스 결과를 동시에 바꾸는 과정을 한 화면에서 확인할 수 있게 함으로써, SQL 처리기의 내부 동작과 응용 계층의 연결 관계를 직관적으로 드러내는 데 목적이 있다.

정리

정리하면, 이 프로젝트의 핵심 구현은 단순한 SQL 문법 데모가 아니라, 파서 -> 실행기 -> 저장소 -> 백엔드 프로토콜 -> 프런트엔드 시각화로 이어지는 흐름을 실제로 연결한 데 있다. 이를 통해 SQL 처리기의 내부 원리를 코드 수준에서 구현해 보고, 그 결과가 사용자 인터페이스에 어떻게 반영되는지도 함께 확인할 수 있는 구조를 만들었다.

추가로 현재 Parse Tree는 엔진 내부 AST(Abstract Syntax Tree)를 직접 직렬화한 결과라기 보다는, 백엔드가 쿼리 문자열을 기반으로 UI용 구조로 재구성한 데이터이다.

 

데모 시나리오 (시연 흐름)

한계와 다음 단계

아직 실제 모든 SQL 문장을 파서하게 설계를 하질 못해 UPDATE 및 DELETE도 구현이 안되어 있는 상태고, SELECT 내의 ORDER BY, GROUP BY, JOIN, IN, 등등 모든 많은 부분들이 부족한 상태이다.

실제로 SQL Client를 만들어 보고 싶다는 욕심이 생기기도 했다. (프로젝트를 하면서) 하지만, 좋은 상용 프로그램이 많은 상태에서 공부하는 것 외로 구현하기에는 그만큼 메리트가 없을 것 같기에 시간이 나면 좀 더 구현해 봐야겠다는 생각이 든다.