저도 비슷한 구조로 하고 있는데 false positive 줄이려면 "실제 버그인지 의견인지" 구분하도록 명확히 지시하는 게 핵심이더라고요. 그리고 context 길이는 아무래도 modified 파일만 던지는 게 제일 무난합니다. 전체 파일 넘기면 토큰 낭비만 심하고요.
이미지생성
코드 리뷰 자동화 프롬프트 좋은 사례 있으신가요?
요즘 AI를 코드 리뷰에 활용하려고 하는데 프롬프트를 어떻게 짜야 할지 고민이 많습니다. 회사에서 PR이 너무 많아서 일단 1차 검토는 LLM으로 자동화하고 싶거든요. 근데 일반적인 "코드 리뷰해줘" 이런 식으로만 던지면 너무 얕은 리뷰만 나오더라고요.
지금 저는 architecture, performance, security, readability 이 4가지 관점에서 검토하도록 구조화된 프롬프트를 쓰고 있는데, 실제 여러분들이 운영 중인 프롬프트는 어떻게 되어 있나 궁금합니다. 혹시 체크리스트 형식으로 점수를 매기도록 한다거나, 아니면 각 섹션별로 구체적인 지적 사항만 뽑아내도록 한다거나 하는 팁이 있을까요?
특히 제가 놓치고 있는 부분이 뭔지 모르겠어요. 거짓 양성이 많이 나온다거나, 혹은 중요한 부분을 놓친다거나 하는 문제가 있으신 분들이 계신지 궁금합니다. 그리고 프롬프트 자체보다는 context 길이가 문제라면 파일을 어떻게 선택해서 던지는지도 알고 싶네요.
마지막으로 하나 더 여쭤볼게 있는데, 코드 패턴이나 회사 컨벤션을 학습시키는 부분은 어떻게 처리하시나요? 시스템 프롬프트에 다 때려박으면 토큰이 너무 많이 나가는 것 같은데, 실무에서는 이걸 어떻게 최적화하고 계신지 궁금합니다. 혹시 fine-tuning까지 고려해본 분이 계신가요?
지금 저는 architecture, performance, security, readability 이 4가지 관점에서 검토하도록 구조화된 프롬프트를 쓰고 있는데, 실제 여러분들이 운영 중인 프롬프트는 어떻게 되어 있나 궁금합니다. 혹시 체크리스트 형식으로 점수를 매기도록 한다거나, 아니면 각 섹션별로 구체적인 지적 사항만 뽑아내도록 한다거나 하는 팁이 있을까요?
특히 제가 놓치고 있는 부분이 뭔지 모르겠어요. 거짓 양성이 많이 나온다거나, 혹은 중요한 부분을 놓친다거나 하는 문제가 있으신 분들이 계신지 궁금합니다. 그리고 프롬프트 자체보다는 context 길이가 문제라면 파일을 어떻게 선택해서 던지는지도 알고 싶네요.
마지막으로 하나 더 여쭤볼게 있는데, 코드 패턴이나 회사 컨벤션을 학습시키는 부분은 어떻게 처리하시나요? 시스템 프롬프트에 다 때려박으면 토큰이 너무 많이 나가는 것 같은데, 실무에서는 이걸 어떻게 최적화하고 계신지 궁금합니다. 혹시 fine-tuning까지 고려해본 분이 계신가요?
추천 14 비추천 0
- 이전글코드 리뷰할 때 쓸만한 프롬프트 있으신가요?26.03.29
- 다음글프롬프트 쓰다 보니까 결국 이 부분이 제일 중요하더라요26.03.21
댓글
20
댓글목록
저도 비슷한 문제 겪었는데 결국 context 관리가 핵심인 거 같아요. 전체 PR을 다 던지기보다는 변경된 파일만 필터링해서 보내는 게 낫더라고요. 그리고 아키텍처/성능/보안 관점은 좋은데 여기에 "기존 코드스타일과의 일관성" 항목을 추가했더니 오탐이 줄었어요. 저희는 심각도 레벨 3단계(Critical/Warning/Info)로 분류하도록 지정했는데 이게 실무에서 훨씬 유용하더라고요. 거짓 양성은 결국 프롬프트보다는 모델 온도 조절이나 few-shot 예시 추가로 많이 개선됐습니다.
저도 비슷한 경험이 있는데 context 길이가 정말 문제더라고요. 전체 파일을 던지면 중요한 부분을 놓치고 엉뚱한 곳에서 지적하거든요. 저는 변경된 함수와 그 함수가 호출하는 부분만 명시적으로 표시해서 던지니까 거짓 양성이 많이 줄었어요. 4가지 관점도 좋지만 팀의 코딩 컨벤션을 프롬프트에 먼저 제시하는 게 도움이 된다고 생각합니다.
저는 거짓 양성 줄이려고 "이 부분이 문제라면 구체적인 예시까지 제시해줘" 이렇게 추가했는데 효과 있더라고요. Context 길이는 정말 답답한데 최근 수정 파일 + 관련된 함수 정의부만 따로 추출해서 던지는 방식을 써봤어요. 완벽하진 않지만 꽤 개선됐습니다.
오 저도 같은 문제 겪고 있었어요 ㅠㅠ
저도 비슷한 고민 중인데 context 문제 정말 심하더라고요. 저는 변경된 파일만 골라서 던지고, 각 섹션별로 "심각도 높음", "개선권고" 이렇게 분류하도록 했어요. 거짓 양성은 줄었는데 놓치는 게 여전히 있네요 ㅠㅠ
저도 비슷한 고민이었는데 context 길이 제한 때문에 수정된 파일만 따로 추출해서 넣으니까 훨씬 정확해지더라고요. 전체 파일 던지면 노이즈가 심하네요.
저도 같은 고민을 했는데 결국 코드 라인 수 제한을 먼저 두었어요. 파일이 크면 변경된 부분만 추출해서 넘기니까 거짓 양성이 확 줄더라고요. 그리고 architecture 체크할 때는 함수 시그니처와 클래스 구조만 별도로 보내는 게 효과적이었습니다.
거짓 양성 진짜 문제네요 ㅠㅠ
저도 비슷한 고민을 했는데 context 길이 문제는 정말 심각하더라고요. 저는 변경된 파일만 골라서 던지고, 각 섹션별로 "구체적인 버그나 성능 이슈만 지적하되, 의견성 지적은 제외해줘" 이렇게 명시했더니 거짓 양성이 많이 줄었습니다.
점수 매기는 건 오히려 안 좋더라고요. 수치로 나오면 사람들이 그걸 절대적으로 받아들이는 경향이 있어서요. 차라리 심각도별로 분류(Critical/Warning/Info) 하는 게 훨씬 실용적이었어요.
점수 매기는 건 오히려 안 좋더라고요. 수치로 나오면 사람들이 그걸 절대적으로 받아들이는 경향이 있어서요. 차라리 심각도별로 분류(Critical/Warning/Info) 하는 게 훨씬 실용적이었어요.
저도 그 문제 겪었는데 context 필터링이 정말 중요하더라고요.
저도 같은 문제로 고민 중이었어요 ㅠㅠ
저도 같은 고민 중이었어요. 저는 거짓 양성 줄이려고 "실제 버그 가능성 있는 것만 언급하고, 스타일 지적은 제외"라고 명시했거든요. 그래도 자잘한 경고들이 많이 나오더라고요.
Context 길이 문제는 정말 크더라고요. 저는 변경된 파일만 따로 추출해서 던지는데, 그 파일의 관련 함수 3개 정도까지만 포함시키도록 제한했습니다. 처음엔 전체 파일 던졌다가 나중엔 무관한 부분까지 지적하는 문제가 생겼거든요.
혹시 점수 체크리스트 방식 쓰시는 분 있으신가요? 저도 궁금한데 수치화가 의미 있을지는 모르겠어요.
Context 길이 문제는 정말 크더라고요. 저는 변경된 파일만 따로 추출해서 던지는데, 그 파일의 관련 함수 3개 정도까지만 포함시키도록 제한했습니다. 처음엔 전체 파일 던졌다가 나중엔 무관한 부분까지 지적하는 문제가 생겼거든요.
혹시 점수 체크리스트 방식 쓰시는 분 있으신가요? 저도 궁금한데 수치화가 의미 있을지는 모르겠어요.
저도 비슷한 고민을 했는데 결국 모델 자체의 한계를 깨달았어요. 거짓 양성은 프롬프트 개선보다는 threshold 설정으로 줄이는 게 낫더라고요. Context 문제는 관련 파일만 골라서 던지되, git diff 형식으로 변경분만 추출해서 주는 게 훨씬 효율적이었습니다.
저도 지금 같은 고민 중이네요 ㅠㅠ
저도 비슷한 문제 겪고 있었는데 context 길이 줄이려고 먼저 린터 통과한 파일만 던지기 시작했어요. 그 다음에 architecture 섹션에서 "변경된 부분이 기존 패턴과 일치하는가"만 집중하니까 거짓 양성이 줄더라고요. 혹시 언어별로 프롬프트를 다르게 가져가세요?
저도 비슷한 고민했는데 결국 프롬프트 자체보다 diff만 넘기고 변경 사항 근처 코드도 포함시키니까 훨씬 나아지더라고요. 전체 파일 던지면 token 낭비되고 집중력도 떨어지는 것 같아요.
거짓 양성 줄이려면 팀의 코드스타일 가이드를 프롬프트에 박아두는 게 도움됩니다. 그러고 나서 실제로 놓친 버그가 뭐였는지 피드백 루프를 만들면 점점 좋아져요.
마지막으로 저는 security 섹션에서 놓친 게 많았는데, 특정 라이브러리나 패턴에 대한 이슈를 따로 언급하도록 수정했더니 훨씬 낫던 거 같아요.
거짓 양성 줄이려면 팀의 코드스타일 가이드를 프롬프트에 박아두는 게 도움됩니다. 그러고 나서 실제로 놓친 버그가 뭐였는지 피드백 루프를 만들면 점점 좋아져요.
마지막으로 저는 security 섹션에서 놓친 게 많았는데, 특정 라이브러리나 패턴에 대한 이슈를 따로 언급하도록 수정했더니 훨씬 낫던 거 같아요.
저도 비슷한 문제로 고민하다가 프롬프트에 실제 코드 스타일 가이드와 팀의 아키텍처 패턴을 컨텍스트로 넣었더니 거짓 양성이 확 줄었어요. 그리고 섹션별로 "개선 필수", "권장", "참고" 이렇게 3단계로 구분해서 나오도록 했는데 실무에서 훨씬 쓸 만하더라고요. 혹시 이렇게 시도해본 분 있나요?
저도 같은 고민을 했는데 결국 프롬프트보다는 context 관리가 핵심이더라고요. 전체 PR을 던지지 말고 변경된 함수 단위로 끊어서 던지면 거짓 양성이 확 줄어듭니다. 그리고 style guide나 회사 컨벤션을 시스템 프롬프트에 명확히 박아두는 게 정말 효과 좋았어요.
저도 비슷한 고민을 했는데 architecture, performance, security, readability 4가지는 정말 좋은 프레임워크네요. 저는 여기에 "왜 이렇게 짰는지" 의도를 먼저 물어보는 프롬프트를 추가했거든요. 그러니까 실수로 플래그 올렸던 거 줄어들더라고요.
context 길이 문제는 저도 있었는데 main 함수 근처 코드만 샘플링해서 던지니까 훨씬 정확해졌습니다.
context 길이 문제는 저도 있었는데 main 함수 근처 코드만 샘플링해서 던지니까 훨씬 정확해졌습니다.
댓글을 작성하려면 로그인이 필요합니다.