지난 글에서 monorepo 하나로 법인 운영을 자동화하는 이야기를 했다. 그 이후 실제로 경비 처리, 급여 관리, 미팅록 관리, 투자사 대응까지 같은 구조 위에서 돌려봤다. 그러다 하나의 패턴을 발견했고 여기 정리한다.
그동안 SaaS의 역할은 사람이 하던 일을 워크플로우로 정리하고, 엔지니어링으로 자동화해서, 비용과 수고를 아껴주는 것이었다. 그런데 AI가 충분히 똑똑해진 지금, 그 엔지니어링으로 자동화 부분을 프롬프트가 대신할 수 있게 됐다. SaaS가 해주던 일을 SaaS 없이 직접 돌릴 수 있다는 뜻이다.
법인 경비 처리를 예로 들어보자.
간단한 웹페이지에서 영수증 이미지를 올리면 GitHub Pull Request가 자동 생성되도록 했다. 이 자동 생성된 PR에서 GitHub Actions로 AI 에이전트가 트리거 된다. 이 AI 에이전트는 영수증 이미지에서 날짜, 금액, 거래처, 항목을 읽고, 복식부기 분개를 만들고, 해당 월 폴더에 정리한다.
아래는 GitHub Actions 워크플로우에 들어 있는 프롬프트에서 발췌한 내용이다.
1. 영수증 이미지에서 거래일자, 공급가액, 부가세, 거래처명, 품목을 추출하라.
2. 카테고리는 expense-categore.yaml 을 참고해 자동 분류하라.
3. 해당 월의 ledger/YYYY-MM.yaml 에 복식부기 분개를 추가하라. 차변 합계와 대변 합계가 일치하는지 검증하라.
4. 영수증 파일을 receipts/YYYY-MM/MMDD_{상호명}_{금액}.pdf 형식으로 변환해 이동하라.
이 과정이 끝나면 GitHub 모바일 앱으로 나에게 알림이 오고 나는 주기적으로 들어가 PR을 살펴보고 merge 한다.
이건 경비 처리 SaaS가 해주는 일과 같다. 영수증을 넣으면 분류하고, 정리하고, 승인받고, 저장한다. 다만 그 일을 SaaS가 아니라 프롬프트와 GitHub Actions가 하고 있을 뿐이다.
여기서 흥미로운 것이 있는데, 이 구조에서 비즈니스/도메인 로직 역할을 하는 AI 에이전트의 프롬프트만 바꾸면 또 다른 SaaS가 탄생한다는 것이다.
급여 관리: 직원 근태 데이터와 급여 테이블을 넣으면 AI 에이전트가 급여를 계산하고, 4대보험료와 원천세를 산출하고, 급여 명세서를 만들어 PR을 올린다. 내가 확인하면 AI 에이전트가 필요한 사이트들에 들어가 반영해준다. HR SaaS가 해주는 루프의 간소화 버전이다.1
미팅록 요약 및 할 일 추출: 미팅이 끝나면 녹음 파일이나 트랜스크립트를 올린다. AI 에이전트가 핵심 논의사항을 요약하고, 결정 사항과 참석자별 할 일을 추출해서 PR을 만든다. 확인하고 merge하면 미팅 노트가 레포에 아카이빙되고, 할 일은 GitHub Issue로 자동 생성된다. 미팅 노트 SaaS가 해주는 일이다. 하지만 모든 소스코드, 법인 정보, 문서들이 모여있는 monorepo에서 이를 수행하였기에 훨씬 맥락에 맞고 feasible한 액션플랜이 도출된다.
투자사 대응: 투자사가 실사 자료를 요청하면 (재무제표, 주주명부, 등기부등본, 통장사본 등) AI가 레포에서 최신 자료를 취합하고, 요청 형식에 맞게 정리해서 PR을 만든다. 확인하면 AI 에이전트가 웹브라우저 열어서 gmail에 이메일 초안까지 적어놓고 send 버튼 누르기 직전에 알려준다. 데이터룸 SaaS를 따로 쓰지 않아도 된다. 어차피 자료 원본은 전부 레포에 있으니까.
이 세 업무의 인프라는 동일하다. GitHub Actions가 오케스트레이션하고, AI 에이전트가 수행하고, PR로 검토한다. 바뀐 건 트리거와 프롬프트뿐, 같은 루프다.
이제 새 업무가 생기면 SaaS를 찾는 대신 세 가지를 묻게 됐다.
- 무엇을: 어떤 입력이 들어오면 어떤 출력이 나와야 하나. 이걸 정의하면 프롬프트가 된다.
- 어떻게 발동시키나: 입력을 어떤 채널로 넣을 건가. 슬랙, 웹폼, 이메일 포워딩. 화려할 필요 없다. AI 에이전트에게 전달만 되면 된다.
- 어떻게 검토하나: AI의 결과물을 누가, 어떤 형태로 확인하나. PR이든 슬랙 승인이든, 사람이 보고 승인하는 단계가 있으면 된다.
이 세 가지를 정하면 SaaS가 하던 일을 대체할 수 있다. 나는 AI 에이전트 발동 편의성과 익숙함, Claude Code를 추가 비용 없이 자유롭게 쓸 수 있다는 점에서 GitHub 기반 워크플로우를 선택했지만 각자의 상황에 따라 인풋 트리거와 검토 및 저장 방법을 선택하면 된다.
그러면 SaaS가 월 구독료를 받고 제공하던 것의 핵심이, 프롬프트 하나와 이미 쓰고 있는 도구들의 조합으로 돌아간다.
이 접근의 가장 큰 장점은 운영 지식이 복리로 쌓인다는 것이다.
예를 들어, 해외 결제에서 invoice 날짜(현지시간)와 카드 승인전표 날짜(한국시간)가 달라서 장부 기재일이 잘못 잡힌 적이 있다. 프롬프트에 “카드 승인전표의 거래일시를 최우선으로 사용하라”는 날짜 우선순위 규칙을 추가해서 해결했다.2
AI는 처음부터 세법, 근로기준법, 회계기준 같은 공적 지식 위에서 출발한다. 부가세 10% 별도 계산, 4대보험료율 적용, 복식부기 차대변 균형, 이런 것들은 프롬프트에 기본으로 깔고 들어간다.
그 위에 우리 회사 고유의 운영 지식이 쌓인다. “접대비는 1인당 10만원 한도, 참석 인원을 반드시 기록하라.”, “비품 감가상각은 법정 최대 10년이 아닌 5년 정액법으로 처리하라.” 등 이것들은 법에 딱 정해진건 아니다. 우리 회사의 회계 전략, 경비 정책, 세무 판단이다. 같은 업종의 다른 회사라면 다르게 결정할 수 있는 것들이다. 실무를 돌리면서 발견하고, 프롬프트에 한 줄씩 추가하면서 코드화한 것이다.
이 과정이 복리로 작동한다. 규칙이 추가될 때마다 다음 작업의 정확도가 올라간다. SaaS에서 이 지식은 어디에 있을까? 설정 메뉴 곳곳에 흩어져 있거나, 아예 표현할 수 없거나, 담당자의 머릿속에만 있다. 담당자가 퇴사하면 같이 사라진다. 프롬프트에서는 한 파일에, 읽을 수 있는 자연어로, 버전 관리되며 축적된다. Git history에 “왜 이 규칙이 추가됐는지”까지 남는다. SaaS는 편리함을 팔지만 이 구조는 운영 지식 자산을 만든다.
물론 이 접근의 한계도 있다. 모든 것이 로직으로 코드화 된 서비스 보다 느리다. AI 에이전트가 구동되고 프롬프트에 따라 업무를 수행하는데 몇 분의 시간이 걸린다. 그러므로 실시간 협업, 수천 명의 동시 접속, 밀리초 응답이 필요한 서비스는 이 구조의 영역이 아니다.
보안도 짚어야 한다. 영수증, 급여 데이터, 투자 자료를 AI에 보내는 것에 우려가 있을 수 있다. 내가 지키는 원칙은 세 가지다. API 데이터를 모델 학습에 사용하지 않는 서비스만 쓴다. 레포지토리는 private으로 두고 접근 권한을 최소화한다. 주민등록번호나 계좌번호 같은 민감 정보는 마스킹 후 처리한다.
이 패턴이 맞는 업무는 실시간 응답이 필요 없고, 하루 처리량이 수십 건 이하이며, 사람의 확인이 들어가는 것이 자연스러운 일. 법인 운영의 상당 부분이 여기에 해당한다.
자 이제 5인 이하 스타트업이 매달 내는 SaaS 구독료 목록을 떠올려보자. 그 중 상당수는 “입력 → 처리 → 승인 → 저장” 루프다. 그리고 그 각각에 대해 “무엇을, 어떻게 발동시키고, 어떻게 검토할까”를 상상해보자. 생각보다 많은 것들이, 프롬프트 하나와 트리거 하나로 대체할 수 있다. 이미 가지고 있는 인프라 위에서.
감사합니다.
Disclaim: 이 글은 주식회사 탭제로 모노리포(tab0inc/monore)에서 tab0inc-marketing/taeho-blog-content-writer AI 스킬을 이용해 작성되고 검토되었습니다.
1
“AI가 급여를 틀리면 어떡하나”고 물을 수 있다. 그러나 어떤 도구를 쓰든 급여 지급과 4대보험 신고의 법적 책임은 고용주에게 있다. 틀렸을 때 정정신고하고 차액을 정산하는 절차도 같다. 이 과정을 복리 엔지니어링의 콜드 스타트 과정으로 볼 수 있느냐가 핵심이다.
2
만약 사용하고 있는 SaaS에 이 규칙이 없었거나 애매했다면 고객센터에 문의해야 했을 일이다.