Transcript
00:00:00Vercel에서 Xero라는 새로운 프로그래밍 언어를 출시했습니다. 이 언어가
00:00:03기존 언어들과 다른 점은, 인간과 AI 에이전트가 함께
00:00:07작은 네이티브 프로그램을 개발할 수 있도록 바닥부터 설계되었다는 것입니다. 하지만 이건 우리 모두가 이미 하고 있던 일 아닌가요?
00:00:12그렇다면 이 언어의 장점은 무엇이며, 실제로 좋은 아이디어일까요? 아니면 몇 달 지나면
00:00:16아무도 이야기하지 않을 또 하나의 사이드 프로젝트에 불과할까요? 한 번 알아보겠습니다.
00:00:25Xero는 Rust나 Zig 같은 시스템 언어입니다. 어쩌면 언젠가 Bun을 이 언어로 다시 작성할 수도 있겠네요.
00:00:30제가 파악한 바로는, 핵심 개념은 현재의 언어들이 인간을 위해 만들어졌다는 점입니다.
00:00:34그래서 인간은 에러 메시지, 경고, 트레이스를 읽지만, AI는 구조화된 데이터가 있을 때
00:00:38훨씬 더 잘 작동합니다. 따라서 Xero는 이 점을 염두에 두고 전체 툴체인을 구축했습니다.
00:00:43즉, 컴파일러가 생성하는 모든 출력을 JSON으로 내보낼 수 있다는 뜻입니다.
00:00:46이제 이런 점들만 봐도, 그리고 이 웹사이트에 있는 꽤 명백하게 AI가 쓴 문장들만 봐도
00:00:51이 언어가 왜 존재해야 하는지, 얼마나 잘 작동할지에 대해 저는 여전히 회의적입니다.
00:00:56하지만 제 의견은 마지막에 말씀드리겠습니다. 우선 언어 자체를 살펴보죠.
00:00:59꽤 흥미로운 언어니까요. 새로운 언어를 배울 때의 클래식한
00:01:03프로젝트인 아주 간단한 문자열 출력부터 시작하겠습니다. 대부분 이해하기 아주 쉽습니다.
00:01:08이 프로그램의 엔트리 포인트로 퍼블릭 메인(main) 함수가 있습니다. 이 함수는
00:01:12void를 반환하고, 내부에서 문자열을 출력합니다. 하지만 이 문자열이
00:01:16출력되는 방식에서 첫 몇 가지 특징을 확인할 수 있습니다. 바로 “world” 성능(capability)을 사용한다는 점입니다.
00:01:21파일 작업, 출력, 네트워크 호출 등 일체의 I/O 작업을 수행하거나
00:01:26어떤 I/O 사이드 이펙트가 발생할 때 이 성능이 필요하며, 이는 이 언어의 명시성 원칙의 일부입니다.
00:01:31함수에 이 world 성능이 있다면 I/O 작업을 수행한다는 즉각적인 신호이며,
00:01:37없다면 I/O 사이드 이펙트가 전혀 없음을 의미합니다.
00:01:40또한 world 성능을 통해 컴파일러는 런타임이 아닌 컴파일 타임에 타겟에 따라
00:01:45사용 불가능한 성능을 거부할 수 있습니다. 예를 들어 이 함수 내에서 파일 시스템에 접근하려고 시도하면서
00:01:50웹어셈블리 빌드를 타겟으로 잡으면, 컴파일러가 먼저 에러를 발생시킵니다.
00:01:54따라서 나중에 뜻밖의 런타임 에러를 겪지 않게 됩니다.
00:01:57world 성능 외에도 이 프로그램에는 몇 가지 키워드가 있습니다.
00:02:00여기 “check”가 있는데, 이것이 에러를 처리하는 방식입니다. 함수가 실패할 가능성이 있다면
00:02:05“raises”로 표시하고, 여기의 “check”를 사용하여 에러를 전파합니다. Rust의
00:02:09물음표(?) 연산자와 꽤 유사하지만, 키워드로 존재합니다. 이것이 Xero에서
00:02:13첫 프로그램을 작성하는 데 알아야 할 전부이며, `xero run hello.xero`를 실행하면 됩니다.
00:02:19참고로 이것이 Xero 언어의 파일 확장자입니다. 이제 엔터를 누르면
00:02:23“hello, subscribe to Betastack”이라고 나옵니다. 꼭 구독하셔야 할 채널이죠.
00:02:26헬로 프로그램을 넘어, 이제 우리는 모두 Xero 전문가가 되었으니
00:02:30기본적인 애플리케이션을 지원할 몇 가지 원시 타입(primitives)을 더 살펴보겠습니다.
00:02:34입력값이 텍스트인지, 숫자인지, 아니면 혼합형인지 분류하는 임의의 앱을 새로 만들었습니다.
00:02:39여기서 보시다시피 표준 라이브러리 같은 기능들을 사용하고 있습니다.
00:02:43열거형(enum)도 있고, 구조체(struct)와 매우 유사한 셰이프(shape)도 있습니다. 그리고
00:02:47if문이나 아래에 있는 while문처럼 예상 가능한 일반적인 언어 기능들이 있고,
00:02:52for 루프도 사용할 수 있으며, switch문과 거의 같은 match문도 아래에 있습니다.
00:02:56그다지 예상 밖이거나 새로운 것은 없습니다. 메모리와 같은 더 고급 개념의 경우에도 Xero에서는
00:03:00모든 것이 명시적이어야 합니다. 쓰기 가능한 뷰를 위한 가변 스팬(mutable span)과
00:03:05읽기 가능한 뷰를 위한 스팬이 있고, 아래에는 소유권 타입(owned type)이 있습니다. 이는 본질적으로
00:03:10이 값이 여기서 소유되며, 스코프를 벗어날 때 drop 함수를 실행한다는 의미입니다. 우리는
00:03:14여기 셰이프에 drop 함수를 직접 정의하므로, 여기에 정리(cleanup) 로직을 넣게 됩니다.
00:03:18이를 수행하는 또 다른 방법은 defer 키워드를 사용하고 뒤에 함수를 배치하는 것입니다.
00:03:22기본적으로 이 함수가 끝나고 스코프를 벗어날 때 이어서 해당 함수를 실행하라는 의미입니다. 따라서
00:03:26오늘날 매우 기본적인 애플리케이션에 필요한 모든 것을 갖추고 있으며, 몇 가지 기능이 더 있지만
00:03:31프로그래밍 튜토리얼이 되는 것은 원치 않으므로, 이력서에
00:03:35“Xero 경력 3분”이라고 편하게 적으셔도 좋습니다. 이제 이 모든 것을 뒤로하고
00:03:39Xero의 진정한 세일즈 포인트인 툴체인과 AI 에이전트를 위해 빌드되었다는 점에 집중해 보겠습니다.
00:03:44AI 에이전트가 Xero 코드를 작성하다가 버그를 유발했다고 가정해 봅시다. 그들의 주장에 따르면
00:03:49대부분의 언어에서는 텍스트 벽만 돌려받게 되며, 해당 에러 메시지들은 인간이 읽도록 설계되었습니다.
00:03:54Xero에서는 인간이 읽을 수 있는 메시지도 얻을 수 있고 대략 이런 모습이겠지만,
00:03:58보시다시피 구조화된 출력은 아닙니다. 그래서 그들은 툴체인의 모든 부분에
00:04:02실제로 JSON 옵션이 포함되도록 만들었습니다. 따라서 동일한 함수를 다시 실행하되
00:04:07이번에는 JSON 옵션을 사용하고 터미널에서 좀 더 보기 좋게 JQ로 파이핑하면,
00:04:12깔끔하게 구조화된 출력의 에러 메시지를 얻을 수 있습니다. 중요도(severity), 코드, 메시지 같은
00:04:16진단 정보(diagnostics)가 있고, 에러가 발생한 위치, 기대값 및 실제값이 표시됩니다.
00:04:21그리고 LLM 자체를 위한 도움말과 함께, 인간의 검토가 필요함을 나타내는 수정 안전성(fix safety) 필드,
00:04:26그리고 이를 수리하는 방법에 대한 정보가 제공됩니다. 즉, LLM이 스스로 문제를 고칠 수 있도록 충분한 컨텍스트를 제공하려는 것입니다.
00:04:31이를 잘 보여주는 또 다른 명령어가 `xero fix`입니다. 이 명령어에
00:04:35플랜(plan) 모드와 JSON을 함께 사용하고 터미널에서 보기 좋게 JQ로
00:04:40파이핑해 보겠습니다. 이를 실행하면 제가 제공한 오류가 있는 분류 파일에 대해
00:04:44진단을 수행하고, 본질적으로 이 파일을 수정하기 위해 무엇을 해야 하는지 알려줍니다.
00:04:49보시다시피 안전 수준, 모드, 적용 여부, 편집 등 거의 LLM만 알면 되는
00:04:53필드들로 구성된 구조화된 출력을 받게 됩니다. 하단에는 자체 호스팅 수리 정책(self-host repair policy) 같은 것들이 있습니다.
00:04:58이어지는 진단 섹션은 방금 전 `xero check` 명령어에서 보았던 것과 거의 동일하며,
00:05:03하단에는 해당 에러 코드 자체에 대한 수정 사항도 있습니다. 그렇다면 이것이 보통 어떻게 수정될까요?
00:05:07본질적으로, 필요할 때 언어가 자체 문서를 제공하면 어떨까라는 아이디어의 일부로 보입니다.
00:05:12따라서 LLM에게 이 새로운 언어를 맡기면, 문서를 찾아보거나 별도의 기술을 사용할 필요 없이
00:05:17실제로 필요할 때 툴체인으로부터 충분한 정보를 얻을 수 있게 됩니다.
00:05:21그래서 이를 테스트해보기 위해, Xero 언어에 대한 정보가 전혀 없는
00:05:25완전히 새로운 디렉토리에 오류가 있는 파일을 넣었습니다. 그리고 이제 Claude에게 이 파일을 수정해달라고 요청하면서,
00:05:30진단에 필요한 명령어도 함께 알려주었습니다. 툴체인을 사용하는 방법에 대한 정보는 필요하니까요.
00:05:34이렇게 하고 Claude가 실제로 이 파일을 고칠 수 있는지 확인해 보겠습니다.
00:05:38놀랍게도 31초 만에 파일의 모든 에러를 수정하는 데 성공했습니다. 제가 고의로 세 개를 넣어두었는데,
00:05:43세 개를 모두 찾아내어 고쳤습니다. 위로 스크롤해서 어떻게 했는지 볼 수 있습니다.
00:05:47그냥 제가 알려준 `xero fix` 명령어를 실행한 것뿐입니다. 이번에는 결과값으로 `ok: true`를 받았으므로
00:05:51남은 에러가 없음을 알 수 있고, 위로 스크롤하면 코드가 변경된 것을 볼 수 있는데,
00:05:56이전 단계에서 `xero fix`를 실행하여 해당 문제를 어떻게 고쳐야 하는지 정확한 정보를
00:06:00얻었기 때문입니다. 그리고 우리가 가졌던 세 가지 문제 모두에 대해 그렇게 처리했습니다.
00:06:05따라서 이 LLM은 Xero 언어에 대한 사전 정보가 전혀 없었고, 문서를 가져오기 위해 웹 검색을
00:06:10하거나 하지도 않았으며, 단지 툴체인이 구조화된 출력으로 제공한 정보만을 사용했습니다.
00:06:14사실 이 부분은 약간 감명 깊었습니다. 언어가 구축된 방식 덕분에
00:06:18완전히 새로운 언어임에도 LLM이 디버깅할 수 있었으니까요. 하지만 한 가지 의문이 남습니다.
00:06:22이게 정말 새로운 것일까요? 툴체인의 에러와 모든 요소가 구조화된
00:06:28출력을 가진다는 셀링 포인트는 이해하지만, 그건 딱히 새로운 개념이 아닙니다.
00:06:31우리는 수십 년 동안 구조화된 에러 메시지를 사용해 왔습니다. 이것 보세요, 제가 Rust로
00:06:37거의 동일한 분류 프로그램을 빌드했고 비슷한 에러가 있는데, 출력을 JSON으로 요청할 수 있습니다.
00:06:41이 아이디어를 중심으로 아예 새로운 언어를 만들 필요가 있었는지는 잘 모르겠습니다. 정보의 공백이 있다고 생각했다면
00:06:46기존 언어들을 개선할 수도 있었을 테니까요. 또한 오류가 있는 Rust 코드를 가져와서
00:06:51Claude에게 고쳐달라고 요청하면, 구조화된 출력을 사용하지 않더라도
00:06:55쉽게 고칠 수 있을 것이라 확신합니다. 제 생각에 LLM은 일반 메시지로도 충분히 잘 해내며,
00:07:00아니면 제가 아직 그런 문제를 겪지 못한 것일 수도 있습니다. 게다가 LLM은 Rust처럼
00:07:05기존의 수많은 코딩 언어로 학습되었기 때문에 디버깅을 아주 잘할 것이고
00:07:10학습 데이터에 수많은 예시가 있지만, Xero의 경우에는 예시가 전무합니다.
00:07:14그렇다고 새로운 언어를 추가하려는 시도를 전혀 하지 말아야 한다는 뜻은 아닙니다. 다만 복잡한 앱을 만든다면
00:07:19Xero를 선택하지는 않을 것이라는 의미인데, 솔직히 그들도 그런 용도로 마케팅하고 있지는 않습니다.
00:07:24전반적으로 이 언어는 재미있는 실험이라고 생각하며, 설령 그렇다 하더라도 LLM을 해당 언어로
00:07:28학습시키지 않고도 필요한 컨텍스트를 제공하여 새로운 언어를 빌드할 수 있음을 보여줍니다. 하지만
00:07:32이것이 꼭 필요했는지에 대해서는 여전히 잘 모르겠습니다. 그렇다고 언어 자체가 멋지지 않다는 뜻은 아닙니다.
00:07:37말씀드렸듯이 실제로 사용하기에 나쁘지 않고, 컴파일된 크기도 아주 훌륭합니다.
00:07:42다만 제가 Rust, Zig, Go처럼 자리를 잡은 언어들 대신 이 언어를 쓸 일은 없을 것 같습니다.
00:07:47이 주제에 대해 많은 의견이 있을 것으로 예상되니, 아래 댓글로 여러분의 생각을 알려주시거나
00:07:51구독을 눌러주세요. 그리고 언제나 그렇듯,
00:07:55다음 영상에서 만나요.