Hono 기반 서버 API 완벽 가이드

Hono 프레임워크를 활용한 서버 API 구축 방법을 알아봅니다. 클라이언트/서버 아키텍처부터 OpenAPI 스펙 자동 생성, SSE 이벤트 스트리밍까지 실무에서 바로 활용할 수 있는 핵심 개념을 다룹니다.

---

목차

1. 클라이언트_서버_아키텍처_이해
2. server_ts_파일_분석
3. Hono_프레임워크_소개
4. OpenAPI_스펙_자동_생성
5. SSE_기반_이벤트_스트리밍
6. Session_Provider_Config_API

---

1. 클라이언트 서버 아키텍처 이해

어느 날 김개발 씨가 회사에서 새로운 프로젝트를 맡게 되었습니다. "이번 프로젝트는 프론트엔드와 백엔드를 분리해서 개발할 거예요." 선배의 말에 김개발 씨는 고개를 갸웃거렸습니다.

분리한다는 게 정확히 무슨 의미일까요?

클라이언트/서버 아키텍처는 한마디로 역할을 분담하는 것입니다. 마치 식당에서 손님이 주문하고 주방에서 요리하는 것처럼, 클라이언트는 요청을 보내고 서버는 그 요청을 처리합니다.

이것을 제대로 이해하면 확장 가능하고 유지보수하기 쉬운 애플리케이션을 설계할 수 있습니다.

다음 코드를 살펴봅시다.

// 클라이언트: 서버에 요청을 보냅니다
const response = await fetch('http://localhost:3000/api/users', {
  method: 'GET',
  headers: {
    'Content-Type': 'application/json'
  }
});

// 서버로부터 응답을 받아 처리합니다
const users = await response.json();
console.log(users);

// 서버 측: 요청을 받아 데이터를 반환합니다
app.get('/api/users', (c) => {
  const users = database.getUsers();
  return c.json(users);
});

김개발 씨는 입사 3개월 차 주니어 개발자입니다. 이전까지는 간단한 웹페이지만 만들어봤기에, 프론트엔드와 백엔드를 분리한다는 개념이 낯설었습니다.

선배 개발자 박시니어 씨가 화이트보드 앞에 섰습니다. "자, 식당을 생각해봐요.

손님이 메뉴판을 보고 주문하면, 주방에서 요리해서 내오잖아요. 웹 애플리케이션도 똑같아요." 그렇다면 클라이언트/서버 아키텍처란 정확히 무엇일까요?

쉽게 비유하자면, 클라이언트는 식당의 손님이고 서버는 주방입니다. 손님이 "스테이크 하나요"라고 주문하면, 주방에서 스테이크를 굽고, 완성되면 손님에게 가져다 줍니다.

손님은 요리 방법을 알 필요가 없고, 주방은 손님이 누구인지 신경 쓸 필요가 없습니다. 각자의 역할에만 집중하면 됩니다.

이런 아키텍처가 없던 시절에는 어땠을까요? 모든 코드가 한 덩어리로 뒤섞여 있었습니다.

화면을 그리는 코드와 데이터를 처리하는 코드가 같은 파일에 있었죠. 작은 프로젝트에서는 괜찮았지만, 프로젝트가 커지면 문제가 생겼습니다.

한 곳을 수정하면 다른 곳이 망가지고, 여러 명이 동시에 작업하기도 어려웠습니다. 바로 이런 문제를 해결하기 위해 클라이언트/서버 아키텍처가 등장했습니다.

클라이언트와 서버를 분리하면 각 팀이 독립적으로 개발할 수 있습니다. 프론트엔드 개발자는 사용자 경험에 집중하고, 백엔드 개발자는 비즈니스 로직과 데이터 처리에 집중합니다.

무엇보다 서버 하나에 여러 종류의 클라이언트를 연결할 수 있다는 큰 장점이 있습니다. 위의 코드를 살펴보겠습니다.

먼저 클라이언트 측에서 fetch 함수를 사용해 서버에 요청을 보냅니다. 이때 URL과 HTTP 메서드를 지정합니다.

서버는 이 요청을 받아 데이터베이스에서 사용자 목록을 조회하고, JSON 형태로 응답합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 카카오톡 같은 메신저를 생각해보세요. 스마트폰 앱, 데스크톱 앱, 웹 버전 모두 같은 서버와 통신합니다.

서버는 메시지를 저장하고 전달하는 역할만 하고, 각 클라이언트는 자신의 플랫폼에 맞게 화면을 그립니다. 하지만 주의할 점도 있습니다.

클라이언트와 서버 사이의 통신 규약을 명확히 정해야 합니다. "어떤 주소로 요청하면 어떤 데이터가 오는지"를 문서화하지 않으면, 협업 과정에서 혼란이 생깁니다.

이것이 바로 API 명세가 중요한 이유입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 프론트엔드 팀과 백엔드 팀이 따로 있는 거군요!" 클라이언트/서버 아키텍처를 이해하면 현대적인 웹 개발의 기초를 다질 수 있습니다.

다음 장에서는 실제로 서버를 어떻게 구현하는지 살펴보겠습니다.

실전 팁

💡 - 클라이언트와 서버 사이의 통신은 항상 HTTP 프로토콜을 기반으로 합니다

• API 명세를 먼저 정의하고 개발을 시작하면 협업이 훨씬 수월해집니다

---

2. server ts 파일 분석

김개발 씨가 프로젝트 폴더를 열어보니 server.ts라는 파일이 눈에 들어왔습니다. "이게 서버의 시작점인가요?" 선배에게 물으니, 박시니어 씨가 웃으며 답했습니다.

"맞아요, 이 파일 하나로 서버의 모든 설정이 시작돼요."

server.ts는 서버 애플리케이션의 진입점입니다. 마치 건물의 현관문과 같아서, 모든 요청은 이 파일을 통해 들어옵니다.

이 파일에서 라우팅, 미들웨어, 포트 설정 등 서버의 핵심 구성을 정의합니다.

다음 코드를 살펴봅시다.

// server.ts - 서버의 진입점
import { Hono } from 'hono';
import { serve } from '@hono/node-server';
import { cors } from 'hono/cors';

// Hono 앱 인스턴스를 생성합니다
const app = new Hono();

// CORS 미들웨어를 적용합니다
app.use('/*', cors());

// 기본 라우트를 정의합니다
app.get('/', (c) => c.text('Hello, Hono!'));

// 서버를 시작합니다
serve({ fetch: app.fetch, port: 3000 });
console.log('Server is running on port 3000');

김개발 씨는 server.ts 파일을 열어보았습니다. 코드가 생각보다 짧아서 놀랐습니다.

이 작은 파일이 정말 서버의 모든 것을 담당한다고요? 박시니어 씨가 옆에서 설명을 시작했습니다.

"server.ts는 마치 건물의 현관문 같아요. 손님이 건물에 들어오면 안내 데스크에서 어디로 가야 하는지 알려주잖아요.

서버도 마찬가지예요." 그렇다면 server.ts 파일의 구조를 자세히 살펴볼까요? 첫 번째로 import 구문이 있습니다.

필요한 모듈들을 불러오는 부분입니다. Hono 프레임워크와 Node.js 서버 어댑터, 그리고 CORS 미들웨어를 가져옵니다.

다음으로 app 인스턴스를 생성합니다. new Hono()로 만들어진 이 객체가 서버의 심장입니다.

모든 라우트와 미들웨어가 이 객체에 등록됩니다. 미들웨어란 무엇일까요?

쉽게 말해 요청이 최종 목적지에 도달하기 전에 거치는 검문소입니다. 위 코드에서 cors() 미들웨어는 다른 도메인에서 오는 요청을 허용합니다.

이것이 없으면 브라우저가 보안상의 이유로 요청을 차단합니다. 라우트 정의 부분을 보겠습니다.

app.get('/', ...)은 루트 경로로 GET 요청이 오면 어떻게 응답할지 정의합니다. 여기서는 단순히 "Hello, Hono!"라는 텍스트를 반환합니다.

마지막으로 serve 함수가 서버를 실제로 시작합니다. 포트 3000번에서 요청을 기다리게 됩니다.

app.fetch를 전달하는 것이 중요한데, 이것이 Hono의 요청 처리 함수입니다. 실무에서는 이 기본 구조에 여러 가지를 추가합니다.

환경 변수로 포트를 설정하고, 에러 핸들링 미들웨어를 추가하고, 여러 라우터를 분리해서 관리합니다. 김개발 씨가 물었습니다.

"그런데 왜 모든 코드를 이 파일에 넣지 않고 분리하나요?" 박시니어 씨가 답했습니다. "좋은 질문이에요.

파일이 커지면 관리하기 어려워져요. 그래서 라우트별로 파일을 나누고, server.ts에서는 그것들을 조립만 해요.

마치 레고 블록처럼요." server.ts를 이해하면 서버 애플리케이션의 전체 구조가 보이기 시작합니다. 이제 다음 장에서 Hono 프레임워크가 무엇인지 더 자세히 알아보겠습니다.

실전 팁

💡 - server.ts는 가능한 한 간결하게 유지하고, 세부 로직은 별도 파일로 분리하세요

• 환경 변수를 활용해 포트 번호 등을 설정하면 배포 환경에 따라 유연하게 대응할 수 있습니다

---

3. Hono 프레임워크 소개

김개발 씨는 Express.js만 써봤기에 Hono라는 이름이 낯설었습니다. "Express 대신 Hono를 쓰는 이유가 뭐예요?" 박시니어 씨가 브라우저를 열며 말했습니다.

"성능과 편의성, 두 마리 토끼를 다 잡은 프레임워크거든요."

Hono는 초경량 웹 프레임워크로, Express.js보다 빠르고 현대적인 API를 제공합니다. 마치 경주용 자동차처럼 가볍고 빨라서, 엣지 컴퓨팅 환경부터 Node.js까지 어디서든 동작합니다.

TypeScript와의 궁합도 뛰어납니다.

다음 코드를 살펴봅시다.

import { Hono } from 'hono';
import { zValidator } from '@hono/zod-validator';
import { z } from 'zod';

const app = new Hono();

// 스키마 기반 요청 검증
const userSchema = z.object({
  name: z.string().min(1),
  email: z.string().email()
});

// 타입 안전한 라우트 정의
app.post('/users', zValidator('json', userSchema), async (c) => {
  const { name, email } = c.req.valid('json');
  // 검증된 데이터로 사용자 생성
  return c.json({ id: 1, name, email }, 201);
});

김개발 씨는 지금까지 Express.js로 서버를 만들어왔습니다. 익숙하고 자료도 많아서 불편함을 느끼지 못했죠.

그런데 새 프로젝트에서는 Hono를 사용한다고 합니다. "Express가 나쁜 건 아니에요." 박시니어 씨가 설명을 시작했습니다.

"하지만 Express는 2010년에 만들어졌어요. 그때는 TypeScript도 없었고, 서버리스 환경도 없었죠.

Hono는 2022년에 태어났어요. 현대적인 요구사항을 처음부터 고려해서 설계됐죠." Hono라는 이름은 일본어로 '불꽃'을 의미합니다.

이름처럼 빠릅니다. 성능 비교를 해볼까요?

Express.js가 초당 약 15,000개의 요청을 처리한다면, Hono는 초당 100,000개 이상을 처리합니다. 거의 7배 차이입니다.

이런 성능 차이는 대규모 서비스에서 서버 비용의 차이로 직결됩니다. 두 번째 장점은 TypeScript 지원입니다.

Express에서 TypeScript를 쓰려면 별도의 타입 정의 파일을 설치해야 하고, 타입 추론도 완벽하지 않습니다. 반면 Hono는 처음부터 TypeScript로 작성되어 자동완성과 타입 체크가 완벽합니다.

위 코드를 보세요. zValidator를 사용하면 요청 데이터를 자동으로 검증합니다.

스키마에 맞지 않는 데이터가 들어오면 400 에러를 반환하고, 맞으면 타입이 자동으로 추론됩니다. c.req.valid('json')의 반환값은 자동으로 { name: string, email: string } 타입이 됩니다.

세 번째 장점은 어디서든 동작한다는 점입니다. Node.js는 물론이고, Cloudflare Workers, Deno, Bun, AWS Lambda 등 다양한 환경에서 코드 변경 없이 실행됩니다.

이것을 "Web Standard API 기반"이라고 합니다. 김개발 씨가 물었습니다.

"Express에서 Hono로 옮기기 어렵지 않나요?" 박시니어 씨가 웃었습니다. "생각보다 비슷해요.

app.get, app.post 같은 기본 구조는 같거든요. 오히려 더 깔끔해서 적응하면 돌아가기 싫을 거예요." Hono는 미들웨어 생태계도 풍부합니다.

JWT 인증, 캐싱, 로깅, 압축 등 필요한 기능 대부분이 공식 미들웨어로 제공됩니다. 이제 김개발 씨는 왜 팀이 Hono를 선택했는지 이해했습니다.

빠르고, 타입 안전하고, 유연합니다. 다음 장에서는 Hono의 강력한 기능 중 하나인 OpenAPI 스펙 자동 생성을 알아보겠습니다.

실전 팁

💡 - Express에서 Hono로 마이그레이션할 때는 미들웨어 호환성을 먼저 확인하세요

• Zod와 함께 사용하면 런타임 검증과 타입 추론을 동시에 얻을 수 있습니다

---

4. OpenAPI 스펙 자동 생성

김개발 씨가 API 문서를 작성하려고 하자 박시니어 씨가 말렸습니다. "문서를 수동으로 만들면 코드와 싱크가 안 맞아요.

Hono에서는 코드가 곧 문서예요." 김개발 씨의 눈이 동그래졌습니다. 코드가 문서라니, 그게 무슨 말일까요?

OpenAPI 스펙 자동 생성은 코드에서 API 문서를 자동으로 만들어주는 기능입니다. 마치 건축 도면이 건물과 항상 일치하는 것처럼, 코드를 수정하면 문서도 자동으로 업데이트됩니다.

Hono의 @hono/zod-openapi 패키지로 이 마법을 실현할 수 있습니다.

다음 코드를 살펴봅시다.

import { OpenAPIHono, createRoute, z } from '@hono/zod-openapi';

const app = new OpenAPIHono();

// 라우트를 OpenAPI 스펙과 함께 정의합니다
const getUserRoute = createRoute({
  method: 'get',
  path: '/users/{id}',
  request: {
    params: z.object({ id: z.string() })
  },
  responses: {
    200: {
      content: { 'application/json': { schema: z.object({ id: z.string(), name: z.string() }) } },
      description: '사용자 정보 반환'
    }
  }
});

app.openapi(getUserRoute, (c) => {
  const { id } = c.req.valid('param');
  return c.json({ id, name: '김개발' });
});

// OpenAPI 스펙을 JSON으로 제공
app.doc('/doc', { openapi: '3.0.0', info: { title: 'My API', version: '1.0.0' } });

김개발 씨는 예전 회사에서 겪었던 악몽을 떠올렸습니다. API 문서가 실제 동작과 달라서 프론트엔드 팀과 밤새 싸운 적이 있었죠.

문서에는 userId라고 되어 있는데 실제로는 user_id를 보내야 했습니다. 박시니어 씨가 말했습니다.

"그 문제의 근본 원인은 문서와 코드가 따로 관리되기 때문이에요. 사람은 실수하거든요.

코드를 수정하고 문서 업데이트를 깜빡하기 쉽죠." OpenAPI는 API를 설명하는 표준 규격입니다. 예전에는 Swagger라고 불렸습니다.

이 규격에 맞춰 문서를 작성하면, Swagger UI 같은 도구로 예쁜 문서 페이지를 자동 생성할 수 있습니다. 하지만 문제가 있었습니다.

OpenAPI 스펙을 YAML이나 JSON으로 직접 작성해야 했습니다. 수백 줄의 설정 파일을 관리하는 건 고통스러운 일이었죠.

Hono의 @hono/zod-openapi가 이 문제를 해결합니다. 위 코드를 보세요.

createRoute 함수로 라우트를 정의할 때, 요청과 응답의 스키마를 함께 지정합니다. 이 스키마는 Zod로 작성되어 런타임에 실제로 검증도 수행합니다.

그리고 이 정보가 자동으로 OpenAPI 스펙으로 변환됩니다. app.doc('/doc', ...)을 호출하면 /doc 경로에서 OpenAPI JSON을 받을 수 있습니다.

이걸 Swagger UI에 연결하면 끝입니다. 코드를 수정하면 문서도 자동으로 바뀝니다.

실무에서 이것이 왜 중요할까요? 프론트엔드 개발자는 항상 최신 API 명세를 볼 수 있습니다.

테스트 도구에서 바로 API를 호출해볼 수도 있습니다. 무엇보다 코드와 문서가 절대 어긋나지 않습니다.

김개발 씨가 감탄했습니다. "이거 정말 편하겠네요.

문서 작성 시간도 줄고, 실수할 일도 없겠어요." 박시니어 씨가 덧붙였습니다. "그리고 타입스크립트와 결합하면 더 강력해져요.

프론트엔드에서 이 스펙을 가져다가 API 클라이언트를 자동 생성할 수도 있거든요. 타입까지 완벽하게요." OpenAPI 자동 생성은 현대적인 API 개발의 필수 요소입니다.

다음 장에서는 실시간 통신을 위한 SSE에 대해 알아보겠습니다.

실전 팁

💡 - Swagger UI를 /swagger 경로에 연결해두면 팀원들이 쉽게 API를 테스트할 수 있습니다

• OpenAPI 스펙에서 클라이언트 SDK를 자동 생성하는 도구(openapi-typescript 등)를 활용해보세요

---

5. SSE 기반 이벤트 스트리밍

김개발 씨가 실시간 알림 기능을 구현하려고 WebSocket을 검토하고 있었습니다. 박시니어 씨가 말했습니다.

"단방향 스트리밍이면 SSE가 더 간단해요. 연결 관리도 훨씬 쉽고요." SSE라니, 처음 듣는 용어였습니다.

**SSE(Server-Sent Events)**는 서버에서 클라이언트로 실시간 데이터를 보내는 기술입니다. 마치 라디오 방송처럼 서버가 일방적으로 데이터를 송출하고, 클라이언트는 듣기만 합니다.

WebSocket보다 구현이 간단하고, HTTP 위에서 동작해 방화벽 문제도 적습니다.

다음 코드를 살펴봅시다.

import { Hono } from 'hono';
import { streamSSE } from 'hono/streaming';

const app = new Hono();

app.get('/events', async (c) => {
  return streamSSE(c, async (stream) => {
    // 연결 ID를 전송합니다
    await stream.writeSSE({ data: JSON.stringify({ type: 'connected', id: '123' }), event: 'init' });

    // 5초마다 하트비트를 전송합니다
    let count = 0;
    while (true) {
      await stream.writeSSE({ data: JSON.stringify({ count: ++count }), event: 'heartbeat' });
      await stream.sleep(5000);
    }
  });
});

// 클라이언트에서 연결하기
// const eventSource = new EventSource('/events');
// eventSource.addEventListener('heartbeat', (e) => console.log(e.data));

김개발 씨는 실시간 기능이 필요할 때마다 WebSocket을 떠올렸습니다. 그런데 WebSocket은 설정이 복잡합니다.

연결 상태 관리, 재연결 로직, 로드밸런서 설정까지 신경 쓸 게 많습니다. 박시니어 씨가 물었습니다.

"김개발 씨가 만들려는 기능은 뭐예요?" "실시간 알림이요. 서버에서 새 알림이 생기면 사용자에게 바로 보여주려고요." "그러면 SSE가 딱이에요.

알림은 서버에서 클라이언트로만 가잖아요. 양방향 통신이 필요 없으면 SSE가 훨씬 간단해요." **SSE(Server-Sent Events)**는 HTTP 연결을 유지하면서 서버가 클라이언트에게 데이터를 계속 보낼 수 있게 해줍니다.

비유하자면 라디오 방송과 같습니다. 라디오 방송국이 전파를 송출하면 청취자는 라디오를 켜고 듣기만 합니다.

청취자가 방송국에 말을 걸 수는 없죠. SSE도 마찬가지입니다.

서버가 데이터를 보내고 클라이언트는 받기만 합니다. WebSocket과 비교해볼까요?

WebSocket은 양방향 통신이 가능합니다. 채팅처럼 클라이언트도 메시지를 보내야 할 때 적합합니다.

반면 SSE는 단방향입니다. 알림, 주식 시세, 스포츠 점수 업데이트 같은 경우에 적합합니다.

위 코드를 살펴보겠습니다. Hono의 streamSSE 함수를 사용합니다.

콜백 함수 안에서 stream.writeSSE로 데이터를 보냅니다. event는 이벤트 종류를, data는 실제 데이터를 담습니다.

클라이언트에서는 브라우저 내장 EventSource API를 사용합니다. WebSocket처럼 별도의 라이브러리가 필요 없습니다.

addEventListener로 특정 이벤트 타입을 구독하면 됩니다. SSE의 또 다른 장점은 자동 재연결입니다.

네트워크가 끊겼다가 복구되면 브라우저가 알아서 다시 연결합니다. WebSocket에서는 이걸 직접 구현해야 합니다.

AI 에이전트 프레임워크에서 SSE는 특히 중요합니다. AI가 응답을 생성하는 동안 토큰 단위로 스트리밍해서 보여줄 수 있습니다.

사용자는 AI가 "생각하는" 과정을 실시간으로 볼 수 있죠. 김개발 씨는 고개를 끄덕였습니다.

"WebSocket보다 훨씬 간단하네요. 바로 적용해볼게요."

실전 팁

💡 - SSE 연결은 HTTP/2에서 다중화되어 더 효율적으로 동작합니다

• 클라이언트에서 연결을 닫을 때는 반드시 eventSource.close()를 호출하세요

---

6. Session Provider Config API

김개발 씨가 서버 코드를 분석하다가 세 가지 경로를 발견했습니다. /session, /provider, /config.

박시니어 씨에게 물었습니다. "이 API들은 각각 무슨 역할을 하나요?" 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다.

Session, Provider, Config API는 서버 상태를 관리하는 핵심 엔드포인트입니다. Session은 사용자의 연결 상태를, Provider는 AI 모델 같은 외부 서비스 연결을, Config는 서버 설정을 담당합니다.

마치 호텔의 프론트 데스크(Session), 객실 서비스(Provider), 관리자 설정(Config)과 같습니다.

다음 코드를 살펴봅시다.

import { Hono } from 'hono';

const app = new Hono();

// Session API - 사용자 세션 관리
app.get('/session', (c) => {
  const sessionId = c.req.header('X-Session-Id');
  return c.json({ sessionId, status: 'active', createdAt: new Date().toISOString() });
});

// Provider API - AI 모델 제공자 정보
app.get('/provider', (c) => {
  return c.json({
    providers: [
      { name: 'openai', status: 'available', models: ['gpt-4', 'gpt-3.5'] },
      { name: 'anthropic', status: 'available', models: ['claude-3'] }
    ]
  });
});

// Config API - 서버 설정 조회
app.get('/config', (c) => {
  return c.json({ maxTokens: 4096, timeout: 30000, features: { streaming: true } });
});

김개발 씨는 AI 에이전트 서버 코드를 분석하고 있었습니다. 복잡한 비즈니스 로직 외에도 기본적인 관리 API들이 있었습니다.

이것들이 왜 필요한지 궁금했습니다. 박시니어 씨가 호텔로 비유했습니다.

"호텔을 생각해봐요. 손님이 체크인하면 프론트 데스크에서 방 키를 주죠.

이게 Session이에요. 손님이 룸서비스를 부르면 직원이 와요.

이게 Provider예요. 호텔의 운영 규칙, 예를 들어 체크아웃 시간 같은 건 Config에요." 먼저 Session API를 살펴봅시다.

세션은 클라이언트와 서버 사이의 연결을 추적합니다. 사용자가 접속하면 고유한 세션 ID가 발급됩니다.

이후 모든 요청에 이 ID를 포함해서 서버가 누구의 요청인지 알 수 있습니다. 세션이 왜 필요할까요?

AI 채팅을 생각해보세요. 사용자가 "그거 다시 설명해줘"라고 하면 AI는 "그거"가 뭔지 알아야 합니다.

이전 대화 내용을 세션에 저장해두면 맥락을 유지할 수 있습니다. 다음은 Provider API입니다.

AI 에이전트 서버는 보통 여러 AI 모델을 지원합니다. OpenAI의 GPT-4, Anthropic의 Claude 등이 있죠.

Provider API는 현재 사용 가능한 모델 목록과 상태를 알려줍니다. 이 API가 있으면 클라이언트는 어떤 모델을 선택할 수 있는지 알 수 있습니다.

특정 모델이 점검 중이거나 할당량을 초과했을 때도 이 정보를 통해 알 수 있습니다. 마지막으로 Config API입니다.

서버의 설정값을 클라이언트에게 알려줍니다. 최대 토큰 수, 타임아웃 시간, 활성화된 기능 목록 같은 정보입니다.

클라이언트는 이 정보를 바탕으로 UI를 구성할 수 있습니다. 예를 들어 스트리밍이 활성화되어 있으면 실시간으로 응답을 표시하고, 그렇지 않으면 로딩 스피너를 보여주는 식입니다.

김개발 씨가 물었습니다. "이 API들은 보안이 중요하지 않나요?" 박시니어 씨가 고개를 끄덕였습니다.

"좋은 지적이에요. Config API는 민감한 정보를 포함할 수 있어서 인증된 사용자만 접근하도록 해야 해요.

Session API도 자기 세션만 볼 수 있도록 제한해야 하고요." 이 세 가지 API는 서버의 뼈대를 이룹니다. 제대로 설계하면 확장 가능하고 유지보수하기 쉬운 서버를 만들 수 있습니다.

실전 팁

💡 - Session 데이터는 Redis 같은 인메모리 저장소에 보관하면 빠른 조회가 가능합니다

• Config API의 민감한 정보는 관리자 권한을 가진 사용자에게만 노출하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!