LLM 코딩 도구를 비결정적 컴파일러처럼 본다는 주장에 동의한다면, 가능한 한 성능 좋은 언어를 고르는 게 꽤 말이 됨
물론 라이브러리나 언어별 네이티브 장점 같은 예외는 많지만, 지난 한 달 정도 C++로 작업해 보니 언어 선택 때문에 느려진 건 컴파일 시간뿐이었음
초반 댓글들을 읽고도 학습 데이터 얘기가 안 보여서 놀랐음. Python 코드가 학습 데이터에 워낙 많음
AI로 Brainfuck도 쓸 수는 있겠지만, Python을 쓸 때와 같은 결과가 나오지는 않을 거라고 봄
후속 질문은 이거임: 이제 AI가 있다면, 필요해지기 전까지 왜 언어를 신경 써야 하나?
5년 만에 Perl을 다시 써보고 싶어졌고, Go로 만들던 프록시를 띄우고 여러 통합 테스트를 작성할 아주 단순한 방법이 필요했음
Claude Code로 대부분을 작성했는데 Claude가 Perl을 정말 잘 다뤘음. CPAN에 손대지 말고 Perl 표준 라이브러리만 쓰라고 했더니 HTTP 클라이언트, TLS, JSON까지 전부 내장되어 있었고, 평소라면 셸 스크립트로 구현했을 일을 매우 안정적이고 쉬운 방식으로 대체할 수 있었음
Perl이 크게 변하지 않았고 학습 데이터도 많아서, Claude는 셸 스크립트를 떠올릴 만한 상황에서 Perl을 꽤 잘 쓰는 것 같음
그냥 Go를 쓰면 됨. LLM이 Go를 많이 봤고, 잘 작성하며, 거의 즉시 컴파일되고, 타입이 있는 컴파일 언어의 장점도 모두 있음
AI로 큰 Python 코드베이스를 만들었는데, LLM이 계속 인수나 딕셔너리 형식을 잘못 추측했음. 단위 테스트나 pydantic 같은 도구가 도움이 되긴 하지만, 그런 종류의 런타임 오류 자체를 피하는 편이 더 낫다
학습 데이터만으로는 답이 다 안 됨. LLM은 다른 프로그래밍 언어로 번역하는 일을 정말 잘함. 텍스트 번역 시스템에서 파생됐다는 점을 생각하면 자연스러움
공개 코드가 상대적으로 적은 언어에서도 결과가 훌륭했음. 더 큰 장애물은 LLM이 대상 언어의 흔한 관용구를 베낀다는 점이고, Java나 C#처럼 “엔터프라이즈스러운” 언어라면 쓸모없는 상용구 코드가 즉시 폭증할 수 있음. 그러면 결과물이 사용 가능한 문맥 창 크기를 넘어서 품질이 떨어질 위험이 커짐
AI에게 열린 루프로 코드를 생성하게 한다면 학습 데이터가 중요할 수 있음. Python에는 요청한 것과 비슷한 코드를 누군가 이미 작성했을 가능성이 높으니까
하지만 에이전트가 코드를 만들고, 컴파일을 시도하고, 자세한 오류 메시지를 본 뒤 그 메시지를 바탕으로 코드를 다듬는다면 더 높은 품질의 결과가 나옴. rustc 진단은 매우 좋고, Python이나 JavaScript/TypeScript가 훨씬 많다 해도 이제 온라인에 Rust 코드도 충분히 많음
왜 Python이냐면, 10년 넘게 써왔고 디버깅 방법을 알며, 에이전트가 코드를 쓰고 10초 안에 큰 사고로 이어질 만한 일을 하는지 냄새로 알아챌 수 있기 때문임
다른 언어라면 그렇지 않고 많이 다시 배워야 함. AI가 빠르게 코드를 쏟아내더라도 어느 정도 통제하고 있다는 느낌이 드는 Python을 선호하게 됨. Go나 Rust로 했다면 AI 보조 프로그래밍이라기보다, 제품 전체를 그냥 YOLO로 밀어붙이는 “바이브 코딩”처럼 느껴졌을 것임
에이전트 시대에 Rust를 쓰기 시작했는데, 다른 언어에서 쌓은 경험이 여전히 이어져서 코드 냄새와 나쁜 아키텍처를 알아보는 데 도움이 됐음
메모리 안전성 부분은 무엇이 “맞는지” 몰라서 배워야 했지만, 나머지는 순조로웠음
문법은 점점 배경으로 사라지고 더 높은 수준의 것에 집중하게 되며 새로운 길을 탐색하게 됨. 한번 시도해 보면 경험이 얼마나 많이 이전되는지 기분 좋게 놀랄 수 있음
나도 비슷했음. AI가 생성한 Python 코드는 몇 줄만 봐도 헛소리인지 냄새를 맡을 수 있어서, 대부분의 프로젝트에 계속 Python을 씀
AI가 글을 써준다면 왜 뇌를 쓰나?
비웃을 일이 아님. 모델은 지난달보다 훨씬 좋아졌고 토큰 비용도 내려갔음. LLM은 뇌를 위한 컴파일러와 같음
/s
AI가 Rust를 쓰게 하는 데서 왜 멈추나? 모든 게 바이브 코딩이고 코드 리뷰도 더 이상 안 한다면, LLM에게 토큰 사용량 최소화와 속도만을 위해 만든 초간결·초고밀도 언어를 설계하게 하면 됨
이 댓글 끝에는 부분적으로만 의도한 /s가 붙어 있음
왜 코드 작성에서 멈추나? 우리 모두 맞춤형 ASIC 칩을 만들어야 하고, 칩 팹이 없다면 최소한 FPGA라도 해야 함
약간 주제에서 벗어나지만, 도대체 왜 아직도 사람들이 Medium에 글을 올리는지 모르겠음
읽기 경험이 끔찍함. 전체 화면 팝업이 읽고 있던 문장을 말 그대로 가려서 이 글도 끝까지 못 읽었음
내가 못 보는 어떤 유인이 있나?
브라우저에서 읽는 어떤 것도 모두에게 궁극적으로 훌륭하고 단연 최고의 읽기 경험을 똑같이 제공할 수는 없음. 현대 웹 모델 자체가 그와 충돌함
CSS 없는 평범한 HTML 페이지는 거의 완벽한 읽기 경험임. 문제는 거의 아무도 그렇게 배포하지 않는다는 것임. 웹이 저자들이 관심을 두고 경쟁하는 출판 플랫폼이 되었기 때문임. 사용자 통제 아래 있는 일반 텍스트 프로토콜이 “모두에게 최고의 읽기 경험”에 더 가까움. 웹도 그럴 수 있었지만 대부분은 그렇지 않음
브라우저에서 긴 글을 읽으려는 시도를 그만뒀음. 관련된 일반 텍스트, 심지어 구조화된 텍스트까지 쉽게 추출해서 내 편집기에서 읽을 수 있는데 왜 브라우저에서 읽어야 하나? 글꼴, 색상, 탐색 등을 내가 통제할 수 있음. 브라우저는 전달 수단이지 읽기 환경이 아님. 그렇게 취급하는 건 습관이지 필수가 아님
오래전부터 세 단어보다 긴 것은 편집기 밖에서 쓰지 않게 됐음. 맞춤법 검사, 동의어 사전, 어원 조회, 번역, 내 모든 노트 접근, LLM 연동까지 이미 필요한 게 다 있음. 언젠가 시도해 보면 엄청나게 해방감을 느낄 것임. 그러면 긴 글을 브라우저에서 읽는 것도 그만둘 수 있음
Medium은 글쓴이에게 돈을 지급하려는 꽤 진지한 시도를 해왔음. Substack과는 다른 모델이지만, 그게 이유임
신문 유료 장벽을 보는 방식과 비슷하게 봄. 마음에 들지는 않지만 왜 있는지는 이해함
가장 그럴듯한 추측은 관성임. 어떤 사람들은 브랜드 충성도가 매우 강하고, 남들이 무엇을 어떻게 하는지에 맞춰 움직여야 함
실제로는 어디에 게시됐는지는 중요하지 않고 URL만 주면 되지만, 모두가 그렇게 행동하지는 않음
글쓴이 친화적인 블로그 플랫폼의 최신 진화처럼 보임. WordPress보다 뉴스레터 형태로 묶기 쉽고, 유료 티어로 수익화하기도 더 쉬움
Python은 Rust보다 훨씬 성숙한 생태계를 갖고 있고, 특히 AI/머신러닝 쪽에서 그렇음
특정 머신러닝 알고리즘을 구현한다고 주장하는 Rust 크레이트를 만났는데 제대로 동작하지 않았음. 그래도 Claude로 대체 구현을 작성할 수는 있었음
AI와 함께라면 타입 시스템 수준에서 정확성을 강제하는 게 좋은 생각이라고 봐서, Python보다 C#이나 Rust 같은 언어를 자주 고름. 다만 어떤 일에는 Python이 분명 맞는 도구임
거의 항상 Rust를 고름. 최근에는 Go로 작성된 어떤 것의 플러그인을 만들었음
Rust를 쓸 수도 있었지만, 결과물이 잘되면 다른 사람들은 하나의 도구 체인을 쓰는 데서 더 큰 가치를 얻을 테니 Go가 맞다고 느꼈음
핵심 이유는 필요할 때 읽을 수 있어야 한다는 것임. 그리고 받는 쪽 생태계가 기대하는 언어가 있음. 일부 데이터 과학 커뮤니티가 R, MatLab, Julia, Python, Mojo를 고르는 것도 기술적으로 무엇이 우월한지가 아니라 동료들이 무엇을 쓰는지에 달려 있음
유일한 사용처는 머신러닝 라이브러리처럼 저수준 C++ 라이브러리를 감싸는 경우라고 봄. 그런 것들은 재현하기가 정말 어렵긴 함
AI와 함께 쓸 때 타입 시스템 강제가 좋은 이유는 몇 가지 있음
추측이지만, 타입 언어는 더 빠르고 좋은 언어 서버를 갖는 경우가 많아서 도구 사용으로 코드를 더 효율적으로 수정할 수 있음
사람이 직접 끼어들어 코드를 조사하거나 수정해야 할 때도, 강한 타입 덕분에 스파게티 코드 안에서 훨씬 쉽게 방향을 잡을 수 있음
AI/머신러닝 라이브러리 지원에는 확실히 할 말이 있음. 그래도 요즘 백엔드 작업은 Rust/TypeScript로 많이 가게 됨. Django를 정말 좋아하는데도 그렇다
Python 생태계에서 벗어나 AI가 의존성을 관리하거나 폴리필하게 둘 거라면, Rust가 아니라 차라리 OCaml/F#까지 가는 편이 나음
그러면 가비지 컬렉션과 강한 타입의 장점을 얻을 수 있음
지금으로서는 사람이 직접 작성할 때 Python을 쓰는 이유와 정확히 같음. Zig 같은 언어보다 Python을 아는 사람이 더 많아서, 사람이 코드를 더 쉽게 읽고 수정할 수 있기 때문임
글의 요지는 이해하지만, 아직 그 단계까지는 아니라고 봄
자동화가 인간이 이해하지 못하는 언어로 작성하는 세상은, 완전히 캄캄한 중국 자동화 공장을 떠올리게 함. 인간은 길을 잃고 혼란스러워하지만 로봇은 그 안에서 편안한 곳
“팀의 아무도 모르는 언어로 출시된 앱”이라니 좋음. 그리 멀지 않은 미래에 이 일을 되돌아보게 될 것임
AI 이전에도 이런 일은 있었음. 10년 전 어떤 사람이 무작위 언어로 핵심 도구를 작성했고, 나머지 사람들이 그걸 유지보수해야 했음. 그래도 어떻게든 해냈음
아마 그들이 대체하던 Electron 앱보다 더 무서울 수 있는 세상 유일한 물건일 듯함
그냥 12~18개월 뒤에 이직하면 됨. 그러면 그건 다른 사람 문제임
“Anthropic 연구원 Nicholas Carlini가 16개의 병렬 Claude 에이전트를 조율해 Rust로 프로덕션 C 컴파일러를 작성했다”는 건 사실이 아님
그 컴파일러는 gcc/clang보다 훨씬 열등한 코드를 생성해서 사실상 쓸모없음
Hacker News 의견들
LLM 코딩 도구를 비결정적 컴파일러처럼 본다는 주장에 동의한다면, 가능한 한 성능 좋은 언어를 고르는 게 꽤 말이 됨
물론 라이브러리나 언어별 네이티브 장점 같은 예외는 많지만, 지난 한 달 정도 C++로 작업해 보니 언어 선택 때문에 느려진 건 컴파일 시간뿐이었음
초반 댓글들을 읽고도 학습 데이터 얘기가 안 보여서 놀랐음. Python 코드가 학습 데이터에 워낙 많음
AI로 Brainfuck도 쓸 수는 있겠지만, Python을 쓸 때와 같은 결과가 나오지는 않을 거라고 봄
후속 질문은 이거임: 이제 AI가 있다면, 필요해지기 전까지 왜 언어를 신경 써야 하나?
Claude Code로 대부분을 작성했는데 Claude가 Perl을 정말 잘 다뤘음. CPAN에 손대지 말고 Perl 표준 라이브러리만 쓰라고 했더니 HTTP 클라이언트, TLS, JSON까지 전부 내장되어 있었고, 평소라면 셸 스크립트로 구현했을 일을 매우 안정적이고 쉬운 방식으로 대체할 수 있었음
Perl이 크게 변하지 않았고 학습 데이터도 많아서, Claude는 셸 스크립트를 떠올릴 만한 상황에서 Perl을 꽤 잘 쓰는 것 같음
데이터는 여기 있음: https://gertlabs.com/rankings?mode=agentic_coding
AI로 큰 Python 코드베이스를 만들었는데, LLM이 계속 인수나 딕셔너리 형식을 잘못 추측했음. 단위 테스트나 pydantic 같은 도구가 도움이 되긴 하지만, 그런 종류의 런타임 오류 자체를 피하는 편이 더 낫다
공개 코드가 상대적으로 적은 언어에서도 결과가 훌륭했음. 더 큰 장애물은 LLM이 대상 언어의 흔한 관용구를 베낀다는 점이고, Java나 C#처럼 “엔터프라이즈스러운” 언어라면 쓸모없는 상용구 코드가 즉시 폭증할 수 있음. 그러면 결과물이 사용 가능한 문맥 창 크기를 넘어서 품질이 떨어질 위험이 커짐
하지만 에이전트가 코드를 만들고, 컴파일을 시도하고, 자세한 오류 메시지를 본 뒤 그 메시지를 바탕으로 코드를 다듬는다면 더 높은 품질의 결과가 나옴. rustc 진단은 매우 좋고, Python이나 JavaScript/TypeScript가 훨씬 많다 해도 이제 온라인에 Rust 코드도 충분히 많음
왜 Python이냐면, 10년 넘게 써왔고 디버깅 방법을 알며, 에이전트가 코드를 쓰고 10초 안에 큰 사고로 이어질 만한 일을 하는지 냄새로 알아챌 수 있기 때문임
다른 언어라면 그렇지 않고 많이 다시 배워야 함. AI가 빠르게 코드를 쏟아내더라도 어느 정도 통제하고 있다는 느낌이 드는 Python을 선호하게 됨. Go나 Rust로 했다면 AI 보조 프로그래밍이라기보다, 제품 전체를 그냥 YOLO로 밀어붙이는 “바이브 코딩”처럼 느껴졌을 것임
메모리 안전성 부분은 무엇이 “맞는지” 몰라서 배워야 했지만, 나머지는 순조로웠음
문법은 점점 배경으로 사라지고 더 높은 수준의 것에 집중하게 되며 새로운 길을 탐색하게 됨. 한번 시도해 보면 경험이 얼마나 많이 이전되는지 기분 좋게 놀랄 수 있음
AI가 글을 써준다면 왜 뇌를 쓰나?
/s
AI가 Rust를 쓰게 하는 데서 왜 멈추나? 모든 게 바이브 코딩이고 코드 리뷰도 더 이상 안 한다면, LLM에게 토큰 사용량 최소화와 속도만을 위해 만든 초간결·초고밀도 언어를 설계하게 하면 됨
이 댓글 끝에는 부분적으로만 의도한 /s가 붙어 있음
약간 주제에서 벗어나지만, 도대체 왜 아직도 사람들이 Medium에 글을 올리는지 모르겠음
읽기 경험이 끔찍함. 전체 화면 팝업이 읽고 있던 문장을 말 그대로 가려서 이 글도 끝까지 못 읽었음
내가 못 보는 어떤 유인이 있나?
브라우저에서 읽는 어떤 것도 모두에게 궁극적으로 훌륭하고 단연 최고의 읽기 경험을 똑같이 제공할 수는 없음. 현대 웹 모델 자체가 그와 충돌함
CSS 없는 평범한 HTML 페이지는 거의 완벽한 읽기 경험임. 문제는 거의 아무도 그렇게 배포하지 않는다는 것임. 웹이 저자들이 관심을 두고 경쟁하는 출판 플랫폼이 되었기 때문임. 사용자 통제 아래 있는 일반 텍스트 프로토콜이 “모두에게 최고의 읽기 경험”에 더 가까움. 웹도 그럴 수 있었지만 대부분은 그렇지 않음
브라우저에서 긴 글을 읽으려는 시도를 그만뒀음. 관련된 일반 텍스트, 심지어 구조화된 텍스트까지 쉽게 추출해서 내 편집기에서 읽을 수 있는데 왜 브라우저에서 읽어야 하나? 글꼴, 색상, 탐색 등을 내가 통제할 수 있음. 브라우저는 전달 수단이지 읽기 환경이 아님. 그렇게 취급하는 건 습관이지 필수가 아님
오래전부터 세 단어보다 긴 것은 편집기 밖에서 쓰지 않게 됐음. 맞춤법 검사, 동의어 사전, 어원 조회, 번역, 내 모든 노트 접근, LLM 연동까지 이미 필요한 게 다 있음. 언젠가 시도해 보면 엄청나게 해방감을 느낄 것임. 그러면 긴 글을 브라우저에서 읽는 것도 그만둘 수 있음
Medium은 글쓴이에게 돈을 지급하려는 꽤 진지한 시도를 해왔음. Substack과는 다른 모델이지만, 그게 이유임
신문 유료 장벽을 보는 방식과 비슷하게 봄. 마음에 들지는 않지만 왜 있는지는 이해함
가장 그럴듯한 추측은 관성임. 어떤 사람들은 브랜드 충성도가 매우 강하고, 남들이 무엇을 어떻게 하는지에 맞춰 움직여야 함
실제로는 어디에 게시됐는지는 중요하지 않고 URL만 주면 되지만, 모두가 그렇게 행동하지는 않음
글쓴이 친화적인 블로그 플랫폼의 최신 진화처럼 보임. WordPress보다 뉴스레터 형태로 묶기 쉽고, 유료 티어로 수익화하기도 더 쉬움
Medium 대체 프론트엔드인 Scribe를 써보면 훨씬 나음:
https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...
https://sr.ht/~edwardloveall/Scribe/
https://libredirect.github.io/
Python은 Rust보다 훨씬 성숙한 생태계를 갖고 있고, 특히 AI/머신러닝 쪽에서 그렇음
특정 머신러닝 알고리즘을 구현한다고 주장하는 Rust 크레이트를 만났는데 제대로 동작하지 않았음. 그래도 Claude로 대체 구현을 작성할 수는 있었음
AI와 함께라면 타입 시스템 수준에서 정확성을 강제하는 게 좋은 생각이라고 봐서, Python보다 C#이나 Rust 같은 언어를 자주 고름. 다만 어떤 일에는 Python이 분명 맞는 도구임
Rust를 쓸 수도 있었지만, 결과물이 잘되면 다른 사람들은 하나의 도구 체인을 쓰는 데서 더 큰 가치를 얻을 테니 Go가 맞다고 느꼈음
핵심 이유는 필요할 때 읽을 수 있어야 한다는 것임. 그리고 받는 쪽 생태계가 기대하는 언어가 있음. 일부 데이터 과학 커뮤니티가 R, MatLab, Julia, Python, Mojo를 고르는 것도 기술적으로 무엇이 우월한지가 아니라 동료들이 무엇을 쓰는지에 달려 있음
추측이지만, 타입 언어는 더 빠르고 좋은 언어 서버를 갖는 경우가 많아서 도구 사용으로 코드를 더 효율적으로 수정할 수 있음
사람이 직접 끼어들어 코드를 조사하거나 수정해야 할 때도, 강한 타입 덕분에 스파게티 코드 안에서 훨씬 쉽게 방향을 잡을 수 있음
그러면 가비지 컬렉션과 강한 타입의 장점을 얻을 수 있음
지금으로서는 사람이 직접 작성할 때 Python을 쓰는 이유와 정확히 같음. Zig 같은 언어보다 Python을 아는 사람이 더 많아서, 사람이 코드를 더 쉽게 읽고 수정할 수 있기 때문임
글의 요지는 이해하지만, 아직 그 단계까지는 아니라고 봄
“팀의 아무도 모르는 언어로 출시된 앱”이라니 좋음. 그리 멀지 않은 미래에 이 일을 되돌아보게 될 것임
“Anthropic 연구원 Nicholas Carlini가 16개의 병렬 Claude 에이전트를 조율해 Rust로 프로덕션 C 컴파일러를 작성했다”는 건 사실이 아님
그 컴파일러는 gcc/clang보다 훨씬 열등한 코드를 생성해서 사실상 쓸모없음