개발을 모른 채 하는 리팩토링
목차
-
- 프로젝트 이관을 시작한 배경
- 현재의 아키텍처
- 잠깐! 리팩토링 하기 전에
- 리팩토링을 하면서
- 리팩토링의 완료
- 배운 것
프로젝트 이관을 시작한 배경
RGBlog는 초기에 lovable로 만든 개인 블로그 프로젝트입니다. 그러나 개인 블로그 목적이자, 제가 생각하는 방식을 AI에게 학습시키려고 한 목적이라서 NotebookLM에 웹사이트를 읽게끔 하려 했는데 계속 실패하더군요. 원인은 Framework에 있었습니다. React+Vite 구조로 Lovable은 클라이언트 언어를 사용하는데, 그 이유는 Mini app prototype을 목적으로 하는 사용자가 주 타겟층이기 때문입니다. 그래서 React의 장점은 동적인 화면 전환이나 App과 같은 스무스한 동작에는 용이하지만 SEO가 되지 않는 문제가 있었어요. (AI에게 물어보니 Single Page Application(SPA) 구조는 NotebookLM의 크롤러가 자바스크립트를 실행한 후의 최종 콘텐츠를 기다리지 못하고 빈 페이지로 인식한다고 합니다.)
그래서 결국은, SEO/AEO를 위해서 & 장기적으로 이 블로그를 제가 사용할 것이므로 프레임워크 리팩토링을 하기로 결심합니다. 근데 저는 개발 언어를 하나도 몰라요! 그래서 Antigravity를 켰습니다. (아직 Claude Max를 결제하진 못했습니다..) 그러나 불안감을 줄이기 위해 현재의 아키텍처를 먼저 이해하고, 그 다음 리팩토링을 시도하기로 합니다.
현재의 아키텍처
현재의 아키텍처는 상당히 간단한 구조로 이뤄져 있습니다. React Query -- Supabase -- React+Vite 구조입니다. 이를 Next.js로 바꾸면 어떤 게 같이 바뀔지 알기 위해 Gemini와 몇 가지 질문을 합니다. 데이터 구조와 UI 디자인은 유지되지만 라우팅 구조나 데이터 페칭만 바뀐다고 합니다. 바뀌어야 할 백단 로직만 바뀌므로 진행에 망설임이 덜어졌습니다. 진행을 하다보니 몇 가지 질문도 추가로 했었는데요. 가령, Lovable은 Supabase와의 연동과 Hosting 등 알아서 해주기 때문에 제가 다른 툴을 쓸 필요가 없었으나 도메인 독립을 하면 DB 관리를 하거나 배포하는 툴을 별도로 써야 하지 않을까? 싶었습니다. 그 부분도 질문하니 Vercel + Cloudflare + Supabase 라는 초심자에게 적합한 조합이 있더라구요. 이를 그대로 따르기로 합니다.
잠깐! 리팩토링 하기 전에
현재의 아키텍처 구조를 물어보면서, 비개발자도 알기 쉬운 수준으로 설명해달라고 했습니다. 제품 구조를 "건물 설계"에 비유한 점이 마음에 듭니다. 골조는 React & Vite이고, 인테리어를 Tailwind CSS & Shaden UI (Lovable의 통일성 있는 UI의 비결)로 하며, 페이지 구조는 방 구조에 맞게 설명해줍니다. Supabase가 관리소이고 이를 React Query로 캐싱해서 가져온다는 점도 잘 설명해주네요.
저는 CRUD의 동작방식도 궁금해서 해당도 비개발자가 알아 듣기 쉽게 설명해달라고 합니다. 레스토랑에 비교해서, 주방에서 어떻게 재료를 왔다갔다 하며 가져오는지 잘 설명해주더라구요. 현재의 아키텍처를 더 이해하기 쉬워졌습니다.
마지막으로, Next.js와 React의 차이점을 저는 잘 몰랐기 때문에 이도 설명해달라고 합니다. Next.js는 Server side로 관리하고 그 언어가 가진 규칙이 있어 번거로울 수 있지만 전반적으로 SEO와 기능 측면에서 좋네요. 이제 확신이 생겼으므로 리팩토링 작업을 시작하기로 합니다.
리팩토링을 하면서
저는 이 작업에서 리뷰와 승인만 했습니다. 처음에는 각 리뷰 단계를 모두 이해해보려 했으나 어느 순간 Task 수행 속도가 너무 빨라서 다 리뷰가 할 수 없을 정도였어요. 그럼 이제 드는 의문이 있습니다.
AI가 알아서 다 하는데, 이 목표 수행에 있어서 내가 병목 아닐까?
저는 각 태스크를 Approve 하는 역할만 하는데, 이 마저도 제가 책을 읽고 있을 때는 중단되고 있으므로 제가 병목이라는 생각이 들었습니다. 승인자로써의 제가 병목이라고 느껴질 정도로 섬뜩한 발전입니다.
그러나 한 가지 중대한 버그가 발견되었습니다. admin 페이지에서 동적 요소의 pre-rendering이 안되어서 한 시간 넘게 헤매고 있더군요. 옵션 A/B/C/D를 추천해줬고 각각의 장/단점도 알려줬습니다. 그러나 저는 각 옵션이 무엇인지도 모르고, 그게 근본 원인을 해결하는 방법인지도 모르겠습니다. 그래서 Gemini에게 교차 검증을 시도하기로 합니다. 비개발자도 알아 듣기 쉽게 이 버그를 설명해달라고 합니다.
상황 재구성: "설계도와 자재가 서로 맞지 않습니다"
지금 발생한 문제는 특정 코드 한 줄의 실수가 아니라, 프레임워크(Next.js)라는 집의 뼈대와 리액트(React)라는 건축 자재가 서로 호환되지 않아 집을 지을 수 없는 상태입니다.
이제야 이해가 가네요. 버전을 다운그레이드 하거나, 어드민 페이지를 아예 별도 관리해야 한다고 합니다. 어드민 페이지를 별도로 관리할 정도로 복잡한 기능을 요구하는 제품이 아니기 때문에, 버전 다운그레이드를 해서 충돌을 줄여보기로 합니다. 중간에 Claude Sonnet 모델로 바꿔봐도 문제해결력에 별 차이점을 못 느낍니다 (화법은 개발자 친화적이라 좋았습니다). 그래서 교차 검증을 해보기로 합니다. Gemini에게 개발자가 버그 픽스에 어려움을 겪고 있는데 예상되는 원인을 알려달라 합니다. Gemini는 이 질문을 해보라고 합니다.
"정적 요소를 억지로 만들고 있는 Client rendering 구조가 있는지 알아봐줄래요?"
저는 모델 간 의견을 왔다갔다 하는 역할만 했습니다. 그래서 솔직히 사람이 왜 필요한지 더 모르겠습니다. 그 이후에도 버그를 픽스하고, 스스로 검증하고, 저는 완료할 때까지 승인만 했습니다. 물론 너무 많은 시간이 걸리고, 모델의 rate limit이 걸려서 모델을 Gemini flash로 다운그레이드 하기도 했지만 완료될 때까지의 단순 반복 작업이기에 저는 더 이상 관여할 게 없었습니다.
리팩토링의 완료
마이그레이션이 완료되고 Walkthrough라는 작업 리뷰 파일을 제게 보여줍니다. 본인이 Chrome Agentic Browsing으로 테스트를 완료한 것까지 보여줍니다. 저는 소름이 돋습니다. 요구사항만 정확하게 주면 구현과 QA, 버그픽스도 알아서 하는 시대가 제가 지금 살고 있는 시대라는 걸 실감합니다.
소름돋는 시간이기도 했지만, 리팩토링도 이제 AI와 함께 직접 할 수 있다는 사실이 낙관적으로 느껴지기도 합니다. 저는 여러 mini app의 바이브코딩을 하면서 AI가 스스로의 버그에서 벗어나지 못하고 계속 끝맺음을 맺지 못한 채 미니앱들이 버려졌습니다. 그러나 이번에는 CRUD가 가능하고 Admin과 사용자향 페이지가 있는 이 기능에 대한 프레임워크 변경을 하루가 되지 않아서 했기 때문입니다. 또 한편으로는 이 가능성이 참 눈부시면서도, 섬뜩하네요.
배운 것
- 웬만한 건 AI와 함께라면 다 된다.
- AI끼리 검증하면 시너지가 더 강하다. 사람의 집단지성이 문제를 더 잘 해결하듯이.
- 단, AI는 오버 엔지니어링을 할 가능성이 높다. 언어만 바꿨는데 코드의 줄 수가 3배 이상 늘어났다.
- 비즈니스 가설 검증: 이 기능이 의도한 비즈니스 요구사항을 충족하는가? 사용하고 피드백한다.
- Edge Case 지시: " 보안 측면에서 취약점은 없는지 다시 한번 Self-critique 해줘"라고 명령한다.
- 확장성 질문: "지금은 기능이 하나지만, 나중에 +@ 기능을 추가하라면 지금 아키텍처를 다 뜯어고쳐야 하니?"라고 물어본다.
- 코드 주석 요청: "1년 후에도 내가 코드를 이해할 수 있도록, 코드블록별 주석을 달아줘."
AI간 검증이 효과적임을 확인했으므로, 다음에는 Multi-agent를 한번 해보려고 합니다. Agent간 기획자<>개발자 역할을 하게 하거나, 아니면 QA <> 개발자 역할을 하게끔 하면 저라는 병목이 오히려 사라질 것 같달까요..? ㅎㅎ ㅜㅜ