174만명의 커뮤니티!! 함께 토론해봐요.
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
최근에 claude fable 5 모델 출시로 인해서 기존에 사람이 지시하는 방식이 아니라 loop 엔지니어링 방식으로 구현을 해야한다는 소식을 듣게 되었습니다. 혹시 loop 엔지니어링에 관해서도 강의 추가 계획이 있으실까요??
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
claude.md에 구현전에 고려해야할 사항을 적어두었습니다. ex) 1. 테스트 환경 1-1. DB 접속 방법 1-2. 로그 확인 방법 라이브 서비스 환경 2-1. 로컬에서 DB 접속 불가 이런식으로 각 환경에 맞게 디버깅하는 방식을 적어두었는데 처음에는 claude.md의 내용을 기억하고 테스트 환경의 DB에 접속하는 등 잘 이행을 하다가 context가 길어지면 라이브 서비스의 DB를 로컬에서 접근 시도하려는등 memory에 문제가 있는것 같습니다. 이런 경우는 어떻게 해결해야할까요?
해결됨
나만의 Claude Code 하네스 (SPEC·TDD·CI로 짓는 AI 개발 워크플로우)
수업노트로 요청한 tdd-red 스킬의 초안은 다음과 같습니다. 아래 내용으로 진행하면 import error, 파일 없음 에러도 정상적인 red 로 인식하고 다음 단계로 진행됩니다. --- name: tdd-red description: 승인된 테스트 시나리오를 실패하는 테스트 코드로 작성한다. TDD Red 단계 시작 시 사용한다. argument-hint: <feature> <이슈 번호> allowed-tools: Read Write Bash --- `$ARGUMENTS`에서 feature 이름과 이슈 번호를 파싱해 해당 이슈의 승인된 시나리오를 실패하는 테스트 코드로 작성한다. ## 시작 전 ### 인자 파싱 `$ARGUMENTS`를 공백으로 분리해 첫 번째 토큰을 `{feature}`, 두 번째 토큰을 `{issue}` 로 사용한다. | 입력 예시 | feature | issue | | ------------------ | -------- | ----- | | `/tdd-red tag 2` | `tag` | `2` | | `/tdd-red search 1`| `search` | `1` | 누락된 값이 있으면 실행 전에 사용자에게 질문한다. - `{feature}`가 없으면: "어떤 기능의 이슈인가요? (예: tag, search, ...)" - `{issue}`가 없으면: "이슈 번호를 알려주세요." 두 값이 확정된 뒤 `docs/features/{feature}/issue-{issue}.md` 를 읽어 시그니처와 테스트 시나리오 목록을 파악한다. - 시그니처 섹션: 테스트 대상 파일 경로 및 함수·컴포넌트명 확인 - 테스트 시나리오 섹션: 작성할 시나리오 목록 전체 수집 파일이 없으면 즉시 멈추고 사용자에게 알린다 (`/test-scenarios {feature} {issue}` 를 먼저 실행해야 한다는 안내 포함). --- ## 단계 1: 테스트 파일 준비 시그니처에서 테스트 대상 파일 경로를 추출하고 테스트 파일 경로를 결정한다. ### 파일 위치 규칙 | 구현 파일 | 테스트 파일 | | ---------------------------------- | ---------------------------------------- | | `src/api/tags.ts` | `src/api/tags.test.ts` | | `src/components/TagInput.tsx` | `src/components/TagInput.test.tsx` | | `src/context/NotesContext.tsx` | `src/context/NotesContext.test.tsx` | - 테스트 파일이 이미 존재하면 기존 내용을 읽어 중복 `describe` 블록을 피한다. - 테스트 파일이 없으면 새로 생성한다. ### 파일 헤더 (신규 생성 시) ```ts import { describe, it, expect, vi, beforeEach } from 'vitest'; // 컴포넌트 파일인 경우에만 추가: // import { render, screen } from '@testing-library/react'; // import userEvent from '@testing-library/user-event'; ``` --- ## 단계 2: 시나리오를 테스트 코드로 작성 시나리오를 하나씩 `it()` 블록으로 변환한다. 한 번에 모두 작성하지 않고 **시나리오 하나 작성 → 실행 → 실패 확인 → 다음 시나리오** 순서를 반복한다. ### 테스트 이름 형식 ``` should [기대 동작] when [조건] ``` ### describe 블록 구조 함수·컴포넌트 단위로 묶는다. ```ts describe('함수명 또는 컴포넌트명', () => { it('should [기대 동작] when [조건]', () => { // Red 단계: 구현이 없으므로 실패하는 코드만 작성 }); }); ``` ### Red 테스트 작성 원칙 - 구현이 존재하지 않으므로 import가 실패하거나 호출이 오류를 던져야 한다. - 억지로 통과시키려 하지 않는다. 실패 자체가 목표다. - `expect`는 실제 기대 동작을 명확하게 표현한다. `expect(true).toBe(false)` 같은 더미 assertion은 사용하지 않는다. **API 함수 예시** ```ts import { addTag } from './tags'; describe('addTag', () => { it('should return updated note when valid tag is added', async () => { const result = await addTag('note-1', 'work'); expect(result.tags).toContain('work'); }); it('should throw when tag is empty string', async () => { await expect(addTag('note-1', '')).rejects.toThrow(); }); }); ``` **컴포넌트 예시** ```ts import { render, screen } from '@testing-library/react'; import { TagInput } from './TagInput'; describe('TagInput', () => { it('should render input when component is mounted', () => { render(<TagInput tags={[]} onAdd={vi.fn()} onRemove={vi.fn()} />); expect(screen.getByRole('textbox')).toBeInTheDocument(); }); }); ``` --- ## 단계 3: 시나리오별 실행 루프 각 시나리오를 작성한 직후 아래 명령으로 해당 테스트 파일만 실행한다. ```bash npx vitest run <테스트-파일-경로> --reporter=verbose ``` - **실패 확인**: `FAIL` 또는 import 오류가 나오면 정상. 다음 시나리오로 이동한다. - **통과**: 테스트가 의도치 않게 통과하면 즉시 멈추고 사용자에게 알린다. 구현 파일이 이미 존재하는지 확인한다. --- ## 단계 4: 전체 확인 모든 시나리오 작성이 끝나면 전체 테스트를 실행한다. ```bash npm test ``` - 작성한 테스트 파일의 모든 케이스가 실패하는지 확인한다. - 기존에 통과하던 테스트가 새로 실패하면 즉시 사용자에게 보고한다. --- ## 제약 - 테스트 파일(`*.test.ts`, `*.test.tsx`)만 생성하거나 수정한다. - `src/` 안의 구현 코드(`*.ts`, `*.tsx`, `*.css` 등 테스트 파일 제외)는 절대 수정하지 않는다. - 테스트가 통과하도록 mock이나 stub으로 우회하지 않는다. --- ## 산출물 - 작성된 테스트 파일 목록 및 경로 - 시나리오별 실패 메시지 요약 - `npm test` 결과: 실패한 테스트 수 / 전체 테스트 수 관련해서, import 에러 및 파일 에러는 없어야한다.(stub 이 있어야 함. Collect 는 모두 성공하고 Test 단계에서 실패해야한다.) 는 점을 고려해서 아래와 같이 스킬을 수정했는데, 피드백 부탁드립니다. --- name: tdd-red description: 승인된 테스트 시나리오를 실패하는 테스트 코드로 작성한다. TDD Red 단계 시작 시 사용한다. argument-hint: <feature> <이슈 번호> allowed-tools: Read Write Bash --- `$ARGUMENTS`에서 feature 이름과 이슈 번호를 파싱해 해당 이슈의 승인된 시나리오를 실패하는 테스트 코드로 작성한다. ## 시작 전 ### 인자 파싱 `$ARGUMENTS`를 공백으로 분리해 첫 번째 토큰을 `{feature}`, 두 번째 토큰을 `{issue}` 로 사용한다. | 입력 예시 | feature | issue | | ------------------- | -------- | ----- | | `/tdd-red tag 2` | `tag` | `2` | | `/tdd-red search 1` | `search` | `1` | 누락된 값이 있으면 실행 전에 사용자에게 질문한다. - `{feature}`가 없으면: "어떤 기능의 이슈인가요? (예: tag, search, ...)" - `{issue}`가 없으면: "이슈 번호를 알려주세요." 두 값이 확정된 뒤 `docs/features/{feature}/issue-{issue}.md` 를 읽어 시그니처와 테스트 시나리오 목록을 파악한다. - 시그니처 섹션: 테스트 대상 파일 경로 및 함수·컴포넌트명 확인 - 테스트 시나리오 섹션: 작성할 시나리오 목록 전체 수집 파일이 없으면 즉시 멈추고 사용자에게 알린다 (`/test-scenarios {feature} {issue}` 를 먼저 실행해야 한다는 안내 포함). --- ## 단계 0: 스텁 생성 테스트 파일을 작성하기 전에, 이슈의 시그니처를 읽어 **아직 존재하지 않는 구현 파일**에 대해서만 최소 스텁을 생성한다. ### 목적 Import Error 때문에 테스트가 실행조차 되지 않으면, 테스트가 무엇을 거부하는지 알 수 없다. 스텁은 빌드를 통과시켜 테스트가 **Assertion Failure로 실패**하도록 만드는 것이 전부다. ### 스텁 작성 규칙 - **기존 파일이 있으면 건드리지 않는다.** 신규 파일만 생성한다. - 시그니처의 파라미터·반환 타입을 그대로 선언한다. 구현 로직은 쓰지 않는다. - 반환값은 타입을 만족하는 최솟값으로 고정한다. | 반환 타입 | 스텁 반환값 | | ------------------ | ------------- | | `string[]` | `[]` | | `string` | `''` | | `boolean` | `false` | | `Promise<T>` | `Promise.resolve(/* 최솟값 */)` | | React 컴포넌트 | `return <div />;` | | `void` | _(반환 없음)_ | ### 스텁 예시 **훅 (`src/hooks/useTagInput.ts`)** ```ts import { useState } from 'react'; export function useTagInput(_initialTags: string[]) { const [tags] = useState<string[]>([]); const [inputValue, setInputValue] = useState(''); return { tags, inputValue, setInputValue, addTag: (_value: string) => {}, removeTag: (_tag: string) => {}, handleKeyDown: (_e: React.KeyboardEvent<HTMLInputElement>) => {}, }; } ``` **컴포넌트 (`src/components/TagInput.tsx`)** ```tsx import { TagInputProps } from '../types'; // 필요 시 인라인 정의 export function TagInput(_props: TagInputProps) { return <div />; } ``` **API 함수 (`src/api/tags.ts`)** ```ts import { Note } from '../types/note'; export async function addTag(_noteId: string, _tag: string): Promise<Note> { return Promise.resolve({} as Note); } ``` --- ## 단계 1: 테스트 파일 준비 시그니처에서 테스트 파일 경로를 결정한다. | 구현 파일 | 테스트 파일 | | -------------------------------- | ----------------------------------- | | `src/api/tags.ts` | `src/api/tags.test.ts` | | `src/components/TagInput.tsx` | `src/components/TagInput.test.tsx` | | `src/context/NotesContext.tsx` | `src/context/NotesContext.test.tsx` | - 테스트 파일이 이미 존재하면 기존 내용을 읽어 중복 `describe` 블록을 피한다. - 테스트 파일이 없으면 새로 생성한다. ### 파일 헤더 (신규 생성 시) ```ts import { describe, it, expect, vi, beforeEach } from 'vitest'; // 컴포넌트 파일인 경우에만 추가: // import { render, screen } from '@testing-library/react'; // import userEvent from '@testing-library/user-event'; ``` --- ## 단계 2: 시나리오를 테스트 코드로 작성 이슈의 시나리오 전체를 한 번에 `it()` 블록으로 변환한다. ### 테스트 이름 형식 ``` should [기대 동작] when [조건] ``` ### describe 블록 구조 함수·컴포넌트 단위로 묶는다. ```ts describe('함수명 또는 컴포넌트명', () => { it('should [기대 동작] when [조건]', () => { // 스텁이 있으므로 import는 통과하고, assertion이 실패한다 }); }); ``` ### Red 테스트 작성 원칙 - `expect`는 실제 기대 동작을 명확하게 표현한다. `expect(true).toBe(false)` 같은 더미 assertion은 사용하지 않는다. - 스텁의 반환값(빈 배열, `<div />` 등)을 기준으로 assertion이 자연스럽게 실패하도록 작성한다. - 테스트가 통과하도록 mock이나 stub으로 우회하지 않는다. **API 함수 예시** ```ts import { addTag } from './tags'; describe('addTag', () => { it('should return updated note when valid tag is added', async () => { const result = await addTag('note-1', 'work'); expect(result.tags).toContain('work'); // 스텁은 {} 반환 → tags 없음 → Assertion Failure }); it('should throw when tag is empty string', async () => { await expect(addTag('note-1', '')).rejects.toThrow(); // 스텁은 throw 안 함 → Assertion Failure }); }); ``` **컴포넌트 예시** ```ts import { render, screen } from '@testing-library/react'; import { TagInput } from './TagInput'; describe('TagInput', () => { it('should render input when component is mounted', () => { render(<TagInput tags={[]} onAdd={vi.fn()} onRemove={vi.fn()} />); expect(screen.getByRole('textbox')).toBeInTheDocument(); // 스텁은 <div /> → textbox 없음 → Assertion Failure }); }); ``` --- ## 단계 3: 실행 및 Red 품질 확인 모든 테스트 파일을 작성한 뒤 파일별로 실행한다. ```bash npx vitest run <테스트-파일-경로> --reporter=verbose ``` ### Red 품질 기준 | 실패 유형 | 판정 | 조치 | | ------------------ | ------------- | ---------------------------------------- | | Assertion Failure | ✅ 올바른 Red | 다음으로 진행 | | Runtime Error | ✅ 허용 | 다음으로 진행 | | Import Error | ❌ 스텁 누락 | 단계 0으로 돌아가 해당 파일 스텁 보완 | | Syntax Error | ❌ 테스트 오류 | 테스트 코드 수정 | - **Import Error가 발생하면 올바른 Red로 인정하지 않는다.** 스텁을 보완한 뒤 다시 실행한다. - 테스트가 의도치 않게 통과하면 즉시 멈추고 사용자에게 알린다. --- ## 단계 4: 전체 확인 모든 파일의 Red 품질이 확인된 뒤 전체 테스트를 실행한다. ```bash npm test ``` - 이슈에서 작성한 테스트 파일의 케이스가 모두 Assertion Failure로 실패하는지 확인한다. - 기존에 통과하던 테스트가 새로 실패하면 즉시 사용자에게 보고한다. --- ## 제약 - 테스트 파일(`*.test.ts`, `*.test.tsx`)은 자유롭게 생성·수정한다. - 단계 0의 스텁은 **존재하지 않는 파일**에 한해서만 신규 생성한다. - **기존 구현 파일은 수정하지 않는다.** --- ## 산출물 - 생성된 스텁 파일 목록 및 최솟값 반환 내용 - 작성된 테스트 파일 목록 및 경로 - 파일별 실패 유형 요약 (Assertion Failure / Runtime Error) - `npm test` 결과: 실패한 테스트 수 / 전체 테스트 수
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
안녕하세요. 강의 주제와 벗어난 질문이지만 궁금해서 문의 드립니다. MD 파일 내용을 보면 특별히 파이썬으로 구현하라는 내용이 없는 것 같은데... 어떻게 파이썬 언어을 선택해서 구현 과정이 이뤄지는지 궁금하네요. 다음에는 더 좋은 질문 드리도록 하겠습니다.
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
섹션5 수업노트와 실습자료 ( claude.md 파일) 첨부가 어디되어있을까요?
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
안녕하세요 실습 과정에서 claude.md 에 대해서 질문이 있습니다 저는 프로젝트 단위에서 각 패치 서버에 대한 정보를 명시해두었고 어떠한 명령을 해도 해당 claude.md 파일을 참고하여 해당 서버의 환경에 맞는 코드 수정을 원했습니다. 하지만 claude.md 를 참고하라고 명시해야했고 명시하지않을 경우 전혀 claude.md 를 참고하지 않아 특정 서버에 맞게 변경을 하라고해도 하지않는 결과가 나타났습니다. 이런 경우에는 permission이나 deny에서 설정을 하는것이 맞을까요?
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
섹션1에서 보여줬던 내용을 다시 보고 싶은데 매번 다시 강의자료로 보기에는 번거롭네요.
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
해당 영상 내용이 41번 강의랑 동일한 내용으로 보이네요.
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
섹션 1 강의자료 없나요? 글자가 너무 작아요 확대 축소 이동 하시면 정신이 좀 없어서요 따로 화면 뛰워놓고 보고 싶어요... ..
미해결
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
안녕하세요. 강의 잘 보고 있습니다. 감사합니다. 강의 소개글과 강의에서 참고한 논문을 언급하셨는데, 혹시 강의에서 기준으로 삼은 논문 목록을 알 수 있을까요? 강의를 이해하는데 도움이 될 것 같습니다. 감사합니다.
해결됨
나만의 Claude Code 하네스 (SPEC·TDD·CI로 짓는 AI 개발 워크플로우)
여기 자료 다운로드 했는데 전체 워크 플로우가 안보입니다 ㅠㅠ 저만 그런가요
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
강의자료 다운받으면 비어있습니다. 오류같은데 확인 부탁드립니다.
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
26강 10분 40초쯤을 보다가 약간 개념이 모호해졌는데, code craft는 하네스 엔지니어링을 하기위한 클로드 코드 기준으로 /plan모드에서 요구사항을 정의하는 방법론이라고 생각하면될까요 ??
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
안녕하세요 강의를 보고 hermes agent에 k-skill ( https://github.com/NomaDamas/k-skill )을 붙여서 사용하고있는데 예를 들면 부동산 실거래가를 조회해줘라고하면 skill 을 안쓰고 제멋대로 합니다 어떤 부분을 수정해야할까요 ?? 프롬프트로 강제성을 좀더 주는것이 맞는걸까요?
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
화면에 띄우신 프로그램이 뭔지 궁금하네요
해결됨
나만의 Claude Code 하네스 (SPEC·TDD·CI로 짓는 AI 개발 워크플로우)
github에 가면 src 원본만 있고, 실습내용대로 진행하려니 사용된 skill.md 및 다른.md 를 타이핑하기에 내용이 많습니다. 혹시 사용하신 md 파일 공유하여 주실수 있나요?
해결됨
나만의 Claude Code 하네스 (SPEC·TDD·CI로 짓는 AI 개발 워크플로우)
codex로 적용해도 큰 문제 없을까요?
해결됨
나만의 Claude Code 하네스 (SPEC·TDD·CI로 짓는 AI 개발 워크플로우)
강의 자료는 어디서 다운 받나요?
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
글로만 설명주시는게 아니라 실습이 보고싶은데요 혹시 그게 추후 올려주시는 섹션5에 올려주실까요?
해결됨
Claude Code Harness & Graph Engineering 클로드코드 심화 CLI 하네스 엔지니어링 실무
안녕하세요 강의를 보다가 Skills와 tool use에 대한 부분에 질문이 있습니다. 보통 반복되는 작업의 경우 skills로 만들어서 사용중인데 그 작업이 mcp를 사용해야만 하는 경우가 있습니다. 그래서 skill안에서 mcp를 사용하고 있는데 이렇게 사용하는것도 skills를 올바르게 사용하는 것이라고 볼 수 있나요?
