요약
에이전트 코딩으로 코드를 고치는 비용이 무너지면서, 코드는 깎는 돌이 아니라 빚는 점토가 됐습니다.
개발자 알베르토 데니아의 글입니다. 그는 큰 변경에 철거와 비계, 치밀한 계획이 필요하던 2025년 11월 이전을 '코딩의 중세'라고 부릅니다. 에이전트 코딩(AI 에이전트가 코드를 직접 쓰고 고치는 방식)이 그 시대를 끝냈다고 봤습니다.
왜 중요한가
- 설계를 미리 굳히지 않고 크게 빚어 본 뒤 다듬는 개발 방식이 가능해집니다.
- 변경은 싸졌지만 어떤 변경이 옳은지 고르는 판단력은 여전히 사람의 몫으로 남습니다.
- 그 판단을 언제, 얼마나 넣을지에 따라 일하는 방식이 장인과 공장으로 갈립니다.
핵심 내용
- 조각가처럼 큰 덩어리를 잡아 시험하고, 버리거나 고친 뒤 세부를 다듬을 수 있다고 했습니다.
- 장인 방식은 사람이 반복마다 코드의 모양까지 보고, 화면만 보고 판단하면 바이브 코딩이라고 선을 그었습니다.
- 그 예로 자신의 마크다운 편집기에 합계를 내는 계산 블록을 탄산음료 반 캔 마실 시간에 붙였습니다.
- 공장 방식은 명세, 생성기, 검증기(테스트·평가·리뷰 에이전트)로 짠 파이프라인에 맡기고 판단을 설계 단계로 옮깁니다.
- 공장은 CRUD 엔드포인트(데이터 생성·조회·수정·삭제 API) 추가처럼 반복 패턴이 뚜렷한 일에 맞고, 두 방식은 서로 보완한다고 했습니다.
HN 반응
- 코드는 원래 고칠 수 있는 것이었다는 지적에, 요점은 몇 달 걸리던 리팩터링(코드 구조 개선)이 며칠로 줄어든 속도라는 반론이 나왔습니다.
- 시간이 드는 건 다시 테스트하고 예전 교훈을 되찾는 일이라는 회의론과, AI로 대규모 리팩터링과 SaaS 교체에 성공했다는 경험담이 맞섰습니다.
코드는 원래부터 유연해야 하는 것이었습니다. 코드는 자산이 아니라 부채라는 말이 오래전부터 있었던 것도 그래서입니다. 진짜 자산은 그 코드가 만들어 내는 데이터입니다. 코드야 언제든 다시 짜면 됩니다.
우리는 대체로 코드가 굳어서 부서지도록(이 비유에 맞춰 말하자면, 말라서 바스러지도록) 내버려 두는 데 아주 서툽니다. AI는 이 문제를 해결해 주지 않습니다. 오히려 AI가 만든 코드가 너무 다루기 힘들어져서, LLM조차 차라리 버리고 처음부터 다시 시작하는 편을 택하는 상황을 보게 될 거라고 확신합니다.
코드가 유연했던 건 코드를 깊이 이해하는 개발자에게만 해당되는 얘기였습니다. 제 경험상 그런 개발자는 정말 드물었습니다. 이유 중 하나는, 남이 짠 코드를 몇 줄 고친다고 인정받는 일은 없는 반면 "우리 조직의 이 문제를 풀려고 새 라이브러리/앱을 만들었습니다!"라고 하면 인정받기 때문이라고 봅니다.
제 기억으로는 이게 원래 개발자라는 직업이었습니다. 벌써 몇 년 전 일이네요.
에이전트가 코딩을 하게 된 지금에 와서 우리가 옛날 코딩을 미화하는 것 같습니다.
평범한 개발자를 얼간이 취급하는 건 데이크스트라부터 FizzBuzz까지 이어진 일종의 가내수공업이었습니다.
저는 그 전에도 미화했어요. 지난 15년 사이에 사회가 개발자를 보는 시선이 너드 루저에서 부자로 바뀐 데는 이유가 있으니까요. 15년 전에 어떤 여자가 저한테 "너는 다르네, 개발자는 루저일 줄 알았는데 그렇지 않네"라고 했던 게 기억나요.
뭐, 너드들은 자기 부류를 (다시) 루저로 만드는 법을 확실히 알고 있죠.
맞아요. AI가 나오기 전을 떠올려 보면, 코드의 90%는 요즘 AI가 쓰는 것보다 더 심한 슬롭이었어요.
슬롭이 아닌 부분은 유명한 오픈소스 프로젝트 몇 개 정도였고요.
대형 IT 기업 대부분에 이런 내부 농담이 있었잖아요. "X는 절대 오픈소스로 못 내놔. 못 해서가 아니라 너무 창피해서."
그렇긴 한데, 직접 만든 프로젝트와 물려받은 프로젝트는 적어도 생산성을 내기까지 걸리는 시간이 확실히 달랐습니다.
물려받은 프로젝트를 이해하고 유지보수하는 능력이 새 그린필드 프로젝트를 만드는 능력보다 더 값집니다.
정말 맞는 말입니다. 코딩을 장인정신이라고 부르거나, 새 프로젝트에서만 훌륭한 코더인 사람을 스스로 대단한 코더라고 여기는 건 분명 잘못된 일입니다.
진짜 훌륭한 코더는 오래된 레거시 프로젝트를 좋아합니다. 도전적이고, 예측할 수 없고, 문서도 없으니까요. 그걸 파악해 내면 신이 된 기분이 듭니다.
완벽한 그린필드 프로젝트를 시작해서 첫 주에 멋진 코드를 쓰는 건 컴공 신입생이라면 누구나 가진 기술입니다. 그건 문제 영역이 아니라 이미 해결된 문제입니다.
하지만 인수합병을 다섯 번 거치고, 인프라도 업종도 언어도 문화도 바뀌는 와중에 10년을 내리 해낸다면요? 그런 사람은 희귀종입니다.
더 간단히 말하면, 쉬운 일로 자신을 평가하지 말고 어려운 일로만 평가하세요. 그러면 쉬운 일은 우습게 보입니다.
저도 겪어 봤는데, 문제는 윗사람들이 그걸 보상해 주지 않는다는 겁니다. 낡은 걸 계속 살려 두는 일은 실력을 갈고닦는 데는 도움이 되지만, "이력서 주도 개발"이 완전히 지배하는 문화에서는 손해입니다.
소득으로서의 가치로 보면 컨설턴트에게는 아마 맞는 말일 겁니다. 하지만 대기업 직원에게는 그다지 맞지 않습니다.
그리고 문제는 코드 자체가 아닌 경우가 많습니다. 코드는 완벽하게 이해하고 쉽게 고칠 수 있습니다. 진짜 문제는 늘 "왜"를 알아내는 일입니다. 그래야 새 변경 요청을 처리하다가 체스터턴의 울타리를 무심코 치워 버리는 일이 없습니다.
분명 차이는 있습니다만, 제 기억으로는 개발자라면 둘 다 해낼 수 있었습니다. 다시 말하지만, 꽤 오래전 일입니다.
대부분의 개발자는 코드를 이해한 적이 없었습니다. 저는 수천 명과 일해 봤는데, 대부분은 코드를 쓰고 뭔가를 납품은 했을지 몰라도 아무것도 이해하지는 못했습니다.
저는 그런 경력을 겪지 않아서 정말 다행입니다. 여러 곳에서 아주 뛰어난 개발자들과 일했거든요. 둔한 사람은 애초에 뽑지 않았습니다.
납품한 결과물이 기대한 대로 기능적으로 동작했습니까? 그렇다면 그 코드 작업을 하는 데 필요한 만큼은 이해한 겁니다. 코드베이스 전체를 이해할 필요는 없고, 지금 하는 작업과 관련된 부분만 이해하면 됩니다.
저는 지금도 사업체를 돌리는 시스템을 통째로 만들었습니다. 코드는 한 줄도 빠짐없이 이해하고 있었습니다.
당신의 경험이 일반적인지는 잘 모르겠네요.
동의하지 않습니다. 특히 순수 함수형 프로그래밍(FP)을 쓰면, 잘 설계된 코드는 더 유연할 수 있고 실제로 그랬습니다. 사람들은 지저분한 추상화와 OOP에서 벗어나 순수 함수와 합성이라는 개념 쪽으로 계속 옮겨 갔고, 그 결과 더 견고하고 유연한 소프트웨어가 만들어졌습니다.
그런데 이제는 견고하고 유연한 코드를 목표로 삼는 대신, 다들 손을 놓고 "원래 다 엉망이었잖아, 그냥 토큰이나 더 퍼붓자"라고 말하고 있습니다.
맞아요. 사람들이 "타입 같은 건 잊어버려야 속도가 나니까 자바스크립트랑 파이썬을 쓰겠다"고 하더니, 결국 돌아와서 두 언어에 타입과 함수형 프로그래밍을 다시 발명했잖아요. 그러고는 이제 뒤죽박죽 쌓인 혼란에 너무 당황해서 LLM에 백기를 들고 있고요.
개발자가 그냥 세간의 유행만 따라왔다면, 이해 수준의 바닥이 워낙 낮으니 이게 최선의 탈출구라는 결론에 이르는 것도 이해는 돼요. 미로 입구 주변을 며칠째 빙빙 돌다가 마침내 문 근처에 AI 상인이 나타나니, 길을 차근차근 그려 가며 빠져나가는 대신 "그래, 이 미로를 나갈 유일한 방법은 저 상인한테 돈을 주고 그 근사한 로봇청소기에 실려 나가는 거야"라고 하는 격이죠.
이기적인 관점에서 보면 저는 괜찮아요. 가까운 시일 안에 대체되지 않을 기술을 쌓아 왔고, 같은 기간에 대부분의 사람들은 실력이 퇴보할 테니까요. 유일한 단점은 같이 협업할 수 있는 사람들의 범위를 더 좁혀야 했다는 거고요.
OOP를 덜 쓰면 비즈니스 로직은 어떻게 짜나요? 저는 그쪽에는 FP가 엉망이던데요.
어떤 종류의 애플리케이션에서 말하는 비즈니스 로직인가요?
가능한 접근법 겸 설명 하나를 소개합니다.
https://pragprog.com/titles/swdddf/domain-modeling-made-functional/
이해도가 낮은 사람들이 수년째, 그것도 아주 많이 코드를 고쳐 왔습니다. 물론 그게 잘 풀린다는 뜻은 아니지만요.
오해하신 것 같습니다.
요점은 이전에는 코드를 크게 바꾸려면 몇 달간 리팩터링해야 할 수도 있었다는 겁니다. 그만큼 큰 추가 수익이 정당화해 주지 않는 한 큰 변경은 아예 고려조차 되지 않았습니다. 일단 아키텍처를 설계하고 나면 사실상 거기에 묶여 있었죠.
이제는 예전에는 아예 비현실적이던 변경이 완전히 현실적입니다. 예전에 6개월 걸렸을 리팩터링이나 마이그레이션도 하루면 동작하는 버전을 만들고, 며칠 더 QA하면 됩니다. 이 글이 말하는 게 그겁니다. 코드는 더 이상 돌이 아니라 찰흙이라는 거죠. 예전에는 상상도 못 하던 방식으로 빠르게 바꿀 수 있습니다.
이건 코드가 부채냐 자산이냐 하는 개념과는 아무 상관이 없습니다. 그건 완전히 별개의 얘기입니다.
그건 환상이에요.
코드를 바꾸는 데 시간이 걸리는 이유는 바꾸는 작업 자체가 오래 걸려서가 아닙니다.
테스트를 전부 다시 해야 하고, 이전 시도에서 힘들게 얻었지만 명세에는 제대로 적히지 않았던 교훈들을 전부 다시 배워야 하거든요. 시간은 거기서 들어갑니다.
저는 지난 6개월 동안 운영 중인 시스템에서 아주 특수하고 규모가 큰 리팩터링을 여러 건 해냈는데, 전부 AI 도구 덕분에 가능했습니다. 하나하나 손으로 하면 몇 달이 걸렸을 변경이고, 고객 대상 업무에서 유료 개발자 시간을 빼앗는다는 이유로 윗선의 승인도 절대 받지 못했을 겁니다.
그 덕에 시스템이 안정됐고, 미완성이던 아이디어가 구체화됐으며, 테스트 역량이 확대됐고, 개발자 경험 중심의 새 도구들이 도입됐고, 민감한 시스템들이 앞으로 쓰기 더 유연하게 리팩터링됐습니다. 탈 나기까지 몇 년, 고치는 데 몇 달이 걸릴 극히 특수한 기술 부채도 처리했고요.
환상과는 거리가 멉니다.
사용 사례에 따라 다를 수 있겠죠. 비행기에서 생명을 위협하는 버그를 다루는 거라면 말씀이 맞습니다.
하지만 사내 할 일 관리 도구를 LLM에게 다른 언어로, 더 나은 설계에 최신 소프트웨어 스택으로 다시 짜게 하는 거라면, 네, 이건 더 이상 환상이 전혀 아닙니다. 저희는 한 달 만에 SaaS 도구 대부분을 걷어냈습니다. Keycloak에 wireguard 뒤에 pocketbase 백엔드까지 갖추고, 저희 회사 디자인에 정확히 원하는 기능만 넣어서요. 첫날부터 흠 없이 잘 돌아갑니다.
설마 Keycloak을 AI 도구로 며칠 만에 다시 짜서 업무나 프로덕션에서 쓰고 계신 건 아니길 진심으로 바랍니다.
만약 그랬다면 지금 당장 팀 회의를 소집하세요. 아무한테도 말하지 말고 그냥 고치세요. 일이 터지면 정말 크게 터집니다.
아뇨, 사내 도구가 OIDC와 백엔드로 쓰는 부분을 제가 짠 겁니다. Keycloak을 다시 짤 필요는 없어요. 저는 Keycloak이 아주 마음에 들거든요.
그리고 제가 쓴 건 사내 도구 얘기였어요. 외부에 공개되는 애플리케이션이 아니라요. 그건 제 취향엔 좀 과하겠죠.
그건 이미 지난 얘기예요. 그냥 현실도피죠. 다들 "그래도 보안이 허술하잖아"라고 스스로를 달래고 있는데, 그건 예전에는 사실이었어요. 지금은 AI 모델이 사람보다 해킹을 더 잘해요. 자기 코드를 AI로 레드팀 해 보면, OIDC를 직접 구현하려는 어떤 개발자가 하는 것보다도 더 나은 모의 침투 테스트 결과가 나옵니다.
그리고 솔직히 말해서... Keycloak 설정해 보신 적 있어요? 그거 "뭐든 다 하는 앱"이 거대하게 덩치만 키운 거잖아요. 그쪽이 공격 표면이 더 좁을 거라는 생각은 사실상 환상이에요.