AI 코딩이 느려질 때, 줄여야 할 것은 출력이 아니라 재작업일까요

핵심 요약 (TL;DR)

AI 코딩을 쓰다 보면 터미널 출력과 대화가 길어질수록 ‘이걸 더 짧게 만들면 싸고 빨라지지 않을까’ 생각하게 됩니다. GitHub는 9월 3일 Copilot CLI 사례를 공개하며, 도구 응답을 무작정 줄이면 오히려 전체 작업 비용이 커질 수 있다고 설명했습니다. 빠진 정보를 다시 찾으려고 에이전트가 명령을 재실행하고, 원본을 다시 읽고, 다음 문맥까지 길게 가져가면 한 번의 절약은 여러 번의 재작업이 됩니다. 중요한 기준은 토큰 한 번이 아니라 완료된 작업 하나입니다.

짧은 출력이 왜 더 비싸질 수 있을까요?

에이전트가 테스트 실패 원인, 빌드 오류, 변경 파일을 읽을 때는 정확한 줄과 문맥이 필요합니다. 출력에서 경로나 오류 줄을 지우면 당장은 응답이 짧아집니다. 그러나 에이전트는 확인할 수 없었던 정보를 얻기 위해 다시 명령을 실행합니다. GitHub도 자신의 통합과 테스트한 작업에서만 성립하는 관찰이라고 분명히 적었지만, 원칙은 실무에 그대로 적용할 수 있습니다. ‘출력이 몇 토큰인가’보다 ‘이 출력으로 다음 행동을 결정할 수 있는가’를 먼저 물어보는 것입니다.

무엇은 줄이고 무엇은 보존해야 할까요?

반복되는 장식과 중복 안내는 줄여도 됩니다. GitHub는 포맷을 제거하는 방식이 특정 오프라인 벤치마크에서 약 5%의 추론 비용 감소를 보였고, 성공률은 일반적인 실행 변동 범위에 머물렀다고 밝혔습니다. 반면 git diff, git show, 임의 스크립트처럼 원본 형태 자체가 의미인 출력은 보존하는 편이 낫습니다. 파일 이름, 오류 코드, 실패한 테스트 이름, 변경 전후의 코드 조각은 압축 대상으로 보기 어렵습니다.

프롬프트를 짧게 만드는 일도 검증해야 할까요?

그렇습니다. GitHub는 프롬프트 압축 뒤 독립 작업이 순차 실행되는 회귀를 발견해 실험을 멈추고 평가를 추가했다고 공개했습니다. 짧아진 문장이 에이전트의 행동 규칙을 바꿀 수 있다는 뜻입니다. 바이브코더라면 프롬프트를 다듬은 뒤 ‘같은 기능 요청에서 병렬 작업이 유지되는지’, ‘테스트가 실제로 실행되는지’, ‘위험한 행동은 여전히 승인받는지’를 확인해 보세요. 문장 수가 줄었다는 사실만으로 개선을 선언하면 안 됩니다.

내 프로젝트에서는 어떤 기록을 남기면 좋을까요?

작업이 끝날 때마다 변경 파일, 실행한 테스트, 남은 실패, 다음 확인 한 가지를 남기세요. 비용이 늘어난 날에는 모델 탓으로 바로 결론 내리지 말고 재실행 횟수와 누락된 정보가 있었는지 보세요. AI 코딩의 속도는 말을 적게 하게 만드는 데서보다, 같은 질문을 다시 하지 않아도 되는 작업 환경에서 나옵니다.

FAQ: 모든 로그를 모델에게 보내야 하나요?

아닙니다. 비밀값과 개인정보는 먼저 가리고, 현재 작업의 판단에 필요한 원문만 제공하세요. 핵심은 로그의 양이 아니라 필요한 증거가 사라지지 않는 것입니다.

FAQ: 비용을 확인할 때 가장 먼저 볼 지표는 무엇인가요?

요청 한 번당 토큰보다 기능 하나를 완료할 때까지 든 총 호출, 재실행 횟수, 사람의 재검토 시간을 함께 보세요. 프로젝트마다 최적점은 다릅니다.

출처: https://github.blog/ai-and-ml/github-copilot/how-we-make-ai-coding-more-cost-efficient-without-sacrificing-task-quality/
발표 확인: https://news.ycombinator.com/item?id=49545164
관찰 시점: 2026-09-04 KST