프레임워크는 3년이면 사라지는데, SQL은 왜 30년째 멀쩡할까

한 번 배우면 평생 쓰는 기술이 있다

개발 공부를 하다 보면 좀 억울한 순간이 있어요. 큰맘 먹고 어떤 프레임워크를 깊게 파놨는데, 2~3년 지나니까 다들 다른 걸 쓰고 있고, 채용 공고에서도 그 기술 이름이 사라져 있는 거죠. jQuery 잘한다고 자랑하던 시절, AngularJS 마스터하던 시절, 다 그렇게 지나갔잖아요.

그런데 이 변덕스러운 동네에서 무려 반세기 가까이 자리를 지키고 있는 기술이 하나 있어요. 바로 SQL입니다. 1970년대에 등장한 이 친구가 2026년 지금도 거의 모든 백엔드 개발자의 필수 무기로 남아 있거든요. 오늘은 "SQL 한 번 제대로 배우면 30년은 우려먹는다"는 이야기를 좀 풀어볼게요.

SQL이 안 늙는 진짜 이유

핵심은 SQL이 선언형(declarative) 언어라는 데 있어요. 이게 뭐냐면, 보통 우리가 쓰는 자바나 파이썬 같은 언어는 "어떻게 할지"를 한 줄 한 줄 다 적어줘야 하잖아요. 반복문 돌리고, 조건 걸고, 임시 변수 만들고요. 이걸 명령형(imperative)이라고 불러요.

반면 SQL은 "무엇을 원하는지"만 말합니다. SELECT 이름 FROM 직원 WHERE 부서 = '개발팀' 이렇게요. "개발팀 사람들 이름 줘"라고 주문만 하면, 그걸 실제로 어떻게 디스크에서 찾아오고 어떤 순서로 처리할지는 데이터베이스 엔진이 알아서 정합니다. 우리는 결과만 받으면 되는 거죠.

이 구조가 왜 강력하냐면, 주문하는 방식이 안 바뀌어도 내부 엔진은 계속 진화할 수 있기 때문이에요. 똑같은 SELECT 문이 1980년대 하드디스크에서도 돌아가고, 지금 SSD 클러스터에서도 돌아가고, 수백 대로 쪼개진 분산 환경에서도 돌아가요. 문법은 그대로인데 그 밑에서 데이터를 처리하는 기술만 수십 년간 갈아끼워진 거죠. 우리가 배운 지식이 안 썩는 이유가 바로 이겁니다.

여기에 더해서 SQL은 표준(ANSI/ISO 표준)으로 관리돼요. 그래서 MySQL에서 배운 기본 문법이 PostgreSQL, 오라클, SQL Server에서도 거의 그대로 통합니다. 회사를 옮겨서 DB가 바뀌어도 다시 처음부터 배울 필요가 없어요. 세부적인 함수 몇 개만 다를 뿐이거든요.

NoSQL이 SQL을 죽일 거라더니

2010년대 초반에 "이제 관계형 DB는 한물갔다, NoSQL 시대다"라는 말이 엄청 돌았어요. MongoDB 같은 문서형 DB가 뜨면서 "SQL은 무겁고 느리다"는 분위기였죠. 그런데 시간이 지나고 보니 결론이 재밌게 났어요.

NoSQL이 사라진 건 아니에요. 적합한 자리에서는 잘 쓰이죠. 하지만 정작 그 NoSQL 진영도 결국 SQL 비슷한 쿼리 문법을 다시 만들어 붙이기 시작했어요. 데이터를 "이런 조건으로 골라줘"라고 표현하는 데 있어서 SQL만큼 잘 다듬어진 언어가 없었던 거예요. 심지어 빅데이터 쪽에서도 Spark SQL, 구글 BigQuery, 데이터 분석용 DuckDB까지 다 SQL을 입구로 채택했어요. 결국 "데이터를 다루는 공용어"는 SQL로 정리된 셈이죠.

한국 개발자에게

실무에서 보면 의외로 SQL을 ORM(객체-관계 매핑, 코드로 DB를 다루게 해주는 도구) 뒤에 숨겨두고 대충 쓰는 분들이 많아요. JPA나 Prisma 같은 거요. 편하긴 한데, 정작 쿼리가 느려서 장애가 터지면 결국 생성된 SQL을 직접 까보고 인덱스를 손봐야 하거든요. 그때 SQL 실력이 바닥이면 디버깅을 못 해요.

그래서 신입 때 시간을 쪼개서라도 JOIN, 인덱스, 실행 계획(EXPLAIN) 정도는 손에 익혀두라고 권하고 싶어요. 화려한 신기술 하나 더 배우는 것보다, 어쩌면 이게 30년짜리 투자일 수 있거든요.