초보자 매매 봇 UI: 중지 의도와 주문 결과를 명확하게
TECH INSIGHT / EXPLAINED
초보자가 매매 패널에서 확인해야 할 것은 세 가지다. 지금 보는 정보가 최신인지, 버튼을 누르면 무엇이 바뀌는지, 결과를 어디서 확인하는지. 이 세 질문에 답하는 화면은 숫자가 많은 화면보다 실수를 발견하기 쉽다.
기존 사용 화면과 소개 이미지
기존 글에 담았던 사용 화면과 소개 이미지를 함께 보며 구조와 동작을 확인할 수 있습니다.


공개 프로젝트 화면 캡처
아래는 이 글에서 다루는 프로젝트의 공개 페이지를 직접 열어 촬영한 화면입니다. 각 그림에 출처와 촬영 날짜를 표시했습니다.
종목·계좌·행동을 같은 자리에서 보여 준다
종목 카드의 순서는 이름과 코드, 조회 시각, 보유량과 주문 상태, 해당 종목 동작으로 고정한다. 표시 전용 값은 텍스트나 output으로, 편집 항목은 명확한 label과 단위가 있는 입력란으로 구분한다. readonly는 편집을 줄이는 UI 속성이지 서버 검증이나 권한 통제가 아니다.
수량 0, 값 없음, 조회 중, 조회 실패를 모두 ‘—’로 표시하지 않는다. ‘보유 0주’, ‘조회 중’, ‘3분 전 정보’, ‘조회 실패: 다시 확인’처럼 의미를 적는다. 400px 팝업은 한 가지 설계 선택이며 넓은 이력은 별도 화면에 둘 수 있다.
저장·시작·주문·중지는 서로 다른 동작이다
저장은 설정만 변경하고 그 결과로 거래가 시작되는지 명시한다. 시작은 활성화할 계좌, 전략과 한도를 보여 준 뒤 실행한다. 직접 주문에는 종목, 매수·매도 방향, 수량, 주문 유형과 가격 조건을 검토하는 단계를 둔다. 자주 쓰는 모든 설정에 같은 확인창을 붙이는 대신 금전적 결과가 생기는 요청에서 내용을 확인하고 수정할 수 있게 한다.
‘청산’은 시장가 전량 매도인지 지정가 매도 요청인지 모호하다. 실제 동작에 맞는 이름과 설명이 필요하다. 매수·매도 색상은 시장마다 관습이 다르므로 텍스트와 아이콘을 함께 사용한다.
사용자의 중지 의도를 보존한다
화면에서 중지를 눌렀으면 원하는 상태는 비활성화다. 서버를 다시 조회한 뒤 반대 상태로 바꾸는 토글은 다른 기기의 동작과 경합할 때 시작 요청이 될 수 있다. 명시적인 중지 요청은 반복돼도 다시 시작하지 않아야 한다.
설정이 아직 로딩되지 않았을 때 신규 주문과 시작은 막는다. 중지는 저장·주문 화면의 로딩 성공에만 의존하지 않도록 별도 경로를 설계한다. 인증과 대상 계좌를 확인할 수 없으면 중지 성공을 선언하지 말고 복구 경로를 보여 준다. 새 실행 중지, 미체결 주문 취소, 보유 자산 매도는 별도 기능이다.
서버 응답이 불명확하면 상태도 불명확하다
응답에 status가 없다고 OFF로 대체하면 실제 가동 중인 봇을 멈췄다고 오인할 수 있다. ‘요청 중’, ‘서버 접수’, ‘중지 확인’, ‘확인 불가’를 구분한다. 활성화 여부 옆에는 마지막 성공 시각과 갱신 시각을 보여 준다. 버튼 연타 방지는 UI에서 하고, 요청 ID에 따른 중복 처리는 서버에서도 수행한다.
예를 들어 매도 가능 수량이 2주일 때 1주·2주 요청은 수량 측면에서 통과할 수 있고 3주 요청은 거절해야 한다. 보유량이 정확히 1인지 검사하는 조건은 이런 요구와 다르다. 서버는 최신 매도 가능 수량, 이미 걸린 주문, 입력 형식과 권한을 다시 확인한다. 매수는 보유 수량이 아니라 주문 가능 금액 등 해당 조건으로 검증한다.
실패 이유를 읽을 수 있게 남긴다
저장 완료와 주문 체결을 같은 성공 메시지로 표현하지 않는다. 로그에는 시각, 대상, 요청 ID와 다음 확인 경로를 남기고 비밀은 가린다. 팝업이 닫히면 사라지는 로그를 영구 이력처럼 설명하지 않는다. 오래된 로그를 읽는 중에는 강제로 맨 아래로 스크롤하지 말고 새 항목 표시를 제공한다.
키보드로 버튼에 도달할 수 있는지, 포커스가 보이는지, 오류 문구가 입력란에 연결되는지 확인한다. 중요한 상태 갱신은 적절한 status/live region으로 전달하되 모든 로그를 경고로 읽게 만들지는 않는다. 화면 읽기 도구와 색상을 구분하기 어려운 사용자도 같은 결과를 이해해야 한다.
출시 전에는 실패 장면을 재현한다
느린 초기 조회, 오래된 상태, 두 기기의 동시 조작, 중복 클릭, 응답 유실, 부분 체결을 시험한다. 질문은 ‘버튼이 작동했나’보다 ‘사용자가 결과를 정확히 설명할 수 있나’다. UI의 확인 과정은 서버 측 한도와 주문 검증을 함께 갖출 때 효과가 있다.
참고 자료
내용·예제 검토: 2026-09-29
댓글
댓글 쓰기