PostgreSQL과 친해지는 과정 (9)

문과생 유목이의 개발일지 · 9화

서버는 떴는데 저장할 곳이 비어 있었다. 이제 예약 데이터를 어떤 모양으로 담을지 정해야 했다.

사실 처음엔 "그냥 파일에 저장하면 안 되나" 싶었다. 엑셀도 결국 파일이었으니까.

그런데 엑셀이 왜 무너졌는지 떠올려보니 답이 나왔다. 두 사람이 동시에 쓰면 하나가 사라지고, 잘못된 입력을 막지 못하고, 기록이 남지 않았다. 데이터베이스는 정확히 이 세 가지를 해주는 물건이다.

같은 줄을 두 사람이 동시에 건드리면 순서대로 처리한다. 규칙에 어긋나면 거절한다. 누가 언제 바꿨는지 남긴다. 엑셀에 없던 게 전부 기본으로 들어 있었다.

종이에 다시 적었다. 예약 한 건을 설명하려면 무엇이 있어야 하는가.

여기서 2화의 결정이 효과를 봤다. 자원을 따로 떼어서 관리하니, 회의실이든 차량이든 같은 표에 들어갔다. 자원을 하나 늘리는 건 줄 하나 추가하는 일이 됐다.

가장 오래 고민한 게 취소 처리였다.

처음엔 당연히 지우는 거라고 생각했다. 취소된 예약을 왜 들고 있나 싶었다.

그런데 엑셀 때가 떠올랐다. 누가 언제 지웠는지 몰라서 전 부서에 메신저를 돌렸던 날. 지워버리면 그때로 돌아가는 것이었다.

그래서 지우지 않고 상태를 바꾸는 방식으로 정했다. 취소된 예약도 줄은 그대로 남고, 상태 칸만 "취소"로 바뀐다. 누가 언제 왜 취소했는지가 남는다.

이 결정 하나로 나중에 꽤 많은 게 편해졌다. 잘못 취소한 예약을 되살리는 기능도, 월별 사용 통계도 전부 여기서 나왔다.

"2026년 11월 3일 오후 2시"를 어떻게 저장할 것인가. 글자로 적으면 될 것 같았는데, 그러면 두 예약의 시간을 비교할 수가 없다. 글자끼리는 크고 작음을 따질 수 없으니까.

날짜·시간 전용 형식으로 저장하기로 했다. 그리고 시간대 설정에서 한 번 더 걸렸다. 서버 컨테이너는 세계 표준시로 돌아가고 있어서, 한국 시간 오후 2시를 저장하면 오전 5시로 들어갔다.

이건 설정 한 줄로 해결했지만, 시간 문제는 여기서 끝나지 않는다. 한참 뒤에 "안내 문자가 안 왔다"는 연락을 받게 되는데, 그 원인도 결국 시간 계산이었다.

데이터베이스에 예약 한 건을 직접 넣어보고, 그걸 다시 불러오는 명령어를 돌렸다. 화면에 내가 넣은 가짜 예약이 그대로 나왔다.

창고가 생겼다. 이제 손님이 들어올 문을 만들 차례였다.

다음 편 — 직원이 직접 쓰는 예약 페이지 만들기 (10)

※ 이 연재에 등장하는 ㈜세움과 모든 인물은 가상이다. 기술적인 구성과 시행착오는 실제 구축 경험을 바탕으로 재구성했다.

엘엔케이 작업책상