2026년 8월까지의 LLM 발전: 학습·코딩·업무의 변화

많은 사람은 AI를 작업 효율을 10~20% 높이는 자동완성 도구로 봅니다. 하지만 Amazon의 실험과 첨단 연구에서는 뚜렷한 격차가 나타납니다. 일부 엔지니어는 속도를 2~3배 높이는 데 머무르고, 다른 엔지니어는 10배 이상 높입니다.

변화는 세 가지 축으로 나뉩니다.

1. 학습과 연구: 결과물을 만들며 기초를 거슬러 배우기

오랫동안 고등교육은 엄격한 상향식 경로를 요구했습니다. 머신러닝을 익히려면 실제 운영 구조를 다루기 전에 미적분, 선형대수, 기존 회귀 모델 등 기초에 4~6년을 써야 했습니다[cite: 3]. 대학이 구조화된 기초 지식을 독점했습니다. 이제 숙련의 경로가 하향식으로 바뀝니다.

완성할 결과물부터 시작하기. 첫날부터 AI에 전체 확산 모델 프로젝트를 만들도록 요청합니다.

거꾸로 파고들기. 코드가 깨지거나 개념이 혼란스러우면 AI 튜터에게 ‘ResNet 블록이 왜 기울기 소실을 막는가?’에서 ‘열두 살에게 설명하듯 행렬 곱셈의 직관을 알려달라’까지 역으로 질문합니다.

기존 연구와의 차이부터 살피기. 논문을 처음부터 끝까지 읽기보다 이전 기법과 달라진 구체적인 부분을 찾아, 실제 구현에 얼마나 도움이 되는지 바로 평가합니다.

과거 여섯 해의 학업 경로가 필요했던 것을 사흘의 집중적인 문제 해결로 익힐 수 있다는 주장입니다.

2. 코딩: 감에 의존하지 않고 원리까지 검증하기

맹목적으로 코드를 복사하지 마십시오. 뛰어난 개발자는 원리와 수학을 이해할 때까지 각 줄을 디버깅합니다.

명세부터 설계하기. 코드를 생성하기 전에 하나의 Markdown 명세에서 시스템 구조와 예외 상황을 정리하면, 저장소 전체를 리팩터링하는 것보다 비용이 훨씬 적게 듭니다.

3. 업무: 매번 지시하기보다 스스로 실행할 조건 마련하기

Amazon의 50개 팀 실험에서 기존 습관에 AI만 조금 더한 팀은 세 배 미만의 개선을 얻었습니다. 흐름을 바꾼 팀은 중간값 기준 4.5배에서 열 배 이상의 속도를 얻었습니다.

30초마다 프롬프트를 기다리면 사람이 병목이 됩니다. 빠른 엔지니어는 코드의 1~2%를 직접 쓰고, 컴파일 점검과 90% 커버리지 기준 같은 자체 검증 조건을 완전한 명세와 함께 제공해 에이전트가 수시간 독립적으로 일하게 합니다.

속도를 높이려면 먼저 준비할 시간이 필요합니다. 선도 팀들은 초기에 산출량이 줄어드는 것을 감수하고 코드 기반을 정비했습니다. CLAUDE.md 같은 맥락 파일을 만들고, 외부 의존성을 로컬에서 모의 구현하며, 에이전트가 기존 코드를 탐색할 MCP 서버를 구축했습니다.

코드 작성이 9~12개월에서 1~2개월로 줄면 새로운 병목은 코드가 아니라 사람의 결정, 제품에 대한 확신, 출시 승인입니다.

도구를 매번 지켜보며 지시하지 마십시오. 검증 기준을 정하고 개입을 줄여, 시스템이 스스로 실행하게 하십시오.