Sejong SQL

SQL Online Judge System

1. 프로젝트 개요1. Project Overview

SQL 기반 세종대학교 Online Judge System. (실제 데이터베이스 수업에 시범 도입)SQL-based Sejong University Online Judge System. (Piloted in actual Database course)

Phase 1: QOJ

Phase 2: Sejong SQL

2. 프로젝트 배경과 성장 과정2. Background and Growth

대학 데이터베이스 수업에서 교수 / 조교가 학생의 SQL 과제를 하나씩 수동으로 실행하며 채점하는 비효율적인 프로세스를 목격한 것이 출발점이었다.The starting point was witnessing the inefficient process where professors / TAs manually executed and graded each student's SQL assignments one by one in university Database courses.

Phase 1: QOJ (2020년 1학기)Phase 1: QOJ (2020 Spring)

2명이 팀을 이루어 QOJ(Query Online Judge)를 데이터베이스 수업 프로젝트로 개발하여 A+ 성적을 받았다. 수업 종료 후 담당 교수님께서 정식 도입을 제안했다.A team of 2 developed QOJ (Query Online Judge) as a Database course project and earned an A+ grade. After the semester, the professor proposed official adoption.

"여태 수업을 진행하면서 가장 인상 깊었던 프로젝트입니다. 학교 측에서 정식으로 도입하여 수업 보조 프로그램으로 활용하고 싶습니다.""This is the most impressive project I've seen throughout my teaching career. The university would like to officially adopt it as a course support tool."

Phase 2: Sejong SQL 고도화 (2022년 1학기)Phase 2: Sejong SQL Enhancement (2022 Spring)

교수님의 제안을 받아, 2022년 1학기 창의학기제를 통해 5명 팀으로 확대하고 PM 역할을 맡아 QOJ를 Sejong SQL로 전면 재설계했다. 고도화 과정에서 데이터베이스 관련 강의를 진행하는 교수님 7명을 직접 컨택하여 미팅을 진행했다. 실습 데이터 전달 방식, 채점 / 피드백 프로세스, 커리큘럼 한계 등에 대한 의견을 수집하여 제품 방향성에 반영했다.Following the professor's proposal, the team expanded to 5 members through the Creative Semester program in 2022 Spring. Taking on the PM role, QOJ was completely redesigned into Sejong SQL. During the enhancement process, 7 professors teaching database-related courses were directly contacted for meetings. Feedback on lab data delivery, grading / feedback processes, and curriculum limitations was collected and incorporated into the product direction.

Phase 1에서는 서비스 DB와 채점 DB를 동일한 MySQL에서 운영하여 환경 격리나 롤백 정책 등 보안 설계가 미흡했다. Phase 2에서는 이 한계를 해결하기 위해 채점 환경의 격리와 보안을 체계적으로 재설계했다.Phase 1 operated both service DB and grading DB on the same MySQL, leaving security design aspects like environment isolation and rollback policies insufficient. Phase 2 systematically redesigned grading environment isolation and security to address these limitations.

3. 채점 엔진3. Grading Engine

채점 엔진은 사용자가 제출한 SQL 쿼리를 안전하게 실행하고, 정답과 비교하여 판정을 내리는 핵심 컴포넌트다.The grading engine is the core component that safely executes user-submitted SQL queries and compares results against the answer to make a verdict.

문제별 격리와 SandboxProblem Isolation and Sandbox

각 문제를 독립된 PostgreSQL Schema로 격리하여, 쿼리가 다른 문제의 테이블에 접근하는 것을 원천 차단했다. 사용자가 제출한 쿼리는 READ ONLY 트랜잭션 + statement_timeout + Schema 격리가 적용된 Sandbox 환경에서 실행되며, 실행 후 무조건 ROLLBACK하여 테스트 데이터의 원본 상태를 보존한다.Each problem is isolated in an independent PostgreSQL Schema, fundamentally blocking queries from accessing other problems' tables. User-submitted queries run in a Sandbox environment with READ ONLY transaction + statement_timeout + Schema isolation, with unconditional ROLLBACK after execution to preserve original test data.

Query ExplainerQuery Explainer

단순 정답 매칭을 넘어, 제출된 쿼리가 얼마나 효율적으로 작성되었는지 분석하는 기능을 제공한다. DBMS 옵티마이저의 EXPLAIN 실행 계획을 파싱하여 Full Table Scan, 불필요한 File Sort, Impossible Condition 등의 비효율 패턴을 탐지하여, 문제 풀이 결과에 대한 피드백을 제공한다.Beyond simple answer matching, this feature analyzes how efficiently the submitted query was written. It parses the DBMS optimizer's EXPLAIN execution plan to detect inefficiency patterns such as Full Table Scan, unnecessary File Sort, and Impossible Condition, providing feedback on the submission results.

4. 보안 설계4. Security Design

SQL OJ 시스템은 사용자가 직접 SQL 쿼리를 작성하여 서버에서 실행하는 구조이므로, SQL Injection과 동일한 위험이 구조적으로 존재한다. 이를 위해 다중 방어 체계를 구성했다.Since the SQL OJ system has a structure where users write SQL queries that are executed on the server, the same risks as SQL Injection structurally exist. A defense-in-depth system was built to address this.

• 애플리케이션 레벨: 위험 구문(DROP, TRUNCATE, ALTER 등) 필터링, ORM 기반 Injection 방지Application Level: Dangerous statement filtering (DROP, TRUNCATE, ALTER, etc.), ORM-based Injection prevention
• DB 레벨: 채점 전용 Role에 최소 권한만 부여, Schema 격리로 접근 범위 제한DB Level: Minimum permissions for grading-dedicated Role, access scope restricted via Schema isolation
• 실행 환경: statement_timeout으로 고비용 쿼리 차단, 트랜잭션 롤백으로 데이터 보존Execution Environment: Expensive query blocking via statement_timeout, data preservation via transaction rollback

각 레이어가 독립적으로 동작하여, 한 레이어가 우회되더라도 다음 레이어에서 차단된다.Each layer operates independently, so even if one layer is bypassed, the next layer blocks the threat.

5. 성과 및 임팩트5. Results and Impact

수업 프로젝트로 시작한 QOJ가 교수님의 제안을 거쳐, 세종대학교 데이터베이스 수업에 실제 시범 도입하여 운영까지 이어졌다. 2명에서 5명으로 팀을 확대하며 PM 역할을 맡아 시스템 설계부터 교수님 미팅, 배포까지 전 과정을 리드했다.QOJ, which started as a course project, was piloted and operated in Sejong University's Database course following the professor's proposal. The team expanded from 2 to 5 members, with the PM role leading the entire process from system design to professor meetings and deployment.

교수 / 조교의 수동 채점이라는 실제 문제를 발견하고, 교수님 7명의 피드백을 직접 수집하여 제품에 반영한 경험은 단순한 기술 구현을 넘어 문제 정의 → 조사 → 실제 프로덕트 반영까지의 전 과정을 경험한 프로젝트였다.Discovering the real problem of manual grading by professors / TAs, directly collecting feedback from 7 professors, and incorporating it into the product — this experience went beyond simple technical implementation to encompass the entire process of problem definition → research → real product delivery.