1인 개발자 체제로 SI, MES, ERP 시스템을 납품하며 현업에서 AI를 적극적으로 활용해 온 입장에서, 최근 대규모 언어 모델(LLM)의 발전 궤적을 지켜보며 깊은 회의감에 직면하게 된다. GPT-5.6 즈음까지만 해도 AI의 코딩 능력은 경이로웠고, 실제로 내 업무 생산성을 폭발적으로 끌어올리며 수익 구조를 안정화하는 핵심 동력이었다. 그러나 최신 모델인 아스트라(Astra)를 기점으로, 나는 현재의 AI 아키텍처가 뚜렷한 한계에 봉착했다는 실무 체감을 느낀다.
이는 단순한 성능의 문제를 넘어, 자본의 효율성(ROI), 시스템 아키텍처의 유지보수, 그리고 우리가 '지능'이라고 불렀던 것의 본질에 대한 근본적인 의문을 제기한다.
정형화된 상태 공간과 AI의 압도적 효율성
실제 현장의 프로그래밍은 학부 시절 다루는 OS 커널이나 복잡한 알고리즘 설계와는 궤가 다르다. 대부분의 사내 ERP나 MES 시스템은 N+1 쿼리 최적화, UI/UX 응답성 개선, 그리고 프레임워크 내에서 제어의 역전(IoC)이나 헥사고널, MVVM 같은 정형화된 구조를 얼마나 잘 조립하느냐의 싸움이라고 할 수 있다. 도메인 로직을 제외한 70~80%는 본질적으로 단순 반복되는 CRUD 애플리케이션이다.
핵심은 유효성 검사(Validation)를 어느 계층에 둘 것인지, 데이터 모델링을 어떻게 검증할 것인지와 같은 아키텍처적 결정에 있다. 일단 이 뼈대와 작업 지시서의 모델링이 주어지면, 탐색 공간이 한정된 함수나 클래스 단위의 구현에서는 AI가 어지간한 인간 프로그래머보다 훨씬 더 정교하고 깔끔한 코드를 산출한다.
이는 부정할 수가 없다.
스케일링 법칙의 종말과 ROI의 붕괴
문제는 GPT-5.3 이후 코딩 영역에서 유의미한 거시적 개선이 멈췄다는 점이다. 특히 이전 세대 대비 토큰 비용이 2.5배 폭증한 아스트라(Astra)의 등장은 현재 LLM 스케일링의 모순을 극명하게 보여준다.
나는 AI 모델을 늘 처음쓸때 하는 기본적인 테스트를 한다.
10가지 테스트를 만들었고, 그 테스트를 10번씩 실행한다.
그중 2개는 다음과 같다.
닫힌 상태 공간 및 불변식 검증 (State Machine with Strict Invariants)
학습된 보일러플레이트를 복사하는지, 도메인 불변식을 타입 시스템에 강제할 수 있는지 테스트
요구 과제: 결제 또는 주문 라이프사이클을 관리하는 유한 상태 머신(FSM) 구현.
제약 조건:런타임 예외(
throw/catch) 사용 금지. 모든 실패는Result<T, E>로 반환할 것.
전이 불가능한 상태(예:
취소됨상태에서배송중으로 전이)는 런타임 if문 이전에 컴파일 타임에 타입 수준에서 불가능하도록 설계할 것 (Phantom Types 또는 Tagged Union 활용).
비동기 타임아웃 발생 시 롤백 트랜잭션이 보장되는 체이닝 구조를 작성할 것.
무할당(Zero-Allocation) 공간 분할 자료구조 (Data-Oriented / Memory)
단순한 문법 지식이 아니라 하드웨어 메모리 레이아웃과 힙 할당 최적화를 고려하는지 확인합니다.
요구 과제: 2D/3D 공간에서 충돌 판정을 위한 정적 그리드 또는 쿼드트리(Quadtree) 구현.
제약 조건:매 프레임 갱신/조회 루프(Hot Loop)에서 힙 메모리 할당(
new) 발생 0회 유지.
객체 참조(Reference) 대신 인덱스 기반 구조(Array-of-Structures 또는 Struct-of-Arrays)로 메모리 연속성 확보.
요소 삭제 시 콤팩트한 메모리 유지를 위한 Swap-back(RemoveAtSwapBack) 패턴 적용.
이 테스트를 10가지 실행한 결과 오히려 아스트라에서 gpt 5.6 sol보다 더 낮은 성능을 다량 양산하였다. 비용도 무려 2.5배로 비싼데 말이다.
아스트라는 3D 에셋이나 메쉬 생성 같은 다중 모달 능력이 향상되었다고 하지만, 코드 생성의 퀄리티는 오히려 이전 모델인 Sol보다 퇴화한 모습을 보인다. 순수하게 B2B 백엔드 시스템이나 기업용 ERP 서비스를 구축해야 하는 엔지니어 입장에서, 비즈니스에 전혀 쓸모없는 3D 아트 기능 때문에 2.5배의 API 비용을 지불해야 할 이유가 없다. 심지어 3D 에셋을 쓰는 순간 유저들의 구매율이 낮아진다. 아이러니다.
RPG 게임에 비유하자면 '국민 세트' 장비를 맞춘 후 상급 장비로 넘어갈 때 비용이 기하급수적으로 폭증하지만 성능 체감은 미미해지는 구간에 진입한 것이다. 투입하는 컴퓨팅 자원 대비 논리적 추론 능력이 정비례하여 오르지 않는 비효율의 임계점이라는 체감이 든다. 지금은 LLM의 트랜스포머 아키텍쳐에 인코더에 멀티 모달을 달아뒀다. 원리상 모델의 가중치는 무한하지 않다. 3D 공간을 렌더링하고, 이미지 픽셀을 텍스트와 매핑하는데 연산량과 파라미터가 할당되면 당연히 프로그래밍쪽 로직과 타입 시스템 문맥 유지를 위해 쓰여야할 자원을 뺏기니까. 이를 Nagative Transfer라고 한다.
트랜스포머 구조는 결국 1차원적 토큰의 시퀀스를 예측 하는 구조다. 멀티 모달을 달았다는 것은 입력과 출력의 형태가 다양해졌다는 것이지만 반대로 그만큼의 크기가 커졌고 비용도 비싸졌다는 것이다.
반대로 말하자면 멀티 모달을 넣어서 positive transfer를 얻을 수 있다. 이미지에서 배운 공간관계, 객체관계, 인과 구조가 텍스트 resonning에도 도움을 줄 수 있다. 하지만 필연적으로 이러면 모델은 커지고 모델이 커질수록 비용이 높아진다.
즉 LLM이라는 정렬 기계의 성능은 엄청나게 커질 수 있지만 input 비용도 그에 비례하게 올라간다는 뜻이다. 그럼 결국 가격면에서 기계를 쓸 일이 없다.
업무 밀도와 코드베이스 오염의 딜레마
AI 도입 이후 1인 개발자가 감당해야 하는 업무 밀도는 비정상적으로 높아졌다. AI가 개발의 최저선을 끌어올린 결과, 프로젝트 계약 기간은 과거의 절반 수준으로 압축되었고 오히려 노동 시간은 늘어났다.
더 치명적인 것은 유지보수의 붕괴다. 10만 줄 단위의 거대한 코드베이스에 인간의 코드와 AI의 코드가 섞이기 시작하면 심각한 아키텍처적 이질감이 발생한다. 현업의 프로그래머들은 알고리즘을 달달 외워서 코딩하는 것이 아니라, 팀의 규약, 관리의 용이성, 도메인의 특수성이라는 '인간의 냄새'가 배어 있어 버릇을 가지고 있다. 반면 AI는 가장 평균적이고 파편화된 로직을 생성하므로, 이를 그대로 방치하면 결국 시스템 전체의 무결성이 훼손되고 끊임없는 버그 수정의 늪에 빠지게 된다.
지능의 환상: '논리'인가, '직렬화(Serialization)'인가?
이러한 현상들을 종합해 볼 때, LLM이 수행하는 작업이 과연 범용 인공지능(AGI)으로 향하는 징검다리인지 깊은 의구심이 든다.
인간의 지적 작업은 비선형적이다. A를 구상했다가 C를 시도하고 다시 B로 돌아와 새로운 결과물을 창조한다. 그리고 논문을 그에 맞게 ABC 구조로 직렬화한다. 즉 논리적인 구조라는 것은 생각해보면 직렬화이다.
AI는 더티(Dirty) 데이터와 파편화된 정보들을 수집해 A-B-C의 연속적인 데이터로 깔끔하게 '직렬화(Serialization)'하는 것에 극도로 최적화된 도구일 뿐이다.
우리가 그동안 고도의 지적 작업이라 착각했던 수많은 사무 업무와 단순 코딩이 사실은 이 직렬화의 산물이었기 때문에 AI가 완벽히 대체하고 있는 것이다. 하지만 차원을 넘나들며 없는 구조를 설계하는 진정한 의미의 '지능'과는 거리가 멀다라고 생각한다.
특화 모델의 시대와 감속주의라는 해자
결국 미래의 AI 생태계는 거대한 범용 모델 하나로 모든 것을 해결하는 방식에서 벗어나, 코딩 특화, 3D 특화 등 도메인별로 정형화된 가벼운 모델들을 복합적으로 오케스트레이션하는 방향으로 갈 수밖에 없다. 그렇지 않으면 폭증하는 토큰 비용을 비즈니스 구조가 감당할 수 없기 때문이다.
최근 빅테크들이 주장하는 안전과 '감속주의' 역시, 새로운 아키텍처로 무장한 혁신적인 소규모 기업들의 추격을 막고, 거대한 인프라 상주 비용을 감당할 수 있는 자신들만의 과점 체제를 굳히려는 자본주의적 해자(Moat) 구축에 불과해 보인다.
아스트라의 비용은 GPT 5.6 Sol의 2.5배이다. 하지만 나의 작업에서 오히려 코드는 더 나빠졌다. 그렇다면 이 모델을 쓸 이유가 있는가?
내 생각에 이 추세는 오래 지속될 것이라 생각한다. 아마 이게 LLM이 가지는 한계선이 아닐까?
비용까지 생각하면 미래에는 오히려 전문화된 모델이 다시 중요해질 가능성이 있다고 본다.
코딩에 특화된 모델.
3D mesh 생성에 특화된 모델.
문서 처리 모델.
수학과 과학 탐색 모델.
그리고 그 위에서 필요한 모델을 조합하는 orchestration layer.
아마 이정도 순에서 멈추고 결국 프로그래머의 선택이란 충분히 자기 작업내에서 가장 싼 기계를 골라서 의뢰인을 만족시키는 정도가 될지도 모르겠다.