Scarf가 Haskell에서 Python으로 마이그레이션하여 AI 기반 개발을 최적화합니다

Scarf가 Haskell에서 Python으로 마이그레이션하여 AI 기반 개발을 최적화합니다

AI 에이전트가 소프트웨어 개발 경제를 바꾸었습니다

Scarf는 대형 언어 모델(LLM)과 AI 코딩 에이전트의 부상으로 인해 느린 컴파일 시간이 개발 주기의 주요 비용이 되면서 새로운 API 개발을 Haskell에서 Python으로 전환했습니다. Haskell은 7년 동안 프로덕션에서 신뢰성과 강력한 타입 안전성을 제공했지만, 이제 AI가 생성하는 코드의 속도가 Haskell 컴파일러의 속도를 앞서면서 병목 현상이 발생해 에이전트 주도의 병렬 실험을 방해하고 있습니다.

병목 현상: 콜드 스타트와 병렬 워크플로우

전통적인 인간 주도 워크플로우에서는 긴 컴파일 사이클이 불편하지만, 인간이 코드를 작성하는 데 많은 시간을 투자하기 때문에 어느 정도 감수할 수 있습니다. 그러나 AI 에이전트는 몇 분 안에 그럴듯한 변경을 초안할 수 있습니다. 개발 루프에 15분짜리 콜드 빌드가 포함되면 컴파일러가 생산성의 주요 제약이 됩니다.

이 문제는 병렬 워크플로우에서 더욱 확대됩니다. Scarf가 원하는 워크플로우는:

  • 여러 워크트리를 동시에 스핀업하기.
  • 다양한 에이전트가 탐색할 수 있도록 서로 다른 작업 라인을 포크하기.
  • 결과를 빠르게 검토하고 폐기하기.

Haskell 환경은 종종 복잡한 캐시 설정(Nix 또는 원격 빌더 사용)과 높은 메모리 사용량을 요구하기 때문에 새로운 작업 스레드를 시작하는 "세금"이 배가됩니다. 증분 빌드는 빠를 수 있지만, 콜드 스타트와 대규모 변경 경우—에이전트 중심 워크플로우에서 흔히 발생하는 상황—는 여전히 허용할 수 없을 정도로 느립니다.

전환 전략: 점진적 마이그레이션

Scarf는 위험한 "빅뱅" 전환을 피하기 위해 기존 Haskell API와 병행하여 Python API 서버를 배포했습니다. 마이그레이션은 다음 규칙을 따릅니다:

  • 새 기능: 모든 새로운 API 라우트는 Python으로 작성합니다.
  • 기존 기능: 특정 기능이 수정되고 포팅될 때까지 Haskell 코드는 계속 실행됩니다.
  • 포팅 과정: 기존 Haskell 로직을 Python으로 포팅하는 데 LLM을 사용했으며, 이는 과거 수동 포팅보다 훨씬 빠르고 간단했습니다.

회사는 이전에 툴체인과 씨름하던 시간이 기능 출시와 테스트 커버리지 확대에 재배치되었다고 보고했습니다. 그 결과 버그 수정이 지원 전화가 끝나기 전에 라이브가 되는 경우도 있는, 더 빠른 "고객 호출 → 배포" 파이프라인을 얻게 되었습니다.

Haskell 생태계에 대한 "AI 시대" 도전 과제

Scarf는 Haskell이 AI를 일류 사용자로 최적화하지 않으면 위험에 처한다고 주장합니다. 저자는 커뮤니티가 타입 시스템 연구(예: 종속 타입)에 집중하는 대신 산업적 요구를 우선시해야 한다고 제안합니다:

  • 콜드 빌드 시간 및 프로젝트 부트스트랩 마찰 감소.
  • 문서 개선—추상 타입만이 아니라 복사·붙여넣기 가능한 현실적인 예시 제공.
  • 에러 메시지 향상—에이전트 친화적으로 만들어 LLM이 코드를 더 빠르게 수정할 수 있게 함.
  • 고품질 학습 데이터 증가—모델이 Haskell 패턴을 더 잘 이해하도록 지원.

커뮤니티 관점 및 반론

Python으로 전환한 결정은 개발자들 사이에 큰 논쟁을 일으켰으며, AI가 언어 선택에 미치는 영향에 대한 의견이 갈렸습니다:

AI 시대에 강한 타입의 필요성

일부 개발자는 강력한 타입 시스템이 더 중요하다고 주장합니다. 이는 LLM이 종종 만들어내는 "쓰레기"를 방지하는 가드레일 역할을 하기 때문입니다.

"LLM이 만들어내는 모든 쓰레기를 잡아줄 좋은 타입 시스템이 없는 언어는 상상할 수 없습니다." — @noelwelsh

다른 사람들은 Scarf가 Python처럼 동적 타입 언어로 옮기기보다 OCaml이나 Go처럼 타입 안전성과 빠른 컴파일을 동시에 제공하는 언어로 옮겼어야 한다고 제안했습니다.

생산성과 반복성 강조

반대로, 일부 엔지니어는 정적 타입이 반복 속도가 충분히 빠르면 그리 중요하지 않다고 봅니다. 한 개발자는 Elixir로 전환하면서 타입 불일치와 관련된 버그가 운영 버그(큐 길이, API 오류 등)보다 드물어져 생산성이 향상되었다고 언급했습니다.

운영상의 우려

Python으로 전환한다는 비판은 컴파일은 빨라지지만, Python이 가져오는 의존성 관리와 다양한 운영 체제 간 버전 관리 문제라는 새로운 마찰을 야기한다는 점을 지적했습니다.

"Vibe Coding" 비판

일부 관찰자는 이번 전환을 "Vibe Coding"으로 규정했습니다. 이는 컴파일러의 엄격함이 에이전트 기반 반복 속도와 방대한 테스트 스위트에 의존하는 방식으로 대체되는 현상을 의미합니다.

요약: Scarf는 새로운 API 개발을 Haskell에서 Python으로 옮겼으며, 이는 AI 에이전트가 많이 활용되는 개발 워크플로우에서 Haskell의 느린 컴파일 시간이 중요한 병목이 되었기 때문입니다.

제목: Scarf가 Haskell에서 Python으로 마이그레이션하여 AI 기반 개발을 최적화합니다

Sources