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

왜 지금 서브에이전트인가집에 있는 개발 서버에서 12개 정도의 파이썬 프로젝트(편의상 프로젝트 A~L로 부르겠다)를 굴리고 있다. 시간이 쌓이면서 다음이 다 붙었다.Stop 훅 — 편집 후 ruff 린트, mypy(대상 5개 프로젝트), pytest 커버리지 baseline-lock, bandit/pip-audit 재스캔pre_commit 훅 — 커밋 전 gitleaks 스캔 + 동일 검증 재실행20+ 개 프로젝트별 Skills — *-dev 네이밍으로 TDD 사이클 체크리스트를 강제audit 훅 — 모든 Bash/Edit을 logs/audit.jsonl에 기록즉, 결정론적 검증은 꽤 촘촘해졌다. 그런데 가만히 작업 흐름을 돌아보니 항상 같은 곳에서 막혔다."이 subprocess.run(..., she..

잃어버린 Visio 파일 하나에서 시작된 프로젝트mermaid는 2014년 스웨덴 개발자 Knut Sveidqvist가 만든 오픈소스다. 계기는 단순하지만 상징적이었다 — 중요한 Visio 파일을 잃어버렸다. 바이너리 .vsdx는 diff가 안 되고, Git에 올려도 변경 이력을 추적할 수 없고, 노트북이 바뀌면 같이 사라진다. 아키텍처가 바뀔 때마다 누군가 GUI를 열어 박스를 다시 그려야 하는 구조였다.Sveidqvist의 통찰은 한 줄이다. "문서가 코드라면 다이어그램도 코드여야 한다." 첫 버전은 flowchart와 sequence 두 종류만 지원했고, 문법은 Markdown처럼 소문자 중심으로 설계했다. 이름은 당시 자녀들이 보던 『인어공주(The Little Mermaid)』에서 따왔다.202..

Javadoc에서 영감 받은 UML 도구PlantUML은 프랑스 개발자 Arnaud Roques가 2009년 4월 17일 SourceForge에 공개한 오픈소스 Java 컴포넌트다. 당시 그는 "Web Sequence Diagrams" 사이트를 보고 "Javadoc처럼 텍스트에서 다이어그램을 자동 생성하자"는 아이디어를 UML 전체로 확장했다.출발점 동기는 세 가지였다. 첫째, Rational Rose 같은 GUI 도구가 코드 변경을 못 따라가서 다이어그램이 낡아버리는 문제. 둘째, Microsoft Word 문서용 다이어그램 자동 생성 수요. 셋째, 위키·코드 주석에 UML을 직접 삽입해 애자일 문화에 녹이는 것. 결과적으로 PlantUML은 mermaid보다 5년 먼저 나온 "Diagram-as-Co..

들어가며 — 에이전트는 왜 삽질하는가AI 코딩 에이전트에게 "기존 XML 레이아웃을 Jetpack Compose로 마이그레이션해줘"라고 시키면 어떤 일이 벌어질까? 에이전트는 Compose 코드 자체는 잘 짠다. 하지만 마이그레이션은 단순 변환이 아니다. 어떤 순서로 진행해야 하는지, 기존 View와 Compose를 혼용하는 과도기에 어떤 패턴을 써야 하는지, 테스트는 어떻게 바꿔야 하는지 — 이런 작업 절차는 코드 생성 능력만으로 해결되지 않는다. 에이전트는 시행착오를 반복하며 토큰을 쏟아붓고, 결과물의 품질은 들쑥날쑥해진다.Google이 Android CLI와 함께 발표한 Android Skills는 이 문제에 대한 구조적인 해법이다. 그런데 더 흥미로운 건, Android Skills가 Google..

들어가며 — "Agent를 위한 SDK"라는 질문2026년 4월, Google이 Android 개발 블로그에 흥미로운 글을 올렸다. 제목은 "Build Android Apps 3X Faster Using Any Agent". AI 에이전트를 활용해 안드로이드 앱을 3배 빠르게 만들 수 있다는 이야기다.이 글을 읽으면서 한 가지 질문이 떠올랐다. Agent를 위한 SDK는 어떤 모습이어야 하는가? 지금까지 SDK는 사람이 쓰는 것이었다. 문서를 읽고, API를 이해하고, 코드를 작성하는 주체는 개발자였다. 그런데 이제 그 주체가 LLM 에이전트로 바뀌고 있다. Google은 이 전환에 대해 나름의 답을 내놓았다.Android CLI — 에이전트가 쓰는 도구Google이 발표한 핵심 도구는 Android C..

"수동 유지 불가능" 앞에서 선택한 길함수 수백 개, 클래스 수십 개, 공개 API 전부에 수동으로 설명서를 붙이는 건 유지보수가 불가능하다. 6개월만 지나도 시그니처가 바뀌고 문서는 그대로 거짓말을 한다. 그래서 자동 생성 도구가 필요하다. Python 생태계에서 2008년에 등장해 지금도 사실상 표준인 도구가 바로 Sphinx다.Sphinx의 핵심은 한 문장으로 요약된다. "코드 안의 docstring을 읽어서 HTML 문서 사이트로 자동 변환한다". 함수 설명을 코드 옆에 한 번 쓰면, CI가 돌 때마다 자동으로 사이트가 갱신된다. 사람은 docstring만 쓰고, Sphinx가 나머지를 다 한다.Sphinx가 왜 나왔는가 — 해결하려던 3가지 문제Sphinx는 Georg Brandl이 Python..

"모든 함수에 설명서"는 왜 망하는가신규 프로젝트를 시작할 때 누군가 "모든 public 함수에 문서를 달자"고 하면 대부분 처음엔 진지하게 따른다. 3개월 뒤 현실은 둘 중 하나다. (1) 모든 함수에 "Does X."라는 의미 없는 한 줄이 붙어 있거나, (2) 시그니처는 바뀌었는데 docstring은 그대로 거짓말을 한다. 이게 "모든 함수 설명서" 규칙이 유지보수 불가능한 이유다.해법은 두 가지다. Type hints로 타입 계약을 선언하고, docstring으로 동작(behavior)만 서술한다. 타입은 자동 검증되고, docstring은 "왜 이렇게 동작하는지", "어떤 예외가 나는지"만 담는다. 2026년 Python 커뮤니티 best practice가 이 분리에 수렴했다.PEP 257 — ..

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