[회고] 새로운 여정의 시작

2026년 5월, 새로운 마음으로 다음 커리어를 시작하게 되었습니다. 새롭게 합류한 곳은 스테이블 코인과 블록체인, PG, PMS 등을 다루는 핀테크 스타트업입니다. 이전 회사에서 함께 일했던 동료의 감사한 추천 덕분에 면접 과정을 거쳐 좋은 기회로 입사할 수 있었습니다.

이곳에서 제 역할은 DevOps Engineer로서 인프라 전반을 담당하는 것입니다. 블록체인 코어부터 스테이블 코인 서비스에 이르기까지, 서비스 전반의 안전한 구축과 효율적인 운영을 책임지게 되었습니다. 입사 후 정신없이 달려온 두 달간의 치열했던 기록을 간략히 정리해 봅니다.

1. GitOps 기반의 CI/CD 파이프라인 고도화

입사 당시 회사는 한창 바쁜 격동의 시기를 지나고 있었습니다. 실제 고객을 위한 운영(Main) 환경의 직전 단계인 pre-main 배포가 한창이었고, 이를 뒷받침할 인프라와 CI/CD 파이프라인이 급하게 필요한 상황이었습니다. 현황을 채 파악하기도 전에 우선 배포 작업부터 뛰어들어야 했습니다.

하지만 기존 배포 현황을 파악했을 때 가장 크게 느낀 점은 ‘자동화의 부재’였습니다. 배포를 위해 GitLab과 Jenkins는 구축되어 있었지만, 쿠버네티스 환경임에도 ArgoCD 같은 GitOps 도구는 전무했습니다. Helm Chart로 배포하면서도 형상 관리(Config)를 사람이 수동으로 주입하고 있었고, Jenkinsfile 파이프라인을 직접 실행한 뒤 매번 서버에 접속해 배포 상태를 수동으로 확인해야 하는 구조였습니다.

인프라의 안정성과 휴먼 에러 방지를 위해 구조 개선이 시급하다고 판단했습니다. 마침 회사에서 기존 온프레미스 환경의 GitLab과 Jenkins를 AWS 클라우드 환경으로 이관할 계획이 있었기에, 이 이관 작업과 동시에 파이프라인 구조를 완전히 재설계했습니다.

ArgoCD & Argo Rollouts 도입: 클러스터 배포 프로세스를 완전한 GitOps 기반의 자동화 파이프라인으로 전환하고, 안전한 배포 전략을 확보했습니다.
형상 관리 최적화: Config 파일에 파편화되어 있던 설정 정보들을 ConfigMap과 Secret 등의 쿠버네티스 네이티브 리소스로 분리하여 관리 편의성과 보안성을 높였습니다.
Istio 연동 자동화: 기존에 수동으로 일일이 생성하던 Istio VirtualService 배포 환경 역시 파이프라인 안에서 유기적으로 고도화했습니다.

2. HA 기반 블록체인 인프라 및 네트워크 설계

신규 Main 서비스 배포를 준비하면서 아키텍처 측면에서도 대대적인 변경과 고민이 필요했습니다. 메인 운영 환경인 만큼 보안(Security)적인 측면과 장기적인 확장성(Scalability)을 동시에 만족하는 구조를 설계해야 했습니다.

개발팀과의 미팅을 통해 가장 중요하게 도출된 요구사항은 ‘고가용성(HA)‘과 블록체인 서비스 특성에 따른 ‘실시간 동기화’였습니다. 트래픽은 효율적으로 분산하되, 특정 노드로 트래픽이 몰려 동기화가 깨지는 현상이 발생하지 않도록 정교한 인프라 구성이 필요했습니다. 대외비 보안상 상세한 아키텍처를 모두 공개할 수는 없지만, AWS의 다양한 관리형 서비스들을 조합하여 고가용성 네트워크 환경을 구축해 낼 수 있었습니다.

더불어, 기존에 필요할 때마다 임의로 개방되어 관리가 안 되던 Security Group(보안 그룹)들을 전수 조사하여, ‘최소 권한의 원칙’에 맞게 전면 보안 최적화 작업을 진행했습니다.

3. 모니터링 통합 및 인프라 가시성(Observability) 확보

기존 환경의 모니터링 스택은 ES + Vector + Kibana + Grafana + Loki + Prometheus + Jaeger가 복잡하게 혼재된 상태였습니다. 가장 큰 문제는 각 VPC별로 Prometheus 서버가 파편화되어 있고, 모든 서버에 Vector가 심어져 있으며, Elasticsearch 인스턴스 마저 여러 개로 쪼개져 있다는 점이었습니다. 이로 인해 대시보드가 너무 많아져 모니터링은 하고 있지만 정작 ‘가시성(Visibility)‘은 확보하기 어려운 아이러니한 상황이었습니다.

우선 왜 이런 복잡한 구조가 되었는지 원인부터 분석했습니다. 현업 분들께 Kibana와 Grafana를 혼용하는 이유를 묻자, *“Kibana에서만 로그 검색이 되어서”*라는 답변을 받았습니다. 하지만 확인해 보니 특별히 고차원적인 쿼리를 쓰는 것이 아니었고, Grafana + Loki 조합으로도 충분히 구현 가능한 수준이었습니다. 단지 기존 환경에 Loki 검색 최적화 설정이 누락되어 있었던 것이 원인이었습니다. 이에 직접 POC를 진행하여 Grafana 중심으로 로그 검색 환경을 통일할 수 있음을 증명했습니다.

다음 고민은 자원 관리였습니다. Prometheus와 ES 모두 서버에 직접 데이터를 저장하는 구조라 메모리 관리에 지속적인 리소스가 들고 있었습니다. 이를 해결하기 위해 초기에는 OpenTelemetry(Otel) Collector 도입을 검토하고 통합 테스트까지 성공적으로 마쳤습니다.

하지만 테스트 과정에서 한 가지 의문이 들었습니다. “어차피 Kibana를 걷어내고 Grafana+Loki 진역으로 통일할 거라면, 아예 수집기까지 Grafana 생태계의 Alloy를 쓰는 게 연동성과 관리 측면에서 더 이득이지 않을까?”

최종 아키텍처 도출: Grafana + Loki + Tempo + Alloy + Mimir
도입 결과: 수동 메모리 관리에 개입할 필요가 없어졌고, 툴 간의 연동성도 극대화되었습니다.

두 대안(Otel vs Alloy)의 테스트 결과를 바탕으로 비교 레포트를 작성하여 공유했고, 최종적으로 Alloy 기반의 스택으로 구조 변경을 단행했습니다. 신규 대시보드 하나에서 전사의 메트릭·로그·트레이싱을 모두 확인할 수 있게 되었습니다.

현재 마이그레이션이 진행 중임에도 서버 대수가 크게 줄어 비용이 절감되었고, 장애 대응 시 컨텍스트 스위칭이 줄어들어 훨씬 빠른 트러블슈팅이 가능해졌습니다. 앞으로 Tempo를 더 적극적으로 활용하여 분산 추적(Tracing)과 AI 기반 분석 단계까지 확장하는 진정한 의미의 Observability(관측 가능성)를 구현해 가고자 합니다.

4. FinOps 관점의 리소스 최적화 및 비용 절감

스타트업 특성상 클라우드 비용을 무한정 쓸 수는 없으며, 비용 효율화는 인프라 엔지니어의 핵심 역량 중 하나입니다. 모니터링 아키텍처를 단일 클러스터로 통합하면서 인프라 유지 비용을 1차적으로 아낄 수 있었지만, 더 큰 비용 누수는 EKS(쿠버네티스) 환경에 있었습니다.

당시 EKS는 Karpenter에 의해 Auto-scale out/in이 되도록 구성되어 있었는데, 서비스가 새로 배포될 때마다 노드 대수가 과도하게 늘어나는 현상이 있었습니다. 실제 컨테이너들의 자원 사용량을 측정해 보니, 실제 사용량에 비해 Pod의 리소스 할당량(Request/Limit)이 너무 높게 잡혀 있는 것이 원인이었습니다. 불필요한 Scale-out이 유발되고 있던 것입니다.

EKS Rightsizing 수행: 실사용량과 할당량을 기준으로 전체 파드 컨테이너 리스트를 엑셀링하고, 갭이 큰 서비스들을 대상으로 최적의 값으로 튜닝하여 롤아웃을 진행했습니다.
결과: 기존에 15대까지 늘어나던 워커 노드를 11대까지 줄이며 클라우드 비용을 크게 절감했습니다.

추후 신규 배포 시에는 이러한 오버 프로비저닝을 사전에 방지하기 위해 네임스페이스 단위로 리소스를 제한하는 LimitRange 도입을 검토하고 있으며, 더 나아가 거버넌스와 보안 정책 강화를 위해 OPA Gatekeeper 도입을 함께 고민하고 있습니다.

🏁 마치며

입사 후 약 두 달이라는 짧은 시간 동안 진행했던 일들과 앞으로의 고민을 정리해 보았습니다. 스타트업 특성상 아직 명확하게 정의되지 않은 부분도 많고, 때로는 한치 앞을 모르는 거친 환경 속에서 문제를 해결해야 할 때도 있습니다.

하지만 같은 배를 탄 이상, DevOps Engineer로서 제가 맡은 인프라를 가장 단단하고 효율적으로 다지는 것이 저와 회사의 동반 성장을 위한 길이라고 믿습니다. 앞으로도 안주하지 않고 다양한 기술들을 치열하게 공부하고 도입하며 끊임없이 최적화를 이뤄내 대내외적으로 신뢰받는 인프라를 만들어가고 싶습니다.