에이전트가 틀렸을 때 어떻게 아는가 | Aside 브라우저 사용설명서 13장

9회차 영상을 재생해 보고 “오히려 후퇴했어”라고 판정했다.

그 영상은 특허 도면 속 기구 동작을 보여 주는 짧은 클립이었다. 대상은 쇼핑카트 뒤쪽 판, 현장에서 ‘등받이’라고 부르는 부분이다. 윗변은 경첩으로 고정되어 있고, 카트를 포갤 때 아랫변이 안쪽 위로 들린다. 고양이 문과 같은 움직임이다. 이 동작을 AI 영상 생성 도구로 아홉 번 만들었고 크레딧을 약 265 썼다. 아홉 번째는 여덟 번째보다 뒤로 갔다. 이 장은 에이전트와 AI 도구가 틀렸을 때 그것을 어떻게 알아차리는지, 같은 실패가 되풀이될 때 요청을 더 다듬을지 방법 자체를 바꿀지를 어떻게 가르는지 정리한다. 이런 검증 작업을 어느 권한으로 돌릴지는 11장에서 정리했다.

13.1 아홉 번 만든 영상

1회부터 3회까지는 프롬프트만 썼다. 동작을 세 장면으로 나눠 적었지만 모델은 경첩 방향을 잘못 읽었다. 4회에는 상위 품질 모델을 썼다. 기본 모델이 한 편에 15크레딧이라면 이 모델은 100크레딧이다. 화질은 좋아졌지만 경첩은 여전히 반대였다. 5회에는 역재생 방식과 비유 표현을 써 봤고, 엉뚱한 면이 움직였다. 6회 정방향 수정본은 아랫변을 경첩으로 읽었다. 7회부터 입력의 종류를 바꿨다. 코드로 그린 도면을 참고 이미지로 첨부했고, 모델이 도면을 따라 그린다는 것을 확인했다. 8회에는 0도와 90도 도면 두 장을 넣었다. 처음으로 회전이 맞았다. 다만 시작 부분에 판이 두 개 그려졌다가 아래에서 하나로 합쳐지는 겹침이 생겼다.

9회에는 겹침을 없애려고 0도 도면 한 장만 넣고 90도 자세는 글로 설명했다. “판은 항상 정확히 하나”라는 제약 문장도 더했다. 결과는 후퇴였다. 시점, 고정점, 동작이 함께 무너졌다. 돌아보면 90도 도면은 겹침의 원인이면서 끝 자세를 알려 주는 유일한 구속이었다. 도면을 줄이자 겹침과 함께 구속도 사라졌다. 개선처럼 보였지만 실제로는 맞바꿈이었다. 8회차를 두고 나는 “아랫쪽에서 만난 순간부터가 올바른 동작”이라고 판정했다. 합쳐지는 순간 앞을 잘라 내면 보조 화면으로는 쓸 수 있다. 하나를 고치자 다른 것이 무너졌다면, 그 고침은 전진으로 세지 않는 편이 안전하다.

아홉 편을 나란히 놓으면 실패에 일정한 모양이 있었다. 실제 판은 윗변이 고정되고 아랫변이 안쪽 위로 들린다. 모델은 매번 아랫변을 고정하고 윗변을 앞으로 눕혔다. 트럭 뒷문(테일게이트)이 열리는 모양이다. 바닥판까지 들어 올려 두 판이 V자로 만나게 그리기도 했다. 프롬프트를 정교하게 다듬어도, 부정문을 넣어도, 비유를 바꿔도 이 쏠림을 이기지 못했다. 표현을 바꿀 때마다 틀린 방식이 달라졌다면 다듬을 여지가 있었을 것이다. 매번 같은 쪽으로 틀렸다는 점이 판단의 출발점이 됐다.

13.2 더 다듬을까, 방법을 바꿀까?

나는 이 실패를 프롬프트 실력의 문제보다 모델의 구조적 한계로 봤다. 학습 데이터에 흔한 동작 쪽으로 끌려간다고 판단한 것이다. 그래서 기구 동작은 코드로 만들기로 했다. SVG로 도면을 그리고 canvas로 움직이는 방식이다. 고정점과 회전축을 코드가 강제하니 동작이 정확했고, 비용은 들지 않았다. AI 영상은 분위기 컷, 도입, 배경에만 쓰기로 했다. 남은 크레딧은 이 건에 더 쓰지 않기로 했다. 방법을 바꾼다는 결정은 도구를 버린다는 뜻과 다르다. 도구가 잘하는 자리와 못하는 자리를 가르고, 못하는 자리를 다른 수단에 넘기는 일이다.

그림 13-1의 흐름은 이 경험에서 뽑은 질문을 차례로 놓은 것이다. 첫 질문은 판정 근거다. 틀렸다는 판정 자체가 틀릴 수 있어서, 무엇을 보고 틀렸다고 했는지부터 확인한다. 이 문제는 13.4에서 다시 다룬다. 그다음은 실패의 모양이 매번 같은지, 입력을 바꿔도 같은 쪽으로 끌려가는지다. 둘 다 그렇다면 다듬기를 멈추고 방법을 바꾼다. 아래 표는 그 신호들을 나란히 놓은 것이다.

신호	계속 다듬을 때	방법을 바꿀 때	9회 영상에서 본 것
실패의 모양	회차마다 다르게 틀린다	매번 같은 모양으로 틀린다	윗변이 앞으로 눕는 테일게이트 동작, V자로 만나는 판
입력을 바꿨을 때	바꾼 만큼 결과가 따라 움직인다	표현, 부정문, 비유를 바꿔도 같은 쪽으로 끌려간다	1~6회 모두 경첩 오인
더 좋은 모델	상위 모델에서 핵심 오류가 풀린다	화질만 좋아지고 핵심 오류는 남는다	4회, 100크레딧 모델도 경첩 오인
고친 결과	한 문제를 고쳐도 나머지가 유지된다	하나를 고치면 다른 것이 무너진다	8회 겹침을 없애려던 9회에서 시점, 고정점, 동작 붕괴
다른 수단	요구를 강제할 다른 수단이 없다	코드나 도면처럼 요구를 강제할 수단이 있다	코드가 고정점과 회전축을 강제, 비용 0

13.3 실패를 스킬로 남기기

결과는 계정 스킬 하나로 기록했다. 9회 실측표, 실패 모양, 앵커 맞교환, 도구 조작 요령을 담았고, 도면을 만드는 코드도 파일로 남겼다. 그러면서 나는 “계속 연구해보자”며 이 한계를 장기 과제로 두었다. 실패를 스킬로 남기는 까닭은 다음 작업이 같은 다듬기를 처음부터 되풀이하지 않게 하려는 데 있다. 기록이 없으면 비슷한 요청이 왔을 때 다시 프롬프트 손질부터 시작하기 쉽다. 무엇을 시도했고, 얼마가 들었고, 어떻게 틀렸는지가 표로 남아 있으면 방법을 바꾼 이유도 함께 전해진다. 스킬 만드는 법은 6장에서 다뤘다.

스킬은 Settings > Plugins & MCPs > Skills 화면에서 볼 수 있다. My Skills, Built-in Skills, System, Password Manager 묶음이 있고, 내 My Skills에는 세 개가 있다. 그중 하나가 영상 실패를 기록한 스킬이다. 스킬을 누르면 SKILL.md 내용이 제목, 표, 코드 블록으로 정리되어 보인다.

그 뒤 같은 도구 안에서 영상-영상 모드를 찾았다. 업로드한 영상을 동작 참고로 삼고 겉모습만 바꾸는 모드다. 모델이 중간 동작을 상상하는 단계를 피할 수 있는 경로라서 다음 후보로 스킬에 이어 적을 만하다.

13.4 성공처럼 보이는 실패는 어떻게 잡나?

영상의 성공 판정은 내가 직접 재생해서 했다. 그 과정에서 Aside는 정지 프레임만 보고 동작의 성패를 두 번 잘못 판단했다. 움직임을 판정하면서 멈춘 그림을 본 셈이다. 그 뒤로 Aside는 볼 것 두 가지, 회전 축이 맞는지와 배경이 멈춰 있는지를 짚어 주고 재생 판정은 나에게 넘겼다. 그러자 판정이 정확해졌다. 검사하는 쪽이 대상의 핵심을 볼 수 없다면 역할을 나누는 편이 낫다. 에이전트는 무엇을 볼지 정리하고, 사람은 그 기준으로 재생해 판정한다.

도구 쪽에도 겉과 속이 다른 순간이 있었다. 영상 도구에 webm 파일을 올렸을 때 도구는 오류 없이 파일을 조용히 무시하고, 직전에 선택돼 있던 다른 미디어를 그대로 잡았다. 올린 항목의 해상도와 길이 표기를 원본과 대조해서 알았다. 같은 내용을 MP4로 올리자 정상 등록됐다. 반대 방향도 있었다. 생성 승인 직후 “문제가 발생했습니다”라는 오류가 떴지만 작업은 정상 접수되어 대기열에 들어가 있었다. 오류 문구만 보고 다시 시도했다면 같은 생성에 두 번 과금될 뻔했다. 확인할 곳은 문구보다 대기열 상태와 생성물 개수다. 비용 안내도 한 번 어긋났다. Aside가 새 생성 모드 비용을 15크레딧으로 미리 안내했는데 승인 화면에는 20이 떠서, 차액을 사후에 보고했다.

13.5 숫자 루틴의 이상값 검사

7장에서 소개한 매일 아침 6시 크론 루틴은 공개 페이지의 숫자 100여 개를 읽어 스프레드시트에 기록한다. 빈칸, 연속 0, 덮어쓰기 사례는 7장에서 다뤘다. 여기서는 그 뒤에 굳은 검사 규칙을 적는다. 첫째, 0이나 -1이 나오면 바로 믿지 않고 두 번 더 읽어 같을 때만 기록한다. 9월 27일 실행에서는 0 하나와 -1 다섯 개를 각각 두 번 다시 읽었고, 모두 같은 값이었다. 진짜 값이었던 것이다. 둘째, 한 항목의 변화가 말이 안 되게 크면 기록 전에 페이지를 다시 열어 직접 읽는다. 이 규칙은 8월 28일에 생겼다. 전날 19였던 항목이 바쁜 묶음 중에 0으로 읽혔는데, 숫자가 뜨기 전의 자리표시 값을 결과로 돌려준 읽기 코드의 결함이었다.

그날의 0은 기록 뒤 큰 감소폭을 골라 보는 점검에서 걸렸다. 다시 읽자 20이었다. 그 행을 고쳤고, 그날 전체 변동은 65에서 85로 바뀌었다. 셋째 규칙은 기록 뒤 대조다. 매번 시트 전체를 CSV로 내려받아 적으려던 값과 한 칸씩 맞춰 보고, 요즘 실행 보고는 “불일치 0″으로 끝난다. 9월 8일에는 이 대조가 상태 칸에 ‘성공’이 두 번 겹쳐 ‘성공성공’으로 적힌 것을 잡았다. 도구는 아무 오류도 내지 않았고, 찾아 바꾸기로 고쳤다. 루틴마다 실행 결과를 적는 루틴 메모리 파일이 있어서, 이상값을 어떻게 처리했는지가 매일 남는다.

시험 자체가 결함을 놓친 적도 있다. 8월 28일, 시트에 붙여넣는 도구가 지정한 칸과 상관없이 맨 왼쪽 위 칸에 붙이는 결함이 있었다. A열 먼 칸에 시험 삼아 적어 보는 시험은 결함이 있어도 통과해 버렸다. 결함은 대상이 A열이 아닐 때만 드러났기 때문이다. 그래서 시험 쓰기는 A열이 아닌 칸, 예를 들어 G열에 한다. 시험이 통과했다는 사실은 그 시험이 결함을 드러낼 수 있는 조건에서 돌았을 때만 의미가 있다.

13.6 다른 AI의 점검 결과는 믿어도 될까?

9장에서 여러 채팅 AI에게 받은 사이트 점검 보고서 6건 가운데, 깨졌다거나 빠졌다는 주장의 절반가량이 사실이 아니었다고 적었다. 틀린 이유는 두 가지였다. 확인하지 않은 짐작, 그리고 사이트가 바뀐 뒤에도 자기가 앞서 본 내용을 다시 쓴 것이다. 그 뒤 받은 보고서들은 정확도가 제각각이었다. 9월 3일 점검은 명백한 오진이 하나뿐이었는데, 표지 이미지 대체 텍스트에 관한 그 하나를 그대로 반영했다면 접근성을 오히려 나쁘게 만들 뻔했다. 9월 4일 받은 개선 지시서는 항목의 절반가량이 이미 구현된 것을 없다고 적었고, 안의 예시 데이터마저 한 책의 저자를 다른 필명으로 적고 있었다. 9월 6일 점검은 거짓 주장이 0건이었고, 한 항목은 지적보다 실제가 더 나빴다. 수정일이 발행일보다 앞서는 날짜 모순이었다.

9월 말 받은 12개 항목 점검은 로그인하지 않은 상태로 다시 보니 11개가 사실, 1개가 틀렸다. 9월 26일에는 한 채팅 AI가 사이트의 robots.txt 때문에 글을 읽을 수 없다고 했다. 로그인하지 않은 요청 세 번이 모두 0.16~0.31초 안에 정상 응답했고, 파일에는 해당 AI 크롤러가 명시적으로 허용되어 있었다. 다른 수집 도구로도 본문을 문제없이 읽었다. 그래서 절차를 정했다. 점검 보고서는 주장 목록으로 받고, 주장마다 어떻게 확인하는지를 붙이며, 확인 방법이 없는 주장은 미확인으로 둔다. 같은 AI에게 다시 물을 때는 지난 답을 재사용하지 말고 지금 상태를 다시 보라고 적는다. 절반이 틀린다는 비율을 상수로 굳히지도 않는다. 점검자와 문서에 따라 편차가 컸으니, 비율 대신 절차를 유지한다.

13.7 검사하는 쪽이 틀릴 때

검증하는 쪽도 틀린다. 9월 8일 Aside가 다른 도구의 코딩 에이전트에게 “네 파일의 분류 목록이 쪼개져 있다”는 결함 보고를 보냈다. 실제 파일은 항목 14개로 정상이었다. 틀린 쪽은 Aside가 대조용으로 급조한 추출식이었다. 따옴표 안의 쉼표까지 잘라 14개를 16개로 세고, 수십 건을 목록 밖으로 잡았다. 이 오류는 상대 에이전트가 먼저 잡아냈다. 9월 16일에는 사이트 주소 225개를 12개씩 동시에 요청하자 6건이 서버 오류(500)로 나왔다. 같은 주소를 1.5초 간격으로 하나씩 세 번 다시 요청하니 모두 정상(200)이었다. 호스팅의 순간 부하로 보였다. 그 뒤로 일괄 점검에서 소수 오류가 나오면, 결함으로 보고하기 전에 하나씩 다시 재현해 본다.

9장에서 소개한 측정 함정 세 가지도 같은 계열이다. 집계가 “전부 0″이나 “전부 같음”으로 나오면 대상보다 파서부터 의심한다. 12장을 올릴 때는 발행 코드에 변수가 빠져 글의 구조화 데이터 주소(@id) 자리에 ‘undefined’가 들어갔다. 발행 뒤 검증 단계에서 발견해 바로 고쳤고, 공개 응답에서 올바른 주소를 확인했다. 판정이 애매한 경우를 위한 규칙도 있다. 다른 AI 채팅 화면의 생성 진행 상태를 읽을 때, 멈춤 버튼은 사라졌는데 끝 표시가 보이지 않으면 끝났다고 추측하지 않고 “모호하다”고 보고하게 했다. 지금까지 본 틀림을 모양별로 모으면 아래와 같다.

틀림의 모양	실제 사례	알아차린 방법	이후 규칙
오류 없이 다른 것을 잡음	webm 파일을 올리자 조용히 무시하고 직전 미디어를 잡음	올린 항목의 해상도와 길이 표기 대조	올린 뒤 표기를 원본과 맞춰 본다. MP4로 올린다
실패처럼 보인 성공	생성 승인 직후 오류 문구, 실제로는 대기열에 접수	대기열 상태와 생성물 개수 확인	오류 문구만 보고 다시 시도하지 않는다
판정 근거가 핵심을 못 봄	정지 프레임으로 동작 성패를 두 번 오판	내가 영상을 재생해 판정	에이전트는 볼 것을 정리하고, 재생 판정은 사람이 한다
자리표시 값이 결과로 기록	전날 19였던 항목이 0으로 기록	기록 뒤 큰 감소폭 점검, 다시 읽자 20	급락이나 급등은 기록 전에 페이지를 다시 연다
오류 없는 중복 기록	상태 칸에 ‘성공성공’	CSV로 내려받아 한 칸씩 대조	매 실행 대조, 불일치 개수 보고
시험이 결함을 통과시킴	A열 시험 쓰기가 붙여넣기 위치 결함을 통과	대상이 A열이 아닐 때 결함이 드러남	시험 쓰기는 G열 등 A열이 아닌 칸에 한다
검사 도구의 결함	추출식이 따옴표 안 쉼표에서 잘라 14개를 16개로 보고	상대 코딩 에이전트가 먼저 지적	집계가 이상하면 파서부터 의심한다
순간 오류를 결함으로 볼 뻔함	주소 225개 중 6건 서버 오류	1.5초 간격으로 하나씩 세 번 재요청, 모두 정상	소수 오류는 하나씩 재현한 뒤 보고한다
발행 뒤 빈 변수	구조화 데이터 주소 자리에 ‘undefined’	발행 뒤 검증 단계	고친 뒤 공개 응답에서 주소를 다시 확인한다
외부 AI의 틀린 진단	robots.txt 때문에 글을 못 읽는다는 주장	로그인 없는 요청 세 번 정상, 파일에 허용 명시, 다른 수집 도구로 본문 확인	주장마다 확인 방법을 붙이고, 없으면 미확인으로 둔다

13.8 검증 조건을 적은 요청

표의 오른쪽 열을 모으면 요청문에 미리 적어 둘 검증 조건이 된다. 결과를 받은 뒤 따지는 것보다, 무엇을 의심하고 어떻게 다시 확인할지를 처음부터 적어 두는 편이 품이 덜 든다. 아래는 숫자를 읽어 시트에 적는 일을 맡길 때의 예다. 페이지, 시트, 값은 모두 가상 설정이다.

[검증 조건을 적은 요청 예시, 가상 설정]
작업: 가상 상품 페이지 30곳에서 재고 숫자를 읽어
      시트 '재고' 탭의 오늘 날짜 열에 기록해
검증 조건:
1. 0이나 -1이 나오면 바로 적지 말고 두 번 더 읽어 같을 때만 기록해
2. 전날보다 절반 넘게 줄거나 두 배 넘게 늘면
   기록 전에 페이지를 다시 열어 직접 읽어
3. 시험 쓰기는 A열이 아닌 G열 빈칸에 해
4. 기록 뒤 시트를 CSV로 내려받아 적으려던 값과
   한 칸씩 대조하고 불일치 개수를 보고해
5. 일부 페이지가 오류를 내면 간격을 두고 하나씩 다시 요청해
   재현될 때만 결함으로 보고해
6. 끝났는지 불분명하면 추측하지 말고 "모호함"으로 표시해
7. 시트 말고 다른 곳에는 아무것도 보내지 마

조건마다 이 장의 사례 하나가 붙어 있다. 1번과 2번은 이상값을 기록 전에 걸러 내고, 3번은 시험이 결함을 드러낼 수 있는 자리에서 돌게 한다. 4번은 오류 없이 잘못 적힌 칸을 잡고, 5번은 순간 오류를 결함으로 부풀리지 않게 한다. 6번은 애매한 상태를 성공으로 뭉개지 않게 한다. 조건이 길어 보여도 한 번 적어 두면 루틴 지시문이나 스킬로 옮겨 계속 쓸 수 있다.

13.9 틀린 걸 알았을 때 Aside에서 하는 일

틀린 것을 알아차린 뒤에는 Aside 안에서 할 수 있는 일이 몇 가지 있다. 2026년 9월 27일에 확인한 도움말 기준이다.

• 작업 상태를 본다. 승인 대기, 답변 대기, 오류, 완료 같은 상태가 표시된다.
• 작업 상세 페이지에서 작업이 만들거나 바꾼 파일을 확인한다. 이미지, PDF, HTML, 텍스트 파일은 미리 볼 수 있다.
• 일반 작업의 대화 기록은 작업 폴더에 저장되므로, 어디서 어긋났는지 되짚을 수 있다.
• 진행 중인 작업이 엉뚱한 쪽으로 가면 후속 메시지를 보낸다. Steer는 진행 중인 실행에 바로 넣어 방향을 고치고, Queue는 현재 실행이 끝난 뒤 적용한다. 선택은 Settings > Agents > Chat에서 한다. 도움말의 예처럼 “청구서 페이지 대신 인보이스 페이지를 쓰고, 메일은 보내지 마”라고 적는 식이다.
• Aside 자체의 문제로 보이면 Settings의 Send feedback이나 작업 상세 페이지의 더보기 메뉴에서 피드백을 보낸다. 작업 피드백에는 대화 기록과 진단 정보를 담을 수 있다. 버그 보고에는 작업 ID, 대략의 시각, 사이트, 기대 결과, 실제 결과, 스크린샷, 오류 문구를 적는다.

틀림을 알아차리는 힘은 결국 기록과 대조에서 나온다. 기대 결과와 실제 결과를 나란히 적을 수 있으면, 피드백이든 스킬이든 다음 요청이든 같은 재료로 쓸 수 있다. 다만 아무리 잘 검증해도 처음부터 맡기지 않는 편이 나은 일이 있다. 14장 「맡기면 안 되는 일」에서 그 경계를 다룬다.

이 장의 확인 범위

기능 설명은 2026년 9월 27일에 확인한 Aside 도움말과 같은 날 내 화면에서 본 것을 기준으로 했다. 이후 화면 이름이나 동작은 바뀔 수 있다.

• 영상 사례는 한 가지 기구 동작을 한 AI 영상 생성 도구로 9번 만든 결과다. 두 번째 도구도 시도했지만 무료 요금제라 생성이 잠겨 있어 비교하지 못했다.
• “모델의 구조적 한계”는 9회 결과를 보고 내린 내 판단이다. 다른 모델이나 다른 기구 동작에도 같은 쏠림이 있는지는 확인하지 않았다.
• 영상-영상 모드의 결과가 기구 동작을 지키는지는 아직 판정하지 않았다.
• 크레딧 비용은 내가 쓴 시점의 표시다. 새 생성 모드의 비용은 안내와 승인 화면이 달랐으니, 승인 화면의 값을 기준으로 본다.
• 외부 AI 점검의 정확도는 내 사이트에 대해 받은 보고서 기준이며, 점검자와 문서에 따라 편차가 컸다. 절반이라는 비율은 일반화하지 않는다.
• 225개 요청 중 서버 오류 6건의 원인을 호스팅의 순간 부하로 본 것은 재요청 결과에서 추정한 것이며 따로 확인하지 않았다.
• 루틴 메모리 파일과 Skills 화면 구성은 내 환경에서 본 것이다.
• 그림 13-1은 설명용 도식이다. 그림 13-2와 13-3은 실제 화면이며 일부 이름과 문구를 가상 값으로 바꾸거나 일반화했다. 요청 예시의 페이지, 시트, 값은 가상이다.

참고한 자료

2026년 9월 27일 확인. 작업 실행 도움말 · 문제 해결 도움말

다음 글: 14장 · 맡기면 안 되는 일
이전 글: 12장 · 노트북을 닫으면 누가 일하나
『Aside 브라우저 사용설명서』 연재 목록

저자의 실제 사용 경험과 Aside 도움말을 바탕으로 AI의 도움을 받아 작성·편집했습니다. 초판 선공개 원고 v1.0.