나는 Python으로 Mini Derivatives Exchange를 구축했다. 커서를 사용했지만 주도하게 두지 않은 방법.

Source: Dev.to

동기

올해 나는 시니어 엔지니어로서 AI‑보조 코딩 실력을 한 단계 끌어올리는 동시에 트레이딩도 탐구하고 싶었습니다. 주문서, 지정가 및 시장가 주문, 매칭 엔진, 포지션 추적 기능을 포함한 종이 파생상품 거래소를 구축했습니다. 사용한 스택은 Python, FastAPI, PostgreSQL입니다. 프로젝트 전반에 걸쳐 Cursor를 사용했지만 “프롬프트만 입력하면 전체 앱이 완성된다”는 방식은 아니었습니다.

계획

한 페이지 아키텍처

IDE가 아니라 문서를 열어 단일 아키텍처 및 프로젝트 파일을 작성했으며, 다음을 포함했습니다:

• 레포지토리 분리 – 프론트엔드와 백엔드는 항상 별개이며, 백엔드당 하나의 배포 가능한 단위가 있습니다.
• 레포지토리 책임 – 거래소 API, 데모 UI, 그리고 향후 게임화 통합을 위한 자리표시자.
• 기술 선택 – FastAPI, PostgreSQL, 가격 정보를 위한 Binance 공개 API (아직 Kafka는 사용 안 함).
• 모듈 경계 – core, market_data, orders, matching, positions, integration 등, 각각 명확한 역할과 공개 인터페이스를 가집니다.

그 문서는 Cursor를 안내하는 계획이 되었습니다. Cursor가 UI를 API와 같은 레포지토리에 두자고 제안했을 때, 저는 문서를 다시 가리키며 거절했습니다. 이것이 바로 Cursor의 Plan Mode와 같습니다: 에이전트가 코드를 작성하기 전에 설계와 파일 수준의 계획을 정확히 잡는 것입니다.

아키텍처

저는 모듈형 모놀리식을 선택했습니다: 하나의 서비스, 하나의 데이터베이스이지만 엄격한 모듈 경계를 유지합니다. 각 모듈은 공개 인터페이스(예: OrderService.place, OrderBook.add)를 노출합니다. 어떤 모듈도 다른 모듈의 내부를 가져오지 않습니다.

왜 모듈형 모놀리식인가?

1. 운영을 단순하게 유지합니다.
2. Cursor에게 “전체 거래 흐름을 구축하라”가 아니라 “orders 모듈에서 OrderService.place를 구현하고 매칭 엔진에 연결하라”와 같이 매우 구체적인 작업을 부여할 수 있습니다.

구현 세부 사항

매칭 엔진

매칭 엔진은 시스템의 핵심입니다. 가격‑시간 우선순위, 제한 및 시장 주문 지원, 포지션 업데이트 및 선택적으로 체결 시 게임화 API에 ping을 보낼 수 있는 기능을 원했습니다.

구현을 작고 검토 가능한 단계로 나누었습니다:

1. 데이터 구조 – Order, Fill, 그리고 OrderBook(가격 레벨별 매수·매도) 정의. 원하는 동작을 설명하고 Cursor에게 add, insert, cancel, best_bid, best_ask와 같은 메서드를 구현하도록 했습니다.
2. 매칭 로직 – 주문이 들어오면 DB에서 책을 로드(모든 미체결 제한 주문), book.add(order)를 실행하고 Fills 리스트를 받습니다. Cursor가 코드를 생성했고, 나는 체결이 주문과 포지션에 어떻게 적용되는지 검토했습니다.
3. 영속성 – 주문과 포지션은 PostgreSQL에 저장됩니다. 책은 매 주문 및 취소 작업 시 DB에서 재구성되며, 장기 메모리 상태를 유지하지 않습니다. 이 트레이드오프는 초저지연보다 단순성과 정확성을 우선시하는 프로토타입에 적합합니다.

각 단계는 명확한 성공 기준을 가진 집중된 프롬프트였습니다. 문제가 발생했을 때(예: 메이커 주문이 체결 시 업데이트되지 않음) 나는 코드를 되돌리고 계획을 다듬은 뒤 에이전트를 다시 실행했으며, 채팅에서 무한히 패치를 시도하지 않았습니다.

프롬프트 관리 유지

전체 코드베이스를 프롬프트에 붙여넣지 않았습니다. 대신 아키텍처 문서와 README를 “규칙”으로 사용했습니다. “positions/service.py와 동일한 패턴으로 체결을 적용하는 통합 호출을 추가해 주세요.”와 같이 기존 파일을 지정했습니다. Cursor는 grep과 의미 검색을 이용해 주문이 저장되는 위치와 포지션이 업데이트되는 위치를 찾아냈으며, 프롬프트를 짧게 유지하고 에이전트를 내가 설정한 경계 내에 두었습니다.

결과

• 제한가 및 시장가 주문이 포함된 주문서.
• 포지션 추적.
• Binance의 실시간 시장 데이터 (API 키 필요 없음).
• 체결 시 게임화 API에 선택적 POST.
• 아키텍처 다이어그램, 시스템 설계 노트, API 표가 포함된 README.
• 로컬 개발을 위한 Docker Compose 구성.

프로덕션 준비 체크리스트

프로젝트를 프로덕션 준비 상태로 고려하기 전에 다음을 추가하겠습니다:

• 속도 제한 (예: Redis).
• 매칭 엔진에 대한 포괄적인 단위 테스트 (OrderBook.add, insert, cancel).
• 주문 배치, 취소 및 주문서 재구성을 위한 통합 테스트.

핵심 요점

1. 먼저 아키텍처와 모듈 맵을 작성한다.
2. 구현을 작고 검토 가능한 단계로 나눈다.
3. “모두 만들기” 요청 대신 에이전트에게 명확한 경계와 구체적인 예시를 제공한다.
4. 출력이 사양에서 벗어날 때마다 계획을 되돌리고 다듬는다.

그 결과는 인터뷰에서 설명할 수 있는 코드베이스와, 설계를 AI에게 맡기지 않고 활용한 이야기가 된다.

저장소 링크

• Backend: mini-derivatives-exchange – API, 매칭 엔진 및 데이터베이스 레이어를 포함합니다.
• Frontend: mini-exchange-ui – API를 활용하는 데모 UI입니다.

두 저장소 모두 아키텍처 다이어그램, API 문서 및 시스템‑설계 노트를 포함한 README를 제공합니다.