mirabo01 님의 블로그

쿠버네티스 배포의 핵심, Deployment와 ReplicaSet 이해하기앞선 글에서 Pod, Node, Cluster 같은 기본 구조를 살펴봤다.이제부터는 실제로 쿠버네티스를 쓰면서 가장 자주 만나게 되는 개념으로 넘어간다.바로 Deployment와 ReplicaSet이다.쿠버네티스에서 애플리케이션을 배포한다고 할 때,대부분의 경우 직접 Pod를 만들지는 않는다.대신 Deployment를 정의하고, 나머지는 쿠버네티스에 맡긴다.왜 Pod를 직접 만들지 않을까처음 쿠버네티스를 접하면 이런 생각이 든다.“컨테이너 하나 띄우면 되는데 Pod만 만들면 되지 않나?”“굳이 Deployment까지 써야 하나?”기술적으로는 가능하다.하지만 운영 관점에서는 거의 의미가 없다.Pod는 다음과 같은 특성을 가진다.언제든..

이전 챕터에서net/http + handler / service / repository 구조로 CRUD API를 만들었다면,이번에는 그 구조를 Gin 프레임워크로 옮겨보는 단계다.이번 챕터의 핵심은 분명하다.Gin 문법을 많이 아는 것 ❌기존 구조를 깨지 않고 프레임워크만 교체 ⭕️즉,“Gin을 쓰면 코드 구조가 어떻게 달라지는가”가 아니라**“달라지지 않아야 하는 부분은 무엇인가”**에 초점을 둔다.왜 이 타이밍에 Gin을 보는가Gin은 Go 웹 프레임워크 중 가장 많이 사용된다.하지만 실무에서 Gin을 잘 쓰는 사람들의 공통점은 이거다.Gin 이전에 net/http 흐름을 한 번은 이해했다이 과정을 거치면Gin의 Context가 왜 필요한지미들웨어가 어디에 끼어드는지테스트를 어떻게 해야 하는지가 훨씬..

쿠버네티스 핵심 구성 요소 한 번에 정리하기 (Pod, Node, Cluster)지난 글에서는 쿠버네티스가 왜 등장했고 어떤 문제를 해결하려는지를 중심으로 살펴봤다.이번 글에서는 쿠버네티스를 이해하기 위해 반드시 넘어야 하는 핵심 구성 요소들을 정리한다.처음 쿠버네티스를 접하면 용어가 많아서 막막해지기 쉽다.하지만 구조를 단순하게 보면, 생각보다 복잡하지는 않다.이 글은 개념을 한 번에 정리하고 싶은 사람에게 도움이 되도록 구성했다.쿠버네티스 구성 요소를 바라보는 관점쿠버네티스를 이해할 때 가장 좋은 방법은 다음 질문에서 출발하는 것이다.컨테이너는 어디서 실행되는가누가 컨테이너를 관리하고 감시하는가문제가 생기면 누가 판단하고 조치하는가이 질문에 답하다 보면 자연스럽게 주요 구성 요소가 정리된다.Pod: ..

CRUD API까지 만들었다면,다음으로 자연스럽게 이어지는 주제는 DB 연동이다.이번 챕터에서는ORM을 바로 쓰지 않고, 표준 라이브러리 database/sql 을 기준으로DB 연결 흐름SQL 실행 방식Repository 패턴으로 구조를 정리하는 방법을 정리한다.목표는“편한 코드”가 아니라실무에서 오래 유지되는 구조를 한 번 만들어보는 것이다.왜 database/sql부터 다뤄야 할까Go에는 GORM 같은 ORM도 있고,sqlx 같은 헬퍼 라이브러리도 있다.그럼에도 불구하고database/sql을 먼저 다뤄보는 이유는 명확하다.모든 DB 라이브러리의 기반쿼리 실행 흐름이 명확함성능 특성을 직접 제어 가능문제가 생겼을 때 디버깅이 쉬움실무에서도“ORM을 쓰더라도 내부 동작은 database/sql”이라는 ..

쿠버네티스란 무엇인가, 왜 요즘 더 중요해졌을까요즘 백엔드나 인프라 쪽 이야기를 하다 보면 쿠버네티스를 빼놓기 어렵다.단순히 “컨테이너 오케스트레이션 도구”라고 설명하기에는, 실제로 사용하는 범위와 영향력이 꽤 넓어졌다.이 글은 쿠버네티스를 처음 접하는 사람이나,도커까지는 써봤지만 그 다음 단계에서 막힌 개발자를 대상으로 한다.개념을 최대한 차분하게 정리하고, 왜 이 기술이 등장했고 어떤 문제를 해결하려는지부터 짚어본다.쿠버네티스는 어떤 문제를 해결하려고 나왔을까컨테이너 기술이 본격적으로 쓰이기 시작하면서, 애플리케이션 배포는 훨씬 가벼워졌다.하지만 컨테이너 개수가 늘어나기 시작하면 다른 문제가 생긴다.컨테이너를 여러 서버에 어떻게 나눠서 배치할지서버가 죽었을 때 컨테이너를 어떻게 다시 띄울지트래픽이 늘..

이전 챕터에서라우팅 분리와 미들웨어 구조를 잡았다면,이제는 그 위에 실제로 동작하는 CRUD API를 올려볼 차례다.이번 챕터의 목표는 단순하다.REST 형태의 CRUD API를 한 번 직접 만들어보고비즈니스 로직과 HTTP 레이어를 분리하고그 구조를 테스트 코드로 검증해본다“완성도 높은 서비스”보다는실무에서 반복되는 기본 패턴을 익히는 데 초점을 둔다.예제 시나리오: User 관리 API예제로는 가장 단순한 User 리소스를 사용한다.POST /users 사용자 생성GET /users 사용자 목록 조회GET /users/{id} 사용자 단건 조회DB 대신메모리 저장소(in-memory store) 를 사용해구조에만 집중한다.기본 구조 다시 정리cmd/serve..

이전 챕터에서 net/http로 가장 단순한 API 서버를 만들었다면,이번에는 그 서버를 **조금 더 “실제 서비스에 가까운 형태”**로 확장해본다.이번 챕터의 핵심은 다음 두 가지다.라우팅 로직을 어떻게 정리하는가공통 로직을 미들웨어 형태로 어떻게 분리하는가프레임워크 없이도구조적으로 정리된 서버 코드를 만드는 게 목표다.왜 라우팅 분리가 필요한가단순 예제에서는 이런 코드가 문제 없어 보인다.http.HandleFunc("/ping", pingHandler)http.HandleFunc("/users", userHandler)http.HandleFunc("/orders", orderHandler)하지만 엔드포인트가 늘어나면 곧 한계가 온다.main 함수가 비대해짐핸들러 간 책임이 섞임테스트가 어려워짐그래서..

앱을 처음 배포해보면빌드보다 더 긴장되는 단계가 있다.바로 스토어 심사다.코드도 문제없고빌드도 잘 됐는데갑자기 “리젝” 메일이 온다이 단계에서 당황하는 이유는개발 문제가 아니라 정책 문제이기 때문이다.이 글에서는React Native + Expo 앱을 기준으로실제로 자주 걸리는 스토어 심사 리젝 사례를입문자 관점에서 정리한다.이 글이 필요한 사람첫 앱 배포를 앞두고 있는 경우이미 한 번 이상 리젝을 당한 경우“뭐가 문제인지 모르겠다”는 상태인 경우스토어 심사는 무엇을 보는가먼저 이 관점부터 정리해야 한다.스토어 심사는“코드 품질”이 아니라사용자 보호와 정책 준수를 본다.그래서 다음 항목들이 핵심이다.개인정보 수집 여부앱 설명과 실제 기능 일치 여부계정/결제/권한 사용의 정당성테스트 가능 여부[이미지: 앱..

성능 분석까지 다뤘다면, 이제는지금까지 배운 내용을 실제 코드로 엮어보는 단계로 넘어가는 게 자연스럽다.이번 챕터에서는외부 프레임워크 없이 표준 라이브러리 net/http만 사용해서가장 기본적인 HTTP API 서버를 만들어본다.이 글의 목적은“화려한 기능”이 아니라,Go 서버 코드의 기본 뼈대가 어떻게 생겼는지를 이해하는 데 있다.왜 net/http부터 시작하는가Go 웹 개발을 검색하면Gin, Echo 같은 프레임워크가 먼저 등장한다.하지만 실무 기준으로 보면,프레임워크도 결국 net/http 위에 있음기본 구조를 모르면 디버깅이 어려움단순한 서비스에는 표준 라이브러리로도 충분이라는 이유로net/http를 한 번은 직접 써보는 게 좋다.가장 단순한 HTTP 서버package mainimport ( ..

이미지 최적화까지 마쳤다면이제 개발 단계는 거의 끝이다.다음으로 반드시 거쳐야 할 단계가 있다.바로 빌드와 배포다.내 폰에서는 잘 되는데APK / IPA는 어떻게 만들지?스토어 등록은 또 뭐가 이렇게 많지?이 글에서는Expo를 사용하는 React Native 프로젝트 기준으로배포 전 전체 흐름을 한 번에 정리한다.이 글이 필요한 사람Expo로 만든 앱을 실제로 배포해보고 싶은 경우Android / iOS 빌드 흐름이 감이 안 오는 경우스토어 등록 전에 무엇을 준비해야 하는지 알고 싶은 경우React Native 배포 전체 흐름큰 흐름부터 보면 이렇다.앱 정보 설정빌드 환경 준비Android / iOS 빌드스토어 업로드심사 대응[이미지: React Native 앱 배포 전체 흐름]이 글에서는Expo + E..