[번역] 팩토리 모델: 코딩 에이전트가 소프트웨어 엔지니어링을 어떻게 바꾸고 있는가

원문: The Factory Model: How Coding Agents Changed Software Engineering

 

최근 에이전트 기반 엔지니어링(agentic engineering) 분야에서는 무언가가 달라졌다는 느낌이 듭니다. 단순히 도구가 조금 더 좋아지고 워크플로우가 점진적으로 발전한 수준이 아닙니다. 한 단계 도약이 일어났습니다. 수십 년 동안 소프트웨어를 만들어온 개발자들은 공통적으로 이렇게 말합니다. "개발이라는 기술의 무게중심이 이동했다."

 

지금 가장 중요한 것은 두 가지 생각을 동시에 붙들고 있는 것입니다. 코딩은 극적으로 변했다. 하지만 소프트웨어 엔지니어링의 본질은 변하지 않았다. 흥미로운 이야기는 바로 이 둘 사이에 있습니다. 그리고 이 간극을 얼마나 명확하게 이해하느냐가 앞으로 이 시대에서 성장할 엔지니어와 뒤처질 엔지니어를 가르게 될 것입니다.

 

최근 저는 Cursor의 Michael Truell이 이 주제에 대해 남긴 생각들을 읽었고, 거기에 제 생각을 조금 덧붙여보고 싶었습니다.

추상화의 역사

소프트웨어 엔지니어링의 역사는 곧 추상화 수준을 높여온 역사입니다. 우리는 비트에서 명령어로, 명령어에서 함수로, 함수에서 객체로, 객체에서 서비스로, 다시 서비스에서 분산 시스템으로 이동해왔습니다. 추상화 계층이 한 단계씩 올라갈 때마다 개발자 개인의 생산성은 향상되었고, 소프트웨어를 만드는 데 참여할 수 있는 사람들의 수도 늘어났습니다.

 

어셈블리는 C에게 자리를 내주었습니다. C는 다시 관리형 언어(Managed Language)와 가비지 컬렉션에게 자리를 내주었고, 관리형 언어는 프레임워크, 패키지 생태계, 클라우드 인프라로 이어졌습니다. 당시에는 모든 변화가 파괴적으로 느껴졌지만, 지금 돌아보면 그 모든 변화는 하나의 길고 일관된 흐름 속에 있었던 자연스러운 다음 단계였습니다.

 

그리고 지금 우리가 겪고 있는 변화 역시 그 연장선상에 있습니다. 우리는 이제 코드를 작성하는 것에서 코드를 작성하는 시스템을 조율하는 것으로 이동하고 있습니다.

 

이러한 관점은 Grady Booch가 제시한 것으로, 그는 이를 소프트웨어의 세 번째 시대 라고 부릅니다. 추상화 수준이 계속 높아지면서 개발자의 역할이 명령어를 작성하는 것에서 의도를 정의하는 것으로 바뀌는, 새로운 황금기라는 의미입니다.

 

이 관점이 중요한 이유는 무엇을 계속 붙잡아야 하고, 무엇을 내려놓아야 하는지를 알려주기 때문입니다.

AI 코딩 도구의 3세대

이 변화를 이해하려면 각 세대를 명확하게 구분해서 볼 필요가 있습니다. 서로 다른 세대를 하나로 뭉뚱그려 생각하면 실제로 얼마나 큰 변화가 일어났는지를 과소평가하게 되기 때문입니다.

 

첫 번째 세대는 더 똑똑한 자동완성 도구였습니다. 다음 줄을 예측하고, 보일러플레이트를 채워주고, 반복적인 패턴에서 타이핑을 줄여주는 도구들입니다. 분명 유용했습니다. 실제로 시간을 절약해주기도 했습니다. 하지만 작업 방식 자체는 달라지지 않았습니다. 여전히 개발자가 운전하고 도구는 보조하는 구조였습니다. 피드백 루프는 코드 작성 → 실행 → 디버깅 → 반복 이었습니다. AI는 그 과정 안의 마찰을 줄여주는 역할을 했을 뿐입니다.

 

두 번째 세대에서는 동기식 에이전트가 등장했습니다. 개발자는 자연어로 작업을 설명하고, 모델은 코드를 생성했습니다. 개발자는 결과를 검토하고 수정한 뒤, 원하는 결과가 나올 때까지 반복했습니다. 추상화 수준은 한 단계 더 올라갔습니다. 타이핑은 줄어들고 의도를 설명하는 비중은 커졌습니다. 하지만 여전히 모든 단계에 사람이 개입해야 했습니다. 에이전트는 자율적으로 일하는 존재가 아니라 협업자에 가까웠습니다. 컨텍스트를 유지하고, 다음 방향을 결정하고, 실수를 실시간으로 잡아내는 일은 여전히 개발자의 몫이었습니다.

 

세 번째 세대에서는 자율 에이전트가 등장했습니다. 이 에이전트들은 명세를 전달받으면 30분, 1시간, 몇 시간, 앞으로는 며칠 동안 스스로 작업을 수행할 수 있습니다. 개발 환경을 구성하고, 의존성을 설치하고, 테스트를 작성하고, 실패를 마주하면 인터넷에서 해결책을 찾아보고, 문제를 수정한 뒤 구현을 이어갑니다. 다시 테스트를 수행하고, 서비스를 구성하고, 최종적으로 검토할 수 있는 결과물을 만들어냅니다. 개발자는 작업을 넘긴 뒤 다른 일을 하다가 나중에 로그, 프리뷰, PR을 확인하러 돌아옵니다. 더 이상 한 줄 한 줄 상호작용하지 않습니다. 이제는 결과를 정의하고 결과물을 검토하는 방식으로 일합니다. 바로 이 지점에서 에이전트 스웜이나 자기 개선 에이전트 같은 개념이 등장합니다.

 

이 변화는 직접 경험해보기 전까지는 쉽게 실감하기 어렵습니다. 불과 몇 달 전만 해도 주말 프로젝트로 여겨졌던 작업들이 이제는 에이전트에게 맡겨두고 30분 뒤 확인하는 일이 되어가고 있습니다.

팩토리라는 사고방식

이 새로운 패러다임을 이해하는 데 가장 유용한 사고방식은 이것입니다. 여러분은 더 이상 단순히 코드를 작성하는 사람이 아닙니다. 이제는 소프트웨어를 만들어내는 공장을 만드는 사람입니다.

 

그 공장은 수많은 에이전트들로 구성됩니다. 각 에이전트는 작업, 도구 모음(저장소, 테스트 러너, 배포 스크립트, 문서), 컨텍스트(명세, 아키텍처 결정 사항, 기존 제약 조건), 그리고 피드백 루프를 가지고 있습니다. 이제는 하나의 작업을 위해 하나의 에이전트를 옆에서 계속 이끌어주는 대신, 여러 에이전트를 병렬로 실행합니다. 어떤 에이전트는 백엔드 리팩터링을 담당하고, 다른 에이전트는 기능을 구현합니다. 또 다른 에이전트는 통합 테스트를 작성하고, 또 다른 에이전트는 문서를 업데이트합니다. 개발자는 결과물을 검토하고, 피드백을 제공하고, 명세를 다듬고, 다시 배포합니다.

 

이 비유는 처음 생각하는 것보다 훨씬 깊습니다. 공장에는 품질 관리가 있습니다. 공장에는 작업 절차를 정리한 문서가 있습니다. 공장에서는 입력값이 정확하게 정의되어야 원하는 결과물이 나옵니다. 운영 환경이 불안정하면 공장은 멈춰섭니다. 이러한 특성은 모두 에이전트 기반 소프트웨어 개발에 그대로 대응됩니다. 그리고 이 비유를 진지하게 받아들이면, 실제로 어디에 투자해야 하는지가 보이기 시작합니다.

 

이 모델을 적극적으로 도입한 팀들에서는 이미 머지되는 PR의 상당수가 클라우드 환경에서 자율적으로 동작하는 에이전트들에 의해 만들어지고 있습니다. 이제는 더 이상 이론적인 이야기가 아닙니다. 점점 더 많은 엔지니어링 조직에서 실제로 벌어지고 있는 일입니다.

 

Cursor에서 이야기한 다음과 같은 표현들도 같은 맥락에 있습니다. "개발자의 역할은 더 이상 제품 자체를 만드는 것이 아니라, 소프트웨어를 만들어내는 시스템, 즉 공장을 만드는 것으로 바뀌고 있다." "그리고 코드를 리뷰하는 것보다 아이디어를 리뷰하는 것이 훨씬 더 재미있다."(영상) 라는 말 역시 이 변화가 의미하는 바를 잘 보여줍니다.

신입 개발자 온보딩과 닮은 점

에이전트의 실제 동작 방식을 살펴보면 가장 흥미로운 점 중 하나가 있습니다. 에이전트의 작업 방식이 신입 개발자를 온보딩하는 과정과 놀라울 정도로 닮아 있다는 것입니다.

 

에이전트에게 명세를 전달하면, 먼저 작업을 여러 개의 하위 작업으로 나눕니다. 그리고 코드베이스를 탐색하며 전체 구조를 파악합니다. 막히는 부분이 생기면 커밋 히스토리를 뒤져보고, 특정 서브시스템을 마지막으로 수정한 사람이 누구인지 알아내기 위해 git blame을 실행합니다. 도메인 지식이 필요하면 슬랙 같은 커뮤니케이션 채널을 통해 적절한 사람에게 질문한 뒤 작업을 이어갑니다. 그리고 결과물이 요구사항을 만족할 때까지 반복합니다.

 

이 과정이 익숙하게 느껴지는 이유는, 실제로 사람들이 일하는 방식과 같기 때문입니다. 그리고 여기에는 중요한 의미가 담겨 있습니다. 슬랙과 이메일은 더 이상 사람과 사람 사이의 소통 수단만이 아닙니다. 앞으로는 사람과 에이전트 사이를 연결하는 인터페이스가 되어가고 있습니다. 깃 히스토리는 에이전트가 아키텍처 결정의 배경을 이해하기 위해 탐색하는 지식 그래프로 진화하고 있습니다. 문서는 단순한 참고 자료가 아니라 자율적으로 작업을 수행하기 위한 학습 자료가 되어가고 있습니다.

 

지금 여러분의 코드베이스에 무엇을 투자해야 할지 고민하고 있다면, 스스로에게 이런 질문을 던져보면 좋습니다. 지금 남아 있는 문서와 커밋 히스토리만으로, 새로 합류한 엔지니어가 왜 코드가 이런 구조로 작성되었는지 이해할 수 있을까? 만약 답이 “아니오”라면, 에이전트 역시 같은 지점에서 어려움을 겪게 될 것입니다. 그리고 여러분이 얻을 수 있는 레버리지 역시 그만큼 제한될 수밖에 없습니다.

명세가 곧 레버리지다

이제부터는 엔지니어로서 자신의 가치를 바라보는 방식을 바꿔줄 중요한 통찰을 이야기해보겠습니다.

 

만약 여러분이 20개, 30개, 50개의 에이전트를 동시에 조율할 수 있다면, 평범한 결과물과 뛰어난 결과물의 차이는 거의 전적으로 명세의 품질에 달려 있게 됩니다. 이 정도 규모에서는 모호한 사고가 단순히 작업 속도를 늦추는 수준에서 끝나지 않습니다. 그것은 증폭됩니다. 애매한 요구사항은 수십 개의 자율 에이전트에게 동시에 전파됩니다. 그리고 각 에이전트는 조금씩 다른 방향으로, 조금씩 다른 방식으로 잘못된 결과를 만들어냅니다. 초기에 잘못된 아키텍처 결정을 내리면 하나의 구현에만 영향을 주는 것이 아닙니다. 그 영향은 전체 에이전트 집단으로 퍼져나갑니다.

 

아키텍처, 시스템 간 통합 경계, 예외 상황, 실패 시나리오, 그리고 절대 깨져서는 안 되는 불변 조건들을 깊이 이해하지 못한다면 이런 환경에서 살아남을 수 있는 명세를 작성할 수 없습니다. 이제 명세는 더 이상 프롬프트가 아닙니다. 명세는 제품에 대한 사고를 명시적으로 표현한 결과물입니다.

 

이것이 바로 뛰어난 소프트웨어 엔지니어가 그렇지 않은 엔지니어보다 AI 도구로부터 더 큰 레버리지를 얻는 이유입니다. 반대가 아닙니다. 코드를 타이핑하는 기계적인 작업은 점점 자동화되고 있습니다. 반면 시스템을 이해하는 인지적 작업은 점점 더 큰 가치를 갖게 됩니다. 이제 아키텍처에 대한 깊은 이해와 시스템 사고를 기르는 데 투자한 한 시간은 단순히 자신의 생산성만 높이는 것이 아닙니다. 그 효과는 수십 개의 자율 에이전트 전체에 걸쳐 배가되어 돌아옵니다.

변하지 않은 것들

여기서는 조금 더 정확하게 짚고 넘어갈 필요가 있습니다. AI 코딩에 대한 과도한 기대 때문에 기존 소프트웨어 엔지니어링 역량이 더 이상 중요하지 않다는 인상을 받을 수 있기 때문입니다.

 

하지만 그렇지 않습니다. 에이전트 기반 개발 환경에서도 여전히 개발자에게 요구되는 것들을 살펴보겠습니다.

 

명확한 요구사항. 성공이 어떤 모습인지 평가 가능한 형태로 설명할 수 없다면, 아무리 많은 자율 실행을 시켜도 원하는 결과를 얻을 수 없습니다. 에이전트는 전달받지 못한 요구사항을 스스로 명확하게 만들 수 없습니다. 빈틈이 있으면 가정으로 채워 넣을 뿐입니다. 그리고 그런 가정들은 점점 쌓여갑니다.

 

좋은 추상화. 모듈 경계가 명확하고, 인터페이스가 일관되며, 관심사가 잘 분리된 시스템에서 작업하는 에이전트는 더 좋은 결과를 만들어냅니다. 반대로 모든 것이 서로 얽혀 있는 코드베이스에서 작업하는 에이전트는 그렇지 못합니다. 에이전트가 구현을 담당한다고 해서 클린 아키텍처의 가치가 줄어드는 것은 아닙니다. 오히려 더 중요해집니다. 에이전트는 자신이 작업하는 시스템의 특성을 그대로 증폭시키기 때문입니다.

 

신뢰할 수 있는 테스트. 이 부분은 별도의 섹션으로 다룰 가치가 있습니다.

 

신중한 트레이드오프. 에이전트는 주어진 목표를 최적화합니다. 하지만 상충하는 요구사항 사이의 균형을 맞추거나, 2차적인 영향을 예측하거나, 기술적으로는 맞지만 제품 관점에서는 잘못된 결정을 경고해주지는 않습니다. 그런 판단은 여전히 개발자의 몫입니다.

 

인간의 감독. 에이전트는 인상적인 결과물을 만들어냅니다. 하지만 동시에 확신에 찬 실수도 합니다. 문제는 결과물의 품질이 꽤 높다는 점입니다. 대충 훑어보는 수준의 리뷰는 충분히 통과할 정도입니다. 이는 곧 리뷰 역량의 기준이 낮아지는 것이 아니라 오히려 더 높아진다는 뜻입니다. 에이전트 시대에도 중요한 것은 여전히 같습니다. 명확한 요구사항, 좋은 설계, 신뢰할 수 있는 테스트, 올바른 트레이드오프 판단, 그리고 꼼꼼한 리뷰입니다. 달라진 것은 구현을 수행하는 주체이지, 좋은 소프트웨어를 만드는 원칙 자체는 아닙니다.

왜 테스트가 그 어느 때보다 중요해졌는가

좋은 테스트와 테스트 주도 개발(TDD)은 원래도 좋은 실천 방법이었습니다. 하지만 에이전트 기반 워크플로우에서는 거의 필수에 가까운 것이 되었습니다.

 

이 개념은 명확하게 설명할 가치가 있습니다. Red/Green TDD란 구현보다 먼저 테스트를 작성하는 것을 의미합니다. 먼저 테스트가 실패하는 것을 확인합니다(Red 단계). 그 다음 테스트가 통과할 때까지 구현을 반복합니다(Green 단계). 이 과정은 형식적인 절차가 아닙니다. 구현이 정말로 의도한 대로 동작하는지 확신할 수 있게 해주는 핵심 메커니즘입니다.

 

한 명의 개발자가 코드를 작성하는 환경에서 테스트 우선 개발을 생략했을 때의 문제는 비교적 단순합니다. 구현이 올바른지 여부와 관계없이 통과하는 테스트를 작성할 수도 있고, 나중에 회귀 버그로 이어질 엣지 케이스를 놓칠 수도 있습니다. 분명 비용이 발생하지만 감당 가능한 수준입니다.

 

하지만 수십 개의 병렬 작업에서 에이전트들이 코드를 생성하는 환경에서는 상황이 달라집니다. 비용이 기하급수적으로 커집니다. 테스트를 통과시키는 것을 목표로 하는 에이전트는 결국 테스트를 통과시킬 방법을 찾아냅니다. 만약 테스트가 구현 이후에 작성되었다면, 그 테스트는 시스템이 원래 어떻게 동작해야 하는지가 아니라 현재 구현이 우연히 어떻게 동작하는지를 검증하게 될 가능성이 높습니다. 그 결과, 잘못된 동작을 검증하는 테스트 스위트와 함께 거대한 코드베이스를 갖게 될 수 있습니다. 포괄적인 테스트 우선 테스트 스위트는 자율적으로 생성된 결과물이 실제로 올바른지 보장하고, 코드베이스가 커지는 과정에서도 기존 기능을 보호할 수 있는 가장 강력한 레버리지 중 하나입니다.

 

“Red/Green TDD”는 좋은 모델이라면 모두 이해하는 일종의 약속된 표현입니다. 이 표현에는 하나의 규율이 담겨 있습니다. 먼저 테스트를 작성한다. 구현 전에 테스트가 실패하는 것을 확인한다. 테스트를 속이는 방식이 아니라 올바른 구현을 통해 테스트를 통과시킨다. 에이전트에게 작업을 맡길 때 “Red/Green TDD를 사용하라”고 지시하는 것은, 작업 시작 단계에서 줄 수 있는 가장 영향력 있는 지시 중 하나입니다.

아직 해결되지 않은 문제는 생성이 아니라 검증이다

이제 더 이상 생성이 병목이 아닙니다. 병목은 검증입니다.

 

에이전트는 인상적인 결과물을 만들어낼 수 있습니다. 하지만 그 결과물이 정말 올바른지 확신할 수 있는가는 전혀 다른 문제입니다. 그리고 생각보다 이를 어렵게 만드는 요인들이 많습니다.

 

변경 이전에 테스트가 통과했다고 해서, 그 테스트가 변경으로 인해 발생한 회귀 버그를 잡아낼 수 있다는 뜻은 아닙니다. 에이전트는 기술적으로는 유효하지만 실제로 중요한 시나리오를 놓치는 테스트를 작성할 수 있습니다. UI 검증 역시 여전히 취약합니다. 시각적인 변화나 동작상의 회귀는 자동화 도구만으로 완벽하게 잡아내기 어렵기 때문에 쉽게 빠져나갈 수 있습니다. 컨텍스트 윈도우의 한계도 문제입니다. 대규모 코드베이스에서 작업하는 에이전트는 현재 보고 있는 범위 밖에 존재하는 중요한 제약 조건이나 패턴을 놓칠 수 있습니다. 불안정한 실행 환경 역시 마찬가지입니다. 한 명의 개발자가 작업할 때는 귀찮은 엣지 케이스 정도로 넘어갈 수 있습니다. 하지만 40개의 에이전트가 동시에 같은 불안정한 테스트를 실행하는 상황에서는 이야기가 달라집니다. 이제 그것은 시스템 전체를 멈춰 세우는 장애물이 됩니다. 공장이 멈춰서는 것입니다.

 

이 모델을 대규모로 운영하기 위해서는 더 나은 자동 회귀 검출, 단순히 변경된 코드 라인만 비교하는 수준을 넘어선 결과물 단위의 검증, 빠르고 안정적인 환경 구성, 그리고 병렬 작업 환경에서도 견딜 수 있는 가드레일이 필요합니다. 이들은 현재 업계가 적극적으로 투자하고 있는 영역입니다. 하지만 아직 해결된 문제는 아닙니다.

 

검증 기술이 생성 기술을 따라잡기 전까지, 인간의 리뷰는 선택 가능한 부가 작업이 아닙니다. 그것은 안전장치입니다. 에이전트가 만들어낸 결과물이 인상적이라고 해서 무조건 신뢰하는 것이 올바른 반응은 아닙니다. 중요한 것은 결과물이 그럴듯해 보인다는 이유로 믿는 것이 아니라, 충분한 아키텍처 이해와 테스트에 대한 규율을 바탕으로 그것을 엄격하게 검증할 수 있는 능력입니다.

높은 레버리지를 만드는 엔지니어링의 새로운 모습

이 시대에 가장 큰 영향력을 발휘하는 엔지니어는 더 이상 타이핑 속도나 문법 암기 능력으로 구분되지 않을 것입니다. 그들을 구분 짓는 것은 전혀 다른 역량들입니다.

 

시스템 사고. 복잡한 아키텍처 전체를 머릿속에 유지하면서 각 구성 요소가 어떻게 상호작용하는지 이해하고, 한 곳의 변경이 다른 곳의 동작에 어떤 영향을 미칠지 예측하는 능력입니다. 이 능력은 타이핑 속도보다 훨씬 기르기 어렵습니다. 하지만 여러 에이전트의 결과물을 통합해야 하는 환경에서는 훨씬 더 큰 가치를 가집니다.

 

문제 분해. 크고 모호한 목표를 에이전트가 안정적으로 수행할 수 있는 작은 작업 단위로 나누는 능력입니다. 작업이 너무 크면 쉽게 방향을 잃습니다. 작업 범위가 불명확하면 잘못 해석됩니다. 문제를 적절하게 분해하고, 그 분해가 올바른지 검증하는 능력은 하나의 전문 기술에 가깝습니다.

 

아키텍처 판단력. 시스템이 왜 현재와 같은 형태로 설계되었는지, 어떤 특성을 최적화하고 있는지, 그리고 어떤 트레이드오프가 있었는지를 이해하는 능력입니다. 에이전트는 구현할 수 있습니다. 하지만 지금 구현하고 있는 것이 정말 올바른 설계인지는 판단할 수 없습니다.

 

명확한 명세 작성 능력. 모호함이 없고, 중요한 엣지 케이스를 빠짐없이 포함하며, 평가하기 쉬운 형태로 요구사항을 작성하는 능력입니다. 애매한 명세는 애매한 결과를 만들어냅니다. 정확한 명세는 정확한 구현으로 증폭됩니다.

 

결과물 평가 능력. 겉보기에는 맞아 보이지만 실제로는 잘못된 결과를 알아차리는 감각입니다. 명시된 문제는 해결했지만 새로운 문제를 만들어낸 구현을 발견하는 능력입니다. 또는 솔루션 자체는 괜찮지만 전체 시스템의 아키텍처와 어울리지 않는 경우를 구분하는 능력입니다. 이러한 판단은 자동화할 수 없습니다.

 

오케스트레이션 역량. 여러 개의 병렬 작업 흐름을 관리하고, 에이전트의 결과물에 효과적으로 피드백을 제공하고, 단순히 방향 수정이 필요한 상황인지 아니면 작업 자체를 다시 정의해야 하는 상황인지를 판단하는 능력입니다. 또한 수많은 자율 에이전트가 만들어내는 결과물 사이에서 일관성을 유지하는 능력이기도 합니다.

 

이 역량들은 사실 새로운 것이 아닙니다. 좋은 엔지니어라면 원래부터 갖추고 있어야 하는 능력들이었습니다. 달라진 것은 중요도의 순서입니다. 소프트웨어 개발의 기계적인 부분은 점점 더 기계가 담당하게 되고 있습니다. 반면 이해하고, 판단하고, 설계하는 인지적 작업의 가치는 점점 더 커지고 있습니다.

더 큰 그림은 무엇일까?

새로운 웹사이트 생성 수는 전년 대비 40% 증가했습니다. 새로운 iOS 앱은 거의 50% 증가했습니다. 미국에서는 GitHub 코드 푸시 수가 35% 늘어났습니다. 이러한 지표들은 2024년 말 이전까지 수년 동안 거의 변화가 없었습니다. 그런데 이제 그래프는 마치 하키 스틱처럼 치솟고 있습니다. 한 줄의 코드도 작성해본 적 없는 사람들이 소프트웨어를 만들고 배포하고 있습니다.

 

물론 양이 늘어난다고 해서 반드시 품질이 좋아지는 것은 아닙니다. 이 점은 분명히 짚고 넘어가야 합니다. 하지만 한 가지 사실은 변하지 않습니다. 소프트웨어를 만드는 진입장벽이 극적으로 낮아졌습니다. 그리고 이것은 소프트웨어 엔지니어링의 지형 자체를 바꾸는 변화입니다.

 

소프트웨어를 만드는 진입장벽이 실제로 낮아진 것은 사실입니다. 이것은 과장이 아닙니다. 하지만 그렇다고 전문 엔지니어의 역량 가치가 낮아졌다는 의미는 아닙니다. 오히려 중요한 역량이 더 높은 추상화 계층으로 이동했다는 뜻입니다. 그리고 이는 과거의 모든 기술 전환에서도 반복되었던 현상입니다.

 

어셈블리에서 C로 넘어가는 과정에서 성공한 개발자는 가장 기발한 어셈블리 코드를 작성하던 사람들이 아니었습니다. 컴퓨터가 무엇을 해야 하는지 이해하고, 그것을 더 높은 수준의 언어로 명확하게 표현할 수 있었던 사람들이었습니다. 관리형 언어와 프레임워크가 등장한 이후에 성공한 개발자들도 마찬가지였습니다. 가비지 컬렉션을 가장 강하게 거부한 사람들이 아니라, 새롭게 확보된 인지적 여유를 더 어려운 문제를 해결하는 데 사용한 사람들이었습니다.

 

에이전트 시대에 성공할 개발자 역시 같은 부류의 사람들일 것입니다. 이 변화를 거대한 흐름 속 또 하나의 단계로 이해하고, 그에 맞춰 투자하는 사람들입니다. 도구를 거부하는 사람들이 아닙니다. 도구를 무비판적으로 맹신하는 사람들도 아닙니다. 도구를 최대한 효과적으로 활용할 수 있도록 판단력, 명확성, 시스템 사고를 키우는 사람들입니다.

 

그것은 더 나은 명세를 작성하는 것을 의미합니다. 테스트 인프라에 투자하는 것을 의미합니다. 피상적인 이해가 아니라 깊이 있는 아키텍처 이해를 갖추는 것을 의미합니다. 결과물을 엄격하게 평가할 수 있는 안목을 기르는 것을 의미합니다. 그리고 문제를 자연스럽게 분해할 수 있을 때까지 반복적으로 연습하는 것을 의미합니다.

 

프로그래밍이 주로 키보드를 두드리는 행위였던 시대는 끝났습니다. 프로그래밍이 생각하고 판단하는 활동이 되는 흐름은 수십 년 동안 계속 가속되어 왔습니다. 그리고 지금 그 변화는 한 단계 더 빨라졌습니다.

 

팩토리 모델은 소프트웨어에 대한 통제력을 잃어간다는 비유가 아닙니다. 그것은 레버리지를 만드는 방법에 대한 비유입니다. 그리고 그 사실을 이해하는 엔지니어들이 앞으로 10년 동안 가장 흥미로운 것들을 만들어낼 것입니다.