후회가 없도록

[React] 절대 경로 설정(feat. Absolute imports)

AS J — Sat, 17 Sep 2022 17:13:47 +0900

1. 절대 경로 설정 방법

React에서 컴포넌트나 파일 등을 import 할 때 보통 상대 경로를 작성한다. 예시를 들자면, 아래와 같은 src 구조를 갖고 있고 Profile.js 파일에서 Home.js, Router.js 파일로부터 무언가를 import 하고 싶을 땐 그 아래의 코드처럼 작성하면 된다.

import Home from "./routes/Home"
import AppRouter from "../components/Router"

...

하지만 파일과 디렉터리가 많아지면 import를 작성하는 과정에서 상대적인 위치를 헷갈리면서 오류가 발생할 수 있다. 이를 조금이나마 방지하고자 절대 경로로 작성하는 경우도 있는데, React에서 절대 경로를 이용할 경우는 src와 같은 디렉터리 단계(React 프로젝트 디렉터리 바로 하위 단계)에서 jsconfig.js 또는 tsconfig.js 파일을 작성함으로써 가능하다.

그리고 jsconfig.json 또는 tsconfig.js 파일의 내용은 아래와 같이 작성하면 된다.

{
    "compilerOptions": {
        "baseUrl": "src"
    },
    "include": ["src"]
}

2. 참고

https://create-react-app.dev/docs/importing-a-component/

Importing a Component | Create React App

This project setup supports ES6 modules thanks to webpack.

create-react-app.dev

[JavaScript] "npm" vs "yarn"

AS J — Mon, 5 Sep 2022 15:24:06 +0900

1. npm이란?

npm(Node Package Manager)은 자바스크립트 프로그래밍 언어를 위한 패키지 관리자이며, 자바스크립트 런타임 환경 Node.js의 기본 패키지 관리자를 의미한다. Node.js로 만들어진 모듈을 웹에서 다운 받은 후, 쉽게 설치하고 관리해주는 프로그램으로써, 개발자 입장에서는 단 몇 줄의 명령으로 기존 공개된 모듈을 설치하여 사용할 수 있다. 이 npm은 "명령 줄 클라이언트(npm)", 공개 패키지와 지불 방식의 개인 패키지의 "온라인 데이터베이스(npm 레지스트리)"로 이루어져 있다. 여기서 레지스트리는 클라이언트를 통해 접근되며, 사용 가능한 패키지들은 npm 웹사이트를 통해 검색할 수 있다고 한다.

이런 npm이 없었을 때에는 필요한 기능을 추가하기 위해 직접 코드를 작성하거나 깃허브를 통해 별도로 다운로드하여 사용해야 했다고 한다. 그리고 이런 불편을 해소하기 위해 나타난 것이 npm이며, npm은 Node.js에 내장되어 있기 때문에 Node.js를 설치하면 npm 명령어를 통해 기능을 추가하고 관리할 수 있다.

2. yarn이란?

yarn 또한 자바스크립트 패키지 관리자이며, 프로젝트 패키지 의존성을 관리하는 툴이다. 주요 기능으로는 npm과 마찬가지로 패키지의 저장소를 제공하고 시스템에서 의존 패키지를 설치, 업데이트 할 수 있도록 도와준다. package.json 파일을 통해 해당 프로젝트가 의존하고 있는 모든 패키지를 구분하고, package.json에 있는 dependencies 필드를 기반으로 패키지를 설치한다. 덕분에 실제 패키지들이 저장되어 있는 node_modules 디렉터리 대신 package.json 파일만을 공유하여 데이터 낭비를 줄일 수 있는 것이다. 이는 npm도 마찬가지이다.

그렇다면 왜 npm이 있는데, yarn이 개발된 것일까? 간단하게 말하면 npm의 단점을 개선하고 향상시키기 위해 개발되었는데, 여기서 말하는 npm의 단점으로는 속도(performance), 안정성(stability), 보안성(security) 등이 있다.

3. "npm" vs "yarn"

1) 속도(performance)

yarn은 다운 받은 패키지 데이터를 캐시(cache)에 저장하여 중복 다운로드를 방지하고, 패키지 설치 또한 병렬로 처리하기 때문에 속도 측면에서 순차적으로 처리하는 npm보다 빠르다고 평가된다.

2) 안정성(stability) 및 보안성(security)

npm은 패키지 설치 시 자동으로 코드와 의존성을 실행할 수 있도록 허용되어 있다. 이는 보장된 정책 없이 등록한 패키지를 설치할 경우에 위험도가 높다는 점이 있다. 반면 yarn은 yarn.lock과 package.json으로부터 설치만 하고, yarn.lock은 모든 디바이스에 같은 패키지 설치를 보장하며 버전 차이로 인한 버그를 방지할 수 있다.

3) 정리

애초에 yarn 자체가 npm의 단점을 개선하고 향상시키기 위한 목적으로 개발되었기 때문에 여러 부분에서 npm보다 상대적으로 나은 점들이 많다. 그럼에도 npm은 상대적으로 많은 사용자 수와 쉬운 접근성이라는 장점이 존재하고, yarn은 brew나 npm을 통해 추가로 설치가 진행되어야 한다는 약간의 불편함 등이 있다. 그리고 npm을 사용해봄으로써 yarn이 어떤 점에서 이점이 있는지 직접 느낄 수 있기 때문에 두 가지를 모두 경험해보는 것이 좋을 것이고, 개인적으로도 그런 편이 좋다고 생각한다.

4. 출처

1) https://ko.wikipedia.org/wiki/Npm_(%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4)

npm (소프트웨어) - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전.

ko.wikipedia.org

2) https://velog.io/@kysung95/%EA%B0%9C%EB%B0%9C%EC%83%81%EC%8B%9D-npm%EA%B3%BC-yarn

[개발상식] npm과 yarn

패키지 관리 툴로는 대표적으로 npm과 yarn이 있습니다.여러분들은 평소 어떠한 패키지 설치 모듈을 사용하나요?

velog.io

[DOM] 브라우저 렌더링 과정 및 Virtual DOM(가상 돔)

AS J — Wed, 8 Jun 2022 23:59:27 +0900

1. 브라우저 렌더링 과정

1) DOM(Document Object Model) tree 생성: 렌더 엔진이 HTML을 파싱하여 DOM 노드로 이루어진 트리 생성.

2) render tree 생성: css 파일과 inline 스타일을 파싱. DOM과 CSSOM을 합친 렌더 트리를 생성.

3) Layout(reflow): 각 노드들의 스크린에서의 좌표에 따라 위치 결정. position이나 size 등도 해당 단계에서 계산.

4) Paint(repaint): 실제 화면에 출력.

위 과정에서 웹 페이지에 어떠한 변화가 발생했을 때, 2번 과정부터 다시 재진행 된다. 즉, 렌더 트리가 재생성 되고 이후의 과정이 다시 반복되며 화면에 UI 재출력이 되는 것이다.

2. Virtual DOM

1) Virtual DOM이란?

SPA(Single Page Application)는 브라우저단에서 자바스크립트가 관리한다. 이를 효율적으로 관리하기 위해 Virtual DOM이 등장했으며, Virtual DOM은 DOM의 복사본 혹은 HTML DOM의 추상화 버전이라고 표현할 수 있다.

2) Virtual DOM의 동작 원리

실제 DOM의 object와 같은 '속성'들을 가지고 있지만, 실제 DOM이 갖고 있는 'api'는 갖고 있지 않는데, 이를 통해 Virtual DOM에 변경 사항이 반영되면 원본 DOM에 필요한 변화만 반영하여 필요한 UI의 업데이트 적용이 가능하다. 이것이 가능한 이유는 Virtual DOM은 HTML 객체가 아닌 자바스크립트 객체(자바스크립트를 기반으로 하는 객체)를 활용하고 있기 때문에 가능한 것이다.

3) Virtual DOM의 이점

- 실제 DOM이 아닌 메모리 상에서 동작하기 때문에 더 빠르게 동작한다.

- Virtual DOM tree는 변화에 일일이 실제 렌더링이 되지 않고, 모든 변화를 하나로 묶어서 딱 한 번만 실행시키기 때문에 연산 비용이 최소화된다.

- 하지만 무조건 Virtual DOM이 빠른 것은 아니다. 정보 제공만 하는 웹 페이지라면 인터랙션이 발생하지 않기 때문에 일반 DOM의 성능이 더 좋을 수도 있다는 점을 명심하며, 용도에 알맞은 방식을 잘 고려하여 선정하는 것이 제일 중요하다.

종합적으로 말하면 Virtual DOM은 DOM fragment의 변화를 묶어서 적용한 다음, 기존 DOM에 던져주는 과정을 수행하고 이를 자동화 및 추상화 해놓은 것이다.

3. 참고 영상

https://www.youtube.com/watch?v=PN_WmsgbQCo

[JavaScript] ES란?(Feat. ES6)

AS J — Mon, 25 Apr 2022 17:08:29 +0900

1. ES란?

ES란 ECMAScript의 줄임말로써, Ecma International이 ECMA-262 기술 규격에 따라 정의하고 있는 표준화된 스크립트 프로그래밍 언어를 의미한다. 쉽게 말하면 자바스크립트(JavaScript)를 표준화하기 위해 만들어졌다고도 볼 수 있다.

역사적으로 보면 1996년 3월 넷스케이프에서 넷스케이프 네비게이터 2.0을 출시하며 자바스크립트를 지원하기 시작했고, 자바스크립트의 성공을 본 마이크로소프트가 이와 적당히 호환되는 J스크립트를 개발했다. 넷스케이프는 이렇게 생겨나는 스크립트 언어들의 표준화를 위하여 ECMA-262라는 이름의 기술 규격을 제출하고 ECMA 일반 회의에서 1997년 6월에 채택된 것이다.

즉, ES(ECMAScript)는 ECMA-262에 의해 표준화된 언어의 이름 및 표준 규격이며, 자바스크립트와 J스크립트는 모두 ES와의 호환을 목표로 하면서 해당 규격에 포함되지 않는 각각의 확장 기능을 제공하는 것이다.

2. ES6란?

ES6란 말 그대로 ES의 6번째 버전을 의미한다. 이는 2015년 6월에 개정된 버전이며, 현재 가장 최신 버전으로는 ES10까지 개정되었다. ES6 이전까지는 불규칙적으로 개정되다가, ES6를 기점으로 이후 매년 6월마다 규칙적으로 개정이 되고 있기 때문에 매년 새로운 ES 버전으로 개정되고 있다.

그렇다면 현재 ES10까지 개정이 되었는데, 최근 ES6가 많이 언급되고 있는 이유는 무엇일까? 우선, ES6는 이전 버전에서 문제가 되었던 부분들이 많이 해결되고, 많은 기능들 또한 추가되었다. 특히 클래스, 모듈 같은 복잡한 응용 프로그램을 작성하기 위한 새로운 문법들이 추가되었고, 이는 가독성과 유지보수성 향상으로 이어졌다. 이런 부분에서 ES6는 이전 버전에 비해 훨씬 더 좋은 응용성을 갖고 있다고 볼 수 있다.

하지만 ES는 ES6 이후부터 매년 개정되고 있기 때문에 최신 버전의 ES를 적용한다고 하면 자바스크립트를 응용하는 React나 Vue에서도 매년 그에 맞추어 개정을 해야 한다는 것을 의미한다. 아마 이런 부분에서 조금씩 부담으로 작용할 수 있다. 또, 가장 핵심적인 변화가 있었고 대부분의 상황에 대해 안정적인 표준이 된 버전이 ES6이기 때문에 ES6를 기준으로 적용하고 있다고 생각한다.

3. 참고

https://ko.wikipedia.org/wiki/ECMA%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8

ECMA스크립트 - 위키백과, 우리 모두의 백과사전

ECMA스크립트(ECMAScript, 또는 ES[1])란, Ecma International이 ECMA-262 기술 규격에 따라 정의하고 있는 표준화된 스크립트 프로그래밍 언어를 말한다. 자바스크립트를 표준화하기 위해 만들어졌다. 액션스

ko.wikipedia.org

[React 에러 해결] npm ERR! code ERESOLVE

AS J — Wed, 13 Apr 2022 00:07:27 +0900

1. 에러 발생

https://as-j.tistory.com/123

[React 에러 해결] You are running `create-react-app` 4.0.3, which is behind the latest release (5.0.0). We no longer support

1. 에러 발생 부끄럽지만 작년에 리액트를 정말 수박 겉핥기식으로만 접한 후, 이제야 다시 제대로 리액트와 프론트엔드 공부, 프로젝트를 시작했다. 먼저 리액트를 이용한 프로젝트를 생성하는

as-j.tistory.com

이 글을 통해 create-react-app을 완료했다고 생각했다. 어떻게 보면 해결하긴 했다. 하지만 위 글의 제목에 해당하는 에러만 발생하지 않을 뿐, 다른 에러가 다시 발생했다. 그 에러는 다음과 같다.

2. 에러 해석

에러 문구가 많긴 하지만 대충만 훑어봐도 react의 몇몇 버전들이 달라서 발생했다고 생각이 들었다. 보통 버전을 표시하는 18.0.0과 같은 형식의 숫자들이 많이 보였기 때문이다.

아마 내가 강의를 따라 하거나 프로젝트를 진행하면서 nodejs 재설치, yarn 설치 등의 과정을 거치면서 npm에 대한 버전 의존성이 꼬였다고 생각이 들었다. 이 부분은 아래 블로그를 보면서 대략적인 느낌만 파악했는데, 추후 npm과 yarn에 대해 다시 직접 비교하고 이해해보며 정리를 해봐야 할 것 같다.

https://velog.io/@kysung95/%EA%B0%9C%EB%B0%9C%EC%83%81%EC%8B%9D-npm%EA%B3%BC-yarn

[개발상식] npm과 yarn

패키지 관리 툴로는 대표적으로 npm과 yarn이 있습니다.여러분들은 평소 어떠한 패키지 설치 모듈을 사용하나요?

velog.io

3. 에러 해결

npm과 yarn에 대한 비교와 아래 글을 통해 아마 내가 에러를 겪는 이유는 이전에 yarn을 설치했다는 점이라고 판단했다. 아래 글에서는 5가지 정도의 해결 방법을 제시해주는데, 그중 맨 마지막에 그냥 yarn을 이용하여 설치하는 방법도 제시해주기 때문이다.

https://www.korecmblog.com/ERESOLVE-unable-to-resolve-dependency-tree/

ERESOLVE unable to resolve dependency tree 해결하기

상황 블로그를 만들기 위해 Gatsby Starter 메뉴얼에 따라서 아래 명령어를 실행했다. 공식 문서에서 제공하는 설치 방법임에도 불구하고 아래와 같은 오류가 발생했다. 자세히 오류를 살펴보면 아

www.korecmblog.com

그리고 실제로도 npx가 아닌 yarn을 통한 아래 명령어를 입력했을 때, 너무나도 편안하게 한 번에 리액트 프로젝트 디렉터리가 설치되는 것을 확인할 수 있었다. 단, 여기서 npx를 통한 명령어와 다르게 create와 react-app 사이는 그냥 띄어쓰기로 입력한다.

yarn create react-app project-name

이외의 상황일 경우에는 바로 위 링크의 블로그 글을 참고하는 것이 더 바람직하다고 생각되며, 추가로 yarn이 설치되어 있지 않은 경우는 아래와 같은 명령어를 통해 yarn을 설치할 수 있다.

npm install -g yarn

[React 에러 해결] You are running `create-react-app` 4.0.3, which is behind the latest release (5.0.0). We no longer support global installation of Create React App.

AS J — Tue, 12 Apr 2022 12:26:34 +0900

1. 에러 발생

부끄럽지만 작년에 리액트를 정말 수박 겉핥기식으로만 접한 후, 이제야 다시 제대로 리액트와 프론트엔드 공부, 프로젝트를 시작했다. 먼저 리액트를 이용한 프로젝트를 생성하는 아래 명령어를 실행했을 때, 다음과 같은 에러가 발생했다.

npx create-react-app project-name

You are running `create-react-app` 4.0.3, which is behind the latest release (5.0.0).

We no longer support global installation of Create React App.

Please remove any global installs with one of the following commands:
- npm uninstall -g create-react-app
- yarn global remove create-react-app

The latest instructions for creating a new app can be found here:
https://create-react-app.dev/docs/getting-started/

2. 에러 해석

에러를 해석해보면 현재 내가 4.0.3 버전의 create-react-app을 사용하고 있고, 최신 버전은 5.0.0 버전이며, npx에서는 더 이상 create-react-app의 전역 설치(?)를 지원하지 않는다고 해석이 된다. 그래서 이미 사용 중인 create-react-app은 -g나 global 옵션을 통해 삭제하고, 최신 버전 사용법을 확인하라는 것으로 보인다.

하지만 정작 에러에서 제시한 명령어를 사용하더라도 해결되지 않는다는 의견들이 많았고, 나 또한 그랬다.

3. 에러 해결

다른 분들의 글을 참고했을 때, 아래와 같은 명령어를 통해 이 에러를 해결할 수 있었다. 이 명령어는 아마 기존의 create-react-app을 삭제하거나 건드리지 않으면서, 생성하려는 프로젝트는 최신 버전의 create-react-app을 통해 설치할 수 있도록 하는 명령어로 보인다.

npx create-react-app@latest project-name

추가로 여기서 프로젝트명에는 대문자(capital letter)가 포함될 경우 프로젝트 생성이 되지 않는다. 프로젝트명에는 대문자를 넣지 말 것!

[UI/UX] 디자인 툴 비교하기(feat. 스케치, XD, 피그마)

AS J — Wed, 23 Mar 2022 01:38:44 +0900

* 이 글은 인프런의 '주간 인프런 #27 - UI 디자인 툴 Top 3 비교하기' 글을 상당 부분 참고하여 제가 이해하기 쉽도록 다시 간단하게 요약 및 정리한 글입니다.

최근 프론트엔드 개발 파트로 참여하게 된 팀 프로젝트가 있는데, 해당 프로젝트에서 유일한 프론트엔드 개발자인 만큼 기본적인 UI 설계 및 구성은 내가 주도적으로 하는 것이 맞다고 판단하였다. 이전에 이어드림 교육 과정에서 중간 프로젝트로 진행했던 팀 프로젝트에서는 빠른 시간 내에 눈에 보이는 결과 먼저 만들기 위해 부리나케 UI 프레임워크나 부트스트랩을 이용했다. 지금은 비교적 여유롭고(그렇다고 매우 느긋하게 만들겠다는 것인 아니지만!) 내가 나아가려는 직무에 대해 조금 더 구색을 갖추고, 트렌드에 맞게 프로젝트를 진행해보고 싶어서 우선 UI 디자인 툴을 통해 UI를 디자인하기로 생각했다.

한 일주일 전에 아주 간단하게 NFT를 만들어보면서 Figma(피그마)라는 툴을 사용한 적이 있는데, 당시 대충만 검색해봐도 뭔가 피그마가 대세라는 느낌이 많이 들었기 때문에 이번 프로젝트에서도 피그마를 사용할 생각이었다. 하지만 그래도 왜 피그마가 대세인지, 구체적으로 다른 디자인 툴과 어떻게 다르며 어떤 장단점이 있는지 파악하고 싶어서 이 글을 작성한다.

0. Good bye, 포토샵!

먼저, 내가 기억하기로는 2000년 초중반 즈음에만 해도 디자인, 합성 등에 무조건 포토샵을 이용했다. 하지만 현재 디자인 툴을 검색하면 포토샵에 대한 언급은 거의 없는 수준이다.

1) 포토샵의 인기가 식은 대표적인 이유는 포토샵이 비트맵(Bitmap) 방식의 툴이기 때문이다. 비트맵 방식으로 그려진 디자인은 아래 사진처럼 확대했을 때, 깨진다는 단점이 있다. 혹은 확대해도 깨지지 않게 하기 위해 너무 용량이 커지거나 처리 시간이 길어지기도 한다. 반면, 일러스트레이터와 같이 벡터 방식으로 그린 이미지는 이미지의 정보를 수학적인 공식으로 저장하기 때문에 이미지를 확대해도 깨지지 않고, 용량 또한 가볍다.

2) 오히려 포토샵의 기능이 너무 많고 세부적이라는 점 또한 단점이 될 수 있다. 프로그램 자체도 무거운 상황에서 다양한 기능을 세밀하게 적용하기 위해 작업을 하다 보면 작업창이 많아지기도 하고, 간단한 UI 디자인을 위한 작업에도 부담이 따를 수 있다.

3) 무엇보다 현재 개발 환경의 트렌드로 애자일한 프로세스가 자리를 잡기 시작했다는 점이 크다. 애자일 프로세스는 짧은 단위의 업무 프로세스를 빠르게 반복하는 개발 방법론으로써, 프로젝트를 최대한 빠르게 만들어 내놓고, 사용자의 피드백을 통해 버그나 보완점을 바로바로 수정하는 데 집중하는 형태이다.

애자일한 프로세스는 사용자와 UX(사용자 경험)가 가장 핵심인데, 더 좋은 UX를 이끌어내기 위해서는 당연히 좋은 UI 또한 중요하고, 사용자의 의견을 반영한 UI를 계속해서 만들어내고 수정하기 위해서는 포토샵보다 더 가볍고, UI 디자인에 최적화된 툴이 필요한 것이다.

오늘날 UI 디자인 툴의 기본 조건

1. 스케치(Sketch)

2010년, 네덜란드의 보헤미안 코딩(Bohemian Coding)에서 출시한 UI 디자인 툴이며, 어도비 XD, 피그마보다 앞서 가장 먼저 출시되었다. 당시 오늘날 UI 디자인 툴의 기본 조건을 두루 갖춘 최초의 툴이었기 때문에 혁신적이라는 평을 받았다.

1) 장점

- 오래된 만큼 업계에서 가장 대중적인 툴이다.
- 툴 자체에 내장된 기능 외에도 강력하게 기능을 보완해 주는 외부 확장 플러그인과 프로그램이 다양하다. 특히, UI 디자인을 실제 애플리케이션으로 구현할 수 있도록 개발자나 팀원들에게 디자인 속성 값, 리소스 등의 가이드라인을 공유해주는 제플린(Zeplin)이라는 프로그램이 있다.
- 업데이트가 자주 있으면서도 안정적으로 지원한다.

2) 단점

- macOS 전용 툴이기 때문에, Windows, Linux 등의 다른 운영체제에서는 사용이 불가하다.
- 구독제로써 비용이 발생하고, 여러 유료 플러그인을 사용할 경우엔 비용이 더 추가될 수 있다.
- 후발 주자인 XD, 피그마 등에 비해 단순한 수준의 프로토타이핑 기능만 지원한다.

여기서 프로토타이핑이란, 프로덕트 개발 과정 초기에 시스템의 모형(Prototype)을 간단히 만든 뒤 실제로 사용해보게끔 하고, 요구 사항을 받아 즉각적으로 기능을 수정, 보완하고 개선시켜나가는 방식을 뜻한다.

2. XD(eXperience Design)

2016년 3월, macOS용 'Adobe Experience Design CC'의 베타(프리뷰) 버전이 어도비 유저들을 대상으로 출시됐고, 같은 해 12월엔 Windows 10용이 공개되었다. 이후 마침내 2017년엔 정식 1.0 버전을 릴리스했다. 이는 피그마보다 출시가 늦은 시점이었다.

1) 장점

- 별도 플러그인 없이 어느 정도 프로토타입을 만들어볼 수 있다.
- 간단한 수준의 애니메이션 구현이 가능하고, 간단하게 공유 링크를 생성함으로써 피드백을 주고받을 수 있다.
- 어도비 사의 프로그램이라는 점에서 포토샵, 일러스트레이터와 단축키부터 인터페이스까지 닮은 부분이 많고, 기존에 쓰던 클라우드 환경을 활용할 수 있다.
- 한국어를 공식 지원하고, Windows 환경에서도 사용할 수 있다.

3. 피그마(Figma)

2016년 9월에 정식 출시되었으며, 스케치, XD를 제치고 2021년에 UI 디자인 목적으로 가장 많이 사용되는 툴 설문조사에서 1위를 차지했다.

1) 장점

- 다른 UI 디자인 툴에 비해 '협업'을 강조함으로써 차별화를 이끌어냈다.
- 웹 브라우저 기반의 툴이기 때문에 스케치나 XD와 달리 별도의 데스크톱 애플리케이션이나 프로그램 설치가 필요 없다.
- 모든 리소스가 클라우드에 저장된다.
- 여러 사람이 동시에 아트보드를 편집할 수 있다.

2) 단점

- 인터넷 연결이 불가능하거나 피그마 서버가 다운되는 경우엔 작업 진행이 전혀 불가하다.
- 보안 관련 위험성이 존재한다.
- 한글을 입력하면 텍스트가 먹히거나 밀리는 등의 자잘한 버그가 존재한다.

이렇게 비교했을 때 피그마가 분명 단점도 존재하는 툴이지만, 별도의 프로그램 설치가 필요 없다는 부분이나 클라우드에 저장된다는 점에서 비교적 간단한 UI 디자인 작업 정도만 요구되는 현재 프로젝트에는 피그마를 사용할 계획이다. 또한 가능하다면 추후 팀원들과도 피그마를 통한 동시 편집 기능도 이용해보고 싶다.

4. 이외의 UI 디자인 툴

이외에도 인비전 스튜디오(InVision Studio), 프레이머(Framer), UX핀(UXPin), 어피니티 디자이너(Uffinity Designer) 등 다양한 소프트웨어가 존재하고, 포토샵이나 일러스트레이터를 사용하는 팀도 여전히 있다. 다만, 아이디어 및 컨셉을 화면에 구현하는 데 초점을 맞춘 로파이(Lo-Fi) 프로토타이핑에 초점을 맞춘다면 스케치, XD, 피그마가 널리 쓰인다고 한다.

하이파이(Hi-Fi) vs. 로파이(Lo-Fi)?

각각 High Fidelity, Low Fidelity의 약자이다. 로파이 프로토타입은 간단하고 기술적으로 복잡하지 않은 수준의 프로토타입으로, 아이디어 및 컨셉을 화면에 구현하는 데 초점을 맞춘다. 일반적으로 GUI 디자인이라 하면 로파이 디자인에 해당하는 것이다. 한편, 하이파이 프로토타입은 최종적으로 개발될 프로덕트와 흡사할 만큼 기능적인 수준의 프로토타입으로, 개발자와 소통을 하기 위해 정교한 인터랙션까지 고려해서 제작된다.

스케치, XD, 피그마를 사용해 레이아웃을 구성하고, 요소를 배치하는 디자인 작업은 일반적으로 로파이 프로토타이핑에 해당하는 영역이다.

[UI/UX] UI/UX란?

AS J — Wed, 23 Mar 2022 00:27:12 +0900

1. UI란?

UI는 'User Interface'의 줄임말로써, 흔히 사용자 인터페이스 디자인을 의미한다. 웹/앱 서비스 측면에서 보면 사용자가 서비스 안에서 마주 보는 대부분의 인터페이스 요소를 말한다.

서비스 내에 배치할 수 있는 여러 요소를 활용해 서비스의 특정한 기능을 구성하고, UX를 이끌어내는 역할을 하며, 특히 버튼, 아이콘, 폰트, 컬러, 레이아웃 등의 그래픽 요소를 활용한 인터페이스는 GUI(Graphic User Interface)라고도 한다.

2. UX란?

UX는 'User eXperience'의 줄임말로써, 사용자 경험 디자인을 의미한다. 서비스 측면에서는 사용자의 관점에서 이루어지는 서비스에 대한 경험을 말한다.

즉, 사용자가 서비스를 이용함에 있어서 무엇을 필요로 하고, 무엇을 겪게 되고, 그 과정에서 어떤 감정을 느끼고 행동하는지 등이 모두 UX에 포함되는 것이다.

[React] 'React'의 시작

AS J — Fri, 10 Dec 2021 12:39:58 +0900

화면 출력에 특화된 프론트엔드 프레임워크, 리액트

1. 기원

1) 누가

페이스북의 소프트웨어 엔지니어, Jordan Walke

2) 언제

- 2011년 페이스북의 뉴스피드에 첫 적용

- 2012년 인스타그램닷컴에 적용

- 2013년 5월 JSConf US에서 오픈 소스화

3) 어디서

페이스북 및 공동체

4) 왜

리액트를 개발한 Jordan Walke는 PHP용 컴포넌트 프레임워크인 XHP에서 영향을 받았다고 한다. 기존의 자바스크립트는 어떤 속성에 대해 값이 변경될 때, 그 속성에 해당하는 DOM과 요소를 찾은 다음 사용자가 정의한 규칙(함수, 이벤트 등)을 적용한다. 만약 이런 인터랙션이 자주 발생하고, 동적인 UI가 요구되는 상황에서는 이런 규칙이 엄청 많아질 것이고, 개발자는 그런 규칙과 DOM을 일일이 관리하고 수정하는 과정에서 많은 시간을 소비하게 될 것이다. 대부분의 자바스크립트 프레임워크가 자바스크립트를 통해 어떤 값이 바뀔 때, DOM과 연결하고 업데이트하는 작업을 간소화해주는 기능을 한다. 하지만 리액트는 DOM을 어떻게 업데이트 할 지 규칙을 정하는 것이 아니라 아예 날려버리고 새로운 것으로 만들어서 보여주려는 아이디어에서 시작됐다. 하지만 용량이 많은 애플리케이션에서 계속해서 없애고, 새로 만드는 과정을 반복한다면 속도가 굉장히 느릴 것이다. 리액트는 이를 Virtual DOM(가상 돔)이라는 기술을 적용함으로써 가능하게 했다.

- 기존 자바스크립트 원리와 리액트 발상: https://react.vlpt.us/basic/01-concept.html

- 가상 돔과 돔의 차이: https://github.com/FEDevelopers/tech.description/wiki/%EA%B0%80%EC%83%81-%EB%8F%94%EA%B3%BC-%EB%8F%94%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

2. 활용

우선, 현재 가장 주목 받는 프레임워크는 리액트(react), 앵귤러(angular), 뷰제이에스(vue.js) 등을 꼽을 수 있다. 앵귤러는 화면 출력, 형상 관리부터 배포까지 많은 기능을 포함한 완성형 프레임워크를 지향하고, 뷰제이에스는 가장 나중에 나오면서 다른 프레임워크의 장점을 흡수, 단점을 보완한 프레임워크이다. 하지만 현재 가장 많이 활용되는 프레임워크는 단연 리액트이다. 이는 아래 출처를 통해 다운로드 수 그래프와 개발자 수요를 확인하면 알 수 있다.

- 프레임워크 다운로드 현황: https://www.npmtrends.com/@angular/core-vs-angular-vs-react-vs-vue

- 프레임워크 개발자 수요: https://bit.ly/2Rmx1Zn

이렇게 리액트가 많이 활용되는 이유는 그만큼 장점을 갖고 있기 때문이라고 생각한다. 내가 파악한 리액트의 장점은 아래와 같다.

1) 컴포넌트(Component)라는 요소로써 화면 UI를 구성한다. 그리고 이 컴포넌트는 기존 웹의 구성 요소(HTML, CSS, JavaScript)를 각각 작성해야 하는 것이 아니라, 컴포넌트 파일 하나에 JSX(JavaScript XML) 문법으로 한 번에 작성될 수 있다는 점이 생산성과 유지 보수에서 용이하다고 판단된다.

2) 서버 사이드 렌더링과 클라이언트 사이드 렌더링을 모두 지원한다. 특히, 클라이언트 사이드 렌더링을 통해 앱 애플리케이션 같은 일정한 양식의 페이지에서 특정 항목만 자연스럽고 부드럽게 전환이 가능하도록 하기 때문에 웹 페이지 전체 리렌더링(새로고침)이 필요 없고, 더 좋은 UI/UX 제공이 가능하다.

3) 가상 돔 기술을 도입하고, 화면 출력 속도를 빠르게 한다. 기존 자바스크립트에서는 제이쿼리(jQuery)와 핸들바(handlebars)라는 라이브러리를 통해 화면을 구성했는데, 화면이 커질수록 화면을 그리는 시간이 길어지고 화면의 일부분만 수정되어도 전체를 다시 그려야 하는 단점이 있었다. 하지만 페이스북에서는 다음에 나타날 화면의 일부를 미리 그려 놓고, 변경된 화면의 일부만 수정하는 방식인 '가상 돔' 기술을 적용함으로써 화면 출력 속도를 향상시켰다.

- 서버 사이드 렌더링과 클라이언트 사이드 렌더링 추가 설명: https://oneroomtable.tistory.com/entry/서버-사이드-렌더링과-클라이언트-사이드-렌더링이란-무엇인가요

=> 이런 장점과 요소를 통해 리액트는 많은 인기를 얻고, 많은 곳에서 활용되고 있다. 개인적으로도 이런 리액트를 잘 습득하면 많은 부분에서 유용하게 활용할 수 있을 것이라 판단되어 공부하고 있다.

[Team Project] 지피지기 - 생애 첫 팀 프로젝트이자, 이어드림 중간 프로젝트

AS J — Tue, 7 Dec 2021 16:29:56 +0900

<프로젝트 개요>

기간: 2021년 11월 8일(월) ~ 2021년 12월 3일(금) (약 4주)
인원: 6명(프론트엔드 2명, 백엔드 2명, 데이터 분석 2명)
역할: 프론트엔드 담당
동기: '지피지기면 백전불태'. 적을 알고 나를 알면 백 번 싸워도 위태롭지 않다는 뜻으로, COVID-19를 알고 우리에게 끼친 영향을 알면 우리가 더 나은 가치 판단을 할 수 있을 것이라는 아이디어에서 프로젝트와 그 이름을 떠올렸습니다.
내용: 교통(서울 주요 지하철역), 문화(영화, 공연 관람), 소비(유통업체별 변화), 생활(유명 검색 포털 사이트 키워드 통계) 등에 걸친 데이터를 시각화 및 분석하여 정보를 제공하는 서비스 프로젝트입니다.

<프로젝트 특징>

프론트엔드

메인 페이지의 두 화면은 서로 위 또는 아래 드래그 한 번만으로 매끄럽게 애니메이션 효과를 보여주며 이동됩니다.
리액트의 axios 라이브러리와 API URL을 통해 데이터를 받아옵니다.
받아온 데이터를 React ApexCharts.js를 통해 그래프로써 시각화합니다.
각각의 그래프와 분석 페이지를 리액트의 Component로 만들어두고, 각각의 버튼으로 useState, 임의의 function 등을 통해 화면에서 변경될 부분반 매끄럽게 전환되도록 구현했습니다.

백엔드

Flask를 통한 서버 구축
AWS의 RDS에 관계형 데이터베이스인 MySQL을 이용하여 저장된 데이터를 프론트엔드와 데이터 분석팀에게 제공
Flask의 SQL-Alchemy와 Data serialization을 통해 데이터를 질의하고, JSON 형태로 반환하여 프론트엔드에서 원하는 형태로 데이터 제공

데이터 분석

수집된 데이터를 모두 전처리하여 로우(Row)와 컬럼(Column) 스타일 통일화
다중 회귀 분석을 통해 데이터에 대한 분석 결과 도출 및 결과 해석

<기여한 부분>

React UI Framework, React Bootstrap, React Material UI 등을 적극 이용하여, 팀원의 의견들에 부합하는 UI를 최대한 구현했습니다.
React의 useState, 임의로 생성한 function 등을 통해 사용자가 보고 싶은 그래프 페이지, 분석 페이지 등을 선택할 수 있는 버튼을 구현했습니다.
각 그래프 페이지, 분석 페이지 등을 리액트의 특성인 Component 요소로써 미리 작성해두고, 3-2에서 언급한 버튼 선택에 따라 해당 요소만 매끄럽게 전환될 수 있도록 구현했습니다.
그 외에 데이터 일부 수집 및 회의록 작성, 관리를 진행했습니다.

<아쉬웠던 점 및 배운 점>

1. 프로젝트를 진행함에 있어서 팀원과의 애자일(agile)한 협의 끝에 빠르게 올바른 툴과 라이브러리를 선택하는 것이 중요하다는 것을 느꼈습니다.

아쉬웠던 점 중 하나는 총 4주 동안 진행된 프로젝트라는 점, 특히 리액트를 사용하기로 결정했을 때 남은 기한이 약 2주였다는 점이었습니다. 해당 프로젝트에서 데이터의 시각화는 중요한 요소였고, 팀원 모두 최대한 동적인, 인터렉티브한 그래프 시각화를 우선으로 하는 것에 동의했습니다. 그래서 이에 적합한 툴을 정하기 위해 파이썬의 Plotly와 Dash, JavaScript와 Chart.js 등을 조사해보면서 프로젝트의 초반 일주일을 보냈습니다.(어떻게 보면 팀원 모두 프로젝트가 처음이었고, 데이터 수집부터 시각화까지 모든 과정을 팀원 모두가 경험해보자는 취지에서 진행했기 때문에 속도 또한 빠르지 못했습니다.) 그렇게 각자 알아보고 공부해보며 1주차를 큰 성과 없이 보내고, 2주차에서야 각자 역할을 나누고 담당하여 진행하기로 했습니다.

그리고 2주차가 끝날 즈음에서는 파이썬의 Plotly나 JS의 Chart.js보다는 SPA(Single Page Application), Component 특성을 통해 그래프 뿐만 아니라 웹 페이지 자체도 매끄럽게 전환되며 좋은 UX를 줄 수 있다고 판단되는 '리액트(React)'를 사용하기로 결정했습니다. 프론트엔드 2명 모두가 기존에 HTML, CSS, JavaScript 등에 대해 아주 기초적인 지식만 있는 상태에서 리액트를 새로 학습하고 적용하기란 쉽지 않았습니다. 그래서 3주차에는 마감 기한을 맞추는 것이 최우선이라 판단하고 구현에 초점을 맞추어 진행했습니다. 그 과정에서 아래에 언급되는 부분들처럼 리액트에서 추구하는, 보편적인, 바람직한 사용 방식과는 다르게 사용됐을 것이라 판단되는 부분들이 아쉬웠습니다.

2. 리액트의 Material UI, Bootstrap, UI Framework와 useState, Component 특성 외에도 존재하는 유용한 특성과 라이브러리(useEffect, hook, Redux, Axios 등)를 익히거나 올바르게 사용해보지 못한 점이 아쉬웠습니다.

기존에 틀이 이미 거의 구현된 UI Framework의 코드에 Material UI, Bootstrap 등을 통해 요소를 추가함으로써 프로젝트에 필요한 대부분의 UI는 구현할 수 있었습니다. 추가로 useState와 간단한 JS 문법의 함수를 통해 Component를 변경하는 버튼도 구현할 수 있었습니다. 하지만 이 UI를 모두 직접 이해하고 구성한 것이 아니라, 기존의 틀 덕분에 구성할 수 있었다는 점이 아쉬웠습니다.

또한, Axios를 통해 데이터를 API로부터 직접 받아오고 이를 그래프로써 시각화하기 위해 데이터를 처리하는 것을 직접 구현해보지 못한 점도 많이 아쉬웠습니다. 대부분의 서비스에서 프론트엔드는 필수적으로 백엔드 혹은 API로부터 데이터를 주고 받고, 이를 이용할 줄 알아야 한다고 생각합니다. 하지만 이번 프로젝트 기간 동안 useEffect나 Axios 등을 응용할 수 있을 정도로 이해하지는 못하면서 아쉬움을 많이 느꼈고, 추후에 리액트를 다시 본격적으로 공부해야겠다고 다짐하게 됐습니다.

3. 위에서 아쉬웠던 점이 누적되면서 결국 리액트의 Component 속성을 제대로 응용하지 못했고, 리액트 영역의 용량이 커지는 아쉬움을 남겼습니다.

리액트에서는 같거나 비슷한 양식의 페이지들을 Component라는 일종의 틀로써 구현하고, 각 상황에 따라, 받는 데이터에 따라 보여지는 부분만이 변경되는 유연함을 갖고 있습니다. 이 부분은 리액트의 장점인데, 데이터를 처리에 미흡했던 저는 같은 양식의 페이지라도 일일이 해당되는 내용을 포함한 컴포넌트 파일로 생성했습니다. 그리고 그저 경우에 따라 조건문을 통해 보여지는 컴포넌트 파일 자체가 변경되는 방식을 취했습니다. 다행히 변경되는 컴포넌트의 개수가 기한 내에 반복 제작해낼 수 있는 양이었고, 내용 또한 실시간으로 변경되는 것이 아니었기 때문에 프로젝트를 의도대로 구현하는 것에는 문제가 없었습니다. 하지만 만약 이 프로젝트에서 제가 맡은 부분이 실시간 데이터를 받아서 보여주는 부분을 구현하는 것이고, 그 양이 정말 방대한 양이었다면 올바르게 구현해내지 못했을 것이라는 걱정과 의심을 느꼈습니다. 그리고 그렇게 됐다면 결국 팀에게도 피해를 끼쳤을 것입니다. 이런 부분에서 제가 선택한 툴과 라이브러리를 올바르게 이해하고, 기한 내에 구현할 줄 아는 개발자가 좋은 개발자일 것이라고도 생각했습니다.

<프로젝트 결과, UI 및 React 코드>

https://github.com/sjan137/Jipi-jigi