The Next Evolution of Software Developers
The next evolution of software developers: from implementation to intent, orchestration, and...
개요 #
AI가 개발자를 대체할 것인가. 이 논쟁을 두고 개발자 Roberto B.는 양쪽 모두 핵심을 비껴갔다고 말한다. 그가 보기에 진짜 변화는 AI가 코드를 짤 수 있다는 사실이 아니다. 코드 작성이 더 이상 소프트웨어를 만드는 데 가장 어려운 일이 아니게 됐을 때, 이 직업에 무슨 일이 벌어지느냐가 진짜 질문이다.
그의 결론은 간단하다. AI는 개발자를 없애는 게 아니라 추상화 스택에서 한 층 위로 밀어 올리고 있다는 것. 어셈블리에서 고급 언어로, 수동 메모리 관리의 종료, 보일러플레이트를 걷어낸 프레임워크, 운영 복잡도를 덜어낸 클라우드까지 — 소프트웨어 엔지니어링의 큰 도약은 늘 추상화 수준을 끌어올리는 방식으로 일어났다. AI도 같은 계보에 있다는 얘기다.
파괴적인 건 AI가 아니라 추상화다 #
글쓴이가 커리어를 시작하던 시절, 개발은 IDE를 중심으로 돌아갔다. 클래스를 만들고 함수를 구현하고 버그를 잡으며 커밋 하나씩 코드베이스를 키워가는 게 하루 일과였다. 코드는 컴퓨터에게 의도를 전달하는 언어 그 자체였다.
시스템이 커지자 흥미로운 일이 생겼다. 새 코드를 쓰는 것만큼 기존 코드를 이해하는 일의 가치가 올라간 것이다. 레거시 애플리케이션을 인수해 동작 방식을 파악하고, 회귀 없이 버그를 고치고, 새 기능을 안전하게 얹는 컨설팅 프로젝트가 통째로 하나의 사업이 됐다. PHP나 Java 코드 100줄을 더 뽑아내는 것보다 시스템을 이해하는 게 중요해지면서, 코드를 읽는 능력이 값비싼 기술이 됐다.
그리고 지금, 추상화 계층이 다시 한번 움직이고 있다.
개발자는 스택 위로 올라가고 있다 #
글쓴이는 요즘 구현을 떠올리기 전에 문제를 이해하는 데 훨씬 많은 시간을 쓴다고 말한다. 요구사항을 정의하고, 제약을 명확히 하고, 트레이드오프를 따지고, 아키텍처를 설계하고, 기존 플랫폼을 연결하고, AI가 만든 코드를 리뷰하고, 어디까지가 결정론적 소프트웨어로 충분하고 어디서부터 AI 추론이 실제 가치를 만드는지 판단한다.
코드 작성은 여전히 업무의 일부다. 다만 가장 큰 가치를 만드는 활동은 더 이상 아니라는 것이 그의 진단이다.
그래서 개발자가 사라진다고 보지 않는다. 스택의 다른 층으로 이동할 뿐이다. 수년간 쌓은 기술 지식이 갑자기 쓸모없어지지도 않는다. 오히려 반대다. 추상화 아래에서 무슨 일이 벌어지는지 이해할 수 있기 때문에 더 높은 층에서 일할 수 있다. 역할은 모든 결정을 손으로 코드에 옮기는 쪽에서, 애초에 그 결정을 내리는 쪽으로 옮겨간다.
개발자가 덜 기술적이 되는 게 아니다. 같은 기술력을 더 높은 추상화 수준에서 쓰는 것이다.
IDE는 더 이상 작업의 중심이 아니다 #
수십 년간 IDE는 소프트웨어를 만드는 주요 인터페이스였다. 그 인터페이스가 바뀌고 있다.
무엇을 만들지 서술하고, 맥락을 주고, 요구사항과 제약을 정의하면 시스템이 구현의 일부를 대신 만들어낸다. 그 시스템이 Codex든 Claude Code든 Gemini CLI든, 아직 세상에 없는 도구든 그건 부차적인 문제다. 중요한 건 개발 행위와의 상호작용 방식이 달라졌다는 점이다.
IDE가 사라지는 건 아니다. 글쓴이도 여전히 파일을 열고 코드를 살피고 디버깅하고 구현을 리뷰하고 가끔은 직접 코드를 쓴다. 다만 역할이 달라진다. 모든 줄이 태어나는 곳에서, 생성된 구현을 검토하고 이해하고 검증하고 발전시키는 곳으로 무게중심이 옮겨간다. 주된 인터페이스가 구현에서 의도 쪽으로 서서히 이동하는 셈이다.
소프트웨어의 경제학이 달라진다 #
이 전환은 개발의 경제성도 바꾼다. AI에도 비용이 든다. 토큰은 공짜가 아니다. 그런데 코드를 생성하고 리뷰하고 반복 개선하는 비용을, 처음부터 끝까지 손으로 했을 때의 비용과 나란히 놓고 보면 업계가 어디로 향하는지는 무시하기 어렵다는 게 그의 판단이다.
구현 비용은 역사상 유례없이 싸지고 있다. 그렇다고 소프트웨어의 가치가 떨어지진 않는다. 오히려 훨씬 더 많은 소프트웨어가 만들어질 것이다. 예전엔 구현 비용이 너무 커서 접었던 아이디어가 실현 가능해진다. 커스텀 소프트웨어를 정당화할 수 없던 소상공인이 업무를 자동화하고, 프리랜서가 예전엔 팀 전체가 필요했던 제품을 만들고, 스타트업은 더 빠르게 실험한다.
그리고 그렇게 늘어난 소프트웨어는 어딘가에서 돌아가야 한다. 안정적인 인프라, 배포 플랫폼, 관측성, 인증, 콘텐츠 관리, 결제, 모니터링, 스토리지, 데이터베이스, 연동, 보안이 필요하다. Laravel Cloud, Vercel, Netlify, Storyblok, Supabase, Stripe 같은 플랫폼은 AI가 코드를 짤 수 있다고 해서 덜 중요해지지 않는다. 더 많은 아이디어가 실제 제품이 되도록 받쳐주는 블록이기 때문이다.
만드는 비용은 싸져도, 운영하고 발전시키고 책임지는 일까지 저절로 사라지진 않는다.
이제 차별점은 소유권이다 #
프로젝트의 모든 코드 한 줄까지 AI가 생성하는 미래를 가정해보자. 그 소프트웨어는 누가 소유하는가?
AI는 아니다.
아키텍처를 소유하는 사람은 여전히 있다. 서비스 간 통신 방식을 정하는 사람이 있고, 보안과 확장성, 신뢰성, 컴플라이언스, 성능, 비용, 장기 유지보수성을 책임지는 사람이 있다. 어떤 트레이드오프가 받아들일 만한지, 어떤 기술 부채는 미뤄도 되고 어떤 부채가 위험 수위에 왔는지 판단하는 사람이 있다. 특정 아키텍처 결정이 왜 내려졌는지, 6개월 뒤에도 그 결정이 유효한지 이해해야 하는 사람이 있다. 새벽 두 시에 프로덕션이 터졌을 때 최종적으로 책임지는 사람도 있다.
규모 있는 제품이라면 그 '누군가'는 개인 한 명이 아니라, 시스템의 각 부분을 나눠 맡은 사람들과 팀이 될 것이다.
코드를 생성하는 일과 제품을 소유하는 일은 전혀 다른 책임이다. 글쓴이는 구현이 싸질수록 소유권의 가치가 커진다고 본다. AI가 생산의 마찰을 걷어낼수록, 아키텍처와 기능·비기능 요구사항에 대한 결정의 질이 더 강한 차별점이 된다는 뜻이다. 소프트웨어를 만드는 일은 애초에 코드를 뽑아내는 일이 아니었다. 결정을 내리고 그 결과를 감당하는 일이었다.
코드는 생성할 수 있어도, 책임은 생성할 수 없다.
소프트웨어가 확률적으로 변하고 있다 #
애플리케이션 내부에서도 흥미로운 변화가 일어난다. 수십 년간 비즈니스 로직은 대부분 결정론적이었다. 같은 입력과 같은 상태라면 매번 같은 출력이 나오리라 기대했다.
AI는 여기에 다른 성질을 들여온다. 애플리케이션이 런타임에 추론하고, 자연어를 해석하고, 정보를 분류하고, 문서를 요약하고, 콘텐츠를 만들고, 도구를 고르고, 맥락에 따라 판단한다. 시스템의 일부가 순수하게 결정론적이지 않고 확률적으로 바뀌는 것이다.
여기서 완전히 새로운 종류의 엔지니어링 결정이 생긴다. 어디에 LLM을 쓰고 어디서는 전통적인 함수가 나은가? 출력이 정당하게 달라질 수 있는 대상을 어떻게 테스트하나? 품질은 어떻게 평가하고, 프로덕션에서는 어떻게 모니터링하나? 변동성은 어디까지 허용되나? 모델이 예상 밖의 결과를 내놓으면 어떻게 되나?
런타임에 지능을 넣을수록 이 질문들의 무게는 커진다. AI는 지능적인 컴포넌트를 제공해서 엔지니어링 결정을 없애주는 게 아니라, 새로운 결정을 만들어낸다.
개발자에게 열린 가장 큰 기회 #
글쓴이가 이 변화를 낙관하는 지점은 여기다.
오랫동안 많은 프리랜서와 컨설턴트가 판 것은 사실상 구현이었다. 고객이 기능을 요청하면 공수를 산정하고, 구현하고, 들인 시간만큼 청구했다. 구현이 싸지면 이 모델은 당연히 흔들린다. 그런데 그는 이를 문제가 아니라 기회로 본다.
경험 있는 개발자 한 명이 AI 역량, 클라우드 인프라, 인증 서비스, 결제 플랫폼, 헤드리스 CMS, 배포 서비스, 데이터베이스, 특화 API를 조합해 몇 년 전이라면 팀 하나가 붙어야 했을 제품을 만들 수 있다. 차별점은 모든 컴포넌트를 직접 구현하는 능력이 아니다. 어떤 컴포넌트를 쓸지, 어떻게 조합할지, 무엇을 커스텀으로 만들고 무엇은 아예 만들지 말아야 할지, 그리고 무엇보다 어떤 문제가 정말 풀 만한 가치가 있는지 아는 것이다.
이건 개발자를 제품 쪽으로 훨씬 가깝게 데려간다. 구현만 파는 대신 해결책을 팔 수 있고, 명세를 받아 코드로 옮기는 대신 무엇을 만들지 정하는 자리에 끼어들어 결과까지 책임질 수 있다.
그래서 그는 빌더(builder) 라는 단어를 좋아한다고 말한다. 빌더는 코드를 얼마나 직접 썼느냐로 정의되지 않는다. 문제를 이해하고, 해결책을 설계하고, 알맞은 도구를 고르고, 조각들을 엮고, 결과를 평가하고, 그다음에 벌어지는 일을 책임지는 사람이다.
이 관점에서 보면 앞으로의 개발자가 더 적은 가치를 만든다고 보긴 어렵다. 가치를 만드는 방식이 달라질 뿐이다. 구현은 줄고 의도는 늘고, 타이핑은 줄고 의사결정은 늘고, 오케스트레이션과 책임의 비중이 커진다.
업계의 모든 큰 전환은 뛰어난 엔지니어의 필요를 없애지 않으면서 추상화 수준을 올려왔다. AI도 같은 일을 하고 있다. 다만 지금까지 겪어본 적 없는 규모와 속도로 진행될 뿐이다. 덜 기술적이 되라는 요구가 아니라, 쌓아온 기술 지식을 더 높은 층에서 — 시스템을 이해하고, 좋은 결정을 내리고, 책임을 지는 일이 더 중요해지는 자리에서 — 쓰라는 기회에 가깝다.
소프트웨어 개발의 끝이 아니라, 소프트웨어 개발자의 다음 진화다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.


Photo by