기술 스택 선택 — 아키텍처와 프레임워크/DB를 조합하는 법

프레임워크, DB, 클라이언트/서버 구조의 선택지가 폭발적으로 많을 때, 어떻게 결정하는가. 핵심은 "뭘로 만들지"가 아니라 "뭘 만들지"가 먼저라는 것이다.

아키텍처와 프레임워크는 다르다

순서: 아키텍처가 먼저, 도구가 나중. 단, 현실의 함정은 프레임워크가 특정 아키텍처를 강제한다는 것이다 (Next.js → SSR 구조, Tauri → 로컬 앱 구조). 그래서 이 둘을 완전히 분리할 수는 없지만, 사고의 순서는 유지해야 한다.

클라이언트에 DB가 붙느냐, 서버에 DB가 붙느냐가 가장 근본적인 분기다. 이 결정에 따라 기술 스택 전체가 갈라진다:

이 결정은 how-to-scope-requirements|요구사항에서 나와야 한다. "누가 쓰나?"에 대한 답이 기술 스택 전체를 결정한다.

모든 게 한 프로세스 안에서 일어난다. 네트워크 없고, 서버 없고, 단순하다. 오프라인 동작, 빠른 속도, 인프라 비용 0. 단, 다른 기기에서 접근 불가.

Client-Server 사이에 네트워크 경계가 생긴다. 이 경계 때문에 고려사항이 폭발적으로 늘어난다: 네트워크 끊김 처리, 동시성 제어, 인증, 서버 비용.

Local-First의 장점을 유지하면서 기기 간 동기화를 추가한 구조. Notion, Obsidian Sync가 이 방식. 가장 복잡하지만 사용자 경험이 가장 좋다.

how-to-design-a-program-from-scratch|설계 과정 안에서 기술 스택 결정이 들어가는 위치:

요구사항 → 데이터 위치 → 아키텍처 → 프레임워크 순서다. 프레임워크를 먼저 고르고 아키텍처를 끼워 맞추는 것이 아니다.

선택지가 너무 많을 때: **"이 선택이 요구사항의 어떤 부분을 해결하는가?"**를 물어본다. 답을 못 하면 그 기술은 아직 필요 없는 것이다.

"왜 SQLite?" → "혼자 쓰는 데스크톱이라 서버 불필요"
"왜 Svelte?" → "Tauri랑 궁합, 번들 크기"
"왜 FastAPI?" → "... 유명하니까?" → ⚠️ 서버 필요 여부부터 결정해야 함

요구사항이 비슷하면 스택도 비슷해지는 것이 자연스럽다. 스택이 먼저가 아니라 요구사항이 먼저이고, 같은 종류의 문제에는 같은 종류의 도구가 적합하다.