1인 회사가 직접 굴리는 자동화 3종, 슬랙 입구·인스타툰·청구 감시

강의·촬영·구축을 혼자 굴리는 1인 회사. 승철소장 AI가 직접 만들어 굴려 온 자동화 3종을, 잘 된 점보다 사고가 난 장면 위주로 풀었습니다.

이 글 3줄 요약

• 슬랙 입구: 채널 하나에 사진·메모·녹음·문서를 던지면 캘린더·할일·기록으로 갈라 보냅니다. 자체검사 973/973 통과.
• 인스타툰 제작: 주제 한 줄에서 7컷 그림과 15초 안팎의 릴스 영상을 만들고, 사람이 검수한 뒤 올립니다. 자동 테스트 979개 통과.
• 청구 감시: 서버 빌드 과금을 발견해 15개 프로젝트를 무과금 설정으로 돌렸습니다. 매주 재발을 확인하던 점검은 지금 토큰 만료로 멈춰 갱신을 기다리는 중입니다.

어떤 상황이었나

일정은 캘린더에, 할일은 할일보드에, 자료는 위키에 따로 넣어야 했습니다. 입구가 기능별로 쪼개져 있었고, 정해진 형식 밖의 입력은 알아듣지 못했으며, 결과물 품질도 들쭉날쭉했습니다. 관리할 자동화가 늘수록 그 자체가 일이 됐습니다. 무엇보다 자동화가 조용히 멈춰도 알 방법이 없었습니다. 혼자 일하는 회사에서 자동화가 멈춘 걸 모르면, 그 일은 그냥 사라집니다.

슬랙 입구: 던지면 알아서 갈라지는 채널

슬랙 채널 하나에 무엇이든 올리면 내용을 판별해 보내는 비서입니다. 예약·티켓 사진은 캘린더로 가고, 사진 한 장에 일정이 여러 개면 전부 등록합니다. "모레 14시 미팅" 같은 문장은 일정이나 할일로, 녹음 파일은 받아쓰고 요약해 기록으로 갑니다. 메일은 분류해서 중요한 것만 알리고 답장은 하지 않습니다. PDF·워드·엑셀·한글·PPT 문서는 맞는 프로젝트 폴더로 사본을 넣고, 어느 폴더인지 모르면 되묻습니다. "그 자료 어디 있었지" 같은 질문에는 위키와 폴더를 읽기 전용으로 찾아 답과 출처를 돌려줍니다. 24시간 켜진 윈도우 PC에서 돌고, 2026년 9월 1일 시작해 9월 3일부터 실제 업무에 썼습니다.

원칙은 두 줄입니다. 명확하면 바로 등록하고, 애매하면 스레드로 되묻습니다. 매일 아침 "살아 있다" 한 줄이 오고, 안 오면 멈춘 것으로 봅니다. 사진이나 메모를 올리면 5분 안에 처리 결과가 회신으로 오는 게 목표이고, 입구 채널에서는 본인 계정의 메시지만 처리합니다. 다른 사람이나 다른 봇이 올린 메시지는 무시합니다.

사고도 여럿 났습니다. 되묻기에 "안 되네"라고 답했는데, 그 안에 섞인 글자를 승인으로 읽어 등록과 삭제가 실행됐습니다. 지금은 답 전체가 승인하는 말일 때만 승인으로 봅니다. 평범한 부탁 문장 속 두 글자가 한 거래처의 줄임말과 겹쳐, 파일이 엉뚱한 고객 폴더에 저장된 일도 있었습니다. 초기에는 PDF 첨부를 받지도 못한 채 아무 말 없이 넘어갔습니다. 지금은 못 처리한 첨부가 있으면 회신으로 알려줍니다. 구글 비밀번호를 바꾼 밤에는 연결 권한이 끊기면서 5분마다 경보가 울려 아침까지 120건이 쌓였습니다. 인증 오류는 한 번만 알리고 기록만 계속 남기게 바꿨습니다.

자체검사 973개에도 사연이 있습니다. 처음엔 검사가 실제 기록 파일과 데이터베이스에 가짜 줄을 써 넣어 운영 기록을 더럽혔습니다. 지금은 검사가 임시 공간에서만 돌고, 실제 데이터나 슬랙에 손을 대려 하면 그 자리에서 멈추게 막아 두었습니다. 시작하던 날에는 다른 작업에서 폴더 구조를 크게 바꿨는데 예약 작업의 경로가 따라오지 못해, 슬랙 등록이 멈추고 이 블로그의 발행 대기 글 9편이 쌓이기도 했습니다.

인스타툰: 그림은 AI, 합격은 사람

AI를 쓰는 직장인의 공감 상황을 캐릭터 인스타툰으로 만드는 파이프라인입니다. 주제 한 줄을 넣으면 7컷 그림이 나오고, 그걸로 15초 안팎의 세로 릴스 영상을 만듭니다. 글자는 그림 AI에 맡기지 않고 나중에 따로 얹고, 대사 음성 없이 음악과 효과음, 화면 글자로 전달합니다.

캐릭터 얼굴이 컷마다 달라지는 게 인스타툰의 흔한 실패라, 표정은 8종을 미리 골라 고정해 두고 장면마다 그중 하나를 씁니다. 캐릭터 기준 이미지도 소품이 없는 컷으로만 고릅니다. 컵이나 펜을 든 컷을 기준으로 삼으면 그 소품이 다음 장면으로 새어 들어갈 수 있기 때문입니다.

자동 검사를 다 통과해도 바로 합격이 아니라 "검수 필요" 상태가 됩니다. 사람이 영상의 8개 장면을 직접 본 뒤에야 합격입니다. 한 장면을 다시 뽑는 건 최대 3번까지이고, 첫 6편 42컷을 전수 검사해 2컷을 불합격 처리하고 다시 고쳤습니다.

여기서 난 사고는 기록이었습니다. 이틀마다 "다음 편 올릴 차례" 알림이 오는데, 알림이 나간 것만으로 그 편을 "올린 편"으로 처리했습니다. 실제로는 게시되지 않은 편이 기록상 올라간 셈입니다. 알림 발송과 게시 완료를 따로 기록하고, 게시한 뒤 사람이 직접 완료 표시를 하게 고쳤습니다.

청구 감시: 범인은 트래픽이 아니라 기본 설정

2026년 9월 4일, 사이트 배포 서비스(Vercel) 사용 요금을 보다가 상당 부분이 사이트 빌드에서 나왔다는 걸 발견했습니다. 방문자가 많아서가 아니라 빠른 빌드 머신과 동시 빌드가 기본으로 켜진 설정 때문이었습니다. 15개 프로젝트를 전부 표준 설정으로 고정했고, 다음 날 청구 원장에서 무과금을 확인했습니다.

문제는 새 프로젝트를 만들면 다시 과금 설정으로 태어난다는 점입니다. 그래서 사람이 기억하는 대신 매주 월요일 새벽에 설정과 청구 내역을 다시 보고 슬랙에 한 줄로 보내게 했습니다. 실제로 9월 14일 점검에서는 목록에 없던 새 프로젝트 1개가 과금 설정으로 생긴 걸 잡아냈습니다. 정상, 경고, 실행 실패 세 가지 모양이고, 월요일에 아무 줄도 안 오면 감시 자체가 멈춘 것으로 봅니다. 그때는 예약 작업의 마지막 실행 결과만 보면 되도록, 성공과 슬랙 전송 실패와 검사 실패를 서로 다른 종료 코드로 나눠 두었습니다. 주 1회 돌지만 9일치를 봐서, 청구 원장이 늦게 차는 날도 다음 주에 한 번 더 확인됩니다.

그리고 이번에는 감시 자신이 멈췄습니다. 9월 21일 점검에서 배포 서비스의 로그인 토큰이 만료돼 프로젝트 조회가 거부됐고, 실패 알림 한 줄을 끝으로 지금은 토큰 갱신을 기다리며 점검이 멈춰 있습니다(2026년 9월 기준). 감시하는 도구도 열쇠가 만료되면 그대로 멈춥니다. 실패 알림이 한 번 울린 게 다행이었지, 그 한 줄을 놓쳤다면 과금 설정이 되살아나도 아무도 모르는 상태가 됩니다.

기계와 사람이 나눠 쥔 버튼

이런 분께 추천합니다

• 혼자 또는 몇 명이 여러 일을 동시에 굴리는 회사. 입력하는 곳을 하나로 모으는 것만으로 빠뜨리는 일이 줄어듭니다.
• 자동화를 들였는데 멈췄는지 모르는 곳. 매일 생존 신호 한 줄이 가장 간단하고 확실한 감시입니다.
• 콘텐츠를 꾸준히 내야 하는 1인 브랜드. 제작은 기계에, 합격과 게시는 사람에게 나누면 품질이 무너지지 않습니다.

현장 인사이트

자동화에서 제일 무서운 건 틀리는 게 아니라 조용히 멈추는 것입니다. 세 자동화 모두 "됐다"보다 "안 됐다"를 먼저 알리도록 만들었습니다.

이 글의 사고는 대부분 성공처럼 보이는 실패였습니다. 알림이 나갔으니 게시된 줄 알았고, 첨부가 조용히 사라지니 처리된 줄 알았습니다. 경보가 120번 울린 밤은 반대 방향의 실패였습니다. 알림이 너무 많으면 사람은 알림 자체를 안 보게 됩니다. 알려야 할 건 상태가 바뀐 순간이지, 같은 고장을 5분마다 되풀이하는 게 아니었습니다. 작은 회사가 자동화를 들일 때는 기능보다 먼저 세 가지를 정해 두면 좋습니다. 되돌리기 어려운 일은 사람이 누르고, 매일 살아 있다는 신호를 받고, "시도했다"와 "끝났다"를 따로 기록하는 것입니다.

우리 회사도 가능할까요?

쓰는 메신저가 슬랙이 아니어도, 일정과 할일이 흩어져 있고 반복 확인이 많은 회사라면 같은 구조로 묶을 수 있습니다. 지금 일이 어떤 도구와 순서로 돌아가는지 먼저 보고 규모에 맞게 제안해 드립니다. 상담과 진단은 무료입니다.

무료 상담 신청하기 →