현이의 개발 이야기

웹

Footer를 페이지 하단에 고정하는 법

대부분의 웹페이지는 Footer가 있으며, 페이지 내용의 길이에 상관 없이 하단에 고정되어 있다. 내용이 짧으면 알아서 페이지의 하단에 붙고, 내용이 길다면 스크롤해야 보이는 Footer를 만들어보자. 페이지 준비 우선 다음과 같이 간단한 페이지 구조를 만들었다. <body> <header class="header">Header</header> <div class="content"> Content </div> <footer class="footer">Footer</footer> </body> body { margin: 0; } .header { background-color: yellow; } .content { background-color: green; } .footer { background-color: skyblue; } Header, Content, Footer를 색으로 구분하였다. 실제 웹페이지에서는 Content 안에 내용이 들어가게 될 것이다. 내용이 짧아 Footer가 위로 붙어있는 모습을 확인할 수 있다. 조건 Footer가 페이지 하단에 고정되기 위해서는 다음의 조건을 만족해야 한다. 내용이 짧을 때는 Content가 길어져야 한다.단, 페이지를 넘어가게 길어져서는 안된다. 내용이 길 때에는 Content가 내용에 맞는 높이만큼 사용해야 한다. 즉, Content의 높이가 Footer를 하단에 고정하는 데 핵심이라고 할 수 있다. 구현 우선, body가 차지하는 높이 자체를 늘려 주어야 한다. 그래야 Content도 그 안에서 원하는 만큼 길이를 가질 수 있을 것이다. 최소 높이, 즉 min-height를 활용하면 내용이 짧을 때에만 효과를 낼 수 있을 것이다. body { margin: 0; min-height: 100vh; } 그 다음, Content가 body에서 남는 공간을 전부 차지하도록 해야 한다. 이를 위해 body는 flex로 설정하고, Content에는 flex-grow: 1을 준다. body { margin: 0; min-height: 100vh; display: flex; flex-direction: column; } .content { background-color: green; flex-grow: 1; } 이렇게만 하면 끝이다. 결과 내용이 짧을 때, Content가 늘어나 Footer가 하단에 고정된 것을 볼 수 있다. 스크롤바 또한 생기지 않는다. 내용이 길어 페이지를 넘어갈 경우, 정상적으로 스크롤바가 생겨 Footer는 페이지 아래로 밀려난다. 스크롤을 아래로 내려보면, Footer가 내용을 가리거나 하는 것 없이 하단에 잘 보여지고 있는 모습도 확인할 수 있다. <body> <header class="header">Header</header> <div class="content"> Content </div> <footer class="footer">Footer</footer> </body> body { margin: 0; min-height: 100vh; display: flex; flex-direction: column; } .header { background-color: yellow; } .content { background-color: green; flex-grow: 1; } .footer { background-color: skyblue; }

02025. 04. 22.

웹

이미지 hover 시 오버레이 보여주기

<div class="container"> <img class="image" src="https://picsum.photos/200" /> <div class="overlay"> Overlay content here </div> </div> .container { position: relative; display: inline-block; cursor: pointer; } .image { display: block; } .overlay { background-color: #000000ff; color: white; opacity: 0; transition: opacity 120ms; position: absolute; top: 0; left: 0; right: 0; bottom: 0; /* 텍스트 가운데 정렬 */ display: flex; align-items: center; justify-content: center; } .overlay:hover { opacity: 0.7; } 이미지에 커서를 hover 했을 때 overlay content가 보여진다. 이미지의 크기에 따라 container의 사이즈도 변경된다. 이미지와, 이를 감싸는 컨테이너를 먼저 배치하고, overlay 엘리먼트를 컨테이너 전체 면적을 차지하도록 absolute로 설정한다. hover 시 opacity를 조정해주면 hover시에만 해당 내용을 보여줄 수 있게 된다. https://jsfiddle.net/rn3e4c5d/20/

02025. 01. 11.

일상

내가 생각하는 구글 최고의 복지 세 가지

2020년에 대학교를 졸업하고 6월에 구글 코리아에 입사했다. 그로부터 벌써 4년 반이 지났다. 팀도 여러 번 옮기고 프로젝트도 여러 개를 했지만 모든 기간 내가 생각하기에 최고라고 느낀 복지 세 가지가 있다. 이번 포스트에서 그 세 가지 복지를 짚어보고자 한다. 1. 자율 출퇴근 구글은 자율 출퇴근제이다. 출근 시간과 퇴근 시간이 정해져있아 않고 내 일정에 맞춰서 일하면 된다. 하루에 8시간 이상, 일주일에 40시간 이상 등의 최소 근무 시간도 없다. 이러한 자율 출퇴근은 내가 최고의 효율을 낼 수 있도록 많은 도움을 주는 복지라고 생각한다. 코딩 테스트 책 출판 이후 요즘 IT와의 인터뷰에서도 자율 출퇴근에 대해서 이야기 한 적이 있다. https://yozm.wishket.com/magazine/detail/2460/ 자율 출퇴근제를 활용하면 내 라이프 스타일에 맞게끔 업무 시간을 조정할 수 있다. 오후와 저녁에 약속이 많은 사람은 최대한 오전 시간을 활용해서 업무를 하고, 오전에 일정이 많은 사람은 오후와 저녁 시간대에 업무를 할 수 있다. 실제로 나는 한동안 야간이나 오전에 배드민턴을 치고, 점심 시간 끝나갈 때 쯤 출근하는 일과를 꽤 오래 유지했다. 구글에서는 이렇게 점심 때 돼서야 회사에 나오는 것을 존중해주는, 아니, 아예 신경 쓰지 않는 분위기이다. 또, 러시아워를 피함으로써 출퇴근 스트레스를 줄일 수 있다. 역삼에서 서울대입구쪽으로 이사오고 나서 출퇴근 거리가 늘었다. 가장 힘들었던 것은 지하철에 사람이 너무 많았다. 역삼에서 오피스 5분 거리에 살 때만 해도 아침에 일어나서 오피스에 금방 걸어가고, 퇴근하고 싶을 때 퇴근할 수 있었는데 이사오고 나니 출퇴근 할 때 사람이 너무 많아 힘들었다. 이 때문에 출퇴근 시간이 자연스레 늦어졌다. 출근 시간이 지나고 사람이 많이 없을 때 출근하고, 마찬가지로 퇴근 시간이 지나고 퇴근한다. 출퇴근할 때 받는 스트레스가 줄어드니 출퇴근도 할만 했다. 2. 음식 구글, 그 중에서도 구글 코리아는 음식이 맛있기로 유명했다. 구글 코리아 오피스에는 두 개의 식당이 있는데, 각 식당은 다르게 운영된다. 하나는 메인 디시 하나와 뷔페식으로 운영되는 사이드 디시들이 있다. 또 다른 하나는 라이스 메뉴나 누들 메뉴를 메인으로 제공하고, 반찬이 있는 식당이다. 메뉴도 매번 바뀌고, 양도 마음껏 먹을 수 있다. 특히 건강하게 먹으려면 얼마든지 건강하게 먹을 수 있고, 반대로 또 얼마든지 안 건강하게 먹을 수 있다는 점에서 그날그날 기분에 따라 맞춰 먹을 수 있다는 점도 큰 것 같다. 아침과 점심을 제공해주는데, 아침은 김밥이나 국밥처럼 간단하게 먹을 수 있는 메뉴 위주이다. 또, TGIT (Thanks God It's Thursday)가 별도로 운영된다. 이건 구글의 TGIF(Thanks God It's Friday)로 널리 알려져 있는데, 시차 때문에 한국에서는 목요일에 하는 것으로 바뀌었다. 여기서는 특별식처럼 맛있는 메뉴들이 종종 나온다. 맥주나 위스키처럼 술도 나오지만 나는 술을 별로 안좋아해서 잘 마시지는 않는다. 3. 사람 이건 정말 빼놓을 수 없는 복지이다. 구글에서 만나게 된 사람들은 전부 자신의 일에 열정을 가지고 있다. 말로는 매번 귀찮다, 집에 가고 싶다, 이런 거 왜 해야 하냐 하지만 막상 보면 "그래도 대충 할 순 없잖아?" 하면서 엄청난 능력을 보여준다. 단순히 코딩 뿐만 아니라 프로젝트 방향성이나 문제 파악, 해결 등 다방면으로 능력을 가진 사람들이 참 많다. 옆에 있는 이런 사람들을 보면 내가 어떤 역량이 부족한지를 확실히 깨닫게 된다. 구글 코리아에서는 직급에 관계 없이 "님" 호칭을 사용한다. 서로 존중하는 문화가 있기에 혼날 걱정 없이 모르는 것을 마음껏 물어볼 수 있다. 혹시나 가끔 답답해할까 걱정하며 조심스럽게 물어보면, 의자까지 끌고와 성심성의껏 설명해주며 코드 포인터까지 공유해준다. 해외에 있는 팀들과의 교류도 굉장히 많은 도움이 된다. 한국에 있는 팀원들이 모르는 것이 있으면 해외에 있는 팀원들에게 물어보고, 자세한 답변을 얻을 수 있다. 반대로 한국 팀이 더 잘 알고 있는 내용이 있으면 우리가 도움을 주기도 한다. 이렇게 서로 교류하며 다른 오피스에서 진행하는 프로젝트 이야기를 듣다보면 시야도 넓어지고 프로젝트 방향성도 점점 명확해지는 느낌이다. 최고의 복지는 동료다. 라고 했던가. 이러한 동료들이 있기에 나도 더욱 성장할 수 있고 회사도 점점 더 발전할 수 있는 것 같다.

02025. 01. 09.

Flutter

안드로이드 adb 무선 연결 디버깅하기

안드로이드는 adb (Android Debug Bridge)를 통해 디버깅 연결을 할 수 있다. Flutter 뿐만 아니라 안드로이드 스튜디오로 진행하는 네이티브 안드로이드 개발도 adb를 통한다. 유선 연결하여 프로젝트를 실행하고 디버깅하는 것이 일반적이지만, adb는 무선 디버깅도 지원한다. 나는 휴대폰을 유선 충전하면서 프로젝트를 디버깅하는 경우가 많아 무선 디버깅을 애용한다. 안드로이드 무선 디버깅하기 무선 디버깅을 연결하는 방법을 살펴보기 전, 다음을 확인하자. 데스트탑에 adb가 설치되어 있어야 한다.cmd에 adb를 쳤을 때 adb로 할 수 있는 명령어 리스트가 출력돼야 한다. 안드로이드 폰에 개발자 모드가 활성화되어 있어야 한다.이 부분은 간단하고 검색하면 잘 나오므로 따로 다루지 않겠다. 안드로이드와 데스크탑이 같은 와이파이에 연결되어 있어야 한다.다른 네트워크에 연결되어있다면 무선 디버깅은 불가능하다. 1. 페어링 정보 생성 안드로이드 디바이스와 데스크탑을 연결하기 위해선 먼저 두 기기를 페어링 시켜 주어야 한다. 이를 위해 안드로이드에서 설정 > 개발자 옵션에 들어간다. 개발자 옵션에서 무선 디버깅을 활성화시킨다. 무선 디버깅을 클릭하여 들어가면 기기의 정보와 함께 다음과 같이 두 가지 페어링 옵션이 있다. 이 중 페어링 코드로 기기 페어링을 선택한다. QR 코드 옵션은 터미널 환경에서 제공되지 않는 것 같다. 그러면 다음과 같이 페어링을 위한 코드와 IP 주소 및 포트가 표시된다. 이 정보는 앞서 표시된 기기 정보와 다르다는 것에 주의하자. 2. 페어링 이제 데스크탑으로 돌아와 명령 프롬프트(혹은 터미널)를 실행시켜준다. adb pair <IP주소>:<포트>를 입력한다. 바로 위에서 확인한 페어링을 위한 IP 주소와 포트를 넣으면 된다. 정상적으로 입력했다면 위 스크린샷과 같이 성공 메시지가 출력된다. 다시 안드로이드를 확인해보면 페어링된 기기에 데스크탑이 표시되는 것을 확인할 수 있다. 그러나 아직 실제 연결은 되지 않은 상태이다. 페어링은 두 기기가 서로의 존재를 알게 해주는 것 뿐, 연결시키는 과정은 아니다. adb devices 명령어로 연결된 안드로이드 디바이스를 확인해보면 아무것도 출력되지 않는다는 것을 알 수 있다. \ 대신 한 번 존재를 확인시켜주었으니 다음에 무선 연결을 할 때에는 별도의 페어링 과정이 필요하지 않다. 3. 연결 실제 연결은 기기 정보를 이용해 adb connect <IP주소>:<포트> 명령으로 할 수 있다. 페어링에 사용했던 포트와 달리, 여기에 들어가는 정보는 무선 디버깅 화면에 표시된 기기 정보이다. 이를 수행하면 다음과 같이 무선 디버깅이 연결되었다는 알림이 뜬다. 이제 유선으로 연결한 것과 똑같이 프로젝트를 실행하고 디버깅할 수 있을 것이다.

02025. 01. 04.

일상

요즘 IT에 2024년 개발자 회고 글을 쓰며 느낀 점

https://yozm.wishket.com/magazine/detail/2907/ 12월 27일에 내가 쓴 2024년 개발자 회고 글이 요즘 IT에 올라갔다. 개인적으로 올해는 더 나은 개발자가 되기 위해 깨달은 바가 조금은 있었기에 여기에 집중하며 글을 써보았다. 회고 글을 쓰면서 생각한 점을 여기에 풀어보고자 한다. 글의 방향 차이 지금까지 내가 써왔던 글은 정보 전달이 주 목적이었다. 처음 출판했던 코딩 테스트 책이나 지금 집필 중인 책, 그동안 요즘 IT에 기고했던 글이나 블로그에 올리고 있는 글까지 모두 내가 생각하는 것을 잘 전달하기 위한 글이었다. 회고 글도 큰 목적은 마찬가지이겠지만 조금 다르게 느껴졌다. 정보 전달보다는 내 경험을 공유하고, 여기서 배운 점을 전달하는 것이 위주가 되었다. 내가 알고 있는 것에 대해서 서술하는 것이 아니라 내가 새로 깨달은 것에 대해 이야기하려다보니 글을 쓰는 것이 어려웠다. 심지어 회사에서 배운 경험들은 구체적인 예시를 들 수도 없었기에 글이 점점 더 추상적으로 써지는 것 같았다. 2025년 목표에 대해서 쓸 때에도 마찬가지였다. 직접 경험해 본 것이 아니라 실험적으로 해보는 것이기에 구체적인 사례를 근거로 제시하기가 힘들었다. 그러나 이것은 이 글이 지금까지 써왔던 글과는 달리, 미래지향적인 글임을 의미한다. 그저 내 지식을 전달하는 것을 넘어서 내 생각을 정리하고 앞으로의 목표도 정할 수 있는 도전적인 성격의 글이었기에 매우 좋은 경험이 되었다. AI와 개발자 최근 제미나이로 지뢰 찾기 사이트 만들기라는 포스트를 올렸다. https://www.hyuni.dev/posts/1zUqcUuX7HcVp7NlSBMH 여기서 제미나이 2.0의 강력한 기능에 감탄했다. 확실히 AI가 코드를 작성하는 능력은 날이 다르게 발전하고, 웬만한 개발자들은 상대가 안될 것 같다고 느꼈다. 또, 요즘 IT에 쓴 개발자 회고 글에는 AI로 인해서 변한 것은 없다고 적었다. 이 생각은 아직도 같다. 개발자가 되기 위해서는 코드를 한 자 한 자 작성하는 것부터 공부하지만, 이것은 그저 가장 기초적인 역량일 뿐이다. 개발자는 그저 코드를 작성하는 것에서 멈춰서는 안된다. 아니, 오히려 코드를 작성하는 것은 그렇게 중요하지 않다. 실력 있는 개발자가 되기 위해서는 전체적인 흐름을 볼 수 있어야 한다. 프로젝트가 해결하고자 하는 문제를 이해하고, 그 원인을 파악해 해결할 수 있어야 한다. 프로젝트로 인해 파생되는 결과와 이것이 사용자에게 어떤 영향을 끼칠지에 대한 인사이트가 있어야 한다. 이것이 2024년 말에 깨달은 내가 생각하는 훌륭한 개발자의 지향점이고, AI의 등장으로 인해 이 지향점은 흔들리지 않는다. 그러나 나는 이러한 역량이 매우 부족하다. 프로젝트 규모가 조금만 커지거나 기술 스택이 복잡해지면 눈 앞의 일을 처리하기에 급급하다. 제대로 이해해보려고 시도하는 와중에 프로젝트는 빠르게 진행되어 놓치는 부분이 많다. 이를 보완하기 위해 문서를 작성하기 시작했다. 내가 이해한 바를 정리하고, 팀원분들이 이를 읽으면서 리뷰하는 과정에 잘못 이해하거나 놓치고 있는 부분이 있으면 금방 고칠 수 있다. 2025년에는 이러한 지향점을 바탕으로 조금 더 리더십과 프로젝트 인사이트가 있는 개발자가 될 수 있으면 한다.

02025. 01. 02.

일상 > 뉴욕 출장기

7일차 - 배터리 파크, 피자

뉴욕 출장의 마지막 날이다. 뉴욕 오피스의 팀원들과 자전거를 타고 맨해튼 남부까지 갔다. 오전 7시 30분 기상 마지막 날의 아침이 밝았다. 구름이 많이 끼고 날이 흐려 눈이 온 것 같은 분위기다/ 오전 9시 30분 아침 역시 오피스에서 아침을 먹었다. 베이컨 오믈렛, 에그 스크램블, 소시지, 감자, 그리고 부리또이다. 부리또에는 베이컨과 계란, 치즈, 감자가 들어가있는 듯 하다. 사실 잘 기억이 안난다. 오후 5시 30분 자전거 타기 일과 후 뉴욕 팀원들이랑 자전거를 타기로 했다. 맨해튼 서쪽 강변을 따라서 남쪽으로 내려갔다. 자전거로 어느 정도 이동한 후 걷기 시작했다. 맨해튼 남서쪽에 위치한 복합 시설로, 상가와 지하철이 연결되어 있다고 한다. 들어가보지는 않았다. 오후 6시 40분 저녁 저녁으로는 피자를 먹었다. Inatteso Pizzabar 라는 곳이었다. 세 판을 시켰는제 각 메뉴가 어떤 것인지는 정확히 기억나지 않는다. 그저 메뉴에 적힌 재료를 보고 추정만 해보았다. 오후 7시 30분 둘러보기 식사를 마치고 근처를 조금 더 둘러보았다. 해가 지고 있는데 이 시간까지 밖에 있어본 적이 없어서 무서웠지만 현지인이 함께 있으니까 크게 걱정되지는 않았다. 그런데 한 분에게 위험한 적 없었냐고 물어봤는데 갑자기 길 가다가 얼굴에 펀치를 맞은 적이 있다고 했다. 몇 년 전 이야기이긴 한데, 센트럴 파크 쪽에서 걷는 중에 한 커플의 남자가 갑자기 주먹을 날리고 웃으며 지나갔다고 했다. 확실히 이상한 사람은 많구나. 911 테러를 추모하기 위한 박물관이다. 오후 8시에 마감하는데 우리는 5분 전에 도착해서 얼른 밖에서 사진만 찍고 나왔다. 다시 오피스 근처로 왔다. 이렇게 늦게까지 밖에 나와 있다니. 생각보다 막 위험하다는 느낌은 들지 않았다. 뉴욕하면 치즈 케이크이다. 치즈 케이크로 유명한 매그놀리아 베이커리를 방문했다. 하지만 가장 인기 있는 오리지널 치즈 케이크는 다 팔리고 없어서 카라멜 피칸 치즈케이크를 샀다. 오후 10시 40분 공항 도착 인천행 비행기가 오전 1시이다. 2시간 반 정도 일찍 뉴어크 공항에 도착해서 탐승 수속을 했다. 팀원분이 비행기에서 잘 자라고 멜라토닌 초콜릿을 사다주셨다. 한 알에 1mg으로 적은 멜라토닌이 들어있는데 이런건 처음 먹어봐서 미지에 대한 두려움에 먹지는 않았다. 한국에 돌아와서 먹어봤는데 그냥 초콜릿이고 잠이 잘 오는 것도 모르겠다. 너무 소량인 듯 하다. 올 때 처럼 기내식을 맥주와 함께 먹었다. 이 때는 파우치는 안줬다. 두 번째 기내식이다. 저 오른쪽 위 초코 케이크가 부드럽고 맛있었다. 잠을 자다 깨다 하면서 심심할 때 책을 썼다. 팀원분들을 포함한 회사 사람들에게 보여주기는 부끄러웠지만 자리가 떨어져있어서 중간 중간 쓸 수 있었다. 이렇게 일주일간의 첫 뉴욕 출장이 막을 내렸다. 처음에 적응하는데 시간이 걸리고, 시간과 체력 한계 때문에 못 해본 것도 많지만 재미있고 유의미한 시간이었다. 특히 한국에서만 일을 하다가 미국에 나가 일을 하니 새삼 구글이라는 회사의 규모가 체감되었다. 내가 하고 있는 일도 그저 흘러가는 것이 아니라 조금 더 책임감을 가져야겠다는 생각과 함께, 형제 팀들에서 진행 중인 다양한 프로젝트를 보면서 시야도 넓어질 수 있었다. 이 때의 경험들을 기반으로 소프트웨어 엔지니어로서 발전시켜야 할 역량이 더욱 확실해진 느낌이다.

02024. 12. 30.

일상 > 뉴욕 출장기

6일차 - 브로드웨이 위키드 뮤지컬, 르뱅 쿠키, 스시

오랜만에 이어 쓰는 뉴욕 출장기.. 사진을 보며 당시 기억을 떠올리면서 써본다. 특히 이 날은 요즘 화제의 영화 위키드의 현지 브로드웨이 뮤지컬 버전을 본 날이다. 이 포스트를 일찍 썼어야 하는데... 오전 8시 30분 르뱅 쿠기 르뱅 쿠키는 한국에서 크고 두꺼운 쿠키의 종류로 알려져 있지만, 사실 미국 뉴욕의 Levain Bakery라는 곳에서 파는 쿠키이다. https://levainbakery.com/ 이곳의 쿠키가 워낙 독특하고 맛있어서 한국에서 르뱅 쿠키 스타일의 쿠키를 따라 만들며 쿠키의 한 종류처럼 유행하기 시작했다. Levain Bakery는 뉴욕에만 여러 종류가 있는데, 그 중 가장 큰 곳은 쿠키를 사기 위해 줄을 서서 기다려야 할 정도로 인기가 많다고 한다. 우리는 숙소에서 오피스를 가는 길에 작은 지점이 있어서 르뱅 쿠기를 포장해 오피스에서 아침과 함께 먹기로 했다. 오전 9시 아침 르뱅 쿠키를 포장해서 오피스에서 아침을 먹었다. 실외 테라스에 자리를 잡고 앉았는데, 쿠키가 있어서 나머지 음식은 그렇게 많이 담지는 않았다. 토스트와 스크램블 에그, 빵 하나와 작은 소시지 한 조각을 담아 왔다. 음료는 오렌지 주스이다. 뉴욕 오피스의 조망이 좋다고 들었고, 월요일에 오피스 투어를 하면서 봤지만 실외에서 아침을 먹으며 보는 경치는 또 달랐다. 완벽한 날씨에서 그늘진 곳에 자리를 잡아 완벽한 아침을 먹을 수 있었다. 아침을 먹고 있는 팀원들을 뒤로한 채 창피함을 무릅쓰고 셀카를 찍었다. 아침을 먹은 후 커피와 함께 르뱅 쿠키를 먹었다. 나는 다크 초콜릿 쿠키를 골랐는데 아주 달고 칼로리 높은 맛이었다. 한 번에 다 먹기는 힘들어서 조금 남겼던 것 같다. 오후 12시 점심 점심은 뉴욕 팀 사람들과 함께 피어 오피스에서 먹었다. 피어 오피스에 대한 내용은 이전에 작성했던 오피스 투어 포스트에서 찾아볼 수 있다. https://www.hyuni.dev/posts/iGsBxcX6PtrYUDhd8t0k 나는 해물로 만든 전 같은 걸 먹었는데 간이 좀 이상했다. 모든 음식이 너무 짰다. 심지어 사진 왼쪽에 있는 샐러드조차 소금 범벅인듯 했다. 과일은 맛있었다. 오후 5시 30분 모모야 첼시 위키드 뮤지컬을 보러 가기 전 저녁으로 스시를 먹기로 했다. 브로드웨이로 가는 길에 있는 모모야 첼시 (Momoya Chelsea)라는 곳을 방문했다. https://momoyanyc.com/chelsea.html 다 같이 먹을 수 있는 모듬 스시를 주문했는데, 정확한 메뉴는 기억이 안나니 사진만.. 가장 인상 깊어서 기억에 남은 스시는 캘리포니아 롤이다. 모듬 스시 2에서 가장 오른쪽에 있는 빈약한 롤이 캘리포니아 롤이었던 것 같다. 한국에서의 캘리포니아 롤은 뭔가 가득가득 들어있어서 터질 것 같은 경우가 많은데 여기는 그렇지 않았다. 뉴욕이라 캘리포니아 이름이 들어간 것에는 힘을 뺀 건가 싶었는데, 검색해보니 원래 캘리포니아롤은 아보카도, 오이, 게 맛살만 들어간다고 한다. 4명이서 먹었는데 음식 값이 $158.96, 팁으로 $30를 내서 총 $188.96을 지불했다. 현재 환율로 약 27만 7천원이다. 오후 6시 50분 브로드웨이 극장 위키드(Wicked) 뮤지컬을 보러 브로드웨이로 향했다. 극장은 보안과 경비가 철저했다. 모든 입장객이 금속 탐지기를 통과해야 했다. 500석 이상의 좌석이 있는 브로드웨이에서 총기사고라도 났다간 대참사일 것이다. 위 사진에서 왼쪽 아래 노란색으로 표시된 곳에 앉았다. 이 위치의 좌석에서는 이 정도 뷰가 나왔다. 웅장한 무대 세팅이 들어가자마자 시선을 사로잡았다. 아무래도 영어라 모든 대사를 알아듣기는 힘들었지만, (특히 노래는 80% 이상 못 알아들었다) 내용은 따라갈 수 있었다. 2 부로 나뉘어 진행됐는데 상당히 재미있었고, 왜 사람들이 뮤지컬을 보러 다니는지 알 것 같았다. 뮤지컬 가격을 보기 전까지는... 브로드웨이 위키드 뮤지컬 가격 뮤지컬을 예매할 때 분명 가격을 들었다. 그런데 달러였는지 체감이 안됐었나보다. 나중에 한국에 들어와서 정산할 때 보니 정산해야 할 금액이 생각보다 많았다. 그렇게 쓴 게 없는 것 같은데 뭐지 하고 보니까 뮤지컬이 거의 전부였다. 당시 가격으로 $158.50 이었으니 20만원이 넘는 가격이다. 재밌긴 했지만... 그정돈가...? 이런 교양 문화와 멀리 떨어져 있는 나는 한 번으로 족한 경험인 것 같다ㅋㅋ 뮤지컬을 마지막으로 이 날은 마무리되었다.

02024. 12. 30.

프로그래밍

제미나이로 지뢰 찾기 사이트 만들기

제미나이 2.0은 매우 강력한 성능을 가지고 있다. 현재 2.0은 실험적으로 공개된 상태인데, 다음의 두 모델이 공개되어 있다. 무료 버전인 Gemini 2.0 Flash 유료 버전인 Gemini 2.0 Advanced 제미나이 2,0은 이전 버전에 비해서 자연어 이해는 물론, 코드 생성 능력도 비교할 수 없을 만큼 향상되었다고 느꼈다. 이전 버전의 제미나이는 코드를 생성했다 하면 다음 문제점 중 하나를 가지고 있었다. 컴파일 되지 않는 코드 이전 버전의 코드 원하는 기능이 누락된 코드 제미나이 2.0은 이러한 점들이 대폭 개선되어 몇 번의 코드 생성만으로 거의 모든 원하는 결과를 얻을 수 있게 되었다. 지뢰 찾기 만들기 제미나이 2.0의 향상된 기능을 테스트해보고자 지뢰 찾기를 만들어 보았다. 이번 경험으로 제미나이를 활용한 개발에 대한 감을 잡을 수 있을 것이다. 1. 첫 코드 생성 맨 처음 다음과 같이 살짝 무책임하게 보일 수도 있는 프롬프트를 입력했다. " html / css / js로 지뢰찾기 만들어줘. 제미나이는 index.html, style.css, script.js 파일을 생성해 주었다. 이를 복사해서 넣어봤는데, 아무런 오류가 없었다..! 그리고 실행 화면도 놀라웠다. 상당히 깔끔하게 스타일을 입혀 놓았다. 배경 색과 지뢰 찾기 판의 색, 버튼 색까지 어색하지 않다. 기능도 잘 동작했다. 클릭으로 해당 칸 확인, 우클릭으로 지뢰를 표시할 수 있다. 왼쪽 위에는 첫 클릭 기준으로 게임 플레이 시간이 표시되며, 오른쪽 위에는 찾은 지뢰의 개수가 표시된다. 모든 지뢰를 다 찾으면 게임 승리 창도 띄워준다. 아래 난이도 버튼을 통해서 판의 크기를 조절할 수 있다. Beginner는 9 x 9 칸에서 10개의 지뢰를, Intermediate은 16 x 16 칸에서 40개의 지뢰를, Advanced는 30 x 16 칸에서 99개의 지뢰를 찾아야 한다. (해보니 지뢰가 너무 많은 것 같아 75개로 줄였다) 지뢰도 매번 랜덤으로 심기 때문에 중복 게임이 발생하지 않는다. 2. 지뢰 찾기 판 가운데 정렬 그런데 한 가지 걸리는 것이 있다. 다른 난이도에서는 괜찮은데, Beginner일 때 지뢰 찾기 판이 왼쪽으로 치우쳐져 있다. 이것을 수정해달라고 요청해보자. " Intermediate나 Advanced에서는 지뢰 찾기 판이 가운데 잘 있는데, Beginner에서는 왼쪽으로 치우쳐져있어. 제목이나 버튼 같은 다른 요소들은 괜찮은데 지뢰 찾기 판만 그래. 수정해줘. 제미나이 2.0은 성공적으로 원인을 찾아 수정 사항을 제시해 주었다. \ table { border-collapse: collapse; box-shadow: 0 0 10px rgba(0, 0, 0, 0.3); background-color: #eee; margin: auto; /* 이것을 추가하여 테이블을 중앙에 정렬 */ } 복사하기 편하게 전체 코드도 제공해 주었다. 제시된 수정 사항을 반영하여 다시 실행해보니, 원하는 대로 가운데에 지뢰 찾기 판이 정렬되게 되었다. 휠 클릭으로 인접 칸 열기 지뢰 찾기 게임에는 휠을 클릭하여 주변 지뢰를 모두 찾은 숫자 칸 주변을 자동으로 오픈하는 기능이 있다. 이를 구현하기 위해 다음과 같이 프롬프트를 추가로 입력했다. " 원래 지뢰찾기는 다음과 같은 편의 기능이 있어. "공개된 숫자 칸에 마우스 휠 버튼으로 클릭한 경우, 만약 해당 숫자 칸으로 인한 지뢰에 전부 깃발 표시를 한 상태이면, 해당 숫자 칸 주변의 8칸 중 나머지 칸을 자동으로 클릭하여 오픈." 이 기능을 구현해줘 제미나이는 코드를 뱉었고, 이를 적용해 보았다. 안타깝게도 코드에는 문제가 있었다. 마우스의 휠 클릭이 아니라, 휠을 돌렸을 때 해당 기능이 동작했다. 사실 몇 번 해보니 휠을 클릭하는 것보다 돌리는게 훨씬 편하긴 했지만, 원하던 방향은 아니니 다시 프롬프트를 입력했다. 제미나이는 다음과 같은 대답을 하며 수정된 코드를 알려 주었다. 휠을 "돌렸을 때"가 아닌 "클릭했을 때" 기능이 동작하도록 수정해달라는 요청을 정확히 이해했습니다. wheel 이벤트는 마우스 휠을 스크롤할 때 발생하기 때문에, 휠 클릭을 감지하려면 mousedown 이벤트를 사용하고 event.button 속성을 확인해야 합니다. event.button 값이 1이면 휠 클릭을 의미합니다. script.js에서 다음과 같이 수정합니다. 그리고 이 코드를 적용하니 휠을 클릭했을 때 주변 칸이 열리는 기능이 정상적으로 동작하였다. 3. 제미나이 2.0을 써보니... 제미나이 2.0이 공개되면서 코드 생성 성능 또한 매우 강력해졌다. 이번에 특히 느낀 것은 다음의 네 가지다. 코드에 버그가 없다.물론 완벽히 없을 수는 없겠지만 이번 지뢰 찾기 정도 수준에서는 찾아볼 수 없었다. 코드를 확인하지 않고 그대로 복사 붙여넣기만 했는데도 원하는 기능이 만들어졌다. 기억력이 좋아졌다.여러 차례 대화가 오갔음에도 처음 생성했던 코드 기반으로 업데이트를 해 나갔다. 기능이 추가되면서 수정된 코드나 처음의 코드를 잊어버릴 법 한데 원하는 수정을 다 할 때까지 누락된 것이 없었다. 이해를 잘 한다.내가 원하는 것을 파악하고 코드로 옮겨 주었다. 휠 클릭과 굴리는 것을 혼동하기는 했지만, 기능 자체는 매우 잘 구현하였고, 수정을 요청했을 때 바로 알아듣고 성공적으로 수정하였다. 답변이 길어졌다.이전에는 답변이 조금 길어진다 싶으면 에러를 뱉고 뻗어버리는 경향이 있었는데, 지금은 상당히 긴 답변을 한다. 지뢰 찾기를 작성하면서 부분적으로 코드를 수정할 때에도 수정된 부분을 보여주고, 이어서 전체 코드를 한 번 더 보여주었다. 이렇게 강력해진 제미나이를 활용하면 코드 작성에는 확실히 신경을 덜 쓸 수 있을 것이다. 앞으로 더욱 프로젝트의 방향성과 논리적 사고에 집중하며 실력 있는 개발자로서의 역량을 키워나갈 수 있을 것 같다. 이번에 작성한 지뢰 찾기 코드는 내 깃헙 Playground 리포지토리에서 찾아볼 수 있고, 다음 링크에서 실제로 해볼 수 있다. https://playground.hyuni.dev/minesweeper/

02024. 12. 27.

프로그래밍

SPA (Single Page Application)의 장단점 - 웹 퍼블리셔와 프론트엔드 개발자

웹 퍼블리셔라는 말을 들어본 적 있을 것이다. 이 용어는 디자인된 페이지를 그대로 HTML / CSS / JS로 옮기는 작업을 하는 사람들을 일컫는다. 얼핏 들으면 프론트엔드 개발자와 같은 역할인 것 같다. 실제로 이러한 인식 때문에 프론트엔드 개발자들이 백엔드 개발자보다 실력 없는 개발자라는 이야기가 많이 있었다. 그러나 웹 개발이 발전해 나감에 따라 웹 퍼블리셔가 없어지고 프론트엔드 개발자가 등장하게 된 데에는 이유가 있다. 이것을 이해하기 위해서는 과거의 웹 개발이 어땠는지 살펴보고, 웹 개발에 획기적인 전환점을 불러일크킨 SPA (Single Page Application)에 대해서 알아볼 필요가 있다. 과거의 웹 개발 전통적인 웹 개발은 백엔드 개발에 많은 부분 얽매여 있었다. 웹 사이트는 여러 개의 HTML 페이지로 구성된 MPA (Multi-Page Application) 형태였으며, 새로운 페이지를 요청할 때마다 서버는 매번 새로운 HTML 파일을 생성하여 브라우저에 전송했다. 즉, 모든 페이지의 렌더링이 서버에서 이루어지는 서버 사이드 렌더링 (Server-Side Rendering) 방식이었다. 이러한 구조에서 Javascript는 주로 폼 유효성 검사나 간단한 시각 효과를 위한 보조적인 역할에 머물렀다. 간혹 api 요청 등 비동기 작업이 있다고 하더라도 대부분의 로직은 서버에서 처리되었기 때문에, 프론트엔드 개발자의 역할은 상대적으로 제한적일 수 밖에 없었다. 과거 웹 개발 방식 (MPA)의 문제점: 느린 페이지 로딩새로운 페이지를 요청할 때마다 전체 페이지를 다시 로드해야 했기 때문에 속도가 느리고 사용자 경험이 좋지 않았다. 아예 새로운 페이지를 로딩하는 것은 감안하더라도, 페이지의 일부분만 업데이트 할 때도 페이지 전체를 새로 로드해야 했다. 높은 서버 부하모든 페이지 요청에 대해 서버가 전체 HTML을 생성해야 하므로, 서버 부하가 높고 많은 양의 데이터가 전송되어야 했다. 제한적인 상호작용사용자와의 상호작용이 많은 웹 애플리케이션을 구현하기 어려웠다. 부드러운 페이지 전환은 불가능했고, Javascript의 비중이 많은 페이지를 개발하는 것도 쉽지 않았다. 복잡한 상태 관리여러 페이지에 걸쳐 애플리케이션의 상태를 관리하는 것이 번거로웠다. SPA의 등장 이러한 문제점을 해결하기 위해 등장한 것이 바로 SPA (Single Page Application) 이다. SPA는 이름 그대로 단 하나의 HTML 페이지를 기반으로 하는 웹 애플리케이션이다. (간혹 여기서 오해하는 경우가 있는데, 개발은 여러 HTML 페이지로 한다. SPA는 이를 webpack으로 묶어 하나의 HTML 파일로 빌드한다.) React.js, Angular, Vue.js와 같은 프레임워크 및 라이브러리가 SPA를 구현하기 위해 대표적으로 사용되며, 최초 로드 시 하나의 HTML 페이지만을 받고, 이후에는 Javascript를 사용하여 동적으로 콘텐츠를 변경하는 클라이언트 사이드 렌더링 (Client-Side Rendering) 방식을 사용한다. SPA는 사용자와의 상호작용에 따라 필요한 데이터만 서버로부터 비동기적으로 가져와(AJAX, Fetch API 등) 화면의 일부분만 업데이트한다. 따라서 전체 페이지를 다시 로드할 필요가 없기 때문에, 훨씬 빠르고 부드러운 사용자 경험을 제공할 수 있다. SPA의 장점 빠르고 반응성 좋은 사용자 경험페이지 전체를 다시 로드하지 않기 때문에, 부드러운 화면 전환과 빠른 반응 속도를 제공한다. 서버 부하 감소필요한 데이터만 요청하고 클라이언트 측에서 렌더링을 수행하기 때문에, 서버 부하를 줄일 수 있다. 코드 재사용성 및 유지보수 용이컴포넌트 기반 아키텍처를 통해 코드의 재사용성을 높이고 유지보수를 쉽게 할 수 있다. SPA의 장점은 그 무엇보다 사용자 경험이 크게 향상된다는 것에 있다. 버튼을 클릭할 때 마다 페이지 전체가 로딩되던 과거와 달리, 버튼을 누르자마자 페이지가 부드럽게 전환되고, 데이터가 로드되면 자연스럽게 보여주는 방식은 SPA를 사용하는 브랜드 자체를 더욱 친근하고 고급스럽게 만들었다. SPA의 대표격인 리액트의 수요가 크게 증가했으며, 단순히 디자인 된 것을 코드로 옮기기만 하는 웹 퍼블리싱보다 더욱 높은 기술적 난이도가 요구되었다. 부드러운 사용자 경험이 안정적인 서비스만큼 중요해지면서 프로젝트에서 Javascript의 비중이 함께 증가했고, 재사용성 높은 컴포넌트를 설계하고 복잡한 프로젝트를 오류 없이 관리해나가는, "엔지니어"의 역량이 필요해진 것이다. 이 때 부터 퍼블리싱 보다는 더욱 사용자와 가까이서 그들을 이해하고, HTML, CSS, Js를 넘어 여러 라이브러리와 프레임워크를 활용하여 알맞는 기술적 솔루션을 구현해내는 프론트엔드 개발자가 등장하기 시작하고, 프론트엔드 기술도 한층 박차를 가해 발전하기 시작했다. SPA의 단점 초기 로딩 속도초기에 모든 Javascript 파일을 로드해야 하기 때문에 초기 로딩 속도가 느릴 수 있다. SEO (검색 엔진 최적화) 문제검색 엔진 크롤러가 Javascript를 실행하지 못하는 경우, 콘텐츠를 제대로 수집하지 못할 수 있다. 대부분의 최근 검색 엔진 크롤러는 SPA를 고려하여 Javascript를 실행한 후, 콘텐츠가 로드되면 크롤링을 한다. 보안클라이언트 측에서 많은 로직이 처리되기 때문에 보안에 더 신경 써야 한다. 높은 사용자 친화적 경험을 제공해서 각광받았던 SPA는 시간이 지남에 따라 그 단점 또한 부각되었다. 대부분의 단점들은 SPA가 발전해나감에 따라 같이 해결되었지만, 기술적 한계로 인해 그렇지 못한 것들도 있다. 초기 로딩 속도 같은 경우, 사이트 전체에서 사용될 코드를 전부 초기 로딩 시에 불러오기 때문에 느릴 수 밖에 없다. 한 번 로드된 이후부터는 매우 빠르게 페이지를 전환할 수 있다는 장점에 대한 트레이드 오프이다. 보안은 각별히 신경써야 한다. 대부분의 로직이 서버에서 돌아가던 과거와 달리, 클라이언트에서 돌아가는 로직은 전부 공개된 것이나 다름 없다. SPA를 구동하기 위한 Javascript는 브라우저에서 실행되어야 하기 때문에 브라우저의 개발자 모드를 열어보면 전부 까볼 수 있다. 난독화 과정을 거치기는 하지만 마음만 먹으면 읽을 수 있기 때문에 안전하다고는 할 수 없다. Javascript에서 사용하는 API 키나 비밀번호 같은 중요한 정보도 모두 공개되기 때문에 중요한 정보는 노출시키지 않도록 세심한 주의가 필요하다. SPA는 분명 장점과 단점을 모두 가지고 있으며, 이러한 단점을 보완하기 위한 차세대 라이브러리와 프레임워크 또한 많이 등장했다. 그러나 사용자에게 더 나은 경험을 제공하고, 개발 생산성을 향상시킬 수 있는 잠재력이 크기 때문에, 현대 웹 개발의 핵심 기술로 자리 잡았다. SPA의 단점을 보완하는 Next.js 등과 같은 프레임워크도 React.js 기반이므로 React.js와 SPA의 장단점을 명확히 파악한다면 Next.js가 어떤 문제를 풀기 위해 탄생했는지, 그로 인해 발생하는 Next.js의 장단점은 무엇인지 또한 자연스럽게 알 수 있을 것이다.

02024. 12. 27.

일상

나의 세 가지 글 쓰기 - 블로그, 요즘 IT, 그리고 책

나의 첫 번째 책 취업과 이직을 위한 프로그래머스 문제 풀이 전략: 자바편을 출간한 후로, 글을 자주 쓰게 되었다. https://www.hyuni.dev/posts/qqK2tlLCrOyYAuahj8FY https://www.hyuni.dev/posts/6DfarGbSppjAMB2AHkY6 확실히 책 하나를 목표로 잡고 달렸던 경험이 글을 쓰는데 있어서 큰 도움이 된 듯 하다. 나는 지금 세 군데 글을 쓰고 있다. 블로그 요즘 IT 책 이번 포스트에서는 이 세 매체에 대한 나의 생각을 정리해보고, 이를 기반으로 각 매체에 어떤 성격을 글을 위주로 쓸지를 정해보려 한다. 각 매체 성격 분석하기 우선 세 매체에서 다루는 글의 성격과 독자층에 대해 생각해보자. 1. 블로그 https://www.hyuni.dev 블로그는 온전한 나의 공간이다. 내가 작성하고 싶은 주제와 내용으로 마음껏 글을 쓸 수 있으며, 분량 제한도 없다. 심지어 지금 운영 중인 블로그는 개발까지 내가 하고 있어 블로그의 시스템과 연계한 글도 작성할 수 있다. 나만의 공간이고 별도의 홍보도 하지 않으므로 방문 수가 적어도 별로 신경 쓰이지 않는다. 오히려 그것이 당연하다고 생각한다. 한글로만 작성된 개발 블로그에 대한 수요는 그렇게 많지 않을 것이다. 이러한 성격의 블로그가 높은 조회수를 기록하기 위해서는 트렌딩한 주제를 들고 오거나 물량으로 승부를 봐야 할 것이다. 그러나 블로그 글의 주제를 찾으려 고군분투하며 스트레스 받고 싶지 않기 때문에 공유할만한 주제가 있을 때마다 기록해두고, 포스트로 작성하는 것이 좋을 것 같다. 블로그의 독자층은 매우 다양하다. 전문적인 정보를 검색하는 사람들도 있을 것이고, 프로그래밍 초기에 자주 접하는 에러를 검색하다가 내 블로그를 접하는 사람들도 있을 것이다. 이들의 공통점은 원하는 정보가 명확하다는 것이다. 길게 늘어진 정보 보다는 찾고자 하는 정보에 대한 답을 빠르게 얻을 수 있는 글을 선호한다. 2. 요즘 IT https://yozm.wishket.com/magazine/@spaceship00/ 요즘 IT는 구글 문서 기준 약 5 페이지 정도의 분량의 단편적인 글을 위주로 기고한다. 주제 제안 후 원고 집필을 하게 되고, 검토와 교정을 거친 후 요즘 IT에 등재된다. 요즘 IT의 장점은 독자층이 많다는 것이다. 내가 지금까지 요즘 IT에 기고한 4개의 글 중 가장 조회수가 적은 글도 조회수가 7천 이상이다. 요즘 IT는 주니어 레벨 독자층이 많은 듯 하다. 사실 나는 내가 기고한 글 중 위의 글이 개발자에게 있어서 가장 중요한 글이라고 생각한다. 논리적 사고로 문제를 해결하는 과정을 직접 따라가 보는 것은 논리적 사고의 흐름에 대한 시야를 틔워줄 수 있는 계기가 될 수 있을 것이라 생각하기 때문이다. 그러나 기고한 다른 글들, 이를테면 "코딩 테스트 준비 팁"이나 "코드 스타일의 중요성"과 같은 글이 훨씬 높은 조회수를 기록했다. 아무래도 이러한 글들은 조금 더 직관적이고 이해하기 쉬운 내용이어서 그런 것 같다. 3. 책 책에 들어가는 글은 가장 집중해서 써야 하는 글이다. 책은 한 번 인쇄 후에는 수정이 불가능하고, 분량도 매우 많다. 종이책이라는 현물을 만들어 내는 것이기에 리스크도 크고 도전적이다. 그러나 그만큼 따라오는 보상도 크다. 내가 이렇게 블로그와 요즘 IT에 글을 쓰고 있는 것도 첫 번째 책을 집필했기 때문이 크다. 글을 쓰는 것의 힘을 알게 되었고, 나의 생각을 글로 표현하는 것의 재미를 느끼게 되었다. 첫 번째 책을 쓸 기회를 얻지 않았다면 지금 이렇게 글을 쓰고 있는 시간에 나는 무엇을 하고 있었을까? 책은 확실한 독자층을 설정해 놓아야 한다. 그리고 그 독자들 입장을 최대한 생각하며 글을 작성해야 한다. 글은 독자들이 천천히 이해할 수 있도록 내용을 유기적으로 연결시켜 써서 그저 정보를 모아놓은 문서 덩어리가 되지 않도록 주의해야 한다. 앞으로 내가 쓸 글 세 매체의 성격이 매우 다르므로 각 매체에 쓸 글의 성격도 다를 것이다. 블로그가벼운 글 단편적인 정보 전달 글 블로그의 기능과 연계하여 쓰는 글 요즘 IT어느 정도 분량이 있는 글 나의 인사이트를 공유하는 글 개발자들에게 일반적으로 적용되는 글 책책의 주제와 유기적으로 연결되는 글 나의 경험을 상세하게 풀어 공유하는 글 블로그는 쉽게 쓸 수 있지만 나 혼자의 만족으로 끝나는 경우가 많다. 요즘 IT는 주제와 분량에 어느 정도 제한이 있지만, 조회수나 댓글 등으로 즉각적 피드백을 받을 수 있다. 책은 가장 오래 걸리고 분량도 많지만 그만큼 한 번 출간했을 때 얻을 수 있는 것이 크다. 노린 건 아니지만 어떻게 하다 보니 세 매체가 서로 균형을 이루게 되었다. 이제 블로그와 요즘 IT, 책 집필의 역할이 모두 정해졌으니 글을 쓸 일이 생겼을 때 주저하지 않고 알맞은 곳을 선택하여 쓸 수 있을 것이다.

02024. 12. 26.

Next.js

Server Component와 Client Component 구분하기

내 블로그는 Next.js로 돌아간다. 포스트의 내용 중 링크가 있으면 Open Graph로 보여주는데, 이를 통해 해당 링크의 제목, 이미지 등 대표적인 내용을 보여줄 수 있다. 링크에서 Open Graph의 내용을 가져오려면 네트워크 요청을 보내야 한다. 그렇기 때문에 server component에서는 async 컴포넌트로 데이터를 가져온 후 렌더링해서 보내준다. if (href != null && href === children?.toString()) { return <OpenGraphBlock url={href} /> } :: 기존의 서버 사이드 Open Graph 렌더링 컴포넌트 :: 문제는 포스트를 쓰는 중 "미리보기"를 할 때 발생했다. 미리보기는 포스트의 내용을 서버에서 렌더링하는 것이 아니라 클라이언트에서 가지고 있는, 현재 작성 중인 내용을 가지고 렌더링한다. 같은 Open Graph 컴포넌트를 사용하면 클라이언트 사이드에서 async 컴포넌트를 호출하게 되는 것이다. 이는 다음과 같은 에러를 발생시켰다. Application error: a client-side exception has occurred (see the browser console for more information). 클라이언트 사이드에서 async 컴포넌트를 렌더링할 수 없어서 생긴 에러였다. 이 에러가 발생하는 것은 진작 알고 있었지만 어차피 게시글은 나 혼자 쓰는 것, 그냥 조금 조심하면서 쓰면 되지 하는 마인드로 미뤄놨었다. 그러나 링크를 많이 사용할 포스트를 작성할 일이 생겨, 수정하기로 했다. 이를 해결하기 위해서는 현재 컴포넌트가 서버 사이드에서 렌더링 되는지, 클라이언트 사이드에서 렌더링 되는지를 알아야 했다. typedef window == 'undefined' 방법은 매우 간단했다. window가 정의되어 있는지를 확인하면 됐다. 서버 사이드의 경우 window 객체가 없기 때문에 그 타입이 undefined이다. 이를 활용하면 undefined인 경우 서버 사이드, 그렇지 않은 경우 클라이언트 사이드임을 알 수 있다. if (typeof window == 'undefined') { return <OpenGraphBlockServer url={href} /> } else { return <OpenGraphBlockClient url={href} /> } :: 렌더링 위치를 구분한 Open Graph 컴포넌트 :: 이제 게시글을 작성할 때에도 링크 포함 여부 상관 없이 미리 보기를 보면서 작성할 수 있게 되었다.

02024. 12. 25.

일상

구글 드라이브로 이미지 호스팅하기 (<img>용 링크 변환)

지금껏 블로그에 올리는 이미지들은 대부분 파이어베이스 스토리지를 사용하고 있었다. 파이어베이스 무료 요금제로는 용량과 대역폭 제한이 있기 때문에 이미지를 올릴 때 원본을 올리기가 망설여졌다. 휴대폰으로 찍은 원본 이미지 몇 장만 들어가도 전송량이 너무 커지기 때문에 유료 요금제로 바꿔야 하나 싶었다. 그런데 나는 구글 드라이브 5TB 용량을 구독하고 있다. (회사 복지 아님. 돈 내고 쓰는 중) 아직 이 중 1.5TB도 사용하고 있지 않다. 구글 드라이브에 블로그 용 이미지를 저장하고, 그 링크를 이용하면 용량이나 대역폭 걱정 없이 이미지를 마음껏 넣을 수 있을 것 같아 알아본 방법을 공유한다. 이미지를 블로그에 넣으려면 태그의 src 속성에 넣을 수 있어야 한다. 그러나 구글 드라이브는 웹에서 들어갔을 때 얻을 수 있는 링크가 이미지 파일 자체 링크가 아닌, 이미지 뷰어의 링크이기 때문에 태그에 직접 넣어줄 수 없고, 변환을 해주어야 한다. 구글 드라이브에 이미지 저장용 폴더를 만들고 태그용 링크를 얻는 것 까지의 과정은 다음과 같다. 1. 이미지 저장용 폴더 생성 나는 블로그에 들어갈 이미지를 호스팅할 것이기 때문에 Blog 폴더 아래에 Images 폴더를 생성해주었다. 이 폴더에 있는 이미지들은 모두 공개되어야 한다. 다음과 같이 폴더에 우클릭 -> 공유 -> 공유 를 선택해준다. 공유 다이얼로그가 뜨면 일반 액세스에 링크가 있는 모든 사용자를 선택해 뷰어 권한을 준다. 2. 이미지 업로드 생성한 Images 폴더에 들어가 공유할 이미지를 업로드한다. 나는 블로그를 작성하면서 찍은 스크린샷들을 올려놓았다. Images 폴더가 공유되어 있기 때문에 이 안의 이미지들은 자동으로 공개되어 있는 상태이다. 3. 이미지 링크 이미지를 태그에서 보여주기 위해서는 우선 이미지의 id를 알아야 한다. 이를 위해 이미지에 우클릭 -> 공유 -> 링크 복사를 선택한다. 그러면 다음과 같은 링크가 생성된다. https://drive.google.com/file/d/1iV4jl41tIfLpSvwZdPpxryO2nkcCIq8u/view?usp=drive_link 이 중 가운데 부분이 이미지의 id이다. 1iV4jl41tIfLpSvwZdPpxryO2nkcCIq8u 이 것을 다음 링크 뒤에 붙여준다. https://lh3.googleusercontent.com/d/{이미지 id} 그러면 다음과 같이 태그 안에 넣을 수 있는 이미지 링크가 된다. <img src="https://lh3.googleusercontent.com/d/1iV4jl41tIfLpSvwZdPpxryO2nkcCIq8u" /> 게시글을 쓸 때마다 이미지 용량이 걱정이었는데, 이제 마음껏 올릴 수 있게 되어서 마음이 편하다. 다만 매번 링크를 변환해주어야 하는 것이 번거로운데, 게시글 작성하는 페이지에 간단하게 변환 툴 하나 넣어놓아야겠다.

02024. 12. 24.

Articles

Recent Posts