📅 2026.05.06(수) - 15일차

데이터베이스와 스토리지의 진화

File에서 Supabase까지. Supbase와 바이브 코딩.
데이터 저장 방식의 역사적 흐름을 통해 현대적인 통합 솔루션이 추구하는 방향성 이해. 단순한 기록을 넘어 실시간 동기화와 보안이 결합된 데이터 생태계.
데이터베이스는 서비스의 심장/기억 장치. 기술이 복잡한 인프라 관리를 대신, 개발자는 비즈니스 로직과 제품의 본질에 집중.
SQL의 강력함과 클라우드의 유연함을 결합한 솔루션을 통해 아이디어를 빠르게 현실로 구현.

01. DB의 시작: 파일 관리의 한계

구조화되지 않은 단순 파일 저장 시대가 직면했던 문제점.

데이터 중복 및 불일치: 같은 정보가 여러 곳에 중복 저장되어 정합성이 깨짐.
검색 효율성 최악: 대용량 데이터 검색 시 성능이 급격히 저하됨.
데이터 유실: 다중 사용자 환경에서 동시 수정 시 충돌 발생.
발전의 흐름: 계층형(나무 구조) ➜ 네트워크형(그물) ➜ 관계형(표 구조)으로의 진화 완성.

02. 관계형 DB(RDBMS)의 혁명 (1970년 ~ 현재)

데이터를 수학적 기초 위에서 표(Table) 형태로 저장하는 혁신적인 모델.

주요 DBMS: Oracle(주로 개인보다는 회사에서 사용), MySQL, PostgreSQL

에드거 F. 코드: IBM 연구원으로서 관계형 모델의 수학적 기초 확립.
SQL의 등장: 영어로 "무엇을" 가져올지 정의하는 표준 확립.
ACID 원칙: 원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 영구 저장(Durability)을 통해 데이터 무결성 완성.
정규화 원칙: 중복을 없애고 업데이트 효율성을 극대화함.
주요 기술: 인덱싱(빠른 검색 성능 보장), 쿼리 최적화, 캐싱(자주쓰는 데이터 최적화)을 통한 성능 보장.

03. 인터넷 폭발과 NoSQL (2000년대 중반)

글로벌 서비스의 데이터 폭증으로 인한 RDBMS의 확장성 한계 돌파.

RDBMS의 한계: 수평 확장의 어려움(여러 서버에 분산 저장 및 JOIN 복잡도 증가), 대용량 트래픽 처리 비용 급증 등 ➜ 해결책: NoSQL - 스키마리스 구조와 압도적인 확장성 (구글, 페이스북 등 글로벌 서비스의 트래픽을 감당하기 위한 진화)
NoSQL의 특징:
- 스키마리스(Schema-less) 구조로 유연한 데이터 관리
- 파티셔닝 (Partitioning): 자동 분산 및 수평 확장
- BASE 원칙: 가용성과 최종 일관성을 중시하며 자동 파티셔닝을 통해 압도적 확장성 완성.
Major Tools: MongoDB (오픈소스라서 있기 있음!), Cassandra 등 (Redis 및 다양한 엔진)

04. 클라우드와 서버리스 시대 (2010년대 ~ 현재)

인프라를 직접 설치하는 시대에서 '서비스로 사용'하는 시대로의 전환.

DB 세팅은 귀찮음. 인증과 실시간 기능이 필요! ➜ Supabase: 오픈소스 기반 실시간 통합 솔루션의 등장

관리형 DB 서비스: AWS RDS, GCP Cloud SQL 등을 통해 자동 백업 및 보안 패치 자동화.
서버리스 흐름(FaaS): 백엔드 부하 처리를 자동화하여 제품 개발 속도에만 집중 가능한 환경 구축.
통합 솔루션의 가치: "인증 + 실시간 기능 + DB"를 하나로 묶어 개발자 경험(DX) 극대화 완성.
핵심 자동화: 1) 자동 백업 & 복구, 2) 실시간 모니터링, 3) 오토 스케일링, 4) 자동 보안 패치

화이트리스트와 블랙리스트 개념 매우 중요!!! ➜ 입장 허용/불허할 리스트

* VPN (Virtual Private Network) ➜ 내가 누군지를 살짝 숨기고 접속! (공공장소에서 보안 강화하기 위한 수단 가능)

보안 패치는 항상 업그레이드 해두기 ㅎㅎ

05. Firebase vs Supabase

모바일/웹 앱 개발 가속화를 위한 차세대 플랫폼 비교.

① Firebase의 혁신과 한계 (2011년 ~ 현재): 구글이랑 연결된 서비스. 데이터베이스와 스토리지가 연결되어 서비스되고 있음.

혁신: Firestore(실시간 동기화), 소셜 로그인 통합, SDK 제공으로 백엔드 없는 MVP 개발 가능.
한계: 복잡한 JOIN(조회/집계) 부족, 쿼리 필터링 제약, 사용량 기반 과금 예측의 어려움.

② Supabase의 등장 (2020년 ~ 현재) : 오픈소스 기반인데 실시간! 인증 기능, 스토리지 기능 등이 들어있음. 평상시에 앱 만들고 할 때는 더 유용

PostgreSQL 기반: 완전한 SQL과 트랜잭션을 지원하는 오픈소스 대안.
실시간 구독: Logical Replication 기반의 Realtime 기능 지원.
강력한 보안: 행 수준 보안(RLS, Row-Level Security) 레벨 결합.
자동 API: DB 스키마 기반 REST/GraphQL 자동 생성으로 백엔드 구축 생산성 완성.

트랜잭션의 개념! (매우 중요): 오고가고의 확인 개념 / 예) 금융-> 송금하다가 중간에 실패했을 경우, 실패한 상황을 확인할 수 있게 해야함 / 이메일은 transaction 아님

06. Supabase 주요 기능 및 지표

서비스 구축에 필요한 핵심 컴포넌트들.

기능	설명	비유/특징
Database	PostgreSQL 기반 관계형 DB	SQL 그대로 사용, 실시간 데이터 구독 완성.
Auth	인증 및 세션 관리	소셜 로그인 및 JWT 기반 보안 체계 완성.
Storage	파일 및 이미지 관리	CDN 기반 빠른 전달과 RLS 권한 제어 완성.
Edge Functions	서버리스 함수 실행	API 로직 및 Webhook 처리를 위한 Deno 기반 환경.
Realtime	실시간 데이터 Push	채팅, 협업툴에 적합한 실시간 동기화 완성.

07. 핵심 가치: 개발 속도의 혁명

통합 솔루션이 바이브 코딩 시대에 제공하는 가치.

통합 스택: DB + Auth + Storage를 하나로 묶어 관리 포인트 최소화.
RLS(Row Level Security): 데이터 접근을 행 단위로 세밀하게 제어하여 보안 설계의 정교함 완성.
오픈소스 기반: 벤더 락인을 완화하고 필요시 셀프 호스팅이 가능한 개방성 확보.
표준 SQL 기반의 통합 솔루션 활용을 통해 제품 출시 속도 극대화 완성.

공공데이터 활용

오픈API 연동과 바이브 코딩 ➔ 공공 문제를 해결하는 MVP 설계
정부와 공공기관이 보유한 방대한 데이터를 단순한 '조회'의 대상이 아닌, 사용자 문제 해결을 위한 '서비스 자원'으로 재해석.
데이터베이스는 서비스의 심장이자 기억 장치. 공공데이터는 서비스의 핵심 재료. 복잡한 데이터를 사용자의 맥락에 맞게 가공하여 가치 창출.
사용자가 더 빠르고 정확하게 의사결정하도록 돕는 경험 설계

01. 공공데이터와 오픈 API의 이해

공공의 자산을 서비스의 재료로 바꾸는 핵심 관점.

공공데이터의 분야: 날씨(외출 추천), 교통(경로 추천), 관광(여행 추천), 보건(지역 의료 정보) 등 다양한 서비스 아이디어 원천.
핵심 질문 5가지:
1. 이 데이터는 누구의 문제를 해결하는가?
2. 사용자는 언제 이 정보가 필요한가?
3. 복잡한 데이터를 어떻게 쉽게 보여줄 것인가?
4. 실시간성이 중요한가?
5. 검색 중심인가, 추천 중심인가?
사용 흐름: 회원가입 ➜ API 검색 ➜ 활용 신청 ➜ Key 발급 ➜ API 호출 및 연동 완성.

02. API 호출 구조와 환경 설정

데이터를 가져오기 위한 기술적 약속과 보안 관리.

요청 URL 구조: Base URL + Service Key + PageNo + ReturnType 등의 파라미터 조합.
보안 관리: API Key는 코드에 직접 노출하지 않고 .env 파일에 환경변수로 설정하여 프로젝트 보안성 완성.
JSON 응답 파싱 포인트:
- header.resultCode: 에러 메시지 처리 및 정상 여부 판단.
- body.items.item: 카드나 리스트 UI로 구현할 실제 데이터 뭉치.
- body.totalCount: 검색 결과 수 표시 및 페이지네이션 설계에 활용.

03. 서비스 기획 7단계: SafeTrip Notice 예시

해외여행 안전 정보를 요약 제공하는 서비스를 통한 기획 프로세스 정립.

문제 발견: 공공기관 사이트의 정보를 찾기 어려워하는 사용자 Pain Point 발견.
데이터 탐색: 필요한 외교부 안전 공지사항 데이터 탐색.
API 확인: 데이터의 사용 가능성 및 실시간성 확인.
시나리오: 국가명 검색 후 요약된 안전 공지를 카드 형태로 확인하는 핵심 경로 작성.
IA 설계: 정보 구조 설계(Home ➜ 검색 ➜ 리스트 ➜ 상세 모달).
MVP 구현: React 기반 기능 구현.
테스트: 사용성 테스트를 통해 서비스 완성도 제고.

[공공데이터베이스 API를 활용한 실습]

data.go.kr 기상청공공데이터, 한전 전기사용료 데이터(?) & Antigravity 활용

월별/지역별 에너지 비용 시뮬레이션 / 평수, 단열 정도 / 연평균 지역별 에너지 사용량 / 카드형의 단점: 키가 너무 큼!

Git & Github

핀란드의 자랑 리누스 토발즈가 만듦 ➔ 버전 관리와 분산 협업의 정석
리눅스 커널의 창시자 리누스 토발즈가 단 2주 만에 설계한 분산 버전 관리 시스템(DVCS) Git. 대규모 프로젝트의 효율성, 데이터의 무결성, 그리고 중앙 서버에 의존하지 않는 독립적 작업 환경을 구축하는 현대 개발의 필수 도구 완성.
Git은 단순한 저장소가 아닌 프로젝트의 타임머신. 모든 변경 사항을 스냅샷으로 기록하고, 가지(Branch)를 쳐서 실험하며, 다시 합치는(Merge) 과정을 통해 안정적인 소프트웨어 생명 주기 완성.
복잡한 협업 과정에서 발생하는 충돌을 해결하고, GitHub을 통해 전 세계 개발자와 소통

1. Git의 탄생 배경과 철학

2005년, 기존 BitKeeper의 라이선스 문제 해결을 위해 시작된 혁신.

개발 목표:
1. 속도: 대규모 프로젝트를 처리하는 압도적인 퍼포먼스.
2. 단순성: 명확하고 직관적인 구조.
3. 완전한 분산: 모든 개발자가 전체 히스토리 복사본을 보유.
4. 무결성 보장: SHA-1 해시를 통한 데이터 손상 방지.
핵심 기술: 파일과 변경 기록을 고유한 해시값으로 관리하여 강력한 데이터 보호 완성.

2. Git 핵심 용어 정리

원활한 협업을 위해 반드시 숙지해야 할 기본 개념.

Repository (Repo): 프로젝트의 모든 파일과 이력이 담긴 '상자'.
Branch: 원본(main)을 두고 실험을 위해 만드는 '복사본' 또는 '가지'. (이전에는 main 대신 master라고 부르기도 했음)
Commit: 변경 사항을 기록하는 '스냅샷' 단위.
Pull Request (PR): 내 작업물을 원본에 합쳐달라고 보내는 '제안'. '이 레시피 좋지? 요리책에 추가해줘!"하고 편집자에 제안.
Merge: 제안된 내용을 원본 코드에 실제로 '합치는 작업'.
Clone: 원격 저장소를 내 로컬 컴퓨터로 그대로 '복사'.

3. Git 설치 및 초기 설정

터미널 환경에서 Git을 사용하기 위한 준비 단계.

설치 확인: git --version
사용자 설정 (최초 1회):
- 이름: git config --global user.name 'Your Name'
- 이메일: git config --global user.email 'your_email@example.com'
연결 보안: SSH 키를 생성(ssh-keygen)하여 GitHub 계정에 등록함으로써 안전한 인증 체계 완성.

today-i-learned 님의 블로그

[UX/UI 디자인] 15. 데이터베이스 & 스토리지 / 공공데이터 활용 / Git