Question 1

LLM의 응답 지연 문제를 사용자 경험 측면에서 어떻게 해결할 수 있나요?

Accepted Answer

LLM 응답은 수 초에서 수십 초가 걸립니다. **지연 자체를 없앨 수 없다면, 체감 지연(perceived latency)을 줄이는 것**이 프론트엔드의 역할입니다.

## 1. 스트리밍 — 가장 효과적

전체 응답을 기다리지 않고 **첫 토큰이 오는 즉시** 화면에 표시합니다. 총 소요 시간은 같아도 체감은 완전히 달라집니다.

핵심 지표는 **TTFT(Time To First Token)**입니다. 전체 완료 시간보다 TTFT가 사용자 만족도에 훨씬 크게 기여합니다.

```tsx
const [text, setText] = useState('');
for await (const chunk of stream) setText(prev => prev + chunk);
```

## 2. 즉각적 피드백 (Optimistic UI)

전송 버튼을 누른 **즉시** 사용자 메시지를 목록에 추가하고 입력창을 비웁니다. 서버 왕복을 기다리지 않습니다.

```tsx
const [optimis

Question 2

생성형 AI 채팅 UI에서 중단 기능을 구현한다면 어떤 기술을 사용할 수 있나요?

Accepted Answer

## 핵심 도구: `AbortController`

Fetch API의 표준 취소 메커니즘입니다.

```tsx
function useChat() {
  const [text, setText] = useState('');
  const [isStreaming, setStreaming] = useState(false);
  const controllerRef = useRef<AbortController | null>(null);

async function send(prompt: string) {
    controllerRef.current?.abort();               // 이전 요청 정리
    const controller = new AbortController();
    controllerRef.current = controller;
    setStreaming(true);

try {
      const res = await fetch('/api

Question 3

RAG 구조에서 프런트엔드 개발자의 역할은 무엇이라고 생각하나요?

Accepted Answer

## RAG란 RAG(Retrieval-Augmented Generation)는 **외부 지식을 검색해 프롬프트에 주입한 뒤 LLM이 답변하게 하는 구조**입니다. 모델이 학습하지 않은 최신·사내 데이터를 다루고, 환각을 줄이며, 출처를 제시할 수 있게 합니다. ``` 질문 → 임베딩 → 벡터 검색 → 관련 청크 추출 → 프롬프트 조립 → LLM → 답변 + 출처 ``` 검색·임베딩·벡터DB는 대체로 백엔드 영역이지만, **RAG의 성패는 상당 부분 UI에서 갈립니다.** ## 프론트엔드의 역할 ### 1. 출처(Citation) UI — RAG의 존재 이유 RAG를 쓰는 가장 큰 이유가 "근거 있는 답변"인데, 이걸 **사용자가 확인할 수 있게 만드는 것이 프론트엔드**입니다. ```tsx

App Router는 서버 컴포넌트가 기본입니다.

{/* 문서명,

Question 4

이미지를 멀티모달 모델에 보낼 때 Base64 인코딩 방식과 멀티파트 방식 중 어떤 방식을 선호할까요?

Accepted Answer

## 두 방식

**Base64 (JSON 인라인)**
```json
{
  "messages": [{
    "role": "user",
    "content": [
      { "type": "image", "source": { "type": "base64", "media_type": "image/jpeg", "data": "/9j/4AAQ..." } },
      { "type": "text", "text": "이 이미지를 설명해줘" }
    ]
  }]
}
```

**멀티파트 (`multipart/form-data`)**
```ts
const fd = new FormData();
fd.append('image', file);          // 바이너리 그대로
fd.append('prompt', '설명해줘');
await fetch('/api/vision', { method: 'POST', body: fd });
```

## 비교

| 항목 | Base64 | 멀

Question 5

고화질 사진을 업로드할 때 토큰 비용을 아끼고 처리 속도를 높이는 방법은 무엇인가요?

Accepted Answer

## 왜 중요한가

멀티모달 모델은 이미지를 **타일 단위로 쪼개 토큰으로 환산**합니다. 해상도가 커질수록 토큰이 급증하고, 이는 비용과 지연에 직결됩니다.

```
4000×3000 원본  →  수천 토큰
1024×768 리사이즈 →  수백 토큰
```

**결정적 사실: 모델의 최대 입력 해상도를 넘는 이미지는 어차피 내부적으로 축소됩니다.** 큰 이미지를 보내는 것은 대역폭만 낭비하고 정확도 이득은 없습니다.

## 1. 클라이언트 리사이즈 — 가장 효과가 큼

업로드 **전에** 브라우저에서 줄입니다.

```ts
async function resize(file: File, maxSide = 1568, quality = 0.85): Promise<Blob> {
  const bitmap = await createImageBitmap(file);
  const scale = Math.min(1, maxSide / Math.max(bitmap.width, bitmap.heigh

Question 6

LLM의 텍스트 응답을 구현할 때 SSE와 웹소켓 중 어떤 것을 선호하나요?

Accepted Answer

## 결론 먼저

**LLM 텍스트 스트리밍에는 SSE(정확히는 fetch + ReadableStream)를 선호합니다.** 통신이 본질적으로 **단방향(서버→클라이언트)**이기 때문입니다. 요청-응답 모델에 정확히 맞고 인프라가 단순합니다.

## 비교

| 항목 | SSE | WebSocket |
| --- | --- | --- |
| 방향 | **서버 → 클라이언트 단방향** | 양방향 |
| 프로토콜 | HTTP (그대로) | 별도 핸드셰이크 후 업그레이드 |
| 재연결 | **자동** (`EventSource`) + `Last-Event-ID` | 직접 구현 |
| 프록시·방화벽 | HTTP라 문제 없음 | 일부 환경에서 차단 |
| HTTP/2 다중화 | ⭕ | ❌ 별도 연결 |
| 인증 | 쿠키·헤더 그대로 | 핸드셰이크 시 별도 처리 필요 |
| 압축·캐싱 | HTTP 인프라 활용 | 별도 |
| 서버 부하 | 연결당 가벼움 | 상태 유지 필요 |
| 데이터 | 텍스트

AI 프론트엔드

01LLM의 응답 지연 문제를 사용자 경험 측면에서 어떻게 해결할 수 있나요?보통UX

02생성형 AI 채팅 UI에서 중단 기능을 구현한다면 어떤 기술을 사용할 수 있나요?보통스트리밍

03RAG 구조에서 프런트엔드 개발자의 역할은 무엇이라고 생각하나요?보통RAG

04이미지를 멀티모달 모델에 보낼 때 Base64 인코딩 방식과 멀티파트 방식 중 어떤 방식을 선호할까요?보통멀티모달

05고화질 사진을 업로드할 때 토큰 비용을 아끼고 처리 속도를 높이는 방법은 무엇인가요?보통멀티모달

06LLM의 텍스트 응답을 구현할 때 SSE와 웹소켓 중 어떤 것을 선호하나요?보통스트리밍