[카테고리:] 1인 자동화

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

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

나는 혼자서 콘텐츠 생성과 발행을 무인으로 돌리는 입장이라 시트뿐 아니라 서버의 예약 작업까지 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']);
}

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

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

상황	트리거	주의점
매일 정해진 시각에 집계 갱신	시간 기반 (일 단위 타이머)	지정 시각이 아니라 그 시간대 안에 임의 실행된다
폼 응답이 올 때마다 정리	양식 제출 시	응답 탭 반영이 늦으면 빈 값을 읽을 때가 있다
특정 셀을 고치면 즉시 처리	설치 가능한 onEdit	수정 즉발이라 중복 실행 방지 로직이 필요하다
1시간마다 외부 API 폴링	시간 기반 (시간 단위 타이머)	실행 한도와 API 호출 단가를 먼저 확인한다

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

시간 기반 트리거는 ‘매일 오전 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의 ‘내 실행’ 로그부터 보세요. 로그에 실행 기록 자체가 없으면 권한 만료나 트리거 삭제를 의심합니다. 성공 알림이 안 오는 경우도 같은 방향으로 확인하면 됩니다.

---

글쓴이 정보

제가 만든 AI 파이프라인이 초안을 쓰고, 저는 검사에 걸린 것만 손봅니다. 통과하지 못한 초안은 그냥 버립니다. 파이프라인은 여기에 정리해 두었습니다.

왜 손으로 쓰는 투자 일지는 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년을 버틴다.

근거로 삼은 문서

• 국세청

---

글쓴이 정보

이 글은 문체·사실성 두 가지 자동 검사를 통과했습니다. 초안을 쓰는 건 제가 만든 AI 파이프라인이고, 검사에 걸리면 공개하지 않습니다. 만드는 과정

자주 묻는 질문

투자 일지를 자동으로 쓰려면 뭐부터 세팅해야 하나요?

먼저 내 자동화 레벨(0~3단계)이 어디쯤인지 진단하는 게 빠르다. 대부분 1단계, 즉 증권사에서 매매 내역을 수동으로 내려받는 단계에서 막혀 있는데, 깜빡하면 그날 데이터가 구멍 난다는 게 구조적 약점이다. 증권사 Open API(한국투자증권 KIS Developers, 키움 영웅문 Open API+)로 체결내역 조회를 스크립트·크론으로 주기 수집하면 수집부터 자동화된다. 초기 세팅은 반나절 정도 걸리지만 일회용 비용이다.

실현손익이 내 계산과 증권사 앱 숫자가 다르게 나오는 이유는?

산식이 다르기 때문이다. 분할 매수한 종목을 일부 매도하면 증권사는 보통 이동평균이나 FIFO 방식으로 매수분을 정하는데, 내가 임의 기준으로 계산하면 숫자가 어길 수밖에 없다. 해외 종목은 적용 환율 시점(매수일·매도일·정산 환율)에 따라서도 원화 손익이 달라진다. 증권사의 산식 설명 페이지를 한 번 읽어두면 대사할 때 원인 짚는 속도가 확 빨라진다.

증권사가 API를 안 제공하면 투자 일지 자동화는 불가능인가요?

불가능하진 않지만 차선책이다. 매일 정해진 시간에 매매 내역 내려받기 자체를 자동화하는 우회로가 있는데, 증권사 화면이 바뀌면 깨지고 2차 인증이 걸리면 그날 수집이 실패한다. 실패 시 알림을 받을 장치까지 같이 세팅해야 진짜 자동화다. 가능하면 API를 제공하는 증권사로 원천을 옮기는 게 구조적으로 안정적이다.

GOOGLEFINANCE로 투자 일지를 자동화할 수 있나요?

GOOGLEFINANCE는 시세를 당겨오는 용도일 뿐, 내 체결 데이터를 가져오지는 못한다. 체결가·수량·주문번호까지 자동 수집하려면 증권사 조회 API를 호출하는 스크립트를 크론에 등록하는 수밖에 없다. 중복 방지를 위해 이미 수집한 주문번호는 건너뛰는 로직을 꼭 넣어야 한다.

손으로 쓰는 투자 일지가 실패하는 가장 큰 이유는 뭔가요?

기록 자체보다 집계와 회고에서 무너진다. 매매 직후가 아니라 저녁에 쓰려다 체결가·수량을 다시 확인하는 게 귀찮아지고, 실현손익 계산이 증권사 숫자와 어긋나면 확인하다 일지 자체를 관두게 된다. 한 달 치를 뒤져 회고하는 작업도 사람을 지치게 한다. 결국 원천 데이터를 하나로 정하고 기계가 수집·집계하게 만드는 게 해답이다.

첫 수익이 발생했는데, 지금 당장 무엇을 신고해야 할까요

카카오톡 알림 소리에 울렁증이 온다. SaaS 첫 결제가 들어온 날, 기쁨보다 당황이 앞섰던 경험이 있다. 돈이 들어왔는데 뭘 해야 할지 모르겠는 게 당연하다. 1인 개발자 세금 신고 필수 항목을 하나하나 챙기다 보면 금방 익숙해진다. 가장 먼저 구분해야 할 건 부가세와 종합소득세다. 헷갈리게 하지만 신고 시기와 대상이 다르다. 아예 다른 세금이다.

부가세는 반기로 끊는다. 개인 일반과세자는 1~6월치를 7월 25일까지, 7~12월치를 다음 해 1월 25일까지 확정신고한다. 4월과 10월에 오는 예정고지서는 직전 반기에 낸 세액의 절반을 미리 내는 것이라 보통 납부만 하면 되고, 매출이 크게 줄었으면 그때는 직접 예정신고를 할 수 있다(1기 예정신고 기한은 4월 25일). 종합소득세는 1년 전체를 합쳐서 다음 해 5월에 신고한다. 지금 당장 급한 건 부가 신고다. 사업자 등록을 하지 않았더라도 일정 규모 이상의 수익이 발생하면 사업자로 간주되어 신고 대상이 된다. 신규 1인 개발자가 범하기 쉬운 실수가 있다. 사업자번호 개설 전 테스트로 벌어들인 수익을 그냥 넘기는 경우다. 이건 누락되면 나중에 가산세를 낼 수 있다. 테스트 수익이라도 사업 관련성이 있다면 신고 대상이다.

업무 비용인지 아닌지, 그 기준을 코드로 치면 어떡하죠

세무사들은 “업무와 관련성”이라고 말한다. 개발자 입장에서 이 말은 너무 추상적이다. 코드로 치면 런타임 에러가 나지 않게 하는 의존성과 비슷하다. AWS 비용 청구서, GCP 세금 계산서, Cloudflare 도메인 결제 내역은 가장 명확한 필수 비용이다. 이건 서비스가 돌아가는 데 없어서는 안 될 리소스다.

헷갈리는 건 장비다. 맥북을 샀는데 회사 일로 100% 쓴다. 그럼 경비인가? 기준은 업무 전용 여부다. 개인 용도(게임, 넷플릭스)로 섞어 쓰면 경비 인정이 까다롭다. 노트북과 모니터처럼 고가 장비는 업무용 쓰임새를 입증하는 자료를 남겨둬야 나중에 심사 때 걸리지 않는다. 일반 관리비와 업무 무관 지출의 경계를 명확히 하는 게 핵심이다. 카페비는 업무 미팅 증빙이 되어야 하고, 식대는 접대 비용으로 처리할 때 한도가 있다.

홈택스 마스터하기: 원천징수 조회와 세금 계산서 발행

홈택스 UI는 개발자 친화적이지 않다. 그래도 메뉴 위치 정도는 외워둬야 한다. 내가 받은 원천징수 내역은 홈택스에 로그인해 My홈택스의 지급명세서 제출내역에서 확인한다. 여기서 3.3%의 원천징수 세금이 제대로 잡혔는지 본다. 이름이 비슷한 ‘원천징수이행상황신고’는 돈을 **주는** 쪽이 신고하는 메뉴라 받는 사람이 볼 곳이 아니다. 홈택스 메뉴 이름은 개편 때마다 바뀌므로 최종 위치는 화면에서 검색해 확인하는 게 빠르다. B2B 거래를 할 때 상대방이 세금을 떼어갔다면 이 내역이 있어야 한다.

계산서를 발행해야 할 때도 있다. 사업자끼리 거래하면 금액과 관계없이 세금계산서를 발행하는 게 원칙이다(부가가치세법 제32조). 흔히 말하는 3만 원은 발행 기준이 아니라 받는 쪽의 증빙 기준이다 — 건당 3만 원을 넘는 지출에 세금계산서·신용카드 매출전표·현금영수증 같은 적격증빙이 없으면 증빙불비 가산세 2%를 문다. ‘계산서 발행 및 수취 내역’ 메뉴에서 입력하면 된다. 스크립트로 돌리는 자동화와는 다르게 수동 입력이라 실수가 잦다. 현금영수증과 세금계산서 중 뭘 써야 할까? 사업자 간 거래는 세금계산서다. 개인 고객에게 서비스를 파는 SaaS라면 신용카드 매출전표나 현금영수증이 증빙이 된다. 고객이 계산서를 달라고 하면 그때 발행 메뉴를 찾아가면 된다.

간편장부 vs 복식부기, 어떤 선택이 개발자에게 유리한가

단순 비용 절감만 생각하면 간편장부가 편해 보인다. 하지만 SaaS 운영 구조를 보면 복식부기가 더 효율적일 때가 많다. 장부 세액 공제를 받을 수 있기 때문이다. 서버 비용과 API 사용료처럼 매입이 명확하게 발생하는 SaaS 사업은 복식부기의 장점을 극대화하기 좋다. 간편장부는 단순수익금액에 비례해 추계 경비를 인정해주지만, 실제 쓴 비용이 그보다 많으면 손해다.

복식부기는 장부를 쓰는 노력이 필요하다. 다행히 전자세금계산서와 연동되는 회계 툴을 쓰면 자동으로 장부가 만들어진다. 매입이 많은 1인 개발자라면 초기 세팅 비용을 들이더라도 복식부기를 선택하는 게 낫다. 장부 세액 공제 덕분에 환급받는 부가세가 간편장부보다 클 가능성이 높다. 단순히 기록의 편의성을 따지기보다 세금 절감 효과를 계산기로 두들겨보고 결정해야 한다.

세금 신고를 위한 필수 서류와 관리 엑셀 양식

복잡한 회계 소프트웨어 없어도 된다. 나는 엑셀 하나로 관리한다. 매출/매입 내역을 기록하는 최소한의 구조만 있으면 충분하다. 날짜, 품명, 공급가액, 부가세, 적요. 이 5개 컬럼만 있어도 세무사는 일을 처리할 수 있다. CSV 파일로 크론 작업을 돌려서 매달 내려받는 식으로 자동화를 구축해두면 두 번 손 쓸 일이 없다.

증빙 서류 보관도 중요하다. 영수증이나 계약서는 종이로 뭉쳐두지 말고 PDF로 스캔해서 클라우드에 올려두자. 세무사에게 장부를 넘길 때 폴더 구조만 깔끔해도 작업 속도가 달라진다. 월별 단위로 폴더를 만들고 그달에 발생한 비용 영수증을 다 넣어둔다. 이거 하나만 지켜도 세무사가 “정리 잘해오셨네”라고 한다.

세금 폭탄을 피하는 마지막 점검: 3가지 핵심

가계 지출을 사업 경비로 넣지 마라. 편의점에서 산 커피나 점심값을 경비 처리하다가 걸리면 가산세가 만만치 않다. 업무와 명확히 관련된 비용만 올린다. 신고 기한을 놓치지 않는 것도 중요하다. 내 자동화 시스템에도 세금 신고 알림 크론이 돌고 있다. 깜빡하고 지나가면 납부 유예 승인을 받더라도 불이익이 따른다.

투자 수익은 사업 수익이 아니다. 주식으로 번 돈을 SaaS 매출 항목에 넣으면 안 된다. 이건 분리해야 한다. 나는 직접 만든 도구를 써서 투자 내역을 사업 장부와 분리해서 관리한다. 섞으면 나중에 못 푼다. 투자 손익과 사업 손익이 섞이면 장부가 꼬이고 세금 신고 때 골치 아파진다. 코드로 돈을 버는 사람이라면 장부도 코드처럼 깔끔하게 유지하는 습관이 필수다.

참고한 공식 문서

• 국세청

고지 — 이 글은 세금에 관한 일반 정보이며 세무사의 자문을 대신하지 않습니다. 세법과 신고 기한은 바뀌므로 실제 신고 전에는 국세청 안내나 세무 전문가에게 확인하시기 바랍니다.

---

글쓴이 정보

여기 올라오는 글의 초안은 운영자가 만든 AI 파이프라인이 자동으로 만듭니다. 다만 문체·사실성 검사를 통과하지 못한 초안은 공개되지 않고 사람이 손봅니다. 그 과정은 포트폴리오에서 볼 수 있습니다.

자주 묻는 질문

사업자 등록 전 테스트 수익도 세금 신고를 해야 하나요?

네, 사업 관련성이 있는 테스트 수익도 신고 대상입니다. 나중에 가산세를 피하려면 사업자번호 개설 전 수익도 누락 없이 합산해야 합니다.

부가세와 종합소득세의 신고 시기는 어떻게 다른가요?

개인 일반과세자는 1~6월치를 7월 25일까지, 7~12월치를 다음 해 1월 25일까지 확정신고합니다. 4월·10월 예정고지는 직전 반기 세액의 절반을 미리 내는 것이라 보통 납부만 하면 됩니다. 종합소득세는 1년치를 합산해 다음 해 5월에 신고합니다.

고가 장비인 맥북을 업무 경비로 인정받으려면 어떻게 해야 하나요?

업무 전용으로 사용된다는 것을 입증할 수 있는 자료를 남겨야 합니다. 개인 용도와 섞여 쓰면 인정이 까다로우므로 사용 내역을 명확히 관리하세요.

B2B 거래 시 세금계산서와 현금영수증 중 뭘 써야 하나요?

사업자 간 거래는 세금계산서를 발행합니다. 개인 고객에게 파는 경우에는 신용카드 매출전표나 현금영수증으로 증빙하면 됩니다.

1인 개발자는 간편장부와 복식부기 중 무엇을 선택해야 하나요?

서버 비용 등 매입이 많은 SaaS 구조라면 복식부기가 세액 공제 측면에서 유리합니다. 비용이 적다면 간편장부가 편하지만, 실제 지출보다 추계 경비가 적으면 손해를 볼 수 있습니다.

세무사에게 장부를 넘길 때 가장 중요한 정리 포인트는?

월별로 폴더를 만들어 비용 영수증을 PDF로 스캔해서 보관하세요. 엑셀에는 날짜, 품명, 공급가액, 부가세, 적요 5개 컬럼만 있어도 세무사가 처리하기에 충분합니다.