본문 바로가기
책상 노트 책상 노트
실무자가 실제로 굴려본 업무도구·업무 자동화 기록

AI 개입이 서른 번이었던 건 AI가 아니라 제 기준 탓

읽는 시간 약 9분

지난 30일 동안 AI 에이전트와 나눈 대화 기록을 통계로 뽑아본 적이 있습니다. 세션 149개, 제가 보낸 메시지 4,532건이었습니다. 세션 하나에 평균 30번 개입했고, 149개 중 69개는 결론 없이 끝났습니다. 중단율로 치면 46%입니다. 하위 작업자에게 일을 넘기는 위임 기능을 쓴 세션은 28개, 19%에 그쳤습니다.

이 숫자를 보기 전까지 저는 AI가 시키는 대로 못 해서 자꾸 고쳐줘야 한다고 생각했습니다. 숫자를 보고 나서 생각이 바뀌었습니다. 세션당 30번 개입하는 건 AI가 30번 틀린 게 아니라, 제가 처음에 무엇이 맞는지 말해주지 않은 경우가 많았기 때문입니다. 이 글은 그 진단과, 그 뒤 바꿔본 방식의 기록입니다.

숫자를 뽑게 된 계기

계기는 원고 작업이었습니다. 블로그 원고 30편을 AI에게 맡겨 쓰게 하는 세션이 있었는데, 그 세션의 메시지가 658건까지 늘어났습니다. 원고 한 편에 스무 번 넘게 왔다 갔다 한 셈입니다. “이 표현 빼”, “존댓말로”, “표는 이미지로”, “그 문장 다시”. 이런 지시가 편마다 반복됐고, 어느 순간 제가 같은 말을 몇 번째 하고 있는지 세어보고 싶어졌습니다.

세션 기록이 로컬 데이터베이스에 남아 있어서 30일치를 뽑아 분류했습니다. 분류 자체는 AI에게 시켰고, 저는 결과표만 봤습니다. 오전에 시작해서 점심 전에 표가 나왔습니다. 분류 기준은 여섯 가지로 잡았습니다. 인프라를 만드는 세션, 조사와 전략을 논의하는 세션, 실제 산출물을 내는 세션, 회사 실무, 장애 복구, 그리고 기타입니다. 뽑고 나서 보니 인프라 구축이 29%로 가장 많았고 실제 산출물은 24%였습니다. 도구를 만드는 세션의 비중이 도구로 무언가를 만드는 세션의 비중보다 컸다는 뜻이라, 이 비율도 눈에 들어왔습니다.

30일간 세션 수와 개입 횟수, 중단율을 숫자로 정리한 도해

표에서 보인 세 가지

항목수치
직접 대화한 세션149개
세션당 평균 개입30.4회
결론 없이 끝난 세션69개 (46%)
위임 기능을 쓴 세션28개 (19%)
평균 발화 80자 미만 세션54개

첫째로 걸린 것은 중단율입니다. 결론 없이 끝난 69개 세션의 상위를 보니 전부 큰 세션이었습니다. 전략 수립 774건, 자동매매 670건, 원고 658건. 길어서 죽은 게 아니라 끝 조건을 정하지 않고 시작해서 길어졌고, 길어져서 죽은 것이었습니다. 어디까지 하면 끝인지 제가 정한 적이 없으니 AI도 저도 멈출 곳을 몰랐습니다.

둘째는 발화 길이입니다. 평균 발화가 80자 미만인 세션이 54개였습니다. “그거 말고”, “다시”, “아니 위에 거”로 운전한 세션들입니다. 짧은 키질 한 번은 빠르지만, 그게 서른 번 쌓이면 처음에 한 문단 제대로 쓰는 것보다 훨씬 느립니다. 그리고 그 서른 번은 세션이 끝나면 사라져서 다음 세션에서 처음부터 다시 시작됩니다.

셋째는 개입의 종류였습니다. 발화 내용을 훑어보니 대부분이 실행 세부 조정이었습니다. 표 정렬을 바꾸라거나 문장 하나를 고치라는 것들입니다. 제가 실제로 판단해야 할 것은 “이 셋 중 무엇부터 하는 게 맞나” 같은 방향 문제였는데, 그런 발화는 손에 꼽을 정도였습니다. 시간의 대부분을 판단이 아니라 손질에 썼습니다.

결론 없이 끝난 세션 중 메시지가 많았던 세 곳을 막대로 비교한 도해

진단: 합격 기준이 없으니 매번 불합격이었습니다

세 가지를 한 줄로 묶으면 이렇습니다. 시작할 때 무엇이 완성인지 정하지 않았기 때문에, 나온 결과물이 매번 조금씩 불만족스러웠고, 그 불만족을 서른 번의 짧은 지시로 메웠고, 그러다 지쳐서 절반은 끝을 못 봤습니다.

돌아보면 사람에게 일을 맡길 때도 같은 실수를 한 적이 있습니다. 신입 직원에게 “이 자료 정리해줘”라고 하고 나서 결과물을 보며 “아니 이렇게가 아니고”를 반복했던 일입니다. 그때는 직원이 눈치가 없다고 생각했는데, 지금 와서 보면 정리의 결과가 어떤 모양이어야 하는지 제가 말한 적이 없었습니다. AI는 그 상황을 하루 열 번씩 재현해서 보여줬을 뿐입니다.

기능 문제로 오해했던 것도 있습니다. 위임 기능을 19%만 쓴 이유를 처음에는 위임하면 결과가 못 미더워서라고 생각했습니다. 그런데 위임 결과가 못 미더웠던 세션을 다시 보니, 위임할 때 넘긴 지시가 한두 줄이었습니다. 한두 줄 받은 하위 작업자가 제 머릿속 기준을 맞출 리가 없었고, 그 결과를 보고 “역시 직접 해야 하네”로 결론 내린 것입니다. 원인과 결과를 거꾸로 읽고 있었습니다.

바꾼 것: 시작할 때 합격 기준을 먼저 씁니다

진단 다음 주부터 규칙을 하나만 바꿨습니다. 어떤 작업이든 첫 지시에 합격 기준을 넣는 것입니다. 산출물의 형태, 개수, 그리고 어떤 상태면 끝난 것으로 치는지를 적습니다. 원고라면 편수, 글자 수 범위, 문체, 금지 표현, 저장 위치, 그리고 보고 형식까지 첫 메시지에 다 넣습니다. 이 첫 메시지를 쓰는 데 10분에서 20분이 걸립니다.

처음에는 이 20분이 아까웠습니다. 예전 방식이면 그 시간에 이미 첫 결과물이 나와 있었을 테니까요. 그런데 몇 번 해보니 그 20분이 뒤의 서른 번 개입을 대체한다는 게 보였습니다. 합격 기준이 있는 세션은 결과물이 나오면 기준과 대조해서 합격이면 끝, 불합격이면 어느 기준에서 틀렸는지 한 줄만 말하면 됐습니다.

같은 규칙에서 따라 나온 것이 두 가지 더 있습니다.

  • 두 번 말한 규칙은 그 자리에서 문서로 박습니다. 세션마다 다시 등장하던 톤 규격, 표 규칙, 금지 표현을 파일 하나에 모으고, 첫 지시에는 그 파일을 읽으라고만 적습니다. 서른 번의 개입 중 절반은 이 파일이 없어서 생겼던 것입니다.
  • 실행은 위임하고 저는 검수만 합니다. 합격 기준이 문서로 있으니 하위 작업자에게 그대로 넘길 수 있고, 결과가 기준을 통과했는지만 제가 봅니다. 위임률이 낮았던 건 위임할 만한 기준이 없었기 때문이라고 판단합니다.
기준 없이 시작한 세션과 합격 기준을 넣고 시작한 세션을 좌우로 비교한 도해

한 줄로 닫히는 세션

합격 기준을 넣고 시작한 세션은 결과물이 오면 기준과 대조해서 끝내거나 한 줄 돌려보내는 것으로 닫히고, 예전처럼 서른 번 오가는 일은 없었습니다.

그래도 줄지 않은 것이 있습니다. 조사와 전략 논의 세션은 여전히 개입이 많습니다. 이건 합격 기준을 먼저 쓰기 어려운 종류의 일입니다. 어디로 갈지 모르니까 논의를 하는 것인데, 시작할 때 도착지를 쓰라는 규칙이 잘 안 맞습니다. 대신 이런 세션은 시간을 정해두고, 시간이 되면 지금까지의 결론을 문서로 남기고 닫는 방식으로 바꿨습니다. 완성 기준 대신 종료 기준을 둔 것입니다.

합격 기준을 실제로 어떻게 쓰는지

규칙만 적으면 막연하니 실제 사용하는 형태를 적어두겠습니다. 원고 다섯 편을 맡길 때 첫 메시지는 대략 이런 항목으로 구성됩니다.

  • 산출물: 파일 다섯 개, 파일명 지정, 저장 경로 지정
  • 형태: 글자 수 범위, 소제목 단계, 문체 규칙이 적힌 문서의 경로
  • 금지: 다른 작업자가 쓰고 있는 소재 목록, 기존 글과 겹치는 각도
  • 완료 판정: 검사 스크립트 통과, 글자 수 범위 안, 다섯 편끼리 도입 구조가 다를 것
  • 보고: 본문을 붙이지 말고 파일명과 글자 수만 표로

이 다섯 항목을 채우는 데 15분 안팎이 듭니다. 채우다 보면 제가 아직 정하지 않은 것이 드러납니다. 글자 수 범위를 적으려다 보면 실제로 몇 자를 원하는지 처음 생각해보게 되고, 완료 판정을 적으려다 보면 검사할 방법이 없는 항목이 나옵니다. 그 항목은 판정 기준에서 빼거나 검사할 수 있는 형태로 바꿉니다. “읽기 좋게”는 판정할 수 없어서 빠지고, “문장 길이 표준편차 25 내외”는 스크립트로 잴 수 있으니 남습니다.

처음 이 방식을 시작하고 두 주 동안은 첫 메시지를 쓰다가 도중에 그만둔 적도 있었습니다. 기준을 적다 보니 이 일을 지금 시킬 만큼 제가 정리가 안 됐다는 게 보였기 때문입니다. 예전 방식이면 그 상태로 시작해서 서른 번 개입하며 정리했을 겁니다. 시작하기 전에 멈춘 것도 이 규칙의 효과로 치고 있습니다.

합격 기준부터 쓰는 네 가지 원칙

  • 일을 넘길 때 첫 메시지에 합격 기준을 씁니다. 형태, 개수, 완료 판정 조건. 이걸 쓰는 20분이 서른 번의 개입보다 짧습니다.
  • 결과가 마음에 안 들면 결과를 고치기 전에 기준을 봅니다. 기준에 없던 불만이면 그건 AI의 실수가 아니라 제 기준의 누락입니다. 기준에 추가하고 다음부터 안 반복되게 합니다.
  • 같은 지시를 두 번 하면 문서로 옮깁니다. 세 번째부터는 문서 경로만 말합니다.
  • 방향을 정하는 일과 실행하는 일을 구분합니다. 실행에 제 시간을 쓰고 있으면 기준이 부족하다는 신호로 읽습니다.

AI에게 일을 시키는 문제라고 생각하고 시작한 진단이었는데, 나온 것은 제가 일을 정의하는 방식의 문제였습니다. 서른 번의 개입은 AI가 서른 번 틀린 기록이 아니라 제가 서른 번 나눠서 기준을 말한 기록이었습니다. 그걸 한 번에 말하는 연습을 지금도 하고 있습니다.

책상 노트 운영자
함께 보면 좋은 글
error: Content is protected !!