#
태그로 돌아본 웹의 30년 > Clean Markdown view of GeekNews topic #25130. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25130](https://news.hada.io/topic?id=25130) - GeekNews Markdown: [https://news.hada.io/topic/25130.md](https://news.hada.io/topic/25130.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-12-17T08:02:41+09:00 - Updated: 2025-12-17T08:02:41+09:00 - Original source: [artmann.co](https://www.artmann.co/articles/30-years-of-br-tags) - Points: 28 - Comments: 7 ## Summary 웹의 30년은 **복잡성을 대가로 한 대중화의 역사**로 요약됩니다. 1990년대 `<br>` 태그와 FTP로 시작된 정적 웹은 PHP·MySQL을 거쳐 누구나 사이트를 만들 수 있는 플랫폼으로 확장되었고, React·Docker·TypeScript를 지나며 완전한 애플리케이션 환경으로 진화했습니다. 이제 **ChatGPT와 Copilot**이 코드 작성 방식을 바꾸며, 개발자는 구현보다 문제 정의와 방향 설정에 집중하는 시대를 맞이했습니다. AI가 결합된 오늘의 웹은 다시 한 번 “누구나 만들 수 있다”는 초창기 약속을 새로운 형태로 실현하고 있습니다. AI시대에 **새로 개발을 접하게 된 사람들**에게 한번 보여주면 좋을 **지난 30년의 기록** 글입니다. ## Topic Body - 1990년대 정적 웹부터 2010년대 JavaScript 중심 웹, 2020년대 AI 시대의 웹까지의 변화를 따라가며, 웹 개발이 어떻게 **진화**해왔는지 정리한 글 - `<br>` 태그와 FTP로 시작한 웹은 PHP·MySQL을 거치며 **누구나 만들 수 있는 플랫폼**으로 빠르게 확장됨 - 2000년대 Rails, Git, Heroku를 기점으로 웹 개발은 **구조화·자동화·협업 중심 산업**으로 재편되며 클라우드와 모바일 시대의 기반을 마련 - 2010년대 React와 빌드 체인, Docker, Node 생태계의 등장은 웹을 문서가 아닌 **본격적인 애플리케이션 플랫폼**으로 고정시킴 - 2020년대에는 **ChatGPT와 Copilot**이 코드 작성 방식을 바꾸며, AI가 개발 생산성을 증폭시키는 새로운 전환점이 됨 - 이 모든 변화는 복잡성을 대가로 삼아, 더 많은 사람이 더 큰 것을 만들 수 있게 만드는 **웹의 대중화 과정**으로 이어짐 --- ### The Static Web - 정적 웹의 시대 > "View Source was how you learned" - **1990년대 후반(late 90s)** 웹은 무엇이 될지 아무도 몰랐던 개척지 상태였고, 그 불확실함 자체가 매력으로 작용함 - 개인 웹사이트는 회사나 조직이 아닌 **개인 서버와 폴더 단위**로 시작됨 - Unix 서버 위에 올린 개인 디렉터리, HTML 파일과 FTP 클라이언트만 있으면 인터넷에 공간을 가질 수 있었음 - Notepad 같은 단순한 텍스트 에디터만으로 글을 쓰고 바로 공개 가능 - 이 시기의 웹은 **검열자·승인 절차가 없는 창작 공간**이었음 - 요리, 공룡, 노래 등 관심사 중심의 자유로운 게시 - “이번 주에 관심 있는 것”을 바로 올리는 구조 - 학습 방식은 철저히 **직접 보고 따라 하는 방식**이었음 - YouTube 튜토리얼이나 Stack Overflow는 존재하지 않음 - 다른 사이트가 궁금하면 우클릭 → **View Source** 가 기본 학습 도구 - 더 깊은 내용은 실제 종이책으로 학습 - **Core Java** 같은 수백 페이지 분량의 기술 서적을 옆에 두고, 코드와 책을 번갈아 보며 학습하는 방식이 일반적이었음 - 느렸지만 지식이 오래 남는 학습 경험 - HTML은 구조와 스타일이 뒤섞인 상태였음 - `<table>`, `<font>`, `<center>` 태그가 레이아웃과 스타일을 동시에 담당 - 1x1 투명 GIF(spacer GIF)로 여백을 조정 - 거칠고 비효율적이었지만 **동작은 했음** - **CSS는 존재했지만 사실상 주류가 아니었음** - 대부분의 스타일은 인라인 속성이나 HTML 태그 자체로 처리 - 레이아웃은 중첩 테이블로 해결 - 동적인 기능은 극도로 높은 진입 장벽을 가짐 - 방명록, 방문자 카운터 같은 기본 기능도 **CGI 스크립트** 필요 - Perl이나 C로 작성해야 했고, URL 파라미터 하나 처리하는 데도 많은 코드가 필요 - 이 복잡성이 동적 웹의 확산을 강하게 제한함 - 공통 레이아웃 문제는 해결책이 거의 없었음 - 헤더·네비게이션·푸터를 모든 HTML 파일에 복사/붙여넣기 - 변경 시 전체 파일 수정 필요 - `<iframe>` 으로 공통 요소를 삽입하는 방식도 있었으나 부작용이 큼 - 브라우저 호환성은 이미 심각한 문제였음 - **Netscape Navigator(1994)** 와 **Internet Explorer(1995)** 가 서로 다른 렌더링 결과를 보임 - 특정 브라우저와 해상도를 명시하는 경고 문구가 실제로 필요했음 - 그럼에도 불구하고 이 시대의 웹은 강한 흡인력을 가짐 - 인쇄·방송 장비 없이도 전 세계에 공개 가능 - 웹은 **표현 수단의 대중화**를 처음으로 실현함 - **GeoCities(1994)**, **Angelfire(1996)** 같은 무료 호스팅 서비스가 수백만 명에게 창작 공간 제공 - 웹 링(web ring)을 통해 팬 사이트와 커뮤니티가 연결됨 - 혼란스럽지만 살아 있는 생태계 형성 - 기업에는 아직 “웹 팀”이라는 개념이 거의 없었음 - 웹사이트가 있다면 “컴퓨터를 아는 사람”이 만든 경우가 대부분 -** 웹 개발자가 직업으로 자리 잡기 직전** 단계 - 도구는 원시적이고 사이트는 조악했지만, - **누구나 만들고 공유할 수 있는 공간**이라는 핵심 아이디어가 이 시기에 뿌리내림 - `<br>` 태그와 열정으로 버텨낸 이 시대가 이후 모든 웹 진화의 출발점이 됨 ### LAMP 스택과 Web 2.0 > "Everything was PHP and MySQL" - **2000년 닷컴 버블 붕괴** 이후에도 웹은 계속 성장했고, 이 시기는 무언가를 만들고 싶었던 사람들에게 **진입 장벽이 급격히 낮아진 전환점**이 됨 - 정적 웹 시대의 가장 큰 돌파구는 **PHP(1995)** 였음 - CGI를 위해 C나 Perl로 수백 줄을 작성하던 시대에서, URL 파라미터를 `$_GET['name']` 한 줄로 읽을 수 있는 경험은 결정적 변화였음 - 컴파일, 메모리 관리, 난해한 에러 메시지 없이 저장 후 새로고침만으로 동작 - **XAMPP(2002)** 는 Apache·MySQL·PHP를 한 번에 설치할 수 있게 하며 로컬 개발 환경 구축을 획기적으로 단순화함 - PHP는 정적 웹 시대의 **레이아웃 재사용 문제**를 처음으로 제대로 해결함 - `include 'header.php'` 한 줄로 공통 헤더·푸터 관리 가능 - 한 번의 수정으로 전체 페이지가 바뀌는 경험이 큰 흥분을 불러옴 - 언어적 결함에도 불구하고 PHP의 강점은 **접근성**이었음 - HTML과 로직이 뒤섞이고, 함수 네이밍이 일관되지 않으며, 보안 API가 조악했지만 - 주말에 배워 실제 서비스를 만들 수 있었음 - **공유 호스팅($5/월)** 과 **cPanel(1996)**, **phpMyAdmin(1998)** 이 기본 제공되며 온라인 진입 장벽이 역사상 가장 낮아짐 - PHP와 함께 사실상 한 세트였던 데이터베이스는 **MySQL(1995)** - 거의 모든 튜토리얼·호스팅·CMS가 MySQL을 전제로 구성됨 - 기능적으로는 충분했지만, 국제화 텍스트 처리에서는 고통의 연속이었음 - 기본 인코딩이 **latin1** 이었고, UTF-8을 제대로 쓰려면 - 데이터베이스 설정, 커넥션 인코딩, HTML charset 선언 을 모두 맞춰야 했음 - “ä 대신 ä” 문제는 이 시대를 상징하는 트라우마로 남음 - **WordPress(2003)** 는 웹의 성격 자체를 바꿔놓음 - 코딩을 몰라도 5분 설치 후 바로 게시 가능 - 테마 선택과 글 작성만으로 사이트 운영 가능 - 웹사이트 제작의 **대중화**를 실질적으로 실현 - 비기술 사용자에게 WordPress는 해방이었음 - 블로거, 소상공인, 예술가, 식당까지 누구나 웹사이트를 가질 수 있게 됨 - **“블로거”** 라는 새로운 정체성이 등장 - WordPress 관리 화면이 곧 “웹사이트 편집기”로 인식되는 수준까지 확산 - **개발자에게 WordPress는 거의 만능 도구**가 됨 - 블로그, 포트폴리오, 기업 사이트, 커뮤니티, 전자상거래까지 모두 WordPress - **WooCommerce(2011)** 로 **이커머스**까지 흡수 - 빠른 구현의 대가로 플러그인 난립과 테마 커스터마이징 기반 기술 부채가 누적됨 - 웹의 가능성을 근본적으로 재정의한 사건은 **Gmail(2004)** 출시 - 기존 **Hotmail**, **Yahoo Mail** 이 수 MB 저장공간을 제공하던 시절 - **1GB 무료 저장공간**은 충격적인 수치였음 - “삭제하지 말고 검색하라”는 메시지가 새로운 사용 방식을 제시 - Gmail의 진짜 혁신은 저장공간이 아니라 **경험**이었음 - 페이지 새로고침 없이 메일 읽기·작성·전환이 가능한 인터페이스 - **AJAX(XMLHttpRequest)** 기반 비동기 통신을 전면 활용 - 웹이 문서가 아니라 **애플리케이션**이 될 수 있음을 증명 - **Google Maps(2005)** 는 이 가능성을 한 단계 더 끌어올림 - 클릭과 드래그로 지도를 이동 - 타일을 백그라운드로 로딩하는 자연스러운 인터랙션 - 이 시점에서 **Web 2.0** 이라는 용어가 본격적으로 정착 - 새로고침 없는 UI, 둥근 모서리, 그라데이션, 그림자가 웹의 기본 언어가 됨 - 미디어와 소셜 영역에서도 결정적 변화가 이어짐 - 비디오 영역에서는 **YouTube(2005)** 가 판도를 바꿈 - RealPlayer·QuickTime·Windows Media Player 같은 플러그인 지옥 종료 - Flash 기반이었지만, “클릭하면 바로 재생”되는 경험 제공 - 비디오는 기술 문제가 아닌 **표현 수단**이 됨 - **Twitter(2006)** 는 140자 마이크로블로깅으로 새로운 소통 방식을 제시 - **Facebook(2006)** 이 일반 사용자에게 개방되며 소셜 네트워크가 주류로 이동 - 웹은 소비형 매체에서 **참여형 플랫폼**으로 전환됨 - 누구나 게시자이자 창작자가 될 수 있는 구조 형성 - 이 모든 변화에도 불구하고 **JavaScript는 여전히 고통스러웠음** - 브라우저 간 DOM·이벤트·AJAX 구현 차이와 IE6 호환 문제로 인한 끝없는 디버깅 - **jQuery(2006)** 는 이 혼란을 사실상 종결함 - `$('#el').hide()` 가 모든 브라우저에서 동일하게 동작 - `$.ajax()` 로 비동기 통신 단순화 - 많은 개발자에게 jQuery는 곧 JavaScript 자체였음 - 동시에 브라우저 동작 원리를 직접 이해하지 않게 만드는 완충재 역할도 수행 - 이 시대의 문제들은 나중에야 문제로 인식됨 - SQL Injection, XSS가 튜토리얼 수준에서 만연 - 사용자 입력을 그대로 쿼리에 연결하는 코드가 일반적이었음 - 버전 관리는 **Subversion(2000)** 이 주류 - 커밋은 무겁고 브랜치는 기피 대상 - `final_final_REAL` 같은 폴더명이 일상적 - 실행 환경 표준화 부재 - 로컬은 Windows + XAMPP - 서버는 Linux + 다른 PHP 버전 - “works on my machine” 이 반복됨 - 패키지 매니저 개념도 부재 - JS는 ZIP 다운로드 후 `/js` 폴더에 수동 관리 - PHP 라이브러리는 파일 복사 기반 - 팀 구조와 개발 프로세스는 매우 비공식적이었음 - PM·EM 역할 거의 없음 - 코드 리뷰 없음 - FTP 업로드 후 바로 운영 반영 - 장애 발생 시 프로덕션 서버에서 즉석 수정 - 그럼에도 이 시대의 에너지는 강렬했음 - **PHP와 저렴한 호스팅**으로 **누구나 배포 가능** - **AJAX로 “진짜 앱”을 만들 수 있다**는 감각 확산 - **소셜 플랫폼**으로 누구나 청중을 가질 수 있게 됨 - 웹 개발의 **직업화와 구조화**가 막 시작되는 시점 - **Ruby on Rails(2004)** 가 “Convention over Configuration”으로 더 구조적인 다음 시대를 예고 - 이 시기의 개발자들은 LAMP 스택과 jQuery 플러그인 그리고, - **“다음 큰 서비스를 만들겠다”** 는 기대감 속에서 웹을 만들어가고 있었음 ### 프레임워크 전쟁 > "Rails changed everything, then everyone copied it" - **2000년대 후반(late 2000s)** 웹 애플리케이션 규모가 커지며, 기존의 PHP 스크립트와 수작업 중심 구조가 한계에 도달 - 이 시기의 해법으로 **프레임워크 중심 개발 방식**이 부상했고, 그 흐름을 결정지은 존재가 **Ruby on Rails(2004)** 였음 - RoR의 실제 영향력은 **2007–2008년** 무렵부터 본격화 - “**Convention over Configuration**” 철학으로 파일 구조, 네이밍, 연결 방식을 프레임워크가 대신 결정 - 개발자는 규칙을 따르기만 하면 되었고, 이는 제약이 아니라 속도를 주는 해방으로 인식됨 - Rails는 이후 웹 개발의 기본 문법이 되는 개념들을 한 번에 묶어 제시함 - 데이터베이스 변경을 코드로 관리하는 **마이그레이션** - SQL 의존도를 크게 낮춘 **ORM** - 테스트가 기본 포함된 개발 흐름 - **MVC(Model–View–Controller)** 구조의 실질적 표준화 - MVC는 **1970년대 Smalltalk** 에서 유래한 개념이었지만, Rails를 통해 웹 개발의 기본 형태로 굳어짐 - Rails의 성공 이후 거의 모든 언어 생태계가 이 공식을 차용함 - **Django(2005)** 는 Python에서, **Laravel(2011)** 은 PHP에서 Rails식 구조를 정착시킴 - **CakePHP(2005)**, **CodeIgniter(2006)** 역시 같은 흐름 위에서 발전 - 생산성 향상은 과장이 아니었음 - 개인 개발자가 주말에 만들 수 있는 범위가 과거에는 팀 단위 작업에 해당 - 스타트업 환경에서 빠른 실험과 반복에 최적의 도구로 작동 - 실제로 여러 대표적인 서비스가 Rails 위에서 성장함 - **Basecamp(2004)**, **Twitter(2006)**, **GitHub(2008)**, **Shopify(2006)**, **Airbnb(2008)** - Rails는 곧 **스타트업 속도의 상징**처럼 인식됨 - 프레임워크가 생산성을 끌어올렸지만, **배포는 여전히 병목**이었음 - PHP 시대의 배포는 FTP 업로드가 일반적이었고, 실수 한 번으로 서비스가 망가질 수 있는 구조 - 더 나은 경우에도 **SSH + SVN pull + Apache 재시작** 같은 작업을 수동으로 처리 - 릴리즈 디렉터리를 나누고 심볼릭 링크를 바꾸는 방식 등, 모든 과정이 **커스텀이고 취약**했음 - 이 문제를 근본적으로 바꾼 것이 **Heroku(2007)** 로 **2009–2010년** 무렵부터 본격적으로 확산됨 - `git push heroku main` 한 줄로 배포가 끝나는 경험 제공 - 서버 설정, 웹 서버 재시작, 스케일링을 플랫폼이 대신 처리 - Heroku는 이후 **PaaS(Platform as a Service)** 라 불릴 개념을 실질적으로 정착시킴 - 개발자는 인프라가 아니라 코드에만 집중하는 역할로 이동 - **Twelve-Factor App(2011)** 원칙을 대중화하며 stateless 프로세스, 환경 변수 기반 설정, 로그 스트림화 등 클라우드 친화적 사고방식을 확산 - 같은 시기에 **협업 방식의 대전환**도 함께 진행됨 - **Git(2005)** 은 분산 버전 관리 모델을 도입해 **로컬에서 자유로운 커밋·브랜치·머지**를 가능하게 했고, **브랜치 비용**이 거의 없어 **실험과 되돌리기가 일상적인 작업**이 됨 - 기존 **Subversion(2000)** 은 중앙 집중식 구조로 브랜치가 무겁고 **머지가 공포의 대상**이었으며, 많은 팀이 트렁크 중심 개발에 의존했음 - Git은 도구 차원의 혁신이었지만, **GitHub(2008)** 가 공개 저장소 탐색과 포크 기반 개발, **Pull Request** 중심 협업을 결합하며 이를 문화로 정착시킴 - GitHub는 **코드 리뷰 문화를 표준화**함 - PR을 병합하기 전 누군가는 반드시 코드를 봐야 하는 구조 - 이 흐름이 회사 내부 개발에도 확산 - 코드가 바로 프로덕션으로 가던 시대의 종료 - 오픈소스 기여 방식은 **메일링 리스트에 패치**를 보내던 흐름에서 **버튼 클릭으로 PR을 제출**하는 방식으로 전환되며 참여 장벽이 크게 낮아짐 - 이 시기 후반부에는 웹의 정체성을 흔드는 변화도 등장 - **iPhone(2007)** 과 **App Store(2008)** 출시로 네이티브 앱이 급부상 - 모바일 웹은 당시 매우 열악했음. 데스크톱 사이트를 축소해 억지로 보는 경험에 가로 스크롤과 확대·축소 반복 - 일부는 **m.example.com** 같은 별도 모바일 사이트를 구축했지만 한계가 명확 - 네이티브 앱은 빠르고, 오프라인 지원, 푸시 알림 제공, **“There’s an app for that”** 이라는 구호로 미래처럼 보임 - 웹 개발자들은 **정체성 위기**를 겪기 시작함 : 웹을 계속해야 하는가? Objective-C를 배워야 하는가? 웹은 사라질 것인가? - 이 혼란에 대한 해답으로 **Responsive Web Design(2010)** 가 등장함 - **Ethan Marcotte(2010)** 가 CSS 미디어 쿼리를 활용해 화면 크기에 따라 레이아웃을 조정하는 방식을 제시하며, 모바일과 데스크톱을 하나의 코드베이스로 통합하는 방향을 제시함 - 초기에는 도구 미성숙과 추가 작업 부담으로 확산 속도가 느렸지만, 웹이 가야 할 방향 자체는 분명해짐 - **Bootstrap(2011)** 은 반응형 웹을 실제 현장에서 쓰이게 만든 계기였음 - Twitter 내부 도구로 시작해 그리드 시스템, 기본 타이포그래피, 폼 스타일을 한 번에 제공하며 디자이너가 없는 개발자도 즉시 사용할 수 있는 UI를 제공함 - 그 결과 웹은 점점 비슷해 보이기 시작했지만, 많은 개발자에게 Bootstrap은 첫 컴포넌트 라이브러리이자 디자인 시스템 경험이 됨 - 이 흐름은 이후 **Material Design(2014)** 등 체계적인 디자인 시스템 확산으로 이어짐 - 인프라도 같은 시기에 급격히 변화함 - 물리 서버를 미리 구매하거나 임대하던 방식에서 **가상 서버(VPS)** 중심 구조로 전환되며, 서버 자원을 필요할 때 생성하는 방식이 가능해짐 - **AWS(2006)** 는 가장 먼저 등장했지만 복잡하고 엔터프라이즈 지향적인 성격으로 개인 개발자에게는 부담이 컸음 - **DigitalOcean(2011)** 은 $5 드롭릿, 직관적인 UI, 빠른 서버 생성 경험으로 인프라 접근성을 크게 낮추며 개인 개발자도 대기업과 유사한 유연성을 갖게 만듦 - 파일 저장 문제는 **Amazon S3(2006)** 가 사실상 해결함 - 서버 수와 무관하게 확장 가능한 저장소, 업로드 후 URL을 바로 반환하는 단순한 모델을 제공함 - 사용자 업로드, 백업, 다중 서버 환경에서의 파일 관리 문제가 한 번에 정리됨 - **Node.js(2009)** 는 웹 개발자들에게 또 다른 충격을 줌 - Chrome **V8** 엔진 기반으로 서버에서 JavaScript 실행이 가능해지며, 프론트엔드 개발자에게는 매력적인 선택지로 보였고 백엔드 개발자에게는 회의적인 반응을 불러옴 - 논블로킹 I/O 모델은 실시간 애플리케이션에 강점을 보였고, 대부분의 튜토리얼이 채팅 앱 예제로 귀결됨 - 이 시기 Node는 아직 프로덕션 주류라기보다는 호기심의 대상에 가까웠고, 실제 서비스는 여전히 Rails·Django·PHP 중심이었으며 **npm** 생태계도 초기 단계였음 - 다만 이후 Node의 진짜 영향력은 서버보다는 빌드 도구와 개발 환경 실행 기반에서 먼저 드러나게 됨 - 데이터베이스 영역에서는 **NoSQL** 흐름이 부상함 - **MongoDB(2009)** 는 문서 기반 데이터 모델과 스키마 유연성, JSON 친화적 구조로 주목받음 - 빠른 프로토타이핑과 확장 가능성, JavaScript 스택과의 궁합에서 강점을 보였지만 모든 서비스에 적합하지는 않았음 - “언젠가 스케일할지도 모른다”는 이유로 선택됐다가, 수천 사용자 단계에서 트랜잭션 한계를 체감하는 사례도 흔했음 - 스타트업 생태계는 이 시기 본격적인 성장 국면에 진입함 - **Marc Andreessen(2011)** 의 “Software is eating the world” 선언과 **Lean Startup(2011)** 방법론 확산으로 MVP → 측정 → 반복 사이클이 정착됨 - 도구 성숙으로 소수 인원 팀의 경쟁력이 실제로 작동하기 시작함 - 개발 프로세스 역시 변화함 - **Agile Manifesto(2001)** 와 Scrum이 대중화되며 스탠드업, 스프린트, 회고가 표준처럼 도입됨 - 원칙보다는 형식만 남은 팀도 다수 등장함 - 코드 리뷰와 자동화 테스트는 권장에서 기본 기대치로 이동했고, CI 시스템이 커밋마다 테스트를 실행하며 소프트웨어 개발의 직업화와 전문화가 가속됨 - 다만 오늘날 당연하게 여겨지는 역할들은 아직 정착 전이었음 - **2012년** 기준으로 엔지니어 매니저, 프로덕트 매니저, 체계적인 백로그나 티켓 관리가 없는 팀이 흔했음 - 작은 팀과 평평한 조직 구조가 일반적이었고, “시니어 개발자”가 3년 차인 경우도 드물지 않았음 - **2013년** 무렵 웹은 완전히 다른 모습이 됨 - 강력한 프레임워크, 쉬운 배포, 소셜 코드 협업, 모바일 대응, 저렴한 인프라, JavaScript의 전면 확산이 동시에 성립함 - 모바일 위기를 넘긴 웹은 오히려 더 강해졌고, 다음 단계인 **JavaScript가 모든 것을 장악하는 시대**를 맞이할 준비를 마침 ### JavaScript 르네상스 > "Everything is a SPA now" - **2013년 전후**, 웹은 이미 Gmail·Google Maps 같은 사례를 통해 “진짜 애플리케이션”을 감당할 수 있음을 증명했지만, 기존의 jQuery + 서버 렌더링 방식은 점점 한계에 부딪힘 :contentReference[oaicite:0]{index=0} - 핵심 문제는 **상태(state) 관리**였음 - 서버가 HTML을 만들고 jQuery로 상호작용을 덧붙이는 구조에서는, 데이터와 UI를 여러 위치에서 일관되게 유지하기가 급격히 어려워짐 - 댓글, 카운트, 알림 배지처럼 동일한 상태가 여러 UI에 반영될수록 코드가 얽히며 스파게티 구조로 변함 - 이에 대한 공통된 결론은 **렌더링을 전부 클라이언트로 옮기자**는 것이었음 - 서버는 JSON을 반환하는 API 역할로 축소 - 브라우저에서 JavaScript가 UI 전체를 관리하는 **SPA(Single Page Application)** 구조가 부상 - 초기 SPA 프레임워크들이 이 시기에 등장함 - **Backbone.js(2010)** 는 모델과 뷰 개념으로 최소한의 구조를 제공 - **Angular(2010)** 는 양방향 데이터 바인딩과 의존성 주입을 도입하며 엔터프라이즈식 접근을 시도 - **Ember.js(2011)** 는 라우팅·데이터·템플릿을 모두 포함한 “JavaScript의 Rails”를 목표로 강한 규칙을 제시 - 이들 프레임워크는 진일보였지만, 공통적으로 **DOM과 데이터 동기화의 복잡성** 문제를 완전히 해결하지는 못함 - 특히 양방향 바인딩은 업데이트 흐름을 추적하기 어렵게 만들며 디버깅 비용을 키움 - 전환점은 **React(2013)** 의 등장임 - Facebook이 오픈소스로 공개했을 당시 JSX 문법은 관심사 분리를 거꾸로 돌리는 것처럼 보이며 거부감을 낳음 - 하지만 React는 DOM을 직접 조작하지 않고, **상태에 따른 UI의 결과를 선언적으로 기술**하는 새로운 사고방식을 제시함 - React의 핵심은 **선언형 모델**과 **Virtual DOM** - 상태가 바뀌면 React가 최소한의 DOM 변경만 계산해 반영 - 개발자는 DOM 조작을 신경 쓰지 않고 상태 관리에 집중 가능 - **컴포넌트** 개념 역시 결정적이었음 - Button, UserAvatar, CommentList 같은 작은 단위를 조합해 UI를 구성 - 각 컴포넌트는 독립적으로 사고하고 재사용 가능 - React는 서서히 확산되다 **2015년 무렵 주류로 자리 잡음** - **Vue.js(2014)** 는 유사한 개념을 더 친숙한 문법으로 제공하며 대안으로 부상 - 프레임워크 전쟁은 새로운 국면으로 진입 - SPA 확산은 **JavaScript 양의 폭발적 증가**를 의미했음 - 문제는 개발자가 쓰고 싶은 JavaScript와 브라우저가 이해하는 JavaScript가 달랐다는 점 - **ES6 / ES2015(2015)** 는 화살표 함수, 클래스, 모듈, 프로미스 등 대규모 언어 개선을 도입 - 콜백 지옥과 `var self = this` 패턴이 사라지며 JavaScript가 비로소 현대적인 언어처럼 느껴지기 시작 - 그러나 브라우저 지원은 뒤처졌고, 그대로 배포하는 것은 불가능했음 - **Babel(2014)** 은 최신 JavaScript를 ES5로 변환하는 트랜스파일러로 이 문제를 해결 - 그 대가로 JavaScript 개발에 **빌드 단계**가 필수 요소가 됨 - 파일 수정 후 새로고침만으로 끝나던 시대의 종료 - 이 과정에서 **Node.js(2009)** 는 서버가 아니라 **개발 도구 실행 환경**으로 모든 개발자 머신을 장악함 - 백엔드를 Node로 쓰지 않아도, 빌드 도구 때문에 Node 설치는 필수가 됨 - 빌드 도구 체인도 빠르게 진화함 - **Grunt(2012)** 는 태스크 러너로 복잡한 빌드 단계를 설정 파일로 관리 - **Gulp(2013)** 는 코드 기반 파이프라인으로 이를 단순화하려 했지만 여전히 복잡했음 - 결정적 변화는 **Webpack(2014)** - 단순 태스크 러너가 아니라 **모듈 번들러**로서 의존성 그래프를 이해 - JavaScript, CSS, 이미지, 폰트까지 모두 모듈로 취급 - 코드 스플리팅, 핫 모듈 리플레이스먼트 같은 개념 도입 - 강력함의 대가로 설정은 악명 높아짐 - Webpack 설정은 밈이 되었고, 팀마다 “이걸 이해하는 한 사람”이 존재 - 그 사람이 떠나면 설정은 손대기 두려운 유물로 남음 - 동시에 **npm 생태계**가 폭발적으로 성장함 - 라이브러리를 직접 다운로드하던 방식에서 `npm install` 중심으로 전환 - moment, lodash, 심지어 **left-pad** 같은 극소 유틸까지 패키지화 - **left-pad 사건(2016)** 은 생태계의 취약성을 드러냄 - 단 11줄짜리 패키지가 삭제되며 수천 개 프로젝트 빌드가 동시에 실패 - React와 Babel조차 설치 불가 상태에 빠짐 - npm이 전례 없이 패키지를 강제 복구하며 사태 수습 - 편의성은 유지됐지만, **의존성 지옥의 현실**을 모두가 인식하게 됨 - **2016년**, 복잡성은 정점에 도달함 - “[How it feels to learn JavaScript in 2016](https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f)” 풍자 글이 확산 - 간단한 웹 페이지를 만들기 위해 React, Webpack, Babel, Redux 등 수많은 도구가 필요하다는 피로감 확산 - 생태계 변화 속도가 너무 빨라 학습한 지식이 빠르게 구식이 됨 - 그럼에도 결과물은 분명했음 - 이전에는 불가능했던 수준의 인터랙티브 웹 애플리케이션 제작 가능 - 복잡성은 **야망의 비용**으로 받아들여짐 - 한편 **Docker(2013)** 는 전혀 다른 문제를 해결하기 시작함 - “works on my machine” 문제를 컨테이너로 해결 - Dockerfile로 실행 환경을 정의하고 어디서나 동일하게 실행 가능 - 초기에는 Mac 환경 성능 문제와 네트워킹 혼란으로 도입이 쉽지 않았음 - Docker Compose, Docker Swarm, 이후 **Kubernetes(2014)** 가 등장하며 오케스트레이션 전쟁 발생 - **2017년 무렵**, 컨테이너가 미래라는 점만큼은 분명해짐 - 이와 함께 **마이크로서비스** 트렌드가 확산 - 서비스 분리와 독립 배포라는 장점을 제공 - 대신 서비스 디스커버리, 로드 밸런싱, 분산 추적 등 새로운 복잡성 발생 - 많은 팀이 모놀리스의 복잡성을 분산 시스템의 복잡성으로 교환했음을 뒤늦게 인식 - 이 시기 웹 애플리케이션의 완성도는 눈에 띄게 상승함 - **Slack(2013)** 은 빠르고 검색 가능한 협업 도구로 이메일을 대체 - **Figma(2016)** 는 브라우저 기반 협업 디자인 도구로 데스크톱 앱의 영역을 침범 - **Notion(2016)** 등과 함께, 웹이 데스크톱급 소프트웨어를 구현할 수 있음을 증명 - 이들 사례는 React·Webpack·빌드 체인의 복잡성을 정당화하는 근거가 됨 - 조직 구조 역시 성숙 단계로 이동함 - **2016년 전후**, 프로덕트 매니저와 엔지니어 매니저가 표준 역할로 자리 잡음 - 초기의 평평한 팀 구조는 점차 프로세스 중심 조직으로 전환 - Scrum과 애자일 의식이 널리 퍼졌고, 팀에 따라 도구가 되기도 형식이 되기도 함 - **2017년**, 생태계는 서서히 안정 국면에 들어섬 - React는 사실상 승자가 되었고 - ES6는 기본 문법이 되었으며 - Webpack과 Docker는 고통스럽지만 표준으로 받아들여짐 - 다음 단계는 이미 예고되어 있었음 - **TypeScript** 의 부상 - **Next.js** 같은 메타 프레임워크 - 더 단순한 배포 경험 - 하지만 그 전제는 하나였음 - 이 **JavaScript 르네상스의 혼란을 통과한 개발자들만이**, 그 다음 단계로 나아갈 수 있었음 ### TypeScript 시대 > "Types are good, actually" - JavaScript 르네상스 이후 도구 난립이 진정되며 생태계가 **성숙 단계**로 접어드는 전환점에 TypeScript가 자리함 - **TypeScript(2012)** 는 JavaScript에 정적 타입을 도입했지만, 초기에는 동적 언어 철학과 빌드 단계 추가 부담으로 오랫동안 외면받음 - 애플리케이션 규모가 커지며 동적 타이핑의 한계가 점점 분명해짐 - 함수 시그니처 변경 후 호출부 추적 비용 증가 - 객체 형태를 파악하기 어려운 코드 가독성 문제 - 단순 오타가 프로덕션 장애로 이어지는 사례 반복 - **2017–2018년**을 기점으로 TypeScript 채택이 빠르게 확산됨 - 자동완성과 정적 분석을 통한 리팩터링 안정성 확보 - 인터페이스가 코드와 동기화된 **강제 문서** 역할 수행 - 주요 프레임워크의 수용이 전환점으로 작용함 - Angular는 TypeScript 우선 전략을 채택 - React 타입 정의 성숙, Vue 3의 TypeScript 기반 재작성으로 **사실상 표준**으로 인식됨 - **2020년** 무렵부터 순수 JavaScript 신규 프로젝트는 거의 선택되지 않게 됨 - TypeScript는 코드베이스의 **접근성을 크게 개선**함 - 신규 합류자가 타입 정의만 읽어도 도메인 모델 파악 가능 - 암묵적 지식 의존 감소로 팀 확장 비용 완화 - **VS Code(2015)** 와의 결합이 개발 경험을 결정적으로 변화시킴 - 지능형 자동완성, 인라인 에러 표시, 신뢰 가능한 리팩터링 제공 - Sublime Text, Atom은 점차 영향력 감소 - React 위에 또 다른 추상화 계층이 형성됨 - React는 UI 라이브러리로서 라우팅·데이터 패칭·SSR에 대한 기본 해법이 없었음 - **Next.js** 는 파일 기반 라우팅, 서버 사이드 렌더링, API 라우트, 자동 코드 스플리팅을 기본 제공하는 **메타 프레임워크**로 이 공백을 채움 - Nuxt, Remix, SvelteKit, Gatsby 등 다양한 대응 프레임워크 등장 - React 생태계에서는 Next.js가 사실상 기본 선택지로 자리 잡음 - 메타 프레임워크 확산으로 이전 시대의 **툴링 파편화 피로**가 크게 완화됨 - webpack·Babel 설정을 직접 조립하던 과정이 기본값으로 흡수됨 - 배포 환경 또한 급격히 단순화됨 - **Vercel**, **Netlify** 는 GitHub 연결만으로 자동 배포와 프리뷰 환경 제공 - 디자이너·PM·QA가 병합 전 실제 환경에서 변경 사항 확인 가능 - Heroku의 영향력은 약화되고, **Railway**, **Render** 같은 신세대 PaaS가 부상함 - **AWS Lambda(2014)** 를 중심으로 Serverless 개념이 확산됨 - 사용량 기반 과금과 자동 확장을 제공 - 콜드 스타트, 상태 관리, 디버깅 한계로 범용 해법은 아님 - **Cloudflare Workers** 는 엣지 실행 모델로 이를 확장함 - CSS 영역에서도 조용한 전환이 진행됨 - Sass·Less 이후 CSS-in-JS를 거쳐 **Tailwind CSS(2017)** 가 대중적으로 채택됨 - 유틸리티 클래스 기반 접근은 - 클래스 작명 부담 제거 - cascade·specificity 문제 감소 - 결과적으로 작은 스타일시트 유지로 이어짐 - **GraphQL(2015)** 은 복잡한 데이터 구조를 다루는 애플리케이션에서 강력한 해법으로 주목받음 - 정확한 데이터 질의, 타입 기반 스키마, 도구 생태계 장점 제공 - 서버 레이어 복잡성, 캐싱 난이도로 인해 단순 CRUD에는 과도한 선택이 됨 - 일부 팀은 REST 유지 또는 tRPC 같은 단순 대안 선택 - 컨테이너 오케스트레이션 경쟁은 **2018년**을 전후로 **Kubernetes**의 승리로 귀결됨 - 강력하지만 높은 학습 비용과 운영 복잡성을 동반 - 많은 팀에는 과도한 해법이었고, PaaS 재부상의 배경이 됨 - **COVID(2020)** 는 웹 개발 수요를 급격히 확대함 - 원격 근무, 전자상거래, 협업 도구가 필수가 됨 - 개발자 수요 폭증과 개발 도구 기업의 급성장으로 이어짐 - 원격 환경에서 비동기 협업과 문서화의 중요성이 커짐 - 코드 리뷰, PR 설명, 내부 문서 품질이 핵심 요소로 부상 - 조직 차원에서도 성숙이 진행됨 - 엔지니어 레벨 체계 정착 - IC 트랙의 정당성 확보 - PM·EM·테크 리드 역할 분화 - **Developer Experience(DX)** 가 독립적인 투자 대상으로 인식됨 - 내부 플랫폼 팀, 빠른 CI, 온보딩 개선이 생산성 핵심 요소로 부상 - **2022년** 무렵, 웹 개발은 복잡하지만 **관리 가능한 상태**에 도달함 - TypeScript 기본값화 - Next.js 중심의 생태계 - 배포 자동화와 성숙한 도구 체계 - 그리고 모든 것이 바뀌어 버림 : OpenAI 라는 회사가 **ChatGPT** 라고 불리는 것을 출시 ### AI의 순간 > "Wait, I can just ask it to write the code?" - **ChatGPT(2022)** 출시를 기점으로, 질문만 입력하면 설명·코드·디버깅 결과가 나오는 경험이 등장하며 개발 규칙이 바뀌었음 - 양자물리 설명부터 Python 디버깅까지 수행 가능했고, 완벽하지 않지만 **충분히 쓸 만한 수준**이라는 점이 충격으로 작용함 - 개발자들은 즉시 실험에 들어갔고, React 컴포넌트 작성, 오류 원인 분석, 언어 간 코드 변환이 **문서 검색이나 포럼 탐색 없이 수초 내 가능**해졌음 - **GitHub Copilot(2022)** 은 에디터 안에서 자동 완성 형태로 코드 생성을 제공하며, 주석만으로 구현을 제안하는 **초강력 자동완성 경험**을 확산시킴 - AI 제안을 빠르게 평가·채택·수정·거절하는 **새로운 메타 스킬**이 개발자의 핵심 역량으로 등장함 - 반복적 보일러플레이트, 테스트 작성, 엣지 케이스 처리 같은 작업이 급격히 빨라지며 **흐름을 끊지 않는 개발**이 가능해짐 - **Cursor(2023)** 는 AI를 기능이 아닌 전제 조건으로 통합한 IDE로, 코드 선택 후 리팩터링 요청, 자연어 설명 기반 다중 파일 수정, 코드베이스와의 대화가 가능해짐 - 이 변화로 시니어리티의 의미가 흔들렸지만, 실제로는 **무엇을 만들지 결정하고, 요구사항·제약·부작용을 판단하는 능력**의 중요성이 더 커졌음 - AI는 코드를 작성할 수 있지만, **문제를 정의하고 올바른 방향을 선택하지는 못함** - 극단적으로는 “프로그래밍의 종말”과 “쓸모없는 유행”이라는 양극단 반응이 있었으나, 실제 결과는 **AI를 쓰는 개발자의 생산성 증폭**으로 나타남 - 개인·사이드 프로젝트의 진입 장벽이 급격히 낮아져, 예전에는 시도하지 않았을 영역(ML·게임·새 프레임워크)도 **대화 기반 학습으로 접근 가능**해짐 - 이 흐름은 웹의 오랜 방향성인 **창작의 대중화**를 가속하는 단계로 작동함 - 코드를 아는 것에서, **무엇을 만들고 싶은지 아는 것**으로 중심이 이동 - 비개발자도 프로토타입 제작에 참여하고, PM·디자이너·도메인 전문가가 직접 도구를 만들며 **기술/비기술 경계가 흐려짐** - 인디 해커와 솔로 빌더가 증가하며, **혼자서도 실질적인 제품을 만들 수 있는 환경**이 현실이 됨 - 동시에 React Server Components, **htmx**, 개선된 CSS·JavaScript 표준, **Bun** 같은 도구들이 “플랫폼 자체를 쓰자”는 흐름을 강화함 - 2022–2023년 대규모 채용 붐 이후 구조조정이 겹치며 시장은 흔들렸지만, AI는 개발자를 대체하지 않았고 **AI 활용 능력은 기본 기대치**가 됨 - 2025년 시점에서 웹 개발은 **아이디어부터 배포까지의 속도가 역사상 가장 빠른 상태**이며, - 클라우드·프레임워크·AI가 결합된 환경에서 **개인은 그 어느 때보다 강력한 창작자**가 됨 - `<br>` 태그로 시작된 웹의 약속, “누구나 만들고 공유할 수 있다”는 원칙은 **AI 시대에 더 강해진 형태로 이어지고 있음** - 지금은 **웹 개발을 하기에 정말 좋은 시기**임 ## Comments ### Comment 56812 - Author: geekgig - Created: 2026-05-04T14:55:09+09:00 - Points: 1 웹/모바일은 멀리서 바라 보기만 하고, PC App(C++) 위주로 살아온 저에게는 Web 전체 역사적 변화 흐름을 잘 알려주는 글이네요. 덕분에 조각조각 알던 내용을 연결하여 보는 눈이 조금은 생긴 듯 합니다. 감사합니다. ~~ ### Comment 47992 - Author: ethanhur - Created: 2025-12-19T11:25:55+09:00 - Points: 1 재밌게 역사서처럼 읽었습니다. ### Comment 47988 - Author: zihado - Created: 2025-12-19T09:59:11+09:00 - Points: 1 카페25에서 서버 호스팅 하나 하고, 제로보드 올려서 나름 커뮤니티라고 꾸미고 놀았던 그 시절 ㅎㅎ ### Comment 47978 - Author: lethee - Created: 2025-12-19T09:03:39+09:00 - Points: 1 재미있게 읽었습니다. 죽기 전에 스쳐가는 주마등 느낌으로요 ㅎㅎ ### Comment 47908 - Author: edunga1 - Created: 2025-12-17T16:03:56+09:00 - Points: 1 재밌게 읽었습니다. 개발 환경으로 가면 VS Code와 LSP 등장. 그리고 Tabnine의 AI시대 이전의 도구까지 연결 되겠어요. ### Comment 47889 - Author: aer0700 - Created: 2025-12-17T11:22:42+09:00 - Points: 1 https://news.hada.io/topic?id=21170 이 글하고 같이보면 좋겠네요 ### Comment 47868 - Author: neo - Created: 2025-12-17T08:02:41+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46254794) - 모든 페이지에 동일한 헤더, 내비게이션, 푸터가 필요했지만 공유할 방법이 없었다는 말은 완전히 맞지 않음 웹서버에는 **Server Side Includes(SSI)** 기능이 있었고, 그걸 쓰기 싫다면 단순히 `cat header body > file` 명령으로도 해결 가능했음 관련 문서: [NCSA SSI 튜토리얼 (1997)](https://web.archive.org/web/19970303194503/http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html) - 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)** 을 생생하게 전달함 보통은 구전으로만 전해지는 인간적인 맥락을 글로 담아낸 점이 인상적이었음 “왜 이렇게 복잡한 클라우드 세상이 되었나”를 비판하기보다, 각 시점의 **합리적 선택들이 누적된 역사적 결과**로 이해하게 해줌 인간사의 아이러니를 기술사 속에서 느낄 수 있었음