1996년 GIMP가 2026년 리눅스에서 부활하다 — 오픈소스의 보존력

▲ 이미지: Unsplash (무료 저작권, 상업 이용 가능)

---

무슨 일이 있었나 — GIMP 0.54.1 Flatpak 프로젝트

2026년 6월, 닉네임 balooii로 활동하는 개발자가 GNOME GitLab에 프로젝트 하나를 공개했다. 내용은 간결했다. 1996년 릴리스된 GIMP 0.54 계열(0.54.1)을 현대 64비트 리눅스에서 실행할 수 있도록 Flatpak으로 패키징한 것이다. 패키지 파일명은 gimp-0.54.1-13.flatpak이며, 설치 명령어 한 줄(flatpak install --user gimp-0.54.1-13.flatpak)로 데스크톱에 올릴 수 있다.

실행 환경은 Wayland + xwayland 조합이다. 1990년대 X11 전용으로 설계된 앱을 현대 디스플레이 서버에서 돌리는 셈이다. 텍스트 도구를 사용하려면 레거시 X11 코어 폰트 패키지(xfonts-base 등)를 별도 설치해야 할 수 있다는 점도 안내되어 있다. 지원 포맷은 JPEG·PNG·GIF·TIFF·XPM·TGA이며, 레이어 기능은 없다. 이펙트와 이미지 연산 메뉴는 캔버스 우클릭으로 접근한다. 유지관리자 스스로 “이 두 사람을 위해 만들었다(for the two people out there)”고 적을 만큼, 실용보다는 소프트웨어 고고학에 가까운 프로젝트다.

그러나 그 이면에는 만만치 않은 기술적 작업이 있었다. 저장소에는 11개의 패치가 포함되어 있으며, 현대 툴체인 호환성 확보, libpng 1.6 API 변경 대응, 그리고 가장 손이 많이 간 64비트(LP64) 이식성 문제 수정이 핵심이었다. 1996년 코드는 포인터와 정수형을 사실상 32비트 동의어로 취급했고, 현대 x86-64 ABI에서는 그 가정들이 곳곳에서 충돌을 일으켰다. LWN 커뮤니티 토론에서는 “컴파일은 되는데 64비트에서 자주 크래시”가 첫 번째 장벽이었다고 회고됐다. balooii는 이 장벽들을 패치로 하나씩 넘었다.

GIMP의 뿌리 — 1995년 버클리 기숙사에서

GIMP의 시작은 1995년 여름, UC 버클리(캘리포니아 대학교 버클리 캠퍼스) 재학생 두 명으로 거슬러 올라간다. 스펜서 킴볼(Spencer Kimball)과 피터 매티스(Peter Mattis)는 CS164(프로그래밍 언어 및 컴파일러 설계) 수업에서 Scheme/Lisp 컴파일러 과제를 내야 했는데, 두 사람은 그 대신 “포토샵과 비슷한 그래픽 이미지 편집 프로그램”을 만들겠다고 결정했다. 1995년 7월 피터 매티스가 인터넷 커뮤니티에 “어떤 기능이 필요하냐”고 묻는 글을 올린 것이 GIMP 역사의 공식 첫 장이다.

약 9~10개월의 개발 끝에 1995년 11월 베타 버전이 공개됐고, 1996년 1월에 버전 0.54가 GIMP의 첫 공개 릴리스로 배포됐다. 초기 이름은 General Image Manipulation Program이었으며, GIMP라는 두문자어는 Pulp Fiction(1994)의 특정 캐릭터에서 착안한 것으로 알려져 있다. 1997년 킴볼과 매티스가 졸업한 뒤 프로젝트가 GNU 프로젝트에 공식 편입되면서 이름이 GNU Image Manipulation Program으로 바뀐다.

버전 0.54는 X11 R5/R6와 Motif 1.2 위젯 툴킷을 기반으로 했다. Motif는 당시 유닉스 데스크톱의 사실상 표준 GUI 라이브러리였으나 비자유 소프트웨어였다. 이 의존성이 오픈소스 방식 배포를 가로막자, GIMP 개발자들은 자체 위젯 툴킷을 직접 만들기로 결심한다. 그 결과물이 오늘날 GNOME 데스크톱 전체의 기반이 된 GTK(GIMP Toolkit)다. GIMP 0.54는 GTK 이전의 마지막 릴리스로서, 이후 데스크톱 리눅스의 시각적 정체성을 바꿔놓을 분기점 직전의 스냅샷이기도 하다.

Tux를 낳은 소프트웨어

GIMP 0.54는 역사적으로 특별한 산출물 하나를 남겼다. 리눅스 공식 마스코트 Tux가 바로 이 버전으로 만들어졌다. 아티스트 래리 유잉(Larry Ewing)이 GIMP 0.54를 사용해, 그래픽 태블릿도 없이 마우스만으로 그려낸 캐릭터다.

오늘날 리눅스가 부팅할 때, 서버 터미널에 뜨는 패키지 목록에, 수백만 장의 배포판 스티커에 찍혀 있는 그 Tux가 GIMP 0.54의 작품이다. 이 사실 하나만으로 이번 Flatpak 프로젝트가 단순한 오타쿠적 복원을 넘어선다고 볼 여지가 있다. “Tux를 만든 그 도구를 지금 내 노트북에서 직접 실행할 수 있다”는 체험은, 오픈소스 역사를 살아있는 것으로 만드는 방식이다.

왜 30년 전 코드가 지금도 돌아가나 — 오픈소스와 소스 보존

이 프로젝트가 가능했던 핵심 이유는 세 가지다.

첫째, 소스코드가 살아있었다. GPL로 배포된 GIMP 0.54.1의 원본 소스는 30년이 지난 지금도 공개되어 있다. 소스가 없으면 어떤 패치도, 어떤 이식도 불가능하다. 1990년대 상용 소프트웨어는 바이너리만 배포했고, 그 바이너리는 32비트 DOS/Windows 환경에 종속돼 오늘날 실행이 불가능하거나 에뮬레이터에 의존해야 한다. 소스의 유무가 20~30년 스케일에서 소프트웨어 생사를 가른다.

둘째, Flatpak이 의존성 격리를 해결했다. “내 컴퓨터에서는 됐는데”의 고전적 문제는 의존성 불일치에서 비롯된다. 1996년 코드는 당시의 libpng, Motif, X11 API를 전제했다. Flatpak은 이 오래된 의존성을 현대 런타임과 격리된 샌드박스 안에 함께 패키징해, 어떤 최신 배포판에서도 동일한 환경을 재현한다. 컨테이너형 배포가 소프트웨어 고고학의 실용 도구가 된 셈이다.

셋째, 오픈소스 표준(GPL)이 수정과 재배포의 법적 권리를 보장했다. balooii의 작업은 기술적 해킹이기도 하지만 법적으로도 완전히 허용된 행위다. GPL은 수령자에게 “소스를 받아 수정하고 재배포할 권리”를 명시적으로 부여한다. 이 조항이 없었다면 11개의 패치를 적용하고 Flatpak을 공개하는 일 자체가 저작권 침해가 될 수 있었다.

상용 소프트웨어와의 대비 — ‘죽은 소프트웨어’의 문제

같은 1996년으로 돌아가 보자. 당시 그래픽 편집 시장을 지배하던 소프트웨어들 — Corel Draw, Macromedia xRes, PaintShop Pro 구버전들 — 은 오늘날 어떻게 됐을까. 일부는 계승 제품이 존재하지만, 1996년 버전 자체를 현대 OS에서 실행하는 것은 사실상 불가능하다. 소스코드는 기업의 자산으로 잠겨 있고, 런타임 라이브러리 라이선스도 공개되지 않았다. 설령 에뮬레이터로 띄운다 해도 수정·개선·재배포는 법적으로 허용되지 않는다.

이것은 단순히 오래된 도구를 향한 향수의 문제가 아니다. 기업 데이터 보존과 감사 추적의 문제다. 2000년대 초 특정 상용 CAD 소프트웨어로 설계된 도면 파일을 지금 열어야 한다면? 벤더가 사라졌거나 해당 버전 라이선스 서버가 종료됐다면, 그 파일은 사실상 잠겼다. 오픈소스 포맷·오픈소스 도구로 생성된 산출물은 이 위험에서 구조적으로 자유롭다.

또 하나의 대조가 있다. Motif 의존성이 GIMP 초기 배포를 어렵게 만들었을 때, 개발자들은 자체 GTK를 만들었다. 이것이 오늘날 GNOME·수천 개 리눅스 앱의 기반이 됐다. 상용 소프트웨어 생태계에서 이런 포크·재구현은 라이선스 조건 때문에 원칙적으로 불가능하다. 오픈소스의 분기 가능성(forkability)은 소프트웨어 진화의 가속 엔진이기도 하다.

중소기업·실무 시사점

이 이야기가 당장 GIMP를 쓰라는 의미는 아니다. 그러나 소프트웨어 도구를 선택할 때 30년 스케일의 질문 몇 가지를 함께 던져볼 만하다.

• 소스코드 접근 가능성: 벤더가 사라지거나 제품이 단종됐을 때, 내 데이터와 워크플로를 계속 운영할 수 있는가. 오픈소스는 최소한 포크 가능성이라는 탈출구가 있다.
• 포맷 개방성: 저장 포맷이 공개 표준인가 독점 포맷인가. 독점 포맷은 벤더 종속(vendor lock-in)의 핵심 메커니즘이다.
• 패키징 기술의 실용 가치: Flatpak·Docker 같은 컨테이너형 패키징은 30년짜리 복원 실험만이 아니라, 지금 당장 팀 환경 일관성과 배포 재현성에 적용할 수 있는 기술이다.
• 장기 유지보수 커뮤니티: 오픈소스 프로젝트는 원래 팀이 떠나도 커뮤니티가 이어간다. GIMP가 1997년 킴볼·매티스 졸업 후에도 계속 발전한 이유가 이것이다.
• 라이선스 조건 확인: GPL·MIT·Apache 등 오픈소스 라이선스는 수정·재배포 권리를 보장한다. SaaS·독점 라이선스는 서비스 종료 시 데이터 내보내기 정책을 반드시 사전 확인해야 한다.

balooii의 프로젝트는 본인 말대로 “이 두 사람을 위한” 것일 수 있다. 하지만 그 두 사람이 증명한 것은 크다. 소스가 열려 있으면, 도구는 죽지 않는다.

---