소프트웨어 팩토리

한 줄로 말하면

소프트웨어 팩토리는 사람이 코드 한 줄 한 줄을 모두 생산하는 대신, 프롬프트와 지식 베이스로 에이전트의 작업 방향을 잡고 테스트·평가·배포 장치로 결과를 확인하는 개발 조립 라인이야.¹

비유로 이해하기

자동차 공장을 떠올리면 쉬워. 한 사람이 자동차 전체를 만드는 게 아니라, 여러 공정이 정해진 순서와 품질 기준을 따라 움직여. 소프트웨어 팩토리에서도 에이전트는 변경을 만들고, 테스트와 린팅과 타입 시스템은 조립 중간의 검사대가 돼.

다만 이 비유에는 한계가 있어. 에이전트는 정해진 규칙만 적용하는 컴파일러가 아니라, 불완전한 기존 코드와 부정확한 요구를 읽고 새 변경을 만드는 새 인턴에 가까워.² 그래서 조립 라인은 자동으로 안정되는 것이 아니라, 사람이 좋은 접근법과 아키텍처 원칙을 먼저 시험하고 정리할수록 더 안정적으로 반복돼.³

정확한 정의

소프트웨어 팩토리는 코드 생성 도구 하나를 뜻하지 않아. 다음 요소가 서로 이어진 작업 구조를 말해.

flowchart LR
    A["요구사항·프롬프트"] --> B["지식 베이스·작업 규칙"]
    B --> C["AI 코딩 에이전트"]
    C --> D["코드 변경"]
    D --> E["테스트·린팅·타입 검사"]
    E --> F["평가·사람의 확인"]
    F --> G["배포"]
    E -. "실패·부족한 점" .-> C
    F -. "패턴·원칙 보강" .-> B

프롬프트와 지식 베이스는 에이전트가 어떤 맥락에서 어떤 변경을 시도할지 정해. 테스트, 린팅, 타입 시스템, 평가와 자동 평가 도구는 결과가 요구한 조건을 지켰는지 확인해. 충분한 제약과 최신 맥락이 있으면 성능이 낮은 모델도 경로를 크게 벗어나지 않는 변경을 만들 수 있다는 설명이 이 구조의 출발점이야.⁴

이 흐름에서 평가는 마지막 관문으로만 머물지 않아. 테스트 실패나 평가 결과가 다음 수정의 입력이 되어 변경 방향을 바꾸면 reflection 구조가 돼. 결과를 만들고, 기준에 비춰 부족한 점을 찾고, 그 판단으로 다시 고치는 반복이기 때문이야.

왜 중요한가

AI가 코드 대부분을 만들어도 소프트웨어 엔지니어의 일은 사라지지 않아. 역할의 중심이 코드 생산에서 조립 라인의 설계와 유지로 이동하기 때문이야. 누구나 프롬프트로 변경을 요청하고 결과를 배포할 수 있게 하려면, 에이전트가 성공할 맥락과 결과를 막아 세울 검증 장치를 함께 만들어야 해.⁵

여기서 사람의 직접 코딩도 여전히 의미가 있어. 에이전트가 만든 diff와 패치를 읽는 것만으로는 시스템 구조와 깊이 연결되기 어렵지만, 직접 코드를 지우고 실행하면 어떤 기능을 더할 때 무엇이 깨지는지 더 선명하게 알 수 있어.⁶ 직접 코딩은 생산량을 지키는 의식이 아니라, 공장의 기준을 세우고 약한 테스트와 불필요한 예외를 발견하는 방법이 되는 거야.

실제 예시

에이전트에게 기존 코드의 상태 저장 방식을 바꾸라고 요청했다고 해보자. 에이전트는 현재 코드와 변경 설명을 읽고, 그 안에 있는 결정을 의도적인 원칙으로 보수적으로 보존할 수 있어. 실제 한 코드베이스에서는 일부 상태만 브라우저 로컬 스토리지를 쓰고 나머지는 백엔드 데이터베이스에 저장했는데, 에이전트가 그 결정을 유지하려고 래핑과 간접 계층을 더했고 코드 줄 수가 약 3배로 늘었다는 사례가 소개돼.⁷

이 사례가 보여주는 건 에이전트가 항상 나쁘다는 뜻이 아니야. 사람이 우연히 남긴 선택도 반복 가능한 규칙처럼 읽힐 수 있다는 뜻이야. 그래서 공장에는 코드 생성만큼이나 아키텍처 원칙을 문서화하고, 디버깅에서 드러난 테스트 전략의 약점을 고치는 일이 필요해.⁸

헷갈리지 말아야 할 점

• 소프트웨어 팩토리는 무인 생산과 같은 말이 아니야. 사람이 모든 코드를 손으로 써야 한다는 뜻은 아니지만, 사람이 기준과 패턴과 확인 지점을 설계해야 해.
• 에이전트는 컴파일러가 아니야. 컴파일러처럼 입력이 정확하면 결과도 정해진다고 생각하면, 품질이 낮은 변경을 그대로 배포하는 태도로 이어질 수 있어.⁹
• 검사 장치가 많다고 품질이 자동으로 보장되지는 않아. 테스트가 약하면 약한 테스트를 통과한 코드만 반복해서 만들 수 있어. 무엇을 실패로 판정할지까지 설계해야 해.
• 직접 코딩과 자동화는 양자택일이 아니야. 대부분의 코드를 AI가 만들더라도, 사람이 직접 실행 환경을 다루며 기준을 갱신하는 일은 남아 있어.¹⁰

관련 문서

• 도구·맥락·검증·권한·사람의 개입을 묶은 작업 흐름: agentic workflow
• 평가 결과를 다음 수정으로 되돌리는 구조: reflection
• 소프트웨어 팩토리라는 관점이 나온 원문 읽기: AI가 코드를 써도 손을 떼면 판단이 무뎌진다

남은 질문들

• 어떤 아키텍처 원칙을 문서화해야 에이전트가 우연한 과거 결정을 규칙으로 확대하지 않을까?
• 테스트·린팅·타입 검사·평가 중 어떤 장치가 어떤 종류의 실패를 가장 빨리 드러낼까?
• 사람이 직접 코드를 만져야 하는 경계와 에이전트에게 반복을 맡겨도 되는 경계는 어떻게 정할까?

각주

1. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

2. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

3. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

4. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

5. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

6. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

7. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

8. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

9. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎

10. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎