1-6. 피크엔드 법칙 ** 인간은 경험 전체의 평균이나 합계가 아니라, 절정의 순간과 마지막 순간에 느낀 감정을 바탕으로 경험을 판단하는 경향이 있다. 사람은 절정(peak), 마지막(end) 순간의 감정을 바탕으로 경험을 판단한다. 게다가 긍정적인 순간보다 부정적인 순간을 더 생생하게 기억한다. 따라서 사용자에게 가장 도움을 주는 순간(중요하게 여겨지는 순간)을 파악하고, pain point를 줄이는 것이 중요하다.

이것을 파악하기 위해 사용자 여정 지도를 만드는데, 이는 사용자가 임무나 목표를 성취하는 과정을 서술함으로써 사용자가 제품 혹은 서비스를 사용하는 방법을 시각화할 때 매우 유용하다. 그리고 pain point를 감소시키는 방법으로 에러 페이지를 따로 만들어둘 것을 제안한다.

=> 법칙의 내용에 대해서는 깊이 공감한다. 특히 부정적인 감정이 긍정적인 감정보다 감정가가 크기 때문에 이를 경감시키는 게 중요하다는 것이 인상 깊었다. 개발자로서 다양한 에러를 만날 수 있다. 책에서 예시로 들었던 것처럼 404 에러는 대표적인 프론트엔드 쪽 오류이다. 추가로 생각해보았을 때는 에러 페이지를 만들지 않더라도 에러가 발생했을 경우, 에러의 원인과 어떻게 하면 이 에러를 해결할 수 있는지 구체적으로 알려주면 좋을 것 같다고 생각했다. 그래서 사용자가 빨리 원래 서비스 혹은 제품으로 복귀하고, 원하던 행동을 할 수 있도록 고민해봐야겠다.

1-7. 심미적 사용성 효과 사용자는 보기 좋은 디자인을 사용성이 더 뛰어난 디자인으로 인식한다. => '보기 좋은 떡이 먹기도 좋다.'라는 속담이 생각나는 파트였다. 다만 '보기 좋은 디자인'이라는 정의가 애매하다는 생각이 들었다. 개인적으로 이해한 바로는 정렬과 배치가 고르게 되어 있는 디자인을 보기 좋은 디자인이라고 정의하는 것 같았는데, 이또한 사용성이 뛰어난 디자인이 아닌가 싶었다.

1-8. 폰 레스토프 효과 비슷한 사물이 여러 개 있으면 그중에서 가장 차이가 나는 한 가지만 기억할 가능성이 크다. 예를 들어서 그냥 줄글로 되어 있는 warning popup이 아니라, 경고 아이콘과 '삭제'라는 부분에는 붉은색으로 표시하는 것을 뜻한다. 이렇게 하면 사용자는 이 아이콘을 주목하고 대화상자에 담긴 콘텐츠가 중요하다는 것을 깨닫는다. 또 한 가지 예시로는 드롭박스에서 회사의 메인 구독 모델을 가운데에 배치하고, 그 모델만 다른 레이아웃을 적용하는 것이다.

다만 이것을 적용하기 전에 저시력자나 움직임에 민감한 사용자에게는 어떤 영향을 미칠지 사전에 고민해보아야 한다. => 아주 효과적이고 본능적으로 사용하는 방법이라고 생각한다. 이 효과를 확실히 누리려면 다양한 파트의 사람들이 협력해야 할 것 같다. 기획면에서 어떤 것이 우리 회사의 메인 서비스일지 고민하고, 디자인면에서는 해당 서비스를 어떻게 강조할 것인지 고민해야 한다. 개발자로서는 이렇게 협의된 내용을 어떻게 하면 웹 표준, 웹 접근성을 지키며 구현할 수 있을지 고민할 수 있다.

1-9. 테슬러의 법칙 복잡성 보존의 법칙이라고도 알려진 테슬러의 법칙에 따르면, 모든 시스템에는 더 줄일 수 없는 일정 수준의 복잡성이 존재한다. 최소한의 복잡성이 존재하기 때문에 결국 사용자 혹은 시스템이 이 복잡성을 감당해야 한다. 다만 추상적으로 느껴질 정도로 인터페이스를 단순화해선 안 된다.

예시로 나오는 게 gmail이다. 메일 서비스를 이용하려면 필연적으로 수, 발신인이 필요하다. gmail은 이 복잡성을 해결하기 위해 보낸 사람은 자동으로 채우고, 받는사람은 기존 이메일을 기반으로 상대를 추천한다. 최근에는 ai를 접목하여 이메일 작성의 부담을 덜어준다. 또 다른 예시로는 애플 페이가 있다. 애플 페이에서는 이전 구매 내역을 불러올 수 있어서 사용자는 주소 등을 작성할 필요가 없어진다. => 이 부분도 개발자로 고민할 여지가 충분히 있을 것 같다. 예를 들어 사용자의 정보를 미리 채워두는 것이라면, 상태는 어떻게 관리하면 좋을지 고민해볼 수 있다. 페이지 이동이 일어나는 경우 이 상태를 어디서부터 물고 올지, 아니면 전역적으로 관리할 지, 만약 여러 개의 컴포넌트라면 props로 값을 관리할 수 있는지 등등 말이다.

1-10. 도허티 임계 ** 컴퓨터와 사용자가 서로를 기다리지 않아도 되는 속도(0.4초 이하)로 인터렉션하면 생산성은 급격히 높아진다. 웹의 페이지 용량 평균은 기하급수적으로 증가해왔다. 2019년 PC 페이지 평균 용량은 2MB에 달하며, 모바일 페이지 용량도 1.7MB로 그리 가볍지 않다. 2010~2011년 PC 평균 페이지 용량이 609KB, 모바일 페이지 용량이 262KB였음을 감안하면 약 3배 정도 증가했다.

그만큼 웹은 무거워졌고 사용자의 대기 시간은 길어지게 되었다. 반면 사용자의 인내심은 훨씬 줄어 인터렉션을 하지 않을 경우 최대 0.4밖에 기다리지 못 한다. 해결책은 1. 성능 최적화를 통해 웹을 최대한 가볍게 만들고 2. 사용자에게 더 빨리 인터렉션을 제공해서 전체 페이지가 로딩될 때까지 기다리지 않도록 하는 것이다.

예시로는 스켈레톤 UI, 블러 업, 프로그레스 바 제공, 낙관적 UI 제공 등이 있다. => 웹 서비스를 만드는 사람이자 이용하는 사람으로서 매우 공감하며 봤던 챕터이다. 업무를 할 때에도 이 부분을 고민해서 최적화를 할 수 있는 방법을 알아보았고, 사용자에게 더 빨리 인터렉션을 제공하기 위해 스켈레톤 UI를 도입했었다.

특히 블러 업 기법은 Progressive JPG를 활용할 수 있을 것 같다. 예전에 웹 성능 최적화 기법을 스터디하며 알게 된 것인데, 고품질 이미지를 한번에 전송하지 않고 전송하는 방식이다. 그 덕분에 브라우저에서는 초기에 저품질 이미지가 보이고 점차 원래 품질을 회복한다. 당시 테스트로 Progressive JPG를 만들어 보았는데(Link에서 만들었다.) 바로 Progressive JPG를 만들 수 있었던 기억이 있다! 무거운 이미지를 사용하는 사이트에서 해당 부분을 도입할 수 있을지 검토해보아야겠다.

2. 감상평 개인적으로 무척 유익했던 책이다. 학부 때 배웠던 내용이 새록새록 기억났다. 그리고 업무를 하면서 자연스럽게 사용했던 부분들이 그때 배웠던 것 덕분이라 생각하니, 어떻게든 배운 것은 써먹는구나 ^^; 싶었다. 여기서 배운 내용을 참고해서 실무를 할 때에 더 적극적으로 활용해봐야겠다!

0. 책을 읽게 된 이유?

나는 비전공 개발자로 심리학과 출신 프론트엔드 개발자다. 내 전공을 선택했을 때에도, 프론트엔드라는 직무를 선택했을 때에도 이유는 분명했다. 사람에 대해 더 알아보고 싶어서! 아무리 생각해보아도 이게 제일 중요한 이유였다.

제품을 만드는 개발자가 되면서 관심사는 사람이 아니라, 우리 서비스를 이용하는 사용자로 좁혀지게 되었다. 이제 내 목표는 사용자에게 어떻게 하면 더 편리하고 유려한 디자인을 제공하고, 우리 서비스에 락인시켜서 매출을 올릴 수 있을지였다.

조금이나마 이런 부분에 도움이 되고자 이 책을 읽어보게 되었다.

1. 내용 정리

1-1. 제이콥의 법칙 _사용자는 여러 사이트에서 대부분의 시간을 보낸다. 그래서 여러분의 사이트도 자신이 이미 알고 있는 다른 사이트들과 같은 방식으로 작동하길 원한다._

사용자의 멘탈 모델, 즉 특정 시스템의 작동 방식에 대해 알고 있다고 생각하는 바에 따라 움직인다. 사용자 멘탈 모델에 어긋나는 서비스를 제공했을 때, 사용자는 멘탈 모델 부조화를 일으키게 된다. 따라서 웹 서비스는 이런 멘탈 모델을 지키기 위해 현실 세계의 요소를 따오게 되었다. 예를 들면, 폼 컨트롤은 제어 패널을 본떠서 만들었다고 볼 수 있다.

다만 '사용자의 멘탈 모델'이라는 부분에서 '사용자'가 누구인지 애매할 수 있다. 이런 부분을 해결하기 위해 '페르소나'라는 가상의 사용자를 만든다. 비즈니스를 만드는 사람들은 이 페르소나를 통해 일반적인 멘탈 모델을 만들고자 한다.

=> 이 부분에 대해서 깊이 공감했다. 대부분의 사용자는 편의성을 위해 서비스를 이용하는데, 서비스를 파악하는 데에 너무 많은 에너지를 쏟게 만들면 사용자가 지레 지쳐 떨어져나가버릴 수도 있다. 즉, 심리학에서 말하는 스키마를 통해 멘탈 모델이 구성된다고 알고 있는데 이렇게 구성된 멘탈 모델에 주목할 필요가 있다. 프론트엔드 개발자로서 이 부분을 서비스에 녹여내기 위해서는 평소에 습관처럼 쓰던 부분들에 더 관심을 가져야겠다고 생각했다.

1-2. 피츠의 법칙 대상에 도달하는 시간은 대상까지의 거리와 대상 크기와 함수 관계에 있다.

즉, 사용자의 입력을 받는 부분은 충분히 크고 각각 적당한 너비를 가져야한다. 대표적인 터치 대상의 최소 권장 규격은 아래와 같다.

휴먼 인터페이스 가이드라인(애플) - 44x44pt 머티리얼 디자인 가이드라인(구글) - 48x48dp 웹 콘텐츠 접근성 가이드라인(WCAG) - 44x44 CSS px

또한 좌상단->우하단으로 이동하는 웹 사이트와는 달리, 화면이 작은 모바일의 경우 가로세로 중앙 부분에 가장 집중도가 올라가게 된다.

이 부분을 서비스에 적용한 사례는 아래와 같다.

1) 폼 입력에서 레이블을 클릭하더라도 입력폼을 작성할 수 있도록 함. 2) 폼 전송 버튼이 마지막 입력 폼과 가까운 위치에 있음.

=> 생각해보니 현업에서 개발할 때에도 자연스럽게 이 법칙을 지키고 있었다. 첫 직장을 다닐 때 UI/UX적으로 불편한 디자인이 있었고, 그 부분을 개선했던 경험이 있다. 지금 생각해보니 컴포넌트 간의 거리가 지나치게 좁았고, 이후 소개할 힉의 법칙을 준수하지 않아서 불편했다고 느꼈던 것 같다.

1-3. 힉의 법칙 의사결정에 걸리는 시간은 선택지의 개수와 복잡성에 비례해 늘어난다.

눈에 띄는 명확한 콜 투 액션의 부재, 불분명한 정보 아키텍처, 불필요한 단계, 과도한 선택지나 정보 등은 사용자의 행동을 방해할 수 있다. 간단히 말해 인지 부하가 오는 것이다.

책에서는 예시로 애플과 구글, 슬렉을 제시하고 있다. 인상 깊었던 건 구글과 슬렉 부분이었다. 구글은 검색이 먼저, 필터링은 검색 이후에 할 수 있도록 되어 있다. 슬렉은 다양한 기능이 있지만, 온보딩 슬라이드를 몇 가지 보여준 뒤 바로 사용자를 서비스에 투입시킨다. 단, 슬랙봇이라는 것을 만들어서 사용자가 필요할 때 필요한 정보만 제공하도록 한다.

=> 회사 메인 페이지를 만들 때 이 부분을 고려했었다. 오래된 서비스의 메인 페이지를 변경하는 건이라, 기존 사용자가 이미 익숙해진 UIUX를 변경해야 했기 때문이다. 다양한 의견이 나왔지만, 결론적으로는 메일링 서비스를 통해 변경된 내용을 알려주는 것으로 해결하였다. 실제로 변경 전후를 비교해보았을 때 사용자는 자신이 원하는 서비스를 제대로 찾아갔다. 아마 그 이유로는 사전에 메일링 서비스를 제공했고, 앞서 말했던 제이콥의 법칙을 잘 지켰기 때문이라 생각한다.

1-4. 밀러의 법칙 보통 사람은 작업 기억에 7(+-2)개의 항목밖에 저장하지 못한다.

여기서 말하는 '7개'라는 숫자는 단순하게 7개라는 뜻이 아니다. chunk 단위로 묶은 덩어리가 7개라는 뜻이다. 즉, 유사성이 높은 부분을 컴포넌트로 묶으면 사용자는 7개 이상을 기억할 수 있게 된다.

책에서는 뉴스 페이지, 나이키 홈 등을 예시로 들었다.

=> 이 부분 역시 자연스럽게 사용했다. 대부분의 프론트엔드 개발자들이 그럴 것 같은데, header와 aside, section 등을 나누다 보면 자연스럽게 chunk 단위로 묶이게 되기 때문이다.

1-5. 포스텔의 법칙 ** 자신이 행하는 일은 엄격하게, 남의 것을 받아들일 때에는 너그럽게.

여기까지 읽으면서 프론트엔드 개발자로서 가장 중요하다고 생각한 부분이다. 사용자의 입력은 너그럽게(포용력 있게, 다양하게) 받아들이면서 출력은 정확하게(사용자의 의도가 맞도록) 나오는 게 가장 중요하다고 생각하기 때문이다.

예를 들어서 폼의 필드를 작성할 때 이미 작성한 내용은 미리 채워져있는 게 사용성 면에서 우수하다. 그리고 다양한 디바이스에 대응할 수 있는 반응형도 이젠 필수가 되었다. 즉, 웹 표준과 웹 접근성을 지키며 개발해야 하는 것이다.

=> 실무를 하면서 이 부분을 지켰는지 고민해보게 되었다. 예시로 나온 폼의 필드 부분이나 반응형 구현은 해본 적 있다. 그리고 개인적으로는 무의미한 div 남발을 자제하고 상황에 맞는 태그 쓰기, br 태그 덜 쓰기 같은 것들은 해본 적 있다. 또 다국어 서비스를 제공했기에 여러 언어로 접근하더라도 동일한 서비스 경험을 할 수 있도록 고민해보았다. 하지만 tab index를 수기로 지정해주거나 저시력자들을 위해 깊이 고민해본 적은 없다. 새 프로젝트를 하게 된다면 이 부분을 더 고민해볼 수 있도록 해야겠다.

테오의 스프린트란 총 기간 5일, 개발 기간은 1~2일 정도로 짧은 스프린트를 하며 어떤 서비스를 론칭해보는 것이다. 말 그대로 극도로 짧은 기간 안에 mvp 버전을 배포하는 게 목적인 셈이다!

1. 참여하게 된 이유?

사실 테오의 스프린트를 알게 된 건 꽤 오래 전이었다. 그런데 그때는 막 상경해서 새 회사에 다니고 있던 상황... 도저히 스프린트를 할 짬이 안 날 것 같았다. 그러면서 언제든 기회가 오기만을 호시탐탐 노리고 있었는데, 마침 이번에 16기를 모집한다고 해서 잽싸게 등록을 완료했다!

리액트를 실무에서 사용해본 적이 없어서 리액트를 이용해서 프로덕트를 만들고 싶은 욕구가 컸다. 그리고 다른 개발자들과 네트워킹 하는 것도 기대가 되었다.

2. 거기서 무슨 일을 했지?

우선 1일 차!

이 날은 아이디어 스케치를 발표하고 선정하는 시간이었다! 내가 준비한 아이디어는 [인터뷰 온 더 블록]이라는 거였는데, 간단하게 요약하자면 면접 질문과 답을 기록하면 랜덤으로 질문을 띄워주는 서비스였다. 다른 것들과 차별점이 있다면, 면접에 대한 답이 버전 관리가 된다는 거였다. 취준인 상태에서 나한테 필요했던 서비스라 요 아이디어를 들고 갔는데, 아쉽게도 채택되지는 못 했다. 그래도 좋은 아이디어가 많아서 나도 슬쩍 다른 아이디어에 편승했다.

결국 내가 선택한 서비스는 장애 아동의 의사 소통을 원활하게 해주는 서비스였다. 심리학과에 재학하면서 병동에 실습 나갔을 때 장애 아동들을 많이 보았고, 확실히 그 애들이 다른 비장애 아동들보다 의사소통에 어려움을 겪는다는 것을 알게 되었다. 상호작용이 줄어들면서 장애가 심해지기도 했고, 심리적으로도 위축되는 것을 보면서 이런 부분을 개선할 수 있는 서비스가 있음 좋겠다 싶었는데... 꼭 그에 맞는 서비스라 이걸 론칭해보고 싶어졌다. 자세한 내용은 아래와 같다!

• 의사소통 카드 제작 도구
• 장애 아동 중 언어장애가 있는 아동들이 사용하는 언어 카드를 봤는데 일반 그림이라 좋아하는 캐릭터 얼굴을 넣어 의사소통 카드를 만들 수 있는 기능이 있으면 좋겠어요.
• 사람 그림에 자신, 가족, 좋아하는 캐릭터의 얼굴을 넣고, 행동을 표현하는 목소리를 녹음하는 기능으로 가족 등 가까운 사람의 목소리를 들려줄 수 있으면 좋겠어요.

그렇게 이 아이디어를 선택한 사람들끼리 팀이 되고, 서로 소개하는 시간을 가졌다. 우리 조는 프론트 4명, 디자이너 1명 이렇게 다섯 명이었다. 팀 캔버스에 우리 서비스의 타겟 유저를 구체화해나가며 막차 직전까지 회의를 했다.

그리고 둘째 날!

어제 러프하게 짰던 부분을 더 구체적으로 이야기 나눠보는 시간이었다. 이때까지는 여전히 아이데이션하는 날이랄까. 더 나은 방법을 찾기 위해 서로 의견을 많이 나누었다. ㅋㅋ 전날의 일을 교훈 삼아 이날은 집에서 스프린트에 참여했는데, 2시가 다 될 때까지 이야기를 나눴던 것 같다. 이 회고록을 작성하며 테오가 보낸 메일을 보고 있는데(테오는 스프린트가 끝날 때까지 메일을 보내주었다. 대단한 열정... 본받고 싶다...), 이런 말이 있었다.

"지도그리기 시간의 가치는 결과물이 아니라 맥락을 공유하는 이 과정에 있습니다."

둘째 날의 의미를 정확하게 요약한 문장인 것 같다!

세 번째 날!

그리고 세 번째 날. 이 날은 이때까지 이야기 나눴던 것들을 구현하기 위해 구체화하는 단계였다. 구체화하기 위해 모인 우리들...

이때는 효율적인 의사 결정을 위해서 ux 권위자와 pl을 선정했다. 사실 우리는 디자이너가 한 명 뿐이라 ux 권위자는 사실상 정해져있었다... 의외였던 건 내가 만장일치로 pl이 됐다는 거였다. 아마도 천성적으로 진행자...? 기질이 있는데 그것 때문에 pl로 뽑아주신 게 아닐까 싶다.

그래서 ux 권위자와 내가 최대한 아이디어를 구체화해보려고 노력했다. 이걸 하며 놀랐던 게 같은 이야기를 하고 있다고 생각했는데, 서로 스케치를 내보니 완전히 다른 이야기를 하고 있었던 경우도 있었다. 또 비슷한 기능을 생각했지만 구체화하는 방식에서 차이가 났다. 예를 들어서 리워드 페이지를 구성하는 데에는 모두가 동의했지만, 거기에 레벨 시스템을 넣을지 아니면 뱃지 같은 걸 부여하고 끝낼지 등을 이야기 하다 보니 하나의 협의점을 찾기 어려웠다.

그래서 생각보다 이걸 하는 시간이 길어졌고, 팀원들이 좀 지쳤던 거 같다. 유저 스토리를 기반으로 bdd를 짜보는데, 모두 졸려서 헤롱헤롱한 상태였다. 이렇게는 안 될 것 같아서 다음 날 일찍 모이기로 하고 우선 이날은 헤어졌다!

네 번째 날, 다섯 번째 날(개발 day)!

어제 못했던 bdd를 했다. 멀쩡한 정신으로 하니 어찌나 빨리 끝나던지. 이때 또 많이 배웠던 것 같다. 안 되는 게 있으면 미련하게 붙잡고 있는 것보다 조금 쉬고 난 뒤에 하는 게 훨씬 능률이 더 좋다는 것 말이다.

아무튼 그렇게 심기 일전을 하고 개발에 들어갔다. 여기서 중요한 것은 언제든 배포가 가능하도록 아주 작은 형태로 완성된 형태를 유지하면서 조금씩 업데이트를 하는 형태로 개발을 진행하는 거였다. 그림으로 따지자면 아래와 같은 형태이다.

나는 전체 스프린트 과정에서 이 부분이 가장 인상 깊었다. 사실 누구든 엉망인 코드, 미완성인 프로덕트를 보여주고 싶지 않을 것이다. 그래서 '조금만 더...'를 외치다 시간을 많이 잡아먹게 되는 것 같다.

하지만 비개발자 입장에서(혹은 같은 개발자라 하더라도) 아예 프로토타입이 없는 것보다는 아주 조그마한 기능을 가졌더라도 배포가 되어 확인이 가능한 상태의 무언가가 있는 게 훨씬 더 낫다. 뭐라도 해볼 수 있기 때문이다. 테오의 말을 빌자면 "데모를 운영을 할 때 바퀴를 보여주는 것보다는 스케이트 보드를 보여주는 것이 훨씬 더 임팩트가 클거라고 생각합니다." 인 것이다.

이때부터 pl로서 고민을 좀 했던 것 같다. 임팩트가 적고 개발 시간이 오래 걸리는 것들은 백로그로 넘기고, 메인 서비스가 무엇일지 정리해나갔다. 이때는 팀원들의 도움이 컸다. 개발하기 바빴을 텐데 각자 할 수 있는 것, 걸리는 시간, 진척도를 물어보았을 때 거의 즉시 대답해주었기 때문이다. 🥲👍 이런 조별 과제는 팀원들 운이 전부인데, 그 운은 타고난 것 같아서 다행이었다.

이 과정 중에 백로그로 넘어간 기능들도 꽤 생겼고, 미리 해둔 bdd가 꽤 많이 바뀌었다. 그래서 나중에는 bdd를 고칠 시간이 없어서 todo list로 관리를 했는데, 이 부분이 좀 아쉬운 부분이다. (그래서 회고할 때 bdd 이야기를 너무 많이 많이 했더니 팀원들이 나중엔 bdd밖에 생각 안 난다고 했었다...🤣🤣)

그래도 덕분에 무사히 론칭할 수 있었다!

3. 그래서 실제로는 어떤 서비스를 만들었지?

데모는 여기서 확인할 수 있다! 우선 홈페이지에 들어갈 때 캐릭터를 골라서 들어갈 수 있고, 해당 캐릭터는 메인 화면 진입 시 우측 네브바 최상단에서 확인이 가능하다. 우측 네브바에서 각 카드의 카테고리를 설정하거나 메인 화면에서 카테고리를 선택해서 들어가면, 카테고리 별 카드를 확인할 수 있다. 카드 클릭 시 모달로 카드 상세가 뜨게 되는데, 왼쪽 상단의 스피커 모양을 누르면 해당 카드의 이름을 읽어준다.

피드백을 받았을 때 실제 타겟인 아동이 기뻐했던 기억이 나서 뿌듯했다. 디자이너 분께서 혼을 갈아 만든 ui가 빛을 발하던 순간이었다. 스프링 모양을 구현하기 위해 고생했던 팀원들의 노고도 잊지 못할 것이다.

나는 서비스에서 git repo를 관리하고, 배포를 진행하고, 카드 화면과 tts를 구현하는 업무를 맡았었다.

4. 그래서 뭐가 남았어?

우선 좋은 사람들이 남은 것 같아서 뿌듯하다. 그리고 pl로 일을 하면서 어떻게 하면 오해 없이 내 말을 전달할 수 있을지, 업무는 어떤 식으로 나누면 좋을지 등을 알아갔던 것 같다. 원래 목적이었던 '리액트 프로젝트 오픈'도 성취했다.

다만 시간 관계상 백로그로 넘겼던 부분들이 있다. 다행히 현업에 계신 한분을 제외하고는 다들 이 프로젝트를 더 해보고 싶다고 해서 아래와 같은 부분을 추가로 진행하기로 했다!

• 카드 상세눌렀을때 소리가 바로 날 수 있도록 처리
• 녹음창
• 앨범 단어장 기준 분류
• 캔버스
• 반응형
• 백엔드를 통한 유저 생성
• 페이지 넘기는 애니메이션
• SOS기능
• 컨벤션 확정
• 리팩토링

마침 어제 스프린트 회의였는데, 위의 task를 우선 순위와 예상 시간에 따라 나누었다. 이걸 기반으로 올해 말까지 mvp 버전을 오픈하는 게 목표! 열심히 해봐야겠다.

ps. 스프린트 기간 동안 고생했던 부릉, 하또, 감자, 해피 너무 감사합니다! 앞으로도 열심히 해봐요! 그리고 테오와 모승, 블루, 체다! 덕분에 처음 하는 스프린트에서 많은 걸 얻어갑니다. 다른 분들도 이런 귀한 경험을 얻어 가셨음 좋겠어요 ^_^)b ps. 백엔드, 디자이너 구합니다.. ^^

=> 개인적으로 이번 포스팅에서 소개된 디자인 패턴이 프론트엔드 개발자에게는 중요하다고 생각한다. 일단 책을 기반으로 정리해두고 보충하면 좋을 것 같다! // TODO

8. MVC 패턴

• 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴
• 각각의 역할로 구분하여, 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있음
• 재사용성과 확장성이 용이하다는 장점이 있으나, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해진다는 단점이 있다.
• 모델
  • 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻함
  • 뷰에서 데이터를 생성하거나 수정하면, 컨트롤러를 통해 모델을 생성하거나 갱신함
• 뷰
  • 사용자 인터페이스 요소. 즉, 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻함
  • 모델이 가지고 있는 정보를 따로 저장하지 않아야 하며, 단순히 사각형 모양 등 화면에 표시하는 정보만 가지고 있어야 함
  • 변경이 일어나면 컨트롤러에 이를 전달
• 컨트롤러
  • 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할
  • 이벤트 등 메인 로직을 담당
  • 모델과 뷰의 생명주기도 관리하며, 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줌

9. MVP 패턴

• MVC에서 C가 프레젠터(presenter)로 교체된 것
• 뷰-프레젠터는 1:1 관계 => MVC 패턴보다 더 강한 결합을 지님
• // todo: 장단점 보충

10. MVVM 패턴

• MVC에서 C가 뷰모델(view model)로 교체된 것
  • 뷰모델? 뷰를 더 추상화한 계층
• 커맨드와 데이터 바인딩을 가지는 것이 특징
  • 커맨드? 여러 가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법
  • 데이터 바인딩? 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법. 뷰모델을 변경하면 뷰가 바뀜
• 뷰-뷰모델 사이의 양방향 데이터 바인딩을 지원
• UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다는 장점이 있다. // todo 단점 보충하기
• 대표적으로는 Vue.js가 해당 패턴을 사용함

4. 옵저버 패턴

• 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴

  • 주체? 객체의 상태 변화를 보고 있는 관찰자
  • 옵저버? 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체들

• 이벤트 기반 시스템에 사용하며 MVC(Model-View-Controller) 패턴에도 사용됨 // TODO: 이벤트 기반 시스템 찾아보기

• JS에서 옵저버 패턴은 프록시 객체를 통해 구현할 수도 있음

  • 프록시 객체? 어떠한 대상의 기본적인 동작(속성 접근, 할당, 순회, 열거, 함수 호출 등)의 작업을 가로챌 수 있는 객체

    • target(프록시할 대상)과 handler(target 동작을 가로채고 어떠한 동작을 할 것인가 설정된 함수)를 매개변수로 받음

  • 프록시 객체를 이용한 옵저버 패턴

     function createReactiveObject(target, callback) {
         const proxy = new Proxy(target, {
            set(obj, prop, value) {
                if(value !== obj[prop]) {
                    const prev = obj[prop]
                    obj[prop] = value
                    callback(`${prop}가 [${prev}] >> [${value}]로 변경되었습니다.`)
                }
                return true
            }
        })
        return proxy
     }
    
     const a = {
         "June" : "Developer"
     }
     const b = createReactiveObject(a, console.log)
     b.June = "Developer"
     b.June = "Front Developer"
     // June가 [Developer] >> [Front Developer] 로 변경되었습니다.
    

  • Vue.js 3.0의 옵저버 패턴

    • ref나 reactive로 정의하면 해당 값이 변경되었을 때 자동으로 DOM에 있는 값이 변경됨 // TODO: 구체적인 동작 원리 찾아보면 재밌을 듯

5. 프록시 패턴과 프록시 서버

• 프록시 패턴
  • 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
  • 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용함
• 프록시 서버
  • 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램
  • nginx 등을 통해 할 수 있음. 이렇게 했을 때 실제 포트를 숨길 수 있고 정적 자원을 gzip 압축하거나 메인 서버 앞단에서의 로깅을 할 수도 있음. 버퍼 오버플로우 취약점을 예방할 수도 있음. CloudFlare를 사용할 수도 있다고 함.
  • 버퍼 오버플로우: 버퍼는 보통 데이터가 저장되는 메모리 공간으로, 메모리 공간을 벗어나는 경우를 뜻함. 사용되지 않아야 할 영역에 데이터가 덮어씌워져 주소, 값을 바꾸는 공격이 발생하기도 함.
  • CORS와 프런트엔드의 프록시 서버
    • CORS(Cross-Origin Resource Sharing)는 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못 하게 하는 HTTP 헤더 기반 메커니즘
    • 프론트 서버가 백엔드 서버와 통신할 때 CORS 에러가 발생하기도 하는데, 프론트에서 프록시 서버를 만들기도 함 => 정확히 이런 이유로 nuxt에서 proxy를 사용해본 적 있음. nuxt.config.js에서 설정만 해주면 되는 거라 간편했던 기억이 있음!
    • 참고: 127.0.0.1은 루프백 IP로 본인 PC 서버의 IP임. 기본이니 안 쪽팔리려면 알아두자 ^_^;;

6. 이터레이터 패턴

• 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴

• 이터레이터라는 하나의 인터페이스로 순회가 가능

  const mp = new Map()
  mp.set('a', 1)
  mp.set('b', 2)
  mp.set('c', 3)
  const st = new Set()
  st.add(1)
  st.add(2)
  st.add(3)
  for(let a of mp) console.log(a)
  for(let b of st) console.log(b)
  
  // 아래와 같은 결과가 나옴
  ['a', 1]
  ['b', 2]
  ['c', 3]
  1,
  2,
  3
  

=> 이것도 하나의 패턴이었구나... js에서 자연스럽게 사용하고 있어서 몰랐다.

7. 노출모듈 패턴

• 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴

• 해당 패턴을 기반으로 만든 JS 모듈 방식으로는 CJS(commonJS) 모듈 방식이 있음

• 참고

  • public
    • 클래스에 정의된 함수에 접근 가능하며 자식 클래스와 외부 클래스에서 접근 가능한 범위
  • protected
    • 클래스에 정의된 함수에서 접근 가능하며 자식 클래스에서 접근 가능하지만 외부 클래스에서 접근 불가능한 범위
  • private
    • 클래스에 정의된 함수에서 접근 가능하며 자식 클래스와 외부 클래스에서 접근 불가능한 범위
  • 즉시 실행 함수
    • 함수를 정의하자마자 바로 호출하는 함수. 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용

  => 디자인 패턴을 공부하면서 느낀 건데, js에서는 나름대로 충실히 객체 지향을 하려고 노력하는 것 같다. 객체 지향의 대표 격인 java에 있는 기능을 구현하려고 노력한 흔적이 많이 보인다. 👀 (반박시 님의 말이 맞습니다...)

1. 디자인 패턴

• 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것을 의미

2 싱글톤 패턴(in javascript)

• 리터럴 {} 또는 new Object로 객체를 생성하게 되면 다른 어떤 객체와도 같지 않기 때문에 이 자체만으로 싱글톤 패턴을 구현할 수 있음

const obj = {
    a: 27
}
const obj2 = {
    a: 27
}
console.log(obj === obj2) // false

• 주로 데이터베이스 연결 모듈 등에 많이 쓰임

  • db connection에 관한 인스턴스 생성 비용을 아낄 수 있어서

• 장점

  • 사용하기가 쉽고 실용적

• 단점

  • TDD할 때 불리함(각 테스트마다 독립적인 인스턴스를 만들기 어려워서)
  • 모듈 간의 결합을 강하게 만들 수 있음
    • 의존성 주입
      • 위의 단점을 해결하기 위해 고안됨
      • 메인 모듈이 직접 다른 하위 모듈에 대한 의존성을 주기보다는 중간에 의존성 주입자가 이 부분을 가로채, 메인 모듈이 간접적으로 의존성을 주입하도록 하는 것
      • 모듈을 쉽게 교체할 수 있고 테스팅이나 마이그레이션 하기에 용이. 애플리케이션 의존성 방향이 일관되고, 애플리케이션을 쉽게 추론할 수 있으며, 모듈 간의 관계들이 조금 더 명확해짐
      • 단 모듈들이 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있음. 그로 인한 런타임 페널티가 생기기도 함

2. 팩토리 패턴(in javascript)

• 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴
• new Object()로 구현 가능

  const num = new Object(42)
  const str = new Object('abc')
  num.constructor.name // Number
  str.constructor.name // String

• 위 예시에서는 전달받은 값(42, 'abc')에 따라 다른 객체를 생성하며 인스턴스의 타입(Number, String) 등을 정의하고 있음

// make a class of coffee(latte, espresso)
class Latte {
    constructor() {
        this.name = "latte"
    }
}
class Espresso {
    constructor() {
        this.name = "espresso"
    }
}

// make a sub class => specific content
class LatteFactory {
    static createCoffee() {
        return new Latte()
    }
}
class EspressoFactory {
    static createCoffee() {
        return new Espresso()
    }
}

const factoryList = { LatteFactory, EspressoFactory }

// make a super class => build a frame
class CoffeeFactory {
    static createCoffee(type) { // static methods => It can be called without creating an object based on the class, and memory allocation for that method can only be made once.
        const factory = factoryList[type]
        return factory.createCoffee()
    }
}

const main = () => {
    // order latte
    const coffee = CoffeeFactory.createCoffee('LatteFactory')

    // call coffee name
    console.log(coffee.name) // latte
}
main()

3. 전략 패턴(in javascript)

• 객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 전략이라고 부르는 캡슐화한 알고리즘을 컨텍스트(개발자가 어떠한 작업을 완료하는 데 필요한 모든 관련 정보) 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
• 이를 활용한 라이브러리로는 passport가 있음

  const passport = require('passport')
  const LocalStrategy = require('passport-local').Strategy
  

passport.use(new LocalStrategy( function(username, password, done) { User.findOne({ username }, function(err, user) { if (err) return done(err) if (!user) return done(null, false, { message: 'Incorrect username.' }) if (!user.validPassword(password)) return done(null, false, { message: 'Incorrect password.' }) return done(null, user) }) } ))

=> // todo: 전반적으로 js에서 패턴을 어떻게 활용하는지 보충하면 좋을 거 같음

1. 프로그래밍 패러다임

• 정의: 프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론
• 

2. 선언형과 함수형 프로그래밍

• 선언형 프로그래밍이랑 '무엇을'에 집중하는 것. '프로그래밍은 함수로 이루어진 것이다.'라는 명제가 담겨 있는 패러다임이기도 함.

  const list = [1, 2, 3, 4, 5, 11, 12]
  const ret = list.reduce((max, num) => num > max ? num : max, 0)
  console.log(ret) // 12

• 함수형 프로그래밍이란 '순수 함수'들을 블록처럼 쌓아 로직을 구현하고 '고차 함수'를 통해 재사용성을 높인 프로그래밍
• 단순하고 유연한 언어이며, 함수가 일급 객체이기 때문에 함수형 프로그래밍 방식이 선호됨.
• 순수 함수? 출력이 입력에만 의존하는 것
• 고차 함수? 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것
  • 고차 함수를 쓰기 위해서는 해당 언어가 일급 객체라는 특징을 가져야 함
  • 일급 객체 특징
    • 변수나 메서드에 함수를 할당할 수 있음
    • 함수 안에 함수를 매개변수로 담을 수 있음
    • 함수가 함수를 반환할 수 있음
• 그 외에도 함수형 프로그래밍은 커링, 불변성 등의 특징을 가짐(// TODO 이 부분 추가로 조사해서 추가해두기)

3. 객체지향 프로그래밍

• 객체들의 집합으로 프로그램의 상호 작용을 표현
• 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식
• 설계에 많은 시간이 소요. 처리 속도가 다른 프로그래밍 패러다임에 비해 상대적으로 느림

  const ret = [1, 2, 3, 4, 5, 11, 12]
  class List {
    constructor(list) {
        this.list = list
        this.mx = list.reduce((max, num) => num > max ? num : max, 0)
    }
    getMax() {
        return this.mx
    }
  }
  const a = new List(ret)
  console.log(a.getMax()) // 12

• 객체지향 프로그래밍의 특징
  • 추상화
    • 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것
  • 캡슐화
    • 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것
  • 상속성
    • 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것
  • 다형성
    • 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것
      • 오버로딩: 같은 이름을 가진 메서드를 여러 개 두는 것. 정적 다형성
      • 오버라이딩: 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것. 동적 다형성
• 설계 원칙(SOLID)
  • 단일 책임 원칙
    • 모든 클래스는 각각 하나의 책임만 가져야 한다
  • 개방-폐쇄 원칙
    • 유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 함
  • 리스코프 치환 원칙
    • 프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함. 즉, 부모 객체에 자식 객체를 넣어도 시스템이 문제 없이 돌아가야 함
  • 인터페이스 분리 원칙
    • 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 함
  • 의존 역전 원칙 // TODO: 이 부분 설명이 어려운 것 같음. 찾아서 이해하기 쉬운 설명 추가해두기
    • 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향을 받지 않게 하는 원칙. 즉, 상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립해야 함

=> js는 객체지향 언어이나 함수형 프로그래밍을 하는 것으로 알고 있음. 각각의 특징과 장단점을 알고, 취할 수 있는 것을 우선적으로 챙기자!

4. 절차형 프로그래밍

• 로직이 수행되어야 할 연속적인 계산 과정으로 이루어져 있음
• 코드의 가독성이 좋으며 실행 속도가 빠름
• => '코드의 가독성'이라는 부분에서 조금 걸린다. 절차형 프로그래밍이라고 무조건 가독성이 좋은 것 같지는 않아서 ^_ㅠ 코딩 처음 시작했을 때에는 절차형 프로그래밍의 가독성이 훨씬 좋았는데, 지금은 함수형 프로그래밍이 훨씬 더 눈에 잘 들어오는 것 같다...*
• 모듈화하기 어렵고 유지 보수성이 떨어진다

  const ret = [1, 2, 3, 4, 5, 11, 12]
  let a = 0
  for (let i=0; i<ret.length; i++) {
    a = Math.max(ret[i], a)
  }
  console.log(a) // 12

1. 복잡도

1) 시간 복잡도

• 문제를 해결하는 데 걸리는 시간과 입력의 함수 관계(얼마나 오래 걸리느냐)
• 보통 빅오 표기법으로 나타냄
  • 빅오 표기법 : 입력 범위 n을 기준으로 해서 로직이 몇 번 반복되는지 나타내는 것
• 효율적인 코드로 개선하는 데 쓰이는 척도가 됨

2) 공간 복잡도

• 프로그램을 실행시켰을 때 필요로 하는 자원 공간의 양

3) 자료 구조에서의 시간 복잡도(평균)

2. 선형 자료 구조

• 요소가 일렬로 나열되어 있는 자료 구조

1) 연결 리스트

• 데이터를 감싼 노드를 포인터로 연결해서 공간적인 효율성을 극대화시킨 자료 구조
• 연결 리스트는 이전에 공부한 적이 있어서 포스팅도 해두었다!(Link)

2) (정적) 배열

• 같은 타입의 변수들로 이루어짐
• 크기가 정해져 있음
• 인접한 메모리 위치에 있는 데이터를 모아놓은 집합
• 중복을 허용하고 순서가 있음
• 랜덤 접근(직접 접근: 순차적인 데이터가 있을 때 임의의 인덱스에 해당하는 데이터에 접근할 수 있음 <-> 순차적 접근)이 가능

3) 벡터(동적 배열)

• 컴파일 시점에 개수를 모르면 벡터를 사용해야 함
• 중복 허용하고 순서가 있음
• 랜덤 접근이 가능
• JS의 배열은 벡터라고 생각하면 될까?(*찾아보기)

4) 스택

• LIFO 성질을 지닌 자료 구조
• 재귀적 함수나 알고리즘, 웹 브라우저 방문 기록 등에 쓰임

5) 큐

• FIFO 성질을 지닌 자료 구조
• CPU 작업을 기다리는 프로세스, 스레드 행렬 또는 네트워크 접속을 기다리는 행렬, 너비 우선 탐색, 캐시 등에 사용

3. 비선형 자료 구조(*이 부분 추가로 공부하기)

• 자료 순서나 관계가 복잡한 구조. 일반적으로는 트리나 그래프를 뜻함.

1) 그래프

• 정점(vertext)와 간선(edge)로 이루어진 자료 구조
• 어떠한 곳(정점)에서 어떠한 곳으로 무언가를 통해(간선) 간다.
• 가중치 : 간선과 정점 사이에 드는 비용
  • ex. 1번 노드와 2번 노드까지 가는 비용이 한 칸? 가중치도 한 칸

2) 트리

• 그래프의 하위 항목
• 부모, 자식 계층 구조를 가짐(같은 경로상에서 어떤 노드보다 위에 있으면 부모, 아래에 있으면 자식)
• 간선 수 = 노드 수 -1(E = V -1)
• 임의의 두 노드 사이의 경로는 유일무이하게 존재함(루트 노드가 있으니 당연함)
• 루트 노드, 내부 노드, 리프 노드로 이루어짐
• 루트 노드 : 가장 위에 있는 노드
• 리프 노드 : 자식 노드가 없는 노드(tree니까 leaf node는 최말단인 것)
• 깊이(레벨) : 각 노드마다 다름. 루트 노드부터 특정 노드까지 최단 거리로 갔을 때의 거리
• 높이 : 루트 노드부터 리프 노드까지 거리 중 가장 긴 거리
• 이진 트리 : 자식의 노드 수가 두 개 이하인 트리.
  • 정이진 트리, 완전 이진 트리, 변질 이진 트리, 포화 이진 트리, 균형 이진 트리 등이 있음
• 이진 탐색 트리(BST) : 오른쪽 하위 트리에는 '노드 값보다 큰 값'이, 왼쪽 하위 트리에는 '노드 값보다 작은 값'이 들어 있는 트리
• AVL 트리 : 두 자식 서브트리의 높이는 항상 최대 1만큼 차이(최악의 경우 선형 트리가 되는 것을 방지하는 것)
• 레드블랙트리 : '모든 리프 노드와 루트 노드는 블랙이고 어떤 노드가 레드이면 그 노드의 자식은 반드시 블랙이다' 등의 규칙을 기반으로 균형을 잡는 트리. 색상을 나타내는 추가 비트를 저장함
• => 트리의 종류가 상당히 많은데, 전부 세세하게 아는 것보다는 각 트리가 만들어진 이유를 아는 게 중요할 듯 하다. 결국은 전부 시간 복잡도를 줄이기 위해 만들어진 개념인 것 같음. 어떤 상황에 어떤 방식으로 대처하면 되는지 경험적으로 알아보기.

3) 힙

• 완전 이진 트리 기반의 자료 구조. 최소힙과 최대힙이 있음.
• 최소힙 : 루트 노드에 있는 키는 모든 자식에 있는 키 중에서 제일 커야함
• 최대힙 : 루트 노드에 있는 키는 모든 자식에 있는 키 중에서 제일 작아야 함
• => 여기서 만약 특정 요소가 들어왔다? 일단 완전 이진 트리니까 제일 왼쪽부터 채우고, 최소힙이냐 최대힙이냐에 따라 각 노드를 스왑함

4) 우선순위 큐(우선순위 대기열)

• 우선 순위가 높은 요소가 우선 순위가 낮은 요소보다 먼저 제공되는 자료 구조
• 힙을 기반으로 구현됨
• 브라우저의 이벤트 루프가 이렇게 되어 있었던 것 같음(*찾아보기)

5) 맵

• 특정 순서에 따라 키와 매핑된 값의 조합으로 형성된 자료 구조(항상 정렬을 보장하진 않음)
• 레드 블랙 트리 자료 구조를 기반으로 형성
• 해시 테이블을 구현할 때 사용
• => 특정 자료 구조를 기반으로 다른 자료 구조를 만드는 경우가 빈번하다. 각 자료 구조의 특징과 왜 다른 자료 구조가 만들어졌는지도 찾아보면 좋을 것 같다.

6) 셋

• 순서가 없고 희소한 값만 저장함(배열과 다른 점)

7) 해시 테이블

• 무한에 가까운 데이터들을 유한한 개수의 해시 값으로 매핑한 테이블
• unordered_map으로 구현함

=> 선형 자료 구조의 경우 많이 찾아봐서 이해가 조금 되는데, 비선형 자료 구조의 경우에는 아직 와닿지는 않는 것 같다. 각각의 자료 구조를 따로 포스팅하든지, 더 찾아 보든지 해서 이해도를 높여야겠다. (*참고)

개인적으로 진행했던 주니어 탤런트 쇼 1기를 회고해보려고 한다.

우선 주니어 탤런트 쇼란 주니어들이 모여 주니어들만이 할 수 있는 이야기를 나누었던 팟캐스트이다. 트위터 스페이스를 통해 보통 격주마다 진행했고 유튜브, 팟빵에서 들을 수 있다!

1. 왜 하게 되었는가

그럼 이건 왜 하게 되었는가? 회고에서도 간략히 말했지만, 만들어진 계기 자체는 사소했다.

개발씬에서 시니어들의 이야기를 들을 수 있는 창구는 열려있다. 하지만 상대적으로 주니어들에겐 발언을 할 수 있는 장소가 제한적이었다. 당장 주니어인 내가 목소리를 낼 수 있는 곳이 필요하다 생각했고, 그렇게 반쯤은 충동적으로 주니어 탤런트 쇼가 만들어지게 되었다.

1기 멤버로는 무림님, 휘님, 클로이님, 셀레스틴님이 찾아와주셨다. 사실 이 멤버 중 제대로 이야기를 나눠본 분은 안 계셨는데, 다들 너무 열정적이고 똑똑하신 분들이라 팟캐스트를 진행하는 내내 많은 인사이트를 얻었다.

2. 하필이면 팟캐스트?

많은 방식 중 팟캐스트라는 형식을 취한 건 지극히 내 취향이 반영된 결과이다. 개인적으로 지대넓얕이라는 팟캐스트를 굉장히 좋아하고, 오랫동안 들어왔다. 주탤쇼도 출퇴근 길에, 설겆이를 하며, 잠들기 전에 편안하게 들을 수 있길 원했고 팟캐스트라는 형식을 택하게 되었다.

3. 준비와 진행은 어떻게?

우린 첫 사전 모임에서 주제를 미리 정해두었는데 취업 → 온보딩 → 토이 프로젝트 → 퇴사 및 이직 이라는 순서로 진행하기로 했다. 이 흐름이 자연스럽다고 생각했기 때문인데, 개인적으로는 일종의 주니어의 라이프 사이클이라 생각한다. 😉

그리고 어떤 주기로, 언제 팟캐스트를 진행할 지 논의해보았다. 다들 의논해보니 격주마다, 토요일 혹은 일요일 저녁에 진행하는 게 좋아서 그렇게 주기와 날짜는 확정되었다.

또 처음엔 사전 녹음 후 팟캐스트로 편집할 예정이었는데, 트위터의 스페이스 기능을 이용하면 실시간 송출이 가능해서 이를 이용하기로 했다. 아무래도 입소문이 좀 나야 진행하는 맛도 있으니 나쁠 게 전혀 없었다.

팟캐스트를 준비하면서는 보통 사전 모임을 한 두 번 정도 가졌고, 팟캐스트 시작 전 1시간 정도 리허설을 했다. 그리고 팟캐스트가 끝나면 1시간 정도 피드백을 가지기도 했다.

진행은 보통 메인 진행자를 한 명으로 두고, 그 메인 진행자가 진행할 수 없는 경우 패널들이 보조하는 식으로 진행되었다. 게스트를 모시고 진행했던 회차도 있었는데, 이땐 최대한 게스트에게 발언권을 많이 드리려 노력했다.

그리고 처음에는 청취자 분들이 자유롭게 발언할 수 있도록 했지만, 진행상 어려운 부분이 있어서 청취자 분들의 발언권은 제한하게 되었다. 다만 언제든 의견을 말씀하실 수 있도록 푸슝이라는 익명 투고함을 열어 두어, 진행하는 중간중간 푸슝에 있는 이야기도 함께 공유하였다.

4. 얻어갔던 것

이 팟캐스트를 통해 내가 얻은 것은 아래와 같다.

1. 커뮤니케이션 스킬
2. 녹음 및 편집 스킬
3. 문서 작성 능력
4. 자신감

우선 커뮤니케이션 스킬은 필연적으로 늘 수밖에 없었던 것 같다. 게스트, 청취자는 물론이고 패널들하고 이야기할 때에도 커뮤니케이션 스킬이 사용되었기 때문이다. 서로 원하는 주제와 방향이 있었기에 생산적인 토론을 나누었던 적이 많은데, 그때 내 의견을 더 조리있게 전달하려면 최대한 '잘' 말할 수밖에 없었다. 게스트의 경우에도 게스트를 섭외할 때나 팟캐스트 진행 중 더 많은 이야기를 이끌어 낼 때 커뮤니케이션 스킬이 필요했다. 어떻게 질문을 던지느냐에 따라 게스트분이 할 수 있는 이야기가 갈렸기 때문이다.

녹음 및 편집 스킬도 당연히 늘었다. 이전까지 편집 프로그램을 써본 적이 단 한 번도 없었는데, 팟캐스트를 진행하며 단축키를 써서 작업할 정도가 되었다. 😄

문서 작성 능력은 회의 내용을 노션으로 정리하다 보니 늘게 되었다. 특히 게스트 분들에게 사전 질문지를 드렸었는데, 그때에도 노션으로 내용을 정리해서 공유드렸다. 패널들이야 회의를 하며 맥락을 이해하지만, 게스트 분은 그렇지 않으시니 최대한 문서 작성에 힘을 쏟아서 게스트께서 맥락을 이해하실 수 있도록 처리했다.

그리고 마지막은 바로 자신감이다. 개인적으로 남들 앞에 나서는 것을 좋아하지 않고, 발표라면 숨기 바빴던 내가 팟캐스트를 진행하면서 단독으로 코너를 이끌기도 했다. 지금 1기의 마지막 스페이스의 청취자 수를 볼 수 있는데, 300여 회가 재생되었다고 나온다. 🥹 기억상으로도 얼추 몇 십 분 정도가 들어오셨던 것 같은데, 장족의 발전이 아닐 수 없다.

5. 더 잘 할 수 있었던 것

그럼에도 아쉬움이 있었던 부분은 아래와 같다.

1. 커뮤니케이션 스킬
2. 더 다양한 분들을 모시지 못 했던 것
3. 적극적으로 홍보하지 못 했던 것

커뮤니케이션 스킬 같은 경우에는 항상 아쉬움이 남는 것 같다. 주로 더 적극적으로 의사소통하지 못 한 것에 대한 아쉬움인데, 이 부분을 보완해보아야겠다.

그리고 두 번째로는 더 다양한 분들을 모시지 못 했다는 점이다. '주니어'라는 이름을 달고 팟캐스트를 시작했지만, 어쩌다 보니 패널을 개발자들만 모시게 되었다. 결코 의도했던 것은 아니라 조금 아쉬웠다. 개인적으로는 '주니어' 기획자, '주니어' 디자이너, '주니어' 데브렐... 이런 분들을 패널이나 게스트로 모시면 더욱 좋았을 것 같다. (주니어 데브렐은 한 분 모신 적 있지만 그래도 더 많이 모시지 못 했던 게 아쉽다.)

마지막으로는 적극적으로 홍보하지 못 했던 것이다. 그러다보니 자연스럽게 주탤쇼를 알게 된 분들을 위주로만 모시게 되었는데, 더 많은 주니어 분들을 모시려면 주탤쇼도 더 적극적으로 홍보해야 하지 않았나 하는 아쉬움이 남는다.

6. 그래서...?

그래서 이렇게 회고 글을 쓰고 홍보도 남겨보기로 했다!

• 1기에서 함께 주탤쇼를 진행했던 분들의 회고록

  • https://teqoo.tistory.com/285
  • https://soohey.tistory.com/entry/%EC%A3%BC%EB%8B%88%EC%96%B4-%ED%83%A4%EB%9F%B0%ED%8A%B8-%EC%87%BC-1%EA%B8%B0-%ED%9A%8C%EA%B3%A0-%EB%B0%8F-2%EA%B8%B0-%EB%AA%A8%EC%A7%91

• 주탤쇼 공식 채널

  • 유튜브 : https://www.youtube.com/channel/UCgG584uIPDVhqMO9Vqkmudg
  • 팟빵 : https://www.podbbang.com/channels/1784478?ucode=L-PjwBhefB
  
  
  

위에 소개한 링크에서 회고글과 팟캐스트를 들을 수 있으며, 현재 주니어 탤런트 쇼 2기도 진행 중이다.

시간을 주말이 아닌 금요일로 변경해서 그런지 지난 차수보다는 관심이 적지만, 2기 멤버 분들과 함께 열심히 진행하고 있다. 많관부! 😄

p.s 다음 모임은 11.25(금) 저녁 10시인데, 주제가 토이 프로젝트입니다. 자신의 소개 프로젝트를 소개하고 싶은 분들이 있다면 ** juniortalentshowofficial@gmail.com**로 연락주시거나 이 게시물에 댓글 남겨주시면 꼭 회신드릴 수 있도록 하겠습니다.

1. 글또 시작 이유와 글또를 하며 얻은 것

이 부분은 시작 글에서도 밝혔듯 '기술 블로그를 운영'하고 동종 업계 분들과 '네트워킹'을 하고 싶어서 시작하게 되었다. 지금 와서 아쉬운 점은 조금 두루뭉술한 목표였지 않았나 싶다. 커다란 목표는 저렇게 잡아도 되겠지만, 각 목표를 정량적/정성적으로 측정할 수 있는 기준을 마련했다면 좀 더 글또 활동에 집중할 수 있었을 것 같다.

그럼에도 불구하고 글또를 하며 얻은 부분들이 있다. 글또를 시작하기 전까지만 해도 이 블로그의 성격은 지극히 개인적이었다. 말은 '기술 블로그'였으나, 기술에 대한 이야기보다는 개인적인 감상을 올리는 데 그쳤었다.

하지만 글또를 시작하고 나서는 기술과 관련된 글의 비중이 훨씬 올라가게 되었다. 처음엔 나도 잘 모르는 기술에 대해 글을 쓰는 게 옳은 일일까 고민스러웠는데, 오히려 그렇기 때문에 블로그에 글을 써야 하는 것 같다. 공개적인 블로그에 글을 쓰는 것이다 보니 이것저것 더 찾아보게 되고, 그러는 과정에서 알고 있다고 생각한 개념이 사실 그렇지 않단 걸 깨닫게 되는 경우도 있었다. 또 아직까진 그런 피드백을 받아본 적은 없지만, 혹시나 틀린 내용을 포스팅했을 때 그 부분을 짚어줄 분들이 계실 거라 생각한다.

그리고 글또를 진행하면서 내 글쓰기의 안 좋은 습관을 돌아보게 되었다. 글또는 작성한 글에 대해 다른 사람들의 피드백을 받게 되어 있는데, 이 과정에서 내 글에서 가독성을 해치는 부분을 덜어내게 되었다. 나같은 경우엔 취소선을 활용하는 거였는데, 내 의도와는 다르게 취소선이 맥락을 방해하고 진지해보이지 않는다는 피드백이 있었다. 글또의 피드백 타임이 아니었다면 영영 알아차리지 못 했을 단점이었다. 이 자리를 빌어 귀한 피드백을 남겨주신 분들께 감사드린다. 🙏

2. 어떤 글을 썼는가

그래서 어떤 글을 썼는가? 당초 목표는 아래와 같았다.

1) firebase, netlify 배포 방법

2) 알고리즘 스터디에서 내가 준비한 발표 자료(주로 자료 구조. 알고리즘을 소개할 가능성도 있음)

3) 현재 하고 있는 토이 프로젝트(가능하다면 개인, 팀플 모두)

4) 타입스크립트 공부한 내용 정리(타입스크립트 핸드북을 토대로)

5) 정처기 공부한 내용

6) 그 외 자바스크립트와 관련된 부분! 일단 생각해둔 내용은 이렇다.

6-1) lazy loading을 하며 IntersectionObserver을 사용했는데, 이 부분을 좀 정리해보고 싶다.

6-2) 선언형 프로그래밍과 명령형 프로그램에 대해서도 정리해보고 싶다.

여기서 작성한 글은 2, 6, 6-2밖에 없다.

우선 1의 경우에는 글감으로 적절하지 않다는 판단이 들어서 제외했다. 2번은 자료 구조 중 하나인 연결 리스트에 대해 포스팅 했었는데, 더 꾸준히 남기지 못 해 아쉬울 따름이다. 3번의 경우에는 현재 진행하고 있는 토이 프로젝트가 없어서 작성하지 못 했다. 대신 팟캐스트와 관련된 내용을 포스팅하려고 준비 중이다. 4번의 경우 아직 타입스크립트에 대한 이해가 부족하다고 생각해서 작성하지 못 했다. 그런데 이 글을 작성하며 생각해보니, 포스팅을 작성하면서 오히려 더 타입스크립트에 대해 이해할 수 있을 것 같다. 😓 조만간 시리즈로 작성해보아야겠다. 5번은 정처기가 우선 순위에서 밀리게 되면서 자연스럽게 작성하지 않게 되었다. 6번은 minify와 uglify에 대해 작성하였다. 또 넓게 보자면 싱글톤 패턴과 관련된 글도 포함할 수 있을 것 같다. 두 내용 다 자바스크립트에 국한된 내용은 아니라서 여유가 될 때 다른 언어로 된 것도 살펴보면 좋을 것 같다. 6-1은 IntersectionObserver 외의 방법도 포함하여 작성해볼 생각이다. 마지막으로 6-2의 경우에는 계획했던 것보다는 디테일하게 작성하였는데, 앞으로도 이렇게 작성할 생각이다.

그 외에 작성한 글의 리스트는 아래와 같다. [글또를 시작하며] [CSS 우선 순위] [CDN 훑어보기] [1년의 반을 넘기고 하는 회고] [베어메탈, 가상화 그리고 컨테이너 환경]

이렇게 쓰고 싶은 글을 미리 써두고, 몇 개월 뒤에 회고를 하며 점검해보니 느끼는 바가 많다. 내 관심사가 어디에서 어디로 옮겨가는지도 보이는 것 같아서 이 방법은 글또를 마치고 난 뒤에도 이어나가볼 생각이다.

3. 글또를 마치며

글또를 마치면서 아쉬웠던 부분도 있고, 스스로 만족하는 부분도 있는 것 같다. 그래도 분명한 건 무언가를 얻어가긴 했다는 거다. 부디 다른 분들도 그러셨으면! 😊

최근 디자인 패턴에 대해 호기심이 생겨 찾아보게 되었다. 우선 디자인 패턴이란 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 다른 말로 하자면, 프로그래머가 어플리케이션이나 시스템을 디자인 할 때 공통된 문제들을 해결하는 데 쓰이는 형식화 된, 가장 좋은 관행이다.

1. 싱글톤 패턴이란?

그럼 싱글톤 패턴이란 무엇일까? 싱글톤 패턴이란 생성자(인스턴스)가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고, 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다. 코드로 보는 게 더 이해하기가 수월할 것 같아서 아래의 코드를 준비해보았다.

2. 코드

2-1) 싱글톤 패턴이 아닌 경우

export default function notSingleton() {
// singleton이 아닌 코드
// Counter의 인스턴스를 여러 번 만들 수 있으므로!
    let count = 0

    class Counter {
        getInstance() {
            return this
        }

        getCount() {
            return count
        }

        increment() {
            return count++
        }

        decrement() {
            return count--
        }
    }

    const counter1 = new Counter()
    const counter2 = new Counter()


// 즉, counter1과 counter2는 각각 별개의 인스턴스를 가리킨다.
// 각 인스턴스의 getInstance 메서드를 호출해 반환되는 레퍼런스를 다르다.
    console.log(counter1.getInstance() === counter2.getInstance()) // false
}

주석으로도 표현해두었지만, 위의 코드는 싱글톤 패턴이 아니다. 왜냐하면 new Counte를 통해 생성한 인스턴스를 비교해보면, 같지 않다고(false 값이) 나오기 때문이다.

싱글톤 패턴은 아래처럼 구현한다.

2-2) 싱글톤 패턴(클래스)

export default function singleton() {
    // notSignleton을 singleton으로 수정

    let instance
    let count = 0

    class Counter {
        constructor() {
            if(instance) {
                throw new Error('You ca only create one instance!')
            }
            instance = this
        }

        getInstance() {
            return this
        }

        getCount() {
            return count
        }

        increment() {
            return count++
        }

        decrement() {
            return count--
        }
    }

    // const counter1 = new Counter()
    // const counter2 = new Counter()
    // console.log(counter1.getInstance() === counter2.getInstance()) // Error occur

    // 인스턴스를 freeze해서 객체를 사용하는 쪽에서 직접 객체를 수정할 수 없도록 해준다.
    // 이 처리로 인해 프로퍼티 추가 및 수정이 불가하므로 Singletone 인스턴스의 프로퍼티를 덮어쓰는 실수를 예방할 수 있다.
    const singletonCounter = Object.freeze(new Counter()) // Counter {}
    console.log(singletonCounter)
}

위에서 보면 counter1과 counter2는 같은 인스턴스를 가리키고 있다.

추가적으로 Object.freeze 메서드를 통해, Count를 사용하는 곳에서 기존에 생성된 인스턴스를 수정할 수 없게 만들었다. 다른 값으로 덮어 쓰이지 않기 때문에 훨씬 안전하게 사용할 수 있다.

2-3) 싱글톤 패턴(객체 리터럴)

자바스크립트에서는 위의 방법처럼 클래스를 사용하지 않고도 싱글톤 패턴을 구현할 수 있다. 객체 리터럴을 이용하면 되는데, 코드는 아래와 같다.

export default function singletonObj() {
    // 다른 언어들과는 달리 js에서는 클래스 대신 객체 리터럴을 사용하여 싱글톤 패턴을 구현할 수도 있다.

    let count = 0;

    const counter = {
        increment() {
            return count++;
        },
        decrement() {
            return --count;
        }
    };

    Object.freeze(counter);
    console.log(counter.getInstance()) // { increment: [Function: increment], decrement: [Function: decrement] }
}

3. 장점과 단점

싱글톤 패턴의 장점으로는 메모리를 절약할 수 있다는 점이다. 인스턴스를 하나만 만들도록 강제하기 때문에 한정된 메모리를 사용할 수밖에 없는 것이다.

다만 단점으로는 최근의 자바스크립트 기조와 달리, 싱글톤 패턴은 일반적으로 앱의 전역 상태를 위해 사용된다는 것이다. 자바스크립트에서는 ES6부터 var 대신 let과 const를 도입하여, 최대한 전역 변수 사용을 지양하고 있다. 또한 export와 import 구문을 도입하여, 전역 객체를 수정하지 않고도 모듈 내에서 전역으로 사용할 수 있는 변수를 만들도록 하였다. 다양한 개념을 도입해서 전역 상태를 지양하도록 하는 것은 전역 상태를 사용하는 것이 자바스크립트의 안티 패턴으로 꼽히기 때문이다.

전역 상태를 무분별하게 사용하게 되면, 프로젝트의 규모가 커질수록 데이터의 흐름을 파악하기 어려워지기 때문이다. 즉, 프로젝트가 커지면 커질수록 전역 상태를 참조하는 컴포넌트가 많아지게 되고 서로 참조하게 되는데 이럴 경우 디버깅이 어려워지는 것이다. 자바스크립트 UI 라이브러리인 React의 경우 전역 상태 관리를 제공하지만, 읽기 전용 상태로 제공하여 부작용을 줄이려 애썼다.

4. 마치며

React뿐만 아니고 Vue에서도 Flux 패턴을 통해 데이터의 흐름을 관리하려 한다. 그만큼 전역 상태를 관리하는 것이 최근의 프로젝트를 다룰 때 중요한 부분임을 알 수 있었다.

5. 출처

1) 디자인 시스템이란

https://ko.wikipedia.org/wiki/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EB%94%94%EC%9E%90%EC%9D%B8_%ED%8C%A8%ED%84%B4

2) 싱글톤 패턴의 정의

https://ko.wikipedia.org/wiki/%EC%8B%B1%EA%B8%80%ED%84%B4_%ED%8C%A8%ED%84%B4

3) 코드 및 장단점

https://patterns-dev-kr.github.io/design-patterns/singleton-pattern/

난 평소에도 인프런을 자주 이용하는 편이고, 향로님과 호돌맨님의 유튜브도 챙겨보는 편이다. 그래서 인프콘에 대한 소식을 일찍 접할 수 있었다. 신청일을 캘린더에 표시해두고, 제발 당첨되기를 얼마나 바랐던지. 우여곡절이 있었지만, 어찌 되었건 인프콘을 다녀올 수 있게 되었다!

1. 입장

처음엔 코엑스가 너무 넓어서 좀 헤맸는데, 다행히 늦지 않게 도착했다. 모두에게 주는 선물인 티셔츠는 내 사이즈가 품절되어 조금 큰 것으로 수령했다. (오히려 좋아!) 패스권도 받고 드디어 입장!

그리고 어마어마한 사람의 행렬에 기선제압을 당했다... 이렇게 개발자가 많다니...? 이 많은 개발자들이 한 곳에 모였다니...? 너무 신기하고, 의욕이 샘솟았다. ㅋㅋㅋㅋ

인프콘에는 각 기업에서 테크 부스를 운영하고 있었는데, 커피챗을 할 수 있거나 인재풀에 등록하면 상품을 주는 등의 행사를 하고 있었다. 나도 몇 군데에서 상품을 수령하고, 바로 세션에 참여하러 이동했다.

2. 첫 번째 세션 - 만들면서 배우는 리액트:기초 / 진유림

나는 미리 핸즈온 세션을 신청해서 듣게 되었다. 리액트를 사용해본 적은 있지만, 실무에서 사용한 게 아니라 궁금했다. 무엇보다 연사인 진유림 님이 궁금해서 꼭 듣고 싶은 세션 중 하나였다.

기대했던 것처럼 진유림 님은 유쾌하고, 긍정적인 에너지를 갖고 계셨다. 어려운 개념을 최대한 쉽게 풀어서 설명해주시려 애쓰셨고, 전달력도 좋았다! '만약 내가 유림 님과 같은 연차일 때, 주니어 분께 저렇게 설명할 수 있을까?' 생각하니 자신 없었다. 그래서 이번 세션은 좋은 자극이 되었던 것 같다.

아쉬웠던 부분도 있었다. 이건 내 선택의 문제였는데, 정말 리액트 기초를 대상으로 한 세션이라 내게는 맞지 않았다. 또 중간중간 조교 분들을 배치해주신 건 좋았으나, 아무래도 실습 형태다 보니 모두가 코드를 따라가는 데 급급했던 것 같다. 유림 님이 작성한 코드를 보는 시간과 직접 코드를 작성해보는 시간이 나뉘어져 있었는데, 진행상 직접 코드를 작성하는 시간이 짧을 수밖에 없었다. 그러다 보니 많은 분들이 유림 님이 작성한 코드를 보는 시간에도 직접 코드를 작성하는 분위기였다.

개인적으로 이런 행사에는 실습하는 형태가 아니라, 연사님이 발표하는 것을 듣는 형태가 가장 무난하고 관리하기 편한 것 같다.

3. 잠시 쉬는 타임

핸즈온 세션이 길어서 이때 겹치는 세션은 포기할 수밖에 없었다. 다음에 예정된 세션까지는 시간이 좀 떠서, 이 시간 동안 화장실도 가고 굿즈도 수령하며 다녔다.

길지 않은 시간이기도 했고, 보다시피 사람들이 많아서 굿즈를 수령하는 데에 시간이 오래 걸릴 수밖에 없었다. 인프콘에 대한 인기를 실감했고, 각 부스에서 회사를 대표해서 애써주시는 분들이 힘드실 것 같단 생각이 들었다. 또 이 많은 인원을 케어하며 별 탈 없이 행사를 진행하는 인프런 멤버들의 노고에 감사하게 되었다.

아, 그리고 룰렛도 돌렸는데 티셔츠랑 책을 받았다. 인프콘은 교보문고와 협업해서 도서를 제공하고 있었는데, 나는 Vue3와 관련된 책을 수령했다! (composition API 널 뽀개주겠어....)

4. 두 번째 세션 - 개발자의 셀프 브랜딩 / 김민준(벨로퍼트)

원래는 다른 세션을 이전에 들으려고 했는데, 너무 사람이 많아서 듣지 못 했다. 하릴없이 바로 이 세션을 듣게 되었다.

이 velog를 만드신 분이기도 한 벨로퍼트님의 세션이었다. 세션 시간이 짧은 게 아쉬울 정도로 세션이 너무 유익했다. 그리고 강의나 외부 활동이 많으신 분이라 그런지, 세션이 굉장히 매끄럽게 진행되었다.

최근 팟캐스트를 운영하고, 이직하며 고민이 되었던 부분 중 하나가 개발자로서 셀프 브랜딩을 하는 방법이었다. 이 세션에서 해결법을 얻어가진 못 해도 고민해볼 포인트를 찾은 것 같았다. 물고기를 잡아준 게 아니라, 물고기를 잡는 법을 알려주신 느낌이랄까.

5. 세 번째 세션 - 언어와 함께 성장하기 - Node.js와 10년, v0.8부터 v16까지 / 강동한

세 번째 세션은 강동한 님의 세션이었다. 연사님께서 말씀하신 것처럼 한국은 Node.js의 불모지나 마찬가지이다. 이 척박한 환경에서 Node.js와 함께 성장한 스토리가 감동적이었다. 사실 JS를 기반으로 한 프레임워크와 라이브러리를 사용하는 입장에서 JS의 런타임 환경인 Node.js에 대해 말씀해주셔서 집중이 될 수밖에 없었다. ㅎㅎ

특히나 프론트는 트렌드에 민감하고 변화가 빠른 편인데, 그런 흐름에 어떻게 적응하면 좋을지 생각해볼 수 있는 세션이었다.

6. 네 번째 세션 - Vanilla JS와 함께 지속가능한 프런트엔드 코드 만들기 / 이문기(준프)

마지막 세션이었다! 마지막 세션이니만큼 동시간대에 듣고 싶은 세션이 몰려있었다...... 거짓말 안 하고 전부 다 듣고 싶은 세션이었는데, 내 몸은 하나라서 너무 원통했다. 마음 같아서는 몸을 네 개로 쪼개고 싶었다...

결국 나머지는 추후에 동영상으로 보기로 하고, 가장 궁금했던 Vanilla JS와 관련된 세션을 보러갔다. 최근 Vanilla JS에 대응해야 하는 일이 있어서 인프런에서는 어떻게 처리했는지 궁금했기 때문이다.

다른 세션들에 비해 기술적인 이야기가 많이 나와, 솔직히 완벽하게 이해하기 힘들었다. 그래도 회사에서 주워들은 게 있어서 조금은 이해할 수 있었다. 특히 CQS는 최근 관심 있는 부분이기도 해서 더 집중하게 되었다. JS DOC이라는 유용한 툴도 알게 되어, TS를 바로 도입할 수 없는 부분에 도입해보면 좋겠다고 생각했다.

이 세션에서는 질문도 중요했던 것 같다. 마지막 세션 특성상 따로 질문 타임을 갖지 않고, 세션장에서 질문을 해야 했는데 그래서 다른 분들이 어떤 질문을 하는지 들을 수 있었다. 덕분에 다른 개발자들이 어떤 걸 고민하고 있는지, 해결 방법은 뭐가 좋을지 알게 되었다. 지금 당장 내겐 필요 없는 개념이고 고민일지라도 키워드를 들어둔다는 느낌으로 열심히 들어두었다. ㅎㅎ 개인적으로는 그래프큐엘을 사용해보지 못 했는데, 관련 질문이 DAO와 연관되어 나와서 그 부분을 조금 찾아보기도 했었다. 이렇게 예상하지도 못한 이득을 얻으며 인프콘의 모든 세션이 끝이 났다!

7. 마치며

맥북 프로 16인치와 기타 등등을 들고 돌아다니려니 너무너무 힘들었지만, 몸의 피로는 아무것도 아닐 정도로 많은 것을 얻었다! 이게 다 발표를 열심히 준비해주신 연사분들과 행사가 매끄럽게 진행되도록 애써주신 인프콘 멤버들 덕분이라 생각한다. 몇 만원을 줘도 아깝지 않은 행사인데, 공짜로 다녀오게 되어서 송구할 정도다. 그나마 고생하신 분들께 조금이라도 보탬이 되고자 이렇게 회고를 남기게 되었다. (내년에도 열렸으면... 그리고 내가 갈 수 있으면 좋겠다........)

다들 너무너무 고생 많으셨습니다!

ps. 글에 첨부한 이미지는 제가 직접 찍은 사진입니다. 외부로 가져가지 말아주세요. 또, 혹시나 사진에 본인이 나오는 게 신경쓰이시면 꼭 말씀 부탁드립니다. 바로 조치하겠습니다!

오늘은 베어메탈과 가상화, 그리고 컨테이너 환경에 대해 알아보려고 한다. 하나같이 생소한 단어들인데 아래에서 조금 더 알아보자.

1. 베어메탈

1-1. 정의 및 특징

베어메탈이란 간단하게 말하자면 가장 일반적인 환경이다. 즉, 하나의 OS 위에 바로 앱이 올라간 상태를 뜻한다. 베어메탈 환경에선 1개의 OS가 모든 하드웨어 자원을 관리하게 되는데, 그림으로 보자면 아래와 같다.

1-2. 장점

그럼 이 베어메탈 환경의 장점은 무엇일까? 가장 큰 장점은 속도가 빠르다는 점이다. 왜냐하면 실제 하드웨어에 OS를 직접 구동시키기 때문이다.

1-3. 단점

그렇다면 단점은 무엇일까? 베어메탈 환경의 특징에서 유추해볼 수 있듯 하나의 OS를 사용하는 게 문제가 된다. 즉, 여러 OS를 사용하려면 그에 맞는 하드웨어가 필요하다. 자연스럽게 자원(CPU나 메모리)간 격리가 불가능하고, 어플리케이션의 자동 확장 역시 어려워진다. 이러한 단점을 극복하기 위해 아래의 가상화 환경과 컨테이너 환경이 등장하게 되었다.

2. OS 가상화 환경

2-1. 정의 및 특징

가상화 환경이란 가상화 층을 구현하여 물리 머신으로부터 가상 환경을 분리하고, 가상 머신(VM)을 생성한다. 보통 가상화 층을 구현할 때는 Hypervisor라는 가상화 관리 툴을 사용한다. 이렇게 생성된 가상 머신은 물리적 머신과 동일한 역할 및 기능을 수행하지만, CPU와 메모리 같은 물리적 머신의 컴퓨팅 리소스를 사용한다. 그림으로 보자면 아래와 같다.

2-2. 장점

이런 가상화 환경의 장점은 자원을 격리해서 사용할 수 있다는 것이다. 즉, 위에서 언급한 베어메탈 환경의 단점을 어느정도 보완할 수 있다. 그리고 남는 컴퓨팅 리소스를 최대한 사용할 수 있어서 경제적이기도 하다.

2-3. 단점

다만 Hypervisor 및 게스트 OS의 부하 문제가 단점으로 꼽힌다. 그림을 보면 알 수 있듯 앱은 Hypervisor와 게스트 OS 위에서 돌아가게 되는데, 이 부분으로 인해 무겁고 느려진다. 또한, 기종이 다른 VM의 경우 기술간 호환성이 문제되기도 한다.

3. 컨테이너 환경

3-1. 정의 및 특징

그렇다면 컨테이너 환경은 어떨까? 우선 컨테이너 환경이란 커널을 공유하는 방법으로 호스트 OS 하나에서 여러 앱을 띄우는 것이다. 여기서 커널이란 운영체제의 핵심 기능부로, 컴퓨터 자원을 관리하는 역할을 한다. 사진으로 보자면 아래같은 구조이다. 우리는 shell과 같은 시스템프로그램을 이용해서 커널을 움직이게 하고, 컴퓨터로 하여금 사용자와 상호작용하도록 할 수 있다.

3-2. 장점

그럼 이 컨테이너 환경의 장점은 무엇일까? 우선 베어메탈 환경과 달리, 자원을 격리할 수 있을 것이다. 개인적으로 가장 큰 장점이라고 생각하는 것은 디펜던시, 환경 설정 등 개발할 수 있는 환경을 그대로 컨테이너 안에 넣을 수 있어서 어디서든, 누구든 동일한 환경에서 접근할 수 있다는 것이다. 말 그대로 컨테이너 상자에 자원을 차곡차곡 정리해두고, 언제든 또 누구든 그대로 사용할 수 있게 된다. 그 외에도 표준 컨테이너 기술로 호환성을 제공하고, 자동 확장 기능을 제공하기도 한다.

3-3. 단점

다만 단점으로는 베어메탈 환경보다는 느릴 수밖에 없다. 가상화 환경처럼 hypervisor나 게스트 OS를 거치진 않지만, 어쨌거나 호스트 OS 위에 도커 엔진을 띄워야 한다. 그래서 이론적으로는 베어메탈 > 컨테이너 > 가상화 환경 순서대로 속도가 빠를 수밖에 없다.

또 다른 문제는 물리 서버 한 대에 여러 대의 서버를 띄우는 방식이므로, 호스트 서버에 문제가 생기면 전 컨테이너에 영향을 미칠 수밖에 없다는 것이다.

4. 가상화 환경과 컨테이너 환경 비교하기

지금까지 베어메탈, 가상화, 컨테이너 환경에 대해 알아보았다. 개인적으로는 가상화 환경과 컨테이너 환경이 헷갈려서 좀 더 조사해보았는데, 간단히 설명하자면 이렇다.

위의 사진을 보면 알 수 있듯이, 왼쪽의 가상화 환경은 호스트 OS 위에 게스트 OS 전체를 가상화해서 사용한다는 것이다.

이와 달리 오른쪽의 컨테이너 환경은 OS 레벨은 공유하고, 앱 레벨에서 각각 격리해서 실행한다. 컨테이너 환경에선 원론적으로 하나의 OS만 구동할 수 있다는 뜻이다. 그래서 하나의 서버에 여러 개의 컨테이너를 실행해도 서로 독립적으로 실행할 수 있게 되는 것이다.

5. 느낀점

사실 프론트엔드 개발자로서 인프라 지식을 얼마나 알아야 하는 건지는 늘 고민했었다. 그리고 사실 지금도 그렇긴 하다.

하지만 실제로 업무(혹은 토이 프로젝트라도)에서 배포를 진행해보니, 인프라에 대해 얕게라도 알고 있어야겠단 생각이 들었다. 그래야 배포시 문제가 생기더라도 해결할 여지가 있고, 아는 만큼 유용하게 사용할 수 있기 때문이다.

그런 의미에서 나중엔 컨테이너 환경의 대표 주자인 도커(컴포즈)를 사용해보며, 거기에 대해 포스팅을 해볼 예정이다. 😃

1년의 반이 훌쩍 지났다. 글또를 시작한 지도 어느새 3달이 지나버렸다. 하루하루는 무척 긴 것처럼 느껴지는데, 시간이 이렇게 빨리 가버렸다니? 믿기 힘들 정도이다.

이렇게 빨리 시간을 흘려보내다 보니 챙겨야 할 사건이나 감정들도 떠내려가는 것 같아, 회고글을 작성하게 되었다.

1. 이직

회고를 작성하며 가장 먼저 이야기하고 싶었던 부분이다. 그만큼 이번 이직은 내 (개발자) 인생에서 중요한 부분을 차지한다. 왜냐하면 지방 토박이었던 내가 상경을 하게 된 계기이기 때문이다.

기존에 다니던 회사도 분명히 좋은 회사였다고 생각한다. 특히 내가 있던 지방에선 프론트엔드 프레임워크(혹은 라이브러리)를 사용하는 곳이 드물었는데, 다니던 회사는 뷰를 사용하고 있어서 분명 메리트가 있었다.

하지만 계속 공부를 진행하고, 다른 개발자 지인들을 만날 수록 성장에 대한 욕구는 계속 커졌다. 더 어려운 환경에 나를 던져보고 싶었고 적응하고 싶었다.

그러던 차에 회사에도 일이 생겨서 퇴사를 결심하게 되었다. 일과 이직 준비를 병행하는 건 힘든 일이었지만, 기존 회사에 잔존할 수 있는 상황이 아니라 필사적으로 준비했다.

이직을 결심한 뒤엔 처음부터 서울로 가기로 마음 먹었다. 익숙한 동네와 친구들, 사촌들, 가족들을 두고 상경하는 게 쉽진 않았다. 그래도 이번 기회가 아니면 다신 상경할 수 없을 것 같았고, 혹시 너무 힘들어서 1년 만에 내려오더라도 상경해보고 싶었다.

그리고 다행히 현재 회사에 합격하게 되었다! 기술 면접을 진행하면서 여기서 많이 배울 수 있을 것 같았고, 이후 핏 면접을 진행하며 내가 기여도 많이 할 수 있을 것 같았다.

그렇게 지금 이직한 회사에서 한 달 정도 근무를 마쳤다. 처음엔 고향 생각이 좀 나기도 했는데, 지금은 너무너무 잘 적응한 것 같다. 앞으로도 쭉 이대로 열심히 해나갈 생각이다. 😁

2. 팟캐스트

다음으로 회고에서 빠질 수 없는 게 팟캐스트이다. 난 <주니어 탤런트 쇼>라는 팟캐스트를 진행 중인데, 만들어진 계기는 사소했다. 그냥 어느 날, 주니어들이 진행하는 팟캐스트가 있으면 어떨까 글을 올렸고 거기에 사람들이 관심을 가져준 것이다. 플랫폼을 팟캐스트로 생각한 건 예전에 지대넓얕이라는 팟캐스트를 들었었는데, 이동하며 듣기 좋아서 그렇게 정했다.

그렇게 관심을 가져준 멤버들과 팟캐스트 준비를 진행하게 되었다. 진행 방향, 주제, 게스트, 운영 방법… 팟캐스트를 시작하기 전에도 논의해야 할 게 참 많았다. 그래도 이렇게 미리 이야기를 해둔 덕분에 팟캐스트가 시작한 후로는 삐걱거림이 덜 했던 것 같다.

개인적으로 주탤쇼는 애정이 많았던 활동이라, 더 자세한 회고는 나중에 따로 남길 예정이다!

그리고 2기 멤버를 구하고 있으니 관심 있으시면 언제든 저 혹은 공식 이메일(juniortalentshowofficial@gmail.com)로 연락주셔요.

3. 타입스크립트 스터디

그 다음으로는 타입스크립트 스터디이다. 사실 기존에도 하고 있던 게 있었는데, 스터디장의 개인 사유로 인해 정리가 되어 몹시 아쉽던 차였다. 그러다 동기들과 뜻이 맞아, 주에 이틀 정도 함께 스터디를 진행하게 되었다.

나도 타입스크립트에 익숙하지 않고, 동기들도 처음 접해본 터라 효율적으로 공부하고 있는지는 아직 잘 모르겠지만 🤔 그래도 성실히 해보려 한다.

4. 독서 모임

다음으로 진행했던 건 독서 모임이다! 지인분께서 진행하고 계신 모임인데, 마침 읽고 싶었던 책으로 모임을 진행한다고 하셔서 참여하게 되었다.

글또에서 추천받은 책으로 <함께 자라기 - 애자일로 가는 길>인데, 읽으면서 많은 인사이트를 얻을 수 있었다. 전공과 이어지는 부분이 많아서 개인적으로는 더 재미있었던 것 같기도 하다.

사실 이 회고를 쓰게 된 것도 이 책 덕분이다. 책에서는 학습을 하기 위해서는 의도적 수련이 중요한데, 의도적 수련을 하기 위한 방법 중 하나로 피드백을 언급한다. 특히 깊이 와닿았던 건 피드백의 시점에 대한 부분이다.

책에서는 인간의 경우도 피드백 주기가 길어지면 학습이 잘 안 된다(29p)고 말하고 있다. 피드백의 중요성에 대해서는 알고 있었지만, 주기에 대해서는 한번도 생각해본 적이 없어서 개인적으로 이 부분이 가장 유익했다.

물론, 그 외에도 생각해볼 거리를 많이 던져주는 책이라 주기적으로 들여다 볼 것 같다.

5. 알고리즘 스터디

이건 아쉽게도 관둔 활동이다. 꽤 오랫동안 알고리즘 스터디를 해왔는데, 위의 이런저런 활동을 하다 보니 우선 순위가 밀리게 되었다.

특히 이직한 회사에 빠르게 적응하고 싶은 맘이 컸다. 적응하기 위한 여러 방법이 있겠지만, 회사에서 사용하는 스킬을 배우는 것도 중요하다 생각했기에 양해를 구하고 스터디에서 나오게 되었다.

성공적으로 회사에 정착하게 되면 알고리즘 스터디는 재진행할 예정이다! 얼른 그날이 오기를... 😂

6. 글또

마지막은 대망의 글또이다. 원래도 뭔가를 끄적이는 것을 좋아한 터라, 글또에 지원하면서도 자신이 있었다.

하지만 성실하게 글을 쓰는 건 참 어려운 일인 것 같다. 이런저런 일이 생길 수도 있고, 좋은 글감을 찾기 힘들 수도 있고, 때로는 글을 쓰는 것보다 좋아하는 사람들과 시간을 보내고 싶을 때도 있기 때문이다.

그래도 다행인 건 초기에 다짐했던 대로 아직 패스를 한 번도 사용하지 않았다는 것이다. 커피챗도 한번은 진행하였다. 이런 부분은 다행이라 생각하고, 좀 더 성실히 임해보려 한다.

다만 처음 다짐했던 것보다는 의욕이 조금 떨어진 것 같다. 글을 작성하는 부분에서도 그렇고, 네트워킹을 하려는 욕구에서도 그렇다. 아마 에너지는 한정되어 있는데, 이것저것 하려다 보니 조금 지친 것 같다. 이건 사실 글또에 한정된 이야긴 아니라, 어떻게 하면 좋을지 꾸준히 고민해볼 예정이다.

7. 마치며

생각보다도 그간 이것저것 많이 한 것 같다. 그래서 몇몇 활동에선 퀄리티를 타협할 수밖에 없었던 것 같은데, 이 부분이 아쉽다.

용두사미가 되지 않도록 마무리 지을 것들은 잘 마무리 짓고, 주기적으로 피드백을 남겨서 지난 활동들을 되돌아 보아야겠다. 😄

프론트엔드 개발자로서 웹을 빠르게 로딩시키는 것은 중요한 일이다.

화면이 빠르게 로딩되지 않으면, 유저의 이탈이 일어나고 유저의 경험도(흔히 UX라고 부르는) 좋을 수 없다.

그래서 이번엔 웹을 빠르게 로딩하는 방법 중 하나로 minify와 uglify에 대해 조사해보았다.

1. minify란?

minify란 말 그대로 경량화 혹은 압축을 뜻한다.

여기서 말하는 경량화(압축)란 코드 내에서 사용하지 않는 변수명, 불필요한 줄바꿈이나 공백, 들여쓰기 등을 삭제하는 것을 뜻한다. 다른 방법으로는 줄여서 사용할 수 있는 긴 구문(ex. if문)을 축약해서 사용하는 것도 포함된다.

이렇게 파일을 지우거나 줄여씀으로써 최종적으로는 번들의 크기를 줄일 수 있다.

2. uglify란?

그럼 uglify란 무엇일까? 이또한 이름에서 유추해볼 수 있듯 난독화를 뜻한다.

난독화에서는 우리가 공들여 작성한 함수명이나 변수명을 알아보기 힘들게 작성하는 것에서부터 일부 루틴을 문자열로 바꿔 뒤섞는 것까지 다양한 단계가 있다.

간단하게 말하자면, 기존에 프로그래머가 사람이 알아보기 쉽게 작성한 코드를 오히려 읽기 힘들게 말하는 것을 뜻한다. 그래서 순수 난독화의 경우 난독화를 진행하면 오히려 빌드 파일이 커지는 경우도 있다.

다만 여기에서 말하고자 하는 난독화란 함수나 변수의 이름 등을 알파벳 문자 하나로 대체하거나 해서 알아볼 수 없을 만큼 축약하는 것을 말한다.

3. 실습

실습은 간단한 sum 함수를 각각 minify, uglify 하는 것으로 해보았다. 단, 여기서의 uglify는 번들의 크기를 늘리더라도 난독화를 강하게 하는 방식으로 진행하였다. 또, 실습툴은 gulp를 이용해보았다.

원본이 되는 코드는 아래와 같다.

// sum.js
module.exports = (a, b) => {
  return a + b;
}

// test.js
const sum = require('./sum');

console.log("function sum test!");
console.log("1 + 2 =", sum(1,2));

3-1. minify

minify해서 변환된 sum.js의 모습은 아래와 같다.

minify한 test.js의 모습도 보자.

척 보기에도 코드의 길이가 많이 짧아졌다. 사실 여기서는 uglify도 함께 쓰이고 있어서 더욱 그렇게 보인다. 실제 용량을 확인해보면 더 확실하게 알 수 있다.

minify해서 변환된 파일과 기존 파일의 용량 차이를 아래에 삽입해보았다. 43바이트가 26바이트가 되었고, 89바이트가 87바이트가 되었다.

아마도 test.js의 크기가 많이 줄어들지 않은 건, sum.js보다 줄일 수 있는 부분이 적었기 때문에 그런 것으로 보인다.

3-2. uglify

이번에는 난독화를 했을 때의 코드를 보자. 정확히는 minify와 uglify를 통해 변환된 sum.js의 모습이다. 척 보기에도 무슨 말인지 모르겠고, 코드가 엄청 길어졌다.

test.js도 마찬가지이다. sum.js처럼 한 화면에 다 담기지 않을 정도로 코드가 길어졌다.

용량은 아래처럼 바뀌었다.

sum.js는 43바이트에서 2키로바이트로, test.js는 89바이트에서 2키로바이트로 바뀌었다. 용량이 상당히 늘어난 것을 알 수 있다.

그래서 보통은 이런 방식으로 난독화를 할 땐 프론트에서 다루진 않는 것 같다. 이런 난독화는 주로 서버에서 처리하거나 노출하고 싶지 않은 일부 로직들만 이렇게 변환한다.

4. 결론

minify와 uglify는 앞서 말했던 것처럼 번들의 크기를 줄여, 최종적으로는 웹 사이트를 빠르게 로딩하는 것이 목적이다.

하지만 이 방법을 사용한다고 해서 무조건 웹 사이트의 로딩이 빨라지는 것은 아니다.

특히 uglify 같은 경우엔 난독화의 단계를 높일수록 코드를 해석하고 실행하는 데 시간이 더 오래 걸리게 된다.

따라서 프로젝트의 성격을 잘 파악해야 하고, 난독화의 단계도 그에 맞도록 조절해야 한다.

5. 출처

https://www.happykoo.net/@happykoo/posts/56

CDN이란?

CDN이란 콘텐츠 전송 네트워크(Content delivery network 또는 content distribution network (CDN))으로, 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템이다. (역시 무슨 말인지 모르겠으므로) CDN을 표현한 그림부터 보자.

그림을 보면 왼쪽의 노란색 부분이 Origin Server이다. 그리고 그 Origin Server를 중심으로 파란색의 CDN Server가 존재한다. 플로우를 보자면, 유저는 Origin Server가 아닌 CDN Server로 요청을 하고 그 CDN Server에서 Origin Server로 다시 요청을 보낸다.

즉, CDN Server는 택배 hub 같은 것이다. 우리가 택배를 받을 때 택배를 부치는 곳에서 바로 우리집으로 택배를 받는 것이 아니라, hub를 한 번 거치는 것처럼 우리가 요청을 보냈을 때 Origin Server로 바로 요청을 보내는 것이 아니라 CDN Server로 요청을 보내는 것이다.

그럼, CDN은 왜 사용하지?

그럼 당연히 궁금하게 된다. Origin Server에 바로 요청하면 빠르게 받을 수 있을 것 같고, CDN Server를 거치면 여간 귀찮지 않을 텐데... 왜 사람들은 CDN을 이용하는 것일까? 많은 사람들이 CDN을 사용하는 데에는 분명히 이유가 있을 텐데.

우선 첫 번째 장점으로는 웹 사이트의 로딩 시간을 개선할 수 있다. 예를 들어 보면 훨씬 와닿을 것이다. 예를 들어서 내가 미국에 살고 서버가 미국에 있는 서비스에 접속한다면, 대체로 원활하게 접속할 수 있을 것이다. 하지만 내가 한국에 있는 서비스를 이용하고자 한다면, 아마도 동일 조건의 미국내에 서버가 있는 것보다는 느린 서비스를 이용하게 될 것이다. 하지만 CDN Server는 여러 지역에 존재하기 때문에 사용자가 어느 지역에서 접근하든 Origin Server를 하나만 두었을 때보다 물리적 거리가 가까울 확률이 높아진다.

두 번째 이유로는 대역폭 비용이 절감된다는 것이다. 당연한 말이지만 Server는 유저의 요청에 응답할 때마다 대역폭이 소비된다. 그리고 대역폭이 증가될 수록 비용은 증가하게 된다. 금액적인 부분이든, 다른 부분이든. CDN Server는 이 문제를 캐싱을 통해 해결한다. 아마 이 글을 읽는 분들에게 캐싱은 익숙한 개념이겠지만, 간단히 설명해보자면 데이터를 저장해두었다가 같은 요청이 들어오면 그 저장한 데이터만 꺼내어 주는 것이다. 즉, CDN Server에 해당 데이터가 있다면 Origin Server에 요청을 보내지 않고도 미리 저장해둔 데이터를 유저에게 제공할 수 있다.

세 번째 이유로는 이중화가 가능하다는 점이다. 대규모 트래픽이나 하드웨어 장애가 발생했을 때, Origin Server 하나만 존재한다면 해당 서비스는 멈춰버리고 말 것이다. 이는 유저에게 불쾌한 경험을 선사하고, 서비스를 이용하지 않을 이유가 되기도 한다. 다행히 CDN을 이용한다면 동일 조건의 Origin Server를 하나만 운영하는 것에 비해 훨씬 안정적이다. CDN이 분산되어 있으므로 다수의 트래픽을 견디고, 하드웨어 장애에 대응할 수 있기 때문이다.

그 외에도 CDN을 이용하는 장점은 많다. 그럼 웹 사이트의 모든 문제는 CDN을 이용하면 다 해결되는 걸까?

당연히 아니다.

많은 장점을 가지고 있는 CDN도 완벽하진 않다. 특히나 프론트엔드 개발자로서 알아두어야 할 점은 CDN이 캐시 서버라는 점이다. 아마 프론트 개발을 해보신 분들은 한번씩 경험해보셨을 텐데, CSS 같은 것을 수정해도 웹 사이트에 바로 반영이 안 되는 경우가 있을 것이다. 이때 우리는 강력 새로고침이나 캐시 비우기를 하곤 한다. (때로는 둘 다 한다!) 이런 문제가 CDN을 이용할 때에도 나타난다.

앞서 말했던 것처럼 CDN은 캐시 서버이므로 Origin Server의 변경 내역을 바로바로 반영하지 못 한다. 즉, CDN Server에 있는 내용이 최신의 상태가 아닐 수도 있다는 것이다.

해결책은?

그럼 또 생각이 많아진다... 아니, CDN의 장점을 줄줄 말하기에 '써야 하나?' 싶었는데, 최신 상태를 반영하지 못 한다니? 쓰라는 건지 말라는 건지 헷갈린다. 그래도 다행히 이 문제를 해결할 방법은 있다. (우린 늘 그렇듯 답을 찾을 테니까 🤣)

캐시는 TTL(Time To Live)에 따른 생애 주기를 가지는데, 개체가 삭제되거나 새로 고쳐지기 전에 캐싱 시스템에 저장된 시간이다. 즉, 저장된 콘텐츠의 유효 기간이라고 생각해도 좋다.

그러니까 해결법은 '기다리면 된다.'는 것이다. TTL이 끝날 때까지 말이다. 좀 더 자세히 말하자면, TTL에 따라 CDN이 처리하는 방식이 달라진다.

위의 그림을 보면 알 수 있듯이 TTL이 만료되면, CDN Server는 Origin Server에 콘텐츠 변경 여부를 확인한다. Origin Server가 304 Not Modifined라는 응답을 준다면, 콘텐츠가 변경되지 않은 것이므로 TTL은 그냥 유지된다. 하지만 만약 상태가 변경되었다면, Origin Server는 200이라는 응답과 함께 변경된 콘텐츠를 보내준다. 그러면 CDN은 이렇게 변경된 콘텐츠를 캐싱하는 것이다.

이 해결법(?)이 허무한가? 하지만 정말이다... 만약 이를 기다릴 수 없다면, 물론 다른 방법도 존재한다! 명백하게 콘텐츠가 변경되었고, 이를 즉시 반영하고 싶을 땐 Purge / Expire / HardPurge 등의 도구를 통해 기존의 콘텐츠를 즉시 무효화시킬 수 있다.

여기까지 읽은 분들은 가슴을 쓸어내릴 지도 모른다. (특히나 프론트 개발자 분들이 그러시지 않을까?) 다만 아래와 같은 부분은 CDN을 이용하기 전에 고려해보면 좋을 것 같다.

CDN 서비스는 특정 국가나 지역만을 타깃으로 할 땐 이용하지 않는 게 좋다. 이 경우에는 불필요한 연결 지점만 늘어나, 오히려 성능이 떨어질 수도 있기 때문이다.

또 특정 CDN 서비스에 의존도가 너무 높을 경우 문제가 생기기도 한다. 최근에 BBC 등의 거대한 웹 사이트가 완전히 작동되지 않는 경우가 있었는데, 이때도 어떤 CDN 회사의 서비스가 먹통이 된 게 그 이유였다. 물론 자체적으로 인프라를 구축하는 것보다야 이런 서비스를 이용하는 것이 훨씬 안정적이겠지만, 우리 회사의(혹은 나의) 서비스가 특정 회사의 컨디션과 직결되는 것은 확실히 유쾌한 일은 아닐 것이다.

마무리하며

이렇게 CDN 서비스에 대해 알아보았다. 각자의 상황에 맞게 CDN을 이용하면 유용할 거라 생각한다!

ps. CDN을 사용하다 보면, 글에는 담지 못 한 여러 가지 불편한 부분이나 좋은 점이 생길 것입니다. 부족한 주니어 개발자가 개인적으로 공부하며 정리한 것이라, 틀린 부분도 있고 미처 담지 못 한 부분도 많을 거라 생각합니다. 혹시라도 그 부분에 대해 댓글로 알려주신다면, 꼭 알아보도록 하겠습니다. (이쪽은 사실 잘 모르는 분야라 조심스럽네요... 🥲)

출처

https://cjnews.cj.net/%EC%98%A5%EC%B2%9Chub%EA%B0%80-%ED%83%9D%EB%B0%B0%EC%9D%98-%EC%84%B1%EC%A7%80-cj%EB%8C%80%ED%95%9C%ED%86%B5%EC%9A%B4-%ED%83%9D%EB%B0%B0%EA%B0%80-%EC%9A%B0%EB%A6%AC%EC%97%90%EA%B2%8C-%EC%98%A4/ https://ko.wikipedia.org/wiki/%EC%BD%98%ED%85%90%EC%B8%A0_%EC%A0%84%EC%86%A1_%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC https://www.cloudflare.com/ko-kr/learning/cdn/what-is-a-cdn/ https://ston.readthedocs.io/ko/latest/admin/caching_purge.html

1.1. 연결 리스트?

• 컴퓨터 과학에서 연결 리스트는 메모리의 물리적 배치에 따라 순서가 지정되지 않는 데이터 요소의 선형 모음입니다(In computer science, a linked list is a linear collection of data elements whose order is not given by their physical placement in memory.)
• 대신, 각 요소는 다음 요소를 가리킵니다 . 그것은 함께 시퀀스를 나타내는 노드 모음으로 구성된 데이터 구조 입니다.(Instead, each element points to the next. It is a data structure consisting of a collection of nodes  which together represent a sequence.)

무슨 말인지 전혀 모르겠으므로 아래 그림을 보도록 하자. 그림을 보면 조금은 더 수월하게 이해할 수 있다.

저기 알약같이 생긴 부분이 노드 모음으로 구성된 데이터 구조이다. 앞 부분에는 값이 들어있고(10, 20, 30, 40), 뒷 부분에는 다음 노드를 가리키는 주소가 있다. (10->20, 20->30, 30->40) 그리고 이 노드 중 가장 첫 번째에 있는 것을 HEAD, 끝 부분에 있는 것을 TAIL이라 부른다.

대략적으로 연결리스트의 모양새를 알아보았으니, 다음은 종류에 대해서 알아보기로 하자.

1.2. 연결 리스트 종류?

연결리스트의 종류를 위키에서 찾아보면 꽤 많지만, 그중 다뤄보고 싶은 세 가지만 소개해보겠다.

• 단일 연결 리스트(Singly linked list)
  • 말 그대로 단방향으로만 연결된 연결리스트이다.
  • 단방향이기 때문에 끝 부분에 도착했을 때(null값을 반환할 때) 다시 돌아갈 수 없다.

• 이중 연결 리스트(Doubly linked list)
  • 단일 연결리스트와는 다르게 앞과 뒤에서 모두 접근이 가능한 연결리스트이다.

• 순환 연결 리스트(Circular linked list)
  • 위의 연결리스트들과는 다르게 TAIL의 다음 값이 HEAD 값이다. (사실상 그래서 TAIL과 HEAD의 구분이 없다.)

2.1. 배열과의 차이점 및 공통점

• 차이점

  1) 배열은 index가 있지만, 연결 리스트는 없다. 따라서 index로 접근할 수 없다. (array[index] 이런 식으로 접근이 불가능함.)

  2) 배열은 메모리에 저장될 때 인접한 위치에 저장되지만, 연결 리스트는 랜덤한 위치에 저장된다.

• 공통점

  1) 데이터들의 모음이다.

  2) 선형 구조이다.

2.2. 배열과 비교했을 때 연결 리스트의 장점과 단점

• 장점

  • 삽입과 삭제할 때 일반적으로 더 빠르다.

  • 이유 : 연결 리스트는 삽입이나 삭제될 때의 이전, 이후 노드의 참조값(next)만 변경하면 되어서. 배열의 경우, 리스트의 중간에 삽입이나 삭제를 할 경우 해당 엘리먼트의 뒤에 있는 모든 엘리먼트가 자리 이동을 해야함.

그림으로 보자면 아래와 같다.

삽입할 때

삭제할 때

• 단점

  • 검색할 때 일반적으로 더 느리다.
  • 이유 : 연결 리스트의 경우, 어떤 노드를 찾으려고 할 때 무조건 head부터 검색해야 한다. 즉, 찾으려는 노드가 제일 끝 노드라면 처음부터 끝까지 리스트를 전부 순회해야 한다(단일 연결 리스트의 경우에). 반면 배열의 경우, 인덱스를 이용해서 해당 엘리먼트로 바로 접근할 수 있다.

그림으로 보자면 아래와 같은 상황이다.

이와 관련해서 속도를 비교해둔 표도 있어서 첨부해보았다.

3. 알고리즘에서 나오는 연결 리스트

나는 이 연결리스트를 알고리즘 문제 풀이를 하면서 알게 되었고, 문제 풀이 상황에서는 연결리스트가 어떻게 나오는지 소개하면 좋겠다고 생각했다. 문제 풀이 사이트인 백준과 리트코드에서 문제를 골라보았다.

1) 연결 리스트(종합) : https://www.acmicpc.net/problemset?sort=submit_desc&solvedac_option=xz%2Cxn&algo=154&algo_if=and

• 백준 대표 문제(제출 수 가장 많은 거) - 1406. 에디터 : https://www.acmicpc.net/problem/1406

2) 단일 연결 리스트 : https://leetcode.com/tag/linked-list/

• leetcode 대표 문제(easy에서 따봉 젤 많은 거) - 21. Merge Two Sorted Lists : https://leetcode.com/problems/merge-two-sorted-lists/

• 이중 연결 리스트 : https://leetcode.com/tag/doubly-linked-list/

• leetcode 대표 문제(medium에서 따봉 젤 많은 거) - 146. LRU Cache : https://leetcode.com/problems/lru-cache/

사실 위의 문제를 다 풀어보아도 문제에서 연결리스트를 활용하기란 쉽지 않다. (저만 그런가요?) 왕도는 없으니 꾸준히 해당 유형을 풀어보는 수밖엔 없을 것 같다. ^_ㅠ (화이팅...!)

4. 출처

• 내용 출처

  • https://en.wikipedia.org/wiki/Linked_list
  • https://ko.javascript.info/recursion
  • https://opentutorials.org/module/1335/8821

• 문제 출처

  • https://leetcode.com/
  • https://www.acmicpc.net/

선언형 프로그래밍이랑 명령형 프로그래밍 좋지. 근데, 프로그래밍이 뭔데?

우선 선언형 프로그래밍과 명령형 프로그래밍에 대해 알아보기 전에 ‘프로그래밍' 그 자체에 대해서 알아보자.

프로그래밍이란 컴퓨터 프로그래밍(영어: computer programming) 또는 간단히 프로그래밍(programming, 문화어: 프로그램 작성) 혹은 코딩(coding)은 하나 이상의 관련된 추상 알고리즘을 특정한 프로그래밍 언어를 이용해 구체적인 컴퓨터 프로그램으로 구현하는 기술을 말한다. 프로그래밍은 기법, 과학, 수학, 공학, 심리학적 속성들을 가지고 있다.

여기서 주목해야 할 부분은 특정한 프로그래밍 언어를 이용해 구체적인 컴퓨터 프로그램으로 구현하는 기술이라는 점이다. 즉, 선언형 프로그래밍과 명령형 프로그래밍 모두 프로그램을 구체화하는 방법인 것이다.

다만 두 방법이 다르게 불리는 이유가 있을 것 같은데, 구체적으로 무엇이 다른 걸까?

선언형 프로그래밍

우선은 선언형 프로그래밍에 대해서 알아보자. 선언형 프로그래밍이란 프로그램이 무엇과 같은지 설명하는 방식을 말한다.

즉, 어떤 방법으로 해야 할 지 구체적으로 알려주는 것이 아니라 목표를 명시하는 방법인 것이다.

그러면 궁금해질 것이다.

“아니, 구체적으로 알려주는 게 아니면 어떻게 코딩을 해?”

하지만 생각보다 우리는 선언형으로 코드를 작성해왔다. 바로 아래처럼 말이다.

위의 두 코드는 둘 다 동일한 기능을 한다. 둘 다 array라는 숫자 배열에서 22보다 큰 숫자 배열을 반환하는 점에서는 동일하지만, 그 방식이 다르다.

첫 번째 코드는 for 반복문을 통해 아이템을 하나하나 돌면서 각 요소가 22보다 큰 지 검사해준다. 이는 프로그래머가 컴퓨터에게 무슨 행동을 해야 할 지 명시적으로 알려준 것이다.

두 번째 코드는 array의 내장 메소드인 filter를 사용하였다. 프로그래머는 filter안의 내용이 어떻게 구성되어 있는지 모른다. 다만 filter를 이용하면 array의 요소를 하나씩 확인할 수 있으며, 조건에 맞는 요소들만 뽑아서 새로 배열을 만들 수 있다는 건 알게 된다. 위의 반복문을 사용할 때와 하는 일은 똑같지만, 프로그래머가 한 것은 컴퓨터에게 무엇을 할 지 명확하게 알려준 것이다.

여기까지 읽었으면 짐작했을 것이다. 첫 번째 방식으로 작성된 것이 뒤에서 살펴 볼 명령형 프로그래밍이고, 두 번째 방식으로 작성된 것이 선언형 프로그래밍이다.

정리하자면 이렇다. 선언형 프로그래밍은 구체적인 알고리즘을 프로그래머가 작성하는 것이 아니라, 고도로 추상화된(캡슐화된) 명령으로 무엇을 할 지만 명시해주면 된다.

즉, 선언형 프로그래밍 내부는 명령형으로 작성이 되어 있지만 그것은 추상화(캡슐화)되어 있어서 프로그래머는 그 내부 로직에 신경을 쓰기 보다는 무엇을 구현할 지에만 집중할 수 있게 된다.

명령형 프로그래밍

위에서 선언형 프로그래밍에 대해서 알아 봤으니 이번에는 명령형 프로그래밍에 대해서도 알아보자. 위키의 정의에 따르면, 명령형 프로그래밍은 자료 처리를 수학적 함수의 계산으로 취급하고 상태와 가변 데이터를 멀리하는 프로그래밍 패러다임의 하나이다.

무슨 말인지 모르겠으니 바로 코드부터 보도록 하자!

선언형 프로그래밍에서도 다루었던 코드이다. 앞서 말했듯 첫 번째 코드가 명령형으로 작성된 코드인데, 조금 더 자세히 보자.

for문을 보면 array의 길이만큼 반복문을 돌고, 그 내부 로직은 조건문을 통해 요소 하나하나가 22보다 큰 지 검사하고 있다. 그리고 만약 해당 조건에 포함된다면(22보다 크다면), result 배열에 하나씩 넣어준다.

해당 코드는 무엇을 하는지가 명확히 보인다. 그리고 하나씩 절차적으로 진행되고 있다. 반복문을 돌면서 조건을 탐색하고, 조건에 일치한다면 액션(여기서는 result 배열에 요소를 넣는 것)이 발생하는 것이다.

다만 해당 코드가 어떻게 동작할 지는 프로그래머가 구체적으로 작성해주어야 한다. 반복문이 어디서부터 어느 범위까지 돌 것인지, 조건에 해당한다면 어떤 액션이 발생할 지 등 말이다. 두 번째 코드에서 filter 내장 메소드를 쓰는 것과는 확연히 다르다.

우리는 filter 메소드를 사용할 때, filter의 내부가 어떻게 동작하는지 구체적으로 알 필요는 없다. 그저 filter 메소드의 인자로 들어온 callback 함수가 true일 때, 해당 값들이 새로운 배열로 반환된다는 것만 알면 된다.

즉, 명령형 프로그래밍은 무엇을 해야 할 지 컴퓨터에게 알려주는 것이 아니라, 프로그래머 스스로 컴퓨터가 수행할 명령을 순서대로 작성하는 방법인 것이다.

결론

지금까지 선언형 프로그래밍과 명령형 프로그래밍에 대해서 알아보았다. 개인적으로 선언형 프로그래밍이 좀 더 모던한 느낌이 있는데(javascript의 3대 라이브러리 중 하나인 react 역시 선언형으로 작성되어서 더 그런 것 같기도 하다.), 그렇다고 해서 두 개념이 우월 관계에 있는 것은 아니다.

프로그래밍이 발전되어 온 역사를 이해하고, 상황에 맞게 적재적소에 사용한다면 좋을 것 같다.

출처

https://ko.wikipedia.org/wiki/%EC%BB%B4%ED%93%A8%ED%84%B0_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

https://ko.wikipedia.org/wiki/%EC%84%A0%EC%96%B8%ED%98%95_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

https://ko.wikipedia.org/wiki/명령형_프로그래밍

많은 사람들이 알고 있다시피, 모든 CSS 속성이 동일하게 적용되진 않는다. 다만 구체적으로 어떤 경우에 우선 순위를 부여 받는지 헷갈리므로(사실 다른 분들은 어떤지 모르겠지만, 내가 헷갈린다…), 정리해보고자 한다.

CSS 우선 순위란?

CSS 우선 순위 혹은 명시도라고 불리는 규칙은 브라우저가 어느 요소와 가장 연관된 속성인지 찾는 수단으로, 이렇게 찾은 속성이 해당 요소에 적용된다. 그리고 이 명시도는 여러 종류의 CSS 선택자로 구성된 일치 규칙에 기반한다.

즉, CSS 우선 순위란 브라우저가 CSS 선택자를 통해 어떤 요소를 (우선적으로) 적용할 것인지 판단하는 규칙이다.

무엇이 더 우선하나?

아래 그림을 보면, css 우선 순위를 한눈에 볼 수 있다! 아무것도 없는 상태(*)가 가장 가중치가 낮고, !important가 가장 가중치가 높다.

그림으로 간단하게 살펴봤지만, 더 자세히 알아보자. 가장 우선하는 속성부터 나열하자면 아래와 같다.

1. 속성 값 뒤에 !important를 붙인 속성

• !important가 붙은 color: red가 적용된 모습
  #### 2. HTML에서 style을 직접 지정한 속성(inline)
• inline으로 적용한 color: green이 적용된 모습
  #### 3. 아이디로 지정한 속성
• id가 world인 color: blueviolet이 적용된 모습
  #### 4. 클래스 혹은 추상 클래스로 지정한 속성
• class, id, tag가 있을 때는 id에 부여된 color: blueviolet이 우선하는 모습
• id가 없어지고 나서는 class가 hello인 것에 부여된 color: aqua가 적용된 모습
  #### 5. 태그 이름으로 지정한 속성
• div나 span처럼 태그 이름으로 지정한 속성이 다음으로 가중치를 얻게 된다.
  #### 6. 상위 객체에 의해 상속된 속성
• css에서는 부모로부터 상속받는 속성(ex. color, ...)과 상속받지 않는 속성(ex. padding, background, ...)이 있다. 그 중 부모로부터 상속받는 속성이 다음으로 가중치를 얻게 된다.
  

위 순서대로 우선 가중치가 높아지게 되는데, 그럼 또 궁금한 점이 생길 것이다.

‘만약 같은 우선 순위에 속한다면?’이라는 생각이 자연스럽게 들 수밖에 없는데,

이 경우에는 위의 선택자들이 모두 동일한 경우, 부모-자식 관계가 많은 경우가 우선된다.

그리고 만약 정말 모든 설정이 같은 경우엔 나중에 선언한 것이 우선되어 적용된다.

• 나중에 선언된 color: brown이 적용된 모습
• color: brown과 color: cornflowerblue의 위치를 바꾸자, 마지막에 위치한 color: cornflowerblue가 적용된 모습

출처

1) https://developer.mozilla.org/ko/docs/Web/CSS/Specificity

2) https://www.w3schools.com/css/css_specificity.asp

1-1. 글또 시작 이유

다들 개발자로서 기술 블로그를 운영하고 싶은 욕구는 있을 것이다. 나도 마찬가지였다. 하지만 이런저런 것들에 우선 순위가 밀려서, ‘해야 하는데....’라고만 생각하곤 했다.

그때 글또를 알게 되었고, 이렇게 강제성이 있다면 내 기술 블로그를 꾸준히 가꿀 수 있을 것 같았다.

그리고 무엇보다 난 다양한 분야의 개발자 분들과 소통하길 원했다. 비전공 개발자로서 비슷한 고민을 나눌 분들도 필요했고, 타 분야의 이야기도 듣고 싶었기 때문이다. 그렇게 하기에 글또가 좋은 계기가 되리라 생각했다.

1-2. 글또를 하며 얻고 싶은 것

자연스럽게 글또를 하며 얻고 싶은 것에 대해 이야기해보자. 위에서 말한 글또 시작 이유와 크게 다르진 않다.

첫 번째로 얻고 싶은 것은 ‘기술 블로그를 꾸준히 관리하는 습관’이다. 이번 7기의 규칙은 2주에 한 번, 반드시 글을 남겨야 한다. 패스권을 사용하거나 예치금에서 차감하면 그 주는 넘어갈 수 있지만, 웬만하면 사용하지 않으려고 한다.

이렇게 관리하는 습관을 기르면, 글을 쓰는 근육이 길러진다고 믿는다. 나중에 글또를 하지 않을 때에도 그 근육으로 블로그를 꾸준히 운영해나갔으면 좋겠다.

두 번째로 얻고 싶은 것은 ‘더 넓은 개발 커뮤니티’이다. 오픈 카카오톡 등으로 좋은 분들을 만나고, 회사 사람들과도 이야기를 자주 하는 편이지만 그 외의 사람들이 궁금했다. 글또 구성원은 데이터 엔지니어, 머신러닝 엔지니어부터 시작해서 프론트, 백엔드 엔지니어 분들 등등이 계셔서 다양한 분들과 좀 더 많이 이야길 나눠보고 싶다.

글또도 이를 위해서 많이 도와주신다. 각기 채널을 배정해주셔서 채널별로 이야기를 나눠볼 수도 있고, 피드백 제도도 있다. 4회 차 이후부터는 남이 작성한 글에 대해 의무적으로 피드백을 해야 하는데, 이러면서 다른 분들과 안면을 익힐 수 있을 것 같다. 또, 이번 기수부터는 커피챗이 독려된다. 커피챗을 하면 최대 2회까지 회당 5000원의 커피챗 지원금이 나온다. (오히려 만원을 벌어가는 기적의 글또!) 이런 기회들을 활용해보려 한다.

2. 어떤 글을 쓸 것인가

구체적으로 어떤 글을 쓸 지 말해보자면, 아래와 같다.

1) firebase, netlify 배포 방법

2) 알고리즘 스터디에서 내가 준비한 발표 자료(주로 자료 구조. 알고리즘을 소개할 가능성도 있음)

3) 현재 하고 있는 토이 프로젝트(가능하다면 개인, 팀플 모두)

4) 타입스크립트 공부한 내용 정리(타입스크립트 핸드북을 토대로)

6) 정처기 공부한 내용

7) 그 외 자바스크립트와 관련된 부분! 일단 생각해둔 내용은 이렇다. 7-1) lazy loading을 하며 IntersectionObserver을 사용했는데, 이 부분을 좀 정리해보고 싶다. 7-2) 선언형 프로그래밍과 명령형 프로그램에 대해서도 정리해보고 싶다.

위에서 언급한 글감이 아니더라도 다른 좋은 글감이 있으면 그걸로 포스팅을 할 예정이다.

3. 글을 마치며

공교롭게도 글또를 시작하면서 여러 일이 겹치게 되었지만, 현명하게 잘 풀어나가보려 한다.

그리고 마감에 급급해서 글을 올리는 데 집중할 수도 있는데, 일정 수준 이상의 퀄리티는 꼭 유지해야 되겠다.

(과연 5개월 뒤의 난 이 글을 보며 어떤 마음일 지... 기대된다...!! 화이팅!)