황민영

IaC 이관

콘솔 자원 14개 Terraform 이관

계정 자원이 모두 콘솔로 만들어져 있어, 새 서버만 코드로 두면 관리가 둘로 나뉩니다.그래서 계정 전체 이관을 제안했고, plan으로 확인해도 위험이 남는 네트워크는 범위에서 뺐습니다.공통 모듈로 옮기면 수정 한 번이 모든 자원에 퍼질 수 있어, 그 위험은 반영 순서로 줄였습니다.

미리 정한 단계로 import, plan, apply를 차례로 반영했습니다.

1. 접속용 서버지워져도 되는 자원
2. 개발 클러스터
3. 보안 장비 서버
4. 운영 클러스터
5. 방화벽마지막에 반영

장애 영향 작음큼

아래로 갈수록 장애 영향이 큽니다.

장애 대응

노드 44개 메모리 장애 복구

운영 환경에서, 개발팀과 3단계로 풀기로 한 메모리 문제의 첫 배포에 Container 설정만 나가고 requests 조정이 빠졌습니다.사용자가 적은 시간대라 서비스 영향은 제한적이었고, 팀장님과 함께 대응해 약 7시간 만에 복구했습니다.

1. 17시~17시 반메모리 문제 시작requests 조정 누락
2. 18시~20·21시경노드 롤링, 약 50노드로 증설안정됐다 다시 반복
3. 그 뒤파드가 뜨지 않기 시작함Docker Hub rate limitECR 이미지로 전환
4. 자정경requests 수정, 안정화

이후. 팀장님 의견에 따라 애플리케이션 쪽에 흩어져 있던 메모리 설정을 Helm 중앙 관리로 옮기고, 배포 순서는 개발팀과 다시 정했습니다.

그 밖의 사례

• 롯데카드RDS 보안 패치, Blue/Green으로

  롯데카드, 변경 관리

  운영 PostgreSQL에서 CVE가 나와 마이너 버전 업데이트가 필요했습니다.In-place, 하이브리드(콘솔 Blue/Green 뒤 Terraform 동기화), Terraform Blue/Green 세 방식을 시험했습니다.개발은 하이브리드로, 운영은 Terraform Blue/Green으로 마쳤습니다.

  • In-place
  • 하이브리드개발
  • Terraform Blue/Green✓ 운영

  Terraform blue_green_update, RDS PostgreSQL

• 롯데카드EKS 2단계 업그레이드

  롯데카드, 업그레이드

  클러스터 4개가 컨트롤 플레인 1.33, 노드그룹 1.31로 벌어져 있었고, 고객사는 둘 다 1.35를 원했습니다.1.34를 거쳐 1.35로 가는 2단계 로드맵을 짜고, 테스트 계정에서 먼저 검증했습니다.클러스터 4개와 노드그룹 5개를 1.35까지 올렸습니다.

  EKS, Managed Node Group, Terraform

• 롯데카드tfstate 평문 비밀번호 차단

  롯데카드, 비밀 관리

  RDS 마스터 비밀번호가 tfvars에 있었고, Secrets Manager 값을 참조해도 tfstate에는 평문으로 남았습니다.Terraform을 1.15로 올린 뒤 ephemeral 변수와 password_wo(1.11+)로 비밀번호를 tfstate에서 뺐고, Backend S3 접근은 보안팀과 협의해 제한했습니다.백엔드 앱의 DB 인증 정보는 Secrets Manager 이관 가이드를 써서 넘겼습니다.

  Terraform 1.15, ephemeral, password_wo, Secrets Manager

• 롯데카드Instance Scheduler 도입

  롯데카드, 비용 자동화

  개발 환경 비용을 줄이려고 업무 시간 밖 자원 자동 중지 방안을 세웠습니다.세 방식을 비교해 제안했고, Lambda 코드 부담이 적고 여러 계정을 한곳에서 관리하는 Instance Scheduler로 합의했습니다.Hub-Spoke로 구성해 크로스 계정 Role은 CloudFormation, DynamoDB 설정은 Custom Resource, 대상 태그는 Terraform으로 넣었습니다.

  • EventBridge + Lambda
  • Systems Manager
  • Instance Scheduler✓ 선택

  Instance Scheduler, CloudFormation, DynamoDB, Terraform

• 핀다Frontend 팀 테스트 환경을 일주일 만에

  핀다, 배포 환경

  Frontend 팀이 기존과 같은 구성의 독립 테스트 환경을 빨리 필요로 했습니다.기존 클러스터에 독립 Argo CD 인스턴스를 Terraform으로 올리고, Istio 라우팅과 GitHub SSO를 붙였습니다.일주일 만에 제공했고, 환경마다 달랐던 Argo CD 배포 방식도 리팩터링으로 통일했습니다.

  Terraform, Helm, Istio, Argo CD

• 핀다보안팀 직통 Loki 알람

  핀다, 보안 알람

  해외 비정상 트래픽이 잦았는데, Istio 4XX 알람까지 약 30분이 걸린 뒤 분석과 차단 요청을 거쳤습니다.Loki로 User-Agent, IP별 트래픽을 집계해, 임계치를 넘으면 보안팀에 바로 알람이 가게 했습니다.그 뒤로는 DevOps가 알람을 분석하기 전에 보안팀이 차단을 끝냈습니다.

  Loki, Grafana

• 핀다업무 시간 외 On-Call 대응

  핀다, On-Call

  장애가 Slack에 올라오면 먼저 본 사람이 대응하는 구조였고, 출근이 필요하면 업무 시간 외에도 출근했습니다.홈페이지 대출한도 계산기가 동작하지 않는다는 연락에, 원격 확인이 잘 되지 않아 팀장님과 함께 재출근했습니다.

  1. URL 확보개발팀에 기능 URL 요청
  2. Loki 로그그날 오후부터 정상 로그가 끊김
  3. 배포 기록 대조같은 시각 배포 확인
  4. 개발팀 전달원인은 코드 문제

  알람 점검24/7 관제팀 전화 연동을 붙이며 알람을 다시 보다가, 임계치가 지표가 도달할 수 없는 값이라 영원히 울리지 않던 Grafana 알람을 찾아 고쳤습니다.

  Slack, Loki, Grafana

• 핀다Secrets 워크플로에 MongoDB 지원

  핀다, 비밀 관리

  개발자가 DB 정보를 PR로 올리면 제가 검토하고(필요하면 직접 고쳐) /create-secret 코멘트로 Actions를 실행한 뒤, 브랜치가 실제 상태와 같도록 merge하는 워크플로가 있었습니다. 여기에 MongoDB를 더했습니다.base 브랜치로 환경을, 엔진으로 포트를 정해 시크릿을 만들고 태그를 붙인 뒤 30일 주기 교체를 겁니다.교체 Lambda는 DocumentDB용(Python)을 MongoDB의 updateUser 방식에 맞게 고쳐, 4단계 단일 사용자 교체로 돌게 했습니다.

  GitHub Actions, AWS Secrets Manager, Lambda(Python, pymongo)

• 핀다GHES 복제와 백업 실패

  핀다, 장애 해결

  업그레이드 뒤 복제가 끊겨 백업도 멈췄고, 지원팀과 수개월 복제본 쪽을 봤지만 풀리지 않았습니다.인프라 팀의 의견을 받아 SSH 디버그 로그를 보니 authorized_keys가 소유권, 권한 문제로 무시되고 있었습니다.관리 콘솔에서 SSH 키를 등록할 때 .ssh 폴더와 키 파일 권한이 바뀌는 것이 원인이었고, 700/600으로 되돌리자 복제와 백업이 돌아왔습니다.

  GitHub Enterprise Server, EC2, SSH

텔레그램 요약 봇

2026.07 – 현재

채널 19곳 중복 제거 봇

• 가벼운 검사 우선. 해시, 같은 링크, 유사도 순으로 거르고 애매할 때만 AI에 묻습니다.
• 실패 원인 확인. 실패율 상승을 로그로 503·429로 짚고, 대체 모델은 쓰지 않았습니다.
• AI 호출 줄이기. 절감안 1개만 적용해 50건 기준 80회를 50회로 줄였습니다.