옵시디언에서 이미지 조절하기

노션에 이어 옵시디언의 필요성도 느끼게 되었다. 노션은 주로 데이터베이스 용도로 사용하고, 옵시디언은 떠오르는 생각들이 휘발되지 않도록 기록하는 용도로 써보려 한다.

🧪 시도한 내용

처음에는 Velog에서 사용했던 방식처럼 <img src='' width="50%"/> 형태를 시도해보려 했다. 하지만 옵시디언에서는 이미지를 직접 업로드하여 사용하는 방식이라 외부 링크가 아닌 파일 자체를 다루기 때문에 이 방법은 적용되지 않는다.

🔍 정리해두기

옵시디언에서 이미지를 넣을 때는 두 가지 방법이 있다. 첫 번째는 아래와 같이 위키링크 ![[파일 경로 또는 이미지 이름]] 를 사용한다.![옵시디언 설정->파일 및 링크->[[wikilink]]사용 옵션이 있다.|](https://velog.velcdn.com/images/6_jamong/post/6c0678c0-3141-4382-8c58-89a098542d50/image.png)두 번째는 일반적인 Markdown 형식 ![대체 텍스트](파일 경로 또는 이미지 이름)이다.

그리고 두 방법 모두 이미지 크기를 조절하는 방식은 유사하다.

1. Wikilink 에서 이미지 사이즈 조절하는 방법

![[파일 경로 또는 이미지 이름|100]] ![[파일 경로 또는 이미지 이름|100x100]]

2. Markdown 에서 이미지 사이즈 조절하는 방법

![|100](파일 경로 또는 이미지 이름) ![|100x100](파일 경로 또는 이미지 이름)

참고로 내가 자주 쓰던 30% 50%로 이미지를 조절하던 방식은 적용이 안 된다.

🛠️ 조절	💡 결과

🧰 이것도 괜찮다 : 플러그인 사용하기

옵시디언의 기본 편집 모드에서는 이미지 미리보기가 표시되지 않는다. 이를 해결하기 위해 Image in Editor 플러그인을 사용했고, 반복적인 사이즈 조절 입력이 번거로워 Image Converter 플러그인도 함께 활용했다.

에디터에서 미리보기 : Image In Editor

이미지 조절 쉽게 하기 : Image Converter

설정 -> 커뮤니티 플러그인 -> 탐색 에서 찾을 수 있다.

두 플러그인을 함께 사용해야 에디터에서 이미지를 보면서 조절할 수 있을 것 같다. 설정을 마친 뒤에는 이미지 위에 핸들이 생겨 쉽게 크기를 조절할 수 있다.

☁️ 오늘도 하나 배웠다

많이 써보진 않았지만 옵시디언은 기록해서 '남겨둔다'는 느낌이 강하다. 노션은 꾸준히 열어보게 되지만 옵시디언은 지금까지 발자취를 남겨두는 느낌. 떠오르는 생각이 많은 나에게는 좋은 툴이 될 것 같다. 또 플러그인이 다양해서 잘 맞는 걸 찾는 재미도 있다. 더 잘 사용해봐야겠다.

🚀 다음은?

지금 노션에 스크랩한 정보들을 모아두는 데이터베이스가 있는데 이걸 옵시디언으로 옮겨서 시각화하고 싶다. 그래프 뷰라는 거 너무너무 매력적이다.

🏫 내가 공부한 글

이 글을 정리하는 데 참고하고 배운 소중한 자료들입니다.

• 옵시디언에서 이미지 조절하기 관련
• 이미지 플러그인 관련

여러 개의 인자를 받는 함수를 단일 인자를 받는 함수들의 함수열로 바꾸는 기법 -> 여러 인자를 한 번에 받도록 하는 게 아니라 하나씩 차례차례 받도록 하는 것.

//커링 적용하지 않음
function log(prefix, message){
console.log(`${prefix}:${message}`);
}
function infoLog(message){
    log('INFO', message);
}
function errorLog(message){
    log('ERROR', message);
}
infoLog('~');
errorLog('~');

//커링 적용
const log = prefix => message => console.log(`${prefix}:${message}`);

const infoLog = log('INFO');
const errorLog = log('ERROR');

infoLog('~');
errorLog('~');

• 간결함과 직관성 ↑
• 매개변수들의 개수와 갈래가 많아질수록 차이가 뚜렷해진다.

참고 https://ko.javascript.info/currying-partials https://www.youtube.com/watch?v=PRLWfdCFQTQ

윈도우 노트북으로도 프로젝트를 하고 싶어서 vscode를 설치하고 터미널은 맥에서 쓰던 zsh로 바꾸기 위한 기록. 우분투 설치 -> zsh 설치 -> 테마 설정 📎 zsh 깃허브 📎 참고 블로그 📎 Powerlevel10k 테마 참고 사이트

1. 우분투 설치

wsl --install -> wsl --install -d ubuntu

wsl --install

나 같은 경우 이렇게 떴는데 이거 그래서 깔린 건지 아닌 건지 고민하다가 현재 wsl버전을 확인하면 될 것 같아서

wsl -l -v

위 코드를 입력해보면 사이트는 여기로 이어진다. (나는 설치한 적이 없는데 왜 작동이 안 될까. 배포판 목록을 보고 우분투를 깔기로 했다.)

wsl --install -d ubuntu

다른 글을 보고 microsoft store에서 우분투를 설치해놨더니 자동으로 뜬다.

2. 설정하기

이처럼 뜨면 닉네임과 비밀번호를 설정해준다. 설치 성공 메시지를 보고 다시 wsl 버전을 확인해본다. 잘 설치됐다!

3. zsh 설치

sudo apt install zsh
chsh -s /usr/bin/zsh

zsh를 설치한 후 기본 쉘을 zsh로 변경해준다. 터미널을 껐다 켜고 이런 내용이 보이면 2를 눌러준다.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

4. vscode에서 기본 터미널 설정

터미널을 열고 기본 프로필 선택에서 wsl을 설정해주면 된다.

5. 테마 설정하기

테마는 zsh 깃허브에서 구경할 수 있는데 테마 구성을 설치 마법사처럼 해준다는 Powerlevel10k 을 사용하기로 했다. ( 원하는 테마로 설정하는 법 참고 블로그 ) 순서는 아래와 같다. 폰트 4개를 설치해주고 터미널에 입력해준다.

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ~/powerlevel10k
echo 'source ~/powerlevel10k/powerlevel10k.zsh-theme' >>~/.zshrc

source ~/.zshrc

이후 터미널을 껐다 켜면 마법사가 실행된다. 원하는 스타일대로 입력해나가면 된다.

다 지정하고 나서 스타일을 다시 바꾸고 싶다! 싶으면 입력하면 된다.

 p10k configure

마음에 드는 스타일로 변경 완료! 🥰

만들고 싶은 홈페이지가 있어 익숙하게 리액트로 세팅하려다가 문득 리액트를 사용하는 근본적 이유가 뭐지? 에서 시작된 perplexity를 이용한 의문 해결을 기록

리액트 -> 리액트의 장점 -> 선언형 프로그래밍 스타일 -> UI를 어떻게 동작해야 하는지가 아닌 UI가 어떤 상태에서 어떤 모습으로 있는가 -> 그럼 전자는 무엇인가 -> 명령형 프로그래밍 스타일 -> 명령형은 움직이는 과정을 상세히 <How> 선언형은 어떤 결과를 얻고자 하는지 <What> (예시) 명령형은 for문으로 반복문과 상태 변경을 사용해 작업 과정을 명시, 선언형은 map을 사용하여 내부 동작은 추상화하면서 최종 결과만 선언 -> 결국 같은 결과값을 가지지만 프로그래밍 스타일에 따른 차이점 파악(명령형 : 복잡한 알고리즘, 세밀한 제어 | 선언형 : UI구성, 데이터 변환 등 높은 추상화가 유리할 때) -> for과 map을 사용할 때 결과는 같은데 효율을 따지자면 map이 더 좋은 것 아닌가? -> 사용하는 상황에 따라서 다르다. 성능과 코드의 가독성 측면에서 차이가 있음.

(성능) map은 배열의 각 요소에 대해 콜백 함수를 실행하고 새로운 배열을 반환한다. 내부적으로 추가 작업이 포함되어 있어서 큰 데이터셋에서는 for보다 느릴 수 있다. (새 배열을 생성하는 시간) for 루프는 배열의 인덱스를 직접 접근해 수행하므로, 메모리 복사나 새 배열 생성 없이 동작하기 때문에 데이터셋 클 수록 성능 차이 확연.

(코드 가독성과 유지보수성) map은 간결함. 뭘 수행하는지 직관적으로 이해 가능

const doubled = arr.map(num => num * 2); 

for루프는 더 많은 제어가 가능하고 복잡한 작업 처리하기에 적합(조건부 반복이나 특정 요소 건너뛰기)

const doubled = [];
for (let i = 0; i < arr.length; i++) {
  if (arr[i] > 10) continue; // 특정 조건 건너뛰기
  doubled.push(arr[i] * 2);
}

따라서 각각 필요한 상황이 다름

map

• 새 배열을 생성해야 할 때
• 데이터 변환 작업이 간단하고 선언적으로 표현할 수 있을 때
• 코드 가독성과 유지보수가 중요한 경우

for

• 데이터셋이 클 때 (성능 최적화 필요)
• 반복 중 특정 조건을 처리하거나 중단해야 할 때
• 기존 배열을 수정하거나 복잡한 작업이 필요한 경우

이쯤 왔을 때 내가 어쩌다 map과 for의 쓰임 차이까지 왔는지 되돌아가기가 필요했다. 내가 map과 for의 차이점(사용처)을 이해하고자 한 것은 map이 간결한데 for보다 좋은 거 아님? 이었다. 여기서 뭔가 처음 궁금했던 점과 초점이 틀려졌음 느꼈다. 리액트는 선언형을 중요시했고 선언형의 대표적인 코드 예시는 map. 그러니까 map의 특성인 간결함에 있음. map이 for보다 간단한 데이터셋에 쓰인다는 사용처에 초점이 아님.

내 이해의 오류 : 명령형과 선언형 프로그래밍 스타일이 대치되는 줄

명령형과 선언형 프로그래밍 '스타일'의 차이이며 리액트는 선언형 프로그래밍 스타일을 강조할 뿐 명령형 프로그래밍 스타일이 안 쓰이는 게 아니다. 강조의 차이일 뿐 특정 상황에서는 명령형 접근이 더 적합할 수 있으며 이를 통해 복잡한 로직이나 성능 최적화를 할 수 있다. 상황에 따라 적절히 선택하면 되는 것.

개념을 하나 이해하려다 보면 자꾸 꼬리에 꼬리를 물고 늘어지게 된다. 이 습관이 속도를 참 느리게 만들긴 하지만 사실 정말 재밌다. 게임을 하는 기분. 예전에는 하나하나 서치해서 찾아야 했기에 지금보다 더 느렸지만 지금은 gpt나 perplexity를 통해 빠르게 묻고 빠르게 확인하고 필요한 부분을 따로 서치해서 확인하는 등 정말 잘 활용하고 있는 것 같다.

코드 비교로 알아보기

React (선언형)

//우리는 이 버튼을 보여줘, 그리고 클릭되면 handleClick 실행해줘 라고 선언한다.
function handleClick() {
  alert('Button clicked!');
}

<button onClick={handleClick}>Click me</button>

JS (명령형)

//우리가 버튼을 어떻게 만들고, 어떻게 붙이고, 어떻게 이벤트를 연결할지 명령식으로 하나하나 직접 써야 한다.
<!-- index.html -->
<body>
  <div id="app"></div>

  <script>
    function handleClick() {
      alert('Button clicked!');
    }

    // 1. 요소를 만들고
    const button = document.createElement('button');

    // 2. 텍스트를 추가하고
    button.textContent = 'Click me';

    // 3. 클릭 이벤트 핸들러를 붙이고
    button.addEventListener('click', handleClick);

    // 4. DOM에 추가하기
    document.getElementById('app').appendChild(button);
  </script>
</body>

결론 : React는 선언형 프로그램이 스타일이기 때문에 상태에 따라 UI 업데이트가 쉽고 직관적이다.

하반기에 다양한 컨퍼런스들이 개최되고 마무리되면서 유튜브에도 영상들이 올라오고 있다. 오늘은 당근 테크 밋업 영상 중 김태희 개발자님의 아니, 여기도 웹뷰였어요? 라는 주제의 영상을 보고 알게 된 점이나 재밌게 본 점을 정리했다.

YOUTUBE

&nbsp 영상은 당근 앱의 2탭의 동네생활에서 피드나 글 쓰기, 수정 등의 화면이 전부 웹뷰 기반이다!로 시작한다. 그리고 SSR, CSR의 차이, 웹뷰에 대한 이야기, 새로고침을 넣는데 생기는 다양한 이슈들에 대한 얘기를 들을 수 있었다.

&nbsp 웹뷰라는 건 간단히 말해 앱에서 보여지는 웹사이트다. 어플의 경우 어떤 기능을 추가하거나 실험을 하게 되면 사용자가 앱을 업데이트해야 한다. 하지만 웹뷰를 도입할 경우 특별한 업데이트 없이도 추가된 기능을 사용할 수 있다는 장점이 있다. 당근 동네생활에서도 역시 다양한 실험을 해보고 싶어서 웹뷰 전환을 결정했다.

&nbsp 웹뷰로 전환할 경우 아무래도 네이티브보다 느릴 수밖에 없는데 CSR WebApp 에서 문제가 될만한 부분은 ...

CDN, 번들 사이즈 문제

CDN이 외국을 다녀오는 경우, 번들을 받는데 인터넷이 느릴 경우인데 이 문제의 경우 번들은 lazy loading으로 쪼개면 되고 CDN 문제는 AWS cloudfrond/s3 기반으로 배포되도록 직접 빌드 파이프라인을 구축하는 방법으로 리젼 문제를 해결할 수 있다고 한다. ( 후자 무슨 말인지 이해 못 함 )

API 호출 문제

&nbsp 기존 CSR 방식의 경우 화면을 그릴 준비가 다 된 후에 API를 호출하는데 사용자 네트워크 상황에 따라서 API요청과 응답 자체가 느릴 수 있었다.

CSR의 이런 문제점 때문에 네이티브만한 성능이 나오지 않을 것 같아서 SSR 도입을 결정. SSR을 도입하는데 next.js를 쓰는 게 아니라 fastify + vite + React DOM Server 기반으로 직접 구축했다고 한다. next.js의 경우 versel이랑 강결합되어 있는 편인데 사내에서 versel을 안 쓰려고 하는 추세였다구...

CSR과 SSR의 동작 차이

이 부분을 들으면서 그동안 이 둘의 차이를 이해하려고 찾아봤던 자료들 중 제일 이해가 잘 가는 것 같았다. 브라우저가 API를 직접 부르느냐 아니냐의 큰 차이점. CSR : js, css 다 다운받고 렌더링 하면서 API를 브라우저가 호출. (cross domain) SSR : 렌더링에 필요한 API 요청 서버에서 하고 나서 렌더링 된 HTML 갖다줌.

&nbsp 여기서 API호출 cross domain 같은 경우 이거 쓸 수 있냐는 물음이 무조건 발생하는데 이런 CORS 관련 preflight 요청이 100~200ms 정도의 지연이 발생한다고 한다. API 호출 하나의 경우 이 정도인데 만약 요청할 API 가 많다? 그럼 더 많은 지연이 발생하는 것. 이런 점이 없다는 게 SSR의 장점이기도 하고 API 호출을 서버에서 한다는 부분에서 사용자의 네트워크 환경을 덜 탄다는 장점도 있다. CSR에서 API 하나를 부르다가 다른 걸 부르는데 네트워크 상태가 안 좋아지면서 느려지면.. 영원히.. 화면이 안 떠..

&nbsp 다만 이렇게 API를 부르다가 하나가 느린 경우더라도 CSR의 경우 로딩스피너 같은 UI를 통해서 사용자에게 아직 로딩중이다라고 인식시킬 수 있는 반면 SSR의 경우 API 요청이 다 끝나야 화면이 떠서 오히려 CSR보다 늦게 뜰 수도 있다고 한다.

_이쯤에서 내 표정 : 이거 완전 도르마무 아녀.😮 _

&nbsp 근데 당근에서는 이걸 해결하려고 Streaming SSR을 도입했다고 한다. API 호출 때문에 화면이 늦게 뜨는 걸 대비하기 위해서 화면을 한 번에 그리는 게 아니라 쪼개서!! 그리는 방식이라고 한다. API 호출과 관련 없는 부분은 호출하기 전에 그려버리고 외부 요소에 의해서 렌더링 되는 부분들은 차근차근 그리는 거라고. Suspense 로 묶이지 않은 부분을 셸이라고 부르는데 셸이 먼저 그려지고 차근차근 Suspense 로 묶인 부분들이 스트리밍되면서 렌더링된다고 한다. 결국 CSR에서 로딩스피너를 보여주던 경험가 비슷해진다고. 신기하다.😮😮

SSR을 사용하게 되면? 해야한다. 서버 모니터링

&nbsp CSR의 경우 별도의 Application Server 가 없어서 모니터링 해야 하는 범위가 적은 편인데 SSR을 하게 되면 별도의 요청을 처리하는 서버가 있을 거고 그럼 서버의 로그를 봐야 하고 트래픽에 따라서 CPU나 메모리가 안 밀리고 있는지 뭐 그런 걸 확인해줘야 한다고 한다. ( 무슨 소리쥐... 😯 ) 아무튼 SSR의 도입을 하려면 고민해야 할 부분이 있다는 점인 건 알겠다.

뜻밖의 문제

&nbsp 안드로이드 사용자로서 앱을 껐다 키는게 일상이니까 웹뷰의 새로운 버전이 그냥! 자연스럽게 전파될 거라고 생각했는데 IOS 사용자의 경우 끄는 게 아니라 그냥 백그라운드에 넣어놨다가 띄워서 쓰는 게 일반적이라 전파가 안 되는 문제가 발생했다고. 오... 그러네.

&nbsp 이 부분은 내부에서 버전의 값을 전역변수로 갖고 있게 한 다음에 내가 쓰고 있는 버전과 서버가 주는 버전이 같은지 다른지 체크해서 다르면 새로고침을 유도하는 스낵바를 띄우는 방법을 사용했다고 한다. 근데 여기서 발생할 수 있는 문제가 사용자가 만약 이때 네트워크가 안 좋다면?? 먹통이 될 거라고. (웹뷰를 사용하게 될 경우 지하철이나 엘리베이트 같은 네트워크가 불안정한 대응을 해줘야 한다고 한다.) 그래서 온라인, 오프라인을 확인하는 훅을 만들어서 오프라인일 경우 메시지를 주는 걸 택했다고 한다.

와, 제대로 알아들을 수 있던 부분 반, 아직 잘 모르겠는 부분 반이긴 했지만 당근 실무에서 사용자에게 더 좋은 경험을 주기 위해 우당탕탕 웹뷰, SSR 도입기를 들으니까 마냥 재미있었다.

CSR과 SSR의 API 호출 차이점, 앱의 경우 안드로이드, IOS 유저들의 행동 차이로도 만들어질 수 있는 문제점이 존재한다는 사실, 그리고 내가 모르는 부분들이 아직도 무궁무진하다는 현실도! 30분 간의 영상이었지만 순식간에 지나갔다. 다른 얘기들도 즐겁게 들어보고 싶다.

리드미에서 이미지 넣고 스타일 주는데 순간 width='50%' 와 style='width:50%'의 두 스타일을 지정하는 방식이 머리에서 섞여서 <img width:'50%' ~/> 해놓고 왜 안 되지. 하고 있었다. 😂 생각해보면 스타일을 줄 때 참 많은 경우가 있다. = 할당 연산자를 통해 스타일 속성에 값을 할당하는 방법 style 속성에 css 키값 구조로 스타일을 지정하는 방식. 그리고 따옴표, 중괄호, 템플릿리터럴(백틱) 각각을 사용하면서 값을 할당하는 차이점을 이번 기회에 정리해두려고 한다.

1. = 와 :

= 할당

= 는 값을 변수에 할당할 때 사용한다. 변수 선언 혹은 속성 값을 설정할 때

const color = "red"; 
let size = "large";
<div id="main" className="container"></div>

: 지정

: 는 객체에서 속성에 값을 할당할 때 사용한다.

const styles = {
  color: "green",        
  fontSize: "16px",
};

<div style={{ color: "green", fontSize: "16px" }}>JAMONG</div>

✅ = 는 값 할당 ✅ : 는 키값 매칭

width:'50%' 와 style='width:50%' 전자는 HTML 태그가 지원하는 속성에 값을 지정하는 방식이고 후자는 CSS로 스타일을 지정하는 방식이라 모든 요소에 적용이 가능하다. 태그 속성으로 스타일을 주느냐 style 속성으로 스타일을 주느냐의 차이. 전자는 태그가 기본적으로 제공하는 스타일 속성이 제한적, 후자는 다양한 스타일링을 할 수 있음.

style='width:50%'와 style={{width:50%}} 전자는 HTML의 속성으로 문자열을 받는 방식(여러 속성을 주고 싶을 땐 ; 로 구분), 후자는 React의 속성으로 객체를 받는 방식(, 로 구분).

2. '' 와 {} 와 `` & ${}

'' 따옴표

HTML 속성 값이나 문자열로 표현할 때 사용. + 정적

<div style="color: red;">JAMONG</div> 

{} 중괄호

스타일 객체를 전달하거나 동적인 값을 사용할 때 사용 React의 style 속성은 HTML의 style 속성과 달리 객체를 기대한다.

<div style={{ color: "red", fontSize: "16px" }}>JAMONG</div>

``& ${} 백틱과 템플릿 리터럴

동적 값을 포함할 수 있는 문자열이 필요할 때 주로 사용

const color = "green";
<div style={{ color: `${color}` }}>JAMONG</div>

회고

문득 이런 게 헷갈렸던 근본적인 이유는 리액트를 쓰면서 HTML에서 태그에 스타일링을 주는 방식이 JSX에서 스타일링을 주는 방식과 달라서인 것 같다. 기본적인 개념을 더 잘 익히는 계기가 됐다.

2일차 : 컴포넌트의 종류와 역할 / 컴포넌트 분할의 타이밍과 기준 / 컴포넌트의 제 역할 찾기 / 깔끔하고 조합 가능한 컴포넌트 / 실무에서 자주 사용하는 최적화 케이스

(withFooter) ㄴ(example) ㄴlayout

example 라우터를 타는 애들은 layout을 타고 가는데 이렇게 푸터가 있는 페이지, 헤더가 있는 페이지 이런 식으로 폴더링을 할 수 있다. UI 상태 같은 걸 next.js 는 라우터로 분리해서 할 수 있도록 되어 있다.

컴포넌트 구조 안에는 이런 식으로. common - 공통적 movie - 관심사 별로 layout login

쿠키 / 로컬 스토리지 / 세션 스토리지 Context API vs Recoil

Q. 사용자인증 관련해서 로컬 스토리지에도 넣어도 되지 않나 싶었는데 httpOnly로 안정성을 위해서 쿠키에 넣는 걸까요? A. 유저가 로컬에 영원히 인증 상태로 남을 수는 없음. 쿠키의 expires 라는 만료일시를 위해서 쿠키에 넣는 것. + httpOnly, secure를 이용해 안전성을 챙김.

주로 쓰는 쿠키 옵션! httpOnly : true // XSS 방지 secure : true // HTTPS 만 허용 sameSite : 'strict' // CSRF 방지 path : '/' // 쿠키 사용 경로 domain '.example.com' // 쿠키 사용 도메인

로컬 - 테마, 언어 선택 같은 데 사용 세션 - 이번에 다시 보지 않기 로 사용

모달용 portal 컴포넌트

1. ssr 대응 : mounted 상태를 통해 클라이언트 사이드 렌더링 보장 (하이드레이션 에러 해결) document. body가 없는 서버 환경에서 오류 방지

상황 : 부모 요소에 overflow : hidden 을 쓰다 보면 자식 요소에 focus시 보여지는 outline이 잘려지는 문제가 종종 발생하는 걸 발견.

focus시 outline이 가려진다.

🚨 이렇게 보이던 키보드 포커스 시 outline이 🧐 부모 요소의 overflow : hidden을 끄면! 무엇에 의한 문제인지는 알았고 포커스 시 어디에 포커싱됐는지 완전히는 아니어도 보이긴 보이기 때문에 이게 문제가 되려나? 싶었다.

이 점은 문제가 된다.

서칭 결과 + 캠프 질의응답에 질의를 남겨둔 결과 답변은 모두 문제가 된다. 였다.

w3c : https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html 이런 focus 이슈는 WCAG2.2 성공기준 2.4.7 Focus Visible과 관련이 있다. 해당 문서에 가면 성공 기준이라는 게 있는데 이 성공 기준의 목적은 사용자가 키보드 포커스가 어디에 있는지 알아야 한다는 것이다. 그래서 지금처럼 포커싱이 보여지는 부분의 일부가 가려진다면 누군가는 잘 못 알아볼 수도 있기 때문에 문제가 될 수도 있다.

overflow:hidden으로 이런 문제가 발생하는 경우가 빈번하다고 한다. 일부가 잘리기도 하지만 초점 전체가 안 보이기도 한다고.

그래서 더 좋은 접근성을 위해서 Focus Appearance 에 대해서 w3c : https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance 이 문서를 이어서 볼 수 있었다. ❗️ 포커스 상태에서 표시기의 영역은 최소한 컴포넌트의 2 픽셀 두께 테두리 영역만큼 커야 함. 결국 모든 면이 잘 보여야 한다는 뜻으로 해석된다.

방법은 세 가지!

1. overflow:hidden 제거

2. outline-offset 네거티브 값 사용

3. box-shadow 또는 가상 요소로 포커스 표시

이 상태에서 overflow:hidden을 제거하는 건 다른 css가 엉망이 되거나 스와이퍼를 쓴 경우 다 흘러나갈 수 있기 때문에 2번 혹은 3번을 써야될 것 같다.

outline

.element:focus {
  outline: 2px solid blue;
  outline-offset: -2px; /* 아웃라인을 요소 안쪽으로 그림 */
}

그런데 outline은 radius가 안 통해서 아쉬운 점이 있다. 네모네모... 그래서 대신 box-shadow를 사용한 스타일링도 좋은 선택이 될 수 있다고 한다. border-radius 속성과 함께 사용하여 focus 시 둥근 모서리 형태의 디자인으로 커스터마이징 할 수 있다는 점이 좋았다. + 여기 더해서 focus-visible 선택자에 대한 내용도 추천받았다.

:focus 와 :focus-visible을 따로 구분해주는 이유는

• :focus 모든 포커스 상황
• :focus-visible 키보드 탐색 시 포커스

키보드의 포커스의 경우 확실히 보여주기 위해 명확한 표시를 해주는 데 터치나 마우스로 선택했을 때 키보드용 포커싱을 보여주면 그 명확한 표시가 깜빡!하고 나타나며 오히려 불편함을 줄 수 있기 때문이다.

.element:focus {
  /* 모든 포커스 상황 */
  background: yellow;
}

.element:focus-visible {
  /* 키보드 탐색 시에만 */
  outline: 2px solid blue;
}

이런 식으로 활용할 수 있다.

앞으로 overflow:hidden 을 사용하게 됐을 때 이런 점을 좀 더 꼼꼼히 체크할 수 있을 것 같다. focus-visible 선택자는 이번에 알게 되었는데 다른 곳에서도 더 유용히 사용할 수 있을 것 같다.

나는 앱을 사용할 때 제일 좋아하는 게 위젯인데 Expo를 통해 React Native를 공부하는 요즘 위젯은 네이티브랑 밀접하다던데 Expo에서도 사용할 수 있나? 싶어서 찾아보던 과정이다.

1. 상황 목표: Expo를 사용하여 앱을 개발 중이며, 앱에 홈 화면 위젯 기능을 추가하고 싶음! 제약: Expo 에서는 네이티브 코드 수정을 지원하지 않아, iOS의 WidgetKit이나 Android의 AppWidgetProvider 같은 네이티브 위젯 API를 사용할 수 없음.

2. 고민 옵션 1: Expo Bare Workflow 또는 EAS Config Plugins로 위젯 기능을 추가해보는 방법 장점: Expo SDK 기능을 대부분 그대로 사용 가능. 단점: Expo 관리형 워크플로우에서 벗어나고, 위젯을 구현하기 위해 복잡한 설정이 필요할 수 있음. 옵션 2: React Native CLI로 전환 장점: Expo의 제한 없이 네이티브 기능을 자유롭게 추가 가능하며, 위젯 구현도 자유로움. 단점: Expo SDK를 그대로 사용할 수 없어 일부 기능을 대체하거나 직접 구현해야 할 수 있음.

3. 결과 선택: 일단 EAS Config Plugins을 써서 기존에 만들었던 날씨 어플의 위젯을 한 번 만들어본 다음에 다음 프로젝트에는 React Native CLI로 만들기로 결정. 필요성 : Expo가 처음 접하기 쉬운 환경을 구성해주기 때문에 선택했던 건데 네이티브 모듈을 커스텀하거나 더 복잡한 어플을 만들려면 React Native Cli 로 전환해야 된다는 것을 알았다. Config Plugins을 이용할 경우 당장 적용해보진 않아서 어떤 점이 도전과제로 다가올지는 아직 잘 모르겠으나 React Native Cli로 아예 처음부터 시작한다면 미래의 도전과제가 줄어들 가능성은 확실해보여서 고민이었다. 프로젝트의 규모가 커질 것을 대비, 혹은 네이티브의 기능을 제한없이 사용할 수 있다는 점이 아무래도...

react native android widget 의 정보를 알았으니까 일단 시도해보자!

프리뷰로 배포해본 후 아이콘을 바꾸고 싶어서 찾아봤다!

app.json에서 icon과 foregroundImage에서 수정해주면 된다. 또 이미지를 정하는 경로가 있길래 찾아보니 splash는 앱이 시작될 때 사용자가 앱을 실행한 직후 잠시 보게 되는 화면이라고 한다.

이렇게 네이티브 코드랑 연관된 업데이트를 프리뷰 빌드에 eas update로 적용이 안 되고 build를 한번 더 해줘야된다

와! 설치할 때부터 보이네.	귀엽다.

아 ㅠㅠ 이거 하나 바꼈지만 너무 귀엽고 웃기고 뿌듯하다.

RN을 배우면서 배포하기 전에 미리보기로 배포볼 수 있다는 걸 알았다. 웹앱 바로가기 말고 실제 앱처럼 깔아볼 수 있다니 날씨 어플을 공부하면서 만들었던 프로젝트로 바로 도전해봤다.

Expo 배포 내가 찾은 preview 는 expo 홈페이지에서 안내하는 것과 다른 옵션인 것 같아서 좀 더 찾아봤다.

• 이 페이지에도 있다 !! EAS 튜토리얼

development 프로필은 빠른 개발과 디버깅을 위해 사용되며, 로컬 환경에서 테스트를 용이하게 하고 preview 프로필은 미리보기를 위한 프로필로, 앱을 프로덕션에 가까운 환경에서 검토할 수 있도록 빌드 품질을 최적화한다고 한다. 프리뷰가 뭔가 최종 점검 느낌?

미리보기 배포를 통해 앱을 팀원이나 테스터들에게 제공하려면, EAS Build와 관련된 여러 단계를 따라야 합니다. 아래에 미리보기 배포 과정에 대한 상세한 절차를 정리했습니다. 이 과정을 처음부터 끝까지 따라가면, 앱을 테스트 용도로 배포할 수 있습니다.

1. EAS CLI 설치

EAS(Expo Application Services)는 Expo 프로젝트에서 빌드 및 배포를 관리할 수 있는 도구.

npm install -g eas-cli

이러면 eas.json 파일이 만들어진다.

2. EAS Build 환경 설정

eas.json 을 열어보면 이렇게 되어 있다.

{
  "build": {
    "android": {
      "preview": {
        "distribution": "internal",
      }
    }
  }
}

• distribution: "internal": 이 설정은 앱을 공개하지 않고, 테스트 그룹 또는 특정 사용자만 접근할 수 있게 한다. 즉, 미리보기용 배포에 적합.

3. 로그인 및 인증

eas login

4. 앱 빌드 시작

eas build -p android --profile preview

• -p android: Android 빌드
• --profile preview: eas.json에서 설정한 미리보기용 프로파일을 사용하여 빌드를 생성.

5. 빌드 상태 확인

진행하다가 오류가 나면 확인해보라는 링크가 뜨던데 이 페이지가 열린다. netlify쓸 때 많이 보던 페이지랑 비슷했다! 어떤 부분에서 오류인지 봤는데 패키지 버전 문제가 좀 있었던 것 같고 그래서 expo doctor 를 많이 썼던 것 같다.

이 명령어로도 상태를 확인할 수 있다고 한다.

eas build:status

6. 빌드 완료 후 다운로드

빌드가 완료되면, CLI에 링크가 QR이 뜨고 QR로 다운받아서 써봤다. 구글 프로텍터였나 파일 검사를 해주더라! 구웃. expo go에서 보던 그대로 어플이 실행되는 게 너무 신기하고 재밌었다.

요약

1. EAS CLI 설치: npm install -g eas-cli

2. EAS Build: eas build -p android --profile preview 명령어로 빌드 시작

3. 빌드 완료 후 배포: 빌드 완료 후 제공된 링크로 테스트 그룹에 배포

expo.dev에 들어가 프로젝트 만들기를 누르면 이렇게 뜬다. 프로젝트 만들기를 먼저 하고 명령어를

처음부터 여기서 만들고 저 명령어를 따라서 프로젝트를 만들거나 이미 만들어둔 코드베이스에 연결하는 식으로 하면 된다.

개발을 하다 보니 문득 함수 안에서 await이 있는 코드가 비동기로 동작하면서도, 왜 그 다음 줄의 console.log()에서는 값을 바로 정상적으로 받아오는지 의문이 들었다. 😅

 const ask = async () => {
    try {
      const { granted } = await Location.requestForegroundPermissionsAsync();
      console.log(granted);

조사해보 결과, await은 비동기 작업이 맞지만 비동기 작업이 완료될 때까지 그 다음 줄의 코드를 실행하지 않도록 동작한다는 것을 알게 되었다. 다시 말해, await은 함수 안에서 순차적인 흐름을 유지하게 해준다. 이렇게 await 덕분에 함수 내부에서는 동기적인 흐름처럼 보이지만, 함수 자체는 비동기 함수이기 때문에 함수 외부에서는 다른 작업을 계속해서 수행할 수 있다.

결론적으로, async와 await이 적용된 함수는 내부적으로는 동기처럼 작동하지만, 외부적으로는 비동기로 작동한다는 사실을 깨달았다. 이제 await이 함수 내부와 외부에서 각각 어떤 역할을 하는지 더 명확하게 이해할 수 있을 것 같다! 분명 배웠던 부분인데 이렇게 문득문득 혼자 나한테 설명하려고 하면 막힐 때가 있다. 그때마다 열심히 되새김질하도록 하자.

멋사 프론트엔드 캠프를 마치면서 익명으로 진행했었던, 마지막 팀플을 했던 팀원들의 피드백을 받아볼 수 있었다. 소중하기도 하고 이때의 마음가짐을 잃지 않기 위해 적어둔다!

아 누가 적어주신 건지는 여전히 알 수 없지만 왠지 말투에서 느껴지는 팀원들이 보이는 것 같기도 하다. 😆 교육과정에서 마지막 팀 프로젝트인 만큼, 그리고 리액트를 배운 다음에 파이널 프로젝트라는 이름처럼 그 전의 가벼운 프로젝트에서 범했던 실수들을 피하고 싶었고 그래서 기획이나 초기 설계가 예상보다 길어질 때도 과거에 빗대어 긴장하지 않으려고 노력했고 그 안에서 팀원들에게 이게 잘못된 것이 아님을 어필하려고도 노력했었다. 예상보다 좀 더 길어진 초기 설계로(DB 설계 쥔짜 어려움... 그래도 이건 여기로 가고 저건 저기로 가면 되겠다. 하는 건 재밌었다. 다들 욕심쟁이 의욕만땅들이라 이것도 넣자 저것도 넣자 하는 거 많아져서 백로그 작성할 때 고민 많이 했다. ㅋㅋㅋㅋ🤣) 그 후에 정해진 일정이 밀리지 않도록 스프린트 주기를 3,4일로 타이트하게 잡고 각자 만든 컴포넌트를 더 빨리 쉽게 가져다 쓸 수 있도록 문서화나 주석 달기에 꼭꼭 신경써 달라고 리마인드도 엄청 하고 (🥹 문득 이런 잔소리도 잘 들어주신 팀원들께 또 감사하네 ㅠㅠ) 내 API를 만들면서 이거 기능은 비슷하겠는데? 싶어서 다른 분들이 가져다 쓸 수 있도록 범위 넓인 API도 만들어보려고 셀프로 일 만들어서 키우고. 나름대로 정말 열심히 하려고 노력했던 것 같다. 성능이랑 접근성 점수 올려보겠다고 이미지랑 싸우고 스와이퍼랑 싸우고 툴팁이랑 싸우고. 😇

고난은 여러번 있었지만 다들 열심히 따라와준 덕에 무사히 마쳤던 것 같다. 최근에 받은 이 피드백으로 그 때의 기억을 한 번 더 상기시키고 있으니 또 불타오른다. 아자자.

View 태그에 다음과 같은 경고가 떴다.

해결방법은

1. import react
2. tsc 옵션에 react-jsx

왜 나는 오류인가 하니 jsx 문법을 쓰는데 컴파일러가 jsx가 쓰이는 react를 안 불러왔다며 띄워주는 오류였던 거다. 그래서 나는 tsconfig.json 에 옵션을 추가해줌으로써 자동으로 react를 가져오게 해놨다.

"compilerOptions": {
    "jsx": "react-jsx"
  }

익숙하지만 헷갈리지 않도록 정리해두자! 내가 이해하기 위한 용어들로!

서버 : "땅"

데이터를 다루기 위한 환경 "중앙" 이라도 생각해도 좋을 듯.

Node.js : "환경"

원래 브라우저에서만 살던 언어인 JS가 다양한 환경에서 살 수 있도록 만들어준 JS 런타임 환경

Next.js : "식탁"

React 기반의 프레임워크. React 앱이 올라온다. SSR, SSG 같은 기능. 프론트엔드 위주의 프레임워크.

Express : "식탁"

Next.js 보다 범용적인 프레임워크. 백엔드 위주의 프레임워크.

라이브러리 : 식탁에 달린 "수저통"

앱에서 필요하면 가져다 쓴다. 안에는 패키지, 패키지 안에는 모듈.

빌드 도구 : "조리 도구 패키지"

빌드 : 개발 중에 작성한 코드를 최종적으로 배포 가능한 형태로 만드는 과정 vite, webpack 같은 조리 도구 패키지 안에 각각의 도구들이 있는 것.

Bundler (믹서기): 파일들을 하나로 묶어 효율적으로 로딩 가능하게 함. Transpiler (통역기): 최신 문법을 구버전 문법으로 변환해 호환성 확보. Minifier (칼과 도마): 불필요한 부분을 제거해 파일 크기를 최소화. Compiler (레시피 변환기): TypeScript와 같은 다른 언어를 JavaScript로 변환. ts컴파일러가 js로 변환해줌!

전체의 흐름을 정리해보자!

서비스가 음식, 데이터는 요리 재료, DB는 재료 진열대, 서버는 재료가 있는 환경/주방, API는 서버에서 재료를 가져오기 위한 카트, 웹 프레임워크가 음식이 놓이는 식탁, 라이브러리는 수저통, 빌드 도구는 조리 도구 패키지이고 그 안에 있는 도구들이 음식을 손님이 먹을 수 있게 최적화(미니파이어, 컴파일러, 등등), 브라우저는 손님이 먹는 자리

프로젝트를 하면서 이런저런 도구의 필요성을 따지고 선택하면서 문득 내가 당연하게 쓰고 있는 리액트에 대해 내가 처음 느꼈던 유용성과 필요성을 기록해두려고 한다.

리액트를 배우기 전에 바닐라 JS로 페이지별로 개발할 때는 코드가 점점 커지고 복잡해지기 때문에 관리가 어려운 경우가 많았다. 이 페이지, 저 페이지에 같은 컴포넌트가 들어갈 때 내가 할 수 있었던 것은 ctrl+c ctrl+v 뿐이었다. (모듈화에 익숙하지 않았던 폐해 🥲) 그러다가 섀도우 돔에 대해서 알게 되었는데 처음 익히기엔 복잡했던 것으로 기억한다. 그래도 스타일 독립성이나 DOM 조작에 있어서 자유로운 게 매력적이었다. 그걸 배운 직후 팀플을 들어가게 되었는데 기간은 짧고 다른 팀원들의 이해수준을 취합한 결과 섀도움 돔으로 컴포넌트화 시키는 것은 시간상 무리일 것이라고 생각해 제대로 사용해보지 못 했다. (아쉽!) 그렇게 프로젝트가 끝나고 바로 React는 수업에 들어가게 됐는데 섀도우 돔을 많이 사용해보지 않았어도 이 편리함은 바로 느낄 수 있었다. 바닐라에서는 수동으로 이벤트 리스너로 조작해줘야 했는데 React에서는 상태로 설정해두면 알아서 변한다. 오오... 신세계. 물론 jsx를 배운 후로 더 엄청나지긴 했는데!! 페이지 별로 개발했던 js때와 다르게 모든 게 컴포넌트였다. 모든 게! 와! 이거 퍼즐 조립이다! 라고 속으로 외쳤던 때가 기억난다. React는 모든 UI를 컴포넌트 단위로 나누어서 관리할 수 있기 때문에 훨씬 더 모듈화되고 유지보수가 용이해진다는 장점이 있다는 것도 배웠다.

요즘 인기있는 스택이기도 하지만 내가 직접 배우면서 유용함을 배울 수 있어서 너무 좋았다.

주로 AI 기술에 관한 이야기가 많이 들렸다. GPT가 어떻게 만들어지게 된 것인지에 대해 들으면서 뭔가 옛날 전선 수업을 듣는 기분이었다. 대학교 4학년 때 내가 선택했던 VR 트랙이 사라지고 ( ... ㅠ ) 얼결에 AI 트랙으로 들어가서 냅다 캡스톤 프로젝트를 하게 됐는데 거기서 CNN으로 수어 판독하는 프로젝트를 맨땅에 헤딩으로 만들어냈던 기억도 새록새록 났다. 그러면서 '옛날에는 지식인으로 검색하며 공부했던 시절이라면 지금은 chatGPT로 공부하는 시절이라'는 말씀을 해주셨는데 진짜 gpt 처음 나왔을 때 우와, 저게 뭐야. 인공 비서다. 라고 혼자 생각했던 시간이 떠올랐다. 지금의 나도 프로젝트를 기획하거나 뭔가 방향성이 필요할 때 잘 사용했었는데 이거 활용하면서도 그래도 구글로 찾아보는게 낫나? 늘 경계하면서 사용했었던 것 같다. 그래서 gpt한테 한번 묻고 공식문서에서 한번 더 보고 구글링도 좀 더 하고 그러면서 탐색 범위를 늘 넓히려고 하고 있었는데 마지막 질의응답 시간에 내 방법에 대한 빙고를 얻은 느낌이었다. 질문 중 현재 gpt를 코드에 대한 답을 찾는데 사용하고 있는데 gpt를 잘 사용하는 것이 ai 시대에 살아남는 ai를 잘! 활용하는 개발자의 능력이라면 그냥 다른 거 신경쓰지 않고 gpt를 활용하는 것이 맞느냐 이런 질문이었던 것 같은데 그에 대한 답으로 답을 찾는 것에서 끝나지 않고 내 안의 인사이트를 늘리는데 집중하면 좋겠다. 라고 하셨다. 듣자마자 오! 나 그래도 잘 쓰고 있었네! 라는 생각이 들었다. AI가 퍼져나가는 시대에서 AI를 무작정 경계하는 것보다 이걸 통해 어떤 간단한 작업들을 줄여나가고 어떻게 더 유용하게 활용하는지 고민하는 개발자가 앞으로 살아남을 것이라는 말에 끄덕였다. 좋은 도구로서 앞으로 더 고민하며 사용해야겠다. 1시간여 정도의 짧지만 알찬 강의였다. 😆

쏘원 프로젝트를 하면서 어떤 식으로 품절 여부를 파악해야할지 감이 안 잡혀서 내가 GPT의 도움을 받았던 기록을 해보려고 한다.

먼저, 품절 여부를 어떤 식으로 파악해야 할지 감이 안 잡혔다. 떠오르기로는 옵션이 있다면 하나하나 눌러 구매하기 버튼이 활성되어있는지 확인하는 것. 혹은 HTML 텍스트 컨텐츠에서 품절에 대한 여부를 파악하는 것. html 구조는 언제든지 바뀔 수 있으니까 첫번째가 나을 것 같기는 한데 그래서 어떻게? 라는 의문이 있었다. 그래서 GPT 에 검색해본다.

내가 만들고자 하는 것과 내가 생각한 저 두 가지의 방법을 타이핑하고 비교해달라고 했다. 비교 결과는 내가 예상한 것과 같아서 그럼 첫번째 방법의 경우 어떤 식으로 진행해야 할지 물어본다.

Puppeteer 같은 브라우저 자동화 도구를 추천해줬다. 웹 스크래핑이나 테스트 도구로도 많이 쓰이는 모양이었다. 여기서 자동화 도구에 대한 힌트를 얻어서 다른 자동화 도구도 찾아봤다.

1. Puppeteer
2. Playwright
3. Selenium 아래로 갈 수록 더 많은 기능을 지원하지만 그래서 좀 더 복잡하거나 리소스가 많이 소모되는 경향이 있었다. 엄청난 기능을 요하는 프로젝트도 아니고 나는 빠르게 결과값을 내고 싶으니까 Puppeteer로 하기로 결정했다. 더 다양한 기능이 필요해지게 되면 Playwright이 Puppeteer와 유사하다고 하니까 확장하면 될 것 같았다.

이렇게 한 가지 관문을 거쳤다! 도구를 찾아보고 거기서 하나 고르는 과정은 꼭 쇼핑하는 기분도 들고 재밌었다. 더 나아가보자.

상품의 품절 여부를 알아보기 위한 과정 기록

링크를 통해 상품의 품절 여부를 어떻게 알아볼 것이냐에서 시작됐다. 내가 생각한 것은 두 가지.

1. 네이버 API 에서 품절과 관련된 정보 제공 2. HTML 구조에서 품절과 관련된 속성으로 구분

1번이 있다면 어렵지 않을 것이라 생각하고 찾아봤으나 품절과 관련된 정보를 제공하지는 않았다. 스마트 스토어에 판매하는 사람들이 품절 상태를 만드려면 재고수량을 0으로 만든다는 것까지는 찾았으나 개발자 센터에서는 마땅한 정보가 없었다. 🥲 검색-쇼핑api에서 상품군 타입이란 게 있길래 설레는 마음으로 들어갔으나 일반/중고/단종/판매예정 상품에 대한 정보뿐이었다. 😞 일반과 판매예정의 차이점이 뭔지 궁금하니까 한번 써보기는 해야겠다.

어쨋든 이렇다보니

1. 네이버 API 에서 품절과 관련된 정보 제공 => 안 해줌
2. HTML 구조에서 품절과 관련된 속성으로 구분

이라서 2번째 방법을 찾아 나섰다.

판매중인 상품 / 단일 옵션에 품절인 상품 / 여러 옵션에 특정 상품은 판매중인 상품

이렇게 세 가지로 분류해서 소스 코드나 차이점을 찾아봤다. 소스 코드에 차이점이 있다면 품절이나 재고 수량에 관련된 속성이 있을 거라고 기대했다. 또 품절일 경우 구매하기 버튼이 있고 품절이 아니면 구매하기 버튼이 있으니까 그걸로 구분할 수 있을까 기대했으나!!

• 태그 내의 재고/품절과 관련된 속성이 있을 것이라 예상 🧨 없었음!
• 구매하기 버튼의 유무로 판단 🧨 옵션이 n개 인 경우 하나라도 품절이 아니라면 구매하기 버튼이 있음

🥹 모두가 내 예상을 빗나가고 있다. 하나 찾은 게 있다면 태그 내의 텍스트 컨텐츠에 품절 이 추가되어 있다는 것 정도.

이렇게 된 이상 다른 품절 알림이 있는 서비스들도 좀 더 뒤져봐야겠다!! 🚨🚨