ERP와 또 다른 개인 업무 시스템의 필요성

ERP는 회사의 공식 업무를 다룹니다. 그런데 직원이 하루를 보내는 실제 업무 — 오늘 할 일, 동료와의 업무 공유, 메모, 일정, 이메일, 회의록 — 은 ERP 밖에서 흩어진 채 돌아갑니다. 직원이 가장 오래 머무는 곳이 정작 회사 시스템 밖이라면, 그 시스템은 회사를 제대로 담고 있지 못한 것입니다. 이 글은 그 빈틈을 메우는 개인 업무 포탈을 왜, 어떻게 설계했는지의 기록입니다.

실제 업무 포탈 화면. ERP의 단단한 전표가 아니라 할 일·메모·일정·프로젝트 같은 "느슨한 일상 업무"가 한곳에 모이고, 위쪽 AI 브리핑이 "오늘 반드시 확인할 것"을 먼저 짚어 줍니다. (직원 이름은 시스템이 이미 ○○ 처리하고, 실제 고객·제품명과 금액은 추가로 가렸습니다.)

ERP가 담지 못하는 “오늘의 업무”

먼저 두 종류의 업무를 구분하겠습니다. 같은 회사 일이라도 성격이 전혀 다릅니다.

용어: 구조화된 공식 업무 (ERP의 영역)

전표·발주서·결재 문서처럼 형식이 정해져 있고 권한이 엄격한 기록입니다. 빈도는 낮지만 한 건 한 건이 무겁고, 법적·회계적 의미를 가집니다.

용어: 느슨한 일상 업무 (개인 업무의 영역)

“이거 내일까지 처리해야지”, “김 대리한테 이 건 넘겨줬어”, “회의에서 이렇게 정했어” 같은 것입니다. 형식은 가볍지만 빈도는 ERP보다 훨씬 높습니다. 직원의 하루 대부분이 여기서 흐릅니다.

ERP의 데이터는 구조가 단단합니다. 형식이 정해져 있고 권한이 엄격합니다. 반면 직원의 하루는 훨씬 느슨합니다. 위의 “느슨한” 것들은 정형화된 ERP 테이블에 들어가지 않습니다. 억지로 끼워 넣으면 ERP가 무거워지고, 무시하면 직원들은 결국 메신저·메모앱·캘린더를 따로 쓰며 회사 시스템 밖에서 일하게 됩니다.

	ERP (공식 업무)	개인 업무 포탈
데이터 형식	단단함 (정해진 양식)	느슨함 (자유 텍스트)
권한	엄격함	가벼움
빈도	낮음 (건당 무거움)	높음 (하루 종일)
예시	전표·발주서·결재 문서	할 일·메모·일정·메일
법적 의미	있음	대체로 없음

두 시스템을 나눈 이유

ERP는 “구조화된 공식 기록”이고, 개인 업무 포탈은 “느슨한 일상 업무”입니다. 할 일·업무 공유·메모·일정·이메일·회의록 — 형식은 가볍지만 빈도는 ERP보다 훨씬 높습니다. 그래서 ERP와 분리하되 같은 플랫폼 안에 있는 개인 업무 포탈을 따로 두기로 했습니다. 분리한 건 성격이 다르기 때문이고, 같은 플랫폼에 둔 건 따로 놀면 또 회사 밖으로 새기 때문입니다.

여기서도 출발점은 동사였다

개인 업무 포탈을 만들 때도 화면이 아니라 동사부터 뽑았습니다(동사부터 묻기). “할 일 화면을 만들어줘”가 아니라, “할 일을 두고 사람이 하는 행위가 무엇인가”를 먼저 물었습니다.

1. 할 일을 만든다 · 상태를 옮긴다(대기→진행→완료) · 담당자를 배정한다
2. 보관한다 · 미룬다 · 우선순위를 바꾼다
3. 진행 상황을 집계한다 · 주간 보고를 만든다

각 행위를 의미 있는 동사로 정의하고, 그 동사를 에이전트가 호출할 수 있는 도구로 등록했습니다. 개인 업무 영역 하나를 이렇게 동사로 풀었을 때 약 85개의 동사가 카탈로그 초안으로 나왔습니다. 화면을 먼저 그렸다면 이 동사 목록은 화면 코드 안에 흩어져 영영 도구가 되지 못했을 것입니다.

입구는 여럿, 계약면은 하나 — 단일 계약면

이 설계에서 가장 중요한 결정은 UI·AI 비서·메신저 봇이 전부 같은 동사를 호출하게 한 것입니다.

용어: 단일 계약면(single contract face)

같은 업무를 어디서 시작하든(화면 클릭이든, AI 대화든, 메신저 명령이든) 그 뒤에서 실행되는 업무 단위는 하나뿐이게 만든 것입니다. 입구는 여러 개지만, 실제 일을 하는 통로는 하나입니다.

화면에서 누르든·AI에게 말로 시키든·메신저에서 명령하든, 그 뒤에서 호출되는 업무 단위는 하나입니다. 입구가 여러 개여도 계약면이 하나여야, 어디로 들어와도 같은 규칙과 같은 기록이 적용됩니다.

이게 왜 중요할까요? 만약 화면용 코드와 AI용 코드와 메신저용 코드가 따로 있다면, “할 일 만들기” 규칙이 세 곳에 흩어집니다. 한 곳을 고치면 나머지 둘이 어긋납니다. 단일 계약면은 그 흩어짐을 원천 차단합니다 — 규칙은 동사 하나에만 있고, 모든 입구가 그 동사를 부릅니다.

처음부터 학습 가능하게 — 활동 기록을 심다

개인 업무라고 해서 자기학습 설계에서 빠지지 않았습니다. 할 일·메모 같은 가벼운 데이터에도 “이건 AI가 제안했나, 사람이 어떻게 바꿨나”를 남기는 칸을 처음부터 넣었습니다. 실제로 핵심 동사를 도구로 등록할 때, AI가 할 일을 제안하고 사람이 그 제안을 받아들이거나 고치면 그 판단이 결정 기록으로 남도록 배선했습니다.

함정: 기록 구조는 소급해서 만들 수 없다

지금 당장 학습 엔진이 돌지 않아도 기록 칸은 처음부터 박아야 합니다. 나중에 “학습시켜 보자”고 마음먹어도, 그동안 기록 구조가 없었으면 먹일 재료 자체가 없습니다. 과거의 판단은 소급해서 만들어 낼 수 없기 때문입니다. → 자가학습의 전제

솔직하게 말하면, 지금은 핵심 동사 몇 개를 도구로 등록하고 할 일 화면을 붙인 초기 단계입니다. AI 비서가 할 일을 제안하고 사람이 검토하는 흐름은 동작을 확인했고, 일정·메일 같은 일부 영역은 실제 외부 서비스와 연동해 동작하는 것도 확인했습니다. 그러나 “입구는 여럿, 계약면은 하나, 모든 행위는 기록된다”는 골격을 먼저 박아 두는 것 — 이것이 나중에 두 번 짓지 않는 유일한 방법이었습니다.

왜 ERP에 억지로 끼워 넣지 않았나

“할 일·메모도 결국 회사 일이니 ERP 테이블에 넣으면 되지 않나?” 충분히 나올 수 있는 질문입니다. 실제로 그렇게 한 시스템도 많습니다. 그런데 그렇게 하면 두 가지가 동시에 망가집니다.

억지로 ERP에 넣으면	무슨 일이 생기나
느슨한 데이터를 단단한 양식에	입력이 번거로워져 직원이 안 쓴다
높은 빈도를 엄격한 권한에	매번 마찰 → 결국 메신저로 도피
가벼운 메모를 무거운 구조에	ERP가 비대해지고 느려진다

그래서 성격이 다른 두 시스템을 분리하되 한 플랫폼에 뒀습니다. 분리는 각자의 성격을 살리기 위함이고, 한 플랫폼은 직원이 회사 밖 도구로 새어 나가지 않게 하기 위함입니다. 둘 다 같은 로그인, 같은 디자인, 같은 동사 원칙을 공유합니다. 직원에게는 하나의 시스템처럼 느껴지지만, 안에서는 두 성격이 각자의 방식으로 돕니다.

교훈

ERP만으로는 직원의 하루를 담지 못합니다. 느슨한 개인 업무(할 일·메모·일정·메일·회의록)를 위한 별도 시스템이 필요하되, ERP와 같은 원칙 위에 세우세요 — 동사부터 뽑고, UI·AI·메신저가 단일 계약면을 공유하고, 모든 행위에 학습용 기록을 남깁니다. 입구가 여러 개여도 통로는 하나여야 규칙이 흩어지지 않습니다. 직원이 가장 오래 머무는 곳이 회사 시스템 밖이라면, 거기가 바로 다음에 지을 곳입니다.

---

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