업무 자동화 ROI, 무엇이 문제였나?
업무 자동화 ROI는 만드는 데 든 시간보다 매주 돌려받는 시간이 크면 성립하고, 저희 계산에서는 구축 4~6시간을 들여 주 5~8시간을 돌려받아 4~7일이면 본전을 찾는다는 답이 나왔습니다. 계산 자체는 덧셈과 나눗셈뿐이었습니다. 어려웠던 쪽은 그 계산에 넣을 숫자를 처음으로 재 보는 일과, 계산이 감추는 결정 변수를 찾아내는 일이었습니다.
대상 업무는 회사가 만드는 과정을 X와 Threads에 매일 공개하는 짧은 글이었습니다. 글 한 편은 작아 보이지만, 매일 글감을 고르고, 글에 쓴 사실이 실제로 있는 자료와 맞는지 확인하고, 두 채널의 말투에 맞춰 다시 쓰는 일이 겹쳐 있었습니다. 대표 한 사람이 회사를 꾸리는 구조라, 이 시간은 고객 일과 제품 개발에서 그대로 빠져나갔습니다.
그래서 미리 예산을 걸어 두었습니다. 공개 일지에 쓰는 시간은 주 2시간을 넘기지 않는다는 상한입니다. 알리는 일이 만드는 일을 잡아먹기 시작하면 알릴 거리 자체가 줄어든다는 판단이었습니다. 문제는 상한을 정해 두고도 실제 사용 시간을 한 번도 합산하지 않았다는 점이었습니다.
이 글은 자동화 ROI를 돈이 아니라 시간 단위로 계산합니다. 대표 한 사람이 꾸리는 회사에서 가장 먼저 바닥나는 자원은 현금보다 대표의 시간이고, 도구 구독료가 없는 자동화라면 비용도 효과도 결국 시간으로 셀 수 있기 때문입니다. 시간으로 계산하면 누구나 자기 업무에 같은 식을 그대로 대입해 볼 수 있다는 장점도 있습니다.
많은 회사가 자동화를 검토할 때 같은 자리에서 멈춥니다. 도구 가격이나 기능 목록은 비교하는데, 지금 그 업무에 사람이 몇 시간을 쓰는지는 재지 않습니다. 이 기준선이 없으면 자동화가 무엇을 돌려줄지 계산할 방법이 없습니다.
처음 잰 숫자: 하루 50~80분, 주 6~9시간
2026년 4월 28일, 처음으로 합산을 해 보았습니다. 방법은 단순했습니다. 하루 수작업 시간에 7일을 곱했습니다. 하루 50~80분이 걸리고 있었고, 7일을 곱하면 주 6~9시간이 나왔습니다. 스스로 정한 상한 주 2시간을 이미 넘긴 상태가 쌓여 있었습니다.
이 숫자가 중요한 이유는 하루 단위로는 문제가 보이지 않는다는 데 있습니다. 하루 50분은 점심시간 정도라 아무도 문제 삼지 않습니다. 같은 시간을 주 단위로 모아 상한 옆에 세워야 몇 배를 넘었는지 보입니다. 매일 반복하는 작은 업무일수록 주 단위로 다시 합산해 봐야 합니다.
기준선을 잴 때 하나 더 확인한 것이 있습니다. 하루 50~80분 안에 무엇이 들어 있는가입니다. 발행 버튼을 누르는 시간은 몇 초에 불과합니다. 대부분은 오늘 무엇을 쓸지 고르고, 글에 적은 사실이 실제로 만든 자산과 맞는지 확인하고, 영어 채널과 한국어 채널에 맞춰 두 번 쓰는 시간이었습니다. 시간을 쓰는 곳을 이렇게 나눠 보지 않으면, 엉뚱한 단계를 자동화하고도 시간이 그대로인 결과를 얻습니다.
측정 방식의 한계도 함께 적어 둡니다. 결정 기록에는 하루 50~80분을 어떤 도구로 쟀는지가 남아 있지 않습니다. 값이 한 점이 아니라 범위로 적혀 있어, 타이머 기록보다는 사람이 어림한 값으로 읽는 편이 맞습니다. 이 글에서도 이 숫자를 정밀 측정값이 아니라 출발선을 잡는 어림값으로 다룹니다.
그래도 어림값으로 충분했습니다. 하루 50분으로 낮게 잡아도 주 2시간 상한을 넘기고, 80분으로 높게 잡으면 훨씬 더 넘깁니다. 범위의 어느 끝을 택해도 결론이 같다면, 더 정밀하게 재느라 시간을 쓸 이유가 없습니다. 기준선은 정확해야 하는 게 아니라 결론을 가를 만큼만 정확하면 됩니다.
세운 가설: 구축 4~6시간이면 4~7일에 회수된다
기준선을 잡은 뒤 세운 가설은 이랬습니다. 글쓰기 절차를 AI에게 넘기고 사람은 마지막 검토만 하면, 하루 검토 시간이 5~10분으로 줄어든다. 이 가설에서 투자 대비 효과를 세 숫자로 계산했습니다.
- 구축 비용: 4~6시간, 한 번만 든다
- 절감 효과: 주 5~8시간
- 회수 기간: 4~7일
구축 비용 4~6시간은 기존 개발 일정에서 빼 와야 하는 시간이었습니다. 당시 가장 급한 개발 작업에서 5시간을 한 번 차감하는 것으로 잡았고, 1주일 뒤에는 효과가 비용을 넘어선다고 계산했습니다.
목표값의 크기도 따져 봤습니다. 하루 50~80분을 5~10분으로 줄인다는 것은 사람이 하던 일의 대부분을 넘긴다는 뜻입니다. 사람에게 남는 일은 초안을 읽고 발행할지 정하는 마지막 판단 하나입니다. 그만큼 넘긴 쪽, 즉 AI가 내는 초안의 품질에 기대는 비중이 커집니다. 목표를 크게 잡을수록 그 목표를 받치는 조건도 엄격해야 합니다.
여기서 자동화 ROI를 계산하는 사람이 놓치기 쉬운 점이 하나 있습니다. 회수 기간 4~7일은 절감 효과가 첫날부터 그대로 나온다는 전제 위에 서 있습니다. 실제로는 새 절차가 손에 익는 기간이 있고, 자동화가 낸 결과물을 사람이 믿지 못하면 검토 시간이 줄지 않습니다. 저희 계산에도 이 전제가 숨어 있었고, 다음 절에서 그 자리를 다룹니다.
가설이 틀린 지점은 어디였나?
자동화 가설보다 먼저 틀린 가설이 있었습니다. 상한만 정해 두면 사람이 알아서 시간을 맞춘다는 가정입니다. 주 2시간 상한은 정한 뒤로 한 번도 지켜지지 않았고, 하루 50~80분이 매일 쌓였습니다. 규칙을 적어 둔다고 규칙이 지켜지지는 않았습니다. 이 가정은 반증된 채로 이 기록에 남깁니다.
1주일 뒤 흑자 전환이라는 예상도 같은 구조입니다. 개발 일정에서 5시간을 한 번 빼 오고, 그 뒤 매주 5~8시간을 돌려받으면 계산상 1주일 안에 본전을 넘습니다. 하지만 첫 주는 새 절차를 처음 쓰는 주입니다. 초안이 기대에 못 미쳐 사람이 고쳐 쓰는 날이 있으면 그 주의 절감은 계산보다 작아집니다. 그래서 회수 기간은 약속이 아니라 정확도가 받쳐 줄 때의 상한으로 읽어야 합니다.
두 번째로 틀린 지점은 ROI 계산 자체였습니다. 계산표에는 시간만 있고 정확도가 없습니다. 그런데 결정 기록을 다시 읽으면, 효과를 좌우하는 변수는 시간이 아니라 AI가 글 속 사실을 실제 자료와 대조하는 정확도라고 적혀 있습니다. 대조가 틀리면 사람이 글을 처음부터 다시 확인해야 하고, 그러면 하루 5~10분 목표는 무너집니다.
다시 말해, 주 5~8시간 절감은 사실 대조 정확도가 충분히 높을 때만 성립합니다. 시간 계산은 이 조건을 표시하지 않습니다. 그래서 저희는 회수 기간보다 대조 정확도를 먼저 합격선에 올렸습니다. 이 순서가 바뀌면 숫자상으로는 회수됐는데 실제로는 검토 시간이 그대로인 상황이 생깁니다.
세 번째로, 대안 중 하나였던 외부 예약 발행 도구는 처음에는 가장 쉬운 답처럼 보였습니다. Buffer나 Hypefury 같은 서비스에 글을 넣어 두면 정해진 시간에 올려 줍니다. 하지만 시간을 잡아먹던 일은 올리는 동작이 아니라 고르고 확인하는 판단이었고, 예약 도구는 그 판단을 대신하지 않습니다. 게다가 한국어 채널과 공개 가능 범위를 나누는 보안 등급 규칙에 맞지 않았습니다.
진짜 원인: 판단 기준이 사람 머릿속에만 있었다
시간이 많이 든 진짜 원인은 글쓰기 속도가 아니었습니다. 어떤 말투로 쓸지, 어떤 글감을 고를지, 어떤 근거를 어디까지 확인할지를 매번 사람이 새로 판단했기 때문입니다. 판단 기준이 문서로 정리되지 않은 상태에서는 AI에게 맡겨도 결과물을 사람이 다시 뜯어봐야 합니다.
이 상황을 바꾼 것은 도구가 아니라 기록이었습니다. 몇 주 동안 운영하면서 말투·글감·검증 순서에 관한 원칙이 학습 기록 문서에 하나씩 쌓였습니다. 결정 기록은 이 시점을 두고 원칙이 충분히 쌓여 자동화 가능한 단계에 들어섰다고 판단합니다. 규칙이 글로 있어야 AI가 그 규칙을 따를 수 있습니다.
이미 있던 자산도 원인 진단에 들어갔습니다. 공개 일지 초안을 쓰는 글쓰기 에이전트가 이미 있었습니다. 여기서 에이전트는 정해진 지시서를 읽고 한 가지 일만 처리하는 하위 AI 작업자입니다. 결정 기록은 새로 만들 필요 없이 이 에이전트를 강화하기만 해도 핵심을 쓸 수 있다고 봤습니다.
이 점은 ROI 계산에도 그대로 들어갔습니다. 구축 비용을 4~6시간으로 낮게 잡을 수 있었던 이유는 바닥부터 만들지 않았기 때문입니다. 글쓰기 에이전트는 이미 있었고, 원칙은 이미 학습 기록에 쌓여 있었습니다. 남은 일은 흩어진 원칙을 에이전트가 자동으로 읽게 연결하고, 글감과 서식을 파일로 정리하는 일이었습니다. 같은 자동화를 아무 기반 없이 시작했다면 구축 비용도 회수 기간도 전혀 다른 숫자가 나왔을 것입니다.
정리하면 원인은 세 겹이었습니다. 측정을 안 해서 초과를 몰랐고, 판단 기준이 머릿속에만 있어 위임할 수 없었으며, 위임할 수 있게 된 뒤에도 그 결과를 검증할 장치가 없었습니다. 조치는 이 세 겹에 하나씩 대응했습니다.
조치: 무엇을 만들었고 무엇을 버렸나?
조치는 새 서비스를 들이는 대신 이미 쓰던 Claude Code 안에서 끝냈습니다. 짧은 명령 한 줄로 절차 전체를 부르는 슬래시 커맨드 2개, 강화한 글쓰기 에이전트 1개, 글감 목록 파일과 서식 파일 2개가 전부입니다. 새 파일 4개를 만들고 기존 파일 1개를 강화했습니다.
- 슬래시 커맨드 2개: X용(영어)과 Threads용(한국어)을 따로 부른다
- 글쓰기 에이전트 강화: 말투·글감·검증 원칙을 자동으로 참조하고, 사실 대조를 건너뛰지 못하게 한다
- 글감 목록 파일: 이미 쓴 글감 이력, 공개해도 되는 자산 목록, 다음에 쓸 글감 우선순위
- 서식 파일: X용 4개짜리 연결 글 + 보충 글, Threads용 단일 글, 보안 등급 확인·사실 대조·한글 번역 칸
버린 대안도 숫자처럼 기록해 둡니다. 대안은 세 가지였습니다. 첫째, 수작업 유지는 상한 초과가 계속 쌓이는 길이라 버렸습니다. 둘째, X API를 직접 연동해 반응 수치까지 자동 기록하는 방안은 범위가 커질 위험이 있어 다음 버전으로 미뤘습니다. 셋째, 외부 예약 발행 도구는 앞 절의 이유로 맞지 않았습니다.
각 부품은 시간을 잡아먹던 단계 하나씩을 맡습니다. 글감 목록 파일은 오늘 무엇을 쓸지 고르는 단계를 맡아, 이미 쓴 글감을 피하고 다음 우선순위를 바로 꺼내 줍니다. 강화한 에이전트는 사실 대조 단계를 맡아, 글에 쓴 자산이 실제로 있는지 확인하지 않고는 초안을 내지 못하게 합니다. 서식 파일은 채널별로 두 번 쓰는 단계를 맡아, 영어 연결 글과 한국어 단일 글의 틀과 한글 번역 칸을 미리 정해 둡니다. 사람에게는 초안을 읽고 발행할지 정하는 마지막 검토만 남습니다.
두 번째 대안을 미룬 판단이 이번 조치에서 가장 중요했다고 봅니다. 반응 수치를 자동으로 모으면 좋은 점이 분명하지만, 그 순간 이 작업은 글쓰기 자동화에서 데이터 수집 시스템으로 커집니다. 구축 4~6시간이라는 계산은 범위를 좁게 잡았을 때만 맞습니다.
재측정 결과: 합격선 3개, 실측 기록은 남지 않았다
다시 잴 기준은 착수 전에 정했습니다. 첫 버전을 끝낼 때 아래 세 조건을 모두 통과해야 완료로 보고, 하나라도 실패하면 미완료로 두고 보정 작업을 더 하기로 했습니다.
- 사람 검토 시간 10분 이하
- 사실 대조: 글에 쓴 자산이 실제 자산과 95% 이상 일치
- 보안 등급 위반 0건
솔직하게 적습니다. 이 글의 재료인 결정 기록에는 합격선 대비 실측 결과가 남아 있지 않습니다. 하루 5~10분은 목표값이고, 회수 기간 4~7일과 1주일 뒤 흑자 전환도 착수 시점의 계산입니다. 실제로 검토 시간이 몇 분으로 줄었는지, 사실 대조가 95%를 넘었는지는 이 기록만으로는 말할 수 없습니다.
재측정은 어렵지 않은 일이었습니다. 합격선 세 개가 모두 셀 수 있는 값이기 때문입니다. 검토 시간은 초안을 연 시각과 발행 결정 시각의 차이로 잴 수 있고, 사실 대조는 글에 나온 자산 이름을 실제 자산 목록과 맞춰 일치 비율을 내면 됩니다. 보안 등급 위반은 공개 범위 규칙에 걸린 글의 건수입니다. 잴 수 있는 기준을 세워 두고 재지 않았으므로, 이 공백은 방법이 아니라 절차의 문제입니다.
그래서 이 글의 ROI 숫자는 결과가 아니라 예상으로 읽어야 합니다. 주 5~8시간을 실제로 돌려받았는지, 4~7일 만에 본전을 찾았는지는 재측정 칸이 채워져야 말할 수 있습니다. 자동화 사례를 소개하는 글이 흔히 예상 효과를 결과처럼 적지만, 저희 기록이 증명하는 범위는 착수 전 기준선과 계산, 합격선까지입니다. 이 경계를 흐리면 다음에 같은 계산을 믿고 더 큰 자동화에 들어갔다가 같은 공백을 되풀이하게 됩니다.
이 공백 자체가 이번 개선기에서 얻은 가장 쓸모 있는 교훈입니다. 자동화를 설계할 때 합격선은 정했는데, 다시 재서 그 결과를 같은 문서에 붙이는 단계는 정하지 않았습니다. 기준선을 재지 않아 상한 초과를 몰랐던 실수가 자동화 이후에도 같은 모양으로 반복될 수 있는 자리입니다. 다음 버전에서는 결과 칸을 결정 기록 안에 미리 비워 두고, 그 칸이 비어 있으면 완료로 치지 않는 규칙이 필요합니다.
남는 한계: 무너지면 다시 보정할 가정 3개
결정 기록은 자동화가 기대는 가정 세 개를 미리 적어 두고, 하나라도 무너지면 다음 버전 보정에 들어가기로 했습니다. 이 가정들이 이번 자동화 ROI의 진짜 위험 요인입니다.
- 가정 1: 글쓰기 에이전트가 자연어 본문에서 자산을 찾아 대조하는 규칙이 95% 이상 정확하다
- 가정 2: 글감 목록의 사용 이력은 사람이 발행하지 않은 글을 따로 표시하는 규칙 없이도 맞게 유지된다
- 가정 3: 공개 가능한 자산 목록 7개와 새로 더할 자산이 최소 운영 14일째까지 글감을 댄다
가정 1은 앞에서 본 결정 변수 그대로입니다. 대조 정확도가 95%에 못 미치면 사람이 다시 확인해야 하고, 검토 시간 목표가 함께 무너집니다. 가정 2는 사람이 초안을 받고도 발행하지 않는 날을 고려하지 않았습니다. 그런 날이 쌓이면 목록에는 쓴 것으로 남은 글감이 실제로는 한 번도 나가지 않은 상태가 됩니다.
가정 3은 글감의 수명입니다. 매일 쓰는 글에 공개 가능한 자산 7개로는 오래 버티기 어렵고, 결정 기록도 최소 14일까지만 보장한다고 적었습니다. 자동화가 글쓰기를 빠르게 만들수록 글감은 더 빨리 바닥납니다. 속도를 얻으면 재료 소비도 빨라진다는 점을 ROI 계산은 보여 주지 않습니다.
결정 기록은 이 정확도 문제를 운영으로 보정하겠다고 적었습니다. 자동화를 직접 매일 쓰면서 대조가 틀린 사례를 모아 규칙을 고치는 방식입니다. 이 방식은 비용이 들지 않지만, 틀린 사례를 기록하는 습관이 없으면 보정할 재료도 생기지 않습니다. 앞에서 본 재측정 공백과 같은 뿌리입니다. 자동화를 만든 뒤에도 사람에게는 결과를 적는 일이 남습니다.
X API 연동을 다음 버전으로 미룬 결정도 한계로 남습니다. 지금 구조는 글을 만드는 시간은 줄이지만, 그 글이 어떤 반응을 얻었는지는 사람이 따로 봐야 합니다. 시간 절감은 측정 범위 안에 있고, 효과 측정은 아직 범위 밖에 있습니다.
우리 회사 업무 자동화 ROI는 어떻게 계산하나?
이 사례를 다른 업무에 옮기려면 순서가 중요합니다. 먼저 하루 사용 시간을 범위로라도 적고, 7일을 곱해 주 단위로 바꿉니다. 그 숫자를 스스로 정한 상한이나 그 업무의 가치 옆에 세웁니다. 저희 경우에는 주 2시간 상한 옆에 주 6~9시간이 서자 결론이 바로 나왔습니다.
다음으로 구축 시간과 주간 절감 시간을 적어 회수 기간을 계산합니다. 여기까지는 누구나 하는 계산입니다. 그다음 단계가 빠지기 쉽습니다. 절감 효과가 어떤 정확도 위에 서 있는지 찾아 합격선으로 올리고, 실패하면 무엇을 할지 미리 정합니다. 저희는 검토 시간 10분 이하, 사실 대조 95% 이상, 보안 등급 위반 0건을 걸었습니다.
자동화 후보를 고를 때 저희가 쓰는 기준도 이 사례에서 나왔습니다. 판단 기준을 글로 적을 수 있는 업무부터 자동화합니다. 말투·글감·검증 순서처럼 사람이 매번 내리던 판단이 문서로 정리돼 있으면, AI는 그 문서를 읽고 같은 판단을 따라 합니다. 반대로 기준이 머릿속에만 있는 업무는 도구를 먼저 들여도 결과물을 사람이 다시 확인하느라 시간이 줄지 않습니다. 이럴 때는 자동화보다 기준을 적는 일이 먼저입니다.
마지막으로 재측정 결과를 적을 자리를 착수 전에 만들어 둡니다. 저희가 놓친 단계입니다. 같은 자동화를 Claude Code 슬래시 커맨드와 에이전트 설계 관점에서 정리한 글은 SNS 포스팅 자동화 기록에 있습니다. 반복 업무의 사람 시간을 재고 자동화 범위를 정하는 일을 함께 검토하고 싶다면 상담으로 이야기를 나눌 수 있습니다.
SGK Studio 개발팀. 이 글의 숫자는 2026년 4월 28일 확정한 자동화 결정 기록에서 가져왔습니다.