docs(supply-chain): fold the server delivery page into the SBOM creation guide

[haksungjang]

서버(OS + 애플리케이션) SBOM 생성 페이지를 없애고 내용을 오픈소스 도구를 활용한 SBOM 생성과 SBOM 제출 절차로 옮깁니다.

배경

서버 페이지에만 있던 내용은 네 가지, 25줄 남짓이었습니다. 나머지는 생성 방법 페이지의 도구 선택 절과 Syft 절을 다시 서술한 것이었습니다. 두 페이지를 따로 두다 보니 같은 이야기가 두 곳에 있어 계속 어긋났습니다. 실제로 서버 페이지가 "일반 애플리케이션 납품이라면 생성 방법만으로 충분하다"고 안내하는 동안, 생성 방법 페이지는 서버·VM 이미지까지 다루고 있었습니다.

옮긴 곳

성격에 따라 나눴습니다.

• 두 층으로 나눠 스캔, 정적 링크 라이브러리, 하나로 합쳐 제출 → SBOM 생성 방법의 서버 납품 절
• 클러스터·다중 노드 제출 단위 → 제출 절차의 제출 단위 절. 생성 방법이 아니라 제품당 SBOM 하나라는 제출 규칙이고, 상용 소프트웨어 공급 페이지도 이 내용을 참조하고 있어 생성 방법 안에 두면 상용 완제품 공급사가 엉뚱한 페이지로 가게 됩니다.
• BomLens 서버 납품 정본 문서 링크 → BomLens 페이지의 참조 표

그 밖의 변경

• 도구 선택 절의 서버 문단과 정적 링크 문단을 갈래 안내와 앵커 링크로 줄였습니다.
• Syft 절 끝에 있던 서버 요약 문단이 새 절과 중복이라 삭제했습니다.
• server-delivery.md를 삭제하고 front matter aliases로 옛 URL을 생성 방법 페이지로 넘깁니다.
• 인바운드 링크 11군데를 새 앵커로 바꿨습니다(공급사 가이드 첫 페이지, 검증 체크리스트, 반려 사유 3곳, 상용 소프트웨어 2곳, 생성 방법 4곳).
• 제출 절차의 절 번호를 재조정했습니다(제출 단위, 제출 시기, 제출 방법, 제출 후 검증).

스캔 대상 서술

두 층으로 나눠 스캔하는 서술을 유지했습니다. Syft로 rootfs를 스캔하면 OS 패키지와 함께 파일로 설치된 파이썬·Node.js 의존성은 딸려 오지만, C/C++처럼 소스에 라이브러리를 포함하는 경우는 전혀 식별되지 않습니다. 실제 반려는 모두 누락 방향이라, 두 층을 명시적으로 확인하게 하는 편이 안전합니다. 이 단서를 새 절에 한 문장으로 적었습니다.

확인

• hugo 빌드 통과
• 옛 URL 두 개(/guide/.../server-delivery/, /en/guide/.../server-delivery/)가 생성 방법 페이지로 리다이렉트되는 것 확인
• 새 앵커 6개(한국어·영어)가 생성된 HTML에 존재하는 것 확인
• 본문에 server-delivery 잔여 참조 없음(앵커와 alias, BomLens 외부 링크 제외)

한국어와 영어 양쪽에 같은 내용을 반영했습니다.