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

AI 코딩 에이전트로 일하는 방식을 두고 요즘 뚜렷한 관점 세 가지를 유심히 지켜보고 있습니다:

Phillip Su는 IC 역할이 매니지먼트로 전환된다고 말합니다. 에이전트를 오케스트레이션하고, 아키텍처를 결정하고, 우선순위를 정하는 식입니다. 직접 코드를 짜기보다 큰 결정을 내리는 관리자에 가까워집니다.

Augment의 Intent는 오케스트레이션에 올인하라고 합니다. 스펙 → 에이전트 팀 → 검증의 반복입니다. 코드 에디터조차 필요 없다고 봅니다. 사람의 일은 의도를 명확하게 정의하고 결과를 검증하는 데 집중됩니다.

Kent Beck은 결이 다른 이야기를 합니다. 에이전트로 B+ Tree 라이브러리를 만들면서도 코드 품질, 복잡도, 테스트 커버리지를 집요하게 챙깁니다. “코드를 손수 타이핑하지는 않지만, 코드의 만듦새는 끝까지 내가 책임진다”는 관점입니다. 매니저나 오케스트레이터라기보다 AI 보조를 받는 진짜 프로그래머에 가깝습니다.

흥미로운 점은 셋 다 일리가 있고, 각자 최적화하는 목표가 완전히 다르다는 것입니다.

각자 뭘 최적화하고 있나

Beck은 코드 품질을 최우선에 둡니다. 에이전트를 엄격한 자기 기준에 맞춰 유도하고, 꼼꼼히 리뷰하고, 리팩토링하면서 복잡도를 억누릅니다. AI는 타이핑 수고를 덜어주는 보조 도구일 뿐, 코드의 품질 기준은 여전히 사람이 쥐고 있습니다.

Intent는 처리량(Throughput)을 최적화합니다. 스펙 작성, 오케스트레이션, 검증 루프를 빠르게 회전시킵니다. 여기서 말하는 “품질”은 코드가 우아한지보다 스펙을 만족하고 자동 검증을 통과하는지를 봅니다.

Su는 전략적 임팩트를 최우선으로 봅니다. 사람의 집중력이 가장 귀한 병목이니 구현 디테일보다 비즈니스 우선순위와 시스템 아키텍처 같은 고수준의 결정에 시간을 쏟아야 한다는 입장입니다.

문제 유형에 맞지 않는 모델을 억지로 끼워 맞추면 탈이 납니다. Beck의 방식을 100개의 병렬 작업 스트림에 적용하려 들면 바로 병목이 생깁니다. Intent 방식을 단일 정밀 라이브러리에 들이대면 과하고 Su의 고수준 접근법만으로는 까다로운 알고리즘의 세밀한 결을 챙기기 어렵습니다.

그래서 “누가 옳은가”를 따지기보다 “지금 나는 무엇을 최적화하려는가”를 먼저 물어야 합니다.

세 관점의 바닥에는 더 근본적인 고민이 깔려 있습니다. 바로 배움(Learning)의 문제입니다.

학습의 붕괴

직접 손으로 코드를 짤 때는 학습이 자연스럽게 부산물처럼 일어납니다:

버그와 씨름하며 언어의 깊은 동작 원리를 이해하고
리팩토링을 거치며 좋은 구조에 대한 감각을 다듬고
직접 설계하며 시스템 관점의 사고를 체화하고
디버깅을 겪으며 복잡성이 어떻게 복리로 커지는지 체감합니다

이 모두가 일하다 보면 얻어걸리는 우연한 배움이었습니다.

하지만 에이전트와 일하면 세 가지 접근법 모두 이 과정의 일부를 덜어냅니다:

Beck의 방식: 코드 리뷰와 리팩토링을 통해 일부 배움을 지키지만 바닥 구현 디테일의 체감은 줄어듭니다.
Intent의 방식: 의사결정 역량은 훈련되지만 코드 레벨에서 오는 생생한 직관을 잃기 쉽습니다.
Su의 방식: 고수준의 설계 감각은 유지되지만 아키텍처 아래의 실질적인 구현 역량은 비어갑니다.

에이전트가 똑똑해질수록(그리고 분명 그렇게 될 겁니다) 이런 현상은 한층 심해집니다. 에이전트가 유능해지면 사람이 줄 안내가 줄고, 안내가 줄면 코드 리뷰가 생략되며, 코드 리뷰가 줄면 우연한 배움의 기회도 메말라갑니다.

결국 한 줄짜리 스펙만 던지면 에이전트가 시스템 전체를 완성하고 사람은 코드 한 번 들여다보지 않은 채 전략 결정과 결과 확인만 반복하다가 내부가 어떻게 굴러가는지 전혀 이해하지 못하는 상태에 이르게 될지도 모릅니다.

불편한 진실은, 이제 학습조차 의도적으로 설계하지 않으면 우연히 일어나지 않는다는 점입니다.

의도적으로 배우려면

에이전트 중심 환경에서도 기술적 날카로움을 잃지 않으려면 의도적인 장치가 필요합니다. 현실에서 효과가 있는 습관 몇 가지입니다:

코드 리뷰를 훈련으로 삼기 굳이 손대지 않아도 돌아가는 코드라 해도 diff를 꼼꼼히 읽고 한 번쯤 직접 리팩토링해 봅니다. 코드에 완벽이 필요해서 하는 일은 아닙니다. 내 감각의 날을 벼리는 연습입니다.
가끔은 ‘노-에이전트’ 스파이크 해보기 분기마다 작은 기능 하나쯤은 도구의 도움 없이 밑바닥부터 짜봅니다. 배포보다는 손끝 감각을 영점 조절하는 데 목적이 있습니다.
결정을 측정으로 연결하기 “배움은 어디로 갔을까?”에서 다뤘듯, “비용 40% 절감”, “신선도 10배 개선” 같은 가설을 적어 두고 직접 계측해 봅니다. 배움은 예상과 실제 지표의 차이에서 생깁니다.
설명하고 문서화하기 다른 동료가 구현할 수 있을 만큼 명확한 설계 문서를 쓰거나 시스템의 맥락을 설명하다 보면 생각이 선명해집니다.
다른 사람의 ‘의도’ 읽기 오케스트레이션이 기본이 되면 스펙 자체가 1급 산출물이 됩니다. 예전에 오픈소스 코드를 읽으며 배웠듯 이제는 잘 쓰인 스펙과 프롬프트 구조를 읽으며 배워 봅니다.

솔직한 현실

하지만 많은 엔지니어는 이 중 어떤 것도 실천하지 않을 가능성이 큽니다. 게을러서가 아니라, 기본으로 주어지는 경로가 너무나 압도적으로 효율적이기 때문입니다.

속도에만 최적화하면 에이전트가 95%의 작업을 해치웁니다. 사람은 회의하고 스펙을 쓰고 대시보드를 봅니다. 그러다 어느 날 문득 “에이전트가 없으면 나 혼자선 아무것도 못 짜겠는데?” 하는 서늘한 순간을 마주합니다.

이 흐름 자체가 완전히 새롭지는 않습니다. 시니어 엔지니어가 연차가 쌓여 매니지먼트로 넘어갈 때 겪던 경로와 비슷합니다. 다만 그 주기가 10년에서 2년으로 극단적으로 압축됐을 뿐입니다.

끝까지 날카로움을 유지하는 사람들은 그것을 일부러 선택한 이들일 겁니다. “내 시간의 20%는 무조건 diff 분석에 쓴다”, “이번 분기에는 에이전트 없이 작게 구현해본다”, “이 구조적 결정의 밑바닥까지 파고든다”처럼 의식적으로 결정을 내린 사람들 말입니다.

이제 배움은 선택입니다. 저절로 생기지 않습니다.

앞으로의 선택지

우리는 지금 각자의 엔지니어링 미래를 선택하는 갈림길에 서 있습니다.

매니저로 나아가고 싶다면, Su의 모델에 집중하세요. 손수 코드를 짜는 집착을 내려놓고 고수준의 우선순위 설정과 아키텍처 판단에 전념하는 편이 규모 있는 조직에서 빛을 발합니다.

오케스트레이터로 자리잡고 싶다면, Intent 모델을 파고드세요. 정교한 스펙 문해력을 기르고, 다층 검증 체계를 설계하며, 에이전트 군단을 안정적으로 조율하는 역량을 다듬으면 됩니다.

프로그래머 본연의 감각을 지키고 싶다면, Beck의 길을 걸으세요. 가끔은 직접 코드를 만지고, 에이전트가 짠 코드를 엄격하게 리뷰하며, 시스템의 디테일에 끝까지 집착하는 겁니다. 10배 빠른 속도로 결과물만 찍어내는 이들 사이에서 코드의 본질을 가장 깊이 꿰뚫어 보는 전문가로 남게 될 겁니다.

저는 대다수가 자연스럽게 Su와 Intent의 흐름으로 수렴할 것으로 봅니다. 산출물이 폭발적으로 불어나는 유혹을 뿌리치기 어렵기 때문입니다. 반대로 “코드에 밀착해 감각을 유지하는 일”에는 의식적이고 다소 역발상에 가까운 용기가 필요할 겁니다.

셋 모두 성립 가능한 길이지만 어느 것도 저절로 주어지지 않습니다. 무엇을 최적화할지 스스로 선택해야 합니다.

지금 에이전트로 무언가를 만들고 있다면 그 일은 곧 자신의 미래를 설계하는 작업이기도 합니다. 부디 의식적으로 선택하시길 바랍니다.

AI 에이전트로 제품을 만들며 써 온 연재를 이 글로 마무리합니다: 배움은 어디로 갔을까, Intent와 IDE, 사이트를 에이전트 친화적으로, 사람의 역할. 질문은 어떤 접근이 옳은가가 아니라, 내가 무엇을 최적화하고 있으며 날카로움을 유지하기 위해 무엇을 기꺼이 훈련할 것인가입니다.