1. 프론트엔드 개발에 Node.js가 필요한 이유

1.1 최신 스펙으로 개발할 수 있다.

  • 자바스크립트 스펙의 빠른 발전에 비해 브라우저 지원 속도는 항상 뒤쳐진다.
  • 아무리 편리한 스팩이 나오더라도 이것을 구현해주는 징검다리 역할, 예를 들면 바벨같은 도구의 도움 없이는 부족하다.
  • 더불어 웹팩, NPM과 같은 노드 기술로 만들어진 환경에서 사용할 때 비로소 자동화된 프론트엔드 개발환경을 갖출 수 있다.
  • Typescript, SASS 같은 고수준 프로그래밍 언어를 사용하려면 전용 트랜스파일러가 필요한다, 이것 역시 Node.js 환경이 뒷받침 되어야 우리가 말하는 프론트엔드 개발 환경을 만들 수 있다.

 

1.2 빌드 자동화

  • 과거처럼 코딩 결과물을 브라우저에 바로 올리는 경우는 흔치 않다.
  • 파일을 압축하고, 코드를 난독화하고, 폴리필을 추가하는 등 개발 이외의 작업을 거친 후 배포한다.
  • Node.js는 이러한 일련의 빌드 과정을 이해하는 데 적지 않은 역할을 한다. 뿐만 아니라 라이브러리 의존성을 해결하고, 각종 테스트를 자동화하는데도 사용된다.

 

1.3 개발 환경 커스터마이징

  • 각 프레임워크에서 자공하는 도구(React의 CRA, Vue의 vue-cli)를 사용하면 손쉽게 개발환경을 갖출 수 있다.
  • 그러나 개발 프로젝트는 각자의 형편이라는 것이 있어서 툴을 그대로 사용할 수 없는 경우도 빈번하다.
  • 커스터마이징 하려면 Node.js에 대한 지식이 필요하다.
  • 자동화된 도구를 사용할 수 없는 환경이라면 직접 환경을 구축해야 할 상황에 놓일 수도 있다.

이러한 배경하에 Node.js는 프론트엔드 개발에서 필수 기술로 자리매김하고있다.

 

1.4 Node.js 기반 프로젝트 만들기

mkdir sample
cd sample
npm init // 프로젝트 생성하는 명령어
  • sample 폴더를 만들고, 그 폴더 안에서 npm init을 실행시킨다.
  • 그러면 프로젝트의 메타데이터를 입력할 수 있는 화면이 제공됩니다.

  • 위와 같이 프로젝트 메타데이터를 입력하면, 해당 데이터를 기반으로 package.json 파일이 생성된다.
{
  "name": "npmtest",
  "version": "1.0.0",
  "description": "npm 테스트 프로젝트입니다.",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "npm"
  ],
  "author": "hyorish03",
  "license": "ISC"
}

 

1.5 패키지 설치

1.5.1 CDN을 이용한 방법

  • 외부 라이브러리를 가져다 쓰는 것은 무척 자연스러운 일이다.
  • 간단한 방법은 CDN(콘텐츠 전송 네트워크)으로 제공하는 라이브러리를 직접 가져오는 방식입니다.
<script crossorigin src="https://unpkg.com/react@18/umd/react.development.js"></script>
  • 그러나 만일 CDN 서버 장애로인해 외부 라이브러리를 사용할 수 없다면, 우리 어플리케이션 서버가 정상이더라도 필수 라이브러리를 가져오지 못한다면 웹 어플리케이션은 정상적으로 동작하지 않을 것입니다.

1.5.2 직접 다운로드하는 방법

  • 라이브러리 코드를 우리 프로젝트 폴더에 다운받아 놓을 수 있다.
  • CDN을 사용하지 않기 때문에 장애와 독립적으로 웹 어플리케이션을 제공할 수 있다.
  • 그러나 라이브러리는 계속해서 업데이트 될 것이고 우리 프로젝트에서도 최신 버전으로 교체해야합니다.
  • 매번 직접 다운로드하는 것은 매우 귀찮은 일이 될 것이고, 버전에 따라 하위 호환성 여부까지 확인하려면 실수할 여지가 많습니다.

💡 그렇다면 라이브러리를 어느 한 곳에서 업데이트하고 하위 호환이 되는 안전한 버전만 다운받아 사용할 수 있다면 어떨까 ?

 

1.5.3 NPM을 이용한 방법

  • NPM은 이러한 방식으로 패키지를 관리한다.
  • npm install 명령어를 활용해 외부 패키지를 우리 프로젝트 폴더에 다운로드 할 수 있다.
npm install react
  • 위 코드는 최신 버전의 react를 NPM 저장소에서 찾아 우리 프로젝트로 다운로드 하는 명령어다.
  • 위 코드를 실행하면 최신 버전의 react가 다운로드 될 것이고, package.json의 dependencies에는 설치된 react 패키지의 정보를 기록한다.

'NPM' 카테고리의 다른 글

[NPM] Package.json vs Package-lock.json 그리고 Caret, Tilde 등등..  (0) 2024.06.25

0. 공부 계기

프로젝트를 진행하며 Package.json 파일은 자주 보고, 사용하지만 Package-lock.json에 대해서 따로 공부해본 경험이 없습니다.

그저 패키지매니저를 재설치 할 때 package-lock.json와 node_modules를 지우고 재설치해야된다는 정도...? 그래서 정확히 공부해야할 필요성을 느껴 공부하기 시작했습니다.

 

1. Package.json이란

Node.js 프로젝트를 시작할 때, 터미널에 'npm install', 'yarn' 등의 패키지매니저를 설치하면 아래와 같이 여러 파일들이 기본적으로 설치됩니다.

 

현재 진행중인 프로젝트의 Package.json

{
    "name": "moyeota-webview",
    "private": true,
    "version": "0.0.0",
    "type": "module",
    "scripts": {
        "dev": "vite --host",
        "build": "tsc && vite build",
    },
    "dependencies": {
        "react": "^18.2.0",
        "react-bootstrap": "^2.10.1",
        /* 중략... */
    },
    "devDependencies": {
        "@types/navermaps": "^3.6.7",
        "@types/react": "^18.2.15",
        /* 중략... */
    }
}

 

2. Package-lock.json이란

  • package-lock.json 파일은 npm을 활용해 node_modules 트리나 package.json 파일을 수정하게 되면 자동으로 생성되는 파일입니다.
  • 이 파일은 파일이 생성되는 시점의 의존성 트리에 대한 정확한 정보를 가지고 있습니다.

다음은 Package-lock.json의 일부분입니다.

{
  "name": "moyeota-webview",
  "version": "0.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "name": "moyeota-webview",
      "version": "0.0.0",
       /* 중략 */
      "devDependencies": {
        /* 중략 */
        "vite-plugin-svgr": "^3.2.0",
        "zustand": "^4.4.1"
      }
    },
  "dependencies": {
    /* 중략 */
    "@types/react": {
      "version": "18.2.28",
      "resolved": "https://registry.npmjs.org/@types/react/-/react-18.2.28.tgz",
      "integrity": "sha512-ad4aa/RaaJS3hyGz0BGegdnSRXQBkd1CCYDCdNjBPg90UUpLgo+WlJqb9fMYUxtehmzF3PJaTWqRZjko6BRzBg==",
      "requires": {
        "@types/prop-types": "*",
        "@types/scheduler": "*",
        "csstype": "^3.0.2"
      }
    },
    "zustand": {
      "version": "4.4.3",
      "resolved": "https://registry.npmjs.org/zustand/-/zustand-4.4.3.tgz",
      "integrity": "sha512-oRy+X3ZazZvLfmv6viIaQmtLOMeij1noakIsK/Y47PWYhT8glfXzQ4j0YcP5i0P0qI1A4rIB//SGROGyZhx91A==",
      "dev": true,
      "requires": {
        "use-sync-external-store": "1.2.0"
      }
    }
  }
}

 

2.1 Package-lock.json이 필요한 이유

  • package.json 파일 의존성 선언에는 version range가 사용됩니다.
  • version range란 특정 버전이 아니라 버전의 범위를 의미합니다.
  • 예를 들어, npm install dotenv를 실행하면 "dotenv": "^16.3.1" 와 같은 형식으로 package.json에 설치됩니다.
    • 여기서 ^16.3.1^은 캐럿 표기법('16.3.1버전 이상, 17.0.0이하'라는 range를 알려줌)으로 ~(틸드)와 구분됩니다. (아래 정리돼있음)
  • package-lock.json에는 해당 라이브러리 설치 당시의 버전에 대한 기록을 가지고 있습니다.
  • 따라서 이후 다른 팀원이 git clone을 받고, npm install을 한다 하더라도 package-lock.json에 있는 파일 버전을 기준으로 동일하게 다운로드 할 수 있습니다.
   "node_modules/dotenv": {
      "version": "16.3.1",
      "resolved": "https://registry.npmjs.org/dotenv/-/dotenv-16.3.1.tgz",
      "integrity": "sha512-IPzF4w4/Rd94bA9imS68tZBaYyBWSCE47V1RGuMrB94iyTOIEwRmVL2x/4An+6mETpLrKJ5hQkB8W4kFAadeIQ==",
      "engines": {
        "node": ">=12"
      },
      "funding": {
        "url": "https://github.com/motdotla/dotenv?sponsor=1"
      }
    },

 

2.2 package-lock.json 사용 예시

package.json and package-lock.json @Atatus

1) 6월 1일, Developer 1이 dotenv 16.3.1을 다운 받습니다. 이는 Package.json으로 관리합니다.

2) Package-lock.json 파일은 Package.json 파일에 기록된 당시의 의존성 트리를 관리합니다.

3) 6월 17일, dotenv 라이브러리가 16.4.0으로 업데이트 됐다고 가정해봅시다

4) 6월 18일, Developer 2가 Git 클론을 받고 npm install 합니다.

     4-1) Developer1이 package-lock.jsongit에 올리지 않았다면 dotenv 16.4.0이 다운로드 될 것입니다.
     4-2) Developer1이 package-lock.jsongit에 올렸다면 Developer2는 클론받은 프로젝트 내의 Package-lock.json 파일을 활용해 정확한 버전인 dotenv 16.3.1이 다운로드 될 것입니다.

 

 

3. 결론

Package-lock.json 파일이 없다면 협업시 팀원과 버전 충돌이 나타날 확률이 매~~우 높다.

우리는 이를 방지하기 위해 Package-lock.json 파일을 사용하는 것이다.

 

 

4. Caret & Tilde

4.1 Semeantic Versioning

React 12.3.5와 같은 버전은 MAJOR.MINOR.PATCH의 구조로 구성되고, 이는 Semantic Versioning, 간단히 줄여 semver이라 부릅니다.

  • MAJOR 버전은 하휘호환 되지 않는 API의 변화들
  • MINOR 버전은 하휘호환이 되는 범위 내에서 기능 추가들
  • PATCH 버전은 하휘호환이 되는 범위 내에서 버그 수정

 

SemVer 명세

1. SemVer을 사용하는 소프트웨어는 무조건(MUST) 공개 API에 선언되어야 한다. 이 API는 코드 그 자체로 선언되거나, 문서로 엄격히 명시해야 한다. 어떤 방식으로든, 정확하고 이해하기 쉬워야 한다.

2. 일반적인 버전 넘버는 무조건(MUST) X.Y.Z 형태여야 한다. 여기서 X, Y, Z는 양의 정수여야 하며, 절대(MUST NOT) 앞에 0을 붙여서는 안된다. X는 MAJOR, Y는 MINOR, Z는 PATCH 버전으로, 각각의 요소는 증가하는 수여야 한다. (1.9.0 -> 1.10.0 -> 1.11.0)

3. 특정 버전을 배포하고나면, 해당 버전의 내용은 절대 (MUST NOT) 변경되어서는 안된다. 어떠한 수정사항일지언정 새로운 버전을 릴리즈 해야한다.

 

여기까지가 제가 번역한 SemVer 명세 1, 2, 3번 입니다. 더 깊은 내용이 궁금하신 분들은 공식문서를 읽어보시면 좋을 것 같습니다.

 

4.2 캐럿(^)과  틸드 (~) 그리고 기타 등등 (<, >, x)

  • 캐럿(^)
    • ^X.Y.Z라 한다면, X 이하의 하위호환성이 보장되는 범위 내에서 버전 업데이트
    • ^1.1.0 : 1.1.0 <= 업데이트 버전 < 2.0  인 버전과 호환 가능
    • 주의) 캐럿도 pre-release 버전 (<1.0)일 경우 틸드처럼 동작
  • 틸드(~)
    • ~X.Y.Z라 한다면, Z 범위 내에서 버전 업데이트
    • ~1.1.0 : 1.1.0 <=, 1.2 > 인 버전과 호환 가능
    • 1.2.x라 한다면, 1.2.x로 표시된 버전만 자동 업데이트가 가능
    • 즉, 1.2.0 ~ 1.2.9까진 가능하지만 1.3.0부턴 자동 업데이트가 불가능
  • ||
    • 1.2.3 || >= 1.2.9 < 2.0.0
    • ||은 or 연산자로, 하나 이상의 범위를 명시할 수 있습니다.
    • 만일 A || B로 버전을 명시한 경우, A 혹은 B 둘 중 하나만 충족해도 버전업이 가능
    • 예를 들어 1.2.3 || >= 1.2.9은 1.2.3 또는 1.3.0 으로 업데이트 가능

 

4.3 그래서 나랑 무슨 상관..?

  • 예를 들어, 내가 zustand 4.4.1 버전을 사용하고 있다고 가정합시다.
  • 그러던 중 4.4.1버전에 버그가 생겨 zustand 개발자는 버그를 수정 후 4.4.2 버전을 다시 릴리즈 했습니다.
  • 그러나 현실적으로 개발자가 사용하는 유저에게 모두 사용중인 zustand의 버전을 업그레이드 하라고 연락을 할 순 없습니다.
  • 이때 만일 package.json의 zustand 버전이 ^4.4.1이라면, 4.5 미만의 버전과는 모두 호환이 가능하다는 것입니다.
  • 따라서 4.4.2 버전이 릴리즈 되고, 업데이트 된다면 나는 굳이 새로 zustand를 업데이트 하지 않아도 자동으로 업데이트 및 호환이 가능하다는 것입니다.

 

 

 

 


[참고자료]

https://semver.org/

https://hyunjun19.github.io/2018/03/23/package-lock-why-need/

https://han7096.medium.com/package-lock-json-%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC-5652f90b734c

https://dev-ellachoi.tistory.com/65 

💙 삼성 청년 SW 아카데미(SSAFY)란?

삼성 청년 SW 아카데미(SSAFY)는 삼성의 SW 교육 경험과 고용노동부의 취업지원 노하우를 바탕으로 취업 준비생에게 SW 역량 향상 교육 및 다양한 취업지원 서비스를 제공하여 취업에 성공하도록 돕는 프로그램입니다.

삼성 그룹의 후원으로 진행되는 IT 취업 교육 프로그램입니다. 멀티캠퍼스라는 업체에 교육을 위탁해 진행합니다. 싸피는 총 1년동안 진행되며 6개월에 한 번씩 새로운 기수를 뽑습니다. 1학기에는 알고리즘, 기술과 관련된 지식 배경, 기술 등을 배운 뒤 기말 프로젝트를 경험합니다.

 

짧은 방학에 잡페어와 특강 등이 진행되고, 2학기는 프로젝트 위주로 진행됩니다. 웹, 모바일 뿐만 아니라 4차 산업 기술 ? AI, 데이터 등등을 배워 적용해 프로젝트를 하는게 큰 특징인 것 같습니다.

싸피 수강생의 대다수는 웹 트랙을 밟고, 웹트랙은 크게 전공자반과 비전공자반으로 나뉩니다.

💰 교육생 혜택

사실 아래 두 가지만 보고 지원하시는 분들이 많을 것 같습니다.

1. 매월 100만원 (지방의 경우 30만원 추가)의 학업 지원금

2. 많은 은행권에서 우대

작년(2023년) 하반기 공채때 은행권 여기저기에 지원했었는데 진짜 싸피 우대해주는구나를 많이 느꼈습니다 .. (샘숭 짱)

 

🔜 지원 절차

12기 기준 지원 절차는 다음과 같습니다.

지원 접수 > 에세이 작성 > SW적성진단 > 인터뷰 > 최종합격

 

 

📝 에세이 작성

지원 신청한 이후 코테 보기 전 날까지 에세이를 쓸 수 있습니다.

향후 어떤 SW 개발자로 성장하고 싶은지 SW 관련 경험을 토대로 기술하고, SSAFY에 지원하신 동기에 대해서도 작성바랍니다 (SW 관련 경험 : SW 개발, SW 프로젝트 및 SW 경진대회 경험(참여, 수상 등), IT 관련 자격증 취득 등 (600자까지 입력 가능)


제가 썼던 지원서를 그대로 공개할 순 없지만 대충 다음과 같이 썼습니다.

 

1. 어떤 개발자가 되고싶은지 ? (149자)

구체적인 분야 및 계기를 적었고 계기에는 공모전 수상 사례도 함께 적었습니다.

 

2. 내 SW에 관한 경험 (317자)

알고리즘을 활용해 기능 개발을 했던 사례를 적고, 문제 해결을 위해 끈질기게 노력했다는 점을 강조했습니다.

싸피가 초반에 알고리즘 교육을 빡세게 시키기도 하고, 인재상이 논리적인 사고를 하는 인재이기 때문에 알고리즘 경험을 강조했습니다.

 

3. 싸피에서의 포부 (126자)

그냥 입에 발린 말 했습니다. 싸피에서 알고리즘 배워서 코딩 역량 강화하고, 심화과정에서 AI 기술을 학습해 실무형 인재가 되겠다고 적      었습니다.

 

근데 막상 제출하고 나니 내가 왜 싸피가 필요한지에 대한 부분이 많이 부족하다고 느꼈습니다. 싸피는 코테 2솔도 지원서 때문에 떨어지고, 0솔도 지원서때문에 붙는다는 말이 있듯이 지원서가 정말정말 중요합니다.

 

그래서 코테를 정말 잘 봐야겠다 생각했습니다.

 

🖥️ SW적성검사 (코딩테스트,  5/19)

사전 오티

사전 오티를 진행합니다. 정말 .. 킹받게 ... 원래 저 날 점심 먹고 데이트 가기로 해서 신났었는데 점심 먹으러 가는 길에 갑자기 생각나서 호다닥 먹고 다시 집에 왔습니다. (아니 어차피 코테 당일 날 또 하는데 왜,,,,)

코딩테스트 후기

음 ... ^^ 정말 쉬웠습니다 .... 총 2개의 알고리즘 문제가 나오는데 전 15분만에 다 풀고 더 효율적으로 풀 수 없는 지 생각했습니다.

제 코테 당시 스펙 (?)

백준 티어: 골드 3
코테 준비 기간: 6개월 이상
프로그래머스: Lv2 이하는 다 풀지만 Lv.3부터는 유형에 따라 어려워함


코딩테스트 준비는 꾸준히 스터디로 해왔었고, SSAFY 코테 2달 전부터는 SWEA의 D3문제를 꾸준히 풀었습니다.

다들 SWEA에서 꼭 준비하세요 !! 그래야 시험 당일에도 당황하지 않을 수 있습니다. 🌝

 

사실 전 기본기가 아주아주 약하다 생각해 지금도 자료구조를 처음부터 공부 중입니다.😅

그래서 복잡한 알고리즘 문제가 나오면 어떡하나.. 계속 걱정했으나.. 정말 오산이었다는 생각이 들었습니다 ㅋㅋ

 

SSAFY 코딩테스트는 쉬운 구현 위주의 문제가 나오기 때문에 조금만 공부해도 충분히 2솔도 가능하다 생각합니다 !

이번 12기 오후 반 코딩테스트는 D2 수준이었다고 생각합니다.

저와 함께 스터디를 했던 언니가 오전 반이었는데 오전도 D2수준 단순 구현문제였다고 합니다.

 

추천 문제

백준 - N과 M 시리즈

https://www.acmicpc.net/problem/15649

https://www.acmicpc.net/problem/15650

https://www.acmicpc.net/problem/15651

백준 - deque

https://www.acmicpc.net/problem/10866

https://www.acmicpc.net/problem/28279

 

🍯 코테 꿀팁 ?

SSAFY 뿐만 아니라 타 기업 공채, 부트캠프 코테 등등 구현 위주의 문제가 나오는 추세입니다.

따라서 너무 어려운 알고리즘 문제를 푸는 것 보단 시뮬레이션, 빡구현 등등 복잡한 구현 문제를 계속해서 풀려고 노력하는 것을 추천합니다

 

 

✅ 에세이 & 코테 합격

에세이에서 왜 나에게 싸피가 필요한지에 대해 많이 적지 못하기도 했고, 코테도 2솔했다고 생각하지만 1번 문제에 대해서 자칫하면 시간초과가 날 수도 있다는 불안감때문에 떨어질 수도 있겠다 싶었습니다.

또, 문제가 워낙 쉬워서 에세이를 많이 볼 것 같은데 난 에세이에 크게 자신감이 없고,,, 해서 기대를 많이 안 하고 있었습니다.

하지만 붙었죠 ?

 

 💪 면접 준비

아마 싸피 면접 준비 좀 찾아보신 분들은 다 아실거예요 .. 강민혁님 PT 면접영상을 ...

운 좋게도 함께 코딩테스트를 준비하던 친구들이 다 면접 전형까지 가게 되어 함께 스터디를 진행했습니다.

🩵 스터디 방식

스터디는 인성, PT 면접, 에세이 카테고리로 나눠 진행했습니다. 인성질문과 에세이는 그냥 ... 다른 면접 준비하듯 준비하시면 됩니다.

아마 PT 면접을 준비하는게 가장 고민이실텐데, 저희는 다음 순서대로 진행했습니다.

 

1. 카테고리 설명

한 사람당 한 개의 카테고리를 전담해 자료 조사를 한 후 발표합니다. (ex. 생성형 AI 담당이라 하면 관련된 자료를 정리 후 발표합니다)

카테고리 고민이 많으실텐데 Ssafy 홈페이지에 보면 4차 산업혁명 기술을 습득하고 이를 적용하는 프로젝트가 있죠 ? 저는 이 점이 중요하다 생각했습니다.

 

제가 담당했던 카테고리 중 하나인 생성형 AI에 대해 정리한 정리본입니다.  

https://hyorinleee.notion.site/AI-1e8ad5eb95b0426f936ad369e24e8f81

 

생성형 AI | Notion

생성형 AI란

hyorinleee.notion.site

 

 

2. 주제 선정 및 PT 준비

본인이 발표를 담당한 카테고리에 대한 주제를 정합니다. 해당 주제에 대해 한 사람당 한 개씩 담당하여 PT 면접을 준비해옵니다.

다음은 제가 스터디때 직접 준비했던 PT 자료입니다.

 

 

💬 면접 후기

솔직히 말하면 면접 준비 하나도 안했습니다..ㅋㅋ

이미 LG U+에서 하는 유레카 교육에 합격한 상황이었고, 사실 전 부캠 중 싸피가 가장 간절하지 않았기에 면접 준비는 스터디 제외하고 열심히 하지 않았습니다. 스터디를 한거면 면접준비 한거 아니냐 할텐데, 사실 스터디에선 너무 무난한 질문들에 대해서만 준비했었습니다.

 

싸피 면접관들이 물어볼만한 질문들을 뽑아 그들이 원하는 답변을 준비했어야 했는데 하나도 준비하지 않았습니다 .. 사실 저보다 저와 함께하는 언니의 합격이 더 간절했기에 면접 전날 언니와 하드트레이닝하는 시간을 거쳤습니다 ^_^ 

 

이걸 읽으시는 분들은 싸피가 어떤 기관인지, 어떤 사람을 뽑고자 하는 지, 어떤 인재상을 갖고 있는 지, 트랙에서 언어는 어떤 것을 쓰는 지 다시 한 번 곰곰히 생각해보시며 면접에 임하셨으면 좋겠습니다 !

 

앗 물론 그 언니는 서울 웹 트랙 합격했습니다 !!! 비록 전 떨어졌지만 너무 기쁩니다 ㅎㅎㅎ

 

비록 최종은 불합이지만 면접 진행중에서도 느껴졌던 부분이기도 했고, 준비할 수 있던 부분을 안한 결과이기에 크게 저에게 영향을 주진 않았습니다.(블로그 유입엔 영향이 있겠지만...)

 

앞으로 전 유레카 교육과정에 몰입해 열심히 참여하도록 하겠습니다 ! 더 궁금한 점은 댓글 남겨주십셔  😊

문제정의 및 원인 파악 글

https://hyorish03.tistory.com/22

 

[React] Geolocation API의 느린 문제 (1) - 문제정의

😫 문제 현상 설명Geolocation의 Watchposition 훅을 사용해 위치 변화가 감지될 때마다 현 위치를 새로 받아와 보여주는데새로고침을 하거나 초기 접속 시 파란 빈 화면이 5초 이상 나타났습니다. •

hyorish03.tistory.com

 

 

원인

  • Geolocation API + React + 크로미움 브라우저 ⇒ 5초 이상의 지연이 발생.
  • Geolocation API의 watchPostion + 바닐라 JS (브라우저 상관X) ⇒ 5초 이상의 지연이 발생.

 

해결방안

1. 눈 속임을 한다.

  • 파란 화면이 나오는 이유는 지도의 최초 center 위도 경도 값을 0으로 초기화했기 때문이었습니다. (그래서 바다가 찍혔던 것..)
  • 초기 위치를 서울과학기술대학교 미래관으로 찍어두고, Geolocation API를 통해 현 위치를 받아오는 5초간 보여지는 화면이 빈 화면처럼 느껴지지 않도록 수정해보았습니다. 

 

변경 전 (빈 파란화면이 5초이상 지속됨)                                                    변경 후 (초기 화면이 파란화면이 아님)



2. RN에서 현 위치를 메시지로 받는다

  • RN에서 로그인할 경우 JWT토큰을 웹뷰로 메시지를 보냅니다.

  • 이를 활용해 현 위치를 accessToken과 함께 웹뷰로 보내는 방식도 있었습니다.
  • 그러나 이와 같은 방식이 웹에서 현 위치를 받는 방식과 속도면에서 큰 차이가 있지 않아 선택하지 않았습니다.
  • /* DB 복구시 추가예정*/

3. 로그인 화면에서부터 현 위치를 조회한다 (⭐️NEW !) - 최종선택

  • 프로젝트는 웹뷰 기반 expo 앱이었습니다. 
  • 따라서 로그인과 마이페이지는 RN으로, 기타 기능은 모두 웹뷰로 구현했습니다.
  • 그러나 프로젝트 진행을 하며 로그인 또한 웹에서 진행하자는 의견이 나왔고, 이를 활용해 Geolocation API가 느린 문제를 해결할 수 있었습니다.
  • 로그인 페이지에서 현 위치 조회한다면, 유저가 로그인하는동안 Geolocation의 5초 지연 시간이 흐르기 때문에 유저가 메인 화면에 들어갈때쯤엔 정확한 위치를 지도에 그릴 수 있었습니다. 
  • /* DB 복구시 추가예정*/

 

+ Recent posts