우당탕탕 개발 로그
우당탕탕 클로드 코드 사용기 · 5화

AI가 다시 써준다면 스택을 갈아타도 될까 — 12일 동안 세 번 갈아탄 기록

12일 동안 백엔드를 Spring Boot에서 Go로, 모바일을 세 번 갈아타며 전환 비용이 정말 0인지 확인한 기록

하려던 것

프로젝트를 만든 지 나흘 됐는데 스택이 마음에 안 들었다. 백엔드는 Spring Boot로 시작했는데 컨테이너가 무겁고, 맥미니에서 여러 서비스를 동시에 띄우려니 메모리가 빠듯했다. 모바일은 Capacitor로 웹뷰를 감쌌는데 네이티브 느낌이 안 났다.

평소 같으면 참고 갔을 거다. 재작성이 며칠짜리 일이니까. 그런데 이번엔 다르게 생각했다.

“프론트 재작성은 네가 할 거잖아. 왜 1인 개발이 부담이라는 거지?”

AI가 코드를 다시 써준다면 스택 선택은 되돌릴 수 있는 결정이 된다. 그러면 처음부터 완벽하게 고를 이유가 없다. 이 가설을 12일 동안 실험했다.

어떻게 시켰나

백엔드 — 두 프로젝트를 같은 날 갈아탔다. 4/16에 공시 요약 서비스와 의정활동 트래커 둘 다 “Spring Boot → Go” 커밋이 찍혔다. 한쪽에서 전환 패턴이 잡히니 다른 쪽은 거의 복사 수준으로 따라갔다. 두 번째가 압도적으로 빨랐다는 게 이 실험에서 제일 분명한 소득이다.

모바일 — 세 번 갈아탔다. 4/15에 Capacitor에서 React Native로 넘어갔고, 4/24~26에 React Native에서 Flutter로 다시 넘어갔다. 12일 만에 세 번째 스택이다.

UI도 마찬가지였다. 의정활동 트래커의 지도 화면은 하루에만 십수 번 갈아엎었다. 실제 지리 → 카토그램 → 격자. 각각이 몇 시간짜리 작업이었으면 첫 번째에서 멈췄을 거다.

어디서 막혔나

전환 비용이 0은 아니었다.

코드를 다시 쓰는 건 확실히 빨랐다. 문제는 코드가 아닌 것들이었다. 빌드 설정, CI, 배포 파이프라인, 라이브러리 생태계 차이, 그리고 내가 그 스택을 모른다는 사실. Flutter로 넘어가니 위젯 트리를 읽는 법부터 다시 익혀야 했다. AI가 코드를 써줘도 리뷰는 내가 한다. 모르는 언어로 된 코드는 리뷰가 리뷰가 아니라 승인이 된다.

그리고 세 번째 전환은 두 번째만큼 명확한 이유가 없었다. React Native로 옮긴 건 Capacitor의 웹뷰 한계라는 분명한 이유가 있었는데, Flutter로 옮긴 건 “이게 더 나을 것 같아서”에 가까웠다. 재작성이 싸지니까 결정이 헐거워졌다.

어떻게 풀었나

지금 정리한 기준은 이렇다.

갈아타도 되는 경우 — 전환 이유를 한 문장으로 쓸 수 있고, 그 문장이 “지금 스택이 X를 못 한다”는 형태일 때. 백엔드 Go 전환이 여기 해당한다(메모리, 배포 단순성).

갈아타면 안 되는 경우 — 이유가 “더 나을 것 같아서”일 때. 세 번째 모바일 전환이 여기다.

그리고 같은 전환을 여러 프로젝트에 할 거면 몰아서 하는 게 훨씬 싸다. 백엔드 두 개를 같은 날 옮긴 게 우연히 잘한 짓이었다. 패턴이 살아 있을 때 두 번째를 하면 절반 값이다.

이 시기에 Codex를 붙여서 PR 리뷰를 자동으로 받게 한 것도 같은 맥락이다. 내가 모르는 스택의 코드를 승인만 하고 있는 상태를 조금이라도 줄여보려는 거였다.

배운 점