데이터베이스란? 엑셀·구글시트로 버티다 막히는 지점

데이터베이스는 데이터를 정해진 규칙대로 저장하고 여러 사람이 동시에 고쳐도 값이 깨지지 않게 붙잡아주는 소프트웨어다. 엑셀이나 구글시트도 데이터를 담기는 한다. 다만 규칙을 강제하지 않는다. 혼자 쓸 때는 멀쩡하다가 사람이 늘고 주문이 늘면 어느 날 갑자기 무너지는 이유다. 한계는 대개 용량이 차기 훨씬 전에, 사람이 겹치는 지점에서 먼저 온다.

핵심 요약

• 마이크로소프트 공식 문서에 따르면 엑셀 워크시트는 1,048,576행 × 16,384열이 상한이다. 대부분의 사업장은 이 숫자 근처에도 못 가고 다른 데서 막힌다.
• 구글시트는 파일당 1,000만 셀이 상한이다. 그 이상이면 구글은 엑셀에서 작업하라고 안내한다. 동시 편집은 100개 탭·기기까지만 허용된다.
• 진짜 한계는 행 수가 아니라 동시성·중복·형식이다. 두 사람이 같은 재고를 동시에 줄이면 시트는 마지막 저장만 남긴다. 데이터베이스는 순서를 정해 처리한다.
• 전환 시점은 누가 언제 무엇을 바꿨는지 추적해야 하느냐에서 갈린다. 여기에 그렇다고 답한다면 시트로는 오래 못 간다.

엑셀과 구글시트는 어디서 막히나

숫자부터 보자. 마이크로소프트 공식 문서는 엑셀 워크시트 한 장의 상한을 1,048,576행 × 16,384열, 셀 하나에 32,767자로 못 박아 뒀다. 구글 고객센터는 스프레드시트 한 파일이 1,000만 셀을 넘으면 엑셀에서 작업하라고 안내한다. 넉넉해 보인다. 이 벽에 부딪혀 데이터베이스로 옮기는 회사는 실제로 많지 않다.

먼저 무너지는 건 사람이 겹치는 자리다. 구글 고객센터에 따르면 문서 하나는 동시에 100개 탭 또는 기기에서만 편집된다. 그 수를 넘으면 소유자와 일부 편집자만 값을 고칠 수 있다. 100명까지 갈 것도 없다. 직원 셋이 같은 재고 시트를 열어두고 각자 수량을 고치면 시트는 마지막에 저장한 사람 값만 남긴다. 나머지 둘의 작업은 조용히 사라진다. 사라진 줄도 모른다는 게 더 큰 문제다.

형식도 새어 나간다. 전화번호 칸에 누군가 '010-1234-5678'을 넣고 다른 사람이 '01012345678'을 넣어도 시트는 아무 말이 없다. 나중에 문자를 일괄 발송할 때가 되어서야 절반이 실패한다. 시트는 무엇이든 받아준다. 규모가 커지면 그 관대함이 비용으로 돌아온다.

데이터베이스가 실제로 하는 일

데이터베이스의 핵심은 저장이 아니라 강제다. 표를 만들 때 '이 칸은 숫자만, 비워둘 수 없음, 중복 불가'처럼 규칙을 미리 못 박는다. 규칙을 어기는 값은 아예 들어오지 못한다. 시트가 사후에 고치는 쪽이라면 데이터베이스는 사전에 막는 쪽이다.

동시 처리도 마찬가지다. 두 사람이 같은 순간에 마지막 재고 한 개를 주문하면 데이터베이스는 두 요청에 순서를 매겨 하나만 성공시키고 나머지는 품절로 돌린다. 화면 뒤에서 이런 처리를 맡는 층이 백엔드다. 화면과 처리와 저장이 어떻게 나뉘는지는 웹사이트 구조 3층에서 이미 다뤘으니 여기서는 저장 층만 파고든다.

권한도 칸 단위로 쪼갠다. 아르바이트생에게는 주문 목록의 배송 상태만 열어주고 매출 합계는 숨기는 식이다. 시트에서 이걸 흉내 내려면 파일을 쪼개거나 시트를 보호해야 한다. 쪼갠 순간 같은 데이터가 두 벌이 되고 두 벌은 반드시 어긋난다.

엑셀과 데이터베이스, 항목별 비교

항목	엑셀·구글시트	데이터베이스
값 규칙	사람이 조심해서 지킨다	어기는 값은 저장 자체가 거부된다
동시 수정	마지막 저장이 앞선 작업을 덮는다	순서를 매겨 하나씩 반영한다
변경 이력	누가 언제 고쳤는지 추적이 흐릿하다	기록을 남기도록 설계할 수 있다
권한	파일 단위로 나뉜다	표·칸 단위로 나뉜다
시작 비용	사실상 없다	개발과 운영이 붙는다
잘 맞는 일	혼자 계산하고 한 번 보고 끝나는 일	여럿이 오래 쌓고 계속 고치는 일

표를 한 줄로 줄이면 이렇다. 시트는 계산기에 가깝고 데이터베이스는 규칙이 박힌 장부에 가깝다. 계산은 시트가 빠르고 싸다. 대신 여러 사람이 오래 쌓아 올리는 기록은 장부 쪽이 안전하다. 어느 한쪽이 우월한 게 아니라 쓰는 자리가 다르다.

옮겨야 할 때를 가르는 다섯 가지 질문

1. 같은 파일을 두 사람 이상이 동시에 고치는가. 그렇다면 이미 값이 덮이고 있을 공산이 크다.
2. 누가 언제 이 값을 바꿨는지 나중에 따져야 하는 일이 있는가. 재고·정산·회원 정보라면 대개 그렇다.
3. 같은 정보가 두 파일에 나뉘어 있고 한쪽만 고치는 실수가 반복되는가.
4. 고객이나 직원이 웹·앱 화면에서 직접 값을 넣게 할 계획인가. 시트를 화면 뒤에 두면 권한과 속도가 곧 문제가 된다.
5. 파일이 무거워져 여는 데만 한참 걸리거나 수식이 늘어져 계산이 밀리는가.

다섯 중 둘 이상에 그렇다고 답하면 옮길 때가 됐다는 신호로 본다. 다섯 개 모두 아니라면 시트로 계속 가도 된다. 혼자 쓰는 견적표나 월말에 한 번 정리하는 장부까지 데이터베이스로 옮길 이유는 없다. 옮기는 순간 개발과 운영 비용이 붙는데, 그 비용은 대개 사람이 겹치기 시작할 때부터 값을 한다.

업체와 이야기할 때는 이렇게 물어보면 된다. "지금 시트에 쌓인 데이터를 그대로 옮길 수 있나요? 옮긴 뒤에도 직원들이 지금처럼 표로 볼 수 있는 화면을 주시나요?" 첫 질문은 이관 비용을, 둘째 질문은 현업의 저항을 줄인다. 데이터베이스로 갈아탄 뒤 직원들이 다시 시트를 쓰기 시작하는 사고가 여기서 갈린다.

자주 하는 오해와 결정 기준

첫째 오해, "데이터가 많아지면 데이터베이스로 옮긴다." 양이 아니라 동시성이 기준이다. 행 1만 개짜리를 넷이 함께 고치는 쪽이 행 50만 개짜리를 혼자 보는 쪽보다 훨씬 위태롭다.

둘째 오해, "엑셀도 잘 짜면 데이터베이스처럼 쓴다." 수식과 매크로로 형식은 흉내 낸다. 동시에 들어온 두 수정 사이에 순서를 매기는 일은 흉내가 안 된다. 그 지점이 갈림길이다.

셋째 오해, "데이터베이스를 쓰면 시트를 버려야 한다." 대부분은 함께 쓴다. 원본은 데이터베이스에 두고 분석이나 보고서는 그때그때 시트로 뽑아 본다. 원본이 하나라는 사실만 지키면 된다.

가상 예시를 들어본다. 소형 가구를 파는 B사는 재고와 주문을 구글시트 두 장으로 관리했다. 주문이 하루 열 건일 때는 문제가 없었다. 스무 건이 되고 직원이 셋으로 늘자 같은 상품을 두 번 팔아 한 명에게 취소 전화를 거는 일이 한 달에 몇 번씩 생겼다. 재고를 데이터베이스로 옮기고 주문 화면에서 수량을 차감하도록 바꾸자 중복 판매가 멈췄다. 사장이 보던 매출 시트는 그대로 뒀다. 원본만 옮겼다.

내 서비스가 어느 유형에 속하는지부터 가늠하고 싶다면 웹사이트·웹앱·시스템 차이를 먼저 보자. 시트에서 옮길 시점이 맞는지 판단이 서지 않으면 문의로 지금 상황을 알려주면 된다.