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 코드 사용 시 책임은 엔지니어에게 있음
스스로 검토하지 않은 코드는 리뷰 대상이 될 수 없음
나의 절차는 다음과 같음:
관련 코드 입력 → 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 링크
Hacker News 의견
Bryan의 글이 균형 잡히고 현실적인 시각을 보여줌
Oxide가 주니어 엔지니어를 고용하지 않기 때문에 RFD에 관련 내용이 빠졌다고 생각함
Bryan은 30년 넘게 어려운 소프트웨어와 하드웨어를 다뤄온 엔지니어로, ‘진짜 어려운 프로그램(OS)’을 완성한 경험이 있음
그가 LLM을 다루는 방식은 2025년의 주니어 엔지니어와 매우 다름
요즘 주니어들은 LLM의 도움 없이 코딩해본 적이 거의 없을 것 같음
너무 지루해서 출근도 힘들었는데, 지금은 LLM으로 몇 분 만에 끝낼 수 있을 것 같음
그때 쏟은 시간이 지금 생각하면 거의 미친 짓처럼 느껴짐
그 후에야 Dreamweaver를 소개했는데, 생산성이 열 배는 늘었음
보안 연구처럼 결과가 명확한 분야에서는 LLM이 탁월하지만, 미묘한 판단이 필요한 문제에는 약함
그래서 반복적이고 체계적인 부분은 LLM에 맡기고, 판단이 필요한 부분은 사람이 맡는 게 이상적임
하지만 이제는 이게 ‘새로운 프로그래밍 방식’ 임을 받아들였고, 그걸 인식하자 오히려 젊어진 기분이 들었음
요즘 em-dash를 쓰면 AI가 쓴 글로 오해받는 게 좀 짜증남
Oxide의 RFD를 읽으며 대부분 고개를 끄덕였지만, “LLM이 코드를 처음부터 잘 쓴다”는 부분에는 동의하지 않음
LLM은 ‘빈 페이지 증후군’ 을 해결하는 데는 좋지만, 실제 배포할 코드는 그 결과물과 거리가 멀다고 생각함
이건 ‘진보의 착각’일 수도 있음
LLM은 데이터셋에 많이 등장한 ‘좋은 해결책’ 을 학습해 문제 해결에 강함
반면 인간의 표현은 다양성이 본질이라 평균적인 표현은 흥미를 잃게 함
결국 LLM은 미해결 문제를 푸는 능력을 제한할 수도 있음
코드 품질이 낮은 이유는 context window 한계 때문이라고 봄
함수 단위 생성은 괜찮지만, 기능 전체를 맡기면 구조나 인터페이스가 엉망이 됨
글쓰기에 비유하면 문단의 첫 문장과 마지막 문장만 주고 나머지를 채우게 하는 정도가 적당함
프로그래머는 코드 품질을 판단할 수 있지만, 글쓰기는 그렇지 않음
구형이나 저가형 모델을 써서 나쁜 인상을 가진 경우가 많음
“LLM이 LLM이 만든 글을 잘 판별한다”는 주장에 의문이 듦
데이터로 증명된 건지 궁금함
자사 채용 과정이 글쓰기 중심이라 최근 LLM 작성 지원서가 폭증했다고 함
RFD 0003과 채용 페이지에서도 주의하라고 했지만 계속 발생함
팟캐스트 에피소드에서도 관련 사례를 다룸
LLM이 모든 AI 글을 잡아내진 못하지만, 의심되는 경우 탐지 보조 도구로는 유용하다고 함
실험은 안 해봤지만 흥미로운 접근임
현재 기술로는 완벽한 판별이 불가능하다고 생각함
LLM 코드 사용 시 책임은 엔지니어에게 있음
스스로 검토하지 않은 코드는 리뷰 대상이 될 수 없음
나의 절차는 다음과 같음:
마지막 단계가 가장 어렵고, 감정적으로 건너뛰고 싶어짐
이 방식은 아키텍처 수준의 사고를 유지하면서 반복 작업을 줄여줌
하지만 LLM은 비결정적이므로, 컴파일러처럼 예측 가능한 도구와는 다름
코드가 제대로 작동하지 않으면 더 많은 수정이 필요함
그래서 LLM이 정말 시간을 절약하는지 확신이 없음
기계가 만든 코드를 다듬는 일에 감정적으로 몰입하기 어려움
LLM이 만든 코드의 저작권 침해 가능성이 언급되지 않은 게 이상함
GitHub 코드가 그대로 복제될 수도 있는데, 이는 오픈소스 기업에 중요한 문제임
인간의 기여가 충분해야 저작권이 성립하는데, 그 기준이 불분명함
문서가 잘 짜였지만, “LLM을 읽기 보조로 쓰는 건 문제없다”는 부분이 모순처럼 느껴짐
완벽하다면 원문과 다를 게 없고, 완벽하지 않다면 오독의 위험이 있음
실제로 LLM이 문서를 제대로 읽지 않고 목차만 보고 추론하는 경우를 자주 봄
콘텐츠와 독자 사이에 번역층이 생기는 위험이 있음
전체 텍스트를 직접 context window에 넣어야 함
다만 세 권 전체는 LLM의 한계를 넘는 분량일 수 있음
“LLM이 만든 글은 사고의 진정성까지 훼손한다”는 말에 공감함
인간이 직접 쓴 글은 가치가 있지만, LLM이 쓴 글은 가치가 희석된 복제물 같음
차라리 프롬프트를 읽는 게 낫다는 말이 인상적임
흥미롭고 독창적인 생각은 평균에서 벗어난 지점에 있음
번역처럼 비원어민이 자신의 생각을 더 잘 표현하려고 LLM을 쓰는 건 이해하지만,
수신자는 그 표현이 진짜 개인의 생각인지 의심하게 됨
코멘트는 코드에 담기지 않은 이론적 맥락을 표현하는 시도임
LLM은 이런 ‘이론’을 가질 수 없기 때문에 진짜 가치 있는 코멘트를 만들지 못함
예를 들어 /r/SaaS 게시물 대부분이 LLM이 쓴 것 같았지만,
감정적 스토리텔링으로 독자 반응을 잘 유도함
나도 문서나 벤치마크 작성에는 LLM을 활용함
비원어민이 기술 문서를 쓸 때도 도움이 되지만, 품질 편차가 큼
결국 정보 전달용 글쓰기에서는 LLM이 점점 유용해지고 있음
무엇을 썼는지가 아니라 왜 썼는지가 궁금함
그래서 내 생각이 독창적이지는 않아도 통계적으로는 드물다는 점이 위안이 됨
LLM으로 쓴 글은 읽을 가치가 없다고 생각함
Oxide가 비코드 산출물에는 LLM을 쓰지 않겠다는 단호한 원칙을 세운 게 좋음
코드 리뷰에서도 마찬가지로, 생성된 코드는 작성자가 먼저 검토해야 함
이런 문화가 실제로 유지될지는 두고 봐야겠지만, 방향성은 현명함
LLM이 도용된 데이터로 학습되었다는 인식이 강한데,
이런 대중 인식을 고려했어야 한다고 생각함
윤리적 문제이든 브랜드 리스크이든, 지금은 분명 중요한 요소임
윤리적 입장보다는 기술적 가이드라인을 제시하는 게 목적임
LLM이 만든 글은 진정성을 잃고, 독자는 그 생각마저 자동화된 것처럼 느끼게 됨
결국 서로 간의 신뢰를 해칠 수 있음
“글쓰기가 읽기보다 더 큰 지적 노동이다”라는 말이 흥미로움
하지만 코드는 반대라고 느낌
그래서 나쁜 코드가 훨씬 많음
반면 잘 쓴 코드는 학습 가치가 크고, 글처럼 통찰이 필요함
“디버깅은 코드를 작성하는 것보다 두 배 어렵다.
그러니 작성할 때 최대한 똑똑하게 굴면, 디버깅은 불가능해진다”
laws-of-software.com 링크