10개 에이전트를 동시에 돌리고, 수백 줄짜리 PR을 쏟아내고, AI가 써준 글을 그대로 올린다. 지금 많은 개발자들이 “AI를 잘 쓴다”고 믿으며 하는 행동들입니다. 그런데 실제로 해본 사람들의 이야기는 조금 달랐습니다.

최근 두 명의 개발자가 각자의 경험에서 출발해 비슷한 결론에 닿았습니다. AI를 더 잘 쓰려면, 오히려 더 천천히, 더 의식적으로 써야 한다는 것입니다.

출처:

• Don’t let AI burn you out – kukicola.io
• Using AI to write better code more slowly – Read the Tea Leaves

에이전트를 많이 돌릴수록 번아웃에 가까워진다

개발자 Karol Bąk은 AI 에이전트를 여러 개 동시에 돌리다 번아웃 직전까지 갔던 경험을 공유했습니다. “X에서 전문가들이 10개 세션을 동시에 돌리지 않으면 뒤처진다고 말한다”는 압박이 문제의 시작이었습니다. 결과는 예상과 달랐습니다. 더 바빠졌지만 코드 품질은 떨어졌고, 이해하지 못한 코드를 리뷰하는 상황이 반복됐습니다.

그가 찾은 해법은 단순했습니다. 에이전트 하나를 처음부터 끝까지 혼자 돌릴 수 있게 만드는 것이 먼저입니다. 에이전트가 실수할 때마다 그 실수를 막는 규칙을 추가하는 방식으로 신뢰도를 쌓고, 그다음에야 세션 수를 하나씩 늘립니다. 알림은 모두 끕니다. 긴급 상황이 아닌 이상 에이전트가 완료 신호를 보내도 즉시 반응하지 않습니다. AI가 만들어내는 비동기 작업을 다시 동기 작업처럼 처리하는 순간, 집중력은 무너집니다.

느리게 쓰는 것이 더 좋은 코드를 만든다

개발자 Nolan Lawson은 LLM을 다르게 활용합니다. 빠른 코드 생산 대신, 여러 AI 모델을 동시에 PR 리뷰어로 투입해 버그를 찾아내는 방식입니다. Claude 서브에이전트, Codex, Cursor Bugbot 세 모델이 같은 PR을 각각 검토한 뒤, 발견한 버그를 심각도 순으로 분류하고 교차 검증해 오탐을 줄입니다.

이 방식을 쓰면 속도는 오히려 느려집니다. 버그를 고치다 보면 PR과 무관한 기존 코드의 결함이 발견되고, 거기서 또 단위 테스트를 작성하는 우회로로 빠집니다. 그가 말하는 “10배 생산성”과는 거리가 멉니다. 하지만 코드베이스의 건강은 꾸준히 좋아지고, 시스템의 실패 지점을 이해하는 깊이도 쌓입니다. AI를 슬롭 캐논처럼 쓰는 것과, 꼼꼼한 검토 파트너로 쓰는 것의 차이입니다.

속도보다 의도가 먼저다

두 사람의 이야기는 서로 다른 문제에서 출발했지만 같은 지점을 향합니다. AI를 잘 쓴다는 것은 많이 쓰고, 빠르게 쓰는 것이 아닙니다. Karol은 에이전트 수를 조절하며 통제력을 되찾았고, Nolan은 속도를 포기하며 코드 품질을 얻었습니다. 방향은 달랐지만 둘 다 먼저 느려졌습니다.