자동화된 프로그래밍과 코딩 에이전트의 등장이 소프트웨어 개발에서 불필요한 복잡성을 걷어내고, 진짜 엔지니어링을 다시 가능하게 만들고 있다는 주장.
URL: https://blog.alaindichiappari.dev/p/software-engineering-is-back
나는 글을 자주 올리는 편이 아니다. 하지만 글을 올릴 때는, 내가 보고 있는 것을 다른 사람들이 소리 내어 말하지 않는다고 느낄 때다.
나는 제품을 맨바닥부터 만들고 있다. “Next.js 템플릿 하나 띄웠다” 같은 의미의 맨바닥이 아니다. 네트워크 설정부터 제품 디자인, 가격 결정까지. 정말로 엔드투엔드다. 그리고 나는 프런티어 모델과 코딩 에이전트를 이용해 매일 몇 시간이고 이 일을 하고 있다. 이 프로젝트에서도, 내 정규직 업무에서도 마찬가지다. 나는 혼란과 과대광고에서 가능한 한 멀어지려고 하면서, 실제로 가치 있는 것이 무엇인지 매우 강하게 걸러내고 있다.
2025년 12월 이후로 상황은 극적으로, 더 좋은 방향으로 바뀌었다. 많은 사람이 알아차렸다. 하지만 올바른 결론을 내리는 사람은 많지 않다.
Antirez는 이를 “자동화된 프로그래밍(automated programming)”이라고 부르는 것을 좋아하는데, 나는 그 프레이밍이 정말 마음에 든다. “바이브 코딩(vibe coding)”이라는 피상적이고 거의 폄하에 가까운 라벨보다 본질을 훨씬 잘 담아낸다. 자동화는 인류 역사에서 대부분의 노동과 문화적 혁명의 핵심이었다. 인쇄기, 방직기, 조립 라인. 이번도 크게 다르지 않다.
내 일의 대부분은 여전히 남아 있다. 내가 만들고 싶은 것의 중요한 모든 측면을 깊이 생각해야 한다. 아키텍처, 트레이드오프, 제품 의사결정, 새벽 3시에 너를 물어뜯을 엣지 케이스들. 사라진 것은, 코드 한 줄 한 줄을 전부 타이핑하는 찢기고 지치는 수작업 노동이다.
지금 시점에서 모델과 도구는, 깨끗하고 집요하게 잘 세팅된 환경에 놓이면, 진짜로 차이를 만든다. 나는 벽돌을 하나하나 쌓고 모르타르를 바르는 지겨운 행위를 하지 않고도 건축가가 될 수 있다. 천을 한 조각 한 조각 자르고 꿰매는 행위를 하지 않고도 옷을 디자인할 수 있다. 하지만 이 모든 것을 할 수 있는 이유는, 내가 20년 동안 직접 벽돌을 쌓고 모르타르를 바르고 재단하고 바느질해 온 경험을 등에 지고 있기 때문이다. 마음에 들지 않으면, 들어가서 이해하고 원하는 대로 고칠 수 있고, 다음에는 내 세팅이 원하는 대로 동작하도록 한 번에 지시해 둘 수 있다.
특히 자동화된 프로그래밍은 내가 필요한 도구를 너무 빠르게 만들 수 있게 해 주는데, 지구상에 존재했던 모든 대장장이가 나를 깊이 부러워할 정도다. 마침내 머릿속에 있는 것에 정말 집중할 수 있다. 마침내 그들이 떠올린 예술에 더 많은 시간을 쓰고, 대장간의 땀에는 덜 시간을 쓰게 된다.
이 생각이 내 머릿속에서 굳어진 지 몇 달이 됐다. 너무나 분명해서, 왜 모두가 이걸 세상에 대고 소리치지 않는지 진심으로 이해가 안 된다.
우리는 마침내 그 모든 중간 작업을 없앨 수 있다. 지난 몇 년 동안 눈 감고 받아들였던 그 쓰레기 같은 적응 레이어(adapting layer) 말이다. 소프트웨어 엔지니어링을 완전히 오염시킨, 특히 웹/모바일/데스크톱 개발에서의 방대한 프레임워크, 라이브러리, 툴링. 의미 있는 것을 추상화하지도 못하는 추상화가 겹겹이 쌓여 있고, 애초에 없어야 했던 문제를 해결한다며 등장해, 고친다고 주장한 문제 하나당 열 개의 새 문제를 만들어낸다.
무슨 일이 벌어졌는지 생각해 보자. 우리 업계는 소프트웨어를 만드는 진짜 복잡성을 보고도, 생각을 더 날카롭게 다듬는 대신, 남의 사고를 기성품으로 사왔다. 마치 부러진 다리를 비단으로 감싸듯, 모든 것을 프레임워크로 감쌌다. 보기엔 좋아 보인다. 다리는 여전히 부러져 있다.
내 생각에, 프레임워크는 (스스로 내세우는 목표 말고) 세 가지 문제를 해결한다. 두 개는 명시적이고, 하나는 명백하지만 아무도 말하지 않는다.
“단순화”. 소프트웨어 엔지니어들은 스스로 설계하는 것을 두려워한다. 시간이 들더라도 목표에서 시작해 거꾸로 내려오며 자신의 아이디어에 딱 맞는 옷을 만들기보다는, 남이 만든 구조를 받아들인 뒤 제품에 억지로 끼워 맞추는 쪽을 택한다. 마치 어떤 건축가가 다른 건축가의 설계도를 맥락, 필요, 지형, 새로운 기술적 가능성을 무시한 채 맹목적으로 적용하는 것과 같다. 우리는 우리가 만드는 제품에 대한 정신 모델을 날카롭게 다듬어 복잡성을 줄이기보다, 만능으로 통하는(one size fits all) 설계를 사서 어디에나 적용해 버렸다. 그건 단순화가 아니다. 지적 항복이다.
자동화. 이건 내가 그나마 어느 정도 이해하고 수긍할 수 있는 유일한 지점이다. 보일러플레이트는 지루한 일이다. 나는 그걸 싫어한다. 그리고 특히, 중복되지만 필요한 코드를 만드는 일을 줄이기 위해 라이브러리를 쓰고, 그 라이브러리를 공부하고, 업데이트를 따라가고, 취약점을 계속 신경 써야 하는 상황을 정말 싫어한다. ORM, CRUD 관리, 코드 생성, API 문서화 같은 것들을 떠올려 보라. 아무도 하고 싶지 않지만 누구나 해야 하는 잡일(grunt work)이다. 그건 인정하자. 하지만 이 생각을 붙잡고 있어라. 바로 이 지점에서 모든 것이 바뀐다.
인건비. 이건 조용한 이유다. 아무도 컨퍼런스 슬라이드에 올려놓지 않는다. 회사 입장에서는, Google, Meta, Vercel이 네가 제품을 만들고 코드를 배포하는 방식을 대신 결정해 주는 편이 훨씬 낫다. 그들의 프레임워크를 채택하라. 락인 비용을 지불하라. 호스팅, 배포, 저장을 위한 그들의 클라우드 관리 솔루션에 매혹되어라. 그러면 엔지니어링과는 무관한 기능을 하나 잠금 해제한다. 더 이상 소프트웨어 엔지니어를 채용할 필요가 없어진다. React 개발자를 채용하면 된다. 교육할 필요 없다. 플러그 앤 플레이. 대체도 쉽다. 누군가 다른 사람이 설계한 기계의 톱니바퀴가 되어, 누군가 다른 사람이 아키텍처한 시스템을 유지보수하고, 누군가 다른 사람이 정의한 문제를 푼다. 이건 엔지니어링이 아니다. 운영이다.
내 의견으로는, 진짜 소프트웨어 엔지니어링이 다시 돌아왔다.
나는 그저 감정적으로만 말하는 게 아니다. 나는 이미 2년 넘게 거의 흠잡을 데 없이 이런 방식으로 개발해 왔다. 하지만 진짜 혁명은 분명히 작년에 일어났고, 2025년 12월 이후로는 주의 깊게 보는 사람이라면 누구나 자명하게 알 수 있다. 앞으로는 더더욱 그럴 것이다.
우리는 다시 쓸모없는 복잡성을 걷어내고, 우리 아이디어/기능/제품의 진짜 복잡성, 환영할 만한 복잡성에 집중할 기회를 얻었다. 중요한 복잡성. 실제로 “너의 것”인 복잡성 말이다.
자동화와 보일러플레이트를 극복하는 비용은 이제 그 어느 때보다도 싸졌다. 나는 사실상 같은 코드를 두 번 쓰지 않는다. 필요한 작은 도구를 즉시 만들어낸다. 목적에 맞게, 당면한 문제의 형태에 정확히 맞게. 멋진 모노레포 매니저도 필요 없다. 간단한 Makefile 하나로 내 사용 사례의 99%에서 내 필요의 100%를 커버한다. 언젠가 일이 정말 복잡해지면, 그리고 정말 복잡해진다면, 그때 가서 생각할 것이다. 하지만 그 전에는 단 1초도 아니다. 이게 엔지니어링이다. 컨퍼런스 무대 위 누군가가 “언젠가 겪게 될” 거라고 말한 문제를 푸는 게 아니라, 지금 네가 가진 문제를 푸는 것.
에이전트는 기본 도구에 대해서는 정말 잘 준비돼 있다. 몇 달 된 도구가 아니라, 문자 그대로 수십 년 된 도구들 말이다. Bash는 1989년에 태어났고, 나보다 두 달 먼저였다. 지금 시점의 가장 평범한 모델조차도 Bash를 세상 어떤 사람보다 잘 안다. Bash는 범용 어댑터다. 코딩 에이전트들이 복잡하고 비싼 MCP 설정에서 벗어나, Bash를 통해 문자 그대로 “세상”과 상호작용하는 단순한 에이전트 루프로 이동하는 건 우연이 아니다. 가장 오래된 도구가 가장 미래지향적(future proof)인 것으로 드러났다. 귀 기울일 마음이 있다면, 여기엔 교훈이 있다.
진지하게 생각해 보라.
왜 대부분의 사용 사례에서, 쓸모없고, 비싸고, 결함이 있고, 종종 취약한 프레임워크와 그에 딸려오는 라이브러리들의 행렬이 필요하단 말인가? 너는 그 기능의 10%만 쓸 가능성이 큰데도 말이다. 그에 따르는 모든 비용까지 포함해서. “가장” 덜 비싼 비용은 운영 비용이다. 예를 들어 Next.js 버전에서 또 치명적 취약점이 발견되어 전부 업데이트해야 하는 일 같은 것. 가장 비싼 비용은 너의 디자인 선택(Design Choices)에 대한 비용이다. 보이지 않는 비용. 너무 오래 지불해서, 자유가 어떤 느낌이었는지 잊어버릴 정도로 매일 지불하는 비용이다.
이 트레이드오프를 계속 받아들이면, 너는 소프트웨어 엔지니어링에서 수십 년 만에 본 가장 큰 기회를 놓치는 것뿐만 아니라, 하이퍼스케일러가 너를 위해 결정해 놓은 것을 또다시 사들이는 너 자신의 게으름을 인지하지 못하고 있는 것일지도 모른다. Google과 Meta와 Vercel이 네 건축가가 되고, 디자이너가 되고, 사색가가 되도록 내버려두는 것이다. 그리고 그 대가로 너는 그들의 운영자가 된다.
도구는 이미 있다. 모델도 이미 있다. 혁명은 이미 일어났는데, 대부분의 사람은 아직도 낡은 집을 꾸미고 있다.
부러진 다리를 비단으로 감싸는 일을 멈춰라. 너의 것인 무언가를 만들기 시작하라.