SQL 이해해보기 - 들어가면서

이번엔 영역을 조금 바꿔서 SQL 에 대해서 이야기를 해보려고 한다. 뭐 생각하기에 따라서 SQL 도 Structured Query Language의 약자이니 기술적 일 뿐 여전히 언어의 범주에 속한다고 생각하고 접근해도 될 듯하다. 그리고 이왕 얘기를 한 김에 SQL과 대칭 된 듯이 보이는 Nosql 쪽에 대한 의견도 정리해 전달해 볼까 한다.

제목을 데이터베이스의 이해라고 하지 않고 SQL의 이해라고 한 이유는 그렇게 깊은 곳까지 들어갈 자신도 없고, 데이터베이스 자체 까지 얘기하다 보면 글의 목적도 많이 벗어나게 될 것 같기 때문이다. 그래서 쿼리를 통해 데이터베이스에 데이터를 저장도 하고 조회도 하는 SQL로 범위를 제한하려 한다. 

이 글의 대상은 쿼리를 어떻게 사용하는지 관심이 있는 비즈니스 쪽 분야이거나(전통적으로 이쪽에서 사내 데이터를 받아 분석하다 직접 퀴리를 날리기 시작하면서 데이터 분야 쪽으로 전직하는 경우도 있고, 요즘은 AI 검색 엔진의 도움을 받아서 좀 더 허들을 쉽게 넘는 경우도 종종 보이는 듯 싶다), 또는 게시판 같은 프로그램 들을 만들면서 간단한 쿼리들을 만들어 봤지만 아직 SQL 의 전체적인 그림은 보이지 않는 기술 쪽 사람들 정도가 될 것 같다. 

이미 SQL을 익숙하게 쓰며 디비를 다루어 봤던 분들은 이 글을 굳이 보실 필요는 없을 것 같지만, 만약 MSSQL, Oracle, MySQL 등의 관계형 디비(RDB)만을 사용해 왔다면, 뒤에서 쿼리 관점에서 간단히 비교해 다룰 MongoDB나 Elastic Search, Redis 에 대한 이야기는 한번 읽어봐도 괜찮을 것 같다고 생각한다.

---

그럼 일단 본격적인 얘기를 시작하기 전에 왜 굳이 SQL을 배우는 게 IT 세상에서 살아가는데 도움이 될 수 있다고 생각하고 있는지와, 요즘 같이 AI에게 하고자 하는 일과 함께 잘 물어보면 쿼리를 잘 만들어 주는 상황에서 굳이 SQL을 처음부터 이해를 할 필요가 있는 지에 대해서 당위성을 살펴보자.



우선 SQL은 데이터베이스나 그와 비슷한 시스템에 쿼리를 날리는 언어라고 볼 수 있을 것이다. Query라는 단어는 무언가 질문을 던지는 의미라서, 요즘 AI 엔진에 질문을 날리는 것과 동일하다고 볼 수 있다. Structured 라는 것은 무언가 구조화된 것을 나타내므로, 현재 언어 기반으로 질문을 던지는 AI 에 비해서는(물론 이것도 어찌 보면 자유 도는 있지만 언어라는 틀에 갇혀 있다고 볼 수 있다. 말도 안되는 말로 질문을 하면, 말도 안되는 답이 올 테니까 말이다) 약간 고지식하게 제한된 단어와 문법을 이용해서 던지게 된다. 

어찌보면 AI 쪽에서 얘기하는 프롬프트 엔지니어링처럼 질문을 받는 대상 엔진이 학습을 한 형태와 결이 맞아, 이해하고 답을 잘 낼 수 있는 형태의 질문을 던지는 거라고 보면 된다. 다만 SQL 쪽은 해당 부분이 훨씬 더 엄격해서(이건 프로그래밍 언어도 그렇다) 조금만 문법이 틀리거나 사전에 정의된 키워드를 사용 안 하면 에러를 내버린다. 사실 프로그래밍 언어를 포함해 이 엄격함 부분이 입문자 들을 힘들게 만드는 요소이긴 하다.

SQL이 질문을 던지는 대상인 데이터베이스는 말 그대로 데이터(data)의 기반(base)이다. 컴퓨터가 생기고 하드 디스크 형태의 저장소(아마 처음엔 테이프 형태였겠지만)가 처음 생겼던 시점부터, 데이터는 어떤 형태로 든 저장되어 왔었었다. 데이터베이스는 해당 데이터를 파일 안에 구조적으로 잘 저장하고, 구조적으로 잘 조회해 오는 데에 특화된 프로그램 형태라고 볼 수 있다. 

실제로 우리가 얘기하는 많은 형태의 SQL, NoSQL 서버들은 데이터들을 파일 안에 바로 저장하거나, 속도를 위해 메모리 안에 파일 형태 비슷하게 저장했다가, 최종적으로는 파일 형태로 저장해서 영구적으로 데이터를 보호하고 제공한다고 보면 된다. 그 저장하고 가져오거나, 조금 더 나아가 데이터베이스 서버에게 특정한 정렬 및 연산을 통해서 우리가 원하는 결과 셋을 가져오게 하는 공식적이고 표준적인 언어를 SQL 이라고 보면 된다. 



그래서 IT를 이해하려면 반드시 사람 또는 기계, 환경으로부터 시작된 여러 데이터들이 흐르게 되고, 그 흘러다니던 데이터가 결국 어딘가에 다음 처리나 영구적인 보관을 위해서 체계적으로 저장되어야 하는데 그게 데이터베이스 형태이고(물론 뭐 여러가지 캐싱이나 카프카 같은 메시징 큐, 로그 파일 등의 중간 형태의 저장도 있긴 할 테지만 그건 기본적인 걸 이해한 후, 다음 단계의 주제니 나중에 고민해 보자), 데이터베이스를 실무적으로 이해하는 방법은 데이터베이스를 설치해 보고 Query 날려 이해하는 것이라고 본다. 또한 다음 시리즈로 다루고 싶은 자동화를 위한 스크립팅이나 프로그래밍 분야의 응용을 위해서도 이 SQL에 대한 이해는 필수 불가결한 주제라고 본다.

데이터 관련 테스팅을 하거나 하거나 보안 업무를 진행하려 한다면, 해당 주제들을 이해하지 못한다면 거의 아무 것도 못한다고 할 수 있다. 물론 테스팅이나 보안 같은 지식들이 당연히 기본으로 동반 되어야 할 테지만 그것은 대상을 어떻게 해당 분야의 관점으로 해석하느냐에 대한 문제이고, 기본적으로 해당 대상이 무엇인지 모른다면 아무것도 할 수 없는 상황이 된다. 좀 더 최신 분야를 얘기하자면 AI 보안 쪽 일 것이다. 데이터 분석이나 AI를 전혀 모르는 보안 인력이 해당 분야에 가서 뭔가 의미 있는 일을 하기에는 같이 일하는 사람들의 아주 큰 배려와 특정 수준까지 올라오기를 기다리는 인내심이 없다면 거의 힘든 상황이 될 것이다. 

그래서 데이터의 이해, 자동화, 개발 또는 데이터베이스와 관련된 테스팅, 보안 등을 잘 하기 위해서는 기본적으로 이해해야 되는 부분 중 하나가 SQL(+NoSQL) 이라고 생각한다. 그래서 개인적으로 SQL 이라는 주제는 IT 와 관련된 직업의 어느 시점에서든 꼭 어느 정도 이해하고 넘어가면 좋을 것 같은 주제라고 생각을 한다.

---

다음으로는 AI의 고도화로 인한 지식의 대체 측면에 대해서 생각해보자. 여기에는 전문가들에 비해서 특별한 소양이 있는 건 아니니 때문에, 사용자 관점에서 얘기를 해보려 한다. 개인적으로 현재 상태의 AI 엔진에 대해 의인화를 하자면 엄청 똑똑하고 아는 게 많지만, 뭔가 평균적이고, 모범적인 느낌이 있고, 가끔 자신도 모르게 거짓말을 섞는 사람이다. 악의는 없기 때문에 또 뭐라고 할 수는 없는데, 그렇다고 그대로 믿기에는 불안한 측면이 있다.

AI 엔진의 결과에 대해서 적절한 사회적 책임을 지우기 위한 논의가 활발하다고는 하지만, 과연 AI 엔진의 생산자가 뻔히 가끔 악의 없는 거짓말 들을 한다는 것을 아는 상태에서(사실 선의/악의 자체가 인간의 기준과는 다르기도 하고 학습 데이터의 담긴 메시지에 의해 결정 나는 편일 것이기 때문에 의도를 따지는 게 별 의미는 없을지도 모른다) 그 책임을 선뜻 맡을 것 같지는 않다. 보험 같은 리스크 분산 형태로 일부 해결될진 모르지만 그런다고 피해자가 생기는 근본적인 문제를 막을 수는 없을 테고, 그런 잘못된 결과에 대해 책임을 지우는 것은 AI 산업 자체의 발전에 큰 제약을 가져올 수도 있을 테고 말이다.

지금 같이 일상적이거나 일부 기술적인 부분에 대해서 질문을 하는 경우에 대해 크게 부작용이 보이지 않는 작은 헤프닝인 것처럼 느껴지지만, 만약 의사 자격이 없는 사람이 뛰어난 AI 엔진에게 문의해 답을 받아서 해당 지식을 가지고 의사 활동을 한다고 하면 누가 그 사람을 인정할 수 있고, 어떻게 그 책임을 질 수 있겠냐는 극단적인 상황을 생각해보면 작은 일은 아닌 듯한 느낌도 든다. 프로그래밍 쪽도 마찬가지로 요즘 같이 모든 기반 산업 및 서비스 등이 소프트웨어에 기반해 돌아가는 측면에서 앞에 예를 든 의료 쪽 문제에 비해서도 그렇게 가벼운 주제는 절대 아닌 듯 하다. 

요즘 개발자 쪽에서 AI 검색으로 얻은 코드를 보기에 잘 돌아간다는 이유로 추가적인 검증 없이 가져다 코드에 넣는 경우도 느는 듯 하지만, 테스팅이나 보안의 관점에서는 이런 행위가 너무 용감하다는 느낌도 드는 측면도 있다(물론 잘 짜여진 프로세스에서는 후속 된 유닛 테스트, 코드 리뷰나 기능 테스팅 등이 해당 문제를 잘 막을 가능성도 있다). 하지만 언젠가 많이 쓰이는 오픈 소스에서 특정한 결함이 있는 코드가 발견되어 해당 코드를 쓰는 수많은 시스템을 변경해야 되는 이슈가 생기는 문제처럼, AI 엔진이 추천해서 만든 코드에서 그런 문제가 생기진 않는 다는 보장은 누구도 못할 듯 하긴 하다.



그럼에도 불구하고 예전 구글 검색 엔진이 생겼을 때처럼 현재의 AI 검색 엔진 또한 무시하고 살아가기는 그 효용 성을 보면 현실적으로 어렵다고 본다. 그럼 어떻게 AI 검색 엔진 사용에 접근 해야 될까? 개인적으로 생각했을 때는 AI 검색 엔진은 특정한 초기 학습을 돕는 목적이 아니라면, 직업 적으로는 자기가 잘 아는 분야에 대해서 질문을 던지는 방식으로 써야 한다고 생각한다.

아까의 의인화 측면에서 얘기하자면 같이 지낼 수 밖에 없는 어떤 대상이 좋은 말을 많이 하지만 의도 되지 않은 거짓말을 가끔 섞어 쓴다면(만약 진짜 의도적이라면 그 사람을 피해야 하겠다...), 그 거짓말에 영향 받지 않도록 내가 상황을 관리하는 수밖에 없다. 해당 부분이 가능 하려면 상대의 상황을 이해하고, 내가 알고 있는 그 분야의 지식과 비교해서 상대가 그렇게 말하는 이유를 추측하고, 신뢰할 수 있는 지를 판단할 수 밖에 없다. 그렇게 되려면 자신이 질문하려는 그 분야를 스스로 잘 이해할 수 밖에 없다고 본다. 

약간 아이러니 하지만 AI 엔진이 제공해주는 추론 적이거나 고차원적인 언어적 쿼리의 혜택을 최대한 누리려면, 내가 그 분야를 AI 엔진이 얘기해 주는 수준과 적어도 비슷하게 이해하는 것이 중요하다고 본다(이런 부분이 AI 시대가 직업을 처음 시작하는 주니어에게는 불리하고, 결과를 비판적으로 볼 수 있는 자기 생각의 기준이 있는 시니어에게 유리하다는 얘기의 일부 측면과 연결되는 게 아닌가도 싶다).

또한 AI 의 발전도 물론 중요하겠지만 한 인간으로써, AI가 새로운 학습을 하듯이 우리도 AI 에게 계속 질문을 던지면서 성장해 가야 한다고 본다. 마치 과거에 구글 검색엔진에 올라온 수많은 사람들의 얘기를 비판적으로 종합해 이해하면서 기술자들의 내면이 성장했듯이 말이다(개인적으로는 요즘 AI 엔진의 경우 그런 데이터들의 학습을 기반으로 성장했을텐데, 실제의 결과에서는 그 사람들의 특이한 관점들이 점점 사라져서, 나중에는 반대로 AI가 학습할 만한 그러한 지식의 반딧불들이 혹시나 멸종되어 버리진 않을까 하는 생각도 해본다). 

그래서 우리가 SQL 을 잘 이해하고 데이터를 저장하고 분석하고, 조회하는 데에 사용하고 싶다면, 우선 SQL을 어느 정도 이해하고 해당 부분을 기반으로 검색 엔진이든 AI 검색이든, 책이든, 타인과의 교류 등을 통해서 자신이 이해한 모델을 확장시켜 나가야 한다고 생각한다. 좀 우스꽝스러운 생각일지도 모르지만 AI 를 사용하는 우리 자신도 하나의 불완전하지만 이상적이고 계속 변할 수 있는 모델이라고 생각하기 때문이다. AI를 신기해 하고 앞으로의 발전을 기대하는 것도 좋지만 우리 자신의 내면의 모델을 강화 시키는 측면에서 AI를 관찰하고 사용하는 것도 나쁘진 않다고 생각한다. 

그래서 AI가 아무리 SQL을 잘 짜 주더라도, 그걸 스스로의 기존 지식에 의해서 잘 이해하고 사용하는 게 스스로나 해당 결과에 영향을 받을 수 있는 외부 시스템이나 사람들에게도 좋기 때문에 SQL 이 무언 지에 대한 자기 생각 정도는 이해해 하나 정도 가지고 있는 게 좋지 않을까 생각한다. 엔지니어로서 기술이 이해는 안 되지만 잘 동작하는 마술같이 보인다면 큰일이라고 생각한다. IT는 반드시 왜 그렇게 동작 하는지 설명이 가능해야 하는 분야이기 때문이다. 여하튼 위의 2개의 이유 때문에 이 글을 시작하게 되었다고 얘기해 봤는데 공감이 되었을진 모르겠다.

[마술의 원리를 이해하기]

---

그럼 앞으로 진행할 방식을 얘기해 보자. 우선 할 얘기가 아주 많진 않을 듯 해서 아마 5~8 편 정도로 끝날 것 같다. 아무래도 이 주제는 실습이 없음 의미가 없을 듯 해서 고민해 보다가 MSSQL이나 MySQL 등을 직접 설치해서 하게 되면, 주제인 SQL 과 크게 상관없는 너무 세부적인 것들을 설명하게 되 버려서 처음 경험하는 분들의 집중력을 해칠 것 같고, 다른 방법으로 무 설치로 웹에서 실습 할 수 있는 방식도 찾아보았으나 조회 쿼리 등은 가능하지만 직접 데이터를 넣지는 못하는 것 같아서, 결국 SQLite 라는 로컬 파일 형식의 미니 디비를 사용해서 이야기를 풀어보려고 한다(일부 프로그램 설치가 필요하지만 앞의 다른 디비들에 비해서는 정말 간단해 관심 있는 사람이면 충분히 따라할 수 있을 것 같이 판단 되었다).

아마 얘기하고 싶은 왠만한 SQL 요소는 거기서 다 얘기할 수 있을 테고, 요즘 맥만 있는 분들도 많으니 예전 책에서의 아쉬움을 생각해서 가능함 처음 세팅 부분에서는 윈도우와 맥 환경의 실습 환경 세팅을 모두 설명해 보려 한다. 전체 글에 걸쳐 가능한 웹이나 AI 검색 엔진의 설명에서 많이 얘기하고 있는 기술적인 관점의 설명보다는, 기존 글과 이어진 언어라는 관점에서 해당 SQL 문법들이 데이터베이스와 소통하는데 필요하게 된 상황을 가능한 쉽게 설명해 보려 한다. 다만 이미 개인적으로는 어느 정도 기술적 뷰의 당연함에 젖어있는 마음이라 잘 될지는 모르겠다(항상 그렇지만 한번도 경험하지 못한 상대방의 입장을 고려해 설명하는 부분은 생각보다 너무 어려운 일인 것 같다).

이런 기본적인 SQL에 대한 이해 부분이 잘 넘어가면, 이 후에 MSSQL 이나 MySQL 같은 다중 사용자 환경에서의 데이터베이스들을 소개하며 간단히 SQL 관점에서 어떤 차이들이 있는지 얘기하려 한다. 여기까지 무사히 마무리가 된다면, 이후에 조금 주제가 어려워 지지만 이 기회가 아님 연결해 얘기하기 힘들다고 생각해서 MongoDB, ElasticSearch, Redis 같은 NoSQL이 왜 나오게 되었을까에 대한 개인적인 생각과 이 녀석들이 기존의 RDB와 어떻게 다르게 데이터를 저장하고 사용하는 지에 대해서 짧은 설명 들을 하며 마무리를 하려 한다. 

- Fin -