▲

<br> 태그로 돌아본 웹의 30년

 (artmann.co)
20P by GN⁺ 2일전 | ★ favorite | 댓글 3개
  • 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” 풍자 글이 확산
    • 간단한 웹 페이지를 만들기 위해 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 시대에 더 강해진 형태로 이어지고 있음
  • 지금은 웹 개발을 하기에 정말 좋은 시기임
▲
edunga1 1일전  [-]

재밌게 읽었습니다.
개발 환경으로 가면 VS Code와 LSP 등장. 그리고 Tabnine의 AI시대 이전의 도구까지 연결 되겠어요.

답변달기
▲
aer0700 2일전  [-]

https://news.hada.io/topic?id=21170
이 글하고 같이보면 좋겠네요

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 모든 페이지에 동일한 헤더, 내비게이션, 푸터가 필요했지만 공유할 방법이 없었다는 말은 완전히 맞지 않음
    웹서버에는 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) 을 생생하게 전달함
    보통은 구전으로만 전해지는 인간적인 맥락을 글로 담아낸 점이 인상적이었음
    “왜 이렇게 복잡한 클라우드 세상이 되었나”를 비판하기보다, 각 시점의 합리적 선택들이 누적된 역사적 결과로 이해하게 해줌
    인간사의 아이러니를 기술사 속에서 느낄 수 있었음

답변달기