로컬 AI가 정말 더 쌀까? 클라우드와 비교할 때 꼭 재야 할 5가지

“API 비용이 계속 나오니 로컬 모델로 바꾸면 공짜 아닌가요?”

처음에는 그럴듯하게 들린다. 클라우드 모델은 호출할 때마다 비용이 보이고, 로컬 모델은 이미 가진 컴퓨터에서 돌아간다. 그래서 가격표만 놓고 보면 로컬이 압도적으로 저렴해 보인다.

하지만 개발 작업의 진짜 비용은 청구서 한 줄로 끝나지 않는다. 같은 버그를 고치는 데 성공률이 낮아 세 번 다시 시도했다면? 엉뚱한 파일까지 수정해 사람이 되돌리는 데 40분이 들었다면? 실행은 무료였지만 개발자의 검토 시간이 더 많이 필요했다면?

모델 가격이 아니라 작업을 끝내는 총비용을 비교해야 한다.

비교 전에 먼저 없애야 할 착시

클라우드와 로컬을 비교할 때 흔히 다음처럼 서로 다른 조건을 놓는다.

• 클라우드 모델에는 충분한 컨텍스트와 도구를 제공한다.
• 로컬 모델에는 짧은 프롬프트만 주고 성능이 낮다고 결론 낸다.
• 반대로 로컬 모델은 여러 번 재시도하면서 API 비용만 0원이라고 계산한다.
• 한쪽은 쉬운 버그, 다른 쪽은 어려운 버그로 평가한다.

이렇게 하면 모델이 아니라 실험 조건을 비교하게 된다. 출발점은 간단하다. 같은 버그, 같은 성공 기준, 같은 권한, 같은 중단 조건을 사용한다.

1단계: 같은 버그 10개를 준비한다

한두 문제로는 운이 크게 작용한다. 실제 저장소에서 자주 만나는 유형을 섞어 작은 평가 세트를 만든다.

1. 경계값 계산 오류
2. 잘못된 조건문
3. 누락된 예외 처리
4. 데이터 형식 변환 오류
5. 상태 갱신 순서 문제
6. 중복 요청
7. 권한 검사 누락
8. 테스트와 구현의 불일치
9. 설정값 처리 오류
10. 성능을 악화시키는 반복 호출

각 버그에는 재현 테스트와 허용되는 수정 범위를 함께 둔다. “그럴듯한 답을 냈다”가 아니라 테스트를 통과했고, 금지된 파일을 건드리지 않았을 때만 성공으로 센다.

2단계: 다섯 가지 지표를 같은 표에 기록한다

가격만 비교하면 가장 중요한 비용이 숨어 버린다. 다음 다섯 가지를 작업별로 기록한다.

지표확인할 질문

재현 테스트 성공률	제한된 시도 안에 실제 문제를 해결했는가?
잘못 수정한 파일 수	요청 범위 밖의 코드를 건드렸는가?
작업당 실행 시간	시작부터 검증 완료까지 얼마나 걸렸는가?
사람의 추가 검토 시간	이해·수정·되돌리기에 몇 분이 들었는가?
총운영 비용	API 요금 또는 장비·전력·운영 시간을 포함하면 얼마인가?

성공률은 가장 먼저 본다. 싼 모델이 열 번 중 네 번만 성공한다면, 실패한 여섯 건의 재시도와 검토 비용이 뒤따른다. 잘못 수정한 파일 수는 성공처럼 보이는 위험한 실패를 잡아낸다. 테스트는 통과했지만 무관한 설정 파일을 바꿨다면 유지보수 비용이 남는다.

3단계: 사람의 시간을 비용에 포함한다

모델 비교에서 자주 빠지는 항목이 개발자의 검토 시간이다. 다음처럼 계산하면 숨은 비용이 보인다.

작업의 총비용 = 모델·인프라 비용
              + 사람의 검토 시간 × 시간당 내부 비용
              + 실패 후 재시도 비용

예를 들어 로컬 실행비가 거의 0원이어도 사람이 결과를 정리하는 데 30분 더 필요하면 무료가 아니다. 반대로 클라우드 호출 비용이 조금 높아도 첫 시도 성공률이 높고 검토가 빠르면 전체 비용은 낮을 수 있다.

여기서 목적은 개발자의 시간을 돈으로만 환산하는 것이 아니다. 팀의 가장 희소한 자원이 어디에서 소모되는지 확인하는 것이다.

4단계: 로컬 모델은 안전한 샘플 환경에서 평가한다

로컬에서 실행된다는 이유만으로 안전한 것은 아니다. 평가 환경은 다음처럼 제한한다.

• 로컬 API는 외부에 노출하지 않는다.
• 실제 저장소 대신 비밀 값이 제거된 샘플 복사본을 사용한다.
• 모델 프로세스에 저장소 쓰기 권한을 직접 주지 않는다.
• 모델은 패치만 제안하고 별도 실행기가 허용된 파일에만 적용한다.
• 클라우드와 동일한 호출 횟수와 시간 제한을 둔다.

이 장치를 빼면 성능 평가가 보안 사고나 저장소 오염 실험으로 바뀔 수 있다. 비교의 공정성은 권한과 중단 조건까지 같을 때 생긴다.

5단계: 평균 하나로 승자를 정하지 않는다

모든 작업에 항상 이기는 모델은 기대하지 않는 편이 좋다. 결과를 작업 유형별로 나누면 라우팅 기준이 보인다.

• 복잡한 추론과 넓은 컨텍스트가 필요한 작업
• 반복적이고 성공 조건이 분명한 작업
• 민감한 데이터를 다루는 작업
• 응답 속도가 중요한 작업
• 사람이 반드시 깊게 검토해야 하는 작업

어떤 팀에서는 어려운 디버깅은 클라우드가 유리하고, 반복적인 코드 분류는 로컬이 유리할 수 있다. 다른 팀에서는 하드웨어와 운영 역량 때문에 결과가 반대일 수도 있다. 중요한 것은 유행이나 인상 대신 자기 팀의 평가표로 결정하는 것이다.

바로 써볼 수 있는 평가 기록표

버그 하나마다 아래 항목을 한 줄로 남긴다.

평가 ID:
작업 유형:
실행 환경: 클라우드 / 로컬
성공 여부:
호출 또는 재시도 횟수:
총실행 시간:
잘못 수정한 파일 수:
사람의 검토 시간:
모델·인프라 비용:
중단 이유:
메모:

10개 평가가 끝나면 모델별 평균뿐 아니라 실패 사례를 함께 읽는다. 성공률 80%라는 숫자만 보면 같아도, 한쪽은 시간 초과로 실패하고 다른 쪽은 잘못된 파일을 수정해 실패했을 수 있다. 두 실패는 운영 위험이 전혀 다르다.

결국 묻고 싶은 질문

“어느 모델이 더 싼가?”보다 좋은 질문은 이것이다.

이 작업을 원하는 품질로 끝내기 위해, 모델 비용과 사람의 시간을 합쳐 어떤 선택이 가장 효율적인가?

비용 최적화는 가장 싼 모델을 고르는 일이 아니다. 불필요한 호출을 줄이고, 실제 사용량을 기록하고, 작업 가치와 실패 비용에 맞는 모델·컨텍스트·중단 조건을 고르는 일이다.

클라우드와 로컬은 경쟁자가 아니라 서로 다른 도구다. 같은 시험지를 주고 총비용을 기록하면, “무조건 로컬”이나 “무조건 클라우드” 대신 어떤 작업을 어디로 보낼지라는 훨씬 실용적인 답을 얻을 수 있다.

다음 글에서는 테스트가 없는 레거시 코드를 바로 고치지 않고, 현재 동작을 특성화 테스트로 먼저 고정하는 방법을 다룬다.