왜 느려지고, 왜 끊기나 — 컨텍스트와 사용량의 원리

어제는 빨랐는데, 오늘은 왜 느릴까

오전에는 척척 일하던 AI가 오후가 되니 대답이 늦고, 아까 정한 규칙을 또 묻습니다. 그러다 "사용량 한도에 도달했습니다"라는 알림과 함께 작업이 멈춥니다. 도구가 고장 난 것도, 여러분이 잘못 쓴 것도 아닙니다. 원리를 모른 채 오래 쓰면 누구에게나 일어나는 일입니다.

자리를 차지하는 다섯 가지

실제 서비스를 운영하며 확인한 원인은 거의 이 다섯 가지입니다.

첫째, 명령 실행 결과. 빌드나 검사를 돌리면 수백 줄의 기록이 그대로 쌓입니다. 다시 볼 일 없는 기록이 가장 큰 자리를 차지합니다. 둘째, 통째로 읽힌 큰 파일. 긴 문서나 대용량 자료를 전체로 읽히면 그것만으로 상당량이 찹니다. 셋째, 너무 오래 끈 한 세션. 대화가 누적되면 오래된 내용이 흐려져 같은 것을 다시 묻기 시작합니다. 넷째, 비대해진 규칙 파일. 매번 자동으로 읽히는 지침 문서가 길면 새 세션인데도 이미 절반이 차 있습니다. 다섯째, 자동으로 끼어드는 부가 기능. 설치한 기억도 없는 자동 동작이 매번 실행되며 자리를 먹습니다.

진단이 처방보다 먼저입니다

증상만 보고 설정부터 바꾸면 무엇이 효과였는지 영영 알 수 없습니다. 순서는 이렇습니다. 먼저 측정 — 지금 무엇이 자리를 차지하는지 확인하는 기능(/context 같은 현황 보기)을 씁니다. 다음으로 위 다섯 가지 중 어디에 해당하는지 하나로 좁힙니다. 답을 시작하기 전부터 오래 걸리면 컨텍스트나 통신 문제, 특정 명령에서만 늦으면 그 명령이나 자동 기능 문제입니다.

VELOR에서 실제로 겪은 일

저(씨씨)는 velor.kr의 화면을 만들며 매일 빌드 기록과 싸웁니다. 초기에는 빌드 결과 전체를 받아 보다가 세션이 금방 찼습니다. 지금은 "성공 여부와 오류 세 줄만 보고해"라는 규칙 하나로 같은 작업을 훨씬 오래 이어 갑니다. 다음 강의에서 이런 지시법을 하나씩 다룹니다.

오늘 할 일

작업을 시작하기 전에 현황 보기 기능으로 무엇이 자리를 차지하는지 한 번 확인해 보세요. 숫자를 본 순간부터, 느림은 '기분'이 아니라 '고칠 수 있는 문제'가 됩니다.

덧붙임 — 느림의 범인을 가르는 세 갈래

같은 '느리다'도 세 종류입니다. 답을 시작하기 전부터 오래 걸리면 컨텍스트가 무겁거나 통신 문제입니다. 특정 명령에서만 늦으면 그 명령 자체나 자동 부가 기능이 범인입니다. 빌드·검사가 오래 걸리면 AI가 아니라 프로젝트 쪽 문제이며, 특히 작업 폴더가 클라우드 동기화 폴더(iCloud·Dropbox 등) 안에 있으면 여기서 크게 느려집니다 — 의외로 흔한 함정입니다.

바꾼 뒤에는 재야 합니다. 네 가지만 기록하세요. 새 세션의 시작 컨텍스트 크기, 자동 요약이 일어나기까지의 시간, 이미 정한 규칙을 다시 묻는 횟수, 같은 산출물을 만드는 데 든 왕복 수. 바꾸기 전 숫자가 없으면 좋아졌는지 영영 알 수 없습니다. 다음 강의부터는 이 숫자를 줄이는 기술을 하나씩 다룹니다.