jarvis는 사람이 직접 코드를 짜는 동안 곁에서 변경을 지켜보다가, 의미 있는 순간에만 페어 내비게이터 Jarvis를 자동으로 깨우는 워치 루프입니다. 코드는 사람이 쓰고, AI는 관찰자로 머뭅니다.
저자성(authorship)을 보존하는 AI 페어 개발 방식. jarvis는 단순한 자동화 도구가 아니라, 하나의 입장에서 출발합니다 — 개발의 저자는 끝까지 사람이어야 한다.
자비스는 토니 스타크의 능력을 증폭시킵니다. 하지만 슈트를 입고 직접 전투를 수행하고 판단하는 주체는 끝까지 토니입니다 — 자비스에게서 정보와 보조를 받을 뿐, 조종간을 넘기지 않습니다. 자비스는 옆에서 띄워주고, 결정과 행동은 토니가 합니다.
지금의 Coding Agent는 그 반대로 가기 쉽습니다. 자동화 수준이 높아서가 아니라, "내 코드인데 내가 조종석에 없는" 구조 — 사람을 의사결정 루프 밖으로 밀어내는 구조 — 를 만들기 때문입니다.
그래서 이름이 자비스입니다 — 사람을 조종석에 앉혀두는 AI.
설치하고, 재시작하고, 띄우면 끝. 최초 1회 강도(strength)를 물어본 뒤 jarvis는 당신이 코드를 짜는 동안 변경을 지켜보다 의미 있는 순간에만 페어 내비게이터를 깨웁니다. 코드는 절대 직접 고치지 않습니다.
설치 시 언어를 물어봅니다 — 영문 / 한글.
훅과 상태줄은 세션 시작 시 로드됩니다.
끝입니다. 새 변경이 쌓였거나·위험 경로가 바뀌었거나·커밋 경계를 넘었을 때만 Jarvis가 깨어납니다.
루프 인터럽트(Esc)
/loop /jarvis · 저장된 설정 복원
/jarvis-reset
/loop /jarvis로 띄우세요.
/loop 5m /jarvis는 고정 스케줄로 돌아 jarvis의
active /
idle /
strength 페이싱을 무시합니다.
관찰자로서의 리뷰는 허위 메타인지를 만듭니다. 이해가 사람이 아니라 도구 안에 쌓이고, 오류는 이미 커밋된 코드가 되어 누군가 해체해야 합니다.
구현은 사람 손에서 장기 기억으로 남습니다. 기계는 관찰자로 머물며 길을 안내하되, 키보드는 끝까지 사람이 잡습니다.
AI full automation 개발이 빠르게 확산되며 코드 생성의 주체가 사람에서 AI로 이동하고 있습니다. 통상의 "Human in the loop"는 AI가 코드를 생산하고 사람이 이를 검토·승인하는 구조입니다.
이 구조는 개발자의 로직 인지능력과 반대 방향으로 작용합니다. 자동화 사이클이 누적될수록 개발자는 전체 맥락은 알지만 상세 로직에 대한 인지를 잃습니다.
더 위험한 것은, "저자"가 아닌 "관찰자"로서의 리뷰가 "알고 있다"는 착각 — 허위 메타인지(false metacognition) — 을 만든다는 점입니다. 이 맹점은 규모와 변경량이 커질수록 가속됩니다.
맥락을 잃은 개발자는 점점 추상적인 지시만 내리게 되고, AI와의 핑퐁 끝에 결과가 어긋나 처음부터 다시 시작하는 비용이 복리로 쌓입니다.
역할을 뒤집어 Human-in-the-loop이 아닌 Machine-in-the-loop을 만듭니다. 개발의 저자는 사람이고, 기계는 루프 안에서 보조합니다.
사람이 직접 개발하는 것을 기본 원칙으로 하며, AI는 개발 중인 로직을 지속적으로 관찰하며 Review · Navigation · Warning 을 제공하되, 코드에 직접 개입하는 것은 사용자의 요청이 있을 때뿐입니다. 그 외에는 관찰자로 머뭅니다.
결정적으로 Navigation은 정답 구현이 아니라 참고 지식·패턴을 제시합니다 — 보여주되 떠먹이지 않아 저자성을 보존합니다.
사람이 직접 쓰기 때문에 구현 위치와 알고리즘 과정이 길고 구체적인 장기 기억으로 남습니다 — 허위 메타인지의 정반대입니다.
오류 비용도 비대칭입니다. AI의 할루시네이션은 저자가 무시하면 그만이지만, full automation의 오류는 이미 커밋된 코드가 되어 누군가 발견하고 해체해야 합니다. 사람의 착오에는 AI가 적극적으로 경고를 남깁니다.
개발자는 본연의 업무에 더 집중할 수 있고, 블랙박스화된 로직에 대한 불안은 사라집니다.
속도는 하루짜리 작업을 10분으로 줄여주지는 않습니다 — 8시간 걸릴 일을 3~4시간으로, 그러나 꾸준히 유지합니다. 규모가 커지고 변화가 많아져도 컨텍스트 망각·유실이 줄어들어, 우리는 AI에게 항상 명확한 지시를 줄 수 있습니다.
그리고 개발자는 자신의 코드에 책임질 수 있습니다.
Jarvis가 사람에게 주는 것은 셋뿐입니다. 공통점은 — 모두 안내이지 생산이 아니라는 것.
"이 부분이 빠진 것 같아"
"이 로직이 더 효율적일 거야"
"다음엔 이걸 하면 될 것 같아"
폴링 자체는 git diff 한 번이라
토큰을 거의 쓰지 않습니다. 비싼 Jarvis 리뷰는 직전 리뷰 이후 새 변경이 쌓였거나·위험 경로가 바뀌었거나·커밋 경계를 넘었을 때만 돌려
토큰 소비를 최소화합니다.
매 wake마다 working tree 변경 라인 수, 위험 경로 변경, 현재 HEAD를 잰다. 토큰 거의 0.
새 커밋이 생겼나? 변경을 되돌렸나? 마커(.jarvis/baseline)와 비교해 자동 보정.
새 변경·위험·커밋 경계 중 하나라도 충족하면 리뷰 대상. 단 대화 중이면 보류하고, 멎으면 누적분을 한 번에 flush.
변경 파일의 AGENTS.md·README·경로별 rules를 모아 맥락으로 넘기고 Jarvis를 호출. 결과는 마커로 감싼다.
ScheduleWakeup으로 다음 실행 간격을 스스로 정한다. /loop의 self-paced 모드 위에서 돈다 — /loop /jarvis로 띄운다.
직전 리뷰 이후 새 변경이 쌓이면(분량 무관 — 고정 라인/파일 임계값 없음) 리뷰. 한 번 리뷰한 변경은 다시 발동하지 않고 새로 쌓일 때만 본다. 사람이 직접 무언가 쓴 뒤에야 AI가 등장.
결제·로그인 같은 위험 경로는 분량과 무관하게 단 한 줄만 바뀌어도 즉시 경고. "작지만 치명적"을 놓치지 않는다.
새 커밋이 감지되면 변경 누적과 무관하게 1회 점검. 착오가 코드로 봉인되기 직전이 경고의 골든타임.
실시간 대화 중에는 리뷰를 미뤘다가, 대화가 멎으면 그때 누적분을 한 번에. 흐름을 끊지 않는다.
변경 파일의 가장 가까운 AGENTS.md·디렉토리 README·경로별 팀 rules를 모아 Jarvis에 주입. "이 패키지 규칙"까지 알고 리뷰.
/loop /jarvis로 띄우면 ScheduleWakeup이 다음 간격을 스스로 정해 추가 입력 없이 계속 감시한다.
빈 persona.md를 채워 Jarvis가 누구처럼, 무엇에 예민하게 볼지 정한다. 두루뭉술한 보편 맥락이 아니라 내 손에 맞춘 navigation.
.claude/jarvis/focus/에 "이 프로젝트에서 특히 봐야 할 것"을 모아두면, 일반 카탈로그보다 우선 렌즈로 본다.
누적 변경의 상당 부분이 생성된 코드면 "직접 파악했는지" 한 줄로 비춘다. 막지도 고치지도 않고 거울만 — 책임이 눈 뜨게.
선택적으로 소스(Jira / Confluence / Notion / 문서 / 직접 작성)를 승인한 계획 + 체크리스트로 만들면, 이후 게이트 리뷰마다 코드를 체크리스트에 대고 점검한다 — 항목별로 뭐가 빠졌나, 어떤 게 거짓 "완료"인가. 계획 저작과 순서는 사람이, jarvis는 초안·추천만. 완전 옵트인.
AI가 자동 생성한 리뷰는 일반 대화와 시각적으로 구분됩니다. 마커 사이가 Jarvis의 말, 바깥은 워치의 운영 메시지. 끝 문구가 매번 저자성을 상기시킵니다.
첫 /loop /jarvis에서 — 강도 질문 앞에 —
"이 작업의 계획 + 체크리스트를 만들까요?"를 묻습니다. 아니오면 아무것도 바뀌지 않고,
예면 이후 게이트 리뷰마다 코드를 당신이 승인한 체크리스트에 대고 점검합니다.
Jira 티켓, Confluence / Notion 페이지, 기존 문서 — 또는 직접 작성. (Jira/Confluence는 Atlassian MCP 필요; 없으면 문서 경로나 직접 불러주기로 폴백.)
jarvis-plan이 계획 + 상세 체크리스트를 초안으로 잡습니다. 당신이 편집·재배열·덜기·더하기 하고 승인하면, 그때 .jarvis/에 기록됩니다.
게이트 리뷰마다 항목별로 뭐가 빠졌나, 체크했지만 코드가 뒷받침하지 않는 항목을 짚습니다. 상태줄에 · plan 3/7. 전 항목 완료로 보이면 최종 리뷰 — 그리고 종료를 추천하면 당신이 확정합니다.
/loop /jarvis strength=high risk=**/*payment* debounce=90s
⚠️ /loop에 간격을 직접 주지 말 것. /loop /jarvis처럼 간격 없이 띄워야 self-pace로 돌아 active/idle/strength args가 ScheduleWakeup으로 주기를 몬다. /loop 5m /jarvis는 고정 스케줄로 돌아 이 args를 무시한다.
| 키 | 의미 | 기본값 |
|---|---|---|
strength | 강도 프리셋 — 아래 폴링 간격 노브들을 묶어 세팅 (low/medium/high) | medium |
risk | 위험 경로 glob — 분량 무관 즉시 경고 | off |
debounce | 대화가 멎었다고 볼 정지 시간 | 90s |
active | 워킹트리에 변경 있음 / 리뷰 직후 wake 간격 | 4m |
idle | 워킹트리 깨끗할 때 wake 간격 | 25m |
warmup | 첫 로드 빠른 폴링 tick 수 | 3 |
paths | 감시 대상 경로 한정 | 전체 |
focus | 집중 영역 디렉토리 — 우선 렌즈로 보는 문서 모음 | .claude/jarvis/focus/ |
mirror | gray zone 거울 — 생성 코드 과다 시 한 줄 메모 (비강제) | on |
plan | 계획 모드 — 첫 부팅에 질문; off로 건너뛰거나, 소스(plan=PROJ-1, URL, 경로)를 주면 곧장 옵트인 | 부팅 시 질문 |
“AI 서비스가 멈춰 있는 몇 시간 동안,
우리의 작업도 멈춰 있어야 합니까?”
full automation에 깊이 기댈수록 그 몇 시간 동안 우리는 아무것도 하지 못합니다 — 이해가 사람이 아니라 도구 안에 쌓여 있기 때문입니다. 도구가 잠시 사라져도 흔들림 없이 손을 움직이려면, 코드에 대한 이해는 도구 안보다 우리 안에 더 많이 쌓여 있어야 하지 않을까요?
jarvis는 그 질문에 대한 하나의 대답입니다.