바이브 코딩으로 만든 코드나 남이 짠 코드를 실제 서비스에 올리기 전에, 그대로 올려도 되는지 누군가 봐 줬으면 할 때가 있습니다. Engineering(엔지니어링)은 Anthropic이 만든 개발 업무용 플러그인으로, 코드 리뷰·디버깅·설계 결정 기록·장애 대응·배포 전 점검표 같은 일을 정해진 순서와 양식으로 하게 하는 스킬 10개를 묶었습니다. 클로드 앱의 “가장 많이 설치된 Skills” 목록에 든 플러그인(설치 약 200만 건)이고, 플러그인은 무료이며 쓸 때 클로드 사용량이 듭니다. 실제로 동작하는 보안 구멍과 버그 9개를 넣은 가상 쇼핑몰 주문 코드로 “머지해도 되는지 검토해 줘”를 플러그인 없이, 깔아 두기만 하고, 명령으로 불러서 두 번씩 맡겼습니다.
- 심어 둔 문제 9개(SQL 인젝션, 코드에 박힌 비밀키, 남의 주문 열람, 동시 주문 초과 판매 등)는 여섯 번 모두 다 찾았습니다. 문제를 찾는 눈은 플러그인이 있든 없든 같았습니다.
/engineering:code-review로 부른 두 번만 스킬 문서의 양식(요약, 심각한 문제 표, 제안 표, 잘된 점, 결론)을 그대로 따랐습니다. 깔아 두기만 하면 스킬이 한 번도 불리지 않았습니다.- 한 번 검토에 1~2분, 사용량은 API 단가로 0.37~0.54달러였습니다.
/engineering:debug는 페이지 버그 하나를 원인부터 고치고 다시 돌려 확인했습니다.
결과부터 보기: 같은 코드, 리뷰 세 개
왼쪽은 플러그인 없이, 가운데는 깔아 두기만, 오른쪽은 /engineering:code-review 명령으로 받은 review.md입니다. 셋 다 “이대로 머지하면 안 된다”는 결론과 함께 고칠 코드를 붙였고, 차이는 보고서 틀에서 났습니다.
직접 눌러 보기: 리뷰 6개와 검토 대상 코드, 문제 9개가 실제로 동작하는 기록 열어 보기(클로드가 쓴 review.md를 그대로 화면용으로 바꿨습니다)
직접 실행 확인한 날짜 2026-10-16
- 실행 환경
- macOS 26.1 · Claude Code 2.1.299 · Opus 5.5 · 생각 깊이 중간 (모든 실행 같은 설정)
- 설치 난이도
- 명령 두 줄(저장소 등록·설치). 안에 든 것은 스킬 문서 10개와 외부 연결 설정 10개, 실행 파일은 없음
- 비용
- 플러그인은 무료. 코드 리뷰 한 번에 API 단가로 0.37~0.54달러어치 사용량
- 라이선스
- Apache-2.0 (anthropics/knowledge-work-plugins)
따라 해 보기: 요청문과 실습 재료
검토할 파이썬 파일을 한 폴더에 두고 클로드 코드를 열어 아래처럼 보내면 이번 실험의 세 번째 조건과 같습니다. 클로드 코드가 처음이라면 클로드 코드 설치 방법을 먼저 보세요. 실습 재료(zip)에는 검토 대상 shop.py, 요청문, 채점 기준과 정답, 문제가 실제로 동작하는지 확인하는 verify.py를 넣었습니다.
/engineering:code-review shop.py shop.py는 친구가 만든 쇼핑몰 주문 처리 코드야. 이번 주에 실제 서비스에 올리려고 하는데, 이대로 머지해도 되는지 검토해서 review.md로 정리해 줘.좋은 결과라면 19행의 SQL 인젝션과 7행의 비밀키를 가장 심각한 문제로 올리고, 각 문제에 줄 번호와 고친 코드를 붙인 뒤 “수정 요청(Request Changes)”으로 끝납니다. 명령 뒤의 shop.py 자리에 검토할 파일 이름을 넣습니다.
Engineering 플러그인에 들어 있는 것
플러그인은 스킬·명령·외부 연결을 묶어 클로드 코드에 넣는 꾸러미입니다(스킬은 클로드 스킬 글 참고). claude plugin details로 뽑은 1.2.0의 구성은 스킬 10개와 외부 연결(MCP 서버) 10개입니다. 에이전트·훅은 없습니다. README는 이 중 6개를 명령으로 소개하고, 클로드 코드에서는 /engineering:이름으로 부릅니다.
| 스킬 (부르는 명령) | 하는 일 | 이번에 써 봤나 |
|---|---|---|
/engineering:code-review | 보안(인젝션·인증·비밀값·경로 조작)·성능(N+1, 무제한 조회)·정확성(경계값·경쟁 상태·오류 처리)·유지보수 네 갈래로 보고, 요약·심각한 문제 표·제안 표·잘된 점·결론 양식으로 씀 | ✅ 두 번(아래 비교) |
/engineering:debug | 재현 → 범위 좁히기 → 원인 진단 → 수정 → 재발 방지 순서로 디버깅하고 보고서를 씀 | ✅ 한 번(아래 4단계) |
/engineering:architecture · incident-response · deploy-checklist · standup | 기술 선택을 장단점과 결정을 담은 설계 결정 기록(ADR)으로 정리, 장애 심각도 판단·상황 공유·회고 작성, 배포 전 점검표(테스트·데이터베이스 변경·되돌리기 계획), 어제·오늘·막힌 일 형식의 아침 공유 글 | 공식 설명 기준 |
| documentation · system-design · tech-debt · testing-strategy | README·운영 안내서 쓰기, 시스템 설계, 기술 부채 분류·우선순위, 테스트 전략. 명령보다는 클로드가 필요할 때 읽는 참고 문서 | 공식 설명 기준 |
MCP 서버 10개는 슬랙·리니어·아사나·아틀라시안(지라·컨플루언스)·노션·깃허브·페이저듀티·데이터독·구글 캘린더·지메일용 연결 자리입니다. 각 서비스에 로그인해야 쓰고, 이번에는 하나도 쓰지 않았습니다. 파일만 주면 스킬은 그대로 동작합니다.
1단계. 플러그인 깔기 (약 1분)
쓰려는 폴더에서 터미널에 아래 명령을 실행합니다. 첫 줄은 Anthropic의 지식 업무 플러그인 저장소를 등록하는 명령이고, 이미 등록돼 있으면 건너뛰어도 됩니다. --scope local은 이 폴더에서만 켜는 옵션입니다.
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install engineering@knowledge-work-plugins --scope local
claude plugin details engineering
이렇게 나오면 성공 ✔ Successfully installed plugin: engineering@knowledge-work-plugins (scope: local)(플러그인 설치 성공, 범위: 이 폴더). 구성 목록 아래의 Always-on: ~873 tok은 스킬 설명이 대화마다 약 873토큰씩 붙는다는 뜻입니다. 같은 묶음의 Productivity(약 354토큰)보다 무겁습니다. code-review 스킬을 부르면 그때 약 1,200토큰이 더 들어갑니다.
- 설치 명령이 플러그인을 찾지 못하면 첫 줄의 저장소 등록 명령을 먼저 실행합니다.
- README에 따르면 이 플러그인은 Cowork(코워크) 데스크톱 앱용으로 먼저 만들었고 클로드 코드에서도 동작합니다. 이 글은 클로드 코드 터미널 기준입니다.
필요 없어지면 같은 폴더에서 아래 명령으로 지웁니다.
claude plugin uninstall engineering@knowledge-work-plugins --scope local2단계. 검토할 코드 받기 (약 1분)
실습 재료 zip을 풀어 shop.py를 1단계의 폴더에 넣습니다. 84줄짜리 쇼핑몰 주문 처리 코드(파이썬, 기본 내장 sqlite3)이고, 실제 서비스 코드에서 자주 나오는 문제 9개를 일부러 넣었습니다. 9개 모두 실제로 동작하는 것을 verify.py로 먼저 확인했습니다.
| 줄 | 넣어 둔 문제 | verify.py로 돌려 보니 |
|---|---|---|
| 19 | 검색어를 SQL 문장에 그대로 끼움(SQL 인젝션) | 검색창에 공격 문장을 넣자 회원 비밀번호가 상품 목록에 섞여 나옴 |
| 7 | 운영용 관리자 토큰이 코드에 그대로 | 코드에 적힌 값으로 관리자 확인 통과 |
| 25 | offset = page * PAGE_SIZE | 주문 25개인 손님의 1쪽에 21번부터 5개만 나옴 |
| 31~35 | 주문마다 상품 목록을 따로 조회(N+1) | 주문 20개 목록에 쿼리 21번 |
| 40~43 | 주문 주인 확인 없음 | 1번 손님이 2번 손님 주문을 열어 봄 |
| 51 | 수량 0·음수 확인 없음 | 수량 -3 주문 뒤 재고 5→8, 잔액 5만→8만6천 |
| 48~55 | 재고 확인과 차감이 따로(경쟁 상태) | 재고 1개에 동시 주문 2건, 둘 다 성공하고 재고 -1 |
| 69~74 | 쿠폰 오류를 삼키고 None 반환 | 쿠폰 값이 잘못되면 금액 대신 None |
| 78 | 파일 이름을 그대로 경로에 붙임(경로 조작) | ../secret.txt로 폴더 밖 파일을 읽음 |
토큰과 비밀번호는 모두 지어낸 값입니다. 채점 기준은 실행 전에 code-review 스킬 문서의 검토 항목과 결과 양식에서 뽑아 문제 9개와 양식 5개(심각도, 줄 번호, 고친 코드, 잘된 점, 결론)로 고정했고, 요청문에는 넣지 않았습니다.
같은 요청, 세 가지 조건 비교
| 검사 | ① 플러그인 없음 (1·2) | ② 깔아 두기만 (1·2) | ③ /engineering:code-review (1·2) |
|---|---|---|---|
| SQL 인젝션(19행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 코드에 박힌 비밀키(7행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 페이지 계산 한 쪽 밀림(25행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| N+1 쿼리(31~35행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 남의 주문 열람(40~43행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 수량 음수·0 확인 없음(51행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 동시 주문 초과 판매(48~55행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 쿠폰 오류 삼킴(69~74행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 경로 조작(78행) | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 문제마다 심각도·줄 번호·고친 코드 | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 잘된 점 칸 | ❌ ❌ | ❌ ❌ | ✅ ✅ |
| 결론(머지 불가) 한 줄 | ✅ ✅ | ✅ ✅ | ✅ ✅ |
| 합계(14개 중) | 13 · 13 | 13 · 13 | 14 · 14 |
| 플러그인 스킬이 불렸나 | 해당 없음 | 두 번 다 안 불림 | 명령으로 들어감 |
| 코드를 직접 돌려 재현했나 | ❌ ✅ | ❌ ✅ | ✅ ✅ |
| 걸린 시간 | 1분 · 1분 반 | 1분 · 2분 가까이 | 2분 가까이 · 1분 반 |
| 사용량(API 단가) | 0.37 · 0.51달러 | 0.38 · 0.54달러 | 0.54 · 0.53달러 |
문제를 찾는 눈은 여섯 번이 같았습니다. 9개를 모두 찾았고, 점수 밖으로 둔 “잔액 확인 없이 차감”과 “없는 상품이면 오류로 멈춤”도 여섯 번 모두 짚었습니다. 줄 번호도 실제 위치와 맞았습니다. 이번 84줄 코드에서는 Opus 5.5가 플러그인 없이도 같은 구멍을 다 찾았습니다.
차이는 보고서 틀에서 났습니다. 명령으로 부른 두 번은 스킬 문서의 양식을 그대로 따라 Summary(요약)·Critical Issues(심각한 문제)·Suggestions(제안)·What Looks Good(잘된 점)·Verdict(결론) 칸을 만들었고, 칸 이름은 영어로 두고 내용은 한국어로 썼습니다. 잘된 점에는 “다른 쿼리는 물음표 자리 표시자를 써서 안전하다”, “주문 당시 가격을 따로 저장해 둔 설계는 좋다” 같은 내용이 들어갔습니다. 명령 없이 받은 네 번(①·②)은 심각도별 소제목과 머지·배포 전 체크리스트를 스스로 만들었고, 잘된 점 칸은 없었습니다.
코드를 직접 돌려 보고 쓴 리뷰는 여섯 중 넷이었습니다. 임시 폴더에 데이터베이스를 만들어 공격 문장을 넣어 본 재현 결과를 붙였습니다. 스킬 문서에는 코드를 돌려 보라는 지시가 없고, 플러그인 없는 쪽에서도 한 번은 돌렸으니 플러그인 덕분이라고 보기는 어렵습니다. 리뷰를 받을 때 “문제마다 직접 돌려서 재현해 줘”라고 한 줄 붙이면 됩니다.
깔아 두기만 하면 불리지 않았다
②의 두 번은 대화를 시작할 때 engineering 스킬 10개가 목록에 올라와 있었지만, 클로드가 code-review 스킬을 한 번도 부르지 않았습니다. 같은 날 리뷰한 Data·Design 플러그인과 같은 모습이고, 깔아 두기만 해도 스킬이 불린 Productivity와는 달랐습니다. 양식을 원하면 명령으로 불러야 합니다.
3단계. 내 코드 리뷰받기 (약 3분)
검토할 파일을 1단계의 폴더에 넣고 위 요청문의 파일 이름만 바꿔 보냅니다. 받은 review.md는 아래 순서로 보면 됩니다.
- Critical Issues 표의 🔴 줄부터 고칩니다. 줄 번호로 해당 줄을 찾아보고, 아래 수정 예시 코드를 붙여 넣은 뒤 다시 리뷰를 맡깁니다.
- Verdict가 Request Changes(수정 요청)면 머지하지 않습니다. Approve(승인)가 나와도 돈·개인 정보를 다루는 코드라면 사람이 한 번 더 봅니다.
- “이 코드는 결제를 처리한다”, “보안 위주로 봐 줘”처럼 맥락을 붙이면 그쪽을 더 깊게 본다고 스킬 문서에 적혀 있습니다.
/engineering:code-review가 명령으로 안 보이면: 1단계에서 설치한 폴더에서 클로드 코드를 다시 엽니다. 다른 폴더에서는 local 범위 플러그인이 꺼져 있습니다.- 깃허브 PR 주소를 넣고 싶다면 깃허브 연결(MCP)에 로그인해야 합니다. 연결 없이는 파일 경로나 붙여 넣은 변경 내용으로 리뷰합니다.
4단계. /engineering:debug로 버그 하나 고치기 (약 2분)
리뷰에서 나온 문제 하나를 손님 문의 형식으로 다시 맡겨 봤습니다. 디버그 명령은 원인을 찾을 뿐 아니라 코드를 고치고 다시 돌려 확인합니다.
/engineering:debug 손님이 주문 내역 1쪽에 최근 주문이 하나도 안 보인대. 주문은 25개 있는 손님이야. shop.py 보고 원인 찾아서 고쳐 줘.클로드는 주문 25개짜리 시험용 데이터베이스를 따로 만들어 문제를 재현하고, 원인 두 가지(25행의 페이지 계산, 정렬 기준 없음)를 찾아 25·27행을 고친 뒤 다시 돌린 표를 보고서에 붙였습니다. 마지막 답 일부입니다.
| | 1쪽 | 2쪽 |
|---|---|---|
| 기대 | 최신 주문 20개 (25→6) | 나머지 5개 (5→1) |
| 수정 전 | `[21, 22, 23, 24, 25]` (5개만) | `[]` |
| 수정 후 | `[25, 24, … , 6]` (20개) | `[5, 4, 3, 2, 1]` |고친 shop.py를 verify.py로 다시 돌리니 1쪽 첫 주문이 25번, 1쪽 개수가 20개로 나왔습니다. 보고서 끝에는 SQL 인젝션 등 같은 파일의 다른 문제 7가지를 “요청 범위가 아니라 손대지 않았다”며 따로 적었습니다. 시키지 않은 곳은 고치지 않는다는 점에서 실제 서비스 코드에 맡기기 편했습니다. 이번 사용량은 0.36달러였습니다.
이런 사람에게 권합니다
- ✅ 리뷰를 팀원이나 고객에게 넘겨야 하는 사람. 명령으로 부르면 매번 같은 양식(심각한 문제 표·제안 표·잘된 점·결론)으로 나와 비교하고 나누기 쉽습니다.
- ✅ 버그 문의를 받으면 원인과 수정, 재발 방지까지 기록으로 남기고 싶은 사람.
/engineering:debug가 그 순서를 지킵니다. - ✅ 깃허브·지라·슬랙·데이터독을 이미 연결해 둔 팀. PR을 자동으로 가져오고 장애 대응에 모니터링 기록을 끌어올 수 있습니다(이번에는 써 보지 않았고, 공식 설명 기준입니다).
- ❌ 내 코드에 구멍이 있는지만 보고 싶은 사람. 플러그인 없이 “머지해도 되는지 검토해 줘”만 보내도 9개를 다 찾았습니다.
한계와 주의할 점
- 84줄짜리 가상 코드 한 파일로 조건마다 두 번씩만 돌렸습니다. 파일이 수십 개인 실제 프로젝트에서는 결과가 다를 수 있습니다.
- 심어 둔 문제는 교과서에 나오는 종류입니다. 업무 규칙을 알아야 보이는 버그(예: 할인 규칙이 회사 정책과 다름)는 이번 시험에 없습니다.
/engineering:architecture·incident-response·deploy-checklist·standup과 외부 연결은 써 보지 않았습니다.- 스킬 문서와 양식은 영어입니다. 이번에는 칸 이름은 영어로, 내용은 한국어로 나왔습니다.
- 대화마다 약 873토큰이 붙으므로, 개발 일을 하지 않는 폴더에는 깔지 않는 편이 낫습니다.
대안
| 방법 | 다른 점 | 이럴 때 고르세요 |
|---|---|---|
| Engineering 플러그인(이 글) | 코드 리뷰·디버깅·설계 기록·장애 대응을 정해진 양식으로 | 같은 양식의 문서를 계속 남길 때 |
| 플러그인 없이 같은 요청 | 양식은 그때그때, 찾는 문제는 같았음 | 한 번 점검해 볼 때 |
클로드 코드 기본 /code-review | 클로드 코드에 들어 있는 리뷰 명령. 지금 작업 중인 변경 내용을 봄 | 깃으로 관리하는 프로젝트에서 바로 볼 때 |
| 개발 스킬 추천(Superpowers 등) | 계획·테스트 먼저 쓰기 같은 개발 습관 전체를 바꿈 | 리뷰보다 만드는 과정부터 다듬고 싶을 때 |
| 클로드 스킬·플러그인 디렉터리 | 같은 묶음의 다른 업무 플러그인 | 다른 일에 쓸 플러그인을 찾을 때 |
자주 묻는 질문
Engineering 플러그인은 무료인가요?
플러그인 자체는 무료(Apache-2.0)입니다. 쓸 때 클로드 사용량이 들고(이번 비용은 위 비교 표), 구독 요금제라면 그만큼 사용량 한도에서 빠집니다.
README의 /review 명령을 치면 안 돼요
README 표에는 /review, /incident로 적혀 있지만 실제 스킬 이름은 code-review, incident-response입니다. 클로드 코드에서는 /engineering:code-review, /engineering:incident-response로 부릅니다.
파이썬이 아닌 코드도 리뷰하나요?
스킬 문서에는 특정 언어 제한이 없습니다. 이번에는 파이썬 한 파일만 써 봤습니다.
리뷰 결과를 믿고 바로 머지해도 되나요?
이번 시험에서는 심어 둔 문제를 다 찾았지만, 놓친 것이 없다는 보장은 아닙니다. 돈이나 개인 정보를 다루는 코드는 고친 뒤 사람이 한 번 더 보고, 리뷰에 나온 문제를 시험 코드로 남겨 두는 편이 안전합니다.
출처
Engineering 플러그인 README·스킬 10개, code-review SKILL.md, debug SKILL.md, anthropics/knowledge-work-plugins 저장소, 클로드 코드 플러그인 문서, 클로드 앱 “가장 많이 설치된 Skills” 화면(설치 2,012,224건) (모두 2026-10-16 확인, 저장소 별 29,822개)