Moon on River

주절주절 세상에서 제일 늦은 2023년 회고

강에 뜨는 달 — Mon, 4 Mar 2024 21:49:38 +0900

사실 더 일찍 쓰고 싶었는데 이 제목으로 글을 작성하고 싶은데, 계속해서 사람들이 이런 제목으로 회고를 작성해서 좀만 늦게 써서 히히 내가 제일 늦게 써야지

하다가 결국 지금 쓰게 되었다...

아예 할꺼면 2Q에 연말 회고를 하고 3Q에 연초 회고를 하면 세상에서 제일 빠른 연말 회고, 제일 느린 연초 회고를 할 수 있지 않을까?

이직

회사를 옮기게 되었다.

이런 저런 이유로 회사의 내부 사정이 어려워지고,

사실 그건 별로 상관 없는데,

보고 배울만한 분들이 떠나고 회사 분위기가 전체적으로 축 쳐지는것이 너무 싫었다.

이직한 회사는 기존 회사랑 많이 다른 느낌이다.

기존 회사는 돈은 못벌고 기술적인 부분에서는 뛰어났고,

현 회사는 돈은 잘 벌지만 기술적인 부분에서 더 나아질수 있는 부분들이 많이 보인다.

그만큼 성장을 빠르게 많이 했다는 반증이며 할 수 있는 것들이 많다는 것이 좋다.

책

책을 많이 읽었다

아주 많이는 아니지만

지난 1년간 처음 회사를 다니며 이것저것 배웠지만

좋은 코드가 무엇인가?

에 대해서 그렇게 치열하게 고민해보진 않았고, 그 점이 아쉬웠다

올해 읽었던 개발 관련된 책

- 클린 아키텍쳐

- 좋은 코드 나쁜 코드

- 오브젝트

솔직히 말해서 그렇게 완전 모든 문장 하나하나를 집중해서 읽진 않았다. 원래 그런 스타일이 아니기도 하고

보통 그떄 읽었던 느낌만을 기억하는 편이다. 가끔은 읽는 방식을 바꿔서 읽어보면 다르게 보이지 않을까 하는 생각도 있다.

읽다보니 드는 생각으로는

위 책들에서는 좋은 코드, 설계에 대한 방법론으로 설명을 하지만, 이 개념이 꼭 코드, 시스템 설계에 대해서 국한되는 얘기만은 아니겠다는 생각이 들었다

결국 좋은 OO를 만들기 위한 방법의 일환으로

OO에 대한 개념에 제약을 건다는 것이다.

그것이 팀의 영역으로 가면 코딩 컨벤션이라던지, 개발적 방법론에 영역에 가면, 함수형, OOP, 등의 방법론을 통해 추구하는 것이 아닐까.

만약 좋은 코드가 무엇이라고 생각하냐는 질문에 OOP를 따르며 SOLID 원칙을 잘 지키는 코드라고 하면 그것은 맞는 말일까?

모르겠다.

OKR처럼 좋은 코드가 가지는 특성이 Object가 되고 OOP->SOLID 원칙을 준수하는 것은 Key Result여야하지 않을까

그럼 좋은 코드란 무엇일까

개발자의 의도와 동일하게 살아있는 코드가 아닐까?

살아남았다는건 강하다는 것 Yeah

단순히 오래 살아남아있다는 것이 좋은 코드인거 같지는 않다.

죽지 못해 살아있는 코드를 좋은 코드라고 할순 없으니까

딱 깔끔하게 죽을 코드는 죽고, 오래 살아있을 코드는 의도대로 살아있는 것이 좋지 않을까

갑자기 너무 글이 길어져서 여기까지...

글

좀 사람들에게 가치를 만드는 글을 쓰고 싶다는 목표가 있었다.

그 목표를 잡고 귀신같이 티스토리에서 글 쓰는 것을 멈췄다.(..?)

너무 목표가 거창했나...

그래도 연말이 되어서 후다닥 글을 하나 쓰게 되었다.

https://kanary159357.github.io/blog/why_use_ref/

Why useRef has different types?

Let's figure out why useRef has several types in types/react

kanary159357.github.io

useRef의 type은 왜 이따구로 많은가? 에 대해서 찾아봤다. useRef의 3가지 타입이 어디다 쓰는진 알겠는데, 진짜 의도가 이건지?가 궁금했다.

글 쓰고 싶은건 좀 있다.

Barrel files가 large file webpack 환경에서 얼마나 악영향을 끼치는데 프로파일링하는거 레포랑 글 딱 준비하면 좋을거 같고

RNNoise 붙이면서 RNNoise가 뭔데? 그리고 WASM 코드는 왜 이렇게 짰는데? Web Audio의 기초적인것들 등등

적어도 올해는 위의 내용들은 다 써보면 좋겠다.

아쉬운 점

그래서 내가 회사에서 올해 뭐했는데?를 문서화하지 못했다. 이것도 근시일내에 까먹기 전에 이력서에 업데이트해야겠다.

-> 이력서 업데이트하고 1Q 혹은 TF 종료시 업데이트해보자

전반적인 인생 및 생각에 대한 문서화가 부족한거 같다. 옵시디언에 풀어내보자

해보고 싶은 것

강의를 찍어보자 인프런에 크몽에?

YIN Algorithm Step 6: Best local estimate

강에 뜨는 달 — Tue, 11 Jul 2023 23:12:33 +0900

식 1~6에서는 추정치가 아정적이고 기본 주기의 시간 척도에 따라 변동하지 않도록 해주는것임.

반대로 변동하면 이건 제대로 했다고 보기 어려움. Tt가 시간 t에 대한 추정치라고 할때 d'(Tt)의 비교적 높은 값과 일치하는 주기의 특정 단게에서 이런 일이 일어나는 경우가 있음. 다른 단계(time t`)에서 추정치가 정확하고 d'(Tt`)도 더 작을 수 있음. Step 6에서는 이 사실을 기반으로 더 나은 추정치를 위해 분석 지점을 '쇼핑'함

시간 인덱스 t에 대해서 d`(T)에 대한 최소값을 구함

Tma는 최대 예측 주기임.

초기 추정치를 기반으로 검색범위를 제한해서 추정 알고리즘을 적용해서 최종 예측값을 정함.

직접 구현하려고 했었는데, 이미 구현된것들이 너무 많고, 이미 구현된거 디테일에서도 논문만 봐서는 몰랐을 것들이 많아서, 해당 코드를 뜯어보고 논문을 정리하면 좋을거 같다.

그리고 LaTex를 배워야지 티스토리에서 정리된 글을 쓸 수 있을거 같다.

YIN Algorithm: Parabolic interpolation

강에 뜨는 달 — Sat, 8 Jul 2023 14:47:42 +0900

주기가 샘플링 주기의 배수일 경우 이전 방법이 됨.

그렇지 않다면 샘플링 기간의 절반까지 부정확할 수 있음. 최악의 경우 dip에서 샘플링된 d'(r)의 값이 클수록, dip사이에서 선택하는 과정에 간섭할수 있고 gross error가 발생할 수 있음.

Parabolic interpolation으로 해결할 수 있음(포물선 보간?)

보간은 두 점을 연결하는 방법. 포물선 보간은 직선으로 두 점을 연결하는게 아니라 포물선 형식으로 두 점을 연결함. (선형 보간이라고 따로 있음)

d'(r)의 지역 최소값과 근처를 포물선으로 맞추고, interpolated(보간)된 최소값을 dip-selection 과정에 사용함.

선택된 최소값의 횡자표가 주기 추정치가 됨. 이렇게 얻은 추정치는 약간 편향되어있음. 이런 편향성을 피하기 위해서 raw difference function d(r)의 최소값이 대신 사용됨

보간을 사용하는것은 업샘플링하는거보다 저렴하고, d(t)가 dip 근처의 4차함수로 모델링될수 있다는 전제하에 정확함.

1. ACF는 파워 스펙트럼의 푸리어 변환이라 신호가 대역제한이 있으면 ACF도 있음

2. ACF는 코사인의 합으로 테일러 급수로 0에 가깝게 근사화 가능

3. 주기 피크는 제로 지연 피크(zero-lag peak)와 동일한 모양을 가지며 d(t)의 주기 딥과 모양이 같고, d'(r)과 유사함. 따라서 딥에 대한 포물선 보간은 강하고 높은 주파수가 나오지 않는 이상 정확함.

보간은 오류율에 그렇게 영향은 없었음. F0가 샘플링레이트에 비해 작았기 떄문. 합성자극을 테스트에서는 모든 F0에서 약간의 오류를 감소시키고 높은 F0에서 gross error를 방지하는 것으로 나타남.

YIN Algorithm : Step 4: Absolute threshold

강에 뜨는 달 — Wed, 5 Jul 2023 00:25:38 +0900

위 그림처럼 higher order dip이 period dip보다 긴 경우가 자주 발생한다.

검색 범위에 속하면 "octave error"라고 하는 subharmoic error가 됨. Autocorrelation method도 비슷하게 higher order peak를 선택하기 쉬움.

제안하는 방법은 절대 임계값을 설정하고, 그 임계값보다 최소 d만큼 더 적은 제일 작은 값 r을 선택하는거임.

선택된게 없으면 전역 최소값을 선택함.

만약 threshold가 0.1이면, 에러가 1.69->0.78로 줄어들음. too low errror가 줄고, too high error가 약간 늘음.

Threshold는 집합에 허용되는 후보들을 걸러주며, 주기적 신호가 견딜수 있는 비주기적 파워에 대한 비율로 볼 수 있음.

이 식을 window에 대해 평균을 내고 4로 나누면 이렇게 됨

우측의 두번쨰 항은 신호가 T 주기를 가지면 0이 됨. 따라서 그 주기의 다른 periodic component를 추가하던 빼던 안변함.

이것은 신호 파워의 비주기적 파워 컴포넌트로 볼 수 있음.

왜냐하면 주기 T의 컴포넌트를 더하거나 빼도 어차피 0이기 떄문(따라서 비주기적인 주기를 가진 신호에만 영향을 받음)

Step 3에서 썼던 공식

r=T일때, 분자인 d(r)은 비주기적인 값에 비례하고, 분모는 0-T사이 d(r)의 평균이므로, 대략적으로 signal power의 2배정도 되는 값이다.

분모가 d(r)의 평균인게 signal power의 2배가 되는건 이게 수학적인건지 아니면 측정이 그런건지?

따라서 d'(r)은 비주기적 신호 파워/전체 신호 파워 라고 볼 수 있다.

T는 이 threshold가 기준 이하면 허용된다. 실제 threshold의 정확한 값이 그렇게 큰 영향은 없음.

YIN Algorithm Step 3: Cumulative mean normalized difference function

강에 뜨는 달 — Tue, 4 Jul 2023 22:51:28 +0900

Zero lag에서 Difference Function은 0이지만, 주기성가 불완전할때가 있기에 주기에서는 0이 아닌 경우가 많다.

low limit를 선택하지 않으면 Zero lag dip을 선택하기 떄문에 방법은 실패한다.

lower limit 설정하더라도 첫번쨰 포먼트에서 강한 공명(resonance) 발생하면, 일련의 이차딥이 발생할 수 있으며, 그것들 중에 하나는 주기 딥보다 깊을수 있음. F1과 F0의 범위가 겹치지기에 lower limit을 거는거는 만족할만한 방법은 아님

포먼트가 무엇인가?
말할때 성대에서 발생하는 강한 공명 주파수를 의미함. 말할때 비강, 입, 목구멍을 지나면서 상호연결된 챔버와 튜브 역할을 함. 각 튜브에는 고유한 공진 주파수(resonant frequency)가 존재한다. F1, F2, F3 포먼트 등이 있고, 1이 제일 낮고 3이 제일 높다.

따라서 Pitch Detection에서 F0의 근본 주파수와 F1의 공진 주파수 범위가 겹치기에 lower limit을 설정하는것 만으로는 제대로 pitch detect를 할수 없다.

해답은 difference function을 cumulative mean normalized function으로 대체하는것! (CMNF로 줄여부르는듯) 한국어로 하면 누적평균 정규화 함수

r=0 이면 1,

이 함수는 이전 값의 더 짧은 지연 값에 대한 평균으로 나누어서 구함.

이 함수는 0이 아닌 1부터 시작하고, d(t)가 평균 이하로 떨어지는 경우에만 1 이하로 떨어짐.

이걸로 대체하면 too high error가 감소하여 1.95-> 1.69로 감소함.

두번쨰 장점은 search range의 주파수 상한을 없애 zero-lag dip을 피할 필요가 없어짐.

세번째 장점은 다음 스텝을 위해 정규화가 된다는 점.

YIN Algorithm: 2. Difference Function

강에 뜨는 달 — Sat, 24 Jun 2023 17:33:10 +0900

주기 T를 가진 신호 x를 가정하자.

이 신호에 대한 제곱을 구하여 평균을 내도 동일하게 0임

반대로 미분 함수를 통해서 주기를 알아낼수 있음. 당연하게 r이 0이면 주기임. 그리고 이 주기의 배수값만큼 값이 무한대 있음.

제곱합을 확장하여 ACF 형태로 표현할 수 있음(이해못함)

첫 두 항은 에너지 항. 두 항이 상수면 미분함수 d(r)은 r(r) 반대로 변하고, 둘중에 한쪽의 최대값을 구하면 반대쪽의 최소값을 구하는거랑 마찬가지임.

하지만 두번쨰 에너지 항도 r에 변해서, r(r)의 최대값과 d(r)의 최소값은 다를수 있음.

실제로 unbiased autocorrelation에서 오류율이 10퍼였게 difference function에서 1.95퍼로 낮아짐.

-- 생각 --
주기 = 1/f 이니까 pitch detection 알고리즘에서 주기를 구해서 pitch를 구한다. difference function에서 0인거를 구하면 주기가 나오니까, 거기서 음정을 구하는건가? 확인 필요

이렇게 확 변한게 놀라울수도 있는데, 식 1의 방법은 진폭 변화에 너무 예빈함. 시간이 지남에 따라 신호 진폭이증가하면 ACF 피크 진폭이 일정하게 유지되지 않고 lag와 함께 증가함. 이는 고차 피크를 선택하게 하고 "too low" error를 만듦.

too low, too high error가 정확히 무슨뜻인지는 모르겠음.. 고차 피크를 선택하는데 왜 too low?
다음 단계에서 이 에러들을 줄인다니까 일단 넘어감

식2가 진폭에 덜 예민한 함수를 만듦. 그러나 d(r) 사용하는 방식은 식 4의 신호 모델에 밀접하게 기반하고 있으며 "too low" 오류와 "too high" 에러를 잡기 위한 다음 두 오류 단계를 위한 기반을 마련함.

식2

식4

--생각--
식 4를 이용하는 방법이라, 이 후 나올 방법도 식 4를 사용하기 떄문에 기반이 된다는 의미인듯?

식2가 식1에 비해 진폭에 덜 예민한 이유는 무엇인가?

2로 계산하면 이렇기 때문.
lag가 커질수록 0에 근접해가는 이유는 큰 r일수록, 당연하게도 더 적은 term이 있기 때문(r이 크다는건 시간 지연이 많다 -> 찍히는 값이 적다

YIN Algorithm 1. autocorrelation method -2

강에 뜨는 달 — Tue, 20 Jun 2023 00:09:43 +0900

Tapered ACF envelope가 에러율에 미치는 영향을 평가하기 위해, W=r max인 식2의 결과를 시뮬레이션하기 위해 식1의 함수에서 음의 ramp을 곱하였음.

Ramp function은 0이하이면 0이고, 그 이상이면 t인 선형 기울기 함수를 의미함.

t ≥ 0의 경우 r(t) = t
t < 0인 경우 0

이런 느낌

https://en.wikipedia.org/wiki/Ramp_function

Ramp function - Wikipedia

From Wikipedia, the free encyclopedia Graph of the ramp function The ramp function is a unary real function, whose graph is shaped like a ramp. It can be expressed by numerous definitions, for example "0 for negative inputs, output equals input for non-neg

en.wikipedia.org

Negative ramp는 ramp function의 반대로 시간이 지날수록 선형적으로 감소!

r max 를 사용하면 중간값에 대한 전체 에러를 최소화하면서 하나의 오차를 희생해서 하나의 에러에 편항되게 만들수 있음. 식2를 사용하면 W 크기를 조절해 더 자연스러운 편향을 만들수 있음. Why? 식 2에서 W크기는 r 값과 반비례하기 때문.

만약 W 크기 조절하는게 의미가 크다면, 식2를 써서 암묵적으로 조절하는것보다, 명시적으로 적용하는게 좋음. 이게 식1을 쓰는 이유.

Autocorrelation은 shift된 신호와 비교하며, 그러한 맥락에서 AMDF 방법과 연관이 있고, 각 이벤트간의 간겨글 측정하는 time-domain method와도 연관이 있음.

ACF는 Power Spectrum의 푸리에 변환이며, 스펙트럼 내부의 하모닉스간의 주기적인 간격을 특정하는거임.

Cepstrum method는 power spectrum을 긴 진폭 스펙트롬으로 대체하며, 스펙트럼의 고진폭 부분에 가중치를 덜 둔다. 비슷하게 Spectral whitening effect는

- Linear predictive inverse filtering

center-clipiping

필터를 여러번 거친 신호를 나누고, 각 채널 내에서 ACF를 산하고 정규화한다음 결과를 더하는 방법.

등이 있음.

현재 Autocorrelation 기반 방법들은 제일 유명한 방법들임.

성능 향상을 위한 많은 노력들이 있었음에도, 이 방법은 오류가 너무 많음.

그래서 에러를 줄이기 위한 여러 스텝들을 고안함.

그래서 다음 스텝부터는 Autocorrlation method를 기반으로 에러를 줄이기 위한 방법들을 소개한다.

YIN Algorithm 1. autocorrelation method

강에 뜨는 달 — Tue, 13 Jun 2023 00:11:17 +0900

잘 아는 분야가 아니라 이해도도 떨어지는데 영어 논문이라 눈에 바로 들어오지도 않아 천천히 정리하고 논문에서 모르거나 많이 설명하지 않고 넘어가는 부분은 추가로 적어가며 정리해보려고 한다.

개론

기존의 유명한 pitch detection인 Classic Autocorrelation 방법을 제시하고, 이것의 오류를 분석한 다음 이것의 오류점들을 개선한 것이 YIN 알고리즘.

YIN이란게 동양의 음과 양, autocorrelation과 cancellation간의 상호작용에서 착안했다.

1. Autocorrelation

Discret signal의 ACF는 이렇게 표현된다.

근데 신호처리에서는 이 식을 많이 씀. r이 커질수록 window 크기가 줄고, 함수의 envelop이 준다.

envelop은 이것!

두 식은 t+1 - t+W 사이에 있으면 동일하지만, 그렇지 않으면 다름. 이 논문에서는 다른말 없으면 대체로 첫번쨰 식 씀.

주기적 신호의 응답으로, ACF는 주기의 배수에서 peak가 뜸. Autocorrelation method는 lag 범위 내에서 가장 높은 zero-lag 피크를 고르는 방법임.

[추가 공부]

신호의 autocorrelation을 구할떄, 원 신호와, delayed, or shifted된 신호와 비교한다. lag는 기존 신호와 비교하기 전에 signal이 얼마나 이동(shifted)했는지를 의미한다.

lower limit이 너무 작으면 zero-lag peak를 고를 가능성이 높아지고, higher limit이 너무 높으면 higher order peak를 고를 가능성이 높아짐.

[추가공부]

higher order peak는 더 긴 delay, shift 에 존재하는 피크를 의미한다. 대체로는 zero-lag peak가 제일 높지만, 때떄로 더 높은 lag에서 추가적인 peak가 존재할수 있음. 따라서 lag를 너무 길게 잡으면 이런 higher order peak를 골라버리는 위험이?!

TIL 2023-02-14 Reverb Algorithm

강에 뜨는 달 — Tue, 14 Feb 2023 23:20:08 +0900

https://valhalladsp.com/category/learn/plugin-design-learn/

Plugin Design Archives - Valhalla DSP

Creative tools for audio workers. Pro plugins for musicians, producers and engineers.

valhalladsp.com

리버브 알고리즘을 어떻게 짜는지 하나도 모르는 상황에서 찾아보니

가성비 플러그인으로 유명한 발할라 DSP에서 관련된 내용들과 추천 논문들이 있는데 이거 천천히 읽어보자

TIL 2023-02-12 Chrome Extension TabCapture 관련 삽질

강에 뜨는 달 — Sun, 12 Feb 2023 23:49:35 +0900

V3 Manifest기준으로는 Chrome tab catpure가 background 페이지에서 작동하지 않는 변경점이 있었다.

Background가 Service worker로 변했는데, 이로 변경하면서 Service worker에서는 DOM으로의 접근을 막아 보안성을 높이려 한거 같다.

그러나 이런 변경점 떄문에 기존에 크롬의 탭에 대한 내용을 가져올 수 있던 chrome.tabCapture API가 백그라운드에서는 작동하지 않게 되었고, 이에 따라 다른 방법을 찾을 수 있었다.

1. inactive인 탭을 만들어 거기서 capture하자

뒷단이 아닌 앞단에서의 tabCapture는 막히지 않았기 때문에, tabCapture을 생성할 임의의 탭을 생성해서, 여기서 tabCapture 이벤트에 관한 내용을 처리하는 것이다.

이렇게 하면 작동은 한다. 문제는 inactive한 tab 하나가 띡 나와버리는 것이다. UI적으로 굉장히 이쁘지 않다.

이에 대한 예제로

https://github.com/zhw2590582/chrome-audio-capture

GitHub - zhw2590582/chrome-audio-capture: Chrome Audio Capture

Chrome Audio Capture. Contribute to zhw2590582/chrome-audio-capture development by creating an account on GitHub.

github.com

해당 레포가 있어 테스트를 해보았는데 크롬 익스텐션에서 저런게 뜨면 썩 달가운 사람은 없을거 같았다.

그래서 포기

2. content.js에 tabCapture 관한 내용을 물려받게 하자.

content 자체는 chrome의 몇몇 API를 제외한 나머지 API들은 모두 막혀있다.

따라서 popup 등에서 tabCapture를 한 뒤, 이에 대한 media stream 내용을 content에 넘겨줘서 사이트에 주입시켜주는 것이다.

일단 이것은 내가 하려는 것과는 맞지 않는다. 왜냐하면 이런 방식을 통한다면 특정 액션 주입을 할떄 무조건 팝업을 거쳐야하기 떄문이다.

또한 한가지 문제점이 더 있었는데, capture을 할떄, 항상 유저에게 권한을 물어본다는 것이다. 이것도 UI적으로 맞지 않다.

--auto-select-desktop-capture-source

크롬에 CLI상으로 이렇게 넣어주면 되는데, 익스텐션을 편하려고 쓰는거지 누가 CLI 까지 넣어가며 익스텐션을 쓰나...(어차피 구성하려는 것과 차이도 있지만)

결국 이 문제는 V3 Manifest로 변환할떄 Service Worker로 바꾸면서, 기존 V2 기능들을 커버하지 못하게 짠게 문제인 것이다...

이에 대해서 V3에서는 offscreen이라는 chrome API가 새로 나왔다.

헤드리스 브라우저처럼 아예 안보이는 브라우저 탭 비스무리하는 것을 생성해주는 기능이다.

https://developer.chrome.com/docs/extensions/reference/offscreen/

chrome.offscreen - Chrome Developers

Build the next generation of web experiences.

developer.chrome.com

문제는 얘도 content처럼 Chrome API에 대해서 굉장히 제한적인 접근 권한이 있어 똑같이 tabCapture에 대해 접근할 수 없다는 것...

나와 같은 상황인 사람들이 생각보다 많은거 같았다.

https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Ekw1nYHyiO8

Offscreen documents API should allow access to chrome.tabCapture API

Juraj M. 읽지 않음, 2022. 9. 3. 오전 2:51:1022. 9. 3.  작성자에게 답장하려면 로그인하세요. 전달하려면 로그인하세요. 이 그룹의 메시지를 삭제할 권한이 없습니다. 메시지를 악용사례로 신고하려

groups.google.com

https://bugs.chromium.org/p/chromium/issues/detail?id=1214847

1214847 - chromium - An open-source project to help move the web forward. - Monorail

bugs.chromium.org

괜히 MV2에서 MV3로 2023년 1월에 다 넘겨버리고 MV2 지원 중단한다고 해놓고 무기한 연기를 한게 아닌거 같다.

근데 그렇다고 지금 MV2로 개발하는것도 에바고....

그럼 2안으로 어떻게 할거냐면

페이지를 만드는 것으로 변경함

1차적으로 지원가능한 기능으로는

플러그인 형식으로 쌓을수 있는 형식이 있음

+ 오디오를 Input으로 넣을수 있음.

이정도로 해보자.

지원할 기능 첫번쨰는

Volume

Compressor

인거 같은데 사실 구현자체는 Web API에서 다 구현해놔서 디자인을 좀 이쁘게 해볼까....

그리고 신스도 만들어보고 싶은데 한번 있는지 확인해봐야겠따.

그리고 블로그 만들어야하는데 Jekyll 테마 따봉 박아놓은거 내일 포크해서 만들자