Oxide의 LLM 사용 가이드라인 (RFD 576)

Who Should Read

팀이나 회사 차원에서 LLM 사용 가이드라인을 만들려는 엔지니어링 리더, 또는 LLM을 업무에 쓰면서 품질과 책임 사이의 균형을 고민하는 시니어 개발자.

Core Mechanics

• Oxide의 Bryan Cantrill이 작성한 RFD(Request for Discussion)로, LLM 사용 시 '책임(Responsibility) > 엄밀함(Rigor) > 공감(Empathy) > 팀워크(Teamwork) > 속도(Urgency)' 순서로 가치를 우선하라고 제안한다. 많은 조직이 속도만 추구하는 것과 정반대 방향.
• LLM이 만든 결과물은 전적으로 그것을 사용한 사람의 책임이라는 원칙을 명확히 세웠다. LLM을 썼다고 밝히는 것 자체가 오히려 책임 회피로 보일 수 있으니, 맥락에 따라 공개 여부를 신중히 판단해야 한다는 점도 짚었다.
• LLM 용도를 '읽기 보조(reader)', '글쓰기(writer)', '코딩', '디버깅' 등으로 나눠서 각각 다르게 접근한다. 문서 요약·분석 같은 읽기 보조는 비교적 안전하지만, 호스팅 LLM에 문서를 올릴 때 학습 데이터로 쓰이지 않는지 반드시 확인해야 한다고 경고한다.
• 글쓰기에 LLM을 쓰는 것에 대해 상당히 부정적이다. LLM이 생성한 글은 작성자의 사고 과정의 진정성을 훼손하며, '지적으로 바지 지퍼를 열고 다니는 것'과 같다고 표현했다. Oxide에서는 비코드 결과물(문서, RFD 등)에 LLM 생성 텍스트를 쓰지 않는다.
• 코딩에는 비교적 열린 입장이지만, LLM이 생성한 코드를 다른 사람에게 리뷰 요청하기 전에 반드시 본인이 먼저 셀프 리뷰해야 한다는 규칙을 둔다. 코드 리뷰 피드백을 반영할 때 전체를 다시 생성하면 반복적 리뷰가 불가능해지므로 금지.
• 디버깅에서의 LLM 사용은 '잃을 것도 없지만 얻을 것도 적다'고 평가한다. 다만 댓글에서는 크래시 덤프나 데드락 분석에서 여러 엔지니어가 못 푼 문제를 LLM이 해결한 사례가 언급되며 이 평가가 보수적이라는 반론이 있었다.
• LLM이 다른 문서의 LLM 작성 여부를 잘 판별한다는 주장을 했는데, 이에 대한 구체적 근거는 제시하지 않아 댓글에서 의문이 제기됐다.
• 전체적으로 'LLM은 도구일 뿐'이라는 관점을 일관되게 유지하면서, 조직 문화와 신뢰를 해치지 않는 범위 안에서 활용하자는 프레임워크를 제시한다.

Evidence

• 주니어 엔지니어에 대한 고려가 빠졌다는 지적이 있었다. Oxide는 시니어만 채용하니 해당이 안 되지만, Bryan처럼 30년 경력자의 LLM 접근법과 2025년 주니어 개발자의 접근법은 근본적으로 다르다는 점을 누군가 짚었다. 주니어는 LLM 없이 프로그래밍해본 적이 없을 수도 있다.
• 'LLM이 코드를 처음부터 잘 쓴다'는 주장에 반론이 나왔다. 실제로 쓸 만한 코드와 LLM이 생성한 코드 사이의 거리가 크기 때문에, LLM 코딩은 '백지 공포증 해소' 정도이지 de novo 코드 생성이라고 보기 어렵다는 의견. 글쓰기에서의 '진행 착각(illusion of progress)'이 코딩에도 동일하게 적용된다는 우려.
• 한 개발자가 자신의 LLM 코딩 워크플로를 공유했다: (1) 관련 소스를 LLM에 넣고 (2) 아키텍처를 먼저 논의하고 (3) 코드 생성 후 (4) 전체를 꼼꼼히 읽는 6단계 과정. 가장 어려운 부분은 마지막 '전체 읽기' 단계인데, 아직 버그를 못 찾은 상태에서 꼼꼼히 읽어야 할 동기가 약하다고 솔직하게 고백.
• LLM 생성 코드의 저작권 문제가 전혀 언급되지 않았다는 비판이 있었다. 오픈소스를 많이 만드는 회사가 GitHub 코드를 그대로 재현할 수 있는 LLM의 라이선스 위반 가능성을 다루지 않은 것은 의외라는 반응.
• LLM 제공업체의 '학습에 사용하지 않겠다'는 약속을 2025년에 믿는 것이 놀랍다는 냉소적 댓글도 있었다. Meta가 사용자 데이터를 광고에 안 쓰겠다는 약속과 같은 수준이라는 비유.

How to Apply

• 팀에 LLM 사용 가이드라인이 없다면, Oxide의 RFD를 템플릿 삼아 '우리 팀의 가치 → 용도별 원칙 → 구체적 규칙' 순서로 내부 문서를 작성해볼 수 있다. 특히 코드 리뷰 규칙(LLM 생성 코드는 본인이 먼저 셀프 리뷰, 리뷰 피드백은 수동 반영)은 바로 적용 가능.
• LLM으로 코드를 생성할 때, 댓글에서 공유된 6단계 워크플로(컨텍스트 주입 → 아키텍처 논의 → 코드 생성 → 테스트 → 전체 읽기 → 수동 수정)를 도입하면 품질 관리에 효과적이다.
• 외부 LLM 서비스에 회사 문서를 업로드할 때, 해당 서비스의 학습 데이터 opt-out 설정을 반드시 확인하고, 가능하면 팀 전체에 설정 방법을 공유하라. OpenAI의 'Improve the model for everyone' 같은 기본 체크 옵션을 특히 주의.
• PR 리뷰에서 LLM 생성 코드가 의심될 때, 전체를 다시 생성하지 말고 구체적 피드백을 수동으로 반영하도록 팀 규칙을 만들면 리뷰 효율이 올라간다.

Terminology

관련 논문

• Mindwalk – 코딩 에이전트 세션을 코드베이스 3D 맵 위에서 재생하는 시각화 도구

  Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.

• Ghost Font: 사람은 읽을 수 있지만 AI는 읽기 어려운 안티-AI 폰트 실험

  움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.

• GPT-5.6, Grok 4.5, Claude, Muse Spark 등 12개 모델이 동일한 앱 4개를 빌드한 결과 비교

  12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.

• Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과

  Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.

• Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구

  LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.

• LLM-as-a-Verifier: 범용 Verification 프레임워크

  LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.

Related Resources

• https://rfd.shared.oxide.computer/rfd/0576