C 언어로 현대적인 웹 앱을 만들었다
A Modern Web App in C
Corey Prophitt는 2026년에 C 언어와 CGI를 사용해 상용 웹 제품 marketyour.games를 출시했다. BCHS 스택(OpenBSD, C, httpd, SQLite)과 libcurl, libsodium, libcjson만으로 단일 바이너리를 만들었고, 모든 요청이 새 프로세스를 생성한다. 그는 프레임워크 대신 기본기에 집중하고, 공급망 위험을 최소화하며, SQLite의 단순함을 강조한다. CGI는 2004년에 표준화된 이후 변하지 않았지만, 오늘날에도 충분히 실용적이라고 주장한다.
CGI는 서버리스와 비슷하다: 슈퍼바이저가 요청마다 코드를 호출하고, 환경 변수 묶음을 건네주고, 결과를 수집한다. CGI는 벤더(그리고 예상치 못한 청구서)만 뺀 서버리스다.
HN 토론
135- dorongrinstein
많은 도구들이 같은 일을 해낼 수 있다. 나는 연필, 펜, 크레파스 등으로 메모를 쓸 수 있다. 비밀을 하나 알려주겠다, 아무에게도 말하지 말라: 어셈블리로도 쓸 수 있다.
- ramses0
내가 가장 좋아하는 잡학은 busybox에 내장된 cgi-bin 지원이 있다는 것이다 (그리고 `rclone serve webdav`도 언급하지 않은 게 아쉽다). `https://elixir.bootlin.com/busybox/1.37.0/source/networking/...`
이 글에서 언급된 모든 것은 100% 사실이고 잘 이치에 맞다, 특히 권한을 낮추기 위한 pledge/chroot/etc.의 포함이 그렇다.
두 가지 정반대의 배포 메커니즘이 있다:
1) 서로 위에 끈적한 것들을 탑처럼 쌓아 올려서, 원격 컴퓨트에서 실행되는 하이퍼바이저 아래 k8s 클러스터의 일부로 proxmox 서버 안의 vm 안의 docker 컨테이너 위에서 간단한 `echo "hello world"`를 실행하게 될 때까지...
2) 그냥 `bash -c 'echo "hello world"'`를 실행하고 CGI로 프론트하면 된다 (상태 없음, 단일 바이너리, 어쩌고저쩌고...)
https://github.com/Domain/bash.cgi 를 한번 보라... 'busybox 위의 bash를 cgi-bin으로'가 '올바른 아키텍처'라고 제안하는 건 아니고, 거의 진정한 '프레임워크 없음'에 이르지 못하게 막는 코드의 양이 아주 적고 이치에 맞게 이해하기 쉽다는 걸 보여주려는 것이다.
내가 직장에서 하는 일부 내부 툴링에서 나는 다음과 같은 쪽으로 기울고 있다:
some-cmd [--json|--markdown] ...yet-more-args...
프로세스와 셸 환경 자체를 repl로 사용하기 시작하면 `[--cgi-bin]`이 '그냥' 또 다른 출력 타입이 되는 쪽으로 흘러가게 되고, 당신의 명령이 독립적이고 재현 가능하며 입력 인자에만 의존하도록 보장하는 능력(아니, 선견지명!)은 당신을 곧바로 '적대적인' 환경에서도 실행 가능하게 만든다 ( […]
- OleksandrC
이상한 웹 애플리케이션에 흥미를 느끼는 사람들을 위해, 나는 C++로 게임 프로젝트를 진행해 왔는데, 클라이언트는 Emscripten으로 WebAssembly로 컴파일되고, 애플리케이션 서버도 C++로 구현되어 있다 (nginx 뒤에).
이것도 AI 이전 시대의 것이다. 게임은 문명 같은 것이다. 처음부터 만든 커스텀 엔진 (3D 부분과 모든 웹 처리도 포함).
한번 보라: https://statebuilder.com/
- assimpleaspossi
나는 22년 전에 내가 소유한 레스토랑을 위한 온라인 메뉴 주문 시스템을 개발한 후 웹 개발 회사를 시작했다. 나는, 그리고 그 다음에는 우리가, 글에서 말한 것과 거의 같은 일을 했지만 fastcgi를 사용했다. 나는 C를 알았기 때문에 C로 시작했다. 그게 내 진짜 직업이었다. 그것은 너무 잘 돌아가서, 프랜차이즈가 내게서 소프트웨어를 사들였고--그리고 나서 그것을 모든 마이크로소프트 것들로 전락시켰고 그때부터 문제에 문제가 이어졌다. 그건 또 다른 이야기다.
나는 온라인 주문이 필요한 다른 업장들, 예를 들어 극단과 레스토랑을 위해 사이트를 계속 만들었다. 모두 C, fastcgi, FreeBSD, postgresql 그리고 h2o-server로, 왜냐하면 그것은 항상 다른 사람의 규칙에 굽히지 않고 우리가 원하는 것을 해냈기 때문이다. 그것은 빠르고, 우리를 위해 또는 우리의 동의 없이 변경이 이루어지지 않는 동안 변경하기 쉬웠다. 우리는 스스로 아주 잘 해냈다.
- unixholder
복잡한 웹 기술과 프레임워크로 깊이 들어갈수록, 단순함이 이긴다는 것이 더 명백해진다.
- benlivengood
Golang도 단일 바이너리에서 웹 사이트나 서비스를 제공하는 것을 가능하게 한다. 코어 Go에 머물면 (CGO_ENABLED=0) libc를 링크하는 것을 피할 수도 있고, 전통적인 웹 서버 (nginx, apache, httpd)를 대체하는 데 필요한 모든 http와 tls 라이브러리를 함께 제공한다.
나는 C를 사랑하고 과거에 C로 몇몇 CGI를 작성했지만, C에서의 동시성 프로그래밍은 좋아하지 않는다. fork와 exec는 .text 세그먼트에 공유 읽기 전용 mmap을 사용할 수 있지만, .bss와 .data는 초기화와 복사가 필요하다; 스레드 프로세스가 피하는 불가피한 시작 오버헤드가 있고, 순수 pthreads는 다소 고통스럽다. 저트래픽 사이트를 제공하기만 하면 된다면 CGI로 충분하다.
내 가장 큰 걱정은 SQLite DB가 얼마나 자주 백업되는가일 것이다, 왜냐하면 오늘날 세상에서 C 웹 서버가 RCE에서 자유로울 방법이 없기 때문이다.
- Levitating
CGI는 훌륭하다. 안타깝게도 nginx는 lighttpd와 달리 그것을 기본적으로 지원하지 않는다.
나는 nginx에 CGI를 추가하는 이 프로젝트를 좋아한다: https://github.com/pjincz/nginx-cgi
passenger[1]를 통해 nginx에서 직접 Rack 애플리케이션을 시작하는 방법도 있다. Rack은 ruby 웹앱을 위한 CGI 같은 인터페이스이다: https://github.com/rack/rack
그것은 몇 줄의 ruby로 애플리케이션과 미들웨어를 작성하는 것을 쉽게 허용한다.
[1]: https://www.phusionpassenger.com/documentation/Users%20guide...
- creatonez
CGI 프로세스가 매 요청마다 SQLite 데이터베이스를 여는 건가...? 그건 가장 미친 경합을 초래할 것이다.