"역사" 태그로 연결된 2개 게시물개의 게시물이 있습니다.

들어가며​

2025년 6월 2일, Snowflake(스노우플레이크)가 Crunchy Data(크런치 데이터)를 약 2억 5천만 달러에 인수했고, 2025년 5월에는 Databricks(데이터브릭스)가 Neon(네온)을 10억 달러 안팎으로 가져갔어요. Microsoft(마이크로소프트)는 자체 Postgres 변형 HorizonDB를 들고나왔어요. 2026년 5월 현재, "PostgreSQL을 쓴다"는 말은 점점 모호해졌어요. Snowflake Postgres인가, Lakebase인가, HorizonDB인가, 아니면 그냥 PostgreSQL인가요.

이 글은 30년에 걸친 PostgreSQL 회사들의 인수와 이별, 그리고 그 사이를 혼자 걸어온 컨설턴트/메인테이너들의 이야기입니다. 사실에 기반해 풀고, 마지막에는 다음 5년을 가늠해 보겠습니다.

한 장으로 보는 흐름​

본문으로 들어가기 전, 큰 패턴을 표 하나로 깔아둡니다.

표를 위에서 아래로 따라 읽으면 한 가지 패턴이 보입니다. PG 회사가 클라우드 회사에 흡수되는 주기가 점점 짧아집니다. Salesforce→Heroku에서 Microsoft→Citus까지 9년, Microsoft→Citus에서 Databricks→Neon까지 6년입니다.

이제 각 시기를 풀어씁니다.

Act 1. 1996~2010​

학교 프로젝트가 살아남은 시기입니다.

PostgreSQL의 출발은 UC Berkeley(버클리)의 POSTGRES (1986)입니다. Michael Stonebraker(마이클 스톤브레이커)가 INGRES의 후속으로 시작한 프로젝트가 1995년 SQL 인터페이스를 도입하며 PostgreSQL이라는 이름을 얻었고, 1996년 첫 정식 릴리스가 나왔습니다. 이 시기 합류한 사람들이 이후 30년의 형태를 만들었습니다.

Tom Lane(톰 레인)은 1996년 무렵부터 활동했습니다 — PostgreSQL 역사에서 가장 많은 commit을 한 사람입니다. 17년간 Red Hat(레드햇)에서 일하다 Salesforce(세일즈포스)를 거쳐 2015년 Crunchy Data로 옮겼습니다. Crunchy는 그에게 PostgreSQL에 100% 시간을 쏟을 자리를 마련해 줬습니다.

Bruce Momjian(브루스 모미얀)은 PostgreSQL 거버넌스의 대변자입니다. 2006년 EDB(EnterpriseDB, 엔터프라이즈DB)에 합류해 지금까지 같은 자리에 있습니다. PostgreSQL 라이선스의 BSD-스타일 약속을 가장 자주 옹호하는 사람이기도 합니다.

1997년에는 Joshua Drake(조슈아 드레이크)가 미국 몬태나에 Command Prompt(커맨드 프롬프트)를 차렸습니다. 2026년 현재까지 살아남은 PostgreSQL 컨설팅 회사입니다.

회사 쪽 흐름은 두 갈래로 갈렸다:

EDB는 2004년 Andy Astor(앤디 애스터), Denis Lussier(데니스 루시에르), Paul T. Winn(폴 윈), Phillip Merrick(필립 메릭)가 설립했습니다. 처음부터 "엔터프라이즈용 PostgreSQL"을 표방했고 Oracle(오라클) 호환성에 무게를 뒀습니다.

2ndQuadrant(세컨드쿼드런트)는 2002년 Simon Riggs(사이먼 릭스)가 영국/이탈리아에 설립했습니다. 설립자가 PITR, Hot Standby, 동기화 replication을 만든 사람이라 회사 자체가 "코어 기능 공급자"였습니다.

2009년에는 Christophe Pettus(크리스토프 페투스)가 PGX(PostgreSQL Experts)를 차렸습니다. The Build(더 빌드) 블로그가 이 회사의 채널입니다.

이 시기 클라우드는 아직 변두리였습니다. 2010년 12월, Salesforce가 Heroku(헤로쿠)를 약 2억 1,200만 달러에 인수했습니다. Heroku는 그해 11월에 PostgreSQL을 도입했고, 다음 해 11월 "Heroku Postgres"를 분리 제품으로 내놨습니다. Ruby/Python 개발자가 PostgreSQL을 "기본"으로 받아들이기 시작한 순간이었습니다.

Act 2. 2011~2019​

클라우드가 책을 다시 쓴 시기입니다.

이 시기 PostgreSQL 회사들은 두 가지 길을 갔습니다. 하나는 클라우드 벤더에 흡수되는 길이고, 다른 하나는 새로운 시장을 만드는 길이었습니다.

흡수된 쪽:

OpenSCG → AWS(2018년 4월경)는 Denis Lussier가 만든 마이그레이션 서비스 회사의 인수 사례입니다. 회사는 AWS의 Database Migration Service에 흡수됐습니다.

Citus Data(사이터스 데이터) → Microsoft(2019-01-24)는 Y Combinator(Y 컴비네이터) S11 출신 회사의 인수 사례입니다. 이 회사는 분산 PostgreSQL extension을 만들었습니다. Microsoft가 인수한 뒤 Azure Database for PostgreSQL Hyperscale (현 Cosmos DB for PostgreSQL)로 이름이 바뀌었으며, 금액은 공개되지 않았습니다.

EDB의 자본 회전도 이어졌습니다. 2014년 Peak Equity Partners(피크 에쿼티 파트너스), 2019년 Great Hill Partners(그레이트 힐 파트너스)가 차례로 EDB의 다수 지분을 가져갔습니다.

새로 만들어진 쪽:

Crunchy Data는 2012년 Bob Laurence/Paul Laurence(폴 로런스) 형제가 창업했으며, 규제 산업/연방 정부 시장에 무게를 뒀습니다. Timescale(타임스케일)은 2015년 PostgreSQL extension으로 시계열 워크로드를 잡았습니다. Aiven(아이븐)은 2016년 핀란드 출신 3인(Oskari Saarenmaa(오스카리 사렌마), Hannu Valtonen(한누 발토넨), Heikki Nousiainen(헤이키 노우시아이넨))이 만든 관리형 오픈소스 플랫폼입니다. 2022년 시리즈 D 2억 1,000만 달러까지 모았습니다. Supabase(수파베이스)는 2020년 Paul Copplestone(폴 코플스톤)/Ant Wilson(앤트 윌슨)이 설립했습니다. "Firebase(파이어베이스)의 오픈소스 대안"이라는 슬로건으로 시작했지만, 본질은 관리형 PostgreSQL + BaaS입니다.

이 시기 가장 묵직한 인물 이동은 Andres Freund(안드레스 프룬트)입니다. 그는 Microsoft Azure Postgres 팀으로 옮겨갔고, 2024년 3월 PostgreSQL을 Debian Sid에서 벤치마킹하다가 SSH 로그인이 500ms 늦은 것을 눈치챘습니다 — 그 흔적을 추적해 xz Utils backdoor를 발견했습니다. "역사상 가장 위험한 backdoor"라는 평가가 붙은 사건의 발견자가 PostgreSQL 커미터였다는 것은 우연이 아닙니다.

2014년에는 한국에서도 작은 움직임이 있었습니다. PostgreSQL Korea User Group이 EDB, 다우기술, 펜타시스템 협업으로 출범한 기록이 남아 있습니다.

Act 3. 2020~2024​

통합과 상실의 시대입니다.

2020년 9월 30일, EDB가 2ndQuadrant 인수를 완료했습니다. 이로써 EDB는 "가장 큰 PostgreSQL 전용 회사"가 됐고, Simon Riggs는 EDB Fellow가 됐습니다. 한 시대가 다른 시대를 흡수한 순간이었습니다.

2021년에는 Neon이 설립됐습니다. 설립자는 Nikita Shamgunov(니키타 샴구노프)/Heikki Linnakangas(헤이키 린나캉가스)/Stas Kelvich(스타스 켈비치) 3인입니다. 서버리스 + 브랜칭 모델로 시작했고, 이 회사는 4년 뒤 Databricks의 손에 들어갔습니다.

2022년 6월, Bain Capital(베인 캐피털) Private Equity가 EDB의 다수 지분을 가져갔습니다. PostgreSQL 최대 후원사가 사모펀드의 자산이 된 셈입니다.

Simon Riggs는 2024년 3월 26일, 영국 Duxford 비행장에서 본인이 조종하던 Cirrus SR22-T 사고로 별세했습니다. PITR, Hot Standby, 동기화 replication을 만든 사람의 죽음을 PostgreSQL 커뮤니티는 길게 애도했습니다. 공식 부고는 postgresql.org에 남아 있습니다.

사흘 뒤인 3월 29일, Andres Freund가 xz Utils backdoor를 발견했습니다. 같은 주에 PostgreSQL은 한 사람을 잃었고, 또 한 사람의 발견은 리눅스 생태계 전체를 구했습니다.

Greenplum(그린플럼)의 운명도 이 시기에 결정됐습니다. 2010년 EMC가 인수했던 이 PostgreSQL 기반 MPP 데이터베이스는 Pivotal(피보탈)/VMware(VM웨어)/Broadcom(브로드컴)을 거쳤습니다. 2024년 5월, Broadcom이 Greenplum을 closed-source로 전환했습니다. 오픈소스 PostgreSQL 변형이 사유 제품이 된 첫 큰 사례입니다.

같은 시기 K8s 쪽에서는 CloudNativePG가 자라났습니다. EDB의 Gabriele Bartolini(가브리엘레 바르톨리니)가 이끄는 프로젝트로, 2025년 1월 CNCF Sandbox에 정식 진입했습니다. PostgreSQL이 CNCF 산하 데이터베이스가 된 첫 사례입니다.

Act 4. 2025~2026​

클라우드 베어의 시대입니다.

2025년이 무겁습니다. 클라우드 베어 셋이 같은 분기에 PostgreSQL 회사를 다 가져갔습니다.

세 인수는 같은 방향을 가리킵니다. AI agent를 위한 PostgreSQL입니다. Neon은 서버리스 + 브랜칭 모델이라 agent가 매 작업마다 격리된 DB 인스턴스를 만들기에 적합합니다. Crunchy는 규제 산업 고객 기반과 안정적 코어 엔진을 가져왔습니다. HorizonDB는 wire 호환만 유지하고 스토리지는 Rust로 새로 짰습니다.

The Build 블로그의 Christophe Pettus는 이 셋을 한 줄로 정리했습니다.

"Pick the one whose adjacent data platform you already use, and do not pretend you have a choice you don't have."

선택은 이미 쓰고 있는 데이터 플랫폼이 정해 줬다는 뜻입니다. Snowflake 고객은 Snowflake Postgres를 쓰고, Databricks 고객은 Lakebase(레이크베이스)를 씁니다. 셋은 SQL과 기본 PostgreSQL 동작까지는 호환되지만, extension, logical replication, pg_basebackup, pgBackRest, Patroni는 통하지 않습니다.

Crunchy 인수는 빈말로 끝나지 않았습니다. Snowflake는 2026년 2월 24일 Snowflake Postgres를 정식 출시(GA)했습니다. Snowflake 콘솔에서 곧바로 Postgres 인스턴스를 만들고 관리할 수 있으며, AWS/Azure 일부 리전에서 먼저 풀렸습니다. Snowflake는 이를 "fork가 아니라" 기존 PostgreSQL 도구를 그대로 쓰는 lift-and-shift 호환 제품이라고 강조합니다. Crunchy의 엔진과 인력이 실제 상용 제품으로 녹아든 결과입니다.

같은 시기 Timescale은 2025년 6월 TigerData(타이거데이터)로 리브랜드했습니다. 시계열에서 벗어나 agent 데이터베이스를 표방합니다.

막간. 혼자 걸어온 사람들​

회사 인수 흐름과 별개로, PostgreSQL 생태계에는 큰 회사 안에 들어가지 않고 30년 가까이 자기 일을 한 사람들이 있습니다.

Christophe Pettus는 2009년 PGX를 차렸습니다. The Build 블로그는 이 회사의 채널입니다. 2026년 5월 현재도 본인이 직접 CEO, 컨설턴트, 블로거 노릇을 합니다.

Markus Winand(마르쿠스 비난트)는 책 한 권(《SQL Performance Explained》), 웹사이트 둘(use-the-index-luke.com, modern-sql.com), 비엔나에서 진행하는 5일 기업 교육으로 일합니다. 이 셋이 그의 회사 전체입니다. "구루"라는 표현이 가장 어울리는 형태입니다.

Hironobu Suzuki(스즈키 히로노부)는 일본 출신으로, 현재 유럽에 거주합니다. 《The Internals of PostgreSQL》을 비롯해 PostgreSQL 책 4권 + MySQL(마이에스큐엘) 책 3권을 썼습니다. interdb.jp는 그의 평생 작업입니다.

Hubert Lubaczewski(후베르트 루바체프스키, 닉네임 depesz)는 explain.depesz.com을 13년째 혼자 돌립니다. PostgreSQL 버전별 "Waiting for…" 시리즈는 1차 자료입니다. 회사는 본인 이름을 그대로 쓴 DEPESZ SOFTWARE HUBERT LUBACZEWSKI (폴란드)입니다.

Joshua Drake는 1997년 Command Prompt를 차렸습니다. 26년 차 PostgreSQL 컨설팅 회사이며, United States PostgreSQL의 회장이기도 합니다.

그러나 2026년 4월, 이 흐름의 어두운 그림자가 드러났습니다. David Steele(데이비드 스틸)이 13년간 단독으로 유지한 pgBackRest의 archive를 선언했습니다. 이미 pgBackRest의 종료 글에서 한 편 정리한 사건입니다. Crunchy가 후원하다가 Snowflake 인수 이후 자금이 끊어졌고, 그는 13개월간 새 직장을 찾지 못했습니다.

며칠 뒤 Steele은 입장을 일부 바꿨습니다. 다중 스폰서 연합 펀딩으로 전환해 프로젝트를 이어 갈 가능성을 발표했습니다. 구체적 후원 기업명은 아직 공개되지 않았습니다. Christophe Pettus와 Gabriele Bartolini는 이 사건을 같은 문장으로 요약했습니다.

"Open source doesn't die. It gets unfunded."

이 문장은 오픈소스는 죽는 것이 아니라 자금이 끊길 뿐이라는 뜻입니다.

커미터들은 어디에 있는가​

빅테크 흡수의 지도를 살펴봅니다.

2025년 기준 PostgreSQL 커미터 31명의 소속을 단순화해 정리하면 다음과 같습니다.

빅테크 흡수는 진행 중입니다 — Microsoft + AWS만 합쳐도 약 25%입니다. EDB가 약 30%이고, Crunchy는 이제 Snowflake 자회사입니다. 일본 NTT/Fujitsu 라인은 의외로 두텁습니다.

한국은 공식 커미터/코어 멤버 명단에서 확인되는 사람이 없습니다.

거버넌스​

라이선스는 안전한지 살펴봅니다.

먼저 던질 질문이 있습니다. Redis(레디스)/MongoDB(몽고DB)는 라이선스를 일방적으로 바꿨습니다. PostgreSQL도 그렇게 할 수 있을까요.

답은 사실상 불가능합니다. 이유는 단순합니다. PostgreSQL의 코드 소유권이 30년 동안 수천 명의 기여자에게 분산돼 있습니다. 라이선스 변경에는 만장일치에 가까운 동의가 필요합니다. Redis/MongoDB는 단일 회사 소유여서 가능했습니다.

PostgreSQL의 BSD-style 라이선스는 명시적으로 "perpetually free and open source"를 약속합니다. 30년의 분산이 이 약속의 진짜 보증입니다.

위험은 다른 곳에 있습니다. 단일 메인테이너 도구의 자금 단절입니다. pgBackRest가 처음 보여줬고, 다음 사례가 어디서 나올지는 모릅니다.

향후 5년​

2031년의 풍경을 그려 봅니다.

사실에서 추측으로 넘어갑니다. 추측이지만 근거를 함께 적습니다.

가능성 높음:

1. PostgreSQL이 사실상 표준 RDBMS 지위를 굳힙니다. Stack Overflow(스택 오버플로우) 2025 조사에서 개발자 55.6%가 PostgreSQL을 쓴다고 답했습니다. AI workload (pgvector) + OLTP + Analytics를 한 엔진이 다 받는 모델은 경쟁자가 없습니다.

2. "PostgreSQL"이라는 단어가 흐려집니다. 사용자는 "Postgres를 쓴다"고 말하지만 실제로는 Aurora, Lakebase, HorizonDB, Snowflake Postgres 중 하나를 쓰는 식이 됩니다. extension 호환성이 가장 먼저 깨집니다.

3. AI agent가 PostgreSQL을 "skill"로 등록하는 패턴이 표준이 됩니다. Supabase의 ChatGPT 공식 앱, Microsoft의 MCP for PostgreSQL이 출발선입니다.

갈등 지점:

1. 단일 메인테이너 도구의 줄도산. Barman은 EDB가 받아 안정적이지만, pgBackRest 사건은 다른 도구에도 일어날 수 있습니다. Cybertec(사이버텍)의 pg_timetable, depesz.com 같은 1인 운영 자원의 지속성을 묻는 시기가 옵니다.

2. K8s 운영자(operator)의 표준 경쟁. CloudNativePG가 CNCF 산하 단일 표준으로 가려면 시간이 더 필요합니다. Crunchy PGO는 Snowflake 인수 이후 장기 전략이 불투명하고, Zalando(잘란도)/StackGres(스택그레스)는 각자 자리를 지키고 있습니다.

3. PostgreSQL 코어팀의 빅테크 의존도. EDB, Microsoft, AWS, Snowflake가 커미터 절대다수를 고용하고 있습니다. 라이선스는 안전해도, 로드맵의 무게중심은 조용히 이동합니다.

작게 가능한 시나리오:

1. OrioleDB 같은 새 storage engine이 코어에 들어갑니다. 현재 public beta입니다. Alexander Korotkov가 Supabase로 옮긴 뒤 Supabase가 후원합니다. 2028년 전후로 production 후보가 될 가능성이 있습니다.

2. 벤더 중립 우산 조직이 생깁니다. Gabriele Bartolini와 ProOpenSource(프로오픈소스)가 제안한 모델입니다. Apache Software Foundation(아파치 소프트웨어 재단)/Codeberg e.V.(코드버그)처럼 PostgreSQL 도구의 거버넌스를 단일 회사에서 분리하는 흐름이며, 아직 제안 단계입니다.

닫으며​

이 이야기에서 무엇이 남는지 생각해 봅니다.

PostgreSQL의 30년에는 두 줄이 동시에 흘러왔습니다. 한쪽에는 Heroku, Citus, OpenSCG, Crunchy, Neon, Timescale로 이어진 회사들의 인수와 흡수가 있고, 다른 쪽에는 Tom Lane, Bruce Momjian, Christophe Pettus, Markus Winand, David Steele처럼 코드와 책과 도구를 30년 가까이 자기 손으로 들고 있는 개인들이 있습니다.

2026년의 풍경은 회사 쪽이 훨씬 시끄럽지만, 무게는 결국 개인 쪽으로 다시 돌아오리라 봅니다. 클라우드 베어 셋이 같은 분기에 PostgreSQL 회사를 다 가져갔어도, Andres Freund가 SSH 로그인의 500ms 차이로 xz backdoor를 잡아낸 순간이 어느 회사의 분기 실적보다 더 오래 기억될 것입니다.

오픈소스는 죽지 않고 자금이 끊길 뿐이라는 말처럼, 다음 30년의 PostgreSQL은 결국 어떤 사람이 어디서 누구의 자금으로 일하느냐에 달려 있어요.

부록. 1986~2026 전체 연표​

1980년대​

• 1986/UC Berkeley에서 POSTGRES 프로젝트 시작 (Michael Stonebraker)

1990년대​

• 1995/POSTGRES → PostgreSQL로 이름 변경. SQL 인터페이스 도입
• 1996/PostgreSQL 6.0 첫 정식 릴리스. Tom Lane/Bruce Momjian 등 코어 합류
• 1997/Joshua Drake, Command Prompt 설립 (미국 몬태나)

2000년대​

• 2002/Simon Riggs, 2ndQuadrant 설립 (영국/이탈리아)
• 2004/EnterpriseDB (EDB) 설립
• 2006/Bruce Momjian, EDB 합류
• 2009/Christophe Pettus, PGX 설립

2010~2015​

• 2010/Citus Data 설립
• 2010-07/EMC, Greenplum 인수
• 2010-11/Heroku에 PostgreSQL 도입
• 2010-12-08/Salesforce → Heroku 인수, 약 2억 1,200만 달러
• 2011-11/Heroku Postgres 분리 제품 출시
• 2012/Crunchy Data 설립 (Laurence 형제)
• 2012/Greenplum, Pivotal로 재조직
• 2014/Peak Equity Partners → EDB 다수 지분 인수
• 2014/PostgreSQL Korea User Group 출범 (EDB, 다우기술, 펜타시스템)
• 2015/Tom Lane, Crunchy Data 합류
• 2015/Timescale 설립
• 2015/Alexander Korotkov, Postgres Professional 공동 설립

2016~2019​

• 2016/Aiven 설립 (Saarenmaa, Valtonen, Nousiainen)
• 2018-04경/AWS → OpenSCG 인수
• 2019-01-24/Microsoft → Citus Data 인수
• 2019/Great Hill Partners → EDB 다수 지분 인수

2020~2023​

• 2020/Supabase 설립 (Copplestone/Wilson)
• 2020/VMware → Pivotal/Greenplum 인수
• 2020-09-30/EDB → 2ndQuadrant 인수 완료
• 2021/Neon 설립 (Shamgunov, Linnakangas, Kelvich)
• 2022-05/Aiven 시리즈 D, 2억 1,000만 달러
• 2022-06/Bain Capital → EDB 다수 지분 인수
• 2023/Alexander Korotkov, Postgres Professional → Supabase
• 2023-11/Broadcom → VMware 인수 (Greenplum 포함)

2024: 상실의 해​

• 2024-03-26/Simon Riggs 별세 (영국 Duxford, Cirrus SR22-T 사고)
• 2024-03-29/Andres Freund, xz Utils backdoor 발견 (SSH 500ms 추적)
• 2024-05/Broadcom, Greenplum closed-source 전환
• 2024/Barman 유지보수, 2ndQuadrant → EDB 공식 이관 완료

2025: 클라우드 베어의 분기​

• 2025-01-21/CloudNativePG, CNCF Sandbox 진입
• 2025-05-14/Databricks → Neon 인수, 약 10억 달러
• 2025-06-02/Snowflake → Crunchy Data 인수, 약 2억 5천만 달러
• 2025-06/Timescale → TigerData 리브랜드
• 2025년 중반/Microsoft, HorizonDB 발표 (자체 개발)
• 2025-10/Supabase 시리즈 E, 1억 달러, 프리머니 50억 달러 밸류에이션

2026: 균열의 신호​

• 2026-02-24/Snowflake Postgres 정식 출시(GA), Crunchy 엔진 기반, AWS/Azure 일부 리전
• 2026-04-27/David Steele, pgBackRest archive 선언
• 2026-04-30/Percona Community: "Open source doesn't die. It gets unfunded."
• 2026-05 초/Steele, 다중 스폰서 연합 펀딩 모델 가능성 발표
• 2026-05-12/The Build, "Picking the Lock-In You Want" 발표
• 2026-05-13/PostgreSQL 2026년 5월 보안 업데이트 (CVE 5건, CVSS 8.8 × 3)

1차 출처​

회사/인수:

• Snowflake Acquires Crunchy Data, Businesswire, 2025-06-02
• Snowflake Postgres GA, Snowflake Docs Release Notes, 2026-02-24
• Delivering the Most Enterprise-Ready Postgres, Built for Snowflake, Snowflake Blog
• Databricks Agrees to Acquire Neon, PRNewswire, 2025-05-14
• EDB Completes Acquisition of 2ndQuadrant, 2020-09-30
• Microsoft Acquires Citus Data, 2019-01-24
• Salesforce Acquires Heroku, TechCrunch, 2010-12-08
• Timescale becomes TigerData, 2025-06
• Greenplum closed-source, Broadcom, 2024-05
• Aiven Series D, 2022-05
• Supabase Series E, 2025-10, $5B

커미터/인물:

• PostgreSQL Official Committers
• PostgreSQL Release History
• Remembering Simon Riggs, 2024-03
• Andres Freund, xz Utils backdoor discovery, Wikipedia
• Who Contributed to PostgreSQL in 2024, Robert Haas
• Crunchy welcomes Tom Lane, 2015

컨설턴트/메인테이너:

• The Build, Christophe Pettus
• SQL Performance Explained, Markus Winand
• The Internals of PostgreSQL, Hironobu Suzuki
• explain.depesz.com, Hubert Lubaczewski
• Command Prompt Inc, Joshua Drake
• pgBackRest archived, The Build, 2026-04-27
• Open source doesn't die. It gets unfunded, Percona Community
• Why the cycle of open-source sustainability needs to be virtuous, Gabriele Bartolini

클라우드 전략/미래:

• The Build, Snowflake/Lakebase/HorizonDB lock-in, 2026-05-12
• Databricks, Lakebase 5x faster writes
• Microsoft, Azure HorizonDB announcement
• CNCF, CloudNativePG Sandbox entry, 2025-01-21
• Will PostgreSQL Change Its License?, Jonathan Katz
• PostgreSQL May 2026 Security Update

30년 버틴 init, 5년 만에 갈아치워진 표준​

리눅스에서 PID 1로 부팅 직후 가장 먼저 실행되는 프로세스가 init이에요. 이 자리는 SysVinit이 30년 가까이 지켰지만 2010년대 초반부터 갑자기 풍경이 바뀌었어요. 2011년 Fedora 15에서 등장한 systemd가 5년 만에 거의 모든 메이저 배포판의 기본 init을 차지했고, 그 사이에는 Upstart가 잠깐 등장했다 사라졌죠.

이 글은 세 init 시스템을 기능 비교 대신 연표로 다룹니다.

• 어떤 배포판이 언제 SysVinit을 버렸는가
• Upstart는 왜 짧게 살았는가
• systemd 채택을 둘러싼 Debian 투표, Devuan 분기, Ubuntu의 입장 변화는 어떻게 흘러갔는가
• 지금도 systemd를 쓰지 않는 배포판은 어디인가

서버에 SSH로 들어가서 ps -p 1 -o comm=을 한 번 실행했을 때, 출력 한 줄이 어떤 역사 위에 서 있는지 정리해 보겠습니다.

세 세대, 한눈에​

세 시스템의 본질적 차이는 한 줄로 줄일 수 있습니다. SysVinit은 셸 스크립트를 순서대로 돌리고, Upstart는 이벤트가 발생하면 잡(job)을 돌리며, systemd는 의존성 그래프를 따라 유닛(unit)을 병렬로 돌린 뒤로도 계속 지켜봅니다.

1세대: SysVinit (1983~)​

뿌리는 AT&T가 1983년에 낸 Unix System V입니다. 리눅스에는 1990년대 초 Miquel van Smoorenburg(미컬 반 스모렌부르흐)가 포팅한 sysvinit 패키지로 흘러들어왔고, 그 후 약 20년간 거의 모든 리눅스 배포판의 기본 init이 됐습니다.

핵심 구조는 단순합니다.

/etc/inittab          → 어느 런레벨에 어떤 스크립트를 돌릴지 선언
/etc/init.d/*         → 각 서비스의 start/stop/restart 스크립트
/etc/rc{0..6}.d/      → 런레벨별 심볼릭 링크 (S20foo, K80foo …)

런레벨(runlevel)은 시스템의 모드 번호입니다. 관습적으로 7개를 씁니다.

런레벨 진입 시 /etc/rcN.d/의 S로 시작하는 링크를 번호 순으로 실행하고, 빠져나갈 때 K 링크를 실행합니다. 부팅이란 곧 "셸 스크립트를 정해진 순서대로 한 줄씩 돌리는" 일이었습니다.

SysVinit의 한계​

SysVinit이 30년을 살아남은 건 단순함 덕이고, 5년 만에 밀려난 것도 그 단순함 탓입니다.

가장 큰 문제는 직렬 부팅이었습니다. S20foo가 끝나야 S21bar가 시작되니, CPU가 놀고 있어도 두 서비스가 서로 무관해도 순서를 바꿀 수 없었고 이게 부팅이 느린 결정적 이유였습니다. 의존성 표현이 약한 것도 여기 얽힙니다. "DB가 떠 있어야 web이 뜬다" 같은 관계를 번호(S20, S21)로만 나타냈고, LSB 헤더가 의존성 기술을 거들긴 했지만 여전히 선형 정렬이 전제였습니다.

나머지 둘은 프로세스 관리 쪽입니다. 스크립트가 &로 백그라운드에 넘긴 자식을 init이 직접 추적하지 않아 PID 파일이 진실의 원천이 되는데, 이게 어긋나면 service foo status가 거짓말을 하고 자식이 더블 fork로 도망가면 더 곤란해집니다. 서비스가 죽었을 때 되살리는 것도 init 밖의 일이라, respawn을 inittab에 직접 걸거나 monit/supervisord 같은 외부 도구를 끌어와야 했습니다.

이 한계들이 2000년대 후반 "부팅이 빨라야 하는 노트북"과 "의존성 많은 데스크톱 환경"의 시대와 충돌했습니다. 다음 두 세대는 모두 이 중 하나 이상을 풀려고 출발합니다.

2세대: Upstart (2006~)​

Canonical의 Scott James Remnant(스콧 제임스 렘넌트)가 만들었습니다. 첫 출시는 **Ubuntu 6.10 "Edgy Eft" (2006-10)**입니다. 이때부터 Ubuntu의 기본 init은 SysVinit이 아니라 Upstart였습니다(호환 모드로 SysV 스크립트도 돌렸습니다).

Upstart의 출발점은 "부팅은 단순한 순서가 아니라 일련의 사건들이다"라는 발상입니다. USB가 꽂히고 네트워크가 올라오며 디스크가 마운트되는 등, 이벤트가 발생할 때마다 그에 맞는 잡이 트리거되도록 모델을 짰습니다.

설정은 /etc/init/*.conf에 한 잡씩 둡니다.

description "Hello Web"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5

exec /usr/local/bin/hello-web --port 8080

respawn 한 줄로 자동 재시작이 해결되고, start on filesystem and net-device-up 식으로 이벤트 조합도 가능했습니다. SysVinit에 비하면 진짜 진보였습니다.

채택도 빨랐습니다. **Ubuntu 9.10 "Karmic Koala" (2009-10)**에서 SysV 호환 레이어 없이 native Upstart 부팅을 기본화했고, **RHEL 6 (2010-11)**이 정식 채택했습니다. Google의 ChromeOS와 일부 Fedora 릴리스도 한때 Upstart를 썼습니다.

Upstart가 짧게 살았던 이유​

그런데 RHEL 6 이후 Upstart의 채택은 거기서 멈춥니다. 2010년대 초반 새로 등장한 systemd로 흐름이 갈아탔고 Ubuntu 본진마저 결국 같은 길을 갔는데, 단순히 "더 좋은 게 나왔다"로는 설명이 부족합니다.

가장 자주 꼽히는 건 Canonical의 CLA 정책입니다. Upstart 코드에 기여하려면 Canonical이 요구하는 Contributor License Agreement에 동의해야 했는데, 받은 코드를 상용으로 재배포할 권리를 회사에 양도하는 형태라 다른 진영이 부담스러워했습니다. 같은 시기 Linux 커널을 비롯한 여러 핵심 프로젝트가 CLA 없이 기여를 받던 흐름과 대조됐습니다.

기술적 한계도 겹쳤습니다. "A 이후 B" 같은 단순 의존이 이벤트 모델로는 어색했던 반면, systemd가 들고 나온 의존성 그래프와 Wants= / Requires= / After= 선언이 더 자연스럽다는 평가가 빠르게 자리 잡았습니다. 자식 프로세스 추적도 Upstart는 SysVinit과 비슷한 한계 안에 머물러, cgroup을 fork-bomb에도 끄떡없는 추적 수단으로 쓴 systemd에 비하면 약했습니다. 여기에 Fedora와 RHEL이 systemd를 적극적으로 밀면서 큰 생태계 플레이어 하나가 Upstart 진영에서 빠져나갔고, RHEL 6의 Upstart는 단명한 뒤 RHEL 7부터 systemd로 갔습니다.

결정타는 Debian과 Ubuntu가 차례로 systemd로 넘어간 시점입니다. 그 부분은 뒤에서 따로 정리합니다.

3세대: systemd (2010~)​

2010년 4월, Red Hat의 Lennart Poettering(레나르트 푀터링)과 Kay Sievers(카이 지버스)가 발표한 글 한 편("Rethinking PID 1")으로 등장합니다. 핵심 아이디어는 세 가지였습니다.

첫째는 의존성 기반 병렬 부팅입니다. 유닛(*.service, *.socket, *.target 등)이 의존성을 명시하고, 의존성이 풀린 것부터 병렬로 출발합니다. 둘째는 소켓 활성화(socket activation)로, 데몬을 미리 띄우는 대신 systemd가 먼저 listen 소켓을 열어두고 첫 연결이 들어올 때 데몬을 깨웁니다. macOS의 launchd에서 영감을 받은 모델입니다. 셋째는 cgroup 기반 프로세스 추적입니다. 서비스가 fork한 자식과 손자까지 cgroup에 묶여 정확히 추적/정리되므로 PID 파일 위조나 더블 fork로 도망갈 수 없습니다.

이 세 가지가 동시에 풀린 게 결정적이었습니다. 이전 세대가 풀지 못한 한계를 한꺼번에 정리했고, 부팅 시간 단축이라는 가시적 효과도 따라왔습니다.

다만 systemd는 init만이 아니라 logind, journald, networkd, resolved, timedated 등 시스템 영역의 여러 컴포넌트를 흡수해 갔고, "Unix 철학과 어긋난다"는 비판도 같은 시기에 나왔습니다. 이 글은 그 논쟁에 한 발 들이지 않고, 채택 흐름만 따라갑니다.

systemd 채택 연표​

발표 시점부터 메이저 배포판들의 채택 시점을 연도순으로 보면 흐름이 분명해집니다.

4년 (2011~2015) 만에 Fedora, RHEL, Debian, Ubuntu, openSUSE, Arch가 모두 systemd로 정렬됩니다. 이 정도 속도로 init 같은 핵심 컴포넌트가 통일된 적은 리눅스 역사에 거의 없습니다.

Debian의 투표와 Devuan 분기​

Debian은 의사결정에 시간이 오래 걸리는 프로젝트입니다. systemd 채택도 예외가 아니어서 2013년 후반부터 Technical Committee 안에서 격론이 오갔고, 결국 2014년 11월 표결로 Debian 8 "Jessie"의 기본 init은 systemd로 결정됩니다.

표결 자체는 그것대로 정리됐지만, 같은 결의에 끼어 있던 또 다른 항목, 즉 "패키지가 systemd 의존성을 강제로 걸 수 있느냐"가 분기를 불렀습니다. 결의는 "다른 init 시스템 지원이 권장되지만 의무는 아니다(recommended, but not mandatory)"로 나왔습니다. 패키지가 systemd 외에 안 돌게 만들어도 막지 않는다는 의미였습니다.

이 결과에 반발한 일부 Debian 사용자/개발자가 "Veteran Unix Admins" 이름으로 2014년 11월 27일 Devuan 분기를 발표합니다. 약 2년 반의 패키지 감사/수정 끝에 2017년 5월 25일 Devuan 1.0 "Jessie"가 나왔습니다. Debian 8을 베이스로 systemd 훅을 모두 들어내고 SysVinit(또는 OpenRC)을 기본 init으로 하는 버전입니다.

Devuan은 이후로도 Debian을 한 단계씩 따라가며 출시를 이어가고 있습니다. 규모는 작지만 "systemd 없이도 Debian 생태계를 쓰고 싶다"는 수요에 답하는 진영으로 살아남았습니다.

Ubuntu가 자존심을 접은 결정​

Ubuntu에게 init은 단순한 부품이 아니었습니다. Upstart는 Canonical의 자체 프로젝트였고, 거의 10년간 Ubuntu의 기본 init이었습니다. 그런데 Debian이 systemd로 결정한 직후, Mark Shuttleworth(마크 셔틀워스)는 "Ubuntu도 upstream(Debian)과 보조를 맞추겠다"고 발표합니다.

마이그레이션은 비교적 부드러웠습니다. Ubuntu 15.04 "Vivid Vervet"(2015-04-23)에서 기본 init이 systemd로 전환됐고, Ubuntu Touch(모바일)만 예외였습니다. 이후 15.04부터 16.10까지는 부팅 시 GRUB에서 Upstart와 systemd를 고를 수 있는 듀얼 부팅 기간을 유지했는데, 회귀가 생겼을 때 도망갈 길을 일정 기간 열어둔 운영적 선택이었습니다. 16.10 이후 Upstart 옵션이 제거되면서 이때부터 Ubuntu는 완전히 systemd 단독으로 갔습니다.

Canonical 입장에서는 자기 프로젝트를 접고 경쟁 프로젝트를 받아들인 결정이었지만, 그 무렵엔 systemd가 사실상 표준이 된 상태였고 Debian과 다른 init을 유지하는 비용이 더 커졌습니다.

systemd를 안 쓰는 배포판들​

2026년 현재도 systemd가 아닌 init을 기본으로 쓰는 배포판이 남아 있습니다. 컨테이너 베이스 이미지나 임베디드, 보수적 운영을 위한 선택지로 의외로 자주 등장합니다.

여기서 중요한 점이 하나 있습니다. Alpine은 컨테이너 이미지 시장에서 표준급 점유율을 가지고 있습니다. "제 노트북은 Ubuntu고 systemd만 만져봤다"고 해도, 컨테이너에 FROM alpine:... 한 줄을 넣는 순간 OpenRC 기반 시스템과 만납니다. 다만 컨테이너 안에서는 init이 거의 의미를 갖지 않는다는 별도의 이슈가 있는데, 그건 마지막에서 다시 봅니다.

같은 작업, 세 가지 표현​

세 init 시스템의 차이를 가장 빨리 느끼는 방법은 같은 서비스를 세 가지 형식으로 옆에 두고 보는 것입니다. hello-web이라는 가상의 HTTP 서버를 부팅 시 자동 기동하고 죽으면 자동 재시작하도록 등록한다고 해보겠습니다.

SysVinit: /etc/init.d/hello-web​

#!/bin/sh
### BEGIN INIT INFO
# Provides:          hello-web
# Required-Start:    $network $remote_fs
# Required-Stop:     $network $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: hello web server
### END INIT INFO

DAEMON=/usr/local/bin/hello-web
PIDFILE=/var/run/hello-web.pid

case "$1" in
  start)
    start-stop-daemon --start --background \
      --make-pidfile --pidfile $PIDFILE \
      --exec $DAEMON
    ;;
  stop)
    start-stop-daemon --stop --pidfile $PIDFILE
    rm -f $PIDFILE
    ;;
  restart)
    $0 stop; sleep 1; $0 start
    ;;
  status)
    [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE) 2>/dev/null \
      && echo "running" || echo "stopped"
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|status}"; exit 1
    ;;
esac

그 후 update-rc.d hello-web defaults(Debian 계열) 또는 chkconfig hello-web on(RHEL 계열)으로 런레벨 링크를 만들어야 합니다. 자동 재시작은 별도 도구가 필요합니다.

Upstart: /etc/init/hello-web.conf​

description "hello web server"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5

exec /usr/local/bin/hello-web --port 8080

스크립트가 아니라 선언문입니다. start-stop-daemon, PID 파일, status 분기, 런레벨 링크가 전부 사라졌습니다. respawn 한 줄로 자동 재시작도 끝납니다.

systemd: /etc/systemd/system/hello-web.service​

[Unit]
Description=hello web server
After=network.target

[Service]
ExecStart=/usr/local/bin/hello-web --port 8080
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target

등록은 systemctl enable --now hello-web 한 줄. 의존성을 After=로 명시하고, 재시작 정책도 Restart=on-failure로 명확합니다. 자식 프로세스 추적은 cgroup이 알아서 해줍니다.

같은 의도가 41줄에서 9줄, 다시 12줄로 짧아집니다. 줄어든 만큼 init이 책임지는 부분과 사용자가 짜야 하는 부분의 경계가 옮겨갔다는 뜻입니다.

컨테이너 시대의 init: PID 1 문제​

여기까지가 "호스트 OS의 init" 이야기였습니다. 그런데 컨테이너 시대로 들어오면 init의 의미가 한 번 더 뒤집힙니다.

도커 컨테이너 안에서 PID 1은 실제 init 시스템 대신 사용자가 실행한 프로세스입니다. CMD ["node", "server.js"]면 node가 PID 1이 됩니다. 그런데 PID 1에는 두 가지 특별한 책임이 있습니다.

하나는 좀비 자식 프로세스 수확입니다. 자식이 죽으면 부모가 wait()으로 거둬야 좀비가 정리되는데, PID 1이 이걸 안 하면 좀비가 영구히 쌓입니다. 다른 하나는 시그널 처리입니다. 커널은 PID 1에게 기본 시그널 핸들러를 붙여주지 않아서, 명시적으로 처리하지 않으면 SIGTERM이나 SIGINT가 무시됩니다.

대부분의 애플리케이션은 이 두 가지를 신경 쓰고 만들어지지 않았습니다. 그래서 컨테이너 생태계에는 경량 init들이 등장했습니다.

tini는 Docker가 --init 플래그로 채택한 사실상 표준입니다. dumb-init은 Yelp가 만든 alternatives이고, s6-overlay는 컨테이너 안에서 멀티 프로세스를 다룰 때 씁니다.

Kubernetes는 이 문제를 한 단계 더 위에서 다룹니다. Pod 종료 시 컨테이너 PID 1에 SIGTERM을 보내고 grace period 후 SIGKILL로 가는데, 앱이 SIGTERM을 안 잡으면 매번 강제 종료가 발생합니다. (이 흐름은 SIGINT, SIGTERM, SIGHUP, SIGKILL: 쿠버네티스 시대의 유닉스 시그널에서 깊게 다뤘습니다.)

호스트의 init은 의존성과 부팅 속도를 고민하지만, 컨테이너의 PID 1은 시그널 전파와 좀비 수확이라는 더 원초적인 책임으로 돌아갑니다.

한 줄로​

SysVinit의 30년은 단순함이 호환성을 만든 시대였고, systemd의 5년은 의존성과 cgroup이 표준을 만든 시대였어요. 그 사이의 Upstart는 좋은 아이디어 한 가지로 잠깐 빛났지만 큰 생태계의 흐름을 못 이긴 사례로 남았고, PID 1 자리에 무엇이 앉느냐는 결국 그 시대 운영체제가 무엇을 가장 중요하게 여기는지를 비추는 거울이에요.

→ 다음 편: systemd 유닛이라는 언어: 11종을 한 바퀴. 이 글에서 살짝만 비춘 유닛 11종이 cron, fstab, inetd, autofs, inotify 같은 옛 도구를 어떻게 흡수했는지 한 바퀴 돕니다.

참고​

• Wikipedia의 init 문서
• Wikipedia의 systemd 문서
• Wikipedia의 Upstart (software) 문서
• Wikipedia의 Devuan 문서
• Rethinking PID 1 — Lennart Poettering (2010)
• Fedora Project Wiki의 Features/systemd
• Ubuntu — A Journey from System V to System D — packagecloud
• It's Easy To Switch Between Upstart & Systemd Right Now On Ubuntu 15.04 — Phoronix
• Debian systemd Controversy Results in Fork — InfoQ