몇 달마다 AI 개발 ‘공장’을 시험하고 다듬어 봤지만, 코드 품질이 나빠질수록 모델의 수정 능력도 떨어져 결국 진척이 멈추는 패턴을 겪음.
코드를 더는 읽지 않는다는 사람들이 뭘 만드는지 정말 이해하기 어려움. 프롬프트만 잘 쓰면 된다는 사람들의 코드를 보면 끔찍하고, 개념 증명 단계를 거의 벗어나지 못한 경우가 많음. 팀 전체가 변경이나 운영 장애에 대응하지 못할 만큼 느려지는 모습도 봤고, 주변에서도 흔히 겪는 일임.
이런 기법을 적극적으로 홍보하려면 이제 성과로 입증해야 함. 내가 본 열성 지지자들은 거의 무제한으로 토큰을 쓰면서 무언가를 판매하고 있었음. 단순한 시스템이나 성숙한 코드베이스의 좁은 작업을 제외하면, 홍보할 상품이 없는 엔지니어가 실제 운영 시스템에서 성공하는 경우는 좀처럼 찾기 어려움.

속도 저하는 나중에 나타나고, 비용 일부는 동료에게 전가됨. 코드 품질이 어느 정도 괜찮은 프로젝트에서 에이전트에 전적으로 맡기고 코드 읽기를 중단하면 일시적으로 빨라질 수 있음. 자신과 팀이 그 방식에 빠져들기에는 충분한 기간임. 도박에서의 ‘초심자의 행운’과 비슷함.

가동 시간이 크게 중요하지 않은 개인 프로젝트에서는 모듈 경계·API·스키마 위주로 검토하는 방향으로 옮겨가고 있음. Bevy 기반 멀티플레이어 게임으로 서버, 게임, 콘텐츠 빌드 파이프라인, 방대한 편집·제작 도구까지 합쳐 아마 15만 줄이 넘는 코드베이스임.
최대한 모듈화해 잘못된 코드가 다른 곳으로 퍼지지 않게 하고, 가끔 특정 모듈을 자세히 살펴 정리하거나 아예 다시 작성함. 다른 사람이 의존하는 시스템에 이렇게 무심하게 접근하지는 않겠지만, 개인 프로젝트에서는 위험을 제한하면서 빠르게 진행할 수 있음. 필요한 시점에 모듈마다 다른 속도로 성숙시킬 수 있어, 나쁜 코드 때문에 개발 전체가 멈추는 일 없이 규모를 키우는 데 도움이 됨.

검토 가능한 PR 규모로 변경을 요청하고, 설계 규칙이 뚜렷한 프레임워크를 기반으로 삼으며 테스트를 명시적으로 요구하면 ‘코드를 읽지 않는’ 접근도 가능하다고 봄. 기존 테스트가 있으면 모델도 대체로 알아서 추가함.
그래도 나는 결과를 읽고, 먼저 기존 테스트가 수정됐는지 확인함. 예상치 못한 테스트 변경은 위험 신호로 봄. 요즘 AI가 엉망인 코드를 만든다는 글을 보면 대개 짧은 프롬프트로 너무 큰 작업을 요구하거나, 기반 프레임워크가 없는 경우임.

코드를 전혀 읽지 않는다는 사람은 거짓말을 하거나, 극도로 단순한 소프트웨어를 만들거나, MVP 이전 단계만 반복하는 것이라고 봄. 처음에는 그럭저럭 진행돼도 저품질 코드가 쌓여 유지보수가 불가능해지는데, 그 전에 다음 ‘대단한 아이디어’로 옮겨가니 상관하지 않는 것임.
거짓 홍보의 배경에는 바이브 코딩과 토큰 사용 극대화를 팔려는 LLM 기업들의 여론 조작과 대리 홍보가 있다고 봄.

개인 프로젝트에서도 주요 기능 몇 개를 코드 검토 없이 진행하면 결국 몇 시간씩 대대적인 수정을 하게 되고, 그 과정에서 화가 치밀어 오름. 이런 ‘에이전트 엔지니어링’이 시간을 많이 절약해 주는지 확신하기 어려움. 좋은 코드나 유지보수성을 신경 쓰지 않았다면 덜 괴로웠겠지만, 실제로 정신 건강에 영향을 줌.

Astra를 쓰며 나도 비슷하게 느끼고 있음. 모델은 장기 과제 성공에는 큰 보상을 받지만 나쁜 코드에는 거의 벌점을 받지 않는 것 같음.
최근 몇 달 사이 OpenAI와 Anthropic이 강화학습 목표를 사람의 유용성 평가에서 장기 과제 성공으로 옮긴 것 아닌지 의심됨. 자율적으로 과제를 완수한다는 면에서는 AGI에 가까워졌지만, 소통 능력은 이상할 정도로 나빠짐. 장기 과제, 컴퓨터 조작, 어려운 수학이나 ARC-AGI 유형 문제에는 놀라울 만큼 강해졌는데 함께 일하기는 점점 더 이상해짐.

이들은 개발자에게 도구를 팔려는 게 아니라, 가능한 한 많은 중간 단계를 없애려는 것임.

장기 과제에 맞춰 훈련할수록 협업 능력은 떨어지는 것 아닌지 궁금함. 훈련받은 하위 에이전트를 지휘하는 데는 능숙하지만, 외부 다중 에이전트 시스템의 구성원으로 일하거나 사람과 번갈아 작업하는 데는 서툴러질 수 있음. Opus 5에서 그렇게 느꼈고, Astra도 초기 사용에서는 비슷함.

더 많은 코드를 생성하도록 최적화하고 있어도 놀랍지 않을 것임. 코드가 많아질수록 장기적으로 유지보수용 토큰을 더 팔 수 있기 때문임.

다른 LLM의 출력을 사람이 받아들이기 편하게 바꾸는 데 LLM을 쓰게 될지 궁금함.

AI 엔지니어링이 네이쥐안(内卷), 즉 인볼루션(involution) 같다는 대목이 와닿음. 노력과 경쟁은 계속 늘어나지만 산출은 개선되지 않는 구조로, 서구에서는 996 근무 같은 형태로도 나타남. 『Agricultural Involution』에서 다룬 농업 집약화 역시 단위 면적당 생산성은 높이지만 1인당 생산성은 그대로인 현상임.

대만의 Reddit 격인 PTT에서 읽은 글이 떠오름. AI가 마침내 인간이 못 하던 일을 해냈음. 관리자는 원하는 것을 정확한 맥락과 함께 전달해야 하고, 임금에 해당하는 토큰 비용도 정확히 지불해야 하며, 중국에서 문제가 되는 듯한 임금 체불도 할 수 없게 됨.

그래도 필요한 농지 면적은 줄어드는 것 아닌가?

붉은 여왕의 경주라고도 부를 수 있음.

Sol이 코드를 옮길 때 주석을 망가뜨려서, 한 프로젝트의 AGENTS.md에 삭제 후 기억에 의존해 다시 쓰지 말고 sed나 Python 같은 결정적 도구를 우선 사용하라고 적었음.
Astra로 바꾸자 갑자기 모든 프로젝트의 모든 편집에 이 방식을 쓰기 시작했는데, 이 역시 좋지 않음. replace의 두 번째 인수는 여전히 ‘기억에 의존해’ 작성하면서, 이제는 무엇이 바뀌었는지 알려면 Python 스크립트부터 해독해야 함.

Sonnet으로 빠르게 만든 시제품을 바탕으로 Astra에 앱 개발을 맡겼는데, 이틀 동안 실제 앱은 거의 진척이 없었음. 문서, 스크립트, 작업 흐름만 만들고 PR마다 온갖 검토를 수행함. MVP만 필요하다고도 분명히 전달함.
평범한 시니어 엔지니어라면 더 빨리, 더 읽기 좋고 품질 높은 코드로 끝냈을 것임. 반면 나는 별 성과 없이 10만 토큰 이상을 쓴 것 같음. 이걸 최고 수준 모델이나 AGI라고 부르는 세상이 우스움.
OpenAI와 Anthropic 엔지니어들은 무슨 작업을 하기에 이 모델들을 그렇게 칭찬하는지 정말 궁금함. Opus 4.5 이후로는 개선을 느끼지 못했음. 한 번의 요청으로 완성했다는 시연도 진지한 소프트웨어 엔지니어링에서는 별 의미가 없다고 봄.

앱 개발이나 코드 평가는 할 줄 모르지만, Astra로 첫 iOS 앱을 직접 만드는 과정은 아주 순조로움. 복잡한 앱은 아니어도 Bluetooth 등 어려울 것 같던 요소가 있는데 잘 진행됨. 한 번에 완성해 달라고 하지 않고 기능별로 만들고 시험하며 쌓아가는 중임.
처음에는 모든 글꼴 크기로 시뮬레이터 테스트를 돌렸지만, UI 검토 때까지 하지 말라고 하자 멈췄음. Sol도 같았을지는 모르겠지만 Astra와의 작업은 만족스러움. 보통 high를 쓰고, 한 번 불가능하다고 했을 때만 max로 바꿔 대안을 찾게 했음.

내 경우에는 구현에 지나치게 결합된 과도한 테스트도 만듦. 템플릿 기반 Go 프로젝트에서 동작을 검증하는 대신 CSS 클래스의 존재 여부를 검사하는 식임.

AI 엔지니어링에서 일찍 배운 교훈은 충분히 구체화한 에픽을 전달하는 일을 대체할 수 없다는 것임. 단순히 ‘제품에 테마를 구현해 줘’가 아니라, 평소보다 더 구체적으로 버튼·이벤트·레이아웃까지 작업 범위와 제외 범위를 명시해야 함.
AI와 함께 에픽을 다듬을 수는 있지만, 명세에 책임질 사람이 최종 검토해야 함. AI의 답변은 해당 에이전트의 출력 토큰 한도에 제한되며, 누락이나 잘못을 인정하더라도 AI가 책임을 지지는 않음.

이 교훈은 부분적으로 낡아가고 있다고 봄. 예전에는 라이브러리, 구성 요소 간 통신, 인증, 비밀정보 저장 등 설계와 운영상의 선택을 미리 지정해야 했음. 그렇지 않으면 모델이 제멋대로 아이디어를 섞어 어이없이 망가진 결과를 내놓곤 했음.
하지만 최근 약 6개월간 최고 수준 모델들은 설계 선택을 잘함. 어제도 Claude에 통합할 시스템의 특성, 목적, 사용자 우선순위와 사용 사례를 중심으로 간단한 서비스를 설명했더니, 보안·인증·배포·장애 조치·통합과 시스템 간 동작 차이 조정까지 탄탄한 개발·운영 관행에 맞춰 제안함. 해당 프로젝트에 맞지 않는 관행은 명시적으로 벗어났고, 내가 생각한 것보다 훨씬 많은 예외 상황도 검토함.
다만 신규 개발보다 기존·레거시 시스템 수정이 훨씬 까다로움. 오래된 문서나 잘못된 이름에서 비롯된 오해가 증폭되기 때문에 세세하게 감독해야 함. 에픽을 아무리 정확히 써도 다른 자료와 충돌하면 미묘한 오류를 만들고, 한참 뒤에야 발견하게 됨.
모델은 읽는 모든 것을 동등한 ‘확정 사실’처럼 취급하는 경향이 강함. 자료가 낡았을 가능성, 시간적·인과적 순서, 단순한 오류를 섬세하게 구분하지 못함. 시간이 지나며 LLM이 코드와 문서까지 쓰게 하면 이 문제가 누적됨.

기존 TypeScript 코드를 직접 수정해 원하는 것을 명세하면, 토큰 비용은 최소로 들고 지식재산 탈취 없이 정확히 원하는 결과를 얻을 수 있음.

이슈 보드에서 에이전트와 유용하게 협업할 수 있어야 한다고 봄. Epiq도 이를 위해 개발됨. 보드를 코드로 관리하고 Git으로 뒷받침하며, 이벤트 로그로 분산하고 기록을 재생해 에이전트가 실제로 무엇을 했는지 확인할 수 있음. https://ljtn.github.io/epiq

그 정도로 구체적으로 써야 한다면 직접 코드를 작성하는 편이 더 빠르고 좋고 저렴하게 결정적인 결과를 얻는 길 아닌가?

2월쯤에는 Claude에 아주 모호하게 요청해도 괜찮았음. 그 이후 모델이 퇴보한 듯한 느낌임.

Opus와 Fable에서도 정확히 같은 패턴을 봄. 파일을 직접 편집할 수 있다는 사실을 잊은 듯 Python 스크립트를 패치 도구로 쓰는 식임.

에이전트 실행 환경의 지시에 따른 동작이며 토큰도 절약됨. 스크립트로 파일을 일괄 수정할 수 있고, 세션 비용 대부분은 캐시 읽기에서 발생함. 예를 들어 문맥이 30만 토큰이면 명령 하나마다 입력 토큰 3만 개에 해당하는 비용이 듦.

Python의 모든 기능을 쓸 수 있는데 굳이 제약 많은 편집 도구를 써야 할 이유가 있을까?

실행 환경이 그렇게 지시함. 메시지 두 개마다 프롬프트를 다시 주입하니 Edit 도구 사용을 ‘잊는’ 것임.

나는 추상 구문 트리(AST) 기반 치환 도구를 쓰는데 훨씬 안정적임.

내가 알기로는 의도된 동작임. 에이전트가 실행 환경의 전용 도구보다 Python 같은 도구를 더 잘 사용함.

다른 결과도 제시하고 싶음. 나는 기존 코드베이스에서 새 기능을 만들고 버그를 고치며, 에이전트에 작업 보드와 Git, 몇 가지 MCP 도구 접근 권한을 줌. 요구사항과 기대 결과가 명확한 작업이면 항상 좋은 코드를 내놓고, 내가 자동·수동 테스트와 코드 검토로 검증한 뒤 동료들이 다시 검토함.
새 기능 개발 시간은 기존의 절반 이하로 줄고 버그도 훨씬 적어졌으며, 버그 수정은 더 빨라짐. 핵심은 탄탄한 요구사항, 명확한 맥락, 그리고 계획 단계와 검증 단계에서의 신중한 인간 감독임.

반론은 아니라고 봄. 성숙한 코드베이스 자체가 에이전트에 줄 수 있는 최상의 맥락임. 이미 패턴이 갖춰져 있으니 그대로 따르면 됨. 현실의 피드백과 제약을 반영하며 수만~수십만 인시를 들여 다듬은 결과물일 수 있음.
반면 처음부터 만들 때 에이전트가 의존할 수 있는 것은 학습 데이터의 평균적인 내용과 텍스트 프롬프트의 명확성 정도임.

새 모델이 온갖 선택 플래그를 끌어다 쓴 읽을 수 없는 Bash 명령이나 Python 스크립트를 실행하려는 모습을 나도 봄. 정규식보다 가독성이 떨어져 검토가 불가능함.

나도 그래서 Claude Code 시스템 프롬프트에 표준 읽기·쓰기 도구를 쓰라는 문구를 추가함. 그런데 기본값이 auto-mode로 바뀐 뒤에는 해당 모드의 도구가 sed, Python 등을 Bash 명령으로 실행하도록 유도한다는 취지의 답변을 봤고, 여기에는 여러 부작용이 따름.

그렇게 똑똑한 도구라면 검토하기 쉬운 형태로 다시 작성하라고 요청하면 되지 않을까?
소프트웨어 개발에서는 은퇴했고 취미 코딩에만 LLM을 조금 쓰므로 전문 도구는 사용하지 않음. 주로 Duck AI를 통해 ChatGPT를 쓰는데, 작동하는 스크립트라도 불필요하게 우회하는 구현 때문에 거의 항상 몇 번씩 다시 쓰게 함. 추가로 요청하면 대체로 더 효율적이고 읽기 쉬운 결과를 얻을 수 있음.