저도 비슷한 구조로 하고 있는데 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.24
- 다음글클로드한테 물어볼 때 이 프롬프트 써보세요26.03.23
댓글
13
댓글목록
저도 비슷한 문제 겪었는데 결국 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개 정도까지만 포함시키도록 제한했습니다. 처음엔 전체 파일 던졌다가 나중엔 무관한 부분까지 지적하는 문제가 생겼거든요.
혹시 점수 체크리스트 방식 쓰시는 분 있으신가요? 저도 궁금한데 수치화가 의미 있을지는 모르겠어요.
댓글을 작성하려면 로그인이 필요합니다.