docs: add 51123 port boundary issue

journey/README.md

@@ -44,6 +44,7 @@
 - [260308 env backup git tracking exposure 및 차단조치](./troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md)
 - [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](./troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
 - [23 gateway MONITOR_URL 구주소 잔존으로 24 monitor 프록시 실패 복구](./troubleshooting/260310_23gateway_monitor_url_구주소잔존_24monitor프록시실패_복구.md)
+- [51123 포트경계 복잡성 및 진입구조불일치 이슈](./troubleshooting/260311_51123_포트경계_복잡성_및_진입구조불일치_이슈.md)
 - [Gitea git credential helper 표준화](./troubleshooting/260309_gitea_git_credential_helper_표준화.md)
 - [23서버 워크스페이스 인프라 구조정리 이슈](./troubleshooting/260307_23서버_워크스페이스_인프라_구조정리_이슈.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 파일 동기화 아이디어](./ideas/260307_external_nas_companyx_sync_아이디어.md)

journey/troubleshooting/260311_51123_포트경계_복잡성_및_진입구조불일치_이슈.md

@@ -0,0 +1,39 @@
+---
+tags: [infra, 51123, ports, ingress, gateway, troubleshooting]
+---
+
+# 260311 51123 포트경계 복잡성 및 진입구조불일치 이슈
+
+## 상위 원칙
+- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
+- [Runtime Principles](../../00_Philosophy/01_PRINCIPLES/Runtime_Principles.md)
+- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
+
+## 관련 문서
+- [51123 포트 진입점 프로젝트 경계 리서치](../research/260310_51123_포트_진입점_프로젝트경계_리서치.md)
+- [23서버 워크스페이스 SSOT 구조전환 리서치](../research/260309_23서버_워크스페이스_SSOT_구조전환_리서치.md)
+- [23 gateway MONITOR_URL 구주소 잔존으로 24 monitor 프록시 실패 복구](./260310_23gateway_monitor_url_구주소잔존_24monitor프록시실패_복구.md)
+
+## 문제
+- 51123의 현재 포트 상태는 단순히 “포트가 많다”가 아니라, `공용 진입면`, `프로젝트 내부 제어면`, `직접 프록시`, `직접 외부노출`이 섞여 있어 운영 판단 기준이 흐려진 상태다.
+- 실제로 `80/443` nginx 외에도 `8000`, `8100`, `8200`, `8505`, `9000`, `9200`, `9600`, `5432`, `7687`이 외부 접근 가능한 형태로 보이며, 이 중 무엇이 공식 진입면이고 무엇이 내부용인지 한 문서에서 바로 닫히지 않는다.
+- `robeing`만 봐도 `ro-being.com/api/* -> 8100 gateway`, `ro-being.com/rb8001/* -> 24서버 8001 직접`으로 ingress 기준이 이중화돼 있다.
+
+## 원인
+- 프로젝트 수가 늘었지만 포트 관리 기준이 `프로젝트별`, `서버별`, `ingress별` 3축으로 아직 고정되지 않았다.
+- 특히 `8100`은 현재 사실상 `robeing 전용 제어면`인데, 운영상 공용 API 게이트웨이처럼 읽힐 여지가 남아 있다.
+- `goosefarminvesting`, `starsandi`, `gitea`, `auth`, `robeing`이 서로 다른 진입 방식을 쓰지만, 이 차이가 포트 문서나 정책 문서로 아직 승격되지 않아 구조 복잡성이 누적됐다.
+
+## 영향
+- 포트 개방/차단, nginx 경로 변경, health 확인, 장애 판단에서 “어느 경로가 기준인가”를 잘못 읽을 위험이 높다.
+- 일부 경로는 정상이어도 다른 경로는 실패하는 `부분 정상` 상태를 운영자가 늦게 인지할 수 있다.
+- gateway 성격을 잘못 이해하면 멀티프로젝트 공용 변경처럼 건드려 불필요한 영향 범위를 만들 수 있다.
+
+## 현재 판단
+- 이 이슈는 아직 `원칙` 단계보다 `인프라 트러블슈팅` 단계다.
+- 먼저 `포트별 책임`, `공식 ingress`, `직접노출 허용 여부`, `23/24 서버 경계`를 실행 기준으로 닫아야 한다.
+- 그 다음에만 `포트맵 SSOT`나 `차단/허용 원칙`으로 승격할 수 있다.
+
+## 결론
+- 지금의 핵심 문제는 “포트 수”가 아니라 “포트 책임 경계와 진입 구조가 문서 SSOT로 아직 닫히지 않았다”는 점이다.
+- 직접 원인은 `프로젝트별 진입 방식 차이`와 `gateway 역할의 애매한 해석 가능성`이다.