01 프롤로그 — EPC Control 과 1차 저장소: 도구 하나에서 그릇까지

뒷이야기 · 1 / 17단계 · 2026-04-09 ~ 05-22 (이후 7/1 까지 40일 공백) · 갈래 SJ FLOW
다음 단계: 02 SJ FLOW v2 ① — 기반 공사

핵심 요약

한 줄 요약 — 도구는 5월 내내 빠르게 자랐고 저장소는 두 시간 만에 만들었지만, 여럿이 같이 쓰게 만드는 일(로그인·공용 DB)은 그날 하지 못하고 40일 뒤로 밀렸다.

1단계 · 프롤로그 — EPC Control 과 1차 저장소

목적

세종기술 SJ FLOW(사내 협업 플랫폼)는 2026년 7월에 새로 시작한 것처럼 보이지만, 그 전에 도구 하나가 먼저 있었다. EPC Control 이다. EPC(설계·구매·시공을 한 회사가 맡는 플랜트 사업)의 일정표(WBS, 작업 분해 구조), 간트차트(막대로 보는 일정), 검사 계획(ITP), 부적합(NCR) 현황을 한 화면에서 보려고 만든 단일 HTML 도구다. crazy4eu(cwkim83)가 만들었다.

문제는 하나였다. 파일 한 장이라 사람마다 자기 PC 에서만 열린다. 한 사람이 만든 도구를 여럿이 같이 쓰는 플랫폼으로 키우려면 도구를 담을 그릇부터 필요했다. 이 단계는 그 그릇을 처음 만든 날까지의 기록이다.

만든 순서

1 · 4월 9~10일 — 이틀에 파일 30개 (4/9 ~ 4/10)

받은 폴더에 EPC 관련 HTML 이 4/9 에 6개, 4/10 에 24개, 모두 30개 남아 있다. 첫 파일은 4/9 09:14 의 epc_integrated_system.html(604줄, 50,106바이트)이다. 이름은 epc_integrated_v4 에서 v14 까지 번호를 올렸고, 4/10 11시 무렵 EPC_Control_System_v15 로 이름이 바뀌어 v23 까지 이어졌다. 같은 번호를 다시 받은 사본이 섞여 있어 판 수와 파일 수는 같지 않다.

이 시기는 서버도 설치도 없었다. HTML 파일을 열면 끝이었고, 고쳐서 바로 시험할 수 있었다. 대신 저장도 공유도 안 됐다. 이 시기의 근거는 파일 이름·크기·받은 시각뿐이다. 판마다 무엇을 왜 바꿨는지 적은 기록은 남아 있지 않다(확인 못 함).

2 · v26.3 — 932줄 기준선 (4/24 ~ 4/27)

v26 계열 파일은 4/24 에 3개, 4/27 에 2개 받았다. 그중 v26_3 이 이후 모든 판의 비교 기준(기준선)이 됐다. 932줄에 분할·트리·간트 세 가지 보기, 사이드바, 수정 패널, 모달(팝업 창), 오른쪽 아래 AI 채팅창이 이미 있었다.

여기서 문서 숫자를 하나 바로잡는다. CHANGELOG(변경 이력)와 이후 이력 문서는 이 판을 "932줄 / 99KB"라 적었다. 파일을 직접 재면 932줄은 맞고 크기는 89,164바이트(약 89KB)다. 99KB 는 틀린 값이다.

이 판에는 브라우저 저장소(localStorage)를 쓰는 줄이 0개였다. 저장 기능은 다음 판들(v27.0·v28.0)에서 들어온다.

채팅창의 모양도 눈에 띈다. 이 판의 AI 채팅은 브라우저에서 Claude 모델 API 를 직접 부르는 코드였고(api.anthropic.com 주소가 파일에 한 번 나온다), 파일 안에는 키가 없었다. 키 없이 실제로 동작했는지는 확인하지 못했다. AI 키를 어디에 둘 것인가는 이 도구의 첫 판부터 풀어야 할 문제였고, 3단계의 게이트웨이까지 이어진다.

3 · v27.0 을 버리고 v28.0 은 고쳐 쓰다 (5/21)

5/21 에 화면 틀을 새로 짠 v27.0(948줄, 69,585바이트)이 나왔다. 파일 안 주석이 "v26.3 대비 변경 사항" 여덟 가지를 적는다. localStorage 자동 저장·복원, JSON 내보내기/가져오기, 엑셀처럼 열을 고정한 3단 WBS 배치, 다년도 달력, 진도율 색, 열 폭 조정, ▲▼ 버튼 이동, 하단 주간 자동 정리 패널이다. CHANGELOG 는 이 판을 같은 날 폐기했다고 적는다. 사유는 "UI 지적 6가지 발생 → v28.0 으로 재빌드"다. 여섯 가지가 무엇이었는지는 기록이 없다(확인 못 함).

대신 v28.0 은 새로 짜지 않고 v26.3 에 "외과수술식 패치"를 했다. 원본은 1줄도 지우지 않고 7개 영역만 고쳤다는 것이 CHANGELOG 의 설명이다. 간트 막대에 진척률 채움, 주간 자동 정리 패널(진행 지연·부적합·이번 주 완료·차주 시작 4분면), JSON 내보내기/가져오기, localStorage 자동 저장(0.4초 디바운스: 입력이 멈춘 뒤 저장), 다년도 달력이다. 목록을 견주면 v27.0 이 시도한 기능과 대부분 겹친다. 같은 기능을 v27.0 은 화면 틀을 새로 짜면서, v28.0 은 원본 위에 얹으면서 넣은 셈이다. 폐기된 것은 기능이 아니라 화면 틀 쪽이었다고 읽힌다(사유 여섯 가지의 내용은 모르므로 추정이다).

v28.0 파일은 받은 폴더에 없어서 "1줄도 안 지웠다"를 직접 확인할 수는 없다. 대신 다음 판 v28.1 과 비교했다. v26.3 의 비어 있지 않은 931줄 중 894줄(96%)이 같은 모양으로 남아 있고 37줄이 바뀌거나 사라졌다. 그 37줄 가운데 29줄이 v28.1 에서 일부러 뺀 AI 채팅창(모양·상태·전송 함수)이고, 나머지 8줄은 머리줄·날짜 상수·표 그리기 줄이다. 새로 짜서 버린 쪽이 아니라 고쳐 쓴 쪽이 살아남았다.

4 · v28.1 — AI 검사 어시스턴트를 뺐다 (5/22)

v28.1 은 5/22 판이다. 화면 폭에 따라 달력이 6~15칸으로 자동 조정되는 반응형 달력, 한 줄 헤더 라벨, 중복 ▲▼ 버튼 제거가 들어갔다. 그리고 하나를 뺐다. 오른쪽 아래 AI 검사 어시스턴트다. CHANGELOG 가 적은 이유는 한 줄이다. "Cowork 트리거가 대체". Cowork(클로드의 예약·자동화 도구)가 같은 일을 하기로 했다는 뜻으로 읽힌다. 그 이상은 CHANGELOG 에 적혀 있지 않다.

뺀 기능은 이런 모양이었다. WBS·ITP 현황을 묻는 채팅창에 "NCR 현황", "WBS 지연", "ITP 미완료" 빠른 질문 버튼 3개가 달려 있었다. 5/27 에 받은 판에는 이 코드가 0줄이다.

이 기능은 43일 뒤인 7/4 15:34 에 돌아온다. 이번에는 플랫폼 전체 데이터를 묻고, 폼을 채워 주되 "직접 저장하지 않는" AI 비서 위젯이었다(커밋 3ebdf74). 3단계에서 이어진다.

5 · 5월 22일 — 그릇을 두 시간 안에 (10:45 ~ 12:38)

5/22 오전 10시 45분 39초에 GitHub 조직(sejong-21c)에 저장소 sejong-platform 을 만들었다. 첫 커밋은 1초 뒤인 10시 45분 40초, 마지막 커밋은 12시 38분 12초다. 그 1시간 52분 32초 동안 커밋 10개를 올렸다. 열 개 모두 커미터(저장 기록을 남긴 주체)가 GitHub 이라 웹 화면에서 직접 올린 것이다. 작성자는 모두 cwkim83 이다. 올린 파일은 8개였다.

• 설명서: README, core/README(공통 기반 안내), 설계서 docs/architecture.md(5,202바이트), 로드맵 docs/roadmap.md(4,868바이트)
• 도구: modules/quality/epc-control/ 의 v28.1 본체(1,149줄, 100,219바이트) · CHANGELOG · README, 그리고 메인 메뉴 index.html

설계서는 원칙 네 가지를 세웠다. ① 모놀리식 우선: 도구마다 저장소를 따로 만들지 않고 한 저장소 안 폴더로 나눈다. 권한·승인·로그인을 한곳에서 관리하려는 이유다. ② EPC 가 중심: 다른 도구는 EPC 가 정한 데이터 구조를 따른다. ③ 단계적 확장: 한꺼번에 만들지 않고 써 보고 필요한 것만 만든다. ④ 반응형 우선: 모바일부터 8K 모니터까지. 구조는 3층이었다. 코드·호스팅은 GitHub, 실시간 데이터는 Firebase Realtime Database(클라우드 실시간 DB), 파일은 NAS 와 구글 드라이브.

로드맵은 Phase 1~5 였다. 1) 그릇 + EPC 안착(5월) 2) 품질관리부 도구 통합(1~2주) 3) 실사용·문제점 수집(1개월) 4) 권한·승인 정식 구현 5) 타 부서 확장(6개월~1년).

6 · 40일의 공백 — 저장소는 멈췄고 도구는 계속 자랐다 (5/22 ~ 7/1)

Phase 1 의 할 일은 10개였다. 그날 체크된 것은 4개(조직 생성 · 저장소 생성 · 폴더 구조 · 문서 작성)였다. 남은 6개는 v28.1 업로드(문서를 올리고 4분 뒤 본체를 올렸다), GitHub Pages 켜기, Firebase 프로젝트 만들기, v28.2 패치(Firebase 연동), 시범 운영, 매일 22시 자동 백업이었다. 완료 기준은 "WBS 수정 시 다른 사람 화면에 0.3초 안에 반영"이었다.

1차 저장소는 그 뒤로 커밋이 하나도 늘지 않았다. 브랜치는 main 하나, 마지막 push 는 5/22 12:38 이다. 새 저장소 sejong-platform-v2 가 만들어진 7/1 09:25 까지 달력으로 40일이다.

그 40일 동안 도구가 멈춘 것은 아니다. 5/27 에 받은 파일 3개가 남아 있다. 가장 작은 것이 2,911줄(199,085바이트)의 v28.4.17 이다. v28.1 의 1,149줄이 닷새 만에 2.5배가 됐다. 7/1 에 새 저장소에 올라간 WBS 본체는 4,148줄이다. CHANGELOG 의 향후 계획과 실제도 달랐다. 계획에서 v28.2 는 Firebase 연동, v28.3 은 ITP 연동이었다. 실제 v28.2 는 워크오더 자동 등록, v28.3 은 가져오기 자동 채움이었다(7/1 업로드 파일의 코드 주석). Firebase 연동은 7/1 에 했고, 계획했던 Realtime Database 가 아니라 Firestore 로 갔다.

왜 멈췄는지는 어느 문서에도 적혀 있지 않다(확인 못 함). 적혀 있는 사실은 셋이다. 1차 저장소는 Phase 1 의 나머지 항목에 닿지 못했다. 도구는 계속 개발됐다. 7/1 에 새로 시작하며 가장 먼저 한 일이 바로 그 미완 과제였다.

7 · 다음 단계로 — 7월 1일 아침 (7/1 09:25)

새 저장소 sejong-platform-v2 가 7/1 09:25 에 만들어졌고, 2분 뒤 09:27 에 파일 6개 13,390줄이 올라갔다. 두 번째 시도의 시작이다. 2단계로 이어진다.

💡 설명

• EPC Control: 플랜트 사업의 일정·검사·부적합 현황을 한 화면에 보여 주는 단일 HTML 도구. 이 기록의 출발점.
• WBS(작업 분해 구조): 큰 일을 작은 작업으로 쪼개 표로 만든 일정표. 간트차트는 이 표를 막대로 그린 그림.
• ITP · NCR: 검사·시험 계획서(ITP)와 부적합 보고서(NCR). 품질관리부가 가장 많이 다루는 두 문서.
• 단일 HTML: 서버·설치 없이 파일 한 장으로 돌아가는 웹 화면. 빠르게 만들지만 저장·공유가 안 된다.
• localStorage: 브라우저 안에 작은 글자를 남기는 저장소. 그 PC 의 그 브라우저에서만 보인다.
• 기준선(baseline): 이후 판들을 견주는 기준으로 정한 판.
• 외과수술식 패치: 원본을 새로 짜지 않고 필요한 곳만 정확히 고치는 방식.
• 디바운스: 입력이 멈춘 뒤 잠깐 기다렸다가 한 번만 저장하는 방식. 키를 칠 때마다 저장하지 않으려는 장치.
• 저장소(repository) · 커밋 · push: 코드와 그 변경 이력을 보관하는 곳, 변경 한 번을 기록한 단위, 그 기록을 서버(GitHub)의 저장소로 올리는 일.
• Phase(단계): 로드맵을 시간 순서로 나눈 묶음. 여기서는 1~5 단계.
• Firebase · Realtime Database · Firestore: 구글의 클라우드 서비스와 그 안의 실시간 DB 두 종류. 계획은 앞의 것, 실제는 뒤의 것.

함정과 배운 것

• 파일 한 장 도구는 빨리 자라지만 저장과 공유가 안 된다. 도구가 쓸 만해지는 순간 그릇과 로그인이 필요하다.
• 그릇만 만들고 연결(로그인·DB)을 남기면 멈춘다. 그날 끝낸 Phase 1 항목은 10개 중 4개였다. 다음 저장소는 남은 과제부터 풀었다.
• 새로 짜기(v27.0)보다 고쳐 쓰기(v28.0)가 살아남았다. 잘 돌아가는 줄은 건드리지 말고 필요한 곳만 고친다.
• 뺀 기능의 이유를 변경 이력에 적어 둔 덕분에 되살릴 때 맥락이 남았다("Cowork 트리거가 대체").
• 문서에 옮긴 숫자는 틀린다. 크기 99KB 는 실제 89KB 였다. 파일에서 직접 센다.
• 계획 문서의 "향후 계획"란은 실적이 아니다. v28.2 는 Firebase 연동이라 적혀 있었지만 실제로는 다른 기능이었다.

출처

• 커밋(1차 저장소 sejong-platform, 10개): 581ccbd · 909b112 · 23b5712 · 6123950 · 7307eb9 · 4f380e1 · f0b7be8 · ab381e6 · 8b21db5 · c45f7e2
• 커밋(sejong-platform-v2): b38dee0 · a31fb9b · 3ebdf74 · 338fe6d · c348c1a(이력 문서에 1차 저장소 반영)
• 문서: sejong-platform-v2 PROJECT-HISTORY.md §0 · 1차 저장소 CHANGELOG.md · docs/roadmap.md · docs/architecture.md
• 파일: 받은 폴더의 EPC 관련 HTML(이름·크기·받은 시각)
• 기억 노트: build-log-room · log-site

02 SJ FLOW v2 ① — 기반 공사 →