database/SQLite14 backend/src/db/sqlite.js 데이터 접근 레이어 backend/src/db/sqlite.js더보기import sqlite3 from 'sqlite3';import config from '../config/config.js';const db = new sqlite3.Database(config.db.sqlite.path, (err) => { if (err) { console.error('SQLite connection error:', err); } else { console.log('Connected to SQLite database'); }});// Promisify database operationsconst sqliteDb = { all: (sql, params = []) => { return new Promise((reso.. 2026. 2. 2. 메뉴목록 호출 실무 흐름 겉으로 보면 메뉴가 그냥 떠 있는 것 같지만, 실제로는 상태 관리 + 캐시 + 권한 + 렌더링이 겹쳐 있다.실무에서 가장 흔한 구조 기준으로, 단계별로 설명.1️⃣ 메뉴가 SQLite에 저장되는 이유 (먼저 개념부터)네비바 메뉴는 보통 이런 성격을 가진다.화면 구조를 정의함 (UI 골격)권한에 따라 보이기도/안 보이기도 함자주 바뀌지는 않지만, 코드 수정 없이 바꾸고 싶음운영/관리 화면에서 수정 가능해야 함그래서 DB에 이렇게 관리한다.MENU- menu_id- parent_id- menu_name- path- sort_order- use_yn- role_code👉 이건 **비즈니스 데이터라기보다 “설정 데이터”**다.그래서 SQLite 같은 로컬 DB가 잘 맞는다.2️⃣ 앱이 실행될 때 일어나는 일 .. 2026. 2. 2. 충돌 해결 전략 좋다. 여기서부터가 local-first 설계의 마지막 관문이다.지금까지 흐름을 정확히 이해했기 때문에, 이제 “충돌 해결 전략”을 정의 → 유형 → 실무 선택 기준 순서로 정리해보자.0️⃣ 먼저 충돌이 뭔지부터 정확히 정의충돌(conflict) 은 이 상황을 말한다. 같은 row (id=100)서로 다른 주체가서로 다른 값을서로의 변경을 모른 채 수정핵심은 “동시에”가 아니라 “서로 모른 채” 다.POS A: id=100 수량 = 5POS B: id=100 수량 = 3둘 다 서버 반영 시도👉 이때 누굴 믿을 건가?1️⃣ 충돌 해결 전략은 “기술”이 아니라 “정책”이다중요한 관점부터 잡자.❗ 충돌 해결에는 “정답”이 없다❗ 업무 성질에 맞는 정책 선택이 전부다그래서 실무에서는 여러 전략을 섞는다.2️⃣.. 2026. 1. 19. 궁금증 - 로컬과 서버의 정보 수정 시점 궁금증 - 로컬과 서버의 정보 수정 시점포스 A에서 서버로 올린 데이터는 id 100번 일 때 push 이고 포스 B는 이 정보를 서버에서 pull 받아서 sync가 되는 흐름.그렇다면 서버랑 로컬디비랑 동시에 한 행을 같이 수정하는 경우는 없나? push를 한 주체가 update까지 하게되는건가? sync상태가 되었다는 표시는 로컬에서 할거같은데 언제 서버가 개입하는건가이 질문은 local-first 설계의 핵심 질문이다.지금 네가 묻는 건 사실상 이거다:“한 row를 누가 언제까지 책임지고,서버는 어디까지 개입하는가?”순서대로, 오해 생길 수 있는 지점을 하나씩 걷어내자.1️⃣ 먼저 네 예시는 정확하다포스 A에서 id=100 생성 → 서버로 push포스 B는 서버에서 pull 받아 sync이건 정석 .. 2026. 1. 19. 소위 Local-first architecture 지금까지 우리가 이야기한 구조는 정확히 _Local-first architecture_라고 부른다.다만 실무에서는 Local-first / Offline-first / Sync-based가 섞여 쓰이기 때문에,개념 경계를 한 번 정확히 잡아두는 게 중요하다.차근차근 정리해보자.1️⃣ Local-first architecture의 정확한 의미Local-first의 핵심은 이 한 문장이다.“데이터의 1차 진실(source of interaction)은 로컬에 있다.”즉,사용자의 입력화면에 보이는 상태즉각적인 반응이 모든 것은 네트워크와 무관하게 로컬에서 먼저 처리된다.예시SQLite (device 내장 DB)항상 먼저 기록오프라인에서도 완전 동작PostgreSQL (서버)나중에 동기화최종 검증과 공유 담당?.. 2026. 1. 18. SQLite의 보안위험성과 대응책 device내장으로 관리하는 파일구조의 조작 가능성 결론부터 말하면: 가능성은 있다.차근차근 현실 기준으로 정리해 보자.1️⃣ SQLite는 결국 “파일”이다 → 조작 가능성은 원천적으로 존재맞다. SQLite는 device 내부의 파일이다.모바일: 앱 전용 저장소 안의 .db데스크톱: 사용자 홈 디렉터리 안의 .db임베디드: 로컬 스토리지의 파일그래서 이론적으로는:파일을 복사할 수 있고열어서 수정할 수 있고교체도 가능하다👉 “조작 가능성 자체”는 0이 아니다.이건 SQLite의 약점이라기보다로컬에 저장된 모든 데이터의 공통 특성이다.2️⃣ 그런데 “누가, 언제, 어떻게” 조작할 수 있나?여기서 현실 필터를 걸어야 한다.✅ 가능한 경우루팅 / 탈옥된 모바일 기기개발자 모드 + 디버깅 접근PC 프로그램에.. 2026. 1. 18. 이전 1 2 3 다음
