먼저 프롬프트가 아니라
‘설정’을 점검하세요
Claude를 오래 사용한다고 해서 결과가 자동으로 좋아지는 것은 아닙니다.
매번 새로운 대화창을 열고
자료를 다시 설명하고,
원하는 스타일을 다시 알려주고,
프로젝트 배경을 처음부터 입력하고 있다면—
Claude를 ‘대화형 챗봇’으로만 사용하고 있을 가능성이 큽니다.
Claude Cowork의 핵심은 단순합니다.
좋은 결과 = 좋은 프롬프트 하나가 아니라
구조(Structure) + 컨텍스트(Context) + 규칙(Rules) + 도구(Tools)의 결합
단 60분만 투자해도 Claude를 반복 질문에 답하는 도구에서 나의 업무 방식을 이해하고 반복 실행하는 작업 시스템으로 바꿀 수 있습니다.
01. 먼저 ‘기반’을 설정하세요
Claude에게 일을 시키기 전에 어떻게 일해야 하는지부터 알려줘야 합니다.
예를 들어 다음을 정의합니다.
→ 내가 원하는 답변 방식
→ 문체와 톤앤매너
→ 반드시 지켜야 할 기준
→ 파일과 폴더 관리 원칙
→ 결과물의 기본 형식
→ 실행 전에 확인해야 할 사항
특히 복잡하거나 중요한 업무라면 처음부터 실행시키기보다,
“바로 작업하지 말고, 필요한 질문부터 해주세요.”
라고 설정하는 것이 효과적입니다.
Claude가 추측해야 하는 부분을 줄일수록 결과의 정확성과 일관성이 높아집니다.
02. 업무를 4개의 핵심 폴더로 구조화하세요
가장 단순하면서도 강력한 구조입니다.
ABOUT ME
나의 목표, 업무, 독자, 선호 스타일, 작성 기준
PROJECTS
현재 진행하고 있는 프로젝트별 자료와 컨텍스트
TEMPLATES
반복해서 사용하는 Prompt, SOP, 체크리스트, 보고서 양식
OUTPUTS
Claude와 함께 완성한 최종 결과물
여기서 중요한 것은 파일을 많이 넣는 것이 아닙니다.
Claude가 “어떤 정보가 어디에 있고, 언제 사용해야 하는가”를 이해할 수 있도록 만드는 것입니다.
자료가 많다고 컨텍스트가 좋아지는 것은 아닙니다.
정리된 정보가 좋은 컨텍스트를 만듭니다.
03. 프로젝트마다 독립적인 Context를 만드세요
모든 업무를 하나의 거대한 프로젝트에 넣으면 시간이 지날수록 정보가 섞입니다.
예를 들어,
뉴스레터 작성
웹사이트 개발
ISO 인증심사
마케팅 콘텐츠
고객 제안서 작성
이 업무들은 목적과 판단 기준이 모두 다릅니다.
따라서 프로젝트마다 최소한 다음 정보를 분리해 두는 것이 좋습니다.
→ 프로젝트 목표
→ 대상 사용자·독자
→ 필요한 참고자료
→ 업무 범위
→ 결과물 형식
→ 품질 기준
→ 하지 말아야 할 것
프로젝트 하나 = 하나의 명확한 업무 Context
이 원칙만 잘 지켜도 Claude가 엉뚱한 과거 정보를 끌어오는 문제를 크게 줄일 수 있습니다.
04. 핵심 Markdown 파일을 만드세요
수십 개의 파일을 무작정 업로드하는 것보다 잘 설계된 핵심 파일 몇 개가 훨씬 강력합니다.
대표적으로 다음 두 파일부터 시작할 수 있습니다.
about-me.md
Claude가 나와 내 업무를 이해하도록 만드는 파일입니다.
→ 나는 누구인가
→ 어떤 일을 하는가
→ 주요 고객과 독자는 누구인가
→ 어떤 결과물을 원하는가
→ 선호하는 문체는 무엇인가
→ 좋은 결과물의 예시는 무엇인가
anti-ai-writing-style.md
Claude가 “어떻게 쓰지 말아야 하는가”를 알려주는 파일입니다.
→ 사용하지 않을 상투적 표현
→ 지나치게 AI처럼 보이는 문장
→ 반복되는 문장 패턴
→ 과장된 표현
→ 피해야 할 단어
→ 좋지 않은 결과물 사례
좋은 예제를 알려주는 것만큼 나쁜 예제를 명확하게 알려주는 것도 중요합니다.
05. 필요한 도구와 연결하세요
Claude의 활용 범위는 대화창 안에서 끝날 필요가 없습니다.
업무 목적에 맞게 연결하면,
Claude → Context → Tool → Action
구조를 만들 수 있습니다.
예를 들어,
Google Drive → 원본 문서와 프로젝트 자료
Slack → 팀 커뮤니케이션 Context
Notion → 문서·지식·프로젝트 관리
기타 연결 도구 → 실제 업무 Workflow 실행
하지만 중요한 원칙이 하나 있습니다.
도구를 많이 연결하는 것이 자동화가 아닙니다.
업무 구조가 없는 상태에서 도구만 연결하면 정보가 더 복잡해질 수 있습니다.
반대로,
잘 설계된 Context + 필요한 도구만 연결
하면 실제 생산성이 크게 높아집니다.
06. 이제 ‘실제 업무’ 하나를 실행하세요
처음부터 거대한 자동화 시스템을 만들 필요는 없습니다.
실제 업무 하나부터 테스트하세요.
예를 들어,
“이번 주 뉴스레터를 만들고 싶습니다. 실행하기 전에 필요한 질문부터 해주세요.”
“이 회의 메모를 Facebook 게시물로 만들고 싶습니다. 먼저 부족한 정보를 질문해주세요.”
“새 프로젝트의 실행계획을 만들고 싶습니다. 계획을 작성하기 전에 요구사항부터 확인해주세요.”
첫 번째 작업에서는 시스템을 테스트하고,
두 번째 작업에서는 규칙을 수정하고,
세 번째부터는 템플릿으로 만들기 시작합니다.
그리고 같은 업무가 반복되면
Prompt → Template → Workflow → Skill/Agent
순으로 발전시킬 수 있습니다.
결국 중요한 것은 ‘프롬프트 기술’보다 ‘Context Engineering’입니다
Claude에게 매번 길고 복잡한 프롬프트를 작성해야 한다면 아직 시스템화가 충분하지 않은 것입니다.
잘 구축된 환경에서는 Claude가 이미 알고 있어야 합니다.
WHO — 나는 누구인가?
WHY — 왜 이 일을 하는가?
WHAT — 무엇을 만들어야 하는가?
HOW — 어떤 방식과 기준으로 작업해야 하는가?
WHERE — 필요한 자료는 어디에 있는가?
VERIFY — 결과가 올바른지 어떻게 검증할 것인가?
그래서 저는 이 흐름을 이렇게 정리하고 싶습니다.
Structure → Context → Rules → Tools → Execute → Verify → Improve
그리고 반복 업무에서는 다시,
Execute → Evaluate → Improve → Reuse
라는 작은 Loop가 만들어집니다.
이때부터 Claude는 단순히 질문에 답하는 도구가 아니라 업무 시스템의 일부가 됩니다.
60분 후 달라져야 할 것은 이것입니다
Before
질문 → 설명 → 파일 첨부 → 다시 설명 → 수정 → 또 수정
After
업무 요청
↓
프로젝트 Context 로딩
↓
규칙·템플릿 적용
↓
필요한 도구 활용
↓
결과 생성
↓
검증
↓
피드백 반영
↓
다음 작업에서 재사용
결국 Claude 활용의 경쟁력은 얼마나 멋진 프롬프트를 한 번 작성했느냐보다,
좋은 결과가 반복해서 나오도록 업무 환경을
얼마나 잘 설계했느냐에서 결정됩니다.
한 문장으로 정리하면
Claude의 성능을 바꾸려고 하기 전에 Claude가 일하는 환경부터 바꾸세요.
구조를 먼저 만들고 → Context를 고정하고 →
규칙을 정의하고 → 도구를 연결하고 →
실제 업무로 검증하세요.
좋은 Claude 결과는 좋은 설정에서 시작됩니다.
Structure First. Context Locked.
Then Prompt.
여러분이라면 지금 Claude 환경에서 가장
먼저 무엇을 바꾸시겠습니까?
— 이춘곤(Mark) · ISC.studio · ISC출판 도서 안내
이 글은 저자의 Facebook에 처음 게시한 글입니다. Facebook 원문 보기
💬 댓글 (0)