소개
신규 프로젝트를 시작할 때 가장 큰 고민은 기술 스택 선정입니다. 특히, 변화가 빠른 프론트엔드 기술 스택을 정할 때에는 신중 해질 수 밖에 없습니다.
공식문서를 읽고 해당 기술의 동작원리를 분석하고 만들어야 할 서비스에 적합한지 검증하는 것은 까다로운 작업입니다.
이번에는 LLM(Large Language Model)의 힘을 빌려 2시간 만에 신규 기술 스택의 동작원리를 파악하고 기술검증을 완료 했습니다.
제가 React Native(Expo) + Tamagui의 기술 검증을 어떻게 했는지 공유 드리겠습니다.
진행 방법
저는 아이디에이션을 목적으로 텍스트 편집을 할 때 Obsidian 문서 폴더를 Cursor로 열어 사용합니다.
장점은 다음과 같습니다.
1. 다양한 LLM 모델 이용
2. 개발자 친화적
3. composer로 문서 즉-시 생성
제가 기술 검증하려고 했던 라이브러리는 expo와 tamagui 였습니다.
저는 react-native-cli로 react-native 개발을 해본적은 있지만, expo로 개발을 해본적은 없었습니다.
expo가 이전에 비해 안정적으로 바뀌었고 지원하지 않았던 기능들을 많이 제공한다는 것을 얼핏 알고 있었습니다.
또한 react-native 공식문서에서도 Get Started에서도 expo를 추천하고 있기 때문에 expo를 도입해볼까?라는 생각이 들었습니다.
react-native에 사용하기 좋은 UI kit이 필요했고 tamagui라는 재밌어 보이는 UI kit을 발견했습니다.
본격적인 기술 검증에 들어갔습니다. 기술 스택 검증에 대한 추론이 필요하다고 생각이 되어서 o3-mini 모델을 사용했습니다.
쉽게 이해하기 위해 표, mermaid, 타입스크립트 코드를 적극적으로 활용해서 결과를 만들어달라고 했고, 몇초만에 기본적인 내용을 정리해줬습니다.
내용을 읽으면서 배포 방식에 대해 궁금해 졌습니다. 설명해준 OTA를 통해 지원이 종료되는 codePush(앱 스토에 출시를 하지 않고 JS번들을 교체해서 앱을 업데이트 하는 도구)를 대체할 수 있겠다는 생각이 들었습니다.
그렇군...!
또 다른 궁금증도 있었습니다. expo 코드 작성 시 react-native-cli와 다른 점은 무엇인지 알고 싶었습니다.
네이티브 코드 접근, 라우팅 방식 등에 대한 차이를 알려줬습니다.
이외에도, 'tamagui 초기 세팅 방법과 스타일링 예시', 'tamagui가 성능적으로 우수한 이유', 'OTA 비용' 등, Q&A를 계속 했습니다.
결론적으로, 다음과 같은 결론을 얻게 되었습니다.
1. **적용 가능성:**
- 대부분의 일반적인 프로젝트에 적합
- 빠른 개발과 프로토타이핑이 중요한 경우 특히 유용
2. **리스크 관리:**
- 초기 설정에 충분한 시간 투자 필요
- 성능 최적화 전략 수립 필요
- 팀 학습 곡선 고려
3. **권장 사항:**
- 프로젝트 초기에 충분한 PoC 진행
- 점진적인 도입 전략 수립
- 지속적인 성능 모니터링
그리고... 고난은 있겠지만 충분히 도전해볼 수 있겠다는 생각이 들었습니다.
결과와 배운 점
LLM으로 빠르게 기술에대한 철학과 동작원리를 파악할 수 있습니다.
AI와 지속적인 Q&A를 통해 궁금한 점을 점진적으로 해결 할 수 있습니다.
Obsidian + Cursor로 빠르게 문서를 작성하고 관리 할 수 있습니다.
해보면서 느낀점은 라이브러리 사용에 대한 기술 블로그 작성에도 굉장히 유리하겠다는것도 알게 되었습니다.
Obsidian + Cursor 조합으로 만들 수 있는 문서에대한 아이디어를 댓글로 함께 공유하면 좋을 것 같습니다.