AX-Portfolio-Positioning-Strategy.md에서 정한 원칙("실용성"이 아니라 "실측→판단→조치" 기술 역량)을 실제 문구로 옮긴 초안. 그대로 복사해 쓰기보다, 본인 어투·지원 직무에 맞게 다듬는 걸 전제로 한다.

이력서 — 프로젝트 섹션

C4I 실시간 전술 지휘통제 시스템 — 개인 프로젝트, 2026.03 ~ 진행중

온프레미스 K3s 클러스터 위에 폴리글랏 마이크로서비스(Java/Python/TypeScript)로 구성한 실시간 표적 추적 + AI 위협 분석 시스템. 국방 시나리오는 시뮬레이션이며, 그 위에서 분산 인프라 설계·AI 파이프라인 구축·GitOps 자동화를 실제로 운영하며 부딪힌 제약과 판단 과정에 집중.

• 개인 소유 하드웨어(MacBook 2대) + VM 3대로 K3s 클러스터(Master 1, Worker 2)를 직접 구성. GitHub Actions → Docker Hub → ArgoCD Image Updater → GitOps write-back → 롤링 업데이트까지 사람 개입 없는 CD 파이프라인을 매 기능 배포마다 실측 검증
• Kafka 이벤트 스트림을 Java(pgvector RAG)·Python(Qdrant RAG) 두 서비스가 독립 consumer group으로 동시 구독하는 폴리글랏 아키텍처 설계, LangGraph로 질의 라우팅(문서 검색/이력 검색) 구현
• LLM function-calling 기반 멀티스텝 플래닝 에이전트 구현 — 모델이 최대 3개 도구(위협등급평가·대응절차조회·자산가용성확인)를 스스로 판단해 체이닝, API 쿼터 제약을 고려해 스텝 상한 설계
• AI 판단이 SITREP 생성에서 끝나지 않고 사람의 승인/반려로 이어지는 human-in-the-loop 워크플로 설계 (WebSocket 실시간 브로드캐스트, 결정 감사 로그)
• 클러스터 리소스를 실측(kubectl top)해 Prometheus/Grafana 풀스택 대신 앱 계측만 선택하는 등, 하드웨어·비용 제약을 먼저 측정하고 그에 맞춰 기능 스코프를 조정
• 운영 중 발견한 이슈(방치된 placeholder API 키 Secret, 순환 임포트, ArgoCD 상태 동기화 지연, SSE 리다이렉트 버그 등) 직접 진단·수정하고 외부 엔드포인트로 회귀 검증

기술스택: Java 21 · Spring Boot · Spring AI · Python · FastAPI · LangGraph · TypeScript · Next.js · Kafka · PostgreSQL/pgvector · Qdrant · K3s · ArgoCD · Docker · Google Gemini API · Prometheus

이력서 공간이 좁으면 위 6개 중 1·3·5번(자동화 파이프라인 실측, 에이전트 설계, 제약 기반 판단)을 우선 남기는 걸 권한다 — 가장 "이 사람이 직접 판단했다"는 신호가 강한 항목들.

자소서 — 프로젝트 소개 / 기술적 도전 (샘플 답변)

Q. 가장 기술적으로 도전적이었던 프로젝트 경험을 소개해주세요.

개인 프로젝트로 국방 C4I(지휘통제통신정보) 시나리오를 빌려 실시간 표적 추적·AI 위협 분석 시스템을 만들었습니다. 국방 도메인 데이터는 시뮬레이션이지만, 그 위에 온프레미스 K3s 클러스터를 직접 구성하고 GitOps 파이프라인·AI 파이프라인을 실제로 운영하며 부딪힌 문제는 전부 실제였습니다.

가장 기억에 남는 판단은 AI 관측성(observability)을 추가할 때였습니다. 처음엔 Prometheus와 Grafana를 클러스터에 새로 배포해 지표를 시각화하려 했습니다. 하지만 kubectl top으로 실측해보니 워커 노드가 이미 메모리 70%대, load average가 vCPU 수를 초과한 상태였습니다. 새 상태 유지형 워크로드를 얹으면 기존 서비스의 안정성을 해칠 수 있다고 판단해, Prometheus 서버 배포는 보류하고 애플리케이션 쪽에만 계측(Micrometer, prometheus-client)을 추가해 /actuator/prometheus·/metrics로 지표를 노출하는 선에서 멈췄습니다. "이상적인 구성"보다 "지금 실측된 제약 안에서 지속 가능한 구성"을 선택한 경험이었고, 이후 LLM API 쿼터 제약이 있던 CI 평가 파이프라인(RAGAS)에도 같은 원칙을 적용해 자동 트리거 대신 수동 트리거로 설계했습니다.

이 경험을 통해, 기술을 "할 수 있다"는 이유만으로 도입하기보다 실측된 제약 안에서 판단하는 습관을 갖게 되었습니다.

자소서 — 문제 해결/장애 대응 경험 (샘플 답변)

Q. 예상치 못한 문제를 발견하고 해결한 경험을 소개해주세요.

운영 중인 개인 프로젝트(K3s 클러스터에 온프레미스로 배포한 AI 기반 위협 분석 시스템)를 점검하던 중, 대시보드의 AI 기능이 정상 동작하는 것처럼 보였지만 실제로는 전부 규칙 기반 폴백으로만 응답하고 있다는 걸 발견했습니다. 원인을 추적해보니, 클러스터의 Kubernetes Secret에 들어있어야 할 실제 API 키가 문자 그대로 "PLACEHOLDER"라는 초기값으로 방치되어 있었습니다.