본문으로 건너뛰기
피드

Mercury는 신입 엔지니어에게 Haskell을 2주 만에 가르친다 — 그 방법론 전체 공개

backend 약 6분
vote
0
댓글
북마크

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

  • 1

    10세트 × 10일, 모나드 트랜스포머 스택까지 커버

  • 2

    교재·강의 제로, 연습문제만으로 학습하는 'Practice over Prose' 철학

  • 3

    Day 1에 Hoogle을 먼저 가르치고, 초기 Hoogle 활용도가 최종 성과를 예측

  • 4

    멘토의 핵심 원칙: '학습을 훔치지 마라' — 답을 알려주면 안 됨

  • 5

    LLM은 양날의 검: 빠른 학습자는 검증에, 느린 학습자는 목발로 사용

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개 구체적 예제를 풀면서 멘탈 모델을 다듬는 방식

중요

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

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

댓글

댓글

댓글을 불러오는 중...

backend

잘못된 추상화보다 중복이 낫다는 샌디 메츠의 고전 조언

샌디 메츠는 중복을 없애려다 잘못된 추상화를 만들면 코드가 조건문과 파라미터로 부풀어 더 위험해진다고 말한다. 이미 틀어진 추상화는 억지로 보존하지 말고, 다시 호출부에 인라인해서 중복을 되살린 뒤 현재 요구사항에 맞는 새 구조를 찾는 편이 빠르다는 주장이다.

backend

리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

리눅스 커널이 오랫동안 버그의 원인이던 strncpy API 사용을 Linux 7.2에서 제거했어. NUL 종료 동작이 직관적이지 않고 불필요한 zero-fill로 성능 문제도 있던 API를 6년 동안 약 362개 커밋으로 걷어낸 작업임.

backend

덕디비는 왜 빠를까: 서버 없는 분석 엔진의 내부 구조 뜯어보기

DuckDB가 단일 바이너리, 인프로세스 실행, 컬럼형 저장, 최적화 패스, Parquet 푸시다운으로 빠른 분석 쿼리를 처리하는 방식을 깊게 설명한 글이다. 6GB Parquet 파일을 노트북에서 바로 SQL로 읽는 경험 뒤에 어떤 설계가 깔려 있는지 따라간다.

backend

피지독, 포스트그레스를 수평 확장시키겠다고 550만 달러 투자 유치

피지독은 포스트그레스 앞단에 프록시를 두고 샤딩과 라우팅을 처리해 수평 확장을 가능하게 하겠다는 오픈소스 프로젝트다. 이미 프로덕션에서 초당 200만 건이 넘는 쿼리를 처리하고, 확인된 규모만 20테라바이트 이상을 샤딩했다고 밝히며 550만 달러 투자를 공개했다.

backend

펜타시스템, EDB 포스트그레SQL로 국내 엔터프라이즈 DB 전환 시장 공략

펜타시스템테크놀러지가 EDB와 파트너 계약을 맺고 국내에 EDB 포스트그레SQL 기반 데이터 플랫폼을 공급한다. 기존 상용 DBMS 정책 변화로 비용 부담이 커진 기업들을 겨냥해, 오픈소스 기반 엔터프라이즈 데이터 플랫폼 전환 수요를 잡겠다는 전략이다. 금융, 공공, 제조, 유통, 클라우드, AI 데이터 분석 환경까지 적용 범위를 넓히려는 움직임이다.