요즘은 AI 도구를 활용해 테이블 생성문이나 SQL 쿼리를 빠르게 만들 수 있습니다. 덕분에 작은 웹서비스나 업무 자동화 도구를 개발할 때도 예전보다 훨씬 빠르게 기능을 붙일 수 있게 됐습니다.
다만 데이터베이스는 코드처럼 당장 실행된다는 이유만으로 안심하기 어렵습니다. 처음에는 별문제 없이 돌아가는 것처럼 보여도, 데이터가 쌓이기 시작하면 결과가 중복되거나 조회 속도가 느려질 수 있습니다. 서로 맞지 않는 값이 저장되는 문제도 뒤늦게 드러나곤 합니다.
특히 바이브 코딩처럼 AI와 대화하면서 서비스를 만들어가는 방식에서는 데이터베이스에 대한 기본 이해가 더욱 중요합니다. AI가 SQL 문법을 작성해줄 수는 있지만, 어떤 데이터를 어떤 테이블에 나눠 담을지, 테이블끼리 어떤 관계로 연결할지, 조회 결과가 올바른지는 결국 사람이 판단해야 하기 때문입니다.
SQL 문법보다 먼저 살펴봐야 할 것은 테이블 구성입니다
데이터베이스를 처음 배울 때는 보통 SELECT, WHERE, JOIN 같은 SQL 문법부터 접하게 됩니다. 물론 쿼리를 작성하려면 문법도 알아야 합니다. 하지만 실제 서비스 데이터를 다루려면 그보다 먼저 테이블이 어떻게 나뉘어 있는지 이해할 필요가 있습니다.
쇼핑몰 서비스를 예로 들어보겠습니다. 회원, 상품, 주문, 주문상세, 결제 정보를 하나의 테이블에 모두 넣으면 처음에는 간단해 보일 수 있습니다. 하지만 주문 하나에 여러 상품이 포함되거나, 회원 정보가 변경되거나, 결제 상태를 별도로 관리해야 하는 순간부터 데이터가 빠르게 복잡해집니다.
이런 문제를 줄이기 위해 데이터의 성격에 따라 테이블을 나누고, 각 테이블을 기본키와 외래키로 연결합니다. 기본키는 각 행을 구분하는 값이고, 외래키는 다른 테이블의 데이터와 관계를 맺을 때 사용하는 값입니다. 이 개념을 이해하지 못하면 AI가 만들어준 테이블 설계가 실제 서비스에 적합한지 판단하기가 쉽지 않습니다.
JOIN 결과가 예상과 다르다면 관계부터 확인해야 합니다
SQL을 작성하다 보면 JOIN을 적용한 뒤 결과 행 수가 예상보다 크게 늘어나는 일이 있습니다. 실제 매출보다 합계가 크게 나오거나, 하나의 주문이 여러 건으로 중복 집계되는 경우가 대표적입니다.
겉으로는 쿼리 문법이 잘못된 것처럼 보이지만, 테이블 사이의 관계를 잘못 이해해 발생하는 경우도 많습니다.
회원과 주문은 일반적으로 1:N 관계를 가집니다. 회원 한 명이 여러 주문을 만들 수 있기 때문입니다. 주문과 상품은 주문상세 같은 중간 테이블을 두어 N:M 관계로 표현하는 경우가 많습니다. 이런 연결 방식을 확인하지 않은 채 JOIN을 작성하면 같은 주문이나 금액이 여러 번 계산될 수 있습니다.
AI가 작성한 JOIN 쿼리를 검토할 때도 실행 여부만 확인해서는 부족합니다. 어떤 테이블이 어떤 컬럼을 기준으로 연결됐는지 살펴보고, 결과 행 수와 집계 기준이 적절한지도 함께 봐야 합니다. NULL이 어떻게 처리되는지, 중복 데이터가 생기지는 않는지도 확인하는 습관이 필요합니다.
인덱스는 실제 조회 방식을 보고 판단해야 합니다
데이터가 많지 않을 때는 대부분의 쿼리가 빠르게 실행됩니다. 그래서 개발 초기에는 성능 문제가 잘 드러나지 않습니다. 하지만 회원과 주문, 로그 데이터가 계속 쌓이면 이전과 같은 쿼리도 갑자기 느려질 수 있습니다.
이럴 때 인덱스를 많이 만들면 해결될 것처럼 느껴지지만, 기준 없이 추가한 인덱스는 오히려 쓰기 성능을 떨어뜨리거나 관리 부담을 늘릴 수 있습니다. 보통 WHERE 조건에 자주 사용되는 컬럼, JOIN 기준이 되는 컬럼, 정렬이나 범위 검색에 활용되는 컬럼을 중심으로 인덱스 후보를 살펴봅니다.
인덱스를 추가한 뒤에는 EXPLAIN을 이용해 실제 실행 계획도 확인해야 합니다. AI가 특정 컬럼에 인덱스를 만들라고 제안하더라도, 서비스에서 어떤 방식으로 데이터를 조회하는지와 실제로 인덱스가 사용되는지를 함께 봐야 현실적인 판단을 내릴 수 있습니다.
트랜잭션은 여러 데이터가 어긋나지 않도록 지켜줍니다
서비스에서는 여러 작업이 하나의 흐름으로 이어지는 경우가 많습니다. 주문을 생성하면서 재고를 줄이고, 결제 기록을 남기고, 포인트를 차감하는 상황을 떠올려볼 수 있습니다.
이 과정에서 일부 작업만 성공하고 나머지가 실패하면 데이터가 서로 맞지 않게 됩니다. 주문 기록은 남았는데 재고가 줄지 않거나, 결제는 완료됐지만 포인트가 차감되지 않는 문제가 생길 수 있습니다.
트랜잭션은 이렇게 연결된 작업을 하나의 단위로 묶어 처리합니다. 모든 작업이 정상적으로 끝나면 COMMIT으로 반영하고, 중간에 문제가 발생하면 ROLLBACK으로 이전 상태로 되돌립니다.
AI가 관련 코드를 작성해주더라도 어떤 작업들을 하나의 트랜잭션으로 묶을지는 서비스 흐름을 이해하는 사람이 정해야 합니다. 이런 이유로 데이터베이스 기초는 개발자에게만 필요한 지식이 아닙니다. 서비스를 직접 만들거나 데이터의 흐름을 설계하는 사람에게도 중요한 판단 기준이 됩니다.
AI 시대의 데이터베이스 학습은 검증하는 힘에 가깝습니다
모든 SQL 문법을 처음부터 외우는 방식은 이제 예전만큼 효율적이지 않을 수 있습니다. 필요한 문법은 AI의 도움을 받아 빠르게 찾을 수 있기 때문입니다.
대신 테이블 구성을 읽고, 데이터 사이의 관계를 파악하고, 쿼리 결과를 직접 검산하는 능력이 더 중요해졌습니다. 조회 속도에 문제가 없는지, 여러 데이터가 서로 일관되게 유지되는지도 확인할 수 있어야 합니다.
AI가 초안을 만들어주면 사람은 요구사항을 더 구체적으로 전달하고, 작은 데이터를 넣어 직접 실행해본 뒤 예상한 결과와 맞는지 살펴봐야 합니다. 테이블, 컬럼, 데이터 타입, PK, FK, ERD, JOIN, GROUP BY, 인덱스, 트랜잭션 같은 개념은 이 검증 과정에서 계속 사용되는 기본 도구입니다.
데이터베이스를 전문 운영자 수준으로 깊게 알아야 한다는 의미는 아닙니다. 다만 AI로 만든 서비스가 실제 데이터가 쌓인 뒤에도 안정적으로 동작하려면, 최소한 테이블과 관계를 읽고 결과가 맞는지 판단할 수 있는 기준은 갖춰두는 편이 좋습니다.
더 깊게 배워보고 싶다면
이 글에서 다룬 테이블 구조, 관계 설계, SQL 검산, 인덱스와 트랜잭션을 MySQL과 DBeaver 실습 흐름으로 익히고 싶다면 아래 강의도 참고해볼 만합니다. https://inf.run/zJt18
바이브 코딩 시대의 데이터베이스: AI로 서비스 만들 때 꼭 알아야 할 최소 지식| 테크타니 – 인프런 강의
이 링크를 통해 수강하면 작성자가 소정의 수수료를 받을 수 있습니다.
