“계획은 Sol, 실행은 Luna”, 정말 최고의 전략일까?

GPT가 맥락을 잃어버려서 프로젝트를 다시 빌드해야 했다고? ChatGPT의 프로젝트는 일련의 대화가 담긴 폴더일 뿐이야. 그 대화 중 하나에서 맥락을 잃었다면 그냥 그 대화를 삭제하면 돼. 프로젝트 전체의 진실 공급원(source of truth)을 보관할 수 있는 소스 폴더가 있고, 각 대화는 프로젝트의 다양한 기능이나 부분에 관한 것일 수 있어. 대화 하나가 잘못된다고 프로젝트 폴더 전체가 망가지는 건 아니야..

난 GitHub 프로젝트를 사용해서 칸반 보드를 설정하고, 그걸로 각 작업 단위를 범위 지정해. 그다음 로컬 러너로 테스트를 돌리고, 각 티켓을 회귀 테스트하게 한 뒤 자체 코드 리뷰를 수행하게 해.

Sol을 모든 작업에 사용하는 또 다른 이유는 Luna로 전환하면 캐시가 무효화되기 때문임. 그래서 실제로는 제한을 더 빨리 잡아먹을 수도 있음.

항상 그런 건 아니야. 다른 제공업체의 모델로 리뷰하는 게(예: 구현은 Opus, 리뷰는 Sol) 더 효과적이라고 봐. 결국 인간도 코드 리뷰는 다른 사람한테 맡기잖아.

Sol은 5x 플랜에서도 구현하기엔 너무 비싸. 난 Sol을 계획 짜고 모든 작업을 생성하는 데 쓰고, 구현은 Terra나 Luna한테 맡겨. Luna max는 너무 오래 걸려. Terra가 45분 걸릴 작업을 Luna max는 구현하는 데 2~3시간씩 걸리거든. Luna는 extra high, Terra는 high에서 제일 잘 돌아가.

직접 테스트하고 벤치마크해본 결과, 결론은 '상황에 따라 다르다'임.

비교적 간단한 문제라면 그냥 Sol을 쓰는 게 주간 사용량 측면에서 더 적게 듦. 아키텍처 설계나 왔다 갔다 하는 과정에서 토큰을 낭비할 필요가 없으니까. 그럴 거면 그냥 terra나 순정 Luna를 쓰는 게 낫다는 주장이 나올 수도 있음.

내 최근 벤치마크 결과, 복잡하고 단계가 많은 프로세스에서는 Dynamic orchestrator와 Luna를 조합하는 게 그냥 Sol만 쓰는 것보다 주간 사용량이 66% 더 적었음. 근데 이건 시작 단계에서 아주 작은 Sol 단계를 제어했을 때의 이야기고, 그...

난 Luna한테 코딩 작업을 맡기지 않을 거야. Luna는 리눅스 관리자로는 좋지만 개발자가 될 만큼 똑똑하진 않아. Sol이 직접 코드를 구현하는 것만큼이나 실수를 수정하는 데 토큰을 쓰게 될걸.

물론 이건 내 개인적인 의견이야. 어떤 사람들은 구현에 Qwen 27b 같은 걸 쓰기도 하더라. 그런 코드는 안 보는 게 나아. ㅋㅋ