새로 나온 코딩 에이전트나 이미지 생성 도구를 잘 써 보려고 주말 내내 프롬프트 작성법과 설정 요령을 정리해 둔다. 어떤 문구를 넣어야 모델이 실수를 덜 하는지, 어떤 영어 단어를 붙여야 화질이 좋아지는지 노트에 적어 두고 남들보다 앞선 ‘AI 활용 기술’을 익혔다고 안심한다.
그런데 몇 달 뒤 모델 버전이 올라가거나 업데이트가 지나가면 그 노트가 하루아침에 쓸모를 잃는다. 결과물에서 뺄 요소를 일일이 적는 부정 프롬프트와 시드 번호를 만져야 나오던 그림이 스타일 버튼 하나로 완성된다. 길게 풀어 적어야 알아듣던 코드 수정 지시도 에이전트가 저장소 구조를 읽고 스스로 처리한다.
베테랑 개발자 찰스 밀러(Charles Miller)가 2026년 10월 26일 올린 「“AI Skills” are worthless in 2026」와 그 뒤를 이은 GeekNews·Lobste.rs의 논쟁은 이 허탈함의 정체를 파고든다. 몇 주 만에 배워 몇 달이면 사라지는 요령을 넘어 도구가 바뀔 때도 남는 실력이 무엇인지 짚어 본다.
i++보다 ++i가 빠르다는 전설과 프롬프트 부적
밀러가 스무 살이던 1995년 무렵 C 언어를 배울 때만 해도 변수 값을 1 늘리는 후위 증가(i++)가 전위 증가(++i)보다 느리다는 말이 상식처럼 통했다. i++는 원래 값을 돌려줘야 하니 복사본을 보관해야 하고 ++i는 바로 값을 늘려 그 낭비를 피한다는 논리였다. 하지만 1995년 당시의 기본적인 최적화 컴파일러(불필요한 동작을 줄여 기계어로 번역하는 프로그램)조차 i++의 반환값을 쓰는지 확인한 뒤 안 쓰면 복사를 생략했다.
이 통념은 C++의 클래스형 반복자(요소를 순서대로 가리키는 객체)에서도 오래 남았다. 사용자 정의 후위 연산자(operator++(int))는 이전 값을 복사해 반환하므로 디버그 빌드에서는 차이가 날 수 있고 정적 분석기 PVS-Studio가 경고를 띄우기도 한다. 그러나 std::vector<T>::iterator 같은 단순 반복자는 최적화를 켜면 컴파일러가 복사본을 지워 측정 가능한 차이가 거의 없다. 요즘처럼 CPU가 다음 갈래를 점치는 분기 예측과 명령어 재배치를 수행하는 환경에서는 옛 프로그래머들의 자잘한 습관이 오히려 프로그램을 느리게 만들기도 한다.
생성형 AI를 둘러싼 요령도 같은 길을 걷는다. 이미지 생성 도구를 운영하는 현장에서는 초기에 ‘masterpiece, 8k, highly detailed, photorealistic’ 같은 마법 단어를 외우고 설정값을 조합하는 일을 기술처럼 여겼다. 하지만 몇 달 지나지 않아 그 요령들은 프롬프트 자동 확장이나 LoRA(화풍을 바꾸는 가중치 조각) 합성, 스타일 프리셋으로 흡수됐다. 모델을 잘 움직여 원하는 결과에 빨리 닿게 해 주는 방식은 효과가 확인되는 순간 제품 뒷단으로 포장되어 기본 경험이 된다.
It makes sense to believe that all the tricks we come up with to make models behave better, the ways of working with models that get us to a useful result faster, if they work, are going to be folded back into the product, packaged, and become the default experience a few months later. And yet, in five years, I’m sure there will be old heads doggedly adding “you are an experienced software developer, make no mistakes” to their custom instructions.
효과가 입증된 요령일수록 개인기로 남지 않고 가장 먼저 제품의 기본 기능으로 사라진다. 그런데도 5년쯤 뒤에는 반환값도 안 쓰면서 ++i를 고집하듯 맞춤 지침에 “당신은 숙련된 소프트웨어 개발자입니다. 실수하지 마세요”를 부적처럼 적어 넣는 사람이 남아 있을 것이다.
일등으로 달리는 사람과 스티븐 브래드버리의 금메달
그렇다고 새 도구와 기법을 외면하자는 뜻은 아니다. 오늘 맡은 업무를 잘 해내려면 현재 도구의 사용법을 익혀야 한다. 다만 몇 주면 배우고 몇 달 뒤면 쓸모없어지는 기술은 딱 그 순간의 일을 처리하는 데 쓰일 뿐 그 시점을 넘어서는 가치를 주지 못한다.
밀러는 18개월 전 한 CEO가 당장 AI 열차에 올라타지 않으면 뒤처질 것이라고 외치던 장면을 떠올린다. 새 물결이 일 때마다 이런 조바심이 반복되지만 역사를 돌아보면 가장 먼저 뛰어든 쪽이 끝까지 이긴 사례는 드물다.
Google, Facebook, 그리고 iPod, iPhone, iPad는 모두 해당 분야의 첫 주자가 아니었다. 자리를 먼저 차지하는 것보다 기술이 무르익었을 때 제대로 작동하는 제품을 내놓는 쪽이 훨씬 큰 가치를 가져갔다. 설익은 요령을 한 달 먼저 외우는 일보다 도구가 안정됐을 때 무엇을 제대로 만들지 아는 편이 훨씬 중요하다.
그래서 밀러가 고른 태도는 호주 쇼트트랙 선수 스티븐 브래드버리(Steven Bradbury)의 방식이다. 브래드버리는 올림픽 결승전에서 무리한 선두 다툼에 끼어들지 않고 뒤에서 자기 속도를 지키며 따라가다가 마지막 코너에서 앞선 선수들이 한꺼번에 넘어지는 바람에 가장 먼저 결승선을 통과했다. 과열 경쟁에 힘을 빼기보다 무리와 보폭을 맞추며 때가 왔을 때 기회를 잡을 준비를 해 두는 셈이다.
기본 화면이 결제 창이 될 때 벌어지는 비용의 양극화
밀러의 글이 커뮤니티에 올라오자 비용을 둘러싼 반론이 뒤따랐다. 유용한 활용법이 몇 달 뒤 기본 기능으로 흡수된다고 하지만 정작 그때 자주 볼 화면은 토큰이 바닥났다는 결제 창일 것이라는 지적이었다. 액센츄어(Accenture)가 직원의 Claude 사용액을 월 29달러로 제한해 슬라이드를 PDF로 변환하는 식의 사용을 줄이려 했다거나 개발자에게 주당 250달러 예산 한도가 적용될 것이라는 소식이 함께 거론됐다.
토큰 가격이 내려가고 있으니 결제 창이 미래의 전부는 아닐 것이라는 의견도 맞섰다. Anthropic의 S-1 신고서를 보면 Amazon, Google, Microsoft에서 빌린 하드웨어 위에서도 추론 마진(구동 비용을 뺀 이익률)이 85%에 이르고 클라우드 회사들이 내줄 수 있는 양보다 더 많은 연산 용량을 원한다고 밝혔다. DeepSeek나 GLM의 ‘Flash’ 계열 같은 오픈 가중치 모델은 100만 토큰당 0.10~0.20달러 이하까지 내려와 1년 전 최상위 모델 못지않은 성능을 낸다.
진짜 격차는 도구가 알아서 해 줄 것이라며 돈을 태우는 방식에서 벌어진다. 동료가 한 달에 2만 달러 넘게 AI 비용을 쓰는 사례까지 나오는데 사람이 코드를 보지 않고 에이전트 떼를 돌리거나 마크다운 파일(SKILL.md)에 영어 산문으로 프로그램을 짜 놓고 모델을 비싼 통역기처럼 부릴 때 이런 일이 생긴다. Artificial Analysis 비교표를 보면 최상위 모델 Fable 5.1을 최대 강도로 돌리는 비용은 경량 모델 Haiku 5.5를 낮은 강도로 돌릴 때보다 380배 비싸다.
실력 있는 개발자들은 한 달 AI 지출이 1,000~2,000달러를 넘지 않고 그보다 훨씬 적게 쓴다. 한 개발자는 남의 코드를 보안 감사할 때 딱 한 번 월 1,000달러어치 토큰을 다 써 봤는데 버그 포상금 플랫폼 HackerOne에 2만 달러를 쓰는 것보다 효과적이었고 AI가 찾은 문제의 95%가 실제 버그였다고 밝혔다. 수백 달러짜리 실행이 그만한 가치가 있는지 추산하고 단순 작업은 저렴한 하위 에이전트에 넘기는 비용 설계야말로 제품이 대신 못 하는 역량이다.
마법 주문이 사라진 자리에 남는 시스템 엔지니어링
이 논쟁을 따라가 보면 ‘AI 활용법’은 두 겹으로 나뉜다. 밀러가 가치가 없다고 한 쪽은 채팅창에 넣는 역할극 문구처럼 모델의 약점을 달래는 잔기술이다. 현업 엔지니어들이 배워야 한다고 말하는 쪽은 모델을 시스템의 부품으로 맞물려 돌아가게 만드는 시스템 엔지니어링(프로그램과 도구가 협력하도록 기반 구조를 설계하는 일)이다.
에이전트에 외부 도구를 연결하는 MCP 서버를 구성하고 브라우저 제어 도구 Playwright를 붙여 화면 테스트를 돌리는 일이 대표적이다. 에이전트가 WebAssembly(빠르게 실행되는 이진 코드 형식)로 컴파일할 수 있을 때 예전에는 못 만들던 무엇을 만들지 판단하는 안목이나 스타트업에서 사업 맥락과 모델 한계를 읽고 다음 자동화 과제를 찾아내는 감각도 몇 년간 직접 부딪친 경험에서 나온다.
질문하는 방식만 봐도 차이가 드러난다. 막연히 “이 앱에 버그가 있나?”라고 묻는 대신 정상 동작을 어떻게 검증할지 효과 대 비용 순으로 정리하고 간단한 검사는 하위 에이전트에 맡긴 뒤 버그 수정이 집중된 이력까지 살피게 하려면 문제를 쪼개는 훈련이 되어 있어야 한다. 손으로 코드를 짤 때처럼 아키텍처와 자료구조, 알고리즘을 잡고 초안이 의도에 맞는지 확인하는 과정은 도구가 좋아져도 건너뛸 수 없다.
옛 도구를 다뤄 본 경험이 왜 특정 설계가 살아남았는지 이해하는 밑거름이 되듯 오늘 AI 도구를 쓰며 기르는 힘도 문제를 정의하고 검증하는 기본기에 쌓인다. 도구를 달래는 요령은 업데이트 한 번에 증발하지만 문제를 검증 가능한 단위로 쪼개고 결과를 책임지는 엔지니어링은 도구가 바뀔수록 빛난다.
출처: Charles Miller, “AI Skills” are worthless in 2026, 2026년 10월 26일 · GeekNews 토픽 #36075 · Lobste.rs 토론.