Composer는 코드 추가만 할 줄 아는 것 같다

Composer 2.5를 한동안 사용해 왔는데, 가장 큰 문제는 이 녀석이 코드 추가만 할 줄 아는 것 같다는 점이야.

작업이 직관적이고 새로운 것을 구현하는 데 집중되어 있을 때는 꽤 괜찮아. 명확한 목표를 주면 계속해서 앞으로 나아가거든.

내가 어려움을 겪는 부분은 디버깅과 유지보수 작업이야.

Composer 2.5는 추론 범위가 놀라울 정도로 좁게 느껴질 때가 많아. 버그의 원인이 무엇인지에 대한 이론을 일단 형성하고 나면, 한 발 물러서서 다른 설명을 고려하기보다는 그 이론을 고수하는 경향이 있어.

그 결과, 나는 이 녀석이 자신의 가정이 맞다면 완벽하게 논리적인 변경을 자신 있게 수행하는 모습을 자주 봐. 하지만 그 가정 자체가 틀린 것으로 판명되지. 수정안은 그럴듯해 보이고 설명도 설득력 있게 들리지만, 실제 버그는 그대로 남아 있어.

이게 특히 좌절스러운 이유는 이런 잘못된 수정들이 공짜로 얻어지는 게 아니라는 점이야. 이런 수정들은 종종 애초에 필요하지 않았던 추가 코드, 추가 복잡성, 추가 컨텍스트를 덧붙여. 이런 과정을 몇 번 거치고 나면, 실제로는 이해조차 되지 않은 문제를 해결하기 위해 토큰을 엄청나게 낭비하며 해결책을 구현하고 있는 자신을 발견하게 돼.

물론 이건 내 프롬프트 방식의 문제일 수도 있어. 문제는 내가 '프롬프트 엔지니어링' 관점에서 생각하지 않는다는 거야. 나는 Composer를 세심하게 다듬어진 지시가 필요한 시스템이라기보다는 협업자로 대하면서, 자연스러운 대화를 통해 '바이브 코딩(vibe coding)'을 하는 편이지.

어쩌면 그게 비현실적인 기대일지도 몰라. 하지만 나는 Composer가 특히 기존 코드베이스 내에서 작업할 때 스스로의 가정을 좀 더 자주 의심해 주었으면 하는 바람이 있어.

그렇긴 해도, 가격을 고려하면 여전히 인상적인 도구야. 다만 나는 이 도구의 강점이 구현 쪽에 너무 치우쳐 있고, 기존 코드베이스 전반에 걸친 근본 원인 분석과 폭넓은 추론 능력은 훨씬 약하다고 느껴.

다른 사람들도 비슷한 경험을 했는지 궁금하네.