동사부터 묻기 — 명사·화면은 맨 마지막

“○○관리 화면을 만들어줘”는 구시대 ERP의 질문이었습니다. 에이전트가 일하는 시스템을 만들려면 질문 자체를 바꿔야 했습니다 — “이 업무에서 1년 동안 일어나는 의사결정 사건을 동사(verb)로 뽑아줘.” 이 한 줄의 차이가 설계의 시작점을 통째로 옮깁니다. 이 글은 그 출발점이 왜 그렇게까지 중요한지의 기록입니다.

명사형 설계와 동사형 설계

이 글은 단 하나의 대비를 다룹니다. 명사부터 설계하느냐, 동사부터 설계하느냐입니다. 말장난 같지만 이 선택이 시스템 전체의 운명을 가릅니다. 먼저 두 단어를 정확히 정의하겠습니다.

용어: 명사형 설계

“무엇이 있는가”에서 출발합니다. 사원·품목·결재 문서 같은 *대상(명사)*을 먼저 정하고, 그 대상을 보여주고 입력하는 화면(Form)과 저장하는 표(Table)를 만듭니다. 전통 ERP는 거의 전부 이 방식입니다.

용어: 동사형 설계

“무슨 일이 일어나는가”에서 출발합니다. 입사시킨다·연차를 승인한다·재고를 확인한다 같은 *행위(동사)*를 먼저 뽑고, 그 행위 하나하나를 시스템이 실행할 수 있는 단위로 만듭니다. 화면은 그 행위의 결과를 사람이 확인하는 마지막 껍데기입니다.

전통 ERP의 설계는 명사에서 출발합니다. 사원 등록 화면, 품목 테이블, 결재 메뉴. 사람이 화면을 열어 데이터를 입력하고 저장 버튼을 누르는 것을 전제로 모든 구조가 짜입니다. 그래서 시작점이 Form과 Table입니다. 20년 동안 ERP는 이렇게 만들어졌고, 그게 당연했습니다. 사람이 일을 하니까, 사람이 쓸 화면부터 만드는 게 자연스러웠습니다.

왜 화면부터 만들면 평범한 ERP가 되는가

그런데 목표가 “대부분의 업무를 에이전트가 처리하고, 사람은 승인·반려만 한다”라면 이 구조는 출발부터 어긋납니다. 이유는 간단합니다. 에이전트는 화면을 클릭하지 않습니다.

에이전트는 버튼을 보지 않고, 드롭다운을 고르지 않고, 저장 버튼을 누르지 않습니다. 에이전트가 하는 일은 다릅니다 — 이벤트가 발생하면 도구(Tool)를 호출하고, 정책에 따라 분기하고, 필요할 때 사람에게 승인을 요청합니다. 그러니 에이전트를 위한 시스템의 시작점은 Form과 Table이 아니라 Event와 Tool이어야 합니다.

함정: 화면부터 만든 모듈의 운명

초기에 만든 인사 모듈은 정직하게 평가하면 전통 ERP였습니다. “직원 목록을 가져온다”, “직원을 등록한다”, “직원 정보를 수정한다” — 전부 사람이 화면에서 누르는 것을 전제로 한 명사형 기능입니다. 에이전트가 끼어들 자리가 없습니다. 화면부터 만들면 결국 “사람이 일일이 눌러야 하는” 시스템이 되고, AI는 그 위에 얹힌 챗봇 정도로 끝납니다. 화면이라는 출구가 모든 설계를 거꾸로 잡아당기기 때문입니다.

같은 업무라도 어디서 출발하느냐가 시스템의 성격을 가릅니다. 왼쪽은 화면이 모든 걸 잡아당겨 "사람이 누르는 시스템"으로 굳고, 오른쪽은 동사가 중심이라 "에이전트가 실행하는 시스템"이 됩니다.

동사 5단 추출 — 하나의 모듈을 묻는 법

그래서 모듈 하나를 설계할 때 화면 이야기를 5단계 뒤로 미뤘습니다. AI에게 “화면을 그려줘”라고 하지 않고, 다음 순서로 물었습니다.

1. 사건 열거 — 이 모듈에서 1년 동안 실제로 일어나는 사건을 시간 순으로 20개 이내로 적습니다. (“신입이 입사한다”, “연차를 신청한다”, “재고가 떨어진다”…)
2. 사건 해부 — 각 사건마다 다섯 가지를 채웁니다. 누가(Actor) · 무엇을 보고(Context) · 어떤 판단(Decision) · 어떤 결과(Output) · 다음 트리거(Next Event).
3. 결정 분류 — 각 결정을 셋으로 나눕니다. 완전 자동화 가능 / 정책 분기로 처리 / 인간 승인 필수.
4. 외부 의존 식별 — 결정에 필요한 바깥 시스템을 적습니다. 메일·회계·근태·결제·세금계산서 등.
5. 동사 명세 — 사건들을 의미 있는 동사(메서드명)로 정리하고 입력·출력 타입을 명세합니다.

예시 — “신규 입사”라는 명사를 동사로 풀면

명사로 보면 신규 입사는 “사원 등록 화면” 하나입니다. 그런데 동사로 풀면 전혀 다른 풍경이 펼쳐집니다.

동사	이 동사의 처리 방식	외부 의존
입사를 처리한다	정책 분기 (자동)	—
계정을 발급한다	자동화 가능	메일
4대보험에 가입한다	자동화 가능	외부 신고 시스템
연봉을 확정한다	인간 승인 필수	—
멘토를 배정한다	정책 자동 분기	—

주목할 점은, 동사로 풀어 적는 순간 각 동사가 자기 처리 방식을 스스로 드러낸다는 것입니다. 4대보험 가입은 외부 어댑터를 부르는 자동 작업이고, 연봉 확정은 절대 자동화하면 안 되는 인간 승인 게이트이며, 멘토 배정은 규칙으로 굴러가는 자동 분기입니다. 명사(“사원 등록 화면”)로만 봤다면 이 차이는 전부 화면 안에 뭉개져 보이지 않았을 것입니다.

동사 하나가 세 가지를 동시에 낳는다

이 방식의 진짜 보상은 동사 하나를 제대로 뽑으면 세 가지 산출물이 한꺼번에 결정된다는 점입니다. 따로 설계할 필요가 없습니다.

동사를 뽑으면…	동시에 정해지는 것	그게 무엇이냐면
입력·출력 타입	도구 시그니처	에이전트가 호출할 MCP Tool의 함수 모양
누가 결정하는가	에이전트 역할	어느 에이전트가 이 동사를 맡는가
자동/분기/승인 분류	정책 룰북	무엇을 사람이 승인할지(권한 경계)

용어: MCP Tool 카탈로그

에이전트가 호출할 수 있는 “동사 목록”을 한곳에 모은 표준 카탈로그입니다. 각 동사마다 이름·입력·출력이 정의돼 있어, 에이전트는 이 카탈로그에서 도구를 골라 업무를 실행합니다. 동사 추출의 결과물이 곧 이 카탈로그가 됩니다.

그래서 동사부터 뽑으면 ERP 모듈들이 “서로 다른 화면 세트”가 아니라, 같은 패턴(동사 + 입력 + 결정 + 출력 + 다음 동사)으로 묶인 하나의 그래프가 됩니다. 에이전트는 그 그래프를 따라 움직입니다. 실제로 개인 업무 영역 하나를 동사로 풀었을 때 약 85개의 동사가 카탈로그 초안으로 나왔고, ERP 전체로 확장하면 수백 개 규모가 될 것으로 봅니다. 화면은 맨 마지막에 “동사 실행 결과를 사람이 확인·승인하는 최소 뷰”로만 붙입니다.

왜 이게 “사전 전제조건”인가

이 순서를 거꾸로 하면 뒤의 모든 설계가 무너지기 때문입니다. 화면부터 만들면 도구 카탈로그가 안 나오고, 도구가 없으면 에이전트가 호출할 게 없고, 호출이 없으면 자가학습에 쌓일 판단 기록도 없습니다. 동사부터 묻는 건 취향이 아니라, 에이전트 시스템이 성립하기 위한 첫 단추입니다.

느려 보이지만, 사실 두 번 짓지 않는 길

동사를 20개 뽑고 다섯 칸을 채우는 작업은 처음엔 답답합니다. “그냥 화면부터 후딱 만들면 될 걸”이라는 유혹이 큽니다. 그러나 화면부터 만든 모듈은 결국 에이전트를 붙이려는 순간 처음부터 다시 설계해야 합니다. 명사형으로 굳은 구조는 동사형으로 리모델링되지 않기 때문입니다.

반대로 동사부터 설계하면, 같은 동사를 사람이 화면에서 호출하든·AI가 말로 호출하든·다른 시스템이 이벤트로 호출하든 그 뒤의 실행 단위는 하나입니다. 한 번 만든 동사가 입구를 가리지 않고 재사용됩니다. 처음 30분 더 들이는 대신, 나중에 통째로 다시 짓는 3개월을 아끼는 셈입니다.

교훈

에이전트 네이티브 ERP의 사전 전제조건은 거창한 인프라가 아니라 질문의 순서입니다. 명사(Form·Table·Menu)부터 묻는 순간 시스템은 구시대 ERP로 굳고, AI는 그 위에 얹힌 장식이 됩니다. 동사부터 묻고 — 1년치 사건을 동사로 뽑아, 각 동사를 자동/분기/승인으로 분류하고 — 그 동사 목록을 그대로 도구 카탈로그로 삼으세요. 화면은 마지막에 얇게 붙입니다. 이 한 줄의 순서 바꿈이 개발을 느리게 만드는 진짜 이유이자, 다른 물건이 되는 출발점입니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.