최근 학교에서 졸업생 선배님과 함께하는 멘토링 시간이 있었습니다. 현업에서 활약하고 계신 선배님의 경험담을 들으며 가장 인상 깊었던 점은, "요즘 실무에서는 반복적이고 단순한 작업은 과감하게 AI를 사용한 워크플로우를 사용해서 해결한다."는 것이었습니다.
단순히 "좋은 이야기였다"로 끝내고 싶지 않았습니다. 선배님의 조언을 내 프로젝트인 'MOZU'에 당장 적용해보고 싶다는 욕심이 생겼습니다.
"단순한 버그 수정이나 스타일 변경 같은 이슈 처리를 자동화할 수는 없을까?"
이 질문에서 시작해, GitHub Actions와 AI(Gemini)를 엮어 "이슈가 등록되면 AI가 코드를 분석해 스스로 해결하고 PR까지 날리는 봇"을 만들어보게 되었습니다. 멘토링에서 얻은 인사이트를 기술로 구현해낸 과정을 공유합니다.
1. 목표 아키텍처
단순히 코드를 짜달라는 게 아니라, 문맥을 파악하는 에이전트를 만들고 싶었습니다.
- Trigger: GitHub Issue가 생성되고
🤖 ai-fix라벨이 붙음. - Analyze: 프로젝트 전체 파일 구조를 AI에게 보여주고 "이 문제를 해결하려면 어떤 파일을 봐야 해?"라고 물어봄.
- Coding: AI가 지목한 파일의 내용을 실제로 읽어서 전달하고 수정을 요청.
- PR: 수정된 코드를 바탕으로 브랜치를 따고 Pull Request 생성.
2. 기술 스택 선정
- CI/CD: GitHub Actions
- Brain: Google Gemini 2.5 Flash (속도가 빠르고 무료 티어 한도가 넉넉함)
- Runtime: Node.js
- Project Env: Yarn Berry (Monorepo)
3. 핵심 구현 내용
3-1. 2단계 추론
처음에는 무턱대고 모든 코드를 다 넣으려 했지만, 토큰 비용과 정확도 문제가 있었습니다. 그래서 전략을 바꿨습니다.
- Step 1: 파일 탐색 -> glob으로 파일 리스트만 추출해서 Gemini에게 "관련 파일 경로"를 JSON으로 리턴받음.
- Step 2: 코드 수정 -> 리턴받은 경로의 파일 내용만 읽어서 프롬프트에 주입.
이 방식을 쓰니 AI가 엉뚱한 파일을 건드리는 할루시네이션이 확 줄었습니다.
3-2. GitHub Actions 워크플로우
이슈에 🤖 ai-fix 라벨이 붙을 때만 동작하도록 설정했습니다.
on:
issues:
types: [labeled]
jobs:
solve-issue:
if: github.event.label.name == '🤖 ai-fix'
# ... (생략)4. 트러블 슈팅
구현 과정은 순탄치 않았습니다. 특히 Monorepo 환경이 발목을 잡았습니다.
문제 1: GitHub Actions Runner는 빈 환경이다
로컬에서는 잘 돌던 스크립트가 Actions에서는 Cannot find module '@google/generative-ai' 에러를 발생시켰습니다.
👉 원인: Runner에는 내가 로컬에 설치한 패키지가 없기 때문.
문제 2: Yarn Berry + Monorepo 환경의 제약
npm install을 하려니 프로젝트 루트의 package.json에 있는 workspace: 프로토콜 때문에 에러가 났고, yarn install을 하려니 시간이 너무 오래 걸리고 PnP 설정이 복잡했습니다.
해결책: "독립 실행 환경 구성"
프로젝트의 의존성과 완전히 분리된 독립적인 환경을 만들어서 봇을 실행시켰습니다.
- bot-deps라는 임시 폴더 생성.
- 그 안에서
npm init -y로 깨끗한 환경 생성. - 봇 구동에 필요한 라이브러리만
npm install. NODE_PATH환경 변수로 스크립트가 임시 폴더의 모듈을 참조하게 설정.
# 워크플로우 핵심 부분
run: |
mkdir -p bot-deps
cd bot-deps
npm init -y
npm install @google/generative-ai simple-git glob
cd ..
export NODE_PATH=$(pwd)/bot-deps/node_modules
node .scripts/solve_issue.js이 방법으로 Monorepo 설정이나 패키지 매니저 종류와 상관없이 무조건 동작하는 환경을 구축했습니다.
문제 3: 모델의 존재 유무 (404 & 429)
처음에 gemini-2.5-pro-latest를 썼더니 404 에러가, gemini-2.5-pro를 호출했더니 429(요청 초과) 에러가 났습니다.
👉 해결: 가장 안정적이고 속도가 빠른 gemini-2.5-flash로 모델을 변경하여 해결했습니다.
코딩 능력도 준수하고 무료 사용량도 넉넉합니다.
5. 최종 결과
이제 이슈 템플릿에 기존에 문제를 겪었던 어드민 웹의 헤더 반응형을 만들어보겠습니다.
-
⚠️ 이슈 템플릿에 따라서 이슈를 작성합니다.
-
🤖 Gemini가 이슈를 분석합니다.
-
📂 프로젝트를 뒤져서 Header.tsx와 스타일링 코드를 찾아냅니다.
-
📝 코드를 수정합니다.
-
🚀 ai-fix/issue-123 브랜치를 만들고 PR을 날립니다.
-
🏷️ PR에도
🤖 ai-fix라벨을 예쁘게 붙여줍니다.
6. 마치며
이번 프로젝트를 통해 "AI를 내 워크플로우에 어떻게 녹여낼 것인가"에 대해 깊이 고민해볼 수 있었습니다. 특히 LLM을 단순 챗봇이 아니라 파일 시스템을 제어하고 Git을 다루는 에이전트로 활용했을 때의 생산성은 놀라웠습니다. (Claude sonnet을 사용하고 싶었지만.. 학생인지라 돈이 없었네요..)
앞으로는 AI가 수정한 코드에 대해 자동으로 테스트 코드를 돌리고(Test Driven), 통과할 때만 PR을 생성하도록 고도화해볼 생각입니다.
