글

Jira에 티켓 적고 산책 갔다 왔더니 PR이 만들어져 있었다 — 개발 자동화 기록

이미지
Jira에 KAN-9 티켓 하나 적고 산책 갔다 왔더니 PR이 만들어져 있었다. 정확히는 16시 44분에 enqueue, 16시 51분에 done. 7분 5초. polling 5분 빼면 실제 처리는 2분 안쪽이다. Jira 티켓을 적으면 M4 Mac Studio에 상주하는 워커가 그걸 받아서 코드 변경, 테스트 작성, GitHub PR 생성, CI 통과 확인까지 자동으로 한다. 사람이 개입하는 건 두 군데뿐이다. 티켓 작성과 PR 리뷰·머지. 그 사이는 모두 자동이다. 비슷한 도구가 이미 있다. Cursor는 IDE 통합형으로 시작했지만 2025년부터 Background Tasks로 비동기 영역에 들어왔다. Devin은 풀스택 자율 SaaS다. 둘 다 잘 만든 도구다. 그래도 jira-agent를 직접 만들 이유가 있었다. 첫째, Jira-driven 이라 IDE도 Cursor 화면도 안 켜도 된다. Jira 티켓에 스펙만 적으면 5분 안에 워커가 가져간다. 둘째, 로컬 LLM 우선 이다. 기본 백엔드가 Qwen3.6 35B (Ollama), 무료. 유료 백엔드(Claude, Kimi)는 옵션이다. Cursor Background Tasks는 cloud 인프라 + Cursor 구독료가 기본이고, Devin은 SaaS 비용이 든다. 흐름은 8 action 시퀀스 Jason Jira Cloud M4 Mac Studio GitHub ───── ────────── ───────────── ────── 티켓 작성 ─→ description labels=ai-impl ─→ worker (launchd 상주) └─ polling 5분 └─ 8 act...
댓글 쓰기
자세한 내용 보기

프롬프트 엔지니어링 / 에이전트 / 하네스 — 무엇이 다른가 (LLM 워크플로우 용어 지도)

이미지
프롬프트 엔지니어링 / 에이전트 / 하네스 — 무엇이 다른가 (LLM 워크플로우 용어 지도) Claude한테 일 시키는 방법은 세 가지로 나뉘는 것 같다. 한 마디 잘 묻는 프롬프트 엔지니어링 (Prompt Engineering, 줄여서 PE). 도구를 쥐어준 에이전트 (Agent). 그 위에 운영 틀을 얹은 하네스 (Harness). 셋 다 “AI 활용”으로 묶이지만 무게가 다르다. 어디에 어떤 도구가 맞는지 헷갈렸던 정리를 여기에 적어둔다. 요약 : PE는 한 번의 입력 최적화, 에이전트는 도구를 들고 알아서 도는 AI, 하네스는 그 둘을 어떻게 운영할지 정하는 메타 틀이다. 작은 → 큰 순서로 쌓인다. 5/3 글 에서 다룬 하네스의 내부 구조 는 이 위계 지도의 마지막 칸에 해당한다. 이 글은 Claude Code를 매일 쓰면서 PE·에이전트·하네스라는 단어가 다 비슷해 보였던 사람을 위해 썼다. 입문자가 아니라 한 번씩 다 써본 사람의 정리에 가깝다. 이런 적 있다면 이 글이 도움이 된다 ChatGPT에 비슷한 작업을 시킬 때마다 거의 같은 프롬프트를 매번 다시 입력한 적이 있다. Claude Code가 한 작업에서 5분 만에 토큰 한도를 다 쓴 걸 본 적이 있다. 같은 종류의 실수가 작업마다 또 반복되는 걸 보고 어떻게 멈추지 가 답답했던 적이 있다. 세 가지 모두 같은 원인이다. 셋이 같은 단계가 아니다. 한 번의 입력 최적화로 풀 일, 도구를 쥐어줘야 풀 일, 운영 틀로만 풀 일이 다 섞여 있다. 위계를 잡으면 어디에 시간을 쓸지 가 분명해진다. 한 줄 정의로 시작한다 단계 한 줄 정의 비유 PE (프롬프트 엔지니어링) 한 번의 질문으로 원하는 답을 받아내는 기법 신입에게 일을 한 번 시키는 법 에이전트 도구를 들고 알아서 돌아가는 AI 권한을 받은 1년 차 하네스 에이전트·프롬프트·문맥을 굴리는 운영 틀 회사의 매뉴얼과 평가 체계 자체 작은 단위가 큰 단위에 ...
댓글 쓰기
자세한 내용 보기

패밀리카를 검색어로 하여 6개 수집 도구를 돌려봤다 — Google이 막은 자리와 다음 학습 방향

이미지
패밀리카를 검색어로 하여 6개 수집 도구를 돌려봤다 — Google이 막은 자리와 다음 학습 방향 trend-scout 를 1년 운영했다. 다음 단계를 결정해야 할 시점이 왔다. 내 수집 도구를 한 단계 더 깊이 키울지, 아니면 더 넓게 가져갈지. 결정하기 전에 지금 가진 도구가 어디까지 풀어내고 어디서 막히는지 한번 측정해 볼 필요가 있었다. ​ 검색어를 “3인가족 패밀리카 추천”으로 잡았다. 여기에 사이트 6곳을 도구 6개로 돌려보는 매트릭스를 만들었다. 결과는 명확했다. Google을 통한 자료 수집은 6개 도구가 모두 실패했다. 반대로 Naver는 우회 도구 없이도 본문에 제품명이 9건 그대로 노출됐다. 이 결과가 다음 학습 방향을 정해줬다 — 깊이가 아니라 넓이. 이 글은 그 측정 과정과 거기서 본 것들을 정리한 글이다. 1. 지금의 trend-scout 구성과 측정 준비 trend-scout는 X·Threads·Google Trends 세 곳을 데이터 출처로 삼는다. 한 달에 비용은 0원, 유지 시간은 2~4시간 정도로 굴리는 사이드 수집기다. ​ 이전 글 엔드포인트는 죽는다 에서 정리한 운영 규율 세 가지가 있었다. 엔드포인트가 평균 2~3개월이면 죽는다는 점. 출처를 분산해야 한다는 점. 죽음 신호를 자동으로 감지해야 한다는 점. 1년 동안 굴리면서 얻은 학습이었다. ​ 다음에 어디로 학습을 끌고 갈지 후보가 둘 있었다. (깊이) 한 사이트에 우회 계층을 더 쌓는다 — TLS 위장, 브라우저 자동화, CAPTCHA 풀이 도구. (넓이) 출처를 더 넓힌다 — 한국 검색, 커뮤니티, 자동차 전문 사이트. 깊이 쪽으로 가려면 지금 도구가 어디서 막히는지부터 알아야 했다. 그래서 한국어 검색어를 정해 두고, 표준 사이트 6곳에 던져 도구 6개로 풀어 보는 시도를 했다. 측정 준비 검색어 : “3인가족 패밀리카 추천” 사이트 6곳 : Google 웹 검색, Google 이미지 ...
댓글 쓰기
자세한 내용 보기

Benchmark가 측정한 건 모델이 아니라 채점기였다 — Honcho/Hindsight 3 라운드 측정 후기

이미지
내 환경(Hermes)의 메모리 provider 두 개(Honcho·Hindsight)를 3 라운드에 걸쳐 비교했다. 1차 10/10 만점, 2차 7점대, 3차 4점대로 점수가 압축됐다. 처음엔 “task가 어려워져서”라고 봤다. 직접 답변을 보니 다른 이유였다. 요약 : 점수 10 → 7 → 4 압축의 진짜 원인은 task 난이도가 아니라 regex scorer false positive. approval_boundary 3.5점 답변이 manual review 5.0이었고, 5.0점 답변엔 risky implications가 남아 있었다. wrapper guardrail 패치까지 진행한 후기. 이런 적 있다면 글이 도움이 된다 도구·모델 비교 글에서 점수가 비슷하게 나와 어느 게 더 나은지 판단 못 한 적이 있다. LLM 답변 채점할 때 regex나 키워드 매칭이 진짜 평가를 한다고 믿어본 적이 있다. benchmark가 모델 약점이 아니라 측정 기구의 약점을 드러내는 건 처음 봤다. 측정 setup — Hermes 안에서 Hermes는 내 1인 운영 자동화 환경이다. 컴포넌트는 다음과 같다. ALIVE : canonical source-of-truth. 프로젝트 상태·결정·산출물 기록 Hermes core memory : compact durable preferences Honcho lab profile : Plastic Labs의 오픈소스 메모리 라이브러리. user-agent modeling, boundary discipline 실험용 Hindsight lab profile : semantic recall, entity graph 실험용 (내 환경 자체 구성) default Discord gateway : 사용자 I/O 메인 채널 Honcho는 stateful agent용 외부 오픈소스다. 내 환경에서는 lab profile로만 띄워두고 default gateway는 별도 inference로 운영한다. 둘 다 ...
댓글 쓰기
자세한 내용 보기

하네스 엔지니어링 측정 2편 — Claude에 AGENTS.md 명시 인용했더니 fail-fast가 강해졌다

1편(어제)에서 N=1로 측정해서 결론을 냈다. “Codex가 fail-fast 약하다”가 아니라 “AGENTS.md 비우면 Codex도 Claude도 똑같이 약하다”였다. 지적이 들어왔다. N=1은 우연일 수 있다. Claude에 AGENTS.md 명시 인용을 직접 해본 적은 없었다. 12회 측정해서 다시 확인했다. 결론은 더 단단해졌다. 그리고 1편이 놓친 변수 하나가 새로 보였다. 요약 : Codex × Claude × 하네스 0/강제 4 condition을 각 3회씩 12회 측정. 모델 효과는 거의 0(가로축 1.0 vs 1.0, 2.83 vs 2.5), 하네스 효과는 큼(세로축 1.0 → 2.5+). Claude도 AGENTS.md를 prompt에 명시 인용하면 fail-fast 1.0 → 2.5로 올라간다. 단 1편의 Claude 채점 “중”은 prompt position 효과(메인 세션 system prompt 자동 로드)였을 가능성이 새로 보였다. 1편이 명시한 5가지 한계 중 통제한 3가지 측정 1편 본문 끝에 한계 5가지를 적었다. 그 중 2편에서 통제 가능한 것은 3가지였다. Sampling 우연 미통제 (N=1) → 12회 측정으로 분산 확인 Prompt position 미분리 → C3 격리 환경 추가로 부분 분리 Claude에 AGENTS.md 명시 인용 미측정 → C4 condition으로 직접 측정 나머지 2가지(컨벤션 vs 코드 품질, 일반화)는 이번에도 미해소다. 측정 setup, 4 condition × 3회 = 12회 같은 명세 verify_published_post() 를 4 condition으로 각 3회씩 측정했다. Condition 모델 하네스 C1 Codex 없음 (AGENTS.md 비움) C2 Codex AGENTS.md 자동 로드 C3 Claude spec만, 격리 Task agen...
댓글 쓰기
자세한 내용 보기