AX 프로젝트 추진 사례
업무관리시스템을 10회차로 완성하기

우리 회사는 교육·컨설팅이 주업무입니다. 고객 문의가 오면 영업 → 견적 → 수주 → 일정 배정 → 강의 수행 → 계산서 발행 → 수금 → (외부강사) 정산까지 한 줄기로 흘러갑니다. 그런데 그 한 줄기가 여러 개의 도구에 나뉘어 있었습니다.

영업이 성사되면 시트와 에어테이블 양쪽에 이중 등록해야 했고, 외부 강사에게 줄 돈은 세 번째 파일에서 따로 계산했습니다. 그리고 어느 쪽도 "이 프로젝트에서 우리가 얼마를 청구했고 얼마가 아직 안 들어왔는지"를 한 화면에서 답하지 못했습니다. 10회차의 목표는 이 셋을 하나로 합치는 것이었습니다.

10회차 프로세스가 회차마다 던지는 핵심 질문에 우리가 어떻게 답했는지를 먼저 펼쳐 둡니다. 이 문서의 각 회차는 이 표의 한 줄을 자세히 푼 것입니다.

진행 방식회차별로 ①무엇을 하는 회차인지 → ②우리가 실제로 한 것 → ③그때 내린 결정 → ④결과 화면·숫자 → ⑤산출물 순으로 읽습니다. 완료 기준: 각 회차 끝의 산출물 목록을 보고 "우리 과제라면 이 자리에 무엇이 놓일지" 말할 수 있는가.

과제 정의는 "실물을 보는 것"에서 시작합니다. 우리가 쓰던 파일 세 개를 그대로 펼쳐 놓고 시작했습니다. 아래 캡처는 실제 원본 파일이고, 고객사명·인명·계좌·금액만 가명으로 바꾼 것입니다.

① 구글 시트를 엑셀로 내려받은 회사 캘린더

이 한 장에서 1회차의 문제가 전부 보입니다. ① 일정은 있는데 금액이 없습니다. ② "이 칸의 약칭이 어느 회사인가"는 사람 머릿속에만 있습니다. ③ 정작 쓸모 있는 정보(시간·장소·연락처)는 셀 값이 아니라 노트에 숨어 있어서, 값만 읽는 프로그램에는 존재하지 않는 것과 같습니다. ④ 달이 바뀌면 블록이 끊겨 "지난주와 이번 주"를 나란히 볼 수 없습니다.

② 에어테이블에서 내보낸 프로젝트 목록

③ 외부 인건비 지급대장 엑셀

우리 SIPOC은 다음과 같이 정리됐습니다. 중요한 것은 I(인풋)에 "실물 파일 이름"이 적혀 있다는 점입니다. "일정 정보"가 아니라 회사캘린더.xlsx의 일정표(2026) 시트라고 적어야 그다음 단계가 굴러갑니다.

가장 중요한 재설계는 "셀 하나에 사람이 알아서 적던 것"을 프로그램이 다룰 수 있는 형태로 바꾸는 일이었습니다. 구글 시트에서는 한 칸에 고객사·시간·장소·담당자 연락처가 자유 문장으로 섞여 있었습니다.

"강의 1건 = 하루 × 강사 1명"이라는 정의가 우리 시스템 전체를 지탱합니다. 이 단위가 있어야 개인별 실적(일수·시간·강사료)이 집계되고, 외부강사 지급행이 자동으로 생기고, 캘린더 칩이 그대로 정산 근거가 됩니다. 단위를 "프로젝트 단위"나 "회차 단위"로 잡았다면 전부 다시 만들어야 했을 것입니다.

진행 방식실물 자료에서 등장인물을 뽑아 테이블로 만듭니다. 완료 기준: 테이블마다 필드·연결·관계 종류가 적혀 있고, "이 구조로 답해야 할 질문"이 함께 적혀 있는가.

우리 설계의 핵심 판단은 프로젝트·계산서·강의가 서로 다른 단위라는 것을 인정한 데 있습니다. 한 프로젝트에 계산서가 2장 나가고 강의가 5건 있는 경우가 실제로 있었습니다. 이걸 한 테이블에 욱여넣으면 어느 쪽 기준으로도 집계가 안 됩니다.

고객사 (clients)
 └─ 프로젝트 (projects)      사업·계약 단위. 계약 총액(부가세 별도) 보유
     ├─ 계산서 (invoices)    전자세금계산서 발행 단위       [N:1]
     └─ 강의 (lectures)      하루 × 강사 1건                [N:1]

멤버 (members) ─→ 강의        내부 멤버 · 외부 강사
멤버 ─→ 지급 (payments)       외부 인건비 지급대장
일정 (events)                 미팅 · 휴가 · 기타 · 공휴일 (강의 외)

계산서와 강의를 직접 연결하지 않는다

둘 다 프로젝트에만 매답니다. 계산서 1장이 강의 3건에 대응하는지 5건에 대응하는지는 업무상 정해져 있지 않고, 억지로 연결하면 헷갈리기만 합니다. 대신 집계 규칙을 이렇게 정의했습니다.

백엔드는 위의 8개 테이블, 프론트엔드는 화면 목록으로 정리했습니다. 이 목록이 그대로 10회차 뒤의 좌측 네비게이션이 됩니다.

화면 10개 중 캘린더를 먼저 만든 이유는 세 가지 기준이 전부 거기서 겹쳤기 때문입니다.

진행 방식MVP 범위를 확정하고 구현합니다. 완료 기준: 인풋 → 아웃풋 한 사이클이 실제 데이터로 관통되는가.

그래서 2회차의 실제 작업은 "캘린더 화면 만들기"가 아니라 "이관 스크립트 + 캘린더 화면"이 되었습니다. 첫 이관 결과는 다음과 같았습니다.

즉 강의 756건 중 185건(24%)만 프로젝트에 붙었습니다. 나머지 571건은 "(미연결 강의)"라는 임시 프로젝트에 격리했습니다. 중요한 것은 버리지 않았다는 점입니다 — 전량을 DB에 적재하되 연결만 보류했습니다.

우리 아웃풋은 "화면"이 아니라 "옮겨진 데이터"였습니다. 그래서 지표도 데이터 정확도로 잡았습니다.

진행 방식측정값이 낮은 원인을 찾아 고치고, 같은 방법으로 다시 잽니다. 완료 기준: Before/After가 같은 지표로 비교되는가.

원인은 사람만 알던 규칙이 코드에 없다는 것이었습니다. 구체적으로 세 가지였습니다.

외부 강사에게 지급할 때는 소득세와 지방세를 떼야 합니다. 이 계산은 틀리면 안 되는 종류입니다. 처음 구현은 "원 단위 내림"이었고, 틀렸습니다.

측정을 하다 보면 "없다고 생각했던 것이 사실 있었다"는 발견이 나옵니다. 우리에게 그 순간은 셀 노트였습니다 — 1회차에서 본 캘린더 캡처의 붉은 삼각형이 그것입니다.

남은 화면은 프로젝트·강의·계산서·고객사·멤버·지급이었습니다. 이들은 겉보기엔 다르지만 전부 "목록 + 검색·필터·정렬·그룹 합계 + 상세 편집"이라는 같은 뼈대였습니다. 그래서 화면을 하나씩 만드는 대신 공용 DataTable을 만들고 컬럼 설정 파일만 화면마다 따로 두었습니다.

이 결정 덕분에 이후 회차에서 화면이 늘어나도 사용자가 새로 배울 것이 없었습니다. 한 테이블에서 익힌 조작이 일곱 테이블에서 그대로 통합니다.

3층 구조가 한 화면에서 만나는 곳 — 프로젝트 상세

진행 방식기능 목록 대비 구현 여부와, 화면에 뜬 값의 정확성을 따로 점검합니다. 완료 기준: 두 점검이 각각 기록으로 남았는가.

1회차 설계에서는 내부 멤버와 외부 강사를 별도 테이블로 두었습니다. 성격이 다르니 자연스러운 판단이었습니다. 그런데 쓰다 보니 문제가 드러났습니다 — 퇴사자입니다. 내부 직원이 퇴사하면 외부 강사가 되고, 그 사람의 과거 강의는 그대로 남아 있어야 합니다.

진행 방식인접 시스템(메일·파일·알림)으로 확장합니다. 완료 기준: 시스템 안에서 만든 산출물이 밖으로 나가 실제 업무를 대체하는가.

프로세스의 맨 앞(견적)이 아직 시스템 밖에 있었습니다. 5회차에 이걸 안으로 들였습니다.

진행 방식배포 대상 환경에서 실제로 빌드·동작하는지 확인합니다. 완료 기준: 로컬이 아니라 배포 환경 기준으로 통과했는가.

처음에는 요청을 가로채는 미들웨어 계층에 인증 게이트를 두었습니다. 로컬에서 7가지 시나리오 전부 통과했습니다. 그런데 배포용 빌드가 "이 방식은 지원하지 않는다"며 실패했습니다.

배포 전 상태로 동시 요청을 부어 봤습니다.

에러는 0인데 동시 요청 지연이 2.8초로 튀었습니다. 여기서 "느리니 최적화하자"로 가지 않은 것이 이 회차의 핵심입니다. 원인을 먼저 봤습니다 — 당시 로컬 DB가 요청을 한 줄로 세워 처리하는 종류였기 때문이고, 운영 환경의 DB로 바꾸면 사라지는 성질의 지연이었습니다.

함께 넣은 것은 기본 보안 헤더입니다 — 서버 종류를 알리는 헤더 제거, 콘텐츠 타입 추측 금지, 다른 사이트에 프레임으로 삽입 금지, 참조 주소 전달 제한. 코드 몇 줄이지만 안 하면 지적받는 항목입니다.

진행 방식시스템 설명서와 사용자 매뉴얼을 작성해 사용자가 찾을 위치에 둡니다. 완료 기준: 다음 사람이 이 문서만 보고 인수할 수 있는가.

진행 방식운영 환경으로 옮기고 실사용을 시작합니다. 완료 기준: 로컬 가정에 기대던 코드가 전부 걷혔는가.

실사용으로 넘어가면서 두 가지가 걸렸습니다. 둘 다 "로컬에서는 됐는데" 유형입니다.

실사용이 시작되면 운영 데이터가 진짜가 됩니다. 그런데 대량 수정은 로컬에서 하는 게 편합니다. 그래서 세 개의 명령을 만들었습니다.

diff   운영 ↔ 로컬 차이(추가·삭제·변경 건수)만 보여 줌 — 읽기 전용
pull   운영 → 로컬로 가져오기
push   로컬 → 운영으로 올리기

※ --force 를 붙이지 않으면 세 명령 모두 "미리보기"만 실행된다.
   실제로 쓰는 동작은 명시적으로 요청해야만 일어난다.

진행 방식실사용에서 나온 개선 요청을 데이터로 우선순위를 매겨 처리합니다. 완료 기준: 개선의 근거가 "요청받아서"가 아니라 "이렇게 쓰이고 있어서"인가.

쓰다 보니 같은 단어가 두 뜻으로 읽히는 문제가 드러났습니다. '수금유형'을 뜻하는 필드 이름이 '지급'으로도 읽혀서, 화면과 코드 양쪽에서 혼선이 났습니다.

캘린더에서 어떤 강의가 전날 칸에 나타나는 일이 있었습니다. 원인은 시간대였습니다 — 날짜를 저장할 때 한국 시각 자정이 세계 표준시로는 전날이 됩니다. 서버가 표준시로 계산하면 하루가 밀립니다.

진행 방식최종 시스템을 완성하고 효과를 정량화합니다. 완료 기준: 남은 이슈가 "무엇인지 아는 상태"로 정리됐는가.

발표에서 답해야 할 질문은 하나입니다. "무엇이 얼마나 좋아졌는가." 우리의 답은 세 갈래였습니다.