팩토리 모델: 코딩 에이전트가 바꿔놓은 소프트웨어 엔지니어링

최근 에이전트 엔지니어링에서 뭔가 근본적인 변화가 일어났다. 추상화의 수준 자체가 달라진 듯한 느낌이다. 도구가 조금씩 나아지고 워크플로가 점진적으로 진화하는, 그런 익숙한 변화가 아니다. 차원이 다른 변화다. 수십 년간 소프트웨어를 만들어온 개발자들이 하나같이 같은 말을 한다. 이 직업의 무게중심이 이동했다고.

지금 가장 유용한 자세는 두 가지 생각을 동시에 긴장감 있게 붙들고 있는 것이다. 코딩은 극적으로 변했다. 하지만 소프트웨어 엔지니어링의 본질은 변하지 않았다. 흥미로운 이야기는 바로 이 둘 사이의 간극에 있다. 이 간극을 제대로 이해하느냐가, 이 시대에 성장하는 엔지니어와 뒤처지는 엔지니어를 가른다.

Cursor의 Michael Truell이 이에 대해 정리한 글을 읽고, 거기에 살을 붙여보고 싶었다.

추상화의 궤적

소프트웨어 엔지니어링의 역사는 곧 추상화 수준을 끌어올려온 역사다. 비트에서 명령어로, 명령어에서 함수로, 함수에서 객체로, 객체에서 서비스로, 서비스에서 분산 시스템으로. 스택이 한 단계 올라갈 때마다 개별 개발자의 생산성은 높아졌고, 소프트웨어를 만들 수 있는 사람의 범위도 넓어졌다.

어셈블리는 C에 자리를 내줬다. C는 매니지드 언어와 가비지 컬렉션에 자리를 내줬다. 매니지드 언어는 프레임워크, 패키지 생태계, 클라우드 인프라에 자리를 내줬다. 당시에는 매번 파괴적인 전환처럼 느껴졌지만, 돌이켜보면 길고 일관된 궤적 위의 다음 한 걸음이었을 뿐이다.

지금 우리가 겪고 있는 것도 바로 그 궤적 위의 또 다른 한 걸음이다. 코드를 직접 작성하는 단계에서, 코드를 작성하는 시스템을 오케스트레이션하는 단계로 넘어가고 있다.

이 관점은 Grady Booch가 소프트웨어의 제3시대라고 명명한 것과 맞닿아 있다. 추상화의 상승이 정의하는 새로운 황금기이며, 개발자의 역할이 명령어를 작성하는 것에서 의도를 정의하는 것으로 전환되는 시대다.

이 프레임이 중요한 이유는, 무엇을 붙잡고 무엇을 놓아야 하는지를 알려주기 때문이다.

AI 코딩 도구의 세 세대

세대별 발전 과정을 정확하게 구분할 필요가 있다. 세대를 뭉뚱그려 보면, 실제로 얼마나 많이 변했는지를 과소평가하게 되기 때문이다.

1세대는 고급 자동완성이었다. 다음 줄을 예측하고, 보일러플레이트를 채워 넣고, 반복 패턴의 타이핑을 줄여주는 도구들이다. 유용했고, 실제로 시간을 절약해줬다. 하지만 워크플로 자체는 달라지지 않았다. 개발자가 운전대를 잡고, 도구는 보조했다. 피드백 루프는 여전히 "코드 작성 → 실행 → 디버그 → 반복"이었다. AI는 그 루프 안의 마찰을 줄여줬을 뿐이다.

2세대는 동기식 에이전트를 도입했다. 자연어로 작업을 설명하면 모델이 코드를 생성했다. 개발자는 결과를 검토하고, 수정하고, 원하는 결과를 향해 반복했다. 추상화 수준이 한 단계 더 올라간 셈이다. 타이핑은 줄고, 의도를 설명하는 비중이 커졌다. 하지만 모든 단계에 여전히 개발자가 붙어 있어야 했다. 에이전트는 협업자였지, 자율적인 작업자는 아니었다. 컨텍스트를 유지하고, 다음 방향을 지시하고, 실시간으로 실수를 잡아내는 것은 여전히 사람 몫이었다.

3세대는 자율 에이전트를 가져왔다. 이 에이전트들은 명세를 받으면 30분, 1시간, 몇 시간, 점점 더 며칠 단위로 스스로 작업을 수행한다. 환경을 설정하고, 의존성을 설치하고, 테스트를 작성하고, 실패를 맞닥뜨리고, 온라인에서 해결책을 찾고, 실패를 수정하고, 구현을 작성하고, 다시 테스트하고, 서비스를 구성하고, 검토할 수 있는 산출물을 만들어낸다. 작업을 맡기고 다른 일을 하다가 돌아오면 로그, 미리보기, 풀 리퀘스트가 기다리고 있다. 더 이상 한 줄 한 줄 상호작용하는 방식이 아니다. 결과를 정의하고, 산출물을 검토하는 방식이다. 에이전트 스웜(swarm)과 자기 개선 에이전트가 등장하는 것도 바로 이 맥락이다.

이 변화가 일하는 리듬을 얼마나 바꿔놓는지는 직접 경험하기 전까지 전달하기 어렵다. 석 달 전만 해도 주말 프로젝트였던 작업이 이제는 시작시켜 놓고 30분 뒤에 확인하면 끝나 있다.

팩토리 멘탈 모델

이 새로운 패러다임을 이해하는 데 가장 유용한 멘탈 모델은 이것이다. 당신은 더 이상 코드를 작성하는 사람이 아니다. 소프트웨어를 만들어내는 공장을 건설하는 사람이다.

이 공장은 에이전트 집단으로 구성된다. 각 에이전트에는 작업, 도구 세트(리포지토리, 테스트 러너, 배포 스크립트, 문서), 컨텍스트(명세, 아키텍처 결정, 기존 제약 조건), 피드백 루프가 갖춰져 있다. 하나의 에이전트를 붙잡고 하나의 작업을 시키는 대신, 여러 에이전트를 병렬로 가동한다. 하나는 백엔드 리팩터링을 맡고, 다른 하나는 기능을 구현하고, 또 다른 하나는 통합 테스트를 작성하고, 또 다른 하나는 문서를 업데이트한다. 개발자는 산출물을 검토하고, 피드백을 주고, 명세를 다듬고, 다시 배포한다.

이 비유는 겉보기보다 훨씬 깊다. 공장에는 품질 관리가 있다. 공장에는 공정 문서가 있다. 공장에는 정확히 지정되지 않으면 결과물이 잘못 나오는 투입물이 있다. 공장은 환경이 불안정하면 멈춘다. 이 모든 속성이 에이전트 기반 소프트웨어 개발에 그대로 대응된다. 이 비유를 진지하게 받아들이면, 정말로 중요한 투자가 무엇인지가 보이기 시작한다.

이 모델을 적극적으로 도입한 팀 내부에서는, 이미 머지되는 풀 리퀘스트의 상당 부분이 클라우드 환경에서 자율적으로 실행된 에이전트로부터 나온다. 이론적 가능성이 아니라, 점점 더 많은 엔지니어링 조직의 프로덕션 현실이다.

Cursor 측에서 밝힌 관점, 즉 "개발자의 역할은 제품이 아니라 소프트웨어를 만드는 시스템, 즉 공장을 만드는 것이 되고 있다"와 "코드를 리뷰하는 것보다 아이디어를 리뷰하는 것이 훨씬 재미있다"(영상)는 이러한 논점과 정확히 공명한다.

온보딩과의 유사성

에이전트의 실제 작업 방식에서 눈에 띄는 패턴 중 하나는, 그 작업 루프가 신규 엔지니어의 온보딩 과정과 놀라울 만큼 닮아 있다는 점이다.

명세를 건네면 하위 작업으로 나눈다. 코드베이스를 탐색하며 전체 구조를 파악한다. 막히면 커밋 히스토리를 뒤진다. git blame으로 해당 서브시스템을 마지막에 누가 수정했는지 확인한다. 도메인 지식이 필요하면 Slack 같은 커뮤니케이션 채널을 통해 적절한 담당자에게 에스컬레이션한 뒤 작업을 이어간다. 인수 기준을 충족할 때까지 반복한다.

이 루프가 익숙하게 느껴지는 이유는 사람이 일하는 방식과 같기 때문이다. 여기서 중요한 함의가 도출된다. Slack과 이메일은 사람과 사람 사이의 인터페이스일 뿐 아니라, 사람과 에이전트 사이의 인터페이스가 되고 있다. Git 히스토리는 에이전트가 아키텍처 결정을 이해하기 위해 탐색하는 지식 그래프로 진화하고 있다. 문서는 자율 실행을 위한 학습 자료가 되고 있다.

지금 코드베이스에 어떤 투자를 해야 할지 고민된다면, 이렇게 자문해보라. 문서와 커밋 히스토리만 보고 신규 엔지니어가 "코드가 왜 이렇게 구조화되어 있는지" 이해할 수 있는가? 답이 '아니오'라면, 에이전트도 마찬가지로 어려움을 겪을 것이고, 얻을 수 있는 레버리지도 제한될 것이다.

명세가 곧 레버리지다

엔지니어로서 자신의 가치를 어떻게 바라볼 것인지를 근본적으로 재구성하는 통찰이 여기 있다.

에이전트 20개, 30개, 50개를 병렬로 오케스트레이션할 수 있다면, 평범한 결과물과 탁월한 결과물의 차이는 거의 전적으로 명세의 품질에 달려 있다. 이 규모에서 모호한 사고는 단순히 속도를 늦추는 게 아니다. 증폭된다. 불분명한 요구사항이 수십 개의 병렬 자율 실행에 전파되고, 각각이 조금씩 다른 방향으로 조금씩 어긋난다. 초기에 내린 잘못된 아키텍처 결정은 하나의 구현에만 영향을 미치는 게 아니다. 전체 에이전트 집단에 걸쳐 전파된다.

아키텍처, 통합 경계, 엣지 케이스, 실패 모드, 절대 깨져서는 안 되는 불변 조건을 깊이 이해하지 않고서는, 이 환경에서 살아남는 명세를 작성할 수 없다. 명세는 더 이상 프롬프트가 아니다. 명세는 제품 사고를 명시적으로 풀어낸 것이다.

역량 있는 소프트웨어 엔지니어가 이 도구들로부터 더 적은 게 아니라 더 큰 레버리지를 얻는 이유가 바로 여기에 있다. 코드를 타이핑하는 기계적 작업은 자동화되고 있다. 시스템을 이해하는 인지적 작업은 증폭되고 있다. 진정한 아키텍처 이해와 시스템적 사고를 기르는 데 투자한 시간 한 시간이, 이제는 본인의 산출물뿐 아니라 자율 작업자 집단 전체에 걸쳐 복리로 돌아온다.

변하지 않은 것들

여기서 정확하게 짚고 넘어갈 필요가 있다. AI 코딩에 대한 과대 포장이 전통적인 소프트웨어 엔지니어링 역량이 쓸모없어졌다는 인상을 줄 수 있기 때문이다.

전혀 그렇지 않다. 에이전트 기반 개발이 여전히 엔지니어에게 요구하는 것을 보자.

명확한 요구사항. 평가 가능한 방식으로 성공이 무엇인지 정의하지 못하면, 아무리 자율 실행을 시켜도 원하는 결과를 만들어내지 못한다. 에이전트는 주어지지 않은 요구사항을 스스로 명확히 할 수 없다. 빈자리는 가정으로 채워지고, 그 가정은 누적된다.

탄탄한 추상화. 모듈 경계가 명확하고, 인터페이스가 일관되며, 관심사 분리가 잘 된 시스템을 받은 에이전트는 모든 것이 모든 것에 의존하는 엉킨 코드베이스를 받은 에이전트보다 훨씬 좋은 결과를 낸다. 에이전트가 구현을 맡는다고 해서 깔끔한 아키텍처의 가치가 줄어드는 게 아니다. 오히려 더 커진다. 에이전트는 자신이 작업하는 시스템의 속성을 증폭시키기 때문이다.

신뢰할 수 있는 테스트. 이 주제는 별도로 다룰 필요가 있다.

신중한 트레이드오프. 에이전트는 명시된 목표에 맞춰 최적화한다. 상충하는 관심사를 자연스럽게 균형 잡거나, 2차 효과를 예측하거나, 기술적으로는 맞지만 제품 관점에서는 잘못된 솔루션임을 경고하지 못한다. 그 판단은 여전히 엔지니어의 몫이다.

사람의 감독. 에이전트는 인상적인 결과물을 낸다. 동시에 자신감 넘치는 실수도 저지른다. 산출물의 품질이 대충 훑어서는 걸러지지 않을 만큼 높기 때문에, 리뷰 역량의 기준은 낮아지는 게 아니라 오히려 높아진다.

테스트가 그 어느 때보다 중요한 이유

좋은 테스트와 테스트 주도 개발(TDD)은 원래부터 좋은 관행이었다. 에이전트 워크플로에서는 거의 필수에 가깝다.

핵심을 명확히 짚어보자. Red/Green TDD란 구현 전에 테스트를 먼저 작성하는 것이다. 테스트가 실패하는 것을 확인하고(Red 단계), 구현을 반복하여 테스트를 통과시킨다(Green 단계). 이 순서는 형식적인 절차가 아니다. 구현이 실제로 의도대로 동작하는지에 대한 확신을 주는 메커니즘이다.

개발자 한 명이 코드를 작성하는 환경에서 테스트 우선 개발을 건너뛰면, 구현의 정확성과 무관하게 통과하는 테스트를 작성하거나, 나중에 리그레션으로 드러나는 엣지 케이스를 놓치는 정도의 비용이 발생한다. 실질적인 비용이지만, 관리 가능한 수준이다.

에이전트 집단이 수십 개의 병렬 작업에 걸쳐 코드를 생성하는 환경에서는 이 비용이 급격히 복합된다. 테스트 통과에 최적화하는 에이전트는 통과할 방법을 찾아낸다. 구현 이후에 작성된 테스트는 "코드가 해야 하는 것"이 아니라 "코드가 실제로 하고 있는 것"을 검증할 가능성이 높다. 그 결과, 잘못된 것을 확인해주는 테스트 스위트를 가진 대규모 코드 영역이 만들어진다. 테스트 우선으로 작성된 포괄적 테스트 스위트야말로 자율 산출물의 실제 정확성을 보장하고, 코드베이스가 커지면서 기존 기능을 보호하는 데 가장 효과적인 레버다.

"Red/Green TDD"는 우수한 모델이라면 모두 이해하는 약속어다. 테스트를 먼저 쓰고, 구현 전에 실패를 확인하고, 테스트를 속이는 게 아니라 올바른 구현을 통해 통과시키는 규율을 담고 있다. 작업 시작 시 에이전트에게 Red/Green TDD를 지시하는 것은, 줄 수 있는 가장 레버리지 높은 지침 중 하나다.

아직 풀리지 않은 문제는 생성이 아니라 검증이다

이제 병목은 생성이 아니다. 검증이다.

에이전트는 인상적인 산출물을 만들어낸다. 문제는 그 산출물이 정확한지 확신을 갖는 것이다. 이것이 겉보기보다 훨씬 어려운 데는 여러 이유가 있다.

변경 전에 통과하던 테스트가 변경으로 인한 리그레션을 잡아준다는 보장은 없다. 에이전트가 작성한 테스트가 기술적으로는 유효하지만 중요한 케이스를 놓칠 수 있다. UI 검증은 여전히 취약하다. 시각적·동작적 리그레션이 빠져나가는 이유는 자동화 도구가 아직 충분히 신뢰할 수 있는 수준이 아니기 때문이다. 컨텍스트 윈도우 제약으로 인해 대규모 코드베이스를 다루는 에이전트가 현재 추론 범위 밖에 있는 중요한 제약 조건이나 패턴을 놓칠 수 있다. 개발자 한 명이 "짜증나는 엣지 케이스"로 우회하던 불안정한 환경은, 40개 에이전트가 동시에 같은 불안정 테스트에 부딪히는 순간 시스템 전체의 블로커가 된다. 공장이 멈추는 것이다.

이 모델을 대규모로 지원하기 위해 필요한 인프라에는, 더 나은 자동 리그레션 탐지, 변경된 줄 단위 diff를 넘어서는 산출물 수준 검증, 안정적이고 빠른 환경 프로비저닝, 병렬 워크로드에서도 견디는 가드레일이 포함된다. 모두 활발히 투자가 이뤄지는 영역이지만, 아직 해결되지 않았다.

검증이 생성을 따라잡기 전까지, 사람의 리뷰는 선택적 부담이 아니다. 안전 장치다. 인상적인 에이전트 산출물에 대한 올바른 대응은, 그럴듯해 보인다고 신뢰하는 것이 아니다. 아키텍처에 대한 이해와 테스트 규율을 갖추고 엄격하게 평가하는 것이다.

높은 레버리지 엔지니어링의 새로운 형태

이 시대에 가장 큰 임팩트를 만들어낼 엔지니어는 타이핑 속도나 문법 암기력으로 구별되지 않을 것이다. 완전히 다른 역량 집합으로 구별될 것이다.

시스템적 사고. 복잡한 아키텍처를 머릿속에 담고, 컴포넌트 간 상호작용을 이해하며, 한 곳의 변경이 다른 곳의 동작에 어떤 영향을 미치는지 예측하는 능력. 이것은 타이핑 속도보다 기르기 어렵고, 산출물을 통합해야 하는 에이전트 집단을 관리할 때 훨씬 더 가치 있다.

문제 분해. 크고 모호한 목표를 에이전트가 안정적으로 실행할 수 있는, 범위가 잘 정의된 하위 작업으로 나누는 법을 아는 것. 너무 큰 작업은 방향을 잃기 쉽고, 범위가 불명확한 작업은 잘못 해석된다. 문제를 잘 분해하고, 그 분해가 맞았는지 검증하는 기술은 그 자체로 고도의 역량이다.

아키텍처 판단력. 시스템이 왜 이렇게 설계되었는지, 어떤 속성을 최적화하고 있는지, 어떤 트레이드오프가 이뤄졌는지를 이해하는 것. 에이전트는 구현할 수 있다. 하지만 자신이 구현하는 것이 올바른 설계인지는 판단하지 못한다.

명세의 명확성. 모호함이 없고, 중요한 엣지 케이스가 빠짐없이 포함되며, 평가가 용이한 구조로 요구사항을 작성하는 능력. 모호한 명세는 모호한 결과를 낳는다. 정밀한 명세는 정밀한 구현으로 증폭된다.

산출물 평가력. 겉보기에는 맞지만 실제로는 틀린 것을 감지하는 눈. 명시된 문제는 해결했지만 새로운 문제를 만드는 구현을 알아채는 눈. 솔루션의 아키텍처가 나머지 시스템의 아키텍처와 맞지 않음을 파악하는 눈. 이 판단력은 자동화할 수 없다.

오케스트레이션 능력. 여러 병렬 작업 흐름을 관리하고, 에이전트 산출물에 효과적으로 피드백하고, 에이전트를 방향 수정할지 작업을 재할당할지 판단하고, 자율 작업자 집단 전체에 걸쳐 일관성을 유지하는 실무적 역량.

엄밀히 말해 완전히 새로운 역량은 아니다. 좋은 엔지니어에게는 항상 필요했던 것들이다. 달라진 것은 상대적 중요도다. 소프트웨어 개발의 기계적 부분은 점점 더 기계가 처리하고 있다. 인지적 부분은 증폭되고 있다.

더 큰 그림은 무엇인가?

신규 웹사이트 생성은 전년 대비 40% 증가했다. 신규 iOS 앱은 거의 50% 증가했다. 미국 내 GitHub 코드 푸시는 35% 급증했다. 이 지표들은 2024년 말 이전까지 수년간 정체 상태였다. 그래프가 하키 스틱 모양이다. 코드를 한 줄도 써본 적 없는 사람들이 소프트웨어를 만들고 출시하고 있다.

물론 양이 늘었다고 질이 함께 좋아지는 것은 아니라는 점은 분명히 짚어야 한다. 하지만 소프트웨어를 만드는 진입 장벽이 극적으로 낮아졌다는 사실 자체가 소프트웨어 엔지니어링 지형의 근본적 변화다.

소프트웨어 창작의 진입 장벽은 실제로 낮아졌다. 과장이 아니다. 이것이 전문 엔지니어에게 의미하는 바는, 역량의 가치가 줄어든다는 게 아니라, 중요한 역량이 스택 위로 이동했다는 것이다. 이전의 모든 전환에서 그랬듯이.

어셈블리에서 C로 넘어간 뒤 살아남은 개발자는 가장 교묘한 어셈블리를 짤 수 있었던 사람이 아니었다. 기계가 무엇을 해야 하는지 이해하고, 그 의도를 상위 언어로 명확하게 표현할 수 있었던 사람이었다. 매니지드 언어와 프레임워크로 넘어간 뒤 살아남은 개발자는 가비지 컬렉션에 가장 저항했던 사람이 아니었다. 확보된 인지적 여유를 더 어려운 문제를 푸는 기회로 삼은 사람이었다.

에이전트 시대에 살아남을 개발자는, 이것이 같은 궤적 위의 또 다른 한 걸음임을 이해하고 그에 맞게 투자하는 사람이다. 도구를 거부하는 것도, 도구에 무비판적으로 맡기는 것도 아니다. 도구의 효과를 극대화하는 판단력, 명확성, 시스템적 사고를 키우는 것이다.

그것은 더 좋은 명세를 쓰는 것이다. 테스트 인프라에 투자하는 것이다. 피상적 친숙함이 아니라 진정한 아키텍처 이해를 쌓는 것이다. 산출물을 엄격하게 평가하는 안목을 기르는 것이다. 문제 분해를 몸에 밸 때까지 연습하는 것이다.

프로그래밍이 주로 키보드 입력 활동이던 시대는 끝났다. 프로그래밍이 주로 사고와 판단의 활동이 되는 흐름은 수십 년간 가속되어 왔고, 이제 한 단계 더 높은 기어로 전환되었다.

팩토리 모델은 소프트웨어에 대한 통제를 잃는다는 비유가 아니다. 레버리지를 만든다는 비유다. 이것을 이해하는 엔지니어가 다음 10년간 가장 흥미로운 것들을 만들어낼 것이다.