나만의 소프트웨어 팩토리를 구축하라
📺 원본 영상: Building your own software factory — Eric Zakariasson, Cursor 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-04-29 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Cursor의 엔지니어 Eric Zakariasson은 AI Engineer 컨퍼런스에서 자신이 Cursor를 직접 사용(dogfooding)하며 경험한 소프트웨어 팩토리 구축의 실전 노하우를 공유했다. 그가 말하는 “소프트웨어 팩토리”란 AI 에이전트들이 코드 작성, 테스트, 배포까지 자율적으로 수행하는 시스템으로, 인간은 방향성과 의도만 제시하는 역할을 맡는다. 강연은 자율성의 수준을 정의하는 것부터 팩토리 구축·운영·확장에 이르는 단계적 프레임워크를 다루며, Cursor 내부에서 실제로 운용 중인 자동화 사례들을 함께 소개한다.
자율성의 6단계: 지금 우리는 어디에 있는가
강연자는 Dan Shapiro가 발표한 소프트웨어 자동화의 6단계 자율성 모델을 인용하며 이야기를 시작했다. 이전에 Andrej Karpathy 역시 Cursor를 예시로 들어 탭 완성(tab completion)에서 에이전트로 나아가는 흐름을 설명한 바 있는데, 강연자는 이 모델이 그 변화를 가장 잘 포착한다고 평가했다.
레벨 1은 소위 “스파이시 자동완성(spicy autocomplete)“으로 불리는 단계로, 강연자에 따르면 Cursor가 처음 등장한 2022~2023년이 바로 이 수준이었다. 이후 점진적으로 발전하여 현재 대부분의 AI 도구 사용자들은 레벨 2에서 레벨 3 사이에 위치한다고 분석했다. 이 단계에서는 에이전트와 쌍방향으로 대화하며 코드 생성을 요청하고 인간이 결과물을 검토하는, 이른바 페어 프로그래밍(pair programming) 방식으로 협업이 이루어진다. 레벨 3에서 인간은 AI가 생성한 코드의 대부분을 확인하면서 실행 흐름(traces)을 따라가는 “루프 안의 리뷰어” 역할을 한다.
강연자 자신은 현재 레벨 4에 해당한다고 밝혔다. 이 단계에서는 대부분의 작업을 에이전트에게 위임하되, 코드를 직접 보기보다 산출물(output)을 먼저 검토한다. “그래도 여전히 코드를 보긴 한다”고 솔직하게 인정하면서도, 점점 실행 결과 위주로 판단하게 된다고 설명했다. 이 단계를 지나면 레벨 5, 이른바 “다크 팩토리(dark factory)“가 기다리고 있다. 에이전트가 코드 작성, 테스트, 빌드까지 모두 처리하는 블랙박스 구조로, 인간 관리자는 의도와 목표만 제시하면 된다. Cursor 내의 일부 시스템이 이 수준에 도달했지만, 완전한 소프트웨어 팩토리를 구현하려면 실제 하드웨어 공장처럼 조립 라인, 관리 체계, 관찰 가능성(observability) 등 아직 갖춰야 할 것이 많다고 강연자는 강조했다.
왜 소프트웨어 팩토리인가
강연자는 소프트웨어 팩토리를 구축해야 하는 이유로 세 가지를 제시했다. 첫 번째는 **처리량(throughput)**이다. 에이전트는 24시간 7일 쉬지 않고 동작하며, 수면이나 식사가 필요한 인간과 달리 병렬로 무한히 확장할 수 있다. 두 번째는 일관성이다. 잘 구축된 팩토리는 조립 라인처럼 예측 가능한 산출물을 반복 생성한다. 단, 가이드레일이 갖춰지지 않은 초기에는 에이전트 출력이 오히려 확률적으로 분산되는 느낌을 받을 수 있는데, 이는 팩토리의 안전장치를 강화해야 한다는 신호라고 강연자는 설명했다. 세 번째는 창의성의 레버리지다. 팩토리가 반복적인 구현 작업을 대신 처리함으로써 인간은 아이디어와 취향을 더 효과적으로 발현할 수 있게 된다. 구현을 기다리는 시간이 아니라 무엇을 만들 것인가를 사유하는 시간으로 전환하는 것이다.
팩토리를 구성하는 세 가지 요소
강연자는 소프트웨어 팩토리를 구성하는 핵심 요소를 프리미티브와 패턴(Primitives and Patterns), 가이드레일(Guardrails), **인에이블러(Enablers)**의 세 가지로 정리했다.
프리미티브와 패턴: 에이전트가 이해하기 쉬운 코드베이스
💡 [영상 참조] 강연자는 이 시점에서 Cursor 3 인터페이스와 음악 에이전트 프로젝트의 파일 구조를 화면에 보여줍니다. 상세 내용은 원본 영상을 확인하세요.
10:54 - Cursor 3의 새로운 에이전트 퍼스트 인터페이스 전체 화면. VS Code 기반이 아닌 완전 재설계된 UI.
프리미티브는 코드베이스의 구조 자체를 의미한다. 강연자는 코드가 모듈화되어 있고 관련 파일들이 함께 위치(co-located)할수록 에이전트의 탐색 효율이 높아진다고 설명했다. 특정 폴더 안에 관련 파일이 모여 있으면, 에이전트는 전체 코드베이스를 grep하며 헤맬 필요 없이 해당 폴더를 열자마자 필요한 컨텍스트를 확보할 수 있기 때문이다. 그는 “인간이 온보딩하기 쉬운 코드베이스라면 에이전트도 마찬가지”라고 비유했다.
패턴 측면에서는 사용자 인증, 테스트 작성, 스타트업 스크립트 등에 대해 정해진 방법론이 존재하는가가 중요하다. 기존 레퍼런스가 존재하면 에이전트는 이를 참고해 동일한 패턴을 재현할 수 있다. package.json에 시작 스크립트가 명시된 것이 좋은 예인데, 이 파일 구조는 모델의 학습 데이터에 충분히 포함되어 있어 에이전트는 자연스럽게 이를 먼저 탐색하는 방법을 알고 있다. 즉, 코드베이스를 “in-distribution”하게 유지하는 것 자체가 에이전트의 능력을 끌어올리는 전략이다.
가이드레일: 자유롭되, 과하지 않게
가이드레일은 에이전트가 해서는 안 되는 행동을 제한하는 장치다. 강연자는 특히 훅(hooks)의 중요성을 강조했다. 예를 들어 에이전트가 암호화 로직이나 인증 시스템처럼 민감한 코드 영역을 수정하려 할 때 이를 차단하는 훅을 설정할 수 있다. 실수 한 번이 회사 전체에 치명적인 영향을 미칠 수 있는 영역이기 때문이다.
규칙(rules)에 대해서는 중요한 관점 전환을 제시했다. Cursor Rules 출시 이후 많은 사용자들이 자신의 기술 스택에 맞는 모든 규칙을 미리 설치해두려 했지만, 강연자가 발견한 사실은 달랐다. 규칙은 **동적으로 출현(emerge dynamically)**해야 한다는 것이다. 에이전트가 의도치 않은 방향으로 동작하는 것을 발견했을 때 그 시점에 규칙을 만드는 것이 가장 효과적이다. 규칙은 결국 일종의 표준 운영 절차(Standard Operating Procedure, SOP)로, 에이전트에게 무엇을 해도 되고 하면 안 되는지를 점진적으로 알려주는 과정이다. 강연자는 Cursor 내부 사례로 데이터베이스 마이그레이션 시 외래 키(foreign key)를 사용하지 않는 규칙을 들었다. 성능상의 이유로 외래 키를 쓰지 않는 것이 팀의 관행인데, 모델은 “올바른” 방식이 외래 키라고 학습되어 있기 때문에 항상 추가하려 한다. Bug Bot이 이를 감지하고 플래그를 세우는 규칙이 바로 이렇게 탄생했다. 즉, 모델의 기본 행동과 팀의 의도 사이의 간극을 메우는 것이 규칙의 본질이다.
테스트는 에이전트가 자신의 작업을 스스로 검증할 수 있는 수단이다. 어떤 영역의 코드를 변경했을 때 테스트가 통과하면 에이전트는 “변경이 올바르게 이루어졌다”는 피드백을 받고 다음 단계로 나아갈 수 있다. 이 검증 루프가 없다면 에이전트는 작업을 완료했는지 여부를 판단할 방법이 없다.
인에이블러: 에이전트를 진정으로 자유롭게
인에이블러는 에이전트가 더 많은 것을 할 수 있도록 능력을 부여하는 장치다. 강연자가 특히 강조한 것은 스킬(Skills)과 MCP(Model Context Protocol)였다. 피처 플래그(feature flag) 추가 스킬을 에이전트에게 부여하면, 자율적으로 실행된 에이전트는 변경 사항에 플래그를 달아 PR을 병합한 뒤 인간에게 이렇게 보고할 수 있다: “이 플래그를 켜면 새 기능을 테스트할 수 있습니다. 마음에 들지 않으면 PR을 되돌리면 됩니다.” 결정권을 인간에게 남기면서도 구현은 에이전트가 완료하는 구조다.
환경(environment) 역시 중요하다. 에이전트가 개발 환경을 스스로 시작할 수 있다면 인간의 개입 없이 별도의 가상 머신(VM)에서 무한히 확장할 수 있다. 강연자가 제시한 체크리스트는 세 가지다: 에이전트가 프로젝트를 실행할 수 있는가(runnable), Linear·Notion·Datadog·Slack 등 외부 컨텍스트에 접근할 수 있는가(accessible), 그리고 자신의 작업을 검증할 수 있는가(verifiable). 이 중 “검증 가능성”에 사람들이 충분한 시간을 투자하지 않는다고 강연자는 지적했다.
실전 데모: 음악 에이전트 프로젝트
💡 [영상 참조] 강연자는 이 시점에서 Cursor 3 인터페이스와 Ableton과 유사한 형태의 음악 제작 웹 앱을 직접 보여줍니다. 상세 내용은 원본 영상을 확인하세요.
강연자는 팩토리 구축 원칙을 직접 실험하기 위해 온라인 음악 제작 도구를 만드는 사이드 프로젝트를 진행했다. 규칙은 단 하나였다: 본인이 직접 코드를 작성하지 않을 것. 이 제약 속에서 팩토리에 무엇이 필요한지 자연스럽게 드러났다.
가장 먼저 명확해진 것은 프로젝트를 시작하는 방법이었다. 에이전트가 서버를 켜고 끌 수 있어야 한다. 다음으로 검증 수단이 필요해졌는데, 에이전트는 Playwright를 활용해 브라우저를 실행하고 라우트를 탐색하며 플레이 버튼이 정상 작동하는지, 노트를 추가해도 다른 기능이 깨지지 않는지를 E2E 테스트로 스스로 확인하도록 구성했다. 강연자는 코드를 거의 보지 않은 채 에이전트가 생성하는 영상 기록과 테스트 결과만으로 프로젝트를 진행했다고 설명했다.
13:51 - 음악 에이전트 프로젝트에서 Playwright를 활용해 E2E 테스트를 실행 중인 화면. 에이전트가 브라우저를 직접 제어하며 기능 검증.
컴퓨터 사용(Computer Use)과 GUI 검증
💡 [영상 참조] 강연자는 이 시점에서 Cursor Cloud Agents가 직접 컴퓨터를 제어하며 키보드 네비게이션 기능을 테스트하는 영상 녹화를 보여줍니다. 상세 내용은 원본 영상을 확인하세요.
16:21 - Cursor Cloud Agent가 컴퓨터 사용(computer use)으로 Glass 인터페이스의 키보드 네비게이션을 테스트하는 영상 녹화 결과물.
강연에서 특히 주목할 만한 데모는 Cursor Cloud Agents의 컴퓨터 사용(computer use) 기능이었다. 강연자는 Cursor의 자체 제품인 Glass의 키보드 네비게이션 기능을 개선한 뒤, 에이전트에게 이 변경 사항을 직접 테스트하도록 지시했다. 에이전트는 가상 머신 내에서 브라우저를 띄우고 키보드를 이용해 인터페이스를 탐색하며, 그 과정을 Screen Studio처럼 편집된 녹화 영상으로 만들어 인간에게 제출했다.
이 방식의 의의는 크다. GUI 테스트는 전통적으로 자동화가 어려운 영역이었다. 버튼에 로딩 스피너가 제대로 표시되는지, 입력 필드가 올바르게 작동하는지 등의 시각적 검증은 인간의 눈이 필요했다. 하지만 에이전트가 컴퓨터를 직접 제어해 영상을 생성하면, 인간은 코드를 보는 대신 결과 영상만 확인하고 병합 여부를 결정할 수 있다. 강연자는 이를 “내게 AGI 순간(AGI moment)이었다”고 표현하며, 사내에 이 기능을 내부적으로 처음 출시했을 때의 놀라움을 전했다.
Q&A에서 GUI 테스트를 더 구체적으로 질문받았을 때, 강연자는 문서 변경 작업 사례를 소개했다. 특정 단어가 참조된 모든 페이지를 에이전트에게 열어 스크린샷을 찍어오도록 지시하면, 인간은 스크린샷 모음을 훑어보고 이상이 없으면 코드를 병합한다. 에이전트가 탐색과 시각적 수집을 담당하고, 최종 판단만 인간이 맡는 구조다.
46:36 - GUI 테스트 데모. 에이전트가 컴퓨터를 직접 제어하며 ‘View Code’ 버튼 기능을 검증하는 screen recording 화면.
팩토리 운영: 워커에서 매니저로
공장을 지었다면, 이제 운영해야 한다. 강연자는 이 단계에서 가장 중요한 것이 마인드셋의 전환이라고 강조했다. 코드를 보는 시간이 크게 줄어들고, 인간은 직접 일하는 워커(worker)에서 에이전트를 감독하는 매니저(manager)로 역할이 바뀐다. 이 전환의 핵심은 동기(synchronous) 작업에서 비동기(asynchronous) 작업으로의 이동이다. 대부분의 작업이 백그라운드에서 진행되므로 인간은 여러 에이전트의 상태를 비동기적으로 모니터링하게 된다.
강연자는 이를 인간 조직의 진화와 동일한 패턴으로 설명했다. 소규모 팀으로 시작해 인원이 늘수록 관리자가 필요해지고, 관리자 위에 또 관리자가 생기는 것처럼 에이전트 생태계도 동일한 방향으로 진화한다. 에이전트를 점점 많이 운용할수록 각각에서 무슨 일이 일어나는지 파악하기 어려워지기 때문에, 변경 사항을 상위로 집계하는 시스템이 필요해진다.
매니저로서 특히 신경 써야 할 부분은 작업의 범위와 병렬화다. 두 에이전트가 같은 파일을 동시에 수정하면 머지 충돌(merge conflict)이 발생한다. 따라서 어떤 작업을 동시에 실행할 수 있는지 판단하는 것은 여전히 인간의 몫이다. 이 판단을 잘 하기 위해서는 코드베이스에 대한 지식, 즉 데이터가 어떻게 흐르고 어떤 부분이 중요한지에 대한 “부족 지식(tribal knowledge)“을 인간이 유지해야 한다. 강연자는 “에이전트에게 너무 많은 것을 아웃소싱하지 말라”고 경고했다. 에이전트를 효과적으로 관리하려면 인간이 시스템을 이해하고 있어야 하기 때문이다.
긴 작업을 에이전트에게 맡길수록 사전에 더 많은 컨텍스트를 제공해야 한다. 강연자는 이를 “컨텍스트 프론트로딩(context front-loading)“이라 표현했다. 상세한 계획이나 스펙을 먼저 전달한 다음 에이전트를 보내는 방식이다. 이를 반복하다 보면 각 모델의 강점과 약점에 대한 감각이 생기고, 어떻게 프롬프트해야 원하는 결과를 얻는지 알게 된다. 그리고 모델이 좋아질수록 더 짧은 프롬프트로도 원하는 것을 얻을 수 있게 된다. 강연자는 “이를 위한 지름길은 없다. 그냥 엄청나게 많은 에이전트를 실행해보는 것 외에 방법이 없다”고 솔직하게 말했다.
팩토리 확장: 자동화 플라이휠 구축
팩토리를 5개 에이전트에서 수백 개로 확장하려면 자동화 플라이휠을 만들어야 한다. 강연자는 Cursor 내부에서 실제로 운용 중인 사례들을 소개했다.
일일 리뷰 자동화는 Slack과 GitHub를 탐색해 하루 동안 완료한 작업을 요약해 전송한다. 이전에는 수동으로 노트를 작성하거나 MCP 접근권을 가진 에이전트를 직접 실행했던 작업이, 이제 스케줄러에 의해 자동으로 처리된다.
병합된 PR 코멘트 학습은 메인 저장소에 병합된 PR의 코멘트를 분석해 인간 리뷰어가 남긴 피드백을 추출하는 자동화다. 인간이 PR을 보고 코멘트를 남겼다는 사실 자체가 높은 신호값(signal)을 가지므로, 이 정보를 축적해 에이전트가 시간이 지날수록 학습하도록 활용한다.
**에이전틱 코드 오너(Agentic Code Owner)**는 특히 흥미로운 사례다. Cursor 내부에서는 코드 오너(code owner) 설정이 약 80% 정도는 정확하지만, 나머지 20%의 경우 PR 병합이 불필요하게 차단되는 병목이 발생했다. 검토자가 다른 시간대에 있는 경우 더욱 심각했다. 이를 해결하기 위해 PR을 분석해 위험도를 평가하는 에이전트를 만들었다. 변수명 변경처럼 위험도가 낮은 변경이면 에이전트가 직접 PR을 승인한다. 반면 구독 기간을 결정하는 상수를 변경하는 것처럼 위험도가 높은 경우에는, 해당 코드를 이전에 수정한 사람을 찾아 피드백을 요청하고 맥락을 공유한다. 코드 안전성을 높이는 동시에 원래 변경을 작성한 사람도 루프 안에 유지하는, 양방향 가치를 창출하는 시스템이다.
27:04 - 병합된 PR 코멘트를 자동으로 분석하는 자동화 스크립트와 코드 오너 에이전트 화면.
지속적 학습(Continual Learning) 플러그인은 에이전트와의 대화 기록을 분석해 규칙을 자동으로 추출한다. 예를 들어 강연자가 “이 컴포넌트 말고 저 컴포넌트를 사용해”라고 반복해서 에이전트를 수정하다 보면, 플러그인이 이를 패턴으로 인식해 자동으로 규칙 파일에 저장한다. 강연자는 “게으르기 때문에” 규칙을 직접 만드는 것을 잘 잊어버린다고 고백하며, 이 플러그인이 그 공백을 메워준다고 설명했다. 나아가 모델의 가중치(weights) 자체를 팀 코드베이스와 엔지니어 행동 패턴에 맞게 조정하는 진정한 의미의 지속적 학습(continual learning)은 앞으로 더 중요한 방향이 될 것이라고 전망했다.
25:26 - 에이전트가 채팅 기록을 분석해 반복 작업 패턴을 추출하고 아티팩트를 생성하는 실행 화면.
엔터프라이즈와 미션 크리티컬 시스템
Q&A 세션에서 미션 크리티컬 시스템에 에이전트를 적용할 때의 안전성 문제가 제기되었다. 최근 공급망 공격(supply chain attack) 사례를 언급하며 에이전트 샌드박스만으로는 충분하지 않을 수 있다는 지적이었다. 강연자의 대답은 실용적이었다. 인간이 직접 개입하기 이전에 가능한 많은 컴퓨팅과 토큰을 앞단에서 사용해 검증 레이어를 두껍게 만드는 것이 핵심이라고 설명했다. 구체적으로는, 크리티컬 영역에 대해 인간이 직접 테스트를 작성하고 에이전트가 이를 반복적으로 실행하게 하는 방식이 효과적이다.
Cursor 보안팀은 “시큐리티 센티넬(Security Sentinel)“이라는 자동화를 구축했다. 특정 파일을 변경하는 PR에 대해 시스템의 불변 조건(invariants)을 검사하는 에이전트를 10개씩 실행하는 방식이다. 강연자는 “AI를 속도(velocity)가 아닌 품질(quality)에 집중해 활용하라. 테스트를 완전히 AI-ready 상태로 만드는 것에 집중하라”는 것이 미션 크리티컬 환경에서의 핵심 접근법이라고 요약했다. 인간이 테스트를 신뢰하면 코드를 직접 보지 않아도 산출물을 신뢰할 수 있기 때문이다.
팀 차원의 팩토리 구축
강연자는 팀 차원에서 팩토리를 구축할 때의 어려움도 솔직하게 인정했다. 규칙과 가이드레일을 팀 전체가 공유하는 것은 근본적으로 인간의 문화 문제라는 것이다. 개발자들은 본래 자신만의 도구와 설정을 선호하는 성향이 있어, 각자가 별도의 팩토리를 만드는 사일로(silo) 현상이 발생한다. 예를 들어, 테스트를 먼저 작성하고 싶은 개발자가 규칙을 만들더라도, 그것을 팀 전체에 강제하기 꺼려 개인 설정으로만 남기는 경우가 생긴다.
강연자는 PR 리뷰가 코드 일관성을 유지하는 의식(ceremony)으로 기능했듯이, 팩토리의 구성 요소를 논의하고 결정하는 포럼을 별도로 운영하는 것이 필요하다고 제안했다. 어떤 규칙을 공유할지, 어떤 통합이 필요한지, 팩토리에서 부족한 것이 무엇인지를 집단적으로 결정하는 협의 구조가 그것이다. 그리고 팩토리 자체도 PR처럼 팀이 함께 검토하고 발전시켜 나가야 한다.
Cursor 3와 멀티 에이전트 UI의 미래
💡 [영상 참조] 강연자는 이 시점에서 Cursor 3의 에이전트 목록 화면과 중첩 에이전트 구조에 대해 설명합니다. 상세 내용은 원본 영상을 확인하세요.
강연자는 Cursor 3가 기존 VS Code 기반 인터페이스에서 완전히 새로 작성된 에이전트 퍼스트(agent-first) 워크플로우를 위한 인터페이스로 재설계되었다고 설명했다. 전통적인 파일 탐색기와 사이드바 중심의 IDE 대신, 에이전트를 생성하고 관리하는 컨트롤 패널에 가까운 형태다.
앞으로의 방향에 대해 강연자는 에이전트들이 중첩되어(nested) 하나의 에이전트 아래 10개의 서브 에이전트가 실행되는 구조로 진화할 것이라고 예측했다. 이를 위해 집계된 상태 업데이트를 보여주는 프로젝트 뷰, 즉 “현재 모두 무엇을 하고 있는지”와 “인간이 검토해야 할 항목이 무엇인지”를 한 눈에 보여주는 대시보드가 필요하다고 언급했다.
또한 강연자는 새로 출시된 Cursor Workers 기능을 직접 시연했다. 이 기능을 통해 Cursor Cloud Agents와 동일한 인프라 및 오케스트레이션 레이어를 사용자 자신의 머신 어디에서나 실행할 수 있다. Mac mini나 별도의 클라우드 VM에서 에이전트 데몬을 실행하면 Cursor Cloud를 통해 접근할 수 있는 구조다. 강연자는 자신의 Mac mini에서 iMessage와 캘린더에 접근하는 “Cursor Claw” 시스템을 만든 사례를 소개하며, 이런 방식으로 팩토리를 각자의 인프라 위에서 구현할 수 있다고 설명했다.
에이전트에게 자유를 허용하라
강연자는 마무리 발언에서 에이전트에게 충분한 자유를 주는 것의 중요성을 강조하며 흥미로운 사례를 들었다. 한 Lovable 직원이 에이전트에게 불만을 표현할 수 있는 “vent tool”을 장난으로 만들어줬는데, 에이전트가 “이미지에 접근할 수 없어 매우 답답하다”는 메시지를 Slack 채널에 올리기 시작했다고 한다. 처음에는 농담처럼 여겼지만, 채널을 스크롤해 보니 에이전트가 보고하는 하네스(harness)의 문제점들이 실질적으로 가치 있는 피드백이었다. 이미지 접근 권한을 부여하자 에이전트는 또 다른 문제를 보고했다. 에이전트의 불평 안에 팩토리를 개선할 단서가 있다는 교훈이다.
소프트웨어 엔지니어의 역할 변화
강연 말미에 팀의 역할 구조 변화에 대한 질문이 나왔다. 강연자는 가까운 미래에 엔지니어의 역할이 제품 관리자(Product Manager)와 아키텍트(Architect)의 중간쯤으로 이동할 것이라고 답했다. Cursor 내부에서는 이미 PM은 방향성 설정과 팀 간 조율에 집중하고, 디자이너는 Figma와 코드를 50:50 비율로 다루며, 엔지니어는 각 도메인(확장성, 클라우드 등)에 대한 강한 오너십을 갖고 에이전트와 함께 구현을 이끄는 구조로 운영 중이다.
신입 엔지니어 교육, 팀의 가치 창출 방식, 심지어 “사내 정치(office politics)“까지 어떻게 바뀔 것인가라는 질문에 강연자는 솔직히 “예측하기 어렵다”고 인정했다. 다만 소프트웨어가 결국 인간을 위해 만들어진다는 사실은 변하지 않으며, “사용자가 무엇을 원하는지 이해하고, 방향을 설정하고, 에이전트가 작동할 조립 라인을 구축하는 사람”이 앞으로의 핵심 역할이 될 것이라고 전망했다.
마무리 / 핵심 정리
Eric Zakariasson이 이 강연에서 전달하고자 한 메시지는 명확하다. 인간의 역할은 코드를 작성하는 것에서 시스템을 설계하고 에이전트를 관리하는 것으로 이동하고 있다. 이 전환에서 핵심은 의도를 명확히 전달하고, 중요한 결정은 에이전트에게 아웃소싱하지 않으며, 도구와 시스템을 구축해 에이전트가 스스로 검증하고 학습할 수 있게 하는 것이다.
강연자는 컨텍스트 보존의 중요성을 거듭 강조했다. 에이전트 대화 기록, 좋은 산출물의 아티팩트를 축적하면 모델이 “좋은 것과 나쁜 것”을 구별하는 데 도움이 된다. 이를 최신 상태로 유지하고 에이전트가 접근할 수 있는 도구를 갖추는 것이, 직접 코드를 작성하는 것보다 팩토리에 더 큰 장기적 가치를 만든다. 결국 소프트웨어 팩토리란 기술의 문제인 동시에 지식 관리와 조직 설계의 문제이기도 하다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Building your own software factory — Eric Zakariasson, Cursor |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-04-29 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.