점진적으로 갈 수밖에 없다고 믿었던 일이, 주말 사흘 만에 끝났다

나는 내 속도를 기준으로 일정을 가늠했다. 그런데 그 기준이 통째로 무색해지는 경험을 최근에 했다. 적어도 한두 달은 잡아야 한다고 믿었던 마이그레이션이, 주말 사흘 만에 80% 넘게 끝나 있었다. "점진적으로 전환하자"던 계획은 무의미해졌다. 즉시 전환이 가능한 일이 되어 있었으니까.

AI가 '보조'였던 시절

얼마 전까지 나에게 AI는 옆에서 거드는 도구였다. nugu의 상품 상세 페이지(PDP)와 주문 화면을 리팩터링할 때가 그랬다. Cursor를 켜놓고, 내가 운전대를 잡은 채 자동완성과 부분 제안을 받아가며 작업했다. 컴포넌트 트리를 쪼개고, 얽혀 있던 상태 로직을 훅으로 빼내고, 클라이언트에서 줄줄이 일어나던 데이터 요청을 서버 쪽으로 끌어올리는 일이었다.

지난 한 해 동안 적응하며 다듬어 온 방식이었고 나쁘지 않았다. AI를 안 쓰던 때보다 분명 빨랐다. 하지만 본질적으로는 내가 한 줄 한 줄 검토하며 동기적으로 진행하는 작업이었다. 제안을 받아들일지 말지, 어떤 문장을 덜어낼지, 코드를 어떻게 고칠지는 전부 내가 직접 골랐다. 결국 일의 총량과 속도는 내 처리 능력에 묶여 있었다. 그렇게 PDP와 주문 화면 리팩터링에 체감상 2주 정도가 들었다. AI는 거들 뿐, 운전대는 내가 잡는다고 믿었다.

점진적 전환을 준비했었다

nugu 곳곳에 인라인 스타일, styled-jsx, 부트스트랩 유틸 클래스, SCSS가 세대별로 켜켜이 쌓여 있었고, 이걸 Tailwind 유틸리티 클래스로 통일해야 했다. 한 줄 한 줄 손보면 되는, 익숙한 종류의 작업이었다. 다만 양이 문제였다. 수십 개 파일에 걸친, 지루하고 손이 많이 가는 일이라 끝이 어디인지 쉽게 가늠되지 않았다.

게다가 이 작업만 붙잡고 있을 수 없었다. 그러니 "점진적 전환"은 더 나은 선택이라서가 아니라, 사실상 유일한 선택지였다. 한 번에 끝낼 시간이 없으니 화면 하나씩, 컴포넌트 하나씩, 몇 달에 걸쳐 조금씩 교체할 수밖에 없었다. 그래도 가늠은 해봐야 했기에 내 2주짜리 PDP 리팩터링 작업을 기준으로 계산하니 적어도 1~3개월은 걸릴 것 같았다. 그게 합리적인 추정이라 생각했다.

몇 달에 걸쳐 천천히 작업할 수 있었던 건, 그 전에 FE팀 혜빈님이 점진적 전환의 토대를 미리 설계해두셨기 때문이다. 부트스트랩과 Tailwind를 한 페이지 안에 공존시키되, 전환한 영역에서는 Tailwind가 안정적으로 이기게 만드는 방식이었다. 마침 혜빈님이 길게 휴가를 떠난 참이었고, 그 사이 내게 여유가 생겨 그 작업을 이어받았다.

간단히 말하면 화면 하나를 고르고, 그 안의 부트스트랩 유틸리티와 SCSS, styled-jsx를 Tailwind로 옮기고, 필요한 예외를 표시하고, 완료한 항목을 체크하는 식이었다.

핵심은 "한 번에 다 바꾸지 않아도 깨지지 않는 상태"를 만드는 것이었다. 부트스트랩 리셋 CSS와 Tailwind preflight는 같은 HTML 요소의 기본 스타일을 건드렸다. 그냥 섞어두면 어느 쪽 스타일이 이길지 화면마다 달라질 수 있었다. 그래서 use-bootstrap, use-tw, reuse-bs 같은 스코프 class로 영역을 나눴다. Tailwind로 옮긴 영역에서는 부트스트랩 초기화와 유틸리티를 걷어내고, 아직 부트스트랩 스타일이 필요한 요소만 reuse-bs로 예외 처리했다.

그다음에는 이 방식을 반복 가능한 작업으로 만들었다. 레거시 리셋 스타일은 낮은 우선순위 레이어에 두고, Tailwind 유틸리티가 그 위에서 이기도록 정리했다. 페이지별로 부트스트랩 초기화 CSS를 켜고 끌 수 있게 해, 전환이 끝난 화면부터 하나씩 부트스트랩 의존도를 낮출 수 있었다. 여기에 tw: 프리픽스, cn() 사용, 클래스 변환 기준을 문서화한 마이그레이션 규칙과 MIGRATION.md 체크리스트를 붙였다. 어디를 바꿨고 어디가 남았는지 추적할 수 있었다.

"어디까지 하나 보자"로 시작한 주말

거창한 계획은 없었다. 랄프 루프를 알게 돼 Claude에게 맡기면 일을 얼마나, 어디까지 해내는지 보고 싶었다. 마침 준비해 둔 검증 도구가 있었다. 핵심 구매 퍼널을 지키는 E2E 테스트와, 레이아웃이 깨지지 않았는지 보는 이미지 리그레션 테스트였다. 그래서 퇴근 후 금요일 저녁에, POC 삼아 던져봤다. "Tailwind로 옮겨봐".

그날 밤부터 주말 내내, 내가 한 일이라곤 노트북을 충전기에 꽂아 둔 채 간간이 "아직 돌고 있나" 들여다보는 게 전부였다. 그리고 그때마다 Claude는 멈추지 않고 계속 일을 하고 있었다.

어, 이게 되네?

사흘이 지나 출근 준비를 하며 확인해 보니 nugu의 거의 모든 파일이 일관되게 Tailwind로 넘어가 있었다. 정적 스타일을 걷어내며 코드는 8,784 줄이 추가되고 29,628 줄이 제거돼 있었다. 한두 달을 잡았던 일의 80%가 주말 사흘 만에 끝나 있었다.

가볍게 "어디까지 하나 보자"고 던진 POC였는데, '어… 이게 되네?' 그 어이없는 한마디가 aha 모먼트였다. 점진적으로만 가능하다고 믿었던 전환이, 즉시 끝낼 수 있는 일이 되어 있었다.

물론 AI가 똑똑해서 된 일이라고만 생각하지는 않는다. 결과를 일일이 검토하지 않아도 되게 해준 검증 도구가 없었다면 이 속도와 결과는 나오지 않았을 것이다. Cursor로 일할 때 내 병목은 늘 "매 변경을 내가 눈으로 확인해야 한다"는 데 있었으니까. 검증을 자동화해 두니 AI는 내 검토 속도라는 족쇄에서 풀려났다.

그래도 마지막 20%가 진짜 일이다

들뜸은 오래가지 않았다. 80%에서 멈춘 나머지를 직접 손보기 시작하니, 누락된 부분과 그동안 가려져 있던 기존 이슈들이 줄줄이 나왔다. 이걸 정리하는 데 또 며칠이 걸렸다.

함께 일했던 현철님의 말이 떠올랐다. "80%까지는 어느 정도 개발 잘하는 사람이라면 구현하기 쉬워요. 어려운 건 그 위로 끌어올리는 거죠." 딱 그 말대로였다. AI는 0에서 80%까지를 경이로운 속도로 메워줬지만, 거기서부터 완성도를 끌어올리는 구간은 여전히 내 몫이었다.

그래서 지금 내 고민은 "AI가 일을 다 해주나?"가 아니다. '남은 20%를, 어떤 작업 방식으로 어떻게 끌어올릴 것인가'다. 검증 루프를 더 촘촘하게 만들면 그 경계를 더 밀어올릴 수 있을까. 아니면 이 마지막 구간은 본질적으로 사람이 가져갈 영역으로 남을까.

받아들이고, 적응한다

분명한 건 하나다. 일하는 방식의 패러다임이 바뀌었다. 내 처리 속도를 기준으로 일정을 잡던 방식, AI를 보조로만 둘 수 있다고 믿던 전제는 이제 유효하지 않다. 한 줄씩 직접 손보는 건 여전히 내 방식이지만, 그게 유일한 길은 아니라는 걸 알게 됐다. 1~3개월짜리라고 믿었던 일이 사흘로 줄어드는 걸 직접 봤으니, 이전 기준으로 돌아갈 수는 없다.

솔직히 두렵다. 속도를 눈으로 확인한 이상, 내 자리는 어떻게 되는 건지 두렵지 않다면 거짓말이다. 하지만 두려움과는 별개로, 변화는 이미 일어났다. 이미 바뀐 것을 안 바뀐 척할 수는 없으니, 두려워도 적응하는 수밖에 없다. 그러니 내가 할 일은 "AI에게 뺏긴다"고 움츠러드는 게 아니라, AI가 주도할 판을 잘 깔고, 마지막 완성도를 책임지는 사람으로 빠르게 옮겨 타는 것이란 생각이 든다. 다음 마이그레이션은 더 이상 몇 달을 잡지 않을 것이다. 대신 검증 루프를 어떻게 짤지, 그리고 마지막 20%를 어떻게 메울지부터 고민할 것이다.