Spine익숙한 개발 방식으로,
더 빠른 서버를.

NestJS와 Spring에서 사용하던 컨트롤러와 서비스 구조로 Go 앱을 구성하세요. 생성자 주입과 인터셉터를 사용하고, 같은 자원에서 측정한 처리량과 메모리 사용량을 확인할 수 있습니다.

Shell

go install github.com/NARUBROWN/spine-cli/cmd/spine@v0.1.4
spine new hello-spine --module example.com/hello-spine
cd hello-spine
go mod tidy
spine contract check
spine verify
spine dev

CLI로 프로젝트를 생성하고 검증한 뒤 실행합니다. 전체 절차는 첫 앱 문서에서 확인하세요.

CLI로 첫 앱 만들기

익숙한 컨트롤러와 서비스

컨트롤러는 요청을 받고 서비스는 업무를 처리합니다. Go의 구조체와 메서드로 각 역할을 나눕니다.

컨트롤러 작성법 보기

생성자로 연결하는 의존성

필요한 서비스를 생성자 매개변수로 선언합니다. Spine이 등록된 생성자를 호출해 객체를 만들고 의존성을 연결합니다.

의존성 주입 보기

인터셉터에 모으는 공통 처리

인증, 트랜잭션, 로깅을 업무 코드에서 분리합니다. 인터셉터를 등록하고 요청 흐름에서 실행할 시점을 정합니다.

인터셉터 사용법 보기

같은 자원으로 더 많이.
메모리는 더 적게.

NestJS/Express, Spring MVC, FastAPI/Uvicorn에 모두 3 vCPU와 3GiB 메모리를 할당해 비교했습니다.

Spine 내부 랩 테스트 / 2026.11.01

측정 조건과 전체 결과 보기

163,559req/s

HTTP 처리량

포화 부하에서 측정한 중앙값

41.8MiB

관측 메모리

초당 2만 요청일 때의 사용량

1.062ms

p99 응답 지연

초당 2만 요청일 때의 지연

같은 CPU 예산에서 처리한 요청 수

높을수록 좋습니다

사용자 1명이 초당 한 번 요청한다면

Spine0.5.2

163,559req/s

NestJS / Express

93,977req/s

Spine이었다면 약 69,582명분의 요청을 더 처리할 수 있었습니다.

Spring MVC

118,943req/s

Spine이었다면 약 44,616명분의 요청을 더 처리할 수 있었습니다.

FastAPI / Uvicorn

50,173req/s

Spine이었다면 약 113,386명분의 요청을 더 처리할 수 있었습니다.

동시 연결 256개에서의 포화 처리량. 각 구현의 실제 처리량을 비교했습니다.

초당 처리량 차이를 1명당 초당 1회 요청으로 환산한 예시입니다. 실제 수용 인원은 요청 빈도와 앱의 작업에 따라 달라집니다.

측정 데이터 CSV

첫 앱 만들기

CLI로 첫 앱 만들기CLI 설치와 프로젝트 생성부터 /health 응답 확인까지 따라갑니다.JWT 로그인 예제 보기토큰을 발급하고 인증이 필요한 요청을 처리하는 구조를 살펴봅니다.API 동작 확인하기생성자, 라우트, 인터셉터 등록 방법과 반환값을 확인합니다.

Spine익숙한 개발 방식으로,더 빠른 서버를.