출처: Anthropic 블로그 Agent Harness Design: 3 Patterns for Harnessing Claude’s Intelligence (Lance Martin, 2026-04-02). 하네스(harness): 모델을 둘러싼 소프트웨어 뼈대. 루프, 도구, 컨텍스트 관리, 가드레일을 묶어 순수한 지능을 동작하는 에이전트로 바꾸는 층이다. 모델 자체(Claude)와는 구분된다. 같은 모델이라도 하네스를 어떻게 짜느냐에 따라 결과가 달라진다. 핵심 메시지: “생성형 AI 시스템은 만들어진다기보다 자라난다.” 하네스에 박아 넣은 “Claude는 이걸 못 하니까 내가 대신해 준다"는 가정은 모델이 좋아지면 그대로 낡은 짐이 된다. 그래서 하네스 설계의 질문은 “무엇을 더 넣을까"가 아니라 “무엇을 그만둘 수 있는가” 다....

핵심: 클러스터 노드가 내려갔다 올라올 때 데이터가 남으려면 세 가지가 동시에 필요하다. 디스크 지속성(AOF/RDB)이 켜져 있어 재시작 시 메모리를 복원할 수 있다. nodes.conf(클러스터 설정 파일)가 살아남아 같은 노드 ID로 클러스터에 재합류한다. 그 사이 failover가 일어났다면 복귀 노드의 데이터는 어차피 버려지므로, replica 쪽에 최신 데이터가 있어야 한다. 흔한 오해: “AOF만 켜두면 재시작해도 데이터가 그대로다.” → failover가 끼면 복원한 데이터는 전부 폐기된다. 지속성은 failover가 없었을 때와 클러스터 전체가 내려갔을 때를 위한 안전장치다....

Redis는 데이터를 메모리에 들고 있다. 프로세스가 죽으면 그대로 사라지므로, 디스크에 남겨 재시작 후 복원하는 장치가 필요하다. 이것이 **지속성(persistence)**이다. 방식은 두 가지다. RDB(Redis Database): 특정 시점의 데이터 전체를 파일 하나로 덤프하는 스냅샷. AOF(Append Only File): 데이터를 바꾼 쓰기 명령을 순서대로 기록한 로그. 재시작 시 로그를 재생해 상태를 복원한다. 둘은 배타적이지 않다. 동시에 켤 수 있고, 데이터를 중요하게 다룬다면 그게 권장 구성이다. RDB: 스냅샷 어느 순간의 데이터셋 전체를 dump.rdb라는 바이너리 파일 하나로 저장한다....

출처: Anthropic 블로그 A harness for every task: Dynamic workflows in Claude Code (Thariq Shihipar, Sid Bidasaria). 동적 워크플로우: Claude가 작업에 맞는 멀티 에이전트 하네스를 즉석에서 JavaScript로 작성해 실행하는 것. 스크립트가 여러 서브에이전트를 생성·조정한다. 각 서브에이전트는 독립 컨텍스트 윈도우 + 좁은 목표를 갖는 별개의 Claude 인스턴스다. 핵심 메시지: 기본 하네스(단일 컨텍스트에서 계획과 실행을 동시에)는 길고 큰 작업에서 구조적으로 무너진다. 작업 형태에 맞춰 하네스 자체를 갈아끼우는 것이 해법이다. 왜 단일 에이전트로는 부족한가 기본 Claude Code는 하나의 컨텍스트 윈도우 안에서 계획·실행을 함께 처리한다....

메타스킬이 일반 스킬과 어떻게 다른지 이해하고, hareness SKILL.md의 실제 파일구조를 통해 Progressive Disclosure와 자기 참조성이 어떻게 구현되는지 확인한다. 6단계 파이프라인의 각 Phase에서 무엇을 실행하고 무엇이 산출되는지 파악하고, 하네스가 한 번 만들면 끝이 아니라 계속 순환하며 발전하는 이유를 이해한다. 메타스킬이란 무엇인가 메타스킬: 스킬과 에이전트를 만드는 스킬이다. 메타스킬이 여는 6단계 파이프라인 도메인 분석 → 팀 설계 → 정의 → 스킬 → 오케스트레이션 → 검증 Phase 1. 도메인 분석: 질문을 정제하는 단계 정제할 항목 도메인과 핵심 작업 유형: 데이터 분석 파이프라인인가, 콘텐츠 생성인가, 웹 앱 개발인가, 코드 리뷰인가....

Jenkins의 master-agent 통신은 Remoting이라는 라이브러리가 담당한다. TCP 기반 통신 프로토콜, 원격 프로시저 호출(RPC), 원격 클래스 로딩, 데이터 스트리밍을 구현한 통신 계층이다. 용어: 예전의 master는 지금 controller, slave는 agent로 이름이 바뀌었다(2020년경). 이 글에서는 controller/agent로 쓴다. 핵심은 controller와 agent가 하나의 양방향 채널(channel) 을 열고, 그 위로 직렬화된 자바 객체를 주고받는다는 것이다. 프로토콜과 포트는 이 채널을 어떻게 뚫느냐의 문제일 뿐이고, 채널이 뚫린 뒤 그 위에서 무엇이 흐르느냐가 본질이다. 아키텍처 전제: 두뇌는 controller에만 있다 agent는 controller에 접속하는 작은 자바 프로세스(agent....

실행 중이던 job이 재시작을 견디느냐는 실행 상태가 어디에 얼마나 자주 디스크로 내려가 있느냐로 갈린다. 재개(resume)는 마법이 아니라 직렬화된 상태를 다시 읽어 들이는 것이다. 그래서 job 종류에 따라 답이 완전히 다르다. Freestyle job은 재개되지 않는다. 빌드 컨텍스트를 복원할 방법이 없어서, controller가 죽으면 실행 중이던 빌드는 그대로 중단된다. 재개를 논할 수 있는 것은 Pipeline(workflow-job)뿐이다. Pipeline이 재개되려면 두 곳의 상태가 모두 살아 있어야 한다. 축이 다르므로 따로 봐야 한다. controller 쪽: 파이프라인 프로그램이 어느 스텝까지 진행됐는지(CPS 실행 상태)....

팀원들이 리더를 거치지 않고 서로 직접 대화할 수 있게 해주는 세 가지 도구 TeamCreate, TaskCreate, SendMessage를 다룬다. 3인이 넘으면 리더가 무너진다. 리더는 한 번에 한 사람과만 대화할 수 있으니, 3인이 넘는 경우 순차 파이프라인으로 퇴행해서 병목이 발생한다. 리더는 이벤트 루프, 팀원은 피어 잘 설계된 오케스트레이터는 리더를 중개자가 아니라 수신자이자 통합자의 위치에 둔다. 왼쪽 그림의 리더는 모든 메시지를 받아 ‘누구에게 전달할지’를 판단하는 중앙 브로커이다. 오른쪽 그림의 리더는 팀원들이 스스로 조율하는 동안 기다리다가, 작업이 끝나거나 막혔을 때 알림을 받는 수신자이다....

description을 Pushy 3단계 공식(동식 나열, 트리거 상황, 경계 조건)으로 작성하는 방법을 익히고, 컨텍스트를 아끼면서도 정보를 충분히 담는 Progressive Disclosure 구조를 이해한다. 규칙이 아닌 이유를 본문에 담는 Why-First 원칙을 실제 예시로 확인한다. 스킬을 썼는데 왜 호출이 안 될까 클로드는 스킬을 호출 할 지 결정할 때 본문을 읽지 않고, name과 description 만 보고 판단한다. 클로드 코드는 세션이 열릴 때 전체 컨텍스트 윈도의 약 1%만 스킬 목록에 쓴다. 1% 예산은 SLASH_COMMAND_TOOL_CHAR_BUDGET 환경 변수로 조정할 수 있으며, 기본 대체 한도는 약 8,000자이다....

ShedLock: 분산 환경에서 @Scheduled 작업이 동시에 두 번 이상 실행되지 않도록 보장하는 라이브러리. net.javacrumbs.shedlock 패키지에서 제공한다. 핵심 애노테이션이 @SchedulerLock이라, 흔히 SchedulerLock으로도 불린다. 스케줄러 자체를 대체하지 않는다. 스프링의 @Scheduled는 그대로 두고, 그 위에 “한 번만 실행” 제약만 얹는 동시성 제어 도구다. 왜 필요한가 무상태 애플리케이션을 여러 인스턴스로 띄우면, 각 인스턴스가 자기 스케줄러를 갖는다. @Scheduled(cron = "0 0 * * * *") 하나만 붙여두면 인스턴스가 3대일 때 매시 정각에 같은 작업이 3번 실행된다....

핵심: 클러스터 모드에서 Lua 스크립트가 접근하는 모든 키는 같은 hash slot에 있어야 한다. 슬롯이 갈리면 실행 자체가 거부된다(CROSSSLOT). 해결책은 하나다 — 같은 원자적 연산으로 묶을 키들에 hash tag({...})를 넣어 슬롯을 강제로 일치시킨다. 왜 이런 제약이 생기나 Redis 클러스터는 키를 16384개의 hash slot으로 샤딩한다. 슬롯은 CRC16(key) % 16384로 계산되고, 각 슬롯은 특정 마스터 노드가 소유한다. Lua 스크립트는 단일 노드에서 원자적으로 실행된다. 스크립트가 도중에 다른 노드의 키를 만지려면 노드 간 조율이 필요한데, 클러스터는 그런 분산 트랜잭션을 지원하지 않는다....

Redis Hash: 하나의 키 아래 여러 field-value 쌍을 담는 자료구조. 객체 하나를 필드 단위로 저장·조회할 때 쓴다. (HSET, HGET) Redis Sorted Set(ZSet): 각 멤버에 score(부동소수점)를 매겨 오름차순 정렬 상태로 보관하는 집합. score가 같으면 멤버 문자열 사전순으로 정렬한다. 랭킹·우선순위 큐·범위 조회에 쓴다. (ZADD, ZSCORE, ZINCRBY, ZRANGEBYSCORE, ZREM) EXPIRE는 자료구조와 무관하게 키 자체에 만료 시간을 거는 키 단위 명령이다. EXPIRE — 키 만료 설정 EXPIRE key seconds: 키에 TTL(Time To Live)을 초 단위로 건다....

출처: Anthropic 블로그 A Field Guide to Claude Fable: Finding Your Unknowns (Thariq Shihipar). 핵심 주장: Claude Fable은 작업 품질이 모델 성능이 아니라 unknowns(모르는 것)를 얼마나 명확히 하느냐에 의해 좌우되는 첫 모델이다. 병목은 프롬프트 기교가 아니라 “내가 무엇을 모르는지 아는” 메타인지다. Map vs Territory Map(지도): Claude에게 제공하는 정보 — 프롬프트, 스킬, 컨텍스트. Territory(실제 지형): 실제 코드베이스와 현실의 제약. Unknowns: map과 territory 사이의 격차. Claude가 추측으로 메워야 하는 영역이다. 작업 결과가 틀리게 돌아오면 대개 모델을 탓할 게 아니라 unknowns 정의나 (적응 여지를 둔) 구현 계획에 시간을 더 써야 한다는 신호다....

출처: Anthropic 블로그 Steering Claude Code: skills, hooks, rules, subagents, and more. Claude의 행동을 제어하는 방법은 7가지이고, 각각 로드 시점 · 컴팩션 동작 · 컨텍스트 비용 · 권한 수준이 다르다. 핵심 결정은 “무엇을 시킬까"가 아니라 “그 지시를 어디에 넣을까"다. 같은 규칙도 넣는 위치에 따라 비용과 강제력이 달라진다. 큰 원칙 하나: 모든 라인은 토큰 비용이다. 항상 로드되는 곳(CLAUDE.md, output style)에는 최소한만 두고, 나머지는 필요할 때만 로드되는 곳으로 밀어낸다. 또 하나: “선택적으로 따라도 되는 규칙"은 규칙이 아니다....

Claude Code에는 두 개의 독립된 다이얼이 있다: **모델 선택(model)**과 effort level(노력 수준). 모델 선택: 고정된 가중치 집합을 고르는 것. 훈련이 끝난 뒤 정해진 능력 범위를 결정한다. effort level: 한 요청에 Claude가 전반적으로 얼마나 일할지를 조절한다. 읽는 파일 수, 사용하는 도구 수, 밟는 단계 수, 그리고 한 턴에 생성하는 토큰 양이 여기에 달려 있다. 흔한 오해: effort는 “생각하는 시간"이 아니다. 검증을 얼마나 하고 다단계 작업을 얼마나 밀어붙일지를 정하는 작업량 다이얼이다. effort level의 동작 effort 값은 요청에 실려 모델로 전달되고, 모델은 각 노력 수준에서 어떻게 행동할지 학습되어 있다....

출처: Anthropic 블로그 Getting Started with Loops (Delba de Oliveira, Michael Segner). 루프: 에이전트가 정지 조건을 충족할 때까지 작업 사이클을 반복하는 것. 사람이 매 턴을 지시하는 대신, 에이전트가 스스로 “맥락 수집 → 실행 → 검증 → 필요 시 반복"을 돌게 만든다. 핵심 메시지: 루프 자체가 새로운 게 아니라, 어떤 작업을 어떤 종류의 루프에 위임하느냐를 고르는 안목이 중요하다. 위임할수록 사람은 감독만 하면 된다. 루프를 분류하는 4가지 축: 트리거: 어떻게 시작되는가. 중지 기준: 언제 끝나는가....

출처: Anthropic 블로그 Running an AI-native engineering org. 조직 전체가 Claude Code를 기본 도구로 쓰기 시작하면, 효율을 위해 만들었던 기존 프로세스가 오히려 발목을 잡는다. 코드를 쓰는 비용이 사라졌기 때문에 병목이 작성에서 검증·리뷰·보안으로 옮겨간다. 따라서 도구만 도입하는 게 아니라 계획·역할·조직 구조를 다시 설계해야 한다. 관통하는 원칙 하나: “이 프로세스가 아직도 필요한가, 자동화할 수 있는가?” 를 모든 절차에 물어라. 필요해서 만든 절차라도 조건이 바뀌면 저절로 사라지지 않으므로, 의도적으로 걷어내야 한다. 더는 작동하지 않는 프로세스들 계획: 장기 로드맵 → 점-시간(just-in-time) 계획....

지금까지 도커를 사용하여 배포 환경을 구축해왔지만 사실 도커에대한 이해가 있는 것은 아니다. 최근에 도커를 건드릴 일이 많아졌기 때문에 이 기회에 도커에대해서 학습해보고자 한다. 컨테이너 도커를 사용하면서 가장 많이 언급되는 단어가 컨테이너다. 컨테이너는 하나의 운영 체제 커널에서 다른 프로세스에 영향을 받지않고 독립적으로 실행되는 프로세스의 상태를 말한다. 독립적인 환경을 가지기 때문에 각 컨테이너마다 프로세스 ID도 격리되어 관리된다. 이 컨테이너 덕분에 우리는 배포 환경에 의존적이지 않도록 구성할 수 있다는 장점이 있다. 예전부터 유닉스나 리눅스는 하나의 운영 체제 안에서 자원을 분리해 할당하고, 실행되는 프로세스를 격리하는 방법이 존재했다....

에이전트 정의 파일을 ‘설정 파일’이 아닌 ‘역할 계약서’로 바라보는 관점을 갖고 name, descrfiption, model, tools 필드와 본문 7섹션을 올바르게 채우는 방법을 익힌다. 어떤 모델을 고를지, 어떤 도구를 허용할지를 결정하는 기준도 함께 살펴본다. 어제 잘 굴러가던 팀이 오늘 아침 사라지는 이유 모든 에이전트는 반드시 .claude/agents/{name}.md 파일로 정의한다. 파일 없이 프롬프트 파라미터에 역할을 직접 넣는 것을 금지한다. 없으면, 다음 날 다시 팀을 소환할 떄 역할을 처음부터 다시 서명해야 한다. 없으면, 두 세션이 같은 기준으로 판단했는지 검즈할 길이 없다....

에이전트, 스킬, 오케스트레이터 각각의 역할과 경계를 이해하고, 책임이 뒤섞였을 때 나타나는 네 가지 문제를 파악한다. 재사용 불가 병렬화 불가 누락 반복 컨텍스트 폭발 2인 팀을 분해해보자 하네스는 누가(Agent), 어떻게 (Skill), 언제∙누구와(Orchestrator) 라는 세 가지 요소로 나뉘며, 이들은 독립적으로 설계되고 실행 시점에만 맞물린다. 한 파일에 다 넣으면 무엇이 깨지는가 위 에이전트가 문제가 되는 이유 재사용 불가: “Conventional Commits 형식 체크” 로직을 PR 리뷰용 에이전트에서도 쓰고 싶다면 복사-붙여넣기밖에 방법이 없다. 한쪽을 고치면 다른 쪽도 함께 고쳐야 하고, 그러다 일관성이 흐트러진다....