AI 업무 시범 운영, 무엇을 기록하고 언제 넓힐지 정하는 법

AI에 맡기기로 고른 업무를 처음 돌려 보면, 며칠 뒤 “이제 다른 일에도 써 볼까” 하는 순간이 금방 와요. 그때 근거가 기억뿐이면 넓힐지 말지를 감으로 정하게 되죠. 이 글은 초기 스타트업과 1인 창업이 시범 운영 기록을 어떤 칸으로 남기면 넓힐지, 고칠지, 멈출지를 기록으로 정할 수 있는지 다룹니다.

시범 운영 기록의 칸은 지어내지 않고 실제 운영 기록에서 골랐어요. AI 담당이 오픈마켓에 상품을 등록하며 남긴 채널 규칙 변경 기록, 이 블로그 엔진이 글을 올릴 때마다 적는 글 번호 기록, 날짜 걸린 후속 일 표가 출발점입니다. 업무를 단계로 쪼개고 첫 업무를 고르는 법은 AI 업무 설계 첫 글에, 사람만 누르는 버튼은 승인 버튼 글에, 단계 사이 넘기는 조건은 AI 업무 인계 글에 있어요. 여기서는 AI 업무 설계의 그다음 단계, 작게 돌리는 기간에 남길 시범 운영 기록만 다룹니다.

시범 운영 기록은 한 건에 한 줄씩 남겨요

AX(AI 전환) 5단계는 업무 진단 → 과제 선정 → 업무 재설계 → 시범 운영 → 정착 순서예요. 이 블로그의 AX 설계 안내는 시범 운영(Pilot)을 요청문·AI 에이전트·작업 양식을 갖추고 실제 자료로 결과를 대조하는 단계로 두고, 산출물로 결과 대조표와 보완 목록을 적어 두었습니다. 시범 운영 기록은 그 대조표와 보완 목록의 재료예요. AI 업무 설계에서 정한 흐름이 실제로 그대로 도는지 이 기록으로 확인합니다.

시범 운영 기록의 단위는 하루가 아니라 한 건으로 잡길 권해요. 상품 하나 등록, 글 한 편 게시, 문의 메일 한 통 답장처럼요. 하루 단위로 적으면 “오늘은 괜찮았음” 같은 줄이 남는데, 건 단위로 적으면 어느 건에서 사람이 손을 댔는지가 남습니다.

판정은 시범 운영 기록을 쌓기 전에 세 갈래로 미리 정해 둡니다. 오픈마켓 상품 기록표를 만들 때 상태 칸에 정해 둔 값이 이 모양이에요. 후보에서 시작해 검수와 승인을 거쳐 ‘테스트’가 되고, 그다음 값은 확대·보류·중단 세 가지뿐입니다. 이 글에서는 확대를 넓힘, 보류를 고쳐서 다시, 중단을 멈춤으로 바꿔 불러요. 보류를 고쳐서 다시로 부른 것은 이 글에서 붙인 대응이에요.

오픈마켓 상품 등록, 첫 묶음 기록이 다음 묶음의 규칙이 됐어요

오픈마켓 저장소에는 채널 규칙 변경 기록이라는 파일이 있어요. 맨 위에 “에이전트가 실제 화면에서 이 폴더의 규칙과 다른 점을 발견하면 여기에 추가한다”는 줄이 있고, 형식은 날짜 [채널] 내용 (근거: 화면 캡처/URL) 한 줄입니다.

2026년 10월 8일 토스쇼핑에 파일럿으로 등록한 묶음이 그 형식으로 남았어요. 검수를 통과한 상품은 무엇을 어떻게 넣었는지(수량 1개 + 개당 중량, 대표 이미지 1장, 상세 4~7장, 태그 11~20개)를 적었고, 반려된 상품은 반려 사유와 바꿔 넣은 값, 그 뒤 통과 여부를 같은 날짜로 이어 적었습니다. 여러 개가 들어 있는 상품은 “수량 1 + 총중량”으로 바꾸자 통과했다는 식이에요.

이 시범 운영 기록은 입력 규칙 문서로 옮겨졌는데, 옮길 때 붙은 단서가 눈여겨볼 곳이에요. 테스트한 식품은 그 방식으로 통과했지만 보리차 등은 개당 수량 칸이 따로 필수였으니, 모든 카테고리에 일괄 적용하지 말고 필수 칸과 단위를 확인하라고 적었습니다. 등록 뒤 다시 읽어 확인할 수 없는 검색 옵션 값은 보낸 값과 검수 상태를 함께 기록한다는 줄도 있고요.

손이 간 정도도 시범 운영 기록의 한 칸이 됐어요. 쿠팡 등록 운영 규칙 문서는 10월 7일 등록 세션을 분석한 근거로 시작하고, 건당 도구 호출 수를 세어 목표를 건당 12~15회로 잡았습니다. 수정 요청 저장은 한 번에 3~4건씩 묶는다는 규칙도 같은 문서에 있어요.

판매 채널을 넓힐 때도 작은 시험이 먼저 적혔어요. 10월 19일 운영 문서는 11번가와 옥션·G마켓에 가구를 “쿠팡과 같은 범위로” 등록한다고 정하고, 공급처별로 몇 개를 먼저 시험 업로드해 결과를 보고 생성기를 고친 뒤 나머지를 올리는 순서를 적었습니다. 옥션·G마켓 담당 지시에는 “공급처별 3~5개 시험 업로드 → 수정 → 나머지”로 들어 있어요.

함께 읽기AI 업무 설계, 일 맡기기 전에 이렇게 쪼개 보세요: 단계·요청문·확인할 자리AI 업무 설계를 처음 하는 초기 스타트업·1인 창업용 방법 글. 일을 입력과 결과로 단계를 나누고, 4칸 요청문을 쓰고, 사람이 확인할…

올린 건마다 번호와 상태를 남기면 같은 일을 두 번 하지 않아요

시범 운영 중에는 고친 건을 다시 돌리는 일이 생겨요. 시범 운영 기록에 건마다 번호와 상태가 없으면 무엇이 이미 끝났는지 몰라 두 번 올리게 됩니다. 2026년 10월 8일 claude.dev 블로그 글 「Building effective agent automations」는 매일 요약을 올리는 에이전트를 예로 이 문제를 다뤄요.

글은 올라간 것이 확인된 뒤에만 보고한 항목 장부를 고치고, 결과가 불분명하면 실행을 “maybe posted”로 표시하고 다른 것은 바꾸지 말라고 해요. 에이전트는 실행마다 runs/<날짜>.md에 실행 기록을 남기고, 장부 한 줄에는 보고한 때, 출처, 바뀌지 않는 번호, 마지막 상태를 적습니다. 읽지 못한 출처는 “새 소식 없음”으로 넘기지 말고 못 읽었다고 한 줄 남기라는 규칙도 있어요.

이 블로그의 게시 엔진도 비슷하게 기록해요. 글을 올리면 워드프레스가 돌려준 글 번호, 상태, 주소를 기록 파일에 적고, 다음에 같은 글을 올리면 그 번호로 새 글 대신 기존 글을 고칩니다. 영상 업로드 중 연결이 끊기면 “실제로는 올라갔을 수 있다”며 확인한 뒤 기록을 맞추고 다시 실행하라는 안내를 내고 멈춰요.

날짜가 걸린 확인은 후속 일 표에 날짜·담당·할 일·출처 네 칸으로 적어요. 엔진을 고친 뒤 “첫 릴스에 AI 레이블이 자동으로 붙었는지 확인”처럼, 바꾼 것을 처음 한 건에서 확인하는 줄이 여기 들어갑니다. 공개하면 안 되는 값을 막는 검사는 오류가 나면 우회 옵션 없이 글을 고치게 되어 있고요.

2026년 발표에서 찾은 넓히는 기준

McKinsey가 2026년 8월 25일 낸 「The state of AI in 2026」은 모든 조직의 과제로, 도구나 시범 사업(pilots)을 쌓아 두기만 하지 말고 그것을 새로운 일하는 방식으로 바꾸는 반복 가능한 역량을 갖추는 것을 꼽아요. 그러려면 업무 흐름 전체를 다시 그리고, 역할과 업무량을 어떻게 옮길지 정하고, 효과가 확인된 것을 넓히는(scale what works) 운영 역량을 길러야 한다고 적었습니다.

넓히는 속도에 대해서는 Anthropic이 2026년 2월 18일 발표한 「Measuring AI agent autonomy in practice」에 관찰이 있어요. Claude Code 사용 기록에서 쓴 지 50세션이 안 된 사용자는 약 20%의 세션에서 전체 자동 승인을 썼고, 750세션쯤에는 40%를 넘었습니다. 글은 이 변화가 점진적이며 신뢰가 꾸준히 쌓인 결과로 보인다고 했고, 경험 많은 사용자일수록 중간에 끼어드는 일도 더 잦았다고 적었어요. 다만 기본 설정이 동작마다 승인을 요구하므로, 이 변화의 일부는 사용자가 설정을 자기 취향에 맞게 바꾼 결과일 수 있다는 단서도 달았습니다.

2026년 9월 15일 Anthropic 공식 저장소의 작은 회사용 플러그인에 추가된 build-agent 스킬은 시험 방법을 구체적으로 적어 둡니다. 대표가 이미 답을 아는 건으로 돌려 손으로 한 결과와 나란히 보여 주고, 맞지 않으면 고쳐서 다시 돌리며, 근소하게 빗나간 결과를 받아들이라고 하지 말라는 내용이에요. 팀에 나눠 줄 때는 무엇이든 보내는 스킬이면 초안까지만 만들게 하라고 권하고, 보내거나 돈을 쓰는 일은 대표가 뭐라고 하든 승인 관문 없이 만들지 말라고 못 박아 둡니다.

함께 읽기AI에 일 맡길 때, 사람만 누르는 버튼부터 정해 두세요AI 승인 단계를 쇼핑몰 운영·앱 출시·블로그에 어떻게 정했는지 열어 봤어요. 결제, 판매가 변경, 출시하기, 글 발행 앞에서 AI가 준…

시범 운영 기록표 8칸, 칸마다 근거가 있어요

위 기록들에서 칸을 골라 시범 운영 기록표 한 장으로 묶었어요. 한 건을 돌릴 때마다 한 줄을 채웁니다.

검수 결과 칸의 통과·고침·보류는 무료 AX 양식 가운데 승인·검수 규칙 체크리스트의 승인 기록과 같은 말이에요. 두 장을 같이 쓰면 승인 기록의 값을 시범 운영 기록표에 그대로 옮겨 적을 수 있습니다. 표 아래 “못 한 것·건너뛴 것” 칸은 claude.dev 글의 못 읽은 출처를 남기라는 규칙에서 가져왔어요.

넓힐지·고칠지·멈출지, 기간이 끝나면 이 순서로 확인해요

시범 운영 기록을 언제 펼쳐 판정할지도 미리 정해 둡니다. 앱 출시 운영 문서는 운영 판정을 7일 단위로 묶어 두었어요. 결과 완료율이나 재방문이 오르면 관련 앱 발송을 넓히고, 유입만 높고 재방문이 낮으면 첫 결과와 저장 흐름을 고치고, 7일 연속 핵심 지표가 나아지지 않으면 새 기능과 광고 집행을 멈추고 기존 앱 개선으로 돌립니다. 같은 저장소의 점검 보고서는 아직 끝나지 않은 주의 숫자로 출시 중단을 단정하지 않는다고 적었고, 앱별 권고는 다음 주에 검증할 가설로 두었어요.

시범 운영 기록으로 여덟 줄이 다 채워지면 넓히고, 3·4번에서 고칠 곳이 보이면 고쳐서 같은 범위로 다시 돌려요. 건마다 사람이 처음부터 다시 확인해야 하는 상태가 이어지면 멈추고 사람이 하던 방식으로 둡니다. build-agent 스킬도 시험하지 않은 스킬은 매번 손으로 확인하게 되어 아무것도 아끼지 못한다고 적었어요.

업종과 업무에 맞춘 AX 설계 상담은 무료 AX 상담 신청에서 받습니다.

시범 운영 기록 자주 묻는 질문

AI 업무 시범 운영 기록에는 어떤 칸이 있으면 되나요?

이 글의 기록표는 날짜, 건 번호, 넣은 것, 결과 상태, 검수 결과(통과·고침·보류), 고친 곳 한 줄, 손이 간 정도, 근거·남긴 곳 여덟 칸이에요. 한 건을 돌릴 때마다 한 줄씩 채우고, 기간이 끝나면 아래 칸에 못 한 것과 판정을 적습니다. 칸마다 오픈마켓 등록 기록이나 블로그 게시 기록에 실제로 있던 항목을 골라 붙였어요.

시범 운영이 끝나면 무엇을 보고 넓힐지 정하나요?

정한 기간과 건수를 다 채웠는지, 답을 아는 건으로 사람 결과와 나란히 대조했는지, 고침으로 남은 건이 다시 통과했는지, 넓힐 범위가 시험한 범위 안인지를 먼저 봐요. 시험한 범위 밖으로 넓힐 때는 작게 시험부터 다시 하고, 보내기·돈 쓰기·발행 단계의 승인 자리는 넓혀도 그대로 둡니다.

시범 운영 결과가 애매하면 바로 멈춰야 하나요?

기간이 끝나기 전에는 판정하지 않는 편이 좋아요. 앱 출시 점검 보고서도 아직 끝나지 않은 주의 숫자로는 출시 중단을 단정하지 않는다고 적어 두었어요. 고칠 곳이 기록에 보이면 요청문이나 규칙을 고쳐 같은 범위로 한 번 더 돌리고, 건마다 사람이 처음부터 다시 확인해야 하는 상태가 이어지면 멈추고 사람이 하던 방식으로 둡니다.

글에 나온 역할별 AI 작업 창은 Claude Code로 띄운 것이고, 공식 안내는 Claude Code 공식 문서에 있습니다.

이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 운영 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.