Frontend는 모델을 실행하지 않는다

실제 파일과 학습 문서의 대응

TSX 파일은 브라우저가 그대로 실행할 수 없다

현재 npm run build는 tsc -b로 type을 검사한 뒤 vite build로 배포 파일을 만든다. npm run dev로 Vite 개발 서버를 띄운다는 사실만으로 별도 TypeScript 검사가 모두 수행되는 것은 아니다.

App.tsx에는 HTML처럼 보이는 JSX와 TypeScript type이 들어 있다. 브라우저의 JavaScript engine은 TypeScript type을 해석하지 못하므로 build 단계가 필요하다.

Source에서 browser까지

현재 App.tsx는 무엇을 실제로 하는가?

const [sidebarOpen, setSidebarOpen] = useState(false)
const [prompt, setPrompt] = useState('')
const [messages, setMessages] = useState<string[]>([])
const send = () => { const text = prompt.trim(); if (!text) return; setMessages((current) => [...current, text]); setPrompt('') }

현재 messages는 role·content 객체 배열이 아니라 string[]이다. send는 입력 공백을 정리하고 빈 문자열을 거절한 뒤, 사용자 문장을 배열에 추가하고 입력 상자를 비운다. 각 문장 밑에는 “FastAPI가 연결되면…”이라는 고정 안내 문구를 표시한다. 실제 HTTP 요청, assistant 응답 저장, streaming, isGenerating은 아직 없다. 한 줄씩 해설과 실제 값 추적은 App.tsx 상세 문서에 있다.

최근 대화 목록·모델 선택·검색·보관 버튼도 현재는 예시 UI이며 API와 연결된 기능이 아니다. 이 단계의 동작 확인은 입력·전송·초기화·반응형 배치를 보는 것이다. Gemma 답변 생성과 대화 영구 저장까지 구현됐다는 뜻이 아니다.

Streaming 연결 후 목표로 하는 데이터 변화

채팅 UI의 핵심은 메시지 배열과 생성 상태다. 예를 들어 초기 state가 []이고 사용자가 “안녕”을 보내면 사용자 메시지가 추가된다. 서버가 streaming을 시작하면 비어 있는 assistant 메시지를 만들고, 도착하는 text 조각을 같은 항목에 누적한다.

위 메시지 구조와 스트리밍 단계는 향후 설계 예시이며 현재 App.tsx의 실행 결과가 아니다. 그때 isGenerating 같은 boolean state를 함께 두면 중복 전송을 막고 중지 버튼이나 loading indicator를 표시할 수 있다. 네트워크 오류가 발생하면 이미 입력한 사용자 메시지는 유지하면서 assistant 항목에 재시도 가능한 오류 상태를 표시하는 편이 좋다.