chore(devlog): vibe-coding article

Author: johnny-mh

apps/devlog/package.json

@@ -22,7 +22,7 @@
     "@microflash/rehype-figure": "^2.1.0",
     "@shikijs/transformers": "^1.10.0",
     "@tailwindcss/typography": "^0.5.13",
-    "astro": "^5.1.1",
+    "astro": "^5.5.5",
     "astro-fuse": "workspace:*",
     "astro-icon": "^1.1.0",
     "astro-robots-txt": "^0.4.0",

apps/devlog/src/assets/postImages/20241231/cover.webp

@@ -0,0 +1,52 @@
+---
+title: Vibe Coding
+description: Vibe Coding에 대한 13년차 프론트엔드 개발자의 생각
+cover: '../../assets/postImages/20250331/pexels-googledeepmind-17483848.jpg'
+coverAlt: Image from Google DeepMind
+categories: [Development]
+tags:
+  - Frontend
+  - Development
+  - AI
+  - Vibe Coding
+publishedAt: 2025-03-31T20:32+09:00
+---
+
+얼마 전부터 AI를 활용한 개발을 **Vibe Coding**이라 부르기 시작했다. 단어가 적절한 듯 하면서도,
+무언가 불필요하게 포장된 느낌이라 입에 딱 붙지는 않는다. 업무상으로는 아예 다르게 표현하고 싶을 정도...
+
+2024년 중순부터 내가 속한 조직에서도 copilot을 시작으로 cursor 등의 AI를 보안 검토 후 사용할 수 있게 되었다.
+하지만 개인, 조직별로 실제 실무에서 적극적으로 활용하는 사례는 찾아보기 어려운 듯 하다.
+
+개발자 커뮤니티, YouTube등 AI를 활용한 개발 대해 검색해 보면. 효율에 대해서는 좀 의견이 갈린다.
+실제로 과거에 함께 일했던 분들의 이야기를 들어보았을 때는 부정적인 쪽으로 기울어있는 느낌이다.
+
+실효성이 떨어진다는 의견의 이유를 대략 정리하자면 "답변의 품질이 떨어진다.", "업무 프로세스 상 번거롭다." 였다.
+
+## 생각 외로 높은 진입장벽
+
+AI로 효율적으로 사용하는 것이 생각보다 만만하지 않다. 그나마 IDE에 붙어 다양한 정보를 주고받게 되어
+단순 채팅만 가능했던 이전보다 쓰기는 훨씬 편해졌지만, 그것만으로 실무에서 큰 도움이나 성과를 만들기엔 무리가 있다.
+
+효과를 보려면 의외로 개발자의 역량이 중요하다. 일을 시키는것도 아는 사람이 시킬수 있고. AI모델의 답변을 다듬는데에도 역량이 필요하다.
+
+또한 업무 프로세스도 이에 맞춰 변경해야 한다. 단순히 지금 필요한 알고리즘을 짜는 것이 아니라, 업무 시작 전.
+AI로 효율을 볼 수 있는 작업과 직접 하는게 더 효율적인 작업을 현실감있게 구분한다. AI에 대한 지식이 필요한 부분이다.
+
+업무 환경도 중요하다. 협업 부서와의 R&R정리라던가, AI사용에 대해 편견이 없는 분위기인지 등등 생각보다 이 부분도 쉽지 않다.
+
+그 동안 대부분의 개발자가 행해 왔던 업무 패턴도 걸림돌이 될 수 있다. 이를테면 자체 구축한 디자인 시스템을 AI가 알 수 있나?
+당연 방법은 있지만 AI활용에 대한 지식이 필요하다.
+
+## 앞으로의 Vibe Coding
+
+앞서 언급한 내용들로 인해. 현실적으로 소, 중규모의 시스템이 갖춰지지 않은 곳에서 먼저 적극적으로 활용할 듯 하다.
+다만 대기업들이 copilot이나 cursor 등 보안에 민감한데도 도입하는 것을 보면 중요성을 알게 되는 순간 금방 따라잡긴 할 것이다.
+
+과거 2010년 중반만 해도 Virtual Scroll, Web Based Editable Grid 들은 어느정도 FE에 투자할 수 있는 의지나 규모가 있는 회사들의
+전유물이었다. 그런데 지금은 AI모델 하나에 스크린샷만 보여주면 눈 깜짝할새에 구현해주는것은 물론이며 SSR도 완벽하다.
+
+그리고 AI는 정말 빠르게 새로운 기술이 나오고 있다. 지금도 그렇지만 23년만 해도 AI에 관련된 **논문**이 쉴 새 없이 쏟아져 나왔는데.
+이제는 개발자가 실제로 적용할만한 **기능**으로 쏟아져 나오고 있다.
+
+당연히 FE개발 역량은 똑같이 쌓아야 하며, AI에 대한 트렌드도 적극적으로 따라가야 한다. 대기업이 허튼데 돈 쓰는것 본 적이 없다.

apps/devlog/src/assets/postImages/20250331/pexels-googledeepmind-17483848.jpg

@@ -0,0 +1,54 @@
+---
+title: 프론트엔드 조직 구성의 새로운 방향
+description: Module Federation과 preload를 활용하여 프론트엔드 조직 구성의 새로운 선택지에 대해 다룹니다.
+cover: '../../assets/postImages/20241231/cover.webp'
+categories: [Development]
+tags:
+  - Frontend
+  - Development
+  - Development Organization
+publishedAt: 2024-12-31T20:32+09:00
+draft: true
+---
+
+Module Federation은 웹 앱의 중앙 집중적 구조에서 발생하는 여러 문제들을 해결할 수 있는 구조 패턴이다. [webpack 5 버전의 릴리즈](https://webpack.js.org/blog/2020-10-10-webpack-5-release/?utm_source=chatgpt.com#module-federation)에 플러그인으로 새롭게 추가되었으며. 현재는 vite, rsbuild등 다양한 번들러도 지원하며 [Module Federation](https://module-federation.io/)이라는 별도의 브랜드 사이트로 제공되고 있다.
+
+사실 Module Federation이던 Micro Frontend던 내용을 찾아보면 기술에 대해서는 이미 많은 글이 게시되어 있다. 이 글에서는 Module Federation의 기능적인 부분을 다루기 보다는. Module Federation을 사용하면 가능한 새로운 조직 형태에 대한 생각을 정리하려고 한다.
+
+관리하는 웹 앱의 규모와 갯수가 늘면 모듈 중복 등 여러 문제들이 생겨나며 점차 개발 속도에 발목을 잡기 시작한다. 조직 규모가 적당하다면 이 시기에 여러 그룹으로 쪼개어 조직원들을 재배치한다. 조직 규모가 작다면 그롭 대신 조직원들에게 다른 역할을 할당한다.
+
+이때. 이름은 다를지 몰라도 보통 다음에 설명할 **공통 조직**과 **서비스 조직**으로 그룹을 나눈다.
+
+## 공통 조직과 서비스 조직
+
+**공통 조직**은 캐러셀, 테이블 컴포넌트와 같이 앱에 보여지며 여러군데에서 똑같이 쓰이는 모듈. 복잡한 히스토리를 가진 웹뷰 브릿지를 쉽게 쓸 수 있게 해 주는 유틸 함수. 구축된 인프라를 활용해 앱을 배포하거나 롤백할 수 있게 해 주는 CLI 등 여러 서비스가 공통으로 사용하는 모듈들을 관리한다.
+
+또 필요하다면 개발한 기능들을 서비스에 적용하는 데 도움을 주기도 하고. 바쁘다 보니 놓칠 수 있는 성능 최적화 측면에서도 리포트를 제공하기도 한다.
+
+서비스 조직의 리소스를 서비스 개발에 온전히 투입할 수 있도록 돕는 역할을 한다.
+
+**서비스 조직**은 회사가 운영하는 서비스의 개발과 유지보수를 직접적으로 담당한다. 그들이 속한 개발팀의 배포 주기 때문이라던가. 회사의 방향성에 따라 한 사람이 같은 기간에 두 개 이상의 개발을 하기도 하며. 하나의 리포지토리에서 여러 기획/개발이 병렬로 여러 페이지들을 개발하기도 한다.
+
+보통 회사에서 프론트엔드 조직의 존재 의미와 직결되는 조직이기 때문에 중요하면서도 매우 바쁘기도 하다.
+
+---
+
+이러한 조직 구성의 효율은 각 조직이 얼만큼 적극적으로 임하는지에 따라 극명하게 갈린다.
+
+**공통 조직**은 서비스 조직이 고객이라는 생각으로. 업무에 관심을 기울여 병목을 찾아 개선해야 하고. 협조가 필요하다면 충분한 설명과 타당한 근거를 준비해야 한다.
+
+**서비스 조직**은 서비스 개발이 최 우선이다. 다만 장기적인 관점에서 개발에 병목이 되는 부분을 찾아내어 공통 조직이 개선할 수 있도록 도움을 주어야 한다.
+
+## 공통/서비스 조직 운영의 한계점
+
+각 조직의 역할이 잘 지켜진다면 업무 효율은 꽤 괜찮은 편이다. 하지만 이런 구성은 시간이 흐르면 변질될 가능성이 높다.
+
+서비스 조직은 점점 더 페이지 개발에만 열중하고 그 외의 다른 디테일에 대해서는 경험을 쌓을 기회가 없거나 아예 모르게 된다. 심지어 지금 하고 있는 일이 비 효율이라는 것도 구별하기 어려워지기도 한다.
+
+공통 조직은 점점 불필요한 리소스를 들이기도 하고. 도입하는 게 오히려 비효율이라 느껴지는 모듈들을 만들기도 한다. 서비스 조직 입장에서 현실적으로 공감되지 않는 방향으로 업무를 진행하게 될 수 있다.
+
+업무 효율을 위해 나눴던 그룹이 결국 서로의 업무를 전혀 모르는 다른 분야로 구분되어 버렸다.
+
+이 상태라도 회사의 비즈니스 요구사항을 만족하는데에는 별 문제가 없다. 다만
+
+## Module Federation을 활용한 조직 구성

apps/devlog/src/data/post/Vibe-Coding.mdx

@@ -107,7 +107,7 @@ const img = await getPostImage(post)
     }
 
     <div
-      class="_blog_content container prose prose-stone mb-20 max-w-none px-1 dark:prose-invert prose-headings:font-semibold prose-h1:mt-20 prose-a:relative prose-a:no-underline prose-a:after:absolute prose-a:after:bottom-0 prose-a:after:left-0 prose-a:after:right-0 prose-a:after:h-[1px] prose-a:after:bg-th-text/80 prose-a:after:content-['']"
+      class="_blog_content container prose prose-stone mb-20 max-w-none break-keep px-1 dark:prose-invert prose-headings:font-semibold prose-h1:mt-20 prose-a:relative prose-a:no-underline prose-a:after:absolute prose-a:after:bottom-0 prose-a:after:left-0 prose-a:after:right-0 prose-a:after:h-[1px] prose-a:after:bg-th-text/80 prose-a:after:content-['']"
     >
       <Content />
     </div>