AI 코딩 비용을 줄이는 법: 작업 난이도와 실패 비용으로 모델을 분리하는 운영 기준

대규모 저장소를 읽고, 비슷한 테스트 파일을 만들고, 회의 뒤 문서를 갱신하는 작업까지 모두 최고급 AI 모델에 맡기면 토큰 비용은 빠르게 쌓입니다. 문제는 개발자가 고급 모델을 너무 많이 쓴다는 데만 있지 않습니다. 어떤 작업을 저가 모델로 보내도 되는지, 그 결과를 누가 어떤 방식으로 확인할지를 정하지 않은 운영 방식에 더 큰 원인이 있습니다.

운영 단계의 CTO와 개발 리드는 모델을 하나 고르는 대신, 작업 난이도와 실패 비용이 다른 업무를 분리하는 라우팅 정책을 만들어야 합니다. 저가 모델이 맡을 수 있는 일은 생각보다 넓지만, 코드 변경의 근거를 판단하거나 보안 경계를 해석하는 일까지 넘기면 절감한 비용보다 큰 재작업 비용을 낼 수 있습니다.

먼저 나눌 것은 모델이 아니라 작업의 실패 비용이다

같은 “코드 작업”이라도 잘못됐을 때의 결과는 다릅니다. 파일 다섯 개에서 특정 설정값의 위치를 찾아 요약하는 일이 틀렸다면, 개발자가 원문을 다시 확인하면 됩니다. 반면 인증 흐름을 바꾸는 코드가 잘못 생성되면 장애, 데이터 노출, 권한 우회 같은 문제가 생길 수 있습니다.

모델을 배정할 때는 아래 두 축을 함께 봐야 합니다.

판단 축	확인할 질문	저가 모델에 적합한 조건
추론 난이도	여러 선택지의 장단점을 비교하거나 숨은 의존성을 찾아야 하는가	입력과 출력 규칙이 비교적 명확하다
실패 비용	틀린 결과가 운영 장애, 보안 문제, 데이터 손상으로 이어지는가	사람이 빠르게 검토하거나 자동 검증할 수 있다
맥락 의존성	저장소 전반의 의도, 과거 결정, 도메인 지식이 필요한가	기준 파일이나 명세만으로 작업 경계를 설명할 수 있다
결과의 가역성	잘못 적용해도 쉽게 되돌릴 수 있는가	새 파일 생성, 초안 작성, 읽기 전용 분석처럼 되돌리기 쉽다
검증 가능성	테스트, 린트, 스키마 검사로 오류를 잡을 수 있는가	기계 검증과 비교 검토가 가능하다

이 기준에서 중요한 점은 “저가 모델은 쉬운 일만 한다”가 아닙니다. 오류가 나도 좁은 범위에서 발견하고 되돌릴 수 있는 일을 맡기는 편이 더 정확합니다. 반대로 복잡해 보여도 산출물 형식이 고정돼 있고 검증이 쉬운 작업은 분리하기 좋습니다.

저가 모델로 분리하기 좋은 업무와 남겨야 할 업무

저가 모델로 우선 분리할 후보는 대체로 입력량이나 출력량은 크지만, 고난도 판단은 적은 작업입니다.

분리 후보 1: 넓게 읽고 좁게 답하는 조사 작업

큰 파일 여러 개를 훑어 특정 메서드의 호출 위치, 설정 키의 사용처, 모듈별 책임을 정리하는 일은 대표적인 후보입니다. 이때 저가 모델에는 “무엇을 찾아야 하는지”를 좁게 지정하고, 결과 형식도 파일명·심볼명·핵심 근거처럼 구조화해야 합니다.

다만 이 요약을 근거로 바로 코드를 고치게 하면 문제가 달라집니다. 요약 모델이 놓친 조건문, 예외 처리, 호출 순서는 수정 판단에 영향을 줍니다. 분석 결과는 탐색 비용을 줄이는 용도로 쓰고, 실제 변경 전에는 담당 모델이나 개발자가 필요한 코드 구간을 직접 읽도록 분리하는 편이 안전합니다.

분리 후보 2: 기준 파일이 있는 정형 코드 생성

기존 테스트와 같은 패턴을 따르는 테스트 파일, 타입 선언, 설정 초안, 문서 템플릿, 반복적인 변환 코드가 여기에 해당합니다. 핵심 조건은 기준 파일입니다. “테스트를 만들어라”보다 “이 테스트 파일의 명명 규칙, 목 구조, assertion 형식을 따르라”가 훨씬 안전한 작업 지시입니다.

생성 결과는 가능하면 설명문 없이 코드만 반환하게 해야 합니다. 코드 생성 모델이 장황한 해설과 마크다운 표기를 섞으면, 상위 에이전트가 그 내용을 다시 읽고 해석하면서 절감 효과가 줄어듭니다. 파일 저장 전후에 포매터, 컴파일, 테스트를 실행하는 경로도 붙여야 합니다.

분리 후보 3: 문서와 운영 산출물의 초안

변경된 API 목록을 바탕으로 문서 초안을 갱신하거나, 정해진 형식의 릴리스 노트를 만드는 작업도 분리 가능성이 높습니다. 단, 고객에게 약속하는 기능 범위, 보안 정책, 장애 원인처럼 사실 확인이 중요한 문서는 초안을 넘어서 최종 문서로 자동 반영하면 안 됩니다.

반대로 아래 업무는 고급 모델 또는 사람의 검토 비중을 높게 두는 편이 낫습니다.

• 요구사항이 모호하고, 구현 전에 질문과 대안 비교가 필요한 설계 작업
• 인증, 권한, 결제, 개인정보, 암호화처럼 실패 비용이 큰 변경
• 장애 원인을 추적하며 여러 서비스의 시간 순서와 로그를 해석하는 작업
• 데이터 마이그레이션, 삭제, 대량 변경처럼 되돌리기 어려운 실행
• 기존 관례와 충돌할 수 있는 리팩터링, 모듈 경계 변경, 공개 API 변경

여기서 고급 모델도 정답 보증 장치는 아닙니다. 더 비싼 모델은 더 넓은 맥락과 복합적인 판단을 처리할 여지가 있지만, 권한 제한과 테스트, 코드 리뷰를 대신하지는 못합니다.

라우팅 규칙은 권고문이 아니라 실행 경로에 넣어야 한다

팀 위키나 에이전트 지침에 “큰 파일은 저가 모델로 요약한다”고 적는 것만으로는 안정적인 절감이 일어나기 어렵습니다. 에이전트는 급한 작업에서 지침을 건너뛸 수 있고, 저장소마다 규칙이 달라지면 팀의 사용 방식도 흔들립니다.

운영 규칙은 가능한 한 도구 호출 경로에 넣는 편이 좋습니다. 예를 들어 다음과 같은 방식입니다.

1. 파일 읽기 요청에서 일정 크기 이상의 비표적 읽기를 감지한다.
2. 전체 파일 읽기 대신 요약 전용 작업으로 보낸다.
3. 상위 에이전트에는 구조화한 결과만 돌려준다.
4. 수정이 필요해지면 필요한 함수나 줄 범위만 다시 읽게 한다.
5. 코드 생성은 기준 파일과 명세가 함께 있을 때만 허용한다.
6. 생성된 파일은 테스트와 정적 검사를 통과하기 전까지 변경 완료로 취급하지 않는다.

이 방식의 목적은 저가 모델이 고급 모델을 대체하게 만드는 데 있지 않습니다. 고급 모델의 컨텍스트를 넓은 파일 탐색과 반복 출력으로 채우지 않고, 설계 판단과 예외 처리에 집중하게 만드는 데 있습니다.

절감 정책이 실패하는 조기 신호

비용 절감 정책이 잘못 설계되면 토큰 사용량은 줄어도 개발 속도와 품질이 나빠질 수 있습니다. 다음 신호가 보이면 라우팅 대상이나 검증 경로를 다시 조정해야 합니다.

첫째, 요약 결과를 받은 뒤 상위 모델이나 개발자가 원문 전체를 다시 읽는 일이 자주 반복됩니다. 질문이 너무 넓었거나, 요약 결과 형식이 후속 판단에 맞지 않는 경우입니다. “이 서비스가 무엇을 하는가”보다 “외부 DB를 호출하는 메서드와 예외 처리 경로는 무엇인가”처럼 질문을 좁혀야 합니다.

둘째, 생성된 테스트가 통과하지만 실제 동작을 검증하지 못합니다. 기존 테스트의 형식만 흉내 내고, 핵심 분기나 실패 경로를 빠뜨렸을 수 있습니다. 이 경우 저가 모델에 더 긴 지시를 추가하기보다, 테스트 시나리오 선정은 상위 모델이나 개발자가 하고 생성 모델은 파일 작성만 맡기는 방식이 낫습니다.

셋째, 팀원이 라우터를 우회해 직접 고급 모델에 대량 파일을 넣습니다. 저가 모델의 품질이 충분하지 않거나, 호출 과정이 번거롭거나, 결과를 신뢰할 수 없다는 뜻일 수 있습니다. 우회를 통제하기 전에 어떤 단계에서 정보가 부족했는지 확인해야 합니다.

넷째, 모델 비용은 낮아졌는데 CI 시간, 리뷰 시간, 재작업량이 늘어납니다. 이때는 토큰 비용만 따로 보지 말고, 생성부터 병합까지 걸린 시간과 실패한 검증 횟수를 함께 봐야 합니다. 저가 모델이 만든 산출물의 검토 비용이 절감액을 넘으면 대상 작업을 축소해야 합니다.

운영 전에는 세 가지 작업군으로 작은 실험을 설계한다

처음부터 전 팀의 모델 사용을 일괄 변경할 필요는 없습니다. 저장소에서 자주 발생하는 작업을 세 부류로 골라 비교하는 편이 좋습니다. 예를 들면 대형 파일 조사, 기준 파일 기반 테스트 생성, 문서 초안 갱신입니다.

각 작업군마다 다음을 미리 정합니다.

• 작업을 저가 모델로 보낼 조건과 제외 조건
• 입력으로 제공할 파일 범위와 기준 파일
• 결과를 받아볼 형식
• 사람 검토, 컴파일, 테스트, 린트 중 어떤 검증을 거칠지
• 실패 시 상위 모델이나 개발자에게 되돌리는 기준
• 토큰 사용량 외에 확인할 재작업 및 검증 실패 신호

고급 모델 사용을 줄이는 목표부터 세우기보다, 한 업무가 “낮은 비용으로 충분히 맞는 결과”를 내는 조건을 먼저 찾으십시오. 그 조건이 문서와 도구 규칙으로 남아야, 담당자가 바뀌거나 저장소가 커져도 비용 절감이 품질 저하로 바뀌지 않습니다.