Luna는 제정신이 아님, 다들 이걸 어떻게 실무에 쓰는지 이해가 안 감
Luna is a lunatic and I don’t understand how y’all trust it with real work
핵심 요약
Luna의 성능에 불만을 가진 작성자가 다른 사용자들의 성공적인 활용 비결을 묻는 글.
- Luna 성능 논란 — 복잡한 작업에서 잦은 오류와 피상적인 결과물로 비판받음.
- 성공적인 활용법 — 철저한 계획 수립과 엄격한 작업 범위 설정이 필수적임.
- 오케스트레이션 중요성 — 상위 모델로 계획하고 Luna를 구현 도구로 사용하는 방식이 주류임.
- 대안 모델 선호 — 비용과 성능 사이에서 Claude나 Sol을 선호하는 사용자들도 존재함.
TL;DR: Luna는 내가 시키는 복잡한 코딩 작업에는 영 꽝임. 코딩의 90%를 이걸로 한다는 사람들... 도대체 뭘 어떻게 하고 있는 거임? 어떻게 성공적으로 쓰고 있는 건지 알려주라.
푸념 좀 할게. 여기저기서 Codex 사용량 제한 때문에 Luna가 대안이라면서 추천하는 글이 계속 보이네: 가격도 엄청 싸고, 코딩 작업의 90%를 이걸로 한다, Luna Max가 코딩 꽤 잘한다, Sol을 코디네이터로 쓰고 Luna Max를 서브 에이전트로 쓴다 등등.
나도 계속 시도해 봤거든. 근데 진짜 진심으로, 아무리 노력해도 사람들이 어떻게 이걸로 제대로 된 코딩 결과물을 뽑아내는지 이해가 안 가.
조금이라도 복잡한 거 시키면 그냥 개판임. 물론 "작동"은 하는 코드를 짜주긴 해. 근데 그게 기준은 아니잖아, 안 그래?
내가 겪는 문제는 항상 이거임:
- 구현이 미묘하게 틀림
- 정작 핵심 문제는 해결 안 하고 멈춰버림
- 근본적인 원인은 안 고치고 꼼수만 부림
- 겉핥기식으로 계획은 따르는데 중요한 부분은 다 놓침
피상적인 작업 말고 제대로 된 코딩 시켰을 때, 내가 실제로 쓰고 싶을 만한 결과물을 가져오는 경우가 거의 없어.
딱 2024년쯤의 GitHub Copilot 느낌임.
나는 꽤 큰 규모의 코드베이스에서 일하고, 변경 사항이 여러 아키텍처 계층을 건드리는 경우가 많거든... 근데 이게 그냥 평범한 소프트웨어 엔지니어링 아니야? 사람들이 말하는 '코딩의 90%를 Luna로 처리한다'는 게 내가 생각하는 거랑 다른 건가? 뭔가 뻔한 걸 내가 놓치고 있는 것 같기도 하고.
참고로 나는 Codex를 꽤 자율적으로 써. 처음에는 챗으로 기능을 구현하거나 리팩토링할 계획을 세우지. 작업이 좀 복잡하면 작은 단위로 쪼갠 계획을 세우고, 아니면 그냥 기본적인 Codex 계획을 짜. 그다음에 계획을 검토하고 수정해. 그러고 나서 목표를 설정하고 일종의 '자기 검증 루프'를 돌려. Codex가 지가 짠 코드가 기능적으로, 아키텍처적으로, UI적으로 기대치에 맞는지 스스로 확인하게 만드는 거지. 그 다음에 코디네이터 에이전트를 실행해서 가능한 한 작업을 병렬로 처리하게 시켜 (보통 DAG 구조를 미리 짜두거든).
작업 하나당 복잡도에 따라 2시간에서 18시간까지 자율적으로 돌아가게 둠.
Luna 찬양하는 사람들한테 묻고 싶음: 도대체 뭘 시키고 있는 거임?
아키텍처나 해결책이 이미 다 정해져 있는 작고 좁은 범위의 변경 사항을 말하는 거야?
아니면 진짜로 복잡한 기능 구현이나 리팩토링을 맡겨도 제대로 된 결과물이 나오는 거야?
Luna로 "토큰 아껴보려고" 할 때마다 결국 처음부터 Sol을 쓸 걸 그랬다는 후회만 함. 물론 Sol은 주간 할당량을 미친 듯이 잡아먹고, 가끔 과하게 설계를 복잡하게 만드는 경향이 있긴 하지만.
그래서 요즘은 오래 걸리는 작업에는 Claude를 주로 써. Opus 5가 딱 적당하더라고. 정확도도 높고 과하게 설계하지도 않음. 제한도 널널해서 서브 에이전트나 팀 써서 병렬 작업 돌려도 주간 할당량의 10~15% 정도면 12시간은 돌릴 수 있어. Codex로 똑같은 세션 돌리면 Sol 기준 주간 할당량의 40% 이상을 처먹거든.
그러니까 제발 너희들이 어떻게 Luna로 사용량을 아끼면서 쓰고 있는지 좀 알려줘라.
