AI로 코드를 더 빨리 쓰지 말고, 더 잘 쓰는 법

AI 코딩, 속도가 전부가 아니더라

요즘 개발자 커뮤니티에서 가장 뜨거운 주제 중 하나가 "AI로 코딩하면 얼마나 빨라지는가"잖아요. Cursor, Claude Code, Copilot 같은 도구들이 등장하면서 "이제는 AI한테 시키고 사람은 검토만 하면 된다"는 분위기가 만들어지고 있거든요. 그런데 Nolan Lawson이라는 개발자(Salesforce에서 일하는 베테랑이고, Mastodon 클라이언트 Pinafore의 메인테이너로도 유명한 분이에요)가 최근에 흥미로운 글을 하나 올렸어요. 제목부터가 도발적입니다. "AI를 써서 코드를 더 천천히, 그러나 더 잘 쓰는 법"이라고요.

이 글이 주목할 만한 이유는, 보통 AI 코딩 도구를 다루는 글들이 "이렇게 하면 10배 빨라진다" 같은 생산성 자랑 일색이었거든요. 그런데 Lawson은 정반대 이야기를 합니다. AI를 쓰면서 오히려 의도적으로 속도를 늦췄더니, 결과적으로 더 좋은 코드를 쓰게 됐다는 거예요.

어떻게 천천히 쓴다는 걸까

Lawson이 말하는 핵심은 이거예요. AI가 코드를 뱉어내면 그걸 그대로 받아들이지 말고, 한 줄 한 줄 따져보라는 거죠. 그런데 이게 말처럼 쉽지 않거든요. AI가 그럴듯한 코드를 100줄 짜주면, 사람 마음이라는 게 "오, 됐다" 하고 그냥 붙여넣고 싶어지잖아요. 특히 시간에 쫓길 때는 더 그렇고요.

Lawson이 제안하는 방법은 이런 것들이에요. 먼저 AI에게 한 번에 큰 덩어리를 시키지 말고, 작은 단위로 쪼개서 시키라는 거예요. "이 기능 전체를 구현해줘" 대신 "이 함수 하나만 짜줘"라고 하는 거죠. 그러면 결과물도 작아지니까 검토하기가 쉬워져요.

그리고 AI가 짜준 코드를 일단 자기 손으로 다시 타이핑해보는 것도 추천해요. 복사-붙여넣기로 끝내면 머리에 안 남는데, 직접 쳐보면 "어, 이 부분은 왜 이렇게 했지?" 하는 의문이 자연스럽게 떠오른다는 거죠. 마치 외국어 책을 그냥 읽는 거랑 직접 베껴 쓰는 거랑 학습 효과가 다른 것처럼요.

또 하나 중요한 게 AI한테 "왜 이렇게 짰는지" 물어보는 습관이에요. AI는 가끔 멋있어 보이는 패턴을 쓰는데, 사실 그 프로젝트 맥락에서는 오버엔지니어링인 경우가 많거든요. "이거 더 간단하게 못해?"라고 한 번 더 묻기만 해도 결과물이 확 달라진다고 해요.

왜 빠른 게 항상 좋은 게 아닐까

사실 이 글이 던지는 더 깊은 질문은 "개발자의 일이 뭐냐"는 거예요. 코드를 타이핑하는 행위 자체가 일의 본질이 아니라, 그 코드가 무엇을 하는지 이해하고 책임지는 것이 본질이거든요. AI가 아무리 빠르게 코드를 생성해도, 그 코드를 배포한 다음 새벽 3시에 알람이 울리면 결국 사람이 디버깅해야 하잖아요.

Lawson은 실제로 자기 경험을 들려주는데요. AI가 짜준 코드를 빨리 머지했다가 나중에 문제가 터졌을 때, 자기가 그 코드를 충분히 이해하지 못해서 디버깅에 두 배 더 시간이 걸렸다는 거예요. 결국 "빨리 짠 코드 + 느리게 고친 시간"이 "천천히 짜고 안 고쳐도 되는 시간"보다 더 길어졌다는 거죠. 이건 사실 AI 이전부터 있던 진리이긴 해요. 다만 AI가 이 함정을 더 교묘하게 만들었다는 게 포인트입니다.

다른 시각들과 비교해보면

비슷한 맥락에서 최근 METR라는 연구 기관에서 실험한 결과가 있어요. 숙련된 오픈소스 개발자들이 AI 도구를 쓸 때 자기 체감으로는 20% 빨라졌다고 느꼈는데, 실제로 측정해보니 오히려 19% 더 느렸다는 결과가 나왔거든요. 이게 왜 그러냐면, AI가 제안하는 코드를 검토하고 수정하는 시간이 생각보다 많이 들기 때문이에요.

반면 Anthropic이나 Cursor 쪽에서는 "에이전트 모드"를 밀고 있어요. AI가 알아서 파일 여러 개 수정하고, 테스트 돌리고, 디버깅까지 하는 흐름이죠. 두 진영의 철학이 정반대인데, Lawson의 글은 전자에 가깝다고 볼 수 있어요. "AI는 도구일 뿐, 운전대는 사람이 잡아야 한다"는 입장이거든요.

한국 개발자 입장에서 생각해볼 점

한국 개발 환경에서도 요즘 AI 코딩 도입이 정말 빠르잖아요. 스타트업은 물론이고 대기업에서도 Copilot 라이선스를 단체로 구매하는 분위기고요. 그런데 현장에서 들리는 이야기들을 보면, 주니어 개발자들이 AI에 너무 의존해서 기본기가 약해진다는 우려도 자주 나와요.

Lawson의 접근은 특히 주니어 분들에게 시사하는 바가 큰 것 같아요. AI를 안 쓸 수는 없지만, "AI가 짜준 코드를 내가 처음부터 짠다고 가정했을 때 설명할 수 있는가?"라는 기준을 가지고 쓰면 좋겠다는 거죠. 코드 리뷰에서 "이 부분 왜 이렇게 했어요?"라고 물었을 때 "AI가 그렇게 해줬는데요"라고 답하면 안 되잖아요.

실무에서 당장 적용해볼 만한 건, PR 단위를 작게 가져가는 것이에요. AI로 빠르게 짤 수 있다고 한 PR에 1000줄씩 욱여넣지 말고, 100줄 단위로 쪼개서 자기도 리뷰어도 검토할 수 있게 만드는 거죠. 그리고 커밋 메시지에 "왜"를 꼭 적는 습관도 중요해요. AI가 코드는 짜줘도 의도까지 적어주진 않거든요.

정리하며

결국 이 글의 메시지는 단순해요. AI는 타자기가 아니라 사고 도구로 써야 한다는 거. 빠르게 코드를 뽑아내는 기계로 쓰면 단기적으로 신나지만, 장기적으로는 코드 품질도 본인 실력도 같이 떨어진다는 경고죠.

여러분은 어떠세요? AI 코딩 도구를 쓰면서 "내가 이 코드를 진짜 이해하고 있나?" 하는 불안함을 느낀 적 있으신가요? 아니면 반대로 AI 덕분에 오히려 더 깊이 공부하게 됐다는 경험도 있을까요? 각자의 작업 방식이 궁금해집니다.