[클라우드 활용 포트폴리오] 디지털 전환 사례와 AWS 서버리스 활용 전략

1. 학습 개요

이번 포트폴리오는 클라우드 활용 14주차 강의자료를 바탕으로, 디지털 전환(Digital Transformation, DX)의 개념과 산업별 변화 사례, 그리고 AWS 클라우드와 서버리스 아키텍처가 디지털 전환을 어떻게 가속화하는지 정리한 글이다.

이전 글에서는 EC2, S3, VPC, IAM, CloudWatch, CloudTrail, AWS Organizations, ELB, Auto Scaling, WAF, GuardDuty 등 AWS의 주요 서비스를 학습했다. 14주차는 이러한 개별 서비스 학습을 마무리하면서, 클라우드가 단순한 인프라 대체 수단이 아니라 기업의 비즈니스 모델과 운영 방식을 변화시키는 기반 기술이라는 점을 이해하는 데 초점을 맞춘다.

특히 14주차 자료는 크게 두 부분으로 나눌 수 있다.

첫 번째는 디지털 전환의 개념과 산업별 사례이다. 금융, 제조, 유통·물류, 의료, 공공 부문에서 클라우드와 AI, IoT, 빅데이터가 어떻게 활용되는지 살펴본다.

두 번째는 서버리스 아키텍처이다. 기존 서버 중심 아키텍처와 비교하여 서버리스가 어떤 장점을 가지며, AWS Lambda, API Gateway, DynamoDB, S3 같은 서비스가 어떻게 빠른 서비스 개발과 확장을 가능하게 하는지 학습한다.

이번 글에서 다룰 내용은 다음과 같다.

• 디지털 전환(DX)의 개념
• Digitization, Digitalization, Digital Transformation의 차이
• 디지털 전환의 목적과 기대 효과
• 산업별 디지털 전환 사례
• 클라우드가 DX를 가속화하는 이유
• 서버리스 컴퓨팅의 개념
• 기존 서버 기반 아키텍처와 서버리스의 차이
• AWS 주요 서버리스 서비스
• Lambda + API Gateway 실습 흐름
• 서버리스 실습 중 문제점 및 해결 방안
• 14주차 학습 후기

---

2. 디지털 전환이란 무엇인가?

디지털 전환(Digital Transformation, DX)은 디지털 기술을 활용하여 기존의 비즈니스 프로세스, 조직 문화, 고객 경험, 서비스 제공 방식을 근본적으로 변화시키는 과정이다.

중요한 점은 디지털 전환이 단순히 종이 문서를 PDF로 바꾸거나, 오프라인 업무를 온라인으로 옮기는 수준이 아니라는 것이다. 디지털 전환은 기술을 통해 비즈니스 모델 자체를 혁신하고, 데이터를 기반으로 새로운 가치를 창출하는 과정이다.

예를 들어 넷플릭스는 처음에는 DVD 대여 서비스에서 출발했지만, 이후 스트리밍 서비스로 전환하면서 비즈니스 모델 자체를 바꾸었다. 이처럼 디지털 전환은 단순한 업무 자동화가 아니라, 고객에게 가치를 제공하는 방식 자체를 바꾸는 변화라고 볼 수 있다.

---

3. 디지털 전환의 3단계

디지털 전환은 보통 다음 세 단계로 구분할 수 있다.

단계설명예시

Digitization	아날로그 정보를 디지털 데이터로 변환	종이 문서 스캔, PDF 저장
Digitalization	기존 업무 프로세스를 디지털 도구로 개선	이메일 결재, ERP 도입
Digital Transformation	새로운 방식의 가치 창출과 비즈니스 모델 혁신	플랫폼 비즈니스, 데이터 기반 서비스

3.1 Digitization

Digitization은 가장 기초적인 단계로, 아날로그 자료를 디지털 데이터로 바꾸는 과정이다.

예를 들어 종이 문서를 스캔하여 PDF 파일로 저장하거나, 수기로 작성하던 고객 정보를 엑셀 또는 데이터베이스로 옮기는 것이 여기에 해당한다. 이 단계에서는 업무 방식 자체가 크게 바뀌지는 않지만, 데이터를 저장하고 검색하기 쉬워진다는 장점이 있다.

3.2 Digitalization

Digitalization은 기존 업무 프로세스를 디지털 도구로 개선하는 단계이다.

예를 들어 종이 결재 대신 전자결재 시스템을 도입하거나, 수기로 관리하던 재고를 ERP 시스템으로 관리하는 것이 여기에 해당한다. 이 단계에서는 업무 효율성이 증가하고, 실시간 관리와 자동화가 가능해진다.

3.3 Digital Transformation

Digital Transformation은 단순한 변환이나 업무 개선을 넘어, 새로운 방식으로 가치를 창출하는 단계이다.

예를 들어 고객 데이터를 분석하여 개인화 추천 서비스를 제공하거나, 오프라인 중심 기업이 온라인 플랫폼 비즈니스로 전환하는 것이 여기에 해당한다. 이 단계에서는 기술이 단순한 보조 도구가 아니라, 새로운 비즈니스 모델을 만드는 핵심 요소가 된다.

---

4. 디지털 전환의 목적과 기대 효과

디지털 전환의 목적은 단순히 최신 기술을 도입하는 것이 아니라, 고객 경험을 개선하고 운영 효율성을 높이며 새로운 수익 모델을 만드는 것이다.

디지털 전환의 대표적인 기대 효과는 다음과 같다.

목적설명

고객 경험 개선	개인화 추천, 모바일 서비스, 옴니채널 경험 제공
운영 효율성 향상	자동화, 실시간 모니터링, 업무 프로세스 최적화
신규 수익 창출	데이터 분석 기반 서비스, 플랫폼 비즈니스 출시
의사결정 고도화	데이터 기반 예측과 분석으로 빠른 의사결정
비용 절감	인프라 자동화, 리소스 최적화, 운영 비용 감소
민첩성 향상	빠른 서비스 개발과 배포, 시장 변화 대응

예를 들어 고객 이탈률 감소, 매출 증가율 향상, 비용 절감률, 서비스 처리 시간 단축 등이 디지털 전환의 성과 지표가 될 수 있다.

---

5. 디지털 전환의 핵심 구성 요소

디지털 전환은 기술만으로 이루어지지 않는다. 강의자료에서는 디지털 전환의 핵심 구성 요소를 기술, 조직, 문화로 정리한다.

구성 요소설명

기술	클라우드, AI, IoT, 빅데이터 등 디지털 기반 기술
조직	애자일 방식, 크로스펑셔널 팀, 데이터 기반 의사결정
문화	변화 수용, 실험 장려, 실패 허용

5.1 기술

디지털 전환의 기술적 기반에는 클라우드, AI, IoT, 빅데이터, 모바일, API 등이 포함된다. 이 중 클라우드는 필요한 컴퓨팅 자원과 저장소, 데이터 분석 환경을 빠르게 제공하므로 DX의 기반 인프라 역할을 한다.

5.2 조직

디지털 전환은 IT 부서만의 프로젝트가 아니다. 서비스 기획, 개발, 운영, 마케팅, 고객 지원 부서가 함께 참여해야 한다. 따라서 부서 간 협업과 빠른 의사결정 구조가 중요하다.

5.3 문화

새로운 기술을 도입하더라도 조직 문화가 변하지 않으면 디지털 전환은 지속되기 어렵다. 작은 실험을 빠르게 수행하고, 실패를 통해 개선하는 문화가 필요하다.

---

6. 산업별 디지털 전환 사례

14주차 자료에서는 금융, 제조, 유통·물류, 의료·헬스케어, 공공 부문에서의 디지털 변화 사례를 다룬다. 각 산업은 서로 다른 문제를 가지고 있지만, 공통적으로 클라우드, AI, IoT, 데이터 분석을 활용하여 운영 방식을 개선하고 있다.

---

6.1 금융 산업

금융 산업에서는 모바일 뱅킹, 간편결제, AI 신용평가, 비대면 대출 심사 등이 대표적인 디지털 전환 사례이다.

예를 들어 모바일 앱에서 대출 신청을 하면, 기존에는 사람이 서류를 확인하고 심사하던 과정을 AI 기반 신용평가 시스템이 자동으로 처리할 수 있다. 이를 통해 고객은 더 빠르게 대출 가능 여부를 확인할 수 있고, 금융기관은 심사 시간을 줄일 수 있다.

금융 산업에서 클라우드를 활용하는 이유는 다음과 같다.

• 대규모 고객 데이터 처리
• AI 기반 신용평가 모델 운영
• 모바일 서비스의 안정적 운영
• 규제 준수를 고려한 보안 관리
• 실시간 이상 거래 탐지
• 빠른 서비스 출시

예시로 신한은행의 AI 기반 비대면 대출 심사 사례처럼, AWS 클라우드 기반 AI 신용평가 시스템을 구축하면 기존 대면 심사 대비 처리 시간을 줄이고, 고객은 모바일 앱에서 빠르게 대출 가능 여부를 확인할 수 있다.

---

6.2 제조 산업

제조 산업에서는 스마트 팩토리, 예측 유지보수, AI 품질 검사, IoT 센서 기반 설비 관리가 대표적인 디지털 전환 사례이다.

예를 들어 항공기 엔진이나 공장 설비에 IoT 센서를 부착하면 온도, 진동, 압력, 작동 시간 등의 데이터를 실시간으로 수집할 수 있다. 이 데이터를 클라우드로 전송하고 AI 모델로 분석하면, 고장이 발생하기 전에 이상 징후를 감지할 수 있다.

제조 산업에서 클라우드가 중요한 이유는 다음과 같다.

• 대량의 센서 데이터 저장
• 실시간 데이터 분석
• AI 기반 품질 검사
• 설비 고장 예측
• 생산 공정 자동화
• 글로벌 공장 간 데이터 통합

예를 들어 GE Aviation의 예측 유지보수 사례에서는 항공기 엔진에 IoT 센서를 설치하고, AWS IoT와 SageMaker를 활용해 데이터를 분석하는 방식으로 이상 징후를 사전에 감지할 수 있다. 현대자동차의 스마트 팩토리 사례처럼 카메라와 센서 데이터를 실시간 분석하여 불량률을 낮추는 방식도 제조 DX의 대표 사례이다.

---

6.3 유통·물류 산업

유통·물류 산업에서는 수요 예측, 자동 재고 보충, 로켓배송 시스템, 물류센터 최적화, 실시간 배송 추적 등이 대표적인 디지털 전환 사례이다.

예를 들어 쿠팡의 로켓배송 시스템은 주문 데이터를 기반으로 수요를 예측하고, 재고와 물류센터를 실시간으로 연동하여 배송 시간을 단축하는 방식으로 이해할 수 있다.

유통·물류 산업에서 클라우드가 중요한 이유는 다음과 같다.

• 주문 데이터의 실시간 처리
• 수요 예측 AI 모델 운영
• 재고 관리 자동화
• 물류센터 간 데이터 연동
• 배송 경로 최적화
• 트래픽 급증 대응

유통 서비스는 특정 이벤트나 할인 기간에 트래픽이 급격히 증가할 수 있다. 클라우드는 Auto Scaling과 서버리스 구조를 통해 트래픽 증가에 유연하게 대응할 수 있다.

---

6.4 의료·헬스케어 산업

의료·헬스케어 산업에서는 AI 영상 분석, 환자 데이터 통합, 원격진료, 의료 데이터 분석, 개인 맞춤형 진료 등이 디지털 전환 사례로 볼 수 있다.

예를 들어 CT나 MRI 영상을 AI 모델로 분석하면, 의료진이 암이나 질병의 이상 징후를 더 빠르게 확인하는 데 도움을 받을 수 있다. 대규모 의료 영상 분석에는 많은 GPU 자원이 필요하기 때문에, 클라우드 기반 인프라가 유용하다.

의료 분야에서 클라우드가 중요한 이유는 다음과 같다.

• 대용량 의료 영상 저장
• GPU 기반 딥러닝 분석
• 환자 데이터 통합 관리
• 글로벌 확장성
• 데이터 보안과 개인정보 보호
• 의료 규정 준수

예를 들어 서울아산병원의 AI 영상 분석 사례처럼 AWS 기반 딥러닝 모델로 CT/MRI 영상을 분석하면 판독 시간을 줄이고 진단 정확도 향상에 기여할 수 있다. Philips HealthSuite 사례처럼 전 세계 환자 데이터를 클라우드에서 통합·분석하는 방식도 의료 DX의 대표적인 흐름이다.

---

6.5 공공 부문

공공 부문에서는 스마트 시티, 전자민원, 교통·에너지·재난 대응 데이터 분석, 행정 서비스 자동화 등이 디지털 전환 사례이다.

예를 들어 싱가포르의 Smart Nation 사례처럼 교통, 에너지, 재난 대응 데이터를 중앙 데이터 허브에 모으고 실시간으로 분석하면 정책 의사결정에 활용할 수 있다. 국내에서도 정부24와 같은 전자민원 서비스는 클라우드 기반으로 안정성과 확장성을 높일 수 있다.

공공 부문에서 클라우드가 중요한 이유는 다음과 같다.

• 대국민 서비스의 안정적 운영
• 트래픽 급증 시 자동 확장
• 데이터 기반 정책 수립
• 공공 데이터 통합 관리
• 재난 대응 시스템 구축
• 비용 효율적인 인프라 운영

공공 서비스는 특정 시기나 정책 신청 기간에 트래픽이 급증할 수 있다. 클라우드의 Auto Scaling과 서버리스 구조를 활용하면 필요한 시점에만 자원을 확장하여 안정성과 비용 효율성을 동시에 확보할 수 있다.

---

7. 클라우드가 디지털 전환을 가속화하는 이유

디지털 전환을 위해서는 데이터를 빠르게 수집하고, 저장하고, 분석하고, 서비스로 연결할 수 있어야 한다. 클라우드는 이러한 과정을 빠르게 수행할 수 있는 기반을 제공한다.

클라우드가 디지털 전환을 가속화하는 이유는 다음과 같다.

 

이유설명

빠른 인프라 제공	서버, 데이터베이스, 스토리지를 몇 분 안에 생성 가능
확장성	트래픽 증가 시 자동으로 자원을 확장 가능
비용 효율성	필요한 만큼 사용하고 사용한 만큼 지불
글로벌 서비스	전 세계 리전과 엣지 로케이션을 통한 서비스 제공
데이터 분석 기반	빅데이터, AI, ML 서비스를 빠르게 활용 가능
민첩한 개발	서버리스와 관리형 서비스로 빠른 개발 가능
보안과 규정 준수	IAM, CloudTrail, GuardDuty, 암호화 등 보안 서비스 제공

즉, 클라우드는 디지털 전환에서 단순한 서버 대여 서비스가 아니라, 서비스 개발 속도, 데이터 활용, 확장성, 비용 효율성, 보안성을 함께 제공하는 기반이다.

---

8. 기존 서버 기반 아키텍처의 한계

기존의 서버 기반 아키텍처에서는 개발자가 애플리케이션 코드뿐만 아니라 서버 운영까지 직접 관리해야 했다. EC2 같은 가상 서버를 사용하는 경우에도 운영체제 패치, 런타임 설치, 보안 설정, 용량 계획, 스케일링, 장애 대응을 고려해야 한다.

기존 서버 기반 구조의 한계는 다음과 같다.

한계설명

서버 관리 필요	OS, 런타임, 패치, 보안 설정 관리 필요
용량 예측 부담	트래픽을 예측해 서버 크기와 개수를 미리 결정해야 함
유휴 비용 발생	요청이 없어도 서버가 실행 중이면 비용 발생
확장 구성 필요	Auto Scaling, Load Balancer 등을 직접 구성해야 함
장애 대응 복잡	서버 장애 시 복구와 교체 과정 필요
배포 관리 부담	배포 환경과 런타임을 지속적으로 관리해야 함

이러한 문제를 줄이기 위해 등장한 방식이 서버리스 아키텍처이다.

---

9. 서버리스 컴퓨팅이란?

서버리스(Serverless)는 개발자가 서버를 직접 생성하거나 관리하지 않고, 코드나 기능 단위로 애플리케이션을 실행할 수 있는 클라우드 컴퓨팅 방식이다.

서버리스라고 해서 실제로 서버가 없는 것은 아니다. 서버는 존재하지만, 서버의 생성, 확장, 장애 복구, 운영체제 관리 등을 AWS와 같은 클라우드 제공자가 담당한다. 사용자는 인프라 관리보다 비즈니스 로직 구현에 집중할 수 있다.

서버리스의 핵심 특징은 다음과 같다.

 

특징설명

서버 관리 불필요	서버 프로비저닝과 운영체제 관리를 직접 하지 않음
자동 확장	요청 수에 따라 자동으로 실행 규모 조절
이벤트 기반 실행	HTTP 요청, 파일 업로드, DB 변경 등 이벤트로 실행
사용량 기반 과금	함수 실행 시간과 요청 수 중심으로 비용 발생
빠른 개발	인프라 구성보다 코드 작성과 배포에 집중
관리형 서비스 연동	API Gateway, DynamoDB, S3 등과 쉽게 연결

 

---

10. 서버리스와 기존 아키텍처 비교

서버리스는 기존 서버 기반 아키텍처와 운영 방식이 다르다.

 

항목기존 서버 기반 구조서버리스 구조

실행 단위	서버 또는 인스턴스	함수 또는 이벤트
서버 관리	사용자가 직접 관리	클라우드 제공자가 관리
확장 방식	Auto Scaling 설정 필요	요청에 따라 자동 확장
비용 구조	서버 실행 시간 기준	요청 수와 실행 시간 기준
유휴 비용	서버가 켜져 있으면 발생	요청이 없으면 거의 없음
배포 방식	서버에 애플리케이션 배포	함수 단위 배포
적합한 업무	장시간 실행 서버, 복잡한 애플리케이션	이벤트 처리, API 백엔드, 자동화 작업

예를 들어 단순한 문의 접수 API를 만들기 위해 EC2 서버를 24시간 실행하는 것은 비용과 운영 측면에서 비효율적일 수 있다. 반면 API Gateway와 Lambda를 사용하면 요청이 들어올 때만 함수가 실행되므로, 작은 규모의 서비스나 이벤트 기반 서비스에 적합하다.

---

11. AWS 주요 서버리스 서비스

AWS에서는 서버리스 아키텍처를 구성하기 위해 다양한 서비스를 제공한다. 대표적인 서비스는 다음과 같다.

서비스역할

AWS Lambda	서버 없이 코드를 실행하는 함수형 컴퓨팅 서비스
Amazon API Gateway	HTTP API 또는 REST API 엔드포인트 제공
Amazon DynamoDB	서버리스 NoSQL 데이터베이스
Amazon S3	객체 스토리지, 정적 웹 호스팅, 이벤트 트리거
Amazon EventBridge	이벤트 기반 서비스 연결
Amazon SQS	메시지 큐 기반 비동기 처리
Amazon SNS	알림 및 메시지 발행/구독
AWS Step Functions	여러 서버리스 작업의 워크플로우 관리
Amazon CloudWatch	로그와 지표 모니터링

서버리스 아키텍처는 단일 서비스 하나로 완성되는 것이 아니라, 이벤트 흐름에 따라 여러 서비스를 조합하여 구성된다.

예를 들어 사용자가 API Gateway로 요청을 보내면 Lambda가 실행되고, Lambda가 DynamoDB에 데이터를 저장한 뒤, CloudWatch Logs에 실행 로그를 남기는 구조를 만들 수 있다.

---

12. Lambda + API Gateway 기본 아키텍처

14주차 서버리스 실습의 핵심 구조는 Lambda + API Gateway이다.

기본 흐름은 다음과 같다.

사용자
→ API Gateway
→ Lambda 함수 실행
→ 응답 반환
→ CloudWatch Logs에 실행 기록 저장

이 구조에서는 EC2 서버를 직접 만들 필요가 없다. 사용자가 API Gateway의 URL로 요청을 보내면 API Gateway가 Lambda 함수를 호출하고, Lambda는 작성된 코드를 실행한 뒤 결과를 반환한다.

이 구조의 장점은 다음과 같다.

• 서버 생성 없이 API 제공 가능
• 요청이 있을 때만 Lambda 실행
• 트래픽 증가 시 자동 확장
• CloudWatch Logs로 실행 결과 확인 가능
• 작은 기능 단위로 빠르게 개발 가능
• 프론트엔드, 모바일 앱, 챗봇, 자동화 작업과 연결하기 쉬움

---

13. 서버리스 실습 과정: Lambda + API Gateway 데모

13.1 실습 목적

이번 실습의 목적은 AWS Lambda와 API Gateway를 활용하여 간단한 서버리스 API를 구성하는 것이다. 이를 통해 EC2 인스턴스를 생성하지 않고도 HTTP 요청을 처리하는 백엔드 기능을 만들 수 있음을 확인한다.

실습 목표는 다음과 같다.

• Lambda 함수 생성
• 간단한 응답 코드 작성
• API Gateway 생성
• API Gateway와 Lambda 연결
• API URL 호출 테스트
• CloudWatch Logs에서 실행 결과 확인
• 실습 후 리소스 정리

---

13.2 실습 구성

항목설정 예시

컴퓨팅	AWS Lambda
API 엔드포인트	Amazon API Gateway
런타임	Python 또는 Node.js
로그	Amazon CloudWatch Logs
인증	실습에서는 공개 테스트, 운영 환경에서는 인증 필요
응답 형식	JSON

 

---

13.3 실습 단계 1: Lambda 함수 생성

AWS Management Console에서 Lambda 서비스로 이동한 뒤, 새 함수를 생성한다.

설정 예시는 다음과 같다.

항목설정

함수 이름	hello-serverless-function
런타임	Python 3.x 또는 Node.js
아키텍처	x86_64
실행 역할	기본 Lambda 실행 역할 생성
권한	CloudWatch Logs 기록 권한 포함

Lambda

생성

 

---

13.4 실습 단계 2: Lambda 코드 작성

Lambda 함수 코드에 간단한 응답을 반환하는 코드를 작성한다.

Python 예시는 다음과 같다.

import json

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps({
            "message": "Hello, Serverless!",
            "source": "AWS Lambda"
        })
    }

이 코드는 API Gateway를 통해 요청이 들어왔을 때 JSON 형태의 응답을 반환한다.

---

13.5 실습 단계 3: Lambda 테스트

Lambda 콘솔에서 Test 이벤트를 생성하여 함수가 정상적으로 실행되는지 확인한다.

테스트 이벤트는 기본 템플릿을 사용하거나 간단한 JSON을 입력할 수 있다.

예시 테스트 이벤트는 다음과 같다.

{
  "test": "hello"
}

테스트 실행 후 statusCode: 200과 Hello, Serverless! 메시지가 반환되면 Lambda 함수가 정상적으로 동작하는 것이다.

---

13.6 실습 단계 4: API Gateway 생성

다음으로 API Gateway 서비스를 열고 HTTP API 또는 REST API를 생성한다.

실습에서는 단순한 구조를 위해 HTTP API를 기준으로 구성할 수 있다.

설정 예시는 다음과 같다.

항목설정

API 유형	HTTP API
Integration	Lambda
Lambda 함수	hello-serverless-function
Method	GET
Route	/hello
Stage	$default 또는 dev

API 생성

 

---

13.7 실습 단계 5: API Gateway와 Lambda 연결

API Gateway의 Integration 설정에서 앞서 만든 Lambda 함수를 연결한다. 연결 후 API Gateway가 Lambda를 호출할 수 있도록 권한이 자동으로 추가되는지 확인한다.

정상적으로 연결되면 API Gateway의 Invoke URL을 통해 Lambda 함수를 호출할 수 있다.

---

13.8 실습 단계 6: API URL 호출 테스트

API Gateway에서 제공하는 Invoke URL에 /hello 경로를 붙여 브라우저 또는 CloudShell에서 호출한다.

예시는 다음과 같다.

https://example-api-id.execute-api.ap-northeast-2.amazonaws.com/hello

CloudShell에서는 다음과 같이 테스트할 수 있다.

curl https://example-api-id.execute-api.ap-northeast-2.amazonaws.com/hello

정상적으로 설정되었다면 다음과 유사한 JSON 응답을 확인할 수 있다.

{
  "message": "Hello, Serverless!",
  "source": "AWS Lambda"
}

---

13.9 실습 단계 7: CloudWatch Logs 확인

Lambda 함수가 실행되면 CloudWatch Logs에 실행 로그가 저장된다. CloudWatch Logs에서 해당 Lambda 함수의 로그 그룹을 찾아 실행 시간, 요청 ID, 오류 메시지 등을 확인할 수 있다.

CloudWatch Logs를 확인하는 이유는 다음과 같다.

• 함수가 실제로 호출되었는지 확인
• 오류 발생 시 원인 분석
• 실행 시간과 메모리 사용량 확인
• API Gateway 요청과 Lambda 실행 흐름 점검
• 운영 환경에서 장애 분석 자료로 활용

---

14. 서버리스 실습 중 문제점 및 해결 방안

14.1 문제점 1: API Gateway 호출 시 500 오류 발생

처음 API Gateway Invoke URL로 접속했을 때 500 Internal Server Error가 발생할 수 있다.

원인 분석

주요 원인은 Lambda 함수의 반환 형식이 API Gateway가 기대하는 형식과 맞지 않았기 때문이다. API Gateway와 연동된 Lambda는 일반적으로 statusCode, headers, body 구조를 가진 응답을 반환해야 한다.

해결 방안

Lambda 반환값을 다음과 같은 형식으로 수정했다.

return {
    "statusCode": 200,
    "headers": {
        "Content-Type": "application/json"
    },
    "body": json.dumps({
        "message": "Hello, Serverless!"
    })
}

수정 후 Lambda를 다시 Deploy하고 API Gateway URL을 호출하니 정상적으로 JSON 응답이 반환되었다.

---

14.2 문제점 2: API Gateway와 Lambda 연결 권한 문제

API Gateway를 생성했지만 Lambda가 호출되지 않는 문제가 발생할 수 있다.

원인 분석

API Gateway가 Lambda 함수를 호출하려면 Lambda 함수에 API Gateway 호출 권한이 부여되어야 한다. 콘솔에서 자동으로 설정되는 경우가 많지만, 수동 설정이나 리소스 재생성 과정에서 권한이 누락될 수 있다.

해결 방안

Lambda 함수의 Configuration 또는 Trigger 메뉴에서 API Gateway가 연결되어 있는지 확인했다. 연결되어 있지 않다면 API Gateway의 Integration을 다시 설정하거나 Lambda Trigger를 추가하여 API Gateway가 Lambda를 호출할 수 있도록 수정했다.

---

14.3 문제점 3: CloudWatch Logs가 바로 보이지 않음

Lambda를 실행했는데 CloudWatch Logs에서 로그가 바로 보이지 않을 수 있다.

원인 분석

Lambda 함수가 실제로 호출되지 않았거나, Lambda 실행 역할에 CloudWatch Logs 기록 권한이 부족할 수 있다. 또는 로그 반영에 약간의 시간이 걸릴 수 있다.

해결 방안

먼저 Lambda 콘솔에서 직접 Test를 실행하여 함수가 호출되는지 확인했다. 이후 IAM Role에 CloudWatch Logs 관련 권한이 포함되어 있는지 확인했다. 마지막으로 CloudWatch Logs에서 /aws/lambda/함수이름 형식의 로그 그룹을 검색했다.

---

14.4 문제점 4: 실습 후 리소스 정리 누락

서버리스는 요청이 없으면 비용이 거의 발생하지 않는 구조이지만, API Gateway, CloudWatch Logs, DynamoDB, S3 같은 연결 리소스는 설정에 따라 비용이 발생할 수 있다.

해결 방안

실습 후 다음 리소스를 확인하고 정리했다.

 

리소스정리 방법

Lambda 함수	더 이상 사용하지 않으면 삭제
API Gateway	API 삭제
CloudWatch Logs	불필요한 로그 그룹 삭제 또는 보존 기간 설정
DynamoDB	실습용 테이블 삭제
S3	실습용 버킷과 객체 삭제
IAM Role	실습용 역할 삭제
EventBridge Rule	테스트용 규칙 삭제

 

---

15. 서버리스 아키텍처 확장 예시

Lambda + API Gateway 구조는 간단한 API부터 이벤트 기반 서비스까지 다양하게 확장할 수 있다.

15.1 문의 접수 API

사용자
→ API Gateway
→ Lambda
→ DynamoDB 저장
→ SNS 이메일 알림

이 구조는 사용자가 문의 내용을 제출하면 Lambda가 요청을 처리하고 DynamoDB에 저장한 뒤, SNS로 관리자에게 알림을 보내는 방식이다.

15.2 이미지 업로드 처리

사용자
→ S3 이미지 업로드
→ S3 이벤트 발생
→ Lambda 실행
→ 이미지 리사이징
→ 결과 이미지 S3 저장

이 구조는 사용자가 이미지를 업로드하면 Lambda가 자동으로 실행되어 썸네일을 생성하는 방식이다.

15.3 정기 자동화 작업

EventBridge Schedule
→ Lambda
→ S3 / DynamoDB / 외부 API 처리
→ CloudWatch Logs 기록

이 구조는 매일 정해진 시간에 Lambda를 실행하여 데이터를 수집하거나 리포트를 생성하는 데 사용할 수 있다.

---

16. 기존 학습 내용과의 연결

14주차 내용은 이번 학기 동안 학습한 AWS 서비스들을 전체적으로 연결한다.

기존 학습 내용14주차와의 연결

EC2	기존 서버 기반 구조와 서버리스 구조 비교
S3	정적 파일 저장, 이벤트 기반 Lambda 트리거
IAM	Lambda 실행 역할과 최소 권한 정책
API Gateway	서버리스 API 엔드포인트 제공
Lambda	서버 없이 코드 실행
DynamoDB	서버리스 데이터 저장소
CloudWatch	Lambda 실행 로그와 지표 확인
CloudTrail	API 호출 기록 추적
EventBridge	이벤트 기반 자동화
Auto Scaling	서버 기반 확장과 서버리스 자동 확장 비교
Cost Explorer	서버리스 사용량 기반 비용 분석

즉, 14주차는 단순히 새로운 서비스를 배우는 주차라기보다, 지금까지 학습한 클라우드 개념을 디지털 전환과 민첩한 서비스 개발 관점에서 종합하는 주차라고 볼 수 있다.

---

17. 14주차 학습 정리

이번 14주차 학습을 통해 디지털 전환은 단순한 기술 도입이 아니라, 비즈니스 모델과 운영 방식의 혁신이라는 점을 이해했다.

핵심 내용을 정리하면 다음과 같다.

 

핵심 개념정리

디지털 전환	디지털 기술로 비즈니스 프로세스, 문화, 고객 경험을 변화시키는 과정
Digitization	아날로그 정보를 디지털 데이터로 변환
Digitalization	기존 업무 프로세스를 디지털 도구로 개선
Digital Transformation	새로운 방식의 가치 창출과 비즈니스 모델 혁신
DX 구성 요소	기술, 조직, 문화
클라우드의 역할	유연성, 확장성, 속도, 비용 효율성 제공
서버리스	서버를 직접 관리하지 않고 코드와 이벤트 중심으로 실행하는 방식
Lambda	서버리스 함수 실행 서비스
API Gateway	HTTP API 엔드포인트 제공
DynamoDB	서버리스 NoSQL 데이터베이스
CloudWatch Logs	Lambda 실행 로그와 오류 분석
핵심 장점	빠른 개발, 자동 확장, 사용량 기반 과금

---

18. 학습 후기

 이번 14주차 학습을 통해 클라우드는 단순히 서버를 빌려 쓰는 기술이 아니라, 기업과 조직이 디지털 전환을 실현하기 위한 핵심 기반이라는 점을 이해했다.

 

 초반 주차에서는 EC2 인스턴스를 생성하고, S3 버킷을 만들고, VPC와 IAM을 설정하는 것처럼 개별 AWS 서비스를 중심으로 학습했다. 하지만 14주차에서는 이러한 서비스들이 실제 산업에서 어떻게 활용되는지 확인할 수 있었다. 금융 산업에서는 AI 기반 신용평가와 모바일 대출 심사에 활용되고, 제조 산업에서는 IoT 센서와 AI 분석을 통해 예측 유지보수와 품질 검사를 수행하며, 유통·물류 산업에서는 수요 예측과 재고 최적화에 활용된다. 의료 분야에서는 AI 영상 분석과 환자 데이터 통합에, 공공 부문에서는 스마트 시티와 전자민원 서비스에 클라우드가 사용될 수 있다.

 특히 인상 깊었던 부분은 디지털 전환이 단순 자동화와 다르다는 점이다. 종이 문서를 PDF로 바꾸는 것은 Digitization이고, 전자결재나 ERP 도입은 Digitalization에 가깝다. 하지만 진정한 Digital Transformation은 데이터를 기반으로 새로운 서비스를 만들고, 고객 경험과 비즈니스 모델 자체를 변화시키는 것이다.

서버리스 아키텍처도 중요한 개념이었다. 기존에는 웹 서비스를 만들기 위해 EC2 인스턴스를 생성하고, 운영체제를 관리하고, 보안 그룹과 스케일링을 직접 구성해야 했다. 반면 Lambda와 API Gateway를 사용하면 서버를 직접 관리하지 않고도 간단한 API를 만들 수 있다. 요청이 들어올 때만 함수가 실행되고, 트래픽이 증가하면 자동으로 확장되므로 빠른 실험과 서비스 개발에 적합하다고 느꼈다.

 

 실습 과정에서는 Lambda 함수의 응답 형식이 잘못되면 API Gateway에서 오류가 발생할 수 있다는 점, API Gateway가 Lambda를 호출하려면 연결 권한이 필요하다는 점, CloudWatch Logs를 통해 실행 결과와 오류를 확인해야 한다는 점을 배웠다. 이를 통해 서버리스는 서버 운영 부담을 줄여주지만, IAM 역할, API 연결, 로그 확인, 리소스 정리 같은 기본 운영 개념은 여전히 중요하다는 점을 알게 되었다.

 

 이번 학기 마지막 주차를 정리하면서, 클라우드 활용 수업에서 배운 내용이 하나의 흐름으로 연결된다는 것을 느꼈다. EC2와 S3는 기본 인프라와 스토리지, VPC와 IAM은 네트워크와 보안, CloudWatch와 CloudTrail은 운영과 감사, ELB와 Auto Scaling은 고가용성, WAF와 GuardDuty는 보안 대응, Lambda와 API Gateway는 민첩한 서비스 개발을 담당한다. 앞으로 AWS를 활용할 때는 단순히 서비스를 개별적으로 사용하는 것이 아니라, 목적에 맞는 아키텍처를 설계하고 운영·보안·비용·확장성을 함께 고려하는 방향으로 접근하고자 한다.