3년 동안 LLM은 어떻게 달라졌는가

제가 LLM을 소프트웨어 개발에 진지하게 써 보기 시작했을 때 가장 중요했던 질문은 꽤 단순했습니다.

이 도구가 실제 개발에서도 정말 도움이 될까?

2023년 당시 제 답은 “가끔은 놀랍다”와 “아직은 꽤 번거롭다” 사이 어딘가에 있었습니다. 모델은 그럴듯하게 설명했고, 코드를 생성했으며, 처음 보면 상당히 전문적으로 보이는 기술 답변을 내놓았습니다. 동시에 Noise도 많았습니다. 존재하지 않는 API를 만들어 내고, Framework 기능을 잘못 가정하고, 최신 변화와 오래된 지식을 섞어 답하기도 했습니다. 특히 빠르게 변하는 기술에서는 답이 단지 그럴듯한 것인지 실제로 맞는 것인지 판단할 수 있을 만큼 해당 기술을 알고 있어야 했습니다.

작고 경계가 분명한 작업에는 이미 충분히 유용했습니다. 함수 하나를 설명하고, 메서드를 Refactoring하고, 작은 예제를 만드는 일은 의외로 잘 됐습니다. 하지만 낯설고 오래된 애플리케이션을 분석하고, 관련된 부분을 찾아내고, 기존 아키텍처를 이해하고, 여러 Layer에 걸쳐 변경을 구현하고, 테스트를 실행하고, 오류까지 스스로 처리하게 만드는 일은 완전히 다른 수준의 문제였습니다.

2026년인 지금 저는 이 도구들과 전혀 다르게 일합니다. 갑자기 완벽해졌기 때문이 아니라, 제가 이 도구들에게 맡길 수 있는 작업의 종류 자체가 달라졌기 때문입니다.

제 경험을 기준으로 보면 변화는 대략 이렇게 흘러왔습니다.

이것은 인공지능 전체의 보편적인 발전 곡선이 아닙니다. 제가 LLM을 사용하는 방식이 어떻게 변했는지를 정리한 것입니다. 그리고 바로 이 경험에서 이 시리즈가 시작됐습니다.

서로 매우 다른 두 현실

제가 LLM을 사용해 온 경험은 성격이 완전히 다른 두 환경에서 나왔습니다. 업무에서는 규모가 큰 소프트웨어 시스템을 다루며, 그중에는 매우 민감한 데이터를 다루는 환경도 있습니다. 이런 곳에서는 “Agent가 기술적으로 무엇을 할 수 있는가?”만으로는 충분하지 않습니다. 어떤 정보를 볼 수 있는지, 어떤 Tool에 접근할 수 있는지, 어떤 결정을 스스로 내려도 되는지, 변경 내용을 나중에 어떻게 추적하고 Review할 수 있는지, 그리고 최종적으로 누가 책임지는지가 똑같이 중요합니다.

기술적으로 전체 애플리케이션을 분석할 수 있는 Agent라고 해서 자동으로 전체 애플리케이션을 분석해도 되는 것은 아닙니다. 정보 경계, 개인정보 보호, Governance, Security, 추적 가능성은 모델 자체만큼이나 전문적인 Agentic Work의 일부입니다.

개인 프로젝트에서는 훨씬 더 자유롭게 실험할 수 있었습니다. 지난 몇 년 동안 규모와 복잡도가 서로 다른 거의 40개의 프로젝트에서 LLM과 Coding Agent를 사용했습니다. 작은 실험부터 Frontend, Backend, Infrastructure, 그리고 AI 자체가 제품 기능의 일부인 애플리케이션까지 다양했습니다.

덕분에 훨씬 과감한 실험이 가능했습니다. Agent에게 전체 Repository 접근 권한을 주고, Agent Files와 Skills를 바꾸고, Memories를 사용하고, Specs를 구체화하고, 모델을 교체하거나, Context를 늘리고 줄였을 때 어떤 차이가 생기는지 관찰했습니다. 이것은 과학적인 표본이 아닙니다. 하지만 최초의 실험들과 지금의 작업 방식 사이에 분명한 차이가 있다는 것을 느끼기에는 충분한 양의 실제 경험이 쌓였습니다.

처음에는 무엇보다 언어가 인상적이었다

초기 대중형 LLM에는 흥미로운 특징이 있었습니다. 많은 기술 상황에서 실제 능력보다 먼저 “굉장히 잘 아는 것처럼” 보였습니다. 문장은 설득력이 있었고, 해결책은 그럴듯했으며, 코드는 실제 개발자가 작성했을 법한 모습이었습니다.

바로 그 점이 문제의 일부였습니다. 해당 Framework나 API를 알고 있다면 존재하지 않는 함수, 잘못된 Parameter, 이미 오래된 지식을 바탕으로 한 해결책을 비교적 빨리 알아챌 수 있었습니다. 하지만 그런 배경지식이 없다면 여전히 매우 자신감 있는 답을 받게 됩니다.

그렇다고 당시의 시스템이 제게 쓸모없었던 것은 아닙니다. 오히려 그 반대였습니다. 작고 경계가 명확한 문제를 다룰 때 이미 좋은 Sparring Partner였습니다. 여러 대안을 만들고, Boilerplate를 줄이고, 코드를 설명하고, 처음 접하는 기술에 진입할 때 도움을 줄 수 있었습니다. 다만 실제 시스템에 통합하는 핵심 작업은 대부분 개발자에게 남아 있었습니다.

당시의 전형적인 흐름은 오히려 이쪽에 가까웠습니다.

AI는 여전히 사람이 주도하는 개발 프로세스 안에 들어간 하나의 도구였습니다. 그리고 중요한 기술 작업은 함수 하나를 작성하는 것이 아니라, 변경이 어디에 들어가야 하는지, 시스템의 어떤 부분이 영향을 받는지, 어떤 부작용이 생길 수 있는지 파악하는 일이었습니다. 바로 이런 문제에서 초기 시스템은 제게 훨씬 더 제한적으로 느껴졌습니다.

가장 중요한 발전은 더 나은 코드 생성이 아니었다

어느 시점부터 제 관점이 달라졌습니다. 물론 코드 생성도 좋아졌습니다. 하지만 제게 더 중요한 변화는 다른 곳에 있었습니다.

LLM이 제 업무에서 더 가치 있어진 가장 큰 이유 중 하나는 기존 코드를 더 잘 읽기 시작했기 때문입니다.

관심 단위가 함수 하나에서 끝나지 않게 됐습니다. 여러 파일을 함께 보고, 의존성을 찾고, 낯선 Feature를 탐색하고, 오류를 여러 Layer에 걸쳐 추적하고, 기존 Pattern을 식별하고, 여러 해결 방법을 현재 아키텍처와 비교할 수 있게 됐습니다.

낯선 기술을 다루는 방식도 달라졌습니다. 예전에는 새로운 Library나 익숙하지 않은 Subsystem을 만나면 먼저 문서를 읽고, 진입점을 찾고, 코드를 검색하고, 예제에서부터 천천히 Mental Model을 만들어야 했습니다. 지금은 LLM이 이 첫 번째 방향 탐색 단계를 크게 줄여 줄 수 있습니다.

LLM이 대신 생각해 주는 것은 아닙니다. Search Space를 좁혀 주는 것입니다. Agent는 진입점을 찾고, 관련 파일을 모으고, 의존성을 따라가고, Bug 원인에 대한 가설을 만들고, Proof of Concept을 준비할 수 있습니다. 그 결과가 곧 완전한 시스템 이해를 뜻하는 것은 아니지만, 제가 시스템을 이해하는 데 필요한 경로는 훨씬 짧아질 수 있습니다.

저에게는 다음에 생성되는 메서드가 조금 더 우아해졌다는 것보다 이 변화가 훨씬 중요했습니다.

Assistant에서 Agent로

Tool Use가 가능해지면서 작업 방식은 다시 한 번 크게 달라졌습니다. 전통적인 Chat은 우선 제가 입력한 것만 압니다. 반면 Coding Agent는 권한 범위 안에서 Repository를 검색하고, 파일을 읽고 수정하고, 테스트를 실행하고, Compiler나 Linter 오류를 확인하고, 그 결과에 반응할 수 있습니다.

그렇게 되면 흐름이 달라집니다.

겉으로는 점진적인 변화처럼 보일 수 있습니다. 실제로는 꽤 큰 차이입니다.

제 개인 프로젝트에서는 이제 명확하게 범위를 제한한 Feature를 Coding Agent에게 설명하고 여러 기술 Layer에 걸친 일관된 구현을 받는 것이 현실적인 Workflow가 됐습니다. 시스템에 따라 Data Model이나 Backend에서 시작해 API와 State를 거쳐 UI까지 이어질 수도 있습니다.

모든 작업이나 모든 모델에서 가능한 것은 아닙니다. 충분한 Context가 필요하고, 자동으로 좋은 해결책이 나오는 것도 아니며, 무엇보다 Review를 대체하지 않습니다. 하지만 이런 Workflow 자체가 실제로 쓸 수 있는 수준이 됐다는 사실만으로도 지금의 작업 방식은 처음 LLM을 사용하던 시기와 본질적으로 다릅니다.

연구에서도 전통적인 Assistive System과 더 Agentic한 도구 사이의 차이를 점점 더 구체적으로 다루기 시작했습니다. 예를 들어 Copilot과 Coding Agent를 비교한 CHI의 통제 연구에서는 자동화 수준이 높은 Agent가 전통적인 보조 시스템보다 더 많은 작업을 맡을 수 있었고, 그 과정에서 사람의 노력을 줄일 수 있었다고 보고합니다. 동시에 사용자는 Agent가 실제로 무엇을 하고 있는지 이해하고 그 행동을 평가할 수 있어야 한다는 새로운 요구도 생겼습니다. [1]

이 결과는 제 경험과 잘 맞습니다. 더 많은 Autonomy가 사람의 일을 반드시 없애는 것은 아닙니다. 대신 사람의 일을 바꿉니다.

Agent는 완벽하지 않아도 충분히 가치 있다

AI와 소프트웨어 개발에 관한 논의에서는 제게 다소 이상하게 느껴지는 기준이 자주 등장합니다. AI가 경험 많은 개발자를 완전히 자율적으로 대체할 수 있는지가 질문이 됩니다. 그리고 오늘 그 답이 “아니다”라면 기술 전체가 과대평가됐다는 결론으로 쉽게 이어집니다.

제 일상 업무에서는 다른 질문이 훨씬 중요합니다.

이 도구를 사용하면서 나는 얼마나 많은 고품질 작업을 안정적으로 책임질 수 있는가?

Coding Agent는 완벽하지 않아도 엄청나게 유용할 수 있습니다. 낯선 영역을 탐색하는 시간을 줄이고, 반나절 걸릴 Proof of Concept을 한 시간 안에 준비하고, 수많은 파일에 걸친 반복 작업을 일관되게 수행할 수 있다면 그것만으로도 상당한 가치가 있습니다. 여러 Layer를 따라 Bug를 추적하고, 가능한 원인을 정리하고, 잘 작성된 Spec에 따라 변경을 대부분 구현한 뒤 제가 아키텍처와 결과를 검토하는 경우도 마찬가지입니다.

중요한 것은 사람의 작업이 사라지는지가 아닙니다. 제가 시간을 어디에 쓰는지가 바뀐다는 점입니다.

개인적인 체감은 분명합니다. 많은 작업에서 저는 현대적인 LLM과 Coding Agent를 사용할 때 훨씬 빠릅니다. 하지만 그 경험만으로 일반적인 생산성 주장을 할 수는 없습니다. 지금까지의 연구는 훨씬 더 복잡한 그림을 보여 줍니다.

2026년에 발표된 세 건의 무작위 현장 실험은 총 4,867명의 개발자를 대상으로 했고, AI Coding Assistance를 사용한 개발자 그룹에서 완료된 작업 수가 종합적으로 약 26% 증가했다고 보고했습니다. 특히 경험이 적은 개발자에게서 효과가 더 크게 나타났습니다. 다만 연구 대상은 Coding Assistant였고, 오늘날의 모든 Agentic Workflow를 다룬 것은 아닙니다. [2]

반대로 많은 논의를 불러온 한 실험에서는 자신이 오랫동안 알고 있던 프로젝트에서 작업하는 16명의 숙련된 Open Source 개발자가 246개의 실제 과제를 수행했습니다. 이 조건에서는 당시의 AI 도구 사용을 허용했을 때 오히려 작업 시간이 19% 늘어났습니다. 특히 흥미로운 점은 실험이 끝난 뒤에도 개발자들이 자신이 AI를 사용할 때 더 빨랐다고 믿었다는 것입니다. [3]

23개의 연구를 종합한 2026년 Meta-analysis에서는 다시 중간 정도의 긍정적인 생산성 효과가 나타났지만, 연구 환경 사이의 차이가 매우 컸습니다. 통제된 실험에서는 Open Source나 기업 환경보다 효과가 더 크게 나타나는 경향이 있었습니다. [4]

저는 이것을 서둘러 해결해야 할 모순이라고 생각하지 않습니다. 오히려 더 흥미로운 결론일 수 있습니다. AI Assistance는 생산성을 높일 수 있지만, 효과의 크기와 경우에 따라서는 방향까지도 Context, 작업 유형, Tooling, 개발자에 크게 좌우될 수 있습니다.

“AI가 개발자를 50% 더 빠르게 만든다”보다 덜 자극적인 문장입니다. 하지만 Engineering 관점에서는 훨씬 쓸모 있습니다.

빠르게 생성된 코드가 좋은 해결책이라는 뜻은 아니다

LLM을 사용하면서도 바뀌지 않은 습관이 하나 있습니다. 저는 코드가 동작한다는 이유만으로 받아들이지 않습니다. 예전에도 그랬고, Coding Agent를 사용하는 지금은 더 중요해졌습니다.

Agent는 테스트를 통과시키면서도 잘못된 System Boundary를 선택할 수 있습니다. Requirement를 정확히 구현하면서 이후 요구사항을 방해하는 Architecture Decision을 할 수도 있습니다. 기존 Workaround를 깔끔하게 복제하고, 국소적인 일관성을 만들면서 시스템 전체의 불일치를 오히려 강화할 수도 있습니다. 기술적으로는 맞지만 시스템 안에서는 잘못된 위치에 솔루션을 배치할 수도 있습니다.

AI-generated code의 품질을 다룬 연구에서도 Verification을 선택적인 마지막 단계로 보지 말아야 할 이유를 충분히 찾을 수 있습니다. AI 코드의 Security에 관한 Systematic Review는 생성된 솔루션의 알려진 약점을 정리하고, 적절한 Review와 Verification 프로세스의 중요성을 강조합니다. [5]

이 말은 AI가 만든 코드는 안전하지 않고 사람이 만든 코드는 안전하다는 뜻이 아닙니다. 그렇게 단순한 문제는 아닙니다. 코드는 사람이 만들었다는 이유나 모델이 만들었다는 이유로 품질이 생기지 않습니다. 동일한 도메인, 아키텍처, 기능, Security 품질 기준을 통과해야 합니다.

바로 이 지점에서 저는 개인 프로젝트에서 반복해서 흥미로운 현상을 관찰합니다. 일부 프로젝트는 꽤 명시적인 규칙을 가지고 있습니다. Architecture Rules, Agent Files, Skills, Memories, 예제, 그리고 Component, Application Logic, State, Infrastructure에 무엇이 들어가야 하는지 분명한 경계가 있습니다. 그럼에도 특정 Pattern이 다시 나타납니다.

몇 차례 변경 후 Component가 다시 도메인 흐름을 Orchestration하기 시작하거나, 깔끔했던 Reactive Flow 중간에 Imperative 구현이 들어가거나, 당장 구현하기 쉽다는 이유로 Layer Boundary가 국소적으로 느슨해지는 식입니다. 항상 즉시 일어나는 것도 아니고 모든 Agent에서 동일하게 나타나는 것도 아닙니다. 하지만 반복적인 실무 관찰이라고 부를 만큼 자주 보입니다.

개인적인 관찰: 명시적인 아키텍처 규칙은 문제가 될 수 있는 결정을 크게 줄여 줍니다. 하지만 긴 작업 과정에서 Coding Agent가 익숙하고 국소적으로 그럴듯한 Pattern으로 다시 기울어지는 것을 자동으로 막아 주지는 않습니다.

왜 이런 현상이 나타나는지는 이 시리즈에서 다룰 질문 중 하나입니다. 그렇다고 여기서 곧바로 LLM은 아키텍처를 이해할 수 없다고 결론 내리는 것은 너무 단순합니다. 더 흥미로운 질문은 모델, Context, 기존 코드, 로컬 예제, Spec, Tooling이 함께 작용하면서 어떤 해결책이 다음 단계로 가장 그럴듯하게 보이게 만드는가입니다.

AI는 촉매다

오늘 Coding Agent와 관련해 이야기하는 많은 문제는 놀라울 만큼 오래된 소프트웨어 엔지니어링의 문제입니다. 사람도 기존 코드를 복사하고, 로컬 예제를 참고하고, 모호한 Requirement를 다르게 해석하고, Workaround를 이어받고, 원래의 맥락이 오래전에 사라진 결정 위에 계속 코드를 쌓습니다.

Coding Agent가 이런 메커니즘을 만들어 낸 것은 아닙니다. 하지만 속도를 크게 높일 수 있습니다.

어떤 시스템 안에 좋지 않은 Workaround가 하나 있다고 생각해 봅시다. 동작하고, 새 작업과 가까운 위치에 있고, 이미 정착된 Pattern처럼 보입니다. 나중의 Change가 이것을 참고하면서 같은 Workaround가 한 번 더 등장합니다. 그러면 Repository 안에서 더 눈에 띄게 되고, 다음 비슷한 작업에서는 의도적인 로컬 규칙처럼 보일 가능성이 더 커집니다.

이 현상은 Broken Window Effect와 닮아 있습니다. 그렇다고 이것이 Coding Agent에 대한 보편적인 법칙으로 이미 과학적으로 입증됐다고 주장하는 것은 아닙니다. 현재로서는 반복적인 관찰에서 나온 Hypothesis에 가깝습니다. 기존 코드가 새로운 결정에서 중요한 Context로 작동한다면, 자주 보이는 로컬 Pattern은 이후 자신이 다시 재현될 가능성을 높일 수 있다는 생각입니다.

흥미로운 점은 이 흐름이 반드시 부정적으로만 작동하지 않는다는 것입니다. 좋은 Pattern도 같은 방식으로 더 잘 보이고, 반복되고, 시스템 전체의 일관성을 높일 수 있습니다.

그래서 저는 AI를 완전히 새로운 문제의 원인으로 보는 것보다 촉매 또는 증폭기로 보는 설명을 더 선호합니다.

AI는 소프트웨어 엔지니어링의 많은 익숙한 문제를 새로 만들어 내지 않습니다. 다만 그 문제의 속도와 범위를 크게 늘릴 수 있습니다.

좋은 Engineering Practice에도 같은 논리가 적용됩니다. Architecture가 덜 중요해지는 것이 아니라, 그 효과가 훨씬 빠르게 드러날 수 있습니다.

사람은 아직 놀랄 만큼 효과적으로 방향을 바로잡을 수 있다

여기까지 읽으면 Coding Agent는 결국 아키텍처적으로 어딘가로 Drift하기 때문에 항상 의심하면서 지켜봐야 한다는 인상을 받을 수 있습니다. 제 경험은 그렇지 않습니다.

중요한 점은 속도가 양쪽에 모두 작용한다는 것입니다. Agent는 짧은 시간에 많은 것을 구현할 수 있습니다. 하지만 경험 많은 개발자도 해결책이 잘못된 방향으로 가고 있다는 것을 일찍 알아차리는 경우가 많습니다. 그러면 전체 작업을 버리는 대신 Spec을 더 구체화하고, Boundary를 명시하고, 참고할 Pattern을 지정하거나, 잘못된 Abstraction을 제거합니다. 그리고 Agent가 계속 작업합니다.

Agent가 빠르게 작업
↓
결과는 대체로 유용함
↓
문제가 되는 방향을 일찍 발견
↓
Context 또는 Constraint 수정
↓
Agent가 구현 계속

현재 저에게는 이것이 가장 생산적인 Agentic Work 방식 중 하나입니다. “전부 끝내고 나면 알려 줘”가 아니라, “명확하게 제한된 공간 안에서는 상당 부분 독립적으로 일하되, 그 공간의 경계를 넘어갈 수 있는 결정은 내가 특히 주의해서 본다”에 가깝습니다.

그래서 2026년 현재, 저는 깊은 시스템 이해를 가진 경험 많은 개발자를 전문적인 Agentic Work의 중요한 구성 요소로 봅니다. 이것은 5년이나 10년 뒤 모델이 무엇을 할 수 있을지에 대한 주장과는 다릅니다. 지금 제가 실제로 일하고 있는 상태를 설명하는 것입니다.

제가 Agent에게 Implementation Work를 더 많이 위임할수록, 현재는 만들어지는 솔루션이 시스템에 맞는지 판단할 수 있는 사람이 더 중요해집니다.

이 때문에 Repository 전체에 걸친 변경과 완전한 Software Autonomy를 같은 것으로 볼 수 없습니다. 최근 Benchmark는 개별 Code Change뿐 아니라 Environment Setup, Implementation, Verification까지 포함한 전체 흐름을 평가하려고 점점 더 시도하고 있습니다. 예를 들어 2026년 SWE-Cycle Preprint에서는 원래 분리돼 있던 작업들을 Human Scaffolding 없이 하나의 End-to-End 프로세스로 수행해야 할 때 성능이 크게 떨어진다고 보고합니다. [6]

오늘의 Agent는 놀라울 만큼 일관된 대규모 변경을 수행할 수 있습니다. 그렇다고 임의의 소프트웨어 프로젝트를 완전히 자율적으로 맡을 수 있다는 뜻은 아닙니다. 이 두 문장 사이에는 상당히 큰 공간이 있고, 지금 제게 가장 흥미로운 실제 작업은 바로 그 공간 안에서 이루어집니다.

진짜 질문이 바뀌었다

2023년 저는 이렇게 물었습니다.

AI가 실제로 쓸 만한 코드를 작성할 수 있을까?

지금은 이 질문이 거의 흥미롭지 않습니다. 물론 AI는 코드를 작성할 수 있습니다. 항상 맞는 것도 아니고, 항상 좋은 것도 아니며, 충분한 Context 없이 가능한 것도 아닙니다. 하지만 쓸 만한 코드 생성 자체가 가능한지는 더 이상 열린 질문이 아닙니다.

지금 더 흥미로운 질문은 이것입니다.

이 속도를 어떻게 사용해야 좋은 소프트웨어가 만들어질까?

이 질문은 훨씬 큰 영역을 엽니다. 왜 결과가 항상 재현되지 않는지, Context가 실제로 무엇을 의미하는지, Memory와 Skills가 무엇을 할 수 있고 무엇을 할 수 없는지, SWE-bench 같은 Benchmark가 실제로 무엇을 측정하는지 이해해야 합니다. 규칙이 있는데도 Agent가 왜 Drift할 수 있는지, Implementation이 점점 저렴해질 때 Requirement는 얼마나 정확해야 하는지, Architecture가 가능한 Solution Space를 어떻게 제한하는지, 그리고 소프트웨어를 생성하는 속도가 사람이 편안하게 Review할 수 있는 속도를 넘어설 때 Verification을 어떻게 해야 하는지도 물어야 합니다.

경제적이고 조직적인 질문도 있습니다. 큰 Frontier Model이 실제로 필요한 때는 언제일까요? 더 작거나 Local Model이면 충분한 경우는 언제일까요? Token뿐 아니라 Review, Infrastructure, 잘못된 결정까지 포함하면 Agentic Work의 실제 비용은 얼마일까요? 더 많은 Implementation Work를 위임할 수 있게 되면 우리의 역할은 어떻게 달라질까요?

이 시리즈는 이런 질문들 중 일부를 살펴볼 것입니다. AI가 기존의 모든 소프트웨어 개발 문제를 갑자기 대체했기 때문이 아니라, 많은 오래된 문제를 새로운 조건 아래에서 다시 보이게 만들기 때문입니다.

2023년에 쓴 글은 이미 역사적인 글이 되었을 것이다

제가 이 글을 2023년에 썼다면 상당 부분은 지금 이미 하나의 역사적 스냅샷처럼 보였을 것입니다. 그것은 인상적인 변화이지만, 그렇다고 이제 반대 방향으로 똑같이 성급하게 주장해도 된다는 뜻은 아닙니다.

다음 변화가 얼마나 클지 우리는 모릅니다. 추가적인 Scaling이 언제부터 큰 효과를 내지 못할지도 모르고, 오늘의 한계 중 무엇이 더 좋은 모델로 사라질지, 어떤 문제가 사용 중인 접근 방식의 구조적인 특성으로 남을지도 알 수 없습니다.

그래서 저는 두 문장을 동시에 중요하게 생각합니다.

2026년의 한계를 영원한 한계로 만들어서는 안 됩니다.

동시에:

지난 3년의 이례적으로 빠른 발전을 무한한 미래로 그대로 외삽해서도 안 됩니다.

둘 다 추측입니다.

Software Engineering 관점에서는 현재 상태만으로도 충분히 중요합니다. 기술은 이미 우리가 전문적으로 다루는 법을 배워야 할 만큼 강력해졌습니다.

이 시리즈를 쓰는 이유

그래서 저는 이 시리즈를 AI 광고로 만들고 싶지도 않고, 모든 것이 과대평가됐다고 주장하는 글 모음으로 만들고 싶지도 않습니다. 모델 순위표에도 큰 관심은 없습니다. 시리즈가 끝나기 전에 이미 오래된 정보가 될 가능성이 높기 때문입니다.

제가 궁금한 것은 Engineering Question입니다. 오늘 실제로 무엇이 가능한가? 어디에서는 예상보다 잘 작동하는가? 어떤 위험이 생기는가? 어떤 오래된 문제들이 단지 더 빨라졌을 뿐인가? 어떤 Workflow가 도움이 되는가? 어떤 규칙은 기대만큼 잘 작동하지 않는가? 무엇을 측정할 수 있고 무엇은 여전히 경험 지식인가? 무엇보다 다음 세대 모델이 또 크게 발전하더라도 어떤 원칙은 여전히 유효할 것인가?

지난 몇 년 동안 LLM에 대한 제 관점은 여러 번 바뀌었습니다. 인상적인 Text Generator에서 쓸 만한 Coding Assistant로, 분석과 탐색 도구로, 그리고 이제는 조건이 맞을 때 구체적인 구현의 상당 부분을 맡길 수 있는 Agent로 변했습니다.

이것은 “그저 Noise”도 아니고, 사람의 지시 없이 복잡한 시스템을 안정적으로 맡을 수 있는 자율적인 Software Developer도 아닙니다. 이제는 두 설명 모두 지나치게 편한 설명처럼 느껴집니다.

그 사이의 현실이 훨씬 더 흥미롭습니다. 그리고 이미 충분히 실용적이기 때문에 Software Engineering은 이에 대한 답을 준비해야 합니다.

그래서 이 시리즈는 무엇보다 하나의 현재 상태에 대한 기록입니다.

관찰하고, 이해하고, 실험하고, 검증한 뒤 가능한 한 견고한 Engineering Principle을 도출한다.

하지만 Agent가 어떤 때는 놀라울 정도로 좋은 결정을 하고, 어떤 때는 놀라울 정도로 이상한 결정을 하는 이유를 살펴보기 전에 먼저 한 걸음 뒤로 물러나야 합니다.

LLM 안에서는 실제로 무슨 일이 일어날까요? Training과 Inference는 무엇일까요? Token은 무엇이고 Context는 무엇일까요? 그리고 결과가 probabilistic하다고 말할 때 그것은 실제로 무엇을 의미할까요?

다음 글은 여기서 시작합니다.

참고 자료

[1] Valerie Chen, Ameet Talwalkar, Robert Brennan, Graham Neubig: Code with Me or for Me? How Increasing AI Automation Transforms Developer Workflows. Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems, 2026. DOI: 10.1145/3772318.3790850.

[2] Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz: The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Management Science, 2026. DOI: 10.1287/mnsc.2025.00535.

[3] Joel Becker, Nate Rush, Elizabeth Barnes, David Rein: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Preprint, 2025. arXiv: 2507.09089. DOI: 10.48550/arXiv.2507.09089.

[4] Sebastian Maier, Moritz Gunzenhäuser, J. Schweisthal, Manuel Schneider, S. Feuerriegel: A meta-analysis of the effect of generative AI on productivity and learning in programming. Preprint, 2026. arXiv: 2605.04779.

[5] Claudia Negri-Ribalta, Rémi Géraud-Stewart, Anastasia Sergeeva, Gabriele Lenzini: A systematic literature review on the impact of AI models on the security of code generation. Frontiers in Big Data 7, 2024. DOI: 10.3389/fdata.2024.1386720.

[6] Hao Guan, Lingyue Fu, Shao Zhang, Yaoming Zhu, Kangning Zhang, Lin Qiu, Xunliang Cai, Xuezhi Cao, Weiwen Liu, Weinan Zhang, Yong Yu: SWE-Cycle: Benchmarking Code Agents across the Complete Issue Resolution Cycle. Preprint, 2026. arXiv:2605.13139.