“도구를 끄면 실력이 드러난다.
더 정확히는, 어디에 시간을 버리고 있었는지가 드러난다.”

생산성이 어디에서 생기는지를 정리하고,
Cursor를 작업 운영체제처럼 쓰는 법까지 썼는데도 한 가지가 남았다.

에이전트를 켠 날만 보면 착시가 생긴다.
빨라진 이유를 도구에만 돌리기 쉽기 때문이다.

그래서 가끔 에이전트 없는 날을 둔다.
금욕이 아니다. 어디가 진짜 병목인지 확인하려는, 하루짜리 실험이다.

TL;DR

  • 같은 날, 같은 작업을 오전(수동) / 오후(에이전트) 로 나눠 비교한다.
  • 체감 차이는 대개 구현이 아니라 탐색·검증·전환에서 난다.
  • 다음 날 3줄만 정리하면, 도구를 꺼도 켜도 레버 위치가 선명해진다.

실험 규칙 (하루짜리)

같은 종류의 일을, 하루 안에서 두 덩어리로 나눈다.

구간 조건 기록
오전 ~3시간 검색·구현·리뷰 초안까지 수동 탐색 시간, 편집 횟수, 피로도(1~5)
오후 ~3시간 동일 작업, 에이전트 허용 위와 동일

숫자를 논문처럼 맞출 필요는 없다.
체감 차이가 어디서 났는지 한 줄로 남기는 게 목적이다.

실제로 보이는 차이

1) 구현 속도보다 탐색 속도

수동일 때 제일 오래 걸리는 건 타이핑이 아니라 어디부터 열지 결정하는 시간이다.
에이전트를 켰을 때 줄어든 것도, 대개 “코드 작성”보다 경로 찾기 쪽이었다.

2) 품질 차이는 초안이 아니라 검증 루틴

수동이든 에이전트든 틀린 초안은 나온다.
차이는 틀린 초안을 몇 번 만에 버리느냐였다.
문제를 먼저 정의하는 습관이 없으면, 빠를수록 같은 초안을 더 오래 끌고 간다.

3) 피로도의 핵심은 컨텍스트 전환

같은 6시간이어도 탭·파일·채팅을 왕복하면 피곤하다.
에이전트가 줄여 준 건 손가락 노동보다 머리의 전환 횟수에 가깝다.

실험 다음 날에만 하는 정리 (3줄)

  1. 탐색이 길었으면 → 다음엔 질문을 더 행동 단위로 쪼갠다.
  2. 수정이 많았으면 → 에이전트에게 던지기 전에 금지/필수를 먼저 적는다.
  3. 리뷰가 길었으면 → PR 본문에 의도·비목표를 넣는다 (횡단 PR·주니어 PR 3단락과 같은 층).

이 셋은 에이전트를 꺼도, 켜도, 둘 다 도움이 된다.

오해하지 않으려면

  • “에이전트 없이도 되네” ≠ 도구가 쓸모없다.
  • “에이전트가 더 빠르네” ≠ 사람이 안 봐도 된다 — 검증 없는 신뢰와 같은 함정이다.

실험의 목적은 승부가 아니라 작동 원리 파악이다.
가속만 알면, 언제 브레이크를 밟아야 하는지 모른다.

마치며

생산성은 도구의 유무보다 레버를 잡는 위치에서 갈린다.
에이전트 없는 날을 가끔 두면, 그 위치가 선명해진다.

처음 해볼 때는 하루 종일 끄지 않아도 된다.
오전만 수동으로 두고 로그 한 줄만 남겨도 충분하다.

한 줄 결: 에이전트는 가속기이고, 실험은 조향장치다. 둘이 같이 있어야 같은 속도로 덜 틀린다.