Agentic Work in Real Life

LLM과 Coding Agent는 소프트웨어 개발을 바꾸고 있습니다. 이제 그 사실 자체를 부정하기는 어렵습니다. 훨씬 더 어려운 질문은 무엇이 실제로 가능하고, 왜 가능하며, 어디에 한계가 있는가입니다.

AI에 관한 논의를 조금만 따라가도 곧 두 가지 극단을 만나게 됩니다. 한쪽에서는 LLM이 머지않아 개발자를 대부분 대체할 것이라고 말합니다. 다른 쪽에서는 그저 그럴듯한 헛소리를 만들어 내는 고급 자동완성 도구에 불과하다고 평가절하합니다.

이 시리즈는 의도적으로 어느 쪽에도 서지 않으려 합니다.

AI를 옹호하기 위한 글도, 반대하기 위한 글도 아닙니다. 그리고 소위 “완벽한 Prompt”를 모아 놓은 가이드도 아닙니다.

여기서 다루려는 것은 Agentic Work in Real Life입니다. LLM과 Coding Agent를 실제 업무에서 사용하며 얻은 경험, 그 뒤에서 작동하는 메커니즘, 그리고 그것이 전문 소프트웨어 엔지니어링에 가져오는 변화를 살펴봅니다.

이 시스템들은 실제로 무엇을 할 수 있을까?

그러려면 먼저 우리가 무엇을 사용하고 있는지 이해해야 합니다.

LLM이란 무엇일까요? Inference는 무엇을 뜻할까요? Token, Context, Memory, Skill은 각각 무엇일까요? 왜 같은 작업을 주어도 항상 같은 해결책이 나오지 않을까요? SWE-bench 점수는 실제로 무엇을 측정하고, 무엇을 측정하지 않을까요?

AI를 둘러싼 많은 용어가 이제는 너무 자연스럽게 사용되지만, 실제 의미는 대략적으로만 알고 있는 경우가 많습니다. 그런데도 그 위에서 생산성, 품질, 심지어 직업군 전체의 미래에 대한 큰 주장이 만들어집니다.

그래서 이 시리즈는 의도적으로 기본 개념에서 시작합니다.

Machine Learning의 수학을 끝까지 파고들기 위해서가 아니라, LLM이 왜 지금과 같은 방식으로 행동하는지 이해할 수 있는 견고한 mental model을 만들기 위해서입니다.

“동작한다”는 것은 무엇을 의미할까?

오늘날 Coding Agent는 놀라운 속도로 코드를 만들어 낼 수 있습니다.

하지만 속도는 품질에 대해 거의 아무것도 말해 주지 않습니다.

어떤 해결책은 동작하면서도 나쁠 수 있습니다. 불필요한 결합을 만들고, 도메인 규칙을 잘못된 계층에 배치하고, 기존 아키텍처를 위반하거나, 유지보수를 어렵게 만들고, 장기적으로 높은 비용을 만들 수도 있습니다.

따라서 “동작한다”는 것은 품질의 가장 낮은 기준일 뿐입니다.

더 중요한 질문은 이것입니다.

좋은 해결책이란 무엇이며, 누가 그것이 좋은지 판단할 수 있는가?

순수한 코드 생산 비용이 낮아질수록 병목은 Requirements, 아키텍처, 계획, Review, Verification 쪽으로 이동합니다.

그에 따라 숙련된 개발자의 역할도 달라집니다.

새로운 조건에서 다시 만나는 오래된 문제들

새로운 AI 문제처럼 보이는 것들 중 상당수는 사실 소프트웨어 엔지니어링의 아주 오래된 문제입니다.

불명확한 Requirements는 항상 위험했습니다. 나쁜 아키텍처는 늘 복제되었습니다. 암묵지는 언제나 위험 요소였습니다. 잘못된 가정 하나가 이후의 잘못된 결정을 연쇄적으로 만들 수도 있었습니다.

다만 Coding Agent는 그 속도와 규모를 바꿉니다.

사람이라면 잘못된 가정을 바탕으로 큰 구현을 완성하는 데 며칠이 걸릴 수 있습니다. Agent는 짧은 시간 안에 수십 개의 파일을 일관되게 수정하고, 테스트를 추가하고, 잘못된 해석을 시스템 깊숙이 정착시킬 수 있습니다.

그렇다고 Requirements Engineering, 아키텍처, Verification이 불필요해지는 것은 아닙니다.

오히려 더 중요해질 가능성이 있습니다.

2026년 말 기준

이 시리즈는 2026년 말의 상황을 기록한 스냅샷입니다.

이 주제에서는 이 점이 특히 중요합니다.

LLM은 불과 몇 년 사이에 엄청난 속도로 발전했습니다. 오늘은 명확한 한계처럼 보이는 능력도 짧은 시간 안에 기술적으로 해결되거나 적어도 크게 개선될 수 있습니다.

그래서 이 시리즈는 다음을 의도적으로 구분합니다.

오늘 관찰할 수 있는 능력과 한계,
사용되는 방법 자체의 근본적인 특성,
현재의 발전에서 도출한 판단,
그리고 명확하게 가설로 표시한 미래 전망.

구체적인 모델, 가격, Benchmark는 특정 시점의 사례로만 사용합니다.

GPT, Claude, Qwen 또는 다른 모델이 오늘 어떤 Benchmark에서 몇 점 더 높게 나오는지는, 그 Benchmark가 실제로 무엇을 측정하며 그 결과에서 현실의 소프트웨어 개발에 대해 어떤 결론을 도출할 수 있는가보다 훨씬 덜 중요합니다.

그렇다면 우리는 어떻게 변할까?

가장 어려운 질문은 기술적인 것이 아닐 수도 있습니다.

LLM이 현재 Junior 또는 Mid-level 개발자가 담당하는 많은 작업을 수행할 수 있게 된다면, 기업 입장에서는 단기적으로 이들을 덜 채용하는 것이 경제적으로 합리적으로 보일 수 있습니다.

하지만 Junior의 일은 단순한 생산 능력만이 아니었습니다.

그 자체가 학습 경로이기도 했습니다.

숙련된 개발자가 앞으로 점점 더 Planner, Reviewer, Architect, Orchestrator의 역할을 맡게 된다면 중요한 질문이 생깁니다.

그 과정에서 필요한 학습 경로를 없애 버린다면, 미래의 숙련된 개발자는 어디에서 나올까?

이런 조직적, 경제적, 사회적 결과 역시 Agentic Work를 현실적으로 바라보기 위해 함께 다뤄야 합니다.

이 시리즈가 지향하는 것

의견보다 메커니즘을 먼저 봅니다.

놀라운 능력을 일부러 깎아내리지 않습니다. 문제를 감추지도 않습니다. 사람을 이상화하지 않는 것처럼 기계도 이상화하지 않습니다.

그리고 관찰이 전망으로 넘어가는 순간에는 그 차이가 분명하게 드러나야 합니다.

이 시리즈의 목표는 결국 AI가 소프트웨어 개발에 좋은지 나쁜지를 증명하는 것이 아닙니다.

목표는 오늘 어디에서 의미 있게 사용할 수 있는지, 그러기 위해 어떤 조건이 필요한지, 그리고 그 과정에서 우리가 동시에 어떤 새로운 문제를 만들어 낼 수 있는지 더 잘 판단하는 것입니다.

글 목록

추가로 LLM / Agentic Engineering 용어집에서 이 시리즈의 핵심 용어를 한곳에 정리합니다.