안녕하세요 석석님, 먼저 CodeGraft 가 아닌 CodeCraft 로, 우선 도메인스토리텔링에 대해 자료를 좀 찾아보았습니다. 그러다보니 조금 답변이 늦게 되었습니다. 도메인스토리텔링이 포함된다고 볼 수 있지만, CodeCraft 문제를 해결하는 일부 단계에 적용될 수 있다고 말씀드릴 수 있습니다. 정확한 정의는 실무형/시스템 엔지니어링 문제로 OOD + Leetcode 가 결합된 형태라고 보시면 조금 더 쉽게 이해하실 수 있을 것 같습니다. 감사합니다.
안녕하세요. 준원님, 좋은 질문입니다. 이 부분은 처음 보면 충분히 헷갈릴 수 있습니다. 결론부터 말씀드리면, 실제 사용에서는 SKILL.md 에 이미 정의된 작업 절차를 프롬프트에 다시 전부 적을 필요가 없습니다. 예를 들어 netflix-history Skill 안에 이미 다음과 같은 절차가 있다고 가정해보겠습니다. 1. 시청 기록을 분석한다 2. 패턴을 분류한다 3. 선호도를 추론한다 4. 결과를 바탕으로 플랜을 만든다 그렇다면 일반적인 요청은 아래 정도면 충분합니다. netflix-history Skill을 사용해서 이 사용자의 시청 기록을 분석하고 플랜을 만들어줘 즉 역할을 나누면 이렇게 이해하시면 좋습니다. Prompt → 이번에 무엇을 해달라는지 Skill → 그 일을 어떤 절차로 수행할지 SKILL.md 가 필요한 이유도 여기에 있습니다. 매번 프롬프트에 동일한 작업 순서, 분석 기준, 검증 방법 등을 반복해서 넣지 않고 재사용 가능한 작업 방법을 Skill로 분리해두는 것 입니다. 넷플릭스 히스토리 실습에서 Skill에 들어 있는 내용을 프롬프트에서도 일부 다시 언급한 것은, Skill이 없어서는 안 돼서라기보다는 실습에서 어떤 요구사항을 중요하게 보고 있는지 명확하게 보여주고, 해당 실행에서 특히 지켜야 할 조건을 강조하기 위한 목적 으로 보시면 됩니다. 실제 Harness를 구성할 때는 오히려 중복을 줄이는 쪽이 좋습니다. 예를 들면 이런 식입니다. SKILL.md - 시청 기록 분석 순서 - 분류 방법 - 결과 작성 형식 - 반복적으로 사용하는 검증 기준 사용자 Prompt에는: 이 Skill을 사용해서 최근 6개월의 시청 기록을 기준으로 가족과 함께 볼 콘텐츠 위주의 플랜을 만들어줘 처럼 이번 Task에만 해당하는 정보 를 적습니다. 여기서 최근 6개월 , 가족과 함께 볼 콘텐츠 같은 것은 이번 요청에만 적용되는 조건이므로 Prompt에 들어가는 것이 맞습니다. 반면 Skill에 이미 있는 시청 기록을 분류한다 선호도를 분석한다 플랜을 작성한다 같은 공통 절차를 매번 다시 적을 필요는 없습니다. 그래서 질문해 주신 것처럼, 프롬프트에 같은 내용을 다시 적으면 그 내용을 이번 실행에서 더 명확하게 강조하는 효과는 있을 수 있습니다. 하지만 Skill을 제대로 설계했다면 재사용되는 절차까지 매번 복사해서 적는 것을 기본 사용법으로 생각하시면 안 됩니다. 정리하면 이렇게 보시면 됩니다. Prompt -> 이번에 무엇을 원하는가 + 이번 작업에만 존재하는 조건 Skill -> 이런 종류의 작업을 반복해서 어떻게 수행할 것인가 그래서 좋은 Skill일수록 사용자의 Prompt는 오히려 짧아질 수 있습니다. 그리고 MVP 관련해서도 기다려주셔서 감사합니다. 하네스 엔지니어링으로 MVP를 개발하고 배포하는 섹션은 커리큘럼에 포함되어 있습니다. 현재 커리큘럼이 구성되고 파일럿 강의 촬영으로 커리큘럼과 강의 흐름을 검토중에 있습니다. 단순히 Claude Code 기능을 따라 하는 프로젝트가 아니라, 실제로 요구사항을 잡고 하네스를 구성한 뒤 MVP 를 개발하실 수 있도록 만들고 있어서 준비되는 대로 강의에 추가하겠습니다 감사합니다. 이번 9월 내로 업데이트를 할 계획에 있습니다.
안녕하세요 준원님, 아주 좋은 질문을 해주셨습니다. 질문 주신 부분은 헷갈릴 수 있습니다. INSTRUCTION / CONTEXT / EVIDENCE / STATE 는 정보를 성격에 따라 구분하는 기준이고, Context Pack 은 특정 작업을 수행하기 위해 그중 필요한 정보만 모아서 Claude에게 전달하는 실행 단위 라고 이해하시면 됩니다. 그래서 CLAUDE.md 안에 네 가지를 전부 넣어야 하는 것도 아니고, 사용자가 매번 Task를 줄 때 Context Pack의 모든 항목을 직접 작성해야 하는 것도 아닙니다. 구조를 먼저 보면 이렇게 이해하시면 가장 쉽습니다. INSTRUCTION ─┐ CONTEXT ─────┤ EVIDENCE ────┼── 필요한 것만 선택 ──> Context Pack ──> Claude STATE ───────┘ 여기서 네 가지는 각각 역할이 다릅니다. INSTRUCTION 어떻게 작업해야 하는가관련 파일부터 검색해라, 수정 후 테스트해라 CONTEXT 작업을 이해하기 위해 알아야 하는 배경 정보프로젝트 구조, 사용 중인 프레임워크, 관련 API 구조 EVIDENCE 현재 판단의 근거가 되는 실제 관찰 결과검색 결과, 코드 내용, 테스트 실패 메시지 STATE 작업이 현재 어디까지 진행됐는가수정한 파일, 현재 가설, 실패한 테스트, 다음 행동 그리고 Context Pack은 이 네 가지 중 현재 작업에 필요한 정보만 묶은 것 입니다. 예를 들어 사용자가 이렇게 요청했다고 해보겠습니다. 로그인은 성공하는데 새로고침하면 로그아웃됩니다. 수정해주세요. 처음부터 Context Pack에 모든 정보가 있는 것은 아닙니다. 처음에는 이렇게 시작할 수 있습니다. Context Pack -> 초기 상태 TASK - 새로고침 후 로그인 상태가 사라지는 문제 수정 INSTRUCTION - 전체 저장소를 읽기 전에 관련 코드를 먼저 검색 - 수정 후 auth 관련 테스트 실행 CONTEXT - React frontend - Node backend - session 기반 authentication EVIDENCE - 아직 없음 STATE - 아직 조사 시작 전 이후 Claude가 검색합니다. rg -n "session|cookie|auth" src server tests 그러면 새로운 정보가 생깁니다. EVIDENCE - src/auth/session.ts에서 cookie 설정 발견 - tests/auth/session.test.ts 존재 테스트를 실행했더니 AssertionError: secure cookie expected true received false 가 나왔다고 해보겠습니다. 이것도 EVIDENCE 입니다. 그리고 현재 진행 상황은 STATE 에 들어갑니다. STATE - src/auth/session.ts 확인 완료 - session.test.ts 실패 - 현재 가설: NODE_ENV에 따라 secure 옵션이 달라짐 - 다음 행동: environment initialization 확인 따라서 작업이 진행되면서 Context Pack도 이렇게 바뀝니다. User Task │ ▼ 초기 Context Pack │ ▼ Search / Read / Test │ ├── 새로운 코드 발견 ───────> EVIDENCE 추가 │ ├── 테스트 실패 ────────────> EVIDENCE 추가 │ └── 진행 상태 변경 ─────────> STATE 갱신 │ ▼ 업데이트된 Context Pack │ ▼ 다음 판단 그러면 CLAUDE.md 에는 무엇을 넣어야 하는지를 보시면, 보통 CLAUDE.md 는 네 가지 중 INSTRUCTION과 비교적 안정적인 CONTEXT 가 중심입니다. 예를 들어 # Instructions Search for relevant symbols and tests before opening many full files. Run the narrowest relevant test after modifying code. # Project Context - Frontend: React - Backend: Node.js - Authentication: session-based 이런 내용은 여러 Task에서 반복해서 사용할 수 있기 때문에 CLAUDE.md 에 둘 수 있습니다. 반대로 다음 내용은 CLAUDE.md 에 넣는 것이 적절하지 않습니다. EVIDENCE - session.test.ts 84번째 줄에서 실패함 STATE - session.ts 수정 완료 - 현재 두 번째 시도 중 이건 특정 작업을 수행하면서 생긴 동적인 정보 이기 때문입니다. 즉, 이렇게 구분하시면 됩니다. CLAUDE.md │ ├── INSTRUCTION ← 주로 여기 │ └── stable CONTEXT ← 필요한 경우 여기 Runtime │ ├── Task-specific CONTEXT ├── EVIDENCE └── STATE │ ▼ Context Pack 사용자가 Context Pack을 직접 작성해야 하는 것은 아닙니다. 오히려 하네스를 설계하는 목적 중 하나가 사용자가 매번 이런 정보를 직접 정리하지 않아도 되도록 하는 것 입니다. 사용자는 보통 그냥 Task를 줍니다. "로그인 후 새로고침하면 세션이 사라지는 문제를 수정해줘." 그다음에는 하네스가 아래처럼 필요한 정보를 구성하게 만드는 것이 목표입니다. Task ↓ 기본 Instruction 로드 ↓ 관련 Context 선택 ↓ Search ↓ Evidence 수집 ↓ State 기록 ↓ Context Pack 구성 ↓ Claude 따라서 Context Pack 은 꼭 하나의 실제 .md 파일이어야 하는 것도 아닙니다. “이번 판단에 Claude에게 어떤 정보를 전달할 것인가”를 설명하기 위한 논리적인 단위 라고 보는 것이 더 정확합니다. 그리고 한 가지 더 중요한 점이 있습니다. Context Pack에 항상 네 항목이 모두 풍부하게 들어갈 필요도 없습니다. 작업 시작 직후에는 INSTRUCTION 있음 CONTEXT 조금 있음 EVIDENCE 없음 STATE 거의 없음 일 수 있고, 작업 중반에는 INSTRUCTION 있음 CONTEXT 있음 EVIDENCE 많이 생김 STATE 있음 으로 변합니다. 그래서 정리해보면, INSTRUCTION / CONTEXT / EVIDENCE / STATE는 “정보를 어떤 성격으로 관리할 것인가”에 대한 분류이고, Context Pack은 현재 작업에서 다음 판단을 위해 필요한 정보만 이 네 종류에서 골라 구성한 묶음입니다. CLAUDE.md 에는 주로 지속적으로 필요한 INSTRUCTION과 안정적인 CONTEXT 를 두고, EVIDENCE 와 STATE 는 작업을 수행하면서 하네스가 수집하고 갱신한다고 이해하시면 됩니다. 질문 주신 두 가지 해석 중에서는 두 번째가 조금 더 가깝지만 , “사용자가 Context Pack을 매번 직접 만들어서 줘야 한다”는 부분만 빼시면 정확합니다. Context Pack은 사용자가 작성하는 Prompt 양식이라기보다 Harness가 실행 중 구성해주는 Context 구조 라고 보시면 됩니다 감사합니다. 좋은 하루 되시길 바라며, 또 다른 질문 있으시다면 언제든지 남겨주세요!
안녕하세요 김다현님, 좋은 의견 감사합니다. 말씀해주신 부분은 저도 중요하게 보고 있는 주제입니다. 현재 강의에서는 에이전트의 성능과 안정성을 높이기 위한 Harness Engineering을 중심으로 다루고 있는데, 이후에는 Claude Code나 Codex에서 불필요한 컨텍스트와 토큰 사용을 줄이는 Context/Token Optimization Harness도 추가해서 다뤄보려고 합니다. 예를 들어 작업 유형에 따라 필요한 코드와 문서만 선택적으로 읽게 하는 방식, context routing, memory/summary, sub-agent context isolation, token budget 등의 구조를 실제 예제와 함께 다룰 수 있을 것 같습니다. 또한 말씀해주신 것처럼 프로젝트를 분석해서 hooks, skills, context rules 등을 자동으로 구성해주는 harness generator 형태의 오픈소스도 좋은 주제라서 함께 추가 섹션으로 구성하는것을 검토해보겠습니다 좋은 피드백과 아이디어 주셔서 감사합니다!
안녕하세요 james 님, 먼저 수강해주셔서 감사의 말씀 드립니다. 현재 강의 노트를 통해 제공하고 있지만, 수강생 분들께 불편한 문제가 있음을 인지하고 현재 code craft 자료와 투명성 및 신뢰를 위한 이 강의의 기반인 클로드코드 논문에 대한 자료를 별도로 필요한 부분만 더 자세히 정리해서 수강생분들께 제공할 계획으로 진행중에 있어 이번주중으로 공지가 나갈 예정입니다. 감사합니다. 좋은하루 되시길 바라며 다시 한번 감사드립니다.