← 글 목록

notes

하네스 엔지니어링 고도화 -1

5 min read

하네스 엔지니어링 고도화 단계의 규칙·자동화·검증 구성 메모.

Kim mr.

프론트엔드 · 기술 블로그

관련: Untitled, Untitled, Harness Engineering - Cursor: Skill.md / Rules로 작업 가이드 붙이기

0. 먼저 정한 원칙

한 줄: 1~4 컨텍스트 → 5~6 steamed 파일럿 → 7~12 자동화·확장. Obsidian은 Wiki만, rules는 레포 SSOT.

추천 순서

  • rules 슬림 + steamed AGENT.md
  • Wiki steamed 2~3노트 + Prompts 방침 A
  • plan-gate rule
  • steamed 한 바퀴 수동 시험
  • PostToolUse lint/typecheck
  • stop build + review-bugbot
  • 7~11은 steamed 복제 또는 여유 있을 때

1. rules 슬림화

.cursor/rules 9개, 합쳐 대략 14KB. thankqcamping-app.mdc만 4KB 가까이. 매 대화마다 실려 가는 고정 짐.

할 일: 긴 rule을 포인터 5~15줄로 줄인다. SectionCard, framer-motion 금지, BottomFixLayout 같은 한 줄 규칙만 남기고, 패턴·예시·화면별 설명은 .cursor/references/ 또는 AGENT.md로 보낸다.

완료 기준: thankqcamping-app.mdc를 30초 안에 훑을 수 있을 정도.

순서: thankqcamping-app → monorepo-ui → design-system-app.

2. references / AGENT.md 층

design-system은 라우트마다 AGENT.md가 있다. thankqcamping은 rules에 다 몰려 있다.

할 일: apps/thankqcamping/AGENT.md, mypage/steamed/AGENT.md를 얇게. 폴더 역할(_screen / _form), Wiki steamed 링크, API·타입 볼 경로 정도만.

1번이랑 같이 한다. rule에는 “상세는 steamed/AGENT.md”만 가리킨다.

완료 기준: steamed 작업 시 rule만 보고 AGENT.md를 열어야 한다는 게 분명할 것.

3. LLM Prompts 이중 구조

Obsidian LLM Prompts와 레포 .cursor/rules가 겹친다.

방침은 하나만.

이 고도화 1차는 A로 간다.

완료 기준: “rules 고쳤는데 Obsidian도?” 고민이 사라질 것.

4. Wiki (03-Wiki) steamed부터

MCP만 있고 Wiki가 비어 있으면 읽을 게 없다.

할 일: 노트 2~3개만 손으로. steamed API 필드 의미, 탭/알림 결정, 확정 UI className 건드리지 않음. 한 노트 = 한 주제.

완료 기준: “steamed API 연동해줘” 할 때 Wiki 검색 결과가 0이 아닐 것.

5. plan-gate (가벼운 버전)

훅 없이 rule 한 문장부터.

할 일: _screen이나 @/lib/client-api를 건드리면, Write 전에 Wiki steamed / AGENT.md 확인 + 계획 3줄.

완료 기준: steamed 작업을 Wiki → plan → 코드 순으로 한 번 돌려 보고, 건너뛸 때 헛수고가 늘어나는지 확인.

6. output-verify (PostToolUse)

할 일: .cursor/hooks에 PostToolUse. thankqcamping 변경 시 lint + typecheck(또는 build). 실패하면 에이전트에 짧게만 알림.

완료 기준: eslint·타입 깨진 채 “완료”가 줄어들 것.

순서: 1~4번 끝난 뒤.

7. API / types (Wiki 우선)

당장: 03-Wiki/api/에 확정된 필드 매핑만 적는다.

나중: OpenAPI → @/lib/types 자동 sync가 있으면 훅에 연결. 없으면 Wiki 수동 유지.

완료 기준: steamed API 작업 시 “이 필드 뭐냐”를 Wiki 또는 types에서 답할 수 있을 것.

8. design-system gen 훅

packages/ui 스토리 바꿨는데 gen 안 돌려 docs가 어긋나는 경우 방지.

할 일: ui 패키지 변경 감지 시 pnpm --filter design-system gen.

완료 기준: docs-index.json 수동 수정이 필요 없어질 것.

9. test-generator

전역 자동화는 하지 않는다.

할 일: steamed _screen / _components 변경 시 해당 경로 테스트 한 파일 생성·실행. stop-gate 또는 체크리스트.

완료 기준: steamed PR에 최소 테스트 1개.

10. change-validator

전용 에이전트를 새로 만들지 않는다. review-bugbot skill을 stop-gate에서 돌릴지 정한다.

할 일: _screen+API 같이 바뀌면 세션 끝에 review-bugbot.

완료 기준: props·필드 엇갈림을 PR에서만 발견하는 빈도 감소.

11. performance-checker (최소)

1차는 금지 import 스캔만. framer-motion, 서버/클라 경계 위반.

할 일: PostToolUse 또는 CI에 작은 shell 스크립트.

완료 기준: no-framer-motion rule + lint로 이중 방어.

12. stop-gate

할 일: thankqcamping 변경 있으면 build 또는 review-bugbot. 처음엔 build만 해도 됨.

완료 기준: 타입 에러 있는 채 “다 했습니다” 감소.

체크리스트 (1차)

  • thankqcamping-app.mdc 30초 분량으로 슬림
  • steamed AGENT.md + rule이 그 파일을 가리킴
  • Prompts 방침 A (레포 SSOT, Wiki만 Obsidian)
  • Wiki steamed 노트 2~3개
  • plan-gate rule 한 문장
  • steamed Wiki → plan → 코드 한 바퀴
  • (이후) PostToolUse lint/typecheck
  • (이후) stop build