| 항목 | 기록 |
|---|---|
| 문제 | 장애 모니터링과 Grafana 연동을 위한 Alloy 설치를 준비하면서, 서버와 DNS가 여러 환경·사업자에 흩어져 있고 과거 외주 자산의 소유권·문서·변경 이력이 불명확한 상태를 확인했다. 관리되지 않은 접근 계정·키·권한도 운영 위험으로 남아 있었고, 전임자 퇴사 이후 전담 인프라 담당자가 없는 상황이었다. |
| 기존 방식과 비용 | 콘솔과 개별 서버 변경은 검토 기준·변경 이력·재현 경로를 분산시킨다. 신규 인스턴스 요청이 늘어날수록 어떤 자산을 누가 어떤 기준으로 바꾸는지 확인하는 비용도 커진다. |
| 제안/판단 | 전사 AI 프로젝트와 신규 인스턴스 요청 증가를 앞두고, MCP 직접 호출이나 비용 제한만으로는 인프라 관리 체계를 대체할 수 없다고 판단했다. Terraform plan → 사람 확인 → apply를 휴먼 게이트로 두고, Git 변경 이력과 repo-first 규칙으로 변경 경로를 표준화했다. |
| 기술 선택 | Terraform으로 기존 Ncloud 자산을 import해 선언과 실제 자산의 연결을 확보하고, 반복되는 일부 핵심 서버 운영 작업은 Ansible로 표준화했다. AI는 탐색과 보조 수단으로 두되, 변경 권한과 최종 판단은 사람 검토에 남겼다. |
| 구현 범위 | 당시 Ncloud 전체 자산 범위를 resource 94개·import 94개로 코드 관리에 편입했다. 네트워크, 서버, 보안 정책, 로드밸런서, 오토스케일링, 관리형 MySQL·Redis, 배포 구성을 선언했다. Ncloud·온프레미스의 일부 핵심 서비스에는 관측 에이전트와 모니터링 구성 등 자주 반복되는 작업만 Ansible로 자동화했다. |
| 내 기여 | 기존 자산 import와 선언 구조, 신규 리소스의 repo-first 규칙, plan 검토 게이트, 서버 자동화 playbook과 운영 문서의 설계·구현·정리를 수행했다. |
| 정량 결과 | resource 94개 · import 94개. 당시 확인한 전체 Ncloud 자산 범위의 코드 편입 수이며 현재 자산 수, 지속 커버리지, apply 성공률이나 운영 효과를 의미하지 않는다. |
| 연결 데이터 | Ncloud 자산 코드 관리 편입 (DATA-SCALE-IAC) |
| 공개 주의사항 | state, tfvars, inventory, 계정·호스트·IP·도메인·보안 정책 식별자, 접근 키와 내부 URL은 공개하지 않는다. 공개 자료에는 리소스 유형별 집계와 추상화한 변경 흐름만 사용한다. |
| 남은 검증 | Terraform 선언 수는 실제 자산 수·100% 커버리지·적용 성공률과 같지 않으므로, 향후 변경 이력과 plan·apply 증적을 기준으로 별도 검증한다. |
근거
지표는 포트폴리오 정본 data/metrics.yml(2026-08-31 기준)의 DATA-* 항목이다. 원본 응답·행 데이터는 저장하지 않는다.
- DATA-SCALE-IAC · 당시 Ncloud 자산 코드 관리 편입: resource 94개 · import 94개
공개 범위
이 글은 포트폴리오 정본의 공개 요약이다. 원본 업무 데이터와 회사·약국·서버·공급사 식별정보는 뺐다. state, tfvars, inventory, 계정·호스트·IP·도메인·보안 정책 식별자, 접근 키와 내부 URL은 공개하지 않는다. 공개 자료에는 리소스 유형별 집계와 추상화한 변경 흐름만 사용한다.