AI. vs 사람 맡길 일 고르는 기준 4가지

요즘 AI로 무엇을 만들고 계신가요? 

반복 업무를 덜어 줄 스크립트 몇 개, 팀에서 같이 쓰는 도구 한두 개를 만들 수도 있고, 뭐든지 에이전트에게 통째로 넘겨 보기도 하죠. 그런데 맡기는 범위가 넓어질수록 다른 고민이 생깁니다. 같은 일을 돌릴 때마다 결과가 달라지고, “완료”라는 보고를 믿었다가 빠진 곳을 뒤늦게 발견하고, 만들어 둔 도구는 늘었는데 계속 손이 가는 건 몇 개 안 됩니다. 이제는 정말 ‘이것도 돼?’를 넘어서, 어디까지 맡기고 어떤 건 내가 꼭 해야 하는지를 정해야 할 때입니다.

이 질문에 딱 맞아 떨어지는 정답은 없습니다. 그래도 먼저 맡겨 보고, 자기만의 기준을 갖게 된 경험과 사고 과정을 기록해둔 사람들이 요즘IT에 있습니다. 매달 400페이지 점검철을 넘기던 사업관리 담당자, 웹페이지 진단 서비스를 만드는 팀, 법률 AI 서비스를 만든 디자이너, 5년 차 라이브 게임 조직의 기획자, 구현과 검증을 통째로 AI에게 맡겨 본 프론트엔드 개발자까지, 직무나 업무는 제각각입니다. 하지만 맡길 것과 맡기지 않을 것의 기준은 모두가 비슷했습니다.

이 글에서는 요즘IT에 2026년 5월부터 10월까지 실린 글 가운데, AI에 무엇을 맡기고, 무엇을 맡기지 않을지를 고민하고 나름의 기준을 만든 사례 아홉 편을 분석해 그 기준을 네 가지로 정리했습니다.

• AI에게 맡길 가치가 있는 것을 맡긴다
• 정해진 답이 있는 일은 AI의 판단이 아닌 규칙으로 만든다
• 되돌리기 어려운 결정은 맡기지 않는다
• 언제 어디서 확인할지를 설계한다

1. AI에게 맡길 가치가 있는 것을 맡긴다

AI 자동화 이야기는 대개 “어떻게 만드나”에서 시작합니다. 그런데 먼저 해 본 사람들이 가장 오래 고민한 건 그보다 한 단계 앞이었습니다. 코딩이 본업이 아닌 사업관리 담당자 아이엠 조차장 작가는 넉 달 동안 업무 도구 열두 개를 만들고 나서야 “진짜 어려운 건 코드를 짜는 일이 아니라 손댈 일을 고르는 일”이라는 걸 알았다고 합니다.

작가가 세운 기준은 네 가지입니다.

• 얼마나 자주 하는가
• 한 번에 얼마나 오래 걸리는가
• 틀리면 얼마나 위험한가
• 다시 쓸 수 있는가

매달 마감 때마다 400페이지가 넘는 점검철 스캔본을 넘기며 서명이 빠진 곳을 찾는 일이 있었습니다. 할 때마다 30분~1시간이 걸리고, 하나만 놓쳐도 마감이 틀어지는 일이었죠. 이 일은 기준 네 가지 중 1~3번에 해당했습니다. 그래서 가장 먼저 만들었습니다. 하지만 1년에 한두 번 하는 다른 작업은 만들 수 있었지만 만들지 않았습니다.

무엇을 만들지 골랐다고 해도 그걸 꼭 AI로 만들어야 하는 건 아닙니다. 게임 스튜디오에서 마케팅, 사업, 피플까지 맡고 있는 김현민 님은 코딩 에이전트 활용 사례를 공유하는 요즘IT의 클코나잇2(현 빌더나잇) 발표에서 “결국 AI는 도구이고, 문제 정의 역량이 중요하다.”고 강조했습니다.

그는 모든 것을 처음부터 클로드 코드로 해보지 않았습니다. 앱스크립트나 n8n으로 충분한 자동화도 많았기 때문입니다. 다만 매번 같은 환경 변수를 반복해 세팅해야 할 만큼 프로젝트가 늘어났을 때 비로소 클로드 코드가 필요하다고 느꼈다고 합니다. 그래서 “기존에 잘 돌아가고 있는 것을 꼭 클로드 코드로 다시 만들어야 할까”를 한 번씩 물어보라고 권합니다.

조직에서도 고르는 순서는 비슷했습니다. 라이브 게임 조직에서 일한 수께끼수 작가는, 데이터와 코드가 오래 얽힌 서비스에서는 큰 문제일수록 연관된 부분이 많아 손댔다가 다른 곳까지 흔들기 쉽다고 봅니다. 그래서 “가장 작은 것부터, 가장 귀찮은 것부터” 맡겼습니다. 엑셀 입력 실수를 줄이는 일, 코드를 분석해 유지보수 문서를 최신화하는 일처럼 서비스를 직접 건드리지 않는 일들이었죠.

그냥 하면 최소 2주가 걸렸을 문서 정리를 이틀 만에 끝내자 회의적이던 조직의 여론이 바뀌었다고 합니다. 개인적으로는 시간을 아낄 수 있었던 작업이기도 했지만, 조직을 설득할 근거를 만든 일이기도 했습니다.

2. 정해진 답이 있는 일은 AI의 판단이 아닌 규칙으로 만든다

맡길 일을 골랐다면 이제 통째로 AI에게 넘기면 될까요? 여기서 많은 사람이 한 번씩 실수를 합니다. AI 검색 노출을 진단하는 서비스를 만드는 zurang23 작가의 팀은 처음에 진단을 거의 통째로 AI에게 맡겼습니다. 그런데 결과가 매번 달랐습니다. 같은 페이지를 세 번 돌렸는데, 점수가 72점, 85점, 61점으로 나온 거죠. 데모에서는 근사했지만 돈을 내는 고객이 믿어 줄 수 없는 숫자였습니다.

팀은 일을 둘로 나눴습니다. robots.txt 파일이 있는지, 특정 태그가 들어 있는지처럼 답이 정해진 사실은 코드가 확인하고, ‘콘텐츠가 믿을 만한지’처럼 판단이 필요한 것만 AI에게 맡겼어요. 작가는 돌아보면 AI를 더 똑똑하게 만든 게 아니라 “AI가 틀려도 괜찮은 자리와 절대 틀리면 안 되는 자리를 나눈 것”이었다고 정리합니다.

프론트엔드 개발자 김의중 작가도 비슷한 경험이 있습니다. 그의 기준은 “결정론적인 일은 자동화에, 추론이 필요한 일은 AI에”입니다. 결정론적인 일이란 입력이 같으면 결과도 늘 같아야 하는 일을 말합니다. 작가는 이 기준을 확인하려고 실제 프로젝트의 OpenAPI 스펙(서버와 화면이 주고받을 데이터 규격을 적은 문서)으로 API 연동 코드를 두 가지 방법으로 만들어 비교했습니다. 하나는 Orval이라는 코드 생성기입니다. AI가 아니라, 스펙을 미리 정해진 변환 규칙대로 코드로 옮기는 프로그램이죠. 다른 하나는 같은 스펙을 AI에게 주고 코드를 짜게 한 것입니다.

결과는 차이가 컸습니다. 코드 생성기는 약 1초 만에, 비용 없이 코드를 만들었고 몇 번을 다시 돌려도 똑같은 코드가 나왔습니다. AI는 같은 일에 2~4분이 걸렸고, 돌릴 때마다 약 1.4달러가 들었습니다. 그런데 두 번 돌린 결과가 서로 달랐고, 그중 한 번은 타입 에러를 4개 남겼습니다. 시간도 돈도 더 들었는데 결과는 매번 달랐던 거죠. 스펙이라는 정답지가 이미 있는 일에서는 규칙대로 옮기는 프로그램이 AI보다 빠르고, 싸고, 정확했습니다. 작가는 이렇게 결정론적인 토대를 깔아 두면 그 위에서 AI가 판단이 필요한 일을 더 정확하게 한다고 결론짓습니다.

그런데 규칙을 정하는 일에는 AI를 활용할 수 있습니다. 앞서 소개한 사업관리 담당자 아이엠 조차장 작가는 점검철 서명 검사를 자동화하려고 서명 검사 도구를 만들었습니다. 400페이지가 넘는 스캔본에서 표지를 골라내고, 표지 아래 서명란 두 칸이 비었는지 확인하는 도구입니다. 이 도구는 서명란에 잉크가 얼마나 묻었는지를 숫자로 재서 서명이 있는지 판정합니다. 매번 AI에게 서명이 있는지 묻는 대신 정해진 규칙으로 판정하게 한 거죠. 그런데 그 규칙을 짠 사람은 개발자가 아니라, 클로드 코드와 대화하며 설계를 잡은 작가 자신이었어요. 정해진 답이 있는 일은 AI가 그때그때 판단하게 두지 않고 규칙으로 고정하되, 그 규칙을 만드는 데는 얼마든지 AI를 쓸 수 있다는 것. 세 작가 모두 경험을 통해 결론 지었습니다.

3. 되돌리기 어려운 결정은 사람에게 남긴다

그럼 정답이 없는 일, 판단이 필요한 일은 AI에게 맡겨도 될까요? 먼저 해 본 사람들은 우선 ‘AI가 틀렸을 때 무엇이 망가지는지’를 확인했습니다. 디자이너 Sarah 작가가 만든 로윈은 판례 기반 법률 AI 서비스입니다. 사용자가 자기 사연을 입력하면 비슷한 실제 판례를 찾아 쟁점과 대응 전략을 짚어 주고, 가장 깊은 단계에서는 변호사 상담으로 연결해 줍니다. 작가는 이 서비스를 만들며 “AI가 틀렸을 때 사람이 되돌릴 수 있는 지점까지만 AI에 맡긴다.”는 기준을 세웠습니다. 쟁점 정리는 틀려도 변호사 상담에서 바로잡을 수 있으니 AI의 몫이지만, 소송을 할지 말지는 틀리면 되돌리기 어려우니 끝까지 사람의 몫으로 남겼어요.

그래서 이 서비스는 승소를 약속하는 문장을 쓰지 않고, 사용자가 가장 많은 돈을 내는 마지막 단계의 마지막 버튼도 더 똑똑한 AI가 아니라 변호사 연결로 두었습니다. 반대로 작가가 따로 만들고 있는 직장 생존 유형 진단 서비스처럼, 결과가 틀려도 사용자가 웃고 넘기는 가벼운 서비스에서는 AI에게 넓은 무대를 준다고 합니다. 되돌리기 어렵다는 건 곧 틀렸을 때 치를 대가가 크다는 뜻입니다. 그래서 대가가 작은 곳에서는 AI에게 많이 맡기고, 소송처럼 틀리면 인생이 걸린 곳에서는 사람이 결정하게 두는 거죠. 작가의 말대로 “경계선의 위치를 결정하는 건 AI의 성능이 아니라 오류의 비용”입니다.

사람을 상대하는 사내 업무에서도 비슷합니다. Un 작가가 인터뷰한 클래스메소드의 HR 담당자 박동현 님은 평가 내용 정리나 급여 데이터 처리 같은 반복 업무는 AI 에이전트로 자동화했지만, 직원 갈등이나 갑작스러운 퇴사 상담처럼 정답이 없는 일에서는 동료에게 묻듯 의견을 구하는 데까지만 AI를 씁니다. 평가나 급여 처리는 자동화할 수 있어도 “최종 판단이나 직원과의 소통은 결국 사람의 몫”이라는 게 박동현 님의 답이에요.

개발 현장에서는 이 기준이 더 구체적인 모습으로 나타납니다. 꼼비 작가는 기획 문서와 디자인 시안(Figma)에서 요구사항을 뽑고, 구현하고, 테스트까지 이어서 AI가 처리하게 하는 개발 도구(하네스 플러그인 code-forge)를 직접 만들었습니다. “구현과 검증은 모두 AI가 맡았다.”고 할 만큼 개발을 통째로 넘겨 본 셈이죠. 그런데 그 흐름 안에서도 애매한 비즈니스 정책은 작가가 직접 정했고, 커밋·푸시와 PR 생성은 작가가 승인한 뒤에야 진행됐으며, 작업을 끝내도 될지도 마지막에 작가가 판단했습니다. 제품 코드나 정책을 고쳐야 한다는 결론이 나오면 도구는 직접 고치지 않고 변경 범위와 재현 근거만 넘기게 해 두었고요.

수께끼수 작가도 지금 수준에서 넘지 말아야 할 선을 따로 적어 둡니다. 실사용자 데이터와 서비스 데이터베이스를 AI가 직접 고치도록 자동화하는 일은 아직 하지 말아야 한다는 겁니다. 읽어서 정리하는 데까지는 괜찮지만, 사람 확인 없이 데이터를 바꾸게 두면 오래 얽힌 구조를 AI가 다 파악하지 못한 채 건드려 다른 곳까지 흔드는 사고가 그대로 되풀이된다는 이유에서죠. 맡기는 범위가 넓은 사람일수록, 되돌리기 어려운 지점에는 오히려 더 명확하게 사람의 역할을 두고 있었습니다.

4. 언제 어디서 확인할지를 설계한다

이제 명확한 기준을 갖고 맡겼다면 손을 떼도 될까요? 그렇지 않습니다. 앞서 소개한 꼼비 작가의 개발 도구는 요구사항 정리부터 구현, 테스트까지 AI가 이어서 처리합니다. 이 도구가 작성한 테스트(Jest)가 전부 통과하자 “개발 완료”를 보고했지만, 요구사항 명세 40개 가운데 코드에 실제로 들어간 건 25개였습니다. 테스트가 이미 구현된 동작만 검사했으니 빠진 기능은 어디서도 실패로 잡히지 않았던 거예요.

그 뒤로 작가는 요구사항마다 수용 조건, 테스트, 코드가 어디에 연결되는지 적은 추적표를 AI에게 만들게 하고, 빠진 연결은 자신이 확인합니다. “요즘은 전체 PASS 보고를 받으면 요구사항 추적표를 먼저 연다.”고 해요. 같은 시나리오가 아홉 번 실패하면 AI가 더 붙잡지 않고 로그와 판단 근거를 들고 작가에게 묻게 하기도 했습니다.

언제 어디서 확인해야 할지를 설계하는 방식은 사람마다 달랐습니다. 아이엠 조차장 작가의 서명 검사 도구는 표지를 찾아 서명 부분만 잘라 결과 보고서 한 장(HTML 파일)에 모으고, 서명이 있는지 애매한 것만 빨갛게 표시해 보고서 맨 위에 올립니다. 사람은 그 위쪽만 눈으로 확인하면 되죠. 출근부와 휴가 신청서를 대조하는 도구도 결과를 대시보드 형태의 보고서로 보여 주는데, 여기서도 두 서류가 서로 어긋난 것만 붉게 띄웁니다. 작가는 “빠뜨리느니, 차라리 좀 더 보여주자.”는 원칙으로 애매하면 무조건 사람이 한 번 더 보도록 했고, 이렇게 하자 “AI한테 다 시키자”고 했던 때보다 “더 정직하고 실제로 더 빨랐다”고 말합니다.

AI가 무서운 속도로 텍스트와 코드를 생성하는데, 사람이 그 속도를 따라잡지 못하기 때문에 ‘사람이 병목’이라는 말도 나오는 요즘인데요. 그렇다고 모든 확인을 사람이 해야 한다는 뜻은 아닙니다. 김의중 작가가 제안하는 개발 흐름에서는 스펙이 바뀌면 코드 생성기가 타입을 갱신하고, 컴파일 에러가 난 곳을 AI 에이전트가 고치는 데까지 사람 손을 거치지 않고 이어집니다. 다만 여기서도 AI가 막연히 추측하는 게 아니라, 결정론적인 도구가 어디가 고장 났는지 먼저 짚어 준다는 전제가 있어요.

사람이 직접 보든 규칙을 정해두든, 아홉 작가 모두 AI의 결과를 묻지도 따지지도 않고 믿는 게 아니라, 확인하는 지점을 따로 설계해 두었습니다. 꼼비 작가의 말처럼 제품 코드를 직접 치는 시간은 줄었어도 “전보다 더 많이 생각하고, 키보드도 더 많이 친다.”는 게 이렇게 AI에 일을 맡긴 사람들의 공통된 경험이었습니다.

AI에 일을 맡길 때 고려해야 할 4가지

아홉 가지 사례에서 작가들은 모두 AI가 얼마나 똑똑한지보다 내가 AI에게 맡기려는 그 일이 어떤 성격인지를 먼저 따졌습니다. 자주, 오래, 위험하게 반복되는 일인지 보고, 정해진 답이 있으면 규칙으로 묶고, 틀렸을 때 되돌리기 어려우면 결정을 사람에게 남기고, 맡긴 일에는 확인할 지점을 따로 만들었습니다. AI에게 맡긴다는 건 사람의 일이 사라지는 게 아니라, 사람이 봐야 할 곳이 좁고 분명해지는 일이었던 것입니다.

그러니 지금 맡길까 말까 망설이는 일이 있다면, 아홉 작가가 그은 네 가지 기준에 그 일을 하나씩 대 보면 어떨까요?

• 1. 맡길 가치가 있는 일인가: 자주, 오래, 위험하게 반복되는 일인지 보세요. 1년에 한두 번이라면 도구를 만들고 관리하는 품이 더 클 수 있어요.
• 2. 정해진 답이 있는 일인가: 있다면 AI가 매번 판단하게 두기보다 규칙으로 고정할 수 있는지 먼저 보고, 그 규칙은 AI와 함께 만들어도 됩니다.
• 3. 틀리면 되돌릴 수 있는 일인가: 되돌리기 어렵다면 AI에게는 자료를 모으고 정리하는 데까지만 맡기고, 결정과 승인은 사람에게 남겨 두세요.
• 4. 어디서 확인할 것인가: “완료” 보고만 믿지 말고, 결과를 언제 어디서 확인할지 맡기기 전에 정해 두세요. 사람이 직접 볼지, 규칙이 대신 볼지도 함께요.

지금 내 상황이라면 이 글부터

만들 수 있는 건 많은데 무엇을 계속 키울지 가늠이 안 된다면

• 아이엠 조차장 작가의 「자동화할 일을 고르는 것도 실력이다」부터 읽어 보세요. 지금 만들려는 도구, 이미 만들어 둔 도구를 작가의 네 가지 기준에 대 보면 공들일 것과 손을 뗄 것이 갈립니다.
• 무엇으로 만들지가 고민이라면 김현민 님의 발표를 정리한 「AI 도구 26개를 직접 만들며 알게 된 자동화 노하우」가 문제 정의부터 도구 고르기까지 이어 줘요.

AI에게 맡겼더니 결과가 돌릴 때마다 다르다면

• zurang23 작가의 「AI 진단의 신뢰도를 높인 건 AI에게 덜 맡기는 것이었다」에서 사실과 판단을 가르다 만난 함정들을, 김의중 작가의 「AI 시대의 엔지니어링: 이 일, 정말 AI에 시켜야 하는가?」에서 코드 생성기와 AI를 직접 비교한 수치를 볼 수 있어요.
• 개발자가 아니라면 아이엠 조차장 작가의 「비개발자가 400페이지 서명 검사를 자동화하며 고민한 것」에서 다섯 번 넘어지며 도구의 역할을 줄여 간 과정을 따라가 보세요.

개발을 크게 맡겨 봤는데 “완료” 보고를 믿어도 될지 모르겠다면

• 꼼비 작가의 「AI에게 처음부터 끝까지 개발을 맡겼습니다」가 맞습니다. 테스트가 다 통과했는데도 기능이 빠졌던 이유와, 그 뒤 완료 조건을 어떻게 바꿨는지까지 적혀 있어요.

틀리면 되돌리기 어려운 일을 다룬다면

• 서비스 기획자는 Sarah 작가의 「내가 일부러 AI에게 맡기지 않은 것들」을, 사람을 상대하는 업무 담당자는 Un 작가가 박동현 님을 인터뷰한 「일본 IT 기업의 HR 담당자가 AI로 업무를 혁신한 방법」을 읽어 보세요.
• 위에서는 쓰라는데 팀은 사고가 무섭다면 수께끼수 작가의 「리더는 “AI 왜 안 쓰냐” VS 실무자는 “사고 나면요?”」가 리더와 실무자가 각자 무엇을 조정해야 하는지까지 짚어 줍니다.

여러분은 지금 무엇을 AI에게 맡기고, 무엇을 일부러 맡기지 않고 있나요? “우리 팀은 이 일까지는 AI에게 맡기고, 여기서부터는 사람이 본다”는 기준이 있다면, 그렇게 정한 이유를 요즘IT에 댓글, 이메일(yozm@wishket.com) 등을 통해 들려 주세요. 다음 레퍼런스로 함께 나누겠습니다.

요즘IT 뉴스레터 받아보기

먼저 해 본 사람들의 AI 실무 레퍼런스를 매주 목요일에 보내 드려요. 요즘IT에 가입하면 뉴스레터를 받아볼 수 있어요.

[요즘IT 가입하고 뉴스레터 받기]

이 글은 AI의 도움을 받아 작성했습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.