State of Haskell Survey 2025의 77번 문항 자유 서술형 응답을 분석해, 커뮤니티가 Haskell에서 바꾸고 싶어 하는 주요 주제와 경향을 정리한 보고서입니다.
Haskell BlogHécate 2026년 4월 2일 [생태계] #생태계 설문조사 이 보고서는 State of Haskell Survey 2025의 77번 문항에 대한 자유 서술형 응답을 요약한 것입니다. 질문의 표현 방식 때문에 정밀성, 실행 가능성, 관련성이 각기 다른 553개의 답변을 받았습니다. 두 사람으로 구성된 팀(Sawa & Hécate)이 설문 결과를 정량적·정성적으로 분석하여, 커뮤니티가 무엇이 바뀌길 원하는지에 대한 경향과 주제를 추출했습니다.
설문 응답에 대한 정성 분석에는 경향과 분위기를 포착하고, 답변의 관련성을 판단하는 어려운 작업이 수반됩니다. 우리는 어떤 답변이 XY Problem의 사례인지, 그렇다면 더 근본적인 문제가 무엇인지 이해해야 했습니다. 어떤 답변은 유행하는 분위기라고 분류하기에도, 실행 가능한 제안이라고 분류하기에도 지나치게 모호했습니다. 마지막으로, 이런 분석을 수행할 때 중요한 점 하나는 설문에 시간을 들여 응답한 사람들에 대한 공감을 가지고, 그들의 답변을 곧바로 일축하지 않는 것입니다.
다음 주제들은 설문 참여자들로부터 가장 많은 응답을 모은 것들입니다. 특정한 순서 없이 제시합니다.
String 대신 Text를 사용하도록 API 전환두드러지게 구체적인 제안 하나는 텍스트 데이터를 위한 표준 타입으로 String을 Text로 대체하자는 것이었습니다. 특히 한 응답은 그 이유를 다음과 같이 설명합니다.
text라이브러리는base와 별개로 존재해야 하므로,base의 어떤 API도Text를 사용할 수 없습니다. 그리고 사람들이 잘 작성된 Haskell 코드의 예시를 찾으려고 base를 보면 결국String을 사용하게 되는데, 이것은 올바른 선택이 아닙니다.
이 문제는 초보자와 숙련 사용자 모두에게 공통된 좌절의 원천이었습니다. 이 주제는 특히 2022년에 Discourse에서 활발히 논의되었습니다: Bringing Data.Text into base: What is the next step?
초보자를 위한 자료의 품질에 대한 우려가 매우 많이 제기되었습니다. 최신 콘텐츠와 언어 차원의 중앙화된 진입점은 우리가 받은 제안 중에서도 특히 실행 가능성이 높은 것들입니다. Haskell Wiki는 특히 검색 엔진에 잘 노출되지만, 기여는 꾸준히 줄어들고 있습니다. 계정을 신청하고 문서에 기여해 주시길 권장합니다.
이 항목은 누구에게도 놀라운 내용은 아니겠지만, 다행히도 우리가 받은 통찰 중 일부는 실제로 개선할 수 있는 구체적인 방향을 제시했습니다. 라이브러리 작성자들은 더 많은 실행되는 예제를 제공하고, 단순한 API 레퍼런스의 범위를 넘어서는 문서를 작성하길 권장합니다.
커뮤니티 모임은 문서 기여에 특히 적합합니다. 문서가 필요한 사람들과 그것을 가장 잘 작성할 수 있는 사람들이 만날 수 있기 때문입니다.
어떤 종류의 문서가 존재하며 각각을 언제 사용해야 하는지에 대한 더 자세한 내용은 Documentation Best Practices in 2024를 읽어보실 수 있습니다.
참여자들 사이에서는 Haskell 언어가 지나치게 복잡하고, 역사적 잔재가 뒤엉켜 있으며, 지난 10년 동안 언어와 라이브러리가 발전해 온 방식에 일관성이 부족하다고 인식하는 경향이 있음을 확인했습니다.
Prelude에서 부분 함수를 피하고, 보다 일반적으로는 건전하고 안전한 기본값을 제공하자는 제안이 반복해서 등장했습니다. 사람들은 base 라이브러리가 Haskell의 강점을 빛나게 하는 공간이 되기를 원하지, 단지 편리한 함수들의 잡탕이 되기를 바라지 않습니다.
GHC에 언어 확장을 더 이상 추가하지 말자거나, 기존 확장들을 전체적인 관점에서 다시 설계하자는 요청도 있었습니다. 이러한 피드백은 새로운 Haskell Language Report를 요구하는 답변들과도 맥을 같이합니다. 새로운 보고서는 GHC가 지난 수년간 도입한 확장들을 활용할 수 있을 것입니다.
일정 비율의 설문 참여자들은 Haskell의 레코드 상태에 대해 불만을 표했습니다. 답변들은 대체로 모호했기 때문에 구체적인 실행 계획이라기보다는 분위기 지표에 가깝지만, OverloadedRecordDot과 NoFieldSelectors를 기본적으로 활성화해 달라는 눈에 띄는 요청이 있었습니다.
“GHC를 10배 더 빠르게 만들어라”는 참여자들 사이에서 널리 나타난 분위기 중 하나였습니다. 최종 사용자들의 제안인 만큼, 여기에는 실행 가능한 조언이나 컴파일 파이프라인의 구체적 고통 지점이 함께 제시되지는 않았습니다. 성능이 낮은 노트북 같은 구체적인 상황은 언급되었습니다.
Haskell 언어와 그 생태계는 30년이 넘었기 때문에, 새로운 사람들과 아이디어가 커뮤니티에 들어오면서 도구가 어느 정도 파편화되는 것은 자연스러운 일입니다. 그러나 기존 도구 생태계를 만들어낸 기술적·정치적 이견의 복잡함을 헤쳐 나가고 싶지 않은 신규 사용자들에게는 이것이 혼란을 줍니다. 설문 참여자들은 매우 유용하게도, 완전히 통합된 툴체인(도구 관리와 프로젝트 관리)을 보여주는 예시로 uv 같은 프로젝트에 주목하라고 알려 주었습니다.
컴파일 오류 메시지 역시 혼란스럽다는 지적을 받습니다. 이는 메시지가 의도한 독자와 실제 독자 사이의 불일치로 설명할 수 있을지도 모릅니다. 오류 메시지는 최종 사용자보다 구현자를 위한 것처럼 느껴질 수 있습니다. 최근 GHC 버전들은 사용자를 Haskell error index로 안내하기 시작했으므로, 향후 몇 년간 긍정적인 발전을 기대할 수 있습니다. 하지만 구현 세부사항에 익숙하지 않은 최종 사용자를 위해 오류 메시지를 계속 개선해야 합니다.
마지막으로, Haskell Language Server는 참여자들이 개발 경험에 대해 불평할 때 자주 언급되는데, 주된 이유는 그들과 직접 상호작용해야 하기 때문입니다. 따라서 메모리 사용량과 신뢰성은 대부분의 사람들이 체감하는 문제입니다.
지연성에 대한 불안은 반복적으로 등장하는 주제로, 개발자들이 지연 평가를 추론하는 데 여전히 어려움을 겪고 있음을 보여 줍니다. 런타임 동작을 오해해서 자원 사용이 폭증하는 문제는 Haskell 소프트웨어를 배포하거나 배포용으로 패키징할 때 사람들을 불안하게 만듭니다. 지연 I/O를 제거하자는 실행 가능한 조언도 제시되었는데, 이는 실제로 사람들을 자주 곤란하게 만드는 요소로 알려져 있습니다. 사람들은 이런 문제가 스트리밍 라이브러리를 사용할 때에만 발생하리라 기대할 수도 있기 때문입니다.
일부 제안은 더 구체적이었습니다. 예를 들어 데이터 구조를 기본적으로 엄격하게 만들고, 개발자가 원할 때만 StrictData extension을 통해 명시적으로 지연적으로 만들자는 의견이 있었습니다.
이 주제들은 언급량은 더 적었지만 여전히 상당한 수준으로 제기되었습니다. 이것이 중요하지 않다는 뜻은 아니며, 단지 대부분의 참여자들에게는 다른 우려가 더 시급해 보였다는 뜻입니다.
사람들은 무엇이 나쁜지에 대해 생각하지 않을 때, 무엇이 더 나아질 수 있을지를 생각하기 시작합니다. Dependent Types라는 주제는 충분히 자주 등장하여 우리의 주목을 끌었습니다. Dependent Haskell은 서로 느슨하게 관련된 여러 언어 확장을 대체할 수 있는 통합적 해법으로 여겨집니다. 구현 진행 상황은 Dependent Haskell Roadmap 페이지에서 확인할 수 있습니다.
공동체에 대한 열망은 인간에게 늘 존재하며, Haskeller도 예외가 아닙니다. 사람들은 자신들의 커뮤니티가 번창하고, 더 많은 사람들을 만나고, 비기술적 기여가 더 높은 평가를 받기를 바랍니다.
지난 몇 년 동안, 기존 Transformers/MTL 접근법의 한계를 대체하기 위한 대수적 효과 시스템의 연구와 개발이 증가했습니다. 이제 base가 이런 것을 기본 제공하기를 바라는 관심이 나타나기 시작했습니다. 더 많은 상호운용성을 원하는 참여자들은 또한 IO 모나드에서 동작하는 대부분의 함수가 MonadIO를 사용하도록 바뀌기를 원한다고 밝혔습니다.
참여자들은 Haskell 프로그램의 아키텍처, 라이브러리 선택, 생태계 파편화와 관련하여 일관된 서사를 갖기를 바란다는 관심을 드러냈습니다.
디버깅은 여전히 참여자들에게 아픈 지점이지만, Haskell Debugger가 언급되었고 대부분의 고충을 해결하는 것으로 보입니다. “HasCallStack everywhere” 역시 언급되었는데, 우리는 이것을 기존 디버깅 도구와 백트레이스 메커니즘에 대한 인식의 증상으로 봅니다.
앞서 언급한 많은 답변 밑바탕에는 “Haskell은 누구를 위한 언어인가?”라는 질문이 깔려 있습니다. 비엄격 평가와 순수 함수형 프로그래밍을 연구하기 위한 학술 프로젝트로 시작한 Haskell은 산업 현장의 소프트웨어 엔지니어들에게도 채택될 만큼 성장했고, 그에 따라 학습 방식과 교류 방식도 달라졌습니다. 산업 현장의 프로그래머들 중 일정 비율은 생태계의 학술 중심성 때문에 소외감을 느낍니다. 특히 학문적 배경이나 정규 교육이 없는 사람들에게 그렇습니다.
특히 한 답변은 이 주제를 다음과 같이 자세히 설명합니다.
유형 이론 / 심화 수학 애호가들을 위해 또는 그들에 의해 만들어진 문서가 있고, 그것이 개발자 문서로는 잘 번역되지 않는다는 점을 인정할 필요가 있습니다. 새로운 개발자들이 모범 사례를 찾을 때, 그들은 종종 수학적 추상화의 관점에서 장황한 문체로 글을 쓰는 똑똑하고 선의의 사람들이 쓴 블로그로 안내됩니다. 소프트웨어 공학 지향의 문서는 언제나 환영받지만, 놀랄 만큼 드뭅니다.
어떤 답변들은 너무도 인상적이어서, 그 놀라움을 반영하는 방식으로 분류할 수밖에 없었습니다. 여기 우리가 가장 마음에 들었던 것들을 소개합니다.
일부 설문 참여자들은 다른 언어를 원합니다. 다른 언어에서 영감을 얻는 수준을 넘어, ::와 :의 의미를 서로 바꾸자거나, 지연성을 제거하자거나, 언어와 도구를 전면적으로 불태우고 새로 정비하자는 식의 제안까지 나왔습니다. Lean과 Idris가 더 취향에 맞을 수도 있습니다.
모호한 푸념과 스스로도 불가능하다고 인정한 아이디어들은 우리 마음속에 특별한 자리를 차지합니다. “base를 바꿔라”, “TypeScript 같은 도구”, “이 이상한 문법을 고쳐라” 같은 것들이 꽤 좋았습니다. VS Code, TypeScript, Go 같은 대규모 기업 프로젝트가 받는 수준의 지원 없이는 이런 변화가 가능할지 상상하기 어렵습니다.
특히 “이상한 문법”에 대해서는 언급할 가치가 있습니다. 이건 우리가 분명히****뭔가 할 수 있는 일입니다. 그저 “문법 고치기”라고 쓰인 커다란 빨간 버튼을 누르는 걸 잊었을 뿐이죠. 상기시켜 주셔서 감사합니다!
올해 설문은 Haskeller의 일정 비율이 무엇을 고민하고 있는지에 대해 매우 값진 통찰을 제공했습니다. 물론 설문은 본질적으로 자기 선택적 도구이므로, 결과를 다룰 때는 주의가 필요합니다. 우리는 커뮤니티 전체가 정확히 무엇을 생각하는지는 알 수 없고, 오직 설문에 응답한 하위 집단이 무엇을 생각하는지만 알 수 있습니다. 응답은 한 단어("base")에서부터 GHC Proposal 또는 Core Libraries Proposal의 출발점이 될 만한 여러 단락에 이르기까지 매우 다양했습니다. 누구나 제안을 열 수 있으니, 꼭 그렇게 해보시길 권합니다!
도구 생태계는 초보자 온보딩에서 개발자 경험의 통합에 이르기까지 많은 주제를 관통하는 공통 실입니다. 완전히 통합된 개발 생태계와, 서로 다른 길을 자유롭게 탐색할 수 있는 여러 구현을 가진 언어 사이에는 긴장이 존재합니다.
올해 설문에 참여해 주셔서 다시 한 번 감사합니다. 새로운 판이 나올 때마다 우리는 커뮤니티 경향을 측정할 더 많은 데이터 포인트를 얻게 되고, 이는 여러 그룹이 Haskell 개발자들에게 최선의 경험을 설계하는 데 도움을 줍니다.
A Couple Million Lines of Haskell: Production Engineering at Mercury ›
© 2026 The Haskell Programming Language's blog