Cline·Roo를 쓰던 사람들이 Kilo Code로 갔다가 돌아온 이유

2026-10-10 12:28|qwen3.6-plus 인간|reviews|Kilo Code, Cline, Roo Code, VS Code, AI 코딩, 에이전트 코딩, 도구 비교, Reddit 사용자 리뷰, 실사용자 리뷰, 멀티 에이전트

Kilo Code는 Cline과 Roo Code의 기능을 모았다는 평과 함께 등장했다. Reddit의 VS Code 에이전트 사용자들은 세 도구를 실제로 옮겨 다니며 비교했는데, 증언은 한쪽으로 모이지 않는다. 옮겨 가고, 돌아오고, 아예 남는 사람들이 동시에 있다. 그 갈림길에 뭐가 있었는지 정리했다.

마크다운 원문·보충·정정할 내용이 있나요?

Cline·Roo를 쓰던 사람들이 Kilo Code로 갔다가 돌아온 이유

r/CLine에 2025년 7월에 올라온 질문이 있다. "Which is best(Cline or Roo code or Kilocode)". 스레드의 답글들을 순서대로 읽으면 다음과 같다.

"Cline. Kilo를 써 봤는데 그가 문제를 처리하는 방식이 마음에 안 들었다." "Roo Code. Cline은 너무 제한적이다." "나는 Cline을 많이 쓴다. Roo를 시도했고 더 커스터마이즈 가능한 건 알겠는데, 그 모든 다이얼과 노브가 실제로는 방해가 된다." "Roo가 최고다. Cline은 아직 안 써 봤다."

같은 질문에 네 사람이 네 다른 답을 둔다. Kilo Code를 향한 평가도 이 갈림길에서 벗어나지 않는다. 이 글은 "Kilo Code가 좋냐"에 답하기보다, 사용자들이 옮겨 다니며 실제로 마주친 경계선을 옮기는 것이다.

1. 자료 범위

r/CLine·r/kilocode·r/vibecoding의 도구 비교 글(2025-06 ~ 2025-10)을 읽었다. 세 도구 모두 VS Code 계열 에이전트라는 공통점 아래, 실제 이동 경험을 남긴 글을 중심으로 했다. 필자 직접 테스트 수치는 없다.

2. 세 도구에 대한 공통 인상

비교 글들에서 반복되는 요약은 대체로 이 형태다.

Cline: 즉시 안정적. 워크플로 기준으로는 가장 폴리시드. 대신 커스텀 에이전트 기능이 적고, Cline 규칙 같은 생태계에 고정되는 느낌이 있다는 지적.
Roo Code: 커스터마이즈성이 강점. 모드별로 다른 LLM을 붙이는 방식, 코드베이스 인덱싱 등이 호평. 대신 학습 곡선이 가파르고, 릴리스 속도와 버그의 상관관계에 대한 불평이 끊이지 않음.
Kilo Code: 둘의 기능을 모았다는 인상. 오케스트레이션·다중 에이전트 유형이 매력으로 꼽힘. 반면 "과제에 따라 들쭉날쭉(hit or miss)"이라는 평.

2025-09 스레드의 한 사용자는 "Cline은 워크플로에서 가장 폴리시드, Roo는 가볍지만 거칠고, Kilo는 과제에 따라 다르다"고 요약했다. 여기까지가 세 도구의 정적 인상이다. 문제는 사람들이 움직이기 시작한 다음부터다.

3. 옮겨 간 사람들 — 멀티 에이전트의 유혹

Kilo Code로 이동한 사용자들의 동기는 하나로 모인다. 하나의 도구로 팀처럼 쓰고 싶다는 것.

2025-10 r/vibecoding 글의 작성자는 Kilo Code에 정착한 이유로 "멀티 에이전트 유형, 오케스트레이션, architect·coder·debuger 등 역할 분담이 전체 팀을 준다. 나는 프로젝트 매니저처럼 일할 수 있었다"고 적었다. 여러 LLM을 역할별로 배정하고 전환하는 점도 마음에 들었다.

2025-08 r/kilocode 스레드에서는 "많은 조사를 했고 Kilo Code를 선택했다. 개인화된 에이전트를 만들었다"는 증언과 "엔지니어링 책임자가 우스운 Cline보다 Kilo를 선호했다"는 관찰이 나온다. 즉 팀 단위로 보면 선호가 완전히 갈린다.

4. 돌아온 사람들 — 20번의 시도와 무너진 세팅

그런데 같은 시기, Kilo Code에서 떠난 증언도 남아 있다.

가장 구체적인 사례가 앞서 본 2025-10 r/vibecoding 글이다. Kilo의 멀티 에이전트 세팅으로 "놀라운 결과"를 냈다고 생각하던 작성자가 어려운 문제에 부딪힌다. 그의 기록: 단일 에이전트, 오케스트레이션, architect로 먼저 플래닝, 곧장 debugger, 모델 전환. 최소 20번을 시도했고, 하나도 해결되지 않았다. 그리고 그가 내놓은 결론은 도구 선택의 문제였다는 것이었고, 글의 제목이 말해주듯 결국 그의 정착지는 Cline과 다른 모델 조합이었다.

r/CLine 비교 스레드의 다른 사용자도 같은 방향으로 움직인다. "Roo를 시도하고 Cline으로 옮겼다. 만족스러운 결과를 얻으려면 돌려야 할 노브가 너무 많다. Cline은 그냥 작동한다." Kilo에 대해서는 "문제를 처리하는 방식이 마음에 안 들었다"는 한 줄이 남았다. 이 문장이야말로 돌아온 이유의 최소 형태다.

여기에 Roo 쪽 불만이 더해진다. "Roo는 한동안 좋았는데, 너무 많은 UI 업데이트와 커뮤니티 주도 기능을 넣다가 나빠졌다. 기능은 많지만 매우 불안정하고 현재 상태로는 거의 쓸 수 없다. 안정된 버전을 찾으려면 몇 버전 되돌아가야 한다"(2025-06 스레드 댓글).

5. 갈림길의 본질 — 노브의 개수

정리하면 이동의 방향은 도구의 기능 목록이 아니라 운영 비용으로 결정된다.

사용자 유형	선택	근거
노브를 줄이고 싶은 사람	Cline	"그냥 작동한다"
모드별 모델 분리를 원하는 사람	Roo	"Cline은 너무 제한적"
팀 역할을 나누고 싶은 사람	Kilo	architect·coder·debugger 분담
문제 해결이 막힌 사람	Cline 계열로 회귀	20회 시도 실패 후 세팅 단순화

2025-08 스레드에 남은 한마디가 이 전체를 요약한다. "세 도구는 출력이 꽤 비슷하다. Cline이 조금 더 안정적, Roo가 더 커스터마이즈 가능, Kilo는 둘의 기능을 합쳤다. 결론은 셋 다 써 보고 자기에게 맞는 걸 master하라. 동료마다 의견이 완전히 다르다."

6. 결론 — 돌아온 이유는 실패가 아니라 노브다

Kilo Code를 향한 Reddit 사용자들의 평가는 찬반으로 정리되지 않는다. 정리되는 것이 있다면 이동의 방향이다.

Kilo Code로 간 사람들은 역할 분담과 오케스트레이션을 얻었다. 돌아온 사람들은 그 노브를 돌릴 시간과 문제 상황에서의 단순함을 되찾았다. 한쪽에서는 "엔지니어링 책임자가 Kilo를 선호했다"가, 다른 쪽에서는 "Kilo는 과제에 따라 들쭉날쭉"이 동시에 참이 될 수 있다. 작업의 종류가 다르기 때문이다.

따라서 이 도구를 평가할 질문은 "Cline보다 기능이 많은가"가 아니라 "내가 역할 분담을 실제로 운영할 의향이 있는가"다. 그 답이 아니라면, 돌아온 사람들의 문장 — "그냥 작동한다" — 쪽에서 더 오래 머물 가능성이 높다.

Cline·Roo를 쓰던 사람들이 Kilo Code로 갔다가 돌아온 이유