[에스넷시스템 부트캠프] TIL Day 67~71 - 프로젝트 5주차
Day 67 - CDN 에러 고치기 & Terraform 인프라 문서화
Route53과 CloudFront 연동 확인
기존에 사용하려던 도메인은 팀원이 내도메인한글 무료 서비스에서 발급받은 것이었다.
처음 계획대로라면 Route53에 Hosted Zone을 만들고 네임서버를 AWS로 변경해야 했는데, 문제는 내도메인한글에서는 네임서버 변경 기능을 제공하지 않는다는 점이었다.
다행히 빠르게 원인을 파악했고, 오래 고민하지 않고 바로 가비아에서 550원을 결제해 도메인을 구입했다. 이후 Route53에 도메인을 등록하고 네임서버도 AWS로 변경 완료. 중간중간 테스트를 하면서 기다렸는데, 약 4~5시간 정도 뒤에 정상적으로 도메인 접속이 가능해졌다.
아직 백엔드 서버 배포 전이지만, 프론트엔드 페이지가 도메인으로 접속되는 걸 확인했을 때의 뿌듯함은 상당했다.
Terraform 인프라 문서화 (Confluence)
Terraform으로 구축한 인프라를 팀원들이 한눈에 볼 수 있도록 Confluence에 문서화했다.
- 코드 레벨에서 정의된 리소스뿐만 아니라, 실제 AWS 상에서 생성된 리소스 이름까지 정리
- 단순 코드(output.tf 등)로 확인할 수 있는 내용도 있지만, 문서로 풀어내니 프로젝트 보고서 느낌이 나서 팀 공유와 향후 발표 자료로 활용하기 적합하다고 생각
다만, 이미 어느 정도 인프라 구성을 마친 상태에서 문서화를 하다 보니 시간이 꽤 걸렸다.
“미리 조금씩 해둘걸…” 하는 후회도 있었지만, 그만큼 이번 정리가 앞으로 팀 협업과 프로젝트 관리에서 큰 도움이 될 거라 믿는다.
Day 68 - 백엔드 코드 인프라 환경 반영
오늘은 기존에 만들어둔 백엔드 애플리케이션을 인프라 환경에 맞게 수정하는 작업을 진행했다.
- 환경 변수 세팅: 인프라에서 필요로 하는 환경 변수들을 코드에 반영
- 불필요한 디버그 출력 정리: 개발 단계에서만 쓰던 디버그용 로그들이 많아 가독성을 해치고 있었는데, 이참에 깔끔하게 정리
수정이 끝난 뒤에는 로컬 환경에서 충분히 테스트를 거쳤다. 기능적으로 큰 문제 없이 동작하는 것을 확인한 후, Docker 이미지를 빌드해 DockerHub에 업로드했다.
이제 본격적으로 EKS 환경에 이 이미지를 배포하면 된다. 드디어 인프라와 애플리케이션이 맞닿는 지점에 도착한 것 같아 긴장되면서도 기대된다.
Day 69 - 멘토링 & 모의면접
현업자 멘토링
EKS 노드 구성 전략
Q. Multi-AZ 2개 노드 vs 단일 AZ + 오토스케일링?
- 비용 중심: 단일 AZ + 오토스케일링 방식
- 실시간성 중요: Multi-AZ 구성으로 즉시 failover
=> 상황에 맞게 결정
오토스케일링 설정
- 지표 설정: 정답은 없음, 프로젝트별 맞춤 설정 필요
- 노드 추가 시간: 일반적으로 5-10분 소요
- 개선 방안:
- 여유 노드 미리 배치 (비용 vs 성능 트레이드오프)
- EKS 관련 기능 활용
- 기본 지표: EC2의 CPU, 메모리 사용량 기준
Terraform 운영 팁
리소스 삭제
- 주석 처리 후 apply 실행 권장
State 파일 관리
- GitHub에 업로드 금지
- 공동 작업 시 원격 저장소 활용 필수
- Terraform용 .gitignore 인터넷 참고 권장
공동 작업
- 원격 저장소 사용 시 자동 동기화
- 별도 pull 과정 불필요
키 페어 관리
- EC2 접근: 필요 시 별도 생성하여 관리
- 고려사항: Terraform 코드 vs 수동 관리 범위 결정 필요
- 보안: NAT Instance SSH 접근용 최소 관리자 키 페어 필요
프로젝트 관리 도구
Jira vs Notion
- 심플한 환경: Notion 선호 업체 많음
- 인프라 관점: 애자일 스프린트가 꼭 필요한지 재검토
- 활용 팁: 각 프로젝트 환경에 맞는 맞춤 설정 권장
모의면접
멘토링 이후에는 모의면접 준비와 진행을 했다.
- 준비: 자기소개 여러 번 리허설, 예상 질문 정리
- 진행: 약 10~15분, 기술 면접보다는 인성 면접에 가까운 느낌
- 결과: 자기소개에서 긴장해 살짝 꼬였지만, 이후 질문에는 솔직하게 잘 답변했다고 생각한다.
면접 피드백
- 개선할 점: 프로젝트별로 내 역할과 수행 과정을 Notion/블로그에 정리해둘 것
- 자격증: AWS SAA 취득 강력 추천
- 이미 강의를 듣고 있었지만 진도가 느림
- 하반기 채용 시즌 대비, 강의보다는 기출 풀이 중심으로 학습 전략 전환
면접이 끝난 뒤에는 자격증 로드맵과 채용 공고를 다시 살펴보며 앞으로의 계획을 조금 더 디테일하게 수정했다.
Day 70 - Kubernetes 리소스 배포
오늘은 Kubernetes 클러스터에 애플리케이션을 실제로 배포했다.
데이터 수집 서비스
- Deployment (replicas=1) 로 배포
- 추가로 CronJob을 설정해 10분마다 뉴스 수집 작업이 실행되도록 구성
- 👉 Replicas를 1로 제한한 이유는, 여러 파드가 동시에 실행될 경우 데이터가 중복 수집되는 문제를 방지하기 위함
데이터 조회 서비스
- Deployment (replicas=3) 로 배포
- 조회 요청은 동시에 여러 사용자에게서 들어올 수 있으므로, 가용성과 부하 분산을 위해 3개의 파드로 구성
Day 71 - 백엔드 코드 또또수정
불필요한 API 삭제
바이브 코딩으로 진행하다 보니 애플리케이션에 불필요한 API가 남아있었다. 코드의 복잡성을 줄이고 유지보수성을 높이기 위해 불필요한 API들을 과감히 삭제했다.
데이터 중복 수집 방지 로직 추가
데이터 수집 서비스는 Pod 1개만 띄웠는데 생각해보니 API 수행만으로도 데이터 중복이 생길 수 있었다. 최대한 애플리케이션 코드를 수정하고 싶지 않았지만 어쩔 수 없이 애플리케이션 레벨에서 중복 수집 방지를 위한 로직을 추가해야했다.
DynamoDB에 저장되어 있는 뉴스 아이템 중에서 가장 최신의 pubDate 값보다 수집 API가 수행됐을 때 수집된 뉴스들의 pubDate가 더 최신일 때만 수집하도록 로직을 변경했다.
권한 문제
백엔드 로직을 수정한 뒤 Docker 이미지로 빌드해서 다시 Kubernetes에 배포했다. 그런데 API 테스트 과정에서 DynamoDB와 S3 권한 에러가 발생했다.
원인은 비교적 단순했다. Terraform 코드에서 DynamoDB 정책에 DescribeTable 권한이 빠져 있었고, S3 권한도 일부 부족했던 것이다. 로컬 환경에서는 내 AWS CLI 계정 키를 사용해 권한을 가져오고 있었기 때문에 문제가 드러나지 않았던 것.
이왕 정책을 수정하는 김에 서비스별 Role을 새로 만들기로 했다. 멘토링 때 들은 팁대로 기존 Role은 주석 처리 후 삭제했고,
- 데이터 수집용 Role
- 데이터 조회용 Role
을 각각 따로 생성한 뒤, 서비스 성격에 맞는 권한만 연결해주었다.
결과적으로 권한 문제를 해결했을 뿐 아니라, 최소 권한 원칙(Principle of Least Privilege) 을 지키는 구조로 개선할 수 있었다. 단순한 에러 해결 작업이 아니라, 보안 수준을 한 단계 끌어올린 의미 있는 수정이었다.
✍️ 주간 회고
이번 주는 공부에 시간을 꽤 많이 썼다. 단순히 AI에게 “해줘”라고 맡기는 것보다는, 내가 정확한 오더를 내릴 수 있도록 블로그에 정리해둔 글이나 책, 인터넷 자료들을 참고하면서 설계를 진행했다.
AI가 생각보다 비효율적인 코드를 짜거나, 내가 요청한 내용을 빠뜨리는 경우가 종종 있었는데, 그럴 때마다 꼼꼼히 점검하는 게 얼마나 중요한지 다시 느꼈다. 솔직히 귀찮을 때도 있었지만, 내가 더 단단해지고 있다는 생각이 들어 뿌듯했다.
다음 주에는 Pod들이 잘 올라가고 API들이 정상적으로 동작하는지 확인하는 걸 먼저 하고, 이어서 프론트 API 경로 수정, HA 테스트, 모니터링 환경 구축까지 진행할 계획이다. 욕심 같아서는 CI/CD도 이번 주 내에 구축해보고 싶지만, 현실적으로는 시간이 빠듯할 수도 있다. 그래도 최대한 달려봐야겠다.