📅 일일 개발 및 학습 요약
1. 작업 분포
| 카테고리 | 비중 | |
|---|
| IaC/인프라 구축 (Terraform/AWS) | 40% | ████░░░░░░ |
| 기술 문서 및 학습 자료 작성 | 35% | ███░░░░░░░ |
| 아키텍처 이론 및 기술 상담 | 25% | ██░░░░░░░░ |
2. 집중 영역 / 시간 소모 포인트
🟢 생산적 작업
- 엔터프라이즈 IaC 프로젝트 (
operation-strix) 기반 구축
- Terraform을 활용하여 Backend(S3/DynamoDB) 구성, VPC 네트워크 설계, EKS 클러스터 생성 과정을 코드로 정의함.
- 단순 리소스 생성을 넘어, 비용 최적화(Single NAT, Spot Instance)과 보안(IRSA, Private Subnet)을 고려한 아키텍처를 적용함.
- GitOps 파이프라인 설계 및 구축
- ArgoCD를 설치하고, GitHub 레포지토리(
epicodix/operation-strix)와 연동하여 ‘App of Apps’ 패턴으로 클러스터 애드온을 관리할 수 있는 기반을 마련함.
- 학습 중심의 기술 문서화
- 인프라 구축 단계별로
docs/ 폴더 하위에 ‘Why(왜 이런 선택을 했는가)‘에 초점을 맞춘 상세한 아키텍처 문서를 작성하여 포트폴리오 자료로 활용 가능하게 함.
🔴 삽질/시간 소모 포인트
- SAA-C03 학습 노트 파일 복구
- 오전 세션의 백그라운드 Python 스크립트가 파일을 덮어쓰는 바람에 6.3장과 7장 내용이 유실됨.
- 유실된 내용을 복구하고, KDS vs KDF 테이블 및 비용 관리/DR 전략 테이블 등을 다시 적용하여 문서를 정상화하는 데 시간을 소요함.
3. 타임라인
| 시간 | 내용 |
|---|
| 10:09 | 🦦 문서 복구 작업: 백그라운드 스크립트 실행 완료 확인 및 오류로 인한 유실 내용(6.3, 7장) 복구 작업 진행. |
| 13:37 | 🐹 포트폴리오 기획 상담: AWS 크레딧 활용 및 인프라 직무 취업 전략에 대한 조언 요청. 1번(EKS/GitOps), 2번(Serverless) 프로젝트 제안 및 실무자 상향 평준화 전략 논의. |
| 15:48 | 🐹 프로젝트 스캐폴딩: operation-strix 프로젝트 시작. infrastructure/bootstrap, modules/vpc, environments/dev 등 엔터프라이즈 표준 Terraform 디렉토리 구조 생성. |
| 16:13 | 🐹 아키텍처 문서화: docs/ARCHITECTURE.md 생성. 인프라 설계의 ‘Why’를 정리하여 포트폴리오의 전문성 강화. |
| 16:49 | 🐹 Bootstrap 배포: Terraform State 관리를 위한 S3 버킷과 DynamoDB Lock 테이블 생성 및 적용 완료. 01_Core_Terraform_Bootstrap.md 학습 자료 작성. |
| 17:04 | 🐹 VPC 네트워크 구축: Public/Private 서브넷 분리 및 NAT Gateway(비용 절감용 1개) 구성 적용. ALB(Inbound)와 NAT(Outbound)의 차이 학습 및 02_Arch_VPC_and_Tradeoffs.md 작성. |
| 17:18 | 🐹 EKS 이론 심화: Karpenter와 Spot 인스턴스 활용 전략, Over-provisioning(Pause Pod) 패턴에 대한 심도 있는 토의. 03_Core_EKS_Karpenter_Spot.md 작성. |
| 17:29 | 🐹 EKS 클러스터 생성: EKS 모듈 작성 및 IRSA(OIDC) 보안 설정 적용. 약 15분간의 클러스터 프로비저닝 진행. |
| 17:39 | 🐹 GitOps 설계: ArgoCD ‘App of Apps’ 패턴과 K8s 필수 애드온(ALB Controller, Metrics Server, Logging)에 대한 학습. 04_Arch_GitOps_and_ArgoCD.md 작성. |
| 18:08 | 🐹 ArgoCD 설치: Helm을 이용한 ArgoCD 설치 및 GitHub 인증 방식(SSH/PAT) 논의. |
| 18:15 | 🐹 GitHub 연동 및 App of Apps 구성: epicodix/operation-strix 레포지토리 연동. Root App 배포를 통해 Metrics Server 자동 배포 파이프라인 구축. |
| 18:33 | 🐹 Karpenter 설치 준비: Karpenter 권한 부여를 위한 IRSA 개념 재확인. Terraform Plan을 통해 Karpenter 모듈(IAM Role, SQS, EventBridge) 배포 준비 완료. |
4. 해결한 문제와 인사이트
💡 핵심 문제 해결
- 인프라 상태 관리의 충돌 방지
- 문제: 로컬
.tfstate 파일 사용 시 팀원 간 동시 작업 시 충돌 및 상태 오염 위험.
- 해결: S3 버킷에 State 파일을 저장하고 DynamoDB 테이블을 이용해 Locking 기능을 적용하여, 동시
apply 시도를 원천 차단하는 안전한 협업 환경을 구축함.
- 비용 절감과 가용성의 균형 (VPC)
- 문제: Multi-AZ 환경에서 각 AZ마다 NAT Gateway를 생성하면 비용이 과도하게 발생함.
- 해결: Dev 환경은
single_nat_gateway = true로 설정하여 비용을 절감하고, 장애 시 일시적 통신 두절을 감수하는 타협점을 명확히 하여 설계함.
- Spot 인스턴스의 단점 보완 (Karpenter)
- 문제: Spot 인스턴스는 강제 회수(Interruption) 위험이 있어 서비스 중단 가능성이 존재함.
- 해결: Karpenter가 AWS EventBridge의 2분 전 경고를 수신하여 Pod를 우아하게 이동시키는(Drain) 전략과, 다양한 인스턴스 타입을 유연하게 선택하여 가용성을 확보하는 전략을 이해하고 적용 계획을 수립함.
🚩 주요 인사이트
- 운영의 센스: 단순히 리소스를 생성하는 것이 아니라, “비용이 왜 발생하는지”, “장애 발생 시 어떻게 대처할지”에 대한 고민을 문서화하는 것이 면접관에게 어필할 핵심 역량임.
- IRSA의 중요성: EC2 노드 전체에 IAM 권한을 부여하는 것은 보안상 매우 위험하며, 파드(Pod) 단위로 최소 권한을 부여하는 IRSA(IAM Roles for Service Accounts)가 현업 표준임.
- GitOps의 힘: ArgoCD의 ‘App of Apps’ 패턴을 사용하면 수십 개의 애드온 설치 과정을 코드로 정의하여, 클러스터 재생성 시 5분 만에 동일한 환경을 복구할 수 있음.
Supported by ai-log-sync & GLM-4.7