앱 개발에서 확장성이란 무엇인가요?

성장은 보이지 않던 약점을 드러냅니다

변화가 서서히 찾아오기도 합니다. 앱이 조금 느리게 느껴지고, 지원 문의가 쌓이고, 릴리스 날에 긴장감이 높아집니다.

갑자기 찾아오기도 합니다. 캠페인이 크게 퍼지고, 언론 소개로 방문이 몰리고, 목적을 가진 프로젝트가 뉴스레터에 공유됩니다. 하루 사용자 500명이 5만 명이 됩니다. 일 년이 아니라 주말 사이의 일입니다.

프로젝트에서 우리가 보는 것은 다음과 같습니다. 확장성이 중요해지는 이유는 기술에 대한 관심보다 신뢰를 지키고 싶어서인 경우가 많습니다. 부하를 받을 때 앱이 흔들리면 오류 하나만 생기는 것이 아닙니다. 사람들의 생각도 달라집니다. 사용자가 떠나고, 평가가 낮아지고, 팀은 위기 대응에 들어갑니다.

기대는 냉정합니다. 모바일 웹 경험에서도 기다릴 여유가 얼마나 적은지 드러납니다. 로딩에 3초가 넘게 걸리면 53% 이상이 페이지를 떠납니다. Marketing Dive(Google의 2016년 연구)↗

앱이 웹사이트와 완전히 같지는 않지만 감정의 논리는 같습니다. 바로 작동하지 않으면 믿을 수 없다고 느낍니다.

우리의 첫 관점은 확장성이 사회적 효과를 안정적으로 전달하는 힘이기도 하다는 것입니다. 더 많은 사람에게 닿아야 하는 교육 앱이나 기부를 움직이는 플랫폼이라면 안정성은 기술만의 문제가 아닙니다. 책임의 일부입니다. 과부하가 걸린 로그인 처리 때문에 목표가 좌절되어서는 안 됩니다.

그래서 Pola는 초기에 간단하지만 중요한 질문을 합니다. 앱은 예측 가능한 성장, 예측 불가능한 급증, 또는 둘 다에 대비해야 하나요? 이 구분이 나중에 처리 용량, 탄력성, 견고함 중 무엇을 먼저 볼지 결정합니다.

사용 부하와 제품 복잡성은 서로 독립적으로 커집니다

확장 가능한 앱을 만들어야 한다고 하면, 더 많은 사용자가 동시에 들어올 수 있어야 한다는 뜻인 경우가 많습니다. 중요하지만 절반의 이야기입니다.

확장성에는 두 성장 축이 있습니다.

첫째, 부하의 증가입니다. 동시 요청, 트래픽, 기기, 푸시·동기화·업로드 같은 백그라운드 작업이 늘어납니다. 앱 시장이 커지면서 모든 것이 자연스럽게 작동해야 한다는 기대도 높아집니다. 밀도만 봐도 압박이 드러납니다. 2023년 Google Play Store에는 370만 개 이상, Apple App Store에는 약 180만 개의 앱이 있었습니다. Selleo↗

둘째, 기능의 증가입니다. 새 기능, 역할, 연동, 시장이 추가됩니다. 화면 5개로 시작한 앱도 시간이 지나면 규칙, 특수 사례, 예외가 있는 제품이 됩니다. 많은 문제가 여기서 생깁니다. CPU가 약해서가 아니라, 모든 변경이 갑자기 위험해지기 때문입니다.

구분이 중요합니다. 확장성은 성능과 같지 않습니다. 성능은 주어진 부하에서 얼마나 빠른지를 설명합니다. 확장성은 부하가 증가해도 성능을 얼마나 잘 유지하는지를 설명합니다.

우리가 자주 쓰는 비유가 있습니다. 성능은 빈 선로에서 기차가 얼마나 빨리 달리는가입니다. 확장성은 승객이 갑자기 세 배가 되어도 문이 막히거나 신호가 고장 나거나 전체 운행이 멈추지 않고 시간표가 유지되는가입니다.

우리의 두 번째 관점은 확장성이 팀이 일하기 좋은 아키텍처이기도 하다는 것입니다. 실제로는 앱뿐 아니라 작업하는 팀도 커집니다. 여러 개발자가 병렬로 결과를 내야 한다면 변경을 서로 분리하는 구조가 필요합니다. 확장 가능한 앱은 테스트하기 쉽고, 모듈화되어 있고, 이해하기 쉬운 앱이기도 합니다.

두 축을 초기에 명확히 하면 결정이 쉬워집니다. 어떤 프로젝트는 먼저 부하의 여유가 필요하고, 어떤 프로젝트는 기능 증가를 위한 정돈된 기반이 필요합니다. 둘을 함께 다루는 경우도 많지만, 비중은 명확해야 합니다.

네 질문으로 여유를 구체화합니다

충분하다는 기준을 아무도 정하지 않으면 확장성은 감각의 문제가 됩니다. 그래서 초기에 일상 업무에서도 유효한 형태로 정리합니다.

현장에서 검증한 방법을 내부적으로 Four-Question Test라고 부릅니다. 프로젝트에서 잊히지 않도록 의도적으로 간단하게 만들었습니다.

1) 핵심 순간은 무엇인가요? 예를 들어 가입, 결제, 기부 완료, 데이터 업로드입니다.

2) 핵심이라는 것을 숫자로 표현하면 무엇인가요? 예를 들어 동시 세션 500개 또는 초당 요청 50개와 응답 시간 목표입니다.

3) 어느 정도 비용을 허용하나요? 금액뿐 아니라 운영의 복잡성도 포함합니다.

4) 잘못되면 무엇이 일어나나요? 매출 손실, 신뢰 손실, 놓치는 사회적 효과입니다.

여기서 숫자에 파묻히지 않고 모니터링할 지표가 나옵니다. 지연 시간은 응답 시간이며 가능하면 95백분위수로 봅니다. 처리량은 초당 요청 수입니다. 오류율에는 타임아웃, 5xx, 충돌률이 포함됩니다. 그리고 요청당 비용입니다.

비용도 보는 이유는 무엇일까요? 그렇지 않으면 확장이 눈치채지 못한 비용 증가로 이어질 수 있습니다. 좋은 확장성은 서버를 계속 늘리는 것이 아니라 투입 자원당 성능을 높이는 것입니다. 자주 놓치는 투자 효과가 여기에 있습니다. 효율적인 앱은 클라우드 비용을 줄이고 에너지 소비도 줄입니다.

경제적 측면에서는 실제 사례가 도움이 됩니다. 작은 지연도 비용을 만들 수 있습니다. Amazon은 내부적으로 100밀리초의 추가 지연이 매출에 1% 영향을 줄 수 있다고 관찰한 것으로 전해집니다. LinkedIn 게시물(Amazon 발언 재인용)↗

이런 수치는 압박하기보다 우선순위를 명확히 하려고 사용합니다. 핵심 순간이 전환이라면 확장성은 기술의 추가 사항이 아니라 가치 창출을 보호하는 일입니다.

실무에서 차이를 만드는 점도 있습니다. 측정할 수 있다는 것은 안심할 수 있다는 뜻이기도 합니다. 모니터링과 부하 테스트가 있으면 잘되기를 바라기만 하지 않고 확인할 수 있습니다.

사용 급증은 가장 좁은 지점을 만납니다

부하 때문에 앱이 멈추면 밖에서는 서버 과부하라는 한 문제로 보입니다. 실제로는 거의 언제나 병목이 이어진 결과입니다.

대표적인 것은 데이터베이스입니다. 처음에는 하나의 중앙 저장소에 일관되고 추적 가능한 정보가 있어 편리합니다. 그러다 단일 쿼리가 갑자기 천 배 자주 실행되거나, 잠금이 쓰기를 막거나, 부적절한 인덱스 때문에 검색이 전체를 훑는 작업이 됩니다.

비슷하게 자주 문제가 되는 것은 코드입니다. 느리게 작성해서가 아니라, 너무 밀접하게 연결해서입니다. 함수 하나가 다른 세 함수를 호출하고, 외부 API를 기다리며, 동시에 로그를 동기식으로 씁니다. 사용자 50명에게는 작동하지만 5천 명에게는 연쇄 문제가 됩니다.

처음에는 거의 이야기하지 않는 병목도 있습니다. 과정과 릴리스입니다. 긴급 수정을 밤에만 배포할 수 있고, 배포가 두렵고, 릴리스 후 무엇을 봐야 하는지 아무도 모른다면 확장되는 것은 시스템이 아니라 스트레스입니다.

우리의 세 번째 관점은 확장성이 장애 대응을 쉽게 만드는 것이기도 하다는 것입니다. 증가뿐 아니라 문제가 생길 때를 위해 만듭니다. 견고한 앱에는 명확한 경계, 타임아웃, 대체 수단이 있습니다. 팀이 상황을 빠르게 이해하도록 돕습니다.

실무에서 사용하는 간단한 원칙은 ‘핵심 처리는 짧게 유지하기’입니다. 가입, 결제, 기부 같은 핵심 순간에는 의존성이 최대한 적어야 합니다. 이후 이메일을 보내거나 PDF를 만들거나 통계를 갱신한다면 비동기로 처리합니다.

많은 장애가 비싼 이유도 여기서 드러납니다. 다운타임은 기술 상태뿐 아니라 사업 손실입니다. Atlassian은 대기업 장애로 수천만 규모의 손실이 발생한 사례를 제시합니다. Atlassian↗

이 영향을 느끼는 데 Facebook만 한 규모는 필요하지 않습니다. 작은 제품은 단지 완충 여력이 더 적습니다.

성능을 높이는 것과 인스턴스를 늘리는 것은 다른 문제를 해결합니다

확장을 이야기하면 두 기본 모델을 만나게 됩니다. 수직 확장과 수평 확장입니다.

수직 확장은 한 시스템의 성능을 높이는 것입니다. CPU, RAM, 데이터베이스 구성을 늘립니다. 빠르게 적용되고 구조 변경이 적어서 첫 단계인 경우가 많습니다. 하지만 한계가 있습니다. 어느 시점부터 매우 비싸지고, 장애가 날 수 있는 중앙 지점도 남습니다.

수평 확장은 여러 인스턴스에 부하를 나누는 것입니다. 서버 한 대를 더 강하게 하는 대신 여러 대를 사용합니다. 이상적으로는 사용 급증 때 자동으로 늘리고 한가할 때 줄입니다.

수평 확장에는 보통 두 가지가 필요합니다. 트래픽을 나누는 로드 밸런서와 상태를 자체적으로 저장하지 않는서비스입니다. 기술적으로 들리지만 간단합니다. 세션이 서버 A에만 저장되어 로그인도 A에서만 작동하면 B는 도울 수 없습니다. 반대로 상태를 공통 저장소, 예를 들어 데이터베이스나 Redis같은 캐시에 두면 어느 인스턴스든 처리할 수 있습니다.

실제 확장은 혼합인 경우가 많습니다. 약간의 수직 확장으로 빠르게 여유를 얻고, 중요한 곳에 수평 확장을 적용합니다.

우리가 항상 기억하는 점은 신뢰성과 확장성이 가까운 관계라는 것입니다. 수평 구성에서는 중복 구조도 자연스럽게 만드는 경우가 많습니다. 인스턴스 하나가 실패하면 다른 것이 맡습니다. 성능뿐 아니라 위험도 개선합니다.

여기에 Pola의 관점이 있습니다. 상시 최대 성능보다 시스템의 탄력성을 중시합니다. 필요할 때만 자원을 추가하면 비용과 불필요한 에너지 소비를 줄입니다. 낭비하지 않는 태도를 기술로 표현하는 것입니다.

처음 시작할 때 중요한 결정은 Kubernetes를 쓸지보다 앱이 기본적으로 여러 인스턴스에서 동작할 수 있는가입니다. 이를 제대로 준비하면 여러 경로를 열어 둘 수 있습니다.

성립하는 가장 간단한 경로가 최선인 경우가 많습니다

아키텍처 논의는 모놀리스는 나쁘고 마이크로서비스는 좋다는 식으로 흐르는 경우가 많습니다. 우리는 다르게 봅니다. 많은 제품에는 초기의 잘 만든 모놀리스가 적합합니다. 구현, 테스트, 이해가 더 쉽기 때문입니다.

문제는 모놀리스 자체보다 경계 없는 모놀리스입니다. 모든 부분이 서로 얽혀 있으면 어떤 변경도 비싸집니다.

그래서 또 다른 검증된 방법을 사용합니다. ‘기술이 아니라 책임으로 나누기’입니다. 초기부터 업무 영역으로 구조화해 나중에 일부를 분리해도 제품 전체를 뜯어내지 않도록 합니다.

일반적인 경로는 다음과 같습니다.

• 계정, 콘텐츠, 결제처럼 명확한 영역을 가진 모듈식 모놀리스로 시작합니다.
• 어떤 영역이 크게 성장하거나 특별한 요구가 생기면 별도 서비스로 분리합니다.
• 팀과 운영에 실제 이점이 있을 때 여러 독립 서비스로 발전시킵니다.

왜 이 순서일까요? 마이크로서비스는 부분별 독립 운영을 가능하게 하지만 네트워크 통신, 분산 디버깅, 버전 관리, 관측 가능성이라는 새 작업도 가져옵니다. 이미 있는 복잡성에 대응할 때 가치가 있습니다. 복잡성을 사들이기 위해 쓰지는 않습니다.

스타트업 맥락의 경고도 맞닿아 있습니다. 스타트업 실패의 큰 비중이 너무 이른 확장과 관련 있다는 지적이 있습니다. 주로 조직과 전략의 문제지만 원칙은 적용할 수 있습니다. LinkedIn 게시물(Startup Genome 수치 재인용)↗

우리의 입장은 문을 계획하되 처음부터 집 전체를 짓지는 말자는 것입니다. 앱은 MVP로 시작할 수 있습니다. 다만 성장 단계마다 처음부터 다시 시작하지 않을 구조여야 합니다.

이런 결정을 더 살펴보고 싶다면, 이후 기능과 사용자 그룹을 추가한 앱 프로젝트에서도 비슷한 아키텍처 질문을 지원했습니다. 예를 들어 Ureka나 Aeri입니다. 맥락은 매번 다르지만 규모보다 명확함을 우선하는 원칙은 같습니다.

캐싱과 분리는 필요한 여유를 만듭니다

확장 가능한 앱을 실용적으로 개선할 때 큰 개편부터 시작하는 경우는 드뭅니다. 몇 가지 집중된 구성 요소가 즉시 안정성을 높이는 경우가 많습니다. 자원 낭비를 줄이므로 지속가능한 사고에도 맞습니다.

캐싱을 먼저 적용하는 경우가 많습니다. 같은 홈페이지를 1만 명이 열면 시스템이 같은 작업을 1만 번 할 필요가 없습니다. 예를 들어 Redis같은 캐시는 자주 쓰는 데이터를 메모리에 저장해 데이터베이스와 백엔드의 부담을 덜어 줍니다.

CDN도 대표적인 구성입니다. 이미지, 자산, 경우에 따라 API 응답 일부를 사용자 가까이에서 전달합니다. 지연과 핵심 시스템 부하를 낮춥니다. 많은 팀에는 Cloudflare가 CDN, 캐싱, 보호 기능을 결합하기 쉬운 빠른 출발점입니다.

큐는 급증을 예측할 수 없을 때 우리가 선호하는 구성 요소입니다. 모든 것을 즉시 처리하기보다 작업을 받아 백그라운드에서 처리합니다. 부하의 급격한 증가를 완화하고 시스템에 기다릴 여유를 줍니다. 기술적으로는 RabbitMQ나 더 큰 규모에서 Apache Kafka를 사용할 수 있습니다.

그다음에는 데이터베이스 전략이 있습니다. 읽기 성능을 위한 복제, 적절한 인덱스, 때로는 파티셔닝입니다. 마이크로서비스만큼 화려하지는 않지만 실제 변화가 시작되는 지점인 경우가 많습니다.

이 순서는 원칙의 강요보다 경험의 관찰입니다. 먼저 분명한 비효율을 줄이고, 그다음 분산합니다.

우리 관점에서는 환경을 고려한 성장은 좋은 엔지니어링인 경우가 많습니다. 필요할 때만 늘어나는 아키텍처는 보통 더 저렴하고, 상시 최대 규모로 작동하는 시스템보다 에너지도 적게 씁니다. Scand도 부하가 늘 때만 자원을 추가하는 자원 효율로 확장성을 설명합니다. Scand↗

목적을 중시한다면 조용하지만 중요한 점입니다. 제품은 성장해도 운영이 상시 과열된 상태로 함께 커질 필요는 없습니다.

테스트 없이는 회복력이 가정에 머뭅니다

확장성은 개발뿐 아니라 무엇보다 운영에서 만들어집니다. 잘 준비된 듯한 팀에도 사용 급증을 통제할 테스트, 알림, 명확한 루틴이 빠져 있는 경우를 너무 자주 봤습니다.

부하 테스트는 사치처럼 들리지만 실제로는 가장 저렴한 현실 점검 중 하나입니다. Miquido도 앱의 성장 가능성은 부하 및 성능 테스트로 드러난다고 실용적으로 설명합니다. Miquido↗

현대적인 파이프라인에 맞는 도구로 우리는 k6를 좋아합니다. 스크립트 기반이고, 자동화가 쉽고, 결과가 명확합니다. 전통적인 구성에서는 JMeter나 Gatling도 탄탄한 선택입니다.

모니터링도 필요합니다. CPU가 높다는 것뿐 아니라 어느 엔드포인트가 느려지는지, 어떤 DB 쿼리가 부하를 차지하는지, 어디서 오류율이 오르는지 봅니다. 지표, 로그, 분산 시스템의 추적을 포함한 관측 가능성이 필요합니다. 검증된 오픈소스 조합은 Prometheus와 Grafana입니다. 더 빨리 시작하고 싶다면 Datadog이나 New Relic이 실용적인 경우가 많습니다.

다음은 장애 대응 준비입니다. 실제로 문제가 크게 나면 어떻게 할까요?

우리는 간단하게 유지하며 팀과 세 가지를 연습합니다.

1) 릴리스에는 관찰이 필요합니다. 첫 30분에 어떤 지표를 확인합니까?

2) 알림은 행동으로 이어져야 합니다. 무시되는 많은 알림보다 적절한 소수의 알림이 낫습니다.

3) 롤백도 기능입니다. 되돌리기 어려우면 모든 업데이트가 위험해집니다.

Pola의 작업은 출시에서 끝나지 않습니다. 성능, 유지보수성, 운영을 함께 생각합니다. 확장성은 일상에 안심을 줄 때 실제 의미를 갖기 때문입니다. 그 안심은 사용자가 이름을 붙이지 못해도 느끼는 품질입니다.