코딩 에이전트와 복잡성 예산

https://leerob.com/agents

저는 cursor.com을 CMS에서 순수 코드와 Markdown으로 마이그레이션했습니다. 몇 주가 걸릴 것으로 예상했지만 사흘 만에 마이그레이션을 완료했고 토큰 비용은 $260이었으며 수백 개의 에이전트를 활용했습니다.

콘텐츠는 곧 코드입니다

Cursor의 Roman과 Eric과 점심을 먹으며 cursor.com 웹사이트에 대해 이야기를 나누기 시작했습니다. 최근에 리디자인을 출시했는데, 그 변화의 일부로 모든 콘텐츠와 웹페이지가 이제 헤드리스 CMS를 통해 구축되었습니다.

테이블을 돌며 불편한 점을 공유했습니다. CMS가 원활히 작동하지 않았습니다. 아름다운 새로운 웹사이트 디자인을 갖추었음에도 새로운 콘텐츠를 배포하는 일이 그 어느 때보다 어려워진 듯했습니다.

이전에는 @cursor⁠에게 코드와 콘텐츠 수정을 요청할 수 있었지만, 이제 그 사이에 새로운 CMS 추상화가 도입되었습니다. 모든 것이 조금 더 번거로워졌습니다. 에이전트에게 작업을 요청하는 대신 다시 UI 메뉴를 클릭하게 되었습니다.

AI와 코딩 에이전트 시대에는 추상화의 비용이 그 어느 때보다 높습니다. 저는 물었습니다: 정말 CMS가 필요할까요? 사람들이 GUI 대신 챗봇으로 콘텐츠를 수정해야 한다면 과연 신경 쓸까요? 우리가 다시 순수 코드로 돌아간다면 엄청난 복잡성을 제거할 수 있습니다.

Roman이 CMS에서 코드로 마이그레이션하는 데 얼마나 걸릴지 물으셨습니다. 제 대략적인 추정은 1–2주였고, 아마 에이전시를 고용해 도움을 받을 것이라고 생각했습니다. 어쩌면 저는 AI의 현재 상태에 맞춰 일정 추정을 갱신하지 않았던 것 같습니다. 그래서 Cursor에서 마이그레이션 계획을 만들어 보고 에이전트를 실행해 1차 시도를 해보기로 했습니다. 얼마나 멀리까지 진행되는지 놀랐지만, 분명 더 많은 작업이 필요했습니다.

그 정도면 주말 동안 마이그레이션에 몰입하기에 충분했습니다. 다음은 그 주말 동안 사이트를 어떻게 마이그레이션했는지입니다.

복잡성 제거

Cursor 웹사이트는 표준 Next.js와 React 앱입니다.

새 버전은 비개발자도 마케팅 페이지를 만들고 글 작성자가 새로운 블로그 포스트를 추가할 수 있도록 CMS 위에 구축되었습니다. 다시 말해, 대부분의 사이트에서 CMS를 사용하는 것은 꽤 표준적입니다.

많은 팀에게 CMS 추상화의 비용은 그만한 가치가 있습니다. 작성자나 마케터가 로그인해 몇 번의 클릭으로 콘텐츠를 변경할 수 있는 포털이 필요하기 때문입니다. 태초(WordPress)부터 그래왔습니다.

덜 논의되는 점은, 현대 웹사이트에 헤드리스 CMS를 “잘” 통합하기 위해 필요한 기술적 복잡성의 양입니다. 저는 모든 제품과 솔루션에 익숙하고, 일부는 그 복잡성을 아주 잘 숨깁니다! 그래도 그 복잡성은 여전히 존재합니다, npm 패키지 뒤에 숨어 있더라도요.

이제 숨겨진 복잡성의 짧은 목록을 보겠습니다. 기술적 세부사항에 덜 관심이 있으시다면 건너뛰셔도 됩니다:

export default async function Navbar() {
  const data = await fetchFromCMS("navigation");

  return (
    <nav>
      <ul>
        {data.map((item) => (
          <li key={item.id}>
            <Link href={item.url}>{item.label}</Link>
          </li>
        ))}
      </ul>
    </nav>
  );
}

const navItems = [
  { id: "1", label: "Home", url: "/" },
  { id: "2", label: "Docs", url: "/docs" },
  { id: "3", label: "Features", url: "/features" },
  { id: "4", label: "Enterprise", url: "/enterprise" },
];

export default function Navbar() {
  return (
    <nav>
      <ul>
        {navItems.map((item) => (
          <li key={item.id}>
            <Link href={item.url}>{item.label}</Link>
          </li>
        ))}
      </ul>
    </nav>
  );
}

export default function Navbar() {
  return (
    <nav className="flex">
      <ul className="flex space-x-4">
        <li>
          <Link className="px-3 py-2 hover:text-primary" href="/">
            Home
          </Link>
        </li>

        <li>
          <Link className="px-3 py-2 hover:text-primary" href="/docs">
            Docs
          </Link>
        </li>

        <li>
          <Link className="px-3 py-2 hover:text-primary" href="/features">
            Features
          </Link>
        </li>

        <li>
          <Link className="px-3 py-2 hover:text-primary" href="/enterprise">
            Enterprise
          </Link>
        </li>
      </ul>
    </nav>
  );
}

마이그레이션 수행

저는 Opus 4.5로 계획을 만들었습니다. Cursor는 몇 가지 명확화 질문을 되돌려 주었습니다.

Cursor가 제안한 것은 분명했지만 제가 즉시 떠올리지 못했던 것입니다. 저희는 이미 CMS에서 콘텐츠를 가져올 수 있는 API 키가 있습니다. 메뉴를 뒤지며 다운로드하는 대신, 콘텐츠를 내보내고, 구조를 검증하고, 이를 리포지토리의 마크다운과 파일로 변환하고, 이미지와 비디오를 객체 스토리지에 업로드하는 일련의 스크립트를 만들 수 있습니다.

저는 아마 10번 정도 에이전트를 실행해 80%까지 도달했습니다. Cursor는 의존성을 설치하고 제거했으며, 스크립트를 실행하고, 수많은 페이지의 콘텐츠를 구축했습니다. 그러나 대부분의 엔지니어링 작업과 마찬가지로 마지막 20%가 대부분의 시간을 잡아먹습니다. 하지만 이미 늦었습니다. 저는 완전히 몰입해 있었습니다. 반드시 이 작업을 끝내고 싶었습니다.

일부 페이지는 완벽한 일치가 아니었기에, 저는 모든 페이지에서 다음 에이전트를 실행했습니다:

/features 페이지가 프로덕션과 완벽히 일치하지 않습니다. 홈 페이지의 CMS 데이터 내보내기 방식을 검토하고, 하위 구성요소, 이미지, 배경을 모두 포함해 features 페이지의 전체 콘텐츠를 다시 내보내세요.

@browser를 사용해 스크린샷을 찍고, 로컬 버전이 완벽히 일치할 때까지 반복하세요. 첫 번째 첨부 이미지는 로컬, 두 번째는 프로덕션입니다.

에이전트를 실행하기 시작하자, 성가시던 모든 코드베이스 패턴에 대해 훨씬 더 광범위한 리팩터링을 시작했습니다. 또한 곧 출시될 서브에이전트(subagents)를 사용할 좋은 기회였습니다. 저는 Opus와 함께 제가 원하는 API 형태에 대한 계획을 만들고, Cursor에게 서브에이전트를 실행해 여러 호출 지점에서 병렬로 변경을 수행하도록 요청했습니다. 훨씬 빨랐습니다.

작은 행운의 사고들

복잡성을 제거하는 데 너무 들떠서 Storybook도 완전히 삭제했습니다.

Storybook에는 멋진 기능이 있지만 저희는 거의 사용하지 않았습니다. 게다가 Cursor 브라우저로 시각적으로 편집할 수 있게 되면서, 이제 그 가치를 그다지 느끼지 못합니다.

게다가, 모든 머신과 CI 실행에서 많은 의존성을 다운로드하고 설치해야 하지만, 저는 이 단순 버전을 매우 빠르게 구축할 수 있었습니다.

또한 객체 스토리지 위에서 에셋을 관리할 GUI는 여전히 필요했습니다. 에이전트에게 3~4개의 프롬프트만 던져도 괜찮고 쓸 만한 결과를 얻을 수 있었습니다. 최소 기능 세트입니다. 물론 더 많은 기능을 추가할 수 있지만, 지금은 그럴 필요가 없습니다.

콘텐츠가 코드에 있을 또 다른 이점은 모든 변경이 git을 통해 흐른다는 것입니다. 과거에도(되돌리거나 누가 변경했는지 파악하는 데) 유용했지만, 코딩 에이전트가 자율적으로 탐색하기에는 엄청나게 도움이 됩니다.

결과

이건 정말 놀라웠습니다. Cursor는 저희 API를 사용해 사용량을 계산하는 스크립트를 작성했습니다:

• $260.32 및 297.4M 토큰(대부분 캐시됨)
• 344 에이전트 요청
• 66 수동 탭 변경
• 67 커밋(+43K / -322K 라인)

몇 주가 걸리고 아마 에이전시의 도움이 필요할 것이라고 생각했던 일이 $260의 토큰(혹은 월 $200의 Cursor 요금제)으로 마무리되었습니다.

더 중요하게는, 마이그레이션은 이미 충분한 가치를 입증했습니다. 다음 날 저는 휴대폰의 클라우드 에이전트로 웹사이트의 수정을 머지했습니다. 그다음 날에는 한 엔지니어가 하나의 PR에서 제품과 마케팅 사이트 전반에 걸친 기능을 출시했습니다.

저희는 에셋을 더 낮은 비용의 객체 스토리지로 옮겨 CDN 사용료에서 수천 달러를 절감하고 있습니다. 부수 효과로, 프리렌더링 시 CMS로 향하는 네트워크 I/O를 제거하면서 빌드 시간이 2배 빨라졌습니다.

AI 시대의 추상화 비용은 매우 높습니다. 과도한 추상화는 늘 성가시고 코드 스멜이었지만, 이제 쉬운 해결책이 있습니다. 토큰을 과감히 사용하면 됩니다. 코드베이스에서 복잡성을 제거하는 데 든 비용은 충분히 가치가 있었고 이미 상쇄되었습니다.

이 이야기가 전체 경제에 걸쳐 어떻게 펼쳐질지 상상해 보시기 바랍니다. 코딩 에이전트는 팀들이 가장 대담한 아이디어를 시도하고, 백로그 깊숙이 묻혀 있던 기술 부채를 해결하도록 돕고 있습니다. 저는 풍부하고 고품질의 소프트웨어 세계가 기대되며, Cursor가 그 실현에 계속해서 기여하길 바랍니다.