개발 운영 하네스 프레임워크
2026-04-01 — present
개발 운영과 이력서/JD 큐레이션을 재현 가능하게 만든 Git 기반 개인 하네스 — 로컬 BGE-M3 RAG, MCP 검색, Git 훅 품질 게이트, JD-custom PDF 생성, 직행/Zighang 외부 피드백 루프와 안전한 T1/T2/T3 반영 체계를 통합
시스템 아키텍처
문제 해결 과정
개발 런타임별 컨텍스트와 규칙이 문서·설정·로컬 홈에 흩어져 실행 환경마다 드리프트 발생
하네스 소스를 canonical source로 두고 런타임 서피스를 자동 생성, XML runtime contract와 cross-harness diff 검증 추가
kh/gp/gd 3개 하네스의 생성 문서 및 런타임 컨트랙트 정합성 확보
마크다운 지식 베이스가 커져 에이전트가 관련 컨텍스트를 매번 수동 탐색
sqlite-vec + FTS5 하이브리드 RAG, BGE-M3 로컬 임베딩, RRF fusion, MCP 검색 서버, 마크다운 변경 후 자동 재색인 구현
548 파일·3,347 청크·20.7 MB 인덱스, warm 쿼리 0.7초, 골드 쿼리 5건 top-2/3 적중
RAG가 opt-in 참고 도구라 실제 조사·검토 프롬프트에서 누락
UserPromptSubmit 기본 트리거로 전환하고 프롬프트 12자 이상이면 search_harness가 자동 호출되도록 gp/gd까지 포팅
3개 하네스에서 15/15 default-on 테스트 통과, 실 프롬프트 smoke test 적중
이력서·포트폴리오 JSON과 JD별 외부 피드백이 서로 분리되어, 공고별 개선이 raw feedback에 의존
resume/portfolio JSON chunker, JD-custom PDF 생성기, 직행/Zighang recruitment-roast 수집기, T1/T2/T3 triage 템플릿을 연결
쥬비스 NestJS JD 통과권, 넥슨 정산 JD 35% low-fit, 한화생명 AI Backend 82% 보완-통과권 피드백을 각각 raw feedback→T1/T2/T3 triage→검증 루프로 분류
이력서·JD 커스터마이징 근거가 세션 로그와 작업 기록에 흩어져 최신 성과 선별과 정량화가 매번 수작업으로 반복됨
private work-data 아카이브를 schema v1.2로 정리하고 outcome_metrics 필드를 도입, Jira·세션 evidence를 resumeProject 단위로 분류해 resume/portfolio/RAG 큐레이션 경로에 연결
279개 작업 항목 증분 수집, 메트릭 보유율 44%→50% 개선, work-data→이력서 후보 선별→검증 루프 정착
프로젝트 설명
AI 지원 개발을 단발성 도구 사용이 아니라 재현 가능한 운영 체계로 만들기 위해 설계한 개인 하네스다. 런타임별 설정은 소스에서 생성해 드리프트를 줄이고, 마크다운·이력서·포트폴리오 JSON은 로컬 임베딩 RAG로 색인해 세션 시작·프롬프트 제출·편집·커밋 시점에 근거 검색을 자동 연결한다. 문서만으로는 지켜지지 않는 규칙은 Git 훅과 테스트로 강제하고, JD-custom PDF 생성과 직행/Zighang 외부 피드백 루프를 통해 채용 공고별 이력서 개선도 raw feedback→T1/T2/T3 triage→검증→커밋 흐름으로 운영한다.
주요 내용
- 런타임 서피스 자동 생성 + XML runtime contract로 3개 하네스 정합성 확보
- 로컬 BGE-M3 RAG로 548 파일·3,347 청크 색인, warm 쿼리 0.7초 달성
- RAG default-on 전환으로 프롬프트 12자 이상 search_harness 자동 호출, 3개 하네스 15/15 테스트 통과
- resume/portfolio JSON을 RAG 코퍼스로 통합, 109 청크 색인 + 32개 테스트 통과
- 브라우저·REPL 런타임 신뢰 경계와 fallback 순서 문서화, 3개 하네스 설정 반영
- work-data schema v1.2와 outcome_metrics 기반 증거 큐레이션으로 279개 작업 항목 증분 수집·메트릭 보유율 44%→50% 개선
- JD-custom PDF + 직행/Zighang 피드백 루프 구축, 쥬비스 92%→88% 통과권·넥슨 35% low-fit 분류로 과최적화 방지
- 직행/Zighang recruitment-roast 헬퍼를 main-scope 결과 저장·Puppeteer 실제 click·upload-form guard로 보강해 sidebar 과거 결과 오탐 방지
성과 지표
| 성과 지표 | 이전 | 이후 |
|---|---|---|
| RAG MVP 인덱스 | manual context search | 548 files / 3,347 chunks / 20.7 MB (0.7s warm query) |
| RAG default-on 검증 | opt-in trigger | 15/15 tests across 3 harnesses (prompt >=12 chars auto-search) |
| Resume RAG 코퍼스 | 0 indexed chunks | 109 chunks (32 tests passed) |
| Work-data 증거 아카이브 | manual evidence curation / 44% metric coverage | 279 incremental work items / schema v1.2 (50% metric coverage) |
| JD 피드백 루프 | manual JD feedback capture | JD PDF + Zighang recruitment-roast + T1/T2/T3 triage + form-start guard (Juvis pass range / Nexon low-fit / Hanwha 82% improve-to-pass) |
기술 선택 근거
- ▶ 클라우드 벡터 DB 대신 로컬 BGE-M3 + sqlite-vec 선택: 마크다운 변경 직후 자동 재색인과 비용 통제를 우선
- ▶ 문서 규칙 대신 hook-first 강제 선택: 에이전트가 필요 시점에 문서를 읽지 않는 문제를 런타임 차단으로 보완
- ▶ 런타임별 수동 설정 대신 runtime surface compiler 선택: 생성물 드리프트를 줄이고 3개 하네스 정합성 검증을 자동화
- ▶ 검색 opt-in 대신 default-on 선택: 조사·리뷰·편집 같은 실제 프롬프트에서 근거 검색 누락을 줄이기 위해 UserPromptSubmit에 연결
깨달은 점
- • AI 지원 개발 생산성은 프롬프트 품질만으로 유지되지 않고, 런타임 컨텍스트·규칙 강제·증거 검색·비용 관측성을 같은 운영 경로로 묶어야 재현 가능하다는 점을 체득
- • 문서 규칙은 필요 시점에 읽히지 않으면 정책이 아니라 참고 자료에 머물기 때문에, 중요한 규칙은 훅·테스트·컴파일러 출력으로 강제해야 한다는 기준 정립
- • RAG는 검색 품질뿐 아니라 자동 호출 위치, 색인 최신성, 사용 로그, fallback 경로까지 포함해야 실제 에이전트 워크플로우에 편입된다는 점 확인
- • 런타임별 기능과 신뢰 경계가 다른 도구는 canonical source와 생성기 기반으로 관리해야 장기 운영에서 드리프트를 줄일 수 있다는 점 학습
- • work-data를 단순 기록 저장소가 아니라 이력서·JD·포트폴리오 큐레이션의 증거 계층으로 분리해 두면, 공개 copy를 안전하게 재가공하면서도 내부 세부정보를 노출하지 않을 수 있다는 점 확인