AX의 첫 세팅은 데이터베이스입니다
— 대전·진주 두 현장에서 해본 데이터베이스 구축 방법
대전 품앗이(로컬푸드 매장)와 진주의 협동조합(매장 3곳, 직원 25명)에서 실제로 진행한 작업을, 업종이 달라도 그대로 적용할 수 있는 형태로 정리했습니다.
1. 왜 데이터베이스부터인가
AI 전환(AX)이라고 하면 보통 “어떤 AI를 쓸까”부터 생각하게 됩니다. 그런데 현장에서 해보면 순서가 반대입니다. AI는 조직의 자료를 읽을 수 있어야 일을 합니다. 자료가 읽을 수 없는 곳에 있으면, 아무리 좋은 AI를 들여와도 일반론밖에 못 합니다.
대부분의 조직에서 자료는 세 군데에 흩어져 있습니다.
- 외부 업체 프로그램 안 — 판매관리, 청구, 회계, 인사 프로그램. 화면으로 보고 인쇄는 되지만, 데이터를 꺼내 쓰는 건 안 되거나 어렵습니다.
- 담당자 개인 PC의 엑셀 — 그 담당자만 알고, PC가 바뀌거나 사람이 바뀌면 사라집니다.
- 수기 장부와 머릿속 — 기록 자체가 없습니다.
이 상태에서는 AI가 손댈 것이 없습니다. 그래서 AX의 진짜 첫 작업은 모델 선택이 아니라, 흩어진 자료를 조직이 직접 다룰 수 있는 저장소 하나로 모으는 일 — 데이터베이스 구축입니다. 이게 되면 그 위에 근태, 정산, 통계, 업무 자동화가 차례로 올라갑니다. 안 되면 무엇을 얹어도 모래 위입니다.
두 현장의 결과만 먼저 말씀드리면:
- 대전 — 수년에 걸쳐 판매 기록을 데이터베이스로 모았고, 지금은 매출·운영 지표가 사람 손 없이 자동 산출됩니다. AI가 “느낌”이 아니라 숫자를 근거로 경영 판단을 돕습니다.
- 진주 — 엿새 만에 압축 구축했습니다. 판매 기록 13만 9천 행, 회원 명부 7천여 건, 상품 목록 1만여 건을 하나의 데이터베이스에 적재하고, 그 위에 홈페이지·근태관리·정산 자동화·업무 위키까지 7종의 시스템을 올렸습니다. 오래 걸리는 일이 아니라는 뜻입니다. 순서를 알면 짧게 됩니다.
2. 구축 순서 — 일곱 단계
① 자료 지도부터 그린다
코딩이 아니라 조사입니다. 어떤 자료가, 어디에, 어떤 형태로, 누구 손에 있는가를 한 장으로 만듭니다.
- 회원(고객·환자·이용자) 명부는 어디에 있나? 몇 개 파일로 나뉘어 있나?
- 매출(진료·청구·판매) 기록은 어느 프로그램에 있나? 내보내기가 되나?
- 근태·급여는 누가 어떻게 계산하나?
- 각 자료의 “주인”(매일 그걸 입력하는 담당자)은 누구인가?
진주에서는 이 조사에서 아무도 모르던 도메인 자산이 나왔고, 회원 명부가 파일 4개로 흩어져 있다는 것도 여기서 드러났습니다. 지도 없이 시작하면 반드시 중간에 되돌아옵니다.
② 갇힌 자료의 내보내기 경로를 확보한다
외부 업체 프로그램 안의 자료는 조직의 자료인데 조직이 못 꺼내는 상태인 경우가 많습니다. 업체에 요청해서라도 내보내기(엑셀, CSV) 경로를 확보하는 것이 먼저입니다. 이건 기술 문제이기 전에 데이터 소유권 문제입니다 — 계약이 끝나면 그 자료는 어디로 갑니까?
처음부터 실시간 연동(API)을 요구할 필요는 없습니다. 진주에서는 월 1회 파일로 받아 올리는 방식으로 시작했고, 한 달쯤 굴려서 “무엇을 어떤 주기로 받아야 하는지”가 확정된 다음에 정식 연동을 요청하기로 했습니다. 수동으로 먼저 돌려보는 기간은 임시방편이 아니라 요구사항을 확정하는 관찰 기간입니다.
③ 중앙 저장소를 하나 만든다 — 조직 명의로
저장소는 관계형 데이터베이스 하나면 됩니다. 요즘은 클라우드 데이터베이스 서비스의 무료·저가 요금제로 중소 조직 규모(수십만 행)는 충분히 감당됩니다. 진주는 서버 구입 없이 월 추가 비용 0원으로 시작했습니다.
여기서 지켜야 할 원칙이 두 개 있습니다.
- 모든 계정을 조직 명의로 만든다. 대표나 담당자 개인 이메일에 얹으면, 그 사람이 바뀌는 순간 조직 자산이 남의 것이 됩니다. 처음부터 조직 공용 계정 하나를 뿌리로 삼고 전부 거기에 물립니다.
- 처음부터 인계를 전제로 만든다. 외부 전문가나 업체가 세팅하더라도, 계정·비밀번호·복구수단을 조직이 넘겨받는 것까지가 구축입니다.
④ 적재하고, 반드시 검증한다
자료를 데이터베이스에 넣는 것(적재)보다 중요한 것이 **넣은 값이 원본과 맞는지 대조하는 것(검증)**입니다. 방법은 단순합니다. 원본 파일의 합계와 데이터베이스의 합계를 끝자리까지 맞춰봅니다.
진주에서는 한 달치 판매 총액을 원본 엑셀, 일별 판매 테이블, 월별 집계 테이블 세 곳에서 각각 뽑아 1원까지 일치하는 것을 확인하고 다음 단계로 갔습니다. 이 검증을 건너뛰면 나중에 숫자가 안 맞을 때 어디서 틀렸는지 찾을 수가 없고, 무엇보다 사람들이 데이터베이스를 믿지 않게 됩니다. 믿지 않는 데이터베이스는 아무도 안 씁니다.
⑤ 시스템 사이의 “코드 연결 사전”을 만든다
거의 모든 조직이 여기서 막힙니다. 판매 프로그램의 상품코드와 회계 프로그램의 품목코드가 다릅니다. 청구 시스템의 코드와 재고 시스템의 코드가 다릅니다. 그래서 두 시스템을 오가는 일(정산, 전표 입력)이 전부 사람의 수작업이 됩니다.
해법은 두 코드를 잇는 대응표(사전)를 한 번 만들어 데이터베이스에 두는 것입니다. 진주에서는 1,646건의 대응표를 만들어, 매달 반복되던 수작업 전표 입력이 “파일 생성 버튼 → 업로드”로 줄었습니다.
이때 함정이 하나 있습니다. 이름으로 잇지 마십시오. 같은 이름의 상품이 수십 개, 같은 이름의 사람이 열 명씩 있습니다. 진주에서 이름으로 이었더니 한 거래처의 월 매출이 실제의 2배로 잡혔습니다. 반드시 코드(고유번호)로 잇고, 코드가 없으면 만들어야 합니다. 그리고 기계가 확신 못 하는 건은 사람이 승인하는 절차를 남겨둡니다.
⑥ 민감정보는 처음부터 분리한다
전부 올리는 것이 아닙니다. 무엇을 데이터베이스에 올리고 무엇을 올리지 않을지가 설계의 일부입니다.
진주에서 정한 선은 이렇습니다. 근태 기록(출퇴근 시각)은 데이터베이스에 두되, 급여 계산은 데이터베이스에 올리지 않고 급여 담당자의 컴퓨터에서 합니다. 회원 명부는 올리되, 누가 열람할 수 있는지를 명시적으로 합의했습니다.
의료·요양처럼 다루는 정보 자체가 민감한 업종이라면 이 단계의 비중이 더 커집니다. 원칙은 같습니다 — 업무에 필요한 최소 범위만 올리고, 가장 민감한 것은 아예 안 올리는 선택지를 항상 열어두고, 누가 무엇을 보는지를 문서로 합의하고 시작한다. 그리고 무료 요금제에는 대개 자동 백업이 없으므로, 정기 백업(월 1회 내보내기라도)을 반드시 업무 달력에 넣습니다.
⑦ 숫자는 데이터베이스에, 지식은 위키에
조직의 자산은 두 종류입니다. **숫자·명부(데이터)**와 일하는 방법·매뉴얼·규정(지식). 이 둘은 저장소를 나눕니다.
- 데이터 → 데이터베이스 (권한 통제, 집계·검증 가능)
- 지식 → 조직 위키 (누구나 찾아 읽는 업무 매뉴얼 모음)
진주에서는 데이터베이스와 함께 업무 위키를 세웠고, 첫 주에 실무 문서 340여 개가 올라갔습니다. 이 위키가 중요한 이유는 사람만 읽는 게 아니기 때문입니다. 실무자가 쓰는 AI가 이 위키를 읽고 조직의 방식대로 답하게 됩니다. 데이터베이스가 AI의 숫자 근거라면, 위키는 AI의 업무 상식입니다.
3. 운영 원칙 — 만든 뒤에 지킬 것
적재는 담당자가, AI는 정제·검증·분석을. 역할을 섞지 않습니다. 매달 자료를 넣는 것은 그 업무의 담당자이고, AI는 넣은 자료의 오류를 찾고 집계하고 분석합니다. 담당자가 소외된 자동화는 오래 못 갑니다.
자동화는 단계적으로. 한 번에 전자동으로 가지 않습니다. ① 조회만 자동 → ② 초안 자동 생성(사람이 승인·입력) → ③ 승인된 건만 자동 전송 → ④ 전체 자동. 각 단계에서 검산이 맞는 것을 확인하고 다음으로 갑니다. 단계를 건너뛰면 틀린 값이 조용히 쌓입니다.
내부에 챔피언을 세운다. 외부가 모든 문제를 풀어줄 수 없습니다. 진주에서는 처음부터 실무 책임자 2인을 “챔피언”으로 정해, 세팅 기간에 배포·수정을 직접 해보게 했습니다. 이후의 유지·확장은 이 두 사람을 통해 갑니다. 시스템 인계가 아니라 능력의 인계가 목표입니다.
AI를 쓰지 않을 권리를 보장한다. 모든 직원이 AI를 써야 하는 게 아닙니다. 구성원은 세 층으로 공존합니다 — ① 앱만 쓰는 사람 ② AI를 자기 업무의 도구로 쓰는 사람 ③ 조직의 전환을 이끄는 사람. 등급이 아니고, 층 이동은 본인이 정합니다. 설계상 중요한 함의는 이것입니다: ①층이 AI 없이도 쓸 수 있는 앱(출퇴근 화면, 인쇄 도구, 위키 열람)이 반드시 있어야 전환이 조직을 가르지 않습니다.
4. 데이터베이스가 생기면 달라지는 것
한 문장으로 줄이면 이렇습니다.
데이터베이스는 시스템 하나가 아니라, 그 위에 모든 것이 올라가는 바닥이다.
진주에서 엿새 동안 만든 홈페이지·가격표 인쇄·근태관리·정산 자동화·업무 위키 7종은 전부 하나의 데이터베이스를 바닥으로 씁니다. 바닥이 있으니 앱 하나 추가하는 일이 가벼워졌고, 다른 조직에서 검증된 앱을 이식받는 것도 가능해졌습니다.
그리고 대전이 보여주는 것은 그 다음입니다. 데이터가 쌓이면 지표 산출이 자동이 되고, AI가 일반론이 아니라 우리 조직의 숫자를 근거로 답하기 시작합니다. “이번 달 어느 부문이 왜 줄었나”에 추측이 아니라 데이터로 답하는 조직 — AX가 목표하는 자리가 거기이고, 그 출발이 데이터베이스 구축입니다.
함께 읽기
- 기업 AX 방법론 뜯어보기 — 에이전트 팀 설계와 검토 게이트 — 데이터베이스 위에서 AI 팀을 어떻게 짜는가, 그 다음 단계
- 자동화 16개 시간 단축 산출 — 대전에서 데이터베이스 위에 올린 자동화들이 실제로 아낀 시간
- LLM 위키 구축 안내 — 7단계 “지식은 위키에”를 실제로 만드는 방법
- 클로드코드 데스크탑앱 안내 — 실무자가 각자 AI를 쓰기 시작할 때의 도구 안내
작성: 품앗이 (2026-08-21) · 대전 품앗이·진주 사례 실작업 기준