소프트웨어 팩토리: AI를 활용한 ADLC에서의 계획(Plan), 구축(Build), 평가(Evaluate)

무작위 테스트 한 번에서, AI 도구를 사용하는 숙련된 개발자는 자신의 작업을 완료하는 데 19% 더 많은 시간이 걸렸습니다. 연구가 시작되기 전, 그들은 AI가 자신들을 24% 더 빠르게 만들어 줄 것이라고 예상했습니다. 연구가 끝난 후에도, 그들은 여전히 AI가 작업 속도를 높였다고 믿고 있습니다 (METR, 2025).

같은 해에 다른 수치도 있었습니다: Faros AI는 AI 도입률이 높아질수록 33.7% 더 많은 작업을 완료하는 것과 함께 진행되지만, 개발자당 54% 더 많은 버그와 PR(Pull Request)당 약 240% 더 많은 인시던트도 발생한다고 보고했습니다 (Faros AI).

즉, AI는 코드를 더 빠르게 생성하지만, 우리는 우리가 실제로 더 빨리 끝났는지, 아니면 결과가 더 좋은지를 평가하는 데 서툽습니다. 바로 이 간극이 이 기사의 핵심입니다. 만약 당신이 AI가 배포 프로세스의 실제 부분을 수행하기를 원한다면, 그것을 팩터리(factory)처럼 다루어야 합니다: 정의된 입력, 정의된 작업 스테이션, 그리고 각 스테이션에서의 품질 검사 말입니다. 본 기사는 소프트웨어 팩토리가 무엇인지, 이것이 AI 기반 개발 수명 주기(AI-Driven Development Life Cycle, ADLC)에 어떻게 통합되는지, 그리고 좋은 Plan, Build, Evaluate 루프가 어떤 모습인지를 논합니다. 이 글은 팀의 파이프라인(pipeline), 리뷰, 권한 방식을 변경할 권한을 가진 테크 리드와 엔지니어링 매니저를 위해 작성되었습니다.

용어에 대한 간략한 참고 사항.

이 용어는 AI의 과열풍보다 더 오래되었습니다. 미국 국방부가 이 개념을 사용하여 소스 코드를 인간의 개입을 최소화하여 배포 준비가 된 아티팩트로 변환하는 파이프라인에 활용했습니다. 당시 버전에서는 사람이 파이프라인을 직접 운영했습니다.

'Agentic'한 새로운 의미는 작업 분담 방식을 변화시킵니다. Faros는 소프트웨어 팩토리를 'AI 에이전트, 엔지니어링 도구, 조직 컨텍스트'에 자동화된 워크플로우, 검증(verification), 인간의 평가를 결합하여 작업을 진행하고 최종적으로 배포되는 소프트웨어를 만드는 시스템으로 정의합니다(Faros AI). 이에는 세 가지 부분이 있습니다:

1. 입력(Intake) 및 오케스트레이션(orchestration). 일련의 장치(harness)가 어떤 에이전트와 모델이 특정 작업을 맡을지, 그들이 어떤 도구와 컨텍스트를 얻게 될지, 그리고 어느 지점에서 인간의 승인이 필요한지를 결정합니다.
2. 지식 및 실행(Knowledge and execution). 컨텍스트 엔지니어링(Context engineering), 에이전트 메모리, 스킬이 에이전트에게 자원을 제공하며, 이들은 통제된 환경에서 작업합니다.
3. 검증 및 피드백(Verification and feedback). 테스트, 평가(eval), 에이전트 리뷰어, 인간의 검토가 작업이 다음 단계로 진행할 수 있는지 여부를 결정합니다. 반복적인 실패는 시스템으로 다시 입력됩니다.

인간의 역할도 변화합니다. 코드를 적게 작성하고 명세서(specification), 인수 조건(acceptance criteria), 에이전트 컨텍스트, 평가, 권한(permission), 그리고 평가가 필요한 엣지 케이스(edge cases)에 더 많은 시간을 할애하게 됩니다.

주의: Faros는 바로 이러한 목적을 위한 플랫폼을 판매하며, 해당 페이지 자체도 아직 표준 정의나 산업 벤치마크가 없음을 인정합니다. 이 프레임워크를 확립된 진실이 아닌 유용한 관점 중 하나로 간주하십시오.

ADLC의 위치

AWS는 2025년 7월에 작성한 글(AWS DevOps Blog)에서 ADLC를 설명했습니다. 핵심 아이디어는 AI가 프로세스의 중심에 위치하며, 인간이 여전히 결정을 내린다는 것입니다. 세 가지 단계가 있습니다:

AWS의 글은 어떠한 측정 결과도 제공하지 않는다는 점에 유의하세요. "주에서 일로"라는 문장은 벤치마크가 아닌 주장입니다. AWS는 또한 이 워크플로우를 Amazon Q Developer(awslabs/aidlc-workflows)와 같은 도구에 로드할 수 있는 규칙(rules)으로 공개했습니다.

공장이라는 은유가 여기에 적합합니다. ADLC는 공장의 평면도입니다. 소프트웨어 팩토리는 그 바닥의 기계 및 품질 관리 시스템입니다.

왜 게이트웨이가 중요한가: 연구 결과가 말해주는 것

세 가지 연구 결과가 제가 이 주제에 대해 생각하는 방식을 형성했습니다. 각각은 서로 다른 게이트웨이를 가리킵니다.

1. AI는 명확하게 정의된 작은 작업에서 가장 빠르다. 이것이 'Plan' 게이트이다. 2023년 실험에서 GitHub Copilot을 사용한 개발자는 JavaScript로 HTTP 서버를 만드는 작업을 대조군보다 55.8% 더 빠르게 완료했으며, 신뢰 구간(confidence interval)은 95%로 21%부터 89%까지였다 (Peng et al., arXiv:2302.06590). 이 작업은 그린필드(greenfield), 독립적이며 명확하게 정의되었다. 바로 이러한 조건에서 가속도가 발생한다. 교훈은 "AI가 모든 것을 더 빠르게 만든다"가 아니다. 교훈은 "입력이 작고 명확할 때 AI가 빠르다"이다. 코드를 작성하기 전에 모호하거나 너무 큰 작업을 거부하는 게이트를 만드는 것이 의도적으로 이러한 조건을 조성하는 방법이다.

2. 개발자는 AI의 도움 여부를 느낄 수 없다. 이것이 'Evaluate' 게이트이다. METR 테스트는 16명의 숙련된 오픈소스 개발자가 자신들이 잘 아는 저장소(repo) 내의 246개 작업에 걸쳐 수행한 것이다. AI를 사용했을 때 완료 시간이 19% 증가했지만, 개발자들은 AI가 자신들을 더 빠르게 만들었다고 믿는다 (METR, arXiv:2507.09089). METR 자체는 이것을 단일 시점의 연구라고 언급했으므로, "AI가 느리다"로 읽어서는 안 된다. "당신의 속도에 대한 느낌은 신뢰할 수 없다"로 읽어야 한다. 작업하는 사람조차 알 수 없다면, 유일한 방법은 측정된 결과와 기준선(baseline)을 비교하는 마지막 게이트를 통해서이다.

3. AI는 이미 존재하는 프로세스를 강화합니다. 이것이 바로 Build 단계의 관문입니다. DORA 2025 보고서에 따르면, 'AI의 주요 역할은 증폭기(amplifier)로서 조직에 이미 존재하는 강점과 약점을 확대하는 것'이며, 가장 큰 결과는 도구(tools)가 아닌 조직 시스템에서 나온다고 합니다 (DORA 2025; [DORA AI Capabilities Model]도 참조). 취약한 배포 프로세스에 AI를 결합하면, 더 빠르지만 여전히 취약한 배포 프로세스가 탄생합니다. 생성된 코드 결과와 메인 브랜치 사이에 존재하는 테스트, 스캔, 권한 확인(permission), 수동 검토(review) 같은 점검 과정은 강화되는 프로세스의 일부입니다. 만약 이 점검이 약하면, AI는 충분히 검사되지 않은 더 많은 코드를 생성합니다. 반면, 점검이 강력하다면, AI는 이미 검사된 더 많은 코드를 생성합니다.

결합해 보면, 가속화는 특정 조건에서만 실질적이며 다른 조건에서는 보이지 않고, 품질 비용은 나중에 발생합니다. 각 단계의 관문(gate)은 좋은 조건을 만들고, 그 비용을 더 일찍 포착하며, 모든 것이 성공했는지 알 수 있는 방법입니다. 본 기사에서는 이 세 가지 관문(Plan, Build, Evaluate)에 대해 순차적으로 논의합니다.

1단계: Plan (개념화/Inception)

좋은 계획이란: 코드가 작성되기 전에 짧고, 문서화되어 있으며, 인간의 승인을 받은 계획입니다.

ADLC에서 AI가 질문을 제기하고 팀이 답변하는 것이 바로 이 단계입니다. AWS의 글에 따르면 AI는 '작업 계획을 수립하고 명확화 질문을 제시'하며, 계획이 검증된 후에야 구현합니다. 인간이 결정권을 가지는데, 그들이 비즈니스 맥락(context)을 가지고 있기 때문입니다.

여기서 파생되는 몇 가지 실질적인 습관들 (이는 제가 위 자료들을 바탕으로 구성한 권장 사항입니다):

• AI가 인터뷰하도록 하세요. 비즈니스 의도를 제공하고 AI에게 명확하지 않은 부분을 목록화해 달라고 요청하세요. 서면으로 답변하세요. 이 답변은 다음 각 단계의 컨텍스트 일부가 됩니다.
• 작업 단위로 분할하세요. 하나의 단위는 한 사람이 한 번에 검토할 수 있어야 합니다. 빠르게 검토할 수 없다면, 그 단위는 너무 큰 것입니다.
• 코드를 작성하기 전에 승인 기준을 작성하세요. 테스트, 쿼리, 스크린샷 비교 등 확인할 수 있는 것을 만드세요. '잘 작동함'은 기준이 아닙니다.
• 게이트를 지금 결정하세요. 각 단위에 대해 누가 무엇을 승인할지, 그리고 에이전트가 건드릴 수 없는 것(인증(auth), 청구(billing), 마이그레이션(migration), 프로덕션 설정(config production))은 무엇인지 정하세요.
• 컨텍스트를 파일로 저장하세요. 명세서, 아키텍처 노트, 코딩 규칙은 에이전트가 읽을 수 있도록 리포지토리(repo)에 있어야 합니다. 이것이 공장의 '컨텍스트 엔지니어링' 부분입니다.

흔한 실수: 에이전트가 빠르기 때문에 계획 단계를 건너뛰는 것입니다. 잘못된 것을 빠르게 생성하는 것도 여전히 틀린 것이며, 이제 검토해야 할 것이 더 많아집니다.

2단계: 구축(Build)

좋은 예시: 작은 볼트, 제한된 에이전트, 그리고 사람이 한 줄을 읽기 전에 실행되는 자동화된 검사입니다.

구축 단계 동안 AI는 아키텍처, 도메인 모델, 코드 및 테스트를 제안하고, 팀은 중요한 기술적 결정에 피드백을 제공합니다. 이 단계를 통제 상태로 유지하는 몇 가지 습관이 있습니다:

• 모든 볼트(변경사항)는 짧고 제한적으로 유지해야 합니다. 작업 단위 하나, 브랜치 하나, PR 하나를 사용하세요. 작은 배치로 진행하면 리뷰가 가능해지고 롤백 비용도 저렴해집니다.
• 테스트가 논하게 하십시오. 에이전트에게 먼저 인수 조건(acceptance criteria)을 기반으로 테스트를 작성하도록 요청한 다음 구현에 착수해야 합니다. 테스트와 코드가 독립적인 검토 없이 동일한 프롬프트에서 나온 경우, 그 테스트는 버그를 확인하는 역할만 할 수 있습니다.
• 리뷰 전에 자동 게이트를 실행하십시오. 린트(Lint), 타입 체크(type check), 테스트, 보안 스캔은 사람이 시간을 들여 보기 전에 PR을 실패 처리해야 합니다.
• 권한을 제한하십시오. 에이전트는 필요한 최소한의 접근 권한만 얻어야 합니다. "이 작업에 이 도구를 할당한다"고 결정하는 하네스(Harness)는 공장 모델에서 묘사되는 것과 정확히 같습니다.
• 감정이 아닌 diff를 검토하십시오. 자동화된 검사는 코드가 실행된다는 것을 알려줄 뿐입니다. 코드가 올바른 작업을 수행하고 있다는 것은 오직 독자만이 알려줄 수 있습니다. 모든 병합(merge)에 대한 책임은 여전히 인간에게 있습니다.

흔한 실수: 리뷰를 단순한 도장 찍기 행위로 내버려 두는 것입니다. AI가 하루에 10개의 PR을 생성할 때, 리뷰는 병목 현상이 되고 대충 읽어봐야 한다는 압박감이 커집니다. 검토자의 인내심이 아니라 파이프라인(더 작은 PR, 더 나은 자동화된 검사)을 개선해야 합니다.

단계 3: 평가 (및 운영)

좋은 방식이란: 코드가 아닌 시스템 수준에서 결과를 측정하고, 실패가 공장 자체를 변화시키는 것입니다.

이것은 팀들이 가장 자주 건너뛰는 단계이며, METR 결과가 이 단계를 절대 건너뛰어서는 안 되는 이유입니다. 개발자는 더 빠르다고 느끼지만 실제로는 느립니다. 여기서는 느낌을 믿을 수 없습니다.

측정하는 것: