에이전트가 커질 때 사람은 어떻게 배울까

AI 코딩 에이전트로 일하는 방식에 대해 세 가지 관점을 따라봤어요:

Phillip Su는 IC 역할이 매니지먼트가 된다고 말해요. 에이전트를 오케스트레이션하고, 아키텍처 결정을 만들고, 우선순위를 정해요. 코드를 짜는 게 아니라 결정해요.

Augment의 Intent는 오케스트레이션에 올인하라고 말해요. 스펙 → 에이전트 팀 → 검증. 코드 에디터 없어요. 사람의 일은 의도를 명확하게 쓰고 결과를 검증하는 거.

Kent Beck은 다르게 말해요. 에이전트로 B+ Tree 라이브러리를 만들면서도 코드 품질, 복잡도, 테스트 커버리지에 계속 신경 써요. “코드를 거의 타이핑하지는 않지만” — 코드 자체는 끝까지 책임진다는 관점이죠. 매니저나 오케스트레이터가 아니라, AI 보조를 받는 프로그래머에 가까워요.

여기 핵심: 다 맞아요, 그리고 각각 다른 걸 최적화하고 있어요.

각자 뭘 최적화하고 있나

Beck은 코드 품질을 최우선으로 둬요. 에이전트를 자기 기준으로 유도하고, 리뷰하고, 리팩토링하면서 복잡도를 계속 눌러요. AI는 타이핑을 줄여주는 도구지, 결정권자가 아니에요.

Intent는 처리량을 최우선으로 둬요. 스펙 → 오케스트레이션 → 검증 루프. “품질”은 코드의 우아함보다는 스펙을 만족하고 검증을 통과하는지에 더 가까워요.

Su는 전략적 임팩트를 최우선으로 둬요. 사람 시간이 병목이니까, 구현 대신 우선순위와 아키텍처 같은 큰 결정을 하는 데 시간을 써요.

문제는 이걸 잘못 적용하면 바로 티가 난다는 거예요. Beck 방식은 100개 병렬 작업에선 유지가 안 되고, Intent 방식은 단일 라이브러리엔 과하고, Su 방식은 까다로운 알고리즘에서 촉을 잃기 쉬워요.

그래서 질문은 “누가 맞아?”가 아니라 “난 뭘 최적화하고 있지?”예요.

그리고 세 관점 아래에 깔린 더 깊은 문제가 있어요: 학습.

학습의 붕괴

직접 코드를 쓸 때는 학습이 수동적으로 일어나요:

  • 버그를 만나고 언어 의미론을 이해
  • 리팩토링하고 패턴 인식 발달
  • 설계하고 시스템 사고 내재화
  • 디버깅하면서 복잡성이 어떻게 복리처럼 불어나는지 체감

이 모두가 우연한 배움이에요. 일의 부산물.

에이전트랑 일하면 세 가지 접근이 모두 부분을 없애요:

  • Beck의 방식은 일부 우연한 배움을 유지 (코드 리뷰, 리팩토링)하지만 구현 세부사항 손실
  • Intent의 방식은 의사결정 배움을 유지하지만 모든 코드 수준 직관 손실
  • Su의 방식은 고수준 배움을 유지하지만 아키텍처 아래 모든 것 손실

에이전트가 더 똑똑해지면 — 그리고 될 거예요 — 이게 악화돼요. 더 똑똑한 에이전트는 더 적은 안내가 필요해요. 더 적은 안내는 코드 리뷰 감소. 코드 리뷰 감소는 우연한 배움 감소.

결국 한 문장 스펙을 써요. 에이전트가 시스템 통째로 만들어요. 전략 결정 내려요. 코드는 본 적 없어요. 행동 검증해요. 어떻게 동작하는지는 이해 못해요.

불편한 진실: 이제 학습을 의도적으로 설계해야 해요. 우연히 일어나지 않아요.

의도적으로 배우려면

에이전트가 커질수록, 날카로움을 유지하려면 계획이 필요해요. 현실적으로 효과 있는 것들만 추리면:

  1. 코드 리뷰를 연습으로 삼기 선택사항이라도 diff를 읽고, 한 번 리팩토링하고, 기준을 유지해요. 코드가 꼭 광택이 필요하지 않아도, 내가 연습할 필요가 있어요.

  2. 가끔은 ‘노-에이전트’ 스파이크 하기 분기마다 작은 걸 직접 만들어봐요. 배포하려는 게 아니라 감각을 다시 맞추는 용도예요.

  3. 결정을 측정으로 바꾸기 “배움은 어디로 갔을까?”에서 말했던 것처럼, 가설을 쓰고(“비용 40%↓”, “신선도 10배↑”), 계측하고, 변화량에서 배워요.

  4. 가르치기 다른 사람이 구현할 수 있는 디자인 문서를 쓰거나, 시스템을 설명하는 순간 사고가 정리돼요.

  5. 남의 ‘의도’를 읽기 오케스트레이션이 표준이 되면 스펙이 1급 산출물이 돼요. 예전엔 코드를 읽었다면, 앞으로는 스펙을 읽는 거죠.

정직한 버전

많은 사람은 이 중 아무것도 안 할 거예요. 게을러서가 아니라, 그냥 기본 경로가 너무 효율적이라서요.

속도만 최적화하면 에이전트가 95%를 처리해요. 우리는 회의하고, 스펙 쓰고, 대시보드 봐요. 그러다 어느 날 “에이전트 없으면 나 혼자 못 만들겠는데?”라는 감각이 슬쩍 올라와요.

이게 완전히 새롭진 않아요. 선임 엔지니어가 수십 년 동안 밟아온 경로랑 비슷해요. 다만 속도가 달라졌죠. 10년이 아니라 2년.

날카로운 사람들은 의도적으로 선택한 사람들이에요. “코드 리뷰에 20% 시간 쓸 거야”, “이번 분기는 노-에이전트로 한번 해볼 거야”, “이 아키텍처 결정은 끝까지 파볼 거야” 같은 식으로요.

지금은 선택이에요. 우연이 아니에요.

당신한테 뭘 의미하는지

지금 당신의 미래를 고르고 있어요.

매니저가 되고 싶으면 — Su의 모델에 집중해요. 코드 쓰기 멈춰. 큰 결정에 집중. 모든 거 위임. 1년 뒤에 대규모에서 중요한 거 유창하게 이해할 거예요.

오케스트레이터가 되고 싶으면 — Intent 모델 배워요. 스펙 문해력 쌓아. 검증을 깊이 있게 이해. 에이전트가 실행할 수 있는 의도 쓰기 전문가.

프로그래머로 남고 싶으면 — Beck의 경로 고르고. 가끔 코드 써. 에이전트 코드 항상 리뷰. 기준에 완벽주의. 1년 뒤에 10배 빨리 배포하는 대부분보다 코드를 더 이해할 거예요.

제 생각엔 대부분은 Su/Intent 쪽으로 자연스럽게 흘러갈 거예요. 산출물이 복리로 쌓이니까요. 반대로 “코드에 가까이 붙어 있기”는 점점 더 의식적인(그리고 약간은 역행하는) 선택이 될 가능성이 커요.

셋 다 유효해요. 하지만 어떤 것도 자동으로 따라오진 않아요. 고르셔야 해요.

솔직한 대화가 안 되고 있어요: 에이전트가 똑똑해지면서 배움이 의도를 필요로 해요. Su, Intent, Beck은 모두 당신이 알아서 할 거라고 가정하죠. 근데 많은 사람은 처리량 최적화에 쏠렸다가, 나중에야 감각이 무뎌진 걸 알아차릴 거예요.

지금 에이전트로 만들고 있으면 미래를 고르고 있어요. 의도적으로 하세요.

AI 에이전트로 만드는 시리즈 마무리: 배움은 어디로 갔을까, Intent와 IDE, 사이트를 에이전트 친화적으로, 사람의 역할. 질문은 어떤 접근이 맞는지가 아니라 어떤 최적화 함수를 고르는지 — 그리고 날카로움을 유지하려고 뭘 포기할 준비가 됐는지예요.