나만 이런 건가?

나는 게임 개발, 주로 그래픽, 물리, 엔진 프로그래밍 분야에서 15년 경력을 쌓은 소프트웨어 엔지니어다. 업무를 할 때 대부분의 경우 어떤 방식으로든 AI를 사용한다. 내 AI 사용 패턴은 주로 정보 검색, 짧은 브레인스토밍, AI와 대화하며 생각 정리하기(rubber-ducking, 결과물을 자세히 읽지는 않음), 가끔 AI를 통한 코드 리뷰로 문제 포착하기, 그리고 당장 필요한 작고 일회성인 도구 만들기 등이다. 따라서 나를 에이전트형 코더라고 부를 수는 없고, 그렇다고 '바이브 코더(vibe coder)'라고 할 수도 없지만, AI 경험이 전혀 없다고 말하는 건 불공평할 것이다.

최근 코딩을 전혀 모르는 내 아내가 Claude Code를 사용해 자신의 필요에 맞는 작은 파이썬 앱을 만들기로 했다. 자세한 내용은 생략하겠지만, 그 앱은 기본적으로 UI가 거의 없는 데이터 처리 기계라서 결과만 보고는 제대로 작동하는지 확인하기가 매우 어렵다.

처음에는 아내가 작업 속도와 Claude의 도움에 정말 신나 했지만, 얼마 지나지 않아 여기저기서 뭔가 잘못되었다는 걸 알아차리기 시작했다. 문제를 파고들어 하나를 고치면 다른 문제가 튀어나왔다. 결국 핵심 로직이 완전히 잘못되었다는 걸 발견했다.

우리는 '아내가 비개발자라서 경험 부족으로 도구를 제대로 못 다루는 것일 뿐'이라고 생각했다. 그래서 내가 직접 이 에이전트형 코딩을 시도해 보고 이 도구들이 얼마나 좋은지 확인해 보기로 했다.

내 계획은 간단했다. 아내의 프로젝트에서 얻은 유용한 발견들을 잘 정리해서 다음에 내가 사용할 형태로 만드는 것이었다. 나는 이 프로젝트를 처음부터 다시 구현하기 위해 아키텍처 문서와 프롬프트를 작성하며 이틀 정도를 연구에 썼다. 원하는 아키텍처, 요구 사항, 구조, 결과물을 꼼꼼하게 설명했고, 내가 아는 모든 예외 케이스까지 적어두었다.

기대는 꽤 컸다. 금방 작동하게 만들 수 있을 거라 생각했다. 만약 이 문서를 주니어 개발자에게 줬다면, 최고는 아니더라도 작동하는 프로젝트를 만들어 왔을 것이다.

모든 준비를 마치고 새로운 세션을 시작했을 때, 진행 속도가 빨라서 만족스러웠다. 하지만 초기 단계가 끝나고 코드를 검토해 보니, 신입 주니어조차 하지 않을 법한 일들이 많았다. 코드 전체에서 동일해야 할 상수들이 여기저기 흩어져 있었는데, 내 문서에는 그런 것들에 대해 단일 진실 공급원(source of truth)이 하나만 있어야 한다고 명시했음에도 그랬다. 시뮬레이션 경로와 실제 작동 코드 경로(과거 데이터를 사용해 재시뮬레이션하는 모드와 실시간으로 작동하는 모드, 이렇게 두 가지 모드가 있음)는 기본적으로 서로 복제본이었다. 최악은 그 복제본들이 정확히 일치하지도 않았다는 점이다. 다시 말하지만, 나는 문서에 그것들이 최대한 비슷해야 하며 같은 추상화를 사용해야 한다고 분명히 적었다.

처음 든 생각은 '내가 뭔가 잘못하고 있는 거겠지, 하지만 고칠 수 있어'였다. 그러고 나서 고통과 수정의 굴레가 시작되었다. 프로젝트가 엄청나게 큰 건 아니었지만, 사람들이 많이 홍보하는 '코드를 직접 작성하지 않는' 방식을 시도해 보고 싶었다. 이 방식의 문제는 기계를 믿고 코드를 거의 검토하지 않거나, 아니면 검토하느라 시간을 다 써서 애초에 직접 코딩하는 것보다 더 많은 시간이 걸린다는 것이다. 물론 직접 짠 코드도 검토해야 하지만, 직접 짠 코드를 검토하는 게 훨씬 쉬운 작업이라는 건 다들 동의할 것이다.

내 접근 방식은 간단했다. 핵심이 작동하는지 확인한 다음 기능을 확장해 나가고 싶었다. 코드를 거의 작성하지 않고 Claude에게 이것저것 구현 방법을 물어보고 수정하도록 유도했음에도 불구하고, 정말 지치고 힘들었다. 시스템이 어디가 맞고 어디가 구현 실수인지 알 수가 없었다. 핵심 부분이라 제대로 된 테스트를 할 수도 없었다. 나는 그냥 앉아서 아무것도 안 하면서, 이 경험이 얼마나 사람을 말려 죽이는지 느꼈다.