독일개발자초록이

Next.JS Streaming이란?

OnceBH — Sun, 20 Jul 2025 05:34:04 +0900

Next.JS Streaming이란?

안녕하세요!

오랜만에 인사드립니다.

그 사이 Next.JS에 수많은 업데이트가 있었고 오늘은 오랜만에 글을 작성해보려고 합니다.

서버 컴포넌트를 사용한다는 것은 여러 가지 장점이 존재합니다.

그중 한 가지는 클라이언트가 다운로드해야 하는 Javascript가 줄어든다는 것입니다.

하지만 서버 컴포넌트를 적절히 활용할 줄 알아야지 그 장점이 부각된다는 것입니다.

모든 정보들을 서버에서 한 번에 보여주려 하다 보면, 오히려 서버가 처리해야 하는 일이 너무 많아지게 되는 경우가 생기고 모든 작업이 끝날 때까지 클라이언트는 로딩화면만 보게 되는 경우도 있게 됩니다.

당연히 요즘 인터넷이야 워낙에 빠르다 보니, 유저가 답답하다고 느끼기도 전에 해결되는 경우다 다반사 일 것이지만,

그렇지 않은 경우도 꽤나 많습니다.

하지만 이러한 경우 클라이언트는 정확한 피드백을 받기 힘들고, 그냥 기다리는 수밖에 없습니다.

예를 들어 클라이언트가 온라인 쇼핑을 하기 위해 아마존 홈페이지에 방문했다고 가정하였을 때,

유저는 Header, Footer, 추천 목록, 제품사진들, 비디오들 등등을 보게 될 것입니다.

하지만 이때 제품사진 하나를 로딩하는데 너무 오랜 시간이 걸려 전체 홈페이지가 보이지 않는다면 어떨까요?

아마 유저는 홈페이지가 오작동한다고 생각하거나 무슨 다른 문제가 있다고 생각하기 쉬울 것이고 UX 측면에서도 좋은 결과를 기대하기는 어려울 것입니다. 이를 위해서 Streaming이라는 것을 사용합니다.

Streaming은 쉽게 말해서 Header, Footer, 추천 목록, 제품사진들, 비디오들 등등을 한 번에 가져오는 것이 아니라,

따로따로 비동기적으로 가져오는 것을 말합니다. 그렇다면 쉽게 말해서, Header와 Footer에 필요한 데이터가 제품 사진보다 먼저 완료되었을 때 Header와 Footer를 먼저 유저에게 보여주고, 추후 제품 사진이 완료되었을때 제품사진을 보여주는 것입니다.

그러면 유저는 홈페이지가 모든 준비를 마칠 때까지 빈 페이지를 보는 게 아니라, 먼저 완료된 정보들을 보게 되는 것입니다.

Streaming을 사용하면 대략 이러한 장점이 있습니다.

앞서 언급하였듯, 홈페이지가 비동기적으로 준비가 완료된 컴포넌트들이 먼저 보이게 됩니다.
모든 정보를 한 번에 가져오고 이때 사진 데이터에를 가져오는 중 에러가 발생하였다고 가정했을 때, 홈페이지 자체가 로드되지 않을 수 있지만, Streaming을 사용하면 사진 데이터에서 가져오는 중 에러가 발생하더라도 나머지 Header, Footer 혹은 추천 목록들은 로드되어 유저에게 보이게 됩니다.
페이지 로딩 시간을 단축시킬 수 있습니다.

Streaming을 사용하는 전제 조건

1. Streaming은 RSC (React Server Component)에서만 사용 가능합니다.

즉! RCC (React Client Component)에서는 사용할 수 없습니다. 그리고 애초에 사용 할 필요가 없습니다. (RCC는 즉 "use client"를 사용하는 컴포넌트를 말합니다.)

왜 RCC에서는 사용이 불가능할까요?

그 이유는 어차피 RCC를 이용한다면, 클라이언트 쪽에서 추후에 일어나는 일들이기 때문입니다.

그렇기에 Streaming이라는 것의 개념이 필요가 없습니다. 그렇기에 RSC에서만 Streaming이 가능하다고 생각하시면 됩니다.

그리고 또한 가끔 Streaming을 이용해서 RSC에 fetch 된 데이터를 업데이트시킬 수 있다고 생각하시는 분들이 있습니다.

예를 들면 데이터는 Server에서 fetch 되어 클라이언트에 보였지만, onClick Event를 이용해서 re-fetch를 하려고 하시는 경우 이는 불가능합니다. 이를 가장 쉽게 가능하게 하는 것은 SearchParams을 이용하여 URL에 그 정보를 바꾸는 것 혹은 Server Actions를 사용하는 것입니다. 하지만 이는 나중에 다루도록 하겠습니다.

2. Streaming을 사용할 때 항상 Suspense를 사용해야 합니다.

Suspense를 사용하지 않으시면 Streaming은 작동하지 않습니다.

Suspense라는 컴포넌트는 Child 컴포넌트가 데이터를 가져오는 동안 fallback을 통해 로딩 중 화면을 보여주는 컴포넌트입니다.

Streaming을 사용하는 간단한 예시

Streaming을 사용하는 아주 간단한 예시를 보여드리겠습니다.

이 예시는 Next.JS를 어느 정도 사용 할 줄 아시고 적어도 Boilerplate(보일러플레이트)를 만든 실 수 있다를 전제로 하고 있습니다.

app/
ㄴ StreamingTest/
ㄴ page.tsx
ㄴ Components/
ㄴ StreamingComponent1.tsx
ㄴ StreamingComponent2.tsx
ㄴ NormalComponent.tsx

이렇게 위와 같은 파일구조에 맞게 파일들을 생성해 주세요.

page.tsx

import { Suspense } from 'react';
import { StreamingComponent1 } from './components/StreamingComponent1';
import { StreamingComponent2 } from './components/StreamingComponent2';
import { NormalComponent } from './components/NormalComponent';

const StreamingTestPage = async () => {
  return (
    <div>
      <Suspense fallback={<div>loading.... StreamingComponent1</div>}>
        <StreamingComponent1 />
      </Suspense>

      <Suspense fallback={<div>loading.... StreamingComponent2</div>}>
        <StreamingComponent2 />
      </Suspense>

      <NormalComponent />
    </div>
  );
};

export default StreamingTestPage;

StreamingComponent1.tsx

export const StreamingComponent1 = async () => {
  // Simulating fetching data. It takes 1 second.
  await new Promise((resolve) => setTimeout(resolve, 1000));

  return <div>This is StreamingComponent1 file!!!</div>;
};

StreamingComponent2.tsx

export const StreamingComponent2 = async () => {
  // Simulating fetching data. It takes 5 second.
  await new Promise((resolve) => setTimeout(resolve, 5000));

  return <div>This is StreamingComponent2 file!!!</div>;
};

NormalComponent.tsx

// Use use client to indicate this component is a client component
'use client';

export const NormalComponent = () => {
  return <div>This is normal component!!!</div>;
};

자 이제 서버를 로컬에서 실행하겠습니다.

yarn dev를 터미널에서 실행해 주세요.

파일 구조를 잘 따라 하시고 모든 예시 파일들을 문제없이 붙여 넣으셨다면,

아래와 같이 동작할 것입니다.

loading... StreamingComponent1은 1초 뒤 This is StreamingComponent1 file!!!라고 바뀌고

loading... StreamingComponent2는 5초 뒤 This is StreamingComponent2 file!!! 라고 바뀔 것입니다.

그리고 This is normal component!!! 는 처음부터 끝가지 변화 없이 표현될 것입니다.

이는 각각의 StreamingComponent들이 Suspense 바운더리 안에 존재했기 때문입니다.
그렇기 때문에 This is normal component!!! 는 클라이언트에서 다운로드되어 보이는 것이고,

StreamingComponents들은 Streaming을 이용해서 서버에서 응답을 받을 때까지 fallback을 보여주다가 (즉 각각 1초 그리고 5초를 딜레이로 기다리다가) 각자 자신이 보여주어야 하는 컴포넌트들을 보여주는 것입니다.

심화 버전

모든 Suspense를 지우면 어떻게 될까요?

서버는 모든 응답을 기다렸다가 마지막에 페이지를 보여주게 됩니다.

즉! 서버는 동안 아무런 페이지도 클라이언트에게 보여주지 않습니다. 그리고 그 5초가 지난 후 클라이언트에게 페이지를 보여줍니다.

아래와 같이 page.tsx파일을 바꿔주세요.

import { StreamingComponent1 } from './components/StreamingComponent1';
import { StreamingComponent2 } from './components/StreamingComponent2';
import { NormalComponent } from './components/NormalComponent';

const StreamingTestPage = async () => {
  return (
    <div>
      <StreamingComponent1 />

      <StreamingComponent2 />

      <NormalComponent />
    </div>
  );
};

export default StreamingTestPage;

모든 Streaming을 지웠습니다.

자 이제 결과가 어떨지 아래의 비디오를 보시겠습니다.

자 페이지는 아무것도 보여주지 않고 로딩하다가 5초가 지난 뒤 페이지를 보여주었습니다.

이러면 실제로 유저는 아무런 피드백을 받지 못하고 페이지에 문제가 있다고 생각할 가능성이 있습니다.

그렇기 때문에 RSC를 사용할 때 data fetching 등이 있다면 Streaming을 이용하는 것이 현명한 방법이 되겠습니다.

마치며

자 오늘은 아주 가볍게 Streaming에 관해 알아보았습니다.

요즘에는 GPT 같은 툴이 아주 잘 되어있어, 굳이 블로그를 방문해서 정보를 찾아보는 분들이 적어지지 않았나 싶습니다.

하지만 항상 조금이나마 도움이 되면 좋겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.
Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

유튜브를 시작해보려 합니다!

OnceBH — Sat, 27 Apr 2024 20:47:46 +0900

유튜브를 시작해보려 합니다!

안녕하세요!

다들 잘 지내시나요??

오랜만에 게시글을 올리네요!

이런저런 바쁜 일들도 많았지만, 스스로 블로그에 더 신경을 써야 하는데 이런 부분이 너무 미흡했던 것 같네요!

이제부터라도 다시 초심을 찾고 천천히 게시글을 다시 적어가도록 해보려 합니다!

다름이 아니라 이번에 유튜브를 시작해 보면 어떨까 하고 시작을 하게 되었습니다.

제 얼굴이나 목소리를 보이는 것은 아니지만, 그리고 뭐 특별한 콘텐츠도 아니지만,

스스로 공부하고 코딩하면서 들어볼 만한 노래들을 자주 업로드해보려 합니다!

이제 1주일 정도 되어서 특별한 것 전혀 없지만, 블로그와 유튜브를 병행해보려고 합니다!

오늘도 하루 너무너무 고생 많으셨습니다!

짧은 주말이지만 평일보다 알차고 의미 있게 보내시길 바라겠습니다!

유튜브 주소: https://www.youtube.com/@devgreenkode

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.
완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

NeoVim으로 개발하기, LazyVim이란?

OnceBH — Fri, 29 Dec 2023 23:48:05 +0900

NeoVim으로 개발하기, LazyVim이란?

안녕하세요!

오늘은 NeoVim에 관해서 짧게 알아보려고 합니다.

저는 개발을 할 때 경우에 따라 2가지의 에디터를 사용합니다.

하나는 VSCode이고 다른 하나는 NVim입니다. VSCode를 사용할 때도 Vim 플러그인을 설치하여 사용하고 있습니다.

Nvim을 이용하여 개발하는 이유는 여러 가지이겠지만, 저의 경우 대략 3가지 이유라고 할 수 있습니다.

1. Vim을 이용하면 코딩하는 재미가 있습니다.

2. Vim을 이용하면 Terminal에서 바로 개발할 수 있기 때문에 동선이 짧고 여러 윈도를 동시에 작업하기 좋습니다.

3. Vim을 이용하여 개발하면 투명한 백그라운드를 만들 수 있습니다. 즉 커스터마이징이 아주 용이하다.

첫 번째와 두 번째의 이유들은 좀 더 생산성에 관한 이유라면 마지막 세 번째는 개인의 취향이라고 할 수 있을 것 같습니다.

NeoVim을 이용하면 확실히 손이 이리저리 마우스와 키보드를 옮겨 다닐 필요성이 확연히 줄어듭니다.

솔직히 개발하는 시간이 좀 더 빠르다? 는 개인적으로 잘 모르겠습니다. 하지만 손이 이리저리 옮겨 다닐 필요가 없어, 생산성 부분에서

분명히 이득이 있는 것은 사실인 것 같습니다.

Vim을 저도 알게 된 지는 몇 년이 지났지만 이번 연도부터 사용하기 시작하였습니다.

처음 Vim을 알게 되었을 때 사용해보려 했지만, 그 당시 왜 이런 걸 사용하나 싶기도 하고 배울 것이 너무 많아 포기했었는데,

이번 연도 들어 다시 한번 사용해 보자라고 생각하였고, 사용을 하다 보니, 왜 Vim을 사용하는지 알게 되었습니다.

이번 연도 초에 들어서 저는 Nvim에 필요한 플러그인들을 직접 설치하였습니다.

제 손으로 처음부터 제게 맞는 나 자신만의 에디터를 만들고 싶었기 때문입니다.

이런저런 비디오, 깃헙을 돌아다니며 어떻게 설치하는지 그리고 어떻게 작동하는지 찾아보고 대략 2개월 정도 시간을 들여 쓸만한 플러그인들을 설치하고 사용해 보고 바꿔보았습니다. 하지만 한 가지 불편한 점이 직접 플러그인들을 업데이트해주어야 하고, 또 업데이트 후 작동하던 플러그인이 작동하지 않거나, 업데이트가 제대로 되지 않는 현상들이 발생하였습니다.

그럼에도 꾸역꾸역 사용하다 어느 순간부터는 그냥 Vim을 VSCode에 설치해서 사용하는 게 훨씬 심적으로 편하겠다는 생각이 들었고, 다시

VSCode를 사용하기 시작하였습니다.

그러던 중 LazyVim에 관해 알게 되었고, 다시 NVim을 설치하였습니다.

현재 대략 3개월간 LazyVim을 이용하여 개발을 하고 있고, 제가 직접 플러그인들을 하나하나 설치했을 때보다 훨씬 편하고 좋은 관리를 받고 있습니다. 요 근래 한 유튜버분의 LazyVim세팅을 보고 제 세팅도 변화를 주었는데, 아주 만족스럽게 이용하고 있습니다.

NVIm에 관심이 있으시다면 LazyVim 홈페이지에 가셔서 설치해보시는 것도 좋을 듯합니다.

https://www.lazyvim.org/installation

️ Installation | LazyVim

You can find a starter template for LazyVim here

www.lazyvim.org

설치 방법이 아주 간단하기 때문에 별문제 없이 설치 및 실행하실 수 있으실 겁니다.

LazyVim을 설치하기 전 준비물은 컴퓨터에 NeoVim과 Git이 설치되어 있어야 합니다.

저는 Mac OS를 사용하기에 기본적으로 Git은 설치되어 있고, NeoVim은 Homebrew를 이용하여 설치하였습니다.

Homebrew는 Mac OS에서 사용할 수 있는 패키지 매니저입니다.

이를 이용하면 여러 곳에서 중구난방으로 프로그램들을 설치하는 번거로움이 줄고, 업데이트나 관리가 훨씬 편해집니다.

Mac OS를 사용하시는데 아직 Homebrew가 없으시다면 꼭 설치하여 사용해 보시길 권장드립니다.

https://brew.sh/

Homebrew

The Missing Package Manager for macOS (or Linux).

brew.sh

혹시 설치방법이나 플러그인들을 어떻게 사용하면 좋을지 잘 모르신다면 유튜브에 좋은 강의 혹은 영상들이 많이 있으니 확인해 보시길 바랍니다.

그리고 마지막으로 Terminal로 개발을 하시다 보면 여러 윈도가 필요할 경우가 자주 생깁니다.

그럴 때눈 Tmux라는 프로그램이 한 가지 방법이니 사용해 보시기 바랍니다.

Tmux 말고 다른 프로그램들도 많으나 저 역시 Tmux를 사용합니다.

Tmux는 앞서 언급한 Homebrew를 이용하여 설치하였습니다.

설치방법은 그냥 구글에 brew tmux라고 시치면 공식홈페이지에 설치방법이 모두 나와있습니다.

오늘은 짧게 제가 요즘 어떤 에디터를 이용하여 개발하는지 알아보았습니다.

사실 Vim을 사용하든 사용하지 않든, VSCode를 사용하든 Notepad를 사용하든 자신에게 맞는 에디터를 찾고 사용하는 게 가장 중요하다고 생각합니다!

오늘도 즐거운 개발 하시기 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gib keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

Firebase를 Next.js에 연결하는 방법.

OnceBH — Sat, 28 Oct 2023 19:49:45 +0900

Firebase를 Next.js에 연결하는 방법.

안녕하세요!

오늘은 간단하게 Firebase를 어떻게 Next.js 13에서 이용할 수 있는지 알아보려고 합니다.

Firebase란?
Firebase 사용방법?
연결 방법?
마치며.

1. Firebase란?

Firebase란 Google에서 제공하는 서비스입니다.

Firebase에는 여러가지 부가적인 빌드를 (기능) 제공합니다. 예를 들면 Firestore database, Authentification, Hosting과 같은 빌드가 존재합니다. 기본적으로 이러한 빌드들은 다 무료인 것으로 알고 있습니다. 하지만 더 나은 성능을 기대한다면 요금제를 선택하여 사용할 수도 있습니다.

Firebase를 이용하면 손쉽게 데이터를 저장하고 유저를 생성할 수 있습니다. 그 외에도 여러 가지 많은 기능들을 사용해 볼 수 있습니다.

2. Firebase 사용방법?

사용방법에 관해서 짧게 알아보겠습니다.

먼저 Firebas 공식 홈페이지로 들어가 Google 아이디로 로그인하시면 사진과 같이 프로젝트를 생성할 수 있는 버튼이 있습니다.

그 후 프로젝트의 이름을 설정합니다. 저는 test-project라고 프로젝트 이름을 설정했습니다.

그 후 Google 애널리틱스에 관한 정보가 나옵니다. 사용하는 것을 권장하지만 저는 따로 애널리틱스 기능을 사용하고 싶지 않기 때문에 비활성화했습니다. 필요하시다면 활성 화하시면 됩니다.

프로젝트 만들기 버튼을 누르면 프로젝트 생성이 시작됩니다.

자 프로젝트 생성이 끝나고 나면 아래와 같은 페이지로 이동할 수 있습니다.

자 이제 프로젝트 생성은 끝이 났습니다.

이제 프로젝트를 사용하기 위한 추가작업을 시작해야 합니다.

아래의 사진을 보시면 여러 버튼이 존재합니다.

각각 IOS, Android, Web Unity 그리고 Flutter입니다.

저희는 웹을 이용할 것이기에 3번째에 위치한 웹버튼을 누릅니다.

자 그럼 아래와 같은 페이지가 뜨게 되고 웹 프로젝트의 이름을 설정해야 합니다.

저는 test-web-project라고 이름을 설정했습니다.

그리고 Firebase 호스팅을 사용하지 않을 것이기에 체크하지 않았습니다.

Firebase 호스팅을 이용해서 자신의 웹사이트를 배포하고 싶으시다면 체크를 설정하시면 됩니다.

하지만 언제든지 나중에 설정을 다시 바꿀 수 있습니다.

자 이제 거의 모든 사전준비는 끝났습니다.

자 그럼 아래와 같이 firebaseConfig이라는 오브젝트가 생성됩니다.

firebaseConfig은 누구에게도 보여주시면 안 되는 민감한 정보입니다.

나중에 Git을 이용하여 코드를 푸시하실 때도 꼭. gitignore에 파일을 지정하여 노출되지 않게 조심하셔야 합니다.

firebaseConfig은 조금 후 Next.js와 연동할 때 사용할 것입니다.

자 이제 우리는 예시로 firestore database 사용 방법을 알아볼 것입니다.

콘솔로 이동 버튼을 누르시고 메인 페이지로 이동 후 빌드에서 Firebase database를 찾아 눌러주세요.

이러한 홈페이지로 이동하시계 될 것입니다.

이제 데이터베이스 만들기를 누르시고 위치를 설정하시고 테스트모드를 선택하신 후 사용설정 버튼을 누르시면 됩니다.

위치는 자신이 지금 현재 거주하는 위치에서 가장 가까운 위치를 선택하시는 게 가장 이상적인 방법입니다.

올바르게 사용 설정이 끝나면 아래와 같은 페이지가 보입니다.

자 이제 컬랙션을 하나 만들어보겠습니다.

저는 컬랙션 아이디는 test-test로 만들고 문서 아이디는 자동으로 그리고 필드는 name과 Mike를 입력하였습니다.

아래의 사진과 같이 test-test컬랙션이 생성되었는 것을 확인할 수 있습니다.

자 이제 모든 사전 작업은 끝났습니다.

3. 연결 방법?

Next.js에 Firebase를 연결할 차례입니다.

먼저 Next.js 프로젝트를 생성합니다.

Next.js프로젝트를 생성하려면 Node.js를 설치해야 합니다.

Node.js가 설치되어 있는지 확인하려면 터미널에서 node -v을 입력해 보시면 됩니다.

Node.js가 설치되어 있지 않으시다면 간단히 Google에 Node.js를 검색하시고 공식 홈페이지에서 다운로드하시면 됩니다.

혹은 여러버 전을 사용하게 되실 경우 nvm이라는 노드 버전 매니저를 설치하시면 됩니다.

아래의 yarn 혹은 npx 커맨드를 이용하여 Next.js프로젝트를 생성할 수 있습니다.
(개인적인 정보가 표시되는 부분은 모두 안 보이게 바꿔놨습니다.)

yarn create next-app
# or
npx create-next-app

자 이렇게 Next.js 프로젝트가 생성되었습니다.

이제 프로젝트를 VSCode를 이용하여 열어보도록 하겠습니다.

그 후 아래의 사진과 같이 firebase 터미널에 입력하여 패키지를 다운로드해 줍니다.

저는 yarn을 사용하지만 없으시다면 npm를 이용해 주세요.

yarn add firebase
# or
npm install firebase

firbase 패키지 설치가 끝나면 루트에서 새로운 폴더를 생성하시고 그 폴더 안에 firebase.ts라는 파일을 생성합니다.

저는 lib폴더를 생성하였지만 이름은 아무것이나 전혀 상관없습니다.

그리고 똑같이 루트에서. env.local이라는 파일도 생성해 주세요.

아래의 사진을 보시면 lib폴더 안에 firebase.ts와. env.local파일이 생성되어 있는 것을 확인할 수 있습니다.

. env.local파일은. gitignore에 포함되어 있기 때문에 어두운 회색으로 표현됩니다.

어두운 회색으로 표현된 모든 파일을 은 Git을 이용해서 코드를 푸시해도 포함되지 않습니다.

자 이제. env.local 파일에 우리가 아까 firebase에서 만들었던 firebaseConfig 오브젝트의 값을 설정할 것입니다.

혹시 firebaseConfig 값을 어디서 찾아야 하는지 모르신다면, 자신의 프로젝트 메인홈페이지로 가셔서 프로젝트 개요 옆 톱니바퀴모양을 클릭 후 프로젝트 설정으로 이동하시면 됩니다.

여기서 WriteYourOwnValue대신 firebaseConfig에 있던 값들을 복사붙여 넣기 하시면 됩니다.

예시를 보시면 이렇게 될 것입니다. 예시와 같이 자신의 모든 firebaseConfig 값을 위에서 아래까지 복사 붙여넣기 해주세요.

FIREBASE_API_KEY=AbCdEFgHiJKLMn
FIREBASE_AUTH_DOMAIN=yourOwnProjectName.firebase.com
FIREBASE_PROJECT_ID=yourOwnProjectName
FIREBASE_STORAGE_BUCKET=yourOwnProjectName.appspot.com
FIREBASE_MESSAGING_SENDER_ID=123121923123
FIREBASE_APP_ID=1:12312312312:web:7c2jwiac3123f5e

자 이제 firebase.ts 파일로 넘어가겠습니다.

firebase.ts에 아래의 코드를 입력해 주세요.

firebaseConfig은 process.env. 를 통해서. env.local에 있는 값을 가져오게 됩니다.

현재 getCollectionData는 firebase에 collectionName 즉 제가 지정한 test-test를 통해서 존재하는 모든 값을 가져오는 함수입니다.

import { initializeApp } from "firebase/app";
import { getFirestore, getDocs, collection } from "firebase/firestore";

/** Firebase config. */
const firebaseConfig = {
  apiKey: process.env.FIREBASE_API_KEY,
  authDomain: process.env.FIREBASE_AUTH_DOMAIN,
  projectId: process.env.FIREBASE_PROJECT_ID,
  storageBucket: process.env.FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.FIREBASE_APP_ID,
};

const app = initializeApp(firebaseConfig);

export const db = getFirestore(app);

/** Get all data from one collection. */
export const getCollectionData = async ({
  collectionName,
}: {
  collectionName: string;
}) => {
  const querySnapshot = await getDocs(collection(db, collectionName));
  // 예시를 위해 any 타입을 설정했습니다. any는 왠만하면 사용하지 않는것이 좋습니다.
  const results: any = [];

  querySnapshot.forEach((doc) => {
	// 체크하기위한 console.log
    console.log(doc.id, " => ", doc.data());
    results.push(doc.data());
  });

  return results;
};

자 이제 마지막으로 백엔드에 route 지정해 주면 모든 준비가 끝났습니다.

백엔드에 route을 지정하는 방법은 아주 간단합니다.

먼저 app 폴더 안에 api폴더를 생성합니다. 그리고 그 안에 collection이라는 폴더를 생성하고 그 안에 route.ts라는 파일을 생성합니다.

아래의 사진을 참조하세요.

자 이렇게 폴더와 파일까지 생성하셨다면 아래의 코드를 route.ts에 붙여 넣어 주세요.

원래는 POST request를 사용하는 것이 맞으나 쉽게 이해시켜 드리기 위해서 GET request를 사용하였고 collectionName에 직접 제가 Firestore에 만든 test-test라는 컬랙션의 이름을 지정해 주었습니다. 컬랙션의 이름을 다르게 설정하셨다면 test-test대신 자신의 컬랙션 이름을 지정해 주시면 됩니다.

import { NextResponse } from 'next/server';
import { getCollectionData } from '@/lib/firebase';

export async function GET() {
  const result = await getCollectionData({ collectionName: 'test-test' });

  return NextResponse.json(result);
}

이제 서버를 시작하여 확인해 보겠습니다. 아래의 커맨드를 이용해서 서버를 로컬에서 실행할 수 있습니다.

yarn dev
# or
npm start dev

로컬에서 제대로 작동하기 시작하면 아래와 같은 표시가 터미널에 나타납니다.

자 이제 브라우저를 열고

http://localhost:3000을 입력합니다.

그러면 Next.js에서 제공하는 메인페이지가 나타날 것입니다.

그렇다면 이제 거의 다 온 겁니다.

이번에는 http://localhost:3000/api/collection을 입력합니다.

그러면 저희가 지정한 컬랙션의 모든 데이터가 브라우저에 나타나게 될 것입니다. 아래의 사진과 같이 말입니다.

4. 마치며.

사진과 코드를 같이 담다 보니 게시글의 길이가 조금 길어진 감이 없지 않아 있습니다.

하지만 이렇게 사진을 같이 보시면 따라 해보기 시 훨씬 편하길 것입니다.

저 역시 코딩할 때 여러 블로그를 확인하지만 글은 잘 읽지 않고 사진과 코드를 먼저 확인하기 때문에

아마 조금이나마 도움이 더 될 것이라고 생각했습니다.

자 오늘은 짧게? Firebase를 Next.js에 연결하는 방법을 알아보았습니다.

Firebase는 제공하는 여러 빌드가 많기 때문에 가능하시다면 한 번씩 사용해 보시는 걸 추천드립니다.

더군다나 무료로 사용이 가능한데 사용하지 않을 이유가 없습니다.

또한 Firebase를 더 쉽게 사용할 수 있도록 도와주는 다른 라이브러리들이 많습니다.

그러한 라이브러리를 이용하면 제가 작성한 코드들마저도 작성하지 않고 Firebase를 사용 가능할 것입니다.

다음에 기회가 되면 Next.js를 Docker를 이용해 image를 생성하여 docker hub에 저장한 후 Web 서버를 만들어 실제로 웹사이트가 서비스되는 과정을 포스팅해보도록 하겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

Prettify Type을 쉽게 확인하자!

OnceBH — Fri, 20 Oct 2023 17:58:09 +0900

Prettify Type을 쉽게 확인하자!

안녕하세요!

오늘은 타입스크립트에서 Type 혹은 Interface를 사용할 때 편의성을 높여주는 또 다른 타입에 관해서 알아보려 합니다.

실제로 개발을 하다 보면 한 가지 타입만을 사용하지 않고 여러 타입을 합치거나 변형해서 사용하는 경우가 대부분입니다.

타입 혹은 인터페이스를 추상화 그리고 상속화하여 사용하기 때문입니다.

이는 OOP를 공부하시다 보면 자연스럽게 배우시고 사용하게 되실 것입니다.

타입과 인터페이스
Prettify란?
사용방법?
마치며

1. 타입과 인터페이스

타입스크립트를 사용하다 보면 자연스럽게 타입과 인터페이스를 사용하게 될 것입니다.

이를 사용할 때 한 가지 타입 혹은 인터페이스에 모든 필요한 key와 그에 상응하는 타입을 지정하지는 않습니다.

가능한 간단하고 명료한 타입을 여러 개 생성하는 게 더 도움이 되죠.

하지만 이러한 여러 개의 타입들이 수시로 바뀌고 추가되어 사용되다 보면 여러 번 알맞은 타입을 찾아야 하는 번거로움이 있습니다.

예를 보시겠습니다.

type PersonType = {
    name: string;
    age: number;
    height: number;
}

type AddressType = {
    address: string;
    addressNumber:number; 
}

type PersonWithAddressType = PersonType & AddressType;

자 PersonType과 AddressType을 병합한 PersonWithAddressType을 새로 만들었습니다.

PersonWithAddressType은 PersonType의 key와 type 그리고 AddressType의 key와 type을 합친 것입니다.

이는 아래의 코드와 같다고 말할 수 있습니다.

type PersonWithAddressType = {
    name: string;
    age: number;
    height: number;
    address: string;
    addressNumber:number; 
}

하지만 PersonWithAddressType위에 마우스를 놓으면 어떤 정보가 나올까요?

확인해 보겠습니다.

마우스를 올려놓았을 때 key와 type이 표현되는 게 아니라 PersonType & AddressType이라는 정보만 나옵니다.

이때 어떤 key들이 존재하는지 확인하기 위해서 다시 한번 각각 PersonType과 AddressType을 확인해야 합니다.

이번에는 다른 예시도 보겠습니다.

type PersonWithAddressType = PersonType & AddressType;

type PersonWithAddressType2 = PersonType & AddressType & {something:string;};

PersonWithAddressType2를 생성하였고 기존 타입들에 추가로 something이라는 key를 추가하였습니다.

자 이제 마우스를 PersonWithAddressType2위에 올려 보겠습니다.

자 기존 2가지의 타입에 합쳐 something의 정보밖에 보이지 않습니다. 여전히 전체적인 key와 type을 확인하기 위해서 따로따로 PersonType과 AddressType을 확인해야 하는 번거로움이 있습니다.

그럼 이제 Prettify를 알아보겠습니다.

2. Prettify란?

type Prettify<T> = {
    [K in keyof T]: T[K];
  } & {};

먼저 위의 코드를 작성해 주세요.

Prettify는 관련된 타입들을 Loopk 하여 하나의 타입인 듯 값을 줍니다.

그러면 결과적으로 마우스를 타입 위에 다시 올렸을 때 이러한 타입 정보를 보여주게 됩니다.

type PersonWithAddressType = {
    name: string;
    age: number;
    height: number;
    address: string;
    addressNumber:number; 
}

type PersonWithAddressType2 = {
    name: string;
    age: number;
    height: number;
    address: string;
    addressNumber:number;
    something: string;
}

자 사용방법을 보겠습니다.

3. 사용방법.

사용방법은 간단합니다.

Prettify를 사용하고자 하는 타입을 wrap 하면 됩니다.

예시를 보겠습니다.

type Prettify<T> = {
    [K in keyof T]: T[K];
  } & {};

type PersonType = {
    name: string;
    age: number;
    height: number;
}

type AddressType = {
    address: string;
    addressNumber:number; 
}

// type PersonWithAddressType = PersonType & AddressType;
 //type PersonWithAddressType2 = PersonType & AddressType & {something:string;};

type PersonWithAddressType = Prettify<PersonType & AddressType>;
type PersonWithAddressType2 = Prettify<PersonType & AddressType & {something:string;}>;

자 이렇게 Prettify를 통해서 사용하고자 하는 타입을 wrap 하였습니다.

이제 아까와 같이 마우스를 타입에 올려보고 어떤 정보가 나타나는지 확인해 보겠습니다.

자 더 이상 PersonType & AddressType 혹은 PersonType & AddressType & {something: string;}이 아닌

관련된 모든 key와 type의 정보가 나오는 것을 확인할 수 있습니다.

4. 마치며.

오늘은 Prettify를 알아보았습니다.

사실 실제로 개발을 하면서 적극적으로 사용할 일은 많지 않을 것 같지만, 여러 타입들을 사용하는 또 다른 타입을 이용해야 한다면,

그리고 그에 관한 정보를 빠르게 찾아보려면 Prettify를 한번 사용해 보는 것도 나쁘지 않을 것 같습니다.

다음에는 또 다른 유용한 유틸리티들을 알아보도록 하겠습니다!

이제 날씨가 조금씩 추워지기 시작하는 것 같습니다.

항상 몸 관리 잘하시고 즐거운 코딩하시길 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine Perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

Privacy Policy

OnceBH — Mon, 2 Oct 2023 00:36:37 +0900

Privacy Policy

Who I am

This website address is: https://ko-de-dev-green.tistory.com

Comments

When visitors leave comments on this blog, we collect the data shown in the comments form and also the visitor's IP address and browser user agent string to help spam detection.

Embedded content from other websites

Articles on this site may include embedded content (e.g videos, images, articles, etc.). Embedded content from other websites behaves in the exact same way as if the visitor has visited the other website.

These websites may collect data about you, use cookies, embed additional third-party tracking, and monitor your interaction with that embedded content, including tracking your interaction with the embedded content if you have an account and are logged in to that website.

How long we retain your data

If you leave a comment, the comment and its metadata are retained indefinitely.

For users that register on Kakao Tistory, we also store the personal information they provide in their user profile. All users can see, edit or delete their personal information at any time (except they cannot change their username). Website administrators can also see and edit this information.

What rights you have over your data

If you have left comments, you can request to erase them.

You can also request that we erase any personal data we hold about you. This does not include any data we are obliged to keep for administrative, legal or security purposes.

- For additional Information please check: Kakao Privacy Policy or Tistory Privacy Policy

Kakao Privacy Policy: https://privacy.kakao.com/center/process?lang=en

Tistory Privacy Policy: https://www.tistory.com/info/privacy/

컴포넌트의 타입을 도와주는 ComponentProps를 알아보자.

OnceBH — Sun, 20 Aug 2023 00:48:14 +0900

컴포넌트의 타입을 도와주는 ComponentProps를 알아보자.

안녕하세요.

오늘은 타입스크립트로 리액트라이브러리를 사용할 때

컴포넌트가 사용하는 Props의 타입을 쉽게 가져올 수 있는 ComponentProps에 관해서 알아보겠습니다.

Props의 타입을 재사용하는 방법?
ComponentProps란?
마치며.

1. Props의 타입을 재사용하는 방법?

리액트로 개발을 하다 보면 빈번하게 새로운 타입을 만들고 사용하며 import 하고 export 합니다.

그리고 이는 새로운 컴포넌트를 만들 때도 동일합니다.

아래의 예시를 잠깐 보겠습니다.

import { FC } from 'react';

export type TestComponentPropsType = {
  testId: number;
  testName: string;
  isSuccess: boolean;
};

const TestComponent: FC<TestComponentPropsType> = ({
  testId,
  testName,
  isSuccess,
}) => {
  return (
    <div>
      <p>{testId}</p>
      <p>{testName}</p>
      {isSuccess ? <p>success</p> : <p>fail</p>}
    </div>
  );
};

export default TestComponent;

이렇게 기본적인 TestComponent라는 이름의 컴포넌트를 생성하였고, Props에 필요한 타입까지 지정했습니다.

자, 그럼 만약 어떠한 다른 컴포넌트에 TestComponent라는 컴포넌트와 그의 타입이 필요하다면 어떻게 할까요?

아마 아래의 예시와 같이 import 하는 것이 가장 보편적인 방법이지 않을까 싶습니다.

import TestComponent, { type TestComponentPropsType } from '../testComponent';

혹은

import TestComponent, { TestComponentPropsType } from '../testComponent';

하지만 이렇게 꼭 컴포넌트와 타입을 각각 일일이 따로 import 할 필요가 있을까요?

그냥 TestComponent만 import 하고 그에 상응하는 타입을 사용할 수는 없을까요?

이럴 때 필요한 게 바로 ComponentProps입니다.

2. ComponentProps란?

ComponentProps란 이미 리액트가 내장하고 있는 기능 중 하나입니다.

ComponentProps를 사용하기 위해서 먼저 import 하는 방법을 보겠습니다.

아래의 코드를 사용하여 ComponentProps를 import 합니다.

import { ComponentProps } from 'react';

자, ComponentProps는 기본적으로 우리가 생성한 컴포넌트뿐만 아니라 DOM-Elements 즉 button, input 등등의 타입까지 가져올 수 있습니다.

예시를 보겠습니다.

type ButtonType = ComponentProps<'button'>;

이렇게 사용하여 button의 타입을 사용할 수 있습니다.

ButtonType위에 마우스를 올리면 아래의 타입이 지정되어 있음을 알 수 있습니다.

type ButtonType = ClassAttributes<HTMLButtonElement> & ButtonHTMLAttributes<HTMLButtonElement>

그리고 아래와 같이 새로운 button 컴포넌트를 만들 때 사용할 수 있습니다.

import { Container } from '@mui/material';
import { ComponentProps } from 'react';

type ButtonType = ComponentProps<'button'>;

const SOmething = ({ onClick, test1 }: ButtonType) => {
  return <button onClick={onClick}>Click!</button>;
};

const TestPage = () => {
  return (
    <Container>
      <SOmething onClick={() => console.log('hello')} />
    </Container>
  );
};

export default TestPage;

자 위의 코드의 경우 Click!이라는 버튼을 누를 경우 hello라는 문자가 콘솔에 표시될 것입니다.

당연히 이보다 더 활용성 높게 사용 할 수 있으나 가벼운 예시를 위해서 아주 간단하게 만들어 보았습니다.

자 그럼 본격적으로 HTML Element가 아닌 Component의 타입을 가져와 보도록 하겠습니다.

우리가 생성한 컴포넌트의 타입을 ComponentProps를 이용하여 가져오기 위해선 typeof라는 키워드가 사용되어야 합니다.

아래의 예시를 보겠습니다.

type TestComponentType = ComponentProps<typeof TestComponent>;

자 이제 마우스를 TestComponentType이라는 타입 위에 놓으면 이러한 타입임을 확인할 수 있습니다.

type TestComponentType = {
    testId: number;
    testName: string;
    isSuccess: boolean;
}

이는 우리가 위에 작성했던 타입 TestComponentPropsType와 동일한 타입을 가지고 있음을 알 수 있습니다.

아래의 예시를 보겠습니다.

import { Container } from '@mui/material';
import { ComponentProps, FC } from 'react';
import TestComponent from '../testComponent';

type TestComponentType = ComponentProps<typeof TestComponent>;

const Test2Component: FC<TestComponentType> = ({
  testId,
  testName,
  isSuccess,
}) => {
  return (
    <div>
      <p>{testId}</p>
      <p>{testName}</p>
      {isSuccess ? <p>success again</p> : <p>fail again</p>}
    </div>
  );
};

const TestPage = () => {
  return (
    <Container>
      <TestComponent testId={1} testName='test1' isSuccess />
      <Test2Component testId={2} testName='test2' isSuccess={false} />
    </Container>
  );
};

export default TestPage;

자, TestComponent라는 컴포넌트의 Props에 사용되는 타입을 가져와 Test2 Component라는 컴포넌트를 만들고 같은 타입을 사용하였습니다. 또한 타입을 변경하거나 확장하는 것도 가능합니다.

아래의 예시를 간단히 보겠습니다.

type TestComponentType = ComponentProps<typeof TestComponent> & {
  testInformation?: string;
};

type TestComponentType = Omit<ComponentProps<typeof TestComponent>, 'testId'>;

이렇게 또 다른 타입을 확장시키거나 불필요한 타입을 제거할 수 있습니다.

첫 번째 타입의 경우 기존 타입에 testInformation이라는 타입을 확장시킨 것이고,

아래의 Omit을 사용한 타입은 기존 타입에서 testId라는 타입을 제거한 것입니다.

3. 마치며.

개발을 하다 보면 항상 조금 더 편하고 쉬운 길이 있는 것 같습니다.

그래서 개발자는 그 누구보다 게을러질 수 있도록 노력해야 하는 것 같습니다.

오늘도 제 글이 조금이나마 도움이 될 수 있으면 좋겠습니다!

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

JsonSchema에 관해서 알아보자.

OnceBH — Sat, 15 Jul 2023 19:14:04 +0900

JsonSchema에 관해서 알아보자.

안녕하세요!

요즘은 Frontend에서 오는 Request이든 다른 3rd Party Provider에서 받아오는 Response이든 대부분

JSON 형식을 사용하고 있습니다. 이러한 Request 혹은 Response들은 사실상 큰 이변이 없다면,

일정한 파라미터와 값을 줄 것입니다. 하지만 현업에서는 이렇게 가볍게 보이는 것들 조차 정확한 파라미터와 값을 주는지

확인(검증) 할 필요가 있습니다.

오늘은 이를 확인할 때 도움이 되는 JsonSchema에 관해서 알아보도록 하겠습니다.

JsonSchema란?
사용방법?
마치며.

1. JsonSchema란?

JsonSchema란 검증 하고자 하는 Json의 값을 Schema (스키마)로 나타낸 것입니다.

이를 이용한다면 크게 3가지의 장점이 있습니다.

검증하고자 하는 Json의 구조가 정확한지.
검증하고자 하는 Json이 Schema와 일치하는 타입의 값을 가지고 있는지.
검증하고자 하는 Json이 필수로 요구하는 값을 포함하고 있는지.

자 그럼 짧게 사용방법을 알아보겠습니다.

2. 사용방법?

JsonSchema는 일반 Json의 구조를 띄고 있습니다.

그리고 각자의 type, properties 그리고 required를 설정하게 되는 게 가장 기본적인 구조입니다.

type: Json 혹은 Properties의 타입을 지정합니다. 타입은 기본적으로 object, number, string, array 등이 존재합니다.

required: 어떠한 Properties들이 필수적으로 포함되어야 하는지 나타냅니다. 기본적으로 array의 형태를 띱니다.

properties: Json이 포함하는 Key를 나타냅니다.

먼저 예시를 보기 전에 모듈 한 가지를 추천드리고 싶습니다. 그건 바로 ajv라는 패키지입니다.

이를 이용하여 보다 쉽게 JsonSchema를 이용하여 Json을 검증할 수 있습니다.

후에 시간이 된다면 따로 ajv라는 패키지에 관해서 설명하는 글을 올려보도록 하겠습니다.

자 그럼 이번에는 예시를 보겠습니다.

// ajv 패키지
import { JSONSchemaType } from 'ajv';

/** Type of person */
type PersonType = {
  name: string;
  age: number;
  email: string;
  isStudent: boolean;
};

/** 값 */
const person: PersonType = {
  name: 'Mike',
  age: 20,
  email: 'miketest@test.com',
  isStudent: false,
};


/** Schema for json */
const personValidationSchema: JSONSchemaType<PersonType> = {
  type: 'object',
  required: ['name', 'age', 'email', 'isStudent'],
  properties: {
    name: {
      type: 'string',
      minLength: 1,
    },
    age: {
      type: 'number',
    },
    email: {
      type: 'string',
      minLength: 1,
    },
    isStudent: {
      type: 'boolean',
    },
  },
};

자 천천히 살펴보겠습니다.

type은 아까 설명드렸듯이 Json이 포함하는 properties들의 타입을 설정한다고 말씀드렸습니다.

제일 처음에 있는 type: 'object'는 Json자체가 object라는 것을 나타냅니다.

그다음 각자의 type들은 위의 PersonType와 일치하게 각자의 properties에 맞는 타입이 설정되었습니다.

그다음은 required를 알아보겠습니다.

이는 기본적으로 array의 형태를 하고 있으며 항상 string으로 필수적은 properties를 작성하셔야 합니다.

그리고 properties입니다.

이는 앞서 PersonType에 존재하는 name, age, email 그리고 isStudent를 포함합니다.

그리 곡 각자의 properties들은 다시 타입 혹은 minLength를 포함하게 됩니다.

여기서 minLength는 말 그대로 적어도 값이 하나 이상의 char를 가지고 있어야 된다는 것입니다.

만약 아무 값이 없는 "" 이러한 string을 값으로 받게 되면 곧바로 검증되지 않는 값이라고 뜨게 됩니다.

자 모든 값들이 이렇게 쉽게 string, number만 존재한다면 좋겠지만,

우리는 개발할 때 array 혹은 enum 또한 사용하게 됩니다.

이에 관한 간단한 예시를 보겠습니다.

/** Enum */
enum DeviceEnum {
  Desktop,
  Tablet,
  Mobile,
}

/** Type of test */
type TestType = {
  test1: string[];
  test2: DeviceEnum;
};

/** Json Value */
const value: TestType = {
  test1: ['test', 'something', 'value'],
  test2: DeviceEnum.Desktop,
};

/** Validation schema */
const validationSchema: JSONSchemaType<TestType> = {
  type: 'object',
  required: ['test1', 'test2'],
  properties: {
    test1: {
      type: 'array',
      items: {
        type: 'string',
        minLength: 1,
      },
      minItems: 1,
    },
    test2: {
      type: 'number',
      enum: [DeviceEnum.Desktop, DeviceEnum.Mobile, DeviceEnum.Tablet],
    },
  },
};

자 array를 사용한다면 test1과 같이 type은 'array'로 지정하실 수 있습니다.

그리고 이때 items를 이용하여 array안에 존재하는 값들이 어떠한 타입을 가지고 있는지 그리고 적어도 몇 개 이상의 char가 필요한지 나타냅니다.

그리고 minItems는 마찬가지로 적어도 몇 개의 값이 array안에 존재해야 하는지 나타냅니다.

이를 지정하지 않는다면 텅 빈 array 즉 [] 또한 문제없이 작동합니다.

Enum을 사용하는 경우는 그렇게 많지는 않지만 그렇다고 지나칠 수는 없는 부분입니다.

test2를 보시면 type이 'number'로 지정되었습니다. Enum은 따로 상응하는 값을 지정하지 않는다면 숫자로 인식됩니다.

그렇기에 enum에 Desktop, Tablet, Mobile이라고 적혀있어도 사실상 1,2 그리고 3으로 인식되는 것입니다.

혹시 type을 string으로 지정하고 싶으시다면 아래와 같이 Enum을 조금 바꿔주시면 됩니다.

enum DeviceEnum {
  Desktop= 'Desktop',
  Tablet= 'Tablet',
  Mobile= 'Mobile',
}

이렇게 바꿔주시면 type을 'string'으로 지정할 수 있습니다.

그리고 enum에 존재 가능한 값들을 지정해 줍니다.

3. 마치며.

자 오늘은 JsonSchema에 관해서 짧게 알아보았습니다.

사실 그냥 이렇게 선언만 해서는 사용할 수 없습니다!

앞서 언급한 ajv와 같은 패키지를 이용하시면 Json의 값과 Schema를 보다 쉽게 비교할 수 있습니다.

개발을 할 때 항상 올바른 값을 주고받는 것은 너무도 중요합니다.

또한 올바르지 않은 값을 서버가 받았을 때 이를 어떻게 처리하는지도 너무 중요합니다.

오늘은 JsonSchema를 통해서 가볍게 Schema를 어떻게 작성하는지 알아보았지만,

다음에는 ajv를 통해서 어떻게 실제로 json의 값을 검증하는지 알아보겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

텍스트로 UML 다이어그램을 그리는 방법. Mermaid란?

OnceBH — Sun, 9 Jul 2023 20:30:25 +0900

텍스트로 UML 다이어그램을 그리는 방법. Mermaid란?

안녕하세요!

개발을 하다 보면 자연스럽게 문서화작업의 필요성을 느끼게 됩니다.

대부분 작업을 하다 보면 코드를 보고 이해할 수 있지만, 협업을 하고 프로젝트의 규모가 커지다 보면,

UML 다이어그램과 같은 시각적인 자료가 얼마나 유용한지 알게 됩니다.

또한 개발자뿐만 아니라 다른 직군의 동료들에게도 코드를 보여주는 것보다 다이어그램을 통해서 훨씬

손쉽게 설명하고 이해시킬 수 있습니다.

오늘은 텍스트를 이용하여 UML다이어그램을 그릴 수 있는 Mermaid에 관해서 알아보겠습니다.

UML 다이어그램이란?
Mermaid란?
설치방법?
사용방법?
마치며.

1. UML 다이어그램이란?

UML 다이어그램이란 Unified Modeling Language로 통합 모델링 언어라고 해석할 수 있습니다.

통합이라는 말과 같이 UML은 하나가 아닌 여러 개발에서 사용되는 여러 다이어그램들의 모음입니다.

이는 OOP (Object-Oriented Programming)를 이용할 때 많이 사용되지만 꼭 OOP를 지원하는 언어를 사용하여

개발할 때만 UML을 이용할 수 있는 것은 아닙니다.

UML에는 크게 Structure Diagram과 Behavior Diagram 나뉘게 됩니다.

Structure Diagram은 말 그대로 구조적인 관계를 나타낼 때 사용하는 다이어그램입니다.

대표적인 예가 클래스 다이어그램으로 클래스가 포함하는 변수, 함수, 클래스 간의 관계, 인터페이스와의 관계 등등을 나타낼 수 있습니다.

Behavior Diagram은 말 그대로 행위를 나타낼 때 사용하는 다이어그램으로 대표적으로 순차 다이어그램을 말할 수 있을 것 같습니다.

순차 다이어그램은 말 그대로 순차적으로 행위가 어떻게 이루어지는지 나타내는 다이어그램입니다.

예를 들면 고객이 로그인할 때 어떤 행위들이 순차적으로 이루어지는 지에 관해서 나타낼 수 있을 것입니다.

예전에 제가 짧게 UML에 관해서 적어놓은 글이 있습니다.

혹시나 조금이라도 더 자세히 알고 싶으시다면 아래의 링크를 이용하실 수 있습니다.

https://ko-de-dev-green.tistory.com/26

2. Mermaid란?

오늘은 Mermaid에 관해서 알아보기로 했으니 UML은 잠시 옆에 두고 Mermaid에 관해서 이야기하겠습니다.

Mermaid란 쉽게 말해서 텍스트 혹은 코드를 이용하여 앞서 언급한 다이어그램들을 정의하고 그릴 수 있게 도와주는 도구라고 할 수 있습니다.

Mermaid는 자바스크립트를 기반으로 한 다이어그램을 그려주는 도구로 특정 텍스트 혹은 코드를 이용하여 쉽게 시각화된 다이어그램을 그려줍니다. Mermaid의 큰 장점이라고 한다면 Github이나 Gitlab에서도 시각화되어 표현된다는 것입니다.

이는 앞서 언급하였듯이, 전체적인 개요 혹은 프로세스를 쉽게 확인할 수 있고 개발자가 아니더라도 빠르게 이해할 수 있도록 도와줍니다.

그럼 설치 방법에 관해서 알아보겠습니다.

3. 설치방법?

설치방법은 아주 간단합니다. 이를 위해서는 기본으로 Node.js v16 이상을 요구합니다.

그 뒤 자신이 사용하는 Package Manager를 이용하시면 됩니다.

예를 들면 npm install mermaid, yarn add mermaid 혹은 pnpm add mermaid.

하지만 여러 Extention을 이용하여 별다른 설치 없이 Meraid를 이용하실 수도 있습니다.

저는 VSCode를 가장 빈번히 이용하는데 Extention을 확인해 보시면,

Markdown Preview Mermaid Support라는 Extention을 찾으실 수 있을 것입니다.

설치해 줍니다. 그 뒤 하나의. md파일을 생성해 줍니다. 예를 들면 README.md와 같은 파일을 생성합니다.

이제 VScode에서 파일을 선택하여 탭을 오픈하시면 자동으로 Preview탭 또한 같이 오픈될 것입니다.

아래의 사진과 같이 말입니다.

혹시 설치하시기 전 먼저 브라우저를 통해서 테스트해보고 싶으시다면

Mermaid에서 지원하는 에디터가 존재합니다.

아래의 링크를 이용하시면 됩니다.

https://mermaid.live/

왼쪽은. md파일의 탭이 그리고 오른쪽은 Preview탭이 열려있는 게 보입니다.

자 그럼 이번에는 간단하게 순차 다이어그램을 작성해 보겠습니다.

4. 사용방법?

사용방법은 너무 간단합니다.

아래의 예시를 먼저 복사해. md파일에 붙여 넣기 해보세요. 그리고 아래와 같이 시각화되어 보인다면 성공입니다.

```mermaid
sequenceDiagram
    Frontend->>Backend: send vlaues 
    Backend->>DB: search data from db
    DB-->>Backend: return results 
    Backend-->>Frontend: sent results
```

처음 mermaid를 이용할 것을 선언해 줍니다.

그다음 sequenceDiagram 즉 순차 다이어그램을 사용할 것을 알려줍니다.

그 뒤 Frontend, Backend 그리고 DB를 정의한 뒤 그 사이에 어떻게 순차적으로 작동하는지 나타냅니다.

문제없이 작동한다면 아래의 사진과 같이 순차 다이어그램이 보일 것입니다.

각자의 다이어그램마다 문법이 조금씩은 비슷하지만 다른 문법들이 많이 있습니다.

그렇기에 Mermaid를 이용하여 다이어그램을 그리신다면 공식 홈페이지에서 문법을 참조하시는 게 좋습니다.

https://mermaid.js.org/syntax/flowchart.html

5. 마치며.

오늘은 Mermaid에 관해서 알아보았습니다.

Mermaid가 불편하시다면 꼭 이를 이용할 필요는 없습니다.

직접 그릴 수 있는 프로그램이나 서비스들이 많이 존재하기 때문입니다.

하지만 Mermaid의 장점으로 앞서 언급하였듯이 Github이나 Gitlab에서도 다이어그램을 바로 볼 수 있다는 것입니다.

그리고 수정이 필요한 경우 따로 제3의 서비스를 이용하여 다이어그램을 수정 후 파일이나 사진으로 저장한 뒤 프로젝트에 저장하는 수고를 덜 수 있습니다. 왜냐하면 그냥 프로젝트에서. md파일을 쉽게 수정할 수 있기 때문입니다.

사용하지 않으면 불편한지 모르지만, 알고 나면 얼마나 편한지 알게 되는 것 같습니다.

아직도 우리가 모르는 모듈들이 넘치고 있습니다.

저도 여러분에게 유용하거나 좋은 모듈, 패키지, 도구들 등등을 찾아내면 알려드리고 공유할 수 있도록 해보겠습니다.

오늘 하루도 고생하셨고, 내일도 힘내시기 바랍니다!

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

NextJS .env.local이란?

OnceBH — Mon, 3 Jul 2023 00:43:42 +0900

NextJS .env.local이란?

안녕하세요! 오늘은 NextJS에서 env.local이란 파일이 무엇인지 알아보겠습니다.

개발을 하다 보면 특히 협업을 한다면 필연적으로 git을 사용하게 됩니다.

이때 우리는 gitlab이나 github에 소스코드를 업로드하게 됩니다.

이때 따로 비공개로 설정하지 않는다면 소스코드는 공개되는 경우가 많습니다.

하지만 개발을 하다 보면 다른 개발자나 타인에게 보여주기 민감하거나 혹은 보이지 않아야 하는 정보들이 있기 마련입니다.

예를 들면 데이터베이스에 접근하기 위한 Id, Password, Database name 등등이 있을 수 있습니다.

이러한 정보들은 자칫 타인에게 보이게 된다면 타인이 데이터베이스에 접근할 수 있기 때문에, 당연히 접근도 할 수 없고 보이지 않아야 합니다.

그렇다면 그러한 정보들을 어떻게 정의하고 사용하는지 짧게 알아보겠습니다.

.env.local 생성 방법?
. gitignore?
꼭. env.local이라는 이름을 사용해야 하나?
값을 설정하는 방법?
값을 사용하는 방법?
마치며.

1. .env.local 설정 방법?

NextJS 프로젝트를 생성하셨다면 root folder에. env.local이라는 파일을 생성합니다.

root folder란 프로젝트를 생성한 최상위 폴더를 말합니다. 쉽게 이해하기 위해서 node_modules라는 폴더라 생성된 위치와 같은 위치에. env.local이라는 파일을 생성하시면 됩니다. 이렇게 말입니다.

자 사진에 보면 여러 파일들이 많이 보이지만 전부 다 무시하시고 styles라는 폴더 밑에. env.local이라는 파일만 보시면 됩니다.

이렇게 간단한 방법으로. env.local파일을 생성해 주시면 일단 처음 준비는 끝입니다.

2.. gitignore?

위 사진에 보시면. env.local이라는 파일을 포함해 몇몇 파일들은 좀 더 어두운 회색을 띠는 것을 알 수 있습니다.

이는 local에서만 존재하는 파일들입니다. 좀 더 자세히 말씀드리면 소스코드를 github과 같은 플랫폼에 업로드할 때 제외되는 파일들입니다. 그러면 이러한 파일들은 어디서 볼 수 있는 것일까요? 바로. gitignore이라는 파일에서 찾아보실 수 있습니다.

자 이게. gitignore이라는 파일입니다.

이 파일은 create-next-app을 통해서 NextJS 프로젝트를 생성하셨다면 자동으로 생성된 있을 것입니다.

현재로서 가장 중요하게 보아야 할 것은 28번 줄에. env*. local이라는 텍스트입니다.

우리가 생성한. env.local파일의 정보도 들어가 있는 게 확인됩니다.

이 파일에 포함된 모든 파일들은 소스코드가 업로드될 때 제외되는 파일 혹은 폴더들입니다.

혹여나 추가로 어떠한 파일이나 폴더를 업로드할 때 제외해야 한다면 이 파일에서 수정하시면 됩니다.

3. 꼭. env.local이라는 이름을 사용해야 하나?

이런 질문은 NextJS의 공식 홈페이지에 Docs를 확인하면 간단하게 해결됩니다.

공식 Docs에서는 일반적으로. env.local이라는 하나의 파일만 요구된다고 나와있습니다.

하지만 dev 혹은 production에서 따로따로 작동하는 환경변수가 필요할 시. env,. env.development 혹은. env.production이라는 파일들을 따로 생성하여 따로 사용할 수 있다고 나와있습니다.

하지만 정보를 계속 읽어보시면. env.local이라는 파일은 항상 기본값을 덮어씌운다라고 나와있습니다.

즉 다시 한번 말하자면 정말 dev나 production에서 따로 사용되어야 하는 값들이 요구되는 것이 아니라면. env.local이라는 파일 하나만 존재하면 된다는 뜻입니다.

좀 더 자세한 경우는 여기서는 다루지 않겠습니다.

필요하신 경우 아래의 링크에서 확인해 보실 수 있습니다.

공식 홈페이지 링크: https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables#default-environment-variables

4. 값을 설정하는 방법?

자 그럼 이제. env.local파일에 값은 어떻게 설정하는 것인지 알아보겠습니다.

값을 설정하는 방법은 생각보다 아주 간단합니다.

대문자 변수이름=값

이렇게 작성합니다. 예시를 보겠습니다.

이렇게 변수는 모두 대문자로 표기하고 문자마다 언더스코어 (_)를 이용하는 게 보편적입니다.

그리고 =뒤에 (따로 값에 따옴표가 필요한 게 아닌 경우라면) 따옴표를 사용하지 않고 그대로 값을 입력해 주시면 됩니다.

자 이렇게 값을 설정하였다면, 이제는 값을 사용해 보도록 하겠습니다.

이러한 값은 기본적으로 서버에서만 참조할 수 있습니다. 즉 브라우저에서는 사용할 수 없다는 뜻입니다.

하지만 브라우저에서도 사용하는 환경변수가 필요하다면 앞에 NEXT_PUBLIC을 붙이시면 됩니다.

예를 들어 TEST_TEST의 값을 브라우저에서도 사용하고 싶다면 NEXR_PUBLIC_TEST_TEST 이렇게 지정하시면 됩니다.

5. 값을 사용하는 방법?

위와 같이 값까지 지정하였다면, 이를 어떻게 사용하는지 궁금하실 겁니다.

. env.local 파일은 다른 파일과 같이 import 하여 사용하지 않고 조금 다르게 사용합니다.

이를 사용하기 위해서 우리는 process.env를 사용하게 됩니다.

const someVariableName = process.env.SOME_VARIABLE_NAME;
const testTest = process.env.TEST_TEST;

이렇게 process.env를 이용하여 위에 지정한 값을 사용할 수 있습니다.

6. 마치며.

오늘은 가볍게 NextJS에서 환경변수와. env.local에 관해서 알아보았습니다.

이는 실제 업무에서도 자주 사용되는 파일이기에 사용 방법을 익히는 것이 중요합니다.

앞서 언급하였듯, 프로젝트에서 사용은 되어야 하나 다른 누군가에게 보여서는 안 되는 즉 아이디, 비밀번호 혹은 API와 관련된 민감한 값들을. env.local 파일에 지정하고 사용합니다.

오늘 하루도 고생 많으셨습니다.

항상 좋은 일만 가득하시길 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

Typescript: Pick and Omit

OnceBH — Tue, 30 May 2023 01:14:14 +0900

Typescript: Pick and Omit

안녕하세요.

오늘은 타입스크립트의 유틸리티 타입스들 중 pick과 omit에 관해서 알아보도록 하겠습니다.

타입스크립트로 개발을 하면서 새로운 타입들을 지정해줄때 한 번씩 이러한 생각이 들 때가 있습니다.

기존에 작성된 타입 중 하나만 제외시키고 싶은데 혹은 하나를 더 추가하고 싶은데 하는 생각말이죠.

잘 이해가 되지 않으신다고요? 아래의 코드를 보겠습니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};

여기 Person이라는 타입이 있습니다. 이 타입은 각각의 name, age 그리고 hobby 타입을 지정하였습니다.

이때 만약 Person타입에 address라는 key를 추가하고 싶다면?? 혹은 name과 age만 필요하고 hobby는 필요하지 않는다면??

그럴 때마다 아래와 같이 비슷한 타입을 또다시 지정해 주는 게 바람직한 방법일까요??

너무 불필요하게 같은 내용을 반복하는게 과연 좋은 것일까요??

기존의 Person이라는 타입을 조금 변형하거나 바꿔서 사용할 수는 없는 것일까요??

이럴 때 Omit과 Pick을 사용할 수 있습니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};

type personWithAddress = {
  name: string;
  age: number;
  hobby: string;
  address: string;
};

type personWithoutHobby = {
  name: string;
  age: number;
};

1. Omit<type, keys>

먼저 Omit을 사용하기전에 뜻을 먼저 알아보면 생략하다 혹은 혹은 빠뜨리다 등으로 해석할 수 있을 것 같습니다.

여기서는 타입안에 존재하는 여러 key들 중 선언된 key들을 생략하겠다.라는 뜻입니다.

예를 다시 보겠습니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};

아까와 동일하게 Person이라는 타입이 있고 각각의 키들이 존재합니다.

이때 hobby라는 key를 생략한 채 name과 age만을 사용한 변형된 타입을 만들고 싶습니다.

그럴 때는 이렇게 코드를 작성할 수 있습니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};


type PersonWithoutHobby = Omit<Person, 'hobby'>;

// type personWithAddress = {
//     name: string;
//     age: number;
//   };

Omit을 사용한 PersonWithoutHobby는 아래의 주석과 같은 타입입니다.

하지만 주석과 같이 다시 Person과 비슷한 타입을 새로 지정하는 것이 아닌 Person이라는 타입에서 hobby라는 key를 생략함으로써

4줄짜리 코드가 1줄로 줄어들었습니다.

그렇다면 이번에 hobby뿐만 아니라 age라는 key도 같이 생략하고 싶다면?? 그때는 어떻게 해야 할까요?

PersonWithoutHobby라는 타입에서 Omit을 통해 다시 age라는 key를 선언해야 할까요?

정답은 아니오입니다. 그것보다 훨씬 쉬운 방법이 있습니다.

아래의 코드를 보겠습니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};


type PersonWithoutHobbyAndAge = Omit<Person, 'hobby' | 'age'>;

// type personWithAddress = {
//     name: string;
//   };

Omit을 사용하여 여러 key들을 생략할 때 콤마를 사용하지 않고 이렇게 파이프를 사용합니다.

이 부분을 유의하시기 바랍니다.

2. Pick <Type, Keys>

이번에는 반대로 Pick에 관해서 알아보겠습니다. Pick은 모두 알다시피 선택하다는 뜻을 가지고 있습니다.

이는 말 그대로 현재 존재하는 타입에서 필요한 key들을 선택하여 사용하겠다라고 생각하시면 됩니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};

자 이번에도 위와 같이 Person이라는 타입이 있습니다.

그리고 이번에는 age와 hobby를 제외한 name이라는 key만 사용하고 싶습니다.

그렇다면 아래와 같이 Pick을 이용할 수 있습니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};

 type PickNameFromPerson = Pick<Person, 'name'>;

// type PickNameFromPerson = {
//     name: string;
//   };

위와 같이 Pick을 사용하고 원하는 타입과 원하는 key를 지정해 주면 됩니다.

그러면 PickNameFromPerson이라는 타입은 주석된 타입과 동일한 결과를 가져옵니다.

그렇다면 모두 예상하셨듯이 여러 key들을 가져오는 방법도 아실 것이라고 생각합니다.

그래도 예시를 보겠습니다.

이번에는 name과 age를 가져오고 싶습니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};

 type PickNameFromPerson = Pick<Person, 'name' | 'age'>;

// type PickNameFromPerson = {
//     name: string;
//     age: number;
//   };

자 이렇게 여러 key들을 가져올 때는 Omit과 마찬가지로 파이프를 사용하면 됩니다.

3. 마치며

오늘은 Omit과 Pick을 알아보았습니다.

이러한 유틸리티들은 종류가 상당히 많습니다. 가능하다면 하나씩 다루어보도록 하겠습니다.

그리고 특히나 Omit과 Pick은 실제현업에서도 많이 사용되고 있습니다. 그렇기에 알아두시면 좋은 정보가 되지 않을까 싶습니다.

오늘 하루도 고생 많으셨습니다!

그리고 즐거운 코딩 많이 많이 하시길 바라겠습니다!

감사합니다!!

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, nie anzufangen.

Typescript as 대신 satisfies 사용하기

OnceBH — Wed, 29 Mar 2023 23:38:00 +0900

안녕하세요!

저번에 타입스크립트에서 as 키워드에 관해서 알아보겠습니다.

하지만 저번에 언급했듯 as 키워드는 실제 타입에 무관한 값이 들어가 있거나 혹은 그 타입을 충족하지 못하거나 않는 값이 들어가 있어도 받아들이기 때문에 사용하는데 주의를 요하는 키워드입니다. 이러한 문제를 보안할 수 있는 다른 키워드가 있습니다.

이 키워드는 현재 3-4개월 전에 나온 키워드입니다. 이는 satisfies라는 키워드입니다.

오늘은 그럼 satisfies라는 키워드가 어떻게 동작하고 어떻게 사용하면 되는지 짧게 알아보겠습니다.

글을 읽어보시고 공부하시는 것도 좋지만 가장 좋은것은 직접 손으로 타이핑하여 결괏값을 보는 것입니다!

그러니 가능하다면 따라서 코드를 쳐보시기 바랍니다!!

as 대신 satisfies.
사용방법과 주의점.
마치며.

1. as 대신 satisfies.

satisfies라는 키워드는 타입스크립트 4.9 버전에서 등장하는 새로운 키워드입니다.

이는 타입을 선언할 때 사용하는 키워드입니다

앞서 언급하였듯이 as 키워드 또한 타입을 선 헌 할 때 사용되는 키워드이지만 이는 자칫 잘못이용하면 상당히 위험할 수 있는 키워드입니다.

예시를 보겠습니다.

type Person = {
  name: string;
  age: number;
  hobby: string;
};

const per1: Person = {
  name: "John",
  age: 20,
  hobby: "computer game",
};
const per2 = {
  name: "Max",
  age: 22,
} as Person;
const per3 = {
  name: "Kai",
  age: 25,
  hobby: "baseball",
} satisfies Person;

자 이렇게 Person이라는 타입을 지정해 주었습니다. 이는 각각의 name, age 그리고 hobby의 타입을 나타내고 있습니다.

첫 번째 per1의 경우 가장 기본적이고 많이 사용되는 방법입니다.

변수 다음에 타입을 지정하는 방법으로 가장 확실하고 정확한 방법입니다.

이때 name, age 그리고 hobby 중 하나라도 정확하지 않은 타입을 가지거나 빠져있다면 에러를 나타낼 것입니다.

두 번째 즉 per2의 경우 as 키워드를 사용하여 Person이라는 타입을 지정해 주었습니다.

이때 일부러 hobby의 값은 지정하지 않았습니다. 하지만 딱히 에러를 나타내지 않습니다.

이게 바로 as 키워드의 함정입니다. 타입 Person은 3가지의 값을 모두 가져야만 사용이 가능합니다.

하지만 as키워드를 사용한다면 그중 몇 개가 빠져도 별다른 에러를 보여주지 않는다는 것입니다.

이는 실제로 코드가 작동할 때 예상치 못한 에러를 발생시킬 수 있는 확률이 너무 높습니다.

마지막 per3의 경우 as 키워드 대신 satisfires라는 키워드를 사용하였습니다.

이 키워든 느 결과적으로 per1과 같이 꼭 필요한 값이 하나라도 빠져있다면 에러를 나타내게 됩니다.

2. 사용방법과 주의점.

as 키워드나 satisfies키워드나 사용 방법은 동일합니다. 값 뒤에 as 혹은 satisfies 키워드를 작성하신 후 필요한 타입을 작성하시면 됩니다. 하지만 가능하다면 per1과 같이 처음에 값을 지정해 주는 것이 가장 편한 방법일 것입니다.

주의점은 현재 사용하시는 모듈 즉 dependency가 satisfies라는 키워드를 지원하지 않는 버전일 수 있습니다.

이는 자연스럽게 시간이 지나 dependency들이 업데이트되면 자연스럽게 해결될 일이지만, 현재로서 아직 지원하지 않는 dependency가 있을 수 있습니다. 이러한 부분이 아니라면 기존 as 키워드를 사용할 때처럼 사용하시면 되고 오히려 as 보다 정확하고 안전한 방법입니다.

3. 마치며

개발의 공부는 끝이 없는 것 같습니다.

조금만 지나도 새로운 기능 새로운 방법들이 등장하니 말입니다.

하지만 이는 개발자라는 직업의 장점이 아닐까 싶습니다. 결과적으로 새로운 기능과 방법들이 사용자들에게 조금이나마 빠르고 편하고 유저친화적인 프로그램이나 애플리케이션을 제공하는 것이기 때문입니다.

요 근래 저와 정말 친한 누나도 새로 이직을 위해서 개발공부를 시작하였습니다.

제가 옆에서 가능한 한 많은 것을 도와주려고 하고 있지만,

저도 똑같이 경험한 바로 얼마나 힘들고 배울게 많은지 그리고 어려운지 알고 있습니다.

지금도 개발 공부를 시작하거나 하고 계신 분들이 많겠지만 모두 힘내셨으면 좋겠습니다.

파이팅입니다!

Typescript Type Assertion. as 키워드 사용하기

OnceBH — Sun, 26 Feb 2023 20:55:56 +0900

Typescript Type Assertion. as 키워드 사용하기

안녕하세요!

오늘은 타입스크립트를 사용하다 보면 한 번씩 마주하게 되는 키워드 중 하나인 as 키워드에 관해서 말씀드리겠습니다.

타입스크립트는 자바스크립트와 거의 동일하지만 타입이 추가된 superset이라고 보시면 됩니다.

하지만 자유로운 자바스크립트와 달리 타입스크립트를 사용하면 자주 파라미터나 변수의 타입 때문에 머리가 아픈 경우가 한두 번이 아닙니다. 특히 한 오브젝트가 여러 가지 타입을 가질 수 있다면 더더욱 그렇습니다.

자 그럼 이제 as 키워드에 관해서 알아보겠습니다.

as 키워드란?
사용방법?
조심해야 되는 부분?
마치며

1. as 키워드란?

as 키워드란 자바스크립트에는 없는 즉 타입스크립트에만 존재하는 키워드입니다.

타입스크립트에서는 Type Assertion이라고 칭하고 있습니다.

이는 변수나 오브젝트의 타입을 지정해 줄때 사용하게 됩니다.

특히 이 as 키워드는 컴파일러에게 직접적으로 이 변수 혹은 오브젝트의 타입은 이것이다!라고 명하는 것입니다.

앞서 언급하였듯이 가끔은 변수나 오브젝트가 여러 타입을 가지거나 혹은 A타입일수도 B타입 일수도 있는 경우가 있습니다.

아래의 코드를 보시겠습니다.

const arr: Array<string | number> = ['This is string', 1234];

위 코드의 경우 arr는 string 값을 가질 수도 혹은 number의 값을 가질 수도 있습니다.

const returnString = (arr: string[]) => {
    return arr.includes('This is string');
  };
  
  returnString(arr);

또한 위의 코드와 같은 함수가 존재하며 배열 arr는 함수의 파라미터로 값이 이용된다고 가정하겠습니다.

이러한 경우 위의 코드에서는 볼 수 없지만 분명 타입 에러를 나타낼것입니다.

그 이유는 즉 함수는 string으로 된 배열만 파라미터로 받고 싶어 하지만 배열 arr는 string일수도 혹은 number일수도 있는 애매한 타입이기 때문에 이러한 에러가 나타나게 될 것입니다.

이럴 때 사용 할 수 있는 키워드가 봐로 as입니다.

사용 방법을 보시겠습니다.

2. 사용방법?

as 키워드는 항상 값 혹은 오브젝트 뒤에 as라는 키워드를 사용하고 그다음 타입을 지정하시면 됩니다.

코드를 보겠습니다.

    const num = 10;
    const value = num as number;

자 위의 코드와 같이 num이라는 값 뒤 as 키워드를 사용하고 number라는 타입을 지정해 주었습니다.

이 경우 value는 num의 값을 number라는 타입으로 알고 받게 되며 컴파일 때에도 number라고 인식되고 사용됩니다.

하지만 이렇게 사용하지 않고 같은 결과를 가져올 수도 있습니다.

코드를 보겠습니다.

const num = 10;
const value = <number>num;

하지만 이 코드는 리액트와 같은 JSX를 사용하게 된다면 사용하지 않으시는 게 좋습니다.

제 컴퓨터의 경우 이를 타입으로 인식하지 않고 JSX Element로 인식하여 에러를 나타내기 때문입니다.

다른 컴퓨터에서는 어떻게 작동할지 모르겠지만 현재의 경우 as 키워드를 사용하는 것이 좀 더 모던한 방법이라고 할 수 있습니다.

또한 as 키워드는 여러 번 중첩되어 사용될 수 있습니다.

예를 들면 이렇게 말입니다.

const something = value as unknown as System;

이렇게 2번 3번의 여러 번의 as 키워드를 사용할 수도 있습니다.

하지만 실질적으로 그렇게 많이 사용되지는 않습니다.

3. 조심해야 되는 부분?

as 키워드가 타입을 지정해 준다는 것을 알았습니다.

그렇다면 항상 이러한 경우 as 키워드만 사용하는 것이 옳은 방법일까요?

as를 사용할 때 조심해야 되는 부분에 관해서 알아보겠습니다.

예를 들어 한 json 오브젝트를 생성하고 싶습니다.

이에 필요한 타입을 지정해 보겠습니다.

type SomeType = {
  a: number;
  b: string;
  c: boolean;
};

자 위의 코드를 보시면 json을 위해서 생성된 타입은 오브젝트이며 a, b 그리고 c라는 key를 가지고 있으며 각각의 값은 number, string 그리고 boolean입니다. 이때 타입에서 a,b 그리고 c 모두 optional이 아니기 때문에 이러한 타입을 활용한 json 오브젝트는 항상 3개의 값을 모두 가지고 있어야 합니다.

예시 코드를 보겠습니다.

const json: SomeType = { a: 10, b: 'hi', c: true };

이렇게 말입니다. 이때 a, b 그리고 c의 값이 모두 존재해야 하며 undefined일 수 없습니다.

이 중 하나의 값이라도 없거나 undefined라면 타입스크립트가 에러를 나타내게 될 것입니다.

하지만 이때 예시와 같은 as 키워드를 사용하여 작성한다면?

const json2 = { a: 10, b: 'hi', c: true } as SomeType;

const json3 = { a: 10 } as SomeType;

예상대로라면 json2는 문제없이 사용이 가능할 것입니다.

a, b 그리고 c의 값을 모두 가지고 있으며 as 키워드를 사용하여 타입을 someType으로 지정했기 때문입니다.

그리고 json3의 경우 에러가 떠야 합니다. 왜냐하면 someType이라는 타입은 a, b 그리고 c의 값을 모두 가져야 하는 타입이기 때문입니다.

하지만 실제로 코드를 작성하면 json3은 에러를 나타내지 않을 것입니다.

이게 as 키워드의 함정입니다. 실제로 이렇게 된다면 프로그램이 작동할 때 예상치 못한 에러를 마주하게 될 수 있으며, 이는 치명적일 수 있습니다. try 문법을 이용하여 문제가 발생 시 우회는 할 수 있겠지만 분명 이는 예상치 못한 버그를 불러올 수 있습니다.

자 IDE를 통하여 보더라도 json3는 a의 값만 충족하고 있지만 에러가 뜨지 않으며 실제로 json3가 가지고 있는 a의 값 이외에도 b와 c를 사용할 수 있다는 것을 알 수 있습니다. 이러한 함정은 알고 사용하는 것과 모르고 사용하는 것의 차이가 클 것입니다.

이렇기 때문에 사실상 as 키워드를 여기저기 남발하는 것보다는 좀 더 확실하고 명확한 타입들을 지정하여 as 키워드가 사용은 되더라도 그 빈도수가 많지 않게 하는 것이 좀 더 안전합니다.

4. 마치며.

자 오늘은 타입스크립트에서 사용되는 as 키워드에 관해서 알아보았습니다.

자바스크립트에서 타입스크립트로 넘어오면서 또한 ECMA 스크립트의 버전이 향상되면서 더 많고 생소하거나 처음 들어보는 키워드들이 많이 생기고 있습니다. 앞으로 이러한 새로운 키워드들도 조금씩 다루어 보도록 하겠습니다.

개발 실력이 하루아침에 일취월장할 수는 없겠지만, 꾸준히하시면 어느순간엔가 내가 짠 코드의 퀄리티가 높아졌다는 것을 아실 수 있으실 겁니다. 처음은 항상 어렵고 무섭습니다. 하지만 이러한 스트레스를 이겨내고 앞으로 나아갈지 아니면 그만두고 다른 일을 찾아볼지는 스스로의 마음가짐에 달렸다고 생각합니다. 스트레스를 이겨내고 앞으로 나아가는것도 그만두고 다른 일을 찾아 보는것도 그 중 어느것이 좋은방법이고 현명한 방법이다 라고 말할 수 는 없습니다. 하지만 스스로 결정할 수 있는 그 마음가짐이 항상 중요한 것 같습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

타입스크립트 함수 작성 방법

OnceBH — Wed, 22 Feb 2023 02:06:15 +0900

타입스크립트 함수 작성 방법

안녕하세요.

오늘은 타입스크립트를 이용할 때 사용하면 좋은 함수 작성 방법을 알아보겠습니다.

function 함수
arrow 함수
응용
마치며

1. function 함수

function은 우리가 예전에 가장 흔하게 사용하던 함수 작성을 도와주는 문법입니다.

하지만 현재는 ECMA 스크립트의 발전으로 function 함수보다는 arrow 함수를 사용하는 것이 일반적입니다.

하지만 그렇다고 function 함수가 오래되었으니 사용하지 않는 것이 좋다라는 뜻은 아닙니다.

상황에 따라서는 function 함수를 사용하기도 합니다. 또한 function 키워드를 사용하면 함수를 정의하기 전 함수를 부를 수 있는 장점이 있습니다. 이러한 상황이 많지는 않겠지만 정말 가끔가다가 유용하게 사용되기도 합니다.

함수 작성 방법을 알아보겠습니다.

function sayMyName(): string {
  return 'Luis';
}

sayMyName();

타입스크립트를 사용할 시 소괄호 후 콜론을 작성하고 그 후 return에 알맞은 타입을 지정하시면 됩니다.

function sayMyName(name: string): string {
  return name;
}

sayMyName('Luis');

위와 같이 파라미터가 존재하는경우 파라미터에도 필요한 타입을 지정할 수 있습니다.

2. arrow 함수

arrow 함수를 작성하는 것은 현재 최신의 방법이라고 생각하시면 될 것 같습니다.

arrow 함수의 경우 예전 함수보다 가독성이 높아집니다 또한 arrow 함수 이전 function 키워드를 이용한 함수를 작성할 시 thisl 키워드의 사용성에 의문이 종종 있었습니다. 하지만 arrow 함수를 이용하시면 이러한 this 키워드를 사용할 필요가 없어집니다.

자 그러면 짧게 함수를 작성하는 방법을 보겠습니다.

const sayMyName = (): string => {
  return 'Luis';
};

sayMyName();

arrow 함수를 사용하실 경우 function이라는 키워드 대신 변수를 만들어 주게되며 =>라는 키워드를 사용합니다.

이때 함수에 return 값을 지정하는 방법은 function 함수와 동일하게 소괄호 뒤에 콜론을 사용하고 해당 타입을 지정하시면 됩니다.

const sayMyName = (name: string): string => {
  return name;
};

sayMyName('Luis');

파라미터가 존재하는 경우 위와같이 사용할 수 있습니다.

3. 응용

이번에는 제가 자주 사용하는 arrow 함수 작성방법을 알려드리겠습니다.

이러한 함수 방법은 파라미터 존재할때 사용 할 수는 방법입니다.

예를 보시겠습니다.

const sayMyName = ({ name }: { name: string }): string => {
  return name;
};

sayMyName({ name: Luis });

이렇게 작성하는 것입니다.

이렇게 작성했을시 장점은 파라미터의 이름과 값을 좀 더 확실하게 볼 수 있고 함수를 호출할 때 오브젝트로 한번 더 key값을 명확하게 할 수 있기 때문에 실제로 코딩을 할 때 훨씬 가독성이 높고 파라미터가 무엇인지 확인하려 이리저리 화면을 옮겨 다녀도 되지 않을 수 있습니다.

파라미터가 많아지면 이렇게 작성 하시면 됩니다.

const sayMyName = ({ name, age, hobby }: { name: string; age: number; hobby: string }): string => {
  return `My name is ${name} and im ${old}. My hobby is ${hobby}`;
};

const hobby = 'game';

sayMyName({ name: Luis, age: 20, hobby });

또한 key와 동일한 변수를 작성하시면 따로 hobby: hobby라고 작성하실 필요 없이 hobby만 작성하시면 됩니다.

4. 마치며

오늘은 짧게 기본적인 함수를 작성하는 방법과 이를 좀 더 응용하여 작성하는 방법을 배웠습니다.

함수가 어떻게 작성되던지 잘 작동하면 그만이겠지만, 실제로 현없에서는 함수를 어떻게 이해하기 쉽게 짜는지가 정말 중요합니다.

결국 내가 작성한 코드를 다른사람이 보고 사용하며 나 또한 다른 사람의 코드를 보고 사용하고 발전시키며 일할 수밖에 없습니다.

그러니 쉬운 함수라도 너무 성의없게 작성하지 마시고 가독성을 좀 더 생각하시며 작성하시면 좋겠습니다.

개발자로 일해보니 결국에 개발자는 소통을 많이하는 직업입니다. 사실 코드를 작성하는 시간보다 회의를 하는 시간이 더 많은 날도 많습니다. 또한 현업에서는 단지 내가 프로그래밍 언어를 다룰 줄 알고 프레임워크를 다룰 줄 아는 것으로 끝나지 않습니다.

클라우드 개념, 데이터베이스, API, 도커, CI, CD, 등등 알아야 하고 사용해야 할 것들이 산더미 입니다.

개발 공부는 정말 끝이 없는 것 같습니다. 좋은 개발자가 되는 것은 쉽지 않은 것 같습니다. 하지만 노력하고 증진하시기 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

Berichtsheft 아우스빌둥 보고서.

OnceBH — Mon, 16 Jan 2023 03:28:31 +0900

Berichtsheft 아우스빌둥 보고서.

안녕하세요! 오늘은 아우스빌둥을 시작하면 꼭 작성해야 하는 보고서에 관해서 이야기하도록 하겠습니다.

아우스빌둥은 단지 회사와 학교를 오가며 교육을 받는것에 그치지 않습니다.

이는 모두 프로토콜화되어 문서로 저장되어야 합니다. 이때 아쭈비는 3년간의 일과를 보고서로 매일 작성해야 합니다.

이는 아우스빌더가 아쭈비가 성실하게 교육에 임하고 있는지 그리고 더 많은 정보와 도움이 필요한지 확인하는 데 사용하게 됩니다.

아우스빌둥 보고서란?
작성 시 유의점?
마치며.

1. 아우스빌둥 보고서란?

아우스빌둥 보고서란 앞서 언급한 것과 같이 아쭈비가 아우스빌둥 기간 동안 받은 교육과정을 스스로 보고서로 작성하여 아우스빌더에게 제출하는 것입니다. 이는 쓰고 싶지 않다고 쓸 수 없는 것이 아닌 아쭈비로서의 의무 중 하나입니다.

아우스빌둥보고서는 수기로 작성할 수도 또는 온라인으로 작성할 수도 있습니다.

이는 회사에 따라 다릅니다. 저의 경우 회사에서 포털 사이터를 이용하여 온라인으로 작성하였고,

저와 같이 학교를 다니던 다른 친구는 모두 수기로 작성하였습니다. 이때 보고서는 매일 몇 시에 무슨 일을 했는지 등등의 정보를 작성하여야 하며 주관적인 부분을 모두 제거한 객관적인 부분만 작성하여야 합니다.

아우스빌둥 보고서는 점수로 매겨지는 것이 아니기에 압박감을 가질 필요는 없습니다. 하지만 아우스빌더가 항상 읽고 체크하기 때문에, 쉽게 생각하고 작성해서는 안될 것입니다.

또한 아우스빌둥 보고서는 졸업 시험에 꼭 제출해야 하는 필수 문서 중 하나입니다.

아우스빌둥 졸업시험의 실기 시험에서 감독관은 아쭈비의 아우스빌둥 보고서를 받아서 확인하며 이를 토대로 몇 가지 질문을 건넵니다.

2. 작성 시 유의점?

유의점이라면 앞서 언급했듯이 주관적인 부분을 모두 제거하고 항상 객관적인 부분들이 작성되어야 한다는 것입니다.

아우스빌둥 보고서를 작성할 때 장엄하게 작성할 필요는 전혀 없습니다.

보고서라고 하지만 내가 그날그날 몇 시에 무엇을 했는지 짧게 작성하는 게 일반적입니다.

이때 저의 경우 시간에 따라 무엇을 공부하고 일했는지 그리고 왜 그렇게 했는지 짧게 10-15 줄 이내로 작성하였습니다.

하지만 몇몇 다른 회사에서 아우스빌둥을 하는 친구들은 심지어 몇 시에 몇 분 동안 화장실을 다녀왔는지 자세하게 작성하기도 했습니다.

이는 회사마다 다르지만 대부분의 회사가 짧고 간결하며 중요 포인트만 작성된 간단한 보고서를 더 선호하는 것 같습니다.

보고서는 월요일부터 금요일까지 회사 그리고 학교에서 무엇을 공부하였는지 작성되어야 합니다.

저 같은 경우 회사에서 일할 때는 시간 순서에 맞게 작성하였고, 학교를 등교할 때는 그날그날 과목과 무엇을 배웠는지 작성하였습니다.

아우스빌둥 작성을 하지 않아도 되는 시점이 2가지가 있습니다.

하나는 휴가 그리고 다른 하나는 병가입니다.

휴가와 병가는 아우스빌둥 교육기간에 직접적으로 배운 것이 아니기에 따로 무엇을 했는지 작성할 필요는 없습니다

하지만 단지 휴가 혹은 병가와 그 이유를 짧게 작성하시면 됩니다.

3. 마치며.

왜 아우스빌둥 보고서를 매일 작성해야 할까요?

이는 곧 매일매일 아쭈비가 제대로 된 교육을 받았다는 증거이기 때문입니다.

언제 어디서 무엇을 왜 배웠는지 작성되기 때문에 졸업 시험에서 감독관이 아쭈비가 제대로 된 교육을 받은 것이 맞는지 확인하는 수단이 되고 또한 아우스빌더가 보고서를 승인하며 아우스빌더의 역할이 제대로 이루어지고 있는지도 확인할 수 있습니다.

아우스빌둥 보고서는 아우스빌더에 의해 반료될 수 있습니다. 이때 대부분 아우스빌더는 어떠한 부분이 미흡한지 어떻게 개선할 수 있을지 도움을 주기 때문에 보고서가 반료되었다고 낙담하거나 스트레스를 받은 실 필요는 없습니다.

제가 마지막으로 드리는 팁은 보고서를 제발 매일 작성하라는 것입니다.

많은 아쭈비들이 귀찮다는 핑계로 하루 이틀 미루다보면 몇주씩 밀리게 되는 경우가 있습니다.

이는 결국에 아쭈비 자신에게 손해입니다. 왜냐하면 교육받고 일을 배울 시간에 몇 주간 밀린 보고서를 작성해야 하기 때문입니다.

그리고 또한 사실 그저께 일한 것도 제대로 기억이 안 나는데 몇 주 전 몇 시에 무엇을 배웠는지 어떻게 알 수 있겠습니까?

나중에는 보고서라는 이름이 무색하게 소설처럼 쓰이게 되고 이는 혹여나 졸업시험 때 감독관이 질문하여 제대로 대답을 못하거나 또는 보고서에 관해 의문을 가질 수 있는 여지가 있습니다. 그러니 만약 아우스빌둥을 하고 계신다면 제발 보고서는 매일매일 작성하세요.

지금 아우스빌둥을 준비하시는 분이시라면 이를 기억하시고 매일 짧게라도 보고서를 작성해야 한다는 것을 명심하기시 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 계약서를 작성할 때 가장 중요한 정보들

OnceBH — Wed, 11 Jan 2023 04:14:43 +0900

아우스빌둥 계약서를 작성할 때 가장 중요한 정보들

안녕하세요! 오늘은 아우스빌둥을 지원해 줄 회사를 찾은 뒤 회사와 계약을 맺을 때 아우스빌둥 계약서에 어떤 내용들이 적혀있어야 하는지 알아보도록 하겠습니다. 한국어로 되어있는 계약서를 들이밀어도 머리가 복잡하고 긴장되는 한편, 영어도 아니고 독일어로 되어있는 계약서를 받는다면 일단 한숨부터 쉬게 됩니다. 어떤 내용이 중요한지, 혹시 내가 사기를 당하는 것은 아닌지 착취를 당하는 것은 아닌지 등등 이런저런 고민과 꼼꼼히 확인을 한 게 맞는지 머리를 스치는 불안감 등등 계약서를 보내고 난 다음에도 계속되는 걱정들...

오늘은 아우스빌둥 계약서에 꼭 명시되어야하는 중요한 정보들이 무엇인지 알아보도록 하겠습니다.

아우스빌둥 계약서란?
아우스빌둥 계약서에 명시되어야 하는 정보?
마치며.

1. 아우스빌둥 계약서란?

아우스빌둥을 지원해 줄 회사가 있다면 회사와 계약을 해야 합니다.

이를 위해 필요한 게 아우스빌둥 계약서입니다. 당연하게도 계약서 없이 아우스빌둥을 시작하는 것은 말도 안 되고,

노동청과 외국인청 각각 Agentur für Arbeit와 Ausländerbehörde에서 계약서가 없으면 허가와 비자를 주지 않습니다.

계약서는 총 2부가 먼저 제공됩니다. 이 2부는 전체 내용이 동일하며 각각 사인을 한 뒤 한부는 회사 그리고 한부는 아우스빌둥 지원자가 가지게됩니다. 이때 회사마다 다르지만 계약서와 함께 아우스빌둥 3년치의 교육과정과 아우스빌둥 기간 중 회사에서 지원 해 줄 수 있는 정보들이 적혀있습니다. 혹여나 이러한 문서를 받으셨다면 꼭 보관하시기 바랍니다.

2. 아우스빌둥 계약서에 명시되어야 하는 정보?

계약서에 싸인을 하고 아우스빌둥을 시작하는 것도 중요하겠지만, 계약서에 명시된 정보들이 정확하고 필요한 정보들이 기재되어있는지 확인하는 것도 아주 중요합니다.

자 천천히 알아보겠습니다.

1. 이름, 나이, 성별 그 외의 개인정보

아우스빌둥을 지원자의 이름, 성별, 나이 등등 필요한 개인정보들이 기재되어야 하고 Ausbildungsbetrieb 즉 회사의 정보도 적혀있어야 합니다.

2. 아우스빌둥의 종류 즉 아우스빌둥 직군 그리고 아우스빌둥의 목표

회사는 지원자에게 계약서를 통하 한번 더 아우스빌둥의 종류 즉 직군과 그에 따른 목표를 명시해야 합니다.

이때 회사는 어떠한 내용과 실무를 지원자에게 지원할 것인지, 아우스빌둥에 관한 대략적인 플랜 그리고 아우스빌둥을 위한 학교와 그에 필요한 내용들을 명시해야 합니다.

3. 아우스빌둥을 시작하게 될 지역

회사는 지원자에게 아우스빌둥이 어느 지역에서 이루어지는지 명시해야 합니다.

4. 근무 시간

회사는 아우스빌둥 지원자 즉 아쭈비에게 근무 시간에 관한 정보를 명시해야 합니다.

5. 수습 기간

회사는 지원자에게 아우스빌둥 시작 후 수습 기간이 얼마나 되는지 명시해야 합니다.

최소 1개월 최대 4개월까지 수습 기간으로 적용될 수 있습니다.

6. 급여

회사는 지원자에게 아우스빌둥 기간의 급여를 명시하여야 합니다.

3년간의 아우스빌둥에 관한 급여가 나와있는 경우가 대부분이고 이때 연차에 따라서 더 높은 급여를 받게 되는 게 일반적입니다.

7. 휴가 기간

회사는 지원자에게 휴가 기간에 관해서 명시해야 합니다.

대부분 회사가 30일의 휴가를 지원하지만 이는 회사에 따라 다를 수 있습니다.

8. 퇴사 가능성

어떤 경우에 회사에서 아우스빌둥을 그만두거나 그만두게 되는지에 관해서 언급합니다.

9. 그 외의 회사 협약 및 단체등에 관한 내용

즉 회사 내에서 노조와 같은 내용을 언급하여야 합니다. 이는 후에 Tarifvertrag이라는 계약서에서 다루겠습니다.

3. 마치며

자 오늘은 아우스빌둥 계약서에 관해서 알아보았습니다.

사실 제가 알기론 어느 정도 통일된 규격의 계약서이고 대부분의 내용이 분명하고 명료하게 적혀있기 때문에,

계약서를 받으신다면 천천히 제가 앞서 언급한 내용들이 모두 언급되어있는지 찾아보시면 될 것 같습니다.

요즘 제 블로그를 방문하시고 아우스빌둥에 관한 정보를 많이 알아가시고 이를 댓글로 남겨주시는 분들이 많아졌습니다.

제가 블로그를 방문하면서 여러분들께 조금이나마 도움이 될 수 있어 너무 기쁩니다.

오늘도 즐겁고 활기찬 하루가 되길 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

CSR, SSR 그리고 SSG는 무엇인가?

OnceBH — Sat, 31 Dec 2022 23:10:28 +0900

CSR, SSR 그리고 SSG는 무엇인가?

안녕하세요.

오늘은 CSR, SSR 그리고 SSG에 관해서 알아보도록 하겠습니다.

개발을 하다 보면 필연적으로 CSR, SSR 그리고 SSG에 관해서 들어보게 될 것입니다.

오늘은 이에 관한 내용을 짧고 쉽게 알아보도록 하겠습니다.

CSR이란?
SSR이란?
SSG이란?
마무리.

CSR이란?

CSR은 Client Side Rendering의 줄임말입니다.

이는 클라이언트 즉 사용자 더 쉽게 말하자면 사용자가 사용하는 브라우저에서 모든 일들이 이루어진다는 것입니다.

지금까지 홈페이지에 접속할 때 사용되는 가장 보편적이고 잘 알려진 방법으로써 클라이언트는 서버로부터 필요한 모든 자바스크립트 파일을 다운로드하게 됩니다. 이때 로직에 필요한 파일들뿐만 아니라 프레임워크 혹은 라이브러리를 구동할 때 필요한 모든 파일을 서버로부터 다운로드한 뒤 렌더링을 하여 마지막에 사용자에게 페이지를 보여주는 것입니다.

이는 가장 쉬운 방법이지만 브라우저가 다운로드 받아야하는 파일들이 크기 때문에, 사용자에게 보여주기까지의 시간이 꽤나 소요된다고 할 수 있습니다.

대표적인 CSR의 단점을 꼽아보겠습니다.

하나는 앞서 말씀드린 다운로드 받아야하는 파일들이 크다는 것입니다. 즉 사용자가 처음 페이지를 접속하여 렌더링이 완료된 페이지를 보기까지 시간이 오래 걸린다는 것입니다.

두 번째는 SEO에 그다지 적합하지 못하다는 것입니다.

브라우저는 서버로부터 거의 비어있는 html파일을 다운로드하게 되고 모든 파일들이 다운로드되었을 때 스스로 홈페이지에 필요한 내용들을 렌더링 하여 사용자에게 보여주게 됩니다. 그렇다면 이게 왜 SEO와 관련이 있을까요?

그 이유는 바로 구글봇과같은 크롤러가 알 수 있는 정보들이 적기 때문입니다. 우리 클라이언트는 거의 비어있는 html을 서버로부터 받았고 클라이언트에서 스스로 필요한 내용들을 구현했습니다. 이때 홈페이지의 소스코드를 살펴본다면, 흥미로운 부분이 있다는 것을 알 수 있으실 겁니다. 분명 홈페이지에는 정확하게 표현되는 정보들이 소스코드에는 들어있지 않기 때문입니다.

이때 구글봇과같은 크롤러는 소스코드를 읽고 내용을 분석하게 되는데, 당연히 소스코드에는 모든 내용이 담겨있지 않기 때문에, 크롤러가 분석하고 알 수 있는 내용들이 적을 수밖에 없습니다.

SSR이란?

이러한 부분을 보안하기위해서 발전된 모습이 바로 SSR Server Side Rendering입니다.

말 그대로 서버에서 지지고 볶고 다 한 다음 클라이언트에게 주는 것을 말하는 것입니다.

그렇다면 당연히 클라이언트에서 다운로드 받아야하는 파일들이 크게 줄어들게 될 것이고, 다운로드한 파일들을 통해서 라이브러리 혹은 프레임워크와 같은 무거는 내용들을 구현하지 않고 곧바로 서버에서 받은 내용을 사용자에게 보여주기 때문에, 페이지를 로드하는 시간도 크게 줄어들게 됩니다. 그리고 또한 모든 필요한 내용들이 서버에서 작업되어 클라이언트에게 넘겨지게 되니, 구글봇과 같은 크롤러들이 알고 분석할 수 있는 내용들이 크게 늘어나게 되며 이는 곧 검색엔진과 같은 부분의 최적화를 가져올 수 있게 됩니다.

그렇다면 모든 부분을 CSR에서 SSR로 옮기면 좋을까요??

그런 것은 또 아닙니다.

모든 부분을 SSR로 구현하는 것도 무리가 있을뿐더러 항상 홈페이지의 내용들이 서버에서 모든 기능을 갖춘 후 클라이언트로 넘겨지기 때문에 트래픽이 많아진다면 서버가 이를 버티지 못할 가능성도 있습니다.

또한 SSR로 홈페이지를 구현하더라도 로그인 혹은 검색과 같은 사용자의 input을 받아서 처리하는 부분들은 여전히 CSR로 사용되게 됩니다. 그리고 이러한 서버의 과부하의 위험을 덜어 줄 수 있는 것이 바로 SSG입니다.

SSG이란?

SSG이란 SSR과 거의 유사합니다.

SSG는 Server Side Generation의 약자입니다.

우리가 요즘 사용하는 홈페이지들은 모두 동적인 홈페이지들입니다. 하지만 이러한 뜻은 100% 모든 부분들이 동적이라는 것은 아닙니다.

많은 홈페이지들이 정적인 내용들을 보여주는 경우가 많습니다. 즉 바뀌지 않거나 많은 변화가 없는 페이지들을 말합니다.

이러한 페이지들은 다른 사용자가 방문하더라도 똑같이 구현되어 보여야 합니다. 이러한 페이지들을 서버에서 굳이 SSR을 통해서 새롭게 구현하고 클라이언트에게 줄 필요는 없을 것입니다. 이는 오히려 서버에게 불필요한 작업을 만들게 됩니다.

이러한 부분을 개선할 수 있는 것이 SSG입니다.

SSG는 말하자면 서버가 미리 그 페이지의 내용을 저장하고 가지고 있다가 그대로 클라이언트에게 주는 것과 같습니다.

즉 서버는 그냥 파일을 클라이언트에게 전달만 할 뿐 새롭게 구현할 필요는 없다는 뜻입니다.

이는 당연히 서버에서 이루어져야 하는 작업을 줄일 수 있기 때문에 훨씬 효율적이고 더 빠를 것입니다.

Next.JS를 공부하시거나 사용하시다 보면 자연스럽게 듣는 것이 이 3가지 CSR, SSR 그리고 SSG일 것입니다.

이때 공식 문서를 보면 Next.JS 또한 기본값으로 SSG를 지원한다는 것을 알 수 있습니다.

그리고 필요에 따라 SSR 혹은 CSR을 이용할 수 있습니다.

마치며.

오늘은 짧게 CSR, SSR 그리고 SSG에 관하여 알아보았습니다.

당연히 더 깊게 파고들겠다 하면 각자의 수많은 장점과 단점들이 존재할 것이고 어떻게 유기적으로 사용되는지 알 수 있을 것입니다.

CSR이든 SSR이든 무조건 하나는 좋고 하나는 나쁜 것이다 혹은 하나는 모던한 방법이고 다른 하나는 올드한 방법이다라고 단정 지을 수는 없습니다. 결과적으로 각자의 방법으로 모든 100%를 사용할 수 없기 때문입니다.

SSR와 SSG에 관심이 있으시다면 Next.JS를 사용해보시는 것을 강력하게 추천드립니다.

또한 이번에 Next.JS 13이 등장하면서 SSR과 SSG를 사용하는 방법이 더욱더 쉽고 직관적으로 바뀌었습니다.

오늘도 제 블로그를 방문해 주셔서 감사합니다!

꾸준히 개발 공부 열심히 하시기 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbeiretung ist das Gleiche, wie nie anzufangen.

Vim으로 개발하기 Vim을 사용하는 이유.

OnceBH — Sat, 24 Dec 2022 17:47:13 +0900

Vim으로 개발하기 Vim을 사용하는 이유.

안녕하세요! 이번 한해도 마무리 잘하고 계신가요?

독일은 작년 크리스마스까지 코로나로 상당히 조용했었는데, 이번년도부터는 다시 크리스마크 마켓도 열리고

생기를 찾아가는 것같습니다. 오늘은 개발자라면 한번씩 들어보았던 Vim에 관해서 이야기 해보려합니다.

지금은 예전과 달리 UI의 발전으로 코드를 작성할때 키보드뿐만 아닌 마우스를 이용하여 코드 블록을 이리저리 자유자재로 옮겨가며 작업 할 수 있습니다. 하지만 이는 알게모르게 코드를 작성할때 손을 옮겨다니는 시간이 소비되기도하고, 실용적인 면이 Vim에 비하면 떨어지는게 사실입니다. Vim을 사용하게 되면 어떤 장점이 있는지 오늘 짧게 알아보고, 제가 자주 사용하는 키와 단축어들을 알아보도록 하겠습니다.

Vim을 꼭 사용해야 할까?
Vim의 장점?
Vim 단축어.
마치며.

1. Vim을 꼭 사용해야 할까?

Vim을 꼭 사용해야하느냐에관한 질문은 당연히 아니요라고 대답 할 수 있지만, Vim을 한번쯤은 사용해보아야 할까? 라는 질문을 받는 다면 네라고 대답하겠습니다. Vim을 이용하면 코딩할때 이리저리 손을 옮겨다니는 시간을 크게 줄일 수 있고, 코드를 훨씬 빠르게 수정 할 수 있습니다. 한 단어를 지운다거나, 괄호 안의 내용을 지운다거나, 혹은 원하는 블록을 지운다거나 복사한다거나 등등 아주 실용적인 부분을 많이 사용 할 수 있는게 Vim입니다. Vim은 단축어가 많고 처음 사용하신다면 어떻게 코드를 작성하고 저장하는지 등등 어려운 부분이 많을 것입니다. 아무래도 Vim은 우리가 일반적으로 사용하는 텍스트 에디터들과는 약간 다릅니다.

크게 입력모드와 명령모드가 존재하고 명령모드에서는 코드를 작성 할 수 없습니다.

사실 Vim이 손에 익기전까지는 분명 마우스를 사용해서 코드를 작성하는 것 보다 시간이 더 걸릴 수 있습니다.

하지만 익숙해지기 시작하면 Vim의 진가를 느끼실 수 있을 것입니다.

저 또한 지금까지 그냥 일반적으로 키보드와 마우스를 이용하여 코드를 작성했습니다.

하지만 Vim을 배우고 난 후로 코드를 작성하거나 수정할 때 훨씬 빠르게 동작 할 수 있다는 것을 깨달았습니다.

2. Vim의 장점?

Vim을 사용하면 키보드만으로 모든 작업이 가능하기때문에 능률을 높일 수 있습니다.

가령 마우스로 수정하고자 하는 부분들을 클릭하거나 드래그 한 뒤 수정하는 번거로움이 Vim에서는 명령어를 통해서 손 쉽고 빠르게 수정가능합니다. Vim을 사용하면 좀 더 전문가 같이 보일 수 있습니다. 당연히 누군가에게 코딩하는 모습을 보여 줄 기회가 있을지 모르겠지만,

나름 Vim의 뽕이 있습니다. 혹여나 UI가 존재하지 않는 리눅스를 사용해야할 때 유용하게 사용될 수 있습니다.

3. Vim 단축어.

이번에는 제가 주로 사용하는 Vim의 단축키들을 알아보겠습니다.

빨간부분은 사용자가 변경 가능하다는 것을 의미합니다.

예를들어 3G는 3번째 줄로 이동하라는 뜻이지만 이는 244G가 될 수 도 43G가 될 수 도 있다는 뜻입니다.

Vim을 사용하게 되면 심지어 키보드의 방향키를 사용 할 일도 줄어듭니다.

h: 소문자 h는 현재 커서가 머무르는 줄에서 왼쪽으로 한칸 움직입니다.

l: 소문자 l은 현재 커서가 머무르는 줄에서 오른쪽을 한칸 움직입니다.

j: 소문자 j는 현재 커서가 머무르는 줄에서 한칸 아래로 움직입니다.

k: 소문자 k는 현재 커서가 머무르는 줄에서 한칸 위로 움직입니다.

H: 대문자 H는 코드의 맨 처음 줄로 이동합니다.

L: 대문자 L은 코드의 맨 아래 줄로 이동합니다.

M: 대문자 M은 코드의 중간 줄로 이동합니다.

{: 중괄호 {는 코드의 위에 비어있는 줄로 이동합니다.

}: 중괄호 }는 코드의 아래에 비어있는 줄로 이동합니다.

gg: gg는 코드의 맨 윗줄로 이동합니다.

G: G는 코드의 맨 아랫줄로 이동합니다.

3G: 숫자와 대문자 G를 이용하면 숫자에 해당하는 줄로 이동합니다.

i: 소문자 i는 가장 쉬운 입렵모드로 들어가는 방법 중 하나로 현재 깜빡이는 커서에서 왼쪽으로 이동하여 입력을 할 수 있도록 도와줍니다.

I: 대문자 I는 현재 커서가 있는 줄에서 가장 왼쪽 즉 가장 처음부분에서 입력을 할 수 있도록 도와줍니다.

a: 소문자 a는 소문자 i완 반대로 현재 깜빡이는 커서에서 오른쪽으로 한칸 이동하여 입력을 할 수 있도록 도와줍니다.

A: 대문자 A는 현재 커서가 있는 줄에서 가장 오른쪽 쪽 맨 끝에서부터 입력을 할 수 있도록 도와줍니다.

o: 소문자 o는 현재 커서가 있는 줄에서 밑으로 한칸을 새롭게 추가한 후 입력을 할 수 있도록 도와줍니다.

O: 대문자 O는 현재 커서가 있는 줄에서 위로 한칸을 새롭게 추가한 후 입력을 할 수 있도록 도와줍니다.

u:는 명령모드에서 컨트롤 + z와 같은 역할을 합니다. undo

w: w는 커서가 단어마다 움직일 수 있도록 도와주는 키입니다. 이때 단어의 첫알파벳에 커서가 머무르게됩니다.

e: e는 w와 같이 단어마다 커서를 움직일 수 있도록 도와주지만 단어의 맨 마지막 알파벳에 커서가 머무르게됩니다.

0: 숫자 0은 현재 커서가 머무르는 줄에서 가장 왼쪽 즉 가장 첫번째 부분으로 커서를 옮겨줍니다.

$:$는 반대로 현재 커서가 머무르는 줄에서 가장 오른쪽 즉 마지막 부분으로 커서를 옮겨줍니다.

dd: dd는 현재 커서가 머무르는 줄을 모두 지워줍니다.

yy: yy는 현재 커서가 머무르는 줄을 모두 복사해줍니다.

p: p는 복사된 정보를 붙여넣어줍니다.

cc: cc는 현재 커서가 머무르는 부분의 줄을 모두 잘라내기 해줍니다. 이 역시 p를 통해 붙여넣기 할 수 있습니다.

이 단축어들은 제가 실제로 자주 사용하는 단축어들입니다.

이제는 응용 버젼을 알아보겠습니다.

daw,dw: 는 현재 커서가 머무르는 단어를 지우는 명령어입니다.

caw,cw: 는 현재 커서가 머무르는 단어를 지우고 곧바로 입력모드로 들어가게 도와주는 명령어 입니다.

d3w, c3w: 는 현재 커서가 머무르는 단어로부터 숫자에 해당하는 단어를 지우는 명령어입니다.

di": 는 현재 커서가 머무르는 줄에서 " 따옴표안에 존재하는 코드들을 모두 지워줍니다.

di{: 위와 같이 현재 커서가 머무르는 줄에서 { 중괄호 안에 존재하는 코드들을 모두 지워줍니다.

df(: 현재 커서가 위치하는 부분부터 ( 소괄호 까지 코드를 지워줍니다.

dt(: 현재 커서가 위치하는 부분부터 ( 소괄호 전까지의 코드를 지워줍니다.

4. 마무리.

자 오늘은 짧게 Vim에 관해서 알아보았습니다.

요즘은 VSCode나 InteliJ와 같은 텍스트에디터 혹은 IDE에서 Extentions 혹은 Plugins로 Vim을 설치 하실 수 있습니다.

이는 기존 IDE의 강력한 기능들을 사용하면서 Vim까지 사용 가능하다는 뜻인데요.

혹여나 관심이 있으시다면 IDE에서 Vim을 추가로 설치하시는게 좋지 않을까 싶습니다.

오늘도 제 블로그를 방문해주셔서 감사합니다!

내일이면 크리스마스인데, 좋은 연휴보내시고 내년도 즐겁게 시작 할 수 있는 원동력을 만드시기 바라겠습니다.

감사합니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine Perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 온라인으로 신청하는 게 좋은가? 아니면 우편으로 신청하는 게 좋은가?

OnceBH — Tue, 20 Dec 2022 05:02:13 +0900

아우스빌둥 온라인으로 신청하는 게 좋은가? 아니면 우편으로 신청하는 게 좋은가?

안녕하세요! 오늘도 제 블로그를 방문해주셔서 감사합니다.

이번 2022년도도 거의 다끝나가고 있습니다. 하지만 이는 내년의 아우스빌둥을 준비하시는 분들께 꽤나 중요한 시간이 되지 않을까 생각해봅니다. 아우스빌둥은 매년 9월 1일 시작하게 됩니다. 상황에 따라서 조금 빨리 혹은 늦게 시작하기도 하지만 그렇지 않다면 9월 1일이 시작하는 날입니다. 이미 여러분들께 댓글로 말씀드렸지만, 아우스빌둥은 가능한 한 빠른 시기에 지원하시는 게 좋습니다.

예를 들면 1월부터 5월 사이에는 지원을 하셔야, 여러 좋은 여건과 배움의 기회를 많이 제공하는 회사를 많이 만날 수 있습니다.

아우스빌둥을 준비하다 보면 은근 고민되는 게 많습니다.

"독일은 서류를 더 중요하게 생각한다는데... 우편으로 신청해야 하나??" "아니면 간편하고 빠르고 안전한 이메일로 지원을 해야 하나??"

오늘은 이 부분에 관해서 짧게 알아보도록 하겠습니다.

그래서? 온라인 아니면 우편?
마치며.

1. 그래서? 온라인 아니면 우편?

일단 저는 모두 인터넷으로 지원했습니다.

저 역시 아우스빌둥을 준비할 때 네이버에서 이런저런 검색을 해보니 우편으로 보내는 게 더 좋다. 우편으로 보내야지 정성을 더 보일 수 있다.

혹은 직접 회사에 방문해서 이력서를 제출하는 게 좋다. 등등 이런저런 정보들이 많았습니다.

그 뒤 까맣게 잊고 지내다 아우스빌둥 지원시기가 되어 갑자기 생각이 나 여자 친구에게 물었습니다.

우편으로 지원하는 게 좋아? 아니면 직접 가서 이력서를 드리는 게 좋은가?

여자 친구가 말했습니다. 온라인으로 해. 요즘은 온라인으로 다해.

혹시나 아우스빌둥은 다를까 싶어서 주변에 요리사로 아우스빌둥을 하던 누나에게 한번 더 확인차 물어보았습니다.

누나가 말했습니다. 온라인으로 해. 누나 온라인으로 다 지원했어.

그렇습니다. 요즘은 다 온라인으로 합니다.

그리고 이제는 이렇게 아우스빌둥을 찾고 지원해주는 사이트도 아주 많이 생겼습니다.

온라인으로 확인하시면 회사에서 제공하는 연차별 월급, 복지, 위치, 회사에서 필요로 하는 자격요건 등등 모두 한눈에 찾아보고 지원까지 편하게 할 수 있습니다.

2. 마치며.

오늘은 짧게 아우스빌둥 어떻게 지원하는 게 좋은가 알아보았습니다.

뭐 어떻게 보면 당연한 이야기이겠지요. 당연히 온라인으로 지원하지 뭔 우편으로 하겠냐...

그런데 막상 독일에서 아우스빌둥 지원을 준비하시는 분들이라면 은근히 헷갈리고 고민될 수 있습니다.

짧지만 조금이나마 도움이 되는 글이었으면 좋겠네요.

이번 한 해도 마무리 잘하시고 하시려는 일 도전하시려는 일 모두 잘 될 수 있기를 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것 과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

개발자 아우스빌둥 많이 물어보시는 질문들

OnceBH — Sun, 4 Dec 2022 06:14:36 +0900

개발자 아우스빌둥 많이 물어보시는 질문들

안녕하세요! 이번 한 해도 마지막을 달려가는 지금,

올해는 만족스러운 한해를 보내고 계신가요? 금년은 제게 정말 많은 변화를 가져다준 해입니다.

그중 가장 큰 부분은 아우스빌둥을 문제없이 졸업했다는 것이고 회사에서 직원으로 일하고 있다는 것입니다.

또한 이번 연도에 한국에 들러 가족과 친구들도 보고 왔다는 점도 큰 부분입니다. 아우스빌둥을 하면서 도저히 시간이 나지 않았기 때문인데요. 오늘은 다름이 아닌 제가 지금까지 자주 댓글로 받았던 질문들을 정리해보고자 합니다.

댓글을 달아주시는 대부분의 분들이 아우스빌둥을 준비하시거나 관심을 두고 계시는 분들일 거라 생각합니다.

아우스빌둥에 관한 정보가 적기때문에 아무래도 현재 자신의 상황에서 아우스빌둥을 어떻게 준비해야 하는 것인지 또 무엇을 준비하고 무엇을 먼저 준비해야 하는지 많이 궁금하실 것 같습니다. 오늘 이 게시글은 단지 제가 자주 받아 온 질문들에 한하여 글을 작성하는 것이니 혹여나 추가적이거나 다른 질문이 있으시다면 언제든지 댓글로 질문해주시기 바랍니다.

나이?
독일어? 아니면 영어?
프로그래밍 언어?
프로그래밍 실력?
아우스빌둥 면접?
아우스빌둥 신청방법?
마치며

1. 나이?

아마 나이에관한 질문이 제가 가장 많이 그리고 자주 받는 질문인 것 같습니다.

대체로 아우스빌둥에 관심을 가지게 되시거나 혹은 알게 되시는 경우가 빠르면 20대 중반 느리면 30대 중후반까지 되는 것 같습니다.

제게 질문을 주셨던 대부분의 분들이 먼저 하시는 말씀 중 하나는 "제 나이가 어린 편이 아니라서..." 혹은 "제가 나이가 좀 있어서..."입니다.

이 부분에 관해서 대답을 드리도록 하겠습니다.

아우스빌둥을 준비하신다면 나이는 크게 중요하지 않습니다.

분명 어릴 때 즉 10대 혹은 20대 초중반 때 준비를 하시는 게 분명 많은 이득이긴 하지만 나이가 많다고 아우스빌둥을 하지 못하는 것은 아닙니다. 제가 아우스빌둥을 하던 때 학교 반에서 가장 나이가 많던 학생은 30대 중반이었습니다. 분명 비율로 따지자면 10대가 대략 30% 20대가 대략 60% 그리고 30대가 대략 10% 정도 되었던 것 같습니다. 하지만 이는 절대 일반적인 비율이 아닙니다. 직종과 지역에 따라서 천차만별이기 때문입니다. 학교에서 옆반은 물류창고 쪽 직종이었는데 그 반은 오히려 20대 후반에서 30대 중반 사이가 훨씬 많기도 했습니다.

나이를 너무 크게 걱정하시지 않으셔도 되지 않을까 싶습니다.

저 역시 어린 나이에 준비한 것이 아니기에 제가 졸업 당시 20대 후반이었습니다.

그러니 나이가 걸림돌이다 혹은 나이 때문에 걱정이다 하시는 생각은 너무 크게 가지지 않으셔도 될 것 같습니다.

회사에서도 성실히 교육받고 직원으로 남아서 일할 아쭈비를 뽑고 싶어 하지 무작정 어린 친구만 선호하지는 않습니다.

2. 독일어? 아니면 영어?

두 번째 많이 받는 질문은 독일어를 준비해야 하는가? 아니면 영어로도 충분한가?입니다.

제 답은 무조건 독일어입니다. 물어볼 것도 없습니다. 반대로 생각하면 똑같습니다.

외국인이 한국에서 공부하고 직업을 가지려 하는데 한국어를 못한다? 정말 글로벌한 대기업이어서 영어를 주로 사용하는 회사가 아니라면

무조건 독일어입니다. 개발자의 경우 2가지 언어를 모두 어느 정도 할 줄 안다면 좋습니다. 모든 회사가 그런 것은 아니지만, 대부분의 회사가 업무는 독일어로 코딩은 영어로 작업하기 때문입니다. 로마에 가면 로마의 법을 따르라는 말이 있듯이 독일에서는 당연히 독일어를 사용하시는 것이 좋고 당연히 영어보다 독일어에 시간을 좀 더 투자하시는 게 좋습니다.

독일어는 어떻게 공부하는 게 좋을까?라는 질문을 추가로 받기도 하는데, 사실 이 부분은 어느 언어든 마찬가지로 그 나라에서 직접 배우는 게 가장 빠릅니다. 애석하게도 이게 현실인 것 같습니다. 한국에서 독일어를 공부한다고 실력이 덜 늘고 독일에서 독일어를 공부한다고 더 늘고 하는 것은 아니겠지만, 언어를 사용하는 정도의 차이가 너무 큽니다. 한국에서 학원을 다니는 동안 독일어를 제한적으로 사용하는 것과 일상에서 독일어를 억지로라도 사용해야 하는 것은 천지차이입니다. 저 역시 한국에서 독일에 가기 전 B1까지는 따고 가자 했는데, 사실 A1 만 따고 그만두었습니다. 혼자서 공부하는데 너무 제한적이고 추가적인 인풋이 너무 부족했기 때문입니다.

반대로 독일에 와서 3개월 만에 B2까지 땄습니다. 일상에서 어떻게든 언어를 사용한다는 것은 그만큼 많은 차이를 두고 있는 것 같습니다.

하지만 분명 한국에서 혼자 혹은 학원을 다니며 공부하는 게 낭비이다 혹은 부질없다는 것은 절대 아닙니다.

단지 현지에서 배우는 것보다 경험과 사용량이 적고 이는 결국 시간이 더 필요하게 된다는 것을 말씀드리고 싶은 것입니다.

3. 프로그래밍 언어?

가끔 인터넷을 보면 여러 프로그래밍 언어를 배우는 단계가 있는 것처럼 느껴질 때가 있습니다.

예를 들면 초보자들이 가장 배우기 쉬운 언어!! 파이썬!!! 라면서 말이죠.

사실 언어를 배우고 문제없이 사용한다는 것은 모든 언어가 어렵습니다.

단지 문법이 조금 더 쉽다 뿐이겠지요. 프로그래밍 언어는 제가 생각해볼 때 배우기 쉽다 어렵다로 나누는 게 아니라

무엇을 공부하고 어떤 것을 프로그래밍하고자 하느냐에 따라 결정해야 합니다.

웹이라면 타입 스크립트, 자바스크립트, 파이썬, C# 등등이 될 것이고

게임이라면 C++, C# 혹은 자바스크립트가 될 것이고

모바일이라면 Java, Kotlin, Swift 등등 이 될 것입니다.

하지만 요즘은 한 가지 언어로 많은 분야를 공부하고 사용할 수 있습니다.

그렇기에 자신이 배우고 싶은 분야를 설정하고 그에 맞는 언어를 공부하세요.

그래도 정 모르시겠다면 C#, Java, Python 그리고 자바스크립트 중 하나를 선택해서 공부해 보세요.

4. 프로그래밍 실력?

간단합니다.

있으면 좋고 없어도 무관 하다입니다.

아우스빌둥은 회사와 학교에서 처음부터 다 가르쳐줍니다. 프로그래밍 실력이 부족하거나 없다고 문제 되는 경우는 거의 없습니다.

가끔 회사에서 기술 면접을 보는 경우가 있습니다. 이때 프로그래밍 기초를 알고 문제를 해결한다면 더할 나위 없이 좋은 것이고,

문제를 풀지 못한다고 무조건 탈락이다 그런 건 아닙니다. 대부분 이러한 기술면접을 준비하는 데는 지원자의 사고력, 노력을 보려는 것이지 문제를 못 맞혔네? 당신은 애석하게도 탈락입니다... 이렇지는 않습니다.

하지만 당연히 문제를 해결할 수 있다면 그 무엇보다 좋을 것입니다.

그리고 가끔은 기술 면접 후 짧게 왜 그렇게 문제를 해결했는지, 왜 그렇게 코드를 작성하였는지 프레젠테이션을 하는 경우도 있습니다.

5. 아우스빌둥 면접?

면접의 기회가 아직 주어지지 않았는데 면접을 준비할 필요는 제가 볼 때 적습니다. 저는 면접 전 일반적인 몇 가지 질문들을 작성하고 준비하는 것으로 면접 준비를 하였고 회사와 면접 날짜를 결정하고 난 다음부터 회사에 맞게 여러 예상 질문을 준비하였습니다.

면접은 아주 편안한 분위기에서 대략 1-4명의 면접관들과 진행됩니다. 면접은 아주 편하고 부드러운 분위기에서 진행됩니다.

압박감이나 부담감을 가지실 필요는 없습니다. 그리고 기본적으로 아우스빌둥 혹은 직군과 동떨어진 말도 안 되는 질문은 전혀 하지 않습니다. 정말 물어보아야 가족관계 정도입니다. 아우스빌둥을 시작하시면 학교에서 배우시겠지만 기본적으로 독일에서 면접을 진행할 때 절대 하지 말아야 하는 몇 가지들을 배우게 됩니다.

6. 아우스빌둥 신청방법?

가끔 질문을 받다 보면 아우스빌둥을 언제 준비하고 신청해야 하는지 잘 모르시는 분들이 계십니다.

내년 초에 독일에 가서 여름쯤 신청해보려 합니다!라는 글들을 간혹 보게 되는데, 그러면 아마 대부분의 회사들이 답을 주지 않거나 자리가 없다고 할 것입니다. 아우스빌둥은 기본적으로 9월부터 시작되기 때문에 많은 분들이 여름쯤부터 신청하고 면접을 준비하면 되겠다라고 생각하지만 사실은 빠르면 작년 겨울부터 늦어도 3-4월 안에는 신청하시는 게 더 많은 기회를 가지시는 방법 중 하나입니다.

그다음부터는 자신이 원하는 직종의 회사들이 현저히 줄어들게 될 것이 뻔합니다. 아우스빌둥을 준비하신다면 시간이 넉넉하다고 천천히 진행하지 마시고 웬만하면 1월부터 이력서를 제출하시기 바랍니다.

7. 마치며.

자 오늘은 제가 지금까지 많이 받아왔던 질문들을 추슬러보았습니다.

이 글을 통해서 조금이나마 아우스빌둥을 준비하시는 분들께 도움이 되었으면 좋겠고, 혹여나 비슷한 질문이 있으신 분들께 조금이나마 해답이 되었으면 좋겠습니다. 저 역시 처음 개발자 아우스빌둥을 준비할 때 정보 찾기가 너무 힘이 들었습니다.

대부분 정확하지 않거나 오래된 정보였고 그 마저도 정보가 거의 없었기 때문에 어떻게 준비해야 하는가 하는 고민을 정말 많이 했습니다.

그게 이 블로그를 시작하는 계기도 되었고 말이죠. 앞으로도 아우스빌둥에 관한 정보들을 꾸준히 올려보려고 합니다.

오늘 하루도 즐겁게 보내시고 행복한 주말 되시기 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

Next.JS 홈페이지의 언어를 바꾸는 쉬운 방법?

OnceBH — Wed, 30 Nov 2022 04:46:42 +0900

Next.JS 홈페이지의 언어를 바꾸는 쉬운 방법?

안녕하세요.

요즘 홈페이지는 한 가지 언어가 아닌 여러 나라의 언어를 제공하는 경우가 많습니다.

이러한 경우 사용자가 원하는 언어를 내비게이션이나 설정에서 바꿀 수 있는 경우가 많죠.

하지만 사용자 즉 유저가 현재 사용하는 혹은 자주 사용하는 언어를 기본값으로 제공한다면,

사용자는 번거롭게 자신에게 맞는 언어 바꾸는 번거로움이 덜게 될 것입니다.

이번 시간은 Next.JS에서 제공하는 훅을 사용하여 사용자가 현재 사용하는 브라우저의 언어에 따라

그에 상응하는 언어를 기본값으로 보여주는 방법을 알아보겠습니다.

useRouter 훅을 사용하자.
마치며

1. useRouter 훅을 사용하자.

useRouter는 Next.JS에서 기본으로 제공하는 훅입니다.

대부분 다른 페이지로 이동하거나 url을 변경하는데만 사용하지 않았나 싶습니다.

useRouter를 사용하는 방법은 이렇습니다.

(push 혹은 replace의 함수들 경우 여기서 다루지는 않겠습니다.)

import { useRouter } from 'next/router';

const TestComponent = () => {
  const router = useRouter();

return <div>Test</div>
};

export default TestComponent;

이때 router는 몇가지 오브젝트를 가지게 되는데 그중 하나는 locale입니다.

코드 예시를 보겠습니다.

import { useRouter } from 'next/router';

const TestComponent = () => {
  const router = useRouter();
  const { locale } = router;

return <div>Test</div>
};

export default TestComponent;

이 locale이라는 오브젝트는 현재 사용자의 기본 브라우저 언어를 값으로 가지게 됩니다.

영어라면 'en' 독일어라면 'de'와 같이 말이죠.

그럼 이미 끝났습니다.

현재 사용자가 브라우저에서 사용하는 언어를 알았으니 그에 맞는 언어를 설정만 해주면 됩니다.

예시를 보겠습니다.

import { useRouter } from 'next/router';
import de from '../../locale/de.json';
import en from '../../locale/en.json';


const TestComponent = () => {
  const router = useRouter();
  const { locale } = router;
  
  const texts = locale === 'de' ? de : en;
	
  console.log(texts);

return <div>Test</div>
};

export default TestComponent;

위의 코드를 보시면 locale이 'de'라면? 즉 독일어라면 de.json을 그렇지 않다면 en.json을 사용하라고 지정하였습니다.

당연히 언어가 많아지면 그에따라 코드를 변경하고 리팩터링 해야겠지만 현재 대략 2가지의 언어를 제공한다면 이렇게 하는 것도 문제없을 것입니다.

이렇게 locale을 사용한다면 독일어 사용자가 홈페이지를 방문하였을때 기본값으로 독일어로 된 홈페이지가 제공될 것이고 그렇지 않다면 영어로 된 홈페이지가 제공될 것입니다.

사실 브라우저의 언어를 사용하는 방법은 기본 자바스크립트에도 존재합니다.

window.navigator.language를 이용하면 말이죠. 하지만 Next.JS를 사용하신다면 더군다나 타입스크립트를 사용하신다면, 번거롭게 window의 타입을 지정해주실 필요가 없고 또한 Next.JS에서 권장하는 사용방법이기에 사용하실 기회가 있다면 사용해보시길 바랍니다.

2. 마치며

SSR이 쉽게 가능해짐에따라 현재 다니는 회사에서도 모든 리액트 프로젝트를 Next.JS로 변경하려고 하고 있습니다.

SSR는 단순하게 로딩 속도가 빠르다 혹은 클라이언트가 다운로드할 자바스크립트 파일이 작다에 그치지 않습니다.

이는 유저의 편의를 높이고 트래킹에 큰 장점이 있습니다. Next.JS에 흥미가 있으시다면 한번 배워보시는 것도 정말 좋을 것 같습니다.

오늘도 블로그를 방문해주셔서 감사합니다.

무슨 일이든 처음이 가장 힘든 법입니다. 하지만 처음 그 힘든 순간만 이겨내면, 그다음부터는 수월할 것입니다.

하시는 모든 일이 잘 되길 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

지금까지 근황 발표.

OnceBH — Mon, 28 Nov 2022 03:56:01 +0900

지금까지 근황 발표.

안녕하세요! 요 근래 일이 많아지면서 블로그에 게시글이 뜸했습니다.

오늘은 지금까지 있었던 일들을 간단히 정리해보려고 합니다.

아우스빌둥 졸업 후?
드디어 한국 입국 그리고 다시 출국
새로운 가족
현재

1. 아우스빌둥 졸업 후?

아우스빌둥을 졸업한 후 저는 운이 좋게도 계속 다니던 회사에서 채용을 해주어 계속 일하고 있는 상황입니다.

저는 처음부터 프론트엔드를 주로 일해왔지만 지금은 풀 스택으로 백엔드도 많이 다루고 있습니다.

풀 스택의 장점이라면 아무래도 팀의 전반적인 프로세스와 아키텍처를 모두 경험하고 사용해 볼 수 있다는 것입니다.

이는 더 큰 그림을 그리는데 많은 도움을 주고 있습니다. 또한 여러 업무를 받아 해결하면서 실력이 팍팍 느는 것도 하나의 장점입니다.

다만 문제라면 아무래도 독일어입니다.

이제는 독일어를 이해하지 못하거나 말귀를 못알아들어서가 아니라, 독일식 농담이나 일상에서 사용되는 표현을 배우는데 힘이 드는 것 같네요. 독일 농담이 이렇게나 재미없구나 하고 속으로 생각할 때도 여럿 있답니다 ㅎㅎ

아우스빌둥을 졸업 후 뭔가 아쉽기도하고 나 자신이 뿌듯하기도 했는데, 이제 정말 팀의 일원으로 일에만 전념할 수 있어 너무 기쁘고 이런저런 다양한 경험을 해보고 제 자신의 실력도 증진하는데 매진할 수 있어 너무 기쁩니다.

2. 드디어 한국 입국 그리고 다시 출국

독일어와 아우스빌둥 준비 총 1년

아우스빌둥 3년 총 4년이 조금 넘는 시간동안 가족을 한 번도 만나지 못했는데, 이번에 드디어 한국에 다녀왔습니다.

한국은 여자친구와 같이 입국하였습니다.

티켓을 늦게 구매하는 바람에 대략 천유로 조금 넘게 지출하였지만, 3주의 휴가를 내었기 때문에, 충분히 한국에 머무르고 가족들과 즐거운 시간을 보냈습니다. 여자 친구의 경우 한남동 근처에서 직장을 다녔었기에 서울에 도착 후 관광을 다닌 뒤 여자 친구와 만났고 자주 다녔던 거리를 돌아다녔습니다. 여자 친구의 알게 모르게 보이는 그립고 아쉬운 표정을 보면서 이제는 못해도 일 년에 한 번씩은 한국에 오자라고 혼자 다짐했습니다. 그 뒤 서울에서 친구들을 조금 만난 뒤 고향 친구와 다 같이 고향으로 내려갔습니다.

당시 추석전이라 친구의 도움으로 미리 티켓을 끊어 무리 없이 KTX를 타고 고향으로 내려갔습니다. 그 뒤 친구들과 다 같이 집에 모여 이런저런 이야기도 나누고 즐거운 시간을 보냈습니다. 여자 친구는 괜찮다고 편하게 이야기하라고 했지만, 한국어를 많이 알아듣지 못하는 여자 친구를 보고 있으니 미안한 감정이 많이 들었습니다.

그날 이 후 가족들과 같이 주변 관광을 다녔습니다. 이미 가족들과 여자 친구는 구면이기에 아버지께서 휴가를 사용하셔서 다 같이 맛있는 것도 먹고 사진도 많이 찍고 여자 친구에게 좋은 경험을 많이 시켜주려고 노력했습니다.

그리고 아버지께서는 일이 바쁘셔서 타지로 가셨고, 남은 일주일은 다시 서울에 올라와 여자친구와 주변을 돌아다니며 휴식을 보내다 다시 독일로 돌아왔습니다.

처음 한국에 들어간다고 비행기를 탔을 당시 드디어 집으로 (한국에) 가는구나! 하는 생각이 들었습니다.

하지만 대략 3주가 다 되어갈 즈음 저도 모르게 아 이제 슬 집으로 (독일로) 가야지 하는 생각이 들었습니다.

저도 모르게 대략 5년간 독일에 살아오면서 독일에 있는 집이 제가 머무르고 지내야 하는 집이라는 생각을 하고 있었던 것 같습니다.

3. 새로운 가족

이번 한국 여행은 제게는 가족과 친구들을 만나는 시간이었지만, 여자친구는 중대한 결정을 내리는 시간였습니다.

여자 친구는 예전부터 한국에 머무르며 못해도 2-3년 정도 지내고 싶어 했습니다.

같이 동일로와 아우스빌둥을 시작하기 전부터 논의한 결정이었습니다.

제 아우스빌둥이 끝나면 한국에 입국해서 머무르며 경험을 쌓고 문화도 배우고 싶다는 이유였습니다.

저 역시 제 아우스빌둥을 위해 원하지 않는 독일로 돌아오게 된 여자 친구에게 당연한 결정이라고 생각하고 그렇게 하자고 했습니다.

하지만 현재 여자 친구는 스스로의 비지니스를 준비하고있고, 또한 이번 한국 여행을 다녀오면서, 여자친구의 생각과 미래에 대한 방향이 많이 바뀐것 같았습니다. 여행을 다녀온 후 여자친구는 제게 가능하면 독일에 더 머무르고 싶다고 하였고, 저희는 한국을 생각하여 입양할 수 없었던 강아지를 한 마리 입양했습니다. 이제 7개월 된 새끼 강아지인데, 똑똑하고 순한 게 벌써 떼어놓지 못할 가족이 되었네요.

4. 현재

현재는 일에 집중하고 아우스빌둥을 하면서 고생했던 여자 친구를 위해서 가능한 한 모든 금전적인 부분을 도와주려 하고 있습니다.

이에 여자 친구도 지난 3년간 짊어졌던 경제적 부담이라던지, 제 독일 이 때문에 항상 동행해야 했었던 불편함이 많이 줄었네요.

현재까지 계속해서 재택근무를 하기 때문에, 어제는 새로운 책상을 하나 장만했습니다.

높낮이가 조절되는 책상인데, 블랙프라이데이여서 그런 가 운 좋게 반값에 구매할 수 있었네요.

사용해보니 생각보다 너무 편하고 좋습니다. 저는 또한 키가 커서 항상 이점이 불편했는데, 자유자재로 높낮이가 조절되어 제 키에 맞추어 사용하기 편하고 또한 너무 오래앉아있때는 책상 높이를 최대로 올려서 일어서서 일할 수 있어 너무 좋습니다.

여러분은 어떻게 지내고 계신가요?

이번 연도도 이제 한 달 조금 남았네요.

이번 연도에 달성하고자 하는 목표는 잘 달성하셨나요? 그렇다면 축하드립니다.

그렇지 않다면 남은 한 달 최선을 다해 보시기 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

Next.JS 데이터 패칭 getStaticProps.

OnceBH — Sun, 14 Aug 2022 21:25:28 +0900

Next.JS 데이터 패칭 getStaticProps.

오늘은 데이터패칭 data fetching에 사용되는 여러 방법 중 하나인 getStaticProps를 알아보겠습니다.

getStaticProps란?
사용방법.
마치며.

1. getStaticProps란?

Next.JS는 React.JS의 Framework입니다.

하지만 왜 이러한 getStaticProps라는 기능이 필요할까요?

잠깐 짧게 알아보겠습니다.

먼저 Next.JS에서는 대략 3 혹은 4가지의 data fetching이 있습니다.

getStaticProps, getStaticPaths, getServerSideProps 그리고 Client Side.

왜 이러한 여러가지 방법이 존재하는 것일까요?

이는 Next.JS가 기본 SSR 즉 Server Side Rendering을 지원하기 때문입니다.

그 반대는 당연히 CSR 즉 Client Side Rendering입니다.

SSR는 모든 필요한 렌더링을 완성시킨 뒤 Client에게 보냅니다.

그리고 Client 즉 브라우저는 이를 받아 리액트를 통해 렌더링만 해주는 것입니다.

이는 크게 2가지 장점이 있습니다.

첫 번째는 Client가 다운로드하고 준비해야 하는 파일 즉 Javascript가 적어진다는 것입니다.

이는 렌더링 속도를 크게 향상해줍니다.

두 번째는 bot이 필요한 데이터들을 바로 읽을 수 있다는 것입니다.
클라이언트에서 준비되고 렌더링 된 후 data fetching을 통해 나온 결과물은 우리가 눈으로 볼 때는 아무 문제없어보일지 몰라도

bot이 볼때는 아닙니다. 전체 HTML 파일을 들여다보면 데이터가 늦게 fetching 되어 사실 소스코드에 들어있지 않는 경우가 많기 때문입니다. 이는 SSR을 통해서 아주 손쉽게 개선될 수 있습니다.

getStaticProps가 그 방법 중 하나입니다.

이는 data fetching에 사용되며 대부분 처음 한 번만 fetching 되면 그 뒤 거의 변화가 없을 데이터들에 사용됩니다.

E-Commerce를 예로 들어보자면 제품의 이름, 정보, 가격 그리고 이미지 등이 이에 해당됩니다.

이러한 정보들은 사용자에게 보이면 되는 정보들입니다. 사용자가 상호작용하여 제품의 이름 혹은 가격을 변경하지는 않기 때문입니다.

자 그럼 코드를 보시겠습니다.

2. 사용방법.

import { NextPage } from 'next';

interface Props {
  id: number;
  name: string;
  age: number;
}

const AboutPage: NextPage<{ data: Props[] }> = ({ data }) => {
  return (
    <div>
      {data.map(({ id, name, age }) => {
        return (
          <div>
            <div>{id}</div>
            <div>{name}</div>
            <div>{age}</div>
          </div>
        );
      })}
    </div>
  );
};

export const getStaticProps = async () => {
  // const res = await fetch('https://rickandmortyapi.com/api/character');
  // const { results }: Props = await res.json();
  
  const data = [
    { id: 1, name: 'Mike', age: 20 },
    { id: 2, name: 'Michael', age: 30 },
    { id: 3, name: 'Kai', age: 28 },
  ];

  return {
    props: {
      data: data,
    },
  };
};

export default AboutPage;

코드를 짧게 짧게 나누어 확인해보겠습니다.

import { NextPage } from 'next';

interface Props {
  id: number;
  name: string;
  age: number;
}

먼저 저는 현재 타입 스크립트를 사용하고 있습니다. 그렇기에 interface를 통하여 타입들을 지정해주었습니다.

이는 컴포넌트가 파라미터로 받을 수 있는 타입들을 설정해준 것입니다.

즉 제가 만든 컴포넌트는 props로 id, name 그리고 age를 파라미터로 받을 수 있으며 이때 각각 int, string 그리고 int 타입이어야 합니다.

const AboutPage: NextPage<{ data: Props[] }> = ({ data }) => {
  return (
    <div>
      {data.map(({ id, name, age }) => {
        return (
          <div>
            <div>{id}</div>
            <div>{name}</div>
            <div>{age}</div>
          </div>
        );
      })}
    </div>
  );
};

이건 제가 만든 컴포넌트입니다. 컴포넌트의 이름은 AboutPage이며 data 파라미터로 받게 됩니다.

이때 data의 타입은 앞서 언급한 Props interface를 사용합니다. 그리고 []를 사용하고 있습니다.

즉 Array안에 오브젝트를 두겠다는 뜻입니다. 이때 map을 통해서 각각의 key 즉 id, name 그리고 age를 통해서 값을 리턴합니다.

export const getStaticProps = async () => {
  // const res = await fetch('https://rickandmortyapi.com/api/character');
  // const { results }: Props = await res.json();
  
  const data = [
    { id: 1, name: 'Mike', age: 20 },
    { id: 2, name: 'Michael', age: 30 },
    { id: 3, name: 'Kai', age: 28 },
  ];

  return {
    props: {
      data: data,
    },
  };
};

자 이제 핵심입니다. getStaticProps를 이용하여 클라이언트에게 데이터를 주기 전 데이터 패칭을 한 뒤

정보를 컴포넌트에게 넘겨주고 마지막으로 서버는 렌더링 한 데이터를 넘겨줍니다.

주석은 데이터 패칭을 하는 예시를 적어놓은 것이며, data는 임의의 데이터를 제가 직접 만든 것입니다.

이 데이터는 마지막 props를 통하여 컴포넌트에게 전달됩니다. 저는 data: data라고 코딩하였지만,

현재의 자바/타입 스크립트는 가볍게 data만 주어도 됩니다.

예를 들면 이렇게 말이죠.

  return {
    props: {
      data,
    },
  };

그리고 마지막으로

export default AboutPage;

컴포넌트를 export 합니다.

일반 React에서는 이러한 기능들을 사용할 필요가 거의 없었습니다.

기본적으로 CSR을 제공하기에 개발자들은 클라이언트에서 데이터 패칭이 이루어질 수 있게 useEffect내에서 사용하는 경우가 많았습니다. 하지만 이는 클라이언트가 데이터 패칭을 볼 수 있다는 큰 단점이있습니다. 이러한 getStaticProps를 이용하여 SSR 중 데이터패칭을 가능하게 하고 이는 클라이언트에게 보이지 않아 보안면에서도 장점을 가지고 있습니다.

3. 마치며.

리액트 시장이 커 저 가며 새로운 여러 프레임워크들도 등장하기 시작했으며 이 중 하나가 Next.JS입니다.

현재 제가 다니는 회사에서도 대대적으로 Next.JS를 이용하여 재구축하려 합니다.

사실 Next.JS는 리액트를 사용하는 프레임워크이기에 일반 리액트와는 크게 차이가 없습니다.

그렇기에 리액트를 사용할 줄 아신다면 Next.JS도 크게 어렵지 않을 것입니다.

앞으로 남아있는 getStaticPaths, getServerSideProps 그리고 Client Side도 차근차근 올려보겠습니다.

부지런히 개발 공부하시는 모습이 너무 멋집니다!

오늘도 제 블로그를 방문해주셔서 감사하고 앞으로도 좋은 일만 가득하시길 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

개인적인 개발자 아우스빌둥 졸업 리뷰

OnceBH — Tue, 2 Aug 2022 04:49:38 +0900

개인적인 개발자 아우스빌둥 졸업 리뷰

안녕하세요!

오늘은 제가 3년간 아우스빌둥을 하면서 느낀 점 그리고 전체적으로 3년간 배운 것, 그리고 느낀 점을 써보려 합니다.

아우스빌둥은 기본적으로 개발자뿐만 아니라 다양한 분야에 존재합니다.

예를 들면 자동차 정비, 수리, 커피숍, 은행, 디자이너, 물류, 꽃집, 레스토랑, 음악, 방송, 등등 셀 수 없이 많이 존재합니다.

그리고 당연히 각각의 직군에 필요한 혹은 요구되는 사항, 요소들이 다릅니다.

제가 블로그를 처음 시사한 계기는 다름 아닌 아우스빌둥이었습니다.

저 역시 처음 아우스빌둥을 준비할 당시 여러 커뮤니티와 구글을 통해 검색하고 찾아다녔지만, 사실 그렇다 할만한 정보를 찾기는

아무래도 제한적이었습니다!. 그 많은 분야들 중에 제가 원하는 분야의 아우스빌둥 정보가 있을 리 만무했죠.

그래서 추후 개발자로 아우스빌둥을 준비하시거나, 정보를 찾으시는 분들께 조금이나마 제 경험과 사실을 알려드리기 위해 시작하였습니다.

현재 아우스빌둥이 예전과 비교해 많이 알려져 있고, 또한 질문들도 받게 되는데, 나름 정보를 나눌 수 있어 기쁘고, 조금이나마 도움이 될 수 있어 뿌듯합니다.

제가 개발자 아우스빌둥을 시작하면서 느낀 가장 중요한 점은 대략 3가지입니다.

첫 번째는 당연스럽게도 독일어입니다.

언어가 부족하다는 것은 단지 의사소통이 불편하다에 국한되지 않습니다. 이는 스스로 자존감과 자신감을 깎아먹게 되기도 합니다.

처음이야 내 모국어가 아니니까. 배우는 중이니까 하고 스스로 다독이지만 이 기간도 길어지면 자연스럽게 위축될 수밖에 없습니다.

저 역시 대략 아우스빌둥 2년 차 중반까지 대화에 적극적으로 참여하지 못하고 옆에서 웃으면 웃고, 얘기하면 경청하고 그 정도였습니다.

하지만 이런 일이 자꾸 반복되면, 내가 원하든 원하지 않았든 아주 수동적으로 보이고, 적극적이지 못한 사람으로 남들에게 인식될 수밖에 없습니다. 저 역시 2년 차 중반까지 아우스 빌더에게 항상 듣던 말이 대화에 적극적으로 참여해 야한 다였습니다. 중요한 건 제가 적극적이지 못하고 수동적인 사람이 아니라는 것입니다. 아마 한국어로 대화했다면 벌써 재잘재잘 수다를 떠느라 바빴을 것입니다.

하지만 독일어로 대화해야 하고, 제 자신의 모습을 보일 수 없고 항상 위축된 것처럼 보인다는 것은 제게 사실상 스스로 너무 힘들고 자존심도 많이 상했습니다. 그러니 독일어를 꼭 정말 꼭 많이 공부하시고 대화를 많이 하셔야 합니다.

저는 아우스빌둥 2년 차까지 혼자서 아우스빌더로부터 직접적으로 과제를 받았기에, 따로 다른 직원과 대화 할 기회가 크게 존재하지 않았습니다. 하지만 3년차부터는 팀에서 실제 직원들과 같이 일해야하고, 이를 위해 2년차 중반부터 회사에 존재하는 여러 팀을 방문하여 대략 1-2주간 머물며 팀의 분위기와 일을 배울 수 있는 프락티 쿰을 하였습니다. 이 시기부터 제 독일어도 크게 발전된 거 같습니다.

지금은 대부분의 의사소통을 아무 문제없이 하고 있습니다. 하지만 제가 아우스빌둥을 시작하는 시기부터 원만하게 의사소통할 수 있는 독일어 실력이었다면, 아마 그 3년간 못해도 뭐 하나는 더 배우지 않았을까요??

당시 제 독일어 실력은 B2였습니다.

두 번째는 질문하기입니다.

모르는 것은 물어봐야 합니다. 하지만 모른다고 계속 물어보라는 뜻은 아닙니다.

가장 좋은 것은 먼저 스스로 찾아보는 것입니다. 그리고 정말로 못 찾겠다면 그때 물어보는 것입니다.

이때 제 스스로 찾아보려는 시도가 있었고, 이에 지금까지의 결과를 같이 말하는 게 중요합니다.

혹은 회의 중 모르는 혹은 전문용어를 사용하여 이해하지 못하는 상황이 있습니다. 특히 처음에는 정말 많습니다.

회의가 한창 진행 중이고 서로 많은 아이디어를 나누는 중이라도 이해가 안 되거나 모르는 부분에 관해서는 물어보는 것이 좋습니다.

회의에서 가장 중요한 부분은 서로 같은 대화에 참여하고 있고, 같은 지식을 공유하고 나누는 것입니다.

이는 외국인이라서, 혹은 나만 못 알아봐서 물어보기가 껄끄럽다... 하는 행동이 전혀 아닙니다.

실제로 같은 독일인들도 한창 회의 중 이해가 되지 않는다면 한창 회의 중이라도 자연스럽게 물어봅니다.

예를 들면 Hey! Sorry ich hab eine dumme Frage, was ist ***? 이런 식으로 말이죠.

마지막은 나의 권리를 챙겨라입니다.

제가 아우스빌둥을 하면서 회사로부터 가장 많이 받은 권유와 제안은 휴가를 사용하라는 것이었습니다.

저는 한국에서 아르바이트나 공장에서 일한 적이 많았습니다. 당시 많아봐야 휴가 3일 혹은 1주일?이었습니다.

하지만 아우스빌둥을 시작하면서 갑자기 휴가가 30일로 늘어났습니다. 도통 어디에 언제 써야 할지 전혀 감이 오지 않더군요.

갑자기 3배로 불어난 자유시간을 어떻게 사용해야 할지도 모르겠고, 당시 정말 휴가가 필요한가?라는 생각조차 들게 되었습니다.

지금이야 감사하다고 사용하지만요. 제가 드리고 싶은 말은 권리를 챙기고 누리라는 것입니다.

휴가가 생기면 휴가를 사용하고 몸이 아프면 병가를 쓰고, 아우스빌둥에 무언가가 필요하다면 고민하지 말고 물어보고 받으라는 것입니다.

특히 아우스빌둥 기간 동안 회사는 일과 공부에 필요한 물품들을 모두 제공해주어야 합니다. 이는 법적으로 그렇습니다.

그렇기에 아우스빌둥을 위해 필요한 게 있다면 회사에 혹은 아우스 빌더에게 꼭 물어보세요. 저 역시 학교와 졸업시험에 필요한 책과 서적들을 모두 회사에서 제공받았습니다. 아마 스스로 구매하려 했다면 대략 10만 원 이상은 들었을 것입니다.

제 블로그를 통해 여러분들과 아우스빌둥에 관한 정보를 나누고 전달해드릴 수 있어 항상 기쁩니다.

앞으로 더 이상 아쭈비는 아니지만 가능한 한 많은 정보를 나누려고 항상 노력하겠습니다.

짧다면 짧고 길다면 긴 3년의 시간이 마무리되었고, 저는 아우스빌둥에서 한 발짝 더 나아가 직원으로 일하며, 여러분들께 독일의 소식과 정보를 드리도록 노력하겠습니다. 감사합니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.
Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 졸업!!! 구두시험, 프레젠테이션

OnceBH — Sun, 17 Jul 2022 23:56:09 +0900

아우스빌둥 졸업!!! 구두시험, 프레젠테이션

안녕하세요!

드디어 저번 주 아우스빌둥을 끝마쳤습니다.

오늘은 구두시험에 관해서 알아보도록 하고 다음에 아우스빌둥 리뷰를 해보도록 하겠습니다.

구두시험 준비
구두시험 당일
마치며

1. 구두시험 준비

먼저 구두시험은 아우스빌둥 최종 졸업시험입니다.

졸업시험은 먼저 필기, 프로젝트 그리고 구두시험으로 나뉘게 됩니다.

필기시험은 말 그대로 지금까지 배웠던 것들을 다루는 필기시험입니다.

그리고 응시자는 프로젝트를 준비합니다. 프로젝트는 이미 다른 게시글에서도 많이 언급하였듯이, 회사와 관련된 프로젝트여야 합니다.

또한 IHK에 승인을 얻어야지만 프로젝트를 수행할 수 있습니다.

결과적으로 응시자는 프로젝트 그 자체를 제출하지 않습니다. 그 이유는 앞서 언급했듯이 회사와 관련된 프로젝트이기 때문입니다.

그렇기에 응시자는 프로젝트 대신 문서를 제출합니다. 이 문서는 당연히 프로젝트에 관한 모든 내용을 포함합니다.

문서는 당연히 그 단계에 따라 나뉘어 작성되어야 합니다. 또한 가능한 세세한 디테일을 신경 써야 합니다.

이렇게 프로젝트를 완료하고 문서화까지 마쳤다면 다음은 온라인 포털을 통해 문서를 제출하여야 합니다.

여기서 응시자는 온라인 포털에 문서를 pdf로 제출하고 한부는 제본하여 책으로 IHK에 직접 보내야 합니다.

당연한 말이지만 데드라인을 꼭 지켜야 합니다. 또한 프로젝트의 승인을 얻기 위해 제출한 제출서에 적은 프로젝트 이름이 꼭 같은지 확인하세요. 많이 하는 실수입니다.

자 문서를 제출하였다면 다음은 프레젠테이션을 만드는 것입니다.

응시자는 자신의 프로젝트를 프레젠테이션을 통해 발표합니다. 이때 최대 15분을 넘지 말아야 하며, 프레젠테이션에 필요한 모든 도구들을 직접 준비해야 합니다. (빔프로젝트만 IHK에서 제공합니다.)

즉 노트북, 레이저 포인터, 여분의 케이블 등등을 직접 준비하셔야 합니다.

또한 아우스빌둥을 시작하면 아쭈비는 3년간 빠짐없이 보고서를 제출해야 합니다. 이 보고서는 구두시험 당일 모두 인쇄되어야 하며,

감독관은 보고서에 기재된 내용을 질문할 수 있습니다. 기본적으로 감독관은 프로젝트와 보고서에 관련된 내용 이외에 모든 내용을 구두시험에서 물어볼 수 있습니다. 그렇기에 마지막까지 긴장의 끈을 놓지 않고 준비하는 게 중요합니다.

2. 구두시험 당일

저는 구두시험 당일 기차를 타고 시험장에 가야 했습니다. 기차로 대략 1시간 반을 달려 IHK건물에 도착하였습니다.

옷은 가능한 한 깔끔하고 단정하게 입고 가려 했습니다. 당시 저는 가벼운 패턴이 있는 와이셔츠, 검은색 청바지와 벨트 그리고 갈색 구두를 신고 갔습니다. 건물에 들어가니 안내데스크에서 일하시는 직원분이 제게 다가와 오늘 시험이 있는지 여쭈어보셨습니다.

저는 맞다고 대답하였고 제가 시험을 치는 직군에 관해 이야기했습니다.

직원분은 제게 어떻게 시험장에 가야 하는지 친절하게 알려주셨습니다.

제가 시험장에 도착했을 때 감독관 중 한 분을 만났습니다. 먼저 인사를 하고 제게 프레젠테이션 준비를 위한 방을 알려주셨습니다. 또한 제게 혹시 시험을 조금 일찍 시작할 수 있을지 여쭈어보셨습니다. 저는 알겠다고 말씀드리고 프레젠테이션 준비를 하고 있었습니다.

그리고 얼마 지나지 않아 3분의 감독관이 들어오셨습니다. 당시 2분은 대략 40대 혹은 50대였고 한분은 30대가량으로 보였습니다.

프레젠테이션을 시작하기 전에 감독관이 정말 많이 물어보는 질문이 있습니다. 그것은 프레젠테이션의 대상이 누구인지에 관한 질문입니다.

"Bevor wir Präsi anfangen, können Sie bitte mir sagen, Wer Ihre Zielgruppe ist?"와 같이 질문합니다. 이는 사실 정해진 답은 없습니다. 하지만 안정적은 답은 Prüfer입니다. 즉 감독관이라는 뜻입니다. 그 후 프레젠테이션을 준비하였습니다.

당시 연습을 많이 했었기에 전혀 떨거나 버벅거리지 않았습니다. 또한 가능한 한 눈을 자주 마주치려고 애썼습니다.

이렇게 프레젠테이션은 문제없이 15분에서 조금 넘은 15분 30초 정도에 마쳤습니다.

그 후 한 감독관이 제게 보고서에 관한 질문을 하였습니다. 저는 가능한 한 문법에 어긋나지 않게 그리고 자연스럽게 이야기하려 애썼습니다.

당연히 독일어는 제 모국어가 아니기에, 긴장을 많이 하면 간결한 문장보다 장엄하고 예시를 많이 들어 넓게 펼쳐 이야기하기 때문입니다.

저는 시험을 조금 일찍 시작한 것 때문인지 다른 아쭈비보다 문제를 더 많이 받았습니다. 문제 또한 프로젝트에 관련된 문제들뿐만 아니라 전반적으로 학교에서 배우는 모든 것을 물어보았습니다. 저는 가능한 한 모든 대답을 하려 애썼고 정말 모르는 상황이 아니면 대답을 하려 애썼습니다. 그리고 시험이 모두 끝난 뒤 감독관 중 한 분이 제게 노트북과 짐을 정리하여도 좋다는 말과 여기서 잠시만 기다려달라는 대답을 들었습니다. 당시 감독관들이 정말 까칠하고 무뚝뚝했기 때문에 시험을 완료했다는 기쁨보다 걱정이 앞섰습니다.

하지만 감독관들은 다른 방에서 제 아우스빌둥 졸업 여부를 논하며 웃고 화기애애하게 이야기하는 것을 듣게 되었습니다.

그리고 대략 5분 후 감독관들이 아주 환하고 친절하게 제게 오더니 아우스빌둥과 졸업시험에 관한 제 의견을 물어보기 시작했습니다. 그리고 마지막으로 제가 회사에서 정직원으로 계속해서 일할 수 있는지 물어보았습니다. 대답이 끝나고 제게 종이 한 장을 건네주었습니다.

합격증이었습니다.

아우스빌둥은 원래 9월까지 진행되지만, 합격증서를 받는다면 그 즉시 아우스빌둥은 종료됩니다.

그렇게 제3년의 아우스빌둥은 종료되었습니다. 이 기쁜 마음을 여자 친구와 가족에게 알렸습니다.

기분 좋은 발걸음으로 회사에 먼저 갔습니다. 회사에서 아우스빌둥 책임자와 짧은 면담을 가졌습니다.

그다음 정직원으로 제 계약이 변경되면 제 비자가 비 뀌어야 하기 때문에 이에 관해서 논의한 뒤,

회사에서 가능한 한 빠르게 Ausländerbehörde와 접촉하였습니다.

그렇게 제 아우스빌둥은 끝이 났고 저는 2일간 휴가를 보냈습니다.

그리고 다시 저번 주 목요일부터 다시 일을 시작하였습니다.

3. 마치며

이렇게 아우스빌둥이 끝이 났습니다. 3년간의 노력이 결실을 맺었고, 좋은 회사와 좋은 팀 덕분에 졸업 후에도 계속 일할 수 있게 되었습니다.

처음 아우스빌둥을 찾겠다고 지원서를 제출하고 면접을 보러 다니고, 아우스빌둥을 시작한 뒤 학교에서 독일 이 때문에 온갖 고생을 하고,

회의에서 잘 들리지도 알아듣지도 못해 항상 엉뚱한 대답을 해야 했던 시간들, 모두 하나같이 힘들고 고단했지만, 지금의 결과를 가져올 수 있게 했던 과정들이었습니다. 제 아우스빌둥은 끝이 났지만, 누군가는 아우스빌둥을 하고 또는 준비하고 계실 겁니다.

제 글이 조금이나마 도움이 되었으면 좋겠습니다. 항상 파이팅입니다!

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

UML 상태 다이어그램이란? State diagram이란?

OnceBH — Fri, 10 Jun 2022 21:18:50 +0900

UML 상태 다이어그램이란? State diagram이란?

안녕하세요!

오늘은 UML 중 하나인 상태 다이어그램 즉 State diagram 독일어로는 Zustanddiagramm을 배워보도록 하겠습니다.

상태 다이어그램은 활동 다이어그램 즉 Activity diagram과 굉장히 유사합니다.

그렇기 때문에 잘못 표기하시는 일이 일어나지 않도록 조심하셔야 합니다.

자 그럼 처음 구성요소부터 간단한 사용법과 예제를 보도록 하겠습니다.

구성요소.
사용법.
예제.
마치며.

1. 구성요소.

그래프를 그리는만큼 구성요소는 비교적 아주 간단합니다.

시작.

이 요소는 그래프의 시작을 나타내는 요소입니다. 빨간 테두리는 검은색으로 칠해져도 무관합니다.

이렇게 안이 꽉 차 있는 원이 상태 다이어그램의 시작을 나타냅니다.

상태 다이어그램은 시작 요소 없이 진행되거나 작성될 수 없습니다.

마침.

이 요소는 그래프를 끝낼 때 사용하는 요소입니다. 위와 마찬가지로 빨간 선들은 검은색으로 칠해져도 무관합니다.

여기서 시작과 마침 요소의 차이점은 꽉 찬 원 밖에 테두리가 존재하는가 하지 않는가입니다.

그래프를 작성하실 때 이 부분을 조금 더 신경 쓰시면 좋을듯합니다.

상태.

자 이 요소는 상태를 나 나태는 요소입니다. 여기서 주의하셔야 할 2가지 사항이 있습니다.

첫 번째는 항상 상태 요소는 네모 반듯한 직각이 아닌 모서리가 둥근 사각형이 여야 합니다.

두 번째는 상태 요소에는 상태가 묘사되어야 합니다. 행동이 묘사되어서는 안 됩니다.

예를 들어 "문 열기", "문 닫기"와 같은 행동이 묘사되어서는 안 됩니다.

"문 열림", "문 닫힘"과 같은 현재 대상의 상태가 표현되어야 합니다.

전이.

전이는 상태가 시작, 마침, 그리고 상태가 변화할 때 사용되게 됩니다.

화살표는 한쪽만 존재하며 양방향으로 존재할 수 없습니다. 이는 한 선에 화살표가 양쪽으로 존재할 수 없다는 뜻이지, 각각의 상태가 한 방향으로만 진행되거나 변화해야 한다는 것은 아닙니다.

전이는 2가지로 알려드리겠습니다. 사실 UML의 단점은 나라 혹은 사용자마다 조금씩 다르다는 점입니다.

처음의 <<문 열기>>의 경우 간단한 행동만 묘사되는 반면 가끔 조건이 따라붙는 경우도 있습니다.

예를 들면 문열기 [현재 평균온도가 35도 이상시] 와같이 말입니다.

또한 조건이 존재하지 않을 경우에도 따로 <<>>를 사용하지 않고 간단히 행동만 묘사하기도 합니다.

2. 사용법.

자 앞서 사용할 때 필요한 필요한 요소들을 배웠습니다. 사실 더 많은 요소들이 존재하지만 사실 상태 다이어그램을 그리기 위해서

이 정도의 요소들만 알아도 문제없이 멋진 상태 다이어그램을 만드실 수 있습니다.

자 이번에는 간단한 사용법을 배워보도록 하겠습니다.

자 어떤 사람이 건물에 들어가려고 하며 현재는 문이 열려있는 상태라고 가정합니다.

이때 들어간 사람은 문을 닫을 수 있습니다. 또한 다시 문을 열 수 있습니다. 그리고 문을 닫은 채 건물 내 2층으로 갈 수 있습니다.

이때 검은색 원은 시작 지점을 나타냅니다. 그리고 당연히 테두리가 있는 검은색 원은 마침을 뜻합니다.

이때 문은 열고 닫힐 수 있으며, 이는 상태로 나타냅니다. 즉 문 열림, 문 닫힘과 같이 말입니다.

또한 이러한 문을 열고 닫으려면 건물에 진입한 사람은 문을 열고 닫아야 합니다. 즉 행동을 취해야 합니다.

이때 문을 열고 닫음으로 문의 상태를 변경할 수 있습니다. 마지막으로 2층으로 가기 위해서는 항상 문이 닫힌 상태여야 합니다.

위의 그래프를 보시더라도 문 딛힘에서 마침으로는 이어져있지만, 문 열림에서 2층으로는 연결되어있지 않습니다.

즉 사람이 2층으로 가기 위해서는 꼭 문을 닫아야 한다는 뜻입니다. 즉 문이 닫혀있는 상태여야 한다는 말입니다.

3. 예제.

자 이번에는 제가 예제를 드리겠습니다.

아래의 문장을 잘 읽어보기고 직접 그래프를 그려보시기 바랍니다.

당연히 정답은 아래에 작성해 놓겠습니다.

예제.

배터리 충전 상태를 나타내는 상태 그래프를 그리고 싶습니다.

배터리를 충전기에 꽂으면 항상 배터리 상태는 "비어있음"을 나타냅니다.

이때 배터리가 5퍼센트 이상 99퍼센트 미만으로 충전이 되어있다면 배터리의 상태는 "충전 중"으로 나타나야 합니다.

마지막으로 배터리가 99퍼센트 이상 충전되었다면 배터리는 "충전 완료" 상태로 나타나야 하며, 100퍼센트 모두 충전되었다면,

배터리는 자동으로 충전을 멈추게 됩니다.

정답은 아래에 있습니다.

자 처음 배터리는 충전할 때 항상 비어있음 상태로 시작됩니다.

그 뒤 배터리가 5퍼센트 이상 99퍼센트 미만 시 충전 중 상태로 들어갑니다.

이때 5퍼센트에서 98퍼센트 미만까지는 항상 충전 중 상태를 유지하게 되므로 재귀되어야 합니다.

그리고 99퍼센트 이상이 되면 항상 충전 완료 상태로 변하여야 하며 마지막 배터리가 100퍼센트라면 충전이 종료되어야 합니다.

자 어떤가요? 스스로 그려본 그래프와 닮아있나요?? 사실 그래프에는 정답이 없습니다.

혹시나 제가 그린 것과 다르다고 너무 상심하지 않으셔도 됩니다. 그래프는 알아볼 수 있고 이해가 되는 수준이라면 어떻게 그려지든 크게 상관없습니다.

4. 마치며.

그래프는 왜 그려야 할까요? 왜 필요한 것일까요??

이는 다름 아닌 쉽게 접근하고 볼 수 있으며 이해하기 간편하다는 장점이 큰 이유이지 않을까 싶습니다.

프로젝트를 구상하고 구현할 때 그래프는 정말 빠질 수 없는 요소입니다.

그래프를 통해서 팀원과 좀 더 쉽게 대화를 이룰 수 있고, 더욱 쉽게 접근하고 이해할 수 있습니다.

오늘은 가볍게 상태 다이어그램 State diagram에 관해 배워보았습니다.

요 근래 UML을 검색하시고 제 블로그를 방문해주시는 분들이 많아졌습니다.

예전에 올려놓은 UML은 정말 간단히 정리만 한 글이었기에, 가능하다면 각각 자주 사용되는 그래프들을 좀 더 자세하게 다루어 보는 것도 나쁘지 않을 것 같다는 생각이 들었습니다.

오늘도 즐거운 하루 보내시고 항상 파이팅 하시기 바랍니다!

무슨 일이든 처음이 가장 겁나고 어려운 법입니다.

하시는 일 꼭 모두 잘 이루시고 새로운 도전도 고민보다는 설렘을 가지고 시작하시기 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

독일에서 내가 자주 듣는 질문, 문장들.

OnceBH — Tue, 7 Jun 2022 18:59:41 +0900

독일에서 내가 자주 듣는 질문, 문장들.

다른 나라의 언어로 의사소통을 한다는 것은 생각보다 정신적인 소모가 상당합니다.

요 근래 유튜브에서 무한도전을 시청 중 싸이가 했던 말이 있었습니다.

"일어나자마자 영어를 하면 설사를 많이 해요"

당연히 프로그램의 재미를 위해서 과장되게 표현한 말이겠지만, 무언가 확 와닿는 표현이네라고 생각했습니다.

그만큼 육 제적으로나 정신적으로나 꽤나 많은 스트레스를 받게 되는 것 같습니다.

저도 대략 지금 4년 정도 독일에서 지내고 있지만, 관공서를 가야 하거나, 조금만 일상에서 벗어난 일이 생겨 대화를 해야 한다면,

생각보다 정신적인 소모를 많이 하게 되는 것 같습니다.

하지만, 서당 개 삼 년이면 풍월을 읊는다라고 하지 않나요? 그래도 듣다 보니 들리고, 말하다 보니 이해하게 되는 질문, 문장들이 많습니다.

오늘은 짧게 제가 독일에서 지내면서, 가장 자주 듣고 받는 질문을 차례대로 적어보려 합니다.

처음에는 일상적으로 많이 사용되는 문장들부터 개발자로서 듣게 되는 문장들까지 차례대로 적어보겠습니다.

1. Wie geht es dir? / Wie geht's? / Alles gut?

가장 자주 듣는 질문 중 첫 번째는 이것입니다.

이 문장은 말 그래도 어때? 잘 지내?라는 뜻입니다.

이 문장을 듣는다면 가장 쉽게 하실 수 있는 답은 이것들입니다.

1. Gut.
2. Naja... Ok

3. Mir geht's gut.
4. Schlecht.

etc...

2. Passt schon! / Kein Ding!

이는 괜찮아, 신경 쓰지 마 별거 아니야 하는 뜻입니다.

예를 들어 길거리에서 걸어가던 중 누군가 제게 와 부딪혀 죄송하다고 할 때 Passt schon! 혹은 kein Din 별거 아니야! 하고 말할 수 있습니다.

3. Gibt's doch nicht!

말도 안 돼! 이럴 리 없어! 할 때 사용하는 문장입니다.

이 문장은 사실상 친구들과 게임을할때 많이 듣긴 했으나, 일반적인 대화 상황에서도 꽤나 많이 사용되고 있습니다.

하지만 이 단어는 대부분 혼잣말로 사용되는 경우가 많습니다.

예를 들어 무언가가 제대로 작동하지 않았을 때 혼자서 Gibt's doch nicht!라고 말합니다.

4. Ich kämpfe mit...

이 문장은 직접적으로 누군가와 다투거나 싸운다는 뜻도 존재하지만,

여기선 고군분투하다 혹은 씨름하다고 생각하시면 될 것 같습니다.

예를 들어 나는 현재 작업 때문에 고군분투한다.

Ich kämpfe mit aktuelle Arbeit.

5. Es ist mir Wurst, Mir ist Wurst. / Es ist mir egal

그것은 내게 소시지이다 라는 뜻이 아니라. 문제없다, 상관없다, 신경 쓰지 않는다 라는 뜻으로 이용됩니다.

이 문장은 일상에서 정말 많이 사용됩니다. 하지만 아무런 상황에서 사용하기보다는, 친구처럼 가볍고 친근한 사이에서

자주 사용합니다. 예를 들어

친구가 무언가 제안했을 때 "야 내일 PC방 갈래? 노래방 갈래?"

당신은 둘 다 상관없습니다. 그러면 "Es ist mir Wurst" 즉 "PC방이든 노래방이든 뭐 상관없어" 이런 뜻으로 사용 가능합니다.

심지어 더 짧게 Wurst라고 하기도 합니다만, 제일 좋은 건 짧게 Mir ist Wurst라고 상용하는 게 좋습니다.

6. Sag Bescheid.

알려줘! 이런 뜻입니다. 무언가 모르는 것을 알려달라고 할 때 사용하는 것은 아니고,

무언가 결정이 선다면 그때 알려줘 와 같은 뜻으로 사용됩니다.

예를 들어 친구가 당신에게 이렇게 카톡을 보냅니다.

"야 내일 뭐해? pc방이 나갈래? 갈 수 있으면 알려줘"

이렇게 무언가 결정되면 그때 알려줘 와 같은 의미로 사용됩니다.

오늘은 이렇게 짧게 자주 쓰이는 표현에 관해서 알아보았습니다.

사실 무궁무진하게 많은 문장들이 존재하겠지만, 막상 생각하려니 생각이 잘 안 나네요.

사실 우리나라에서 지역별로 자주 사용하고 말하는 방식이 다르듯이 독일도 주마다 혹은 지역마다 사용하는 사투리나 방식이 다릅니다.

특히 바이에른주 쪽은 사투리가 너무 심해서, 막상 직접 들으면 응?? 무슨 말이지 하는 것도 많답니다.

이제부터 생각이 날 때마다 조금씩 자주 사용되는 문장을 적어보려 합니다.

혹시나 독일어 공부를 하시거나, 회화를 조금이나마 쉽게 알고 싶으신 분들께 조금이나마 도움이 될 수 있으면 좋겠습니다.

언어는 정말 꾸준히 하는 방법 외에는 없는 것 같습니다. 파이팅입니다!!

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, nie anzufangen.

Blackbox and Whiteboxtest란? 블랙박스 테스트 와 화이트박스 테스트?

OnceBH — Sun, 5 Jun 2022 01:26:04 +0900

Blackbox and Whiteboxtest란? 블랙박스 테스트 와 화이트박스 테스트?

개발을 한다는 것은 소스코드를 단지 작성하는 것에 그치지 않습니다.

개발을 위해 행해지는 모든 행위와 과정들이 사실 개발을 한다는 것이라 할 수 있습니다.

이는 예를 들면, 고객으로부터 요구사항을 듣고 분석하여 기능적으로 구현 가능한지 판단한 뒤, 디자인을 마치고 개발한 뒤 테스팅을 거쳐 마지막 고객에게 결과를 가져다주는 것입니다. 이중 오늘은 테스팅에 관해서 좀 더 자세히 유닛 테스트에 관해서 알아보려 합니다.

테스트 왜 필요한가?
유닛 테스트란?
Jest.js란?
마치며.

1. 테스트 왜 필요한가?

테스트란 무엇일까요??
이는 누구나 당연히 생각하듯 코드가, 프로그램이, 결과가 제대로 작동하고 보이고 도출되는지 확인하는 작업입니다.

그렇다면 어떻게 이루어져야 할까요??

이는 크게 두 가지의 관점으로 이루어집니다. 즉 개발자의 관점과 사용자 혹은 제삼자의 관점입니다.

이를 좀 더 전문적으로 Whiteboxtest와 Blackboxtest라고 부릅니다.

Whiteboxtest는 개발자의 관점에서 이루어지는 테스트들을 뜻하며,

당연히 Blackboxtest는 사용자의 관점에서 이루어지는 테스트를 말합니다.

이 둘의 가장 큰 차이는 소스코드 즉 구조적, 기술적 작동방식을 알고 테스트하느냐 모르고 테스트하느냐에 차이입니다.

즉 Whiteboxtest는 개발자의 관점에서 코드가 어떻게 구성되었고 작동해야 하는지 기술적인 구현을 이미 알고 있는 상태입니다.

반대로 Blackboxtest에서는 사용자의 관점으로써 작동이 제대로 이루어지는 판단하는 것입니다.

즉 다시 말해 Whiteboxtest의 경우 프로그램이 내부적으로 어떻게 이루어져 있고, 작동하는지 알고 있는 상태에서 테스트하는 것이며,

Blackboxtest의 경우 내부적으로 어떻게 작동하는지는 모르지만, 제대로 작동하는지 테스트하는 것입니다.

이러한 두 가지 큰 틀은 당연히 여러 테스트들로 나뉩니다.

그렇다면 테스트는 꼭 필요할까요??

결과적으론 그렇다일 것입니다. 하지만 회사의 규모 혹은 프로젝트의 규모에 따라 테스트를 생략하는 곳도 있습니다.

하지만 프로그램을 개발한다는 것은 당연히 퀄리티 또한 보장이 되어야 합니다

이때 퀄리티란 보안, 작동시간, 항상 동일한 작업을 수행하고 같은 결과를 도출하는지, 오류는 없는지, 예외를 해결 가능한지 등등 많은 부분을 다루게 됩니다.

2. 유닛 테스트란?

테스트하면 가장 기본이 되는 테스트가 유닛 테스트입니다.

이는 가장 작은 단위의 테스트이며 Blackbox테스트 중 하나입니다.

즉 개발자 관점에서 이미 코드가 어떻게 짜여있고, 어떤 식으로 프로그램이 실행되는지 로직을 알고 있는 상태로 실행되는 테스트입니다.

유닛 테스트에서 가장 작은 단위의 메서드들이 테스트됩니다. 또한 우리는 리액트를 이용할 것이기에 컴포넌트들도 테스트되어야 합니다.

개발자는 유닛 테스트를 통해서 크게 오류의 유무를 판단하기도 하지만 작성한 코드가 의도한 대로 작동하는지 그리고 일정한 값을 반환하는지 등을 알아볼 수 있습니다. 컴포넌트의 경우, 컴포넌트가 존재하는지, 어떤 내용을 포함하고 있는지, 몇 개의 컴포넌트가 렌더링 되었는지 등등을 알아볼 수 있습니다.

이를 위해서 기본적으로 리액트에서 jest.js와 react testing library를 사용합니다.

이는 우리가 create react app을 이용하여 프로젝트를 생성할 때 포함되어있는 모듈입니다.

이를 확인하기 위해서 개발자는 프로젝트에서 명령어 npm test 혹은 yarn test를 통해 jest가 문제없이 실행되는지 알 수 있습니다.

3. jest.js?

앞서 언급한 create react app을 통해 리액트 프로젝트를 생성할때 자동으로 포함되어 설치되는 모듈입니다.

처음 또 다른 모듈의 사용방법을 배우려면, 그것도 테스트 모듈을 배우려면 먼저 스트레스부터 다가올 것입니다.

하지만 걱정 마세요!! jest는 정말 직관적이거든요.

하지만 배워야 하는 부분은 상당히 많습니다. 오늘은 jest.js라는 것이 있다는 것만 알고 가셔도 충분합니다.

그리고 저 또한 방대한 내용을 오늘 이 글에 쓰지 않을 것입니다. 대신 다음 글에 조금이라도 쉽게 사용하실 수 있도록 작성해보겠습니다.

4. 마치며.

사실 테스팅이라는 게 참 귀찮습니다.

이미 나는 내가 작성한 코드가 어떻게 작동하는지 알고, 로컬에서 작성한 코드를 직관적으로 볼 수 있는데, 왜 또 테스트 코드를 작성해야한다니, 개발 다 해놓고 또 이에 맞는 테스트코드를 작성하려면 머리가 또 아파옵니다.

하지만 개발자로서 가장 중요한 것은 증명하고 남들도 이해할 수 있도록 코드를 작성하고 또한 테스트를 통해 증명하는 것일 것입니다.

또한 이를 통해 코드의 퀄리티도 높아질 것입니다.

저도 처음에는 컴포넌트가 렌더링 되었는 걸 직관적으로 볼 수 있고, 버튼을 눌러보면 메서드가 실행되는걸 바로 확인 가능한데 왜?? 또 테스트 코드를 따로 작성해야되지??? 싶었습니다. 하지만 스스로 작동하는것을 확인하고 마는것과 그걸 테스트코드를 통해서 항상 검증하는 것은 큰 차이이며, 또한 이러한 와중에 의도하지 못한 버그 혹은 에러를 찾는 경우가 정말 많습니다.

또한 이는 협업에서도 빛을 발하게 됩니다. 그 이유는 제가 어떠한 작업을 수행하고 관련된 관련된 컴포넌트가 제가 작성한 코 스로인해서 에러를 유발하게 될 수 있으며, 이는 테스트를 통해 검증하지 않으면 어떠한 다른 문제를 야기할지 모르기 때문입니다.

예로 이번 주에 다른 팀과 작업하는 과정에서 큰 에러를 발견했습니다.

비디오에 사용될 컴포넌트를 개발하는데 막상 라이브에 올리고 나니, 건드리지도 않은 부분에서 에러가 발견된 것입니다.

또한 이게 비디오 컴포넌트 때문인지, 요 근래 새로 도입한 모듈 때문인지 혹은 쿠키 때문인지 정말 아무도 몰랐습니다.

이때 다행히 미리 작업된 테스트 코드가 있었고, 이를 통해 문제를 파악하고 고칠 수 있었습니다.

만약 테스트 코드 없이 눈으로만 확인하고 대충 라이브에 올렸다면, 그리고 이 문제가 1주일 뒤 혹은 1달 뒤에 발견되었다면??

이 에러를 찾느라 얼마나 고생하게 될지 정말 생각하기도 싫습니다.

이처럼 테스트 코드를 작성하는 것은 참 귀찮지만, 언제나 양질의 서비스를 고객에게 제공하기 위해서 혹은 항상 일정한 퀄리티의 서비스를 추 구하기 위해서 테스트는 꼭 이루어져야 할 것입니다.

그리고 앞서 언급했듯이, 빠른 시일 내에 jest.js의 예시 코드를 작성하여 게시글을 작성해보도록 하겠습니다.

오늘도 고생 많으셨고, 남은 하루도 알차게 보내시기 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.
Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 졸업시험 필기시험 합격

OnceBH — Fri, 3 Jun 2022 03:20:37 +0900

아우스빌둥 졸업시험 필기시험 합격

안녕하세요!

저번 주 드디어 필기시험 결과가 나왔습니다.

오늘은 짧게 필기시험 이후의 이야기를 다루어보려 합니다.

필기시험 이후?
프로젝트와 문서?
필기시험 결과?
마치며.

1. 필기시험 이후?

필기시험이 끝나고 난 후 잠시도 숨 돌릴 시간이 없습니다.

그 이유는 프로젝트와 문서를 작성 후 IHK에 제출하여야 하기 때문입니다.

일반적으로 필기시험의 날짜와 문서 제출 날짜를 같이 알려줍니다.

많은 독일인이 필기시험과 프로젝트를 동시에 준비하는 경우가 대부분입니다.

하지만 저는 필기시험 이후 대략 2-3주의 시간의 여유가 있었기에, 먼저 필기시험에 더 집중하였습니다.

저번에도 언급한 적이 있지만 프로젝트는 필기시험 이전에 먼저 프로젝트 신청서를 제출합니다.

프로젝트는 항상 회사와 연관된 주제를 다루어야 합니다. 이는 아우스 빌더와 같이 상의하여 프로젝트를 결정하는 경우가 대부분입니다.

저의 경우 3년 차부터 아쭈비로써가 아닌 팀의 직원과 같이 일하며 배우기 때문에, 아우스 빌더와 팀장과 함께 프로젝트를 구상했습니다.

그리고 필기시험 이후 곧바로 프로젝트를 시작하였습니다.

프로젝트는 무조건 문서화되어야 하며, 결과적으로 IHK에 문서를 온라인과 제본하여 제출합니다.

2. 프로젝트와 문서?

앞서 언급하였듯 프로젝트는 사실상 어떠한 주제더라도 회사와 연관되면 가능합니다.

이를 위해서 프로젝트 신청서를 제출합니다.

이때 몇 가지 사항이 부족하거나 프로젝트가 적합하지 않다고 판단되면, 문서를 수정하거나 다른 프로젝트를 기획하라는 결과를 받습니다.

그렇지 않으면 프로젝트는 승인되고 시작할 수 있게 됩니다.

프로젝트는 70시간 안에 모든 것이 완성되어야 합니다.

이때 단지 프로젝트를 시행하는 것뿐만 아닌, 분석, 디자인, 구현, 테스팅 등등 여러 단계로 나뉘게 되며, 이 모든 것을 70시간 이내에 완성하여야 합니다. 그렇기에 이 70시간을 어떻게 적절히 사용하는지가 중요합니다.

사실 프로젝트를 진행하면서 70시간 이상이 되어도 혹은 프로젝트가 완성되지 않아도 큰 상관은 없습니다.

중요한 것은 그 과정을 모두 문서화하는 것이며, 이를 IHK에 제출하는 것입니다. IHK 또한 프로젝트들이 회사와 관련되어있다는 것을 알기에 자세히 묻거나 하지 않습니다. 하지만 문서를 통해서 프로젝트의 과정과 결과를 체크하기에 사실상 문서를 잘 작성하는 게 관건입니다.

문서를 작성하는 과정은 프로젝트 신청서에 작성한 방법대로 작성되어야 하며, 이를 바꿀 시에 그에 관한 내용이 반드시 작성되어야 합니다.

또한 이는 온라인 포털에 업로드하고 제본하여 제출하여야 합니다.

3. 필기시험 결과?

저번 주 드디어 필기시험 결과를 받게 되었습니다.

시험날 당시 총 3가지의 시험을 보았으며, 첫 번째와 두 번째는 주관식 마지막은 객관식으로 이루어집니다.

결과를 확인하는 방법은 필기시험 안내문에 제시된 홈페이지에서 확인 가능합니다.

저는 결과적으로 문제없이 3가지 시험을 통과하였습니다.

두 번째 시험의 경우 당시 걱정이 많았는데 생각보다 점수가 너무 잘 나와 너무 기분이 좋았습니다.

이때 3가지 시험의 총평균이 50점 이상이 되어야 합니다. 이때 첫 번째 시험과 두 번째 시험은 결과의 40%를

마지막 세 번째 시험은 20%를 채점하게 됩니다.

예를 들어 모든 시험이 각각 50점을 맞았다고 한다면, 첫 번째와 두 번째 시험에서 각각 20점 그리고 마지막 시험에 10점 총 50점이 됩니다.

이때 한 가지 시험이라도 30점 미만을 받게 되면 졸업시험 자체를 떨어지게 되며, 대략 6개월 후 다시 졸업시험을 쳐야 합니다.

또한 하나 혹은 두 개의 시험이 50점 미만이지만 결과적으로 총평균이 50점을 넘게 되면 시험에 통과입니다.

또한 50점에서 조금 못 미치는 점수가 나온다면, 실기시험에서 추가적인 시험을 통해 통과할 수 있는 기회를 받게 됩니다.

이때 합격하지 못하면 시험에서 탈락하게 됩니다.

또한 실기시험은 문서 제출과 프레젠테이션으로 이루어지며, 이 또한 평균 50점 이상이 되어야 합니다.

이렇게 필기시험과 실기시험이 총 평균 50점 이상이면 시험 합격입니다.

사실상 대부분의 시험 응시자들이 합격을 합니다. 하지만 분명히 탈락하는 사람들도 많습니다.

2021년 여름 시험 당시 독일에서 총응시자는 5285명이었습니다.

이 중 4714명이 합격하였습니다.

베를린의 경우 총 203명이 응시하였고 이 중 158명이 합격하였습니다.

바이에른주에서는 총 1032명이 응시하고 총 971명이 합격하였습니다.

보시다시피 독일에서 대략 10%가 탈락하였으며, 베를린에서 대략 22% 바이에른에서 대략 5퍼센트가 탈락하였습니다.

주와 도시마다 모두 다르긴 하지만 독일 전체에서 10퍼센트의 응시자들이 불합격한 것을 볼 때, 사실상 시험의 난이도는 꽤나 있습니다.

4. 마치며.

필기시험을 합격하였다는 생각에 너무 행복한 하루였습니다.

또한 저번 주 이미 저는 문서까지 제출하였습니다. 아직 실기시험의 날짜는 결정되지 않았지만 대략 6월 말 혹은 7월 초일 것이라 예상하고 있습니다. 이제 저는 프레젠테이션을 잘 준비하는 일만 남았네요.

이 글을 읽고 조금이나마 아우스빌둥과 개발자라는 직업에 관해 관심을 가지시면 좋겠습니다.

항상 처음 시작도 중요하지만 끝맺음이 더 중요한 법입니다.

끝가지 열심히 하시고 좋은 결과를 가져오시길 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.
Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 졸업시험 후기

OnceBH — Sat, 14 May 2022 23:18:05 +0900

아우스빌둥 졸업시험 후기

저번 주 드디어 기다리고 준비하던 아우스빌둥 졸업시험이 시작되었습니다.

졸업시험은 2가지 시험으로 나뉘게 되는데

첫 번째는 필기시험 그리고 두 번째는 회사의 분야와 주제에 맞는 자유로운 주제로 프로젝트를 수행하고 이를 문서화한 뒤

발표하는 것입니다. 그리고 오늘 이야기 나눌 졸업시험은 첫번째 시험 즉 필기시험을 다루어보려 합니다.

아우스빌둥 학교와 졸업시험?
IHK 시험?
졸업시험 준비할 것?
졸업시험 당일.
마치며.

1. 아우스빌둥 학교와 졸업시험?

졸업시험은 아우스빌둥 3년간 학교에서 공부 한 과목들을 배우는 것입니다.

하지만 여전히 학교에서 배우지 못하거나 배우지 않는 문제들이 나올 수 있습니다.

한 가지 가장 도움이 되는 방법은 예전 시험지들을 구하여 공부하는 것입니다.

학교에서 배운 것들이지만 그 범위가 넓고 많기 때문에, 특정 범위만 출제되는 경우가 많으며,

이를 위해서 예전 시험지를 많이 구하고 공부하는 것이 제일 좋은 방법입니다.

2 IHK 시험?

IHK는 아우스빌둥을 관리하는 기관입니다. 그리고 아쭈비들은 2-3년 혹은 그 이상의 교육을 회사와 학교에서 받은 후

마지막 IHK에서 주관하는 졸업시험을 보게 됩니다.

Fachinformatiker Anwendungsentwickler이 경우 총 2가지의 시험이 존재합니다.

첫 번째는 필기시험 그리고 두 번째는 구두시험입니다.

필기시험의 경우 총 3 가지의 필기시험을 보게 됩니다.

첫 번째의 경우 UML, 알고리즘, 데이터베이스 그리고 SQL-Query가 주로 나오는 주제입니다.

두 번째의 경우 파일 혹은 사진의 용량 구하기, 전자와 전기, 경제와 계산, 보안등의 주제가 주로 나옵니다.

마지막의 경우 경제와 법 쪽에 관해서 주로 나오게 됩니다.

이때 첫 번째와 두 번째는 모두 주관식 문제들입니다. 이를 위해서 왜 독일어가 중요한지 알게 될 것입니다.

시험은 특정 상황을 먼저 설명해주며 그 뒤 그 상황에 맞는 질문들로 준비되어있습니다. 상황과 질문을 제대로 이해하기 힘들다면,

아무래도 질문에 응답하기에 많은 제약이 따르게 됩니다.

마지막 시험의 경우 객관식이며 대략 30문제입니다.

마지막 시험의 경우 크게 어려운 부분은 없습니다 그리고 대부분 예전 시험과 비슷 혹은 거의 동일한 문제들이 자주 등장합니다.

하지만 그렇다고 공부를 게을리한다면 큰 손해를 보게 될 것입니다.

이제 구두시험을 알아보겠습니다.

구두시험의 경우 크게 2가지의 시험들로 준비되어있습니다.

첫 번째의 경우 프로젝트를 구상, 기획, 적용, 문서화하는 것입니다.

이때 프로젝트는 무조건 회사와 관련되어야 하며, 실질적인 사용화가 능하고 실현 가능한 프로젝트여야 합니다.

이때 아쭈비는 먼저 프로젝트의 초안을 IHK로 작성하여 보내게 됩니다.

그리고 초안에는 현재의 상황, 프로젝트 목표, 이유, 그 후의 발전될 가능성, 프로젝트 수행 시간(최대 70시간), 문서화 개요 등을

제출합니다. 이때 3가지의 경우가 존재하는데 첫 번째는 프로젝트를 승인받는 것으로 승인 이후 프로젝트를 시작하시면 됩니다.

두 번째의 경우 자격요건의 미달입니다. 이러한 경우 IHK에서 요구하는 사항이 완벽하게 서술되어있지 않았기 때문이며,

수정한 뒤 다시 제출할 수 있습니다. 그리고 마지막은 프로젝트를 거부당하는 것입니다. 이는 아예 새로운 프로젝트를 구상 다시 제출하여야 합니다.

두 번째 시험의 경우 마감 날짜 안에 프로젝트를 문서화한 파일과 실질적으로 종이로 프린트된 문서를 IHK에 제출합니다.

그다음 대략 30분의 프레젠테이션과 질문응답을 수행하게 됩니다.

그리고 모든 직군이 그런 것은 아니지만 개발자의 경우 프레젠테이션 후 곧바로 합격 혹은 불합격의 결과를 알 수 있습니다.

3. 졸업시험 준비할 것?

자 이번에는 졸업시험에 필요한 것들을 알아보겠습니다.

첫 번째는 IHK에서 받은 시험 응시서류입니다. 이 서류를 준비하지 않았다면 애석하게도 시험을 칠 수 없습니다.

두 번째는 여권 혹은 신분증입니다. 이 또한 응시서류와 마찬가지로 준비하지 못하면 시험을 칠 수 없습니다.

마지막은 음료, 과자입니다.

조금 의아할 수 있지만 시험기간 중 스낵과 같이 소음을 유발하는 과자가 아니라면 반입이 가능하며 시험 중 섭취도 가능합니다.

저 같은 경우 당을 보충할 수 있는 젤리와 새콤달콤을 준비해 갔습니다.

제 앞에서 시험을 응시한 친구의 경우 물, 커피, 차, 견과류, 껌, 캬라멜 등등 이것저것 많이 준비해서 책상에 올려놓고 수시로 마시며,

먹던 모습이 기억납니다. 시험에 응시할 때 부여받는 책상이 정말 큽니다. 그렇기에 이렇게 많은 음료와 과자를 준비해도 넉넉히 자리가 남습니다. 혹여나 시험을 준비하신다면 음료와 과자를 준비해 가시기 바랍니다.

이는 시험 중 스트레스, 긴장감을 많이 낮춰주는데 큰 역할을 합니다.

4. 시험 당일

대부분의 시험은 IHK가 어디에 위치해 있는지에 따라 결정됩니다.

이 말은 제가 A라는 도시에 살고 회사가 B라는 도시에 위치해있고 IHK가 C라는 도시에 위치해있다면,

졸업시험은 C라는 도시에서 이루어진다는 것입니다.

저 같은 경우, 제가 거주하는 도시와 시험이 치러지는 도시까지 대략 2시간 반에서 3시간 이상 거리에 있었기에,

시험 전날 먼저 도착하여 호텔에서 숙박하였습니다. 시험은 커다란 강당 혹은 농구 혹은 배구경기장 같은 커다란 홀에서 이루어집니다.

저 같은 경우 그곳에 대략 50-60명 사이의 학생들이 전부 모여 시험을 보았습니다.

이때 개발자뿐만 아니라 다른 직군의 아쭈비들까지 모두 모여서 진행합니다.

시험은 앞서 언급한 3가지의 구두시험을 먼저 보며 이는 90분, 90분 60분의 시간 이주 어집니다.

IHK에 따라 차이가 있으나, 대부분 한 가지 시험이 끝난 뒤 쉬는 시간을 가지게 됩니다. 하지만 쉬는 시간 없이 이루어지는 곳도 있습니다.

첫 번째와 두 번째 시험은 앞서 언급한 5가지의 분야들로 각각 나뉩니다. 한 분야마다 최대 25점을 받을 수 있으며,

시험 응시자는 5가지의 분야들 중 한 가지를 제외한 4가지를 응시하게 되며 총 합점은 100점입니다.

이때 시험 응시자는 임의에 따라 응시하고 싶지 않은 분야를 선택할 수 있습니다.

첫 번째와 두 번째 시험은 시험 감독관이 시험 지자체를 들고 갑니다.

시험지에 직접 답을 서술하여야 하기 때문입니다. 하지만 마지막 객관식의 시험은 따로 OMR카드와 비슷한 종이를 나누어주며,

시험지는 응시자가 챙겨갈 수 있습니다. 시험은 대략 8시에 시작되며, 끝나는 시점은 12시이나,

준비, 쉬는 시간을 포함하면 대략 13시 반에서 14시 즈음 끝이 납니다.

회사에 따라 다르지만 대부분 시험 전날과 시험날은 회사에 출근하지 않아도 되도록 조치를 취해줍니다.

혹여나 그런 사항을 들어보지 못하셨다면 한번 여쭈어 보시는 것도 좋습니다.

5. 마치며

저 같은 경우 프로젝트와 구두시험은 자신이 있기에, 이번 필기시험을 정말 많이 공부했습니다.

다행히 회사에서도 예전 졸업시험들을 많이 제공해주어, 정말 끝도 없이 보고 준비하고 풀어보았습니다.

다행히 대부분 준비한 만큼 실력 발휘를 할 수 있었습니다.

당연히 걱정되는 부분들도 존재하나 그만큼 준비하고 노력했으니, 큰 걱정 없이 조용히 결과를 기다려보려 합니다.

결과가 나오는 대로 또 블로그를 작성해보려 합니다.

긴 글 읽어주셔서 감사합니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.
Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

변수 함수 이름을 쉽게 지어보자.

OnceBH — Sat, 16 Apr 2022 02:23:04 +0900

변수 함수 이름을 쉽게 지어보자.

안녕하세요!

개발을 하다 보면 필연적으로 만나게 되는 것이 바로 변수와 함수의 이름을 지어주는 번거로움?

혹은 어려움일것입니다. 이러한 어려움을 해소하기 위해서 변수를 작성하는 방법은 여러 가지 들이 있습니다.

또한 언어에따라서 달라지기도 합니다. 오늘은 제가 주로 사용하는 방법을 간단하게 말씀드리려 합니다.

변수의 이름
함수의 이름
주석
마치며

1. 변수의 이름

아마 대부분 개발을하고 피드백을 받으면 한 번씩은 변수의 이름이 부정확 혹은 애매모호하다는 말을 들어보셨을지 모르겠습니다.

사실 정말 쉽게 마음먹자면, 변수 이름이 애매모호하면 어떻냐. 누가 봐도 코드를 보면 변수의 사용방법을 알고 이해할 수 있는데.

라는 마음을 가질 수 있습니다. 저 역시 그랬습니다. 하지만 이는 혼자서 개발할때의 한하며 또한 혼자서 개발을 하더라도

이러한 습관은 반드시 버리셔야합니다. 개발자는 개발만 하는 것이 아닌 소통, 유지보수도 해야 하기 때문입니다.

예전에는 변수의 이름을 가능한 짧게 지었습니다. 예를 들면 i, y, z와 같이 말입니다.

이는 옛날 메모리의 문제로 인해서 그런 것이며 지금은 그렇게까지 걱정할 이유가 없습니다.

변수는 먼저 이름이 쉬워야 합니다. 누가 봐도 알 수 있는 그런 특정된 단어를 사용하는 것이 좋습니다.

하지만 그러다 보면 필연적으로 변수의 이름이 길어질 수 있습니다. 그럼에도 불구하고 길게 짓는 편이

훨씬 좋습니다. 예를 들어보겠습니다.

// 좋은 예시
const valueFromSomething = 10;

// 좋지 못한 예시
const valFrSome = 10;

// 좋은 예시
const currentTotalValue = "something";

// 좋지 못한 예시
const cuToVal = "something";

짧다고 다 좋은 것이 아닙니다. 이해하기 쉽고 딱 보고 알 수 있는 변수를 지정하는 것이 좋습니다.

변수의 이름이 정말 너무 길면 그것도 보기는 좋지 않겠지만, 필연적으로 길어야 한다면 긴 것이 짧게 줄인 것보다 훨씬 좋습니다.

Boolean 값의 변수를 지정하려는 경우 가장 편한 방법은 is를 사용하는 것입니다.

예를 보겠습니다.

// Boolean 예시
const isChecked = false;
const isUpdated = true;
const isModalOpened = true;

이렇게 작성하시는 것이 보기에 좋습니다.

말 그대로 체크가 되었는가? 업데이트되었는가? 모달이 오픈되었는가? 와같이 의문문으로 작성하시면,

이해하기도 쉽고 사용할 때도 훨씬 덜 헷갈리게 됩니다.

2. 함수의 이름

함수의 이름을 짓는 것은 사실 변수의 이름을 짓는 것보다 쉽습니다.

함수 또한 앞에 변수와 언급한 것과 같이 짧은 것보다는 길더라도 정확한 이름을 지어주는 것이 좋습니다.

그리고 함수의 경우 웬만하면 동사를 먼저 위치시키는 것이 좋습니다.

예를 보겠습니다.

// 좋은 예시
const setValue = () => {};
const getValue = () => {};
const showModalAfterClick = () => {};
const updateCurrentLocation = () => {};

// 좋지 못한 예시
const valueSet = () => {};
const valueGet = () => {};
const ModalAfterClick = () => {};
const currentLocationUpdate = () => {};

사실 형태를 보면 이게 함수인지 변수인지 알 수 있지만 이렇게 동사를 먼저 사용해줌으로써

실행되어야 한다는 느낌을 주시는 것이 좋고 이를 통해 이 변수가 업데이트를 하는지, 보여주는지, 가져오는지, 설정하는지를

명시해주는 게 정말 중요합니다.

다른 방법은 함수를 하나의 사람 혹은 사물의 형태로 바꿔주는 것입니다.

예를 보겠습니다.

// 예시
const valueSetter = () => {};
const valueGetter = () => {};
const ModalHandler = () => {};
const currentLocationUpdateHandler = () => {};

저는 이러한 방법보다는 위의 방법을 더 선호하며 자주 사용합니다.

처음에 동사를 보고 바로 이 함수의 목적을 알 수 있기 때문입니다.

3. 주석

개발을 하다 보면 주석을 잘 사용하는 분들이 있으신가 하면 거의 전혀 사용하지 않으시는 분들도 계십니다.

이때 주석을 잘 사용한다는 것은 일일이 하나하나의 변수와 함수의 목적과 동작원리를 적어놓는 것이 아닌,

함수의 이름에 비해 동작원리가 복잡하거나, 함수의 실행 순서, 이 함수를 사용할 때의 주의점이나 추후의 개선점을 적어놓는 것입니다.

특히나 협업을 하게 된다면 주석은 너무너무 필수입니다. 저뿐만 아니라 모든 직원들이 자신의 코드를 작성 후

필요에 따라 주석을 통해 작동원리 혹은 추후의 개선 점등을 작성합니다.

이는 다른 개발자들이 당장 보지 않더라도 언젠가 같은 파일을 작업하게 된다면 보게 될 것이고 정보를 얻을 수 있습니다.

예를 보시겠습니다.

// This method should be deleted after current promotion.
// Otherwise it causes conflict with legacy codes.
const changeValueFromResult = () => {};

주석은 회사마다 다르겠지만, 기본적으로 영어를 사용하시는 것이 좋습니다.

4. 마치며

자 오늘은 짧게 변수와 함수의 이름 짓는 법을 알아보았습니다.

사실 이름을 짓는 것은 자유이지만 오늘은 제가 자주 사용하는 방법을 알아보았습니다.

짧지만 도움이 되었으면 좋겠습니다.

완벽한 준비란 없다,완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

내가 사용하는 VScode extention 추천. 비주얼 스튜디오 코드 익스텐션 추천 파트 2

OnceBH — Sun, 27 Mar 2022 19:00:25 +0900

내가 사용하는 VScode extention 추천. 비주얼 스튜디오 코드 익스텐션 추천 파트 2

안녕하세요.

오늘은 제가 개발 시 사용하는 VScode extention들을 추가로 이야기해보는 시간을 가지려 합니다.

개발을 하시다 보면 가벼우면서 여러 익스텐션이 존재하는 VScode를 많이 사용하십니다.

저 또한 그렇습니다. 그렇기에 오늘은 파트 2로써 제가 사용하거나 알게 된 유용한 익스텐션을 소개해보겠습니다.

Peacock
SynthWave '84
Import Cost
마치며.

1. Peacock

개인 프로젝트 혹은 혼자서 작업을 하시는 거라면 딱히 여러 개의 VScode를 프로젝트별로 열어두어야 하는 일은 적을 것입니다.

하지만 협업을 하게 되면 여러 개의 프로젝트를 열어놓고 확인해가며 일하시게 될 가능성이 커집니다.

그리고 저는 항상 높은 확률로 다른 프로젝트의 VScode를 탭 하여 여러 번 탭을 옮겨야 되는 상황이 발생하곤 합니다.

이때 Peacock은 많은 도움을 줄 수 있습니다.

Peacock은 VScode의 가장자리에 색상을 바꿔줄 수 있습니다.

예를 들면 이렇게 말입니다.

이렇게 색상을 나눔으로써 좀 더 직관적으로 상단의 프로젝트 이름을 보고 확인해야 하는 번거로움이 줄어들게 됩니다.

처음에는 별 쓸모를 못 느끼고 있었지만, 막상 사용하고 눈에 익기 시작하니 너무 편하다는 생각이 들었습니다.

특히 맥을 이용하신다면 더더욱 편하게 찾으실 수 있습니다. 이렇게 말이죠.

윈도우에도 유사하게 현재 사용 중인 프로그램, 폴더 등을 일목요연하게 볼 수 있는 방법이 있는 걸로 알고 있습니다.

(저는 윈도를 사용하지 않은지 기간이 오래되어 생각이 가물가물하네요.)

자 어쨌든 위의 사진처럼 여러 프로그램들을 동시에 보기 위해 미션 컨트롤러 화면으로 전환 시 VScode상단 중앙에 위치한

프로젝트의 이름이 잘 보이지 않는 경우가 많습니다. 하지만 이렇게 색상을 기억하신다면 훨씬 더 편하게 그리고 빠르게 필요한 프로젝트를

찾아 작업하실 수 있으실 것입니다.

2. SynthWave '84

이 익스텐션은 유용하다기보다는 제가 현재 사용하고 있는 Theme입니다.

저는 예전까지만 해도 Theme에 큰 관심 없이 기본 검은색 Theme을 사용하곤 하였습니다.

하지만 개발자라면 한 번씩 멋지고 예쁜 Theme혹은 fonts 등을 사용하고 싶어 하지 않나 싶습니다.

저도 그런 적이 있었고 주변 동료 개발자로부터 제 마음에 쏙 드는 Theme을 발견하였는데 그것이 바로

SynthWave '84였습니다. 색상이 예쁘고 문자의 색상이 배경화 면가 잘 어울리는 것 같아 추천드리는

익스텐션 중 하나입니다.

3. Import Cost

이번 익스텐션은 꼭 추천드리는 익스텐션입니다.

개발을 하다 보면 필연적으로 필요한 것이 다른 모듈 혹은 패키지들을 import 하는 것입니다.

그때 우리는 현재 import 하는 패키지의 용량을 따로 확인하지는 않습니다.

하지만 이는 당연히 개발에 있어 꽤나 중요한 부분으로 작용합니다.

패키지 혹은 모듈의 용량이 클수록 로딩 혹은 리로드 시간이 길어지기 때문입니다.

그리고 이는 다른 비슷하거나 더 가벼운 모듈을 사용하게 만들 요소로 충분히 작용할 수 있습니다.

현재 제가 일하는 회사에서 따로 모듈을 관리하고 그 모듈을 모두가 같이 사용합니다.

하지만 현재 이 모듈의 용량은 비교적 크기 때문에 항상 로딩 시간에 불만이 있었습니다.

그 후 얼마 지나지 않아 다른 팀에서 Material UI를 통하여 시험용으로 프로젝트를 하나 진행하였고,

이때 모든 개발자들이 로딩 속도의 차이를 느꼈습니다. 왜냐하면 Material UI가 훨씬 가벼웠기 때문입니다.

이처럼 개발하면서 필요한 모듈을 import 하여 사용하게 될 때 모듈의 용량 또한 살펴보아야 할 항목 중 하나입니다.

하지만 이를 확인하기에는 너무 번거롭습니다. 이럴 때 Import Cost를 사용하게 됩니다.

이와 같이 import 되는 모듈 혹은 패키지의 용량을 보여줍니다.

용량이 커지면 생상도 초록색에서 빨간색으로 바뀌게 되어 훨씬 더 직관적으로 용량의 크기를 확인하실 수 있습니다.

4. 마치며.

개발을 하다 보면 익스텐션의 중요성을 많이 깨닫게 되는 것 같습니다.

개발자들의 빠르고 편안한 개발환경을 위해서 이러한 기능들을 제공하고 관리해주는 다른 개발자분들이 정말 대단하다고 생각됩니다.

저는 개발자가 너무 좋다고 생각하는 이유 중 결정적인 이유는 바로 오픈된 정보라고 생각됩니다.

개발자들은 항상 하나라도 더 알리고 전달하고 싶어 하고 공유하고 싶어 하는 그리고 이러한 움직임이 나뿐 아니라 대중적인 개발환경을 변화시키고 발전시킨다고 생각합니다. 오늘도 즐거운 개발하시기를 바라겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 졸업 필기시험 준비.

OnceBH — Sat, 12 Mar 2022 22:05:36 +0900

아우스빌둥 졸업 필기시험 준비.

이제 아우스빌둥 졸업시험이 대략개월 앞으로 다가왔습니다.

오늘은 아우스빌둥 졸업시험 준비를 어떻게 하고 있는지 정보 나누어보려 합니다.

저는 현재 Fachinformatiker Anwendungsentwicklung (개발자)이라는 아우스빌둥을 하고 있어며,

현재 3년 차로 졸업시험을 준비하고 있습니다.

현재도 아우스빌둥을 준비하시는 분들께 추후에 도움이 될 수 있었으면 좋겠습니다.

아우스빌둥 졸업시험은 어떻게 이루어지는가?
졸업시험 필기 준비는 어떻게 하는가?
필기시험 후?
마치며.

1. 아우스빌둥 졸업시험은 어떻게 이루어지는가?

예전에 이미 짧게 다루어본 주제입니다.

먼저 아셔야 하는 게 있습니다. 학교와 IHK 즉 아우스빌둥을 담당하는 기관은 사실

조금은 다르게 움직입니다. 즉 학교에서 보는 시험들은 사실상 졸업시험에 포함되지 않습니다.

즉 학교에서 보는 시험들은 사실상 졸업시험 그리고 그 후에도 거의 반영되지 않는다는 것입니다.

즉 학교 시험성적이 좋지 않더라도 졸업시험만 통과하면 아우스빌둥 졸업이라는 것이죠.

하지만 그럼에도 불구하고 학교 시험은 꽤나 중요합니다.

그 이유는 즉 학교와 회사에서 제 성적을 보며 제가 학교에 잘 적응하고 있는지, 태도는 괜찮은지 등등의

지표로 사용되기 때문입니다. 그렇기에 학교에서 한 학기가 끝나면 항상 하는 것이 한 학기의 성적증명서를 발부한 뒤

학생들에게 아우스 빌더 혹은 Auszubildende 즉 회사에서 사인을 받아 보여달라고 합니다.

자 다시 주제로 돌아와서 졸업시험은 총 3단계입니다.

1차로 필기시험을 치른 뒤 2차로 개인 프로젝트를 문서로 제출합니다. 그리고 마지막으로 프레젠테이션을 하게 됩니다.

보통 별 문제가 없다면 프레젠테이션 후 담당관들이 곧바로 제가 시험에 합격을 하였는지, 부족했는지 혹은 불합격하였는지 알려줍니다.

이때 합격을 하게 되면 별문제 없이 졸업을 하는 것이며, 부족하다는 평가를 받으면 추가적으로 구두시험을 통해 제 부족한 점수를 채울 수 있습니다. 또한 여기서 알맞은 점수를 받아 졸업 점수 이상이 되면 졸업입니다. 그 외에 점수가 모자라거나 부족하게 되면 불합격하게 됩니다.

불합격 시 대략 6개월 이후에 한번 더 볼 수 있습니다.

2. 졸업시험 필기 준비는 어떻게 하는가?

이 부분이 사실 참 난감합니다.

앞서 언급하였듯이 회사와 IHK는 서로 다르게 움직입니다. 즉 IHK시험에 필요한 부분들을 학교에서 배운다는 것보다,

학교에서는 정말로 일하면서 필요한 이론적인 부분을 배우는 부분이 더 큰 거 같습니다.

하지만 이는 학생들에게 특히 졸업시험을 준비하는 학생에게는 너무 불편합니다.

먼저 학교에서 배우지 않은 부분들이 시험에 포함됩니다.

이는 대략 3가지 경우로 나뉩니다.

첫째 학교에서 가르치는 부분이 아님

둘째 배웠지만 너무 짧게 맛만 보고 넘어감

셋째 배워야 하는 과정이나 상황에 따라서 배우지 못함.

특히 3번째 경우는 최악입니다.

저 역시 이번 코로나 사태로 대부분의 선생님들이 병가를 신청하여,

사실상 졸업을 앞두고 있는 상황에서 너무 많은 과목을 배우지 못하였습니다.

자 그럼에도 불구하고 시험은 다가올 것이고, 준비는 해야 합니다.

그렇다면 어떻게 준비하는 게 현명할까요??

정답은 회사와 아쭈비들에게 물어 예전에 치러진 졸업시험 문제지 혹은 파일이 있는지 물어보는 것입니다.

그다음 자료가 없거나 충분하지 않다면 회사에 구매를 요청하는 것입니다.

회사는 아쭈비가 아우스빌둥과 졸업에 필요한 필기구, 책, 문제지, 정보지 등을 제공해주어야 하는 의무가 있으며,

법적으로 지정되어 있습니다. 이렇게 받은 예전 시험지를 최대한 많이 훑어보고 패턴과 자주 등장하는 주제를 골라내어야 합니다.

그리고 그 주제들을 먼저 우선적으로 그 뒤 부과적인 주제들을 공부하여야 합니다.

또한 졸업시험은 우리가 평소 학교에서 중간, 기말고사를 보듯이 과목별로 나눠져있지 않습니다.

시험은 총 3파트로 나뉘어있으며, 처음은 IT와 개발, 두 번째는 네트워크와 하드웨어 그리고 마지막은 경제와 법입니다.

하지만 사실 실제 시험을 보게 되면 이들이 나뉘어있다고는 하나 엮여서 나오는 경우가 많습니다.

예를 들면 두 번째 네트워크와 하드웨어에서 경제에서 나오는 문제를 혼합하는 경우입니다.

3. 필기시험 후?

대부분의 졸업 프로젝트들이 필기시험을 준비하는 과정에서 같이 시작되어야 합니다.

IHK는 대략 5월 말까지 프로젝트를 문서화하여 제출하기를 원하며, 시험은 대략 5월 초 혹은 중순입니다.

개발자의 경우 70시간 내에 분석, 디자인, 적용 및 개발, 테스트, 문서화까지 완성한 뒤 문서를 제출하기 원합니다.

그렇기에 필기시험이 끝났다고 한숨 돌리기보다는 프로젝트에 몰두하고 프레젠테이션을 준비해야 합니다.

4. 마치며.

가끔 스스로 이러한 생각을 해본 적이 있었습니다.

아우스빌둥이 꼭 필요했을까? 아우스빌둥 말고 그냥 한국에서 공부하고 바로 직장을 구하는 게 낫지 않았을까?

하지만 항상 결과는 내 선택은 스스로 한 것이고 또한 미래를 위해서라면 아우스빌둥이 정답이다 였습니다.

개발자로서 사실 졸업증명서 혹은 자격증은 중요하기는 하나 큰 변수가 되기는 힘듭니다.

하지만 아우스빌둥이라는 것이 졸업의 의미를 떠나서 배우는 과정에서 습득하게 되는 기술, 능력, 프로세스 등은

사실 생각보다 훨씬 중요하고 값집니다.

요 근래 아우스빌둥에 관하여 물어보시는 분들이 많아지고 있습니다.

특히 그중 한 분은 너무 열정적이고 스스로 도전하시려는 그 모습이 너무 멋지다고 생각했습니다.

마음을 먹는다는 것은 비교적 쉽습니다. 하지만 이를 몸으로 옮기고 실천하는 것은 몇 배는 고되고 힘이 듭니다.

더군다나 잘 다니던 직장을, 직군을 바꾸고 무언가 새롭게 시작한다는 것은 더더욱 많은 용기와 노력이 필요하다고 생각됩니다.

아우스빌둥을 준비하는 모든 분께 힘내라고 말씀드리고 싶습니다.

파이팅입니다.

Next JS 란? Next JS 사용하는 이유. 웹개발 역사를 짧게 알아보자.

OnceBH — Sat, 19 Feb 2022 22:32:40 +0900

Next JS 란? Next JS 사용하는 이유. 웹개발 역사를 짧게 알아보자.

안녕하세요.

오늘은 왜 리액트가 등장하였고 또한 왜 NextJS가 등장하고 사랑받고 있는지,

가볍게 알아보겠습니다.

HTML, CSS, Javascript
리액트의 등장
Next JS의 등장
마치며

1. HTML, CSS, Javascript

누구든지 처음 웹 개발을 공부, 시작하게 되면 듣게 되는 3가지 언어들이 있습니다.

HTML, CSS, Javascript입니다.

예전에는 HTML과 기본적인 CSS로 개발을 했습니다.

그 후 자바스크립트의 등장으로 웹 개발의 시동을 걸었다고 할 수 있습니다.

하지만 이를 위해서는 기본적으로 브라우저의 역사를 알 필요가 있습니다.

하지만 너무 자세히 들어가면 내용이 방대해질 수 있으므로,

가볍게 정리하자면, 브라우저의 발전에 따라 자바스크립트가 개발되었고,

그 후 여러 브라우저 개발사 혹은 개발자들은 자신들만의 언어를 브라우저에 장착하기 시작했습니다.

하지만 이는 브라우저에 따라 다르게 혹은 동작하지 않는 결과를 초래하였고,

끝내 ECMA스크립트가 등장하였습니다. 이는 또 다른 언어가 아닌 자바스크립트를 기본으로 규격, 규율을 정하여,

여러 브라우저에서도 큰 차이 없이 동일한 작업을 수행할 수 있도록 도와주었습니다.

하지만 당시 자바스크립트로 DOM에 접근하여 태그들을 컨트롤하는 것은 꽤나 불편한 일이었습니다.

그리고 이러한 작업을 줄이고 쉽게 해 줄 수 있는 여러 라이브러리들이 출현하게 되었고, 그중 유명한 것이 JQuery라고 할 수 있습니다.

(예전에도 언급하였지만 현시점에서 JQeury는 할 줄 안다면 좋겠지만, 거의 필요가 없습니다.

당연히 회사에서 JQuery를 사용하거나, JQeury로 개발된 예전 프로그램들을 관리하게 된다면 사용할 수밖에 없지만,

그렇지 않다면 크게 배울 이유는 없지 않을까 싶습니다.)

하지만 후에 여러 문제점들 혹은 개선사항들이 발견되기 시작합니다.

1. JQuery가 너무 무거웠습니다.

2. 유저의 조그마한 Interact에도 브라우저가 전체 리로드 되어야 했습니다.

이는 Single Page Application으로 발전되기 시작하였고 또한 컴포넌트들을 분할하여 각각 따로 동작할 수 있는 방법을 강구하게 하였습니다. 예를 들어 컴포넌트들이 분할되어 동작하지 못한다면, 유튜브에서 동영상을 보다가 좋아요 버튼을 누르면 페이지 전체가 리로드 되어

비디오가 처음부터 시작되는 것과 같습니다.

그리고 이러한 단점들을 보안할 수 있는 라이브러리인 리액트가 등장하게 되었습니다.

2. 리액트의 등장

앞서 말한 여러 단점들의 보안을 위해 리액트가 등장하였습니다.

리액트는 기본적으로 SPA를 지원하며, 컴포넌트들 분할하여 관리할 수 있습니다.

또한 이러한 컴포넌트들은 재사용될 수 있어 코딩의 시간과 번거로움을 줄여줍니다.

하지만 그다음 문제가 슬슬 등장하기 시작합니다.

그중 하나는 CSR 즉 클라이언트 사이드 렌더링이었습니다.

CSR이 무엇인지 짧게 알아보겠습니다.

CSR은 클라이언트, 즉 유저 쪽에서 우리가 작성한 코드를 다운로드하고 리액트가 렌더링 하여 결과적으로 유저에게 보여줍니다.

이는 대략 크게 2가지의 문제가 존재합니다.

1. 인터넷 사용량이 증가하고, 사용인원이 증가함에 따라 홈페이지를 구글과 같은 포털에 더 쉽고 자주 노출시켜, 유저들에게

보여줄 필요가 생겼습니다. 이는 끝내 검색엔진에 의해 이루어지는데, CSR이 경우 유저가 홈페이지를 리로드 하는 과정 중 검색엔진은

사실상 아무런 데이터도 받지 못하게 됩니다. 그렇다면 이는 당연히 검색엔진 사용에 불리하게 작용합니다.

2. 인터넷 속도입니다.

사실상 우리가 이용하는 인터넷의 속도는 워낙 빠르기 때문에 큰 문제는 되지 않을 수 있지만,

검색엔진과 같은 프로그램들에게는 앞서 말한 것처럼 불리할 수 있습니다.

그리고 인터넷이 느리다면 유저는 모든 로딩이 끝날 때까지 아무런 화면도 볼 수 없다는 것입니다.

사실 요즘은 로딩 화면을 구성하거나 혹은 리액트의 Suspense를 이용하여 로딩화면을 더 쉽게 구현할 수 있습니다.

그렇다면 이러한 문제들을 해결 혹은 발전시키기 위해서 나온 것이 Next JS입니다.

3.Next JS의 등장

자 드디어 Next JS가 나왔습니다.

Next JS는 리액트의 프레임워크입니다.

Next JS는 SSR을 기본적으로 지원합니다.

이를 확인하는 방법은 간단합니다. Next JS 환경을 구축하고,

로컬에서 실행시킨 뒤 브라우저에서 개발자 툴을 이용하여 네트워크를 확인하시면

현재 보시는 홈페이지의 구성요소들이 서버를 통해 들어오는 것을 확인하실 수 있습니다.

그리고 또한 페이지를 리로드 할 때 속도를 체감하신다면 얼마나 빠르게 렌더링 되는지 확인하실 수 있습니다.

Next JS는 이미 대부분의 필요한 요소들이 들어가 있기에 별다른 모듈을 또다시 다운로드할 필요가 줄어듭니다.

이는 또한 끝내 로딩 속도를 줄여주게 되는 계기가 됩니다.

SSR은 결과적으로 앞서 말한 문제점들을 대부분 개선할 수 있습니다.

또한 Next JS가 지원하는 라우팅은 정말 편하고 직관적입니다.

그리고 결과적으로 여러 기능들이 추가된 리액트라고 생각하시면 되기에, 또 다른 언어를 배우거나 모르는 문법 혹은 기능을 배우는 것이

아닙니다. 이는 조금만 익숙해져도 기본 리액트를 이용하여 개발하시는 것보다 훨씬 쉽고 빠르며 효과적이라는 것을 알게 되실 것입니다.

그 외에도 여러 많은 기능 혹은 장점들이 존재합니다. 이는 후에 시간이 된다면 Next JS만 중점적으로 다루어보도록 하겠습니다.

4. 마치며

웹 개발환경은 하루가 다르게 변화하고 있습니다.

특히 프론트엔드는 말하기 힘들 정도로 새로운 기능, 변화들이 이루어지고 있습니다.

새로운 것에 거부감을 줄이고 흥미를 들이는 것이 개발자가 가져야 할 자질 중 하나이지 않을까 싶습니다.

오늘은 이렇게 처음부터 Next JS까지 쉽게, 빠르게 훑어보았습니다.

이는 대략적으로 제가 짧게 요약한 것입니다. 사실은 더 복잡하고 많은 사건들이 있었습니다.

우리가 개발을 할 때 왜 이러한 라이브러리, 프레임워크 혹은 기능들을 사용하는지 대략적으로 알고 사용하는 것은

큰 도움이 됩니다. 이를 위해서 선임 개발자분들이 제게 자주 하던 말이 바닐라로도 한번 만들어봐라라는 것입니다.

예를 들면 슬라이드 기능과 같이 바닐라로 만들기에는 꽤나 시간을 들여야 하는 기능들을 스스로 만들어보는 것입니다.

한번 만들어 보고 나면 왜 모듈 사용이 효율적이고 더 안전할 수 있는지 등등을 알게 될 수 있습니다.

오늘도 제 블로그를 방문해 주셔서 감사하고, 즐거운 개발하시기 바랍니다!

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다

Es gibt keine Perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

IaaS, PaaS, SaaS란? Cloud Computing이란?

OnceBH — Sat, 5 Feb 2022 20:22:42 +0900

IaaS, PaaS, SaaS란? Cloud Computing이란?

안녕하세요.

오늘은 클라우드 컴퓨팅에 관해서 짧게 알아보려 합니다.

인터넷이 발전하고 보급이 빠르게 이루어지면서 IT는 급격한 변화를 겪게 되었습니다.

하루가 다르게 새로운 기술, 아키텍처, 구성 등등 변화하고 바뀌었습니다.

이러한 변화는 자연스럽게 보안, 생산성, 확장성, 성능 등의 빠르게 발전시켰습니다.

그러며 서서히 클라우드라는 개념이 드러나게 됩니다.

클라우드는 쉽게 생각하면 그다지 어려운 것은 아닙니다.

클라우드란 쉽게 말해 인터넷을 통해서 여러 서비스를 제공하는 것입니다. 이는 DB, 네트워킹, 서버 등등

많은 분야에 폭넓게 제공되고 있습니다.

오늘은 그 서비스를 제공하는 형식을 알아보려 합니다.

IaaS란?
PaaS란?
SaaS란?
마치며

자 우리는 이제 하나의 상황을 가정한 뒤 시작하겠습니다.

저희는 현재 하나의 홈페이지를 개발, 배포하려 합니다.

이를 상기하시면 아무래도 아래의 정보를 이해하기 쉬울 것입니다.

1. IaaS란?

Infrastructure as a Service.

클라우딩 서비스를 제공하는 가장 기본적인 형식입니다.

이는 컴퓨팅의 아키텍처와 인프라를 제공합니다.

기본적으로 가상 머신을 통해 서버, 스토리지, 네트워크, 가상화 등을 제공받으며 더 많은 리소스를 제공받을 수 있습니다.

그 후 OS, 런타임, 애플리케이션을 직접 다루면 된다고 볼 수 있습니다.

이는 당연히 유연한 확장성을 제공하게 됩니다. 하지만 그만큼 보안의 문제를 신경 쓸 필요가 존재합니다.

이는 일반적인 유저가 사용하기보다는 개발자가 많이 사용하는 영역이라 할 수 있습니다.

즉 저희는 컴퓨터 한 대를 온라인으로 제공받은 것이며, 여기에 스스로 윈도즈 혹은 리눅스 같은 운영체제를 설치한 뒤

홈페이지를 배포할 수 있는 환경을 만들어줍니다. 그리고 마지막으로 홈페이지를 개발하고 배포하는 것입니다.

2. PaaS란?

Platform as a Service.

이는 인프라뿐만 아니라 사용자가 자신이 개발한 홈페이지를 구동할 수 있는 환경까지를 제공받는 것입니다.

즉 스토리지, 네트워크, 서버뿐만 아니라 운영체제와 런타임까지 제공받는 것입니다.

이러한 즉 우리는 사용자로서 홈페이지를 개발만 하면 된다는 뜻입니다.

그 뒤 홈페이지를 배포하는 것은 PaaS를 제공해주는 업체에서 알아서 해주는 것이죠.

이러한 대표적인 예로는 Heroku, Netlify와 같은 회사들이 있습니다.

이들은 사용자의 코드가 업로드되면 자동으로 그에 맞는 환경을 제공하고 사용자의 홈페이지를 배포해줍니다.

이들은 무료 배포를 제공하지만 고객의 사용량에 따라 유료로 리소스를 확장할 수 있습니다.

즉 저희는 컴퓨터에 운영체제, 런타임까지 모두 제공된 컴퓨터를 제공받은 것이며,

우리가 해야 하는 일은 단지 코드를 이러한 환경에 업로드하는 것입니다. 그 뒤 컴퓨터는 알아서 코드를 읽고 배포까지 마칠 것입니다.

3.SaaS란?

Software as a Service.

그럼 마지막으로 SaaS는 무엇일까요?

자 우리는 IaaS를 통해 직접 운영체제, 배포 환경, 홈페이지 코드를 작성하고 홈페이지를 배포하였거나

혹은 PaaS를 통해서 우리의 코드만 작성하고 홈페이지를 배포하였습니다.

즉 우리는 지금까지 개발자의 시점으로 IaaS와 PaaS를 알아보았습니다.

이제는 우리의 홈페이지를 사용하는 고객, 사용자들의 시점으로 보아야 합니다.

사용자는 우리의 홈페이지를 방문합니다. 또한 서비스를 이용합니다.

하지만 여기서 SaaS의 특징이 있습니다.

1. 일단 저희가 제공하는 서비스를 사용하기 위해 따로 설치를 필요로 하지 않는다는 것입니다.

즉 브라우저를 통해서 모든 서비스를 고객이 사용할 수 있다는 뜻입니다.

2. 사용자는 인터넷 환경만 존재한다면 언제든지 저희 서비스를 이용할 수 있습니다.

3. 사용자가 저희 서비스에 만족하고 더 많고 퀄리티 높은 서비스를 제공받기 위해 결제를 하기도 합니다.

이는 부가적인 것입니다. 즉 On-Demand Service입니다.

4. 많은 사용자들이 한꺼번에 이용 가능합니다.

이러한 특징들은 먼저 운영체제 그리고 전자기기에 상관없이 사용 가능하다는 장점이 있습니다.

하지만 단점으로 인터넷이 반드시 필요하다는 것이며, 브라우저를 통해서만 사용가능하다는 점이 있습니다.

4. 마치며

자 오늘은 가볍게 IaaS, PaaS 그리고 SaaS를 알아보았습니다.

짧게 정리를 하겠습니다.

IaaS, PaaS는 개발자의 관점입니다.

즉 개발자가 원하는 서비스를 제공하기 위해 이러한 서비스를 이용하는 것입니다.

IaaS는 더 많은 리소스를 가상 머신을 통해 제공받으며 더 높은 유연성을 가집니다.

PaaS는 이보다 더 간결한 서비스입니다. 개발자는 자신의 코드만 환경에 제공해주면 알아서 배포까지 완료됩니다.

이는 더 쉽고 빠르고 저렴하게 원하는 서비스를 사용자들에게 제공할 수 있습니다.

하지만 PaaS를 제공하는 회사가 지원하지 않는 프로그래밍 언어로 개발하거나, 마이그레이션에 제한이 있을 수 있습니다.

마지막으로 SaaS는 개발자가 아닌 사용자의 시점으로 보아야 합니다.

즉 IaaS 혹은 PaaS를 통해 배포된 서비스를 고객이 사용하는 것을 의미합니다.(이러한 환경을 통하지 않고 모든 것을 직접 개발하고 배포된 서비스도 당연히 포함됩니다.)

즉 넷플릭스, 구글 메일 등과 같이 우리는 매일 이러한 서비스를 이용합니다.

또한 넷플릭스의 경우 On-Demand 즉 요구에 따라 사용자가 결제하고 서비스를 제공받기도 합니다.

이는 운영체제 혹은 사용자의 기기에 무관하게 사용 가능하며 인터넷과 브라우저만 있다면 언제든지 사용 가능합니다.

그 반대로 인터넷이 없거나 브라우저에 문제가 있다면 사용할 수 없다는 뜻이기도 합니다.

자 어떤가요?

그냥 이러한 의미들만 몰랐을 뿐 설명을 보신다면 아... 이게 그거구나? 할 정도로 이미 이러한 서비스들은

우리의 사회에 깊게 그리고 빠르게 제공되고 있습니다.

당연히 더 깊게 들어간다면 한없이 어려울 수 있지만, 지금은 초보 개발자로서 이러한 정보만 알고 있더라도 큰 힘이 됩니다.

오늘도 코딩하는 여러분을 응원하며 새해 복 많이 받으시기 바랍니다.

감사합니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

개발자들은 어떻게 버전을 표기할까? SemVer란 무엇일까?

OnceBH — Sun, 30 Jan 2022 23:13:59 +0900

개발자들은 어떻게 버전을 표기할까? SemVer란 무엇일까?

안녕하세요!

우리는 개발을 하면서 혹은 일상에서 버전에 관해서 많이 보고 들었습니다.

간단하게 자주 볼 수 있는 예를 제시하자면, 우리가 즐겨하는 게임을 실행하기 전

우리는 v 13.8.2와 같은 영어 v와 함께 여러 숫자들이 나열되어있는 것을 한 번쯤은 보았을 것입니다.

우리는 이를 보고 이 게임의 버전이구나 하고 생각하지만, 과연 어떻게 이러한 숫자들이 어떤 규칙을 따르는 것인지

그리고 그 규칙 중 하나인 SemVer 즉 semantic version에 관해서 알아보겠습니다.

SemVer란?
마치며

1. SemVer란?

SemVer란 Semantic Versioning의 약자로써 버전을 관리하는 형식 중 하나입니다.

많은 소프트웨워가 이러한 형식을 따르지만 꼭 모두 그런 것은 아닙니다.

대부분의 버전은 3가지의 숫자로 표시되며 이는 각각 점을 통해서 나뉘게 됩니다.

예를 들면 앞서 언급하였던 13.8.2가 될 수 있습니다. 이때 숫자의 제한은 없습니다.

자 그럼 왜 3가지의 숫자로 나뉘어있고, 각각 무엇을 의미하며 어떻게 사용되는지 알아보겠습니다.

이러한 숫자들은 Major, Minor, Patch를 각각 뜻하게 됩니다.

패치는 그럭저럭 감이 오지만 그렇다면 Major와 Minor는 무엇을 뜻하는 것일까요?

자 지금부터 알아보겠습니다.

Major: 메이저는 가장 큰 변화를 뜻합니다. 그 말은 즉 프로그램 혹은 라이브러리 등의 거대한 변화가 있으며,

이로 인해 예전에 작성되거나 사용 중에는 버전의 프로그램, 라이브러리 등이 새로운 버전을 적용 시 작동하지 않을 수 있을 정도의

큰 변화인 것입니다. 이때 중요한 것은 마이너와 패치의 숫자는 다시 0으로 초기화된다는 것입니다.

예를 들면 13.8.2 ->14.0.0과 같이 말입니다.

Minor: 메이저보다는 작은 변화를 말합니다. 이때 대부분 새로운 기능이 추가되었을때 마이너의 숫자가 올라가게 됩니다.

리액트를 예로 들어보면 페이스북에서 리액트 훅을 발표했을 당시 메이져 버전이 변경된 것이 아닌 마이너의 버전이 변경되었습니다.

이는 새로운 기능(feature)이기 때문입니다.

Patch: 이는 우리가 익숙하게 생각하는 버그 패치, 텍스트 변경 등등의 자잘한 패치들이 진행될 때 버전이 변경되게 됩니다.

이러한 변경점들은 몇 가지 규칙을 가지게 됩니다.

예를 들면 버전이 한 번에 2 혹은 3과 같이 올라갈 수 없습니다. 즉

13.8.2 -> 13.8.5로 껑충 뛰는 것은 불가능합니다. 항상 숫자는 1씩 올라가게 되어야 합니다.

또한 버전이 정해지게 된 후 업데이트가 잘못되었다는 것을 깨닫는다면 이때 버전을 돌리거나 바꿀 수 없습니다.

단지 다시 그 버그를 수정하여 그다음 버전으로 릴리스해야 합니다. 즉

13.8.2 ->13.8.3 패치 후 버그 발견 -> 버그를 수정한 후 13.8.4 버전으로 배포.

그렇다면 이러한 버전은 어떻게 하나하나 관리될까요??

사실상 개발자들조차 의식하고 알아차릴 수 있을까요?

정답은 네입니다. 이를 위해서 한 가지 모듈로 Semantic Release가 있습니다.

이는 버전의 변경에 따른 changelog의 변경과 배포를 도와줍니다.

이때 개발자는 깃을 통해 코드를 푸시할 때 커밋으로 몇몇 메시지를 남기게 됩니다.

예를 들면 fix, feature등과 같이 말입니다.

그렇다면 이를 통해 매니저는 새로운 패치, 업데이트가 있음을 감지하고 그에 상응하는 새로운 버전을 만든 후 배포합니다.

2. 마치며.

오늘은 짧게 버전에 관해 알아보았습니다.

사실 혼자서 자유롭게 프로젝트를 진행하다 보면, 버전 관리는 소홀해지기 마련이고, 그냥 읽기 쉽고 편하게

또한 다른 Branch 없이 master에 직접 코드를 푸시하고 간단하게 사용하기 마련입니다.

하지만 실제 협업에서는 이러한 작업방식은 모두를 난해하게 만들고 실수를 유발하기 마련입니다.

또한 회사는 각각의 라이브러리 혹은 모듈을 가지고 있는 경우도 있습니다.

이러한 모듈은 모든 개발자들이 공유해서 사용하는 경우가 많기 때문에,

코드의 수정이 있다면 그에 상응하는 버전을 항상 관리해주어야 합니다.

처음은 이해하기 힘들고 새로운 버전을 배포하기까지 실수는 하지 않았는지, 제대로 커밋을 했는지

많은 고민을 하게 될 것이지만 적응이 되면, 왜 버전이 관리되어야 하는지, 어떤 버전에 어떤 기능과 패치들이 존재하는지,

더 자세하고 쉽게 이해할 수 있을 것입니다.

다음은 실제 협업을 할 때 깃으로 어떻게 작업을 하는지 짧게 알아보겠습니다.

또한 많이 사용되는 커맨드들은 어떤 것들인지 역시 알아보겠습니다.

오늘도 제 블로그를 방문해주셔서 감사합니다.

저는 깊은 지식은 아니지만 이해하기 쉽고 머리에 많이 남을 핵심들을 게시글에 작성하려 노력하고 있습니다.

오늘도 여러분의 코딩을 응원하며, 즐거운 코딩하시기 바랍니다.

감사합니다.

완벽한 준비란 없다. 완벽한 준비란, 영원히 시작하지 않는 것과 같다.

Es gibt keinep perfekte Vorbereitung,

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

리액트 훅 React hooks와 스토리북 Storybook

OnceBH — Sun, 16 Jan 2022 22:35:39 +0900

리액트 훅 React hooks와 스토리북 Storybook

안녕하세요.

오늘은 리액트로 개발할 때 디자인을 좀 더 디테일하게 나누고 관리할 수 있는 storybook에 관해서 알아보겠습니다.

스토리북이란?
사용방법
마치며

1. 스토리북이란?

리액트로 개발할때 디자인 관리를 어떻게 하시나요?

npm start 혹은 yarn start를 이용하여 프로젝트를 실행하신 뒤 디자인하시나요?

그렇다면 이제는 스토리북을 이용해보실 차례인 것 같습니다.

스토리북은 기본적으로 디자인을 관리해주는 오픈소스입니다.

이해하기 조금 애매한가요?

즉 yarn start처럼 리액트를 실행시킨 뒤 즉석으로 디자인을 바꾸고 변화시키는 개념이 아닌,

개별 환경을 통해서 컴포넌트들을 문서화하는 개념에 가깝다고 할 수 있습니다.

또한 이를 통해 컴포넌트의 재사용, 테스팅할 수 있으며, 변화, 변경을 빠르게 확인해 볼 수 있습니다.

자 그럼 설치방법을 알아보겠습니다.

설치 방법은 아주 간단합니다.

아래의 커맨드를 통해서 설치할 수 있습니다.

npx sb init

그 뒤 모든 설치 과정이 끝날 때까지 기다리신 뒤, 설치가 끝나면

.storybook 폴더와 sotires 폴더가 생성된 것을 확인할 수 있습니다.

개발하시는 스타일에 따라 .storybook 폴더 안 main.js의 stories를 변경 혹은 추가해주시는 것이 좋습니다.

저의 경우 src폴더 안에 components폴더를 생성 그 후 컴포넌트 이름을 딴 폴더(logo) 그 안에 index.tsx파일과 stories라는 폴더
그리고 stories폴더 안에 index.stories.tsx파일을 생성합니다. 이해하기 난해할 수 있으니 아래에 예시를 만들어 놓았습니다.

예시:

src
ㄴ components
  ㄴ logo
    ㄴ index.tsx
    ㄴ stories
      ㄴ index.stories.tsx

아래의 구조를 이용하는 경우 "../src/**/**/*.stories.@(js|jsx|ts|tsx)"를 stories에 넣으시면 됩니다.

또한 다른 구조를 이용하신다면 그에 맞게 코드를 입력해주시면 됩니다.

자 이제 스토리북을 실행해보겠습니다.

아래의 커맨드를 통해 스토리북을 실행할 수 있습니다.

// npm
npm run storybook

// yarn
yarn storybook

2. 사용방법

스토리북이 문제없이 실행되었나요? 축하드립니다.

자 그럼 지금부터 사용방법을 알려드리겠습니다.

먼저! 일반적인 컴포넌트가 필요합니다.

이를 위해 임의의 컴포넌트를 만들어보겠습니다.

export interface Props {
  title: string;
}

const Hello: React.FC<Props> = ({ title }) => {
  return <div>{title}</div>;
};

export default Hello;

먼저 컴포넌트를 이해할 수 있도록 설명드리겠습니다.

인터페이스의 경우 저는 타입스크립트를 사용하기 때문에 작성한 것입니다.

자바스크립트로 개발하신다면 필요 없습니다.

자 저는 지금 Hello라는 컴포넌트를 작성하였습니다.

title이라는 prop으로 받으며, 그 값이 div에 감싸져 나타나게 됩니다.

즉 title이 Hello이면 Hello로 Bye면 Bye로 값이 나타난다는 것입니다.

그리고 컴포넌트가 다른 파일에 import 될 수 있도록 export 합니다.

자 그럼 이제 스토리북에 스토리를 작성해보겠습니다.

import { Meta, Story } from "@storybook/react";
import Hello, { Props } from "../index";

const meta: Meta = {
  title: "/components/Test",
  component: Hello,
};

export default meta;

const Template: Story<Props> = (args) => <Hello {...args} />;

export const Default = Template.bind({});
export const Bye = Template.bind({});

Default.args = {
  title: "Hello",
};

Bye.args = {
  title: "Bye",
};

먼저 Meta와 Story를 스토리북에서 import 한 뒤,

사용하려는 컴포넌트와 Propstype을 import 합니다.

그 뒤 meta라는 변수를 선언하고 그 안에 타이틀과 컴포넌트를 작성해줍니다.

title의 경우 스토리북 왼쪽에 리스트 형태로 나타나게 됩니다.

아래의 사진을 참고해주세요.

그리고 컴포넌트는 우리가 import 한 즉 사용하려는 컴포넌트를 입력해줍니다.

그 뒤 meta를 기본으로 export 합니다.

뒤이어 Template이라는 변수를 선언하고 타입을 Story<Props>로 지정합니다.

여기서 컴포넌트가 props를 가진다면 args 없다면 아무것도 필요 없습니다.

그 뒤 Default와 Hello를 생성합니다.(변수 이름은 자유롭게 사용하시면 됩니다.)

그리고 Template으로 bind 합니다.

그 뒤 props을 가지는 컴포넌트라면 아래와 같이 Deaulft.args 혹은 Hello.args를 작성해주면 되며,

아무런 props를 가지지 않는다면 필요 없습니다.

이해하기 어려운가요? 그렇다면 코드를 복사하여 직접 이것저것 시도해보세요.

그게 가장 빠르게 배울 수 있는 부분이라고 생각됩니다.

3. 마치며

위의 예시는 아주 간단하고 기본적인 예시입니다.

그 밖에 여러 기능들이 많습니다.

각각 설명드리지 못해 아쉽습니다. 하지만 처음이라면 기초가 어떻게 작성되는지 아는 것으로

스토리북의 시작을 좀 더 원활하게 할 수 있지 않을까 싶습니다.

프론트엔드는 아주 빠르게 변화하고 있습니다.

제가 그만큼 빠르게 반응하여 이런저런 기능들을 설명드리지는 못하지만,

그래도 현업에서 많이 쓰이고 생산성 좋은 기능, 기술들을 알려드리고 싶습니다.

저 또한 스토리북 마스터는 아니지만 서로 같이 배워가는 입장에서 한 걸음씩 앞으로 나아가고 싶습니다.

항상 제 블로그를 방문해주셔서 감사하고 조금이나마 도움이 될 수 있어 기쁩니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.
Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

독일 크리스마스는 가족과 함께

OnceBH — Thu, 6 Jan 2022 20:03:15 +0900

독일 크리스마스는 가족과 함께

안녕하세요.

크리스마스, 새해가 지났네요.

모두 새해 복 많이 받으시고 건강하시고 열심히 코딩하시기 바랍니다.

이번 독일의 크리스마스 역시 아주 조용하게 지나갔습니다.

그 이유는 대략 2가지로 볼 수 있을 것 같네요.

첫째는 당연히 코로나로 인해 크리스마스가 열리지 못하거나 그 규모가 많이 축소된 점.

두 번째는 폭죽 사용의 제제였을 것 같네요.

독일의 크리스마스는 볼거리, 먹거리가 아주 많습니다.

커다란 트리, 그 중심에서 열리는 크리스마스 마켓은 딱히 무언가를 사지 않더라도 꼭 들러보아야 합니다.

또한 Glühwein은 절대 잊지 말고 드셔야 할 크리스마스 대표 음료라고 할 수 있습니다.

하지만 이번 연도는 너무 조용했네요.

여러분들은 크리스마스를 어떻게 보내셨나요?

저는 아침에 부모님께 연락드린 후 여자 친구의 부모님 집으로 갔습니다.

독일의 크리스마스는 우리나라의 크리스마스와는 조금 다른 점이 있습니다.

저도 우리나라에서 크리스마스는 친구들과 술 한잔 기울이는? 그런 날이었지만,

독일에서 크리스마스는 가족들이 모두 모이는 날이라고 볼 수 있습니다.

그리고 옹기종기 큰 테이블에 모여 앉아 먹고 얘기하고 같이 보드게임을 합니다.

저 또한 여자친구의 부모님과 배 터지게 먹고 같이 Rummy라는 게임을 대략 5-6시간 한 것 같네요.

해외에서 생활하다 보면 설날, 추석은 잘 모르겠지만, 독일의 휴일, 명절에 가족들이 모이는 것을 보면

기쁘면서도 왜 그렇게 마음 한 군데 슬퍼지는지 모르겠네요.

이럴 때 가족들이, 친구들이 더 그리워지는 것 같습니다.

요즘은 기술도 많이 좋아져 얼굴 보며 화상채팅을 한다고는 하지만 확실히 바로 앞에서 대화하는 것보다는

부족한 점이 많죠. 저도 벌써 한국에 못 들어간 지 거의 4년이 다 되어가고 있네요.

이번 여름 아우스빌둥 졸업시험을 마친 꼭 가족, 친구들을 보러 들어갈 예정입니다.

여러분도 즐거운 크리스마스 보내셨기를 바라며, 항상 건강하시기 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 M1 맥북프로 교체 그리고 도커 컨테이너 이슈.

OnceBH — Sun, 26 Dec 2021 19:41:43 +0900

아우스빌둥 M1 맥북프로 교체 그리고 도커 컨테이너 이슈.

안녕하세요.

오늘은 아우스빌둥을 하면서 제가 처음부터 사용하던 노트북과 현재의 m1 맥북프로에 대하여 말씀드리겠습니다.

회사에서는 아쭈비들을 위해 랩탑을 제공해주는 경우가 대부분입니다.(컴퓨터가 필요 없는 직군이라면 그렇지 않을 수 있습니다.)

저는 처음 아우스빌둥을 시작할 당시 레노버의 Thinkpad를 제공받았습니다.

당시의 노트북으로 아우스빌둥 프로젝트 혹은 공부를 하기에는 충분한 사양이었으나 회사에서 개발자들을 위한 전용 노트북을

다시 한대 제공해 주었습니다. 즉 저는 처음 아우스빌둥을 시작하면서 2대의 노트북을 가지고 시작하게 된 것입니다.

다시 새로 받은 노트북은 개발자들을 위한 노트북으로 같은 Thinkpad였으나 사양이 훨씬 더 높은 노트북이었습니다.

그렇게 1년을 아무런 문제없이 잘 사용하였습니다.

당시 저는 HTML, CSS 그리고 자바스크립트만 사용하던 상황이었고, 회사의 프로젝트에 직접 관여하지 않기 때문에,

전혀 문제가 없었습니다. 그렇게 2년 차에 접어들게 되었습니다.

당시 저보다 1년을 먼저 시작한 다른 친한 아쭈비가 3년 차에 접어들게 되면서 맥북으로 교체를 하게 되었습니다.

그 당시 저와 같은 Thinkpad를 사용 중이었으나, 모바일 개발로 넘어가고 싶어 했던 친구였기에,

아무래도 윈도우보다는 맥이 훨씬 더 좋은 선택이었죠.

그렇게 2년 차 중반기에 저는 아우스빌더와 이야기를 하게 됩니다.

그건 바로 제 노트북을 3년 차에 접어들기 전에 바꾸자는 것이었습니다.

그 이유는 3년 차부터 팀에서 회사 프로젝트를 직접 다루게 되는데 윈도우를 사용하여 개발하는 인원이 한 명도 없었기 때문입니다.

처음 제안은 윈도우를 지운 뒤 리눅스를 설치하는 것이었으나, 회사 측에서 위험부담이 있으며, 아쭈비가 리눅스를 사용한 경우가

없기에 정말 개발을 위해서 운영체제를 바꿀 필요가 있다면 맥북을 사용하라는 답변을 받습니다.

그 뒤 저는 아우스빌더와 이야기하여 맥북을 새로 주문하기로 합니다.

주문 당시 이미 인텔 맥북은 더 이상 구매하지 못하여 M1 맥북프로를 구매하게 됩니다.

주문하려던 그 당시가 2년 차가 끝나갈 무렵이었습니다.

하지만 학교와 여러 일로 인하여 3년 차에 접어들어 맥북프로를 주문하였죠.

회사의 답변은 맥북프로가 도착하기까지 대략 7주가 걸릴 것이라는 것이었습니다.

그러하여 일단 윈도우에 가상 머신을 돌려 리눅스로 작업을 하고 있었습니다.

어느덧 8주의 기다림 속에 지친 저는 현재 상황을 알기 위해 문의를 하였습니다.

돌아오는 답변은 저를 당황하게 하였습니다.

그 답변은 회사의 서버팀에서 온 것이었습니다. 그건 바로 현재 m1를 사용하는 개발자가 회사 내에 없으며,

그로 인해 도커 컨테이너가 다른 프로세서를 인식하지 못할 것이라는 것이었습니다.

그렇지만 그나마 긍정적인 답변은 언젠가 대부분의 인텔 맥이 실리콘 맥으로 바뀌어야 할 것이며,

ARM 프로세서를 지원하기 위해 현재 컨테이너를 개발 및 업데이트하고 있다는 소식이었습니다.

저는 먼저 의견을 제시했습니다.

현재 제가 사용하는 맥북이 M1 맥북에어이며, 개인 맥북에 먼저 시험을 해보고 싶다고 말이죠.

그리고 답변 또한 다행히 긍정적이었습니다.

그리고 역시나 테스트 결과 컨테이너는 ARM을 인식하지 못했습니다.

그 뒤 저는 아우스빌더와 이를 상의하였고, 결론을 냈습니다.

일단 M1 맥북프로를 제가 전 직원 중 제일 처음으로 받고, 서버팀과 협력하여 컨테이너 테스트를 하라는 것이었죠.

그러하여 장장 10주가 넘는 기간을 새로운 맥북을 위해 기다렸고, 드디어 저번 주 따끈따끈한 M1맥북 프로를 받았습니다.

10주 만의 시간이라서 그런지 아니면 새 맥북을 받아서 그런지 기다리는 동안 지겹고, 답답했지만 막상 받으니

모든 기다림의 시간이 한순간 녹아내리는 듯한 기분입니다.

여러분은 주로 어떤 운영체제를 통해 개발하시나요??

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 졸업 과제 준비.

OnceBH — Sun, 5 Dec 2021 20:40:35 +0900

아우스빌둥 졸업 과제 준비.

아우스빌둥을 졸업하기 위해서 대부분의 직군에 졸업 과제가 존재합니다.

오늘은 개발자 아우스빌둥의 졸업 과제는 무엇인지 알아보겠습니다.

아우스빌둥이란?
개발자 아우스빌둥 졸업 과제?
개발자 아우스빌둥 졸업 후?
마치며.

1. 아우스빌둥이란?

이미 이 부분은 자세하게 설명해놓은 게시글이 존재합니다.

그렇기에 짧게 다루고 가겠습니다.

아우스빌둥 자체에 좀 더 관심이 있으시다면 아래의 링크를 확인해주세요.

https://ko-de-dev-green.tistory.com/6?category=864456

독일 아우스빌둥 시작하기까지.

독일 아우스빌둥 시작하기까지. 1. 독일 아우스빌둥이란? 아우스빌둥이란 듀얼 프로그램이다. 즉 학교와 회사에서 교육, 트레이닝을 받게 되는데 직군에 따라 다르지만, 나 같은 경우 대략 6주

ko-de-dev-green.tistory.com

아우스빌둥은 3년간 회사와 학교에서 교육을 받는 것으로,

회사에서는 실질적 업무에 필요한 기술을 배우게 되며,

학교에서는 이론을 배우게 됩니다. 하지만 학교와 아우스빌둥을 담당하는 IHK는 각자 서로 다르기 때문에,

아우스빌둥 마지막년차에(대부분 3년을 기준으로 합니다.) IHK에서 제시하는 졸업 시험을 보게 됩니다.

아우스빌둥 졸업 시험에 관해서는 한번 더 자세하게 올릴 예정입니다.

오늘은 개발자 아우스빌둥 졸업에 필요한 과제를 알아보는 시간만 가지도록 하겠습니다.

2. 개발자 아우스빌둥 졸업 과제?

앞에서 언급하였듯이 개발자 아우스빌둥을 졸업하기 위해서는 프로젝트를 담당해야 합니다.

프로젝트의 선택은 자유입니다. 하지만 꼭 회사와 연관된 프로젝트만 하여야 합니다.

이를 위해서 당연히 아우스 빌더와 이에 관해 이야기해보아야 합니다.

혹은 저 같은 경우 3년 차에 팀에 직접적으로 속하여 아우스 빌더와 PO에게 직접적으로 과제를 받습니다.

이는 회사마다 다를 수 있기 때문에 구체적으로 말씀드리기 조금 애매합니다.

아우스빌둥을 하는 상태 시라면 아우스 빌더에게 문의하시는 게 제일 빠릅니다.

프로젝트는 IHK로부터 확인을 받아야 합니다. 이를 위해서 프로젝트에 관련된 정보를 IHK에 보내야 합니다.

그 뒤 IHK의 승인이 떨어지게 되면 프로젝트를 시작하시면 됩니다. 이때 가장 중요한 것은 문서화하는 것입니다.

이는 후에 문서와 프레젠테이션의 형태로 IHK에 제출되어야 하며, 후에 발표를 통해 프로젝트에 관해 설명하게 됩니다.

이때 가장 중요한 것은 회사와 관련된 프로젝트이기에 결과를 보여주거나 회사와 관련이 깊은 정보를 제공할 필요가 없다는 것입니다.

프로젝트에 관해서만 언급하시면 됩니다. 프레젠테이션의 경우 꼭 파워포인트로 만드실 필요는 없습니다.

이때 팁은 프로젝트를 수행할 수 있는 시간이 정해져 있습니다. 그렇기에 이러한 시간을 잘 분배하여 사용하시는 것이 중요하며,

또한 꼭 문서화시키시는 게 중요합니다. 개발자로 일하면서 어쩌면 가장 중요한 것 중 하나가 모두 문서화시키는 것입니다.

또한 이를 위해 독일어는 필수입니다.

3. 개발자 아우스빌둥 졸업 후?

졸업시험을 끝마치신 경우 아직은 아쭈비입니다.

그리고 그 후 졸업 시험의 결과를 알게 되는 시점, 즉 졸업 시험을 통과했다는 것을 알게 된 그 시점부터 당신은

아쭈비가 아닙니다. 이는 가능적한한 빨리 회사에 통보되어야 합니다.

사실 3년 차에 들어가면 대부분 11월에서 1월 사이에 팀의 대표와 아우스빌둥 졸업 후를 이야기합니다.

이때 우리는 졸업 후 정직원으로 채용될 수 있는지 또한 연봉은 어느 정도 될지를 이야기하게 됩니다.

회사의 경우 당연히 정직원으로 채용하기 위해 아쭈비들을 고용합니다.

그렇기에 웬만하면 정직원으로 채용될 것입니다.

하지만 아우스빌둥 기간 동안 불량한 태도를 보였거나, 회사의 재정 혹은 상황이 좋지 못하거나 그 외의 직원이 충분하거나 등등의

이유로 정직원 채옹이 거부 혹은 거절될 수 있습니다.

하지만 대부분 1-2년 정도 아우스빌둥을 제공한 회사에서 경력을 쌓은 후 다른 회사로 이직하는 경우가 많다고 합니다.

일단 가장 중요한 것은 정직원으로 채용될 수 있는 지를 아시는 것입니다.

또한 이는 가능한 한 빨리 이야기되는 것이 좋습니다. 아쭈비가 먼저 물어봐야 하는 것이며, 물어보지 않는다면 회사 측에서

정직원으로 남고 싶지 않아 하는 것으로 판단할 수 있습니다.

그렇기에 3년 차를 시작하셨다면 가능한 한 11월에서 1월 사이에 꼭 이에 관해 이야기해보세요.

4. 마치며.

오늘은 짧게 개발자 아우스빌둥 졸업에 필요한 졸업 과제에 관하여 알아보았습니다.

다음은 졸업 시험 전반적인 중요한 것들에 관해서 모두 적어보는 시간을 가져보겠습니다.

요즈음 아우스빌둥을 시작하시거나 준비하시는 분들에게 많은 연락을 받습니다.

제 블로그를 찾아 주신 모든 분들께 감사하고 또한 타 지도 아닌 타국에서 준비하시고 노력하시는 모습 너무 멋집니다.

모두 꼭 좋은 소식 있으시길 바라며, 오늘도 파이팅하시기 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

리액트 훅 React Hooks Lazy이란?

OnceBH — Tue, 16 Nov 2021 00:38:51 +0900

리액트 훅 React Hooks Lazy이란?

안녕하세요. 오늘은 리액트 훅에서 사용되는 lazy에 관해서 알아보려고 합니다.

프로젝트가 거대해지고 무거워지는 과 동시에 발생하는 문제 중 하나는 로딩 문제일 것입니다.

느려져봐야 0. 몇 초 혹은 몇 초? 일 텐데 그게 큰 상관일까 싶지만, 사실 이는 큰 문제입니다.

많은 개발자들이 0.1초라도 줄이기 위해 최적화 작업에 공을 들이고 있습니다.

그렇기에 우리도 이러한 기능을 알아두면 참 좋을 것입니다.

Lazy와 Suspense.
사용방법.
마치며.

1. Lazy 와 Suspense.

Lazy를 사용하기 위해서 꼭 알아야 할 것이 있습니다.

이는 바로 Suspense인데요. 이것 없이 Lazy를 사용할 수 없습니다.

Suspense는 JSX로 사용되며, fallback이라는 prop을 받게 됩니다.

이때 prop의 값을 JSX로 받을 수 있습니다.

여기서 Suspense는 감싸고 있는 컴포넌트가 렌더링 과정에 있을 시 fallback에 명시된 JSX를 먼저 보여주게 됩니다.

그리고 컴포넌트의 렌더링이 끝나게 되면 자동으로 해당 컴포넌트를 보여주게 됩니다.

이 둘을 사용하기 위해서는 react로부터 import 되어야 합니다.

아래의 예시 코드를 보시죠.

import { lazy, Suspense } from 'react';

자 이렇게 lazy를 사용할 컴포넌트 안에 위와 같이 import 해주셔야 합니다.

자 그럼 사용 준비는 끝이 났습니다. 그럼 사용 방법을 알아보러 가시죠.

2. 사용방법.

사용방법을 알아보겠습니다.

처음 우리는 새로운 컴포넌트가 필요합니다. 이를 위해 src 폴더에 components폴더를 생성하고

그 안에 임의의 컴포넌트를 생성하겠습니다.

저는 MyTest라는 임의의 컴포넌트를 생성하였습니다.

코드는 아래의 코드 블록을 확인해주세요.

const MyTest = () => {
  return <div>This is MyTest component</div>;
};

export default MyTest;

이 코드를 더 짧게 만드시려면,

아래와 같이도 작성 가능합니다.

const MyTest = () => <div>This is MyTest component</div>;

export default MyTest;

자 그럼 App 파일을 보도록 하겠습니다.

저는 App에서 lazy를 사용할 것이기에, App 안에 lazy와 Suspense를 import 합니다.

import { lazy, Suspense } from 'react';
const MyTest = lazy(() => import('./components/myTest'));

const App = () => {
  return (
    <div className='App'>
      <Suspense fallback={<div>loading...</div>}>
        <MyTest />
      </Suspense>
    </div>
  );
};

export default App;

자 그럼 천천히 위의 코드를 보겠습니다.

먼저 제일 위를 보시면 lazy와 Suspense를 import 하였습니다.

그다음 변수로써 MyTest를 초기화하고 lazy 함수를 이용했습니다. 이는 콜백 함수를 파라미터로 받습니다.

그 뒤 import 하려는 파일의 경로를 작성해주었습니다.

그다음 Suspense를 작성해줍니다. 위에 언급한 것과 같이 Suspense는 fallback이라는 prop을 받습니다.

이는 JSX로 <div>loading...</div>이라고 작성해주었습니다.

그 뒤 Suspense안에 MyTest를 넣어줍니다.

그렇다면 이미 우리는 모두 끝낸 것입니다.

이론 상 처음 페이지가 로드되거나 페이지가 리로드 될 때 MyTest는 렌더링 과정에 들어갈 것이고,

그 과정에서 먼저 fallback에 명시된 JSX가 유저에게 보입니다.

그 뒤 MyTest가 렌더링을 끝내고 보여지게 될 수 있을 때 MyTest가 유저에게 보이며 fallback의 값은 사라집니다.

이를 확인하기 위해 페이지를 리로드 해보세요.

너무 빨라서 확인하기 힘드신가요? 혹은 변화를 확인할 순간도 없이 렌더링이 끝났나요??

이는 우리의 프로젝트가 너무 작기 때문입니다.

이를 위해서 네트워크의 성능을 낮춰 줄 필요가 있습니다.

어떻게 하는지 가볍게 알아보겠습니다.

개발자 툴을 열어주세요. 크롬의 경우 F12번을 눌러 주세요.
Network 탭으로 들어가 주세요.
No throtting이라고 나와있는 곳을 눌러주신 뒤 Fast 3G 혹은 Slow 3G로 바꿔주세요.
다시 리로드 해보세요.

아마 이렇게 하시면 확인이 가능하실 겁니다.

이는 일시적으로 네트워크의 속도를 늦춰주는 것입니다.

3. 마무리.

오늘은 lazy에 관해서 알아보았습니다.

사실 혼자서 개인 프로젝트를 하는 것으론 이러한 기능을 사용하기 어려울 수 있습니다.

성능의 차이 혹은 로딩 시간에 큰 영향을 미칠 정도의 규모의 프로젝트를 하지 않기 때문이죠.

하지만 몰라서 사용하지 못하는 것과 알지만 사용할 이유가 없어 사용하지 않는 것은 다릅니다.

분명히 회사에서 큰 프로젝트를 맡거나 다른 개발자들과 협업을 하다 보면 필요할 수 있는 기능입니다.

항상 개발 툴, 개발 라이브러리, 프레임워크는 하루가 다르게 발전하고 바뀌어 갑니다.

옛것을 하는 것도 중요하지만 새로 나온 것 혹은 몰랐던 기능을 사용하는 것 또한 정말 중요합니다.

항상 노력하시고 열심히 공부하시기 바랍니다.

저 역시 이렇게 블로그를 개설 후 스스로 공부하고 게시글을 올리면서 많이 배우게 되는 것 같습니다.

이렇게 블로그를 방문해주시는 유저분들과 같이 공부하고 나눌 수 있어서 기쁩니다.

항상 응원하겠습니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

React hooks 리액트 훅 useRef란?

OnceBH — Mon, 1 Nov 2021 02:57:27 +0900

React hooks 리액트 훅 useRef란?

오늘은 리액트의 중요한 훅 중 하나인 useRef를 배워보려 합니다.

useRef라는 훅은 다른 useState 혹은 useEffect보다는 사용 빈도가 낮은 것 같습니다.

저 역시 리액트를 이용하면서 useRef를 사용해본 적이 정말 손에 꼽을 정도로 적은 것 같습니다.

하지만 당연히 알고 사용하는 것과 모르고 사용하지 못하는 것은 정말 다를 것입니다.

오늘은 가볍게 useRef에 관해서 알아보겠습니다.

useRef 사용 방법.
마무리.

1. useRef 사용 방법.

아래의 코드를 설명해드리겠습니다.

Click me 버튼을 누르면 isRef는 현재의 boolean값의 반대 값을 가지게 됩니다.

즉 기본 값이 false 이면 true, true 이면 false가 됩니다.

그리고 isRef값이 true가 되면 ActiveRef라는 JSX를 통해서 input tag이 렌더 되며,

useEffect를 통해 isRef값이 변경될 때마다 로그가 생성됩니다.

ref는 input tag뿐만 아닌 다른 tag도 가능합니다.

또한. current를 이용하여 tag를 이용할 수 있습니다.

예 ) refElement.current

아래의 코드는

{isRef ? <ActiveRef /> : null}

이와 같이 변경하실 수 있습니다.

{isRef && <ActiveRef />}

import { useRef, useState, useEffect } from 'react';

const App = () => {
  const refElement = useRef<HTMLInputElement>(null);
  const [isRef, setIsRef] = useState(false);

  useEffect(() => console.log(refElement.current), [isRef]);

  const ActiveRef = () => (
    <div>
      <input type='text' ref={refElement} />
    </div>
  );

  const activeIsRef = () => setIsRef(!isRef);

  return (
    <div>
      <button onClick={activeIsRef}>Click me</button>
      {isRef ? <ActiveRef /> : null}
    </div>
  );
};

export default App;

2. 마무리.

앞에도 언급했듯이 useRef는 useState 혹은 useEffect에 비해 적게 사용되는 것 같습니다.

하지만 당연히 사용할 줄 아는것이 중요합니다.

useRef는 javascript에 document.getElementById()와 같이 사용 할 수 있습니다.

오늘은 가볍게 useRef에 관해서 알아보았습니다.

useRef가 비교적 적게 사용된다는 것이지, 사용되지 않는다는 것은 아닙니다.

꼭 사용 방법을 숙지해두시기 바랍니다.

오늘도 열심히 미래를 준비하시는 모습이 정말 멋집니다.

하루하루 크게 다를 것 없는 하루 같지만 언젠가 뒤돌아보면 예전보다 나아진 자신을 발견할 것입니다.

오늘도 내일도 파이팅입니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.
Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

아우스빌둥 3년 차 팀에서 일하며 느낀 점.

OnceBH — Sun, 24 Oct 2021 17:03:13 +0900

아우스빌둥 3년 차 팀에서 일하며 느낀 점.

안녕하세요.

저는 현재 아우스빌둥 3년 차를 진행 중이며, 제가 다니는 회사는 3년 차부터 직접 팀에 일원으로써

팀과 직접 소통하고 팀원으로써 실제 업무를 받아 일을 하게 됩니다.

그리고 또한 아우스빌둥 3년 차, 즉 졸업반은 회사와 관련된 자신의 프로젝트를 제출해야 되기에,

이에 대한 준비도 하게 됩니다. 오늘은 이렇게 일하면서 느낀 점과 제 경험을 적어보려 합니다.

아우스빌둥이란?
1년 차, 2년 차는 어땠는가?
3년 차 팀에서 일하며 느낀 점.

1. 아우스빌둥이란?

아우스빌둥이란 쉽게 말해 회사와 학교를 병행하며 교육을 받는 교육방식입니다.

아우스빌둥은 여러 직업군별로 나뉘어있으며, 직업군마다 서로 다른 교육을 받게 됩니다.

개발자 아우스빌둥은 대략 5-6주는 회사 2주는 학교를 가는 방식으로 되어있습니다.

하지만 이는 지역에 따라 다를 수 있습니다.

학교에서는 같은 직업군을 가진 아쭈비들과 다 같이 수업을 받게 됩니다.

이때 다른 아쭈비들은 당연히 다른 회사의 아쭈비들이며, 얘기를 나눠보면,

회사마다 모두 커리큘럼이 다르다는 것을 알 수 있습니다.

예를 몇 가지 들어보자면,

1. 개발자 아우스빌둥을 시작했으나, 고객의 전화나 이메일을 직접 응대하는 경우.

2. 코딩을 먼저 배우기 전 DB와 SQL을 먼저 배우는 경우.

3. 연차에 따라 프런트엔드와 백엔드를 배우는 경우.

4. 처음부터 다 배우는 경우.

등등 천차만별입니다.

아우스빌둥의 궁극적인 목적은 졸업 후 회사에서 정직원으로 일하는 것이며,

회사의 상황 혹은 자신의 태도, 성적, 실력에 따라 회사가 졸업 후 정직원으로 채용하지 않는 경우도 있습니다.

제가 다니는 회사의 경우 매년 20명 혹은 그 이상의 여러 직군의 아쭈비들을 선별하며,

정말 위의 경우가 아니라면 대부분 대략 90퍼센트 이상은 정직원으로 채용됩니다.

하지만 이 또한 회사에 따라 천차만별이기 때문에 정확하다라고는 말할 수 없습니다.

2. 1년 차, 2년 차는 어땠는가?

저 같은 경우 독일어가 항상 걸림돌이었습니다.

특히 실전에서는 어학원에서 배우지 않는 문법, 문장, 숙어 등이 정말 많아서

처음에는 정말 긴장하며 회사를 다녔습니다.

왜 언어는 또 그렇게 빨리 나아지지 않는 것일까요?

정말 언어는 끝이 없고, 항상 곁에 두고 상시 사용해야 하는 것 같습니다.

저 같은 경우 프론트엔드에 더 관심이 있었던 터라, 1년차를 프론트엔드로 시작했습니다.

저같은 경우 이미 웹 개발에 필요한 언어를 대부분 할 줄 알았었고, 장고로 소규모 프로젝트도 해본 적이 있었기에,

큰 무리 없이 맡은 프로젝트를 수행할 수 있었습니다.

2년 차부터 백엔드를 시작했지만,

대규모 프로젝트를 받게 되었습니다. 풀 스택으로 회사 내에서 사용 가능한 예측 게임을 개발했습니다.

독일에 유명한 tv 프로그램이 있어, 그에 대한 결과를 예측하는 프로젝트였습니다.

저는 이때 정말 많이 성장한 것 같습니다.

처음부터 프런트엔드와 백엔드는 어떤 언어를 사용할 것인지, 어떤 라이브러리, 프레임워크를 사용할 것인지

스스로 결정하고 문서화한 뒤 담당자의 피드백을 받고, 프로젝트의 작업을 소규모로 나누어 다시 문서화했습니다.

그 뒤 디자이너 아쭈비와 함께 작업을 했습니다. 즉 스크럼을 따라 개발을 시작한 것이지요.

이때 코딩 실력뿐 아니라 팀으로써의 역할과 작업의 분할을 배우고, 이러한 프로세스를 따르면 어떤 이득이 있고,

어떠한 과정이 있는지 배워나갔습니다.

3. 3년 차 팀에서 일하며 느낀 점?

저희 회사의 경우, 1-2년 차는 아쭈비로써 팀이 아닌 독립적으로 아우스빌더에게 과제를 받고 도움을 받습니다.

그리고 3년 차를 시작하기 전 프락티 쿰으로 모든 팀을 경험해보고 3년 차가 시작될 때 팀을 결정 후

PO(Produkt Owner)에게 직접 과제를 받습니다. 처음 제가 팀에 들어갔을 당시,

팀은 새로운 작업에 많이 바빴기 때문에 과제를 직접 받지 않았고 일단 모든 회의에 참가하여,

팀의 분위기, 팀의 강점, 팀의 역할을 배워나갔고, 그 뒤 천천히 과제를 받았습니다.

혼자서 개발환경을 세팅한다고 애를 먹기도 했었죠.

그 뒤 천천히 업무를 받고 적응해가고 있는 상황입니다.

또한 3년 차에 팀에서 일하면서 드디어 얼마나 협업이 중요하고 커뮤니케이션이 중요한지 한번 더

깨달을 수 있었습니다. 좋은 개발자란 코딩만 잘하는 것이 아닌 커뮤니케이션을 코딩만큼이나 잘해야 한다는 것 또한

깨달을 수 있었습니다. 앞으로 배울 것이 많습니다. 하지만 아우스빌둥을 통해 정말 많이 성장했다는 것을 스스로

느끼고 있습니다. 가끔은 아우스빌둥을 하지 않았다면? 하는 생각도 하지만 역시 아우스빌둥을 선택하길 잘했다고

생각합니다.

오늘은 그냥 일기? 형식으로 가볍게 써 내려갔네요.

여러분은 이제까지 인생을 바꿀 수 있는 새로운 결정, 도전을 해보신 적이 있으신가요?

결정에는 항상 용기가 필요한 것 같습니다. 끝이 좋든 좋지 않든, 그건 해보지 않으면 모르는 일입니다.

낯선 것, 모르는 것에 너무 막연한 불안감과 걱정을 할 필요는 없는 것 같습니다.

걱정을 하지 마시고, 준비를 하시길 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung,

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

리액트 훅 useEffect를 JSX와 함께 사용해보자.

OnceBH — Thu, 21 Oct 2021 02:06:29 +0900

리액트 훅 useEffect를 JSX와 함께 사용해보자.

안녕하세요 이번 시간에는 예전 useEffect를 설명하며 빠트렸던 부분에 대해 설명하려 합니다.

리액트로 개발을 하다 보면 필연적으로 사용하게 되는 것이 useEffect입니다.

useEffect는 렌더링이 끝난 뒤 한번 실행되게 되며, 파라미터에 따라 무제한으로 변화에 따라 실행시키거나

파라미터로 지정된 state가 변화 시 실행되거나 혹은 정말 렌더링 후 딱 한 번만 실행시키는 등

다양한 방법이 존재합니다. 이는 아래의 링크에서 확인하실 수 있습니다.

https://ko-de-dev-green.tistory.com/18?category=865864

React hooks 리액트 훅 useEffect란?

React hooks 리액트 훅 useEffect란? 오늘은 또 하나의 리액트 훅에 없어서는 안 될 useEffect를 알아보겠습니다. 여느 때와 마찬가지로 전혀 비전문적이고 간단하게 설명하려고 합니다. 목차. useEffect

ko-de-dev-green.tistory.com

또한 리액트로 작업을 하다 보면, 지금 당장은 필요하지 않지만, 후에 혹은 조건에 따라

useEffect를 실행시키고 싶은 경우도 생깁니다.

이럴 때 사용해 보실 수 있는 것이 useEffect를 JSX와 함께 사용하시는 것입니다.

아래의 코드의 경우 우리가 자주 사용하는 useEffect의 형태일 것입니다.

아래의 코드는 처음 hello라는 텍스트를 보여준 뒤 콘솔에 working!!이라는 로그가 남을 것입니다.

하지만 이는 아주 빠르게 실행되기에 사람이 인지하기란 쉽지 않죠.

이렇게 실행되는 코드의 장점은 코드가 실행되고 렌더링이 끝난 뒤 useEffect가 실행된다는 것입니다.

하지만 앞에서 말했듯 특정한 경우에만 useEffect를 실행하려는 경우 어떻게 해야 할까요??

const App = () => {

    useEffect(() => {
    	console.log("working!!");
    },[])

	return <div>hello</div>;
}

export default App;

일단 특정한 경우에 실행한다는 것은 어떤 경우일까요??

이러한 경우는 예를 들면, 조건에 따라 특별하게 렌더링 되어야 하는 JSX가 있을 시 좋습니다.

이를테면 Modal 같은 경우입니다.

이러한 경우 모달이 렌더링 되지 않는다면 useEffect의 사용을 줄일 수 있으니,

불필요한 성능을 낭비할 필요도 없습니다.

아래의 코드와 같이 변경하실 수 있습니다.

이렇게 사용되는 경우는 생각보다 적지 않습니다.

이 외에도 많은 방법들이 존재하지만, 오늘은 useEffect를 항상 component의 최 상단에서 사용하시는 여러분께

알려드리고 싶었습니다. 또한 이러한 코드는 fetching을 할 때도 좋습니다.

위에 언급했다시피 불필요한 useEffect의 사용을 줄일 수 있기 때문입니다.

특히 커스텀 훅을 이용하신다면 이와도 잘 어울립니다.

const App = () => {
    const Test = () => {
        useEffect(()=>{
            console.log("hello");
        },[])
        
        return null;
    }

    return (
        <div>
            <Test />
        </<div>
    );
    
}

export default App;

또한 당연히 아래의 코드와 같이 파라미터를 주어 조건에 따라 useEffect를 재실행하실 수도 있습니다.

이렇게 실행하시면 특정 필요한 상황에 useEffect를 발생시키고 그 후 state가 변화할때마다

useEffect가 실행 될 것입니다.

const App = () => {
  const Test: React.FC<{ name: string }> = ({ name }) => {
    useEffect(() => {
      console.log('hello');
    }, [name]);

    return (
      <div>
        <p>{name}</p>
      </div>
    );
  };
  
  return (
      <div>
          <Test />
      </div>
  );
}

export default App;

마지막으로 오늘은 useEffect를 함수 안에서 실행시키고 return 값으로 jsx를 주어, 필요한 상황에만

useEffect를 실행하는 방법을 배웠습니다.

사실 사용 방법은 무궁무진 한것 같습니다. 항상 프로젝트나 상황에 따라 다르게 변화할 테니 말이죠.

저도 아직 배울게 투성이지만 여러분과 중요한 정보가 아니더라도 나눌 수 있어 정말 행복합니다.

오늘 하루도 무사히 마무리하시고 항상 좋은 일만 가득하시길 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung is das Gleiche, wie nie anzufangen.

프로그래밍 공부 방법. 프로그래밍 기초 배우기.

OnceBH — Fri, 15 Oct 2021 23:38:25 +0900

프로그래밍 공부 방법. 프로그래밍 기초 배우기.

안녕하세요. 요즘은 코딩을 전문적으로 또는 취미로 배우시는 분들이 많아지고 있습니다.

예전에 뉴스로도 학교에 정규과목으로 프로그래밍을 추가하려 한다는 것을 본 적이 있습니다.

사실 프로그래밍은 꼭 개발자가 아니더라도 많은 도움이 됩니다.

특히 문제를 이해하고 스스로 로직을 만들어 해결하는 능력에 정말 좋은 것 같습니다.

또한 많은 분들이 프로그래밍은 어려운 것이다.

프로그래밍은 개발자가 아니면 하기 힘들다.

독학이 불가능하다 등등 많은 잘못된 지식을 가지고 계시는 분들도 많습니다.

(프로그래밍, 개발 어렵습니다. 하지만 전문적으로 무언가를 한다면 어렵지 않을 것이 어디 있겠습니까?)

오늘은 프로그래밍을 처음 시작하시려는 분들께 동기부여도 팍팍 주고 또한 실력도 많이 늘 수 있는 방법

몇 가지를 소개해드리려 합니다.

이는 제가 사용한 방법이기도 하기에 따라 해 보시는 것도 좋은 방법일 것 같습니다.

그럼 알아보겠습니다.

내가 배우고 싶은 언어는 무엇인가?
처음부터 끝까지 기초를 끝내는 것이 좋을까?
개발 공부에 도움이 되는 것들은?
마치며.

1. 내가 배우고 싶은 언어는 무엇인가?

처음부터 어쩌면 가장 결정하기 힘든 부분이군요.

개발을 처음 시작하신다면 멋진 게임도 만들어보고 싶고, 앱도 만들어보고 싶고,

홈페이지도 만들어보고 싶고 또는 해킹기술도 배우고 싶을 것입니다.

그리고 당연히 분야에 따라서 배우고 공부해야 되는 언어도 많이 달라집니다.

저는 먼저 이러한 고민에 가장 무난하다고 생각한 언어는 자바였습니다.

자바는 두루두루 많이 사용되기도 하며, OOP이기 때문이었죠.

지금도 현업에서 두루 사용되고 있는 언어이기도 합니다.

하지만 많은 언어들이 존재하듯, 당연히 배우려는 사람의 목적과 성격에 따라

다른 언어들도 많습니다.

2. 처음부터 끝까지 기초를 끝내는 것이 좋을까?

저는 처음에 기초를 끝내겠다는 생각으로 아무것도 모르는 상태에서

모든 기초를 끝냈습니다. 하지만 이는 솔직히 제게 그렇게 많이 도움이 되었다 라고

말하기 힘들 것 같습니다. 그 이유는 기초를 배우지만 상황에 맞는 조그마한 프로젝트를

같이 만들고 배울 수 있다면 더 쉽게 이해하고 왜 이러한 기능들이, 기술들이 필요한지

알게 되기 쉽기 때문입니다. 그렇다면 이런 상황에 맞는 조그마한 프로젝트란 무엇일까요?

아래에서 알아보겠습니다.

3. 개발 공부에 도움이 되는 것들은?

요즘은 정말 유튜브가 많이 발달하여 모든 대부분의 언어들을 배우고 클론 프로젝트를 만들어보기 좋습니다.

하지만 대부분의 클론 프로젝트는 어느 정도 기본 지식을 요하며, 그렇다고 튜토리얼 동영상을 보니

열심히 배우겠다는 마음은 온데간데없이 잠이 솔솔 옵니다.

그래서 저는 유튜브에서도 많이 배웠지만 유데미라는 플랫폼을 자주 이용합니다.

유데미는 여러 개발뿐만 아니라 여러 분야의 강의들을 제안, 제공해주는 곳입니다.

하지만 대부분의 강의들이 유료이기에 결제를 해야 한다는 불편함이 있습니다.

하지만 대부분의 강의들이 세일 기간에 2만 원-4만 원이면 구매할 수 있고, 평생 소장 가능하기에,

치킨 한 두 번 안 먹는다는 생각으로 결제를 하시면 마음이 편합니다.

일단 유데미에서 강의를 구매하시면, 기초뿐만 아니라 사이드 프로젝트들을 많이 접해 볼 수 있고,

더 체계적이기 때문에 집중하기도 스스로 공부하기도 훨씬 더 편합니다.

또한 진행상황을 보고 끝가지 강의를 완료했을 때의 성취감도 높습니다.

애석하게도 대부분의 강의들이 영어이기에 영어를 어느 정도 할 줄 알아야 한다는 것이 발목을 잡지만

개발자라면 사실 영어를 기본적으로 어느 정도는 해야 합니다.

그렇다면 일석이조의 효과도 기대해 보실 수 있습니다.

4. 마치며.

사실 처음 배울 언어를 고민한다는 것은 쉽지 않습니다.

이럴 때는 시장의 동향을 파악하는 것도 나쁘지 않습니다.

어느 언어, 프레임 워크, 라이브러리가 유명하고 자주 사용되는지 등을

파악하는 것도 하나의 방법입니다.

또한 사실 공부라는 것이 끝이 없습니다.

유데미에서 강의를 완료한다고 전문가 같은 실력이 나오기는 힘들 것입니다.

하지만 언어를 어느 정도 다룰 수 있다면, 그때부터는 시도해볼 수 있는 문이, 길이 트입니다.

책으로 공부하시는 것도 아주 좋은 방법입니다. 하지만 하루가 다르게 변하는 IT업계이기에,

항상 최신의 정보를 기대하기는 어려울 수 있습니다.

마지막으로 프로그래밍, 개발은 어렵습니다. 하지만 스스로 프로그램을 만들고, 직접적인 사용자들이

생기기 시작한다면 또 다른 재미를 느끼실 수 있습니다.

시작이 반입니다. 무슨 일을 하시든, 하고 싶으시든 처음부터 안될 것이다, 어려울 것이다, 시간이 없다 라는 생각 말고

시도해보자, 차근히 해보자, 끝가지 해보자 라는 마음가짐으로 도전하시기 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung is das Gleiche, wie nie anzufangen.

M1 맥북 에어 기본형 웹, Xcode 개발 후기.

OnceBH — Mon, 13 Sep 2021 17:10:44 +0900

M1 맥북 에어 기본형 웹, Xcode 개발 후기.

안녕하세요. 오늘은 제가 대략 3개월 전 구매했던 맥북 기본형에 대해 짧은 후기를 남기려 합니다.

그리고 또한 맥북이 과연 개발할 때 정말 좋을지 알아보려고 합니다.

개발하려면 맥북?
3개월 웹, 스위프트 개발 후기.
마치며.

1. 개발하려면 맥북?

제가 독일에서 경험해본 바로 여기선 개발자들이 윈도우보다는 맥북을 선호하는 것 같습니다.

왜 그런 걸까요?? 단지 감성?? 디자인이 심플하고 멋져서? 아니면 개발자 스티커를 붙이기 좋아서?

스타벅스 출입?? 이를 위해선 운영체제 또한 터미널을 알아야 할 필요가 있습니다.

애플의 맥은 Unix 계열 중 하나입니다. 이는 리눅스 또한 마찬가지입니다.

여러 배포판이 있지만 사실 Unix를 기초 바탕으로 나온 여러 갈래의 리눅스들인 셈입니다.

이 중 유명한 배포판으로 페도라, 우분투, 칼리 등등이 있습니다.

좀 더 자세한 정보는 리눅스 배포판을 검색해 보시면 될 것입니다.

하여튼 이러한 Unix계열은 상상 이상으로 뛰어난 터미널을 보유하고 있습니다.

그리고 이러한 터미널은 단지 파일을 생성, 실행, 삭제하는 것에 그치지 않고

다운로드, 업데이트, 각종 셀 수 없을 정도로 많고 유용한 명령어를 이용하여 무궁무진한 사용성을 보여줍니다.

또한 이러한 터미널을 이용하면 손쉽게 개발 세팅을 준비하고 설치할 수 있습니다.

이게 제가 생각하는 가장 궁극적인 이유가 아닌가 싶습니다.

또한 여러 이유들이 존재할 것 같습니다.

튼튼한 하드웨어, 부드러운 동작, Xcode를 사용하기 위해서 등등.

그러한 이유로 사실 개발자들이 윈도우를 많이 사용하지만 리눅스, 맥 OS에도 많이 분포하고 있는 것 같습니다.

2. 3개월 웹, 스위프트 개발 후기.

먼저 애석하게도 안드로이드 스튜디오는 실험해보지 못했습니다.

하지만 3개월 동안 맥북을 웹, 스위프트 앱 개발을 위해 사용했었습니다.

이에 관해 저는 너무너무 만족하고 있습니다.

이번 M1 맥북은 정말 놀랄 정도의 가성비와 성능을 자랑하는 것 같습니다.

현재 저는 개인용으로 M1 맥북 회사 개발용 랩탑으로 윈도우를 사용 중입니다. (이 역시 현재 새 맥북을 기다리는 중입니다.
윈도우로 개발환경을 세팅하는 것도 가능하지만 여간 불편한 일이기 때문입니다.)

맥북은 에어 기본형이며 회사 개발용 랩탑은 i7 고성능 CPU에 램은 32GB입니다.

하지만 실제로 개발할 때 더 빠르게 동작하는 것은 맥북입니다.(하지만 안드로이드 스튜디오 같은 혹은 또 다른 무거운 프로그램을

오래 유지하면 회사 개발용 랩탑이 더 좋은 성능을 발휘할지도 모릅니다.)
이 부분에 정말 놀라웠습니다.

또한 미디어에서도 극찬한 발열입니다. 정말 거의 열이 느껴지지 않으며, 뜨겁다 보다는 이제 조금 미지근하네 정도입니다.

Xcode를 통해 개발할 때도 마찬가지였습니다. 발열을 느끼기 정말 어렵고, 버벅거림이나 끊김이 전혀 없습니다.

너무 부드럽게 동작해서 오히려 놀랐습니다.

그리고 배터리가 정말 미쳤습니다.

저는 지금 맥북을 개발, 블로그 혹은 가끔 유튜브를 보기 위해 사용하며, 한번 사용 시 사용시간은 1-3시간 정도 되는 것 같습니다.

이를 고려할 때 1번 완충하여 1주일을 대략 사용하는 것 같습니다.

3. 마치며.

저는 결과적으로 너무 만족하고 있습니다.

과거 맥북을 구매하고 싶을 당시 정말 말도 안 되는 가격에 많이 좌절하다 이번 M1이 출시되면서

가격이 많이 하양 되었고 여자 친구 또한 맥북을 사용하며 여러 번 추천하여 이번을 계기로

가장 저렴한 에어 기본형을 구매하였는데, 사실 전혀 문제없이 개발자로서 필요한 프로그램들을 수행했습니다.

하지만 일반 대학생분들에게는 맥북이 그리 좋지 않을 수 있습니다.

사실 대학생 때 랩탑 구매 시, 나는 정말 게임을 하지 않을 것이다. 나는 정말 공부, 작업을 목적으로 구매할 것이다 라며,

랩탑을 구매하지만 한두 달 지나면 게임 하나씩은 설치하시지 않나요? (저는 그랬습니다..)

맥북으로 실행 가능한 게임들이 늘어나고는 있지만, 사실 아직도 불편한 점이 많고, 추후에 게임을 할 거라면 윈도우가

답이지 않을까 싶습니다. 하지만 개발자라면 그럼에도 불구하고 맥북을 고려해보시는 것도 좋은 방법일 것 같습니다.

그리고 맥북을 뭐 배우기 어렵다. 헷갈린다. 힘들다고 하는 글들이 있습니다.

그런데 사실 2-3일만되면 필요한 기능들은 거의 문제없이 사용 가능합니다.

그러니 걱정 마시고 도전해보세요.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung,

Perfekte Vorbereitung is das Gleiche, wie nie anzufangen.

아우스빌둥 선배로써 후배에게 무엇을 해주는가?

OnceBH — Sun, 12 Sep 2021 22:04:57 +0900

아우스빌둥 선배로써 후배에게 무엇을 해주는가?

아우스빌둥을 준비하시거나 아우스빌둥에 관심을 가지는 분들이 늘어나고 있습니다.

저는 개인적으로 정말 좋은 현상인 것 같습니다.

하지만 막상 아우스빌둥을 준비하고 시작하게 된다고 하더라도, 절망적인 독일어, 문화 차이 등의

걱정을 하시는 분들이 많을 것 같습니다. 사실 당연합니다. 새로운 환경에 새로운 언어를 사용한다는 것이

여간 쉽지 않고 긴장도 많이 됩니다.

하지만 사실 그런 부분은 크게 걱정 할 것이 없다는 것입니다.

그 이유는 필요한 사항, 정보를 아우스빌더가 다 준비해주기 때문입니다.

하지만 아우스빌더가 모든 것을 준비하거나 도와줄 수 없습니다.

왜 일까요?? 아우스빌더라면 모든 사항에 저를 도와주고 책임져주어야 되는 것 아닐까요??

반은 맞고 반은 틀리지 않을까 싶습니다.

사실 아우스빌더도 일반 직원입니다. 즉 아우스빌더 또한 팀에서 직원으로서 일하기 때문에 자신의 업무가 있습니다.

그렇기에 항상 아쭈비를 옆에서 돌보고 도와주지 못합니다.(당연히 아우스빌더가 후에라도 시간이 된다면 와서 도와줄 것입니다.)

하지만 이러한 상황을 좀 더 유연하게 대처하기 위해서 아우스빌둥을 1-2년 먼저 시작한 다른 아쭈비들이

당신을 도와줄 것입니다. 제가 다니는 회사에서는 alter Hase라고 합니다.

alter Hase는 직역하자면 늙은 토끼이지만, 의역하면 그 분야의 노련한 전문가를 뜻합니다.

alter Hase는 기본적으로 아우스빌더가 가르쳐주지 않아도 되는 사소한 것들을 책임지게 되는 경우가 많습니다.

가령 새로운 아쭈비에게 작은 문제가 생겼거나, 프로젝트의 준비를 도와주거나 그 외의 대부분 사소한 질문들에 답하고 도와줍니다.

저의 경우 또한 alter Hase로써 1년 먼저 시작한 아쭈비가 저를 도와주었습니다.

그리고 제가 아우스빌둥 2년 차를 시작할 때 아쉽게 새로운 아쭈비가 들어오지 않았지만 제가 3년차를 접어든 지금 새로운 아쭈비가

들어왔고 지금은 제가 alter Hase로써 새로운 아쭈비의 대부분 질문, 문제를 도와주고 있는 상황입니다.

아우스빌둥을 시작하게 되면 배울 것들이 정말 많습니다.

제가 다니는 회사의 경우 2주 정도 회사의 규율 기본 이메일 작성방법 여러 툴 사용방법을 배웁니다.

제가 항상 말씀드리지만 처음에 제일 어렵고 힘든 법입니다.

그 후부터는 크게 어려울 것이 없습니다. 아우스 빌더와 커리큘럼에 대해 이야기하고, 앞으로의 방향을 잘 잡으시면 됩니다.

지금 이 순간에도 아우스빌둥을 준비하시는 분들이 계실 거라 생각합니다.

아우스빌둥을 하기로 결심하신 그 마음을 정말 존경합니다.

아우스빌둥을 시작하시더라도 너무 크게 걱정하지 마시고, 주눅 들지 마시고 씩씩하고 적극적으로 행동하시기 바랍니다.

우리나라도 마찬가지지만, 독일에서도 항상 적극적으로 동참하고 자신의 생각을 자신 있게 말하는 사람을 좋아합니다.

무슨 일이 있어도 얼머부리시거나 회피하지 마세요. 잘못했다면 바로 인정하시고 해결법을 찾으려 노력하세요.

아쭈비로써 가장 중요한 것은 적극적으로 배우려는 마음과 노력입니다.

질문하는 것도 두려워하시거나 고민하지 마세요.

당연히 너무 자주 물어보고 똑같은 질문을 여러 번 하면 문제이지만, 그렇지 않은 이상 아우스빌더나 선배 아쭈비들은 다 이해합니다.

그리고 하나라도 더 알려주려고 노력합니다. 그러니 너무 걱정하지 마시고 질문하시기 바랍니다.

오늘은 아우스빌둥을 시작할 때 선배들은 신입들에게 무엇을 해주는지 알아보았습니다.

사실 별거 아니게 보일 수 있습니다.

아 그냥 뭐 이거 저거 알려주고 도와주는 건데 뭘 이렇게 장엄하게 적었어 싶으실 수 있으나,

사실 그 이외에도 정말 많은 도움을 얻을 수 있고 또 도움을 주려고 노력합니다.

오늘도 즐거운 하루 보내시길 바랍니다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine Perfekte Vorbereitung,

Perfekte Vorbereitung is das Gleiche, wie nie anzufangen.

Typescript와 React npm 모듈 설치관련 정보.

OnceBH — Sat, 11 Sep 2021 23:00:49 +0900

Typescript와 React npm 모듈 설치 관련 정보.

개발자에 관한 관심이 많아지면서, 자연스럽게 코딩을 접하는 분들이 많아지고,

프런트엔드에 필요한 프로그래밍 언어, 라이브러리 혹은 프레임워크를 배우시게 되는 과정에서

리액트를 알게되거나 배우시는 분들이 많아지는 것 같습니다.

저는 개인적으로 너무 좋은 현상이라고 생각합니다.

개발자는 자신의 지식을 이리저리 꽁꽁 숨기는 직업이 아닌 너도나도 지식을 나누어 필요한 혹은 유용한

프레임워크 라이브러리 혹은 알고리즘을 대중화시키고 나누는 것이 중요합니다.

리액트를 배우시는 경우라면 자바스크립트를 어느 정도 사용하실 수 있다는 뜻일 것입니다.

또한 그 과정에서 타입스크립트를 들어보시거나 경험해 보신 분들도 많을 것입니다.

오늘은 타입스크립트로 리액트 프로젝트를 할 때 npm 모듈에 관해 잠시 이야기해보려 합니다.

타입스크립트로 리액트 프로젝트를 만드는 방법.
타입스크립트를 사용할 때 모듈 관리방법.
마치며.

1. 타입스크립트로 리액트 프로젝트를 만드는 방법.

리액트 프로젝트를 시작하신다면 대부분 create-react-app이라는 모듈을 아실 것입니다.

이 모듈은 리액트 프로젝트에 필요한 기초적인 세팅을 편하게 준비해주는 모듈입니다.

당연히 이러한 모듈 없이도 직접 세팅을 하실 수 있으나, 가장 편리하고 보편적으로 사용되는 방법이

아마 create-react-app이지 않을까 싶네요.

기본적인 터미널 명령법은 프로젝트를 생성할 경로에 npx create-react-app my-project-name입니다.

하지만 타입스크립트를 기반으로 리액트 프로젝트를 생성하시려면

npx create-react-app my-project-name --template typescript라고 입력하시면 됩니다.

그러면 자동으로 타입스크립트를 기반으로 하는 리액트 프로젝트가 생성됩니다.

그럼 파일의 확장자는 jsx가 아닌 tsx로 바뀌게 됩니다.

2. 타입스크립트를 사용할 때 모듈 관리방법.

자바스크립트를 기반으로 리액트 프로젝트를 하신다면 필요 없는 내용이지만,

타입스크립트를 사용하신다면 생각보다 유용한 내용일 것 같습니다.

타입스크립트를 기반으로 하는 리액트 프로젝트에서 npm 모듈들을 정확히 인스톨하여도

에러가 뜨는 경우가 있습니다. 그럴 때는 먼저 npm 홈페이지를 확인하시는 것이 중요합니다.

몇몇 모듈은 곧잘 타입스크립트를 지원하기도 하나 대부분의 모듈이 또 다른 디펜던시를 설치해 주어야 합니다.

방법은 전혀 어렵지 않습니다.

예를 보시겠습니다.

위의 axios의 경우 옆에 TS라고 표시되어있습니다.

그렇다면 타입스크립트의 경우에 별다른 추가적인 디펜던시 없이 곧바로 인스톨해주시면 됩니다.

예를 들면 npm install axios와 같이 말이죠.

자 그럼 다음의 경우를 보겠습니다.

styled-components의 경우 옆에 TS가 아닌 DT라고 표시되어있는 것을 알 수 있습니다.

이러한 경우 두 번의 모듈 설치가 필요합니다.

한 번은 npm install styled-components입니다.

그 후 추가적인 설치를 위해 DT를 클릭해주세요.

그렇다면 페이지가 바뀌면서 아래와 같이 될 것입니다.

모두가 인스톨하는 경우가 다르나 저의 경우 추가적인 모듈을 설치할 때 -D옵션으로 devDependency로 분류합니다.

예를 들면 npm install -D @types/styled-components와 같이 터미널에 입력합니다.

styled-components와 같이 따로 설치해야 하는 모듈이 존재하는 경우, TS의 모듈만 설치해서는 동작하지 않기에,

두 개의 모듈을 모두 설치하는 것이 중요합니다.

3. 마치며.

자 오늘은 가볍게 typescript에서 개발을 시작할 때 npm 모듈들에 관해 알아보았습니다.

자바스크립트로 시작하다 타입스크립트로 처음 코드를 작성하다 보면, 편하다, 좋다는 느낌보다는

너무 불편해, 짜증 나, 왜 자꾸 오류가나... 하는 생각이 더 많이 들게 됩니다.

하지만 이렇게 하나씩 배워가는 게 아닐까요??

오늘도 짧은 글 읽어주셔서 감사합니다. 조금이나마 제 글이 도움이 될 수 있으면 좋겠습니다.

항상 좋은 하루 보내시고, 열공하시고 열심히 코딩하시기 바랍니다!

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

과연 인생은 자기 자신이 만드는 것이다.

OnceBH — Wed, 25 Aug 2021 05:59:54 +0900

과연 인생은 자기 자신이 만드는 것이다.

기회를 기다리는 것보다 스스로 만드는 것이 더 중요하다 라는 말을 많이 들었습니다.

하지만 그럴 때마다 항상 문득 드는 의문이 있었습니다.

"아니 그게 기회인지 어떻게 확신하고 스스로 만드라는 거지?? 만약 그게 기회가 아니라면??",

"만약 내가 그게 기회라는 것조차 모르고 있다면??"

그러다 대학교 2학년을 마칠 때 즈음 가장 친한 형이 저에게 묻더군요.

나랑 같이 독일 워킹홀리데이 한번 안 해볼래??

저는 당시 독일과 워킹홀리데이에는 전혀 관심조차 없었습니다.

하지만 딱 한 가지 생각이 들더군요.

"다른 나라에서 살아보는 것도 재미는 있겠네, 경험이나 한다고 생각하고 가봐야겠다."

당시 아르바이트로 모아둔 돈으로 준비해서 무작정 아무 생각 없이

단지 그냥 독일에서 살아보고 싶다는 생각으로 형과 독일에 갔습니다.

저는 당시 그냥 독일 일상이 궁금했고, 그 일상에서 무엇을 경험할 수 있을지.

딱 그게 제가 독일에 온 목적이었습니다. 무언가 체계적으로 준비해서 유학을 준비하는 것이 아닌

단지 그냥 독일 일상이 궁금해서 그것도 아주 가벼운 마음으로 말이죠.

사실 워킹홀리데이가 끝나갈 때 즈음 경험하고 주변 사람들을 보곤 후회를 조금 했습니다.

하... 이렇게 워킹홀리데이를 사용하지 말고 좀 더 체계적으로 준비해서 올걸 하고 말이죠.

하지만 그에 비해 정말 많은 인생공부, 인생 경험을 했습니다.

아마 그때로 돌아가면 여전히 지금과 똑같이 행동했을 것 같습니다.

그리고 이때 지금 하고 있는 아우스빌둥에 대해 알게 되었습니다.

그렇게 한국에 돌아가기 전날까지 아무런 생각도 느낌도 없었는데,

방문 앞에서 제가 지내온 방을 보니 왠지 모를 울컥함이 저를 덮쳐 왔습니다.

왠지 모를 서러움과 슬픔으로 한참을 울었던 것 같네요.

그 뒤로 한국에 온 뒤 저는 제 스스로 결정을 내렸습니다.

아우스빌둥이란 것에 도전하기로, 독일에서 다시 지내기로.

그리고 당장 대학교를 그만두었습니다.

어떻게 보면 제 삶에서 처음으로 인생이라는 것을 바꿀지 모르는 결정을 내린 것이지요.

그 뒤 제 산업체 복무가 마치는 날까지 가능한 한 많은 돈과 정보를 모으려 노력했습니다.

복무를 마치고 지체 없이 곧바로 독일로 향했습니다.

지체하면 지금까지 공들여온 제 노력과 시간이 낭비되고 흐지부지될 것 같았습니다.

독일에 도착 후 다시 처음부터라는 생각으로 옳은 결정이라는 믿음으로

독일어와 아우스빌둥을 준비했습니다.

그리고 지금은 제가 결정하고 꿈꿨던 결과를 이루었고 또 이루는 중입니다.

제가 나이가 많은 건 아니지만 인생이라는 건 항상 주체적이어야 한다고 생각합니다.

기회인지 모를 것이 기회가 되는 건 나 스스로 새로운 것의 도전이고 용기이며,

그 기회인지 모를 것을 기회라고 느끼는 그 순간부터

내 스스로의 결정과 노력이 반영이 되는 것이라 생각합니다.

제가 독일 워킹홀리데이라는 도전을 하지 않았다면?? 더욱이 용기가 없어서 하지 못했다면?

그 기회일지 모르는 것은 정말 기회가 되었을지 모를 것으로 남아 사라지지 않았을까요??

제가 워킹홀리데이 도중 아우스빌둥을 알게 되었지만, 아우스빌둥을 하기로 결정하고

준비하는 노력이 없었다면 그것 또한 기회일 뻔했던 것에 지나지 않았을까요??

저희는 살면서 항상 도전과 용기라는 것에 갈등하고 결정과 노력이라는 것에 시간을 할애합니다.

스스로의 삶은 스스로 만들어가는 것입니다.

모든 도전이 알맞은 결정이 되는 것은 아니지만,

도전조차 안 해본다면 내가 내 인생을 못 바꾸는데 그 무엇이 내 인생을 바꿀 수 있을까요?

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.

자바스크립트 동기? 비동기? 초보 개발자 공부

OnceBH — Mon, 23 Aug 2021 23:50:54 +0900

자바스크립트 동기? 비동기? 초보 개발자 공부

오늘은 자바스크립트의 동기, 비동기 함수에 관해서 이야기해보려 합니다.

우리는 개발을 진행함에 따라 이러한 말들을 많이 들어볼 텐데요.

오늘도 아주 쉽게 알아보도록 하겠습니다.

자바스크립트 작동원리.
동기 함수란?
비동기 함수이란?
마무리.

1. 자바스크립트 동작원리.

우리는 동기, 비동기 함수들을 알아보기 전 자바스크립트가 어떻게 작동을 하는지

잠시 들여다볼 필요가 있습니다.

우리가 사용하는 언어는 대부분 2가지의 형태를 띠고 있습니다.

컴파일러 언어 혹은 인터프리터 언어가 그것입니다.

(자바 혹은 C#과 같이 JIT 컴파일러를 사용하는 언어도 있습니다.)

컴파일러와 인터프리터에 관해 좀 더 자세히 알고 싶으시다면,

아래의 링크를 확인해주세요.

https://ko-de-dev-green.tistory.com/20?category=864457

Compiler(컴파일러) 와 Interpreter(인터프리터) 차이점.

Compiler(컴파일러)와 Interpreter(인터프리터) 차이점. 우리는 무언가 개발하기 위해서 프로그래밍 언어를 사용합니다. 하지만 우리가 작성한 코드는, 사람을 위한 코드이죠. 컴퓨터를 위한 코드는

ko-de-dev-green.tistory.com

우리가 사용하는 자바스크립트는 인터프리터 언어입니다.

인터프리터 언어는 쉽게 말해 컴퓨터와 코드 사이에 중간 해석자가 존재하며,

코드를 한 줄 한 줄 읽는 대로 컴퓨터에 해석해서 알려주는 것을 의미합니다.

또한 자바스크립트는 기본적으로 여러 가지 작업을 동시에 작업할 수 없습니다.

자바스크립트는 기본적으로 위에서 아래로 하나의 동작씩 수행해 나갑니다.

왜 그러한지는 아래에서 알아보겠습니다.

2. 동기 함수란?

동기 함수란 전혀 어려울 게 없습니다.

아래의 코드와 같이 우리가 평소에 사용하는 함수입니다.

const sayHello = () => console.log("hello");

3. 비동기 함수란?

자 그럼 이제 비동기 함수를 알아봅시다.

제가 위에서 언급했듯이, 자바스크립트는 하나의 작업씩 차례대로 수행해 나간다고 했습니다.

하지만 비동기 함수를 만난다면 자바스크립트는 비동기 함수를 일반 동기 함수처럼

수행하는 것이 아닌 대기하는 공간에 두게 되고 거기서 비동기 함수가 수행됩니다.

즉 자바스크립트 스스로

"아 이건 비동기 함수네, 일단 대기하는 공간에 미뤄두고 결과가 나오면 그때 받아서 사용해야지"

라고 생각하고 수행합니다.

즉 비동기 함수는 스택에(Stack)서 동기 함수처럼 실행되고 결과가 나올 때까지 기다리는 것이 아닌,

비동기 함수는 옆에 대기하는 공간에서 실행되고 결과를 받아오면 다시 스택에 올려 보내게 됩니다.

하지만 바로 스택에 올라가는 것이 아닌 큐(Queue)에서 결과를 받아온 뒤 스택으로 올려 보냅니다.

큐는 스택이 비어있다면 그때 하나씩 결과를 올려 보내고 스택이 결과를 받아 수행하게 됩니다.

자 설명이 길었습니다.

이제 어떻게 비동기 함수를 작성하는지 보겠습니다.

비동기 함수는 대략 2가지 종류가 있습니다.

오늘은 async await을 작성하고 다음에는 promise를 작성하겠습니다.

async await은 비교적 최근 문법이며, promise보다 쉽고 가독성 높게

코드를 작성할 수 있습니다.

그렇기에 이번 시간에 먼저 async await을 다루고 다음에 promise를 다루기로 했습니다.

아래의 코드를 보겠습니다.

// 동기 함수
const fetchData = () => {
	const data = fetchSomthing('fetching URL');
	console.log(data);
};

// 비동기 함수
const fetchData2 = async() => {
	const data = await fetchSomthing('fetching URL');
	console.log(data);
};

자 위에 동기와 비동기 함수가 존재합니다

위의 두 함수가 둘 다 실행된다고 한다면

첫 번째 fetchData함수 동기 함수로써 undefined 혹은 null이 나오게 될 것입니다.

그 이유는 fetchSomething이라는 함수가 api를 통해 데이터를 가져오기 전 콘솔 로그가 출력되기 때문입니다.

아래의 코드는 비동기 함수입니다.

함수의 파라미터 앞에 async라는 키워드가 있고,

그리고 fetchSomething이라는 함수 앞에 await이라는 키워드가 붙어있습니다.

이 뜻은 즉 fetchSomething이라는 함수를 실행하고 데이터를 가져오기까지 기다린 뒤

결괏값을 받아오면 그때 콘솔 로그를 출력해라 라는 뜻입니다.

사용방법이 전혀 어렵지 않습니다.

두 가지 키워드만 사용하면 비동기 함수를 만들 수 있는 것입니다.

4. 마무리.

자 다시 한번 키워드만 짚어보겠습니다.

1. 자바스크립트는 사실 하나의 작업만 수행하고 그 작업이 끝날 시 다음 작업으로 넘어갑니다.

2. 비동기 함수는 스택에서 실행되지 않고 대기하는 공간으로 보내진 뒤 그곳에서 실행됩니다.

3. 대기하는 공간에서 실행되어 결과를 얻은 함수는 큐에 보내져 스택이 비워진 뒤 큐에서 스택에 보내게 됩니다.

4. 비동기 함수는 2가지가 있습니다. promise와 async await

5. async await은 최신 문법이며 await 키워드가 있다면 키워드가 붙어있는 작업이 끝날 때까지 기다린 뒤

다음 작업으로 넘어가게 됩니다.

매번 말씀드리지만 시작이 가장 어렵습니다.

천천히 차근차근 배우신다면 어떠한 일이든 꼭 좋은 결과가 있을 겁니다.

다 같이 힘내서 공부합시다.

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.