Claude Code에 플러그인을 열두 개 설치해 두면, 병목은 '기능 부족'이 아니라 '기억력'으로 바뀝니다. 50개가 넘는 슬래시 명령어 중 지금 당장 필요한 것이 어디 있는지 도저히 떠오르지 않는 상황 말이죠. Lens는 바로 이 탐색 문제를 해결하기 위해 만들어진 도구입니다.
Creeta Lens란 무엇이며 어떤 문제를 해결하나
Lens는 Claude Code용 스킬 네비게이터이자 멀티 에이전트 오케스트레이터입니다. 설치된 플러그인을 스캔해 작업에 가장 적합한 스킬을 찾아내고, 하드코딩된 플러그인 의존성 없이 단일 명령어로 실행합니다. github.com/livevil7/creeta-lens에서 MIT 라이선스 오픈소스로 공개되어 있으며 현재 버전은 v3.18.1입니다 . 어떤 플러그인이 어떤 명령어를 소유하는지 외울 필요 없이, 작업을 설명하면 Lens가 라우팅합니다.
한줄 요약: Creeta Lens는 MIT 라이선스 기반의 Claude Code용 스킬 네비게이터(v3.18.1)로, 설치된 Skills·MCP 툴·LSP 서버를 스캔해 8개 언어에 걸쳐 최적 매칭을 추천하고 /c, /cc, /cp 등의 명령어로 실행합니다. 플러그인 10개 이상, 슬래시 명령어 50개 이상을 운용하는 사용자를 대상으로 합니다.
타깃 사용자는 명확합니다. 플러그인 10개 이상, 슬래시 명령어 50개 이상, MCP 툴과 LSP 서버를 운용하면서 하나의 진입점에서 탐색·오케스트레이션·계획·QA·동기화를 처리해야 하는 사람입니다 . 요구 사항은 최소한으로 명시되어 있습니다. Claude Code v1.0.33 이상과 플러그인 2개 이상이면 충분합니다 . Lens는 기존 생태계 위에 얹히는 메타 레이어로, 개별 플러그인을 대체하는 것이 아니라 그 사이를 라우팅합니다.
명령어 체계는 의도에 따라 깔끔하게 나뉩니다. /c와 /cc는 실행, /cp와 /cpp는 계획, /ccp는 QA, /cr은 자체 감사용입니다 . 프로젝트 README는 이를 이렇게 정의합니다. "설치된 플러그인을 스캔해 작업에 가장 적합한 스킬을 찾아내고, 하드코딩된 플러그인 의존성 없이 단일 명령어로 실행한다" (source: creeta-lens README).
더 진행하기 전에 혼동을 피하기 위한 설명이 하나 필요합니다. 발음이 비슷한 이름이 많기 때문입니다. creeta.com의 개발자 도구 사이트 Creeta와 creeta-lens 저장소는 Creata AI(소비자용 생성 AI 앱)도, Cresta Intelligence(엔터프라이즈 컨택센터 AI)도, CrewAI(오픈소스 멀티 에이전트 프레임워크)도, Creta(web3 게임 플랫폼)도 아닙니다. 발음은 같지만 완전히 다른 제품들입니다.
슬래시 명령어 한눈에: /c, /cc, /cp, /cpp, /ccp, /cr
Lens는 실행·계획·품질·메타 관리, 네 가지 축에 대응하는 여섯 개의 명령어를 제공합니다. 플러그인별 문법을 외울 필요 없이 의도에 따라 명령어를 고르면 됩니다. 작업 실행, 계획 수립, 검증, Lens 자체 감사 중 원하는 것을 선택하면 네비게이터가 스킬 선택을 처리합니다. 아래 표는 전체 명령어를 요약하며, 이후 섹션에서 주요 쌍을 자세히 설명합니다.
| 명령어 | 용도 | 기능 |
|---|---|---|
/c | 실행 (순차) | 단일 워커, 결정적 라이프사이클: 분석 → 계획 → 스킬/모델 배정 → 승인 → 실행 → 수퍼바이저 검토 → QA |
/cc | 실행 (동시) | Leader·Workers·Monitor·Supervisor·QA 역할의 다중 워커; 최대 5회 반복 |
/cp | 계획 (빠른/표준) | 일반 계획 및 문서 라이프사이클, Fast와 Standard 두 단계로 구분 |
/cpp | 계획 (심층) | 빌드 준비형 계획: 목표 확정, 6축 리서치 팬아웃, Codex 연동, 정확한 경로/변경/검증 태스크, EARS 검증 |
/ccp | 품질 | 빌드 완료 후 또는 실행 중 QA 및 수리; Playwright·앱 실행·curl로 실제 동작을 검증한 뒤 4가지 대립적 리뷰 렌즈 적용 |
/cr | 메타 | Lens 기능 각각을 KEEP·THIN·OBSOLETE·UNKNOWN으로 분류하는 자체 현대화 감사 — 코드 자동 삭제 없음 |
실행 축. /c는 순차 실행 엔진입니다. 단일 워커가 분석·계획·스킬 및 모델 배정·사용자 승인·실행·수퍼바이저 검토·QA 검증으로 이어지는 고정 라이프사이클을 처리합니다 . /cc는 동시 실행 버전으로, Leader·Workers·Monitor·Supervisor·QA 역할 아래 여러 워커를 동시에 파견하며 루프를 최대 5회로 제한합니다 .
계획 축. /cp는 일반 작업의 빠른 계획·표준 계획과 문서 라이프사이클을 담당합니다 . /cpp는 심층 빌드 준비 플래너입니다. 목표를 확정하고 6개 축에 걸쳐 리서치를 팬아웃하며, Codex 연동을 필수화하고, EARS 검증이 포함된 정확한 경로/변경/검증 태스크를 출력합니다. v3.18부터는 기존의 길이 제한이 제거되었습니다 .
품질 축. /ccp는 빌드 완료 후 또는 이미 실행 중인 작업에 대한 진입점입니다. Playwright·앱 실행·curl을 실제로 구동해 동작을 검증한 뒤, 4가지 대립적 리뷰 렌즈를 적용해 실패 항목을 수정합니다 .
메타 축. /cr은 도구를 자기 자신에게 겨냥합니다. Lens의 모든 기능을 현재 Claude Code 및 Codex 네이티브 기능과 비교해 각각 KEEP·THIN·OBSOLETE·UNKNOWN으로 태깅합니다. 코드 자동 삭제는 의도적으로 피하며, 제거 결정은 개발자에게 맡깁니다 .
/c vs /cc: 순차 실행 vs. 동시 실행
/c와 /cc의 차이는 순차 실행과 병렬 실행 사이의 선택입니다. /c는 단일 워커를 고정된 생명주기 — 분석, 계획 수립, 스킬·모델 배정, 사용자 승인, 실행, 모니터링, 수퍼바이저 검토, QA 검증 — 를 통해 실행하며, 각 단계가 다음 단계의 진입을 통제하므로 모델이 앞 단계를 건너뛸 수 없습니다 . /cc는 병렬 변형으로, Leader·Workers·Monitor·Supervisor·QA 역할 아래 여러 워커를 동시에 배치합니다 .
/cc에서는 Leader가 작업을 분해하고 서브태스크를 Workers에게 동시에 배분하며, Monitor가 진행 상황을 추적하고, Supervisor와 QA가 통합 결과를 감사한 뒤 배포합니다 . 이 구조는 서브태스크가 진정으로 독립적일 때 — 연관 없는 모듈 다섯 개를 리팩터링하거나, 동일 상태를 건드리지 않는 여러 파일을 생성할 때 — 비로소 가치를 발휘합니다. 순서가 중요한 작업이라면 /c의 결정론적 단계 통제는 부담이 아니라 핵심입니다.
실용적인 판단 기준은 명확합니다:
/c사용 — N번째 단계가 N−1번째 단계의 출력에 의존하는, 순서 자체가 정확성인 상호의존 작업./cc사용 — 공유 가변 상태 없이 서브태스크를 동시에 실행할 수 있는 작업.- 판단이 서지 않으면
/c를 기본값으로 — 느리고 순서 있는 경로가 더 안전합니다. 병렬 워커가 같은 파일을 건드리면 경쟁 조건과 머지 충돌을 불러옵니다.
/cc는 5회 반복으로 제한됩니다 . 수렴 없이 무한히 돌아가는 병렬 사이클을 막기 위한 의도적인 안전장치입니다. 다섯 번이 넘어야 할 것 같다면, /cc를 호출하기 전에 범위를 줄이거나, 직접 순서를 정해 별도의 /c 호출로 나누는 것이 신호입니다. 이 제한은 하나의 규율을 강제합니다: 병렬 처리는 이미 깔끔하게 분할할 수 있는 작업을 위한 것이지, 아직 윤곽을 잡는 중인 문제를 위한 것이 아닙니다.
/cpp: 목표 확정부터 심층 리서치 인계까지
/cpp는 Lens의 심층 빌드 준비 계획 엔진입니다. 리서치 시작 전 목표를 고정하고, 여러 차원에 걸쳐 리서치를 병렬 전개하며, Codex와 구현을 조율하고, 워커에게 바로 넘길 수 있을 만큼 정밀한 경로·변경·검증 계획을 산출합니다. 2026-06-11 v3.15.0에서 심층 빌드 준비 계획 레인으로 처음 출시되었습니다 . /cp가 빠른 또는 표준 계획 수립을 담당한다면, /cpp는 범위 이탈이 작업을 망칠 만큼 규모가 큰 태스크에 도달했을 때 선택하는 진입점입니다.
목표 확정이 첫 번째 단계이며, 그것이 핵심입니다. 리서치나 계획이 시작되기 전에 목표가 확인되고 동결됩니다. 이는 대규모 LLM 지원 작업에서 가장 흔한 실패 모드 — 긴 계획 도중 목표가 조용히 바뀌는 것 — 를 차단합니다. Lens는 이를 제로 후속 질문 의도라고 부릅니다. 완성된 문서는 누군가 실행하기 전에 추가 확인 없이 바로 활용할 수 있어야 합니다 .
그 기준에 도달하기 위해 /cpp는 6축 병렬 전개를 실행합니다. 서로 다른 차원에 걸친 여러 리서치 패스를 단일 얕은 스윕이 아닌 하나의 계획으로 종합합니다 . Codex 조율은 선택이 아닌 필수입니다. /cpp는 구현 단계를 명시적으로 Codex에 인계하기 때문에, 단순한 계획 문서가 아니라 코드를 생성하는 빌드 태스크에 적합한 도구입니다.
"필수 Codex 조율, 정확한 경로/변경/검증 태스크, EARS 검증, 제로 후속 질문 의도." — Lens /cpp 스킬 명세 (source: creeta-lens/skills/cpp/SKILL.md)
출력 형식은 의도적으로 구체적입니다. 각 태스크는 정확한 파일 경로, 변경 내용, 검증 방법을 명시하며, EARS 방식의 검증 — Event(이벤트), Action(행동), Result(결과), State(상태) — 을 통해 수용 기준이 모호하지 않고 테스트 가능합니다. 2026-06-14에 출시된 v3.18.0에서 Lens는 /cpp와 그 HTML 출력의 단어·길이 제한을 제거하고, 슬라이드 수 제한 없는 task-deep HTML 형식을 추가해 대규모 계획 레인으로 재정립했습니다 . 실제로는 진정한 대규모 계획이 예산에 맞춰 잘리는 대신 임의의 크기로 인계 문서를 생성할 수 있게 되었습니다.
v3.18 /cpp 전면 개편: 길이 제한 철폐와 HTML 심층 문서
v3.18 라인은 /cpp를 Lens의 대형 플래닝 전용 경로로 탈바꿈시킵니다. 2026-06-14 출시된 v3.18.0은 기존 /cpp와 HTML 출력에 적용되던 단어 및 길이 제한을 제거하고, 슬라이드 수 제한 없는 task-deep HTML 형식을 추가했습니다 . 이는 출력 계약의 구조적 변화입니다. 기존에는 예산에 맞게 내용을 잘라내던 플래너가, 이제는 실제로 큰 계획을 임의 크기의 핸드오프 문서로 출력할 수 있습니다. /cpp 출력의 예측 가능한 길이를 전제로 파싱하거나 렌더링하는 다운스트림 도구를 구축했다면, 그 전제는 더 이상 유효하지 않습니다 — 업그레이드 전에 해당 소비자 코드를 검토하세요.
같은 날 몇 시간 뒤, v3.18.1이 드리프트 및 불일치 수정을 위한 후속 패치로 6가지 수정 사항을 담아 출시되었습니다 . 운영 측면에서 가장 중요한 변경은 Codex service_tier를 priority에서 fast로 수정한 것으로, 이는 /cpp의 필수 Codex 호출의 비용과 큐 위치 모두에 영향을 미칩니다 — Codex 지출을 추적한다면 주목할 만합니다.
| v3.18.1 수정 항목 | 변경 내용 |
|---|---|
Codex service_tier | priority → fast (비용 및 큐 위치에 영향) |
| 릴리스 가이드 버전 파일 수 | 9 → 13 |
| /cpp 완료 스윕 문서 | 문서 업데이트됨 |
| Codex 그레이스풀 디그레이드 | /cpp 하드 게이트와의 충돌 해결 |
| bump-version 레이블 | 13단계로 정규화 |
| upgrade.py dry-run | 마켓플레이스 뒤처짐 상태 보고 수정 |
이 속도는 주변 릴리스와 일관됩니다. v3.17.0 (2026-06-13)은 필수 Why 섹션을 추가하고 What, Why, How, Review를 중심으로 계획 문서를 표준화했으며, v3.16.0 (2026-06-11)은 /ccp와 Power Verify 플로우를 도입했고, v3.15.0 (2026-06-11)은 /cpp를 처음 추가하면서 /cp를 Fast와 Standard 티어로 분리했습니다 . 요약하면, /cpp는 불과 3일 만에 신기능에서 대형 플래닝을 위한 무제한 기본 옵션으로 자리잡았습니다. 개발자 관점의 시사점은 명확합니다. /cpp에서 더 크고 슬라이드 기반의 HTML 산출물이 생성될 것을 예상하고, Codex 호출 예산 책정 시 service_tier 변경을 반영하세요.
autoRecommend=false, autoCommit=true 설정과 그 함의
Lens는 레포지토리 내 동작 방식을 결정하는 의도적인 기본값을 탑재하고 출시됩니다. 실제 lens.config.json은 autoRecommend를 false, autoCommitOnComplete를 true, buildBoard를 true, capabilityAuditNudge를 true, capabilityAuditIntervalDays를 30으로 설정합니다 . 각 플래그는 그대로 유지하기 전에 이해할 가치가 있는 트레이드오프를 수반합니다.
autoRecommend: false는 Lens가 매번 호출 시 스킬 제안을 자동으로 내보내지 않음을 의미합니다. 제어권은 사용자에게 있습니다. /c, /cc 등을 명시적으로 호출하거나 필요 시 추천기를 직접 실행하면 됩니다. 실질적 의미는 Lens가 일반적인 Claude Code 상호작용을 방해하지 않는다는 것입니다 — 요청할 때만 나타납니다.
autoCommitOnComplete: true는 주목해야 할 플래그입니다. 작업이 완료되면 Lens는 수동 커밋 단계 없이 결과를 git에 커밋하고, buildBoard: true 설정으로 태스크 보드가 자동으로 최신 상태를 유지합니다. 편리하지만, 무엇이 제거되는지 주목하세요. 작업 완료와 커밋이 히스토리에 기록되는 사이에 검토 게이트가 없습니다. 기록 전에 diff를 검토하고 싶다면, 이 기본값은 불리하게 작용합니다.
capabilityAuditNudge와 capabilityAuditIntervalDays: 30 조합은 Lens가 30일마다 /cr 자기 현대화 감사를 요청하도록 합니다 . 그 프롬프트는 무시할 잡음이 아닌 정기 유지보수 신호로 취급하세요 — 네이티브 Claude Code 또는 Codex 기능으로 대체되었을 수 있는 기능을 Lens가 알리는 방식입니다.
주의가 필요한 조합: v3.14.1에서 Lens 자체 시크릿 제외 필터가 제거되어, Lens는 이제 각 레포지토리의 .gitignore에만 의존해 민감한 파일을 커밋에서 제외합니다 . autoCommitOnComplete: true와 함께 사용하면, .gitignore 누락으로 추적되는 모든 파일이 자동으로 커밋되며, 이를 잡아낼 인간 체크포인트가 없습니다. 이 조합을 활성화하거나 유지하기 전에 .gitignore를 감사하세요 — Lens가 제공하던 안전망은 사라졌습니다.
/cr 감사: Lens가 기능을 KEEP·THIN·OBSOLETE로 분류하는 방식
/cr 명령어는 Lens의 자기 현대화 감사 도구입니다. Lens의 모든 기능을 Claude Code와 Codex의 현재 네이티브 기능과 비교한 뒤 각각 KEEP, THIN, OBSOLETE, UNKNOWN으로 분류합니다 . KEEP은 Lens가 플랫폼 네이티브 기능보다 명확한 가치를 여전히 제공한다는 의미입니다. THIN은 가치가 미미해 단순화할 만하다는 의미입니다. OBSOLETE는 네이티브 도구가 이미 완전히 대체한다는 의미입니다. UNKNOWN은 판단하기에 데이터가 부족하다는 의미입니다. 결과물은 삭제 명령이 아닌 분류 보고서입니다.
비파괴적 설계가 핵심입니다. /cr은 분류된 코드를 자동으로 삭제하지 않도록 의도적으로 설계되었습니다 . 출력은 권고 사항이며, 작성자가 보고서를 검토하고 무엇을 폐기할지 직접 결정합니다. 네이티브 동작을 감싸는 플러그인에서 이 점은 매우 중요합니다. 잘못된 OBSOLETE 판정이 자동으로 실행되면 팀이 의존하는 워크플로우가 삭제될 수 있기 때문입니다.
/cr이 겨냥하는 실질적 문제는 드리프트입니다. Claude Code가 네이티브 슬래시 명령어, MCP 도구 오케스트레이션, LSP 통합 기능을 갖춰감에 따라 한때 Lens를 정당화했던 기능들이 조용히 중복될 수 있습니다. 검토 메커니즘 없이는 그 중복이 데드 코드와 어떤 경로를 써야 하는지에 대한 혼란으로 이어집니다. /cr은 중복이 쌓이기 전에 이를 드러냅니다.
Lens는 이 정리 작업을 주기적으로 스케줄링합니다. lens.config.json에서 capabilityAuditIntervalDays: 30으로 설정하여 매월 /cr 실행을 유도합니다 . 프로젝트 자체가 빠르게 움직이는 점을 고려하면 — 2026년 6월 11일부터 14일 사이에 v3.18 라인을 포함한 마이너 릴리즈가 세 차례 있었습니다 — 빠르게 움직이는 플랫폼 위에 올려진 레이어에는 30일 자가 감사가 합리적인 주기입니다.
핵심은 이렇습니다. Lens는 자신의 유효성을 당연한 것으로 여기지 않고 검증 대상으로 다룹니다. 사용 중이라면 매월의 /cr 알림이 제 역할을 하도록 두고, KEEP/THIN/OBSOLETE 보고서를 읽은 뒤 신중하게 정리하세요. 그것이 네이티브 도구를 감싸는 래퍼가 정리하려 했던 혼잡 자체가 되지 않고 유용함을 유지하는 방법입니다.
자주 묻는 질문
Creeta Lens에서 /cp와 /cpp의 차이는 무엇인가요?
/cp는 일상적인 문서화와 가벼운 계획 작업을 위한 Fast/Standard 계획 단계이고, /cpp는 심층적이고 즉시 구현 가능한 계획 도구입니다. /cpp는 목표를 사전에 고정하고, 6축 팬아웃 리서치를 실행하며, Codex와 의무적으로 협력하고, 완전한 경로/변경/검증 인계 문서를 생성합니다. v3.18.0부터 /cpp에는 단어 수나 길이 제한이 없으므로, 두 명령어는 이제 계획 스펙트럼의 명확히 구분된 양 끝에 위치합니다 — 빠른 문서화와 철저하고 추가 문의 없는 브리핑 (source: cpp SKILL.md).
Creeta Lens는 모든 Claude Code 플러그인과 작동하나요, 아니면 특정 플러그인만 지원하나요?
설치된 플러그인이면 모두 됩니다. Lens는 하드코딩된 플러그인 의존성이 없는 라우터로, 이미 설치된 Skills, MCP 도구, LSP 서버를 스캔하고 작업에 가장 적합한 것을 추천합니다. 유일한 필수 요건은 Claude Code v1.0.33+ 이상과 최소 2개의 설치된 플러그인입니다 . 자체 지원 도구 카탈로그를 제공하지 않고 현재 설치된 것을 오케스트레이션하기 때문에, 10개 이상의 플러그인과 50개 이상의 슬래시 명령어를 실행하는 환경으로도 확장됩니다 (source: README.md).
v3.18에서 /cpp가 정확히 어떻게 바뀌었나요?
v3.18.0 (2026-06-14)에서 /cpp와 HTML 출력의 모든 단어 수 및 길이 제한을 제거하고, 대규모 계획을 위한 슬라이드 수 무제한 task-deep HTML 형식을 도입했습니다. 같은 날 v3.18.1은 Codex service_tier (priority → fast), 릴리즈 가이드 버전 파일 수 (9 → 13), /cpp done-sweep 문서 업데이트, /cpp 하드 게이트와 Codex 그레이스풀 디그레이드 간의 충돌, bump-version 레이블 정규화, upgrade.py dry-run 수정을 포함한 6개의 드리프트 항목을 패치했습니다 (source: CHANGELOG.md).
autoCommitOnComplete=true로 두어도 안전한가요?
.gitignore 관리 상태에 전적으로 달려 있습니다. v3.14.1부터 Lens는 자체 시크릿 제외 필터를 실행하지 않고 각 저장소의 .gitignore에만 의존합니다 . lens.config.json에서 autoCommitOnComplete를 true로 설정하면 작업이 완료될 때 실수로 커밋된 시크릿을 포함한 모든 추적 파일이 자동으로 스테이징 및 커밋됩니다. 이 조합을 사용하기 전에 .gitignore를 감사하고 민감한 파일이 추적되지 않는지 확인하세요 (source: lens.config.json).
Creeta는 Creata AI, Cresta Intelligence, CrewAI와 같은 프로젝트인가요?
아닙니다. Creeta (creeta.com, github.com/livevil7/creeta-lens)는 별개의 프로젝트이자 Lens의 홈입니다. Creata AI는 소비자용 생성형 아트 및 텍스트 앱이고, Cresta는 엔터프라이즈 컨택 센터 AI 회사이며, CrewAI는 오픈소스 멀티 에이전트 오케스트레이션 프레임워크이고, Creta는 web3 게임 플랫폼입니다. 이름은 발음상 유사하지만 각 프로젝트는 기능적으로 전혀 무관합니다.
