AI 용어 40개, 실무에서 막힌 순서대로

지난 몇 달 동안 업무에 AI 도구를 붙여본 기록을 열 편쯤 남겼습니다. 열 편입니다. 그 기록을 다시 읽어보니 일이 막힌 지점마다 공통점이 하나 있었습니다. 도구가 부실한 게 아니었습니다. 화면에 뜬 단어를 제가 잘못 알아들었던 것이고, 그 오해가 매번 같은 자리에서 저를 붙잡아 세웠습니다.

“세션을 지우면 비용이 줄겠지”라고 믿고 수백 개를 지웠는데 비용은 한 푼도 줄지 않았던 일, “지침을 저장해뒀으니 경로만 주면 되겠지”라고 생각했다가 반나절을 통째로 날린 일, 승인 버튼 하나가 실제로 무엇을 실행하는지 몰라서 위험한 문구를 그대로 두고 넘어갔던 일까지, 전부 용어를 어떻게 알아들었느냐에서 갈렸습니다.

그래서 사전에 실린 정의는 접어두고, 제가 그 단어를 실제로 마주쳤던 화면과 그 자리에서 알았어야 했던 뜻만 골라 정리했습니다. 개발자용 설명은 아닙니다. 사무직 실무자가 도구를 굴리다 막히는 지점이 기준입니다.

모델: 실제로 생각하는 부분

내가 던진 말을 읽고 답을 만들어내는 엔진입니다. 도구 이름, 앱 이름, 화면 이름은 전부 껍데기이고, 그 안에서 실제로 판단하는 알맹이가 모델입니다. 껍데기는 여러 개, 알맹이는 하나입니다.

이 단어를 가장 자주 마주치는 자리는 설정 화면과 요금 화면입니다. 둘 다 돈이 걸린 화면입니다. 사용량 표시를 앱 타이틀바에 붙이는 작업을 할 때, 화면에 띄우려던 값 네 가지 중 하나가 지금 돌고 있는 모델이었는데, 무거운 모델로 파일 이름 바꾸기 같은 단순 작업을 시키고 있어도 화면 어디에도 아무 표시가 뜨지 않는다는 게 그 작업을 시작한 이유였습니다.

모르면 생기는 문제는 두 방향입니다. 하나는 돈입니다. 파일 이름 바꾸기처럼 판단이 거의 필요 없는 일에 가장 비싼 모델을 물려두면, 그 차액이 한 번도 빠짐없이 매번 나갑니다. 실제로 토큰 절감 작업에서는 제목 생성, 대화 압축, 메모리 검색처럼 결과물이 눈에 보이지 않는 배경 작업만 저렴한 경량 모델로 내렸고, 답변 품질이 그대로 드러나는 본 대화 모델은 손대지 않고 그대로 뒀습니다. 반대 방향의 착각도 있습니다. 단톡방 사진을 자동으로 내려받게 하려다 실패했을 때, 그러면 상위 모델로 바꾸면 되느냐고 물었습니다. 크게 달라지지 않는다는 답이 돌아왔습니다. 그 문제는 애초에 추론 능력이 아니라 화면 인식과 좌표의 문제였고, 모델을 아무리 올려도 버튼을 안정적으로 눌러 맞히는 능력은 조금도 달라지지 않기 때문이었습니다. 돈만 더 나갈 뻔했습니다.

혼동하기 쉬운 것은 앱과 모델입니다. 제가 매일 여는 창은 앱입니다. 그 창이 말을 거는 상대가 모델입니다. 앱을 바꿔도 모델은 그대로일 수 있습니다. 실제로 앱을 편집기 밖으로 꺼내 완전히 독립된 창으로 다시 실행했을 때도, 기존 모델 인증과 그동안 쌓인 세션 목록은 아무것도 다시 설정하지 않았는데 그대로 따라왔습니다.

토큰: 글자를 세는 단위이자 요금 단위

AI가 읽고 쓰는 글의 양을 세는 단위입니다. 그게 전부입니다. 한글은 대략 한 글자가 한 토큰 안팎입니다. 실무 감각으로는 그 정도면 충분합니다. 중요한 건 계산법이 아닙니다. 무엇이 세어지느냐입니다.

토큰이 눈에 보이는 숫자로 나온 건 비용 절감 작업 때였습니다. 매 대화마다 자동으로 따라붙던 설정 파일 하나가 턴당 약 26,600토큰이었습니다. 원인은 이랬습니다. 그 앱의 기본 작업 폴더가 하필 앱 소스코드 폴더로 잡혀 있었고, 그 폴더에 들어 있던 106KB짜리 개발자용 지침 파일이 재무 정산을 묻든 블로그 원고를 시키든 상관없이 매 턴 같이 실려 나가고 있었습니다. 이것을 포함해 일곱 가지를 정리하니 총 28,200토큰이 빠졌습니다. 손댄 건 설정 몇 줄이었습니다.

모르면 생기는 문제는 비용의 원인을 엉뚱한 데서 찾는 것입니다. 저는 오래 “질문을 많이 해서 비싸다”고 믿었습니다. 아니었습니다. 실제로는 질문 한 마디를 던질 때마다 그 뒤에 자동으로 얹혀 나가는 짐이 문제였습니다. 하루에 백 번 말을 걸면 그 짐도 백 번 실립니다. 질문이 아니라 짐이 비용이었습니다.

혼동하기 쉬운 것은 대화 횟수와 토큰입니다. 이 둘은 비례하지 않습니다. 짧게 자주 묻는 게 아껴주지 않습니다. 매 턴 자동으로 붙는 짐이 크면, 오히려 짧은 질문일수록 본문 대비 짐의 비율이 커져서 손해가 커집니다.

컨텍스트: 지금 이 대화에 실려 있는 짐

모델이 이번 답 하나를 만들려고 실제로 읽는 자료 전부를 말합니다. 내가 넣은 것만이 아닙니다. 지금까지 나눈 대화, 중간에 열어본 파일 내용, 매번 자동으로 붙는 지침이 전부 여기에 차곡차곡 쌓입니다. 토큰이 자라면, 컨텍스트는 그 자로 재는 대상입니다.

이 단어를 처음 눈으로 본 건 영수증 캡처 21장을 맡겼을 때였습니다. 판독 도구를 호출했더니 이미지 대신 `[screenshot removed to save context]`라는 문자열이 돌아왔습니다. 컨텍스트를 아끼려고 스크린샷을 뺐다는 뜻입니다. 도구는 분명히 호출됐는데, 정작 이미지 데이터는 모델 쪽으로 한 장도 넘어가지 않은 상태였습니다. 호출과 전달은 다른 일이었습니다.

또 한 번은 웹사이트 하나를 통째로 문서로 만들 때였습니다. 에이전트가 페이지를 하나씩 열어 읽으면 그 페이지 수만큼 컨텍스트에 그대로 쌓이고, 쌓인 만큼 빠짐없이 과금됩니다. 그래서 방식을 바꿨습니다. 모델은 크롤러를 짜기만 하고, 본문을 실제로 내려받아 파일에 쓰는 일은 그 프로그램이 혼자 하게 했습니다. 1,000개를 긁어도 모델이 소비하는 양은 코드 몇 개 분량이 됩니다. 페이지 수와 비용이 끊어집니다.

모르면 생기는 문제는 두 가지입니다. 원문을 통째로 읽히면 그 분량이 그대로 비용이 되고, 자료가 길수록 답 한 줄을 받는 값이 같이 올라갑니다. 반대 방향도 있습니다. 컨텍스트가 가득 차오르면 도구가 알아서 오래된 부분을 솎아내는데, 하필 방금 넣은 자료가 그때 조용히 빠져나가도 화면에는 아무 표시가 남지 않습니다.

혼동하기 쉬운 것은 저장과 컨텍스트입니다. 둘은 다릅니다. 파일로 저장해둔 것과 지금 모델이 읽고 있는 것은 별개이고, 저장은 디스크 어딘가에 글자가 남아 있다는 뜻일 뿐입니다. 저장돼 있어도 이번 대화에 불러오지 않으면 모델은 그 내용을 모릅니다.

세션: 대화 한 칸

한 주제로 열어둔 대화 창 하나입니다. 창을 새로 열면 새 세션입니다. 이전 세션은 목록에 남습니다.

세션 때문에 가장 크게 헛돈 기록이 비용 절감 편에 있습니다. 저는 세션이 쌓이면 비용이 오른다고 믿고, 오래된 세션을 몇 달 동안 주기적으로 지워왔습니다. 확인해보니 세션은 그냥 로컬 DB에 저장만 되고 모델 쪽으로는 한 글자도 전송되지 않았습니다. 391개든 3,000개든 턴당 토큰은 같았습니다. 완전히 헛짚었습니다. 모델이 받는 건 지금 열려 있는 대화 하나뿐입니다. 당시 DB는 세션 391개에 메시지 21,432개, 233MB였는데, 제가 지운 15MB는 비용을 한 푼도 아껴주지 않은 채 “그때 그거 어떻게 했더라”를 나중에 검색해볼 자산만 줄여놨습니다.

세션이 상태를 들고 있다는 것도 뒤늦게 알았습니다. 창 하나가 설정까지 기억합니다. 조직도에 AI 담당자를 붙이는 작업에서 사용 한도에 걸려 기본 모델을 바꿨는데 응답이 이상했습니다. 원인은 엉뚱한 데 있었습니다. 세션을 이어서 부르면 그 대화에 저장돼 있던 이전 모델이 설정을 덮고 그대로 복원되는 구조였습니다. 설정만 바꾸고 이어붙이면 새 모델이 적용되지 않습니다. 고장이 아닙니다. 설정 변경이 다음 세션부터 온전히 적용된다는 것도 같은 이유입니다.

모르면 생기는 문제는 중복입니다. 같은 일을 두 번 합니다. 어디까지 했는지가 안 보이니 같은 주제로 창을 새로 열고, 저번에 했던 설명을 처음부터 토씨까지 다시 하게 됩니다. 그 반복이 실제 비용이었습니다.

혼동하기 쉬운 것은 세션과 기억입니다. 목록에 세션이 남아 있다고 해서, 새로 연 세션이 그 안의 내용을 알고 시작하는 건 아닙니다. 담당자를 둘로 늘렸을 때 각자에게 독립된 세션과 독립된 대화 기록 파일을 따로 준 것도, 그렇게 나눠두지 않으면 두 담당자가 서로의 맥락을 자기 것인 양 물고 들어오기 때문이었습니다.

에이전트: 대답만 하지 않고 손을 대는 쪽

질문에 답만 하고 끝나는 게 아니라 파일을 열고, 폴더를 만들고, 프로그램까지 실행하는 AI를 에이전트라고 부릅니다. 구분선은 단순합니다. 내 컴퓨터나 계정에서 무언가를 실제로 바꾸느냐, 그것뿐입니다.

에이전트를 조직도에 담당자로 한 명 심어본 기록이 이 단어의 실제 사례입니다. 담당자 한 명을 세우려면 담당 역할, 업무 지침, 접근 가능한 자료, 사용할 도구, 보고 형식, 실행 조건, 승인 범위, 업무 이력까지 여덟 가지를 빠짐없이 정의해야 했습니다. 하나라도 비면 그럴듯한 말만 하고 끝났습니다. 여덟 개는 많아 보이지만, 사람 한 명을 새로 뽑아 자리에 앉힐 때 알려줘야 하는 것을 적어보면 결국 그 정도가 나옵니다. 특히 접근 가능한 자료 칸이 비어 있으면 “확인 가능한 자료만으로는 원인을 확정할 수 없습니다”라는 답만 돌아왔습니다.

모르면 생기는 문제는 권한 착각입니다. 양쪽으로 생깁니다. 승인 팝업을 만들어두고 눌러봤습니다. 승인했다는 텍스트가 다시 전달되고 회신 문구가 정리되는 게 전부였습니다. 전송 도구가 붙어 있지 않았으니 발송은 여전히 사람이 복사해서 보내야 했습니다. 반대쪽이 더 위험합니다. 지급 실행과 회신 발송을 한 팝업에 묶어두면, 버튼 한 번에 이체까지 나가는 것처럼 읽힙니다.

혼동하기 쉬운 것은 채팅형 AI와 에이전트입니다. 사고의 크기가 다릅니다. 채팅형은 틀린 답을 해도 내가 안 쓰면 그만입니다. 에이전트는 다릅니다. 틀린 판단이 곧바로 파일 삭제나 이동으로 이어지고, 그때는 이미 되돌릴 것이 남아 있지 않습니다. 그래서 자료 조회 도구를 등록할 때 조회용만 허용했습니다. 수정 계열은 전부 뺐습니다.

프롬프트: 이번에 던지는 말

지금 입력창에 쓰는 문장이 프롬프트입니다. 이번 한 번만 유효합니다.

실무에서 프롬프트가 결정적으로 작용한 순간은 오히려 짧은 질문이었습니다. 영수증 작업이 계속 막혔을 때 제가 던진 “왜 안 되지, 예전엔 잘 됐는데. 기존 자료 샘플도 있는데”라는 한 마디로 흐름이 통째로 바뀌었습니다. 긴 지시문이 아니었습니다. 방향을 트는 짧은 질문 하나가 일을 풀었습니다.

모르면 생기는 문제는 프롬프트에 모든 걸 담으려는 습관입니다. 매번 같은 설명을 처음부터 다시 쓰게 되고, 어제는 잘 되던 표현이 오늘 안 먹히면 무엇이 달라진 건지 짚을 근거가 아무것도 남아 있지 않습니다. 반복 업무에서 관리해야 하는 건 프롬프트가 아닙니다. 다음 항목인 지침입니다.

혼동하기 쉬운 것은 질문문과 지침의 차이입니다. 유효기간이 다릅니다. 프롬프트는 이번 대화에만 남습니다. 지침은 다음에도 자동으로 불려 나옵니다. 이번만 다르게 하고 싶은 건 프롬프트에 두고, 매번 같아야 하는 건 지침에 둡니다. 실제 운용은 여기서 갈렸습니다.

스킬: 저장해두고 매번 불려 나오는 지침

작업 절차를 미리 문서로 적어두면 AI가 그 작업을 할 때 알아서 찾아 불러 씁니다. 도구마다 부르는 이름은 다르지만 성격은 같습니다. 사람으로 치면 인수인계 문서입니다.

이 단어가 가장 아프게 남은 사례가 영수증 정리 건입니다. 매달 하는 일이고 지침도 미리 만들어뒀으니, 폴더 경로만 던져주면 알아서 끝날 거라고 생각했습니다. 실제로는 그 지침 안에 “이미지만 붙이면 됨, 판독 불필요”라고 적혀 있었습니다. 몇 달 전 양식을 기준으로 쓴 문장이었습니다. 그 사이에 양식은 상단 합계와 엑셀에 그대로 붙여넣을 내역이 들어가는 형태로 이미 바뀌어 있었고, 그 칸을 채우려면 결국 영수증을 한 장씩 읽어야 합니다. AI는 지침을 제대로 불러왔고 충실히 따랐습니다. 문제는 그 지침이었습니다. 지침이 없어서 실패한 게 아니라, 몇 달 전에는 맞았던 문장이 그대로 남아 있어서 실패했습니다.

모르면 생기는 문제가 여기 있습니다. 속도가 문제입니다. 사람은 그렇게 안 합니다. “지난달 파일 뭐였지” 하면서 폴더를 최신순으로 정렬하고 맨 위를 엽니다. 지침을 문서로 박아두면 그 문서가 갱신되지 않는 한 몇 달 전 판단이 계속 최신인 것처럼 실행됩니다. 자동화의 이득이 그대로 오답의 반복 속도가 됩니다. 그래서 지침 첫 줄을 바꿨습니다. “결과물 폴더를 최신순으로 정렬해 가장 최근 것을 연다”입니다.

저장 위치가 도구마다 다르다는 것도 이때 알았습니다. 편집기에 붙여 쓰는 코딩 AI와 독립 실행 앱은 애초에 서로 다른 폴더를 들여다봅니다. 한쪽에 21개를 만들어 뒀는데 다른 쪽은 그중 하나도 쓸 수 없었습니다. 같은 컴퓨터 안에서 그랬습니다.

지침은 공짜가 아닙니다. 쌓아둘수록 나갑니다. 이름과 한 줄 설명이 매 턴 같이 전송되는 구조라서, 실제로 쓰든 안 쓰든 등록해둔 개수가 곧 비용이 됩니다. 비용 절감 작업에서 118개를 76개로 줄였습니다. 파일을 지우지는 않고 설정에서 비활성으로만 돌렸습니다. 절감액은 600토큰 정도로 크지 않았습니다. 다만 지워버리면 나중에 되돌릴 때 비용을 두 번 치른다는 기준은 그대로 남겼습니다.

배치: 여러 갈래로 나눠 동시에 돌리기

한 덩어리 일을 여러 조각으로 쪼개 동시에 돌리는 방식입니다. 사람으로 치면 네 명에게 나눠 맡기는 것입니다. 도구에 따라 병렬, 묶음 처리, 하위 작업자처럼 다른 이름으로 나오기도 합니다.

실제 사례는 영수증 편에 있습니다. 남은 18장을 하위 작업자 4개에 갈라 동시에 판독시켰습니다. 분배 직후에는 4개 모두 이미지를 정상적으로 받았다고 나왔습니다. 그런데 36분 44초를 기다린 끝에 돌아온 응답은, 분배를 지시한 쪽이 결과를 기록하기 전에 종료돼 결과를 알 수 없다는 것이었습니다. 판독이 됐는지조차 확인이 안 됐습니다. 36분의 대가가 “알 수 없음”이었습니다.

모르면 생기는 문제는 중간 결과가 통째로 날아가는 것입니다. 나눠 돌리는 방식 자체는 좋습니다. 다만 각 조각이 결과를 파일로 먼저 떨어뜨리게 해두지 않으면, 마지막 한 번의 실패로 앞에서 멀쩡히 끝난 작업까지 전부 같이 사라집니다. 이후로는 분배 작업을 시킬 때 결과를 반드시 파일에 먼저 쓰게 합니다.

혼동하기 쉬운 것은 배치와 새 세션입니다. 비슷해 보여도 다릅니다. 무거운 조사 작업을 시킬 때 “새 세션을 하나 열어서 거기서 돌리자”는 생각이 먼저 들었습니다. 그건 없애려던 중복 세션을 하나 더 만드는 짓이었습니다. 하위 작업 위임은 다릅니다. 중간 데이터가 내 대화에 쌓이지 않고 결과만 돌아오는 구조입니다. 병렬 작업을 여러 창으로 관리하는 도구는, 병렬 작업이 실제로 늘어난 다음에 붙여도 전혀 늦지 않았습니다.

스크립트: AI가 짜고 컴퓨터가 실행하는 절차서

정해진 순서대로 컴퓨터가 실행하는 명령 묶음입니다. 문법은 몰라도 됩니다. 실무자 시점에서 중요한 건 역할입니다. 스크립트가 도는 동안 모델은 쉽니다.

드라이브 정리 작업에서 첫 단계는 삭제가 아니었습니다. 목록 만들기였습니다. 파일 경로, 크기, 수정 시각, 확장자만 뽑아 CSV로 떨구는 스크립트를 돌렸습니다. 판단은 나중이었습니다. 지도부터 만든 것입니다. 나중에는 4단계로 나눈 스크립트를 밤새 돌렸습니다. 이 방식이 유효했던 이유는 하나입니다. 파일 수십만 개를 모델에게 단 한 번도 읽히지 않았기 때문입니다. 웹사이트 아카이빙도 같았습니다. 모델은 크롤러를 쓰고 결과 통계를 확인할 뿐이었습니다.

모르면 생기는 문제는 “AI에게 시켰다”는 말의 범위를 착각하는 것입니다. AI가 자료를 모은 게 아닙니다. AI가 프로그램을 짜고, 그 프로그램이 일한 경우가 대부분입니다. 이 구분을 해두면 어디서 비용이 나가고 어디서 안 나가는지가 바로 보입니다.

혼동하기 쉬운 것은 코딩과 스크립트 사용입니다. 저는 코딩을 하지 않습니다. 저는 코드를 붙잡고 있지 않습니다. 자연어로 방향을 교정하고, 결과가 이상하면 다시 지시합니다. 다만 그 스크립트가 내 파일의 무엇을 건드리는지 정도는 알고 있어야 합니다. 엑셀 양식을 손보던 중에 제가 파일을 직접 열어 폰트와 테두리까지 고쳐놓은 상태였는데, 그 상태에서 스크립트로 통째로 다시 저장했다면 손으로 맞춘 서식이 그대로 날아갈 상황이었습니다. 그때부터는 필요한 값만 골라 바꾸게 하고, 백업을 먼저 남깁니다. 한글 인코딩이 깨진 파일명 딱 하나 때문에 목록 생성 스크립트 전체가 멈춰 선 적도 있습니다.

캐시: 한 번 읽은 것을 잠시 들고 있기

같은 것을 두 번 가져오지 않으려고 잠시 저장해두는 임시 보관입니다. 실무에서는 대개 비용이나 속도 이야기와 붙어 나옵니다.

비용 절감 작업에서는 프롬프트 캐시 유지 시간을 5분에서 1시간으로 늘렸습니다. 5분은 짧습니다. 잠깐 다른 일을 보다 돌아오는 사이에 캐시가 날아가고, 조금 전과 똑같은 내용을 처음부터 다시 전송하게 됩니다. 반대로 캐시가 깨지는 쪽도 겪었습니다. 진행 중인 세션에서 외부 연동을 다시 켜면 캐시가 깨져 오히려 비용이 튑니다. 켠 다음 새 세션을 여는 게 맞았습니다.

사용량 표시를 만들 때는 제가 직접 캐시를 걸었습니다. 표시용 정보 하나 때문에 외부 조회를 계속 내보내면 그것도 결국 비용이라, 60초짜리 캐시를 두고 조회에 실패하더라도 오류를 던지는 대신 “사용 불가”만 조용히 돌려주게 했습니다.

캐시가 벽이 된 적도 있습니다. 이번엔 반대였습니다. 메신저에서 사진을 꺼내려고 내부 캐시를 직접 열어보는 우회로를 검토했습니다. 암호화된 형식이라, 파일만 복사해서는 복원할 수 없었습니다.

모르면 생기는 문제는 변경이 반영되지 않는 상황을 고장으로 오해하는 것입니다. 고장이 아닙니다. 설정을 바꿨는데 화면이 그대로면, 십중팔구 이전 값이 캐시에 그대로 남아 있는 것입니다.

혼동하기 쉬운 것은 캐시와 저장입니다. 무게가 다릅니다. 캐시는 사라져도 되는 사본입니다. 저장은 사라지면 안 되는 원본입니다. 캐시에 있는 것을 자료로 믿고 원본을 지우면 그대로 손실입니다.

이 용어들이 어떻게 연결되는지

낱개로 외우면 안 붙습니다. 실제로는 한 줄로 이어집니다.

순서	용어	하는 일	앞뒤 관계
1	모델	판단하고 답을 만듭니다	아래 모든 것이 결국 모델에게 전달됩니다
2	에이전트	모델의 판단으로 실제 작업을 실행합니다	모델 + 도구 + 지침이 합쳐진 형태입니다
3	세션	대화 한 칸을 담습니다	세션이 바뀌면 모델 설정과 맥락이 초기화됩니다
4	컨텍스트	이번 세션에서 모델이 읽는 자료 전부입니다	세션 안에 쌓이고, 길어지면 앞부분이 잘려나갑니다
5	토큰	컨텍스트의 크기를 재는 단위입니다	컨텍스트가 커지면 토큰이 늘고 그대로 요금이 됩니다
6	프롬프트	이번 턴에 내가 넣는 말입니다	컨텍스트에 더해지는 가장 작은 조각입니다
7	스킬	매번 자동으로 불려 나오는 지침입니다	프롬프트와 달리 세션이 바뀌어도 따라옵니다
8	배치	일을 쪼개 동시에 돌립니다	조각마다 별도 컨텍스트를 쓰므로 내 대화가 가벼워집니다
9	스크립트	컴퓨터가 직접 실행하는 절차입니다	이 구간은 모델을 거치지 않아 토큰이 들지 않습니다
10	캐시	이미 보낸 것을 잠시 들고 있습니다	같은 컨텍스트를 다시 보내는 비용을 줄여줍니다

읽는 방향은 이렇습니다. 모델이 일하고, 에이전트가 그 판단으로 손을 대고, 그 작업은 세션 안에서 벌어지며, 세션 안에 쌓인 컨텍스트를 토큰으로 세어 요금이 매겨집니다. 프롬프트는 이번 한 번입니다. 스킬은 매번입니다. 배치와 스크립트는 모델이 읽어야 할 양을 줄이는 두 가지 방법이고, 캐시는 이미 보낸 것을 다시 안 보내게 하는 장치입니다.

이 용어들이 실제로 문제를 일으킨 글

각 단어가 실제로 사고를 낸 현장 기록은 따로 남겨뒀습니다. 아래가 그 목록입니다.

• 스킬과 배치가 동시에 무너진 기록은 영수증 캡처 21장을 AI에게 맡겼다가 반나절을 날린 기록에 있습니다. 낡은 지침을 그대로 믿고 충실히 따르다 실패한 과정과, 남은 물량을 하위 작업자 4개에 나눠 돌렸다가 결과를 통째로 잃은 대목이 여기 나옵니다.
• 스크립트가 사람 대신 일한 사례는 드라이브 데이터를 정리하면서 하나도 잃지 않은 순서에 있습니다. 삭제보다 목록이 먼저였던 이유가 여기 있습니다.
• 세션과 모델 인증이 앱과 별개로 움직인다는 것을 확인한 기록은 AI 작업 환경을 편집기 밖으로 꺼낸 기록입니다.
• 에이전트에게 어디까지 권한을 줄지 정한 기록은 조직도에 AI 담당자를 심어본 기록입니다. 승인 버튼이 실제로 무엇을 실행하는지 확인한 대목이 있습니다.
• 토큰, 컨텍스트, 캐시, 세션이 한꺼번에 나오는 글은 AI 에이전트 토큰 비용을 반으로 줄인 기록입니다. 이 글의 숫자는 대부분 여기서 나왔습니다.
• 컨텍스트를 안 쓰고 자료를 모으는 방법은 웹사이트 하나를 문서 한 개로 아카이빙한 기록에 있습니다.
• 모델을 올려도 해결되지 않는 문제의 사례는 단톡방 사진 정리를 AI에게 맡겼다가 실패한 기록입니다.
• 모델과 사용량을 화면에 띄우고 캐시를 건 기록은 AI 사용량을 타이틀바에 붙인 기록입니다.
• 스크립트가 손으로 고친 서식을 덮어쓸 뻔한 사례는 문서 양식을 다시 만든 기록에 있습니다.
• 도구를 사서 쓸지 만들지 판단한 기록은 ERP를 사는 것과 만드는 것을 비교한 기록입니다.

용어를 정확히 알면 일이 저절로 풀리지는 않습니다. 그렇게까지 되지는 않습니다. 다만 막혔을 때 어디를 먼저 봐야 하는지가 달라집니다. 저는 비용의 원인을 세션에서 찾다가 한참을 헤맸고, 실패의 원인을 도구에서 찾다가 결국 제가 몇 달 전에 써둔 지침 한 줄에서 발견했습니다. 그 시간 차이가 이 글을 쓴 이유입니다.