아래는 **대규모 프로젝트(예: 1만 줄 이상 코드, 매우 많은 커밋 등)**에서도 위 GitFolio 코드를 완벽하게 동작시키기 위해 어떤 부분을 어떻게 수정하면 좋을지에 대한 구체적인 방안입니다. 요점은 API 호출·LLM 토큰 제한을 고려하면서, Incremental(증분) 처리, 필터링 등을 통해 안정적으로 “전체 레포지토리”를 분석하도록 만드는 것입니다.

1. 서버(Express) 측 변경: 대규모 데이터 처리 전략

1.1 커밋·코드 청크(Chunk) 단위 처리

문제:

• 현재 코드에서는 fetchCommits, fetchUserContributions 등의 함수가 ?per_page=10로 제한된 호출을 하고 있습니다. 작은 규모라면 괜찮지만, 만 줄 이상의 프로젝트에서 수백~수천 건의 커밋이 있을 수 있음.

해결 방안:

1. Pagination(페이지네이션) 사용:

   • GitHub API에서는 ?page=1&per_page=100까지 가능하므로, 원하는 만큼 반복 호출하여 “전체 커밋”을 모을 수 있음.

   • 예:

     async function fetchAllCommits(owner, repo) {
       let allCommits = [];
       let page = 1;
       const perPage = 100; // 최대 100
       while (true) {
         const response = await axios.get(
           `https://api.github.com/repos/${owner}/${repo}/commits?page=${page}&per_page=${perPage}`
         );
         const commits = response.data;
         if (commits.length === 0) break;
         allCommits = allCommits.concat(commits);
         page++;
       }
       return allCommits;
     }
     
     

   • 이를 통해 만 건 이상의 커밋도 전부 수집 가능(단, API Rate Limit 고려).

2. 커밋 제한:
   • 대규모 저장소라면 정말 전부 불러오면 시간이 오래 걸림.
   • “최근 500개 커밋”같이 상한선을 두어도 실무상 충분할 수 있음. (필요에 따라 설정)

1.2 증분(Incremental) 분석

문제:

• 매번 “전체 레포지토리”를 새로 분석하면 API 호출도 많고 LLM 토큰 비용도 큼.해결 방안:

1. DB 혹은 캐싱을 사용
   • 이전에 분석한 커밋/파일은 “분석 결과”를 DB에 저장, 다음 호출 시 새 커밋 혹은 바뀐 파일만 분석해 누적.
2. GitHub 웹훅(Webhook) / 스케줄러
   • 특정 시간이 되면 or Push 이벤트마다 “새 커밋만” 분석.

1.3 코드 파일 분석 시 필터링

문제:

• 만 줄 이상의 코드, 혹은 수십 MB짜리 파일이 있을 수 있음. LLM에 전부 넣으면 토큰 초과 + 성능 저하.해결 방안:

1. 확장자 필터: .json, .png, .md, .min.js 등은 무시
2. 폴더 필터: node_modules/, build/, dist/ 등 빌드 산출물 폴더 제외
3. Partial Summarization: 파일 내용이 만 줄 이상이면, 문맥이 중요한 앞부분/핵심 함수 부분만 추려서 LLM에 보내고, 나머지는 요약으로 대체.