거의 40년 된 Tcl/Tk, 왜 지금도 크로스플랫폼 도구의 대안이 되나

크로스플랫폼 데스크톱 도구를 만들어야 할 때 개발자들은 대개 Electron이나 Flutter 같은 최신 프레임워크를 떠올린다. 그러나 이런 접근에는 공통된 한계가 있다. 이 글의 원저자는 오랫동안 AutoHotkey v2로 윈도우용 소형 유틸리티를 만들어 왔는데, C 계열에 가까워진 문법 덕분에 자바스크립트나 C# 경험자에게는 쓰기 편했지만 결정적으로 윈도우 전용이라는 벽에 부딪혔다고 말한다. Wine 호환 계층으로 리눅스에서 돌릴 수는 있어도 윈도우 고유의 네이티브 호출이 제대로 작동한다는 보장이 없었다. 대안을 찾던 그가 도달한 결론은, 오늘날 '크로스플랫폼'을 표방하는 상당수 GUI 솔루션이 실제로는 이식성이 아니라 '환경을 통째로 싸 들고 다니는' 방식이라는 점이다. OS의 네이티브 UI API를 호출하지 않고 캔버스에 픽셀을 그리기 때문에 결과물이 네이티브 앱처럼 보이지 않는 경우가 많다.

이런 문제의식 끝에 그가 다시 발견한 것이 1990년 존 오스터하우트가 만든 Tcl(Tool Command Language)과 그 GUI 툴킷 Tk였다. Tcl은 원래 고성능 컴파일 코드와 사람이 읽기 쉬운 유연한 로직 계층을 이어 주는 '아키텍처용 접착제', 즉 글루 언어로 설계됐다. 글루 언어란 핵심 연산을 직접 수행하기보다 서로 별개로 만들어진 소프트웨어 구성 요소들을 연결하고 데이터 흐름을 조율하며 복잡한 내부 처리를 간단한 명령으로 감싸는 역할을 한다. 명령줄만으로는 사용자 상호작용에 한계가 있다는 점을 오스터하우트가 곧 깨달으면서 GUI 툴킷 Tk가 더해졌고, 이후 Tk가 워낙 널리 쓰이면서 흔히 'Tcl/Tk'로 함께 불리게 됐다. 그 공로로 1997년 그는 ACM 소프트웨어 시스템 상을 받았다.

조용히 세상을 떠받쳐 온 언어

Tcl의 역설은 가장 덜 '유명한' 언어 축에 속하면서도 거의 40년간 어디에나 쓰여 왔다는 데 있다. 원저자는 미션 크리티컬 시스템, 고사양 네트워킹 장비, 대형 은행의 거래 처리 같은 영역에서 Tcl이 동작해 왔다고 설명한다. 핵심이 순수 C로 작성돼 매우 작기 때문에 우리가 매일 쓰면서도 인식하지 못하는 장치들 속에 임베디드되어 있다는 것이다. 특히 흥미로운 사실은 세계에서 가장 많이 배포된 데이터베이스 엔진 SQLite가 처음에는 Tcl 확장으로 만들어졌다는 점이다. SQLite의 저자 리처드 힙 역시 Tcl 커뮤니티의 일원이며, 원저자는 SQLite의 성공에 그 'Tcl 시절'이 중요한 배경이 됐다고 전한다.

Tk와 Tcl의 관계는 게임 개발에서 유니티나 언리얼 엔진이 OpenGL·Vulkan에 대해 갖는 관계에 비유된다. 대다수 개발자가 스스로를 'OpenGL 개발자'가 아니라 '유니티 개발자'로 소개하듯, 가치와 커뮤니티는 추상화 계층인 Tk에 모이고 그 아래 언어는 일종의 구현 세부사항이 된다. 콘솔 앱을 GUI 앱으로 바꾸는 데도 Tk 패키지를 '요청'하기만 하면 되고, 그러면 몇 줄의 코드로 네이티브에 가까운 인터페이스를 만들 수 있다는 점이 Tcl을 선택하는 핵심 이유 중 하나로 꼽힌다.

이식성과 하위 호환성이라는 강점

실무 관점에서 Tcl/Tk의 가장 큰 매력은 이식성과 하위 호환성이다. 잘 작성된 C 구현 덕분에 윈도우, 리눅스, macOS는 물론 CLI 앱은 Termux를 통한 안드로이드, GUI 스크립트는 Androwish(안드로이드)나 iWish(iOS)로 실행할 수 있고 ARM, x86, RISC-V 등 다양한 CPU 아키텍처를 지원한다. 재컴파일 없이 여러 환경에서 같은 스크립트가 돌아간다는 것은 도구 배포 부담을 크게 줄여 준다. 버전 간 업데이트에 신중한 태도를 유지해 온 덕분에 1995년에 작성된 스크립트가, 특히 순수 Tcl이나 Tk 명령에만 의존한다면 오늘날에도 대체로 그대로 실행된다. 게다가 BSD 라이선스 기반이라 수정, 재배포, 판매까지 사실상 제약 없이 허용된다.

다만 이 유연성은 양날의 검이다. Tcl 코드는 공백이나 탭으로 구분된 '단어'들의 나열이며, 각 단어는 직접 입력되거나 다른 명령이 반환한 값으로 채워져 완성된 명령 문자열을 이룬다. 문법은 흔히 '도데카로그'라 불리는 12개의 기본 규칙으로 이뤄져 있다. '모든 것은 문자열'이라는 접근, 코드가 곧 데이터이고 데이터가 곧 코드가 되는 동형성(homoiconicity), 이벤트 기반 철학은 분명 개성이지만, 자바스크립트나 파이썬처럼 구조가 비교적 엄격한 언어에 익숙한 현대 개발자에게는 오히려 진입 장벽이 된다고 원저자는 솔직히 인정한다. 실제로 원문은 문자열을 다룰 때 값에게 스스로 다듬으라고 요청하는 대신 string 앙상블 안의 range 같은 도구를 호출해 넘겨받은 데이터를 처리하는 함수적 방식을 예로 든다.

무엇을 취할 것인가

정리하면 이 글은 'Tcl이 부당하게 잊힌 최고의 언어'라는 식의 과장을 경계하면서도, 신뢰성·하위 호환성·크로스플랫폼 호환성이 최우선인 영역에서 Tcl/Tk가 여전히 실용적 선택지임을 보여 준다. 한국의 실무자 입장에서 보자면, 사내 유틸리티나 운영 도구처럼 화려한 UI보다 여러 OS에서 오래도록 안정적으로 도는 것이 중요한 소형 도구에 검토해 볼 만하다. 배포 환경별로 CLI와 GUI 진입점을 구분하고 싶다면 윈도우용 Magicsplat 배포판이 제공하는 .tclapp, .tkapp 같은 관례를 따르는 방법도 있다. 최신 스택이 주는 생태계와 채용 시장의 이점을 포기하기 어려운 현실을 감안하면 모두에게 권할 기술은 아니지만, 무거운 런타임을 싸 들고 다니지 않으면서 네이티브에 가까운 도구를 만들고 싶다면 한 번쯤 진지하게 들여다볼 가치는 충분하다.