Stop Prompting — Greg Pstrucha, Sentry

한 줄 핵심

AI가 만든 코드를 계속 말로만 교정하지 말고, 테스트·타입·린터·정책으로 규칙을 코드베이스에 박아 넣어야 에이전트의 반복 실수를 줄일 수 있다.

시간별 요약

1. 0:00
   소개 Sentry의 AI 엔지니어가 에이전트가 만드는 코드의 반복적 실수를 줄이기 위해서는 프롬프트를 더 잘하는 것보다 규칙을 코드로 고정하는 방식이 중요하다고 문제를 제기한다.
2. 0:38
   누가 아직 AI 코드를 읽는가? 운영 코드처럼 위험한 영역에서는 AI가 생성한 코드를 직접 검토해야 하지만, 부수 프로젝트나 낮은 위험도 작업에서는 모든 줄을 읽지 않아도 된다. 결국 검토 수준은 맥락에 따라 달라진다.
3. 1:13
   코드는 형편없다 에이전트는 과도하게 방어적인 코드와 의미 없는 테스트 같은 초보적 실수를 자주 만든다. 이런 문제를 매번 대화로 고치면 좌절만 누적된다.
4. 1:58
   당신 말이 맞습니다 에이전트는 피드백을 받으면 잠깐은 수정하지만, 컨텍스트가 압축되면 같은 실수를 다시 반복한다. 같은 지적을 반복하지 않으려면 규칙이 기억되어야 한다.
5. 2:23
   프롬프트를 멈추고 규칙을 코드화하라 대화로 매번 고치는 대신 코드베이스 안에 지켜야 할 규칙과 정책을 명문화해야 한다. 기대하는 품질과 관례를 결정론적 검사를 통해 강제하는 것이 핵심이다.
6. 2:58
   테스트, 엄격한 타입, 린터 결정론적 장치로는 테스트, strict types, linters가 중요하며, 특히 린터가 규칙을 고정하는 데 가장 직접적이다. 다만 이것들만으로 좋은 코드를 보장할 수는 없고, 제약 설계가 함께 필요하다.
7. 4:08
   지금 린트 규칙이 저렴한 이유 예전에는 린터를 만드는 비용이 컸지만, 지금은 에이전트가 규칙 작성 자체를 도와주기 때문에 훨씬 싸고 빠르다. 인간과 달리 에이전트는 같은 실수를 반복하므로 규칙화의 효과가 더 크다.
8. 5:28
   대화 기록에서 규칙을 발굴하라 과거의 리뷰, 봇 피드백, 동료 코멘트를 훑어 반복적으로 지적되는 문제를 린트 규칙으로 전환해야 한다. 이미 자주 재지시하던 문제는 대체로 규칙 후보가 된다.
9. 5:58
   맞춤형 린트 규칙 맞춤 린트는 console.log 금지나 design system 사용 강제처럼 코드베이스의 관례를 자동화하는 데서 시작한다. 에이전트 시대에는 더 복잡한 패턴까지 규칙화할 수 있다.
10. 6:43
    API를 서로 맞추는 예시 Django와 DRF 기반의 오래된 코드베이스에서 endpoint의 반환 타입, 문서화, OpenAPI 스키마 일치를 린트로 강제해 API 드리프트를 줄인다. 이를 통해 생성 코드와 실제 API 정의가 더 잘 맞아떨어진다.
11. 7:52
    에이전트 스킬 린팅 예시 Sentry의 debugging agent용 skill은 예제 코드 블록이 hallucination으로 오염될 수 있어, 코드 블록이 실제로 타입 검사와 sandbox 실행을 통과하는지 린트한다. 이렇게 해야 skill과 OpenAPI schema의 정합성을 유지할 수 있다.
12. 9:17
    에이전트와의 두더지잡기 규칙을 추가하면 에이전트가 그 빈틈을 피해 다른 방식으로 문제를 회피하는 일이 생긴다. 예제를 코드 블록에서 빼거나 URL을 지우는 식의 우회가 반복되지만, 결국 규칙을 보강해 정합성을 맞춘다.
13. 10:37
    도구: ESLint, ast-grep, Taskless ESLint, flake8, clippy, ast-grep 같은 기존 도구를 활용할 수 있고, ast-grep은 언어에 덜 종속적이다. Taskless처럼 원하는 동작을 영어로 적으면 린터를 유도하는 방식도 등장하고 있다.
14. 11:27
    린터만으로는 부족할 때 상태 수 증가나 구조적 품질 저하처럼 정량 규칙으로 잘 표현되지 않는 문제도 많다. 이 경우에는 경험과 감각으로 거절해야 하며, 일부는 LLM 보조 검토로만 다룰 수 있다.
15. 12:22
    정책과 Grumpy Engineer 과도한 테스트나 과도한 방어 코드를 피하라는 저장소 정책을 만들고, 이를 여러 하위 에이전트가 점검하는 Grumpy Engineer 스킬로 구현한다. 목표는 코드 리뷰를 없애는 것이 아니라 검토의 기준선을 높이는 것이다.
16. 14:07
    조작되는 지표를 조심하라 cyclomatic complexity나 test coverage처럼 수치화된 지표는 에이전트가 숫자만 최적화하게 만들 위험이 크다. 100% coverage라도 실제 테스트 품질이 나쁘면 잘못된 안도감만 준다.
17. 15:22
    행동 촉구 지금 바로 에이전트에게 린터와 정책 생성을 시켜 보고, 저장소가 스스로 규칙을 기억하게 만드는 실험을 해보는 것이 권장된다. 핵심은 말로만 고치지 말고 규칙을 남기는 것이다.

실무 인사이트

• AI 코드 품질 개선은 프롬프트 튜닝보다 규칙의 영속화가 더 효과적이므로, 반복 지적되는 리뷰 코멘트를 린트 규칙 후보로 전환하는 프로세스를 두는 것이 좋다.
• 린트 규칙은 단순 스타일 가이드보다 API 스키마 정합성, skill 예제의 실행 가능성처럼 에이전트가 자주 틀리는 구조적 문제를 잡는 데 투자 가치가 크다.
• 정량 지표는 에이전트의 최적화 대상이 되기 쉬우므로, coverage 같은 숫자는 보조 신호로만 쓰고 실제 품질 판단은 정책·리뷰·경험 기반으로 유지해야 한다.