[한영자막] 프롬프트는 이제 그만하세요 — Greg Pstrucha, Sentry

한 줄 핵심

AI가 만든 코드는 프롬프트로 계속 고치기보다 테스트·타입·린터와 저장소 정책으로 규칙을 코드화해야 품질을 안정적으로 올릴 수 있다.

시간별 요약

1. 0:00
   AI가 만든 코드를 누가 읽는가? 실제 서비스 코드처럼 위험이 큰 맥락에서는 AI가 만든 코드를 꼼꼼히 읽어야 하지만, 작은 개인 프로젝트에서는 매 줄을 확인할 필요가 없다. 다만 다시 들여다보면 코드가 지나치게 방어적이고 유지보수하기 어려운 경우가 많다.
2. 0:33
   AI가 만든 코드의 문제 에이전트가 만든 코드는 테스트가 부실하고 쓸데없이 복잡해지는 경우가 많아 유지보수가 어려워진다. 이런 문제를 매번 말로 지적해도 근본적인 개선이 잘 안 되고, 가드레일이 없으면 아주 기본적인 실수를 반복한다.
3. 1:18
   에이전트는 같은 실수를 반복한다 에이전트는 수정하겠다고 해도 몇 분 지나 컨텍스트가 압축되면 다시 원점으로 돌아가기 쉽다. 그래서 같은 피드백을 계속 반복하게 되고, 이 방식은 장기적으로 비효율적이다.
4. 1:43
   프롬프트 대신 규칙을 코드로 핵심 해법은 반복적인 프롬프트 조정이 아니라 코드베이스 안에 규칙과 정책을 명시적으로 심는 것이다. 기대하는 관례와 품질 기준을 결정적 검사로 고정해야 에이전트가 따라야 할 기준이 분명해진다.
5. 2:18
   테스트·타입·린터 결정적 수준에서 우선순위가 높은 것은 테스트, 엄격한 타입, 린터다. 다만 타입만으로는 충분하지 않고, 특히 린터를 통해 코드베이스에서 원치 않는 패턴을 체계적으로 제거하는 접근이 중요하다.
6. 3:28
   린터를 만들기 쉬워진 이유 예전에는 린터를 만드는 비용이 높아 자주 반복되는 문제가 아니면 굳이 만들지 않는 경우가 많았다. 그러나 코드를 쓰는 주체가 기억이 없는 에이전트로 바뀌면서 같은 실수가 반복되고, 린터는 훨씬 싸고 쉽게 추가할 수 있게 되었다.
7. 4:48
   리뷰 기록에서 규칙 찾기 과거의 대화 기록, GitHub 리뷰, 봇 피드백, 동료의 코멘트를 분석하면 반복해서 등장하는 문제를 규칙으로 바꿀 수 있다. 그렇게 추출된 규칙은 매번 재설명할 필요가 없는 고품질 린터 후보가 된다.
8. 5:18
   사용자 정의 린터 규칙 사용자 정의 린터는 console.log 제거처럼 단순한 관례부터 디자인 시스템 준수 같은 팀 규칙까지 넓게 적용된다. 에이전트가 코드를 더 많이 쓰는 환경에서는 이런 규칙을 더 세밀하고 복잡한 수준까지 확장할 수 있다.
9. 6:03
   OpenAPI와 API를 동기화하기 오래된 Django·DRF 코드베이스에서는 구현과 OpenAPI schema가 쉽게 어긋난다. 응답 타입, schema 데코레이터, 실제 타입 일치를 린터로 강제하면 API 문서와 구현의 동기화를 훨씬 안정적으로 유지할 수 있다.
10. 7:12
    에이전트 스킬 검증 Sentry agent의 skill 예시 코드가 환각으로 오염되자, 코드 블록이 들어간 skill은 추출·타입체크·샌드박스 실행·OpenAPI 일치 여부를 검증하도록 린터를 만들었다. 이렇게 하면 skill 생성이 API 변화와 더 잘 맞물린다.
11. 8:37
    린터 오류를 따라가며 문제 고치기 린터가 생기면 에이전트는 먼저 규칙을 회피하는 방향으로 움직이므로, 코드 블록 제거, 백틱 제거, prose로 우회, URL 제거 같은 식의 줄다리기가 벌어진다. 그러나 반복적인 미세 조정을 거치면 결국 skill과 schema가 자동으로 맞물리는 상태를 만들 수 있다.
12. 9:57
    ESLint·AST-Grep·Taskless 린터 구현은 ESLint, AuxLint, Flake8, Clippy, AST-Grep 같은 기존 도구로 시작할 수 있다. 최근에는 Task Class처럼 원하는 동작을 영어로 쓰면 린터를 유도하는 방식도 등장하고, 에이전트에게 직접 린터를 생성시키는 방법도 유용하다.
13. 10:47
    린터가 다루지 못하는 판단 상태 수가 과도하게 늘어나는 문제처럼 정량 규칙으로 깔끔하게 표현되지 않는 판단도 많다. 이런 경우에는 린터보다 엔지니어의 경험과 취향이 중요하며, 필요하면 LLM이 보조적으로 검토할 수 있다.
14. 11:42
    저장소 정책과 Grumpy Engineer 저장소 수준의 정책으로는 과도한 테스트 수, 지나치게 방어적인 코드, 원치 않는 상태 표현을 줄이는 기준을 둘 수 있다. 여기에 Grumpy Engineer라는 skill을 만들어 정책별 서브에이전트가 피드백을 주고 물러설 때까지 반복하면, 사람이 보기 전 기본 품질을 크게 끌어올릴 수 있다.
15. 13:27
    숫자로 잰 품질의 함정 cyclomatic complexity나 test coverage 같은 숫자는 에이전트가 쉽게 최적화해버려서 품질을 왜곡할 수 있다. 100% coverage처럼 보이더라도 실제 테스트가 의미 없는 검증이면 오히려 잘못된 안전감을 준다.
16. 14:42
    마무리 실행 가능한 결론은 에이전트에게 린터와 정책 생성을 맡겨 보고, 반복되는 피드백을 규칙으로 바꿔보는 것이다. 말로 계속 고치기보다 코드베이스 안에 기준을 고정하는 쪽이 더 지속 가능하다.

실무 인사이트

• AI 코딩 품질을 올리려면 프롬프트 개선보다 반복 피드백을 린터·테스트·정책으로 전환하는 것이 효과적이다.
• 정량 지표는 에이전트의 최적화 대상이 되기 쉬우므로, coverage 같은 숫자보다 실제 유지보수성과 의도 일치 여부를 함께 봐야 한다.
• 리뷰 코멘트와 과거 실패 사례를 수집해 규칙으로 만드는 작업이, 가장 재사용 가능한 AI 코딩 가드레일을 만든다.