더 느리게, 더 나은 코드를 작성하기 위해 AI 활용하기

많은 사람들이 AI 코딩의 목적이 가능한 한 빠르게 저품질의 코드를 작성하는 것이라고 확신하는 것 같습니다. 간신히 통과할 수준의 쓰레기(slop)를 쏟아내고, 거대한 PR(Pull Request)을 열고, 검토 없이 병합(merge)하는 것이죠. 그냥 배포해 버리는 겁니다!

하지만 문제는 LLM(Large Language Models)은 매우 유연하다는 점입니다. 여러분은 LLM을 더 느리게 고품질의 코드를 작성하는 데에도 똑같이 효과적으로 사용할 수 있습니다.

이 문장은 현시점에서 저에게는 너무나 당연하게 느껴지며, 바로 그 이유 때문에 이 글을 쓰고 싶지 않았을 정도입니다. 하지만 LLM이 오직 쓰레기를 쏟아내는 대포(slop cannons)로서만 유용하다고 확신하는 사람들이 충분히 많아 보이기에, 그 반대의 사례를 제시할 가치가 있다고 판단했습니다.

Mythos가 우리에게 가르쳐준 것이 있다면, LLM 에이전트(agents)는 버그를 찾는 데 정말 뛰어나다는 사실입니다. 코드베이스(codebase)에 에이전트들을 충분히 많이 투입하면, 어떻게 처리해야 할지 모를 정도로 수많은 버그를 찾아낼 것입니다.

다른 많은 이들과 마찬가지로, 저 또한 이것이 Mythos가 아닌 모델들에게도 해당된다는 것을 발견했습니다. 미묘한 버그를 찾거나 오탐(false positives)을 피하는 데 있어 모델마다 차이는 있을 수 있지만, Anthropic과 OpenAI의 최신 공개 모델들은 검토되지 않은 코드베이스에서 충분히 많은 버그를 찾아낼 만큼 성능이 뛰어납니다.

문제는 버그를 찾는 것 자체가 아니라, 버그의 우선순위를 정하고 검증하는 것입니다. 이러한 이유로 저는 이 기사의 핵심 통찰력에서 응용한 Claude 스킬을 가지고 있는데, 그 핵심은 PR 리뷰에 더 많고 다양한 모델을 투입할수록 환각(hallucinations)이나 가짜 버그(bogus bugs)를 얻을 가능성이 낮아진다는 것입니다.

해당 스킬의 내용은 다음과 같습니다 (의역):

Claude 서브 에이전트(sub-agent), Codex, 그리고 Cursor Bugbot를 실행하여 이 PR의 버그를 중요도(critical/high/medium/low) 순으로 찾아내세요. 작업이 모두 완료되면, 그 결과물들을 검토하고, 오탐을 배제하기 위해 직접 조사한 뒤, 최종 보고서를 작성하세요.

기본적으로 이것이 전부입니다. 원한다면 여러분만의 "버그"에 대한 정의를 추가할 수도 있습니다. 저의 경우 KISS 및 DRY 원칙, 접근 가능한 HTML/JSX 작성, SQL 쿼리에 적절한 인덱스(indexes) 사용 등에 관한 규정을 포함하고 있습니다.

제 경험상, 이 기술은 PR(Pull Request)에서 수많은 버그를 찾아내며, 오탐(false positive) 비율은 거의 제로에 가깝습니다. 너무 많은 버그를 찾아내서 그 모든 것을 해결하려고 하면 지루해서 견딜 수 없을 정도일 것입니다. 버그의 범위는 치명적인 보안 또는 정확성 버그부터, 보다 일상적인 중간 수준의 성능(perf) 버그, 그리고 "이 주석은 오해의 소지가 있음"과 같은 낮은 수준의 버그까지 다양합니다.

저의 전형적인 워크플로우는 다음과 같습니다:

• 에이전트(agent)가 모든 치명적(critical) 및 높음(high) 수준의 버그를 수정하도록 합니다 (적절한 해결책에 대한 저의 가이드를 포함하여). 그리고 치명적/높음 수준의 버그가 없을 때까지 반복합니다.
• 투입 대비 효과가 낮은(the juice isn’t worth the squeeze) 높음/중간 수준의 버그는 건너뜁니다 (예: 좁은 엣지 케이스(edge case) 하나를 고치기 위해 100줄의 코드를 수정해야 하는 경우).
• 만약 PR에 치명적인 버그가 너무 많아서 전체적인 접근 방식 자체가 잘못되었다는 것을 깨닫게 되면, 해당 PR을 포기합니다.

이 기술을 사용할 때, 저의 개발 속도(velocity)가 반드시 빨라지는 것을 보지는 못했습니다. 오히려 리뷰 과정에서 기존에 존재하던 버그들이 발견되는 경우가 많아서, 결국 PR 이전부터 존재했던 단위 테스트(unit tests)를 작성하거나 미묘한 결함들을 수정하는 부차적인 사이드 퀘스트(side-quest)에 빠지게 됩니다. 이는 대부분의 사람들이 바이브 코딩(vibe coding)을 생각할 때 상상하는 "10배 생산성"의 슬롭 캐논(slop-cannon) 스타일의 개발과는 정반대되는 방식이지만, 저는 매우 만족스럽습니다.

이는 코드베이스의 전반적인 건강 상태를 개선하는 동시에 코드베이스의 생소한 구석구석을 배우는 아주 좋은 방법입니다. 제 경험상, 복잡한 아키텍처의 해피 패스(happy-path)는 실패 모드(failure modes)보다 덜 흥미롭습니다. 그리고 LLM(Large Language Model)이 나오기 전에도, 저는 보통 이런 방식으로 코드베이스에 익숙해졌습니다. 즉, 가정이 깨지는 지점을 이해하고, 그것을 고치기 위해 직접 손을 더럽히는 방식 말입니다.

만약 당신이 AI 코딩이 그 무엇에도 도움이 되지 않을 것이라고 회의적인 사람이라면, 이 글이 당신을 설득할 수 있을지는 의문입니다. 하지만 에이전트를 사용하여 스스로도 거의 이해하지 못하는 수백 줄짜리 PR을 작성하는 유형의 개발자라면, 조금 천천히 속도를 줄이고 이 다른, 더 느린 스타일의 "바이브 코딩"을 시도해 보라고 권하고 싶습니다. 에이전트에게 당신의 PR이 어떻게 작동하는지, 그리고 어떻게 실패할 수 있는지 물어보세요. 필요하다면 Mermaid 차트를 포함한 마크다운(Markdown) 문서를 작성하게 하세요. Matt Pocock의 /grill-me를 사용해 보세요.

전체 PR (Pull Request)을 처음부터 끝까지 완전히 이해할 때까지 기술을 연마하세요.

단순히 작성하는 코드의 양 측면에서는 더 "생산적 (productive)"이지 않을 수도 있습니다. 당신의 계획 전체가 처음부터 잘못되었다는 것을 알아내기 위해 엄청난 양의 토큰 (tokens)을 소모할 수도 있습니다. 하지만 저는 이러한 방식의 코딩이 LLM (Large Language Models)이 등장하기 전부터 제가 이미 시도하려 했던 프로그래밍 방식의 더욱 강력한 버전이라고 생각합니다. 즉, 신중하고, 체계적이며, 품질에 집착하고, 다음 개발자를 위해 상황을 더 개선하는 데 집중하는 방식 말입니다.

그러니 심호흡을 하고, 속도를 늦추고, 이 기술을 시도해 보세요. 그리고 더 느리게, 하지만 더 나은 코드를 작성하는 과정이 얼마나 즐거운지 직접 확인해 보시기 바랍니다.