mirabo01 님의 블로그

상태 관리까지 정리했다면이제 앱은 “기능적으로는” 꽤 그럴듯해진다.그다음에 체감되는 문제가 하나 있다.화면 전환이 묘하게 버벅인다입력할 때 전체 화면이 다시 그려지는 느낌리스트가 많아지면 확 느려진다이건 대부분렌더링 구조를 제대로 이해하지 못한 상태에서컴포넌트가 불필요하게 다시 그려지기 때문이다.이 글에서는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컴포넌트 하나에서 관리하지만 앱이 커지면상태가 여러 화면에 걸쳐 필요해진다.예를 들면,로그인 사용자 정보토큰다크모드..

프로젝트 구조까지 정리했다면, 이제 Go 개발에서 빠질 수 없는 주제인의존성 관리, 즉 go mod를 살펴볼 차례다.예전의 GOPATH 기반 개발을 경험한 사람이라면go mod 도입 이후 “훨씬 편해졌다”는 말을 많이 하게 된다.다만 실제로 쓰다 보면go.mod, go.sum, replace, tidy 같은 개념에서 한 번쯤 헷갈리게 된다.이 글에서는go mod의 기본 개념go.mod / go.sum의 역할실무에서 자주 쓰는 명령어와 주의점을 중심으로 정리한다.Go 모듈이란 무엇인가Go 모듈은 프로젝트 단위의 의존성 관리 시스템이다.프로젝트가 어떤 라이브러리를 사용하는지어떤 버전을 사용하는지어떻게 재현 가능한 빌드를 보장하는지를 명확하게 관리한다.Go 1.16 이후부터는go mod가 사실상 표준 방식이 ..

네비게이션까지 만들었다면이제 앱의 형태는 거의 갖춰졌다.다음 단계는“실제 데이터”를 붙이는 것이다.서버에서 목록 가져오기상세 정보 요청로딩 처리에러 처리React Native에서 API 연동은웹과 크게 다르지 않지만,처음에는 몇 가지 포인트에서 헷갈린다.이 글에서는fetch와 axios를 기준으로 API 연동의 기본 흐름을입문자 + 실무 기준으로 정리한다.이 글이 필요한 사람서버 데이터를 화면에 띄우고 싶은 경우fetch와 axios 중 뭘 써야 할지 고민되는 경우API 호출 위치와 타이밍이 헷갈리는 경우React Native에서 API 연동 흐름전체 흐름을 먼저 보면 이렇다.화면 진입API 요청로딩 상태 표시데이터 성공/실패 처리화면 렌더링이 흐름은React Native든 웹이든 거의 동일하다.[이미지..

동시성까지 한 번 훑었다면, 이제는**“Go 프로젝트를 어떻게 구성하는 게 좋은가”**라는 질문으로 넘어오게 된다.Go는 문법뿐만 아니라프로젝트 구조와 패키지 설계에서도 강한 의견을 가진 언어다.처음에는 “너무 자유로운 것 아닌가?”라는 느낌을 받을 수 있지만,몇 가지 기준만 잡아두면 오히려 유지보수가 쉬워진다.이 글에서는Go 프로젝트의 기본 구조패키지를 나누는 기준실제로 많이 사용하는 디렉터리 패턴을 중심으로 정리한다.Go 프로젝트 구조에는 정답이 없다먼저 전제부터 정리할 필요가 있다.Go에는 공식적으로 강제되는 프로젝트 구조가 없다Spring, Django처럼“이 디렉터리는 반드시 이 역할” 같은 규칙이 존재하지 않는다.대신 Go는 다음 원칙을 강하게 밀고 있다.패키지는 작게의존성은 한 방향으로불필요..

Stack Navigation으로화면 이동까지 구현했다면이제 앱 구조가 조금 보이기 시작한다.하지만 실제 앱을 떠올려보면대부분 이런 형태다.하단에 탭이 있고홈 / 검색 / 설정 같은 화면이 고정되어 있음화면을 왔다 갔다 해도 탭은 유지됨이 구조를 만드는 게**Tab Navigation(탭 네비게이션)**이다.이번 글에서는react-navigation 기반 하단 탭 구조를 처음부터입문자 기준으로 정리한다.이 글이 필요한 사람하단 탭이 있는 앱 구조를 만들고 싶은 경우Stack과 Tab을 어떻게 같이 써야 할지 헷갈리는 경우실제 앱 같은 구조로 확장하고 싶은 경우Tab Navigation이 필요한 이유Stack Navigation만 쓰면화면이 계속 쌓이는 구조가 된다.홈 → 상세 → 설정 → 다시 홈이런 흐..

channel까지 이해했다면, 이제 Go 동시성의 흐름을 실제로 제어하는select 문을 살펴볼 차례다.goroutine과 channel을 사용하다 보면“여러 channel 중 하나라도 준비되면 처리하고 싶다”는 상황이 자연스럽게 등장한다.이때 사용하는 문법이 바로 select다.이 글에서는select 문이 어떤 역할을 하는지동작 방식과 기본 규칙실무에서 자주 사용하는 패턴을 중심으로 정리한다.select 문이 필요한 이유channel 하나만 다룰 때는 하지만 channel이 여러 개라면 이야기가 달라진다.// 이런 상황은 불가능하다if 여러 channel을 동시에 기다리기 위해Go는 select라는 전용 문법을 제공한다.select 기본 구조select {case v := 준비된 case 하나만 실행실..