왜 손으로 쓰는 투자 일지는 1년을 못 버티나
매매할 때마다 수기로 남기려다 세 달쯤에 포기한 경험이 있을 거다. 투자 일지 자동으로 쓰는법을 검색하는 순간은 대개 그 직후다. 장이 끝나고 매매 내역 앱을 열었다가, “내일 몰아서 쓰지” 하다가 결국 안 쓰는 날이 쌓인다.
수기 일지가 실패하는 세 가지 이유
내가 여러 번 실패하면서 찾은 패턴이 있다. 첫째는 매매 직후가 아니라 저녁에 쓰려니 체결가·수량을 다시 확인해야 한다. 둘째는 손익 계산이 손이다. 실현손익을 내 방식으로 계산하면 증권사 앱 숫자와 자꾸 어긋나서, 어느 쪽이 맞는지 확인하다 일지 쓰기 자체를 관둔다. 셋째는 회고다. 기록은 그럭저럭 남아도 한 달 치를 뒤져 요약하는 작업이 사람을 지치게 한다.
기록이 아니라 집계와 회고가 실패 지점이었다.
내가 자동화로 전환한 계기
나는 혼자서 AI 자동화로 SaaS 여러 개를 굴리는 1인 빌더다. 지금 무인 크론이 63개 돌고 있고, 작업 폴더가 183개, git 저장소가 90개 쌓여 있다. 이 정도 규모가 되면 사람 손으로 뭔가를 기록하는 방식은 구조적으로 못 버틴다. 콘텐츠 발행도 처음엔 손으로 올리다 지금은 검사 통과분만 자동 공개된다. 투자 일지도 똑같은 문제라고 판단해서, 발행 파이프라인과 같은 구조로 갈아엎었다.
투자 일지 자동화, 뭘부터 세팅해야 하나
도구를 고르기 전에 내 자동화 레벨이 어디쯤인지부터 아는 게 빠르다.
0~3단계 자동화 레벨 진단
0단계는 전부 수기. 1단계는 매매 내역 엑셀을 증권사에서 수동으로 내려받아 붙여넣기. 2단계는 내려받기까진 사람이 하되 집계·손익 정리는 수식이나 스크립트가 처리. 3단계는 수집부터 회고 초안까지 주기적으로 기계가 하고 사람은 검수만 한다. 대부분 1단계에서 막혀 있는데, 1단계의 문제는 귀찮음이 아니라 “내려받기를 깜빡하면 그날 데이터가 구멍 난다”는 취약성이다.
데이터 원천을 하나로 정하는 원칙
SaaS를 만들면서 몸에 밴 원칙이 하나 있다. 원천 데이터는 단일 소스로 정하고 나머지는 전부 파생시킨다. 투자 일지에 대입하면 원천은 증권사 거래 데이터다. 일지·손익·회고는 전부 그 위에 얹히는 뷰일 뿐이다. 내가 예전에 수기 계산과 증권사 숫자가 어긋났던 것도, 원천이 둘이었기 때문이다. 원천을 하나로 정하면 “어느 숫자가 진짜냐”는 질문 자체가 사라진다.
세팅에 실제로 걸리는 시간
솔직히 말하면 처음 세팅은 반나절 걸린다. API 키 발급, 스프레드시트 권한, 크론 등록을 순서대로 밟아야 해서다. 다만 이건 일회용 비용이고, 이후 주간 유지는 점검 수준으로 줄어든다. 세팅 시간 아까워서 1단계에 머무는 게 진짜 손해다.
매매 내역을 수동으로 받지 않고 자동으로 가져오는 법
증권사별 자동 연동 가능 여부 비교
국내 증권사는 Open API를 공개하는 곳과 아닌 곳이 갈린다. 한국투자증권은 KIS Developers에서 실전계좌 API 키를 발급받아 당일 체결내역·잔고를 조회할 수 있다. 키움은 영웅문 Open API+가 있는데 조회용 모듈을 로컬에 깔아야 한다. 토스증권·슬로우메이저 등 일부는 공식 개인용 조회 API를 제공하지 않는다. 그런 곳은 다음 절의 차선책으로 간다.
스프레드시트·크론으로 주기 수집 설계
내 블로그 발행은 cron이 주기적으로 초안을 만들고 검사를 통과한 글만 공개하는 구조다. 매매 수집도 같은 뼈대다. 매일 장 마감 뒤 한 번, 조회 API를 호출해 어제 분까지 스프레드시트에 붙이고, 이미 들어와 있는 주문번호면 건너뛴다. 중복 방지가 핵심인데, 이건 아래에서 다시 다룬다.
가장 단순한 형태는 GOOGLEFINANCE로 시세를 당기는 것인데, 이건 시세용이지 내 체결 데이터가 아니다. 체결까지 자동으로 가져오려면 API 호출 스크립트를 cron에 올리는 수밖에 없다.
# 매일 17시에 체결내역 동기화 (이미 수집한 주문번호는 skip)
0 17 * * 1-5 /usr/bin/python3 /home/aileego/sync/kis_trades.py --dup-check order_no >> /var/log/trades.log 2>&1
자동 수집이 안 될 때의 차선책
API가 없는 증권사라면 매일 정해진 시간에 내려받기 자체를 자동화하는 우회로가 있다. 다만 이 방식은 증권사 화면이 바뀌면 깨지고, 로그인 2차 인증이 걸리면 그날 수집이 실패한다. 차선책은 어디까지나 차선이다. 실패하면 어떻게 알림을 받을지까지 같이 세팅해야 진짜 자동화다.
실현손익·환손익, 왜 내 계산과 다르게 나오나
증권사가 손익을 계산하는 산식
실현손익이란 매도 금액에서 매수 금액과 제비용을 뺀, 증권사 산식으로 확정된 손익이다. 내 계산과 어긋나는 첫 지점이 매수 단가 처리다. 분할 매수한 종목을 일부 매도하면 증권사는 보통 이동평균이나 FIFO 방식으로 어떤 매수분을 파는지 정한다. 내가 “맨 마지막에 산 걸 팔았다”고 계산하면 산식이 다른 이상 숫자는 어긋날 수밖에 없다. 내 계산이 틀린 게 아니라 기준이 다른 거다.
환율 적용 시점이 만드는 차이
환손익이 말썽인 이유는 적용 환율이 시점마다 다르다. 매수 당일 환율로 잡느냐, 매도 당일 환율이냐, 정산 환율이냐에 따라 원화 손익이 달라진다. 같은 종목을 같은 가격에 사고 팔아도 통화 손익이 플러스일 수 있다. 증권사 앱의 산식 설명 페이지를 한 번 읽어두면, 이후 대사할 때 어긋난 원인을 짚는 속도가 확 달라진다.
제비용·세금 포함 여부 확인법
증권사 손익 화면은 수수료와 거래세 포함 여부를 안내 문구로 적어둔다. “수수료·제세금 포함” 같은 문구가 어디까지 감싸는지 확인하지 않고 내 계산과 비교하면 영영 맞춰지지 않는다. 나는 원천을 증권사로 정한 뒤로는 내 손익을 따로 계산하지 않는다. 증권사 숫자를 그대로 가져오고, 계산 로직은 증권사 산식을 따르는 걸로 통일했다.
자동 기록이 사실과 다르게 저장되는 리스크와 검증법
자동화가 실패하는 대표적인 네 가지 상황
배치 지연, 중복 집계, 수정 거래 반영 실패, 권한 만료. 이 넷이면 열에 아홉이다. 실제로 겪은 건 배치 지연이었다. 장 마감 직후 조회를 돌렸는데 당일 체결분이 아직 조회 창구에 안 올라와 있어서, 그날 매매가 통째로 일지에서 빠졌다. 스크립트는 성공으로 종료했으니 로그에는 문제가 없었다. 이게 제일 무섭다. 에러 없이 조용히 틀린다.
사실 검증 3단계 체크리스트
그 뒤로 대사 루틴을 만들었다.
- 주 단위로 증권사 앱의 당주 체결 건수와 시트 행 수를 맞춘다.
- 월 단위로 앱의 월간 실현손익과 시트 합계를 맞춘다. 어긋나면 환율·제비용·FIFO 순서로 원인을 좁힌다.
- 수집 스크립트가 비정상 종료하면 알림이 오게 해서, 조용한 실패를 막는다.
자동화 후에도 사람이 볼 지점
내 블로그도 자동 검사를 통과한 글만 공개되지만, 걸린 초안은 사람이 검토한다. 투자 데이터도 구조가 같다. 숫자 집계는 기계 몫, “이 숫자가 진짜 맞나”를 눈으로 찍는 대사는 사람 몫으로 남긴다. 그래서 주간 10분 점검을 아래 루틴에 넣어뒀다.
월간 회고까지 자동으로 만드는 루틴
주간 10분 점검 루틴
주말에 커피 한 잔 들고 세 가지만 본다. 이번 주 체결 건수 맞는지, 미리 정해둔 대사 항목 이상 없는지, 알림 온 게 있었는지. 여기서 어긋나는 걸 발견하면 그 자리에서 원인을 좁힌다. 미루면 다음 달에 세 배 고생한다.
월간 30분 회고 자동 생성 흐름
월간 회고 파이프라인은 블로그 발행 파이프라인을 그대로 재활용했다. 월 1회 크론이 월간 거래 요약(종목별 손익, 잦은 매매 패턴, 미국장 통화 손익)을 모아 회고 초안을 만든다. 이때 프롬프트는 사실만 다루게 좁혀둔다.
아래 월간 거래 요약 표만 근거로 회고 초안을 써라. 표에 없는 해석·감정·전망은 한 줄도 쓰지 마라. 종목별 손익, 매매 빈도, 최대 손실 종목 순서로 정리하라.
감정이나 전망을 기계가 지어내면 그 순간부터 회고가 소설이 된다. 근거 없는 문장을 봉쇄하는 프롬프트 설계가 회고 자동화의 절반이다.
사람이 써야 할 한 문단
매매 이유와 그때 심리는 사람이 쓴다. “급등 보고 물탔는데 흔들렸다” 같은 문장은 데이터에서 나오지 않는다. 자동 생성 요약 뒤에 빈 칸 하나를 남겨두고 거기만 손으로 채우는 구조다. 자동화 몫과 사람 몫의 경계선을 안 지키면, 회고가 점점 텅 비고 일지는 다시 죽는다.
정리: 오늘 세팅하고 주말에 끝내는 행동 순서
첫 주에 할 일 3가지
첫째 날, 쓰는 증권사가 조회 API를 주는지 확인하고 키를 발급받는다. 둘째 날, 시트를 만들고 어제·그제 체결내역을 한 번 수동으로 붙여 구조를 잡는다. 주말에 조회 스크립트를 크론에 올리고, 월요일 장 마감 뒤 자동으로 쌓이는지 확인한다. 이 순서면 첫 주 안에 3단계 자동화에 들어간다.
자동화하지 말아야 할 것
매매 판단과 매매 이유 기록은 자동화하지 않는다. 나도 콘텐츠 파이프라인을 돌리면서 배웠는데, 자동 검사가 잘못 잡는 경우가 있다. 실제로 중복 검사 가드를 검증해 보니 발행된 글 35편끼리 비교했을 때 595쌍 중 73쌍을 중복이라고 잘못 판정했다. 도구는 검증 대상이지 신앙이 아니다. 투자 일지 자동화도 같다. 원천은 증권사, 집계는 기계, 대사와 회고의 마지막 한 문단은 사람. 이 경계선만 지키면 일지는 1년을 버틴다.
근거로 삼은 문서
이 글은 문체·사실성 두 가지 자동 검사를 통과했습니다. 초안을 쓰는 건 제가 만든 AI 파이프라인이고, 검사에 걸리면 공개하지 않습니다. 만드는 과정
투자 일지를 자동으로 쓰려면 뭐부터 세팅해야 하나요?
먼저 내 자동화 레벨(0~3단계)이 어디쯤인지 진단하는 게 빠르다. 대부분 1단계, 즉 증권사에서 매매 내역을 수동으로 내려받는 단계에서 막혀 있는데, 깜빡하면 그날 데이터가 구멍 난다는 게 구조적 약점이다. 증권사 Open API(한국투자증권 KIS Developers, 키움 영웅문 Open API+)로 체결내역 조회를 스크립트·크론으로 주기 수집하면 수집부터 자동화된다. 초기 세팅은 반나절 정도 걸리지만 일회용 비용이다.
실현손익이 내 계산과 증권사 앱 숫자가 다르게 나오는 이유는?
산식이 다르기 때문이다. 분할 매수한 종목을 일부 매도하면 증권사는 보통 이동평균이나 FIFO 방식으로 매수분을 정하는데, 내가 임의 기준으로 계산하면 숫자가 어길 수밖에 없다. 해외 종목은 적용 환율 시점(매수일·매도일·정산 환율)에 따라서도 원화 손익이 달라진다. 증권사의 산식 설명 페이지를 한 번 읽어두면 대사할 때 원인 짚는 속도가 확 빨라진다.
증권사가 API를 안 제공하면 투자 일지 자동화는 불가능인가요?
불가능하진 않지만 차선책이다. 매일 정해진 시간에 매매 내역 내려받기 자체를 자동화하는 우회로가 있는데, 증권사 화면이 바뀌면 깨지고 2차 인증이 걸리면 그날 수집이 실패한다. 실패 시 알림을 받을 장치까지 같이 세팅해야 진짜 자동화다. 가능하면 API를 제공하는 증권사로 원천을 옮기는 게 구조적으로 안정적이다.
GOOGLEFINANCE로 투자 일지를 자동화할 수 있나요?
GOOGLEFINANCE는 시세를 당겨오는 용도일 뿐, 내 체결 데이터를 가져오지는 못한다. 체결가·수량·주문번호까지 자동 수집하려면 증권사 조회 API를 호출하는 스크립트를 크론에 등록하는 수밖에 없다. 중복 방지를 위해 이미 수집한 주문번호는 건너뛰는 로직을 꼭 넣어야 한다.
손으로 쓰는 투자 일지가 실패하는 가장 큰 이유는 뭔가요?
기록 자체보다 집계와 회고에서 무너진다. 매매 직후가 아니라 저녁에 쓰려다 체결가·수량을 다시 확인하는 게 귀찮아지고, 실현손익 계산이 증권사 숫자와 어긋나면 확인하다 일지 자체를 관두게 된다. 한 달 치를 뒤져 회고하는 작업도 사람을 지치게 한다. 결국 원천 데이터를 하나로 정하고 기계가 수집·집계하게 만드는 게 해답이다.
