fos-blog/study
01 / 홈02 / 카테고리03 / 시리즈
01 / 홈02 / 카테고리03 / 시리즈

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agent 페이지로 이동
    • claude-code 페이지로 이동
    • harness 페이지로 이동
    • llm 페이지로 이동
    • ops 페이지로 이동
    • practice 페이지로 이동
  • algorithm 페이지로 이동
    • Alias Method: 가중치 랜덤 선택을 전처리 O(n), 추출 O(1)로 바꾸기
    • Welford's Online Algorithm: 값을 저장하지 않고 평균과 분산 계산하기
  • architecture 페이지로 이동
    • distributed-systems 페이지로 이동
    • domain 페이지로 이동
    • evolution 페이지로 이동
    • patterns 페이지로 이동
  • database 페이지로 이동
    • milvus 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • qdrant 페이지로 이동
    • redis 페이지로 이동
    • vespa 페이지로 이동
    • DB Connection Pool Saturation과 Thread Pool 격리
    • 커넥션 풀 크기는 얼마나 조정해야 할까?
    • MyBatis 기본기 — XML Mapper, resultMap, 동적 SQL, 운영 패턴 정리
    • MyBatis와 JPA/Hibernate 트레이드오프 — 레거시 백엔드를 다루는 시니어 관점
    • 한국어 형태소 분석기 Nori vs Lindera — OpenSearch에서 Milvus로 갈 때 어휘 검색은 유지되나
    • 정규화와 역정규화: 무결성과 조회 비용 사이의 선택
    • 벡터 DB 5종, 아키텍처는 어떻게 다른가
    • 벡터 DB 5종을 실제로 벤치마크했다 — 같은 recall에서 QPS는 얼마나 갈리나
    • 벡터 DB 어떻게 고를까 — OpenSearch · Milvus · Qdrant · Vespa · pgvector 비교
    • 벡터 DB를 실제로 도입한 사례 — 빅테크 프로덕션
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • Envoy Proxy
    • Graceful Shutdown
    • 종료 신호는 어디서 멈추는가
  • http 페이지로 이동
    • HTTP Connection Pool
    • HTTPS와 TLS: 핸드셰이크, 인증서, 종료 지점
  • java 페이지로 이동
    • concurrency 페이지로 이동
    • jdbc 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • testing 페이지로 이동
    • Java 동시성 락 정리 — 커머스 메뉴/프로모션 정책 캐시 갱신 관점
    • JVM 튜닝 실전: 메모리 구조부터 Virtual Threads, GC 튜닝, 프로파일링까지
    • 로그에 traceId 남기기 — MDC 부터 OpenTelemetry 까지
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node 백엔드 운영 패턴 — Streams 백프레셔, pipe/pipeline, 멱등성 vs 분산 락
    • Node.js
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 클러스터 아키텍처: Broker, KRaft Controller와 복제
    • Kafka 기본 개념: Topic, Partition, Offset과 Segment
    • Kafka 실전 설계: 파티션 전략, 컨슈머 그룹, 전달 보장, 재시도, 순서 보장 트레이드오프
    • Kafka 파티션·리밸런스·컨슈머 지연 운영
    • Kafka를 로그로 이해하기: 복제, 재처리, 상태와 데이터 통합
    • Spring Kafka 컨슈머 오프셋 커밋과 트랜잭션 정렬: AckMode, manual ack, 멱등 처리
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • SSH forced command 로 배포 키가 실행할 수 있는 명령 제한하기
  • mlops 페이지로 이동
    • llm-serving 페이지로 이동
    • model-router 페이지로 이동
    • Python CUDA 버전 생태계 — nvidia-smi, nvcc, pip, conda가 다 다른 버전을 말하는 이유
    • GPU 컨테이너의 CUDA 버전 호환성 — nvidia-smi부터 이미지 다이어트까지
    • Kubernetes GPU 노드에서 /run tmpfs가 꽉 차서 Pod가 안 뜰 때
    • GPU·CUDA·MPS 기초 — 자바 백엔드 개발자가 처음 만나는 그림
    • Multi-process GPU 워크로드 — 자바 ThreadPool 사용자가 만나는 모델 차이
    • ML 서비스 성능 분석 워크플로 — 자바 백엔드 트러블슈팅과 다른 점
    • 한 GPU 를 여러 프로세스가 나눠 쓰기 — Time-Slicing 과 MPS
  • network 페이지로 이동
    • Connection reset by peer는 누가 보낸 걸까 — 리버스 프록시 홉마다 TCP 연결은 따로 논다
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • observability 페이지로 이동
    • Observability 입문: 시니어 백엔드가 장애를 탐지하고 대응하는 방식
    • K8s 위 Spring Boot 앱의 메트릭 수집
  • python 페이지로 이동
    • Python async/await — CompletableFuture·Reactor 와 다른 점, 그리고 blocking I/O 함정
    • Python 의존성 관리 — Java Maven/Gradle 사용자가 만나는 첫 충격
    • FastAPI 기초 — Spring Boot 사용자가 빠르게 익히는 법
    • Java 개발자를 위한 Python 심화 — OOP·데코레이터·컨텍스트 매니저
    • PyTorch 기초 — 텐서, 디바이스, 그리고 모델 로딩이 무거운 이유
    • Java 개발자를 위한 Python 문법 핵심
    • ThreadLocal 에서 contextvars 로 — Python 의 요청 컨텍스트 전파
    • OCR 동작 원리 — Layout · Text · Post-process 3단계
    • Python 서버의 RSS가 줄지 않는 이유: CPython, gc.collect(), malloc_trim
  • rabbitmq 페이지로 이동
    • RabbitMQ Basics — 실전 백엔드 관점에서 정리하는 메시지 브로커 기본기
    • RabbitMQ vs Kafka — 백엔드 메시징 선택 기준과 실전 운영 관점
  • resume 페이지로 이동
    • 경험 및 경력기술서
    • 김병태 경력기술서
    • 김병태 포트폴리오
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • sb-dev-team 페이지로 이동
    • the-future-company 페이지로 이동
  • thinking 페이지로 이동
    • 자기주도 학습: 질문에서 시작해 글로 검증하기
    • 좋은 일을 넘어 중요한 일을 하는 법
FOS-BLOG · FOOTERall systems normal·v0.1 · 2026.04.27·seoul, kr
Ffos-blog/study

개발 학습 기록을 정리하는 블로그입니다. 공부하면서 기록하고, 기록하면서 다시 배웁니다.

visitors
01site
  • Home↗
  • Posts↗
  • Categories↗
  • Glossary↗
  • About↗
02policy
  • 소개/about
  • 개인정보처리방침/privacy
  • 연락처/contact
03categories
  • AI↗
  • Algorithm↗
  • DB↗
  • DevOps↗
  • Java/Spring↗
  • JS/TS↗
  • React↗
  • Next.js↗
  • System↗
04connect
  • GitHub@jon890↗
  • Source repositoryjon890/fos-study↗
  • RSS feed/rss.xml↗
  • Newsletter매주 1 회 · 한 편의 글→
© 2026 FOS Study. All posts MIT-licensed.
built with·Next.js·Tailwind v4·Geist·Pretendard·oklch
fos-blog/AI/여러 저장소가 쓰는 스킬은 도메인 중립 코어…
ai

여러 저장소가 쓰는 스킬은 도메인 중립 코어와 저장소별 오버레이로 나눈다

같은 스킬을 여러 저장소에 복사해 두면 스킬을 고칠 때마다 저장소 수만큼 손으로 옮겨야 한다. 시간이 지나면 저장소마다 조금씩 갈라져서 유지 비용이 계속 쌓인다. 이 글은 스킬을 하나의 코어와 저장소별 오버레이로 나눠, 개선을 한 곳에서만 하고 모든 저장소가 받게 하는 구조를 정리한다. 오버레이를 찾는 순서, 배포할 때의 우선순위 함정, 코어로 옮길 때 깨...

2026.10.02·4 min read·13 views

같은 스킬을 여러 저장소에 복사해 두면 스킬을 고칠 때마다 저장소 수만큼 손으로 옮겨야 한다. 시간이 지나면 저장소마다 조금씩 갈라져서 유지 비용이 계속 쌓인다. 이 글은 스킬을 하나의 코어와 저장소별 오버레이로 나눠, 개선을 한 곳에서만 하고 모든 저장소가 받게 하는 구조를 정리한다. 오버레이를 찾는 순서, 배포할 때의 우선순위 함정, 코어로 옮길 때 깨지는 결합점을 함께 다룬다.

스킬 문서 한 편 안의 구조는 스킬 문서는 반복 실행을 스크립트로 내리고 같은 지시를 한 곳에서만 소유하게 쓴다에서 다룬다. 이 글은 그 위의 단계, 즉 여러 저장소에 걸친 스킬 공유를 다룬다.

사례는 공개 저장소 fos-skills에서 가져왔다.

복제본이 갈라지는 문제

planning 같은 스킬을 여러 저장소에 복사해 쓴다고 하자. 스킬 하나를 개선하면 나머지 저장소에도 같은 변경을 손으로 이식해야 한다. 이식하다 보면 저장소마다 조금씩 다른 버전이 남는다. 여러 프로젝트에 같은 하네스를 퍼뜨릴수록 이 비용이 커진다.

구조: 코어가 뼈대를, 오버레이가 저장소 특화를

구분담는 것위치
코어도메인 중립 워크플로. 단계 뼈대, 핵심 원칙, 공용 검증기스킬 전용 저장소 하나
오버레이저장소 특화. 도메인 단계 변형, 문서 컨벤션, 검증 경로, 실행 핸드오프 명령각 저장소의 .claude/<스킬 이름>-overlay.md

코어는 시작할 때 현재 저장소의 오버레이를 읽어 뼈대를 채운다. 오버레이가 없으면 코어의 기본값, 즉 도메인 중립 동작으로 돌아간다.

오버레이는 코어를 덮어쓰지 않고 채운다. 코어가 뼈대이고 오버레이가 거기에 저장소 특화 내용을 붙이는 방식이다.

효과는 두 가지다.

  • 워크플로를 개선할 때 코어 한 곳만 고치면 모든 저장소에 반영된다. 손으로 옮기는 일이 사라진다.
  • 저장소마다 있던 큰 스킬 파일이 작은 오버레이 파일로 줄어든다.

오버레이를 찾는 순서

fos-skills 의 planning/references/monorepo.md 는 단일 저장소에서 설정을 찾는 순서를 정한다.

  1. <저장소 루트>/.claude/<스킬 이름>-overlay.md
  2. 그 저장소의 하네스 지침 파일, 즉 AGENTS.md 와 CLAUDE.md
  3. 어디에도 없으면 사용자에게 확인한다

모노레포는 루트 바로 아래 디렉터리에 오버레이가 하나라도 있으면 모노레포로 본다. 이 경우 작업 대상 하위 프로젝트를 정한 뒤 그 하위 프로젝트의 오버레이를 루트 오버레이보다 먼저 읽는다. 변경이 두 하위 프로젝트에 걸치면 하나로 정하지 않고, 경로에 딸린 값은 각 하위 프로젝트의 오버레이에서 읽는다.

판정과 탐색 순서는 문서에 적혀 있고 scripts/overlay_paths.py 가 그대로 실행한다.

함정: 개인 전역에 둔 스킬이 프로젝트 스킬을 가린다

코어를 전용 저장소에 두고 ~/.claude/skills/<이름> 로 symlink 해서 모든 프로젝트에서 쓰게 할 수 있다. Claude Code 는 symlink 된 스킬 디렉터리를 지원한다.

그런데 같은 이름의 스킬이 여러 곳에 있으면 우선순위가 정해져 있다. Claude Code 스킬 문서는 같은 이름이 enterprise, personal, project 에 모두 있을 때 enterprise, personal, project 순으로 실행된다고 설명한다. 개인 전역은 프로젝트보다 우선한다.

그러면 자체 저장소 안에 같은 이름의 스킬을 가진 다른 저장소가 있을 때, 그 머신에서는 개인 전역 스킬이 이긴다. 저장소의 스킬이 가려지는 것이다. 개인 혼자 쓰는 저장소 묶음에는 문제가 없지만, 팀 공용 저장소처럼 자체 스킬을 유지하는 곳에는 맞지 않다.

fos-skills 는 현재 플러그인으로 스킬을 싣는 방식을 기준으로 설명한다. 같은 문서에 따르면 플러그인 스킬은 /플러그인이름:스킬이름 으로 네임스페이스가 붙어서 개인, 프로젝트 스킬과 우선순위가 충돌하지 않는다.

코어로 옮길 때의 주의

저장소마다 복사된 스킬을 코어로 모을 때는 두 가지를 조심한다.

  • 통째로 복사하지 않는다. 저장소마다 특화된 부분을 오버레이로 추출해야 한다. 통짜로 이식하면 각 저장소의 특화가 사라진다.
  • 삭제하기 전에 참조를 전부 찾는다. 스킬을 코어로 옮기면 의존하는 다른 스킬의 하드코딩된 경로나, 삭제 대상 아래에 있던 공유 자원이 함께 깨질 수 있다. 삭제 전에 참조를 전수 grep 하고, 공유 자원을 중립 위치로 먼저 옮긴다. 과거 기록(ADR 이나 완료된 작업 문서)의 언급은 그대로 둔다.

정리

상황대응
같은 스킬이 여러 저장소에 복제돼 있다코어 하나와 저장소별 오버레이로 나눈다
저장소 특화 내용이 필요하다코어를 고치지 않고 오버레이에 적는다
오버레이가 없다코어의 기본값으로 동작한다
전역에 둔 스킬이 프로젝트 스킬을 가린다우선순위를 확인하고 배포 위치를 바꾼다
코어로 옮기며 삭제한다삭제 전에 참조를 전부 찾고 공유 자원을 먼저 옮긴다
on this page
  • 01복제본이 갈라지는 문제
  • 02구조: 코어가 뼈대를, 오버레이가 저장소 특화를
  • 오버레이를 찾는 순서
  • 03함정: 개인 전역에 둔 스킬이 프로젝트 스킬을 가린다
  • 04코어로 옮길 때의 주의
  • 05정리
tags
#study#insights

이런 글도

  • ai

    하네스 회고는 새 문서로 쌓지 않고 종류에 맞는 기존 단일 소스에 환원한다

    2026.10.02
  • ai

    에이전트가 배운 회피 패턴은 조건을 통과한 것만 파일로 쌓고 주기적으로 지운다

    2026.10.02
  • ai

    ADR 은 되돌리기 어려운 결정의 이유만 남기고, 대안 기각은 옵션마다 줄을 나눈다

    2026.10.02
  • ai

    스킬 문서는 반복 실행을 스크립트로 내리고 같은 지시를 한 곳에서만 소유하게 쓴다

    2026.10.02

댓글 (0)