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

출처: 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 리뷰용 에이전트에서도 쓰고 싶다면 복사-붙여넣기밖에 방법이 없다. 한쪽을 고치면 다른 쪽도 함께 고쳐야 하고, 그러다 일관성이 흐트러진다....

하네스 엔지니어링이 무엇인지 이해한다. 프롬프트 엔지니어링과 하네스 엔지니어링이 어떻게 다른지 정리하고 흔히 오해하는 세 가지 개념을 짚어본다. 혼자 일하는 AI는 자기 실수를 못 본다 단일 에이전트는 자신의 실수를 잘 보지 못한다. 하나의 에이전트가 plan → code → verify → self-revise 를 일반적으로 거친다. 이 과정은 자기 출력물을 자기가 검토하는 것과 같기때문에 한계가 있다. 병목은 능력이 아니라 구조다 AI 에이전트 시대에 ‘엄격함’은 사라진게 아니라 자리를 옮겼다. 예시: GC가 들어왔을 때 메모리 관리의 엄격함이 사라진 것이 아니라 런타임과 프로파일러로 옮겨 갔다....

하네스가 ‘좋은 프롬프트’와 어떻게 다른지 결과물로 직접 느끼고, .claude/agents와 .claude/skills/ 디렉터리를 처음부터만들어 본다. author와 reviewer 두 에이전트가 파일을 주고받으며 협업하는 2인팀을 완성하고, 자연어 한 줄로 팀을 소환하는 경험을 한다. 직접 해보기 생성-검증 패턴(generator-verifier): author 에이전트가 쓰고 reviewer 에이전트가 검토한다. 한쪽이 놓친 문제를 다른 한쪽의 기준에서 걸릴 가능성이 높아진다. 에이전트에 model 필드를 지정하지 않으면 부모 세션의 모델을 따라간다.

셋 다 인메모리 캐시 솔루션이지만, 관계를 이해하려면 먼저 memcached와 Redis의 차이를 알아야 한다. Arcus는 memcached 포크이고, Valkey는 Redis 포크다. 즉 Arcus vs Redis/Valkey는 memcached 계열 vs Redis 계열의 차이, Redis vs Valkey는 라이선스의 차이로 정리된다. memcached vs Redis 두 솔루션의 출발점이자, 나머지 비교의 토대다. 자료구조 memcached: 값을 plain string으로만 저장하는 단순 key-value 저장소. 키는 최대 250 byte, 값은 기본 1MB로 제한된다. Redis: string 외에 hash, list, set, sorted set, stream, bit array, hyperloglog 등 풍부한 자료구조를 지원한다....

기본 요소: 함수와 변수 Hello, World! 함수를 선언할 때 fun 키워드를 사용한다. 파라미터 이름 뒤에 그 파라미터의 타입을 쓴다. 함수를 최상위 수준에서 정의할 수 있다. 꼭 클래스 안에 함수를 넣어야 할 필요가 없다. 배열도 일반적인 클래스와 마찬가지다. 코틀린에는 자바와 달리배열 처리를 위한 문법이 따로 존재하지 않는다. System.out.println 대신에 println이라고 쓴다. 코틀린 표준 라이브러리는 여러 가지 표준 자바 라이브러리 함수를 간결하게 사용할 수 있게 감싼 wrapper를 제공한다. 줄 끝에 세미콜론을 붙이지 않아도 좋다....