모든 페이지에 동일한 헤더, 내비게이션, 푸터가 필요했지만 공유할 방법이 없었다는 말은 완전히 맞지 않음
웹서버에는 Server Side Includes(SSI) 기능이 있었고, 그걸 쓰기 싫다면 단순히 cat header body > file 명령으로도 해결 가능했음
관련 문서: NCSA SSI 튜토리얼 (1997)
HTML은 원래 SGML 기반 어휘로 만들어졌기 때문에, SGML과 XML에는 공통 헤더나 푸터 같은 문서 조각을 참조할 수 있는 엔티티/텍스트 매크로 기능이 있었음
아마 원 댓글은 순수 HTML만을 기준으로 말한 것 같음
글의 마지막이 “...그리고 그 모든 과정 속에서도, 겸손한 <br> 태그는 여전히 제 역할을 하고 있음” 같은 문장으로 끝났으면 좋겠다는 생각이 들었음
예전에 일했던 회사에서는 배포할 때마다 새 폴더를 만들고, 심볼릭 링크를 최신 버전으로 바꾸는 시스템을 썼음
수동이긴 했지만, 각 서버에서 원자적 전환이 가능하고 롤백도 쉬워서 정말 우아한 방식이라 느꼈음
이전에는 수십 대 서버에 수작업으로 파일을 복사하고 10~20단계 명령을 직접 실행해야 했는데, 그에 비하면 훨씬 안전하고 단순했음
나중에 자동화 도구를 써봤지만, 설정이 복잡하고 불투명해서 오히려 더 취약한 배포 프로세스였음
“CGI 스크립트를 쓰려면 Perl이나 C를 배워야 했다”는 말이 있는데, 정말 수백 줄이 필요했을까 의문이었음
실제로는 간단한 C 함수로도 URL 파라미터를 읽을 수 있음
나는 최근에 순수 C로 설문 웹사이트를 만들었는데, 예전에 만든 HTML 생성 라이브러리 덕분에 꽤 수월했음
OS의 CGI 라이브러리를 리팩터링해 쓰고, SQLite를 정적으로 링크해서 단일 바이너리로 배포했음
웹서버 없이도 stdin/stdout으로 테스트 가능했음
결론적으로 CRUD 웹사이트는 C로도 충분히 쉽고, HTML은 트리 구조이므로 문자열 보간(string interpolation) 은 잘못된 접근이라는 생각임
코드가 <param>으로 끝나는 첫 번째 파라미터를 매칭하기 때문에 정확히 일치하지 않을 수 있고, 퍼센트 인코딩도 처리하지 않음
HTML이 트리 구조를 표현한다는 점에서 문자열 보간은 부적절하다는 말에 공감함
그런데 30년이 지난 지금도 여전히 문자열 보간이 가장 흔한 도구처럼 느껴짐
정말 포괄적이고 잘 쓴 글이었음
저자는 낙관적이지만, 나는 웹 개발이 임시방편의 누적으로 이루어진 불안정한 탑처럼 보임
웹 표준화가 소수 브라우저 벤더에게 장악되면서, 근본 문제를 해결하지 않고 덧칠만 해온 결과라고 생각함
최근의 생성형 AI 도구들도 이런 복잡성을 우회하기 위한 임시 해결책일 뿐임
결국 이 탑은 언젠가 무너질 것이라 봄
이 글은 아마 고전으로 남을 기사가 될 것 같음
요즘 개발자들이 놓친 웹 기술의 역사를 간결하게 담고 있음
“Virtual private servers changed this…” 부분을 읽으며 떠올랐음
사실 최초의 VPS 제공자는 2001년경 JohnCompanies였고, FreeBSD jail을 기반으로 했음
고객들은 원격 백업을 원했고, rsync를 선호했음
그래서 4년 뒤 나는 rsync.net 도메인을 등록했음 (rsync/samba 저자들에게 허락받았음)
1998년부터 2012년까지 웹 개발을 했는데, 이 글을 읽으며 추억 여행을 한 기분이었음
그 이후의 변화를 한눈에 볼 수 있는 요약이기도 함
글의 내용이 내가 기억하는 웹 기술의 흐름과 거의 일치함
PHP 이전의 CGI는 번거롭긴 했지만, mod_perl과 FastCGI 덕분에 쓸 만했음
컴파일 언어로 CGI를 짜는 건 거의 마조히즘에 가까웠고, PHP는 그런 점에서 가볍고 재미있었음
나는 jQuery가 뜨기 직전 프런트엔드 개발을 그만뒀음
정말 놀라운 글이었음
단순히 기술 연대기를 나열한 게 아니라, 각 시대의 시대정신(zeitgeist) 을 생생하게 전달함
보통은 구전으로만 전해지는 인간적인 맥락을 글로 담아낸 점이 인상적이었음
“왜 이렇게 복잡한 클라우드 세상이 되었나”를 비판하기보다, 각 시점의 합리적 선택들이 누적된 역사적 결과로 이해하게 해줌
인간사의 아이러니를 기술사 속에서 느낄 수 있었음
Hacker News 의견들
모든 페이지에 동일한 헤더, 내비게이션, 푸터가 필요했지만 공유할 방법이 없었다는 말은 완전히 맞지 않음
웹서버에는 Server Side Includes(SSI) 기능이 있었고, 그걸 쓰기 싫다면 단순히
cat header body > file명령으로도 해결 가능했음관련 문서: NCSA SSI 튜토리얼 (1997)
글의 마지막이 “...그리고 그 모든 과정 속에서도, 겸손한
<br>태그는 여전히 제 역할을 하고 있음” 같은 문장으로 끝났으면 좋겠다는 생각이 들었음예전에 일했던 회사에서는 배포할 때마다 새 폴더를 만들고, 심볼릭 링크를 최신 버전으로 바꾸는 시스템을 썼음
수동이긴 했지만, 각 서버에서 원자적 전환이 가능하고 롤백도 쉬워서 정말 우아한 방식이라 느꼈음
이전에는 수십 대 서버에 수작업으로 파일을 복사하고 10~20단계 명령을 직접 실행해야 했는데, 그에 비하면 훨씬 안전하고 단순했음
나중에 자동화 도구를 써봤지만, 설정이 복잡하고 불투명해서 오히려 더 취약한 배포 프로세스였음
“CGI 스크립트를 쓰려면 Perl이나 C를 배워야 했다”는 말이 있는데, 정말 수백 줄이 필요했을까 의문이었음
실제로는 간단한 C 함수로도 URL 파라미터를 읽을 수 있음
나는 최근에 순수 C로 설문 웹사이트를 만들었는데, 예전에 만든 HTML 생성 라이브러리 덕분에 꽤 수월했음
OS의 CGI 라이브러리를 리팩터링해 쓰고, SQLite를 정적으로 링크해서 단일 바이너리로 배포했음
웹서버 없이도 stdin/stdout으로 테스트 가능했음
결론적으로 CRUD 웹사이트는 C로도 충분히 쉽고, HTML은 트리 구조이므로 문자열 보간(string interpolation) 은 잘못된 접근이라는 생각임
<param>으로 끝나는 첫 번째 파라미터를 매칭하기 때문에 정확히 일치하지 않을 수 있고, 퍼센트 인코딩도 처리하지 않음그런데 30년이 지난 지금도 여전히 문자열 보간이 가장 흔한 도구처럼 느껴짐
정말 포괄적이고 잘 쓴 글이었음
저자는 낙관적이지만, 나는 웹 개발이 임시방편의 누적으로 이루어진 불안정한 탑처럼 보임
웹 표준화가 소수 브라우저 벤더에게 장악되면서, 근본 문제를 해결하지 않고 덧칠만 해온 결과라고 생각함
최근의 생성형 AI 도구들도 이런 복잡성을 우회하기 위한 임시 해결책일 뿐임
결국 이 탑은 언젠가 무너질 것이라 봄
이 글은 아마 고전으로 남을 기사가 될 것 같음
요즘 개발자들이 놓친 웹 기술의 역사를 간결하게 담고 있음
“Virtual private servers changed this…” 부분을 읽으며 떠올랐음
사실 최초의 VPS 제공자는 2001년경 JohnCompanies였고, FreeBSD jail을 기반으로 했음
고객들은 원격 백업을 원했고, rsync를 선호했음
그래서 4년 뒤 나는
rsync.net도메인을 등록했음 (rsync/samba 저자들에게 허락받았음)1998년부터 2012년까지 웹 개발을 했는데, 이 글을 읽으며 추억 여행을 한 기분이었음
그 이후의 변화를 한눈에 볼 수 있는 요약이기도 함
글의 내용이 내가 기억하는 웹 기술의 흐름과 거의 일치함
PHP 이전의 CGI는 번거롭긴 했지만, mod_perl과 FastCGI 덕분에 쓸 만했음
컴파일 언어로 CGI를 짜는 건 거의 마조히즘에 가까웠고, PHP는 그런 점에서 가볍고 재미있었음
나는 jQuery가 뜨기 직전 프런트엔드 개발을 그만뒀음
정말 놀라운 글이었음
단순히 기술 연대기를 나열한 게 아니라, 각 시대의 시대정신(zeitgeist) 을 생생하게 전달함
보통은 구전으로만 전해지는 인간적인 맥락을 글로 담아낸 점이 인상적이었음
“왜 이렇게 복잡한 클라우드 세상이 되었나”를 비판하기보다, 각 시점의 합리적 선택들이 누적된 역사적 결과로 이해하게 해줌
인간사의 아이러니를 기술사 속에서 느낄 수 있었음