▲

Oxide가 LLM을 활용하는 법

 (rfd.shared.oxide.computer)
4P by GN⁺ 5일전 | ★ favorite | 댓글 1개
  • 대규모 언어 모델(LLM) 이 업무 방식을 근본적으로 바꾸고 있으며, Oxide는 이를 조직 내에서 어떻게 사용할지 명확히 정의함
    • Oxide 는 온프레미스 데이터 센터를 위한 통합 하드웨어 및 소프트웨어를 만드는 온디맨드 컴퓨팅 인프라 스타트업
  • LLM 활용의 핵심 원칙으로 책임, 엄밀함, 공감, 팀워크, 긴급성의 균형을 제시
  • 문서 요약·이해, 코드 리뷰, 디버깅 등에서는 유용하지만, 글쓰기나 코드 작성 시 인간의 판단과 책임이 필수임
  • LLM이 생성한 결과물은 항상 인간이 검토·책임지는 구조를 유지해야 함
  • Oxide는 LLM 사용을 장려하되, 제품·고객·동료에 대한 책임감을 전제로 함

LLM 사용의 가치 기준

  • Oxide는 LLM 사용을 조직의 핵심 가치에 따라 평가함
    • 책임(Responsibility) : LLM은 도구일 뿐이며, 결과물의 책임은 전적으로 인간에게 있음
    • 엄밀함(Rigor) : 신중히 사용하면 사고를 정교하게 다듬을 수 있으나, 부주의하면 사고의 질을 떨어뜨림
    • 공감(Empathy) : 언어의 수신자와 작성자 모두 인간임을 인식하고, 인간 중심의 소통을 유지해야 함
    • 팀워크(Teamwork) : LLM 사용이 동료 간 신뢰를 훼손하지 않도록 주의해야 하며, 사용 사실의 공개가 책임 회피로 비치지 않도록 함
    • 긴급성(Urgency) : 속도 향상이 가능하더라도, 다른 가치들을 희생해서는 안 됨

LLM의 다양한 활용 방식

LLMs as Readers

  • LLM은 문서 요약과 질의응답에 매우 뛰어나며, 방대한 자료를 빠르게 이해할 수 있음
  • 단, 데이터 프라이버시를 보장해야 하며, 업로드된 문서가 모델 학습에 사용되지 않도록 설정 필요
  • 문서 이해 보조 도구로는 유용하지만, 직접 읽어야 하는 상황을 대체해서는 안 됨

LLMs as Editors

  • 완성된 문서의 구조·문체 개선에 효과적이며, 후반 단계에서 활용 시 유용함
  • 그러나 LLM은 과도하게 긍정적인 반응을 보이는 경향이 있어, 비판적 분석이 부족할 수 있음
  • 초안 단계에서 사용하면 작성자의 고유한 목소리를 잃을 위험이 있음

LLMs as Writers

  • LLM이 생성한 글은 진부하거나 자동 생성의 흔적이 뚜렷한 경우가 많음
  • 자동 생성된 글은 사고의 진정성과 독자의 신뢰를 훼손할 수 있음
  • 독자는 작성자가 내용을 이해했다고 전제하지만, LLM 작성물은 그 전제를 무너뜨림
  • Oxide는 구성원이 모두 글쓰기 능력을 갖추고 있음을 전제로, LLM을 글쓰기 주체로 사용하지 않음
  • 단, 아이디어 정리나 보조 도구로는 제한적으로 활용 가능

LLMs as Code Reviewers

  • LLM은 특정 유형의 코드 문제 탐지에 유용하지만, 인간 리뷰를 대체할 수 없음
  • 제안이 비논리적이거나 맥락을 놓칠 수 있으므로, 보조적 도구로만 사용

LLMs as Debuggers

  • LLM은 디버깅 아이디어를 유도하는 ‘러버덕’ 역할로 활용 가능
  • 실제 문제 해결 능력은 제한적이지만, 새로운 접근을 떠올리게 하는 자극으로 유용함

LLMs as Programmers

  • LLM은 코드 생성 능력이 매우 뛰어나며, 실험적·보조적 코드 작성에 적합함
  • 제품 코드에 가까울수록 검증과 책임이 중요함
  • LLM이 작성한 코드는 작성자가 직접 검토(self-review) 해야 하며, 동료 리뷰 전에 반드시 확인 필요
  • 코드 리뷰 중 전체 재생성으로 대응하는 행위는 금지, 반복 검토가 불가능해짐
  • 코드 생성 시에도 책임, 엄밀함, 공감, 팀워크를 유지해야 함

운영 및 지침

  • LLM 사용의 기술적 세부사항과 내부 가이드라인은 GitHub의 내부 문서에 정리되어 있음
  • Oxide는 LLM 사용을 권장하되, 책임 있는 활용을 전제로 함
    • 제품 품질, 고객 신뢰, 동료 간 협업에 대한 책임 의식을 최우선으로 함
▲
GN⁺ 5일전  [-]
Hacker News 의견

  • Bryan의 글이 균형 잡히고 현실적인 시각을 보여줌
    Oxide가 주니어 엔지니어를 고용하지 않기 때문에 RFD에 관련 내용이 빠졌다고 생각함
    Bryan은 30년 넘게 어려운 소프트웨어와 하드웨어를 다뤄온 엔지니어로, ‘진짜 어려운 프로그램(OS)’을 완성한 경험이 있음
    그가 LLM을 다루는 방식은 2025년의 주니어 엔지니어와 매우 다름
    요즘 주니어들은 LLM의 도움 없이 코딩해본 적이 거의 없을 것 같음

    • 예전에 회사에서 데이터 인제스트용 모델만 몇 달 동안 만들던 시절이 있었음
      너무 지루해서 출근도 힘들었는데, 지금은 LLM으로 몇 분 만에 끝낼 수 있을 것 같음
      그때 쏟은 시간이 지금 생각하면 거의 미친 짓처럼 느껴짐
    • 웹디자인 첫 수업에서 선생님이 한 학기 내내 Notepad로 HTML, CSS, JS의 ‘기초 원리’ 를 가르쳤던 기억이 있음
      그 후에야 Dreamweaver를 소개했는데, 생산성이 열 배는 늘었음
    • LLM의 ‘장인정신 vs 실용성’ 의 긴장이 흥미로움
      보안 연구처럼 결과가 명확한 분야에서는 LLM이 탁월하지만, 미묘한 판단이 필요한 문제에는 약함
      그래서 반복적이고 체계적인 부분은 LLM에 맡기고, 판단이 필요한 부분은 사람이 맡는 게 이상적임
    • 20년 넘게 프로그래밍을 해왔는데, LLM을 쓰는 데 보이지 않는 거부감이 있었음
      하지만 이제는 이게 ‘새로운 프로그래밍 방식’ 임을 받아들였고, 그걸 인식하자 오히려 젊어진 기분이 들었음
    • 문장 중 ‘LLM의 흔적을 알아보는 사람들’이라는 표현 바로 뒤에 em-dash(—) 가 등장한 게 웃겼음
      요즘 em-dash를 쓰면 AI가 쓴 글로 오해받는 게 좀 짜증남

  • Oxide의 RFD를 읽으며 대부분 고개를 끄덕였지만, “LLM이 코드를 처음부터 잘 쓴다”는 부분에는 동의하지 않음
    LLM은 ‘빈 페이지 증후군’ 을 해결하는 데는 좋지만, 실제 배포할 코드는 그 결과물과 거리가 멀다고 생각함
    이건 ‘진보의 착각’일 수도 있음

    • 글쓰기는 개인의 표현이지만, 코드는 문제 해결 도구임
      LLM은 데이터셋에 많이 등장한 ‘좋은 해결책’ 을 학습해 문제 해결에 강함
      반면 인간의 표현은 다양성이 본질이라 평균적인 표현은 흥미를 잃게 함
      결국 LLM은 미해결 문제를 푸는 능력을 제한할 수도 있음
      코드 품질이 낮은 이유는 context window 한계 때문이라고 봄
    • 진부한 글은 나쁘지만, 진부한 코드는 오히려 좋음
    • “다른 모델을 써보라”는 반박은 이제 LLM 세계의 ‘No True Scotsman’ 처럼 느껴짐
      함수 단위 생성은 괜찮지만, 기능 전체를 맡기면 구조나 인터페이스가 엉망이 됨
      글쓰기에 비유하면 문단의 첫 문장과 마지막 문장만 주고 나머지를 채우게 하는 정도가 적당함
    • 우리가 잘 아는 분야의 뉴스는 오류를 쉽게 알아차리지만, 모르는 분야는 그대로 믿는 현상과 비슷함
      프로그래머는 코드 품질을 판단할 수 있지만, 글쓰기는 그렇지 않음
    • LLM의 품질은 모델에 따라 다름
      구형이나 저가형 모델을 써서 나쁜 인상을 가진 경우가 많음

  • “LLM이 LLM이 만든 글을 잘 판별한다”는 주장에 의문이 듦
    데이터로 증명된 건지 궁금함

    • Oxide의 Bryan이 직접 설명함
      자사 채용 과정이 글쓰기 중심이라 최근 LLM 작성 지원서가 폭증했다고 함
      RFD 0003과 채용 페이지에서도 주의하라고 했지만 계속 발생함
      팟캐스트 에피소드에서도 관련 사례를 다룸
      LLM이 모든 AI 글을 잡아내진 못하지만, 의심되는 경우 탐지 보조 도구로는 유용하다고 함
    • LLM이 만든 글을 판별하는 방법으로, 텍스트 절반을 LLM에 넣고 나머지를 예측하게 하여 n-토큰 확률을 비교하는 아이디어를 제안함
      실험은 안 해봤지만 흥미로운 접근임
    • LLM이 얼마나 개입했는지(전체 작성, 요약, 교정 등)에 따라 탐지가 어렵기 때문에
      현재 기술로는 완벽한 판별이 불가능하다고 생각함

  • LLM 코드 사용 시 책임은 엔지니어에게 있음
    스스로 검토하지 않은 코드는 리뷰 대상이 될 수 없음
    나의 절차는 다음과 같음:

    1. 관련 코드 입력 → 2) 목표 설명 → 3) 설계 검토 → 4) 코드 생성 → 5) 테스트 및 수정 → 6) 전체 코드 정독 및 수동 수정
      마지막 단계가 가장 어렵고, 감정적으로 건너뛰고 싶어짐
      이 방식은 아키텍처 수준의 사고를 유지하면서 반복 작업을 줄여줌
      하지만 LLM은 비결정적이므로, 컴파일러처럼 예측 가능한 도구와는 다름
    • 실제로는 6단계가 전체 시간의 대부분을 차지함
      코드가 제대로 작동하지 않으면 더 많은 수정이 필요함
      그래서 LLM이 정말 시간을 절약하는지 확신이 없음
    • 4단계 전에 테스트 코드를 먼저 생성하게 하고, 실패 후 통과하도록 만드는 절차를 추가하면 좋음
    • 수동 수정 대신 LLM이 모든 변경을 주도하게 하면, 세션 내에서 지식 일관성을 유지할 수 있음
    • 이렇게 하면 엔지니어의 자존심과 소유감이 손상된다고 느낌
      기계가 만든 코드를 다듬는 일에 감정적으로 몰입하기 어려움

  • LLM이 만든 코드의 저작권 침해 가능성이 언급되지 않은 게 이상함
    GitHub 코드가 그대로 복제될 수도 있는데, 이는 오픈소스 기업에 중요한 문제임

    • LLM 생성물이 저작권 대상이 아니라면, Copyleft 라이선스 코드의 법적 지위가 모호해짐
      인간의 기여가 충분해야 저작권이 성립하는데, 그 기준이 불분명함
    • 이런 사안이 법정에서 다뤄진 적이 있는지 궁금함
    • 최신 LLM이 여전히 이런 문제를 일으키는지, 혹은 인간보다 더 자주 그런지 의문임

  • 문서가 잘 짜였지만, “LLM을 읽기 보조로 쓰는 건 문제없다”는 부분이 모순처럼 느껴짐
    완벽하다면 원문과 다를 게 없고, 완벽하지 않다면 오독의 위험이 있음
    실제로 LLM이 문서를 제대로 읽지 않고 목차만 보고 추론하는 경우를 자주 봄
    콘텐츠와 독자 사이에 번역층이 생기는 위험이 있음

    • RFD는 ‘읽기’가 아니라 ‘쓰기’의 사회적 기대에 대한 이야기였다고 생각함
    • 세 권의 기술서를 비교시켰는데 잘못된 결과를 냈다면, 이는 도구 사용 실패임
      전체 텍스트를 직접 context window에 넣어야 함
      다만 세 권 전체는 LLM의 한계를 넘는 분량일 수 있음

  • “LLM이 만든 글은 사고의 진정성까지 훼손한다”는 말에 공감함
    인간이 직접 쓴 글은 가치가 있지만, LLM이 쓴 글은 가치가 희석된 복제물 같음
    차라리 프롬프트를 읽는 게 낫다는 말이 인상적임

    • 인간의 예술은 개인의 내면을 표현하지만, LLM은 집단 평균의 산출물임
      흥미롭고 독창적인 생각은 평균에서 벗어난 지점에 있음
      번역처럼 비원어민이 자신의 생각을 더 잘 표현하려고 LLM을 쓰는 건 이해하지만,
      수신자는 그 표현이 진짜 개인의 생각인지 의심하게 됨
    • Naur의 “Programming as Theory Building”을 떠올림
      코멘트는 코드에 담기지 않은 이론적 맥락을 표현하는 시도임
      LLM은 이런 ‘이론’을 가질 수 없기 때문에 진짜 가치 있는 코멘트를 만들지 못함
    • LLM 특유의 ‘AI 글투’ 가 싫지만, 많은 사람들은 그걸 눈치채지 못함
      예를 들어 /r/SaaS 게시물 대부분이 LLM이 쓴 것 같았지만,
      감정적 스토리텔링으로 독자 반응을 잘 유도함
      나도 문서나 벤치마크 작성에는 LLM을 활용함
      비원어민이 기술 문서를 쓸 때도 도움이 되지만, 품질 편차가 큼
      결국 정보 전달용 글쓰기에서는 LLM이 점점 유용해지고 있음
    • “프롬프트를 읽고 싶다”는 말은 뉴스 헤드라인을 볼 때도 듦
      무엇을 썼는지가 아니라 왜 썼는지가 궁금함
    • LLM은 평균적인 문장은 잘 예측하지만, 창의적인 문장은 거의 못 맞춤
      그래서 내 생각이 독창적이지는 않아도 통계적으로는 드물다는 점이 위안이 됨

  • LLM으로 쓴 글은 읽을 가치가 없다고 생각함
    Oxide가 비코드 산출물에는 LLM을 쓰지 않겠다는 단호한 원칙을 세운 게 좋음
    코드 리뷰에서도 마찬가지로, 생성된 코드는 작성자가 먼저 검토해야 함
    이런 문화가 실제로 유지될지는 두고 봐야겠지만, 방향성은 현명함

  • LLM이 도용된 데이터로 학습되었다는 인식이 강한데,
    이런 대중 인식을 고려했어야 한다고 생각함
    윤리적 문제이든 브랜드 리스크이든, 지금은 분명 중요한 요소임

    • 이 문서는 대중 대상이 아니라 내부 기술 문서로 봄
      윤리적 입장보다는 기술적 가이드라인을 제시하는 게 목적임
    • 글에서 말하는 ‘신뢰의 붕괴’가 바로 그 문제를 다른 표현으로 다룬 것 같음
      LLM이 만든 글은 진정성을 잃고, 독자는 그 생각마저 자동화된 것처럼 느끼게 됨
      결국 서로 간의 신뢰를 해칠 수 있음

  • “글쓰기가 읽기보다 더 큰 지적 노동이다”라는 말이 흥미로움
    하지만 코드는 반대라고 느낌

    • 형편없는 글은 쓸모없지만, 형편없는 코드도 일단 돌아가기만 하면 Jira 티켓을 닫을 수 있음
      그래서 나쁜 코드가 훨씬 많음
      반면 잘 쓴 코드는 학습 가치가 크고, 글처럼 통찰이 필요함
    • Kernighan의 법칙을 인용함
      “디버깅은 코드를 작성하는 것보다 두 배 어렵다.
      그러니 작성할 때 최대한 똑똑하게 굴면, 디버깅은 불가능해진다”
      laws-of-software.com 링크
답변달기