Module 2B · Project — chat-app

2B.1 · The big picture — now three servers

1편의 "프론트 + 백" 구조는 그대로인데, 이제 백엔드가 바깥의 LLM API(Claude)에게 한 번 더 물어봅니다.

ft_transcendence에서 SPA + 백엔드 + 외부 서비스(OAuth 등)를 엮었던 경험과 같은 모양이에요. 새로 끼어든 셋째 참가자(LLM)가 느리고, 가끔 실패하고, 돈이 든다는 점만 기억하면 됩니다.

2B.2 · Memory — why the bot forgets your name (stateless)

LLM API는 이전 대화를 기억하지 않습니다. 매 요청마다 지난 대화 전부를 다시 보내줘야 "기억하는 것처럼" 보입니다.

지금 Projects/Module_02_chat-app/backend/app.py는 현재 메시지 한 개만 보냅니다:

resp = client.messages.create(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": user_message}],  # ← 딱 한 줄, 과거 없음
)

그래서 "My name is Alex." → "What is my name?" 순서로 보내면, 두 번째 요청에는 첫 문장이 들어 있지 않아 봇이 모릅니다. 고치려면 messages 배열에 대화 전체를 쌓아 보내야 해요:

messages = [
    {"role": "user",      "content": "My name is Alex."},
    {"role": "assistant", "content": "Nice to meet you, Alex!"},
    {"role": "user",      "content": "What is my name?"},   # 이제 위 맥락을 본다
]

2B.3 · Async & loading — what does the UI do while it waits?

LLM 답변은 몇 초 걸립니다. 그 사이 화면이 "멈춘 듯" 보이지 않게 하려면 로딩 상태를 직접 만들어야 합니다.

지금 App.jsx의 send는 이렇게 끝납니다:

const res = await fetch('/api/chat', { ... })  // ← 여기서 몇 초 멈춤
const data = await res.json()
setMessages((m) => [...m, { role: 'assistant', text: data.reply }])

await는 "답이 올 때까지 기다린다"는 뜻이에요. 그 몇 초 동안 로딩 표시도, 입력칸 잠금도 없습니다. 사용자는 버튼을 또 누르거나 "고장 났나?" 싶어집니다. 보통 isLoading 같은 상태를 두고, 요청 직전 true, 응답 후 false로 바꿔 "..." 표시와 버튼 비활성화를 제어합니다.

2B.4 · Network failure — what if the backend is down?

백엔드가 죽어 있으면 fetch가 거부(reject)되고, 지금 코드엔 그걸 잡는 장치가 없어 조용히 깨집니다.

const res = await fetch('/api/chat', { ... })  // 백엔드 down → 여기서 throw!
const data = await res.json()                  // ← 도달조차 못 함

fetch가 실패하면 예외가 던져지는데, send 함수엔 try/catch가 없습니다. 그래서 에러는 콘솔에만 찍히고 화면엔 아무 안내가 없어요. 고치는 자리는 App.jsx의 send 함수입니다 — try/catch로 감싸고, 실패 시 messages에 "⚠️ 연결 실패" 같은 메시지를 넣어 주면 됩니다.

2B.5 · API errors — 5xx · rate limit · bad key

Claude API가 5xx를 주거나, 너무 자주 호출해 막히거나(429), 키가 틀리면(401) messages.create()가 예외를 던집니다. 지금 app.py엔 이를 잡는 try/except가 없습니다.

예외를 안 잡으면 Flask가 500 + HTML 에러 페이지를 토해내고, 프론트의 res.json()도 깨질 수 있어요. anthropic SDK는 상황별로 타입이 다른 예외를 주니, 골라서 잡으면 됩니다:

import anthropic

try:
    resp = client.messages.create(...)
except anthropic.RateLimitError:      # 429: 너무 자주 호출
    return jsonify(error="잠시 후 다시 시도해 주세요"), 429
except anthropic.AuthenticationError: # 401: 키가 틀림
    return jsonify(error="API 키 설정을 확인하세요"), 500
except anthropic.APIStatusError as e: # 500/529 등 서버 쪽 문제
    return jsonify(error="LLM 서버 오류, 잠시 후 재시도"), 502

2B.6 · Input validation & other gaps

request.json["message"]는 요청 모양이 조금만 어긋나도 터집니다. 그 외에도 영속성·스트리밍 등 "진짜 앱"의 조각들이 빠져 있어요.

user_message = request.json["message"]  # 키가 없으면 KeyError → 500

대표적으로 더 빠진 것들:

• 입력 검증 — 빈 메시지, message 키 누락, JSON 아님 → 친절한 400으로 막기
• 영속성(DB) — 새로고침하면 대화가 사라짐(메모리에만 있음)
• 스트리밍 — 답이 한 번에 "툭" 나옴. 글자가 흐르듯 나오게 하려면 streaming 필요
• 인증·남용 방지 — 누구나 호출 가능 → API 비용 폭탄 위험

2B.7 · Find the 5 bugs (read the code)

이제 개념을 무기로, 실제 연습 문제에 답해 봅니다. 먼저 스스로 답을 떠올린 뒤 펼쳐서 맞춰 보세요. 1번은 당신이 직접 채울 차례입니다.