왜 2부인가 — '딸깍'의 한계
1부의 방식으로도 사이트는 만들어집니다. 하지만 쓰다 보면 세 가지 벽에 부딪힙니다. 이 벽을 넘는 도구가 2부의 내용입니다.
매번 처음부터
AI는 어제 한 일을 오늘 모릅니다. 같은 설명을 매번 반복하게 됩니다.
믿을 수가 없다
그럴듯하게 지어냅니다. "됐다"는 말과 실제로 된 것 사이의 간격.
손발이 짧다
화면만 만들 뿐, 우리 자료를 읽거나 다른 서비스와 이어지지 못합니다.
하네스 복습 — 작업장의 네 기둥
하네스(harness)는 원래 말에 채우는 마구입니다. 말이 아무리 힘이 세도 마구 없이는 수레를 못 끕니다. AI도 같습니다. 모델은 엔진이고, 하네스는 그 엔진을 실제 일에 연결하는 장치 전부. 기둥은 넷입니다.
지시문
매번 지켜야 할 원칙. 내가 누구고, 어떤 말투를 원하고, 뭘 하면 안 되는지.
기억
지난 작업의 맥락 유지. 대화가 끝나면 잊으니, 기록이 이어줘야 한다.
도구·재료
AI가 직접 손발을 쓰게 함. 우리 자료를 읽고, 다른 서비스와 잇는다.
검증
결과를 믿기 전에 확인. '됐다'는 말이 아니라 결과물로 확인하는 습관.
부품 다섯 — 어려운 이름을 쉬운 말로
2부 예고에 나온 이름들(MD·스킬·커넥트·API·에이전트)은 무섭게 들리지만, 하네스의 네 기둥을 더 튼튼하게 만드는 부품일 뿐입니다. 하나씩 쉬운 말로 풉니다. 각 부품 아래 초록 칸은 우리(품앗이)가 실제로 그 부품을 어떻게 쓰는지입니다.
MD — AI가 매번 읽는 사용설명서
MD는 .md로 끝나는 글 파일입니다. 그중 특별한 한 장이 지시문 파일 —
도구마다 이름이 다릅니다. 클로드 코드는 CLAUDE.md, 코덱스는 AGENTS.md, 제미나이는 GEMINI.md.
AI가 대화를 시작할 때마다 자동으로 읽는 헌법 같은 파일입니다. 여기에 원칙을 적어두면 매번 설명할 필요가 없습니다.
CLAUDE.md에 '조사 없이 발언 없다',
'데이터 먼저', '거짓말 금지' 같은 레드라인이 적혀 있습니다. 실수할 때마다 한 줄씩 늘어납니다 — 실수 기록이 지시문이 되는 순환.스킬 — 자주 하는 일을 '기술'로 굳히기
매번 똑같이 설명하는 작업이 있다면(예: "이 문서를 이런 형식으로 위키에 올려줘"), 그 절차를 한 번 정리해 이름 붙인 기술로 저장해 둘 수 있습니다. 다음부터는 이름만 부르면 그 절차대로 움직입니다.
말하자면 요리 레시피 카드입니다. 매번 재료와 순서를 설명하지 않고 "그 레시피대로" 하면 되는 것.
배포, 지원사업, 위키 발행 같은 스킬이 있습니다.
"이 문서 위키에 올려"라고만 하면 등급 격리·검증·링크 회신까지 정해진 절차가 한 번에 돕니다.커넥트(MCP) — AI를 다른 서비스에 잇는 콘센트
커넥트는 AI를 바깥 서비스에 이어주는 표준 콘센트입니다. 전문 용어로 MCP라고 부릅니다. 이걸 꽂으면 AI가 채팅창을 넘어 실제로 우리 데이터베이스를 읽고, 메일을 확인하고, 일정을 봅니다.
1부에서 클로드 코드에 GitHub를 연결(커넥트 버튼)했던 게 바로 이것입니다.
API — 프로그램이 서로 이야기하는 창구
API는 서비스끼리 정해진 방식으로 정보를 주고받는 창구입니다. 사람이 화면을 클릭하듯, 프로그램은 API로 요청하고 답을 받습니다. "이 우편번호의 날씨 줘" 같은 요청을 프로그램이 직접 보내는 것.
커넥트가 표준 콘센트라면, API는 그 콘센트 너머의 개별 창구입니다. 1부의 Supabase '열쇠(키)'가 바로 이 창구를 여는 열쇠였습니다.
에이전트 — 만드는 AI와 검사하는 AI
에이전트는 특정 일을 맡아 스스로 처리하는 작은 AI입니다. 핵심은 하나가 아니라 여럿을 나눠 쓰는 것 — 특히 만드는 AI(maker)와 검사하는 AI(checker)를 따로 두는 방식입니다. 만든 쪽이 제 숙제를 채점하면 후하게 주니까, 검사는 다른 쪽에 맡깁니다.
함정도 있습니다. 아무 일이나 자동으로 떠넘기면 통제를 잃고 비용도 폭발합니다. 무엇을 맡길지는 사람이 고릅니다 — 이 원칙이 다음 장으로 이어집니다.
루프 — 부품이 모이면 스스로 도는 작업장
하네스가 '에이전트 한 명의 작업장'이라면, 루프는 그 한 층 위입니다. 타이머로 스스로 돌고, 필요하면 보조 에이전트를 낳고, 자기 일감을 스스로 찾아 먹는 자동으로 도는 작업장. 애디 오스마니는 이걸 '루프 엔지니어링'이라 부르며 부품 여섯을 꼽습니다. 우리는 그중 다섯 반을 이미 갖췄습니다.
자동 실행
정해진 때에 스스로 도는 타이머.
보유격리 작업대
서로 안 부딪히게 따로 만드는 작업 공간.
보유(강화 여지)스킬
이름 붙인 반복 절차.
보유커넥트
바깥 서비스로 잇는 콘센트(MCP).
보유맡은 에이전트
만드는 AI ↔ 검사하는 AI.
보유디스크 기억
대화를 넘어 남는 기록·업무일지.
보유그런데 — 무인 루프는 일부러 돌리지 않는다
부품이 다 있으니 스위치만 켜면 AI가 사람 없이 종일 스스로 일하게 만들 수 있습니다. 기술적으로는 가능합니다. 그런데 우리는 검토 끝에 그렇게 하지 않기로 정했습니다. 이유가 있습니다.
무인 재귀의 세 가지 함정
- 검증 붕괴 — AI가 만든 걸 AI가 검사하며 빠르게 돌면, 아무도 안 본 결과가 쌓입니다.
- 이해 부채 — 결과만 받고 과정을 안 겪으면, 정작 문제가 터졌을 때 손을 못 댑니다.
- 인지 투항 — 판단을 기계에 넘기는 게 편해지면, 사람이 생각하기를 멈춥니다.
그래서 우리가 택한 형태는 '무인 실행'이 아니라 반자동 트리아지(triage) 루프입니다. 트리아지는 응급실에서 환자를 급한 순서로 분류하는 말입니다. 즉 — 발견하고 분류하는 데까지만 AI가 자동으로, 판단하고 실행하는 것은 반드시 사람이.
AI가 발견 → 판단 → 실행 → 다시 발견을 사람 없이 반복. 빠르지만, 아무도 안 본 결정이 세계에 나간다.
AI가 발견·분류까지만 자동으로. "이건 급함, 저건 나중"까지 정리해 사람 앞에 놓는다. 결정 버튼은 사람이 누른다.