AI 구동 개발(AIDD) — 개발 프로세스의 주체를 AI로 삼는 흐름이 정착되어 왔습니다. 그 다음으로 이야기되기 시작한 것이 바로 'AI 구동 기업'입니다. 같은 원리를 개발뿐만 아니라 사업 운영 전체와 경영에 확장하는 것입니다. 영업, 경리, 기획, 의사 결정까지 AI 에이전트가 주도하고, 인간은 판단, 윤리, 관계성에 집중하는 — 그런 형태의 회사입니다.
그림으로는 이해할 수 있습니다. 그렇다면, 이를 실제로 구현하려면 무엇을 사용해야 할까요? 이 글에서는 AI 구동 기업의 청사진을 Devin의 기능에 하나씩 대입해 보면서 구현 수준까지 내려가 봅니다. 부서는 어떤 기능에, 품의는 어떤 설정에, 업무 매뉴얼은 어느 상자에 —와 같이 회사의 요소를 Devin 공식 문서를 기능 이름까지 번역하는 작업입니다.
먼저 솔직하게 말씀드립니다. 이것은 실제로 구동한 기록이 아니라, 공식 문서를 읽으면서 구상을 기능 이름으로 번역한 설계 매핑입니다. 말할 수 있는 것은 '문서상으로는 논리적이다'까지만 가능하며, '실제로 구축 가능하다'고 단언하기 위해서는 이 이후에 실제 실행(실주)이 필요합니다.
먼저 3줄로 요약하면 다음과 같습니다:
- AI 구동 기업이란 사업 운영의 '주체'가 사람에서 AI 에이전트로 바뀐 기업. AI로 효율화하는 것이 아니라, AI가 움직이는 것을 전제로 재설계하는 것.
- 회사의 구성 요소는 Devin의 기능 이름까지 깔끔하게 내려옵니다. 업무 매뉴얼은 Playbooks에, 교육/인수인계는 Knowledge에, 오케스트레이션은 Dynamic Workflows에 대응합니다.
- 성공 전략은 '프롬프트가 뛰어난 인재'가 아니라 '업무를 에이전트 단위로 분해할 수 있는 조직'. 상자(도구)는 갖추어져 있고 부족한 것은 설계입니다.
| 용어 | 대략적인 의미 | |
|---|
| AIDD | AI-Driven Development. 개발 프로세스의 주체를 AI로 삼음 | |
| ... | | |
| 정의는 간단합니다. 사업 운영의 주체가 '사람'에서 'AI 에이전트'로 바뀐 기업입니다. 수주, 채용, 출하, 청구에 이르는 실행을 AI 에이전트가 담당하고, 인간은 판단, 윤리, 관계성에 집중합니다. 회사 형태가 '사람이 운영하는 회사'에서 'AI가 방향을 결정하는 회사'로 변한다는 정리입니다. | | |
여기서 효과적인 것이 '주체(主語)'라는 표현입니다. AI를 도입했는지 여부가 아니라, 업무를 한 문장으로 썼을 때 주체가 어느 쪽이 되는지 — '담당자가 청구서를 만든다'인지 '에이전트가 청구서를 만든다'인지. 이렇게 하면 자신의 직장에 그대로 대입하여 판별할 수 있습니다.
'빠른 마차'를 발명하는 것이 아니라 '자동차'를 발명한다는 비유가 자주 사용됩니다. 기존 프로세스에 AI를 추가하는 것(Retrofit)인지, AI가 움직이는 것을 전제로 다시 만드는 것(Reimagine)인지를 구분하는 것입니다. AI를 '도구'로 보는 것이 아니라 '동력원'으로 두는가 하는 구별입니다.
이 시각을 파고들면, 회사의 구성 요소는 에이전트/사업 규칙/API에 매핑될 수 있다라는 발상에 이르게 됩니다. 부서는 전문화된 에이전트에, 품의는 승인 게이트에, 업무 매뉴얼은 절차서에 대응하는 식입니다. 조직도를 '에이전트 구성도'로 그릴 수 있느냐 하는 것입니다.
그 매핑 대상을 Devin의 실제 기능으로 채워 넣으면 다음과 같습니다.
| 회사의 요소 | 대응 개념 | Devin에서의 구현 |
|---|
| 부서/직책 | 도메인 전문가 에이전트 (Domain Expert Agent) | Dynamic Workflows의 하위 Devin / CLI 서브 에이전트 |
| ... | Playbooks + Skills | |
| 교육/인수인계 | 지식 설계 (Memory/자동 지식화) | Knowledge (repo 등에서 자동 생성 및 후술) |
| 감사/인사 평가 | 로그 감사/평가 기준 | Enterprise API의 감사 로그 + RBAC・SSO |
흥미로운 점은, Devin의 기능 이름 자체가 원래 '회사의 어휘'에 맞춰져 있다는 것입니다. '업무 매뉴얼'에는 처음부터 **Playbook(반복하는 작업의 절차서)**이라는 이름의 상자가 있고, '교육/인수인계'에는 **Knowledge(새로운 사원에게 온보딩하듯이 조직의 맥락을 전달)**라는 상자가 있습니다. 매핑표의 좌우가 언어적으로 거의 일치합니다.
먼저 두 가지 행에 대해 짚고 넘어가겠습니다(품의/교육은 나중에 각 절에서 깊이 다루겠습니다).
업무 매뉴얼(業務マニュアル) → 플레이북(Playbooks). Devin의 Playbook은 공식적으로 **'반복적인 작업을 위한 커스텀 시스템 프롬프트(a custom system prompt for a repeated task)'**로 정의됩니다. 웹 애플리케이션 상에서 생성하며, **절차(Procedure)/명세(Specifications)/조언(Advice)/금지 행동(Forbidden Actions)/사용자 필요 입력(Required from User)**과 같은 섹션을 가질 수 있습니다. '절차・완료 조건・금지 사항・필요한 입력'의 순서는 잘 만들어진 업무 매뉴얼의 목차 그 자체입니다. !task-name와 같은 매크로를 통해 호출할 수 있으며, 조직 전반에 걸쳐 공유도 가능합니다.
부서/직책 → 다이나믹 워크플로우(Dynamic Workflows)의 하위 Devin. 여러 전문 특화 에이전트가 협력하는 구성은 Dynamic Workflows—공식적으로는 'Devin 에이전트 팀을 오케스트레이션하는 결정론적 Python 스크립트'—가 담당합니다. 하나의 조정 세션이 기본적으로 별도의 VM에서 실행되는 독립적인 하위 Devin 여러 개를 구동하여, 병렬 및 파이프라인 방식으로 처리를 연결합니다. 작게 분업만 할 것이라면 Devin CLI의 **서브 에이전트(sub-agent)**도 사용할 수 있습니다.
감사/인사 평가 → 엔터프라이즈 API(Enterprise API). 모든 액션의 추적은 Enterprise API(api.devin.ai/v3/enterprise/*)가 감사 로그, 분석, 사용자 관리를 전반적으로 처리합니다. 아울러 커스텀 역할 및 RBAC(Custom Roles & RBAC), SSO(Okta / Microsoft Entra ID / SAML / OIDC), IdP 그룹으로부터의 역할 자동 할당이 갖춰져 있어, 권한 경계를 처음부터 배선에組み込む 수 있습니다.
기존 기업과 AI 구동 기업을 나란히 놓고 비교하면 변화가 명확합니다.
| 관점 | 기존 기업 | AI 구동 기업 (Devin) |
|---|
| 실행의 주체 | 사람 | AI 에이전트 (Devin) |
| ... | | |
| 개인적으로 눈에 띄는 것은 성장의 상한선 항목입니다. 인원수에서 컴퓨팅량으로 변화한다는 것은, 채용 계획이 곧 예산 계획이 된다는 의미입니다. Devin의 경우 '몇 명을 고용할 것인가'가 아니라 '어떤 세션을 병렬로 돌리고 ACU를 얼마나 사용할 것인가'입니다. 경영 의사결정의 형태 자체가 바뀝니다. | | |
그리고 가장 큰 차이는 한마디로 **'개선 루프의 속도'**라고 생각합니다. 월별분기별 개선이 분 단위시간 단위로 돌아갑니다. 여기가 핵심입니다.
AI 구동 기업의 골격은 'AIDD를 통해 실증한 수단과 시스템을 기업 운영에 적용하는 것'입니다.
AIDD (AI-Driven Development): 개발 프로세스의 주체를 AI로 삼는 것입니다. 코드 생성・테스트・리뷰를 AI가 구동하며, 소수 인원 × 초고속 개발을 실증합니다. -
AIDM (AI-Driven Management): 같은 원리를 사업 운영 전체와 경영에 확장하는 것입니다. 영업・경리・기획・의사결정까지 AI가 구동하고, 인간은 판단・윤리・관계성에 집중합니다.
Devin은 이 '개발에서의 실증'을 담당하는 에이전트입니다. 코드를 작성하고 테스트하며 PR을 내는 과정을 자율적으로 처리합니다. 그 실행 엔진을 개발 → 사업 → 경영으로 확장해 나가는 순서입니다. 개발에서의 성과가 먼저 있기 때문에, 경영에 적용한다는 이야기가 현실적 기반을 갖습니다.
'AI로 움직이는 회사 만들기'라고 하면 거대한 내부 구축(내재화)이 필요할 것 같지만, 필요한 요소들을 모아 Devin에게 할당하면 도구는 대체로 갖춰져 있습니다.
| 필요한 요소 | Devin에서의 담당 |
|---|
| 업무 실행 (에이전트 본체) | Devin (CLI / 클라우드 세션) |
| ... | Knowledge (→ Skills / Plugins로 전환 중) |
| 워크플로우 (오케스트레이션) | Dynamic Workflows |
| 시작/트리거 | Automations (schedule / Slack・GitHub・Linear・webhook) |
| 추적 가능성 (Traceability) | 세션 기록 + Enterprise API의 감사 로그 |
| 비용 최적화 | Usage Policies (ACU 상한) + 이용 현황 분석 |
실행도, 절차서도, 지식도, 엮는 시스템도, 시작점도, 감사(Audit)도, 비용의 상한선도 이름 붙은 기능으로 존재합니다. 그래서 부족한 것은 도구가 아니라, 업무를 에이전트에게 맡기는 설계입니다.
그렇다고 해도, 도면까지 내려보면 '이름 붙은 기능에 그대로 들어맞는 부분'과 '직접 설계가 필요한 부분'이 보입니다. 특히 효과적인 것이 다음 3가지입니다.
'이벤트가 오면 에이전트를 작동시킨다'라는 진입점은 자동화의 핵심입니다. 이 부분을 직접 만들 필요가 없었던 것이 Devin의 강점이었습니다. Automations는 **스케줄(cron)**과 이벤트(Slack / GitHub / Linear / webhook) 두 가지 트리거를 모두 가지고 있으며, 조건이나 호출 횟수의 상한선도 설정할 수 있습니다. 에이전트 내부(부모-자식 분업/승인/안전 실행)만 설계하면, 시작 계기는 배선하기만 하면 됩니다.
'부서/직책'을 에이전트 팀에 옮겨 놓았을 때, 누구에게 어떤 순서로 무엇을 맡길지는 직접 결정하는 부분입니다. Devin의 Dynamic Workflows는 이를 결정론적인 Python 스크립트로 작성합니다. 병렬 처리도 파이프라인도 코드로 제어할 수 있으며, JSON 스키마로 단계를 연결하고 각 호출 기록이 남아 재개도 가능합니다. 즉, 절차적으로 오케스트레이션(Orchestration)을 장악하는 느낌입니다.
이벤트 기반으로 저절로 움직이는 자동화를 실제 환경에 배치하려면, 처음부터 비용의 상한선을 설계에 포함해야 합니다. Devin은 Usage Policies를 통해 멤버 단위/조직 단위로 월별 ACU 상한선을 설정합니다. **어느 쪽이든 상한선에 도달하면 세션이 차단(block)**되고, 사용자는 'Request more' 버튼을 통해 추가 할당량을 요청할 수 있습니다 (추가 할당량은 해당 청구 주기 한정의 임시적인 것입니다). 이 상한선은 Desktop, CLI, 클라우드 모든 영역에 적용됩니다. 참고로, 이 per-user ACU 상한선은 베타(Beta) 기능이며 엔터프라이즈 환경에서 활성화해야 합니다.
AI 구동 기업에서는 지식 설계의 중심이 이동합니다. 이전에는 AI에게 줄 지식을 사전에 축적하는 방식(RAG)으로, 지식의 신선도와 포괄성은 '사람이 사전에 준비할 수 있는 분'이 한계였습니다. AI 구동 기업에서는, AI가 업무를 수행함으로써 지식이 축적됩니다. 실행 로그나 수정 기록이 그대로 지식원이 되며, 사용할수록 조직의 지식이 늘어나는—암묵지가 업무를 돌리는 것만으로 형식지화되는 상태를 목표로 합니다.
Devin에서 이 역할을 담당하는 것이 Knowledge입니다. 공식적으로는 '새로운 직원에게 조직의 맥락을 온보딩(onboarding)하는 것'처럼 설명되며, 코드 규약/배포 절차/PR 명명법/테스트 절차 등을 세션 간에 참조하게 합니다. 효과적인 것은 자동 생성 기능으로, 리포지토리에 접근 권한을 주면 README나 파일 구조로부터 지식을 자동으로 만들고, CLAUDE.md
/ AGENTS.md
/ .cursorrules
와 같은 기존 규칙 파일도 가져옵니다. 검색은 트리거(trigger) 기반이며, 어떤 세션에서 어떤 지식이 사용되었는지는 'Accessed Knowledge'로 표시됩니다.
'가져오는 입구(기존 규칙 파일)'와 '시각화(Accessed Knowledge)'가 처음부터 갖춰진 것이 이 방향과 잘 맞는 부분입니다.
⚠️ 하나 정확히 적자면, 공식 문서상 Knowledge는 Skills (Plugins)로 이전되는 처리 과정을 거치고 있습니다. 지금부터 설계한다면 Skills도 함께 살펴보는 것이 안전합니다. 본 기사에서는 매핑의 이해하기 쉬움을 우선하여 Knowledge라는 용어로 설명하고 있습니다.
결재 과정에 비유되는 HITL 게이트(Human-in-the-Loop)는 실무에서 '모든 것에 사람을 개입시키기/모두 자동화'의 이분법적 선택이 아니라, 위험도에 따라 관여 깊이를 설계하는 것이 요령입니다. 일반적인 정리는 3단계입니다.
| 위험 | 관여 모델 | 예 |
|---|
| 높음 | Human-in-the-Loop (실행 전 사람 승인) | 고객에게 전송, 프로덕션 배포, 계약/결제 |
| ... | | |
| 이를 Devin의 권한 시스템에 적용하면 자연스럽게 대응합니다. Devin CLI는 단계적인 권한 모드를 가지고, | | |
| 모드 | 동작 방식 (대략) |
|---|
| Normal (기본값) | 읽기는 자동 승인, 쓰기/셸은 그때그때 승인 필요 |
| ... | |
더 나아가 allow / ask / deny 규칙으로 세밀하게 나누고, deny가 항상 최우선입니다 (아무리 구체적인 allow라도 deny를 덮어쓸 수 없습니다). 조직 레벨의 deny / ask는 프로젝트/사용자 설정에서 덮어쓸 수 없습니다. 고위험은 deny | |
/ask | |
로 막고, 저위험은 allow | |
| 로 통과시키는 — 이 세밀한 단계가 그대로 표현될 수 있습니다. | |
- 고위험 → 위험 작업에
deny
/ask
. Normal 모드에서 그때그때 승인 필요 - 중위험 → Autonomous + sandbox에서 실행하고, 로그로 감시
- 저위험 →
allow
로 자동 통과. Bypass에 가까움
(Smart 모드는 단계적으로 제공되고 있어, 환경에 따라 아직 선택지에 나타나지 않을 수 있습니다. 또한, 이 세 가지 단계에 대한 할당은 제가 해석한 것이므로, 공식적으로 이 세 단계를 정의한 것은 아닙니다.)
적용을 마치고 가장 강하게 남은 것은 도구 이야기가 아니었습니다.
성공하는 조직에게 공통적으로 보이는 요인은 '프롬프트가 능숙한 인재'가 아니라,
업무를 에이전트 단위로 분해할 수 있는 조직에 있습니다.
Devin은 충분한 '상자(箱)'를 마련해 줍니다. 업무 실행도, 절차서(Playbook)도, 지식(Knowledge)도, 시작점(Automations)도, 승인 경계(권한 규칙)도, 거버넌스(Enterprise API)도 말입니다. 하지만 상자의 내용은 조직이 직접 작성할 수밖에 없습니다. Playbook에 무엇을 쓸지, Knowledge에 무엇을 저장할지, 어떤 이벤트로 누구를 작동시키고 어디서 사람을 개입시킬지, 부모-자식의 분업을 어떻게 나눌지 — 이것들은 전부 도구가 정해줄 수 없는 업무 설계입니다.
성공하는 조직에게 공통적으로 보이는 요인을 꼽는다면, 경영진의 관여・업무 설계의 해상도・거버넌스 선행 세 가지입니다. 특히 거버넌스 선행 — 규모화 이전에 권한 경계・감사 로그・감시 체계를 갖추는 것 — 은 Devin이라면 권한 규칙과 Enterprise API로 첫 배선에 통합할 수 있습니다.
AI 구동 기업의 핵심을 5가지로 정리하면 다음과 같습니다.
- AI를 통한 효율화가 아니라,
AI로 움직이는 기업 만들기 - 업무 프로세스 전체를
AI 에이전트가 실행하는 형태로 전환하기 -
사용할수록 똑똑해지기 위한 지식 축적(Knowledge) - 사람의 역할은,
판단・윤리・관계성 및 업무 설계 - 지금 있는 조직은,
AI 에이전트 도입과 지식 설계부터 시작
그리고 마지막으로, 경영의 질문 자체가 재작성됩니다.
'몇 명을 고용해야 돌아갈까?'에서 '어떤 태스크를 AI에 맡기고, 사람은 어디에 집중할까?'로.
앞서 비교표에 있던 '성장 상한선이 인원수에서 컴퓨트량으로'가 경영의 질문 형태로 다시 표현된 것입니다. Devin으로 말하자면, '채용 규모'가 아니라 'Playbook의 장 수', '병렬 세션 수', 'ACU 예산'으로 사업 성장을 설계한다는 의미입니다.
'AI 구동 기업'이라는 큰 그림을 Devin의 기능 이름까지 하나하나 내려보았습니다. 알게 된 것은, 매핑표의 좌우가 생각보다 곧게 연결된다는 것입니다. 업무 매뉴얼은 Playbooks, 교육은 Knowledge, 부서는 Dynamic Workflows의 자식 Devin, 품의(稟議)는 권한 규칙, 거버넌스는 Enterprise API입니다. 기능 이름들이 원래 회사 용어에 맞춰져 있기 때문에, Devin은 이 그림을 그리기 쉬운 쪽이라고 느꼈습니다.
동시에, **도면에 그려봐야 비로소 보이는 '스스로 작성해야 하는 부분'**도 있었습니다. 시작점(起動の入口)은 Automations으로 채워지는 한편, 부모-자식의 협조는 코드로 묶고, 비용 상한선은 천장처럼 설계합니다. '갖춰진 것은 상자이고, 부족한 것은 설계'라는 것이 적용을 마치고 느낀 점입니다.
여기서 솔직히 말씀드리자면, 제가 한 것은 도면을 그리는 것까지였고, 아직 실제로 작동시켜 본 적이 없습니다. 그래서 '구축할 수 있다'고 단언하기는 어려우며, 말할 수 있는 것은 '공식 문서상으로는 모순이 없었다'까지만입니다. 설계도와 도면 다음은 실주행(實走)이 필요합니다.
다음에는 — 이번이야말로 — 어느 한 줄을 실제로 작동시켜 보겠습니다. Automations으로 작은 이벤트를 하나 받고, Playbook 한 장을 가진 Devin을 작동시키는 것부터 말입니다.
- 플레이북 생성 (Playbooks) (Devin Docs)
- 지식 온보딩 (Knowledge Onboarding) (Devin Docs)
- 동적 워크플로우 (Dynamic Workflows) (Devin Docs)
- 예약 세션/자동화 (Scheduled Sessions / Automations) (Devin Docs)
- CLI 권한 (CLI Permissions) (Devin Docs)
- CLI 서브 에이전트 (CLI Subagents) (Devin Docs)
- 사용 정책 (Usage Policies) (Devin Docs)
- 사용 추적 (Usage Tracking) (Devin Docs)
- 엔터프라이즈 시작하기 (Enterprise Getting Started) (Devin Docs)
- SSO 온보딩 가이드 (SSO Onboarding Guide) (Devin Docs)
- API 개요 (API Overview) (Devin Docs)
