아마 이 편이 마지막 편이 될 것이다.
프롬포트 셋팅에 따라서 어떻게 달라지는지를 한 번 테스트 해봤다. 저번에 올린 글에서 사용한 프롬포트는 아래와 같다.
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
OPENAI_API_KEY: ${{ secrets.OPENAPI_SECRET_KEY }}
LANGUAGE: Korean
OPENAI_API_ENDPOINT: https://api.openai.com/v1
MODEL: gpt-4o
PROMPT: 코드 위주로 리뷰해줘
top_p: 1
temperature: 0.7
max_tokens: 1500
MAX_PATCH_LENGTH: 5000
IGNORE_PATTERNS: /node_modules/**/*,*.md,*.log,*.txt
위 프롬포트로 GPT가 남긴 리뷰를 보려면 아래 링크로 가면 볼 수 있다.
어제 맘에 들지 않았던 부분을 수정하기 위해 프롬포트를 조금 수정해 봤다.
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
OPENAI_API_KEY: ${{ secrets.OPENAPI_SECRET_KEY }}
LANGUAGE: Korean
OPENAI_API_ENDPOINT: https://api.openai.com/v1
MODEL: gpt-4o
PROMPT: 코드 자체에 집중해서 리뷰해 주세요. 실행 맥락이나 추측은 피하고, 현재 제공된 코드 범위 내에서만 피드백을 부탁드립니다. 불필요한 리뷰는 생략해 주세요.
top_p: 1
temperature: 0.7
max_tokens: 1500
MAX_PATCH_LENGTH: 5000
IGNORE_PATTERNS: /node_modules/**/*,*.md,*.log,*.txt
위처럼 수정 후에 날린 PR을 살펴보자.
음.... 정말 잘 모르겠는데,
이 리뷰가 맞는걸까?
나는 정말 필요 없는 리뷰가 많은 것 같다. 특히 1,4,5가 그렇다.
그래서 다시 프롬포트를 수정해봤다.
PROMPT: |
코드의 기능적 동작과 설계 품질에 초점을 맞춰 리뷰해 주세요. 다음과 같은 요소에 집중해 주세요
- 코드의 로직이 명확하고 오류가 없는지
- 예외 처리 및 경계값 테스트가 적절한지
- 테스트가 실제 동작을 충분히 검증하는지
- 도메인 설계나 책임 분리가 잘 되었는지
다음 요소는 언급하지 않아도 됩니다
- 코드 스타일이나 포맷팅 (예시 파일 끝의 newline, 줄 간격 등)
- 메서드 이름이나 주석 등의 표현 방식 (스타일 가이드는 팀마다 다를 수 있으므로)
- 불필요한 import 여부
실행 맥락에 대한 추측 없이, 현재 제공된 코드 내에서만 분석해 주세요.
와...
더 맘에 안들어졌다. 1,3,4는 진짜 필요 없는 리뷰라고 생각했다.
그래서 다시 다음과 같이 프롬포트를 수정했다.
PROMPT:
리뷰는 반드시 **현재 제공된 코드 범위 내에서만** 해 주세요.
- 구현되지 않은 동작이나 추측성 설명(예 = 이 인터페이스는 ~일 것 같다, ~해야 할 것 같다, 구체적인 로직 파악은 어렵다 등)은 하지 말아 주세요.
- 코드에 **직접 명시된 기능, 로직, 설계만** 리뷰해 주세요.
- 테스트 코드가 없으면 "없다"고만 언급하고, 어떻게 구현되어야 한다는 **추측성 피드백은 생략해 주세요.**
중점 리뷰 대상
- 코드가 의미상, 설계상 문제는 없는지
- 명확하고 일관된 책임을 갖고 있는지
- 의도된 동작을 코드 상에서 정확하게 수행하는지
다음은 리뷰하지 않아도 됩니다
- 코드 스타일, 네이밍, 주석 등 팀마다 다른 요소
- 파일 끝 newline 여부 등 포맷팅
그랬더니 코드량은 확 줄고, 애가 좀 멍청해지는 것 같다.
리뷰가 아닌 그냥 코드만 설명하는 느낌이 강해졌다.
이럴 때는 프롬포트를 아예 엎어야 하는 것 같다.
그래서 완전히 새로 짜봤다.
PROMPT:
시니어 개발자처럼, 코드의 설계 품질과 기능적 완성도에 집중해서 리뷰해 주세요.
다만, **리뷰는 반드시 현재 제공된 코드 범위 내에서만** 수행해 주세요.
코드 외적인 맥락, 실행 예상 시나리오, 구현되지 않은 내용에 대한 추측은 포함하지 말아 주세요.
특히 다음을 중점적으로 리뷰해 주세요:
- 코드가 명확하고, 읽기 쉬우며, 유지보수하기 좋은 구조인지
- 코드가 실제로 의도된 기능을 정확하게 수행하는지 (기능적 오류 여부 포함)
- 책임 분리가 잘 되어 있고, 각 구성요소의 역할이 명확한지
- 테스트가 존재한다면, 의미 있는 케이스를 다루고 있는지 (예외, 경계값 포함)
다음 항목은 리뷰하지 않아도 됩니다:
- 코드 스타일, 포맷팅, newline 여부
- 네이밍, 주석 스타일, 메서드 이름 언어 등 가독성에 큰 영향을 미치지 않는 표현 방식
- 테스트나 구현이 존재하지 않는 경우, "존재하지 않는다"고만 언급하고, 그 외의 **추측성 조언은 생략**해 주세요
예시는 불필요하며, 리뷰는 간결하고 핵심적으로 작성해 주세요.
리뷰가 훨씬 좋아졌다.
"시니어 개발자처럼" 이라는 말이 많이 좋아진 것 같다.
읽으면서도 충분히 납득이 되는 리뷰였다.
그래서 마지막으로, 욕심을 좀 더 내봤다.
PROMPT:
시니어 개발자처럼, 코드의 설계 품질과 기능적 완성도에 집중해서 리뷰해 주세요
특히 다음과 같은 소프트웨어 설계 원칙을 충실히 따르고 있는지를 평가해 주세요
- 도메인 주도 설계(DDD) 원칙 = 애그리거트, 엔티티, 값 객체, 도메인 서비스 등 개념이 올바르게 적용되어 있는지
- 클린코드 원칙 = 단일 책임, 명확한 의도 표현, 중복 제거, 적절한 추상화 등이 잘 지켜졌는지
- 레이어드 아키텍처 = 각 계층(Presentation, Application, Domain, Infrastructure)의 역할이 잘 분리되어 있는지
- 객체지향 프로그래밍(OOP) = 캡슐화, 다형성, 책임 중심 설계가 반영되어 있는지
단, 리뷰는 반드시 **현재 제공된 코드 범위 내에서만** 해 주세요.
**실행 맥락에 대한 추측**, 혹은 **구현되지 않은 부분에 대한 상상**은 포함하지 말아 주세요.
중점 리뷰 항목
- 코드가 명확하고, 읽기 쉬우며, 유지보수하기 좋은 구조인지
- 실제로 의도된 기능을 정확하게 수행하는지 (기능적 오류 여부 포함)
- 책임과 관심사의 분리가 명확한지
- 설계 원칙(DDD, OOP, 레이어드 아키텍처 등)이 코드 안에서 자연스럽게 드러나는지
- 테스트가 있다면, 의미 있는 경계값과 예외 케이스를 다루고 있는지
다음 항목은 리뷰하지 않아도 됩니다
- 코드 스타일, 포맷팅, newline 여부
- 메서드 이름, 주석, 네이밍 같은 표현 방식
- 존재하지 않는 구현/테스트에 대한 추측적 조언
리뷰는 간결하고 핵심 위주로, 코드 품질 향상에 실질적인 도움이 되도록 작성해 주세요.
음.......
롤백 엔딩!! 😅