코덱스(Codex)로 사내 B2B 교육 ERP 점검을 3일 동안 하면서 메모·문서·견적·교육 일정의 저장 규칙을 정리했습니다. 파일 111개를 고친 PR은 사내 개발자 검토를 거쳐 2026년 10월 29일 운영에 반영됐어요.
새 기능을 붙이기보다 팀원이 덜 헷갈리게 줄이는 쪽을 고른 과정, 그때 쓴 판단 기준, 실제로 바뀐 사례를 순서대로 적었습니다.
흩어진 ERP 기록을 저장 위치 하나로 3일 만에 정리했다는 제목과, 업무 시스템 화면을 가리키는 고양이 캐릭터
문제의 원인은
저장 규칙 부재였어요
ERP에 기능이 없어서 불편한 게 아니었습니다. 같은 정보를 사람마다 다른 곳에 저장하는 게 문제였어요.
저희 팀은 교육 프로젝트마다 일정, 견적, 문서, 고객 요청을 ERP에 남깁니다. 팀원이 직접 쓰기도 하고, 각자 쓰는 AI가 MCP로 기록하기도 해요. 그러다 보니 이런 일이 쌓였습니다.
메모 탭에 메일 원문과 자동 저장 로그가 계속 쌓임
강사 비고에 강사와 상관없는 자료가 들어감
교육세션 날짜를 바꿔도 프로젝트 교육기간은 그대로
견적서와 문서가 이전 버전인지 최종인지 구분되지 않음
저는 지피터스 B2B 교육팀에서 일하는 AX Consultant 한가경입니다. 이 ERP는 제가 클로드 코드(Claude Code)와 코덱스로 커밋 340여 건을 직접 올려 온 사내 시스템이에요(GitHub 기여 기록 기준).
Codex로 실제 화면과
코드를 함께 진단했어요
2026년 10월 27일 오전, 코덱스 데스크톱 앱에 처음 보낸 요청은 정리된 기획서가 아니었습니다. 눈에 보이는 증상을 그대로 적었어요.
ERP 점검하는 게 필요해 보여. 맥락 관리를 우리 팀 사람들이 하고 있는데
메모 탭에 불필요한 정보가 쌓이거나, 교육세션 기간에 맞게 교육 일정이
자동 수정 안 되거나, 문서가 다른 곳에 가거나, 견적서가 활성화 안 된 게 있어.
전반적인 점검이 필요한데 어디서부터 손대야 할지 모르겠네.
이미 로그인된 크롬으로 실제 화면과 코드를 같이 보게 했습니다. 기획서를 먼저 쓰면 제가 아는 문제만 고치게 되는데, 증상을 주면 AI가 화면과 코드를 오가며 원인을 묶어 와요.
증상을 원인별로 묶는 일은 AI에게, 무엇을 고칠지는 제가 정했습니다. 네 가지 증상의 원인은 결국 하나였어요. 정보마다 어디에 저장할지 정한 규칙이 없었던 거죠.
정보 유형별로
저장 위치를 단일화했어요
그래서 이번 점검의 원칙은 정보 하나에 저장 위치 하나였습니다. 이 그림이 이번 PR의 요약이에요.
전후 비교. 왼쪽은 메모 탭 하나에 메일 원문, 일정 변경, 견적 v2, 자동 로그가 뒤섞여 넘치는 모습. 오른쪽은 세션, 메모, 개요, 문서, 견적 서랍으로 나뉜 서류장
실제로 바뀐 모습은 이렇습니다.
교육 날짜: 전에는 교육세션 날짜를 옮겨도 프로젝트 기간은 예전 날짜로 남아 목록과 대시보드가 어긋났어요. 이제 세션을 저장하면 기간이 따라옵니다.
메모: 전에는 메일 원문과 초안 재작성 같은 자동 로그가 쌓였어요. 이제 "변경 | 3일차 분반 시간을 예약 시간에 맞춤 (고객 메일)"처럼 결정과 이유만 남깁니다. 이 형식은 ERP가 저장할 때 직접 검사해서, 어긋나면 웹이든 AI든 저장이 거절되고 올바른 예시를 돌려줘요(10월 29일 반영).
문서와 견적: 덮어쓰기 대신 버전 이력으로 관리하도록 바꿨어요. 아래에서 따로 설명할게요.
팀원은 이 그림대로만 쓰면 됩니다. 개인 AI(Claude, Codex 등)를 쓰는 분은 새 세션을 열거나 ERP MCP를 다시 연결해야 새 규칙이 적용돼요.
문서·견적에
버전 이력 관리를 적용했어요
문서와 견적은 덮어쓰기 대신 버전 이력으로 관리하도록 바꿨습니다. 옛 일정이나 옛 금액이 다시 쓰이는 사고를 막으려는 거예요.
문서와 견적의 버전 관리. 문서는 현재본 앞에 이전 v2, 이전 v1이 겹쳐 있고 보관 상자가 따로 있음. 견적 v2 하나가 1차수, 2차수, 3차수 프로젝트로 나뉘어 배분됨
문서는 이렇게 바뀌었어요.
문서마다 현재본, 이전 버전, 보관 세 가지 상태가 있습니다. 목록에는 현재본만 보이고 이전본은 따로 찾아볼 수 있어요.
링크나 파일을 바꾸면 기존 문서를 고치지 않고 새 버전이 생깁니다. 파일 이름이 같다고 구판을 지우지 않아요.
현재본을 보관해도 이전본이 저절로 올라오지 않습니다. 다시 쓰려면 사람이 현재본으로 지정해요.
견적은 한 걸음 더 나가서, 견적 하 나를 여러 프로젝트가 나눠 쓰는 경우까지 다뤘습니다.
같은 견적을 고치면 v1, v2처럼 버전이 쌓입니다. 예전 내용으로 되돌리는 것도 새 버전으로 남아요.
단가 계약처럼 견적 하나를 여러 차수가 나눠 쓰면, 견적 하나에 프로젝트 여러 개를 연결하고 프로젝트마다 배분금액을 적습니다. 전에는 견적이 프로젝트 하나에만 붙어서 차수마다 같은 견적을 따로 등록해야 했어요.
배분금액이 비어 있는 프로젝트는 합계에서 빼고 미배분으로 표시합니다. 같은 금액이 여러 번 더해지지 않게요.
기존 데이터도 같은 기준으로 정리했어요. 미확정으로 보이던 견적 20건을 입금 내역과 대조해 보니 17건은 최종본이 따로 있는 이전안이나 대안이었습니다(개발자 대조 결과). 그중 13건은 보관하고, 근거로 쓰는 단가표 4건과 나머지 3건은 남기기로 했어요.
작업 범위는
세 가지 기준으로 정했어요
작업 중에 고를 일이 생기면 세 가지를 물었습니다. 이 질문이 범위를 줄여 줬어요.
팀원이 확인할 일이 늘어나는가?
사람이 확인해야 하는 값인가? (일정, 금액)
이미 저장된 데이터로 풀 수 있는가?
1번이 바로 걸린 순간이 있었습니다. 코덱스가 기간이 안 맞는 프로젝트와 메모에 섞인 자료를 찾아 주는 팀원용 점검 화면을 새로 만들자고 했거든요. 저는 이렇게 되물었어요.
근데 기간 불일치나 메모·강사 비고에 섞인 자료를 찾아보는 점검 화면을
추가하는 게 과연 좋을까? 더 복잡해지는 것 같기도.
코덱스도 기능을 추가하는 쪽으로 과하게 잡았다고 인정했고, 별도 화면은 뺐습니다. AI가 기능을 더하자고 할 때 빼는 판단은 결국 사람 몫이었어요.
3일 동안 누가 무엇을. 10월 27일 AI가 점검과 수정, 제가 점검 화면 빼기. 10월 28일 개발자가 오류 4건 수정, 제가 판단 질문 5건 답. 10월 29일 개발자가 머지와 운영 반영, 제가 맥북 자동화 맞추기
교육 메일은
스레드 단위로 연동했어요
2번과 3번 질문은 교육 메일 연동에 그대로 적용했습니다. 고객 메일 내용이 ERP에 늦게 들어오거나 답장마다 메모가 쌓이던 문제예요.
메일 한 통이 반영되는 순서. 1 고객 메일 도착, 2 연락처로 프로젝트 찾기, 3 봇이 변경안 제안, 4 사람이 확인 후 반영
프로젝트 연결은 제가 낸 아이디어였습니다. 매번 사람이 프로젝트를 고르면 번거로운데, 고객 담당자 연락처는 이미 ERP에 다 저장돼 있었거든요. 한 담당자가 교육 여러 개를 맡고 있으면 후보로만 남깁니다.
지난주에 실제로 받은 메일로 설명해 볼게요. 4일 과정 고객사가 예약한 분반 시간이 지난 차수와 반대로 잡혀 있었습니다. 지금까지는 제가 메일을 읽고 회신 초안과 ERP 메모를 직접 정리했어요. 앞으로는 사내 슬랙봇 비투비서가 "분반 시간이 예약과 다름"을 근거 문장과 함께 제안하고, 시간표는 담당자가 확인한 뒤 고칩니다.
비투비서 분석 예약(15분마다, 한 번에 메일 최대 3개 비교)은 먼저 돌아가고 있고, 메일 수집은 서버 연결을 마무리하는 대로 바로 시작합니다.
개발자 리뷰에서는
업무 기준을 결정했어요
PR을 올리기 전에 Claude와 Codex가 서로의 코드를 교차 검토했고, 자동 검사 13묶음과 배포 빌드를 통과시켰습니다(PR 기록 기준). 그다음 사내 개발자 하영님께 검토를 부탁했어요.
하영님은 오류 4건을 직접 고쳐 주시고, 업무 판단이 필요한 질문 5건을 남겼습니다(슬랙 검토 스레드 기준). 코드 설명은 클로드 코드에게 물어서 이해했고, 답은 업무 기준으로 정했어요.
현재본 문서를 보관하면 이전본을 자동으로 올릴까요? 아니요. 오래된 일정이나 금액이 다시 쓰일 수 있어서 사람이 골라서 올립니다.
프로젝트에 연결 안 된 메일 원문은 누가 볼까요? 비투비서와 지정 관리자만 봅니다.
개인 API 키로 고친 기록은요? 키 주인의 ERP 계정에 연결하고, AI로 고쳤다는 표시도 남깁니다.
코드는 몰라도 업무 기준은 제가 제일 잘 알았습니다. PR은 10월 29일 오전 머지되어 운영에 반영됐어요.
검토 후속으로 제 맥북 자동화도 같은 규칙에 맞췄습니다. 그 ERP에 기록하던 자동화 6개를 새 규칙과 대조했어요.
문서 업로드: 구판을 지우던 방식에서 새 버전으로 등록하는 방식으로
강사 회신 추적: DB에 직접 쓰던 방식에서 ERP API를 거치는 방식으로. 필요한 API는 하영님이 같은 날 추가했고, 사람이 고친 강사 배정과 비고를 자동화가 덮어쓰지 않게 막는 보완은 검토를 기다리고 있어요.
다음 할 일 자동 갱신: 만들어 두고 실제로는 안 보게 돼서 이번에 중지
마지막 건이 제일 아팠습니다. 직접 개발해 보고 싶었던 기능인데 효용을 못 느꼈거든요. 안 쓰는 자동화는 끄는 것도 정리라고 생각했어요.
사내 시스템 점검을
따라 하는 5단계
숫자로 보면 2026년 10월 27일부터 29일까지 3일 동안 파일 111개, 커밋 15개짜리 PR을 만들어 개발자 검토를 거쳐 운영에 반영했습니다(GitHub PR 기록 기준). 제가 한 일의 대부분은 코드를 쓰는 것보다 범위를 줄이고 업무 기준을 정하는 쪽이었어요.
사내 시스템을 AI로 점검하고 싶다면 이 순서를 추천합니다.
기획서 대신 눈에 보이는 증상을 그대로 적어 줍니다.
AI가 실제 화면과 코드를 같이 보게 합니다. 이미 로그인된 브라우저를 쓰면 편해요.
원인을 묶은 뒤 정보마다 저장 위치 하나를 정합니다.
새 화면이나 메뉴를 추가하자는 안은 세 가지 질문으로 거릅니다.
개발자 검토에서 나온 판단 질문에는 업무 기준으로 답합니다.
바로 쓸 수 있는 프롬프트
[시스템 이름] 점검이 필요해 보여. 팀원들이 [기록하는 곳]에 정보를 쌓는데 [증상 1], [증상 2], [증상 3] 같은 일이 생겨.
실제 화면과 코드를 보고 원인을 묶어서 알려줘. 정보마다 저장 위치를 하나로 정하는 안을 먼저 주고, 새 화면이나 메뉴는 꼭 필요할 때만 제안해 줘. 일정이나 금액처럼 사람이 확인해야 할 값은 따로 표시해 줘.
[대괄호]는 본인 상황에 맞게 바꿔 쓰세요.
지피터스가 사내 AX를 어떻게 하는지는 지피터스는 사내 AX를 어떻게 할까에 모아 두었어요.
