진행단계는 요구사항 [7][11]대로 13단계로 넣고, 진행상태(신청/진행중/완료)와
KPI 임계값을 attrs로 데이터화했다. 요구사항 [2](보고서가 올라와야 최종완료)는
completed 임계값을 13번에 두는 것으로 해결된다.
공공누리 유형은 scopes로 사용처(review/process/prior)를 구분한다. 세 화면의
목록이 7/5/6개로 달랐던 것이 실수가 아니라 자리 차이였기 때문이고, 이 구분 없이
합치면 권리처리 화면에 보류가 잘못 노출된다.
Co-Authored-By: Claude Opus 5 (1M context)
코드값을 소스가 아니라 데이터로 관리하기 위한 기반. 저장값은 지금 업무 테이블에
들어 있는 한글 문자열을 그대로 쓴다 - 영문 키로 바꾸면 기존 데이터 변환과 엑셀
양식 수정이 딸려와 위험 대비 실익이 없다.
설계서와 Phase 1 구현계획도 함께 넣는다.
Co-Authored-By: Claude Opus 5 (1M context)
서버에서 itnhub.env를 Windows에서 만들어 올리면 source 할 때 줄 끝 캐리지 리턴이
값에 그대로 붙는다. DB 비밀번호나 SERVER_PORT가 조용히 틀어지고 빈 줄에서는
command not found 가 뜬다. 캐리지 리턴을 걷어낸 사본을 만들어 읽도록 바꾼다.
원본 파일은 그대로 둔다.
alpine에서 bash -n, shellcheck, CRLF env 주입까지 확인했다.
Co-Authored-By: Claude Opus 5 (1M context)
Windows에서 작업하고 리눅스 서버에서 실행하는 파일인데, git이 체크아웃할 때 CRLF로
바꿔놓아 bash가 syntax error로 죽었다(shellcheck SC1017). .gitattributes로 *.sh 와
Dockerfile, compose 파일의 줄바꿈을 LF로 고정하고 기존 파일을 정규화한다.
ps1은 Windows 전용이라 CRLF로 둔다.
start.sh는 포트를 파일 위쪽 설정 블록의 APP_PORT=8877 로 끌어올려, 기동과 확인이
같은 값을 쓰도록 정리했다. env 파일에 SERVER_PORT가 있으면 그 값이 우선한다.
alpine 컨테이너에서 bash -n 과 shellcheck로 확인했다.
Co-Authored-By: Claude Opus 5 (1M context)
application.yml에 server.port가 없어 기본 8080으로 뜨고, 실행 스크립트마다 --server.port를
따로 넘기고 있어서 환경별로 포트가 달랐다. 앱 자체 기본값을 8877로 두어 어디서 띄우든
같은 포트가 되게 한다. SERVER_PORT 환경변수로는 여전히 덮어쓸 수 있다.
함께 맞춘 곳:
- Dockerfile EXPOSE / HEALTHCHECK, docker-compose 포트 매핑
- deploy/start.sh 기본값, itnhub.env.example (SERVER_PORT·TZ 항목 추가)
- vite 개발 프록시 대상(:8080 -> :8877). 이걸 안 바꾸면 npm run dev 에서 /api 가 죽는다
- run-local.ps1 은 --server.port 인자를 떼고 앱 기본값을 따르게 함
- README / deploy/README 의 포트 표기
로컬에서 재빌드 후 확인: 8877 /login 200, 8080 닫힘.
Co-Authored-By: Claude Opus 5 (1M context)
기능이 대폭 늘었는데 README는 기관 명부·채널 생성까지만 설명하고 있어 실제와 어긋났다.
대시보드·사업관리·시스템관리·권리확인/처리·도움말까지 반영하고, 읽는 순서대로 다시 배치한다.
- 화면 구성, 12단계 흐름, 최초 사용 순서를 표와 도식으로 정리
- 환경변수를 필수 8개와 기본값 있는 선택 2개로 나눠 표기
- 수정할 때 깨뜨리면 안 되는 약속(채널 2종, 재실행 안전, 채널⇔단계 불변식,
엑셀 재업로드 병합 규칙, 제3자 권리처리 정책, 연번 문자열)을 한 표로 모음
- 패키지·화면 구조와 API 목록, 배포(deploy/README.md 연결) 추가
Yona 렌더러에서 깨지지 않도록 GitHub 전용 문법(경고 블록, HTML 표) 대신
표준 마크다운만 쓴다.
Co-Authored-By: Claude Opus 5 (1M context)
멀티스테이지로 프런트(React)까지 이미지 안에서 빌드해 단일 jar로 만든다.
빌드 머신에만 인터넷이 필요하고(Node v20.17.0·npm·Maven 내려받음) 실행 서버에는
JDK도 Node도 깔 필요가 없다.
- 컨테이너 시간대를 Asia/Seoul로 고정한다. UTC로 두면 업무단계 도달 일시,
칸반 카드의 D+n, 연락 이력 날짜가 9시간 어긋난다.
- 비루트 사용자로 실행하고, actuator가 없으므로 헬스체크는 /login 200으로 한다.
- 이미지 빌드 중에는 테스트를 돌리지 않는다(-DskipTests). Testcontainers가 Docker를
다시 요구해 Docker-in-Docker가 되기 때문이며, 테스트는 CI에서 별도 단계로 돌린다.
- .dockerignore로 run-local.ps1을 제외한다(DB 비밀번호가 들어 있다).
deploy/는 192.168.0.176 운영 정의다. DB는 기존 192.168.0.60을 그대로 쓰므로 컨테이너로
띄우지 않고, 앱이 로컬 디스크에 쓰는 것이 없어(업로드는 DB와 Mattermost로 간다)
영속 볼륨도 두지 않는다. 실제 값은 서버의 /etc/itnhub/itnhub.env 에만 두고
저장소에는 .example만 남긴다.
로컬에서 이미지 빌드·기동까지 확인했다: jar 안에 static/index.html 포함, 컨테이너
시간대 KST, /login 200, HEALTHCHECK healthy, Flyway "schema itnhub: 12, up to date".
Co-Authored-By: Claude Opus 5 (1M context)
요청자 피드백 PPT 2건(기능확인 24쪽, 문정원 검토내용 17쪽)에서 확인된
요구를 다음과 같이 반영한다.
- 대시보드: KPI 7타일 + "단계 미지정" 포함 13컬럼 칸반(카드 드래그로 단계 이동)
+ 최근 진행 기관. 집계는 /api/dashboard 한 번으로 끝낸다 - 기관별로 건수를
반복 조회하면 화면 한 번에 150회 조회가 되기 때문이다.
- 사업관리: 3단계 대상 기관 현황, 신청 확인 연락 이력, 기관별 최종 보고서.
기관 현황 숫자는 대시보드와 같은 집계를 재사용해 두 화면이 어긋나지 않게 한다.
- 시스템관리: 채널 초기화(대상 미리보기 → 확인문구 입력 → 서버 재검사).
삭제가 아니라 보관(아카이브)이며 DB가 아는 채널만 대상으로 한다.
- 권리확인: 제3자 권리처리 정책변경 반영. "권리처리 추진 미희망"과 공공누리
"보류"를 신설하고, 처리결과에 따라 공공누리 유형·비고를 규칙대로 자동 채운다.
- 권리확인/권리처리: 일괄 등록·선택 삭제와 열별 조건 복합검색(AND).
- 업무메모: 작성자를 화면에서 고르지 않고 로그인 사용자를 서버가 기록하며,
수정 기능을 추가한다(작성자·작성시각은 유지).
- 기관관리: 채널에 고정된 최초 안내글을 확인하는 [최초 게시글 보기].
- 도움말: 주요 버튼 옆 (?) 모달 15개 항목. 실제 화면 캡처를 함께 담는다.
마이그레이션 두 건:
- V11 "채널 있음 <=> 단계 있음" 불변식을 맞추는 1회성 백필. 단계 기능(V8)
이전에 채널을 만든 기관이 칸반에서 사라지는 것을 막는다.
- V12 사업관리용 contact_log / org_report.
테스트: 백엔드 221건, 프런트 191건 전부 통과.
Co-Authored-By: Claude Opus 5 (1M context)
권리확인 탭과 같은 목록↔상세 구조로 권리처리 보드를 만든다. 상태 칩(전체/미처리/
처리완료)과 검색어로 목록을 필터링하고, 상세에서 계약서 유무를 체크박스 조합(+기타
직접입력)으로 관리하며 권리처리상태를 고르기 전에는 저장을 막는다. 기관 상세 헤더의
권리확인/권리처리 통계 카드도 각 탭의 완료·전체 건수를 실데이터로 보여주도록 연결한다.
권리확인 모듈을 참고해 권리처리 탭 전용 process_item 테이블과 CRUD API를 구성한다.
조사원+권리확인 영역은 재업로드마다 항상 최신 파일값으로 갱신하고, 계약서 유무와
권리처리 판정(공공누리유형/최종의견/판단근거/처리상태)은 웹에서 한 번이라도 수정하면
재업로드가 덮어쓰지 않는다. 처리완료 최초 도달 시각은 processed_at에 남기고 이후
재저장에도 값이 바뀌지 않는다.
기관별 권리확인 엑셀(Sheet0, ~1000행)을 업로드해 review_item 테이블에 반영하고,
조사원 항목은 항상 최신화하되 변호사 판정은 웹에서 한번 수정되면(web_edited_at)
재업로드가 덮어쓰지 않는 병합 정책을 적용한다. 목록/단건조회/판정저장/삭제/원본
서식 그대로의 엑셀 다운로드까지 REST로 제공한다.
기관의 신청기관/문정원/아이티앤/변호사 담당자가 채널 생성(또는 재확인) 시
이메일 기준으로 Mattermost 계정을 찾거나 새로 만들고, 문정원/법률검토 채널에
알맞게 추가하도록 ChannelProvisionService.ensureMembers 훅을 추가했다.
계정 생성 실패(아이디 중복 등)와 채널 추가 실패는 담당자별로 격리되어
provision 결과를 뒤집지 않고 메시지에만 남는다.
Co-Authored-By: ITN Dev
- STEPS 배열을 src/stages.ts(STAGE_LABELS)로 분리해 OrgOverview와 Timeline이 공유
- 업무단계 스트립: 완료(체크)/진행중/미래 상태 표시, 현재 단계 클릭 시 확인 후 다음 단계로 진행
- [진행단계 변경] 버튼을 활성화해 12단계 중 하나를 바로 골라 변경하는 모달 추가
- Timeline 컴포넌트: 단계변경/업무메모/자료등록 이벤트를 날짜별로 묶어 시간순으로 표시
- 관련 컴포넌트 테스트 fixture에 stage 필드 추가
- V8 마이그레이션으로 organization.stage와 stage_history 테이블 도입
- PUT /api/orgs/{id}/stage: 1..12 범위 검증 후 단계 변경 + 이력 적재
- 채널 2개가 처음 모두 갖춰지면 진행단계 1(신청)을 자동 시작(재실행 안전)
- GET /api/orgs/{id}/timeline: 단계 이력·업무메모·채널 첨부파일을 최신순으로 합쳐 제공
(Mattermost 조회 실패는 채널별로 흡수하고 200 유지)
