에이전트 팀을 늦게 만든 것 — 화면이 아니라 동사부터
처음엔 AI 한 명에게 “이 모듈 다 만들어줘”라고 통째로 던졌습니다. 한참 뒤에야 알았습니다. 모듈 하나를 제대로 설계하려면 역할이 다른 여러 에이전트가 정해진 순서로 일해야 하고, 그 순서의 출발점은 화면(명사)이 아니라 **동사(verb)**여야 한다는 것을요. 이 글은 “왜 한 명에게 다 시키면 안 되는지”, “파이프라인이 어떤 순서로 흐르는지”, 그리고 “왜 하필 동사가 맨 앞이어야 하는지”를 차근차근 풀어 쓴 기록입니다.
한 명에게 다 시키면 안 된다
섹션 제목: “한 명에게 다 시키면 안 된다”사람 회사에서 ERP 모듈 하나를 만든다고 해보겠습니다. 기획자가 업무를 분석하고, DB 설계자가 테이블을 잡고, 아키텍트가 API를 정하고, 개발자가 코드를 짜고, QA가 검증합니다. 역할이 또렷하게 나뉩니다. 각 역할이 앞 사람의 결과물을 받아 다듬습니다. 그런데 저는 초기에 AI 한 세션에게 이 전부를 한꺼번에 시켰습니다. 결과는 “그럴듯하지만 어딘가 헐거운” 설계였습니다. 업무 흐름을 충분히 파헤치기도 전에 코드부터 튀어나왔습니다.
왜 한 명에게 다 시키면 헐거워질까요? AI 세션 하나의 주의(attention)는 한정돼 있기 때문입니다. 한 세션에 “업무 분석 + DB 설계 + API 설계 + 구현 + 테스트”를 다 욱여넣으면, 각 단계에 쏟을 집중이 얕아집니다. 특히 가장 중요한 맨 앞 단계 — 업무를 깊이 이해하는 일 — 이 흐지부지된 채로 코드 생산으로 떠밀립니다. 그래서 역할을 쪼갠 에이전트 팀을 만들었습니다. 탐색·계획·테스트 담당을 분리한 게 5월 초, 모듈 설계 전용 에이전트들을 순서대로 엮은 파이프라인을 정립한 게 5월 중하순이었습니다. 이걸 처음부터 했어야 했습니다.
파이프라인의 순서 — 한눈에 보기
섹션 제목: “파이프라인의 순서 — 한눈에 보기”신규 ERP 모듈은 강제된 순서를 탑니다. 각 단계는 전담 에이전트가 맡고, 앞 단계 산출물이 검증을 통과해야만 다음으로 넘어갑니다. 한 단계라도 부실하면 거기서 멈춥니다.
| 순서 | 단계 | 하는 일 | 비유 |
|---|---|---|---|
| 1 | catalog | 이 모듈의 “완전한 모습” 표준을 정의 (북극성) | 완성 사진 |
| 2 | scan → scope | 지금 코드 현황 조사 → 갭과 모드(신규/확장/감사) 결정 | 현재 위치 측정 |
| 3 | mcp | 동사(verb) 추출 + Tool 시그니처 정의 | 업무 동작 목록 |
| 4 | domain | 업무 프로세스·불변식·상태 머신 정의 | 규칙서 |
| 5 | erd | 데이터 모델·테이블·제약 설계 | 골격 |
| 6 | arch | API 계약·권한 모델·이벤트·트랜잭션 경계 | 배관도 |
| 7 | plan → check | 실행 계획 → 체크리스트로 완료 판정 | 작업 지시서 |
가장 중요한 단계 — 동사(verb) 추출
섹션 제목: “가장 중요한 단계 — 동사(verb) 추출”표에서 3번 mcp 단계가 이 파이프라인의 심장입니다. 보통 ERP 설계는 “어떤 화면이 필요한가”부터 시작합니다. 입력 폼, 목록 테이블, 메뉴 구조 — 전부 명사입니다. 우리는 정반대로 했습니다. 명사를 묻기 전에 동사를 먼저 물었습니다.
왜 동사가 먼저여야 하나
섹션 제목: “왜 동사가 먼저여야 하나”이유는 한 문장입니다. 우리가 만들려는 건 “AI 에이전트가 운영하는 ERP”이기 때문입니다. 사람이 화면을 열어 일일이 입력하는 구시대 ERP를 그대로 재현하려는 게 아닙니다. 에이전트가 업무를 처리하고, 사람은 그 결과를 승인·반려만 합니다. 그러려면 에이전트가 “호출할 수 있는 업무 동작”이 설계의 1급 시민이어야 합니다.
| 명사부터 (구시대 ERP) | 동사부터 (AI 네이티브 ERP) |
|---|---|
| “입력 폼 → 목록 → 상세” 화면을 먼저 그린다. 설계의 중심에 사람의 입력 행위가 박힌다. 에이전트는 나중에 이 화면을 흉내 내야 하는 처지가 된다 — 만들려던 것과 정반대. | ”신청한다·승인한다·차감한다” 동작을 먼저 정의한다. 에이전트가 이 동작을 직접 호출한다. 화면은 그 결과를 사람이 확인·승인하는 얇은 뷰로 맨 끝에 붙는다. |
화면부터 그리면 사람의 입력 행위가 설계의 중심에 박혀버립니다. 그 위에 나중에 “AI 자동화”를 얹으려 하면, 이미 사람 중심으로 굳은 구조와 충돌합니다. 반대로 동사부터 시작하면 “사람이 하든 에이전트가 하든 같은 동작”이라는 추상이 자연스럽게 생깁니다. 이게 동사-우선이 단순한 취향이 아니라 목표에서 도출된 필연인 이유입니다.
늦게 잡은 대가 — retrofit
섹션 제목: “늦게 잡은 대가 — retrofit”이 순서를 늦게 깨달은 대가는 분명했습니다. 파이프라인을 정립하기 전에 이미 만든 몇몇 모듈은 명사형으로 짜여 있었습니다 — 화면과 CRUD 중심이고, 에이전트가 부를 동사 레이어가 없었습니다. 이걸 버리고 새로 짤 수는 없으니, 기존 코드는 그대로 두고 그 위에 동사 레이어를 덧입히는 별도 작업(retrofit)이 필요했습니다.
- 기존 모듈 식별 — 화면·CRUD만 있고 동사가 없는 모듈을 골랐습니다.
- 코드 미수정 원칙 — 기존 컨트롤러·서비스는 건드리지 않습니다(회귀 위험 차단).
- 동사 래퍼 추가 — “신청한다·승인한다” 같은 동사형 진입점을 별도 레이어로 새로 얹습니다.
- Tool 등록 — 그 동사들을 에이전트가 호출할 수 있는 도구로 등록합니다.
이 retrofit은 “처음부터 동사로 시작했다면 안 해도 됐을 일”이었습니다. 순서 하나를 늦게 잡은 비용이, 다 만든 모듈을 다시 들여다보는 추가 작업으로 돌아온 것입니다.
왜 “분리된 팀”이 “한 명의 천재”를 이기나
섹션 제목: “왜 “분리된 팀”이 “한 명의 천재”를 이기나”“좋은 모델 하나면 충분하지, 굳이 단계를 나눠야 하나?”라는 의문이 들 수 있습니다. 답은 모델의 똑똑함이 아니라 구조에 있습니다. 단계를 나누면 세 가지가 생깁니다.
| 분리가 만드는 것 | 한 명에게 다 시킬 때 |
|---|---|
| 집중 — 각 에이전트가 한 단계에만 주의를 쏟음 | 한 세션이 모든 단계를 얕게 처리 |
| 검증 지점 — 단계마다 산출물을 검사하고 통과해야 다음으로 | 중간 점검 없이 코드까지 직행 |
| 흔적(문서) — 각 단계가 문서를 남겨 다음 세션이 이어받음 | 맥락이 대화창에만 남아 세션 끝나면 소실 |
특히 두 번째 — 단계 사이의 검증 지점 — 이 품질을 만듭니다. 동사 추출이 부실하면 데이터 모델로 못 넘어가고, 데이터 모델이 헐거우면 API 설계로 못 넘어갑니다. 한 명이 다 하면 이 “멈춤 지점”이 없어서, 첫 단계의 결함이 그대로 코드까지 흘러내립니다. 그리고 세 번째 — 각 단계가 문서를 남기는 것 — 은 세션이 바뀌면 다 잊는 AI에게 결정적입니다. 설계 산출물이 곧 다음 단계 에이전트(다른 세션)의 입력이 되니까, 망각이 일어나도 작업이 끊기지 않습니다.
이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에, 이 팀과 게이트를 떠받치는 규칙 기반은 〈하네스〉에, 세션이 바뀌어도 설계가 살아남게 하는 문서화는 〈AI는 세션이 바뀌면 다 잊는다〉에 있습니다.