CUI 기반 Event-Driven ChatOps — 채팅창 하나로 운영하는 감독형 자동매매 구조
breakawaych가 제안한 구조는 화려한 대시보드와 풀 오토보다, 채팅 UI + 이벤트 기반 트리거 + 사람 승인(HITL) 조합이 더 단순하고 오래 버티는 운영면이라는 주장이다.
- 작성자: @breakawaych
- 시각: 2026-04-24 03:58 AM
- 반응: 3 replies, 9 reposts, 32 likes, 54 bookmarks, 9.1K views
- 프로필 바이오 관찰값: 정보관리 기술사 / Senior Lead PM / All-round Cyclist. 투자·트레이딩, 스윙·돌파, 롱·숏 균형, Agentic AI와 Vibe Coding에 관심.
단순함의 미학 CUI 기반 Event-Driven ChatOps 아키텍처
CUI 기반 Event-Driven ChatOps
지난 2개월간 자동매매 시스템을 만들며 깨닳은 단순한 아키텍처
자동매매 시스템을 만든다고 하면 사람들이 가장 먼저 떠올리는 그림이 있다.
화려한 대시보드. 실시간 차트. 빨갛고 파란 숫자들이 깜빡이는 모니터링 페이지. 한쪽엔 포지션, 다른 쪽엔 손익, 위쪽엔 알림 배지. 모바일 앱까지 만들어서 출퇴근길에도 본다.
6개월간 시스템을 만들면서 깨달은 건, 그 그림이 전부 함정이라는 사실이었다.
내가 도달한 구조는 한 줄로 요약된다.
CUI 기반 Event-Driven ChatOps
이름은 거창한데, 실제로는 무지하게 단순하다. 디스코드 채팅창 하나가 시스템의 전부다.
세 단어를 풀면
CUI (Conversational UI). 채팅 인터페이스. GUI를 만들지 않는다. 사용자가 매일 쓰는 메신저가 곧 UI다.
Event-Driven. 시간 기반 폴링이 아니라, 시장 이벤트가 모든 것의 트리거다. 가격이 도달하면, 알림이 오면, 그때 시스템이 깨어난다.
ChatOps. DevOps 진영에서 GitHub과 Slack이 보여준 패턴. 운영을 채팅으로 한다. 그걸 트레이딩에 가져왔다.
세 개의 단어 모두 새롭지 않다. 합쳐서 매매 시스템에 적용하니 다른 그림이 보였다.
실제 흐름
1. 이벤트 발생 (TradingView 웹훅 시그널 - 지표견님 시그널) 2. AI 분석 (지표 계산, 컨텍스트 수집, 주문 제안 생성) 3. 챗으로 카드 발송 (“삼성전자 1주 시장가 매수 어떠세요?“) 4. 내가 한 단어 응답 ([승인] 또는 [거부]) 5. 시스템이 실행 (KIS API 호출, 주문 전송) 6. 결과 회신 (주문번호 포함, 같은 채널에)
이게 전부다. 화면도 하나, 동작 흐름도 하나의 직선이다. 2번, 3번을 생략하고 자연어 기반으로 4번에서 명령을 내릴 수도 있다.
내가 보는 건 채팅창 하나. 시스템이 던지는 카드 한 장. 답하는 단어 하나. 돌아오는 회신 하나.
대시보드를 만들 필요가 없다. 모니터링 페이지를 만들 필요가 없다. 채팅 히스토리가 곧 로그다. 푸시 알림이 곧 모니터링이다. 모바일 앱? 디스코드 앱이 이미 깔려 있다.
왜 풀 오토가 아닌가
자동매매라는 단어를 들으면 사람들은 자동으로 “풀 오토”를 상상한다. 사람 손이 닿지 않는 깨끗한 자동화. 자는 동안에도 돈이 들어오는 그림.
6개월 동안 풀 오토를 시도하면서 배운 것들:
- 버그 한 번에 계좌가 박살난다
- 시장 이상 상황에 대응이 0이다
- 새벽에 깨서 로그를 보고 있는 나를 발견한다
- “AI를 믿는다”가 아니라 “AI에 인질로 잡힌다”
자동화의 목적은 자유였는데, 오히려 더 묶이게 된다.
반대로 풀 매뉴얼은 AI를 쓰는 의미가 없다. 그럼 그냥 평소처럼 손으로 매매하면 된다.
답은 가운데 있다. HITL (Human-in-the-loop), 한국어로 “감독형 자동화.”
- AI는 탐색·필터링·근거 제시·속도에 강하다
- 사람은 최종 판단·예외 대응·책임에 강하다
- 둘을 합치되, 마지막 방아쇠는 사람이 당긴다
이게 6개월간 깨지면서 도달한 균형점이다.
채팅이 왜 정답인가
처음엔 나도 웹 대시보드를 만들었다. 차트 라이브러리 골랐고, 인증 붙였고, 모바일 반응형 했고, 알림 권한 받았다. 두 달 걸렸다.
그러고 나니 깨달았다. 나는 그 페이지를 잘 안 본다.
이유는 단순했다. 페이지를 보려면 일부러 들어가야 한다. 브라우저를 열고, 북마크 누르고, 로그인하고. 마찰이 5단계.
반면 디스코드는 이미 켜져 있다. 메시지가 오면 바로 보인다. 답하는 데 3초. 마찰이 0단계.
UI를 만들지 않는 게 아니다. 이미 존재하는 UI를 쓰는 것이다. 사용자가 매일 쓰는 채팅창보다 좋은 UI는 없다.
이 깨달음을 한 줄로 정리하면:
대시보드를 만들 시간에, 디스코드 봇 한 줄을 만든다.
이벤트 드리븐의 의미
전통적 자동매매는 보통 폴링 구조다. 1분마다, 5분마다 시장을 확인한다. 조건에 맞으면 매매한다.
폴링은 단순하지만 비효율적이다. 99%의 시간은 “아무 일 없음”을 확인하는 데 쓴다. 그리고 진짜 중요한 순간엔 1분 늦는다.
이벤트 드리븐은 반대다. 무언가 발생할 때만 깨어난다.
- TradingView가 알림을 쏜다(지표견 시그널) → 웹훅 수신 → 시스템 가동
- 가격이 임계점 도달 → 거래소 푸시 → 분석 시작
- 정해진 시간 도달 → 스케줄러 발화 → 일과 시작
쉬는 시간엔 완전히 쉰다. 일할 시간엔 즉각 반응한다. 서버 비용도 적게 든다. 무엇보다 코드가 단순해진다. 각 이벤트에 핸들러 하나씩만 붙이면 된다.
ChatOps가 가르쳐 준 것
ChatOps는 매매를 위해 만들어진 패턴이 아니다. 인프라 운영팀이 슬랙 채널에서 서버 배포하고 장애 대응하던 문화다.
그 문화의 본질은:
- 모든 액션이 채팅에 남는다 = 자연스러운 감사 로그
- 팀원이 옆에서 지켜본다 = 투명성
- 봇이 동료처럼 끼어든다 = 자동화와 사람의 자연스러운 협업
이걸 1인 트레이더 환경으로 줄이면, 팀원은 미래의 나, 동료는 AI 봇이 된다. 모든 매매는 채팅 히스토리에 남는다. 한 달 뒤에 “왜 그때 그 종목 샀지?” 했을 때 스크롤만 올리면 답이 거기 있다.
매매 일지를 따로 쓸 필요가 없다. 채팅이 곧 일지다.
Harness Engineering과의 연결
이 구조의 진짜 가치는 개별 컴포넌트가 좋아서가 아니다. 컴포넌트들을 잇는 방식이 단단해서다.
- 승인이 안 들어옴 → 60초 후 자동 거부
- API 호출 실패 → 재시도 + 알림
- 시스템 다운 → 마지막 상태부터 복구
- AI 제안이 이상함 → 사람이 거부 한 단어로 차단
각 단계가 끊어져도, 다음 단계가 이어받거나 안전하게 멈춘다.
에이전트 시스템을 만들다 보면 결국 깨닫게 된다. 진짜 어려운 건 개별 단계가 아니다. 단계와 단계 사이를 잇는 인프라다. 실패를 우회하고, 충돌에서 회복하고, 원래의 목표를 잃지 않는 구조. 나는 이걸 Harness Engineering이라 부른다.
CUI 기반 Event-Driven ChatOps는 그 Harness Engineering 철학을 매매 시스템에 구현한 한 가지 패턴이다.
정리
화려한 대시보드를 만들지 마라. 정교한 풀 오토를 만들지 마라. 모니터링 페이지에 인생을 갈아넣지 마라. (참고로 저는 모두 해봤습니다.)
대신,
- CUI: 채팅 한 줄로 시작하라
- Event-Driven: 폴링 말고 반응하라
- ChatOps: 운영도 채팅으로 가져와라
복잡하게 만들수록 무너지기 쉽다. 단순한 구조가 끝까지 살아남는다.
Vibe Coding 시대의 시스템은 거대한 빌딩이 아니라 작은 조립식 구조물이어야 한다. 채팅창 하나에 들어갈 정도로 작아야 한다. 한 단어 응답으로 동작할 정도로 직관적이어야 한다. 상상력으로 자연어 기반으로 주문 넣는 것 까지 완료
핵심 주장
이 포스트는 자동매매 시스템의 정답이 실시간 대시보드나 완전 무인화가 아니라, 다음 세 가지를 묶은 단순한 운영 구조라고 본다.
- CUI (Conversational UI) — 별도 GUI 대신 Discord 같은 메신저를 그대로 운영 UI로 사용
- Event-Driven — 폴링 대신 TradingView 웹훅, 가격 임계치, 스케줄러 같은 이벤트가 시스템을 깨움
- ChatOps — 제안, 승인, 실행, 결과 회신, 로그를 채팅 흐름 안에서 처리
핵심은 AI가 주문을 제안하고 사람은 마지막 승인/거부를 맡는 감독형 자동화(HITL) 다.
구조 메모
포스트가 제시한 직선형 흐름은 다음과 같다.
- 이벤트 발생
- AI 분석 (지표 계산, 컨텍스트 수집, 주문 제안 생성)
- 챗으로 카드 발송
- 사용자가 한 단어로 승인/거부
- 시스템이 주문 실행
- 결과를 같은 채널로 회신
이 구조에서 채팅 히스토리는 단순 알림창이 아니라 다음 역할을 동시에 맡는다.
- 운영 UI
- 감사 로그 / 매매 일지
- 모니터링 피드
- 모바일 접근 표면
왜 중요한가
이 글은 AI 트레이딩을 “더 똑똑한 모델” 문제가 아니라 더 견고한 실행 하네스 문제로 다시 본다.
- 풀 오토는 버그, 이상장, 책임 전가 문제에 취약하다.
- 반대로 풀 매뉴얼은 AI를 붙일 이유가 약하다.
- 따라서 AI는 탐색·필터링·근거 제시·속도를 담당하고, 사람은 예외 처리와 최종 책임을 담당하는 편이 현실적이다.
특히 다음 문장이 이 포스트의 요지다.
대시보드를 만들 시간에, 디스코드 봇 한 줄을 만든다.
채팅이 곧 일지다.
이 관점은 harness 페이지가 다루는 “개별 모델보다 단계 사이 연결 구조가 더 중요하다”는 논점과 직접 맞닿아 있다. 포스트 안의 Harness Engineering 표현도 같은 맥락이다. 승인 타임아웃, API 재시도, 장애 복구, 인간 차단 장치가 모두 연결부 설계 문제로 설명된다.
실무 해석
관점에서 이 포스트가 주는 실전 메시지는 다음에 가깝다.
- 자동 거래는 처음부터 별도 웹 대시보드로 시작할 필요가 없다.
- Upbit/KIS/TradingView/Telegram·Discord 조합처럼, 메신저를 운영면으로 삼는 가벼운 구조가 초기 실험에 더 유리하다.
- 완전 자율보다 approval gate가 있는 event-driven 파이프라인이 운영 리스크를 낮춘다.
- 결국 중요한 건 모델 성능보다도, 실패했을 때 멈추고 복구하는 하네스 설계다.