📱 Webview

<img src="https://image.until.blog/morethanmin/article/1717424912994" alt="until-401"><p>디자인 시스템을 구현하면서 <code spellcheck="false">:hover</code> 가상 클래스를 적용했던 경험을 기록한다.</p><p><code spellcheck="false">:hover</code>는 포인터가 해당 엘리먼트 위에 올라가 있는 상태를 나타내는 가상 클래스로 주로 버튼이나 인풋과 같은 컴포넌트를 구현할 때 사용한다.</p><p>이러한 <code spellcheck="false">:hover</code> 가상 클래스는 마우스를 올려둔다와 같은 경우가 없는 환경에서는 어떻게 동작할까? 대표적으로 터치로 동작하는 모바일 디바이스가 있을 텐데, 어떻게 동작하는지 알아보자.</p><h1><strong>터치 디바이스에서의 :hover</strong></h1><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://developer.mozilla.org/ko/docs/Web/CSS/:hover">:hover</a> 페이지의 예제를 브라우저에서 실행시켜보면 쉽게 알 수 있다.</p><pre spellcheck="false"><code class="language-css">a:hover {
  background-color: gold;
}
</code></pre><p>PC 브라우저에서는 잘 동작하지만, 모바일 브라우저에서는 마우스 포인터가 없으니 <code spellcheck="false">:hover</code> 클래스가 동작하지 않을 것처럼 보이지만, 클릭 이벤트가 발생할 경우 <code spellcheck="false">:hover</code>에 선언한 배경 색상이 변경된 채로 남아있는다. 그리고 다른 영역을 클릭하면 효과가 해제된다는 것을 알 수 있다.</p><p>그렇다면 마우스 환경과 동일하게 <code spellcheck="false">touchOver</code> 시에만 스타일이 적용되게 하려면 어떻게 해야할까?</p><h1><strong>터치 디바이스에서 동일하게 스타일 적용하기</strong></h1><h2>@media hover</h2><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media/hover">@media hover</a>를 이용하면, hover를 지원하는 환경인 경우에만 해당 스타일이 적용되도록 할 수 있다.</p><p>예시는 아래와 같다.</p><pre spellcheck="false"><code class="language-css">a:hover { /* default hover effect */
  color: black;
  background: yellow;
}

@media (hover: hover) { /* when supported */
  a:hover {
    color: white;
    background: black;
  }
}
</code></pre><p>하지만 이방법을 사용하더라도 <strong>일부 Android </strong>에서는 길게 누를 때 호버링을 에뮬레이트하는 기능이 있어 hover를 지원하는 것으로 판단하는 경우가 있다.</p><p>이러한 경우에도 동일한 경험을 제공하기 위해서는 @media pointer를 사용하면된다.</p><h2><strong>@media pointer</strong></h2><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pointer">@media pointer</a>는 장치에 포인터의 존재 여부와 포인팅 장치의 정확도를 확인한다.</p><p>mdn에서는 아래와 같이 설명하고 있다. 우리의 경우에는 fine 을 사용하면 된다.</p><blockquote><p><code spellcheck="false">none</code></p><p>The primary input mechanism does not include a pointing device.</p><p><code spellcheck="false">coarse</code></p><p>The primary input mechanism includes a pointing device of limited accuracy, such as a finger on a touchscreen.</p><p><code spellcheck="false">fine</code></p><p>The primary input mechanism includes an accurate pointing device, such as a mouse.</p></blockquote><p>결과적으로 아래와 같이 적용하면 된다.</p><pre spellcheck="false"><code>@media (hover: hover) and (pointer: fine) { /* when supported */
  a:hover {
    color: white;
    background: black;
  }
}
</code></pre><p>호버를 지원하고, 포인터를 지원하는 디바이스인 경우에만 호버 스타일을 적용할 수 있게 되었다.</p><h1>결론</h1><p>결론적으로 위 방법을 사용하면 포인터를 사용하는 디바이스에서만 호버스타일을 적용할 수 있게되었지만, 위 방법이 무조건적으로 적합한 방식인지는 생각해볼 필요가 있다.</p><p>결국 터치디바이스에서 hover스타일을 적용시키고 있는 것이 지금의 웹 표준 동작에 가깝다고 할 수 있는 것이기 때문이다.</p>

디자인 시스템을 구현하면서 :hover 가상 클래스를 적용했던 경험을 기록한다.:hover는 포인터가 해당 엘리먼트 위에 올라가 있는 상태를 나타내는 가상 클래스로 주로 버튼이나 인풋과 같은 컴포넌트를 구현할 때 사용한다.이러한 :hover 가상 클래스는 마우스를 올려둔다와 같은 경우가 없는 환경에서는 어떻게 동작할까? 대표적으로 터치로 동작하는 모바일 디

터치 디바이스에서 hover 스타일 제어하기

프론트엔드

🖥 백엔드

<pre spellcheck="false"><code class="language-java">public class ArticleService {
    private final ArticleRepository articleRepository;
    private final UserRepository userRepository;

    public Article writeArticle(ArticleWriteRequest request) {
        // ...
    }
}</code></pre><p>Layered Architecture와 함께 Spring으로 서비스를 구현하다보면 필연적으로 Repository 의존성이 생기게 된다. 그리하면 당연히 서비스의 테스트를 짜기 위해서는 Repository의 의존성을 주입해주어야 한다.</p><p></p><pre spellcheck="false"><code class="language-java">class ArticleServiceTest {
    @Test
    void writeArticleTest() {
        // given
        ArticleRepository repository = mock(ArticleRepository::class);
        when(repository.save(any())).thenReturn(
            Article.builder()
                .id(1)
                .title("title")
                .content("content")
                .build()
        );

        ArticleService articleService = new ArticleService(
            repository,
            mock(UserRepository::class)
        );
        
        // when
        articleService.writeArticle(
            new ArticleWriteRequest("title", "content")
        );

        // then
        assertThat(repository.findAll()).hasSize(1);
        assertThat(repository.findById(1).getTitle()).isEqualTo("title");
    }
}</code></pre><p>하지만 서비스의 테스트를 하기 위해 매번 <code spellcheck="false">@SpringBootTest</code>를 할 수 없는 노릇이고, 매번 이렇게 모킹을 할 경우 매번 <code spellcheck="false">when</code>을 통해 Repository의 동작을 작성해주어야 하므로 실제로 Service가 제대로 동작하는지를 확인하기 조금 까다롭다.</p><p></p><pre spellcheck="false"><code class="language-java">public class ArticleMockRepository implements ArticleRepository {
    private final Map&lt;Long, Article&gt; articleMap = new HashMap&lt;&gt;();

    public Article save(Article a) {
        articleMap.put(a);
        return a;
    }
    
    public Optional&lt;Article&gt; findById(long id) {
        return Optional.ofNullable(articleMap .get(id));
    }

    public List&lt;Article&gt; findAll() {
        return List.copyOf(articleMap.values());
    }

    public void clear() {
        map.clear();
    }
}</code></pre><p>그렇기 때문에 나는 Stub을 통해 진짜 객체를 넣어주는 것을 선호한다. 레포지토리는 HashMap을 통해 구현할 수 있으니!</p><p>하지만 Repository는 비즈니스 객체의 갯수만큼 존재할 것이고, 이걸 매번 다 짜려면 굉장히 귀찮은데.</p><p>그러니 제네릭을 활용하여 공통화를 해보자.</p><p></p><h1>제네릭을 사용해 공통화하기</h1><pre spellcheck="false"><code class="language-java">public class HashMapRepository&lt;T&gt; {
    private final Map&lt;Long, T&gt; map = new HashMap&lt;&gt;();

    protected void save(long id, T entity) {
        map.put(id, entity);
    }

    public Optional&lt;T&gt; findById(long id) {
        return Optional.ofNullable(map.get(id));
    }

    public List&lt;T&gt; findAll() {
        return List.copyOf(map.values());
    }

    // 원하는 조회 조건 생성용
    protected Optional&lt;T&gt; findBy(Predicate&lt;T&gt; predicate) {
        return map.values().stream()
                .filter(predicate)
                .findFirst();
    }

    protected List&lt;T&gt; findAllBy(Predicate&lt;T&gt; predicate) {
        return map.values().stream()
                .filter(predicate)
                .toList();
    }

    public void clear() {
        map.clear();
    }
}</code></pre><p>다음과 같이 <code spellcheck="false">HashMapRepository</code>를 구현할 수 있다. 이렇게 구현한다면 이제 각 도메인 별로 레포지토리를 만들기는 간단하다.</p><p></p><pre spellcheck="false"><code class="language-java">class ArticleMockRepository extends HashMapRepository&lt;Article&gt; implements ArticleRepository {
    @Override
    public Article save(Article article) {
        super.save(article.getId(), article);
        return article;
    }

    @Override
    public Optional&lt;Article&gt; findByAuthorId(long authorId) {
        return findBy(it -&gt; it.getAuthorId() == authorId);
    }
}</code></pre><p>다음과 같이 <code spellcheck="false">save</code>만 재정의해주면 된다.</p><p>만약 원하는 조회 조건이 필요하다면, <code spellcheck="false">findBy</code>, <code spellcheck="false">findAllBy</code>를 이용해서 원하는 조건을 <code spellcheck="false">Predicate </code>로 넣어주는 방식을 이용해서 추가해주면 된다.</p><p></p><h1>적용과 함께 마무리</h1><pre spellcheck="false"><code class="language-java">class ArticleServiceTest {
    @Test
    void writeArticleTest() {
        // given
        ArticleRepository repository = new ArticleMockRepository();

        ArticleService articleService = new ArticleService(
            repository,
            new UserMockRepository()
        );
        
        // when
        articleService.writeArticle(
            new ArticleWriteRequest("title", "content")
        );

        // then
        assertThat(repository.findAll()).hasSize(1);
        assertThat(repository.findById(1).getTitle()).isEqualTo("title");
    }
}</code></pre><p>꽤나 깔끔한 모양새로 테스트를 작성할 수 있게 됐다.</p><p></p><h1>구현해야 할 메소드가 너무 많아요</h1><img src="https://image.until.blog/octoping/article/1730861041484.png" data-width="75%" data-align="center" alt="1985"><p>이런 식으로 Stub 객체를 만드려고 했더니 <code spellcheck="false">ArticleRepository</code> 안의 인터페이스가 너무 많아서 모두 구현하기 힘들 수도 있다. ( <code spellcheck="false">JpaRepository</code> 를 그대로 상속받아서 사용 중인 경우 특히 그렇다)</p><p>하지만 그렇다고 Stub을 포기하고 Mock을 시도하는 것은, 테스트 코드가 알려주는 코드 악취를 모킹이라는 강력한 도구로 감추고 숨는 것에 지나지 못한다.</p><p>그럴 때에는 설계를 조금 고쳐보는 것은 어떨까? 이전 블로그의 글을 링크 걸어본다.</p><a data-type="bookmark" href="https://octoping.tistory.com/27" target="_blank"><div class="content"><div><div class="title">Service 계층에 적당한 무게의 Repository 의존성 지우기</div><div class="description">시작하기 전에 계층형 아키텍처에서 개발을 진행할 때 우리는 보통 Controller, Service, Repository 이렇게 3개의 계층의 구조로 짜게 된다. 이 3개의 계층은 Controller에서 Service로, Service에서 Repository로 의존성이 흐르는데, 이 중에서도 Repository 부분을 보통 JpaRepository나 Mybatis mapper 같은 클래스로 직접 의존성으로 사용하는 경우가 많다. 하지만 Service 계층에서 바로 이런 클래스들에 의존하게 될 경우 몇 가지 문제가 생기게 된다. 이 글에서는 쉬운 예제 작성을 위해 JpaRepository를 사용하겠다. Service에서 바로 JpaRepository를 의존할 때 생기는 문제 Service 계층이 세부 사항..</div></div><div class="href">https://octoping.tistory.com/27</div></div><img src="https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&amp;fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdoLA4o%2Fbtr91zZpY94%2FcfEYJzMiizQCm0JDnuHq31%2Fimg.png"></a>

반복되는 Repository Stub 코드 줄이기

HashMap으로 Repository 모킹 간편하게 하기

<blockquote><p>웹뷰에서 마주하는 여러 팁을 공유합니다.</p></blockquote><p>웹뷰를 구현하다보면 아래와 같은 화면을 자주 마주하게 됩니다.</p><p>아래 사진은 토스에서 가져왔습니다.</p><img src="https://image.until.blog/morethanmin/article/1719587839236" alt="until-680"><p>이때 하단에 항상 위치하고 있는 버튼을 보통 CTA(Click-To-Action) 버튼이라고 부르는데요. 이러한 버튼은 일반적으로 컨텐츠 위에 위치하고 있어야하기에 <code spellcheck="false">position:fixed</code>로 구현하면 됩니다.</p><p>간단한 것 같지만 한가지 고려 해야할 점이 있습니다. 컨텐츠 영역에서 특정한 높이를 차지하고 있지 않기에 뒤에 컨텐츠를 가리게 된다는 점입니다.</p><img src="https://image.until.blog/morethanmin/article/1719588105264" alt="until-681"><p>그럼 어떻게 하면 뒤 컨텐츠 영역을 가리지 않고 CTA 버튼을 만들 수 있을까요?</p><p>가장 단순한 방법으로는 최하단에 높이를 차지하는 요소를 두면 됩니다.</p><pre spellcheck="false"><code class="language-typescript">const Example = () =&gt; {
  return (
    &lt;div&gt;
      content
      &lt;Footer /&gt;
      &lt;div style={{ height: 60 }} /&gt;
      {/* 내부적으로 60px의 높이를 가진 fixed element를 렌더하고 있음*/}
      &lt;CTAButton /&gt;
    &lt;/div&gt;
  )
}

export default Example</code></pre><p>위와 같은 방식은 잘 동작하겠지만, 아래와 같은 문제점들을 마주할 수 있습니다.</p><p>바로 버튼의 높이가 동적으로 바뀌는 것에 대응할 수 없다는 것입니다.</p><p>이를 해결하기 위해서는 <a target="_blank" rel="noopener noreferrer nofollow" href="https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver"><strong>ResizeObserver </strong></a>라는 API를 사용하면 됩니다.</p><p>해당API를 사용하면 요소의 사이즈 변화를 감지하여 해당 높이를 가져올 수 있고, 이를 spacer에 주입해줄 수 있습니다.</p><pre spellcheck="false"><code class="language-typescript">const Example = () =&gt; {
  const targetRef = useRef&lt;HTMLDivElement&gt;(null)
  const spacerRef = useRef&lt;HTMLDivElement&gt;(null)

  const observer = new ResizeObserver(([entry]) =&gt; {
    if (spacerRef.current) {
      spacerRef.current.style.height = `${
        entry.target.getBoundingClientRect().height
      }px`
    }
  })

  useEffect(() =&gt; {
    if(!targetRef.current) return

    const el = targetRef.current

    observer.observe(el)

    return () =&gt; {
      observer.unobserve(el)
    }
  }, [])
  
  return (
    &lt;div&gt;
      content
      &lt;Footer /&gt;
      &lt;div style={{ height: 60 }} /&gt;
      {/* 내부적으로 60px의 높이를 가진 fixed element를 렌더하고 있음*/}
      &lt;CTAButton /&gt;
    &lt;/div&gt;
  )
}

export default Example
</code></pre><p>이러한 CTA 버튼이나 Appber처럼 fixed요소만큼 너비를 차지해야하는 경우들이 자주 발생하기에 <code spellcheck="false">useSpacer</code>라는 hook으로 분리해 보겠습니다.</p><pre spellcheck="false"><code class="language-typescript">import { useRef, useEffect } from "react";

export const useSpacer = () =&gt; {
  const targetRef = useRef&lt;HTMLDivElement&gt;();
  const spacerRef = useRef&lt;HTMLDivElement&gt;(null);

  const observer = new ResizeObserver(([entry]) =&gt; {
    if (spacerRef.current) {
      spacerRef.current.style.height = `${entry.target.getBoundingClientRect().height}px`;
    }
  });

  useEffect(() =&gt; {
    if(!targetRef.current) return

    const el = targetRef.current

    observer.observe(el)

    return () =&gt; {
      observer.unobserve(el)
    }
  }, [])

  return { spacerRef, targetRef };
};</code></pre><p>이제 CTA 버튼을 손쉽게 구현할 수 있습니다! 👏</p><p></p><p></p><p></p>

웹뷰에서 마주하는 여러 팁을 공유합니다.웹뷰를 구현하다보면 아래와 같은 화면을 자주 마주하게 됩니다.아래 사진은 토스에서 가져왔습니다.이때 하단에 항상 위치하고 있는 버튼을 보통 CTA(Click-To-Action) 버튼이라고 부르는데요. 이러한 버튼은 일반적으로 컨텐츠 위에 위치하고 있어야하기에 position:fixed로 구현하면 됩니다.간단한 것 같지

fixed 요소만큼 높이 차지하는 CTA 버튼 구현하기

⚛️ React

<img src="https://image.until.blog/morethanmin/article/1726239900445.gif" data-width="100%" data-align="center" alt="until-1342"><p>언틸의 피드에서는 유저들이 작성한 아티클을 모달의 형태로 볼 수 있는데요.</p><p>이런 모달 형태는 유저들의 글을 빠르게 전환하며 볼 수 있다는 장점을 가지고 있어요.</p><p>하지만 React State로 관리되기 때문에 몇가지 단점이 존재했어요. 예를 들어 새로고침시에 보고 있던 게시글이 사라지거나, 브라우저의 history stack을 쌓지 않기 때문에 뒤로가기(history.back)로 닫을 수 없었어요.</p><p>이런 경험은 데스크탑에서는 그렇다 쳐도 모달이 풀페이지로 나타나는 모바일에서는 뒤로가기를 했을 때 아예 페이지가 닫혀버리는 등 유저 경험이 좋지 않았어요.</p><p>때문에 Route로 동작하는 Modal로 변경하기로 했어요. 어떤 방식으로 구현했는지 간단하게 공유해볼게요.</p><h2>ArticleCard</h2><p>우선 ArticleCard는 기존에는 onClick handler를 통해 isOpen state를 변경해주고 있었는데요. 이것을 next/Link 컴포넌트로 변경해주었어요.</p><pre spellcheck="false"><code class="language-typescript">import { LinkProps } from 'next/link'
import { useRouter } from 'next/router'
import * as _ArticleCard from 'src/components/ArticleCard'
import { ArticleItem } from 'src/types/article'

type Props = {
  data: ArticleItem
}

export const ArticleCard = ({ data }: Props) =&gt; {
  const router = useRouter()

  const href: LinkProps['href'] = {
    query: {
      ...router.query,
      'article-id': data.articleId,
    },
  }

  const as = `@${data.blog.username}/${data.urlSlug}`

  return (
    &lt;_ArticleCard.Root data={data}&gt;
      &lt;_ArticleCard.Thumbnail shallow href={href} as={as} /&gt;
      &lt;_ArticleCard.AuthorInfo showGroup /&gt;
      &lt;_ArticleCard.ArticleInfo shallow href={href} as={as} /&gt;
    &lt;/_ArticleCard.Root&gt;
  )
}</code></pre><p><code spellcheck="false">Article.Thumbnail</code> 과 <code spellcheck="false">Article.ArticleInfo</code>가 Link의 props을 대신 받아오고 있습니다.</p><p>이제 아티클 카드를 클릭하면 next/router는 href에 의해서 <code spellcheck="false">until.blog?article-id=219</code> 로 이동하게 되요.</p><p>또한 as prop을 통해 article-hash-id를 브라우저 검색창에 노출하지 않고 실제 게시글 상세 route인 것처럼 변경해주었어요.</p><h2>ArticleDetailDialog</h2><p>이제 서치파라미터에 등록된 article-id를 읽어와서 모달을 띄워주면 돼요.</p><pre spellcheck="false"><code class="language-typescript">import { useRouter } from 'next/router'
import { Dialog, useCurrentSize } from 'ui'
import Content from './Content'
import { boxStyle } from './styles'

const ArticleDetailDialog = () =&gt; {
  const router = useRouter()
  const currentSize = useCurrentSize()

  const articleId =
    typeof router.query['article-id'] === 'string' &amp;&amp;
    router.query['article-id'] !== ''
      ? Number(router.query['article-id'])
      : null

  const handleClose = () =&gt; {
    const query = { ...router.query }
    delete query['article-id']

    router.push(
      {
        query,
      },
      undefined,
      { shallow: true, scroll: false },
    )
  }

  return (
    &lt;Dialog
      open={!!articleId}
      onClose={handleClose}
      align="top"
      alignOffset={currentSize === 'desktop' ? 60 : 40}
      css={{
        maxWidth: '920px',
        width: '100%',
      }}
    &gt;
      &lt;div css={boxStyle}&gt;
        &lt;Content articleId={articleId} onClose={handleClose} /&gt;
      &lt;/div&gt;
    &lt;/Dialog&gt;
  )
}

export default ArticleDetailDialog</code></pre><p>이를 통해 유저는 새로고침을 하더라도 게시글 상세페이지를 유지할 수 있고, 뒤로가기를 통해서도 모달을 닫을 수 있게 되었습니다. 👍</p><p></p><p></p><p></p><p></p>

언틸의 피드에서는 유저들이 작성한 아티클을 모달의 형태로 볼 수 있는데요.이런 모달 형태는 유저들의 글을 빠르게 전환하며 볼 수 있다는 장점을 가지고 있어요.하지만 React State로 관리되기 때문에 몇가지 단점이 존재했어요. 예를 들어 새로고침시에 보고 있던 게시글이 사라지거나, 브라우저의 history stack을 쌓지 않기 때문에 뒤로가기(hist

next.js 에서 라우트로 관리되는 모달 구현하기 (route as modal)

<h1>들어가며</h1><p>JDK와 서버리스는 궁합이 좋지 못하다고들 한다.</p><p>서버리스는 해당 서버를 쓰지 않을 때에는 종료된다는 특성을 생각해본다면, 유독 시작 시간이 긴 Spring은 이런 서버리스와 궁합이 맞지 않는 것이 당연하다고 생각이 든다.</p><p>실제로 내가 Render의 서버리스를 이용해서 Docker로 만 Spring Boot 서버를 배포했을 때에는 콜드 스타트 시간이 2분 가까이 걸리기도 했다. 물론 Render 프리티어의 저열한 컴퓨팅 성능과 Spring의 어마무시한 시작 시간이 합쳐진 탓이었겠지만..</p><p>하지만 순수 Java 애플리케이션은 Spring과 같이 시작 시간이 크게 존재하지는 않는 것으로 보이는데, Java 개발자들은 서버리스 함수를 개발할 때 주력 언어를 버리고 어쩔 수 없이 Node.js나 Pytyhon을 사용해야 하는 것일까?</p><p></p><h1>Java가 왜 느릴까?</h1><p>Java가 왜 서버리스에서 성능이 좋지 않은지에 대해 먼저 알아보면 좋을 것 같다.</p><p></p><h2>Cold Start 문제</h2><ul><li><p><strong>JVM 초기화 시간</strong>: Java는 JVM (Java Virtual Machine)을 사용하여 실행되기 때문에, 첫 실행 시 JVM을 초기화하는 데 시간이 걸리게 된다.</p></li><li><p><strong>Class Loading</strong>: Java에서 사용하는 여러 클래스와 라이브러리를 로드해야 하므로 (Warm up), Cold Start 시 이 과정도 시간이 소요된다.</p></li></ul><h2><strong>언어 특성</strong></h2><p>Java는 소스 코드를 바이트코드로 컴파일한 후 JVM에서 실행되기 때문에, Python와 Javascript와 같은 인터프리터 언어에 비해 초기 실행이 느릴 수 밖에 없다.</p><h2><strong>환경 설정</strong></h2><p>서버리스 환경에 맞게 JVM을 최적화하지 않은 경우에도 성능이 저하될 수 있다.</p><p>AWS Lambda에서는 메모리 설정에 따라 CPU 성능이 달라지는데, 128MB에서 256MB로 메모리를 늘리는 것만으로도 속도가 확실히 향상되는 것을 볼 수 있다.</p><p></p><h1>속도 비교해보기</h1><p>물론 가장 확실한 방법은 직접 속도를 체크해보는 것이지만, 다른 멋진 분들이 이미 측정해주신 좋은 자료가 있다.</p><p>다음은 AWS Lambda에서 언어 별로 콜드 스타트 시간을 정리해놓은 글이다.</p><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://mikhail.io/serverless/coldstarts/aws/languages/">https://mikhail.io/serverless/coldstarts/aws/languages/</a></p><p></p><img src="https://image.until.blog/octoping/article/1720963479562" alt="until-838"><p>확실히 Java도 그리 느리지는 않은 속도를 보여주는 것 같다.</p><p>하지만 Python의 최소 시간은 0.14초인데 Java의 최소 시간은 0.28초인걸 보면, 절대적 시간 차이는 미미하지만 상대적 시간 차이는 2배 가까이 나는 것을 볼 수 있다. 역시 파이썬인가..!</p><p></p><h1>마무리하며</h1><p>JVM은 Warm Up이라는 개념이 존재하는 특이한 런타임인만큼, 매번 껐다 켜지는 서버리스 환경과 자바는 역시 쉽게 녹아들 수 없는 언어인가보다.</p><p>하지만 서버리스를 통해 실행하는 로직이 콜드 스타트 시간이 마치 0으로 느껴질 만큼 큰 시간이 걸리는 경우 (ex. AWS Lambda로 유튜브 영상 다운 받기) 굳이 언어에 제약을 둘 필요는 없을 것으로 보인다.</p>

서버리스와 Java는 공존할 수 없는 운명인걸까?

Spring 없는 Java조차 서버리스에서 못 써먹는걸까?

들어가며

Java가 왜 느릴까?

Cold Start 문제

언어 특성

환경 설정

속도 비교해보기

마무리하며