앤트로픽이 직접 알려주는 클코 워크숍을 알아보자. 미리보기 영상만 보면 “오, Claude Code가 PR도 만들 수 있네” 정도로 끝날 수 있다. 그런데 27분 전체 자막을 따라가보면 핵심은 훨씬 더 분명하다. Claude Code는 프롬프트를 예쁘게 쓰는 도구가 아니라, 작업 환경을 통째로 넘겨받을 때 힘이 나는 에이전트다.
AilaunchX가 공유한 Anthropic Claude Code 워크숍 영상에서 발표자는 처음부터 이 점을 강조한다. Claude Code는 한 줄 자동완성 도구가 아니다. 함수 하나, 파일 하나, 버그 하나, 기능 하나를 통째로 다루는 agentic coding assistant에 가깝다. 그래서 중요한 질문도 바뀐다.
“어떤 프롬프트를 쓰면 코드를 잘 짤까?”보다 먼저 물어야 할 것은 이거다.
Claude가 실제 엔지니어처럼 일하려면 무엇을 보고, 무엇을 실행하고, 무엇으로 자기 결과를 검증해야 할까?
처음부터 코드를 맡기지 말고, 코드베이스를 물어봐야 한다
워크숍에서 가장 실용적인 첫 조언은 의외로 소박하다. 처음부터 “이 기능 만들어줘”라고 던지지 말라는 것이다. 먼저 코드베이스 Q&A부터 시작하라고 한다.
예를 들어 이런 질문이다.
- 이 클래스는 어디에서 쓰이나?
- 이 함수는 왜 인자가 이렇게 많나?
- 이 코드는 어떤 Git 히스토리에서 생겼나?
- 지난주에 내가 무엇을 ship 했나?
이게 중요한 이유는 Claude Code가 단순 검색만 하지 않기 때문이다. 파일을 찾고, 사용 예시를 보고, Git 기록을 뒤지고, 이슈와 PR 맥락까지 연결하면서 “문서처럼 읽히는 답”을 만들 수 있다. 발표자는 Anthropic 내부 온보딩에서도 이 방식을 쓴다고 설명한다. 새로 들어온 사람이 팀원에게 계속 물어보지 않아도, 먼저 Claude Code에게 코드베이스를 묻고 감을 잡게 하는 식이다.
여기서 독자가 가져가야 할 포인트는 명확하다. Claude Code를 잘 쓰는 첫 단계는 코드를 시키는 게 아니라, 코드베이스에 대해 대화하는 것이다. 이 과정을 거쳐야 모델이 어디까지 한 번에 해낼 수 있고, 어디부터 사람의 손잡이가 필요한지 감이 생긴다.
도구를 연결하면 프롬프트가 아니라 워크플로가 바뀐다
중간 구간에서 워크숍의 톤이 바뀐다. Claude Code가 진짜 빛나는 지점은 도구를 붙였을 때다. 발표자는 크게 두 종류를 말한다. 하나는 bash 도구, 다른 하나는 MCP 도구다.
이 부분이 중요하다. Claude에게 “테스트도 해봐”라고 말하는 것과, 실제로 테스트 명령을 실행할 수 있게 해주는 것은 완전히 다르다. “브라우저 화면도 확인해봐”라고 말하는 것과, Puppeteer나 iOS simulator 스크린샷을 직접 확인하게 해주는 것도 다르다. 모델에게 피드백 도구가 생기면 결과물을 한 번 만들고 끝내는 게 아니라, 스스로 보고 고치고 다시 확인하는 반복 루프가 열린다.
그래서 Claude Code 워크플로는 대략 이렇게 바뀐다.
- 코드베이스를 탐색한다.
- 먼저 계획을 세운다.
- 필요한 파일을 고친다.
- 테스트나 스크린샷으로 결과를 확인한다.
- 실패하면 다시 고친다.
- Git 커밋, 브랜치, PR까지 이어간다.
이건 “코드 짜줘”가 아니다. 일하는 순서를 Claude에게 맡기되, 검증할 도구까지 같이 주는 방식이다. 이 차이가 크다. 프롬프트만 길게 쓰면 결과가 좋아지는 데 한계가 있지만, 도구를 붙이면 모델의 행동 반경이 달라진다.
컨텍스트는 많이 주는 게 아니라, 오래 쓸 수 있게 정리하는 것이다
후반부의 핵심은 컨텍스트다. 발표자는 Claude Code에 더 많은 맥락을 줄수록 판단이 좋아진다고 말한다. 다만 여기서 말하는 컨텍스트는 긴 설명문을 매번 붙여넣는 방식이 아니다.
워크숍에서는 CLAUDE.md 같은 프로젝트 문맥 파일, 개인용 로컬 문맥, 하위 디렉터리별 문맥, slash command, mention file, enterprise policy 같은 계층을 설명한다. 이름은 환경마다 다르게 들릴 수 있지만, 원리는 단순하다.
팀이 반복해서 설명하는 내용을 한 번 정리해두는 것이다.
- 자주 쓰는 bash 명령
- MCP 서버와 사용법
- 스타일 가이드
- 아키텍처 결정
- 중요한 파일 위치
- 테스트 방식
- 접근하면 안 되는 URL이나 막아야 할 명령
여기서 중요한 건 “무조건 길게 쓰자”가 아니다. 발표자는 오히려 짧게 유지하라고 말한다. 너무 긴 문맥은 토큰을 잡아먹고, 실제 판단에는 도움이 안 될 수 있다. 좋은 컨텍스트는 백과사전이 아니라 작업 안내서에 가깝다.
Claude가 매번 물어보지 않아도 되는 팀의 암묵지를 파일로 바꾸는 것. 이게 컨텍스트 설계의 핵심이다.
SDK와 파이프라인은 Claude Code를 ‘도구’에서 ‘부품’으로 바꾼다
영상 후반에는 Claude Code SDK 이야기도 나온다. 이 부분은 개발자에게 특히 중요하다. CLI에서 한 번 쓰고 끝나는 것이 아니라, JSON 출력이나 streaming JSON으로 받아서 CI, incident response, 내부 파이프라인에 넣을 수 있다는 설명이다.
이 관점에서 Claude Code는 앱 하나가 아니라 유닉스 유틸리티처럼 다룰 수 있다. 입력을 주고, 결과를 받고, 다른 도구와 pipe로 연결한다. 그러면 “Claude Code를 켜서 대화한다”를 넘어서, “우리 팀의 반복 업무 안에 Claude Code를 끼워 넣는다”가 된다.
이건 교사나 콘텐츠 제작자에게도 힌트가 된다. AI 도구를 잘 쓴다는 건 대단한 프롬프트 하나를 외우는 일이 아니다. 내가 반복하는 업무에서 어떤 단계가 탐색이고, 어떤 단계가 작성이고, 어떤 단계가 검증인지 나누는 일이다. 그 다음 각 단계에 필요한 도구와 문맥을 AI에게 연결하는 것이다.
그래서 좋은 프롬프트란 무엇인가
이 워크숍을 보고 나면 “좋은 프롬프트”의 정의가 바뀐다.
좋은 프롬프트는 멋진 문장 하나가 아니다. 좋은 프롬프트는 Claude가 일할 수 있는 환경을 여는 첫 문이다. 코드베이스를 물어보고, 계획을 요구하고, 팀 도구를 알려주고, 테스트로 확인하게 하고, 팀 규약을 문맥 파일로 남기는 것까지 포함한다.
그러니까 Claude Code를 제대로 쓰고 싶다면 이렇게 시작하는 게 좋다.
- 처음엔 코드베이스 Q&A로 모델의 감을 본다.
- 큰 작업은 바로 시키지 말고 계획부터 요구한다.
- 테스트, 스크린샷, Git, PR 같은 검증 도구를 연결한다.
- 팀 규약과 자주 쓰는 명령을 짧은 문맥 파일로 남긴다.
- 반복 업무는 slash command나 SDK 파이프라인으로 만든다.
내가 보기엔 이 영상의 메시지는 “Claude Code가 코딩을 대신한다”가 아니다. 더 정확히는 Claude Code가 일할 수 있는 작업장을 사람이 설계해야 한다는 쪽에 가깝다.
프롬프트는 질문 기술이 아니라 업무 설계다. 그리고 Claude Code 시대의 업무 설계는, 모델에게 무엇을 말할지보다 모델이 무엇을 보고 실행하고 검증할 수 있게 할지를 정하는 일이다.
출처: AilaunchX가 공유한 Anthropic Claude Code 워크숍 영상
원문: https://x.com/Ai_Tech_tool/status/2061515874545344716
Threads 미리보기: https://www.threads.com/@conanssam/post/DZE3eClDqUz