AI로 만든 앱에 진짜 데이터베이스가 필요한 순간 (그리고 필요 없는 순간)

데이터베이스는 실제로 무슨 일을 하나요?

데이터베이스의 본질적인 역할은, 같은 앱을 쓰는 두 사람이 서로의 작업을 실수로 덮어쓰거나 망가뜨리지 않도록 막는 것입니다 — 속도, 구조, 복잡한 검색은 그 한 가지 문제를 해결하는 과정에서 따라오는 부산물일 뿐입니다.

AI로 앱을 만들었습니다. 잘 작동합니다. 파일이나 스프레드시트에 데이터를 저장합니다. 모든 게 괜찮아 보입니다.

그러다 다음 두 가지 중 하나가 일어납니다.

누군가 앱을 쓸 때마다 점점 느려진다.
두 사용자가 동시에 앱을 쓰다가 뭔가가 망가진다.

이 두 가지 실패는 일이 터지기 전까지는 눈에 띄지 않습니다. 둘 다 사실은 데이터베이스 문제가 다른 모습으로 나타난 것입니다.

아직 파일이나 스프레드시트를 쓰고 있다면, 아마 데이터베이스가 없는 상태일 겁니다. 그건 괜찮습니다. 다만 곧 데이터베이스가 필요해질 거라는 경고 신호는 알고 있어야 합니다.

데이터베이스 없이 그냥 파일만 써도 괜찮은 경우는?

파일은 앱을 쓰는 사람이 나 혼자뿐이고, 데이터 변경이 드문 경우라면 충분히 괜찮습니다 — 이게 판단 기준의 전부입니다.

프리랜서의 포트폴리오 사이트? 파일로 완벽합니다. 개인 가계부? 파일로 충분합니다. 사용자가 한 명뿐인 취미 프로젝트? 굳이 복잡하게 만들지 마세요.

파일이 잘 맞는다는 진짜 신호들:

한 번에 한 사람만 앱을 사용한다(또는 다른 사람이 작업 중일 때 나머지는 오프라인이다).
데이터를 자주 바꾸지 않는다(하루에 한 번, 일주일에 한 번, 한 달에 한 번).
최근 30초 정도의 작업을 잃어도 괜찮다(빌더가 다시 시도하면 되니까).
데이터 파일을 이메일로 보낼 수 있을 만큼 작다(10MB 이하).

네 가지가 모두 해당한다면, 파일을 계속 쓰세요. 정말로요. 단순함은 한계가 아니라 하나의 장점입니다.

AI로 만든 앱이 왜 점점 느려질까요?

앱이 느려지는 이유는 저장하는 파일이 계속 커지는데, 빌더가 뭔가를 수정할 때마다 그 파일 _전체_를 메모리로 불러오기 때문입니다 — 처음에는 거의 티가 안 나지만, 파일이 커질수록 부담이 커집니다.

느려지는 건 처음엔 그냥 “느낌”으로 옵니다. 예전보다 앱이 느리게 느껴집니다. 버튼을 클릭하면 1초쯤 더 걸립니다. 검색은 눈에 띄게 느려집니다. 코드를 바꾼 것도 아닌데 왜 느려졌을까요? 패턴은 이렇습니다.

앱이 전체 데이터 파일을 불러온다(100줄, 빠르다).
사용자가 레코드를 하나 추가한다(이제 101줄).
앱이 확인을 위해 파일 전체를 다시 읽는다(아직은 빠르다).
레코드 2,000개가 넘으면 파일을 읽는 데 2초가 걸린다.
레코드 10,000개가 넘으면 20초가 걸린다.

기하급수적으로 느려지는 건 아니지만, 5,000개 근처부터 체감이 되고 20,000개 근처부터는 정말 답답해집니다.

첫 번째 해법(데이터베이스를 도입하기 전에): 빌더에게 데이터를 필요할 때만 불러오도록 요청하세요. 화면에 보여줄 레코드만, 또는 보여줄 열(column)만 불러오게 하는 겁니다. 불러오는 방식만 똑똑하게 바꿔도 파일로 계속 버틸 수 있는 앱이 많습니다.

데이터베이스로 옮겨야 할 때: 데이터가 50,000개 레코드를 넘거나, 불러오기를 최적화했는데도 느림이 계속될 때입니다.

두 사람이 동시에 앱을 썼더니 왜 데이터가 사라졌을까요?

두 사람이 동시에 같은 파일을 수정할 수 있는데, 앱은 그 사실을 알 방법이 없기 때문입니다 — 나중에 저장한 쪽이 이기고, 먼저 저장한 사람의 변경 내용은 조용히 사라집니다. 이걸 “충돌하는 쓰기(conflicting write)“라고 부르며, 전형적인 데이터 손실 버그입니다.

두 사람 모두 자기 화면에서는 자신의 변경 내용을 봅니다. 둘 다 “저장”을 누릅니다. 다음과 같은 일이 생긴다면 이 문제를 겪고 있는 겁니다.

사용자들이 가끔 데이터가 사라졌다고 보고한다(특히 여러 사람이 앱에 동시에 있을 때).
사용자들이 이유 없이 자기 변경 사항이 “되돌려졌다”고 보고한다.
두 사용자가 같은 레코드를 수정했는데 한쪽의 수정 내용이 사라진다.
“분명 어제 이걸 추가했는데 지금은 없어졌어요” 같은 메시지를 받는다.

이건 앱의 잘못이 아닙니다. 파일이라는 방식 자체의 한계입니다. 데이터베이스 없이 이 문제를 제대로 해결할 방법은 없습니다.

데이터베이스로 옮겨야 할 때: 아직 문제가 터지지 않았더라도, 두 사람이 동시에 앱을 쓰기 시작하는 순간부터입니다.

파일로는 왜 복잡한 검색을 처리할 수 없나요?

파일을 쓰면 빌더가 관련된 모든 데이터셋을 한 단계씩 직접 불러오고 걸러내야 하기 때문입니다 — 질문 하나를 던지고 답 하나를 받는 게 아니라요. 데이터베이스는 똑같은 일을 쿼리 하나로 밀리초 만에 해냅니다.

예를 들어 “지난 일주일간 연락하지 않은 캘리포니아 고객의 미결제 청구서 전부”를 찾고 싶다고 해봅시다. 파일로 하면 빌더는 이렇게 해야 합니다.

모든 청구서를 불러온다.
미결제(unpaid = true) 항목만 걸러낸다.
모든 고객 정보를 불러와서 ID로 매칭한다.
주(state) = “CA”인 항목만 걸러낸다.
모든 연락 기록을 불러와서 고객 ID로 매칭한다.
날짜가 일주일 이전인 항목만 걸러낸다.

데이터베이스라면 쿼리 하나만 작성하면 됩니다. 밀리초 만에 이 모든 걸 처리합니다.

데이터베이스로 옮겨야 할 때: 빌더가 “그 질문에 답하려면 커스텀 코드를 따로 짜야 한다”고 말할 때입니다. 또는 필터링된 데이터를 보여주기 위해 앱이 지나치게 많은 일을 하고 있다는 게 눈에 띌 때입니다.

데이터베이스가 필요할 때 빌더에게 뭐라고 말해야 하나요?

무엇이 문제인지 있는 그대로 말하고 계획을 물어보세요. 예를 들면 이렇게: “앱이 [느려지고 있어요 / 데이터가 사라졌어요 / 더 복잡한 검색이 필요해요]. 데이터베이스를 추가해야 할 것 같은데, 얼마나 큰 작업일까요?”

대부분의 빌더는 작은 앱이라면 1~2일, 더 큰 앱이라면 며칠 정도면 파일에서 데이터베이스로 옮길 수 있습니다. 과정은 대략 이렇습니다.

앱은 대체로 그대로 유지한다(사용자 입장에서는 큰 변화가 없다).
데이터베이스 백엔드를 연결한다(나머지 코드 입장에서는 여전히 파일처럼 보이지만, 내부는 데이터베이스다).
정말 철저하게 테스트한다(데이터를 옮기는 건 민감한 작업이니까).
확신이 들 때까지 일주일 정도 둘을 병행 운영한다.

빌더가 이렇게 물어볼 수도 있습니다.

“PostgreSQL, MySQL, 아니면 다른 걸 쓸까요?”
- 당신의 답: “가장 편한 걸로 하세요. 저는 차이를 모르지만 당신을 믿어요.”
“3일 정도 걸릴 텐데, 할 만한 가치가 있을까요?”
- 당신의 답: “어차피 옮겨야 한다면, 데이터가 더 늘어나기 전에 빨리 하는 게 나아요.”
“예전 데이터도 옮길까요?”
- 당신의 답: “네, 100개 미만이 아니라면요. 그 정도면 그냥 새로 시작해도 괜찮아요.”

데이터베이스를 저 스스로 이해해야 하나요?

아니요 — 데이터베이스가 뭔지 알 필요도, SQL을 배울 필요도, PostgreSQL과 MySQL 중 뭐가 나은지 따질 필요도 없습니다. 빌더에게 해야 할 말은 이것뿐입니다: “두 사람이 동시에 앱을 써도 서로의 작업을 잃지 않게 해주세요.”

그게 전부입니다. 데이터베이스 선택은 빌더에게 맡기면 됩니다. SQLite처럼 단순한 것(동시 사용자 10명 미만의 개인용·팀용 앱)이든 PostgreSQL(더 큰 규모라면)이든, 둘 다 그 역할을 해냅니다.

내 앱에 데이터베이스가 필요한지 어떻게 알 수 있나요?

아래 네 가지 중 나에게 해당하는 항목을 체크해보세요 — 두 개 이상 체크됐다면 지금 데이터베이스를 추가할 때입니다.

느려짐: 3개월 전엔 더 빨랐는데 지금은 느려졌다. 데이터 파일이 20MB가 넘거나 레코드가 10,000개를 넘는다.
데이터 손실: 누군가의 변경 내용이 사라졌거나, 여러 사용자가 편집 내용이 사라졌다고 보고했다.
복잡성: “X를 Y로 필터링해서 보여줘” 같은 질문을 하고 싶은데 빌더가 “파일로는 어렵다”고 말한다.
사용자: 한 명 이상이 동시에 앱을 쓴다(가끔이라도).

두 개 이상 체크했다면, 앱은 데이터베이스를 도입할 준비가 된 상태입니다.

하나도 체크하지 않았다면, 파일로 충분합니다. 그대로 유지하세요. 단순함은 그 자체로 가치가 있습니다.

한 개만 체크했다면, 빌더에게 물어보세요: “앞으로 6개월은 이 속도로 버틸 만한가요?” 그렇다면 기다리세요. 아니라면 지금 옮기세요.