안녕하세요! 프로덕트 디자이너 메리입니다.
비가 추적추적 오니 막걸리 한사바리 하고 싶은 날이군요.
오늘은 디자이너/기획자도 한 번쯤은 들어봤을 AWS에 대해 아주 기초적인 개념만 콕 집어 정리해보려 합니다.
AWS 안에는 정말 많은 기능이 있는데요. 이 기능을 잘 쓰면 주먹밥, 흩어지면 볶음밥이랍니다.(오늘도 피곤해서 걍 아무말이나 뱉는중)
☁️ AWS란?
Amazon Web Services의 줄임말로, 말 그대로 아마존이 제공하는 클라우드 컴퓨팅 서비스입니다.
우리가 흔히 생각하는 '서버'를 직접 사서 관리하는 게 아니라,AWS라는 거대한 공간 안에 있는 컴퓨터(=서버)를 빌려서 사용하는 구조에요.
쉽게 말해:
🧍♀️옛날: 회사에서 직접 서버 컴퓨터를 사서 사무실에 설치함
☁️요즘: AWS에서 서버를 몇 개 클릭만으로 임대함 (필요할 때만 사용료 지불)
라고 볼 수 있습니다. 예전에 전산실 ? 서버실 사진 보셨을련지.. (제가 9n년생이라 전 교과서에서 많이봤어요)
요즘은 세상이 좋아져서 AWS에서 클릭 몇번으로 서버를 빌릴 수 있다는 사실~
1. EC2 (Elastic Compute Cloud)란?
EC2는 AWS에서 가장 기본이 되는 가상의 서버에요. 디자이너 입장에서 EC2는 이렇게 이해하면 좋아요 :
우리가 디자인한 서비스를 실제로 "돌아가게 하는 컴퓨터", 로그인 기능, 결제 기능 등 서버 로직이 돌아가는 공간이라고 볼 수 있죠. EC2를 하나 만든다는 건 = 서버 한 대 빌렸다는 뜻이에요.
2. S3 (Simple Storage Service)
S3는 이미지, 영상, 파일 같은 것들을 저장하는 저장소에요. 우리가 업로드한 유저의 프로필 사진, 배너 이미지, 첨부파일 등을 저장할 때 사용하는 곳입니다. 디자인 시스템에 들어가는 이미지들, 유저가 업로드한 사진이나 첨부파일,앱/웹에서 쓰이는 정적 파일들(css/js 등)이 여기에 들어가죠.
3. 인스턴스란?
EC2를 만들면 생기는 실제 서버의 '작동 중인 상태'를 의미해요. 예시로, 컴퓨터를 샀는데, 전원을 안 켜면 그냥 기계죠? EC2라는 서버를 만들고, 작동시키면 그게 "인스턴스"가 되는 거예요! 인스턴스는 필요할 때만 켜고, 안 쓸 땐 꺼서 비용을 아낄 수도 있어요.(= 그래서 개발자들이 테스트용 인스턴스는 다 꺼놓자~ 같은 얘기 자주 함!)
🧪 스테이징 / 개발 / 상용 서버는 뭐가 다른 거야?
우리가 말하는 "서버 환경"은 AWS 인스턴스를 어떻게 나눠서 관리하느냐에 따라 달라집니다.
- 개발 서버 (Dev): 개발자가 새 기능을 마음껏 테스트하는 곳
- 스테이징 서버 (Stage): 실제 운영 환경이랑 최대한 비슷하게 구성해서 QA나 시연을 해보는 곳
- 상용 서버 (Prod): 진짜 사용자가 접속하는 운영 서버! 실수하면 사고남!
이 각각의 환경도 결국 AWS 인스턴스로 만들어져요.
같은 EC2더라도 목적에 따라 나눠서 관리하는 거죠.
디자이너 입장에선,
🙋🏻♀️"이 디자인, 지금 어디에 올라간 거죠?"
🙆"이거는 스테이징이에요, 아직 프로덕션은 아님!"
이런 대화를 이해할 수 있게 되는 것만으로도 협업이 훨씬 수월해집니다.
🗃️ RDS (Relational Database Service)
RDS는 AWS에서 제공하는 데이터베이스 서비스인데요. RDS는 우리가 아는 MySQL, PostgreSQL 같은 데이터베이스를 AWS에서 쉽게 셋업해서 쓸 수 있도록 도와주는 서비스예요.
- 회원가입한 유저 정보
- 유저가 쓴 게시글, 댓글, 좋아요 등의 데이터
-> 이런 것들이 모두 DB(데이터베이스)에 저장되는데, 그걸 쉽게 구축하고 관리할 수 있게 해주는 게 RDS예요.
디자이너 입장에서 이걸 알면, "어떤 데이터가 어디 저장되는지", "이건 프론트에서 저장되는 게 아니구나" 같은 흐름을 이해하는 데 도움이 됩니다!
⚙️ Lambda (람다)
서버 없이도 특정 코드를 실행할 수 있는 기능! = 서버리스라고들 하는데요. 어떤 동작을 자동으로 실행해야 할 때, 굳이 EC2를 돌리지 않아도 되는 방식이에요.
예시)
- 📨 사용자가 가입하면, 환영 이메일 자동 발송
- 💸 결제 완료 시, 관리자에게 알림 보내기
이런 걸 "이벤트 기반으로 트리거 실행"하는 구조인데,
그때 람다 함수를 만들어두면 서버 없이도 필요한 작업이 자동으로 실행돼요!
디자이너 입장에서, 특정 액션이 자동으로 이어지는 로직(UI→알림 등)을 구성할 때 람다 개념을 알면 흐름이 훨씬 명확해집니다.
🔍 그 외에 개발에서 자주 쓰는 AWS 기능은?
- CloudFront : S3에 저장된 이미지나 정적파일을 빠르게 전송해주는 CDN 서비스
- Route 53 : 도메인 주소 관리 서비스 (ex. marykim.design)
- CloudWatch : 서버 로그/모니터링 툴, 장애 감지할 때 씀
- IAM : 권한 관리 기능 (누가 S3를 접근할 수 있는지 등 설정)
- ECS / EKS : 대규모 서비스 운영 시 컨테이너 단위로 배포하는 방식
이 중에서 디자이너와 가장 관련 있는 건 S3, CloudFront, IAM, CloudWatch 정도예요!
특히 IAM 기능의 경우, 피그마의 권한 초대와 굉장히 유사한데요.
AWS 계정을 누구에게나 다 알려줄 수 없으니 (보안이슈) IAM 계정을 만들고,
권한을 부여해서 같이 작업할 개발자를 초대하는 방식이라고 보면 될 것 같습니다.
💡 디자이너가 AWS를 알아두면 좋은 이유
1) 이미지 저장 방식이나 URL 구조를 이해할 수 있습니다.
2) 서버와 클라이언트의 구조를 감 잡을 수 있습니다. (중요!)
3) 트래픽이 몰릴 때 무슨 일이 벌어지는지 상상할 수 있어요.
4) 에러코드(5xx)가 왜 생기는지도 연결해서 이해돼요.
5) QA 단계에서 "이건 dev, 이건 prod입니다" 같은 말을 듣고 당황하지 않을 수 있어요.
마지막으로, 디자인 시스템에서 어떤 리소스가 어디에 저장되고, 누가 접근 가능한지 이해할 수 있어요.
특히나 협업할 때, 디자인이 실제로 배포되는 환경을 아는 디자이너는 지존입니다.
큰회사의 경우 자본이 많기(?) 때문에 막대한 서버비용에 대한 감당이 가능하지만, 스타트업이나 규모가 작은 회사의 경우 서버구조를 잘 짜야 서버비용이 많이 안나오기 때문에, 기획과 디자인단에서 서버비용을 고려한 설계가 거의 필수라고 볼 수 있습니다.
🔥 서버비용을 고려하지 않은 디자인 UI 예시
1. 무한 스크롤 + 썸네일 이미지 과다 노출
📌 문제: 홈 화면에 수십 개 썸네일 + 고화질 이미지 무한 로딩 → S3 + CloudFront 트래픽 폭증
🧾 예시: “사용자 피드에 이미지 30개가 한 번에 뜨게 해주세요~!”
💸 결과: CloudFront 요금 급상승, 특히 이미지가 고화질일수록 비용도 같이 늘어남
2. GIF 배너, 영상 자동재생
📌 문제: 첫 화면 진입부터 영상 or GIF 배너 자동재생 → 사용자 당 수십 MB 데이터 요청 발생
🧾 예시: 메인에 ‘움직이는 감성 배너’ 넣고 싶다며 매번 5초짜리 영상 업로드
💸 결과: 트래픽 요금 + CDN 과금 폭발 → 특히 모바일 사용자가 많은 서비스일수록 치명적
3. 검색/필터 기능 과도하게 나눠진 구조
📌 문제: 필터를 변경할 때마다 백엔드 API 여러 번 호출 (Ex. 색상별 + 사이즈별 + 별점정렬)
🧾 예시: “컬러칩 누를 때마다 실시간 반응 보여주세요~!”
💸 결과: EC2 인스턴스 부하 + RDS 호출 과다 → 서버 비용 상승 + 성능 저하
4. 파일 업로드 무제한 UI
📌 문제: 유저가 첨부파일 50개, 100MB 영상도 막 올릴 수 있는 UI 제공
🧾 예시: “유저가 사진 많이 올리면 좋잖아요~!” / “파일 크기 제한요? 그거 있으면 불편해요!”
💸 결과: S3 스토리지 비용 상승 → 특히 사용자가 많을 경우 금방 수백 GB 단위로 용량 차지
5. “좋아요”, “댓글”에 실시간 반응을 주는 구조
📌 문제: 모든 유저에게 알림 + 실시간 숫자 갱신 → Lambda 또는 WebSocket 과부하
💸 결과: 기능 하나에 이벤트 트리거가 과도하게 발생 → Lambda 실행 횟수 증가로 과금↑
💡 그래서 디자이너는?
“데이터가 언제, 어디서, 얼마나 불러와지는지”를 고려한 UI 설계가 필요합니다. 또한 클라이언트에서 미리 캐싱해둘 것 vs 서버에서 다시 호출할 것 구분하는 것도 필요하죠. 그래서 UI를 설계할 때, “한 번의 액션이 얼마나 많은 서버 리소스를 부를 수 있을까?” 생각해보는 것이 중요합니다.
예시를 보면 인스타그램, 무신사 같은 서비스가 생각나지 않나요? 이 서비스들은 굉장히 막대한 서버비용이 나올 수 있다고 볼 수 있죠. 하지만 우리 앱에 이 기능들을 넣는다면,, 바로 파산핑 되는겁니다~~~ (개발자들이 안된다고 하는 이유는 기능 구현이 힘든 것도 있지만, 저 기능을 넣으면 막대한 서버비용과 리소스가 발생하기 때문인거시죠)
👊🏻 마무리!
이번 편에서는 AWS 중에서도 자주 언급되는 EC2, S3, RDS, Lambda, 그리고 인스턴스 개념을 가볍게 정리해봤는데요. 거기에 실무에서 자주 듣는 스테이징/상용 환경 개념과, 개발자들이 자주 쓰는 AWS 기능들도 살짝 소개해봤습니다. 어때요. 그렇게 어렵지 않지 않나요?
다음엔 AWS 배포 구조나, CloudFront를 중심으로 한 성능 최적화 개념도 풀어보도록 하겠습니다.
제 글이 여러분들께 도움이 되길 바라며.. 서버비용을 아낄 수 있는 디자이너가 함 되보자구요? (저도 예전에 AWS 세팅 잘못해서 파산핑될뻔함;;;)
아무튼. 읽어주셔서 감사합니다. 다음 편에서 또 만나요!
