2025년 8월 24일·7분
하스켈이 함수형을 넘어 현대 언어 설계를 형성한 방법
하스켈이 강한 타입, 패턴 매칭, 효과 처리 같은 아이디어를 어떻게 대중화했는지, 그리고 그 개념들이 비(非)함수형 언어들에 어떻게 영향을 주었는지 살펴봅니다.
하스켈이 강한 타입, 패턴 매칭, 효과 처리 같은 아이디어를 어떻게 대중화했는지, 그리고 그 개념들이 비(非)함수형 언어들에 어떻게 영향을 주었는지 살펴봅니다.
하스켈은 흔히 “순수 함수형 언어”로 소개되지만, 그 진정한 영향력은 함수형과 비함수형의 경계를 훨씬 넘어섭니다. 강력한 정적 타입 시스템, 부작용을 분리하려는 성향(계산과 부작용을 분리), 그리고 제어 흐름이 값을 반환하는 표현 지향 스타일은 정확성, 조합성, 툴링에 대한 진지한 관심을 촉발했습니다.
그 압력은 하스켈 생태계 안에만 머물지 않았습니다. 가장 실용적인 아이디어들은 표면적 문법을 복제하지 않고도 설계 원칙으로 흡수되어 버그를 만들기 어렵게 하고 리팩터링을 더 안전하게 만들었습니다.
사람들이 하스켈이 현대 언어 설계에 영향을 미쳤다고 말할 때, 다른 언어들이 곧바로 ‘하스켈처럼 보이게’ 되었다는 뜻은 아닙니다. 영향은 주로 개념적입니다: 타입 주도 설계, 더 안전한 기본값, 불법적 상태를 표현하기 어렵게 만드는 기능 등입니다.
언어들은 이러한 개념을 빌려와 각자의 제약에 맞게 적응합니다—종종 실용적 타협과 더 친숙한 문법으로요.
주류 언어는 UI, 데이터베이스, 네트워크, 동시성, 큰 팀이라는 뒤얽힌 환경에서 작동합니다. 그런 맥락에서 하스켈에서 영감을 받은 기능들은 버그를 줄이고 코드를 진화시키기 쉽게 만듭니다—모두가 “완전히 함수형으로 전환”할 필요는 없습니다. 부분적 채택(더 나은 타입, 결측값 처리 명확화, 예측 가능한 상태)이더라도 빠른 이득을 줍니다.
하스켈의 어떤 아이디어가 현대 언어들의 기대를 바꿨는지, 그 아이디어가 여러분이 이미 쓰는 도구들에 어떻게 드러나는지, 그리고 미학을 복제하지 않고 원칙을 실무에 적용하는 방법을 보여드립니다. 목표는 실용적입니다: 무엇을 빌려갈지, 왜 도움이 되는지, 그리고 어떤 트레이드오프가 있는지요.
하스켈은 정적 타입이 단순히 컴파일러의 확인 항목이 아니라 설계적 태도라는 생각을 정착시켰습니다. 타입을 선택적 힌트로 취급하는 대신 하스켈은 타입을 프로그램이 할 수 있는 일을 설명하는 주요 수단으로 봅니다. 많은 최신 언어가 이 기대를 받아들였습니다.
하스켈에서 타입은 컴파일러와 사람 모두에게 의도를 전달합니다. 이 사고방식은 언어 설계자들이 강한 정적 타입을 사용자에게 유익한 기능으로 보게 만들었습니다: 늦은 시점의 깜짝 문제 감소, 더 명확한 API, 코드 변경 시 더 큰 자신감.
하스켈의 흔한 워크플로우는 타입 서명을 먼저 쓰고 데이터 타입을 정의한 다음 구현을 채워 타입이 맞게 만드는 것입니다. 이는 유효하지 않은 상태를 표현하기 어렵게 하는 API를 장려하고 작은 조합 가능한 함수로 유도합니다.
비함수형 언어에서도 표현력이 풍부한 타입 시스템, 향상된 제네릭, 컴파일 타임 검사로 전체 범주의 실수를 막는 경향에서 이 영향이 보입니다.
강한 타이핑이 기본이면 툴에 대한 기대도 올라갑니다. 개발자들은 다음을 기대하게 됩니다:
대가는 분명합니다: 학습 곡선이 있고 때로는 타입 시스템과 싸워야 합니다. 그러나 보상은 런타임에서의 깜짝 상황 감소와 대규모 코드베이스를 일관되게 유지하는 더 명확한 설계 레일입니다.
대수적 자료형(ADT)은 단순하지만 영향력 큰 아이디어입니다: 의미를 null, -1, 빈 문자열 같은 ‘특별 값’으로 인코딩하는 대신, 명명된 명시적 경우들의 작은 집합을 정의합니다.
Maybe/Option과 Either/Result하스켈은 다음과 같은 타입을 널리 알렸습니다:
Maybe a — 값이 존재하거나(Just a) 존재하지 않는다(Nothing).Either e a — 두 가지 결과 중 하나를 얻는다. 보통 “오류(Left e)” 또는 “성공(Right a)”.이는 모호한 규약을 명시적 계약으로 바꿉니다. Maybe User를 반환하는 함수는 미리 “사용자가 없을 수도 있다”는 것을 알려줍니다. Either Error Invoice는 실패가 예외적 여담이 아니라 정상 흐름의 일부임을 전달합니다.
널과 센티넬 값은 숨은 규칙을 기억하게 만듭니다("빈값은 누락을 의미한다", "-1은 미지" 등). ADT는 그 규칙을 타입 시스템으로 옮겨 값이 사용되는 모든 곳에서 가시화하고 검사할 수 있게 합니다.
그래서 주류 언어들은 “데이터를 지닌 열거형(enums with data)”을 채택했습니다: Rust의 enum, Swift의 연관값을 가진 enum, Kotlin의 sealed class들, TypeScript의 판별 유니언은 모두 추측 없이 실제 상황을 표현할 수 있게 해줍니다.
값이 의미 있는 몇 가지 상태만 가질 수 있다면 그 상태들을 직접 모델링하세요. 예를 들어 status 문자열과 선택적 필드 대신:
Draft (아직 결제 정보 없음)Submitted { submittedAt }Paid { receiptId }타입이 불가능한 조합을 표현할 수 없을 때, 많은 종류의 버그가 런타임 전에 사라집니다.
패턴 매칭은 하스켈의 가장 실용적인 아이디어 중 하나입니다: 일련의 조건문으로 값을 들여다보는 대신, 기대하는 형태들을 기술하고 언어가 각 경우에 맞는 분기로 라우팅하게 합니다.
긴 if/else 체인은 종종 같은 검사를 반복합니다. 패턴 매칭은 이를 명확히 이름 붙여진 케이스들의 간결한 집합으로 바꿉니다. 위에서 아래로 읽으면 선택지 메뉴처럼 이해하기 쉽습니다.
하스켈은 간단한 기대를 밀어붙입니다: 값이 N개의 형태 중 하나라면, 그 N개를 모두 처리해야 한다는 것. 하나를 빠뜨리면 컴파일러가 조기에 경고합니다—사용자가 크래시를 보거나 이상한 폴백 경로를 경험하기 전에요. 이 아이디어는 널리 퍼졌고, 많은 현대 언어는 enum 같은 폐쇄 집합에 대해 전개 처리를 검사(또는 권장)할 수 있습니다.
패턴 매칭은 다음과 같은 주류 기능에 나타납니다:
match, Swift의 switch, Kotlin의 when, 최신 Java/C#의 switch 표현식Result/Either를 매칭해 에러 코드를 체크하는 대신 흐름으로 처리Loading | Loaded data | Failed error 같은 UI 상태값의 종류(variant/state) 에 따라 분기할 때 패턴 매칭을 쓰세요. 단순 불리언 조건이나 가능성이 열린 집합인 경우 if/else를 유지하세요.
타입 추론은 컴파일러가 타입을 알아내는 능력입니다. 여전히 정적 타입 언어지만 모든 타입을 일일이 적을 필요가 없습니다. 표현식을 쓰면 컴파일러가 프로그램 전체를 일관되게 만드는 가장 정밀한 타입을 유추합니다.
하스켈에서는 추론이 부차적 편의 기능이 아니라 중심입니다. 이로 인해 개발자들은 “안전한 언어”에 대해 다른 기대를 갖게 되었습니다: 강력한 컴파일 타임 검사를 가지면서 보일러플레이트에 갇히지 않아도 된다는 것입니다.
추론이 잘 작동하면 두 가지를 동시에 충족합니다:
리팩터링도 개선됩니다. 함수 하나를 바꿔 추론 타입을 깨트리면 컴파일러가 어디가 어긋났는지 정확히 알려줍니다—종종 런타임 테스트보다 더 빨리요.
하스켈 개발자들도 여전히 타입 서명을 자주 씁니다—그리고 그건 중요한 교훈입니다. 추론은 지역 변수와 작은 헬퍼에 훌륭하지만, 명시적 타입은 다음 상황에서 도움이 됩니다:
추론은 소음을 줄여주지만 타입은 강력한 커뮤니케이션 도구로 남습니다.
하스켈은 “강한 타입이 곧 장황한 타입”이라는 통념을 깨뜨렸습니다. 추론을 기본 편의 기능으로 만든 언어들에서 이 기대가 반영됩니다. 하스켈을 직접 언급하지 않더라도 기준은 이동했습니다: 개발자들은 컴파일러가 이미 알고 있는 것을 반복하는 데 의심을 갖게 되었습니다.
하스켈의 큰 아이디어는 부작용을 영원히 피하는 것이 아니라, 부작용을 명시적이고 통제 가능하게 만드는 것입니다. 순수한 코드는 결정과 변환을 담당하고, 효과가 있는 코드는 가장자리로 밀려 가시적이고 별도로 검토·테스트됩니다.
비순수 생태계에서도 같은 설계 압력이 보입니다: 더 명확한 경계, 언제 I/O가 발생하는지 알리는 API, 숨은 의존성이 없는 함수를 보상하는 툴(예: 캐싱, 병렬화, 리팩터링에 유리)이 그것입니다.
어떤 언어에서나 이 아이디어를 차용하는 간단한 방법은 작업을 두 계층으로 나누는 것입니다:
테스트가 순수 코어만으로 동작하면 시간이 걸리지 않고 신뢰성 높은 테스트를 얻을 수 있고, 설계 문제는 더 빨리 드러납니다.
모나드는 때론 위협적인 이론으로 소개되지만, 일상적 아이디어는 단순합니다: 규칙을 갖고 연산을 순차적으로 연결하는 방법입니다. 특수한 제어 흐름을 여기저기 흩뿌리지 않고도 평범해 보이는 파이프라인을 작성하면 “컨테이너”가 다음 연결 방식을 결정합니다.
모나드를 값과 그 값을 연결하는 정책으로 생각하세요:
이 정책이 효과를 관리 가능하게 합니다: 매번 제어 흐름을 재구현하지 않고도 단계를 합성할 수 있습니다.
하스켈이 이런 패턴을 널리 알렸지만 이제는 어디에나 보입니다:
Option/Maybe는 “없음”에서 자동으로 단계를 단축시켜 널 체크를 피하게 합니다.Result/Either는 실패를 데이터로 만들어 오류가 성공과 함께 흐르도록 합니다.Task/Promise 같은 타입은 나중에 실행되는 연산을 연결하면서 가독성을 유지하게 합니다.언어들이 “모나드”라고 명시하지 않더라도 영향은 다음 형태로 보입니다:
map, flatMap, andThen)으로 비즈니스 로직을 선형으로 유지async/await: 콜백 지옥 없이 효과적인 단계 순서를 제공하는 친숙한 표면핵심 요지는 범주 이론을 외우기보다 ‘실패할 수 있는, 없을 수 있는, 혹은 나중에 실행되는 계산을 합성한다’는 사용 사례에 집중하는 것입니다.
타입 클래스는 하스켈의 가장 영향력 있는 아이디어 중 하나로, 구체적 능력(예: “비교할 수 있다”, “텍스트로 변환할 수 있다”)에 의존하는 제네릭 코드를 어떻게 작성할지 해결합니다. 이때 모든 것을 단일 상속 계층으로 몰아넣을 필요가 없습니다.
간단히 말해 타입 클래스는 “어떤 타입 T가 이 연산들을 지원하면 내 함수는 동작한다”고 말할 수 있게 해줍니다. 이는 **임의적 다형성(ad-hoc polymorphism)**입니다: 함수는 타입에 따라 다르게 동작할 수 있지만 공통 부모 클래스를 요구하지 않습니다.
이로 인해 관련 없는 타입들을 추상 기반 타입 아래로 억지로 넣거나, 깊고 깨지기 쉬운 상속 구조에 빠지는 전형적 객체지향의 함정을 피할 수 있습니다.
많은 주류 언어가 유사한 구성요소를 채택했습니다:
공통점은 “is-a” 관계보다 준수(conformance) 를 통해 동작을 추가할 수 있다는 점입니다.
하스켈의 설계는 또한 미묘한 제약을 강조합니다: 둘 이상의 구현이 적용될 수 있으면 코드가 예측 불가능해질 수 있습니다. 일관성(coherence)과 중복/겹치는 인스턴스를 피하는 규칙은 “제네릭 + 확장 가능”이 런타임에서 미스테리로 변하는 것을 막습니다. 여러 확장 메커니즘을 제공하는 언어들도 비슷한 트레이드오프를 해야 합니다.
API 설계 시 작은 트레잇/프로토콜/인터페이스를 조합하는 것을 선호하세요. 강력한 재사용성을 유지하면서 소비자를 깊은 상속 구조로 몰아넣지 않고 테스트와 확장이 쉬운 코드를 얻을 수 있습니다.
불변성은 하스켈에서 영감을 받은 습관 중 하나로, 하스켈 코드를 전혀 쓰지 않더라도 반복해서 이득을 줍니다. 데이터가 생성된 후 변경될 수 없을 때 “누가 이 값을 바꿨나?”라는 버그 범주가 사라집니다—특히 여러 함수가 같은 객체를 건드리는 공유 코드에서 그렇습니다.
가변 상태는 흔히 지루하지만 비용이 큰 실패를 초래합니다: 보조 함수가 “편의상” 구조를 변경하고 이후 코드가 이전 값을 암묵적으로 기대하는 경우 등. 불변 데이터에서는 “업데이트”가 새 값을 만드는 것이므로 변경이 명시적이고 국지화됩니다. 이로 인해 가독성도 좋아집니다: 값을 컨테이너가 아닌 사실(fact)으로 취급할 수 있습니다.
불변성은 낭비처럼 보이지만, 주류 언어들이 함수형에서 차용한 트릭 덕분에 실용적입니다: 지속적 자료구조. 변경 시 전체를 복사하는 대신 새 버전이 이전 버전과 대부분의 구조를 공유합니다. 이렇게 하면 효율적인 연산을 유지하면서 이전 버전을 보존할 수 있습니다(undo/redo, 캐싱, 스레드 간 안전한 공유에 유용).
이 영향은 언어 기능과 스타일 권장에서 보입니다: final/val 바인딩, 객체 동결(frozen objects), 읽기 전용 뷰, 불변 패턴을 장려하는 린터 등. 많은 코드베이스는 언어가 변경을 허용하더라도 “명확한 필요가 있을 때만 변경”을 기본으로 합니다.
불변성을 우선시하세요:
파싱이나 성능 민감 루프처럼 경계가 좁은 곳에서만 변이를 허용하고 비즈니스 로직에서는 피하세요.
하스켈은 함수형을 널리 알린 것뿐 아니라 많은 개발자가 “좋은 동시성”이 무엇인지 재고하게 만들었습니다. 동시성을 “스레드 + 락”으로 보는 대신 더 구조화된 관점을 도입했습니다: 공유 변이를 드물게 하고 통신을 명시적으로 하며 런타임이 가벼운 작업 단위를 많이 처리하게 한다는 관점입니다.
하스켈 시스템은 종종 OS 스레드보다 런타임이 관리하는 경량 스레드에 의존합니다. 이는 사고 방식을 바꿉니다: 많은 작은 독립 작업을 구조화해도 각 작업을 추가할 때 큰 비용을 지불하지 않게 됩니다.
이는 메시지 전달과 자연스럽게 짝을 이룹니다: 프로그램의 부분들은 공유 객체를 잠그기보다 값을 보내는 방식으로 소통합니다. 상호작용이 “변수를 공유”하는 대신 “메시지 보내기”일 때 흔한 레이스 조건이 숨을 곳이 줄어듭니다.
순수성과 불변성은 대부분의 값이 생성 후 변경되지 않기 때문에 추론을 단순화합니다. 두 스레드가 같은 데이터를 읽어도 누가 중간에 변경했는지 의문이 생기지 않습니다. 이는 동시성 버그를 완전히 없애진 못하지만 표면적을 크게 줄여 우발적 버그를 줄입니다.
많은 주류 언어와 생태계는 액터 모델, 채널, 불변 자료구조, “통신으로 공유하기(share by communicating)” 가이드라인을 통해 이런 아이디어로 이동했습니다. 언어가 순수하지 않더라도 라이브러리와 스타일 가이드는 점점 상태를 분리하고 데이터를 전달하도록 팀을 유도합니다.
락을 추가하기 전에 공유 가변 상태를 먼저 줄이세요. 상태를 소유권 단위로 분할하고 불변 스냅숏 전달을 선호하며, 진정으로 공유가 불가피할 때만 동기화를 도입하세요.
QuickCheck는 단순한 테스트 라이브러리를 넘어서 다른 테스트 사고방식을 대중화했습니다: 몇 가지 예제를 직접 고르는 대신 항상 성립해야 할 속성을 기술하고 도구가 수백~수천 개의 무작위 테스트 케이스를 생성해 깨뜨려 보게 하는 방식입니다.
전통적 단위 테스트는 특정 사례의 기대 동작을 문서화하는 데 탁월합니다. 속성 기반 테스트는 여러분이 생각하지 못한 엣지 케이스를 탐색함으로써 그걸 보완합니다. 실패가 발생하면 QuickCheck 스타일 도구는 보통 실패 입력을 더 작은 반례로 축소(shrink) 해 주어 버그를 이해하기 쉽게 만듭니다.
그 워크플로우—생성(generator), 반증(falsify), 축소(shrink)—는 널리 채택되었습니다: ScalaCheck(Scala), Hypothesis(Python), jqwik(Java), fast-check(TypeScript/JavaScript) 등. 하스켈을 쓰지 않는 팀들도 파서, 직렬화기, 복잡한 비즈니스 룰 코드에 대해 이 방식이 매우 유용하다는 것을 경험하고 사용합니다.
다음 몇 가지 속성은 자주 높은 효율을 보입니다:
한 문장으로 규칙을 표현할 수 있다면 보통 그것을 속성으로 바꿔 도구가 이상한 경우를 찾아내게 할 수 있습니다.
하스켈은 단지 언어 기능을 널리 알린 것만이 아니라 개발자들이 컴파일러와 툴에 대해 무엇을 기대하는지 형성했습니다. 많은 하스켈 프로젝트에서 컴파일러는 번역기를 넘어 협업자처럼 다뤄집니다: 코드를 단순히 실행하는 것이 아니라 위험, 불일치, 누락된 케이스를 적극적으로 지적합니다.
하스켈 문화는 부분 함수, 사용되지 않는 바인딩, 비전개 패턴 같은 경고를 진지하게 받아들이는 편입니다. 사고방식은 간단합니다: 컴파일러가 의심스러운 점을 증명할 수 있다면 조기에 알려주길 원합니다—버그 리포트가 되기 전에요.
그 태도는 다른 생태계에도 영향을 주어 “경고 없는 빌드”를 표준으로 삼게 하고, 컴파일러 팀이 더 명확한 메시지와 실행 가능한 제안을 투자하게 만들었습니다.
언어에 표현력이 높은 정적 타입이 있으면 툴링도 더 자신 있게 됩니다. 함수를 리네임하거나 데이터 구조를 변경하거나 모듈을 분리하면 컴파일러가 모든 호출 지점을 안내해 줍니다.
시간이 흐르며 개발자들은 다음을 기대하게 되었습니다: 더 나은 정의로 이동(jump-to-definition), 안전한 자동 리팩터링, 더 신뢰할 수 있는 자동완성, 런타임에서의 미스터리한 오류 감소 등.
하스켈은 언어와 도구가 기본적으로 올바른 코드를 향하도록 유도해야 한다는 아이디어에도 영향을 주었습니다. 예:
이건 엄격함 자체가 목적이 아니라 올바른 일을 하는 비용을 낮추려는 시도입니다.
실천적 습관: 컴파일러 경고를 리뷰와 CI에서 1급 신호로 취급하세요. 경고가 허용 가능한 경우 그 이유를 문서화하고, 그렇지 않다면 고치세요. 이렇게 하면 경고 채널의 의미가 유지되고 컴파일러가 일관된 리뷰어 역할을 하게 됩니다.
하스켈이 현대 언어 설계에 준 가장 큰 선물은 단일 기능이 아니라 사고방식입니다: 불법적인 상태를 표현 불가하게 만들고, 효과를 명시하며, 반복적인 검사를 컴파일러에게 맡기라는 것. 하지만 모든 하스켈 영감이 모든 곳에 어울리는 건 아닙니다.
하스켈 스타일의 아이디어는 API 설계, 정확성 추구, 동시성으로 인해 작은 버그가 증폭될 수 있는 시스템에서 특히 빛을 발합니다.
풀스택 소프트웨어를 만든다면 이 패턴들은 실무에 잘 녹아듭니다: 예를 들어 React UI에서 TypeScript 판별 유니언을 쓰고, Flutter에서 Dart sealed class를 쓰고, 백엔드에서 명시적 에러 결과를 사용하는 식입니다.
추상화가 지위의 상징(status symbol)으로 채택될 때 문제가 생깁니다. 과도한 추상 코드는 의도를 숨기고, ‘영리한’ 타입 트릭은 온보딩을 늦춥니다. 팀원이 기능을 이해하려면 용어집이 필요하다면 그건 해롭습니다.
작게 시작해 반복하세요:
이 아이디어들을 전체 파이프라인을 재구성하지 않고 적용하려면 스캐폴딩과 반복 방식에 포함시키는 것이 도움이 됩니다. 예컨대, Koder.ai 같은 도구를 쓰는 팀은 계획 우선 워크플로우에서 도메인 상태를 명시적 타입으로 정의하고(예: UI 상태에 TypeScript 유니언, Flutter에 Dart sealed class), 어시스턴트에게 전개 처리된 흐름을 생성하게 한 뒤 소스 코드를 내보내고 다듬습니다. Koder.ai가 React 프런트엔드와 Go + PostgreSQL 백엔드를 생성할 수 있으므로 “상태를 명시하라”는 규칙을 초기에 강제하기에 편리합니다. 이는 임의의 널 체크와 마법 문자열이 코드베이스로 번지는 걸 막아줍니다.
하스켈의 영향은 외형적 유사성보다는 개념적 전이입니다. 다른 언어들은 대수적 자료형(ADT), 타입 추론, 패턴 매칭, 트레잇/프로토콜 같은 아이디어와 컴파일 타임 피드백 문화를 차용했지만, 문법이나 일상적 스타일은 전혀 다를 수 있습니다.
대규모 현실 시스템은 완전한 순수 함수형 생태계를 요구하지 않습니다. 대신 안전한 기본값을 도입하면 많은 이득을 얻습니다. 예를 들어 Option/Maybe, Result/Either, 철저한 switch/match 처리, 향상된 제네릭 등은 I/O, UI, 동시성 작업이 많은 코드베이스에서 버그를 줄이고 리팩터링을 쉽게 만듭니다.
타입 주도 개발은 먼저 데이터 타입과 함수 시그니처를 설계하고, 그 후 구현을 채워 넣어 타입이 맞게 만드는 방식입니다. 실무에서 적용하려면:
Option, Result).목표는 타입이 API 형태를 이끌어 실수 표현 자체를 어렵게 만드는 것입니다.
ADT는 값을 유한한 명명된 경우들로 모델링해 null이나 특수값(-1, "") 같은 규약을 제거합니다. 예를 들어:
Maybe/Option은 “존재함 vs 없음”을Either/Result는 “성공 vs 실패”를 표현합니다.이렇게 하면 엣지 케이스가 명시적으로 드러나고 컴파일 시점에 다룰 수 있게 됩니다.
패턴 매칭은 가지(branch)를 값의 종류/구조로 표현해 가독성을 높입니다. 컴파일러의 완전성(exhaustiveness) 검사 덕분에 누락된 케이스를 경고받을 수 있습니다.
패턴 매칭을 선호할 때는 값의 **변형/상태(variant/state)**로 분기할 때입니다. 단순 불리언 조건(예: 이 수가 > 0인가?)이나 열린 집합의 경우 if/else가 더 적절합니다.
타입 추론은 컴파일러가 타입을 유추해 정적 타입의 장점을 유지하면서 코드의 장황함을 줄여줍니다. 실무 규칙 예:
이로써 안전성과 간결성 사이의 균형을 맞출 수 있습니다.
하스켈의 순수성(purity)은 같은 입력엔 항상 같은 출력을 내는 함수라는 뜻입니다. 목표는 효과를 피하는 게 아니라 효과를 명시하고 경계에 둔다는 것입니다. 실무에서 적용하려면 “순수한 코어 / 효과를 담당하는 셸” 패턴을 사용하세요:
이렇게 하면 테스트가 쉬워지고 숨은 의존성이 줄어듭니다.
모나드는 복잡한 이론처럼 보이지만 실용적 핵심은 ‘규칙을 가진 연산의 연결(chaining)’입니다. 예:
중요한 점은 범주이론을 외우는 것이 아니라 map, flatMap, andThen 같은 합성 패턴으로 문제를 푸는 것입니다. 도 같은 사고의 산물입니다.
타입 클래스는 ‘비교할 수 있다’, ‘텍스트로 변환할 수 있다’ 같은 **능력(capability)**을 기반으로 제네릭 코드를 쓰게 해 줍니다. 이는 상속 계층구조에 얽매이지 않는 재사용을 가능하게 합니다. 현대 언어에서의 대응물:
설계 팁: 작은 능력 단위(트레잇/프로토콜)를 조합하도록 하세요. 깊은 상속 대신 합성이 더 유연합니다.
퀵체크(QuickCheck)는 속성 기반 테스트(property-based testing)를 널리 알렸습니다. 핵심은 ‘특정 입력을 고르는 대신, 지켜야 할 속성을 정의하면 도구가 많은 랜덤 케이스를 생성해 깨뜨려 본다’는 것과, 실패하면 보통 최소 반례로 축소(shrink)해 준다는 점입니다.
빠른 성과를 주는 속성들:
이 패턴은 버그의 의외의 구석을 찾아내는 데 아주 효과적입니다.
하스켈은 컴파일러와 툴링에 대한 기대치도 높였습니다. 컴파일러는 단순 번역기가 아니라 잠재적 문제를 미리 지적해 주는 공동 작업자처럼 여겨집니다.
실천적 습관:
이렇게 하면 ‘올바른 행동을 하는 쪽이 더 쉬운’ 환경을 만들 수 있습니다.
Promise/async/await