들어가며 — 좋아하는 언어를 떠난다는 것
"언어를 갈아탔다"는 글은 대개 그 언어를 성토하는 자리가 됩니다. 그런데 2026년 7월, Scarf의 창업자 Avi Press가 쓴 글은 정반대 톤이었습니다. 제목부터가 하스켈을 "아쉬워하며(reluctantly)" 떠났다입니다. 그는 16년째 하스켈 팬이고, Scarf는 7년간 프로덕션에서 하스켈을 돌렸습니다. 본인 말로도 이런 글은 잘 안 쓴다고 합니다 — 무언가를 만들고 알리는 걸 좋아하지, 비판을 즐기는 사람은 아니라면서요.
이 글이 던지는 질문은 좋은 질문입니다. 아직 좋아하는 언어를, 팀은 대체 무엇 때문에 버리게 되는가? 배신당한 언어도, 억지로 떠안은 언어도 아닌, 스스로 골랐고 공개 석상에서 변호할 수도 있는 언어를 말입니다. 이런 질문의 답은 흔한 언어 전쟁의 땔감보다 대체로 더 정직합니다. 글쓴이에게 갈아 낼 도끼가 없기 때문입니다.
그래서 이 글이 흥미롭습니다. 하스켈이 무너져서 떠난 게 아니기 때문입니다. 오히려 하스켈은 자기 약속을 대부분 지켰습니다. 그리고 사람들이 "하스켈을 왜 떠나?"라고 물을 때 흔히 튀어나오는 이유 — 채용이 어렵다, 사람 구하기 힘들다 — 는 이 글 어디에도 등장하지 않습니다. Avi가 든 이유는 훨씬 구체적이고, 훨씬 2026년적이며, 곱씹어 볼 만합니다.
무너지지 않은 약속 — 하스켈이 지킨 것들
먼저 균형을 잡고 시작하죠. Avi는 하스켈을 진지한 프로덕션 시험대에 올렸고 그 약속의 많은 부분이 실제로 지켜졌다고 분명히 적습니다. 코드는 안정적이었고, 타입 시스템은 진짜 버그를 잡았으며, 언어가 도메인을 신중하게 모델링하도록 강제했습니다. 계약상 SLA가 걸린 서비스를 수년간 문제없이 운영했고, 고성능 코드도 대체로 어렵지 않게 뽑아냈다고 합니다.
스택도 구체적입니다. API는 Servant와 Beam을 PostgreSQL 위에 얹어 만들었고, 트래픽이 많은 Scarf Gateway는 WAI 위에 직접 성능 중심 서비스로 구현했습니다. 이런 것들이 실제 오픈소스 패키지 트래픽을 견뎌냈습니다.
가장 정직한 대목은 이겁니다. 파이썬으로 옮기며 포기한 타입 안전성이 지금까지 구체적으로 아쉬웠던 적은 없다고 인정합니다. 타입의 열렬한 팬이 스스로 이렇게 말하는 건 무게가 다릅니다. 물론 이건 양날입니다 — 타입이 조용히 막아 주던 사고는 원래 눈에 안 띄는 법이니까요. 하지만 적어도 그는 잃은 것을 과장하지 않습니다.
여기엔 개인적인 결도 있습니다. Avi는 하스켈을 배우며 훨씬 나은 프로그래머가 됐다고 말하고, 그 부채감이 글에서 느껴집니다. 아쉬움의 출처가 바로 거기입니다 — 이건 원한을 갚는 글이 아니라 오래된 관계를 다시 협상하는 글입니다. 이 포스트를 언어를 때리는 탄약으로 인용하기 전에, 그 점을 기억해 둘 만합니다.
진짜 이유 — 컴파일 시간과 에이전트 경제학
그럼 무엇이 문제였나. Avi가 꼽은 가장 큰 두 가지는 컴파일 시간과 에코시스템 마찰입니다. 특히 컴파일 시간이 핵심인데, 여기서 이야기가 분명하게 2026년적으로 흘러갑니다.
빠를 때는 반복 루프가 20초 남짓이고, 그럴 땐 기분이 좋다고 합니다. 문제는 콜드 스타트입니다. 여러 AI 코딩 에이전트에게 각자 다른 브랜치를 병렬로 맡기는 개발 방식을 상상해 보세요 — 다섯 에이전트가 다섯 브랜치를 동시에 탐색하는 식입니다. 각 브랜치는 깨끗한, 버려도 되는 빌드 환경이 필요합니다. 그런데 에이전트가 몇 분 만에 그럴듯한 변경을 만들어 놓고 콜드 빌드가 끝나기를 15분씩 기다린다면, 컴파일러는 이제 사소한 불편이 아니라 그 작업 흐름에서 가장 큰 비용이 됩니다.
캐싱으로 대응하면 되지 않냐고요? Avi의 답은 냉정합니다. 캐시는 결코 완벽해지지 않고, 캐시를 충분히 좋게 만드는 데 드는 엔지니어링 노력 자체가 문제의 일부라는 것입니다. 실제로 그들은 빌드·캐시·Nix·개발 환경·CI를 다듬는 데 많은 시간을 썼습니다.
핵심 통찰은 경제학의 재구성입니다. 에이전트는 코드를 생성하는 데는 싸고, 막혔을 때 비쌉니다. 하스켈은 컴파일 시점에 오류를 잡는 데 최적화된 언어입니다 — 사람이 병목이던 시절엔 그게 큰 미덕이었죠. 하지만 LLM이 순식간에 작동하는 코드를 뽑아내는 시대에는 그 미덕의 상대적 가치가 줄어듭니다. 언어가 나빠진 게 아니라, 무엇이 비싼지가 바뀐 겁니다.
달리 말하면 이렇습니다. 수십 년간의 통념은 오류 검출을 최대한 앞으로 당기라는 것이었습니다 — 시프트 레프트, 새벽 3시가 아니라 컴파일 시점에 실패하라. 그 논리는 코드를 쓰는 사람이 희소 자원이라는 가정 위에 섭니다. 희소 자원을 몇 초 만에 후보를 뽑아내는 지치지 않는 생성기로 바꾸면, 병목은 피드백 루프의 지연 시간으로 옮겨 갑니다. 빠르지만 덜 똑똑한 루프가 느리지만 똑똑한 루프를 이길 수 있게 된 것이죠. 불편한 생각이지만, Avi는 이를 외면하지 않습니다.
Avi는 커뮤니티 방향에 대한 아쉬움도 짧게 내비칩니다. 빌드 시간·온보딩·문서·예제·툴링보다 타입 시스템 연구가 우선시된다는 감각, 그리고 AI에 대해서는 활용(enablement)보다 제약(restriction)에 대화가 쏠려 있다는 점입니다.
에코시스템 마찰이 여기서 무엇을 뜻하는지는 짚고 넘어갈 만합니다. Avi는 라이브러리가 미성숙하다거나 뭔가 동작하지 않는다고 불평하는 게 아닙니다 — 위의 스택은 수년간 잘 굴러갔습니다. 마찰은 코드를 둘러싼 기계 장치에 있습니다. 빠른 에이전트 워크플로가 끊임없이 기대는 빌드·캐시·환경·CI, 그리고 관심의 방향이 다른 곳을 향한 커뮤니티 말입니다. 흔한 불평과는 다른, 그래서 더 흥미로운 불평입니다.
떠나는 방식, 그리고 남는 교훈
옮기는 방법은 교과서적입니다. 새 API 작업은 전부 파이썬으로 시작하고, 파이썬 API 서버를 기존 하스켈 서버 옆에 나란히 띄운 뒤, 요청을 알맞은 쪽으로 라우팅하고, 손대는 기능부터 하나씩 파이썬으로 넘깁니다. 스트랭글러 무화과(strangler fig) 패턴 그대로입니다. 기존 코드를 새 언어로 포팅하는 일은 기계적인 작업을 LLM에 맡기니 꽤 수월했다고 합니다. 그리고 지금도 하스켈은 프로덕션에서 돌고 있고, 그들은 여전히 하스켈을 존중합니다.
조용한 아이러니 하나를 짚어 둘 만합니다. 머무는 비용을 끌어올린 바로 그 능력 — LLM이 컴파일러를 병목으로 만들 만큼 빠르게 코드를 생성하는 능력 — 이 떠나는 비용을 싸게 만들었습니다. 역사적으로 잔혹한 작업이던 다른 언어로의 포팅이, 모델이 한 줄씩 옮겨 주니 이제 대부분 기계적인 일이 됐습니다. 만드는 경제학을 바꾼 도구가 옮기는 경제학까지 바꾼 셈입니다.
성과도 정직하게 적습니다. 테스트 커버리지는 그 어느 때보다 좋아졌고, 핫픽스는 이제 슬랙 메시지 하나면 나간다고 합니다. 하지만 Avi는 승리를 부풀리지 않습니다 — PR 처리량이 뚜렷이 늘었다고 말하기는 어렵고, 커밋 수는 노이즈가 많으며, 코드 줄 수는 나쁜 지표라고 스스로 못 박습니다.
여기서 얻을 교훈은 "하스켈은 별로다"가 아닙니다. 언어의 적합성은 절대값이 아니라 우리가 어떻게 만드는가에 대한 상대값이라는 것입니다. 7년 전 하스켈 선택이 틀렸던 게 아니라, 판이 그 아래에서 바뀐 겁니다. 그리고 이 결정 전체는 하나의 전제 위에 서 있습니다 — 에이전트 중심 개발이 앞으로 이 팀이 소프트웨어를 만드는 방식이라는 전제. 그 전제가 맞다면 Avi 말대로 이 이동은 명확하고 논리적인 다음 수순입니다. 전제가 흔들리면 계산도 달라지겠죠.
위험도 분명히 이름 붙여 둡시다. 검증된 강점을 베팅과 맞바꾸는 것은 여전히 베팅입니다. 에이전트 중심 개발이 정체되거나, 타입이 잡아 주던 보이지 않는 버그가 규모가 커지며 드러나기 시작하면, 1년 뒤 장부는 달라 보일 수 있습니다. 측정되지 않는 이득에 대한 Avi의 정직함은 양날입니다 — 비용 역시 닥치기 전까지는 똑같이 눈에 안 보일 수 있으니까요.
그래서 이건 n=1의 이야기이고, 한 회사의 경제학입니다. "다들 파이썬으로 다시 쓰라"는 처방이 아니라, 당신의 병목이 어디로 옮겨갔는지 정직하게 다시 재보라는 초대에 가깝습니다.
마치며
이 글에서 가장 배울 만한 건 결론이 아니라 태도입니다. Avi는 하스켈이 잘한 것을 또렷이 인정하고, 얻은 것을 과장하지 않으며, 자신의 결정이 특정 전제 위에 서 있다는 것도 숨기지 않습니다. 언어를 떠나는 글이 이렇게 균형을 유지하기는 쉽지 않습니다. 스택이 무엇이든, 그 정직함 — 무엇이 지켜졌고, 무엇이 바뀌었고, 무엇이 아직 불확실한지를 구분하는 규율 — 이야말로 베낄 가치가 있습니다.
더 넓은 신호를 읽자면 이겁니다. AI가 코드 쓰는 방식을 바꾸면서, 우리가 언어를 줄 세우는 축이 조용히 회전하고 있습니다 — 언어가 얼마나 많이 막아 주는가에서, 얼마나 빨리 다시 시도하게 해 주는가 쪽으로. 그게 진보인지 함정인지는 아직 분명치 않습니다. 다만 이 회전을 일찍 알아차리고 자기 숫자에 정직한 팀이, 옛 병목을 최적화하고 있는 팀보다 더 나은 결정을 내릴 겁니다.
참고 자료
현재 단락 (1/26)
"언어를 갈아탔다"는 글은 대개 그 언어를 성토하는 자리가 됩니다. 그런데 2026년 7월, Scarf의 창업자 Avi Press가 쓴 글은 정반대 톤이었습니다. 제목부터가 하스켈...