Featured Post

AI 바이브 코딩으로 GitHub Actions 짤 때, 토큰 덜 쓰고 덜 헤매는 내 방식

작성자:
0

Repomix로 LLM 토큰 아끼는 법, 제가 실제 프로젝트에서 쓰는 방식입니다

작성자:
Repomix - 코드 컨텍스트 관련 이미지

요즘 주변 개발자들이랑 이야기하다 보면 AI 바이브 코딩 얘기가 정말 자주 나와요. 저도 벌써 개발자로 밥 먹고 산 지 20년 가까이 됐는데, 솔직히 요즘은 LLM 없이 코딩하는 날이 더 어색하더라고요. 코드 리뷰도 시키고, 리팩토링 방향도 물어보고, 레거시 코드 읽다가 막히면 “야, 이거 좀 같이 보자” 하는 느낌으로 AI를 켜게 됩니다.

그런데 쓰면 쓸수록 자꾸 신경 쓰이는 게 하나 있어요. 바로 토큰입니다. 뭐랄까, 여행 갈 때 캐리어 무게 제한 신경 쓰는 느낌이랑 비슷해요. 이것도 넣고 싶고, 저것도 넣고 싶은데 다 넣으면 초과 요금 나오는 그런 느낌이죠. LLM에 프로젝트 코드를 넘길 때도 딱 그래요. 파일 몇 개 붙여넣다 보면 어느새 컨텍스트가 터지고, 정작 중요한 질문을 하기도 전에 한도가 아슬아슬해집니다.

특히 오래된 회사 프로젝트나 폴더 구조가 복잡한 백엔드 코드를 AI한테 설명하려고 하면 참 난감해요. “이 프로젝트는 Express고요, auth middleware가 있고요, controller는 이런 식이고요…” 하다 보면 제가 AI한테 코드를 설명하는 건지, 프로젝트 인수인계를 하는 건지 헷갈릴 때가 있거든요. 그래서 한동안 이것저것 써보다가 지금은 Repomix를 꽤 꾸준히 쓰고 있습니다. 오늘은 제가 실제로 쓰는 방식 그대로, 너무 거창하지 않게 풀어볼게요.

Repomix, 처음엔 저도 그냥 파일 합치는 도구인 줄 알았습니다

제가 Repomix를 처음 본 건 어느 개발자 커뮤니티에서였어요. 누가 “프로젝트 전체를 LLM에게 먹이기 좋게 하나의 파일로 만들어준다”고 하더라고요. 그때 제 첫 반응은 솔직히 이랬습니다. “그냥 cat으로 합치면 되는 거 아닌가?”

근데 막상 써보니까 좀 달랐어요. 단순히 파일을 줄줄이 붙이는 게 아니라, 프로젝트 디렉토리를 훑으면서 LLM이 읽기 좋은 형태로 파일 구조와 코드 내용을 정리해주는 도구에 가깝더라고요. 특히 .gitignore를 알아서 인식해주는 점이 마음에 들었습니다. node_modules, dist, build 같은 애들은 굳이 AI한테 보여줄 필요 없잖아요. 걔들까지 보내면 토큰만 먹고 답변 품질은 오히려 떨어집니다.

제가 제일 자주 쓰는 명령어는 이거예요.

npx repomix --style markdown --output ./ai-context.md

이렇게 한 줄 치면 프로젝트 안의 주요 파일들이 ai-context.md 하나로 정리됩니다. 저는 이 파일을 열어보고 “아, 이번 질문에 이 정도면 충분하겠다” 싶으면 그대로 ChatGPT나 Claude에 붙여넣어요. 예전처럼 폴더 하나하나 열어가며 복사할 필요가 없으니, 이게 생각보다 몸이 편합니다. 개발하다가 흐름 끊기는 게 제일 싫잖아요.

비교 항목 제가 예전에 하던 직접 복붙 Repomix를 썼을 때
토큰 소모량 대략 15,000 ~ 25,000 tokens까지 금방 올라감 필요한 파일만 고르면 4,000 ~ 8,000 tokens 선에서 정리됨
준비 시간 파일 찾고, 열고, 복사하고, 설명 붙이느라 5~10분 터미널에서 명령어 한 번, 보통 몇 초
누락 위험 제가 기억 못 하면 빠짐 프로젝트 구조 기준으로 정리되니 훨씬 안정적
AI 답변 품질 제가 설명한 만큼만 이해함 실제 코드 흐름을 보고 판단하는 느낌이 강함

이 차이가 은근 큽니다. 특히 회사에서 운영 중인 프로젝트는 머릿속에 다 들어있는 것 같아도 막상 설명하려면 빠지는 게 생기거든요. controller 하나 이야기하다가 service를 빼먹고, middleware 설명하다가 type 정의를 놓치고요. 그러면 AI도 엉뚱한 코드를 만들어냅니다. AI가 멍청해서라기보다, 제가 재료를 엉성하게 준 거죠.

LLM에게 코드를 던질 때는 “설명”보다 “맥락”이 더 잘 먹히더라고요

예전에는 AI에게 뭘 부탁할 때 제가 엄청 설명하려고 했어요. 예를 들어 Node.js 백엔드 프로젝트에 새 API를 하나 추가해야 한다고 치면, 이런 식이었습니다.

“이 프로젝트는 Express를 쓰고 있고, routes 폴더 안에 user route가 있고, auth middleware는 이런 식으로 붙이고, user controller는 대충 이런 패턴이고, 에러 처리는 AppError를 쓰고…”

이러다 보면 제 설명이 길어집니다. 길어지면 토큰도 많이 먹고요. 더 피곤한 건, 제가 설명을 살짝 잘못하면 AI도 그걸 믿고 갑니다. 오래된 주석을 보고 착각하는 후배 개발자처럼요. 나쁜 뜻은 아닌데, 방향이 틀어지는 거죠.

요즘은 접근을 조금 바꿨어요. 제가 프로젝트를 설명하려고 애쓰는 대신, Repomix로 뽑은 컨텍스트를 먼저 주고 AI가 직접 읽게 합니다.

[여기에 Repomix로 만든 프로젝트 컨텍스트 붙여넣기]

위 프로젝트에 새로운 사용자 알림 설정 API를 추가하려고 해. POST /api/users/notifications 엔드포인트를 만들 거야. 기존 auth middleware와 user controller 패턴을 따라가고, 에러 처리 방식도 현재 프로젝트 스타일에 맞춰줘. TypeScript 타입 정의도 빠뜨리지 말아줘.

이렇게 하면 확실히 답변이 달라집니다. AI가 “제가 말로 설명한 프로젝트”가 아니라 실제 코드가 있는 프로젝트를 기준으로 답하거든요. 이 차이는 꽤 큽니다. 특히 리팩토링이나 API 추가처럼 기존 패턴을 잘 따라야 하는 작업에서는 체감이 확 와요.

제가 자주 쓰는 프롬프트 형태는 대충 이런 느낌입니다.

[역할]
너는 20년 경력의 시니어 백엔드 개발자야.
지금부터 내가 제공하는 코드 구조와 스타일을 기준으로만 판단해줘.

[프로젝트 컨텍스트]
[여기에 Repomix로 만든 ai-context.md 내용 붙여넣기]

[요청]
위 프로젝트에서 src/controllers/user.controller.ts 파일을 리팩토링하고 싶어.
기존 asyncHandler 패턴은 유지해줘.
에러 메시지는 지금보다 구체적으로 바꿔줘.
프로젝트의 기존 에러 처리 방식과 네이밍 스타일을 따라줘.

[출력 방식]
전체 파일을 다시 쓰지 말고, 변경 사항만 diff 형식으로 보여줘.
불필요한 설명은 짧게만 붙여줘.

여기서 제가 중요하게 보는 건 두 가지예요. 하나는 AI의 역할을 정해주는 것, 다른 하나는 출력 형식을 미리 못 박는 것입니다. 그냥 “이거 고쳐줘”라고 하면 AI가 친절해지고 싶어서 설명을 잔뜩 붙입니다. 가끔은 원하지도 않은 전체 파일을 다시 써주고요. 고마운데, 토큰은 눈물 나죠.

그래서 저는 가능한 한 “diff만 줘”, “수정된 함수만 줘”, “파일 경로별로 나눠줘”처럼 말합니다. 이게 작은 습관 같지만 누적되면 꽤 큽니다. 특히 하루 종일 LLM 붙잡고 개발하는 날에는 답변 하나하나의 길이가 곧 작업 속도더라고요.

Repomix 설정은 프로젝트마다 조금씩 다르게 둡니다

Repomix는 그냥 실행해도 쓸 만합니다. 그런데 계속 쓰다 보면 결국 설정 파일을 만들게 돼요. 저는 프로젝트 루트에 repomix.config.json을 두는 편입니다. 혼자 쓰는 프로젝트라면 제 취향대로 맞춰두면 되고, 팀 프로젝트라면 이 파일을 공유해두는 게 좋습니다. 팀원들이 같은 기준으로 AI 컨텍스트를 뽑을 수 있거든요.

include와 exclude로 AI가 볼 범위를 딱 잘라줍니다

AI에게 프로젝트 전체를 다 보여주는 게 항상 좋은 건 아니에요. 사실 대부분은 너무 많이 보여줘서 문제가 생깁니다. UI 컴포넌트 리팩토링을 부탁하는데 테스트 파일, 스타일 파일, Storybook 파일까지 다 들어가면 AI가 괜히 산만해져요. 사람도 회의 자료가 너무 많으면 핵심을 놓치잖아요.

프론트엔드 프로젝트에서 컴포넌트와 hook만 보고 싶을 때 저는 이런 식으로 설정합니다.

{
  "include": ["src/components/**/*.tsx", "src/hooks/**/*.ts"],
  "exclude": ["**/*.test.ts", "**/*.spec.ts", "src/styles/**"]
}

이렇게 해두면 질문 범위가 확 줄어듭니다. 제가 실제로 React 프로젝트에서 이렇게 잘라서 써봤는데, 대략 토큰이 3분의 1 정도로 줄었어요. 답변도 더 명확해졌고요. 이상하게 AI는 정보를 많이 주면 더 똑똑해질 것 같지만, 꼭 그렇진 않습니다. 필요한 정보만 줬을 때 오히려 더 깔끔하게 판단하는 경우가 많아요.

    • UI 리팩토링이면 components, hooks 위주로만 포함
    • API 수정이면 routes, controllers, services, types 중심으로 포함
    • 테스트 작성 요청이 아니라면 test, spec 파일은 일단 제외
    • 스타일 수정이 아니라면 styles, css, scss 파일은 과감히 제외
    • 문서 생성 요청이 아니라면 README나 docs도 필요할 때만 포함

저는 이 기준을 꽤 고집하는 편입니다. LLM한테도 적당한 식단 관리가 필요하다고 생각해요. 많이 먹인다고 좋은 답이 나오는 건 아니더라고요.

출력은 Markdown으로 고정해두는 편이 편했습니다

Repomix는 출력 스타일을 고를 수 있는데, 저는 거의 항상 Markdown으로 둡니다. XML도 나쁘진 않은데, ChatGPT나 Claude에게 붙여넣고 대화하기에는 Markdown이 더 자연스럽게 읽히는 느낌이 있었어요. 코드 블록과 파일 경로가 눈에 잘 들어오기도 하고요.

{
  "output": {
    "style": "markdown",
    "filePath": "ai-context.md",
    "removeComments": true,
    "removeEmptyLines": true,
    "topFilesLength": 10
  }
}

여기서 제가 좋아하는 옵션은 removeComments입니다. 처음엔 주석을 제거하는 게 괜찮을까 싶었어요. 주석도 맥락 아닌가 싶잖아요. 그런데 오래된 프로젝트에서는 주석이 오히려 독이 되는 경우가 있습니다. 코드와 주석이 서로 다른 이야기를 하고 있는 경우, 생각보다 흔해요.

예전에 한 번은 “이 함수는 더 이상 사용하지 않음”이라는 주석이 붙어 있었는데, 실제로는 운영 API에서 여전히 호출 중인 함수였어요. AI가 그 주석을 보고 해당 로직을 제거하는 방향으로 제안하더라고요. 그때 살짝 식은땀이 났습니다. 그 뒤로는 질문 목적에 따라 주석을 제거하고 보는 편이에요. 문서화나 주석 개선을 요청할 때가 아니라면, 저는 코드 자체를 더 믿습니다.

상황 removeComments 사용 여부 제 판단 기준
리팩토링 사용하는 편 오래된 주석보다 실제 로직을 기준으로 보는 게 안전함
버그 원인 분석 상황에 따라 다름 주석에 힌트가 있을 수도 있어서 한 번은 포함해봄
문서화 거의 사용하지 않음 기존 주석 스타일을 참고해야 할 때가 많음
테스트 코드 생성 보통 사용 함수 시그니처와 실제 분기만 있어도 충분한 경우가 많음

.repomixignore는 귀찮아도 꼭 만들어둡니다

이건 조금 진지하게 말하고 싶어요. .repomixignore는 귀찮아도 만들어두는 게 좋습니다. 아니, 회사 프로젝트라면 저는 거의 필수라고 봅니다.

Repomix가 .gitignore를 따라주긴 하지만, 그걸로 모든 민감 정보가 막힌다고 믿으면 위험해요. 팀마다 이상한 폴더 하나쯤 있잖아요. 예를 들면 secrets, certs, deploy-key, private-config 같은 것들요. “이건 우리끼리만 쓰는 거니까 괜찮아” 하면서 git에는 안 올리는데 로컬에는 있는 파일들. 그런 게 AI 컨텍스트에 섞이면 꽤 골치 아파집니다.

저는 프로젝트 루트에 이런 식으로 넣어둡니다.

secrets/
certs/
*.pem
*.key
.env
.env.*
config/production.json
config/staging.json

예전에 한 번 API 키가 들어간 설정 조각을 실수로 외부 도구에 붙여넣은 적이 있었어요. 큰 사고로 번지진 않았지만, 그날 이후로 습관이 바뀌었습니다. 키는 바로 폐기하고 재발급했고, 팀 회의 때 “AI에 코드 넣기 전에 민감 정보부터 막자”고 공유했죠. 이런 건 한 번만 겪어도 몸에 남습니다.

특히 아래 파일들은 저는 거의 자동으로 제외합니다.

    • .env, .env.local, .env.production
    • *.pem, *.key, *.crt 같은 인증서 관련 파일
    • production DB 접속 정보가 들어간 config 파일
    • 외부 API token이나 webhook secret이 들어간 JSON 파일
    • 고객사명, 내부 서버 주소, 계정 정보가 박힌 임시 문서

AI 도구를 잘 쓰는 것도 중요하지만, 저는 그보다 먼저 안전하게 쓰는 습관이 더 중요하다고 생각합니다. 개발자는 결국 남의 데이터를 만지는 사람이고, 회사 시스템을 만지는 사람이니까요. 편하자고 쓰는 도구가 사고의 시작이 되면 너무 속상하잖아요.

제가 실제로 자주 쓰는 작업 흐름은 이렇습니다

말로만 하면 좀 뜬구름 같으니, 제가 평소에 어떻게 쓰는지 흐름을 한 번 적어볼게요. 대단한 건 아니고요. 그냥 손에 익은 루틴입니다.

프로젝트 루트 이동
↓
.repommixignore 또는 .repomixignore 확인
↓
질문 범위에 맞게 repomix.config.json 수정
↓
npx repomix 실행
↓
ai-context.md 열어서 민감 정보 섞였는지 한 번 확인
↓
LLM에 컨텍스트 붙여넣기
↓
요청은 짧고 구체적으로 작성
↓
diff 또는 파일 경로 기준으로 결과 받기
↓
로컬에서 직접 테스트

여기서 제일 중요한 단계는 의외로 ai-context.md를 한 번 열어보는 것입니다. 자동화 도구를 써도 마지막 확인은 사람이 해야 해요. 저는 이걸 약간 여행 가기 전 여권 확인하는 느낌으로 봅니다. 분명 챙긴 것 같은데, 그래도 공항 가기 전에 한 번 더 보잖아요. 코드도 똑같습니다.

그리고 AI가 준 코드는 바로 믿지 않습니다. 이건 제 나름의 원칙이에요. AI가 만들어준 diff를 보고, 프로젝트 스타일에 맞는지 확인하고, 테스트 돌리고, 로그까지 봅니다. AI는 좋은 동료처럼 쓸 수 있지만, 최종 책임자는 결국 저니까요.

토큰 아끼려고 하다가 답변 품질까지 좋아진 게 제일 마음에 듭니다

처음에는 단순히 LLM 토큰 절약이 목적이었어요. 비용도 비용이고, 컨텍스트 길이 제한도 신경 쓰였거든요. 그런데 Repomix를 계속 쓰다 보니 오히려 답변 품질이 좋아졌습니다. 제가 장황하게 설명하지 않아도 AI가 실제 파일 구조를 보고 판단하니까요.

특히 효과를 많이 본 작업은 이런 것들이었습니다.

    • 기존 controller 패턴을 유지하면서 새 API 추가하기
    • service layer 분리 기준을 AI와 같이 검토하기
    • TypeScript 타입 누락이나 any 사용 지점 찾기
    • 레거시 코드에서 사용되지 않는 함수 후보 뽑기
    • 테스트 코드 작성 전에 필요한 mocking 범위 정리하기
    • 신규 팀원에게 설명할 프로젝트 구조 문서 초안 만들기

물론 만능은 아닙니다. 프로젝트가 너무 크면 Repomix로 뽑은 파일도 여전히 커요. 그럴 때는 욕심내서 다 넣지 말고, 질문 범위를 잘라야 합니다. “전체 프로젝트를 이해해줘”보다 “결제 모듈 안에서 webhook 처리 흐름만 봐줘”가 훨씬 낫습니다. AI에게도 시야를 좁혀주는 게 필요해요.

저는 요즘 이런 식으로 범위를 나눕니다.

하고 싶은 일 AI에게 넘기는 범위 제가 피하는 방식
새 API 추가 routes, controllers, services, types, middleware 프론트 코드까지 통째로 넣기
컴포넌트 리팩토링 대상 component, 관련 hook, type 전체 src 폴더를 전부 넣기
버그 분석 에러 로그, 호출 흐름, 관련 파일 “뭔가 안 돼요”만 적기
테스트 작성 대상 함수, 기존 테스트 패턴, mocking 대상 구현 코드만 던지고 테스트 스타일은 안 알려주기

이런 분이면 Repomix 한 번 써보셔도 좋습니다

Repomix가 무슨 대단한 마법 도구는 아니에요. 그런데 개발 흐름을 덜 끊기게 만들어주는 도구는 맞습니다. 저는 그런 도구를 좋아합니다. 개발자는 집중력이 제일 비싼 자산이라고 생각하거든요. 한 번 흐름이 깨지면 다시 들어가는 데 시간이 꽤 걸립니다.

특히 이런 분이라면 한 번 써보셔도 좋을 것 같아요.

    • LLM에게 코드 리뷰를 맡겼는데 매번 “컨텍스트가 부족하다”는 답을 듣는 분
    • 프로젝트 구조 설명하느라 질문보다 설명이 더 길어지는 분
    • ChatGPT나 Claude에 코드를 붙여넣다가 토큰 한도 때문에 자주 막히는 분
    • 레거시 프로젝트를 AI와 같이 읽어보고 싶은 분
    • 팀원들과 비슷한 방식으로 AI 컨텍스트를 공유하고 싶은 테크 리드
    • AI 바이브 코딩은 하고 싶은데, 아무 파일이나 통째로 넣는 건 찝찝한 분

솔직히 말하면, 요즘 AI 코딩 도구는 점점 좋아지고 있습니다. 그런데 도구가 좋아질수록 더 중요해지는 게 있어요. 무엇을 얼마나 보여줄지 결정하는 개발자의 감각입니다. AI에게 모든 걸 던지는 게 실력은 아니더라고요. 필요한 맥락을 잘라서 주고, 원하는 출력 형식을 분명히 말하고, 결과를 직접 검증하는 것. 저는 그게 요즘 개발자의 새로운 기본기 중 하나라고 봅니다.

오늘 이야기한 Repomix도 그 기본기를 도와주는 작은 도구입니다. 터미널 열고 npx repomix 한 번 실행해보세요. 아마 처음엔 “음, 그냥 파일 하나 생겼네?” 싶을 수도 있는데, 실제로 LLM에 붙여넣고 코드 수정 요청을 해보면 느낌이 올 겁니다. 아, 내가 그동안 너무 열심히 설명하고 있었구나. 그런 생각이 살짝 들 거예요.

저는 이런 식의 도구들이 참 좋습니다. 요란하진 않은데, 하루 작업을 조금 덜 피곤하게 만들어주거든요. AI와 같이 코딩하는 시대라지만, 결국 편한 리듬을 만드는 건 우리 몫인 것 같습니다. 무리하지 말고, 안전하게, 그리고 조금 더 똑똑하게 써보면 좋겠습니다.

댓글

댓글 쓰기