🥬 상추의 공간

iPad 앱에서만 외부 링크가 빈 화면으로 뜬 문제 (ft. iPadOS 27 popover, 오픈소스 기여)

들어가며iPad 앱에서 외부 링크를 누르면 화면 아래에 작은 창이 뜨는데, 그 안이 계속 비어 있다는 문의를 받았다. 웹에서는 잘 되는데 앱에서만 안 된다고 했다. 원인은 iPadOS 27에서 달라진 Safari 창의 동작과 관련이 있었다. 다만 처음에는 내 환경에서 재현되지 않아 찾기까지 시간이 걸렸다.이 글에서는 원인을 찾아 앱을 고치고, Expo에 이슈를 보고해 라이브러리 수정까지 이어진 과정을 정리했다. 문제 상황iPad 앱에서만 뜨는 빈 화면문의 내용은 이랬다. (문의 사진은 이해를 돕기 위해 일부 다듬어서 만들었다.)문의에서 단서는 두 가지였다.웹에서는 잘 된다. 같은 링크가 웹에서는 열리니, 앱이 링크를 여는 부분부터 봐야 했다.화면 아래에 작은 창이 뜬다. 봄봄 앱은 외부 링크를 Safar..

들어가며Sentry에 쌓인 오류를 일일이 확인하고, 분석하고, 수정하고, 기록하고, PR을 올리는 과정이 은근 번거로웠다. 그래서 내가 하던 일을 AI에게 맡겨 보기로 했다.이 글에서는 Sentry 대응을 자동화하며 고민했던 내용과 실제 구축 과정을 정리해 보려고 한다. 비슷한 자동화를 고민하는 사람에게도 도움이 되었으면 좋겠다. 반복되는 Sentry 대응을 자동화하고 싶었다봄봄은 뉴스레터를 모아 읽는 서비스이다. 실제 사용자가 있는 만큼 Sentry로 프론트엔드 오류를 모니터링하고 있다. 처음에는 Sentry 대시보드에서 에러 메시지와 스택 트레이스를 직접 확인하며 문제를 분석했다. 그런데 이 정보만으로는 오류가 어떤 상황에서 발생했는지 파악하기 어려울 때가 많았다. Session Replay까지 확인..

어느 날 갑자기 봄봄 블랙리스트(?)에 당하다봄봄 뉴스레터 개발자이자 열혈 사용자인 나는 어느 날 봄봄 블랙리스트(?)에 당했다.봄봄에서 아티클을 읽고 생각에 잠긴 나는, 손이 심심해 투데이와 보관함 탭을 여러 번 이동했다. 그러니까 투데이 ↔ 보관함을 반복해서 눌렀다.그러다 갑자기 몇 초 동안 스켈레톤 로딩 화면이 보이더니 로그인이 풀렸다. 다시 로그인하려니 빈 백지의 화면만 보였다.너무 당황해서 PC로도 접속해 봤는데, PC에서도 접속되지 않았다. 모바일 앱과 PC 웹 모두 접속할 수 없는 상황이었다. 네트워크 탭을 열어 보니 모든 API 요청이 CORS 에러로 표시되고 있었다. 그래서 서버에 문제가 생긴 줄 알고 급하게 팀 디스코드에 상황을 공유했다. 그런데 약 5분 뒤에 정상화가 됐다.접속은 정상..

서론봄봄 뉴스레터는 여러 발행처의 뉴스레터를 하나의 아티클 화면에서 모아 읽을 수 있는 서비스다. “일부 아티클의 글자가 작아 읽기 어렵다”는 사용자 피드백을 꾸준히 받아왔다. 나도 사용자로서 공감하던 바였다. 그래서 이번에 본문 글자 크기를 직접 선택할 수 있는 기능을 구현하게 되었다. 처음에는 본문을 감싸는 요소의 font-size만 바꾸면 될 것처럼 보였다. 하지만 봄봄은 발행처마다 구조와 스타일이 다른 뉴스레터 HTML을 아티클 화면에 렌더링한다. 부모 요소의 글자 크기만 바꿔서는 모든 텍스트가 함께 커지지 않았다.그렇다고 화면 전체를 확대하면 이미지와 버튼, 봄봄의 UI까지 함께 커진다. 읽기용 텍스트만 조절하면서도 뉴스레터가 가진 제목·본문·캡션의 크기 관계와 기존 읽기 기능을 유지해야 했다...

들어가며크롬에서 탭을 여러 개 열어두면 컴퓨터가 느려진다는 걸 한 번쯤 느껴봤을 것이다.실제 맥 활성 상태 보기를 열어보면 크롬 관련 프로세스가 수십 개씩 떠 있고, RAM을 수백 MB씩 잡아먹고 있는 걸 볼 수 있다. 왜 탭 몇 개 열었을 뿐인데 이렇게 될까?이 질문에 답하려면 먼저 "메모리"가 무엇인지부터 짚어야 한다. 우리가 일상적으로 '메모리를 많이 먹는다'고 할 때의 메모리는 RAM을 가리킨다.프로그램은 평소엔 SSD나 HDD에 저장돼 있지만, 실행되는 순간 운영체제가 필요한 코드와 데이터를 RAM으로 복사해 올린다. CPU는 RAM에 올라온 내용을 읽으며 명령을 수행한다. 크롬도 마찬가지다. 그렇다면 크롬은 왜 이렇게 RAM을 많이 쓰는 걸까?그 이유는 크롬이 웹 페이지를 여러 프로세스로 분리..

서론브라우저 주소창에 URL을 입력하면 어떤 일이 일어날까?이 글에서는 Chrome DevTools Performance 패널로 직접 측정하며, 브라우저가 HTML을 받아오기까지의 네트워크 흐름을 살펴본다. TCP 연결 수립, TTFB, 캐시 정책 등 Network 막대 하나에 담긴 과정들을 하나씩 짚어볼 것이다. Performance 패널로 확인한 이유는 단순한데, 평소에 성능을 세부적으로 측정하고 싶을 때 해당 도구를 사용하는데, 항상 보는 부분만 보고 다른 영역들은 뭘 의미하는걸까 궁금증을 갖고 있었다. 잘 모르니 단편적으로만 확인할 수 밖에 없었고, 그래서 더 잘 활용하고 싶은 니즈가 항상 있었다. 그래서 이번 기회에 조금 더 친해져보고자 사용하게 되었다. 참고로 학습하고 있는 입장이라 최대한 검..

들어가며Sentry는 서비스에서 발생하는 에러를 실시간으로 수집하고 대시보드에서 확인할 수 있는 모니터링 툴이다. 우테코에서 미션 요구사항으로 구축을 했으나, 처음 써보는 툴인 데다 당시 우선순위가 높지 않다 보니 기본적인 초기화 세팅만 해두었다. 에러가 발생해도 잘 활용하지 못하고 있었다. 하지만 사용자로부터 직접 에러 발생 피드백을 받으면서, 사소한 에러라도 사용자의 신뢰도를 떨어트릴 수 있고 이탈로 이어질 수 있겠다는 생각이 들었다. 실제로 연구에 따르면, 기술적 오류는 사용자의 분노와 실망에 유의한 영향을 미치고, 이는 이탈 의도로 직결된다고 한다. 그래서 방치되고 있던 Sentry를 실질적인 디버깅 도구로 만들기 위한 개선 작업을 시작했다. 문제기존엔 에러 타입, 메시지, 상태코드, 페이지 UR..

들어가며지난 글에서는 LCP 7.6초라는 문제를 진단하고, 네 가지 방법을 비교해 S3 이벤트 기반 Lambda 비동기 처리 방식을 선택하기까지의 과정을 다뤘다. 이미지 최적화 파이프라인 구축기 (1) - 문제 진단과 방법 선택들어가며이전에 정적 이미지 최적화 방식을 다룬 글을 작성한 적 있다. 이번에는 사용자가 업로드한 이미지를 최적화한 경험을 정리해보려 한다. 이번 글에서는 LCP 7.6초라는 수치를 발견하고,sanghee01.tistory.com이번 글에서는 실제로 어떻게 구현했는지를 다룬다. S3 이벤트 트리거 설정부터 Lambda 함수 구현, 원본과 최적화 버킷 분리 설계까지 순서대로 진행한다. 전체 파이프라인 구조이미지 업로드부터 최적화 과정,사용자에게 이미지가 보이기까지의 전체 흐름을 먼저 ..

들어가며이전에 정적 이미지 최적화 방식을 다룬 글을 작성한 적 있다. 이번에는 사용자가 업로드한 이미지를 최적화한 경험을 정리해보려 한다. 이번 글에서는 LCP 7.6초라는 수치를 발견하고, 네 가지 최적화 방법을 비교해 S3 이벤트 기반 Lambda 방식을 선택하기까지의 과정을 다룬다. 이 작업을 통해 최종적으로 LCP를 7.6초에서 2.1초로 단축하고, Lighthouse Performance 점수를 70에서 90으로 개선했다. 문제 상황모멘트는 사용자가 게시물에 텍스트와 이미지를 함께 업로드할 수 있는 SNS 커뮤니티 서비스다. 일부 사용자로부터 이미지 로드 속도가 느리다는 피드백을 받았고, 서비스 성능을 점검하기 위해 Lighthouse 측정을 진행했다.수치로 확인해보니 문제는 생각보다 명확했다...

문제 상황유난히 번들 크기가 큰 패키지모멘트 프로젝트에서 번들 분석을 하던 중, 아이콘 패키지 lucide-react의 비중이 유난히 크게 보였다.프로젝트에서 실제로 사용하는 아이콘은 약 20개였는데, 번들에 아이콘이 무수히 많이 포함되어있고, node_modules 번들의 1/4 이상을 차지하는 게 이상하다고 판단했다. 트리셰이킹과 관련되었다고 판단하여, 관련 설정을 하나씩 점검했고, 그 결과 특정 옵션을 수정해 번들 크기를 줄일 수 있었다.하지만 수정하고도 찝찝한 마음이 들었다. 그 옵션은 트리셰이킹을 돕기 위한 옵션으로 알고 있었기 때문이다. 이 글에서는 내가 무엇을 오해했는지, 실제 원인이 무엇이었는지, 그리고 올바른 해결 방법은 무엇이었는지 정리하고자 한다. 사전 지식트리셰이킹 트리셰이킹은 프로..

도입모멘트 프로젝트에서 페이지에 사용되고 있는 정적 이미지(레벨, 아이콘 등)의 로딩 속도가 느린 것을 확인하였다. 기존에는 단순히 네트워크 속도가 느리거나 기기 사양이 낮아서 로드 속도가 낮은 것이라고 생각했었는데, 웹 성능 최적화에 대해 학습한 이후 관점이 달라졌다. 단순 사용자의 기기 문제라고 끝낼게 아니라, 개발자가 충분히 개선할 수 있는 영역이었다. 이 글에서는 이미지 로딩 속도를 어떻게 개선했는지 공유하고자 한다. 문제 상황앞서 말했듯 모멘트 프로젝트에 쓰이는 아이콘들의 로딩 속도가 느린 문제가 있었다. 특히 저사양 기기일수록 이미지가 로드되는 속도는 더 느렸다. 1. Lighthouse 측정먼저 Lighthouse 측정을 해봤다.Lighthouse는 Chrome 개발자 도구에 내장된 성능 ..

6주차 이후, 2주간 이야기6주차까지의 회고 이후부터 7, 8주차, 방학까지의 이야기를 해보겠다. 우선순위 쪼개고 쪼개기, 그리고 내려놓기6주차 이후, 거의 건강한 마인드로 미션에 임할 수 있었다. 당시, 다들 영화리뷰 미션 step2를 시작할 때, 나는 점뭐먹 미션 step2를 리팩토링도 아닌, 기본 기능 구현을 할 정도로 엄청 밀려있었다. 하지만 다른 크루들 속도에 신경쓰지 않고 내 위치에서 최선을 다했다. 그래서 점뭐먹 미션, 영화 리뷰 미션은 정말 즐겁게 했던 것 같다. 그때부터 스스로 고민을 하면서 구현하기 시작해서 그 시기에 많이 성장한 것 같다. 구현하면서 고민했던 내용과 겪은 문제 상황도 노션에 기록하며 진행했어서 내가 당시 뭘 고민했는지 더 잘 기억할 수 있었다. 또한, PR 본문에 리뷰..