Mercury가 200만 줄의 Haskell로 은행 시스템을 운영하는 법

Haskell이 진짜 프로덕션에서 돌아간다고?

Haskell 하면 보통 "학교에서 배우는 함수형 언어", "수학 잘하는 사람들이 쓰는 언어" 같은 이미지가 떠오르잖아요. 그런데 미국의 핀테크 스타트업 Mercury가 자사 블로그에서 공개한 내용을 보면 생각이 좀 달라질 거예요. 이 회사는 무려 200만 줄이 넘는 Haskell 코드로 실제 은행 서비스를 굴리고 있거든요. 고객 계좌, 송금, 카드 결제 같은 돈이 직접 오가는 시스템을 전부 Haskell로 짜놨다는 얘기예요.

이게 왜 신기하냐면, 보통 핀테크 회사들은 Java, Go, Python, TypeScript 같은 "안전한 선택지"를 쓰거든요. 사람을 구하기 쉽고 라이브러리도 풍부하니까요. 그런데 Mercury는 처음부터 Haskell을 골랐고, 회사가 커지면서도 그 결정을 후회하지 않는다고 말하고 있어요.

Haskell을 고른 이유: 타입이 곧 명세다

Mercury 엔지니어들이 강조하는 건 타입 시스템이에요. 이게 뭐냐면, 코드를 컴파일하는 단계에서 "이 함수는 절대 null을 받으면 안 돼", "이 돈 계산은 반드시 통화 단위가 같아야 해" 같은 규칙을 언어 차원에서 강제할 수 있다는 거예요. 런타임에 가서야 "앗 버그다!" 하고 발견하는 게 아니라, 빌드가 아예 실패해버리니까요.

예를 들어 송금 기능을 만든다고 해볼게요. 보통 언어라면 transfer(fromAccount, toAccount, amount) 이렇게 짜고, 실수로 인자 순서를 바꿔도 컴파일은 통과해요. 근데 Haskell에서는 Account와 Amount를 별도 타입으로 만들어두면, 순서가 틀리면 빌드부터 안 되거든요. 돈이 잘못 빠져나가는 사고를 코드 단계에서 막는 거죠.

글에서는 또 리팩토링이 무섭지 않다는 점도 강조해요. 200만 줄짜리 코드베이스를 건드린다고 생각해 보세요. 보통 회사라면 "이거 손대면 어디서 터질지 몰라" 하면서 다들 피하잖아요. 그런데 Haskell은 함수 시그니처 하나만 바꿔도 그걸 쓰는 모든 곳에서 컴파일 에러가 나기 때문에, 변경의 파급 범위를 컴파일러가 알려준다는 거예요.

그렇다면 단점은 없을까

Mercury도 솔직하게 어려움을 털어놓아요. 가장 큰 건 채용이에요. Haskell 잘 쓰는 사람을 시장에서 찾기가 정말 어렵거든요. 그래서 Mercury는 "Haskell 경험 없어도 좋다, 우리가 가르친다"는 전략을 쓴다고 해요. 보통 Java나 Python 백그라운드 가진 사람을 뽑아서 3~6개월 정도 적응 기간을 주는 식이에요.

빌드 시간도 고민거리예요. Haskell 컴파일러(GHC)는 워낙 똑똑한 일을 많이 하다 보니 빌드가 느려지기 쉬운데, Mercury는 빌드 인프라에 꽤 많은 투자를 했다고 해요. 캐싱 잘 해두고, CI 파이프라인을 잘게 쪼개고, 모듈 의존성을 적극적으로 관리하는 식이죠. 라이브러리 생태계도 Node.js나 Python에 비하면 좁아서, 필요한 도구를 직접 만들어 쓰는 일이 종종 있다고 합니다.

비슷한 사례들과 업계 맥락

사실 함수형 언어를 프로덕션에 쓰는 회사가 Mercury만 있는 건 아니에요. Jane Street는 OCaml로 금융 트레이딩 시스템을 굴리는 걸로 유명하고, WhatsApp은 Erlang으로 수억 명의 메시지를 처리해왔어요. Standard Chartered도 Haskell로 파생상품 시스템을 운영하고 있죠. 공통점은 "실수가 곧 큰 손해로 이어지는 도메인"이라는 거예요. 금융, 통신처럼 한 번의 버그가 수백만 달러 손실이나 서비스 장애로 직결되는 분야에서는, 컴파일 단계에서 잡을 수 있는 버그는 무조건 잡고 가는 게 이득이거든요.

반대로 최근 Rust가 시스템 프로그래밍 영역에서 비슷한 자리를 차지하고 있어요. Rust도 강력한 타입 시스템과 메모리 안전성을 컴파일 타임에 보장하니까, "안전을 컴파일러에게 맡기자"는 흐름의 또 다른 갈래로 볼 수 있죠.

한국 개발자에게 주는 시사점

한국의 핀테크나 금융권에서 Haskell을 당장 도입하기는 쉽지 않을 거예요. 채용 풀이 더 좁고, SI 환경에서 검증된 스택을 선호하는 분위기도 있으니까요. 하지만 타입을 도메인 모델링의 도구로 쓰는 사고방식은 충분히 가져올 수 있어요. TypeScript의 브랜드 타입(branded type), Kotlin의 value class, Scala의 case class 같은 도구로도 비슷한 효과를 낼 수 있거든요.

예컨대 "숫자 1000"이 원화인지 달러인지 구분 안 되는 코드 대신 KRW(1000), USD(1000)처럼 타입을 입혀두면, 실수로 두 통화를 더하는 코드는 컴파일조차 안 되게 만들 수 있어요. Mercury의 사례는 이런 사고방식을 200만 줄 규모까지 확장했을 때 어떤 일이 벌어지는지 보여주는 귀중한 데이터 포인트인 셈이에요.

마무리

결국 핵심은 "언어 선택은 곧 어떤 종류의 버그를 미리 차단할지에 대한 선택"이라는 점이에요. 여러분이 지금 쓰고 있는 언어는 어떤 실수를 컴파일러가 잡아주고 있나요? 그리고 Haskell 같은 "진입 장벽 높지만 보상도 큰" 언어를 회사 차원에서 도입한다면, 채용과 학습 비용을 감당할 만한 도메인이 어디라고 생각하세요?