대부분의 IT 회사가 무시하던 개발자 모범 사례가 AI 모범 사례로 재발명되는 모습이 재미있음
예전에는 코드 안에 문서를 두고, Jira 작업만 던지지 말고 프로젝트 전체 맥락을 알려주며, 장기 생산성을 위해 리팩터링하라고 하면 지루하게 여겼음
이제 같은 내용을 AI 문서는 코드와 CLAUDE.md에 두고, 프롬프트로 세세하게 통제하지 말며, AI 생산성을 위해 리팩터링하자고 하면 흥미롭게 받아들여짐

인간 동료보다 AI 에이전트가 같은 일을 일관되게 수행하도록 만들기 훨씬 쉬움
인간은 옳은 방법을 알아도 바쁘거나 집중력이 흐트러지지만, 에이전트는 지루한 작업에 싫증 내지 않으므로 인간에게 효과가 입증됐지만 꾸준히 적용하기 어려웠던 절차가 현실적으로 가능해짐
공통 명세를 바탕으로 구현과 테스트를 별도 에이전트가 작성하고 감사 에이전트가 검증하게 해 서로의 결과에 오염되지 않도록 했는데, 이는 IBM이 1980년대 인간을 위해 개발한 클린룸 공학을 AI로 폭넓고 일관되게 적용한 것임

이 글과 관련된 인물은 20여 년 전 책 《Refactoring》을 써서 해당 용어를 대중화한 Martin Fowler임
낡은 관행을 AI 유행에 맞춰 새것처럼 포장하는 게 아니라, 20년 넘은 모범 사례가 여전히 유효하다는 점을 근거와 함께 보여주는 것임

AI 이전과 이후의 큰 차이는 인간에게는 꽤 좋은 장기 맥락 관리 능력이 있다는 것임
에이전트는 세션마다 맥락을 새로 습득해야 하므로 모범 사례의 가치가 훨씬 커지고 효과도 즉시 나타남

AI 열풍 덕분에 원하던 개발자 경험 개선 작업에 예산을 받을 수 있게 됐지만, 그 이유가 잘못됐다는 점은 씁쓸함
그래도 한 시간 동안 CLI를 100번 실행시켜 새 플래그의 사용성을 시험할 수 있는 건 좋음

인간은 SharePoint의 낡은 문서, 회의 중 흘려들은 전체 맥락, 낮은 리팩터링 우선순위 속에서도 품질과 일정이 나빠질 뿐 어떻게든 결과를 만들어냄
반면 AI는 이런 기반이 없으면 매우 형편없이 수행하거나 아예 작동하지 않으므로, 건전한 엔지니어링 관행이 장기적 개선책이 아니라 필수 전제조건이 됨
실제 순효과가 전혀 없더라도 AI를 작업 흐름에 넣으면 제대로 된 개발 관행을 도입할 명분이 생긴다는 점에서는 유용함

이 글은 AI 도구가 실제로 어떻게 쓰이는지에 기반해 구체적이고 정량적으로 비판한다는 점이 좋음
실제 사용 사례 없이 사회적 위험을 막연히 논하는 글보다, AI가 무엇을 못하는지 측정값으로 보여주는 글이 훨씬 유익함
같은 이유로 Boko Haram 조직원을 인터뷰해 AI가 테러에 어떻게 활용됐는지 조사한 보고서도 인상적이었음

AI 없이 직접 하는 리팩터링을 정말 좋아함
눈에 보이는 변화는 없지만 지금 당장 성과가 드러나지 않을 웹사이트를 미래에 훨씬 다루기 쉽게 만든다는 데 만족감을 느낌
이미 정립된 패턴으로 해결된 문제를 과거의 기괴한 우회 코드가 다시 풀고 있는 모습을 찾아 모범 사례 쪽으로 옮기되 새 기술 부채를 만들지 않는 과정이 퍼즐처럼 즐거움
인증까지 모든 것을 엉성하게 직접 구현해 어려운 방식으로 내부 원리를 배웠고, 그 결과 앞으로 10년간 즐길 리팩터링 거리도 생겼음

Fowler의 《Refactoring》을 읽고 과학·연구용 코드에도 효과가 있을지 의심했지만, 불만스러운 코드 구조에 실험적으로 적용한 뒤 관점이 완전히 바뀌었음 코드베이스는 하나의 시스템이라는 말을 구체적으로 이해하게 됐고, 코드를 당기고 눌러볼 수 있는 연속적인 조직이나 그물처럼 높은 수준에서 보게 됨
AI가 이런 학습 과정을 없앨 수 있다는 점이 주니어 개발자 문제를 부각함. 직관을 얻으려면 직접 깊이 파고드는 수밖에 없으며, Naur가 40년 전에 경고했어도 이 교훈은 계속 잊힘

Windows 98 디스크 조각 모음 화면을 볼 때처럼 도파민 보상을 받기 때문일 수도 있음

그 감정은 장인으로서의 자부심임. 이해하는 사람에게는 설명이 필요 없고, 이해하지 못하는 사람에게는 어떤 설명도 통하지 않음

리팩터링 중 회귀를 막기 위해 테스트 스위트를 어느 정도 안전장치로 구축했는지 궁금함

여러 리팩터링 패턴과 실제 적용 사례를 공부하는 과정이 즐거움

에이전트가 리팩터링할 때는 인간 참여가 필수적이라고 봄
생성 모델이 초기 작업에 집중하며 놓친 부분을 검토 모델이 찾을 수는 있지만, 프로젝트 전체의 목적과 코드가 결합되는 방식을 실제로 이해해 중복이나 더 우아한 구조를 판별할 수 있는지는 의문임
코딩 에이전트에게 리팩터링을 맡기는 일은 외상외과 의사에게 운동 능력을 높여달라고 하는 것과 비슷하며, 제대로 하려면 전체론적 관점이 필요함
큰 파일을 여러 파일로 나누는 것만으로는 피상적 리팩터링에 그침. 어떤 코드가 함께 있어야 하고 무엇을 유틸리티 함수로 추출할지에 대한 이론이 없다면 인수분해가 아니라 큰 수를 작은 수로 쪼갠 뒤 다시 더하는 것에 가까움
에이전트는 API에서 이미 가져오는 값을 다시 저장하고 계산하는 시스템을 만들기도 하지만, 인간은 프로젝트 전체를 보면서 JSON의 특정 키에 필요한 데이터가 이미 있다는 사실을 정밀하게 찾아낼 수 있음

현재 LLM도 특정 코드 구간에 구체적인 리팩터링을 지시하면 충분히 잘 수행함. 예를 들어 데이터 클래스 대신 functools.partial로 Command 패턴을 구현하라는 복잡한 요구도 처리 가능함
파일 경계는 논리적 하위 시스템의 경계를 나타내 추론을 쉽게 하며, 다른 파일의 내용은 기본적으로 불투명하게 취급한다는 개념도 학습 데이터에 풍부함
이 구조의 이점은 인간 인지의 우연한 특성만이 아니라 객관적인 측면도 있다고 봄

인간이 옆에서 방향을 설명하는 방식으로 몇 달 걸릴 리팩터링을 약 일주일 만에 대부분 끝냈음
리팩터링 경력과 타인의 코드베이스를 다룬 방식, 원래 설계자로서 과거와 현재의 의도를 설명할 수 있었던 점이 도움 됐음
의존성 취약성이 적고 LLM이 다루기 쉬운 비주류 언어였으며, JavaScript와 Python 쪽 편향을 제거한 뒤에는 작업 속도가 크게 붙었음
여러 인기 언어로 스크립트를 작성하되 환경 요구에 따라 모두 JVM에서 실행하는 JSR-223 프로젝트였음: https://en.wikipedia.org/wiki/Scripting_for_the_Java_Platform

에이전트가 리팩터링을 못한다는 평가는 낡았으며, 지금은 매우 뛰어남
이 채용 시장에서는 최신 최전선 모델 기반 코딩 에이전트를 사용하고 그 능력과 한계를 정확히 알아야 하며, 면접에서 반대 평가를 내놓으면 탈락 사유가 될 수 있음

간결한 맥락은 토큰 소비만 줄이는 것이 아니라 추론을 개선하고, 한 맥락에 더 많은 계층을 넣어 지능적으로 다룰 수 있게 함
좋은 추상화를 향한 리팩터링은 시험한 사례뿐 아니라 내삽·외삽된 사례에서도 맞을 가능성이 높은, 더 잘 일반화되는 소프트웨어를 만듦
이를 뒷받침하는 정보이론 및 베이즈 수학이 있으며, 경제적·에너지 효율이 높은 소프트웨어가 더 정확해지는 것은 절묘한 우연처럼 보임
핵심은 코드의 엔트로피를 줄이는 것임

세계와 우주의 어디에서든 엔트로피 감소는 무언가를 건설하는 일로 볼 수 있음

인간 가독성을 목표에서 버리고 토큰 소비 감소만 목적 함수로 삼으면 어디에 도달할지 알기 어려움
LLM은 이미 적은 맥락으로도 의미를 꽤 잘 추론함

데이터가 제시된 점이 흥미로우며, 잘 분리된 코드에서 LLM이 크게 이득을 보지만 스스로 그런 코드를 만드는 능력은 그다지 뛰어나지 않다는 내 체감과 일치함
대부분의 인간 개발자도 비슷할 것임

별도로 엉성한 코드 제거 시간을 예산에 넣고 있으며 지금도 바로 옆 창에서 그 작업을 하고 있음
전체적으로 AI의 이득은 크지만 정리 시간도 필요하고, 여전히 모든 줄을 읽어야 한다고 봄
다른 팀의 진행을 막지 않으려고 일부 검토를 미뤘다가 나중에 평소보다 큰 기술 부채를 갚고 있는데, 먼저 병목을 푸는 편이 가치 있었음
AI는 모든 의미에서 기술 부채를 더 쉽게 끌어다 쓰게 했으며, 안내만 잘하면 부채 해소도 꽤 잘함. 다만 결과는 사람마다 다름: https://news.ycombinator.com/item?id=49035455

기본 상태에서는 같은 결과를 봤지만, 리팩터링 방향을 구체적으로 잡아주면 더 잘 분리된 코드를 만들 수 있었음
잘 구성된 코드의 예시나 오픈소스 저장소를 통해 해야 할 것과 하지 말아야 할 것을 보여주면 큰 도움이 됨

리팩터링의 경제적 이익 대부분은 토큰 절약보다 인간의 이해도 향상에서 나옴
새벽 3시 장애 호출을 더 빨리 해결하고, 운영 환경에 들어가는 버그를 줄이며, 경쟁사보다 빠르게 출시할 수 있음
무엇보다 시스템을 이해하면 책임과 소유권을 기꺼이 맡게 되어 문제가 생겼을 때 더 빨리 고치고 개선할 부분에도 적극적으로 뛰어들게 됨

글이 martinfowler.com에 실렸지만 Martin이 쓴 것은 아니며, 저자는 Thoughtworks CTO인 Giles Edwards-Alexander로 표시돼 있음

실제 핵심은 절약액이 겨우 수십 센트 수준이라는 것임
Sonnet 5 가격을 MTok당 3달러로 계산하면 데이터 접근 계층을 건드리는 향후 변경에서 절약되는 금액은 39.7센트임
OpenAI의 가격 인하와 개방형 모델, 장기적인 토큰 가격 하락을 고려하면 시간당 100달러쯤 하는 시니어 개발자가 리팩터링을 안내하는 비용과 맞지 않을 수 있음

에이전트가 만든 코드는 에이전트만 읽고 이해할 수 있을 정도로 거대한 덩어리가 됐고, 이는 기능인지 버그인지 창발적 속성인지보다 현실 자체가 중요함
AI 도구로 생성한 코드를 다루기 위해 다시 AI 도구에 종속되고 있음
다만 인간도 이미 끔찍하게 큰 파일과 모노리포를 만들었고, LLM 덕분에 이를 편집하고 리팩터링하는 일이 비로소 감당 가능해짐
코드베이스가 인간이 이해하기엔 너무 크고 엉망이 된 상황에서 LLM이 우리를 구할 수도 있으며, 개인적으로 거대 파일을 혐오하지만 Fowler식 정리 원칙은 더는 중요하지 않을 수도 있어 씁쓸함

에이전트 코드가 에이전트만 이해할 수 있다는 말은 근본적으로 사실이 아니며, 그렇게 느낀다면 LLM 사용법이 잘못된 것임

나쁜 코드는 원래부터 있었지만 AI는 나쁜 채용의 피해 범위를 1,000배 키우는 새로운 문제임
평균적이거나 가끔 잘하는 직원조차 예전에는 회사 절차 때문에 못 하던 일을 번개처럼 실행하게 만들어 오히려 나쁜 직원으로 바꿀 수 있음

LLM이 100% 작성한 코드베이스도 읽거나 원하는 위치를 찾는 데 문제가 없었고, 직접 작성했을 때보다 어렵지 않았음

에이전트가 만든 코드가 인간이 만든 최악의 코드보다 나쁜 경우는 본 적이 없음
에이전트가 거대한 파일이나 함수를 만들면 그러지 말라고 지시하기만 해도 따름

리팩터링은 건강한 개발팀을 보여주는 가장 좋은 징후 중 하나라고 봄
리팩터링 자체의 이점도 있지만, 제품 책임자나 기능 작업표에서는 그 가치가 잘 보이지 않음
팀이 전체 소프트웨어의 건강을 위해 리팩터링한다면 개발자가 좋은 소프트웨어를 위한 제안을 편하게 내고, 그 제안이 진지하게 받아들여진다는 뜻임
소프트웨어 부패는 팀이 고품질 소프트웨어라는 비전을 실현할 동기나 권한이 없을 때 가장 심해지며, 팀이 탁월함에 대한 판단을 따를 수 있다면 대체로 좋은 신호임
물론 Ruby, Node, Rust를 거쳐 다시 에이전트 친화적 기술로 전면 재작성하는 식의 과잉도 있지만, 기업 환경에서는 개선할 허가가 없다고 느끼는 팀이 훨씬 더 흔함