에이전틱 역량 감퇴

에이전트가 등장하기 전, 나는 코드를 직접 작성하는 과정에서 반복 훈련을 쌓았다. 다양한 방법을 시도하고, 무엇이 잘못됐는지 디버깅하고, 다른 사람의 코드를 리뷰하고, 많이 읽었다. 에이전트는 이런 과정의 상당 부분을 건너뛸 수 있기 때문에, 의식적으로 반복 훈련을 쌓으려는 노력이 필요하다.

업계에 이제 막 입문한 사람이라면, 프롬프트를 입력하기 전에 먼저 가설을 세워보길 권한다. "왜?"라는 질문을 자주 던지고, diff를 꼼꼼히 읽고, 어디서 문제가 생길지 예측해보자. 때로는 문제를 스스로 직접 풀어보는 것도 중요하다.

내 경험상, 에이전트를 잘 활용하려면 두 가지 능력이 핵심이다.

1. 깊은 전문 지식: 좋은 결과물이 무엇인지 정의할 수 있을 만큼 해당 문제 영역을 깊이 이해해야 한다. 사용자, 제품, 비즈니스에 대한 이해도 여기에 포함된다.
2. 실전 판단력: 자신의 안목을 바탕으로 적절한 컨텍스트, 제약 조건, 테스트, 검증 방법을 선택해 명확하고 검증 가능한 계획으로 구체화하는 능력이다.

이 두 가지 역량을 키우려면 의사결정, 명세 작성, 방향 조정, 결과 검증을 꾸준히 훈련해야 한다.

내가 실제로 쌓아온 반복 훈련

소프트웨어 엔지니어링을 처음 시작했을 때는 솔직히 뭘 하고 있는지 감이 없었다. 그럼에도 뭔가를 만드는 게 재미있었고, 이런저런 시도를 해보다 실패하고, 거기서 배우면서 조금씩 성장하는 과정이 즐거웠다. 실패할 때마다 더 나은 엔지니어가 되기 위한 밑거름으로 삼으려 했다. 그렇게 쌓인 반복 훈련이 곧 나의 성장 과정이었다. 자바스크립트를 익힌 것도, C++로 프로그래밍하고 데스크톱 애플리케이션을 만드는 법을 배운 것도, 그래픽 집약적인 애플리케이션의 성능을 튜닝하는 법을 터득한 것도 모두 그런 방식이었다.

반복 훈련을 쌓는 과정에서 나는 어떤 작업에 임할 때 늘 가설이나 아이디어를 먼저 떠올렸다. 설령 완전히 틀린 생각이더라도 말이다. 내가 맞다고 생각하는 방법을 먼저 시도해보고, 안 될 때는 Stack Overflow를 찾거나 웹에서 문서를 검색해 지식을 흡수했다. 특히 난해한 주제라면 책을 읽기도 했다. 그렇게 계속 나아가다 보면, 그 시도들이 쌓여 전문성이 형성된다. 특히 취미로 하던 수준을 넘어 실제 프로젝트에 적용하기 시작하면 더욱 그렇다.

오늘날 내가 활용하는 판단력 대부분은 이런 수천 번의 작은 반복 훈련에서 나왔다. 실패를 디버깅하고, 다른 사람의 코드를 리뷰하고, 실제 시스템에서 한계가 드러나기 전까지는 괜찮아 보였던 추상화와 함께 살아가면서 쌓인 것들이다. 에이전트는 이제 그런 과정의 상당 부분을 생략할 수 있다. 경력 3년 차 정도라면, 코드가 생성되는 속도가 그것을 판단하는 능력보다 빠를 수 있다.

학습 과정의 단락(短絡)

AI를 처음 접하는 많은 사람들이 학습 여정을 상당 부분 건너뛸 수 있게 됐다고 생각한다. "여기 문제가 있어"에서 "여기 해결책이 있어", 혹은 "작업이 완료됐어"로 순식간에 넘어갈 수 있다. 그 과정에서 지식 기반을 쌓아주거나, "이건 왜 하면 안 되는지, 이걸 해야 하는 이유가 뭔지, 트레이드오프는 어떻게 따져야 하는지"를 몸으로 익히는 단계가 통째로 생략된다. 특히 주니어 엔지니어일수록 스스로 학습 여정을 적극적으로 챙겨야 하는 시대가 됐다고 생각한다.

여러 AI 연구소와 이야기를 나눠봤는데, 현재 주요 플레이어 대부분은 최대한 빠르게 결과나 답을 얻도록 돕는 데 집중하고 있다. 그게 당신의 명시적인 목표가 아닌 한, AI가 스스로 학습을 도와주지는 않는다. "일정 관리 앱을 만들어줘"와 "일정 관리 앱을 만들면서 단계별로 어떻게 하는지 가르쳐줘"는 전혀 다른 요청이다. 대부분은 두 번째 방식을 선택하지 않는다. 그게 옵션이라는 걸 모르기도 하고, '요즘은 빠른 속도와 빠른 출시가 중요하니까'라는 압박감 때문이기도 하다. 하지만 더 뛰어난 엔지니어가 되려면, 그리고 안목과 판단력을 꾸준히 키우는 전문성을 유지하려면, 숙련도를 쌓는 데 의식적으로 시간을 투자해야 한다.

작업 완료가 곧 반복 훈련은 아니다

어떤 문제든 비판적으로 사고하려면 해결책에 대한 가설, 즉 그것이 어떤 모습일지에 대한 아이디어를 먼저 갖는 것이 유용하다. 로직과 코드라면 어떤 구조일지, UI라면 어떻게 보이고 느껴지며 어떻게 상호작용할지를 미리 그려보는 것이다. 작업이 끝났다고 해서 반드시 무언가를 배운 건 아니다. 그저 작업이 완료됐을 뿐이다. 배움의 기회를 의식적으로 포착하려는 노력이 필요하다. 에이전트에게 작업 중간이나 완료 시점에 이런 질문을 던질 수도 있다. "중급 개발자, 혹은 주니어 개발자로서 내 지식을 넓히거나 문제를 바라보는 시각을 키우는 데 도움이 될 핵심 인사이트를 정리해줘." 이런 식으로 꾸준히 물어보면 된다. 스스로 적극적으로 학습에 임하기만 한다면.

요즘 내가 AI를 활용하는 분야 중 하나가 복잡한 3D 그래픽 프로그래밍이다. 나는 이 분야 전문가가 아니다. 그래서 AI에게 꼭 묻는다. "이게 어떻게 동작하는지 설명해줄 수 있어? 방금 구현한 이 개념에 대해 가르쳐줘. 이 요소들이 어떻게 연결되는지 이해할 수 있게 도와줘." 배우고 싶다는 욕구가 있기 때문에, 에이전트와 함께 그 목표를 추구한다. 배우려는 의지가 없다면 그런 기회는 그냥 흘러가고 만다.

작업 완료가 반복 훈련이 되지 않는 또 다른 경우는, 과정에서 실수가 없을 때다. 실수가 생기면 자연스럽게 생각하게 된다. '왜 잘못됐지? 뭘 더 잘할 수 있었을까? 내가 놓친 게 뭘까?' 그렇게 되돌아보게 된다. 반면 잘 풀렸을 때는 딱히 배움의 순간이 생기지 않는다. 그냥 '됐네, 다음 작업으로 넘어가자'가 되는 것이다. 특히 주니어라면 끊임없이 성장 기회를 찾으려는 자세가 필요하다.

Anthropic의 2026년 연구에서 주니어 엔지니어들이 파이썬 라이브러리 Trio를 학습하는 과정을 살펴봤다. 사후 퀴즈에서 AI 어시스턴트를 활용한 그룹은 50점을 받은 반면, 직접 작업한 그룹은 67점을 받았다. AI 그룹 내에서도 좋은 결과를 낸 사람들은 모델을 코드 자판기처럼 쓰는 대신 개념적인 질문을 던지고 설명을 요청한 경우였다. 앞서 한 말과 이어지는 내용이다. AI를 산출물 생성 도구로만 쓰고, 페어(pair)로 활용하거나 비판적 사고와 지식, 작동 원리 이해를 키우는 데 쓰지 않는다면, 어떻게 돌아가는지는 잘 모르면서 프롬프트만 잘 쓰는 상황이 될 수 있다. 그렇게 되면 결과를 검증하는 능력도 제대로 키우기 어렵다. 질문하고 설명을 요청한 사람들이 더 나은 결과를 낸 건 그다지 놀랍지 않다. 그들은 작동 방식, 기존 지식과의 연결 고리에 대해 훨씬 더 많이 생각했을 것이다. 패턴을 인식하고, '이게 어떻게 동작하는지, 어떻게 이해해야 하는지, 내 지식의 어디에 구멍이 있는지'에 대한 감각을 조금씩 쌓아간다. 17%p 차이가 납득되는 이유다. 물론 단일 파이썬 라이브러리를 대상으로 한 단기 연구라는 한계가 있어 단정 짓기는 어렵지만, 그럼에도 시사하는 바가 적지 않다.

낯선 것을 배울 때 나는 지금도 이런 방식으로 일한다. 의식적으로 루프 안에 머문다. 프롬프트를 입력하기 전에 가설을 세우고, 이유를 묻고, diff를 살피고, 어디서 문제가 생길지 예측하고, 에이전트가 작업을 검증할 수 있는 구체적인 방법을 제시한다. 가끔은 작은 문제를 직접 손으로 풀어보기도 한다. 에이전트가 작업을 마무리하는 동안에도 내 멘탈 모델이 함께 움직이길 원하기 때문이다.

그래도 적극적으로 활용하라

코드 수준의 전문성이 지금처럼 가치를 인정받는 시대가 얼마나 계속될지 나는 모른다. 모델이 너무 빠르게 발전하고 있어 확신하기 어렵다. 그렇다고 에이전트를 멀리하거나 모든 코드를 직접 타이핑하던 시절을 낭만적으로 그리워하는 것도 답이 아니다. 나는 에이전트를 적극적으로 활용한다. 어떤 날은 다섯 개에서 열 개의 세션을 동시에 띄워놓기도 하는데, 한번은 엉뚱한 프로젝트에 다크 모드 추가를 요청하는 실수를 저질렀다. 그 실수가 한 가지를 분명히 깨닫게 해줬다. 에이전트의 처리 속도는 내 주의력보다 빠르게 확장된다.

성능 패널에서 보낸 수천 시간

제대로 익히기까지 수천 시간이 걸린 것들이 있다. 성능 최적화가 바로 그중 하나다. 예전에는 참고할 만한 블로그 포스트나 책이 많지 않았다. 메모리나 하드웨어 제약을 다루는 고전적인 문헌이 일부 있었지만, 웹 성능 최적화나 자바스크립트 최적화, 힙 최적화 같은 주제를 잘 다룬 자료는 거의 없었다. 결국 Chrome 개발자 도구를 열고 성능 패널에서 페이지나 앱의 트레이스를 돌리며 직접 반복 훈련을 쌓아야 했다. 어디서 느려지는지 찾아보고, 플레임 그래프의 어느 부분이 문제인지 가설을 세우고, 메모리 패널에서 가비지 컬렉션이 막히는 건 아닌지 파고드는 식이었다. 그 시절에는 수많은 실수를 겪고 근본 원인을 파헤치는 과정을 통해서만, 무엇이 되고 무엇이 안 되는지에 대한 그 때로는 난해하기까지 했던 지식을 쌓을 수 있었다.

요즘이라면 비슷한 흐름을 DevTools MCP가 에이전트와 함께 성능 프로파일링을 대신 해주고, 원인을 파악해 수정까지 제안하는 방식으로 처리할 수 있다. 그러다 보면 성능에 대한 전문성이 예전만큼 쌓이지 않는다.

상상할 수 있는 것만 프롬프트로 만들 수 있다

요즘 트위터를 스크롤하다 보면 피드에 넘쳐나는 상상력과 창의성에 감탄하게 된다. 디자이너와 크리에이터들이 놀라운 셰이더, 게임, UI, 몰입형 경험을 만들어 공유한다. 기술적 토대는 이미 있었지만, 이제는 상상력이 곧 한계다. 원하는 걸 훨씬 빠르게, 훨씬 쉽게 만들 수 있는 시대가 됐다. 하지만 그러려면 먼저 아이디어를 떠올릴 수 있어야 하고, 에이전트에게 방향을 제시할 수 있어야 한다. 그리고 결과물을 검증할 전문성도 갖춰야 한다. 검증이 바닥이라면, 상상력은 천장이다.

음악을 하는 나는 곧 공개할 앨범 사이트 작업을 하면서, 홈페이지에 인터랙티브한 3D 오브젝트를 넣고 싶었다. 3D CD 플레이어, 바이닐 레코드 플레이어, 테이프 플레이어 같은 90년대 감성의 요소들이었다. 그런데 초기 버전은 완성도가 떨어질 뿐 아니라 인터랙션 패턴도 맞지 않았고, 모바일에서의 성능도 좋지 않았다. 우선 버그가 있다는 걸 알아챌 수 있는 전문성이 있어야 했다. 일반 사용자라면 그냥 느낄 수도 있겠지만, 나는 왜 그런지에 대한 가설을 세울 수 있었다. 그래서 직접 프로파일링하거나 에이전트에게 맡겨 원인을 파악할 수 있었다. 인터랙션 로직이 잘못 작성된 부분이 있었다. 상상력이 중요하다는 걸 다시 한번 느꼈고, 동시에 전문성도 그만큼 중요하다는 걸 깨달았다. 둘 다 있어야 한다. 생각할 수 있다면, 만들 수 있다.

다음 세대에게도 전문성이 필요할까?

이런 질문을 할 수 있다. 에이전트가 이런 작업들을 점점 더 잘 처리한다면, 사람이 굳이 전문성을 쌓아야 할까? 다음 세대는 이런 난해한 영역에서 전문성을 키울 필요가 있을까? 적어도 지금 시점에서는, 에이전트가 완벽하지 않은 영역, 결과물을 검토해야 하는 영역에서 여전히 전문성이 빛을 발한다고 생각한다. 특정 루프, 애니메이션, 스케줄링 루틴을 최적화해달라고 요청했을 때, 에이전트가 다른 무언가를 희생하는 방식으로 처리할 수 있다. 무엇을 봐야 하는지 모르거나, 구현 내용을 읽고 무슨 작업이 이루어졌는지 파악하지 못한다면, 원하는 것과 다른 결과물을 그대로 배포하게 될 수 있다.

스킬과 MCP는 유용한 워크플로를 담아낼 수 있다. 하지만 그 전제가 내 시스템에 더 이상 맞지 않는 순간을 알려주지는 못한다.

약 40만 건의 Claude Code 세션을 분석한 Anthropic 연구에서는 전문성을 특정 작업 단위로 살펴봤다. 해당 작업에 대해 중급 수준의 전문성만 갖추고 있어도, 초보자에 비해 검증된 성공에 도달할 확률이 높아졌다. 스택 전반에 걸쳐 10년 경력이 필요한 게 아니라, 다루는 문제 영역에서 '좋다'는 것이 무엇인지 알아볼 수 있을 만큼의 이해가 필요하다는 뜻이다. 요즘은 이걸 '안목'이라는 말로 표현하기도 하는데, 나도 이전에 이 주제로 글을 쓴 적이 있다. Claude Code 모범 사례 가이드를 읽으면서 검증 이야기로 시작한다는 점이 반가웠다. 테스트, 스크린샷 활용, 에이전트가 지속적으로 반복할 수 있는 근거를 제공하는 다양한 신호들, 그리고 단순한 완료 메시지 대신 직접 검토할 수 있는 증거를 남기는 방식 말이다. 전문성이 있으면 훨씬 더 능숙하게 결과물을 빚어낼 수 있다. 전문성 없이 얼추 그럴듯한 걸 만들어내는 것과는 차원이 다르다.

결국 이 모든 것은 결과물을 검증하고, 에이전트의 작업을 판단할 수 있는 전문성으로 귀결된다. 소프트웨어 엔지니어링이 점점 더 높은 추상화 레이어 위에서 이루어지는 시대에도, 숙련도와 장인 정신에 대한 투자가 계속되길 바란다.

전문성의 가치가 높아지고 있다

소프트웨어 엔지니어링의 기본기는 앞으로도 계속 중요할 것이고, 전문성도 마찬가지라고 생각한다. 바닥이 높아진 지금, AI는 사람들이 가진 역량과 전문성의 가치도 함께 높여주고 있다. 주니어는 실제로 무언가를 만들고, 실수하고, 배우고, 반복 훈련을 쌓으면서 시니어로 성장한다. 전문가는 무엇을 만들어야 하는지, 어떻게 검증해야 하는지, 완성도 높고 안정적이며 유지보수 가능하고 확장 가능한 결과물이 어떤 것인지, 다양한 컨텍스트와 플랫폼에서 어떻게 동작해야 하는지에 대한 직관이 있다. 이제 누구나 프롬프트 하나로 아이디어를 현실로 만들 수 있는 시대가 된 만큼, 그것을 충분히 높은 품질로, 실제로 배포 가능하게, 매력적으로, 유지보수 가능하게, 프로덕션에서도 안정적으로 만드는 역량은 앞으로도 계속 중요할 것이다.

이런 상황을 나는 매주 몇 번씩 마주한다. 지금은 어떤 앱이든 어떤 기능이든 프롬프트 하나로 시작할 수 있다. 예를 들어, 나는 지금 텍스트 에디터를 만들고 있다. 처음부터 만드는 건 아니고, 문법 개선이나 AI 스타일 문체 사용 여부 같은 것들을 짚어주는 글쓰기 보조 도구 개념이다. 프론티어 모델은 많은 주고받음 끝에 나름 괜찮은 UI를 만들어줬다. 놀라운 수준은 아니었고, 문제도 여럿 있었다. 화면 공간 활용이 최적화되지 않았고, 색상 대비도 부족했고, 스크롤 방식도 매끄럽지 않았다. 내가 이걸 알아챈 건 예전에 직접 같은 실수를 겪어봤고, 그 과정에서 전문성을 쌓았기 때문이다. 하지만 그 경험이 없다면, 프롬프트를 입력하고 결과물을 그냥 세상에 내놓고 끝낼 수 있다. 무엇이 더 나은지 모르기 때문에, 전문성을 쌓는 데 시간을 투자하지 않았기 때문이다.

다음 에이전트가 찾을 수 있는 곳에 교훈을 남겨라

내가 멘토링하는 사람들에게 자주 하는 말이 있다. 에이전트와 함께 일할 때, 당신이 에이전트를 더 나아지게 해야 하고, 에이전트도 당신을 더 나아지게 해야 한다는 것이다. 매일 어떤 형태로든 사이클이 돌아야 한다. 교훈이 메모리나 기록으로 쌓이고, 에이전트가 점점 발전하는 구조여야 한다. 그렇지 않으면 새 세션을 시작할 때마다 기억 상실증에 걸린 신입을 온보딩하는 것처럼 느껴질 수 있다. 당신의 비즈니스, 제품, 팀, 사용자에 대한 미묘한 맥락을 에이전트가 기억할 리 없다. 그래서 스킬뿐 아니라 컨텍스트와 온갖 정보를 에이전트에게 주입하는 데 공을 들이게 된다. 무엇이 실제로 유용하고 특정 문제에 맞는 내용인지, 단순히 도움이 될 것 같다는 생각에 넣은 내용인지 구별하는 것도 중요하다. 에이전트를 어떻게 더 가르칠 수 있을지, 매일 조금씩 에이전트와 자신 모두가 성장하고 있는지 점검하길 항상 권한다.

채팅 창에서 문제를 풀다 보면, 예를 들어 작업 중인 UI 컴포넌트에서 미묘한 스크롤 버그를 발견했다고 하자. 에이전트와 함께 주고받으며 해결하다 보면, 나중에도 쓸 수 있는 교훈이 어딘가에 담겨 있다. 그 교훈이 메모리에 추가될 수도 있고, 그렇지 않을 수도 있다. 특히 세션이 길어서 압축이 일어났다면 그 교훈이 제대로 남지 않을 수 있다. 채팅 창이 닫히면 교훈도 사라진다. 반면 특정 교훈이나 테스트, 린트 규칙처럼 리포지토리에 담기에 충분히 작은 형태로 코드화해두면, 이후 에이전트에게도 가르침이 된다. 나는 실제로 이 방식이 큰 도움이 됐다. 어떤 교훈을 얻으면 잠깐 시간을 내어 검토한다. lessons.md에 추가할 가치가 있는지, 에이전트 메모리에 저장하도록 요청할지, 어떻게든 계속 남겨둘 방법이 있는지. 교훈이 사라지는 건 아깝다. 나 스스로도 잊고 다음 문제로 넘어가기 마련이니까. 이런 상황이 정말 자주 생긴다. UI를 접근하는 방식에 대한 선호, 컴포넌트 작성 방식, 성능을 다루는 방식, 온갖 것들이 해당된다. 특정 문제를 내가 다루는 섬세한 방식이 있다면, 에이전트가 그걸 기억하게 하거나 기억할 수단을 마련해두고 싶다. 매번 반복해서 설명해야 하는 상황은 피하고 싶다.

에이전트가 우리가 하는 모든 것을 기억해줄 거라고 여기는 경우가 많은데, 꼭 그렇지는 않다. 메모리 시스템이 있더라도 배우려 했던 내용, 선호하는 작업 방식, 검증 접근법 같은 것들을 완전히 기억에 의존하기는 어렵다. 마크다운 파일에 이런 것들을 더 많이 기록해두는 것도 괜찮다. 다만 그게 전략이 되어 과도하게 투자하지 않도록 조심해야 한다. 나는 항상 이중 루프 개념을 좋아했다. 배움이 있는 좋은 반복 훈련은 나를 날카롭게 갈고, 동시에 에이전트도 날카롭게 갈아야 한다. 어떤 가설이 수정됐을 때, 그 수정이 린트 규칙, 타입 제약, 문서 컨벤션, 테스트로 남길 가치가 있는지 생각해보자. 앞으로도 계속 도움이 될 수 있도록.

외부 루프

숙련도라는 관점에서 이 모든 이야기가 의미하는 바는 이렇다. 전문성과 장인 정신에 투자하라. 반복 훈련을 쌓고, 실수하고, 거기서 배워라. 시간이 쌓이면 무엇을 만들 가치가 있는지 판단할 수 있게 된다. 계획을 작성하고 다듬으며, '완료'의 정의를 세우고, 정확성·안전성·사용자 영향을 확인하기 위해 사람이 루프에 남아야 할 지점을 설계할 수 있게 된다. 오늘날 엔지니어가 책임져야 할 외부 루프가 바로 이것이라고 생각한다. AI는 엔지니어링을 계속 더 높은 추상화 레이어로 밀어 올릴 것이다. 그리고 실행할 수 있는 에이전트가 많아질수록, 내 한정된 시간과 안목과 판단력을 어디에 쏟을지 더 신중하게 선택해야 한다.