GraphQL vs REST API : 2025년 기준으로 다시 생각해보기

![image](https://memgraph.com/_next/image?url=%2Fimages%2Fblog%2Fgraphql-vs-rest-api%2Fcover.png&w=1920&q=75)

# 개요

> 2025년 현재, 클라이언트-서버 API 설계에는 두 가지 주요 접근 방식이 있습니다. REST API는 20년 넘게 업계 표준이었고, GraphQL은 2015년 오픈소스화 이후 빠르게 성장했습니다. 둘 다 프로덕션에서 충분히 검증되었으며, "최고"의 선택은 프로젝트 요구사항에 따라 달라집니다.

---
# REST API

## 핵심 개념

- HTTP 메서드(GET, POST, PUT, DELETE)를 사용한 리소스 기반 아키텍처
- 각 리소스는 고유한 URL을 가짐 (/users/123, /posts/456)
- JSON 형식의 응답 (사실상 표준)
- Stateless 통신

## 장점
### 1. 낮은 학습 곡선

- 대부분의 개발자가 이미 알고 있음
- HTTP 표준을 그대로 활용
- 새 팀원 온보딩이 빠름

### 2. 강력한 캐싱
```javascript
// HTTP 캐싱을 그대로 활용
GET /api/users/123
Cache-Control: max-age=3600
ETag: "abc123"

// CDN, 브라우저 캐시 모두 자동으로 동작
```
### 3. 성숙한 생태계

- Postman, Insomnia 같은 테스트 도구
- OpenAPI/Swagger로 자동 문서화
- 모든 HTTP 클라이언트 라이브러리 호환
- AWS API Gateway, Nginx 등 인프라 지원 완벽

### 4. 명확한 의미론
```javascript
GET /api/posts // 목록 조회
POST /api/posts // 생성
GET /api/posts/123 // 단건 조회
PUT /api/posts/123 // 전체 수정
PATCH /api/posts/123 // 부분 수정
DELETE /api/posts/123 // 삭제
```
### 5. 디버깅 용이

- 브라우저 Network 탭에서 바로 확인
- curl 한 줄로 테스트 가능
- 로그에서 URL만 봐도 무슨 요청인지 파악

## 단점
### 1. Over-fetching
```javascript
// 사용자 이름만 필요한데 모든 필드를 받음
GET /api/users/123
{
 "id": 123,
 "name": "홍길동", // 필요한 필드
 "email": "hong@example.com", // 불필요
 "phone": "010-1234-5678", // 불필요
 "address": { ... }, // 불필요
 "created_at": "...", // 불필요
 "updated_at": "..." // 불필요
}
```

### 2. Under-fetching (N+1 문제)
```javascript
// 게시글 목록
GET /api/posts
[{ id: 1, title: "...", author_id: 10 }, ...]
`
// 각 게시글의 작성자 정보를 가져오려면 추가 요청 필요
GET /api/users/10
GET /api/users/11
GET /api/users/12
// ...

// 또는 엔드포인트를 추가로 만들어야 함
GET /api/posts?include=author
```

### 3. 버전 관리의 복잡성
```javascript
// API가 변경되면 버전을 올려야 함
/api/v1/users // 구버전 유지
/api/v2/users // 신규 필드 추가
/api/v3/users // 구조 변경

// 여러 버전을 동시에 유지보수해야 함
```

### 4. 엔드포인트 폭발
```javascript
// 다양한 요구사항에 맞춰 엔드포인트가 계속 추가됨
GET /api/posts
GET /api/posts?status=published
GET /api/posts?author=123
GET /api/posts?author=123&status=published
GET /api/posts/trending
GET /api/posts/recommended
GET /api/users/123/posts
// ...
실무 예시
javascript// 사용자 정보와 최근 게시글 5개를 가져오려면
const user = await fetch('/api/users/123').then(r => r.json());
const posts = await fetch(`/api/users/123/posts?limit=5`).then(r => r.json());

// 2번의 네트워크 요청 필요
// 각 게시글의 댓글 수까지 필요하면 3번째 요청 또는 복잡한 엔드포인트 설계 필요
```
---
# GraphQL
## 핵심 개념

> - Facebook(현 Meta)이 2012년 개발, 2015년 오픈소스화
> - 쿼리 언어로 클라이언트가 필요한 데이터 구조를 명시
> - 단일 엔드포인트 (POST /graphql)
> - 강력한 타입 시스템 (Schema Definition Language)
> - 현재는 Linux Foundation 산하 GraphQL Foundation에서 관리

## 장점
### 1. 정확한 데이터 요청

```graphql
query {
 user(id: 123) {
 name # 필요한 필드만 명시
 email
 }
}

# 응답
{
 "data": {
 "user": {
 "name": "홍길동",
 "email": "hong@example.com"
 }
 }
}
```
### 2. 단일 요청으로 복잡한 데이터 구조
```graphql
query {
 user(id: 123) {
 name
 email
 posts(limit: 5) {
 title
 createdAt
 comments(limit: 3) {
 content
 author {
 name
 avatar
 }
 }
 }
 }
}

# 한 번의 요청으로 사용자 → 게시글 → 댓글 → 작성자 모두 가져옴
```
### 3. 강력한 타입 시스템
```graphql
type User {
 id: ID!
 name: String!
 email: String!
 posts: [Post!]!
}

type Post {
 id: ID!
 title: String!
 content: String!
 author: User!
 comments: [Comment!]!
}

# IDE에서 자동완성, 타입 체크 가능
# 컴파일 타임에 오류 발견
```

### 4. 버전 관리 불필요
```graphql
type User {
 id: ID!
 name: String!
 email: String!
 phone: String @deprecated(reason: "Use phoneNumber instead")
 phoneNumber: String
}

# 필드 추가/deprecated만으로 관리
# 클라이언트는 필요한 필드만 요청하므로 호환성 유지
```

### 5. 자가 문서화
```graphql
# 스키마 자체가 문서
# GraphQL Playground에서 모든 타입, 필드, 인자 확인 가능
# 별도 문서 작성 불필요
6. 실시간 기능 (Subscriptions)
graphqlsubscription {
 newMessage(chatId: "123") {
 id
 content
 author {
 name
 }
 }
}

# WebSocket으로 실시간 업데이트
# 채팅, 알림, 실시간 대시보드 구현 용이
```
## 단점
### 1. 학습 곡선

- GraphQL 쿼리 언어 학습 필요
- Schema 설계 패턴 학습 필요
- Resolver 개념 이해 필요
- 팀 전체가 익숙해지기까지 시간 소요

### 2. 캐싱 복잡성
```javascript
// REST는 URL 기반 캐싱
GET /api/users/123 → 캐시 키: /api/users/123

// GraphQL은 쿼리 내용이 캐시 키
// POST 요청이라 HTTP 캐싱 불가
// Apollo Client, urql 같은 전용 캐싱 필요
```
### 3. 쿼리 복잡도 관리
```graphql
# 악의적이거나 비효율적인 쿼리 가능
query {
 users {
 posts {
 comments {
 author {
 posts {
 comments {
 # 무한 중첩...
 }
 }
 }
 }
 }
 }
}

# Depth limiting, Query complexity analysis 필수
```

### 4. N+1 문제
```javascript
// Resolver가 비효율적이면 성능 문제
const resolvers = {
 Post: {
 author: (post) => {
 return db.users.findById(post.authorId); // 각 게시글마다 DB 쿼리!
 }
 }
};

// DataLoader로 해결 필요
const userLoader = new DataLoader(ids => 
 db.users.findByIds(ids) // 배치 처리
);
```

### 5. 파일 업로드
```javascript
// GraphQL 표준이 아님
// multipart/form-data 별도 구현 필요
// 또는 별도 REST 엔드포인트 사용
```
### 6. 에러 처리
```javascript
// HTTP 상태 코드를 활용할 수 없음
// 쿼리 일부만 실패해도 200 OK 반환
{
 "data": {
 "user": null // 실패
 },
 "errors": [{
 "message": "User not found",
 "path": ["user"]
 }]
}

// 클라이언트가 data와 errors를 모두 확인해야 함
```

## 실무 예시
```javascript
// Apollo Client 예시
const { data, loading, error } = useQuery(
gql`
 query GetUserWithPosts($userId: ID!) {
 user(id: $userId) {
 name
 email
 posts(limit: 5) {
 title
 createdAt
 commentCount # 서버에서 계산된 필드
 }
 }
 }
`,{
 variables: { userId: '123' }
});

// 한 번의 요청으로 모든 데이터
// 타입 안정성 보장
// 캐싱 자동 처리
```
---
# 성능 비교 (2025년 기준)
- 페이로드 크기
```javascript
// REST - 불필요한 필드 포함
{
 "id": 123,
 "name": "홍길동",
 "email": "hong@example.com",
 "phone": "010-1234-5678",
 "address": { /* ... */ },
 "preferences": { /* ... */ },
 "created_at": "2024-01-15T10:30:00Z",
 "updated_at": "2025-02-20T14:20:00Z"
}
// ~800 bytes

// GraphQL - 필요한 필드만
{
 "data": {
 "user": {
 "name": "홍길동",
 "email": "hong@example.com"
 }
 }
}
// ~150 bytes
```

**실측 데이터** (복잡한 중첩 쿼리 기준):
- REST: 평균 3-5개 요청, 총 ~2-3MB
- GraphQL: 1개 요청, ~800KB

## 네트워크 레이턴시

### REST: 
1. 요청 1: 사용자 정보 (100ms)
2. 요청 2: 게시글 목록 (120ms) 
3. 요청 3: 댓글 수 (90ms)
4. 총: ~310ms + 네트워크 오버헤드

### GraphQL:
1. 단일 요청: ~180ms

## 개발 속도

1. REST: 프론트엔드가 새 데이터 필요 → 백엔드 엔드포인트 추가 → 배포 → 사용
2. GraphQL: 프론트엔드가 새 데이터 필요 → 스키마에 이미 있으면 바로 쿼리 작성
---

# 2025년 실무 트렌드
## **REST**가 여전히 우세한 영역
### 1. 공개 API
```javascript
// Stripe, GitHub, Twilio 등 대부분의 공개 API는 REST
GET https://api.stripe.com/v1/customers/cus_xxx
Authorization: Bearer sk_xxx
```

외부 개발자가 사용하기 쉬움
문서화가 직관적
curl로 바로 테스트 가능

### 2. 간단한 CRUD 애플리케이션
```javascript
// To-do 앱, 블로그, 간단한 관리 시스템
GET /api/todos
POST /api/todos
PUT /api/todos/123
DELETE /api/todos/123
```
### 3. 레거시 시스템 통합

- 기존 REST API 인프라 활용
- 마이그레이션 비용 없음

## GraphQL이 강세인 영역
### 1. 모바일 앱
```graphql
# 데이터 사용량 최소화
# 배터리 절약
# 3G/4G 환경에서도 빠른 응답
query {
 feed(limit: 10) {
 id
 thumbnail # 작은 이미지만
 title
 }
}
```
### 2. 복잡한 데이터 관계
```graphql
# E-commerce, SNS, 협업 도구
query {
 product(id: "123") {
 name
 price
 reviews(limit: 5) {
 rating
 comment
 author {
 name
 verified
 }
 }
 relatedProducts(limit: 3) {
 name
 price
 thumbnail
 }
 }
}
```

### 3. BFF (Backend For Frontend) 패턴
*BFF패턴에 대해선 나중에 따로 다룰 예정입니다*

### 4. 실시간 대시보드
```graphql
subscription {
 orderUpdates {
 orderId
 status
 timestamp
 }
}
# WebSocket으로 실시간 업데이트
```
---

# 선택 가이드
## REST API가 적합할 경우:
1. 공개 API 또는 파트너 API
2. 간단한 CRUD 위주 애플리케이션
3. 팀이 GraphQL 학습 시간이 없는 경우
4. HTTP 캐싱을 적극 활용하고 싶은 경우
5. 레거시 시스템과 통합해야 하는 경우
6. 파일 업로드/다운로드가 주요 기능인 경우

### 구체적 예시:

1. 블로그 플랫폼 (Medium, WordPress)
2. 결제 서비스 API (Stripe, PayPal)
3. OAuth 인증 서비스
4. 간단한 관리자 대시보드


## GraphQL이 적합할 경우:

1. 모바일 앱 (데이터 효율성 중요)
2. 복잡한 데이터 관계가 많은 경우
3. 프론트엔드 요구사항이 자주 변경되는 경우
4. 실시간 기능이 필요한 경우
5. 여러 데이터 소스를 통합하는 BFF 구축
6. 타입 안정성이 중요한 경우

### 구체적 예시:

1. SNS 플랫폼 (Facebook, Instagram)
2. E-commerce (Shopify)
3. 협업 도구 (Notion, Slack)
4. 복잡한 SaaS 대시보드

---
# 실제 기업 사례 (2025년)

## REST 사용사례

- Stripe: 결제 API (외부 개발자 친화적)
- Twilio: SMS/음성 API
- AWS: 대부분의 AWS 서비스

## GraphQL 사용사례

- GitHub: API v4는 GraphQL
- Shopify: Admin API와 Storefront API
- Netflix: 내부 API (Falcor, GraphQL 유사)

## 둘 다 사용하는 사례

- GitHub: REST (v3) + GraphQL (v4)
- Contentful: REST + GraphQL
- Hasura: 자동으로 DB에서 GraphQL 생성

## 하이브리드 접근
실무에서는 둘을 함께 사용하는 경우가 많습니다:
```javascript
// 공개 API: REST
app.get('/api/v1/products/:id', ...)

// 웹/모바일 앱: GraphQL
app.post('/graphql', graphqlHTTP({ schema }))

// 파일 업로드: REST
app.post('/api/upload', upload.single('file'), ...)

// 실시간 알림: GraphQL Subscription
```
### 장점:
1. 각 기술의 강점을 활용
2. 점진적 마이그레이션 가능
3. 레거시 호환성 유지

## 마이그레이션 전략
REST → GraphQL
```javascript
// 1단계: GraphQL 서버가 REST API를 래핑
const resolvers = {
 Query: {
 user: (_, { id }) => fetch(`/api/users/${id}`).then(r => r.json())
 }
}

// 2단계: 점진적으로 Resolver를 직접 DB 접근으로 변경
const resolvers = {
 Query: {
 user: (_, { id }) => db.users.findById(id)
 }
}

// 3단계: 프론트엔드를 하나씩 GraphQL로 전환
```

### 비용 고려사항

#### **REST 추가 비용** 
- 거의 없음 (표준 HTTP)
#### **GraphQL 추가 비용**
1. 개발: 스키마 설계, Resolver 구현
2. 인프라: Apollo Server, DataLoader 등
3. 모니터링: Query complexity, 성능 추적
4. 학습: 팀 교육 시간

# 결론

**2025년 현재, 둘 다 성숙하고 프로덕션에서 검증된 기술이며 프로젝트에 맞게 사용하는게 중요할 것 같습니다.**

## 실무 추천
### 1. 스타트업/신규 프로젝트:
- 작게 시작: REST로 MVP 개발
- 복잡해지면: GraphQL 고려
- 필요시: 하이브리드 접근

### 2. 대규모 프로젝트:
- 내부용: GraphQL (효율성)
- 외부용: REST (접근성)
- 실시간: GraphQL Subscriptions

# 마지막으로 기술 선택시 가장 중요한 것
1. 팀의 경험
2. 프로젝트 요구사항
3. 장기 유지보수 가능성 고려

# 느낀점
REST API는 워낙 익숙하게 써오다 보니 크게 생각하지 않았지만, 블로그를 만들면서 처음 GraphQL을 제대로 다뤄보니 둘의 장단점이 확실히 비교를 할 수 있었습니다. 
특히 요즘 GraphQL은 Apollo까지 함께 이해해야 해서 초반에는 머리가 지끈거릴 정도로 어렵고, 학습곡선도 짧지 않지만 그래도 시간이 지나 익숙해지니까 확실히 편한 면이 많았습니다. 

개인 프로젝트라도 이렇게 GraphQL을 직접 적용해보고, 그 경험을 바탕으로 글까지 정리해볼 수 있다는 게 참 의미 있고 좋은 기회였던 것 같습니다.

> 끝을 맺기를 처음과 같이 하면 실패가 없다. - 노자 

# 프로젝트 개요
- 이 프로젝트는 지인 1명의 아이디어로 출발을 시작했습니다. 언제 완성해서 언제 끝낼지는 모르지만 최대한 열심히 프로젝트를 진행 해 볼 예정입니다

# 참여인원
- 아이디어 제공자 - 1명
- 개발자 - 1명

이 프로젝트는 개발자인 저 포함 아이디어 제공자 총 2명으로 이뤄진 프로젝트입니다 
그래서 모든 인프라, 백엔드, 프론트엔드 등의 모든 개발은 제가 혼자 할 것이고 그 외의 것들은 아이디어 제공자와 같이 진행할 예정입니다


# 계기
처음 논의된 것은 게이미피케이션의 Todo-list에서 출발했습니다. 
아이디어 제공자의 얘기를 시작으로 
외국의 한 Todo-list 앱을 모티브삼아 얘기를 진행하다가 Growdo 프로젝트까지 오게됐습니다

# What is Growdo?
명칭은 Grow + todo-list를 합친것입니다 본인의 todo list를 진행하다보면 성장한다는 뜻으로 Growdo 라고 짓게됐습니다 
전체적인 기능은 todo-list와 포인트를 합친 모습이 될 것 같습니다 
예를들어 todo-list를 진행해서 포인트를 쌓으면 그 포인트로 여러 쿠폰으로 교환 할 수 있는 형태입니다.

# 마무리
이 프로젝트는 계속 논의중이며 현재 설계단계에 있습니다 그래서 갑자기 그만둘수도 있습니다 
그렇지만 끈기를 가지고 정식 출시까지 한번 달려보겠습니다 
프로젝트의 진행상황이나 진행중의 여러 문제점은 블로그를 통해 조금씩 올려볼 예정입니다

Growdo 프로젝트

![](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/d9d6ce2b-f24a-4501-8192-42864d5d1943_how_to_manually_create_an_openstack_image.png)

>이전 포스팅에서는 오픈스택 구축에 관한 경험을 정리 했었는데 이번 포스팅부터는 구축 후 발생했던 겪었던 이슈에 대한 이슈를 정리 해본다

# 🚨 설치 단계 문제

## 1. OS 설치 관련

### 그래픽 모드 문제
**증상**: Rocky Linux 설치 시 그래픽 화면이 뜨지 않음

**원인**: 
- Nvidia 그래픽 카드 드라이버 이슈
- 하드웨어 호환성 문제

**해결방법**:
```bash
# 방법 1: 부팅 옵션 추가
# GRUB 화면에서 'e' 키를 누르고 다음 추가:
splash nomodeset

# 방법 2: Text mode 설치 후 그래픽 드라이버 설치
sudo dnf install nvidia-driver
```

### 설치 중 네트워크 문제
**증상**: 패키지 다운로드 실패

**해결방법**:
```bash
# DNS 설정 확인
cat /etc/resolv.conf

# 임시 DNS 설정
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf
```

---

# 🔧 의존성 및 버전 문제

## 1. Python/Pip 버전 불일치

**증상**: 
- Ansible 설치 실패
- "requirement already satisfied" 오류

**해결방법**:
```bash
# Python 및 pip 업그레이드
sudo dnf update python3 python3-pip

# 가상환경 사용 (권장)
python3 -m venv openstack-env
source openstack-env/bin/activate

# pip 업그레이드
pip install --upgrade pip

# 캐시 클리어
pip cache purge
```

## 2. Ansible 버전 호환성

**증상**: 
- Ansible 실행 시 모듈 오류
- "module not found" 에러

**해결방법**:
```bash
# 특정 버전 설치
pip install ansible==6.0.0

# 의존성 재설치
pip install --force-reinstall ansible

# Galaxy 컬렉션 설치
ansible-galaxy collection install ansible.posix
```

---

# 🐳 Docker 관련 문제

## 1. Docker 권한 문제

**증상**: 
- "permission denied" 오류
- Docker 명령어 실행 불가

**해결방법**:
```bash
# 사용자를 docker 그룹에 추가
sudo usermod -aG docker $USER

# 그룹 권한 즉시 적용
newgrp docker

# Docker 소켓 권한 확인
sudo chmod 666 /var/run/docker.sock
```

## 2. Docker 서비스 시작 실패

**증상**: Docker 데몬이 시작되지 않음

**해결방법**:
```bash
# 서비스 상태 확인
sudo systemctl status docker

# 로그 확인
sudo journalctl -u docker.service

# 서비스 재시작
sudo systemctl restart docker

# 자동 시작 설정
sudo systemctl enable docker
```

---

# ⚙️ Kolla-Ansible 배포 문제

## 1. 메모리 부족

**증상**: 
- 컨테이너 생성 실패
- OOM (Out of Memory) 오류

**해결방법**:
```bash
# 스왑 파일 생성
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 영구 설정
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# 메모리 사용량 확인
free -h
```

## 2. 네트워크 인터페이스 문제

**증상**: 
- "Network interface not found" 오류
- 외부 연결 불가

**해결방법**:
```bash
# 네트워크 인터페이스 확인
ip addr show

# globals.yml 수정
sudo vim /etc/kolla/globals.yml

# 올바른 인터페이스 설정
network_interface: "enp0s3" # 실제 인터페이스명
neutron_external_interface: "enp0s8"
```

## 3. 포트 충돌

**증상**: 
- "Port already in use" 오류
- 서비스 바인딩 실패

**해결방법**:
```bash
# 포트 사용 현황 확인
sudo netstat -tulpn | grep :80
sudo netstat -tulpn | grep :443

# 기존 서비스 중지
sudo systemctl stop httpd
sudo systemctl stop nginx

# 포트 확인 후 재배포
kolla-ansible -i all-in-one prechecks
```

---

# 🌐 OpenStack 서비스 문제

## 1. Keystone 인증 실패

**증상**: 
- "Authentication failure" 오류
- 대시보드 로그인 불가

**해결방법**:
```bash
# 패스워드 확인
grep keystone_admin_password /etc/kolla/passwords.yml

# 환경 변수 재설정
source /etc/kolla/admin-openrc.sh

# Keystone 컨테이너 재시작
sudo docker restart keystone
```

## 2. Nova 컴퓨트 서비스 문제

**증상**: 
- 인스턴스 생성 실패
- "No valid host found" 오류

**해결방법**:
```bash
# 컴퓨트 서비스 상태 확인
openstack compute service list

# Nova 컨테이너 로그 확인
sudo docker logs nova_compute

# 리소스 사용량 확인
openstack usage show
```

## 3. Neutron 네트워크 문제

**증상**: 
- 네트워크 생성 실패
- 인스턴스 네트워크 연결 안됨

**해결방법**:
```bash
# 네트워크 에이전트 상태 확인
openstack network agent list

# OVS 브리지 확인
sudo ovs-vsctl show

# Neutron 서비스 재시작
sudo docker restart neutron_server
sudo docker restart neutron_openvswitch_agent
```

---

# 💾 스토리지 문제

## 1. Cinder 볼륨 생성 실패

**증상**: 
- 볼륨 생성 시 오류
- "No space left" 메시지

**해결방법**:
```bash
# 디스크 사용량 확인
df -h

# Cinder 설정 확인
sudo docker exec cinder_volume cat /etc/cinder/cinder.conf

# LVM 설정 확인 (LVM 백엔드 사용 시)
sudo vgs
sudo lvs
```

## 2. 스토리지 백엔드 문제

**증상**: 
- 백엔드 초기화 실패
- 스토리지 서비스 다운

**해결방법**:
```bash
# 스토리지 서비스 상태 확인
openstack volume service list

# 로그 확인
sudo docker logs cinder_volume
sudo docker logs cinder_scheduler
```

---

# 🔍 진단 및 모니터링

## 1. 시스템 리소스 모니터링

```bash
# CPU 사용률
top
htop

# 메모리 사용률
free -h
cat /proc/meminfo

# 디스크 I/O
iostat -x 1

# 네트워크 트래픽
iftop
nethogs
```

## 2. 컨테이너 상태 확인

```bash
# 모든 컨테이너 상태
sudo docker ps -a

# 특정 컨테이너 로그
sudo docker logs <container_name>

# 컨테이너 리소스 사용량
sudo docker stats

# 컨테이너 내부 접근
sudo docker exec -it <container_name> bash
```

## 3. OpenStack 서비스 상태

```bash
# 모든 서비스 상태
openstack endpoint list
openstack service list

# 컴퓨트 서비스
openstack compute service list
openstack hypervisor list

# 네트워크 서비스
openstack network agent list

# 볼륨 서비스
openstack volume service list
```

오픈스택 구축 및 운영시 발생할 수 있는 이슈 정리

![how_to_manually_create_an_openstack_image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/d9d6ce2b-f24a-4501-8192-42864d5d1943_how_to_manually_create_an_openstack_image.png)

> 회사에서 진행한 프로젝트를 통해 OpenStack을 직접 구축하며 학습했던 과정을 정리해보려 합니다. 
당시엔 시행착오도 많고 정말 힘들었지만, 프로젝트 중에 남겨둔 문서와 제 기억을 바탕으로 가능한 한 자세하게 기술해보고자 합니다. 
다양한 시도 과정, 맨땅에 헤딩하듯 해왔던 삽질까지 모두 기록하려 합니다. 
훗날 저와 비슷한 상황에 놓인 분들에게 작은 도움이라도 되길 바라는 마음으로 이 글을 작성합니다.

# 📋 프로젝트 개요

## 배경
- **프로젝트**: 재산관리통합 프로젝트
- **메인목표**: 고객사와 유사한 개발 환경 구축
- **서브목표**: 개발자들이 통합 환경에서 배포 및 소스코드를 관리 할 수 있는 환경 구축
- **요구사항**: OpenStack 기반 클라우드 인프라 구성


## 고객사 플랫폼 구성
- **상태**: 개발 중인 플랫폼 (불안정)
- **아키텍처**:
 - OpenStack 기반 클라우드
 - VM 위에 OpenShift 컨테이너 플랫폼
 - 별도 서버의 Git 및 Database

---

# 🛠 프로젝트 개발서버 구축 환경

## 시스템 사양
- **OS**: Rocky Linux 9.4
- **네트워크**: Online망 -> Offline망

## 기술 스택
- **클라우드 플랫폼**: OpenStack
- **자동화 도구**: Ansible
- **컨테이너**: Kubernetes

---

# ⚡ 주요 도전과제 및 해결방법

## 1. OpenStack 설치 도구 선택

### 시도한 방법들
1. **DevStack** ❌
 - Red Hat 지원 중단
 - Rocky Linux 9.4 비호환

2. **PackStack** ❌
 - 동일하게 지원 중단
 - 설치 패키지 부재

3. **Ansible (Kolla-Ansible)** ✅
 - 최종 선택한 방법
 - 안정적인 지원 및 커뮤니티

---


## 2. 버전 호환성 문제

### 문제 상황
- Python과 pip 버전 불일치
- Ansible 요구 버전 미충족
- 의존성 패키지 충돌

### 해결 과정
```bash
# Python 및 pip 업그레이드
sudo dnf update python3 python3-pip

# 가상환경을 통한 Ansible 설치
python3 -m venv ansible-env
source ansible-env/bin/activate
pip install ansible

# 버전 확인
ansible --version
python3 --version
pip --version
```

**소요 시간**: 2-3일 (OS 재설치 반복 포함)

## 3. OpenStack 설정 복잡성

### 주요 난점
1. **아키텍처 선택**
 - All-in-one vs Multi-node 구성
 - 리소스 및 용도에 따른 선택 기준 부족

2. **환경 설정**
 - `globals.yaml` 파일 설정
 - 네트워크, 스토리지 구성
 - 보안 설정

3. **설치 진행 상황 판단**
 - 에러와 정상 진행 구분 어려움
 - 로그 분석 능력 부족

---

# 📚 학습 포인트

## 기술적 측면
- **시스템 관리**: Linux 시스템 관리 능력 필요
- **네트워크**: 가상 네트워크 구성 이해
- **가상화**: OpenStack 아키텍처 및 컴포넌트 이해
- **자동화**: Ansible 플레이북 작성 및 실행

## 프로젝트 관리 측면
- **문서화**: 충분한 레퍼런스 부족 시 대응 방법
- **문제 해결**: 체계적인 디버깅 접근법
- **시간 관리**: 예상보다 긴 구축 시간 고려

---

# ⚠️ 주요 교훈

## 사전 준비의 중요성
1. **환경 조사**: 하드웨어 호환성 사전 확인
2. **도구 선택**: 지원 상태 및 커뮤니티 활성도 검토
3. **백업 계획**: 실패 시 복구 방안 수립

## 학습 접근법
1. **기초 지식**: OpenStack 아키텍처 이해 우선
2. **단계별 접근**: 컴포넌트별 순차 학습
3. **실습 환경**: 테스트 환경에서 충분한 검증

## 커뮤니티 활용
1. **공식 문서**: OpenStack 공식 문서 숙지
2. **커뮤니티**: Stack Overflow, Reddit 등 활용
3. **현업 조언**: 경험자 멘토링의 중요성

---

# ✅ 최종 결과
1. OpenStack 폐쇄망 구성 완료
2. 각 서비스별 VM 발행 후 CI/CD 구축 준비 완료
3. CI/CD 구축 후 개발 환경 구성완료

---

# 💭 회고 및 느낀 점

OpenStack 구축하면서 제일 먼저 느낀 건 이거였습니다. 
"아… 이건 그냥 설치만 한다고 되는 시스템이 아니구나." 
클라우드 인프라 전체를 알아야 하고, 네트워크 구조에 대한 감도 어느 정도 필요했습니다. 

처음엔 오류 로그만 봐도 머리가 아파서 
반나절은 로그 읽고, 반나절은 구글링하고, 또 반나절은 삽질하면서 보냈습니다. 
근데 이 과정을 겪다보니
자동화의 필요성이랑 환경 격리의 중요성은 진짜 몸으로 느낄 수 있었습니다. 

**이번에 얻은 핵심 교훈은 딱 세 가지입니다** 

	1.	문서 없는 환경에서 문제 해결은 결국 ‘시도 → 실패 → 기록’ 반복이 유일한 답이다.
	2.	OpenStack 같은 대형 시스템은 설치보다 유지보수가 난이도 최상이다.
	3.	Ansible은 선택지가 아니라 필수다. 자동화 없으면 재현성도 확장성도 없다.

다음에는 OpenStack을 그냥 구축하는 데서 끝내지 않고, 
각 컴포넌트가 내부에서 어떻게 통신하고 연결되는지 
아키텍처 레벨에서 제대로 뜯어보고 싶습니다. 
실제로 알아가다 보니 더 깊이 파고싶다는 생각이 들었습니다. 
지금은 시간이 없으니 추후 프로젝트 종료 후에 다시한번 깊게 공부하면서 파볼 예정입니다.

오픈스택 구축 경험 정리

> 회고록(回顧錄) 지나간 일을 돌이켜 생각하며 적은 기록.

# 2024년을 돌아보며

## 1. 퇴사와 새로운 시작 
2024년은 정말 다사다난한 한 해였습니다. 
3월을 끝으로 지난 회사를 떠나 5월에 현재 회사에 합류했는데, 규모도 크고 개발자로서 더 성장할 기회를 제공해준 회사였습니다. 
여러 사람들과 협업하고 제안서도 작성해보며, 평소 개발만 해서는 접하기 어려운 경험들을 하게 되어 감회가 새로웠습니다.

## 2. 올해의 목표와 가장 뿌듯했던 순간 
올해의 목표는 새로운 환경에 잘 적응하고 개발자로서 한 단계 성장하는 것이었습니다.

그중에서도 가장 뿌듯했던 순간은, 제가 참여한 제안서가 실제 프로젝트 수주로 이어지고, 치열한 경쟁 속에서 결국 우리 팀이 프로젝트를 따낸 일이었습니다. 
이런 기회를 만들어준 회사와 팀에 감사했고, 스스로 목표를 잘 수행하고 있다는 확신도 들었습니다.

## 3. 마찰과 기회 
물론 과정이 순탄하기만 했던 것은 아닙니다. 제안서 작업에서는 수많은 마찰과 긴장감이 있었고, 특히 실적 압박을 받는 부장·차장급 선임들의 부담감을 가까이서 지켜보며 개발자로서는 쉽게 경험하기 어려운 순간들을 겪었습니다.

코드·서비스·성장에 대한 고민만 하던 저에게, 프로젝트 수주 과정에서 사람들의 심리와 압박까지 함께 느껴본 것은 값진 경험이었습니다. 
이 경험은 제 성장의 중요한 발판이 되었습니다.

 

# ⏳ 프로젝트 경험 
현재 저는 그 제안서로 시작된 프로젝트에 투입되어 실제 개발까지 맡고 있습니다. 
제안서 작성부터 수주, 초기 문서 작업, 중간보고, 그리고 개발까지 이어지는 A to Z 전체 과정을 직접 경험하는 것은 정말 드문 기회라 더욱 의미가 큽니다.

## 4. DevOps & Infra 경험 
올해는 개발뿐 아니라 DevOps와 인프라 업무까지 맡게 되면서 스스로 한 단계 성장했다고 느낍니다.

사람이 부족해 자연스럽게 담당하게 되었지만, 회사 워크스테이션에 OpenStack을 설치하고 개발자들이 사용할 인프라를 구축한 경험은 그 자체로 소중했습니다. 
네트워크, k8s, 인프라 관리 등 다양한 영역을 공부하고 적용하며, 개발자들이 편하게 코드 관리와 배포를 할 수 있는 환경을 성공적으로 구축했습니다. 
내년에는 이 과정들을 블로그에 조금씩 기록할 예정입니다.

 

# 💻 블로그 개발 
올해 초 제작한 블로그를 꾸준히 업데이트하며, 연말에 이렇게 회고록을 남기니 감회가 더욱 새롭습니다.

"나만의 블로그를 갖고 싶다"는 생각에서 시작했지만, 직접 설계·개발·디자인을 거쳐 완성한 뒤 운영해보니 스스로 만든 공간을 가진다는 것이 큰 기쁨이었습니다. 
블로그 개발 과정은 백엔드, 프론트엔드, 인프라, 디자인 등 모든 영역을 고민하게 했고, 개발의 재미를 다시 느끼게 해준 계기이기도 했습니다.

 

# ✅ 마무리 
올해는 정말 많은 일들이 있었습니다.

- 나만의 블로그 구축 
- 퇴사와 새로운 회사 입사 
- 프로젝트 제안 및 수주 경험 
- DevOps 및 인프라 담당 
- 그리고 현재 진행 중인 프로젝트 개발

개발자로서 다양한 경험을 하게 해준 회사와 팀원들에게 감사하며, 내년에는 프로젝트 완주에 집중하려 합니다. 

올 한 해 모두 고생 많으셨습니다. 
따뜻한 연말 되시길 바랍니다. 

감사합니다.

2024년 회고록

![typescript](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/e8c1cc3c-8aa3-42f8-9382-60df0d5c2cee_typescript.jpeg)

# react-native와 typescript로 공부를 하다 진짜 너무 황당한 에러를 맞딱뜨렸다..
>'string | null' 형식의 인수는 'string' 형식의 매개 변수에 할당될 수 없습니다. 'null' 형식은 'string' 형식에 할당할 수 없습니다.

---

# 무슨 내용의 에러인가
## 1. 우선 코드를 살펴보자
```typescript
const key = 'todos';
const rawTodos = await AsyncStorage.getItem(key);
const savedTodos: ITodos[] = JSON.parse(rawTodos);
```
1. AsyncStorage에 있는 todos라는 key로 Object Value를 가져와서 rawTodos 변수에 저장한다.
2. rawTodos에 저장되어있는 Object를 JSON.parse를 통해 파싱을 해서 savedTodos 변수에 저장한다.
3. 이때 JSON.parse(rawTodos)에서 rawTodos에 빨간색 밑줄이 생기면서 위의 에러를 떨군다

## 2. 무엇이 문제인가
해당 코드의 에러는 typescript에서 발생해서 타입이 맞지않는다는 에러인데 rawTodos에
const rawTodos: string | null
으로 type을 지정해줘도 위의 에러는 사라지지않았다

---

# 해결방법
정말 온갖 생쇼를 하다가 정말 간단하게 해결했다
## 1. 해결방법1
```typescript
const key = 'todos';
const rawTodos = await AsyncStorage.getItem(key);
if (!rawTodos) {
 throw new Error('No saved todos');
}
const savedTodos: ITodos[] = JSON.parse(rawTodos);
```
위의 코드처럼 rawTodos가 없을때 즉 null일 경우 처리해준다

## 2. 해결방법2
tsconfig.json에서 
strictNullChecks: false 
로 설정해준다 
typescript로 개발하다보면 현재의 경우처럼 빡세게 null 체크를 할 때가있는데 이걸 false로 해주면 좀 널널하게 바꿔준다는것 같다

---

# 마무리
typescript를 공부하는 중이라 정말 여러가지 난관에 부딪히는거 같다
특히 저런 에러는 구글링을해도 잘 못찾겠더라
typescript를 잘다루기까지의 난관이 너무 험난하다...

TypeScript 타입 에러

![nestjs](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/709b0388-fd0c-4648-a768-381a590ad90e_nestjs.jpg)

> NestJS 패키지 설치시 ts-jest 때문에 설치가 안되는 현상

# 2023년 1월 중순부터 현재(1월 31일)까지 ts-jest 설치가 안되는 현상이 발견됨

1. 일단 이렇게 패키지 설치가 안될경우에 패키지의 문제인지 아닌지를 확인하기위해서 스택오버플로우에 검색을 해봤지만 외국인들은 설치가 잘만 되는것 같았다
2. 그럼 집에있는 네트워크가 문제인가 싶어 노트북에 핸드폰 테더링을 연결해서 install 해봤지만 실패 (집에있는 인터넷, 핸드폰 모두 KT 사용중)
3. 그렇다면 생각해볼 수 있는건 통신사 문제라는것으로 결론이 났고 그렇게 구글링 시작


# 현재 이 문제는 KT를 사용하고 있는 한국사람들 대상으로 일어나고 있는 문제가 맞았다

1. https://github.com/kulshekhar/ts-jest/issues/3992 확인해보니
2. 한국인들이 이슈를 열어 놓은게 있어 읽어봤다
3. KT망에서만 설치가 안되는것을 확인했다
4. npm support 팀에서 KT망에서만 안되는 원인을 파악중이라고 한다


# 해결책
`npm config set registry https://registry.npmjs.cf/`을 터미널에 입력해 mirror로 바꿔주고 install 하면 제대로 설치된다
나중에 이슈가 해결되면

`npm config set registry https://registry.npmjs.org/`
로 다시 바꿔주는것도 잊지말자..

# 결론
KT나 npm쪽에서 아직 공식적인 발표가 없어 뭐라 하긴 힘들지만... 1월 초까지만 해도 분명 잘됐었다 지금 KT 사용자만 안되는걸로봐선 거의 KT 잘못이 확실한것 같다... 통신사를 바꾸던지 해야지...



ts-jest 설치 안되는 현상


# 새로운 시작 블로그를 열며

저만의 공간을 가지고 싶어 블로그를 하나 만들어 제 생각을 남길 예정입니다

지금 상용하고있는 여러 블로그도 있지만 내 입맛대로 꾸미고싶은 욕심이 항상 있어서

이렇게 만들어서 운영하게 됐습니다

제 블로그에 쓴 글 들이 누군가에겐 도움이 되길 바라며...