현대백화점 인재개발원 SQL 실무 과정 4주가 입문 단계에 DDL(테이블 설계·생성)을 넣었다. 이미 쿼리를 쓰는 실무자의 병목은 문법 부족이 아니라 구조를 읽는 관점의 부재였기 때문이다. 사내 SQL 교육을 검토한다면 참가자가 자기 테이블을 한 번 만들어 보는 회차가 있는지 확인한다.
원문 2026년 1월 12일에 따르면 현대백화점그룹 인재개발원 암사캠퍼스의 Data(SQL) 실무 과정은 2025년 9월 매주 화요일 5시간씩 4주로 진행됐다. 인원은 30~40명, 현대백화점·현대홈쇼핑·현대그린푸드·한섬·현대리바트 등 계열사 실무자가 한 강의실에 모였다. 모집 기준은 "SQL 미숙자(엑셀 기본 활용 가능자)", 방식은 강의·실습·미니프로젝트다.
첫 시간에 확인된 사정은 달랐다. 이미 업무에서 SQL을 쓰는 참가자가 많았다. 한 참가자는 "기존 쿼리문을 보면 구조를 모르겠어서 퍼즐 맞추기처럼 바꿔가며 겨우겨우 하게 돼요"라고 말했다. 쿼리가 왜 그렇게 짜였는지 모른 채 조건이 바뀌면 감으로 고쳐 돌려보고, 결국 엑셀로 내려받아 마무리한다.
같은 기관 과정 3년을 정리한 현대백화점 인재개발원 SQL 과정 3년이 도착점을 첫 데이터 추출 한 건으로 잡았다면, 이 글은 2025년 9월 회차가 입문 과정에 DDL을 넣은 이유를 다룬다.
"SQL을 쓰는데도 SQL을 못 쓰는 상태"는 문법이 아니라 구조를 읽는 관점의 문제였다
강사는 첫 시간에 물었다. SQL을 못 해서 힘든 것인지, 쓰긴 쓰는데 감으로 쓰는 것이 힘든 것인지. 수업 중 익명게시판으로 실시간 반응을 받았고, 답은 후자였다. 한 참가자는 "이 줄 지우면 깨질 것 같고, 저 줄 바꾸면 결과가 이상하고… 그냥 계속 돌려보면서 맞추는 느낌이에요"라고 적었다.
원문은 이 답을 교육 설계를 바꾼 단서로 꼽는다. 문법을 더 가르치는 것으로는 풀리지 않는다. 테이블이 왜 쪼개져 있고 어떤 키로 연결되는지가 보여야 기존 쿼리가 해석되고 수정이 덜 두려워진다.
그래서 목표는 "조회만 할 줄 아는 사람"이 아니라 자기가 쓰기 좋은 구조를 만들고(DDL), 뽑고(SELECT), 보고서로 끝내는 사람으로 잡혔다. 같은 기관 심화반이 ChatGPT 오답의 원인을 프롬프트에 넣지 못한 ERD에서 찾았듯, 이 회차도 문법 앞에 구조를 두었다.
입문 단계에 DDL을 넣자 "개발자 영역"이라던 참가자가 자기 구조를 생각하기 시작했다
원문에 따르면 대부분의 SQL 입문 교육은 SELECT 중심이다. 이 과정은 DDL(테이블 설계·생성)을 처음부터 포함했다. 도구는 MySQL과 HeidiSQL이었고, ChatGPT로 쿼리를 작성하고 검증하는 실습이 들어갔다.
첫 반응은 저항이었다. 한 참가자는 "DB 설계요…? 그건 개발자 영역 아닌가요?"라고 물었다. 강사의 정리는 세 가지다. 개발자가 만드는 것은 서비스 운영 DB이고, 실무자에게 필요한 것은 분석·집계·보고서용 구조인 경우가 많으며, 그것은 거창한 아키텍처가 아니라 자기가 뽑고 싶은 질문에 맞춰 테이블을 정리하는 능력이다.
마지막 회차는 미니프로젝트였다. 실제 데이터로 DB를 직접 구축하고(DDL 포함), 알고 싶은 질문을 쿼리로 정의하고, 데이터를 추출해, 보고서 형태로 정리한다. 원문은 실전 투입을 가르는 것이 "마지막 20%"라고 적는다. SELECT를 이해해도 업무 데이터 앞에서 다시 막히기 때문에, 쿼리 한 줄이 아니라 결과물 완성을 경험하게 했다. 한 참가자는 "이제 기존 쿼리도 덜 무섭고, '내가 원하는 데이터 구조'를 생각하게 되네요"라고 답했다.
계열사가 섞인 강의실에서는 실습 데이터를 세 갈래로 나눴다
두 번째 장벽은 업무 맥락의 다양성이었다. 계열사가 섞이면 같은 SQL 문장을 배워도 떠올리는 데이터가 다르다. 강사는 실습 데이터를 계열사 성격에 맞춰 나눴다. 그린푸드 계열은 음식 데이터, 백화점 계열은 매장·상품 데이터, 디지털·커머스 계열은 온라인 커머스 데이터다. 한 참가자는 "우리 팀 보고서 뽑을 때 쓰는 조건이랑 똑같네요"라고 했고, 관련 컬럼명만 들어가도 몰입도가 올라갔다고 적는다.
교육 뒤 남은 후기는 두 문장이다. "현대백화점 그룹 다니면서 가장 좋았던 복지가 이 강의 들은 것이다." "조언받은 대로 SQL 추출해서 개발팀에게 칭찬들었습니다." 논지에 닿는 것은 두 번째, 개발팀에 넘긴 추출 한 건이다.
가져갈 것
원문에서 확인된 항목만 적은 체크리스트다.
- 모집 기준이 "SQL 미숙자"여도 실제로는 쿼리를 감으로 고치는 참가자가 섞여 있는지, 첫 시간에 익명게시판 같은 실시간 채널로 확인했는가
- 과정 목표가 SELECT 조회에서 끝나지 않고, 참가자가 DDL로 자기 테이블을 설계·생성하는 단계를 포함하는가
- 마지막 회차가 DB 구축 → 질문을 쿼리로 정의 → 추출 → 보고서까지 완주하는 미니프로젝트인가
- 소속이 다른 참가자가 섞여 있다면 실습 데이터를 업무 성격별(음식·매장/상품·온라인 커머스처럼)로 나눠 준비했는가
- 주 1회 5시간, 4주 배치처럼 회차 사이 간격이 있고, 참가자 PC에 MySQL·HeidiSQL을 설치할 수 있는가
안 되는 경우
- 참가자 전원이 SQL을 처음 보는 조직. 설계 변경은 감으로 쓰는 참가자가 많다는 첫 시간의 확인에서 나왔고, 전원 초심자에게도 같은 효과가 나는지 원문은 다루지 않는다.
- 사내 서비스 운영 DB를 직접 설계하거나 고쳐야 하는 팀. 원문이 말한 DDL은 분석·집계·보고서용 구조이며, 운영 DB 설계는 개발자 영역으로 구분했다.
- 4주 20시간과 계열사별 실습 데이터를 준비할 수 없는 조직. 하루 압축 과정에서 같은 결과가 나오는지는 원문에 없다.
- 원문이 밝히지 않은 것: 만족도 수치, 후기 두 건이 30~40명 중 몇 명의 의견인지, 미니프로젝트에 쓴 "실제 데이터"의 출처와 사내 데이터 여부, 참가자별 사전 SQL 경험 분포, 보고서 결과물의 형식과 건수.
사내 SQL 교육을 검토하고 있다면 이번 주에 바꿀 것은 기획서의 참가자 정의다. "SQL 미숙자"를 "기존 쿼리를 감으로 고치는 사람"으로 바꿔 적고, 그 사람이 자기 테이블을 한 번 만들어 보는 회차가 과정 안에 있는지 확인한다. 그 회차가 없으면 문법을 더 얹어도 기존 쿼리는 퍼즐로 남는다. 실무자 대상 SQL·데이터 교육이 조녁컴퍼니의 어느 사업영역에 속하는지는 아래 링크에 있다. 사업영역 →