25년간 C를 써 온 개발자가 Claude Code의 Opus 4.5 같은 AI 코드 에이전트를 실제 코드베이스에서 시험해 보고, 시간 절약 효과와 한계, 활용 요령을 정리한다.
URL: https://danielchasehooper.com/posts/code-agents/
나는 25년 동안 C로 프로그래밍을 해 왔고, 아직까지는 AI가 프로그래밍에 유용하다고 느낀 적이 없다. 나는 그동안의 과대광고를 “경험 없는 글루 코더들”의 소란 정도로 치부해 왔다. 그렇다고 내가 러다이트(기술 혐오자)는 아니다. 나는 LLM을 구글 대체재로는 쓴다. Cursor에서 AI 자동완성도 써 봤다. 하지만 매번 자동완성 제안을 읽느라 흐름이 끊기는 게 짜증났다.
그런데 최근 “AI 코드 에이전트”(Opus 4.5, 그리고 gpt-5.2-codex high)라는 새로운 세대가 등장했고, 이건 시험해 볼 만해 보였다.
모델 개선 외에도, 코드 에이전트는 기존의 AI-for-code 방식 대비 3가지 장점이 있다.
그래서 나는 Claude Code를 설치하고, Opus 4.5로 전환한 뒤 실험을 시작했다…
나는 Claude Code CLI 도구를 사용했고, Claude가 생성해 준 CLAUDE.md 외에는 어떤 커스터마이징도 하지 않았다. 비밀 프롬프트 엔지니어링 주술 같은 건 없다. 각 작업마다 나는 이렇게 했다.
내가 발견한 것은, 에이전트가 만든 코드를 내 기준에 맞게 리뷰하고 편집한 뒤에도 AI 보조가 대체로 직접 하는 것보다 순시간 기준으로 이득이었다는 점이다. 어떤 작업은 UTF-16 문자열 타입을 만들고, UTF-16↔UTF-8 변환을 작성하고, 기존 문자열 사용처 전체를 감사(audit)하고, 영향을 받는 다른 타입들을 재정리하는 것이었다. 내가 직접 하면 4시간이 걸렸다. AI 보조를 쓰면: 30분. 단순하지만 지루한 일—AI에 이상적인 시나리오였다.
실험 밖에서도, 에이전트가 일을 잘못하더라도 그 변경 사항을 읽는 것만으로 문제를 내 머리에 로드하는 지름길이 되어, 결국 내가 직접 작업하는 데 도움이 된다고 느꼈다.
AI에 대해 어떻게 생각하든, 이 실험을 직접 해 보길 권한다.
이번 세대의 에이전트가 이미 초보 프로그래머보다는 낫긴 하지만, 훌륭한 프로그래머보다는 확실히 못하다. 실수는 코드 구조를 엉망으로 짜는 것부터, O(n)으로 가능할 뿐 아니라 더 단순하기까지 한 문제에 대해 끔찍하게 느린 O(n²) 알고리즘을 쓰는 것까지 다양하다.
그렇다고 완벽해야만 유용한 건 아니다. 이건 인턴이나 변호사의 패러리걸(paralegal)처럼 다루는 게 가장 좋다. 큰 그림의 계획은 당신이 세우고, 구체적인 지시를 주면, 에이전트가 백그라운드에서 잡일을 처리하고, 당신이 리뷰하고 조금 손본 뒤 커밋한다.
자유롭게 맡겨 두면 최고의 코드를 쓰지는 못하지만, 피드백 처리는 잘한다. 나는 그 O(n²) 알고리즘을 선형 시간으로 바꾸라고 했고, 실제로 그렇게 했다. 코드가 어떻게 개선될 수 있는지 알기 위해서는 당신이 이미 좋은 프로그래머여야 한다. 나는 피드백을 한 번 주고도 기대에 못 미치면 손절하고 직접 고친다. 방향 제시를 잘하게 되고, 어떤 일을 맡길 수 있는지 배우면서 수정이 필요한 횟수도 줄었다.
분석에 유용하다. 많은 버그에서 시간이 많이 드는 부분은 수정 코드를 쓰는 게 아니라, 무엇이 잘못됐는지 알아내는 것이다. 예를 들어, 나는 15만 개 이상 아이템을 set에 추가하면 앱이 몇 초씩 멈추는 버그가 하나 있었다. (오픈 어드레싱으로 구현된) set에서 삽입당 평균 probe 수가 엄청나게 컸기 때문에, 값싼 xor 해시가 충돌을 유발하는 거라고 생각했다. 다른 해시 알고리즘도 시도해 봤지만 도움이 안 됐다. 혹시나 하는 마음에 Claude에게 나와 병렬로 조사해 달라고 했다. Claude는 내 추측에 동의했다. xor 해시 함수가 이 데이터에서 퇴화(degenerate)하는 실패 케이스가 있었다. 하지만 더 중요한 건, set이 리사이즈하기 전에 100%까지 차는 것을 허용하도록 최근 변경된 점을 찾아냈다는 것이다. 그 때문에 결국 15만 개 항목에 대한 선형 검색으로 붕괴해 버렸다. 나는 작은 수정만 직접 했고, 멈춤 현상은 사라졌다.
미루는 습관을 넘는 데 도움이 됐다. 계속 미뤄 둔 작업을 에이전트에게 시키면 시작하기가 훨씬 쉬워졌다. 최선의 경우: 작업을 끝내 준다. 최악의 경우: 정신적 고비를 넘게 해 준다. 나는 크로스 컴파일을 위한 리눅스 sysroot를 만들어야 했을 때 이걸 경험했다. 에이전트가 헤더와 정적 라이브러리를 찾아 다운로드했다.
내가 다른 일을 하는 동안 백그라운드에서 하나 이상의 에이전트를 돌리는 것은 초능력처럼 느껴진다. 이 배치는 내가 가장 잘하는 일에 집중하면서도 하루에 더 많은 성과를 내게 해 준다. 로컬에서 이를 시도하려면 에이전트 인스턴스마다 프로젝트 폴더를 복사해 두고, 각 인스턴스가 자기 브랜치로 푸시하게 하면 된다. 또는 웹 버전 에이전트를 써서 Github 저장소에 연결된 리눅스 VM에서 작업하게 할 수도 있다. 이 접근의 장점 중 하나는, 셸 명령을 실행할 때마다 당신의 허락을 구할 필요가 없다는 점이다.
내 경험을 다른 사람들과 공유했을 때 나왔던 감정들을 다뤄 보겠다.
“AI가 코드를 쓰면 나는 내 코드베이스를 이해하지 못하게 될 거야.”
첫째, AI가 하는 일을 전부 리뷰해야 한다.
둘째, 어떻게 사용할지는 당신이 결정한다. 그러니 “이 기능 전체 구현해 줘, 고마워 바이” 같은 프롬프트 대신 “사용자 배열 조회를 해시맵으로 교체하고 모든 사용 지점을 업데이트해” 같은 식으로 하라. AI로 뇌를 대체하지 말고, 키보드를 대체하라.
나는 개인적으로 내가 직접 할 줄 모르는 일을 시키지 않는다. 낯선 영역에서는 연구 보조처럼 쓴다. “선택지는 뭐가 있지?” “트레이드오프는?” “그 접근을 처음 소개한 논문 링크 줘” 같은 식으로.
“하지만 나는 프로그래밍이 좋아. AI 매니저가 되고 싶지 않아.”
에디터에 코드를 타이핑하는 건 프로그래밍에서 가장 흥미 없는 부분이다. AI 보조는 당신이 흥미로운 부분—데이터와 로직 설계, 기능 기획, 최적화—에 집중하도록 해 준다. vibecode 괴짜들처럼 기술적 통제권을 포기할 필요도 없다. 당신이 프로그래밍을 좋아하는 이유가 ‘무언가를 만드는 것’이라면, AI는 더 많이 만들게 도와줄 수 있다.
“그렇게 생산적이라면 AI로 만든 제품들은 다 어디 있어?”
누구나 “AI가 만들었음”을 광고하고 싶어 하진 않지만, 이미 AI로 작성된 것들이 있다. 그리고 “제품이 더 많아지는 것”만이 생산성 향상을 실현하는 유일한 방식은 아니다. AI가 있는 작은 팀이 AI 없는 큰 팀과 같은 양을 해낼 수도 있다. 또는 고정된 릴리스 주기 안에 더 많은 기능을 개발할 수도 있다. 전반적으로 이것은 생산성 향상 주장에 대한 반박으로는 약하다.
현 세대 모델은 강력하지만 분별력이 부족하다. 가장 큰 강점이자 가장 큰 약점은 동일하다. 즉, 시키는 대로 한다. 이들은 C, 알고리즘, 그리고 당신의 기존 코드에 대해 충분히 이해하고 있어서, 명확히 지시하면 유용할 수 있다. 완벽하진 않지만, 이제 코드 에이전트는 내 도구상자의 일부가 될 것 같다.
이 글의 예시는 내가 작업 중인 빌드 비주얼라이저에서 나왔다.
나는 C에서 제네릭 자료구조를 작성하는 법도 썼다.
내가 가장 인기 있는 글은 “릭 앤 모티로 셰이더 프로그래밍 배우기”다.
다음 글 알림 받기:
