Claude Code 자동화 용어 정리 2026 — Triage·Compound·LLM Wiki·Harness를 어디에 써야 안 겹칠까

Posted on by

Claude Code 자동화를 조금만 깊게 파기 시작하면 용어가 갑자기 우르르 몰려온다.

Triage, Compound, LLM Wiki, Harness.

처음 보면 다 그럴싸하다.

문제는 다 그럴싸해서 전부 한 프로젝트에 다 넣고 싶어진다는 거다.

그러다 보면 시스템은 똑똑해지는 게 아니라 그냥 레이어가 겹치기 시작한다.

분류기가 위키 흉내를 내고, 위키가 실행기를 흉내 내고, 하니스가 메모장 역할까지 떠안는다.

결국 자동화는 늘었는데 운영은 더 피곤해진다.

직접 굴려보니 이 네 단어는 같은 범주의 멋있는 말이 아니라, 서로 다른 문제를 해결하는 서로 다른 레이어에 가깝다.

이 글은 그 구분을 한 번에 정리하려는 메모다.

개념 설명만 하는 글은 아니다.

Claude Code 기반으로 볼트 자동화, 블로그 운영, 하네스, 위키, 액션보드를 실제로 붙여보면서 느낀 기준으로 언제 무엇을 쓰고, 언제는 안 써도 되고, 어디서부터 오버엔지니어링 냄새가 나는지 정리해보겠다.

Quick Answer
Triage는 유입을 나누는 입구 레이어고, Compound는 반복하면서 점점 좋아지게 만드는 누적 레이어고, LLM Wiki는 읽기 좋은 지식 레이어고, Harness는 실행을 안정화하는 런타임 레이어다.
네 개는 비슷한 자동화 용어가 아니라 서로 맡는 일이 다르다.
혼자 쓰는 자동화라면 대개 Harness + 약한 Triage만 있어도 충분하고, 문서가 쌓여서 다시 꺼내 쓰기 힘들어질 때 LLM Wiki를 붙이고, 같은 판단을 계속 반복해서 개선하고 싶을 때 Compound를 붙이는 순서가 덜 망한다.

오늘 막 나온 운영 글로 이어보면 세션·실행 쪽은 Claude Code 세션을 갈아탈 때 꼭 남겨야 할 로그는 무엇일까 2026 — handoff 최소셋 가 바로 붙고, 지식 축은 짧은 AI 뉴스 메모를 나중에 운영 허브로 키우는 가장 쉬운 방법 2026 — 메모와 가이드 분업 설계 가, 출고 게이트는 AI가 만든 PDF를 바로 배포하면 왜 사고가 나나 2026 — 검수·버전·저작권 체크리스트 가 제일 잘 이어진다.

이런 상황이면 이 글이 잘 맞는다

  • Claude Code 자동화 관련 글을 읽을수록 용어가 더 헷갈리는 사람
  • 새 개념이 보일 때마다 다 적용하고 싶어지는 사람
  • 지금 만든 자동화가 왜 자꾸 중복되는지 감이 안 오는 사람
  • 분류, 축적, 실행, 위키가 어디서 갈리는지 알고 싶은 사람
  • 팀 문서나 개인 second brain에 어느 레이어부터 붙여야 할지 고민하는 사람
  • 멋있는 구조보다 실제로 덜 피곤한 구조가 궁금한 사람

지금 결론

먼저 아주 짧게 정리하면 이렇다.

  1. Triage는 들어오는 것을 분류한다.
  2. Compound는 반복되는 판단을 누적해서 더 좋아지게 만든다.
  3. LLM Wiki는 다시 읽고 다시 쓰기 좋은 compiled knowledge를 만든다.
  4. Harness는 자동화가 실제로 덜 죽고 덜 흔들리게 만든다.
  5. 네 개를 한 번에 넣는 것보다, 지금 프로젝트가 어디서 아픈지 보고 한 겹씩 올리는 게 맞다.

한 줄로 줄이면 이거다.

입구 문제면 Triage, 복리 문제면 Compound, 읽기 문제면 LLM Wiki, 실행 문제면 Harness다.

왜 자꾸 다 같은 말처럼 들릴까

이 네 단어는 전부 AI 자동화 글 주변에 등장한다.

게다가 다들 살짝 멋있게 들린다.

  • 더 체계적일 것 같고
  • 더 자동화될 것 같고
  • 더 오래 굴러갈 것 같고
  • 더 AI Native해 보인다

그래서 묶여 보인다.

근데 실제 역할은 많이 다르다.

문제를 잘게 나눠보면, 자동화에서 자주 아픈 구간은 대략 네 가지다.

아픈 지점 실제 문제 맞는 레이어
입력이 뒤죽박죽 들어온다 무엇부터 처리할지 모름 Triage
같은 판단을 매번 새로 한다 이전 교훈이 쌓이지 않음 Compound
자료는 많은데 다시 꺼내 쓰기 어렵다 읽기 좋은 지식층이 없음 LLM Wiki
자동화가 자꾸 끊기고 재현이 안 된다 실행 환경과 복구 루프가 약함 Harness

이 표만 잡혀도 훨씬 덜 헷갈린다.

문제는 사람 마음이 늘 이렇다는 거다.

분류가 필요해도 위키부터 만들고 싶고, 실행이 불안정해도 멋있는 지식 레이어부터 붙이고 싶다.

시스템은 보통 여기서 살짝 꼬인다.

직접 붙여보니 어디서 가장 많이 겹쳤나

내가 실제로 많이 꼬였던 지점은 세 군데였다.

1. 인박스 분류기가 갑자기 위키 흉내를 낼 때

처음엔 단순히 이건 글감, 이건 운영 이슈, 이건 참고자료 정도만 나누면 될 일인데, 입구 단계에서 자꾸 설명을 더 붙이고 싶어진다.

그러면 triage 문서가 갑자기 mini wiki가 된다.

분류는 빨라야 하는데, 설명을 늘리기 시작하면 입구가 병목이 된다.

여기서 느낀 건 단순했다.

입구는 짧고 거칠어도 괜찮고, 대신 읽는 층은 따로 만들어야 한다.

2. 위키가 좋아지면 실행 계층까지 품고 싶어질 때

LLM Wiki를 만들다 보면 주제 허브에 규칙도 적고 싶고, 체크리스트도 적고 싶고, 실행 명령도 같이 붙이고 싶어진다.

이게 한두 번은 편하다.

근데 나중엔 위키 문서가 설명서인지, 운영 규칙인지, 실행 문서인지 구분이 안 간다.

그 순간부터 수정이 느려진다.

위키는 어디까지나 읽기 쉬운 compiled knowledge까지가 가장 예쁘다.

실행은 하니스나 별도 운영 문서에 두는 편이 훨씬 덜 꼬였다.

3. 하니스가 강해지면 모든 문제를 코드로 해결하고 싶어질 때

이건 진짜 자주 온다.

daily sync 한 번 멈추고, townhall 한 번 stale 나고, publish contract 한 번 timeout 나면 갑자기 모든 걸 하니스 코드로 해결하고 싶어진다.

근데 실제로는 실행 안정성 문제와 지식 정리 문제와 운영 학습 문제를 같은 파이썬 파일에 몰아넣는 순간 더 무거워진다.

내 경험상 하니스는 실행과 복구에만 욕심낼 때 제일 쓸모 있었다.

똑똑한 하니스보다 덜 죽는 하니스가 훨씬 낫다.

1. Triage는 무엇인가

내 기준에서 Triage는 들어오는 것을 우선순위와 라벨로 나누는 입구 작업이다.

즉 자동화의 첫 번째 문지기다.

여기서 하는 일은 대체로 이런 거다.

  • 인박스 메모를 분류한다
  • 어떤 채널로 보낼지 고른다
  • 즉시 액션인지 나중에 검토인지 정한다
  • 버릴 것과 살릴 것을 나눈다
  • 다음 팀으로 넘길 핸드오프를 만든다

중요한 건 Triage는 무언가를 깊게 이해하는 레이어가 아니라는 점이다.

여기서는 길게 생각하지 않는다.

빨리 나누고, 빨리 태깅하고, 빨리 다음 단계로 넘기는 게 핵심이다.

직접 굴릴 때 Triage가 유용한 구간

내 볼트 기준으로는 이런 상황에서 Triage가 제일 빛났다.

  • 00.Inbox에 URL 요약, 생각 메모, 글감이 섞여 들어올 때
  • 블로그 아이디어를 TAEK2 / 배당노마드 / TECHTAEK로 갈라야 할 때
  • 액션 보드에서 verify, refresh, new를 분기해야 할 때
  • 아이디어는 많은데 오늘 당장 뭘 칠지 골라야 할 때

즉 Triage는 생산성 앱의 예쁜 폴더 놀이가 아니라, 운영 병목을 줄이는 입구 정리다.

Triage가 아닌 것

여기서 자주 생기는 오해가 있다.

Triage는 위키가 아니다.

그래서 이런 걸 기대하면 안 된다.

  • 주제를 깊게 설명해주기
  • 장기 기억처럼 누적되기
  • 프로젝트 전체 맥락을 정리해주기
  • 실행 안정성을 책임지기

Triage는 잘해봐야 분류는 잘하는 비서다.

박사도 아니고, 운영총괄도 아니다.

2. Compound는 무엇인가

여기서 말하는 Compound는 복리라는 일반 단어가 아니라, 반복할수록 시스템이 조금씩 더 좋아지게 만드는 누적 구조 정도로 이해하면 된다.

핵심은 한 번 잘하는 게 아니라 매번 조금씩 덜 바보처럼 하게 만드는 것이다.

예를 들면 이런 패턴이다.

  • 실패 사례를 다음 체크리스트에 반영한다
  • 이번 주에 먹힌 제목 구조를 다음 글감팀이 참고한다
  • 검증팀이 찾은 패턴을 운영 위키에 넣는다
  • 발행 후 성과를 보고 다음 파생글을 만든다

즉 Compound는 하나의 작업이 아니라 교훈이 다음 실행에 먹히게 만드는 루프에 가깝다.

직접 굴릴 때 Compound가 유용한 구간

내 쪽에서는 이런 데서 효과가 컸다.

  • 수익이 나온 글을 분석해서 파생글 3개로 늘릴 때
  • verify > refresh > hub_expand > new 우선순위를 반복 보정할 때
  • 발행 실패, 링크 깨짐, 캐시 꼬임 같은 실수를 위키에 누적할 때
  • 분석팀이 숫자를 보고 끝내지 않고 winner_expand로 번역할 때

이건 말 그대로 복리 구조다.

한 번의 리포트보다 다음 액션으로 번역되는 운영 습관이 중요하다.

Compound가 아닌 것

Compound도 자주 과대평가된다.

이건 자동 실행기가 아니다.

그냥 회고 노트 몇 개 쌓인다고 Compound가 되는 것도 아니다.

아래면 아직 Compound라기보다 기록에 가깝다.

  • 실패를 적기만 하고 다음 스텝이 안 바뀜
  • 숫자는 보는데 파생글이 안 나옴
  • 팀은 회고하는데 시스템은 그대로임
  • 실험 로그가 있는데 플레이북이 안 생김

Compound는 노트의 양이 아니라 다음 행동의 변화로 판별해야 한다.

3. LLM Wiki는 무엇인가

LLM Wiki는 raw source를 버리지 않으면서 사람과 모델이 다시 읽기 쉬운 compiled knowledge layer를 만드는 방식이다.

이건 검색 인프라보다 앞단의 읽는 표면에 가깝다.

쉽게 말하면 이런 식이다.

  • 원문 클립은 그대로 둔다
  • 주제별 허브 문서를 만든다
  • 자주 나오는 개념을 읽기 좋은 페이지로 정리한다
  • LLM과 사람이 같은 진입점을 보게 만든다

그래서 LLM Wiki는 지식 정리의 문제를 푼다.

실행 안정성의 문제를 푸는 건 아니다.

직접 굴릴 때 LLM Wiki가 빛나는 구간

내 기준으로는 이런 때였다.

  • inbox 자료는 많은데 같은 주제를 매번 다시 요약할 때
  • 에이전트/하니스/위키/운영 철학이 여러 프로젝트에 걸쳐 반복될 때
  • raw source는 살아 있는데 읽는 레이어가 없어서 회수율이 떨어질 때
  • RAG 붙이기엔 아직 너무 이르고, 그냥 허브 품질이 더 시급할 때

예를 들어 LLM Wiki, Harness, Claude Code 운영 같은 주제는 raw source만으로는 다시 꺼내 쓰기 어렵다.

이때 compiled page가 하나씩 있으면 사람도 덜 헤매고, 에이전트도 덜 헤맨다.

LLM Wiki가 아닌 것

LLM Wiki는 실행기가 아니다.

그래서 아래는 기대하면 곤란하다.

  • 자동 재시도
  • 헬스체크
  • 실패 복구
  • 승인 경계
  • 런타임 모니터링

위키는 똑똑한 책장이지, 발전기나 UPS가 아니다.

책장이 예쁘다고 서버가 덜 죽지는 않는다.

4. Harness는 무엇인가

Harness는 내가 가장 자주 과소평가했다가, 나중엔 제일 자주 고맙다고 느낀 레이어다.

정리하면 자동화가 실제로 계속 돌 수 있게 받쳐주는 실행 계층 이다.

여기엔 보통 이런 게 들어간다.

  • 실행 명령
  • 상태 저장
  • 실패 감지
  • 자동 재시작
  • 헬스체크
  • 로그
  • 폴백
  • 권한 경계

즉 Harness는 멋있는 개념이라기보다 운영의 잡일을 대신 떠안는 몸통이다.

직접 굴릴 때 Harness가 빛나는 구간

내 쪽에서는 이런 순간에 하니스가 제값을 했다.

  • daily sync가 한동안 stale돼 있었는데 다시 살려야 할 때
  • 발행 파이프라인에서 글은 올라갔는데 계약 마감이 timeout으로 삐끗할 때
  • townhall, revenue weekly, dashboard sync처럼 주기적 갱신이 필요한데 사람이 매번 확인하기 싫을 때
  • long-running automation이 중간에 죽어도 상태를 이어야 할 때

한마디로 실행이 아픈 구간은 거의 Harness 문제였다.

문서를 잘 써도, 지식이 많아도, 입구 분류가 좋아도, 하니스가 약하면 시스템은 결국 사람 손을 다시 찾는다.

Harness가 아닌 것

하니스도 만능은 아니다.

이건 지식 정리 도구가 아니다.

그래서 이런 걸 맡기면 무거워진다.

  • 개념 설명까지 하려는 하니스
  • 플레이북까지 품은 하니스
  • 위키 역할도 하는 하니스
  • 분류와 판단까지 다 떠맡는 하니스

하니스가 과해지면 코드는 많아지고 읽기는 더 어려워진다.

진짜 흔한 실패가 이거다.

불안하니까 일단 다 하니스에 넣자

그러면 하니스가 자동화 런타임이 아니라 거대한 만능 주머니가 된다.

그 순간부터는 수정도 무섭고 복구도 느려진다.

어디에 무엇을 쓰나: 실전 매핑표

이 부분이 사실 제일 중요하다.

개념을 외우는 것보다 어디에 쓸지 고르는 게 더 중요하니까.

상황 먼저 볼 레이어 이유 그다음 후보
인박스가 지저분하다 Triage 무엇부터 처리할지 모름 Compound
매번 같은 실수를 반복한다 Compound 교훈이 다음 실행에 안 먹힘 LLM Wiki
자료는 많지만 다시 못 꺼내 쓴다 LLM Wiki 읽기 좋은 compiled layer가 없음 Triage
자동화가 자꾸 끊긴다 Harness 실행 안정성 문제 Triage
팀이 같은 용어를 다르게 쓴다 LLM Wiki 공통 정의 문서가 필요 Compound
운영 루프는 있는데 우선순위가 매번 바뀐다 Triage 입구 분기 기준이 약함 Compound
실행은 되는데 사람마다 결과 편차가 크다 Harness 환경/권한/복구가 들쭉날쭉 LLM Wiki

이 표에서 포인트는 하나다.

아픈 곳을 봐야지, 멋있어 보이는 곳을 보면 안 된다.

보통은 어떤 순서가 덜 망하나

혼자 또는 작은 팀이 Claude Code 자동화를 만들 때는 대체로 이 순서가 무난했다.

1단계: 약한 Triage

일단 들어오는 걸 나눈다.

  • 뭐가 글감인지
  • 뭐가 운영 이슈인지
  • 뭐가 그냥 참고자료인지

입구가 안 정리되면 나머지는 다 고생한다.

2단계: 얇은 Harness

그다음 실행 루프를 안정화한다.

  • 상태 저장
  • 실패 감지
  • 재실행
  • 기본 로그

여기까지가 되어야 자동화가 사람한테 자꾸 울지 않는다.

3단계: LLM Wiki

자료가 누적되고 반복 질문이 생기면 그때 읽기 좋은 지식층을 붙인다.

이 타이밍이 중요하다.

너무 빨리 붙이면 빈 위키만 늘어나고, 너무 늦게 붙이면 같은 설명을 백 번 하게 된다.

4단계: Compound

그리고 어느 정도 운영 데이터가 모이면 실수, 성과, 승자 패턴을 다음 실행에 반영한다.

이제부터 복리가 붙는다.

즉 내 경험상 Triage -> Harness -> LLM Wiki -> Compound 순서가 가장 덜 아팠다.

물론 프로젝트마다 다르다.

하지만 최소한 Compound부터 하자 혹은 위키부터 거대하게 깔자 보다 훨씬 안전했다.

언제는 아예 안 붙여도 되나

이 부분도 꽤 중요하다.

새 개념을 이해하면 보통 다음 반응이 그럼 나도 이거 붙여야겠네 로 가는데, 실전에서는 안 붙이는 게 정답인 구간도 많다.

상황 굳이 안 붙여도 되는 것 이유
혼자 쓰는 작은 자동화 Compound 배운 걸 누적할 만큼 반복량이 아직 적음
자료가 아직 20~30개 수준 LLM Wiki 허브보다 원자료 자체가 아직 적음
하루 한두 번만 도는 가벼운 스크립트 무거운 Harness 실패 복구보다 단순 재실행이 더 쌈
인박스 유입이 거의 없는 프로젝트 Triage 입구보다 실행/출력 설계가 더 중요함

이걸 반대로 읽으면 기준이 보인다.

규모가 아직 작으면 레이어도 얇게 가라

이건 멋없어 보여도 꽤 중요한 원칙이다.

자동화는 초반에 과하게 설계하면 대부분 사람이 시스템을 돌보는 일이 더 많아진다.

시스템이 사람을 덜 부르게 만들어야 하는데, 거꾸로 사람을 더 부르면 진 거다.

1인 운영 기준 최소 조합 추천

혼자 Claude Code 자동화를 굴리는 사람 기준으로는 대개 이 셋 중 하나면 충분하다.

상황 추천 조합 이유
인박스가 많고 실행은 단순함 약한 Triage + 얇은 Harness 일단 분류와 실행 안정화만 잡아도 체감이 큼
자료 회수가 안 되고 같은 설명을 반복함 Triage + LLM Wiki 입구와 읽기층을 분리하면 회수율이 올라감
이미 여러 루프가 돌고 있고 같은 실수를 반복함 Harness + Compound 실행 기록이 다음 액션으로 이어질 기반이 생김

이 조합표가 왜 중요하냐면, 네 개를 다 이해했다고 네 개를 다 설치할 필요는 없다는 걸 보여주기 때문이다.

실무에선 보통 하나 잘 붙이는 것이 네 개 어설프게 붙이는 것보다 낫다.

다 쓰려다 생기는 문제

여기서부터가 진짜 실전이다.

이론상 네 개 다 좋다.

문제는 실제 운영은 시간이랑 집중력이 유한하다는 거다.

전부 다 넣으면 보통 아래 중 하나가 터진다.

1. 관리 포인트가 너무 많아진다

입구 분류 규칙도 관리해야 하고, 위키도 갱신해야 하고, 하니스도 고쳐야 하고, 회고 루프도 돌려야 한다.

이건 잘 굴러갈 때야 멋있다.

바쁠 때는 바로 지옥문 연다.

2. 레이어 경계가 무너진다

가장 흔한 증상은 이거다.

  • triage 문서가 플레이북처럼 길어진다
  • wiki가 실행 규칙까지 품는다
  • harness가 지식베이스 역할까지 한다
  • compound 메모가 아무데도 반영되지 않는다

결국 각자 뭘 해야 하는지 모르겠는 시스템이 된다.

3. 설명이 아니라 종교가 된다

AI 자동화 글은 종종 이쪽으로 샌다.

새 개념이 나오면 이제 이것만 붙이면 된다 같은 분위기가 생긴다.

근데 실전은 훨씬 촌스럽다.

어떤 팀은 triage만 있어도 충분하고, 어떤 팀은 harness만 고쳐도 문제가 다 풀린다.

네 개를 다 붙여야 한다는 말은 보통 멋은 있는데 운영 냄새는 약하다.

내가 실제로 느낀 귀찮은 지점

Triage의 귀찮음

너무 세밀하게 설계하면 분류 자체가 일거리가 된다.

입구에서 너무 똑똑해지려 하면 오히려 속도가 느려진다.

입구에서는 70점만 맞아도 된다.

Compound의 귀찮음

누적은 멋있는데 진짜 누적되려면 다음 액션으로 번역돼야 한다.

여기서 대부분 멈춘다.

회고는 했는데 습관은 안 바뀌는 거지.

그래서 Compound는 개념보다 운영 discipline이 더 어렵다.

LLM Wiki의 귀찮음

위키는 만들 땐 재밌는데 업데이트가 끊기면 stale shelf가 된다.

즉 만든 것보다 계속 읽히게 유지하는 게 더 어렵다.

Harness의 귀찮음

하니스는 티가 안 난다.

안 죽으면 아무도 칭찬 안 하고, 죽으면 갑자기 다 쳐다본다.

즉 보람보다 귀찮음이 먼저 오는 레이어다.

근데 웃기게도 가장 실무적인 가치도 여기서 많이 나온다.

실수 TOP 5

1. 개념을 문제보다 먼저 고르는 실수

프로젝트가 어디서 아픈지 안 보고 그냥 멋있는 용어부터 골라 붙이는 경우다.

이건 거의 항상 돈도 시간도 같이 샌다.

2. Triage를 만능 판단기로 만드는 실수

입구 분류기는 빠르게 나눠야지 깊게 설명하기 시작하면 바로 무거워진다.

3. LLM Wiki를 RAG 대체품처럼 보는 실수

위키는 읽기 좋은 지식층이지 모든 retrieval 문제의 만병통치약은 아니다.

4. Harness에 모든 걸 집어넣는 실수

하니스는 실행 안정화를 맡아야지 정의서, 플레이북, 분류 규칙까지 다 품으면 금방 비대해진다.

5. Compound를 그냥 회고 메모라고 착각하는 실수

누적은 기록이 아니라 다음 루프가 바뀌는 것까지 포함해야 한다.

아주 간단한 선택 질문 4개

지금 네 프로젝트에 무엇이 먼저 필요한지 모르겠다면 아래 네 질문만 보면 된다.

  1. 들어오는 게 너무 많아서 뭘 먼저 해야 할지 모르나
  2. 같은 실수를 계속 반복하나
  3. 자료는 많은데 다시 꺼내 쓰기가 어렵나
  4. 자동화가 자꾸 끊기거나 재현이 안 되나

답이 1이면 Triage, 2면 Compound, 3이면 LLM Wiki, 4면 Harness를 먼저 보면 된다.

보통은 한 프로젝트의 주증상이 하나 먼저 튄다.

그걸 잡고 나서 다음 레이어를 붙이는 게 맞다.

FAQ

Triage랑 LLM Wiki를 같이 써도 되나

된다.

오히려 자주 같이 간다.

다만 역할은 분리해야 한다.

Triage는 들어오는 걸 나누고, LLM Wiki는 나중에 다시 읽기 쉽게 만든다.

입구와 지식층을 같은 문서에서 해결하려 하면 금방 비대해진다.

Harness만 잘 만들면 나머지는 없어도 되나

아니다.

하니스는 실행 안정화에 강하지만, 지식 정리와 누적 학습을 대신하진 못한다.

실행은 안정적인데 팀이 계속 같은 설명을 반복하고 있으면 위키나 compound가 빠진 거다.

Compound는 꼭 시스템으로 구현해야 하나

아니다.

처음엔 아주 단순한 규칙이어도 된다.

예를 들면 승자 글은 파생글 3개로 번역한다 같은 운영 규칙도 compound의 시작이 될 수 있다.

혼자 쓰는 Claude Code 자동화에도 이 네 개가 다 필요한가

대개 아니다.

혼자 쓰는 자동화는 보통 약한 Triage + 얇은 Harness 정도만 있어도 충분하다.

자료가 쌓이면 LLM Wiki를 붙이고, 반복 최적화가 필요해질 때 Compound를 얹으면 된다.

지금 당장 하나만 손대라면 뭘 먼저 보나

대부분은 Harness다.

이유는 단순하다.

실행이 흔들리면 분류도 위키도 누적도 결국 사람이 다시 메운다.

자동화가 사람을 덜 부르도록 만드는 게 먼저다.

다만 진짜 입력이 뒤죽박죽이면 Triage부터 보는 게 맞다.

같이 걸어둘 운영 글

참고 자료

  • 오늘 Claude Code/볼트 자동화 운영에서 직접 부딪힌 구분
  • Andrej Karpathy의 LLM Wiki 아이디어를 통해 정리한 compiled knowledge layer 관점
  • AI Native Company 계열 자동화 담론을 실제 개인 운영 구조에 대입해본 메모

마무리

이 네 단어는 다 좋아 보인다.

근데 좋아 보인다고 다 필요한 건 아니다.

실전에서는 무엇이 더 미래적이냐보다 무엇이 지금 병목을 줄이느냐가 중요하다.

그래서 내 기준은 꽤 단순하다.

  • 들어오는 게 문제면 Triage
  • 배운 게 안 쌓이면 Compound
  • 지식 회수가 안 되면 LLM Wiki
  • 자동화가 자꾸 흔들리면 Harness

이 정도만 구분돼도 새 개념이 나올 때마다 시스템에 덕지덕지 바르지 않게 된다.

자동화는 원래도 충분히 복잡하다.

거기에 용어까지 헷갈리면 진짜 일은 안 하고 구조만 사랑하게 된다.

그건 좀 웃기잖아.