1. 프론트엔드 = 사용자가 보고 만지는 화면
2. 백엔드 = 데이터를 처리하는 보이지 않는 엔진
3. API = 둘 사이의 소통 인터페이스

옛날 (1990-2010년대):
Desktop 프로그램
→ exe 파일 설치
→ 내 컴퓨터에서만 실행
→ 예: Excel, Photoshop, 한글
→ Frontend + Backend 한 덩어리

요즘 (2010-현재):
Web/Mobile 프로그램
→ 브라우저/앱에서 실행
→ 어디서나 접속 가능
→ 예: Gmail, YouTube, 넷플릭스
→ Frontend와 Backend 분리

장점:
✅ 설치 불필요 (브라우저만 있으면 됨)
✅ 어디서나 접속 (폰, 태블릿, PC)
✅ 자동 업데이트 (서버만 업데이트)
✅ 협업 쉬움 (데이터 공유)

Desktop GUI는 점점 줄어드는 추세
→ 전문가용 툴 정도만 Desktop
→ 일반 서비스는 대부분 Web

프론트엔드 (Frontend)
= 집의 외관 + 내부 인테리어 + 가구
→ 사람들이 보고 사용하는 모든 것

예시:
- 예쁜 외벽
- 거실 소파
- 부엌 싱크대
- 조명 스위치

백엔드 (Backend)
= 보일러실 + 배관 + 전기 배선 + 기계실
→ 보이지 않지만 집이 작동하게 하는 것

예시:
- 온수를 만드는 보일러
- 물이 흐르는 배관
- 전기가 흐르는 선
- 정화조

API (Application Programming Interface)
= 스위치와 배관의 연결점
→ 사용자가 스위치(프론트엔드)를 누르면
   보일러(백엔드)가 작동함

시나리오: 따뜻한 물로 샤워하기

1. 사용자: 샤워기 손잡이를 돌림 (프론트엔드)
   ↓
2. 손잡이가 밸브에 신호 전달 (API)
   ↓
3. 보일러가 물을 데움 (백엔드)
   ↓
4. 따뜻한 물이 나옴 (결과)

사용자는 보일러가 어떻게 작동하는지 몰라도 됨!
손잡이만 돌리면 됨!

프론트엔드
= 식당 홀 + 메뉴판 + 테이블 + 인테리어
→ 손님이 보고 경험하는 공간

예시:
- 예쁜 메뉴판
- 편한 의자
- 조명과 음악
- 주문 태블릿

백엔드
= 주방 + 재료 창고 + 조리 과정
→ 손님이 보지 못하는 뒷작업

예시:
- 요리사가 요리하기
- 재료 보관
- 식기 세척
- 재고 관리

API
= 주문서 + 서빙
→ 홀과 주방을 연결

예시:
- 손님이 메뉴판에서 "불고기" 선택
- 주문서가 주방으로 전달
- 주방에서 요리
- 완성된 음식이 테이블로

시나리오: 음식 주문하기

1. 손님: 태블릿에서 "불고기" 터치 (프론트엔드)
   ↓
2. 주문 정보가 주방 프린터로 출력 (API)
   ↓
3. 요리사가 불고기 조리 (백엔드)
   ↓
4. 완성된 음식이 테이블로 서빙 (결과)

손님은 주방에서 무슨 일이 일어나는지 몰라도 됨!
메뉴만 선택하면 됨!

프론트엔드 (눈에 보이는 것)
- 빨간색 재생 버튼
- 동영상 플레이어
- 댓글창
- 좋아요 버튼
- 추천 영상 목록

백엔드 (보이지 않는 것)
- 동영상 파일 저장
- 사용자 로그인 처리
- 추천 알고리즘
- 댓글 데이터베이스
- 조회수 카운팅

API (연결)
- "재생 버튼 클릭" → "동영상 파일 전송 요청"
- "댓글 작성" → "댓글 DB에 저장"
- "좋아요" → "카운트 +1"

1. 사용자가 검색창에 "고양이" 입력 (프론트엔드)
2. 검색 요청이 서버로 전송 (API)
3. 서버가 DB에서 고양이 영상 검색 (백엔드)
4. 결과 목록 반환 (API)
5. 화면에 썸네일 표시 (프론트엔드)

프론트엔드
- 상품 사진
- 장바구니 아이콘
- 검색창
- 가격 정보
- 구매하기 버튼

백엔드
- 상품 재고 관리
- 결제 처리
- 배송 추적
- 회원 정보 저장
- 주문 내역 DB

API
- "장바구니 담기" → "상품 ID를 장바구니 DB에 추가"
- "결제하기" → "결제 처리 + 재고 차감"
- "주문 조회" → "DB에서 주문 정보 가져오기"

1. 사용자가 상품 클릭 (프론트엔드)
2. 상품 정보 요청 (API)
3. DB에서 상품 정보 + 재고 확인 (백엔드)
4. 정보 반환 (API)
5. 가격, 재고 상태 표시 (프론트엔드)

프론트엔드
- 글 작성 에디터
- 글 목록
- 댓글창
- 방문자 수

백엔드
- 글 저장 (DB)
- 이미지 업로드 처리
- 방문자 카운팅
- 검색 기능

API
- "글 작성" → "DB에 저장"
- "댓글 달기" → "댓글 추가"
- "글 목록 요청" → "DB에서 조회"

API = Application Programming Interface
= 프로그램들이 소통하는 인터페이스

Interface = 둘 사이의 접점, 경계면, 소통 방식

리모컨 버튼 = 인터페이스

사용자는:
- TV 내부가 어떻게 작동하는지 몰라도 됨
- 전기 회로가 어떻게 생겼는지 몰라도 됨
- 그냥 버튼만 누르면 채널이 바뀜

→ 복잡한 내부를 간단한 버튼으로 제어

버튼과 동전 투입구 = 인터페이스

손님은:
- 내부 기계가 어떻게 돌아가는지 몰라도 됨
- 냉각 시스템이 뭔지 몰라도 됨
- 동전 넣고 버튼만 누르면 음료수 나옴

→ 복잡한 기계를 간단한 조작으로 사용

터치스크린 = 인터페이스

고객은:
- 은행 시스템이 어떻게 돌아가는지 몰라도 됨
- 데이터베이스 구조를 몰라도 됨
- 화면만 터치하면 거래 완료

→ 복잡한 은행 시스템을 화면으로 쉽게 이용

Frontend ↔ Backend 사이의 소통 인터페이스

Frontend: "논문 목록 주세요"
   ↓
API (약속된 방식): "GET /papers"
   ↓
Backend: 데이터베이스에서 검색
   ↓
API (약속된 형식): {"papers": [...]}
   ↓
Frontend: 받아서 화면에 표시

Frontend = 사용자
API = 리모컨 버튼
Backend = TV 내부 회로

"채널 변경" 버튼 누르면
→ TV가 알아서 처리
→ 내부 작동 원리 몰라도 됨

Frontend = 손님/웨이터
API = 주문서
Backend = 주방

손님이 주문서에 "불고기" 작성
→ 주방이 요리
→ 요리 과정 몰라도 됨

Frontend = 전자기기
API = 콘센트 (표준 규격)
Backend = 전기 시스템

플러그만 꽂으면
→ 전기가 공급됨
→ 발전소가 어떻게 작동하는지 몰라도 됨

프론트엔드가 보내는 요청:
"GET /papers"
→ "논문 목록을 주세요"

백엔드가 보내는 응답:
{
  "papers": [
    {"title": "AI 논문", "author": "김철수"},
    {"title": "ML 논문", "author": "이영희"}
  ]
}
→ "여기 논문 2개 있어요"

프론트엔드:
받은 데이터를 예쁘게 화면에 표시

비유: 건축

외관 디자이너 (프론트엔드 개발자)
- 예쁜 외벽
- 인테리어
- 조명 배치
→ 미적 감각, 디자인 전문

구조 엔지니어 (백엔드 개발자)
- 튼튼한 기둥
- 배관 설계
- 전기 배선
→ 공학 지식, 로직 전문

한 사람이 다 하기엔 너무 복잡!

프론트엔드 팀:
"오늘은 버튼 디자인 바꿀게요"
→ 백엔드 영향 없음

백엔드 팀:
"오늘은 DB 최적화할게요"
→ 프론트엔드 영향 없음

서로 독립적으로 개발 가능!

같은 백엔드를 여러 곳에서 사용:

백엔드 (API 서버) 하나
   ↓         ↓        ↓
웹사이트  모바일앱  태블릿앱

데이터 처리 로직은 한 번만 만들고
화면은 각 플랫폼에 맞게!

사용자가 많아지면:

프론트엔드 서버 3대
백엔드 서버 10대
DB 서버 5대

필요한 부분만 늘릴 수 있음!

Layer 1: 구조 (뼈대)
→ React, Vue, Svelte
→ "어디에 버튼 놓을지"
→ "클릭하면 무슨 동작"

Layer 2: 스타일 (꾸미기)
→ TailwindCSS, Bootstrap
→ "버튼을 파란색으로"
→ "둥근 모서리"

Layer 3: 슈퍼 세트 (올인원)
→ Next.js, Nuxt
→ "React + 편의 기능 전부"
→ "페이지 라우팅, 최적화 자동"

Layer 4: 빌드 (완성)
→ Vite, Webpack
→ "개발 코드 → 배포용으로 변환"
→ "번역 + 압축 + 최적화"

React = 레고 블록
→ 기본 부품
→ 자유롭게 조립

TailwindCSS = 페인트 세트
→ 색칠 도구
→ 빠르게 스타일링

Next.js = 레고 + 설명서 + 받침대 + 전동 드라이버
→ 프리미엄 패키지
→ React를 더 쉽고 강력하게

Vite = 3D 프린터
→ 설계도를 실제 제품으로
→ 개발 코드를 배포용으로

오해: "Next.js를 쓰면 React 안 써도 되나?"

진실:
Next.js = React를 포함한 슈퍼 세트
→ Next.js 쓰는 것 = React 쓰는 것
→ 단지 더 편하게 쓰는 것

비유:
React = 라면
Next.js = 컵라면 (라면 + 용기 + 포크)

컵라면 먹어도 = 라면 먹는 거!

Django
= 올인원 패키지
→ DB, 인증, 관리자 페이지 전부 포함
→ 큰 웹사이트용
→ 무겁지만 기능 많음
→ 전통적 웹사이트 제작

예시: 블로그, 게시판, 커뮤니티

Flask
= 미니멀 키트
→ 핵심만 제공
→ 가벼운 프로젝트용
→ 자유도 높음
→ API + 간단한 웹

예시: 작은 웹앱, API 서버

FastAPI
= API 전문가
→ API만 빠르고 쉽게
→ 요즘 유행
→ 자동 문서화
→ 타입 안정성

예시: 모던 API 서버, 마이크로서비스

도구: Streamlit, Gradio, Django

구조:
프론트엔드 + 백엔드 한 프로젝트
→ 하나의 코드베이스
→ Python 코드만 작성

예시:
- Streamlit: Python 코드 → 웹 화면 자동 생성
- Gradio: ML 모델 → 웹 인터페이스 자동
- Django: 템플릿 + 백엔드 통합

장점:
✅ 배우기 쉬움
✅ 빠른 개발 (1-2주)
✅ 혼자 할 수 있음
✅ 배포 간단

단점:
❌ 디자인 커스텀 제한
❌ 확장 어려움
❌ 팀 작업 어려움

언제 쓰나?
→ 개인 프로젝트
→ 프로토타입
→ 연구용 도구
→ 사내 도구

도구: React + FastAPI, Vue + Django

구조:
프론트엔드 프로젝트 (별도)
   +
백엔드 프로젝트 (별도)
→ 두 개의 코드베이스
→ 각각 다른 언어

예시:
- Frontend: HTML/CSS/JavaScript (React)
- Backend: Python (FastAPI)
- 둘이 API로 통신

장점:
✅ 디자인 자유도 높음
✅ 팀 작업 가능
✅ 확장성 좋음
✅ 전문적 결과물
✅ 모바일 앱도 같은 Backend 사용

단점:
❌ 배우기 어려움 (2-3개월)
❌ 개발 시간 오래 걸림
❌ 두 프로젝트 관리

언제 쓰나?
→ 팀 프로젝트
→ 상용 서비스
→ 대규모 시스템
→ 모바일 앱도 만들 때

프로젝트 폴더/
│
├── frontend/                 (프론트엔드)
│   ├── src/
│   │   ├── components/      (버튼, 카드 등)
│   │   ├── pages/           (페이지들)
│   │   └── App.jsx          (메인)
│   └── package.json
│
└── backend/                  (백엔드)
    ├── app/
    │   ├── api/             (API 엔드포인트)
    │   ├── models/          (DB 모델)
    │   └── main.py          (진입점)
    └── requirements.txt

1단계: 프론트엔드 개발
- 화면 디자인
- 버튼, 입력창 배치
- 사용자 인터랙션

2단계: 백엔드 개발
- DB 설계
- API 엔드포인트 작성
- 비즈니스 로직

3단계: 연결
- 프론트엔드에서 API 호출
- 데이터 주고받기 테스트
- 에러 처리

4단계: 테스트 및 배포

1단계: 사용자 행동
사용자가 검색창에 "machine learning" 입력
→ 검색 버튼 클릭

2단계: 프론트엔드 처리
"검색 버튼 클릭됨!"
→ 백엔드에 요청 보내기
→ "machine learning 논문 찾아줘"

3단계: API 통신
프론트: "GET /search?keyword=machine learning"
→ 인터넷을 통해 백엔드로 전송

4단계: 백엔드 처리
요청 받음
→ 데이터베이스 검색
→ "machine learning" 포함 논문 10개 찾음
→ 결과 정리

5단계: API 응답
백엔드: 논문 목록 JSON 형태로 전송
→ 인터넷을 통해 프론트엔드로

6단계: 프론트엔드 표시
받은 데이터를 예쁘게 화면에 표시
→ 논문 제목, 저자, 년도 등
→ 사용자가 볼 수 있게

식당에서 주문하기:

1. 손님: "불고기 주세요" (사용자)
2. 웨이터: 메뉴판 확인, 주문서 작성 (프론트엔드)
3. 주문서를 주방으로 전달 (API 요청)
4. 주방: 재료 확인, 요리 시작 (백엔드 처리)
5. 완성된 음식을 홀로 전달 (API 응답)
6. 웨이터: 테이블에 서빙 (프론트엔드 표시)
7. 손님: 음식 받음 (결과 확인)

손님은 주방 내부를 전혀 몰라도 됨!

✅ 혼자 쓸 도구
✅ 빠른 프로토타입
✅ 데이터 시각화
✅ 사내 도구
✅ ML 모델 데모

예시:
- 논문 PDF 요약기
- 실험 데이터 분석 대시보드
- 이미지 처리 도구
- 통계 분석 웹앱

개발 시간: 1-2주
난이도: ★☆☆☆☆

✅ 팀 프로젝트
✅ 여러 플랫폼 (웹+모바일)
✅ 확장 가능성
✅ 전문적인 서비스
✅ 프론트엔드 개발자 있음

예시:
- 연구소 논문 관리 시스템
- 공용 실험 장비 예약 시스템
- 데이터 공유 플랫폼
- 협업 도구

개발 시간: 2-3개월
난이도: ★★★★☆

Streamlit (올인원):
학습 시간: 1-2일
개발 시간: 1-2주
난이도: ★☆☆☆☆
결과물: 실용적
비용: 무료

React + FastAPI (분리형):
학습 시간: 2-3개월
개발 시간: 1-3개월
난이도: ★★★★☆
결과물: 전문적
비용: 무료 (배포 시 서버 비용)

기능:
1. 논문 PDF 업로드
2. 자동 요약 (AI)
3. 검색
4. 즐겨찾기
5. 팀원 공유

구현:
- Python 코드만 작성
- st.file_uploader() → 파일 업로드 UI 자동
- st.button() → 버튼 자동
- st.dataframe() → 표 자동

장점:
- 빠른 개발 (1-2주)
- Python만 사용
- 코드 간결

단점:
- 디자인 제한적
- 모바일 앱 불가
- 동시 접속자 제한

적합한 경우:
- 연구실 내부용
- 10명 이하 사용
- 빠른 프로토타입

Frontend (React + TailwindCSS):
- 논문 목록 화면 (자유로운 디자인)
- 검색 UI (자동완성, 필터)
- 파일 업로드 드래그앤드롭
- 모바일 반응형
- 다크모드

Backend (FastAPI):
- PDF 파일 저장
- AI 요약 API
- PostgreSQL DB
- 사용자 인증
- 권한 관리

장점:
- 전문적 디자인
- 모바일 앱 추가 가능
- 확장성 (사용자 1000명도 OK)
- 팀 협업

단점:
- 개발 시간 (2-3개월)
- 두 가지 언어 필요
- 배포 복잡

적합한 경우:
- 연구소 전체 사용
- 장기 프로젝트
- 모바일 앱도 계획

= 사용자가 보고 만지는 모든 것

역할:
- 화면 그리기
- 사용자 입력 받기
- 데이터 예쁘게 표시
- 버튼, 입력창 등

도구:
- React, Vue, Svelte (구조)
- TailwindCSS (스타일)
- Next.js (슈퍼 세트)

비유:
집의 외관, 식당 홀, 상점 진열대

= 데이터를 처리하는 보이지 않는 엔진

역할:
- 데이터 저장/조회
- 계산 처리
- 비즈니스 로직
- 보안 처리

도구:
- FastAPI, Django, Flask (Python)
- Node.js, Java, Go (다른 언어들)

비유:
집의 보일러실, 식당 주방, 상점 창고

= 프론트엔드와 백엔드를 연결하는 인터페이스

역할:
- 요청 전달
- 응답 반환
- 데이터 형식 약속
- 둘 사이의 소통 방식

방식:
- RESTful API (가장 흔함)
- GraphQL (고급)
- WebSocket (실시간)

비유:
리모컨, 자판기 버튼, ATM 화면, 콘센트

1. Frontend와 Backend 분리가 표준
   → Desktop GUI는 점점 줄어듦
   → Web 기반이 대세

2. API로 소통
   → Frontend는 Backend 내부 몰라도 됨
   → 마치 리모컨처럼

3. 재사용 가능
   → 같은 Backend를 웹/모바일에서 사용

4. 확장 가능
   → 필요한 부분만 서버 증설

초보자 → 중급자 로드맵:

1단계: Streamlit으로 시작 (1-2주)
→ 빠른 성공 경험
→ Python만 사용
→ 실용적인 도구 완성

2단계: HTML/CSS 기초 (1-2주)
→ 웹의 기본 이해
→ 간단한 페이지 만들기

3단계: JavaScript 기초 (2-3주)
→ 프론트엔드의 핵심
→ 동작 추가하기

4단계: React 입문 (1개월)
→ 현대 프론트엔드
→ 컴포넌트 기반 개발

5단계: FastAPI 깊게 (1개월)
→ 전문 백엔드
→ API 설계 패턴

Streamlit:
- 공식 문서 (영어, 한글 번역 가능)
- 유튜브 튜토리얼 많음
- 예제 프로젝트 풍부

React:
- React 공식 튜토리얼
- Next.js 공식 문서
- 인터랙티브 코스

FastAPI:
- FastAPI 공식 문서 (한글 지원!)
- Swagger UI 자동 생성
- 예제 풍부

1. 프론트엔드 = 보이는 것 (화면)
   백엔드 = 보이지 않는 것 (데이터 처리)

2. API = 둘 사이의 소통 인터페이스
   → 리모컨, 자판기 버튼처럼

3. 분리하는 이유
   → 전문성, 독립적 작업, 재사용, 확장성

4. 현대 프로그램 = 대부분 웹 기반
   → Frontend/Backend 분리가 표준

5. 통합 vs 분리
   → 프로젝트 규모에 따라 선택

6. 초보자는 Streamlit 추천
   → 코드 적고 결과 빠름

7. 전문가는 분리형
   → 더 복잡하지만 더 강력

핵심 메시지:

"현대 프로그램은 크게 두 부분으로 나뉩니다.

보이는 부분 (프론트엔드)
보이지 않는 부분 (백엔드)

마치 집의 외관과 보일러실처럼요.

둘은 API라는 인터페이스로 대화합니다.
리모컨이 TV를 제어하듯이요.

여러분은 Streamlit으로 시작할 거예요.
이건 둘을 한 번에 만들어주는 마법 같은 도구죠!

나중에 더 전문적으로 하고 싶으면
React + FastAPI를 배우면 됩니다.

하지만 연구용 도구는 Streamlit이면 충분해요!"