그동안은 비즈니스 미팅에서 빠르게 보여주기 위해 로컬 환경에서 구동되는 것에 집중했습니다.
이제 핵심 기능인 인앱브라우저 개발에 들어가며, 실제 기기에서 테스트해보기 위해 인프라 구축을 시작했습니다.
1. 처음 접해보는 AWS
기존에 팀프로젝트들을 했을 때에는 매번 인프라를 맡은 팀원이 있었습니다.
저는 프론트엔드나 백엔드를 맡아 인프라를 제외한 기능 개발에 힘썼었죠.
인프라에 대해서는 해당 팀원이 Linux 화면에서 로그 찍고 서버 재시작하는걸 옆에서 본 게 전부였습니다.
사수도 없는 환경에서 처음 접해보는 인프라 구축을 해야했고, 회사 돈이 지출되는 일이다 보니 잘못 설정해서 요금이 많이 부과될까봐 긴장됐습니다.
그래서 처음에는 EC2, RDS를 프리티어로 생성하며 최대한 무료 범위 안에서 구성하려 했습니다.
하지만 막상 서비스 형태를 갖추기 시작하니 Load Balancer, NAT Gateway, CloudFront 등 프리티어만으로는 안 되는 영역들이 생겨났습니다.
결과적으로 서비스를 런칭하기 전인데도 매달 약 60달러 정도는 고정적으로 지출되고 있었습니다.
- RDS(DB, 30달러), CloutFront(정적 파일 CDN, 15달러), VPC(NAT Gateway, 10달러), EC2, Route 53, Tax 등
그래도 추가비용을 감수하는 대신 그렇지 않은 경우보다 개발 시간과 안정성을 확보할 수 있었습니다.
인프라를 다룰 때마다 AWS 콘솔에서 요금 관리 확인, 현 단계에서 꼭 필요한 구성인지 여부를 계속 반복해서 확인하며 진행해나갔습니다.
"EC2 하나 띄우고, RDS 하나 붙이면 되겠지?" 라는 생각으로 시작했는데, 어느 순간 보니 제가 들어가 본 서비스가 이렇게 많았습니다.
- Systems Manager
- 결제 및 비용 관리
- IAM
- EC2
- VPC
- Aurora & RDS
- KMS
- Route 53
- S3
- CloudFront
- WAF & Shield
- AWS Firewall Manager
- Certificate Manager
이번 글에서는 이 모든 서비스에 대해 다루기보다는 실제로 막혔던 문제 하나를 중심으로 적을 생각입니다.
2. Android HTTP 차단
인앱 브라우저를 통해 브랜드몰에 접속하는 기능을 만들고, 이제 실제 기기로 테스트를 해볼 차례였습니다.
그런데 Android에서 예상치 못한 벽에 부딪혔습니다.
로컬 개발 환경에서는 잘 작동했던게 Android 환경에서는 에러가 발생했던 것입니다.
net::ERR_CLEARTEXT_NOT_PERMITTED
검색해보니, Android 9 Pie 버전부터는 HTTP 연결을 기본적으로 차단한다는 걸 알게 됐습니다.
HTTP는 보안 측면에서 큰 문제를 지니고 있기 때문이죠.
- 데이터가 평문(암호화되지 않음)으로 전송됨
- 중간에 누군가가 가로채서 내용을 볼 수 있음(중간자 공격)
- 로그인 정보, 결제 정보, 개인 정보 등이 그대로 노출
- 악의적으로 데이터를 변조할 수 있음
HTTP를 임시로 허용하는 설정을 추가할 수도 있지만, 캐시백 앱은 사용자의 구매 정보를 다루기 때문에 이런 보안 위험을 그냥 넘어갈 수 없었습니다.
Google Play 정책도 HTTPS 사용을 강력히 권장하고 있었습니다.
그래서 HTTPS를 제대로 적용하기 위해 SSL 인증서부터 발급받았습니다.
[SSL 인증서]
SSL 인증서는 이 서버가 신뢰할 수 있는 서버라는 것을 증명하고, 통신 내용을 암호화해주는 장치입니다.
HTTP가 클라이언트와 서버가 암호화되지 않은 상태로 통신한다면, HTTPS는 SSL 인증서를 기반으로 암호화된 통신 채널을 생성합니다.
HTTPS에서는 다음과 같은 과정이 추가됩니다.
- 클라이언트가 서버에 접속 시도
- 서버가 SSL 인증서를 전달
- 클라이언트가 인증서의 유효성을 검증
- 신뢰가 확인되면 암호화 키를 교환
- 이후 모든 통신은 암호화된 상태로 진행
이 덕분에 중간에 패킷을 가로채더라도 내용을 해석할 수 없고, 데이터가 변조되었는지도 바로 감지할 수 있습니다.
저는 ACM(AWS Certificate Manager)에서 SSL/TLS 인증서를 발급받았습니다.
3. AWS Load Balancer
HTTPS 설정을 검색해보니 여러 방법이 나왔습니다.
EC2에 직접 인증서를 설치하는 것보다, AWS Load Balancer를 사용하는 것이 훨씬 관리하기 쉬워보였습니다.
EC2가 HTTP로 받으면, ALB(Application Load Balancer)가 HTTPS를 처리해줍니다. ACM 인증서도 자동으로 갱신됩니다.
로드밸런서는 여러 서버에 트래픽을 분산시키는 역할을 한다는 것 정도로만 알고 있었습니다.
아직 서버가 1대밖에 없는데 로드밸런서를 사용한다는 점이 신기했습니다.
그래서 더 알아보니 로드밸런서는 단순히 트래픽을 분산시키는게 아니라, 클라이언트와 서버 사이에서 SSL을 종료해주는 프록시 역할도 한다는 것을 깨달았습니다.
// ALB의 역할
1. HTTPS 프록시 (SSL 종료)
앱 → [암호화 HTTPS] → ALB → [내부 HTTP] → EC2
2. 트래픽 분산 (로드밸런싱)
나중에 EC2 10대가 돼도 ALB가 알아서 나눠줌
3. 자동 인증서 갱신
ACM이 알아서 SSL 갱신
[DNS 설정]
로드밸런서를 만들고 나니 긴 주소가 나왔습니다.
myapp-alb-1234567890.ap-northeast-2.elb.amazonaws.com
이제 이걸 api.myapp.com 으로 연결해야 했습니다.
검색하니 Route 53(AWS DNS 서비스)을 쓰라는 글이 많았습니다.
하지만 도메인은 이미 가비아에서 구매한 상태였고, 가비아에서 CNAME에 추가하면 되니 굳이 옮길 필요는 없어 보였습니다.
(Route 53은 추후에 해외 서비스 리팩토링 과정에서 사용하게 됩니다.)
시도 1: CNAME 추가(실패)
가비아 DNS 관리 페이지에서 다음과 같이 저장하고 기다렸는데 연결이 안됐습니다.
타입: CNAME
호스트: api
값: myapp-alb-1234567890.ap-northeast-2.elb.amazonaws.com
실패한 원인은 기존에 A레코드로 api.myapp.com 이 이미 등록되어 있었기 때문입니다. CNAME과 A레코드가 동시에 있으면 충돌이 발생했던 거죠.
시도 2: A레코드 삭제 후 CNAME 추가(실패)
CNAME이 ALB를 가리키므로 A레코드를 삭제해도 괜찮습니다.
그래서 기존 A레코드를 지우고 다시 시도했지만 이번엔 다른 에러가 나타났습니다.
CNAME 값이 올바르지 않습니다
알고보니 가비아는 CNAME 값 끝에 .(점)이 있어야 인식했습니다.
시도 3: .(점) 추가(성공)
맨 끝에 .(점)을 추가한 뒤 5~10분 기다리니 드디어 연결이 됐습니다.
타입: CNAME
호스트: api
값: myapp-alb-1234567890.ap-northeast-2.elb.amazonaws.com.
이 점 하나 때문에 DNS 설정에서 꽤나 오랜 시간을 보냈습니다.
이후 브라우저와 Android 앱에서 테스트를 하니 HTTPS로 정상 작동했습니다.
4. 아직도 HTTP를 쓰는 브랜드몰이 있다구요?
HTTPS 문제를 정리하던 중, 큰 문제를 발견했습니다.
입점 예정 브랜드 중 하나의 브랜드몰이 아직도 HTTP로만 운영되고 있었던 것입니다.
우리 서비스는 ALB와 SSL 인증서로 HTTPS를 적용해 통신 구간을 암호화했지만, 인앱 브라우저로 이동한 외부 브랜드몰이 HTTP라면 그 구간은 여전히 평문 통신입니다.
"브랜드사에 HTTPS로 바꾸라고 요청해야하나?" 싶었지만
해당 브랜드 입장에서도 서버 설정 변경은 부담스러운 일이고, 우리가 강제할 수 있는 입장도 아니었습니다.
다행히도 그 브랜드는 네이버 스마트스토어도 운영하고 있었고, 스마트스토어는 기본적으로 HTTPS를 사용하고 있었습니다.
그래서 자체 브랜드몰 대신 네이버 스마트스토어 링크를 브랜드몰로 삼아 우회하는 방식을 통해 보안 문제를 해결했습니다.
보안은 선택이 아니라 필수입니다. 특히 결제, 주문, 개인 정보처럼 민감한 데이터를 다루는 서비스라면 더욱 그렇습니다. 적당히 되니까 괜찮겠지라는 생각은 나중에 더 큰 비용으로 돌아올 수 있습니다.
인프라 비용도 마찬가지였습니다.
처음에는 AWS 추가 비용이 부담스럽게 느껴졌지만 HTTPS 적용, 로드밸런서 도입, 헬스 체크, 보안 그룹 분리 같은 기능들은 결국 서비스 안정성과 신뢰를 사는 비용이었습니다.
최소 비용을 추구하는 것도 좋지만, 필요한 부분에는 제대로 쓰는게 맞다고 생각합니다.
다음 글에서는 핵심 기능인 인앱브라우저와 주문추적에 대해 다루겠습니다.
'개발 > 주니어 개발자의 캐시백 앱 단독 개발기' 카테고리의 다른 글
| 7. 편했던 ScrollView를 FlatList로 바꾸게 된 이유 (0) | 2026.02.09 |
|---|---|
| 6. 인앱브라우저에서 주문을 추적하는 법 (0) | 2026.01.29 |
| 4. 갑자기 해외 서비스도 추가된다고? (0) | 2026.01.19 |
| 3. 앱 소셜 로그인의 첫 관문 - SHA-1과 키 해시 (0) | 2026.01.07 |
| 2. 브랜드마다 다른 캐시백 정책, 어떻게 DB에 담을까? (0) | 2026.01.05 |