업무 자동화 프로그램 2026 — 직접 만들기 vs 외주, 파이썬으로 되는 선 7단계

# 업무 자동화 프로그램 2026 — 직접 만들기 vs 외주, 파이썬으로 되는 선 7단계

자동화는 만드는 것보다 유지하는 게 어렵다

업무 자동화를 검색하면 대부분 「파이썬으로 만드는 법」이 나온다. 실제로 엑셀 정리나 웹 데이터 수집은 하루면 돌아가는 스크립트가 나온다. 그건 사실이다.

문제는 그다음이다.

• 만든 사람이 부서를 옮기면 아무도 못 고친다
• 웹사이트 구조가 바뀌면 조용히 멈추는데, 멈춘 걸 아무도 모른다
• 한 사람 PC에서만 돌아서 그 사람이 휴가면 업무도 멈춘다
• 처리 결과가 틀렸을 때 어디서 틀렸는지 추적이 안 된다

자동화의 실패는 「안 만들어져서」가 아니라 「만들었는데 관리가 안 돼서」 일어난다. 그래서 직접 만들지 외주로 넘길지는 기술 난이도가 아니라 누가 몇 년간 책임질 것인가로 갈린다.

직접 만들어도 되는 것 — 세 조건을 다 만족할 때

아래 셋이 전부 참이면 직접 만드는 게 맞고, 하나라도 어긋나면 다시 생각한다.

전형적으로 여기 해당하는 것들이다.

• 매달 받는 엑셀 여러 개를 한 파일로 합치기
• 특정 사이트에서 가격·재고를 하루 한 번 긁어 스프레드시트에 넣기
• 정해진 폴더의 파일 이름 규칙 맞추기
• 반복되는 보고서 양식에 숫자만 채워 넣기

⚠️ 위 셋 중 「틀려도 되나」가 가장 자주 잘못 판단된다. 자동화가 조용히 잘못된 값을 넣기 시작하면, 사람이 하던 때보다 훨씬 오래 발견되지 않는다. 사람은 이상하면 멈추지만 스크립트는 계속 돈다.

판단할 때 이렇게 물으면 정확해진다. 「이 값이 3주 동안 틀려 있었다면 무슨 일이 벌어지나」. 답이 「그냥 다시 돌리면 된다」면 직접 만들어도 되고, 「거래처에 이미 나갔다」거나 「그 숫자로 의사결정을 했다」면 넘겨야 한다.

그리고 「혼자 쓰나」도 시간이 지나면 깨진다. 유용한 자동화는 옆 팀이 쓰겠다고 한다. 그 순간 조건이 바뀐 것인데 도구는 그대로라 문제가 시작된다.

넘겨야 하는 신호 6가지

하나라도 해당하면 직접 만들기의 비용이 급격히 오른다.

마지막 항목이 실제로 가장 많이 터진다. 대부분의 사내 자동화는 잘 만들어졌는데 담당자가 옮기면서 죽는다. 코드가 남아 있어도 아무도 손을 못 댄다 — 문서가 없고, 어디서 도는지도 모르고, 고치다 망가뜨릴까 봐 그냥 수동으로 돌아간다.

이걸 미리 막는 방법은 기술이 아니라 절차다. 만든 사람이 한 번도 손대지 않고 다른 사람이 실행해 보게 한다. 그 자리에서 막히는 지점이 곧 문서에 빠진 부분이고, 대개 「환경 변수를 어디서 받나」와 「실패하면 어디를 보나」 둘이다.

⚠️ 「개인정보를 다룬다」도 과소평가된다. 고객 명단을 로컬 PC의 CSV로 내려받아 스크립트를 돌리는 순간, 그 PC가 관리 대상이 된다. 분실·유출 시 책임이 개인에게 간다.

파이썬 스크립트로 되는 선

기술적으로는 대부분 된다. 문제는 「되는가」가 아니라 「몇 년 굴러가는가」다.

자주 깨지는 지점

웹 수집이 특히 그렇다. 대상 사이트가 화면을 바꾸면 조용히 멈추거나, 더 나쁘게는 엉뚱한 값을 가져온다.

```

정상 가격 셀을 찾아 12,000 을 읽음

변경 구조가 바뀌어 옆 칸의 배송비 3,000 을 읽음

결과 숫자가 나오니 에러도 안 나고, 한 달 뒤에 발견됨

```

그래서 자동화에는 「값이 이상하면 멈추는」 장치가 필요하다. 직접 만들 때 가장 자주 빠지는 부분이고, 이게 없으면 자동화가 사람보다 위험해진다.

간단한 것부터 넣는다.

```

• 결과 건수가 평소의 절반 이하면 중단하고 알림
• 숫자 필드에 예상 범위를 두고 벗어나면 중단
• 마지막 실행 시각을 기록하고, 하루 넘으면 알림

```

이 세 줄이 자동화의 신뢰도를 대부분 결정한다. 「성공했다」를 알리는 것보다 「평소와 다르다」를 알리는 게 중요하다 — 매일 오는 성공 알림은 2주면 아무도 안 본다.

건수 기준이 특히 유용하다. 대상 사이트가 바뀌면 대개 0건이 되거나 절반으로 줄고, 그건 값을 검증하는 것보다 훨씬 만들기 쉬우면서 대부분의 사고를 잡는다.

RPA 와 스크립트는 다른 도구다

둘 다 「자동화」로 묶이지만 쓰는 자리가 다르다.

API 가 있으면 스크립트가 낫다. RPA 는 「API 가 없어서 화면을 클릭할 수밖에 없을 때」 쓰는 우회로다. API 가 있는데 RPA 로 화면을 긁으면 더 잘 깨지고 더 비싸다.

⚠️ RPA 도 사람이 클릭하던 걸 그대로 옮기면 실패한다. 비효율적인 절차를 자동화하면 비효율이 빨라질 뿐이다. 자동화 전에 그 절차가 필요한지 먼저 묻는다.

실무에서 자주 나오는 경우가 있다. 두 시스템 사이에서 사람이 복사·붙여넣기를 하고 있는데, 그건 원래 연동으로 풀 문제다. RPA로 그 손동작을 흉내 내면 매년 라이선스를 내면서 화면이 바뀔 때마다 고쳐야 한다. 연동이 가능한지 먼저 확인하고, 정말 불가능할 때만 RPA로 간다.

무엇부터 자동화할지 고르는 법

「가장 귀찮은 것」부터 하면 대개 실패한다. 귀찮은 일은 대체로 판단이 많이 들어가서 자동화가 어렵다.

빈도 × 규칙성으로 고른다.

분기에 한 번 하는 일을 자동화하지 마라. 만드는 시간이 앞으로 3년치 수동 작업 시간보다 길고, 게다가 분기마다 도는 스크립트는 다음 실행 때 이미 깨져 있다. 석 달 사이에 대상 시스템도 바뀌고 만든 사람도 사용법을 잊는다.

계산해 보면 명확하다. 매주 30분 걸리는 일은 1년에 26시간이라 하루짜리 자동화가 금방 회수된다. 분기 1회 2시간짜리는 1년에 8시간뿐이라, 만드는 데 이틀이 들면 3년을 써야 본전이고 그전에 깨진다.

부분 자동화가 정답인 경우가 많다

전부 자동화하려다 실패하는 것보다, 사람이 판단하는 지점만 남기고 나머지를 자동화하는 편이 오래 간다.

```

❌ 전부 자동 수집 → 판단 → 처리 → 발송

✅ 부분 자동 수집 → [사람이 확인·판단] → 처리 → 발송

```

특히 외부에 나가는 것(메일·문자·API)은 사람의 확인 한 단계를 남기는 것이 안전하다. 하루 30초를 쓰고 사고를 막는다.

확인 단계를 넣을 때는 바로 보내지 말고 초안을 쌓아두는 형태가 낫다. 스크립트가 발송 대상과 내용을 만들어 목록에 넣고, 사람이 훑어보고 「발송」을 누른다. 이렇게 하면 이상한 건이 섞여 있을 때 그 한 건만 빼면 되고, 전체를 멈출 필요가 없다.

그리고 부분 자동화는 나중에 전체 자동화로 옮기기 쉽다. 몇 달 돌려보면 사람이 실제로 무엇을 보고 판단하는지가 드러나고, 그게 규칙으로 정리되면 그때 그 단계를 넘긴다.

외주로 넘길 때 비용·기간

국내에서 통상 형성되는 범위다. 대상 시스템과 예외 처리 범위에 따라 달라진다.

견적을 가르는 건 자동화 자체가 아니라 예외 처리다. 「정상 흐름만」과 「예외까지」는 2배 이상 차이 난다. 그리고 예외 처리 없는 자동화는 위에서 본 대로 사람보다 위험하다.

발주 문서를 어떻게 준비하는지는 요구사항 정의서 작성법에, 기능 단위로 범위를 세는 법은 기능 정의서 작성법에 정리했다.

넘길 때 반드시 정할 것

⚠️ 마지막 항목을 계약서에 안 적으면 반드시 분쟁이 난다. 외부 사이트 구조 변경은 개발사 잘못도 발주처 잘못도 아닌데, 누가 고칠지가 안 정해져 있다.

실무적으로는 연 단위 대응 횟수를 정해두는 방식이 무난하다. 「외부 대상 변경으로 인한 수정은 연 4회까지 하자보수 범위, 초과분은 건당 얼마」처럼 숫자로 적으면 양쪽 다 예측이 된다. 이걸 안 적으면 첫 번째 변경에서 감정이 상한다.

실패하는 자동화의 공통점

① 문서가 없다

어디서 도는지, 뭘 하는지, 실패하면 어떻게 되는지가 만든 사람 머릿속에만 있다.

② 알림이 없다

멈춰도 아무도 모른다. 한 달 뒤 「그거 요즘 안 되던데요」로 발견된다. 그리고 그 한 달치 데이터는 대개 복구가 안 된다.

③ 예외 처리가 없다

정상 흐름만 만들어져 있어서 조용히 틀린 값을 넣는다.

④ 절차를 그대로 옮겼다

비효율적인 수동 절차를 자동화하면 비효율이 빨라진다.

⑤ 담당자가 한 명이다

가장 흔하고 가장 치명적이다. 최소한 어떻게 돌리는지 아는 사람이 두 명이어야 한다.

판단 7단계

```

[ ] 1. 이 절차가 애초에 필요한가 (없애는 게 최선)

[ ] 2. 빈도 확인 — 매일·매주가 아니면 우선순위를 내린다

[ ] 3. 넘기는 신호 6가지 점검 (돈·다수·외부·개인정보·업무정지·1인)

[ ] 4. 전부 vs 부분 — 판단이 들어가면 사람을 남긴다

[ ] 5. 직접 만들면: 이상값 감지와 알림을 먼저 넣는다

[ ] 6. 외주면: 어디서 도나 · 멈추면 누가 아나 · 로그 · 소스 인도 확정

[ ] 7. 아는 사람을 두 명으로 만든다

```

AI-Native 팀이 자동화를 다루는 방식

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 자동화에서 어려운 것은 만드는 일이 아니라 깨졌을 때 알아채는 구조를 만드는 일이다.

• 예외 케이스 도출 — 정상 흐름에서 빠질 수 있는 경우(값 없음·형식 변경·건수 급감)를 뽑아 감지 조건으로 만든다
• 기존 스크립트 인수 — 담당자가 떠나 문서 없이 남은 스크립트를 읽어 무엇을 하는지·어디서 깨지는지 정리한다
• 모니터링 자동 구성 — 실행 이력과 결과 건수를 기록해 평소와 다른 날을 잡아낸다

자동화의 가치는 만든 순간이 아니라 2년 뒤에도 돌고 있는가로 판가름난다. 감지와 문서화를 자동화해 사람이 업무 판단에 집중하게 만드는 것이 AI-Native 개발 방식의 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

파이썬을 배워서 직접 만드는 게 낫지 않나요?

혼자 쓰고, 틀려도 알아채고, 멈춰도 되는 일이면 그렇다. 그 셋 중 하나라도 어긋나면 만드는 비용보다 유지하는 비용이 크다.

챗GPT로 스크립트를 만들면 되지 않나요?

코드는 나온다. 다만 깨졌을 때 고칠 수 있는지가 문제다. 만들 때는 도움이 되지만, 2년 뒤 그 코드를 이해할 사람이 필요한 건 그대로다.

RPA 도구를 사는 게 나을까요?

API가 없어서 화면을 클릭할 수밖에 없을 때만 그렇다. API가 있으면 스크립트가 더 안정적이고 싸다.

자동화했는데 오히려 일이 늘었습니다.

대개 예외 처리가 없어서다. 자동화가 처리 못 하는 건이 쌓이면 사람이 그걸 따로 처리하게 되고, 결국 두 가지 흐름을 관리하게 된다. 예외 비율이 20%를 넘으면 자동화 범위를 좁히는 편이 낫다.

얼마나 자주 깨지나요?

외부 사이트를 긁는 것은 분기에 한 번쯤 손이 간다고 보면 된다. 사내 시스템만 다루면 훨씬 안정적이다. 다만 사내 시스템도 업그레이드하면 한 번에 여러 자동화가 같이 멈추니, 어떤 자동화가 어느 시스템에 의존하는지 목록으로 갖고 있어야 그때 무엇을 점검할지 안다.

정리

업무 자동화는 만드는 난이도가 아니라 유지 책임으로 갈린다.

실무에서 결과를 가르는 지점은 셋이다.

1. 넘기는 신호 6가지 중 몇 개에 해당하나 — 돈·다수·외부·개인정보·업무정지·1인 담당
2. 이상값 감지와 알림이 있나 — 없으면 자동화가 사람보다 위험하다
3. 아는 사람이 두 명인가 — 대부분의 사내 자동화는 담당자가 옮기면서 죽는다

이 셋만 챙기면 직접 만들든 외주로 넘기든 2년은 간다.