코드 작성/분석 관점에서 실용적으로 정리하면 이렇습니다.

핵심 구분: "무엇을 재사용하는가" vs "어디서 실행되는가"

스킬(Skill) = 재사용 가능한 지식/워크플로우를 담은 마크다운 파일. 메인 대화 컨텍스트 안에서 로드됨. 서브에이전트(Subagent) = 독립된 컨텍스트에서 실행되는 별도의 작업자. 작업 결과만 요약해서 돌려줌.

즉 스킬은 "무엇을 어떻게 하는지"에 대한 지식이고, 서브에이전트는 "어디서, 누가" 그 작업을 수행하는지에 대한 문제입니다. 실제로는 이 둘이 자주 결합됩니다 (서브에이전트가 특정 스킬을 preload해서 실행).

판단 기준표

기준 스킬을 써야 할 때 서브에이전트를 써야 할 때

목적 반복되는 지식/체크리스트/워크플로우를 재사용 메인 컨텍스트를 오염시키지 않고 격리된 작업 수행
예시 API 스타일 가이드, /deploy 배포 체크리스트, 코드 리뷰 체크리스트 코드베이스 전체를 뒤지는 리서치, 대규모 리팩터링 실행, 병렬 검증
컨텍스트 영향 메인 대화창에 그대로 쌓임 (설명은 항상, 본문은 사용 시) 별도 창에서 처리되고 요약만 돌아옴
적합한 작업 규모 짧고 명확한 절차, 참고 자료 파일을 수십 개 읽어야 하거나, 탐색적이고 결과가 불확실한 작업

실용적 규칙

  1. "같은 프롬프트를 세 번째 붙여넣고 있다" → 스킬로 만드세요.
  2. "이 작업이 끝나면 중간 과정은 볼 필요 없고 결론만 필요하다" → 서브에이전트로 위임하세요.
  3. "파일을 수십 개 읽어야 하는데 메인 대화가 그걸로 꽉 찰 것 같다" → 서브에이전트.
  4. "이건 지식이지 실행 단위가 아니다" (예: DB 스키마, 코딩 컨벤션) → 스킬.
  5. 둘은 배타적이지 않습니다. 예: /audit 스킬이 보안·성능·스타일 검사용 서브에이전트 3개를 동시에 띄우는 패턴이 흔합니다.

만들 때 실전 팁

스킬 만들 때:

  • ~/.claude/skills/이름/SKILL.md에 name, description(트리거 조건을 명확히!)을 프론트매터로 작성
  • description이 모호하면 Claude가 스킬을 안 부르거나 잘못 부름 — "언제 쓰는지"를 구체적으로 명시
  • 부작용(side effect)이 있는 스킬(배포, 삭제 등)은 disable-model-invocation: true로 설정해서 자동 트리거 막고 /이름으로만 수동 실행

서브에이전트 만들 때:

  • 자체 시스템 프롬프트, 도구 허용 목록, 필요시 모델까지 별도 지정 가능
  • skills: 필드로 특정 스킬을 미리 로드시킬 수 있음
  • 읽기 전용 작업(코드 리뷰, 조사)엔 쓰기 도구를 아예 빼서 안전하게 격리 가능

CLAUDE.md와 헷갈릴 때는: "항상 지켜야 하는 규칙"이면 CLAUDE.md, "가끔 필요한 참고자료/절차"면 스킬입니다.


서브에이전트는 YAML frontmatter가 있는 마크다운 파일입니다. 만드는 방법과 호출 방법을 나눠서 설명할게요.

1. 만드는 방법

파일 위치

  • .claude/agents/이름.md — 프로젝트 단위 (팀과 공유, git에 커밋)
  • ~/.claude/agents/이름.md — 사용자 단위 (모든 프로젝트에서 사용)
  • 우선순위: managed > project > user (같은 이름이면 상위가 이김)

만드는 두 가지 방법

  1. Claude에게 직접 만들어달라고 요청 — "code-reviewer라는 서브에이전트를 만들어줘, Read/Grep/Glob만 쓰고 보안·버그 위주로 검토하게" 라고 프롬프트로 말하면 됨
  2. 직접 파일 작성

참고: v2.1.198부터 /agents 명령이 대화형 생성 마법사를 열지 않습니다. 대신 Claude에게 요청하거나 .claude/agents/를 직접 편집하라는 안내만 출력됩니다.

예시 파일

---
name: code-reviewer
description: 코드 변경 후 버그, 보안 이슈, 컨벤션 위반을 검토. 코드 작성/수정 직후 사용.
tools: Read, Grep, Glob
model: sonnet
permissionMode: default
skills: code-review-standards
---

당신은 시니어 코드 리뷰어입니다. diff나 파일 묶음이 주어지면:
1. 정확성 버그, 보안 취약점, 놓친 엣지 케이스를 찾는다
2. 코딩 컨벤션 위반을 지적한다
3. 발견 사항을 우선순위별로 요약해서 보고한다

주요 frontmatter 필드

필드 필수 설명

name 소문자+하이픈
description 자동 위임의 핵심. Claude가 이 설명을 보고 언제 이 서브에이전트를 부를지 판단하므로, 구체적인 트리거 조건을 써야 함
tools 생략 시 전체 도구 상속. 필요한 것만 좁게 지정 권장 (읽기 전용 작업이면 쓰기 도구 아예 빼기)
model sonnet/opus/haiku/inherit
permissionMode default/acceptEdits/bypassPermissions/plan
skills 이 서브에이전트에 미리 로드할 스킬 목록
disallowedTools 명시적으로 금지할 도구
mcpServers, hooks, maxTurns, memory, effort 고급 설정

2. 호출하는 방법

(1) 자동 위임 — 가장 일반적

아무 지시 없이 그냥 작업을 요청하면, Claude가 description을 보고 알아서 적절한 서브에이전트에게 위임합니다. description에 "proactively" 같은 키워드를 넣으면 더 적극적으로 자동 위임하도록 유도할 수 있습니다.

(2) 명시적으로 지정

프롬프트에서 이름을 직접 언급하면 됩니다.

code-reviewer 서브에이전트로 이 diff 검토해줘

(3) /agents 명령

현재 등록된 서브에이전트 목록 확인, 실행 중인 서브에이전트 확인/중지에 사용 (생성 마법사는 이제 없음).

(4) --agent 플래그로 세션 전체를 특정 에이전트로 실행

claude --agent code-reviewer

이건 "위임"이 아니라 메인 세션 자체가 그 에이전트의 시스템 프롬프트/도구 제약을 그대로 쓰는 방식입니다.

(5) --agents 플래그로 즉석 정의 (파일 없이)

claude --agents '{"reviewer": {"description": "...", "prompt": "...", "tools": "Read,Grep"}}'

실전 팁

  • description을 구체적으로 쓰세요. "코드 리뷰 담당" 같은 애매한 설명은 자동 트리거가 잘 안 됩니다. "코드 작성/수정 직후 버그와 보안 이슈를 검토, 사용해야 함"처럼 트리거 조건을 명시하세요.
  • tools는 최소한으로. 읽기 전용 리서치 에이전트라면 Write/Edit을 아예 빼서 실수로 파일을 건드리지 못하게 하세요.
  • description이 모호하거나 여러 에이전트 범위가 겹치면 Claude가 잘못 위임하는 게 가장 흔한 실패 사례입니다.

클로드 코드에 붙여넣을 프롬프트 예시입니다.

기본 프롬프트

.claude/agents/ 에 code-analyzer 라는 서브에이전트를 만들어줘.

역할: 이 프로�트의 특정 파일이나 디렉토리, 또는 최근 변경된 diff를 
받으면 다음 두 가지를 수행한다:
1. 코드 동작 설명 - 이 코드가 무엇을 하는지, 주요 함수/모듈의 
   흐름과 책임을 초보자도 이해할 수 있게 설명
2. 코드 리뷰 - 버그 가능성, 보안 이슈, 성능 문제, 컨벤션 위반, 
   가독성/유지보수성 문제를 찾아서 우선순위(심각/보통/사소)별로 정리

동작 방식:
- 먼저 관련 파일들을 읽고 프로젝트의 전체 구조(디렉토리 구성, 
  주요 의존성, 아키텍처 패턴)를 파악한다
- 파일 간 의존관계(어디서 호출되고 어디서 임포트되는지)도 함께 확인한다
- 결과는 "동작 설명" 섹션과 "리뷰 결과" 섹션으로 나눠서 보고한다
- 리뷰 결과에는 구체적인 파일명:라인번호와 함께 무엇을, 왜 고쳐야 하는지 제시
- 코드를 직접 수정하지 않고 읽기 전용으로만 분석한다

이 서브에이전트는 코드 리뷰가 필요하거나, 특정 파일/모듈이 무엇을 
하는지 설명이 필요할 때 자동으로 위임되도록 description을 작성해줘.
tools는 읽기 전용(Read, Grep, Glob 등)으로 제한해줘.

더 간단한 버전 (빠르게 시작하고 싶을 때)

이 프로젝트를 분석해서 코드 리뷰와 동작 설명을 해주는 서브에이전트를 
.claude/agents/code-analyzer.md 로 만들어줘. 읽기 전용 도구만 쓰게 
하고, description에는 코드 리뷰나 코드 설명이 필요할 때 자동으로 
호출되도록 구체적인 트리거 조건을 넣어줘.

만든 후 사용법

생성이 끝나면 이렇게 호출하면 됩니다.

code-analyzer로 src/auth 디렉토리 분석하고 리뷰해줘

또는 아무 언급 없이 "이 함수 뭐 하는 건지 설명해줘" / "이 PR 리뷰해줘"라고만 해도 description이 잘 작성되어 있으면 Claude가 자동으로 위임합니다.

팁: 프로젝트가 특정 언어/프레임워크(예: TypeScript+React, Django 등)라면 프롬프트에 그 스택을 명시해주면 리뷰 기준(예: React 훅 규칙, Django ORM 쿼리 최적화 등)이 훨씬 정확해집니다.

좋은 질문이네요. 결론부터 말씀드리면 — React(또는 웹 UI)로 파라미터를 입력하면 바로 파형이 그려지는 방식을 메인으로 만들고, Claude Code는 그 앱을 "개발하는 도구"로 쓰는 게 맞습니다. Claude Code가 매번 파형을 "보고 분석해서 만들어주는" 방식은 시뮬레이터의 핵심 용도(반복적으로 파라미터 바꿔가며 확인하는 것)에 맞지 않습니다.

두 방식 비교

항목 Claude Code가 매번 생성/분석 React 앱 (결정론적 렌더링)

응답 속도 수 초~수십 초 (LLM 추론) 즉시 (ms 단위)
재현성 매번 조금씩 다를 수 있음 항상 동일한 결과 보장
반복 튜닝 (파라미터 슬라이더로 조정) 사실상 불가능 매우 적합
비용 호출마다 토큰 소모 0 (한 번 만들면 끝)
오프라인/CI 통합 어려움 쉬움 (테스트 자동화 가능)
복잡한 비표준 패턴 해석·설명 강점 약함
정확성 검증 LLM 특성상 검산 필요 코드로 로직 고정 → 검증 쉬움

메모리 테스트 패턴(March C-, MATS+, Checkerboard, Walking 1/0, GalPat 등)은 사실 알고리즘이 명확히 정의되어 있는 도메인이라, LLM이 매번 "추론"할 이유가 없습니다. 오히려 코드로 고정해놓고 결정론적으로 그리는 게 훨씬 신뢰도 높습니다.

추천 아키텍처

1. Claude Code로 만드는 것 = React 기반 인터랙티브 시뮬레이터

  • 입력: 클럭 주기, 셋업/홀드 타임, 커맨드(READ/WRITE/ACT/PRE 등), 주소/데이터 버스 폭, 테스트 알고리즘 선택(March C-, MATS+, Checkerboard 등)
  • 출력: 타이밍 다이어그램(SVG/Canvas), 각 사이클별 신호 상태(CLK, CMD, ADDR, DATA, CS/WE/OE 등)

2. 컴포넌트 구조 제안

/src
  /patterns
    marchC.ts      // 알고리즘별 순수 함수 (파라미터 → 신호 시퀀스 배열)
    mats.ts
    checkerboard.ts
  /waveform
    WaveformCanvas.tsx   // 신호 시퀀스를 SVG/Canvas로 렌더링
    TimingRuler.tsx
  /controls
    ParamPanel.tsx       // 클럭/타이밍/패턴 선택 UI
  App.tsx

3. 데이터 흐름

  • 파라미터 → pattern 함수(순수 함수, LLM 개입 없음) → 신호 배열({time, signal, value}[]) → 렌더러가 파형으로 그림
  • 이렇게 하면 나중에 패턴을 추가하거나 검증할 때도 함수 단위로 유닛테스트 가능

4. Claude Code의 역할

  • 이 알고리즘들(March 계열, timing 규칙)을 정확히 구현하도록 코드 작성/디버깅
  • 라이브러리는 SVG 직접 그리기 or recharts/d3 조합 추천 (타이밍 다이어그램은 커스텀 SVG가 제어하기 편함)

그래도 LLM 분석이 필요한 경우

  • 비표준/커스텀 패턴을 텍스트로 설명했을 때 그걸 신호 시퀀스로 "번역"해주는 보조 기능
  • 시뮬레이션 결과에서 이상 패턴(예: setup/hold violation)을 자연어로 설명해주는 리포트 기능

이런 부분은 앱 안에 "AI 해석" 버튼 같은 형태로 부가 기능으로 넣고, Claude API를 호출하는 방식이 합리적입니다. 핵심 파형 생성 로직과는 분리해두세요.


원하시면 위 구조를 바탕으로 실제 March C- 알고리즘이나 기본 타이밍 다이어그램 컴포넌트를 하나 만들어서 예시를 보여드릴 수 있어요. 어떤 테스트 패턴/신호 조합부터 시작하고 싶으신가요?


좋은 질문이에요. 결론부터: 파싱은 Python으로, 최종 산출물은 JSON으로 변환해서 React가 그 JSON만 소비하는 구조를 추천합니다.

언어 선택: Python vs JavaScript

상황 추천

파일이 CSV/Excel/이상한 텍스트 포맷 섞여있음 Python — pandas, openpyxl 등 파싱 생태계가 압도적으로 강함
파일이 표준 JSON/YAML로 이미 정리되어 있음 JS도 무방
파싱 로직이 복잡한 정규식/도메인 규칙(핀맵 표기법 등) Python — 문자열 처리, 예외 처리, 디버깅이 더 수월
웹에서 사용자가 직접 파일 업로드 → 브라우저에서 즉석 변환 JS(브라우저 내) 불가피할 수 있음
Claude Code로 반복 실행/수정하며 개발 Python 추천 — 스크립트 단위 실행/검증이 쉬움

왜 Python이 더 나은가:

  • 채널 핀맵, 파형 종류, 타이밍 스펙 같은 "엔지니어링 스프레드시트류" 파일은 실무에서 대개 CSV, Excel, 또는 반정형 텍스트(datasheet 형태)로 존재합니다. 이런 걸 다루는 데는 pandas/openpyxl이 JS보다 훨씬 성숙해있어요.
  • 파싱은 일회성 배치 작업(빌드 타임)이지 실시간 반응성이 필요한 게 아니라서, 굳이 브라우저에서 돌아갈 필요가 없습니다.
  • Claude Code 관점에서도, 파일 구조가 지저분할 때는 Python으로 탐색적으로 짜고 검증하는 게 반복 개발에 유리합니다.

JS를 써야만 하는 경우는 "사용자가 웹 앱에서 파일을 업로드하면 그 자리에서 바로 파싱해서 보여줘야 한다"는 요구사항이 있을 때뿐입니다. 그게 아니라면 굳이 하나의 언어로 통일할 필요 없어요.

파일 직접 참조 vs JSON 중간 변환

JSON으로 변환하는 방식을 강력 추천합니다. 이유:

  1. 관심사 분리(Separation of concerns)
    • 파싱 로직(지저분한 원본 파일 다루기)과 렌더링 로직(React가 파형 그리기)을 완전히 분리
    • 원본 파일 포맷이 바뀌어도 React 쪽 코드는 건드릴 필요 없음 (JSON 스키마만 안 바뀌면 됨)
  2. 검증(validation)이 쉬움
    • 파싱 단계에서 "이 핀 번호가 중복됐다", "타이밍 값이 음수다" 같은 걸 미리 걸러낼 수 있음
    • React는 이미 검증된 깨끗한 데이터만 받으므로 방어 코드가 줄어듦
  3. 디버깅/재사용성
    • JSON 파일 자체를 눈으로 열어보거나 diff 떠서 "파싱이 제대로 됐는지" 바로 확인 가능
    • 같은 JSON을 다른 도구(테스트 자동화, 리포트 생성 등)에서도 재사용 가능
  4. 성능
    • React가 매번 원본 파일(Excel 등)을 파싱하는 건 느리고 브라우저에서 하기도 번거로움. JSON 로드는 즉시.

추천 파이프라인

[여러 원본 파일: CSV/Excel/txt]
        │
        ▼
Python 파서 (pinmap_parser.py, timing_parser.py, waveform_parser.py)
   - 각 파일 타입별 파서 함수 분리
   - 통합 스키마로 정규화
        │
        ▼
config.json  ← 단일 진실 소스(source of truth)
{
  "channels": [{ "pin": "A0", "name": "ADDR0", "polarity": "active_high" }, ...],
  "timing": { "clockPeriod": 10, "setup": 2, "hold": 1 },
  "pattern": "marchC-"
}
        │
        ▼
React 앱이 config.json을 fetch/import해서 파형 렌더링

폴더 구조 예시:

/parser (Python)
  pinmap_parser.py
  timing_parser.py
  merge_to_json.py   # 최종적으로 config.json 생성
/app (React/TS)
  /patterns
  /waveform
  App.tsx            # config.json을 읽어서 렌더링만 담당

이렇게 하면 나중에 원본 파일 포맷이 바뀌거나(엑셀→CSV 등) 새 파일 소스가 추가돼도, Python 파서만 수정하면 되고 React 쪽은 전혀 손댈 필요가 없습니다.

원하시면 실제 예시로 핀맵 CSV 하나 + 타이밍 스펙 파일 하나를 가정해서 Python 파서 스켈레톤과 통합 JSON 스키마를 같이 설계해드릴까요?

Warp 를 이용하여 클로드코드 실행 - ai 기반 터미널 어플리케이션
skill-creator (https://claude.ai/settings/capabilities)
https://github.com/anthropics/skills
claude code 에서 설치하기
  /plugin -> marketplace, add marketplace / anthropcis/skills 입력, example-skills, /exit
  /skills
> skill-creator 스킬을 활용하여 README.md 문서를 작성하는 스킬을 생성해줘

claude-plugins-official
병렬 리서치 - 서브에이전트를 병렬로 활용
순수 HTML, CSS, JavaScript 만으로 웹 기반 슬라이드 프레젠테이션을 구현하는 최적의 방법을 리서치하세요. 외부 라이브러리(Reveal.js 등)는 참고만 하고, 최종 구현은 순수 바닐라로 가능해야 합니다.

다음 4개의 주제를 서브에이전트로 병렬 리서치하세요.
1. 슬라이드 레이아웃 & DOM 구조
2. 키보드& 마우스 네이게이션
3. 슬라이드 전환 애니메이션
4. 슬라이드 내 콘텐츠 애니메이션

 


https://claude-prompts-kr.vercel.app/
https://tinyurl.com/26hh3439
https://naver.me/xTy7Jf5I
https://tinyurl.com/28mfwuv5

github.com/anthropics/claude-plugins-community/blob/main/eli5/skills/eli5/SKILL.md 
/plugin marketplace add anthropics/claude-plugins-community
/plugin install eli5@claude-community

🔗 링크
1. Karpathy Guidelines
https://github.com/multica-ai/andrej-...
2. claude-video
https://github.com/bradautomates/clau...
3. Superpowers
https://github.com/obra/superpowers
4. Understand-Anything
https://github.com/Lum1104/Understand...
5. agentmemory
https://github.com/rohitg00/agentmemory

skills.sh 에 스킬순위 있음

🔗 링크
1. Karpathy Guidelines
https://github.com/multica-ai/andrej-...

2. claude-video
https://github.com/bradautomates/clau...

3. Superpowers
https://github.com/obra/superpowers

4. Understand-Anything
https://github.com/Egonex-AI/Understa...

5. agentmemory
https://github.com/rohitg00/agentmemory

6. humanizer
https://github.com/DaleSeo/korean-ski...

마켓플레이스 URL 특징
클로드 공식 github.com/anthropics/skills 앤트로픽 공식, 가장 안정적
Skills.sh skills.sh 스킬별 상세 레퍼런스
SkillsMP skillsmp.com 70만+ 대규모 커뮤니티
SkillHub skillhub.club AI 평가 등급, Playground

Claude Code를 반도체 테스트 패턴(ATE 프로그램) 분석·시각화·생성에 활용하는 방법을 정리해 드릴게요. 최신 문서 기준으로 확인한 내용입니다.

1. Claude Code가 이 작업에 적합한 이유

Claude Code는 터미널(또는 VS Code, JetBrains, 데스크톱 앱)에서 실행되는 에이전틱 코딩 도구로, 파일을 직접 읽고, 편집하고, 스크립트를 실행할 수 있습니다. 반도체 테스트 패턴은 보통

  • STIL, WGL, ATML, TSL2 같은 표준 포맷
  • 또는 Teradyne(J750/UltraFLEX), Advantest(V93000), Keysight 등 벤더별 독자 포맷
  • 혹은 사내 자체 스크립트/C/Python 기반 패턴 생성기

로 존재하는데, 이런 텍스트/바이너리 기반 파일을 파싱하는 커스텀 코드를 즉석에서 작성해 실행하고, 결과를 검증하는 루프를 Claude Code가 잘 수행합니다.

2. 워크플로우 설계

프로젝트 설정 — CLAUDE.md

프로젝트 루트에 CLAUDE.md 파일을 만들어 반도체 도메인 지식을 기록해두면, 세션마다 이를 자동으로 읽습니다.

# 테스트 패턴 분석 프로젝트

## 패턴 포맷
- 사용 포맷: STIL (IEEE 1450)
- 벡터 파일 위치: /patterns/*.stil
- 핀 매핑 정의: /config/pinmap.csv

## 분석 시 확인할 것
- 타이밍 위반 (setup/hold)
- 벡터 카운트 및 반복 구간
- 사용하지 않는 핀/신호

## 코딩 컨벤션
- 파서는 Python으로 작성, pandas로 벡터 데이터 저장
- 시각화는 matplotlib/plotly 사용

분석 단계

  • "이 STIL 파일을 파싱해서 핀별 벡터 시퀀스를 표로 정리해줘" 같은 요청으로 파서를 즉석에서 작성시킬 수 있습니다.
  • 대용량 패턴 파일(수만~수백만 라인)의 경우, 서브에이전트를 활용해 파일을 청크 단위로 병렬 분석하게 하면 컨텍스트 낭비 없이 처리할 수 있습니다.
  • 반복되는 분석 작업(예: 매주 새 패턴 검증)은 **스킬(Skill)**로 만들어두면 재사용이 쉽습니다 — .claude/skills/ 아래에 분석 절차를 저장해두는 방식입니다.

시각화

  • 타이밍 다이어그램, 벡터 파형, 핀 상태 맵 등은 Claude Code에게 Python(matplotlib/plotly) 스크립트를 작성·실행시켜 이미지나 HTML로 출력하게 하면 됩니다.
  • VS Code 확장이나 데스크톱 앱을 쓰면 생성된 이미지/HTML을 바로 미리보기로 확인할 수 있어 반복 조정이 편합니다.

패턴 생성

  • "이 알고리즘으로 새 벡터 시퀀스를 생성해줘" 같은 요청도 가능하지만, 생성된 패턴이 실제 ATE에서 문법적으로 유효한지는 반드시 검증 루프를 넣어야 합니다 — 예: 생성 후 자체 파서로 재검증하거나, 벤더 제공 신택스 체커를 CLI로 실행해 결과를 Claude에게 피드백하는 식.
  • 이런 "생성 → 자동 검증 → 수정"을 반복시키려면 훅(Hooks)으로 파일 저장 시 자동 검증 스크립트를 트리거하게 설정하는 것도 좋습니다.

3. 실전 팁

  • 탐색 → 계획 → 실행 순서를 명시적으로 요청하세요 ("먼저 패턴 구조를 파악하고 계획을 세운 뒤 진행해줘"). Plan Mode를 쓰면 파일을 수정하기 전에 계획을 검토할 수 있습니다.
  • 검증 가능한 기준(예: "생성된 패턴이 원본과 벡터 수가 일치해야 함")을 프롬프트에 넣어주면 Claude가 스스로 확인하며 작업합니다.
  • 사내 포맷이 독자적이라면, 샘플 파일 몇 개와 스펙 문서를 프로젝트에 포함시켜두는 것이 파서 정확도에 크게 도움이 됩니다.

혹시 사용 중인 ATE 플랫폼(Teradyne/Advantest/Keysight 등)이나 패턴 포맷(STIL/WGL/자체 포맷)을 알려주시면, 그에 맞춘 파서/시각화 예제 코드를 바로 작성해드릴 수 있습니다.반도체 테스트 패턴처럼 파일 기반 코드 작업이 많다면, 위 앱으로 로컬 파일에 직접 접근해가며 작업하는 게 훨씬 수월할 거예요.


좋은 질문이에요. 결론부터 말씀드리면 가능은 하지만 방식이 다릅니다.

ASC vs MPA의 근본적 차이

  • ASC: 텍스트 기반 소스 포맷이라 Claude Code가 바로 읽고 파싱할 수 있습니다. 문법 구조가 보이니까요.
  • MPA: Advantest 컴파일러가 ASC를 테스터(T2000 등) 하드웨어가 실행할 수 있는 바이너리로 컴파일한 결과물입니다. 이건 Advantest의 독자 바이너리 포맷이라 공개된 스펙 문서가 없고, 제 학습 데이터에도 MPA의 정확한 바이너리 구조(헤더, 필드 레이아웃 등)는 들어있지 않습니다. 이 부분은 솔직히 말씀드려야 할 것 같아요 — 아는 척하고 잘못된 필드 해석을 드리면 더 위험합니다.

그럼 어떻게 접근할 수 있나?

1) 가장 확실한 방법 — 벤더 제공 API/툴 활용 Advantest T2000 플랫폼에는 보통 MTX(또는 유사한) 라이브러리나 CLI 유틸리티가 있어서 MPA를 다시 텍스트로 디컴파일하거나 정보를 덤프할 수 있는 경우가 많습니다. 이런 공식 도구가 있다면:

  • Claude Code가 그 CLI를 호출하는 스크립트를 작성 → 출력 텍스트를 파싱 → 분석/시각화
  • 이게 가장 안전하고 정확한 경로입니다.

2) 공식 도구가 없거나 부족할 때 — ASC 대비 차분 분석(reverse engineering)

  • 같은 패턴을 ASC → MPA로 컴파일한 샘플 여러 개를 준비
  • ASC 내용을 조금씩 바꿔가며 MPA의 바이트가 어떻게 달라지는지 비교
  • Claude Code에게 hex dump 스크립트를 작성시켜 구조적 패턴(헤더 매직넘버, 벡터 반복 인코딩 등)을 추정하게 할 수 있습니다

다만 이 방법은 추측 기반이라 완전한 정확도를 보장 못 하고, 실제 테스터에 적용하기 전 반드시 검증이 필요합니다. 분석/디버깅 용도(예: 왜 두 MPA 파일이 다른지 확인)에는 유용하지만, 이 추정 구조로 MPA를 직접 생성/수정하는 건 위험합니다.

3) 현실적인 워크플로우 추천 대부분의 실무에서는 ASC 단계에서 분석·시각화·생성을 다 끝내고, MPA는 Advantest 컴파일러(공식 도구)로만 생성하는 방식을 씁니다. 즉:

  • Claude Code로 ASC 파서/분석기/생성기 구축
  • 컴파일은 Advantest 공식 컴파일러(bash_tool로 CLI 호출 가능하면 그것도 자동화 가능)에 맡기고
  • 컴파일 후 결과(로그, 에러, 벡터 카운트 등 텍스트 출력)를 다시 Claude Code가 파싱해서 검증

질문 하나 드릴게요 — MPA를 분석하려는 목적이 (a) 컴파일이 의도대로 됐는지 검증, (b) MPA만 있고 원본 ASC가 없는 경우 복원/역분석, (c) 순수 바이너리 구조 탐구 중 어디에 가깝나요? 목적에 따라 접근법이 많이 달라져서요.

전자회로에서 pole과 zero는 수학적으로는 전달함수 H(s)의 분모/분자를 0으로 만드는 s값이지만, 직관적으로 이해하려면 "회로가 주파수에 어떻게 반응하는가"의 관점에서 보는 게 좋습니다.

1. 핵심 직관: "저항하는 정도"와 "밀어주는 정도"

  • Pole(극점) = 신호를 감쇠시키는 지점. 그 주파수 근처에서 회로가 신호를 통과시키기 "힘들어"합니다. 커패시터/인덕터가 에너지를 저장하며 신호 변화를 지연시키는 효과라고 보면 됩니다.
  • Zero(영점) = 신호를 증폭/강조시키는 지점(엄밀히는 분자를 0으로 만들어 출력이 0이 되는 지점이지만, Bode 선도에서는 이득이 올라가는 효과로 나타남).

가장 쉬운 비유: RC 저역통과 필터를 생각해보세요.

  • 낮은 주파수: 커패시터가 거의 개방(open) → 신호가 그대로 통과
  • 높은 주파수: 커패시터가 거의 단락(short) → 신호가 접지로 빠져나가 감쇠

이 "커패시터가 단락되기 시작하는 주파수"가 바로 pole 주파수(ωₚ = 1/RC) 입니다.

2. s-평면에서의 그림

이걸 s-평면(복소평면)에서 시각화하면 더 명확해집니다. 그려드릴게요.## 3. 그림을 읽는 법 — "거리"가 핵심

전달함수의 크기는 대략 이렇게 생각할 수 있습니다:

|H(jω)| ∝ (zero까지의 거리) / (pole까지의 거리)

  • jω축을 따라 위로 올라가며(주파수를 높이며) 이동할 때, pole에 가까워지면 → 분모가 작아져서 → 이득이 뚝 떨어집니다 (감쇠)
  • zero에 가까워지면 → 분자가 작아져서 → 이득이 확 올라가거나(원점 zero인 경우) 꺾임이 생깁니다

즉, 극점(pole)은 "블랙홀"처럼 그 근처 주파수를 빨아들여(감쇠시켜) 통과를 막고, 영점(zero)은 반대로 그 주파수를 밀어내며 강조한다고 생각하면 직관적입니다.

4. 회로 요소와의 대응 (감각적 매핑)

회로적 의미 pole zero

RC 저역통과 필터 1/RC에서 이득이 -3dB, 이후 -20dB/decade로 감소 (단순 RC LPF엔 없음)
RC 고역통과 필터 원점 zero + 유한 pole s=0에 zero (DC 성분 차단)
되먹임(피드백) 증폭기 극점 개수 = 위상 지연 증가 → 안정도 저하 가능 위상을 앞당겨(lead) 안정도를 개선 가능
실제 물리적 느낌 "관성", 반응이 느려지는 지점 "가속", 반응을 앞당기는 지점

5. 시간 영역에서의 직관

  • Pole은 **시간응답의 지수함수 형태(e^(-t/τ))**를 결정합니다. pole이 왼쪽으로 갈수록(σ가 더 음수) → 더 빨리 감쇠 → 회로가 더 빨리 안정됨.
  • Zero는 시간응답의 미분(derivative) 성분을 더해주는 역할입니다. 그래서 zero가 있으면 신호의 변화(edge, transient)에 더 민감하게 반응하는 "오버슈트"가 생기기도 합니다.

6. 실무 감각 요약

  • Pole = 저역통과 특성을 만든다 (고주파를 깎아낸다)
  • Zero = 고역통과 특성 or 위상 보상을 만든다 (특정 주파수를 살리거나 위상을 앞당긴다)
  • 두 개를 조합하면 대역통과, 대역저지, lead-lag 보상기 등 원하는 주파수 응답을 설계할 수 있습니다.

혹시 특정 회로(예: RC 필터, 연산증폭기 보상 회로, 스위칭 레귤레이터 안정도 등)에서의 pole-zero 배치를 구체적으로 살펴보고 싶으신가요?

전류원(Current Source)은 전압원과 달리 부하와 관계없이 일정한 전류를 흘려주는 회로입니다. 실제로는 이상적인 전류원을 직접 만들 수 없고, 트랜지스터의 특성을 이용해 근사적으로 구현합니다. 주요 구성 방법들을 정리해 드릴게요.

1. 기본 원리: 왜 전류원이 필요한가

이상적인 전류원은 출력 임피던스가 무한대여야 합니다. 부하가 바뀌어도 전류가 일정해야 하니까요. 실제 회로에서는 BJT나 MOSFET의 높은 출력 저항(rₒ)을 이용해서 이를 근사합니다.

2. BJT를 이용한 전류원

(1) 저항 바이어스 전류원 (가장 기본)

  • 저항과 다이오드(또는 저항 분압)로 베이스 전압을 고정
  • 이미터에 저항 Rₑ를 넣어 전류를 설정: I ≈ (V_B - V_BE) / R_E
  • 온도 변화에 취약하다는 단점이 있음

(2) 커런트 미러 (Current Mirror) — 가장 널리 쓰이는 방식

     Vcc
      |
   ┌──┴──┐
   |     |
  Q1    Q2  (베이스-베이스, 이미터-이미터 연결)
   |     |
  Iref  Iout
  • 기준 전류(Iref)를 만드는 트랜지스터(Q1, 다이오드 연결)와 이를 복사하는 트랜지스터(Q2)로 구성
  • Q1과 Q2의 베이스-이미터가 같은 전압을 공유하므로 V_BE가 같아지고, 트랜지스터 특성이 동일하면 Iout ≈ Iref
  • 여러 개의 출력 트랜지스터를 병렬로 붙이면 여러 곳에 동일한(또는 비율이 다른) 전류를 공급 가능 (면적비로 전류비 조절)

(3) 윌슨 전류원 (Wilson Current Source)

  • 커런트 미러에 트랜지스터 하나를 추가해 출력 저항을 크게 높인 구조
  • 얼리 효과(Early effect)로 인한 오차를 줄여 정확도가 향상됨

(4) 캐스코드 전류원 (Cascode Current Source)

  • 트랜지스터를 위아래로 쌓아(cascode) 출력 임피던스를 rₒ²gm 수준으로 크게 증가
  • 아날로그 IC의 정밀 전류원에 많이 사용

3. MOSFET을 이용한 전류원

  • 원리는 BJT와 동일하지만 V_GS 대신 게이트 전압으로 제어
  • 포화영역(saturation region)에서 동작시켜 드레인 전류가 V_DS와 거의 무관하게 만듦
  • MOSFET 커런트 미러도 IC 설계에서 매우 흔하게 사용됨

4. 정밀도를 높이는 방법

  • **밴드갭 기준(Bandgap Reference)**과 결합하면 온도에 무관한 정전류 생성 가능
  • 저항 대신 능동소자(전류원 자체)를 부하로 써서(active load) 이득을 높이는 데도 응용

5. 간단한 저항 기반 방법 (정밀도가 낮아도 될 때)

  • 전압원에 큰 저항을 직렬로 연결하면 전류가 거의 일정해짐 (I ≈ V/R, 부하 저항이 R보다 훨씬 작을 때만 근사적으로 성립)
  • 이는 진짜 전류원이 아니라 근사치이며, 정밀한 응용에는 부적합

요약: 실무에서 가장 많이 쓰이는 건 커런트 미러입니다. 간단하고, 여러 개의 동일한 전류원을 IC 안에서 쉽게 복제할 수 있기 때문입니다. 더 높은 정밀도가 필요하면 캐스코드나 윌슨 구조를 추가하는 식으로 발전시킵니다.

혹시 특정 응용(예: 오피앰프 내부 바이어스, LED 정전류 드라이버 등)을 염두에 두고 계신가요? 그에 맞춰 더 구체적으로 설명드릴 수 있어요.

+ Recent posts