Loading the catalog…
Loading the catalog…
자동화는 코드가 아니라 업무 관찰에서 시작한다 자동화할 업무를 고르는 법 한 줄 요약 "코드로 만들 수 있을까?"보다 먼저 "이 업무에서 사람이 반복해서 내리는 판단은 무엇인가?" 를 물어야 한다. 게이트 3문항으로 걸러내고, 4가지 기준으로 평가한 뒤, 오류 비용에 맞춰 자동화 수준 을 정하면 만들고도 안 쓰이는 도구를 줄일 수 있다. i️ 이 글은 특정 회사나 서비스와 무관한 일반 방법론 입니다. 예시 업무는 모두 가상 이고, 숫자는 설명을 위한 가정 값입니다. 들어가며 반복 업무를 보면 자동화 욕심이 생깁니다. 그런데 막상 만들고 나면 이런 일이 자주 생깁니다. 만들었는데 아무도 쓰지 않는다 예외가 계속 나와서 수정에 더 많은 시간 이 든다 절감한 시간보다 만드는 데 쓴 시간 이 더 길다 만든 사람이 자리를 비우자 아무도 고치지 못한다 원인은 대부분 기술이 아니라 대상 선정 입니다. 어떤 업무를 자동화할지, 어느 수준까지 자동화할지를 먼저 정하지 않았기 때문입니다. 1. 먼저 손익을 계산해 본다 자동화에는 비용이 듭니다. 감이 아니라 대략이라도 계산해 보세요. 주당 절감 시간 = 1회 소요 시간 × 주당 횟수 × 사용자 수 손익분기(주) = 개발 시간 ÷ 주당 절감 시간 가정 예시입니다. 1회 40분 걸리는 업무를 주 2회, 한 명이 한다면 주당 80분을 절약합니다. 개발에 12시간(720분)이 들면 손익분기는 약 9주 입니다. 여기에 숨은 비용을 더하면 더 길어집니다. 숨은 비용 내용 예외 처리 규칙에 안 맞는 건을 따로 다루는 시간 유지보수 입력 형식·규칙이 바뀔 때마다 수정 권한·보안 접근 권한 관리, 키 관리, 점검 문서화·인수인계 만든 사람 외에도 쓸 수 있게 하는 시간 반대로 시간 외의 가치도 있습니다. 오류 감소 , 지연 감소 , 특정 사람에 대한 의존 감소 가 그 예입니다. 이런 가치는 숫자로 환산하기 어려우니 별도 항목으로 적어 두세요. 2. 업무를 먼저 관찰하고 분해한다 코드를 쓰기 전에 업무를 네 칸으로 나눕니다. 칸 질문 입력 어디서 오는가? 형식이 정해져 있는가? 처리 어떤 규칙으로 변환·계산하는가? 사람이 판단하는 부분은 어디인가? 출력 결과물은 무엇이고 누가 받는가? 후속 행동 결과를 받은 사람이 무엇을 하는가? 처리 상태는 어디에 남는가? 그리고 두 가지를 실제로 해봅니다. 한 번 직접 수행하며 단계를 기록 합니다. 머릿속 절차와 실제 절차는 다릅니다. 최근 20건 정도를 모아 예외가 몇 건인지 셉니다. 예외 비율이 규칙성의 가장 솔직한 지표입니다. 3. 선정 방법: 게이트 → 평가 → 판정 1 게이트 3문항 (하나라도 No면 보류) 질문 No라면 도구를 유지할 오너 가 있는가? 만든 사람이 떠나면 방치된다. 오너부터 정한다 프로세스가 한동안 안정적 인가? 곧 바뀔 업무를 자동화하면 폐기물이 된다. 안정화 후에 한다 결과를 검증할 방법 이 있는가? 틀려도 모르는 자동화는 위험하다. 검증 기준부터 만든다 2 4가지 기준으로 평가 기준 상 중 하 빈도 주 1회 이상 월 1~3회 분기에 1회 이하 소요 시간 1회 1시간 이상 20분~1시간 20분 미만 규칙성 기준이 명문화되고 예외가 적다 기준은 있으나 예외가 꽤 있다 사람마다 판단이 다르다 입력 정형성 표·폼처럼 구조화되어 있다 일부 정리가 필요하다 자유 서술, 이미지, 스캔본 여기에 오류 비용 (틀리면 얼마나 아픈가)을 따로 봅니다. 이 항목은 점수가 아니라 자동화 수준 을 정하는 데 씁니다. (4장에서 설명합니다) 3 판정 평가 결과 판정 빈도·소요 시간 높음 + 규칙성·입력 정형성 높음 규칙 기반 자동화 빈도·소요 시간 높음 + 입력이 비정형 (규칙으로 쓰기 어려움) AI 보조 + 사람 확인 빈도·소요 시간 높음 + 판단 기준이 사람마다 다름 기준·프로세스 정리가 먼저 빈도가 낮거나 소요 시간이 짧음 자동화하지 않고 체크리스트로 가상의 업무 네 가지에 적용해 보면 이렇습니다. 업무 (가상) 빈도 소요 규칙성 입력 오류 비용 판정 주간 실적 취합·리포트 작성 상 상 상 상 중 규칙 기반 자동화 문의 메일 1차 분류 상 중 하 하 하 AI 보조 + 사람 확인 담당자마다 방식이 다른 월간 보고 중 상 하 중 중 기준 정리가 먼저 연 1회 감사 대응 자료 정리 하 상 중 중 상 체크리스트로 충분 💡 세 번째 업무가 중요한 사례입니다. 기준이 사람마다 다른 업무를 자동화하면, 그 혼란이 그대로 빠르게 반복됩니다. 자동화는 나쁜 프로세스를 고쳐 주지 않고 더 빠르게 만들 뿐입니다. 4. 자동화 수준을 정한다 "자동화할 것인가 말 것인가"의 이분법이 아니라 어디까지 맡길 것인가 를 정합니다. 수준 설명 사람의 역할 L0 수동 전부 사람이 한다 전부 L1 문서화 절차를 체크리스트·템플릿으로 정리한다 실행과 판단 L2 반자동 도구가 집계·초안을 만들고 사람이 확인·승인한다 확인과 승인 L3 자동 + 예외 알림 도구가 실행하고 예외만 사람에게 넘긴다 예외 처리 L4 완전 자동 사람 개입 없이 실행하고 로그만 남긴다 주기적 점검 오류 비용이 수준을 결정합니다. 오류 비용 권장 수준 낮음 (틀려도 쉽게 고침) L3 이상 중간 L2~L3 (결과를 확인하는 단계 유지) 높음 (금전·신뢰·법적 문제) L2 이하. 최종 승인은 사람이 한다 대부분의 업무에서 L2~L3이 가장 현실적 입니다. 처음부터 L4를 목표로 하면 예외 처리 때문에 끝나지 않는 프로젝트가 됩니다. AI는 어디에 쓰는가 작업 규칙으로 AI로 정해진 형식의 표 계산·변환 ✅ ❌ (결정적이고 싸고 검증이 쉽다) 자유 서술 분류·요약·정보 추출 ❌ (규칙으로 쓰기 어렵다) ✅ (단, 사람 확인 포함) 금액·수량 같은 정확도가 필수인 계산 ✅ ❌ (결과가 매번 다를 수 있다) 초안 작성 △ ✅ (사실 확인은 사람이) 규칙으로 되는 일에 AI를 쓰면 비용이 늘고 결과를 재현하기 어려워집니다. AI는 규칙으로 못 푸는 비정형 입력에 쓰고, 그 결과는 반드시 검증 단계를 거치게 하세요. 5. 만들 때 지킬 설계 원칙 원본을 보존하고 로그를 남깁니다. 결과가 이상할 때 되짚을 수 있어야 합니다. 입력을 구조화합니다. 자유 메시지 대신 정해진 양식으로 받으면 오류의 절반이 사라집니다. 예외를 숨기지 않고 사람에게 넘깁니다. 처리 못 한 건을 조용히 버리는 자동화가 가장 위험합니다. 가장 흔한 케이스부터 만듭니다. 전체의 70~80%를 덮고, 나머지는 예외 큐로 보냅니다. 규칙과 코드를 분리합니다. 기준이 바뀔 때 코드가 아니라 설정 파일이나 표만 고치게 합니다. 되돌릴 수 있게 만듭니다. 실행 전 미리보기, 중복 실행해도 문제없는 구조를 선호합니다. 권한은 최소로, 키는 코드 밖에 둡니다. 접근 정보를 코드에 직접 넣지 않습니다. 오너와 문서를 지정합니다. 개인 PC에서만 도는 스크립트는 자동화가 아니라 개인 습관입니다. 6. 도입 후에 할 일 전후를 측정합니다. 소요 시간, 오류 발생 건수, 예외 비율, 실제 사용 횟수를 기록하세요. 추정치와 실측치를 구분해서 말합니다. "약 N분 줄 것으로 추정"과 "실측 N분 감소"는 다른 말입니다. 범위로 말하고, 업무 조건에 따라 달라진다는 점을 함께 적으세요. 2~4주 뒤 사용 현황을 점검합니다. 쓰이지 않는다면 이유를 묻고, 개선하거나 폐기합니다. 규칙이 바뀔 때의 대응 절차를 정합니다. 누가 언제 수정하는지 미리 정해 두세요. 7. 흔한 안티패턴 안티패턴 문제 처방 사용자 없이 만든다 만들고 나서 안 쓴다 업무 담당자와 함께 관찰하고, 초기 버전을 같이 써 본다 일회성 업무를 자동화한다 손익분기가 오지 않는다 빈도 기준을 먼저 본다 예외를 무시한다 자동화가 오히려 오류를 늘린다 예외 비율을 측정하고 예외 큐를 만든다 블랙박스로 만든다 결과를 검증할 수 없다 중간 산출물과 로그를 남긴다 AI를 과하게 쓴다 비용·비재현성·오류가 늘어난다 규칙으로 되는 곳은 규칙으로 절감 시간을 과장한다 신뢰를 잃는다 실측과 추정을 구분한다 프로세스를 안 고치고 자동화한다 나쁜 방식이 굳는다 기준 정리를 먼저 한다 8. 체크리스트 도구를 유지할 오너가 있는가 프로세스가 당분간 안정적인가 결과를 검증할 방법이 있는가 직접 한 번 수행하며 단계를 기록했는가 최근 건을 모아 예외 비율을 확인했는가 빈도 · 소요 시간 · 규칙성 · 입력 정형성을 평가했는가 손익분기(개발 시간 ÷ 주당 절감 시간)를 대략 계산했는가 오류 비용에 맞는 자동화 수준(L2~L3 등)을 정했는가 규칙으로 되는 곳과 AI가 필요한 곳을 구분했는가 원본 보존, 로그, 예외 큐, 설정 분리를 설계에 넣었는가 도입 전후 측정 방법과 점검 날짜를 정했는가 마무리 좋은 자동화는 사람이 하던 일을 없애는 것이 아니라, 반복적인 조회와 전달을 줄이고 사람이 판단과 처리에 집중할 수 있게 만드는 일입니다. 그러려면 만들기 전에 두 가지를 먼저 답해야 합니다. "이 업무는 자동화할 가치가 있는가?" 그리고 "어디까지 맡길 것인가?"
What RADAR observed and classified to build this opportunity. It is what the source published, not a verification that the offer is still active.
자동화할 업무를 고르는 법. 자동화는 코드가 아니라 업무 관찰에서 시작한다 자동화할 업무를 고르는 법 한 줄 요약 "코드로 만들 수 있을까?"보다 먼저 "이 업무에서 사람이 반복해서 내리는 판단은 무엇인가?" 를 물어야 한다. 게이트 3문항으로 걸러내고, 4가지 기준으로 평가한 뒤, 오류 비용에 맞춰 자동화 수준 을 정하면 만들고도 안 쓰이는 도구를 줄일 수 있다. i️ 이 글은 특정 회사나 서비스와 무관한 일반 방법론 입니다. 예시 업무는 모두 가상 이고, 숫자는 설명을 위한 가정 값입니다. 들어가며 반복 업무를 보면 자동화 욕심이 생깁니다. 그런데 막상 만들고 나면 이런 일이 자주 생깁니다. 만들었는데 아무도 쓰지 않는다 예외가 계속 나와서 수정에 더 많은 시간 이 든다 절감한 시간보다 만드는 데 쓴…
Open source