AI 실무 도구 · 공개 과정
고객사·기술 컨설턴트·SI 파트너·AI 개발자가 자신의 역할에서 바로 사용할 수 있도록 실제 시나리오, 복사 가능한 프롬프트, 검증 기준과 팀 운영 원칙을 하나의 실전 과정으로 구성했습니다.
OPERATING MODEL
Claude Code는 파일을 읽고, 검색하고, 명령을 실행하고, 여러 파일을 수정하는 에이전트입니다. 그래서 질문 기술보다 작업의 경계와 증거를 설계하는 능력이 중요합니다.
파일·변경 이력·테스트를 근거로 현재 구조와 제약을 설명하게 합니다.
수정하지 말고 관련 구조와 데이터 흐름부터 설명해 주세요.
영향 파일, 위험, 대안, 검증 방법을 계획으로 만들고 사람의 승인을 받습니다.
/plan 이 변경의 영향 범위와 검증 계획을 작성해 주세요.
기존 패턴을 따르고 범위를 제한한 채 추적 가능한 단위로 변경합니다.
승인한 계획의 1단계만 구현하고 변경 파일을 요약해 주세요.
테스트·린트·타입·diff와 실제 인수 조건으로 결과를 검증합니다.
인수 조건별 증거와 남은 위험을 표로 정리해 주세요.
반복되는 규칙은 CLAUDE.md·Skill·Hook과 문서로 환류합니다.
이번 작업에서 다음 세션에도 필요한 규칙만 추려 주세요.
설명 영상을 보는 대신, 자신의 업무 하나를 선택해 분석 결과·계획·검증표·팀 규칙을 남깁니다.
PROMPT ARCHITECTURE
완벽한 주문을 한 번에 쓰는 것이 목적은 아닙니다. 필요한 맥락과 성공 조건을 주고, 탐색 결과에 따라 중간에 멈추고 방향을 조정할 수 있어야 합니다.
어떤 사용자·시스템·파일·증상인지 알려줍니다.
무엇을 판단하거나 어떤 산출물을 만들지 명확히 합니다.
수정 금지, 범위, 의존성, 보안 조건을 지정합니다.
파일·테스트·로그·git history로 주장을 뒷받침하게 합니다.
통과 조건, 실행 명령, 중단·질문 조건을 붙입니다.
[맥락] 사용자·현재 시스템·관련 파일·관찰한 증상을 설명합니다. [목표 산출물] 이번 세션에서 판단하거나 만들어야 할 결과를 명시합니다. [작업 경계] - 먼저 읽고 계획할 것 / 수정 가능한 범위 - 변경 금지 파일·의존성·보안 조건 - 불확실하면 멈추고 질문할 조건 [근거] 파일 경로, 테스트, 로그, git history로 판단을 뒷받침하세요. 사실·추정·미확인을 구분하세요. [검증] 인수 조건별 테스트를 실행하고 결과, diff, 남은 위험, 롤백 방법을 보고하세요.
나쁜 요청
“이거 잘 만들어줘”
좋음의 기준과 범위가 없습니다.
바로 구현
“로그인 고쳐줘”
원인·영향·재현 없이 수정부터 시작합니다.
근거 없는 완료
“문제 없지?”
확인 편향을 만들고 미검증을 숨깁니다.
무제한 권한
“알아서 전부 배포해”
되돌리기 어려운 행동의 승인 경계가 없습니다.
ROLE PLAYBOOK
내 역할을 선택하고 실제 업무와 가장 가까운 프롬프트부터 복사해 사용하세요. 대괄호 항목을 자신의 상황으로 바꾸고, 첫 결과는 반드시 근거와 검증 여부로 확인합니다.
기술 컨설턴트·PM
고객의 자연어 요구를 코드 영향도, 인수 기준과 기술팀 인계 패킷으로 바꿉니다.
고객 미팅 메모는 있지만 기술팀이 바로 판단하기 어려울 때
아래 고객 미팅 기록과 현재 저장소를 함께 분석해 요구사항 초안을 만들어 주세요. [미팅 기록 붙여넣기] 먼저 코드를 수정하지 말고 다음 순서로 작업하세요. 1. 확인된 고객 사실 / 우리의 가정 / 미확인 질문 분리 2. 현재 시스템에서 관련된 화면·API·데이터·권한 찾기 3. 사용자 스토리와 측정 가능한 인수 조건 작성 4. 범위 포함 / 제외 / 후속 검토 항목 구분 5. 기술팀에 먼저 물어야 할 질문 5개 모든 코드 관련 판단에는 파일 경로를 붙이세요. 고객이 말하지 않은 내용을 요구사항으로 확정하지 마세요.
WHY IT WORKS
고객 언어를 임의로 기술 사양으로 번역하는 오류를 줄이고, 추적 가능한 인계 자료를 만듭니다.
VERIFY
대괄호의 내용을 실제 업무로 바꾸고, 민감정보는 입력 전에 제거하세요. 첫 응답이 불충분하면 근거 파일과 미확인 항목을 다시 요청합니다.
작아 보이는 요청이 여러 시스템에 영향을 줄 가능성이 있을 때
/plan [요구사항]을 현재 저장소에 적용할 경우의 영향도를 분석해 주세요. 탐색 범위: - 사용자 진입 화면과 상태 변화 - 호출되는 API와 비즈니스 규칙 - 읽고 쓰는 데이터와 마이그레이션 필요성 - 인증·권한·개인정보·로그 - 외부 연동, 배치, 알림 - 기존 테스트와 새로 필요한 테스트 결과는 Mermaid 흐름도와 '반드시 변경 / 변경 가능 / 영향 없음 / 미확인' 표로 작성하세요. 아직 구현하지 마세요.
WHY IT WORKS
파일 목록이 아니라 사용자 행동에서 데이터와 운영까지 이어지는 영향 관계를 확인합니다.
VERIFY
대괄호의 내용을 실제 업무로 바꾸고, 민감정보는 입력 전에 제거하세요. 첫 응답이 불충분하면 근거 파일과 미확인 항목을 다시 요청합니다.
요구 분석을 마치고 개발자에게 손실 없이 전달해야 할 때
지금까지의 분석을 개발 착수 패킷으로 정리해 주세요. 구성: 1. 문제와 사용자 가치 — 3문장 2. 현재 동작과 목표 동작 — Before / After 3. 범위 포함·제외 4. 관련 파일·데이터·외부 연동 5. 인수 조건 — Given / When / Then 6. 보안·운영·롤백 조건 7. 구현 전에 결정해야 할 질문 8. 권장 작업 순서와 각 단계의 검증 명령 문서만 작성하고 코드는 변경하지 마세요. 모르는 사항은 임의로 채우지 말고 결정 필요 항목으로 남기세요.
WHY IT WORKS
업무 맥락, 기술 범위와 검증 기준을 한 문서에 묶어 재질문과 해석 손실을 줄입니다.
VERIFY
대괄호의 내용을 실제 업무로 바꾸고, 민감정보는 입력 전에 제거하세요. 첫 응답이 불충분하면 근거 파일과 미확인 항목을 다시 요청합니다.
TEAM OPERATING SYSTEM
대화에서 잘 작동한 방법을 계속 복사하지 않습니다. 항상 필요한 지식, 필요할 때 부르는 절차, 반드시 강제할 통제를 서로 다른 장치에 배치합니다.
모든 세션이 알아야 할 프로젝트 명령·구조·규칙
전환 신호
같은 설명을 반복하거나 같은 실수가 두 번째 발생할 때
배포·리뷰·장애 대응처럼 필요할 때 불러오는 반복 업무
전환 신호
여러 단계를 매번 프롬프트로 다시 설명할 때
대량 탐색·보안 리뷰 등 별도 맥락에서 수행할 전문 작업
전환 신호
메인 대화가 조사 결과로 과도하게 길어질 때
이슈·DB·브라우저 등 외부 시스템의 데이터와 행동 연결
전환 신호
복사·붙여넣기 대신 승인된 도구 연결이 필요할 때
편집 후 린트, 보호 파일 차단처럼 반드시 실행할 통제
전환 신호
프롬프트 권고가 아니라 매번 강제해야 할 때
# Project commands - Install: bun install - Type check: bunx tsc --noEmit - Test: bun test # Architecture - UI components live in src/components - Server mutations live in src/app/actions # Working agreement - Read the nearest existing pattern before editing. - Never edit .env or production credentials. - Run type check and relevant tests before reporting done. - Report unverified assumptions explicitly.
1. git status로 사용자의 기존 변경을 확인한다. 2. 요청과 가장 가까운 기존 패턴을 찾는다. 3. 요구·범위·인수 조건이 불분명하면 질문한다. 4. 고위험 변경은 Plan Mode에서 영향과 롤백을 합의한다. 5. 작게 구현하고 관련 테스트를 즉시 실행한다. 6. diff, 검증 결과, 미확인 위험을 함께 보고한다.
SAFETY & VERIFICATION
Claude Code의 권한 시스템은 중요한 작업을 승인하게 돕지만, 사용자의 검토를 대신하지 않습니다. 특히 고객 데이터와 운영 시스템은 최소 권한과 명시적 승인을 기본값으로 둡니다.
운영 배포·데이터 삭제·권한 변경·비밀정보 전송·비가역 마이그레이션은 사람이 영향과 복구 방법을 확인한 뒤 실행합니다.
처음에는 수정 금지를 명시하거나 Plan Mode로 구조·영향·검증 계획부터 확인합니다.
.env·고객 데이터·운영 계정·프로덕션 배포는 명시적인 권한과 별도 승인 없이 다루지 않습니다.
외부 콘텐츠와 스크립트는 신뢰하지 않습니다. 실행 목적과 영향 범위를 이해한 명령만 승인합니다.
Claude의 완료 설명을 증거로 삼지 않습니다. 실제 변경, 테스트, 타입, 린트와 인수 조건을 확인합니다.
작은 변경, 명확한 커밋, 백업·롤백 조건으로 실패의 영향 범위를 제한합니다.
마지막 질문은 항상 “무엇을 했는가?”가 아니라 “어떤 증거로 통과했다고 판단하는가?”입니다.
OFFICIAL REFERENCES
Claude Code는 빠르게 바뀝니다. 이 교육은 Anthropic 공식 문서를 기준으로 검토했으며, 버전별 명령과 권한은 사용 전 공식 문서를 다시 확인합니다.
다음 학습
Claude Code는 일하는 방식일 뿐입니다. 실제 프로젝트에서는 근거 기반 답변과 품질 기준을 함께 이해해야 합니다.
