나는 당신의 스킬이 필요 없다

"그거 하나면 끝난다니까!"

사무실 복도에서도, 마이크로키친의 커피 머신 앞에서도, 점심 식사 테이블 너머에서도 한동안 오가던 대화의 주제는 하나뿐이었다.

"그 스킬 써봤어? 그거 하나면 끝난다니까."

2025년 이후로 우리의 일상은 AI라는 거대한 열풍에 휩싸여 있었다. 특히 엔지니어들 사이에서는 에이전트의 '스킬'과 '하네스'가 매일의 화두였다. 복잡하고 반복적인 작업 단계를 묶어 한 번에 실행시키는 일종의 '단축키'가 스킬이라면, 모델이 엉뚱한 길로 새지 않도록 다른 도구와 데이터를 연결해 고삐를 틀어쥐는 손잡이가 하네스다.

GitHub는 이 마법 지팡이 같은 템플릿들로 넘쳐났고, 유명 테크 인플루언서들은 하루가 멀다 하고 새로운 스킬과 도구를 쏟아냈다. 그것들을 주머니 속에 얼마나 챙겨 넣었는지가 엔지니어의 생산성을 가르는 절대적인 척도처럼 느껴지던 때였다.

그로부터 2년이 지난 지금, 잠시 숨을 고르고 주변을 둘러본다. 누가 새로운 스킬이 좋다며 건네준다면, 당신은 그것을 자신의 개발 환경에 곧바로 적용해 쓸 것인가?

만약 그것이 아무런 마찰 없이 곧바로 돌아간다면, 조금 섭섭한 이야기지만 그 프로젝트는 프로덕션의 무게를 짊어지지 않은 가벼운 규모일 확률이 높다. 실제 알 만한 이름을 단 소프트웨어 제품들은 그 안에 가늠하기 힘든 복잡도, 기술 부채, 의존성이 빈틈없이 얽혀 있다. 남의 워크플로우를 위해 만들어진 스킬을 내 프로덕션 환경에 그대로 던져 넣어 쓰는 일은 불가능에 가깝다.

환호는 쉽고, 채택은 무겁다

초기에는 모델의 추론 능력이 실제 생산성으로 곧바로 연결되기 힘들었다. 원하는 결과를 얻어내기 위해 사람들은 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링을 치열하게 연구했고, 온갖 팁과 트릭을 패키징해 공유했다. 그것이 일종의 노하우이자 자산이었다.

하지만 모델의 성능이 하루가 다르게 도약하면서 상황이 완전히 뒤집혔다. 정밀하게 규격화되었던 프롬프트들은 점점 필요성이 떨어지기 시작했다. 복잡하고 긴 다단계 작업이 주어져도, 이제 코딩 에이전트들은 문맥을 단숨에 이해하고 온더플라이(On-the-fly)로 맞춤형 도구를 만들어 스스로 개발 환경을 점진적으로 성장시키는 단계에 이르렀다.

한계 비용의 역전이 일어난 것은 바로 이때쯤이었다.

남이 만든 스킬은 사실 공짜가 아니다. 내가 원하는 기능의 스킬을 찾았다고 해도, 그 코드를 내려받고 입출력 규격을 일일이 살펴야 한다. 무엇보다 내 에이전트에 이미 설정된 고유한 규칙과 충돌하는 부분은 없는지 검토해야 한다. 즉, 내 작업 환경에 맞게 고쳐 쓰는 데 적지 않은 인지적 비용이 발생한다. 반면 더 똑똑해진 모델들은 별도의 거창한 스킬 없이도 스스로 판단하고 필요한 도구를 필요한 순간에 만들어 쓴다. 실제로 모델이 업그레이드될 때마다 우리 팀의 스킬 파일 분량이 점점 줄어드는 것은 결코 우연이 아니다.

최근 소프트웨어 엔지니어링 세미나나 미팅에 들어가 보면 이 모순이 적나라하게 드러난다. 여전히 많은 이들이 자신이 개발한 '놀라운 AI 스킬'을 화면에 띄우고, 그것이 업무 속도를 얼마나 끌어올렸는지 열정적으로 프레젠테이션한다. 모두가 감탄하며 박수를 친다. 하지만 세미나가 끝난 뒤 그 코드를 내려받거나 실제로 자기 환경에 설치해 쓰는 사람은 단 한 명도 없다.

환호는 쉽고, 채택은 무겁다.

만약 그 발표의 핵심 아이디어가 정말로 인상적이었다면, 실제로 벌어지는 일은 따로 있다. 이제 엔지니어들은 남의 스킬을 내려받아 복사해 붙여넣지 않는다. 조용히 자리로 돌아와 자신의 코딩 에이전트에게 이렇게 지시를 내릴 뿐이다.

"여기 새로 나온 스킬의 링크가 있어. 이 스킬에서 내 작업 환경에 적용할 수 있는 새로운 아이디어를 찾아내 줘. 그리고 장단점을 분석해서 에이전트의 생산성을 높일 수 있는 방안을 기술 보고서로 정리해 줘."

실제로 얼마 전 Anthropic이 Claude Code의 '다이내믹 워크플로우(Dynamic Workflow)'를 공개했을 때, 내가 Gemini 중심의 하네스에 그 아이디어를 이식하기 위해 에이전트에게 내렸던 프롬프트가 정확히 이것이었다.

요즈음의 프론티어 모델들은 외부의 스킬을 직접 읽고 핵심 메커니즘을 파악한 뒤, 내 로컬 환경에 최적화된 새로운 도구를 1분 만에 재합성해 낸다. 초고속 개선과 즉각적인 재생산이 가능해진 시대에, 인터넷에 공유된 스킬과 하네스는 더 이상 소중히 모셔야 할 자산이 아니라 수명이 짧은 소모품에 가깝다.

섣부른 표준화가 부르는 음의 생산성

조금 더 현실적인 엔지니어링 현장으로 들어가 보자. 많은 조직이 앞다투어 추진하는 '팀 표준 스킬 배포' 같은 작업들은 과연 실보다 득이 많은 선택일까?

과거 소프트웨어 엔지니어링에서 병목은 언제나 '독해와 구현'이었다. 방대한 코드를 읽고 맥락을 파악하는 데 수개월이 걸렸고, 새로운 기능 하나를 안전하게 구현하기 위해 며칠 밤을 신중하게 고민해야 했다. 하지만 엔지니어들에게 코딩 에이전트와 팀 표준 스킬을 쥐어주자 패치(Patch) 제작 속도가 폭발적으로 빨라졌다. 그리고 병목은 곧바로 다음 단계인 '코드 리뷰'로 옮겨갔다.

하루에도 수십, 수백 개씩 쏟아지는 패치들을 인간이 일일이 검토하고 승인할 여력이 없자, 아예 리뷰를 포기하는 조직들까지 생겨났다. 그나마 리뷰를 유지하려는 팀들은 그 병목을 해소하기 위해 리뷰 스킬을 만들어 공유하기 시작했다. 테스트를 더 촘촘히 짜고, 다중 페르소나 기법이나 적대적 리뷰 기법을 동원해 리뷰의 질과 속도를 억지로 끌어올렸다. 그러자 이번에는 무슨 일이 벌어졌을까?

패치 제작과 리뷰가 동시에 가속되자, 이제는 CI(지속적 통합) 시스템 전체에 거대한 과부하가 걸리기 시작했다. 빌드와 테스트를 담당하는 인프라가 소방 호스에서 쏟아지는 물줄기처럼 밀려드는 패치의 양을 감당하지 못하고 늘어지거나 뻗어버린 것이다. 의외로 최근 내 주변에서 가장 뜨겁게 떠오르는 엔지니어링 토론 주제는 최신 스킬이나 하네스가 아니라, 'CI 테스트의 양과 빌드에 필요한 컴퓨팅 파워를 어떻게 줄일 것인가'이다.

당장 눈앞에 보이는 문제를 해결하려고 AI를 들이대면, 오직 그 부분만 국소적으로 가속되어 결국 다음 단계의 병목으로 이어질 뿐이다.

댄 히스(Dan Heath)는 저서 《업스트림(Upstream)》에서 눈앞에 닥친 문제만 수습하느라 시스템의 근본적인 원인을 보지 못하는 현상을 날카롭게 지적한다. 하류(Downstream)로 떠내려오는 문제들을 각개격파하는 데 몰두하다 보면, 기다리는 것은 팀의 번아웃뿐이라는 것이다. 지금 우리가 벌이고 있는 '팀 표준 스킬' 경쟁이 정확히 그 꼴이다. 코딩 속도를 올려 리뷰가 막히면 리뷰 스킬을 만들고, 리뷰가 빨라져 CI가 무너지면 CI 효율화를 연구하는 이 끝없는 하류의 두더지잡기 게임이다.

국소적인 문제를 해결하기 위한 섣부른 AI 도입과 표준화가, 조직 전체의 관점에서는 병목을 그저 다른 곳으로 이전시키며 '음의 생산성(Negative Productivity)'을 만들어내고 있는 것은 아닐까.

단 5분의 집중력으로 무엇을 할 것인가

칼 뉴포트(Cal Newport)는 《슬로우 프로덕티비티(Slow Productivity)》에서 눈에 보이는 결과물을 맹목적으로 늘리는 것을 '가짜 생산성(Pseudo-productivity)'이라고 지적했다. 고전적 지식 노동의 오랜 병폐를 꼬집은 말이었지만, 프롬프트 하나에 수천 줄짜리 코드가 쏟아져 나오는 AI 시대에 이 경고는 더욱 중요해졌다.

일단 AI로 뭔가를 빠르게 뱉어내어 다른 사람들의 집중력을 소비하게 만드는 것 역시 명백한 '음의 생산성'이라 할 수 있다. 진짜 가치는 더 많은 코드를 쏟아내는 데 있지 않다. 오히려 가장 희소하고 값비싼 자원이 되어버린 사람의 집중력을 보호해 주는 것이야말로 리더십과 팀 프로세스가 가장 깊이 신경 써야 하는 부분이다.

크로미움처럼 긴 역사를 지닌 프로젝트에는, 항상 그 세월에 걸맞은 방대한 양의 부산물이 쌓여 있다. 그중에서도 사람들의 마음을 가장 지치게 만드는 것이 바로 버그 트래커다. 이 트래커 안의 수만 개에 달하는 리포트 중에는 오랜 세월 관심 바깥으로 밀려난 '유령 버그'들이 방치되어 있다. 투자 시간 대비 효용 가치가 낮아 누구도 손대지 않으려 하지만, 코드베이스의 질을 평가할 때 무시 못 할 노이즈를 만들어내는 문제들이다.

엔지니어의 집중력을 쓰기에는 너무 아깝지만 누군가는 반드시 치워야 하는 문제들. 바로 이런 것들을 사람 대신 조용히 해결해 주는 시스템이야말로 실질적인 가치를 제공하는 것이 아닐까?

이러한 프레임에서 다시 질문을 던져본다.

"한 명의 엔지니어가 5분의 집중력을 투자할 수 있다면, 그 5분 안에 해결할 수 있는 가장 가치 있는 일은 무엇인가?"

새 코드를 짜거나 설계를 뒤엎는 일은 5분 안에 끝낼 수 없다. 필연적으로 또 다른 적체와 병목을 부르기 때문이다. 내가 제안하는 답은 바로 백그라운드에 상주하는 섀도우 에이전트 시스템이다.

이 에이전트는 밤낮없이 버그 트래커를 누비며 오래된 리포트를 하나하나 검수하고 현재 코드베이스에서 재현 테스트를 실행한다. 버그가 이미 해결된 것이 확인되면, 에이전트는 적절한 엔지니어를 찾아 짤막한 코멘트를 남긴다.

"이 이슈는 12년 전 등록되었으나, 현재 브랜치에서 재현되지 않으며 관련 회귀 테스트를 모두 통과했습니다. 커밋 1234를 통해 이미 해결된 것으로 보입니다. 이슈를 닫으시겠습니까?"

엔지니어는 에이전트가 정리해 둔 코멘트를 훑어보고, 채 5분도 걸리지 않아 확인 버튼을 누르고 이슈를 닫는다.

누구에게도 새로운 스킬 설치를 요구하지 않았다. 누구의 워크플로우도 흔들지 않았다. 지루한 검증은 에이전트가 백그라운드에서 끝내두고, 사람에게는 오직 5분 이내의 검토와 승인만을 요청했을 뿐이다.

이 시스템을 가장 좋아하는 이들은 다름 아닌 팀원들이다. 자신들은 깊은 사고와 창의성이 필요한 일에 고도의 집중력을 유지하면서, 하루 5분의 투자로 십수 년 넘게 묵혀 있던 팀의 버그들을 매일 조금씩 지워나갈 수 있기 때문이다.

이 사례가 증명하듯, AI 시대의 생산성은 완전히 다르게 접근되어야 한다.

생산성 = 측정 가능한 임팩트 / 소비된 인간의 집중력(시간)

에이전트 시스템의 완성도는 결과물을 얼마나 빨리, 많이 쏟아내는가가 아니라, 인간의 집중력을 요구하는 시간을 얼마나 철저하게 통제해 냈는가로 증명된다. 분모인 인간의 집중력이 획기적으로 줄어들 때, 비로소 시스템의 진짜 생산성은 폭발한다. 보다시피 생성해 낸 코드의 양은 이 공식 안에 없다.

기승전-다양성

타인의 스킬을 내려받는 것으로 시작한 이 글은 의외의 종착역에 다다른다. 그것은 결국 우리 인간으로서의 다양성이 얼마나 중요한가에 대한 이야기다.

세상의 모든 소프트웨어 엔지니어들이 대동소이한 모델을 쓰게 되면서, 코딩 능력의 평준화라는 거대한 트렌드는 이미 거스를 수 없는 파도가 되었다.

이 거대한 파도 앞에서 우리에게 남은 진짜 가치는 무엇일까. 많은 이들이 AI 시대 엔지니어의 핵심 덕목을 묻지만, 내게 있어 가장 유효했던 답은 문제의 본질을 바라보는 '나만의 독특한 관점'을 빚어내는 일이었다. 그리고 그 관점은 엔지니어 각자의 고유한 셋업과 작업 스타일에 고스란히 녹아든다.

이 독특함은 최신 유행의 스킬을 복사해 내려받는다고 해서, 혹은 엄청난 양의 코드를 쉴 새 없이 뿜어낸다고 해서 결코 생겨나지 않는다. 맞닥뜨린 문제의 본질을 넓고 깊게 고민하고, 숱한 실험을 거치며 얻은 통찰이 프로젝트 전반에 서서히 배어들 때 비로소 만들어진다. 고전과 오래된 지혜들이 일러주듯, 도구의 속도가 아무리 빨라져도 엔지니어링의 본질인 직관, 취향, 그리고 비전의 가치는 조금도 변하지 않았다.

"나는 당신의 스킬이 필요 없다."

내가 오히려 바라는 것은 오직 당신만의 고유한 경험에서 길어 올린 독특한 관점, 그리고 문제의 본질을 꿰뚫어 보는 통찰과 지혜다. 그리고 서로가 그 고유함을 잃지 않도록 부단히 자극하고 지켜봐 주는 건강한 팀 문화다.

모두가 같아져 버린 시대, 이제 '다름'이 가장 귀해지는 시간이 올 것이다.