AI Algorithm Mentor(알고리즘 풀이 자동 리뷰 GitHub Action)은, 알고리즘 풀이 코드를 GitHub에 푸시하면 문제 내용 + 내 코드를 함께 분석해서 “왜 맞는지/어디가 느린지/개선점은 뭔지”를 코치처럼 커밋 코멘트로 남겨주는 자동 리뷰 도구입니다. 알고리즘/코테 공부에서 가장 큰 병목은 보통 이 3가지입니다.
- 정답은 맞는데 더 좋은 풀이가 있는지 모름
- 시간/공간 복잡도(빅오)·엣지 케이스가 불안함
- 혼자 공부하면 “리뷰/피드백”이 쌓이지 않음
AI Algorithm Mentor는 이런 상황에서 “매 커밋마다 자동 회고/피드백 로그를 남기기”에 초점이 있습니다.
동작 방식(핵심 아이디어를 흐름으로 이해하기)
전체 파이프라인은 아래 4단계로 보면 가장 이해가 빠릅니다.
- 풀이 파일 ‘첫 줄 주석’에 문제 URL 작성
- push 이벤트 발생 → GitHub Actions 실행
- 문제 URL 감지 → 온라인 저지 페이지를 크롤링(제목/설명/입출력/예제 등 수집)
- LLM이 문제+코드 분석 → 결과를 “커밋 코멘트”로 자동 게시
즉, 문제 설명을 사람이 복붙할 필요 없이, “URL만 정확히 달면” 문제 정보 수집부터 리뷰 게시까지 자동으로 굴러갑니다.
주요 기능을 “실무적으로” 풀어보기
지능형 코드 분석(리뷰에서 보통 다루는 포인트)
이 Action은 단순 스타일 검사기가 아니라, 다음 관점의 피드백을 목표로 합니다.
- 문제 요구사항/제약 자동 파악
- 시간/공간 복잡도 분석 및 최적화 제안
- 가독성/컨벤션 개선 제안
- CrewAI 기반 “리뷰 에이전트” 구조
예를 들면 이런 류의 코멘트가 자연스럽게 나오는 형태를 기대할 수 있습니다.
- “이중 루프라 O(N²)인데, 해시맵 쓰면 O(N) 가능”
- “입력 범위가 커서 Python은 sys.stdin.readline 권장”
- “정렬 기준이 애매한데 comparator/키 함수로 명시하면 안전”
- “엣지 케이스: 빈 배열/중복/overflow 가능성 점검”
Online Judge 자동 감지 & 크롤링
파일 첫 줄의 URL로 플랫폼을 판별하고, 문제 페이지에서 필요한 정보를 수집합니다.
여러 파일 동시 처리(병렬)
한 번의 푸시에 여러 풀이 파일이 올라가도 비동기 병렬 처리로 리뷰를 돌릴 수 있게 설계되어 있습니다.
멀티 LLM 지원(프로바이더/모델 선택)
LiteLLM 기반으로 여러 제공자를 붙일 수 있게 되어 있고(예: OpenAI/Google(Gemini)/Anthropic(Claude)), 워크플로에서 LLM_PROVIDER, MODEL_NAME로 선택합니다. 리뷰 언어도 REVIEW_LANGUAGE로 지정 가능합니다.
설치/사용 방법
준비물: API 키 1개(선택한 프로바이더)
문서에 나온 키 예시는 다음과 같습니다.
- OpenAI →
OPENAI_API_KEY - Google AI →
GEMINI_API_KEY - Anthropic →
ANTHROPIC_API_KEY
GitHub Secrets 등록(필수)
GitHub Repository → Settings → Secrets and variables → Actions 에 등록합니다.
예
GEMINI_API_KEY = ...
(또는 선택한 제공자 키)
Workflow 예시(.github/workflows/ai-review.yml)
README에 제시된 형태(핵심 파라미터 포함) 예시는 아래 흐름입니다.
name: AI Algorithm Mentor
on:
push:
branches: [ main, master ]
jobs:
ai-review:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: choam2426/AI-Algorithm-Mentor@v5
with:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
LLM_PROVIDER: google # openai, google, anthropic
MODEL_NAME: gemini-3-pro-preview # 선택
GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
REVIEW_LANGUAGE: korean # korean, english, etc..포인트는 3가지입니다.
contents: write권한이 있어야 커밋 코멘트 게시가 자연스럽습니다.GITHUB_TOKEN은 GitHub Actions 기본 제공 토큰을 사용합니다.- 프로바이더에 맞는 API 키만 넣으면 됩니다.
“첫 줄 주석 URL” 규칙(가장 중요)
이 규칙이 깨지면 크롤링/플랫폼 감지가 실패할 수 있습니다. “첫 줄”이 핵심입니다.
예시
백준(BOJ)
# https://www.acmicpc.net/problem/1000
a, b = map(int, input().split())
print(a + b)LeetCode
// https://leetcode.com/problems/two-sum/
var twoSum = function(nums, target) {
const map = new Map();
for (let i = 0; i < nums.length; i++) {
const complement = target - nums[i];
if (map.has(complement)) return [map.get(complement), i];
map.set(nums[i], i);
}
};프로그래머스
// https://school.programmers.co.kr/learn/courses/30/lessons/12345
class Solution {
public int[] solution(int n, int[] arr) {
// 풀이 코드
}
}설정 옵션(운영에서 자주 만지는 것만 콕 집기)
README 기준으로 핵심 옵션은 아래 3개가 “운영 체감”이 큽니다.
LLM_PROVIDER:openai | google | anthropicMODEL_NAME: 예)gpt-5.1,gemini-3-pro-preview,claude-sonnet-4-5REVIEW_LANGUAGE: 예)korean,english
그리고 프로바이더에 맞는 API 키(예: GEMINI_API_KEY)를 함께 넣습니다.
내부 구조(왜 이런 기능이 가능한가)
문서에 나온 아키텍처 개념을 “역할 중심”으로 풀면 다음과 같습니다.
- GitHub에서 변경 파일 수집 → URL 파싱 & 플랫폼 감지
- 플랫폼별 스크래퍼로 문제 정보 수집(BOJ/LeetCode/프로그래머스)
- CrewAI 리뷰 에이전트가 LLM 호출(LiteLLM로 프로바이더 교체 가능)
- 결과를 GitHub 커밋 코멘트로 게시
도입 전에 반드시 점검해야 할 것들
이 유형의 자동화는 “편의성”만 보면 위험합니다.
핵심은 데이터 흐름(코드/문제/메타데이터) + 비밀정보(키) + 실행환경(runner) 3요소를 통제하는 겁니다.
시크릿(API 키) 관리 체크포인트
점검 포인트
- API 키는 반드시 GitHub Secrets에만 저장 (레포/코드에 하드코딩 금지)
- 키 권한/스코프 최소화(가능하면 “프로젝트 전용 키”)
- 키 로테이션(주기적 교체)
- GitHub Actions 로그에 키/응답이 노출되지 않도록 마스킹/출력 통제
- (특히 디버그 모드 사용 시 주의)
“코드가 외부 LLM으로 나간다”는 전제 점검
이 Action은 문제 정보 + 코드를 LLM에 보내 리뷰를 받는 구조입니다. (LLM 분석 단계가 핵심)
따라서 다음 리스크를 정책으로 정리해두는 게 안전합니다.
점검 포인트
- 사내/고객 코드가 섞인 레포에서는 사용 금지(또는 강한 통제)
- 알고리즘 풀이 전용 레포로 분리(권장)
- 사내 정책상 외부 전송이 금지된 데이터(고객정보/영업비밀/취약점 PoC 등) 포함 여부 점검
- 필요 시 “자체 호스팅 가능한 LLM/프록시” 또는 “허용된 엔드포인트”만 사용(조직 정책에 맞춤)
실행 환경(GitHub-hosted vs Self-hosted runner) 통제
점검 포인트
- 조직 네트워크/내부망 접근이 필요한 경우엔 Self-hosted runner 사용을 검토
- Self-hosted runner는 반대로 “침해 시 내부망 피벗” 위험이 커지므로,
- 러너 전용 격리망/전용 VM
- 아웃바운드 허용 목적지 제한(LLM API, GitHub API 정도)
- 패치/EDR/무결성 모니터링
같은 통제가 필요합니다.
GitHub Token 권한 최소화(중요)
점검 포인트
- Workflow의
permissions를 최소로(현재 예시는contents: write) - “코멘트 게시”에 필요한 권한 외에는 제거
- PR에 외부 기여자가 있는 오픈소스 형태면, 시크릿이 노출될 수 있는 트리거(
pull_request_target등) 사용 여부를 특히 조심
활용 사례(운영 관점)
개인 알고리즘 학습 루틴 자동화
“하루 1문제 커밋” → 커밋마다 피드백 축적 → 나중에 내가 자주 실수하는 패턴을 회고하기 좋습니다.
스터디/팀 단위 “리뷰 보조”
사람이 꼭 봐야 하는 논점(아이디어/증명/엣지)은 사람이 보고,
기본적인 복잡도/가독성/입출력 최적화 같은 건 AI가 초안을 줘서 리뷰 비용을 줄일 수 있습니다.
조직 도입 시 권장 운영 모델(안전 버전)
권장 패턴
- “알고리즘 풀이 전용 공개/사내 레포” 분리
- 허용된 LLM 프로바이더만 사용
- 러너 격리 + 권한 최소화
- 로그/코멘트 정책(민감정보 금지) 합의
도입 체크리스트
아래만 지켜도 “사고 확률”이 확 줄어듭니다.
- API 키는 GitHub Secrets로만, 주기적으로 교체
- 알고리즘 풀이 전용 레포로 분리(사내 코드 섞지 않기)
- Workflow 권한 최소화(
permissions) - 러너 선택(Hosted vs Self-hosted) 시 내부망 피벗 리스크까지 고려
- “첫 줄 URL 주석” 규칙을 팀 컨벤션으로 고정
댓글