이 도구는 무엇인가요?
테스트 데이터베이스에 초기 데이터를 넣거나, 스프레드시트에서 내보낸 데이터를 테이블에 옮기거나, 작은 데이터셋을 마이그레이션하는 작업은 대개 같은 지점에서 시작합니다. CSV 파일은 있는데 SQL이 필요한 상황이죠. 이 도구는 CSV를 파싱해서(헤더 행을 컬럼 이름으로 사용) 모든 데이터 행을 담은 하나의 INSERT INTO 문을 만들어주고, 이 문장은 데이터베이스 클라이언트에 바로 붙여넣을 수 있습니다.
문자열 값은 작은따옴표로 감싸고 내부에 있는 따옴표는 두 번 반복해 이스케이프합니다(그래서 O'Brien은 O''Brien이 됩니다). 이는 MySQL, PostgreSQL, SQLite가 공통으로 따르는 표준 이스케이프 규칙입니다. 빈 CSV 셀은 빈 문자열이 아니라 SQL 키워드 NULL로 씁니다. 이는 의도적인 선택입니다. 스프레드시트의 빈 셀은 대개 '빈 텍스트'가 아니라 '값 없음'을 의미하며, 대부분의 스키마가 이 경우 NULL을 기대하기 때문입니다.
값을 따옴표로 감쌀지 그대로 둘지는 실제 타입 추론이 아니라 단순한 휴리스틱으로 결정됩니다. 다듬은(trim된) 셀 값이 순수한 정수나 소수처럼 보이면(선택적으로 앞에 마이너스 부호가 붙어도) 따옴표 없이 씁니다. 그 외에는 모두 문자열로 따옴표를 붙이는데, 여기에는 앞자리가 0으로 시작하는 우편번호나 전화번호처럼 숫자와 비슷해 보이지만 실제로는 다른 문자가 섞인 값도 포함됩니다. 이렇게 하면 결과물이 정직해집니다. 작은 규모의 데이터 임포트에는 좋은 출발점이지만, 실행하기 전에 실제 테이블 스키마와 맞는지 데이터를 검증하는 작업을 대신해주진 않습니다.
출처: CSV 파싱은 RFC 4180을 따르며, 이는 공식적인 CSV 표준에 가장 가까운 문서입니다. 문자열 이스케이프를 위한 작은따옴표 두 번 반복은 MySQL, PostgreSQL, SQLite가 공통으로 채택한 관례입니다.
왜 사용해야 할까요?
- 커스텀 테이블 이름 — 대상 테이블을 한 번만 지정하면 모든 행이 그 테이블을 대상으로 합니다.
- 정확한 문자열 이스케이프 — 값 안의 작은따옴표를 두 번 반복해 SQL이 깨지거나 잘리지 않습니다.
- 예측 가능한 NULL 처리 — 빈 셀은 빈 문자열이 아니라 NULL이 되어, 대부분의 데이터베이스가 결측값을 구분하는 방식과 일치합니다.
- 일반적인 SQL 문법 — 여기서 생성되는 INSERT INTO ... VALUES ... 형태는 MySQL, PostgreSQL, SQLite에서 수정 없이 그대로 동작합니다.
- 100% 클라이언트 사이드 — 고객 기록이나 비즈니스 데이터가 포함될 수 있는 CSV 데이터는 브라우저 안에서 파싱·변환되며 어디로도 업로드되지 않습니다.
사용 방법
- 헤더 행이 포함된 CSV 데이터를 붙여넣으세요. 예: name,age\nAlice,30\nBob,25.
- 대상 테이블 이름을 입력하세요(기본값은 my_table입니다).
- "SQL 생성"을 클릭하세요.
- INSERT INTO 문을 복사하거나 .sql 파일로 다운로드한 뒤 데이터베이스에서 실행하세요.
예시
입력
name,age,city
Alice,30,
Bob,,NYC결과
INSERT INTO `my_table` (`name`, `age`, `city`)
VALUES
('Alice', 30, NULL),
('Bob', NULL, 'NYC');빈 셀이 빈 문자열이 아니라 NULL이 된 것과, 숫자처럼 보이는 age 값 30은 따옴표 없이 남고 모든 텍스트 값은 따옴표로 감싸진 것을 확인하세요.
실무 팁
- 로컬 테스트 데이터베이스 초기화: 스프레드시트에서 작은 샘플을 CSV로 내보내고 여기서 변환한 뒤, 개발용 데이터베이스에 INSERT 문을 실행하세요.
- 실제 테이블에 생성된 SQL을 실행하기 전에는 항상 컬럼 타입을 검토하세요. 이 도구는 실제 스키마가 아니라 단순한 휴리스틱으로 숫자와 텍스트를 구분하기 때문에, 특정 형식을 기대하는 정수 컬럼이라면 수동 조정이 필요할 수 있습니다.
- 수천 행 규모라면 이 도구가 생성하는 단일 다중 행 INSERT 문도 여전히 유효한 SQL이지만, 문장이 너무 크면 데이터베이스의 최대 패킷 크기 제한에 걸릴 수 있습니다. 그런 경우라면 CSV를 더 작은 배치로 나눠서 처리하세요.
왜 빈 문자열이 아니라 NULL인가
CSV-to-SQL 스크립트를 직접 작성할 때 흔히 하는 실수 중 하나가 빈 셀을 모두 빈 문자열 ''로 취급하는 것입니다. 이는 문법적으로는 유효한 SQL이지만, 대개는 의도한 것과 다른 결과를 낳습니다. 정수로 정의된 컬럼은 ''를 아예 거부하고, 텍스트 컬럼에서도 ''는 대부분의 스키마 설계와 리포팅 쿼리에서 '값을 모른다'와는 조용히 다른 의미를 가집니다(WHERE column IS NULL 조건은 빈 문자열과 매칭되지 않고, 반대의 경우도 마찬가지입니다). 빈 셀에 NULL을 쓰는 것이 대부분의 데이터베이스와 ORM이 기대하는 의미에 맞고, 일부 행에 결측값이 있는 숫자 컬럼에서 타입 오류가 나는 것도 피할 수 있습니다.
자주 묻는 질문
이 도구, 아무 SQL 데이터베이스에서나 다 되나요?
생성되는 문법 — 백틱으로 감싼 식별자, 작은따옴표로 감싼 문자열 값, 표준 INSERT INTO ... VALUES ... 형태 — 은 MySQL, PostgreSQL, SQLite에서 공통으로 사용됩니다. PostgreSQL은 원래 식별자에 백틱을 요구하지 않고 필요하면 큰따옴표를 쓰지만, 예약어와 충돌하는 특이한 컬럼명이 없는 한 백틱이 붙어 있어도 문제없이 동작합니다. 어떤 단일 공식 SQL 표준을 따른다기보다는, 가장 널리 쓰이는 데이터베이스들에서 수정 없이 통하는 문법을 쓴 것입니다.
빈 셀은 왜 빈 문자열 '' 대신 NULL이 되나요?
이건 의도적인 설계입니다. 실제 CSV 내보내기에서 빈 셀은 대개 값을 몰라서 비워둔 것이지, 문자 그대로 '빈 텍스트'를 의미하는 경우는 거의 없습니다. 대부분의 데이터베이스 스키마가 이런 경우 NULL을 기대합니다. 정말로 빈 문자열이 필요한 경우라면 생성된 SQL을 해당 부분만 직접 수정해야 합니다.
값에 따옴표를 붙일지 말지는 어떻게 결정되나요?
실제 타입 추론이 아니라 단순한 휴리스틱입니다. 다듬은 셀 값이 숫자(선택적으로 앞에 마이너스 부호 하나, 소수점은 최대 하나)로만 이루어져 있으면 따옴표 없이 숫자로 씁니다. 나머지는 모두 문자열로 따옴표가 붙습니다. 즉 00501 같은 우편번호나 전화번호는 텍스트로 처리될 수도 있고, 반대로 앞자리가 0으로 시작하는 값이라도 다른 문자가 섞여 있지 않으면 숫자로 파싱되기도 하니, 우편번호나 ID 같은 식별자는 SQL을 실행하기 전에 한번 더 확인하는 게 좋습니다.
제 데이터가 어딘가로 업로드되나요?
아니요. 파싱과 SQL 생성 모두 브라우저 안에서 자바스크립트로 처리되며 서버로 전송되지 않습니다. 그래서 내보낸 고객 정보나 비즈니스 데이터에도 안전하게 쓸 수 있습니다.
값에 쉼표나 따옴표가 섞인 CSV도 처리되나요?
네. 단순히 쉼표로 잘라내는 방식이 아니라, 쉼표·줄바꿈·따옴표로 둘러싸인 필드 안의 이중 따옴표까지 이해하는 제대로 된 따옴표 필드 파서를 사용합니다. 그래서 "Smith, John" 같은 필드도 두 컬럼으로 쪼개지지 않고 하나의 값으로 정확히 읽힙니다.