01 / RESEARCH NOTES
왜 이 실험을 했나요?
간단한 앱 설명이나 작은 수정까지 늘 같은 큰 모델을 거치면, 결과를 만드는 시간보다 누가 처리할지 정하는 시간이 길어질 수 있습니다. 작업의 종류와 난이도를 먼저 구분해 필요한 모델로 바로 보낼 수 있는지 살폈습니다.
Jev는 최종 답변을 대신 작성하는 모델이 아니라, 정해진 선택지 사이에서 경로를 고르는 역할로 사용했습니다. 확신이 부족하면 더 깊이 판단하는 모델로 이어지도록 구성했습니다.
02 / RESEARCH NOTES
첫 시안은 오히려 느렸습니다
같은 날 먼저 시험한 작업실 경로는 평균 시간이 14.261초에서 16.3516초로 14.7% 늘었습니다. 출력 구조 검사는 8/10에서 9/10으로 나아졌지만, 10건 모두 Sonnet 판단으로 돌아가 중간 호출을 한 번도 줄이지 못했습니다.
작업실에 들어갈지 정하는 판단과 어떤 모델이 실행할지 정하는 판단을 분리하고, 답변 구조를 보완한 뒤 아래 후속 실험을 진행했습니다. 최초 실패는 후속 결과로 덮어쓰지 않았습니다.
03 / RESEARCH NOTES
무엇을 고정하고 비교했나요?
앱 요청 5개를 각각 두 번씩 실행하고 변경 전후를 비교했습니다. 결과가 요구된 구조를 지키는지도 함께 검사했습니다. 20회는 앱 전체를 완성·배포한 횟수가 아니라 라우팅과 응답 경로의 실행 횟수입니다.
표를 좌우로 넘겨 모든 항목을 확인하세요.
| 확인 항목 | 변경 전 | 변경 후 |
|---|---|---|
| 평균 완료 시간 | 16.7294초 | 10.0882초 |
| 평균 추정 API 비용 | $0.0587446 | $0.02609081 |
| 출력 구조 검사 | 10 / 10 | 10 / 10 |
04 / RESEARCH NOTES
분류가 달라지면 실행 경로도 달라집니다
별도 분류 검사 66회 중 일반 요청 38회는 Luna로 직접 연결 25회, Sonnet으로 직접 연결 11회, 재분류 2회로 나뉘었습니다. 공통 요청 26회의 직접 연결은 변경 전 9회에서 변경 후 26회로 늘었습니다.
앱 실행 비교에서는 변경 후 10회 중 9회가 중간 Sonnet 판단을 생략했습니다. 모든 요청을 가장 저렴한 모델에 보내는 방식이 아니라, 분류가 충분히 명확한 요청에서 한 단계를 덜 거치는 방식입니다.
05 / RESEARCH NOTES
적용 판단과 남은 확인
짧고 명확한 작업은 바로 연결하고, 애매하거나 복잡한 작업은 상위 모델로 넘기는 방향을 확인했습니다. 속도뿐 아니라 결과 형식을 지키는지도 함께 통과해야 하는 조건을 유지했습니다.
수치는 10월 4일의 제한된 실험 결과입니다. 실제 Windows 앱 제작 전체 시간, 네트워크 상황, 모든 사용자의 청구 비용을 대표하지 않습니다. 후속 연구에서는 실제 작업 종류를 넓혀 완성도와 재시도 비용까지 비교해야 합니다.