AI가 코드를 쓰는 시대, 이제 필요한 것은 ‘소프트웨어 공장’이다 (하네스)

AI 코딩 도구가 빠르게 발전하면서 소프트웨어를 만드는 속도는 이전과 비교하기 어려울 정도로 빨라졌다.

Cursor, Claude Code, Codex와 같은 도구를 사용하면 개발자는 몇 시간 만에 기능을 구현하고, 화면을 만들고, 테스트 코드까지 작성할 수 있다. 예전에는 며칠 걸리던 작업이 몇 시간 안에 끝나는 경우도 이제 낯설지 않다.

그런데 여기서 새로운 문제가 생긴다.

코드를 만드는 속도는 빨라졌지만, 좋은 소프트웨어를 지속적으로 배포하는 속도까지 같은 비율로 빨라진 것은 아니다.

AI가 만들어내는 코드가 많아질수록 리뷰해야 할 코드도 늘어난다. 품질 편차도 커지고, 어느 순간부터는 사람이 전체 시스템을 제대로 이해하지 못하는 상황까지 발생한다.

결국 AI 개발의 다음 경쟁력은 ‘코드를 얼마나 빨리 생성할 수 있는가’가 아니라,

AI가 만든 결과물을 어떻게 안정적으로 검증하고 지속적으로 제품으로 내보낼 것인가

로 이동하고 있다.

이 지점에서 다시 주목받는 개념이 있다.

바로 소프트웨어 팩토리(Software Factory)다.

---

소프트웨어 팩토리란 무엇인가

소프트웨어 팩토리를 단순하게 표현하면 다음과 같다.

사람이 개발 공정을 설계하고, 여러 AI 에이전트가 그 공정 안에서 반복적으로 소프트웨어를 생산하는 개발 체계

여기에서 중요한 단어는 ‘AI’보다 오히려 공정(Process)이다.

일반적인 AI 코딩은 개발자가 AI에게 이렇게 요청하는 형태다.

“로그인 기능 만들어줘.”

AI는 코드를 작성하고, 개발자는 결과를 확인한다.

반면 소프트웨어 팩토리에서는 작업이 조금 다르게 흘러간다.

먼저 요구사항이 표준화된 형태로 입력된다.

무엇을 만들어야 하는지, 어디까지 구현해야 하는지, 어떤 조건을 만족해야 하는지, 어떤 테스트를 통과해야 하는지가 정의된다.

그다음 여러 에이전트가 역할을 나눠 작업한다.

어떤 에이전트는 구현하고, 다른 에이전트는 테스트한다. 또 다른 에이전트는 보안이나 코드 품질을 검사할 수도 있다.

그리고 마지막으로 모든 결과물이 동일한 품질 검사를 통과한다.

이 조건을 만족한 변경만 실제 서비스에 반영된다.

구조를 단순화하면 다음과 같다.

요구사항 → 표준화된 Spec → 작업 Queue → AI Agent → 검증 → 리뷰 → 배포 → 사용자 피드백 → 다시 작업 Queue

이러한 루프가 하나가 아니라 여러 개 동시에 돌아가는 것이 소프트웨어 팩토리의 핵심이다.

---

AI 코딩과 소프트웨어 팩토리는 다르다

많은 조직이 개발자들에게 AI 코딩 도구를 제공하고 있다.

하지만 AI 도구를 많이 사용하는 조직이 반드시 AI 개발을 잘하는 조직은 아니다.

개발자 10명이 각자 AI를 사용하면 코드 생산량은 크게 증가할 수 있다.

문제는 그다음이다.

리뷰해야 할 Pull Request가 급증하고, 테스트해야 할 기능도 늘어난다. 각 개발자가 서로 다른 방식으로 AI를 사용하면서 코드 스타일이나 설계 방식도 달라질 수 있다.

결국 이런 상황이 발생한다.

코드 생산량은 10배 늘었는데 검증 능력은 그대로다.

이 경우 AI는 오히려 새로운 병목을 만들어낸다.

그래서 소프트웨어 팩토리는 단순히 AI에게 일을 많이 시키는 개념이 아니다.

AI가 만든 결과물이 반드시 일정한 공정을 통과하도록 만드는 것이 핵심이다.

---

공방의 품질과 공장의 품질

소프트웨어 팩토리를 이해하는 데 좋은 비유가 있다.

‘공방’과 ‘공장’의 차이다.

공방에서는 장인의 실력이 제품의 품질을 결정한다.

좋은 개발자가 있으면 좋은 코드가 나온다.

반면 공장에서는 조금 다르다.

제품의 품질이 특정 작업자의 능력에만 의존하지 않는다.

어떤 자재를 사용했는지, 어떤 공정을 통과했는지, 어떤 검사를 통과했는지가 품질의 근거가 된다.

소프트웨어 역시 같은 방향으로 이동할 수 있다.

기존에는 이런 질문이 중요했다.

“이 코드는 누가 만들었나?”

앞으로는 다음 질문이 더 중요해질 수 있다.

“이 코드는 어떤 기준을 만족했고, 어떤 검사를 통과했나?”

사람이 작성했든 AI가 작성했든 같은 품질 기준을 통과하도록 만드는 것이다.

---

소프트웨어 팩토리의 네 가지 조건

소프트웨어 팩토리를 운영하려면 최소한 네 가지 요소가 필요하다.

1. 입력의 표준화

AI에게 자유로운 자연어만 던지는 방식으로는 안정적인 결과를 얻기 어렵다.

작업 요청 자체가 일정한 구조를 가져야 한다.

예를 들어 단순히

“구글 로그인 만들어줘.”

라고 요청하는 것이 아니라,

• 기능 목표
• 구현 범위
• 기술적 제약
• Acceptance Criteria
• 테스트 요구사항
• 보안 요구사항

등을 명확하게 정의한다.

AI에게 좋은 코드를 요구하기 전에 좋은 작업 정의를 제공하는 것이 먼저다.

---

2. 공통 검증

사람이 작성한 코드와 AI가 작성한 코드가 다른 검사를 받아서는 안 된다.

모든 변경은 동일한 품질 기준을 통과해야 한다.

예를 들어 다음과 같은 항목들이다.

• Unit Test
• Integration Test
• E2E Test
• Security Scan
• Performance Test
• Accessibility
• 디자인 시스템 준수
• API 호환성
• 코드 품질 검사

AI가 만들었다는 이유만으로 더 느슨한 기준을 적용해서는 안 된다.

오히려 코드 생성량이 커질수록 자동 검증의 비중은 더 중요해진다.

---

3. 결과의 측정

공장은 측정할 수 있어야 한다.

소프트웨어 팩토리 역시 마찬가지다.

예를 들어 다음과 같은 지표를 볼 수 있다.

• 개발 사이클 타임
• PR Merge 시간
• 테스트 실패율
• 배포 후 버그 발생률
• Rollback 비율
• 보안 문제 발생률
• Agent 성공률
• Human Intervention 비율

어떤 AI 모델이 좋은지보다 더 중요한 질문은 이것일 수 있다.

어떤 개발 루프가 가장 안정적으로 좋은 결과를 만들어내는가.

---

4. 추적 가능성

생성형 AI는 같은 입력을 주더라도 항상 같은 결과를 만들지는 않는다.

따라서 완벽한 재현성보다는 어떻게 만들어졌는지를 추적할 수 있는 구조가 중요하다.

예를 들어 하나의 변경 사항에 다음 정보가 남을 수 있다.

• 어떤 Task에서 시작됐는지
• 어떤 Prompt를 사용했는지
• 어떤 모델을 사용했는지
• 어떤 Agent가 실행했는지
• 어떤 코드 버전을 기반으로 했는지
• 어떤 테스트를 통과했는지
• 누가 승인했는지

이 기록은 문제가 발생했을 때 매우 중요하다.

AI가 개발에 더 깊게 들어올수록 코드 자체뿐 아니라 생성 과정 역시 개발 자산이 된다.

---

결국 핵심은 Harness다

최근 AI Agent 개발에서 자주 등장하는 개념이 Harness다.

Harness는 AI Agent가 일하는 환경과 규칙 전체를 의미한다.

쉽게 말하면 AI에게 제공하는 ‘작업장’이다.

여기에는 다음과 같은 요소가 포함될 수 있다.

• Context
• Rules
• Tools
• Permissions
• Memory
• Runtime
• Tests
• Quality Gate
• Definition of Done

AI 모델이 아무리 좋아도 이런 구조가 없다면 결과 품질은 흔들릴 수밖에 없다.

반대로 모델이 조금 부족하더라도 좋은 Harness가 있다면 일정 수준 이상의 결과를 반복적으로 만들어낼 가능성이 높아진다.

그래서 앞으로 AI 개발에서 중요한 경쟁력은 모델을 선택하는 능력보다 Agent가 안정적으로 일할 수 있는 작업 환경을 설계하는 능력이 될 수 있다.

---

거대한 AI 하나보다 작은 루프 여러 개

AI Agent를 활용하는 방식에서도 변화가 나타나고 있다.

처음에는 하나의 강력한 Agent에게 긴 작업을 맡기는 방식이 주목받았다.

“이 서비스를 처음부터 끝까지 만들어줘.”

하지만 작업이 길어질수록 Context가 복잡해지고 오류가 누적될 수 있다.

그래서 최근에는 작업을 작게 나누고 짧은 Agent 실행을 반복하는 방식도 많이 논의된다.

예를 들어,

Task 1을 실행한다.

결과를 Git이나 파일에 저장한다.

다음 Task에서는 새로운 Context로 Agent를 실행한다.

그리고 다시 결과를 저장한다.

이런 작은 루프가 반복된다.

결국 소프트웨어 팩토리는 하나의 거대한 AI 개발자가 아니라,

수많은 작은 AI 작업 루프가 연결된 개발 조직

에 가깝다.

---

디자인 역시 공장의 품질 기준이 된다

소프트웨어 팩토리가 생산하는 것은 코드가 아니다.

사용자가 실제로 사용하는 제품이다.

따라서 디자인 역시 검증 대상이 된다.

예를 들어 다음과 같은 규칙을 자동으로 검사할 수 있다.

• 지정된 Color Token을 사용했는가
• Spacing 규칙을 지켰는가
• Typography가 Design System과 일치하는가
• Loading 상태가 존재하는가
• Empty State가 정의되어 있는가
• Error State가 존재하는가
• Keyboard Navigation이 가능한가
• 문구 Tone & Manner가 규칙을 따르는가

이렇게 되면 디자인 시스템은 단순한 Figma 파일이 아니다.

AI와 사람이 모두 읽을 수 있는 제품 품질 규칙이 된다.

디자인도 개발 이전 단계의 작업물이 아니라 배포를 결정하는 Quality Gate의 일부가 된다.

---

가장 위험한 문제, ‘이해 부채’

AI 개발이 빠르게 확산되면서 새로운 형태의 기술 부채도 등장한다.

바로 이해 부채(Understanding Debt)다.

AI가 코드를 작성하는 속도가 사람이 코드를 이해하는 속도보다 빨라지면 이런 상황이 발생한다.

코드는 계속 증가한다.

테스트도 통과한다.

서비스도 정상적으로 돌아간다.

그런데 어느 순간 문제가 발생했을 때 아무도 해당 코드가 왜 그렇게 만들어졌는지 설명하지 못한다.

전체 코드량과 사람이 실제로 이해하고 있는 코드 사이의 간격이 계속 커지는 것이다.

AI가 많은 코드를 만들어낼수록 이 문제는 더 빠르게 커질 수 있다.

따라서 모든 개발을 무조건 자동화하는 것이 좋은 전략이라고 보기는 어렵다.

---

같은 AI가 코드와 테스트를 만들 때 생기는 문제

AI 개발에서 특히 조심해야 할 부분이 있다.

같은 Agent가 기능을 구현하고 그 기능의 테스트까지 작성하는 경우다.

AI가 요구사항을 잘못 이해했다고 가정해보자.

그러면 잘못 이해한 요구사항을 기준으로 코드를 작성한다.

그리고 같은 이해를 바탕으로 테스트도 작성한다.

결과적으로 이런 상황이 가능하다.

코드는 잘못됐지만 테스트는 통과한다.

초록색 체크가 반드시 올바른 소프트웨어를 의미하지 않는 이유다.

따라서 중요한 기능에서는 구현과 검증을 분리하거나, 원래 Specification을 기준으로 독립적인 검증을 수행하는 구조가 필요하다.

---

모든 것을 자동화할 필요는 없다

소프트웨어 팩토리에서 중요한 것은 ‘사람을 없애는 것’이 아니다.

어떤 작업에 사람이 필요한지 결정하는 것이다.

자동화하기 쉬운 작업이 있다.

예를 들어 영향 범위가 작고 실패 여부를 기계적으로 판단할 수 있는 변경이다.

반면 사람이 반드시 판단해야 할 작업도 있다.

• 인증
• 결제
• 개인정보
• 권한
• 데이터베이스 Migration
• Public API
• 핵심 Architecture
• 중요한 보안 변경

이런 영역은 잘못됐을 때 영향이 크다.

따라서 AI가 구현하더라도 사람이 최종 판단을 하는 것이 합리적이다.

목표는 ‘Human 0%’가 아니다.

기계가 검증할 수 있는 것은 자동화하고, 판단이 필요한 곳에는 인간을 남기는 것.

이 경계를 설계하는 것이 중요하다.

---

AI 시대의 진짜 병목은 코드 생성이 아니다

AI 모델과 컴퓨팅 자원을 늘리면 코드 생성량은 계속 늘릴 수 있다.

하지만 사람의 Attention은 무한하지 않다.

QA 인력도 무한하지 않고, Security Review나 Architecture Review에 사용할 수 있는 시간 역시 제한되어 있다.

결국 AI 개발에서 가장 희소한 자원은 코드가 아니라 검증 능력이 된다.

그래서 앞으로 개발 조직이 고민해야 할 질문도 바뀔 가능성이 높다.

“어떤 AI가 코드를 가장 잘 쓰는가?”

보다

“우리는 AI가 만든 결과를 얼마나 빠르고 정확하게 검증할 수 있는가?”

가 더 중요한 질문이 된다.

---

개발자의 역할도 달라질 수 있다

AI가 코드를 더 많이 작성하게 된다고 해서 개발자가 필요 없어지는 것은 아니다.

다만 역할의 중심이 이동할 수 있다.

과거 개발자의 핵심 업무가 직접 코드를 작성하는 것이었다면 앞으로는 다음과 같은 일이 더 중요해질 수 있다.

무엇을 만들어야 하는지 정의한다.

Acceptance Criteria를 만든다.

Agent가 사용할 Context와 Tool을 설계한다.

자동화할 수 있는 검증 기준을 만든다.

중요한 Architecture를 결정한다.

그리고 최종 품질을 책임진다.

즉 개발자의 역할이

Coder

에서

Software Factory Designer

로 확장되는 것이다.

---

AI를 잘 쓰는 회사보다 ‘AI가 일하는 시스템’을 잘 만드는 회사

AI 코딩 도구는 빠르게 평준화될 가능성이 있다.

좋은 모델은 누구나 사용할 수 있고, 좋은 코딩 Agent 역시 많은 조직이 사용할 수 있다.

그렇다면 차이는 어디에서 만들어질까.

결국 조직 내부에 쌓인 다음과 같은 것들이 경쟁력이 될 수 있다.

• 좋은 Specification을 만드는 방법
• 좋은 Prompt와 Context
• 개발 규칙
• Design System
• 테스트 체계
• Quality Gate
• Security Policy
• Agent Workflow
• 실패 사례와 Feedback Loop

이것들은 단순히 AI 모델을 바꾸는 것으로 얻을 수 없다.

조직이 시행착오를 반복하면서 만들어야 한다.

그리고 이런 구조가 갖춰진 조직에서는 AI Agent가 하나 늘어날 때 단순히 개발자 한 명이 늘어나는 것이 아니라 생산라인 하나가 추가되는 효과가 나타날 수도 있다.

---

앞으로 중요한 질문

AI 개발의 초반 경쟁은 ‘누가 AI로 더 빨리 코드를 쓰는가’였다.

하지만 그 단계는 빠르게 지나가고 있다.

이제 더 중요한 질문은 이것이다.

AI가 하루에 수백 개의 변경을 만들어낸다면 우리는 그 결과를 어떻게 믿을 것인가?

소프트웨어 팩토리는 그 질문에 대한 하나의 답이다.

AI에게 더 많은 코드를 작성시키는 것이 아니라,

좋은 코드만 살아남는 개발 공정을 만드는 것.

AI 시대의 소프트웨어 경쟁력은 결국 코드 생성량이 아니라,

얼마나 안정적으로 검증하고, 얼마나 반복적으로 좋은 제품을 출하할 수 있는 시스템을 가지고 있는가

에서 결정될 가능성이 크다.

어쩌면 앞으로 가장 중요한 개발 능력은 코드를 잘 작성하는 능력만이 아닐지도 모른다.

AI가 좋은 소프트웨어를 계속 만들어낼 수 있도록 ‘공장’을 설계하는 능력.

그것이 소프트웨어 팩토리가 다시 주목받는 이유다.