[Kt 에이블스쿨 9기 기자단] DX컨설턴트 9주차 후기

안녕하세요. KT 에이블스쿨 9기 기자단입니다.
오늘은 9주차 후기를 작성해보겠습니다.
 
참고로  aws와 network api,db용어에 대해 보고싶다면
제가 이전 블로그 2개에 공부하기 좋게 자세히 정리해놨습니다.
참고해주시면 좋을것 같습니다!
아래는 해당 블로그 링크입니다.
https://notion16641.tistory.com/11
https://notion16641.tistory.com/12
 
9주차에는 화요일부터 금요일까지 5차 미니프로젝트가 진행되었습니다.
이번 프로젝트의 큰 주제는 클라우드였습니다.
화요일과 수요일에는 고가용 인프라 구축 및 인프라 구성도 작성을 주제로 진행되었고,
목요일과 금요일에는 CRUD API 구현 및 서비스 인터페이스 작성을 주제로 진행되었습니다.
 
두 프로젝트 모두 이론 학습 후 실습을 진행하는 방식으로 진행되었습니다.
확실히 이론만 배울 때보다 직접 실습해보니
전체적인 구조와 흐름을 더 쉽게 이해할 수 있었습니다.
특히 NAT Gateway와 같은 AWS 서비스는 실제 환경에서는 비용이 발생하지만,
KT 에이블스쿨에서 제공한 계정을 통해 실습할 수 있어
비용 부담 없이 다양한 기능을 경험할 수 있었습니다.
 
비대면으로 진행되다 보니 학생마다 서로 다른 오류가 발생하기도 했습니다.
저 역시 여러 에러를 겪으며 어려움을 겪었는데,
강사님께서 실시간으로 학생들과 소통하며
직접 계정에 원격 접속해 문제를 해결할 수 있도록 도와주셨습니다.
또한 교육생들의 질문에도 친절하게 답변해 주셔서,
저같이 클라우드를 처음 접하는 사람도
큰 어려움 없이 수업을 따라갈 수 있었습니다.
 
실습이 끝난 후에는 조별 과제를 진행했습니다.
이번 미니프로젝트는 팀별로 차별화된 아이디어를 고민하기보다는
주어진 과제를 정확하게 수행하는 것이 중요했기 때문에
비교적 수월하게 진행할 수 있었습니다.
또한 전체 미팅에서는 다섯 팀만 발표를 진행했는데,
발표 시간이 10분으로 넉넉하게 주어졌던 점도 인상적이었습니다.
이전 미니프로젝트에서는 발표 시간이 5분이어서
준비한 내용을 충분히 설명하기 어려웠는데,
이번에는 각 팀이 프로젝트를 진행한 과정과 결과를
자세히 들을 수 있어 많은 도움이 되었습니다.
 
아래는 이번주를 진행하며 배운 내용에 대해 제가 정리한 내용 입니다.

1. EC2 가상 컴퓨팅 인스턴스 핵심

1.1 범용 버스터블(Burstable) 인스턴스의 이해

AWS의 t 패밀리(t2, t3, t4g 등) 인스턴스는 기본적인 워크로드를 저렴하게 처리하면서, 필요 시 성능을 폭발적으로 높일 수 있는 대표적인 범용 인스턴스 요금제입니다.

CPU 크레딧 시스템: 평상시(기본 임계치 이하)에는 CPU 크레딧을 지속적으로 축적합니다.

버스트(Burst) 메커니즘: 트래픽 급증이나 연산 집중 작업이 발생하면 모아둔 크레딧을 소모하여 베이스라인을 뛰어넘는 고성능 연산을 수행합니다.

성능 제약 조건: 크레딧이 모두 고갈되면 인스턴스의 연산 성능이 기본 베이스라인 수준으로 강제 제한되므로 지속적인 고성능이 필요한 서버에는 부적합합니다.

1.2 구매 옵션별 최적 워크로드 배치

비즈니스 연속성과 비용 효율성을 동시에 달성하기 위해서는 적절한 인스턴스 구매 옵션 선정이 필수적입니다.

스팟(Spot) 인스턴스: AWS의 잉여 자원을 최대 90% 저렴한 비용으로 이용할 수 있는 옵션입니다.

자원 회수 리스크: AWS 내부 자원 수요가 증가하면 2분 전 유예 알림(Notice)을 보낸 후 인스턴스를 강제로 회수(종료)합니다.

주의 사항: 강제 종료 시 심각한 비즈니스 장애로 이어지는 프로덕션 환경의 '결제 및 주문 처리 웹 서버' 등에는 절대로 배치해서는 안 됩니다.

권장 워크로드: 중간에 작업이 중단되어도 무방하거나 처음부터 다시 실행하면 되는 배치(Batch) 분석 작업, 가벼운 테스트 환경, CI/CD 빌드 워커에 최적입니다.

1.3 EC2 인스턴스 초기화 및 라이프사이클

EC2 가상 서버를 가동할 때 환경 설정을 자동화하기 위해 초기화 가이드라인을 준수해야 합니다.

EC2 서비스 개념: 인스턴스의 정식 명칭은 'Elastic Compute Cloud'이며, 클라우드 환경에서 유연하고 확장 가능한 컴퓨팅 파워를 제공합니다.

User Data 스크립트 실행 시점: 인스턴스가 최초로 생성되어 처음 부팅되는 시점에 딱 1회만 시스템 최고 권한(root)으로 자동 실행되는 쉘 스크립트입니다.

재실행 메커니즘: 일반적인 운영체제 설정 변경 없이는 가상 서버를 단순히 재부팅(Reboot)하거나 중지 후 시작(Stop & Start)하더라도 스크립트가 재실행되지 않습니다.

2. 블록 스토리지 및 데이터 고가용성 설계

2.1 EBS (Elastic Block Store) vs Instance Store

가상 서버에 연결하는 스토리지는 데이터 영속성과 입출력(I/O) 성능 요구치에 따라 이원화하여 설계합니다.

특성 구분	EBS (Elastic Block Store)	Instance Store
데이터 영속성	영구 저장 (인스턴스 중지 및 장애 시에도 유지)	휘발성/임시 저장 (인스턴스 중지 시 데이터 즉시 물리적 삭제)
물리적 위치	네트워크로 연결된 독립 스토리지 볼륨	EC2 인스턴스가 탑재된 물리 호스트 서버의 내장 디스크
주요 용도	OS 부팅 볼륨, RDBMS 데이터 파일 등 영구 보존용	임시 버퍼, 캐시 디렉터리, 스왑 영역 등 고속 가공용

2.2 고가용성 아키텍처와 단일 장애점(SPOF) 극복

멀티 가용 영역(Multi-AZ)을 활용하여 인프라를 구성하더라도, 컴포넌트 배치 실수 하나로 인해 전체 시스템이 마비되는 구조적 결함이 발생할 수 있습니다.

내장 고가용성 컴포넌트: ALB와 ASG는 AWS 내장 인프라가 자체적으로 고가용성을 분산 관리해 주어 SPOF 리스크가 매우 낮습니다.

NAT Gateway의 한계: Private 서브넷의 아웃바운드 인터넷 통신을 중재하는 NAT Gateway는 기본적으로 '특정 가용 영역(AZ)'에 종속되는 리소스입니다.

SPOF 시나리오: 모든 가용 영역의 Private 서버들이 오직 1개의 가용 영역에 배치된 NAT Gateway만을 공유할 경우, 해당 가용 영역에 장애가 나면 아웃바운드 통신이 완벽하게 마비되는 단일 장애점(SPOF)이 됩니다.

올바른 해결 아키텍처: 진정한 고가용성을 위해서는 서비스가 배포되는 물리적 가용 영역(AZ)마다 NAT Gateway를 각각 독립적으로 배치해야 합니다.

3. 트래픽 제어 및 리소스 거버넌스

3.1 로드 밸런서(ALB) 배치 및 고급 라우팅

Application Load Balancer(ALB)는 들어오는 모든 클라이언트 요청의 최전방 관문 인터페이스 역할을 수행합니다.

Internet-facing ALB 위치: 외부 퍼블릭 인터넷 사용자들의 트래픽을 직접 수신해야 하므로 외부 인터넷 라우팅이 열려 있는 Public Subnet에 반드시 전면 배치되어야 합니다.

Cross-Zone Load Balancing: 가용 영역(AZ) 간에 인스턴스 숫자가 불균형하게 배치되어 있는 상황(예: AZ-a에 8대, AZ-c에 2대)에서 강력한 진가를 발휘하는 기술입니다.

트래픽 균등 제어 메커니즘: 해당 기능이 비활성화되면 단순 AZ 단위로 50:50 분산하여 소수 인스턴스에 과부하가 걸리나, 기능을 활성화하면 AZ 경계를 넘어 전체 인스턴스 풀에 균등한 트래픽(예: 대당 10%)을 보장합니다.

3.2 로드 밸런서 상태 검사(Health Check)

로드 밸런서는 살아있는 서버로만 안전하게 사용자를 안내하기 위해 실시간 상태를 정교하게 모니터링합니다.

임계값(Threshold)의 정의: 특정 서버의 상태가 정상(Healthy) 혹은 비정상(Unhealthy)으로 확정 변경되었다고 선언하기 위한 '연속된 성공/실패 횟수'를 정의합니다.

Unhealthy Threshold = 3의 실무적 의미: 타겟 인스턴스가 로드 밸런서의 상태 확인 신호에 대해 '연속으로 총 3회' 응답 실패 및 에러를 내면 즉시 Unhealthy 상태로 판정하고 트래픽 유입 라우팅 대상에서 제외시킵니다.

3.3 리소스 삭제 및 의존성(Dependency) 관리 규칙

인프라 테스트 환경을 정리하고 자원을 안전하게 철거하기 위해서는 인프라 락(Lock) 구조와 의존 관계를 반드시 준수해야 합니다.

인프라 의존성 규칙: AWS 클라우드 자원은 상호 결합 및 종속되어 있으므로 철거 작업은 반드시 '생성 순서의 완벽한 역순'으로 진행해야 결함이 없습니다.

최우선 삭제 대상 (ASG): 하위에 가상 인스턴스 자원을 움켜쥐고 있는 ASG(Auto Scaling Group)를 가장 먼저 파괴(Delete)해야 내부의 EC2 인스턴스들이 차례대로 안전하게 종료(Terminate) 처리됩니다.

삭제 락(Lock) 방지: 내부 인스턴스가 살아있는 상태에서 기반 네트워크망인 VPC나 보안 그룹(Security Group)을 강제 삭제하려 시도하면, '리소스가 사용 중'이라는 예외 경고와 함께 삭제 연산이 거부됩니다.

안전한 자원 철거 프로세스 순서 1단계: ASG (Auto Scaling Group) 삭제 처리로 인스턴스 자동 종료 유도
2단계: 외부 진입점인 ALB (Application Load Balancer) 철거
3단계: 인프라 방화벽 정책인 보안 그룹(Security Group) 정리
4단계: 최상위 가상 네트워크망인 VPC 최종 삭제

1. HTTP 프로토콜 및 API 메서드 설계

1.1 HTTP 409 Conflict 상태 코드

HTTP 409 코드는 서버의 현재 상태와 요청이 충돌(Conflict)할 때 발생하는 클라이언트 에러(4xx) 코드입니다. 시스템의 무결성을 지키기 위해 비즈니스 로직 상 허용되지 않는 상태 변경 요청에 주로 응답합니다.

대표적인 발생 상황: 서버 내 특정 데이터가 유일성(Unique) 제약 조건을 가질 때, 중복 가입이나 중복 데이터를 전송하는 경우 발생합니다.

동시 수정 제어: 리소스의 동시성 제어 이슈로 인해 두 요청이 같은 자원을 동시에 수정하려고 할 때 발생합니다.

멱등성 미보장 행위 제어: 이미 탈퇴 처리된 계정에 반복적으로 탈퇴 요청을 보내는 등, 비즈니스 규칙에 부합하지 않는 중복 행위를 차단할 때 쓰입니다.

유관 HTTP 상태 코드 가이드 400 Bad Request: 요청 구문 자체가 잘못되었을 때 사용
401 Unauthorized: 인증이 필요하거나 실패했을 때 (예: JWT 만료/누락)
403 Forbidden: 인증은 되었으나 해당 리소스에 대한 접근 권한이 없을 때
404 Not Found: 요청한 리소스가 존재하지 않을 때

1.2 REST API URI 네이밍 및 컬렉션 설계 규칙

RESTful API 설계 사상에서 URI는 자원(Resource) 자체를 명확히 표현해야 하며, 행위(Method)는 완전히 배제되어야 합니다.

자원은 명사로 표현: URI 구조에는 명사만 사용해야 하며, '행위'를 뜻하는 동사(get, list, delete 등)는 HTTP Method로 대체해야 합니다.

단수형이 아닌 복수형 사용: 단일 자원(Element)이 아닌 복수형 명사(Plural)를 컬렉션 표현으로 사용하는 것이 글로벌 업계 표준 사상입니다.

소문자 및 하이픈 케이스 지향: URI 가독성을 높이기 위해 언더바(_) 대신 하이픈(-)을 사용하며, 모든 글자는 소문자로 작성하는 것을 원칙으로 합니다.

사용자 목록 조회 설계 비교 안 좋은 예시 (Anti-Pattern): GET /api/getUsers, GET /api/user/list
올바른 예시 (Best Practice): GET /api/users

1.3 리소스 수정: PUT과 PATCH의 명확한 차이점

데이터를 수정할 때 흔히 혼동하는 두 HTTP 메서드는 '자원의 교체 범위' 측면에서 완벽히 다른 명세를 지닙니다.

PUT Method: 자원의 '전체 교체(Replace)'를 의미합니다. 클라이언트가 보내지 않은 필드는 기본값 혹은 null로 초기화될 위험이 있으므로 완전한 데이터 셋을 전송해야 합니다. (멱등성 보장)

PATCH Method: 자원의 '부분 수정(Partial Update)'을 뜻합니다. 오직 변경하려는 특정 필드(예: status 등)만 전송하여 기존 데이터를 유지한 채 부분적으로 업데이트를 수행합니다. (비멱등성 가능성)

2. 데이터베이스 아키텍처 및 관리 패턴

2.1 SQLite vs PostgreSQL 핵심 비교

프로젝트 스케일과 구동 인프라 환경에 맞춰 올바른 RDBMS 아키텍처 모델을 선택해야 합니다.

비교 항목	SQLite	PostgreSQL
아키텍처 유형	서버리스 파일 기반 DB (임베디드 엔진)	클라이언트-서버 구조 분리 네트워크 기반 DB
동시성 및 트랜잭션	단일 파일 잠금(Lock) 메커니즘, 다중 쓰기 성능 제한	MVCC(다중 버전 동시성 제어) 지원, 대규모 동시 트랜잭션 최적화
주요 활용 분야	모바일 앱 로컬 저장소, 소규모 프로토타이핑, 테스트 환경	대형 복잡 웹 애플리케이션, 데이터 분석 및 엔터프라이즈 환경

2.2 Soft Delete(논리 삭제) 패턴의 이해

데이터베이스 설계 시 레코드를 실제로 날리는 Hard Delete 방식 대신, 비즈니스 연속성과 감사를 위해 Soft Delete 방식을 대단히 널리 활용합니다.

복구 용이성(Data Recovery): 실수로 유저가 데이터를 지웠을 때 상태 플래그(is_deleted = false)만 복원하면 즉시 원상복구가 가능합니다.

감사 이력 보존(Audit Trail): 과거의 이력 추적 및 법적 규제 준수를 위한 감사 로그(Audit Log)를 유지할 수 있어 보안 및 데이터 관리 측면에서 뛰어납니다.

참조 무결성 유지 보조: 조인(Join) 관계가 얽혀있는 상위 테이블 데이터를 강제로 지울 때 발생하는 외래키 참조 무결성 오류를 쉽게 우회할 수 있습니다.

단점 및 고려사항: 매 조회마다 삭제 플래그 조건을 인덱스 처리하여 체크해야 하므로 대용량 조회 성능이 미세하게 저하될 수 있으며 디스크 용량이 계속 늘어납니다.

3. 현대 백엔드 프레임워크 및 프랙티스

3.1 FastAPI와 자동화 문서 (Swagger UI)

FastAPI 프레임워크는 강력한 자동화 문서 생성 기능 덕분에 모던 백엔드 진영에서 각광받고 있습니다.

OpenAPI 표준 연동: 소스 코드 내 작성된 Pydantic 모델과 Type Hint 정보를 기반으로 애플리케이션 빌드 시 표준 OpenAPI 규격 사양서를 자동으로 구성합니다.

자동 생성 경로: 개발자가 별도 조치를 취하지 않아도 서버 구동 후 '/docs' 엔드포인트 접근 시 Swagger UI 웹 콘솔이 즉시 노출됩니다.

대화형 API 테스트: 웹 브라우저 상에서 정의된 파라미터 값들을 직접 채워 넣어 실제 API 호출 테스트(Try it out)를 수행할 수 있어 프론트엔드 개발자와의 협업 효율을 극한으로 끌어올립니다.

3.2 Pydantic 라이브러리의 핵심 역할

파이썬의 동적 타이핑 단점을 보완하고 엄격한 데이터 핸들링을 수행하는 데이터 유효성 검증 프레임워크입니다.

데이터 유효성 검증 (Validation): 외부 요청(Request Body/Query) 데이터가 서버 비즈니스 조직이 원하는 형태(int, string, datetime 등)를 만족하는지 검증하고 맞지 않으면 422 에러를 자동 반환합니다.

직렬화 및 역직렬화: 네트워크 레이어에서 교환되는 JSON 데이터 문자열을 내부 파이썬 객체로 역직렬화(Deserialization)하고, 반대로 DB 객체나 파이썬 딕셔너리를 웹에 반환할 JSON 형태로 직렬화(Serialization)해줍니다.

3.3 인터페이스 정의서(IDD)와 마이크로서비스(MSA) 설계

대규모 개발 프로젝트의 협업 및 시스템 아키텍처 분리를 관통하는 두 핵심 키워드입니다.

IDD (Interface Definition Document): 프론트엔드와 백엔드 개발 스쿼드 간 소통 비효율을 없애고 통합 테스트를 조기에 수행할 수 있도록 엔드포인트 명세를 맞춘 협업 약속 매뉴얼입니다.

MSA 분리의 표준 기준: 거대 단일 애플리케이션(Monolith)을 마이크로서비스 아키텍처(MSA)로 쪼갤 때, 기술 스택이나 인원수가 아닌 '비즈니스 도메인(Business Domain)' 단위로 서비스를 격리시켜야 독립적 배포와 낮은 결합도가 달성됩니다.

URL 기반 API 버전 관리: URL에 버전 경로를 삽입하는 방식(/api/v1/users)은 가시성이 뛰어나 게이트웨이단의 네트워크 라우팅 룰을 단순화하고 인프라 레벨의 CDN 캐싱 전략을 수월하게 적용할 수 있는 강력한 장점을 가집니다.

 
------------------------------------------------------------
5월엔 휴일이 많아서 짧게 느껴진 것 같습니다.
다음주부턴 본격적인 여름이 시작되는 6월인데요.
6월달도 힘내보겠습니다.
여기까지 읽어주셔서 감사합니다!