JH의 개발 기록

[20주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 89

Ejah — Sun, 31 May 2026 19:01:25 +0900

파이프라인 모니터링

[20주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 88

Ejah — Tue, 26 May 2026 23:53:36 +0900

클라우드 컴퓨팅과 마이크로서비스 아키텍처 완벽 이해

실무에서 가장 많이 사용되는 현대 백엔드 구조

최근 대부분의 IT 서비스는 “클라우드 기반”으로 운영된다. 우리가 매일 사용하는 넷플릭스, 유튜브, 카카오톡, 쿠팡, 배달앱, 은행 서비스까지 거의 모두 클라우드 환경 위에서 동작하고 있다. 특히 AI 서비스와 실시간 데이터 처리, 대규모 트래픽이 중요해지면서 클라우드 컴퓨팅과 마이크로서비스 아키텍처(MSA)는 이제 선택이 아닌 필수가 되었다.

이번 글에서는 다음 내용을 중심으로 클라우드 컴퓨팅의 핵심 개념과 마이크로서비스 아키텍처를 쉽게 정리해보겠다.

클라우드 컴퓨팅이란?
클라우드의 주요 특징
서비스 모델(IaaS / PaaS / SaaS)
클라우드 경제성과 확장성
마이크로서비스 아키텍처(MSA)
모놀리식 구조와의 차이점
실제 실무에서 사용하는 기술
클라우드 환경에서의 개발 흐름

1. 클라우드 컴퓨팅이란?

클라우드 컴퓨팅(Cloud Computing)은 인터넷을 통해 서버, 저장소, 데이터베이스, 네트워크, 소프트웨어 등의 IT 자원을 필요할 때 제공받아 사용하는 방식이다.

예전에는 회사가 직접 서버 컴퓨터를 구매하고 서버실을 운영해야 했다. 하지만 클라우드 환경에서는 AWS, Azure, GCP 같은 클라우드 제공 업체가 이미 구축해 둔 인프라를 인터넷으로 빌려 사용할 수 있다.

즉, 필요한 만큼만 서버를 사용하고 사용한 만큼 비용을 지불하는 구조다.

예를 들어 웹 서비스를 만든다고 가정해보자.

과거 방식:

직접 서버 구매
서버실 운영
네트워크 구성
유지보수 직접 진행

클라우드 방식:

AWS EC2 생성
몇 분 만에 서버 사용 가능
자동 확장 가능
유지보수 부담 감소

이러한 특징 덕분에 스타트업부터 대기업까지 대부분 클라우드 환경을 사용한다.

2. 클라우드 컴퓨팅의 주요 특징

2-1. 온디맨드 셀프 서비스(On-Demand Self Service)

사용자가 직접 필요한 자원을 즉시 생성하고 사용할 수 있다.

예를 들어 AWS에서 버튼 몇 번만 누르면:

서버 생성
데이터베이스 생성
스토리지 생성
CDN 연결

등이 가능하다.

관리자 승인 없이 바로 사용할 수 있다는 점이 핵심이다.

2-2. 광범위한 네트워크 접근(Broad Network Access)

인터넷만 연결되어 있다면 어디서든 접근 가능하다.

즉:

노트북
스마트폰
태블릿
회사 PC

모두 동일한 클라우드 서비스를 이용할 수 있다.

2-3. 자원 풀링(Resource Pooling)

클라우드 제공 업체는 거대한 데이터센터를 운영하며 여러 사용자가 자원을 공유한다.

이를 통해:

비용 절감
효율적인 자원 사용
높은 가용성

을 제공할 수 있다.

2-4. 빠른 탄력성(Rapid Elasticity)

트래픽 증가 시 자동으로 서버를 늘릴 수 있다.

예시:

평소 서버 2대 운영
이벤트 기간 서버 20대로 자동 확장
이벤트 종료 후 다시 축소

이를 오토스케일링(Auto Scaling)이라고 한다.

실제 대규모 서비스에서 매우 중요한 기능이다.

2-5. 측정 가능한 서비스(Measured Service)

사용량 기반 과금이 가능하다.

예:

CPU 사용량
저장 공간
네트워크 트래픽
API 요청 수

사용한 만큼만 비용을 낸다.

3. 클라우드 서비스 모델

클라우드는 제공 범위에 따라 크게 3가지로 나뉜다.

3-1. IaaS (Infrastructure as a Service)

가장 기본적인 인프라를 제공하는 형태다.

제공:

서버
네트워크
스토리지
가상머신

사용자는:

OS 설치
서버 설정
애플리케이션 배포

등을 직접 관리해야 한다.

대표 서비스:

AWS EC2
Google Compute Engine
Azure VM

장점:

자유도가 높음
세밀한 설정 가능

단점:

관리 부담 증가

3-2. PaaS (Platform as a Service)

개발 환경까지 제공하는 형태다.

사용자는 코드만 배포하면 된다.

대표 서비스:

Render
Heroku
Vercel
AWS Elastic Beanstalk

예를 들어 Node.js 서버를 Render에 배포하면:

서버 세팅
빌드 환경
HTTPS
배포 자동화

등을 플랫폼이 처리해준다.

실무에서도 빠른 배포를 위해 많이 사용한다.

3-3. SaaS (Software as a Service)

완성된 소프트웨어를 사용하는 방식이다.

대표 예시:

Gmail
Notion
Google Docs
Slack
Figma

사용자는 설치 없이 바로 사용할 수 있다.

4. 클라우드의 경제성과 장점

4-1. 초기 비용 절감

서버 구매 비용이 필요 없다.

스타트업 입장에서:

초기 투자 감소
빠른 서비스 출시 가능

이라는 엄청난 장점이 있다.

4-2. 유지보수 감소

하드웨어 관리 부담이 줄어든다.

클라우드 업체가:

서버 관리
네트워크 관리
데이터센터 운영

등을 대신 처리한다.

4-3. 글로벌 서비스 가능

AWS 같은 서비스는 전 세계 리전을 제공한다.

예:

서울
도쿄
미국
유럽

등에 서버를 배포할 수 있다.

이를 통해 글로벌 서비스를 빠르게 구축할 수 있다.

4-4. 높은 가용성

장애 발생 시 자동 복구가 가능하다.

예:

서버 장애 발생
다른 서버로 자동 전환
서비스 중단 최소화

실무에서는 매우 중요한 요소다.

5. 클라우드와 가상화 기술

클라우드의 핵심 기술 중 하나는 가상화(Virtualization)이다.

하나의 물리 서버를 여러 개의 가상 서버처럼 나누어 사용하는 기술이다.

예를 들어:

하나의 물리 서버
여러 사용자가 독립적으로 사용

가능하게 된다.

최근에는 Docker 기반 컨테이너 기술도 매우 중요해졌다.

6. 컨테이너와 Docker

컨테이너는 애플리케이션 실행 환경을 패키징하는 기술이다.

Docker를 사용하면:

동일한 환경 유지
배포 간소화
실행 속도 향상

이 가능하다.

예시:

docker build .
docker run

개발 환경과 운영 환경이 동일해지는 것이 핵심 장점이다.

7. Kubernetes와 오케스트레이션

서비스 규모가 커지면 컨테이너 수가 많아진다.

이때 Kubernetes(K8s)가 사용된다.

역할:

컨테이너 자동 배포
자동 복구
오토스케일링
로드밸런싱

대규모 서비스 운영에서 사실상 표준 기술이다.

8. 마이크로서비스 아키텍처(MSA)란?

마이크로서비스 아키텍처는 서비스를 작은 단위로 분리하여 개발하는 구조다.

예를 들어 쇼핑몰 서비스가 있다면:

모놀리식 구조:

로그인
결제
주문
상품
알림

모든 기능이 하나의 프로젝트에 존재

MSA 구조:

인증 서비스
결제 서비스
주문 서비스
상품 서비스
채팅 서비스

각각 독립적으로 분리

9. 모놀리식 아키텍처와 비교

모놀리식 구조

장점:

초기 개발 쉬움
구조 단순
테스트 간단

단점:

규모가 커질수록 복잡
배포 부담 증가
일부 장애가 전체 영향

마이크로서비스 구조

장점:

독립 배포 가능
장애 격리
팀별 개발 가능
확장성 우수

단점:

운영 복잡성 증가
네트워크 통신 필요
모니터링 어려움

10. MSA에서 중요한 기술들

10-1. API Gateway

모든 요청의 진입점 역할을 한다.

기능:

인증
라우팅
로깅
트래픽 제어

대표:

Kong
Nginx
Spring Cloud Gateway

10-2. 서비스 디스커버리

서비스 위치를 자동으로 찾는 기술이다.

예:

주문 서비스가 결제 서비스 주소 탐색

대표:

Eureka
Consul

10-3. 메시지 큐

서비스 간 비동기 통신에 사용된다.

대표:

Kafka
RabbitMQ
Redis Pub/Sub

실시간 처리 시스템에서 매우 중요하다.

11. 클라우드 환경에서의 데이터베이스

클라우드에서는 관리형 DB를 자주 사용한다.

대표:

AWS RDS
Cloud SQL
MongoDB Atlas

장점:

백업 자동화
장애 복구
성능 관리

직접 DB 서버를 관리하지 않아도 된다.

12. Redis와 캐싱

실무에서 성능 최적화를 위해 Redis를 자주 사용한다.

Redis는 메모리 기반 데이터 저장소다.

사용 예:

로그인 세션
실시간 랭킹
캐싱
채팅

예를 들어:

DB 조회 속도 500ms
Redis 조회 속도 5ms

처럼 큰 차이가 발생할 수 있다.

대규모 서비스에서는 필수에 가깝다.

13. CDN(Content Delivery Network)

이미지나 정적 파일을 빠르게 제공하기 위한 기술이다.

대표:

CloudFront
Cloudflare

사용자와 가까운 서버에서 데이터를 전달한다.

예:

한국 사용자는 서울 서버
미국 사용자는 미국 서버

에서 데이터를 받는다.

14. DevOps와 CI/CD

현대 클라우드 환경에서는 자동화가 매우 중요하다.

CI/CD는:

자동 테스트
자동 빌드
자동 배포

를 의미한다.

대표 도구:

GitHub Actions
Jenkins
GitLab CI

예시 흐름:

Git Push
→ 테스트 실행
→ 빌드
→ Docker 생성
→ 서버 배포

사람 개입 없이 자동으로 배포된다.

15. 실무에서 많이 사용하는 클라우드 기술 스택

실제 프로젝트 예시:

Frontend:

React
Next.js
Vercel

Backend:

Node.js
NestJS
Express

Database:

PostgreSQL
MySQL

Cache:

Redis

Infra:

Docker
Kubernetes
AWS

Monitoring:

Grafana
Prometheus

이러한 구조가 현재 매우 흔하게 사용된다.

16. 클라우드 시대의 개발자 역량

이제 개발자는 단순히 코딩만 잘해서는 부족하다.

필요한 역량:

서버 이해
네트워크 이해
Docker
Linux
배포 자동화
클라우드 이해

특히 백엔드 개발자라면 클라우드 지식은 거의 필수다.

17. 클라우드의 미래

앞으로 클라우드 시장은 계속 성장할 가능성이 매우 높다.

특히:

AI 서비스
빅데이터
IoT
실시간 스트리밍
메타버스

등이 성장하면서 클라우드 의존도는 더욱 커질 것이다.

또한 서버리스(Serverless) 기술도 빠르게 발전 중이다.

대표:

AWS Lambda
Cloud Functions

서버 관리 없이 함수 단위로 실행할 수 있다.

마무리

클라우드 컴퓨팅은 현대 IT 서비스의 핵심 인프라다. 과거처럼 직접 서버를 구매하고 관리하는 시대는 점점 줄어들고 있으며, 이제는 필요할 때 원하는 만큼 자원을 사용하는 방식이 일반화되고 있다.

또한 서비스 규모가 커질수록 마이크로서비스 아키텍처와 컨테이너 기술, Kubernetes 같은 오케스트레이션 기술의 중요성도 함께 커지고 있다.

특히 실무에서는:

Docker
Redis
CI/CD
AWS
Kubernetes

등의 기술이 매우 자주 사용된다.

개발을 공부하는 입장에서는 단순히 “클라우드가 서버를 빌리는 것” 정도로 이해하는 것이 아니라, 실제 서비스가 어떻게 배포되고 운영되는지까지 이해하는 것이 중요하다.

앞으로의 개발 환경은 더욱 자동화되고 분산화될 가능성이 높다. 따라서 클라우드와 MSA에 대한 이해는 현대 개발자에게 매우 중요한 경쟁력이 될 것이다.

[19주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 87

Ejah — Fri, 22 May 2026 20:24:28 +0900

컴퓨터 네트워크와 소프트웨어공학 학습 정리

OSI 7계층부터 코드 리뷰까지, 개발자가 반드시 알아야 할 핵심 개념

최근 컴퓨터 네트워크와 소프트웨어공학에 대한 학습을 진행하면서, 단순히 “인터넷이 연결된다”, “코드가 동작한다” 수준을 넘어 실제 서비스와 협업 개발에서 왜 이러한 개념들이 중요한지를 다시 느낄 수 있었다.

특히 이번 학습에서는 다음과 같은 주제를 중심으로 공부했다.

디지털 통신과 아날로그 통신
OSI 7계층 모델
IP 네트워크와 주소 체계
CIDR 및 서브넷 개념
TCP/IP 프로토콜
소프트웨어공학의 목적
폭포수 모델과 애자일
코드 리뷰와 클린 코드
코드 인스펙션

이번 글에서는 위 내용을 바탕으로, 개발자가 반드시 이해해야 할 핵심 개념들을 정리해보려고 한다.

1. 디지털 통신과 아날로그 통신

우리가 사용하는 인터넷, 스마트폰, 게임 서버, 스트리밍 서비스는 모두 디지털 통신 기반으로 동작한다.

과거에는 아날로그 통신이 중심이었다면, 현재는 대부분 디지털 방식이 사용된다.

디지털 통신의 대표적인 장점은 다음과 같다.

잡음에 강하다.
오류 검출 및 오류 정정이 가능하다.
암호화 적용이 쉽다.
데이터 저장 및 복원이 용이하다.
컴퓨터 시스템과 직접 연동하기 좋다.

특히 중요한 부분은 “오류 검출과 정정”이다.

예를 들어 네트워크 전송 중 데이터 일부가 손상되더라도, 디지털 통신에서는 이를 검출하거나 복구할 수 있다.
반면 아날로그 통신은 잡음이 섞이면 원본 품질 자체가 저하된다.

또한 오늘날 보안 기술의 핵심인 암호화 역시 디지털 데이터 기반이기 때문에 가능하다.

2. OSI 7계층 모델

네트워크를 공부하면 반드시 등장하는 개념이 바로 OSI 7계층 모델이다.

OSI(Open Systems Interconnection) 모델은 네트워크 통신 과정을 7개의 계층으로 나누어 설명한 구조이다.

OSI 7계층 구조

계층역할

7계층	응용 계층(Application)
6계층	표현 계층(Presentation)
5계층	세션 계층(Session)
4계층	전송 계층(Transport)
3계층	네트워크 계층(Network)
2계층	데이터 링크 계층(Data Link)
1계층	물리 계층(Physical)

물리 계층

실제 전기 신호나 케이블, 허브 같은 물리적인 연결을 담당한다.

예시:

랜선
광케이블
전기 신호

데이터 링크 계층

프레임 단위 전송을 담당한다.

대표 기능:

MAC 주소 사용
오류 검출
흐름 제어

대표 장비:

스위치

네트워크 계층

라우팅과 IP 주소를 담당한다.

대표 프로토콜:

IP
ICMP

대표 장비:

라우터

인터넷에서 “어디로 데이터를 보낼지” 결정하는 핵심 계층이다.

전송 계층

종단 간 통신의 신뢰성을 보장한다.

대표 프로토콜:

TCP는 신뢰성을 보장하고,
UDP는 속도를 우선시한다.

게임 서버나 실시간 스트리밍에서는 UDP가 많이 사용되며,
웹 서비스에서는 TCP 기반 HTTP 통신이 주로 사용된다.

3. 데이터 링크 계층과 라우팅의 차이

학습하면서 헷갈리기 쉬운 부분 중 하나가 데이터 링크 계층과 네트워크 계층의 역할 차이였다.

데이터 링크 계층:

프레임 단위 처리
MAC 주소 기반 통신
오류 검출
흐름 제어

네트워크 계층:

IP 주소 사용
라우팅
경로 선택

즉, 라우팅은 네트워크 계층의 역할이지 데이터 링크 계층의 역할이 아니다.

이 개념은 면접에서도 자주 등장한다.

4. IP 주소와 CIDR

인터넷에서 모든 장치는 IP 주소를 가진다.

예시:

168.0.1
0.0.1
16.0.1

IP 주소는 네트워크 상에서 장치를 식별하기 위한 주소 체계이다.

CIDR이란?

CIDR(Classless Inter-Domain Routing)은 IP 주소를 효율적으로 관리하기 위한 방식이다.

예시:

10.10.0.0/22

여기서 /22는 네트워크 비트 수를 의미한다.

서브넷 마스크로 변환하면:

255.255.252.0

이러한 방식 덕분에 IP 주소를 더 유연하게 관리할 수 있게 되었다.

클래스 기반 주소 체계

과거에는 다음과 같이 클래스 기반으로 주소를 나누었다.

클래스범위

A	1~126
B	128~191
C	192~223

예를 들어:

10.x.x.x

는 클래스 A에 해당한다.

하지만 현재는 CIDR 방식이 일반적으로 사용된다.

5. TCP와 UDP

네트워크에서 가장 중요한 프로토콜 중 하나는 TCP이다.

TCP 특징:

연결 지향(connection-oriented)
신뢰성 보장
순서 보장
흐름 제어
혼잡 제어

특히 TCP는 데이터를 보내기 전에 3-way handshake 과정을 수행한다.

3-way Handshake

연결 과정:

SYN
SYN + ACK
ACK

이 과정을 통해 클라이언트와 서버는 서로 연결 가능 여부를 확인한다.

웹 브라우저에서 사이트 접속 시에도 TCP 연결이 먼저 이루어진다.

UDP 특징

UDP는 TCP보다 단순하다.

특징:

비연결형
빠른 속도
신뢰성 보장 없음

대표 사용 예시:

게임
실시간 음성 채팅
스트리밍

실시간성이 중요한 경우 UDP가 유리하다.

6. 소프트웨어공학이란 무엇인가

소프트웨어공학은 단순히 “코딩”을 의미하지 않는다.

소프트웨어를 체계적이고 효율적으로 개발하기 위한 공학적 접근 방법이다.

핵심 목표:

생산성 향상
품질 향상
유지보수성 확보
비용 절감
일정 관리

즉, 좋은 소프트웨어를 안정적으로 개발하기 위한 모든 활동이 포함된다.

7. 소프트웨어 생명주기(SDLC)

소프트웨어는 다음과 같은 생명주기를 가진다.

요구사항 분석
설계
구현
테스트
배포
유지보수

이를 SDLC(Software Development Life Cycle)라고 한다.

실무에서는 개발보다 유지보수 비용이 훨씬 커지는 경우도 많다.

따라서 처음부터 유지보수를 고려한 설계가 중요하다.

8. 폭포수 모델

폭포수(Waterfall) 모델은 전통적인 개발 방법론이다.

단계를 순차적으로 진행한다.

대표 단계:

Requirements
Design
Implementation
Verification
Maintenance

각 단계가 끝난 뒤 다음 단계로 이동한다.

폭포수 모델 장점

문서화가 체계적
관리가 쉽다
대규모 프로젝트에 적합

단점

변화 대응이 어렵다
요구사항 변경 비용이 크다
피드백 반영이 느리다

9. 애자일(Agile)

최근 대부분의 IT 기업은 애자일 방식을 사용한다.

애자일 핵심:

빠른 피드백
반복 개발
협업 중심
변화 대응

대표 방법론:

Scrum
Kanban

애자일이 중요한 이유

현대 서비스는 요구사항이 매우 빠르게 변한다.

예:

사용자 피드백
시장 변화
비즈니스 전략 수정

이러한 환경에서는 폭포수보다 애자일이 훨씬 유리하다.

10. 코드 리뷰와 코드 인스펙션

좋은 개발 문화에서 코드 리뷰는 필수이다.

코드 리뷰 목적:

버그 발견
품질 향상
지식 공유
유지보수성 향상

중요한 점은 “사람을 공격하는 자리가 아니라는 것”이다.

리뷰 대상은 개발자가 아니라 코드이다.

코드 인스펙션

코드를 체계적으로 검토하는 공식적인 절차이다.

주요 역할:

Moderator
Author
Reviewer

효율적인 코드 인스펙션을 위해서는:

사전 코드 공유
충분한 검토 시간
명확한 목적
이 중요하다.

11. 클린 코드와 리팩토링

좋은 코드는 단순히 “동작하는 코드”가 아니다.

좋은 코드의 조건:

읽기 쉽다
유지보수하기 쉽다
의도가 명확하다
중복이 적다

리팩토링이 중요한 이유

프로젝트가 커질수록 코드 복잡도는 빠르게 증가한다.

리팩토링 없이 기능만 계속 추가하면:

버그 증가
개발 속도 감소
유지보수 난이도 상승
문제가 발생한다.

따라서 지속적인 리팩토링은 장기적으로 매우 중요하다.

12. 협업 개발에서 가장 중요한 것

이번 학습을 통해 느낀 가장 중요한 점은:

“개발은 혼자 하는 것이 아니다.”

라는 것이다.

네트워크 역시 계층 간 협력이 필요하고,
소프트웨어 개발 역시 팀 협업이 핵심이다.

좋은 개발자는 단순히 코드를 잘 짜는 사람이 아니라:

구조를 이해하고
협업을 잘하고
유지보수를 고려하며
지속적으로 개선하는 사람이다.

마무리

컴퓨터 네트워크와 소프트웨어공학은 단순 이론 과목이 아니다.

실제 개발 현장에서:

서버 통신
API 설계
실시간 게임
클라우드 인프라
협업 개발
코드 품질 관리

모든 곳에서 직접 연결된다.

특히:

OSI 7계층
TCP/IP
IP 주소 체계
소프트웨어 생명주기
애자일
코드 리뷰

이러한 개념들은 개발자의 기본 체력에 해당한다고 느꼈다.

앞으로도 단순히 “기능 구현”만이 아니라:

왜 이렇게 설계되는지
왜 이런 프로세스가 필요한지
왜 유지보수가 중요한지

를 계속 고민하면서 학습해야겠다고 느꼈다.

[19주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 86

Ejah — Thu, 21 May 2026 20:05:14 +0900

컴퓨터 구조부터 벡터 데이터베이스까지, 백엔드 개발자가 이해해야 하는 핵심 개념 정리

최근 학습한 내용을 정리하면서 컴퓨터 구조, 운영체제, 데이터베이스, ORM, 그리고 벡터 데이터베이스까지 전체 흐름을 다시 복습해보았다.
처음에는 각각 전혀 다른 분야처럼 느껴졌지만, 실제로는 모두 연결되어 있었다.

특히 백엔드 개발이나 서버 개발을 하다 보면:

왜 캐시가 필요한지
왜 프로세스와 스레드를 알아야 하는지
왜 데이터베이스 구조가 중요한지
왜 ORM이 편리하면서도 위험할 수 있는지
왜 최근 AI 서비스들이 벡터 DB를 사용하는지

이런 것들이 결국 하나의 흐름으로 이어진다는 걸 느끼게 된다.

이번 글에서는 학습한 내용을 바탕으로 컴퓨터 구조부터 운영체제, 데이터베이스, 벡터 데이터베이스까지 핵심 개념들을 정리해보려고 한다.

1. 컴퓨터 구조와 운영체제

컴퓨터는 어떻게 프로그램을 실행할까?

우리가 작성한 코드는 결국 CPU가 이해할 수 있는 명령어로 변환되어 실행된다.

예를 들어:

JavaScript
Python
Java
C

같은 언어는 사람이 읽기 쉽게 만든 고급 언어이다.

하지만 CPU는 오직 기계어만 이해할 수 있기 때문에, 프로그램은 반드시 번역 과정을 거쳐야 한다.

이때 등장하는 개념이:

컴파일러
인터프리터
이다.

2. 컴파일러와 인터프리터

컴파일러 방식

컴파일러는 프로그램 전체를 한 번에 번역한다.

대표적인 언어:

특징:

실행 속도가 빠르다
실행 전에 오류를 많이 검출 가능하다
최적화에 유리하다

하지만:

운영체제나 CPU 구조가 달라지면 다시 컴파일해야 한다

예를 들어:

Windows용 exe
Mac용 실행 파일
은 서로 다르다.

인터프리터 방식

인터프리터는 한 줄씩 읽으면서 실행한다.

대표적인 언어:

Python
JavaScript

특징:

플랫폼 독립성이 좋다
개발 속도가 빠르다
디버깅이 편하다

하지만:

실행 속도가 상대적으로 느리다

실제로 Python이 C보다 느린 이유도 여기에 있다.

3. RISC와 CISC

CPU 구조에서도 중요한 개념이 있다.

바로:

RISC
CISC

이다.

CISC

Complex Instruction Set Computer

특징:

명령어 종류가 많다
하나의 명령어가 복잡한 작업 수행 가능
대표적으로 x86 계열

장점:

코드 길이가 짧아질 수 있다

단점:

하드웨어 구조가 복잡하다

RISC

Reduced Instruction Set Computer

특징:

단순한 명령어 위주
Load / Store 구조 사용
ARM 계열에서 많이 사용

장점:

전력 효율이 좋다
파이프라이닝에 유리하다

최근 모바일 CPU 대부분은 ARM 기반이다.

애플 M 시리즈 칩 역시 ARM 기반 RISC 구조를 사용한다.

4. 운영체제의 역할

운영체제(OS)는 단순히 화면을 보여주는 프로그램이 아니다.

운영체제의 핵심 역할은:

CPU 관리
메모리 관리
프로세스 관리
입출력 관리

등 하드웨어 자원을 효율적으로 관리하는 것이다.

그리고 이 핵심 기능을 담당하는 부분이 바로 커널(kernel)이다.

5. 시스템 콜(System Call)

사용자 프로그램은 하드웨어에 직접 접근할 수 없다.

예를 들어:

파일 읽기
네트워크 통신
메모리 할당

같은 작업은 반드시 운영체제를 거쳐야 한다.

이때 사용하는 인터페이스가 시스템 콜이다.

흐름은 보통 다음과 같다.

사용자 프로그램
→ 라이브러리 함수
→ 시스템 콜
→ 커널
→ 하드웨어

즉 운영체제가 안전하게 자원을 관리하기 위해 중간에서 통제하는 구조라고 볼 수 있다.

6. 프로세스와 스레드

운영체제를 공부하면서 가장 중요하게 느낀 개념 중 하나가 프로세스와 스레드였다.

프로세스(Process)

실행 중인 프로그램 자체를 의미한다.

예:

크롬 브라우저 실행
VSCode 실행

각 프로세스는 독립된 메모리 공간을 가진다.

스레드(Thread)

프로세스 내부에서 실제 작업을 수행하는 흐름이다.

예를 들어:

게임 렌더링
네트워크 처리
사용자 입력 처리

를 각각 다른 스레드가 담당할 수 있다.

7. 동기화 문제

멀티스레드 환경에서는 여러 작업이 동시에 같은 자원에 접근할 수 있다.

대표적인 문제가:

Race Condition
이다.

예:

동시에 같은 변수 수정
동시에 같은 파일 접근

이런 문제를 해결하기 위해:

Mutex
Semaphore
Monitor

같은 동기화 기법을 사용한다.

운영체제는 이런 동기화 메커니즘도 제공한다.

8. 메모리 관리와 캐시

CPU는 매우 빠르지만 메모리는 상대적으로 느리다.

이 속도 차이를 줄이기 위해 캐시 메모리를 사용한다.

특징:

CPU 내부에 존재
자주 사용하는 데이터를 저장
접근 속도가 매우 빠름

하지만 캐시 용량은 매우 작기 때문에:

어떤 데이터를 넣을지
어떤 데이터를 제거할지

를 결정해야 한다.

흥미로운 점은, 이런 캐시 교체는 보통 운영체제가 아니라 하드웨어 레벨에서 처리된다는 것이다.

9. 데이터베이스와 관계형 모델

백엔드 개발에서 가장 중요한 영역 중 하나가 데이터베이스다.

특히 관계형 데이터베이스(RDBMS)는 여전히 가장 많이 사용된다.

대표적으로:

MySQL
PostgreSQL
Oracle

등이 있다.

관계형 데이터베이스의 기본 구조

테이블 구성 요소:

Row → 튜플(tuple)
Column → 속성(attribute)

그리고 테이블 자체를 릴레이션(relation)이라고 부른다.

10. 데이터 무결성

데이터베이스에서는 데이터가 잘못 저장되지 않도록 여러 제약 조건을 둔다.

대표적인 것이:

개체 무결성
참조 무결성

이다.

참조 무결성

외래키(Foreign Key)는 반드시 존재하는 데이터를 참조해야 한다.

예:

존재하지 않는 사용자 ID 참조 금지
삭제된 게시글 참조 금지

이런 규칙이 참조 무결성이다.

실무에서도 굉장히 중요하다.

11. 트랜잭션과 ACID

데이터베이스에서 가장 중요한 개념 중 하나는 트랜잭션이다.

트랜잭션은:
“모두 성공하거나 모두 실패해야 하는 작업 단위”
이다.

예:

계좌 이체
결제 처리
주문 생성

ACID 속성

트랜잭션은 다음 4가지 속성을 만족해야 한다.

Atomicity (원자성)

모두 성공 또는 모두 실패

Consistency (일관성)

데이터 상태 유지

Isolation (독립성)

동시 실행 간 간섭 방지

Durability (영구성)

커밋된 데이터는 유지

백엔드 개발에서 트랜잭션 처리는 정말 중요하다.

특히 동시성 문제가 있는 서비스에서는 더 중요하다.

12. ORM(Object Relational Mapper)

최근 대부분의 백엔드 프레임워크는 ORM을 적극적으로 사용한다.

예:

Prisma
TypeORM
Sequelize
Hibernate

ORM은 객체와 데이터베이스를 연결해주는 기술이다.

ORM의 장점

1) 생산성 향상

직접 SQL을 작성하지 않아도 된다.

예:

const users = await prisma.user.findMany();

처럼 객체 기반으로 개발 가능하다.

2) 유지보수성 향상

테이블 변경 시 코드 관리가 편하다.

3) DB 종속성 감소

MySQL → PostgreSQL 변경 시 상대적으로 유리하다.

ORM의 단점

하지만 ORM이 만능은 아니다.

문제점:

복잡한 쿼리 비효율 가능
N+1 문제
성능 튜닝 어려움

실무에서는 ORM + Raw SQL을 함께 사용하는 경우가 많다.

13. NoSQL과 벡터 데이터베이스

최근 AI 서비스가 많아지면서 벡터 데이터베이스(Vector DB)가 굉장히 중요해지고 있다.

14. 벡터 데이터베이스란?

텍스트나 이미지를 숫자 벡터로 변환하여 저장하고 유사도를 검색하는 데이터베이스이다.

예:

ChatGPT 검색
추천 시스템
이미지 유사 검색
문서 검색

등에서 사용된다.

15. 임베딩(Embedding)

비정형 데이터를 숫자로 변환하는 과정을 임베딩이라고 한다.

예:

문장
이미지
음성

→ 벡터 변환

이 벡터끼리 거리 계산을 수행한다.

16. ANN 알고리즘

벡터 검색에서는 완전 탐색이 매우 느리다.

그래서:

Approximate Nearest Neighbor

알고리즘을 사용한다.

특징:

정확도를 조금 희생
속도를 크게 향상

대표적인 라이브러리:

FAISS
HNSW
Annoy

17. 추천 시스템과 벡터 검색

벡터 DB는 추천 시스템에서도 자주 사용된다.

예:

유튜브 추천
넷플릭스 추천
쇼핑몰 상품 추천

“비슷한 사용자”
“비슷한 콘텐츠”
를 빠르게 찾을 수 있기 때문이다.

18. 결국 모든 것은 연결되어 있다

이번 내용을 공부하면서 느낀 점은:

컴퓨터 구조
→ 운영체제
→ 프로세스/메모리
→ 데이터베이스
→ 벡터 검색

이 모두 따로 존재하는 개념이 아니라는 점이었다.

예를 들어:

캐시는 CPU에도 존재하고 Redis에도 존재한다
동기화 문제는 OS에서도 발생하고 DB에서도 발생한다
메모리 관리 개념은 벡터 DB 성능에도 영향을 준다

결국 좋은 백엔드 개발자가 되기 위해서는 단순히 API만 만드는 것이 아니라 컴퓨터가 어떻게 동작하는지 전체 흐름을 이해하는 것이 중요하다는 걸 느끼게 되었다.

마무리

처음에는:

운영체제
데이터베이스
벡터 검색

이 모두 어려운 개념처럼 느껴졌지만, 하나씩 연결해서 이해하니 훨씬 재미있었다.

특히 최근 AI 시대에는:

벡터 데이터베이스
임베딩
유사도 검색

같은 개념이 점점 더 중요해지고 있다.

앞으로는 단순 CRUD를 넘어서:

검색
추천
AI 기반 서비스

까지 고려하는 개발자가 되는 것이 목표다.

[19주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 85

Ejah — Thu, 21 May 2026 20:00:28 +0900

소프트웨어 개발 프로세스

[19주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 84

Ejah — Mon, 18 May 2026 22:48:05 +0900

CI/CD 파이프라인과 스테이징 배포, 테스트 자동화까지 한 번에 이해하기

최근 대부분의 개발 프로젝트에서는 단순히 “기능을 만든다”에서 끝나지 않습니다.
기능을 안정적으로 배포하고, 오류를 빠르게 발견하며, 협업 과정에서 품질을 유지하는 것까지 모두 개발의 중요한 영역이 되었습니다.

특히 팀 프로젝트나 실무에서는 다음과 같은 질문들이 자주 등장합니다.

“왜 내 코드만 배포하면 오류가 날까?”
“배포 전에 테스트를 자동으로 돌릴 수 없을까?”
“운영 서버에 바로 올리기 전에 미리 검증할 방법은 없을까?”
“매번 수동으로 빌드하고 배포하는 게 너무 번거로운데?”

이런 문제를 해결하기 위해 등장한 개념이 바로 CI/CD 파이프라인, 테스트 자동화, 스테이징 배포, 그리고 인수 테스트입니다.

이번 글에서는 실제 개발 흐름을 기준으로 아래 내용을 하나씩 정리해보겠습니다.

CI/CD란 무엇인가
왜 자동화가 중요한가
빌드 및 패키징 과정
단위 테스트와 코드 커버리지
스테이징 배포
인수 테스트
실제 프로젝트 흐름 예시
협업 과정에서 얻을 수 있는 장점

CI/CD란 무엇일까?

CI/CD는 크게 두 가지 개념으로 나뉩니다.

CI (Continuous Integration)
CD (Continuous Delivery / Deployment)

쉽게 말하면:

“코드를 자주 합치고(CI), 자동으로 배포까지 연결(CD)하는 개발 문화와 시스템”

이라고 볼 수 있습니다.

Continuous Integration (CI)

CI는 지속적인 통합을 의미합니다.

여러 명의 개발자가 동시에 작업하다 보면 아래와 같은 문제가 발생합니다.

서로 다른 코드 충돌
기능 간 예기치 못한 버그
테스트 누락
환경 차이로 인한 실행 오류

예전에는 기능 개발이 끝난 뒤 한 번에 코드를 합쳤기 때문에 충돌이 매우 많았습니다.

하지만 CI 환경에서는:

개발자가 코드를 push
자동으로 테스트 실행
빌드 검사
문제 여부 확인

이 과정을 반복합니다.

즉:

“코드를 자주 합치고, 문제를 빠르게 발견한다”

가 핵심입니다.

Continuous Delivery / Deployment (CD)

CD는 자동 배포 개념입니다.

CI가 “문제가 없는 코드인지 검증”하는 단계라면,

CD는:

서버 배포
Docker 이미지 생성
클라우드 반영
서비스 업데이트

까지 자동화합니다.

여기서 CD는 두 가지로 나뉩니다.

Continuous Delivery

배포 가능한 상태까지 자동 준비

→ 실제 운영 배포는 사람이 버튼 클릭

Continuous Deployment

운영 서버까지 완전 자동 배포

→ 테스트 통과 시 즉시 반영

왜 CI/CD가 중요할까?

개발을 하다 보면 아래 문제가 정말 자주 발생합니다.

1. “내 컴퓨터에서는 잘 되는데요?”

가장 유명한 문제입니다.

로컬에서는 잘 동작하지만:

Node 버전 차이
환경 변수 문제
OS 차이
패키지 버전 문제

등으로 서버에서는 오류가 발생합니다.

CI 환경에서는 항상 동일한 환경에서 검증하기 때문에 이런 문제를 줄일 수 있습니다.

2. 테스트 누락 방지

수동 테스트는 반드시 놓치는 부분이 생깁니다.

특히 프로젝트 규모가 커질수록:

로그인
회원가입
API 응답
권한 처리
예외 처리

등을 전부 사람이 확인하기 어렵습니다.

CI에서는 코드가 올라갈 때마다 자동으로 테스트를 수행합니다.

3. 배포 속도 향상

수동 배포 과정은 생각보다 시간이 오래 걸립니다.

예를 들어:

코드 pull
의존성 설치
빌드
서버 실행
로그 확인

이 과정을 매번 사람이 수행하면 실수 가능성이 커집니다.

CI/CD 환경에서는 이 모든 작업이 자동으로 수행됩니다.

CI/CD 파이프라인 설계

CI/CD 파이프라인은 보통 아래 흐름으로 구성됩니다.

코드 Push
   ↓
Lint 검사
   ↓
테스트 실행
   ↓
빌드 수행
   ↓
Docker 이미지 생성
   ↓
스테이징 배포
   ↓
인수 테스트
   ↓
운영 배포

각 단계를 자세히 살펴보겠습니다.

1. Lint 검사

Lint는 코드 스타일과 문법 문제를 검사합니다.

대표적으로:

ESLint
Biome
Prettier

등을 사용합니다.

예를 들어:

const a = "hello"

세미콜론이 없거나 스타일 규칙이 맞지 않으면 자동으로 감지합니다.

왜 중요할까?

팀 프로젝트에서는 코드 스타일 통일이 매우 중요합니다.

스타일이 제각각이면:

가독성 저하
리뷰 어려움
유지보수 비용 증가

문제가 발생합니다.

2. 단위 테스트(Unit Test)

단위 테스트는 가장 작은 기능 단위를 검증합니다.

예시:

function add(a, b) {
  return a + b;
}

테스트:

expect(add(1, 2)).toBe(3);

단위 테스트의 장점

빠른 오류 발견

코드 수정 직후 문제 확인 가능

리팩토링 안정성

기존 기능이 깨졌는지 즉시 확인 가능

유지보수 향상

오래된 프로젝트일수록 효과가 큼

코드 커버리지(Code Coverage)

커버리지는:

“테스트가 코드의 몇 %를 검증했는가”

를 의미합니다.

예시:

함수 10개 중 8개 테스트
조건문 일부 미검증

→ 커버리지 80%

커버리지가 중요한 이유

테스트가 존재한다고 해서 충분한 것은 아닙니다.

실제로 중요한 로직이 테스트되지 않았을 수도 있습니다.

그래서:

함수
조건문
분기
예외 처리

등이 얼마나 검증되었는지 확인해야 합니다.

3. 빌드 및 패키징

테스트가 끝나면 실제 서비스 형태로 빌드합니다.

예를 들어 React 프로젝트라면:

pnpm build

NestJS라면:

npm run build

을 수행합니다.

패키징이란?

애플리케이션을 배포 가능한 형태로 묶는 과정입니다.

대표적으로 Docker를 많이 사용합니다.

Docker 기반 패키징

예시 Dockerfile:

FROM node:20

WORKDIR /app

COPY . .

RUN pnpm install

RUN pnpm build

CMD ["pnpm", "start"]

Docker의 장점

환경 통일

개발/테스트/운영 환경 일치

배포 안정성

“내 컴퓨터에서는 됨” 문제 감소

확장성

클라우드 환경과 궁합이 좋음

4. 스테이징 배포

스테이징(Staging)은:

운영과 거의 동일한 테스트 서버

입니다.

운영 서버에 바로 배포하면 위험하기 때문에 중간 검증 단계가 필요합니다.

왜 스테이징이 중요할까?

실제 운영 환경에서는:

DB 연결
Redis
인증
클라우드 스토리지
환경 변수

등 다양한 요소가 연결됩니다.

로컬 테스트만으로는 검증이 어렵습니다.

그래서 운영과 유사한 환경에서 먼저 테스트합니다.

스테이징 서버에서 하는 것

API 검증

실제 요청 테스트

UI 테스트

프론트 화면 확인

성능 테스트

응답 속도 확인

협업 검증

프론트/백엔드 연동 테스트

5. 인수 테스트(Acceptance Test)

인수 테스트는:

“사용자 입장에서 기능이 정상 동작하는가”

를 확인하는 테스트입니다.

단위 테스트와 차이점

단위 테스트

함수/모듈 중심

인수 테스트

실제 사용자 흐름 중심

예시

사용자 로그인 흐름:

로그인 페이지 접속
이메일 입력
비밀번호 입력
로그인 버튼 클릭
메인 페이지 이동 확인

이 전체 흐름을 테스트합니다.

E2E 테스트와의 관계

인수 테스트는 보통 E2E 테스트 형태로 구현됩니다.

대표 도구:

Selenium
Cypress
Playwright

실제 CI/CD 흐름 예시

예를 들어 GitHub Actions를 사용하면:

name: CI

on:
  push:
    branches:
      - develop

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v3

      - run: pnpm install

      - run: pnpm lint

      - run: pnpm test

      - run: pnpm build

이렇게 자동화할 수 있습니다.

GitHub Actions의 장점

GitHub와 통합 쉬움

별도 서버 없이 사용 가능

PR 검증 가능

Pull Request마다 자동 테스트

협업 효율 증가

오류 코드 머지 방지

실무에서 자주 사용하는 전략

브랜치 전략

대표적으로:

main
develop
feature/*
hotfix/*

형태를 많이 사용합니다.

feature 브랜치

기능 개발용

develop 브랜치

통합 테스트용

main 브랜치

실제 운영 코드

PR 기반 코드 리뷰

CI/CD와 함께 코드 리뷰 문화도 중요합니다.

PR 과정에서:

코드 품질 확인
로직 검증
버그 예방
구조 개선

이 가능합니다.

자동화가 가져오는 가장 큰 변화

CI/CD를 도입하면 가장 크게 바뀌는 것은:

“개발 속도보다 안정성이 훨씬 좋아진다”

입니다.

처음에는 설정이 어렵고 복잡하게 느껴질 수 있습니다.

하지만 프로젝트 규모가 커질수록 자동화의 가치가 엄청나게 커집니다.

실제로 줄어드는 문제들

배포 실수 감소

수동 작업 제거

테스트 누락 감소

자동 검증

협업 충돌 감소

빠른 피드백

장애 대응 속도 향상

문제 위치 빠른 파악

DevOps 문화와 연결

CI/CD는 단순 도구가 아닙니다.

개발(Development)과 운영(Operations)을 연결하는 DevOps 문화의 핵심입니다.

즉:

개발자
QA
운영팀
인프라 팀

이 함께 안정적인 서비스를 만드는 방향으로 연결됩니다.

앞으로 더 중요해지는 자동화

최근에는:

Docker
Kubernetes
GitHub Actions
Jenkins
ArgoCD
Terraform

등 자동화 생태계가 더욱 발전하고 있습니다.

특히 AI 기반 개발 도구가 증가하면서:

“더 빠르게 개발하고 더 안정적으로 배포하는 능력”

이 점점 중요해지고 있습니다.

마무리

처음 CI/CD를 접하면 어렵고 복잡하게 느껴질 수 있습니다.

하지만 실제 프로젝트를 진행하다 보면:

테스트 자동화
배포 자동화
스테이징 검증
코드 품질 관리

가 얼마나 중요한지 체감하게 됩니다.

특히 팀 프로젝트에서는:

협업 효율 증가
버그 감소
유지보수 향상
안정적인 서비스 운영

에 큰 도움이 됩니다.

결국 좋은 개발은 단순히 기능을 만드는 것이 아니라:

“안정적으로 동작하고, 안전하게 배포되며, 지속적으로 개선 가능한 구조를 만드는 것”

이라고 생각합니다.

CI/CD는 바로 그 기반이 되는 핵심 개발 문화입니다.

[18주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 83

Ejah — Sun, 17 May 2026 18:59:16 +0900

AWS 기반 배포 환경 구축과 테스트 경험 정리

최근 프로젝트를 진행하면서 단순히 기능 개발만 하는 것이 아니라, 실제 서비스처럼 “배포 가능한 환경”을 직접 구축해보는 경험을 하게 되었습니다.
특히 AWS를 활용한 서버 배포, 환경 설정, 배포 도구 구성, 그리고 최종 테스트 과정까지 경험하면서 단순한 로컬 개발과는 전혀 다른 영역이라는 것을 느낄 수 있었습니다.

이번 글에서는 제가 진행했던 AWS 활용 계획부터 배포 환경 설정, 배포 도구 구성, 그리고 테스트 과정까지 전체 흐름을 정리해보려고 합니다.

왜 배포 환경이 중요한가?

처음 프로젝트를 시작하면 대부분은 로컬 환경에서 개발을 진행합니다.

예를 들어:

localhost:3000
localhost:5173
localhost:8080

이런 형태로 실행하게 됩니다.

하지만 실제 서비스는 로컬 환경에서 동작하지 않습니다.

실제 서비스는 다음과 같은 요소들이 필요합니다.

외부 사용자가 접속 가능한 서버
데이터베이스 운영 환경
보안 설정
HTTPS
로그 관리
장애 대응
배포 자동화
서버 재시작 및 프로세스 관리

즉, 개발만 잘한다고 끝나는 것이 아니라 “운영 가능한 형태”로 만드는 과정이 반드시 필요합니다.

그리고 이 과정을 담당하는 대표적인 클라우드 플랫폼 중 하나가 바로 AWS입니다.

AWS를 사용하는 이유

AWS(Amazon Web Services)는 현재 가장 많이 사용되는 클라우드 플랫폼 중 하나입니다.

대표적으로 다음과 같은 장점이 있습니다.

1. 높은 확장성

서비스 규모가 커지면 서버도 함께 확장할 수 있습니다.

예를 들어:

사용자가 많아짐
트래픽 증가
이미지 업로드 증가
실시간 소켓 통신 증가

이런 상황에서 AWS는 서버를 유연하게 확장할 수 있도록 도와줍니다.

2. 다양한 서비스 제공

AWS는 단순히 서버만 제공하는 것이 아닙니다.

대표적인 서비스는 다음과 같습니다.

서비스역할

EC2	가상 서버
RDS	데이터베이스
S3	파일 저장
CloudFront	CDN
Route53	DNS
IAM	권한 관리
CloudWatch	로그/모니터링
ElastiCache	Redis 캐시

즉, 실제 서비스를 구성하는 대부분의 요소를 AWS 안에서 해결할 수 있습니다.

3. 실제 현업에서 많이 사용

많은 기업들이 AWS 기반으로 인프라를 운영합니다.

따라서 프로젝트 단계에서 AWS를 경험해보는 것은 단순한 학습 이상의 의미가 있습니다.

특히:

서버 배포
인프라 구조
환경 변수 관리
보안 그룹
운영 로그
장애 대응

같은 경험은 이후 실무에서도 매우 도움이 됩니다.

AWS 활용 계획

프로젝트 초기에는 어떤 구조로 서비스를 배포할 것인지 먼저 계획을 세워야 했습니다.

단순히 “서버 하나 띄우기”가 아니라 전체 구조를 생각해야 했습니다.

예를 들어:

프론트엔드 배포 위치
백엔드 서버 위치
데이터베이스 운영 방식
Redis 사용 여부
이미지 저장 위치
도메인 연결 방식

등을 고려해야 했습니다.

전체 배포 구조 설계

저희 프로젝트는 대략 다음과 같은 흐름으로 설계했습니다.

사용자 브라우저
   ↓
프론트엔드 서버
   ↓
백엔드 API 서버
   ↓
DB / Redis

그리고 각각의 역할을 나누었습니다.

프론트엔드

프론트는 React + Vite 기반으로 구성되어 있었습니다.

배포 시에는:

pnpm build

를 통해 정적 파일을 생성하고 이를 배포했습니다.

백엔드

백엔드는:

Node.js
Express 또는 NestJS
TypeScript

기반으로 구성되었습니다.

실제 서버에서는:

PM2
Node 실행 환경
환경 변수
포트 관리

등이 필요했습니다.

데이터베이스

PostgreSQL 기반으로 운영했습니다.

로컬에서는 Docker 기반으로 실행했지만 운영 환경에서는 별도 서버 또는 클라우드 DB 환경을 고려했습니다.

Redis

실시간 기능과 캐싱 처리를 위해 Redis도 함께 사용했습니다.

특히:

랭킹 캐시
오늘 목표 조회 캐시
타이머 상태
실시간 데이터 처리

등에서 Redis가 중요한 역할을 했습니다.

배포 환경 설정

실제 배포를 진행하면서 가장 먼저 해야 했던 것은 서버 환경 설정이었습니다.

EC2 서버 생성

AWS에서 가장 대표적인 서버 서비스는 EC2입니다.

EC2는 가상 서버를 생성할 수 있는 서비스입니다.

처음에는 다음과 같은 작업을 진행했습니다.

1. 인스턴스 생성

운영체제를 선택합니다.

보통:

Ubuntu
Amazon Linux

등을 많이 사용합니다.

저는 Ubuntu 환경을 사용했습니다.

2. 키 페어 생성

EC2 접속을 위해 .pem 키 파일을 생성합니다.

이 파일은 SSH 접속에 사용됩니다.

예:

ssh -i key.pem ubuntu@ip주소

3. 보안 그룹 설정

보안 그룹은 AWS의 방화벽 개념입니다.

여기서:

22번 포트 (SSH)
80번 포트 (HTTP)
443번 포트 (HTTPS)
서버 포트

등을 열어야 합니다.

예를 들어:

→ SSH 접속
→ HTTP
→ HTTPS
→ Node 서버

서버 초기 세팅

서버에 접속한 이후에는 개발 환경을 구성해야 했습니다.

Node.js 설치

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install nodejs

pnpm 설치

프로젝트에서 pnpm을 사용했기 때문에 설치가 필요했습니다.

npm install -g pnpm

Git 설치

sudo apt install git

이후 GitHub 저장소를 clone 했습니다.

git clone repository-url

환경 변수 설정

실제 배포에서 가장 중요한 부분 중 하나가 환경 변수입니다.

예를 들어:

DATABASE_URL=
JWT_SECRET=
REDIS_URL=
AWS_ACCESS_KEY=
AWS_SECRET_KEY=

같은 값들은 절대로 코드에 직접 올리면 안 됩니다.

따라서 .env 파일을 통해 관리했습니다.

환경 변수 관리가 중요한 이유

환경 변수는 다음과 같은 민감한 정보를 포함합니다.

DB 비밀번호
JWT Secret
AWS 키
Redis 주소
API Key

만약 GitHub에 잘못 업로드되면 큰 문제가 발생할 수 있습니다.

따라서:

.env

설정도 반드시 필요했습니다.

배포 도구 설정

서버에서 단순히:

node server.js

로 실행하는 것은 매우 위험합니다.

왜냐하면:

서버가 꺼질 수 있음
SSH 종료 시 프로세스 종료 가능
로그 관리 어려움
재시작 불가능

등의 문제가 있기 때문입니다.

PM2 사용

그래서 PM2를 사용했습니다.

PM2는 Node.js 프로세스 매니저입니다.

설치:

npm install -g pm2

실행:

pm2 start dist/main.js

PM2의 장점

1. 서버 자동 재시작

프로세스가 죽으면 자동 복구됩니다.

2. 로그 확인 가능

pm2 logs

를 통해 로그를 쉽게 확인할 수 있습니다.

3. 상태 확인

pm2 status

현재 서버 상태를 확인할 수 있습니다.

4. 재부팅 후 자동 실행

pm2 startup
pm2 save

를 통해 서버 재부팅 이후에도 자동 실행됩니다.

Nginx 설정

실제 서비스에서는 Nginx도 매우 중요했습니다.

Nginx는:

Reverse Proxy
HTTPS 처리
로드 밸런싱
정적 파일 처리

등을 담당합니다.

Reverse Proxy 구조

예를 들어:

사용자 → 80포트
Nginx → Node 서버 3000포트

이런 구조로 연결됩니다.

Nginx 설정 예시

server {
    listen 80;

    location / {
        proxy_pass http://localhost:3000;
    }
}

HTTPS 적용

실제 서비스에서는 HTTPS가 매우 중요합니다.

이를 위해 Let's Encrypt를 사용했습니다.

대표적으로:

sudo certbot --nginx

를 사용하여 HTTPS 인증서를 적용할 수 있습니다.

Redis 운영 경험

프로젝트에서는 Redis를 적극적으로 사용했습니다.

특히 캐시 처리에서 Redis의 효과를 체감할 수 있었습니다.

예를 들어:

목표 리스트 조회
랭킹 조회
타이머 상태

등을 캐싱했습니다.

캐시의 장점

DB를 직접 조회하는 대신 Redis에서 데이터를 가져오기 때문에 훨씬 빠릅니다.

예:

DB 조회 → 느림
Redis 조회 → 매우 빠름

하지만 Redis도 장애가 발생한다

실제로 운영 환경에서는 Redis 연결 오류도 경험했습니다.

예를 들어:

SocketClosedUnexpectedlyError
ClientClosedError

같은 문제들이 발생했습니다.

처음에는 당황했지만 이를 통해 중요한 점을 배웠습니다.

운영 환경에서는 장애 대응이 중요하다

단순히 기능만 구현하는 것이 아니라:

Redis 장애 시 fallback
DB fallback 처리
timeout 처리
reconnect 처리

등이 매우 중요했습니다.

예를 들어:

try {
  return await redis.get(key);
} catch {
  return dbData;
}

같은 방식으로 안정성을 높였습니다.

캐시 전략 고민

모든 데이터를 무조건 캐싱하면 오히려 문제가 생길 수도 있었습니다.

예를 들어:

실시간성이 중요한 데이터
자주 변경되는 데이터
사용자별 데이터

는 캐시 정합성 문제가 발생할 수 있었습니다.

특히:

오늘 목표 리스트
타이머 상태

는 캐싱 전략을 매우 신중하게 설계해야 했습니다.

배포 환경 테스트

배포 이후에는 반드시 테스트가 필요했습니다.

단순히 “배포 성공”이 끝이 아닙니다.

테스트 항목

실제로 다음과 같은 부분들을 확인했습니다.

1. API 정상 동작 여부

로그인
회원가입
목표 생성
타이머 시작
타이머 종료

등이 정상 동작하는지 확인했습니다.

2. 환경 변수 적용 여부

운영 환경에서 .env 값이 정상 반영되는지 테스트했습니다.

3. Redis 연결 상태

Redis가 정상 연결되는지 확인했습니다.

로그를 통해:

Redis Connected
Redis Ready

등을 확인했습니다.

4. DB 연결 확인

Prisma 연결 상태도 확인했습니다.

5. 서버 재시작 테스트

PM2 재시작 이후 정상 복구되는지 확인했습니다.

6. 캐시 동작 테스트

동일 요청 시:

첫 요청은 DB 조회
두 번째 요청은 Cache Hit

가 되는지 확인했습니다.

실제 운영 환경에서 느낀 점

배포를 직접 경험하면서 가장 크게 느낀 것은:

개발과 운영은 완전히 다른 영역이라는 점입니다.

로컬에서는 잘 동작하던 코드가 운영 환경에서는 예상치 못한 문제를 만들기도 했습니다.

예를 들어:

환경 변수 누락
포트 충돌
Redis 연결 실패
CORS 문제
HTTPS 문제
서버 재시작 이슈

등이 발생했습니다.

가장 어려웠던 부분

개인적으로 가장 어려웠던 부분은:

“정합성 유지”

였습니다.

특히 캐시를 사용할 때:

데이터 수정
→ 캐시 삭제
→ 새로운 데이터 생성

흐름을 제대로 관리하지 않으면 오래된 데이터가 보여질 수 있었습니다.

이 과정에서:

캐시 무효화
TTL 설정
fallback 처리

등의 중요성을 크게 느꼈습니다.

배포 경험을 통해 얻은 것

이번 경험을 통해 단순히 코드를 작성하는 것 이상의 것들을 배우게 되었습니다.

예를 들어:

서버 운영 흐름
클라우드 구조
보안 설정
환경 변수 관리
장애 대응
캐시 전략
HTTPS 적용
프로세스 관리

등을 실제로 경험할 수 있었습니다.

마무리

처음에는 AWS와 배포 환경이 굉장히 어렵게 느껴졌습니다.

하지만 직접 서버를 만들고, 환경을 구성하고, Redis와 DB를 연결하고, 실제 API를 운영해보면서 단순한 “기능 개발” 이상의 경험을 얻을 수 있었습니다.

특히:

실제 서비스 구조를 이해하게 되었고
운영 환경의 중요성을 체감했으며
안정적인 서비스를 만들기 위해 어떤 고민이 필요한지 배우게 되었습니다.

앞으로는 단순히 기능 구현만 하는 개발자가 아니라:

“운영까지 고려할 수 있는 개발자”

가 되는 것을 목표로 계속 경험을 쌓아가고 싶습니다.

[18주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 82

Ejah — Thu, 14 May 2026 23:15:56 +0900

Selenium을 활용한 E2E 테스트 자동화 완벽 가이드

들어가며

웹 서비스를 개발하다 보면 가장 많이 듣게 되는 말 중 하나가 바로 “테스트는 중요하다”라는 이야기다. 실제로 기능 하나를 수정했는데 전혀 예상하지 못한 곳에서 오류가 발생하거나, 배포 이후 특정 기능이 동작하지 않는 상황은 생각보다 자주 발생한다. 특히 프론트엔드와 백엔드가 함께 동작하는 서비스에서는 단순한 단위 테스트만으로는 실제 사용자의 행동 흐름을 완벽하게 검증하기 어렵다.

예를 들어 회원가입 → 로그인 → 게시글 작성 → 댓글 작성 → 로그아웃과 같은 흐름은 여러 API와 UI, 상태 관리 로직이 동시에 연결되어 있다. 이런 흐름은 각 기능이 따로 정상 동작하더라도 실제 사용 환경에서는 예상치 못한 문제가 발생할 수 있다.

이때 중요한 역할을 하는 것이 바로 E2E(End-to-End) 테스트이다.

E2E 테스트는 실제 사용자가 서비스를 사용하는 것처럼 브라우저를 직접 조작하면서 전체 흐름을 검증하는 테스트 방식이다. 그리고 이러한 E2E 테스트 자동화 도구 중 가장 대표적인 것이 Selenium이다.

이번 글에서는 Selenium이 무엇인지부터 시작해 Selenium IDE, Selenium WebDriver, E2E 테스트 전략, 테스트 자동화의 장점과 한계, 실제 프로젝트 적용 방법까지 자세하게 정리해보려고 한다.

Selenium이란?

Selenium은 웹 브라우저를 자동으로 제어할 수 있도록 도와주는 오픈소스 테스트 자동화 프레임워크이다.

쉽게 말하면 사람이 직접 브라우저를 클릭하고 입력하는 행동을 코드로 대신 수행할 수 있도록 만들어주는 도구라고 볼 수 있다.

예를 들어 아래와 같은 행동을 자동으로 수행할 수 있다.

특정 웹사이트 접속
로그인 버튼 클릭
입력창에 텍스트 입력
게시글 작성
페이지 이동 검증
특정 요소 존재 여부 확인
버튼 활성화 상태 확인
경고창 처리
파일 업로드
스크롤 이동
페이지 렌더링 대기

즉, 사용자의 실제 행동을 자동화해서 테스트할 수 있는 것이다.

Selenium은 다양한 브라우저를 지원한다.

Chrome
Firefox
Edge
Safari

또한 여러 프로그래밍 언어에서도 사용할 수 있다.

JavaScript
TypeScript
Java
Python
C#
Ruby

특히 최근에는 React, Vue, Next.js 같은 프론트엔드 프레임워크 기반 프로젝트에서도 E2E 테스트의 중요성이 커지면서 Selenium이나 Playwright, Cypress 같은 자동화 도구 사용이 점점 증가하고 있다.

E2E 테스트란?

E2E는 End-to-End의 약자로, 서비스의 전체 흐름을 처음부터 끝까지 검증하는 테스트를 의미한다.

보통 테스트는 크게 세 가지로 나뉜다.

종류설명

단위 테스트(Unit Test)	함수나 컴포넌트 하나를 테스트
통합 테스트(Integration Test)	여러 모듈이 함께 동작하는지 테스트
E2E 테스트	실제 사용자 흐름 전체 테스트

예를 들어 로그인 기능을 테스트한다고 가정해보자.

단위 테스트

expect(validatePassword("1234")).toBe(false);

비밀번호 검증 함수 하나만 테스트한다.

통합 테스트

로그인 API 호출 후 토큰 저장 여부 확인

프론트와 API 연결 정도를 테스트한다.

E2E 테스트

1. 로그인 페이지 접속
2. 이메일 입력
3. 비밀번호 입력
4. 로그인 버튼 클릭
5. 메인 페이지 이동 확인

실제 사용자가 행동하는 전체 흐름을 테스트한다.

즉, E2E 테스트는 가장 현실적인 테스트 방식이라고 볼 수 있다.

Selenium의 주요 구성 요소

Selenium은 단순히 하나의 도구가 아니라 여러 구성 요소로 이루어져 있다.

1. Selenium IDE

Selenium IDE는 브라우저 확장 프로그램 형태로 제공되는 도구이다.

사용자가 직접 브라우저를 조작하면 그 행동을 자동으로 기록해준다.

예를 들어 아래와 같은 행동을 기록할 수 있다.

클릭
입력
페이지 이동
요소 선택
검증

초보자도 쉽게 테스트 케이스를 만들 수 있다는 장점이 있다.

특히 테스트 자동화를 처음 접하는 사람에게 매우 좋은 입문 도구라고 생각한다.

Selenium IDE 장점

코드 없이 테스트 가능
브라우저 조작만으로 테스트 생성 가능
빠른 테스트 프로토타입 작성 가능
간단한 기능 검증에 적합

Selenium IDE 단점

복잡한 로직 구현 어려움
유지보수 어려움
동적 UI 대응 한계
대규모 프로젝트에는 부적합

즉, 간단한 테스트에는 매우 유용하지만 실제 서비스 수준의 자동화에는 한계가 있다.

2. Selenium WebDriver

실제 프로젝트에서 가장 많이 사용하는 핵심 기능이다.

WebDriver는 코드로 브라우저를 직접 제어할 수 있게 해준다.

예를 들어 JavaScript에서는 아래와 같이 사용할 수 있다.

const { Builder, By } = require("selenium-webdriver");

(async function example() {
  let driver = await new Builder().forBrowser("chrome").build();

  await driver.get("https://example.com/login");

  await driver.findElement(By.name("email")).sendKeys("test@test.com");

  await driver.findElement(By.name("password")).sendKeys("1234");

  await driver.findElement(By.css("button")).click();
})();

실제 브라우저를 실행하고 사용자 행동을 그대로 자동화한다.

3. Selenium Grid

Selenium Grid는 여러 환경에서 테스트를 동시에 실행할 수 있도록 도와주는 기능이다.

예를 들어 아래와 같은 테스트가 가능하다.

Chrome + Windows
Safari + macOS
Firefox + Linux

대규모 서비스에서는 다양한 브라우저 호환성이 매우 중요하기 때문에 Grid 기능이 자주 활용된다.

Selenium을 사용하는 이유

1. 실제 사용자 환경 테스트 가능

가장 큰 장점이다.

단순 함수 테스트가 아니라 실제 브라우저를 기반으로 테스트하기 때문에 현실적인 오류를 발견할 수 있다.

예를 들어 아래와 같은 문제를 발견할 수 있다.

버튼 클릭이 안 되는 문제
CSS 때문에 요소가 가려지는 문제
모바일 반응형 깨짐
브라우저 호환성 문제
API 응답 지연 문제
렌더링 타이밍 문제

이런 문제는 단위 테스트만으로는 발견하기 어렵다.

2. 반복 작업 자동화

매번 수동으로 테스트하는 것은 매우 비효율적이다.

특히 배포 전마다 아래와 같은 작업을 반복한다고 생각해보자.

로그인 테스트
회원가입 테스트
결제 테스트
게시글 작성 테스트
관리자 권한 테스트

기능이 많아질수록 테스트 시간은 기하급수적으로 증가한다.

하지만 Selenium을 활용하면 버튼 클릭부터 결과 검증까지 모두 자동으로 수행할 수 있다.

즉, 개발자는 더 중요한 문제 해결에 집중할 수 있게 된다.

3. 회귀 테스트에 강함

회귀 테스트는 기존 기능이 정상 동작하는지 다시 확인하는 테스트이다.

예를 들어 로그인 기능을 수정했는데 게시글 작성 기능이 갑자기 깨지는 상황이 발생할 수 있다.

Selenium 기반 자동화 테스트가 있다면 이런 문제를 빠르게 발견할 수 있다.

실제 현업에서는 새로운 기능 개발보다 기존 기능 유지보수 비중이 훨씬 커지는 경우가 많다.

따라서 회귀 테스트 자동화는 프로젝트 안정성에 매우 중요한 역할을 한다.

Selenium 테스트 전략

테스트 자동화를 무조건 많이 만든다고 좋은 것은 아니다.

잘못 설계된 테스트는 오히려 유지보수 비용만 증가시킨다.

따라서 테스트 전략이 매우 중요하다.

1. 핵심 사용자 흐름 우선 테스트

가장 중요한 흐름부터 자동화하는 것이 좋다.

예를 들어 쇼핑몰 서비스라면 다음 흐름이 핵심이다.

회원가입 → 로그인 → 상품 조회 → 장바구니 → 결제

이 흐름이 깨지면 서비스 자체가 동작하지 않는 수준의 문제가 발생한다.

따라서 가장 먼저 자동화해야 한다.

2. 지나치게 세부적인 UI 테스트 지양

예를 들어 아래와 같은 테스트는 유지보수 비용이 매우 크다.

버튼 너비가 정확히 120px인지 확인

UI는 자주 변경되기 때문에 너무 세부적인 테스트는 오히려 독이 될 수 있다.

대신 실제 사용자 기능 중심으로 테스트하는 것이 중요하다.

예를 들어:

로그인 버튼 클릭 시 메인 페이지 이동 여부 확인

이런 테스트가 훨씬 가치가 높다.

3. 테스트 독립성 유지

테스트끼리 서로 영향을 주지 않도록 구성해야 한다.

예를 들어 회원가입 테스트가 실패했다고 로그인 테스트까지 실패하면 원인 파악이 어려워진다.

따라서 테스트는 가능한 독립적으로 설계하는 것이 중요하다.

Selenium IDE를 활용한 테스트 케이스 개발

Selenium IDE는 테스트 자동화 입문 단계에서 매우 유용하다.

특히 QA나 비개발 직군도 쉽게 테스트를 만들 수 있다는 장점이 있다.

테스트 케이스 예시

로그인 테스트

1. 로그인 페이지 접속
2. 이메일 입력
3. 비밀번호 입력
4. 로그인 버튼 클릭
5. 메인 페이지 이동 확인

Selenium IDE는 이 과정을 자동으로 기록한다.

그리고 저장된 테스트는 반복 실행할 수 있다.

Selenium WebDriver 실전 예제

프로젝트 설치

npm install selenium-webdriver

ChromeDriver도 필요하다.

npm install chromedriver

기본 테스트 코드

const { Builder, By, until } = require("selenium-webdriver");

(async function test() {
  let driver = await new Builder().forBrowser("chrome").build();

  try {
    await driver.get("https://example.com/login");

    await driver.findElement(By.name("email")).sendKeys("test@test.com");

    await driver.findElement(By.name("password")).sendKeys("1234");

    await driver.findElement(By.css("button")).click();

    await driver.wait(until.urlContains("dashboard"), 5000);

    console.log("로그인 성공");
  } finally {
    await driver.quit();
  }
})();

이 코드는 실제 브라우저를 실행한 뒤 로그인 과정을 자동으로 수행한다.

동적 페이지 테스트 시 주의할 점

최근 웹 서비스는 대부분 React, Vue 같은 SPA 구조를 사용한다.

이 경우 비동기 렌더링 때문에 테스트가 실패하는 경우가 많다.

예를 들어 버튼이 아직 렌더링되지 않았는데 클릭하려고 하면 오류가 발생한다.

따라서 적절한 대기 처리가 매우 중요하다.

잘못된 방식

await driver.sleep(3000);

단순 sleep은 비효율적이다.

좋은 방식

await driver.wait(until.elementLocated(By.id("submit")), 5000);

요소가 실제로 나타날 때까지 기다리는 방식이 훨씬 안정적이다.

E2E 테스트 자동화의 장점

안정적인 배포 가능

자동화 테스트가 있으면 배포 전 검증이 쉬워진다.

CI/CD 파이프라인과 연결하면 아래 흐름이 가능하다.

코드 Push → 자동 테스트 → 성공 시 배포

즉, 사람이 직접 테스트하지 않아도 된다.

개발 속도 향상

처음에는 테스트 작성 시간이 오래 걸린다.

하지만 프로젝트 규모가 커질수록 자동화의 효과가 엄청나게 커진다.

특히 반복 테스트 시간이 크게 줄어든다.

협업 효율 증가

프론트엔드와 백엔드가 동시에 개발할 때 자동화 테스트는 매우 큰 도움이 된다.

API 변경이나 UI 변경이 발생했을 때 즉시 문제를 발견할 수 있기 때문이다.

Selenium의 한계

물론 Selenium이 완벽한 도구는 아니다.

테스트 속도가 느림

실제 브라우저를 실행하기 때문에 단위 테스트보다 훨씬 느리다.

유지보수 비용 존재

UI가 자주 바뀌면 테스트 코드도 계속 수정해야 한다.

특히 CSS selector 기반 테스트는 쉽게 깨질 수 있다.

비동기 처리 어려움

렌더링 타이밍 문제 때문에 flaky test가 발생하기 쉽다.

flaky test란 가끔 성공하고 가끔 실패하는 불안정한 테스트를 의미한다.

좋은 테스트 코드 작성 방법

1. data-testid 사용

<button data-testid="login-button">로그인</button>

By.css('[data-testid="login-button"]')

이렇게 작성하면 UI 변경에도 테스트가 덜 깨진다.

2. Page Object Pattern 활용

페이지별 로직을 분리하면 유지보수가 쉬워진다.

LoginPage.js

class LoginPage {
  async login(email, password) {
    // 로그인 로직
  }
}

이런 방식으로 구조화하면 테스트 코드 재사용성이 높아진다.

3. 테스트 데이터 분리

하드코딩 대신 별도 데이터 파일을 사용하는 것이 좋다.

const testUser = {
  email: "test@test.com",
  password: "1234",
};

CI/CD와 Selenium 연동

실무에서는 GitHub Actions와 함께 사용하는 경우가 많다.

GitHub Actions 예시

name: E2E Test

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Install Dependencies
        run: npm install

      - name: Run Selenium Tests
        run: npm run test:e2e

이렇게 설정하면 코드가 Push될 때마다 자동으로 E2E 테스트가 실행된다.

실제 프로젝트에서 느낀 점

테스트 자동화는 처음에는 굉장히 귀찮게 느껴질 수 있다.

특히 기능 개발 일정이 촉박한 상황에서는 테스트 코드 작성이 우선순위에서 밀리는 경우가 많다.

하지만 프로젝트 규모가 커질수록 테스트 자동화의 중요성은 압도적으로 커진다.

특히 여러 명이 협업하는 프로젝트에서는 예상치 못한 사이드 이펙트가 자주 발생한다.

이때 자동화 테스트는 단순한 품질 관리 수준을 넘어 개발 안정성을 지켜주는 안전망 역할을 하게 된다.

또한 Selenium 기반 E2E 테스트를 경험하면서 느낀 가장 큰 점은 “사용자 관점으로 기능을 바라보게 된다”는 점이었다.

단순히 API가 성공했다고 끝나는 것이 아니라:

실제 버튼이 눌리는지
페이지 이동이 자연스러운지
로딩 중 문제가 없는지
렌더링 타이밍 오류는 없는지
브라우저별 차이가 없는지

이런 부분까지 확인하게 된다.

즉, 테스트 자동화는 단순 검증 도구가 아니라 더 좋은 사용자 경험을 만들기 위한 과정이라고 생각한다.

마무리

Selenium은 오랫동안 사용되어 온 대표적인 웹 테스트 자동화 도구이다.

특히 E2E 테스트를 통해 실제 사용자 흐름을 검증할 수 있다는 점에서 매우 강력한 장점을 가지고 있다.

물론 테스트 속도나 유지보수 같은 한계도 존재하지만, 프로젝트 규모가 커질수록 자동화 테스트의 가치는 더욱 커진다.

특히 최근에는 CI/CD 환경과 결합되면서 테스트 자동화가 거의 필수 요소처럼 자리 잡고 있다.

처음에는 Selenium IDE로 간단한 테스트를 경험해보고, 이후 WebDriver 기반 코드 자동화로 확장해나가는 방식이 가장 좋은 학습 흐름이라고 생각한다.

결국 안정적인 서비스를 만드는 가장 좋은 방법은 “문제가 발생하기 전에 미리 검증하는 것”이다.

그리고 Selenium 기반 E2E 테스트 자동화는 그 검증을 가능하게 만들어주는 매우 강력한 도구라고 할 수 있다.

[18주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 81

Ejah — Wed, 13 May 2026 23:48:31 +0900

단위 테스트 실습 파일과

컨테이너화에 대한 이야기

[18주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 80

Ejah — Tue, 12 May 2026 23:20:53 +0900

데이터베이스 설계와 프론트엔드 설계, 컴포넌트