Bubble.io CSV 가져오기 오류 해결｜데이터 유실·중복을 막는 파싱 가이드

2026년 9월 27일 읽는 시간 약 18분

Bubble.io에서 운영 데이터를 옮기거나 대량으로 수정할 때 가장 자주 사용하는 형식이 CSV입니다. 엑셀처럼 행과 열로 구성되어 있어 다루기 쉬워 보이지만, 실제 가져오기 과정에서는 문자 인코딩, 구분자, 날짜 형식, 빈 셀, 관계형 데이터 연결 방식이 조금만 달라도 값이 누락되거나 다른 레코드와 연결될 수 있습니다.

특히 운영 중인 앱에서 CSV를 잘못 가져오면 단순히 몇 개의 값이 비는 수준에 그치지 않습니다. 기존 데이터를 덮어쓰거나 중복 레코드를 생성하고, 사용자와 주문처럼 서로 연결된 데이터의 관계가 끊어질 수도 있습니다. 따라서 CSV 작업은 파일을 다운로드하고 다시 업로드하는 단순한 절차가 아니라, 백업→정제→파싱 검증→소량 테스트→본 작업→사후 대조의 순서로 진행해야 합니다.

이 글에서는 Bubble.io의 데이터 내보내기와 가져오기 과정에서 발생할 수 있는 대표적인 오류를 살펴보고, 실제 운영 데이터의 유실 가능성을 낮추는 CSV 파싱 방법을 단계별로 정리합니다.

이 글의 핵심: 원본 CSV는 수정하지 않고 보관하며, Development 환경에서 10~20행을 먼저 검증한 뒤 Live 데이터에 적용해야 합니다.

CSV 파싱 오류가 데이터 유실로 이어지는 이유

CSV는 구조가 단순하지만 데이터 타입에 대한 정보를 별도로 저장하지 않습니다. 파일 안의 2026-09-22, 00125, yes는 모두 텍스트처럼 기록될 수 있고, 이를 날짜·숫자·참/거짓 중 무엇으로 해석할지는 CSV를 읽는 프로그램과 가져오기 설정에 따라 달라집니다.

예를 들어 상품 코드 00125를 스프레드시트에서 열면 숫자 125로 바뀔 수 있습니다. 전화번호의 앞자리 0이 사라지거나, 긴 식별자가 지수 표기법으로 변환되는 현상도 같은 원리입니다. 주소나 상품 설명에 포함된 쉼표를 열 구분자로 잘못 해석하면 이후 데이터가 한 칸씩 밀릴 수도 있습니다.

따라서 CSV 유실 방지는 단순히 행 개수만 확인해서는 부족합니다. 다음 네 가지가 모두 일치해야 합니다.

파일의 문자 인코딩과 구분자
CSV 열과 Bubble 필드의 매핑
각 값의 데이터 타입과 표현 방식
가져오기 전후의 레코드 수와 핵심 값

작업 전에 반드시 준비할 3개의 파일

안전한 작업을 위해서는 하나의 CSV만 수정해서 사용하지 않는 것이 좋습니다. 다음과 같이 파일을 분리하면 원본 훼손과 작업 혼선을 줄일 수 있습니다.

backup_original.csv: Bubble에서 내려받은 원본으로, 절대 수정하지 않습니다.
working_cleaned.csv: 인코딩과 값 형식을 정리하는 작업용 파일입니다.
import_final.csv: 검증이 끝난 실제 가져오기용 파일입니다.

파일명에는 작업 날짜와 데이터 타입을 함께 기록하는 편이 좋습니다. 예를 들어 20260922_Order_backup_original.csv처럼 저장하면 여러 번 작업한 뒤에도 어떤 파일이 원본인지 바로 구분할 수 있습니다.

또한 Development와 Live 데이터베이스는 서로 분리되어 있으므로 현재 어느 버전의 데이터를 보고 있는지 먼저 확인해야 합니다. 테스트 파일을 Live에 올리거나, Live 백업이라고 생각한 파일이 Development 데이터였던 실수를 예방하기 위한 기본 단계입니다.

1단계: Bubble 데이터 내보내기 전 점검

Bubble 편집기의 Data → App data에서 대상 데이터 타입을 선택한 뒤 현재 보기에 표시된 데이터를 CSV로 내보낼 수 있습니다. 이때 화면의 필터나 표시 열에 따라 필요한 값이 빠지지 않았는지 확인합니다.

내보내기 전에 아래 내용을 별도로 기록해 두면 가져오기 후 대조가 쉬워집니다.

점검 항목	기록할 내용
데이터베이스 환경	Development 또는 Live
데이터 타입	User, Product, Order 등
전체 레코드 수	내보내기 전 화면 기준 개수
핵심 식별 필드	이메일, 주문번호, 외부 시스템 ID 등
빈 값 허용 필드	메모, 보조 주소, 선택 옵션 등
관계형 필드	User, Product, Category 연결 여부
작업 시각	백업 및 가져오기 실행 시간

대용량 데이터는 브라우저에서 생성되는 CSV 내보내기가 불안정하거나 오래 걸릴 수 있습니다. 데이터가 매우 많다면 한 번에 무리하게 처리하기보다 범위를 나누거나 Bubble Data API를 이용한 별도 백업 방식을 검토하는 것이 안전합니다.

2단계: UTF-8 인코딩으로 한글 깨짐 방지

한글이 포함된 CSV에서 흔한 문제는 글자가 ??? 또는 깨진 문자로 보이는 현상입니다. 운영체제와 스프레드시트 프로그램이 서로 다른 기본 인코딩을 사용하면 발생할 수 있습니다.

가져오기용 파일은 가능하면 UTF-8 CSV로 저장합니다. 엑셀을 사용한다면 일반 CSV가 아니라 CSV UTF-8(쉼표로 분리) 형식을 선택합니다. 저장 후에는 파일을 다시 열어 다음 항목을 확인합니다.

한글 이름과 주소가 정상적으로 보이는가
특수문자와 이모지가 손상되지 않았는가
줄바꿈이 포함된 설명이 하나의 셀 안에 유지되는가
열 제목의 앞뒤에 보이지 않는 공백이 붙지 않았는가

한 번 깨진 글자를 그대로 저장하면 원래 문자를 복구하기 어려울 수 있습니다. 그래서 인코딩 문제가 보이면 수정한 파일을 덮어쓰지 말고, 보관해 둔 원본에서 다시 작업해야 합니다.

3단계: 열 구분자와 따옴표 확인

CSV에서 쉼표는 일반적으로 열을 나누는 구분자입니다. 하지만 주소, 금액 설명, 상품명에도 쉼표가 들어갈 수 있습니다.

다음 행을 살펴보겠습니다.

name,address,status
김민지,"서울시 강남구 테헤란로 1, 5층",active

주소 전체가 큰따옴표로 감싸져 있으므로 중간의 쉼표는 데이터로 유지됩니다. 반대로 따옴표가 빠지면 주소 뒤의 5층이 새로운 열로 해석될 수 있습니다.

Bubble 가져오기 화면에서는 쉼표, 세미콜론, 탭, 파이프 등의 구분자를 선택할 수 있습니다. 본문 텍스트에 쉼표가 매우 많다면 탭이나 파이프를 주 구분자로 사용하는 방식도 고려할 수 있습니다. 단, 목록형 필드의 내부 구분자는 주 구분자와 달라야 합니다.

안전한 파싱을 위해 다음 규칙을 적용합니다.

셀 내부에 쉼표·줄바꿈·큰따옴표가 있으면 해당 셀을 큰따옴표로 감쌉니다.
셀 안의 큰따옴표는 ""처럼 두 번 기록합니다.
모든 행의 열 개수가 헤더의 열 개수와 같은지 확인합니다.
마지막 열 뒤에 불필요한 구분자가 붙지 않았는지 확인합니다.

4단계: Bubble 필드 타입별 값 정규화

CSV를 가져오기 전에 각 열을 Bubble의 실제 필드 타입에 맞춰 정리해야 합니다.

Text 필드

상품 코드, 우편번호, 전화번호처럼 계산하지 않는 값은 숫자처럼 보여도 Text로 다루는 것이 안전합니다. 앞자리 0이 중요한 값은 특히 주의해야 합니다.

안전한 값: 00125
변형된 값: 125

스프레드시트에서는 해당 열을 텍스트 형식으로 먼저 지정한 뒤 값을 붙여넣는 것이 좋습니다.

Number 필드

천 단위 쉼표, 통화 기호, 단위 문자를 제거합니다. ₩12,000원이 아니라 12000처럼 숫자만 남깁니다. 소수점 기호도 가져오기 환경에서 인식할 수 있는 형태로 통일합니다.

Yes/No 필드

Bubble의 yes/no 필드는 true/false, Y/N, 1/0이 아니라 yes/no 형식으로 통일하는 것이 안전합니다. 대소문자와 공백이 섞이지 않도록 전체 열을 정리합니다.

Date 필드

날짜는 지역 설정에 따라 월과 일이 뒤바뀔 위험이 있습니다. 09/10/2026처럼 해석이 모호한 표기보다 월 이름을 포함하거나, 테스트를 통해 Bubble이 확실히 인식하는 한 가지 형식으로 통일합니다.

예시: Sep 22, 2026 3:30 PM

모든 행에서 시간대와 시·분 포함 여부도 동일하게 맞춥니다. 날짜 범위나 기간은 일반 날짜와 요구 형식이 다르므로 별도로 검증해야 합니다.

File·Image 필드

파일과 이미지 필드에는 파일 자체가 아니라 접근 가능한 파일 URL을 넣습니다. URL에 공백이 있거나 접근 권한이 제한되어 있으면 가져온 뒤 이미지가 표시되지 않을 수 있으므로 표본 URL을 브라우저에서 직접 열어 확인합니다.

List 필드

목록 필드는 CSV 전체의 열 구분자와 목록 내부의 구분자를 구별해야 합니다. 예를 들어 열 구분자가 쉼표라면 목록 내부에는 세미콜론을 사용할 수 있습니다.

[노코드; 자동화; 데이터베이스]

Bubble에서 내보낸 목록 표현과 가져오기에서 요구하는 표현이 다를 수 있으므로, 전체 파일을 올리기 전에 1개의 레코드로 반드시 재가져오기 테스트를 진행합니다.

5단계: 관계형 데이터는 부모부터 가져오기

User와 Order, Category와 Product처럼 서로 연결된 데이터는 가져오는 순서가 중요합니다. 주문 데이터가 사용자를 참조하려면 해당 사용자가 데이터베이스에 먼저 존재해야 합니다.

권장 순서는 다음과 같습니다.

독립적으로 존재하는 부모 데이터 가져오기
부모 데이터의 Bubble Unique ID 또는 중복되지 않는 외부 키 확보
자식 CSV에 연결용 키 입력
관계형 필드의 매핑 방식 확인
자식 데이터 소량 가져오기
실제 연결 여부를 Bubble에서 직접 확인

관계형 데이터를 이름으로 연결하면 동명이인이나 중복 상품명 때문에 잘못 매칭될 수 있습니다. 이메일, 주문번호, 외부 ID처럼 유일성이 보장된 값을 사용해야 합니다. Bubble의 custom data type을 직접 연결할 때는 참조 대상의 Unique ID가 필요한 경우가 있으므로, 파일을 준비하기 전에 매핑 방식을 먼저 확인합니다.

두 개 이상의 레코드가 같은 매칭 값을 가지고 있다면 관계 설정이 모호해집니다. 가져오기 전에 스프레드시트의 중복 제거 기능이나 COUNTIF 등을 이용해 연결용 키의 중복을 검사해야 합니다.

6단계: 빈 셀과 덮어쓰기 옵션 구분

CSV에서 빈 셀은 단순한 공백처럼 보이지만 수정 작업에서는 의미가 크게 달라집니다.

빈 셀을 무시: 기존 값을 유지합니다.
빈 값으로 덮어쓰기: 기존 값을 삭제하고 비웁니다.
매핑하지 않은 열: 해당 필드를 변경하지 않습니다.

기존 레코드를 CSV로 일괄 수정할 때 Overwrite data when the field value is empty와 같은 빈 값 덮어쓰기 설정을 잘못 선택하면 정상 데이터가 대량으로 사라질 수 있습니다. 값을 지울 목적이 아니라면 빈 셀 덮어쓰기 옵션을 사용하지 않는 편이 안전합니다.

공백 한 칸이 들어간 셀은 완전히 빈 셀과 다르게 처리될 수 있습니다. TRIM 기능을 이용해 앞뒤 공백을 제거하고, 실제 빈 값과 의도적으로 공백을 넣은 값을 구분합니다.

7단계: 새 데이터 추가와 기존 데이터 수정 구분

가져오기 작업의 목적이 신규 레코드 생성인지 기존 레코드 수정인지 명확히 해야 합니다. 동일한 CSV를 Upload 방식으로 반복 실행하면 같은 데이터가 중복 생성될 수 있습니다.

기존 데이터를 일괄 수정하려면 대상 레코드를 정확히 지정할 수 있는 Unique ID 열이 필요합니다. 반면 외부 시스템에서 새 데이터를 추가할 때는 자체적인 external_id 필드를 만들어 중복 여부를 먼저 검사하는 방식이 좋습니다.

예를 들어 주문번호가 ORD-2026-0001인 행을 다시 가져오기 전에 Bubble에서 같은 주문번호가 존재하는지 확인합니다. 존재하면 수정 대상으로 보내고, 없으면 신규 생성 대상으로 분리합니다. 이 과정을 생략하면 같은 주문이 두 번 생성되고 결제·재고·통계 데이터까지 왜곡될 수 있습니다.

8단계: 전체 업로드 전에 10~20행으로 테스트

Bubble의 Validate data 기능은 유용하지만, 실제 운영 데이터 전체의 의미까지 보장하는 것은 아닙니다. 검증이 통과해도 잘못된 열을 다른 필드에 연결했거나 날짜가 다른 기준으로 해석될 수 있습니다.

따라서 다음과 같은 경계값이 포함된 테스트 파일을 별도로 만듭니다.

한글과 영문이 함께 포함된 행
값이 비어 있는 행
쉼표와 줄바꿈이 포함된 긴 텍스트
앞자리가 0인 코드
소수점이 있는 숫자
날짜와 시간이 포함된 값
여러 항목을 가진 목록
관계형 데이터가 연결된 행

Development 데이터베이스에 10~20행을 먼저 가져온 뒤 각 필드를 직접 확인합니다. 레코드 수만 보지 말고 검색·필터·워크플로우에서 정상적으로 사용되는지도 점검해야 합니다.

9단계: 본 작업 후 데이터 대조

가져오기가 완료되었다는 메시지만으로 작업을 종료하면 안 됩니다. 최소한 다음 항목을 원본 파일과 비교해야 합니다.

검증 항목	확인 방법
레코드 수	CSV 데이터 행 수와 Bubble 생성·수정 건수 비교
필수값 누락	이메일·주문번호·상태가 비어 있는 레코드 검색
중복	외부 ID나 주문번호 기준 그룹화·검색
한글	이름·주소·설명의 표본 확인
날짜	과거·현재·미래 날짜를 각각 표본 확인
숫자	합계·최솟값·최댓값 비교
관계	User–Order, Category–Product 연결 확인
파일 URL	이미지와 첨부파일 실제 접근 확인

가능하다면 가져오기 전후에 핵심 숫자의 합계를 비교합니다. 예를 들어 주문 데이터라면 레코드 수뿐 아니라 전체 주문금액 합계도 확인합니다. 행 수가 같아도 특정 금액이 문자열로 들어가거나 소수점이 바뀌면 합계에서 차이가 드러납니다.

실무용 CSV 사전 검증 체크리스트

아래 항목을 모두 확인한 뒤 본 작업을 진행합니다.

원본 CSV를 별도 파일로 보관했다.
Development와 Live 환경을 구분했다.
UTF-8 인코딩으로 저장했다.
헤더 이름과 Bubble 필드 매핑을 확인했다.
모든 행의 열 개수가 같다.
코드·우편번호·전화번호의 앞자리 0이 유지된다.
Number 필드에서 쉼표·통화 기호·단위를 제거했다.
Yes/No 값을 yes와 no로 통일했다.
날짜 형식과 시간대를 통일했다.
CSV 구분자와 List 구분자를 다르게 설정했다.
연결용 키에 중복이 없는지 확인했다.
빈 셀 덮어쓰기 옵션의 영향을 확인했다.
10~20행으로 테스트 가져오기를 완료했다.
가져오기 전후의 레코드 수와 핵심 합계를 비교했다.
오류 발생 시 되돌릴 백업과 작업 기록이 있다.

자주 발생하는 오류와 해결 방법

한글이 깨져서 들어옵니다

파일을 UTF-8 CSV로 다시 저장하고, 원본 단계에서 이미 글자가 깨지지 않았는지 확인합니다. 깨진 파일을 재저장하는 것만으로는 복원되지 않을 수 있습니다.

데이터가 오른쪽 열로 밀립니다

본문의 쉼표, 줄바꿈, 큰따옴표가 올바르게 이스케이프되지 않았을 가능성이 큽니다. 문제가 있는 행의 열 개수를 헤더와 비교하고, 텍스트 셀을 큰따옴표로 감쌉니다.

날짜가 하루 전이나 다음 날로 표시됩니다

CSV의 시간대와 Bubble에서 표시하는 시간대가 다를 수 있습니다. 날짜만 필요한 데이터인지 정확한 시각이 필요한 데이터인지 먼저 구분하고, 테스트 레코드로 저장값과 화면 표시값을 각각 확인합니다.

관계형 데이터가 연결되지 않습니다

참조 대상 데이터가 먼저 존재하는지, 매칭에 사용한 값이 유일한지 확인합니다. 이름처럼 중복될 수 있는 값보다 Unique ID 또는 별도의 외부 ID를 사용하는 편이 안전합니다.

같은 데이터가 여러 번 생성됩니다

신규 Upload를 반복했을 가능성이 있습니다. 가져오기 전에 외부 ID를 기준으로 기존 데이터 존재 여부를 검사하고, 신규 생성 파일과 기존 수정 파일을 분리합니다.

진행률이 0%에서 움직이지 않습니다

CSV 가져오기는 백그라운드 작업 처리 순서와 앱의 작업량에 영향을 받을 수 있습니다. 같은 파일을 즉시 반복 업로드하면 중복 위험이 있으므로 완료 또는 오류 알림을 먼저 확인합니다. 한 앱에서는 가져오기나 수정 작업을 동시에 여러 개 실행하지 않는 것이 좋습니다.

대용량 CSV는 언제 Data API를 고려해야 할까?

수백 또는 수천 행을 가끔 옮기는 작업이라면 Bubble의 기본 CSV 기능으로 충분할 수 있습니다. 하지만 데이터가 매우 많거나 정기적으로 동기화해야 한다면 수동 CSV 방식은 점점 위험해집니다.

다음 조건에 해당하면 Data API와 자동화 스크립트를 검토할 수 있습니다.

매일 또는 매주 외부 시스템과 데이터를 동기화해야 하는 경우
실패한 행만 다시 처리해야 하는 경우
중복 방지를 위한 upsert 로직이 필요한 경우
처리 결과와 오류 로그를 행 단위로 남겨야 하는 경우
대량 데이터를 여러 배치로 나눠야 하는 경우

자동화에서는 한 번에 전체를 보내기보다 일정한 배치 크기로 나누고, 각 레코드에 외부 고유 키를 부여해야 합니다. 성공·실패 응답을 저장하고 재시도 횟수에 제한을 두어야 동일 데이터가 반복 생성되는 문제를 줄일 수 있습니다.

마무리

Bubble.io의 CSV 기능은 데이터를 빠르게 이전하고 수정할 수 있는 유용한 도구입니다. 그러나 CSV 자체에는 필드 타입과 관계 정보가 충분히 담기지 않기 때문에, 파일을 그대로 업로드하는 것만으로 데이터의 안전성이 보장되지는 않습니다.

가장 중요한 원칙은 세 가지입니다. 원본을 보존하고, 소량으로 먼저 검증하며, 작업 전후 결과를 수치로 대조하는 것입니다. 여기에 UTF-8 인코딩, 명확한 구분자, 필드 타입별 정규화, 관계형 데이터의 가져오기 순서를 함께 관리하면 한글 깨짐·값 누락·중복·연결 오류를 크게 줄일 수 있습니다.

운영 데이터는 한 번 잘못 덮어쓰면 복구 비용이 훨씬 커집니다. CSV 작업을 단순 업로드가 아닌 작은 데이터 마이그레이션으로 보고 체크리스트에 따라 진행하는 것이 가장 확실한 유실 방지 방법입니다.