Go로 백엔드 짜기 — 단순함과 동시성, 그리고 Gin·Chi
언어마다 성격이 있다. 어떤 언어는 표현력을 위해 기능을 잔뜩 더하고, 어떤 언어는 일부러 덜어낸다. Go는 후자다. 상속도, 복잡한 제네릭 문법도, 예외 처리 키워드도 처음엔 과감히 뺐다. "기능이 적으면 표현이 제한되지 않나?" 싶지만, Go의 노림수는 분명하다 — 누가 짜도 비슷하게, 읽기 쉽게, 빨리 익히게. 큰 팀에서 코드가 한 사람 머릿속에만 있지 않도록 하는 것이다.
여기에 Go의 또 다른 무기가 더해진다. 동시성을 언어 차원에서 싸게 만든 것이다. 서버는 본질적으로 수많은 요청을 동시에 다뤄야 하는데, Go는 이걸 위한 **고루틴(goroutine)**을 거의 공짜 수준의 비용으로 제공한다. 단순한 문법과 값싼 동시성 — 이 둘이 Go가 백엔드·인프라(Docker·쿠버네티스도 Go로 짜였다)에서 자주 보이는 이유다.
Go는 "할 수 있는 게 많은" 언어가 아니라 "헷갈릴 게 적은" 언어를 지향한다. 기능을 빼서 코드의 다양성을 줄이고, 그 대신 읽기·협업·빌드 속도를 얻는다. 이 철학을 알면 "왜 Go엔 이게 없지?"의 상당수가 의도된 선택임을 알게 된다.
1. 왜 백엔드에서 Go를 고르나
Go가 서버 쪽에서 사랑받는 이유는 몇 가지 구체적 성질로 나뉜다. 각각이 운영의 어떤 고통을 덜어주는지 보자.
- 1단순함 → 협업과 유지보수
문법이 작아 누가 짜도 코드가 비슷하다.
익히는 데 며칠이면 충분하고, 남의 코드도 금방 읽힌다. 화려한 기교가 적어 코드 리뷰·인수인계가 쉽다. 큰 조직일수록 이 균질함이 값지다.
- 2고루틴 → 값싼 동시성
수만 개를 띄워도 가벼운 경량 실행 단위.
OS 스레드는 무거워 많이 못 띄우지만, 고루틴은 아주 가벼워 수만 개도 동시에 돌릴 수 있다. "요청마다 하나씩"처럼 단순하게 짜도 서버가 잘 버틴다. (자세한 동작은 2절)
- 3단일 바이너리 → 쉬운 배포
컴파일하면 의존성 없는 실행 파일 하나가 나온다.
런타임·라이브러리를 따로 깔 필요 없이 파일 하나만 서버에 두면 돈다. Docker 이미지도 아주 작고 가볍게 만들 수 있어, 컨테이너 환경과 궁합이 좋다.
- 4빠른 컴파일 + 정적 타입
큰 코드도 금방 빌드되고, 타입으로 실수를 잡는다.
정적 타입이라 많은 오류를 컴파일 단계에서 걸러내면서도, 빌드가 빨라 개발 리듬이 끊기지 않는다. "안전함"과 "빠른 피드백"을 함께 가져간다.
요약하면 Go의 매력은 화려함이 아니라 균질함·동시성·배포 단순함이라는 운영 친화적 성질들이다. 그래서 트래픽이 많고 오래 굴려야 하는 서버에 잘 맞는다.
2. 고루틴: 동시성을 싸게 만드는 법
Go 서버의 심장은 고루틴이다. 동시성을 다루는 방식이 다른 언어와 어떻게 다른지 보면, "왜 Go로 서버를 짜면 단순한데도 잘 버티나"가 풀린다.
- 1고루틴 — 아주 가벼운 실행 단위
go 한 단어로 함수를 동시에 돌린다.
go 함수()라고 쓰면 그 함수가 별도 흐름으로 동시에 실행된다. 하나당 메모리 부담이 작아 수만 개를 띄워도 괜찮다. OS 스레드를 직접 다루던 복잡함을 언어가 가려준다. - 2스케줄러 — 적은 스레드에 많은 고루틴
Go 런타임이 고루틴을 OS 스레드에 알아서 얹는다.
개발자는 고루틴을 마구 만들고, 런타임이 그걸 소수의 OS 스레드 위에 분배해 돌린다. 한 고루틴이 I/O로 기다리면 그 틈에 다른 고루틴을 돌려, 스레드를 놀리지 않는다.
- 3채널 — 고루틴끼리 안전하게 주고받기
공유 메모리 대신 채널로 값을 전달한다.
여러 흐름이 같은 데이터를 동시에 만지면 버그(경쟁 상태)가 난다. Go는 채널 로 값을 주고받게 해, "메모리를 공유해 통신하지 말고, 통신해서 공유하라"는 방식으로 이 위험을 줄인다.
많은 언어에선 "동시에 많이 처리"를 위해 콜백·비동기 키워드로 코드를 비틀어야 한다. Go는 고루틴 덕에 평범하게 위에서 아래로 읽히는 코드를 써도, 런타임이 알아서 동시에 굴린다. 동시성의 복잡함을 언어가 떠안아, 개발자 코드는 단순하게 남는다.
3. 웹 프레임워크가 필요한 자리
Go는 표준 라이브러리(net/http)만으로도 웹 서버를 짤 수 있다. 그런데도
프레임워크를 얹는 이유가 있다. 표준만 쓰면 라우팅·미들웨어 같은 반복 작업을
매번 손으로 해야 하기 때문이다. Go 생태계의 프레임워크는 대개 얇다 — Spring
이나 Nest처럼 구조를 강제하기보다, 표준 위에 편의를 살짝 더하는 쪽이다.
- 1표준만으로도 되지만 번거롭다
경로 매칭·파라미터 추출을 일일이 직접 짜게 된다.
/users/42에서42를 빼내고, 메서드별로 분기하고, 공통 처리를 끼우는 일을 표준만으로 하면 코드가 장황해진다. 프레임워크가 이 반복을 줄여준다. - 2Go식 프레임워크는 '얇게' 더한다
구조 강제보다 라우팅·미들웨어 편의에 집중.
NestJS가 "이렇게 짜라"고 틀을 강제했다면, Go 프레임워크는 표준에 가깝게 남겨 둔 채 자주 쓰는 것만 얹는다. Go의 "덜어내기" 철학이 프레임워크에도 묻어 있다.
Gin — 빠르고 기능이 갖춰진 인기 프레임워크
Gin은 Go 웹 프레임워크 중 가장 널리 쓰이는 축이다. 성능이 좋고, 라우팅· 미들웨어·JSON 바인딩·검증 같은 웹에 자주 필요한 것들을 기본 제공한다. "표준은 번거롭고, 그렇다고 무겁긴 싫다"는 자리를 잘 메운다.
- 1빠른 라우팅
경로 매칭이 빠르게 설계돼 처리량이 높다.
많은 경로·요청에서도 라우팅 오버헤드가 작아, 고성능이 필요한 API에 자주 쓰인다. Go 자체의 속도에 얇은 프레임워크가 더해져 빠르다.
- 2갖춰진 편의 기능
JSON 바인딩·검증·미들웨어 등을 바로 쓴다.
요청 본문을 구조체로 받아 검증하거나, 공통 미들웨어를 끼우는 일이 간결하다. "웹 API에 필요한 것"이 대부분 준비돼 있어 빨리 만든다.
Chi — 표준에 충실한 가벼운 라우터
Chi는 다른 결을 택한다. 표준 net/http 와의 호환을 중시하며 아주 가볍다.
Gin이 "편의를 갖춘 프레임워크"라면, Chi는 "표준에 얇게 얹은 라우터"에 가깝다.
표준 인터페이스를 그대로 따르기에, 표준용으로 만든 미들웨어를 거의 그대로 쓸 수
있다.
- ·기능이 갖춰진 풀세트에 가까움
- ·JSON 바인딩·검증 등 편의가 많음
- ·성능 좋고 생태계·예제가 풍부
- ·표준과 살짝 다른 자기 방식을 가짐
- ·표준 net/http에 충실, 매우 가벼움
- ·표준 미들웨어를 그대로 재사용 가능
- ·최소한만 더해 '얇음'을 유지
- ·편의는 적지만 표준 지식이 그대로 통함
빠르게 기능 갖춘 API를 만들고 풍부한 예제를 원하면 Gin, 표준에 가깝게 가볍고 투명하게 가져가고 싶으면 Chi 가 어울린다. 둘 다 표준 위에 얇게 얹는다는 Go의 결을 공유하므로, 무엇을 고르든 NestJS 같은 무거운 틀과는 다른 가벼운 느낌이다. 정답은 없고 팀의 취향과 프로젝트 성격이 정한다.
정리하면 Go는 기능을 덜어 단순함을, 고루틴으로 값싼 동시성을, 단일 바이너리로 쉬운 배포를 가져가는 언어다. 웹은 표준만으로도 되지만 반복을 줄이려 얇은 프레임워크를 얹는데, 기능을 갖춘 Gin과 표준에 충실한 Chi가 그 양 끝을 대표한다. 어느 쪽이든 "표준 위에 가볍게"라는 Go의 성격을 공유한다.
한 장 요약
- 1철학
기능을 덜어내 단순함을 택 — 누가 짜도 비슷하고 읽기 쉽게.
- 2강점
값싼 동시성(고루틴)·단일 바이너리 배포·빠른 컴파일·정적 타입.
- 3고루틴
go 한 단어로 동시 실행, 런타임이 소수 스레드에 분배, 채널로 안전 통신.
- 4프레임워크
표준으로도 되지만 반복을 줄이려 '얇게' 얹는 게 Go식.
- 5Gin
성능 좋고 JSON 바인딩·검증 등 편의가 갖춰진 인기 풀세트.
- 6Chi
표준 net/http에 충실한 가벼운 라우터 — 표준 미들웨어를 그대로 재사용.