Search

3월

3/1

expo prebuild

expo prebuild는 expo설정기반으로 ios android디렉토리 재생성하기 때문에 덮어씌워질 위험이 있음
expo prebuild를 해야하는 경우는 expo install로 네이티브 라이브러리를 추가한 경우 라이브러리가 적용되도록 하기 위해서. 혹은 app.json등의 expo설정 변경
네이티브 코드를 변경한 이후에는 prebuild를 할 필요가 없다 오히려 덮어씌워진다!!
그러므로 expo run:android로 빌드만 다시 수행한 이후 expo start해서 핫 리로딩으로 사용하면 되지 prebuild하면 안된다.
따라서 기존에 수정했던 내용 덮어씌우고 싶은게 아니라면 prebuild를 피해야함
npx expo run android는 개발서버 실행하는 명령어는 아니다 빌드 명령어지. 근데 마지막에 개발서버도 expo start로 실행해주는거임
초기 빌드:
expo run:android (또는 expo run:ios)를 한 번 실행하여 커스텀 dev client를 빌드합니다.
JS 개발 단계:
Metro Bundler를 실행하기 위해 expo start를 별도로 실행하거나, expo run 명령어가 자동으로 Metro를 실행하도록 설정되어 있다면 그대로 사용합니다.
이렇게 하면, JS 코드 변경 사항은 핫 리로딩으로 빠르게 반영됩니다.
네이티브 코드 변경 시:
네이티브 파일 수정 후에는 expo run:android (또는 expo run:ios)를 다시 실행하여 변경된 네이티브 코드를 적용합니다.

Config Plugin 사용 방법

Config Plugin은 Expo의 prebuild 시 네이티브 프로젝트(ios/, android/)의 설정을 자동으로 수정해 주는 도구입니다.
이를 통해 수동으로 네이티브 파일을 수정하지 않고도, 앱 구성(app.json 또는 app.config.js) 기반으로 원하는 네이티브 설정을 적용할 수 있습니다.

기본 사용법

1.
플러그인 파일 생성
예를 들어, 프로젝트 루트에 withMyCustomConfig.js 파일을 만듭니다.
js CopyEdit // withMyCustomConfig.js const { withAndroidManifest, withInfoPlist } = require('@expo/config-plugins'); // AndroidManifest.xml 수정 예시 const withCustomAndroidManifest = (config) => { return withAndroidManifest(config, config => { // 예: 기존 Manifest에 새로운 intent-filter 추가 등 const manifest = config.modResults; // 수정 로직을 여기에 작성 return config; }); }; // Info.plist 수정 예시 const withCustomInfoPlist = (config) => { return withInfoPlist(config, config => { // 예: 새로운 키-값 추가 config.modResults.MyCustomKey = "MyCustomValue"; return config; }); }; // 플러그인 메인 함수 const withMyCustomConfig = (config) => { config = withCustomAndroidManifest(config); config = withCustomInfoPlist(config); return config; }; module.exports = withMyCustomConfig;
JSON
복사
2.
앱 구성에 플러그인 추가
app.json 또는 app.config.js 파일에 플러그인 경로를 추가합니다.
json CopyEdit { "expo": { "name": "MyApp", "slug": "myapp", "plugins": [ "./withMyCustomConfig.js" ] } }
JSON
복사
3.
prebuild 실행
앱 구성 파일에 플러그인을 추가한 후, expo prebuild를 실행하면 플러그인에서 정의한 네이티브 수정 사항이 ios/ 및 android/ 폴더에 반영됩니다.

js

html의 script태그 내에 직접 작성할수도 있고 src로 주소를 제공할수도 있음
근데 결국에는 <script>로 변환되어서 html에 들어간다.
여러개의 script태그를 사용할 수 있고 위에서부터 아래로 순차적으로 브라우저가 실행함
외부 JavaScript 파일을 불러올 때 <script> 태그를 <body> 끝부분에 두는 것이 일반적
<head> 안에 <script>를 넣으면 HTML이 완전히 로딩되기 전에 JavaScript가 실행될 수 있어서 웹 페이지 렌더링이 지연될 가능성이 있음.
<body> 끝에 배치하면 HTML이 먼저 로딩된 후 JavaScript가 실행되므로 성능이 개선됨.

css

css는 style태그로 변환되지 않음. 왜냐면 렌더링엔진은 html css를 따로 해석해서 html파싱하면서 동시에 css파일 다운로드함 non-blocking
js는 html파싱 멈추는 blocking임
<link> 방식이 더 선호되는 이유
CSS를 별도의 파일로 관리하면 HTML과 분리되어 유지보수가 쉬워짐
여러 HTML 문서에서 같은 스타일을 재사용 가능
브라우저가 CSS 파일을 캐싱하여 성능을 최적화할 수 있음

3/5

supabase, react-native-google-signin 둘다 참고해야함
google cloud도 필수임
React Native에서 네이티브 모듈을 자주 추가할 계획이라면 기본적인 Android 빌드 시스템 (Gradle, Kotlin DSL 등) 학습이 도움 됨.
향후 React Native + 네이티브 기능을 결합한 앱 (예: Bluetooth, Background Services 등)을 만들 생각이라면 Android 네이티브를 조금 공부하는 게 좋음.
Expo 대신 React Native Bare Workflow(네이티브 코드 많이 수정하는 방식)로 개발할 계획이라면 Android/iOS 네이티브 개발 지식이 필요함.
cd android ./gradlew clean cd .. expo run:android
JSON
복사
gradlew로 빌드하는것은 안드로이드 프로젝트만.
expo run android는 안드로이드 프로젝트 빌드 + 번들링된 js파일과 브릿지 설정하고 expo sdk에 포함된 네이티브 모듈 연결해서 사용가능한 앱으로 만든다.
cd ios pod install cd .. expo run:ios
JSON
복사

OAuth

OAuth는 사용자가 서비스에 로그인할 때 제3자 인증 제공자(Google, Facebook 등) 를 통해 인증하는 방식이야. 보통 OAuth 2.0이 사용되며, 기본적인 흐름은 다음과 같아:
1.
사용자가 웹/앱에서 로그인 버튼을 클릭.
2.
브라우저를 통해 Google (또는 다른 인증 제공자)으로 이동.
3.
사용자 동의 후, 서비스가 액세스 토큰을 받아옴.
4.
액세스 토큰을 이용해 API 요청을 인증할 수 있음.

OneTap

One Tap은 OAuth를 좀 더 쉽게 사용할 수 있도록 Google이 제공하는 간편 로그인 방식이야.
웹용 One Tap: 사용자가 Google 계정으로 로그인하려 하면 브라우저 상단에 팝업이 떠서 한 번의 클릭으로 로그인 가능.
Android용 One Tap (네이티브 로그인): 브라우저를 거치지 않고, OS가 제공하는 기능을 이용해 바로 Google 계정으로 로그인 가능.
iOS의 경우? iOS에는 Android처럼 네이티브 One Tap 기능이 없기 때문에, OAuth 기반의 로그인 방식을 사용해야 해.
즉, iOS에서는 Google의 OAuth 인증을 사용하여 ID 토큰을 받아 Supabase Auth 서버에 보내는 방식이 적절해.

iosURLScheme

iOS URL Scheme은 앱이 특정 URL 패턴을 통해 실행될 수 있도록 설정하는 값이야. Google OAuth를 iOS에서 사용할 때, 사용자가 Google 계정으로 로그인한 후 다시 앱으로 돌아오도록 하기 위해 필요해.
Google OAuth에서는 로그인을 마친 후 Google이 인증 결과를 앱으로 전달할 때 이 URL Scheme을 사용해.
Unlike the OAuth flow which requires the use of a web browser, the native Sign in with Google flow on Android uses the operating system's built-in functionalities to prompt the user for consent. Note that native sign-in has been rebranded as One Tap sign-in on Android by Google, which you should not confuse with One Tap sign in for web, as mentioned below.
When the user provides consent, Google issues an identity token (commonly abbreviated as ID token) that is then sent to your project's Supabase Auth server. When valid, a new user session is started by issuing an access and refresh token from Supabase Auth.

ios 프로젝트 xcode로 열기

cocoapods를 사용하는 경우 xcworkspace를 열어야함
cd ios xed .
JSON
복사
iOS에서도 webClientId가 필요해!
Google OAuth를 React Native에서 구현할 때 iOS와 Android는 서로 다른 clientId를 사용하고, iOS에서도 webClientId가 필요할 수 있어.
GoogleSignin.configure({ iosClientId: 'iOS-CLIENT-ID.apps.googleusercontent.com', webClientId: 'WEB-CLIENT-ID.apps.googleusercontent.com', // ✅ iOS에서도 필요 });
JavaScript
복사
네, expo prebuild를 실행한 이후에도 Expo SDK의 대부분의 기능을 사용할 수 있습니다.
expo prebuild 후에도 사용할 수 있는 Expo SDK 기능
Expo의 많은 패키지는 React Native의 네이티브 모듈로 래핑되어 있기 때문에 여전히 사용할 수 있습니다.
예를 들어, expo-camera 같은 모듈도 네이티브 코드가 포함된 라이브러리이지만, expo prebuild가 필요한 설정을 자동으로 생성해 주므로 사용할 수 있습니다.
주의할 점
1. Expo Go에서 실행 불가
expo prebuild를 하면 Managed Workflow에서 Bare Workflow로 전환됩니다.
Expo Go에서는 일부 Expo SDK가 동작하지 않을 수 있습니다. 대신 **빌드된 앱 또는 개발용 클라이언트(Dev Client)**를 사용해야 합니다.
해결 방법: expo-dev-client를 설치해서 Expo Go 대신 사용할 수 있습니다.
npx expo install expo-dev-client
2. 수동으로 네이티브 설정이 필요할 수 있음
일부 Expo SDK 패키지는 expo prebuild 후에도 추가적인 네이티브 설정이 필요할 수 있습니다.
예를 들어 expo-camera를 사용할 경우 AndroidManifest.xml에서 권한을 확인해야 할 수도 있습니다.
3. Expo SDK 버전에 따라 호환성 문제 발생 가능
expo prebuild 후에는 Expo SDK 버전과 네이티브 프로젝트(예: Android/iOS) 간의 호환성이 깨질 수 있습니다.
따라서, Expo SDK 버전을 주의 깊게 관리해야 합니다.
결론
expo prebuild 후에도 Expo SDK의 대부분 기능을 사용할 수 있습니다.
다만 Expo Go 대신 expo-dev-client를 사용해야 하고, 일부 네이티브 설정이 필요할 수 있습니다.
만약 Expo SDK가 완전히 지원되지 않는다면, 일반 React Native 라이브러리를 직접 추가해서 사용하는 방법도 고려해야 합니다.
Expo의 Managed Workflow vs Bare Workflow 차이점
Expo에는 크게 Managed Workflow와 Bare Workflow 두 가지가 있습니다.
특징
Managed Workflow
Bare Workflow
Expo SDK 사용
대부분 사용 가능
사용 가능, 하지만 일부는 직접 설정 필요
Expo Go 지원
지원
미지원 (빌드된 앱 사용)
네이티브 코드 접근 (Android/iOS)
불가능
가능
네이티브 패키지 추가
npx expo install만 가능
직접 react-native link 또는 pod install 가능
빌드 방식
Expo 서버 (expo build / eas build)
직접 Xcode, Android Studio 사용 가능
업데이트 용이성
expo update로 쉽게 가능
직접 관리 필요
사용 대상
빠르게 개발하고 싶을 때
네이티브 코드 수정이 필요할 때
Managed Workflow
“Expo가 모든 것을 관리해줌”
Expo의 기본 모드로, 네이티브 코드(Android/iOS)를 직접 수정할 수 없음.
expo install을 이용해 Expo SDK 패키지를 쉽게 추가 가능.
Expo Go 앱에서 바로 실행 가능.
expo build, expo start, expo update 명령어로 간편하게 관리.
단점: 네이티브 코드 커스텀이 어렵고, 일부 라이브러리는 지원되지 않음.
언제 사용해야 할까?
React Native만으로 개발이 가능할 때.
네이티브 코드 수정 없이 빠르게 앱을 만들고 싶을 때.
Expo Go를 사용하면서 쉽게 테스트하고 싶을 때.
Bare Workflow
“네이티브 프로젝트를 직접 관리”
Expo가 아닌 React Native 프로젝트처럼 네이티브 코드를 직접 수정 가능.
expo prebuild를 실행하면 Expo가 네이티브 프로젝트를 생성해 줌.
Expo Go를 사용할 수 없고, 빌드된 앱에서만 실행 가능.
npx react-native run-android / run-ios 등의 명령어로 빌드해야 함.
네이티브 모듈 추가 시 pod install (iOS) / gradle sync (Android) 필요.
언제 사용해야 할까?
Expo에서 지원하지 않는 네이티브 패키지를 사용해야 할 때.
iOS/Android 네이티브 코드를 직접 수정해야 할 때.
Expo Go 없이 개발이 가능할 때.
expo prebuild가 하는 역할은?
Managed → Bare Workflow로 전환하는 과정
expo prebuild를 실행하면, Expo가 Android/iOS 폴더를 생성하고 네이티브 설정을 자동으로 해 줍니다.
즉, Managed Workflow에서 Bare Workflow로 전환되며, Expo Go 사용이 불가능해집니다.
하지만 Expo SDK를 계속 사용할 수 있으며, 일부 Expo 기능도 유지됨!
이 후에는 eas build 또는 직접 네이티브 빌드를 해야 함.
결론: 어떤 걸 선택해야 할까?
Expo Go 사용 & 빠른 개발 → Managed Workflow
네이티브 코드 수정 & 커스텀 기능 필요 → Bare Workflow
Expo SDK를 쓰면서 네이티브 코드도 수정해야 함 → expo prebuild 후 Bare Workflow 사용
expo prebuild를 실행하면 되돌리기 어렵기 때문에 신중하게 결정해야 합니다!

3/6

네이티브 코드 변경한게 아니라 app.json같은거만 변경한거면 안심하고 prebuild하면 된다.
react native는 환경변수를 .env에서 직접 가져올수없음 라이브러리를 사용해야함
// 잘 나오는지 확인 echo $GOOGLE_CLOUD_CLIENT_ID_IOS
JavaScript
복사

react-native-dotnev

TypeScript와 함께 사용하기 위해 .env 파일의 타입을 지정하는 .env.d.ts 파일을 생성합니다.
//babel.config.js module.exports = { presets: ['module:metro-react-native-babel-preset'], plugins: [ [ 'module:react-native-dotenv', { moduleName: '@env', path: '.env', }, ], ], };
JavaScript
복사
ios google signin 되는지 확인
OAuth구성으로 가서 테스트 유저 등록하기

드디어 구글 로그인 성공!!!!

3/18

DiffusionBee

DiffusionBee는 Stable Diffusion을 쉽게 사용할 수 있도록 만든 로컬 AI 이미지 생성 프로그램이야.
Mac에서 실행할 수 있도록 최적화되어 있으며, 별도의 코드 실행 없이 GUI(그래픽 인터페이스)로 텍스트에서 이미지 생성 (Text-to-Image), 이미지 수정 (Inpainting), 업스케일링 같은 기능을 제공해.
특징
무료 & 오픈소스
로컬에서 실행 (인터넷 연결 필요 없음)
Mac(M1/M2)에서 Apple Silicon GPU 가속 지원
Stable Diffusion 모델 쉽게 다운로드 및 사용 가능

SDXL (Stable Diffusion XL)

SDXL은 Stable Diffusion XL의 줄임말로, Stability AI에서 개발한 Stable Diffusion 모델의 업그레이드 버전이야.
기존 Stable Diffusion 1.5나 2.1보다 더 높은 화질과 디테일을 제공하고, 텍스트 프롬프트 해석 능력이 향상되었어.

1. 하드웨어 성능 체크

Stable Diffusion은 VRAM이 많이 필요한 모델이야.
GPU VRAM 확인: 최소 4GB, 권장 8GB 이상 (16GB 이상이면 더 좋음)
CUDA/ROCm 지원 확인: NVIDIA GPU의 경우 CUDA 드라이버가 최신인지 확인
Xformers 사용: 메모리 최적화 및 속도 향상을 위해 -xformers 옵션 활성화

2. 모델 및 설정 개선

1.
최신 모델 사용
기본적으로 v1.4, v1.5 모델은 품질이 떨어질 수 있어.
SDXL, Anything-v4.5, DreamShaper, Realistic Vision 같은 모델을 사용해보자.
Hugging FaceCivitAI에서 최신 모델을 다운로드 가능.
2.
CFG Scale 조정
CFG Scale이 너무 높으면 왜곡될 수 있음.
CFG Scale을 7~10 사이로 설정하는 게 일반적.
3.
Sampling Method 조정
Euler a, DPM++ 2M Karras, DPM++ SDE 등이 고품질 샘플링에 적합.
4.
Step 증가
50~100 스텝으로 설정해보면 퀄리티가 개선될 수 있음.
하지만 너무 많으면 과적합되거나 처리 속도가 느려짐.

3. 추가적인 개선 방법

1.
LoRA(저용량 훈련 모델) 활용
인물 생성이 잘 안되면 LoRA 모델을 추가로 다운로드해서 활용.
LoRA(Low-Rank Adaptation)는 Stable Diffusion 같은 대형 모델을 가볍게 튜닝할 수 있는 기술이야.
쉽게 말해, 원래의 무거운 모델을 직접 학습시키지 않고, 적은 데이터와 적은 연산으로 특정 스타일이나 특징을 추가할 수 있는 방법이라고 보면 돼.

LoRA의 핵심 개념

1.
기존 모델을 직접 수정하지 않음
원래 Stable Diffusion 모델(예: v1.5, SDXL)을 변경하지 않고, 작은 보조 모델을 추가하는 방식이야.
즉, LoRA는 원본 모델의 가중치를 건드리지 않고 새로운 정보를 덧씌우는 방식이라 가볍고 빠름.
2.
VRAM과 연산량을 크게 줄여줌
원래 Stable Diffusion을 직접 학습하려면 VRAM이 최소 24GB 이상 필요하지만, LoRA를 사용하면 8GB 이하의 VRAM에서도 학습 가능.
3.
스타일, 특정 인물, 특정 개념을 빠르게 학습 가능
특정 그림체, 연예인, 애니메이션 스타일, 캐릭터 디자인 등을 LoRA로 학습해서 적용 가능.
예를 들어, 지브리 스타일, 실사 같은 얼굴, 특정 유명인의 얼굴 같은 LoRA를 다운로드해서 바로 적용 가능.\

3/23

리눅스 명령어의 tee 명령어는 표준 입력에서 읽은 내용을 표준 출력에도 사용하면서 파일에 저장하는 두 가지를 동시에 사용하는 명령어입니다.
sudo apt install net-tools
ifconfig
ssh username@ip

3/29

react, svelt ,가상돔