diff --git a/journey/research/260310_51123_포트_진입점_프로젝트경계_리서치.md b/journey/research/260310_51123_포트_진입점_프로젝트경계_리서치.md
index 600df2e..7d6c66f 100644
--- a/journey/research/260310_51123_포트_진입점_프로젝트경계_리서치.md
+++ b/journey/research/260310_51123_포트_진입점_프로젝트경계_리서치.md
@@ -23,6 +23,10 @@ tags: [infra, ports, ingress, gateway, project-boundary, research]
 - 이 중 외부 웹 진입면은 `80/443`의 nginx다.
 - `3000`은 Gitea, `9000`은 auth-server, `51123`은 SSH다.
 - `5432`, `7687`, `8000`, `8100`, `8200`, `8505`, `9200`, `9600`은 운영상 직접 접근 가능한 상태지만, 모두 공용 진입면으로 설계된 것은 아니다.
+- `sudo ufw status numbered` 기준 전체 허용은 아니다.
+  - `80/443`, `51123`은 광범위 허용
+  - `5432`, `7687`은 일부 출발지 대역만 허용
+  - 반면 `8000`, `8100`, `8200`, `8505`, `9000`, `9200`, `9600`은 현재 UFW 규칙상 별도 제한이 보이지 않는다
 
 ### 2. `ro-being.com`의 공용 API 진입은 대부분 `8100` gateway로 모인다
 - `/api/`는 `localhost:8100`으로 프록시된다.
@@ -41,6 +45,12 @@ tags: [infra, ports, ingress, gateway, project-boundary, research]
 - `starsandi`는 `ro-being.com` 아래에서 더 이상 내부 프록시를 쓰지 않고 `https://starsandi.com`으로 리다이렉트된다.
 - `git.ro-being.com`은 `localhost:3000` Gitea로 직접 간다.
 - `auth.ro-being.com`은 `localhost:9000` auth-server로 직접 간다.
+- 실도메인 확인 결과도 일치한다.
+  - `https://ro-being.com/ -> 200`
+  - `https://ro-being.com/api/healthz -> 405` (`/api/*`가 실제 gateway로 전달됨을 보여줌)
+  - `https://git.ro-being.com/ -> 200`
+  - `https://starsandi.com/ -> 307 /ko`
+  - `https://auth.ro-being.com/ -> 404` (서브도메인 프록시는 존재하지만 루트 엔드포인트 자체는 미구현)
 
 ### 5. `robeing` 경로 안에서도 ingress 기준이 둘로 나뉜다
 - `ro-being.com/api/*`는 `8100 gateway`를 거친다.
diff --git a/journey/troubleshooting/260311_51123_포트경계_복잡성_및_진입구조불일치_이슈.md b/journey/troubleshooting/260311_51123_포트경계_복잡성_및_진입구조불일치_이슈.md
index 249f46c..f942b1e 100644
--- a/journey/troubleshooting/260311_51123_포트경계_복잡성_및_진입구조불일치_이슈.md
+++ b/journey/troubleshooting/260311_51123_포트경계_복잡성_및_진입구조불일치_이슈.md
@@ -18,11 +18,13 @@ tags: [infra, 51123, ports, ingress, gateway, troubleshooting]
 - 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 기준이 이중화돼 있다.
+- `sudo ufw status numbered` 확인 결과 `5432`, `7687`은 일부 대역만 제한하지만 `8000`, `8100`, `8200`, `8505`, `9000`, `9200`, `9600`은 별도 제한 규칙이 보이지 않아, 리슨 상태와 노출 정책이 문서 기준 없이 섞여 있다.
 
 ## 원인
 - 프로젝트 수가 늘었지만 포트 관리 기준이 `프로젝트별`, `서버별`, `ingress별` 3축으로 아직 고정되지 않았다.
 - 특히 `8100`은 현재 사실상 `robeing 전용 제어면`인데, 운영상 공용 API 게이트웨이처럼 읽힐 여지가 남아 있다.
 - `goosefarminvesting`, `starsandi`, `gitea`, `auth`, `robeing`이 서로 다른 진입 방식을 쓰지만, 이 차이가 포트 문서나 정책 문서로 아직 승격되지 않아 구조 복잡성이 누적됐다.
+- 즉 직접 원인은 `프로젝트별 ingress 방식 불일치`와 `포트별 노출 정책 미고정`, 근본 원인은 `포트 책임 경계를 SSOT로 아직 승격하지 않은 상태`다.
 
 ## 영향
 - 포트 개방/차단, nginx 경로 변경, health 확인, 장애 판단에서 “어느 경로가 기준인가”를 잘못 읽을 위험이 높다.