mirabo01 님의 블로그

이전 챕터에서라우팅 분리와 미들웨어 구조를 잡았다면,이제는 그 위에 실제로 동작하는 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..

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

FlatList 최적화까지 했는데도앱이 여전히 무겁게 느껴진다면다음으로 의심해야 할 건 거의 항상 이미지다.실무에서 체감 성능 문제를 추적해보면원인이 이런 경우가 많다.이미지 용량이 너무 큼스크롤할 때마다 이미지 다시 로드리스트에 이미지가 많은데 최적화 안 됨이 글에서는React Native에서 이미지를 다룰 때 꼭 알아야 할 최적화 포인트를실무 기준으로 정리한다.이 글이 필요한 사람이미지가 많은 화면에서 스크롤이 끊기는 경우FlatList는 최적화했는데 여전히 느린 경우이미지 캐싱 개념이 잘 안 잡히는 경우React Native에서 이미지가 느린 이유웹과 달리모바일 앱에서는 이미지가 더 민감하다.메모리 사용량 제한네트워크 환경 다양저사양 기기 존재특히 리스트 + 이미지 조합은최적화하지 않으면 바로 성능..

테스트까지 작성했다면, 이제 한 단계 더 나아가**“이 코드가 얼마나 효율적으로 동작하는가”**를 고민하게 된다.Go는 성능을 직접 튜닝하지 않아도상당히 준수한 결과를 내는 편이지만,트래픽이 늘거나 처리량이 중요해지는 순간막연한 추측이 아니라 근거 있는 분석이 필요해진다.이때 사용하는 도구가 바로 pprof다.이 글에서는pprof가 무엇인지어떤 성능 문제를 볼 수 있는지실무에서 최소한으로 활용하는 방법을 중심으로 정리한다.pprof는 무엇을 해주는 도구인가pprof는 Go에서 제공하는 성능 프로파일링 도구다.코드를 뜯어보거나 로그를 찍지 않아도, 다음 정보를 수집할 수 있다.CPU를 어디서 많이 쓰는지메모리를 어디서 할당하는지goroutine이 왜 늘어나는지어떤 함수가 병목인지중요한 점은**“느린 이유를..

리스트 화면은React Native 앱에서 가장 흔하면서도가장 쉽게 느려지는 부분이다.처음엔 잘 동작하다가데이터가 조금만 늘어나면 이런 증상이 나온다.스크롤이 끊긴다이미지 로딩이 버벅인다입력할 때 리스트 전체가 다시 그려진다이 글에서는FlatList를 쓸 때 실무에서 꼭 챙기는 성능 포인트를옵션 중심으로 정리한다.이 글이 필요한 사람FlatList 스크롤이 부드럽지 않은 경우리스트 아이템이 많아질 예정인 경우성능 최적화를 어디서부터 해야 할지 모르는 경우FlatList가 기본적으로 빠른 이유FlatList는보이는 영역 위주로만 렌더링한다.화면에 안 보이는 아이템은 렌더링하지 않음스크롤 위치에 따라 동적으로 생성/제거그래서ScrollView보다 기본 성능은 훨씬 좋다.하지만설정을 안 하면 반쪽짜리 성능이 ..

go mod까지 정리했다면, 이제 실제로코드를 어떻게 빌드하고 실행하며, 운영 환경에 배포하는지를 다룰 차례다.Go는 빌드와 배포 과정이 단순한 편이다.하지만 단순하다고 해서 아무 생각 없이 쓰다 보면환경별 차이, 바이너리 관리, 설정 처리에서 다시 헷갈리기 쉽다.이 글에서는Go 빌드와 실행의 기본 흐름환경별 빌드 방식실무에서 자주 사용하는 배포 패턴을 중심으로 정리한다.go run vs go build, 언제 무엇을 쓰나go run: 빠른 실행용go run main.go소스 코드를 즉시 컴파일 후 실행임시 바이너리를 만들어 실행한다실행 파일이 남지 않는다로컬 개발이나 간단한 테스트에는 충분하지만,운영 환경에서는 거의 사용하지 않는다.go build: 실행 파일 생성go build현재 디렉터리 기준으로 ..