<div id="readability-page-1" class="page"><div><p>ReScript를 아마 실무에서 1년이상 써본 사람은 많지는 않을 것 같은데 (굳이 그 대상을 한국으로 한정짓지 않아도), 사실 제대로 된 블로그 글을 쓸만한 여유는 없고 그 경험을 메모처럼 적어본다.</p>
<p>ReScript에 관심이 있지만 실무에 도입할 만한지 고민하는 사람들이 있을 것이라고 생각한다. 특히 TypeScript 대비 큰 장점이 있는지, 도입에 문제가 될만한 부분이 있는지 궁금해할 것 같다. 입지가 잘 다져지지 않은 언어를 영업을 해야 하는 입장에선 보통 좋은 부분만 말할 수 밖에 없기도 하고, 실무로 사용해본 사람이 많지 않아 실무 도입의 단점이 잘 정리되어 있는 경우는 흔치 않을 것 같다. 그래서 간단하게 정리해 본다.</p>
<h3 id="rescript-실무-도입의-장점">ReScript 실무 도입의 장점</h3>
<ul>
<li>TypeScript에 익숙한 사람이면 상당히 금방 배울 수 있다. 적절한 가이드만 있다면.</li>
<li>언어에 킬러 피쳐들이 많다. 패턴 매칭, Optional, if as expression, pipe, etc... 추론도 매우 강력해서 타입을 반복적으로 손으로 써줄 일이 거의 없다. 오히려 TypeScript 대비 초심자에게 더 적합.</li>
<li>생각보다 active하게 개발되고 있다. 개발진들이 (내 기준) 이슈에 매우 민첩하게 대응해주는 편이다. 커뮤니티도 어느정도 형성되어 있다.</li>
</ul>
<h3 id="rescript-실무-도입-시-단점">ReScript 실무 도입 시 단점</h3>
<ul>
<li>당연하지만, 익숙해지는 데 시간이 좀 걸린다. 숙련된 개발자도 보통 적응기간이 1-2개월 정도 걸리는 것 같다. (함수형 언어에 대한 선행학습이 되어 있을 경우, 더 빨리 안착할 수 있다)</li>
<li>당장 가져다 쓸 수 있는 바인딩이 잘 없다. 바인딩을 직접 쓰는 데 많이 익숙해져야 한다.<ul>
<li>대부분 바인딩은 굉장히 간단하지만, 일부 라이브러리들은 사고방식의 변화를 요구하기도 한다. (react-hook-form을 ReScript로 <a href="https://github.com/green-labs/rescript-bindings/blob/main/packages/rescript-react-hook-form/src/ReactHookForm.res">어떻게 바인딩할 것인가?</a>)</li>
<li>(경우가 흔하진 않지만) 빌드툴이 타입을 emit해야 하는 경우 좀 더 스코프가 커질 수도: <a href="https://github.com/zth/rescript-relay">rescript-relay</a></li>
</ul></li>
<li>돈의 맛이 느껴지는 TypeScript 개발 도구들을 쓰다 ReScript 세계로 오면 조금 부족함을 느낄 수 있다. 대부분의 경우는 괜찮지만, 시도때도 없이 나는 알 수 없는 VS Code 익스텐션 에러 등에 조금 지칠 수도</li>
</ul>
<h3 id="bonus-rescript-gotchas">bonus: ReScript Gotchas</h3>
<ul>
<li>파일명의 <a href="https://rescript-lang.org/docs/manual/latest/project-structure#file-casing">제약</a>이 있다.<ul>
<li>Next.js 사용 시 file-based routing 이슈가 자연히 발생하는데, route를 위한 파일은 TypeScript로 작성하고 ReScript 파일명은 자유롭게 작성하여 <code>export ... from ...</code> 으로 가져오길 추천한다.</li>
</ul></li>
<li>React 바인딩 / DOM API 등의 지원이 TypeScript 대비 불완전하다.<ul>
<li>1-2개의 props만 다른 비슷한 React 컴포넌트에 대해 모든 prop들을 따로 타이핑을 해야 할 수도 있다.</li>
<li>DOM API가 typesafe하지 않은 이유를 찾아봤다: <a href="https://forum.rescript-lang.org/t/more-type-safe-way-to-call-a-method-on-event-target/2728">글 링크</a></li>
<li>JSX 타입체크가 불완전하다. svg attribute prop을 넣어봤을 때의 비교: <a href="https://www.typescriptlang.org/play?#code/MYewdgzgLgBAgjAvDAFASiQPhgbxgJwFMoBXfMGAHgEswAHE2AQwBtqBzMAW0LCgCEmEQmzCFEAIgBGQkbUISYAemwBfIA">TS</a> <a href="https://rescript-lang.org/try?code=DYUwLgBAhhC8EG8IB4CWA7ADgV0lYqA5ugLYjpgBCUAziAeiLAEQBGt9GIzEA9AHwQAvkA">ReScript</a></li>
</ul></li>
<li>ReScript를 쓴다고 자동으로 type-safe 해지는 것은 아니다.<ul>
<li>당연한 이야기지만, 바인딩이 잘못되면 런타임 에러가 얼마든지 발생할 수 있다.</li>
<li><a href="https://rescript-lang.org/docs/manual/latest/interop-cheatsheet#dangerous-type-cast"><code>%identity</code></a> 같은 escape hatch가 존재하기에, 함수 구현을 어느정도 신경써야 한다. (<a href="https://green-labs.github.io/reasonml-ways-with-types">참고</a>)</li>
</ul></li>
<li>함수는 <a href="https://rescript-lang.org/docs/manual/latest/function#uncurried-function">기본적으로 currying이 되어있다</a>.<ul>
<li>함수를 일부만 apply해서 원하지 않는 결과를 얻는 실수를 할 수 있다.</li>
</ul></li>
</ul>
<h3 id="더불어">더불어</h3>
<ul>
<li>ReScript의 발전을 위해서 사내용 코드가 일부 가려진 실무 사용 사례 <a href="https://github.com/green-labs/sinsunhi-frontend-mirror">미러</a>가 공개되어 있으니 관심이 있으면 참고해봐도 좋을 듯하다.</li>
<li>실무 도입에 관심이 있다면, <a href="https://twitter.com/reasonseoul">Reason Seoul</a> 커뮤니티 디스코드에서 많은 도움을 받을 수 있다.</li>
<li>이 글은 완전히 검증된 내용이 아니기에 참고만 바라며, 글 내용의 수정이나 보완 의견은 댓글로 부탁 드립니다.</li>
</ul></div></div>

ReScript를 아마 실무에서 1년이상 써본 사람은 많지는 않을 것 같은데 (굳이 그 대상을 한국으로 한정짓지 않아도), 사실 제대로 된 블로그 글을 쓸만한 여유는 없고 그 경험을 메모처럼 적어본다.
ReScript에 관심이 있지만 실무에 도입할 만한지 고민하는 사람들이 있을 것이라고 생각한다. 특히 TypeScript 대비 큰 장점이 있는지, 도입에 문제가 될만한 부분이 있는지 궁금해할 것 같다. 입지가 잘 다져지지 않은 언어를 영업을 해야 하는 입장에선 보통 좋은 부분만 말할 수 밖에 없기도 하고, 실무로 사용해본 사람이 많지 않아 실무 도입의 단점이 잘 정리되어 있는 경우는 흔치 않을 것 같다. 그래서 간단하게 정리해 본다.
ReScript 실무 도입의 장점
TypeScript에 익숙한 사람이면 상당히 금방 배울 수 있다. 적절한 가이드만 있다면.
언어에 킬러 피쳐들이 많다. 패턴 매칭, Optional, if as expression, pipe, etc... 추론도 매우 강력해서 타입을 반복적으로 손으로 써줄 일이 거의 없다. 오히려 TypeScript 대비 초심자에게 더 적합.
생각보다 active하게 개발되고 있다. 개발진들이 (내 기준) 이슈에 매우 민첩하게 대응해주는 편이다. 커뮤니티도 어느정도 형성되어 있다.
ReScript 실무 도입 시 단점
당연하지만, 익숙해지는 데 시간이 좀 걸린다. 숙련된 개발자도 보통 적응기간이 1-2개월 정도 걸리는 것 같다. (함수형 언어에 대한 선행학습이 되어 있을 경우, 더 빨리 안착할 수 있다)
당장 가져다 쓸 수 있는 바인딩이 잘 없다. 바인딩을 직접 쓰는 데 많이 익숙해져야 한다.
대부분 바인딩은 굉장히 간단하지만, 일부 라이브러리들은 사고방식의 변화를 요구하기도 한다. (react-hook-form을 ReScript로 어떻게 바인딩할 것인가?)
(경우가 흔하진 않지만) 빌드툴이 타입을 emit해야 하는 경우 좀 더 스코프가 커질 수도: rescript-relay
돈의 맛이 느껴지는 TypeScript 개발 도구들을 쓰다 ReScript 세계로 오면 조금 부족함을 느낄 수 있다. 대부분의 경우는 괜찮지만, 시도때도 없이 나는 알 수 없는 VS Code 익스텐션 에러 등에 조금 지칠 수도
bonus: ReScript Gotchas
파일명의 제약이 있다.
Next.js 사용 시 file-based routing 이슈가 자연히 발생하는데, route를 위한 파일은 TypeScript로 작성하고 ReScript 파일명은 자유롭게 작성하여 export ... from ... 으로 가져오길 추천한다.
React 바인딩 / DOM API 등의 지원이 TypeScript 대비 불완전하다.
1-2개의 props만 다른 비슷한 React 컴포넌트에 대해 모든 prop들을 따로 타이핑을 해야 할 수도 있다.
DOM API가 typesafe하지 않은 이유를 찾아봤다: 글 링크
JSX 타입체크가 불완전하다. svg attribute prop을 넣어봤을 때의 비교: TS ReScript
ReScript를 쓴다고 자동으로 type-safe 해지는 것은 아니다.
당연한 이야기지만, 바인딩이 잘못되면 런타임 에러가 얼마든지 발생할 수 있다.
%identity 같은 escape hatch가 존재하기에, 함수 구현을 어느정도 신경써야 한다. (참고)
함수는 기본적으로 currying이 되어있다.
함수를 일부만 apply해서 원하지 않는 결과를 얻는 실수를 할 수 있다.
더불어
ReScript의 발전을 위해서 사내용 코드가 일부 가려진 실무 사용 사례 미러가 공개되어 있으니 관심이 있으면 참고해봐도 좋을 듯하다.
실무 도입에 관심이 있다면, Reason Seoul 커뮤니티 디스코드에서 많은 도움을 받을 수 있다.
이 글은 완전히 검증된 내용이 아니기에 참고만 바라며, 글 내용의 수정이나 보완 의견은 댓글로 부탁 드립니다.

웹 프론트엔드 ReScript 실무 사용에 대한 간단한 메모

댓글