바이브 코딩, 주식 거래 에이전트 개발 — AI와의 협업과 신뢰

작성자:

얼마 전 세 번째 바이브 코딩 프로젝트를 완료했습니다.

첫 번째 프로젝트에서는 AI를 이용해서 얼마나 빠르게 앱을 만들 수 있는지 보았습니다. 아이의 학습 습관을 기록하는 웹앱을 만들면서, 구현 방향을 정하고 결과를 확인하는 시간이 훨씬 길고 중요하다는 사실을 알게 되었습니다. 두 번째 프로젝트인 주식 거래 관리 앱에서는 장기간 개발을 하면서 개발 속도와 맥락을 유지하려면 테스트와 각종 문서, handoff 관리, 주기적 리팩토링이 필요하다는 점을 경험할 수 있었습니다.

이번에는 Telegram 기반의 주식 거래 에이전트를 만들었습니다. Telegram으로 에이전트와 대화하며 계좌를 확인하고, 관심 종목을 관리하고, 거래 전략을 분석하고, 필요하면 주문까지 실행할 수 있는 도구입니다.

사실 “자동 매매”라는 개념 자체는 새롭지 않습니다. 하지만 증권사 API 사용법을 확인하고, Telegram 대화 흐름을 설계하고, 거래 전략을 구현하고, 주문 실행까지 이어지는 전체 과정을 AI와 함께 짧은 시간 안에 분석 및 설계하고 검증할 수 있다는 경험은 이전과 전혀 다른 종류의 일이었습니다.

이번 개발에서 가장 인상 깊었던 것은 AI의 속도보다 신중함이었습니다. 실제 돈을 다루는 일이다 보니 우려했던 것보다는 신중하게 접근한다는 사실이 놀라웠습니다. 다만, AI가 신중하게 제안한다는 사실과 시스템이 실제로 안전하다는 사실은 같지 않을 수 있습니다. 이번 글에서는 이러한 경험을 정리해 보았습니다.

목 차

초기 구조 설계

처음에는 막연하게 자동 매매 에이전트를 만들어 보자는 생각으로 시작했습니다. 하지만 AI와 함께 실제로 처음 진행한 일은 안전한 구조를 설계하는 일이었습니다.

기존에 만들어 둔 Kiwoom API 코드를 별도의 API 레이어로 분리했습니다. 실제로 계좌를 조회하고 거래내역을 읽는 역할은 이 레이어에 남기고, 그 위에 에이전트, 전략, Telegram UX, 저장소, 리포팅, 주문 흐름을 쌓아 올리는 구조로 잡았습니다. 전략이나 대화 로직이 API 레이어에 섞이지 않게 경계를 먼저 만든 것입니다.

그리고 첫 버전에서는 API가 잘 동작하는지 확인하는 Health check와 계좌 목록, 거래내역 조회와 같은 단순 조회 기능만 구현했습니다. 이 과정을 통해서 보안 관련 부분도 점검했습니다. API 응답에서 계좌번호는 마스킹하고, 관련 Key와 Secret code는 실행 시점에만 전달하며, Token cache가 응답에 나오지 않게 했습니다.

주문 API, 전략 판단, Telegram 연동은 모두 다음 단계로 미뤘습니다. 얼핏 보기에 예상보다 진행이 느린 것처럼 보일 수도 있지만, 모호하거나 잘못된 구현 때문에 실제 경제적인 손해가 생길 수 있기 때문에, 무엇이 어디까지 할 수 있는지를 분명히 정리하는 일이 무엇보다 중요했습니다.

기능 구현

이후 AI와 함께 대화 흐름, 전략, 백그라운드 실행 구조까지 시스템의 구조를 함께 설계했습니다.

Web Chat 구현 후 Telegram 연결

먼저, Telegram을 바로 붙여서 확인하는 대신 Web 기반의 Chat 인터페이스를 먼저 만들었습니다. Telegram 관련 봇 등록이나 Token 설정 없이 명령 흐름만을 빠르게 검증할 수 있었고, 명령 체계를 잡아가는 초기 단계에서 특히 유용했습니다. 또한, 로컬 환경에서 작업을 할 경우는 굳이 Telegram을 통하지 않아도 되기 때문에 사용성 면에서도 장점이 있었습니다. 이후 명령 체계를 안정화하고, Telegram과 연결을 진행했습니다.

이때 Telegram을 연결하는 과정에서는 Web Chat에서 만들어 둔 Command handler를 공유하게 함으로써 구현 비용을 절감할 수 있었고, 동시에 서로 다른 인터페이스에서 같은 기능을 같은 의미로 사용할 수 있게 되었습니다. 이전 개발 당시 화면마다 같은 기능이 미묘하게 다르게 동작하는 문제를 겪었기 때문에 이 부분을 좀 더 신경 써서 진행했습니다.

명령어 대신 대화로

Telegram 명령어를 설계하는 과정에서 초기에는 마치 CLI 명령처럼 명령어와 파라미터를 이용하도록 만들었습니다. 그런데 막상 모바일 화면에서 모든 명령어를 입력하는 것이 쉽지 않았습니다. 예를 들어 /history 005930 1w 같은 명령은 컴퓨터 앞에서는 자연스럽지만, 이동 중에 쓰는 메신저에서는 사용성이 무척 떨어집니다.

그래서 텍스트를 입력하면 종목 검색으로 처리하고, 검색 결과를 Telegram에서 제공하는 GUI 버튼으로 고르게 하였습니다. 또 관심 종목을 추가하고, 계좌 요약과 현황을 오가고, 전략 결과를 확인하는 흐름을 최대한 자연스럽게 대화 안에 넣었습니다. 계좌는 원문 계좌번호 대신 번호 버튼으로 선택하도록 해서 계좌번호가 직접 노출되는 횟수도 함께 줄였습니다.

진행 과정에서 사소하지만 해결이 좀 오래 걸린 문제도 있었습니다. Telegram은 글자 폭이 일정하지 않은 글꼴을 쓰기 때문에 한글과 숫자가 섞인 표의 너비가 계속 틀어졌습니다. 결국 HTML 표를 기본으로 하고, 표를 지원하지 않는 환경에서는 한글 표시 폭을 계산해 정렬하는 fallback을 두는 것으로 해결했습니다.

초기 화면
명령어 목록
매수 주문

추천과 주문의 분리

종목을 분석하고 매수/매도를 결정하는 전략도 단순히 하나의 추천 알고리즘을 붙이는 일이 아니었습니다. 평균회귀, 추세추종, 모멘텀처럼 서로 다른 관점의 신호를 제안하게 했습니다. 이 과정에서 각 알고리즘을 정확히 알지 못했고, 상당한 시간 동안 AI와 대화하면서 알고리즘을 공부하는 시간도 가졌습니다.

다만 매수/매도 추천이 곧바로 주문으로 연결되도록은 하지 않았습니다. 우선 추천 결과가 저장되게 하고, 주문 초안을 만들게 하되 별도의 승인 과정을 거치도록 했습니다.

사실 이 부분이 자동 매매의 핵심입니다. 다만 당분간 추천 알고리즘을 보완하고 상황을 지켜보면서 추후에 자동 매매 기능으로까지 확장할 예정입니다.

상태 기반 주문

특정 조건을 만족했을 때 시장가 기반으로 주문하도록 하는 기능도 추가했습니다. 단순하게 구현하면 Telegram 버튼을 누른 자리에서 가격을 계속 기다리는 동기식 방식을 생각할 수 있으나, 이는 사용자가 오래 기다릴 수 없고, 재시작이나 취소, 기타 거래 중 발생할 수 있는 오류도 다룰 수 없습니다. 그래서 감시 조건을 DB에 저장하고, 별도 Worker가 주기적으로 상태를 확인하도록 비동기식으로 구현했습니다.  

active, triggered, sent, cancelled, failed의 상태를 DB에 저장하고, 마지막 확인 가격과 시각, 전송 시각, 주문번호, 오류까지 기록으로 남겼습니다. 재시작해도 감시가 유지되도록 했고, 문제가 생기면 DB에서 무슨 일이 있었는지 확인할 수 있습니다. 비로소 대화 기능이 아니라 운영할 수 있는 시스템이 되었습니다.

AI의 신중함 vs 불완전함

이번 구현에서 특히 인상적이었던 점은, AI가 안전한 순서를 제안했다는 것입니다.

계좌를 읽는 API부터 만들고, Web Chat에서 명령 흐름을 확인하고, Telegram을 통해 실제 사용 흐름을 검증하고, 전략 추천과 실제 주문을 분리했습니다. 주문은 계좌 선택, 방식, 수량, 가격을 대화로 확인한 뒤 최종 확인 화면을 거쳐야 전송됩니다.

이런 순서는 단순히 조심스럽다는 말로 설명하기 어렵습니다. 추천, 주문 초안, 사용자 확인, 전송, 결과 기록을 하나의 AI 행동으로 묶지 않고, 각각을 다른 단계로 나눈 구조입니다. 신중함이 대화의 태도가 아니라 실제 권한과 흐름으로 들어간 셈입니다.

그렇다고 AI와의 협업이 아주 매끄러웠다는 뜻은 아닙니다. 이번에도 사람의 개입이 필요한 순간들이 있었습니다.

계좌 화면을 만들 때의 일입니다. 제가 원했던 흐름은 계좌 요약과 계좌 현황 두 화면을 오가는 것이었습니다. 그런데 구현 과정에서 그 사이에 계좌 메뉴라는 세 번째 화면이 생겼습니다. 코드로 보면 자연스러운 선택이었지만, 사용자가 계좌를 확인하는 흐름상 불필요한 단계였습니다. 결국 메뉴를 제거하고 계좌 버튼이 바로 요약으로 들어가게 다시 단순화했습니다. 아직 대화를 통해서 화면을 정리하는 중이었는데, AI가 의도와 달리 설명에서 구현으로 너무 빨리 넘어간 것입니다.

전략 화면에서도 비슷한 일이 있었습니다. 전략을 실행하면 결과 메시지에 전체보기 버튼이 붙는데, 처음 구현은 이 버튼이 과거 실행 이력까지 모두 보여줬습니다. 방금 실행한 결과를 보려고 누른 버튼이 옛 기록과 섞인 화면을 여니, 동작은 정상인데 의미가 틀린 상태였습니다. 실행마다 식별자를 부여하고 버튼이 그 실행의 스냅샷만 열도록 고쳐서 해결했습니다. 버튼 하나에도 “이 버튼을 통해 확인할 데이터 범위는 어디까지인가”라는 결정이 숨어 있었던 것입니다.

두 사례 모두 AI는 요청을 성실하게 수행했습니다. 코드도 동작했습니다. 다만 화면 사이의 관계, 버튼이 보존해야 할 맥락 같은 제품의 의미는 요구사항으로 명시되기 전까지 AI가 스스로 보장하지 않습니다. AI가 유창하게 좋은 결과를 반복하면 어느 순간 사람 동료처럼 느껴지고, “알아서 잘했겠지”라고 넘기게 됩니다. 이 착각이 어떻게 쌓이고 무엇을 무너뜨리는지는 지난 글 「바이브 코딩, 주식 거래 관리 앱 개발 ④ — “바이브”의 한계」에서 자세히 다뤘습니다. 이번 프로젝트에서도 비슷한 경험을 할 수 있었습니다.

신뢰를 만드는 방법

그래서 이번 프로젝트를 통해, AI와 협업 기준이 조금 더 분명해졌습니다.

첫째, 위험한 기능의 Do와 Don’t를 구현 전에 문서로 고정해야 합니다.
실제 계좌 주문은 반드시 승인을 받아야 한다는 원칙은 대화에서 한 번 말하는 것으로 충분하지 않습니다. 설계 문서, 권한 검사, 테스트, 운영 절차에 모두 남아 있어야 합니다. 문서에 있는 금지는 세션이 바뀌어도 이어질 수 있지만, 대화 속의 금지는 다음 세션에 존재하지 않게 됩니다.

둘째, 실행을 여러 단계로 나눠야 합니다.
AI의 추천, 주문 초안, 사용자 확인, 실제 전송, 결과 기록은 서로 다른 일입니다. 이 단계를 한 번에 합치면 편해 보이지만, 문제가 생겼을 때 어디서 멈추고 무엇을 확인해야 하는지 알 수 없습니다.

셋째, 대화 밖에 상태를 남겨야 합니다.
AI의 세션과 Telegram의 callback은 오래 지속되는 업무를 책임질 수 없습니다. Worker가 할 일은 DB에 남기고, 재시작/취소/실패를 모두 상태로 관리해야 합니다. 인수인계서를 포함한 각종 문서도 같은 이유로 필요합니다. AI가 기억하지 못하는 것을 대신 기억하는 장치이면서, 사람이 AI를 너무 사람처럼 믿지 않게 하는 장치입니다.

넷째, 화면과 용어의 모델을 구현 전에 합의해야 합니다.
계좌 메뉴와 전체보기의 시행착오는 둘 다 이 문제와 관련이 있습니다. 버튼 하나가 가리키는 다음 화면과 그 화면의 데이터 범위를 먼저 정하고, 요약, 현황, 전체보기 같은 용어를 화면 전체에서 일관되게 써야 합니다. 코드보다 용어를 먼저 정리하는 것이 결국 더 빠른 길이었습니다.

맺음말

AI는 API 사용법을 찾아주고, 구조를 제안하고, Telegram 대화 화면을 만들고, 전략과 Worker를 구현해 줄 수 있습니다. 이 모든 일을 단시간 내에 해결할 수 있다는 사실은 분명 놀랍습니다. 그리고 이번 프로젝트에서 AI는 스스로 안전한 순서까지 제안했습니다.

하지만 신뢰는 AI가 조심스럽게 말해준다고 해서 생기는 것이 아닙니다. 사람이 그 제안을 판단하고, 문서와 검증에 반영할 때 생깁니다. 신중한 ‘대화’는 세션이 끝나면 사라지지만, 문서와 검증은 지속되기 때문입니다.

AI와의 협업은 신중한 답변을 듣는 일이 아닙니다. 그 신중함을 시스템으로 설계하는 일에서 시작됩니다.

ChulJoo Kim (김철주)

※ 참고문헌

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기