개발자 퉁이리

2023 회고

퉁이리 — Wed, 3 Jan 2024 03:13:48 +0900

2023년은 제게 있어, 새로운 경험과 도전이 가득했던 해였습니다.

프로그래머스 데브코스에서의 학습, 카카오브레인에서의 인턴 생활, 그리고 네이버 면접까지.

각각의 경험은 새로운 지식과 시야를,

실패를 겪으면서는 다시 일어서는 법을 배웠습니다.

1️⃣ 문제의 근본적인 이해: 멈추지 않는 질문

문제 해결에 있어서 '왜'라는 질문은 단순히 문제를 해결하는 것을 넘어 근본 원인을 이해하는 데 중요한 역할을 합니다. 제 경험을 예로 들어볼까요? 한 프로젝트에서 메모리 부족 문제에 직면했을 때, 표면적인 해결책으로는 단순히 메모리를 증가시키는 것이었습니다. 그러나 이러한 접근은 문제의 근본적인 원인을 파악하고 해결하는 데 도움이 되지 않았습니다.

저는 이 문제를 다루면서 먼저 '왜 이런 문제가 발생했는가'에 대해 심층적으로 생각하기 시작했습니다. 이 과정에서 여러 가능성을 고려하게 되었어요. 가령, 가비지 컬렉션(GC)이 제대로 작동하지 않고 있을 수도 있고, 메모리 누수가 어딘가에서 발생하고 있을 수도 있었습니다. 이러한 질문들은 문제를 단순히 표면적으로 해결하는 것을 넘어서, 프로젝트 전체에 대한 깊은 이해로 이어졌습니다.

결국, 메모리 누수의 원인을 찾아내고 해결함으로써, 이 문제는 프로젝트의 전반적인 성능 향상으로 이어졌습니다. 이 경험을 통해 저는 근본적인 원인 분석의 중요성을 깊이 인식하게 되었으며, 이는 제 프로그래밍 접근 방식에 중요한 변화를 가져왔습니다.

2️⃣ 색 없는 사람: 어느 팀에서든 적응 및 기여

카카오브레인에서의 인턴 생활을 통해 저는 두드러지게 눈에 띄는 것보다는 조직에 자연스럽게 녹아들며 기여하는 것의 중요성을 배웠습니다. 대부분의 큰 기업들, 특히 카카오 같은 곳에서는 개별적으로 돋보이기보다는 팀이 큰 기여하는 것을 선호합니다. (이미 개개인이 돋보인다..) 여기서의 핵심은 기술적 역량을 바탕으로 묵묵히 자신의 역할을 수행하며, 동시에 팀 전체의 성과에 기여하는 것입니다. 예를 들어, 카카오브레인에서는 매주 금요일마다 팀에서 임팩트 있는 성과를 보여주는 것이 중요했습니다.

제가 말하는 '색 없는 사람'이라는 개념은 어느 팀에서든 자신의 역할을 잘 수행하고, 팀의 다양한 환경에 쉽게 적응할 수 있는 유연성을 의미합니다. 반면, '색이 있는 사람'은 특정한 환경이나 팀 구성에 더 적합할 수 있으며, 그렇지 않은 환경에서는 그들의 역량을 충분히 발휘하기 어려울 수 있습니다. (카멜레온 같은 사람이 되고 싶었지만 투명한 색은 생각하지 못했던 것 같다.)

저는 어떤 팀에서든 쉽게 녹아들 수 있는, 유연하고 조화롭게 기여할 수 있는 사람이 되고자 합니다.

3️⃣ 감당 안 되는 긴장 : 철저하게 준비하기

네이버 인턴 면접은 제가 지금까지 경험한 면접 중 가장 떨렸던 면접이였습니다. 세분의 면접관님들은 짧은 면접시간임에도 제 긴장을 풀어주시기 위해 노력했지만 이것만, '이 면접을 통과하면 네이버에 간다'라는 생각으로 이어져, 더 긴장되는 순간으로 만들었고 제 자신의 발목을 제대로 붙잡게 되었습니다.

이 과정에서 중요한 교훈을 얻었습니다. 네이버 서류와 코딩 테스트에 합격한 후, 면접 날짜가 바로 이틀 후에 잡혔습니다. 준비할 수 있는 시간이 짧았지만 저는 가능한 한 많은 케이스를 대비하려 애썼습니다. 하지만 실제 면접에서는 제가 준비한 질문들이 나오지 않았고, 이는 준비의 중요성과 긴장을 관리하는 방법에 대해 다시 생각하게 만들었습니다.

준비는 단순히 특정 케이스에 집중하는 것이 아니라, 다양한 가능성을 고려하는 것이며, 긴장을 최소화하는 것임을 배웠습니다. 종합적인 준비는 긴장된 상황에서도 침착하게 대처할 수 있는 기반을 제공합니다. 준비가 부족했다면, 긴장감은 증가하고, 생각이 정리되지 않아 면접에서 효과적으로 자신을 표현하는 데 실패할 수 있습니다. 이번 면접을 통해 이를 몸소 체험했습니다.

2024년은 이러한 교훈들을 바탕으로 더 큰 도전에 맞서고, 제 역량을 한계 없이 확장하는 것입니다.

올 한해 모두 같이 성장하고 배우는 한 해가 되기를!!!

감사합니다 (+_+)

프론트엔드 이미지 최적화: 압축, 변환을 활용한 효율적인 이미지 관리

퉁이리 — Fri, 5 May 2023 20:02:48 +0900

웹 사이트와 애플리케이션에서 이미지는 사용자 경험(UX)에 큰 영향을 미칩니다. 이미지와 원활한 로딩 속도는 사용자의 만족도를 높이고, 결과적으로 전환율과 사용자 참여도를 향상시킵니다.

계속 올라가는 이미지 크기

최근 초고속 인터넷 시대에 접어들면서 사용자는 더 좋은 화질을 원하고 자연스럽게 이미지 크기는 점점 더 커지고 있습니다. 하지만, 고화질 이미지는 용량이 크고 로딩 속도가 느려질 수 있으며, 이는 사용자 경험에 부정적인 영향을 줄 수 있습니다. 따라서 이미지 최적화는 프론트엔드 성능 향상에 핵심적인 역할을 합니다.

콘텐츠 유형 및 파일 형식

이미지 파일은 웹 사이트에서 가장 많은 용량을 차지하는 콘텐츠이기도 합니다. 2022년 HTTP 아카이브 연구에 따르면, 페이지 용량에 가장 큰 영향을 주는 리소스 콘텐츠 유형의 중앙값을 확인했을 때, 이미지가 데스크탑 페이지에서 1,026KB로 가장 큰 비중을 차지하고 있음을 알 수 있습니다(모바일에서는 811KB).

이미지 종류

웹 사이트와 애플리케이션에서 사용되는 이미지에는 여러 종류가 있습니다. 일반적으로 사용되는 이미지 형식으로는 JPEG, PNG, GIF, SVG, WebP 등이 있습니다. 각 형식은 서로 다른 용도와 특성을 가지고 있으며, 웹 개발자는 상황에 맞는 적절한 이미지 형식을 선택해야 합니다.

JPEG (Joint Photographic Experts Group): JPEG는 손실 압축 방식의 이미지 포맷으로, 사진이나 그림과 같은 복잡한 그래픽을 효율적으로 저장할 수 있습니다. JPEG는 압축률을 조절하여 이미지 품질과 파일 크기 사이의 균형을 찾을 수 있습니다. 일반적으로 웹에서 사용되는 사진이나 배경 이미지에 주로 사용됩니다.

PNG (Portable Network Graphics): PNG는 무손실 압축 방식의 이미지 포맷으로, 투명도(알파 채널)를 지원합니다. 디지털 아트, 아이콘, 로고 등의 이미지에 적합하며, 선명한 텍스트나 선 그림을 포함한 이미지에 유용합니다. 하지만 파일 크기가 큰 편입니다.

GIF (Graphics Interchange Format): GIF는 무손실 압축 방식의 이미지 포맷으로, 256색까지만 지원하는 제한된 색상 팔레트를 가집니다. 이러한 제한 때문에 사진 등의 고화질 이미지에는 적합하지 않지만, 간단한 애니메이션을 만드는 데 주로 사용됩니다.

SVG (Scalable Vector Graphics): SVG는 벡터 그래픽을 표현하기 위한 XML 기반의 이미지 포맷입니다. 벡터 이미지는 확대/축소 시 품질이 손상되지 않아, 아이콘, 로고, 일러스트 등의 웹 요소에 적합합니다. 또한, 스타일 및 애니메이션을 CSS와 JavaScript를 통해 조작할 수 있습니다.

WebP: WebP는 Google이 개발한 이미지 포맷으로, 손실 압축과 무손실 압축 두 가지 방식을 모두 지원합니다. 높은 압축률을 유지하면서도 이미지 품질을 유지할 수 있어, 웹 성능 최적화에 유용합니다. 하지만 아직 모든 브라우저에서 지원되지는 않습니다.

AVIF (AV1 Image File Format): AVIF는 Alliance for Open Media가 개발한 이미지 포맷으로, AV1 비디오 코덱을 기반으로 합니다. 손실 압축을 사용하며, WebP와 비교하여 더 높은 압축률과 이미지 품질을 제공합니다. 최신 브라우저에서 점차 지원되고 있으나, 일부 브라우저에서 지원되지 않을 수도 있습니다.

이러한 이미지 포맷들은 각각의 특성과 용도에 따라 웹 개발에서 적절하게 사용되어야 합니다. 그런데 위 설명에서 소개된 손실 압축과 무손실 압축은 무엇일까요?

이미지 변환 기법: 무손실 압축과 손실 압축

이미지 최적화에는 무손실 압축과 손실 압축 두 가지 기법이 사용됩니다. 무손실 압축은 이미지 품질을 손상시키지 않고 파일 크기를 줄이는 방법이며, 손실 압축은 이미지 품질을 손상시켜도 파일 크기를 더욱 줄일 수 있는 방법입니다.

이미지 손실 압축 (Lossy Compression):

손실 압축은 원본 이미지의 일부 정보를 버림으로써 이미지의 크기를 줄입니다. *손실 압축 알고리즘은 이미지의 눈에 띄지 않거나 덜 중요한 부분에 대해 데이터를 제거함으로써 압축을 수행합니다. 손실 압축은 일반적으로 높은 압축률을 제공하지만, 원본 이미지와의 완전한 복원은 불가능합니다. JPEG는 손실 압축 방식으로 널리 사용되는 이미지 포맷입니다. JPEG 압축은 DCT (Discrete Cosine Transform) 기반의 알고리즘을 사용합니다.

*JPEG 압축 - DCT (Discrete Cosine Transform) 기반의 알고리즘:

DCT는 이미지를 주파수 도메인으로 변환하고, 고주파 영역의 정보를 삭제하여 이미지 크기를 줄입니다. JPEG 압축률을 조절할 수 있어, 원하는 품질과 파일 크기 간의 균형을 맞출 수 있습니다.

이미지를 8x8 픽셀 블록으로 나눕니다.
각 블록의 픽셀 값을 0-255 범위에서 -128~127 범위로 조정합니다. - 데이터 정규화
DCT를 사용하여 각 블록을 주파수 도메인으로 변환합니다. - 이산코사인변환
양자화 과정을 통해 고주파 계수를 삭제하고 압축률을 조절합니다.
남은 계수를 엔트로피 코딩을 사용하여 더욱 압축합니다.

손실 압축 이미지 종류

JPEG
JPEG 2000
WebP
AVIF 등

무손실 압축 알고리즘 (Lossless Compression Algorithm):

무손실 압축 알고리즘은 원본 데이터를 정확하게 복원할 수 있는 방식으로 데이터 크기를 줄입니다. 이 방식은 이미지 데이터의 패턴과 반복을 인식하고, 이를 효율적으로 표현하여 압축을 수행합니다. PNG는 무손실 압축 이미지 포맷입니다. PNG 압축은 DEFLATE 알고리즘을 사용하여 이미지 데이터를 압축합니다. DEFLATE는 LZ77 및 허프만 코딩(Huffman coding)을 결합한 알고리즘으로, LZ77은 이미지 데이터의 반복 패턴을 인식하고, 허프만 코딩은 데이터의 빈도에 따라 코딩을 최적화합니다.

전공자라면 매우 익숙한 ... 그 이름, 허프만.
허프만 코드(Huffman's Code)는 허프만 알고리즘에 의해 생성된 최적 이진코드를 말한다.

무손실 압축 이미지 종류

PNG
GIF
WebP 등

용량을 상대적으로 많이 줄여주는 손실 압축 이미지를 활용하여 로딩 속도를 개선하면 좋을까요? 이미지 용량을 줄이려면 손실을 시켜야하고 손실을 아무런 기준없이 진행하면 위험합니다. 사용자 경험과 이어지기 때문입니다.

사람은 명암 차이에는 민감한 반면, 채색 차이에는 크게 민감하지 않아 이미지 색이 비슷한 부분을 하나로 통일하여도 일반적으로 사용자는 눈치채기 어렵습니다. 또한 약간의 화질 차이에도 그렇게 민감하지 않습니다. 이러한 부분들을 위에서 소개드린 알고리즘을 통해 손실시켜 이미지 용량을 줄이면서 사용자 경험을 향상시키면 보다 효율적인 웹사이트를 만들 수 있습니다.

그러면 의문점
몇퍼센트나 손실시켜야할까? 기준이 있을까?

https://github.com/rflynn/imgmin

Imagin 프로젝트의 연구조사에 의하면 75% 손실까지는 품질 차이가 거의 없다고 합니다.

For an average JPEG there is a very minor, mostly insignificant change in apparent quality from 100-75, but a significant filesize difference for each step down. This means that many images look good to the casual viewer at quality 75, but are half as large than they would be at quality 95. As quality drops below 75 there are larger apparent visual changes and reduced savings in filesize. - Imagin progject

75% 이하로 내려가는 순간 사용자가 시각적 반응에 민감해진다고 하니, 연구조사 결과를 통해 75%까지 손실 기준을 잡을 수 있을 것 같습니다.

지금까지 현대 웹 생태계에서 이미지의 중요성을 살펴보았고, 다양한 이미지 종류와 손실 압축 알고리즘, 무손실 압축 알고리즘에 대해 알아보았습니다. 또한, 얼마나 손실이 발생해도 사용자가 허용 가능한지에 대한 연구 결과를 살펴보았습니다. 지금부터 이미지 최적화를 어떻게 실제로 적용할지에 대해 알아보겠습니다.

우리는 이미지를 가볍게 만드는 방법에 대해 이해했습니다.

그렇지만 이미지를 가볍게 만들었다고 해도, 최근에는 다양한 디바이스로 인해 화면 크기가 다양하기 때문에 각 상황에 맞는 적절한 이미지를 브라우저에 로딩하는 것이 중요합니다. 모바일 화면(382 x 466)에서 4K 화면(3,840 X 2,160)에서 사용될 이미지를 다운로드 받는 것은 비효율적이기 때문입니다.

이제 화면 크기에 맞는 적절한 이미지를 보여주는 방법을 알아볼 필요가 있습니다.

https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

srcset 속성

srcset은 브라우저에게 제시할 이미지 목록과 그 크기를 정의합니다. HTML의 <img> 태그에 사용되며, 브라우저에게 여러 이미지 소스를 제공하고 이미지를 다양한 해상도에서 표시할 수 있게 합니다. 이를 통해 반응형 웹 디자인에서 디스플레이 크기나 픽셀 밀도에 따라 가장 적절한 이미지를 선택하고 로드할 수 있습니다.

<img src="tooo1-small.jpg"
     srcset="tooo1-small.jpg 480w, tooo1-medium.jpg 720w, tooo1-large.jpg 1280w"
     alt="퉁이리가 짱이다">

(스크린 리더): 퉁이리가 짱이다 이미지

alt 속성에 이미지라는 단어는 안 넣어도 돼요!
스크린 리더가 <img>를 통해 ‘이미지’로 결정해줘요.

그리고
저처럼 사용하시면 안 돼요. (퉁이리가 짱이다)
이미지에 적합한 대체 텍스트를 사용해 주세요!

여기서 src 속성은 기본 이미지를 설정하고, srcset 속성에는 각 이미지 파일과 그에 해당하는 이미지의 너비(해상도)를 지정합니다. w 단위는 너비를 의미하며, 이미지 너비를 픽셀로 나타냅니다.

위 예시에서 브라우저는 기기의 화면 크기와 픽셀 밀도를 고려하여 사용 가능한 이미지 중 가장 적합한 이미지를 선택합니다. 예를 들어, 화면의 너비가 480픽셀인 경우 tooo1-small.jpg를, 화면의 너비가 720픽셀인 경우 tooo1-medium.jpg를 선택할 수 있습니다.

srcset 속성을 사용하면 다양한 환경에서 이미지를 최적화하고, 사용자에게 더 나은 사용자 경험을 제공할 수 있습니다. 그러나 메모리 등 환경이 여의치 않으면 낮은 해상도의 이미지가 선택되어 화면에 나타날 수 있습니다. srcset은 어느정도 해결해주긴 하지만 완벽하게 지원하지는 않습니다. 해상도별로 다른 사진을 주게되면 기대와 다른 사진을 사용자에게 제공할 수도 있어요. 그래서 동일한 이미지를 크기만 다르게 사용하는 것이 예외 케이스를 막아 최대한 동일한 사용자 경험을 제공할 수 있다고 생각합니다.

picture 태그

<picture> 태그는 웹 페이지에서 다양한 조건에 따라 이미지 소스를 선택하고 사용할 수 있도록 도와주는 HTML5의 요소입니다. <picture> 태그는 여러 <source> 태그를 포함하며, 이를 통해 미디어 쿼리와 함께 다양한 이미지 소스를 제공할 수 있습니다. 브라우저는 <source> 태그들 중 조건에 맞는 이미지를 선택하여 로드하게 됩니다.

<picture> 태그와 srcset 속성을 함께 사용하면 더욱 정교한 이미지 선택이 가능합니다. 이를 통해 브라우저는 뷰포트 크기와 기기의 픽셀 밀도에 따라 적절한 이미지를 선택할 수 있습니다.

예를 들어 다음과 같이 <picture> 태그와 srcset 속성을 사용하여 뷰포트 크기에 따라 다른 이미지를 제공할 수 있습니다.

<picture>
  <source media="(min-width: 1280px)" srcset="tooo1-large.jpg">
  <source media="(min-width: 720px)" srcset="tooo1-medium.jpg">
  <img src="tooo1-small.jpg" alt="퉁이리가 짱이다">
</picture>

위 예시에서는 뷰포트의 너비가 1280 픽셀 이상인 경우 tooo1-large.jpg 이미지를 사용하고, 720 픽셀 이상인 경우 tooo1-medium.jpg 이미지를 사용합니다. 그 외의 경우에는 기본 이미지인 tooo1-small.jpg를 사용합니다.

https://caniuse.com/?search=picture

<picture> 태그와 srcset 속성을 함께 사용하면, 화면 크기, 픽셀 밀도, 이미지 형식 등 다양한 조건에 따라 최적화된 이미지를 제공할 수 있으며, 이를 통해 사용자에게 더 나은 사용자 경험을 제공할 수 있습니다. 그러나 모든 브라우저가 지원하고 있지 않아요. 하지만 최신 버전들의 브라우저들은 대부분 picture 태그를 지원하니 안심하고 사용하셔도 될 것 같습니다.

만약 지원하지 않는 브라우저에서도 picture 태그를 사용하고 싶으시면 polyfill를 활용해요!

실제 활용 사례

실제 활용 사례를 찾기 위해 많은 사이트를 프로파일링하였고 예시에 적합한 사이트를 찾았어요!

https://about.daangn.com/

당근마켓 소개페이지를 예시로 들어보겠습니다.

이미지 로딩이 완료된 상황입니다. 이제 화면 사이즈를 바꿔볼까요?

화면 크기가 바뀔 때마다 새로운 사진을 받아오고 있습니다. 코드를 살펴볼게요.

<picture
  ><source
    type="image/avif"
    sizes="100vw"
    srcset="
      /static/e196734140dc4952ed1c2ab9e1ce0b12/98582/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).avif  576w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/92ec5/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).avif  768w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/f851b/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).avif  992w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/13c44/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).avif 1080w
    " />
  <source
    type="image/webp"
    sizes="100vw"
    srcset="
      /static/e196734140dc4952ed1c2ab9e1ce0b12/540d8/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).webp  576w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/3f179/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).webp  768w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/89940/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).webp  992w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/91c76/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).webp 1080w
    " />
  <img
    data-main-image=""
    style="opacity: 1"
    sizes="100vw"
    decoding="async"
    loading="lazy"
    alt="당근마켓 사무실 전경, 넓은 라운지에서 당근이가 손을 흔들고 있어요."
    src="/static/e196734140dc4952ed1c2ab9e1ce0b12/5129e/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).jpg"
    srcset="
      /static/e196734140dc4952ed1c2ab9e1ce0b12/24fdc/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).jpg  576w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/7511c/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).jpg  768w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/d8184/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).jpg  992w,
      /static/e196734140dc4952ed1c2ab9e1ce0b12/5129e/2107eb7a-c125-4118-b1a8-7fafb49c8509_home_key_mobile(3x4).jpg 1080w
    "
/></picture>

제가 설명드렸던 것과 동일하게 화면 크기 및 해상도에 따라 서로 다른 이미지 파일을 제공하고 있으며, 또한 이미지 형식도 다양하게 제공하고 있습니다. 두 개의 <source> 태그 중 첫 번째는 AVIF 이미지 형식을, 두 번째는 WebP 이미지 형식을 사용합니다.

네트워크 탭을 살펴보면 브라우저에서 어떤 이미지를 지원하는지도 알 수 있습니다. 기본적으로 Accept 헤더에 표시되고 있고 또한 User-Agent Client Hints를 통해 다양한 정보 힌트를 담을 수 있습니다. 저같은 경우에는 다음과 같네요!

Sec-Ch-Ua: Google Chrome 113, Chromium 113, 그리고 Not-A.Brand 24가 포함되어 있고 저는 힌트를 토대로 크롬을 이용하고 있습니다.

Sec-Ch-Ua-Mobile: 클라이언트가 모바일 기기인지 여부를 나타냅니다. 이 경우에는 ?0으로 표시되어, 모바일 기기가 아님을 나타냅니다. 노트북으로 들어왔어요!
Sec-Ch-Ua-Platform: 클라이언트의 운영 체제를 나타냅니다. 저는 Windows입니다.
Sec-Fetch-Dest: 요청 목적을 나타냅니다. 이 경우에는 이미지를 가져오는 것이 목적입니다. 우리는 image를 공부하고 있죠!
Sec-Fetch-Mode: 요청 모드를 나타냅니다. 이 경우에는 no-cors입니다.
Sec-Fetch-Site: 요청이 어떤 출처에서 이루어졌는지를 나타냅니다. 이 경우에는 same-origin입니다.
User-Agent: 클라이언트의 브라우저 및 운영 체제에 대한 정보를 나타내는 문자열입니다.

https://developer.chrome.com/ko/articles/user-agent-client-hints/

자세한 예시를 통해 학습을 한 후 실제 활용 사례를 보니 더욱 이해가 되네요.

웹 페이지의 이미지 최적화를 위한 다양한 방법과 기술을 살펴보았습니다. 먼저, 여러 이미지 종류와 그 특징들을 알아보았고 이미지 변환 기법 중 무손실 압축과 손실 압축에 대해서도 알아봤습니다. 이어서, 이미지를 더 효율적으로 관리하기 위해 사용하는 srcset 속성과 picture 태그에 대해, 마지막으로, 실제 활용 사례를 통해 이미지 최적화 기법들이 어떻게 적용되는지를 확인하였습니다.

이미지 최적화는 사용자 경험과 웹 페이지의 로딩 속도에 큰 영향을 미치기 때문에 프론트엔드 개발자들이 주목해야 할 중요한 주제입니다. 이 글을 통해 소개된 이미지 최적화 기법들을 적용하여 웹 페이지의 이미지 관리를 개선하고, 사용자들에게 더 나은 웹 환경을 제공할 수 있기를 바랍니다.

좋아요는 로그인하지 않아도 누를 수 있습니다!

캐시 이해와 프론트엔드 개발자를 위한 최적의 캐시 활용 전략 및 주의사항

퉁이리 — Mon, 1 May 2023 15:52:11 +0900

캐시는 프로세서와 메모리 사이의 속도 차이를 해결하기 위해 사용되는 작고 빠른 메모리입니다. 주로 프로세서가 빠른 반응 속도를 위해 자주 사용하는 데이터를 캐시에 저장하여 전체 시스템 속도를 높입니다. 캐시는 지역성 원리(Principle of Locality)를 따르며, 시간 지역성(Temporal locality)과 공간 지역성(Spatial locality)으로 구분됩니다.

지역성 원리를 이해하기 위해 구체적인 예시를 들어볼게요!

예를 들어, 컴퓨터에서 어떤 프로그램을 실행한다고 가정해 봅시다. 이 프로그램은 배열(Array)에 저장된 데이터를 반복적으로 읽고 쓰는 작업을 수행합니다. 배열의 크기는 1,000,000이고, 프로그램은 다음과 같은 순서로 데이터에 접근합니다.

1. 0번 인덱스부터 999,999번 인덱스까지 순차적으로 접근합니다.
2. 999,999번 인덱스부터 0번 인덱스까지 역순으로 접근합니다.
3. 0번 인덱스부터 999,999번 인덱스까지 순차적으로 접근합니다.

C++코드와 JavaScript 코드로 예시를 구현해볼게요.

C++

#include <iostream>

int main() {
    const int SIZE = 1000000;
    int* array = new int[SIZE];

    // 0번 인덱스부터 999,999번 인덱스까지 순차적으로 접근
    for (int i = 0; i < SIZE; ++i) {
        array[i] = i;
    }

    // 999,999번 인덱스부터 0번 인덱스까지 역순으로 접근
    for (int i = SIZE - 1; i >= 0; --i) {
        array[i] = i;
    }

    // 0번 인덱스부터 999,999번 인덱스까지 순차적으로 접근
    for (int i = 0; i < SIZE; ++i) {
        array[i] = i;
    }

    delete[] array;
    return 0;
}

JavaScript

const SIZE = 1000000;
let array = new Array(SIZE);

// 0번 인덱스부터 999,999번 인덱스까지 순차적으로 접근
for (let i = 0; i < SIZE; i++) {
  array[i] = i;
}

// 999,999번 인덱스부터 0번 인덱스까지 역순으로 접근
for (let i = SIZE - 1; i >= 0; i--) {
  array[i] = i;
}

// 0번 인덱스부터 999,999번 인덱스까지 순차적으로 접근
for (let i = 0; i < SIZE; i++) {
  array[i] = i;
}

C++ 코드를 사용하는 이유는 캐시와 메모리 관리에 대한 이해를 돕기 위해서입니다. C++은 메모리를 직접 관리할 수 있는 대표적인 언어로, 메모리 할당 및 해제에 대한 예제를 쉽게 작성할 수 있습니다. 또한, C++의 컴파일러 최적화를 통해 메모리 접근 및 캐시 동작에 대한 예측이 더 정확해집니다.

반면 JavaScript는 메모리 관리를 직접 제어할 수 없는 언어입니다. 이는 자바스크립트의 가비지 컬렉션(Garbage Collection) 메커니즘이 메모리를 자동으로 관리하기 때문입니다. 이로 인해 캐시와 메모리 관리에 대한 예제를 작성할 때, C++ 보다 JavaScript가 상대적으로 제한적일 수 있습니다.

하지만, 위에서 제시한 JavaScript 예제도 시간 지역성과 공간 지역성에 대한 이해를 돕는데 충분하다고 생각했고 프론트엔드 개발자를 위한 포스팅이라 C++, JavaScript 둘 다 준비해 봤습니다.

위 프로그램의 경우, 배열의 크기가 1,000,000인 정수 배열을 생성하고, 순차적 접근과 역순 접근을 반복하여 데이터에 접근합니다. 이 예시에서 시간 지역성과 공간 지역성 원리가 적용됩니다.

시간 지역성(Temporal Locality)의 경우, 각 인덱스에 저장된 데이터는 한 번 접근하면 가까운 미래에 다시 접근되기 때문에 캐시에 저장되어 있으면 접근 시간이 단축됩니다. 따라서, 최근에 참조된 데이터가 캐시에 저장되어 있으면 이 프로그램의 성능이 향상됩니다.

공간 지역성(Spatial Locality)은 인접한 메모리 위치에 저장된 데이터가 함께 사용될 가능성이 높다는 원리입니다. 이 예시에서는 배열의 데이터가 순차적으로 접근되므로 인접한 메모리 위치에 있는 데이터를 미리 캐시에 저장해 두어 접근 시간을 줄일 수 있습니다. 이를 통해 프로그램의 성능이 향상됩니다.

캐시 알고리즘

여러 가지 캐시 알고리즘이 있어요. 이번 포스팅에서는 간단하게 소개하고 넘어가려고 합니다.

최근 최소 사용(LRU, Least Recently Used): 이 알고리즘은 최근에 사용하지 않은 데이터를 캐시에서 교체하는 방식으로 작동합니다. 시간 지역성을 고려하여 구현되며, 최근에 사용한 데이터가 곧 다시 사용될 가능성이 높다는 점을 활용합니다.

최적(OPT, Optimal): 이 알고리즘은 미래에 가장 오랫동안 사용되지 않을 데이터를 캐시에서 교체하는 방식으로 작동합니다. 이 알고리즘은 이론적으로 최적의 캐시 효율을 제공하지만, 실제 구현에서 미래의 메모리 참조를 미리 알기 어렵기 때문에 실용적이지 않습니다.

응용 프로그램 특정(Application-Specific): 캐시 교체 정책이 애플리케이션의 특성에 따라 결정됩니다. 이 알고리즘은 공간 지역성 원리를 활용하며, 애플리케이션에서 인접한 메모리 위치에 대한 접근이 높은 경우 효과적입니다.

적응형(Adaptive): 적응형 캐시 알고리즘은 시간 지역성과 공간 지역성의 패턴을 동적으로 학습하고 적용하여 캐시 성능을 최적화합니다. 이 알고리즘은 프로그램의 실행 동안 메모리 접근 패턴을 모니터링하고, 해당 패턴에 기반하여 캐시 정책을 조정합니다.

지금까지 기본적으로 캐시를 이해하기 위해 지역성 원리(Principle of Locality)를 구체적인 예시를 통해 알아보았고 캐시 알고리즘도 맛보기로 보았습니다. 이제 캐시에는 어떠한 유형들이 있는지 알아보려고 합니다.

다양한 캐시 유형

L1 캐시 (Level 1 Cache): 프로세서와 가장 가까운 캐시로, 속도를 위해 Instruction Cache와 Data Cache로 나뉜다.
L2 캐시 (Level 2 Cache): 용량이 큰 캐시로, 프로세서와 더 멀리 떨어져 있다.
L3 캐시 (Level 3 Cache): 멀티 코어 시스템에서 여러 코어가 공유하는 캐시로, L2 캐시보다 더 크다.
하드웨어 캐시 (Hardware Cache): 하드웨어 구성 요소에 의해 관리되는 캐시로, CPU와 GPU에 사용된다.
브라우저 캐시 (Browser Cache): 웹 브라우저에서 사용되는 캐시로, 웹 페이지의 요소를 저장하여 빠르게 불러온다.
분산 캐시 (Distributed Cache): 여러 시스템 간에 데이터를 저장하고 공유하기 위해 사용되는 캐시이다.
콘텐츠 전송 네트워크 (CDN) 캐시: CDN에서 사용되는 캐시로, 사용자에게 가까운 서버에서 웹 콘텐츠를 전송한다.
메모리 캐시 (Memory Cache): RAM에 저장되는 캐시로, 데이터베이스 조회 결과 등을 저장한다.
트랜잭션 캐시 (Transactional Cache): 데이터베이스 트랜잭션을 처리하는 동안 일시적으로 데이터를 저장하는 캐시이다.
서비스 워커 캐시 (Service Worker Cache): 웹 애플리케이션에서 오프라인 기능을 지원하기 위해 사용되는 캐시이다.

Cache를 $로도 표현하기도 해요. 캐시(Cache)의 발음이 현금을 뜻하는 'Cash’와 같기 때문이에요.

프론트엔드 개발자가 주로 사용하는 캐시 유형

프론트엔드 개발자가 주로 사용하는 캐시 유형은 다음과 같아요.

브라우저 캐시
콘텐츠 전송 네트워크 (CDN) 캐시
메모리 캐시
서비스 워커 캐시

브라우저 캐시

브라우저 캐시는 웹 페이지의 요소를 저장하여 빠르게 불러옵니다. 예를 들어, 웹 페이지에 사용되는 이미지를 브라우저 캐시에 저장해 두면, 다음 방문 시 이미지를 더 빠르게 불러올 수 있습니다.

<!-- HTML 코드 예시 -->
<meta http-equiv="Cache-Control" content="max-age=86400" />

콘텐츠 전송 네트워크 (CDN) 캐시

CDN 캐시는 사용자에게 가까운 서버에서 웹 콘텐츠를 전송합니다. 이를 통해 웹 페이지의 로딩 시간을 줄일 수 있습니다.

메모리 캐시

메모리 캐시는 RAM에 저장되며, 데이터베이스 조회 결과 등을 저장한다. 이를 통해 데이터베이스에 빈번한 요청을 줄이고 애플리케이션의 성능을 향상시킬 수 있습니다.

// JavaScript 코드 예시
const cache = new Map();

function getData(key) {
  if (cache.has(key)) {
    return cache.get(key);
  }

  const data = fetchDataFromDatabase(key);
  cache.set(key, data);
  return data;
}

서비스 워커 캐시

서비스 워커 캐시는 웹 애플리케이션에서 오프라인 기능을 지원하기 위해 사용됩니다. 이를 통해 네트워크 연결이 끊겼을 때에도 애플리케이션을 계속 사용할 수 있습니다.

프론트엔드에서 캐시를 잘 활용하기 위한 전략

지금부터는 작성자가 학습하고 느낀 부분을 서술할 예정입니다. 따라서 지극히 주관적이며 사실과 다른 부분이 있을 수 있습니다. 틀린 부분이 있다면 댓글을 통해 알려주시면 감사하겠습니다.

크게 4가지로 생각해 봤습니다.

캐시 유효 기간을 설정하자

캐시의 유효 기간을 적절하게 설정하여, 캐시 된 데이터가 오래된 경우 새로운 데이터로 갱신되도록 합니다. 이를 통해 최신 정보를 유지하면서 성능 향상을 도모할 수 있다고 생각합니다.

불필요한 캐시를 회피하자

동적 데이터나 자주 변경되는 데이터는 캐시 하지 않는 것이 좋습니다. 이를 통해 항상 최신 정보를 보장하고 캐시 공간을 효율적으로 사용할 수 있습니다.

캐시 우선순위를 결정하자

데이터의 중요도와 사용 빈도에 따라 캐시 우선 순위를 결정합니다. 이를 통해 중요한 데이터를 빠르게 불러올 수 있도록 합니다.

-> 더 나아가 우선 순위를 결정할 때 빈도에만 따라서해도 될까라는 고찰

캐시 성능도 고려하면 좋겠다고 생각했습니다. 캐시 성능을 측정하는 데 사용되는 주요 메트릭들은 다음과 같았어요.

캐시 히트율(Cache Hit Rate): 캐시 히트율은 캐시에서 원하는 데이터를 찾았을 때의 비율을 나타냅니다. 캐시 히트율이 높을수록 성능이 좋다고 판단할 수 있습니다. 캐시 히트율은 다음과 같이 계산할 수 있습니다.

캐시 히트율 = (캐시 히트 수 / (캐시 히트 수 + 캐시 미스 수)) * 100

캐시 미스율(Cache Miss Rate): 캐시 미스율은 캐시에서 원하는 데이터를 찾지 못했을 때의 비율을 나타냅니다. 캐시 미스율이 낮을수록 성능이 좋다고 판단할 수 있습니다. 캐시 미스율은 다음과 같이 계산할 수 있습니다.

캐시 미스율 = (캐시 미스 수 / (캐시 히트 수 + 캐시 미스 수)) * 100

평균 메모리 액세스 시간(Average Memory Access Time, AMAT): 평균 메모리 액세스 시간은 캐시와 메인 메모리의 액세스 시간을 고려하여 계산합니다. 캐시 히트 시간과 캐시 미스 패널티를 사용하여 AMAT를 계산할 수 있습니다.

평균 메모리 액세스 시간 = 캐시 히트 시간 + (캐시 미스율 * 캐시 미스 패널티)

캐시 파티셔닝 :: 캐시를 개인화하자

사용자별로 다른 캐시를 구성하여 개인화된 사용자 경험을 제공합니다. 이를 통해 각 사용자에게 최적화된 콘텐츠를 제공할 수 있습니다.

캐시를 이용하면 무조건 좋나요????? 그렇다고 캐시를 무분별하게 사용해서는 안 됩니다. 캐시 활용 시 주의하면서 사용해야 해요!!

캐시 활용 시 주의사항

데이터 일관성 유지:

캐시 된 데이터와 원본 데이터 간의 일관성을 유지해야 합니다. 데이터 변경 시 캐시도 함께 갱신되도록 주의합니다.

보안 고려:

캐시된 데이터는 보안상의 이유로 다른 사용자에게 노출되지 않아야 합니다. 암호화 및 인증 기능을 사용하여 캐시 데이터의 보안을 강화합니다.

캐시 용량 관리:

캐시 용량이 고갈되지 않도록 주기적으로 캐시를 정리하고 관리합니다. 이를 통해 캐시의 효율성을 유지할 수 있습니다.

글 마무리를 하자면 캐시는 컴퓨터 시스템의 성능을 향상시키는 중요한 기술입니다. 우리가 사용하는 거의 모든 것에는 캐시가 있죠!! 프론트엔드 개발에서도 다양한 캐시 유형과 전략을 활용하여 애플리케이션의 로딩 속도를 높이고 사용자 경험을 향상시킬 수 있습니다. 캐시 활용 시 주의사항을 지켜 데이터의 일관성과 보안을 유지하면서 캐시의 장점을 최대한 활용하도록 노력해야 한다고 생각합니다.

좋아요는 로그인하지 않아도 누를 수 있습니다!

참고

https://computationstructures.org/lectures/caches/caches.html

https://stackoverflow.com/questions/7638932/what-is-locality-of-reference

FOUC와 FOUT 현상 극복하기: 브라우저 렌더링 원리와 최적화 전략

퉁이리 — Sat, 29 Apr 2023 15:01:07 +0900

이 글에서는 웹 페이지 로딩 과정에서 발생하는 FOUC(Flash of Unstyled Content)와 FOUT(Flash of Unstyled Text) 현상에 대해 알아보고, 브라우저 렌더링 원리를 이해하고 이를 극복하는 최적화 전략을 소개합니다.

FOUC(Flash of Unstyled Content)와 FOUT(Flash of Unstyled Text)

FOUC와 FOUT은 웹 페이지 로딩 과정에서 일시적으로 스타일이 적용되지 않은 콘텐츠와 텍스트를 사용자에게 보여주는 현상입니다. 두 현상 모두 스타일 로드 및 적용 시점과 브라우저 렌더링 시점 간의 차이 때문에 발생합니다. FOUC는 일반적인 콘텐츠에, FOUT은 웹 폰트에 대한 스타일 적용 지연 때문에 발생합니다.

FOUC - 일반적인 콘텐츠

FOUC

브라우저가 HTML 문서를 파싱하고 DOM 트리를 구성하는 동안, 외부 CSS 파일이 아직 로드되지 않았을 때 발생합니다. 이로 인해 브라우저는 초기에 스타일이 적용되지 않은 콘텐츠를 화면에 표시하게 됩니다. 외부 CSS 파일이 로드되고 파싱되어 CSSOM 트리가 만들어지면, 렌더 트리가 업데이트되고 스타일이 적용된 콘텐츠가 표시됩니다. 이 과정에서 사용자는 잠시 스타일이 적용되지 않은 콘텐츠를 볼 수 있게 됩니다.

11초 짤예시 (FOUC)

FOUT - 웹 폰트에 대한 스타일 적용 지연

FOUT

웹 폰트를 사용하는 경우, 브라우저가 웹 폰트 파일을 다운로드하고 파싱하는데 시간이 걸릴 수 있습니다. 웹 폰트가 아직 로드되지 않았을 때, 브라우저는 시스템 기본 폰트를 사용하여 텍스트를 먼저 렌더링합니다. 웹 폰트가 로드되면, 브라우저는 렌더 트리를 업데이트하여 웹 폰트를 적용한 텍스트를 표시하게 됩니다. 이 과정에서 사용자는 잠시 웹 폰트가 적용되지 않은 텍스트를 볼 수 있게 됩니다.

FOUC, FOUT 발생 단계 (브라우저 렌더링 원리를 곁들인)

브라우저는 HTML, CSS, JavaScript 파일을 로드하여 웹 페이지를 렌더링합니다. HTML은 페이지의 구조를 정의하고, CSS는 스타일을 적용하며, JavaScript는 동작을 추가합니다. 이 과정에서 브라우저는 다음 단계를 거칩니다.

HTML 파싱: 브라우저는 HTML 파일을 파싱하여 DOM(Document Object Model) 트리를 생성합니다.
CSS 파싱: 브라우저는 CSS 파일을 파싱하여 CSSOM(CSS Object Model) 트리를 생성합니다.
렌더 트리 생성: DOM 트리와 CSSOM 트리를 합쳐서 렌더 트리를 생성합니다. 이 트리는 페이지의 시각적 요소를 나타냅니다.
레이아웃: 렌더 트리의 요소들에 대한 위치와 크기를 계산합니다.
페인팅: 최종적으로 스타일과 레이아웃 정보를 바탕으로 화면에 요소를 그립니다.

FOUC와 FOUT 현상은 주로 렌더 트리 생성 및 레이아웃 단계에서 발생합니다. 스타일 정보가 늦게 도착하거나, 웹 폰트가 로드되는 동안 브라우저가 기본 폰트로 렌더링하기 때문입니다.

브라우저 동작원리에 대해 더 자세히 궁금하다면 https://d2.naver.com/helloworld/59361
원문은 https://web.dev/howbrowserswork/

FOUC와 FOUT 현상을 극복하기 위한 최적화 전략

FOUC와 FOUT 현상을 극복하기 위한 여러 전략들이 있습니다. 이 전략들은 브라우저 렌더링 원리를 이해를 기반으로 하고 스타일 로드와 적용 과정을 최적화하는 데 초점을 맞춥니다.

CSS를 HTML 문서의 <head> 태그에 배치:

브라우저는 HTML 문서를 순차적으로 해석하므로, 스타일을 가능한 한 빨리 로드하려면 <head> 태그 내에 <link> 태그를 사용하여 CSS 파일을 연결하는 것이 좋습니다. 이렇게 하면 브라우저가 렌더링을 시작하기 전에 스타일을 먼저 로드하고 적용할 수 있습니다.

<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>퉁이리</title>
    <link rel="stylesheet" href="styles.css"> <!-- 여기 -->
</head>
<body>
    <!-- Your content here -->
</body>
</html>

인라인 CSS 사용:

인라인 스타일은 별도의 HTTP 요청 없이 페이지와 함께 로드되기 때문에 렌더링 속도가 빨라질 수 있습니다. 하지만 이 방법은 파일 크기가 커질 수 있으므로, 필수적인 스타일 정보만 인라인으로 삽입하는 것이 좋습니다. 이를 부분적으로 적용하기 위해 크리티컬 CSS라는 기법을 사용할 수 있습니다.

크리티컬 CSS란 웹 페이지의 초기 렌더링에 영향을 미치는 중요한 스타일을 인라인으로 삽입하는 방법입니다.

<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>퉁이리</title>
    <style>
        /* Critical CSS: 페이지 초기 렌더링에 필요한 중요한 스타일 */
        body {
            font-family: Arial, sans-serif;
            background-color: white;
            margin: 0;
            padding: 0;
        }
        header {
            background-color: #333;
            color: white;
            padding: 1rem;
        }
    </style>
    <link rel="stylesheet" href="styles.css"> <!-- 나머지 스타일은 여기서 로드 -->
</head>
<body>
    <header>
        <h1>퉁이리</h1>
    </header>
    <!-- Your content here -->
</body>
</html>

CSS 파일 크기 줄이기:

CSS 파일의 크기를 최소화하면 로드 시간이 단축되어 FOUC와 FOUT 현상을 줄일 수 있습니다. 이를 위해 불필요한 코드를 제거하거나 CSS 파일을 압축하는 방법을 사용할 수 있습니다.

수동으로 할 수도 있지만, CSS 압축 도구를 사용하면 더 효율적입니다. 자동화를 이용해요!

웹 폰트 로드 최적화:

웹 폰트를 불러오는 방식을 최적화하면 FOUT 현상을 줄일 수 있습니다. 예를 들어, <link> 태그의 preload 속성을 사용하여 웹 폰트를 미리 로드할 수 있습니다. 또는 CSS font-display 속성을 사용하여 웹 폰트의 로드 및 렌더링 동작을 조절할 수 있습니다.

JavaScript 로드 순서 조절:

JavaScript가 페이지의 스타일 적용을 차단하거나 렌더링을 지연시키는 경우, FOUC와 FOUT 현상이 발생할 수 있습니다. 따라서 JavaScript 로드 순서를 조절하여 문제를 해결할 수 있습니다. 스크립트를 HTML 문서의 <body> 태그 끝 부분에 배치하거나 async 또는 defer 속성을 사용하여 스크립트 로드 순서를 변경할 수 있습니다. 이렇게 하면 브라우저가 스크립트 로드를 지연시키고 스타일이 완전히 로드되고 적용된 후에 스크립트를 실행할 수 있습니다.

<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>퉁이리</title>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <!-- Your content here -->

    <!-- JavaScript를 문서 끝부분에 위치시키기 -->
    <script src="your-script.js"></script>
    <!-- 또는 `async` 또는 `defer` 속성 사용 -->
    <script async src="your-script.js"></script>
    <script defer src="your-script.js"></script>
</body>
</html>

콘텐츠를 숨겨놓고 로드가 완료된 후에 표시하기:

이 방법은 초기 로딩 시 콘텐츠를 숨기고, 페이지의 스타일과 스크립트가 완전히 로드된 후에 콘텐츠를 표시하는 것입니다. 예를 들어, 페이지의 최상위 요소에 opacity: 0 또는 display: none 같은 스타일을 적용하여 콘텐츠를 숨길 수 있습니다. 그런 다음 JavaScript를 사용하여 페이지 로드가 완료되면 해당 스타일을 제거하여 콘텐츠를 표시할 수 있습니다. 이 방법은 FOUC 현상을 완전히 제거할 수 있지만, 사용자가 빈 화면을 잠시 볼 수 있으므로 적절한 *로딩 인디케이터를 제공하는 것이 좋습니다.

로딩 인디케이터는 사용자에게 웹 페이지나 애플리케이션의 컨텐츠가 로드 중임을 알려주는 시각적 요소입니다. 로딩 인디케이터는 사용자 경험(UX)의 중요한 부분으로, 사용자가 데이터가 로드되고 있음을 인지하게 해서 기다리는 동안의 불편함을 줄이는 역할을 합니다.

로딩 인디케이터는 일반적으로 다음과 같은 형태로 나타내요.

스피너(Spinner): 원형 아이콘으로 회전하면서 로드 중임을 나타내는 가장 일반적인 로딩 인디케이터입니다. 스피너는 크기와 색상을 변경할 수 있으며, 웹 페이지나 애플리케이션의 스타일에 맞게 커스터마이징할 수 있습니다.

진행바(Progress bar): 로딩이 진행되는 과정을 가로 또는 세로 형태의 바로 표시하는 인디케이터입니다. 진행바는 데이터 로드가 완료될 때까지 점진적으로 채워지며, 사용자에게 로딩 과정의 상태를 더 구체적으로 표시해줍니다.

스켈레톤 로딩(Skeleton loading): 콘텐츠의 형태와 크기를 대략적으로 표시하는 뼈대를 사용하여 로딩 중임을 나타내는 인디케이터입니다. 스켈레톤 로딩은 실제 콘텐츠가 로드될 때까지 사용자에게 대략적인 레이아웃을 보여주어, 페이지가 로드되는 동안 사용자의 인내심을 높이는 데 도움이 됩니다.

서버 사이드 렌더링 (SSR) 사용하기:

SSR은 클라이언트 사이드에서 렌더링하기 전에 서버에서 HTML을 렌더링하는 기술입니다. 이를 통해 브라우저가 이미 스타일이 적용된 HTML 문서를 받게 되어 FOUC 현상을 피할 수 있습니다. Next.js 등의 프레임워크에서는 SSR을 지원하며, 이를 사용하여 FOUC 현상을 방지할 수 있습니다.

FOUC와 FOUT 현상은 웹 페이지의 사용자 경험에 부정적인 영향을 미칠 수 있습니다. 따라서 위에서 제시한 방법 중 하나 이상을 사용하여 FOUC와 FOUT 현상을 최소화하거나 완전히 제거할 수 있도록 노력해야 합니다. 이렇게 함으로써 사용자가 웹 페이지를 더 빠르게 로드하고 스타일이 올바르게 적용된 콘텐츠를 볼 수 있게 되어 사용자 경험을 향상시킬 수 있습니다.

좋아요는 로그인하지 않아도 누를 수 있습니다!

참고

https://stackoverflow.com/questions/60841540/flash-of-unstyled-text-fout-on-reload-using-next-js-and-styled-components

https://dev.to/lyqht/what-the-fouc-is-happening-flash-of-unstyled-content-413j

https://en.wikipedia.org/wiki/Flash_of_unstyled_content#:~:text=A%20flash%20of%20unstyled%20content,before%20all%20information%20is%20retrieved.

https://d2.naver.com/helloworld/59361

Vercel, 그냥 사용하시나요? (feat. SaaS가 해결해주는 문제)

퉁이리 — Wed, 12 Apr 2023 21:19:35 +0900

서론

현대 웹 애플리케이션 개발은 복잡한 과정으로, 개발자들은 다양한 문제들을 해결하며 프로젝트를 진행해야 합니다. 이러한 문제들을 해결해 주는 SaaS(Software as a Service) 툴들은 개발자들에게 효율적인 개발 환경을 제공합니다. 이 글에서는 Vercel이라는 SaaS 툴이 웹 애플리케이션 개발에서 어떤 이점을 제공하며, SaaS 없이(without vercel) 웹 애플리케이션을 배포하고 관리하려면 어떻게 해야 했는지에 대해 서술해보려합니다.

SaaS

SaaS는 "Software as a Service"의 약자로, 소프트웨어를 서비스 형태로 제공하는 것을 의미합니다. SaaS는 클라우드 컴퓨팅의 한 형태로, 사용자가 웹 브라우저를 통해 인터넷에 접속하여 소프트웨어를 사용할 수 있게 합니다. 이를 통해 사용자는 서비스의 유지 관리 방식이나 인프라를 생각할 필요 없이 소프트웨어를 어떻게 사용할지만 생각하면 됩니다.

SaaS 제공자는 소프트웨어를 호스팅 하고 유지 관리를 담당하며, 사용자는 서비스에 대한 구독료를 지불하여 사용할 수 있습니다. SaaS는 비용 효율적이고 편리한 방식으로 소프트웨어를 사용할 수 있는 방법으로 인기를 얻고 있으며, 고객 관계 관리(CRM), 전사적 자원 관리(ERP), 메일 시스템 등 다양한 분야에서 활용되고 있습니다.

예) Google Workspace, Salesforce, Slack, Microsoft Office 365 등

본론 1 - SaaS 툴이 해결해 주는 문제들

1. 지속적인 통합 및 배포(CI/CD)

지속적인 통합 및 배포(CI/CD)를 쉽게 구현할 수 있게 돕습니다. 코드 변경이 발생할 때마다 자동으로 빌드하고 테스트를 진행한 후, 성공적인 테스트 결과를 바탕으로 배포하는 프로세스를 자동화해 주어 개발 효율성을 높입니다.

2. 성능 최적화

웹 애플리케이션의 성능을 향상시키는 다양한 기능을 제공합니다. 예를 들어, 이미지 및 동영상 최적화, 코드 압축 및 최소화, 캐싱 전략 등을 적용하여 웹 애플리케이션의 로딩 속도를 높이고 사용자 경험을 개선할 수 있습니다.

3. 협업

원격으로 작업하는 팀원들 사이의 협업을 용이하게 합니다. 클라우드 기반의 서비스로, 동시에 작업하고 변경 사항을 공유할 수 있어 개발 프로세스가 더욱 원활하게 진행됩니다. 이를 통해 팀원들 간의 소통이 개선되고 프로젝트의 진행 상황을 실시간으로 파악할 수 있습니다.

4. 확장성

웹 애플리케이션의 사용자 수가 증가하거나 트래픽이 늘어나면, 인프라를 쉽게 확장할 수 있어야 합니다. SaaS 툴들은 이러한 확장성 문제를 해결해 주며, 자동으로 리소스를 조절하여 애플리케이션의 성능을 유지할 수 있게 돕습니다.

본론 2 - Vercel이 해결해 주는 문제들

Vercel은 SaaS 툴 중 웹 애플리케이션 및 정적 사이트를 배포, 호스팅 하고 최적화하는 데 주력하는 플랫폼입니다. Vercel은 근본적으로 다음과 같은 문제들을 해결해 줍니다.

1. 복잡한 인프라 관리

Vercel은 사용자가 인프라에 대한 걱정 없이 개발에 집중할 수 있게 해 줍니다. 전통적인 호스팅 서비스와 달리, Vercel은 서버 관리, 확장성 및 성능 최적화와 관련된 복잡한 작업을 자동화하고 추상화합니다.

2. 배포 및 지속적인 통합

Vercel은 소스 코드 저장소와 통합되어, 코드 변경이 발생할 때마다 자동으로 빌드하고 배포하는 기능을 제공합니다. 이를 통해 지속적인 통합 및 지속적인 배포(CI/CD)를 손쉽게 구현할 수 있습니다.

3. 글로벌 CDN 제공 및 캐싱 최적화

Vercel은 웹 애플리케이션의 정적 파일들을 전 세계적인 CDN(Content Delivery Network)에 배포하여 사용자들이 빠른 로딩 속도로 웹 애플리케이션을 이용할 수 있게 해줍니다. 또한, Vercel은 캐싱 전략을 적용하여 변경되지 않은 파일들을 캐시 하여 성능을 더욱 향상시킵니다.

4. 개발자 경험 개선

Vercel은 개발자 경험에 큰 가치를 두고 있습니다. 프로젝트를 시작할 때 사용자 친화적인 대시보드와 쉬운 설정을 제공하며, 로컬 개발 환경에서 실시간 미리보기 기능과 같은 도구를 제공하여 개발 및 디버깅을 용이하게 합니다.

본론 3 - Vercel 없이 배포 및 관리하려면??

다양한 빌드 및 배포 자동화 도구를 활용하여 웹 애플리케이션을 배포하고 관리해야 합니다. Jenkins, GitLab CI/CD, GitHub Actions 등의 도구를 사용하여 소스 코드 변경 사항이 발생할 때마다 자동으로 빌드하고 배포하는 프로세스를 구축하여야 합니다.

또한, 웹 애플리케이션의 성능을 최적화하기 위해 개발자는 다양한 테스트와 조정을 직접 수행해야 합니다. 개발자는 성능 테스트 도구 등을 사용하여 최적화가 필요한 부분을 찾아내고 개선해야 합니다.

그리고 Vercel이 제공하는 CDN과 캐싱 기능을 사용하지 않는 경우, 개발자는 직접 CDN 서비스를 설정하고 캐싱 전략을 관리해야 합니다. Cloudflare, Amazon CloudFront 등의 CDN 서비스를 사용하여 웹 애플리케이션의 정적 파일들을 전 세계적인 CDN에 배포하고, 캐싱 전략을 설정 등을 일일이 해야 합니다.

추가로 Vercel 없이 지속적인 통합(CI) 및 지속적인 배포(CD)를 구축하려면 개발자는 이러한 프로세스를 지원하는 도구를 선택하고 설정해야 합니다. 위에서 언급한 Jenkins, GitLab CI/CD, GitHub Actions 등의 도구를 사용하여 지속적인 통합 및 지속적인 배포 프로세스를 구축해야 합니다.

마지막으로, 모니터링 및 로깅, 백업 및 복구와 같은 중요한 기능들을 구축하고 관리해야 합니다. 오픈 소스 도구와 클라우드 스토리지 서비스를 활용하여 이러한 기능들을 직접 구축해야 합니다.

결론

독립적으로 웹 애플리케이션을 배포하고 관리하려면, 다양한 도구와 전략을 활용해야 합니다. 이러한 과정으로 진행하면 개발자가 프로젝트를 완벽하게 이해하고 통제할 수 있겠지만 상당히 복잡하고 시간 또한 많이 소요됩니다. Vercel과 같은 SaaS 툴은 이러한 문제를 해결해 줍니다. 웹 애플리케이션 개발에서 발생하는 다양한 문제들을 효과적으로 해결할 수 있습니다.

이 글을 통해 우리가 당연하게 여겨온 혜택들이 사실 그렇지 않았다는 사실과 프로젝트의 요구 사항과 예산, 그리고 개발 팀의 역량을 고려하여 SaaS를 사용할지, 아니면 독립적으로 웹 애플리케이션을 구축 및 관리할지 생각해 보시는 시간이 되셨으면 좋겠습니다.

참고

https://aws.amazon.com/ko/what-is/saas/

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-saas

https://vercel.com/docs

F - UNIV CAMP 2022 회고

퉁이리 — Tue, 20 Dec 2022 20:12:44 +0900

안녕하세요! 저는 컴퓨터sw 재학 중인 4학년 퉁이리입니다.
2022년 12월 18일에 F - UNIV CAMPERENCE 행사를 성공적으로 마무리하고 회고글을 작성해 보려고 합니다. 동아리, 프로젝트, 스터디, 강의 등 여러 프로그램을 진행한 경험은 있지만 컨퍼런스 관련 경험은 없었어요. 새로운 부분에 대해 도전하는 건 언제나 두렵지만 새롭고 재미있으면서 배울 부분이 많네요. 까먹기 전에 빨리 적어야겠어요!

https://www.f-univ.kr

사건의 발단

사실 컨퍼런스를 열 생각은 아니였어요.
스터디를 하려고 했습니다. 결과물은 컨퍼런스가 되었지만...

교내에서 Frontend 관련 스터디를 하고 싶었어요. 그리고 사람을 모집해봤지만 지원자를 한 명도 구할 수가 없었습니다. 제가 만든 교내 IT 동아리 인원만 해도 155명이 있었는데도 말이죠. 그래도 저는 여기서 포기할 수 없었어요. 함께 공부할 수 있는 스터디가 필요했거든요. 그리고 이번에는 대학생분들과 함께 하고 싶었어요. 교내에서는 구하지 못하여 다른 대학교에서 프론트엔드로 진로를 정하고 공부하신 분들에게 연락을 했습니다.

친구님이 다니시는 대학교에 FE 준비하시는 분 있나요?

지인분과 카톡

다른 대학교도 제가 다니는 대학교 상황과 별반 다르지 않았어요. 대학생분 중에서 FE 분야를 공부하는 분을 찾기가 너무 어려웠습니다. 그렇게 한분씩 수소문하여 컨택을 이어갔어요. 모으다 보니 대학교가 전부 달랐고 대부분 교내 동아리에 속해 계셨습니다. 그때 든 생각이 스터디가 아니라 각 동아리에 속해 있는 인원들에게 기술 공유로 해볼 수 있을 거 같다고 생각했어요.

교내 스터디 → FE 스터디 → 각 동아리 연합 기술 공유

여기까지 생각이 가니까 컨퍼런스가 생각이 났어요..... 최근에 2022 FECONF를 다녀왔었거든요... 대학생들만의 FECONF를 떠올리기까지는 시간문제였어요.. 왜 그랬을까요 ㅋㅋ.. 이때가 10월 22일이었어요.

생각이 들자마자 행동으로 옮겼습니다. 그렇게 일을 저지릅니다.

10월 22일

바로 사람들을 더 적극적으로 찾기 시작했어요. 위에 적은 것처럼 열심히 수소문해도 한두분밖에 구하지 못한 상황이었거든요.

기획

대학연합 컨퍼런스를 한다면 4학년인 저는 2022년인 올해에 하고 싶었어요. 그리고 적절한 일정을 찾아봤습니다. 12월 가장 마지막 주를 생각했는데 크리스마스이브와 크리스마스, 그리고 12월 31일이 반겨주고 있었어요. 이때 열면 발표자만 참석하겠구나 직감하고 17일이나 18일로 하기로 결정했습니다.

일정을 확정하고 나선 사람을 찾는데에 몰두했습니다. 이때 도움을 주신 분이 계셨어요. 우아한스터디에서 인연이 이어져 지금까지 연락을 하고 있는 개발자 장현석님의 도움을 많이 받았습니다. 현석님의 도움을 받아 2분의 섭외와 그리고 기존 인원의 지인 분 1명 섭외로 총 6명 구성을 이루는 데 성공했어요.

노션페이지

스피커 인원을 다 구한 이후에는 계획을 세웠습니다. 무엇이 필요한지, 무엇을 해야 하는지 등

진행을 하면서 가장 중요한 것들에 대해 우선순위를 세웠고 결정하지 못한 부분에 대해 결정하고 문제가 있는 것들은 해결해 나가며 진행했습니다. 짧은 시간에 모든 것을 해결하고 결과를 내야 하는 상황이라 타협은 필요했지만 방향성만큼은 최대한 올바르게 가려고 노력했어요. 그러기 위해서는 중간중간 경험이 있으신 분들의 피드백은 정말 큰 도움이 되었습니다.

피드백 개선

같이 소속되어 있는 그룹에 당근마켓 프론트엔드 이동근 개발자님이 컨퍼런스 관련한 경험이 있다는 소식을 들어서 위 사진과 같이 피드백을 요청하였습니다. 흔쾌히 응해주신 이동근 개발자님 감사드립니다.

피드백 중 두 개를 공개할게요!

듣는 이들이 듣고 싶은 것을 말하는가?
구체적으로 정해진 대상이 있는가?

원래는 위에서 계속하여 언급이 되었지만 초반에는 발표가 기술에 초점이 맞추어져 있었어요. 누구는 webpack에 대해서, 누구는 vite에 대해, react에 대해, typescript에 대해서 등 기술 발표를 하려고 하였습니다. 애초에 스터디에서 출발했기 때문인데요. 진행하면서 컨퍼런스로 바뀌었고 자연스럽게 대상도 바뀌었었습니다. 그런데 내용은 그대로였어요.

기획이 바뀌며 Front-end Developer를 꿈꾸는 대학생들이 정보 공유를 통해 한층 더 성장하는 자리를 만드는 것이 목표로 바뀌었거든요. 이 안에는 이번에 새로 시작하는 분들도 계실 거고 프론트엔드 분야를 모르시지만 이번 기회에 알게되어 유입되는 대학생분들, 이미 학습하고 계신분들과 마지막으로는 현업에서 일하고 계신 대학생분들도 있다고 생각했어요.

피드백을 듣고 단순히 기술 발표가 되면 안 된다고 생각했습니다. 대상을 구체적으로 설정하여 듣는 이가 듣고 싶은 것을, 원하는 것을 가져가는 자리를 만들면 더 의미가 있다고 생각했어요. 왜냐하면 제가 이 프로그램을 시작한 이유는 같은 프론트엔드 분야를 공부하는 많은 대학생분들과 많은 이야기를 하고 싶었던 거였거든요. 그래서 초반에 언급했던 스터디를 구할 때도 대학생분들과 함께하고 싶었던 거였고 그 힘으로 여기까지 온 것이었어요. 대학생, 공감대. 이것을 가장 중요하게 생각했습니다.

그리고 스피커분들과 이야기 주제에 대해 다시 고민했어요. 나름대로 카테고리도 구분했습니다. 나만이 할 수 있는 유니크한 이야기, 프론트엔드 공부한 이야기, 고민한 지점 등에 대해서 고민했어요. 이동근 개발자님의 피드백 덕분에 F - UNIV 색깔이 잡혀가는 느낌을 받았습니다.

홈페이지 만들기

F - UNIV는 소개할 수 있는 페이지가 필요했어요. 사람들이 그 페이지를 통해 F - UNIV가 어떤 행사인지 알고 참여할 수 있게끔 해야 했기 때문인데요. 디자인이 필요했습니다. 그래서 저는 카카오X구름 해커톤에서 같이 대회를 진행했었던 4567의 디자이너 이채민님에게 요청했어요. 혹시 이런 걸 기획하고 진행하고 있는데 디자인해볼 생각이 있는지!

디자이너 섭외하는 방법: 쉽다고 말한다.

이채민님은 재미있을 것 같다고 흔쾌히 참여의사를 밝혀주셨습니다. 넘어와주셔서 감사합니다 채민님 ㅎㅎ 참고할만한 자료들을 보내주면 디자인 시작을 한다고 해주셨어요. 그리고 엄청난 양의 작업이 시작됩니다 ㅋㅋ....

스포주의(일부분)

레퍼런스 제공

FECONF와 JSCONF 사이트를 디자이너분에게 제공했습니다. 원하는 메인 컬러와 어떤 느낌의 홈페이지였으면 좋겠다는 레퍼런스도 함께 드렸어요. 제일 중요한 마감일도 같이!

1차 디자인

그렇게 마감일이 되어서 1차 디자인이 나왔습니다. 지금 홈페이지와는 많이 다르죠? 처음부터 최종까지 10번 이상을 수정했어요..! ㅠ ㅋㅋㅋ 갑자기 디자이너분에게 죄송하네요. 감사합니다 ㅎㅎ

더 자세히 보여드리면 이렇습니다! 이때는 이름도 2022 Front-end univ.conference였어요! 그리고 느낀 점과 사용자가 보기에 더 편리한 방향성들에 대해 디자이너 분과 통화하면서 실시간으로 이야기를 주고받았어요. 그렇게 2차에서는 7개 정도의 시안을 받아볼 수 있었습니다.

2차 홈페이지

디자인을 받고 저는 6번을 선택했어요. 선택하고 가만히 있을 수 없겠더라고요. 바로 개발하고 싶었거든요. 즉시 개발을 하여 배포한 홈페이지를 통해 디자이너분에게 시각적으로 보여드렸습니다. 홈페이지 개발이 어느 정도 진행되면서 한 가지 이슈가 생겼었어요. 스피커분들의 발표 주제와 내용이 필요했습니다. 아직 결정되지 않았거든요.

그리고 언제까지 드리겠다고 약속하였습니다. 그렇지만 그때까지 개발을 멈출 수는 없었어요. 기한이 촉박했기 때문인데요. 홈페이지가 일정보다 적어도 2주 전에는 완성이 되어야 홍보가 가능해서 다음으로 계속해서 나아갔습니다.

멈추지 않고 제 데이터를 제공해 드린 후에 그 정보로 다른 분들의 공간을 채운 후 진행했어요. 파비콘도 미리 요청하고 받았습니다! F - UNIV에 파비콘이 생기는 순간이었어요!

계속해서 다음으로 나아갔습니다. 부족한 부분을 조금이라도 개선하여 더 나은 사용자 경험을 드리고 싶었고 그것은 곧 행사 신청으로 이어진다고 생각했기 때문이었어요.

너무 개발 쪽으로 이야기가 진행된 것 같아서 다시 행사 기획 쪽으로 넘어오려고 해요. 이야기하고 싶은 것이 아직도 많이 남았네요 ㅠ.

스피커분들과의 첫 미팅

다들 바쁘신 일정에도 시간을 내주셔서 강남역 카페에서 다 같이 만나는 시간을 가질 수 있었어요!

만나서는 일정 공유와 주제에 대해서 확실하게 정하는 시간을 가졌어요. 예정된 홈페이지 완성 일정까지 이제 일주일이 남았었기 때문이에요. 그리고 한 시간을 넘게 몰입하여서 고민한 끝에 지금의 발표 주제가 정해지게 되었습니다!!!

짜자잔~~

이때 취업을 준비하시는 분들은 취업 준비로, 회사 다니시는 분들은 회사일로 다들 바쁘셨는데도 불구하고 맡아주신 일에 대해서 최선을 다해주셨어요. 너무너무 감사드려요! 글을 작성하고 있는 지금, 미취업이셨던 3분 중 저를 제외한 2분은 취업에 성공하셨습니다!!!! 정말 축하드려요!!! ㅎㅎ 잘되실 줄 믿고 있었습니다. 앞으로도 응원해요!!!!

그렇게 미팅이 끝나고 바로 디자이너분에게 정보를 전달해 드린 후 저는 바로 동네 카페로 돌아가서 다음을 이어갔어요.

홈페이지 개발

그렇게 여러 번의 수정, 여러 가지 선택을 통해 ver1의 웹페이지가 개발 완료 일정 하루 전에 완성이 되었습니다!!!!!!!!!!!!!!!!! 우와아!!!!!!! ㅋㅋ 그렇게 쉬는 시간을 가졌으면 좋을 테지만 저는 아직 많은 피드백이 필요했어요. FECONF에게 메일을 보냅니다.

이메일 피드백 요청

2차 피드백 개선

그렇게 메일을 보낸 며칠 후, FECONF 오거나이저분에게 답장이 옵니다!!!! 내용은 피드백과 함께 오프라인 만남 제안이었어요. 그렇게 오프라인으로 만나 개발자분들의 피드백을 듣게 됩니다.

이번에는 피드백 네 개를 공개할게요!

홈페이지가 대학생만의 느낌이 없는 것 같아요.
CONF는 아무래도 기술에 대해 더 기대하게 만들어요.
리허설을 많이 하면 좋아요.
지속성이 중요해요!

1번의 피드백에 대해서는 생각하지도 못하고 있었어요. 그리고 듣자마자 바로 납득했습니다. 왜냐하면 처음에 레퍼런스를 FECONF와 JSCONF를 보면서 홈페이지를 만들었기 때문이에요. 그런데 이제 시간이 없었습니다. 곧 발표기도하고 저는 발표 내용 준비와 여러 가지 행사 진행에 대해 신경 써야 하는 부분이 많이 남았기 때문에 홈페이지를 새로 추가 개발하는 건 어려운 상황이었어요.

2번 피드백도 동의했습니다. 대학교 재학생으로 이루어졌고 저를 제외한 스피커분들이 좋은 회사에 재직 중이시라고 하시지만 그래도 아직 대학생이 실무 몇 년 차 고수분들에 비하면 기술에 대해 안다고 얼마나 알겠어요 ㅠㅠ. 그러던 중에 친구에게 제가 진행하는 행사를 소개하던 중 제가 오타를 낸 것이 생각났어요. 컨퍼런스를 캠퍼런스로 보내는 오타를 냈습니다. 해당 피드백은 네이밍을 바꾸어 브랜딩 전략을 다르게 가져가면서 해결하는 방향으로 가져갔어요. 캠퍼스 + 컨퍼런스를 합친 캠퍼런스로요!

3번은 리허설을 많이 하면 좋겠다고 하셔서 마지막 발표주에는 비정기 온라인 미팅과 전날에 오프라인 미팅 시간을 잡으며 최대한 연습했어요.

마지막으로 4번 지속성에 대해서 엄청 고민한 끝에 행사가 끝날 때 내년을 빛내주실 스피커분들을 모집한다고 이야기를 했습니다! 저는 앞으로 계속 프론트엔드 분야에 공부할 생각이기에 지속하는 것은 어려운 문제가 아니였어요. 프론트엔드 분야를 공부하는 분들을 앞으로도 많이 알고 싶었기도 하고요!

1번 피드백은 해결이 안 되었네요?

홈페이지 리팩토링... 결단의 시간을 가져야 했습니다. 제가 시간 내는 건 둘째 치더라도 디자이너분이 시간이 없으시면 불가능했어요. 고민을 엄청 한 끝에 안 하는 것보다 하는 게 더 좋다는 생각으로 마무리되어 디자이너분에게 해당 피드백 내용을 전달합니다! 그리고 아주 조금만 바꾸자고 조금씩 설득한 끝에 조금 바꾸는 걸 성공했어요. (하나 조금 바꾸면 다른 것도 조금씩 바꾸어야 하는..) ㅋㅋ 그렇게 결국 전체가 바뀌었습니다.

2차 홈페이지 개발

폰트찾기

대학생에게 맞는 폰트를 엄청 찾아보고 색상도 좀 더 밝게, 문구도 더 어리게 가져가려고 노력했어요.

ver2

여러 번의 작업을 고치고 고민한 끝에 현재 페이지가 완성되었습니다. 분량상 여기까지 오는 과정까지는 스킵해야 할 것 같아요!

잠깐! 어느 순간부터 이름이 F - UNIV가 되지 않았나요?

3차 피드백으로 갑니다.

3차 피드백

개발자 장현석님께서 이름이 너무 길다고 하시면서 다른 이름을 제안해 주셨어요!

F-univ

그렇게 지금의 F - UNIV가 탄생했습니다 ㅋㅋㅋ 굵직굵직하게 몇 차 피드백이라고 적었지만 다른 피드백 주신 분들도 많으셨고 다 도움이 되었습니다. 조언주신 모든 분들 감사드려요!

유데미 코리아의 후원

이제 홈페이지가 완성되었고 사람들에게 알리는 것만 남았어요. 링크를 여기저기 뿌리고 다니던 중 위에도 언급되었었던 장현석 개발자님이 도움이 필요했던 저에게 유데미의 콘텐츠 매니저분을 소개해 주셨어요!

유데미 콘텐츠 매니저 상아님과의 첫 대화

제가 필요했던 건 두 가지였어요.

ZOOM 유료 계정 (웨비나)
발표 장소 (스피커분들과는 오프라인으로 진행)

위 두 가지에 대해 지원이 가능하다고 하여 이야기를 이어갔어요! 긍정적으로 이야기가 오가던 중 발표 장소에 대한 지원은 어렵다고 하셨습니다 ㅠㅠ 이유는 행사 일자가 일요일로 주말이라서 어려웠어요. 그렇지만 제가 필요했던 ZOOM 유료 계정에 대한 지원은 받을 수 있었어요! ㅋㅋ 너무 감사한 마음에 행사일에 채팅창으로 유데미 홍보를 몇 번 했는지 모르겠습니다 ㅋㅋㅋ

발표 전 추가 개발

카운트다운

발표시간이 다가오면서 카운트다운이 있으면 좀 더 나을 것 같아서 추가했어요! 해당 시간이 지나가면 COMING SOON 부분은 사라지면서 링크 버튼은 ZOOM으로 이동하게 끔 구현했습니다. 그전에는 링크 연동을 막고 행사 시간을 기다려달라는 알림을 넣었어요!

4차 피드백

마지막 피드백입니다. 마지막 피드백은 역량이 뛰어나신 우리 스피커 팀원분들에게 받았어요! 다들 발표 준비를 열심히 해주셨는데 관련 템플릿이 있으면 좋겠다고 하셔서 템플릿을 만들었습니다.

이런 속지였어요! ㅎㅎ 원래 오른쪽 아래에 챕터 정보는 없었는데 팀원분 중 한 분께서 있으면 더 좋을 것 같다고 하셔서 추가가 되었어요. 그리고 여러 가지 리허설을 진행하면서 부족했던 부분들에 대해 추가적으로 피드백을 받고 성공적으로 행사를 마무리할 수 있었습니다.

결과

결과는 3,469회의 홈페이지 유입과 55개의 대학을 다니시는 159명의 재학생분들이 신청해주셨고 행사도 성공적으로 마무리되었습니다.

마무리

ZOOM 계정을 지원해주신 유데미와도 성공적으로 마무리할 수 있었어요! 감사드립니다!! 정말 많은 분들이 도와주셨어요. 도움을 주신 덕분에 짧은 기간에도 성공적으로 진행할 수 있었습니다. 정말 감사드립니다.

추억 기록 22.12.17

이번 포스팅에는 분량상 일정 부분이 생략되었는데 도움을 주신 모든 분들 정말 다시 한번 감사드리며 글을 마칩니다.

제 다음 행보는 어떻게 될까요?

프론트엔드 개발자 선택 후, 약 반년간의 회고 (feat. 왜 프론트엔드를 선택하셨나요?)

퉁이리 — Sun, 9 Oct 2022 07:30:00 +0900

첫 회고글

안녕하세요! 저는 컴퓨터sw 재학 중인 4학년 퉁이리입니다.

취업을 준비하며 최근 많이 받았던 질문 중 하나를 고르자면 왜 프론트엔드를 선택했는지에요.

그래서 언제부터 프론트엔드를 시작했고 그 이유가 무엇인지에 대해 그냥 일기장 적듯... 제 생각도 정리해볼 겸 편하게 적어보려고 해요.

프론트엔드 개발자의 길 선택

프론트엔드 공부는 2022년 2월부터 시작했어요. 이전까지는 평범한(?) 컴퓨터 전공 대학생으로 살았습니다. 왜 프론트엔드를 선택했냐라고 물으신다면 인턴십에서 최우수상을 받고나서부터였어요. 인턴십은 학교에서 대학교와 스타트업을 이어주는 프로그램이 있었는데 운 좋게 웹개발자로 참여할 수 있었고, 6주간 스타트업에서 웹 개발을 한 후에 성과보고대회에서 최우수상을 수상했습니다. 해당 인턴십에서 업무는 주로 레이아웃 조작(HTML, CSS)을 했어요. 기존의 홈페이지를 예쁘게 리뉴얼하는 작업을 했습니다.

직접만든 로켓단 개발.Ver

웹개발을 하는 인턴십 기간 내내 재미있게 개발을 했고 결과가 수상까지 이어지는 경험을 한 후 프론트엔드 개발자 해야겠다라고 결심을 했어요. 그렇게 리액트와 첫 만남을 가졌죠. 저는 무언갈 만들어보면서 공부하는 것을 선호해서 아무것도 모른 상태로 바로 개발을 시작했어요. 단순 덧셈 게임을 만드는 것을 생각하고 MVP를 만들어갔어요. 참고로 혼자 진행하는 개인 프로젝트였어요.

첫 프로젝트 배포까지

첫 개발이 쉽다고는 할 수 없지만 어렵다고 생각할 틈도 없이 재미있게 개발에 몰두했어요. 그렇게 첫 개발 20일차에 첫 배포까지 성공했습니다. 배포는 대학교 커뮤니티 "에브리타임"에 올려서 사용자 피드백을 받았어요. 반응은 폭발적이었습니다. 82개의 댓글이 달리면서 인기 게시글로 등극하는 성과를 가져왔어요. 그리고 교내 학보사에서도 관심을 주셔서 교내 뉴스 기사에도 실리게 되었어요. 해당 경험을 통해 더욱 프론트엔드 개발자의 길에 대해 확신을 얻고 다음 프로젝트와 개발 공부를 이어갔어요.

2개월만에 회사 지원까지

그렇게 2달동안 총 3개의 프로젝트를 완성하고 2개의 프로젝트 진행과 5개의 스터디를 진행하였고, 진행한 프로젝트들을 정리하여 이력서를 써봤어요. 이력서의 내용은 제가 학교에서 운영하는 동아리 FLAG에서의 성과와 프로젝트로 채워졌어요. 그리고 개발 2개월차가 겁 없이 회사에 지원하기 시작합니다. 그런데 결과가... 지금 생각하면 믿기지 않네요.

당근마켓

토스

2개월짜리 제 서류가 통과를 하여 면접 경험과 과제 경험을 할 수 있는 소중한 시간을 가졌어요. 그리고 현실적인 벽을 느꼈습니다. ~~(이때만 해도 저는 제가 개발 천재인 줄 알았지요.....이게 왜 돼....?)~~ 면접 경험과 과제 경험에서 느낀점을 공유해드릴게요.

첫 면접 경험

실무 개발자님과 개발 이야기는 처음이라... 너무너무 설렜습니다. 그리고 면접에 팬심 가득 안고 입장을 했어요. 그리고 들은 질문 중 하나.

타입스크립트의 유틸리티 타입 중에서 PICK이 있는데요. 혹시 사용해보신 경험이 있으신가요?

네?? 타입스크립트???? 유틸리티 타입??? PICK????

머릿속은 혼돈의 카오스.... 타입스크립트가 무엇인지도 모르고 유틸리티 타입??? 그리고 PICK??? 아무리 생각해도 무엇인지 전혀 모르겠단 말이죠... 그래서 대답을... 이렇게 했던 거 같아요.

그... PICK이요....? 그게 무엇일까요...? 하하...

그렇게 면접이 마무리됨과 동시에 자신만만하던 제 모습은 사라지고 절망에 빠졌어요. 그리고 메타인지를 자연스럽게 하게 되었죠. 그리고 더 공부를 했어요. 여기서 배운 교훈은 많은 개발자분들과 대화를 통해 생각을 공유하는 것과 주기적으로 면접을 보자라는 생각을 했어요.

많은 개발자분들과 대화를 통해 생각을 공유하면 몰랐던 부분을 아는 기회가 될 수도 있고, 잘못알고있었던 지식을 바로잡을 수 있는 기회를 얻을 수 있다는 것을 몸소 깨달았어요. 그뿐만 아니라 상대방에게 제 생각을 공유하면서 제대로 설명하지 못하는 부분에 대해 추가 학습할 수 있는 기회까지 얻을 수 있는 기회였어요.

두 번째로 주기적으로 면접을 보자고 생각한 이유는 실무 개발자분들에게 현업에 연계되기도 하면서도 기초가 되는 기술 질문(신입 기준)을 받으며 제 자신을 시험할 수 있는 좋은 경험을 할 수 있을 뿐만 아니라 말하는 능력까지 기를 수 있는 기회라고 깨달았습니다. 사실 첫 번째로 배운 교훈인 대화를 통해 생각을 공유하는 것은 말이 통해야 가능하다고 생각해요. 그래서 말하는 능력이 매우 중요하다고 생각했습니다.

첫 과제 경험

아무것도 모르는 상태에서 시작해서 여러 프로젝트를 성공적으로 진행한 경험이 있는 저로서 과제는 무섭지 않았어요. 받기 전까지는요. (^^;)

정해진 몇시간 동안 주관식과 기능 개발을 진행하는 과제를 받았는데 과제에서도 자바스크립트와 타입스크립트를 선택하게 되어있어요. 이때, 타입스크립트 공부의 필요성을 절실히 다시 깨달았어요. 타입스크립트의 진짜 필요성은 타입스크립트를 공부하면서 자연스럽게 알게 되었지만요. 그리고 예상하신 대로 과제를 받고 나서 절망편 2탄을 찍었어요.

테스트를 전부 통과해야.... API 연동을 하여....

테스트??????? API????? 절망편 2탄 시작

혼자 프로젝트를 진행해서 백엔드와 협업을 한 경험이 없던 저는 API 경험이 거의 없었고, 테스트 코드는 짜 본 경험은 당연히 없었어요. 과제를 받고 깨달은 것은 여러 분야와 협업 경험을 풍부하게 해야겠다와 안정성 있는 코드를 작성해야겠다였어요.

이때 깊게 생각해보니 여러 분야와 협업 경험은 프론트엔드 개발자라면 필수라고 생각했어요. 서버에서 데이터를 받아와 처리할 때, 서버 개발자와 소통이 가능한 수준이라면 더 효율적으로 데이터를 받아올 수 있을 것이고, 디자이너 분과의 소통이 가능한 수준이라면 더 예쁘고 더 나은 UX를 제공할 수 있을 것이고, 기획자와 소통이 가능한 수준이라면 더 나은 서비스를 만들 것이라는 확신을 가졌어요.

두 번째로 과제에서 테스트 코드를 보고 든 생각은 테스트 코드를 공부해야겠다도 생각했지만 안정성 있는 코드를 작성하고 싶은 욕구가 생겼어요. 그때부터 "클린 코드", "의존성" 이런 단어들을 검색하면서 공부를 했어요. 테스트 코드를 보고 안정성 있는 코드를 짜야겠다고 느낀 이유는 본질에 주목했기 때문인데요. 테스트를 하는 이유는 예상치 못한 부분에서의 오류를 찾을 수 있고 테스트 코드를 통해 코드 관리에 유리하다고 생각했어요. 그렇게 안정성 있는 코드를 짜야겠다는 교훈을 얻었습니다.

2개월 차에 많은 일이 일어났고 또 기적 같은 일이 찾아옵니다. 돌이켜보니 저는 운이 정말 좋았네요.

우아한스터디

우아한형제들에서 진행하는 우아한스터디 자바스크립트 완벽가이드에 지원했는데 운 좋게 선발이 되었어요. ~~(정말 운이 좋았... TOP 시크릿 비하인드 스토리가 있음둥)~~

그리고 다양한 실무 경험을 하신 개발자분들과 소통할 수 있는 소중한 경험을 했어요. 글을 쓰고 있는 지금도 진행 중인 ing에요. 매주 정해진 분량을 읽고 생각을 공유하는 시간을 가지는데 당시 저에게 필요한 것들을 전부 하고 있던 스터디였어요. 아참! 이때는 5월로, 저는 개발 3개월 차에 접어드는 시기였어요.

다양한 실무 경험을 하신 개발자분들과의 소통을 통해 정말 많은 것을 얻었어요. 소중한 경험이네요. 이렇게 소중한 기회를 놓치지 않기 위해 진행하는 기간 동안 출석 100%를 했어요. 글을 작성하는 지금 우아한스터디 자바스크립트는 종료되었지만 후속 스터디를 이어서 진행하고 있어요. 지금까지 글의 전개 흐름상 뒤의 이야기라 뒤에서 이야기를 다시 이어갈게요.

Fun.D 7기

그리고 6월이 되어 개발을 시작한 2월부터 같이 한 Fun.D가 마무리되었어요. 저는 엄마의 잔소리에 속해있었고 성과대회에서 우리 팀이 최우수상을 받았어요 ㅎㅎ! 여러 분야와의 협업 경험을 하고 싶어서 들어간 IT 연합동아리였는데 기획자, 디자이너, 개발자분들과 협업을 했고 전부 좋은 분들을 만나게 되어서 너무 좋았네요. 팀 이름을 JASIK팀이라고 부르고 있는데 아직까지 정기적으로 회의를 하고 있고 개발 또한 계속해서 진행하고 있습니다.

가장 인상 깊었고 도움을 많이 받았던 것은 문서 정리였어요. 자랑을 하자면 우리 JASIK팀은 문서화가 정말 잘되어있어요. 일정이나 진행상황 공유, 문의사항 등을 전부 문서화하여 팀에서 공유가 되고 있어서 진행이 수월했어요. 그래서 프로젝트를 진행하거나 어떠한 일을 진행할 때, 문서화의 중요성을 잘 알아서 신경을 많이 쓰면서 하려고 노력해요.

KAKAO X GOORM 해커톤

그리고 8월에 KAKAO X GOORM 해커톤이 열렸어요. 400명이 넘는 지원자가 지원을 했고 30명이 선발되는 해커톤 참여하는 좋은 기회를 얻었어요. 여기 해커톤에서 결과도 최우수상을 수상했어요! 팀 이름이 4567이었는데 팀 구성원 나이가 24, 25, 26, 27라서 4567로 지었어요.

짧은 시간 안에 MVP를 완성해야 했는데 저는 짧은 기간에 MVP 완성하는 것에 자신이 있었어요. 그래서 새로운 기술도 도입하면 재미있을 거 같다고 생각을 해서 해커톤 기간에 소개받은 GDS와 Goorm IDE을 사용하여 개발을 진행했어요.

저 혼자서 짧은 기간 안에 무엇을 만드는 경험은 많았지만 기획자, 디자이너, 서버 개발자 분들과 같이 만드는 경험은 처음이었어요. 해커톤 경험을 통해 느낀 점은 협업의 중요성과 디자인 시스템의 중요성이었어요. 사실 해커톤은 무언가 배워서 적용하기엔 해커톤 특성상 기간이 너무 짧고, 내가 공부한 것들을 검증하고 시험해본다는 특성이 강하다고 생각해요.

협업은 이전에 경험했던 다양한 분들과의 소통 경험이 해커톤에서 빛을 발휘했어요. 의견이 갈리면 빠르게 의견을 취합하여 정리했고 갈등이 생기는 부분에 대해서는 문제 본질에 집중하여서 문제 해결하는 것에 포커스를 맞추어 디벨롭해갔어요.

그리고 짧은 기간에 진행하다 보니 디자인에서 디테일을 놓칠 수도 있을 것 같다는 생각이 스쳤고 해커톤 기간에 배운 디자인 시스템을 도입하여 디자이너와의 소통 비용을 줄이기로 결정했어요. 결과는 성공적이었고 해커톤에서 우리 팀만 디자인 시스템을 적용했던 걸로 기억해요. UI적인 부분은 디자인 시스템이 알아서 해결해주어서 로직에 더 집중하는 경험을 했어요.

우아한스터디 (후속 스터디, 집필)

우아한스터디 자바스크립트 완벽가이드가 종료되었고 스터디 리더님께서 후속 스터디를 이어서 할 생각이 있는 스터디원이 있다면 이어서해도 좋다고 말씀해주셨어요. 그러던 중 스터디 원분 한분이 좋은 아이디어를 내주셨어요.

e-book 만들어보는 건 어때요?

듣자마자 저는 너무 좋은 아이디어라고 생각하고 아이디어를 내주신 스터디원분에게 연락을 했어요.

그 아이디어 혹시 제가 책임지고 진행해봐도 될까요?

흔쾌히 허락해주셔서 인원을 모집하고 현재 진행 중에 있는 프로젝트예요. 제가 듣자마자 바로 좋은 아이디어라고 생각했던 이유는 우아한스터디의 결과물이 될 수 있을 것 같다고 생각했어요. 어떠한 과정을 통해 결과물을 내는 것은 생각보다 중요하다고 저 개인적으로 생각해서 현재 진행 중에 있어요.

2022 FECONF

글을 쓰고 있는 지금은 2022 FECONF에 다녀왔어요. 6초 만에 매진되었다는 티켓. 제가 티켓팅에 성공했습니다. 수강신청으로 단련되어있는 대학생이에요. ㅋㅋ

여기까지 제가 프론트엔드를 선택하고 나서부터의 여정을 한번 풀어봤어요. (생략한 경험도 많아요. 저와 함께한 시간이 해당 블로그에 적히지않아도 이해해주세요.... 가슴에 간직하고 있어요...) 이렇게 긴 호흡의 글은 제 블로그에서 처음이네요. 여기까지 제 여행기를 읽어주셔서 감사해요.

앞으로의 제 이야기가 궁금하신가요? 저도 궁금하네요. 같은 시간을 공유하는 우리. 같이 재미있는 이야기를 만들어가요!

감사합니다.

[프로그래머스] 코딩테스트 연습 : 올바른 괄호 - PYTHON[파이썬]

퉁이리 — Sun, 4 Sep 2022 04:23:16 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/118666?language=python3

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

⊙ 문제

⊙ 제한사항

⊙ 입출력 예

⊙ 문제 접근 과정

servey와 choices가 주어진다.

servey는 앞은 비동의일 때, 뒤는 동의일 때 어떤 유형인지 알려준다.

choices는 동의 여부에 대해 알려준다.

4를 분기점으로 나눈다. 이때 4의 경우는 결과에 영향이 없어서 고려해주지않았어요.

배열을 하나 만들고 거기에 점수만큼의 해당 유형을 추가해주었다.

count함수를 통해 개수를 세고 더 많은 유형을 result 문자열에 추가해주었다.

동일한 경우에는 앞의 유형을 우선으로 추가.

⊙ 문제 풀이

def solution(survey, choices):
    answer = []
    result = ""
    
    for cnt in range(len(survey)):
        if choices[cnt] < 4:
            for _ in range(4-choices[cnt]):
                answer.append(survey[cnt][0])
        if choices[cnt] > 4:
            for _ in range(choices[cnt]-4):
                answer.append(survey[cnt][1])
        
    if answer.count('R') < answer.count('T'): result+='T'
    else: result+='R'
    if answer.count('C') < answer.count('F'): result+='F'
    else: result+='C'
    if answer.count('J') < answer.count('M'): result+='M'
    else: result+='J'
    if answer.count('A') < answer.count('N'): result+='N'
    else: result+='A'
        
    return result

⊙ 마무리

잊을만하면 돌아오는 알고리즘

좋아요는 로그인하지 않아도 누를 수 있습니다!

[타입스크립트] 타입 추론 vs 타입 어노테이션

퉁이리 — Mon, 18 Jul 2022 20:03:38 +0900

타입스크립트 프로그래밍 책을 읽다가 생소한 단어가 눈에 들어왔어요. 타입 어노테이션.

타입 어노테이션과 타입 추론, 둘을 비교하면서 어떠한 친구들인지 한번 알아보는 시간을 가져보아요!

타입 추론

선언과 초기화를 동시에 하여 초기화된 값을 통해 타입을 해석하는 동작을 말해요.

const tooo1 = '퉁이리'

위와같이 선언과 초기화를 동시에 해주면 타입스크립트는 tooo1의 값을 string으로 간주해요.

초기화를 해준 '퉁이리'의 값을 통해 string을 추론한 것이죠.

실제로 typeof를 통해 확인해보면 'string'이라고 나옵니다.

원래 C언어나 C++ 등 자바스크립트 이전 언어들은 보통 타입을 선언해주었어요.

string tooo1 = "퉁이리";

다음과 같이요.

그렇지만 우리 멋진 자바스크립트는 타입 선언을 안 해주어서 타입을 추론합니다.

그런데 선언을 할 때, 초기화를 해주지 않으면 타입을 추론할 수가 없어요.

이때는 다른 방법으로 타입을 알기 위해 타입 어노테이션을 사용합니다.

타입 어노테이션

선언 시 타입을 직접 알려주는 것을 말해요.

const tooo1:string

다음과 같이 변수나 상수명 뒤에 콜론(:)을 찍은 후, 타입을 직접 선언하는 방법이에요.

타입 어노테이션을 사용하면 타입 추론과 달리 값을 초기화하지 않아도 타입을 알려줄 수 있어요.

말 그대로 변수 뒤에 어노테이션, 주석을 달아서 알려줍니다!

좋아요는 로그인하지 않아도 누를 수 있습니다!

[프로그래머스] 코딩테스트 연습 : 짝지어 제거하기 - PYTHON[파이썬]

퉁이리 — Fri, 1 Jul 2022 16:25:06 +0900

https://programmers.co.kr/learn/courses/30/lessons/12973

코딩테스트 연습 - 짝지어 제거하기

짝지어 제거하기는, 알파벳 소문자로 이루어진 문자열을 가지고 시작합니다. 먼저 문자열에서 같은 알파벳이 2개 붙어 있는 짝을 찾습니다. 그다음, 그 둘을 제거한 뒤, 앞뒤로 문자열을 이어 붙

programmers.co.kr

⊙ 문제

⊙ 제한사항

⊙ 입출력 예

⊙ 입출력 예 설명

⊙ 문제 접근 과정

총 3번의 도전.

- 첫 번째 풀이 -

2중 반복문 + replace (일부 통과, 시간 초과)

def solution(s):    
    while len(s):
        flag = True
        for i in range(len(s)):
            if s[i]+s[i] in s:
                s = s.replace(s[i]+s[i],'')
                flag = False
                break
        if flag:
            return 0
    
    return 1

반복문을 돌려서 같은 것이 연달아 배열 안에 있다면 replace로 변경해주면 되겠다고 생각했어요.

문제점

1. 배열을 반복문 중 직접 건든다.

2. 2중 반복문으로 시간 복잡도(O(n^2))가.. (문자열이 1,000,000까지 인데...)

첫 번째 풀이 결론: 여러 허점이 많다.

- 두 번째 풀이 -

첫 번째 풀이 + set (일부 통과, 시간 초과)

def solution(s):    
    listS = set(list(s))
    
    for _ in range(len(s)//2+1):
        for l in listS:
            while l+l in s:
                s=s.replace(l+l,'')
    
    if len(s):
        return 0
    return 1

첫 번째 풀이 때의 replace 함수에 대한 미련을 버리지 못하고 한번 더 도전을 해보았어요.

이번에는 3중 반복문이네요.. ㅋㅋ

나름 반복을 줄인다고 set을 사용하고, 절반 길이를 사용해보았지만 역시나 근본적인 해결을 하지 못했습니다.

두 번째 풀이 결론: replace를 버리자.

- 마지막 풀이 -

stack (통과)

def solution(s):    
    stack = []
    
    for i in s:
        if not stack:
            stack.append(i)
            continue
        
        stack.pop() if stack[-1] == i else stack.append(i)
        
    if stack:
        return 0
    return 1

첫 번째 시도와 두 번째 시도에서 가장 큰 문제점은 n중 반복문과 배열을 직접 건든다였어요.

replace 함수를 사용하고 싶었나 봐요...

배열을 직접 건드리지 않고, 반복문을 한 번만 사용하여 해당 문제를 풀 수 있지 않을까?

고민하던 중 stack이 생각나더라고요.

바로 적용했습니다.

stack을 하나 생성해주고, 반복문을 돌려요.

stack에 값이 없으면,

현재 값을 stack에 넣어주고 다음으로 넘어갑니다.

stack에 값이 있으면,

최상단 값과 현재 값을 비교, 비교 후 같다면 pop, 다르다면 push

결론: 반복문이 끝까지 돌고 stack에 값이 남아있는지 없는지로 판별해주었더니 성공했어요.

⊙ 문제 풀이

def solution(s):    
    stack = []
    
    for i in s:
        if not stack:
            stack.append(i)
            continue
        
        stack.pop() if stack[-1] == i else stack.append(i)
        
    if stack:
        return 0
    return 1

⊙ 마무리

NONE