라벨이 Claude Code인 게시물 표시

AI 코딩 설정도 코드처럼 썩는다 — 가짜 보안 훅과 죽은 에이전트 11개

이미지
하네스(AI 도구를 내 방식대로 굴리는 설정·규칙·자동화 묶음)를 만드는 법은 전에 썼다. 그런데 만든 다음, 그 AI 코딩 설정이 계속 작동하는지는 아무도 점검하지 않는다. 며칠 전 처음으로 내 설정을 전수 점검했다. 몇 달 동안 잘 굴러간다고 믿었던 설정이다. 다 열어보고 든 생각은 하나였다. 절반이 조용히 죽어 있거나, 가짜로 작동하고 있었다. 가장 충격적인 건 보안 훅이었다. API 키가 새는 걸 막으려고 달아둔 훅이, 필드명 오타 하나 때문에 설치된 날부터 한 번도 실행된 적이 없었다. 개발 에이전트 11개는 주석 한 줄 때문에 세션에 등록조차 안 되고 있었다. 설정도 코드처럼 썩는다. 만들고 방치하면 죽은 참조와 작동 안 하는 안전장치가 쌓인다. 영어로는 이걸 설정 부패(config rot)라고 부른다. 누가 읽으면 좋은가 Claude Code·Cursor에 CLAUDE.md·에이전트·훅을 세팅해 본 사람 설정을 한참 전에 만들어두고 그 뒤로 열어본 적 없는 사람 “에러가 안 나니까 잘 돌고 있겠지”라고 믿고 있는 사람 한 줄로 요약하면, 설정 파일에 등록돼 있다는 것과 그 기능이 실제로 작동한다는 것은 전혀 다른 문제였다. 주석 한 줄에 사라진 에이전트 11개 점검에서 가장 먼저 걸린 건 개발 에이전트들이었다. architect, planner, code-reviewer… 정의 파일은 멀쩡히 다 있었다. 그런데 세션에서 단 하나도 호출되지 않고 있었다. 원인은 파일 맨 위에 무심코 넣은 주석 한 줄이었다. # Part of … 같은 한 줄이 그 아래 frontmatter 파싱을 깨뜨렸고, 시스템은 그 파일들을 에이전트로 인식하지 못했다. 정의는 있는데 시스템은 그들을 보지 못한 것이다. 11개가 이 상태였다. 에러도, 경고도 없었다. 그냥 명단에서 빠져 있었다. 한 번도 돌지 않은 보안 훅 더 무서운 건 보안 훅이었다. 시크릿이 화면에 노출되는 걸 막으려고 만든 훅인데, 코드는 tool_result 라는 필드를 보...

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

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

하네스 엔지니어링 측정 1편 — AGENTS.md 비우면 Codex도 fail-fast 안 지킨다

Codex와 Claude에 같은 명세를 3 condition으로 던졌다 Codex와 Claude에 동일한 Python 함수 명세를 3가지 setup에서 돌렸다. fail-fast 충실도가 약→중→강으로 갈렸고, 그 차이는 모델이 아니라 AGENTS.md 같은 하네스 파일 적용 여부에서 나왔다. 어제 발행한 하네스 엔지니어링 3대 구성요소 글에서 카파시의 이론(컨텍스트 파일·자동 강제 시스템·가비지 컬렉션)을 정리했다. 이 글은 그 이론을 같은 명세 1건으로 직접 측정한 1차 데이터다. YES 3번 — 이런 적 있다면 이 글이 답이 된다 Codex와 Claude Code 차이를 1주 써보고 잘 모르겠다는 결론을 낸 적 있다. 같은 task로 통제 비교를 안 했기 때문에 모델 차이인지 setup 차이인지 분리 못 했다. 도구 비교 글은 많은데 “차이가 어디에서 나오나”를 측정한 글은 본 적 없다. 측정 setup 명세는 Blogger 발행 검증 함수다. verify_published_post(service, blog_id, post_id, expected_title, min_content_length) — 발행 직후 Blogger API로 post를 재조회해 title 일치·content 최소 길이를 검증한다. fail-fast 규칙 적용 (silent default 금지·예외 그대로 raise). 3 condition: Codex v1 — 하네스 0. AGENTS.md 없음. 사용자 시스템 인스트럭션 없음. Claude Opus 4.7 — CLAUDE.md 자동 로드. fail-fast 규칙·Iron Law of Verification 글로벌 메모리에 있음. Codex v2 — Codex v1과 같은 모델. AGENTS.md를 작업 디렉토리에 두고 프롬프트에서 “AGENTS.md 규칙을 적용하라” 명시 인용. 같은 모델·다른 하네스 비교는 1과 3 (Codex v1 vs v2). 다른...