블로그

매일 복붙하는 그 작업, 시트가 알아서 합니다

구글 스프레드시트 자동화를 검색하는 순간 대부분은 이런 상황일 겁니다. 아침마다 폼 응답을 열어 복사해서 정리하고, 다른 시트에서 숫자를 받아다 집계표를 갱신하고, 그걸 보고서 양식에 붙여 넣는다. 코딩을 배울 시간은 없고, 그렇다고 이 반복을 계속할 수도 없다. 그 사이 어딘가에 있을 겁니다.

나는 혼자서 콘텐츠 생성과 발행을 무인으로 돌리는 입장이라 시트뿐 아니라 서버의 예약 작업까지 cron 63개를 직접 관리한다. 그래서 아는 것이다. 자동화는 어렵지 않은데, ‘망가졌을 때 조용히 망가진다’는 게 진짜 문제라는 걸. 이 글은 함수 나열이 아니라 실패했을 때 어떻게 붙잡는지까지 쓴다.

개발을 못 해도 시작할 수 있을까?

된다. 스프레드시트 자동화란 반복되는 데이터 입력·정리·집계를 사람 대신 시트 함수와 예약 실행이 처리하도록 만드는 작업이다. 구글 시트는 함수만으로도 상당 부분 자동화되고, 거기서 한 발 더 가면 ‘매크로 녹화’가 있고, 그다음이 Apps Script라는 코드다. 이 순서대로 가면 코드를 직접 짜는 순간은 생각보다 늦게 온다. 나도 처음엔 녹화 매크로에서 시작했다.

오늘부터 자동화 가능한 작업 vs 아닌 작업 구분법

구분 기준은 하나다. “입력이 정해진 형태로 들어오고, 출력 규칙이 사람이 문장으로 설명할 수 있는가?” 예컨대 ‘폼 응답이 쌓이면 미결제 건만 뽑아 별도 탭으로 옮긴다’는 규칙이라 자동화된다. 반면 ‘이번 주 분위기에 맞게 홍보 문구를 손봐라’처럼 판단이 매번 달라지는 일은 사람 몫으로 남긴다. 경계선 애매하면 일주일 치 작업을 수기로 하면서 내 판단을 문장으로 적어보라. 문장이 안 나오는 작업은 아직 자동화 대상이 아니다.

시작 전 5분 점검: 이 설정 놓치면 데이터가 망가집니다

자동화 사고의 대부분은 화려한 기술 실패가 아니라 설정 누락에서 나온다. 실제로 나는 무인 배치가 권한 만료로 조용히 멈춘 걸 한참 뒤에야 알았다. 에러도 없다. 그냥 안 돌았을 뿐. 그 뒤로는 뭘 만들든 아래 다섯 가지를 먼저 확인하고 시작한다.

1. 큰 배치를 돌리기 전에 파일 > 사본 만들기로 백업본을 떠 둔다.
2. 원본 데이터 시트와 자동화 결과 시트를 파일 단위로, 최소 탭 단위로 분리한다.
3. 자동화 계정의 접근 권한이 ‘편집자’ 이상인지, 만료일이 없는지 확인한다.
4. 자동화가 결과를 ‘덮어쓰는지’, ‘행을 추가하는지’를 정해 두고 기록해 둔다.
5. 시트 파일 설정의 시간대를 한국 표준시로 맞춘다.

자동화 전 반드시 백업해 두기

구글 시트는 버전 기록이 기본 켜져 있지만, Apps Script나 외부 도구가 대량 수정을 하면 최근 상태 위에 계속 덮인다. 복구 지점이 필요하면 큰 배치를 돌리기 직전에 파일을 복제해 두는 습관이 가장 확실하다. 나는 원본을 읽기 전용으로 두고, 자동화는 사본에만 쓰게 만든다. 이 구조로 가면 스크립트가 아무리 잘못돼도 원본은 남는다.

원본 시트와 자동화 시트를 분리하는 구조 설계

흔한 사고가 ‘사람이 보는 집계표’와 ‘기계가 쓰는 원천 데이터’가 같은 탭에 섞이는 거다. 정렬 한 번 잘못 누르면 함수가 참조하던 행이 전부 어긋난다. 구조는 단순하게. 데이터가 쌓이는 탭(사람 손 금지), 함수가 읽어 정리하는 탭, 사람이 보는 리포트 탭. 이렇게 세 겹으로 나누면 중간이 망가져도 원천은 살아 있다.

권한·공유 설정에서 자주 터지는 함정

Apps Script가 다른 스프레드시트를 읽게 하면 권한 승인 팝업이 뜨는데, 이걸 브라우저에서 한 번 승인했다고 끝이 아니다. 계정 비밀번호를 바꾸거나, 소유자가 문서를 이동하거나, 승인 토큰이 만료되면 조용히 끊긴다. 워크스페이스 관리자가 앱 권한을 정리하는 바람에 끊기는 경우도 봤다. 그래서 나는 권한을 링크가 아니라 특정 계정 기준으로 부여하고, 스크립트 소유 계정을 자동화 전용 하나로 고정해서 쓴다.

폼 응답·외부 데이터 자동으로 쌓기: 세팅 순서대로 따라하기

데이터가 자동으로 쌓이는 구조를 만들면 그다음 정리·집계는 시트 함수의 몫이 된다. 내 운영 시트도 같은 구조다. 폼과 외부 도구가 쓰는 탭, 그걸 읽어 상태를 정리하는 탭, 리포트 탭. 스크린샷 대신 구조로 보면 이렇다.

시트 구조 템플릿: [raw] 폼 응답 원본 (사람 금지 구역) / [clean] QUERY 함수로 상태별 분류 / [report] 월별 집계 + 조건부 서식 / [log] 자동화 실행 기록 남기는 탭

구글폼 → 시트 연결 후 응답 자동 정리 구조 만들기

구글폼의 ‘스프레드시트에 연결’을 누르면 응답 탭이 자동 생긴다. 여기서 바로 원본을 고치려 들면 안 된다. 응답 탭 옆에 탭을 하나 만들고 QUERY로 끌어오는 식이다. 예컨대 =QUERY('폼 응답 1'!A:H, "select B,C,E where E = '미결제'") 같은 형태로 쓰면 미결제 건만 별도 탭에 실시간으로 뜬다. 이러면 폼이 몇 백 건 쌓여도 정리 탭은 늘 같은 모양을 유지한다.

IMPORTRANGE로 다른 시트 데이터 가져오기와 주의점

다른 파일의 데이터는 IMPORTRANGE로 가져온다. 첫 실행 때 권한 승인을 한 번 눌러야 하는데 이걸 놓치고 ‘왜 안 되지’를 오래 하는 경우가 많다. 주의점은 로딩이다. 참조 범위가 크면 화면에 뜨는 데 시간이 걸리고, 그 사이 다른 함수가 빈 값을 참조해 오류를 낸다. 그래서 나는 IMPORTRANGE로 통째로 전용 탭에 받아 놓고, 다른 함수는 그 탭만 바라보게 나눠 쓴다. 원본이 덜 흔들린다.

외부 데이터(API·다른 도구)를 쌓는 최소 구성

외부 데이터가 필요하면 Apps Script로 받아서 쌓는 게 최소 구성이다. URL Fetch 서비스로 API를 부르고, 결과를 raw 탭에 행으로 추가한다. 실행 기록은 log 탭에 남긴다. 비용 관련해서 하나만 적자면, 나는 헤드리스로 LLM을 부를 때 기본 설정이 1회 $0.78이었던 걸 모델과 작업 디렉터리를 지정하고 불필요한 도구를 떼는 방식으로 $0.028까지 줄인 적이 있다. 외부 API를 쓰는 자동화는 이렇게 호출 단가와 횟수를 먼저 따져보고 붙여야 한다. 생략하면 청구서로 배우게 된다.

기본형은 이렇다. 마지막 행 다음에 붙이는 구조라 덮어쓰기 사고가 없다.

function appendOrder() {
  const sh = SpreadsheetApp.getActive().getSheetByName('raw');
  const row = [new Date(), '주문', '자동 수집'];
  sh.appendRow(row);
  SpreadsheetApp.getActive().getSheetByName('log')
    .appendRow([new Date(), 'appendOrder', 'ok']);
}

트리거 완전 정리: 시간·폼 제출·수정 시, 언제 뭘 써야 하나

자동화를 ‘걸어두는’ 장치가 트리거다. 어떤 트리거를 쓰느냐에 따라 실패 양상이 달라지니, 선택 기준부터 정리한다. 무인으로 돌리는 입장에서 내가 실제로 쓰는 판단 표다.

각 트리거의 함정: 중복 실행, 실행 한도, 타임존

시간 기반 트리거는 ‘매일 오전 6시’로 지정해도 6시 정각이 아니라 그 시간대 안에서 구글이 정한 시점에 돈다. 나는 cron 63개를 무인으로 돌리는데, 시간 지정을 하는 순간부터 ‘정시 보장이 없다’를 전제하고 설계한다. 중복 실행도 조심한다. 사람이 셀을 빠르게 여러 번 고치면 onEdit가 그 횟수만큼 발생한다. 그래서 스크립트 첫머리에 ‘같은 행을 최근에 처리했으면 건너뛰기’ 확인을 넣는다. 타임존은 파일 설정과 스크립트 설정이 따로 놀 때가 있다. Apps Script 프로젝트 설정에서 Asia/Seoul로 맞춰두지 않으면 날짜 경계가 어긋나서 새벽 배치가 전날 데이터를 가져간다.

매크로 녹화에서 Apps Script 트리거로 넘어가는 시점

매크로 녹화로 시작해도 된다. 녹화하면 내부적으로 Apps Script가 만들어지니까, 나중에 확장하기도 쉽다. 넘어갈 시점의 신호는 두 가지다. 녹화된 매크로를 조건에 따라 다르게 굴러가게 하고 싶어질 때, 그리고 자동 실행을 걸고 싶을 때다. 매크로는 트리거에 조건 분기 얹기가 어색하니, 그때 코드를 열어 녹화본을 고치는 식으로 넘어가면 된다.

자동화가 실패했을 때: 복구 5단계와 재발 방지 세팅

여기가 이 글의 심장이다. 자동화 실패는 대부분 소리 없이 온다. 나는 이 블로그의 글도 문체·사실성 자동 검사를 통과한 것만 공개하는 구조로 운영하는데, 검사를 통과 못 한 초안은 사람이 검토한다. 이 원칙을 만든 이유가 바로 무음 실패 때문이었다. 자동화가 잘못된 걸 스스로 알려주는 경우는 생각보다 드물다.

데이터가 꼬였을 때 복구 순서 (버전 기록 활용)

복구는 서두르면 망가진다. 순서를 지켜라. 첫 단계로 트리거를 일시 중지한다. 이걸 안 하고 고치는 사이 배치가 또 돌아서 꼬임이 두 배가 된다. 다음은 raw 탭이 온전한지 확인한다. 원천이 살아 있으면 정리 탭은 함수 다시 당기는 걸로 끝난다. raw까지 손댔다면 파일 > 버전 기록에서 망가지기 직전 시점으로 복사본을 만든다. 원본에 바로 복원하지 말고 사본에서 검증부터. 검증이 끝나면 복구본을 새 원본으로 삼고, 마지막으로 log 탭에 뭐가 어긋났는지 한 줄 적어둔다. 이 기록이 다음 사고를 줄인다.

무음 실패를 잡는 실패 알림 세팅법

실패 알림은 try-catch로 에러를 잡아 본인 메일이나 슬랙으로 쏘는 게 최소 구성이다. 성공 알림도 하나 남겨두라는 게 내 방식이다. ‘오늘 6시 배치 완료’라는 한 줄이 안 오면 그 자체가 실패 신호다. 에러만 알려주는 구조는 ‘에러 없이 안 돈 경우’를 못 잡는다. 권한 만료로 멈춘 배치가 정확히 그 경우였다. 실패 처리 코드는 짧게 이런 모양이다.

function dailyJob() {
  try {
    // 본문 처리
    MailApp.sendEmail('[email protected]', '배치 완료', 'ok');
  } catch (e) {
    MailApp.sendEmail('[email protected]', '배치 실패', e.message);
  }
}

절대 자동화하면 안 되는 작업의 경계선

경계선을 세 개 둔다. 원본 삭제·파기가 결과인 작업은 자동화하지 않는다. 돈이 실제로 움직이는 결제·환불 실행은 사람 확인 없이 돌리지 않는다. 그리고 ‘판단 기준을 글로 못 쓰겠다’는 작업은 애초에 자동화 대상이 아니다. 이 세 개를 넘는 자동화는 절약해 주는 시간보다 되돌리는 데 드는 시간이 커진다.

정리: 1인 운영 루틴과 오늘 당장 시작하는 3단계

이 블로그는 한 달 반 동안 43편을 발행했는데, 초안 생성에서 공개까지 기계가 하고 사람이 검수하는 구조다. 그걸 가능하게 한 건 화려한 기술이 아니라 점검 루틴이다. 자동화는 한 번 만드는 게 아니라 매주 쳐다보는 시스템이다.

주문·문의 집계 자동화 사례와 매주 월요일 5분 점검

1인 사업자에게 시트 자동화의 최대 수혜는 집계 시간이 아니라 ‘깜빡함’이 사라지는 거다. 주문 폼, 문의 폼, 재고 시트가 각자 쌓이고 리포트 탭이 알아서 갱신되면 아침에 확인 한 번으로 끝난다. 나의 월요일 루틴은 이렇다. 배치 성공 알림이 주간 분량대로 쌓였는지 본다. log 탭에서 지난주 에러 한 줄을 훑는다. 마지막으로 raw 탭 맨 아래행의 타임스탬프가 최근인지 확인한다. 셋 다 이상 없으면 점검 끝이다. 이 루틴으로 잡은 사고가 더러 있다. 그중 반은 권한 문제였다.

자동화 확장 순서: 시트 → 폼 → 알림 → 외부 도구

확장은 순서가 있다. 시트 함수로 정리를 붙잡고, 폼으로 입력을 규격화하고, 알림으로 무음 실패를 막은 다음에 외부 도구를 붙인다. 이 순서를 뒤집으면 외부 도구가 고장 났을 때 원인을 특정할 수가 없다. 나도 초반에 순서를 무시했다가 어디서부터 망가졌는지 몰라 전부 끊고 다시 쌓은 적이 있다.

오늘 당장 시작하는 3단계 행동 플랜

1단계는 복붙 작업 하나를 골라 원본 시트와 자동화 시트를 분리하는 것부터다. 2단계는 트리거 딱 하나만 걸고 사흘이 아니라 며칠간 지켜보는 것이다. 실행 기록 탭을 같이 만들어두면 지켜보는 게 훨씬 쉬워진다. 3단계는 성공·실패 알림을 붙이는 것. 여기까지 오면 진짜 무인 운영이다. 관련해서 Apps Script 타임존 설정 실패기, 무코드 자동화의 한계와 넘어설 시점, 무음 실패를 잡는 점검 루틴 글도 함께 보면 좋다.

자주 묻는 질문

코딩을 전혀 몰라도 자동화할 수 있나요? 시트 함수와 매크로 녹화 수준이면 코딩 없이 충분합니다. Apps Script는 필요해지면 그때 녹화본을 조금씩 고치는 방식으로 시작하면 됩니다.

무료로 가능한가요? 요금은 언제 드나요? 구글 시트의 함수·트리거·메일 알림은 무료 구간에서 돌아갑니다. 외부 API를 매시간 부르는 구조로 가면 그때부터 호출 비용을 따져야 합니다. 내 경우 호출 단가를 27배 줄인 적이 있으니 설정을 먼저 점검하세요.

트리거가 갑자기 멈추면 어떻게 확인하나요? Apps Script의 ‘내 실행’ 로그부터 보세요. 로그에 실행 기록 자체가 없으면 권한 만료나 트리거 삭제를 의심합니다. 성공 알림이 안 오는 경우도 같은 방향으로 확인하면 됩니다.

왜 손으로 쓰는 투자 일지는 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단계 체크리스트

그 뒤로 대사 루틴을 만들었다.

1. 주 단위로 증권사 앱의 당주 체결 건수와 시트 행 수를 맞춘다.
2. 월 단위로 앱의 월간 실현손익과 시트 합계를 맞춘다. 어긋나면 환율·제비용·FIFO 순서로 원인을 좁힌다.
3. 수집 스크립트가 비정상 종료하면 알림이 오게 해서, 조용한 실패를 막는다.

자동화 후에도 사람이 볼 지점

내 블로그도 자동 검사를 통과한 글만 공개되지만, 걸린 초안은 사람이 검토한다. 투자 데이터도 구조가 같다. 숫자 집계는 기계 몫, “이 숫자가 진짜 맞나”를 눈으로 찍는 대사는 사람 몫으로 남긴다. 그래서 주간 10분 점검을 아래 루틴에 넣어뒀다.

월간 회고까지 자동으로 만드는 루틴

주간 10분 점검 루틴

주말에 커피 한 잔 들고 세 가지만 본다. 이번 주 체결 건수 맞는지, 미리 정해둔 대사 항목 이상 없는지, 알림 온 게 있었는지. 여기서 어긋나는 걸 발견하면 그 자리에서 원인을 좁힌다. 미루면 다음 달에 세 배 고생한다.

월간 30분 회고 자동 생성 흐름

월간 회고 파이프라인은 블로그 발행 파이프라인을 그대로 재활용했다. 월 1회 크론이 월간 거래 요약(종목별 손익, 잦은 매매 패턴, 미국장 통화 손익)을 모아 회고 초안을 만든다. 이때 프롬프트는 사실만 다루게 좁혀둔다.

아래 월간 거래 요약 표만 근거로 회고 초안을 써라. 표에 없는 해석·감정·전망은 한 줄도 쓰지 마라. 종목별 손익, 매매 빈도, 최대 손실 종목 순서로 정리하라.

감정이나 전망을 기계가 지어내면 그 순간부터 회고가 소설이 된다. 근거 없는 문장을 봉쇄하는 프롬프트 설계가 회고 자동화의 절반이다.

사람이 써야 할 한 문단

매매 이유와 그때 심리는 사람이 쓴다. “급등 보고 물탔는데 흔들렸다” 같은 문장은 데이터에서 나오지 않는다. 자동 생성 요약 뒤에 빈 칸 하나를 남겨두고 거기만 손으로 채우는 구조다. 자동화 몫과 사람 몫의 경계선을 안 지키면, 회고가 점점 텅 비고 일지는 다시 죽는다.

정리: 오늘 세팅하고 주말에 끝내는 행동 순서

첫 주에 할 일 3가지

첫째 날, 쓰는 증권사가 조회 API를 주는지 확인하고 키를 발급받는다. 둘째 날, 시트를 만들고 어제·그제 체결내역을 한 번 수동으로 붙여 구조를 잡는다. 주말에 조회 스크립트를 크론에 올리고, 월요일 장 마감 뒤 자동으로 쌓이는지 확인한다. 이 순서면 첫 주 안에 3단계 자동화에 들어간다.

자동화하지 말아야 할 것

매매 판단과 매매 이유 기록은 자동화하지 않는다. 나도 콘텐츠 파이프라인을 돌리면서 배웠는데, 자동 검사가 잘못 잡는 경우가 있다. 실제로 중복 검사 가드를 검증해 보니 발행된 글 35편끼리 비교했을 때 595쌍 중 73쌍을 중복이라고 잘못 판정했다. 도구는 검증 대상이지 신앙이 아니다. 투자 일지 자동화도 같다. 원천은 증권사, 집계는 기계, 대사와 회고의 마지막 한 문단은 사람. 이 경계선만 지키면 일지는 1년을 버틴다.