수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기를 읽고 나서

오늘 읽은 토스페이먼츠의 `수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기`는 꽤나 인상적이었다. 인프라와 운영 자동화에 관심이 많아서 예전부터 설정 관리나 대규모 환경에서 발생하는 문제와 패턴에 대해 고민했었던 내게는 공감가는 부분과 아직 잘 모르는 부분이 동시에 있었던 것 같다.

설정 관리는 왜 중요한가?

나는 현업에서 조차 적은 서버 수를 다룰 때에는 복붙으로도 그럭저럭 돌아가는 게 현실이라고 느꼈다. 근데, 글에서처럼 2000개, 3000개, 심지어 그 이상이 되면 오타 하나가 엄청난 서비스 장애로 이어질 수 있다는 점은 너무 무섭고 현실적인 경고였다. 엄청난 금액의 트랜잭션이 실리는 환경에서는 작은 실수가 수십억, 수백억의 돈을 날릴 수도 있다는 점에서, "설정도 코드 개발처럼 바라보고 설계한다."는 접근이 정말 맞다고 느꼈다. 나는 실수 투성이었던 사회초년생 신입사원 시절, PG사에서 결제 코어 개발을 담당했던 적이 있었다. 단순 설정 오탈자 하나 때문에 장애가 발생되었고 장애 원인을 찾지 못해 주말까지 일했던 아찔하고 현타오는 장애 발생 경험을 했었다.

오버레이 아키텍처와 템플릿, 그 조합의 힘

내가 보기에는 YAML 계층 구조와 템플릿 엔진을 결합해 설정을 유연하게 만드는 시도가 특히 인상적이었다. 환경 별, 클러스터 별, 서비스 별 등 계층이 분리돼 있고 우선순위가 부여된 설계는 깔끔하다고 생각한다. 복잡한 요구사항이 생겨도 고정된 구조에 갇히지 않고 점진적으로 진화할 수 있기 때문이다.
다만, 템플릿 패턴으로 값 조합을 지원하는 과정에서 중복이나 고질적인 복잡성도 내부적으로는 쌓이지 않을까 하는 생각도 조금 들었다. 결국 템플릿 자체가 늘어나면 또 그것을 관리하는 난이도도 올라갈 수 있으니, 이 부분을 어떻게 풀었을지가 더 궁굼해졌다.

현업에도 적용가능한가?

내가 만약 대규모 SaaS 서비스의 인프라를 담당한다면, 굳이 거창한 플랫폼을 개발하지는 못해도, 최소한 설정의 계층화를 시도해보고 싶다는 생각이 들었다. 사실 작은 프로젝트라도 "복붙을 줄이는 환경"을 만드는 건 모든 규모에서 중요한 일인 것 같다. 우리 팀에서는 아직 각 서비스별 config 파일을 개별로 관리하고 있는데, 이런 오버레이나 템플릿 접근은 충분히 적용해볼 가치가 있다고 느꼈다. (한 번 팀내에 공유를 해보겠다!)

배치 시스템과 선언적 인프라 관리

특히 내가 좋아하는 Jenkins Job-DSL을 활용한 선언형 빌더 패턴, 그리고 이를 어댑터로 감싸 단순히 Groovy 함수 한 두 줄로 공통화된 배치 환경을 만드는 점은 정말 크게 공감했다. CI/CD 파이프라인이나 배치를 돌아가게 만들 때마다 늘 만든 사람이 나중에 무슨 옵션을 줬는지 몰라서 곤란했던 기억이 떠올랐다. 그리고, 테스트 가능하도록 했다는 점… 즉, 설정 자체를 사전 검증한다는 점에서 많은 장애를 예방할 수 있겠다는 생각도 들었다.

동적 프로비저닝과 비용

나는 동적 프로비저닝에 대한 지식이 부족하다. 하지만 동적 프로비저닝 이야기도 나름 재밌었다. 고정된 노드를 계속 유지하는 것보다, 쓰임에 따라 노드를 동적으로 할당하고, 사용이 끝났을 때 스케일 하지 않는 구조는 트래픽 변동이 심한 서비스에선 필수가 아닐까 싶다. 실제로 Kubernetes, 서버리스 같은 플랫폼이 대세가 된 이유이기도 한 것 같다.
장비 표준화와 자동화 배포를 위해 jar 배포 경로 표준화까지 같이 했다는 설명이 공감갔다. 결국 인프라 자동화는 소프트웨어와의 규약에 달린 것 같다는 생각이 든다.

계속 진화하는 설정, 그리고 DevOps의 가치

큰 틀에서 봤을 때 "진화"라는 키워드가 진짜 핵심이지 않을까..? 시스템도, 설정도, 기술도 계속 변하니까, 구조 자체가 유연하고 변화에 강해야 한다는 점이 요즘 DevOps의 본질인 것 같다. 인프라가 고도화될수록, 개발자와 인프라 엔지니어가 분리되지 않고 같이 변화를 리딩하는 문화도 정말 중요하다는 생각이 들었다. 뭐...요새는 aiops라는게 있지만, 이건 논외인 것 같다.

아쉬운 점과 궁금한 점

• 설정 진화 과정에서 발생할 수 있는 기술 부채는 어떻게 관리하는지 궁금하다. 오버레이나 템플릿도 시간이 지나면 헷갈리거나 중복, Legacy가 많아지지 않을까?
• Jenkins와 같은 기존 툴 활용이 매우 현실적이지만, 점점 Kubernetes-native Job 관리 플랫폼(예를 들어 Argo Workflows 같은...)으로 이전할 계획은 없는지도 궁금하다.
• AI/ML 파이프라인 운영에서도 이런 설정 체계가 잘 먹힐지, 아니면 좀 더 다른 접근이 필요할지?

---

참고 문헌:
수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기 - 토스 기술 블로그