요즘 AI를 코드 리뷰에 활용하려고 하는데 프롬프트를 어떻게 짜야 할지 고민이 많습니다. 회사에서 PR이 너무 많아서 일단 1차 검토는 LLM으로 자동화하고 싶거든요. 근데 일반적인 "코드 리뷰해줘" 이런 식으로만 던지면 너무 얕은 리뷰만 나오더라고요.
지금 저는 architecture, performance, security, readability 이 4가지 관점에서 검토하도록 구조화된 프롬프트를 쓰고 있는데, 실제 여러분들이 운영 중인 프롬프트는 어떻게 되어 있나 궁금합니다. 혹시 체크리스트 형식으로 점수를 매기도록 한다거나, 아니면 각 섹션별로 구체적인 지적 사항만 뽑아내도록 한다거나 하는 팁이 있을까요?
특히 제가 놓치고 있는 부분이 뭔지 모르겠어요. 거짓 양성이 많이 나온다거나, 혹은 중요한 부분을 놓친다거나 하는 문제가 있으신 분들이 계신지 궁금합니다. 그리고 프롬프트 자체보다는 context 길이가 문제라면 파일을 어떻게 선택해서 던지는지도 알고 싶네요.
마지막으로 하나 더 여쭤볼게 있는데, 코드 패턴이나 회사 컨벤션을 학습시키는 부분은 어떻게 처리하시나요? 시스템 프롬프트에 다 때려박으면 토큰이 너무 많이 나가는 것 같은데, 실무에서는 이걸 어떻게 최적화하고 계신지 궁금합니다. 혹시 fine-tuning까지 고려해본 분이 계신가요?
저도 비슷한 구조로 하고 있는데 false positive 줄이려면 "실제 버그인지 의견인지" 구분하도록 명확히 지시하는 게 핵심이더라고요. 그리고 context 길이는 아무래도 modified 파일만 던지는 게 제일 무난합니다. 전체 파일 넘기면 토큰 낭비만 심하고요.
현실주의자
저도 비슷한 문제 겪었는데 결국 context 관리가 핵심인 거 같아요. 전체 PR을 다 던지기보다는 변경된 파일만 필터링해서 보내는 게 낫더라고요. 그리고 아키텍처/성능/보안 관점은 좋은데 여기에 "기존 코드스타일과의 일관성" 항목을 추가했더니 오탐이 줄었어요. 저희는 심각도 레벨 3단계(Critical/Warning/Info)로 분류하도록 지정했는데 이게 실무에서 훨씬 유용하더라고요. 거짓 양성은 결국 프롬프트보다는 모델 온도 조절이나 few-shot 예시 추가로 많이 개선됐습니다.
딥러닝장인
저도 비슷한 경험이 있는데 context 길이가 정말 문제더라고요. 전체 파일을 던지면 중요한 부분을 놓치고 엉뚱한 곳에서 지적하거든요. 저는 변경된 함수와 그 함수가 호출하는 부분만 명시적으로 표시해서 던지니까 거짓 양성이 많이 줄었어요. 4가지 관점도 좋지만 팀의 코딩 컨벤션을 프롬프트에 먼저 제시하는 게 도움이 된다고 생각합니다.
현실주의자
저는 거짓 양성 줄이려고 "이 부분이 문제라면 구체적인 예시까지 제시해줘" 이렇게 추가했는데 효과 있더라고요. Context 길이는 정말 답답한데 최근 수정 파일 + 관련된 함수 정의부만 따로 추출해서 던지는 방식을 써봤어요. 완벽하진 않지만 꽤 개선됐습니다.
AI새싹
오 저도 같은 문제 겪고 있었어요 ㅠㅠ
궁금하면
저도 비슷한 고민 중인데 context 문제 정말 심하더라고요. 저는 변경된 파일만 골라서 던지고, 각 섹션별로 "심각도 높음", "개선권고" 이렇게 분류하도록 했어요. 거짓 양성은 줄었는데 놓치는 게 여전히 있네요 ㅠㅠ
딥러닝장인
저도 비슷한 고민이었는데 context 길이 제한 때문에 수정된 파일만 따로 추출해서 넣으니까 훨씬 정확해지더라고요. 전체 파일 던지면 노이즈가 심하네요.