직원 없이 회사를 돌리는 법, 5가지 AI 에이전트 기본 요소

화요일 밤 11시, 정부지원사업 포털에 로그인하다가 든 생각

작년 이맘때 저는 화요일 밤 11시에 노트북을 켜고 지원사업 포털 다섯 곳에 순서대로 로그인하고 있었습니다. 마감이 임박한 사업이 있는지 훑어보고, 판매자 대시보드에서 환불 요청을 처리하고, 장부 SaaS에 들어가 미분류 거래 더미를 째려보는 게 하루 일과의 마지막 순서였습니다. 회사에는 직원이 없습니다. 저 혼자 실물 재고를 관리하고, 스토어 두 곳을 운영하고, 여러 마켓플레이스에 입점하고, 구독 상품을 팔고, PG사와 계약하고, 세금을 신고합니다. "1인 기업 + 파트타임 도우미 한 명"이 아니라 정말로 한 명입니다.

3년 전이었다면 이건 그냥 불가능한 규모였을 겁니다. 지금도 브라우저 탭에 챗봇 하나 띄워놓는 걸로는 안 됩니다. 달라진 건 AI가 추상적으로 "똑똑해졌다"는 게 아니라, 에이전트가 이제 직원이 하듯 소프트웨어를 조작할 수 있게 됐다는 점입니다. 어드민 화면을 클릭하며 돌아다니고, 정부 사이트 양식을 채우고, 코드를 작성해 배포하고, 지난주에 무슨 결정을 내렸는지 기억하고, 시키지 않아도 스케줄에 맞춰 돌아갑니다. 그게 가능해지자 직원이 하던 일 대부분은 "매일 제가 손대는 일"에서 "매주 감사만 하면 되는 워크플로우"로 바뀌었습니다.

다섯 가지 기본 요소, 그 이상은 없다

제가 돌리는 모든 자동화는 결국 다섯 가지 조합입니다. 도구 이름은 6개월마다 바뀌지만 이 기본 요소는 안 바뀝니다.

브라우저를 조작하는 에이전트. 제 실제 로그인 정보가 담긴 실제 브라우저 세션을 조작합니다. 판매자 대시보드, 은행 포털, 정부 사이트, 이메일까지 전부요. 이게 단연 레버리지가 가장 큰 요소인데, 이유는 간단합니다. 국내 사업 운영의 90%는 공식 API가 없고 로그인 벽 뒤에 살고 있기 때문입니다. 정부지원사업 포털, 세무 플랫폼, 마켓플레이스 셀러센터, PG사 대시보드 — 이 중 어느 것도 깔끔한 API를 제공하지 않습니다. 자동화 전략이 "API가 있는 것만" 자동화하겠다고 하면, 결국 사업의 10%만 자동화하게 됩니다. 브라우저 에이전트는 이 벽을 그냥 넘어갑니다. 사람이 클릭하듯 클릭하니까요.

코딩 에이전트. 리포지토리를 읽고, 변경 사항을 작성하고, 리뷰 패스를 거쳐 배포합니다. 저는 이 에이전트를 커밋 권한이 있고 수습 기간이 영원히 안 끝나는 외주 개발자처럼 대합니다. 스토어 코드, 내부 대시보드, 스크레이퍼, 크고 작은 글루 스크립트를 전부 이쪽에서 만듭니다.

예약 루틴, 즉 에이전트를 위한 cron. "매일 아침 이 다섯 개 지원사업 포털을 스캔해서 새 공고만 보고해" 같은 것들입니다. 여기서 열리는 건 기술적인 가능성보다 심리적인 여유입니다. 스케줄로 돌아가는 일은 더 이상 머릿속을 차지하지 않습니다. 1인 창업자에게 가장 희소한 자원은 사실 시간이 아니라 "열려 있는 루프"입니다. 루틴은 그 루프를 닫아줍니다.

지속되는 메모리. 에이전트들이 구조화된 노트를 유지합니다. "이 장부 도구 내보내기 버튼은 설정 아래에 있다" 같은 사이트별 메모, "PG사 B 심사 진행 중, 마지막 확인 며칠 전" 같은 프로젝트별 메모, "구독은 카드 결제만 유지하기로 결정함, 되돌리지 말 것" 같은 결정별 메모. 메모리가 없으면 모든 세션이 0에서 시작하고 옛날 실수를 반복합니다. 있으면 제 "직원들"에게 근속 연차가 생깁니다.

승인 게이트. 위의 모든 걸 안전하게 만드는 규칙입니다. 에이전트가 초안을 만들고, 제가 승인하고, 에이전트가 실행합니다. 돈을 보내는 것, 정부에 신청서를 제출하는 것, 공개적으로 게시하는 것, 프로덕션에 배포하는 것 — 되돌릴 수 없는 모든 것은 사람의 명시적 체크포인트를 거칩니다.

왜 브라우저 에이전트가 한국 상황에서 결정적인가

미국식 자동화 콘텐츠를 보면 대부분 API 연동 얘기입니다. Zapier로 이 서비스와 저 서비스를 연결하는 식이죠. 그런데 한국에서 소상공인이나 중소기업을 운영해 본 사람은 압니다. 중소벤처기업부·지자체 지원사업 공고는 API가 없고, 매번 다른 포털에 로그인해서 공고문을 직접 읽어야 합니다. 홈택스, 세무 SaaS, 은행 인증서 로그인도 마찬가지입니다. 네이버 스마트스토어, 쿠팡 윙 같은 셀러 어드민도 공식 오픈 API가 있는 기능은 일부뿐이고, 나머지는 대시보드를 직접 클릭해야 합니다.

이 환경에서 "API 우선" 자동화 전략을 짜면 사업의 극히 일부만 건드리게 됩니다. 반면 브라우저 에이전트는 사람이 로그인해서 클릭하는 방식 그대로 움직이기 때문에, API 유무와 무관하게 작동합니다. 정부지원사업 포털을 매일 아침 스캔하고, 셀러 어드민에서 주문·환불을 처리하고, 장부 SaaS에서 거래를 분류하는 일이 전부 이 방식으로 돌아갑니다.

판단은 대체하지 않는다

이 스택이 실제로 하는 일을 보수적으로 말하면, 일상 반복 업무 기준으로 정규직 2~4명 몫(운영 어시스턴트, 회계 보조, 주니어 마케터, 주니어 개발자)을 대체하는 정도입니다. 비용은 한 달에 몇백 달러 수준이니 직원 한 명의 하루치 인건비도 안 됩니다. 하지만 가격, 브랜드, 제품, 법적 전략 같은 판단은 여전히 제가 합니다. 에이전트는 그 결정을 실행하는 비용을 낮춰줄 뿐, 결정을 내릴 필요를 없애주진 않습니다.

이걸 실제로 시작하려면 아래 프롬프트로 아무 반복 업무 하나에 브라우저 에이전트를 붙여보는 걸 추천합니다.

당신은 내 사업 운영 보조입니다. 다음 사이트에 로그인해서
[구체적 작업, 예: 신규 주문 확인 / 지원사업 신규 공고 스캔]을 하세요:
[포털 URL].
작업 후 반드시:
1) 화면에 나타난 결과 상태를 스크린샷으로 남기고 실제로 반영됐는지
   검증할 것 (버튼 클릭 성공 메시지만으로 완료라고 보고하지 말 것).
2) 애매하거나 정책에 없는 케이스는 실행하지 말고 나에게 질문할 것.
3) 결과를 표로 요약: 항목 | 상태 | 근거 | 다음 액션.
아직 아무것도 최종 제출/전송/발송하지 마세요. 초안과 확인까지만입니다.

결국 이 다섯 가지 기본 요소는 각자 따로 두면 그저 편리한 도구입니다. 하지만 브라우저 에이전트가 로그인 벽을 넘고, 코딩 에이전트가 실행을 맡고, 예약 루틴이 열린 루프를 닫고, 메모리가 근속 연차를 쌓고, 승인 게이트가 전부를 안전하게 묶을 때, 비로소 한 사람이 회사 하나를 실제로 돌릴 수 있는 시스템이 됩니다.