AI 코딩을 빠르게 대충 처리하는 도구가 아니라, 더 신중하고 체계적으로 고품질 코드를 작성하는 데 활용하는 방법을 다룬 글입니다.
많은 사람들이 AI 코딩의 핵심은 가능한 한 빨리 저품질 코드를 작성하는 것이라고 확신하는 듯하다. 간신히 통과할 만한 엉성한 결과물을 마구 뱉어내고, 거대한 PR을 열고, 검토도 제대로 하지 않은 채 머지한다. 배포하자!
하지만 중요한 점은, LLM은 매우 유연하다는 것이다. 그리고 그것들을 사용해 고품질 코드를 더 느리게 작성하는 것도 얼마든지 똑같이 효과적으로 할 수 있다.
이 말은 이제 내게는 너무도 자명하게 느껴져서, 그 이유 때문에 이 글을 거의 쓰고 싶지 않을 정도였다. 하지만 LLM은 slop cannons로만 쓸모가 있다고 확신하는 사람들이 충분히 많은 것 같아서, 그 반대 입장을 이야기할 가치는 있다고 본다.
Mythos가 우리에게 무언가를 가르쳐줬다면, 그것은 LLM 에이전트가 버그를 찾는 데 정말 뛰어나다 는 점이다. 코드베이스에 충분히 여러 번 투입하면, 어떻게 처리해야 할지 막막할 정도로 많은 버그를 찾아낼 것이다.
많은 다른 사람들처럼, 나 역시 이것이 Mythos가 아닌 모델들에도 해당된다는 것을 확인했다. 어떤 모델은 미묘한 버그를 더 잘 찾거나 거짓 양성을 더 잘 피할 수도 있겠지만, 사실 Anthropic과 OpenAI의 최신 공개 모델들은 검토되지 않은 코드베이스에서 충분히 많은 버그를 찾아내기에 이미 충분히 뛰어나다.
문제는 버그를 찾는 것 자체라기보다, 그것들의 우선순위를 정하고 검증하는 데 있다. 그래서 나는 이 글의 핵심 통찰을 바탕으로 수정한 Claude 스킬을 가지고 있는데, 그 통찰이란 PR 리뷰에 더 많고 서로 다른 모델을 투입할수록 환각이나 엉터리 버그를 접할 가능성이 줄어든다는 것이다.
그 스킬은 이렇게 말한다(의역하면):
이 PR에서 버그를 critical/high/medium/low 순위로 찾아내기 위해 Claude 서브 에이전트, Codex, 그리고 Cursor Bugbot을 실행하라. 모두 끝나면, 그들의 발견 사항을 검토하고, 거짓 양성을 배제하기 위해 스스로 추가 조사를 한 뒤, 최종 보고서를 작성하라.
기본적으로는 그게 전부다. 원한다면 “버그”에 대한 자신만의 정의를 추가할 수도 있다. 내 경우에는 KISS와 DRY 원칙, 접근성 있는 HTML/JSX 작성, SQL 쿼리에 적절한 인덱스 사용 등에 대한 조건이 들어 있다.
내 경험상, 이 스킬은 PR에서 항상 엄청나게 많은 버그를 찾아내고, 거짓 양성 비율은 거의 0에 가깝다. 너무 많은 버그를 찾아내기 때문에, 그것들을 전부 처리하려고 하면 지루해서 견디기 힘들 정도다. 그 버그들은 치명적인 보안 또는 정확성 문제부터, 좀 더 평범한 중간 수준의 성능 버그, 낮은 수준의 “이 주석은 오해를 부른다” 같은 유형의 버그까지 다양하게 걸쳐 있다.
내가 보통 따르는 워크플로는 이렇다:
이 기법을 사용할 때, 내 속도가 꼭 빨라진다고 느끼지는 않았다. 오히려 리뷰 과정에서 기존에 있던 버그가 자주 발견되기 때문에, 결국 나는 PR보다 앞서 존재하던 미묘한 결함을 고치고 유닛 테스트를 작성하는 곁가지 탐험에 들어가곤 한다. 이것은 사람들이 바이브 코딩을 떠올릴 때 흔히 상상하는 “10배 생산성”의 slop-cannon식 개발과는 정반대지만, 나는 이 과정이 아주 만족스럽다.
이 방식은 코드베이스의 전반적인 건강 상태를 개선하는 동시에 그 낯선 구석구석을 배우는 데에도 아주 좋다. 내 경험상, 복잡한 아키텍처의 정상 경로보다 실패 모드가 더 흥미롭다. 그리고 LLM 이전에도, 내가 보통 코드베이스에 익숙해지던 방식은 바로 이것이었다. 가정이 어디서 무너지는지 이해하고, 직접 손을 더럽혀가며 그것을 고치는 것 말이다.
만약 당신이 AI 코딩이 어떤 것에도 쓸모없다고 회의적으로 보는 사람이라면, 아마 이 글이 당신을 설득하지는 못할 것이다. 하지만 자신도 거의 이해하지 못한 채 수백 줄짜리 PR을 작성하게 에이전트를 사용하는 개발자라면, 잠시 속도를 늦추고 이런 다른, 더 느린 스타일의 “바이브 코딩”을 시도해보라고 권하고 싶다. 에이전트에게 당신의 PR이 어떻게 작동하는지, 그리고 어떻게 실패할 수 있는지 물어보라. 필요하다면 Mermaid charts가 포함된 Markdown 문서를 작성하게 하라. PR의 앞뒤를 완전히 이해할 때까지 Matt Pocock의 /grill-me 스킬을 활용하라.
순수한 코드 라인 수 기준으로는 더 “생산적”이지 않을 수도 있다. 시작부터 계획 전체가 잘못된 방향이었다는 사실을 알아내기 위해 엄청난 양의 토큰을 태우게 될 수도 있다. 하지만 나는 이런 코딩 스타일이 LLM 이전부터 내가 하려고 애쓰던 종류의 프로그래밍을 더 강력하게 확장한 버전이라고 느낀다. 신중하고, 체계적이며, 품질에 집착하고, 다음 코더를 위해 더 나은 상태를 만드는 데 집중하는 방식 말이다.
그러니 깊게 숨을 들이쉬고, 속도를 늦추고, 이 기법을 시도해보라. 그러면 더 나은 코드를 더 느리게 작성하는 일이 의외로 꽤 즐겁다는 것을 알게 될지도 모른다.
