AI 시대를 맞아 어떻게 공부해야할까?
어떤 전문성이 요구되는지, 어떠한 능력이 가장 지금 시대에 가치있는지 감이 잡히지 않았습니다.
개발자를 고용하는 회사도, 개발자도 명확한 기준을 모르는건 마찬가지 일 것 같지만,
어쨋든 가만히 있으면 무조건 손해라는 생각은 들었습니다.
일단 뭐라도 만들어보자 라는 생각에
학습용으로 처음엔 단순히 크롬 리모트 데브툴을 만드는걸로 시작했습니다.
만들다가 보니 리엑트 네이티브도 리모트 디버거로 지원되게 만들어보자
-> 메트로를 몰라서 너무 햇갈린다.
-> 메트로 클론코딩 해보면서 공부해보자
-> 리엑트 네이티브에서 메트로보다 나은 번들러를 만들 수 없을까?
-> 롤다운, swc, bun읉 통해 이것저것 깔짝이며 메트로 번들러보다 나은 번들러를 만드려고 노력.
그나마 번, 롤다운이 가능성이 있었으나 이것저것 메인쪽 커스텀을 하거나 포크를 따는것에 한계를 느낌.
그렇다고 메트로 번들러와 완벽히 호환되는 웹 번들러가 없음 flow, hermes 엔진이 허용하는 자바스크립트 문법, 또 일반 웹과는 다르게 중요한 호출 순서 등..
아.. 그냥 어차피 공부인데 그냥 번들러도 만들어서 리엑트 네이티브 메트로를 대체해보자.
번들러를 만들다가 느낀점.
그럼 걍 웹도 지원하면 되는거 아냐?
롤다운에서 포기한 ES5도 넣자
RN을 실행해야하니 플로우 파서도 지원하자
wasm도 지원하자
속도도 bum, rolldown을 이겨보자
자체 hmr도 넣자
트리쉐이킹도 좀 더 공격적으로 해보자
minify도 다른 번들러에 비해 앞서보자
존재하는 번들러들을 벤치마크에서, 일단 인지한 기능은 다 이겨보자라는 생각으로 개발했습니다.
물론 많은곳에서 패배하고 있을 거라는 생각은 듭니다.
다른 번들러들에 비하면 안정성이나 기능, 지원하는 생태계 커뮤니티 등, 위에서 말한 tree-shaking이나 minify는 일부모듈에선 앞서지만 일부 모듈에선 뒤쳐지는 등 당연하게도 미완성인 부분이 많습니다.
다만 어느정도 실행 테스트 결과 일부 이기는 부분도 있고, 아직 할 일은(SSL, MCP, CLI, 안정화, API 문서 등) 많이 남았지만, 원래 목표였던 리엑트 네이티브 앱 빌드 및 동작은 상용 앱 3개를 릴리즈 빌드, 개발 빌드, 개발 서버 확인해본 결과 이상 없이 동작하는걸 확인해서 이쯤에서 공개를 하고 쭉 개발을 해도 되지 않나 싶은 생각에 글을 작성하게 되었습니다.
그래도 개발 및 번들 기능(zntc도 zntc로 빌드해서 배포 함)이 어느정도 잘 돌아가고,
필수 기능인 데코레이터나, 리엑트 네이티브에서 반필수 기능인 worklet, typescript, flow 등도 테스트한 라이브러리들은 이상 없이 잘 돌아가고,
vite, rspack용 플러그인도 제공하고, vite, rspack처럼 개발환경도 제공(RN, Web) 문서도 있고, 리액트 hmr도 있고, 모듈 페더레이션도 지원하고 등등
그래도 나름 번들러, 트랜스파일러의 기본 기능은 갖추었다고 생각해서 피드백도 받을겸 공개 후 계속 개발 하려고 합니다.
손으로 쓴 코드는 0이고 다 AI와 치열한 토론으로 개발되었습니다.
그 어떤 제품 개발 할때보다 AI를 갈군것 같네요.
클로드만 쓰다가 나중에 코덱스도 사용했습니다.
번들러 자체 개발기간은 약 3개월(약 3000개의 PR) 위에 말한 의식의 흐름까지 포함하면 한 6개월 정도 밤낮없이 작업하였습니다.
평일 휴일 쉼없이 작업하였고, 괜한 다른 번들러들과의 비교로 인한 자격지심? 의식때문에
test262 100% 등 다양한 테스트케이스를 통과하기 위해 테스트 케이스도 뇌절이라 할 만큼 많이 작성해서 개발했습니다.
많은 피드백 부탁드립니다 (__)
댓글과 토론
두서없이 글 쓰다가 빼먹었네요.
말씀주신 것처럼 Re.pack도 참고 많이 했습니다.
Re.pack, Rspack 둘 다 swc 기반이라서 flow를 네이티브로 지원하지 않는걸로 알고 있고,
Re.pack의 경우 버전 5부터는 Rspack이 베이스로 알고 있는데, 마찬가지로 Re.pack도 swc+babel을 쓰고 있어서, flow나 reaniamted, nativewind(zntc는 지원 예정) 등 인기 많은 플러그인이 여전히 바벨로 트랜스파일링 되는걸로 알고 있습니다
개인적으론 바벨에서 벗어나고 싶어서, zntc의 경우 기본적으로 지원하는 옵션으로 만들었습니다.
zntc도 바벨 호환성을 지원하긴 하지만, babel 의존성을 가능하면 제로로 만들고 싶었습니다.
안정성도 뛰어나고 검증 받은 코드들이지만, js라는 한계로 속도에선 항상 병목이여서요.
사실 개발하면서 계속 다른 번들러들과 벤치마크를 비교해가면서 봤고, 눈으로 계속 체감한 만큼 당연히 다른 번들러에 비해 기능이나 안정성, 확장성이 떨어지다보니 이부분은 계속 개선 해보려고 합니다.
다만, 주요 리액트 네이티브 라이브러리들의 파서 호환성 등 아예 내장이 되어있기 때문에 Re.pack에서는 어쩔 수 없이 발생하는 구조적 병목 구간쪽에서는 앞서고 있다고 생각하고 있습니다!