Factory Model — 코딩 에이전트가 바꾼 소프트웨어 엔지니어링의 구조

엔지니어가 하루 종일 키보드 앞에서 코드를 짜는 모습은 곧 옛날 사진이 될 것 같다.

Addy Osmani가 제안한 **Factory Model(공장 모델)**은 코딩 에이전트가 대중화된 조직의 새 작업 구조를 설명한다. 핵심은 간단하다. 엔지니어가 "작업자"에서 "공장장"으로 이동한다.

공장 비유가 의미하는 것

전통적 소프트웨어 팀이 장인 공방이라면, AI 에이전트가 들어온 팀은 자동화 공장에 가깝다.

여기서 "기계"가 코딩 에이전트다. 엔지니어는 더 이상 라인 위에서 망치질하지 않는다. 대신 설비를 배치하고, 품질 게이트를 설계하고, 이상 상황에 개입한다.

엔지니어 역할의 네 가지 축

Addy가 제안한 새 축은 이렇다.

1. Spec Author — 사양 작성자

에이전트가 정확히 무엇을 만들어야 하는지 정의한다. 입력 조건, 기대 출력, 성공 기준을 명시적으로 쓰는 역량이 핵심이다.

목표: 주문 취소 API 추가
입력: orderId(string), reason(enum)
성공 기준:
  - 취소 가능 상태(Pending, Paid)만 처리
  - 결제 완료 건은 환불 API 호출 후 상태 변경
  - 감사 로그에 취소 사유 기록
실패 시: 400 응답, 원인 메시지 반환

잘못된 사양은 잘못된 코드로 직결된다. "적당히 만들어줘"는 작동하지 않는다.

2. Process Designer — 공정 설계자

어떤 에이전트에게, 어떤 순서로, 어떤 도구를 줄지 설계한다. 서브에이전트 구조, 검증 파이프라인, 롤백 정책이 여기 포함된다.

3. Quality Inspector — 품질 검사자

에이전트 산출물을 검토한다. 모든 라인을 읽는 게 아니라, 자동 테스트·정적 분석·샘플링 리뷰로 품질을 보장한다. 공장에서 완제품을 전수 검사하지 않는 것과 같다.

[💡 잠깐! 이 용어는?] 샘플링 리뷰: 전체 변경 중 일부만 추출해서 심층 검토하는 방식. 나머지는 자동화된 검증에 위임한다.

4. Exception Handler — 예외 처리자

에이전트가 막힌 지점에서 사람이 개입한다. 모호한 요구사항, 정치적 판단이 필요한 결정, 엣지케이스가 여기 해당한다.

팀 구조의 변화

10명짜리 팀이 어떻게 재편되는지 가상의 예시를 보자.

총원은 비슷하지만, 저레벨 코드 작성 포지션이 줄고 설계·품질 포지션이 늘어난다. 기존 주니어가 사라진다는 뜻이 아니라, 업무가 사양 리뷰·에이전트 관리로 이동한다는 의미다.

생산성 지표도 바뀐다

기존 지표(LoC, PR 수)는 공장 모델에서 의미가 옅어진다. 대신 이런 지표가 중요해진다.

• 에이전트 작업 성공률: 사람 개입 없이 완결된 작업 비율
• 재작업 비율: 에이전트 산출물이 수정된 정도
• 사양 품질: 사양 한 번으로 통과한 비율
• 예외 개입 시간: 사람이 막힌 지점에서 보낸 시간

포인트: "얼마나 많이 짰나"가 아니라 "얼마나 적게 개입하고도 돌아가게 했나"가 생산성이 된다.

주의할 점

Factory Model은 장밋빛이 아니다.

기술 부채의 성격이 바뀐다. 에이전트가 대량 생산한 코드는 로컬 최적은 될 수 있어도 아키텍처 일관성이 흔들린다. 시니어의 리팩토링 투자가 오히려 더 중요해진다.

주니어 성장 경로가 흐릿해진다. 코드를 직접 짜면서 배우던 경로가 줄어든다. 사양 작성·리뷰 중심의 새 교육 과정이 필요하다.

디버깅 난이도 상승. 에이전트가 생성한 코드의 버그를 사람이 디버깅할 때, 코드의 의도를 읽는 데 시간이 더 든다.

정리

• 엔지니어 역할이 장인에서 공장장으로 이동한다
• 핵심 역량은 사양·공정·품질·예외 처리로 재편된다
• 지표도 생산량에서 개입 효율로 바뀐다
• 주니어 성장 경로와 아키텍처 관리는 여전히 사람의 몫이다

코딩 에이전트가 대중화된 이후 "무엇을 빠르게 짜는가"는 덜 중요해진다. **"무엇을 만들 것인지 정확히 정의하는 능력"**이 새로운 상위 역량이다.

참고:

• Addy Osmani: https://addyosmani.com/blog/factory-model/