SQL 실습 서비스, 브라우저 SQLite로 시작할지 서버 DB를 구축할지 정하는 기준

SQL 학습·실습 서비스를 기획할 때 가장 먼저 나오는 요구는 대개 “설치 없이 브라우저에서 바로 실행하게 해 달라”입니다. 이 요구만 놓고 보면 브라우저 안에서 SQLite를 실행하는 방식이 답처럼 보입니다. 그러나 제품 책임자가 결정해야 할 질문은 조금 더 구체적입니다.

학습자가 첫 쿼리를 실행한 뒤 데이터를 바꿔도 되는가, 문제 풀이와 자유 실습은 같은 데이터베이스를 써도 되는가, 정답은 무엇으로 판정할 것인가, 다른 기기에서도 진도를 이어야 하는가를 함께 정해야 합니다. 이 흐름을 정리하지 않으면 브라우저 SQLite든 서버 DB든 시간이 갈수록 예외 처리와 운영 부담이 쌓입니다.

이 글의 결론부터 말하면, 입문 SQL 학습과 정형화된 문제 풀이가 중심이라면 브라우저 내 SQLite 구조로 시작할 수 있습니다. 다만 DBMS 고유 문법, 다중 사용자 협업, 대용량 데이터, 실행 계획 비교, 운영 DB와 유사한 권한 체험이 핵심이라면 서버 실행 환경을 별도로 검토해야 합니다.

먼저 나눌 것은 기술이 아니라 학습 장면입니다

“SQL을 실행한다”는 기능은 하나처럼 보이지만, 학습 서비스 안에서는 서로 다른 장면이 섞여 있습니다.

학습 장면	필요한 환경	권장 분리 방식
입문 문법 연습	언제든 초기 상태로 돌아갈 수 있는 데이터	브라우저 메모리 또는 로컬 저장소 기반 샌드박스
문제 풀이와 자동 채점	사용자 쿼리와 정답 쿼리를 같은 조건에서 비교할 환경	문제마다 초기 데이터 복사본 사용
자유 SQL 스튜디오	사용자가 만든 테이블과 수정 이력을 유지할 공간	개인 작업 DB를 별도 저장
진도, 북마크, 설정	기기 간 동기화와 계정 기준 접근 제어	서버 또는 클라우드 저장소
커뮤니티, 공유 과제	여러 사용자가 읽고 쓰는 데이터와 권한 관리	서버 저장소와 작성자 권한 규칙

브라우저 SQLite는 첫 세 장면 중에서도 특히 입문 실습과 개인 작업 공간에 잘 맞습니다. 사용자가 UPDATE나 DELETE를 잘못 실행해도 다른 학습자의 데이터에는 영향이 없습니다. 실습 환경을 사용자별로 생성하고 초기화하는 서버 운영도 줄일 수 있습니다.

반면 진도, 계정 설정, 게시글, 댓글처럼 여러 기기와 여러 사용자가 공유해야 하는 정보까지 브라우저에만 두면 서비스가 끊깁니다. SQL 실행은 브라우저에서 하고, 학습 기록과 공유 데이터는 서버에 저장하는 분리가 현실적인 출발점이 될 수 있습니다.

브라우저 SQLite로 시작해도 되는 조건

브라우저에서 SQLite를 실행하려면 일반적으로 WebAssembly 기반 엔진을 불러와야 합니다. 예를 들어 sql.js는 SQLite를 브라우저에서 구동할 수 있게 해 주지만, SQLite가 모든 상용 DBMS의 동작을 재현하는 것은 아닙니다.

다음 조건이 많을수록 브라우저 SQLite로 시작하기 좋습니다.

• 교육 목표가 SELECT, WHERE, JOIN, GROUP BY, 서브쿼리, 집합 연산 등 공통 SQL 문법에 가깝다.
• 학습 데이터셋을 서비스 운영자가 미리 설계하고 제공한다.
• 학습자별 데이터가 서로 섞이지 않아야 한다.
• 문제 풀이가 짧은 쿼리와 결과 확인 중심이다.
• 실습 환경이 네트워크 상태에 크게 좌우되지 않아야 한다.
• 초기 단계에서 DB 실행 서버의 운영, 사용자별 DB 생성, 세션 정리 부담을 피하고 싶다.

이 경우에도 “브라우저에서 실행되니 가볍다”고 가정하면 안 됩니다. SQL 엔진과 WebAssembly 파일을 첫 화면에서 모두 불러오면, 아직 실습을 시작하지 않은 방문자도 로딩을 기다리게 됩니다. 홈, 강의 목록, 진도 화면과 SQL 스튜디오를 같은 진입 경로로 묶지 말고, 실행 엔진은 실습 화면에 들어갈 때 불러오는 편이 낫습니다.

또한 브라우저 저장소는 사용자가 삭제할 수 있고, 기기나 브라우저를 바꾸면 이어지지 않을 수 있습니다. 개인 작업 DB를 로컬에 보관한다면 초기화, 내보내기, 복구 가능 범위를 제품 정책으로 명확히 안내해야 합니다.

서버 DB 실행 환경이 필요한 신호

서버 DB가 필요한 이유는 “더 전문적으로 보이기 때문”이 아닙니다. 학습 목표가 브라우저 SQLite의 범위를 넘어설 때 선택해야 합니다.

다음 요구가 요구사항 문서에 반복해서 등장한다면 서버 실행 환경을 우선 검토하는 편이 안전합니다.

• MySQL, PostgreSQL, Oracle 등 특정 DBMS의 문법과 함수 차이를 실습해야 한다.
• 저장 프로시저, 트리거, 사용자 권한, 트랜잭션 격리 수준처럼 DBMS별 동작을 다뤄야 한다.
• 여러 학습자가 하나의 데이터베이스를 함께 수정하며 협업 과제를 수행해야 한다.
• 대용량 데이터 처리, 인덱스 설계, 실행 계획, 쿼리 성능 비교가 교육 목표에 포함된다.
• 강사나 운영자가 학습자의 실행 이력, 오류, 제출 상태를 상세하게 재현해야 한다.
• 기업 교육처럼 내부 데이터 모델에 가까운 환경과 접근 통제가 필요하다.

서버 DB를 구축한다고 해서 모든 학습자가 하나의 공용 DB를 쓰게 해서는 안 됩니다. 한 학습자의 변경 쿼리가 다음 학습자의 문제를 망가뜨리는 순간, 운영팀은 데이터 초기화 요청을 반복해서 처리하게 됩니다. 과제별 데이터베이스 복제, 사용자별 스키마 분리, 실행 시간 제한, 허용 쿼리 범위, 초기화 정책을 함께 설계해야 합니다.

특히 변경 쿼리를 허용할지 먼저 결정해야 합니다. 조회 문제만 제공한다면 INSERT, UPDATE, DELETE를 제한하는 편이 채점과 복구를 단순하게 만듭니다. DML과 DDL 학습이 목표라면 허용하되, 과제 종료 후 폐기할 샌드박스와 재시작 절차가 필요합니다.

자동 채점은 SQL 문장이 아니라 학습 목표를 평가해야 합니다

SQL 학습 서비스에서 채점은 실행 엔진보다 더 어려운 제품 기능이 될 수 있습니다. 같은 결과를 만드는 SQL은 여러 형태로 작성할 수 있기 때문입니다. 문자열이 정답 SQL과 같은지만 비교하면, 올바른 풀이도 오답 처리하게 됩니다.

기본 채점은 사용자 쿼리와 기준 쿼리를 같은 초기 데이터에서 각각 실행한 뒤 결과를 비교하는 방식이 적합합니다. 이때 요구사항에 다음 기준을 적어 두는 편이 좋습니다.

• 행 수와 열 수를 비교할 것인가
• 열 순서와 열 이름까지 검사할 것인가
• 정렬이 문제 요구사항에 포함될 때만 행 순서를 평가할 것인가
• 숫자, 날짜, NULL 값을 어떤 규칙으로 비교할 것인가
• 오류가 난 쿼리에 어떤 수준의 안내를 제공할 것인가
• 변경 쿼리와 여러 문장 실행을 허용할 것인가

결과 비교만으로는 우회 풀이를 충분히 막기 어렵습니다. 현재 데이터에 보이는 값을 직접 나열해도 우연히 정답 결과가 나올 수 있습니다. 이를 줄이려면 기준 데이터 외에 값과 행 구성이 달라진 검증 데이터를 두고, 두 환경에서 모두 의도한 결과가 나오는지 확인하는 방식을 고려할 수 있습니다.

다만 여기에도 한계는 있습니다. 모든 논리적 동치를 자동으로 판별하려 하면 채점 시스템이 과도하게 복잡해집니다. 학습 목표가 JOIN 연습인지, 집계 함수 연습인지에 따라 요구 테이블이나 핵심 구문 사용 여부를 제한적으로 검사하고, 문제 설명에서 허용 풀이 범위를 분명히 하는 편이 운영 가능성이 높습니다.

데이터셋과 스키마 탐색이 에디터보다 먼저 결정돼야 합니다

입문자는 빈 SQL 에디터 앞에서 오래 멈춥니다. 특히 JOIN과 GROUP BY는 테이블이 여러 개 있다는 사실만으로 학습되지 않습니다. 어떤 키로 연결하는지, 연결하지 않은 행이 왜 남는지, 집계했을 때 그룹별 차이가 왜 생기는지를 데이터가 보여줘야 합니다.

요구사항 단계에서 데이터셋 담당자와 제품 담당자가 함께 확인할 항목은 다음과 같습니다.

• 테이블 사이의 관계가 외래키 또는 명확한 연결 규칙으로 표현돼 있는가
• INNER JOIN과 LEFT JOIN의 차이가 결과에서 드러나는가
• 그룹별 건수나 합계가 모두 같지 않아 집계 결과를 해석할 수 있는가
• 주문이 없는 고객, 소속 직원이 없는 부서처럼 예외 행이 있는가
• 같은 문제를 여러 난도로 확장할 수 있는가
• 스키마, 컬럼 설명, 샘플 행, 관계도를 학습 화면에서 확인할 수 있는가

스키마 설명을 별도 문서에만 두면 학습자는 문제와 문서를 오가며 맥락을 잃기 쉽습니다. 테이블명, 컬럼 타입, 샘플 데이터, 관계를 SQL 에디터 가까이에서 확인하게 하면 학습자는 쿼리를 복사하기보다 연결 조건을 스스로 찾을 가능성이 높아집니다.

요구사항 문서에는 네 가지 저장소를 구분해 적어야 합니다

개발팀이나 외주 업체에 “SQL 실습 기능”을 요청할 때는 데이터 저장 위치를 한 문장으로 뭉뚱그리지 않는 편이 좋습니다. 아래 네 가지를 분리해 적으면 구현 견적과 운영 범위도 더 정확해집니다.

1. 학습용 기준 데이터: 모든 문제의 출발점이 되는 읽기 전용 데이터입니다. 버전 관리와 초기화 기준이 필요합니다.
2. 사용자 작업 데이터: 자유 실습에서 사용자가 수정한 테이블과 쿼리입니다. 로컬 저장, 서버 동기화, 보관 기간을 정해야 합니다.
3. 채점용 실행 데이터: 제출마다 깨끗한 상태로 시작해야 합니다. 사용자 작업 데이터와 섞이면 안 됩니다.
4. 학습 기록과 공유 데이터: 진도, 정답 여부, 북마크, 설정, 게시글, 댓글처럼 계정과 권한이 필요한 정보입니다.

이 구분이 빠지면 흔히 두 문제가 생깁니다. 하나는 자유 실습에서 바꾼 데이터가 문제 채점에 영향을 주는 경우입니다. 다른 하나는 실행 결과와 원본 데이터를 서버에 과도하게 저장하면서 비용, 개인정보, 접근 권한 논의가 뒤늦게 따라오는 경우입니다.

브라우저 SQLite로 시작할지 서버 DB를 구축할지는 기술 선호의 문제가 아닙니다. 첫 출시에서 제공할 학습 범위를 정한 뒤, 문제 풀이의 초기화 규칙과 채점 기준을 먼저 문서화해 보십시오. 그 문서에서 특정 DBMS 문법, 협업 수정, 성능 실습, 상세 실행 재현이 필수로 드러난다면 서버 환경을 준비할 이유가 분명해집니다. 반대로 입문 학습의 흐름이 중심이라면, 실행은 브라우저에 두고 저장이 필요한 정보만 서버로 분리하는 구조로 충분히 시작할 수 있습니다.