node v22로 업그레이드하면서 라이브러리 버전을 확인해야 했다.

로컬에서 먼저 확인하기

먼저 로컬에서 nvm으로 node를 버전업하고 빌드 에러를 확인했다.

nvm install v22
nvm use v22

그런데... 너무 잘 됨.. 빌드 성공 npm outdated 명령어를 실행했을 때 버전업이 필요해 보이는 라이브러리가 많아 걱정했는데 바로 빌드를 성공해서 오히려 당황스러웠다.

vercel에서 확인하기

그런데!! vercel에서 node 버전 업 후 redeploy를 하니 빌드 에러 발생🚨

에러를 확인해 보니 npm install 중에 발생했는데, 로컬에서는 아무리 npm install을 다시 해봐도 에러가 나지 않았다.

vercel의 에러 로그를 gpt에게 물어봤더니 다음과 같이 알려줬는데

내용을 확인하고 나니, 얼마 전 env가 제대로 인식되지 않아 프로젝트를 삭제하고 다시 clone 한 적이 있었는데, (변경된 코드가 하나도 없는데 딱 한 개의 환경변수만 인식 되지 않았다.) 그때도 npm install 시 canvas 라이브러리 설치 문제였던 게 생각났다.

brew install pkg-config cairo pango libpng jpeg giflib librsvg pixman python-setuptools

npm - canvas gpt 말대로 canvas는 위와 같이 종속 라이브러리를 설치해 줘야 하는데, 로컬에는 설치되어 있지만 vercel의 리눅스 환경에는 설치되어 있지 않아 발생한 문제였다.

그렇게 버전업을 하려고 찾던 중 발견한 사실.. canvas를 사용하지 않는다.. DOM <canvas>를 사용하는 부분은 있는데, 라이브러리를 사용하고 있는 코드는 없었다.

그래서 다른 라이브러리에 종속된 건가 싶어 아래 명령어로 확인해 봤다.

npm ls canvas

jsdom에서 사용하고 있는데 중복으로 설치되어 있어 최종적으로 해당 의존성은 남기고 직접 설치한 canvas만 제거했다.

아마 이전에 사용하던 라이브러리가 더 이상 사용하지 않는데 제거되지 않은 모양이다.🥲 제거 후 vercel에서 확인하니 빌드 성공!

테스트하니 기능적으로도 문제가 발생하지 않아 배포했다.

수정이 필요한 부분이 있어 꼭 배포를 해야 하는 상황이었다. 그래서 최소한의 변경으로 빌드 성공 후 바로 배포했는데, 이어서 다른 라이브러리들도 버전 확인 후 업데이트를 진행해야 할 듯하다.

이는 기본적으로 자식 엘리먼트가 부모 엘리먼트 기준 가운데 정렬되어있기 때문에, 브라우저는 부모 엘리먼트 상단으로 튀어나간 자식엘리먼트의 부분은 overflow로 인지하지 않는다. 그래서 아무리 왼쪽으로 스크롤을 해도, 자식 엘리먼트의 끝부분까지 스크롤이 되지 않았다.

이럴 때 safe 키워드를 사용하면 flex-start처럼 가장 처음부터 정상적으로 스크롤이 되도록 할 수 있다.

justify-content: safe center;

그런데 크로스 브라우징을 고려할 필요가 있을 듯하다. https://caniuse.com/?search=flex%20safe

결국, 크로스 브라우징 때문에 margin으로 정렬하도록 변경했다.

참고자료

• Flexbox Align-items center와 overflow scroll이 결합될 때!

flex:1 은 필요에 따라 하는 듯, 없어도 해결이 됨. display: -webkit-box 필수

참고자료

글자 말 줄임 처리(feat. 반응형)

코딩을 잘하려면

• 멋있는 것보다는 알맹이를
  • 꼬리 질문을 통해 학습하고 내 색깔 찾기
• 압도적으로 좋은 것 많이 보기
  • 꾸준하게 내가 몰랏던 양질의 자료 접하기
• 두뇌 풀가동시키기
  • 당연한 내용에 고개를 끄덕이는 것이 아니라 자신없는영역에 도전하기
• 적용하기
  • 지식을 얻는 것에서 멈추지 않고 실제로 행동 계획 세우기

• 나를 어떻게 더 발전시킬 것인가

• 변화에 열려있기

  • 무엇이든 개선할 수 있다, 나에게 맞는 방법으로

• 꾸준함

  • 차이를 만드는 것은 재능보다는 꾸준함
  • 피드백과 칭찬으로 꾸준히 하기
    • 스스로 행동을 피드백, 축하하기
    • 외부 피드백 받기
  • 함께 꾸준히 하기

개수로 보면 적어 보일지 몰라도 두 문의를 합쳐 그날 하루 CS의 30% 이상 차지하고 있었다. 매일매일 빠짐없이 들어온 이 문제를 해결한 방법을 공유하려 한다.🪄

문제 1: 카카오톡 인앱 브라우저

프론트에서 구현하는 이미지 다운로드 기능은 보통 라이브러리를 사용하게 되고 브라우저 정책에 따라 라이브러리가 지원하지 않거나 다르게 동작할 수 있다.

DOM을 이미지로 만들기 X같은 이유와 해결법

이미지 다운로드가 되지 않는다는 문의가 들어오면 고객에게 어떤 앱을 사용했냐고 여쭤봤는데 모두 카카오톡 인앱 브라우저를 통해 해당 기능을 사용한 경우였다.

원래 우리 서비스는 특정 페이지를 제외하고는 카카오톡 인앱 브라우저로 사용자가 유입되는 경우가 없었기 때문에 크로스 브라우징을 크게 고려하지 않았는데, 알림톡으로 안내하는 플로우가 추가되면서 알림톡을 통해 서비스에 접근하면 카카오톡 인앱 브라우저로 사용자가 들어오는 것이었다.

처음엔 팝업을 통해 다른 브라우저 사용을 안내할까 했는데, 사용자 입장에서 다른 브라우저로 다시 접속하는 게 번거롭기도 하고, 다른 기능이 추가되는 경우도 고려했을 때 카카오톡 인앱 브라우저를 지원하지 않는 게 낫겠다고 판단했다.

그래서 url 스킴을 사용해 카카오톡 브라우저로 서비스에 접속할 경우 해당 페이지를 외부 브라우저를 통해 띄우도록 했다. 카카오톡/라인 인앱브라우저에서 외부브라우저 띄우기

처음엔 알림톡 버튼 링크를 수정할까 했는데 그럴 경우 알림톡마다 설정을 해야 했기에 그보다 근본적으로 서비스 내에서 로직이 실행될 수 있도록 할 필요가 있었다.

최종적으로 미들웨어에서 카카오톡 인앱 브라우저를 감지하면 특정 페이지로 리다이렉트하고, 그 페이지에서 url 스킴을 사용해 외부 브라우저로 보내도록 했다.

export async function middleware(req: NextRequest) {
  const token = await getToken({ req, secret: process.env.NEXTAUTH_SECRET });

  const userAgent = req.headers.get('user-agent') || '';
  const isKakaoTalk = userAgent.includes('KAKAOTALK');

  // 카카오톡 브라우저로 접속한 경우 noactive페이지로 리다이렉트
  if (isKakaoTalk) {
    const currentUrl = req.nextUrl.href;
    const url = req.nextUrl.clone();
    url.pathname = '/noactive';
    url.search = '';

    const response = NextResponse.redirect(url);
    response.cookies.set('referer', currentUrl);
    response.cookies.get('referer');
    return response;
  }
 }

next.js의 미들웨어에서 카카오톡 인앱 브라우저를 감지해 noactive 페이지로 리다이렉트를 시킨다. 사용자가 외부 브라우저에서도 원했던 페이지로 바로 접근할 수 있도록 referer를 쿠키에 저장해둔다.

import { ReactElement, useEffect } from 'react';
import { useCookies } from 'react-cookie';

const NoActive = () => {
  const [cookies] = useCookies(['referer']);

  useEffect(() => {
    const referer = cookies['referer'];

    if (referer) {
      const kakaoUrl = `kakaotalk://web/openExternal?url=${encodeURIComponent(
        referer,
      )}`;
      window.location.href = kakaoUrl;
    }
  }, []);

  return <></>;
};

export default NoActive;

noactive 페이지에 접속하면 외부 브라우저로 연결해 준다.

🚨 미들웨어에서 바로 외부 브라우저로 연결하게 되면 문제가 있다. 뒤로 가기를 할 경우 다시 카카오톡 인앱 브라우저로 돌아오는데, 이때 마지막 접속 페이지가 그대로 보인다. 이 때문에 확실하게 사용할 수 없다는 걸 보이기 위해 빈 페이지인 noactive 페이지가 마지막이 될 수 있도록 리다이렉트 후 외부 브라우저를 연결하도록 했다.

문제 2: 모바일 사파리 다운로드 파일 경로

갤럭시의 경우 크롬에서 파일을 저장하면 갤러리에 바로 저장된다. 하지만 아이폰의 경우 다운로드하면 갤러리가 아닌 별도의 경로에 저장된다. 이 때문에 고객이 다운로드한 파일을 못 찾겠다는 문의가 매일 들어왔고, 문의가 들어올 경우 아래 링크를 직접 안내했다.

iPhone 또는 iPad에서 다운로드 항목을 찾을 수 있는 위치

이를 해결하기 위해 토스트 팝업의 내용을 수정했다. 원래 토스트 팝업의 문구는 모든 브라우저에서 동일했는데 분기 처리를 통해 사파리에서는 위 링크로 접속할 수 있도록 링크가 연결된 버튼을 추가했다.

  const showDownloadCompleteToast = () => {
    if (isIPhone) {
      toast({
        description: (
          <div>
            <p>{MESSAGE.DOWNLOAD_COMPLETE_NOTICE}</p>
            <Button asChild variant="outline">
             //다운로드 파일 경로 안내 링크
              <a
                href="https://support.apple.com/ko-kr/102440"
                target="_blank"
              >
                다운로드 된 이미지를 찾을 수 없나요?
              </a>
            </Button>
          </div>
        ),
        variant: 'success',
      });
    } else {
      toast({
        description: MESSAGE.DOWNLOAD_COMPLETE_NOTICE,
        variant: 'success',
      });
    }
  };

관련 문의 0

수정 후 해당 문의들은 더 이상 들어오지 않았다 👏👏👏👏👏👏👏👏

사실 처음에 이미지 다운로드 기능을 구현하면서 이 이슈가 예견되긴 했다. 그래서 검색하다 url 스킴으로 외부 브라우저를 연결할 수 있는 방법을 알게 되었고.

그리고 논의를 했는데 아직 벌어지지 않은 이슈였고 해당 기능을 사용자가 얼마나 많이 이용할지 알 수 없었기에 먼저 배포를 해보자고 결론을 내려 그대로 진행한 것이었다.

기능 사용에 대한 데이터도 수집하고 있었지만, 이슈에 대한 문의를 통해 사용자가 이 기능을 원한다는 것을 확실히 알게 되었다. 또한, 덕분에 상세페이지에도 해당 기능 제공에 대한 내용을 추가할 수 있었다.

문제

html2canvas

기존에 html2canvas 라이브러리를 선택했던 이유는 다음과 같다.

- html-to-image : 서체가 적용되지 않은 채로 이미지로 변환 됨
- dom-to-image : 사파리에서 이미지가 출력 안 됨, 이슈에 동일한 내용 많음, 리드미에 사파리 지원 안 한다고 적혀있음
- dom-to-image-more : dom-to-image와 동일하게 사파리 지원 안 한다고 적혀있음

많이 언급되는 라이브러리들을 검토했을 때 위와 같은 문제가 있었다. html2canvas는 크기가 크다는 단점이 있지만, 이는 문제가 되지 않는다고 느껴졌고 테스트 결과 변환 속도도 빨랐다. 그리고 중요한 건 사파리를 무조건 지원해야 했다.

새로운 디자인에는 클리핑 패스 기능을 사용해 이미지를 하트 모양으로 크롭한 부분이 있는데, 이는 SVG의 clipPath 기능으로 구현했다.

            <div className='photo__box'>
                <svg
                    xmlns="http://www.w3.org/2000/svg"
                    viewBox="0 0 300 318"
                    className="mask-svg"
                  >
                    <defs>
                      <clipPath id="frame">
                        <path
                          fillRule="evenodd"
                          clipRule="evenodd"
                          d="M150 50.599C138.49..."
                        />
                      </clipPath>
                    </defs>
                  </svg>

                  <div className="image-wrapper">
                    <img
                      src={imageUrl}
                      alt="메인사진"
                    />
                  </div>
               </div>

          photo__box {
            clip-path: url(#frame);
            -webkit-clip-path: url(#frame);
           }

문제가 된 부분은 아래의 왼쪽처럼 하트 모양이 있는 부분을 clip-path 방식으로 구현했는데, 이미지로 다운로드하면 적용되지 않은 채로 다운로드되었다.

해결

modern-screenshot

dom-to-image로 테스트해보니 하트 모양은 정상적으로 이미지로 변환되었지만, 크롬에서만 동작했다. 역시나 사파리에서 정상적으로 동작하지 않았으며, 깃허브 이슈를 찾아봐도 해결 방법을 찾지 못했다. 그러던 중 발견한 한 개의 이슈:

Most of the issues have been fixed in forked library modern-screenshot

npm에 검색해보니 생각보다 다운로드 수도 많음... clip-path가 정상적으로 적용되는 것도 확인했다.

modern-screenshot의 문제

이미지로 변환이 잘되어 이 라이브러리를 사용하려 했으나, 이후에도 여러 문제를 해결해야 했다.

사파리에서 발생하는 이슈1

dom-to-image에서는 이미지 리소스를 다운로드하지 못하는 이슈가 있었는데, 이 라이브러리도 동일한 이슈가 있었다.

dom-to-image의 깃허브 이슈에서 두 번 실행하라는 내용이 많았는데, 그땐 동작하지 않았으나 modern-screenshot에서는 두 번 실행하면 정상적으로 작동했다. 그런데 두 번 실행하니까 속도가 느려진다.. 그래서 원래 4가지 이미지를 한 번에 다운받게 했었는데 필요한 사진만 각각 다운받을 수 있도록 수정했다.

?

사파리에서 리소스를 다운로드할 때 시간이 오래 걸리며 생기는 오류라는 것 같은데, 내부적으로 수정할 수 없어 이렇게 해결해야 하는 건가? 싶지만 왜 두 번 실행하면 제대로 동작하는지는 알 수 없었다.

사파리에서 발생하는 이슈2

문제 1을 해결하고 나니 사파리에서 Not allowed to load local resource라는 에러가 발생하며 이미지가 정상적으로 변환되지 않는 이슈가 발생했다.

그런데 어떤 디자인 타입은 정상적으로 동작하고, 어떤 타입은 동작하지 않았다. 오류에 적힌 data URL이 SVG라 동작하지 않는 케이스와 동작하는 케이스를 추려 사용된 SVG의 차이점을 비교했지만, 원인을 알 수 없었다.

결국 동작하지 않는 케이스의 코드를 하나씩 지워본 결과, SVG가 아닌 일반 텍스트 요소를 지우니 다시 동작했는데 알고 보니 Pretendard 서체를 사용하는 디자인 타입만 동작하지 않는 것이었다.

@import url('https://fastly.jsdelivr.net/gh/orioncactus/pretendard@v1.3.9/dist/web/static/pretendard-dynamic-subset.min.css');

@import는 브라우저가 외부 CSS 파일을 가져오도록 요청하는 방식인데, 이 요청이 CORS 정책의 영향을 받습니다. 만약 Pretendard의 호스트(여기서는 fastly.jsdelivr.net)가 올바른 CORS 헤더를 설정하지 않았다면, 브라우저가 해당 리소스를 차단할 수 있습니다. 리소스를 로드하지 못하거나 403(Forbidden) 또는 다른 HTTP 오류가 발생합니다. 출처: GPT

global.css에 프리텐다드 서체가 @import 방식으로 불러오고 있었는데 이 부분이 이미지로 변환 시 브라우저 보안 문제가 발생한 것 같다. 해당 부분을 @font-face 방식으로 수정해 오류를 해결할 수 있었다.

?

GPT가 css 파일을 불러오는 방식으로 되어있어 이미지 변환 시 문제가 발생한 거라고 하는데 CSS 파일을 불러오는 것과 폰트 파일 경로로 불러오는 게 무슨 차이가 있는 걸까..?

모바일 크롬에서 발생하는 이슈

모바일 크롬에서 텍스트가 줄바꿈되어 버리는 문제가 있었는데, 이는 white-space: nowrap;을 사용해 해결할 수 있었다. (나는 줄바꿈이 필요 없었지만 여러 줄의 텍스트인 경우 이 방법으로는 해결할 수 없지 않을까?)

마무리

html2canvas를 사용할 때보다 변환 속도가 느려진 점은 아쉬웠지만, 앞으로 추가될 수 있는 다양한 디자인 타입을 고려했을 때 꼭 해결해야 하는 과제였다.

이 과정에서 이미지를 개별 다운로드하는 방식으로 UI를 수정하며 고객들에게 불편함을 줄 수 있을까 걱정했지만, 오히려 필요한 이미지만 선택적으로 다운로드할 수 있는 기능으로 개선되면서 예상치 못한 긍정적인 결과를 얻을 수 있었다.👍

[react, html] DOM 조작으로 인한 메모리 문제 해결

해결 과정

크롬의 메모리 탭에서는 3가지의 프로파일링 방식을 제공한다. 문의가 3번 들어왔는데 특정 동작을 했을 때 새로고침이 된다는 내용으로 동일했다. 그래서 동작을 재연하면서 타임라인의 할당 계측과 성능 탭을 사용해서 측정했다.

그러다 더 이상 눈에 띄는 게 없어 힙 스냅샷으로 측정을 해봤다. 측정해 봤더니 사용한 적 없는 mui 컴포넌트가 엄청 많은 거다. 세상에😱

• Default import vs Named import

mui는 import를 default 방식으로 해야 필요한 컴포넌트만 가져온다. 우리 프로젝트에 군데군데 named 방식을 사용하는 곳이 있었고 해결을 위해 babel 설정을 했으나 바로 해결되지 않았다.

• babel 설정 방법: mui - Minimizing bundle size

이때부터 추가로 고민을 했다. 현재 프로젝트 상황은

1. 문제가 되는 컴포넌트들은 추후에 디자인 리뉴얼이 계획되어 있다.
2. ui 라이브러리를 교체했고, 새로 구현되는 컴포넌트는 shadcn으로 구현된다.(mui는 점차적으로 없애는 중)
3. 당장의 조치를 취해서 메모리 이슈 문의는 더 이상 발생하지 않고 있다. (근본적 문제 해결을 위해 작업중)

이 상황에서 디자인 작업을 위한 시간을 하루만 더 들이면 많은 부분을 한 번에 해결할 수 있을 것 같다는 판단이 들었다. 그래서 트리쉐이킹 설정을 더 찾기보다 mui를 덜어내는 방향으로 정했다.

해당 컴포넌트들 내부에 있던 모든 mui 코드를 shadcn을 사용하는 것으로 수정하고 불필요한 상태들을 정리했다.

비교

힙 스냅샷을 다시 측정해 보니 메모리를 차지하고 있던 mui 컴포넌트가 없어졌다.

• 수정전
• 수정후 JS 힙의 사용량이 45.1MB -> 7.8MB까지 80% 감소했다.

참고자료

• mui - Minimizing bundle size
• Mui 번들 크기 줄이는 법

오류 발생

사진이 많은 팝업 컴포넌트를 열면 페이지가 새로고침된다는 오류가 접수되었다.

해결 과정

가설 1 사진이 많아서 메모리를 너무 많이 사용한다.

처음에는 오류가 발생한 동작을 타임라인으로 메모리 검사를 진행했다. 그런데 메모리를 많이 차지하는 부분은 대부분 라이브러리 내부에서 발생하고 있었다.

사진의 개수를 줄이면 새로고침 현상이 발생하지 않았다. 그래서 사진과 관련된 부분을 집중적으로 살펴보았으나, 대부분 UI 라이브러리와 Swiper를 사용한 코드였다.

가설 2 이미 메모리가 많이 사용 중인 상태에서 사진이 있는 팝업까지 더해져 한계치에 도달한 것이다.

오류를 캡처한 영상을 검토한 결과, 페이지에서 스크롤을 내린 후 팝업 트리거를 클릭하자마자 새로고침이 발생했다. 이를 통해 메모리를 이미 많이 사용한 상태에서 팝업이 추가되면서 OOM(Out of Memory)이 발생한 것으로 추측했다.

페이지에서 팝업을 열지 않고 가만히 둔 상태로 메모리 검사를 진행해 보니 메모리 그래프가 꾸준히 증가하는 것을 확인했다.

특히 메모리가 급격히 증가하는 부분을 분석해 보니, 디데이를 카운트다운하는 로직에서 문제가 발생하고 있었다.

해당 로직의 일부이다. 1초마다 setInterval로 실행되며, innerHTML을 통해 DOM을 조작하는 방식이었다. 생략된 부분에선 타이머가 useEffect 내부에서 실행되며 클린업 함수도 작성되어 있다.

 const timer = setInterval(() => {
      if (timerElement) {
        const { time, dDay } = showRemaining();
        const timerNumbers = timerElement.querySelectorAll('.timer__number');
        const timerInfoToArray = Object.entries(time);
        const dDayElement = timerElement.querySelector('.d-day');

        if (dDayElement) {
          dDayElement.innerHTML = `${dDay}`;
        }

        Array.from(timerNumbers).forEach((item, index) => {
          item.innerHTML = `${timerInfoToArray[index][1]}`;
        });
      }
    }, 1000);

문제는 여기서 innerHTML을 사용하면서 메모리 할당이 불필요하게 반복되었다는 점이다. 😱

1. 기존 내용 삭제: innerHTML을 사용하면 해당 요소의 모든 기존 자식 노드가 삭제됩니다.
2. 새로운 DOM 트리 생성: 새로운 HTML 문자열을 파싱 하여 해당 요소의 새로운 자식 노드들이 생성되고, DOM 트리에 삽입됩니다.
3. 메모리 재할당: 이 과정에서 기존의 DOM 노드들은 해제되고, 새로운 DOM 노드들이 메모리에 할당됩니다.

단순 텍스트만 수정하고 싶다면 기존의 노드를 새로 만들지 않고, 기존 텍스트 노드를 업데이트하는 방식으로 동작하는 textContent 또는 innerText를 사용하는 것이 더 효율적이라고 한다.(나는 사용하지 않았다.)

Next.js를 사용하기 때문에 DOM을 직접 조작할 필요가 없어 상태로 관리할 수 있도록 로직을 수정했다.

또한, 매초 리렌더링이 발생하는 문제를 해결하기 위해 React.memo()를 사용해 자주 변하지 않는 일, 시간, 분 등의 값이 매번 렌더링 되지 않도록 최적화했다.

비교

• 수정전

• 수정후

JS 힙 메모리 그래프는 아직 개선이 필요하지만, 노드 메모리 사용량이 크게 감소하면서 문제를 많이 해결할 수 있었다.

추가

JS 힙 메모리 최적화는 다음 글에서 해결되었다. mui 번들 크기 줄이기로 시작했으나 없애버리고 메모리 줄이기

참고

• Chrome DevTools로 JS 메모리 누수(Memory Leak) 디버깅하기

디자인

creatie

100% 무료! 4개월 만에 1등 한 AI 디자인 툴은 세계 1위 피그마를 이길 수 있을까?

요즘 아주 핫하다고 해서 써봤다. 영역을 잡으면 해당 영역에 흔히 사용되는 ui를 생성해 주는 느낌이다. 빈 영역에서 시작해서 그런지 내가 필요한 요소에 엄청 적합하다 이런 느낌은 안 들었다. 그걸 하나하나 바꾸면 그냥 와이어 프레임을 고쳐서 디자인하는 거랑 다를 게 없다 싶어서 패스

uizard

uizard는 프롬프트를 작성하면 앱 하나를 만들어주는 느낌으로 페이지별 ui를 촤르륵 작성해 준다. 근데 치명적인 게 너무 안 이쁨 디자인 상관없다! ai가 최대한 많이 만들어줘! 일단 만들고 본다! 이런 상황이면 오히려 더 빠를 수 있겠다 싶었으나, 나는 디자인을 보자마자 다른 서비스를 찾았다.

Galileo AI

이제 AI랑 대화하면서 1분 만에 앱/웹 디자인이 가능하네..

테스트 후 현재 결제해서 사용 중인 서비스이다. 사용법이 미드저니랑 거의 유사해서 아주 쉽다! 그리고 무엇보다 디자인이 정말 깔끔하게 나온다.👍

진짜 디자인 너무 잘 나옴 대박 ai가 만든 디자인에서 색상 바꾸고, 서체 프리텐다드로 바꾸고, mvp 단계에서 구현할 기능만 남겼다.

미드저니처럼 나온 결과물을 다시 수정하고 할 수 있지만 복잡한 부분도 아닌데 원하는 대로 결과는 안 나오고 크레딧만 줄어드는 거 같아서 그냥 피그마에서 직접 수정했다.

간격, 여백, 글자 크기를 수정해야 하면 어렵고 오래 걸리는데, 이 부분이 잘 나와서 개발자의 사이드 프로젝트로 사용하기에 차고 넘친다. 이 서비스 발견해서 너무 행복하다.. 증말...🙇‍♀️

• 다른 예시들도 엄청 깔끔하다.

스타일 가이드

creatie에 ai가 스타일 가이드를 만들어주는 기능이 있다. 피그마 파일을 .fig 확장자로 내보내면 creatie에 바로 임포트 할 수 있다.(반대는 안됨🥲) 가져와서 기능을 사용해 봤다.

이것도 어마어마함...

하지만 스타일 가이드는 디자이너가 디자인을 할 때 사용해 줘야 의미가 있는 건데 Gailieo에서 디자인을 하니까 과연 사용 가능할까 싶다. 컬러는 내가 수정할 때 사용하면 될 것 같기도🧐

마무리

Gailieo AI를 활용해 서비스를 사용해보니, 굳이 와이어프레임을 만들어야 했나 싶다. 와이어프레임이 있어서 이미지를 프롬프트에 사용하긴 했지만, 갈릴레오에 텍스트로 프롬프트를 작성하는 것과 비교해 볼 때, Wireframe Designer를 쓴다는 게 큰 차이가 있는지 의문이 들었다.

지금까지 AI가 제시한 단계를 따라 기획부터 디자인까지 진행해 봤다. 이렇게 AI로 기획하고 노코드 툴로 서비스를 만든다면, 정말 간단한 앱은 찍어낼 수 있지 않을까 하는 생각이 든다.😱 (아직 사용해 보진 않았지만, 그냥 떠올려본 생각이다.)

AI가 주는 가치는 그야말로 생산성의 혁명인 것 같다.

숏폼 중독을 끊자(정신차려!) 개발 with ai 동료 - 서비스 기획 숏폼 중독을 끊자(정신차려!) 개발 with ai 동료 - 화면 기획, 유저스토리

• 배경으로 깔려있는 이미지의 위치를 드래그해서 이동할 수 있어야 한다.

구현

두 요소가 겹쳐져 있어 배경 이미지는 클릭 이벤트가 발생할 수 없다. 하지만 이미지 위치를 조정하기 위해선 이미지에 드래그 이벤트를 발생시켜야 한다.

최상위 컨테이너 요소에 마우스 클릭 이벤트가 발생하면 배경 이미지에 드래그 이벤트를 발생시키면 될 것 같았다.

찾아보니 자바스크립트는 커스텀 이벤트를 생성하고 수동으로 이벤트를 발생시킬 수 있다. 🧐

커스텀 이벤트 생성

드래그 이벤트를 생성해 준다. 이때 이벤트 객체도 직접 넣어줘야 한다. 이미지 위치를 옮기기 위해서 필요한 값들을 마우스(터치) 이벤트 객체에서 뽑아내서 전달했다.

• DragEvent: DragEvent() constructor

  const createCustomDragEvent = (
    event: MouseEvent | DragEvent | TouchEvent,
    eventType: 'dragstart' | 'dragover' | 'drop',
    dataTransfer: DataTransfer,
  ) => {
    let clientY;
    let clientX;

    if (event instanceof MouseEvent) {
      // 마우스 이벤트인 경우
      clientY = event.clientY;
      clientX = event.clientX;
    } else {
      // 터치 이벤트인 경우
      const touch = event.touches[0] || event.changedTouches[0];
      clientY = touch?.clientY;
      clientX = touch?.clientX;
    }

    return new DragEvent(eventType, {
      bubbles: true,
      cancelable: true,
      clientY,
      clientX,
      dataTransfer,
    });
  };

수동으로 이벤트 발생시키기

• EventTarget.dispatchEvent()

    const dataTransfer = new DataTransfer();

    dropzone.addEventListener('mousedown', (e) => {
      const dragStartEvent = createCustomDragEvent(
        e,
        'dragstart',
        dataTransfer,
      );
      draggableImage.dispatchEvent(dragStartEvent);
    });

    draggableImage.addEventListener('dragstart', handleDragStart);

컨테이너 요소(=dropzone)에 mousedown 이벤트가 발생하면 draggableImage 요소에 dragStart 이벤트가 발생한다.

이미지를 이동하기 위해 dragstart, dragover, drop 이렇게 세 가지 이벤트를 사용해야 해서 동일한 방법으로 커스텀 이벤트를 수동으로 발생시켰다.

    // PC를 위한 마우스 이벤트
    dropZone.addEventListener('mousedown', (e) => {
      const dragStartEvent = createCustomDragEvent(
        e,
        'dragstart',
        dataTransfer,
      );
      draggableImage.dispatchEvent(dragStartEvent);
    });

    document.addEventListener('mousemove', (e) => {
      const dragOverEvent = createCustomDragEvent(e, 'dragover', dataTransfer);
      dropZone.dispatchEvent(dragOverEvent);
    });

    document.addEventListener('mouseup', (e) => {
      const dropEvent = createCustomDragEvent(e, 'drop', dataTransfer);
      dropZone.dispatchEvent(dropEvent);
    });

    // 모바일을 위한 터치 이벤트
    dropZone.addEventListener(
      'touchstart',
      (e) => {
        if (e.target === dropZone || dropZone.contains(e.target as Node)) {
          e.preventDefault();
        }

        const dragStartEvent = createCustomDragEvent(
          e,
          'dragstart',
          dataTransfer,
        );
        draggableImage.dispatchEvent(dragStartEvent);
      },
      { passive: false },
    );

    document.addEventListener(
      'touchmove',
      (e) => {
        if (e.target === dropZone || dropZone.contains(e.target as Node)) {
          e.preventDefault();
        }

        const dragOverEvent = createCustomDragEvent(
          e,
          'dragover',
          dataTransfer,
        );
        dropZone.dispatchEvent(dragOverEvent);
      },
      { passive: false },
    );

    document.addEventListener('touchend', (e) => {
      const dropEvent = createCustomDragEvent(e, 'drop', dataTransfer);
      dropZone.dispatchEvent(dropEvent);
    });

    //이미지 위치를 이동하는 드래그 이벤트
    draggableImage.addEventListener('dragstart', handleDragStart);
    dropZone.addEventListener('dragover', handleDragOver);
    dropZone.addEventListener('drop', handleDrop);

카카오맵을 사용하는 부분에서 메모리가 터지는 에러를 발견했다.

기존 코드를 살펴보니 useEffect 내부에 카카오맵 객체를 생성하는 코드가 모두 함께 있었다.

그리고 의존성 배열에 값을 추가해 사용자 입력값이 바뀌면 useEffect가 재실행 되면서 매번 객체가 생성되도록 작성되어 있었다. 언마운트 할 때 참조 해제도 되어있지 않았다.

  useEffect(() => {
    const kakao = (window as any).kakao;

    if (!kakao) return;

    kakao.maps.load(function () {
      // 주소-좌표 변환 객체 생성
      const geocoder = new kakao.maps.services.Geocoder();

      const mapContainer = document.getElementById(''),

      // 지도 생성
      const map = new kakao.maps.Map(mapContainer!, mapOption);

      const renderMap = () => {
        //좌표 생성
        const coords = new kakao.maps.LatLng(latitude, longitude);

        // 표시할 마크 생성
        const marker = new kakao.maps.Marker({});

        // 장소 인포 생성
        const infowindow = new kakao.maps.InfoWindow({});
        infowindow.open(map, marker);
        };
    });
  }, [a, b, c]);

입력이 바뀔 때마다 무한 생성 중...

수정 1

지도 객체를 여러 번 생성할 필요가 없었기 때문에 useRef로 객체를 저장하고 의존성 배열을 비워 한 번만 생성되도록 코드를 수정했다.

  const infoWindow = useRef<kakao.maps.InfoWindow | null>(null);
  const marker = useRef<kakao.maps.Marker | null>(null);
  const map = useRef<kakao.maps.Map | null>(null);
  const coords = useRef<kakao.maps.LatLng | null>(null);
  const zoomControl = useRef<kakao.maps.ZoomControl | null>(null);
  const mapContainer = useRef<HTMLDivElement>(null);

 useEffect(() => {
    if (!window.kakao) return;

    window.kakao.maps.load(() => {
      const MapContainer = mapContainer.current;

      coords.current = new kakao.maps.LatLng();
      marker.current = new window.kakao.maps.Marker();
      infoWindow.current = new window.kakao.maps.InfoWindow();
      map.current = new window.kakao.maps.Map();
      zoomControl.current = new kakao.maps.ZoomControl();
    });

    return () => {
      marker.current?.setMap(null);
      infoWindow.current?.close();
      marker.current = null;
      map.current = null;
      infoWindow.current = null;
    };
  }, []);

수정 2

메모리 누수가 발생하던 코드는 입력값이 바뀌면 카카오맵과 관련된 모든 객체를 새로 생성하도록 되어있었다. 카카오맵에서 제공되는 api로 객체를 새롭게 생성할 필요 없이 값을 변경할 수 있다.

그래서 api들을 사용하고 각각의 입력값 별로 useEffect를 분리해 동작할 수 있게 수정했다.

  useEffect(() => {
    if (name && map.current && infoWindow.current) {
      infoWindow.current?.setContent(infoWindowTemplate(name));
    }
  }, [name]);

  useEffect(() => {
    if (level && map.current) {
      map.current?.setLevel(level);
    }
  }, [level]);

  useEffect(() => {
    if (coordinates && map.current && marker.current && infoWindow.current) {
      const moveLatLon = new kakao.maps.LatLng(
        coordinates.latitude,
        coordinates.longitude,
      );
      map.current?.setCenter(moveLatLon);
      marker.current?.setPosition(moveLatLon);
      infoWindow.current?.open(map.current, marker.current);
    }
  }, [coordinates]);

개발을 해야 하는데 기획이 없으면 뭘 만들어야 할지 모르겠고, 디자인을 해야 하는데 뭐부터 시작할지 정리가 안돼서 와이어프레임을 그려봤고, 팀원들끼리 핀트가 안 맞다 싶으면 유저스토리를 작성했다. 그러다 보니 알음알음 찾아보고 간단하게 작성해 본 정도였다.

거의 그런 식이었다. 그래서 이번 프로젝트를 할 때 ai를 사용해 보고 싶었다. 결국은 필요한 저 과정들을 ai가 도와주면 빨리할 수 있을 것 같았다. (특히 ui 생각할 땐 너무 힘들다. 안 써본 종류의 서비스라면 더더욱 🥲)

1. 사이트맵

화면 기획 구성
- 홈 화면 (Dashboard)
- 사용 시간 상세 화면 (Usage Details)
- 목표 설정 화면 (Goal Setting)
- 알림 관리 화면 (Notification Management)
- 리포트 및 분석 화면 (Report & Analytics)
- 설정 화면 (Settings)

기획안을 토대로 gpt가 구성해 준 페이지들은 위와 같았는데 결과적으로 총 4페이지로 정했다.

홈 화면 (Dashboard)
- 오늘의 총 사용 시간
- 앱별 사용 시간 리스트
- 중독 경고 알림
- 이동: 통계 화면, 목표 설정 화면, 설정 화면

통계 화면 (Statistics)
- 기간 선택 필터 (일간, 주간, 월간)
- 사용 시간 그래프 (막대 그래프 또는 원형 그래프)
- 앱별 사용 시간 리스트
- 이동: 홈 화면, 목표 설정 화면, 설정 화면

목표 설정 화면 (Goal Setting)
- 일일/주간 목표 시간 설정 (슬라이더)
- 목표 설정 상태 (시각적 표시)
- 알림 옵션 (토글 버튼)
- 이동: 홈 화면, 통계 화면, 설정 화면

설정 화면 (Settings)
- 테마 설정 (다크 모드, 라이트 모드)
- 데이터 동기화 옵션 (주기 설정)
- 앱 정보 및 도움말
- 이동: 홈 화면, 통계 화면, 목표 설정 화면

2. 와이어프레임

🔥 AI를 활용해 만드는 와이어프레임은 어떤 모습일까?

• 사이트맵, 유저 플로우, 와이어프레임을 한 번에 만들 수 있는, Flowmapp
• 서비스 소개를 입력하면 와이어프레임을 만들어주는, Wireframe Designer

원래 시작부터 와이어프레임을 그리려다 Flowmapp 서비스를 사용하고자 사이트맵을 작성한 거였다. 그런데 사용법을 잘 몰라서 Wireframe Designer로 계획 변경 🤯

플러그인이 만들어준 와이어프레임

그래도 작성한 사이트맵이 요긴하게 쓰였다. 디자인하기 전에 와이어프레임이 정리를 위해 필요한 것처럼 사이트맵은 와이어프레임 전에 생각 정리를 위해 필요한가 보다.

수정된 와이어프레임

많이 수정된 듯하지만 ai가 만들어준 와이어프레임 덕분에 훨씬 빨리 수정할 수 있었다. 심지어 오토 레이아웃까지 다 적용돼 있기 때문에 수정할 때 정말 편하다. 컴포넌트들도 깔끔해서 뭔가... 이대로 만들어도 안 되나? 하는 생각도 했다. (직접 만든 요소도 있다.)

3. 유저스토리

와이어프레임을 작성하고 깨달았다. 유저플로우랑 유저스토리 작성 안 했다는걸...🫣 디자인할 때 에러 케이스 처리할 수 있게 만들어둬야지! 하고 언제 에러 케이스 넣을지 보려 했더니 유저스토리가 없네...ㅎㅎ 그래서 와이어프레임 수정하면서 자꾸 이 기능 필요한가 아닌가 고민했나 보다.

gpt가 작성해 준 유저스토리에 와이어프레임을 보면서 내용을 추가했다. 최소 기능만 남겼다고 생각했는데 와이어프레임을 작성해 보니 통계 기능은 당장 필요한 것 같다는 생각이 들지 않아서 우선순위를 뒤로 미뤘다.

마무리

유저플로우는 앱이 복잡하지 않아서 그런지 유저스토리를 적고 나니 크게 필요하단 생각이 들지 않아 작성하지 않았다.

정답은 없겠지만 보통 유저스토리나 유저플로우를 작성하고 화면 기획에 들어가는 경우가 많다고 하던데,

나는 유저스토리가 필요한 목적이 기획보다 구현할 기능 목록이라 그런지 화면을 보면서 유저스토리를 적게 되는 것 같다. 화면 보면서 할 일 정리하는 느낌?

이젠 ai와 함께하는 디자인 차례!🤩

숏폼 중독을 끊자(정신차려!) 개발 with ai 동료 - 서비스 기획 숏폼 중독을 끊자(정신차려!) 개발 with ai 동료 - 디자인

이 앱의 시작은 지극히 나의 개인적인 경험에서 시작되었다.

1. 숏폼에 빠져 누워있었다.
2. 전화가 왔다.
3. 전화를 마쳤다.
4. 할 일을 하러 갔다.

이런 경험이 몇 번 있었다. 숏폼에 빠져있다 언젠가 잘못 맞춰둔 알람이 울려서 정신을 차리고, 어떤 앱의 푸시 알림이 떠서 정신 차리게 되는 경험이

그래서 숏폼에 빠져있을 때 정신을 차릴 수 있는 계기를 만들자! 해서 시작되었다. 그리하여 이름이 정신 차려....

빠른 기획을 위해 gpt와 함께 합니다.

---------------gpt가 알려준 기획 과정---------------

1. 문제 정의
2. 타겟 사용자 정의
3. 핵심 기능 선정
4. 경쟁 서비스 분석
5. 기술 스택 선정
6. 와이어프레임 & 프로토타입 제작
7. MVP(최소 기능 제품) 설정
8. 비즈니스 모델 구상

1.문제 정의

사용자 불편 및 니즈 발견

(GPT) 사용자들은 숏폼 콘텐츠를 시청할 때, 자신이 생각했던 것보다 더 오랜 시간을 소비하고 있으며, 이로 인해 일상적인 일정에 차질이 생기거나 생산성이 떨어지는 문제를 겪고 있다.

(나) 특히 퇴근하고 나서 에너지 소모가 커 자기 통제력이 떨어진 시간대에 중독에서 빠져나오기 힘들다. 잠을 늦게 자서 다음날 일상에 영향을 미치기도 함

• 숏폼 서비스 중 시간제한 설정 기능이 있다. 틱톡, 유튜브
• 숏폼 서비스 중 시간제한 설정 기능이 없다. 인스타그램, 네이버 (다만, 운영체제에서 제공하는 사용 시간제한 기능이 있음.)

1. 각 앱마다 따로 설정을 해야 하는 것이 불편하다. 한 곳에서 통합 관리했으면 함.
2. 네이버 앱은 브라우저로 사용하기 때문에 시간제한 설정을 걸 수 없음

해결하고자 하는 목표

(GPT) 사용자가 스스로 숏폼 콘텐츠 중독에서 빠져나올 수 있도록 하는 계기 제공. 강제적이거나 일방적인 제한보다는 사용자가 스스로 선택하게끔 돕는 도구나 경험 제공.

(나) 서비스를 사용하지 못하게 하기에는 유튜브가 단순 흥미 위주의 콘텐츠뿐만 아니라 지식을 얻는 창고로 사용되는 경우도 많으며, 네이버의 경우 브라우저로 사용하고 있기에 앱 사용을 막을 순 없음. 보통 콘텐츠를 보면서 즐거우나 한 편으로는 할 일을 미루고 있다는 죄책감이 들 때가 있음 이 죄책감을 시각화해 충격을 줘 숏폼 시청을 중단하는 것이 목표.

2. 타겟 사용자 정의

주 타겟 사용자 그룹:

숏폼 콘텐츠 소비가 많은 젊은 층

• 연령대: 16~30세
• 직업: 학생, 대학생, 직장 초년생
• 디지털 기기 사용 패턴: 스마트폰을 자주 사용하며, 주로 짧은 시간에 - 여러 콘텐츠를 빠르게 소비함.
• 특징: 숏폼 콘텐츠의 즉각적인 자극(도파민 분비)으로 인해 쉽게 중독되고, 시간 관리에 어려움을 겪음.
• 니즈: 효과적인 시간 관리, 생산성 향상, 중독에서 벗어나기 위한 지원.

디지털 웰빙에 관심이 있는 사람들

• 연령대: 25~40세
• 직업: 직장인, 프리랜서
• 디지털 기기 사용 패턴: 하루 대부분을 컴퓨터와 스마트폰을 사용하는 직업군으로, 주기적인 휴식이나 디지털 디톡스를 원함.
• 특징: 기술에 친숙하며, 자신의 스마트폰 사용 패턴에 대해 의식하고 있음. 숏폼 콘텐츠를 시간 가는 줄 모르고 소비하는 습관에서 벗어나고 싶어함.
• 니즈: 생산성 향상, 더 나은 시간 관리, 집중력 유지.

페르소나 예시

김민준 (20세, 대학생)

• 배경: 대학에 다니는 김민준은 틈날 때마다 인스타그램과 틱톡에서 숏폼 영상을 본다. 시간 가는 줄 모르고 보고 있다 보면 중요한 과제를 미루거나 수면 시간이 줄어드는 경우가 많다.
• 목표: 숏폼 콘텐츠 중독에서 벗어나 시간을 효율적으로 사용하고 싶지만, 스스로 조절이 어렵다고 느낀다.
• 니즈: 일정 시간이 지나면 중독되기 전에 알려주거나, 자극적인 영상에서 잠시 벗어나 집중할 수 있도록 돕는 기능.

이서영 (32세, 마케터)

• 배경: 마케팅 업무를 하는 이서영은 일과 중에도 자주 인스타그램 릴스를 보곤 한다. 업무에 집중해야 할 시간이 많지만, 짧은 휴식이 길어지는 경우가 많아 생산성이 떨어진다고 느낀다.
• 목표: 자신의 숏폼 콘텐츠 시청 시간을 더 잘 관리하고, 효율적인 휴식 시간을 가질 수 있는 방법을 원한다.
• 니즈: 숏폼 영상을 일정 시간 동안 시청한 후 스스로 멈출 수 있는 경고나, 콘텐츠 소비 시간을 관리할 수 있는 도구.

3. 핵심 기능 선정

1. 사용 시간 모니터링 및 시각화

• 기능 설명: 사용자가 숏폼 콘텐츠를 시청하는 시간을 실시간으로 모니터링하고, 시각적으로 보여주는 기능.

• 기능 특징: 사용자는 자신이 콘텐츠를 몇 시간 동안 소비했는지 확인 가능.

• 사용자에게 주는 가치: 사용자가 자신이 얼마나 많은 시간을 숏폼 콘텐츠에 투자했는지 인지하게 함으로써 중독성을 자각하게 도와줌.

• 기술 구현 예시: 앱 내 대시보드를 통해 실시간 사용 시간을 그래프나 차트로 시각화하여 제공.

2. 일정 시간 경과 후 푸시 알림

• 기능 설명: 사용자가 일정 시간 동안 숏폼 콘텐츠를 소비했을 때 알림을 통해 휴식 또는 콘텐츠 소비 중단을 유도.

• 기능 특징: 사용자가 스스로 시간을 설정하거나, 기본적으로 30분 또는 1시간 단위로 알림을 설정 가능. 푸시 알림 클릭 시 즉시 앱 종료 옵션, 잠시 휴식 모드로 전환 옵션, n 분 후 알림 옵션 제공

• 사용자에게 주는 가치: 사용자가 시간을 잊고 콘텐츠에 몰입했을 때, 휴식을 취하거나 사용 습관을 개선할 수 있는 계기 제공.

• 기술 구현 예시: Firebase Cloud Messaging 또는 Apple Push Notification을 통해 알림 제공.

기능 세부 정의

사용 시간 모니터링 및 시각화 기능 동작 정의

1. 사용 시간 모니터링 앱 사용 시간 추적

   • 앱 포그라운드 및 백그라운드 감지: 앱이 포그라운드로 전환될 때부터 사용 시간을 추적하기 시작합니다. 앱이 백그라운드로 전환되면 사용 시간을 중지하고, 경과된 시간을 기록합니다.

   • 사용 시간 기록: 사용 시간이 기록될 때마다 경과된 시간을 누적하여 저장합니다.

2. 알림 트리거

   • 특정 조건(예: 연속 사용 30분 경과, 하루 목표 시간 초과 등)을 감지하여 사용자에게 알림을 보냅니다.

3. 데이터 시각화 시각적 요소

   • 앱 별 사용 시간: 가장 많이 사용된 앱의 순위와 사용 시간을 표시합니다.

   • 홈 화면: 오늘의 총 사용 시간과 가장 많이 사용한 앱을 시각화하여 보여줍니다.

   • 상세 화면: 사용자가 특정 기간(일간, 주간)을 선택하면 해당 기간의 사용 시간 데이터를 차트로 표시합니다.

4. 사용자 인터랙션

   • 사용자가 직접 목표 시간을 설정하거나 변경할 수 있도록 UI를 제공합니다.

푸시 알림 기능 동작 정의

1. 시간 경과에 따른 중독 경고 알림

   • 일정 시간이 지나면 알림을 통해 사용자가 오랫동안 숏폼 콘텐츠에 몰입되어 있다는 사실을 알려줌.

   • 알림은 단순 경고가 아닌, 사용자의 행동을 변화시킬 수 있는 유도형 메시지로 설계.

2. 알림 타이밍 설정 사용자 맞춤형으로 알림을 보낼 수 있도록 설계

   • 일정 시간 동안 연속으로 숏폼 콘텐츠를 시청할 때 (예: 30분, 1시간 등)

   • 사용자가 설정한 목표 시간(예: 하루 1시간)을 초과했을 때

ex)

• "30분 동안 숏폼 영상을 시청 중입니다. 오늘 할 일이 있었지 않나요? 👀"
• "1시간이 지나가고 있어요! 정신 차리세요! ⛔📵 "
• "벌써 n 번째 알림을 무시했어요! 이제부터 5분마다 알려드릴게요! ⏰"

3. 푸시 알림 디자인

   • 시각적 요소를 포함하여 사용자에게 즉각적인 경각심을 줄 수 있도록 이미지, 텍스트와 더불어 아이콘, 이모티콘을 사용해 감정적으로도 자극

4. 푸시 알림의 동작

   • 숏폼 서비스에 접속하면 설정한 시간을 알려주는 알림을 보낸다.

   • 사용자가 설정한 사용 기간이 지나면 알림을 보내기 시작한다.

   • 3번까진 다시 알림을 위한 선택권을 준다.

     ex) 30분 후, 10분 후

   • 3번이 지나면 다음 주기를 줄여 알림 빈도를 높인다.

     ex) 10분 -> 5분 -> 1분

5. 기술 스택 선정

필수조건

• javascript 사용
• react 생태계와 호환이 많이 될수록 좋음

내가 만들고 싶어서 만드는 프로젝트지만 업무 외적으로 이것저것 적용해 보며 공부하려는 이유가 있기 때문에 필수조건이 있었다. Flutter가 쉽다고 들었지만 앱이라면 React Native여야 한다!

• 백엔드: Supabase (관계형 데이터베이스 접해보고 싶음)
• 프론트엔드: React Native
• 상태 관리: 미정
• 데이터 페칭 및 동기화: React Query(공부하고 싶어서)
• 개발 환경 및 배포: Expo (RN치면 Expo 밖에 안 나옴...정보 많은 걸 선택)
• ui 라이브러리: 미정 (사용한다면 Gluestack?)

마무리

몇 단계가 빠졌는데 내 목적에선 크게 중요한 기획 영역이 아닌 것 같아서 간단하게 넘어갔다.

4. 경쟁 서비스 분석

• 찾아본 바로는 어플을 못쓰게 하는 건 많은데 이렇게... 강력하게 정신차리라는 문구로 알림을 보내는 어플은 없는 것 같다. 세션으로 사용 시간을 알려주는 앱은 있었다.
• 사용해 보고 싶은 기술을 써보자 + 내 입맛에 맞는 어플을 만들자 하는 목적이 크다 보니 경쟁 서비스 분석보단 어떻게 만들어야 할지 찾아봤다.

• 6. 와이어프레임 & 프로토타입 제작*
• ai 디자인 서비스 사용해 보고 싶다. 다음 디자인 편에서 이야기할 예정

• 7. MVP(최소 기능 제품) 설정*
• 이미 최소 기능만 남겨둔 상태라고 생각한다. (GPT가 더 많은 기능을 알려줬었다.)

• 8. 비즈니스 모델 구상*
• 당장은 학습용 개인 프로젝트의 목적이 커 스토어에 올릴 계획이 없다.

GPT가 제시해 준 내용을 정리해서 적었지만 내용을 다 적다 보니 엄청 길어졌다.👻

혼자 프로젝트하면서 이렇게 페르소나까지 생각해 본 건 처음인 것 같다. 스토어에 올리지 않을 프로젝트 이렇게까지 기획해서 뭐하나 싶기도 했지만, 왜 이 앱을 만들고 싶었는지 뭘 만들고 싶은지 생각을 정리하는 데 도움이 되었다.

다음은 ai와 함께 디자인을 시도해볼 예정!

숏폼 중독을 끊자(정신차려!) 개발 with ai 동료 - 화면 기획, 유저스토리 숏폼 중독을 끊자(정신차려!) 개발 with ai 동료 - 디자인

카카오톡에 공유할 때는 잘 된다. 근데 인스타그램에서 공유하면 주소만 띡 하고 보내짐...

• 카카오톡 링크 공유 (카카오로 공유하기 X, 링크 복붙)

• 인스타그램 링크 공유

그래서 페이스북 공유디버거를 확인해봤더니 og:image는 인식을 못하고 있었다. description도 지정되있는데 못가져오는듯 하고.. 아래 사진의 빨간 박스 쳐둔 부분을 보면 이유를 알려주는데 크롤링 하는 봇을 우리 사이트에서 허용을 안해둬서 생긴 문제인 것 같았다.

해결

robots.txt에 페이스북 크롤링 봇을 허용해 주는 설정을 추가했다.

User-agent: facebookexternalhit
Allow: /

User-agent: Facebot
Allow: /

이제 잘 나온다(만족)

https://stackoverflow.com/questions/72315270/nextjs-getstaticprops-not-working-in-my-component

두둥

처음에 middleware를 내가 설정한 게 아니라 생각을 못 하고 next.js 관련된 이슈를 찾으려 했는데 나와 똑같은 문제를 올려둔 next-auth의 깃허브 이슈를 발견했다.

• 307 Status Code(Temporary Redirect) on Logo in singin Page

웃긴 게 제목이 내 상황과 100%로 일치ㅋㅋㅋㅋㅋㅋ 나도 헤더 컴포넌트를 수정하는데 로고 이미지가 로그인이 된 상태에서는 잘 나오는데 로그아웃만 하면 이미지가 나오지 않았고 확인해 보니 응답이 307이 뜨고 있었다.

깃허브 이슈에서는 이미지 파일을 추가하라는데 나는 public 디렉토리를 추가해 줬다.

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - public
     * 미들웨어를 거치지 않는 경로들
     */
    '/((?!public|$).*)',
  ],
};

고려해야 할 시나리오는 다음과 같다. **

1. 브라우저 닫기: 사용자가 브라우저를 닫으려 할 때.
2. 페이지 새로고침: 사용자가 페이지를 새로고침할 때.
3. 페이지 이동: 사용자가 다른 페이지로 이동할 때 (예: 뒤로 가기, 앞으로 가기, URL 직접 입력 등).

**

beforeunload로 페이지 이탈 방지하기

먼저 beforeunload 이벤트를 사용하면 1번과 2번을 시나리오를 막을 수 있다. 이 이벤트는 사용자가 페이지를 떠나려고 할 때 브라우저가 경고 메시지를 표시하도록 한다.

  useEffect(() => {
    const handleBeforeunload = (e: {
      preventDefault: () => void;
      returnValue: string;
    }) => {
      e.preventDefault();
      e.returnValue = '';
    };

   window.addEventListener('beforeunload', handleBeforeunload);

    return () => {
      window.removeEventListener('beforeunload', handleBeforeunload);
    };
  }, []);

여기까지 막으면 다 막혔다고 생각했지만 SPA에서는 끝이 아니다!

SPA에서 페이지 이탈 방지하기

우리 프로젝트의 폼 입력 페이지에는 제작 내역 페이지로 이동하는 next.js의 Link를 사용한 버튼이 있다. 위의 beforeunload로 기능을 구현하고 페이지 이동을 했더니 이벤트가 동작하지 않는다!

SPA를 풀어쓰면 단일 페이지 앱! 당연히 페이지 이동이 없다. 그래서 이벤트가 발생이 안된다. Next.js에서 제공하는 router의 이벤트를 사용해서 페이지 이동을 감지할 수 있다.

  useEffect(() => {
    const handleBlockPopState = ({ url }: { url: string }) => {
      if (router.asPath !== url) {
        window.history.pushState(null, '', router.asPath);
      }
      return true;
    };

    const handleBeforeHistoryChange = () => {
      if (
        window.confirm(
          '변경사항이 저장되지 않을 수 있습니다. 사이트에서 나가시겠습니까?',
        )
      ) {
        router.events.emit('routeChangeComplete');
      } else {
        router.events.emit('routeChangeError');
      }
    };

    const handleRouteChangeError = () => {
      throw 'Route change aborted.';
    };

      router.events.on('beforeHistoryChange', handleBeforeHistoryChange);
      router.events.on('routeChangeError', handleRouteChangeError);
      router.beforePopState(handleBlockPopState);

    return () => {
      router.events.off('beforeHistoryChange', handleBeforeHistoryChange);
      router.events.off('routeChangeError', handleRouteChangeError);
      router.beforePopState(() => true);
    };
  }, []);

handleBeforeHistoryChange

Next.js 공식문서 router.events

beforeHistoryChange(url, { shallow }) - Fires before changing the browser's history(브라우저 히스토리가 변경되기 전에 발동)

beforeHistoryChange 이벤트 발생 시에 컨펌창을 띄우고, 컨펌 창의 값에 따라 뒤로 가기를 마저 완료하거나 에러를 일으키도록 한다.

handleBlockPopState

뒤로 가기를 하고 팝업을 띄우면 beforeHistoryChange에 잡히기 전 Url이 바뀌어버려서 취소를 눌러도 뒤로 가기 한 후의 주소가 나타난다. 이를 방지하기 위한 함수이다.

• localhost:3000로 페이지는 그대로인데 url이 바뀌어 버림

• localhost:3000/editor 현재 페이지의 url을 유지

handleRouteChangeError

팝업에서 취소를 눌렀을 때 에러를 던져 페이지 이동을 막기 위한 함수이다. 이 함수가 없다면 취소를 눌러도 뒤로 가기가 동작해버린다.

폼 입력에 변경사항이 있을 때만 뒤로 가기 방지 기능이 동작하도록 하기

입력한 게 없다면 폼을 이탈해도 무방하다. 이를 위해 커스텀 훅에서 외부로부터 불리언 값을 받아, 해당 값에 따라 이벤트를 발생시킬지 여부를 결정하도록 추가로 구현한다. 이 불리언 값은 입력값이 변경되었는지를 나타낸다.

const usePreventFormExit = (isEnabled = true) => {
  const router = useRouter();

  useEffect(() => {
    const handleBeforeunload = (e: {
      preventDefault: () => void;
      returnValue: string;
    }) => {
      e.preventDefault();
      e.returnValue = '';
    };

    const handleBlockPopState = ({ url }: { url: string }) => {
      if (router.asPath !== url) {
        window.history.pushState(null, '', router.asPath);
      }
      return true;
    };

    const handleBeforeHistoryChange = () => {
      if (
        window.confirm(
          '변경사항이 저장되지 않을 수 있습니다. 사이트에서 나가시겠습니까?',
        )
      ) {
        router.events.emit('routeChangeComplete');
      } else {
        router.events.emit('routeChangeError');
      }
    };

    const handleRouteChangeError = () => {
      throw 'Route change aborted.';
    };

    if (isEnabled) {
      window.addEventListener('beforeunload', handleBeforeunload);
      router.events.on('beforeHistoryChange', handleBeforeHistoryChange);
      router.events.on('routeChangeError', handleRouteChangeError);
      router.beforePopState(handleBlockPopState);
    } else {
      window.removeEventListener('beforeunload', handleBeforeunload);
      router.events.off('beforeHistoryChange', handleBeforeHistoryChange);
      router.events.off('routeChangeError', handleRouteChangeError);
      console.log(window.history);
      console.log(router.asPath);
      router.beforePopState(() => true);
    }

    return () => {
      window.removeEventListener('beforeunload', handleBeforeunload);
      router.events.off('beforeHistoryChange', handleBeforeHistoryChange);
      router.events.off('routeChangeError', handleRouteChangeError);
      router.beforePopState(() => true);
    };
  }, [isEnabled]);
};

현재 프로젝트에서는 react-hook-form을 사용하고 있어 isDirty값을 사용해 판단한다. formState에 다른 상태들도 있어 고려해 봤는데 isDirty로 충분하다 판단했다.

const isEnabled =
    methods.formState.isDirty && !methods.formState.isSubmitting;

usePreventFormExit(isEnabled);

마무리

처음에 beforeunload만 달면 끝난다!라고 단순히 생각했으나 왜 안돼? 가 계속 발생한 폼 이탈 방지...잡을 수 있는 부분은 최대한 잡아서 구현했는데 빠진 게 있다면 알려주시면 감사드립니다..🙇‍♀️

참고자료

• 페이지 이탈시 확인 컨펌창 만들기
• How to add the "Changes you made may not be saved" warning to a Next.js app with React Hook Form
• Next router 이동 막기 _알림창
• React Hook Form의 isDirty와 dirtyFields를 알아보자

UI 구현을 하다 보면 컴포넌트에 여백(margin)을 어떻게 적용해야 할지 고민이 될 때가 많았다. 특히 재사용 할 컴포넌트라면 사용하는 위치에 따라 여백이 달라져 수정을 하게되는 경험이 많아서 CSS를 작성할 때마다 고민이 되는 부분이었다.

예를 들어 A 페이지에서는 20px의 여백이 필요하지만, B 페이지에서는 10px 필요한 경우이다.

처음에는 컴포넌트에 직접적으로 여백을 적용한 뒤, 다른 페이지에서 재사용할 경우 해당 페이지의 다른 컴포넌트로 여백을 옮기곤 했다.

이 방식의 문제는 여백을 옮긴 컴포넌트 1, 컴포넌트 4도 어딘가에서 재사용될 경우 발생한다. 컴포넌트 1이 재사용 된다면 여백을 또 어디로 옮겨야 할까?

발전1

정말 정말 처음에는 컴포넌트 내부에 css로 여백을 선언하다 이런 상황을 몇 번 겪고는 컴포넌트를 호출할 때 여백을 props로 넘겨주기로 했다.

타입스크립트에서 컴포넌트를 선언할 때 HTMLElement의 type들을 상속받으면 className을 직접 선언하지 않아도 props로 넘겨줄 수 있기 때문에 이 방법이 유효했다. 그런데 모든 컴포넌트가 HTMLElement 타입을 상속받지 않을 수 있다. 그런 경우에는 또 어디에 여백을 주냐 하는 고민이 생겼다.

발전2

이런 케이스가 생기다 보니 컴포넌트 자체에 여백을 직접 주지 않는 방법을 생각해 봤다. A 페이지 B 페이지마다 여백이 다르다는 건 그 여백들은 해당 페이지 내부에서만 필요한 정보(?)라고 생각했다.

그러다 Container, Presentation 패턴을 보고 Presentation 컴포넌트를 만들어 배치, 여백 관련 스타일을 적용하면 되겠다는 생각이 들었다.

const SomePage = () => (
    <div className="max-w-[980px] mx-auto mt-6 mb-16">
      <div className="px-4">
        <div className="mb-4">
          <TypographyH4>제목</TypographyH4>
        </div>
      </div>

      <div className="mt-4">
        <MyComponent/>
      </div>
    </div>
);

이렇게 레이아웃 관련 스타일을 적용하는 컴포넌트를 만들어서 사용했다. 그러니 또 다른 페이지를 구현해도 그 페이지를 위한 Presentation 컴포넌트를 만들어 사용하면 되고 기존 재사용 컴포넌트는 수정할 필요가 없어져 유지 보수가 쉬워졌다.😎

유지 보수가 유리해진 건 좋은데 단순 스타일을 위한 태그가 너무 많아지는 것 아닌가 하는 고민이 되긴 한다. 또한 Container, Presentation 패턴을 사용하면 파일이 많아지고 코드 베이스가 복잡해질 수도 있다고 하는데 이 부분은 프로젝트가 커질 경우라 현재 우리 프로젝트에서는 문제보단 유지 보수가 용이해진 장점이 더 크다.

결론적으로, 현재 프로젝트에서는 컴포넌트의 여백 같은 레이아웃 관련 부분을 부모 요소, Presentation 컴포넌트에 위임하는 방식으로 코드를 작성하려 한다. 추가적으로 패턴에 대한 공부를 더 해볼 필요성이 느껴진 고민이었다.

• 모바일 크롬에서 개발자 도구 사용하기

연결 자체는 위 영상을 참고하면 된다. 연결하고 다른 서비스를 개발자 도구로 구경하는 것도 흥미롭다.

ios 테스트

• IOS safari로 개발자 도구 사용
• 크롬에서 간단하게 IOS 웹뷰 테스트하기

베타 서버에 배포하지 않고 모바일에서 테스트하기

연결해도 로컬에서 개발 중이면 모바일에서 접속이 안되니까 ngrok을 이용해 외부에 로컬 서버를 공개해 접속할 수 있도록 해줘야 한다.

• ngrok - 포트포워딩 없이 외부에 로컬서버 공개하기

사용법은 쏘이지 사이트에 사용법 따라 하자

문제

네이버 로그인, 카카오 맵 api는 등록해둔 url만 통신을 허용해 준다. cors 에러 발생! ngrok을 그냥 사용하면 서버를 실행할 때마다 도메인이 계속해서 바뀌기 때문에 고정 도메인이 필요했다.

해결

마침 ngrok은 static 도메인을 무려 무료 플랜에서도 하나 준다.

New Domain 눌러서 도메인 하나 추가해 준다. 그리고 사용하는 api 사이트로 가서 이 도메인을 등록해 주면 끝!

ngrok http --domain=도메인 로컬포트번호

이 명령어로 실행하면 항상 동일한 도메인으로 실행된다.

테스트할 때마다 베타 서버를 사용했는데 QA 단계 전, 개발 도중 논의할 때 등 배포 없이 바로바로 확인하고 수정 가능해서 아주 좋다.

원래 사용하던 방법

<img class="m_none" src="경로1" alt="대체 텍스트">
<img class="m_show pc_none" src="경로2" alt="대체 텍스트">

기존에 회사에서 사용하던 방법이다. 이전에 사용하던 방법을 나도 따라서 사용했었다.

사실 데스크탑 사이즈에서는 경로1의 이미지만 필요하다. 하지만 위의 방법으로 작성된 코드는 경로1, 경로2의 이미지를 모두 로드 받는다. 필요 없는 경로2를 받는 만큼 로딩이 느려진다.

랜딩 페이지는 이미지를 사용하는 부분이 많다. 그런 부분들이 모두 이렇게 작성되어 있다고 생각하면 로딩 속도는 훨씬 느려지게 된다.

picture 태그

picture 태그는 노마드 코더 유튜브에서 보게 됐다. 그리고 랜딩 페이지 작업할 때 다른 사이트들을 참고하는데 패스트캠퍼스를 보니 picture 태그를 사용하는 것을 보고 이번에 로딩 속도 개선을 위해 적용하면 좋겠다 싶었다.

picture 태그는 내부에 있는 source 태그들과 img 태그 중에서 조건에 맞는 이미지만 로드해 준다. source 태그는 여러 개를 작성해 조건을 달아줄 수 있고, img 태그는 source 태그들의 조건을 모두 만족하지 못할 경우 default 이미지로 동작하게 된다.

• 패스트캠퍼스 100가지 시나리오로 학습하는 프론트엔드 강의 랜딩 페이지에서 사용 중

webp 확장자

그리고 위 사진에 첨부된 이미지의 확장자를 보면 webp를 사용하고 있다.

webp는 구글에서 만든 이미지 확장자이다 png처럼 투명 배경을 지원하고 gif처럼 애니메이션도 지원한다. webp 확장자는 png, jpg보다 용량을 2~30% 줄일 수 있다고 한다.

사용가능한가? (크로스 브라우징)

그래도 무작정 사용할 순 없으니 호환성이 얼마나 되는지 찾아봤다.

picture 태그는 can i use에서 96.5%의 브라우저에서 지원한다고 하고 webp는 96.6%가 지원한다고 한다. 그런데... webp 확장자에 대해 검색하면 safari에서 지원하지 않는다는 글이 많은 것이다...

더 찾아봤더니 ios14부터는 safari에서 webp를 지원한다고 한다. 그럼 ios14 이상의 점유율은 얼마인가?!

이 부분은 애플 공식 사이트에서 알려준다.

ios15~16이 98%, 그 외는 2%...라서 webp를 사용하기로 결정했다. (작업할 땐 94%, 그 외 6%였는데 그새 점유율이 늘었나 보다.)

참고로 아직 safari에서 애니메이션으로 webp를 사용하면 버벅임이 발생할 수 있다고 한다. 그래서 gif는 대체하지 않았다.

lazy 로딩

laze 로딩은 말 그대로 로딩을 지연하는 것이다. 위 gif를 보면 스크롤을 내리면서 이미지가 로드가 되는데 처음부터 페이지 내의 모든 이미지를 로드 받는 것이 아니라 이미지가 필요할 때가 되어서야 로드를 받는 것이다.

코드

적용하면 이런 모습이다. 좋은 게 source 태그에는 클래스나 alt를 적지 않아도 img 태그의 속성들로 적용된다.

<picture>
   <source media="(max-width: 576px)" srcset="경로1">
   <img class="content_img" srcset="경로2" alt="타이틀 이미지" loading="lazy">
</picture>

결과

결과를 라이트 하우스로 측정해 봤다. performance가 50 -> 65로 상승했다. 물론 65점도 개선할 부분이 많은 점수지만... 당장 할 수 있는 부분인 이미지만 최적화했는데도 15점이 올랐다.

LCP가 18.9s -> 2.3s로 향상된 걸 볼 수 있는데 이 부분이 가중치가 25%로 높은 편이라 performance 점수에 영향을 많이 미쳤나 보다.

참고자료

• 웹 성능 최적화를 위한 Image Lazy Loading 기법
• picture 태그를 사용한 브라우저 별 이미지 최적화
• 포스팅을 할 때 사진을 극적으로 줄이는 완벽한 방법! WebP (단순 용량 압축 X )