배경:
- frontend build 의 가장 큰 시간 소비 = runner stage 의 COPY node_modules (12분 16초)
- 전체 21분 34초 중 57%
- next.config.mjs 의 output: "standalone" 가 prod 빌드에서 이미 활성 상태였으나, Dockerfile 의 runner stage 가 .next 통째 + node_modules 통째를 COPY 하느라 standalone 결과물 미활용
조치:
- runner stage 재작성:
- .next 전체 → .next/standalone (server.js + 실제 사용 node_modules)
- .next/static 별도 COPY (standalone 가 자동 포함 안 함)
- public 별도 COPY (standalone 가 자동 포함 안 함)
- node_modules 통째 COPY 제거 (standalone 가 알아서 포함)
- package.json COPY 제거 (server.js 직접 실행)
- CMD: npm start → node server.js
검증:
- frontend 에 dynamic require/import 0건 (정적 import 만) → standalone 의존성 추적 정확
- prisma 가 package.json 에 있으나 코드 import 0건 → 자연 제외, 추가 설정 불필요
예상 효과:
- 빌드 시간 21m 34s → 약 9분 (12분 단축, 57% 감소)
- 이미지 크기 약 1GB → 약 300MB (70% 감소)
- pull 시간 단축
- runtime memory footprint 감소
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
main 의 최근 8연속 build 실패 (run 113~120) 원인이 docker build 단계의 OOM Killed.
진단:
- wace 호스트 32GB / available 24GB 충분, 시스템 OOM 기록 없음
- act_runner systemd MemoryMax=infinity, config container.options=null (제한 없음)
- 그러나 Next.js build V8 heap spike (5-8GB+) 가 다른 30개 동시 가동 서비스 (k3s/mailu/nextcloud/mattermost 등) 와 충돌
- Committed_AS 21.6 GB / Limit 24.8 GB 한계 — page touch 시 oom-killer 가 build process kill
- 결과: 28분 빌드 후 Killed → 8연속 main 배포 실패
조치:
- builder stage 에 NODE_OPTIONS=--max-old-space-size=4096 명시 → V8 heap 4GB 로 cap
- build process 가 알아서 절제 → OOM killer 트리거 안 됨
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
빌드 컨텍스트 변경에도 운영 frontend chunk 에 신규 라우트가 들어가지
않는 증상 발견. Kaniko/Docker layer cache 가 npm run build 단계를
잘못된 시점에 hit 하는 것으로 의심. GIT_SHA build-arg 를 npm run build
직전에 주입해 매 commit 마다 그 layer 부터 강제 invalidate.
또 진단 step 에 deploy 이미지 tag 표시 추가 — 새 image 로 갱신
됐는지 즉시 확인 가능.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
운영 도메인이 실제로는 v1.invyone.com / solution.invyone.com / api.invyone.com 인데
코드/문서 곳곳에 v1.invion.com / api.invion.com 등 미존재 도메인이 박혀 있어 정리.
변경 파일 (21):
- frontend lib/api/client.ts, lib/utils/apiUrl.ts: hostname 체크 endsWith(\".invyone.com\") 일반화
- frontend lib/api/dashboard.ts, file.ts, flow.ts, FileViewerModal*2.tsx: 도메인 치환
- frontend invion-layout-v5.html: 시안 내 placeholder 도메인 정리
- backend-spring SecurityConfig.java: CORS 주석 예시 정리
- docker/deploy/docker-compose.yml, k8s/traefik-dynamic.yaml: traefik Host 라벨 정리
- scripts/prod/deploy.sh: 안내 메시지 정리
- .cursor/rules/api-client-usage.mdc, project-conventions.mdc: AI 가이드 정리
- docs/* 4개: 아키텍처/플로우 문서 도메인 정리
- notes/gbpark/* 3개: 과거 메모 정리
신규:
- docs/DOMAIN_MAPPING.md: 운영/개발/폐기 도메인 영구 기록.
AI 에이전트와 신규 개발자가 헷갈리지 않도록 단일 진실 출처.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- application.yml, k8s configmap, docker-compose 4종: SPRING_DATASOURCE_URL path
- provisioning 코드: {prefix}_vexplor → {prefix}_invyone 테넌트 DB 네이밍 규칙
- 프론트 마법사: Step1Basic, Step4Run 미리보기 라벨
- CompanyAccordionRow: 기본 DB 이름 포맷
- 마이그레이션/멀티테넌시 문서 동기화
- Traefik 와일드카드 설정 산출물 보관 (notes/)
비밀번호(vexplor0909!!) 및 역사 기록 문서(INVYONE_CONCEPT,
DDD1542, test-output, dashboard-runtime-fixes) 는 의도적으로 미변경.
- Added a new controller for managing process work standards, including CRUD operations for work items and routing processes.
- Introduced routes for fetching items with routing, retrieving routings with processes, and managing work items.
- Integrated the new process work standard routes into the main application file for API accessibility.
- Created a migration script for exporting data related to the new process work standard feature.
- Updated frontend components to support the new process work standard functionality, enhancing the overall user experience.
johngreen
Johngreen
gbpark