fix(server): 실행 컨텍스트와 배포 설정 통합

[danpung2]

문제

REST와 gRPC 전송 계층이 각각 LogService 구현을 등록하면서 all 모드의 Spring 컨텍스트에서 빈 충돌이 발생했고, 프로토콜·포트 설정 키가 실행 방식과 배포 파일마다 달라 특정 프로필과 컨테이너 환경의 동작이 일치하지 않았습니다. 또한 REST 프로필에서 서비스 빈은 제외됐지만 gRPC health/reflection listener가 계속 50051 포트를 열고 있었습니다.

변경 사항

• 전송 계층이 공유하는 DefaultLogService를 core 모듈에 추가하고 REST/gRPC 전용 중복 구현을 제거했습니다.
• 프로토콜 선택을 logpilot.protocol과 LOGPILOT_PROTOCOL로 통일하고 rest, grpc, all 모드의 조건부 구성을 정리했습니다.
• REST 프로필의 grpc.server.port를 -1로 설정해 gRPC listener를 완전히 비활성화하고 회귀 테스트를 추가했습니다.
• REST, gRPC, management, cluster advertised 포트를 분리하고 Docker Compose 및 Kubernetes 설정에 같은 키를 적용했습니다.
• gRPC 메타데이터 키를 HTTP/2 규칙에 맞는 소문자 x-api-key로 통일했습니다.
• Docker/Kubernetes 실행 안내, 상태 확인 경로, 버전 고정 이미지 태그, API 키 전달 방식을 현재 동작과 맞췄습니다.

검증

• ./gradlew test 성공: 41개 테스트 스위트, 239개 테스트, 실패·오류·스킵 0
• 기본/all, REST, gRPC Docker 이미지 빌드 성공
• 세 컨테이너의 management health UP 확인
• all/REST 모드의 REST 저장·조회와 all/gRPC 모드의 인증된 reflection, SendLog, FetchLogs 성공
• gRPC 전용 모드의 8080 및 REST 전용 모드의 50051 연결 거부 확인
• API 키가 없는 gRPC 요청이 Unauthenticated로 거부되는 것을 확인
• 세 Compose 파일의 docker compose config -q 성공
• kubectl kustomize k8s 성공: 610줄 렌더링
• Minikube에 Kustomize 리소스를 적용하고 Pod 1/1 Ready, 재시작 0, PVC Bound 확인
• Kubernetes Service를 통한 management health, REST 저장·조회, gRPC reflection·저장·조회 성공
• staged 변경, 커밋 제목, PR 제목과 본문에 대한 private-vault 참조 검사 통과

운영 참고

• 관리 엔드포인트는 기본적으로 8081 포트를 사용합니다.
• 배포 시 LOGPILOT_API_KEY를 외부에서 제공해야 하며 manifest에는 비밀 값을 저장하지 않습니다.
• Kubernetes 시작 과정에서 PVC 바인딩 전 scheduling 지연과 애플리케이션 준비 전 startup probe 실패가 각각 한 번 기록됐지만, 최종 Pod 상태와 런타임 요청은 모두 정상입니다.