👋 프롤로그: 왜 우리는 Go로 거래소를 만들어야 하는가?

안녕, 미래의 개발 갓(God)!
혹시 '나만의 서비스'를 만들어보고 싶다는 생각, 한 번쯤 해보지 않았어? 그 중에서도 암호화폐 거래소는 개발자에게 '종합선물세트' 같은 프로젝트야. 왜냐고? 실시간 데이터 처리, 대용량 트랜잭션, 튼튼한 보안, 안정적인 서버 아키텍처까지...
현대 웹 서비스의 모든 기술적 도전 과제가 이 안에 녹아있거든. 이걸 성공적으로 만들면, 당신의 개발 실력은 말 그대로 '떡상'하는 거지. 📈

근데 왜 하필 'Go' 언어일까? 파이썬은 쉽고, 자바는 국룰 아니냐고? 물론 좋은 언어들이지. 하지만 암호화폐 거래소의 심장을 뛰게 하려면 특별한 능력이 필요해.

• 미친 성능과 동시성 처리: Go는 태생부터 멀티코어 프로세서를 갈아 넣을 기세로 만들어졌어. '고루틴(Goroutine)'이라는 마법 같은 기능으로 수만, 수십만 개의 동시 요청을 가볍게 처리해. 쉴 새 없이 오더가 쏟아지는 거래소 환경에 이보다 더 적합할 수 있을까?
• 단순함의 미학: Go의 문법은 놀랍도록 간결하고 명확해. 덕분에 코드가 길어지고 복잡해져도 유지보수가 쉽고, 여러 개발자가 협업할 때 발생하는 혼란을 줄여주지. "코드는 짧고, 인생은 길다"는 개발자의 명언을 실현시켜 준달까.
• 강력한 표준 라이브러리와 생태계: 웹 서버, 네트워킹, 암호화 등 거래소 개발에 필요한 웬만한 기능은 Go 표준 라이브러리에 다 들어있어. 여기에 Gin, gRPC, GORM 같은 든든한 서드파티 라이브러리까지 합세하면 천하무적이야.

이 글은 당신을 'Go 언어를 이용한 암호화폐 거래소 개발'이라는 대장정으로 안내할 거야. 물론 하루아침에 뚝딱 만들 수 있는 건 아니야. 하지만 걱정 마. 가장 중요한 핵심 개념부터 차근차근, 마치 친한 친구가 옆에서 알려주듯 재미있게 풀어줄게. 자, 그럼 커피 한 잔 진하게 타시고, 우리만의 디지털 월스트리트를 건설하러 떠나볼까? 💻

🏛️ 아키텍처 설계: 우리 거래소의 청사진 그리기

모든 위대한 건축물은 탄탄한 설계도에서 시작돼. 우리 거래소도 마찬가지! 수많은 사용자가 몰려도 버벅대지 않고, 새로운 기능을 쉽게 추가할 수 있는 유연한 구조를 만들어야 해. 이런 요구사항에 가장 잘 맞는 현대적인 아키텍처는 바로 '마이크로서비스 아키텍처(MSA)'야.

쉽게 말해, 거대한 하나의 프로그램(모놀리식)으로 만드는 게 아니라, 기능별로 잘게 쪼개서 독립적인 작은 서비스들을 여러 개 만드는 방식이지. '회원 관리 서비스', '주문 처리 서비스', '지갑 서비스'처럼 말이야. 얘네들은 서로 약속된 방식(주로 API)으로만 소통해.

자, 그럼 우리 거래소를 구성할 핵심 마이크로서비스들을 하나씩 살펴보자. 아래 그림은 우리 거래소의 전체적인 구조를 보여주는 청사진이야.

각각의 역할을 간단히 짚어볼까?

• API 게이트웨이 (API Gateway): 모든 클라이언트(웹, 모바일앱)의 요청이 가장 먼저 도착하는 관문. 요청을 알맞은 서비스로 보내주고, 인증/인가, 접속량 제한(Rate Limiting) 같은 공통 기능을 처리해.
• 사용자 서비스 (User Service): 회원가입, 로그인, 개인정보 관리, KYC(본인 인증) 등 사용자 계정에 관한 모든 것을 책임져.
• 지갑 서비스 (Wallet Service): 사용자의 암호화폐 입출금을 관리. 블록체인 네트워크와 직접 통신하며 트랜잭션을 생성하고 확인하는 중요한 역할을 해.
• 매칭 엔진 (Matching Engine): 거래소의 심장! ❤️ 사용자가 제출한 '살래요(매수)', '팔래요(매도)' 주문을 접수하고, 조건이 맞는 주문끼리 연결(체결)시켜주는 핵심 로직이야. 성능이 생명이지.
• 시장 데이터 서비스 (Market Data Service): 체결된 거래 내역, 현재 호가창 정보, 차트 데이터 등을 가공해서 클라이언트에게 실시간으로 뿌려주는 역할을 해.
• 알림 서비스 (Notification Service): 주문 체결, 입출금 완료 등 중요한 이벤트가 발생했을 때 사용자에게 이메일이나 푸시 알림을 보내줘.
• 메시지 큐 (Message Queue): 서비스들 사이의 통신을 직접 연결하는 대신, 중간에서 메시지를 잠시 보관했다가 전달해주는 우체국 같은 역할. 시스템의 안정성과 확장성을 높여주는 숨은 공신이야.

어때? 좀 복잡해 보이나? 괜찮아. 우리는 이 거대한 시스템을 하나씩 정복해 나갈 거니까. 가장 중요한 건, 이렇게 잘게 쪼개진 구조 덕분에 우리가 어떤 한 부분에만 집중해서 개발하고 개선할 수 있다는 점이야. 이게 바로 MSA의 파워지!

🛠️ 개발 환경 세팅: 전쟁터에 나갈 준비

"훌륭한 목수는 연장 탓을 하지 않는다"지만, 우린 훌륭한 개발자니까 최고의 연장을 세팅하고 시작하자. Go 언어로 개발하기 위한 기본 환경 설정과, 우리 프로젝트를 도와줄 필수 라이브러리들을 소개할게. 터미널을 열고 따라와!

1. Go 설치 및 환경 설정

이 글을 읽는 당신이라면 Go 정도는 이미 설치했겠지만, 혹시 모를 친구들을 위해. 공식 홈페이지(https://go.dev/dl/)에서 자기 OS에 맞는 버전을 다운로드해서 설치하면 끝. 설치가 끝나면 터미널에서 아래 명령어로 버전을 확인해보자.

$ go version
go version go1.22.1 darwin/arm64

요즘은 Go Modules가 기본이라 예전처럼 GOPATH, GOROOT 같은 환경변수 때문에 머리 아플 일은 거의 없어. 프로젝트 폴더를 만들고, 그 안에서 `go mod init [모듈이름]` 명령어로 프로젝트를 시작하면 돼.

$ mkdir go-crypto-exchange
$ cd go-crypto-exchange
$ go mod init github.com/my-awesome-dev/go-crypto-exchange
go: creating new go.mod: module github.com/my-awesome-dev/go-crypto-exchange

이제 이 폴더가 우리 프로젝트의 베이스캠프가 되는 거야.

2. 우리를 도와줄 어벤져스 라이브러리 군단

맨땅에 헤딩할 순 없지. 이미 똑똑한 개발자들이 만들어놓은 훌륭한 라이브러리들을 적극 활용하자. 이걸 '바퀴를 재발명하지 않는다'고들 하지. 우리 거래소 프로젝트에 꼭 필요한 라이브러리 몇 개를 추려봤어.

# 웹 프레임워크 (API 서버 만들 때 필수)
go get -u github.com/gin-gonic/gin

# gRPC (마이크로서비스 간 통신)
go get -u google.golang.org/grpc
go get -u google.golang.org/protobuf/cmd/protoc-gen-go

# 데이터베이스 ORM (DB 작업 편하게)
go get -u gorm.io/gorm
go get -u gorm.io/driver/postgres

# WebSocket (실시간 데이터 전송)
go get -u github.com/gorilla/websocket

# 로깅 (문제 추적의 필수품)
go get -u go.uber.org/zap

# 설정 관리 (config 파일 읽기)
go get -u github.com/spf13/viper

# 암호화폐 관련 (비트코인 예시)
go get -u github.com/btcsuite/btcd

각 라이브러리의 역할을 간단히 설명해줄게.

• Gin: 가볍고 빠른 웹 프레임워크야. API 게이트웨이나 각 서비스의 HTTP API 엔드포인트를 만들 때 아주 유용해. 라우팅, 미들웨어 기능이 끝내주지.
• gRPC: 구글이 만든 고성능 RPC(원격 프로시저 호출) 프레임워크. 마이크로서비스끼리 통신할 때 HTTP/JSON보다 훨씬 빠르고 효율적이야. 서비스 간의 약속(인터페이스)을 `.proto` 파일로 명확하게 정의할 수 있어서 협업에도 좋아.
• GORM: Go에서 가장 인기 있는 ORM(객체 관계 매핑) 라이브러리. 복잡한 SQL 쿼리를 직접 짜지 않고, Go 구조체(struct)로 데이터베이스를 다룰 수 있게 해줘. 생산성이 확 올라가.
• Gorilla WebSocket: 실시간 양방향 통신을 위한 WebSocket 구현체. 시장 데이터 서비스에서 클라이언트로 시세나 호가창 정보를 쏴줄 때 필수적이야.
• Zap: Uber에서 만든 구조화된 로깅 라이브러리. 그냥 `fmt.Println`으로 찍는 것보다 훨씬 빠르고, 로그를 레벨별(info, error, debug)로 관리하거나 JSON 형태로 출력해서 나중에 분석하기 쉽게 만들어줘.
• Viper: 데이터베이스 접속 정보나 API 키 같은 설정 값들을 파일이나 환경변수에서 쉽게 읽어올 수 있게 도와주는 라이브러리야.

이 정도면 전투 준비는 끝났어. 이제 진짜 심장부를 만들러 가볼까? 🚀

🧠 거래소의 심장, 매칭 엔진 개발하기

드디어 올 것이 왔다. 암호화폐 거래소의 알파이자 오메가, 매칭 엔진(Matching Engine)! 여기가 바로 수많은 '살래요'와 '팔래요'가 만나 역사가 이루어지는 곳이야. 매칭 엔진의 성능이 곧 거래소의 경쟁력이라고 해도 과언이 아니지. 0.001초의 지연도 용납할 수 없는, 극한의 성능을 요구하는 영역이야.

Go의 동시성 처리 능력, 즉 고루틴과 채널이 빛을 발하는 순간이 바로 여기야. 자, 정신 바짝 차리고 따라와!

1. 매칭 엔진의 기본 원리: 가격-시간 우선 원칙

매칭 엔진은 '경매장'과 같아. 가장 비싸게 사겠다는 사람과 가장 싸게 팔겠다는 사람을 먼저 연결해주지. 이게 바로 가격 우선(Price Priority) 원칙이야.

• 매수 주문(Bid): 높은 가격일수록 우선순위가 높다. (100원에 사겠다는 사람이 99원에 사겠다는 사람보다 먼저)
• 매도 주문(Ask): 낮은 가격일수록 우선순위가 높다. (100원에 팔겠다는 사람이 101원에 팔겠다는 사람보다 먼저)

만약 가격이 같다면? 그때는 시간 우선(Time Priority) 원칙이 적용돼. 먼저 주문을 낸 사람이 우선권을 갖는 거지. "선착순!"

이 두 가지 원칙을 합쳐서 '가격-시간 우선 원칙(Price-Time Priority)'이라고 불러. 모든 증권 및 암호화폐 거래소 매칭의 기본 룰이야. 이거 완전 국룰이죠.

2. 핵심 데이터 구조: 오더북(Order Book)

매칭 엔진은 이 가격-시간 우선 원칙에 따라 주문들을 관리해야 해. 이때 사용하는 데이터 구조가 바로 오더북(Order Book)이야. 오더북은 크게 두 부분으로 나뉘어.

• 매수 오더북 (Bid Book): 모든 매수 주문을 '가격 내림차순'으로 정렬해서 보관.
• 매도 오더북 (Ask Book): 모든 매도 주문을 '가격 오름차순'으로 정렬해서 보관.

이 구조를 효율적으로 구현하려면 어떤 자료구조가 좋을까? 단순 배열이나 리스트로 만들고 매번 정렬? 주문이 수백만 개라면? 끔찍하지. 😱 여기서 우리는 힙(Heap)이나 균형 잡힌 이진 탐색 트리(Balanced Binary Search Tree, ex: Red-Black Tree) 같은 자료구조를 사용해야 해. 이런 자료구조들은 데이터를 추가, 삭제, 검색(특히 최대/최소값)하는 데 아주 빠른 성능(O(log n))을 보장하거든.

3. Go로 구현하는 매칭 로직 (간략화 버전)

자, 이제 코드로 직접 만들어보자. 여기서는 개념 이해를 돕기 위해 아주 간단하게 구현할 거야. 실제 프로덕션 코드에서는 힙(Heap) 자료구조를 쓰고, 동시성 제어를 위해 뮤텍스(Mutex)나 채널을 사용해야 해.

먼저 주문(Order)과 오더북(OrderBook)을 표현할 구조체를 정의하자.

package matching

import (
	"time"
)

// OrderType은 주문 타입을 나타냄 (지정가, 시장가 등)
type OrderType string

const (
	LimitOrder  OrderType = "LIMIT"
	MarketOrder OrderType = "MARKET"
)

// Order는 단일 주문 정보를 담는 구조체
type Order struct {
	ID        uint64
	Type      OrderType
	IsBuy     bool      // true: 매수, false: 매도
	Price     float64   // 지정가 주문의 경우 가격
	Amount    float64   // 수량
	Timestamp time.Time // 주문 시간 (시간 우선 원칙)
}

// OrderBook은 한 쌍의 자산(예: BTC/KRW)에 대한 오더북
type OrderBook struct {
	Bids []*Order // 매수 주문 목록 (가격 내림차순 정렬 필요)
	Asks []*Order // 매도 주문 목록 (가격 오름차순 정렬 필요)
}

// NewOrderBook은 새로운 오더북을 생성
func NewOrderBook() *OrderBook {
	return &OrderBook{
		Bids: make([]*Order, 0),
		Asks: make([]*Order, 0),
	}
}

// AddOrder는 오더북에 새로운 주문을 추가하고 매칭을 시도
func (ob *OrderBook) AddOrder(order *Order) {
	if order.IsBuy {
		// 매수 주문 처리
		ob.matchAndAddBid(order)
	} else {
		// 매도 주문 처리
		ob.matchAndAddAsk(order)
	}
}

이제 가장 중요한 매칭 로직을 만들어보자. 새로운 매수 주문이 들어왔을 때, 매도 오더북(Asks)을 확인하며 체결 가능한 주문이 있는지 찾는 `matchAndAddBid` 함수를 구현해볼게. (실제로는 정렬된 슬라이스 대신 힙을 사용해야 성능이 보장됩니다!)

// matchAndAddBid는 매수 주문을 받아 매도 주문과 매칭 시도
func (ob *OrderBook) matchAndAddBid(buyOrder *Order) {
	// 매도 주문 목록(Asks)을 낮은 가격부터 순회
	// (실제로는 힙의 최상단 노드만 확인하면 됨)
	for i := 0; i < len(ob.Asks); {
		askOrder := ob.Asks[i]

		// 매수 희망가가 매도 희망가보다 낮으면 더 이상 체결 불가
		if buyOrder.Price < askOrder.Price {
			break
		}

		// 체결!
		if buyOrder.Amount >= askOrder.Amount {
			// 매수량이 더 많거나 같으면, 매도 주문은 전부 체결됨
			println("Trade matched:", askOrder.Amount, "at price", askOrder.Price)
			buyOrder.Amount -= askOrder.Amount
			
			// 매도 주문 목록에서 제거
			ob.Asks = append(ob.Asks[:i], ob.Asks[i+1:]...)

			if buyOrder.Amount == 0 {
				// 매수 주문도 전부 체결되었으면 루프 종료
				return
			}
		} else {
			// 매도량이 더 많으면, 매수 주문은 전부 체결되고 매도 주문은 일부만 체결됨
			println("Trade matched:", buyOrder.Amount, "at price", askOrder.Price)
			askOrder.Amount -= buyOrder.Amount
			buyOrder.Amount = 0
			// 매수 주문이 모두 소진되었으므로 루프 종료
			return
		}
	}

	// 매칭 후에도 매수 주문량이 남아있다면, 매수 오더북에 추가
	if buyOrder.Amount > 0 {
		// (실제로는 가격-시간 우선순위에 맞게 정렬된 위치에 삽입해야 함)
		ob.Bids = append(ob.Bids, buyOrder)
		println("Remaining buy order added to the book.")
	}
}

머리 좀 아프지? 😅 괜찮아. 핵심은 이거야.

1. 새 주문이 들어온다. (예: 10,050원에 3 BTC 매수 주문)
2. 반대편 오더북을 확인한다. (매도 오더북)
3. 가장 조건이 좋은 주문(가장 싼 매도 주문)부터 비교한다. (예: 10,010원에 1 BTC 매도 주문)
4. 매수 희망가(10,050원) >= 매도 희망가(10,010원) 이므로 체결!
5. 수량을 비교해서 체결량을 결정하고, 각 주문의 남은 수량을 업데이트한다.
6. 한쪽 주문이 완전히 소진될 때까지 이 과정을 반복한다.
7. 그래도 주문이 남았다면, 자기편 오더북에 추가한다.

이 모든 과정이 1초에 수천, 수만 번씩 일어나야 해. 그래서 우리는 각 거래 페어(BTC/KRW, ETH/KRW)마다 별도의 고루틴을 할당해서 매칭 엔진을 돌릴 거야. 그리고 외부(API 게이트웨이 등)로부터 오는 주문 요청은 채널(Channel)을 통해 안전하게 매칭 엔진 고루틴으로 전달하는 거지. 이것이 바로 Go의 동시성을 활용한 고성능 매칭 엔진의 기본 구조야.

🛡️ 지갑 서비스와 철통 보안: 돈 문제는 심각하다

거래소의 심장이 매칭 엔진이라면, 금고는 바로 지갑 서비스(Wallet Service)야. 사용자의 소중한 자산을 안전하게 보관하고, 입출금을 처리하는 곳이지. 여기는 단 한 번의 실수도 용납되지 않는, 보안이 최최최우선인 영역이야. 만약 여기가 뚫리면? 거래소는 문 닫는 거고, 우리는 뉴스 사회면에 나오는 거야. 😱

1. 핫 월렛 vs 콜드 월렛: 계란은 나눠 담자

거래소 지갑은 크게 두 종류로 운영돼. 이건 보안의 기본 중의 기본이야.

• 핫 월렛 (Hot Wallet) 🔥: 인터넷에 항상 연결되어 있는 지갑이야. 사용자의 빠른 입출금 요청을 처리하기 위해 필요해. 편리하지만, 온라인 상태이기 때문에 해킹 공격에 직접적으로 노출될 위험이 커. 그래서 전체 자산의 아주 일부(예: 5% 미만)만 핫 월렛에 보관해야 해.
• 콜드 월렛 (Cold Wallet) ❄️: 인터넷과 완전히 분리된, 오프라인 상태의 지갑이야. USB 형태의 하드웨어 지갑이나, 인터넷이 차단된 컴퓨터에 키를 보관하는 방식이지. 해킹이 거의 불가능하기 때문에 거래소 전체 자산의 대부분(예: 95% 이상)을 여기에 보관해야 해.

지갑 서비스는 이 두 지갑 사이의 자산 이동을 관리하는 역할도 해. 예를 들어, 핫 월렛의 잔고가 일정 수준 이하로 떨어지면 관리자에게 알림을 보내고, 정해진 절차에 따라 콜드 월렛에서 핫 월렛으로 자금을 보충하는 거지. 이 과정은 대부분 수동으로, 여러 명의 승인을 거쳐 진행돼.

2. 입금 처리 프로세스

사용자가 우리 거래소에 비트코인을 입금하는 과정을 상상해보자.

1. 입금 주소 발급: 사용자가 '입금' 버튼을 누르면, 지갑 서비스는 해당 사용자를 위한 고유한 비트코인 입금 주소를 생성해서 보여줘야 해. 이 주소는 미리 수만 개를 생성해서 데이터베이스에 저장해두고, 필요할 때마다 하나씩 할당해주는 '주소 풀(Address Pool)' 방식으로 운영하는 게 효율적이야.
2. 블록체인 모니터링: 지갑 서비스는 비트코인 블록체인 네트워크를 실시간으로 감시해야 해. 이걸 위해 '비트코인 풀노드(Full Node)'를 직접 운영하거나, 블록체인 데이터 제공 API 서비스를 이용할 수 있어.
3. 입금 트랜잭션 감지: 우리가 발급한 주소 중 하나로 돈이 들어오는 트랜잭션이 발생하면, 지갑 서비스가 이걸 포착해야 해.
4. 컨펌(Confirm) 확인: 블록체인에서는 트랜잭션이 하나의 블록에 포함된 후, 그 뒤로 몇 개의 블록이 더 쌓여야 안전한 거래로 인정해줘. 이걸 '컨펌'이라고 해. 비트코인은 보통 6 컨펌을 안전하다고 보지. 지갑 서비스는 충분한 컨펌이 쌓일 때까지 기다려야 해.
5. 사용자 계정 잔고 업데이트: 안전성이 확인되면, 그제야 데이터베이스에 있는 해당 사용자의 비트코인 잔고를 늘려주는 거야. "고객님, 입금 처리 완료되었습니다! 띵동! 🔔"

3. 출금 처리 프로세스

출금은 훨씬 더 민감하고 위험해. 돈이 빠져나가는 거니까!

1. 출금 요청 접수: 사용자가 출금할 주소와 수량을 입력하고 요청을 보내.
2. 보안 검증: 2FA(2-Factor Authentication, 예: 구글 OTP), 이메일 인증 등 추가 인증 절차를 반드시 거쳐야 해. 또한, FDS(이상 금융 거래 탐지 시스템)를 통해 평소와 다른 패턴의 출금(거액, 낯선 주소 등)인지 확인해야 해.
3. 핫 월렛에서 트랜잭션 생성: 검증이 완료되면, 지갑 서비스는 핫 월렛의 개인키를 사용해서 블록체인 네트워크로 보낼 트랜잭션을 서명하고 생성해. 이때 개인키는 절대로 외부로 노출되면 안 돼! HSM(하드웨어 보안 모듈) 같은 전용 장비에 보관하는 게 가장 안전해.
4. 트랜잭션 브로드캐스팅: 생성된 트랜잭션을 블록체인 네트워크에 전파(broadcast)해.
5. 출금 완료 처리: 트랜잭션이 블록체인에 성공적으로 기록된 것을 확인한 후, 사용자의 계정 잔고를 차감하고 출금 완료를 알려줘.

Go로 지갑 서비스를 만들 때는 `btcd`, `go-ethereum` 같이 각 코인을 지원하는 라이브러리를 사용해서 주소를 생성하고, 트랜잭션을 만들고, 노드와 통신할 수 있어. 하지만 다시 한번 강조할게. 보안은 기술 스택의 문제가 아니라 정책과 프로세스의 문제야. 코드 한 줄보다 콜드 월렛 관리 규정 하나가 더 중요할 수 있다는 걸 명심해!

🚪 API 게이트웨이와 사용자 서비스: 거래소의 얼굴과 문지기

자, 이제 거래소의 내부 핵심 부품들(매칭 엔진, 지갑)을 살펴봤으니, 사용자와 직접 만나는 부분을 만들어보자. 바로 API 게이트웨이와 사용자 서비스야. API 게이트웨이는 우리 거래소의 모든 요청이 거쳐 가는 '대문'이고, 사용자 서비스는 그 대문을 통과할 자격이 있는지 확인하는 '문지기' 역할을 해.

1. API 게이트웨이: 모든 길은 나에게로 통한다

클라이언트(웹 브라우저, 모바일 앱)가 "비트코인 현재가 알려줘!", "주문 넣어줘!" 같은 요청을 보낼 때, 수많은 마이크로서비스 중 어디로 가야 할지 어떻게 알까? 클라이언트가 모든 서비스의 주소를 일일이 알고 있는 건 너무 복잡하고 비효율적이야.

그래서 우리는 API 게이트웨이라는 단일 진입점을 두는 거야. 게이트웨이의 역할은 다음과 같아.

• 라우팅 (Routing): 요청 URL을 보고 "아, `/api/v1/orders` 요청이네? 이건 주문 서비스로 보내야지." 하고 길을 안내해주는 역할.
• 인증 및 인가 (Authentication & Authorization): 요청에 포함된 토큰(JWT 같은)을 보고 "이 사용자는 로그인한 정상적인 사용자인가?", "이 사용자가 주문을 넣을 권한이 있나?"를 검사해. 자격 미달이면 "너는 못 지나간다!" 하고 컷.
• 요청/응답 변환 (Request/Response Transformation): 필요하다면 클라이언트가 보내준 요청을 내부 서비스가 이해하기 쉬운 형태로 바꾸거나, 그 반대의 작업을 수행해.
• 공통 기능 처리: 로깅, 사용량 제한(Rate Limiting), 캐싱 등 여러 서비스에 공통적으로 필요한 기능들을 게이트웨이에서 한 방에 처리할 수 있어. 코드 중복이 줄어들지.

Go의 `Gin` 프레임워크와 `net/http/httputil` 패키지의 `ReverseProxy`를 사용하면 비교적 간단하게 API 게이트웨이를 만들 수 있어.

package main

import (
	"log"
	"net/http"
	"net/http/httputil"
	"net/url"

	"github.com/gin-gonic/gin"
)

func main() {
	r := gin.Default()

	// 예: /user/ 로 시작하는 모든 요청은 사용자 서비스(localhost:8081)로 전달
	r.Any("/user/*path", proxyHandler("http://localhost:8081"))

	// 예: /order/ 로 시작하는 모든 요청은 주문 서비스(localhost:8082)로 전달
	r.Any("/order/*path", proxyHandler("http://localhost:8082"))

	r.Run(":8080") // 게이트웨이는 8080 포트에서 실행
}

func proxyHandler(target string) gin.HandlerFunc {
	targetURL, err := url.Parse(target)
	if err != nil {
		log.Fatal(err)
	}
	proxy := httputil.NewSingleHostReverseProxy(targetURL)

	return func(c *gin.Context) {
		// 여기에 인증(JWT 검증 등) 미들웨어를 추가할 수 있음!
		log.Println("Request received, forwarding to:", target)
		
		// Gin의 컨텍스트를 표준 http.Request로 변환하여 프록시로 전달
		proxy.ServeHTTP(c.Writer, c.Request)
	}
}

2. 사용자 서비스: "신분증 좀 보여주시겠어요?"

사용자 서비스는 말 그대로 사용자에 대한 모든 것을 관리해.

• 회원가입 및 로그인: 이메일, 비밀번호를 받아 계정을 생성하고, 로그인 요청 시 정보를 확인해. 비밀번호는 절대 그냥 저장하면 안 되고, `bcrypt` 같은 알고리즘으로 해싱해서 저장해야 하는 거 알지? 국룰이야!
• 인증 토큰 발급 (JWT): 로그인이 성공하면, "이 사용자는 인증되었다"는 증표로 JWT(JSON Web Token)를 발급해줘. 이 토큰에는 사용자 ID 같은 정보가 암호화되어 담겨 있어. 클라이언트는 이후 모든 요청에 이 JWT를 포함해서 보내고, API 게이트웨이는 이 토큰을 검증해서 사용자를 식별하는 거지.
• KYC/AML 관리: 'Know Your Customer(고객 알기 제도)'와 'Anti-Money Laundering(자금 세탁 방지)'는 금융 서비스의 필수 요건이야. 사용자의 신분증, 주소 증명 서류 등을 받아 신원을 확인하고, 거래 레벨을 관리하는 기능이 필요해.

Go로 JWT를 생성하고 검증하는 건 `github.com/golang-jwt/jwt` 라이브러리를 사용하면 아주 쉬워.

import (
	"time"
	"github.com/golang-jwt/jwt/v5"
)

var jwtKey = []byte("my_super_secret_key") // 실제로는 훨씬 복잡하고 안전한 키를 사용해야 함!

type Claims struct {
	UserID uint `json:"user_id"`
	jwt.RegisteredClaims
}

// GenerateJWT는 사용자 ID를 받아 JWT를 생성
func GenerateJWT(userID uint) (string, error) {
	expirationTime := time.Now().Add(24 * time.Hour) // 토큰 유효기간: 24시간
	claims := &Claims{
		UserID: userID,
		RegisteredClaims: jwt.RegisteredClaims{
			ExpiresAt: jwt.NewNumericDate(expirationTime),
		},
	}

	token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
	return token.SignedString(jwtKey)
}

// ValidateJWT는 토큰 문자열을 받아 유효성을 검증하고 클레임을 반환
func ValidateJWT(tokenStr string) (*Claims, error) {
	claims := &Claims{}
	token, err := jwt.ParseWithClaims(tokenStr, claims, func(token *jwt.Token) (interface{}, error) {
		return jwtKey, nil
	})

	if err != nil {
		return nil, err
	}
	if !token.Valid {
		return nil, errors.New("invalid token")
	}

	return claims, nil
}

이렇게 API 게이트웨이와 사용자 서비스가 튼튼하게 자리를 잡고 있어야, 뒤에 있는 핵심 서비스들이 안전하게 자기 일에만 집중할 수 있는 환경이 만들어지는 거야. 이제 사용자들이 실시간으로 시세 변동을 볼 수 있게 만들어주러 가볼까?

⚡ WebSockets으로 실시간 데이터 뿜어주기

거래소 화면을 띄워놓고 있는데, 가격이 내가 새로고침(F5)을 눌러야만 바뀐다면? 호가창이 멈춰있다가 한참 뒤에 업데이트된다면? 아마 하루 만에 모든 사용자가 떠나갈 거야. 🤣 성공적인 거래소의 필수 조건은 바로 '실시간'이야. 차트가 부드럽게 움직이고, 호가창과 체결 내역이 눈앞에서 파바박 하고 바뀌어야 "아, 이 거래소 좀 치네?" 하는 소리를 듣는 거지.

이런 실시간 양방향 통신을 구현하는 데 가장 널리 쓰이는 기술이 바로 웹소켓(WebSocket)이야. 클라이언트와 서버가 한 번 연결을 맺으면, 그 연결을 계속 유지하면서 어느 쪽에서든 원할 때 데이터를 보낼 수 있는 기술이지. 서버가 "야, 방금 10,500원에 비트코인 체결됐어!" 하고 능동적으로 클라이언트에게 정보를 쏴줄 수 있다는 거야.

1. 웹소켓은 어떻게 작동할까?

기존의 HTTP 통신은 클라이언트가 요청하고 서버가 응답하면 연결이 끊어지는 '단방향' 방식이야. 그래서 실시간처럼 보이게 하려면 클라이언트가 1초에 한 번씩 계속해서 서버에 "뭐 새로운 거 없어?" 하고 물어봐야 해(폴링, Polling). 이건 엄청난 낭비지.

웹소켓은 달라. 처음에는 HTTP 프로토콜로 "우리 이제부터 웹소켓으로 대화하자!" 하고 악수(Handshake)를 해. 서버가 "OK!" 하면, 그 다음부터는 둘만의 전용 통신 채널(TCP 연결)이 열리는 거야. 이 채널은 누군가 명시적으로 끊기 전까지 계속 살아있어. 덕분에 불필요한 HTTP 요청/응답 오버헤드가 없고, 지연 시간도 훨씬 짧아.

2. Go와 Gorilla WebSocket으로 서버 만들기

Go 생태계에는 아주 훌륭한 웹소켓 라이브러리인 `Gorilla WebSocket`이 있어. 이걸 사용해서 간단한 웹소켓 서버를 만들어보자. 이 서버는 클라이언트가 접속하면 1초마다 "현재 시간은..." 하고 메시지를 보내주는 역할을 할 거야. 실제 거래소에서는 '시장 데이터 서비스'가 이 역할을 하겠지?

package main

import (
	"log"
	"net/http"
	"time"

	"github.com/gorilla/websocket"
)

// Upgrader는 일반 HTTP 연결을 웹소켓 연결로 업그레이드하는 역할을 함
var upgrader = websocket.Upgrader{
	ReadBufferSize:  1024,
	WriteBufferSize: 1024,
	// 실제 프로덕션에서는 Origin을 체크해서 허가된 도메인의 요청만 받아야 함
	CheckOrigin: func(r *http.Request) bool { return true },
}

// handleConnections는 웹소켓 요청을 처리하는 핸들러
func handleConnections(w http.ResponseWriter, r *http.Request) {
	// HTTP 연결을 웹소켓으로 업그레이드
	ws, err := upgrader.Upgrade(w, r, nil)
	if err != nil {
		log.Fatal(err)
	}
	// 함수가 끝나면 웹소켓 연결을 꼭 닫아줘야 함
	defer ws.Close()

	log.Println("Client connected!")

	// 1초마다 클라이언트에게 메시지를 보내는 무한 루프
	for {
		// 메시지 타입과 내용을 준비
		messageType := websocket.TextMessage
		message := []byte("Current time is: " + time.Now().Format(time.RFC1123))

		// 클라이언트에게 메시지 쓰기
		err := ws.WriteMessage(messageType, message)
		if err != nil {
			log.Println("Write error:", err)
			break // 에러 발생 시 루프 종료 (클라이언트 연결 끊김 등)
		}

		// 1초 대기
		time.Sleep(1 * time.Second)
	}
}

func main() {
	http.HandleFunc("/ws", handleConnections)
	log.Println("http server started on :8000")
	err := http.ListenAndServe(":8000", nil)
	if err != nil {
		log.Fatal("ListenAndServe: ", err)
	}
}

이 코드를 실행하고, 웹소켓을 테스트할 수 있는 클라이언트(예: Postman 또는 간단한 HTML/JS 페이지)로 `ws://localhost:8000/ws`에 접속하면, 1초마다 서버로부터 시간 정보를 받는 걸 볼 수 있을 거야.

3. 실제 거래소에 적용하기: Pub/Sub 모델

실제 거래소에서는 훨씬 더 복잡한 시나리오를 다뤄야 해.

• 다양한 채널: 사용자는 'BTC/KRW 호가창', 'ETH/KRW 실시간 체결 내역', '내 주문 체결 알림' 등 원하는 정보만 구독(Subscribe)하고 싶어 할 거야.
• 수많은 클라이언트: 수만, 수십만 명의 사용자가 동시에 접속해 있을 수 있어.

이런 문제를 해결하기 위해 발행/구독(Publish/Subscribe, Pub/Sub) 모델을 사용해.

1. 매칭 엔진이 거래를 체결시키면, 'BTC/KRW 거래 체결'이라는 이벤트를 메시지 큐(Kafka 등)에 발행(Publish)한다.
2. 시장 데이터 서비스는 이 메시지를 구독(Subscribe)하고 있다가, 메시지를 받으면 "아! BTC 거래가 체결됐구나!" 하고 알아차린다.
3. 시장 데이터 서비스는 현재 'BTC/KRW 실시간 체결 내역' 채널을 구독하고 있는 모든 웹소켓 클라이언트들에게 이 체결 정보를 쫙~ 뿌려준다(Broadcast).

이렇게 하면 매칭 엔진은 그냥 자기 할 일(체결)만 하고 이벤트만 던져주면 되고, 시장 데이터 서비스는 그 이벤트를 받아서 관심 있는 클라이언트들에게만 전달해주면 되니 역할 분리가 확실해지고 시스템 전체의 부하도 분산되지.

이런 복잡한 실시간 시스템을 구축하는 데 어려움을 겪는다면, 재능넷 같은 플랫폼에서 Go 언어나 시스템 아키텍처 전문가의 도움을 받아보는 것도 좋은 방법이야. 고수의 어깨에 올라타면 더 멀리 볼 수 있는 법이니까! 😉

🗄️ 데이터베이스 선택과 관리: 어떤 데이터를 어디에 담을까?

우리 거래소는 정말 다양한 종류의 데이터를 다뤄야 해. 사용자 정보, 주문 내역, 체결 기록, 지갑 주소... 이 소중한 데이터들을 어디에, 어떻게 저장해야 할까? 데이터베이스를 선택하는 건 우리 집의 가구를 고르는 것과 같아. 어떤 가구는 서랍이 많아야 하고, 어떤 가구는 튼튼해야 하고, 어떤 가구는 빨리 꺼내 쓸 수 있어야 하지. 데이터의 성격에 따라 최적의 데이터베이스를 선택하는 '데이터 폴리글랏(Data Polyglot)' 전략이 필요해.

1. 관계형 데이터베이스 (RDBMS): 신뢰의 아이콘

언제 사용할까? 데이터의 정합성과 일관성이 매우 중요할 때. 즉, 돈과 관련된 거의 모든 데이터!

• 사용자 정보: ID, 이메일, 비밀번호 해시, KYC 인증 레벨 등
• 주문 및 체결 내역: 누가, 언제, 어떤 코인을, 얼마에, 얼마나 주문했고 체결되었는지에 대한 기록. 이건 법적 증거 자료가 될 수도 있어.
• 자산 원장: 각 사용자가 코인별로 얼마의 잔고를 가지고 있는지 기록. 입출금 내역.

왜 RDBMS인가? 바로 트랜잭션(Transaction) 기능 때문이야. 'A 사용자의 원화 잔고를 100만원 줄이고, B 사용자의 원화 잔고를 100만원 늘린다'는 두 작업은 반드시 둘 다 성공하거나, 하나라도 실패하면 둘 다 없던 일(롤백)이 되어야 해. 이런 원자성(Atomicity)을 보장해주는 게 바로 트랜잭션이야. PostgreSQL이나 MySQL 같은 RDBMS가 이런 작업에 최적화되어 있어.

Go에서는 GORM 라이브러리를 사용하면 이런 RDBMS를 아주 편리하게 다룰 수 있어. SQL 쿼리를 직접 작성하지 않고도 Go 코드로 데이터베이스 작업을 할 수 있지.

import (
  "gorm.io/gorm"
  "gorm.io/driver/postgres"
)

// User 모델 정의
type User struct {
  gorm.Model // ID, CreatedAt, UpdatedAt, DeletedAt 필드 자동 포함
  Email    string `gorm:"unique"`
  Password string
  Balance  float64
}

func main() {
  dsn := "host=localhost user=gorm password=gorm dbname=gorm port=9920 sslmode=disable"
  db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{})
  if err != nil {
    panic("failed to connect database")
  }

  // 테이블 자동 생성 (마이그레이션)
  db.AutoMigrate(&User{})

  // 사용자 생성
  db.Create(&User{Email: "test@example.com", Password: "hashed_password", Balance: 10000})

  // 사용자 조회
  var user User
  db.First(&user, "email = ?", "test@example.com") // SELECT * FROM users WHERE email = 'test@example.com';
  
  // ...
}

2. NoSQL 데이터베이스: 속도와 유연성의 대명사

모든 데이터를 RDBMS에 넣는 건 비효율적일 수 있어. 어떤 데이터는 정합성보다는 엄청나게 빠른 읽기/쓰기 속도가 더 중요하거든. 이럴 때 NoSQL 데이터베이스가 활약해.

대표 주자: Redis (인메모리 Key-Value 스토어)

• 오더북 캐싱: 오더북은 초당 수천 번씩 바뀌고, 수만 명의 사용자가 동시에 쳐다봐. 이 모든 요청을 매번 RDBMS까지 보낸다면 DB는 비명을 지를 거야. 그래서 현재 오더북의 스냅샷을 메모리 기반인 Redis에 저장해두고, 읽기 요청은 Redis에서 처리하는 거야. 훨씬 빠르지!
• 실시간 시세(Ticker) 저장: "현재가", "24시간 거래량" 같은 정보는 아주 빈번하게 업데이트되고 조회돼. 이런 데이터도 Redis에 저장하면 좋아.
• 세션 관리: 사용자의 로그인 세션 정보를 저장하는 데도 Redis는 훌륭한 선택이야.

Go에서는 `go-redis` 라이브러리를 사용해서 Redis와 쉽게 통신할 수 있어.

import "github.com/go-redis/redis/v8"

var ctx = context.Background()

func main() {
    rdb := redis.NewClient(&redis.Options{
        Addr:     "localhost:6379",
        Password: "", // no password set
        DB:       0,  // use default DB
    })

    // 오더북 데이터를 JSON 형태로 직렬화해서 저장한다고 가정
    orderbookJSON := `{"bids": [...], "asks": [...]}`
    err := rdb.Set(ctx, "orderbook:btc-krw", orderbookJSON, 0).Err()
    if err != nil {
        panic(err)
    }

    // 저장된 오더북 데이터 읽기
    val, err := rdb.Get(ctx, "orderbook:btc-krw").Result()
    if err != nil {
        panic(err)
    }
    fmt.Println("orderbook:btc-krw", val)
}

결론: "정답은 없다. 상황에 맞게 섞어 쓰는 게 최고다." 트랜잭션이 중요한 핵심 데이터는 PostgreSQL 같은 RDBMS에, 속도가 생명인 휘발성 데이터나 캐시는 Redis 같은 NoSQL에 저장하는 하이브리드 전략이 우리 거래소를 더욱 강력하고 빠르게 만들어 줄 거야.

🚀 배포와 확장: 우리 거래소를 세상에 내놓고 키우기

자, 드디어 우리 거래소의 핵심 기능들이 완성됐어. 내 컴퓨터에서는 아주 잘 돌아가. 이제 이걸 세상에 공개하고, 수백만 명이 사용해도 끄떡없는 서비스로 만들어야지! 이 과정을 배포(Deployment)와 확장(Scaling)이라고 해. 여기서부터는 'DevOps'의 영역이 시작돼. 개발(Dev)과 운영(Ops)은 하나다!

1. 컨테이너화: "내 컴퓨터에선 잘 됐는데..."의 종말 (Docker)

"제 컴퓨터에서는 잘 돌아가는데요?" 라는 말, 개발자라면 한 번쯤 해봤거나 들어봤을 거야. 😅 개발 환경과 실제 서버 환경이 달라서 생기는 문제지. 이런 문제를 해결하기 위해 등장한 구원자가 바로 도커(Docker)야.

도커는 우리 애플리케이션(Go로 만든 서비스)과 그 실행에 필요한 모든 것(라이브러리, 설정 파일 등)을 '컨테이너'라는 표준화된 상자에 담아버리는 기술이야. 이 상자는 어디서든 똑같이 작동해. 내 노트북, 동료의 컴퓨터, AWS 서버... 어디서든! 우리는 우리가 만든 마이크로서비스들(사용자 서비스, 주문 서비스 등)을 각각의 도커 컨테이너로 만들 거야.

Go 애플리케이션을 위한 `Dockerfile`은 보통 이렇게 생겼어.

# 1단계: 빌드 환경
# 가벼운 알파인 리눅스 기반의 Go 이미지를 사용
FROM golang:1.22-alpine AS builder

# 작업 디렉토리 설정
WORKDIR /app

# 의존성 파일 먼저 복사해서 캐싱 활용
COPY go.mod go.sum ./
RUN go mod download

# 소스 코드 복사
COPY . .

# 애플리케이션 빌드
# CGO_ENABLED=0: C 라이브러리 의존성 없이 순수 Go 바이너리 생성
# -o /app/main: 빌드 결과물을 /app/main 파일로 저장
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/main .

# 2단계: 실행 환경
# 아무것도 없는 아주아주 가벼운 scratch 이미지에서 시작
FROM scratch

# 빌드 환경에서 작업 디렉토리 설정
WORKDIR /app

# 빌드 단계에서 생성한 바이너리 파일만 복사
COPY --from=builder /app/main .

# 컨테이너가 시작될 때 실행할 명령어
CMD ["/app/main"]

이 `Dockerfile`을 사용해서 `docker build` 명령을 실행하면, 우리 Go 서비스가 담긴 작고 가벼운 컨테이너 이미지가 뚝딱 만들어져. 이걸 `docker run` 하면 서비스가 실행되는 거지. 이제 환경 탓은 끝!

2. 오케스트레이션: 컨테이너 군단을 지휘하라 (Kubernetes)

컨테이너가 1~2개일 때는 수동으로 관리할 수 있겠지만, 우리 거래소는 수십, 수백 개의 컨테이너가 돌아갈 거야. 사용자가 몰리면 주문 서비스 컨테이너를 3개에서 10개로 늘려야 하고, 특정 컨테이너가 죽으면 자동으로 다시 살려내야 해. 이런 복잡한 컨테이너 군단을 자동으로 관리하고 지휘해주는 시스템이 바로 쿠버네티스(Kubernetes, k8s)야.

쿠버네티스는 컨테이너 오케스트레이션의 사실상 표준(De facto standard)이야. 우리가 할 일은 "주문 서비스는 컨테이너 3개를 유지해줘. CPU 사용량이 80%를 넘으면 10개까지 자동으로 늘려줘." 라고 선언적인 설정 파일(YAML)을 작성해서 알려주는 것뿐. 나머지는 쿠버네티스가 알아서 다 해줘.

• 자동 스케일링 (Auto-scaling): 트래픽에 따라 컨테이너 수를 자동으로 조절.
• 자가 치유 (Self-healing): 컨테이너나 서버에 문제가 생기면 자동으로 재시작하거나 다른 곳으로 옮겨줘.
• 서비스 디스커버리 & 로드 밸런싱: 서비스들이 서로를 쉽게 찾을 수 있게 해주고, 여러 컨테이너에 트래픽을 골고루 분산시켜줘.
• 무중단 배포 (Rolling Update): 구버전 컨테이너를 하나씩 신버전으로 교체해가며 배포해서, 서비스 중단 없이 업데이트를 할 수 있어.

물론 도커와 쿠버네티스는 그 자체로도 배워야 할 게 많은 거대한 주제야. 하지만 걱정 마. 요즘은 AWS EKS, Google GKE, Azure AKS 같은 클라우드 서비스들이 관리형 쿠버네티스를 제공해서 예전보다 훨씬 쉽게 시작할 수 있어. 우리는 Go로 튼튼한 서비스를 만드는 데 집중하고, 복잡한 인프라 관리는 똑똑한 도구들에게 맡기자고!

🏁 에필로그: 이제부터가 진짜 시작이다

와, 여기까지 따라오느라 정말 고생 많았어! 👏 우리는 Go 언어를 가지고 암호화폐 거래소라는 거대한 산의 등반로를 함께 걸어왔어. 마이크로서비스 아키텍처라는 지도를 펼치고, 매칭 엔진이라는 심장을 만들고, 지갑 서비스라는 금고의 보안을 고민했지. API 게이트웨이와 웹소켓으로 사용자와 소통하는 법을 배우고, 데이터베이스와 컨테이너 기술로 우리 서비스를 세상에 내놓을 준비까지 마쳤어.

이 글을 다 읽었다고 해서 당장 내일부터 거래소를 운영할 수 있는 건 아닐 거야. 우리가 다룬 건 핵심적인 기술 개념들이고, 실제 상용 서비스를 만들기 위해서는 훨씬 더 많은 디테일과 노력이 필요해.

• 법률 및 규제 준수: 암호화폐 거래소는 매우 엄격한 법적 규제를 받아. 각국의 자금세탁방지(AML), 정보보호(ISMS) 등의 규정을 반드시 확인하고 준수해야 해. 이건 기술보다 더 중요할 수 있어.
• 테스트, 테스트, 테스트: 단위 테스트, 통합 테스트, 부하 테스트... 상상할 수 있는 모든 종류의 테스트를 통해 시스템의 안정성을 검증해야 해. 돈이 오가는 시스템이니까!
• 모니터링과 로깅: 시스템이 잘 돌아가는지 24시간 감시하고, 문제가 생겼을 때 원인을 빠르게 찾을 수 있도록 상세한 로그를 남기는 체계를 갖춰야 해.
• 사용자 경험 (UX/UI): 기술적으로 아무리 뛰어나도 사용하기 불편하면 아무도 쓰지 않아. 직관적이고 아름다운 인터페이스는 필수야.

하지만 중요한 건, 이제 당신은 이 모든 걸 해낼 수 있는 '지도'와 '나침반'을 가졌다는 거야. 어떤 기술을 공부해야 하는지, 시스템이 어떤 구조로 돌아가야 하는지 큰 그림을 이해하게 된 거지. 이것만으로도 엄청난 성장이야.

이 프로젝트는 혼자서 하기엔 버거울 수 있어. 그럴 땐 주저하지 말고 커뮤니티에 질문하고, 동료를 찾아봐. 재능넷 같은 플랫폼에서 당신의 부족한 부분을 채워줄 전문가를 만나거나, 당신의 지식을 다른 사람과 나누는 것도 멋진 경험이 될 거야. 개발은 결국 함께 성장하는 과정이니까.

이제 당신의 키보드 위에서 새로운 디지털 금융의 역사가 시작되기를 응원할게. Happy Coding! 그리고... To the Moon! 🌕