콘텐츠로 이동

백엔드 (Backend)

여러 제품이 저마다 다른 백엔드 언어를 쓰다 보면 재미있는 상황이 생겨요. 웹빌더는 TypeScript(NestJS)로, 이벤트는 Java 계열로 돌아가는데, 정작 LLM을 붙이는 부분이 제품마다 중복으로 흩어지고 관리가 어려워지죠. 그래서 백엔드는 한동안 "LLM 통합과 API Gateway 축으로 수렴하는 여정" 중이라고 말해요. 언어는 달라도 API 계약은 공통으로 맞추고, 게이트웨이 한 곳에서 인증·라우팅·요청 분배를 맡는 식이죠.

이 페이지는 그 백엔드 카테고리의 허브예요. 프레임워크별 상태 배지를 보면서 어떤 기술이 어디까지 왔는지 한눈에 확인하고, 궁금한 기술은 각 하위 페이지로 들어가면 됩니다.

하위 기술 목차

프레임워크

  • NestJS (🟢 운영) — ./nestjs.md · TypeScript 기반의 Node.js 프레임워크예요. 모듈·의존성 주입·파이프 구조가 짜여 있어서 규모가 커져도 코드가 흩어지지 않게 잡아줍니다. v10·v11을 함께 다룹니다.
  • Spring Boot (🟢 운영) — ./spring-boot.md · Kotlin/Java 기반의 엔터프라이즈 프레임워크예요. 무거운 트랜잭션, 인증, 배치 기능이 기본 제공돼서 안정성을 우선하는 제품에 어울립니다. 3.5 기준입니다.
  • FastAPI (🔵 적용) — ./fastapi.md · Python 기반의 API 프레임워크예요. 타입 힌트로 자동 검증되는 요청/응답 모델을 만들어서 AI·자동화 백엔드에 적합해요.
  • axum (⚪ 역량) — ./axum.md · Rust 기반의 비동기 웹 프레임워크예요. 팀이 다룰 줄 알지만 아직 제품엔 안 쓰는 상태라 로드맵에 올라와 있어요. 성능이 중요한 지점에서 쓸 수 있어요.

주변 기술 (함께 보면 좋아요)

  • Express (🟢 운영) — NestJS처럼 도구가 큰 게 부담될 때 단순한 API를 빠르게 여는 Node.js HTTP 프레임워크예요.
  • Kong / Kong Ingress (🟢 운영) — API 게이트웨이로, 모든 요청이 한 곳을 거치며 인증·rate limit·라우팅을 통일하는 관문이에요.
  • Bull / BullMQ (🟢 운영) — Redis 기반 작업 큐예요. 시간이 걸리는 작업을 백그라운드로 밀어 넣고 처리해요. NestJS 쪽에서 자세히 봅니다.
  • JPA / QueryDSL (🟢 운영) — Java 진영의 ORM과 타입 안전한 쿼리 빌더예요. Spring Boot 쪽에서 자세히 봅니다.
  • LLM 추상화 계층 (🟢 운영) — Vercel AI SDK와 여러 벤더를 "하나의 주소"로 추상화하는 계층이에요. 자세한 건 AI·LLM 통합에서 봐요.

왜 이 프레임워크들을 쓰나요?

대부분의 선택은 단일 제품이 아니라 여러 제품이 함께 쓰는 공통 언어를 고르는 데서 시작해요. 웹빌더·캔버스·이벤트·뉴런이 하나의 백엔드 언어로만 돌아가면 좋겠지만, 이미 각자 다른 언어로 시작한 제품이 있어서 현실은 "여러 언어가 공존"하는 상태죠.

그래서 우리의 지향점은 두 가지예요. 첫째, LLM 통합 계층으로 벤더를 추상화해 어떤 프레임워크든 같은 코드로 LLM을 다루게 하는 것. 둘째, API Gateway로 인증·라우팅·요청 분배를 한 곳에 모아 언어 차이를 겉으로 드러나지 않게 하는 것. 프레임워크는 각자 자기 강점(안정성·생산성·성능)을 살리고, 공통 표면은 게이트웨이와 추상화 계층이 맞춰주는 구조예요.

아키텍처는 표현·응용·도메인·인프라를 나누는 계층형으로 잡아요. DDD로 도메인을 모델링하고, 조회와 명령을 나누는 CQRS를 필요한 부분에 적용하며, DTO로 계층 간 데이터를 명시적으로 오가게 해요. LLM을 다룰 땐 Provider Abstraction과 Multi-Vendor API, Retry/Backoff/Timeout, 다단계 Fallback이 핵심이에요.

더 알아보기