AI를 활용해 더 느리지만 더 나은 코드 작성하기
이 글은 AI 코딩의 목적이 단순히 대량의 저품질 코드를 빠르게 양산하는 것이 아니라, 오히려 코드 품질을 높이기 위해 더 느리고 꼼꼼하게 작업하는 데 활용해야 한다고 주장합니다. 저자는 여러 LLM 에이전트를 활용해 PR의 버그를 찾고 가양성을 제거하는 워크플로우를 소개하며, 이를 통해 전체 코드베이스의 건강성을 크게 개선할 수 있다고 설명합니다.
Read the Tea Leaves Software and other dark arts, by Nolan Lawson
많은 사람들이 AI 코딩의 요점은 최대한 빨리 저품질 코드를 작성하는 것이라고 확신하는 것 같습니다. 그럭저럭 넘어갈 만한 쓰레기 코드(slop)를 쏟아내고, 거대한 PR(풀 리퀘스트)을 열고, 검증 없이 병합하는 식입니다. 일단 배포해요!
하지만 사실 LLM(대형 언어 모델)은 매우 유연합니다. 그리고 이를 활용해 더 느리게 고품질 코드를 작성하는 데에도 똑같이 효과적으로 사용할 수 있습니다.
이 말은 지금 저에게 너무나 당연해 보여서, 사실 이 글을 쓰고 싶지 않을 정도였습니다. 하지만 LLM은 그저 쓰레기 코드 제조기(slop cannons)로만 쓸모있다고 확신하는 사람들이 여전히 충분히 많기에 반대되는 의견을 제시할 가치가 있다고 생각했습니다.
만약 Mythos가 우리에게 무언가를 가르쳐줬다면, 그것은 LLM 에이전트가 버그를 찾는 데 매우 뛰어나다는 것입니다. 코드베이스에 에이전트를 여러 번 던져보면, 처리할 수 없을 정도로 수많은 버그를 찾아낼 것입니다. 다른 많은 분들처럼, 저 역시 Mythos가 아닌 다른 모델들에서도 이것이 사실임을 발견했습니다. 미묘한 버그를 찾거나 가양성(false positive)을 피하는 데 있어 일부 모델이 다른 모델보다 더 뛰어날 수 있지만, Anthropic과 OpenAI의 최신 공개 모델들이 검증되지 않은 코드베이스에서 수많은 버그를 찾기에 충분히 훌륭하다는 것은 사실입니다.
문제는 버그를 찾는 것 자체보다는, 이를 우선순위로 정하고 검증하는 데 있습니다. 이러한 이유로 저는 한 글의 핵심 통찰력을 응용하여 나만의 Claude 스킬(기능)을 만들었습니다. 그 통찰이란, 하나의 PR 리뷰에 더 많고 다양한 모델을 투입할수록 환각(hallucination)이나 가짜 버그가 나올 가능성이 줄어든다는 것입니다.
이 스킬의 지시문은 다음과 같습니다 (요약): "Claude 하위 에이전트, Codex, 그리고 Cursor Bugbot을 실행하여 이 PR의 버그를 Critical(심각)/High(높음)/Medium(보통)/Low(낮음) 순위로 찾아라. 모든 작업이 끝나면, 그 결과를 검토하고 가양성을 제거하기 위해 직접 조사한 뒤 최종 보고서를 작성해라."
기본적으로 이게 전부입니다. 원한다면 '버그'에 대한 본인만의 정의를 추가할 수 있습니다. 저의 경우 KISS(단순하게 유지)와 DRY(반복하지 않기) 원칙, 접근성 높은 HTML/JSX 작성, SQL 쿼리에 적절한 인덱스 사용 등에 대한 조항을 포함시켰습니다.
제 경험상, 이 스킬은 항상 PR에서 수많은 버그를 찾아내며 가양성 비율은 거의 0%에 가깝습니다. 버그가 너무 많이 발견되어, 이를 모두 해결하려고 하면 지루하고 기진맥진해질 것입니다. 치명적인 보안 또는 정확성 버그부터, 더 일상적인 중간 수준의 성능 버그, 그리고 낮은 수준의 '이 주석은 오해의 소지가 있다'는 식의 버그까지 아주 다양하게 나옵니다.
저의 일반적인 워크플로우는 다음과 같습니다:
- (올바른 솔루션에 대한 저의 가이드와 함께) 에이전트가 모든 Critical 및 High 버그를 수정하게 한 뒤, 더 이상 Critical/High 버그가 없을 때까지 반복합니다.
- 수정 비용 대비 얻는 이익이 적은 High/Medium 버그는 건너뜁니다 (예: 좁은 예외 상황 하나를 수정하기 위해 100줄의 코드를 작성해야 하는 경우).
- Critical 버그가 너무 많아서 PR의 전체적인 접근 방식 자체가 잘못되었다는 것을 깨닫게 되면, PR을 폐기합니다.
저는 이 기술을 사용할 때 제 개발 속도(velocity)가 반드시 빨라진다고 생각하지 않습니다. 오히려 리뷰 과정에서 기존에 존재하던 버그가 자주 발견되기 때문에, 단위 테스트(unit test)를 작성하고 PR 이전부터 존재했던 미묘한 결함들을 수정하는 엉뚱한 사이드 퀘스트에 빠지게 됩니다.
이는 대부분의 사람들이 '바이브 코딩(vibe coding)'을 떠올릴 때 상상하는 '10배 빠른 생산성'의 쓰레기 코드 배출 스타일과는 정반대이지만, 저는 이 방식이 매우 만족스럽습니다. 이는 코드베이스의 전반적인 건강성을 개선하는 훌륭한 방법일 뿐만 아니라, 코드베이스의 복잡하고 잘 모르던 구석에 대해서도 알려줍니다.
제 경험상, 복잡한 아키텍처의 정상 경로(happy-path)보다 실패 모드(failure modes)가 더 흥미로운 경우가 많습니다. 그리고 LLM 이전의 시절에는 보통 이런 방식으로 코드베이스에 익숙해졌습니다. 즉, 코드의 기본 전제가 어디에서 무너지는지 이해하고, 직접 손을 더럽혀 이를 수정하는 식이었습니다.
만약 여러분이 'AI 코딩은 쓸모가 없다'고 회의적인 사람이라면, 이 글이 여러분을 설득하지 못할 것이라고 생각합니다. 하지만 여러분이 에이전트를 사용해 스스로도 제대로 이해하지 못하는 수백 줄짜리 PR을 작성하는 개발자라면, 속도를 조금 늦추고 이 다른, 그리고 더 느린 스타일의 '바이브 코딩'을 시도해 보기를 권하고 싶습니다. 에이전트에게 여러분의 PR이 어떻게 작동하며 어떻게 실패할 수 있는지 물어보세요.