EP 2. 브라우저에도 데이터베이스가 있다고?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

브라우저에도 IndexedDB라는 데이터베이스가 있으며, 데이터의 용도와 보관 기간에 따라 sessionStorage·localStorage·IndexedDB를 구분해 써야 한다.

📌 핵심 요점

1. 화면 표시, 실제 저장, 다른 사람과의 공유는 각각 다른 문제다. 저장 버튼의 성공 표시만으로 데이터의 위치와 보존 여부를 판단하면 안 된다.
2. sessionStorage는 현재 탭의 임시 입력값에 적합하다. 새로고침해도 유지되지만, 주소를 직접 입력해 연 새로운 탭에서는 기존 메모가 보이지 않는다. 탭 복제나 스크립트로 연 창에는 초기값이 복사될 수 있다.
3. localStorage는 작은 화면 설정이나 간단한 값을 보관하기 편하다. 실습에서는 같은 프로필의 다른 탭과 브라우저 재실행 후에도 설정이 유지되며, 사이트 데이터를 삭제하면 사라진다.
4. IndexedDB는 구조화된 데이터를 레코드별로 저장하는 브라우저 데이터베이스다. 객체 저장소와 키로 데이터를 구분하고, 인덱스로 조건 검색을 지원하며, 트랜잭션으로 여러 변경을 하나의 작업 묶음으로 처리한다.
5. 브라우저 저장소는 영구 백업이나 공동 작업을 자동으로 해결하지 않는다. 오프라인 재실행에는 앱 캐시 설계가, 중요한 데이터와 여러 사람의 공동 사용에는 백업·서버 동기화·인증 설계가 별도로 필요하다.

🧩 배경과 문제 정의

지난 영상에서는 고객 명단이 사라지고 브라우저 프로필에 따라 보이는 데이터가 달라지는 문제가 발생했다. 이번 영상은 그 원인을 추적하면서, 데이터베이스가 백엔드에만 있다는 생각에서 벗어나 브라우저 내부의 저장 공간을 직접 확인한다.

핵심 문제는 화면에 보이는 것, 실제로 저장되는 것, 다른 사람과 공유되는 것을 혼동하는 데 있다. 같은 고객 관리 앱에서 임시 메모·화면 설정·고객 레코드를 각각 저장하고, 개발자 도구로 저장 위치와 유지 범위, 검색 및 트랜잭션 동작을 확인하는 방식으로 차이를 설명한다.

🕒 시간순 섹션별 상세정리

1. 브라우저 안의 저장소를 직접 열어보기

• 고객 명단이 사라진 사건에서 출발해 개발자 도구 속 데이터베이스를 발견한다. 화면 표시·저장·공유가 서로 다른 문제라는 지난 영상의 결론을 다시 짚어 본다. [00:42]
• 브라우저 저장 공간으로 sessionStorage·localStorage·IndexedDB를 보여준다. 용어 암기보다 같은 고객 관리 앱에서 값을 넣고 어디에 저장되는지 확인하는 실습을 택한다. [01:06]
• 웹페이지에서 검사 또는 Mac의 Command+Option+I로 개발자 도구를 열고 Application의 Storage 영역을 찾는다. 세 저장소가 비어 있는 상태에서 데이터를 넣어 위치를 확인할 준비를 한다. [01:45]

2. 임시 메모와 화면 설정으로 보존 범위 비교하기

• sessionStorage에 고객 미팅 메모를 저장하면 새로고침 후에도 남지만, 주소를 직접 입력해 연 새 탭에는 나타나지 않는다. 탭 복제나 스크립트로 연 창은 초기값이 복사될 수 있어 비교 방법을 구분한다. [02:31]
• localStorage에는 화면의 간단 표시 설정을 저장한다. 같은 프로필의 다른 탭과 브라우저 재실행 후에도 설정을 읽을 수 있지만, 사이트 데이터를 지우면 삭제된다. [03:02]
• 지난 영상에서 프로필에 따라 고객 명단이 달랐던 현상을 브라우저 저장 공간의 경계와 연결한다. [03:08]

3. 문자열 저장에서 IndexedDB의 고객 레코드로 확장하기

• sessionStorage와 localStorage는 키와 값으로 저장하며 값은 기본적으로 문자열이다. 여러 고객을 JSON 문자열로 넣을 수 있지만, 특정 고객 검색·정렬·여러 값의 변경이 필요해지면 다루기 불편해진다. [03:58]
• IndexedDB를 구조화된 데이터를 보관하고 검색하는 데이터베이스 API로 보여준다. 데이터베이스는 보관실, 객체 저장소는 보관함, 키는 고객 식별값, 인덱스는 검색용 색인에 해당하며 트랜잭션은 여러 저장 작업을 묶는다. [04:46]
• Claude Code에 고객 번호·이름·지역 저장과 지역 검색을 요청해 customers 객체 저장소와 지역 인덱스를 만든다. 고객 여덟 명을 입력하고 개발자 도구에서 버전 1의 데이터베이스와 레코드별 객체를 확인한다. 패널은 항상 실시간으로 갱신되지 않아 새로고침이 필요할 수 있다. [06:24]

4. 인덱스 검색과 트랜잭션 중단을 검증하기

• 지역값을 기준으로 고객을 찾는 인덱스를 활용해 서울과 부산 고객을 각각 조회한다. 검색은 인덱스에 지역 조건을 전달해 결과를 읽는 방식으로 동작한다. [06:56]
• 개발자 도구에서 byRegion 인덱스가 만들어졌는지 확인한다. 인덱스는 개발자가 검색에 활용해야 하는 데이터 구조이므로, 생성 여부와 실제 사용 여부를 함께 살펴야 한다. [07:11]
• 같은 읽기·쓰기 트랜잭션에 두 고객을 추가한 뒤 의도적으로 중단하면 아무도 추가되지 않는다. 정상 저장에서는 두 고객이 함께 추가되며, 중단 시 작업 묶음의 변경을 되돌리는 역할을 보여준다. [07:59]

5. 오프라인 활용의 조건과 저장 기술 선택 기준

• 이미 열린 페이지에서 네트워크를 오프라인으로 바꿔도 고객 조회와 신규 저장이 동작한다. 다만 재실행까지 지원하려면 앱 캐시 설계가 필요하며, 용량 제한과 데이터 삭제 가능성 때문에 중요한 정보에는 서버 동기화와 별도 백업이 필요하다. [08:49]
• 임시 입력값은 sessionStorage, 작은 설정은 localStorage, 구조화된 목록·인덱스 검색·묶음 처리는 IndexedDB를 후보로 정리한다. 직원 다섯 명의 실시간 공동 관리에는 서버 데이터베이스·인증·동기화가 필요하며, 선택 기준은 누가 어디서 얼마나 오래 데이터를 쓰는지다. [09:37]
• AI가 만든 앱의 저장 버튼만 믿지 말고 개발자 도구에서 저장 위치와 새로고침 후 유지 여부, 객체 저장소와 인덱스를 확인하라고 권한다. 다음 편의 AI 데이터베이스 설계 점검을 예고하며, 브라우저도 데이터를 보관하고 찾아오는 작업 공간이라는 결론으로 마친다. [10:22]

🧾 결론

• 저장 기술을 고르는 기준은 기술의 이름보다 데이터를 누가, 어디서, 얼마나 오래 사용하는지다.
• 임시 입력값은 sessionStorage, 작은 설정은 localStorage, 구조화된 고객 목록과 조건 검색·묶음 처리는 IndexedDB를 후보로 삼을 수 있다.
• AI가 만든 앱도 개발자 도구에서 저장 위치, 실제 레코드, 객체 저장소와 인덱스를 직접 확인해야 한다.
• 브라우저는 화면을 보여주는 창이면서 데이터를 보관하고 찾아오는 작업 공간이기도 하다.

📈 투자·시사 포인트

• AI로 만든 앱을 평가할 때는 화면 완성도와 함께 저장 구조를 확인해야 한다. 고객 명단이 특정 브라우저에만 남는지, 동료와 공유되는지에 따라 실제 활용 범위가 달라진다.
• 오프라인에서 데이터가 읽힌다는 시연만으로 앱 전체의 오프라인 실행을 판단하기 어렵다. 이미 열린 페이지의 동작과 브라우저 재실행 후의 동작을 구분해 확인필요가 있다.
• 공동 고객 관리 도구를 도입한다면 서버 데이터베이스·인증·동기화와 백업 설계까지 평가 범위에 포함해야 한다.
• 이 영상은 브라우저 저장 기술을 설명하며, 특정 기업이나 자산의 수익성·가치평가를 판단할 근거는 제공하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 저장 용량의 구체적인 한도와 브라우저가 데이터를 정리하는 조건은 제시되지 않는다. 영상의 실습만으로 장기 보존을 보장할 수 없다.
• 오프라인 실습은 페이지가 이미 열린 상태에서 진행된다. 브라우저를 종료한 뒤에도 앱을 오프라인으로 다시 실행하는 캐시 설계는 구현 과정이 설명되지 않는다.
• 지역 인덱스를 이용한 검색은 시연하지만, 대규모 데이터에서의 성능 수치나 비교 결과는 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 개발자 도구의 Application 메뉴에서 sessionStorage·localStorage·IndexedDB를 열고 실제 저장 위치를 확인한다.
• 같은 데이터를 저장한 뒤 새로고침, 주소를 직접 입력한 새 탭, 브라우저 재실행에서 각각 유지되는지 비교한다.
• IndexedDB의 객체 저장소에서 고객별 키와 이름·지역 값을 확인하고, 데이터가 보이지 않으면 패널을 새로고침한다.
• 지역 인덱스의 존재를 확인하고, 앱의 지역 검색이 해당 인덱스에 조건을 전달해 결과를 읽는지 점검한다.

❓ 열린 질문

• 이 앱의 데이터는 누가, 어느 컴퓨터와 브라우저에서, 얼마나 오래 사용해야 하는가?
• 현재 탭의 임시 보관, 개인 설정 유지, 구조화된 고객 데이터 관리 중 어떤 요구가 핵심인가?
• 오프라인 지원 범위는 이미 열린 페이지의 작업까지인가, 브라우저를 다시 시작한 뒤의 앱 실행까지인가?