코드를 읽는 즐거움

최근에 나는 Elixir 프로그래밍 언어의 창시자인 José Valim과 함께 Beyond the Commit 에피소드를 녹음하기 위해 자리에 앉았다. 우리는 결국 2시간이 넘도록 이야기했다 — 타입에 대해, AI에 대해, 프로그래밍 언어가 어디로 향하고 있는지에 대해.

그 대화는 나를 생각하게 만들었다. 나는 몇 년 동안 Elixir를 띄엄띄엄 익혀 왔다 — 개인 프로젝트를 위해서, POC를 위해서 — 그러다가 낮 시간의 일이 요구하는 그날그날의 진지한, 엔터프라이즈 언어로 다시 돌아가곤 했다. 그런데도 나는 계속 돌아왔다. 그리고 그 이유는 내가 예상했던 것보다 더 단순했다.

나는 내가 Elixir 코드를 읽는 일을 진심으로 즐긴다는 사실을 깨달았다.

나는 여러 언어로 작성된 코드를 읽으며 여러 해를 보냈고, 대부분의 언어에서 “읽기” 는 내가 기대하는 일이 아니라 견뎌내는 일에 가깝다. 그것은 목적을 위한 수단이다.

Elixir를 다르게 만드는 것은 그 단순함이다. 파이프 연산자, 패턴 매칭, 프로토콜 — 각각의 구성 요소는 유연하고 유용할 만큼 충분히 강력하면서도, 코드가 읽기 쉬운 상태로 남을 만큼 충분히 단순하다.

물론 다른 많은 언어들도 단순함을 달성했다. 예를 들면 Golang이 그렇다. 하지만 내가 아는 한, 단순함과 조화로운 미학의 균형을 이 정도 수준으로 달성한 언어는 없다. 적어도 나에게는 그렇다.

Elixir는 아주 좁은 설계의 복도를 놀라울 만큼 잘 걸어간다.

이를 내가 한때 잘 알았던 Scala와 비교해 보자. 잘 작성된 Scala 코드는 읽는 즐거움이다. 형편없이 작성된 Scala 코드는 지옥의 아홉 번째 원이다.

Elixir는 당신을 부드럽게 명료함 쪽으로 제약하고, 그 결과 대부분의 Elixir 코드는 대체로 비슷한 방식으로 읽힌다. 그리고 그것이 바로 코드 리뷰가 일인 사람에게 원하는 것이다.

이 철학은 언어 자체를 넘어 그 생태계까지 확장된다. 개인 프로젝트에서는 나는 몇 년째 Django를 사용해 왔다. 보통은 hot reload, Stimulus, Tailwind, 반복 작업, 그리고 이런저런 것들을 직접 연결해야 했다. 결국 그 모든 것은 내가 직접 만든 cookiecutter 템플릿 안으로 들어갔다. Phoenix에서는 그 모든 것이 하나의 일관된 패키지로 기본 제공된다 — 유연할 만큼 충분히 강력하고, 곧바로 익혀서 바로 만들기 시작할 수 있을 만큼 충분히 단순하다. 깔끔하고 우아한 패키지다.

내가 직관에 어긋난다고 느끼는 부분은 여기다. 우리는 지금 사람들이 손으로 직접 코드를 쓰는 일이 더 이상 중요하기는 한지 토론하는 순간을 살고 있다. AI가 코드를 작성하고, 당신은 그것을 검토하고 안내한다. 나는 바로 그 점 때문에 언어의 미학이 덜이 아니라 더 중요해진다고 생각한다. 코드와의 주된 상호작용이 그것을 읽는 일이라면, 그 경험이 얼마나 즐거운지는 최우선 관심사가 된다. 적어도 우리가 배포하는 코드를 여전히 이해해야 한다는 기대를 받는 동안에는 말이다…

지금의 통념은 정적 타입 언어가 AI 보조 개발에 더 적합하다는 것이다. 타입은 모델에 더 많은 맥락을 제공하고, 오류를 더 일찍 잡아내며, 해법 공간을 제약한다. 직관적으로는 말이 된다. 어쩌면 정말 그럴지도 모른다. 적어도 엔터프라이즈급 소프트웨어에 대해서는 확실히 설득력 있는 주장이다.

한편으로 우리는 이런 사례 같은 흥미로운 실험도 가지고 있다. 올바른 개인 프로젝트를 생성하는 비용을 시험하는 것이다. Yusuke Endoh는 13개 언어에 걸쳐 Claude Code를 테스트했는데 — Ruby가 가장 앞섰다. 가장 빠르고, 가장 저렴하며, 가장 신뢰할 수 있었다. Ruby에 타입 체커를 추가하자 속도가 2-3배 느려졌다. 간결하고 표현력이 풍부한 언어 — 사람이 읽기에도 즐거운 언어 — 는 AI가 가장 적은 토큰을 낭비하는 언어이기도 하다.

José 본인이 쓴 이 흥미로운 글도 있다. 타입의 건전성을 해치지 않고서는 어떤 사소한 표현들을 올바르게 타입 지정하는 것이 불가능하다는 문제와 관련된 긴장을 다루고 있지만, 그것은 완전히 다른 이야기다.

그사이 OpenAI는 자사의 에이전트 오케스트레이션 프레임워크인 Symphony를 Elixir로 만들었다. 최전선의 AI 연구소가 자사의 에이전트를 오케스트레이션하기 위해 전화 교환기를 위해 설계된 40년 된 가상 머신 위에 구축된 언어를 선택한 것이다.

그 사실에는 어딘가 시적인 면이 있다. AI가 점점 더 많은 글쓰기를 처리하는 세상에서, 적어도 당분간 남는 것은 취향, 명료함, 그리고 잘 설계된 무언가와 함께 일하는 즐거움이다.

그리고 Elixir는 그것을 아주 풍부하게 갖추고 있다.