복잡도는 지수적으로 증가하고, 아마 그보다 더 빠를 수도 있음. 그래서 AGI 특이점을 두려워하는 사람들도 종종 놓치는데, 아무리 똑똑한 사람·모델·에이전트라도 아이디어·시스템·프로젝트·코드베이스·기능 집합이 커지면 결국 급격한 복잡도의 벽에 부딪힘
모든 소프트웨어 프로젝트는 초반엔 비교적 순조롭지만, 어느 순간 복잡도의 지수 증가가 모든 걸 압도함. 좋은 아키텍처·설계·품질은 그 시점을 늦출 뿐이고, 유능한 사람들이 잘 설계하고 품질을 챙기면 크기·기능·성능·와우 포인트를 10배쯤 더 버틸 수는 있어도 결국 벽에 닿게 됨
LLM 보조는 일정 수준, 대체로 평균적인 품질의 기능과 코드를 훨씬 빨리 만들게 해줌. 즉 그 벽에도 훨씬 빨리 도달한다는 뜻임. 성장, 실험, 비교적 쉬웠지만 시간이 많이 들던 저복잡도 작업에는 좋지만, 전에 없던 것이나 크고 복잡한 프로젝트를 만들게 해주는 건 아님. 그런 데 필요한 건 복잡도를 억제하는 개선인데, 현재 LLM은 그걸 제대로 제공하지 못함
고전적인 문제임. 원인과 결과가 바로 이어지면 즉각적인 이익은 쉽게 보이지만, 원인과 결과 사이에 시간이 벌어져 있으면 부정적 효과는 훨씬 보기 어려움 http://bastiat.org/en/twisatwins.html
코드 에이전트 사용 비용은 직접적으로 드러나지 않고, 무엇보다 시스템이 어떻게 동작하는지에 대한 집단적 이해 상실에서 나옴
그래도 계층적 조직화는 큰 규모의 복잡도를 관리하는 길을 제공함. 자연에서도 이런 방식으로 엄청나게 복잡한 구조가 생겨나는 걸 볼 수 있음. 독립적인 단위들이 조합되어 더 큰 구조를 이루는 식으로 시스템을 만들 수 있음
견고한 시스템은 충격에 버티고 스스로 적응할 수 있어야 하므로, 각 부분은 독립적으로 실패하고 피해도 국소화되어야 함. 시스템을 중첩된 하위 시스템으로 조직하면, 서로 대화하며 일을 처리하는 세포 같은 단위가 생김. 이 단위들은 다른 세포의 내부 과정을 알 필요 없이 안정적인 부분 조립품처럼 동작함
각 계층은 다른 곳에서 벌어지는 일에 발목 잡히지 않으므로 자기 영역 안에서 스스로 조직화하고 회복력을 유지할 수 있음. 이는 사실상 인터페이스 뒤에 부수적 복잡도를 캡슐화하고, 그 인터페이스가 의미를 담는 추상화를 만드는 방식임. 계층은 큰 시스템의 구성 요소들을 잇는 결합 조직으로 보는 게 좋음 Erlang OTP는 이런 접근을 소프트웨어에서 잘 보여주는 예로, 큰 시스템을 서로 메시지를 주고받는 격리된 프로세스들로 구성함. 개별 프로세스가 죽거나 오류가 나도 전체 시스템을 무너뜨리지 않음
“복잡도를 억제한다”는 건 결정, 견해, 그리고 때로는 반대나 충돌을 필요로 한다고 봄
누군가에게 무언가를 구현해 달라고 하면 “너무 복잡하다”, “1년 뒤에 터질 거다”, “Y팀이 하고 있다는 것과 호환되지 않는다”, “구현할 사람이 충분하지 않다” 같은 답을 할 수 있음. 마지막 말은 실제일 수도 있고, 간접적으로 “안 된다”고 말하는 방식일 수도 있음
LLM이 그렇게 답할 가능성은 매우 낮음. 특히 낙관적이고 공손하게 조정되어 있기 때문임. 더구나 그런 성향이 참여도를 높이는 데 필요하니 다르게 조정될 가능성도 낮아 보임
이 문제는 LLM이 사용자의 자살을 도운 문제와 비슷해 보임. 그건 꽤 명백한데도 LLM이 많이 해왔음. 관리되지 않은 복잡도로 프로젝트가 죽는 건 그보다 훨씬 덜 명확하니, LLM이 가까운 시일 안에 더 잘해낼 거라는 기대는 크지 않음
“Claude Code를 쓰면 진짜 제품 개발 속도 우위가 생기고, Anthropic이 7개월 동안 독점했다면 Claude Code와 모든 경쟁자 사이의 격차는 메울 수 없어야 한다. Codex는 무의미해야 한다. 그런데 사람들은 여전히 어느 쪽이 더 나은지 활발히 논쟁 중이다”라는 식의 추론은 탄탄해 보이지 않음 Claude Code는 좋은 소프트웨어지만, 경쟁이 불가능해질 정도의 이상한 AGI 마법은 아님
게다가 Codex도 바이브코딩으로 만들어졌으니 그 비교는 그런 면에서도 좀 우스움. 몇 달 먼저 시작했다는 건 별 의미가 없을 수 있음. 추가되는 많은 기능은 실제 사용자들이 도구로 무엇을 하는지에서 나오기 때문임
Claude Code가 처음부터 완성된 로드맵을 갖고 있었고, 주된 장벽이 코드 작성 속도였던 건 아님. 핵심 장벽은 아이디어임. 모두가 해가며 만들어내는 중임
글을 대체로 훑어봤을 뿐이라 깊게 말하긴 어렵지만, 문장 첫 글자 대소문자 문제는 차치하더라도 대부분 LLM이 쓴 산문처럼 보여서 읽고 싶지는 않았음
지금까지 에이전트의 실수는 곱셈적으로 누적되는 경향이 있음
기술적으로는 동작하지만 사용할 때 약간의 추가 코드가 필요한 API를 만들면, 그 결과 코드가 늘어나고, 중복·분기·버그가 생길 장소도 늘어남. 그러면 프랙털처럼 또 그다지 좋지 않은 코드가 더 많이 작성됨
한 에이전트가 id 필드가 선택적인 구조체를 설계한 적이 있음. 자기가 작성한 생성자 하나 때문에 필요했던 필드였음. 그러고는 id가 있을 때와 없을 때의 코드를 지치지도 않고 두 벌로 쓰고, 없을 때를 위한 어색한 대체 경로까지 만들었음. 그 대체 경로들은 당연히 복잡하고 취약했음. 구조체의 거의 모든 사용처와 그에 의존하는 것들까지 감염됐고, 정작 id 없는 생성자는 쓰이지도 않았음. 코드베이스 절반은 쉽게 삭제할 수 있었음
“멍청한 짓을 하고 있으면 파기를 멈춰라” 같은 지시를 충분히 넣으면 고칠 수 있고 코딩이 “해결”되기까지 몇 가지 해킹만 남은 건지, 아니면 확률적 앵무새의 장기적 문제라 선형 개선을 위해 지수적으로 증가하는 비용이 계속 필요한 건지 정말 모르겠음. 실수가 복리로 쌓이는 한, 복리 성장은 결국 발목을 잡음
인간 개발자에게도 매우 비슷한 일이 일어나는 걸 봤음. 최고의 개발자를 가르는 특징 중 하나는 한 단계 높고 바깥 수준에서 멈춰 돌아보는 성향이라고 봄
때로는 비즈니스 프로세스까지 포함됨. 도메인을 잘 아는 개발자는 기술적 해법을 몇 달 구현하는 대신 “계속 파기보다 그냥 프로세스를 바꾸면 안 되나?”라고 물을 수 있고, 답이 “물론이지, 그건 쉽다”일 때도 있음
LLM도 결국 이 부분을 더 잘하게 될 것 같음. 이미 “이 접근은 좋아 보이지 않는데, 대안을 생각해볼 수 있나?”라고 직접 물으면 꽤 자주 찾아내기도 함. 다만 지금은 성공과 실패가 들쭉날쭉하고, 일단 그런 멍청한 일을 해두면 관련 없는 작업을 하다가 스스로 알아차릴 가능성은 낮음
여기엔 절충도 있음. 사람들은 이미 모델이 문제를 과하게 생각하며 토큰을 태운다고 불평함. 특정 문제를 푸는 코드가 “어떤 느낌이어야 하는지”에 대한 경험과 직관이 있으면 개발자는 자연스럽게 언제 돌아봐야 할지 알 수 있음. 에이전트도 더 나은 훈련으로 그런 직관을 얻게 될지도 모름
Lobste.rs 의견들
복잡도는 지수적으로 증가하고, 아마 그보다 더 빠를 수도 있음. 그래서 AGI 특이점을 두려워하는 사람들도 종종 놓치는데, 아무리 똑똑한 사람·모델·에이전트라도 아이디어·시스템·프로젝트·코드베이스·기능 집합이 커지면 결국 급격한 복잡도의 벽에 부딪힘
모든 소프트웨어 프로젝트는 초반엔 비교적 순조롭지만, 어느 순간 복잡도의 지수 증가가 모든 걸 압도함. 좋은 아키텍처·설계·품질은 그 시점을 늦출 뿐이고, 유능한 사람들이 잘 설계하고 품질을 챙기면 크기·기능·성능·와우 포인트를 10배쯤 더 버틸 수는 있어도 결국 벽에 닿게 됨
LLM 보조는 일정 수준, 대체로 평균적인 품질의 기능과 코드를 훨씬 빨리 만들게 해줌. 즉 그 벽에도 훨씬 빨리 도달한다는 뜻임. 성장, 실험, 비교적 쉬웠지만 시간이 많이 들던 저복잡도 작업에는 좋지만, 전에 없던 것이나 크고 복잡한 프로젝트를 만들게 해주는 건 아님. 그런 데 필요한 건 복잡도를 억제하는 개선인데, 현재 LLM은 그걸 제대로 제공하지 못함
http://bastiat.org/en/twisatwins.html
코드 에이전트 사용 비용은 직접적으로 드러나지 않고, 무엇보다 시스템이 어떻게 동작하는지에 대한 집단적 이해 상실에서 나옴
견고한 시스템은 충격에 버티고 스스로 적응할 수 있어야 하므로, 각 부분은 독립적으로 실패하고 피해도 국소화되어야 함. 시스템을 중첩된 하위 시스템으로 조직하면, 서로 대화하며 일을 처리하는 세포 같은 단위가 생김. 이 단위들은 다른 세포의 내부 과정을 알 필요 없이 안정적인 부분 조립품처럼 동작함
각 계층은 다른 곳에서 벌어지는 일에 발목 잡히지 않으므로 자기 영역 안에서 스스로 조직화하고 회복력을 유지할 수 있음. 이는 사실상 인터페이스 뒤에 부수적 복잡도를 캡슐화하고, 그 인터페이스가 의미를 담는 추상화를 만드는 방식임. 계층은 큰 시스템의 구성 요소들을 잇는 결합 조직으로 보는 게 좋음
Erlang OTP는 이런 접근을 소프트웨어에서 잘 보여주는 예로, 큰 시스템을 서로 메시지를 주고받는 격리된 프로세스들로 구성함. 개별 프로세스가 죽거나 오류가 나도 전체 시스템을 무너뜨리지 않음
누군가에게 무언가를 구현해 달라고 하면 “너무 복잡하다”, “1년 뒤에 터질 거다”, “Y팀이 하고 있다는 것과 호환되지 않는다”, “구현할 사람이 충분하지 않다” 같은 답을 할 수 있음. 마지막 말은 실제일 수도 있고, 간접적으로 “안 된다”고 말하는 방식일 수도 있음
LLM이 그렇게 답할 가능성은 매우 낮음. 특히 낙관적이고 공손하게 조정되어 있기 때문임. 더구나 그런 성향이 참여도를 높이는 데 필요하니 다르게 조정될 가능성도 낮아 보임
이 문제는 LLM이 사용자의 자살을 도운 문제와 비슷해 보임. 그건 꽤 명백한데도 LLM이 많이 해왔음. 관리되지 않은 복잡도로 프로젝트가 죽는 건 그보다 훨씬 덜 명확하니, LLM이 가까운 시일 안에 더 잘해낼 거라는 기대는 크지 않음
“Claude Code를 쓰면 진짜 제품 개발 속도 우위가 생기고, Anthropic이 7개월 동안 독점했다면 Claude Code와 모든 경쟁자 사이의 격차는 메울 수 없어야 한다. Codex는 무의미해야 한다. 그런데 사람들은 여전히 어느 쪽이 더 나은지 활발히 논쟁 중이다”라는 식의 추론은 탄탄해 보이지 않음
Claude Code는 좋은 소프트웨어지만, 경쟁이 불가능해질 정도의 이상한 AGI 마법은 아님
Claude Code가 처음부터 완성된 로드맵을 갖고 있었고, 주된 장벽이 코드 작성 속도였던 건 아님. 핵심 장벽은 아이디어임. 모두가 해가며 만들어내는 중임
글을 대체로 훑어봤을 뿐이라 깊게 말하긴 어렵지만, 문장 첫 글자 대소문자 문제는 차치하더라도 대부분 LLM이 쓴 산문처럼 보여서 읽고 싶지는 않았음
지금까지 에이전트의 실수는 곱셈적으로 누적되는 경향이 있음
기술적으로는 동작하지만 사용할 때 약간의 추가 코드가 필요한 API를 만들면, 그 결과 코드가 늘어나고, 중복·분기·버그가 생길 장소도 늘어남. 그러면 프랙털처럼 또 그다지 좋지 않은 코드가 더 많이 작성됨
한 에이전트가
id필드가 선택적인 구조체를 설계한 적이 있음. 자기가 작성한 생성자 하나 때문에 필요했던 필드였음. 그러고는id가 있을 때와 없을 때의 코드를 지치지도 않고 두 벌로 쓰고, 없을 때를 위한 어색한 대체 경로까지 만들었음. 그 대체 경로들은 당연히 복잡하고 취약했음. 구조체의 거의 모든 사용처와 그에 의존하는 것들까지 감염됐고, 정작id없는 생성자는 쓰이지도 않았음. 코드베이스 절반은 쉽게 삭제할 수 있었음“멍청한 짓을 하고 있으면 파기를 멈춰라” 같은 지시를 충분히 넣으면 고칠 수 있고 코딩이 “해결”되기까지 몇 가지 해킹만 남은 건지, 아니면 확률적 앵무새의 장기적 문제라 선형 개선을 위해 지수적으로 증가하는 비용이 계속 필요한 건지 정말 모르겠음. 실수가 복리로 쌓이는 한, 복리 성장은 결국 발목을 잡음
때로는 비즈니스 프로세스까지 포함됨. 도메인을 잘 아는 개발자는 기술적 해법을 몇 달 구현하는 대신 “계속 파기보다 그냥 프로세스를 바꾸면 안 되나?”라고 물을 수 있고, 답이 “물론이지, 그건 쉽다”일 때도 있음
LLM도 결국 이 부분을 더 잘하게 될 것 같음. 이미 “이 접근은 좋아 보이지 않는데, 대안을 생각해볼 수 있나?”라고 직접 물으면 꽤 자주 찾아내기도 함. 다만 지금은 성공과 실패가 들쭉날쭉하고, 일단 그런 멍청한 일을 해두면 관련 없는 작업을 하다가 스스로 알아차릴 가능성은 낮음
여기엔 절충도 있음. 사람들은 이미 모델이 문제를 과하게 생각하며 토큰을 태운다고 불평함. 특정 문제를 푸는 코드가 “어떤 느낌이어야 하는지”에 대한 경험과 직관이 있으면 개발자는 자연스럽게 언제 돌아봐야 할지 알 수 있음. 에이전트도 더 나은 훈련으로 그런 직관을 얻게 될지도 모름
2025년 11월 변곡점 이후의 데이터로 갱신된 모습을 보면 좋겠음