---
title: "Mercury는 신입 엔지니어에게 Haskell을 2주 만에 가르친다 — 그 방법론 전체 공개"
published: 2026-03-15T22:28:07.000Z
canonical: https://jeff.news/article/612
---
# Mercury는 신입 엔지니어에게 Haskell을 2주 만에 가르친다 — 그 방법론 전체 공개

핀테크 Mercury가 50명 이상의 신규 엔지니어를 2주 만에 Haskell 실무 투입 수준으로 교육한 프로그램 LHbE를 공개. 교재·강의 없이 순수 연습문제 + 매일 1:1 멘토링으로 모나드 트랜스포머 스택까지 도달.

## Mercury의 "2주 만에 Haskell 배우기" 프로그램

- 핀테크 기업 Mercury가 신규 엔지니어를 위한 Haskell 교육 프로그램 "Learn Haskell by Exercises(LHbE)"를 공개함. 인턴부터 매니저, 시니어 엔지니어까지 **동일한 커리큘럼으로 2주(10 영업일)** 만에 Haskell을 가르침. 지난 6개월간 50명 이상이 수료

- 사전 Haskell 지식 불요. 첫날 Double이 뭔지도 몰랐던 사람이 수료한 적도 있음. 이미 Haskell을 아는 사람은 10분짜리 배치 테스트로 확인 후 단축 과정 진행

## 커리큘럼 구성

- 10세트 × 10일 구조. 진도 체크는 쉽지만 빨리 끝내도 됨 (한 인턴은 8일 만에 완료)
  - **Set 1-2**: Hoogle, GHCi, 타입 시그니처, typed holes, `map`, do notation, `Maybe`
  - **Set 3-4**: ADT, 패턴 매칭, IO, 타입클래스, `instance`/`deriving`, 유닛/통합 테스트
  - **Set 5-6**: 레코드 문법, 언어 확장, `Either`, `Semigroup`/`Monoid`, 타입 앱
  - **Set 7-8**: `Foldable`, 비엄격 평가, 무한 자료구조, `Functor`, `Applicative`
  - **Set 9-10**: `Monad`, do notation 디슈가링, `Reader`/`Writer`/`State`, **모나드 트랜스포머 스택**까지 도달

- 10일 만에 모나드 트랜스포머 스택까지 간다는 게 좀 미친 속도인데, 가능한 이유가 있음

## 교육 철학: "읽지 말고 풀어라"

- **교재, 강의, 읽기 자료 일절 없음.** 순전히 연습문제만으로 학습. 예전에 책을 병행했다가 오히려 성과가 나빠져서 제거함. 90초짜리 유튜브 영상 몇 개와 200자 미만 소개글만 제공

- 각 모듈의 첫 번째 문제는 "worked example"으로 정답을 직접 보여줌. 이후 문제들은 퍼즐 게임의 레벨처럼 점진적으로 변형을 추가. 한 토픽당 20~30개 구체적 예제를 풀면서 멘탈 모델을 다듬는 방식

> [!IMPORTANT]
> Mercury의 핵심 원칙: "학습을 훔치지 마라(Don't steal learning)". 헬스장에서 남의 무게를 대신 들어주거나 친구 게임 컨트롤러를 뺏어서 보스를 대신 잡아주는 것처럼, 멘토가 답을 알려주면 지표상 진도만 나가고 실제 학습은 제로

## 피드백 레이어가 빡빡함

- 실시간 피드백 계층구조:
  - **즉시**: `ghciwatch` 파일 감시 타입체커 — 코드 수정 즉시 컴파일러 출력 확인 (alt-tab도 느린 거라고 봄)
  - **15초 이내**: 타입 에러 메시지 + typed holes + 타입 어노테이션
  - **1분 이내**: **Hoogle** — Day 1에 제일 먼저 가르치는 게 Hoogle임. 2-3일차에 Hoogle 잘 쓰는 사람이 9-10일차에 성과가 좋다는 데이터가 있음
  - **5분 이내**: LLM 또는 Google/Stack Overflow
  - **15분 이내**: Haskell 멘토에게 메시지

- 검증 계층: 타입체커 → 테스트 → LLM 코드 리뷰(선택) → PR 리뷰 → **매일 1:1 30분 멘토 콜**

- LLM 활용에 대한 관찰이 흥미로운데, 가장 빠른 학습자와 가장 느린 학습자 둘 다 LLM을 많이 씀. 빠른 사람은 자기 작업을 검증하거나 더 깊이 파고드는 데 쓰고, 느린 사람은 답을 얻는 목발로 사용함

## 메타인지 피드백

- 멘토가 물어보는 질문들이 Haskell이 아니라 **사고 과정**에 대한 것들임: "x의 타입이 뭐야?", "그걸 어떻게 증명해?", "어디서 찾아볼 수 있어?", "더 확신할 수 있는 방법은?"

- 최고 성과자들의 공통점: 코드에 혼란스러운 부분을 인라인 주석으로 표시해서 멘토에게 공유. "모르겠다"고 먼저 말하는 투명한 불확실성(transparent uncertainty)이 학습 성공의 핵심 지표

- "이 코드 더 좋아질 수 있을까?" 질문을 반복하는 연습이 있는데, 멘토가 먼저 "됐다"고 끝내지 않음. 가끔 학습자가 멘토도 못 본 개선점을 찾기도 하고, 진짜 중요한 건 **스스로 "아니오"라고 할 근거가 생길 때까지 계속 묻는 습관**을 기르는 것

- Mercury 트레이닝팀의 요약: "출발점은 거의 상관없고, **진행 중인 행동 패턴이 최종 실력을 결정**한다"

## 핵심 포인트

- 10세트 × 10일, 모나드 트랜스포머 스택까지 커버
- 교재·강의 제로, 연습문제만으로 학습하는 'Practice over Prose' 철학
- Day 1에 Hoogle을 먼저 가르치고, 초기 Hoogle 활용도가 최종 성과를 예측
- 멘토의 핵심 원칙: '학습을 훔치지 마라' — 답을 알려주면 안 됨
- LLM은 양날의 검: 빠른 학습자는 검증에, 느린 학습자는 목발로 사용

## 인사이트

Haskell이라는 극단적 사례지만, 교육 방법론 자체가 보편적으로 적용 가능함. '읽지 말고 풀어라' + '즉각적이고 정확한 피드백'이라는 원칙은 어떤 기술 온보딩에도 통함.