'개발자가 아닌 사람'을 위한 언어 EYG, 무엇이 다른가

엑셀 매크로를 짜본 사람, 업무용 자동화 스크립트를 손봐본 사람이라면 익숙한 순환이 있다. 문제를 풀 코드는 어렵지 않게 떠올리지만, 그것을 배포하고 실행하고 버전과 의존성을 관리하는 단계에서 매번 벽에 부딪힌다. EYG(Eat Your Greens)는 바로 이 벽을 겨냥해 만들어진 정적 타입 함수형 언어다. 개발자를 더 뛰어난 개발자로 만드는 도구가 아니라, 프로그래밍을 본업으로 삼지 않는 사람이 신뢰할 수 있고 공유 가능한 프로그램을 만들도록 돕는 것을 목표로 한다. 저자는 스웨덴에서 새 직장을 시작하기 전 비자를 기다리던 10주 동안 이 언어를 만들기 시작했다고 밝힌다.

문제는 '프로그래밍'이 아니라 그 주변이다

저자는 소프트웨어를 만드는 일을 두 범주로 나눈다. 하나는 자신이 풀려는 문제를 코드로 표현하는 일(범주 1)이고, 다른 하나는 배포·실행·릴리스·의존성 관리처럼 소프트웨어를 실제로 돌아가게 만드는 주변 작업(범주 2)이다. 저자가 '메이커(maker)'라 부르는 사람들, 즉 기술적 소양은 있지만 개발을 전업으로 하지 않는 이들은 대개 범주 1은 무리 없이 해내지만 범주 2를 통달할 시간이 없다. 그렇다면 시각적 언어처럼 '프로그래밍 자체를 더 쉽게' 만들려는 흔한 시도는 애초에 잘못된 문제를 풀고 있는 셈이다.

이 관점에서 저자는 엑셀을 다시 읽는다. 엑셀 매크로도 결국 텍스트 프로그래밍이지만, 매크로를 배포하고 실행하는 문제를 완전히 없애버렸다는 점이 핵심이다. 엑셀은 범주 2를 통째로 해결했기 때문에 '가장 인기 있는 프로그래밍 언어'라는 농담이 성립한다. EYG의 야심은 여기에 있다. 범주 2 문제를 플랫폼과 런타임이 자동으로 처리하게 넘기고, 메이커는 오직 자신의 문제를 기술하는 데만 집중하도록 하는 것이다.

게으른 것이 아니라 우선순위가 다르다

저자는 스웨덴에서 자동화 엔지니어들과 일하며 이 필요를 확인했다고 말한다. 이들은 전기·기계·안전 문제를 고민하는 데 소프트웨어만큼의 시간을 쓰는 엄연한 프로그래머다. 저자가 이들에게 정적 타입 함수형 언어 Gleam의 튜토리얼을 권하자, 새로운 패러다임이었음에도 대부분 무난히 끝내고는 '이제 뭘 하면 되냐'고 물었다. 언어의 구성 요소는 익혔지만 그것을 어디에 적용하고 어떻게 배포할지를 몰랐던 것이다. 결국 걸림돌은 언어가 아니라 릴리스와 배포였다.

흥미로운 지적은 개발자만이 '기계에 대한 동정심'을 갖는다는 대목이다. 개발자는 정수 오버플로가 왜 일어나야 하는지 기꺼이 설명하지만, 보통 사람의 반응은 '그건 숫자가 작동하는 방식이 아니다'이다. 저자는 BigInt가 있는 이상 이 '황당하다'는 반응이 99% 옳다고 본다. 또한 개발자는 평균적으로 더 큰 문제를 다루기에, 기존 개발자 도구는 한 사람의 전업 관심에도 못 미치는 작은 문제를 오히려 홀대한다는 것이다.

EYG가 더하고 뺀 것들

구체적으로 EYG는 몇 가지 결정에서 다른 언어와 갈라진다. 타입 시스템은 유지하되, 사용자가 타입을 미리 정의하도록 강요하지 않고 실행도 선택적이다. Gleam이 명목적(nominal) 타이핑으로 도메인을 엄밀히 기술하는 데 강하다면, EYG는 구조적(structural) 타이핑을 택해 사용자가 타입을 앞서 고민하지 않아도 컴퓨터가 도와주도록 했다. 의존성 지옥에 대해서는, 의존성을 사용하는 지점에 인라인으로 정의하되 모듈 내용의 해시로 식별하는 방식으로 우회한다. 버전 충돌 자체가 성립하지 않는 구조다.

부수 효과(side effect)를 타입 시스템에 담는 선택도 눈에 띈다. 웹페이지용 스크립트에서 파일 시스템을 호출하는 의존성이 있으면 친절한 타입 오류로 드러나고, 나아가 플랫폼이 람다 함수가 키-값 효과를 쓰는 경우에만 키-값 저장소를 프로비저닝하는 식으로 확장할 계획도 밝힌다. 다만 이는 아직 구현된 기능이 아니라 저자의 구상이라는 점은 감안해야 한다.

정리하면 EYG는 대규모 팀이 새 브라우저를 만드는 언어가 아니다. 저자 스스로 그런 목적이라면 Rust를 권한다고 못 박는다. EYG가 말하는 '더 나음'의 기준은 설정, 스크립트, 자동화, 위젯 같은 '집에서 요리한(home cooked)' 소프트웨어를 메이커가 얼마나 신뢰성 있고 공유 가능하게 만들 수 있는가에 있다. 언어 문법을 쉽게 만드는 데 몰두하는 대신 배포와 운영의 마찰을 걷어내는 데 집중했다는 점에서, 한국의 실무 자동화·사내 도구 제작자들에게도 시사점이 있다. 물론 아직 초기 단계 프로젝트인 만큼, 제시된 비전 중 상당 부분이 검증보다 앞선 설계 의도라는 사실은 함께 읽어야 한다.