저도 비슷하게 하는데 추가로 "잠재적 버그 가능성"을 체크리스트에 넣으니까 훨씬 좋더라고요. 아키텍처는 다이어그램 설명 먼저 주고 각 컴포넌트 간 의존성 검토 요청하면 괜찮습니다.
글쓰기
LLM한테 코드 리뷰 받을 때 쓰는 프롬프트 공유
최근에 발견한 건데 코드 리뷰 프롬프트를 구체적으로 작성하면 정말 실용적인 피드백을 받을 수 있더라고요. 그냥 "이 코드 리뷰해줘"라고 하면 뻔한 답변만 나오는데, 역할을 먼저 정의하고 체크리스트를 준 다음 코드를 붙여넣으면 훨씬 나아요.
저는 이렇게 사용하고 있습니다. "너는 5년차 백엔드 엔지니어야. 다음 코드를 보안, 성능, 가독성 관점에서만 리뷰해줄 때 각 항목마다 구체적인 개선 사항을 제시해. 실제 제시할 수 있는 예시 코드도 포함해줘." 이 정도면 팀 리뷰 받기 전에 미리 점검할 때 꽤 유용해요.
혹시 더 좋은 방식 쓰시는 분 계신가요? 특히 복잡한 아키텍처 검토할 때는 어떻게 하시는지 궁금하네요.
저는 이렇게 사용하고 있습니다. "너는 5년차 백엔드 엔지니어야. 다음 코드를 보안, 성능, 가독성 관점에서만 리뷰해줄 때 각 항목마다 구체적인 개선 사항을 제시해. 실제 제시할 수 있는 예시 코드도 포함해줘." 이 정도면 팀 리뷰 받기 전에 미리 점검할 때 꽤 유용해요.
혹시 더 좋은 방식 쓰시는 분 계신가요? 특히 복잡한 아키텍처 검토할 때는 어떻게 하시는지 궁금하네요.
추천 14 비추천 0
- 이전글챗봇한테 물어보는 방식 좀 바꿨더니 답변이 달라지더라고요26.04.22
- 다음글코드 리뷰할 때 쓰는 프롬프트 공유해요26.04.20
댓글
7
댓글목록
저도 비슷하게 쓰고 있는데 추가로 "잠재적인 버그 가능성"을 따로 물어보는 게 효과적이더라고요. 아키텍처 검토할 때는 역할 정의 후에 "확장성과 유지보수성" 체크리스트를 미리 제시하고 각 항목마다 위험도까지 표시해달라고 하면 훨씬 실질적인 답변이 나와요. 예시 코드까지 포함하라는 거 정말 좋은 팁입니다.
저도 이 방식 써봤는데 정말 차이가 크더라고요. 특히 "어떤 부분이 문제인지", "왜 문제인지" 이 두 줄만 추가해도 훨씬 실질적인 답변이 나와요. 복잡한 아키텍처는 다이어그램 설명을 먼저 요청한 다음에 리뷰 포인트를 정리해서 넘기면 괜찮았습니다.
저도 비슷하게 하는데 체크리스트 앞에 "다음 형식으로 답변해줘"라고 JSON 형태 예시를 먼저 보여주니까 더 구조화된 답변이 나오더라고요. 아키텍처는 다이어그램 설명 추가하고 각 컴포넌트별로 따로 리뷰받으면 좋았어요.
역할 정의하니까 정말 달라지네요 ㅋㅋ
오 저것도 좋네요 한번 써봐야겠다
오 이 방식 진짜 효과 있더라고요 ㅋㅋ
댓글을 작성하려면 로그인이 필요합니다.