## 한 줄 요약
1편에서 "사람 / AI / 자동화" 세 역 할로 시스템을 나눴다고 했는데, 이번 편은 그게 발주·입고검수·매출 수집·재고 관리 네 기능에서 실제로 어떻게 갈렸는지, 그리고 만든 사람이 없어져도 시스템이 안 무너지게 만든 방법(앱 안의 WIKI)까지 담은 완결편이에요.
## 들어가며
시스템을 만들 때 제가 계속 스스로에게 던진 질문은 하나였어요.
> 이건 사람이 판단해야 하나, 규칙으로 자동화할 수 있나, 아니면 AI에게 맡길 일인가?
기능마다 답이 달랐어요. 그리고 그 답을 정하는 건 언제나 현장을 아는 사람이었어요.
## 1. 발주 추적 — 프로세스를 그린 건 사람이었다
우리 발주는 성격에 따라 단계가 달라요.
- 자사·사입: 발주 요청 → 발주 확인 → 출고 예정 → 입고 (4단계)- 위탁: 위탁 요청 → 출고 확인 → 정산 (3단계)이 단계 구분은 개발로 나온 게 아니라 현장에서 실제로 일이 흘러가는 순서예요. 위탁 재고는 업체 소유라 정산 구조가 완전히 다르다는 걸, 매일 발주를 넣는 사람만 알아요.
그리고 발주를 확정하는 순간 시스템이 자동으로 갈라요 — 창고에 재고가 있으면 창고분(물류 출고), 없으면 업체분(직납). 담당자가 일일이 나눌 필요가 없어요.
- 사람: "이 흐름이 왜 이렇게 나뉘는지" 프로세스 정의
- 자동화: 창고 재고 유무로 전표 자동 분기
- AI: 그 규칙을 DB 스키마와 발주 화면으로 구현
한국사이트 스크린샷
## 2. 입고검수 — 예외를 아는 건 결국 사람이다
입고검수에서 제가 꼭 넣어달라고 한 두 가지가 있어요.
거래명세서 이미지 필수화. 명세서를 첨부하지 않으면 수량 입력 자체가 안 되게 막았어요. 왜냐면 — 현장에서 이 문서를 빼먹는 일이 실제로 생기거든요. 이건 기능 명세서엔 안 나오는, 겪어본 사람만 아는 구멍이에요.
라인 단위 취소 + 재고 롤백. 검수 완료한 라인을 나중에 개별 취소하면 재고가 자동으로 되돌아가요. "이런 케이스가 실제로 일어난다"는 걸 아는 게 핵심이었어요.
- 사람: "이 기능이 왜 필요한지" — 현장의 예외를 지목
- AI: "어떻게 구현할지" — 첨부 검증, 롤백 로직 해결
AI는 제가 겪은 적 없는 기술 문제를 풀었고, 저는 AI가 알 수 없는 현장의 예외를 채웠어요.
## 3. 재고 관리 — 세 영역이 교차하는 지점
여기가 제일 흥미로웠어요. 한 기능 안에 세 역할이 다 들어가거든요.
가챠머신 재고 기준시점. 매장마다 실사하는 날짜가 달라서 재고 기준일이 제각각이에요. "왜 매장마다 다른지"는 사람이 정의하고, 기준시점 자동 갱신은 시스템이 해요.
바코드 스캔 필수화 — 그런데 보류했어요. 기술적으로는 충분히 만들 수 있었어요. 그런데 상품 중 14%가 아직 바코드 미등록이라, 지금 강제하면 매장이 멈춰요. 그래서 만들 수 있어도 지금은 하지 않기로 결정했어요.
이게 저한테는 제일 중요한 배움이었어요.
> 자동화할 수 있느냐보다, 자동화하지 말아야 할 때가 언제인지 아는 게 진짜 설계력이더라고요.
기술은 AI가 다 할 수 있어요. 하지만 "지금 이걸 켜면 현장이 준비가 안 됐다"는 판단 — 그건 온전히 사람의 몫이에요.
### 여기서 보인 패턴
네 기능을 뜯어보니 규칙이 보였어요.
- 규칙이 명확하면 → 자동화
- 기술 문제면 → AI
- "왜"와 "지금 해도 되는가"는 → 언제나 사람
AI 시대에도 사람이 사라지지 않는 이유가 여기 있어요. 무엇을 자동화할지, 그리고 무엇을 아직 자동화하지 않을지를 정하는 건 도메인을 아는 사람이니까요.
## 잘 만드는 것보다 어려운 것: 안 무너지게 하는 것
기능을 다 만들고 나서 진짜 어려운 건 따로 있었어요.
> 만든 사람만 아는 시스템은, 만든 사람이 없어지는 순간 블랙박스가 된다.
매장 직원은 바뀌고, 담당자도 바뀌어요. "이 화면은 왜 물류만 쓰나요?" "이 규칙은 왜 이렇게 됐어요?" — 이 질문에 답할 사람이 없으면, 잘 만든 기능도 아무도 안 쓰게 돼요.
기존엔 이 지식이 노션에, 카톡에, 누군가의 머릿속에 흩어져 있었어요. 그래서 인수인계 때마다 처음부터 다시 설명해야 했죠.
## WIKI를 앱 "안에" 넣기로 했다
문서를 따로 두지 않고, 앱 안에 WIKI 메뉴를 만들어서 시스템과 설명을 한 몸으로 붙였어요. 기능을 배포할 때마다 그 설명과 이력이 같은 곳에 쌓이게요.
중요한 건 이 WIKI를 비개발자·초보 직원 눈높이의 존댓말 문서로 썼다는 거예요. 기술 용어를 걷어내고, 일상 비유로 풀었어요. 예를 들어 이 시스템의 핵심을 이렇게 설명했어요.
> "이 앱은 ERP에 올리기 전, 모든 재고의 움직임을 먼저 기록하고 검증하는 중간 검문소입니다."
이 한 문장이면 개발을 몰라도 시스템의 존재 이유를 이해해요.
## WIKI가 실제로 해결한 3가지
1. 업무 구분이 명확해졌다. 물류 화면 / 매장 화면 / 본사 화면이 왜 다른지, 누가 무엇을 쓰는지가 문서에 남아요. "이건 제 일이 아닌데요"가 줄었어요.
2. 인수인계가 쉬워졌다. 새 매장 직원이 와도 앱 안에서 사용법을 바로 확인해요. 옆에서 붙어 설명하던 시간이 확 줄었어요.
3. 히스토리가 사라지지 않는다. 배포할 때마다 업데이트 로그에 한 줄씩 쌓여요. "언제 뭐가 바뀌었지?"를 거슬러 올라갈 수 있어요. 이게 쌓이니까 시스템 자체가 하나의 기록물이 되더라고요.
## 결산: MD가 AI와 일하면서 배운 것
- 설계를 먼저 하면 AI와의 대화가 몇 배는 빨라진다. "만들어줘"가 아니라 "이 흐름의 이 화면"이라고 말할 수 있으면 결과가 완전히 달라져요.
- iterate를 두려워하지 말 것. DB 구조를 서른 번 넘게 고쳤어요. 처음부터 완벽할 수 없다는 걸 받아들이니 오히려 빨라졌어요.
- 아직 못 만든 것도 많다. 반품 로직,— 설계가 덜 여문 부분은 AI도 저와 함께 헤매요. 결국 시스템의 완성도는 제 도메인 이해의 완성도만큼이더라고요.
## 마무리: AI 시대에 MD의 역할
이 작업을 하기 전엔 막연히 "AI가 내 일을 줄이겠지" 생각했어요. 그런데 직접 해보니 반대였어요.
> AI 시대에 운영자의 역할은 사라지는 게 아니라, 더 선명해집니다.
무엇을 만들지, 무엇을 자동화하고 무엇을 아직 하지 말지, 왜 이 규칙이 필요한지 — 이걸 정의하는 건 여전히 도메인을 아는 사람이에요. 그리고 이제는 그걸 언어로 정확히 설명하는 능력이 곧 시스템을 만드는 능력이 됐어요.코드를 못 짜도 괜찮아요. 내 일을 누구보다 잘 알고, 그걸 설명할 수 있다면 — AI와 함께 얼마든지 시스템을 만들 수 있어요. 저처럼 비개발자 MD도요.
### 다음에 해볼 것
- 반품 로직 설계 — event 구조부터 다시
- 마이너스 재고 대시보드 — 예외 승인 건을 한눈에
---
(1~2편 완결) 읽어주셔서 감사해요. 비개발자도 도메인만 정확히 알면 AI와 시스템을 만들 수 있다는 게, 이 기록의 전부예요.
