Not All AI Builders Are Doing the Same Work
In 2026, nearly everyone I interact with in tech wants to talk about AI. It comes up on LinkedIn, at...
개요 #
"저 요즘 AI로 빌드하고 있어요." 2026년 개발자 모임에서 가장 많이 들리는 말이다. 그런데 이 한 문장 안에는 서로 완전히 다른 세 가지 작업이 섞여 있다.
엔지니어 Danielle Heberling은 링크드인, 밋업, 컨퍼런스, 회사에서 오가는 AI 대화가 대부분 표면에 머문다고 지적했다. 무엇을 만들고 있는지, 어떻게 만들고 있는지 물으면 답이 갈린다는 것이다. 그는 자신이 만나본 사람들을 기준으로 AI 빌더를 세 부류로 나눴다. 성숙도 모델은 아니라고 못 박았다. 위 단계가 아래 단계보다 낫다는 뜻이 아니라, 각자 실제로 하는 일을 더 정확히 부르자는 제안이다.
아래 순서는 그가 현장에서 자주 마주친 쪽부터다.
1. AI로 만드는 사람 (uses AI to build) #
압도적으로 흔한 유형이다.
Codex나 Claude 같은 코딩 어시스턴트로 설계를 잡고, 코드를 쓰고, 리뷰를 받는다. AI는 작업 흐름에 들어온 도구일 뿐, 자기가 만드는 시스템의 일부는 아니다.
엔지니어만 있는 것도 아니다. 프로덕트 매니저, 마케터, 고객 지원팀도 같은 도구로 코드를 짠다. 그중에는 자기가 만든 코드가 무슨 일을 하는지 정확히 모르는 채 결과물만 뽑아내는 경우도 있다.
Heberling의 판단은 이렇다. PoC 단계라면 괜찮다. 아이디어가 파볼 만한 것인지 빠르게 확인하는 방법으로는 유효하다. 다만 프로덕션에 올릴 때는 제대로 아는 엔지니어의 리뷰나 재작성을 거쳐야 한다. 돌아가는 소프트웨어처럼 보인다고 해서 프로덕션에 올릴 준비가 된 건 아니다.
2. AI를 넣어 만드는 사람 (builds with AI) #
수는 적지만 분명히 존재하는 부류다.
특정 목적의 에이전트를 만들거나, 소프트웨어 팩토리(AI가 제품의 일부를 생성하고 조립하는 자동화 파이프라인)를 구축하거나, LLM 출력을 제품의 일부로 쓰는 애플리케이션을 개발한다. 로컬 모델을 직접 돌려보는 실험도 여기에 들어간다.
Photo by David Brown on Pexels
1번과의 결정적 차이는 간단하다. AI가 소프트웨어를 만드는 걸 돕는 데서 끝나지 않고, 소프트웨어가 작동하는 방식 자체에 들어가 있다.
구분법도 명쾌하다. 1번이 만든 결과물에서 AI를 빼면 개발 속도가 느려진다. 2번이 만든 결과물에서 AI를 빼면 제품 기능 자체가 사라진다.
Heberling은 좀 더 캐주얼한 테스트도 제안했다. 만든 사람의 노트북이 절전 모드로 들어가도 그 물건이 계속 돌아가는가?
로컬 데모로도 배울 건 많다. 하지만 다른 사람이 쓸 수 있도록 AI 시스템을 배포하는 순간 문제의 종류가 달라진다. 안정성과 비용은 물론이고, 모델이 예상 밖의 응답을 뱉었을 때 어떻게 할지도 누군가는 고민해야 한다.
3. AI를 만드는 사람 (is building AI) #
경험상 가장 작은 집단이다.
모델 자체를 만들고 학습시키는 사람들이다. AI 연구자, 혹은 Anthropic이나 OpenAI 같은 회사에서 수백만 명이 쓰는 모델과 그 주변 도구를 다루는 엔지니어를 떠올리면 된다. 이들의 하루는 제품 기능을 배포하는 일과는 거리가 멀다. 학습 실험을 돌리고, 모델 행동을 평가하고, 다른 빌더들이 나중에 기대게 될 인프라를 만드는 쪽에 가깝다.
글쓴이는 어디쯤 있나 #
Heberling 본인은 1번과 2번에 걸쳐 있다고 밝혔다. 일상적인 엔지니어링 작업에는 AI 어시스턴트를 쓰고, 동시에 AI가 제품 동작의 일부가 되는 시스템을 만드는 데 관심이 크다.
회사에서 그는 실패한 CloudFormation 배포를 개발자가 조사할 수 있게 돕는 도구를 만들었다. Claude Code를 활용하되 공용 컴퓨트 위에서 돌아가고, 분석 결과를 Slack에 올린다. 그의 노트북이 켜져 있든 말든, 그가 자리에 있든 없든 팀이 쓸 수 있다.
이게 그가 말하는 2번의 모습이다. AI가 도구를 만드는 걸 도운 게 아니라, AI가 도구의 작동 방식 안에 들어가 있다.
아키텍처와 아직 다듬지 못한 부분에 대해서는 별도 글 Getting Claude Code off my laptop and onto shared compute에 정리했다.
전망 #
Heberling은 과감한 예측이라고 스스로 단서를 달았다. 2026년에 쓴 글이고, 나중에 틀린 것으로 드러나도 괜찮다는 말도 덧붙였다.
1번 유형은 사라지지 않지만 수요는 지금만 못할 거라는 게 그의 전망이다. 모두가 같은 도구를 쓸 수 있는 상황에서 AI 코딩 어시스턴트를 다룰 줄 안다는 게 큰 강점이 되기 어렵다는 이유다.
오해는 경계했다. 1번에 속하는 엔지니어가 전부 위태롭다는 뜻은 아니다. 경험 많은 엔지니어들은 AI를 쓰면서도 자기가 책임지는 시스템을 여전히 이해하고 있다. 그가 지목한 건 AI 도구에서 그럴듯한 결과물을 뽑아내는 것 자체가 주된 기술인 사람들이다.
이들도 일자리는 찾겠지만 선택지는 줄어들 것이다. 특히 정말 가고 싶은 엔지니어링 팀일수록 그렇다. 더 많은 선택지를 갖는 쪽은 AI가 틀렸을 때 알아채고, 결과물을 고치고, 그게 프로덕션에 올라갔을 때 책임질 수 있는 사람들이다.
2번과 3번의 선택지는 늘어날 거라고 봤다. 나머지 모두가 쓰게 될 시스템과 역량을 만들고 있고, 그건 프롬프트를 잘 쓰는 것과는 다른 일이기 때문이다.
마무리 #
Heberling은 앞으로 누군가 "AI로 빌드한다"고 말하면 그게 무슨 뜻인지 되물을 생각이라고 했다.
AI로 만들고 있습니까, AI를 넣어 만들고 있습니까, 아니면 AI를 만들고 있습니까?
당신은 오늘 어디에 속하나?
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.