Spring Cloud — 흩어진 서비스를 하나처럼 묶는 도구 모음

서비스를 하나로 크게 만들면(모놀리식) 단순하다. 코드도 한 군데, 배포도 한 번, 설정도 한 파일이다. 그런데 서비스가 커지고 팀이 늘면 이 "하나"가 족쇄가 된다. 작은 수정에도 전체를 다시 배포해야 하고, 결제 트래픽이 몰리면 전혀 상관없는 회원 기능까지 같이 느려진다. 그래서 큰 덩어리를 여러 개의 작은 서비스로 쪼개는 마이크로서비스(MSA)로 간다.

그런데 쪼개는 순간, 모놀리식에선 공짜였던 것들이 전부 새로운 문제가 된다. 한 파일이던 설정은 수십 개로 흩어지고, 같은 프로세스 안에서 함수 호출이던 것은 네트워크 통신이 되며, 서비스들은 서로의 주소조차 모른다. Spring Cloud는 바로 이 "쪼갰더니 생긴 문제들"을 각각 담당하는 도구들의 모음이다. 이 글은 개별 도구를 깊게 파기 전에, 무엇이 어떤 문제를 맡는지 지도를 먼저 그린다.

1. 쪼개면 생기는 네 가지 공통 문제

마이크로서비스로 가면 거의 항상 같은 문제들을 만난다. 도구를 보기 전에, 왜 그 도구가 필요한지부터 분명히 해두자. 도구는 항상 문제의 답이지, 그 자체가 목적이 아니기 때문이다.

이 네 문제는 서로 독립적이지 않다. 게이트웨이가 요청을 받아 적절한 서비스로 넘기려면 먼저 그 서비스의 위치를 디스커버리에서 찾아야 하고, 각 서비스는 Config에서 설정을 받아 부팅된다. 즉 이들은 한 무대 위에서 맞물려 돌아간다.

2. 네 조각이 맞물려 도는 모습

문제를 하나씩 풀어주는 도구들이 실제로 어떻게 연결되는지 한 번에 보자. 하나의 외부 요청이 들어왔을 때, 이 조각들이 차례로 개입한다.

각 조각의 자세한 동작은 별도 글로 나눈다. Config Server는 "설정을 어떻게 중앙화 하는가", Eureka는 "서비스들이 어떻게 서로를 찾는가", API Gateway는 "단일 입구가 무엇을 해주는가"를 각각 깊게 다룬다. 이 글은 그 전에 전체 지형을 머리에 넣어두기 위한 것이다.

3. 도구를 쓰기 전에 따져볼 것

Spring Cloud의 도구들은 강력하지만, MSA 자체가 복잡성의 비용을 동반한다는 걸 잊으면 안 된다. 모놀리식 하나면 끝날 일을, 디스커버리·게이트웨이·설정 서버까지 굴려야 하는 인프라로 바꾸는 것이기 때문이다.

정리하면 Spring Cloud는 "서비스를 쪼갰기 때문에 새로 생긴 문제들"의 표준 해법 묶음이다. 설정·발견·입구·격리라는 네 축으로 기억해 두면, 개별 도구를 배울 때 "이건 그 중 어느 문제를 푸는 거지?"로 자리를 잡을 수 있다. 도구가 먼저가 아니라 문제가 먼저다.

한 장 요약