개발자/기술스택 도구6 모노레포 도입 후 실제 팀에 생긴 변화 개발자 현직자 솔직 경험담모노레포 도입 후실제 팀에 생긴 변화Turborepo로 전환한 지 6개월, 좋아진 것과 예상 못 한 문제들 Frontend Developer 2026년 6월 약 14분 읽기모노레포를 도입하기로 한 이유우리 팀 상황을 먼저 설명한다. 프론트엔드 개발자 셋이서 세 개의 Next.js 프로젝트를 유지하고 있었다. 사용자용 웹 서비스, 어드민 패널, 그리고 마케팅 랜딩페이지. 세 레포지토리가 따로 있었다.문제는 공통 컴포넌트였다. 버튼, 인풋, 모달 같은 UI 컴포넌트를 세 레포가 각자 갖고 있었다. 디자인 시스템 변경이 있으면 세 곳을 각각 고쳐야 했다. 색상 토큰 하나 바꾸는 데 PR이 세 개였다. ESLint 설정, TypeScript 설정, Prettier — 전부 따로따로 .. 2026. 7. 17. 상태 관리 라이브러리 바꾸면서 겪은 마이그레이션 고통 기술 마이그레이션 Redux → Zustand ⏱ 읽는 시간 약 10분Redux를 Zustand로 바꾸는 데3주가 걸린 이유"Zustand는 간단하잖아요" — 그 말이 얼마나 틀렸는지 마이그레이션 첫날 알았다회의는 30분이면 끝났다. "Redux 보일러플레이트가 너무 많고, Zustand가 더 가볍고 빠르니까 바꾸자." 팀원 모두 동의했다. 예상 기간은 1주일이었다.실제로는 3주가 걸렸다. 그 3주 동안 프로덕션 버그 2건이 났고, 팀원 한 명이 번아웃에 준하는 상태가 됐고(나였다), 스프린트 일정이 한 번 밀렸다."기술 스택을 바꾼다"는 말이 얼마나 가볍게 결정되고 얼마나 무겁게 실행되는지 — 이 글은 그 경험의 기록이다.1주일회의에서 나온예상 기간3주실제 마이그레이션소요 기간2건마이그레이션 중프로덕션.. 2026. 7. 10. Figma와 협업하면서 생긴 프론트엔드 개발자의 고충 Figma 협업 프론트엔드 고충 ⏱ 읽는 시간 약 9분"hover 색상은 느낌으로요"Figma 협업의 현실디자이너는 완성됐다고 했다. 개발자 입장에서 완성이 아닌 이유를 여섯 가지로 정리했다입사 초기에는 Figma가 신세계였다. 디자인 시안이 한눈에 보이고, 스펙 수치도 클릭 한 번이면 확인됐다. "이제 개발이 쉬워지겠다"는 생각을 했다. 그게 얼마나 순진한 생각이었는지는 첫 번째 기능 개발을 하면서 바로 알았다.Figma 파일을 열었다. 모바일 화면이 없었다. hover 상태가 없었다. 컴포넌트마다 간격 수치가 달랐다. 색상은 디자인 토큰이 아니라 전부 HEX 하드코딩이었다. 그리고 가장 인상적인 건 — 디자이너 슬랙 메시지: "나머지는 개발자분이 알아서요 😊"Figma 자체가 나쁜 게 아니다. 협업.. 2026. 7. 3. 내가 지금 쓰는 개발 도구 세팅 공개 - VSCode, 터미널, 맥 환경 개발 환경 세팅 공개 ⏱ 읽는 시간 약 10분VSCode, 터미널, 맥 환경, 그리고 일상 앱까지 — 이유 있는 세팅만 남기고 전부 쳐냈다개발 환경 세팅 글을 쓰고 싶다는 생각을 꽤 오래 했다. 근데 매번 미뤘다. "내 세팅이 정답은 아닌데"라는 생각 때문이었다. 그러다가 마음을 바꿨다. 정답이 아니니까 오히려 솔직하게 쓸 수 있겠다고.이 글에 있는 것들은 전부 "한 번 써봤다가 버렸거나", "지금도 매일 쓰는 것들"이다. 유명해서 쓰는 게 아니라 실제로 내 작업 속도를 올려줬기 때문에 남아있는 것들이다. Next.js 위주로 개발하는 프론트엔드 개발자 기준이라는 것도 미리 밝혀둔다.3년세팅을 갈아치운기간23개현재 설치된VSCode 익스텐션47개설치했다가지운 익스텐션macOS현재 메인개발 환경VSCode.. 2026. 6. 26. TypeScript 도입, 현실은 달랐다 처음 TypeScript 도입을 제안했을 때, 팀장님의 반응은 이랬다. "그거 배우는 데 얼마나 걸려? 우리 스프린트 일정 있잖아." 그리고 시니어 개발자 K님은 "자바스크립트가 뭐가 문제야, 우리 3년 동안 잘 썼는데"라며 미간을 찌푸리셨다. 2024년 초, 우리 팀의 TypeScript 도입기는 그렇게 시작됐다.결론부터 말하자면, 6개월 뒤 팀 전체가 TypeScript를 쓰고 있다. 그런데 그 과정이 기술 블로그에서 말하는 것처럼 "생산성 향상, 버그 감소, 팀 만족도 급등"의 해피엔딩이었냐고 물으면… 솔직히 그렇게 단순하지 않았다. 왜 TypeScript를 꺼냈나 — 진짜 이유공식적인 이유는 "코드 품질 개선"이었지만, 솔직한 이유는 따로 있었다. 우리 팀 Next.js 프로젝트에 버그가 너무 자.. 2026. 6. 19. Next.js 실무 도입 후 1년, 솔직하게 달라진 점들을 써봅니다 2026년 6월 | 개발자 현직 경험담 | Frontend 개발솔직히 말하면, Next.js를 처음 실무에 도입하자는 이야기가 나왔을 때 나는 그렇게 적극적이지 않았다. 당시 팀에서 쓰던 Create React App 기반 구조가 나름 익숙했고, "잘 돌아가는 걸 왜 바꾸지?" 하는 생각이 있었다. 그런데 SEO 이슈가 계속 발목을 잡았고, 결국 팀 전체가 Next.js로 전환하기로 결정했다.그게 2025년 초의 일이다. 지금은 1년 넘게 실무에서 써봤고, 기대했던 것도 있었고 예상 못 했던 것도 있었다. 좋은 점만 골라 쓰는 홍보글 말고, 진짜로 달라진 것들을 기록해두고 싶어서 이 글을 쓴다. 도입 전 우리 팀 상황팀은 프론트 3명 규모였고, 스택은 React + Vite였다. 백엔드 API는.. 2026. 6. 12. 이전 1 다음
