배경 — 왜 이 문제를 짚었나

AX(AI 전환) 관련 강화 작업(human-in-the-loop 승인 루프, Prometheus 계측, 멀티스텝 플래닝 에이전트)을 끝내고 나서, "이 프로젝트를 정말로 어디에 쓸 수 있는가"라는 질문이 나왔다. 답을 찾다 보니 더 근본적인 질문에 부딪혔다 — 이 포트폴리오를 "실제로 쓸모 있는 시스템"으로 팔 것인가, "실제 엔지니어링 역량을 증명하는 수단"으로 팔 것인가. 이 둘은 겹치는 것 같지만 실제로는 서로 다른 약점과 강점을 가진 별개의 전략이라, 어느 쪽으로 미는지에 따라 이력서 문구, 자소서, 면접 답변 방향이 전부 달라진다.

결론

기술 역량 프레이밍이 맞다. "실용성"을 앞세우면 이 프로젝트의 구조적 약점을 스스로 정면에 드러내게 된다.

왜 "실용성" 프레이밍이 취약한가

이 시스템이 다루는 대상은 전부 시뮬레이션/가짜 데이터다.

요소 실체
드론/항공기 표적 DroneSimulator가 생성하는 난수 좌표 (일부는 adsb.fi 실제 피드지만, 이 역시 "위협"으로 재해석한 것일 뿐 실제 위협 탐지 자산이 아님)
위협 패턴 10종 ThreatKnowledgeInitializer가 앱 시작 시 하드코딩 시딩
요격 자산 가용성 check_intercept_asset_availability — 정적 시드 + READY/COOLDOWN 랜덤, 실제 자산 관리 시스템과 무관
위협 인텔 문서 sample-threat-report.txt 등 직접 작성한 예시 문서

"이게 실제로 어디에 쓰이나요?"라는 질문에는 방어할 근거가 없다. 그리고 실용성을 스스로 앞세우는 카피(예: "실전 배치 가능한", "국방 현장에 적용되는")는 오히려 이 질문을 상대방에게 먼저 유도하는 꼴이 된다 — 자기 발등을 찍는 프레이밍.

왜 "기술 역량" 프레이밍이 강한가 — 근거 목록

도메인이 시뮬레이션이어도, 그 위에서 실제로 벌어진 엔지니어링은 전부 진짜다.

1. 실측 기반으로 스코프를 의도적으로 줄인 판단

사례 실측 근거 판단
온프레미스 LLM 보류 Mac mini M2, 통합메모리 8GB인데 k3s VM 3개가 이미 6GB 점유 상시 운영 대신 데모용 임시 기동으로 축소
Prometheus/Grafana 풀스택 미배포 kubectl top 기준 worker 노드 메모리 70%대, load average가 vCPU 수 초과 앱 계측(/actuator/prometheus, /metrics)까지만, 스크레이핑 서버는 보류
RAGAS CI 게이트 수동 트리거 Gemini 무료 tier 일일 쿼터를 이미 여러 번 실측으로 소진해본 이력 on: push 자동 대신 workflow_dispatch
멀티스텝 에이전트 스텝 상한 위와 동일한 쿼터 제약 MAX_TOOL_STEPS=3으로 요청당 최악의 경우 상한

2. 실제로 터진 프로덕션 이슈를 발견·수정

이슈 발견 경위 조치
gemini-api-key Secret이 실제 키가 아니라 문자 그대로 "PLACEHOLDER"로 방치 새 기능 검증 중 /chat 호출이 조용히 끊기는 걸 보고 파드 로그 확인 실제 키로 patch + 두 서비스 재시작, 외부 호출로 회귀 검증
tools.py ↔ doc_store.py ↔ gemini_client.py 순환 임포트 새 도구 추가 후 로컬 import 테스트 중 발견 지연 임포트(lazy import)로 해결
ArgoCD Image Updater가 git write-back에는 성공했지만 Application이 즉시 반영 안 됨 배포 후 digest 폴링이 5분간 멈춰있는 걸 관찰 argocd.argoproj.io/refresh=hard 어노테이션으로 강제 동기화, 원인(파일이 deployment.yaml이 아니라 .argocd-source-*.yaml인 것)까지 규명
/ai/metrics가 trailing slash 없이 접근 시 http://로 다운그레이드되는 307 리다이렉트 외부 curl 검증 중 발견 app.mount() 대신 일반 라우트로 재작성

3. GitOps 파이프라인이 실제로 끝까지 돈다는 걸 매번 실측 검증

기능 추가할 때마다 "커밋 → 푸시 → GitHub Actions 빌드 → Docker Hub → ArgoCD Image Updater 감지 → git write-back → ArgoCD sync → 롤링 업데이트 → 외부 URL로 실동작 확인"까지 전 구간을 실제로 지켜보고 검증했다 (사람 개입 없이 동작한다고 "주장"만 한 게 아니라 매번 실측).

적용 가이드

원칙: "무엇을 할 수 있다"가 아니라 "무엇을 실측·설계·발견·수정했다"

피해야 할 표현 (실용성 프레이밍) 대신 쓸 표현 (기술 역량 프레이밍)
"실전 국방 C4I 시스템에 적용 가능한 위협 탐지 시스템" "실측 기반으로 하드웨어/비용 제약을 판단해 기능 스코프를 조정한 AI 파이프라인"
"요격 자산을 실시간으로 관리하는 시스템" "모델이 여러 도구를 스스로 체이닝하는 멀티스텝 에이전트 설계 (쿼터 상한으로 비용 통제)"
"국방 현장에서 바로 쓸 수 있는 대시보드" "온프레미스 K3s 클러스터에 GitOps로 자동 배포되는 실시간 대시보드, 발견한 프로덕션 이슈 N건 직접 수정"

이력서/자소서 문구 방향