Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

LLM으로 생성한 코드 작성하기

LLM은 유용한 도구이지만, 오용하기 쉬운 도구이기도 합니다. 주요 위험은 감당하기 어려운 분량과 이해 부족입니다. PR을 작성할 때에는 반대편에 여러분의 변경 사항을 리뷰하고 이해해야 하는 사람이 있다는 점, 그리고 프로젝트의 다른 사람들이 앞으로 수년 동안 여러분의 코드를 읽어야 한다는 점을 명심하십시오. 변경 사항을 작고, 목적이 분명하며, 품질 높게 만들어 저희를 도와주십시오.

다음 인용구를 명심하십시오:

프로그램은 사람이 읽을 수 있도록 작성되어야 하며, 기계가 실행하는 것은 부차적인 일일 뿐입니다. — Harold Abelson, Gerald Jay Sussman, Structure and Interpretation of Computer Programs

규칙

코드를 작성하기 전에

무엇보다 먼저, 여러분의 PR을 자원하여 리뷰해 줄 리뷰어를 찾으십시오. 리뷰어를 어디서 찾아야 할지 모르겠다면, Zulip의 #llm-mentoring에서 문의하십시오. 첫 메시지에는 다음 내용을 담아야 합니다:

  • 여러분에게 적합한 이슈를 찾을 수 있도록, 여러분의 관련 경험
  • 작업하고 싶은 문제(또는 문제의 종류)
  • (선택 사항) 지금까지 생각해 둔 해결 방안
  • (선택 사항) 해결 방안을 어떻게 테스트할 계획인지

멘토는 여러분을 돕기 위해 있습니다. 멘토와 일찍 이야기하면 헛수고를 피하는 데 도움이 됩니다.

작업하는 동안

문서 주석, // SAFETY 주석, 진단 메시지 문구, 건전성(soundness)에 중요한 코드는 직접 작성하십시오. 앞서와 마찬가지로, LLM을 사용하여 작업을 리뷰할 수는 있지만 처음부터 작성하게 해서는 안 됩니다. 무엇이 건전성에 중요한 코드에 해당하는지 모르겠다면, 리뷰어와 논의하십시오.

PR을 열 때

아래의 공개 지침에 따라 LLM 사용 여부를 공개하십시오. 공개 내용은 직접 작성하십시오. 직접 작성한 공개 내용을 LLM으로 비공개로 리뷰하는 것은 허용되지만, 초안을 작성하거나 다시 쓰게 해서는 안 됩니다.

PR 설명과 댓글은 직접 작성하십시오. 저희는 여러분의 에이전트가 아니라 여러분의 이야기를 듣고 싶습니다. LLM으로 생성한 PR 설명은 금지됩니다. LLM으로 생성한 GitHub 댓글은 금지됩니다.

지침

코드를 작성하기 전에

한 번에 PR 하나씩 시작하십시오. 변경 사항은 여러분과 리뷰어가 모든 부분을 이해할 수 있을 만큼 작게 유지하십시오. 천천히 진행하십시오.

E-easy 이슈에는 LLM을 사용하지 마십시오. 이러한 이슈는 여러분이 직접 코드를 작성하도록 마련된 것입니다. E-mentor 이슈를 작업하기 전에는 먼저 문의하십시오. 멘토가 LLM이 생성한 코드로 작업하기를 원하지 않을 수도 있습니다.

이것이 유용하고 범위가 적절한 변경인지 판단하십시오. 예를 들면 다음과 같습니다.

작업하는 동안

버그를 수정할 때는 테스트가 변경 전에는 실패하고 변경 후에는 성공하는지 확인하십시오. 테스트 절차는 새 테스트 추가하기와 모범 사례를 참고하십시오. 테스트는 반드시 필요합니다. 기존 테스트든 여러분이 새로 작성한 테스트든 상관없습니다. 테스트되지 않은 LLM PR은 병합되지 않습니다.

대량의 이름 변경이나 재작성에는 ast-grep과 같은 적절한 구문 재작성 도구를 사용하는 편을 강력히 권장합니다. 해당 도구에 쓸 명령을 생성하는 데는 LLM을 사용해도 되지만, LLM으로 재작성을 직접 수행하는 것은 매우 신중해야 합니다.

코드를 작성할 때 성능을 고려하십시오.

의존성을 추가하기 전에 신중히 생각하십시오. 새 의존성에 관한 안내를 참고하십시오.

여러분의 이해가 맞는지 기존 코드, 문서, 테스트와 대조하여 확인하십시오. LLM 자신에게 관련 자료를 읽도록 지시하면 더 나은 조언을 얻을 수 있습니다. LLM을 신뢰할 수 있는 정보원으로 삼지 마십시오.

유지 보수하기 쉬운 코드 작성

생성된 코드는 최종 결과물이 아니라 초안으로 취급하십시오. 정확성 및 유지 보수성 규칙을 따르십시오.

불필요한 추상화와 호환성 계층을 피하십시오. Rustc에는 안정된 API가 없습니다. 내부 컴파일러 API의 하위 호환성을 유지할 필요는 없습니다.

커밋 구조

“PR 구성 방법”을 참고하십시오. 커밋 메시지는 LLM이 아니라 여러분이 직접 작성해야 합니다.

PR을 열기 전에

PR을 열기 전에 자신의 PR을 직접 검토하십시오. 이치에 맞습니까? PR의 목표가 무엇인지 알 수 있습니까? 그 목표를 달성합니까?

오래되었거나 프로토타이핑용인 코드와 디버깅 코드를 제거하십시오.

에이전트와의 대화만이 아니라 전체 diff를 다시 읽으십시오. 리뷰어는 여러분의 대화가 아니라 코드를 보게 됩니다.

변경 사항이 제대로 동작하는지 확인하려면 테스트를 실행하십시오. 어떤 UI 테스트를 실행했는지 PR 설명에 절대 적지 마십시오. CI가 어차피 실행하므로 불필요한 정보일 뿐입니다. 수동 테스트나 벤치마킹을 수행했다면 그 내용은 꼭 적으십시오. 다만 모든 LLM PR에는 자동화된 테스트가 있어야 한다는 점에 유의하십시오.

진단 스냅숏을 검토하십시오. 단순히 --bless로 덮어써서 넘어가지 마십시오.

변경 사항을 게시하기 전에 다른 모델을 사용하여 적대적 로컬 리뷰를 수행할 것을 권장합니다. 그렇더라도 자신의 변경 사항을 직접 검토할 책임은 여전히 여러분에게 있습니다.

자신의 변경 사항 이해하기

여러분이 자신의 변경 사항과 그 엣지 케이스를 이해하고 설명할 수 있기를 바랍니다. LLM에게 묻는 것이 출발점이 될 수는 있지만, 직접 설명하는 것과 같지는 않습니다.

PR을 열기 전에 자신의 변경 사항을 스스로에게 설명해 보십시오. 예를 들어 스스로에게 다음과 같이 물어보십시오:

  • 원래 버그는 무엇입니까? 언제 발생합니까? 얼마나 심각합니까? 원인은 무엇입니까?
  • 왜 이것이 올바른 수정입니까? 다른 수정 방법이 있습니까? 각각의 장점이나 단점은 무엇입니까?
  • 엣지 케이스가 있습니까? 여러분의 코드가 그것들을 처리합니까?
  • 코드에 기존 불변 조건이 있습니까? 그 불변 조건을 유지했습니까?
  • 변경되지 않는 동작은 무엇입니까? 어떤 테스트가 그것을 입증합니까?
  • 여러분의 테스트는 왜 그 버그를 유발합니까?
  • 아직 확신하지 못하는 부분은 무엇입니까?

확신이 없는 것도, 도움을 요청하는 것도 괜찮습니다. 잘못 추측하신 뒤 어디서 잘못되었는지 역추적해야 하는 상황보다, 확신이 없으셔서 저희가 도와드리는 편이 훨씬 낫습니다.

공개 지침

LLM 사용의 범위와 목적을 공개하십시오. 어떤 모델을 사용했는지는 중요하지 않지만, LLM을 아이디어를 구현하는 데 사용했는지 아니면 아이디어를 떠올리는 데 사용했는지는 중요합니다.

좋은 예시:

LLM 사용 공개: 프로파일링 데이터를 확인한 뒤 세 개의 커밋을 직접 작성했습니다. 제출하기 전에 LLM을 사용하여 커밋을 검토했습니다. LLM이 ImplString::is_negative가 더 이상 사용되지 않는다는 점을 찾아냈고, 그래서 해당 필드를 직접 제거했습니다.

LLM의 도움을 받아 작성했으며, LLM은 다음 작업을 수행했습니다:

  • Fastly와 CloudFront 헤더를 비교 검사하여 캐시 히트 누락의 원인이 무조건적인 return(pass)임을 추적했고,
  • 해당 스니펫이 추가된 이유를 파악하기 위해 git 히스토리를 검토했으며,
  • VCL 변경을 수행했습니다.

나쁜 예시:

🤖 Claude Code로 생성됨

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

LLM 정책

Forge를 참조하십시오.