diff --git a/docs/00_guide_tdc114plus_android_release_meeting_2026-07-20.md b/docs/00_guide_tdc114plus_android_release_meeting_2026-07-20.md
index f7c6575..e13405f 100644
--- a/docs/00_guide_tdc114plus_android_release_meeting_2026-07-20.md
+++ b/docs/00_guide_tdc114plus_android_release_meeting_2026-07-20.md
@@ -370,6 +370,145 @@ production 직행의 장점은 아래 정도다.
 
 즉 "처음부터 무조건 완전 별도 물리 서버"가 아니라, "서비스 경계는 분리하고 인프라는 현실적으로 시작"하는 방향이다.
 
+## 5.6-A 위 문장을 더 쉽게 풀면
+
+여기서 가장 헷갈리기 쉬운 부분은 아래 3가지를 같은 뜻으로 오해하는 것이다.
+
+1. 저장소를 따로 둔다
+2. 서비스를 따로 운영한다
+3. 물리 서버를 따로 둔다
+
+이 3가지는 서로 다른 이야기다.
+
+### 저장소 분리
+
+이 뜻은 소스코드를 Git 저장소 단위로 따로 관리한다는 뜻이다.
+
+예:
+
+- `tdc114plus` 앱 저장소
+- `tdc114plus-auth` 저장소
+- Baron SSO 저장소
+
+### 서비스 분리
+
+이 뜻은 실제 실행되는 프로그램을 따로 운영한다는 뜻이다.
+
+예:
+
+- Baron SSO 본체 프로세스
+- `tdc114plus-auth` 프로세스
+
+둘이 같은 서버 안에 있어도 실행 주체가 따로면 서비스는 분리된 것이다.
+
+### 물리 서버 분리
+
+이 뜻은 아예 다른 VM, 다른 컨테이너 호스트, 다른 장비에 올린다는 뜻이다.
+
+즉 아래처럼 이해하면 된다.
+
+- 저장소는 따로일 수 있다
+- 서비스도 따로일 수 있다
+- 하지만 물리 서버는 처음엔 같은 것을 쓸 수도 있다
+
+그래서 "처음부터 인프라를 너무 크게 벌리지 않아도 된다"는 말은 `저장소만 다르게 둔다`는 뜻이 아니라 아래 뜻에 가깝다.
+
+- Git 저장소는 분리한다
+- 실행 서비스도 분리한다
+- 다만 처음에는 같은 운영 서버 자원을 활용할 수 있다
+
+## 5.6-B 실제로는 어떤 모습인가
+
+예를 들어 한 대의 서버 안에서 아래처럼 운영할 수 있다.
+
+- Baron SSO 본체 서비스는 기존 포트/기존 설정으로 실행
+- `tdc114plus-auth`는 별도 포트 또는 별도 컨테이너로 실행
+- 외부에서는 `114-auth.hmac.kr` 주소로 들어오고 reverse proxy가 `tdc114plus-auth`로 전달
+
+즉 겉으로 보기에는 전용 서버처럼 보이지만, 실제 초기 운영은 기존 인프라 안의 독립 서비스로 시작할 수 있다.
+
+이 구조의 핵심은 아래다.
+
+- 주소는 분리
+- 실행 프로세스도 분리
+- 설정값도 분리
+- 배포도 분리
+- 다만 물리 장비는 처음엔 공유 가능
+
+## 5.6-C `tdc114plus-auth`는 같이 둘 수 있는데, `tdc114plus` 앱은 왜 다르게 보나
+
+이 부분도 자주 헷갈릴 수 있다.
+
+### `tdc114plus-auth`
+
+`tdc114plus-auth`는 서버 프로그램이다.
+
+즉 실제로 서버 위에서 계속 실행되어야 하는 대상이므로, Baron SSO 인프라 안의 독립 서비스로 두는 개념이 성립한다.
+
+### `tdc114plus`
+
+반면 `tdc114plus`는 모바일 앱 소스코드와 빌드 산출물이다.
+
+즉 서버에서 계속 떠 있는 운영 프로세스가 아니라 아래 성격에 가깝다.
+
+- 개발 대상
+- 빌드 대상
+- 배포 대상
+- 휴대폰에 설치되는 결과물
+
+그래서 `tdc114plus-auth`를 같은 서버 인프라 안의 독립 서비스로 둔다는 개념을 그대로 앱 저장소에 적용하면 안 된다.
+
+## 5.6-D 그럼 `tdc114plus` 앱 소스코드를 Baron SSO 쪽에 같이 두는 것은 어떤가
+
+기술적으로 저장소를 한곳에 둘 수는 있다.
+
+하지만 현재 프로젝트 기준으로는 권장하지 않는다.
+
+이유는 아래와 같다.
+
+1. 책임이 다르다
+- `tdc114plus`는 모바일 앱이다
+- Baron SSO는 인증 본체다
+- `tdc114plus-auth`는 앱 전용 중계서버다
+
+2. 배포 시점이 다르다
+- 앱 배포
+- auth 서버 배포
+- Baron SSO 배포
+
+이 셋은 서로 다른 주기로 움직일 수 있어야 한다.
+
+3. 커밋과 리뷰 경계가 다르다
+- 앱 화면 수정
+- 인증 서버 수정
+- SSO 본체 수정
+
+이것이 한 저장소에 섞이면 추적과 검토가 어려워진다.
+
+4. 보안과 권한 경계가 다르다
+- 앱 개발자
+- auth 운영자
+- Baron SSO 운영자
+
+각자 접근 범위가 달라질 수 있다.
+
+그래서 현재 기준 추천 구조는 아래다.
+
+- `tdc114plus`: 별도 저장소
+- `tdc114plus-auth`: 별도 저장소
+- Baron SSO: 기존 저장소 유지
+
+단, `tdc114plus-auth` 실행 위치는 초기에는 Baron SSO 운영 인프라 안의 독립 서비스일 수 있다.
+
+## 5.6-E 한 줄로 정리하면
+
+아래처럼 기억하면 가장 쉽다.
+
+- `tdc114plus-auth`는 같은 서버 인프라 안에 둘 수 있다
+- 하지만 Baron SSO와 같은 서비스는 아니다
+- `tdc114plus` 앱은 같은 저장소나 같은 관리 경계에 섞지 않는 편이 낫다
+- 즉 서버 위치 공유는 가능하지만, 저장소와 서비스 경계까지 합치는 것은 권장하지 않는다
+
 ## 5.7 `tdc114plus-auth` 배포를 아주 쉽게 설명하면
 
 초보자 기준으로 가장 먼저 이해해야 할 점은 아래다.