주식 자동매매 프로그램 만들기 (1) - 요구사항 분석과 MVP 범위 정하기

대현·2026년 8월 7일

주식 자동매매 프로그램 만들기 (1) - 요구사항 분석과 MVP 범위 정하기

올해 초부터 계속 고민하던 개인 프로젝트가 하나 있었다.

바로 주식 자동매매 프로그램이다.

평소 증권 도메인에 관심이 많기도 했고, 자동매매 시스템이 실제로 어떤 구조로 동작하는지도 궁금했다.

특히 최근에는 금융권에서도 AI를 활용해 데이터를 분석하거나 투자 의사결정을 보조하는 사례가 늘어나고 있다.

그래서 단순히 증권사 API를 호출해서 주문을 보내는 프로그램보다는, 거래 시스템과 투자 판단 시스템을 분리해서 만들어보면 어떨까?라는 생각이 들었다.

대략적인 구조는 다음과 같다.

                    주식 자동매매 시스템

        ┌─────────────────────────────┐
        │   Python 분석 / 판단 시스템   │
        │                             │
        │  시장 데이터 분석             │
        │       ↓                     │
        │  매수 / 매도 전략             │
        │       ↓                     │
        │  BUY / SELL / HOLD 판단      │
        └──────────────┬──────────────┘
                       │
                       │ 거래 판단 결과
                       ↓
        ┌─────────────────────────────┐
        │   Java / Spring 거래 시스템   │
        │                             │
        │  인증 / 계좌 / 주문 / 체결     │
        │       ↓                     │
        │       증권사 API              │
        └─────────────────────────────┘

증권사 API와 통신하고 계좌, 주문 등의 도메인 객체를 관리하는 부분은 Java / Spring으로 구현하고,

실질적으로 데이터를 분석하여 매수와 매도를 판단하는 부분은 Python을 활용할 생각이다.

처음에는 간단한 규칙 기반 전략부터 시작하고, 이후 데이터를 충분히 확보하면 머신러닝이나 AI 모델을 적용해 판단 로직을 발전시키는 것이 최종적인 목표다.


그런데 무엇부터 만들어야 할까?

아이디어 자체는 올해 초부터 가지고 있었다.

하지만 학교도 다니고 여러 활동에도 참여하다 보니 정작 증권 도메인과 시스템 자체에 대해서는 제대로 공부하지 못했다.

그래서 이번 여름방학에는 미뤄두었던 이 프로젝트를 본격적으로 진행해 보려고 한다.

다만 이번 프로젝트에서는 곧바로 코드를 작성하고 싶지는 않았다.

학교에서 소프트웨어 공학과 개발론을 배우면서 항상 들었던 이야기가 있다.

개발은 코드를 작성하는 것부터 시작하는 것이 아니다.

무엇을 만들어야 하는지 정의하고, 필요한 기능을 분석하고, 구조를 설계한 뒤에야 실제 구현이 시작된다.

개인 프로젝트를 할 때는 아이디어가 떠오르면 바로 IDE부터 켜는 경우가 많았는데, 이번에는 학교에서 배운 개발 프로세스를 실제 개인 프로젝트에 적용해 보고 싶었다.

그래서 다음과 같은 순서로 프로젝트를 진행해 볼 생각이다.

요구사항 분석
      ↓
기능 목록 정리
      ↓
도메인 분석
      ↓
화면 / API / 데이터 구조 설계
      ↓
아키텍처 설계
      ↓
MVP 범위 결정
      ↓
개발
      ↓
테스트
      ↓
배포 / 운영
      ↓
개선 반복

물론 실제 개발에서는 이 과정이 항상 일직선으로 흘러가지는 않을 것이다.

개발하면서 새로운 요구사항이 생길 수도 있고, 설계가 잘못되었다면 이전 단계로 돌아갈 수도 있다.

그래도 '일단 만들고 나중에 생각하기'보다는 무엇을 왜 만드는지 먼저 정의해 보는 것을 이번 프로젝트의 또 다른 목표로 잡았다.


첫 번째 단계, 요구사항 분석

그렇다면 가장 먼저 해야 할 것은 요구사항 분석이다.

프로그램을 만들기 전에 최소한 다음 질문들에는 답할 수 있어야 한다고 생각했다.

  1. 이 프로그램은 사용자에게 무엇을 제공해야 하는가?
  2. 어떤 증권사 API와 통신할 것인가?
  3. 어떤 데이터를 가져와야 하는가?
  4. 어떤 조건에서 매수와 매도를 판단할 것인가?
  5. 주문 실패, API 오류, 잔고 부족 같은 상황은 어떻게 처리할 것인가?
  6. 첫 번째 버전에서는 어디까지 구현할 것인가?

처음 적어두었던 이 질문들은 별도의 개발 단계라기보다는 요구사항을 구체화하기 위해 스스로에게 던진 질문에 가깝다.

그리고 이를 바탕으로 요구사항을 사용자 요구사항과 시스템 요구사항으로 나누어 정리했다.


사용자 요구사항과 시스템 요구사항

두 요구사항은 비슷해 보이지만 관점이 다르다.

사용자 요구사항(User Requirement)

사용자 입장에서

"이 프로그램을 이용해서 무엇을 할 수 있어야 하는가?"

를 정의한다.

시스템 요구사항(System Requirement)

사용자 요구사항을 만족시키기 위해

"시스템 내부에서는 어떤 기능을 수행해야 하는가?"

를 정의한다.

예를 들어 사용자는 단순히

"내 계좌 상태를 보고 싶다."

라고 생각할 수 있다.

하지만 시스템 입장에서는 이를 위해

사용자 인증
    ↓
Access Token 발급
    ↓
증권사 API 요청
    ↓
계좌 정보 조회
    ↓
응답 데이터 변환
    ↓
사용자에게 전달

과 같은 여러 작업이 필요하다.

이 차이를 기준으로 요구사항을 정리해 보았다.


사용자 요구사항

현재 생각한 사용자 요구사항은 다음과 같다.

  1. 사용자는 증권 계좌에 투자금을 입금한다.
  2. 사용자는 자동매매 프로그램을 실행할 수 있다.
  3. 사용자는 계좌에서 현재 사용 가능한 잔액을 확인할 수 있다.
  4. 프로그램은 설정된 매수/매도 전략에 따라 거래 여부를 판단한다.
  5. 조건이 충족되면 프로그램은 매수 또는 매도를 수행할 수 있다.
  6. 사용자는 거래 결과와 현재 계좌 상태를 확인할 수 있어야 한다.

아직 초기 단계이기 때문에 상당히 큰 단위의 요구사항만 작성했다.

프로젝트를 진행하면서 실제 사용자 흐름을 구체화하면 더 세분화할 예정이다.


시스템 요구사항

사용자 요구사항을 실제로 구현하기 위해 시스템이 제공해야 하는 기능도 정리했다.

  1. 시스템은 증권사 API 인증 토큰을 발급받고 관리할 수 있어야 한다.
  2. 시스템은 계좌 잔고를 조회할 수 있어야 한다.
  3. 시스템은 보유 종목을 조회할 수 있어야 한다.
  4. 시스템은 특정 종목의 현재가를 조회할 수 있어야 한다.
  5. 시스템은 매수/매도 전략에 필요한 데이터를 판단 시스템에 전달할 수 있어야 한다.
  6. 판단 시스템은 데이터를 기반으로 매수/매도 여부를 결정할 수 있어야 한다.
  7. 시스템은 판단 결과에 따라 증권사에 매수/매도 주문을 요청할 수 있어야 한다.
  8. 시스템은 주문 및 체결 결과를 확인할 수 있어야 한다.
  9. 시스템은 거래 내역과 판단 결과를 로그로 저장할 수 있어야 한다.
  10. 시스템은 API 오류, 인증 실패, 잔고 부족 등의 예외 상황을 처리하고 기록할 수 있어야 한다.

아직 어떤 증권사 API를 사용할지, 두 시스템을 어떤 방식으로 통신시킬지는 완전히 결정하지 않았다.

REST API를 사용할 수도 있고, Python 판단 시스템을 별도의 서비스로 분리할 수도 있다.

이 부분은 이후 아키텍처 설계 단계에서 조금 더 구체적으로 고민해 보려고 한다.


그런데 처음부터 이걸 전부 만들어야 할까?

요구사항을 작성하고 보니 생각보다 구현해야 할 것이 많았다.

인증
계좌
시세
전략
주문
체결
로그
예외 처리
UI
백테스트
AI
...

여기에 처음부터 머신러닝 모델과 실시간 UI, 실제 주문까지 전부 넣으려고 하면 프로젝트가 끝나기도 전에 지칠 가능성이 높다.

그래서 필요한 것이 MVP다.


MVP란?

MVP는 Minimum Viable Product, 즉 최소 기능 제품을 의미한다.

쉽게 말하면

"우리 서비스의 핵심 가치를 확인하기 위해 첫 번째 버전에서는 어디까지 만들 것인가?"

를 정하는 것이다.

여기서 중요한 것은 단순히 기능을 적게 만드는 것이 아니다.

최소한의 기능만 가지고도 이 시스템의 핵심 흐름이 실제로 동작하는지 확인할 수 있어야 한다.

내 자동매매 프로그램에서 가장 먼저 검증하고 싶은 흐름은 다음과 같다.

증권사 API 연결
        ↓
계좌 / 시장 데이터 조회
        ↓
Python 판단 시스템으로 데이터 전달
        ↓
매수 / 매도 / 대기 판단
        ↓
결과 기록

이 흐름이 정상적으로 동작한다면 그다음에 실제 주문이나 복잡한 전략을 추가할 수 있다.


1차 MVP

그래서 첫 번째 MVP의 범위를 다음과 같이 잡았다.

1. API 인증

증권사 API를 사용하기 위한 인증 토큰을 정상적으로 발급받고 관리한다.

2. 계좌 잔고 조회

API를 통해 실제 계좌의 사용 가능한 잔액을 가져온다.

3. 특정 종목 현재가 조회

지정한 종목의 현재 가격 데이터를 가져온다.

4. 단순한 매수/매도 전략 구현

Python으로 가장 단순한 규칙 기반 전략부터 구현한다.

시장 데이터
    ↓
Python 전략
    ↓
BUY / SELL / HOLD

이 단계에서는 처음부터 복잡한 AI 모델을 사용하는 것이 아니라 Java/Spring 시스템과 Python 판단 시스템이 정상적으로 연결되는지 확인하는 것을 우선한다.

5. 모의 판단 결과 기록

1차 MVP에서는 실제 주문을 보내지 않는다.

[14:30:01] 삼성전자 현재가 : 80,000원
[14:30:01] 전략 판단 : BUY
[14:30:01] 주문 실행 : SKIP (MVP Simulation Mode)

이처럼 실제 돈이 움직이지 않는 상태에서 전체 파이프라인이 정상적으로 동작하는지 먼저 검증한다.


1차 MVP에서 제외할 것

반대로 처음부터 만들지 않을 기능도 명확하게 정했다.

  1. 실제 매수/매도 주문 실행
  2. 복잡한 투자 전략
  3. 머신러닝/딥러닝 기반 투자 판단
  4. 실시간 차트 UI
  5. 백테스트 시스템
  6. 서버 배포
  7. 모바일 알림

특히 AI 기반 투자 판단은 일부러 1차 MVP에서 제외했다.

최종적으로는 Python을 이용해 데이터를 분석하고 모델이 매수와 매도를 판단하도록 만드는 것이 목표지만, 아직 데이터 파이프라인조차 만들어지지 않은 상태에서 AI부터 붙이는 것은 순서가 아니라고 생각했다.

먼저

데이터를 제대로 가져올 수 있는가?

        ↓

Java/Spring과 Python이 통신할 수 있는가?

        ↓

판단 결과를 안정적으로 전달할 수 있는가?

        ↓

로그와 예외 처리가 정상적으로 이루어지는가?

부터 확인하려고 한다.

그다음 전략을 하나씩 고도화하면 된다.


앞으로의 방향

여기까지 내가 만들고자 하는 자동매매 프로그램의 요구사항과 1차 MVP를 간단하게 정리해 보았다.

아직은 설계 초기 단계라 앞으로 개발하면서 바뀌는 부분도 분명히 있을 것이다.

하지만 이번 프로젝트에서는 단순히

"자동매매 프로그램 하나 만들어봤다."

에서 끝내고 싶지는 않다.

요구사항 분석부터 도메인 설계, 아키텍처 설계, 구현, 테스트와 배포까지 학교에서 배운 소프트웨어 개발 과정을 실제 개인 프로젝트에 하나씩 적용해 보는 것이 또 하나의 목표다.

그리고 그 과정에서 왜 이런 구조를 선택했고, 어떤 문제가 발생했고, 어떻게 개선했는지도 계속 기록해 보려고 한다.

다음 글에서는 요구사항을 기반으로 실제로 구현해야 할 기능 목록을 조금 더 구체적으로 정리해 볼 예정이다.

다음 글 : 주식 자동매매 프로그램 만들기 (2) - 기능 목록 정의하기

profile
도전을 멈추지 않는 개발자

0개의 댓글