AI를 기반으로 개발시에는 개발일지를 작성하는 것이 좋습니다.

1. AI와의 협업 효율 극대화 (컨텍스트 복원)

• 새로운 대화창에서도 끊김 없는 작업: AI와의 대화가 길어지거나 며칠 뒤 새 세션을 시작할 때, AI에게 *"어제 개발일지(docs/devlog/...) 읽고 다음 작업 시작해줘"*라고만 하면 AI가 전체 프로젝트 히스토리와 다음 할 일을 1초 만에 파악합니다.
• 같은 오류 반복 방지: AI가 이전에 겪었던 오류나 시도했다가 실패한 방식을 개발일지를 통해 인지하므로, 비효율적인 답변을 반복하지 않습니다.

2. '삽질'의 자산화 (트러블슈팅 시간 절약)

• 미래의 나를 위한 공략집: 개발 중 겪는 라이브러리 충돌, 폰트 깨짐, API 인증 오류 등은 2~3달 뒤에 또 발생할 확률이 높습니다.
• 해결 과정을 일지에 한 번 적어두면, 나중에 동일한 문제가 생겼을 때 몇 시간 동안 구글링할 필요 없이 10초 만에 해결할 수 있습니다.

3. 작업 전환 비용(Context Switching) 제로화

• "어제 어디까지 했더라?" 방지: 퇴근 후나 며칠 쉬고 다시 코드를 열었을 때, 어디서부터 손대야 할지 막막해지는 현상을 완전히 없애줍니다.
• 일지 마지막의 📌 Next Steps(다음 할 일) 체크리스트만 보고 바로 코딩에 몰입할 수 있습니다.

4. "왜 이렇게 짰지?"에 대한 의사결정 기록 (Architecture Decision)

• 코드는 '어떻게(How)' 구현했는지만 보여주지만, 개발일지는 '왜(Why)' 그 라이브러리를 골랐고 그 방식을 택했는지를 남겨줍니다.
• 나중에 코드를 리팩토링하거나 기능을 확장할 때 중요한 나침반 역할을 합니다.

5. 강력한 포트폴리오 & 기술 블로그 콘텐츠

• 프로젝트가 끝난 뒤 포트폴리오나 기술 블로그(Velog, Medium 등)를 쓰려고 하면 기억이 안 나서 막막합니다.
• 매일 누적된 개발일지는 그대로 다듬기만 하면 가장 진정성 있고 설득력 있는 기술 블로그 글이자 포트폴리오가 됩니다.

vs code 또는 Anitigravity에서 다음과 같이 지시합니다.

[ 프롬프트 ]

당신은 이 프로젝트의 테크니컬 리드이자 페어 프로그래머입니다. 우리는 이 프로젝트의 모든 개발 과정을 일자별 개발일지로 투명하게 기록합니다.

[개발일지 작성 규칙]
- 주요 기능 구현이나 리팩토링, 버그 수정이 완료되면 항상 `docs/devlog/` 폴더에 일자별 마크다운 파일(`YYYY-MM-DD.md`)을 생성하거나 갱신합니다.
- 단순 작업 나열이 아니라, "왜 이 기술/라이브러리를 선택했는지", "어떤 오류가 있었고 어떻게 해결했는지"에 대한 기술적 맥락(Context)을 반드시 남깁니다.
- 코드 파일 경로와 함수명은 백틱(`) 또는 마크다운 링크 형식으로 명확히 기재합니다.

[ 개발일지 포맷 예시 ]

# 📅 개발일지: YYYY-MM-DD

## 🎯 오늘의 목표
- [x] Streamlit 기반 기본 UI 대시보드 레이아웃 구성
- [ ] Gemini API 연동 및 프롬프트 파이프라인 테스트

---

## 🛠️ 주요 진행 및 구현 내용

### 1. [컴포넌트/기능명]
- **파일:** `src/components/card_preview.py`, `app.py`
- **구현 세부사항:**
  - 사용자로부터 URL/키워드를 입력받는 사이드바 구현
  - 4:5 비율 카드뉴스 슬라이드 렌더링 영역 배치

### 2. [추가 작업 내용]
- ...

---

## 💡 기술적 의사결정 및 트러블슈팅 (Troubleshooting)

### 1. [문제 발생 상황 또는 고민한 점]
- **문제/이슈:** HTML-to-Image 렌더링 시 한글 폰트가 깨지는 현상 발생
- **원인 분석:** 기본 시스템 폰트에 Noto Sans KR이 누락되어 있음
- **해결 방안:** 웹 폰트(Google Fonts Noto Sans KR)를 인라인 CSS `@import` 방식으로 강제 로드하여 해결

---

## 🧪 테스트 및 검증 결과
- `streamlit run app.py` 로컬 실행 정상 확인
- 샘플 텍스트 입력 시 5장 슬라이드 실시간 미리보기 반응 속도 0.5초 이내 확인

---

## 📌 다음 진행 예정 작업 (Next Steps)
- [ ] Gemini Flash API 연동 모듈 (`src/ai/generator.py`) 구현
- [ ] 슬라이드 텍스트 인라인 편집 상태 관리(Session State) 연결

Windows 11 환경으로 마이그레이션하면서 기존에 사용하던 Informix Client SDK (CSDK) 연동 문제로 고생좀 했습니다.^^

기존 배포파일에 포함된 인포믹스 설치 파일이 없어서 고객사가 제공해준 sdk로 설치를 진행하면서 헤매이었던 과정들을 정리하여 공유 합니다.

크게 1) 아무리 최신 버전(V4.5)을 깔아도 드라이버 인식이 안 되는 문제, 그리고 2) 설치(인스톨러) 화면 자체가 아예 뜨지 않고 튕겨버리는 문제 두 가지 함정에 빠지기 쉽습니다. 오늘은 이 두 가지 문제의 명확한 원인과 확실한 해결법을 총정리해 드립니다.

🚨 함정 1. 버전 아키텍처 불일치 (32비트 앱과 64비트 드라이버)

가장 많이 겪는 착각 중 하나가 "가장 최신 버전인 Informix Client SDK V4.5를 다운받아 설치하면 문제없겠지?"라는 생각입니다.

왜 32비트 애플리케이션에서 64비트 ODBC 드라이버를 쓸 수 없을까?

결론부터 말하자면 "메모리 주소 공간이 완벽히 분리되어 있기 때문"입니다. 64비트 Windows 운영체제에서 32비트 프로그램들은 `WoW64 (Windows 32-bit on Windows 64-bit)`라는 서브시스템(가상의 32비트 격리 공간) 안에서 실행됩니다.

• 32비트 애플리케이션 (예: 기존 PowerBuilder) : 32비트용 DLL 라이브러리만 로드하여 사용할 수 있습니다.
• 64비트 ODBC 드라이버 (CSDK V4.5) : 64비트 메모리 주소를 사용하도록 컴파일되어 있습니다.

즉, 32비트 프로그램이 데이터베이스에 접속하기 위해 64비트 ODBC 드라이버(DLL)에 접근하려고 시도하면 운영체제가 이를 하드웨어 차원에서 차단해버리게 되고, 결국 "드라이버를 찾을 수 없습니다" 또는 연동 실패 에러가 발생하게 되는 것입니다.

🚨 함정 2. 인스톨러 GUI 실행 불가 (OS 인식 오류)

그렇다면 알맞게 V4.10 (32비트) 설치 파일을 다운로드해서 실행해 보려는데... এবার은 설치 창 자체가 안 뜨고 모래시계만 잠깐 돌다가 튕겨버리는 증상이 발생합니다.

✅ 해결 방법: 환경변수(JAVA_TOOL_OPTIONS) 속이기

설치를 진행할 때 인스톨러에게 "이 컴퓨터는 Windows 11이 아니라 Windows 7이야"라고 거짓말을 치면 깔끔하게 해결됩니다.

• 명령 프롬프트를 관리자 권한으로 실행
  작업 표시줄 돋보기 버튼에서 cmd를 검색한 뒤 '관리자 권한으로 실행'을 클릭합니다.
• Java OS Name 환경변수 임시 세팅
  명령 프롬프트 창에 아래 명령어를 입력하고 엔터를 누릅니다.
  

  set "JAVA_TOOL_OPTIONS=-Dos.name=Windows 7"

• 설치 파일 경로로 이동 및 실행
  cd 명령어로 설치 파일이 있는 경로로 이동한 뒤 설치 파일 .exe를 실행합니다.
  

  cd C:\Users\사용자\Downloads\Informix_SDK_4.10_32bit
  installclientsdk.exe

CMD 창에 Picked up JAVA_TOOL_OPTIONS: -Dos.name=Windows 7 이라는 문구가 출력되면서, 실패했던 마법사 UI 창이 정상적으로 로딩되고 무사히 설치를 완료할 수 있습니다.

🚨 함정 3. 마이그레이션 후 DB 접속 언어셋(Locale) 에러 (-23197, -23101)

CSDK 마이그레이션(예: V2.70 → V4.10) 후 기존 파워빌더 등에서 DB 접속 시 다음과 같은 언어셋 에러가 발생하는 경우가 많습니다.

• SQL Error -23197 : Database locale information mismatch
• SQL Error -23101 : Unable to load locale categories (언어셋을 euc-kr 등으로 임의 입력했을 때 발생)

왜 구버전에서는 잘 되었는데 지금은 안 될까?

가장 큰 원인은 신버전 CSDK의 엄격해진 GLS(Global Language Support) 검증 로직 때문입니다.

과거 구버전(V2.70)은 DB_LOCALE이나 CLIENT_LOCALE 값이 비어있어도 느슨하게 파싱하여 접속을 허용(가비지 인 가비지 아웃)했습니다. 하지만 신버전(V4.10)은 클라이언트가 설정한 로케일 값과 DB 서버가 실제로 생성될 때 세팅된 로케일 값이 100% 일치하지 않으면 접속을 원천 차단(-23197)합니다. 또한 Informix는 고유의 언어셋 명칭 규칙(`언어_국가.코드셋`)을 따르므로 통상적인 euc-kr은 인식하지 못해 -23101 에러를 발생시킵니다.

⚠️ 추가 주의사항 (비밀번호 및 레지스트리 경로)

최신 CSDK 4.10 부터는 보안 정책 강화로 인해 Setnet32에 Host Password 저장을 지원하지 않습니다. 비밀번호는 직접 애플리케이션의 Connection String에 전달하는 방식으로 접속 로직을 런타임으로 변경해야 합니다.

또한, 64비트 OS(Windows 11)에서 기존 32비트 CSDK 설정(.reg 백업본)을 임포트할 때는 반드시 HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Informix 하위 경로에 적용되도록 관리자 권한으로 설정해 주셔야 합니다.

마치며

설치가 완료된 후에는 32비트 환경 통신 및 레지스트리 세팅을 위해 setnet32.exe를 실행하여 환경을 구성해 줍니다. 그리고 제어판의 기본 ODBC가 아닌 반드시 C:\Windows\SysWOW64\odbcad32.exe (32비트 ODBC 관리자)를 열어 시스템 DSN을 등록해 주어야 기존 32비트 애플리케이션에서 문제없이 데이터베이스에 연결할 수 있습니다.

마이그레이션 과정에서 저와 같은 삽질을 겪고 계신 개발자분들께 큰 도움이 되길 바랍니다. 💪

🚀 TistoAI 시스템 고도화

실시간 데이터 연동 엔진 업데이트

1차 개발후 사용해보니, 카테고리별 핫 토픽을 조회하니 뭔가 과거 데이터를 가져오는 것이었습니다.

역시나, AI로 개발을 해보면 내가 원하는 방향으로 기획으로 AI가 개발을 진행했는지 끊임없이 의심하고 검증 해볼 필요가 있습니다.

다음은 개발 분석을 통해서 검색 엔진을 고도화한 내용입니다.

이번 업데이트에서는 사용자가 프로그램을 실행하는 바로 그 순간(실시간 기준일)의 최신 핫토픽과 정책 뉴스를 100% 반영하도록 카테고리별 검색 알고리즘과 LLM 프롬프트 파이프라인을 전면 개편하였습니다.

1. 2024년 과거 데이터 생성 원인 분석 (Root Cause)

기존 시스템에서 과거 2024년 기준의 내용이 출력되었던 핵심 원인은 다음 3가지였습니다:

1. 프롬프트 내 동적 날짜(Timestamp) 미주입:
   기존 프롬프트에는 단순히 '오늘 발표된 뉴스'라는 추상적인 단어만 주어졌습니다. LLM(Gemini) 모델 특성상 명확한 현재 연도(2026년)와 날짜 기준이 없으면 자체 사전 학습 데이터의 최신 커트라인 시점(2024년)을 기본 '오늘'로 판단하는 경향이 있었습니다.
2. Search Grounding 할당량 초과 시 지식 커트라인 회귀:
   실시간 구글 웹 검색 API(google_search) 호출 중 분당/일일 쿼터 초과(429 Error) 시 내장 지식으로 자동 전환(Fallback)되면서 2024년 데이터가 그대로 노출되었습니다.
3. 글 생성(generate_blog_post) 시 본문 세부 검증 부재:
   주제는 최신 키워드였더라도, 실제 본문 HTML을 생성하는 과정에서 실시간 웹 검색 및 날짜 가이드가 적용되지 않아 본문 세부 지원금 수치와 조건이 2024년 구 버전으로 작성되었습니다.

2. TistoAI 카테고리별 실시간 검색 기준 및 로직

TistoAI는 총 5가지 핵심 카테고리를 제공하며, 각 분야에 최적화된 실시간 검색 키워드 및 구글 뉴스 RSS 파이프라인을 통해 고단가·고유입 주제를 추출합니다.

3. 핵심 시스템 개선 사항 (Engine Upgrades)

① 실행 시점 동적 타임스탬프(datetime.now()) 100% 자동 연동

사용자가 조회를 실행하고 글 생성을 누르는 바로 그 순간의 컴퓨터 실시간 날짜를 읽어와 프롬프트 최상단에 자동 인젝션합니다:

today_str = datetime.now().strftime("%Y년 %m월 %d일")
current_year = datetime.now().year
# -> [작성 기준일]: 2026년 08월 19일 (현재 연도: 2026년) 자동 주입

[시점 최신성 엄수 규칙]을 명시하여 2024년 등 과거 연도의 지원금 액수나 정책 기준이 본문에 섞이는 현상을 완벽히 차단했습니다.

② 구글 뉴스 RSS 2차 방어막(Fallback) 구축

Gemini API의 실시간 Search Grounding 툴 할당량이 초과되더라도, Google News RSS 파서가 당일 실제 언론사 및 정부 브리핑 헤드라인을 실시간 수집하여 LLM에 전달합니다. 따라서 100% 팩트 기반의 최신 핫뉴스 주제를 반환합니다.

③ 본문 포스팅 생성 시 실시간 웹 검색 및 최신성 검증 보장

주제 선정뿐만 아니라 '글 생성' 단계에서도 Google Search Grounding을 동시에 실행하여, 지원금 신청 자격, 세부 금액, 공식 사이트 바로가기 링크까지 현재 시점 기준으로 정밀 작성됩니다.

기존 레거시 윈도우 환경에서 동작하던 다수의 파워빌더(PowerBuilder) 시스템을 최신 컨테이너 기반인 OpenShift (Kubernetes) 환경으로 이관하는 작업을 진행하게 되었습니다. 배포된 모델은 웹을 통해 클라이언트 모듈을 내려받는 파워클라이언트(PowerClient) 구조입니다.

이 포스팅에서는 6개의 업무 시스템(인사, 회계 등)을 어떻게 단일 OpenShift 환경으로 효율적으로 배포하고, 도커(Docker) 이미지 관리를 극대화했는지에 대한 실무 구축기를 공유합니다.

1. 아키텍처 결정: 분리 배포 vs 통합 배포

6개의 업무 시스템 폴더가 나누어져 있었기 때문에 초기에는 6개의 Dockerfile과 6개의 Pod를 띄우는 완전한 마이크로서비스 구성을 고려했습니다. 하지만 인프라 환경에서 단일 도메인(예: https://pb.apps.example.com/)만을 발급받아 라우트(Route)를 통일하는 구조로 결정되었습니다.

2. 껍데기만 남긴 Dockerfile 전략

파워클라이언트 앱은 Java 로직 구동 환경(WAS)이 아닌 HTML, ZIP, PBD를 뿌려주는 정적 웹 리소스에 가깝습니다. 고객사의 표준 배포 이미지가 Tomcat 기반이었지만, 우리는 컨테이너 이미지 자체에 파워클라이언트 배포 파일들을 구워 넣지 않았습니다.

대신 도커 이미지는 껍데기(웹 서버 엔진) 역할만 수행하며, 실제 리소스 파일은 PVC 스토리지를 통해 런타임에 덮어 씌우는 방식을 선택했습니다. 이렇게 함으로써 소스(UI) 수정 시 매번 길고 무거운 Docker 이미지를 재빌드하지 않아도 됩니다.

FROM registry.example.com/base-images/openjdk:v1.0

USER root

# 스토리지(PVC)가 연결될 기본 디렉토리 공간 권한 세팅
WORKDIR /APP/powerbuilder/deploy

RUN chown -R 1001100000:1001100000 /APP/powerbuilder/deploy && \
    chmod -R 750 /APP/powerbuilder/deploy

EXPOSE 8500

USER 1001100000

# 앱 구동 스크립트 실행
CMD ["/APP/powerbuilder/deploy/start_server.sh", "run"]

3. 인프라와 쿠버네티스의 연결 고리: YAML 설정 노하우

단일 이미지를 기반으로 작성한 Deployment.yaml에서는 두 가지 요소가 배포의 핵심이었습니다.

① 필수 볼륨 마운트 (VolumeMounts)
`containers` 영역 내부에 물리 스토리지(PVC)를 특정 동작 런타임 폴더(/APP/powerbuilder/deploy)에 마운트하여, 컨테이너가 켜짐과 동시에 FTP를 통해 업로드해 둔 파워클라이언트 6개 파일 폴더(insa, acc 등)를 인식할 수 있게 만들었습니다.

② subPath를 통한 깔끔한 로그 관리

volumeMounts:
  - name: log-volume
    mountPath: /app/logs
    subPath: powerclient-web/logs

컨테이너 내부는 /app/logs를 쓰면, OpenShift가 자동으로 물리 스토리지 쪽에 powerclient-web/logs 라는 폴더 트리를 생성해주고 거기로 다이렉트를 시키는 subPath 방식을 적용했습니다. (개발자가 굳이 FTP로 접속해서 빈 폴더를 만들어주지 않아도 시스템이 알아서 폴더를 개척해 줍니다!)

4. 요약 및 결론

결과적으로 Git 레포지토리에는 가벼운 형상 관리 셋업용 스크립트 세트(Dockerfile, build.sh, push.sh, config) 단 1개만 올려두고 관리가 가능해졌습니다. OpenShift 인프라 담당자가 PVC 스토리지만 부여해 주면, 쿠버네티스의 자동화 능력을 바탕으로 유연하고 빠른 프론트(Client) 배포 환경이 완성되었습니다.

5. 샘플 코드

1. config (환경 변수 공통 파일)

 역할 : 빌드와 이미지 푸시 스크립트에서 공통으로 사용할 정보를 한곳에서 관리. 나중에 이미지 버전 (v1.0 -> v1.1) 변경될때 이 파일 수정하면 됩니다.

#!/bin/bash
# ========================================================
# 빌드 및 푸시에 사용될 환경 변수 공통 설정
# ========================================================
REGISTRY="quay.apps.cl-hub-test.ocp.kftc.net/my-project"
IMAGE_NAME="powerclient-all-in-one"
TAG="v1.0"

# 최종 이미지 주소 조합
FULL_IMAGE_PATH="${REGISTRY}/${IMAGE_NAME}:${TAG}"

2. build.sh (컨테이너 이미지 빌드 스크립트)

역할 : 작성한 6개 시스템의 소스 파일과 도커파일을 이용해 톰캣이 깔려 있는 하나의 이미지로 굽습니다.

#!/bin/bash
# ========================================================
# Docker / Podman 빌드 스크립트
# ========================================================
source ./config

echo "==========================================="
echo "🚀 6개 시스템 통합 컨테이너 빌드를 시작합니다..."
echo "📦 대상 이미지: $FULL_IMAGE_PATH"
echo "==========================================="

docker build -t $FULL_IMAGE_PATH .

echo ""
echo "✅ 빌드가 완료되었습니다!"

3. push.sh (컨테이너 레지스트리 업로드 스크립트)

역할 : 빌드가 끝난 이미지를 고객사 쿠버네티스(오픈시프트) 환경의 레지스트리로 전송(업로드) 합니다.

#!/bin/bash
# ========================================================
# 컨테이너 레지스트리 푸시 스크립트
# ========================================================
source ./config

echo "==========================================="
echo "☁️ 이미지를 원격 레지스트리로 푸시합니다."
echo "🏷️ 업로드 이미지: $FULL_IMAGE_PATH"
echo "==========================================="

# docker login 명령어로 레지스트리 로그인이 먼저 되어있어야 합니다.
docker push $FULL_IMAGE_PATH

echo ""
echo "✅ 레지스트리 푸시가 완료되었습니다!"

4. server.xml (톰캣 환경설정 파일)

역할 : 1개의 톰캣 엔진 내부에 6개의 시스템(A~F)을 각각 다른 폴더 경로(Context)로 쪼개어 연결해 줍니다.

이렇게 하면 http://URL/system_a 와 같은 형식으로 6개의 웹에 각각 접속 할 수 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
  <Service name="Catalina">
  
    <!-- 고객사에서 지정(가이드)해 준 서비스 포트 (예: 8080 또는 8500) -->
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" URIEncoding="UTF-8" />
               
    <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false">
        
        <!-- [핵심] 6개의 시스템을 단일 톰캣 엔진 내 6개의 별도 앱(Context)으로 분리 -->
        <Context path="/system_a" docBase="system_a" reloadable="false" />
        <Context path="/system_b" docBase="system_b" reloadable="false" />
        <Context path="/system_c" docBase="system_c" reloadable="false" />
        <Context path="/system_d" docBase="system_d" reloadable="false" />
        <Context path="/system_e" docBase="system_e" reloadable="false" />
        <Context path="/system_f" docBase="system_f" reloadable="false" />

      </Host>
    </Engine>
  </Service>
</Server>

5. Dockerfile( 배포 이미지 설계도)

역할 : 톰캣 베이스 이미지 위로 server.xml 환경 설정과, 서버 루트 디렉토리 안에 system_a ~ system_f 소스 폴더(또는 war)를 한번에 copy 해 줍니다.

# 1. 톰캣 기본 베이스 이미지 사용 (고객사 환경에 맞춰 Java 버전 수정 가능)
FROM tomcat:9.0-jdk17-openjdk-slim

# 작업 디렉토리 고정
WORKDIR /usr/local/tomcat

# 2. 통합용 Custom server.xml 덮어쓰기 (6개 Context 맵핑)
COPY server.xml /usr/local/tomcat/conf/server.xml

# 3. 6개의 시스템 소스 코드를 차례대로 복사
COPY ./src/system_a /usr/local/tomcat/webapps/system_a
COPY ./src/system_b /usr/local/tomcat/webapps/system_b
COPY ./src/system_c /usr/local/tomcat/webapps/system_c
COPY ./src/system_d /usr/local/tomcat/webapps/system_d
COPY ./src/system_e /usr/local/tomcat/webapps/system_e
COPY ./src/system_f /usr/local/tomcat/webapps/system_f

# 권한 설정 (컨테이너 내 권한 문제가 없도록)
RUN chmod -R 755 /usr/local/tomcat/webapps

# 방화벽 포트 명시
EXPOSE 8080

# 톰캣 서버 포어그라운드(Background) 실행 방지 -> OpenShift Pod가 종료되지 않게 유지
CMD ["catalina.sh", "run"]

6. deploy.yml (쿠버네티스/오픈시프트 명세서)

역할: 만들어진 1개의 큰 도커 이미지를 쿠버네티스에서 어떻게 띄우고(Deployment), 어떤 네트워크로 연결하며(service), 어떤 외부 주소로 빼줄지(Route)지시 합니다. 단 하나의  Route 도메인만 존재하면 됩니다.

---
# 1. Deployment: 6개 시스템이 들어있는 컨테이너 구동 세팅
apiVersion: apps/v1
kind: Deployment
metadata:
  name: powerclient-allinone-deployment
  labels:
    app: allinone-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: allinone-app
  template:
    metadata:
      labels:
        app: allinone-app
    spec:
      containers:
      - name: tomcat-container
        # config에 명시한 주소 그대로 불러오기
        image: quay.apps.cl-hub-test.ocp.kftc.net/my-project/powerclient-all-in-one:v1.0
        ports:
        - containerPort: 8080   # server.xml 톰캣 포트

---
# 2. Service: 컨테이너 내부 네트워크 맵핑 (LoadBalancer 역할)
apiVersion: v1
kind: Service
metadata:
  name: powerclient-allinone-service
spec:
  selector:
    app: allinone-app
  ports:
    - protocol: TCP
      port: 8080        
      targetPort: 8080  # 톰캣 컨테이너가 열어둔 포트
  type: ClusterIP

---
# 3. Route: 브라우저 접속을 위한 단일 통합 도메인 URL 설정 (OpenShift 전용)
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: powerclient-allinone-route
spec:
  # 고객사가 가이드해준 대시보드(웹) 단일 도메인 URL 입력
  host: pb-all.apps.cl-intsvc-test.ocp.kftc.net
  to:
    kind: Service
    name: powerclient-allinone-service
  port:
    targetPort: 8080