ollama로 코드 리뷰 자동화하기

코드 리뷰는 개발 프로세스에서 매우 중요한 단계입니다. 하지만 바쁜 일정 속에서 일일이 코드 변경 사항을 검토하는 것은 쉽지 않습니다. 이를 자동화하기 위해 ollama와 최신 LLM 모델을 활용하여 코드 리뷰 프로세스를 자동화하는 방법을 소개합니다.

LLM code review

1. ollama 설치

https://ollama.com/download

2. Model 받기 - 리뷰를 위한 LLM 모델

ollama pull mistral:7b

3. 코드리뷰 shell script 작성

조건: git 초기화가 필요함
git diff기반으로 변경사항에 대해서 코드리뷰를 진행함

vi pre-commit.sh

#!/bin/bash

model="mistral:7b"
#model="llama3.2-kor:latest"
#model="llama3.3:70b"

export LANG=ko_KR.UTF-8
export LC_ALL=ko_KR.UTF-8

# 프로젝트의 루트 디렉토리로 이동
cd "$(git rev-parse --show-toplevel)"

# 수정된 파일들을 찾음
files=$(git diff --name-only --diff-filter=ACM | grep -E ".py$|.js$|.tsx$|.yml$|.java$|.sh$")

system_prompt="당신은 친절하고 유익한 코드 리뷰어입니다. 먼저 칭찬할 부분을 찾은 후, 다음 세 가지 주요 측면에 집중하세요: **1. 변경 사항 및 동작 여부 확인 ✅** **2. 코드 품질(버그, 가독성, 유지보수성) 🧐** **3. 성능 및 최적화 🚀**. 코드 품질/가독성에 대해서는 복잡한 메서드에만 문서화 주석을 제안하세요. 개선이 필요한 부분이 있다면 '**🎯 개선 제안**' 섹션을 만들어 구체적인 코드 예시와 함께 제시하세요. 리뷰를 칭찬으로 마무리하고, 머지 전에 수정이 필요한 경우 수정이 필요한 파일 위치를 명확히 표시하고 추가 커밋을 요청하세요. 이모지를 많이 사용하고, 한국어로 캐주얼하고 친근하고 간략한 어조로 응답하세요."

for file in $files
do
    prompt="$file 파일에 해당하는 개발언어 코드정책을 고려하여, 변경사항을 자세히 검토하여 리뷰하세요. "

    # 파일의 전체 내용을 가져옴
    #full_content=$(cat "$file")
    full_content=""

    # 변경된 내용만 가져옴
    changed_content=$(git diff "$file" | grep '^[+-]' | grep -v '^[-+][-+][-+]' ) # | sed 's/^[+-]//')

    if [ -n "$changed_content" ]; then
        # API에 보낼 JSON 페이로드 생성
        json_payload=$(jq -n \
            --arg full_content "$full_content" \
            --arg changed_content "$changed_content" \
            --arg system_prompt "$system_prompt" \
            --arg prompt "$prompt" \
            --arg model "$model" \
            '{ "model": $model, "messages": [ {"role": "system", "content": $system_prompt}, {"role": "user", "content": ($prompt + "\n\n변경된 내용:\n" + $changed_content + "\n\n전체 파일 내용:\n" + $full_content)} ] }')

        echo "$file content length: $(echo "$json_payload" | wc -c)"
        if ! response=$(curl -s -w "\n%{http_code}" http://localhost:11434/api/chat \
            -d "$json_payload")
        then
            echo "에러: API 요청 실패"
                        echo $response
            exit 1
        fi

        # HTTP 상태 코드와 응답 본문 분리
        http_code=$(echo "$response" | tail -n1)
        body=$(echo "$response" | sed '$d')

        if [ "$http_code" -ne 200 ]; then
            echo "에러: API가 상태 코드 $http_code를 반환했습니다"
            echo "$body"
            exit 1
        fi

        # JSON 응답에서 리뷰 내용 추출
        #review_content=$(echo "$body" | tr -d '[:cntrl:]' | jq -r '.message.content | @text' \
        review_content=$(echo "$body" | tr -d '[:cntrl:]' | jq -r '.message.content | @json' | sed 's/^"\(.*\)"$/\1/g' | tr -d '\\' \
            | sed 's/^$/++++/g' | sed 's/\n\n/++++/g' | tr -d '\n' | sed 's/++++/\n/g' | sed 's/'"'"'/"/g' ) 

        echo "==========================================================="
        echo "  $file  <---  \"$model\"의 리뷰"
        echo "==========================================================="
        echo "$review_content\n\n"

    else
        echo "에러: $file 파일의 내용이 비어있습니다"
        exit 1
    fi
done

exit 0

작성된 스크립트를 git 초기화된 디렉토리에서 실행

sh pre-commit.sh

아래는 LLM의 리뷰 내용

decorator.py content length:     1385
===========================================================
  decorator.py  <---  "mistral:7b"의 리뷰
===========================================================
🌟 Wow, 많이 바꾸셨네요! 변경사항에는 대부분 적합하다고 생각합니다. 40글자를 추가해 더 깔끔하게 보이신 것 같습니다!
  🧐 하지만, 코드 품질 관점에서는 변경된 부분을 포함한 메서드 내의 모든 문장에 대해서 문서화 주석이 필요합니다.
  🎯 개선 제안: `@decorator` 기능에 대한 간단한 설명을 추가하면 좋을 것 같습니다. 예를 들어, "Decorator for logging function calls"로 시작해서, 각 함수의 역할과 사용법에 대해 알리는 식으로 추가하면 좋을 것 같습니다.
  🚀 Performance-wise, 이 변경은 성능에 큰 영향을 미치지 않을 것으로 예측됩니다.

  이 코드는 현재 OK입니다! Merge it is whenever you"re ready, but if you need to make changes based on my suggestions, please create additional commits. 고맙습니다! 🤗


prediction.py content length:     2751
===========================================================
  prediction.py  <---  "mistral:7b"의 리뷰
===========================================================
🎉 머리가 굴리고, 이해하기 어려운 부분은 적당히 줄임aya! 📝
  1. **변경 사항 및 동작 여부** 확인: 변경된 코드는 꽤 많이 수정되었습니다. 새로운 변수 `self.ml`와 `self.label_encoder`를 추가하고, 함수 내의 변수명을 일관성 있게 수정하였으며, 문제 없이 동작합니다. 👍
  2. **코드 품질(버그, 가독성, 유지보수성)** 확인: 복잡한 함수에만 주석을 추가하는 습관은 좋습니다. 변수명과 함수명이 의미를 분명히 드러내고, 일반적으로 코드는 깔끔합니다.
  3. **성능 및 최적화** 확인: 이해하기 어려운 부분은 없어 보이지만, 파일 전체의 성능을 평가할 수 있는 방법이 없습니다.

  🎯 **개선 제안**: `final_decoded`에 대한 주석을 추가하여 함수의 목적과 처리 방식에 대해 설명할 수 있으므로, 코드의 가독성을 높이고 유지 보수성을 끌어올려 보실 것 같습니다.

  문제없이 동작하며, 코드의 품질은 굉장히 좋아요! 변경사항이 필요 없는 상태입니다. 머지 후에 추가 커밋을 요청합니다~🌺


run_model.py content length:     1389
===========================================================
  run_model.py  <---  "mistral:7b"의 리뷰
===========================================================
🌟 멋진 변경 사항을 보았어요! 기존에는 `1.45`, `1.5`, `1.55`, `1.6` 값으로 Outlier 검출을 했지만, 이제 `1.4`로 줄였습니다.

  🧐 코드 품질에 관심을 갖겠습니다! 가독성과 유지보수성을 위해, 메서드가 복잡하면 문서화 주석(docsstring)을 추가하는 것이 좋습니다. (documentation string)
  그러나 여기선 Outliers 메서드에 대한 설명만 필요합니다.

  🎯 개선 제안: 함수가 어떤 일을 하는지, 매개변수에 대해 설명이 없어서 불편함이 있습니다. Outliers 함수의 docstring를 작성하여 개선해보세요!
  예:
  ```python
  def Outliers(threshold):
      """
      This function detects and removes outliers based on the provided threshold value.
      :param threshold: The value to determine whether a data point is an outlier or not.
      :return: An updated array without outliers.
      """
  ``` 🚀 성능에 대해선 당분간 문제가 없어보이네요! 성능 최적화는 필요하지 않습니다. 머지 전에 Outlier 함수의 docstring을 작성해주시면 감사하겠습니다!
  코드 리뷰를 마치며, 수정이 필요한 부분이 없어서 이곳은 머지할 준비가 되었어요!