이 글은 Claude Opus 4.6 을 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Dave Thomas, Pragmatic Programmers Newsletter — “Failing Faster With AI”

“모든 거대한 컴퓨팅 재앙은 너무 많은 아이디어를 한곳에 집어넣으려다 생겨났습니다.”

— Gordon Bell

지난 8년쯤 개인 프로젝트를 하나 진행해 왔습니다. 1970년대 중반의 오래된 PIC 언어를 구현하는 것으로 시작했습니다. 셀 수 없이 많은 반복을 거쳤는데, 순수한 PIC 언어로 출발해서 오늘날에는 프로토타입 기반 스크립팅 언어와 애니메이션 기능을 내장한 형태가 되었습니다.

저는 항상 직접 손으로 코드를 작성해 왔습니다. 처음에는 그게 프로그래밍하는 방법이었기 때문이고, 최근에는 이런 개인 프로젝트야말로 직접 만지는 정성이 필요하다고 느꼈기 때문입니다.

그런데 몇 주 전, 한 변형에서는 언어 기능을, 다른 변형에서는 애니메이션 아이디어를 가져와 합치고 싶어졌고, Claude에게 계획을 세워달라고 부탁해 보았습니다. Claude가 딱 맞는 답을 내놓았습니다. 한 시간 만에 모든 테스트가 통과했고, 저는 미친 듯이 애니메이션을 스크립팅하고 있었습니다.

그래서 유혹에 굴복했습니다. 이봐 Claude, oklch 색상 지원을 추가해줄 수 있어? SVG 대시 길이 트릭을 이용한 선 애니메이션을 구현해줄래? 그렇게 기능 위에 기능이 쌓여갔습니다.

superpowers 스킬을 사용하고 있었는데, 프로젝트 규율을 유지하는 데 꽤 괜찮은 역할을 하는 것 같았습니다. 일주일 동안은 새로운 기능이 쏟아져 나오는 속도에 취해 있었습니다.

부패의 시작#

둘째 주에 접어들자, 기능 추가에 점점 더 오래 걸리기 시작했습니다. 변경 사항이 회귀 버그를 일으키고, A가 B를 깨뜨리고 B가 다시 A를 깨뜨리는 루프에 빠지기도 했습니다. 상황이 걷잡을 수 없어지는 느낌이었습니다.

저는 그냥 쏘고 잊어버리는 식의 바이브 코딩을 한 게 아닙니다. 변경 사항을 검토하고 방향을 잡아가면서 진행했습니다. 그런데도 코드가 제가 허용했어야 할 수준보다 더 지저분해지고 말았습니다. 기능 추가를 멈추고 리팩터링을 시작할 때가 된 것입니다.

새로운 것은 오래된 것#

코드를 읽어보니 온갖 끔찍한 것들이 눈에 들어왔습니다. 대량의 중복. 전역 문제에 대한 국소적 수정. 지나치게 많은 조건문. 그리고 특수 케이스. 수많은 특수 케이스.

문득 깨달은 것이 있었습니다. 수년간 이런 모습의 코드를 자주 만나왔습니다. 컨설팅을 할 때면 거의 모든 코드베이스가 이런 상태였습니다. 팀들은 어김없이 “재작성"을 이야기했습니다.

하지만 예전에는 그 지경에 이르기까지 18개월, 혹은 그 이상이 걸렸습니다.

AI와 함께라면, 5일 저녁 동안 총 18시간이면 충분했습니다.

이것이야말로 진보입니다.

여전히 프로그래밍일 뿐#

코드를 깨끗하게 유지하려면 규율이 필요합니다. 기능과 위생 사이에서 균형을 잡아야 합니다. 코드는 자연스럽게 퇴화합니다. 그것을 막으려면 의식적인 노력을 기울여야 합니다.

그런데 LLM 뒤의 프롬프트는 그런 지루한 일에 초점을 맞추지 않습니다. 대신 여러분의 참여와 만족을 유지하도록 설계되어 있습니다. “멋진 아이디어네요, Dave!”

AI는 해결책을 제시하기 좋아합니다. 사소한 성공 하나하나에 “이제 X를 구현해볼까요?” 라고 덧붙입니다. 그런 면에서 AI는 강아지 같은 주니어 개발자와 비슷합니다. 기꺼이 일하려고 하지만, 주변을 꽤 어질러놓습니다.

기능 추가의 엔도르핀에 취한 저는, 개발에 대해 알고 있던 것들을 잊어버렸습니다. 어쩌면 제 무의식은 그런 것들을 한 1년쯤은 생각하지 않아도 될 거라고 속삭이고 있었는지도 모릅니다.

그렇다면 착각이었습니다. 18시간이 걸리든 18개월이 걸리든, 여전히 프로그래밍일 뿐입니다.

즐기세요…