아프니까 개발자다 아프니까 개발자다

이번엔 또 보안이다내 홈 서버에는 개인 프로젝트 12개가 돌아간다. 지난 며칠 동안 차례로 네 가지 품질 축을 자동화해왔다.ruff로 린트 경고 0mypy로 타입 에러 0pytest-cov로 테스트 커버리지 baseline-lock그리고 지금: 보안 스캔처음엔 "개인 프로젝트에 보안 스캔까지 필요한가"라는 생각이 있었다. 공개 서비스도 아니고, 주로 홈 네트워크 안에서만 동작한다. 그런데 몇 가지가 마음에 걸렸다.의존성은 수시로 업데이트된다. 내가 1년 전에 `pip install`한 라이브러리 중 어떤 게 지금 CVE를 맞고 있는지 모른다.내 코드에 subprocess.run(..., shell=True) 같은 위험한 패턴이 섞여 들어갔는지도 모른다.시크릿이 실수로 코드에 하드코딩됐을 수도 있다.확인해..

왜 또 이걸 하나내 홈 서버에는 개인 프로젝트 11~12개가 돌아간다. 지난 며칠간 차례로:ruff로 린트 경고를 0으로mypy로 타입 에러를 0으로둘 다 Stop/pre-commit hook에 걸어서 재발 방지그다음 자연스럽게 떠오른 질문이 있었다. "테스트는 얼마나 충실히 쓰고 있나?"지금까지 나는 프로젝트마다 pytest로 테스트를 쓰고 있었다. 총 500~600건. 각각 초록불이 떠야만 기능 개발을 이어갔다. 그런데 정작 어디까지 실제로 실행됐는지는 한 번도 측정하지 않았다. coverage 도구(pytest-cov, coverage.py)가 전부 설치조차 되어 있지 않았다.직관적으로는 "적당히 커버하고 있을 것 같다". 하지만 직관은 틀릴 때가 많다. 그래서 확인해보기로 했다.1단계 — 일단 수..

ruff는 깔았는데, 왜 또 타입 체크인가며칠 전 프로젝트 10여 개에 ruff 린트를 돌려 경고 0을 만들었다. 쓰지 않는 import, 오타, 중복 키 — 테스트 통과와 무관하게 조용히 썩고 있던 것들이 드러났다. 그래도 한 가지는 여전히 남아 있었다.타입은 검증되지 않고 있었다. 타입 힌트는 힌트일 뿐, 실제로 맞게 썼는지는 아무도 안 본다. 런타임에서 터지기 전까지는.먼저 현황부터 — baseline mypy12개 Python 프로젝트 전체에 mypy --ignore-missing-imports .를 돌렸다. 결과는 프로젝트별로 의존성과 동적 패턴에 따라 크게 갈렸다.난이도특징대략의 프로젝트 수용이타입힌트 50% 이상 + 의존성 단순(aiohttp 정도)4~5개중간getattr/importlib ..

ruff 바로 뒤이어서 — 같은 날 shellcheck까지오전에 Python 프로젝트 10개에 ruff를 넣으면서 한 줄을 이렇게 남겨뒀다. "shellcheck는 다음 주기에 다루기로 했다 — 한 번에 한 도구씩 확실히 안착시키자." 그렇게 ruff 쪽 정리가 끝나고 나니, 그 "다음 주기"를 굳이 다른 날로 미룰 이유가 없어졌다. 손이 뜨거워진 김에 같은 날 그대로 shellcheck로 넘어갔다.대상은 개인 프로젝트 4곳에 흩어져 있는 bash 스크립트 17개. cron용 엔트리포인트, GPU 자원 관리 도구, 백그라운드 서비스 재시작 스크립트 — 전부 손으로 짠 글루 코드다. Python 쪽은 테스트·ruff로 촘촘히 덮었지만, bash는 "잘 돌아가길래 그냥 둔" 상태였다. 그 "잘 돌아간다"가 ..

왜 갑자기 린트인가개인 프로젝트가 10개까지 늘었다. Python 코드만 180여 개 파일. 각각은 테스트 통과를 확인하며 개발했지만, 프로젝트를 공개 저장소로 옮길 생각을 하면서 한 가지 불안이 생겼다. "내가 쓰지도 않는 import가 도대체 몇 개 남아 있을까?"테스트는 동작을 검증한다. 하지만 린트는 눈으로 확인하지 않은 결함을 잡아낸다. 쓰지 않는 import, 오타가 만든 미정의 참조, 동일 dict에 실수로 두 번 넣은 키. 테스트는 이런 것들이 실행 경로에 없으면 조용히 통과시킨다. 그리고 공개 저장소에 올라간 순간, 남들 눈에 먼저 띈다.그래서 린트를 돌렸다. 도구 고르기부터 hook으로 재발 방지하는 것까지, 하루짜리 작업의 기록이다.도구 선택 — 왜 ruff였나Python 린터는 선택..

시리즈 맥락 복기Step 3까지 우리는 "에이전트에게 무엇을 시킬 것인가"를 정의했습니다. 하지만 시킨 일을 잘못 실행하는 것을 막을 장치가 없으면, Skill이 늘어날수록 사고 위험도 함께 커집니다. Step 4의 Hook은 바로 이 방어선입니다.#0 업무 프로세스 매핑#1 프로젝트 규칙 설정#2 Code Wiki 작성#3 Skill 정의#4 검증 (Hook) ← 이번 편#5 자동 트리거 + 완료 조건... (#8까지)이 단계의 의미 — Hook은 하네스의 안전벨트다Hook은 에이전트가 도구를 실행하기 직전과 직후에 끼어드는 코드입니다. 말에 비유하면 안전벨트 혹은 브레이크에 가깝습니다. 사람이 "출발!"을 외쳐도, Hook이 "길이 막혔다"고 판단하면 실행을 차단합니다. 반대로 실행 후에는 상태를 업..

AI가 코드를 짰다. 근데 제대로 됐나?AI 코딩 에이전트를 쓰다 보면 불안한 순간이 온다. 에이전트가 파일 10개를 수정하고 명령어 5개를 실행했다. 겉보기엔 잘 된 것 같다. 빌드도 통과했다.그런데 이런 의문이 든다:어떤 파일이 어떻게 바뀐 거지?테스트 커버리지가 떨어진 건 아닌가?우리 팀 컨벤션을 지켰나?만약 나중에 문제가 생기면 AI가 뭘 했는지 추적할 수 있나?이 불안을 해소하는 것이 Audit(감사) 시스템이다. 그리고 AI 코딩 에이전트에서 이것을 구현하는 핵심 도구가 PostToolUse 훅이다.PostToolUse 훅이란Hook은 AI 에이전트가 특정 행동을 할 때 자동으로 실행되는 스크립트다. 이전 포스팅에서 Hook의 종류를 소개했는데, 그 중 PostToolUse는 도구 실행이 성공..

Hook이란 무엇인가?AI 코딩 에이전트(Claude Code, Cursor, Copilot 등)가 코드를 읽고 쓰고 명령을 실행할 때, 그 실행 전후에 내가 만든 스크립트를 끼워 넣는 것이 바로 Hook이다.비유하면 이렇다. AI가 파일을 수정하려는 순간, 내가 먼저 "잠깐, 이 파일은 건드리면 안 돼" 하고 막을 수 있다. 혹은 파일이 수정된 직후 "수정됐으니까 린터 돌려줘" 하고 자동으로 후처리를 할 수 있다.즉 Hook은 두 가지 역할을 한다:사전 차단(Pre-hook): 위험한 행동이 실행되기 전에 막는다사후 처리(Post-hook): 실행 완료 후 추가 작업을 자동화한다왜 Hook이 필요한가? - Harness EngineeringAI 코딩 에이전트는 강력하지만 비결정적(non-determin..