Local LLM 이용한 Github 코드 리뷰 Actions 구현 및 배포하기 with Github Copilot - 1

코드 개발 및 작성은 아래 링크에서 진행합니다.

GitHub - ray5273/ollama-pr-review-action

 

개발 전 코드리뷰 봇 오픈소스 검토하기

• Github에 올라와 있는 오픈소스가 있다면 활용하면 좋을것 같았습니다.
• 사내 코드에 대한 리뷰라서 외부 API는 사용하면 안되는 이유로 온프레미스 환경을 기반으로 동작해야했습니다.
• 따라서 이를 먼저 확인 해 봤는데, On-premise 서버를 기반으로 한 code-review github action은 보이지 않았습니다.
• (추가) 추가로 github actions에서 ollama로 검색했을때는 아래와 같이 몇개가 나오니 한번 확인해보셔도 좋을 것 같습니다.

 

이전 프로젝트에서는 Cursor AI를 썼었는데 이번에는 현재 유료로 사용하고 있는 Github Copilot 유료버전을 통해서 코드리뷰 봇 action을 만들어보려고 합니다.

인프라 설정

• 우선은 내가 가지고 있는 mac mini를 가지고 실험을 해봐도 좋을것 같아서 이를 통해 실험해보려고 했습니다.
• 또한, 동일한 코드를 해당 인프라에서 돌려 테스트를 해보고 용량이 부족한 경우 다른 인프라를 사용 해 볼예정입니다.

 

코드리뷰에 대한 요구사항

1. 전체 코드와 comment를 읽고 의도를 파악 한 후 전반적인 코드리뷰를 진행합니다.

2. 또한, 로그 작성에 대한 추천을 자연스럽게 하는 것이 주요 목적입니다. (주로 info, debug level의 로그)
우리 부서가 필요한 부분이기도 합니다

 

 

개발과정

1. LLM 모델 선정 

• 내 코드에 대한 코드리뷰를 진행 예정이라 OpenAI의 API등을 사용하면 안됩니다. 따라서 로컬 LLM을 배포해야 합니다.
• 해당 LLM의 API를 활용하여 원하는 코드 리뷰를 진행하려고 합니다.
• 따라서, 코드에 대한 이해가 좋은 LLM, 그리고 영어와 한글을 잘 하는 LLM이어야 합니다.

 

2. 프롬프트 작성

• 프롬프트에 따라서 모델의 성능이 크게 차이가 있을 수 있으므로 코드 리뷰를 위한 적절한 프롬프트가 필요합니다.

 

로컬 LLM 실행 및 API로 노출을 위한 프로그램들

제가 현재 서버로 사용중인 m4 mac mini와 실제로 사용할 linux에서 잘 작동해야하므로 이 두개의 플랫폼을 지원해야합니다.

아래와 같은 여러가지 후보가 있었습니다.

1. llama.cpp
2. GPT4All
3. LocalAI
4. Ollama

그 중에 가장 편해보이는 ollama를 사용하려고 합니다.

ollama/docs/api.md at main · ollama/ollama

위의 Documentation을 통해서 API Endpoint와 Response를 알아 볼 수 있습니다.

 

기본적인 사용방법은 아래와  같은 curl 명령어를 통해서 메세지를 보낼 수 있습니다.

$ curl http://localhost:11434/api/generate -d '{
  "model": "deepseek-r1:8b",
  "prompt": "Why is the sky blue?",
  "stream": false
}'

결과는 아래와 같이 옵니다.

{
    "model":"deepseek-r1:8b",
    "created_at":"2025-02-22T06:01:38.17341Z",
    "response":"\u003cthink\u003e\n\n\u003c/think\u003e\n\nThe phenomenon of a blue sky is due to Rayleigh scattering, which occurs when sunlight passes through the Earth's atmosphere. Shorter wavelengths of light, such as blue and violet, are scattered by oxygen and nitrogen molecules in the atmosphere, resulting in the sky appearing blue to us. This explanation aligns with the theory of classical physics.",
    "done":true,
    "done_reason":"stop",
    "context":[128011,10445,374,279,13180,6437,30,128012,128013,271,128014,271,791,25885,315,264,6437,13180,374,4245,311,13558,64069,72916,11,902,13980,994,40120,16609,1555,279,9420,596,16975,13,10928,261,93959,315,3177,11,1778,439,6437,323,80836,11,527,38067,555,24463,323,47503,35715,304,279,16975,11,13239,304,279,13180,26449,6437,311,603,13,1115,16540,5398,82,449,279,10334,315,29924,22027,13],"total_duration":5014105667,
    "load_duration":30456500,
    "prompt_eval_count":9,
    "prompt_eval_duration":1173000000,
	"eval_count":72,
	"eval_duration":3809000000
}

LLM 모델로 Deepseek을 쓰다보니 CoT 과정까지 response로 포함되어 나오는 모습입니다.

 

ollama의 response 항목은 아래와 같이 설명 가능합니다.

Response	설명
load_duration	model을 loading하는 시간 (nanosecond 단위)
prompt_eval_count	prompt의 토큰 개수
prompt_eval_duration	prompt를 평가하는 시간 (nanosecond 단위)
eval_count	response의 토큰 개수
eval_duration	response를 만들어내는데 걸린 시간 (nanosecond 단위)
context	response의 대화에 쓰인 encoding, 다음 요청에 conventional memory로 쓰일 수 있음.

 

또한, mac mini에 대한 action을 지원하기 위해서는 container가 아닌 python 코드 테스트로 수정을 해야합니다.

아래를 참고해서 작성해보려고 합니다.

AWSBedrock-CodeReview/action.yml at main · eple0329/AWSBedrock-CodeReview

AWSBedrock-CodeReview/action.yml at main · eple0329/AWSBedrock-CodeReview

 

 

리뷰의 예시 (Deepseek-r1:8b)

Okay, so I'm trying to understand how this code works. It seems like it's a Python script that interacts with GitHub and an AI model through an API. Let me break it down step by step.
First, the script has two main functions: request_code_review and post_review_to_github. The request_code_review function is supposed to send some code changes to an AI for review and get back a response. Then, that response is sent back to GitHub as a comment on the pull request.

Looking at the imports, it uses json for handling JSON data and os for interacting with environment variables. That makes sense because the script needs to get configuration details without hardcoding them.

In the request_code_review function, it starts by setting up headers for authentication using a GitHub token. Then, it constructs some prompts: the system prompt includes the response language, and the user prompt is built from custom input plus the changes in a JSON format. It sends this prompt to an API endpoint to get the review.

Wait, how does it handle getting the code changes? It fetches the files changed in the pull request using the GitHub API. For each file, it extracts the filename, patch, and status. Then it converts these into a JSON string for the AI model.

The AI response is then processed, and the actual review text is extracted from the response. This review is then sent back to GitHub as a comment using the post_review_to_github function.

In the main block, the script reads environment variables for API URL, GitHub token, owner, repo, PR number, custom prompt, response language, model, and so on. It calls request_code_review with these variables and then posts the review back to the PR.

I'm a bit confused about how exactly the AI's response is integrated into the comment. Does it just take the text and append it as is? Also, the script uses specific environment variables, which means it needs to have those set before running. That makes it flexible but requires proper setup.

Another thing I noticed is error handling. The script uses raise_for_status in the requests to handle any HTTP errors. That's good practice. However, I'm not sure if all possible errors are handled, like if the AI API returns a non-HTTP error or something unexpected.

I also wonder about the scalability. If someone uses this for large organizations with many pull requests, it might be slow since each PR would need to wait for an external service response. But maybe that's acceptable depending on use cases.

Overall, the script seems functional but could benefit from more logging and perhaps better error messages if things go wrong. It's a good start for automating code reviews with AI.

The provided Python script automates the process of requesting a code review from an AI model and posting the feedback back to GitHub. Here's a step-by-step explanation of how it works:

1. Imports
json: For handling JSON data.
os: For accessing environment variables.
2. Functions
request_code_review
Purpose: Sends code changes to an AI model for review and retrieves the feedback.
Steps:
Sets up authentication headers using a GitHub token.
Constructs system and user prompts based on configuration parameters.
Fetches changed files from the PR using the GitHub API.
Converts file changes into a JSON string for the AI model.
Sends the prompt to the AI API, processes the response, and extracts the review text.
post_review_to_github
Purpose: Posts the AI's review comment back to the corresponding GitHub pull request.
Steps:
Constructs the URL for adding a comment.
Sends the comment using the GitHub API, including the review text.
3. Main Execution
Retrieves configuration parameters from environment variables.
Invokes request_code_review with these parameters.
Posts the AI's feedback as a comment on the specified PR.
4. Usage
Dependencies: The script requires an AI API endpoint, a GitHub token with the necessary permissions (read and write for pull requests), and an API key for the AI service provider.
Setup: Configure environment variables with your API details and GitHub credentials.
Run: Execute the script to automate sending code reviews through AI and posting them back to GitHub.
5. Example Workflow
User initiates a PR on GitHub.
Script triggers (configured via CI/CD or manual run) when PR is created or updated.
Code changes are fetched from the PR.
AI model provides feedback, which is then posted as a comment by this script.
This automation streamlines the code review process, leveraging AI for efficiency and consistency, while integrating seamlessly with GitHub's workflow.

 

간단하게 만들어서 위와 같이 결과를 확인 해 봤습니다.

리뷰는 안하고 다른 답변을 준다는 점이 좀 이상해서 모델 용량이 작은게 원인으로 보여 높은 용량의 LLM을 테스트 해보려고합니다.

 

우선은 제대로 모델 선정 및 테스트부터 해보겠습니다.

 

모델 선정 및 테스트

Chatbot Arena (formerly LMSYS): Free AI Chat to Compare & Test Best AI Chatbots

위 사이트에서 매일의 순위를 확인할 수 있습니다.

현재의 순위는 위와 같아서 위의 코드 중에 LocalLLM으로 사용 가능한 LLM을 사용해보도록 하려고합니다.

 

1. Deepseek-r1:70B

https://github.com/ray5273/ollama-pr-review-action/pull/3#pullrequestreview-2652408556

Removed unnecessary prompt by ray5273 · Pull Request #3 · ray5273/ollama-pr-review-action

Alright, let me try to break down how I arrived at the review for this code change. So, first off, I saw that there's a GitHub Actions workflow file being modified. The main changes are in the job configuration.
The runner was switched from macOS to elice. Hmm, I remember that GitHub offers different runners, and sometimes people switch for better performance or specific environments. But I'm not sure why they picked 'elice' here. Maybe it's a typo? Because I don't recall 'elice' being a standard runner. Maybe they meant 'ubuntu-latest'? That would make more sense.

Next up, the CUSTOM_PROMPT was emptied out. Originally, it was set to ask for responses in Korean. Removing that could lead to English responses by default, which might not be desired if the team prefers Korean. So I thought suggesting keeping some prompt, maybe making it optional with a default, would help maintain consistency.

Then there's the model change from 'qwen2.5-coder:7b' to 'deepseek-r1:70b'. That seems like a significant jump in model size and potentially performance. But larger models can be slower or cost more if this is a paid service. I wondered if they considered the trade-offs here, maybe suggesting a way to configure it dynamically so they're not stuck with one model all the time.

I also noticed that some default values were removed, like the custom prompt and model. That could introduce variability in how the action behaves each time it runs. So I thought about making these configurable through workflow inputs or secrets for more flexibility and security.

Overall, while the changes aim to optimize the setup, there are potential issues with consistency and performance. My main points were about correcting the runner, keeping necessary defaults, managing model configurations wisely, and ensuring maintainability by documenting the workflow better.

이 코드 변경에 대한 분석입니다:

의도와 논리 흐름 평가:
이 PR은 GitHub Actions 워크플로우 파일을 수정하여 다음과 같은変更을 진행합니다:
macOS runner에서 elice runner로 변경
CUSTOM_PROMPT 값을 비움
모델을 qwen2.5-coder:7b에서 deepseek-r1:70b로 변경
이 변경은 주로 워크플로우의 실행 환경과 AI 모델 관련 설정을 수정하는 것에 초점을 맞추었습니다.

개선 필요사항 및潜在問題:
runner 변경 (macOS -> elice):

elice는 GitHub Actions의 공식 runner이 아닙니다. 이는 타사 runner 또는 사용자 정의 runner일 수 있습니다.
만약 elice가 특정한 환경을 위해 구성된 커스텀 runner라면, 그 용도를 명확히 문서화하고 유지보수할 수 있어야 합니다.
또한, 다른.runner와 비교하여 성능이나 비용적인 이점이 있는지 검증해야 합니다.
CUSTOM_PROMPT 값 초기화:

기존에 '답변을 한글로 작성해주세요.'라는 값을 가지고 있던 CUSTOM_PROMPT가 빈 문자열로 변경되었습니다.
이는 AI가 응답할 때 한국어를 사용하도록 유도하는 문구를 제거함으로써 응답 언어의 일관성을 유지하지 못할 수 있습니다.
이 변경이 특정한 이유에 의해 진행되었다면, 그 의도를 명확히 commented로 남기는 것이 좋을 것입니다.
모델 변경 (qwen2.5-coder:7b -> deepseek-r1:70b):

모델의 크기가 7B에서 70B로 Dramatically 증가하였습니다.
더 큰 모델은 더 나은 성능을 제공할 수 있지만, 동시에 더 많은 컴퓨팅 자원을 소모하고,inferencing 시간도 길어질 수 있습니다.
특히 GitHub Actions와 같은 CI/CD 환경에서 Such a large model may lead to longer execution times and potential timeouts.
추가 제안 및 리팩터링 아이디어:
runner 설정에 대한 검토:

elice runner의 유용성과 안정성을 평가하고, 공식 GitHub runner 중 하나를 사용하는 것을 고려합니다.
예를 들어, ubuntu-latest 또는 windows-latest와 같은 표준 runner를 사용하면 유지보수性とcompatibility가 향상될 수 있습니다.
CUSTOM_PROMPT에 대한 처리:

빈 문자열로 설정하는 대신, Default Prompt를 한국어로 유지하는 것을 고려합니다.
또한, CUSTOM_PROMPT의 값을 동적으로 지정할 수 있도록 workflow inputs을 통해 유연性を 제공할 수 있습니다.
모델 관리:

모델을_hard-coded_하는 대신, 환경 변수或者workflow configuration를 통해 동적으로指定할 수 있도록 합니다.
이는 추후 다른 모델로 쉽게 전환할 수 있도록 гибкость을 제공합니다.
성능 및 리소스 管理:

Larger models may not be necessary for all use cases. Evaluate whether a smaller model could suffice for your needs.
Additionally, consider implementing timeouts or caching mechanisms to optimize the workflow execution.
코드 유지보수性と可读性:
CUSTOM_PROMPT와 모델 변경에 대한 주석을 추가하여 의도를्पष하게 설명합니다.
특히, MODEL의 경우 크기가 Dramatically 증가하였으므로 이로 인해 발생할 수 있는 성능影響을 명확히 문서화해야 합니다.
보안性:
새로운 runner와 모델을 도입할 때, 보안상에 문제가 없는지 확인합니다.
특히, 커스텀 runner의 경우, 실행 중인 환경에서-sensitive 데이터가 노출되지 않도록 주의해야 합니다.
综上所述, 이 변경은 워크플로우의 성능과 환경을 최적화하는 것을 目표로 했지만, 一些潜在的な 問題を 가지고 있습니다. 特别是 Runner와 모델の変更이 전체 시스템에 미치는 影響을仔细 검토해야 합니다. 또한, 코드의可读性と 유지보수性을 높이기 위해適当한 주석과 문서화가 필요합니다.

한글로 잘 해주기는 하는데 일부 중국어가 출력되는게 있네요.

역시 영어 + 중국어가 잘 되는 deepseek이기에 그런것 같습니다.

 

또한, r1 모델이라서 추론에 대한 결과까지 출력되어 이를 위한 처리가 별도로 필요해서 좀 귀찮을것 같습니다.

 

2. llama 3.3 70B

https://github.com/ray5273/ollama-pr-review-action/pull/3#pullrequestreview-2652411311

Removed unnecessary prompt by ray5273 · Pull Request #3 · ray5273/ollama-pr-review-action

 

 

3. codestral 22B

Codestral | Mistral AI

Codestral | Mistral AI

https://github.com/ray5273/ollama-pr-review-action/pull/3#pullrequestreview-2652409016

Removed unnecessary prompt by ray5273 · Pull Request #3 · ray5273/ollama-pr-review-action

 

 

4. qwen-2.5-coder:32B

알리바바의 모델입니다.

https://github.com/ray5273/ollama-pr-review-action/pull/3#pullrequestreview-2652409312

Removed unnecessary prompt by ray5273 · Pull Request #3 · ray5273/ollama-pr-review-action

개인적으로 느끼기에는 품질이 가장 훌륭했습니다.

아래는 몇가지 이슈 해결에 대한 고민이었습니다.

 

이슈 1. 작은 모델 사용시 (<10B) 리뷰 답변의 언어를 korean으로 했었는데 프롬프트만으로는 한국어로 대답하지 않는다는 점.

local LLM 자체가 많은 언어를 지원하기가 쉽지가 않을 것 같다는 생각이 들었습니다.

특히나 용량이 작은 모델이라면 말이지요.

따라서, 코드 리뷰에 대한 결과를 번역 API를 통해서 재 번역해서 해결해야할 것 같다는 생각이 들었습니다.

 

해결 1. LLM 모델을 두개를 사용한다 - 코드용, 번역용

API를 두번 요청해보면 좋을것 같네요.

1. 코드리뷰용 LLM

2. 1의 결과를 다음 번역 LLM으로 넘겨서 이를 번역하게함. 

이런 방식으로요

 

쉽게 이를 적용했더니 아래와 같이 되었습니다.

뭔가 포맷이 안맞아서 이상하게 느껴지기는 합니다.

다만, 각각의 역할을 할 수는 있는것 같아 보입니다.

 

따라서, 리뷰에 대해서 파이프라인을 잘 구성을 하면 어떻게든 사용할 수 있다는 생각은 듭니다.

아래는 결과의 예시인지 품질 자체는 마음에 들지는 않아서 모델이 잘 못 번역을 한건지 아니면 제가 인풋을 잘못준건지 한번 더 확인을 해보려고 합니다.

야놀자의 EEVE 모델도 있어서 이를 테스트 해봤는데 맥미니 m4 기본에서는 충분한 속도를 내지 못하네요.

yanolja (Yanolja)

bnksys/yanolja-eeve-korean-instruct-10.8b

bnksys/yanolja-eeve-korean-instruct-10.8b

맥 미니 m4에서는 모델의 용량이 좀 커서 빠르게 처리가 불가능하고 잘 안되었습니다.

그래서 이 모델은 AWS의 GPU 모델에서 옮겨서 추후에 테스트 해보려고합니다.

또한, 큰 LLM 모델만으로도 테스트 해보려고합니다.

 

해결 2. 큰 LLM 모델을 사용해본다.

큰 LLM을 쓰면 Korean으로 바꿔달라고 하니까 잘 바꿔주는것을 볼 수 있었습니다.

역시나 LLM은 모델 크기가 일정 사이즈 이상되면 비약적인 성능 상승을 보여주는것 같습니다.

 

10B 미만의 모델을 사용하다가 deepseek-r1:70B 로 교체하니까 CoT만 영어로 생각하고 답변을 바로 한글로 해주네요 ㅎㅎ 훌륭합니다.

다른 모델들도 22B ~ 70B쯤되면 다 한글로 잘 적용해주는것으로 보입니다.

다만, 너무 간단한 코드/PR에 대한 테스트라서 기존에 회사에서 올렸던 PR에 대한 테스트를 몇가지 진행해보려고합니다.

 

 

실제 프로덕션 코드에 대한 리뷰 테스트

새로운 API를 추가하는 기능에 대한 PR 결과를 확인해보려고합니다.

그리고 저의 요구사항인 logger.info()와 logger.debug()를 추가해 달라는 custom prompt를 추가했습니다.

 

프로덕션 코드 테스트 결과

회사 내부의 코드라서 결과를 첨부할 수는 없어서 결론만 정리하자면 아래와 같습니다.

해보니 코드가 너무 긴 경우에 input을 짤라먹는것 같은 문제와 출력의 길이가 제한적인 문제가 있는것 같았습니다.

출력이 대부분 code 설명만 하다가 끝나버립니다.

또한, 한글로 대답하지도 않구요.

 

따라서, 현재의 문제를 정의해보면 아래와 같습니다.

1. 내가 원하는 프롬프트 적용이 잘 안된다 (logger를 추가할만한 위치 추천을 안함)
2. 언어 변경 요청에 대한 한글 답변이 잘 안된다.
3. input/output 사이즈가 길때의 조정이 필요하다.

 

프롬프트 문제, 컨텍스트 윈도우 문제가 있는것 같아서 해당 문제는 다음 포스트에서 문제 해결 시도를 해보려고합니다.

 

 

비용 측정

큰 모델을 사용하려면 결국은 외부 클라우드의 GPU를 사용해야할 것 같습니다.

좀 괜찮은 모델을 쓰려면 GPU vRAM 용량이 20~40GB 정도는 필요해서 집에있는 mac mini나 GPU로는 힘들어서요.

위의 조건에 만족하는 EC2 instance는 아래 두 제품이였습니다.

g6e.xlarge

g6e.xlarge는 시간당 1.8달러, spot은 0.58달러입니다. -> 시간당 계산시 1달에 1300달러

g6e.2xlarge는 시간당 2.2달러, spot 인스턴스는 1.1달러입니다.-> 시간당 계산시 1달에 1600달러

활성화 되는 시간만 할시에는 계산이 또 필요합니다.

 

bedrock이나 sagemaker를 쓰는 방법도 있는데 확인 결과 아주 많은 LLM을 현재 지원하지는 않았고 또한 그냥 GPU instance를 쓰는것 보다 비용이 추가로 더 들것 같아서 배제했습니다.

 

인프라 최적화는 다음 포스트에서 진행하려고 합니다.

 

참고 : LLM 용량별 GPU 필요 메모리 계산법

Calculating GPU memory for serving LLMs | Substratus.AI

모델명	필요 GPU 메모리
llama3.3 70B, 4bit quantization (codellama도 동일)	42 GB
qwen2.5-coder 32B, 4bit quantization	19.2 GB
deepseek-coder-v2, 16B 4bit quantization	8.6 GB
codestral 22B, 4bit quantization	12 GB
yi-coder 9B, 4bit quantization	4.9 GB

=> NVIDIA A40정도면 전부 돌릴 수 있을것으로 생각됩니다.

Can You Run It? LLM version - a Hugging Face Space by Vokturz

Can You Run It? LLM version - a Hugging Face Space by Vokturz

엘리스 무료 크레딧으로 프로젝트 결과를 테스트 해보고 있습니다.

 

 

참고 : GPU 사용량을 실시간으로 확인하는 방법

asitop을 다운받고 아래와 같이 명령어 실행

brew install asitop
sudo asitop

 

참고 자료

시간은 금이다: LLM을 이용한 AI 코드 리뷰 도입기

LLM을 활용한 GitHub PR 코드 리뷰 자동화

LLM을 활용한 GitHub PR 코드 리뷰 자동화

AWS Bedrock으로 PR 리뷰 봇 만들어보기- 최소기능 구성 (1)

AWS Bedrock으로 PR 리뷰 봇 만들어보기- 최소기능 구성 (1)

LLM을 활용한 GitHub PR 코드 리뷰 봇 만들기

LLM을 활용한 GitHub PR 코드 리뷰 봇 만들기

Langchain + Local LLMs for code review | by smrati katiyar | Medium

Langchain + Local LLMs for code review