AI 코딩, '빠르게'가 아니라 '느리게'로 '잘' 쓰는 비결
요즘 AI 코딩에 대한 이야기가 정말 뜨겁죠. 많은 사람들이 AI를 써서 마치 마법처럼 순식간에 코드를 쏟아내는 것을 상상합니다. 버그가 많든 말든, 일단 빠르게 찔러 넣고 보는 식의 개발 말이에요. 하지만 소프트웨어 엔지니어 놀란 로슨은 정반대의 접근법을 제안합니다. AI를 이용해 '더 느리게, 하지만 더 잘' 코드를 작성하는 방법 말이죠. 이게 대체 무슨 소리인지, 그리고 우리에게 어떤 의미가 있는지 함께 파헤쳐 볼까요?
AI 코딩, '슬로건'이 아니라 '꼼꼼함'으로 가는 길
AI, 특히 거대 언어 모델(LLM)을 이용한 코딩이 마치 '초당 10x 생산성'만을 위한 도구처럼 여겨지는 경향이 있습니다. 마치 코드 덩어리를 마구잡이로 뱉어내고, 검증도 제대로 안 된 채로 병합하는 식 말이죠. 하지만 LLM의 진짜 힘은 그 '유연성'에 있습니다. 우리가 생각하는 것 이상으로 다양한 방식으로 활용될 수 있거든요. 특히, AI를 '오류를 잡아내는 탁월한 탐정'으로 활용한다면, 우리가 상상하는 것보다 훨씬 더 '고품질의 코드'를 '느리게' 만들 수 있다는 것이 놀란 로슨의 주장입니다.
그는 AI 에이전트가 코드베이스를 샅샅이 뒤져 버그를 찾아내는 데 매우 뛰어나다고 말합니다. 물론 최신 AI 모델들이 완벽하진 않습니다. 때로는 엉뚱한 오류를 보고하거나, 실제 존재하지 않는 버그를 찾아낼 수도 있죠. 하지만 중요한 것은, 이러한 AI를 여러 개 동시에 활용하면 이런 '환각'이나 '잘못된 버그 보고'의 가능성을 현저히 낮출 수 있다는 것입니다. 놀란 로슨은 이 점에 착안해 'PR(Pull Request) 검토' 과정에 AI를 접목시키는 자신만의 방법을 개발했습니다. 여러 AI 에이전트에게 코드를 검토하게 하고, 그 결과들을 종합적으로 분석하여 실제 버그인지 아닌지를 판단하는 방식입니다.
AI, '버그 탐지기'로 변신하다: 실질적인 활용법
그렇다면 이 '느린 코딩' 방식은 실제로 어떻게 작동할까요? 놀란 로슨의 핵심 아이디어는 이렇습니다. PR 검토 과정에 여러 AI 모델(그는 Claude, Codex, Cursor Bugbot 등을 언급)을 투입하여 버그를 찾아내고, 이 버그들을 심각도별로 분류하는 것입니다. 여기서 중요한 점은, AI가 찾아낸 모든 것을 맹신하는 것이 아니라, 개발자가 직접 검토하고 '헛점'을 걸러내는 과정이 필수적이라는 것입니다. 그가 정의하는 '버그'는 단순히 코드 오류뿐만 아니라, KISS (Keep It Simple, Stupid)나 DRY (Don't Repeat Yourself) 원칙 위배, 접근성이 떨어지는 HTML/JSX 작성, SQL 쿼리의 부적절한 인덱스 사용 등 다양한 측면을 포함합니다.
놀란 로슨은 이 방법을 사용했을 때 PR에서 '엄청난 수의 버그'를 발견하게 된다고 이야기합니다. 이 버그들은 심각한 보안 취약점이나 기능 오류부터 시작해서, 성능을 저하시키는 중간 수준의 문제, 심지어는 주석이 잘못되었다는 수준의 사소한 문제까지 다양하다고 합니다. 그의 일반적인 작업 흐름은 다음과 같습니다. 먼저 AI에게 '치명적'이거나 '높음' 수준의 버그를 수정하도록 지시하고, 그의 안내에 따라 AI가 수정 작업을 진행합니다. 이 과정을 반복하면서 더 이상 심각한 버그가 없을 때까지 진행하는 것이죠. 때로는 '이 정도 수정하자고 코드가 이렇게 길어지나?' 싶을 정도로 효율성이 떨어지는 버그는 과감히 포기하기도 합니다. 만약 PR에 너무 많은 치명적인 버그가 발견된다면, 애초에 접근 방식 자체가 잘못되었음을 깨닫고 PR을 되돌리기도 합니다.
'느리게' 코딩하는 것이 '더 나은 코드'로 가는 이유
이런 방식을 사용하면, 단순히 코드 라인 수만 놓고 봤을 때 생산성이 높아졌다고 느끼기는 어려울 수 있습니다. 오히려 기존에 존재했던 버그를 발견하게 되어, PR과는 별개로 단위 테스트를 작성하고 미묘한 오류를 수정하는 '부차적인 작업'에 더 많은 시간을 쏟게 될 수도 있습니다. 흔히 이야기하는 AI 코딩의 '10x 생산성'과는 거리가 멀어 보입니다. 하지만 놀란 로슨은 이러한 방식이 '매우 만족스럽다'고 말합니다. 이 과정을 통해 코드베이스의 전반적인 '건강'을 향상시킬 수 있을 뿐만 아니라, 코드의 '숨겨진 구석'들에 대해 배우는 기회까지 얻게 된다는 것이죠.
그는 복잡한 아키텍처에서 '가장 쉬운 경로'를 따라가는 것보다, 그 아키텍처가 '실패하는 지점'을 이해하는 것이 더 흥미롭다고 말합니다. 그리고 LLM이 등장하기 전에도 그는 이런 방식으로 코드를 이해하곤 했습니다. 즉, 기존의 가정들이 깨지는 지점을 찾고, 그것을 고쳐나가는 과정 말이죠. 만약 당신이 AI 코딩이 쓸모없다고 회의적인 사람이라면, 이 글이 당신을 설득시키지는 못할지도 모릅니다. 하지만 당신이 AI 에이전트에게 수백 줄의 코드를 맡기고, 정작 그 코드가 어떻게 작동하는지 제대로 이해하지 못하는 개발자라면, 한번쯤 '천천히' 코딩하는 이 '다른 스타일'의 '바이브 코딩'을 시도해보라고 권하고 싶습니다.
AI 코딩, '속도'보다 '깊이'를 탐구하다
AI에게 당신의 PR이 어떻게 작동하는지, 그리고 어떻게 실패할 수 있는지 물어보세요. 필요하다면 Mermaid 차트를 활용한 마크다운 문서를 작성하게 할 수도 있습니다. 매트 포콕의 '/grill-me' 스킬 같은 것을 활용하여 PR 전체를 처음부터 끝까지 이해할 때까지 스스로를 ' grill' 해볼 수도 있습니다. 코드 라인 수로는 분명 더 '생산적'이지 않을 수 있습니다. 어쩌면 당신의 계획 전체가 처음부터 잘못되었다는 것을 깨닫기 위해 엄청난 양의 토큰을 소모하게 될 수도 있습니다. 하지만 놀란 로슨은 이 스타일의 코딩이 이전 LLM 이전 시대에 그가 하려 했던 '신중하고, 체계적이며, 품질에 집착하고, 다음 코더를 위해 더 나은 것을 만드는 데 집중하는' 프로그래밍의 '슈퍼파워 버전'이라고 말합니다.
결국 AI 코딩의 진정한 가치는 속도 경쟁에 있지 않을지도 모릅니다. 마치 마라톤 선수처럼, 때로는 잠시 멈춰 서서 호흡을 가다듬고, 내비게이션을 다시 확인하며, 자신의 경로가 옳은지 점검하는 과정이 필요합니다. AI라는 강력한 도구를 단순히 '빠르게' 찍어내는 도구로만 사용하기보다, '깊이'를 탐구하고 '품질'을 높이는 파트너로 삼는다면, 우리는 분명 우리가 생각했던 것보다 훨씬 더 '잘' 코드를 작성할 수 있을 것입니다. 그러니 잠시 숨을 고르고, 속도를 늦추고, 이 방법을 시도해보세요. 어쩌면 당신도 '더 나은 코드를 더 느리게' 작성하는 즐거움을 발견하게 될지도 모릅니다.
원문 참고: https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/
댓글 쓰기