같은 리스트를 탄생 목적 / 실사용 두 줄로 분리해서 정리한다. (★ 표시는 둘이 크게 갈라진 케이스 — 즉 “원래 그러려고 만든 게 아닌데 더 유명해진” 기술)

1. 프로그래밍 언어

• C (1972, Dennis Ritchie @ Bell Labs)
  • 탄생: Unix를 다른 컴퓨터로 이식하기 위한 OS 기술용 언어
  • 실사용: OS, 임베디드, 다른 언어의 런타임/확장
• Java (1995, James Gosling @ Sun) ★
  • 탄생: 셋톱박스/가전제품용 임베디드 언어 (Project Oak). 인터랙티브 TV 시장 노림
  • 실사용: 엔터프라이즈 백엔드, Android
• Python (1991, Guido van Rossum)
  • 탄생: ABC 언어 후속. CWI의 Amoeba OS 자동화용 스크립트 + 가독성 실험
  • 실사용: 웹 백엔드, 데이터/ML, DevOps
• Ruby (1995, 마츠모토 유키히로)
  • 탄생: Perl보다 OO스럽고 Smalltalk보다 실용적인 스크립트 언어. “프로그래머 행복”
  • 실사용: Rails 백엔드, DevOps (Chef/Puppet)
• PHP (1995, Rasmus Lerdorf) ★
  • 탄생: 자기 개인 홈페이지에 방문자 카운터 같은 거 넣을 Perl/CGI 스크립트 모음
  • 실사용: WordPress, 전 세계 웹 70%
• Go (2009, Google)
  • 탄생: Google 내부 C++ 빌드 너무 느림 + 동시성 어려움. 시스템 SW를 단순하게
  • 실사용: 클라우드 인프라(Docker, k8s, Terraform), 마이크로서비스
• Rust (2010, Graydon Hoare @ Mozilla) ★
  • 탄생: Mozilla 차세대 브라우저 엔진(Servo)의 메모리 안전성 위해
  • 실사용: 시스템 SW, 블록체인, CLI 도구, 일부 백엔드
• Node.js (2009, Ryan Dahl)
  • 탄생: Apache가 “오래 열린 연결”(파일 업로드 진행률 같은) 다루기 어려움. V8 위에 이벤트 기반 IO 서버
  • 실사용: 웹 백엔드, 빌드 도구, Electron
• Kotlin (2011, JetBrains) ★
  • 탄생: JetBrains가 자기 IDE를 Java로 짜다 boilerplate에 지쳐 만든 사내 언어
  • 실사용: Android 공식 언어
• TypeScript (2012, Anders Hejlsberg @ MS)
  • 탄생: MS 내부 대규모 JS 프로젝트(Bing/Office) 유지보수 위해 점진적 타입 추가
  • 실사용: 모던 프론트엔드 + Node 백엔드 표준

2. 웹 프레임워크

• Ruby on Rails (2004, DHH)
  • 탄생: 자기 회사 Basecamp 만들면서 추출
  • 실사용: 스타트업 MVP, GitHub/Shopify 백엔드
• Django (2005, Lawrence Journal-World)
  • 탄생: 캔자스 지역 신문사 내부 도구. 기사 사이트 빠르게 찍어내기
  • 실사용: 콘텐츠 사이트(Instagram, Pinterest), 어드민
• Spring (2003, Rod Johnson)
  • 탄생: 책 부록 코드. EJB 무거움을 IoC + DI로 대체
  • 실사용: 엔터프라이즈 자바 백엔드 표준
• Express (2010, TJ Holowaychuk)
  • 탄생: Ruby Sinatra에 영감받아 Node용 minimal 프레임워크
  • 실사용: Node 라우팅 사실상 표준
• FastAPI (2018, Sebastián Ramírez)
  • 탄생: Flask는 type hint 활용 못 하고 자동 문서 없음. Pydantic + Starlette 위에
  • 실사용: ML 모델 서빙, 모던 Python API

3. RDB

• SQL (1974, IBM)
  • 탄생: System R 프로젝트에서 Codd의 관계형 모델(1970)을 실제 쿼리 언어로 구현
  • 실사용: 거의 모든 RDB의 표준
• PostgreSQL (1986, Stonebraker @ UC Berkeley)
  • 탄생: 학술 프로젝트. 확장 가능한 DBMS 연구 (custom type, 객체-관계형 등)
  • 실사용: 범용 OLTP, JSON/지리정보/벡터까지 다 처리
• MySQL (1995, MySQL AB)
  • 탄생: 스웨덴 회사 TcX가 자기 데이터 도구에 mSQL 쓰려다 너무 느려서 직접 만듦
  • 실사용: LAMP 스택, WordPress
• SQLite (2000, D. Richard Hipp) ★
  • 탄생: 미 해군 구축함 통신 SW에 임베드할 의존성 없는 작은 DB
  • 실사용: 모바일 앱, 브라우저, 데스크톱 SW의 로컬 저장소

4. NoSQL / 특수 DB

• MongoDB (2009, 10gen) ★
  • 탄생: 원래 만들려던 PaaS의 백엔드 DB. PaaS는 망하고 DB만 살아남음
  • 실사용: 스키마 자주 바뀌는 웹앱, 프로토타입
• Redis (2009, Salvatore Sanfilippo)
  • 탄생: 자기 스타트업 실시간 분석이 MySQL로 너무 느려서. 메모리 자료구조 서버
  • 실사용: 캐시, 세션, rate limiting, pub/sub, 큐
• Cassandra (2008, Facebook)
  • 탄생: Facebook 받은편지함 검색의 폭주하는 쓰기를 받기 위해. Dynamo + Bigtable
  • 실사용: 시계열, 로그, 대규모 쓰기 (Apple, Netflix, Discord)
• DynamoDB (2012, AWS)
  • 탄생: Amazon 쇼핑카트가 RDB로 안 버틴 경험(2007 Dynamo 논문)을 매니지드화
  • 실사용: AWS 환경 키-값, 서버리스
• Elasticsearch (2010, Shay Banon)
  • 탄생: 자기 아내 요리 레시피 검색 앱 만들다 Lucene 분산화 필요
  • 실사용: 로그 검색(ELK), 전문 검색
• Neo4j (2007)
  • 탄생: 자산 관리 시스템에서 RDB JOIN으로 그래프 쿼리가 지옥
  • 실사용: 추천, 사기 탐지, 지식 그래프
• pgvector / Pinecone / Weaviate
  • 탄생: ML 임베딩 벡터 유사도 검색 (Pinecone은 원래 추천 시스템용)
  • 실사용: LLM RAG 백엔드 ★ (LLM 붐 이후)

5. 메시지 큐 / 스트리밍

• RabbitMQ (2007)
  • 탄생: AMQP(JPMorgan 주도 금융권 메시징 표준)의 레퍼런스 구현
  • 실사용: 범용 작업 큐, 마이크로서비스 통신
• Kafka (2011, LinkedIn)
  • 탄생: LinkedIn 사이트 활동 데이터를 여러 소비자에게 흘려보낼 통합 파이프라인
  • 실사용: 이벤트 스트리밍 백본 (탄생 목적과 거의 동일)
• Celery (2009)
  • 탄생: Django 앱의 백그라운드 작업(이메일 등) 비동기 처리
  • 실사용: Python 비동기 작업 표준

6. API 통신

• REST (2000, Roy Fielding 박사논문)
  • 탄생: 새 기술이 아님. 박사논문에서 HTTP/웹이 왜 잘 작동하는지 분석한 아키텍처 스타일
  • 실사용: 웹 API 사실상 기본값
• GraphQL (2012 FB 내부, 2015 공개)
  • 탄생: Facebook 모바일 앱 리뉴얼 시 REST의 over-fetching/under-fetching, endpoint 폭증
  • 실사용: SPA·모바일 백엔드, BFF
• gRPC (2016, Google)
  • 탄생: Google 내부 RPC(Stubby) 오픈소스화. 서비스 간 빠른 통신
  • 실사용: 마이크로서비스 internal 통신, k8s 컴포넌트 간
• WebSocket (2011 표준)
  • 탄생: HTTP polling/long-polling으로 양방향 흉내내는 게 비효율적
  • 실사용: 채팅, 게임, 실시간 협업
• SSE (HTML5의 일부) ★
  • 탄생: 서버→클라 단방향 push를 polling 없이 (2008년경 알림용으로 도입)
  • 실사용: 지금은 거의 LLM 응답 스트리밍 때문에 부활

7. 인증 / 보안

• OAuth (1.0: 2007, 2.0: 2012)
  • 탄생: Twitter API 등에서 3rd party 앱이 사용자 비밀번호 받는 게 위험. 권한 위임
  • 실사용: “구글로 로그인”, API 권한 위임
• JWT (2015) ★
  • 탄생: OpenID Connect용 ID 토큰 포맷. SAML(XML)을 JSON/URL-safe로 대체
  • 실사용: stateless 백엔드 인증, API 토큰 (탄생 의도와 다름)
• SAML (2002)
  • 탄생: 엔터프라이즈 환경 시스템 간 신원 정보 교환 표준 (XML)
  • 실사용: 기업 SSO (Okta, Azure AD)
• TLS/SSL (SSL 1.0: 1995 Netscape)
  • 탄생: Netscape가 e-commerce(신용카드) 위해 HTTP 트래픽 암호화
  • 실사용: 모든 HTTPS, gRPC, 이메일, VPN
• bcrypt (1999, OpenBSD)
  • 탄생: MD5/crypt가 너무 빨라 brute-force 취약 → 의도적으로 느린 비밀번호 해시
  • 실사용: 비밀번호 저장 표준

8. 컨테이너 / 오케스트레이션

• Docker (2013) ★
  • 탄생: dotCloud라는 PaaS 회사가 자기 플랫폼 내부에서 쓰던 LXC 래퍼를 오픈소스화
  • 실사용: 개발 환경 일치, 배포 단위, k8s 실행 단위
• Kubernetes (2014, Google)
  • 탄생: Google Borg(15년 운영) + Omega 경험 오픈소스화. AWS 대항마 의도도
  • 실사용: 컨테이너 오케스트레이션 표준 (탄생 목적 그대로)
• Helm (2015)
  • 탄생: k8s YAML이 환경별로 반복적이라 패키지 매니저 필요
  • 실사용: k8s 앱 배포 패키지
• Istio (2017)
  • 탄생: Lyft Envoy + Google service mesh. 통신 정책/관측을 코드 밖으로
  • 실사용: 마이크로서비스 mTLS, 트래픽 관리

9. 웹 서버 / 프록시

• Apache (1995)
  • 탄생: 망한 NCSA HTTPd의 사용자들이 패치 모음(“a patchy server”) 만든 게 기원
  • 실사용: 전통적 웹 서버, PHP 호스팅
• Nginx (2004, Igor Sysoev)
  • 탄생: 러시아 검색 사이트 Rambler의 C10K 문제 해결용 이벤트 기반 서버
  • 실사용: 리버스 프록시, 정적 파일, 로드밸런서 (탄생 그대로 + 더 확장)
• HAProxy (2001)
  • 탄생: 자기 회사 트래픽 분산할 무료 L4/L7 LB가 없어서 직접 작성
  • 실사용: 고성능 로드밸런싱
• Caddy (2015)
  • 탄생: HTTPS 설정이 너무 복잡 (Let’s Encrypt 자동 통합)
  • 실사용: 작은~중간 웹 서버

10. CI/CD / IaC

• Jenkins (2011)
  • 탄생: Sun이 만든 Hudson의 fork. Oracle 인수 후 라이선스 분쟁
  • 실사용: 자체 호스팅 CI/CD
• GitHub Actions (2019)
  • 탄생: GitHub repo와 통합된 CI 부재 (CircleCI/Travis 의존 내재화)
  • 실사용: 오픈소스 + 중소 프로젝트 표준
• Terraform (2014, HashiCorp)
  • 탄생: 클라우드 GUI 클릭은 재현 불가. 코드 + multi-provider 통합
  • 실사용: IaC 표준
• Ansible (2012)
  • 탄생: Puppet/Chef는 agent 필요 + Ruby DSL. SSH + YAML로 더 단순하게
  • 실사용: 서버 설정 관리
• ArgoCD (2018, Intuit)
  • 탄생: Intuit가 자기 k8s 배포 관리하려고. GitOps 개념 정립
  • 실사용: k8s GitOps 배포

11. 관측

• Prometheus (2012, SoundCloud)
  • 탄생: SoundCloud가 마이크로서비스 옮기는데 기존 도구가 동적 환경에 약함. Borgmon 영향
  • 실사용: k8s/마이크로서비스 메트릭 표준 (탄생 목적 그대로)
• Grafana (2014) ★
  • 탄생: Kibana를 fork해 Elasticsearch 외 시계열 DB(InfluxDB/Graphite)도 시각화
  • 실사용: 모든 데이터 소스 대시보드 표준
• Jaeger (2015, Uber)
  • 탄생: Uber 마이크로서비스 추적. Google Dapper 논문 기반
  • 실사용: 분산 트레이싱 표준
• OpenTelemetry (2019)
  • 탄생: OpenTracing + OpenCensus 두 표준이 경쟁하다 합쳐짐
  • 실사용: vendor-중립 관측 데이터 수집

12. 버전 관리

• Git (2005, Linus)
  • 탄생: Linux 커널팀이 BitKeeper 무료 사용권 박탈당해 Linus가 2주 만에
  • 실사용: 소스 관리 사실상 표준
• GitHub (2008)
  • 탄생: Git CLI가 너무 어려움. 웹 UI + 협업(PR, 이슈)
  • 실사용: 오픈소스/기업 코드 호스팅

13. 클라우드 / 서버리스

• AWS (2006) ★
  • 탄생: Amazon이 자기 e-commerce 인프라를 외부 판매. Bezos의 “API everything” 정책 부산물
  • 실사용: 범용 클라우드 인프라
• S3 (2006)
  • 탄생: Amazon 내부 다양한 데이터 저장 표준화
  • 실사용: 파일 저장, 백업, 데이터 레이크
• Lambda (2014)
  • 탄생: 서버 없이 코드만 올려 실행하는 이벤트 기반 컴퓨팅 모델
  • 실사용: 짧은 작업, 이벤트 처리, 서버리스 백엔드
• Cloudflare Workers (2017)
  • 탄생: Cloudflare CDN edge에서 코드 실행 (V8 isolate로 Lambda보다 가볍게)
  • 실사용: edge computing, API 게이트웨이

14. ORM / DB 도구

• Hibernate (2001)
  • 탄생: Java 개발자가 EJB CMP에 지쳐 만든 ORM
  • 실사용: Java ORM 표준
• SQLAlchemy (2006)
  • 탄생: Python에 본격적 ORM 부재. Core(SQL 추상화) + ORM 두 레이어
  • 실사용: Python ORM 표준
• Prisma (2019)
  • 탄생: TypeScript에서 type-safe DB 접근. Sequelize 등은 타입 약함
  • 실사용: TS 풀스택
• Alembic (2009)
  • 탄생: SQLAlchemy 작성자가 마이그레이션 도구로 같이 만듦
  • 실사용: Python 마이그레이션
• dbt (2016)
  • 탄생: 컨설팅 회사 Fishtown이 분석 SQL을 SW 엔지니어링 방식으로 관리
  • 실사용: 데이터 웨어하우스 변환 표준

15. 테스팅

• JUnit (1997, Kent Beck + Erich Gamma)
  • 탄생: 비행기에서 SUnit(Smalltalk)을 Java로 포팅
  • 실사용: Java 단위 테스트 표준
• pytest (2003)
  • 탄생: Python의 unittest(JUnit 이식)가 boilerplate 많음
  • 실사용: Python 테스트 표준
• Selenium (2004, ThoughtWorks)
  • 탄생: ThoughtWorks가 자기 웹앱 테스트 자동화
  • 실사용: E2E 테스트, 웹 자동화
• Playwright (2020, MS)
  • 탄생: Puppeteer 만든 팀이 MS로 옮겨 멀티 브라우저 후속작
  • 실사용: 모던 E2E
• Postman (2012) ★
  • 탄생: 자기가 API 개발 중 curl 반복이 귀찮아 만든 Chrome 확장
  • 실사용: API 수동 테스트, 팀 컬렉션 공유 (회사로 성장)
• k6 (2017)
  • 탄생: JMeter 등 부하 테스트가 GUI 위주라 CI 친화적이지 않음
  • 실사용: 부하 테스트, 성능 회귀

16. 빌드 / 패키지

• Maven (2004)
  • 탄생: Apache가 Jakarta 프로젝트 빌드 표준화. Ant는 자유로워서 일관성 없음
  • 실사용: Java 빌드 표준
• npm (2010)
  • 탄생: Node 모듈 공유/설치 표준 부재
  • 실사용: 거의 모든 JS 프로젝트 의존성 관리
• pip (2008) → poetry (2018) → uv (2024)
  • 탄생: 단계별로 “이전 도구의 한계”를 풀려고 만들어짐 (의존성 해결, lock, 속도)
  • 실사용: Python 패키지 관리 (현재는 uv로 빠르게 이동 중)

---

★ 표시들에서 보이는 패턴

탄생 목적과 실사용이 갈라진 케이스를 보면 공통점이 있다:

패턴	예시
회사 내부 도구가 오픈소스화 후 다른 곳에서 더 유명	Docker, Kafka, k8s, Cassandra
다른 분야(임베디드/PaaS/브라우저)용으로 만들었는데 백엔드가 가져감	Java, SQLite, JWT, Rust
스크래치 가려운 데에서 출발해 회사가 됨	PHP, Postman, Elasticsearch
fork/패치 모음으로 시작	Apache, Jenkins, Grafana, MariaDB
이전 기술의 라이선스 분쟁이 만든 결과	Git, MariaDB, Jenkins

→ “탄생 목적과 실사용이 다르다”는 건 실패가 아니라 오히려 정상이다. 한 분야에서 잘 만들어진 도구는 인접 분야에서 자주 재발견되고, 진짜 좋은 도구는 원래 의도를 넘어 살아남는다. 새 기술 평가할 때 “지금 사람들이 어떻게 쓰나”와 “원래 어떤 문제를 풀려고 만들어졌나”를 모두 보면, 그 도구의 강점이 어디서 오는지 더 정확히 보인다 (예: SQLite는 “임베디드 신뢰성”이 뿌리라서 모바일 앱이 신뢰하고 쓰는 것).