금요일의 정리 회의
중요한 데이터를 Google Sheets로 함께 관리해 본 팀이라면 익숙한 풍경이야. 월요일에는 두 사람이 동시에 행을 붙여 넣다가 한쪽 변경이 사라져. 화요일에는 누군가 열 이름을 바꿔서 뒤따르던 스크립트가 조용히 멈추고, 목요일에는 숫자 칸에 "N/A"가 들어가 SUM이 문자열 오류를 내. 금요일 결론은 시트를 “정리하자”는 것, 곧 수백 행을 다시 손보자는 말이야.
스프레드시트와 CSV가 커질수록 무너지는 까닭은 도구가 나빠서가 아니야. 운영 데이터에 꼭 필요한 세 가지 약속을 강제하도록 설계되지 않았기 때문이야. 두 쓰기 작업이 부딪힐 때 순서를 정하는 동시성 제어, 스키마를 어긴 행을 막는 데이터 정합성, 5천만 행 중 하나를 50ms 안에 찾게 하는 효율적인 질의가 필요해.
데이터베이스가 대신 지키는 것
PostgreSQL은 잘못된 행을 INSERT하는 순간 거절해. 동시에 시작한 두 트랜잭션이 모순된 결과를 모두 확정하지 못하게 조율하고, 색인은 처음부터 끝까지 훑는 선형 탐색을 로그 시간 검색으로 바꿔. 이 퀘스트에서 배울 ACID는 학술용 약자가 아니라 금요일 회의를 없애는 실제 장치야.
파일이 더 알맞을 때도 있어
CSV 같은 파일은 데이터를 내보내거나 공유하고 보관할 때, 또는 설정을 함께 배포할 때 아주 좋아. 하지만 둘 이상의 프로세스가 같은 내용을 쓰기 시작하거나 행을 조건별로 자주 찾아야 한다면 역할이 달라져. 쓰기 주체가 둘 이상이거나 질문이 단순 조회를 넘어가는 순간이 데이터베이스를 검토할 신호야.