2026년 3월, 우리는 플랫폼 전반의 moonshot.ai 경험을 새롭게 다듬었습니다. 겉으로는 새로운 색상 팔레트, 더 정돈된 타이포그래피, 업데이트된 모션처럼 단순해 보였습니다. 하지만 실제로는 전체 사이트의 공유 컴포넌트, 디자인 token, 라우트, 인터랙티브 레이어까지 영향을 미치는 작업이었습니다.
우리는 Kimi K2.5 기반의 Kimi Code CLI를 AI 코딩 agent로 활용해 리빌드를 진행했습니다. 이 프로젝트는 데모 환경이 아니라 실제 프로덕션 워크플로에서 터미널 기반 agent가 어떻게 맞물리는지 검증하는 실전 테스트가 되었습니다. 이 글에서는 우리가 어떻게 활용했고 그 과정에서 무엇을 배웠는지 소개합니다.
이번 리프레시의 진짜 목적
moonshot.ai 리프레시는 브랜드를 처음부터 다시 디자인하는 일이 아니었습니다. 디자인 작업 대부분은 이미 Figma에 존재했습니다. 진짜 과제는 그 업데이트를 기존 코드베이스 전반에 일관되게 적용하는 것이었습니다.
즉 공유 token을 추적하고, 컴포넌트를 업데이트하며, 인터랙티브 동작을 점검하고, 분석과 접근성이 영향을 받지 않도록 보장해야 했습니다. 개별 변경은 작은 경우가 많았지만 사이트의 여러 레이어에 걸쳐 있었습니다.
이런 작업이 어려운 이유는 알고리즘 복잡도 때문이 아닙니다. 범위가 넓고 일관성을 지켜야 하기 때문입니다. 핵심은 변경이 어디까지 영향을 미치는지 파악하고, 놓치는 것이 없도록 하는 데 있습니다. 이를 지원하기 위해 Figma와 Model Context Protocol (MCP) 연결을 사용해 디자인 사양과 구현을 더 잘 맞췄고, agent가 구조를 이해하도록 도와 수동 해석을 줄였습니다.
기본 원칙: agent를 유용하게 만들기
첫 단계는 프롬프트 작성이 아니라 맥락 설정이었습니다. /init 명령으로 AGENTS.md 파일을 생성한 뒤 약 한 시간 동안 다듬었습니다. 그 안에는 리프레시 범위, 변경해서는 안 되는 것, 프로젝트 구조, 빌드 프로세스 작동 방식을 문서화했습니다. 또한 네이밍 규칙, 간격, 대비 요구사항을 다룬 규칙 파일도 추가했습니다.
이 설정 덕분에 이후 반복 설명이 줄었고 Kimi Code CLI 워크플로도 더 일관되게 유지되었습니다. 프로젝트별 맥락이 없으면 AI 코딩 agent는 그럴듯하지만 일반적인 결과물을 내는 경향이 있습니다. 맥락을 제공하면 이미 코드베이스를 이해하고 있는 팀원에 가까운 방식으로 동작합니다.
실제로 활용한 방식
이 섹션에서는 리프레시 과정에서 Kimi Code CLI를 실제로 어떻게 사용했는지 살펴봅니다. 의존성 추적, 디자인 정합성 확인, 동작 조사, 성능 점검, 통합 리스크 검토를 아우릅니다. 초점은 자동화가 아니라 대규모 리팩터링에서 불확실성을 줄이는 데 있었습니다.
변경이 영향을 미치는 범위 파악하기
무엇이든 수정하기 전에 Kimi Code CLI의 agent에게 대상 영역을 읽고, 여기에 의존하는 다른 요소들을 나열해 달라고 요청했습니다. 버튼 색상 같은 단일 변경도 hero 섹션, 다운로드 섹션, hover 상태, 공유 token에 영향을 줄 수 있으며, 공유 컴포넌트와 모션 타이밍, 분석 hook까지 더해지면 영향 범위는 더 커질 수 있습니다. 먼저 의존성 목록을 확보하니 이후의 예기치 못한 상황이 줄고 수정도 더 예측 가능해졌습니다.
코드를 디자인 사양에 맞추기
이후 hero, 내비게이션, 제품 섹션, 다운로드 CTA, 푸터처럼 섹션별로 컴포넌트를 디자인 사양과 비교했습니다. agent는 스타일을 디자인 token 및 레이아웃 값과 대조해 속성 수준의 변경 목록을 만들어냈습니다. 이 과정은 수동 시각 검수보다 구조화된 디자인 시스템 자동화에 더 가까웠습니다. 대부분의 차이는 간격, border radius, font weight처럼 작았지만, 시간이 지나며 같은 variant를 공유해야 할 컴포넌트들이 서로 어긋난 더 큰 불일치가 드러나기도 했습니다. 그 결과 시각적으로 추측하는 대신 구체적인 수정 목록을 얻을 수 있었습니다.
새로운 동작 조사하기
이번 리프레시에는 코드베이스에 이전에는 구현되지 않았던 새로운 UI 동작이 도입되었습니다. 커스텀 커서, 런타임 기반 hero, hover 시 재생되는 일러스트 카드, 스크롤로 트리거되는 등장 효과가 그것입니다.
각 기능마다 문서와 저장소 상태를 함께 불러와 Kimi Code CLI를 맥락이 갖춰진 환경처럼 사용했습니다. 바로 여기서 Kimi K2.5가 중요했습니다. 더 긴 컨텍스트 덕분에 구현과 참고 자료를 한곳에 두고 추론하기가 쉬웠습니다.
질문은 실무적이었습니다:
hover 애니메이션은 종료 시 끝까지 재생해야 할까, 취소해야 할까?
커서 상태는 hero canvas와 상호작용해야 할까?
여러 레이어가 겹치면 무엇이 깨질까?
큰 컨텍스트 창 덕분에 디자인 의도와 코드가 같은 세션 안에 공존하는, 더 연속적인 kimi code 워크플로가 가능했습니다.
용량과 성능 점검하기
리프레시로 새로운 서체, 더 많은 모션, 추가 asset이 도입되면서 페이지 용량이 늘었습니다. 우리는 agent를 사용해 기존 font subsetting 스크립트를 조정하고 결과물을 검증했으며, 이후에는 Lighthouse 보고서를 해석하는 데 도움을 받아 회귀를 조기에 발견할 수 있었습니다. 목표는 끝에서 모든 것을 최적화하는 것이 아니라, 변경이 아직 작을 때 유지할지 덜어낼지 결정하는 것이었습니다.
병합 전 통합 리스크 추적하기
등장 애니메이션, 커서, hero canvas 같은 여러 인터랙티브 레이어는 서로 다른 컴포넌트에 있어도 순서와 포인터 동작을 공유하므로, 한 레이어의 변경이 다른 레이어에 영향을 줄 수 있습니다. 또한 CSS와 렌더링 동작이 항상 같지 않을 수 있는 브라우저 및 OS 간 차이도 고려해야 했습니다. 변경 묶음을 병합하기 전에 diff를 Kimi Code CLI에 입력하고 어떤 상호작용이 영향을 받을 수 있는지 추적해 달라고 요청한 뒤, 브라우저에서 해당 경로를 확인하고 여러 환경을 가볍게 점검했습니다.
MCP 통합과 Skills
Model Context Protocol (MCP)을 통해 Kimi Code CLI는 프로젝트 데이터가 담긴 외부 시스템에 직접 연결할 수 있었습니다. 우리는 mcp Figma를 사용해 디자인 token, 레이아웃 데이터, 타이포그래피를 Figma에서 직접 가져왔고, 디자인과 코드 사이의 수동 변환을 줄였습니다. 또한 내부 도구도 연결해 작업, 사양, 엣지 케이스를 컨텍스트 전환 없이 드러낼 수 있었습니다.
서버 추가는 명령 하나로 끝납니다:
이 패턴은 MCP 생태계 전반으로 확장됩니다. 예를 들어 agents를 다음과 연결할 수 있습니다:
Figma — 캔버스의 디자인 컨텍스트, 변수, 레이아웃 데이터를 위한 공식 MCP
Atlassian Cloud — Atlassian의 원격 MCP 진입점을 통한 Confluence 페이지와 Jira 작업 항목(Rovo와 함께 문서화됨)
데이터베이스, CMS APIs — 벤더 또는 커뮤니티 MCP 서버. 레지스트리에는 카테고리별로 수백 가지 옵션이 정리되어 있습니다.
사용하는 스택은 다를 수 있습니다. 비공개 문서 API, 내부 디자인 token 서비스, 데이터 웨어하우스일 수도 있습니다. 핵심은 같습니다. 관련 데이터를 이미 보유한 시스템에 agent를 연결하는 것입니다. Kimi Code CLI에서 MCP를 구성하는 config 파일, 서버 정의, 기타 연결 방법은 플랫폼 가이드를 참고하세요.
Review Skill
우리는 코드 리뷰용 Skill도 작성했습니다. Kimi Code CLI가 merge request를 처음부터 끝까지 평가하는 방법을 알려주는 규칙 파일입니다. diff를 읽고, 영향을 받는 파일과 컴포넌트를 추적하며, 디자인 시스템 위반(그대로 들어간 색상 literal, 그리드에서 벗어난 간격, 누락된 접근성 fallback)을 확인하고, 영역별 리스크를 평가한 뒤 구조화된 보고서를 생성합니다.
보고서는 정해진 형식을 따릅니다:
의도와 범위 요약
심각도별로 묶은 발견 사항(병합을 막는 중대 이슈, 권장 개선 사항, 사소한 일관성 제안)
각 발견 사항별 diff 근거, 영향 평가, 구체적인 조치 항목
Skill은 agent가 확신하지 못하지만 검증 비용은 낮은 경우처럼, 빠른 브라우저 또는 기기 검증이 필요할 수 있는 잠재 리스크도 표시합니다.
실제로 moonshot.ai 비주얼 리프레시 기간의 모든 PR은 리뷰 완료 전에 이 구조화된 점검을 거쳤습니다. 결과물에는 항상 의도 요약, 심각도순 발견 사항, 근거, 수정안이 포함되었습니다.
이를 통해 후반 단계의 불필요한 반복을 줄이고 Kimi Code 워크플로 전반의 일관성을 높일 수 있었습니다. 예를 들어 공유 상수 옆에 하드코딩된 URL, 정렬이 필요한 분석 필드, 모바일 상호작용 엣지 케이스 같은 문제가 드러났습니다.
예상하지 못했던 점
리팩터링 중에는 처음에는 분명하지 않았던 몇 가지 패턴이 드러났습니다.
사양을 코드로 옮기는 속도가 예상보다 빨랐습니다
Figma MCP와 Kimi Code CLI가 같은 스레드 안에 있으니 치수와 디자인 token이 수동 전사가 아니라 구조화된 입력으로 들어왔습니다. 그 결과 섹션별 반복 주기가 짧아졌고, 속성 수준의 변경과 수정이 도구 사이를 오가는 대신 한 번에 반영되는 경우가 많았습니다.
조사 프롬프트의 효과가 예상보다 컸습니다
이번 리프레시는 저장소와 함께 런타임 문서와 참고 구현을 길게 훑는, 문서 중심의 작업에 크게 의존했습니다. 이런 자료를 코드와 같은 세션에 두는 것만으로도 종종 실제 수정만큼 가치가 있었습니다.
리뷰 Skill이 작은 불일치를 목록으로 바꿔 주었습니다
구조화된 보고서는 앞서 설명한 것과 같은 유형의 문제를 드러냈습니다. 공유 상수 옆에 하드코딩된 URL, 정렬이 필요한 분석 필드, 모바일 상호작용 엣지 케이스 등이었습니다. 대부분은 개별적으로는 사소했지만, 한 번에 묶어 보니 훨씬 쉽게 처리할 수 있었습니다.
긴 스레드도 부담 없이 이어갈 수 있었습니다
kimi --continue와 /compact 같은 명령 덕분에 여러 날에 걸친 작업에서도 매일 아침 컨텍스트를 다시 쌓을 필요가 없었습니다. 재프롬프트가 줄어들고 같은 Kimi Code 워크플로가 안정적으로 이어졌습니다.
세션을 이어가기, 세션 간 전환, /compact 및 관련 명령으로 컨텍스트를 관리하는 방법은 Kimi Code CLI 세션 가이드를 참고하세요.
moonshot.ai를 다시 구축하며 얻은 교훈
비슷한 moonshot.ai 비주얼 리프레시를 다시 진행한다면, 몇 가지는 다르게 접근할 것입니다.
코드보다 컨텍스트를 먼저 준비하세요
처음 한 시간 동안 범위, 제약, 규칙을 문서화한 것이 이후 어떤 프롬프트보다 더 많은 시간을 절약해 주었습니다. 이를 미리 정해 두니 Kimi Code CLI 같은 도구가 워크플로 전반에서 더 일관되게 동작했습니다.
단일 진실 공급원을 일찍 연결하세요
우리의 경우에는 Figma였습니다. 다른 프로젝트에서는 CMS, 내부 API, 디자인 시스템일 수 있습니다. 특히 프런트엔드 리팩터링 맥락에서 AI 코딩 agent를 사용할 때 핵심은 시스템이 추정된 가정이 아니라 실제 데이터로 작동하도록 하는 것입니다.
디자인과 작업 컨텍스트를 같은 루프에 유지하세요
token, 사양, 구현을 공유 컨텍스트로 가져오자 오가는 과정이 줄고 반복 주기가 더 안정되었습니다. Figma MCP와 Kimi Code CLI를 함께 쓰는 워크플로가 특히 효과적이었던 지점입니다. 디자인 의도와 코드 변경이 하나의 연속된 루프 안에서 맞물리도록 도왔기 때문입니다.
코드를 쓰고 싶지 않다면: Kimi Websites
위 내용은 터미널, diff, 컨텍스트 파일을 다루는 개발자 중심 워크플로를 설명합니다. 하지만 속도가 프레임워크 수준의 제어보다 중요하다면, 같은 결과물인 완성도 높고 반응형인 웹사이트를 그 스택 없이도 만들 수 있습니다.
Kimi Websites는 같은 Kimi K2.5 모델을 기반으로 하지만, 시각적인 노코드 인터페이스로 작동합니다. 원하는 것을 자연어로 설명하고, 대화를 통해 섹션을 다듬은 뒤, 클릭 한 번으로 게시할 수 있습니다. 기존 스크린샷을 입력으로 받아 레이아웃 구조를 재구성할 수도 있습니다.
랜딩 페이지를 프로토타이핑하는 창업자나 촉박한 일정 안에 캠페인 사이트를 출시해야 하는 마케터에게는 전통적인 프런트엔드 스택을 직접 다루는 것보다 더 빠른 길이 됩니다.
결론
Kimi Code CLI와 Kimi K2.5는 복잡성보다 범위가 더 중요한 프로젝트 구간에서 가장 유용했습니다. 비주얼 리프레시는 대개 어려운 문제를 푸는 일이 아니라, 시스템 전반에서 일관성을 유지해야 하는 수많은 작은 변경의 문제입니다. 사람에게는 시간이 많이 걸리지만, 파일을 넘나들며 추적하고 비교할 수 있는 agent에게는 비교적 잘 맞는 작업입니다.
결정은 여전히 우리가 내렸고, 모든 변경을 검토했으며, 최종 결과도 직접 검증했습니다. agent는 반복적인 추적, 비교, 초기 리뷰 작업을 맡았습니다. 실제로 이 역할 분담은 AI 코딩 agent를 프로덕션 워크플로에 통합하는 실용적인 방식임이 드러났습니다. 여러 파일에 걸친 리팩터링, 디자인-코드 검증, 대규모 일관성 작업에 이 접근 방식은 유용했습니다.