주제: 자동매매

홈으로

  • 초보자 매매 봇 UI: 중지 의도와 주문 결과를 명확하게

    English version TECH INSIGHT / EXPLAINED 초보자가 매매 패널에서 확인해야 할 것은 세 가지다. 지금 보는 정보가 최신인지, 버튼을 누르면 무엇이 바뀌는지, 결과를 어디서 확인하는지. 이 세 질문에 답하는 화면은 숫자가 많은 화면보다 실수를 발견하기 쉽다.

  • GAS PropertiesService: 작은 설정 저장소의 범위·검증·복구

    English version TECH INSIGHT / EXPLAINED 설정 몇십 개를 저장하려고 데이터베이스부터 운영할 필요는 없다. PropertiesService는 작은 문자열 상태를 보관하기에 편리하다. 대신 실행 사용자, 입력 형식, 동시 변경과 크기 한도를 저장 함수의 계약으로 정해야 한다.

  • GAS 분 단위 트리거: 54초 루프의 한도와 중복 실행 방지

    English version TECH INSIGHT / EXPLAINED 분마다 시작하는 트리거 안에서 54초를 반복 실행하면 거의 상시 동작하는 것처럼 보인다. 하지만 실제 설계의 제약은 6분짜리 1회 실행 한도보다 하루 총 실행 시간과 중복 실행이다. 시간을 채우기 전에 필요한 관측 주기부터 정해야 한다.

  • 월배당 ETF 교체 규칙: 날짜·총수익·주문 상태를 분리하기

    English version TECH INSIGHT / EXPLAINED 달력에 ‘월중 ETF에서 월말 ETF로 이동’이라고 적는 것과, 주문 가능한 규칙을 만드는 것은 다르다. 날짜·분배금 자격·실제 체결·총수익을 각각 표현해야 한다. 여기서는 두 종목을 교체하는 아이디어를 검증 가능한 상태와 계산으로 바꾸며, 특정 상품이나 수익성을 추천하지 않는다.

  • Chrome 확장 매매 봇 패널: 권한·상태·중지 동작 설계

    English version TECH INSIGHT / EXPLAINED 매매 봇의 모든 정보를 작은 팝업에 넣으면 정작 중지 버튼을 찾기 어려워진다. 확장 프로그램을 리모컨으로 설계하면 우선순위가 선명해진다. 현재 상태, 최근 갱신 시각, 명시적인 시작·중지, 설정 저장 결과가 첫 화면에 있어야 한다.

  • Google Apps Script 백엔드: 작은 자동화의 실행 예산과 운영 경계

    English version TECH INSIGHT / EXPLAINED 주문 엔진을 만들기 전에, 시세를 정기적으로 읽고 설정을 보관하는 작은 백엔드부터 만들어 볼 수 있다. Google Apps Script는 이 실험의 진입 비용을 낮춰 준다. 다만 분 단위로 실행되는 작업과 계속 살아 있는 서버는 운영 방식이 다르다.

  • 멈춘 봇 진단: 프로세스·작업 진전·데이터 신선도

    English version TECH INSIGHT / EXPLAINED 대시보드가 멈췄다고 어느 구성요소가 고장 났는지는 알 수 없습니다. 프로세스 종료·실행 중 진전 없음·의도된 대기·봇은 계속 돌지만 화면만 갱신되지 않음을 먼저 구분합니다.

  • 포지션 사이징: 계획 손실 예산과 실제 최대 손실은 다르다

    English version TECH INSIGHT / EXPLAINED 포지션 사이징은 가정한 손실 시나리오를 수량으로 바꾸는 작업입니다. 손절 주문을 넣었다고 모든 상황에서 실제 손실이 그 예산과 같아지는 것은 아닙니다.

  • 슬리피지와 체결 품질: 평균가 계산부터 안전한 재주문까지

    English version TECH INSIGHT / EXPLAINED 체결 품질에는 기준 가격과 시간 순서가 필요합니다. 의사결정 가격과 수량 가중 평균 체결가의 차이를 구하고, 수수료와 미체결 수량은 따로 기록해야 합니다.

  • 자동매매 전략 비교: 페어 트레이딩 vs 그리드 vs 추세추종

    English version TECH INSIGHT / EXPLAINED 전략은 필요한 가정과 그 가정이 틀릴 때 남는 노출로 비교합니다. 페어·그리드·추세추종이 같은 기간에 함께 손실 볼 수도 있어 시장 국면 이름만으로 분산 효과가 보장되지는 않습니다.

  • 온체인 봇을 위한 텔레그램 알림 시스템 설계

    English version TECH INSIGHT / EXPLAINED 알림 경로는 거래 엔진을 막거나 백그라운드 작업을 무한히 만들지 않으면서 중요한 실패를 보여 줘야 합니다. Telegram도 접수 결과, 속도 제한, 실패 상태가 있는 전달 서비스로 다룹니다.

  • Go로 자동매매 신호봇 프레임워크 설계하기

    English version TECH INSIGHT / EXPLAINED 재사용 가능한 Go 봇은 데이터 수집, 결정론적인 판단, 위험 검사, 주문 실행, 알림을 분리합니다. 계약을 충족하는 작은 의존성을 선택하되 단일 바이너리라는 배포 방식이 상태 복구를 대신하지는 않습니다.

  • 자동매매 봇 개발 M1·M2·M3: 관찰, 재현, 복구 검증

    English version TECH INSIGHT / EXPLAINED 자동매매 봇을 단계별로 만든다는 것은 기능을 조금씩 켠다는 뜻만은 아닙니다. 각 단계가 끝났다고 판단할 증거를 먼저 정하고, 주문 전송 권한은 그 증거와 별도로 관리하는 방식입니다. 이 글의 M1·M2·M3는 설명을 위한 개발 단계 이름입니다. 특정 업계 표준이나 검증된 수익 전략을 뜻하지 않습니다. M1은 관찰, M2는 주문 없는 재현, M3는 장애 복구 연습 으로 나누며, 실거래 전환은 세 단계 이후의 별도 결정으로 둡니다.