AI가 코드를 쓴다면, 우리는 무엇을 해야 할까? 소프트웨어 엔지니어링의 미래
2026. 8. 6.
AI가 코드를 쓴다면, 우리는 무엇을 해야 할까? 소프트웨어 엔지니어링의 미래
가끔 이런 생각이 듭니다. 내가 평생을 바쳐 쌓아온 이 커리어, 어렵게 공부하고 수십 년간 갈고닦은 이 기술이 과연 언제까지 유효할까? 그 불안감은 외로운 소수자로 일해야 해서도, 나이가 많아서도 아닙니다. 오히려 코딩은 저를 젊게 만들어주는 활력소인 걸요! 그리고 제가 IT를 떠나겠다고 결심한 것도 아니고요.
정작 저를 불안하게 만드는 건 소프트웨어 엔지니어링이라는 '기술' 자체가 알아볼 수 없을 만큼 빠르게 변하고 있다는 사실입니다. 우리의 정체성이 이 일에 너무나 깊이 뿌리내리고 있기에, 이런 변화는 솔직히 너무나 두렵죠. 제가 실무에서 이 부분을 테스트해 봤을 때, 단순히 도구가 변하는 것을 넘어 우리의 존재 방식까지 흔들리는 기분이었죠.
Rails가 마법처럼 느껴졌던 시절
Rails가 마법처럼 느껴졌던 시절을 기억하시나요? 초창기 우리 팀은 레거시 엔터프라이즈 자바 환경에서 벗어나지 못하고 있었습니다. 그러다 스터디 그룹에서 《Ruby for Rails》 책을 읽으며 완전히 새로운 세상을 만났죠. '설정보다 관례(Convention over Configuration)', 코드 스캐폴딩, 그리고 이미 잘 연결된 MVC 아키텍처는 그야말로 충격이었습니다.
프레임워크가 많은 결정을 대신 해주니 개발은 놀랍도록 생산적이었고, 무엇보다 ‘마법’ 같았습니다. Rails는 매번 고민할 필요 없는 복잡성을 깔끔하게 추상화해 주었죠. 물론 그 밑에서 어떤 일이 벌어지는지는 여전히 이해해야 했지만요. 당시 우리가 일하던 레거시 자바 환경에서는 이런 유용한 도구를 꿈도 꾸지 못했습니다.
이런 마법 같은 경험이 저나 제 일의 가치를 떨어뜨렸을까요? 전혀요, 오히려 그 반대였습니다. 프로젝트 초기 설정을 하거나 기본적인 컴포넌트를 연결하는 데 드는 시간을 아낄 수 있었죠. 덕분에 고객과 클라이언트를 위한 훨씬 더 본질적인 문제, 즉 '무엇을 만들 것인가', '어떻게 만들 것인가'에 집중할 수 있게 되었습니다.
Rails는 기존 엔지니어들의 속도만 높여준 게 아니었습니다. 이미 고수준 언어가 기계어 명령어를 직접 다루지 않고도 프로그래밍을 가능하게 했듯이, Rails는 모든 개발자가 모든 계층을 처음부터 조립할 필요 없이 웹 개발에 쉽게 접근할 수 있도록 문턱을 낮춰주었죠. 저수준 작업이 패키징될수록 더 많은 사람이 소프트웨어를 만들 수 있고, 숙련된 개발자들은 더 야심찬 프로젝트를 시도할 수 있다는 패턴은 그때부터 명확해졌습니다. 제가 처음 Rails를 접했을 때, 이 프레임워크가 제공하는 놀라운 생산성과 간결함에 매료되어 '아, 개발은 이렇게 하는 거였구나!' 하고 무릎을 탁 쳤던 기억이 생생합니다.
추상화가 우리에게 가져다준 것
자, 이제 시야를 좀 넓혀 볼까요? 소프트웨어는 언제나 우리와 밑단 기계장치 사이에 또 하나의 계층을 추가하면서 진화해 왔습니다. 어셈블리어는 숫자 명령어 대신 읽기 쉬운 이름을 제공했고, 고수준 언어는 CPU 연산을 생각할 필요 없이 로직을 서술하게 해주었죠.
Rails나 Spring 같은 프레임워크는 공통적인 애플리케이션 구조를 패키징했습니다. IDE와 자동 완성 기능은 수동 코딩의 일부를 대신해 주었고요. yo webapp, ionic start, 그리고 create-react-app 같은 제너레이터들은 초기 설정과 보일러플레이트 코드를 책임졌습니다. 개인적으로 저는 Heroku를 통해 인프라 프로비저닝이 얼마나 쉬워질 수 있는지 몸소 체험했고, 특히 Rails 프로젝트에서 큰 도움을 받았습니다.
각각의 추상화는 우리가 한 가지 걱정을 덜고, 대신 더 흥미로운 일에 집중할 수 있도록 해주었습니다.
그렇다고 해서 밑에서 무슨 일이 일어나는지 완전히 잊어도 된다는 뜻은 아니었습니다. 특히 문제가 생겼을 때는 의존하는 계층들을 여전히 이해해야 했죠. 하지만 모든 작업을 위해 모든 세부 사항을 머릿속에 담고 다닐 필요는 없어졌습니다. 각 추상화는 우리에게 약간의 '인지적 대역폭(mental bandwidth)'을 되찾아 주었죠. 우리는 이 여유를 무엇에 쓸 수 있었을까요?
그러다 GitHub Copilot, Amazon CodeWhisperer, Amazon Q Developer 같은 도구들이 아예 '코드 자체'를 생성하기 시작했습니다. 추상화는 우리가 항상 '프로그래밍'이라고 생각했던 작업의 핵심 부분으로 점점 더 가까이 다가온 것입니다. GitHub Copilot을 처음 써봤을 때 느꼈던 충격은 마치 Rails를 처음 만났을 때와 비슷했습니다. '이제 정말 코딩의 본질이 바뀌는구나' 싶었죠.
도구가 협력자가 될 때
하지만 AI 코딩 에이전트들은 이전에 있었던 추상화 도구들과는 확연히 다른 느낌을 줍니다. 이전 추상화들은 대부분 우리가 소프트웨어를 구축하는 데 도움을 주는 '도구'처럼 느껴졌습니다. 하지만 에이전트들은 마치 '협력자'이자 때로는 '경쟁자'처럼 느껴집니다. 그들이 직접 소프트웨어를 구축하고 있으니까요.
에이전트에게 GitHub 이슈 목록을 주고, 그 이슈들을 처리하도록 맡겼을 때의 경험은 정말 색달랐습니다. 요청된 변경 사항을 적용하고, 스스로 테스트하며, 제가 최소한의 개입만 해도 요구사항을 충족할 때까지 반복 작업하는 모습을 보았을 때, 솔직히 놀라움을 넘어선 두려움이 밀려왔습니다.
추상화가 이제는 '우리'를 포함하는 것처럼 보였기 때문이죠.
실제로 이런 일이 일어나고 있는지 아닌지는 중요하지 않습니다. 많은 엔지니어가 '컴퓨터가 내가 하던 일의 더 많은 부분을 할 수 있다면, 나는 이제 어디에 설 자리가 있는가?'라고 묻는 이유가 여기에 있습니다. 그리고 기업들은 훨씬 더 불편한 질문을 던지죠. '에이전트가 엔지니어의 더 많은 일을 할 수 있다면, 과연 얼마나 많은 엔지니어가 계속 필요할까?' 최근 한 프로젝트에서 AI 에이전트가 Jira 이슈를 자동으로 처리하고 PR까지 올리는 걸 보면서, '아, 이제 정말 단순히 코드를 잘 짜는 것만으로는 안 되겠구나' 하는 위기감을 느꼈습니다.
엔지니어링의 중심이 이동한다
하지만 여기서 중요한 사실이 있습니다. 코드를 타이핑하는 것은 언제나 일의 한 부분일 뿐이었습니다. 우리의 궁극적인 목표는 문제를 해결하는 것이었죠. 추상화가 진화할수록, 우리 작업의 초점도 함께 이동했습니다.
XML을 연결하는 대신 시스템을 설계했고, 빌드 도구를 설정하는 대신 제품을 만들었습니다. 상투적인 코드를 작성하는 대신 핵심 비즈니스 로직과 기능 구현에 집중했죠. API를 암기하는 대신 고객 문제를 해결하는 데 몰두했습니다.
한때는 '지름길'처럼 보였던 것이 이제는 새로운 '기준점(baseline)'이 되었습니다. 자동 완성, 프레임워크, 제너레이터, 클라우드 같은 도구들을 굳이 어려운 길을 가기 위해 포기할 개발자는 거의 없을 겁니다.
이 패턴이 계속된다면, AI 에이전트들은 또다시 그 문을 더 넓게 열어줄 것입니다. 더 많은 사람이 모든 하위 계층을 이해하지 않고도 소프트웨어를 구축하기 시작할 수 있게 되겠죠. 이런 가능성은 위협적으로 느껴질 수 있지만, 더 많은 사람이 소프트웨어를 만들 수 있도록 하는 것이 바로 소프트웨어 산업이 여기까지 올 수 있었던 원동력이기도 합니다.
그리고 이제 우리는 모든 코드를 직접 작성하는 데 시간을 덜 쓸 수 있습니다. 작업 단위도 변하고 있죠. 한 줄의 코드를 완성하는 것에서 컴포넌트를 생성하고, 나아가 에이전트에게 특정 기능 전체를 구현해달라고 요청하는 수준으로 말입니다. 이는 엔지니어링을 '없애는' 것이 아니라, '엔지니어링이 일어나는 지점'을 바꾸는 일입니다.
이 변화가 순탄하지만은 않을 것이고, 모든 엔지니어링 직무가 변함없이 살아남을 것이라고 약속할 수도 없습니다. 모든 세대의 엔지니어들은 도구가 변화함에 따라 '엔지니어란 무엇인가'를 재정의해야 했습니다. 이번에는 우리가 '코드를 생산하는 프로그래머'에서 벗어나, 우리가 구축하는 '시스템 전체에 책임지는 엔지니어'로서 스스로를 바라봐야 할 때일지도 모릅니다. 이런 변화 속에서 저 역시 '내가 하는 일이 과연 엔지니어링인가?'라는 질문을 던지곤 합니다. 하지만 결국 중요한 건 어떤 가치를 창출할 것인가에 대한 고민인 거죠.
이 모든 변화는 결국 첫 번째 '엽서'에서 던졌던 질문으로 우리를 되돌립니다. "만들 수 있다면, 만들어야 하는가?"
어쩌면 소프트웨어 엔지니어링의 역사는 더 좋은 코드를 작성하는 역사가 아니었을지도 모릅니다. 오히려 컴퓨터에게 '어떻게(how)' 할지 지시하는 것에서 우리의 관심을 떼어놓고, '무엇(what)'이 만들 가치가 있는지를 결정하는 방향으로 이동해 온 역사였을지도 모릅니다.
어쩌면 우리는 생각보다 오랫동안 이 순간을 준비해왔던 것 아닐까요?
다음 포스팅에서 만나요.
P.S. 저는 10년 넘게 사람들의 소프트웨어 구축을 돕는 일에 매달려 왔습니다. 이 글은 구축 도구가 구축의 '원칙'보다 더 빠르게 변할 때 어떤 일이 일어나는지에 대해 과거의 저에게 보내는 일련의 편지이자 일종의 기록입니다. 기술은 빠르게 진화하지만, 정작 중요한 질문들은 언제나 변치 않는다는 것을 다시금 상기시켜주는 글이 되기를 바랍니다.
원문: https://dev.to/jennapederson/the-abstraction-appears-to-include-us-2d47 수집일: 2026-08-06 01:16:25