– 자격증은 붙었는데, 정작 어려웠던 건 “왜 이걸 하는지”였다
필자는 비전공자다.
10년 정도 다른 일을 하다 늦게 개발로 넘어왔다.
그 과정에서 데이터 쪽 자격증을 몇 개 땄는데 그중 하나가 SQLD(SQL 개발자)다.
솔직히 고백하면, 처음 공부할 때 나는 SQL이 뭔지 감이 안 왔다.
“테이블에서 원하는 데이터를 가져온다”는 문장부터 막혔다.
테이블이 뭔데. 가져온다는 게 뭔데.
지금 보면 우스운 질문인데 그때는 진짜 그랬다.
그래서 이 글은 “SQLD 이렇게 공부하면 합격합니다” 같은 글이 아니다.
비전공자가 시험을 통과하고 실제로 쿼리를 써보면서 느낀 것,
시험이 묻는 것과 실무가 쓰는 것이 생각보다 다르더라는 이야기다.
SQLD 합격 증서
윗부분은 넘버가 있어서 삽입하지 않았다
SQLD는 어떤 시험인가
경험담부터 늘어놓기 전에, 검색해서 들어온 사람을 위해 시험 정보부터 정리한다.
- 주관: 한국데이터산업진흥원(K-DATA) — dataq.or.kr
- 응시 자격: 제한 없음 (전공·학력·경력 조건이 없다)
- 검정 방식: 필기만. 실기 시험이 없고 전부 객관식이다.
- 문항·시간: 객관식 50문항 / 90분
- 1과목 데이터 모델링의 이해 — 10문항
- 2과목 SQL 기본 및 활용 — 40문항
- 합격 기준: 총점 60점 이상, 단 과목별 40% 미만이면 과락
- 응시료: 50,000원 (2026년 기준)
- 시행: 연 4회(2026년은 60~63회). 2026년 일정은 3/7, 5/31, 8/22, 11/14로, 이 글을 쓰는 시점 기준 올해 남은 회차는 11월 14일 한 번이다. 접수는 대개 시험 4~5주 전에 열리고, 합격 발표는 시험 2~3주 뒤다. 회차별 정확한 날짜는 해마다 바뀌니 접수 전 dataq.or.kr 공지를 확인하는 게 안전하다.
여기서 두 가지가 눈에 띈다.
하나는 응시 자격에 제한이 없다는 점이다.
비전공자가 데이터 쪽에 발을 걸칠 때 가장 낮은 문턱이라, 나도 그래서 시작했다.
다른 하나는 2과목이 40문항으로 압도적이라는 점이다.
이름은 “SQL 개발자”지만 배점을 보면 이 시험의 본체는 결국 SQL 문법이다.
그리고 하나 더.
실기가 없다.
손으로 직접 쿼리를 짜서 검증받는 절차가 없다는 뜻인데, 나중에 이야기할 “시험과 실무의 간극”이 사실 여기서 출발한다.
비전공자가 자격증이 어려운 진짜 이유
공부하면서 제일 힘들었던 건 문제가 어려워서가 아니었다.
“이걸 왜 하는지”를 모른 채 외워야 한다는 거였다.
트랜잭션이라는 게 나온다.
원자성, 일관성, 격리성, 지속성.
이게 뭔 소린지 모르겠는데 시험엔 나오니까 그냥 외운다.
무지성으로.
정규형도 그렇다.
제1정규형, 제2정규형… 규칙은 외웠는데, 이걸 왜 나누는 건지는 몰랐다.
전공자라면 학교에서 데이터베이스 수업을 들으며 “왜”를 먼저 배웠을 거다.
그런데 비전공자는 그 “왜”가 통째로 비어 있다.
그래서 개념이 머리에 얹히지 않고 흘러내린다.
암기한 게 시험장 나오면 증발하는 이유가 이거였다.
붙잡을 맥락이 없으니까.
실무를 해보고 나서야 개념이 붙었다
재밌는 건, 순서가 반대로 왔을 때다.
프로젝트를 하면서 직접 테이블을 설계하고 쿼리를 짜보니 그제야 시험에서 외웠던 게 이해되기 시작했다.
PK(기본키)를 왜 주는지.
시험에선 “각 행을 유일하게 식별하는 값” 정도로 외웠다.
그런데 실제로 데이터를 넣고 빼다 보면,
PK가 없으면 같은 데이터가 중복으로 쌓이고 어떤 행을 고쳐야 할지 알 수가 없다.
그 불편을 한 번 겪고 나면 “아, 그래서 PK를 주는구나”가 몸으로 온다.
정규형도 마찬가지다.
한 테이블에 모든 걸 욱여넣었다가,
데이터 하나 바꾸는데 열 군데를 고쳐야 하는 상황을 만나면 그때 정규화가 왜 필요한지 이해된다.
트랜잭션의 원자성도 그렇다.
돈을 옮기는 처리에서 “빼기”는 됐는데 “더하기”가 실패하면 어떻게 되나.
그 순간 원자성(둘 다 되거나 둘 다 안 되거나)이 왜 필요한지가 선명해진다.
결국 개념은 정의를 외운다고 붙는 게 아니라, 그게 없을 때의 불편을 겪어야 붙는다.
비전공자에게 자격증이 어려운 진짜 이유가 여기 있다고 생각한다.
시험에는 나오는데 실무에선 안 쓰는 것
이렇게 실무 관점이 생기고 나서 시험을 돌아보니, 재밌는 게 보였다.
시험이 비중 있게 다루는데 실무에선 거의 안 쓰는 것들이 있다.
대표적인 게 UNION이다.
두 쿼리 결과를 위아래로 합치는 문법인데, 시험엔 꽤 나온다.
UNION과 UNION ALL의 차이(중복 제거 여부)를 묻는 문제도 단골이다.
그런데 나는 실무에서 UNION을 거의 안 쓴다.
이유는 단순하다.
여러 결과를 메모리에 올려놓고 합치는 동작이라, 데이터가 커지면 메모리 부담이 확 커진다.
굳이 UNION으로 합칠 상황이면, 대개 쿼리 설계를 다르게 하거나 애플리케이션 단에서 처리하는 게 낫다.
그래서 시험 볼 땐 열심히 외웠지만, 실무에선 손이 잘 안 간다.
반대로 실무에서 압도적으로 많이 쓰는 건 JOIN이다.
그중에서도 INNER JOIN.
두 테이블에서 조건이 맞는 것만 이어 붙이는 건데, SQL로 하는 일의 절반은 이거다.
OUTER JOIN(한쪽에 짝이 없어도 남기는 것)은 생각보다 잘 안 쓴다.
필요가 없어서다.
대부분의 작업은 “조건에 맞는 것만” 필요하지, “짝 없는 것까지” 필요한 경우가 드물다.
이걸 겪고 나니 SQL이라는 도구의 정체가 정리됐다.
SQL은 결국, 방대한 데이터에서 조건에 맞는 걸 골라내는 도구다.
이 한 줄이 머리에 박히니, 어떤 문법이 실무에서 중요하고 어떤 게 시험용인지가 자연스럽게 갈렸다.
그래서 SQLD, 딸 가치 있나
솔직한 결론부터 말하면, SQLD는 추천한다.
비전공자가 데이터를 다룰 때 필요한 최소한의 문법과 개념을 한 바퀴 강제로 돌게 해준다.
무엇보다 “테이블에서 가져온다”가 뭔 소린지도 몰랐던 내가
적어도 SQL 앞에서 주눅 들지 않게 된 계기였다.
시험을 위한 지식이 실무의 뼈대와 겹치는 부분이 꽤 있다.
반면 같이 많이 언급되는 ADsP는, 개인적으로는 비추다.
데이터 분석 준전문가라는 이름이지만 실기가 없고 개념 위주라 “따고 나서 남는 게 적다”는 느낌이었다.
비전공자 입장에서 3과목(통계)이 특히 낯설어 고생은 고생대로 하는데 손에 쥐어지는 실무 감각은 얇다.
그럴 바에는 차라리 빅데이터분석기사(빅분기)나 정보처리기사(정처기)를 따는 게 낫다고 본다.
같은 시간을 쓴다면 실기가 있어서 손을 움직여야 하는 자격증이 남는 게 많다.
그럼에도 ADsP는 개발쪽으로 전향하기 막 시작한 사람이 전반적으로 훑어보려고 하거나,
기획이나 마케팅 직무에서 개발 지식을 찍먹(?) 하고 싶다면 괜찮아 보인다
(근데 요즘 시험 난이도가 극악이라 들었다. Team ADsP 밈이 생긴걸 보고
AI가 발전하고 생산성이 높아질수록 자격증 따기가 더 어려워지겠다는 생각이 들었다)
비전공자를 위한 SQLD 꿀팁
거창한 공부법은 아니고, 내가 겪고 나서 “이건 먼저 알았으면 좋았겠다” 싶은 것들이다.
1. 배점부터 보고 공부 비중을 정해라.
2과목(SQL 기본 및 활용)이 40문항, 1과목(데이터 모델링)이 10문항이다.
시험의 무게추가 어디 있는지 명확하다.
막연히 “처음부터 차근차근”보다, 2과목에 시간을 몰아주는 게 합리적이다.
2. 그런데 과락은 1과목에서 난다.
총점 60점을 넘겨도 과목별 40% 미만이면 떨어진다.
1과목은 문항이 10개뿐이라, 몇 개만 흔들려도 과락 구간에 들어간다.
배점이 작다고 버리면 그게 발목을 잡는다.
비중은 2과목에, 하한선은 1과목에 두는 게 맞다.
3. 실기가 없다는 걸 양날로 이해해라.
손으로 쿼리를 짜서 제출하는 절차가 없으니 부담은 적다.
대신 그만큼 문법을 눈으로 외우는 비중이 커진다.
이게 편해 보이지만, 앞에서 말한 “시험과 실무의 간극”을 만드는 원인이기도 하다.
4. “실무에서 안 쓰니까 버린다”는 안 통한다.
앞에서 이야기했듯 UNION처럼 실무에선 손이 잘 안 가는데 시험엔 꾸준히 나오는 문법이 있다.
실무 감각이 생기고 나면 이런 걸 무시하고 싶어지는데, 시험은 시험이다.
시험용 지식은 시험용대로 따로 담아두는 게 마음 편하다.
5. 그래도 제일 빨리 붙는 건 직접 짜보는 것이다.
이건 팁이라기보다 이 글 전체의 결론에 가까운데, 다음 문단에서 이어서 쓴다.
비전공자에게 하고 싶은 말
만약 예전의 나처럼 “테이블이 뭔지도 모르겠는데 자격증부터 봐야 하나” 싶은 사람이 있다면.
정의를 무지성으로 외우기 전에, 작은 거라도 직접 쿼리를 한 번 짜보라고 말하고 싶다.
무료 데이터베이스 하나 깔고, 표 두 개 만들고, JOIN 한 번 걸어보는 것.
그 30분이 트랜잭션 정의를 열 번 읽는 것보다 개념을 훨씬 단단하게 붙여준다.
비전공자에게 부족한 건 머리가 아니라 맥락이다.
그 맥락은 외워서 채워지지 않고, 작게라도 만들어봐야 채워진다.
나는 그걸 시험에 붙고 나서야 알았다.
그래서 이 글을 남긴다.
함께 읽으면 좋은 글
글쓴이 · Plutojoshua
핀테크에서 LLM과 AI 에이전트를 실제 서비스에 적용하는 개발자다. 카카오 AI 앰배서더로 Kanana 모델을 앱에 직접 연동해 검증하고, 비전공자로 시작해 실제 코드와 측정값을 근거로 “왜 그렇게 설계했는지”를 1인칭으로 기록한다. 운영자 소개는 About, 코드는 GitHub에서 볼 수 있다.