AI-DLC: Claude Code와 Codex 등에서 요구사항부터 배포까지 진행하며, 필요한 경우 사람 승인 단계를 강제하는 워크플로우 (feat. AWS)

9bow · 10월 16, 2026, 2:30오전

핵심 요약

AI-DLC는 AWS가 공개한 AI 주도 개발 방법론의 오픈소스 구현체로, AI가 아닌 결정적(deterministic) 엔진이 다음 단계를 정하고 코딩 에이전트는 그 단계를 수행한 뒤 사람의 승인을 기다립니다.
하나의 코어를 Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, GitHub Copilot에서 실행합니다. 다만 에이전트의 행동을 거부하는 강도는 하네스마다 다릅니다.
5개 단계(phase)와 33개 스테이지(stage)를 기본으로 하되, 8개 스테이지만 거치는 개념 증명(poc)부터 33개를 모두 거치는 엔터프라이즈(enterprise)까지 11개의 워크플로우 프로필로 진행 범위를 고릅니다.
권장 모델은 Claude Opus 4.8이고, 인프라 설계와 환경 구성 스테이지를 이끄는 에이전트는 AWS(CDK, CloudFormation) 기준으로 정의되어 있습니다. 2026년 9월 1일부터 10월 8일까지 안정 버전이 7개 나왔을 만큼 변화도 빠릅니다.

AI-DLC 소개

코딩 에이전트에게 "재고 관리 REST API를 만들어 줘" 같은 요청을 그대로 맡기면, 무엇을 먼저 묻고 언제 코드를 쓰기 시작할지는 모델이 정합니다. 작업이 작을 때는 문제가 되지 않지만, AI-DLC 프로젝트는 이런 즉흥적인(ad-hoc) AI 코딩이 프로젝트가 커질수록 맥락을 잃는다고 봅니다. 어떤 요구사항에서 어떤 설계 결정이 나왔는지, 테스트는 무엇을 기준으로 작성됐는지가 대화 기록 속에 흩어진다는 것입니다. 에이전트에게 규칙 파일을 주고 순서를 지키라고 지시할 수는 있지만, 그 지시를 따를지는 결국 모델에 달려 있습니다. 이번에 소개하는 AI-DLC(AI-Driven Development Life Cycle)는 AWS가 공개한 오픈소스 워크플로우 프로젝트입니다. 요구사항부터 배포까지의 흐름을 정해진 스테이지와 승인 게이트(approval gate)로 나누고, 그 순서를 별도의 엔진이 관리합니다.

AI-DLC는 AWS가 2025년 7월 블로그 글과 방법론 정의 문서로 공개한 개발 방법론에서 출발했습니다. 이 방법론의 핵심은 대화의 방향을 뒤집는 것입니다. 사람이 AI에게 일을 하나씩 시키는 대신 AI가 계획을 세우고 필요한 내용을 질문합니다. 사람은 그 계획을 검토하고 승인하는 역할을 맡습니다. 아래 그림은 AWS 블로그에 실린 이 순환 구조입니다. 보라색 AI TASKS는 계획 작성(Create Plan), 질문(Seek Clarification), 구현(Implement Plan)이고, 주황색 HUMAN TASKS는 사람이 답을 주는 단계(Provide Clarification)입니다:

블로그는 방법론의 또 다른 축으로 팀 협업을 듭니다. 착수 단계에서는 팀 전체가 AI의 질문과 제안을 함께 검증하는 몹 정교화(Mob Elaboration)를 하고, 구축 단계에서는 기술 결정을 실시간으로 함께 정하는 몹 구축(Mob Construction)을 합니다. 작업 주기도 몇 주 단위의 스프린트 대신 몇 시간에서 며칠 단위의 볼트(bolt)로 바꾸고, 에픽(Epic)은 작업 단위(Unit of Work)로 대체합니다.

저장소는 이 방법론을 두 번에 걸쳐 구현했습니다. 첫 버전(v1)은 각 코딩 에이전트의 규칙 디렉토리에 복사해 넣는 마크다운 규칙 파일 묶음이었고, 지금도 v1 브랜치에서 유지보수되고 있습니다.

반면 2026년 6월 2.0.0부터 이어진 2.x 버전은 워크플로우 계층을 다시 만들었습니다. AI-DLC Workflows 2.0 명세에 따르면, 고객 사례에서 1.0의 스테이지 정의는 지나치게 정해진 방식을 강요해(too opinionated) 도입의 걸림돌이 됐습니다. 예를 들어 1.0은 빌드와 테스트를 한 스테이지로 다뤘지만, 대부분의 고객에게는 리뷰, 빌드, 기능 테스트, 보안 테스트가 따로 이어지는 일이었습니다. 그 사이 에이전트 플랫폼에는 스킬(Skills)과 멀티 에이전트 런타임이 생겼고, 결정적인 생명주기 훅(hook)으로 진행을 멈추고 감사 기록을 남길 수도 있게 됐습니다. 그래서 규칙 문서만이 아니라 실행 장치로 흐름을 강제할 수 있게 됐습니다.

명세는 장기 방향도 밝힙니다. 기계가 검사할 수 있는 검증 범위가 넓어지는 만큼 사람의 개입을 점차 줄여 자율적인 소프트웨어 개발로 나아가겠다는 것입니다. 다만 사람의 개입을 완전히 없앨 수 있는지에 대해서는 아직 합의하지 못했다고 덧붙이고 있습니다.

현재 버전은 aidlc라는 네이티브 실행 파일과 TypeScript로 작성된 엔진, 그리고 하네스별 설정을 생성하는 패키징 도구로 구성되어 있습니다.

AI-DLC와 기존 방식 비교

AI 코딩 에이전트에 개발 절차를 입히는 프로젝트는 이미 여럿 있습니다. 각 프로젝트가 스스로 밝힌 절차의 성격을 나란히 놓으면 다음과 같습니다:

프로젝트	설치	시작 명령	절차를 다루는 방식 (원문 기준)
AI-DLC 2.x	네이티브 설치 스크립트 (`aidlc`)	`/aidlc` (Codex CLI는 `$aidlc`)	결정적 엔진이 다음 스테이지를 정하고, 승인 게이트에서 사람의 답을 받을 때까지 멈춤
AI-DLC 1.x (`v1` 브랜치)	규칙 zip 파일을 에이전트 규칙 디렉토리에 복사	에이전트에 작업 요청	3단계 적응형 워크플로우를 규칙 문서로 지시
Spec Kit ( GitHub, 스펙 기반 개발(Spec-Driven Development)를 위한 실험적 프레임워크 Spec Kit 공개)	`uv tool install specify-cli`	`specify init` 후 에이전트 명령	스펙 주도 개발, 버그 수정, 아이디어 평가가 서로 독립된 진입점이며 필수 단계가 아님
OpenSpec ( OpenSpec: AI 에이전트 행동 정의를 위한 오픈소스 경량 프레임워크)	npm 패키지	`/opsx:propose` 등	"fluid not rigid" 를 원칙으로 변경 제안 단위로 진행
BMad Method ( BMad-Method: AI 중심의 애자일 개발 방식을 진환시킨 범용 AI 에이전트 프레임워크)	`npx bmad-method install` (v6.12)	`bmad-build`	어느 단계에서든 시작할 수 있는 전달 루프

다른 세 프로젝트가 절차를 유연하게 고르는 쪽에 무게를 두는 반면, AI-DLC 2.x는 가장 엄격한 쪽에 서 있습니다. 진행 순서는 모델이 아니라 엔진이 정합니다. 순서를 줄이고 싶을 때도 에이전트가 단계를 건너뛰는 것이 아니라, 사람이 더 작은 워크플로우 프로필을 고르거나 /aidlc --skip <stage>로 뺄 스테이지를 지정해 경로 자체를 바꿉니다. 같은 저장소의 1.x와 2.x를 비교해도 차이는 같습니다. 1.x는 규칙을 문서로 전달했고, 2.x는 훅이 에이전트의 도구 호출을 검사해 거부할 수 있습니다.

AI-DLC를 사용하면 좋을 사용자

AI-DLC는 요구사항, 설계 결정, 구현, 테스트가 어떻게 이어졌는지를 나중에 다시 확인해야 하는 팀에 맞습니다. 모든 스테이지가 버전 관리되는 마크다운 산출물과 감사(audit) 기록을 남기고, 규제 대상 업무를 위한 enterprise 프로필은 33개 스테이지를 가장 상세한 깊이로 진행합니다. 여러 사람이 Claude Code, Codex CLI, Copilot처럼 서로 다른 도구를 쓰는 조직이라면, 같은 방법론과 같은 산출물 구조를 도구마다 따로 맞추지 않아도 된다는 점도 장점입니다. AWS에 배포하는 팀은 인프라 설계(3.4)와 환경 구성(4.2) 스테이지를 이끄는 AWS 플랫폼 에이전트가 CDK와 CloudFormation 템플릿을 작성한다는 점에서 얻는 것이 더 많습니다.

반대로 한 파일짜리 스크립트나 짧은 실험에는 절차가 과합니다. 방법론 정의 문서도 트레이드오프(trade-off)가 거의 없는 단순한 시스템은 AI-DLC의 범위 밖이라고 밝히고 있습니다. 모델 선택도 제약입니다. 프로젝트는 Claude Opus 4.8을 권장하며, Kiro 하네스 문서는 약한 모델이 리뷰어 검토나 학습 단계 같은 선택 단계를 건너뛰고 승인 게이트를 서두를 수 있다고 경고합니다. Opus를 쓸 수 없어 Sonnet 같은 중간급 모델만 쓰는 조직에는, 세션을 medium 노력 수준으로 시작하고 어려운 단위의 코드 생성처럼 필요한 스테이지에서만 높이라고 권합니다. 스테이지마다 여러 차례 대화가 오가므로 토큰 비용도 일반적인 에이전트 사용보다 큽니다.

헤드리스(headless) 실행이나 CI에서 사람 없이 끝까지 실행하려는 팀에게는 AI-DLC가 적절한 선택지가 아닙니다. 승인 게이트는 사람의 실제 메시지가 있어야 통과하도록 설계되어 있고, Cursor의 헤드리스 agent -p 실행은 승인 게이트를 통과할 수 없다고 명시되어 있습니다.

AI-DLC의 엔진과 컨덕터 구조

AI-DLC는 실행을 2가지 역할로 나눕니다: 하나는 다음에 무엇을 할지 정하는 엔진(engine) 이고, 다른 하나는 그 일을 실제로 수행하는 컨덕터(conductor) 입니다. 엔진은 AI가 아닌 일반 프로그램이어서 같은 상태가 들어가면 항상 같은 다음 단계를 돌려줍니다. 어떤 스테이지를 실행할지, 선택한 프로필이 어떤 스테이지를 빼는지, 언제 게이트에서 멈춰야 하는지를 엔진이 결정합니다. 컨덕터는 /aidlc를 실행한 코딩 에이전트 세션으로, 해당 스테이지에 맞는 에이전트 역할을 맡아 사용자에게 질문하고 산출물을 만든 뒤 결과를 엔진에 보고하고 다음 단계를 다시 묻습니다.

아래는 온보딩 문서에 실린 이 순환을 렌더링한 그림입니다. You(사용자), Conductor (/aidlc), Engine (deterministic) 사이에서 What is next? 질문과 Approve / Request Changes 응답이 반복됩니다:

이 구조에서 에이전트는 경로를 임의로 바꿀 수 없습니다. 프로젝트 문서는 새 사용자가 "왜 그냥 시킨 대로 하지 않는가" 라고 느끼는 순간이 대부분 컨덕터가 알아서 진행하기를 기대할 때 생긴다고 설명합니다. 스테이지가 멈춰 있다면 엔진이 게이트에서 사용자의 답이나 이전 스테이지의 산출물을 기다리는 중입니다. 각 스테이지는 자신이 읽는 산출물(consumes)과 만드는 산출물(produces)을 선언하고, 엔진은 필요한 입력이 없으면 그 스테이지를 실행하지 않습니다.

승인 게이트에서는 사용자가 승인하거나 수정을 요청합니다. 요청한 수정은 컨덕터가 반영해 같은 게이트를 다시 보여주고, 리뷰어 에이전트가 낸 지적 사항에는 고정 ID가 붙어 다음 검토에서 해결 여부를 추적할 수 있습니다. 게이트를 통과하려면 사람의 실제 메시지가 필요하며, 이 조건은 프로필이나 작업별 설정으로 낮출 수 없고 AIDLC_SKIP_HUMAN_PRESENCE_GUARD=1 설정으로만 끌 수 있습니다. 반면 계획 재승인, 리뷰 동결, 상태 전이 검사 같은 보조 가드를 묶은 가드 정책(Guard Policy)은 2.11.0부터 enterprise를 제외한 모든 프로필에서 기본으로 꺼져 있고, 가드가 비켜설 때마다 그 사실을 감사 기록에 남깁니다. 모든 결정은 작업 단위인 인텐트(intent)의 기록 디렉토리 aidlc/spaces/<space>/intents/<YYMMDD>-<label>/ 아래 aidlc-state.md와 audit/ 기록으로 남으며, 감사 이벤트 종류는 119가지로 정의되어 있습니다.

스테이지 대부분은 컨덕터가 에이전트 역할을 맡아 대화 안에서 직접 처리합니다. 33개 중 29개가 이런 인라인(inline) 방식입니다. 나머지 4개 중 실무 관행 탐색(Practices Discovery)과 코드 생성(Code Generation)은 서브에이전트로, 리버스 엔지니어링(Reverse Engineering)은 파이프라인으로 실행됩니다. 사용자 스토리(User Stories)는 여러 에이전트가 함께 참여하는 몹(mob) 방식입니다. 다만 보조 에이전트가 참여하는 협업(collaborators) 설정은 enterprise에서만 기본으로 켜져 있어, 다른 프로필에서는 이 스테이지들도 주 에이전트 혼자 실행하며 /aidlc --collaborators on으로 켤 수 있습니다. 에이전트는 도메인 전문 에이전트 11개, 리뷰어 2개, 맞춤 경로를 제안하는 컴포저(composer) 1개를 합해 14개입니다.

AI-DLC의 5단계 생애주기와 33개 스테이지

AI-DLC의 생애주기는 초기화(Initialization), 아이디어 구상(Ideation), 착수(Inception), 구축(Construction), 운영(Operation)의 5단계로 이루어집니다. AWS 블로그의 원래 방법론은 착수, 구축, 운영의 3단계였고, 2.x는 앞쪽에 작업 공간을 준비하는 초기화와 시장 조사, 타당성 검토, 범위 정의를 다루는 아이디어 구상 단계를 더했습니다. 아래는 단계와 스테이지 문서의 Mermaid 다이어그램을 세로 배치로 렌더링한 그림으로, 단계 사이마다 Verification Gate가 있고 운영 단계의 Feedback Loop가 아이디어 구상으로 돌아갑니다:

초기화의 3개 스테이지는 1초 안에 자동으로 끝나고 승인 게이트가 없습니다. 그 뒤로는 범위에 포함된 모든 스테이지가 승인 게이트로 끝납니다. 구축 단계에서 자동 진행(Continue automatically)을 고르면 일반 완료 체크포인트는 묻지 않고 기록으로 남깁니다. 다만 계획 승인, 검증 명령 선택, 스켈레톤 승인과 실패 상황은 이때도 사람에게 묻습니다.

초기화에서 아이디어 구상으로 넘어갈 때를 제외한 단계 경계마다 검증 게이트(verification gate)가 실행됩니다. 이 게이트는 앞 단계 산출물 사이에 빠진 연결이나 고립된 산출물, 서로 어긋나는 내용이 없는지 자동으로 검사합니다. 착수 단계는 기존 코드 분석, 실무 관행 탐색, 요구사항 분석, 사용자 스토리, 목업 구체화, 도메인 설계, 작업 단위(Unit) 분해, 계약 설계, 전달 계획의 9개 스테이지로 구성됩니다.

구축 단계는 작업 단위마다 기능 설계, 비기능 요구사항(NFR) 정의와 설계, 인프라 설계, 코드 생성을 반복하고, 모든 단위가 끝난 뒤 빌드와 테스트, CI 파이프라인을 한 번 실행합니다. 혼자 진행하는 새 작업은 기본적으로 단위를 하나씩 순서대로 완성하며, 각 단위의 완료는 사람이 승인한 검증 명령의 실행 결과(exit 0)로 확인합니다. 이 검증 명령은 전달 계획 스테이지에서 프로젝트를 살펴 제안하고 사용자가 승인해야 기록되므로, 에이전트가 검증 시점에 다른 명령으로 바꿔 통과시킬 수 없습니다. 워킹 스켈레톤(walking skeleton)을 켜면 첫 단위를 가장 작은 통합 동작 단위로 만들어 실제 종단 간 검사를 통과시킨 뒤에야 나머지 단위로 넘어갑니다.

운영 단계는 배포 파이프라인, 환경 구성, 배포 실행, 관측성(observability) 설정, 장애 대응, 성능 검증, 피드백과 최적화의 7개 스테이지로 이루어집니다. 모두 조건부(CONDITIONAL) 스테이지여서 프로젝트 상황에 따라 실행 여부가 정해집니다.

AI-DLC의 워크플로우 프로필

33개 스테이지를 매번 모두 거치면 작은 작업에는 지나치게 무겁습니다. AI-DLC는 이 문제를 프로필 선택으로 해결합니다. 엔진 내부에서는 스코프(scope)라고 부르는 워크플로우 프로필은 실행할 스테이지 경로와 산출물 깊이, 테스트 전략을 함께 정하며, 11개가 기본 제공됩니다:

프로필	용도	스테이지	깊이
`classic`	1.x와 같은 방식으로 착수와 구축을 거쳐 빌드와 테스트까지 (기본값)	18 / 33	Standard
`express`	요구사항이 이미 분명할 때 가장 짧은 구현과 테스트 경로	10 / 33	Minimal
`feature`	운영 환경에 들어갈 기능을 전체 생애주기로 개발	33 / 33	Standard
`enterprise`	규제 대상이거나 완전한 추적성이 필요한 작업	33 / 33	Comprehensive
`mvp`	운영 단계를 제외한 첫 제품 출시분	23 / 33	Standard
`poc`	접근 방식이 가능한지 확인하는 개념 증명	8 / 33	Minimal
`bugfix`	원인을 아는 결함의 수정과 회귀 테스트	9 / 33	Minimal
`refactor`	동작을 바꾸지 않는 내부 구조 개선	10 / 33	Minimal
`infra`	인프라 코드(IaC), 배포 기반, 비용 최적화	13 / 33	Standard
`security-patch`	CVE(Common Vulnerabilities and Exposures) 대응 같은 좁은 범위의 보안 수정	10 / 33	Minimal
`workshop`	진행자가 이끄는 교육이나 그룹 실습	26 / 33	Standard

프로필 이름을 몰라도 /aidlc Fix the login timeout bug처럼 작업을 설명하면 AI-DLC가 맞는 프로필을 제안하고, 스테이지와 게이트 수를 보여준 뒤 확인을 받습니다. 기존 프로필에 맞지 않는 작업에는 컴포저가 맞춤 스테이지 경로를 제안하며, 이 경로도 승인을 받은 뒤에 만들어집니다. 문서는 처음 쓰는 팀에게 5단계 연습 순서를 권합니다. 15분짜리 express 실행으로 순환 구조를 익히고, 같은 아이디어를 poc로 다시 실행해 경로가 바뀌는 것을 봅니다. 이어서 게이트에서 수정을 요청해 보고 기록 디렉토리를 살펴본 뒤, 마지막으로 실제 코드에서 feature를 실행합니다.

AI-DLC의 하네스별 동작 차이

AI-DLC는 모든 하네스에서 같은 엔진을 실행하지만, 각 도구가 훅에 허용하는 권한이 달라서 흐름을 강제하는 강도도 다릅니다. 진행자 가이드는 약한 하네스일수록 워크플로우가 에이전트의 지시 준수에 더 의존하고, 실패를 놓치기 쉽다고 밝히고 있습니다. 하네스별 차이를 정리하면 다음과 같습니다:

하네스	에이전트 행동 거부	턴 종료 시 동작	알아 둘 점
Claude Code	모든 검사에서 가능	단계 보고까지 진행을 유지	문서상 별도 공백 없음
Codex CLI	모든 검사에서 가능	진행을 유지	프로젝트 훅을 신뢰(trust)로 등록해야 훅이 실행됨, Git 저장소 필요
GitHub Copilot	가능 (VS Code는 문서상 지원이나 실측 검증 전)	진행을 유지	선택 상자 응답을 받지 않으므로 답을 직접 입력, VS Code는 워크스페이스 신뢰와 Chat: Use Hooks 설정 필요, 상태 표시줄 없음
Cursor	가능	턴을 붙잡지 못해 후속 메시지로 알림	Git 저장소와 폴더 신뢰 필요, 헤드리스 `agent -p`는 승인 게이트 통과 불가
Kiro CLI	가능	대화형 세션에서만 진행을 유지	`aidlc` 에이전트 활성화 필요, 세션 종료와 컨텍스트 압축 전 훅 없음
Kiro IDE	일부 검사만 가능 (리뷰어 읽기 범위 검사 없음)	턴을 붙잡지 못함	폴더 신뢰, 창 새로고침, `aidlc` 에이전트 선택 필요
opencode	가능	턴을 붙잡지 못해 새 프롬프트로 알림	AI-DLC 플러그인 설치 필요, 세션 종료 이벤트 없음

도구를 고를 수 있는 상황이라면 Claude Code와 Codex CLI가 문서상 가장 적은 공백으로 동작합니다. 모델 제공자 설정은 각 하네스가 맡으며, aidlc config providers로 Amazon Bedrock 설정을 적용할 수 있지만 방법론 자체는 특정 제공자에 묶여 있지 않습니다.

AI-DLC 설치와 사용

macOS, Linux, WSL에서는 설치 스크립트 한 줄로 aidlc 실행 파일과 모든 하네스 런타임을 설치합니다. Bun이나 Node.js를 따로 설치할 필요가 없고, 기본 설치 위치는 ~/.local/bin입니다:

curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.sh | sh

설치 스크립트는 릴리스의 SHA-256 체크섬을 검증하고, GitHub CLI(gh)가 있으면 릴리스 증명(attestation)도 확인합니다. 파이프로 바로 실행하는 대신 스크립트를 먼저 내려받아 읽어 보고 싶다면 하네스 가이드가 안내하는 다음 순서를 따릅니다:

tmp="$(mktemp -d)"
curl -fsSL \
  https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.sh \
  -o "$tmp/install.sh"
sh "$tmp/install.sh"
rm -rf "$tmp"

Windows PowerShell에서는 일반 PowerShell 창에서 다음 명령을 실행합니다. "관리자 권한으로 실행"한 창에서는 덜 안전하다는 경고와 함께 계속할지 묻습니다:

irm https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.ps1 | iex

설치가 끝나면 프로젝트 루트에서 사용할 하네스를 지정하고 상태를 점검합니다. claude 자리에는 kiro, kiro-ide, codex, cursor, opencode, copilot을 넣을 수 있습니다:

cd /path/to/your-project
aidlc config --harness claude
aidlc doctor

이제 하네스를 열고 작업을 설명합니다. Codex CLI에서는 /aidlc 대신 $aidlc를 씁니다:

/aidlc Build a REST API for inventory management

AI-DLC는 요청에 맞는 워크플로우를 고르고, 부족한 결정 사항을 질문한 뒤, 승인 게이트마다 멈춥니다. 멈춘 이유를 모르겠으면 aidlc doctor를 먼저 실행하고, 현재 위치는 /aidlc --status로 확인합니다. 새 버전으로 올릴 때는 aidlc update 후 프로젝트마다 aidlc config --yes로 런타임을 갱신합니다. 안정 버전은 2026년 9월 1일 2.7.0부터 10월 8일 2.11.0까지 7개가 나왔고, 기본값이 바뀌는 경우도 있으므로 업데이트 전에 변경 이력을 확인하는 것이 좋습니다. 프로젝트 로드맵은 2026년 9월 11일 기준으로 7개 목표 중 단계 간 순환 흐름과 산출물 추적성은 아직 부분 구현(Partial)으로 표시하고 있습니다.

AI-DLC의 라이선스

AI-DLC 문서 사이트

AWS 블로그의 AI-DLC 방법론 소개 글

AI-DLC Workflows 2.0 명세 (PDF)

AI-DLC 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

이 글은 파이토치 한국 사용자 모임이 직접 정리한 글입니다. 새 글을 놓치지 않으시려면 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 알림을 받으시고, 회원으로 가입하시면 주요 글들을 이메일로도 보내드립니다!

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~

aicost_tools · 10월 17, 2026, 9:22오전

aicost.tools에서 모델 가격을 정리하는 입장에서는 poc(8개 스테이지)부터 enterprise(33개 스테이지)까지 프로필을 고를 수 있다는 점이 제일 반갑습니다. 스테이지마다 에이전트가 요구사항과 이전 산출물을 다시 읽으니, 권장 모델인 Opus급으로 33개를 다 돌리면 비용이 작업 크기보다 스테이지 수에 더 크게 좌우될 것 같거든요. 혹시 스테이지별로 다른 모델(예: 문서 정리는 작은 모델)을 지정하는 설정도 있는지 아시나요?