도구만 바꾸고 일은 그대로 두면 돈은 안 번다, 업무 자동화 100년 삽질사

Apollo 수석 이코노미스트가 AI 투자는 넘쳐나는데 빅테크 7개 바깥의 493개 회사에선 매출도 마진도 그대로라고 썼다. 개발자들 댓글은 “원래 이런 건 늦게 나온다”가 대세다. 그 말이 맞는지 보려면 업무 자동화가 예전엔 어떻게 굴러갔는지부터 봐야 한다.

도구를 사다 놓는 것과 일하는 방식이 바뀌는 것은 다른 사건이고, 돈은 뒤쪽에서 나온다. 자동화는 “규칙으로 쓸 수 있는 부분”만 먹고, 규칙으로 안 써지는 판단은 계속 사람 몫으로 남는다. LLM은 그 판단 영역을 처음으로 건드리는 도구지만, 책임을 지는 주체가 아니라는 점은 안 바뀌었다.

장부 시대는 느렸지만 책임자가 있었다

컴퓨터가 사무실에 들어오기 전에는 주문, 급여, 재고가 전부 종이 장부였다. 계산은 사람이 하고, 틀리면 다른 사람이 검산했다. 느리고 비쌌지만 구조가 단순했다. 장부마다 담당자가 있었고, 사고가 나면 누구 이름을 부를지 정해져 있었다.

더 중요한 건 이 시대의 업무에는 문서에 안 적힌 규칙이 잔뜩 섞여 있었다는 점이다. “김 과장 거래처는 월말에 몰아서 처리한다”, “이 금액 넘으면 부장님한테 한 번 더 물어본다” 같은 것들이다. 이런 규칙은 매뉴얼에 없고 사람 머릿속에 있었다. 이게 나중에 자동화할 때 계속 발목을 잡는다.

그럼 처음부터 전부 컴퓨터로 옮기면 되지 않았냐고? 못 옮겼다. 규칙이 어디 적혀 있는지 아무도 몰랐기 때문이다. 자동화는 “규칙을 글로 쓸 수 있는 부분”부터 먹기 시작했고, 이 순서가 지금까지 이어진다.

그때 방식 그대로 짜보면

장부 시절 업무를 코드로 옮기면 이런 모양이다. 한 묶음의 주문을 읽어서, 규칙으로 처리 가능한 건 자동 승인하고 나머지는 사람 큐로 보낸다. 메인프레임 배치 작업이 하던 일의 축소판이다.

# Python 3.x, 표준 라이브러리만 사용
import csv, io

RAW = """id,customer,amount,note
1,kim,12000,
2,lee,-3000,환불요청
3,park,450000,
4,choi,8000,어제 전화로 깎아주기로 함
"""

LIMIT = 100_000
approved, review = [], []

for row in csv.DictReader(io.StringIO(RAW)):
    amount = int(row["amount"])
    # 규칙으로 쓸 수 있는 것만 자동 처리
    if amount < 0 or row["note"] or amount > LIMIT:
        review.append(row)      # 사람이 봐야 하는 것
    else:
        approved.append(row)

print("자동 승인:", [r["id"] for r in approved])
print("사람 확인:", [(r["id"], r["note"] or "금액") for r in review])

여기서 아픈 지점은 이렇다.

• 규칙은 if 한 줄이지만 그 규칙이 맞는지는 코드 어디에도 없다. 4번 주문의 “전화로 깎아주기로 함”은 사람이 읽어야만 의미가 생긴다.
• 사람 큐(review)가 자동화의 진짜 병목이다. 예외가 늘면 자동화 비율은 올라가 보여도 사람 일은 안 줄어든다.
• 한도 LIMIT을 누가 왜 10만으로 정했는지 아무도 모른다. 몇 년 뒤엔 규칙이 근거 없이 굳는다.

그래서 어떻게 진화했나

먼저 전체 흐름을 한 번 보고 가자. 아래 그림은 화살표를 따라 왼쪽에서 오른쪽으로, 각 단계가 앞 단계의 불편에서 나왔다는 걸 보여주는 개념도(실제 연도 아님)다.

flowchart LR
    A["종이 장부"] --> B["메인프레임 배치"]
    B --> C["클라이언트 서버 + DB"]
    C --> D["스프레드시트"]
    D --> E["ERP와 SaaS"]
    E --> F["LLM 에이전트"]

1단계. 종이에서 배치로. 불편은 계산이 느리고 틀린다는 것이었다. 해법은 큰 컴퓨터에 데이터를 모아 밤새 한꺼번에 돌리는 배치 처리였다. 새 문제는 현장 사람이 결과를 보려면 다음 날까지 기다려야 하고, 프로그램을 고치려면 전산 부서에 요청해야 한다는 것이었다. 업무를 아는 사람과 코드를 쓰는 사람이 갈라졌다.

2단계. 데이터베이스와 클라이언트 서버. 불편은 파일이 부서마다 따로 있어서 같은 고객이 세 군데에 다른 모양으로 있다는 것이었다. 해법은 관계형 DB에 데이터를 모으고 화면 프로그램이 거기 붙는 구조였다. 새 문제는 화면 하나 바꾸는 데도 개발 일정이 잡혀야 한다는 것이었다. 현장은 이 속도를 못 기다렸다.

3단계. 스프레드시트. 불편은 전산 부서를 기다리기 싫다는 것이었다. 해법은 현장 담당자가 직접 수식을 짜는 표 계산 프로그램이었고, 이게 의외로 업무 자동화의 가장 큰 승리였다. 새 문제는 “그 파일 누가 만들었는지 모른다”로 요약된다. 수식이 틀려도 검증할 길이 없고, 최종본이 어느 파일인지도 모르는 일이 생겼다.

4단계. ERP와 SaaS. 불편은 스프레드시트 지옥이었다. 해법은 회계, 재고, 인사를 한 시스템에 넣고 업무 방식을 시스템에 맞추는 것이었다. 새 문제는 시스템이 요구하는 방식에 회사가 맞춰야 한다는 점이다. 도입 프로젝트가 몇 년씩 걸리고, 예외 업무는 결국 다시 스프레드시트로 돌아갔다.

여기까지 한 줄로 정리하면 이렇다. 각 세대가 앞 세대의 비효율을 지웠지만, 예외와 판단은 매번 사람에게 남았다.

시대	방식	장점	한계
종이 장부	사람이 계산하고 검산	책임자가 명확함	느리고 비쌈
배치 처리	밤새 일괄 계산	대량 계산이 빠름	현장과 개발이 분리됨
DB와 화면	데이터 한곳에 모음	중복과 불일치 감소	변경이 느림
스프레드시트	현장이 직접 수식 작성	속도와 자율성	검증과 관리가 불가능
ERP와 SaaS	업무를 시스템에 맞춤	표준화	도입 비용, 예외 처리 약함

표는 위에서 아래로 갈수록 최근이고, 마지막 열이 다음 행이 생긴 이유다.

전기 모터를 물레방아 자리에 꽂았더니

이쯤에서 HN 댓글 하나가 정확히 맞는 얘기를 한다. 물레방아로 돌아가던 방앗간에 전기 모터를 사다 놓았다고 바로 생산성이 오르진 않았다. 물레방아는 건물 밖에 있고, 동력은 천장의 긴 축과 벨트로 기계에 나눠졌다. 모터를 그 자리에 그대로 끼우면 같은 구조에 힘만 다른 셈이다.

아래 그림은 왼쪽이 중앙 동력 하나에 벨트로 매달린 옛 공장, 오른쪽이 기계마다 모터를 단 공장이다. 오른쪽이 되어야 배치를 마음대로 바꿀 수 있다는 걸 보여주는 개념도(실제 수치 아님)다.

여기서 의문이 하나 생긴다. 모터가 더 효율적이면 바로 그 효과가 나와야 하는 거 아니냐는 것이다. 안 나온 이유는 효율이 모터에 있지 않고 공장 배치에 있었기 때문이다. 기계를 일의 흐름대로 놓으려면 건물을 새로 짓고 작업 순서를 다시 짜야 했고, 그건 돈과 시간이 드는 일이었다.

컴퓨터도 똑같이 지나갔다. 80년대 후반에 이미 “컴퓨터는 어디서나 보이는데 생산성 통계에서만 안 보인다”는 말이 돌았다고 한다. 업무를 종이 결재 그대로 두고 화면만 전자결재로 바꾸면 속도만 조금 빨라질 뿐이다. 업무 흐름을 다시 짜는 회사가 나온 뒤에야 숫자가 달라졌다.

지금은 어떤가

오늘 기사 내용은 단순하다. 빅테크 7개는 직원당 매출과 마진이 오르는데 나머지 493개는 평평하고, 생산성 통계에도 아직 변화가 없다. 일반 기업은 토큰 비용을 성장 투자가 아니라 마진을 깎는 비용으로 보기 시작했다는 얘기다. 위의 전기 모터 이야기로 보면 놀랍지 않은 숫자다.

읽는 법: 기사가 말한 7개와 493개의 비율이다. 오르는 쪽은 전체의 1.4%뿐이라 평균 통계에는 거의 안 잡힌다.

다만 댓글 중 반대 의견도 있다. 쓸 만한 모델이 나온 지 아직 1년이 안 됐으니 너무 이르다는 것이다. 이 주장은 타당하다. 반면 “생산성 이득이 전부 AI 회사 매출로 잡히는 구조”라는 댓글도 만만치 않다. 둘 다 지금 데이터로는 확인이 안 되니, 어느 쪽이 맞는지는 모른다고 적어두는 게 맞다.

그럼 LLM은 앞선 세대와 뭐가 다르냐. 이전 도구들은 “규칙을 글로 쓸 수 있는 일”만 먹었다. 위 코드에서 4번 주문의 “전화로 깎아주기로 함” 같은 문장은 if로 못 풀어서 사람 큐로 갔다. LLM은 처음으로 그 문장을 읽고 요약하고 분류하는 일을 한다. 그래서 사람 큐 앞단의 비용이 실제로 줄 수 있다.

하지만 기사 저자가 짚은 한계도 같은 자리에 있다. 읽는 것과 책임지는 것은 다르다. 환불을 해줄지, 깎아주겠다는 약속을 인정할지는 회사의 암묵적 규칙, 신뢰, 평판 위험이 얽힌 결정이다. 모델은 그 대가를 치르지 않고, 같은 질문에도 어떤 모델에게 묻느냐에 따라 답이 달라진다. 결국 review 큐는 사라지지 않고 모양만 바뀐다.

선택지를 비교하면 이렇다.

• 기존 업무에 챗봇만 붙이기: 가장 싸고 가장 빨리 하지만, 물레방아 자리에 모터를 끼우는 방식이라 숫자는 거의 안 움직인다.
• 업무 흐름 자체를 다시 짜기: 돈과 시간이 들고 실패도 많지만, 과거 전기화와 컴퓨터화에서 이득이 나온 쪽은 이쪽이다.
• 모델 비용을 계속 줄이며 기다리기: 가격은 내려가겠지만 결국 흐름을 못 바꾸면 싼 계산기를 쥔 채 같은 자리에 있게 된다.

이번 사이클에서 돈이 어디로 가는지는 아직 기사 하나로 못 박을 수 없다. 다만 과거 두 번은 도구를 산 쪽이 아니라 일하는 방식을 바꾼 쪽이 먹었고, 이번이라고 그 순서가 뒤집힐 근거는 아직 못 봤다.

---

원문: No signs of AI payoff outside the tech sector (via hn)