요즘 회사 일이 잠깐 숨 돌릴 틈이 생겨서, 예전에 계속 미뤄뒀던 레거시 프로젝트를 하나씩 손보고 있었어요. 그런데요. 막상 열어보니까 마음이 좀 무거워지더라고요. 5년 전 코드, 7년 전 코드가 꼭 오래된 여행 가방처럼 느껴질 때가 있어요. 열기 전엔 별거 아니겠지 싶은데, 열고 나면 어디서부터 정리해야 할지 잠깐 멍해지는 그 느낌 있잖아요.
저도 개발을 20년 가까이 해왔지만, 솔직히 요즘은 AI 없이 코딩하는 게 더 어색한 시대가 된 것 같아요. GitHub Copilot도 오래 써봤고, Cursor도 업무에 꽤 진지하게 붙여봤는데, 최근에는 Roo Code라는 AI 코딩 에이전트를 써보면서 생각이 좀 달라졌습니다. 단순히 코드 몇 줄 추천해주는 도구가 아니라, 뭐랄까, 옆자리 개발자에게 “이거 한번 같이 정리해보자” 하고 맡기는 느낌이 꽤 강했거든요.
그래서 이 글은 사용법 소개라기보다는, 제가 실제 업무에서 Roo Code로 AI 바이브 코딩을 어떻게 해봤는지, 어디서 편했고 어디서 식은땀 났는지, 그리고 비용과 시간을 아끼려면 어떻게 다뤄야 하는지를 편하게 풀어보려고 해요. 친구한테 커피 마시면서 얘기하듯이요.
Roo Code가 좀 다르게 느껴졌던 이유
처음에는 저도 그냥 “또 하나의 AI 코딩 도구겠지” 했어요. 요즘 워낙 비슷한 도구가 많이 나오니까요. 그런데 Roo Code는 Copilot처럼 내가 타이핑하는 옆에서 코드 조각을 슬쩍 제안하는 방식하고는 결이 조금 달랐습니다.
제가 느낀 가장 큰 차이는 작업을 맡길 수 있다는 점이었어요. 예를 들어 “이 폴더 안에 있는 모든 API 라우트에 JWT 인증 미들웨어를 추가해줘”라고 말하면, Roo Code가 프로젝트 파일을 읽고, 필요한 파일을 찾아보고, import 문도 추가하고, 경우에 따라 테스트 명령까지 실행해봅니다. 물론 늘 완벽하진 않아요. 그런데 흐름 자체가 꽤 개발자스럽습니다.
Copilot이 “이 줄 다음에 이런 코드 어때요?” 하고 속삭이는 느낌이라면, Roo Code는 “제가 한번 전체 구조 보고 손대볼게요”에 가깝달까요. 그래서 저는 요즘 단순 구현보다 레거시 정리, 반복 작업, 마이그레이션 초안 만들기 쪽에 Roo Code를 자주 붙이고 있어요.
| 비교 항목 | GitHub Copilot | Roo Code |
|---|---|---|
| 주요 느낌 | 옆에서 코드 추천해주는 조수 | 작업 단위를 맡길 수 있는 에이전트 |
| 동작 방식 | Inline 코드 제안 중심 | 터미널 기반으로 파일 탐색과 명령 실행 |
| 잘 맞는 작업 | 함수 작성, 반복 코드 보완 | 리팩토링, 마이그레이션, 여러 파일 수정 |
| 주의할 점 | 맥락을 놓치면 엉뚱한 제안이 나옴 | 프로젝트 전체를 건드릴 수 있어 검토가 꼭 필요함 |
다만 여기서 살짝 조심해야 할 게 있어요. Roo Code는 꽤 적극적으로 움직입니다. 이게 장점이기도 한데, 반대로 말하면 내가 의도하지 않은 파일까지 건드릴 가능성도 있다는 뜻이에요. 그래서 저는 Roo Code를 “믿고 맡기는 도구”라기보다는 “일 잘하는데 중간중간 방향 잡아줘야 하는 후배 개발자” 정도로 생각하고 씁니다. 이 비유가 제일 맞는 것 같아요.
실제로 써먹은 사례: 레거시 Express API에 TypeScript 입히기
제가 Roo Code를 꽤 괜찮게 봤던 순간은 Node.js Express API를 TypeScript로 마이그레이션할 때였어요. 이 프로젝트가 5년 정도 된 서비스였는데, JavaScript로만 되어 있었고 타입 정의도 거의 없었습니다. 처음 만들 때는 작았는데, 기능이 계속 붙으면서 어느 순간 “이거 잘못 건드리면 터지겠다” 싶은 상태가 됐죠.
이런 코드 있잖아요. 당장 돌아가긴 하는데, 수정하려고 보면 마음이 불편한 코드. 저도 그런 프로젝트를 보면 괜히 커피를 한 잔 더 마시게 됩니다.
처음 Roo Code에게 이렇게 지시했어요.
이 Express 프로젝트를 TypeScript 기반으로 마이그레이션해줘.
단, 기존 API 동작은 깨지면 안 되고, 먼저 현재 폴더 구조를 파악한 뒤 변경 계획을 보여줘.
바로 파일을 수정하지 말고, 어떤 파일을 바꿀지 먼저 설명해줘.
여기서 제가 일부러 넣은 문장이 있어요. “바로 파일을 수정하지 말고” 이 부분입니다. 이거 꽤 중요해요. Roo Code 같은 에이전트는 의욕이 좋아서, 가끔 설명하기도 전에 파일부터 고치려고 합니다. 사람도 그렇잖아요. 똑똑한데 급한 친구들이 꼭 있어요.
Roo Code는 먼저 프로젝트 구조를 읽고, 대략 이런 순서로 작업 계획을 잡았습니다.
- 기존 package.json에서 빌드 스크립트와 의존성 확인
- tsconfig.json 생성
- src 폴더의 .js 파일을 .ts로 단계적 변경
- Express Request, Response 타입 추가
- 환경 변수와 route parameter에 대한 타입 가드 추가
- npm run build 실행 후 에러 수정
여기까지 보고 “오, 생각보다 침착한데?” 싶었어요. 그래서 진행하라고 했습니다. 그러자 Roo Code가 tsconfig.json을 만들고, 필요한 타입 패키지를 확인하고, 파일 확장자를 바꾸고, import 경로까지 조금씩 손봤습니다.
물론 한 번에 아름답게 끝나진 않았어요. 그런 마법은 없습니다. 중간에 빌드 에러가 났고, 그 에러가 오히려 이 도구를 어떻게 써야 하는지 감을 잡게 해줬어요.
src/routes/user.ts:25:18 - error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
Type 'undefined' is not assignable to type 'string'.
이 에러를 보고 제가 Roo Code에게 다시 말했어요.
userId route parameter가 undefined일 수 있는 상황을 처리해줘.
단순 type assertion으로 덮지 말고, 잘못된 요청이면 400 응답을 반환하도록 타입 가드를 추가해줘.
비슷한 패턴이 있는 route도 같이 확인해줘.
이렇게 말하니까 Roo Code가 단순히 as string으로 뭉개지 않고, 실제로 parameter 체크를 넣어줬습니다. 제가 이 부분에서 좀 만족했던 이유는, “에러를 없애는 코드”가 아니라 운영에서 덜 위험한 코드 쪽으로 유도할 수 있었기 때문이에요.
혼자 했으면 아마 반나절은 잡아먹었을 작업이었는데, 실제로는 한 시간 조금 안 걸렸습니다. 물론 그 한 시간 안에는 제가 코드 리뷰한 시간도 포함이에요. AI가 고친 코드를 눈 감고 merge하는 건, 솔직히 저는 아직 못 하겠더라고요. 그건 용기가 아니라 방심에 가깝습니다.
Roo Code 쓸 때 시간을 아껴준 작은 습관들
Roo Code를 며칠 써보면 금방 느껴지는 게 있어요. 이 도구는 프롬프트를 대충 줘도 뭔가 하긴 합니다. 그런데 일을 잘하게 만들려면 경계선을 잘 그어줘야 해요. 사람한테 일 부탁할 때도 마찬가지잖아요. “알아서 해줘”라고 하면 서로 피곤해지는 경우가 많습니다.
Context 파일은 미리 챙겨두는 게 좋더라고요
프로젝트가 작을 때는 크게 상관없는데, 폴더가 커지면 Roo Code가 이것저것 읽으면서 토큰을 꽤 씁니다. 특히 monorepo거나 오래된 프로젝트면 안 봐도 되는 파일이 너무 많아요. build 결과물, fixture, 오래된 migration, 임시 백업 파일 같은 것들이요.
저는 그래서 .roorules 같은 규칙 파일에 대략 이런 내용을 적어둡니다.
dist 폴더는 읽지 마.
node_modules는 절대 탐색하지 마.
.env 파일은 열거나 수정하지 마.
migration 파일은 참조만 하고 수정하지 마.
테스트를 실행하기 전에는 어떤 명령을 실행할지 먼저 알려줘.
이렇게 해두면 확실히 덜 헤맵니다. 비용도 조금 줄고요. 사실 AI 도구를 쓰다 보면 “몇 천 원 아끼자”보다 더 중요한 게 있어요. 내가 원하지 않는 방향으로 작업이 커지는 걸 막는 것입니다. 토큰 비용보다 개발자 멘탈 비용이 더 비쌀 때가 많거든요.
“바로 수정하지 말고 계획부터 보여줘”라는 말은 거의 습관처럼 씁니다
Roo Code에게 “리팩토링해줘”라고만 말하면 일단 움직입니다. 그런데 리팩토링이라는 말이 너무 넓잖아요. 어떤 사람은 함수 분리를 떠올리고, 어떤 사람은 레이어 구조 변경을 떠올리고, 어떤 사람은 네이밍 정리를 떠올립니다. AI도 비슷해요. 내가 생각한 리팩토링과 Roo Code가 생각한 리팩토링이 다를 수 있습니다.
그래서 저는 보통 이런 식으로 말합니다.
- 변경 전에 현재 구조를 요약해줘.
- 수정 대상 파일 목록을 먼저 보여줘.
- 작업 단계를 3단계 이내로 나눠줘.
- 기존 테스트가 있으면 먼저 실행해줘.
- 파일을 수정하기 전에 내가 승인할 수 있게 멈춰줘.
이렇게 말하면 Roo Code가 훨씬 얌전해집니다. 표현이 좀 웃기지만 진짜 그래요. 급하게 달려나가던 도구가 잠깐 앉아서 회의록 쓰는 느낌이 됩니다.
한 번에 큰 덩어리를 맡기면 꼭 어딘가 삐끗합니다
제가 초반에 했던 실수 중 하나가 이거였어요. “회원가입 API 만들어줘. DB 연결하고, validation 넣고, JWT 발급하고, 테스트까지 만들어줘.” 이렇게 한 번에 던진 적이 있습니다. 결과요? 돌아가긴 하는데 폴더 구조가 제 스타일이 아니고, import 경로가 애매하고, validation 방식도 기존 코드랑 달랐어요.
그때 느꼈습니다. AI 바이브 코딩은 대충 맡기는 게 아니라, 리듬을 잘게 쪼개는 작업이구나 하고요.
| 제가 피하는 요청 | 요즘 쓰는 요청 |
|---|---|
| 회원가입 기능 전체 만들어줘 | User 모델에 필요한 필드만 먼저 제안해줘 |
| 인증 시스템 붙여줘 | 기존 middleware 구조를 보고 JWT 검증 middleware 초안만 만들어줘 |
| 전체 리팩토링해줘 | routes/user.ts 파일에서 중복 validation만 분리해줘 |
작게 시키면 결과가 훨씬 낫습니다. 그리고 중간에 제가 방향을 바꿀 수도 있어요. 개발이라는 게 원래 그렇잖아요. 하다 보면 처음 생각이 조금씩 바뀝니다. AI에게도 그 여백을 남겨줘야 덜 피곤합니다.
좋았던 점만 말하면 좀 섭섭하죠, 실패담도 있습니다
Roo Code가 꽤 쓸 만한 건 맞는데, 만능은 절대 아닙니다. 오히려 잘 쓰려면 어느 정도 의심하는 습관이 필요해요. 저는 한 번 꽤 아찔했던 적이 있습니다.
개발 환경용 Docker compose 파일을 만들어달라고 했어요. 저는 로컬에서만 쓸 가벼운 구성, 그러니까 API 서버와 PostgreSQL 정도를 생각했는데, Roo Code가 개발 환경과 프로덕션 환경을 묘하게 섞은 compose 파일을 만들어버렸습니다. 거기에 volume mount 경로도 제가 쓰는 로컬 구조와 달랐고요. 잘못 실행했으면 로컬 DB 데이터가 꼬일 뻔했습니다.
그 순간 살짝 등에서 땀이 나더라고요. 여행 가서 숙소 주소 잘못 찍고 낯선 골목에 들어간 느낌이랄까요. 큰일은 아닌데, “어, 이 길 아닌데?” 싶은 그 싸한 느낌이 있습니다.
- Docker, DB, 인증, 배포 관련 파일은 자동 수정 전에 반드시 diff를 본다.
- .env, secret, credential이 엮인 작업은 AI에게 직접 열어보게 하지 않는다.
- 운영 환경에 영향을 줄 수 있는 명령은 실행 전에 무조건 멈추게 한다.
- 생성된 설정 파일은 공식 문서와 한 번 더 대조한다.
또 하나 조심할 점은 최신 라이브러리나 빠르게 바뀌는 프레임워크입니다. 예를 들어 Next.js App Router처럼 버전별로 패턴이 빨리 바뀌는 영역에서는 Roo Code가 예전 방식으로 코드를 작성할 때가 있어요. 이건 Roo Code만의 문제라기보다 AI 코딩 도구 전반의 문제에 가깝습니다.
그래서 저는 최신 기술을 다룰 때 이렇게 요청합니다.
Next.js 15 기준으로 작성해줘.
확실하지 않은 API는 임의로 만들지 말고, 내가 확인할 수 있게 주석으로 표시해줘.
기존 Next.js 14 방식과 섞지 말아줘.
이렇게 해도 완벽하진 않지만, 적어도 AI가 자신감 있게 틀리는 상황은 조금 줄어듭니다. 저는 이게 중요하다고 봐요. AI가 모르는 걸 모른다고 말하게 만드는 것. 개발자도 그렇고 AI도 그렇고, 모르는 걸 아는 척할 때 사고가 납니다.
제가 자주 쓰는 Roo Code 프롬프트 패턴
몇 번 삽질하고 나니까, 저한테 잘 맞는 말투가 생겼습니다. 너무 길게 장황하게 쓰기보다, 목표, 제한 조건, 확인 방식을 같이 주는 게 제일 안정적이었어요.
| 상황 | 제가 실제로 쓰는 요청 방식 |
|---|---|
| 레거시 코드 분석 | 이 폴더의 구조를 먼저 요약해줘. 수정은 하지 말고, 위험해 보이는 부분과 테스트가 부족한 부분만 알려줘. |
| 리팩토링 | 동작은 바꾸지 말고 중복 코드만 줄여줘. 변경 전후로 어떤 함수가 바뀌었는지 설명해줘. |
| 테스트 추가 | 현재 구현을 기준으로 실패 케이스 중심의 테스트를 먼저 작성해줘. 구현 코드는 아직 수정하지 마. |
| 빌드 에러 수정 | 이 에러를 고쳐줘. 단, type assertion으로 숨기지 말고 실제 런타임 안전성이 좋아지는 방향으로 수정해줘. |
| 설정 파일 생성 | 개발 환경 전용 설정만 만들어줘. 운영 환경 설정과 섞지 말고, 실행 전에 내가 확인할 수 있게 멈춰줘. |
이런 식으로 요청하면 Roo Code가 훨씬 덜 엇나갑니다. 특히 “수정하지 마”, “먼저 보여줘”, “기존 동작은 유지해줘” 같은 표현은 거의 안전벨트처럼 쓰고 있어요. 개발할 때 안전벨트 좀 답답해도, 사고 한 번 막아주면 그걸로 값어치 다 한 거니까요.
Roo Code를 써도 사람 개발자가 꼭 봐야 하는 부분
제가 주변 개발자들에게 Roo Code 이야기를 하면 꼭 같이 말하는 게 있어요. AI가 코드를 빨리 만들어주는 것과, 그 코드가 좋은 코드인지는 별개의 문제라는 겁니다.
Roo Code는 빠릅니다. 꽤 똑똑하고요. 그런데 프로젝트의 맥락, 팀의 히스토리, 장애 났던 기억, 운영하면서 생긴 암묵적인 규칙까지 다 아는 건 아닙니다. 그런 건 아직 사람 몫이에요. 특히 오래된 서비스에는 코드에 안 적힌 사정이 많습니다. 이 API는 왜 이상한 응답 포맷을 유지하는지, 이 필드는 왜 nullable인지, 이 배치 작업은 왜 새벽 3시에만 돌아야 하는지. 이런 건 문서에도 없는 경우가 많잖아요.
- AI가 만든 코드라도 diff 확인은 꼭 하기
- 테스트가 없으면 기능 추가보다 테스트 작성을 먼저 시키기
- 보안, 인증, 결제, 개인정보 쪽은 자동 생성 결과를 절대 그대로 믿지 않기
- 팀 컨벤션과 다른 스타일이 나오면 바로잡아주기
- 빌드 성공만 보지 말고 실제 시나리오로 한 번 더 확인하기
저는 개인적으로 Roo Code를 “개발자를 대체하는 도구”라고 보진 않습니다. 오히려 개발자의 손을 빠르게 만들어주는 도구에 가깝다고 봐요. 설계 감각, 위험 판단, 운영 경험은 여전히 사람이 붙잡고 있어야 합니다. 이 부분을 놓치면 AI 코딩은 생산성이 아니라 기술 부채 생성기가 될 수도 있어요.
이런 개발자라면 Roo Code를 꽤 재밌게 쓸 수 있을 거예요
20년 동안 개발하면서 정말 많은 도구를 써봤습니다. IDE도 바뀌었고, 프레임워크도 바뀌었고, 배포 방식도 몇 번이나 세대교체가 됐죠. 그중에서 Roo Code는 꽤 인상적인 편입니다. 특히 반복 작업이 많거나, 레거시 코드를 정리해야 하거나, 빠르게 프로토타입을 만들어야 하는 개발자에게는 확실히 도움이 됩니다.
| 추천 대상 | 잘 맞는 이유 |
|---|---|
| 레거시 프로젝트를 맡은 개발자 | 구조 분석, 타입 추가, 반복 리팩토링 초안을 빠르게 만들 수 있음 |
| CRUD API를 자주 만드는 백엔드 개발자 | 모델, route, validation, 테스트 초안 작성 시간을 줄일 수 있음 |
| MVP를 빨리 만들어야 하는 스타트업 개발자 | 초기 구조와 반복 코드를 빠르게 잡아볼 수 있음 |
| AI 코딩 도구를 이미 써본 개발자 | Copilot보다 큰 작업 단위를 맡기는 방식에 적응하기 쉬움 |
반대로, 아직 코드 리뷰나 테스트에 익숙하지 않은 상태에서 “AI가 다 해주겠지”라는 마음으로 쓰면 조금 위험할 수 있어요. Roo Code는 좋은 도구지만, 방향을 잘못 주면 정말 성실하게 잘못된 방향으로 달려갑니다. 그게 무섭습니다. 게으른 도구보다 부지런하게 틀리는 도구가 더 위험할 때가 있거든요.
제 기준에서 Roo Code로 AI 바이브 코딩을 잘하는 방법은 단순합니다. 작게 맡기고, 자주 확인하고, 위험한 건 직접 판단하기. 이 세 가지만 지켜도 꽤 쓸 만합니다. 특히 레거시 코드를 정리해야 하는 분, 반복 작업에 지친 백엔드 개발자, AI 코딩 도구를 업무에 진지하게 붙여보고 싶은 분이라면 한 번쯤 써볼 만해요.
저도 아직 완전히 익숙해진 건 아닙니다. 매번 조금씩 배워요. 어떤 날은 “와, 이걸 이렇게 빨리?” 싶고, 어떤 날은 “아니, 이걸 왜 이렇게 했지?” 싶습니다. 그래도 분명한 건 하나예요. 이제 개발자는 AI를 쓸지 말지를 고민하는 단계는 지난 것 같습니다. 어떻게 안전하게, 내 스타일대로, 팀에 맞게 쓸 것인가가 더 중요한 질문이 된 것 같아요.
혹시 Roo Code를 처음 써보려는 분이라면, 운영 코드에 바로 붙이기보다는 작은 사이드 프로젝트나 테스트용 레거시 모듈부터 시작해보세요. 그게 마음도 편하고, 도구의 성격도 금방 보입니다. 저처럼 오래 개발한 사람도 아직 배우는 중이니, 너무 겁먹을 필요는 없고요. 다만, merge 버튼 누르기 전에는 꼭 한 번 더 봅시다. 그건 우리 개발자들의 오래된 생존 본능이니까요.
댓글
댓글 쓰기