mirabo01 님의 블로그

성능 분석까지 다뤘다면, 이제는지금까지 배운 내용을 실제 코드로 엮어보는 단계로 넘어가는 게 자연스럽다.이번 챕터에서는외부 프레임워크 없이 표준 라이브러리 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현재 디렉터리 기준으로 ..

상태 관리까지 정리했다면이제 앱은 “기능적으로는” 꽤 그럴듯해진다.그다음에 체감되는 문제가 하나 있다.화면 전환이 묘하게 버벅인다입력할 때 전체 화면이 다시 그려지는 느낌리스트가 많아지면 확 느려진다이건 대부분렌더링 구조를 제대로 이해하지 못한 상태에서컴포넌트가 불필요하게 다시 그려지기 때문이다.이 글에서는React Native에서 성능 최적화를 시작할 때가장 먼저 이해해야 할 포인트를 정리한다.이 글이 필요한 사람앱이 커질수록 점점 느려지는 느낌이 드는 경우useMemo, useCallback을 왜 쓰는지 감이 안 오는 경우“일단 다 감싸면 되지 않나?”라고 생각한 적 있는 경우React Native 성능의 핵심은 렌더링이다React Native 앱에서성능 이슈의 대부분은 이 한 문장으로 정리된다.“필..

로깅과 설정까지 정리했다면, 이제 운영 관점에서 빠질 수 없는 마지막 기본 주제인테스트(testing) 를 다룰 차례다.Go는 테스트를 “특별한 작업”으로 취급하지 않는다.별도의 프레임워크를 강요하지도 않고,테스트 코드 역시 일반 Go 코드의 연장선으로 다룬다.이 글에서는Go의 testing 패키지 기본 사용법테스트 코드 파일 구조실무에서 자주 쓰는 테스트 작성 기준을 중심으로 정리한다.Go 테스트의 기본 철학먼저 Go 테스트의 전제를 하나 짚고 가는 게 좋다.Go 테스트는많이, 자주, 가볍게 작성하는 것을 전제로 한다.테스트 러너 설치 필요 없음IDE 의존도 낮음CI 환경에서도 동일하게 동작덕분에 테스트는“나중에 여유 되면”이 아니라개발 흐름 안에 자연스럽게 포함되기 쉽다.testing 패키지 기본 구..

useContext까지 정리했다면이제 이런 생각이 들기 시작한다.상태가 점점 많아진다Context가 여러 개로 늘어난다로직이 한곳에 모이지 않는다이 지점에서상태 관리 라이브러리를 고민하게 된다.문제는 항상 이거다.“도대체 뭘 써야 하지?”이 글에서는React Native 실무에서 자주 언급되는Redux, Zustand, Recoil을과하지 않게, 선택 기준 중심으로 정리한다.이 글이 필요한 사람useContext로 버티다 한계를 느낀 경우Redux가 무겁게 느껴지는 경우상태 관리 라이브러리 선택 기준이 없는 경우상태 관리 라이브러리를 쓰는 이유상태 관리 라이브러리는상태와 로직을 한곳에서 관리하기 위해 사용한다.상태 위치가 명확해진다화면과 로직이 분리된다디버깅이 쉬워진다하지만 그만큼구조와 규칙이 추가된다...

빌드와 배포까지 정리했다면, 이제부터는**“운영 환경에서 Go 애플리케이션을 어떻게 관리할 것인가”**라는 관점으로 넘어가게 된다.그중에서도 가장 기본이 되는 요소가로깅(logging) 과 설정 관리(configuration) 다.코드는 잘 돌아가는데, 막상 문제가 생기면“어디서 뭐가 잘못됐는지 알 수 없는 상태”가 되는 경우는 대부분 이 두 가지가 부실할 때 발생한다.이 글에서는Go에서 로깅을 어떻게 시작하는 게 좋은지설정 값을 어떤 방식으로 관리하는 게 현실적인지실무에서 자주 쓰는 기준과 주의점을 중심으로 정리한다.Go 기본 로깅: log 패키지부터 이해하기Go 표준 라이브러리에는 log 패키지가 기본 제공된다.import "log"log.Println("server started")별도 설정 없이 ..

API 연동까지 했다면이제 이런 고민이 자연스럽게 생긴다.로그인 정보는 어디에 두지?여러 화면에서 같은 데이터를 써야 하는데?props를 계속 내려야 하나?이 시점이 바로상태 관리가 필요해지는 순간이다.이 글에서는상태 관리 라이브러리를 바로 쓰기 전에,React Native에서 useContext로 어디까지 가능한지를실무 기준으로 정리한다.이 글이 필요한 사람props drilling이 불편해지기 시작한 경우전역 상태가 왜 필요한지 감이 안 오는 경우Redux 같은 라이브러리가 부담스러운 경우상태(state)는 왜 문제가 될까지금까지는대부분 이런 구조였을 것이다.화면 안에서만 쓰는 state컴포넌트 하나에서 관리하지만 앱이 커지면상태가 여러 화면에 걸쳐 필요해진다.예를 들면,로그인 사용자 정보토큰다크모드..