[2025-05] 코드잇 중급 프로젝트 회고

 

 

코드잇 중급 프로젝트와 2025.03.31 ~ 2025.05.12까지 해온 것들의 회고록입니다.

 

 

🐻 중급 프로젝트 회고

5월 12일 한 달간 진행했던 중급 프로젝트를 마무리하고 그동안의 성과를 발표하며 본인이 만든 결과물을 뽐내는 시간을 가졌다.각 팀은 PPT를 예쁘게 만들어서 어떤 부분에 대해서 중요하게 생각했고 학습하고 적용해 왔는지 발표했다.

 

정말 신기하게 각 팀의 결과물, 팀원 각자마다 어떤 것을 중요하게 생각하는지가 모두 달랐고 (프로젝트가 정해져 있지만) 설명하는 방법 또한 미세하게 차이가 있었다.

 

총 10팀이 발표를 했고, 우리 조의 발표를 제외하면 9개의 조의 발표를 들었다. 한 팀씩 발표를 들으면서 느낀 점은 정말 잘하는 사람이 많구나 이였다. 대단하다고 생각하기도 하고 한편으로는 비교되는 내가 조금 작아 보여서 우울하기도 했다. 이에 왜 이런가에 대해서 생각을 조금 해보았다.

 

다른 팀들의 발표 콘텐츠가 뛰어나고 뛰어난 사람들이 많다. 그렇다고 내가 다른 사람들에 비해서 떨어진다고 생각하면 안 되고 그렇게 말한 것도 아니다. 각자 집중 분야에 따라 좋아하는 주제에 정말 많은 학습을 하였을 것이고 시간을 많이 투자했을 것이다. 나 또한 나에게 중요하고 좋아하는 분야에 시간을 많이 쏟았었고, 꾸준한 학습을 진행해 오면서 정리도 해나가고 있다.

 

다른 사람들이 중요하게 생각하는 부분과 대중적인 주제 또한 놓치지 않아야 된다. 내가 중요하게 생각하는 부분에서만 머물러 있는 게 아니라 다른 사람들과 소통하며 다양한 분야를 접해봐야겠다. 또한 학습을 할 때는 언제나 심도 깊게 학습하고 적용하며, 성과를 정리하는 시간을 빼먹지 않을 것이다. 

 

앞으로 다음 고급 프로젝트 시작 일정까지 총 6주 정도의 시간이 남아있다. 6주를 어떻게 쓰고 무엇을 공부하여 고급 프로젝트에 적용해 볼 것인지 생각 정리를 해본다.

 

다음 프로젝트에서 내가 해보고 싶은 작업은?

• 데이터 수만 개 적재 후 성능 개선을 해보기
  • Redis
  • Mongo DB
  • Elastic search
  • Rabbit MQ
  • Kafka
• JMeter, Locust, K6 등 도구를 이용해서 TPS 측정해 보고 성능 개선 (기본적인 용어 개념 정리)
• 동시성 처리

 

하고 싶은게 뚜렷하다 보니까 한 달간 굉장히 바쁘게 살아갈 것 같다고 예상된다. 학습하는 것도 중요하지만, 정리하는 것도 중요하다. 꾸준히 학습하고 정리하는 루틴을 통해서 사용 방법만 익히기보다는 전체적인 그림을 파악하고 사용한 이유와 성과를 잘 정리하자.

 

📚  프로젝트 깃허브 

https://github.com/jaewoo9797/sb01-deokhugam-team09

GitHub - jaewoo9797/sb01-deokhugam-team09: [코드잇 중급 프로젝트 저장소] - 덕후감

 

🐻 서버 관리 부담은 줄이고 개발 집중은 높이고: ECS/Fargate 도입 회고

기존 EC2 환경에서 벗어나 컨테이너 기반 배포를 경험하기 위해 AWS의 ECR(Elastic Container Registry)과 ECS (Elastic Container Service)를 활용하여 토이프로젝트를 배포했다. 컨테이너화된 애플리케이션의 이식성, 관리 용이성, 그리고 확장 가능성에 대한 기대감을 가지고 ECS를 선택했고, 특히 서버 관리에 대한 부담을 줄이고 개발에 집중하고자 Fargate 기반 배포를 시도했습니다. ECS 도입하며 EC2 와의 비교, 장단점, 그리고 실제 경험을 통해 느낀 점을 공유합니다.

 

컨테이너와 도커 관련 글은 이 포스트를 참고해 주세요

[운영 배포] CI/CD 도커 정리

 

1. ECR, ECS 서비스를 이용한 이유

최근 MSA 트렌드와 함께 컨테이너 오케스트레이션의 중요성이 더욱 커지고 있다고 생각합니다. AWS도 이에 ECS (Amazon Elastic Container Service)를 이용할 수 있도록 제공해주고 있다.

 

이번 토이 프로젝트는 규모가 작고, 초기에는 많은 트래픽이 발생하지 않을 것으로 예상되어 복잡한 EKS 대신 ECS를 선택했다. 특히 EC2 기반 배포 방식과는 달리, Fargate 기반 배포를 하였다. 

 

• Fargate 기반 : AWS가 서버를 관리하고 SSH 접속이 제한된다.
• EC2 기반 : 사용자가 서버를 관리한다. EC2에 SSH 접속하여 직접 관리할 수 있다.

 

정리하자면, 도커 컨테이너를 이용해서 애플리케이션 배포를 하기 위해서 AWS에서 제공하는 ECS를 선택했다. 내가 직접 관리하지 않고 AWS에서 관리하는 방식으로 배포를 경험해 보고, EC2 대신 Fargate를 사용하여 직접 서버를 관리하는 방법과 차이를 느꼈다. 이를 통해서 프로젝트를 진행함에 있어서 서버 관리에 대한 리소스를 줄어드는 것을 기대했고, 실제로 SSH로 접속하여 관리하는 시간 리소스를 개발과 학습 내용 정리에 시간을 더 쓸 수 있었다.

 

2. 기존 EC2와 비교

EC2를 이용하여 서버를 띄우고 서버 안에 접속하여 애플리케이션 서버를 구축하는 방식을 했던 것과 비교하면 굉장히 간결하고 자동화된 프로세스를 이용할 수 있었다. ECS 클러스터에 정의한 Task를 이용하여 정의한 설정에 따라서 Service를 통해 자동으로 관리한다. 이를 통해서 직접 SSH 접근이 필요 없고 정의된 Task Definition 대로 서버를 자동배포 할 수 있다. 

 

SSH 접속하여 우분투 명령어로 서버를 관리하는 러닝커브가 없다는 점이 처음에 서버를 배포하는 방법으로 선택하여 빠르게 배포할 수 있다는 장점이 있었다. 대신에 세세한 설정을 하려면 조금은 AWS에 대한 이해도가 필요하다는 점이 있었던 것 같다. 

• Task를 정의하는 방법
• IAM 정책을 생성해서 원하는 서비스와 연결하는 방법
• 자동 배포마다 변경되는 IP를 ALB 서비스를 이용하여 연결하는 방법

 

장점

• AWS의 서버 관리 자동화 
  • 서버 배포 방식을 AWS에서 관리해 준다. 롤링 업데이트, Blue-Green 배포 등
  • 이전에는 서버에 스크립트를 작성해서 다른 서비스에서 해당 스크립트를 콜 해서 자동배포했었던 것에 비해 리소스 감소
• 배포 안전성 향상
  • 배포 시 문제가 발생할 경우 서버를 교체하지 않고 기존 컨테이너 유지
• 서버 관리 리소스 절감
  • 서버 직접 관리하지 않아도 AWS 가 관리해 준다.
• AWS 서비스와의 용이한 연동
  • 다른 AWS 서비스와 연동 (S3, RDS, Secrete Manager, Cloud Watch 등) 

그리고 이번에 추가적으로 시크릿 키를 코드상에서 아예 노출시키지 않기 위해서 관련 설정을 하여 서비스의 유기적인 연동을 할 수 있었다.

 

단점

• ECS에 대한 기본 개념 학습 정리, 세팅 방법 러닝커브
• 직접 SSH 접근을 하지 못하는 점 (추가적인 세팅을 AWS에서 하기보다 직접 접속해서 관리하는 게 아직 편했다.)
• 비용 문제. Fargate는 사용한 만큼 돈을 지불하는 종량제 서비스였지만 프리티어가 제공하는 EC2 시간과는 다르게 실제로 사용한 만큼 돈이 나가서 지원받지 않으면 선택하기에 꺼리게 된다.

느낀 점

• 서버를 배포하고 추가로 prometheus, grafana를 함께 내장하게 만들어서 EC2 안에서 컨테이너를 띄우는 방식을 사용하려고 했으나 직접 SSH 접속이 제한되어 추가로 Task를 정의하거나 서비스를 만들어야 하는 부분이 발생하였다.
• 일정 산출 결과 해당 작업을 하기에는 불가능하다고 판단하여 로컬에서 모니터링 툴을 컨테이너로 띄워서 수동 메트릭 수집을 하게 되었다.
• 자동화된 서버 클러스터 배포를 통해서 배포에 시간을 많이 쓰지 않고 개발과 정리에 더 많은 시간을 들일 수 있었다.

 

전체적으로 서버 배포에 시간을 줄일 수 있다는 점이 좋았으나, 세세한 컨트롤을 위해서 설정할 경우에 시간 비용이 더 발생할 수 있다는 점. 그리고 비용적인 문제가 발생한다는 점이 다음에 또 해당 서비스를 이용하기에 꺼리게 된다. 프리티어에서 EC2는 일정 시간 무료로 사용할 수 있지만 Fargate는 진짜 내가 사용한 만큼 무료 시간 없이 바로 비용이 발생한다.

 

전반적으로 ECS와 Fargate는 서버 관리 부담을 줄여주는 강력한 도구이지만, 서비스의 특성과 비용 효율성을 충분히 고려하여 프로젝트에 적합한 방식을 선택하는 것이 중요하다고 생각합니다.

(Fargate가 EC2에 비해서 저렴한 이유 : OS를 포함하고 있는 EC2와 포함하지 않는 Fargate)

 

 

ECR, ECS 간단 정리는 이 포스트를 참고해 주세요.

 

🐻 Docker Image 최적화: 적용과 성과 분석

이번 프로젝트에서는 Docker를 이용해 애플리케이션을 컨테이너로 배포했습니다. 컨테이너화 자체에는 익숙했지만, 이미지 최적화가 실제 운영 환경에서 얼마나 중요한지는 체감하지 못하고 있었습니다.

그래서 이 기회에 Docker 이미지 최적화에 대해 학습하고, 프로젝트에 적용해 실제 성과까지 확인해보았습니다.

 

👉 관련 정리 포스트: Docker Image 최적화 (이론 정리 및 실습 비교)

 

문제 인식: 이미지 크기가 커지면서 생긴 문제들

CI/CD 파이프라인을 GitHub Actions로 구축하고 배포 자동화를 해둔 상태였습니다. 하지만 개발이 진행될수록 의존성, 정적 파일, 설정 파일 등 이미지에 포함되는 리소스가 늘어나면서 이미지 크기가 점차 커졌고, 그에 따라 다음과 같은 문제를 겪게 되었습니다:

• 빌드 시간 증가 (기반 이미지 포함)
• 이미지 레지스트리(ECR, Docker Hub) 업로드 시간 증가
• 배포 시간 증가 → 롤링 배포 시 딜레이
• 오토 스케일링 시 신규 노드에 이미지 pull 속도 저하
• Fargate 디스크 용량 낭비

 

특히 오토 스케일링 상황에서 이미지 크기가 클수록 신규 노드에 컨테이너가 배치되기까지의 시간이 지연될 수 있어, 실 서비스에서의 영향도 크다고 판단했습니다.

 

 

도커로 대규모 시스템을 구축하는 경우 마지막 오토 스케일링과 관련된 문제가 가장 크게 다가올 것이라고 생각했습니다. 서버 리소스가 부족해지면 오토 스케일링을 통해 새로운 노드가 투입되며, 이 새 노드에 얼마나 빨리 도커 이미지를 배치할 수 있는지가 중요하기 때문에 Docker Image의 크기가 중요하다고 생각했습니다.

적용한 최적화 전략

이미지 크기를 줄이기 위해 다음과 같은 전략을 적용했습니다

 

최적화를 위한 전략

• ✅ 경량 베이스 이미지 사용: Alpine Linux 기반 이미지
• ✅ 멀티 스테이지 빌드: 빌드 도구, 테스트 파일 제외
• ✅. dockerignore설정: 불필요한 파일 제외
• ✅ 정적 리소스 분리: HTML/CSS/JS는 CDN에서 서빙
• ✅ 이미지 레이어 최적화: Dockerfile 작성 순서 조정

👉 Alpine Linux 란?

구분	이미지 크기
최적화 전 (기본 설정)	1.99 GB
Alpine 베이즈 적용 후	약 1.7 GB
Multi-stage 및 정리 후 최종	723MB
ECR 업로드 시 최종 이미지	약 300~400 MB

 

 

🎯 최종적으로 약 58%의 크기 절감에 성공했으며, 실제로 ECR에 이미지를 push 하거나 배포하는 시간도 체감할 수 있을 만큼 빨라졌습니다.

 

아쉬운 점은 정적 리소스 파일을 스프링부트 서버에서 서빙하는 게 아니라 외부 서비스를 이용하면 이미지 크기를 더 줄일 수 있었지만, 마땅한 서비스를 찾지 못했고 해결 구현 방법을 적용하지 못했다는 점입니다.

 

느낀 점

처음에는 단순히 Dockerfile을 작성해서 애플리케이션을 컨테이너로 띄우는 것에 집중했지만, 이번 경험을 통해 운영 환경에서 배포 효율성과 비용까지 고려한 설계의 중요성을 느낄 수 있었습니다.

 

• 단순히 잘되는 Dockerfile 구현을 넘어 가볍고 빠르며 안정적인 이미지가 실제 서비스 품질에 영향을 미친다는 점
• 도커 이미지 최적화와 관련된 다양한 레퍼런스를 찾아보며 이론-실습-성과 분석을 한 흐름 자체가 큰 학습이 되었다.

 

정리하며
도커 이미지 최적화 이론부터 실전 적용까지 진행하며 관련 자료들을 많이 찾아보고 책도 읽어보며 몰입을 해보는 경험을 할 수 있었습니다. 또한 과정 속에서 하나하나 실습해 보며 정리의 중요성, 실제 결과 분석이 보다 성장하게 만드는 것 같았습니다.

 

🐻운영 환경 모니터링 구축기: Spring Boot + Prometheus + Grafana

이번 프로젝트에서는 초기 기획 단계부터 서버 모니터링 시스템 도입을 목표로 삼고 진행했습니다. 지금까지 잘 돌아가는 스프링 부트가 내부적으로 어떤 상태인지 파악해 보고 성능 개선을 위한 첫 단계로 적용해보고 싶었기 때문입니다. 이에 시간을 들여 스프링 매트릭과 프로메테우스, 그라파나를 사용하는 방법에 대해서 정리 후 실제 프로젝트에 적용했습니다.

 

👉 관련 포스트 : 운영 환경 대비를 위한 서버 모니터링 구축 학습기

운영 환경 대비를 위한 서버 모니터링 구축 학습기 : Spring Actuator, Prometheus, Grafana

 

 

실제 학습을 진행하면서 스프링 컨테이너가 제공하는 기능을 사용했습니다. 실제 프로젝트에 적용하는 방법은 어렵지 않았고 프로메테우스와 그라파나도 미리 만들어진 대시보드를 사용하는 방법과 컨테이너로 띄울 수 있다면 손쉽게 연결할 수 있었습니다. 

 

실제 프로젝트에 붙여보면서 기술적인 구현 방법보다는 각 용어들이 무슨 뜻인지 그리고 어떤 아키텍처로 구현이 되었고 내가 간편히 사용할 수 있는가에 대해서 정리했습니다. 

 

모니터링 목표 설정

초기 목표는 다음과 같았습니다.

• 애플리케이션의 동시 요청 처리 상태 (스레드 풀) 모니터링
• HikariCP 기반 DB 커넥션 풀 모니터링
• JVM 힙 메모리 사용량 모니터링 

실제 스프링부트가 동시에 여러 요청을 처리할 수 있는지에 대해서 궁금하였고 스레드 풀의 변화를 눈으로 확인해 보았습니다. 이에 어떤 방식으로 동시에 요청 처리할 수 있는지에 대해서 궁금하게 되었습니다. 이에 추가로 스레드에 관해서 기본적인 개념에 대해서 책과 인터넷 강의, 블로그 등을 통해서 정리하고 있습니다.

 

• Spring Boot는 과연 어떻게 동시에 여러 요청을 처리하는 걸까?
• 내가 본 Tomcat Threads 수치는 무엇인가?

위의 궁금증을 해결하기 위해서 자바 스레드에 대해서 학습, 정리, 실습을 해보면서 블로그를 정리하고 있으며 관련 지식들을 확장해 나가고 있습니다.

 

👉 관련 포스트 시리 : 스레드란 무엇인가? : Spring Boot 모니터링을 하다 생긴 궁금증

스레드란 무엇인가: Spring Boot 모니터링을 하다 생긴 궁금증 (1)

 

느낀 점

이번 프로젝트에서는 다양한 업무와 함께 추가적으로 모니터링을 구축하면서 일정 산출을 해보고 모니터링 시스템에 대해서 학습과 간단히 눈으로 보는 것까지를 목표로 설정했었습니다. 왜냐하면 다음 프로젝트에서 학습한 내용을 바탕으로 빠르게 모니터링 서비스를 구축하고 JMeter와 같은 툴을 사용해서 실제 요청을 많이 날려보고 성능을 분석해보고 싶었기 때문입니다. 

 

또한 눈으로 수치를 확인해 보면서 스레드와 커넥션 풀, 메모리 등 수치를 확인해보면서 개발 시 성능을 최적화하여 코딩할 수 있도록 느끼고 싶었습니다.

 

마무리

이번 프로젝트를 진행하면서 계속해서 고민했던 것이 있습니다. 바로 나에게 프로젝트를 한다는 것은 무엇인가 입니다.

프로젝트를 하면서 어떤 것을 얻기를 원하고, 무엇을 중점에 두고 어떤 방식으로 성장해 나갈 것인가에 대한 고찰이 있었습니다. 

 

저에게 있어서 이번 프로젝트는 나의 학습이 주된 목표였고, 내가 한 코드와 설계 구현, 아키텍처에 대한 것은 설명할 수 있어야 한다는 생각을 했습니다.

 

스터디 '투게더' 에서 '함께 자라기' 라는 책을 함께 읽고 소프트웨어 스킬에 대해서 많이 고민하고 스터디원들과 많은 이야기를 했었습니다. 여기서 저는 프로젝트를 성공하기 위해서 팀원들과의 소통을 중요하게 여기게 되었고, 신뢰 자산을 바탕으로 프로젝트의 성숙도를 높일 수 있다 라는 생각을 가졌었습니다. 

 

프로젝트를 진행하면서 나의 학습과 함께 자라기 사이의 균형을 찾기가 어려웠던 것 같습니다. 팀원 모두의 코드를 읽어보고 버그가 예상되거나 요구사항에 맞지 않게 코딩된 부분을 식별하고 보다 나은 방식을 제안하기 위해서 노력했습니다. 하지만, 나의 학습을 중요시 여기는 부분도 있어서 어느정도 타협하고 넘어가는 부분도 있었습니다.

 

균형을 잡기 (시간적 분배, 타협 등) 어려웠으나, 나의 학습이 더 중요하다고 생각을 많이 했었고 비중을 조금 더 두었던 것 같습니다. 주로 내가 했던 작업들을 정리하고, 노션에 이후에 정리하기 편하게 초안을 작성했었습니다. 그리고 퇴고를 하며 티스토리에 블로깅하였습니다. 이 과정에서 글로 내 생각을 정리하고 학습한 내용을 정리하게 되면서 학습이 잘 되었던 것 같습니다.