LLM으로 코딩 속도를 높이려는 시도는 이제 흔한 일이 됐지만, 실제로 생산성 향상으로 이어지는지는 별개의 문제다. 그래픽스 프로그래밍으로 잘 알려진 개발자 파비앙 상글라르(Fabien Sanglard)는 자신의 블로그에서 지난 1년간 LLM 코딩 도구를 다시 시도한 경험과, 그 과정에서 정착한 agent.md 활용법을 공유했다. 그의 기록은 도구의 성능 변화뿐 아니라 실무자가 LLM을 어떻게 길들여야 하는지에 대한 구체적인 힌트를 담고 있다.
그가 처음 LLM을 코딩에 써본 것은 2025년 중반, 러스트로 mDNS 구현체인 libadbmdns를 작업할 때였다. 결과는 실망스러웠다. 생성된 코드는 컴파일조차 되지 않았다. 그러나 2026년 1월 다시 시도했을 때는 사정이 달랐다. 인덱스 기반 이진 힙 클래스처럼 복잡한 자료구조를 작성해냈고, 윈도우 IOCP 구현에서 비롯된 polling 크레이트의 난해한 버그까지 짚어냈다. 반년 사이 모델의 실질적인 코딩 능력이 눈에 띄게 올라간 셈이다.
성능은 올랐지만 품질은 별개였다
문제는 코드 품질이었다. 동작은 하지만 주석도 구조도 없는 스파게티 코드였다는 것이 그의 평가다. 이런 코드를 프로덕션 수준으로 다듬는 데 드는 시간이 속도 이득을 상쇄한다면, LLM을 쓰는 의미가 사라진다. 이 지점은 많은 실무자가 공감할 대목이다. 초안을 빠르게 뽑아주는 것과, 그 초안을 팀의 코드베이스에 합류시킬 수 있느냐는 전혀 다른 이야기이기 때문이다.
전환점은 2026년 3월 Antigravity나 VS Code의 Claude Code 플러그인 같은 에이전트형 IDE를 쓰기 시작하면서 찾아왔다. 스테이징된 코드를 놓고 반복적으로 다듬을 수 있게 되자, 그는 마치 인내심 강한 신입 개발자의 코드를 리뷰하듯 매번 같은 주문을 반복하게 됐다. 매직 넘버를 쓰지 말 것, 여기에 짧은 설명 주석을 붙일 것, 함수 이름을 짧게 지을 것 같은 지적들이었다. 이렇게 하자 결과물은 직접 손으로 짠 것에 근접할 만큼 좋아졌지만, 세션마다 같은 말을 되풀이해야 하는 피로가 남았다.
반복되는 지적을 파일 하나로 고정하다
그가 찾은 해법이 agent.md다. 코딩 세션이 시작될 때 하네스가 이 파일을 읽어 프롬프트에 주입하는데, 여기에 코딩 스타일 선호를 미리 적어두면 매번 반복할 필요가 없어진다. 같은 제안을 또 하고 있다는 것을 깨달을 때마다 그 규칙을 파일에 추가하는 방식이다. 프로젝트 루트에 두면 적용되며, gemini.md나 claude.md를 agent.md로 심볼릭 링크해두면 어디서든 동일한 규칙을 쓸 수 있다고 그는 설명한다. 규칙을 새로 넣을 때 굳이 편집기를 열 필요 없이 에이전트에게 agent.md를 직접 갱신해달라고 요청하는 것도 그의 습관이다.
다만 그는 이것이 코드를 읽지 않아도 되게 해주는 만능 해법은 아니라고 분명히 선을 긋는다. LLM은 끊임없이 환각을 일으키며 신뢰할 수 없기에 여전히 많은 검증과 반복이 필요하다. 달라진 점은 검토의 초점이다. 예전에는 코드 스타일을 붙들고 씨름했다면, 이제는 아키텍처와 설계에 시간을 쓸 수 있게 됐다는 것이다. 규칙으로 자동화할 수 있는 영역과, 사람이 직접 판단해야 하는 영역을 나눈 셈이다.
그는 이 접근의 한계로 이른바 '컨텍스트 희석' 또는 '어텐션 희석' 현상도 언급했다. 'Lost in the Middle' 논문에서 지적된 이 문제는 컨텍스트가 길어질수록 모델이 중간에 놓인 지시보다 앞부분과 끝부분에 더 주목하는 경향을 말한다. 왜 이런 일이 벌어지는지는 아직 잘 규명되지 않았다고 그는 덧붙인다. 이는 agent.md에 규칙을 계속 쌓기만 하면 정작 중간에 묻힌 지시는 무시될 수 있다는 뜻이기도 하다. 결국 규칙 파일 역시 무한정 늘리는 것이 능사가 아니며, 무엇을 어디에 배치할지까지 고민해야 하는 도구라는 점을 이 실험은 시사한다.