# Baron SSO 작업 타임라인 보고서

## 1. 보고 목적

본 문서는 2026-06-10 기준 Baron SSO 저장소에 대해 진행한 분석 및 로컬 실행 준비 작업의 흐름을 시간 순서대로 정리한 보고서입니다. 사용자의 지시 내용, 확인한 사항, 발생한 문제, 검증 방법, 해결 결과 및 현재 잔여 이슈를 함께 기록합니다.

## 2. 작업 개요

- 대상 저장소: Baron SSO
- 작업 목적:
  - 시스템 구조 분석
  - 문서화
  - 로컬 브라우저 실행 방법 파악
  - 로컬 `.env` 구성
  - Docker 기반 실행 준비
  - 현재 환경의 미비점 식별

## 3. 타임라인별 작업 내역

### 단계 1. 저장소 구조 및 시스템 성격 분석 요청

#### 사용자 지시
- 코드 파일들을 먼저 분석하고, `docs` 디렉토리에 Baron SSO 구조 분석 문서를 생성해 달라는 요청
- 문서 파일명: `baronsso_structure_analysis.md`
- 포함 내용:
  - 어떤 시스템인지
  - 아키텍처가 어떻게 되어 있는지
  - 개발 기술 스택 요약

#### 수행한 작업
- 저장소의 핵심 문서와 설정 파일을 확인함
- 주요 확인 대상:
  - `README.md`
  - `docker-compose.yaml`
  - `compose.infra.yaml`
  - `compose.ory.yaml`
  - `backend/go.mod`
  - `adminfront/package.json`
  - `devfront/package.json`
  - `orgfront/package.json`
  - `userfront/pubspec.yaml`
  - `pnpm-workspace.yaml`

#### 확인 결과
- Baron SSO는 단순 로그인 페이지가 아니라 멀티테넌트 SSO/IAM 운영 플랫폼 성격의 시스템으로 판단됨
- 핵심 아키텍처는 self-hosted Ory Stack(Kratos, Hydra, Keto, Oathkeeper)을 중심으로 구성됨
- Baron Backend는 Go + Fiber 기반 비즈니스/운영 API 서버 역할
- 프론트엔드는 역할별로 분리되어 있음
  - `userfront`: Flutter 기반 사용자 UI
  - `adminfront`: React/Vite 기반 관리자 UI
  - `devfront`: React/Vite 기반 개발자 UI
  - `orgfront`: React/Vite 기반 조직/시각화 UI
- 데이터 저장소로 PostgreSQL, ClickHouse, Redis 사용
- Docker Compose 기반 멀티 서비스 구조임

#### 산출물
- `docs/baronsso_structure_analysis.md` 생성 완료

#### 검증
- 생성된 Markdown 파일에 대해 오류 진단 수행
- 결과: 오류 없음

#### 해결/결론
- 시스템 구조 분석 및 문서화 작업 완료

---

### 단계 2. 브라우저에서 어떤 주소를 띄워야 하는지 확인 요청

#### 사용자 지시
- 분석 결과를 바탕으로 브라우저에서 어떤 창을 띄워야 하는지 알려 달라는 요청

#### 수행한 작업
- 실행 절차와 노출 포트를 확인하기 위해 다음 자료를 검토함
  - `Makefile`
  - `README.md`의 실행 절차 섹션
  - 각 frontend의 README/패키지 구성

#### 확인 결과
- 기본 사용자 화면은 `userfront`
- 로컬 브라우저 기본 진입 주소는 `http://localhost:5000`
- 추가 접속 대상은 다음과 같음
  - `http://localhost:5173`: adminfront
  - `http://localhost:5174`: devfront
  - `http://localhost:5175`: orgfront
  - `http://localhost:3000/health`: backend health check

#### 문제점
- 샘플 환경변수 파일의 일부 URL이 운영/스테이징 도메인 기준이어서 그대로 사용할 경우 로컬 로그인 리다이렉트가 꼬일 가능성이 있었음

#### 확인 방법
- `.env.sample`의 URL 관련 항목과 README의 callback 규칙을 대조함

#### 해결/결론
- 로컬에서는 `localhost` 기준 URL로 재정의해야 한다는 결론 도출

---

### 단계 3. Laragon 하위 배치 필요 여부 및 현재 환경 미비점 점검 요청

#### 사용자 지시
- Laragon 디렉토리 하위에 위치시켜야 하는지
- 현재 환경 셋팅에서 부족한 점이 무엇인지 확인해 달라는 요청

#### 수행한 작업
- 실제 로컬 환경의 도구 설치 상태를 점검함
- 점검 대상:
  - Docker
  - make
  - bash
  - go
  - flutter
  - node
  - pnpm
  - git
  - `.env` 존재 여부
  - `config/.generated/auth-config.env` 존재 여부
  - Docker 엔진 파이프 상태

#### 확인 결과
- 설치/확인됨:
  - Docker CLI
  - bash
  - node
  - git
- 미설치 또는 미확인:
  - make
  - go
  - flutter
  - pnpm
- 당시 기준 `.env` 없음
- 당시 기준 `config/.generated/auth-config.env` 없음
- 당시 Docker 엔진 연결이 정상 동작하지 않았음

#### 문제점
- Docker 클라이언트는 있었으나 엔진 연결이 불안정하거나 미기동 상태였음
- 실행에 필요한 `.env`와 auth config 생성 파일이 없음
- 로컬 네이티브 개발 도구 일부가 누락되어 있었음

#### 확인 방법
- PowerShell에서 각 명령어의 존재 여부와 버전 확인
- Docker 연결 확인

#### 해결/결론
- Laragon 하위에 둘 필요는 없고, 본 프로젝트는 이미 Docker Compose 기반으로 구성되어 있으므로 별도 Laragon 환경은 불필요하다고 판단
- 핵심 미비점은 Laragon이 아니라 Docker 엔진 상태, `.env`, auth config, 네트워크/레지스트리 접근성이라는 점을 정리

---

### 단계 4. 포트포워딩만 하면 되는지, 현재 상태 기준 작업 순서 정리 요청

#### 사용자 지시
- Docker는 설치돼 있는 것 같고 포트포워딩만 하면 될 것 같은데, 현재 상황을 파악해서 작업 순서를 알려 달라는 요청

#### 수행한 작업
- 현재 포트 사용 현황과 환경 파일 존재 여부를 재확인함
- 확인 포트:
  - 3000
  - 5000
  - 5173
  - 5174
  - 5175
  - 5432
  - 6389
  - 8123

#### 확인 결과
- 대부분 포트는 비어 있었음
- `5432`는 이미 다른 프로세스가 점유 중이었음
- `.env`와 `config/.generated/auth-config.env`는 여전히 없었음

#### 문제점
- Baron SSO의 PostgreSQL 기본 포트와 기존 로컬 PostgreSQL 또는 다른 서비스 포트가 충돌할 가능성이 있었음
- 포트포워딩만으로 해결되는 상황이 아니라, 리다이렉트 URL과 auth config 생성이 선행되어야 했음

#### 확인 방법
- PowerShell의 포트 점유 확인 명령 사용

#### 해결/결론
- `DB_PORT`를 `5433`으로 조정하는 방향을 제안함
- 실행 전에 `.env`와 `config/.generated/auth-config.env`를 반드시 준비해야 한다고 정리함

---

### 단계 5. `.env.sample` 기준으로 로컬 `.env` 초안 정리 요청

#### 사용자 지시
- `.env.sample`을 참조해서 로컬 실행용 `.env`를 정리해 달라는 요청

#### 수행한 작업
- `.env.sample`을 기반으로 운영 도메인을 모두 localhost 기준으로 바꾸는 로컬용 설정 초안을 작성함

#### 핵심 반영 사항
- `USERFRONT_URL=http://localhost:5000`
- `OATHKEEPER_PUBLIC_URL=http://localhost:5000`
- `HYDRA_PUBLIC_URL=http://localhost:5000/oidc`
- `KRATOS_BROWSER_URL=http://localhost:5000/auth`
- `KRATOS_UI_URL=http://localhost:5000`
- `ADMINFRONT_URL=http://localhost:5173`
- `DEVFRONT_URL=http://localhost:5174`
- `ORGFRONT_URL=http://localhost:5175`
- `DB_PORT=5433`

#### 문제점
- 기존 `.env.sample`에는 운영 도메인 기준 URL이 들어 있어 로컬 테스트에 그대로 쓰기 부적절했음

#### 확인 방법
- `.env.sample`의 URL/콜백 관련 항목을 로컬 실행 목적에 맞게 재해석함

#### 해결/결론
- 로컬 `.env` 초안 확정

---

### 단계 6. 실제 `.env` 생성 및 auth config 생성 요청

#### 사용자 지시
- 위에서 정리한 로컬 `.env`를 실제로 적용해 바로 진행해 달라는 요청

#### 수행한 작업
- 저장소 루트에 `.env` 파일 생성
- 내용은 localhost 기반, `DB_PORT=5433`, 로컬 callback 기반으로 구성

#### 산출물
- 루트 `.env` 생성 완료

#### 문제점 1
- `scripts/auth_config.sh build` 실행 시 WSL 경로 인코딩 문제 발생
- 경로에 한글/공백이 포함되어 있어 WSL 변환 경로에서 `cd`가 실패함

#### 확인 방법 1
- WSL bash 경유 실행
- Git Bash 경유 실행
- 경로 문자열 확인

#### 해결 1
- PowerShell에서 저장소 디렉토리로 먼저 이동한 뒤, 현재 작업 디렉터리를 Git Bash가 그대로 상속받도록 실행 방식 변경
- 그 결과 경로 이동 문제 없이 스크립트 실행 성공

#### 검증 결과
- `scripts/auth_config.sh build` 성공
- 생성 파일:
  - `config/.generated/auth-config.env`

#### 추가 확인 내용
- 스크립트 출력 기준 정상 생성 로그 확인
- `hydra_url_match_mode: mapped_match`
- admin/dev/org callback 인식 확인

#### 해결/결론
- `.env`와 `auth-config.env` 생성 완료

---

### 단계 7. Docker 네트워크 준비 및 스택 기동 시도

#### 사용자 지시
- 로컬 실행을 바로 진행하는 방향으로 계속 작업

#### 수행한 작업
- Docker Compose에서 요구하는 외부 네트워크를 생성함
- 생성/확인한 네트워크:
  - `baron_net`
  - `ory-net`
  - `hydranet`
  - `kratosnet`
  - `public_net`

#### 이후 수행한 작업
- 아래 명령과 동일한 방식으로 infra + Ory stack 기동 시도
  - `docker compose --env-file .env --env-file config/.generated/auth-config.env -f compose.infra.yaml -f compose.ory.yaml up -d`

#### 문제점
- Docker Hub 레지스트리 이미지 pull 단계에서 실패
- 핵심 오류:
  - `lookup registry-1.docker.io: no such host`

#### 확인 방법
- Docker Compose pull 로그 확인
- 오류 메시지로 DNS/프록시/레지스트리 접근 문제 판단

#### 해결 상태
- 아직 완전 해결되지 않음
- 현재는 Docker Desktop이 외부 레지스트리(`registry-1.docker.io`)에 접근하지 못하는 상태로 판단됨

#### 현재 판단
- 문제의 본질은 포트포워딩이 아니라 Docker Desktop 네트워크 또는 사내 프록시/DNS 설정임

---

### 단계 8. 사내 프록시 주소 정보가 `.env.sample`에 있는지 확인 요청

#### 사용자 지시
- 사내 프록시 주소 정보가 `.env.sample` 파일에 있는지 확인해 달라는 요청

#### 수행한 작업
- `.env.sample`과 저장소 전체에서 다음 키워드를 검색함
  - `proxy`
  - `HTTP_PROXY`
  - `HTTPS_PROXY`
  - `NO_PROXY`
  - `http_proxy`
  - `https_proxy`
  - `no_proxy`

#### 확인 결과
- `.env.sample`에는 사내 HTTP/HTTPS 프록시 주소 관련 변수는 없음
- `.env.sample`의 `Proxy/Handoff` 섹션은 서비스 내부 공개 URL 라우팅 목적이지, 회사망 프록시 설정 목적이 아님

#### 문제점
- 사용자가 필요로 한 것은 Docker Desktop이 외부 인터넷에 접속하기 위한 프록시 설정이었지만, 저장소 `.env`에는 해당 정보가 없음

#### 확인 방법
- `.env.sample` 직접 검색
- 전체 저장소 텍스트 검색

#### 해결/결론
- 사내 프록시 주소는 저장소 내부 파일보다 다음 위치에서 확보해야 한다고 정리함
  - Docker Desktop 설정
  - Windows 환경변수
  - 사내 네트워크 문서 또는 IT 인프라팀 제공 정보

---

### 단계 9. 최근 터미널 수동 명령 실행 내역 반영

#### 사용자 수행 명령
- PowerShell Extension 터미널에서 `cd baron-sso` 실행

#### 실행 당시 정보
- 작업 전 현재 디렉터리: `C:\Users\user\Desktop\안건 파일\code_test`
- 명령 실행 후 대상 디렉터리: `C:\Users\user\Desktop\안건 파일\code_test\baron-sso`
- 종료 코드: `0`

#### 확인 결과
- 사용자가 저장소 루트 디렉터리로 정상 진입한 것으로 확인됨

#### 보고 의미
- 이후 Docker Compose 명령, `.env` 확인, 설정 파일 검토 등의 후속 작업을 저장소 루트 기준으로 수행할 수 있는 상태가 되었음을 보여주는 실행 이력임

---

### 단계 10. Docker Desktop 재시작 이후 infra + Ory stack 재기동 및 1차 실패 분석

#### 사용자 지시
- Docker Desktop을 다시 재시작했으니 현재 어디까지 진행됐는지 확인하고, 이어서 바로 진행해 달라는 요청

#### 수행한 작업
- Docker 엔진 상태 확인
- `docker pull alpine:latest`로 외부 레지스트리 접근 재검증
- infra + Ory stack 재기동 시도
- 실패 컨테이너 로그와 이미지 단독 실행 결과 확인

#### 확인 결과
- Docker Desktop 엔진 자체는 정상 동작함
- `docker pull alpine:latest` 성공으로 Docker Hub 접근 문제는 해소된 것으로 확인됨
- 그러나 stack 기동 과정에서 아래 이미지들이 `exec format error`로 실패함
  - `postgres:17-trixie`
  - `clickhouse/clickhouse-server:latest`

#### 문제점
- 초기에는 DNS/프록시 문제로 추정했으나, 재시작 후에는 이미지 태그 호환성 문제가 실제 실패 원인으로 드러남
- 특히 Ory Postgres와 ClickHouse가 기동 전에 즉시 종료되어 이후 Ory 서비스 전체가 연쇄적으로 생성 상태에 머무름

#### 확인 방법
- `docker compose ... up -d` 로그 확인
- `docker logs ory_postgres`
- `docker run --rm postgres:17-trixie postgres --version`
- `docker run --rm clickhouse/clickhouse-server:latest clickhouse-server --version`

#### 해결
- 저장소 내 다른 템플릿과 CI 사용 태그를 대조함
- 로컬 실행용 태그를 다음과 같이 조정함
  - `ORY_POSTGRES_TAG=17-alpine`
  - `CLICKHOUSE_TAG=24.6`
- 관련 반영 파일:
  - `.env`
  - `.env.sample`
  - `compose.infra.yaml`
  - `compose.ory.yaml`

#### 검증 결과
- `postgres:17-alpine` 단독 실행 성공
- `clickhouse/clickhouse-server:24.6` 단독 실행 성공
- 재기동 시 `ory_postgres`, `baron_clickhouse`, `ory_clickhouse`가 정상 기동됨

#### 해결/결론
- Docker Desktop 재시작 후 네트워크 문제는 해소되었고, 실제 잔여 문제는 일부 이미지 태그 선택 문제였음

---

### 단계 11. Oathkeeper 생성물 누락 및 Ory 설정 검증 실패 수정

#### 사용자 지시
- stack 기동을 계속 진행하여 실제 서비스가 올라오게 해 달라는 요청

#### 수행한 작업
- `ory_oathkeeper` 실패 로그 확인
- `config/.generated/ory/oathkeeper` 디렉터리 상태 확인
- Ory 설정 렌더 스크립트 재실행
- 이후 Kratos/Hydra 실패 로그 추가 분석

#### 확인 결과
- `ory_oathkeeper`는 `/etc/config/oathkeeper/entrypoint.sh`를 찾지 못해 시작 실패
- 원인은 `config/.generated/ory/oathkeeper` 디렉터리가 비어 있었기 때문임
- `scripts/render_ory_config.sh` 실행 시 Windows CRLF 개행 때문에 `.env` source 단계에서 오류 발생
- 이를 우회해 렌더링 후에는 Oathkeeper 생성물이 정상 생성됨
- 그 다음 단계에서 Kratos/Hydra가 아래 설정 검증 오류로 종료됨
  - Kratos: `selfservice.allowed_return_urls` 항목 중 `[]`가 배열 값으로 들어감
  - Hydra: `SECRETS_SYSTEM` 길이가 16자 미만이라 검증 실패

#### 문제점
- `.generated/ory` 산출물이 빠져 있으면 compose 설정이 맞아도 Oathkeeper가 시작되지 않음
- 로컬 `.env` 값 중 `KRATOS_ALLOWED_RETURN_URLS_EXTRA=[]`가 의도와 다르게 실제 배열 항목으로 렌더됨
- Hydra가 DB 비밀번호(`orysecret`)를 시스템 시크릿으로 재사용하고 있었는데, 길이 정책을 만족하지 못함

#### 확인 방법
- `docker logs ory_oathkeeper`
- `docker logs ory_kratos`
- `docker logs ory_hydra`
- 렌더된 `config/.generated/ory/kratos/kratos.yml` 확인

#### 해결
- LF 개행 임시 파일을 사용해 `scripts/render_ory_config.sh`를 재실행하여 `config/.generated/ory` 재생성
- `.env`에서 `KRATOS_ALLOWED_RETURN_URLS_EXTRA`를 빈 값으로 정리
- `.env`에 `HYDRA_SYSTEM_SECRET` 추가
- `compose.ory.yaml`에서 Hydra가 `SECRETS_SYSTEM=${HYDRA_SYSTEM_SECRET:-${ORY_POSTGRES_PASSWORD}}`를 사용하도록 수정
- `.env.sample`에도 동일 정책 반영

#### 검증 결과
- 생성 파일 확인:
  - `config/.generated/ory/oathkeeper/entrypoint.sh`
  - `config/.generated/ory/oathkeeper/oathkeeper.yml`
  - `config/.generated/ory/oathkeeper/rules*.json`
- 재기동 후 `ory_kratos`, `ory_hydra`, `ory_keto`, `ory_oathkeeper`, `ory_vector` 정상 기동
- `ory_stack_check`와 `baron-sso-init-rp-1`이 `Exited (0)`로 완료됨

#### 추가 확인 내용
- Hydra RP 초기화 결과로 아래 클라이언트 등록 성공 확인
  - `adminfront`
  - `devfront`
  - `orgfront`
  - `oathkeeper-introspect`

#### 해결/결론
- Ory stack 전체가 초기화와 내부 readiness 검증까지 통과함

---

### 단계 12. app stack 기동 시 backend DB 포트 오설정 문제 수정

#### 사용자 지시
- 다음 작업을 계속 진행해 로컬 브라우저 접속까지 가능하게 해 달라는 요청

#### 수행한 작업
- `docker-compose.yaml` 기준 app stack 서비스 확인
- `backend`, `userfront`, `adminfront`, `devfront`, `orgfront` 기동 시도
- 실패한 `backend` 로그 확인

#### 확인 결과
- `adminfront`, `devfront`, `orgfront`는 먼저 기동됨
- `backend`는 PostgreSQL 연결 단계에서 즉시 종료됨
- 핵심 오류:
  - `dial tcp ... postgres:5433: connect: connection refused`

#### 문제점
- 루트 `.env`의 `DB_PORT=5433`은 호스트 포트 충돌 회피용 값인데, backend 컨테이너 내부에서도 그대로 사용되고 있었음
- 컨테이너 내부 네트워크에서는 `postgres:5432`로 붙어야 하므로, 호스트 노출 포트와 컨테이너 내부 접속 포트를 분리해야 했음

#### 확인 방법
- `docker logs baron_backend`
- `docker-compose.yaml`의 backend environment 확인
- backend 코드에서 `DB_PORT` 사용 위치 확인

#### 해결
- `docker-compose.yaml`의 backend 환경변수에 `DB_PORT=5432`를 명시적으로 추가하여 컨테이너 내부 접속 포트를 고정함

#### 검증 결과
- 재기동 후 `baron_backend`가 `healthy` 상태로 전환됨
- 이어서 `baron_userfront`도 정상 기동됨

#### 해결/결론
- 호스트 포트 회피용 설정과 컨테이너 내부 서비스 포트를 분리하여 backend 기동 문제 해결

---

### 단계 13. 로컬 브라우저 진입 주소 최종 검증

#### 사용자 지시
- 지금 상태에서 실제 접속 가능한지까지 확인해 달라는 요청

#### 수행한 작업
- app-facing 컨테이너 상태 확인
- localhost 주소별 HTTP 응답 확인

#### 확인 결과
- 정상 기동 확인 서비스
  - `baron_backend`
  - `baron_userfront`
  - `baron_adminfront`
  - `baron_devfront`
  - `baron_orgfront`
  - `baron_gateway`
- `baron_gateway`도 최종적으로 `healthy` 상태 확인
- HTTP 응답 코드 확인 결과
  - `http://localhost:5000` -> `200`
  - `http://localhost:5173` -> `200`
  - `http://localhost:5174` -> `200`
  - `http://localhost:5175` -> `200`

#### 실패했던 부분
- 초기에는 `baron_gateway`가 `baron_userfront could not be resolved` 오류로 unhealthy 상태였음
- 이는 userfront가 아직 뜨지 않았기 때문이며, app stack이 정상 기동된 뒤 해소됨

#### 해결/결론
- Baron SSO 로컬 실행 스택이 브라우저 접속 가능한 상태까지 도달함

---

### 단계 14. Docker Desktop 제거 후 WSL Docker 환경 재점검

#### 사용자 지시
- 기존 Docker Desktop을 제거하고 WSL에 Docker를 설치했으니 다시 작업을 이어가 달라는 요청

#### 수행한 작업
- Windows PowerShell과 WSL Ubuntu 양쪽에서 Docker CLI/엔진 상태를 재확인함
- 기존 Baron SSO 관련 컨테이너, 네트워크, 볼륨 존재 여부를 점검함
- 저장소 내부 `.env`, 생성된 auth config, compose 파일은 그대로 유지되는지 확인함

#### 확인 결과
- Windows PowerShell 기준으로는 `docker`가 PATH에 없어 직접 실행되지 않았음
- WSL Ubuntu 내부에는 `/usr/bin/docker`가 존재했고 Docker 엔진도 정상 응답했음
- 다만 새 WSL Docker 엔진에는 기존 Baron SSO 컨테이너/네트워크가 남아 있지 않았음
- 저장소 내부의 `.env`, `config/.generated/auth-config.env`, 렌더된 Ory 설정 파일은 유지되고 있었음

#### 문제점
- 런타임 리소스는 초기화되었지만 저장소 설정 파일은 남아 있어, 환경 자체를 다시 만드는 것이 아니라 WSL 엔진 기준으로 stack만 재기동해야 하는 상태였음

#### 확인 방법
- PowerShell과 WSL에서 각각 Docker 명령 실행 가능 여부 확인
- `docker ps -a`, `docker network ls`로 기존 리소스 상태 점검

#### 해결/결론
- 이후 작업은 Windows Docker Desktop 기준이 아니라 WSL Ubuntu 내부 Docker 엔진 기준으로 진행하기로 정리함

---

### 단계 15. Debian trixie-slim 기반 이미지 정책 반영

#### 사용자 지시
- Docker를 Debian trixie (slim) 베이스 이미지 기반으로 맞출 수 있는 부분은 반영해 달라는 요청

#### 수행한 작업
- 저장소 내 커스텀 이미지 Dockerfile과 helper 서비스 이미지를 검토함
- 외부 공식 이미지와 저장소 내부에서 직접 빌드하는 이미지를 구분해 수정 범위를 정함
- backend, gateway, adminfront, devfront, orgfront, userfront 및 일부 helper 컨테이너를 trixie/trixie-slim 기반으로 조정함
- userfront의 기본 빌드 타깃을 production으로 사용하도록 `.env.sample` 정책도 맞춤

#### 확인 결과
- 다음 커스텀 이미지들은 Debian trixie 또는 trixie-slim 기반으로 전환 가능했음
  - `backend/Dockerfile`
  - `gateway/Dockerfile`
  - `adminfront/Dockerfile`
  - `devfront/Dockerfile`
  - `orgfront/Dockerfile`
  - `userfront/Dockerfile`
- helper 서비스도 다음과 같이 조정함
  - `compose.ory.yaml`의 `oathkeeper_logs_init`, `ory_stack_check`
  - `docker-compose.yaml`의 `infra_check`
- 반면 다음 외부 공식 이미지는 저장소 안에서 베이스 OS를 직접 통제할 수 없었음
  - `postgres`
  - `redis`
  - `clickhouse/clickhouse-server`
  - `oryd/*`
  - `ghcr.io/cirruslabs/flutter`

#### 문제점
- Alpine 전용 패키지 설치 명령과 Nginx 설정 경로를 Debian 계열에 맞게 바꿔야 했음
- userfront의 기존 Brotli 설정은 Debian 패키지 nginx 기본 구성과 맞지 않았음

#### 확인 방법
- 관련 Dockerfile 및 compose 설정 검토
- `docker compose config`와 실제 이미지 빌드로 변경 타당성 확인

#### 해결
- Alpine 기반 `apk` 사용 구문을 `apt-get` 기반으로 변경
- Debian nginx 경로에 맞게 userfront 설정 파일 복사 위치를 `/etc/nginx/conf.d/default.conf`로 조정
- `userfront/nginx.conf`에서 Debian 기본 nginx와 맞지 않는 Brotli 설정 제거
- healthcheck에 필요한 도구를 포함할 수 있도록 Debian 패키지 설치 구성 정리

#### 검증 결과
- WSL Docker 기준으로 커스텀 이미지 빌드 성공 확인
- 주요 빌드 대상:
  - `baron-sso-backend`
  - `baron-sso-gateway`
  - `baron-sso-adminfront`
  - `baron-sso-devfront`
  - `baron-sso-orgfront`
  - `baron-sso-userfront`

#### 해결/결론
- 저장소 내부에서 제어 가능한 범위에 대해서는 Debian trixie-slim 정책을 반영했고, 외부 공식 이미지는 예외로 유지함

---

### 단계 16. WSL Docker 기준 전체 stack 복구 및 최종 정상화

#### 사용자 지시
- trixie-slim 반영 이후 실제 기동까지 계속 진행해 달라는 요청

#### 수행한 작업
- WSL Docker 엔진에 Baron SSO 외부 네트워크를 재생성함
- infra + Ory stack, app stack을 WSL 기준으로 다시 기동함
- 기동 중 실패 컨테이너 로그와 health 상태를 점검하고 문제를 국소 수정함

#### 확인 결과
- 초기 재기동 시 `ory_clickhouse`가 시작 직후 종료됨
- `baron_userfront`, `baron_gateway`는 실제 응답은 가능했지만 healthcheck가 `unhealthy` 상태였음
- 원인 분석 결과:
  - `docker/ory/clickhouse/init.sql`의 TTL 식이 ClickHouse 24.6에서 `DateTime64(3)`와 호환되지 않았음
  - Debian 기반으로 바뀐 `gateway`, `userfront` 이미지에는 healthcheck가 사용하는 `wget`이 빠져 있었음

#### 문제점
- Ory 로그 저장소 초기화 SQL이 새 ClickHouse 버전 제약과 맞지 않아 Ory용 ClickHouse가 안정적으로 올라오지 못했음
- gateway/userfront는 서비스 자체는 떠 있었지만 healthcheck 도구 부재 때문에 compose 상에서 비정상으로 표시됐음

#### 확인 방법
- `docker logs ory_clickhouse`
- `docker inspect baron_gateway`, `docker inspect baron_userfront`
- `Invoke-WebRequest http://localhost:5000`
- WSL 기준 `docker ps` 상태 확인

#### 해결
- `docker/ory/clickhouse/init.sql`의 TTL 식을 `TTL toDateTime(timestamp) + INTERVAL 30 DAY`로 수정
- `gateway/Dockerfile`, `userfront/Dockerfile`에 `wget` 설치를 추가
- 수정된 이미지/서비스만 다시 빌드 및 재기동하여 영향 범위를 최소화함

#### 검증 결과
- 최종 컨테이너 상태 확인:
  - `baron_gateway` healthy
  - `baron_userfront` healthy
  - `baron_backend` healthy
  - `ory_clickhouse` running
  - `ory_hydra`, `ory_keto`, `ory_kratos`, `ory_oathkeeper`, `ory_vector` 정상 실행
- HTTP 응답 코드 확인 결과
  - `http://localhost:5000` -> `200`
  - `http://localhost:5173` -> `200`
  - `http://localhost:5174` -> `200`
  - `http://localhost:5175` -> `200`

#### 추가 확인 내용
- `http://localhost:4457/health/alive`는 `404`를 반환했으며, 이는 public proxy 포트가 일반 앱 health endpoint를 그대로 노출하는 용도가 아님을 보여줌
- Baron/Ory 주요 서비스는 WSL Docker 기준으로 다시 정상화됨

#### 해결/결론
- WSL Docker와 Debian trixie-slim 반영 이후에도 Baron SSO 로컬 실행 스택을 다시 브라우저 접속 가능한 상태까지 복구 완료함

## 4. 현재까지 생성/변경된 주요 파일

- `docs/baronsso_structure_analysis.md`
- `docs/baronsso_docker_container_roles.md`
- `.env`
- `config/.generated/auth-config.env`
- `config/.generated/ory/kratos/kratos.yml`
- `config/.generated/ory/hydra/hydra.yml`
- `config/.generated/ory/keto/keto.yml`
- `config/.generated/ory/oathkeeper/entrypoint.sh`
- `config/.generated/ory/oathkeeper/oathkeeper.yml`
- `compose.infra.yaml`
- `compose.ory.yaml`
- `docker-compose.yaml`
- `.env.sample`
- `backend/Dockerfile`
- `gateway/Dockerfile`
- `adminfront/Dockerfile`
- `devfront/Dockerfile`
- `orgfront/Dockerfile`
- `userfront/Dockerfile`
- `userfront/nginx.conf`
- `docker/ory/clickhouse/init.sql`

## 5. 현재까지 확인된 주요 문제 목록

### 5.1 로컬 환경 및 설정 문제
- 초기에는 `.env`가 없었음
- 초기에는 `config/.generated/auth-config.env`가 없었음
- `5432` 포트가 이미 사용 중이었음
- `make`, `go`, `flutter`, `pnpm`이 로컬에 없음
- 로컬 `.env`의 일부 값이 컨테이너 내부 접속 포트와 외부 노출 포트를 혼용하고 있었음

### 5.2 경로 처리 문제
- 저장소 경로에 한글/공백이 있어 WSL 경유 `bash` 실행 시 경로 변환 실패 발생
- Windows CRLF 개행 때문에 Bash가 `.env`를 직접 source할 때 오류 발생

### 5.3 Docker 이미지 및 런타임 문제
- `postgres:17-trixie`가 로컬 Docker 환경에서 `exec format error`로 실패
- `clickhouse/clickhouse-server:latest`가 로컬 Docker 환경에서 `exec format error`로 실패
- `config/.generated/ory/oathkeeper` 산출물 누락 시 Oathkeeper 시작 실패
- Kratos allowed return URLs 렌더링 값 오류
- Hydra system secret 길이 부족 오류
- Docker Desktop 제거 후 Windows 기준 `docker` PATH와 WSL Docker 엔진 기준 실행 환경이 분리됨
- ClickHouse 24.6에서 Ory init SQL의 TTL 식이 `DateTime64(3)`와 호환되지 않았음
- Debian trixie-slim 전환 후 gateway/userfront healthcheck에 필요한 `wget`이 누락되었음

### 5.4 현재 남아 있는 참고 사항
- gateway는 userfront가 떠 있기 전에는 unhealthy가 될 수 있음
- `DB_PORT=5433`은 호스트 접속용이며, backend 컨테이너 내부 접속은 `5432` 고정이 필요함

## 6. 현재까지 해결된 항목

- Baron SSO 구조 분석 문서 작성 완료
- 로컬 실행용 `.env` 작성 완료
- `config/.generated/auth-config.env` 생성 완료
- Docker 네트워크 생성 완료
- 기본 서비스 포트 점검 완료
- DB 포트 충돌 회피안(`5433`) 반영 완료
- Docker Hub 접근 정상화 확인 완료
- 로컬 호환 태그 기준 Ory Postgres/ClickHouse 기동 완료
- `config/.generated/ory` 재생성 완료
- Ory stack 전체 기동 및 readiness 검증 완료
- Hydra RP 초기화 완료
- backend DB 포트 오설정 수정 완료
- app stack 기동 완료
- localhost 브라우저 진입 주소 응답 확인 완료
- WSL Docker 기준 런타임 재기동 및 네트워크 복구 완료
- Debian trixie-slim 기반 커스텀 이미지 전환 완료
- ClickHouse TTL 호환성 수정 완료
- gateway/userfront healthcheck 정상화 완료

## 7. 현재 미해결 항목

- 현 시점 기준 치명적 미해결 항목 없음
- 다만 실제 로그인/회원가입/OIDC callback까지 포함한 사용자 시나리오 E2E 검증은 아직 별도로 수행하지 않음

## 8. 다음 권장 작업 순서

1. 브라우저에서 `http://localhost:5000`에 접속해 실제 로그인/회원가입 흐름 검증
2. admin/dev/org front에서 OIDC redirect 및 callback 정상 동작 확인
3. 필요 시 현재 로컬 실행용 수정사항을 README 또는 운영 문서에 반영
4. 필요 시 `.env`의 로컬 전용 값과 배포 전용 값을 분리하는 정책 정리

## 9. 최종 요약

이번 작업에서는 Baron SSO 저장소 구조 분석과 문서화에서 출발해, 로컬 `.env` 및 auth config 생성, Docker 네트워크 준비, infra + Ory stack 기동, app stack 기동, 브라우저 접속 검증, 이후 WSL Docker 환경 전환과 Debian trixie-slim 기반 이미지 정책 반영까지 순차적으로 완료했습니다. 진행 중에는 Docker Desktop 재시작 이후 레지스트리 접근 문제, 이미지 태그 호환성 문제, Ory 생성물 누락, Kratos/Hydra 설정 검증 오류, backend DB 포트 오설정, WSL 전환 후 런타임 리소스 재생성, ClickHouse TTL 호환성 문제, gateway/userfront healthcheck 도구 누락 문제가 순차적으로 드러났습니다. 각 문제는 로그, compose 설정, 렌더 결과, 실제 HTTP 응답을 기준으로 원인을 확인한 뒤 태그 조정, 설정 재생성, Dockerfile 수정, compose 환경변수 보정, 국소 재기동으로 해결했습니다. 최종적으로 WSL Docker 기준에서도 `http://localhost:5000`, `http://localhost:5173`, `http://localhost:5174`, `http://localhost:5175`가 모두 `200` 응답을 반환하는 상태까지 복구했습니다.