결제 시스템이 멈추지 않으려면 — 아메리칸 익스프레스의 '셀 기반' 아키텍처 이야기

카드 결제가 1분만 멈춰도 벌어지는 일

마트에서 카드를 긁었는데 "승인 실패"가 떴다고 생각해보세요. 한 번이면 다시 긁으면 그만이지만, 전국에서 동시에 이런 일이 벌어지면 어떻게 될까요? 결제 시스템은 잠깐의 멈춤도 그대로 돈과 신뢰의 손실로 이어지는, 정말 예민한 분야거든요. 그래서 아메리칸 익스프레스(아멕스) 같은 글로벌 카드사는 "어떻게 하면 시스템 일부가 고장 나도 전체가 멈추지 않게 할까"를 늘 고민해요. 이번에 아멕스 엔지니어링 팀이 공개한 해법이 바로 셀 기반 아키텍처(Cell-based Architecture)입니다.

'셀'이 뭐냐면

셀(cell)이라는 말이 좀 생소하죠. 이게 뭐냐면, 시스템 전체를 똑같이 생긴 여러 개의 작은 독립 단위로 쪼개는 거예요. 각 셀 안에는 서비스 처리에 필요한 게 다 들어 있어요. 애플리케이션 서버도 있고, 데이터베이스도 있고, 캐시도 있고요. 하나의 셀이 그 자체로 완전한 미니 결제 시스템인 셈이에요.

비유하자면 큰 식당 하나를 운영하는 대신, 똑같은 메뉴를 파는 작은 식당 열 개를 운영하는 거랑 비슷해요. 한 가게 주방에 불이 나도 나머지 아홉 가게는 멀쩡하게 손님을 받잖아요. 셀 아키텍처의 핵심이 바로 이거예요. 한 셀이 죽어도 그 셀이 담당하던 고객만 영향을 받고, 나머지 고객은 아무 일 없었다는 듯이 결제를 계속할 수 있게 하는 거죠. 이렇게 "고장의 피해 범위"를 줄이는 걸 업계에서는 블라스트 레이디어스(blast radius, 폭발 반경) 축소라고 불러요.

트래픽은 어떻게 셀로 나뉠까

그럼 들어오는 요청을 어느 셀로 보낼지는 누가 정할까요? 여기서 셀 라우터(cell router)라는 얇은 길잡이 계층이 등장해요. 예를 들어 회원번호나 계좌 ID를 기준으로 "이 고객은 3번 셀", "저 고객은 7번 셀" 하는 식으로 미리 정해서 항상 같은 셀로 보내는 거예요. 중요한 건 이 라우터를 최대한 단순하고 가볍게 유지한다는 점이에요. 라우터 자체가 복잡하고 무거우면, 그게 또 하나의 거대한 단일 장애점(single point of failure)이 되어버리니까요.

또 하나 멋진 점은 배포(deploy) 방식이에요. 새 버전을 한 번에 전체에 올리지 않고, 먼저 한 셀에만 올려보는 거예요. 거기서 문제가 없으면 다음 셀로 점점 넓혀가고요. 만약 새 버전이 버그를 품고 있어도 피해는 셀 하나로 막을 수 있어요. 마이크로서비스가 "기능 단위"로 잘게 쪼개는 거라면, 셀은 "전체 스택을 통째로 복제해서 격리"하는 거라 결이 조금 달라요.

업계 흐름에서의 위치

사실 이 패턴은 아멕스가 처음 만든 건 아니에요. AWS가 내부 인프라를 안정적으로 운영하려고 오래전부터 써온 방식이고, 슬랙(Slack)이나 도어대시 같은 회사들도 비슷한 셀/샤드 격리 전략을 공개한 적이 있어요. 다만 카드 결제처럼 "단 1초의 중단도 용납 안 되는" 영역에서 실제로 어떻게 적용했는지를 구체적으로 보여줬다는 게 이번 글의 가치예요. 흔히 쓰는 멀티 리전(multi-region) 이중화가 "지역 전체가 죽으면 다른 지역으로"라는 큰 단위 대비책이라면, 셀은 그보다 훨씬 촘촘한 그물망을 한 겹 더 까는 거라고 보면 돼요.

한국 개발자에게 주는 시사점

"우리는 아멕스만큼 크지 않은데?" 싶을 수 있어요. 하지만 핵심 아이디어인 "피해 범위를 잘게 가두자"는 규모와 상관없이 통하거든요. 예를 들어 멀티테넌트 SaaS를 운영한다면, 고객사를 몇 개 그룹으로 나눠 각 그룹을 독립된 인프라 묶음에 배치하는 것만으로도 "한 고객 때문에 전체가 느려지는" 노이지 네이버(noisy neighbor) 문제를 크게 줄일 수 있어요. 핀테크나 커머스처럼 트래픽 폭주와 안정성이 둘 다 중요한 국내 서비스라면 특히 곱씹어볼 만한 패턴이에요.