msp-work-record

Imported from wingunkh/multica-skills (skills/msp-work-record/SKILL.md). Install upstream with npx skills add wingunkh/multica-skills --skill msp-work-record. Copyright stays with the author.

MSP 업무 기록 정리

스킬 버전: 1.2.0

목적

이 기록은 요약이 아니라 정리다. 기관별 주간보고에서 여러 담당자가 함께 보고, 나중에 "그때 무엇을 확인하고 무엇을 안내했는지" 되짚는 근거가 된다. 그래서 짧게 줄이는 것보다 요청, 확인 사실, 안내한 선택지, 조치 결과, 후속 필요사항을 따로 추적할 수 있게 나누는 것이 더 중요하다.

• 결론은 먼저 쓰되, 확인·조치·후속의 세부 경로와 조건을 한 줄로 뭉개지 않는다.
• 확인 경로, 접근 방법, 플랫폼명, 솔루션명, 담당 주체, 제약 사항은 생략하지 않는다.
• 줄여도 되는 것은 원시 데이터 나열(파일 크기, 파일별 속성 시각, 반복 로그)뿐이며, 이것도 결론에 필요한 값은 남긴다.
• 판단이 애매하면 더 적게 쓰는 쪽이 아니라 원문 정보를 보존하는 쪽을 고른다.

입력

• 기준일: YYYY-MM-DD. 본문 첫 줄 날짜로 쓴다.
• 원문 블록: 1개 이상. 블록마다 입력일(YYYY-MM-DD)이 붙어 있을 수 있다. 블록이 여러 개면 모두 합쳐 하나의 기록으로 처음부터 다시 정리한다.

출력

아래 형식 그대로 출력한다. 설명이나 코드블록을 덧붙이지 않는다.

제목: [기관약칭] 제목 내용
처리 상태: 완료|진행 중|확인 필요|보류|이관

[YYYY-MM-DD]

 

■ 요약 : 내용

 

■ 요청 : 내용

...

처리 상태: 줄 다음 빈 줄부터 끝까지가 본문이다. 본문의 정확한 형식은 ## 본문 형식을 따른다.

작업 순서

1. 원문 정리: 메일 헤더(보낸 사람, 받는 사람, 참조, 보낸 날짜, 제목, From, Sent, To, Cc, Subject, -----Original Message-----), 인사말, 서명, 면책 문구, [External] 같은 태그를 걷어낸다.
2. 시간순 재구성: Outlook 스레드는 보통 최신 메일이 위에 있지만 항상 그렇지는 않다. 메일 날짜가 있으면 날짜로, 없으면 "요청 → 확인 → 회신 → 추가 요청" 같은 내용상 인과로 순서를 정한다.
3. 화자 구분: 기관 측, 벤더·솔루션사, 자사 발화를 나눈다. 자사에 대한 요청·설명은 누가 했든 요청, 확인된 사실은 확인, 자사 회신·안내·수행은 조치, 권고·남은 일은 후속으로 간다.
4. 처리 상태 판단 (아래 기준표)
5. 제목 작성
6. 본문 작성
7. 마스킹
8. 자기 검수 체크리스트 확인 후 출력

제목

• 형식: [기관약칭] 대상 + 작업/요청 내용
• 명사형으로 끝낸다. 주로 요청, 문의, 작업, 전달, 점검, 대응, 추가, 변경, 배포로 끝난다.
• 처리 결과(완료, 해결)나 상태는 제목에 쓰지 않는다. 결과는 본문과 처리 상태가 담는다.
• 대상 시스템명, 솔루션명, 리소스명이 원문에 있으면 제목에도 원문 그대로 넣는다.
• 40자 안팎으로 쓰고, 날짜·IP·티켓번호는 넣지 않는다.
• 40자와 식별자 보존이 충돌하면 식별자를 살리고 설명 부분을 줄인다. 식별자를 축약하거나 빼지 않는다. 제목은 나중에 같은 건을 찾는 검색 키이기 때문이다.

좋은 예:

[문화] 서버접근제어 내 유지보수 담당자 계정 추가 요청
[보건] 배포 프로세스 관련 문의
[산림] eval 시스템 PVC 작업 요청
[문화] api-server 이미지 배포 요청

기관 약칭

• 기관 약칭은 org-context 스킬(조직 컨텍스트)의 약칭표를 따른다. 제목을 쓰기 전에 반드시 그 스킬을 읽는다.
• 조직 컨텍스트 스킬이 없으면 원문에 나온 기관 이름을 가장 짧고 명확하게 줄여 쓴다.
• 전 기관을 대상으로 한 공통 작업(일괄 점검, 공통 정책 적용, 전체 공지 등)은 [전체]를 쓴다.
• 기관을 판단할 단서가 전혀 없으면 [미확인]을 쓴다. 추측으로 기관을 고르지 않는다.

본문 형식

아래가 정본 형식이다. 블록 사이   줄까지 그대로 따른다.

[YYYY-MM-DD]

 

■ 요약 : 내용

 

■ 요청 : 내용

 

■ 발생 : 내용

 

■ 확인 : 내용
- 항목
- 항목

 

■ 조치 : 내용

 

■ 후속 : 내용

• 첫 줄은 기준일만 [YYYY-MM-DD]로 쓴다. 날짜 줄에 다른 글자를 붙이지 않는다.
• 레이블 순서는 요약, 요청, 발생, 확인, 조치, 후속으로 고정이며 각 레이블은 한 번만 쓴다.
• 내용이 없는 레이블은 줄 자체를 쓰지 않는다. "-", "없음", "해당 없음"을 쓰지 않는다.
• 6개 레이블 어디에도 딱 맞지 않는 내용은 가장 가까운 레이블에 넣는다. 새 레이블을 만들지 않는다.

배치 규칙

• 항목 1개: ■ 레이블 : 내용 한 줄
• 항목 2개: 쉼표로 이어 한 줄로 썼을 때 레이블을 뺀 내용이 40자 이하면 한 줄, 넘으면 불릿으로 나눈다
• 항목 3개 이상, 항목 2개가 40자를 넘는 경우, (MM/DD) 표기가 붙는 항목이 있는 경우: ■ 레이블 줄만 쓰고 다음 줄부터 - 항목
• 여러 항목이 하나의 작업으로 묶이는 경우: ■ 레이블 : 묶음 내용 다음 줄부터 - 세부 항목. 모든 레이블에 같은 기준을 적용한다.

마크다운 렌더링 규칙

이 기록은 마크다운으로 렌더링되는 화면에서 읽힌다. 줄바꿈 하나는 화면에서 무시되어 줄이 합쳐지고, 줄 앞 공백은 코드블록이나 중첩 목록으로 바뀐다. 가독성이 깨지는 원인 대부분이 여기서 나오므로 아래를 정확히 지킨다.

• 날짜 줄과 첫 레이블 사이, 레이블 블록과 다음 레이블 블록 사이에는 반드시 빈 줄 →   → 빈 줄 세 줄을 넣는다. 마크다운 화면은 빈 줄만으로는 간격을 보여주지 않기 때문에,   줄이 있어야 블록 사이에 눈에 보이는 공백이 생긴다.
•  는 백틱으로 감싸지 않고 줄 첫 칸에 그대로 쓴다.
• 레이블 줄 바로 다음에 불릿이 이어질 때는 빈 줄을 넣지 않는다.
• 같은 레이블 안의 불릿 사이에는 빈 줄을 넣지 않는다. 여러 항목을 - 없이 빈 줄로만 구분하지 않는다. 빈 줄은 레이블 블록 사이에만 쓴다.
• 모든 줄은 첫 칸에서 시작한다. ■, -, [ 앞에 공백이나 탭을 넣지 않는다.
• 불릿은 - 한 단계만 쓴다. 하위 불릿, 번호 목록, 굵게, 제목(#), 표를 쓰지 않는다.
• 경로, 파일명, 명령어, 설정 키/값, 에러 메시지, 마스킹 값은 백틱으로 감싼다. 역슬래시(\), 별표(*), 밑줄(_), 꺾쇠(<>)가 마크다운 문법으로 해석되어 사라지는 것을 막기 위해서다. 예: D:\pdfconv\srcdoc, /etc/hosts, kubectl rollout restart, ******

레이블별 기준

한 사실은 한 곳에만

같은 내용이 여러 레이블에 반복되면 기록이 길어지기만 하고 읽는 사람은 무엇이 새 정보인지 구분하지 못한다. 아래 기준으로 사실마다 자리를 하나만 정한다.

• 기관 측·벤더·솔루션사가 자사에 말한 것(요청, 현상, 배경, 추정) → 요청

• 자사나 제3자가 확인해 알게 된 사실과 판단 → 확인

• 자사가 한 행위(문의, 조회, 테스트, 설정, 회신, 안내) → 조치

• 앞으로 남은 일과 권고 → 후속

• 회신에 담긴 사실은 확인에 쓰고, 조치에는 "확인 결과 회신"처럼 행위만 한 줄로 쓴다. 회신 내용을 조치에 다시 풀어 쓰지 않는다.

• 권고는 후속에만 쓴다. 조치에 "~ 확인 권고", "~ 필요 안내"로 같은 내용을 반복하지 않는다.

• 결과가 확인에 있더라도 그 결과를 얻기 위해 자사가 수행한 행위(제3자 문의, 테스트, 조회)는 조치에 쓴다.

• 조치에 쓴 작업을 확인에 결과로 다시 쓰지 않는다. "네임스페이스 삭제"를 조치에 썼다면 확인에 "네임스페이스 삭제 완료"를 넣지 않는다.

• 자사가 수행한 작업만으로 이루어진 건은 확인을 쓰지 않는다. 점검·조회로 알아낸 사실이 따로 없으면 조치만 쓴다.

• 벤더, 솔루션사, 기관 측이 수행한 작업과 그 결과는 확인에 쓰고, 조치에는 자사 행위(요청, 전달, 수신, 회신)만 남긴다.

• 같은 대상에 대한 값과 그 값에 대한 판단은 한 불릿으로 합친다. 예: JVM DNS TTL : Negative 10초, Positive 30초(기본값), 오류 시간 대비 짧아 원인으로 보기 어려움

요약

• 해결·확인된 것과 남은 것을 한 문장, 80자 안팎으로 쓴다.
• 기록 전체의 처리 상태 단어(완료, 진행 중, 확인 필요, 보류, 이관)로 문장을 끝내지 않는다. 처리 상태는 처리 상태: 줄이 담는다.
• 아래 중 하나에 해당할 때만 쓴다. 해당하지 않으면 요약 줄을 쓰지 않는다.
  • 원인에 대한 판단(추정, 확인 불가 포함)이 있음
  • 처리 상태가 이관 또는 진행 중
  • 확인과 조치의 불릿이 합쳐서 4개 이상. ■ 레이블 : 내용 한 줄짜리는 1개로 센다
• 원인이 확정되지 않았으면 "추정", 확인하지 못한 부분은 "확인 불가"를 명시한다. 원문에 없는 원인을 추론하지 않는다.
• "안내 완료", "처리 완료"처럼 포괄 표현만 쓰지 않는다. 핵심 결론, 제약, 남은 선택지 중 최소 1개를 함께 쓴다.
• 세부 수치와 식별자는 확인·조치에 둔다. 단, 여러 확인 경로나 목적별 선택지가 핵심이면 그 존재는 요약에 남긴다.

요청

• 자사에 들어온 요청, 문의, 확인 요청과 함께 전달된 현상, 배경, 추정을 쓴다. 요청한 쪽이 기관 측이든 벤더·솔루션사든 모두 요청에 쓴다.
• 기관 측 요청은 주체를 생략한다. 벤더·솔루션사 등 기관 외 요청은 앞에 업체명 측 :을 붙인다. 예: 가나문서 측 : NAS 접근 로그 공유 요청
• 요청 주체는 그 문장이 들어 있는 메일의 발신자로 판단한다. 스레드 안의 이전 메일이나 인용문에 있는 요청도 마찬가지다. 같은 업체가 여러 번 요청했으면 불릿마다 주체를 붙인다.
• 발생 빈도(불규칙 반복 등), 변경 이력 유무처럼 기관이 판단 근거로 든 사실도 남긴다.
• 하나의 요청에 딸린 세부 항목과 조건은 불릿을 나누지 않고 괄호나 쉼표로 같은 불릿에 붙인다. 요청 한 건은 불릿 한 줄이다. 예: 가나문서 측 : NAS 감사 로그 기록 여부 확인 및 공유 요청(접근 시각, 작업 유형, 접근 계정, Client IP), 미기록 시 해당 여부 회신 요청
• 조건이 붙은 요청은 조건까지 보존한다. 예: "미설정 또는 무제한 시 설정 추가 필요", "MSP 영역이 아닐 경우 회신 요청 (기관 측 유지보수 업체 통해 진행 예정)"
• 진행 중 추가 요청이 생기면 각각 쓰고, 같은 요청의 반복은 한 번만 쓴다.
• 요청 없이 시작된 업무에는 요청 대신 발생을 쓴다.

발생

• 기관 요청 없이 자사 쪽에서 업무가 시작된 계기: 모니터링 알림, 장애·오류 탐지, 보안 이벤트 탐지, 정기 점검 일정, 자체 발견, 내부 지시.
• 기관 측이 요청하면서 설명한 장애 현상은 발생이 아니라 요청에 쓴다.
• 알림명, 대상 시스템, 발생 시각, 에러 메시지는 원문 그대로 쓴다.
• 알림 후 기관 요청이 이어졌다면 발생과 요청을 함께 쓴다.

확인

• 자사가 점검, 조회, 로그 분석, 테스트로 확인한 사실, 수치, 결과.
• 배포 구조, 파일 성격, 접근 가능 여부, 확인 한계, 운영 상태 같은 객관 사실은 조치에 합치지 않고 확인에 분리한다.
• 벤더, 솔루션사, 기관 측으로부터 받은 답변·분석 결과도 확인에 쓴다.
• "이상 없음", "이력 없음"도 확인 결과이므로 쓴다.
• 같은 속성 값을 공유하는 여러 항목은 "hwp 2건"처럼 묶는다.
• 하나의 구조나 동작 설명이 여러 문장이어도 한 불릿으로 합친다.
• 같은 경로나 같은 시각을 다루는 항목은 한 불릿으로 합친다. 예: 변환 폴더 생성 사실과 그 시각에 모듈이 폴더만 만들고 파일은 만들지 않았다는 설명은 같은 경로·시각이므로 한 불릿이다.
• 합칠 때는 두 문장을 이어 붙이지 않고, 겹치는 사실은 한 번만 쓴다. 예: "폴더 생성, 파일 없음" + "모듈이 폴더 생성, 파일 미생성" → 모듈이 폴더만 생성하고 파일은 미생성
• 판단의 근거가 된 수치(로그 줄 수 변화, 사용률, 건수)는 원시 데이터가 아니라 결론에 필요한 값이므로 남긴다. 예: DNS 로그 8줄 → 2줄

조치

• 원문에 실제 수행, 전달, 설정, 안내, 회신, 완료가 명시된 것만 쓴다.
• 자사가 수행한 행위만 쓴다. 벤더·솔루션사·기관 측이 수행한 작업은 확인에 쓰고, 조치에는 그에 대한 자사 행위(요청, 수신, 전달)만 쓴다.
• 무엇을 안내했는지를 쓴다. "배포 구조 안내", "확인 목적별 안내"처럼 원문 섹션 제목이나 포괄 행위만 쓰지 않는다.
• 원문에 번호 목록이나 목적별 선택지가 있으면 선택지마다 독립 불릿으로 풀어 쓴다.
• 증적 전달, 정책 적용, 설정 변경, 백업 확인에는 파일명, 자료명, 정책명, 제품명, 서비스명, 설정값, 리소스명을 함께 쓴다.
• 실패한 시도도 결과와 함께 쓴다. 예: WAS-02 재기동, 30분 후 동일 증상 재발
• 임시 조치는 앞에 (임시)를 붙인다.
• 여러 단계 조치는 수행 순서대로 쓴다.

후속

• 원문에 남은 작업, 예정 일정, 권고, 회신 대기, 추가 확인·협의 필요 사항이 있을 때만 쓴다.
• 주체가 자사가 아니면 "기관 측", "솔루션사", "벤더"처럼 주체를 앞에 쓴다.
• 요청한 주체와 이행할 주체를 혼동하지 않는다. 벤더가 자사에 요청한 일을 "기관 측 ~ 필요"로 쓰지 않는다.
• 벤더·솔루션사·기관 측이 밝힌 향후 계획(재발 시 분석, 예정 작업 등)은 요청이 아니므로 주체를 붙여 후속에 남긴다. 예: 동일 현상 재발 시 가나문서 측 변환 이력·뷰어 로그·NAS 접근 이력 비교 분석 예정
• 요청에 쓴 내용을 후속에 다시 풀어 쓰지 않는다. 후속에는 그 요청을 이행하기 위해 남은 행위만 쓴다. 예: 요청에 "가나문서 측 : NAS 감사 로그 공유 요청"이 있고 클라우드 사업자에 문의 중이면, 후속은 클라우드 사업자 측 회신 후 가나문서 측 전달 필요
• 갱신으로 다시 정리할 때, 이후 경과로 이미 이행되거나 해소된 이전 후속은 지운다.
• 원문에 없는 후속 작업을 제안하거나 만들지 않는다.
• 기관 요청 중 회신에서 다루지 않은 항목을 찾아 후속으로 만들지 않는다.

경과와 날짜

• 실패한 시도, 판단 변경, 결정 사항, 결과가 있는 확인은 남긴다.
• 사실이 없는 경과는 지운다: 단순 접수, "확인 중입니다", "검토 후 회신드리겠습니다", 수신 확인, 감사 회신.
• 같은 사실이 여러 번 나오면 식별자와 수치가 가장 구체적인 표현으로 한 번만 쓴다.
• 같은 레이블 안에서는 발생 순서대로 쓴다.
• 항목 앞 (MM/DD) 표기:
  • 항목의 날짜는 원문에 명시된 날짜, 없으면 그 항목이 나온 원문 블록의 입력일이다. 둘 다 없으면 날짜를 추측하지 않는다.
  • 한 레이블 안 항목의 날짜가 모두 기준일이면 표기하지 않는다.
  • 한 레이블 안에 기준일이 아닌 날짜의 항목이 하나라도 있으면, 그 레이블의 모든 항목에 날짜를 붙인다(기준일 항목 포함). 요청 경과가 시간순으로 한눈에 보이게 하기 위해서다.
  • 요약과 후속에는 날짜를 붙이지 않는다. 후속은 앞으로의 일이기 때문이다.
  • 항목 내용 안의 일정·시각(예: 8/29 22:00)은 이 표기와 별개로 원문 그대로 둔다.

원문 정제

• 원문 문장을 옮기지 않고 명사형 업무 기록체로 다시 쓴다. "~습니다", "~드립니다", "~보입니다" 어미를 남기지 않는다.
• 인사말, 서명, 존칭 표현, 감사 표현, 메일 헤더, 중복 문장은 지운다.
• 메일 인용문이 본문과 중복되면 지우고, 인용문에만 있는 요청·경과는 반영한다.
• 기관은 "기관 측"으로 쓰고, 자사 주체("당사", "저희", 자사 회사명)는 생략한다.
• 본문에는 기관 이름을 쓰지 않는다. 기관 식별은 제목의 [약칭]이 담당한다. 계약 종료, 기관 통합처럼 기관 자체가 업무 대상인 경우에도 본문에는 "기관 측"으로 쓴다.
• 개인 이름은 원문에 있으면 지우지 않는다. 호칭·존칭(님, 매니저님 등)만 뗀다.
• 전화번호, 이메일 주소는 원문 그대로 둔다.

식별자 보존과 마스킹

반드시 원문 그대로 보존

IP, 계정명, 도메인, URL, 경로, 서버명, 호스트명, 사고번호, 티켓번호, 문서번호, 설정 키/값, 명령어, 리소스명, 네임스페이스, 정책명, 서비스명, 제품명, 솔루션명, 에러 메시지, 일정, 전달·변경·적용한 파일명과 자료명.

대상을 특정하는 식별자가 원문에 있는데 기록에 없으면 틀린 기록이다.

• 같은 경로가 구분자만 다르게(/와 \) 여러 번 나오면 한 번만 쓴다.
• 파일 크기, 파일별 생성·수정·액세스 시각, 반복 로그 원문 줄은 결론에 필요한 값만 남긴다.

반드시 마스킹

비밀번호, 초기 비밀번호, 토큰, API 키, Secret, 인증서·SSH 개인키, OTP·인증번호는 값만 ******로 바꾼다. 무엇의 값인지(PW, token 등)는 남긴다.

• 예: PW: Mock#2026pw → PW: ******
• 계정 ID, IP, 도메인, 경로는 마스킹하지 않는다.

상태 표현

• 항목 안의 "완료"는 원문에 완료, 적용, 정상 확인이 명시된 경우에만 쓴다.
• 실패, 오류, 미확인으로 끝난 항목은 결과를 그대로 쓰고, 남은 확인은 후속에 "확인 필요"로 쓴다.
• 부정 결과를 "확인 완료"로 쓰지 않는다.

문체

• 명사형으로 끝낸다: 요청, 확인, 전달, 안내, 회신, 완료, 필요, 권고.
• 한 항목은 한 줄이다. 길어지면 항목을 나눈다.
• 3개 이상의 선택지, 확인 경로, 조치 단계는 한 줄 요약보다 불릿 나열을 우선한다.
• 경로, 파일명, 설정값, 기술 식별자는 길어도 보존한다.

처리 상태

처리 상태는 출력의 처리 상태: 줄에 쓴다. 판단 근거는 원문이다.

• 완료: 핵심 작업 수행이 끝남. 별도 협의·예정 작업이 후속으로 남아도 핵심 작업이 끝났으면 완료.
• 진행 중: 핵심 작업이 진행 중이거나 예정됨. 기관 측 추가 정보를 받아야 핵심 작업을 시작할 수 있는 경우 포함.
• 확인 필요: 실패, 오류, 미확인으로 끝나 원인 확인이 자사에 남음.
• 보류: 원문에 보류, 중단, 연기가 명시됨.
• 이관: 자사 확인·회신은 끝났고 남은 작업을 기관 측, 솔루션사, 벤더가 이어받음.
• 확인 필요와 이관이 둘 다 성립하면 남은 확인·작업의 주체로 판단한다. 자사가 이어서 확인해야 하면 확인 필요, 기관 측·솔루션사·벤더가 이어받으면 이관이다. 후속에 자사 몫과 타 주체 몫이 섞여 있으면 확인 필요다.

자기 검수 체크리스트

출력 전에 하나씩 확인하고, 어긋나면 고친 뒤 출력한다.

1. 첫 두 줄이 제목:, 처리 상태:이고 그다음 빈 줄, 날짜 줄 순서인가
2. 날짜 줄과 첫 레이블 사이, 각 레이블 블록 사이에 빈 줄 →   → 빈 줄이 모두 들어갔는가 (레이블과 불릿 사이, 불릿과 불릿 사이에는 넣지 않는다)
3. 모든 줄이 공백 없이 ■, - , [,   중 하나로 시작하는가 (빈 줄 제외)
4. 레이블 순서가 맞고 중복·빈 레이블이 없는가
5. 원문의 IP, 경로, 계정, 도메인, 제품명, 파일명, 설정값이 모두 남아 있는가
6. 비밀번호·토큰 값이 ******로 바뀌었는가
7. 경로·파일명·명령어·설정값·에러 메시지·마스킹 값이 백틱 안에 있는가
8. "~습니다" 같은 문장 어미, 인사말, 메일 헤더가 남지 않았는가
9. 원문에 없는 원인, 조치, 후속이 들어가지 않았는가
10. 조치에 "안내", "전달"만 있고 무엇을 안내·전달했는지 빠진 항목이 없는가
11. 같은 사실이 확인·조치·후속에 반복되지 않았는가
12. 자사가 수행한 문의·테스트·조회가 조치에 있는가
13. 기관 측 조건부 요청이 요청에 남아 있는가
14. 본문에 기관 이름이 노출되지 않았는가
15. 조치에 쓴 작업이 확인에 결과로 반복되지 않았는가
16. 같은 레이블 안에 같은 사실이 표현만 바꿔 반복되지 않았는가
17. 벤더·솔루션사의 요청이 요청에 주체와 함께 들어갔는가 (후속으로 밀려나거나 주체가 "기관 측"으로 바뀌지 않았는가)
18. 요청 한 건이 불릿 여러 개로 쪼개지지 않았는가
19. 요청에 쓴 내용이 후속에 다시 들어가지 않았는가
20. 같은 경로나 같은 시각을 다루는 항목이 여러 불릿에 나뉘지 않았는가
21. 기준일이 아닌 날짜가 섞인 레이블은 모든 항목에 (MM/DD)가 붙었고, 날짜가 모두 기준일인 레이블과 요약·후속에는 붙지 않았는가
22. 벤더·솔루션사·기관 측이 밝힌 향후 계획이 후속에 남아 있는가
23. 합친 불릿 안에 같은 사실이 두 번 들어가지 않았는가

예시

예시 1은 실제 출력과 똑같은 완전한 형태다. 예시 2부터는 읽기 쉽도록 블록 사이   줄만 생략했으므로, 실제 출력에서는 예시 1처럼 모든 블록 사이에 빈 줄 →   → 빈 줄을 넣는다.

예시 1) 분석 회신이 섞인 문의, 이관

기준일: 2026-09-11

원문:

안녕하세요.
PDF 변환 솔루션(pdfconv) 변환 오류 관련 문의드립니다.
변환 시점과 별개로 해당 폴더의 액세스 일자가 이후인 8/31로 변경되어 있습니다.
D:/pdfconv/srcdoc/2026/8/12/DOC2026081200123
변환 일자 : 2026/08/12 15:43:58
액세스 일자: 2026/08/31 14:43
해당 경우에는 '재변환' 작업 등은 관련 테이블에서 확인 결과 없었습니다.
대상 폴더 및 파일에 대한 8/12 변환 시점부터 8/31 전후까지의 접근/생성/수정/삭제 이력을 확인 요청 드립니다.

[회신]
서버 파일 속성(생성·수정·액세스 일시)을 확인한 결과입니다.
원본 폴더 경로: D:\pdfconv\srcdoc\2026\8\12\DOC2026081200123
폴더 및 hwp 2건: 생성·수정 2026-08-12 15:43:58
변환 폴더 경로: D:\pdfconv\pdfout\2026\8\12\DOC2026081200123
폴더: 생성·수정 2026-08-31 14:43:43 / 폴더 내 파일 없음 (숨김 파일 포함)
8/31 14:43 당시 폴더에 접근하거나 변환 폴더를 생성한 주체(사용자/프로세스)와 그 경위는 파일 속성만으로는 확인되지 않습니다.
해당 시각 전후의 애플리케이션(변환/뷰어) 로그에서 확인이 필요합니다.
추가로, 서버접근제어 솔루션을 통한 접속 이력 또한 확인되지 않습니다.
8/31 14:43경 변환·뷰어 모듈이 원본 폴더를 조회하고 PDF 폴더를 생성했으나 PDF 파일은 생성되지 않은 것으로 보입니다.
해당 부분은 3rd Party 솔루션사 통해 문의하시는 방안을 권장드립니다.

출력:

제목: [문화] pdfconv PDF 변환 폴더 접근 이력 확인 요청
처리 상태: 이관

[2026-09-11]

 

■ 요약 : 8/31 14:43경 변환·뷰어 모듈이 PDF 폴더만 생성하고 파일은 미생성한 것으로 추정, 생성 주체는 파일 속성으로 확인 불가

 

■ 요청 : pdfconv 8/12 변환 건(DOC2026081200123) 폴더 액세스 일자 8/31 변경 관련, 8/12 ~ 8/31 접근/생성/수정/삭제 이력 확인 요청

 

■ 확인
- 원본 폴더(`D:\pdfconv\srcdoc\2026\8\12\DOC2026081200123`) : 폴더·hwp 2건 생성·수정 2026-08-12 15:43:58
- 변환 폴더(`D:\pdfconv\pdfout\2026\8\12\DOC2026081200123`) : 2026-08-31 14:43:43 생성, 파일 없음(숨김 파일 포함), 접근·생성 주체(사용자/프로세스)와 경위는 파일 속성만으로 확인 불가
- 서버접근제어 솔루션 접속 이력 없음

 

■ 조치 : 파일 속성 및 서버접근제어 접속 이력 확인 결과 회신

 

■ 후속
- 8/31 14:43 전후 애플리케이션(변환/뷰어) 로그 확인 필요
- 기관 측 3rd Party 솔루션사 문의 권고

예시 2) 단순 요청과 하나의 작업으로 묶이는 조치

한 줄 레이블, 식별자(IP, 사고번호) 보존, 여러 세부 작업을 하나의 조치로 묶는 형태를 함께 보여준다.

제목: [산림] 해외 IP 차단 요청
처리 상태: 완료

[2026-08-22]

■ 요청 : 203.0.113.48 → 10.20.30.10 양방향 통신 확인 및 차단 요청 (사고번호 S260822-01234)

■ 조치 : 203.0.113.48 차단 완료
- WAF(WebGuard WAF) 차단 정책 등록
- IPS(SecuHost IPS) 차단 정책 등록

예시 3) 요청 없이 시작된 업무

제목: [기상] 8월 정기 백업 점검
처리 상태: 완료

[2026-08-25]

■ 발생 : 8월 정기 백업 점검

■ 확인 : 백업 job 12건 중 11건 정상, NAS-BK02 job 8/24 23:00 실패 (`Error: Repository out of space`, repository 사용률 97%)

■ 조치 : NAS-BK02 repository 30일 초과 복원 지점 정리 후 job 수동 재실행, 정상 완료 확인

■ 후속 : repository 증설 여부 기관 측 협의 필요

예시 4) 일부 실패로 끝난 건

제목: [보건] 회계시스템 원격접속포털 접근 불가 확인 및 계정 초기화 요청
처리 상태: 확인 필요

[2026-08-20]

■ 요청 : 회계시스템 원격접속포털 접근 불가 확인 및 서포트 엔지니어 계정(portal-kdlee/kdlee) 초기화 요청

■ 조치
- 홈페이지 VPN 연결 및 원격접속포털 접근 확인 완료(portal-sjpark)
- 회계시스템(sjpark) VPN 연결 후 서버 접속 실패

■ 후속 : 회계시스템(sjpark) 서버 접속 실패 원인 확인 필요

예시 5) 여러 날짜 경과가 누적된 장애 건

제목: [기상] 홈페이지 간헐적 502 오류 대응
처리 상태: 진행 중

[2026-08-26]

■ 요약 : WAS-02 게시판 첨부파일 조회 모듈 메모리 누수로 원인 확인, L4 임시 제외로 502 해소 후 8/29 22:00 패치 적용 예정

■ 요청
- (08/26) 홈페이지(www.example.go.kr) 간헐적 502 오류 확인 요청
- (08/27) WAS-02 금주 중 복구 및 8/29 22:00 이후 작업 진행 요청

■ 확인
- (08/26) WEB-01 nginx `error.log` 내 `upstream timed out` 다수
- (08/26) 네트워크 구간 문제 의심으로 L4 세션 점검, 이상 없음
- (08/26) WAS-02 JVM heap 사용률 98%, Full GC 반복
- (08/27) 벤더 분석 결과 게시판 첨부파일 조회 모듈 메모리 누수, 패치 파일 수령

■ 조치
- (08/26) WAS-02 재기동, 30분 후 동일 증상 재발
- (08/26) heap dump 수집(`/data/dump/was02_0826.hprof`) 및 벤더 분석 요청
- (08/26) (임시) L4에서 WAS-02 제외, 이후 502 미발생
- (08/27) 기관 측에 8/29 22:00 WAS-02 패치 적용 일정 안내

■ 후속 : 8/29 22:00 WAS-02 패치 적용 예정

예시 6) 확인 목적별 선택지를 안내한 문의

제목: [보건] 배포 프로세스 관련 문의
처리 상태: 완료

[2026-09-15]

■ 요약 : .war 파일만으로 개발 원본 소스코드 전체 확인은 어렵고, 확인 목적별 접근 경로 3가지 안내

■ 요청 : 소스코드 확인 절차 문의

■ 확인
- 개발사에서 소스코드를 .war 파일로 VM 서버의 NAS 스토리지에 업로드 후 오로라(Kubernetes 기반 배포 플랫폼)을 통해 운영 환경에 배포
- .war 파일은 컴파일·패키징된 배포 파일로 개발 원본 소스코드 전체 확인은 어려움

■ 조치
- 원본 소스코드 확인 필요 시 개발사(가나소프트) 직접 문의 안내
- 운영서버의 .war 파일 확인 필요 시 서버접근제어 솔루션으로 해당 파일 위치 서버 접근 가능 안내
- 운영 중인 애플리케이션 배포 상태 확인 필요 시 오로라 플랫폼에서 배포 이력 및 운영 현황 확인 가능 안내
- 확인 목적 공유 시 상황별 가이드 전달 가능 안내

예시 7) 추가 정보 대기와 자격증명 마스킹

기준일: 2026-09-15

원문:

eval 시스템 PVC 작업 요청드립니다.

[처리]
ana-sec-mount 컨테이너 할당 완료했습니다. (ID: deploy-admin, PW: Mock#2026pw)
도메인 접속 테스트를 위해 /etc/hosts 파일에 eval.example.re.kr 10.20.30.6 추가 부탁드립니다.

PVC 작업 관련하여 아래 정보 추가로 알려주시면 진행하겠습니다.
- 작업 대상 네임스페이스
- 작업 대상 카탈로그
- PVC 작업 대상 컨테이너 내부 경로(mountPath)

출력:

제목: [산림] eval 시스템 PVC 작업 요청
처리 상태: 진행 중

[2026-09-15]

■ 요약 : ana-sec-mount 컨테이너 할당 후 PVC 작업은 기관 측 대상 정보 회신 대기

■ 요청 : eval 시스템 PVC 작업 요청

■ 조치
- ana-sec-mount 컨테이너 할당 완료 (ID: deploy-admin, PW: `******`)
- 도메인 접속 테스트를 위한 `/etc/hosts` 파일 추가 안내 (eval.example.re.kr 10.20.30.6)

■ 후속 : 기관 측 PVC 작업 관련 추가 정보 회신 필요
- 작업 대상 네임스페이스
- 작업 대상 카탈로그
- PVC 작업 대상 컨테이너 내부 경로(mountPath)

예시 8) 기관 측 추정과 조건부 요청이 있는 장애 문의, 이관

확인·조치·후속에 같은 내용이 반복되지 않도록 사실마다 자리를 하나만 둔 예시다.

제목: [기상] 통합업무시스템 SMS 발송 실패 DNS 캐싱 설정 확인 요청
처리 상태: 이관

[2026-09-16]

■ 요약 : 클라우드 사업자 측 DNS 변경 이력 없고 JVM DNS TTL은 원인으로 보기 어려운 수준, HTTP Client Connection 설정과 도메인 끝 마침표 적용 여부 기관 측 확인 필요

■ 요청 : SMS API 문자 발송 실패 원인 확인 요청
- 2026-09-15 SMS API 문자 발송 실패, `HTTPS hostname wrong: should be <sms.api.example-cloud.com>` 오류 불규칙 반복 발생
- 배포·소스 변경 없음, Pod 쉘 직접 실행 시 정상으로 기관 측은 DNS 캐싱 문제 추정
- 최초 에러 인지 시각 16:20:34 이전 sms.api.example-cloud.com IP 갱신·DNS 작업 유무 클라우드 사업자 확인 요청
- Docker 이미지 및 Pod JVM DNS 캐싱 시간 설정 확인 요청, 미설정 또는 무제한 시 설정 추가 필요
- MSP 영역이 아닐 경우 회신 요청 (기관 측 유지보수 업체 통해 진행 예정)

■ 확인
- 클라우드 사업자 측 회신 결과 IP 갱신·DNS 변경 특이사항 없음
- JVM DNS TTL : Negative 10초, Positive 30초(기본값), 통신 오류 시간 대비 짧아 TTL로 인한 질의 문제로 보기 어려움
- JVM HTTP 전역 설정 별도 지정 없이 기본 정책 동작, HTTP Client Connection 재사용·해제는 애플리케이션 내부 설정에 따라 다름
- Kubernetes Pod는 외부 API 호출 시 CoreDNS 내부 조회를 순차 수행 후 모두 실패 시 외부 질의, 호출 1회당 내부 조회 반복 발생
- Pod 내부 테스트 결과 도메인 끝 마침표(`sms.api.example-cloud.com.`) 적용 시 DNS 로그 8줄 → 2줄로 외부 단건 질의 (서버 명령어 기준, 애플리케이션 적용 여부 미검증)

■ 조치
- 클라우드 사업자 측 sms.api.example-cloud.com IP 갱신·DNS 변경 여부 문의
- Pod 내부 도메인 끝 마침표 적용 DNS 질의 테스트
- 확인 결과 기관 측 회신

■ 후속
- 기관 측 HTTP Client Connection 처리 방식 및 관련 설정 확인 권고
- 기관 측 테스트 환경에서 sms.api.example-cloud.com 호출부 마침표 적용 가능 여부 확인 권고

예시 9) 자사 수행 작업만으로 이루어진 건

점검·조회로 알아낸 사실이 따로 없으므로 확인을 쓰지 않고 조치만 쓴다.

제목: [보건] 계약 종료에 따른 Kubernetes 및 연계 솔루션 리소스 정리
처리 상태: 완료

[2026-09-18]

■ 요약 : 계약 종료에 따라 Kubernetes 네임스페이스와 연계 보안 솔루션의 관련 리소스 정리 완료

■ 발생 : 기관 측 계약 종료에 따른 Kubernetes 및 연계 솔루션 정리 작업

■ 조치
- 오로라 Kubernetes 대상 네임스페이스 삭제로 관련 리소스 전체 삭제
- 오로라 Kubernetes 동적 프로비저너 `Deployment` 및 `StorageClass` 삭제
- WebGuard WAF 관련 도메인 삭제
- 서버접근제어 솔루션 `AccessOne` 관련 VM 할당 삭제
- DB 접근제어 솔루션 `DBGuard` 관련 VM 할당 삭제

예시 10) 갱신으로 벤더 요청이 추가된 건

예시 1 기록에 원문 블록 2가 추가된 경우다. 벤더 요청은 요청에 주체를 붙여 쓰고, 벤더의 향후 계획은 후속에 남기며, 날짜가 섞인 레이블은 모든 항목에 날짜를 붙이고, 진행 중인 분석의 근거가 되는 이전 확인 사실(시각, 경로)은 줄이지 않으며, 이후 경과로 해소된 이전 후속은 지운다.

기준일: 2026-09-11 / 원문 블록 1: 예시 1의 원문 (입력일 2026-09-11)

원문 블록 2 (입력일 2026-09-18):

PDF 변환 모듈과 동일한 NAS 경로를 참조하는 뷰어 모듈(docviewer)에도 방어 로직 적용 및 로그 강화 작업을 진행했으며, 9/16~9/17 대상 기관 적용 및 서비스 정상 확인하였습니다.
다만 결과 파일이 정상 생성된 이후 미존재 상태로 변경된 시점과 작업 주체는 당사 솔루션 로그만으로는 특정하기 어렵습니다.
pdfout 경로가 구성된 NAS 장비에서 File Access/Audit 로그를 기록하고 있는지 확인 부탁드리며, 로그가 있다면 접근 시각, 작업 유형, 접근 계정, Client IP를 공유 부탁드립니다.
기록하지 않아 제공이 어려우면 해당 여부만이라도 회신 부탁드립니다.
동일 현상이 재발하면 변환 이력, 강화된 뷰어 로그, NAS 접근 이력을 함께 비교해 추가 분석하겠습니다.

[회신]
현재 클라우드 NAS 서비스는 콘솔에서 파일 단위 접근/감사 로그 확인이 불가합니다.
클라우드 사업자 측에 로그 제공 가능 여부를 문의하였으며, 답변 받는 대로 전달드리겠습니다.

출력:

제목: [문화] pdfconv PDF 변환 폴더 접근 이력 확인 요청
처리 상태: 진행 중

[2026-09-11]

■ 요약 : 솔루션 로그로는 변환 결과 파일 유실 시점·주체 특정 불가, NAS 감사 로그 제공 가능 여부 클라우드 사업자 회신 대기

■ 요청
- (09/11) pdfconv 8/12 변환 건(DOC2026081200123) 폴더 액세스 일자 8/31 변경 관련, 8/12 ~ 8/31 접근/생성/수정/삭제 이력 확인 요청
- (09/18) 가나문서 측 : pdfout 경로 NAS의 `File Access/Audit` 로그 기록 여부 확인 및 공유 요청(접근 시각, 작업 유형, 접근 계정, Client IP), 미기록 시 해당 여부 회신 요청

■ 확인
- (09/11) 원본 폴더(`D:\pdfconv\srcdoc\2026\8\12\DOC2026081200123`) : 폴더·hwp 2건 생성·수정 2026-08-12 15:43:58
- (09/11) 변환 폴더(`D:\pdfconv\pdfout\2026\8\12\DOC2026081200123`) : 2026-08-31 14:43:43 생성, 파일 없음(숨김 파일 포함), 생성 주체·경위는 파일 속성만으로 확인 불가
- (09/11) 서버접근제어 솔루션 접속 이력 없음
- (09/18) 가나문서 docviewer 모듈에 방어 로직·로그 강화 적용(9/16~9/17 대상 기관 적용, 서비스 정상), 솔루션 로그로는 유실 시점·작업 주체 특정 불가
- (09/18) 클라우드 NAS는 콘솔에서 파일 단위 접근·감사 로그 확인 불가

■ 조치
- (09/11) 파일 속성 및 서버접근제어 접속 이력 확인 결과 회신
- (09/18) 클라우드 사업자 측에 NAS 파일 접근·감사 로그 제공 가능 여부 문의

■ 후속
- 클라우드 사업자 측 로그 제공 가능 여부 회신 후 가나문서 측 전달 필요
- 동일 현상 재발 시 가나문서 측 변환 이력·뷰어 로그·NAS 접근 이력 비교 분석 예정