1차 프로젝트 회고에 이어, 1주일만에 돌아온 2차 프로젝트 회고 글이다.
이번에는 밀리지 않고 싶어서 프로젝트 발표 끝나자마자 작성해 본다.
2차 프로젝트 회고
프론트와 백엔드의 API 연동 대전쟁
- 2차 프로젝트 초반에는 핵심 기능을 제외한 부가 기능들에 대한 API 연동 작업을 했다.
- 아무래도 단기간에 빠르게 개발한 탓에, API 명세서와 틀어진 부분들도 있었고 백엔드 로직 내부에 잘못된 계산식이 들어가 있어서 올바르지 않은 반환 값이 돌아오는 경우도 있었다.
- 거의 1주일 기간동안 프론트 및 백엔드 연동 관련 내용에 시간을 쏟은 것 같다.
- 백엔드 개발 시점에서는 몰랐던 관점 차이를 정말 많이 알게된 것 같다.
- 프론트엔드 개발자의 퍼포먼스는 생각보다 백엔드 개발자의 수준과 밀접한 관계가 있다.
그동안 나 때문에 고생했던 프론트엔드 개발자들에게 사과를...
취약점 분석 보고서...를 작성... 했어요...
- 미처 생각 못했던 취약점 분석 보고서가 깜짝 퀘스트로 등장했다.
- 다른 팀의 프로젝트를 분석해서 취약점을 찾아 공격 시나리오를 작성하는 내용이다.
- 내가 분석하게 된 팀이 함께 팀 스터디를 진행했던 팀원 분이여서 죄송했지만, 오히려 성공적인 프로젝트가 되실 수 있도록 최대한 열심히 했다.
- ML 모델 학습 데이터셋 취약점
- Git Commit에 올라와 있던 Key 값 탈취로 실제 공격 성공 등
- 주로 정보보호병 시절이랑 보안기사 필기 공부할 때 배웠던 지식들을 사용해서 5가지 정도의 공격 시나리오를 제안드렸다.
EKS 운영 리소스가 우리 주머니에서 돈을 털어가요
- 비용이 정말 맙소사다 맙소사.
- 우리는 고작 t3.medium worker node 4개 밖에 사용하지 않는데도, EKS를 통해서 운영하니 시간당 0.308$ 가 부과된다.
- 그래서 기존에 있던 코어타임 시간을 줄이고, 좀 더 Strict한 리소스 관리를 도모하고 있다.
- 이후 Terraform, Ansible 등을 추가로 도입해서 완전한 프로비저닝 자동화를 꿈꾸고 있다.
등 뒤에 VPCEndpoint 있어요
- 최근 SGI서울보증보험 보안 침해사고 사례 등을 참고하여 전통적인 SSH Key 기반 접근에 대한 취약점들을 발견했다.
- 우리 프로젝트에도 적용하면 너무 좋을 것 같아서, Bastion Host를 Private Subnet으로 배치하고 SSM + EC2 Instance Connect를 활용하여 보안성을 강화했다.
- 이렇게 되면, Public IP 자체를 Bastion Host 자체가 지니고 있지 않기 때문에 공격 표면이 최소화된다.
- 다만 이 과정에서 EIP 3개와 VPCEndpoint 들이 사용돼 시간당 0.039$ 가 부과된다.
- 작아보일 수 있지만 24시간 기준으로 30일을 돌린다고 가정하면 생각보다 부담되는 금액이다.
- 이후 프로비저닝 과정에서 Terraform 을 활용하여 Destroy를 해서 코어타임에만 사용하도록 개선할 예정이다.
시간이 부족해서 선택했던 SQS, 지적을 받다
- 우리 서비스의 기존에 개발되어 있던 거래 엔진에 대한 트랜잭션 무결성을 개선하는 과정에서 SQS 도구를 채택했다.
- 내가 해당 거래 엔진을 분석했을 때, 인메모리 큐를 활용하여 무결성을 개선하고 있었기에, 아무 생각없이 Queue 구조를 분리하면 되겠다! 싶어서 SQS 도구를 채택했었다.
- 하지만, 주문 트랜잭션 자체에 Queue 구조를 활용하는 것이 올바르지 않은 것 같다는 지적을 받았다.
- 해당 파트의 팀원은 실제로 Kafka 도입을 검토했었는데, 시간이 부족해서 내가 제안했던 SQS 도구를 채택한 것 같다.
- 조금 더 면밀히 신경 썼어야 하는데 잘못된 정보를 제안한 것 같아 죄송했다.
- 그래서 Kafka 도입을 재검토하고, 마지막 프로젝트인 3차 프로젝트에 개선할 예정이다.
이외의 추가된 기능들
- 정적 코드 분석 도구(Semgrep) 연동
- 동적 코드 분석 도구(OWASP ZAP) 연동
- Grafana 대시보드 연동
- 대시보드 템플릿은 쿼리 짜기가 매우 어려워서, 기본 템플릿들을 사용했다.
- RDS Event를 SNS + Lambda 조합을 통해 Discord Webhook 호출로 알림 시스템 구축
그렇게 만들어진 2차 프로젝트 최종 아키텍처...

좋았던 점
- 언젠가 내가 CTO가 된다면, '개발자가 아니라 소프트웨어 엔지니어처럼 일하라' 라는 말을 하고싶다.
- 건방져보일 수도 있지만 그만큼 문제 해결에 진심인 소프트웨어 엔지니어가 되고싶다.
- 그 중에서도 시스템, 인프라, 아키텍처 쪽에 기여하는 사람이 되고싶다.
- 그 직업의 이름이 클라우드 엔지니어, DevOps, 시스템 엔지니어인지는 크게 상관없다.
3차 프로젝트에서 할 일들
[핵심]
- Terraform 을 활용한 AWS 인프라 관리 자동화
- Ansible 도입을 통한 프로비저닝 자동화
- ArgoCD 적용을 통해 배포 자동화 및 GitOps 환경 실현
- 애플리케이션 관련 데이터 자동 백업/복구 시스템 구축
- Kafka 마이그레이션
[욕심]
- AI 관련 기능을 한 스푼 얹고 싶다.
다음은 3차 프로젝트 회고이자, 수료식 회고로 돌아올 예정이다.
마지막 남은 1개월, 화이팅!
'Personal > Notes' 카테고리의 다른 글
| 구름 딥다이브 클라우드 네이티브 교육과정을 마치며 (4) | 2025.10.24 |
|---|---|
| [KDT 해커톤 후기] K-디지털트레이닝 해커톤 최우수상 (고용노동부 장관상) 후기 (4) | 2025.09.05 |
| [구름톤 딥다이브 후기] - 클라우드 네이티브 엔지니어링, 1차 프로젝트 회고 #7 (3) | 2025.08.07 |
| [구름톤 딥다이브 후기] - 클라우드 네이티브 엔지니어링, 11주차 ~ 16주차 #6 (이론기간 회고 및 팀 프로젝트 포부) (7) | 2025.06.23 |
| [구름톤 딥다이브 후기] - 클라우드 네이티브 엔지니어링, 8주차 ~ 10주차 #5 (0) | 2025.05.10 |