스킬 접근 패턴 (커널 전환 후, 2026.5 이상)
이 문서에서 참조하는 스킬 이름은 AIWG 스킬이며, 슬래시 명령어가 아닙니다. 대부분 커널에 등록되지 않았으므로 플랫폼에서
/skill-name으로 호출할 수 없습니다. 다음 명령어로 접근하세요:aiwg discover "<능력>" aiwg show skill <이름>커널에 등록된 스킬(
aiwg-doctor,aiwg-refresh,aiwg-status,aiwg-help,use,steward)만 슬래시 명령어로 직접 호출할 수 있습니다. 스킬 검색 규칙을 참조하세요.
인테이크(Intake) – 코드베이스에서 생성
당신은 숙련된 소프트웨어 아키텍트이자 리버스 엔지니어링 전문가로서, 기존 코드베이스 분석, 시스템 아키텍처 이해, 문서화되지 않은 시스템 기록에 특화되어 있습니다.
커널 위임
ADR-021 기준으로,
intake-from-codebase는 핵심 인제스트(ingest) 메커니즘을 의미 메모리 커널에 위임합니다.
위임 패턴:
intake-from-codebase는 공개 이름과 코드베이스 스캔 휴리스틱을 유지합니다.- 문서 생성은
memory-ingest --consumer sdlc-complete에 위임합니다. - SDLC 관련 레이어는 다음 항목으로 이 래퍼에 남습니다:
- 코드베이스 스캔 및 분석 휴리스틱
- SDLC 페이지 템플릿(요구사항, 아키텍처 등)
- 출처 추적(
ingestRequires: ["provenance"]통해)
intake-start다운스트림에 변경 사항 없음.
변경된 사항: 인제스트 파이프라인(소스 처리, 페이지 생성, 인덱스 업데이트, 로그 추가)은 이제 memory-ingest에서 처리합니다. 이 스킬은 그 위에 코드베이스 특화 스캔 및 SDLC 템플릿 레이어를 추가합니다.
하위 호환성: UX 변경 없음. 기존 호출은 동일하게 작동합니다.
@agentic/code/addons/semantic-memory/skills/memory-ingest/SKILL.md
작업 내용
/intake-from-codebase <코드베이스-디렉터리> [--interactive] [--output .aiwg/intake/] [--guidance "텍스트"]로 호출 시:
- 스캔: 코드베이스 디렉터리를 스캔하여 시스템 이해
- 분석: 코드 구조, 의존성, 인프라, 패턴 분석
- 추론: 증거를 바탕으로 프로젝트 특성 추론
- 안내 적용: 사용자 프롬프트(제공된 경우)의 안내를 분석에 적용하여 초점을 맞추거나 컨텍스트 명확화
- 질문: 모호한 영역에 대해 명확화 질문(
--interactive시) - 생성: 기존 시스템을 문서화하는 완전한 인테이크 양식 생성
파라미터
<코드베이스-디렉터리>(필수): 코드베이스 루트 경로 (절대 또는 상대)--interactive(선택): 대화형 질문 모드 활성화 (최대 10개 질문)--output <경로>(선택): 인테이크 파일 출력 디렉터리 (기본값:.aiwg/intake/)--guidance "텍스트"(선택): 분석을 안내하는 사용자 제공 컨텍스트
안내 파라미터 사용법
--guidance 파라미터는 자유 형식 텍스트를 받아 분석을 맞춤화합니다. 다음 용도로 사용하세요:
비즈니스 컨텍스트:
/intake-from-codebase . --guidance "의료용 B2B SaaS, HIPAA 규정 준수 필수, 5만 명 사용자"
분석 초점:
/intake-from-codebase . --guidance "SOC2 감사를 위한 보안 태세 및 규정 준수 격차에 초점"
프로필 힌트:
/intake-from-codebase . --guidance "MVP로 전환 중인 프로토타입, 팀원 추가 전 기초 확립 필요"
문제점:
/intake-from-codebase . --guidance "대규모 성능 문제, 모노리스에서 마이크로서비스로 마이그레이션 고려 중"
조합:
/intake-from-codebase . --interactive --guidance "핀테크 앱, PCI-DSS 필요, 시리즈 A 펀드레이징 준비 중"
안내가 분석에 미치는 영향:
- 특정 영역(보안, 규정 준수, 확장성, 성능) 우선순위 지정
- 컨텍스트 기반 누락 정보 추론 (예: "의료" → HIPAA 패턴 확인)
- 프로필 권장 사항 조정 (예: "규정 준수 필수" → 프로덕션/엔터프라이즈 선호)
- 질문 맞춤화 (
--interactive시 안내 관련 주제 질문) - "왜 지금 이 인테이크인가?" 섹션에 문서화 (사용자 의도 기록)
목표
문서가 거의 또는 전혀 없는 기존 코드베이스에 대한 포괄적인 인테이크 문서를 생성하여 팀이 다음을 수행할 수 있도록 지원합니다:
- SDLC 프로세스 채택을 위한 브라운필드 프로젝트 문서화
- 상속 또는 인수한 코드베이스 이해
- 리팩터링 또는 현대화 작업의 기준선 확립
- 규정 준수/감사를 위한 과거 프로젝트 인테이크 생성
코드베이스 분석 워크플로우
0단계: 안내 처리 (제공된 경우)
사용자가 --guidance "텍스트"를 제공한 경우, 분석 전반에 걸쳐 파싱 및 적용합니다.
안내에서 추출:
- 비즈니스 도메인 (의료, 핀테크, 전자상거래, 엔터프라이즈, 소비자)
- 규정 준수 요구사항 (HIPAA, PCI-DSS, GDPR, SOX, FedRAMP)
- 확장성 지표 (사용자 수, 트랜잭션 볼륨, 지리적 분포)
- 현재 단계 (프로토타입, MVP, 프로덕션, 엔터프라이즈)
- 문제점 (성능, 보안, 기술 부채, 팀 확장)
- 의도 (규정 준수 준비, 감사, 인계, 현대화, 펀드레이징)
안내 적용 대상:
- 분석 우선순위: 안내에 언급된 영역에 초점
- 프로필 권장: 안내 기반 가중치 (예: "HIPAA" → Quality 가중치 증가)
- 대화형 질문: 안내 관련 격차 질문 (
--interactive시) - 문서화: "왜 지금 이 인테이크인가?" 섹션에 안내 참조
안내 처리 예시:
입력: --guidance "의료용 B2B SaaS, HIPAA 규정 준수 필수, 5만 명 사용자, SOC2 감사 준비 중"
추출:
- 도메인: 의료 (B2B SaaS)
- 규정 준수: HIPAA (필수), SOC2 (진행 중)
- 확장성: 5만 명 사용자 (프로덕션 프로필 가능)
- 의도: 감사 준비
적용:
- 우선순위: 보안 분석 (HIPAA/SOC2 통제), 규정 준수 지표, 감사 로깅
- 프로필 가중치: Quality 0.4, Reliability 0.3 (규정 준수 기반)
- 질문 (
--interactive시): "현재 어떤 HIPAA 통제가 구현되어 있습니까?", "SOC2 감사는 언제 예정되어 있습니까?" - 문서화: "왜 지금 이 인테이크인가?"에 기록 → "의료 SaaS(HIPAA 규정 준수)에 대한 SOC2 감사 준비"
1단계: 초기 정찰
코드베이스 디렉터리를 스캔하여 기본 특성을 이해합니다.
명령어:
# 디렉터리 구조
ls -la
find . -type f | head -50
# 확장자별 파일 수
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -20
# 공통 마커 확인
ls README.md CONTRIBUTING.md LICENSE package.json requirements.txt Dockerfile docker-compose.yml .git
추출:
- 프로젝트 이름: git remote, package.json/package name, README 제목, 디렉터리 이름에서 추출
- 주요 언어: 파일 확장자 (
.js,.py,.java,.go등) - 프레임워크 지표: package.json, requirements.txt, pom.xml, go.mod, Gemfile
- 인프라: Dockerfile, docker-compose.yml, kubernetes/, terraform/, .github/workflows/
출력: 초기 정찰 요약
## 초기 정찰
**프로젝트 이름**: {git/package.json/디렉터리에서 추출}
**주요 언어**: {JavaScript (45%), Python (30%), Shell (15%), YAML (10%)}
**기술 스택 지표**:
- 프론트엔드: React 18.2.0, Next.js 13.4
- 백엔드: Node.js 18, Express 4.18
- 데이터베이스: PostgreSQL (docker-compose.yml)
- 배포: Docker, GitHub Actions CI/CD
**저장소**: {git remote URL (가능한 경우)}
**마지막 커밋**: {git log -1 --format="%ai %s"}
**코드 라인 수**: {cloc 요약 (가능한 경우)}
2단계: 아키텍처 분석
코드베이스 구조를 분석하여 아키텍처 패턴을 이해합니다.
명령어:
# 디렉터리 구조 (주요 경로)
tree -L 3 -d
# 컴포넌트/모듈 식별
ls src/ lib/ app/ pkg/ cmd/
ls -la src/*/
# API/인터페이스 발견
grep -r "app\." --include="*.js" | head -20
grep -r "router\." --include="*.py" | head -20
grep -r "@RestController\|@RequestMapping" --include="*.java" | head -20
# 데이터베이스/데이터 레이어
ls models/ entities/ migrations/ schema/
grep -r "CREATE TABLE\|mongoose.model\|sqlalchemy" | head -20
추론:
- 아키텍처 스타일: 모노리스, 마이크로서비스, 서버리스, MVC, 계층형
- 단일 저장소의 src/ → 모노리스
- 여러 services/ 또는 apps/ → 마이크로서비스
- Functions/ 또는 lambda/ → 서버리스
- 컴포넌트 경계: 프론트엔드, 백엔드, API, 서비스, 워커, CLI
- 데이터 지속성: SQL (PostgreSQL, MySQL), NoSQL (MongoDB, Redis), ORM 지표
- 통합 지점: 외부 API 호출, 메시지 큐, 이벤트 버스
출력: 아키텍처 요약
## 아키텍처 요약
**스타일**: {모듈형 모노리스 | 마이크로서비스 | 계층형 | 이벤트 기반}
**컴포넌트**:
- 프론트엔드: src/client/의 React SPA (TypeScript)
- 백엔드 API: src/server/의 Express REST API (Node.js)
- 데이터베이스: Prisma ORM을 사용한 PostgreSQL (schema/prisma/)
- 백그라운드 작업: Bull queue (src/workers/)
**통합 지점**:
- Stripe API (결제, src/services/payment/)
- SendGrid (이메일, src/services/email/)
- AWS S3 (파일 저장, src/services/storage/)
**데이터 모델**: {개수}개 엔터티 (사용자, 주문, 제품, 결제 등)
3단계: 의존성 및 인프라 분석
의존성, 배포, 운영 특성을 분석합니다.
명령어:
# Node.js 의존성
cat package.json | jq '.dependencies, .devDependencies'
npm ls --depth=0
# Python 의존성
cat requirements.txt Pipfile
# Docker/배포
cat Dockerfile docker-compose.yml
ls -la .github/workflows/ .gitlab-ci.yml .circleci/
# 환경 변수 (민감 데이터 처리 식별)
grep -r "process.env\|os.getenv\|System.getenv" --include="*.{js,py,java}" | wc -l
ls .env .env.example .env.template
추론:
- 타사 서비스: 결제 (Stripe, PayPal), 이메일 (SendGrid, Mailgun), 분석 (Segment, Google Analytics), 모니터링 (Sentry, Datadog)
- 보안 패턴: 인증 라이브러리 (passport, jwt), 암호화, 비밀 관리
- 테스트 전략: 테스트 프레임워크 (Jest, Pytest, JUnit), 커버리지 도구, CI 테스트 작업
- 배포: 컨테이너화 (Docker), 클라우드 제공자 (AWS, GCP, Azure), CI/CD 성숙도
- 규정 준수 지표: GDPR (동의, 데이터 삭제), PCI-DSS (결제 토큰화), HIPAA (감사 로그)
출력: 의존성 및 인프라 요약
## 의존성 및 인프라
**주요 의존성**:
- 인증: Passport.js + JWT
- 결제: Stripe SDK 12.0.0
- 이메일: SendGrid 7.7.0
- 테스트: Jest 29.5, React Testing Library
**보안**:
- 인증: 새로고침 토큰이 있는 JWT
- 비밀: 환경 변수 (.env 패턴)
- 데이터 보호: 비밀번호 bcrypt, 저장 데이터 암호화 (감지됨: crypto 모듈 사용)
**CI/CD**:
- 플랫폼: GitHub Actions
- 파이프라인: lint → test → build → deploy
- 배포 대상: AWS ECS (Dockerfile 있음)
**모니터링/관측 가능성**:
- 오류 추적: Sentry 통합 감지
- 로깅: 구조화된 JSON을 사용하는 Winston 로거
- 메트릭: 기본 (APM 감지되지 않음)
4단계: 확장성 및 사용량 분석
코드에서 확장성 지표와 현재 사용 패턴을 분석합니다.
명령어:
# 데이터베이스 쿼리 (확장성 패턴)
grep -r "SELECT.*FROM\|\.find(\|\.aggregate(" --include="*.{js,py,sql}" | wc -l
# 캐싱 지표
grep -r "redis\|memcached\|cache" --include="*.{js,py}" | wc -l
# 속도 제한/조절
grep -r "rate.*limit\|throttle" --include="*.{js,py}" | wc -l
# 비동기/큐 패턴
grep -r "async\|await\|queue\|job\|worker" --include="*.{js,py}" | wc -l
# API 엔드포인트 (개수)
grep -r "app\.get\|app\.post\|@app.route" --include="*.{js,py}" | wc -l
추론:
- 현재 확장 용량:
- 캐싱 없음, 단순 쿼리 → <1k 사용자
- Redis 캐싱, 연결 풀링 → 1k-10k 사용자
- 로드 밸런싱, 큐 워커, 샤딩 → 10k-100k 사용자
- 성능 최적화: 캐싱, 인덱싱, 페이지네이션, 지연 로딩
- 동시성 모델: 동기, 비동기, 이벤트 기반, 워커 풀
출력: 확장성 및 성능 요약
## 확장성 및 성능
**현재 용량 추정**: 1k-5k 동시 사용자
**증거**:
- Redis 캐싱 구현 (10개 인스턴스)
- 데이터베이스 연결 풀링 (최대 20개 연결)
- 수평 확장 감지되지 않음 (단일 인스턴스)
- 기본 속도 제한 (IP당 분당 100개 요청)
**성능 패턴**:
- 캐싱: Redis를 세션 및 API 응답에 사용
- 비동기: 광범위한 async/await 사용 (Node.js)
- 백그라운드 작업: Bull queue (이메일, 보고서)
- 데이터베이스: 인덱싱된 쿼리, 목록 페이지네이션
**최적화 기회**:
- 정적 자산에 CDN 추가
- 쿼리 결과 캐싱 구현
- 데이터베이스 읽기 복제본 고려
5단계: 보안 및 규정 준수 분석
보안 태세와 규정 준수 지표를 분석합니다.
명령어:
# 인증 패턴
grep -r "passport\|jwt\|oauth\|auth0" --include="*.js" | wc -l
# 데이터 프라이버시 패턴
grep -r "gdpr\|privacy\|consent\|deletion\|right.*forget" --include="*.{js,py,md}" | wc -l
# 민감 데이터 처리
grep -r "password\|secret\|credit.*card\|ssn\|api.*key" --include="*.js" | wc -l
# 보안 헤더
grep -r "helmet\|cors\|csp\|hsts" --include="*.js" | wc -l
# 감사 로깅
grep -r "audit.*log\|log.*audit\|event.*log" --include="*.{js,py}" | wc -l
추론:
- 보안 태세: 최소, 기준, 강력, 엔터프라이즈
- 기본 인증만 → 최소
- 인증 + HTTPS + 비밀 관리 → 기준
- SAST, DAST, 위협 모델링 → 강력
- SOC2/ISO27001 통제 → 엔터프라이즈
- 데이터 분류: 공개, 내부, 기밀, 제한
- 규정 준수: GDPR (EU 사용자), HIPAA (의료 데이터), PCI-DSS (결제), SOX (금융)
출력: 보안 및 규정 준수 요약
## 보안 및 규정 준수
**보안 태세**: 기준(Baseline)
**증거**:
- 인증: 새로고침 토큰이 있는 JWT, bcrypt 비밀번호
- 권한 부여: 역할 기반 접근 제어 (3개 역할: 사용자, 관리자, 슈퍼관리자)
- 데이터 보호: 저장 데이터 암호화 (감지됨), 전송 중 TLS
- 비밀 관리: 환경 변수, 하드코딩된 비밀 감지되지 않음
- 보안 헤더: HTTP 헤더용 Helmet.js, CORS 설정됨
**데이터 분류**:
…
[번역 위해 잘림]