「직접 해 보기:」 https://link.chlee.dev/38vfq7.html (설치·로그인 없음. 「샘플 넣기」 한 번이면 전후가 나란히 보입니다. 붙여넣은 글은 브라우저 밖으로 나가지 않고, 화면 오른쪽 위에 외부 요청 횟수가 표시됩니다.)

1. 어떤 상황에서 AI를 활용했나요

AI를 업무에 제대로 쓰기 시작하면 아무도 처음에 말해주지 않는 문제가 생깁니다. 「AI는 읽은 만큼 돈을 받습니다.」 그리고 한 번에 읽을 수 있는 분량에도 한도가 있습니다.

저는 개발 업무를 하면서 매일 AI에게 일을 시킵니다. 자료를 붙여넣고, 파일을 읽히고, 명령을 실행해 그 결과를 다시 보여줍니다. 하루에도 수백 번 이런 주고받기가 일어납니다. 그런데 AI에게 넘어가는 자료를 한참 들여다보니, 「상당 부분이 AI가 볼 필요가 없는 것들」이었습니다.

- 「파일 목록」에는 파일마다 권한 표시(-rw-r--r--), 소유자, 그룹, 수정 시각이 붙어 옵니다. 대부분의 질문에 필요한 건 이름과 크기뿐입니다.
- 「로그」에는 같은 경고가 수십, 수백 번 반복됩니다. 필요한 건 "이 경고가 몇 번 나왔다"와 그 아래 진짜 오류 한 줄입니다.
- 「웹페이지」를 통째로 넘기면 메뉴, 광고, 추적 스크립트, 꼬리말이 본문보다 깁니다.
- 「검색 결과」는 여러 곳에서 같은 문장을 되풀이합니다.
- 「긴 파일」은 처음부터 끝까지 통째로 읽히는데, 실제로 필요한 건 그중 한 부분입니다.

이게 두 가지 손해를 만들었습니다.

「첫째, 비용이 샙니다.」 안 봐도 되는 걸 읽히고 그만큼 사용량을 씁니다. 사용량 한도가 있는 요금제에서는 한도가 일찍 차서 일이 멈춥니다.

「둘째, 더 큰 손해는 정확도입니다.」 AI가 한 번에 기억할 수 있는 분량은 정해져 있는데, 군더더기가 그 자리를 차지하면 「정작 중요한 내용이 밀려 나갑니다.」 긴 로그를 통째로 붙여넣었을 때 AI가 엉뚱한 곳을 짚는 이유가 이것입니다. 머리가 나빠서가 아니라 「책상 위가 잡동사니로 덮여 있어서」입니다.

그래서 질문을 바꿨습니다. "AI에게 어떻게 잘 물어볼까"가 아니라 「"AI에게 무엇을 안 보여줄까"」 입니다.

2. 어떤 AI를 어떻게 활용했나요

AI 코딩 에이전트(Claude)에게 일을 시키는 흐름 한가운데에 「자료 정리 단계」를 하나 끼워 넣었습니다. 이 단계 자체도 AI와 함께 만들었습니다. 무엇을 버려도 되는지 규칙을 같이 정하고, 제가 실제로 쓰는 자료로 시험하고, 잘못 버린 사례가 나오면 규칙을 고치는 식입니다. 구조는 [그림 2]와 같습니다.

「① 보내기 전에 한 번 거릅니다.」 명령을 실행하면 결과가 AI에게 가기 전에 이 단계를 자동으로 통과합니다. 사람이 신경 쓸 일이 없습니다. 자료 종류마다 버릴 것이 정해져 있습니다.

자료 종류 / 남기는 것 / 버리는 것
파일 목록 / 이름, 크기 / 권한·링크 수·소유자·그룹·수정 시각
로그 / 처음 한 줄 + 반복 횟수 (×N), 오류 줄 / 같은 줄의 반복
웹페이지 / 제목, 본문 / 메뉴·광고·추적 스크립트·꼬리말
검색 결과 / 여러 검색 결과를 합친 뒤 상위 몇 개의 본문 / 중복된 결과, 하위 결과의 본문
긴 파일 / 제목·목차·함수 이름 같은 「구조」 / 처음에는 본문 전체 (필요한 줄만 나중에 다시 읽음)

마지막 줄이 가장 크게 먹혔습니다. 사람도 두꺼운 책을 처음부터 읽지 않고 목차를 먼저 봅니다. 「AI에게 목차를 먼저 주고, 필요한 쪽만 펼치게 하는 것」만으로 읽히는 분량이 크게 줄었습니다. 실제 누적 기록에서도 파일을 읽는 명령과 검색 명령이 절감량의 대부분을 차지했습니다(첨부 상세서 2절 표).

「② 얼마나 줄었는지 매번 기록합니다.」 이게 없었으면 이 사례는 "줄어든 것 같다"로 끝났을 겁니다. 정리 단계를 통과할 때마다 원래 분량과 줄인 분량을 자동으로 남기게 했습니다. 이 글을 다듬으면서 2026년 9월 23일에 웹페이지 세 개를 다시 읽혀 본 기록은 이렇습니다.

위키백과 「광합성」 문서 653KB → 56KB -92%
해외 개발자 뉴스 첫 화면 34KB → 2KB -93%
정부 정책 포털 첫 화면 209KB → 574B 거의 전부 제거

세 번째는 일부러 넣었습니다. 포털 첫 화면은 거의 메뉴와 배너뿐이라 남는 게 없습니다. 「많이 줄었다고 좋은 게 아니라, 남은 게 쓸모 있어야 합니다.」 이런 경우에는 첫 화면이 아니라 필요한 기사 주소를 직접 읽힙니다.

「③ 손실이 나면 안 되는 곳에는 안 씁니다.」 압축은 정보를 버리는 일이라 아무 데나 쓰면 안 됩니다. 그래서 「탐색·조사 단계에서만」 켜고, 실제로 문서를 고치거나 코드를 수정하는 단계에서는 「원문 그대로」 읽습니다. 요약본을 보고 고치면 없는 줄을 고치려 들거나 공백 하나 차이로 수정이 어긋납니다. 이 구분이 이 사례에서 가장 중요한 판단입니다.

「④ 작은 판단은 로컬 모델에 맡겼습니다.」 어떤 규칙을 적용할지 애매한 자료를 가르는 일처럼 가벼운 판단은 내 컴퓨터에서 도는 오픈모델(Gemma)로 시험했습니다. 무거운 추론만 큰 모델이 하고, 잡일은 작은 모델이나 규칙이 처리하게 나눈 것입니다.

3. 활용 결과 어떤 변화가 있었나요

정리 단계가 자동으로 남긴 누적 기록을 2026년 9월 23일에 그대로 조회했습니다 [그림 1].

토큰은 AI가 글을 세는 단위로, 한글 한두 글자쯤이 1토큰입니다. M은 100만입니다. [그림 1]의 검은 상자에서 Input tokens는 「정리 전」 분량, Output tokens는 「정리 후」 분량입니다(AI가 답한 분량이 아닙니다).

지표 / 값 / 비고
누적 처리 명령 수 / 「236,833건」 / 2026년 6월부터 실사용 누적
정리 전 명령 출력 분량 / 약 3억 4,270만 토큰 / 342.7M
정리 후 명령 출력 분량 / 약 7,460만 토큰 / 74.6M
절감된 분량 / 「약 2억 6,820만 토큰」 / 268.2M
명령 출력 분량 절감률 / 「78.2%」 / 268.2M ÷ 342.7M
명령 1건당 평균 실행 시간 / 「0.32초」 / 사람이 거의 느끼지 못하는 수준
파일 목록 정제 (예: 현재 폴더 목록) / 평균 「-73.5%」 / 같은 명령 490회 누적
웹페이지 1건 정제 / 653KB → 56KB (「-92%」) / 2026-09-23 재측정

「기준을 밝힙니다. 78.2%는 AI에게 넘어가는 명령 출력의 분량 기준이며, 전체 AI 사용량 절감률이 아닙니다.」 제가 쓴 질문, AI의 답변, 대화의 나머지 부분은 이 집계에 들어가지 않습니다. 과장하지 않기 위해 기준을 먼저 적습니다.

월별로 보면 쓰는 방식이 자리 잡는 과정이 보입니다. 처음 쓴 6월에는 2,360건에 절감률 3.2%였고, 규칙을 늘린 7월 52.0%, 8월 78.6%로 올라갔습니다. 9월(23일까지)은 16만 1천 건으로 사용량이 크게 늘었습니다. 9월 절감률은 99.3%로 잡혔지만, 월별 비율은 그 달에 어떤 명령을 많이 썼는지에 따라 크게 흔들리므로 「대표값으로는 누적 78.2%만 씁니다.」

「작은 예로 보면 이렇습니다.」 데모에 들어 있는 샘플은 파일 목록 5줄, 같은 경고가 12번 반복되는 빌드 로그, 학교 공지 웹페이지 한 장을 이어 붙인 40줄짜리 글입니다(샘플은 설명용으로 만든 것입니다). 정리 단계를 거치면 「2.0KB가 553바이트로, 40줄이 14줄로」 줄어 73.2%가 빠집니다(2.0KB는 반올림한 표기이고, 비율은 실제 바이트 수로 계산했습니다). 남는 것은 파일 이름과 크기, 경고 한 줄과 「×12」, 오류 줄, 공지 제목과 본문 두 문장입니다. AI에게 "빌드가 왜 실패했지?"라고 물을 때 필요한 정보는 하나도 빠지지 않았고, 오류 줄이 화면 가운데로 올라왔습니다. 어떤 줄을 왜 지웠는지는 오른쪽 목록을 누르면 원본의 해당 줄이 노랗게 켜져서 바로 확인됩니다 [그림 3].

「비용보다 체감이 컸던 건 긴 자료를 겁내지 않게 된 것입니다.」 예전에는 로그가 길면 붙여넣기를 포기하고 제가 눈으로 훑었습니다. 지금은 그냥 넘깁니다. 반복 줄은 접히고 오류 줄만 남으니 AI가 바로 원인을 짚습니다. 「"AI에게 맡길 수 있는 일의 범위"가 넓어졌습니다.」

또 하나는 사용량 한도입니다. 같은 한도 안에서 더 많은 일을 시킬 수 있게 되었습니다. 다만 이것이 정확히 몇 배인지는 대화 부분까지 함께 재야 알 수 있어 숫자로 주장하지 않습니다.

4. 나만의 방식 또는 개선 포인트

「"프롬프트를 짧게 쓰라는 얘기 아닌가요?"」 반대입니다. 사람이 쓰는 질문은 원래 짧습니다. 분량을 잡아먹는 건 「사람이 쓴 질문이 아니라 기계가 뱉은 자료」입니다. 그래서 저는 사람이 조심하게 만들지 않고, 「기계가 뱉는 쪽을 자동으로 걸렀습니다.」 사람이 매번 신경 써야 하는 방법은 결국 잊힙니다. 이 방법은 신경 쓰지 않아도 돌아갑니다.

다르게 한 것은 네 가지입니다.

1. 「효과를 재는 장치를 먼저 만들었습니다.」 줄인 양을 매번 기록하게 했기 때문에 이 글에 "그런 것 같다"가 아니라 23만 건의 누적 수치를 쓸 수 있습니다. 어느 규칙이 효과가 없는지도 기록을 보고 알았습니다.
2. 「자료 종류별로 버릴 것을 따로 정했습니다.」 하나의 규칙으로 뭉뚱그리면 중요한 걸 버립니다. 파일 목록에서 크기는 남기고 권한은 버리는 식으로, 종류마다 "무엇이 정보이고 무엇이 소음인가"를 따로 적었습니다.
3. 「켜지 말아야 할 곳을 명시했습니다.」 문서를 고칠 때와 원문을 인용할 때는 끕니다. 「압축이 이득인 구간과 손해인 구간을 나눈 것」이 핵심입니다.
4. 「실패를 규칙으로 되돌렸습니다.」 정리 단계가 필요한 줄을 버려 AI가 헛짚은 적이 있습니다. 그럴 때마다 원문으로 다시 확인하고, 그 사례를 규칙 수정으로 바로 반영했습니다. 월별 절감률이 올라간 것은 이 반복의 결과입니다.

「한계도 적어 둡니다.」

- 압축은 원리상 손실입니다. 걸러낸 자료만 보고 판단하면 놓치는 게 생깁니다. 그래서 결과가 이상하면 정리를 끄고 원문으로 한 번 더 확인합니다.
- 절감률은 자료 종류에 따라 편차가 큽니다. 이미 잘 정리된 문서는 거의 줄지 않고, 포털 첫 화면처럼 메뉴뿐인 자료는 너무 많이 줄어 쓸모가 없어집니다.
- 이 수치는 한 사람의 작업 기록입니다. 다른 사람의 작업 방식에서 같은 비율이 나온다고 말할 수 없습니다.
- 앞서 밝혔듯 78.2%는 명령 출력 축의 수치이고, 요금 고지서가 78.2% 줄었다는 뜻이 아닙니다.

5. 다른 사람도 따라 할 수 있나요

「프로그램 없이도 원리는 그대로 씁니다.」 AI 챗봇을 자주 쓰는 분이라면 오늘 바로 네 가지를 바꿔보세요. 비용은 0원입니다. 위의 데모 주소에 자기 로그나 표를 붙여넣어 보면 어떤 줄이 군더더기인지 눈으로 먼저 확인할 수 있습니다 [그림 3].

1. 「통째로 붙여넣지 말고 "구조 먼저" 물어보세요.」 긴 문서는 목차나 소제목만 먼저 넣고 "어느 부분을 봐야 하나요"라고 물은 뒤, 그 부분만 넣으세요. 답의 질이 오히려 올라갑니다.
2. 「반복되는 건 사람이 먼저 지우세요.」 엑셀·로그·표를 붙여넣을 때 필요 없는 열은 지우고, 같은 줄이 반복되면 한 줄만 남기고 "이 줄이 40번 나왔음"이라고 적으세요. 30초면 됩니다.
3. 「웹페이지는 주소 대신 본문만 붙여넣으세요.」 브라우저의 읽기 모드로 본문만 남긴 뒤 복사하면 메뉴와 광고가 빠집니다.
4. 「고칠 때는 원문을 주세요.」 요약한 자료로 문서를 고쳐 달라고 하면 틀립니다. 찾을 때는 줄이고, 고칠 때는 원문을 줍니다.

회사나 팀이라면 한 단계 더 갈 수 있습니다. AI 에이전트에 연결된 명령들 앞에 이런 정리 단계를 하나 두고, 「줄인 양을 기록하는 것부터」 시작하면 됩니다. 기록이 쌓이면 어느 규칙이 효과가 있는지 저절로 보입니다.

기억할 한 문장은 이겁니다. 「AI에게 많이 주는 게 아니라 정확히 주는 게 이깁니다.」 사람에게 자료를 넘길 때 필요한 것만 추려서 주듯, AI에게도 똑같이 하면 됩니다. 사용량이 줄어드는 건 덤이고, 진짜 이득은 「답이 정확해지는 것」입니다.