요약
딜샨 자야코디가 어셈블러와 링커 없이 실행 파일을 바로 만드는 Flash C 컴파일러와 IDE를 공개했습니다.
에이다프루트 블로그가 개발자 자야코디의 블로그 글을 짧게 소개했습니다. x86-64 리눅스용 C89 컴파일러와, 볼랜드 Turbo C++를 닮은 텍스트 화면 IDE(통합 개발 환경)를 처음부터 새로 짰다고 합니다.
왜 중요한가
- 어셈블러, 링커, 시스템 C 라이브러리에 기대지 않아 컴파일러 하나만 있으면 실행 파일이 나옵니다.
- 옛 Turbo C 방식의 전체 화면 개발 환경과 디버거를 지금의 리눅스에서 다시 쓸 수 있게 됩니다.
핵심 내용
- 컴파일러 fcc는 C 소스를 읽어 정적 ELF 실행 파일(외부 라이브러리 없이 혼자 도는 리눅스 실행 파일)을 바로 씁니다.
- 런타임 라이브러리도 Flash C로 짜서 컴파일러에 넣었고, main에서 실제로 호출되는 함수만 결과물에 담습니다.
- 최적화는 48개 패스(코드를 한 차례씩 훑어 고치는 단계)로 나뉘며, 하나하나 켜고 끌 수 있습니다.
- IDE인 fc는 풀다운 메뉴, 겹쳐 띄우는 편집 창, ptrace 기반 소스 수준 디버거, 하이퍼링크 도움말을 갖췄습니다.
- 메뉴 순서와 오류 문구는 Turbo C++ 3.1 실행 파일을 분석해 맞췄고, 원래 코드나 리소스는 쓰지 않았다고 밝혔습니다.
HN 반응
- 커밋과 문서가 모두 Claude로 작성됐다는 지적과 함께, 직접 짜며 배울 장난감 컴파일러를 AI에 맡기면 의미가 없다는 비판이 이어졌습니다.
- AI가 짠 코드를 '처음부터 새로 짰다'고 소개해도 되느냐를 두고 찬반 논쟁이 길었고, 링커가 없어 외부 라이브러리를 못 쓴다는 아쉬움도 나왔습니다.
GitHub 페이지를 봤는데 역시나 바이브 코딩이네요. 이런 프로젝트는 원래 Crenshaw의 "Let's Build a Compiler" 시리즈 같은 걸 읽어 가며 몇 달 동안 공부 삼아 만들어 보는 거잖아요. 그걸 바이브 코딩으로 하는 이유를 모르겠습니다. 결국 아무도 안 쓸 장난감 컴파일러가 나올 뿐이고, 컴파일러가 어떻게 돌아가는지는 하나도 못 배우니까요. 의미가 없어요.
동감합니다. 저는 'Writing a C Compiler' 책을 따라 하면서 (Zig로 했습니다) 많이 배우고 재미도 있었습니다. 이걸 AI한테 시키는 건 의미가 없습니다.
이걸 구현해 보면 개발자 도구를 바이브 코딩하는 방법을 꽤 배울 것 같은데, 의미가 없다고까지 할 수 있나요? 흥미로운 실험 같습니다.
특히 코딩 에이전트가 더 읽기 좋은 코드와 더 나은 문서를 만들어 내게 하는 방법을 실험해 보고 싶습니다. 코드를 어느 정도 읽기 좋게 만들 수는 있지만, 아직 제대로 풀지는 못했습니다.
바이브 코딩이라는 건 사람이 코드를 들여다보지 않았다는 뜻인데, 그게 사실인지 어떻게 아시죠?
LLM의 도움을 받아 만든 코드베이스는 쉽게 알아볼 수 있습니다. 하지만 사람이 코드에 전혀 관심을 두지 않았는지는, LLM에 프롬프트를 넣은 당사자와 얘기해 보지 않고서는 알기 어렵습니다.
컴파일러 소개 블로그 글도 AI가 썼고, GitHub 저장소의 README도 AI가 썼고, 문서 전부를 AI가 썼고, Borland Turbo C++ 리버스 엔지니어링 분석도 AI가 썼고, 코드 주석도 전부 AI가 썼고, 저장소의 커밋은 하나도 빠짐없이 Claude가 했습니다. 작성자가 코드에 진지하게 관심을 가졌다고 하기엔 무리가 있다고 봅니다. Claude에게 커밋을 시키기 전에 훑어봤을 수는 있겠지만, 그걸로는 장난감 컴파일러를 직접 만들 때만큼 얻는 게 없습니다.
알기 어렵지 않아요. 바이브 코딩이 LLM 코딩의 기본 방식이니까, 반대 증거가 없으면 그렇다고 보면 됩니다.
chibicc에서 파생된 게 분명합니다. 테스트 스위트가 좀 허술해서, 이걸로 뭔가 많이 컴파일시킬 생각은 들지 않네요. 제가 만든 소규모 C 컴파일러 비교표에 추가할지도 모르겠습니다.
정말 멋지네요, 한번 써 봐야겠어요. 저는 QuickBASIC으로 시작해서 Turbo Pascal, 나중엔 Turbo C로 컸습니다. 요즘처럼 에이전트가 점점 판치는 세상에서 머리를 식히려고 수학 문제를 풀거나 손으로 직접 짜는 개인 프로젝트를 할 때는, fpc 컴파일러에 들어 있는 텍스트 모드 Free Pascal IDE를 쓰고 있습니다. Borland의 TurboVision DOS TUI 라이브러리를 오픈소스로 구현한 거죠. 이게 Turbo C 에뮬레이션 모드도 있었으면 하고 늘 바랐어요.
fcc에서 아쉬운 건 링커가 없어서 외부 라이브러리를 쓸 수 없다는 점뿐입니다. 그래서 프로젝트 안에 직접 포함시킬 수 있는 것만 쓸 수 있는데, 정말 C89를 준수한다면 여러 용도로 쓸 만한 단일 헤더 라이브러리가 많이 있습니다.
한번 살펴봐야겠어요!
이 얄팍한 광고가 페이지를 보여 주기 전에 내 컴퓨터에서 돌리겠다는 그 개똥 같은 악성코드를 화이트리스트에 올려 줄 생각은 없습니다. 누가 요약 좀 해 주실래요?
또 하나의 바이브 코딩 컴파일러입니다.
Adafruit 글은 작성자의 블로그 글을 LLM이 요약한 거고, 그 블로그 글은 Claude로 바이브 코딩한 프로젝트를 LLM이 요약한 거예요. 신호 대 잡음비가 기하급수적으로 떨어지고 있습니다.
아, 젠장. 저는 Nils Holm의 C 부분집합 컴파일러 책을 읽고 있어서 이게 괜찮은 보충 자료가 되길 바랐는데요. 휴지통행입니다.
https://github.com/fosslinux/live-bootstrap
찾으시는 게 여기 있을지도 모릅니다. 단계와 사용한 도구는 "parts.rst" 파일에 나와 있습니다.
코드를 한 줄도 직접 쓰지 않았으면서 왜 다들 LLM이 만든 코드를 "처음부터 작성했다"고 하는 거죠? 처음부터 쓰인 건 맞죠, 당신이 쓴 게 아닐 뿐이지!!
이런 프로젝트는 프로그래머 사회의 명예를 더럽히고 있습니다.
ArtCraft도 전부 처음부터 작성했다고 하던데요.
ArtCraft는 거짓말을 합니다. 크레이트를 잔뜩 쓰는데, 제 생각에 그러면 "처음부터"라는 주장은 성립하지 않아요. 처음부터 만드는 이유는 컴파일된 바이너리 안의 모든 코드 한 줄 한 줄을 완전히 통제하기 위해서잖아요.
https://github.com/rfgplk/micron.cpp
이게 진짜 "처음부터 구현"한 예입니다 (freestanding 컴파일 옵션을 대상으로 할 때 기준이고, hosted는 스레딩에 아직 pthread에 의존합니다). 명시한 저장소 밖의 외부 코드나 참조는 전혀 없습니다. (컴파일러 내장 기능이나 include조차 필요 없습니다.) 원하는 곳에 끌어다 놓고 컴파일 누르면 끝입니다.
"처음부터 작성했다"는 건 뭔가를 만들 때 외부 코드나 기존 라이브러리를 쓰지 않았다는 뜻일 뿐입니다. 요즘은 코드나 크레이트 같은 걸 재사용하는 것보다 이쪽이 낫습니다. a) 공급망 공격을 피할 수 있고, b) 구현이 대체로 대안보다 더 정확하고 성능도 좋으며, c) 기존 라이브러리를 받아서 프로젝트에 억지로 끼워 맞추는 것보다 직접 만드는 게 사실 더 쉽기 때문입니다.
그게 왜 중요하죠? 솔직히 이제는 최전선 모델을 썼다면 평균적인 코드베이스를 AI 이전의 평균적인 코드베이스보다 더 신뢰할 것 같습니다.
뛰어난 개발팀이 지금의 최전선 LLM 코드보다도 좋은 품질을 내는 예외도 있습니다. SQLite가 떠오르네요. 하지만 그게 상위 0.x%라는 건 잊기 쉽습니다.
그 댓글은 품질을 말하는 게 아니라, (홍보에 쓰인) "처음부터"라는 부분을 말하는 거잖아요.
근데 그게 맞는 말 아닌가요? 뭔가를 기반으로 한 것 같지도 않은데, 제가 놓친 게 있나요?
아니면 "애플파이를 만들려면 먼저 우주를 창조해야 한다" 같은 얘기인가요? 그것도 저한테는 말이 안 되는데요.
셰프를 집으로 불러서 처음부터 파이를 만들게 했다면, 그 파이를 친구들과 나눠 먹으면서 내가 처음부터 만들었다고 하시겠어요?
아니요, 안 하겠죠. 하지만 여기서 일어난 일은 그게 아닙니다. 빵 만드는 로봇에 재료를 넣고 빵이 나왔다면, 대부분은 빵을 처음부터 만들었다고 말하는 데 거리낌이 없을 거예요. 마찬가지로 사람들은 "빨래했다", "설거지했다"고 말하지만, 실제 일은 대개 세탁기와 식기세척기가 하죠.
마찬가지로 프로그램 매니저가 코드를 한 줄도 기여하지 않았어도 "우리가 X를 처음부터 만들었다"고 말하는 건 자유입니다. 이번에는 다른 사람이 끼지 않았으니 '우리'가 '나'로 바뀌었을 뿐이고요.
(대부분은 빵을 처음부터 만들었다고 말하는 데 거리낌이 없을 것)
빵이라면 괜찮죠. 하지만 코드를 예술에 더 가깝게 보는 사람들은 "처음부터"라고 하면 직접 코드를 쓴다는 뜻이라는 선입견이 있습니다.
어떤 사람들은 문제를 해결하려고 코드를 짜고, 어떻게 해결되는지는 신경 쓰지 않습니다. AI를 쓰는 데 거리낌이 없고 다른 방식은 구시대적이라고 봅니다. 그건 그 사람들 일이니 계속 그러시면 됩니다.
저한테는 과정이 더 중요합니다.
"손으로" 코드를 짤 수 있다는 것이 제 자부심과 성취감을 채워 줍니다. 아무나 할 수 있는 게 아닌 걸 내가 할 수 있다는 걸 아는 거죠. 버튼을 누르거나 AI에게 프롬프트를 넣는 건 저한테는 같지 않고, 프로젝트 매니저에 더 가까운데 저는 절대 그게 되고 싶지 않습니다.
반AI 진영을 깎아내리는 사람들은 사람마다 코딩하는 이유가 다르고, 어느 쪽이 더 옳고 그른 게 아니라는 걸 이해하지 못하는 겁니다.
사람이 코드를 어떤 이유로 쓰든 그건 타당하다는 데 동의합니다.
코드가 예술일 수 있듯 요리도 예술일 수 있습니다. 그래서 코드가 그 점에서 베이킹과 본질적으로 다르다는 구분에는 동의하지 않습니다.
"처음부터"와 "손으로"는 제 생각에 서로 바꿔 쓸 수 있는 말이 아닙니다. "손으로"는 과정에 대한 말이고, "처음부터"는 시작하기 전의 상태에 대한 말이지 과정에 대한 말이 아니니까요.
이 맥락에서는 서로 바꿔 쓸 수 있다고 생각하고, 실제로 많은 사람이 그렇게 바꿔 씁니다. 당신이 동의하든 안 하든요.
의견이 다른 건 괜찮습니다. 당신이 "틀렸다"고 생각하지 않고, 제가 "옳다"고 생각하지도 않아요. 그냥 관점도 단어의 정의도 서로 다른 것이고, 그래도 괜찮습니다.
더 중요한 건 말하는 사람의 의도를 이해하는 것이지, 논쟁에서 이기려고 애쓰는 게 아니라고 생각합니다. 그건 어차피 대화와 주제를 엉뚱한 데로 끌고 가니까요. 그리고 이 맥락에서 제가 "손으로"와 "처음부터"라는 말로 전하려던 건 LLM을 쓰지 않고 코딩한다는 개념뿐이었습니다.
더 적절한 비유는 냉동 포장 파이를 데워 놓고 처음부터 만들었다고 말하는 겁니다. 물론 사 온 건 _당신_이지만, 어딘가에서 재료가 조합됐고 "처음부터" 만들어졌으니까요.
제 기억으로는 적어도 Hallmark 로맨틱 코미디 영화 하나의 줄거리가 그렇습니다. (-:
바이브 코딩에 대한 댓글들이 재밌네요.
소프트웨어로 먹고사는 사람은 거의 다 AI를 쓰고 있습니다. 이런 댓글을 다는 순간 최근 기술 현장과 연이 없다는 게 들통나는 겁니다.
아무리 향수에 젖고 희망 사항을 늘어놔도 현실을 이길 순 없습니다.
컴파일러 소스가 500kB인데 그 절반이 옵티마이저입니다. 여기에 바이브 코딩으로 만든 새 문법을 얹는 기반으로 쓰기 좋지 않을까요? 먼저 Zig나 Rust로 옮기고요?
멋지긴 한데, 추세는 지켜볼 필요가 있습니다. 이렇게 AI 코딩이 대세라면 (사실이라면요) 일부는 이미 곧바로 어셈블리로 가고 있으니까요.