devrun_ryan.log

rendering_SSR

Wed, 05 Apr 2023 07:43:46 GMT

SSR(Server-Side Rendering)은 클라이언트 측에서 데이터를 받아와 렌더링하는 것이 아닌 클라이언트에서 요청시 서버 측에서 HTML 파일을 렌더링하여 클라이언트에게 보내주는 방식입니다. 이 방식은 SPA(Single-Page Application)에서 발생하는 초기 로딩 속도와 검색 엔진 최적화(SEO) 문제를 해결하기 위해 사용됩니다.

장점

초기 로딩 속도 개선 SSR을 적용하면 서버에서 HTML 파일을 렌더링하므로 초기 로딩 속도가 빨라집니다. SPA에서는 클라이언트에서 JavaScript 파일을 다운로드하고 실행한 후에 데이터를 받아와서 렌더링하기 때문에 초기 로딩 속도가 느립니다. 하지만 SSR을 사용하면 서버에서 HTML 파일을 렌더링하므로 초기 로딩 속도가 빨라집니다.
SEO SSR을 적용하면 검색 엔진 최적화 문제도 해결할 수 있습니다. 검색 엔진은 페이지의 HTML 코드를 크롤링하여 검색 결과에 반영합니다. SPA에서는 HTML 코드가 클라이언트에서 동적으로 생성되기 때문에 검색 엔진이 크롤링하지 못할 수 있습니다. 하지만 SSR을 사용하면 서버에서 HTML 파일을 렌더링하므로 검색 엔진이 크롤링할 수 있는 HTML 코드를 제공할 수 있습니다.
보안 CSR은 브라우저(클라이언트)에서 js를 통해 렌더링을 하게 되는데, 그 과정에서 서버와 통신이 발생한 경우 클라아언트에서 노출이 될 수 있습니다. 그러나, SSR은 서버에서 렌더링한 HTML을 전달해주기 때문에 브라우저(클라이언트)에 서버와의 통신과 관련된 보안적인 내용에 대해 노출될 가능성이 적다고 볼 수 있습니다. console.log를 할 때 서버에서 실행되는 환경일 경우 브라우저 콘솔이 아닌 terminal에 출력되기 때문에 사용자가 보지 않아도 되는 콘솔내용에 대해 노출되지 않을 수도 있을 것 같습니다.
SSG, ISR과 다르게 요청할 때마다 서버에서 렌더링하기 때문에 실시간 데이터를 사용해서 반영할 수 있고, 사용자별 필요한 데이터를 사용할 수 있다는 것도 장점이 될 수 있다고 생각합니다.
js 없어도 렌더링 됨 서버에서 받은 html로 초기 렌더링 되기 때문에 js를 비활성화 하더라도 화면에 렌더링이 가능합니다.

단점

속도 요청할 때마다 서버에서 렌더링해서 전달해주기 때문에, 서버에 과부하가 걸릴 수 있으며 비교적 느릴 수 있다는 단점이 있습니다. (사용자가 많아질수록 사이트에 접속하는 시간이 오래 걸릴수 있습니다.)
캐시 요청할 때마다 렌더링을 하게 되기 때문에, CDN에 캐시가 안된다는 단점이 있습니다. nextjs 프레임워크를 사용할 경우 일정부분은 개선이 될 수도 있다고 생각은 됩니다.
서버환경 js의 경우 서버는 Node.js 환경에서 동작하기 때문에 Node.js와 서버에 대한 이해가 필요할 수 있으며, 브라우저API(window, event(click, change, ...), 기타 등등...)를 사용하지 못한다는 것을 고려해야 될 수 있습니다.
hydrate, css-in-js 서버에서 만든 html로 먼저 화면에 표시되기 때문에 사용자가 초기에 화면을 보는 속도는 빠를수는 있습니다. 그러나, 이후 css js 파일을 다운로드 받아 실행하고, 인터렉션이 가능하게 되는 구조(hydrate)에서 오는 단점도 있다고 생각됩니다.
- html이 화면에 렌더링은 되지만, js가 실행되지 않을 경우 클릭과 같은 사용자 인터렉션(상호작용)에 반응하지 못합니다. 추가로, 요청할 때 서버에서 html을 만들어서 주기 때문에, 서버에서 html을 받기 이전까지 화면에 표시되지 않아 깜빡이는 현상이 발생할 수도 있습니다.
- styled-components와 같은 css-in-js를 통해 스타일을 적용할 경우, js가 비활성화되있을 경우 적용되지 않으며, js가 활성화 되있어도 초기에는 html css로 적용되다가, 이후 js로 styled-components가 실행될 경우 해당 스타일이 적용되기 때문에 시간이 지난뒤 스타일이 적용되면서 발생하는 문제가 있을 수 있습니다(Cumulative Layout Shift 등)
- 서버에서 렌더링할 때 css-in-js를 적용해서 html을 전달해줄 수 있지만, 결국 서버에서 처리하기 때문에 이로 인한 비용증가 및 관련 문제도 고려하는 것이 필요할 수 있습니다.

요약하자면, SSR은 CSR의 초기 로딩 속도와 검색 엔진 최적화 문제를 해결하기 위해 사용되는 방식이라고 생각됩니다. SSR의 장점이 매력적인 것은 맞지만, 단점도 명확하게 존재하기 때문에 사용하는 목적에 따라 어떤 렌더링 방식을 사용할지에 대해 결정하는 것도 중요하다고 생각됩니다.

nextjs 프레임워크를 이용한다면 페이지 단위로(13버전에서는 컴포넌트 단위로) 다른 렌더링 방식을 적용(하이브리드 웹 앱)해서 만들 수 있기 때문에, 이를 이용해서 만들 경우에도 각각의 렌더링 방식에 대해 이해하고 있는 것이 도움이 될 수 있다고 생각됩니다.

rendering_CSR

Wed, 22 Mar 2023 07:53:54 GMT

CSR

Client Side Rendering

브라우저에 표기(렌더링)하기 위한 모든 코드들을 클라이언트측에서 다운로드 받고, 클라이언트 측에서 코드를 실행하고 분석해서 표기하는 것

Client Side: 렌더링하는 주체자가 클라이언트이며, 웹 어플리케이션에서는 브라우저를 의미한다.

Client -> request -> Server
로딩 화면
Server -> HTML -> Client body의 내용이 없는 HTML (아무것도 없는 HTML) vite react app 예시
```
 
 
 
 Vite + React


 
 
```
HTML이 렌더링 되지만 내용이 없기 때문에 빈 화면(UI가 없음)을 보게 됨
React 라이브러리 소스 파일 및 js 소스 파일 로드(컴포넌트 포함)
React 라이브러리 로드 -> root요소에 index(루트) 컴포넌트를 연결해서 렌더링
사용자가 paint된 화면을 보게 됨

장점

한번 로딩 되면, 빠른 UX 제공
- 1개의 페이지(HTML 파일 1개)
- 사용자의 요청에 따라 Ajax를 통해 필요한 부분만 변경해서 렌더링
서버의 부하가 작음

단점

페이지 로딩 시간(Time To View, First Contentful Paint)이 길다
브라우저 설정에서 js를 비활성화할 경우 웹 어플리케이션이 동작하지 않고, 사용자도 화면을 볼 수 없다
SEO 최적화가 힘들다
보안에 취약하다(클라이언트에서 모든 코드를 받아서 클라이언트에서 실행 -> 페이지를 표시하기 위한 데이터를 서버에서 받아오기 위해 필요한 키등이 노출되기 때문)
CDN(Content Delivery Network)에 캐시가 안된다

DesignPattern_Container/Presentational

Wed, 15 Mar 2023 03:49:06 GMT

React에서 관심사의 분리(SoC) 를 강제하는 방법은 Container/Presentational Pattern을 이용하는 방법이 있다. 이 를 통해 비즈니스 로직에서 뷰를 분리해낼 수 있다.

6개의 강아지 사진을 다운로드받아 화면에 렌더하는 앱을 만든다고 가정해 보자.

이상적으로는 이 프로세스를 아래 두가지로 분리하여 관심사의 분리를 강제하고 싶다.

Presentational Components: 데이터가 어떻게 사용자에게 보여질 지에 대해서만 다루는 컴포넌트. 예제에서는 강아지 사진의 목록을 렌더링하는 부분이다.
Container Components: 어떤 데이터가 보여질 지에 대해 다루는 컴포넌트. 예제에서는 강아지 사진들을 다운로드한다.

강아지 사진을 다운로드하는것은 비즈니스 로직의 역할이고. 이미지를 보여주는 것은 뷰의 역할이다.

Presentational Component

Presentational 컴포넌트는 props를 통해 데이터를 받는다. 이 컴포넌트의 주요 기능은 받은 데이터를 화면에 표현하는것이며 그 목적을 위해 스타일시트를 포함한다. 데이터는 건드리지 않는다.

아래 강아지 사진을 출력하는 예제를 확인해 보자. 강아지 사진을 렌더링 할 때. 단순히 각 이미지들을 API로부터 다운로드 받고 화면에 렌더링 하는데. 그렇게 하지 말고. 이미지들을 props를 통해 받아 화면에 그리는 함수형 컴포넌트만 만드는 것이다.

import React from "react";

export default function DogImages({ dogs }) {
  return dogs.map((dog, i) => );
}

여기서 DogImages 컴포넌트는 Presentational 컴포넌트이다. Presentational 컴포넌트는 UI 변경을 위한 상태 외에는 상태를 갖지 않는다. prop을 통해 받은 데이터는 Presentational 컴포넌트에 의해 수정되지 않는다.

Presentational 컴포넌트는 Container 컴포넌트로부터 데이터를 받는다.

Container 컴포넌트

Container 컴포넌트의 주요 기능은 Presentational 컴포넌트에 데이터를 전달하는 것이다. Container 컴포넌트 자체는 화면에 아무것도 렌더링하지 않는다. Container 컴포넌트는 아무것도 화면에 그리지 않으니 스타일시트도 포함하지 않는다.

아래 예제에서 강아지 사진 목록을 DogImages 컴포넌트에 전달하기 위해 Container 컴포넌트를 만들었다. 만들어진 Container 컴포넌트는 외부 API로부터 강아지 이미지를 다운로드하고 Presentational 컴포넌트인 DogImages 컴포넌트에게 전달하고 있다.

import React from "react";
import DogImages from "./DogImages";

export default class DogImagesContainer extends React.Component {
  constructor() {
    super();
    this.state = {
      dogs: []
    };
  }

  componentDidMount() {
    fetch("https://dog.ceo/api/breed/labrador/images/random/6")
      .then(res => res.json())
      .then(({ message }) => this.setState({ dogs: message }));
  }

  render() {
    return ;
  }
}

위의 두 컴포넌트를 조합하면 비즈니스 로직과 뷰를 분리하고 있다.

Hooks

대개 Container/Presentational 패턴은 React Hooks로 대체 가능하다. React 에 Hooks가 추가되면서 Container 컴포넌트 없이도 stateless 컴포넌트를 쉽게 만들 수 있게 되었다.

DogImagesContainer 컴포넌트에 있는 데이터 로드 코드를 아래와 같이 커스텀 훅으로 만들 수 있다.

export default function useDogImages() {
  const [dogs, setDogs] = useState([])

  useEffect(() => {
    fetch('https://dog.ceo/api/breed/labrador/images/random/6')
      .then(res => res.json())
      .then(({ message }) => setDogs(message))
  }, [])

  return dogs
}

위의 훅을 사용하면 데이터를 받아오기 위해 DogImagesContainer 컴포넌트를 사용할 필요가 없다. 대신 Presentational 컴포넌트인 DogImages 에서 훅을 직접 호출해 사용하면 된다.

import React from "react";
import useDogImages from "./useDogImages";

export default function DogImages() {
  const dogs = useDogImages();

  return dogs.map((dog, i) => );
}

useDogImages 훅을 사용하여 Container/Presentational 패턴을 사용한 것과 같이 비즈니스 로직과 뷰를 분리했다. DogImages 는 단순히 훅에서 반환된 값을 수정없이 사용하면 된다.

훅은 이 장에서 소개한 패턴처럼 비즈니스 로직과 뷰를 쉽게 분리할 수 있게 해주고. 불필요한 Container 래핑을 줄일 수 있게 해 준다.

장점

Container/Presentational 패턴은 여러 장점들을 가지고 있다.

해당 패턴을 활용하면 자연스럽게 관심사의 분리를 구현하게 된다. Presentational 컴포넌트는 UI를 담당하는 순수함수로 작성하게 되는 반면 Container 컴포넌트는 상태와 기타 데이터를 책임지게 된다.

Presentational 컴포넌트는 데이터 변경 없이 화면에 출력할 수 있으므로 앱의 여러 곳에서 다양한 목적으로 재사용할 수 있다.

Presentational 컴포넌트는 앱의 비즈니스 로직을 수정하지 않으므로 코드베이스에 대한 이해가 깊지 않은 개발자더라도 쉽게 수정이 가능하다. 공통으로 쓰이는 Presentational 컴포넌트가 디자인의 요구사항에 따라 수정하면 앱 전체에서 반영된다.

Presentational 컴포넌트는 테스트하기도 쉽다. 일반적으로 순수함수로 구현되므로 전체 목 데이터 스토어를 만들 필요 없이 요구하는 데이터만 인자로 넘겨주면 된다.

단점

Container/Presentational 패턴은 비즈니스 로직과 렌더링 로직을 쉽게 분리할 수 있지만 훅을 활용하면 클래스형 컴포넌트를 사용하지 않고도, 또 이 패턴을 따르지 않아도 같은 효과를 볼 수 있다. 참고로 지금은 상태를 가진 컴포넌트도 함수형으로 만들 수 있다.

훅을 사용하더라도 이 패턴을 사용할 수는 있지만 너무 작은 규모의 앱에서는 오버엔지니어링 일 수 있다.

참조 Presentational and Container Components - Dan Abramov

TIL_Docker(도커)

Wed, 08 Feb 2023 07:31:30 GMT

출처

해당 글의 출처는 fastcampus의 프론트엔드 웹 개발의 모든 것 강의임을 알려드립니다. https://fastcampus.co.kr/dev_online_fesignature

도커를 학습하고자 한 이유

실제 기업에서 개발을 하거나 부트 캠프 과정중에 협업 프로젝트를 할 경우 어느정도 이해를 하고 사용할 줄 알아야 된다는 필요성을 느껴서 학습하게 되었습니다. (요즘 도커를 사용하지 않는 곳이 거의 없다고 듣기도 해서...)

도커를 사용하는 이유

어떠한 프로그램을 다운 받는 과정을 굉장히 간단하게 만들기 위해서이다.

도커 없이 프로그램을 받을 때 원래 프로그램을 다운 받고 실행하는 순서 인스톨러 내려받기 => 인스톨러 실행 => 프로그램 설치 완료
- 실제로 프로그램을 설치하는 과정 중에 갖고 있는 서버, 패키지 버전, 운영체제 등에 따라 프로그램을 설치하는 과정 중에 많은 에러 발생
- 또한 설치 과정이 다소 복잡함

도커 없이 프로그램을 내려받을 때 예시(Redis)

Redis 홈페이지로 이동 => redis.io

wget이 없어서 에러가 발생하기 때문에, wget을 받은 후 다시 Redis를 받아야 한다.

이와 같이 어떤 특정 프로그램을 받을 때 거기에 맞는 부수적인 것들도 계속 받으면서 설치하는 과정이 있을 수 있기 때문에, 설치하는 과정이 복잡해지고 에러도 많이 생기게 된다.

도커를 사용해서 프로그램을 내려받을 때 예시(Redis)

docker run -it redis => 다운로드 끝

이와 같이 도커를 이용하여 프로그램을 설치하면 예상치 못한 에러도 덜 발생하며, 설치하는 과정도 훨씬 간단해진다.

도커란 무엇인가?

컨테이너를 사용하여 응용프로그램을 더 쉽게 만들고, 배포하고 실행할 수 있도록 설계된 도구이며, 컨테이너 기반의 오픈소스 가상화 플랫폼이며 생태계이다.

일반적인 컨테이너의 개념

위와 같이 컨테이너에 물건을 넣고 다양한 운송수단으로 쉽게 옮길 수 있다.

서버에서 컨테이너의 개념

위와 같이 컨테이너 안에 다양한 프로그램, 실행환경을 컨테이너로 추상화 하고 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해준다. (일반 컨테이너의 개념에서 물건을 손쉽게 운송 해주는 것 처럼) 프로그램을 손쉽게 이동,배포,관리를 할 수 있게 해준다. 또한, AWS, Azure, Google cloud 등 어디에서든 실행 가능하게 해준다.

API_Mocking_library[Mock Service Worker]

Wed, 01 Feb 2023 07:43:48 GMT

reference

kakao Tech Blog:Mocking으로 생산성까지 챙기는 FE 웹개발

프론트엔드 개발 과정의 현실

전체 개발 프로세스 중 요구 사항 분석 및 기획, 백엔드 개발, 프론트엔드 개발에 이르는 각각의 개발 과정은 크게 겹치지 않고 진행되는 것이 가장 이상적일 것 입니다. 왜냐하면, 개발 과정에서 도출되는 요구 사항이나 사용 가능한 인터페이스에 변경이 있으면, 각 단계별 의존성에 따라 다시 작업해야 하는 경우가 발생하기 때문입니다.

따라서, 개발과정이 다음과 같이만 진행된다면 요구 사항과 제공된 스펙에 따라 순조롭게 프론트엔드 개발을 진행할 수 있습니다.

하지만 현실은, 많은 시간을 프론트엔드와 백엔드를 병행하여 개발하게 되는 경우가 많습니다.

이때 프론트엔드에서 백엔드의 API를 활용해야 하는 것처럼, 백엔드 개발에 종속적인 부분이 있다면, 해당 부분이 완성되기 전까지는 프론트엔드에서 개발을 진행할 수 없고, 그 부분이 진행된 후에나 개발이 가능합니다. 심지어 추가적인 수정사항이 발생했는데 백엔드 개발에 의존성이 있는 부분에 수정이 필요하다면, 이러한 비효율적인 과정을 반복 진행할 수밖에 없습니다.

만약, 이러한 부분을 해결해줄 수 있는 대안이 없다면 심할 경우 아래와 같은 상황이 펼쳐질 수 있다고 개인적으로 생각됩니다.

기획자: ~작업은 어떻게 진행 중이신가요? 프론트엔드 개발자: 그게... 아직 API가 준비되지 않아서 다음주 까지 기달려야 합니다.

프론트엔드 개발자: 백엔드 때문에 프론트 개발 진행이 안되네요... 🤬 (업무와 밀접한 관련이 있고 일정 압박등으로 인해 스트레스가 심한 경우 욕설이 나올 것 같다고 예상됨) 백엔드 개발자: 그럼 당신이 백엔드 개발을 하시던가요! 🤬 (백엔드 개발자도 개발자만의 사정이 있기 때문에 협업이 어려워 질 것 이라 예상됨)

제가 실제 협업에서 일해보지는 않았지만, 협업을 할 때 위와 관련된 상황에 대해 생각해보지 않았다면 협업하면서 일하는 것이 어려울 것 같다고 생각됩니다. 또한, 다툼이 있었다면 백엔드 부서와의 관계도 좋지 않게 될 것 같고요. mocking을 활용해서 개발을 진행하지 않으면 시간이 계속 지체될 것 같다고 생각됩니다.

mock(mocking)

kakao Tech Blog 글에 의하면 기존에도 mocking을 통해 사전 개발을 진행했었고 그 것에 대한 장단점은 아래와 같다고 합니다.

화면에 필요한 데이터의 상태를 애플리케이션의 내부 로직에 직접 Mocking 해서 필요한 화면에 붙이는 방식

장점: 구현이 쉬워 빠르게 적용할 수 있다
단점: 애플리케이션의 서비스 로직에 직접 Mocking을 해야 해 애플리케이션 서비스 로직을 수정해야 하고, HTTP 메소드와 네트워크의 응답 상태에 따라 각각 대응하기가 쉽지 않다.

Mock 서버를 별도로 만드는 방법

장점: 웹 애플리케이션의 서비스 로직을 수정하지 않아도 된다.
단점: 데이터 상태 구현에는 직접 Mocking 대비 비용 및 공수가 상당히 들어가며, 이를 로컬이 아닌 누군가에게 공유해야 한다면, Mock 서버를 원격으로 제공하기 위한 추가 환경 구성 작업 등에도 적지 않은 공수가 들어 효율적이지 않다.

기존 Mocking의 또 다른 문제점

각 화면에 대한 테스팅 및 디버깅 시에 어려움이 발생한다.
결과물을 확인하고자 하는 인원이 담당 프론트엔드 개발자가 아니라면, 예를 들어 에러 화면을 보려고 해도 크롬 개발자 도구가 요청을 블록 처리할 가능성이 높아 특정 상태의 화면을 다른 사람들에게 공유하기가 어렵고, 실제 API 스펙처럼 발생하는 상황을 모의하기가 쉽지 않다.
대기, 로딩, 에러 등 API의 응답 상태에 따른 여러 가지 구현을 가지고 있을 경우, 각 단위 개발은 어떻게 진행한다고 하더라도 실제 화면을 구성하기 위한 구현 단계에서는 각 케이스별로 임의의 상태를 만들어 보면서 개발하거나 그 자체를 디버깅하기에 어려움이 있다.

위를 종합하면, 협업하면서 원활히 개발을 진행하기 위해 필요한 Mocking의 수준은 실제 API를 사용하는 것처럼 네트워크 수준에서 Mocking하는 것입니다. 이와 같은 고민을 가지고 찾아보던 중 MSW(Mock Service Worker, 네트워크 요청 과정에서 Request에 대한 Mocking이 가능)를 알게 되었고 추가적으로 카카오 기술 블로그 글도 접하게 되었습니다.

MSW?

https://mswjs.io

MSW는 Mock Service Worker의 약자
서버의 네트워크 요청을 가로채서 모의 응답(Mocked Response)을 보내주는 역할을 하는 API Mocking 라이브러리
Mock 서버를 구축하지 않아도 API를 네트워크 수준에서 Mocking 할 수 있음
Service Worker를 통해 HTTP 요청을 가로채기 때문에 API Mocking이 가능함

service worker

Service Worker는 웹 애플리케이션의 메인 스레드와 분리된 별도의 백그라운드 스레드에서 실행시킬 수 있는 기술 중 하나이며, Service Worker 덕분에 애플리케이션의 UI Block 없이 연산을 처리할 수 있습니다.

이러한 특징으로 인해, Service Worker는 다음과 같은 기능에 많이 사용되고 있습니다.

네트워크가 원활할 때 동기화를 시켜주는 백그라운드 동기화 기능이나, 높은 비용의 계산을 처리할 때 또는 푸시 이벤트를 생성할 때 주로 사용됨
MSW의 동작 방식과 관계되어 있는, 네트워크 요청을 가로채는 행위도 수행할 수 있음
- Service Worker가 애플리케이션과 서버 사이에서 Request를 가로채서 직접 Fetch에 대한 컨트롤도 할 수 있기 때문에 색다른 작업이 가능해짐
- 예를 들어, HTTP Request와 Response를 보고 캐싱 처리를 한다든지, 필요하다면 로깅을 한다든지 하는 여러 가지 새로운 동작을 만들어 낼 수 있음
- MSW도 이 과정을 통해서 Request를 가로채서 Response를 Mocking 하는 원리를 사용함

Service Worker의 사용이 제한되는 경우도 있습니다.

Service Worker는 대부분의 모던 브라우저에서 지원하고 있으나, IE와 같은 일부 브라우저에서는 지원하고 있지 않음
기본적으로 localhost가 아닌 환경이라면 HTTPS 보안 프로토콜 환경이 필요함
- Service Worker는 중간에서 네트워크로 연결을 가로채고 조작할 수 있는 강력한 기능을 갖고 있기 때문에, Service Worker에서는 HTTPS가 기본적으로 제공되는 환경에서만 사용할 수 있음

즉, MSW는 Service Worker를 기반으로 모의 API를 만들어내기 때문에 다른 프론트엔드에서 사용하는 수많은 라이브러리나 프레임워크에 종속적이지 않고 호환성에 문제없이 동작합니다.

동작 원리

브라우저에 service worker 설치
설치 이후부터는 브라우저에서 실제 이루어지는 요청을 service worker가 가로챔
service worker에서는 해당하는 실제 요청을 복사해서 MSW에게 해당 요청과 일치하는 모의 응답을 제공받고, 이를 브라우저에 그대로 전달

이러한 과정을 통해서, 실제 서버 존재 여부와 상관없이 실제 요청으로 이어지지 않고 예상할 수 있는 요청에 대해 Mocking이 가능해집니다. 이렇게 Mocking이 가능해지면 API가 아직 준비되지 않았어도 다음과 같은 개발 방식을 선택할 수 있습니다.

MSW를 활용한 개발 방식

기획자가 요구 사항을 전달
프론트엔드 개발자와 백엔드 개발자가 API 스펙을 합의하고, 백엔드 개발자는 프론트엔드 개발자에게 API의 스펙을 제공
프론트엔드 개발자는 MSW를 통해 네트워크 레벨에서의 Mocking을 진행한 후, 애플리케이션을 개발

API 없이도 프론트엔드 개발자는 높은 완성도를 갖고 있는 수준에서 기획자와 미리 프론트엔드 애플리케이션을 확인하며 피드백을 주고받고, 그 사이 백엔드 개발자는 API 개발을 진행합니다. 이후 백엔드 개발자가 API를 제공하면, 프론트엔드 개발자는 별다른 작업 없이 MSW를 스위치 오프(NODE_ENV 설정)만 하면 Production으로 배포할 수 있는 형태의 개발 과정을 통해 개발을 진행할 수 있습니다.

MSW는 디버깅이 필요한 상황에서도 좋은 시너지를 만들어 낼 수 있습니다.

예를 들어, 특정 API 응답을 기준으로 에러가 발생해 디버깅이 필요한 상황이라면, 기존 서비스 로직을 전혀 건드리지 않고 오로지 MSW에서 Mocking을 만들어 내서 쉽게 디버깅할 수 있습니다.

더 나아가, 이러한 장점은 기획자 등의 다른 누군가에게 각 화면을 공유하고 피드백을 받아야 하는 상황이 발생했을 때에도, 추가적으로 MSW에서 해당 상황을 만들어낼 수 있도록 작업을 해 둔다면 별다른 서비스 로직의 수정 없이도 MSW를 통해 제공이 가능해집니다.

프론트엔드 개발 시 MSW 활용을 통해 얻을 수 있는 장점

낮은 진입장벽으로 빠른 적용이 가능
별도의 환경 없이 네트워크 요청에 대한 모의 가능
API에 종속성 없이 완성도 높은 수준의 사전 개발 가능
네트워크 상태에 따른 디버깅을 위해 활용 가능

TIL_옵저버 패턴

Wed, 25 Jan 2023 06:25:55 GMT

참고 사이트

멘토님이 추천해주신 디자인 패턴 사이트 중에서 평소 알고 싶었던 옵저버 패턴에 대해서 학습해보았습니다.

갑자기 스타크래프트 옵저버가 생각나서... 이 옵저버는 아닙니다 (이 개그에 불쾌감을 느끼신 분들이 있으시다면 사과의 말씀 드립니다...)

Observer 패턴

Observable을 활용해 Subscriber에게 이벤트 발생을 알린다

Observer 구독하는 주체
Observable 구독 가능한 객체
이벤트가 발생할 때마다 Observable은 모든 Observer에게 이벤트를 전파한다

Observable 객체

Observable 객체는 (보통) 3가지 주요 특징을 포함한다.

observers 이벤트가 발생할 때마다 전파할 Observer들의 배열
subscribe() Observer를 Observer 배열에 추가한다
unsubscribe() Observer배열에서 Observer를 제거한다
notify() 등록된 모든 Observer들에게 이벤트를 전파한다

class Observable {
  constructor() {
    this.observers = []
  }

  subscribe(func) {
    this.observers.push(func)
  }

  unsubscribe(func) {
    this.observers = this.observers.filter(observer => observer !== func)
  }

  notify(data) {
    this.observers.forEach(observer => observer(data))
  }
}

subscribe 메서드를 통해 Observer를 등록하고, unsubscribe를 통해 등록을 해지할 수 있다. notify 메서드를 통해 모든 Observer에게 이벤트를 전파할 수 있다.

Observable 객체를 활용해보기

리액트

사용자가 Button을 클릭하거나 Switch 를 토글할 때 타임스탬프를 로깅하고자 하며, 이벤트 발생시마다 토스트 알림을 화면에 노출하려고 한다.

구현해야 되는 로직은

사용자가 handleClick 또는 handleToggle 함수를 호출할 때 마다 핸들러는 Observable의 notify를 호출
notify 메서드는 등록된 모든 Observer들에게 handleClick혹은 handleToggle에서 전달된 데이터를 포함한 이벤트를 전파

와 같다.

import { ToastContainer, toast } from 'react-toastify'

function logger(data) {
  console.log(`${Date.now()} ${data}`)
}

function toastify(data) {
  toast(data)
}

observable.subscribe(logger)
observable.subscribe(toastify)

export default function App() {
  function handleClick() {
    observable.notify('User clicked button!')
  }

  function handleToggle() {
    observable.notify('User toggled switch!')
  }

  return (
    
      
      } />
      
    
  )
}

Observable의 subscribe 메서드를 사용해서 logger, toastify 함수를 연결해서 Observer로서 작동할 수 있도록 해준다. 이벤트가 발생할 때 마다 logger, toastify 함수는 알림을 받게 되며, handleClick과 handleToggle 이벤트 핸들러에서 notify를 호출하는 것을 통해 이벤트를 전파한다. 이 때 Observer에서 필요한 데이터를 인자로 전달한다.

전체 플로우를 살펴보면 아래와 같다.

handleClick과 handleToggle이 Observable의 notify를 호출 => 이를 구독하고 있던 Observer (Observers배열) logger와 toastify함수는 이 이벤트를 받아서 특정 동작을 수행한다. 앱 내에서 인터렉션(상호작용)이 발생하는 동안 logger와 toastify는 notify의 호출로부터 이벤트를 계속 받을 수 있다.

활용할 수 있는 사례

Observer 패턴은 다양하게 활용할 수 있지만 비동기 호출이나 이벤트 기반 데이터를 처리할 때 매우 유용하다. 만약 어떤 컴포넌트가 특정 데이터의 다운로드 완료 알림을 받기 원하거나, 사용자가 메시지 보드에 새로운 메시지를 게시했을 때 모든 멤버가 알림을 받거나 하는 등의 상황을 말한다.

RxJS

RxJS는 Observer 패턴을 구현한 유명 오픈소스 라이브러리이다

ReactiveX 는 Observer 패턴, 이터레이터 패턴, 함수형 프로그래밍을 조합하여 이벤트의 순서를 이상적으로 관리할 수 있다.

RxJS를 사용하면 Observable과 Observer(Subscriber)를 만들어낼 수 있다. 아래 예제는 공식 문서에 소개된 것으로 사용자가 문서를 드래그 중인지 아닌지 콘솔에 출력해준다.

RxJS는 이것 말고도 Observer 패턴에 대한 매우 많은 빌트인 기능들을 제공한다.

Observer 패턴의 장점과 단점

장점

Observer 패턴을 사용하는 것도 관심사의 분리와 단일 책임의 원칙을 강제하기 위한 좋은 방법이다. Observer 객체는 Observable 객체와 강결합되어있지 않고 언제든지 분리될 수 있다. Observable 객체는 이벤트 모니터링의 역할을 갖고. Observer는 받은 데이터를 처리하는 역할을 갖게 된다.

단점

Observer가 복잡해지면 모든 Observer들에 알림을 전파하는 데 성능 이슈가 발생할 수 있다.

참조

:empty 가상 선택자 활용해보기

Wed, 18 Jan 2023 09:03:11 GMT

:empty를 알게된 계기

개인적으로 과제등을 할 때 로딩처리에 대한 구현을 css로 한 적이 있는데, 처음에는 아래처럼 개별적으로 loading에 대한 클래스를 통해 구현했었습니다.

.movie-title {
  font-size: 3rem;
  &.loading {
    height: 3rem;
    background-color: vars.$background-color--pulse;
    animation: pulse 1s infinite alternate;
  }
}

데이터를 가져오는 동안에는 loading클래스를 삽입하고, 데이터를 가져오는 것이 완료되면 loading클래스를 제거하는 방식으로 구현은 가능했습니다. 좀 더 편하게 적용할 수 있는 방법이 있는지 생각하던 중 저는 아래와 같은 고민을 하게 되었습니다.

마우스를 올렸을 때 :hover 가상 클래스 선택자를 활용할 수 있는 것처럼, 빈 요소에 대해서 활용할 수 있는 css 선택자가 있을까?

이후 mdn에서 css 가상 선택자에 대해서 살펴보던 중 :empty 를 접하게 되었고, 실제로 활용할 수 있는지 테스트하게 되었습니다

:empty

https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-classes

mdn 에서는 :empty 를 아래와 같이 설명하고 있습니다.

The :empty CSS pseudo-class represents any element that has no children. Children can be either element nodes or text (including whitespace). Comments, processing instructions, and CSS content do not affect whether an element is considered empty.

짧은 영어 실력으로 요약해보면, '자식이 없는 요소(element that has no children)를 의미한다'라고 할 수 있을 것 같습니다.

즉, 위와 같이 요소는 있지만, 하위 자식들이 없어 빈 요소로 표현될 수 있는 경우를 의미한다고 생각합니다.

적용해보기

.movie-title {
  font-size: 3rem;
  &.loading {
    height: 3rem;
    background-color: vars.$background-color--pulse;
    animation: pulse 1s infinite alternate;
  }
}

위에서 예로 들었던 영화 상세보기(모달 창)창에서 타이틀에 대한 scss를 수정해보면

.movie-title {
  font-size: 3rem;
  &:empty {
    height: 3rem;
    background-color: vars.$background-color--pulse;
    animation: pulse 1s infinite alternate;
  }
}

위와 같이 수정해줄 수 있습니다.

:empty를 이용할 때 동작하는 방식을 제가 이해한 방식으로 과정을 요약해보면 아래와 같습니다.

-> 빈 요소 -> .movie-title:empty{...} 스타일 적용 -> 데이터 로드, 렌더링 -> avengers -> 빈 요소가 아님 -> .movie-title:empty{...} 스타일 적용 해제, .movie-title 스타일 적용

omdbapi를 이용한 영화 검색 사이트(과제)의 배포된 도메인에서 :empty를 활용한 로딩처리 결과 화면은 아래와 같습니다.

적용해보면서 느낀 장점

자동화

제가 적용해보면서 느꼈던 장점은 javascript로 내가 css 클래스를 제어해주지 않아도, css 표준 기술을 활용해서 자동으로 빈요소에 대한 스타일을 제어할 수 있다 입니다. 요소는 있는데 안에 자식이 없어서 비어있는 경우의 스타일링을 :empty 에게 위임할 수 있다는 의미입니다. :empty를 활용하면서 로딩처리 스타일링을 할 때 좀 더 로딩처리 자체 스타일링에만 초점을 맞춰서 진행할 수 있어서 만족하면서 사용을 했습니다. 과제 이후에도 저는 개인적으로 로딩처리에 대한 css를 작성할 때 활용하고 있습니다.

호환성

기능이 좋아도 호환성이 좋지 않다면, 지금 바로 사용하는 것은 힘들 수 있습니다. 그러나, mdn과 caniuse에서 제공되는 호환성을 보면 거의 대부분의 브라우저에서는 사용이 가능하다고 볼 수 있습니다. 대부분의 사용자 브라우저에서 적용이 될 것이라 예상되기 때문에, 맘 놓고 적용할 수 있을 것 같다는 것이 저의 생각입니다.

끝맺으며

오늘은 :empty 를 개인적으로 학습하면서 적용해본 경험을 기반으로 포스트를 작성해보았습니다. 더 보기 영역(fetch-more)와 같이 요소 안에 스피너 아이콘에 대한 자식 요소를 보여주고 숨겨줘서 로딩 구현을 할 경우에는 :empty 를 활용해서 로딩 구현을 하기는 어렵다고 생각합니다. 다만, 이 외의 경우에는 좀 더 편하게 로딩에 대한 구현을 할 수 있어서 저는 만족하면서 필요한 경우 계속 활용하고 있습니다.

틀린 내용이 있거나, 이와 관련된 의견이 있으시다면 언제든지 댓글로 알려주시길 바랍니다.

env파일이 만능일까? (feat. 프론트엔드)

Wed, 11 Jan 2023 08:45:21 GMT

생각을 해보게 된 이유

API를 활용한 과제에서 쿼리스트링 파리미터로 apikey를 전달해줘야 되는데 env파일만 활용하면 중요한 값이 노출되는 상황을 방지할 수 있는지 확인해보고 싶었고, 이와 관련한 실험을 하게 되었습니다.

.env 파일을 이용하면 노출이 안되지 않을까?

실험을 해보기 전까지는 일반적으로 .env파일을 통해 중요 값을 노출시키지 않는다고 이해하고 있었기 때문에 고민을 하지 않고 .env파일만 작성해서 활용했었지만, 실험 후에는 생각이 바뀌게 되었습니다.

.env 파일로 노출되면 안되는 값에 대해 저장하였으며,

const fetchMovieData = async () => {
  const moviesResponse = await fetch(
    `https://www.omdbapi.com/?apikey=${process.env.apikey}&s=avengers`
  ).then((res) => res.json());
  console.log(moviesResponse);
};

fetchMovieData();

js파일에서는 omdbapi를 호출하는 간단한 코드를 작성해보았습니다.

env파일을 통해 중요 값이 노출되지 않는다고 생각한다면 "노출되어도 process.env.apikey로 노출이 되지 않을까?" 라는 예상을 할 수 있을 것 같습니다.

그러나, 실제로 개발서버를 통해 확인해보면...

apikey=... 으로 해당 값이 그대로 노출되는 것을 확인할 수 있습니다.

이를 통해서 저는 IDE 상의 코드 작성한 곳에서는 process.env.apikey로 보이기 때문에 노출되는 것을 피할 수 있지만, 실제 필요한 상황에서는 해당 데이터(값)를 이용하기 때문에 발생할 수 있는 현상이라고 생각하게 되었습니다.

물론, 쿼리 파라미터외에도 request header에 어떤 값이 있다면 네트워크 탭을 통해 확인이 가능해서 이와 관련한 고민도 필요하다고 생각합니다. (그래서 API 플랫폼에서 허용하도록 설정한 주소외에 모든 요청은 응답하지 않는 것과 CORS, JWT과 같은 방법이 등장했다고 생각합니다.)

최대한 중요값을 보호할 수 있는 방법이 있을까?

그럼에도 불구하고 .env은 여전히 중요 값을 보호하기 위해서는 활용해야 되는 파일이라고 생각합니다. 다만, 추가적인 방법을 통해 이를 보호할 수 있는 방법이 무엇이 있을까요?

제 나름대로 생각한 방법은 서버를 이용하는 것입니다.

서버를 통해 통신하면 적어도 프론트엔드 측에서 먼저 확인되는 주소는 서버와의 요청을 위해 필요한 주소이다.
서버는 내부 비즈니스 로직에서 중요값을 활용해 외부 API와 통신하거나 다른 방법으로 응답할 데이터를 생성하고 전송해준다.
서버가 노출된다면 중요값을 보호할 수는 없겠으나, 적어도 프론트엔드 측에서 주소로 드러나는 일은 막을 수 있다

vercel serverless function을 이용해서 제가 구현한 서버에서 사용하는 movies 데이터 요청 rest api 주소 형식은 /api/v1/movies?searchKeyword=avengers&year=2022&page=1 과 같으며, 서버는 해당 쿼리 파라미터를 실제 사용할 파라미터로 변환해서 omdbAPI서버로 요청, 그 결과를 응답하는 구조입니다.

실제로 작성해서 개발서버로 확인한 결과는 아래와 같습니다.

과정은 아래와 같습니다.

(화면에서는 잘려서 보이지 않지만) avengers 라는 키워드를 입력하고 검색을 진행
server에서는 자체 로직에서 process.env.apikey라는 환경변수 값을 이용해서 omdbAPI와 통신을 하고 { status, payload, message } 형식으로 응답을 내려줌

즉, 서버로 요청하는 restAPI 주소에서 민감한 정보는 가급적 받지 않도록 설계하였고, 이를 통해 얻게된 결과입니다.

이를 통해 저는

env파일을 통해 IDE상에서의 노출은 피할수 있지만, 실제 값을 이용하는 상황에서 노출될 수 있다. 이를 보완하기 위한 방법은 여러가지가 있지만 서버를 활용하는 방법도 있을 수 있다.

라는 결론을 내리게 되었습니다.

마무리 지으며

.env파일을 보완하기 위한 다양한 방법들이 있는 것 같지만, 그 중에서 필요한 경우 직접 서버를 개발해서 사용해볼 수 있는 방법도 있을 것 같아 시도해보았고 과정을 공유하고 싶은 마음에서 글을 작성하게 되었습니다.

제가 생각한 방법이 틀릴 수도 있기 때문에, 이와 관련한 의견이 있으실경우 의견 남겨주시면 감사할 것 같습니다.

vercel serverless function을 활용해서 개발할 때는 이상이 없었으나, (깃헙 연동등의 방법을 통해) 배포하면 에러가 발생하는 상황을 해결하는 과정도 있었지만 그것은 이후 기회가 된다면 글을 작성해보도록 하겠습니다.

레이아웃 클론코딩 도전기_[main]-2

Mon, 02 Jan 2023 08:40:17 GMT

시작하기에 앞서

원래는 구현하는 것과 동기화해서 글을 작성하는 것을 목표로 하였지만, 시간을 지체할 수 없었습니다. 지금 글을 작성하는 시점에서는 클론코딩 과제를 제출하였고 데모사이트 배포가 된 상황입니다. 실제 개발하면서 경험했던 상황을 재현하기 위해 개발자도구를 통해 제어를 해서 재현을 했는데요... 이 부분에서 양해를 부탁드립니다 ㅜㅜ

데모 사이트 https://zesty-custard-249c6c.netlify.app/
검색 버튼 클릭시 검색 컴포넌트(요소) 활성화, 영어와 한글 변환 기능, 모바일 반응형 디자인을 제외한 나머지를 구현했습니다. 공유기능은 실제 API를 사용해야 되서 이번 과제에서는 구현하지 못했습니다.

main title 영역

제가 생각했을 때 main 영역내부에서 실제 카드요소로 이루어진 콘텐츠에 진입하기 직전에 보여지는 영역이기 때문에 main title영역이라고 구분지어봤습니다. 처음에 달력의 애니메이션을 보고 "직접 애니메이션 처리를 해줘야 되나?" 하고 난감했었는데요...

다행히도, 해당 달력 요소를 만들기 위해 네트워크 통신으로 gif파일을 받아서 처리하는 것을 확인할 수 있었고, 이를 통해 비교적 손쉽게 구현을 할 수 있었습니다. 주소 양식에서 유추할 수 있듯이 ~/ico_date{해당 일자}.gif로 요청하면 해당 일자에 대한 gif파일을 응답으로 가져올 수 있습니다. (e.g. ~/ico_date30.gif로 요청하면 30일에 해당하는 gif 파일을 응답으로 받을 수 있습니다)

위와 같이 html에서는 img태그를 통해 구현가능 합니다.

card 분석

sticky

css의 position:sticky 를 활용하여 좀 더 인터렉티브한 콘텐츠를 만들 수 있습니다. 스크롤 되는 요소가 특정위치에 도달하면 sticky가 적용된 요소는 스크롤이 끝나기 전까지 끈끈하게 달라붙어서 고정되어있습니다.

이게 어떤 차이인지는 실제 눈으로 보면 체감이 되실 것 같기 때문에, 개발자 도구에서 sticky 속성을 제거한 것(미적용)과 제거하지 않은 것(적용)한 것에 대한 차이를 보여드리겠습니다.

sticky가 사용되지 않은 경우

position:sticky가 적용되지 않은 상태에서 스크롤을 내리면 아무 효과 없이 일반적인 스크롤처럼 동작합니다. 그런데, 무언가 밋밋한 느낌이 들지 않나요? 사용자를 사로잡을 인터렉티브한 요소가 없어 보입니다.

sticky가 사용된 경우

이번에는 position:sticky를 적용한 화면입니다. sticky가 없던 화면과 다르게 스크롤 될 때 일정위치가 되면 메인뉴스에 해당하는 요소는 그 위치에서 움직이지 않고 고정되어있으며, 메인 카드 서브 요소들의 스크롤이 끝나면 고정되지 않고 정상적인 스크롤 방식으로 동작합니다.

이와 같이 인터렉티브한 요소가 있다면 전과는 다르게 스크롤할 때 콘텐츠에 집중해서 보고 싶은 욕구가 들지 않으시나요? (저만 그럴 수도 있습니다...)

호환성

역시 IE는 지원하지 않네요 (Internet Explorer를 삭제하여 그동안 수고한 Internet Explorer에게 조의를 표합시다...)

그러나, 대부분의 모던 브라우저에서는 지원해주기 때문에 호환성이 괜찮다고 할 수 있습니다. 예전에 js로 스크롤 위치를 계산해주고 position:fixed 를 활용하여 복잡하게 구현했던 것을 조금 더 간편하게 구현할 수 있도록 도와주는 css 표준 속성이라고 할 수 있습니다. 지원하지 않는 브라우저에도 지원해야 될 경우에는 번거롭지만, 직접 js로 구현이 필요해보이는군요...

sticky를 사용하기 위한 구조

제 생각으로 카카오에서는 자동으로 적용될 수 있도록 아래와 같은 방법을 사용했을 것이라고 추측됩니다.

서버사이드 프레임워크인 Nuxt를 사용하고, 요청URL의 뉴스데이터에 카드 타입이 명시되있다.
인라인 스타일로 css가 작성되어 있다. =>

타입에 따른 카드요소들의 높이는 정해져 있기 때문에, 통신을 통해 가져온 뉴스 데이터를 활용해서 높이를 계산
js를 이용하여 계산된 수치값을 wrapper요소.style을 통해 인라인 스타일로 작성

다만, 저는 레이아웃을 직접 클론코딩해야 되기 때문에 각각 개별적으로 수치를 확인하고 적용했습니다.

height: calc(100vh - px)

sticky를 처음에 적용해서 확인했을 때 카카오 사이트와 달라서 어떻게 구현해야되는지 고민을 하게 되었습니다. 이미 사이트에 정답이 있고 그 것을 통해 배울수 있다는 클론코딩의 장점을 활용해서 구현을 하긴 했는데요... 제가 미숙해서 시간이 소요되었습니다. 혹시라도 저처럼 동일한 문제에 처해계신 분들을 위해 공유하고자 합니다. 일단 어떤 차이점이 있는지 아래를 통해 확인해봅시다.

카카오 메인 랜딩페이지 sticky

일반

뷰포트 높이가 줄어듬

네... 역시 카카오답게 매우 자연스러운 sticky 동작을 확인할 수 있습니다. (클론코딩할 때 레이아웃보다 이런 세세한 애니메이션을 구현해야 되는 것에 시간이 더 소요되었다는 사실이...?! ㅠㅠ)

calc(100vh - px) 미적용

일반

뷰포트 높이가 줄어듬

이 화면을 처음봤을 때 당황했습니다. sticky 기본적인 내용만 알고 있는 상태이여서 해결방안이 생각이 나지 않아 그랬던 것 같습니다. 처음에는 배우는 입장이고, 시간이 지체될 것 같아서 그냥 넘어갈까도 싶었지만... 꺾이지 않는 마음을 가지고 개발자 도구 형님의 도움을 받아보기로 합니다.

vh는 viewport height 뷰포트 높이에 대한 단위이며 100vh의 의미는 실제 보여지는 브라우저 영역 높이의 전체입니다. 이것이 유동적으로 높이가 줄어들어 일정한 비율로 보여지게 되는 원리입니다. 카드 컴포넌트의 높이를 100vh에서 하단 여백으로 설정하고 싶은 높이를 빼주면 됩니다. 여기에서, max-height를 통해 최대 높이를 설정해주지 않을 경우 레이아웃을 해칠수 있기 때문에 700px로 설정해서 하단 콘텐츠들의 레이아웃에 영향이 없도록 한 것을 확인할 수 있습니다.

inline 특성과 vertical-align: baseline으로 인한 img 하단의 공백을 제거하기 위해 display: block을 설정한 것으로 보입니다. (vertical-align: top을 이용해서도 제거할 수 있습니다. 그래서 inline-block으로 설정한 요소의 css에 vertical-align:top속성이 적용되는 것도 같은 이유라고 할 수 있습니다.)

이미지는 넘칠 경우 잘려져서 보이게 되며, 카드 컴포넌트의 높이는 보여지는 뷰포트의 높이에 따라 줄어들고 늘어납니다. 결과적으로 스크롤하였을 때 유동적으로 일정비율을 유지하며 고정되있는 효과와 스크롤 했을 때 이미지가 같이 스크롤 되는 것 같은 효과를 얻을 수 있습니다.

relative wrapper

section_home의 두번째 자식요소의 wrap_item이 메인 카드 옆에 있는 서브카드들의 wrapper입니다. 여기에서 height를 충분히 주는 것을 통해 스크롤이 되서 sticky가 화면상에서 정상적으로 적용되도록 할 수 있습니다. height 값을 늘이고 줄여보면 어떤 의미인지 체감할 수 있습니다.

flex-direction: row-reverse

처음 카드 섹션이 끝나고 밑으로 더 스크롤이 되면 동일한 구조의 카드 컴포넌트 구조가 확인됩니다. 다만, 여기에서는 서로 방향이 반대로 되어있네요. 반대로 구현하기 위해서 다시 구조를 만들고 스타일을 생성해야 될까요...?

다행히도 card container는 flex container요소이며 현재 flex의 direction은 기본 값인 row입니다. 즉, 가로방향을 따라 정렬되어있습니다. 동일한 html 구조와 class 스타일을 적용한 뒤, flex container인 card container요소에 flex-direction: row-reverse 를 적용하면 순서가 거꾸로 되서 가로로 정렬되기 때문에 비교적 손쉽게 동일한 레이아웃을 만들 수 있습니다.

이미지 스프라이트

culture 영역의 아이콘에 사용되는 이미지들은 이미지 스프라이트라는 기법을 통해 적용이 됩니다. 그럼 카카오만 이 기술을 적용하고 있을까요?

네이버도 동일한 기술을 사용하고 있습니다.

그럼 이 기술을 왜 사용하는 걸까요? 동일한 100MB의 용량이 있고 1MB로 100개를 받는 것과 100MB로 1개를 받는다고 가정해봅시다. 여기에서는 서버에서의 비용이라는 개념을 생각해야 되는데, 서버 입장에서는 여러개로 분할해서 받는 것 보다 최대한 1번에 받는 것이 비용이 저렴합니다. 이런 이유로, 여러 이미지들이 모여져 있는 이미지 1개를 받고, background-position 속성으로 위치를 조정하여 해당하는 아이콘의 이미지를 삽입하는 구조입니다.

이미지 스프라이트에 대해 궁금하신 분들은 아래의 사이트를 참고하셔도 좋을 것 같습니다.

https://velog.io/@untiring_dev/HTMLCSS-Day31.-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%8A%A4%ED%94%84%EB%9D%BC%EC%9D%B4%ED%8A%B8-%EA%B8%B0%EB%B2%95

처음에는 레이아웃 클론코딩으로 시작하였지만 하게 되면서 애니메이션 구현에 대한 배움도 있는 것 같고 다양한 기법들에 대해 학습할 수 있어서 유익한 과정이 되는 것 같습니다. 이외의 내용들은 다음 포스트에서 다룰 수 있도록 하겠습니다.

레이아웃 클론코딩 도전기_[main]-1

Tue, 27 Dec 2022 07:03:54 GMT

시작하기에 앞서

클론코딩하면서 관련 내용을 작성하는 것이 의외로 시간을 많이 할애해야 되는 작업이였군요... 조금 힘들지만 미래의 저를 위해 기록으로 열심히 남겨봅니다...

카카오 홈페이지와 동기화를 할 것인가?

동기화? 그 의미는 카카오 홈페이지의 최신 내용과 제 클론코딩 사이트에서의 내용을 동일하게 일치시킬지에 대한 문제입니다.

개발자 도구 - 네트워크탭에서 확인되는 요청URL을 통해 데이터를 가져오고, js에서 dom을 조작하여 데이터에 기반한 내용으로 작성할 수 있습니다. 뉴스와 관련된 데이터도 있지만, 살펴보면 category등 페이지 구성에 필요한 모든 데이터를 네트워크로 요청해서 받아와서 처리하는 것을 볼 수 있습니다(보통 이 작업을 처리하는 방법에 따라 비동기 통신 또는 동기 통신 이라고 부르는 것 같고, 네트워크 통신을 통해 데이터를 관리하는 것도 프론트엔드 분야에서 중요한 역량인 것 같습니다).

비동기 통신, 동기 통신에 대해 궁금하신 분들이 있을 경우 아래 블로그 글을 참고하셔도 좋을 것 같습니다. https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-%EB%B9%84%EB%8F%99%EA%B8%B0Async%ED%86%B5%EC%8B%A0-%EB%8F%99%EA%B8%B0Sync%ED%86%B5%EC%8B%A0

제가 요청URL인 https://www.kakaocorp.com/api/v1/content/home?lang=KOR 을 통해 get요청을 해도 해당 데이터를 응답받을 수 있기 때문에 클론코딩 사이트에서도 활용해서 구현 가능합니다(일반 사용자, 즉 제가 아니여도 가능합니다). 단, 그렇게 하기 위해서는 fetch API나 axios등을 통해 통신해서 데이터를 가져와야되고 js를 사용해야되는 영역입니다. 이렇게 하나 하나씩 다 하면 실제 사이트의 모든 부분을 클론 코딩하게 될 것 같았고, 이번 과제에서는 특정 날짜에서 카카오 랜딩 페이지에서 보여주는 화면을 기준으로 클론코딩하도록 하겠습니다. 나중에 개선한다면 할 수 있겠지만 js중심의 과제가 아니기 때문에 이 과제에서 필요하다고 생각되는 js 구현(메뉴 클릭시 하위 메뉴 나타남: 레이아웃을 위해 필요하다고 생각하여 구현함)이 아닐 경우 하지 않도록 하겠습니다.

refactoring

(scss, css) inner 클래스 사용

header가 아닌 main 영역도 가운데로 위치한 형태로 화면에 출력되야 되기 때문에 공통 클래스인 inner를 만들어서 재사용하는 구조로 수정했습니다.

.inner {
  max-width: 1296px;
  margin: 0 auto;
}

또한, mobile을 제외한 breakpoint에서 자연스러운 inner 스타일의 적용을 위해 관련한 media 쿼리도 추가했습니다.

@media screen and (max-width: 1439px) {
  .inner {
    max-width: 952px;
  }
}

스크롤을 해도 header 영역이 가려지지 않도록 z-index와 background-color를 설정하였습니다.

.landing_header {
  /* ... */
  z-index: 999;
  background-color: #fff;
  /* ... */
}

(js) event handling

중복을 줄이고 재사용해서 사용하기 위해 findActiveNavMenu 함수 작성 및 호출
등록하는 이벤트를 줄이고 유지보수를 위해 nav 요소에 이벤트를 위임하는 것으로 변경

const attachNavMenuEvent = () => {
  /* 
    - 중복성을 줄이고 재사용 하기위해 findActiveNavMenu함수를 만들어서 사용
    - nav element를 parent인자로 주는 것을 전제로 해서 작성함
    - nav element의 클래스 이름(.on)을 활용해서 활성화된 list item을 반환
      없을 경우 undefined 반환
  */
  const findActiveNavMenu = (parent) => {
    const menu_items = Array.from(parent.children).slice(0, -1);
    const activedMenu = menu_items.find((menu_item) =>
      menu_item.classList.contains("on")
    );
    return activedMenu;
  };

  const $nav_menu_list = document.querySelector(".gnb_list");

  const notExpandMenuTitles = ["뉴스"];

  /*
    - nav 요소에 Event delegation (이벤트 위임) 적용
    - 처음에는 li 요소에 개별적으로 이벤트를 적용했으나,
      최적화 및 유지보수를 위해 이벤트 위임을 활용하는 방식으로 변경함  
  */
  $nav_menu_list.addEventListener("click", (e) => {
    if (e.target === e.currentTarget) return;
    const title = e.target.textContent;
    if (notExpandMenuTitles.includes(title)) return;

    const activedMenu = findActiveNavMenu(e.currentTarget);
    if (activedMenu && activedMenu !== e.target.parentElement) {
      activedMenu.classList.remove("on");
    }

    /* 
     - a tag영역을 li 요소의 전체영역으로 설정했기 때문에, 
       li를 클릭했을 때 target은 a tag 요소가 됨
     - li > a 인 구조이기 때문에 e.target.parentElement는 li 요소가 됨
     - li 요소에 on클래스를 활용해서 메뉴 펼침을 제어하기 때문에,
       li 요소의 클래스를 toggle하여 제어
    */
    e.target.parentElement.classList.toggle("on");
  });

  /*
    - dim 영역(nav외의 영역)을 클릭했을 때 펼쳐진 메뉴가 있을 경우,
      해당 메뉴를 닫기 위해 이벤트 등록
    - 버블링 이벤트시 nav -> window 순서로 이벤트가 전파되기때문에 
      nav menu를 클릭했을 때 영향을 받을 수 있겠다고 생각함 
      -> 캡쳐이벤트 사용
  */
  window.addEventListener(
    "click",
    (e) => {
      const activedMenu = findActiveNavMenu($nav_menu_list);
      if (!activedMenu) return;
      if (e.target !== activedMenu.querySelector("a")) {
        activedMenu.classList.remove("on");
      }
    },
    true
  );
};

attachNavMenuEvent();

main 영역

main이라는 이름에 걸맞게 다른 영역보다 많은 시간을 할애하고 있는 영역입니다.

분석하면서

부드러운 애니메이션 효과에 신경을 (많이) 썼다는 느낌을 받았습니다. 예를 들면 아래와 같이

화면이 줄어들어 breakpoint에 도달하면 애니메이션으로 위치가 이동(transition)하고 이를 위해 position으로 각각 위치를 지정한 것을 확인할 수 있었습니다(한땀한땀 정성을 들이는 장인정신...).

이를 고려해서 처음부터 해당 카드 요소의 컨테이너 측에 relative, 카드 요소를 absolute로 배치한 것을 확인할 수 있고

breakpoint에 도달하면 absolute의 top, left 의 포지션을 수정해서 transition을 통한 애니메이션을 적용합니다.

제가 왜 이렇게 구체적으로 얘기하냐면... 네... 이거 구현하기 위해 생각보다 많은 시간을 할애했기 때문입니다 ㅜㅜ

보통 애플이 이런 측면에서 변태적?인 것 같다는 말을 하는 것을 들을 수 있었는데, 카카오도 ... ?

card

카카오 홈페이지에서 동일한 구조로 보여지는 저 스타일을 일반적으로 card 또는 card 컴포넌트라고 부르는 것 같습니다. css에서 사용하기 위해서는 card라는 클래스를 만들어서 사용해야 된다고 생각하여 관련 스타일링을 위한 작업을 하게 되었습니다.

구조 보통은 wrapper요소, 해당 content 요소 2개로 구분해서 작업을 했었는데, 유지보수 및 구현을 위해 container요소, wrapper요소, card요소 3개로 구분하여 구현했습니다.
- container
card를 활용한 영역을 구분하기 위해 작성하였고, container에서 외부 여백등에 대한 스타일링을 하여 나중에 수정이 필요할 때 손쉽게 하기 위한 구조라고 볼 수 있습니다. box-sizing: border-box 를 통해 wrapper요소가 container에서 padding 등을 제외한 크기를 가질 수 있도록 합니다. 또한 부모 요소인 aticle은 display: flex, card container는 flex:1 을 적용하여 flex 에 기반한 구조를 가지고 있습니다. card container는 max-width, min-width를 적용하여 카드가 사용되어지는 영역에 대한 크기를 제한합니다.
- wrapper
card 요소가 차지해야 되는 width를 가지며, card의 외곽요소(border 등)에 대한 적용이 되는 영역입니다.
- card
실제 card의 내용이 되는 영역입니다. padding을 통해 여백을 가지며, 저는 여기서 추가적으로 제목 등의 영역을 구분하고자 card header 클래스를 사용하고 html 구조를 작성하였습니다.

이후의 내용은 다음 포스트를 통해 다룰수 있도록 하겠습니다 ㅜㅜ

레이아웃 클론코딩 도전기_[header]-2

Sun, 25 Dec 2022 13:52:03 GMT

시작하기에 앞서...

처음에는 반응형으로 만들어서 모든 디바이스에 대응하도록 하고 싶었지만, 시간이 부족할 것 같습니다. 여건이 되는대로 개선하는 것을 목표로 해보겠습니다 ㅠㅠ

line-height ?

개발자 도구로 네비게이션 메뉴들에 대해 확인하던 중 "여기서 line-height를 적용한다고?"라고 생각되는 부분이 있었습니다. 이와 관련해서 생각해본 결과 "사용자의 편의성을 위해 li 요소의 글자가 아닌 상하좌우 영역을 클릭하더라도 링크가 동작할 수 있도록 하고자 한다. 그리고, 가운데로 정렬하여 디자인적인 요소를 스타일링한다" 라는 결론을 내리게 되었습니다. 실제 카카오 사이트의 네비게이션 메뉴글씨 상하단 영역으로 마우스를 올리더라도 클릭시 해당 링크로 이동할 수 있으며 글자는 li의 가운데 정렬 되있습니다.

일종의 css trick이라고 생각이 되며, 작업 중간에 flex로 개선할 수도 있지만, line-height를 적용해서 진행해보겠습니다.

:hover

당차게 navigation 영역을 작성하다가 첫번째 난관에 부딪혔습니다. hover시 어떻게 처리할 것인가에 대한 문제이며 아래와 같은 고민을 하였습니다.

(javascript) mouse 이벤트를 통해 클래스를 삽입하고 지워서 스타일을 적용한다.
(css) css변수를 사용하고, javascript로 제어해야되나?
(css) css만 가지고 사용할 수는 없을까?

가능한 css만으로 구현하고 싶어서 생각해보았고, 그 결과 구현을 할 수 있었습니다. 제가 구현한 방법은 아래와 같습니다.

navigation menu item 중 if(kakao) 2022은 id를 부여해서 우선순위를 더 높게 준 뒤, 해당 item만이 가져야 되는 스타일을 정의해준다.
navigation menu list를 hover할 때 if(kakao) 2022를 제외한 모든 item의 글자색을 원하는 색으로 지정한다(#888)
menu item을 hover할 경우 글자색을 부모의 글자색으로 강제상속하여 원래의 글자색이 되도록 스타일을 덮어쓴다.

/* gnb(nav) */
.gnb {
  &_list {
    display: flex;
    align-items: center;
    font-family: sans-serif;
    color: $fontColor;
    margin-left: 74px;
    &:hover > li > a:not(#link_if_kakao) {
      color: #888;
    }
  }
  .list_sub {
    position: absolute;
    top: 60px;
    left: 4px;
  }
  &_item {
    position: relative;
    color: $fontColor;

    .link_menu {
      display: block;
      color: $fontColor;
      flex-shrink: 0;
      font-weight: 700;
      padding: 0 28px;
      line-height: 72px;
      &:hover:not(#link_if_kakao) {
        color: inherit;
      }
    }
    #link_if_kakao {
      height: 42px;
      line-height: 42px;
      padding: 0 20px;
      color: #fff;
      background-color: #000;
      border-radius: 21px;
      position: relative;
      &::after {
        content: "";
        position: absolute;
        top: 0;
        right: -6px;
        width: 6px;
        height: 6px;
        background-color: #ff4024;
        border-radius: 50%;
      }
    }
  }
}

결과

클릭할 때의 구현을 위해서는 js를 이용해야 될 것 같다는 생각이 들었습니다. css 가상 선택자 중에 클릭했을 때의 요소에 대한 것은 없다고 알고 있기 때문입니다. focus가 대안이 될수는 있겠지만 완벽한 대안이라고 하기에는 말하기 어려울 것 같습니다.

js를 활용해 구현하기 위해 생각한 방법은 아래와 같습니다.

클릭시 상위 메뉴의 글자색이 유지될수 있도록 하기 위해 .on클래스를 활용한 스타일을 적용
관련된 sublist를 li의 자식요소로 삽입(position:absolute 로 배치하기 위해서)
상위 메뉴 클릭시 .on클래스를 토글하여 스타일을 적용
메뉴 이외의 영역을 클릭할 경우 active된 메뉴의 .on클래스 제거
- window 클릭 캡쳐 이벤트
- 버블링 이벤트로 할 경우 메뉴 on -> window 에서 on클래스 제거 -> 메뉴가 보이지 않는다(클릭해도 변화가 없다)

결과

button - search, language, darkmode

기한 내 제출이 어려울 수 있기 때문에 생략하고 진행
기한 내 제출이 가능할 경우 추가적으로 작업

기한 내 제출이 어려울 수도 있기 때문에 먼저는 생략하고 진행하지만, 만약 시간적 여유가 있다면 작업해보는 것으로 하겠습니다 ㅠㅠ 단, button에 대해 focus 가능하도록 하기 위해 요소에 tabindex를 설정해주고, focus시 outline이 생기도록 css 스타일링 하겠습니다.

아쉬웠던 점

카카오 공식 사이트에서는 kakaobig이라는 자체 글꼴을 사용하고 있지만, 제가 그 글꼴을 사용할 방법은 없기 때문에, 최대한 유사한 NotoSansKR (sans-serif, 고딕체 계열) 구글 웹폰트를 사용했습니다.
글자를 두껍게 적용할 경우 이로 인해 sub_menu_list의 width가 미세하게 증가해서 화면에 출력됨
- max-width:352px로 설정하여 미세하게 width가 증가하지 않도록 함
desktop만 고려하여 작업하고 있음 (시간적 여유가 있을 경우 개선 예정)

코드 결과

html



  
    
    
    
    
    
    
    
    
    
    
    카카오
    
    
    
    
    
    
  
  
    
      
        
        
          
        
        
        
          
            
              카카오
              
                
                  카카오문화
                
                
                  공동체
                
                
                  히스토리
                
              
            
            
              뉴스
            
            
              기술과 서비스
              
                
                  기술
                
                
                  서비스
                
              
            
            
              약속과 책임
              
                
                  ESG
                
                
                  소셜임팩트
                
                
                  디지털 권리
                
                
                  AI 윤리
                
              
            
            
              if(Kakao) 2022

scss (css)

/* ./styles/main.scss */

@import url("./_reset.scss");
@import url("https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@400;500;700&display=swap");

/* global */
$fontColor: #000;
$baseForeground: #000;
$buttonBaseBackground: transparent;
$buttonBaseHoverColor: #eee;

body {
  font-family: "Noto Sans KR", sans-serif;
}

a {
  text-decoration: none;
}

.btn {
  appearance: none;
  outline: none;
  border: none;
  margin: 0;
  padding: 0;
  border-radius: 1.125em;
  background-color: $buttonBaseBackground;
  font-weight: 400;
  color: #333;
  cursor: pointer;
  &:hover {
    background-color: $buttonBaseHoverColor;
  }
}

/* icon */
.ico {
  width: 24px;
  height: 24px;
  vertical-align: top;
}

/* custom-common-styles (for deduplication) */
.flex-container--not-shrink {
  display: flex;
  flex-shrink: 0;
}

/* header */
.landing_header {
  position: fixed;
  width: 100%;
  top: 0;
  left: 0;

  &__wrapper {
    display: flex;
    align-items: center;
    min-width: 952px;
    max-width: 1296px;
    margin: 0 auto;
    height: 72px;
    justify-content: space-between;

    a.logo_link {
      display: block;
      text-decoration: none;
      width: 74px;
      height: 24px;
      .ico_logo {
        width: 100%;
        height: 100%;
      }
    }
  }
}

/* gnb(nav) */
.gnb {
  &_list {
    display: flex;
    align-items: center;
    color: $fontColor;
    margin-left: 74px;
    &:hover > li > a:not(#link_if_kakao) {
      color: #888;
    }
    &:hover > li.on > a:not(#link_if_kakao) {
      color: inherit;
    }
  }

  &_item {
    position: relative;
    color: $fontColor;
    .menu_link {
      display: block;
      color: $fontColor;
      flex-shrink: 0;
      font-weight: 700;
      padding: 0 28px;
      line-height: 72px;
      &:hover:not(#link_if_kakao) {
        color: inherit;
      }
    }
    &:not(.on) {
      .gnb_sub_list {
        display: none;
      }
    }
    &.on {
      .gnb_sub_list {
        position: absolute;
        display: flex;
        gap: 24px;
        width: max-content;
        max-width: 352px;
        border-radius: 24px;
        top: 60px;
        left: 4px;
        padding: 0 24.5px;
        background-color: $baseForeground;
        box-sizing: border-box;

        &_item {
          .sub_menu_link {
            display: block;
            color: #eee;
            font-weight: 500;
            flex-shrink: 0;
            padding: 11px 0 13px;
            line-height: 24px;
            z-index: 99;
            &:hover {
              font-weight: 700;
              color: #eee;
            }
          }
        }
      }
    }
    #link_if_kakao {
      height: 42px;
      line-height: 42px;
      padding: 0 20px;
      color: #fff;
      background-color: $baseForeground;
      border-radius: 21px;
      position: relative;
      &::after {
        content: "";
        position: absolute;
        top: 0;
        right: -6px;
        width: 6px;
        height: 6px;
        background-color: #ff4024;
        border-radius: 50%;
      }
    }
  }
}

/* util-area */
.area-util {
  gap: 12px;

  .btn {
    width: 36px;
    height: 36px;
    flex-shrink: 0;
    &:focus {
      outline: 2px solid;
      border-radius: 50%;
    }

    &_search {
      &:hover {
        border-radius: 50%;
      }
      .ico_search {
        stroke: $baseForeground;
      }
    }

    &_language {
      &:hover {
        border-radius: 50%;
      }
      .ico_language {
        stroke: $baseForeground;
      }
    }

    &_theme {
      &:hover {
        border-radius: 100%;
      }

      .ico_theme {
        stroke: $baseForeground;
      }
    }
  }
}

js (javascript)

// ./src/index.js
const attachNavMenuEvent = () => {
  const $nav_menu_items = document.querySelectorAll(
    ".gnb_list > li:not(:last-child)"
  );

  const notExpandMenuTitles = ["뉴스"];

  $nav_menu_items.forEach((menu_item) => {
    menu_item.addEventListener("click", (e) => {
      const title = e.currentTarget.querySelector("a").textContent;

      if (notExpandMenuTitles.includes(title)) {
        return;
      }

      const [activedMenu] = Array.from($nav_menu_items).filter((menu_item) =>
        menu_item.classList.contains("on")
      );
      if (activedMenu) activedMenu.classList.remove("on");

      e.currentTarget.classList.toggle("on");
    });
  });

  window.addEventListener(
    "click",
    (e) => {
      const [activedMenu] = Array.from($nav_menu_items).filter((menu_item) =>
        menu_item.classList.contains("on")
      );
      if (!activedMenu) return;
      if (e.target !== activedMenu) activedMenu.classList.remove("on");
    },
    true
  );
};

attachNavMenuEvent();

레이아웃 클론코딩 도전기_[header]-1

Thu, 22 Dec 2022 13:25:25 GMT

여기에서는 실제 사이트를 확인해보고 header를 구현해보는 과정을 남겨보려고 합니다.

분석

head

favicon.ico

브라우저 탭에서 확인시 보여지는 저 작은 아이콘을 favicon이라고 부른다고 합니다.
favicon을 직접 제작하는 것도 가능하지만, 공식 사이트에서 제공하는 favicon의 이미지 주소에서 다운로드 받아 사용하도록 하겠습니다.

metaTag

요즘 웹사이트 주소를 붙여넣으면 사이트에 대한 정보를 표시해주는 데, 페이스북의 opengraph나 트위터의 twitter card를 활용하는 것 같습니다. 카카오도 해당 기술을 사용하는지 확인해보니... 사용하네요 (너무 당연한 얘기인것 같지만...) 위 이미지에서는 검색 봇이 오픈그래프 속성을 확인해서 분석한 내용을 기반으로 표시된 것 같네요

property="og:site_name" 과 같은 메타태그의 속성이 명시되있는 것이 확인됩니다. 헤더 태그를 작성하기 이전에 사이트에 대한 메타데이터를 먼저 작성해주고 시작하는 것이 좋을 것 같습니다.

이런 부분을 신경쓰지 않고 header부터 바로 작성했었는데... 현업에서는 사용자들을 위해 세부적인 것들을 더 작업하는거 같네요 ㅎ 헤더영역을 제작하기 이전에도 head에 메타데이터를 위해 적지 않은 부분을 작성해야 되니... 현업에서 일하시는 개발자분들 존경합니다...

저와 같이 궁금하셨던 분들을 위해 공식 사이트를 링크해두겠습니다

opengraph https://ogp.me/
twitter card https://developer.twitter.com/en/docs/twitter-for-websites/cards/overview/abouts-cards

이 과제에서는 opengraph만 도입해서 구현해보려고 합니다.

metaTag Test

reference https://dev-hyun.tistory.com/186
배포할 때 까지 기다려서 opengraph를 확인하는 것은 시간이 걸릴거 같고, 현재의 로컬 환경에서 어떻게 오픈그래프가 표시되는지 확인하고 싶어졌습니다. 검색해서 작업해 본 결과, localhost open graph checker 라는 크롬 확장 프로그램을 사용하여 테스트할 수 있었습니다.

이 주소를 복사해서 붙여넣기 해보니

wow ! 점점 흥미가 생겨지는 것 같습니다. 사이트 주소는 해당 크롬 확장 프로그램이 firebase에 임시배포를 해서 생기는 것이라고 추측되며, 정확한 테스트는 나중에 배포한 뒤의 주소로 확인이 가능할 것 같습니다.

url은 나중에 배포되면, 배포사이트의 주소로 대체할 예정이지만, (head까지 작성한) 현재 html은 아래와 같습니다.

헤더 영역 계산

보통 사이트에서 최상단에 로고와 네비게이션 메뉴들 등이 모여있는 곳이 header라고 생각됩니다. 이런 측면에서 보았을 때 카카오 공식 홈페이지에서의 헤더영역은 아래와 같다고 분석됩니다.

header 영역의 가로 너비는 브라우저 창의 전체 너비를 사용할 것으로 예상되는데, 정확한 높이값을 확인해야 될 것 같습니다.

가로너비는 개발자 도구를 열어 놓은 상태여서 영향을 받은 것 같고, 100%가 맞는 것 같습니다. 높이는 72px로 확인됩니다. 이와 같이 계산된 값을 통해서 헤더영역을 제작해보도록 하겠습니다.

내용이 너무 길어지는 것 같아, 이를 기반으로 한 header 영역의 구현에 대한 과정은 다음 포스트에서 남기도록 하겠습니다.

아, commit하는 것을 깜빡할뻔했네요 ㅠㅠ

레이아웃 클론코딩 도전기_intro

Thu, 22 Dec 2022 08:23:37 GMT

html, css 수업을 열심히 듣고 있던 중에 두려운 단어를 듣게 되었으니,

강사님: "~까지 과제를 제출해주세요." 나: ?!

자유롭게 하는 방식이기는 하지만 과제라는 것은 매번 할 때마다 부담되는 것 같습니다... 첫 과제라서 더 그런것 같기도 하고요...

하지만, 중요한 것은 꺾이지 않는 마음이겠죠? 두려움이 있지만 마음을 다시 잡고 과제를 하면서 이 과정을 기록으로 남기면 나중에 저에게도 도움이 될 것 같아 작성해보려고 합니다.

과제

내용
- 원하는 사이트(페이지)를 자유롭게 선택하고 해당 페이지의 레이아웃을 클론코딩
- 평소에 도전해 보고 싶었거나 혹은 자신의 수준에 맞는 사이트(페이지)를 선택
필수 요구사항
- 설명이 포함된 README.md 파일 제공
- 결과와 비교할 수 있는 선택 사이트의 주소를 명시
- 확인 가능한 HTML, CSS 파일 등이 모두 포함되어야 한다
- 브라우저에서 정상적으로 출력되어야 한다
선택 요구사항
- 시멘틱 태그를 최대한 활용
- 최신의 CSS Flex 혹은 Grid 등을 활용
- BEM 방법론 도입
- JS는 자제, JS과제가 아니므로 구현해도 가볍게 구현
- SCSS 등의 CSS 전처리 도구 도입
- SCSS 컴파일에 Parcel과 같은 번들러를 활용

기술셋 선정

실제로 코드를 작성하기 이전에 설계를 먼저하고 작성하는 습관이 되면 좋을 것 같아서 기술셋을 먼저 선정해보려고 합니다. 시퀀스 다이어그램과 같은 것은 이 과제와는 어울리지 않는다고 생각되기 때문에 이후 기회가 될 경우 학습해보면서 적용해보고자 합니다.

html, css 중심의 레이아웃 과제이다보니 여러가지 기술들에 대해 비교해보고 선택하는 것은 무의미할 수 있겠지만 제 나름대로 생각해본 결과는 아래와 같습니다.

css 전처리: SCSS

비교항목	SASS	SCSS
가독성	△	○
호환성	X	○

가독성
- SASS 중첩이 들여쓰기로 구분되기 때문에 내용이 길어지지 않을 경우 깔끔하게 보여지기는 하지만, 내용이 길어질 경우에는 구분하기가 어려울 것 같습니다.
- SCSS CSS처럼 { } (브라켓)을 사용하여 중첩이 구분되기 때문에 SASS보다는 내용을 보고 구분하기 쉬울 것 같습니다.
호환성 CSS 전처리기이기 때문에, CSS와의 호환성을 기준으로 비교해보겠습니다.
- SASS CSS문법으로 작성된 내용을 SASS에 사용할 경우, 들여쓰기로 구분되어지기 때문에 컴파일 되지 않습니다. 이런 이유로 CSS와의 호환성은 좋지 않다고 생각합니다.
- SCSS CSS문법으로 작성된 내용을 SCSS에 사용해도 호환(typescript가 javascript의 superset인 것과 비슷하게 느껴지는 것 같습니다)이 되기 때문에 CSS와의 호환성은 좋다고 생각합니다.
결론 CSS와 호환이 되는 SCSS를 사용하는 것이 좋을 것 같습니다.

번들러: Parcel

reference https://velog.io/@subin1224/Parcel-vs-Rollup-vs-Webpack-%EB%B9%84%EA%B5%90

비교항목	Parcel	Rollup	Webpack
환경설정(configuration)	zero-config	entry, output, loaders, plugins 등을 설정하는 구성파일이 필요, 파일변환을 위해서는@svgr/rollup과 같은 라이브러리가 필요함	entry, output, loaders, plugins 등을 설정하는 구성파일이 필요, 파일변환을 위해서는 loader가 필요
devServer	devServer가 내장되있음	`rollup-plugin-serve` 제공, live-reload가 필요한 경우 `rollup-plugin-livereload` 필요함	`webpack-dev-server` 제공, live-reload 지원

환경설정
- Parcel zero-configuration으로 별도의 환경설정없이 사용 가능
- Rollup rollup.config.js 와 같이 별도의 환경설정이 필요하며, 경우에 따라 추가적으로 라이브러리를 활용하여 설정해줘야 함
- Webpack rollup과 같이 별도의 환경설정 파일이 필요하며, polyfill을 지원하지 않기 때문에 필요한 경우 관련 설정이 필요합니다. 다양한 변환을 위해서는 css-loader, babel-loader와 같은 loader가 필요하고 관련 설정이 필요합니다.
=> Parcel > Rollup > Webpack
devServer
- Parcel devServer가 내장되어있고, 파일이 변경될 경우 다시 빌드합니다.
- Rollup devServer가 필요할 경우 rollup-plugin-serve 라이브러리를 통해 사용가능하며, live-reload가 필요한 경우 rollup-plugin-livereload가 필요합니다.
- Webpack webpack-dev-server를 제공하고, live-reload를 지원합니다.
=> Webpack > Parcel > Rollup
결론
- 초기 환경설정과 학습비용(러닝커브)이 있지만 Webpack이 여러 부분에서 우수한 것 같습니다.
- 안정적인 애플리케이션을 제공해야되는 실제 서비스 사이트 전체를 개발하는 것이라면 Weppack을 사용했을 것 같습니다.
- 다만, 현재 과제(프로젝트)는 시간이 제한적이고 복잡한 설계가 필요한 것은 아니라고 생각되기 때문에 Parcel을 사용해서 빠르게 개발하는 것이 좋을 것 같습니다. Webpack이나 Rollup을 사용한다면 환경설정을 위해 별도의 시간을 소모해야 되기 때문입니다.

배포: netlify

Vercel Vercel은 주로 Nextjs로 만든 사이트를 배포할 때 여러 이점을 얻을 수 있다고 생각합니다.
Heroku Heroku의 경우 예전에는 무료여서 간단한 프로젝트에 많이 사용하는 추세인 것 같았지만, 최근에 유료 정책으로 변환되어서 이용하고 싶다는 생각이 들지 않는것 같습니다(AWS기반이고 Heroku자체 이익도 있어야 되기 때문에 AWS를 이용하는 것보다 비용이 더 비싼것 같습니다)
Netlify 비용을 지불하지 않더라도 간편하고 빠르게 사이트를 배포할 수 있는 것 같습니다.
결론 현재 과제에서는 Vercel보다는 Netlify를 이용해 배포하는 것이 좋다고 생각합니다.

요약

Parcel을 사용해 SCSS를 컴파일하여 CSS를 생성하고, 다른 사람들이 확인 가능해야 되기 때문에 배포도 해야됩니다. 배포 사이트는 여러 사이트가 있지만, 레이아웃 위주의 클론코딩이기때문에 여러가지를 고려해야 될 필요가 없다고 생각이 됩니다. 그래서 배포는 netlify를 활용하여 진행해보려고 합니다.

클론코딩 사이트 선정

생각이 나는 사이트는 네이버, 슬랙, bugs 등의 여러가지가 있었지만 ... 저는 카카오 프렌즈의 캐릭터를 좋아하기 때문에(제 블로그 이름이 devrun_ryan 이네요?) 카카오 공식 홈페이지의 랜딩페이지를 클론코딩 해보려고 합니다. 그리고 카카오 공식 홈페이지에서는 position: sticky 를 사용하는 것 같아서 관련한 css도 학습이 될 것 같습니다.

앞으로 진행하면서 내용을 더 남길 수 있도록 노력하겠습니다.

TIL_Git_Github_사용해보기

Tue, 20 Dec 2022 07:13:34 GMT

git과 함께 사용하는 원격저장소(Cloud Remote Repository Services)

Github: 비영리였지만, 이후 Microsoft에 인수되었습니다. 현재 가장 유명한 서비스입니다.
Bitbucket
- Atlassian이 서비스
- jira, confluence, trello 등의 부가도구와 유기적입니다.
GitLab
- GitLab이 서비스
- 사설 서버 구성이 가능합니다(보안)
- github private repository이더라도 github에 업로드된 소스코드는 github 데이터 센터에 저장되는 것이기 때문에, 보안에 민감할 경우 GitLab을 통해 회사 사설 서버로 구성하여 사용이 가능합니다

준비사항

여기에서는 가장 많이 이용하는 github과 같이 연동하여 사용하는 것을 전제로 진행해보겠습니다.

git

git 설치
- macOS : git 홈페이지에서 다운로드 https://git-scm.com/
- window
  - gitforwindows 홈페이지에서 다운로드 https://gitforwindows.org/
  - git bash를 통해 unix-like 명령어로 cli이용이 가능(window 명령프롬프트에서 ls와 같은 명령어는 동작하지 않습니다)하며, 이후 브랜치 전략으로 git flow를 적용할 때 작업을 편리하게 해주는 command가 기본 내장되어 있음 => window에서 편하게 git으로 개발하기 위해 다운로드

설치 확인
```
$ git -v
```
git 환경설정
```
$ git config --global user.name "github유저네임(아이디)"
$ git config --global user.email "github메일주소"
$ git config --global core.editor "vim"
$ git config --global core.paper "cat"
```
- $ git config --global user.name "github유저네임(아이디)"
  - --global 플래그(옵션)이 없으면 새 프로젝트를 할 때마다 계속 설정해야 될 수 있습니다. 번거로운 작업이 될 수 있고 로그인을 여러번 하는 것을 방지하는 등의 이유로, 해당 플래그를 사용해서 설정하는 것을 권장합니다. (다른 사이트에서 참고할 때 --global 설정하는 내용이 많이 보이는 것도 그런 이유가 아닐까 생각됩니다)
  - github과 연동할 때 여기서 설정한 유저네임은 매치되지 않기 때문에 일치할 필요성은 없다고 하지만, 특별한 이유가 아니라면 github에서 사용하는 유저네임(아이디)로 설정하는 것을 권장합니다.
- $ git config --global user.email "github메일주소" github과 연동할 때 여기서 설정한 이메일을 매치하여 작업하기 때문에, github에서 등록한 email주소와 다르다면 에러가 발생할 수 있습니다. github과 연동하고자 할 때 에러가 발생한다면 git config --global --list 또는 git config --list 명령을 통해 email이 올바르게 작성되었는지 먼저 확인해보시는 것도 괜찮습니다.
- $ git config --global core.editor "vim" git에서 vim을 이용하여 텍스트 에디트를 할 경우 설정합니다.
- $ git config --global core.paper "cat" cli에서 텍스트 입력이 필요할 때 다른 프로그램(e.g. VSCode)이 열릴 수 있습니다. DX(Developer Experience, 개발자 경험)측면에서 좋지 않기 때문에 shell에서 텍스트를 출력하고 확인할 수 있도록 설정합니다.
잘못 설정한 경우 해결 방법
1. vi ~/.gitconfig 명령으로 텍스트를 편집하여 (직접) git 환경설정 파일을 수정
2. git config --global --unset user.email => git config --global user.email "수정할 메일 주소" (위는 예시 입니다. --unset과 수정하고 싶은 환경설정이름을 사용하여 설정을 제거해주고, 이후 다시 설정해주면 됩니다)
  
  window git bash에서 붙여넣기
마우스 우클릭으로 붙여넣기 하거나, shift + insert 키 입력으로 붙여넣기

github

github 가입 https://github.com/
가입할 때 등록한 username, email, password 를 잃어버리지 않고 잘 기억하기
repository(저장소) 생성 Profile페이지 - Repositories탭 에서 New 버튼 클릭
- * 표시된 항목은 필수 입력 항목입니다.
- Owner repoistory를 생성할 계정을 선택해주시면 됩니다.
- Repository name 생성할 repository의 이름입니다.
- Description 생성할 repository에 대한 설명입니다. 입력하지 않아도 repository 생성이 가능합니다(Optional)
- Public, Private repository를 모든 사용자에게 공개(Public)할지 비공개(Private)로 할 것인지를 설정합니다. Private repository의 경우 추가로 비용을 지불하지 않을 경우 제약사항이 있을 수 있으니 Public으로 사용하는 것을 권장합니다.
- Add a README file
  - README.md 파일을 자동으로 생성해줍니다.
  - create react app(CRA)과 같이 자동으로 README.md파일을 생성하는 라이브러리와 같이 사용한다면, 서로 충돌이 발생(github에서 생성한 README.md, CRA에서 생성한 README.md - 둘 다 루트경로에 생성하기 때문에 동일한 위치)할 수 있습니다. conflict를 해결하면 이용이 가능하지만, 번거롭기 때문에 이런 문제를 방지하고자 하는 경우에는 설정하지 않는 것을 권장합니다.
- Add .gitignore gitignore.io 사이트를 통해 .gitignore파일을 커스텀하게 작성할 예정이기 때문에 여기에서는 설정하지 않습니다. https://www.toptal.com/developers/gitignore/
- Choose a license
  - 보통은 MIT License를 많이 사용합니다.
  - 오픈소스 라이센스에 대해 궁금하신 분들은 https://sktelecom.github.io/guide/use/obligation/ 를 참고해보시는 것도 괜찮습니다.

사용해보기

git process flow

git commit convention

commit의 제목은 commit을 설명하는 하나의 구나 절로 완성
Important of Capitalize와 같이 가독성을 위해 대문자를 적절히 사용
prefix 작성

prefix	의미
feat	기능 개발 관련
fix	오류 개선 혹은 버그 패치
docs	문서화 작업
test	test 관련
conf	환경설정 관련
build	빌드 관련
ci	Continuous Integration
refactor	코드 리팩토링(코드의 결과물은 동일하고 구조 등이 수정되었을 경우 등)

commit 할 때 기억해야 할 것

commit 메시지의 기본 구조
```
prefix: subject
```

body

footer

- 동작 가능한 최소단위로 자주 commit합니다.
- 해당 작업단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 합니다.
- 모두가 이해할 수 있는 log를 작성해야 합니다.
- Open Source Contribution의 경우 영어가 강제되지만, 그렇지 않을 경우 팀 내 사용언어를 따라 씁니다.
- 제목은 50자이내로 축약해서 작성하며, 내용은 문장형으로 작성하여 추가설명 합니다. 해당 commit의 구성과 의도를 충실히 작성할 수 있도록 합니다.
- 제목과 내용은 구분할 수 있도록 한 줄 띄워 분리합니다.

### git commands
- `status`
```bash
$ git status

추적상태를 출력해줍니다.

add
```
$ git add 파일경로
```
- 해당 파일을 스테이지에 올립니다(commit을 작성하기 이전에 관련된 파일들을 설정)
- git add .을 통해 변경된(추적되지 않은) 모든 파일을 스테이지에 올리고 commit을 작성할 수 있습니다. 그러나, (최소한으로 동작하는) 기능의 단위로 commit을 작성한다는 취지와는 어긋날 수 있습니다. 그래서, 관련된 파일을 직접 지정해서 add하고 commit을 작성하는 것이 올바른 습관이라고 할 수 있습니다.
  
  add 할 때 CRLF 관련 경고(warning) 메시지가 출력될 경우
운영체제에서 개행문자를 처리하는 방식이 다름에서 오는 경고이며, 그냥 사용하셔도 동작은 되지만, 해결하고 싶으신 경우는 https://www.lesstif.com/gitbook/git-crlf-20776404.html 참고해보시는 것이 좋을 것 같습니다.
commit
```
$ git commit
```
- commit을 작성합니다.
- -m 플래그(옵션)은 가급적이면 사용하지 않는 것을 권장합니다.
- git commit -m "메시지"로 작업할 경우 git commit 명령을 통해 생성되는 기본적인 내용을 무시하고 지정한 메시지가 강제로 적용되어 작성됩니다(기본적인 내용이더라도 유용한 정보들이 요약되어 작성되있는 경우가 있습니다). 그래서, git commit => 제목, 내용 직접 작성 의 흐름으로 git을 사용하는 것이 올바른 습관이라고 할 수 있습니다.
log 이력을 확인할 수 있습니다.
push
```
$ git push {원격저장소 별칭} {브랜치 이름}
```
git push origin main 작성한 commit들을 origin(별명, alias)으로 설정한 원격저장소의 main 브랜치에 보냅니다.

경험할 수 있는 에러

remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.

정책이 변경되어서 패스워드 인증대신에 token을 발급하고 사용해야 됩니다.

settings - developer settings 클릭
Personal access tokens - Generate new token - Generate new token(classic) 클릭하여 토큰 생성 토큰을 발급하면 한번만 보여주기 때문에 기억하거나 저장해서 사용해야 됩니다.(잃어버린 경우 다시 발급해야 됩니다)
비밀 번호입력시 해당 토큰 값으로 입력
참고할만한 사이트 https://yian.tistory.com/38

unable to acess 'https://github.com/아이디/저장소.git':The requested URL returned error: 403 (403에러)

github에 최초로 등록한 계정과 현재 push하는 계정(환경설정에서 설정한 계정)이 달라 해당 저장소에 접근 권한이 없어서 나타나는 에러입니다.

윈도우 자격증명 관리자로 해결 https://itsjh.tistory.com/47 참고하시면 도움이 될 것 같습니다.
git remote set-url로 Remote URL 변경하기 https://velog.io/@arthur/GitHub-%EC%97%90%EB%9F%AC-%ED%95%B4%EA%B2%B0-The-requested-URL-returned-error-403 참고하시면 도움이 될 것 같습니다.

gitignore.io 사용법 및 .gitignore를 사용하는 이유

입력 창에 운영체제(window, macOS, ...), 프레임워크(React, Vuejs, ...), 프로그래밍 언어(Node, JAVA, ...)를 입력합니다.
자동완성 목록에서 선택하고, 없을 경우 유사한 것이 있다면 그것을 선택해도 됩니다(e.g. javascript 대신에 Node 선택)
생성 버튼을 누릅니다.

텍스트 파일을 모두 선택 및 복사하여 사용합니다.

.gitignore를 사용하는 이유

.gitignore에서 명시한 파일들은 git에서 변경사항이 발생했다고 인식하지 않습니다.
실제 소스코드와 관련된 파일이 아닌 다른 설정파일들도 추적하게 된다면, 의미없는 파일들을 commit하고 push해야 됩니다. window 설정파일 등이 이에 해당한다고 볼 수 있고, 이런 이유로 운영체제 등에 대해 추적할 필요가 없는 파일을 설정하는 것입니다.
npm을 사용할 경우 package.json만 잘 작성되어 있다면 npm i를 통해 의존 라이브러리(사용되는 라이브러리)를 모두 설치할 수 있기때문에 실제 라이브러리 파일들이 저장되는 공간인 node_modules가 github에 올라가지 않아도 됩니다. node_modules는 용량을 많이 차지하는 편이기 때문에 사이즈를 줄이기 위해서라도 git에서 무시하도록 설정하는 것이 좋습니다.
.env와 같이 IDE (e.g. VSCode, WebStorm, ...)상에서 노출되어서 않되는 값들을 설정한 경우 git에서 무시하도록 설정해야합니다.( github 등의 원격저장소에 업로드 되고, 일반 사용자들이 해당 값을 본다면 ... ?)

TIL_Git_개요

Sat, 17 Dec 2022 06:54:49 GMT

git은 무엇인가?

소스코드를 관리하거나 버전을 관리하기 위한 시스템, 소프트웨어 공학에서는 형상관리 도구에 포함된다고 할 수 있다.

VCS( Version Control System, 버전관리 시스템 ) SCM( Source Code Management, 소스코드 관리 ) < SCM( Software Configuration Management, 형상관리 )

리눅스를 만든 Linus Torvalds가 만들었다. (단 2주만에... 대단하다)
git(버전관리 시스템)과 github(웹 서비스)는 같지 않습니다(같다고 혼용하면 안됩니다)
2022년에 실시한 stackoverflow survey에서 전체 93.87%라는 압도적인 비율을 차지하고 있다(업계 1위로 자리 잡고 있다) https://survey.stackoverflow.co/2022/#section-version-control-version-control-systems

git의 필요성

당장 현실로 느껴지는 것은 stackoverflow 설문조사에서 볼 수 있듯이 개발을 직업으로 가지면 git을 사용할 줄 알아야 된다는 것입니다. (회사에서는 git을 사용해서 협업하고 있는데 제가 사용할 줄 모르면 원활한 협업이 힘들겠죠? "📨팀장님: 탕비실 ... go?") 개인이 개발하더라도 git의 특징과 장점이 있기 때문에 사용하는 것이 (정신건강에) 좋다고 생각합니다.

발표자료_최종 -> 발표자료_최종_수정 -> ... -> 발표자료_진짜_진짜_최종_수정2 -> ... 언제까지?? 이 많은 파일들을 다 가지고 있어야 되나? ㅠㅠ

git을 사용하면 위와 같은 고민을 하지 않아도 됩니다. 파일 단위가 아니라 라인 단위로 추적하기 때문에 관련된 파일을 다 기록하거나 기억할 필요가 없다는 것입니다.

비유를 들면, 조별 과제를 한다고 하였을 때

팀장님이 usb를 팀원들에게 개별적으로 나눠 줌 => 팀원들이 작업해서 팀장님에게 usb를 전달 => 팀장님은 모든 usb를 연결해서 각각 확인 (소스코드 주고 받기) => 팀장님은 원하는 내용을 복사 붙여넣기하여 최종 결과물을 파일에 반영 (배포) => 반영된 파일을 usb에 저장하고 다시 작업할 때 팀원들에게 다시 usb를 전달 (소스코드 주고 받기, 기능 개발) => ... (반복)

기능 구현하고 하나의 버전으로 배포하는 과정이라고 볼 수 있는데, 이를 위해 번거로운 과정(비효율적)을 거치고 있다는 생각이 들지 않으시나요?

특징

단순한 구조와 빠른 속도
분산형 저장소를 지원한다 (네트워크가 되지 않더라도 독립적으로 로컬에서 개발을 하고, 이후 네트워트가 가능할 때 원격 저장소와 동기화를 할 수 있다)
비선형적 개발(수천개의 브랜치)이 가능하다

장점

서로 소스코드를 주고 받지 않아도 동시작업이 가능하기 때문에 생산성이 증가한다
수정내용은 commit 단위로 관리하며, 배포 뿐 아니라 원하는 시점으로 Checkout(Switch) 가능하다
새로운 기능 추가는 Branch로 개발하여 편안하게 실험(개발)이 가능하며, 성공적으로 개발이 완료될 경우 Merge하여 반영한다
인터넷이 연결되지 않아도 개발할 수 있음 (네트워크가 되지 않아 서버에 접속이 되지 않아도, 로컬에서 먼저 개발을 진행할 수 있다)

구조

Git Objects

Blob 파일 하나의 내용에 대한 정보
Tree Blob이나 subtree의 메타데이터(디렉토리 위치, 속성, 이름 등)
Commit 커밋 순간의 스냅샷

reference

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

TIL_CLI_commands

Thu, 15 Dec 2022 06:14:57 GMT

CLI Commands

개요

개인적으로 개발을 진행했을 때 CLI라는 용어를 많이 듣게 되고, 클라우드 플랫폼(e.g. AWS) 공식문서에서 CLI에서 어떤 입력을 통해 어떤 작업을 수행할 수 있다는 것을 상세하게 설명한 것을 보았습니다.

그리고, git push origin main git add . 등을 통해 CLI라는 용어를 몰랐더라도 그동안 자연스럽게 CLI를 사용했던 나를 발견할 수 있습니다.

수학을 공부할 때 본격적으로 수학을 학습하기 이전에 이해하기 위해 필요한 숫자를 학습하는 것처럼, 개발을 공부할 때 shell에 대한 내용에 대해 학습하면 좋을 것 같아 학습한 내용을 정리해보려고 합니다. 개인적으로 학습한 내용을 기반으로 작성된 것이기 때문에 잘못된 내용이 있거나 개선해야 될 점등을 말씀해주시면 참고하고 수정하겠습니다.

용어

CLI

Command Line Interface (명령줄 기반 인터페이스)

CLI란 Command Line(명령줄) 기반으로 명령을 내리고, 응답을 받는다는 의미입니다. 대표적으로 위의 이미지와 같이 윈도우에서 명령프롬프트가 있습니다.

GUI

Grapic User Interface

GUI는 Grapic User Interface의 줄임말이고, 마우스와 같은 그래픽 요소를 이용해서 명령을 내리고 응답을 받는다는 의미입니다. 대표적으로 위의 이미지와 같이 윈도우에서의 탐색기가 있습니다.

알아두면 좋은 용어

delete: 삭제라고 부르며, 물리적인 삭제를 의미합니다.
remove: 제거라고 부르며, 논리적인 삭제를 의미합니다(실제 하드디스크에는 존재하지만, 접근할수 있는 주소를 차단하여 없는 것처럼 동작합니다. 이후 하드디스크에서 큰 용량의 파일을 저장해야 되는 등의 상황이 올 때 해당 공간에 다른 값이 할당될 수 있습니다. 즉 덮여쓰기 될 수 있습니다)

Commands

shell

개발 공부를 학습할 때 주로 unix-like 명령어를 접하고, 최근에는 윈도우에서도 관련된 명령어를 사용할 수 있도록 지원해주기 때문에 여기에서는 unix-like shell 기반을 기준으로 설명하겠습니다.

~

Tilde

틸드(물결표시)라고 부르며, shell에서는 최상위 디렉토리(유저 디렉토리)를 의미합니다.

/

Delimiter

 슬래시라고 부르며, shell에서는 디렉토리(경로)를 구분하기 위해 사용합니다.

$ 현재 shell에서 입력을 받을 준비가 되었다는 의미입니다.
* 별표(asterisk, 에스터리스크)라고 부르며, shell에서는 '모든'이라는 의미로 사용됩니다.

위를 종합하면 shell에서 command line의 왼쪽에 보이는 devryan@ubuntu-bionic:~$ 은 " 내가 사용하고 있는 서버이름(컴퓨터 이름)은 ubuntu-bionic이고 유저이름은 devryan이다. 그리고, 현재 경로는 해당 서버(컴퓨터)의 최상단(유저)디렉토리이며, 입력을 받을 준비가 되어있다($) "라는 의미입니다.

Shell Commands

pwd

Print Working Directory

현재 경로를 절대경로로 보여줍니다.
ls

List Segment
- 지금 위치(경로)에서 하위로 접근할 수 있는 디렉토리나 파일을 리스트로 출력해 줍니다.
- shell에서 디렉토리 단위에서의 . 은 현재 디렉토리, .. 은 상위디렉토리를 의미합니다.

cd

Change Directory

 directory 단위로 경로를 변경할 수 있습니다. ( `cd ..` 상위 디렉토리로 이동)

mkdir

Make Directory

새 폴더를 생성합니다.
touch 파일을 생성합니다.
mv

move
- command $ mv {이동할 파일경로} {이동시킬 파일경로} ( $ mv ../style.css . )
- 기능
  - 파일을 이동시킵니다.
  - 이름을 변경합니다. mv app.js main.js mv 내부적인 동작으로 인해 이동 시키는 기능 뿐 아니라 app.js를 main.js라는 이름으로 변경이 가능합니다.
cp

copy
- command cp {원본 파일경로} {복사할 파일경로} ( cp app.js ../ )
- 기능
  - 파일을 복사합니다(사본 생성).
  - 이름을 지정하지 않을 경우 원본파일의 이름을 그대로 사용합니다.
rm

remove
- command rm {파일경로}
- 기능
  - 파일을 제거합니다
  - 별도의 옵션(플래그)없이 파일이 아닌 디렉토리(폴더)를 삭제하려고 하면 에러가 발생합니다. (파일은 실제로 존재하지만, 디렉토리는 논리적으로 존재하기 때문입니다)
  - *를 활용하면 조건에 맞는 파일을 매치해서 삭제할 수도 있습니다. ( rm server.* 현재 경로에서 server라는 이름을 가진 모든 파일을 지움 )
- 옵션
  - -r
    
    recursive
    - command rm -r {디렉토리 이름}
    - 디렉토리를 삭제하기 위한 옵션입니다.
    - 재귀적으로 순회하면서 타겟이 되는 디렉토리 하위의 모든 디렉토리, 파일들을 지우고, 이후 타겟이 되는 디렉토리도 지웁니다.
  - -rf
    - command rm -rf
    - -r 만으로도 충분히 동작하지만, -r에서 지울 때 경우에 따라 지울지 물어보고 진행할수 있으며, 물어보지 않고 강제로 모두 삭제하기를 원할 때 -rf 를 사용합니다.

cat
- command cat {파일 경로}

텍스트 라인을 병합해서 화면에 출력합니다.
shell에서 파일의 텍스트(소스코드)가 올바르게 작성되었는지 확인하고자 할 때 사용할 수도 있습니다.

Vim commands

vim은 CLI에서 사용할 수 있는 대표적인 텍스트 에디터이며, 소스코드 작성으로도 활용할 수 있습니다.
mode를 기반으로 동작합니다. 그래서, 해당 기능을 사용하기 위해서는 해당하는 mode로 진입 후 사용해야 합니다.
commands
- vi {파일 경로} 해당 파일을 vim으로 open합니다.
- vim 에디터
  - esc
    
    escape
    
    normal 모드로 진입합니다.
  - normal 모드
    - :
      - command 모드로 진입합니다.
      - 하단에 표시되는 : 를 통해 command모드에 진입한 것을 확인할 수 있습니다.
      - i
        
        insert
        
        수정 모드로 진입합니다.
        
        하단에 표시되는 -- INSERT -- 를 통해 insert 모드에 진입한 것을 확인할 수 있습니다.
  - command 모드
    - w 작성한 내용을 저장합니다.
    - wq 작성한 내용을 저장하고 나갑니다(shell로 복귀).
    - q! 내용을 저장하지 않고 처음 상태를 유지합니다(override).