5강 — 백엔드 기초

🎯 학습 목표

백엔드가 무엇이고, 프론트엔드·데이터베이스로 이루어진 3-tier 구조에서 어디에 위치하는지 설명할 수 있다
API의 개념을 "레스토랑 주문 시스템" 비유로 이해하고, 요청(Request)과 응답(Response)의 흐름을 설명할 수 있다
REST API의 네 가지 메서드(GET/POST/PUT/DELETE)와 CRUD의 대응 관계를 안다
FastAPI로 Hello World API를 직접 만들고, 로컬에서 uvicorn으로 서버를 띄워 테스트할 수 있다
우리 리뷰 분석 앱에 필요한 API 엔드포인트가 무엇인지 설계할 수 있다

📖 해설

1. 백엔드는 앱의 두뇌입니다

오늘은 백엔드를 배웁니다. 백엔드가 뭐냐고요? 35차시에서 우리가 설계한 앱을 떠올려 보세요. 그때 앱을 프론트엔드 · 백엔드 · 데이터베이스라는 세 개의 층(layer)으로 나눴습니다. 이렇게 세 계층으로 나누는 구조를 3-tier 구조라고 부릅니다.

프론트엔드(Frontend): 사용자가 직접 보고 누르는 화면입니다.
백엔드(Backend): 화면 뒤에서 실제 일을 처리하는 부분입니다.
데이터베이스(Database): 데이터를 저장해 두는 창고입니다.

지난 36~37차시에서 우리는 이 중 데이터베이스를 만들었습니다. 그 위에 올라가는 게 바로 오늘 만들 백엔드입니다. 백엔드는 앱의 두뇌라고 생각하시면 됩니다. 화면(프론트엔드)이 "이거 해줘"라고 시키면, 두뇌(백엔드)가 창고(데이터베이스)에서 데이터를 꺼내 처리하고 다시 화면에 돌려주는 역할이죠.

오늘의 순서는 이렇습니다. ① 먼저 API가 무엇인지 비유로 이해하고, ② REST라는 약속을 배우는데, 여기서 GET과 POST 이 두 가지만 알아도 많은 일을 할 수 있습니다. ③ 그다음 FastAPI라는 도구로 직접 Hello World API를 만들고, ④ 마지막으로 우리 리뷰 분석 앱에 쓸 API의 첫발을 내딛어 봅니다.

2. 37차시 복습 — 데이터 저장소는 이미 준비됐습니다

잠깐 36~37차시에서 만든 것을 복습하겠습니다. 우리는 SQLite 데이터베이스에 테이블 두 개를 만들었습니다.

reviews 테이블: 게임 리뷰 원본을 저장하는 테이블
analysis_results 테이블: LLM이 분석한 결과(감성 등)를 저장하는 테이블

그리고 이 두 테이블을 외래 키(FOREIGN KEY)로 연결했습니다. 어떤 리뷰의 분석 결과인지 짝을 맞춰 둔 거죠. 또 Python에서 cursor.execute()로 SQL을 실행하고 commit()으로 저장하는 법, 그리고 CRUD(Create-Read-Update-Delete, 즉 생성·조회·수정·삭제)도 배웠습니다. 이 CRUD는 잠시 뒤 REST와 다시 만나니 기억해 두세요.

자, 이렇게 데이터 저장소는 준비됐습니다. 그런데 한 가지 질문이 남습니다. 이 저장소를 어떻게 사용해야 할까요? 화면에서 "리뷰 목록 보여줘"라고 했을 때, 어떻게 데이터베이스에서 데이터를 꺼내 화면까지 전달할까요? 바로 여기서 API가 필요합니다.

3. API가 뭐예요? — 레스토랑 주문 시스템으로 이해하기

API는 Application Programming Interface, 우리말로 "응용 프로그램 프로그래밍 인터페이스"의 약자입니다. 그런데 이렇게 외우면 너무 어렵죠. 그래서 비유로 이해하는 게 가장 빠릅니다. API는 한마디로 "코드끼리 데이터를 주고받는 방법"입니다.

레스토랑에서 음식을 주문하는 상황을 떠올려 보세요. 등장인물이 넷입니다.

레스토랑	우리 앱	역할
손님(클라이언트)	프론트엔드(화면)	음식을 주문하는 사람
메뉴판	API 문서	어떤 요청이 가능한지 적힌 목록
주방	백엔드 서버	실제로 요리(=데이터 처리)하는 곳
웨이터	API	주문을 받아 주방에 전달하고, 음식을 가져다 줌

핵심은 이겁니다. API는 웨이터입니다. 손님(화면)과 주방(서버) 사이를 오가며 연결해 줍니다. 손님이 주방에 직접 들어가 요리하지 않죠. 웨이터에게 주문하면 웨이터가 알아서 주방에 전달하고 음식을 가져옵니다. API도 똑같습니다. 화면이 데이터베이스를 직접 만지는 게 아니라, API가 중간에서 요청을 받아 처리하고 결과를 돌려줍니다.

그래서 API의 핵심은 딱 두 가지, 요청(Request)과 응답(Response)입니다. 그게 전부입니다.

요청(Request): 클라이언트가 서버에게 "이거 해줘"라고 보내는 것
응답(Response): 서버가 클라이언트에게 "결과야"라고 돌려주는 것

주문하면 음식이 나오듯, 요청을 보내면 응답이 옵니다. 어렵게 생각할 필요 없습니다. 요청 보내고 → 응답 받으면 끝입니다.

실제 예시로 날씨 앱을 생각해 봅시다.

사용자가 날씨 앱을 열고 "서울 날씨 보기" 버튼을 누릅니다.
앱이 날씨 서버에 요청을 보냅니다 — "서울 날씨 알려줘".
서버가 응답을 보냅니다 — "서울 15도, 맑음".
앱이 받은 데이터를 예쁘게 화면에 보여줍니다.

이게 바로 API 호출입니다. 요청 보내고, 서버가 처리하고, 응답받고 — 우리가 매일 쓰는 앱들이 전부 이렇게 동작합니다.

4. REST API — 웹에서 가장 많이 쓰는 주문 방식

REST API라는 말, 들어보셨나요? REST는 REpresentational State Transfer의 약자인데, 이 약자 자체는 "그런가 보다" 하고 넘어가셔도 됩니다. 중요한 건 REST가 웹에서 가장 많이 쓰이는 API 형식(방식)이라는 점입니다.

다시 레스토랑 비유로 돌아가면, 메뉴판에 주문 방법이 적혀 있는 것처럼 REST는 API 요청의 규칙입니다. 그리고 REST API에는 네 가지 주문 방법이 있습니다. 이걸 HTTP 메서드라고 부릅니다.

메서드	뜻	의미
GET	조회	"이 데이터 주세요" — 읽기만 하고 변경은 하지 않음
POST	생성	"새 데이터 추가해 주세요" — 새로 만듦
PUT	수정	"이 데이터 바꿔 주세요" — 기존 데이터 변경
DELETE	삭제	"이 데이터 지워 주세요" — 데이터 제거

이 중 GET과 POST 두 가지만 알아도 대부분의 상황을 처리할 수 있습니다. 그래서 이번 MVP(최소 기능 제품)에서는 가장 많이 쓰이는 이 두 가지를 주로 사용할 예정입니다.

GET과 POST, 언제 쓰는지 정리해 봅시다. 기준은 아주 간단합니다.

GET — 데이터를 "달라"고 할 때
예: "리뷰 목록 보여줘", "분석 결과 보여줘"
POST — 데이터를 "보낼" 때
예: "새 리뷰 저장해줘", "이거 분석해줘"

한 문장으로 외우세요. 달라고 하면 GET, 보내면 POST.

여기서 36차시의 CRUD와 자연스럽게 연결됩니다. CRUD는 Create(생성)·Read(조회)·Update(수정)·Delete(삭제)였죠. REST 메서드와 짝을 맞춰 보면 이렇게 똑 떨어집니다.

CRUD	REST 메서드	데이터베이스(SQL)
Create(생성)	POST	INSERT
Read(조회)	GET	SELECT
Update(수정)	PUT	UPDATE
Delete(삭제)	DELETE	DELETE

이름만 달라졌을 뿐 같은 개념입니다. 데이터를 새로 만들고(Create=POST=INSERT), 읽고(Read=GET=SELECT), 고치고, 지우는 — 결국 데이터를 다루는 네 가지 기본 동작이 화면·API·데이터베이스에서 각각 다른 이름으로 불릴 뿐입니다.

5. FastAPI — Python 몇 줄로 API 서버 만들기

이제 실제로 API를 만들어 봅니다. 사용할 도구는 FastAPI입니다. "Fast"는 빠르다는 뜻이죠. 이름 그대로 빠르게 API를 만들 수 있고, 성능도 강력합니다. Python 코드 몇 줄로 API 서버가 완성되는 걸 직접 경험해 봅시다.

FastAPI의 장점은 네 가지입니다.

빠른 개발 — 코드 몇 줄이면 API가 완성됩니다.
Python — 우리가 아는 Python으로 그대로 작성합니다. 새 언어를 배울 필요가 없습니다.
자동 문서화 — API 문서가 자동으로 만들어집니다. 따로 문서 작업을 하지 않아도 됩니다.
타입 검증 — 잘못된 형식의 데이터를 자동으로 걸러 주는 기능이 내장돼 있습니다.

중요: 이번 차시부터는 Colab이 아니라 로컬 환경(내 컴퓨터)에서 실습합니다. 지금까지는 Colab에서 코드를 돌렸지만, API 서버는 계속 켜져 있어야 하고, 코드를 파일로 저장해야 하며, 터미널에서 명령어로 실행해야 합니다. Colab은 세션이 끊기면 끝이라 서버를 띄우기에 적합하지 않습니다. 34차시에서 설정한 VS Code(또는 Cursor) + Python 환경을 사용합니다. (아래 노트북 셀들은 코드 구조를 눈으로 확인하는 용도이고, 실제 실행은 로컬 main.py 파일에서 합니다.)

FastAPI 설치하기

먼저 가상환경을 활성화합니다. 34차시에서 만든 가상환경을 기억하시죠? 활성화는 매번 가장 먼저 챙겨야 할 습관입니다. 가상환경은 프로젝트마다 라이브러리를 따로 담아 두는 격리된 공간이라고 보시면 됩니다.

터미널을 열고, 가상환경 폴더가 있는지 dir(Windows) 또는 ls로 확인한 다음 활성화합니다. 그러고 나서 FastAPI와, 서버를 실행할 도구인 uvicorn을 설치합니다. (FastAPI 자체에는 서버를 가동하는 기능이 없어서, uvicorn이라는 별도 서버가 필요합니다.)

# 1) 가상환경 활성화 (Windows 예시)
venv\Scripts\activate
# Mac/Linux라면: source venv/bin/activate

# 2) FastAPI와 uvicorn(서버 실행 도구) 설치
pip install fastapi uvicorn

Hello World API 만들기 — 4단계

이제 가장 기본적인 API를 직접 만들어 보겠습니다. "Hello World!"를 돌려주는 API입니다. 만드는 순서는 네 단계입니다.

FastAPI 불러오기 — from fastapi import FastAPI
앱 객체 만들기 — app = FastAPI(). 이 app이 우리 백엔드가 동작하는 기본 모체가 됩니다.
경로(엔드포인트) 만들기 — 어떤 주소로 요청이 오면 처리할지 정합니다.
함수 정의하기 — 그 요청이 오면 무엇을 응답할지 함수로 작성합니다.

코드로 보면 이렇게 다섯 줄 정도입니다.

# 1) FastAPI 불러오기
from fastapi import FastAPI

# 2) 앱 객체 만들기 (이 app이 백엔드 서버의 본체)
app = FastAPI()

# 3) "/hello" 주소로 GET 요청이 오면  →  4) 아래 함수를 실행
@app.get("/hello")
def hello():
    # return으로 보낸 이 딕셔너리가 JSON 형식으로 응답됩니다
    return {"message": "Hello World!"}

코드를 한 줄씩 뜯어보겠습니다.

코드	무슨 뜻인가
`from fastapi import FastAPI`	FastAPI 라이브러리를 가져옵니다
`app = FastAPI()`	FastAPI 인스턴스를 만들어 `app` 변수에 담습니다 (= 앱 객체 생성)
`@app.get("/hello")`	`/hello` 주소로 GET 방식 요청이 오면, 아래 함수를 실행하라는 뜻
`def hello():`	요청이 왔을 때 실행될 함수
`return {"message": "Hello World!"}`	이 데이터를 응답으로 보내라 — Python에서는 딕셔너리로 쓰지만, 웹에서는 JSON 형식으로 변환되어 나갑니다

여기서 @app.get(...) 앞의 @ 기호(데코레이터)와 그 안의 문자열이 핵심입니다. @app.get은 "GET 방식으로 받겠다"는 뜻이고, 따옴표 안의 "/hello"는 우리가 약속한 주소입니다. 이 주소는 자유롭게 정할 수 있습니다. 단순히 print("Hello World")로 화면에 찍는 게 아니라, 웹에서 동작하는 REST API를 만드는 게 목적이라서 반드시 응답(return)이 있어야 하고, 그 응답은 보통 딕셔너리(키-값) 형태로 구성합니다. 주소와 함수를 연결하는 것, 이것이 바로 API 엔드포인트입니다.

서버 실행하기

이제 이 코드를 파일로 저장하고 서버를 띄워야, 브라우저로 접속해 결과를 볼 수 있습니다.

먼저 하나의 프로젝트는 별도의 디렉토리로 관리하는 것을 원칙으로 삼으세요. 여러 데모 파일이 뒤섞인 폴더에서 작업하면 나중에 실행할 때 에러가 나거나 관리가 불편해집니다. 그래서 새 폴더를 하나 만들고, 그 안에서 VS Code/Cursor를 여는 게 정석입니다.

# 1) 프로젝트 폴더 만들고 들어가기
mkdir review-api
cd review-api

# 2) 가상환경 생성 및 활성화 (이미 만들었다면 활성화만)
python -m venv venv
venv\Scripts\activate          # Windows
# source venv/bin/activate     # Mac/Linux

# 3) 패키지 설치
pip install fastapi uvicorn

그다음 위에서 작성한 코드를 main.py라는 이름으로 저장합니다. 파일 이름은 자유지만 보통 main이나 app을 씁니다. (Cursor/VS Code에서 코드를 칠 때 자동완성으로 흐릿하게 뜨는 제안을 Tab 키로 받으면 개발 속도가 훨씬 빨라집니다.)

저장했으면 터미널에서 서버를 실행합니다. 이때도 가장 먼저 가상환경이 활성화돼 있는지 꼭 확인하세요.

# main.py 안의 app 객체를 서버로 띄운다
uvicorn main:app --reload

이 명령을 풀어 보면: - uvicorn — 서버를 실행하는 도구 - main — main.py 파일을 가리킵니다 (파일 이름을 바꿨다면 이 부분도 바꿉니다) - app — 그 파일 안에서 우리가 만든 app 변수(=FastAPI 인스턴스) - --reload — 코드를 고치면 서버를 껐다 켜지 않아도 자동으로 다시 불러와(reload) 반영해 주는 옵션. 개발 단계에서 거의 필수입니다.

엔터를 치면 서버가 가동되고, 터미널에 접속 주소가 뜹니다. 보통 http://127.0.0.1:8000 형태입니다. 여기서 127.0.0.1은 "내 컴퓨터"라는 뜻이고, 8000은 8000번 포트를 뜻합니다. 즉 "내 컴퓨터의 8000번 포트에서 우리 API 서버가 동작 중"이라는 의미입니다. (localhost도 127.0.0.1과 똑같이 "내 컴퓨터"를 가리키는 표현입니다.)

이제 브라우저를 열고 주소를 칩니다. 여기서 일부러 한 번 실패부터 해 봅시다. 먼저 경로 없이 http://localhost:8000/만 쳐 보세요. 아무 내용도 안 나오거나 "Not Found" 같은 메시지가 뜰 겁니다. 당황하지 마세요. 이게 정상입니다. 왜 그럴까요? 우리는 함수를 /(맨 끝 슬래시, 즉 빈 경로)가 아니라 /hello라는 경로에 연결해 뒀기 때문입니다. 주소 뒤를 비워 두면 "연결된 함수가 없는 주소"를 요청한 셈이라 응답이 없는 거죠.

그러니 주소 끝에 우리가 정한 경로 /hello를 꼭 붙여야 합니다.

http://localhost:8000/ → 아무것도 안 나옵니다 (이 주소에는 함수를 연결해 두지 않았으니까요)
http://localhost:8000/hello → {"message": "Hello World!"} 라는 응답이 보입니다

빈 화면을 먼저 보고 나면 원인이 또렷해집니다. 우리가 함수를 /hello 주소에 연결했기 때문에, 정확히 그 주소로 요청해야 응답이 옵니다. 서버를 끄려면 터미널에서 Ctrl + C를 누릅니다.

자동 API 문서 — Swagger UI

FastAPI의 강력한 장점 하나를 보여드리겠습니다. 주소 끝에 /docs를 붙여 접속해 보세요.

http://localhost:8000/docs

그러면 Swagger UI라는 형태의 자동 생성된 API 문서 페이지가 열립니다. 우리가 따로 문서를 만들지 않았는데도, 만들어 둔 엔드포인트들이 한눈에 나열됩니다. 지금은 /hello 하나만 만들어서 하나만 보이지만, 기능을 추가할수록 그 아래에 쭉 나열됩니다.

각 엔드포인트를 클릭하면 상세 내용이 펼쳐지고, 오른쪽의 Try it out(직접 테스트) 버튼을 누른 뒤 Execute(실행)를 누르면, 약속된 주소로 실제 요청을 보내 응답을 바로 확인할 수 있습니다. 이때 상태 코드(status code)도 함께 표시됩니다.

200번대: 정상
400번대: 사용자(요청) 오류
500번대: 서버 오류

이렇게 브라우저에서 클릭 몇 번으로 API를 테스트할 수 있다는 것, 이게 FastAPI의 큰 장점입니다.

6. 우리 앱에 필요한 API 설계하기

같은 원리로 여러 API를 직접 만들 수 있습니다. 그럼 우리 리뷰 분석 앱에는 어떤 API가 필요할까요? 35차시에서 설계한 내용을 떠올려 보면 이렇게 정리됩니다.

기능	메서드 + 경로	설명
리뷰 조회	`GET /reviews`	저장된 리뷰 목록 가져오기
리뷰 저장	`POST /reviews`	새 리뷰 데이터 저장하기
분석 요청	`POST /analyze`	리뷰 분석을 요청하기
결과 조회	`GET /results`	분석 결과 가져오기

규칙을 다시 떠올리면 쉽습니다. 달라고 하는 조회는 GET, 데이터를 보내는 저장·분석요청은 POST. 리뷰 저장의 POST는 CRUD의 Create와 짝을 이루는 거죠.

이제 Hello World를 넘어서, 실제로 리뷰를 조회·저장하는 API를 만들어 봅시다. 아직 데이터베이스를 연결하기 전이라, 임시로 리스트를 "가짜 데이터베이스"처럼 써서 구조를 익히겠습니다. (나중에 이 부분을 진짜 SQLite로 교체합니다.)

from fastapi import FastAPI
from pydantic import BaseModel   # 입력 데이터의 형식을 정의하는 도구
from typing import Optional      # "있어도 되고 없어도 되는" 선택 항목을 표시할 때 사용

# 앱 객체 생성 (제목과 버전을 주면 자동 문서에 그대로 표시됩니다)
app = FastAPI(title="리뷰 분석 API", version="0.1.0")

# 임시 데이터 저장소 (DB 대신 쓰는 가짜 리스트)
fake_reviews = [
    {"id": 1, "content": "정말 재밌는 게임이에요!", "sentiment": "긍정"},
    {"id": 2, "content": "버그가 너무 많아요.", "sentiment": "부정"},
]

# POST로 새 리뷰를 받을 때, 어떤 형식으로 받을지 정의하는 모델
class ReviewCreate(BaseModel):
    content: str                      # 필수: 문자열 (리뷰 내용)
    sentiment: Optional[str] = None   # 선택: 문자열 또는 없음 (감성)

# GET /reviews  →  리뷰 목록 조회
@app.get("/reviews")
def get_reviews():
    return {"reviews": fake_reviews, "count": len(fake_reviews)}

# POST /reviews  →  새 리뷰 추가
@app.post("/reviews")
def create_review(review: ReviewCreate):
    new_id = len(fake_reviews) + 1            # 새 id는 현재 개수 + 1
    new_review = {
        "id": new_id,
        "content": review.content,
        "sentiment": review.sentiment,
    }
    fake_reviews.append(new_review)           # 가짜 DB(리스트)에 추가
    return {"message": "리뷰 추가 완료", "review": new_review}

# GET /  →  기본 인사 (접속 확인용)
@app.get("/")
def root():
    return {"message": "리뷰 분석 API에 오신 것을 환영합니다!"}

위 응답값(메시지·개수 등)은 예시이며, 입력한 데이터에 따라 달라집니다.

여기서 새로 나온 게 Pydantic 모델입니다. POST 요청으로 데이터를 받을 때, 어떤 형식으로 받을지 미리 정의해 두는 장치입니다.

class ReviewCreate(BaseModel):
    content: str                      # 반드시 있어야 하는 문자열
    sentiment: Optional[str] = None   # 없어도 되는 선택 항목

이렇게 정의해 두면 FastAPI가 알아서: - 필수 필드(content)가 없으면 자동으로 에러를 냅니다. - 타입이 틀리면(예: 숫자를 넣으면) 자동으로 에러를 냅니다. - 이 형식이 API 자동 문서에도 그대로 반영됩니다.

앞에서 말한 FastAPI의 네 번째 장점, "타입 검증"이 바로 이 Pydantic 모델로 동작하는 겁니다. 잘못된 데이터를 우리가 일일이 검사하지 않아도 FastAPI가 자동으로 걸러 줍니다.

이 코드를 main.py로 저장하고 uvicorn main:app --reload로 띄운 뒤, http://localhost:8000/docs에 들어가면 /reviews(GET·POST) 엔드포인트가 보입니다. POST는 Try it out에서 content만 입력해도 바로 새 리뷰가 추가되는 걸 클릭만으로 테스트할 수 있습니다.

7. 지금까지 온 길, 그리고 전체 흐름

오늘로 우리 앱의 큰 그림이 한 단계 더 채워졌습니다. 설계대로 차근차근 진행되고 있는지 확인해 봅시다.

35차시: 설계 — 사용자·요구사항·기능·화면 정의
36~37차시: DB — SQLite + 테이블 2개(reviews, analysis_results) + CRUD
오늘(백엔드 기초): API — FastAPI로 백엔드 첫발, Hello World API 구성
다음: 화면 — Streamlit으로 프론트엔드 만들기

이렇게 설계 → 데이터베이스 → 백엔드 → 프론트엔드 순서로 3-tier가 하나씩 완성되고 있습니다. 무엇보다, 여러분이 어떤 기능을 떠올렸을 때 "아, 이건 GET으로 만들면 되겠다", "이건 POST겠네" 하는 생각이 자연스럽게 떠오른다면, 우리는 아주 성공적으로 진행하고 있는 겁니다.

🔑 핵심 용어

용어	쉬운 설명
백엔드(Backend)	화면 뒤에서 실제 일을 처리하는 "앱의 두뇌". 3-tier 구조에서 프론트엔드와 데이터베이스 사이
3-tier 구조	앱을 프론트엔드·백엔드·데이터베이스 세 계층으로 나눈 구조
API	코드끼리 데이터를 주고받는 방법. 손님(화면)과 주방(서버)을 잇는 "웨이터"
요청 / 응답(Request / Response)	클라이언트가 "이거 해줘"(요청) → 서버가 "결과야"(응답). API의 두 핵심
REST API	웹에서 가장 많이 쓰는 API 규칙(형식). HTTP 메서드로 요청 종류를 구분
HTTP 메서드	GET(조회)·POST(생성)·PUT(수정)·DELETE(삭제). CRUD와 일대일로 대응
엔드포인트(Endpoint)	"주소 + 함수"의 연결. 어떤 주소로 요청이 오면 어떤 함수를 실행할지 정한 것
FastAPI	Python 몇 줄로 API 서버를 만드는 도구. 자동 문서화·타입 검증 내장
uvicorn	FastAPI 서버를 실제로 실행해 주는 도구(서버 프로그램)
`@app.get` / `@app.post`	그 주소를 GET / POST 방식으로 받겠다고 표시하는 데코레이터
Pydantic 모델(BaseModel)	POST로 받을 입력 데이터의 형식을 정의 → 필수/타입을 자동 검증
JSON	키-값 형태의 데이터 교환 형식. Python 딕셔너리가 응답될 때 이 형식으로 변환됨
Swagger UI(`/docs`)	FastAPI가 자동 생성하는 API 문서 겸 테스트 페이지
상태 코드	200=정상, 400번대=사용자 오류, 500번대=서버 오류
localhost / 127.0.0.1	둘 다 "내 컴퓨터"를 뜻하는 주소. 뒤의 `:8000`은 8000번 포트

🎮 게임 기획자 시점

지금까지 우리는 리뷰를 수집하고(1주차), 정제하고(2주차), LLM으로 감성·키워드를 분석하고(3주차), 그 결과의 신뢰도까지 다뤘습니다(4주차). 그런데 그 분석 결과가 분석가의 노트북 안에만 있으면 다른 사람은 볼 수 없습니다. 백엔드와 API는 바로 이 "분석 결과를 대시보드(프론트)로 전달하는 핵심 연결고리"입니다. GET /results 한 줄이 곧 "기획자·운영팀이 브라우저에서 분석 결과를 조회하는 통로"가 되는 거죠.

기획자가 시스템 구조(화면-백엔드-DB)를 이해하면, 엔지니어와 대화할 때 "이 화면에 이 데이터를 보여주려면 어떤 API가 필요하다"는 식으로 기능을 API 단위로 요청할 수 있습니다. 예컨대 "부정 리뷰 급증 알림"을 기획한다면, 그건 GET /results에 기간·감성 필터를 더한 엔드포인트로 풀린다는 걸 떠올릴 수 있죠. GET/POST와 CRUD의 대응을 아는 것만으로도, 기획서가 곧바로 구현 가능한 명세에 가까워집니다.

⚠️ 흔한 오해 / 짚고 갈 점

API는 무슨 특별한 프로그램이 아니라 "약속된 통로"입니다. 손님이 주방에 직접 못 들어가듯, 화면은 데이터베이스를 직접 만지지 않고 반드시 API(웨이터)를 거칩니다.
GET과 POST를 헷갈리지 마세요. "달라고 하면 GET(조회), 데이터를 보내면 POST(생성)"입니다. 새 리뷰 저장은 데이터를 보내는 것이니 POST입니다.
주소 끝의 경로를 빠뜨리면 응답이 안 옵니다. localhost:8000만 치면 빈 화면이고, localhost:8000/hello처럼 우리가 연결해 둔 경로까지 정확히 적어야 합니다.
return한 딕셔너리는 그냥 출력되는 게 아니라 JSON 응답으로 나갑니다. print로 화면에 찍는 것과 다릅니다. API는 웹으로 데이터를 "보내는" 것이 목적입니다.
이번 차시부터는 Colab이 아니라 로컬에서 실습합니다. 서버는 계속 켜져 있어야 하고 main.py 파일로 저장해 uvicorn으로 띄워야 하므로, Colab은 적합하지 않습니다.
프로젝트는 별도 폴더로 관리하세요. 다른 데모 파일들과 섞인 폴더에서 작업하면 실행 에러나 관리 문제가 생기기 쉽습니다. 새 폴더를 만들고 그 안에서 에디터를 여는 게 정석입니다.
--reload는 개발용 옵션입니다. 코드를 고칠 때마다 서버를 껐다 켜지 않아도 자동 반영되니 편하지만, 실제 배포(운영) 환경에서는 보통 빼고 띄웁니다.

✅ 30초 정리

API는 웨이터입니다 — 화면(손님)과 서버(주방) 사이에서 요청을 받아 전달하고 응답을 가져다줍니다.
GET은 조회, POST는 생성입니다 — "달라고 하면 GET, 보내면 POST". (PUT=수정, DELETE=삭제이며 CRUD와 일대일로 대응)
FastAPI로 다섯 줄이면 API 완성 — main.py에 작성하고 uvicorn main:app --reload로 서버를 띄우면, Python으로 빠르고 강력한 백엔드 API가 만들어지고 /docs에서 바로 테스트까지 됩니다.

▶️ 다음 강 연결

오늘은 Hello World 수준의 연습용 API를 만들어 봤습니다. 다음 강 API 설계와 보안에서는 진짜 우리 앱에 쓸 API 엔드포인트를 제대로 설계하고, 무엇보다 API 키 관리를 배웁니다. Colab에서 Secrets로 키를 숨겼던 것처럼, 이제 로컬 환경에서는 환경변수로 키를 안전하게 다루는 법, 그리고 나중에 앱을 클라우드에 올릴 때도 문제없도록 보안 실수를 예방하는 법을 익힙니다.